unidad 4 mad modelado analisis casos de uso

Sergio Sánchez Rios

Análisis y UML

“Fundamento de los Casos de Uso”

Metodologías de Análisis y DiseñoUnidad IV

Sergio Sánchez Rios.

Ingeniero en Informática – Licenciado en Informática


UML: Fundamentos de los modelos de Caso de

Uso Fueron presentados por primera vez por Jacobson a principios de los 90.

Los casos de uso documentan el comportamiento del sistema (acción y reacción) desde el punto de vista del usuario.

Como <<usuario>> se entiende cualquier cosa que ajena al sistema se desarrolla y que interactúa con el mismo (persona, sistema de información, dispositivos de hardware, etc.).

El modelado de caso de uso ayuda con tres de los aspectos más difíciles del desarrollo: La captura de requisitos, La planificación de las iteraciones del desarrollo, La validación de los sistemas.


UML: Fundamentos de los modelos de Caso de

Uso Definición:

Un caso de uso especifica un comportamiento deseado del sistema.

Representan los requisitos funcionales del sistema.

“Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor” .

Describe que hace el sistema, no como lo hace.


Un diagrama de caso de uso es relativamente fácil de comprender de forma intuitiva, incluso sin conocer la notación. Esto es una ventaja importante.

Figura que representa al caso de uso. Un caso de uso individual representa un tipo de tarea que tiene que soportar el sistema

Los casos de uso también se describen en detalle, normalmente en texto. (Descripción de alto nivel, Formato expandido)

UML: Fundamentos de los modelos de Caso de Uso

<Use Case Name>

(from <Use Case Name>)


Otro componente de los caso de uso es el Actor, normalmente aparece con el símbolo de un muñeco, representa un tipo de usuario del sistema.

Notación UML

Un actor es una entidad externa del sistema que de alguna manera estimula el sistema con eventos de entrada o espera una respuesta del sistema.


<Actor Name>

(f rom Actors)


Los actores suelen ser los roles representados por las personas, como también cualquier tipo de sistema. Ejemplo:

Roles: Cliente, Cajero, Alumno, Profesor.

Sistemas de Computo.

Aparatos electrónicos o mecánicos.

El tiempo puede ser un actor (“procesos iniciados por el sistema”)

La misma persona física puede desempeñar varios roles distintos.



Ejemplo:

Hay una línea que conecta un actor con un caso de uso si el actor interactúa con el sistema para realizar parte de la tarea. (Comunicación sencilla).


<Use Case Name>

(from <Use Case Name>)<Actor Name>

(f rom Actors)


Beneficiarios: Cada caso de uso tiene que representar una tarea, que se le requiere al sistema que soporte. Normalmente esto significa que el caso de uso tiene valor para al menos uno de los actores. Al actor para el que un caso de uso tiene valor se le llama beneficiario del caso de uso.

Por esta razón los desarrolladores tienen que conocer quién necesita un caso de uso (Actor Primario) y quien esta implicado en él sin obtener ningún beneficio (Actor Secundario).

Identificar los actores: los usuarios humanos potenciales de un sistema, tienden a ser relativamente fáciles de identificar. Para desarrollar un modelo de caso de uso se necesita identificar los roles que estos humanos pueden desempeñar.

UML: Actores en Detalle


Actores no humanos: la situación con los actores no humanos tiende a ser menos clara, principalmente debido a que es menos claro qué se debería considerar como un sistema externo o dispositivo.

La solución es pragmática: se hace lo que parece que va a ser más útil, y distintas personas tienen visiones diferentes. Incluso si esta claro lo que es un sistema externo o dispositivo, nace una pregunta qué cosa debería aparecer en un caso de uso. Fowler y Scott, resumen diciendo que se pueden mostrar las interacciones con sistemas externos:

Siempre.

Cuando es el otro sistema o dispositivo el que inicia el contacto.

Cuando es el otro sistema o dispositivo el obtiene algo del contacto.

UML: Actores en Detalle


Son iniciados por un actor con un objetivo en mente y es completado con éxito cuando el sistema lo satisface.

Pueden incluir secuencias alternativas que llevan al éxito y fracaso en la consecución del objetivo.

El sistema es considerado como una “caja negra” y las interacciones se perciben desde fuera.

El conjunto completo de casos de uso especifica todas las posibles formas de usar el sistema, esto es el comportamiento requerido.

UML: Propiedades de los casos de uso


Un caso de uso describe un conjunto de secuencias de interacciones o escenarios: flujo principal y flujo alternativos o excepcionales.

Un escenario es una instancia de un caso de uso.

UML: Escenarios y Casos de Uso


UML: Ejemplo

Comprar producto

Log In

Pagar producto

Inicializar

Terminar

Agregar usuarios

CajeroCliente

Sist. Adm.

Gerente

Sist. Punto de VentaSist. Punto de Venta

Actor Caso de uso

Cajero Log inDar vuelto

Cliente Comprar productosPaga productos

Gerente IniciarTerminar

Sistema administrador Agregar nuevos usuarios


Descripción en lenguaje natural, respetando el dominio del problema.

Formatos:

Formato de Alto nivel: describen muy clara y concisamente un proceso.

Formato expandido: describe un proceso en mayor detalle, concentrándose en el curso de los eventos: describen los detalles de la interacción entre el sistema y sus actores.

UML: Formato para Casos de Uso


Descripción del formato de alto nivel

• Caso de Uso: Nombre del Caso de Uso

• Actores: Lista de Actores (agentes externos)

• Tipo: Primario (Representa un proceso común e importante), Secundario (representa un proceso menor o raro), Opcional (representa un proceso que no debe abordarse necesariamente)

• Descripción: Resumen de los eventos involucrados en el caso de uso.



Descripción del formato de alto nivel

Ejemplo:


Caso de uso: Comprar productos

Actores: Cliente, Cajero

Descripción: Un cliente llega a la caja registradora con los artículos que comprará. El Cajero registra los artículos y recibe el pago, el cual debe ser autorizado. Al terminar la operación, el Cliente se marcha con los artículos comprados.

Tipo: Primario


Descripción formato Expandido

Primera Sección:

• Caso de Uso: Nombre del Caso de Uso.

• Actores: Lista de Actores (agentes externos), en el cuál se indica quien inicia el caso de uso.

• Propósito: Intención del caso de uso.

• Precondición: Descripción de las condiciones que deben satisfacerse antes de dar inicio al caso de uso. No se prueban en el caso de uso se asumen que son verdaderas.




Primera Sección:

• Resumen: Repetición de la descripción de alto nivel.

• Tipo: 1.- Primario, secundario u opcional. 2.- Esencial (caso de uso expandido libre de aspectos tecnológicos y detalle de implementación (diseño, interfaz usuario, etc.), Real (caso de uso expandido que describe concretamente el proceso a partir de su diseño concreto actual, sujeto a las tecnologías especificas de entrada.




Primera Sección:

• Referencia Cruzada: casos de uso y funciones relacionadas con el sistema.

Segunda Sección: Curso normal de eventos (Escenario principal de éxito y pasos).

• Detalle de la conversación iterativa entre los actores y el sistema.

• Se explica la secuencia genérica más común no las situaciones alternativas.




Segunda Sección:

Formato Dos columnas

Acción del Actor Responsabilidad del Sistema (Respuesta del Sistema)

Acciones numeradas de los actores

Descripción numerada de las respuestas del sistema




Ultima Sección: Curso alternativo de eventos

• Describe las opciones o excepciones más importantes que pudiesen presentarse en el curso normal de eventos. Si son muy complejas pueden convertirse en otro caso de uso o sección.



Descripción formato expandido

Ejemplo:


Caso de uso: Comprar productos

Actores: Cliente (iniciador), Cajero

Propósito: Capturar una venta y su pago en efectivo.

Resumen: Un cliente llega a la caja registradora con los artículos que comprará. El Cajero registra los artículos y recibe el pago, el cual debe ser autorizado. Al terminar la operación, el Cliente se marcha con los artículos comprados.

Tipo: Primario y esencial

Referencias Cruzadas:

Funciones: R1.1, R1.2, R1.3, R1.7, R2.1



Ejemplo: Segunda Sección


Acción de los actores Respuesta del sistema

1.- Comienza cuando el cliente llega a una caja con productos que desea comprar.

2.- El cajero registra la identificación de cada producto. Si hay varios productos de una categoría, se puede introducir la cantidad

3.- Determina el precio del producto e incorpora a la transacción actual la información correspondiente. Se presenta la descripción y el precio actual del producto.

4.- Al terminar de introducir el producto. El cajero indica que se concluya la captura de productos

5.- Calcula y presenta el total de la venta

6.- El cajero indica el total al cliente

7.- El cliente efectúa el pago en efectivo (el efectivo ofrecido probablemente es mayor que la venta)

8.- El cajero registra la cantidad de efectivo recibido 9.- Muestra al cliente la diferencia, emite recibo

10.- El cajero deposita el efectivo recibido y extrae el cambio 11.- Registra venta concluida

12.- El cliente se marcha con los artículos comprados



Ejemplo: Ultima Sección Casos Alternativos

• Línea 2: Introducción del identificador invalido. Indicar Error.

• Línea 7: El cliente no tenia suficiente dinero. Cancelar Venta.



Otros formatos

Formato de una línea para eventos.

Nota: No existe el formato ideal. Algunos prefieren un a columna otros dos. Quitan y agregan secciones. Sin embargo esto no es importante, la clave está en escribir el curso normal de eventos y los curso alternativos en alguna forma.



Opcionalmente, puede haber una caja en un diagrama de casos de uso, alrededor de los casos de uso, etiquetado con el nombre del sistema. La caja representa el limite del sistema.

Puede ser útil cuando se modelan sistemas complejos con muchos subsistemas.

UML: Limite del Sistema


Para la captura de requisitos

Los casos de uso pueden ayudar con la captura de requisitos, proporcionando una forma estructurada de abordarlos:

Identificar los actores.

Para cada actor averiguar:

Lo que necesita del sistema , es decir, qué casos de uso hay que tienen valor para ellos.

Cualquier otra interacción que espera tener con el sistema, esto es, en qué casos de uso podría formar parte para el beneficio de otro.

UML: Utilización de los casos de uso


Casos de uso a través del desarrollo

Planificación: antes de realizar una estimación coherente y planificar el proceso para todo el proyecto, se necesita tener una lista con todos los caso de uso del sistema, junto con:

Una buena idea de lo que significa cada caso de uso.

Un entendimiento de quien quiere cada uno y cuanto.

El conocimiento de que casos de uso tienen mas riesgos.

Un plan de cuanto llevaría implementar cada caso de uso.

Un aspecto básico es que no se debería planificar la entrega del sistema en una suma de tiempo inferior a la suma de los tiempos para el desarrollo de cada caso de uso.



Casos de uso a través del desarrollo

Aspectos políticos: entregar primero los casos de uso más prioritarios, para mostrar que el sistema genera aportes.

Aspectos Técnicos: entra en conflicto con los anteriores, hay que implementar primero los casos de uso más riesgosos, para abordar los riesgos cuando sea posible.

Validación del sistema: Cada caso de uso describe un requisito del sistema por lo que un diseño correcto permite que se ejecuta cada caso de uso: es decir realizar cada caso de uso. Una técnica y obvia para validar el diseño de un sistema es tomar de uno en uno los casos de uso y comprobar que el sistema permite ejecutar dicho caso de uso.



Realice los siguientes ejercicios para practicar los conceptos aprendidos.

Ejercicios

UML: Ejercicios


Casos de Uso para la reutilización

El caso más vital es cuando se puede sacar factor común del comportamiento de dos o más casos de uso originales.

También cuando se descubre que se puede implementar parte de uno de los casos de uso utilizando un componente.

Ejemplo: Tomar prestada copia y ampliar préstamo.

Actor

Ampliar Préstamo

Tomar PrestadaCopia de libro

Comprobar paraReserva

<<include>>

<<include>>

UML: Relación entre casos de uso



Destacar que la flecha va desde el caso de uso <<usuario>> hacia el caso de uso <<usado>>, y se etiqueta con <<include>>, para representar que el caso de uso origen incluye el caso de uso destino

Actor

Ampliar Préstamo


Comprobar paraReserva

<<include>>

<<include>>




El caso de uso origen depende del caso de uso destino, pero el caso de uso destino no depende del caso de uso origen.

Cuando una instancia del caso de uso <<llega al lugar>> donde el comportamiento de otro caso de uso debe ser incluido, ejecuta todo el comportamiento descrito por el caso de uso incluido y luego continua de acuerdo a su caso de uso original.




Ventajas:

Es una manera conveniente de almacenar la decisión de que se va a utilizar un componente, o de evitar almacenar la información en más de una descripción detallada del caso de uso.

Sacar factores de partes de la descripción del caso de uso, puede hacer que las descripciones de los casos de uso sean más cortas y fáciles de comprender.

Puede ser una manera de descubrir una posible reutilización de un componente.




Desventajas:

Hay un serio riesgo de que la búsqueda de la reutilización en el modelo de caso de uso orientados a la funcionalidad, se vuelva atrás hacia un estilo de diseño de descomposición funcional de arriba hacia abajo.

La incorporación de un caso de uso <<include>> es difícil de leer por alguien que no esta acostumbrado a UML.




Resumen: Considere la utilización de <<include>> entre casos de uso:

Para mostrar cómo el sistema puede utilizar un componente que ya existe.

Para mostrar la funcionalidad común entre casos de uso.

Para documentar el hecho de que el proyecto ha desarrollado un nuevo componente reutilizable.



Separación del comportamiento variable <<extend>>

Si un caso de uso incorpora dos o más escenarios con diferencias significativas, esto es, se podría mostrar como un caso de uso principal y uno o más casos secundarios.

Cuando se realiza esto es un problema de juicio, ya que siempre se pueden mostrar casos variables en un caso de uso.

Ejemplo: Tomar prestada copia de libro.

Actor


Rechazar Préstamo<<extend>>



Separación del comportamiento variable <<extend>>

Se utiliza la flecha <<extends>> desde el caso de uso menos central al central. La flecha va desde el caso excepcional al caso normal.

La precondición debe hacer referencia al caso de uso extendido

Actor


Rechazar Préstamo<<extends>>



Generalización (herencia)

Dos actores, o dos casos de uso, pueden estar relacionados por medio de la generalización.

Ejemplo: generalización actores

PrestatarioLibro

PrestatarioRevistas



Generalización (herencia)

Cuando los casos de uso están relacionados a través de una generalización la idea es mostrar una tarea y una versión especializada de la misma.

Pagar en Efectivo

Pagar con Cheque

Pagar



Una regla básica es que si se quiere describir comportamiento extra posiblemente se requiera <<extends>>, mientras que si lo que se quiere es una etiqueta para una versión especializada de una tarea completa, probablemente se quiera generalización.



Identificar las funciones del sistema, identifique los actores y casos de uso.

Describa todos los casos de uso de alto nivel.

Dibuje un diagrama de caso de uso.

Escriba el formato esencial expandido de los casos de uso más importantes para lograr una mayor comprensión de la complejidad y las dimensiones del problema, posponga los demás para la etapa de análisis.

Posponga, la descripción de los casos de usos reales hasta la fase de diseño.

UML: Pasos para la especificación de los casos de uso


UML: ¿Por qué casos de Uso?

“Ofrecen un medio sistemático e intuitivo para capturar los requisitos funcionales, centrándose en el valor añadido para el usuario”.

Dirigen todo el proceso de desarrollo puesto que la mayoría de las actividades (planificación, análisis, diseño, validación, test, ..) se realizan a partir de los casos de uso.

Mecanismo importante para soportar “trazabilidad” entre modelos.


UML: RecomendacionesERROR COMÚN: no identificar como casos de uso las tareas que lanza el propio sistema.

“Anular reservas pasadas quince días”

No incluir casos de uso de las operaciones CRUD sobre un objeto de negocios (consultas, borrado, actualización, registros): excepto si se trata de operaciones relevantes para el sistema, como “registrar clientes” en un sistema de ventas por Internet.

Cuidado con el empleo de la relación <<include>>

NO HACER UNA DESCOMPOSICIÓN FUNCIONAL!!!


UML: RecomendacionesEscribir casos de uso independientes de la interfaz o de detalles de implementación, escribirlos a nivel esencial.

Hay que comprobar que los casos de uso incluyen toda la funcionalidad del sistema.

Los casos de uso sólo consideran los requisitos funcionales del proyecto, hay que añadir los no funcionales.


Bibliografía

Guía del Tópico:

Software Engineering 6a. ed.– Ian Sommerville – Pearson Education – 2000. (Cap. 6)Ingeniería de Software Teoría y Práctica – Shari Lawrence Pfleeger – Pearson Education – 2002.Utilización de UML en ingeniería del software con objetos y componentes – Perdita Stevens & Rob Pooley – Addison Wesley – 2002. UML y Patrones una introducción al análisis y diseño orientados a objeto y al proceso unificado – Craig Larman – Prentice Hall - 2002.

unidad 4 mad modelado analisis casos de uso

Documents