Transcript Refinamiento casos de uso

Refinamiento casos de
uso
Daniel Correa Botero
Jose López Vélez
Análisis de Sistemas II
¿Qué es un caso de uso?
Un caso de uso es un caso (o situación) en el cual el sistema es usado
para cumplir uno o más de los requisitos de los usuarios; un caso de uso
captura una pieza de funcionalidad que el sistema provee.
Los casos de uso están en el corazón de todo el modelo dado que
afectan y guían a todos los demás elementos dentro del diseño del
sistema.
Su fin principal es lograr un objetivo cuantificable.
La mayoría de los proyectos requieren muchos casos de uso para
describir su alcance total.
Fueron introducidos pro Ivar Jacobson en los inicios de los 90’s.
Kruchten’s 4+1 view model
• Clases
• Objetos
• Máquina de
estados
• Interacciones
• Despliegue
• Actividades
• Paquetes
• Componentes
Desde un objetivo a un caso de
uso
 Existen varias técnicas para extraer los casos de uso de una
aplicación. Una buena manera consiste en ir desde un
objetivo del negocio a un (unos) casos de uso que ayuden a
cumplir tal objetivo.
Objetivos
 General: Debe dar amplia claridad con respecto a la única
función general del sistema.
«Permitir a los usuarios del departamento de
ingeniería de sistemas un manejo sistematizado de la
información asociada al pensum, como: Planes de
estudio, materias, periodos, docentes, aulas y horarios.»
 Específico: Debe lograr que se consiga detallar la función
general del sistema, a través de la definición de productos
que se puedan medir en cada objetivo.
«Facilitar la creación de horarios»
Formato para objetivos
OBJ – <id>
Versión
Autores
Fuentes
Descripción
Sub-Objetivos
Importancia
Urgencia
Estado
Estabilidad
Comentarios
<nombre descriptivo>
Facilitar la creación de horarios
<nro de la versión actual> (<fecha de la versión actual>)
1.0 (17-09-2013)
<autor de la versión actual> (<organización del autor>)
<fuente de la versión actual> (<organización de la fuente>)
El sistema deberá <objetivo a cumplir por el sistema>
El sistema deberá facilitar la elaboración de horarios de los cursos que se dictan en
el programa de ingeniería de sistemas y, además, notificar de alguna incoherencia
en el horario planteado en tiempo real.
OBJ – <id>
<importancia del objetivo>
Alta
<urgencia de objetivo>
Alta
<estado del objetivo>
Pendiente
<estabilidad del objetivo>
alta
<comentarios sobre el objetivo>
Mapa conceptual
 Otro elemento importante que es útil para aclarar el proyecto
es un mapa conceptual que relacione los términos relevantes
del dominio del problema.
 Este puede ser desarrollado con ayuda de los stakeholders.
Formato para requisitos
funcionales (cómo)
FRQ-<id>
Versión
Autores
Fuentes
Objetivos
asociados
Descripción
Importancia
Urgencia
Estado
Estabilidad
Comentarios
<nombre descriptivo>
Consultar aulas disponibles
<n° de la versión actual>(<fecha de la versión actual>)
<autor de la versión actual>(<organización del autor>)
<fuente de la versión actual>(<organización de la fuente>)
jefe del departamento de sistemas
OBJ-X <nombre del objetivo>
El sistema deberá<capacidad del sistema>
El sistema deberá permitir al usuario consultar las aulas disponibles en un momento
dado.
<Importancia del requisito>
alta
<Urgencia del requisito>
alta
<Estado del requisito>
<Estabilidad del requisito>
<comentarios adicionales sobre el requisito>
Formato para requisitos no
funcionales
NFR – <id>
Versión
Autores
Objetivos asociados
Requisitos asociados
Descripción
<nombre descriptivo>
Usabilidad
<nro de la versión actual> (<fecha de la versión actual>)
<autor de la versión actual>(<organización del autor>)
OBJ-X <nombre del objetivo>
FRQ – X <nombre del requisito>
El sistema deberá<capacidad del sistema>
El manejo de la aplicación deberá ser intuitivo, de modo que el
usuario no requiera demasiado
tiempo en aprender a utilizar el
sistema. El sistema brindará una interfaz gráfica enfocada a facilitar
Importancia
Urgencia
Estado
Estabilidad
el entendimiento de los procesos de la aplicación.
Alta
Media
Pendiente
Alta
Formato para requisitos de
información. (qué, cuándo)
IRQ - <id>
Versión
Autores
<nombre descriptivo>
Registrar aula
<nro de la versión actual> (<fecha de la versión actual>)
<autor de la versión actual>(<organización del autor>)
Fuentes
Objetivos asociados
<fuente de la versión actual>(<organización de la fuente>)
OBJ-X <nombre del objetivo>
Requisitos asociados
Descripción
Datos específicos
FRQ – X <nombre del requisito>
El sistema deberá almacenar la información pertinente a un aula.

Ubicación

Medios disponibles

Capacidad
Tiempo de vida
Media
Indeterminado
Media
3
Alta
Inmediata
Pendiente
Alta
Ocurrencias simult.
Importancia
Urgencia
Estado
Estabilidad
Comentarios
Máximo
Indeterminado
Máximo
6
Formato para reglas de negocio
CRQ-01
Versión
Autores
Fuentes
Objetivos asociados
Requisitos asociados
Descripción
Importancia
Urgencia
Estado
Estabilidad
Comentarios
<nombre descriptivo>
Asignación de Aulas
1.0 (10-06-2009)
<autor de la versión actual>(<organización del autor>)
OBJ-2, OBJ-4, OBJ-5
FRQ – 4
El número de aulas asignadas a cada materia no debe exceder el cupo
máximo de cada asignatura
Alta
Alta
Pendiente
Retomando los casos de uso
«Si usted diseña una casa nueva y empieza a razonar acerca
de cómo usted y su familia la usarán, este es un análisis
basado en casos de uso. Usted considera las diferentes
maneras en las cuales usará la casa y estos casos de uso
guían el diseño.»
Grady Booch et al.
Un caso de uso es descrito a
menudo en texto claro
 Ejemplo: Registrar estudiante en un curso.
 Flujo principal de eventos: El caso de uso inicia cuando el
estudiante busca la página de registro del curso e ingresa sus
credenciales. El sistema presenta todos los posibles cursos para
este estudiante. El estudiante selecciona el curso de interés y
realiza la matrícula presionando el botón matricular.
 Flujo excepcional de eventos: El estudiante puede cancelar el
registro presionando el botón cancelar.
Por lo general un caso de uso es
seguido de una descripción más
detallada de cómo la funcionalidad
es lograda
 Precondición
 Flujo principal o excepcional de eventos expresados como
una lista de acciones.
 Postcondiciones.
Refinamiento y algunas
limitaciones
 Es posible trabajar de arriba hacia abajo, primero especificar
casos de uso en alto nivel y luego proceder con unos
diagramas de caso de uso más elaborados.
 Algunas limitaciones:
 Las interacciones entre los objetos dentro del sistema no son
modeladas.
 No se puede modelar concurrencia.
Elementos principales
 Actor: Persona, organización o sistema externo que desempeña un
papel en una o más interacciones con el sistema con el fin de lograr un
objetivo (usuario del sistema). Se pinta con un hombre de palo y su
nombre debajo de la figura.
 Caso de uso: Se muestra como una elipse con un nombre que lo
identifica (verbo + sustantivo).
 Asociación: Es la relación entre un actor y un caso de uso o entre dos
casos de uso.
 Escenarios: Es un camino que puede tomar un caso de uso. Existen
escenarios exitosos, en los cuales el objetivo del caso de uso se logra,
y los escenarios fallidos, donde el objetivo no se logra. Se puede ver
como instancia de un caso de uso.
 Límites del sistema (system boundaries): Es posible, y
recomendable, definir los límites del sistema. Resulta particularmente
útil si se tiene un sistema complejo.
Relaciones entre casos de uso
 Existen tres tipos de relaciones:
 Generalización (preferible no usarla)
 Include
 Extends
 El uso de estas características hacen que un diagrama sea
más difícil de leer, por lo tanto es recomendable usarlas con
cuidado.
Include
 La relación include indica que el caso de uso base incorpora
el comportamiento del otro caso de uso.
 El caso de uso base es dependiente del caso de uso
incluido, pero el caso de uso incluido no es dependiente del
caso de uso base.
 La funcionalidad compartida entre dos casos de uso pueden
ser extraída y descrita en un caso de uso separada e
incorporada usando esta relación.
Especificando un punto de
inclusión
 Registrar estudiante en un curso.
 Flujo principal de eventos:
 El caso de uso inicia cuando el estudiante busca la página de registro
del curso e ingresa sus credenciales.
 Punto de inclusión: validar estudiante.
 El sistema presenta todos los posibles cursos para este estudiante. El
estudiante selecciona el curso de interés y realiza la matrícula
presionando el botón matricular.
Extend
 Si un caso de uso incorpora dos o más escenarios
claramente diferenciados – algunas condiciones dictan
cuáles – esto puede ser modelado por una relación de
extend.
 La relación extend puede ser usada para modelar el
comportamiento que el usuario ve como opcional o como
una excepción al comportamiento normal. El caso de uso
base puede incorporar el comportamiento extendido bajo
ciertas condiciones de otra manera puede seguir actuando
de manera independiente.
Extend
 Se debe especificar:
 La condición sobre la cuál el uso extendido aplica.
 En cuál punto la condición debe ser evaluada y el
comportamiento puede divergir; este punto es llamado el punto
de extensión.
Generalización
 La relación de generalización indica que el caso de uso hijo
heredará el comportamiento y significado del caso de uso
padre. El caso de uso hijo puede alterar y/o extender el
comportamiento del caso de uso padre, pero debería ser
posible sustituir el caso de uso padre por el caso de uso hijo
en cada lugar donde éste es usado.
Extend y generalización
 Estas relaciones son muy similares, algunos dicen que UML
sería mejor con sólo una de ellas.
 Cómo seleccionar la relación a usar:
 Extend: si se desea describir un comportamiento extra que es
usado bajo determinadas condiciones; una condición que es
evaluada en tiempo de ejecución.
 Generalización: si se tiene una versión especializada de un caso
de uso entero.
¿Qué error hay en el diagrama?
Ejemplo diagrama
Nombre del Caso de Uso
Gestionar Matricula
Código del Caso de Uso
UC8
Actor(es)
Estudiante.
Descripción
Crear, listar, modificar o eliminar información referente a la matricula.
Precondición
El estudiante debe estar identificado y autentificado en el sistema.
Flujo Principal
Acción actor
1) Accede a Matriculas.
2) Selecciona crear matricula.
Acción sistema
3) Recopila la información
necesaria para realizar el proceso
(ejecuta el caso de uso Gestionar
grupos). Muestra en pantalla los
grupos ofertados.
4) Selecciona los grupos a
matricular.
5) Envía la matricula.
7) Selecciona terminar sesión.
Flujo Alternativo 1
2.a) Selecciona listar matricula.
2.c) Visualiza la información y
termina su sesión.
Flujo Alternativo 2
2.c. i) Selecciona actualizar
matricula.
2.c. ii) Realiza los cambios
deseados y selecciona almacenar.
2.c iv) Selecciona terminar sesión.
Flujo Alternativo 3
2.c. i) Selecciona eliminar
matricula y confirma su selección.
6) Almacena la matricula y ejecuta
el caso de uso Visualizar Horario.
8) Finaliza la sesión del usuario.
2.b) Recopila información
referente a la matricula del
estudiante y la muestra en
pantalla.
2.d) Finaliza la sesión del usuario.
2.c. iii) Actualiza la matricula y
ejecuta el caso de uso Visualizar
Horario.
2.c v) Finaliza la sesión del
usuario.
2.c. ii) Actualiza la matricula y
registra los cambios.
2.c v) Selecciona terminar sesión.
Postcondición
2.c vi) Finaliza la sesión del
usuario.
Se registra, consulta, modifica o elimina una matrícula.
Flujo Excepcional
3. a) No se puede realizar la
matricula.
Frecuencia
3. b) Se lee el error y se toman las
medidas necesarias para
solucionarlo.
Alta
Importancia
Alta
Referencias






Architectural blueprints: The ‘4+1’ View Model of software Architecture. Philippe
Kruchten, 2003. Doug Rosenberg and Kendall Scott: Use Case Driven Object
Modeling with UML:
A Practical Approach
Addison-Wesley
Ivar Jacobson: Object-Oriented Software Engineering: A Use Case Driven Approach.
Addison-Wesley, 1994
Martin Fowler with Kendall Scott: UML Distilled.
Addison-Wesley, 1997
Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language
User Guide.Addison-Wesley, 1999
Terry Quatrani: Visual Modeling with Rational Rose and UML.
Addison-Wesley, 1998
Daniel Tkach, Walter Fang and Andrew So: Visual Modeling Technique, 1996