UML: CASOS DE USO Y UML: CASOS DE USO Y UML: CASOS DE USO Y UML: CASOS DE USO Y DIAGRAMA DE CASOS DE USODIAGRAMA DE CASOS DE USODIAGRAMA DE CASOS DE USODIAGRAMA DE CASOS DE USO

FUNDAMENTOS DE INGENIERÍA DE

SOFTWARE

DIAGRAMA DE CASOS DE USODIAGRAMA DE CASOS DE USODIAGRAMA DE CASOS DE USODIAGRAMA DE CASOS DE USO

Docente:

Ing. Armando Cabrera

Integrantes:

Marilyn Jaramillo

Katty Landacay

UMLUnified Modeling Language

•Lenguaje Estándar para:– Visualizar– Visualizar

– Especificar

– Construir

– Documentar los planos del software

Indican como crear y leer modelos bien formados pero no nos dicen qué modelos se deben crear ni cuándo se los deberían crear

Ir a Casos de uso

UML es un lenguaje para visualizar

• La distancia entre pensar en una implementación y transformarla en código es casi cero.

• En algunos casos: Lo que piensas lo codificas.

• UML es algo más que un simple montón de símbolos gráficos.

• En algunos casos: Lo que piensas lo codificas.

• Algunas cosas se modelan mejor textualmente; otras se modelas mejor de forma gráfica

UML es un lenguaje para especificar• Significa construir modelos precisos, no ambiguos y completos

• UML cubre todas las decisiones de análisis, diseño e implementación

UML es un lenguaje para construir

• Pero sus modelos pueden conectarse a una gran variedad de lenguajes de programación

• No es un lenguaje de programación

UML es un lenguaje para construir

UML es un lenguaje para documentar

• UML cubre la documentación de la arquitectura de un sistema y todos sus detalles

• Proporciona un lenguaje:• Proporciona un lenguaje:

� Expresar requisitos y pruebas

� Modelar actividades de planificación de proyectos y gestión de versiones

CASOS DE USO

�Qué es un caso de uso?�Para que sirven los casos de uso?�Cómo se representan?�Cómo se debe crear un caso de uso?�Flujo de eventos�Flujo de eventos�Relaciones�Diagramas de caso de uso

Use Case 2 Specification

Actor 2

Use case 1

Model

Use case 2

Use case 3

QUÉ ES UN CASO DE USO?

� Describen una interacción típica entre un usuario (actores) y un sistema decómputo.

� Es una técnica para capturar información de cómo un sistema o negociotrabaja actualmente, o de cómo se desea que trabajetrabaja actualmente, o de cómo se desea que trabaje

� Produce algo de valor para algún actor como el cálculo de algúnresultado

� DescribeDescribeDescribeDescribe quéquéquéqué hacehacehacehace unununun sistemasistemasistemasistema peroperoperopero nononono especificaespecificaespecificaespecifica cómocómocómocómo lolololo hacehacehacehace

� El caso de uso capta alguna función visible para el usuario.� El caso de uso puede ser pequeño o grande.� El caso de uso logra un objetivo discreto para el usuario.

� Un caso de uso debe ser simple, claro y conciso

PARA QUE SIRVEN LOS CASOS DE USO?

� Para capturar el comportamiento deseado del sistema sin tener que especificar como se implementa ese comportamiento

� Como medio de comprensión del sistema para desarrolladores, � Como medio de comprensión del sistema para desarrolladores, usuarios finales y expertos del dominio

� Ayudan a validar la arquitectura y a verificar el sistema en el transcurso del desarrollo de este

Un caso de uso se representa en UML como un óvalo:

CÓMO SE REPRESENTAN?

Nombre del Caso de Uso

En UML, un actor se representa como monigote

Actor

ACTORES� Representa un conjunto de roles que los usuarios de los casos de uso juegan alinteractuar con éstos

� Representa un rol que es jugado por una persona, un dispositivo hardware uotro sistema que interactúe con nuestro sistema

� Se puede definir categorías generales de actores (como cliente) y� Se puede definir categorías generales de actores (como cliente) yespecializarlos (como ClienteComercial) a través de relaciones de generalización

Cliente

ClienteComercial

actor

actor

generalización

� Un actor y un caso de uso se pueden comunicar a través de una asociaciónen donde cada uno de ellos pueden enviar y recibir mensaje.

FLUJO DE EVENTOS

� CómoCómoCómoCómo yyyy cuándocuándocuándocuándo empiezaempiezaempiezaempieza yyyy acabaacabaacabaacaba elelelel casocasocasocaso dededede usousousouso

� Cuándo interactúan con los actores y que objetos se intercambian

� Conviene separa el flujo principal de uno alternativo

Ejemplo:

VALIDACIÓN DE USUARIO

FLUJOFLUJOFLUJOFLUJO DEDEDEDE EVENTOEVENTOEVENTOEVENTO PRINCIPALPRINCIPALPRINCIPALPRINCIPAL::::

el caso de uso comienza cuando se pide al cliente un número de identificaciónpersonal (cédula), el cliente introduce la cédula, luego acepta con enter, elsistema lo comprueba para su validación, si la cédula es válida el sistema aceptala entrada y acaba el caso de uso.

FLUJOFLUJOFLUJOFLUJO DEDEDEDE EVENTOEVENTOEVENTOEVENTO EXCEPCIONALEXCEPCIONALEXCEPCIONALEXCEPCIONAL::::

- El cliente puede cancelar su transacción en cualquier momento con el botóncancelar, reiniciando el caso de uso, no se efectúa ningún cambio a la cuenta delcliente ....- El cliente puede borrar la cédula en cualquier momento antes de introducirloy volver a teclear una nueva cédula- El cliente introduce un cédula inválida el caso de uso vuelve a empezar, si se lorealiza tres veces se cancela la transacción.

Cómo identificar los casos de uso?

Cómo se debe crear un caso de uso?

� Tras localizar los actores, procede el describirlos� especificar describiendo un flujo de eventos � Los actores sólo pueden conectar a los casos de uso a través de

asociacionesGeneralmente hay pocos actores asociados a cada Caso de Uso� Generalmente hay pocos actores asociados a cada Caso de Uso

� Preguntas clave:– ¿cuáles son las tareas del actor?– ¿qué información crea, guarda, modifica, destruye o lee el actor?– ¿debe el actor notificar al sistema los cambios externos?– ¿debe el sistema informar al actor de los cambios internos?

� La descripción del Caso de Uso comprende:– el inicio:el inicio:el inicio:el inicio: cuándo y qué actor lo produce?– el fin:el fin:el fin:el fin: cuándo se produce y qué valor devuelve?– la interacciónla interacciónla interacciónla interacción actor-caso de uso: qué mensajes

intercambian ambos?

� objetivo del caso de uso:objetivo del caso de uso:objetivo del caso de uso:objetivo del caso de uso: ¿qué intenta el caso de uso?� cronología y origen de las informaciones� repeticiones de comportamiento: ¿qué operaciones son iteradas?

� situaciones opcionales:situaciones opcionales:situaciones opcionales:situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el caso de uso?

Puntos claves del ejemplo:

• Las precondicionesprecondicionesprecondicionesprecondiciones son los hechos que se han de cumplir para que el flujo de evento se pueda llevar a cabo.

• Flujo de eventos NormalFlujo de eventos NormalFlujo de eventos NormalFlujo de eventos Normal, que corresponde a la ejecución normal y • Flujo de eventos NormalFlujo de eventos NormalFlujo de eventos NormalFlujo de eventos Normal, que corresponde a la ejecución normal y exitosa del caso de uso

• Los flujos alternativos flujos alternativos flujos alternativos flujos alternativos son los que nos permiten indicar qué es lo que hace el sistema en los casos menos frecuentes e inesperados.

• las poscondiciones poscondiciones poscondiciones poscondiciones son los hechos que se ha de cumplir si el flujo de eventos normal se ha ejecutado correctamente.

Ejemplo: escribir un mensaje en un foro

RELACIONESPara extraer el comportamiento de los casos de uso en los que se incluye y poniendo ese comportamiento en otros casos de uso que lo extiende

Tipos:- GENERALIZACIÓN- EXTENSIÓN- EXTENSIÓN- INCLUSIÓN

GENERALIZACIÓN

� El caso hijo hereda el comportamiento y significado de caso de uso padre

� El hijo puede añadir o redefinir el comportamiento del padre� El Caso de Uso fuente hereda la especificación del Caso de Uso

destinodestino

Caso de uso origen

Caso de uso destino

INCLUSIÓN

– Un caso base de uso base incorpora expolisitamenteel comportamiento de otro caso de uso en el lugarel comportamiento de otro caso de uso en el lugarespecificado en el caso base.

– Se usa para evitar describir el mismo flujo deeventos repetidas veces, poniendo comportamientocomún en un caso de uso aparte

– Se representa como una dependencia estereotipadacon <<include>>

Caso de uso origen

Caso de uso destino

<<include>>REPRESENTACIÓN:

EJEMPLO:

Ingresando pedido

Buscando datos deproducto

Obtener reporte De Ventas por

producto

<<include>><<include>>

Empleado deventas

Gerente

EXTENSIÓN• Significa que un caso de uso base incorpora implícitamente el

comportamiento de otro caso de uso en el lugar especificadoindirectamente por el caso de uso que extiende al base

• Se usa esta relación cuando se tiene un caso de uso que es similar aotro, pero que hace un poco más.otro, pero que hace un poco más.

Caso de uso origen

Caso de uso destino

<<extends>>

Ejemplo:

RealizarLlamada telefónica

Realizar llamadaCon conferencia

<<extend>>

relación de extensiónRed

Recibir llamadatelefónica

Recibir llamadaadicional

Usar agenda

<<extend>>

relación de extensión

frontera del sistema

Casos de uso

Redtelefónica

Usuario

Actores

Teléfono móvil

� Ejemplo de todas las relaciones :

Giro por Internet<<extends>>

Identificación

Cliente

Giro<<includes>>

• Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso, actores y sus relaciones.

DIAGRAMAS DE CASO DE USO

En UML, cada caso de uso debe tener al menos un actor. Esta forma de ver el sistema nos ayuda a concebirlo como un todo.

conjunto de casos de uso, actores y sus relaciones.• Son importantes para modelar el comportamiento de un sistema.

• Normalmente los casos de uso contienen:

– Casos de Uso– Actores– Relaciones de dependencia, generalización y asociación.

• Cubren principalmente el comportamiento del sistema.

• Es un tipo especial de diagrama, por su contenido particular.

• Se emplean para modelar la vista de casos de uso estática.(comportamiento, servicios externos).

• Para modelar el contenido de un sistema• Para modelar el contenido de un sistema

• Dibujar una línea alrededor de todo el sistema, los actores quedarán fuera del sistema e interactúan con el, se especificara los actores y el significado de los roles.

• Para modelar los requisitos de un sistema

• Especificar que debería hacer el sistema, independientemente de cómo se haga, se especificará el comportamiento deseado del sistema.

• Permite ver el sistema entero como una caja negra.

Técnicas comunes del modelado

• Elementos dentro y fuera, son responsables del comportamiento que esperan los elementos externos..

• Los elementos externos que interactúan con el sistema constituyen su contexto, es decir el entorno en que reside el sistema.contexto, es decir el entorno en que reside el sistema.

• Modelar el contexto de un sistema– Identificar actores en torno del sistema.– Grupos que necesitan ayuda del sistema, – Grupos necesarios para ejecutar las funciones del sistema.– Grupos que interactúan con el hardware o software.– Grupos que realizan funciones secundarias de administración y

mantenimiento.• Organizar los actores similares en jerarquía de generalización/especificación• Proporcionar un estereotipo para cada actor.• Introducir los actores en un diagrama de CU y especificar las vías de

comunicación .

Antes Después

Comercio

Cliente

RealizarTransacciónCon tarjeta

Procesar facturaDel cliente

Cliente

EntidadFinanciera

Clienteindividual

Clientecorporativo

Ajustar transacciones

Gestionar cuentaDel cliente

Conclusiones:•Los Casos de Uso no son parte del diseño (cómo), sino parte del análisis (qué).

•Los Casos de Uso son qué hace el sistema desde el punto de vista del usuario.Es decir, describen un uso del sistema y cómo este interactúa con el usuario.Es decir, describen un uso del sistema y cómo este interactúa con el usuario.

• Los diagramas de casos de uso muestran las relaciones entre los casos de usode un sistema y sus actores.

•En una relación << extends>>, un actor que lleve a cabo el caso de uso basepuede realizar o no sus extensiones. Mientras, en una relación <<include>> elactor que realiza el caso de uso base también realiza el caso de uso incluido.

Bibliografía:1. http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php2. http://www-gris.det.uvigo.es/~avilas/UML/node25.html3. Libro de UML: EL LENGUAJE UNIFICADO DE MODELADO, Booch,

Jacobson, Rumdaugh, pag 190- 223Jacobson, Rumdaugh, pag 190- 223