Refinamiento casos de uso

1. Refinamiento casos de uso Daniel Correa BoteroJose López VélezAnálisis de Sistemas II

2. ¿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.

3. Clases • Objetos • Máquina de estados • Interacciones Kruchten’s 4+1 viewmodel • Actividades • Paquetes • Componentes • Despliegue

4. 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.

5. 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»

6. Formato para objetivos

7. 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.

9. Formato para requisitos funcionales (cómo)

10. Formato para requisitos no funcionales

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

12. Formato para reglas de negocio

13. 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.

14. 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.

15. 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.

16. 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.

17. 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 (systemboundaries): Es posible, y recomendable, definir los límites del sistema. Resulta particularmente útil si se tiene un sistema complejo.

18. 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.

19. 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.

20. 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.

21. 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 extendpuede 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.

22. 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.

23. 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.

24. 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.

25. ¿Qué error hay en el diagrama?

26. Ejemplo diagrama

28. Referencias • Architecturalblueprints: The‘4+1’ View Model of software Architecture. PhilippeKruchten, 2003. Doug Rosenberg and Kendall Scott:Use Case Driven Object Modeling withUML:A Practical ApproachAddison-Wesley • IvarJacobson: 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