Diagramas UML

Ingeniería de Software Diagramas - UML

Facultad de IngenieríaEAP. Ingeniería de Sistemas

Ing. CIP. Eddy Iván Quispe Soto

EnfoqueTendencia Orientada a

Objetos para elDesarrollo de Software

Resumen Situación ActualNotación – Herramientas - Proceso

Análisis Diseño

Diagramas de Casos de Uso

Diagramas de Actividad

Diagramas de Secuencia

Diagramas de Colaboración

Diseño de Interfaces

DFDs

Diagrama de Clases

Diagrama de Estados

Diagramas de Actividad

DEs

ModeloRelacional !!

Implementación

Entornos de Programación

Visual

Bases de Datos (Objeto-)

Relacionales

ModeloRelacional

E-REnfoque

Estructurado

Enfoque OO

SUPRAESTRUCTURA UML

Enfoques de UML 2.0 - 2.1

ESTRUCTURA

COMPORTAMIENTO

INTERACCION

1. D. CLASES

2. D. OBJETOS

3. D. COMPONENTES

4. D. DESPLIEGUE

5. D. PAQUETES

6. D. ESTRUCTURA COMPUESTA

7. D. CASOS DE USO

8. D. ACTIVIDADES

9. D. ESTADOS

10 D. SECUENCIA

11 D. COMUNICACIÓN (COLABORACION)

12. D. VISION GENERAL( OverView)

13 D. TIEMPO

Diagrama Descripción Prioridad Diagrama de Clases

Muestra una colección de elementos de modelado declarativo (estáticos), tales como clases, tipos y sus contenidos y relaciones.

Alta

Diagrama de Componentes

Representa los componentes que componen una aplicación, sistema o empresa. Los componentes, sus relaciones, interacciones y sus interfaces públicas.

Media

Diagrama de Estructura de Composición

Representa la estructura interna de un clasificador (tal como una clase, un componente o un caso de uso), incluyendo los puntos de interacción de clasificador con otras partes del sistema.

Baja

Diagrama de Despliegue Físico

Muestra cómo y dónde se desplegará el sistema. Las máquinas físicas y los procesadores se representan como nodos y la construcción interna puede ser representada por nodos o artefactos embebidos. Como los artefactos se ubican en los nodos para modelar el despliegue del sistema, la ubicación es guiada por el uso de las especificaciones de despliegue.

Media

Diagrama de Objetos

Presenta los objetos y sus relaciones en un punto del tiempo. Se puede considerar como un caso especial de un diagrama de clases o un diagrama de comunicaciones.

Baja

Diagrama de Paquetes

Presenta cómo se organizan los elementos de modelado en paquetes y las dependencias entre ellos, incluyendo importaciones y extensiones de paquetes.

Baja

Diagrama de Actividades

Representa los procesos de negocios de alto nivel, incluidos el flujo de datos. También puede utilizarse para modelar lógica compleja y/o paralela dentro de un sistema.

Alta

Diagrama de Comunicaciones (Diagrama de colaboraciones)

Enfoca la interacción entre líneas de vida, donde es central la arquitectura de la estructura interna y cómo ella se corresponde con el pasaje de mensajes. La secuencia de los mensajes se da a través de un esquema de numerado de la secuencia.

Baja

Diagrama de Revisión de la Interacción

Enfocan la revisión del flujo de control, donde los nodos son Interacciones u Ocurrencias de Interacciones. Las Líneas de Vida los Mensajes no aparecen en este nivel de revisión

Baja

Diagrama de Secuencias

Representa una interacción, poniendo el foco en la secuencia de los mensajes que se intercambian, junto con sus correspondientes ocurrencias de eventos en las Líneas de Vida.

Alta

Diagrama de Máquinas de Estado

Ilustra cómo un elemento, muchas veces una clase, se puede mover entre estados que clasifican su comportamiento, de acuerdo con disparadores de transiciones, guardias de restricciones y otros aspectos de los diagramas de Máquinas de Estados, que representan y explican el movimiento y el comportamiento.

Media

Diagrama de Tiempos

Muestra los cambios en el estado o la condición de una línea de vida (representando una Instancia de un Clasificador o un Rol de un clasificador) a lo largo del tiempo lineal. Muestra el cambio de estado de un objeto a lo largo del tiempo, en respuesta a los eventos. Los eventos que se reciben se anotan, a medida que muestran cuándo se desea mostrar el evento que causa el cambio en la condición o en el estado.

Baja

Diagrama de Casos de Uso

Un diagrama que muestra las relaciones entre los actores y el sujeto (sistema), y los casos de uso.

Media

Diagramas de Casos de Uso

Actor ACaso de Uso A

Actor BCaso de Uso B

Denominados también: Diagrama de Caso Típico

Elementos involucrados

Actores:

Casos de Uso:

Comunicación:







Casos de uso

• Concebidos por I. Jacobson - Objectory/OOSE (Jacobson, 92)

• Presentes en casi cualquier nuevo método de desarrollo de software.

• Incluidos en UML y Métrica 3 entre otros metodos que involucren la captura de requerimientos.

... Casos de Uso• Técnica de recolección y especificación

de requisitos.• Fáciles de comprender/validar por los

usuarios.• Guían todo el ¿proceso? de desarrollo.• Ayudan a la planificación/desarrollo

incremental.• Tradicionalmente ligados a la OO

– pero no obligatorio• Ayudan a determinar la interfaz de usuario.

Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario

Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno

Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implementación

Comparación con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado

… Casos de Uso

Los Casos de Uso cubren la carencia existente en métodos previos (OMT, Booch) en cuanto a la determinación de requisitos.

Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo.

El usuario debería poder entenderlos para realizar su validación.

… Casos de Uso

Ejemplo:

… Casos de Uso

Busqueda de producto

Informes

Genera ProformaPromotora

Ejemplo:

… Casos de Uso

Ingreso datos Cliente Vizualiza Comprobante

Ingresa Cantidad

Generar Total a Pagar

Busqueda de Productos

(from Casos de uso)

Informes

Genera Proforma

<<include>> <<extend>><<extend>>

<<extend>> Promotora

Igreso codigo

(from Casos de uso)<<extend>>

Ingresar Descripcion

(from Casos de uso)<<extend>>

Filtrar datos

(from Casos de uso)

<<include>>

Ejemplo:

… Casos de Uso

Ingreso datos Cliente

Vizualiza Comprobante

Ingresa Cantidad

Generar Total a Pagar

InformesGenera Proforma

<<include>>

<<extend>> <<extend>>

<<extend>>

Ejemplo:

… Casos de Uso

Informes

(f rom SubsistemaVenta)

Busqueda de Productos

Igreso codigo Filtrar datos

Ingresar Descripcion

<<extend>><<include>>

<<extend>>

Roles que presentan los usuarios cuando interactúan con el sistema.

La misma persona física puede interpretar varios papeles como actores distintos (generalización)

El nombre del actor describe el papel desempeñado

Casos de Uso : Actores

Cobranza

Principales: roles que usan el sistema.

Secundarios: roles que mantienen o administran el sistema.

Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la aplicación y deben ser utilizados.

Otros sistemas: sistemas con los que el sistema interactúa.

… Casos de Uso: Actores


Características• Inician la ejecución de los casos de

uso.• No tienen que ser personas

necesariamente.• Un mismo rol puede ser jugado por

más de un usuario.• Un usuario puede jugar más de un rol.


• Generalización de actores, se pueden generalizar roles de actores mediante una relacion de generalización, Ejm.

Administración

Contador Administrador

Como localizarlos: Los Casos de Uso se determinan observando y

precisando, actor por actor, las secuencias de interacción, los escenarios, desde el punto de vista del usuario.

Un escenario es una instancia de un caso de uso.

Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso.

... Casos de Uso

UML define cuatro tipos de relación en los Diagramas de Casos de Uso:

–Comunicación

ActorCaso de Uso

Casos de Uso: Relaciones

– Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino

<<include>> reemplazó al denominado <<uses>>

Caso de Uso Origen Caso de Uso Destino

<<include>>


Verificar Operación

Reintegro Cuenta Corriente

Cliente

Reintegro Cuenta de Crédito

<<include>>

<<include>>

Ejemplo <<include>>:


–Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino


Caso de uso Origen Caso de Uso Destino

<<extend>>

Solicitar Nueva Tarjeta

ClienteSolicitar Préstamo

<<extend>>

[Tarjeta Caducada]

Ejemplo <<extend>>:


Ejemplo <<include>> y <<extend>>:

Identificación

Transferencia en Internet

ClienteTransferencia

<<include>>

<<extend>>


Ejemplo <<include>> y <<extend>>:

Place OrderSalesperson

*1 *1

Supply Customer Data

<<include>>

Order Product

<<include>>

Arrange Payment

<<include>>

Request Catalog

<<extend>>

the salesperson asks for the catalog


– Herencia : el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía, aunque este no sea muy aplicable

Caso de Uso Hijo Caso de Uso Padre


Casos de Uso

En todas las etapas del Desarrollo del Software

Requerimientos Análisis Diseño Construcción Pruebas

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

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?

Casos de uso: Construcción

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

intercambian ambos?– objetivo del caso de uso: ¿qué lleva a cabo o

intenta?– cronología y origen de las interacciones– repeticiones de comportamiento: ¿qué

operaciones son iteradas?– situaciones opcionales: ¿qué ejecuciones

alternativas se presentan en el caso de uso?


Cuando un modelo de casos de uso se completa entonces dicho modelo es presentado y discutido con usuarios y clientes

Los usuarios deben validar que el modelo encaja perfectamente en sus necesidades y que les ofrece la funcionalidad deseada


Los casos de uso permiten realizar dos tipos de test: verificación y validación

Verificar significa confirmar que el sistema se desarrolla correctamente

Validar asegura que el sistema bajo desarrollo es el que el usuario realmente quiere

Casos de uso: Test

Conclusión

¿Qué se considera un actor?– podemos preguntarnos

¿Porqué se construye el sistema?

– Los actores “ganan valor” con la ejecución del caso de uso (actor primario del caso de uso),

– o pueden sólo “participar” en él (actores secundarios del caso de uso)

Conclusión

¿Casos de Uso o funciones?• Capturan una función visible para el

usuario.• Consiguen un objetivo para el usuario del

sistema.• Caso de uso : Breve descripción en

lenguaje natural

Comentarios En métodos OO que carecen de una técnica de

captura de requisitos se comienza inmediatamente con la construcción del modelo de análisis/diseño

Los Casos de Uso son una idea maravillosa que ha sido generalmente complicada. El verdadero truco para los Casos de Uso es mantenerlos simples. Rober C. Martin

Comentarios Los requisitos NO funcionales también son

importantes. Desempeño, cumplimiento de estándares o leyes, atributos de calidad (confiabilidad, disponibilidad, seguridad, mantenibilidad, portabilidad), etc.


Barra de sincronización que indica que las actividades se encuentran comprendidas y se estarán dando al mismo tiempo.

Diagrama de Actividades Los diagramas de actividad proveen una vía para

modelar el flujo de trabajo (workflow) de un escenario de negocio, la vía para modelar una operación de la clase o para modelar el flujo de funcionalidad en un Sistema.

Diagrama que captura acciones, es decir flujos de trabajo y actividades a llevarse a cabo. Este diagrama permite enfocar:

Las actividades de un caso de uso a implementar La implementación de operaciones de una clase Las actividades de un objeto. Las actividades de un caso de uso de negocio


• Perspectivas del Diagrama de Actividades:–Diagrama Conceptual.- Una actividad es

cierta tarea que debe llevarse a cabo, ya sea por un ser humano o por una computadora.

–Diagrama de Especificación o de Implementación.- Una actividad es un método (operación) de una clase.

• El símbolo principal es la caja “Actividad”• Los enlaces entre las actividades son los

“Disparadores” o “Transiciones”• Los diagramas de actividades tienen uno o

más puntos finales definidos. • El punto final de una diagrama de

actividad es el punto donde todas las actividades disparadas han sido ejecutadas y no existen mas actividades para realizar.


Punto Inicial

Disparador / Transición Actividad


• Las guardias determinan cual disparador es usado.

• En un simple punto en el tiempo, solo un disparador puede ocurrir.

Guardias

Diagrama de Actividades Guardias

Actividad de Decisión

Guardias

Actividad de Decisión

Diagrama de Actividades vs Diagrama de Flujos

• Los diagramas de actividades permiten seleccionar el orden en que se harán las cosas. Esto es, simplemente me dice las reglas esenciales de secuencia que tengo que seguir.

• Los diagramas de flujos se limitan normalmente a procesos secuenciales.

Actividades Concurrentes

• La diferencia entre los diagramas de flujos y los diagramas de actividades es que en un diagrama de actividad el comportamiento paralelo puede ser expresado.

• Esto es importante para el modelamiento de negocios, donde los procesos secuenciales innecesarios pueden ser diseñados como ejecución en paralelo.

Barras de Sincronización

Las barras de sincronización inician secciones concurrentes en un diagrama de actividades.

Barra de Sincronización

Actvidades Concurrentes

Barras de SincronizaciónLas barras de sincronización sincronizan actividades concurrentes.



Disparadores Múltiples

AND OR

53

Punto Final

ClasePréstamo de Material

Revisa Material

Lector [ no hay material ]

Busca Material

EntregaCarnet/Doc.

LlenaFicha

Fin

[ hay material ]

Proceso Préstamo

Solicitar pasaje

Seleccionar vuelo

Pagar pasaje

Verificar existencia vuelo

Informar alternativas y precios

Solicitar pago

Reservar plazas

Emitir billete

Dar detalles vuelo

Confirmar plaza reservada

AirlineVendedorPasajero

Buscar Bebida [ no hay café ]

Poner café en filtro

Añadir agua al depósito

Coger taza

Poner filtro en máquina

Encender máquina

Café en preparación

/ cafetera.On

Servir café Beber

Coger zumo

[ hay café ]

indicador de fin

[ hay zumo ]

[ no zumo ]


Representa la relación entre una actividad y el objeto que esta crea como output o utiliza como imput

Elabora orden : Orden


Elabora orden : Orden

No necesita una transición si su diagrama tiene dos actividades conectadas a través de un objeto y dos flujos de objetos correspondientes.

Estado

Diagramas de Estado o Maquinas de Estado

Diagrama de Estados

• Captura el ciclo de vida de los objetos, subsistemas y sistemas.

• Define los estados que un objeto puede tener y cómo los eventos afectan esos estados.

Diagrama de Estados de una Orden de Pedido

Diagrama de Estados

Diagrama de Estados

con préstamos

sin préstamos

alta baja

prestar devolver[ número_préstamos = 1 ]

prestar

devolver[ número_préstamos > 1 ]

número_préstamos = 0

número_préstamos > 0

Socio

número : intnombre : char[50]número_prestamos : int = 0

alta()baja()prestar(código_libro : int, fecha : date)devolver(código_libro : int, fecha : date)

¿Para qué sirven? DE El Diagrama de Estados modela el

comportamiento de una parte del sistema a través del tiempo

Son buenos para describir el comportamiento de un objeto a través de varios casos de uso

El comportamiento es modelado en términos del estado en el cual se encuentra el objeto, qué acciones se ejecutan en cada estado y cuál es el estado al que transita después de un determinado evento

Los Diagramas de Estados representan autómatas de estados finitos, desde el punto de vista de los estados y las transiciones

Son útiles sólo para los objetos con un comportamiento significativo

El formalismo utilizado proviene de los Statecharts (Harel)

Diagrama de Estados

Cada objeto está en un estado en cierto instante

El estado está caracterizado parcialmente por los valores de algunos de los atributos del objeto

El estado en el que se encuentra un objeto determina su comportamiento

Cada objeto sigue el comportamiento descrito en el D. de Estados asociado a su clase

Los D. de Estados y los escenarios son complementarios

Diagrama de Estados

Los D. de Estados son autómatas jerárquicos que permiten expresar concurrencia, sincronización y jerarquías de objetos

Los D. de Estados son grafos dirigidos Los D. De Estados de UML son

deterministas Los estados inicial y final están

diferenciados del resto La transición entre estados es instantánea y

se debe a la ocurrencia de un evento

Diagrama de Estados

Estados y Transiciones

A B

Evento [condición] / Acción

Tanto el evento como la acción se consideran instantáneos

Diagrama de Estados

Ejemplo de un Diagrama de Estados para la clase persona:

en el paro en activo

jubilado

contratar

perder empleo

jubilarsejubilarse

Diagrama de Estados

Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transición:

A

B

Evento [condición] / OtroObjeto.Operación

Acciones

Se puede especificar el ejecutar una acción como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento:

estado A

entry: acción por entrarexit: acción por salirdo: acción mientras en estado

… Acciones

on evento: acción

Generalización de Estados

Podemos reducir la complejidad de estos diagramas usando la generalización de estados

Distinguimos así entre superestado y subestados

Un estado puede contener varios subestados disjuntos

Los subestados heredan las variables de estado y las transiciones externas


Ejemplo:

A B

C

e1

e2

e2

Quedaría como:

C

a bA Be1

e2


Las transiciones de entrada deben ir hacia subestados específicos:

C

a bA B

e1

e2

e0

… Generalización de Estados

Ingeniería de Software Diagramas - UML

Facultad de IngenieríaEAP. Ingeniería de Sistemas

Ing. CIP. Eddy Iván Quispe Soto

Diagramas UML

Documents

Transcript of Diagramas UML