Refinamiento casos de usoDaniel Correa BoteroJose López VélezAná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.

• Clases• Objetos• Máquina de

estados• Interacciones

• Actividades

• Despliegue

• Paquetes• Componentes

Kruchten’s 4+1 view model

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 objetivosOBJ – <id> <nombre descriptivo>

Facilitar la creación de horarios 

Versión  <nro de la versión actual> (<fecha de la versión actual>) 1.0 (17-09-2013)

Autores  <autor de la versión actual> (<organización del autor>)Fuentes  <fuente de la versión actual> (<organización de la fuente>)Descripción 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. 

Sub-Objetivos  OBJ – <id>Importancia <importancia del objetivo>

 AltaUrgencia <urgencia de objetivo> 

AltaEstado <estado del objetivo> 

PendienteEstabilidad  <estabilidad del objetivo>

altaComentarios  <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> <nombre descriptivo>

Consultar aulas disponiblesVersión <n° de la versión actual>(<fecha de la versión actual>)Autores <autor de la versión actual>(<organización del autor>)Fuentes <fuente de la versión actual>(<organización de la fuente>)

jefe del departamento de sistemasObjetivos asociados

OBJ-X <nombre del objetivo>

Descripción El sistema deberá<capacidad del sistema>El sistema deberá permitir al usuario consultar las aulas disponibles en un momento dado.

Importancia <Importancia del requisito>alta

Urgencia <Urgencia del requisito>alta

Estado <Estado del requisito>Estabilidad <Estabilidad del requisito>Comentarios <comentarios adicionales sobre el requisito>

Formato para requisitos no funcionales

NFR – <id> <nombre descriptivo>Usabilidad

Versión <nro de la versión actual> (<fecha de la versión actual>)Autores <autor de la versión actual>(<organización del autor>)Objetivos asociados OBJ-X <nombre del objetivo>Requisitos asociados FRQ – X <nombre del requisito>Descripción 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

el entendimiento de los procesos de la aplicación.Importancia AltaUrgencia MediaEstado PendienteEstabilidad Alta

Formato para requisitos de información. (qué, cuándo)

IRQ - <id> <nombre descriptivo>Registrar aula

Versión <nro de la versión actual> (<fecha de la versión actual>)Autores <autor de la versión actual>(<organización del autor>)

Fuentes  <fuente de la versión actual>(<organización de la fuente>)Objetivos asociados OBJ-X <nombre del objetivo>

Requisitos asociados FRQ – X <nombre del requisito>Descripción El sistema deberá almacenar la información pertinente a un aula.Datos específicos Ubicación

Medios disponibles Capacidad

Tiempo de vida Media Máximo Indeterminado Indeterminado

Ocurrencias simult. Media Máximo 3 6

Importancia AltaUrgencia InmediataEstado Pendiente Estabilidad AltaComentarios  

Formato para reglas de negocio

CRQ-01 <nombre descriptivo>Asignación de Aulas

Versión 1.0 (10-06-2009)Autores <autor de la versión actual>(<organización del autor>)Fuentes  Objetivos asociados OBJ-2, OBJ-4, OBJ-5Requisitos asociados FRQ – 4Descripción El número de aulas asignadas a cada materia no debe exceder el cupo

máximo de cada asignaturaImportancia AltaUrgencia AltaEstado PendienteEstabilidad  Comentarios  

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 Acción sistema 1) Accede a Matriculas.

2) Selecciona crear matricula. 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. 6) Almacena la matricula y ejecuta el caso de uso Visualizar Horario.

7) Selecciona terminar sesión. 8) Finaliza la sesión del usuario.

Flujo Alternativo 1 2.a) Selecciona listar matricula. 2.b) Recopila información referente a la matricula del estudiante y la muestra en pantalla.

2.c) Visualiza la información y termina su sesión.

2.d) Finaliza la sesión del usuario.

Flujo Alternativo 2 2.c. i) Selecciona actualizar matricula.

2.c. ii) Realiza los cambios deseados y selecciona almacenar.

2.c. iii) Actualiza la matricula y ejecuta el caso de uso Visualizar Horario.

2.c iv) Selecciona terminar sesión. 2.c v) Finaliza la sesión del usuario.

Flujo Alternativo 3 2.c. i) Selecciona eliminar matricula y confirma su selección.

2.c. ii) Actualiza la matricula y registra los cambios.

2.c v) Selecciona terminar sesión. 2.c vi) Finaliza la sesión del usuario.

Postcondición Se registra, consulta, modifica o elimina una matrícula.

Flujo Excepcional 3. a) No se puede realizar la matricula.

3. b) Se lee el error y se toman las medidas necesarias para solucionarlo.

Frecuencia 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