PROCESO UNIFICADO DIRIGIDO POR CASOS DE USO

Presentación del tema: "PROCESO UNIFICADO DIRIGIDO POR CASOS DE USO"— Transcripción de la presentación:

1 PROCESO UNIFICADO DIRIGIDO POR CASOS DE USO
TEMA 12: PROCESO UNIFICADO DIRIGIDO POR CASOS DE USO

2 PROCESO DIRIGIDO POR CASOS DE USO
Se capturan requisitos de usuario a través de casos de uso. Son fundamentales para: Identificar y especificar clases, subsistemas e interfaces. Identificar y especificar casos de prueba. Planificar las iteraciones e integración del sistema. Nos guían a través de los flujos de trabajo.

3 PROCESO DIRIGIDO POR CASOS DE USO
En cada iteración se identifican e implementan unos cuantos casos de uso. Los casos de uso sirven para idear la arquitectura. Se seleccionan los casos de uso más representativos. Se utiliza como partida para escribir el manual de usuario. La captura de requisitos tiene dos objetivos: Encontrar los verdaderos requisitos. Representarlos de un modo adecuado para los usuarios, clientes y desarrolladores. Un sistema tiene muchos tipos de usuarios. Cada tipo de usuario se representa por un actor.

4 ¿POR QUÉ CASOS DE USO? Proporcionan un medio sistemático e intuitivo de capturar requisitos funcionales centrándose en el valor añadido para el usuario. Dirigen todo el proceso de desarrollo debido a que la mayoría de las actividades como el análisis, diseño y prueba se llevan a cabo partiendo de los casos de uso. Los casos de uso nos ayudan a llevar a cabo el desarrollo iterativo. Cada iteración, se dirige por los casos de uso a través de todos los flujos de trabajo, de los requisitos al diseño y a la prueba, obteniendo un incremento. Cada incremento es una realización funcional de un conjunto de casos de uso.

5 LOS CASOS DE USO ESPECIFICAN EL SISTEMA
Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede llevar a cabo, y que producen un resultado observable de valor para un actor concreto. Identificamos los casos de uso examinando como los usuarios necesitan utilizar el sistema para realizar su trabajo. Los casos de uso también se utilizan como contenedores de los requisitos no funcionales, tales como los requisitos de rendimiento, disponibilidad, exactitud y seguridad que son específicos de un caso de uso

6 PROCESO DIRIGIDO POR CASOS DE USO
Requisitos funcionales a través de casos de uso. Cliente del banco Sacar dinero Ingresar dinero Transferencia

7 PROCESO DIRIGIDO POR CASOS DE USO
Actores: usuarios, otros sistemas, hardware, software, etc. Un usuario puede actuar como varios actores. Varios usuarios pueden actuar como un mismo tipo de actor. La comunicación con el sistema se realiza mediante el paso de mensajes.

8 MODELO DE ANÁLISIS A PARTIR DE CASOS DE USO:
Crece incrementalmente. Se especifica a través de diagramas de clases y de colaboración. Al principio se examinan unos pocos casos de uso y se crean sus realizaciones. Cada clasificador puede participar en distintas realizaciones con distintos roles. Se utilizan clases estereotipadas de análisis (entorno, control y entidad).

9 MODELO DE ANÁLISIS A PARTIR DE CASOS DE USO:
Realización de un caso de uso (análisis): Modelo de casos de uso Modelo de análisis Sacar dinero Sacar dinero Cuenta Retirada efectivo Interfaz cajero Salida «traza»

10 MODELO DE ANÁLISIS A PARTIR DE CASOS DE USO:
Modelo de casos de uso Modelo de análisis Salida Retirada efectivo Sacar dinero Cliente del banco Interfaz cajero Transferencia Cuenta Ingresar dinero Cliente del banco Transferencia Receptor dinero Ingreso

11 MODELO DE DISEÑO A PARTIR DEL MODELO DE ANÁLISIS
Se adapta al entorno de implementación. Se define con los mismos diagramas. El modelo de diseño es más “físico” y el modelo de análisis más “conceptual”. Sacar dinero Modelo de casos de uso Modelo de análisis «traza» Modelo de diseño

12 MODELO DE DISEÑO A PARTIR DEL MODELO DE ANÁLISIS
Cuenta Retirada efectivo Interfaz cajero Salida Modelo de análisis Modelo de diseño «traza» «traza» «traza» «traza» Teclado Cuenta Gestor de Cliente Sensor de salida Retirada de efectivo Clase Persistente Dispositivo de visualización Alimentador de la salida Contador de efectivo Lector de tarjetas Gestor de Transacciones Gestor de Cuentas

13 PROCESO DIRIGIDO POR CASOS DE USO
Dispositivo de visualización Sensor de salida Teclado Alimentador de la salida Lector de tarjetas Contador de efectivo Retirada de efectivo Gestor de Cliente Gestor de Transacciones Cuenta Gestor de Cuentas Clase Persistente Cliente del banco

14 PROCESO DIRIGIDO POR CASOS DE USO
:Cliente del banco :Dispositivo de visualización :Teclado :Lector de tarjetas :Contador de efectivo :Gestor de Cliente :Gestor de Transacciones Introducir tarjeta Tarjeta introducida(ID) Solicitar PIN Mostrar petición Especificar código PIN Código PIN Validar código PIN Solicitar cantidad a retirar Mostrar petición Especificar cantidad Cantidad(C) Disponib. Saldo(C) Solicitar retirada cantidad(C)

15 PROCESO DIRIGIDO POR CASOS DE USO
Las clases se agrupan en subsistemas Dispositivo de visualización Sensor de salida Teclado Alimentador de la salida Lector de tarjetas Contador de efectivo Gestor de Cliente «subsystem» Interfaz del CA Gestor de Transacciones «subsystem» Transacciones Retirada de efectivo Efectivo Cliente del banco Cuenta Gestor de Cuentas Clase Persistente «subsystem» Gestión de Cuentas IEntrega ITransferen IRetirada