Clase2
- 1. MPN5501 Profesor: Eduardo Berrios G.
- 2. Inicio ◦ Objetivos de la clase Desarrollo ◦ ¿Qué es un caso de uso? ◦ Diagramas de casos de uso Cierre ◦ Síntesis ◦ Lo que viene
- 3. Definir y describir Artefactos UML para BPMN. Diagramas de casos de uso (Modelo conceptual). Discutir la importancia que tienen los casos de uso para analizar sistemas
- 4. Recordemos que UML, ayuda a: ◦ Visualizar Ayuda a que analistas de SW e interesados en el proceso hablen mismo lenguaje ◦ Especificar Ayuda a definir modelos precisos ◦ Construir Sirve para conectarse con distintos tipos de programación ◦ Documentar requisitos, arquitectura del sistema, pruebas, etc.
- 5. UML Business Modelling Profile: ◦ Extensión de UML ◦ Ayudar a la comunicación entre usuarios y analistas
- 6. Como identificar un caso de uso?: ◦ Cuáles son las tareas y responsabilidades de cada actor? ◦ ¿Algún actor creará, almacenará, cambiará, borrará o leerá información del sistema? ◦ ¿Qué Casos de Uso crearán, almacenarán, cambiarán, borrarán o leerán esta información? ◦ ¿Es necesario que un Actor informe al sistema sobre cambios externos? ◦ ¿Es necesario que un Actor sea informado sobre ciertas incidencias del sistema? ◦ ¿Qué Casos de Uso darán soporte y mantendrán el sistema? ◦ ¿Pueden ser realizados por los Casos de Uso todos los requerimientos funcionales
- 7. Descripción de un conjunto de secuencias de acciones que ejecuta un sistema para producir un resultado observable para el actor: Actor Caso de uso Retirar dinero Cliente Nombre simple
- 8. Actor ◦ Representa un conjunto de roles que tienen los usuarios al interactuar con éstos ◦ Puede representar una persona, hardware o sistema ◦ Se puede definir categoría generales de actores y posteriormente generalizarlos, a través de una relacion de generalización actor actor Usuario Usuario autenticado
- 9. Proporcionar un medio para que desarrolladores, usuarios finales y expertos lleguen a una comprensión común del sistema Mostrar comportamientos esenciales de un sistema o subsistema y no debe ser mi muy específico ni muy genérico Describe que hace un sistema pero no como lo hace
- 10. El comportamiento de un caso de uso se puede especificar como un flujo de eventos en forma textual: ◦ Ejemplo: Validar usuario en Tbanc Evento principal: El sistema (pagina web) le pide al cliente ingresar su Rut y password. El cliente acepta presionando el botón entrar. A continuación se solicita ingresar el pin pass, presiona enter y el cliente entra a su sucursal virtual Evento alternativo: El sistema le pide al cliente ingresar su Rut y password. El Cliente ingresa la password erróneamente tres veces. El sistema lo bloquea
- 11. Escenarios: ◦ Es una interacción entre sistemas y actores que puede ser descrito como una secuencia de mensajes. El caso de uso será una generalización de un escenario Socio biblioteca Llevar prestado libro
- 12. Especificación de Escenarios:
- 13. Especificando relaciones los casos de uso para extraer su comportamiento y extenderlos en otros casos de uso ◦ Generalización ◦ Inclusión ◦ extensión
- 14. Generalización ◦ Hereda el significado y comportamiento del padre Caso de uso padre Caso de uso hijo
- 15. Inclusión ◦ Incluye explícitamente el comportamiento de un caso de uso en el caso base Gerente Comercial Buscar datos de producto cliente <<include>> <<include>> Ingresar pedido Obtener reporte de De Ventas por producto
- 16. Extensión ◦ Incluye implícitamente el comportamiento de un caso de uso en el caso base Se usa para modelar un comportamiento opcional del sistema cliente <<extend>> Realizar llamada Realizar llamada telefónica Con conferencia
- 17. Para modelar el comportamiento de un elemento ◦ Identificar los actores relacionados con ese caso de uso ◦ Organizar los actores desde los roles más generales a los más específicos ◦ Considerar las formas más importantes que tiene el actor para interactuar con el elemento ◦ Utilizar relaciones de inclusión y extensión en los casos de uso ◦ Modelar los casos de uso más importante del sistema
- 18. ¿Qué debiera incluir una descripción de un caso: ◦ Comentarios generales y anotaciones que describan el caso. ◦ Requerimientos: cosas que el caso de uso debe permitir hacer al usuario, tales como <habilidad para actualizar un pedido>, <habilidad para modificar el pedido>, etc. ◦ Restricciones: reglas acerca de qué se puede hacer y qué no se puede hacer. Incluyen: ◦ Pre-condiciones que deben ser verdaderas antes que el caso de uso “esté corriendo”, por ejemplo, <crear pedido> debe preceder a <modificar pedido> ◦ Post-condiciones que deben ser verdaderas una vez que el caso de uso “esté corriendo”, por ejemplo, <pedido es modificado y es consistente> ◦ Invariantes: estas deben ser siempre verdaderas, por ejemplo, un pedido siempre debe tener un número de cliente. ◦ Escenarios: descripción secuencial de los pasos necesarios para llevar adelante el caso de uso. Puede incluir multiples escenarios. ◦ Diagramas de escenario: diagramas de secuencia similares a los workflow, pero representados gráficamente. ◦ Atributos adicionales: tales como fases de implementación, número de versión, grado de complejidad,etc
- 19. Diagrama que muestra un conjunto de casos de uso, actores y sus relaciones. Se utilizan para modelar el comportamiento de un sistema.
- 21. Sistema: Teléfono móvil Teléfono móvil Realizar llamada Realizar llamada telefónica De conferencia Red Telefónica Recibir llamada telefónica Realizar llamada adicional Usuario Usar Agenda
- 22. Sintésis Actividad complementaria virtual ◦ Grupos tres alumnos ◦ Seleccionar algún proceso de una industria ◦ Hacer la descripción de casos de usos básicos ◦ Plazo una semana Lo que viene ◦ Diagramas de actividad