IntroducciónPor muchos años, los analistas han usado escenarios o

historias que describen maneras en que un usuario va a interactuar con el sistema.

Ivar Jacobson introdujo lo que conocemos como Diagramas de Casos-de-Uso (1994)

Se los utiliza para la obtención y modelamiento de requerimientos.

Es quizás el diagrama más importante presentado por UML, ya que describe la funcionalidad de una serie de Casos en el que se usaría el sistema a modelar, desde el punto de vista del usuario final

Casos de UsoUn Casos de Uso es una secuencia de

transacciones en un sistema cuyo resultado proporciona un valor mesurable a un actor individual del sistema.

Describe el QUÉ hace el sistema desde la perspectiva del usuario.

Conjunto de escenarios relacionados entre si por un objetivo común del usuario.

Diagramas de Casos de Uso

relación entre los actores y los casos de uso del sistema.

Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa.

Elementos de un DCUSistema

Se debe delimitar las fronteras del sistema desarrollado coma parte del modelamiento de los casos de uso

Se lo representa mediante un recuadro donde el nombre del sistema aparece arriba o encima del recuadro.

NOMBRE DEL SISTEMA

Elementos de un DCUActores

Un actor representa un rol que es desempeñado con respecto al sistema, y no así un usuario individual del sistema. Un mismo usuario puede desempeñar varios roles.

El nombre del actor describe el papel desempeñado

Tipos de Actores

Elementos de un DCURelaciones entre Actores

Cuando varios actores, aparte de su rol, desempeñan también un rol general común puede ser descrito como generalización.

Los actores “heredan” el comportamiento y lo extienden de alguna manera.

CajeroSupervisorGerente

Elementos de un DCUCasos de Uso Son eventos que se producen

entre un actor y un sistemaSiempre es iniciado por un actor.El caso de uso proporciona cierto valor al actor.El caso de uso es completo (No dividir un caso

de uso en otros más pequeños)Los escenarios de un caso de uso son

descritos textualmente utilizando un formato común (plantilla).

Un caso de uso debe estar libre de detalles relacionados a la tecnología.

EJEMPLO 1

Actor ACaso de Uso A

Actor BCaso de Uso B

Ejemplo 2

Pasajero

Empleado

Sistema de Reservaciones

RealizarReserva

ProgramarVuelos

DescribirVuelos

Ejemplo 3

UML 1.5

Elementos de un DCURelaciones entre Casos de Uso

Se representan como una línea que une a los dos casos de uso relacionados, con una flecha en forma de triángulo y con una etiqueta <<extiende>> o <<incluye>> o <<usa>> según sea el tipo de relación.

Asociación: Es una línea continua que asocia los actores con su o sus respectivos casos de uso.

InclusiónInclusión : Indica que el caso de uso que esta incluido dentro del base se ejecuta de forma obligatoria.

Caso de Uso Origen Caso de Uso Destino

<<include>>

<<include>>

Pago con tarjeta Verificar tarjeta

ExtensiónExtensión : Indica que el caso de uso que se esta representando tiene un comportamiento o un uso de carácter opcional. En otras palabras el caso de uso origen extiende el comportamiento del caso de uso de destino.

Caso de Uso Origen Caso de Uso Destino

<<extend>>

<<Extend>>

Hacer Compras

Pagar tarjeta crédito

Utilizaremos una relación tipo << uses>> cuando nos encontramos con una parte de comportamiento similar en dos casos de uso y no queremos repetir la descripción de dicho comportamiento común.

<<uses>>

Preguntas claves para la construcción de los CU

Habiendo identificado cada uno de los actores podemos preguntar:

¿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?

Como ejemplo esta el caso de una Máquina Recicladora: Sistema que controla una máquina de reciclamiento de botellas,

tarros y jabas. El sistema debe controlar y/o aceptar: Registrar el número de ítemes ingresados. Imprimir un recibo cuando el usuario lo solicita: a. Describe lo depositado b. El valor de cada item c. Total El usuario/cliente presiona el botón de comienzo Existe un operador que desea saber lo siguiente: a. Cuantos ítemes han sido retornados en el día. b. Al final de cada día el operador solicita un resumen de todo

lo depositado en el día. El operador debe además poder cambiar: a. Información asociada a ítemes. b. Dar una alarma en el caso de que: i. Item se atora. ii. No hay más papel.

Ejemplo:

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:

Como una primera aproximación identificamos a los actores que interactúan con el sistema:

Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien

puede ser realizada a petición de un operador.

Entonces, el diseño completo del Diagrama de Caso de Uso es:

<<extend>> : indicar en que punto entra en juego el caso de uso que lo extiende (punto de extensión)

EJEMPLOS DE CASOS DE USOS

Verificar Operación

Reintegro Cuenta Corriente

Cliente

Reintegro Cuenta de Crédito

<<include>>

<<include>>

Asociaciones Actor-Caso de Uso(también se pueden mostrar cardinalidades)

Generalización Actor-Actor(también pueden darse

Caso de Uso-Caso de Uso)

Cliente

Solicitante

Proveedor

Empleado

Gerente

Sistema Burger Queen

OrdenarComida

ContratarPersonal

ControlarVentas e

Inventarios

ReordenarSuministros

ProducirReportes

<<incluye>>

<<incluye>>

La forma mas popular de un caso de uso es un documento de texto.

•Título

•Actor

•Precondiciones

•Objetivo

•Flujo Principal

•Flujos Alternos

•Poscondiciones

Estructura de casos de uso

TítuloSección fundamental del caso de uso.

Permite identificarlo y comunicar parte de sus características.

Ejemplo: Factura_Aprobar

ActorEjemplo: Imaginemos un encargado de atender las llamadas telefónicas de solicitud de servicio. El encargado tiene una meta: registrar la llamada en un sistema computacional e iniciar la solicitud de servicio.

El encargado del ejemplo es un actor y tiene una meta. Un actor en un caso de uso es aquel que interactúa con el sistema para lograr una meta.

Ejemplos: Encargado de reservaciones, Gerente de Finanzas.

PrecondicionesEs el estado del sistema que debe cumplirse

antes de ejecutar un caso de uso.

Generalmente una precondición indica que se ha ejecutado algún otro caso de uso o que se tiene acceso a información que se utilizará en el caso de uso.

ObjetivoEs el valor o beneficio que el actor desea

obtener al ejecutar el caso de uso.

Durante la redacción del caso de uso es imprescindible mantener el objetivo en mente para prevenir acciones o pasos que no estén en el alcance del caso de uso.

Ejemplos: “Eliminar un registro de inventario”, “Autorizar un contrato de arrendamiento”.

Flujo PrincipalEl flujo principal es una serie de pasos que

sirve para llegar al objetivo o meta del caso de uso.

En un caso de uso el flujo principal es único.

El flujo principal define el “camino feliz” del caso de uso. Es decir, la obtención del objetivo (escenario de éxito) sin obstáculos ni interrupciones.

Flujos AlternosEn un caso de uso pueden existir uno o varios

flujos alternos.

Los flujos alternos capturan las acciones que pueden desviar el flujo principal.

Son útiles para capturar las excepciones funcionales de un sistema así como escenarios alternos de éxito.

No tienen como propósito documentar errores de operación de un sistema.

PoscondicionesLas poscondiciones definen el estado del sistema después de ejecutar el flujo principal de un caso de uso.

Ejemplo. “El sistema autoriza una orden de compra”.

DIAGRAMAS DE ACTIVIDADES Los diagramas de actividades muestran las

transiciones de estado en que se encuentra el sistema en una determinada transacción. Esta representa un flujo de eventos en un caso de uso.

ELEMENTOS Y SU REPRESENTACION

Actividad:

Transición:

Final:

Inicio:

Decisión:

Actividad

REPRESENTACIÓN Y PARTES DE UN DIAGRAMA DE ACTIVIDADES

El diagrama de actividades resalta, precisamente, las actividades.

DECISIONES

RUTAS CONCURRENTES INDICACIONES

Diagrama de Estado

Cambios necesarios de los objetos que lo conforman

Conforme un sistema interactúa con los usuarios y (posiblemente) con otros sistemas, los objetos que lo conforman pasan por cambios necesarios para ajustar las interacciones. Por esa razón se necesita contar con un mecanismo para cambios en el modelo. Un cambio en un sistema se da debido a que los objetos que componen dicho sistema modificaron su estado como respuesta a los sucesos y al tiempo.

Diagrama de estado

Estados por los que pasa una lavadora paraentregar la ropa limpia.

DIAGRAMA DE CLASES

Los diagramas de clases representan un conjunto de elementos del modelo que son estáticos, como las clases y los tipos, sus contenidos y las relaciones que se establecen entre ellos.

Sirve para visualizar las relaciones entre las clases que involucran el sistema.

Elementos

Claseatributos,métodos

Relaciones

Herencia, Asociación EnsambladoDependencia

CLASE

ATRIBUTOS

ACCIONES

ATRIBUTOS Y ACCIONES DE UNA LAVADORA

Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

CLASE

ATRIBUTOS

Representa alguna propiedad de la clase, que se encuentra en todas las instancias de la clase. Definen la estructura de una clase y de sus correspondientes objetos.

Nombre_de_la_clase

lista_de_atributos

Persona

nombre

edad

Los atributos básicos son atributos independientes dentro del objeto. En contraste, los atributos derivados son atributos que dependen de otros atributos. Los atributos derivados dependen de otros atributos del objeto, los cuales pueden ser básicos o derivados.

ATRIBUTOS DERIVADOS

Notación para atributos derivados.

Ejemplo

TIPOS DE ATRIBUTOS

Public: Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados

Private: Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar)

Protected: Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven

Los valores de los atributos de una clase pueden restringirse.

RESTRICCIONES DE LOS ATRIBUTOS

OPERACIONES(METODOS)

Tipos de Método

Las operaciones son funciones o transformaciones que se aplican a todos los objetos de una clase particular. La operación puede ser una acción ejecutada por el objeto o sobre el objeto.

Uno-uno

Uno-muchos

Muchos-muchos

Muchos-uno

RELACIONES

ENTRE

CLASES Ensamblados

Generalización

Asociación

Clasificación

Cardinalidad de relaciones

Indica que una subclase hereda los métodos y atributos especificados por una Superclase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Superclase.

GENERALIZACION(HERENCIA)

permite asociar objetos que colaboran entre si.

Ejemplo: Los objetos Juan Pérez y UNLaR están relacionadas por la liga estudia-en que describe que "Juan Pérez estudia en la UNLaR".

ASOCIACION

El grado de una asociación se determina por el número de clases conectadas por la misma asociación. Las asociaciones pueden ser binarias, ternarias, o de mayor grado.

Notación para diagrama de clases describiendo una asociación ternaria.

GRADO DE ASOCIACION

ASOCIACIONES REFLEXIVASLas asociaciones pueden ser reflexivas, relacionando distintos objetos de una misma clase.Ejemplo: Para una clase persona puede existir una asociación pariente que describe que dos objetos de tipo persona, como Juan Pérez y Laura Pérez son parientes.

ATRIBUTOS DE LIGA (O ASOCIACIÓN)Al igual que un atributo de clase es propiedad de la clase, un atributo de asociación (o atributo de liga) es propiedad de una asociación. La notación es similar a la usada para los atributos de clases, excepto que se añade a la asociación, y no se incorpora un nombre de clase.

Asociación como clase

ENSAMBLADOS: AGREGACIÓN Y COMPOSICIÓN

Son formas especiales de asociación entre un todo y sus partes, en donde el ensamblado está compuesto por sus componentes.

Composición (el Objeto base se construye a partir del objeto incluido).

Agregación (el objeto base utiliza al incluido para su funcionamiento).

COMPOSICION AGREGACION

Diagrama de objetos Partiendo del hecho

que un objeto es una instancia de clase, tal como se define en la conceptualización básica de la programación orientada a objetos, en UML la representación de un diagrama de objetos se hace de tal forma que teniendo ya una clase, el símbolo del objeto es un rectángulo, pero con el nombre subrayado.

El nombre de la instancia específica se encuentra a la izquierda de los dos puntos (:), y el nombre de la clase a la derecha. Por ejemplo, si ya se tuviera una clase llamada “BANCO”, una instancia de esa clase o un objeto instanciado a partir de esa clase se representaría de la siguiente forma:

Diagrama de objetos

BancoSuperior:BANCO

DIAGRAMA DE SECUENCIA

Este tipo de diagramas muestra una interacción ordenada según la secuencia de eventos vista a la luz de una línea de tiempo. En particular, se muestran los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo.

ELEMENTOS Y SU REPRESENTACIÓN. Intercambio de mensaje entre Objetos y otros

elementos:

Mensajesó peticiones

Líneas de Vida

Tiempo de EjecuciónDel Caso de Uso

Objetos

NOMBRE NOMBRE

Muestra cada unode los eventos que realiza la lavadora en una línea de vida

EJEMPLO 1

DIAGRAMA DE COLABORACIONES DIAGRAMA DE COMUNICACIONES

Este diagrama de nivel dinámico, representa el conjunto de objetos y la interacción que existe entre ellos.

ELEMENTOS Y SU REPRESENTACIONRecepcionista

GUI

2: SolicitarHabitDisponibles()5: MuestraHabDisponibles()

Objetos

Mensajes

()

()

EJEMPLO 1

EJEMPLO 2