Ingeniería de Software Laboratorio V

1. Ingeniería de SoftwareLaboratorio V Diseño - Casos de Uso Eduardo Saavedra A. 30/09/2009

2. Tópicos • ¿ Qué es un caso de uso? • Conceptos • Caso de uso • Actor • Escenario • Condiciones • Relaciones • Como confeccionar los casos de uso • Ejemplos

3. ¿ Qué es un caso de uso?

4. ¿ Qué es un caso de uso? • En ingeniería del software, un caso de uso es una técnica para la captura del comportamiento deseado de un sistema, sin tener que especificar como se implementa ese comportamiento.

5. ¿ Qué es un caso de uso? • Ningún sistema se encuentra aislado, siempre existe la interacción con actores, tanto humanos como mecánicos. • Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico.

6. ¿ Qué es un caso de uso? • Normalmente, en los casos de usos se evita el empleo de jergas técnicas, prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso. • Son creados bajo la identificación funcional de requerimientos pero no tienen una relación uno a uno con ellos (caso de uso != requerimiento).

7. Conceptos Caso de uso Actor Escenario Relaciones

8. Conceptos – Caso de uso • Nombre Caso de Uso • Debe estar compuesto por lo menos de un verbo. • Representa una acción que los usuarios realizan ante el sistema.

9. Conceptos – Actor • Actor • Representan roles que humanos, dispositivos de hardware o sistemas externos juegan mientras interactúan con el sistema • No son parte del sistema y están situados fuera de sus límites

10. Conceptos – Escenario • Escenario • Especifican el comportamiento de un caso de uso por descripción, no por modelamiento • Ejemplos incluyen texto estructurado informal, texto estructurado formal con condiciones y pseudocódigo. • Típicamente especifica: • Cómo y cuándo el caso de uso comienza y termina • Interacción con actores e intercambio de objetos • Flujo de eventos: normal (exitoso), alternativo (exitoso) y excepcional (falla) • Legible para el usuario NO experto.

11. Conceptos – Ejemplo Escenario • En el caso de uso “Validación de Tarjeta” de un sistema de cajero automático pueden haber estos escenarios: • Escenario normal: Validar un Cliente por medio de su clave. • Escenario alternativo: Validación de tarjeta fallida y se solicita reintentar. • Escenario excepción: Tarjeta se bloquea.

12. Conceptos – Condiciones • Pre-Condiciones • Describe el ambiente bajo el cual el caso de uso es invocado. • Post-Condiciones • Reflejan el impacto en el ambiente del caso de uso luego de su ejecución. • Requisitos de Calidad (opcional) • Por ejemplo, el sistema debe responder en menos de 30 segundos.

13. Conceptos – Ejemplo Condiciones • Para un caso de ingreso de ficha médica para un consultorio. • Pre-Condiciones • Usuario debe estar validado por el sistema. • Post-Condiciones • Ficha médica ingresada en el sistema. • Requisitos de Calidad (opcional) • El sistema debe responder en menos de 30 segundos para todo el flujo.

14. Conceptos – Relaciones • Asociación • Se utiliza para relación natural entre un actor y un caso de uso. • Nunca existe una asociación entre dos casos de uso • El uso de punta de flecha se deja de utilizar después de UML 1.2

15. Conceptos – Relaciones • <<include>> (<<uses>> en UML 1.2 ) • Si X incluye Y, Y siempre se realiza cuando se realiza X. • Y es un comportamiento común en más de un caso de uso.

16. Conceptos – Relaciones • <<extend>> • Si Y extiende X, bajo ciertas condiciones de la ejecución de X también se ejecuta Y. • Cuando se incluye un comportamiento de uso sólo bajo ciertas condiciones

17. Conceptos – Relaciones • Especialización (herencia) • Al igual que en la POO, la herencia consiste en rasgos que un Caso de uso hijo pueda heredar de su padre.

18. Como confeccionar un diagrama de CU • Identificar contexto: • Identificar Sistema - Límite • Identificar actores: ¿Quiénes usarán el sistema? • Identificar relaciones entre actores. • Identificar requisitios • Identificar casos de uso: ¿Qué interacciones tendrá el actor con el sistema? • Identificar relaciones entre los casos de uso: Extensiones, Inclusiones y Especializaciones. • Adornos a los casos de uso, notas, comentarios, etc.

19. Ejemplos

20. Ejemplo • Cajero automático (ATM)! • Asumamos un cajero donde se realizan depósitos en dinero y cheques. • El negocio distingue dos actores para efectuar operaciones, el cliente del banco y el poseedor de tarjeta. El Cliente de banco es el único que puede efectuar depósitos, mientras que el poseedor de tarjeta es el que puede retirar dinero al igual que el Cliente del banco. • Se sabe que el negocio envía cada cierto tiempo a operadores para reabastecer el cajero con dinero. Además ellos desbloquean las tarjeta que los usuarios han dejado en el ATM por fallas en su validación (luego de 5 fallas se bloquea).

21. Límites

22. Ejemplo – Cajero Automático • Identificación de actores

23. Ejemplo – Cajero Automático • Identificar Casos de uso

24. Ejemplo – Cajero Automático • Identificar Relaciones

25. Ejemplo – Cajero Automático

26. Escenarios • Recordar que un escenario es la instancia de un caso de uso! • Validación tarjeta:

27. Especificación de Caso de uso

28. Escenarios • Retiro de dinero

29. Bibliografía • I. Jacobson J. Rumbaugh and G. Booch. El LenguajeUnificado de Modelado. Addison-Wesley, 2000. • Roger S. Pressman. Ingeniería del Software. MC Graw Hill, 2000, SextaEdición.