diagramas uml
Post on 05-Jul-2015
841 Views
Preview:
TRANSCRIPT
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:
Actor ACaso de Uso A
Actor BCaso de Uso B
Actor ACaso de Uso A
Actor BCaso de Uso B
Actor ACaso de Uso A
Actor BCaso de Uso B
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
… 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.
… Casos de Uso: Actores
• 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>>
Casos de Uso: Relaciones
Verificar Operación
Reintegro Cuenta Corriente
Cliente
Reintegro Cuenta de Crédito
<<include>>
<<include>>
Ejemplo <<include>>:
Casos de Uso: Relaciones
–Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino
Casos de Uso: Relaciones
Caso de uso Origen Caso de Uso Destino
<<extend>>
Solicitar Nueva Tarjeta
ClienteSolicitar Préstamo
<<extend>>
[Tarjeta Caducada]
Ejemplo <<extend>>:
Casos de Uso: Relaciones
Ejemplo <<include>> y <<extend>>:
Identificación
Transferencia en Internet
ClienteTransferencia
<<include>>
<<extend>>
Casos de Uso: Relaciones
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
Casos de Uso: Relaciones
– 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: Relaciones
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?
Casos de uso: Construcción
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
Casos de uso: Construcción
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.
Diagrama de Actividades
Diagrama de Actividades
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
Diagrama de Actividades
• 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.
Diagrama de Actividades
Punto Inicial
Disparador / Transición Actividad
Diagrama de Actividades
• 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.
Barra de Sincronización
Barra de Sincronización
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 ]
Diagrama de Actividades
Representa la relación entre una actividad y el objeto que esta crea como output o utiliza como imput
Elabora orden : Orden
Diagrama de Actividades
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
Generalización de Estados
Ejemplo:
A B
C
e1
e2
e2
Quedaría como:
C
a bA Be1
e2
Generalización de Estados
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
top related