Qué Necesita el Usuario

Transcripción

1

2 Qué Necesita el Usuario

3 Qué Pidió el Usuario

4 Cómo lo Vio el Analista

5 Cómo se Diseñó

6 Cómo lo Escribió el Programador

7 Cómo Funciona el Sistema (en ocasiones...)

8

9 Qué es? Técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona uno o más escenarios que indican la interacción del usuario con el sistema, o entre sistemas para conseguir un objetivo específico.

10 Diagrama de casos de uso Muestra el Comportamiento del Sistema ud Curso Listar catálogo de cursos Muestra Alcance Sistema el del Alumno Inscribir en curso Sist. de Cobranza Interacciones con entidades externas Profesor Generar lista de curso

11 Elementos Actor Caso de Uso Relaciones

12 Actor Representa el rol que juega una entidad externa que interactúa con el sistema. Intercambia información con el sistema Puede ser un recipiente pasivo de información Actor Puede representar el rol que juega un humano, una máquina u otro sistema Se nombran generalmente con sustantivos en singular Cliente, Vendedor, Administrador, Alumno, Sistema de Nómina, etc.

13 Actor Es una idealización de una persona externa, de un proceso, o de una cosa que interactúa con un sistema, subsistema o una clase. Interactúa con el caso de uso intercambiando mensajes. Puede ser un ser humano, otro sistema informático, o un cierto proceso ejecutable. También pueden ser definidos en jerarquías de generalización.

14 Caso de uso ud Curso Caso de Uso Es la especificación de un conjunto de acciones que ejecuta el sistema Genera un resultado observable con valor real para el actor Describe un flujo de eventos completo Describe las interacciones entre el actor y el sistema El actor inicia un caso de uso cuando invoca cierta funcionalidad del sistema Al unir todos los casos de uso se tienen todas las formas posibles de usar el sistema Se nombran generalmente con un verbo en infinitivo: Realizar Venta, Cotizar Seguro, Generar Nómina, etc.

15 Caso de Uso Hacer pedido Es una unidad coherente de funcionalidad, externamente visible, que no revela la estructura interna del sistema. Se representa mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema (debe empezar con un verbo en infinitivo).

16 Relaciones entre casos de uso (1/2) En ocasiones hay fragmentos de funcionalidad que varios casos de uso comparten Para evitar la repetición, esta funcionalidad común la podemos factorizar en un caso de uso nuevo Los casos de uso que lo requieren, invocan al caso de uso factorizado

17 Relaciones entre casos de uso (2/2) Entre los casos de uso pueden darse dos tipos de relaciones: Dependencia Implica que la funcionalidad englobada en un caso de uso depende de otro ya sea por que el primero (dependiente) incluye o extiende la funcionalidad definida por el segundo Generalización Implica que un caso de uso especializado reutiliza tanto el comportamiento como las relaciones que posee otro caso de uso más general Además, el caso de uso especializado puede redefinir ciertas actividades definidas por el padre

18 Relación <<include>>

19 Relación <<extend>>

20 Relación Generalización

21 Caso de uso base Hacer pedido <<extend>> Solicitar Catálogo <<include>> <<include>> <<include>> Caso de uso de extensión Capturar datos de cliente Pedir Producto Pagar Producto Caso de uso padre Caso de uso de inclusión Pagar al contado Acordar Crédito Caso de uso hijo

22 Proceso de Desarrollo de CU Determinar la frontera del sistema. Determinar los actores que interactúan con el sistema. Para cada actor, determinar los modos fundamentalmente diferentes en los cuales el actor utiliza el sistema en términos de eventos. Cada uno de estos modos constituye un caso de uso. Para cada caso de uso: Identificar el evento inicial que arranca cada caso de uso Determinar la condición de terminación que concluye el caso de uso Dibujar un escenario prototípico o describir las variaciones en palabras Identificar y describir todas las excepciones que estén lógicamente asociadas con un caso de uso dado. Al terminar, verificar que el conjunto de los casos de uso comprenda toda la funcionalidad del sistema.

23 Ventajas La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor (su usuario) al hacer uso del sistema. Como técnica de extracción de requerimiento permite que el analista se centre en las necesidades del usuario, qué espera éste lograr al utilizar el sistema, evitando que la gente especializada en informática dirija la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos. El analista se concentra en las tareas centrales del usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la priorización del requerimiento.

24 Limitaciones Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no establecen completamente los requisitos funcionales No permiten determinar los requisitos no funcionales. Los casos de uso deben complementarse con información adicional como reglas de negocio, requisitos no funcionales, diccionario de datos que complementen los requerimientos del sistema.

25 Conclusión Los casos de uso no describen ninguna funcionalidad interna ni explican cómo se implementará. Simplemente muestran los pasos que el actor sigue para realizar una tarea. Herramienta En analista Determina su complejidad y funcionamiento.