ESTRUCTURAR EL MODELO DE CASOS DE USO SEMANA 3 – Primera Sesión

Profesores del Curso: Aréstegui Guillén Oscar

Temario • • • •

Refinar la definición del sistema Detallar un Caso de Uso Documento Especificación de Caso de Uso Estructurar el Modelo de Casos de Uso.

Objetivos •Entender el datalle de un Caso de Uso •Estructurar el Modelo de Casos de Uso final •Entender la importancia de la Especificación de un Caso de Uso, base para el Análisis y Diseño.

I. MODELO DE CASOS DE USO 1. DEFINICION • Artefacto de UML • Casos de uso Propuestos inicialmente por Jacobson Mecanismos para ayudar a representar y comprender los objetivos y Requisitos Funcionales, de forma simple y comprensible para todo el personal involucrado (Cliente – Desarrolladores).

2. Actividades de la Captura de Requisitos Según el RUP, los principales pasos para capturar los requerimientos son: • Identificación de Actores y Casos de uso • Priorizar Casos de Uso • Detallar Casos de Uso • Estructurar el MCU • Prototipar la interfaz de usuario (GUI).

: Analista de sistemas

: Arquitecto

: Especificador de casos de uso

: Diseñador de interfaces de usuario

Encontrar actores y casos de uso Priorizar los casos de uso

Detallar un caso de uso

Estructurar el modelo de caso de uso

Prototipar la interfaz de usuario

2.1. Encontrar Actores y Casos de Uso • Objetivos  Delimitar el sistema y su entorno

 Esbozar quién y qué (actores) interactuarán con el sistema, y qué funcionalidad se espera del sistema  Capturar y definir un glosario de términos comunes esenciales para poder describir detalladamente los CU del sistema.

• Actividad decisiva para obtener adecuadamente los requerimientos • Responsabilidad del Analista de Sistemas

• Actividades (no tienen por qué seguir este orden)

 Establecer el límite del sistema: solo software, hardware y software como un todo, lo utiliza una persona, una organización, etc.  Encontrar actores principales: Usuarios que se satisfacen con el uso de los servicios del sistema

 Para cada actor, identificar sus objetivos de usuario  Definir los CU que satisfagan los objetivos de usuario. Nombrarlos de acuerdo con sus objetivos  Describir brevemente (descripción informal) cada CU.

2.1.1. Actores • Representan entidades externas que (mantenimiento y/o operación) con el sistema • Puede ser un usuario o un sistema externo • Un actor representa un rol:

interactúan

No se corresponde directamente con personas concretas Toda persona que interactúa con el sistema es representado al menos por un actor en el MCU

• Identificación de Actores

¿Qué grupos de usuarios necesitan el sistema para su trabajo? ¿Qué usuarios realizan las funciones principales del sistema? ¿Qué usuarios realizan funciones secundarias, como mantenimiento o administración? ¿Existe algún sistema externo de hardware o software?

• Se da nombre a los actores y se describen brevemente sus papeles y para qué utilizan el sistema.

Identificar Actores principales y objetivos Además de actores principales y objetivos, se pueden utilizar diferentes preguntas para identificar otros menos evidentes: • ¿Quién arranca y detiene el sistema? • ¿Quién administra el sistema? • ¿Quién gestiona los usuarios y la seguridad?

• ¿Es un actor el “tiempo” porque el sistema hace algo como respuesta a un evento de tiempo? • ¿Quién evalúa la actividad o el rendimiento del sistema?

Tipos de Actores • Actor Principal: Usuario que se satisface mediante el uso de los servicios del sistema (Cajero) • Actor de Apoyo: Proporciona un servicio y/o información al sistema a desarrollar (Autorización de Pago). Normalmente es un Sistema Informático, pero puede ser una Organización o una persona • Actor Pasivo: Está interesado en el comportamiento del CU, pero no es principal ni de apoyo (Agencia Tributaria).

La Lista Actor - Objetivo (recoge

los Actores principales y sus

objetivos de usuario). Actor

Objetivo

Actor

Objetivo

Cajero

Procesar ventas Gestionar devoluciones Abrir caja Cerrar caja

Administrador del sistema

Añadir usuarios Modificar usuarios Eliminar usuarios Gestionar seguridad Gestionar tablas

Jefe de cajas

Controlar productividad cajero Distribuir cajeros en cajas

Sistema de Control de Ventas

Analizar datos de ventas y rendimiento

2.1.2. Identificación de Casos de Uso •Escenario (o instancia de caso de uso) Es una descripción narrativa de lo que la gente hace cuando utiliza una aplicación, es una secuencia específica de acciones e interacciones entre los actores y el sistema. Descripción concreta e informal de una sola característica del sistema, desde el punto de vista de un solo actor Los analistas y los usuarios escriben y refinan diversos escenarios para comprender mejor lo que debe hacer el sistema

Identificación de escenarios ¿Qué tareas necesita el actor que realice el sistema? ¿Qué información consulta el actor? ¿quién crea esos datos? ¿se pueden modificar? ¿quién puede hacerlo? ¿Qué cambios externos necesita informar el actor al sistema? ¿Cuándo y con qué frecuencia? ¿De qué eventos necesita el actor que le informe el sistema? ¿cuándo y con qué frecuencia?

• Caso de Uso  Especifica todos los escenarios posibles para una determinada funcionalidad  Es iniciado por un Actor  Puede interactuar con otros actores  Representa un flujo de eventos completo a través del sistema, es decir, describe una serie de interacciones relacionadas que resultan de la inicialización del CU.

2.1.3. Relaciones entre Actores y CU • Representan el flujo de información durante el CU • Se puede distinguir entre el Actor que inicia el CU y los demás actores que intervienen posteriormente • Los CU identificados previamente a partir de los objetivos de los actores, se representan mediante óvalos y representan una tarea que el sistema en desarrollo tiene que incorporar • El Modelo de Casos de Uso representa el contexto del sistema: Límites del sistema Qué permanece fuera del sistema Cómo se utiliza el sistema

Resume el comportamiento de un sistema y sus actores

2.2. Priorización de casos de uso • Determinar cuáles son necesarios para el desarrollo en las primeras iteraciones y cuáles pueden dejarse para posteriores iteraciones • Cuestiones a tener en cuenta: CU con dificultad de desarrollo

CU imprescindibles para la puesta en marcha del sistema Organización del desarrollo incremental Disponibilidad de equipo de desarrollo

• Se revisa la priorización con el Jefe de Proyecto y se utiliza como entrada para la planificación de cada iteración del proyecto.

Detallar los casos de uso

2.3. Detallar los casos de Uso • Objetivo principal: describir su flujo de sucesos en detalle Cómo comienza Cómo termina Cómo interactúan con los actores • Se detalla paso a paso la secuencia de acciones del CU • Se trabaja estrechamente con los usuarios reales de los CU • Resultado: descripción detallada mediante – Texto – Diagramas

2.4. Estructurar el modelo de Casos de Uso • Extraer descripciones de funcionalidad (de casos de uso) generales y compartidas que pueden ser utilizadas por casos de uso más específicos • Extraer descripciones de funcionalidad (de casos de uso) adicionales u opcionales que pueden extender casos de uso más específicos (relaciones de extensión) • Extraer descripciones de funcionalidad (de casos de uso) adicionales e incondicionales incluidas en la ejecución de casos de uso específicos (relaciones de inclusión).

2.4.1. Generalización • Simplifica la forma de trabajo y la comprensión del MCU • Permite reutilizar CU “semifabricados” cuando se reúnen CU terminados, requeridos por el usuario y se les llaman CU concretos • El CU “semifabricado” existe solamente para que otros CU lo reutilicen y se les llaman CU abstractos. No pueden instanciarse por sí mismos Una instancia de CU concreto también exhibe el comportamiento especificado por CU abstracto (reutilizado).

Comprador

Ejecutar transacción

Pagar factura

Vendedor

2.4.2. Relaciones de Extensión entre Casos de Uso • Un CU extiende otro caso de uso si éste puede incluir el comportamiento del primero bajo determinadas condiciones • Ventajas de separar el flujo excepcional y opcional con respecto al CU básico  El CU básico se hace más pequeño y comprensible  Se distingue entre el caso común y el excepcional, permitiendo que los desarrolladores los traten de forma diferente

• Ambos son CU completos por sí mismos, con condición inicial y final, y comprensibles por el usuario • Regla general: utilizar relaciones de extensión para comportamientos excepcionales, opcionales o que rara vez ocurren.



OficialCampo

Conexión perdida Informar Emergencia

Comprador

Vendedor

Pagar factura



Ejecutar transacción Pagar cargos saldo deudor

2.4.3. Relaciones de inclusión entre casos de uso • Permiten dividir las redundancias y reutilizar CU • El comportamiento sólo debe dividirse en CU separados cuando es compartido por dos o más CU • No conviene dividir en exceso (especificación confusa) • Regla general: utilizar relaciones de inclusión para comportamientos que se comparten entre dos o más CU.

Controlador

Ver plano

Asignar Recursos

Ampliar préstamo



Prestatario Libro

Comprobar reservas

Tomar libro prestado

2.4.4. Identificación de Casos de Uso de Mantenimiento, Consulta y Reportes • Los CU hasta el momento identificados son las actividades necesarias para que se ejecute un Proceso del Negocio. • Además existen CU de Mantenimiento de los archivos del sistema, Consultas y/o Reportes realizadas por el usuarios • Se adicionan en el MCU (al final) los cuales también deben mostrados al Usuario • Deben ser incluidos en la Lista de Casos de Uso • Participan en la Priorización de Casos de Uso, para identificar en que interacción del proyecto se debe implementar.

2.5. Prototipado de la interfaz • Diseño lógico de la interfaz: se decide qué se necesita de las interfaces de usuario para habilitar los CU para cada actor • Diseño físico de la interfaz: se desarrollan prototipos que ilustran cómo pueden utilizar el sistema los usuarios para ejecutar los CU • Resultado final: conjunto de esquemas de interfaces de usuario y prototipos de interfaces que especifican la apariencia de esas interfaces para los actores más importantes. ___ ___ ___ ___ Requisitos Modelo de ___ casos deadicionales uso Caso de uso ___ (descrito) Prototipar ___ la interfaz ___ Glosario

Prototipo de interfaz de usuario

No olvidar los requerimientos no funcionales • Aspectos del sistema visibles para el usuario, no relacionados de forma directa al comportamiento funcional del sistema. • Aspectos:  GUI y factores humanos: tipo de interfaz, experiencia, etc.  Documentación: destinatarios, tipo de documentación técnica, etc.  Consideraciones de HW: compatibilidad con otro hardware, existencia de otros sistemas, etc.  Características de Ejecución: usuarios concurrentes, carga de trabajo, etc.  Gestión de errores y excepciones  Calidad: fiabilidad, disponibilidad, robustez, etc.  Modificaciones futuras  Ambiente físico: condiciones climáticas, exposición a golpes, accidentes, etc.  seguridad.

II. ESPECIFICACION DE CASOS DE USO

1. ¿QUÉ ES LA ECU?

• Se describen QUE hacen el Actor y el Sistema y NO COMO se implementa • Tanto el camino básico como los alternativos deben describirse textualmente en una sección de la ECU.

2. Partes de una ECU 1. Nombre • Debe indicar el título del Caso de Uso 2. Breve Descripción • Descripción pequeña de las actividades o pasos principales que realiza el CU. • Debe incluir el propósito del CU.

3. Flujo de Eventos Evento Disparador Evento que demandan la ejecución del CU del sistema. Evento ante el cuál el sistema de software debe reaccionar. Indica que Actor inicia el CU: El Caso de Uso comienza “cuando” el Actor solicita ….. Se pone antes del Flujo Básico.

3.1. Flujo Básico • Incluir el punto de inicio y de termino del CU. • Conjunto ordenado de acciones (enumerados) realizados por el Actor y el Sistema, para alcanzar el propósito • La instancia del CU se inicia y pasa a un estado de comienzo • El CU es invocado por el mensaje de un actor • Transita a otro estado realizando una secuencia de acciones (cálculos, selección de camino, mensajes de salida, etc.)

• Queda a la espera (en el nuevo estado) de otro mensaje externo • Es invocado (otra vez) por un nuevo mensaje • Termina la instancia del CU • El camino elegido como básico debe ser el normal, el más habitual u obvio para el Actor que actúa en la mayoría de los escenarios • Incluir mensajes de confirmación.

1

2

3

9

FLUJO BASICO

10

CASO INCLUIDO •Activación mandatoria del CU incluido, en algún evento del flujo de eventos del CU principal (el que incluye) •El sistema incluye el Caso de Uso •Se grafica en la actividad “Estructurar el MCU”.

1

2

3

9

Mandatorio 1

n

CU INCLUIDO

10

4. Flujo(s) Alternativo(s) Los caminos alternativos, desviaciones o excepciones pueden ocurrir porque: • Si está implicado más de un actor, las acciones de uno de ellos pueden influenciar el camino de las acciones de los otros • El sistema puede detectar ingresos erróneos de los actores • Violación de Reglas del Negocio.

• Alguna falla en el funcionamiento de alguno de los recursos del sistema, por lo que éste no puede efectuar su trabajo hasta el fin del CU. Incluir si el CU continua o termina, además de los mensajes preventivos o alertas.

1

2

3

9

10

Escenario 3.1

3.n

FLUJO ALTERNATIVO

5. Subflujos • Los subflujos se dan cuando el actor elige otra opción dentro del CU. • Por Ejemplo en Gestión de Productos: Ingresar Producto es el Flujo Básico. Los Subflujos serían: Actualizar Producto, Eliminar Producto, Consultar Producto. • Los Subflujos también tienen Flujos Alternativos.

6. Pre y Post Condiciones • Son estados del sistema de los que el usuario puede darse cuenta.

6.1. Pre Condiciones Expresan condiciones o restricciones para que el flujo de eventos del CU comience (no es el evento inicial) •Se expresan en términos de: Estado interno del sistema de software Condiciones externas al sistema de software (estado del contexto) Una precondición de un CU no se aplica a subflujos individuales, sino a todo el CU. Futuro (debe…).

¿?

EVENTO

CONDICION

QUE

ACCION

= ECA

6.2. Post Condiciones • Expresan las condiciones que deben darse una vez realizado el CU (resultados esperados en forma exitosa). • Se expresan en términos de: Estado interno del sistema de software Condiciones externas al sistema de software (estado del contexto) Futuro (debe ...)

¿?

EVENTO

CONDICION

QUE

ACCION

¿?

ESPERADO

7. Puntos de Extensión • Activación condicionada de un CU extendido en algún paso del flujo de eventos de CU principal • El sistema se extiende al Caso de Uso Se grafica en la actividad “Estructurar el MCU”.

1

2

3

9

10

Condición 1

n

CU EXTENDIDO

7.1. Generalización / Especialización • Definición de casos de usos de propósito específicos a partir de un caso de uso de propósito general • El caso de uso general no es ejecutado, en su lugar el sistema se usa para el desarrollo de los casos específicos.

8. Prototipos (GUI) Una alternativa para la definición de los requerimientos. Consiste en capturar un conjunto inicial de necesidades e implementarlas rápidamente con la intención de expandirlas y refinarlas iterativamente, al ir aumentando la compresión que tienen del sistema los Usuarios y Desarrolladores.

3. TIPS PARA DETALLAR LOS CU • Escriba oraciones cortas, concisas • Evite adverbios: muy, casi, mejor que, bastante, etc. • Emplee correctamente los signos de puntuación • Evite usar oraciones compuestas • Describa el flujo, no sólo el propósito del CU • Describa sólo el flujo del CU, evite mencionar eventos de otros CU que pudieran ejecutarse en paralelo

• No mencione actores que no intervienen en el CU • Si el orden de los eventos no es fijo, esta característica debe ser explícita • Emplee lenguaje simple y claro, evitando términos técnicos.

4. ¿QUIÉNES LEEN LAS ECU? • Clientes: aprueban lo que debe hacer el sistema • Usuarios: obtienen comprensión del sistema • Desarrolladores del Sistema: documentan el comportamiento del sistema • Revisores: examinan el flujo de eventos • Analistas del Sistema / Diseñadores: proveen la base para un análisis y diseño • Testeadores del Sistema: usado como base para casos de prueba • Líder de Proyecto: provee entradas para el planeamiento de proyectos • Escritor Técnico: para el “Manual de Usuario”.

5. PLANTILLA 1. Nombre del Caso de Uso 2. Breve Descripción 3. Flujo de Eventos Evento Disparador 3.1 Flujo Básico 1. 2. Incluir Casos de Uso 3. n…. 3.2 Flujos Alternativos 3.2.1 < Primer Flujo Alternativo > 3.2.2 < Segundo Flujo Alternativo >

3.3 < Sub Flujos > 3.3.1 < Flujos Alernativos del Sub Flujo > 4. Requerimientos Especiales 4.1 < Primer Requerimiento Especial > 5. Pre Condiciones 5.1 < Precondición 1 > 6. Post Condiciones 6.1 < Post Condición 1 > 7. Puntos de Extension 7.1 > 8. Prototipo (GUI).

Ejemplo de Caso de Uso

EVENTOS

Login: Passwor d: Aceptar Evento: acción sobre algún elemento de la interfaz y que provoca una reacción DE IMPORTANCIA en el sistema.

Cancelar

Cuando el usuario indica Aceptar el Sistema válida si el password y el login son válidos.

FLUJO BÁSICO DE EVENTOS ¿Qué hace el usuario?

¿Qué hace el sistema?

1. Ingresar login 2. Ingresar password

3. Indicar Aceptar

4. El sistema válida si el password y el login son válidos

Flujo alternativo de Eventos ¿Qué hace el usuario?

¿Qué hace el sistema?

1. Ingresar login 2. Ingresar password

3. Indicar Aceptar

4. El sistema valida si el password y el login son válidos

Alternativas Si en 4 el Sistema determina que el password y el login no son válidos entonces emitirá al usuario el mensaje: “login y password inválidos”. Y se regresa al paso 1

Ejemplo de Especificación de Caso de Uso