Upload
tranthu
View
231
Download
0
Embed Size (px)
Citation preview
1
Desarrollo de Software Basado en Modelos
UML
Prof. Roxana Giandini
Facultad de Informática - UNLPOptativa - 2010
UNLP, Marzo 2010
Unified Modeling Language
Lenguaje Unificado de Modelado
2
UNLP, Marzo 2010
Modelado
Ideas centrales en la concepción del Proceso de Modelado:
§ El modelo es la columna vertebral de un lenguaje utilizado por todos los integrantes del equipo:
Desarrolladores - Expertos del dominio – Usuarios - Analistas
§ El modelo es conocimiento depurado.
UNLP, Marzo 2010
§Ayudan a la comprensión de sistemas complejos
§ Indican QUE hará el sistema pero NO COMO lo hará
§Ayuda a la corrección de errores
§Ayuda a la evolución y reuso
§ Esencial para la comunicación entre miembros de un equipo
Modelado
3
UNLP, Marzo 2010
Unificado
Un poco de historia• A mediados de los noventa existían muchos métodos de
Análisis y Diseño OO
§ Mismos conceptos con distinta notación§ Mucha confusión§ No existía un lenguaje líder de modelado
• En 1994 deciden unificar sus
métodos: Unified Modeling Language (UML)
• Proceso de estandarización promovido por OMG en 1997
G. Booch (Método Booch)J. Rumbaugh (OMT) I. Jacobson (Proceso Objectory)
UNLP, Marzo 2010
Unificado
La unificación agrupa otros enfoques:
Rumbaugh Jacobson
Meyer
Harel
Wirfs-Brock
Fusion
Embly
Gamma y otros
Shlaer-Mellor
Odell
Booch
Pre y Post Condiciones
Diagramas de Estado
Responsabilidades
Descripción de operaciones,Numeración de mensajes
Clases singleton
Frameworks, Patrones, Notas
Ciclo de vida del objeto
Clasificación
4
UNLP, Marzo 2010
Unificado
Ventajas de la unificación:
• Reunir los puntos fuertes de cada método.
• Idear nuevas mejoras
• Proporcionar estabilidad al mercado
• Eliminar ambigüedad en los usuarios
UNLP, Marzo 2010
• En la unificación se adopta un Lenguaje Gráfico estándar
• Como toda definición de Lenguaje, posee:
§ Sintaxis:
determina las reglas de construcción de los diagramas de modelado.
Provee base formal para los diagramas (metamodelo, OCL).
§ Semántica:
otorga la descripción detallada del significado conceptual de cada
elemento de modelado.
Lenguaje
5
UNLP, Marzo 2010
¿ Qué es entonces UML ?
UML es un lenguaje estándar para:
§ visualizar
§ especificar
§ construir
§ documentar
los artefactos de un sistema.
Lenguaje Unificado de Modelado
UNLP, Marzo 2010
•Útil en las diferentes etapas del ciclo de vida del desarrollo
de sistemas.
Lenguaje Unificado de Modelado
6
UNLP, Marzo 2010
• Independiente del proceso de desarrollo de software.
Lenguaje Unificado de Modelado
MSF
UNLP, Marzo 2010
• Independiente del lenguaje de implementación.
Lenguaje Unificado de Modelado
C++
7
UNLP, Marzo 2010
•Un estilo
•Un lenguaje
•Un proceso
•Herramientas
à O.O.
à UML
à UPà Together / Poseidon / Rational Modeler
¿Qué elementos definen un Método de Modelado?
UNLP, Marzo 2010
Visión General de UML
• Definición de Vistas como proyección
compor
tamien
to
estructura
8
UNLP, Marzo 2010
Utilidades de UML
UML permite:
• Definir los límites del sistema y sus principales funciones, mediante Casos de Uso y actores.
• Ilustrar el funcionamiento de un caso de uso mediante Diagramas de Interacción
• Representar la estructura de un sistema mediante Diagramas de Clases.
• Modelar el comportamiento de los objetos mediante Diagramas de Máquinas de Estados.
UNLP, Marzo 2010
Utilidades de UML
UML permite:
• Describir la arquitectura de la implementación física con Diagramas de Componentes y Despliegue.
• Extender la funcionalidad de elementos estándar mediante estereotipos.
• Proveer base formal para los diagramas (metamodelo, OCL).
9
UNLP, Marzo 2010
Diagramas de UML 2.0
Diagrama de Estructura Compuesta
Diagrama de Estructura Paquete
Diagrama deComponentes
Diagrama deDespliegue
Diagrama deObjetos
Diagrama deClases
Diagrama de Secuencias
Diagrama General deInteracción
Diagrama de Tiempos
Diagrama de Comunicación
Diagrama de MáquinaDe Estados
Diagrama deActividad
Diagrama de Casos de Uso
UNLP, Marzo 2010
• Elementos
• Relaciones
• Diagramas
UML: bloques de construcciónClase - Interfaz - Estructura Compuesta - Caso de UsoClase Activa - Componente - Nodo
Interacci ón - Máquina de Estados - Actividad
Paquetes - Frame
Notas
DependenciaAsociaciónGeneralización
Estructurales
De Comportamiento
De Agrupación
De Anotación
De Instancia Objetos
Diagrama de ClasesDiagrama de ObjetosDiagrama de Estructura CompuestaDiagrama de PaquetesDiagrama de ComponenteDiagrama de DespliegueDiagrama de Casos de UsoDiagrama de Máquina de EstadosDiagrama de ActividadesDiagrama de Secuencia Diagrama de ComunicaciónDiagrama de TiemposDiagrama de Vista Global
10
UNLP, Marzo 2010
Diagramas de Casos de Uso
Diagramas Estáticos§ Diagrama de Clases§ Diagrama de Objetos§ Diagrama de Estructuras Compuesta§ Diagrama de Paquetes
Diagramas de Comportamiento§ Diagrama de Máquina de Estados§ Diagrama de Actividades§ Diagrama de Interacción:§ Diagramas de Secuencia § Diagramas de Comunicación§ Diagramas de Tiempo§ Diagramas de Vista Global
Diagramas de Implementación§ Diagrama de Componentes§ Diagrama de Despliegue
Clasificación de los Diagramas UML
UNLP, Marzo 2010
Construcciones de extensión
UML incluye tres construcciones principales de extensión:
§ Restricciones:una declaración textual de una relación semántica expresada en un cierto lenguaje formal (OCL) ó en lenguaje natural.
§ Estereotipos:una nueva clase de elemento del modelo, ideada por el modelador, y basada en un tipo existente de elemento del modelo.
§ Valores etiquetados:una porción de información con nombre, unida a cualquier elemento del modelo.
11
UNLP, Marzo 2010
•• La restricción en la clase Representación asegura quelos nombres de las representaciones sean únicas.
Construcciones de extensión: restricciones
Representación
nombre: string;
cd UsoDeRestriccion
restricción
{ deben ser únicos para una temporada de teatro }
UNLP, Marzo 2010
•• El estereotipo en el componente BD Entrada indica que el componentees una base de datos, lo que permite omitir qué interfaces soporta,puesto que son las soportadas por todas las bases de datos.
Construcciones de extensión: estereotipos
cmp UsoDeEstereotipos
<< base de datos >>BD Entradas
estereotipo
BD Entradas
icono de estereotipo
12
UNLP, Marzo 2010
Construcciones de extensión: valores etiquetados
pkg UsoDeValoresEtiquetados
<< subsystem >>Planificación
estereotipo
valores etiquetados
Programación
{ autor = Juan Pérezcreación = 20/08/2005 }
Marketing
{ autor = Pedro Rodríguezcreación = 05/03/2004 }
Diagrama de Casos de Uso
13
UNLP, Marzo 2010
Modelado de Casos de Uso
Los Casos de Uso son útiles para representar requisitos funcionales. Fueron propuestos inicialmente por Ivar Jacobson e incorporados a UML.
Objetivos:
• Dar una descripción de lo que deberá hacer el sistema
• Dar un base para realizar las pruebas del sistema
• Definir una base para rastrear errores, simplificando los cambios y
extensiones del sistema.
UNLP, Marzo 2010
Contenido:
•Casos de Uso
•Actores
•Relaciones
Diagramas de Casos de Uso
<< actor >>
Nombre_ActorNombre_Actor
Nombre del caso de uso
Dependencia
Asociación
Generalización
14
UNLP, Marzo 2010
•Un Caso de Uso es, en esencia, una interacción típica entre un usuario y un sistema.
•El Caso de Uso capta una función visible para el usuario.
•El Caso de Uso logra un objetivo concreto para el usuario.
Casos de Uso
UNLP, Marzo 2010
Un actor modela un tipo de rol que juega una entidad queinteracciona con el sistema pero que es externa a él.
•Notación:
§ Se representan con el ícono estándar de “stick man” o “monigote” con el nombre del actor (obligatorio) cerca del símbolo.
§ Se pueden usar otros símbolos para representar tipos de actores, por ejemplo actores no humanos.
Actores
Subsistema Contable
uc actor_a
BD Facturaciones
uc actor_b
Aplications Server
uc actor_c
15
UNLP, Marzo 2010
Se pueden establecer relaciones de generalización entre actores:
• El actor general describirá el comportamiento de un rol más general.
• Los actores especializados heredan el comportamiento del actor general y lo refinan de alguna forma.
Una instancia de un actor especializado siempre se puede utilizar en aquellos casos en los que se espera una instancia del actor general.
Relaciones entre Actores
Relación “es subclase de”
UNLP, Marzo 2010
Relaciones entre Casos de Uso
Notación:
• Asociación
• Generalización
• Dependencia
– Inclusión
– Extensión
<< includes >>
<< extends >>
16
UNLP, Marzo 2010
Relaciones entre Casos de Uso
Generalización:
Se utiliza cuando un Caso de Uso se puede especializar en uno o más Casos de Uso hijos.
Realizar búsqueda de libro
Búsqueda por autor Búsqueda por título Búsqueda por ISBN
UNLP, Marzo 2010
Relaciones entre Casos de Uso
Inclusión:
• El Caso de Uso incorpora el comportamiento de otros Casos de Uso como parte de su propio comportamiento en un determinado momento del curso de su acción.
•Se entiende que algunos de los pasos en una situación dentro de un Caso de Uso son los mismos que los de otro Caso de Uso, y en lugar de listar los mismos pasos, tan sólo indicamos el Caso de Uso de donde provienen.
17
UNLP, Marzo 2010
Ejemplo
Tomar curso UML Avanzado
Validar condiciones del estudiante Validar estado del curso Efectivizar matrícula
<< include >><< include >> << include >>
UNLP, Marzo 2010
Relaciones entre Casos de Uso
Extensión:
• El Caso de Uso se define como una extensión incremental de un caso de uso base en uno o más puntos de extensión.
•Se entiende que se agregan pasos a un Caso de Uso existente, y esto se hace creando un nuevo Caso de Uso, que enriquece al existente, pero no lo modifica.
18
UNLP, Marzo 2010
Documentación de los Casos de Uso
Composición general No estandarizada:
•Resumen de la Identificación.
•Descripción de Recursos.
•Definición de Conversación.
•Requisitos de Interfaz de usuario
• Requisitos funcionales.• Requisitos no funcionales.
UNLP, Marzo 2010
Pre-condiciones: - la representación solicitada existe en el teatro.- hay asientos disponibles para la función solicitada.
Post-condiciones: - el vendedor posee más efectivo en la caja registradora- el nº de asientos disponibles para dicha representaciónes menor que al comienzo del C.U.
Conversación del C.U. “Comprar entradas por reserva”
19
UNLP, Marzo 2010
8.1. – La tarjeta se encuentra dañada àRECHAZAR EL COBRO Y DAR
AVISO.
8. – Validar Tarjeta de débito
1. – Comprar Entrada x Reserva
11. – Entregar Boleto impreso y elmedio de pago (Tarjeta de débito)
10. – Imprimir Boleto de Entrada
9.1. – La tarjeta No posee saldo disponible àRECHAZAR EL COBRO Y DAR
AVISO.
9. – Efectuar cobro del boleto
7. – Confirmar pago (Tarjeta de débito)
6. – Solicitar forma de pago
5. – Generar Boleto
4. – Eliminar Reserva
3. – Efectivizar Compra
2.1 – La reserva está vencida àRECHAZAR LA COMPRA.
2. – Validar la reserva
Curso AlternativoCurso Normal
RESPUESTA DEL SISTEMAACCIONES DEL
Conversación del C.U. “Comprar entradas por reserva”
Diagrama de Clases
20
UNLP, Marzo 2010
Diagrama de Clases
Definición:
Un diagrama de clases muestra las clases del sistema y sus relaciones. Describe la vista estática de un sistema.
UNLP, Marzo 2010
•¿Qué es una clase?Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.
•Estructura:
NombreClase
Atributos
Operaciones
Diagrama de Clases: clase
21
UNLP, Marzo 2010
•¿Cómo podemos proteger los datos?El encapsulado es el principio para ocultar datos(data hiding).
La visibilidad puede ser:
§ Privada (-): objetos donde está definido el atributo u operación.
§ Protegida (#): objetos de las subclases.
§ Pública (+): objetos de cualquier clase.
Visibilidad de atributos y operaciones
UNLP, Marzo 2010
Clase: atributo
Sintaxis
[visibilidad] nombre [multiplicidad][:tipo][=valor inicial][{lista_propiedades}]
Propiedades:- changeable- addOnly- frozen
Ejemplos
id
nombre
responsable
género
Representación-id: Integer {frozen}
+nombre:String
responsable [1..2]:String
#genero:String=musical
Representación
22
UNLP, Marzo 2010
Clase: operación
•Sintaxis
[visibilidad] nombre[(lista de parámetros)][:tipo de retorno][{propiedades}]
• Declaración de un parámetro:[dirección] nombre :tipo [multiplicidad][=valor]
• Donde dirección puede ser:- in: la operación puede modificar el parámetro y el que
llama no necesita volver a verlo.- out: la operación coloca o cambia el parámetro y lo
devuelve al que llama.- inout: la operación utiliza el parámetro y puede cambiarlo
para devolverlo.
UNLP, Marzo 2010
Clase: operación
Propiedades– isQuery– ….
Ejemplos
Representación
nuevaRep()
nombreRep()
estaVigente()
Representación
+nuevaRep(in nombre:String)
#nombreRep()
estaVigente(): Boolean {isQuery}
23
UNLP, Marzo 2010
Diagrama de clases: relaciones
¿Qué son las relaciones entre clases?
Una relación es una conexión semántica entre objetos. Proveen un camino de comunicación entre ellos.
¿Qué tipos de relaciones existen?
•Asociación•Generalización•Dependencia•Realización
UNLP, Marzo 2010
Diagrama de clases: relaciones
•Notación:
• Asociación
• Agregación
• Composición
• Generalización
• Dependencia
• Realización
24
UNLP, Marzo 2010
Relaciones: Asociación
¿Qué es una Asociación?
Es una relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro.
Ejemplo
UNLP, Marzo 2010
Asociación: propiedades (cont.)
Multiplicidad: indica “cuántos” objetos pueden conectarse a través de una instancia de una asociación.
• Se puede indicar una multiplicidad de:
– Exactamente Uno:
– Cero o Uno:
– Muchos:
– Uno o Más:
– Número Exacto:
– Lista:
– Rango:
A
A
A
A
A
A
B
B
B
B
B
B
1
0..1
0..*
1..*
3
0..1,3..5,7..9
A B3..6
25
UNLP, Marzo 2010
• Rol: son las caras que presentan las clases a las demás.• Navegabilidad: sirve para limitar la navegación a una sola
dirección.
• Visibilidad: sirve para limitar la visibilidad a través de esta asociación relativa a los objetos externos a ella.
• Pública (+)• Protegida (#)• Privada (-)
Asociación: propiedades
Usuario Clave*1 propietario
GrupoUsuarios Usuario Clave* * 1 *
+usuario+propietario -clave
UNLP, Marzo 2010
Asociación: propiedades (cont.)
Agregación: es una asociación especial, una relación del tipo “todo/parte” dentro de la cual una o más clases son partes de un todo.
Ejemplo:
Equipo
Miembro
Todo
Parte1 Parte2
Todo
Parte1 Parte2
TeatroDepartamento
26
UNLP, Marzo 2010
Asociación: propiedades (cont.)
Composición: es una forma de agregación, con fuerte sentido de posesión y tiempo de vida coincidentes de las partes con el conjunto.
– Una parte puede pertenecer solamente a una composición (un todo).
– Cuando el todo desaparece, también lo hacen sus partes.
Todo
Parte
UNLP, Marzo 2010
Asociación: propiedades (cont.)
Ejemplos de Agregación y Composición
Polígono
Estilo
ColorestáLleno
Punto
Círculo
radio
3..*
*
1 1
*
1..*{ordenado}
27
UNLP, Marzo 2010
Asociación: notación accesoria
• Nombre: indica la naturaleza de la asociación. Puede estar acompañado de un triángulo que apunta en la dirección que debe leerse.
• Ejemplo
Espectador Entradacompra
FormaDePago
paga
UNLP, Marzo 2010
¿Qué es una Generalización?Es una relación entre un elemento general (llamadosuperclase o padre) y un caso más específico de eseelemento (llamado subclase o hijo).
Ejemplo
Relaciones: Generalización
Representación
nombreRep()vigenteHasta()
Recital
vigenteHasta()
ObraDeTeatro
vigenteHasta()
MuestraArtística
vigenteHasta()
•En UML puede representarse herencia múltiple
28
UNLP, Marzo 2010
Generalización
•En UML puede enriquecerse el diagrama de Herencia (Generalización) con discriminantes y restricciones.
•Ejemplo con restricción
•Otras Restriccionescomplete, incomplete, disjoint, overlapping.
Representación
Recital ObraDeTeatro MuestraArt ística
<<powertype>>TipoDeRepresentaci ón
{incomplete}
UNLP, Marzo 2010
Generalización
•Ejemplo con discriminador
Vehículo
PorViento
propulsi ón
PorMotor SobreAgua SobreTierra
TractorVelero
propulsi ónlugar
lugar
29
UNLP, Marzo 2010
Elementos de anotación
•¿Qué es una nota?Es un símbolo para mostrar restricciones y comentarios junto a un elemento o una colección de elementos.
•Ejemplo
Persona Compañiaempleado trabajo
* 1
jefe
1..*
1
{ Persona.trabajo = Persona.jefe.trabajo }
empleados
UNLP, Marzo 2010
Diagrama de clases - Ejemplo
30
Diagrama de Paquetes
UNLP, Marzo 2010
Paquete
Nombre de Paquete+Clase_1+Clase_2#Clase_3
Nombre de Paquete
PaqueteContenedor::Nombre de Paquete{versi ón = 2.0}
¿Qué es un Paquete?
Es un elemento más de UML, cuyo propósito general esorganizar elementos en grupos.
Notación:
31
UNLP, Marzo 2010
Paquete
¿Cuáles son las ventajas de utilizar Paquetes?
• Evitar conflictos de nombres.
• Facilitar el reconocimiento y búsqueda de elementos de acuerdo a una funcionalidad específica.
• Controlar el acceso a sus contenidos.
• Todos los mecanismos de extensibilidad de UML se aplican a los paquetes.
UNLP, Marzo 2010
Paquete
•Nombre: cada paquete ha de tener un nombre que lo distingue de otros paquetes.
•Elementos contenidos: puede contener clases, interfaces, componentes, nodos, colaboraciones, casos de uso, diagramas e incluso otros paquetes.
• Elementos de diferentes tipos pueden tener el mismo nombre dentro de un paquete.
•Visibilidad: se controla la visibilidad de los elementos contenidos en el paquete, de la misma manera que se controla la visibilidad para atributos y operaciones de una clase.
• Pública (+)• Protegida (#)• Paquetes amigos• Privada (-)
32
UNLP, Marzo 2010
Accesibilidad
Importación: Se concede un permiso de un solo sentido para que los elementos de un paquete accedan a los elementos de otro.
Exportación: las partes públicas de un paquete son sus exportaciones.
Paquete_1 Paquete_2<<import>>
+Clase_1+Clase_2-Clase_3
Paquete1
+Clase_1-Paq::Clase_2
Paquete2exportaciones
<<import>>
Diagramas de Interacción
33
UNLP, Marzo 2010
Definición:
Un diagrama de interacción describe una interacción, que consta de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar, para realizar un comportamiento.
Diagramas de Interacción
UNLP, Marzo 2010
•Objetos
•Enlaces
•Mensajes
• Pueden contener:• notas y restricciones.
Diagramas de Interacción: contenido
objeto:Clase
34
UNLP, Marzo 2010
Diagrama de Secuencia
Definición:
Un diagrama de secuencia destaca la ordenación temporal de los mensajes.
Sintaxis:[Número de secuencia] [condición] * [expresión iteración] [valor de retorno :=] nombre del mensaje (parámetros)
UNLP, Marzo 2010
Bifurcaciones
objetoA:ClaseA :ClaseB
:ClaseC[cond1] mensajeCond1()
[cond2] mensajeCond2()
35
UNLP, Marzo 2010
Iteración o bucle
•Sintaxis:* [expresión-iteración ] mensaje
•Ejemplo:
v: Vendedor :LíneaProducto
*[1..8] verificarLínea()
UNLP, Marzo 2010
Iteración de una serie de mensajes
•Ejemplo:
bucle
36
UNLP, Marzo 2010
Diagrama de Comunicación
Definición:
Un Diagrama de Comuncación destaca la organización estructural de los objetos participantes y el envío de mensajes.
Sintaxis:Número de secuencia [condición] *[expresión iteración]: [valor de
retorno :=] nombre del mensaje ([parámetros])
UNLP, Marzo 2010
Mensajes condicionales
Un mensaje condicional es aquel que se envía si la evaluación de la cláusula es verdadera.
Notación:
:ObjetoClaseA :ObjetoClaseB1:[condición] mensaje()
Si condición es verdadera, se env ía el mensaje.
37
UNLP, Marzo 2010
Iteración o bucle
•Sintaxis:* [expresión-iteración ] mensaje
•Ejemplo:
v:Vendedor :LíneaProducto1 *[1..8]: verificarLínea()
UNLP, Marzo 2010
Iteración sobre una colección
•Los multiobjetos se utilizan para denotar un conjunto de instancias -colección-.
•Ejemplo:
v:Venta :LíneaDeVenta1 * : st::= getSubtotal() *
Estos dos símbolos “*” utilizados conjuntamente implican iteración sobre el multiobjeto y el env ío del mensaje getSubtotal a cada uno de los miembros.
38
Diagrama de Actividades
UNLP, Marzo 2010
Diagrama de Actividades
¿Qué es una actividad?Es una ejecución no atómica en curso, dentro de una máquina de estado
¿Qué es un Diagrama de Actividades?Representa el comportamiento mediante un modelo de flujo de datos y flujo de control
• muestra el flujo de control entre distintas actividades, cumpliendo una finalidad
• destaca la actividad a lo largo del tiempo
39
UNLP, Marzo 2010
Diagrama de Actividades
Las actividades producen finalmente una acción.
¿Qué es una acción?
Es una especificación de una unidad fundamental de comportamiento que representa una transformación o procesamiento.
• Las acciones están compuesta de cálculos atómicos ejecutables que producen un cambio de estado o la devolución de un valor.
UNLP, Marzo 2010
Diagrama de Actividades
ACCIONES
•Llamadas a otras operaciones.
•Creación de objetos.
•Envío de señales
•Destrucción de objetos.
•Simples cálculos.
40
UNLP, Marzo 2010
Diagrama de Actividades
• estados
• transiciones
• objetos
de acción
de actividad
Un Diagrama de Actividades está compuesto por:
nombre_estado
objeto:Clase
UNLP, Marzo 2010
Diagrama de Actividades
Estado de acción:
• Es un estado atómico.
• Pueden representar la evaluación de una expresión o invocar una operación sobre un objeto, incluso crearlo o destruirlo.
Ejemplos:
Eliminar mensaje
Monto total := costoUnitario x cantidad Expresión
Acción simple
41
UNLP, Marzo 2010
Diagrama de Actividades
Estado de actividad:
• No es un estado atómico.
• Puede ser visto como un elemento compuesto que se descompone en estados de actividad y de acción.
• Puede tener acciones de entrada y salida (entry/exit) y especificaciones de submáquinas.
Preparar construcción ()
entry / ponerBloqueo() Acción de entrada
Submáquina
UNLP, Marzo 2010
Transición de una actividad:
Diagrama de Actividades
Actividad 1
Actividad 2
punto inicial
punto final
transición sin disparador
nombre de la actividad
42
UNLP, Marzo 2010
• Bifurcaciones• Divisiones • Uniones• Swimlanes
Diagrama de Actividades
Elementos de interconexión:
UNLP, Marzo 2010
Diagrama de Actividades
Despertar
Desayunar Volver a dormir
[ inapetente ][ hambriento ]
Expresión de guardaBifurcación
43
UNLP, Marzo 2010
Diagrama de Actividades: fork y join
Fin de la jornada
Controlar recaudación Cerrar caja
división
unión
UNLP, Marzo 2010
Marcos de responsabilidades
Llamar al cliente y concertar una cita
Preparar una salade conferencias
Preparar una laptop
Junta con el cliente
Enviar un memorando
Crear propuesta
Enviar la propuesta al cliente[ no se plantea un problema ]
[ cita local ]
[ cita externa ]
Ver el D. de actividades para crear un documento
Vendedor Consultor Técnico
[se plantea un problema ]
44
Diagrama de Máquina de Estados
UNLP, Marzo 2010
Modelado de Máquina de Estados
•Los Diagramas de Máquina de Estados
• Son útiles para modelar la vida de un objeto.
• Describen los estados por los que puede pasar un objeto
durante su ciclo de vida y el comportamiento en esos estados
junto con los eventos que causan los cambios de estado.
•Los Diagramas de Máquina de Estados pueden asociarse a
• Clases• Casos de Uso• Sistemas Completos
para visualizar, especificar, construir y documentar la dinámica de un objeto individual.
45
UNLP, Marzo 2010
Diagrama de Máquina de Estados
Las Máquinas de Estados pueden componerse de:
• estados
– estados simples.
– estados compuestos.
• transiciones
– eventos.– acciones.
Nombre_del_estado
NombreSubestado
NombreSubestado
Nombre_del_estado
UNLP, Marzo 2010
Diagrama de Máquina de Estados
Estado:es una condición en la que puede estar un objeto en algún momento de su ciclo de vida, durante un cierto tiempo.
Mientras está en un determinado estado, el objetopuede llevar a cabo algunas (o todas) de las siguientesacciones:
– realizar una actividad.– esperar un evento.– satisfacer una o más condiciones.
46
UNLP, Marzo 2010
Diagrama de Máquina de Estados
Estado inicial
Estado final
H
Estado de historia
Estado secuencial compuesto Estado concurrente compuesto
evento1 / nombre de actividad internaevento2 / nombre de actividad interna
exit / nombre de actividad al salirenter / nombre de actividad al entrardo / nombre de actividad a realizar
Transiciones internas
Nombre del estado
Variables de estado
UNLP, Marzo 2010
•Transiciones: una transición es un cambio del objeto desde un estado (estado
fuente/origen) a otro (estado destino).
Empaquetando Enviando
También puede haber una auto-transición cuando ambos estados coinciden.
Recibiendo Pedidos
Diagrama de Máquina de Estados
47
UNLP, Marzo 2010
Diagrama de Máquina de Estados
Evento: es la especificación de un acontecimiento significativo.
Acción: es una computación que produce un cambio de estado en el modelo o la devolución de un valor.
Enviando EnviadoconfirmacionEnvío
Enviando EnviadoconfirmacionEnvío / registraNºEmpaque( )
UNLP, Marzo 2010
Diagrama de Máquina de Estados
reservar comprar
cancelar
[cantidad _ días > 5]
devolver
comprar
Estado finaltransición
autotransición
[<condición>]/<acción>
Estado simple
Estado inicial
evento