2 Uml

1
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp, Simon Pickin, Angeles Manjarrs
1
Unified Modeling Language 2.0
Autores:
Dr. Harald Strrle
MGM-EDV Beratung GmbH
y Universidad de Munich
Dr. Alexander Knapp
Universidad de Munich
Versin abreviada y traduccion:
Simon Pickin, Angeles Manjarrs
Para el tutorial original ver, por ejemplo:
ht t p: / / www. pst . i f i . l mu. de/ ver oef f ent l i chungen/ UML 2. 0- Tut or i al . pdf
2
Tutorial UML 2 fuentes originales
Esta presentacin es una
traduccin de una versin
abreviada de un tutorial
redactado por A. Knapp & H.
Strrle y presentado
en congresos internacionales
(SEFM06, VLHCC06),
para formacin en empresas
(WEKA, MGM)
para formacin universitaria
(MNM).
Los autores proporcionan
formacin y consultora sobre
UML y temas afines.
Ms artculos sobre UML vase:
www.pst.ifi.lmu.de/~knapp
www.pst.ifi.lmu.de/~stoerrle.
Los diagramas de este tutorial
se han tomado de los dos libros
siguientes, ahora ampliamente
usados para formacin en
Alemania.
UML 2 fr Studenten
ISBN 3-8273-2268-5 ISBN 3-8273-7143-0
2
3
Ejemplo utilizado a travs del tutorial:
Albatross Air Autopilot (AAA)
Imagnese una lnea area ficticia, Albatross Air, que
est a punto de automatizar sus procesos en base a
un nuevo sistema de informacin de gran alcance
llamado Autopiloto Albatross Air abreviado a AAA.
Las capacidades de AAA incluyen soporte para la
reserva de vuelos, y para el check-in y embarque de
pasajeros, as como un programa de puntos para
clientes habituales llamado Millas Albatross.
4
Parte 1 - Introduccin
3
5
1 - Introduccin
Historia y predecesores
El UML es la lingua franca de la
ingeniera del software.
Subsume, integra y consolida a la
mayor parte de sus predecesores
Tiene un alcance ms amplio y un
soporte mucho mejor
(herramientas, libros, formacin
etc.) que otras notaciones.
Transicin UML1.xUML2.0:
nmerosos problemas resueltos,
muchos conceptos nuevos
introducidos,
estructura interna revisada
completamente y mejorada.
Aunque UML 2.0 todava tiene
muchos problemas, es mucho
mejor que lo que exista antes.
versin actual (el estndar)
formal/05-07-04 de agosto 05
6
1 - Introduccin
Escenarios de uso
UML no se dise para usos especficos y limitados.
Actualmente no hay consenso sobre su papel:
algunos ven UML slo como una herramienta para esbozar
diagramas de clase que representan programas Java.
otros creen que UML es el prototipo de la prxima
generacin de lenguajes de programacin.
En realidad, UML es una sistema de lenguajes (o
notaciones, tipos de diagramas), cada uno de los
cuales puede usarse en varias situaciones distintas.
UML es aplicable, en mayor o menor grado, para
mltiples fines y durante todas las fases del ciclo de
vida del software.
4
7
1 - Introduccin
Escenarios de uso
8
1 - Introduccin
Tipos de diagramas de UML 2
UML es un sistema coherente de lenguajes ms que
un lenguaje nico.
Cada lenguaje tiene su enfoque particular.
5
9
1 - Introduccin
Los tipos de diagramas tambin dependen
de su uso
Cada tipo de diagrama puede usarse
en multitud de contextos, para cada
uno de los cuales sean pertinentes
diferentes reglas y buenas prcticas.
Por ejemplo, los diagramas de clase
pueden usarse tanto durante el
anlisis como durante la
implementacin.
Durante el anlisis, este diagrama de
clases es malo, o al menos dudoso.
Durante la implementacin, es malo
si y solo si no se corresponde con el
cdigo (u otra estructura) para cuya
representacin es usado.
10
1 - Introduccin
Estructura Interna: Visin de conjunto
UML se estructura mediante un enfoque de metamodelado
de cuatro capas.
La capa M
2
se denomina metamodelo.
El metamodelo se estructura a su vez en anillos, en uno de
los cuales, denominado superestructura, se definen los
conceptos (el metamodelo propiamente dicho).
La Superestructura se estructura en un rbol de paquetes
6
11
1 - Introduccin
Estructura Interna: Niveles
12
1 - Introduccin
Estructura Interna: Capas
7
13
1 Introduccin
Estructura Interna: Anillos
14
1 - Introduccin
Estructura Interna: Paquetes
8
15
1 - Introduccin
Diagramas y Modelos
nombre del
diagrama
(pragmtico)
tipo de diagrama
modelo
(sintaxis abstracta)
diagrama
(sintaxis completa)
representa presenta
Estructura de datos,
instancia del metamodelo
16
1 - Introduccin
UML no es (slo) orientado a objetos
Una popular concepcin errnea del UML consiste en
considerarlo obligadamente orientado a objetos.
Es cierto que
UML define conceptos como clase y generalizacin;
UML se define (principalmente) mediante un conjunto de modelos
de clases;
UML2 redescubre la idea de comportamiento incorporado en objetos.
Sin embargo, UML 2.0
tambin abarca muchos otros conceptos de origen pre o no-OO
(Actividades, Mquinas de Estados, Interacciones,);
puede utilizarse en proyectos de desarrollo con independencia
completa de sus lenguajes de implementacin;
no est vinculado a ningn lenguaje ni paradigma de lenguajes, ni
por accidente ni a propsito.
9
17
1 - Introduccin
UML 1.x vs. UML 2.0
UML 2.0 tiene varias ventajas frente a UML 1.x:
muchos nuevos conceptos potentes
definiciones mucho mejores (esto es, semntica)
estructuracin interna mejorada
Sin embargo, aunque UML 2.0 est mucho mejor definido que
UML 1.5, su estado no es an satisfactorio, p.e..
sintaxis
notacin sobrecargada: demasiados sinnimos,demasiado azucarado,
falta de ortogonalidad notacional, hay quien ni siquiera desea esto,
semntica
falta de semntica precisa: informal, dfns. contradictorias y poco claras,
pragmtica
falta de base metodolgica tal como condiciones de coherencia de
modelos, tipos de uso etc.
Aun as, es el lenguaje de modelado ms completo (unificado)
18
1 - Introduccin
Conclusiones
UML is la lingua franca de la ingeniera del software.
Tiene muchos problemas, pero aun as es lo mejor
hasta la fecha.
Puede usarse durante todo el ciclo de desarrollo soft.
para planear, analizar, disear, implementar y documentar
El UML est estructurado
mediante un enfoque de metamodelado de 4 niveles
(M
0
: sistema, M
1
: modelo, M
2
: metamod., M
3
: metametamod.),
el metamodelo se estructura en 3 anillos
(infraestructura, superestructura, extensiones),
la superestructura se organiza como un rbol de paquetes.
(e.g. Acciones, Actividades, Comportamientos Comunes, Clases)
UML no es obligadamente orientado a objetos.
10
19
Parte 2 Casos de Uso
20
3 Casos de Uso
Un primer vistazo
Aspectos mostrados
lmites y contexto del sistema
sistemas usuarios y vecinos
funcionalidades
relaciones entre funcionalidades (llamada/dependencia, taxonoma)
requisitos funcionales
algunos requisitos no funcionales (calidad) como comentarios/
anotaciones
11
21
3 Casos de Uso
Escenarios de Uso
Inventario de casos de uso/ arquitectura del dominio
catlogo completo de todos los subdominios y (grupos de)
procesos de negocio y funciones de negocio
visin de conjunto de las capacidades (del dominio) del sistema
Casos de usoclsicos
ilustran el contexto de la funcionalidad individual
til en el diseo/documentacin de los procesos de negocio (esto
es, fase de anlisis y reingeniera)
Tabla de casos de uso / casos de test
descripcin detallada esquemtica de procesos/funciones/casos de
pruebas
rbol de funciones
descomposicin funcional del comportamiento del sistema
til para construccin no-OO y re-arquitectura de sistemas pre-OO
22
3 Casos de Uso
Conceptos principales (sintaxis concreta)
Actor
Clase (tambin posible: Componente)
extiende
(una Dependencia)
Caso de
Uso
incluye
(una Dependencia)
Asociacin
12
23
3 Casos de Uso
Inclusin & extensin
Inclusin
la llamada comn
dirigida desde el llamante al
llamado
puede tener lugar una o ms
veces
Extensin
cubre comportamiento
variante o excepcional
la relacin se dirige desde la
excepcin al caso estndar
puede o no tener lugar
tiene lugar al menos una vez
24
3 Casos de uso
Puntos de extensin
Una extensin tiene lugar en
un (denominado)
ExtensionPoint, cuando se
satisface una condicin
especfica.
En cierto modo los
ExtensionPoints son similares
a los user exits o hooks.
En sistemas del mundo real,
hay muchos ExtensionPoints,
muchos de los cuales estn
pobremente documentados
UseCase con ExtensionPoints,
sintaxis alternativa adecuada para
un gran nmero de ExtensionPoints
ExtensionPoint
13
25
3 Casos de Uso
Cualquier nivel de abastraccin es vlido
Un caso de uso representa una
funcionalidad individual de un
sistema.
Existen sistemas en cualquier
nivel de granularidad.
As, los casos de uso pueden
utilizarse para funcionalidades
de cualquier granularidad :
desde procesos de negocio de
alto nivel,
via servicios (web),
a mtodos individuales de
funciones.
26
3 Casos de Uso
Generalizacin
Al igual que todos los
Classifiers, los casos de uso
pueden organizarse en
jerarquas taxonmicas.
Esto es particularmente til
para catlogos de
funcionalidades.
Desde el punto de vista
metodolgico, los casos de
uso abstractos son similares
a los subsistemas
funcionales.
14
27
3 Casos de Uso
Conclusiones
Los Casos de Uso pueden utilizarse para representar
una visin de alto nivel de la funcionalidad, como
visin de conjunto de la funcionalidad / arquitectura del
dominio
descripcin detallada del contexto del caso de uso individual
rbol de funciones (particularmente para reingeniera y
propsitos de documentacin)
UML an no incluye un esquema textual para
describir casos de uso.
Basicamente, los casos de uso de UML 2.0 son
iguales a los de UML 1.x.
28
Parte 3 Clases y paquetes
15
29
2 Clases y paquetes
Escenarios de uso
Las clases y sus relaciones describen el vocabulario del
sistema.
anlisis: ontologa, taxonoma, diccionario de datos,
diseo: estructura esttica, patrones,
implementacin: contenedores de cdigo, tablas de bases de
datos,
Las clases pueden utilizarse con distinto sentido en
distintas fases del desarrollo software.
30
2 Clases y paquetes
Metamodelo
16
31
2 Clases y paquetes
Ejemplo 1: diagrama de clases de analisis
32
Features estructurales
propiedades
comnmente conocidas como atributos
describen structura/estado de instancias
pueden tener multiplicidades
(por defecto: 1 para extremos de
asociaciones, 0..* = * para otras features)
Features comportamentales
operaciones
servicios que pueden invocarse
necesitan el respaldo de un mtodo
2 Clases y paquetes
Clases
Las clases describen un conjunto de instancias con
features (y semntica) comunes
clases inducen tipos (que representan conjuntos de valores).
son espacios de nombres (que contienen elem. nombrados).
17
33
2 Clases y paquetes
Asociaciones
describen conjuntos de tuplas cuyos valores se refieren a
instancias tipadas
en particular, relaciones estructurales entre clases
las instancias de asociaciones se denominan enlaces.
Los extremos de asociacin son propiedades.
corresponden a propiedades de la clase opuesta
(pero la multiplicidad por defecto es 1)
Los extremos de asociacin pueden ser navegables.
en contraste con las propiedades generales
navegable no navegable
asociacin ternaria
nombre de asociacin direccin
de lectura
extremo cualificado
(fh por fecha)
34
2 Clases y paquetes
Ejemplo 2: diagrama de clases de anlisis
18
35
2 Clases y paquetes
Herencia
Generalizacin
relaciona una clase especfica con una clase ms general
las instancias de la clase especfica lo son de la general
las features de la clase general estn especificados
implcitamente para la clase especfica
Tambin se aplican a las
asociaciones
puesto que son Classifiers
{ abstract } class
(sin instancias
directas, slo
las especializaciones
pueden tenerlas)
decorado con { root }: no hay superclass
decorado con { leaf }: no hay subclass
36
2 Clases y Paquetes
Restricciones
Restringen la semntica de los elementos del modelo.
pueden aplicarse a uno o ms elementos
no se prescribe ningn lenguaje
OCL se usa en la especificacin de UML 2.0
tambin puede usarse lenguaje natural
restriccin definida por
el usuario
restriccin predefinida de UML
(persona o compaa
propietarios)
19
37
Agrupan elementos.
proporcionan un espacio de nombres para estos elementos.
los elementos de un paquete pueden ser
public (+, visibles desde fuera; por defecto)
private (-, no visibles desde fuera)
acceso a elementos pblicos mediante
nombres cualificados
e.g., Flights::MilesAccount
2 Clases y paquetes
Paquetes (1)
Variantes notacionales
38
Importan nombres cualificados simplificados.
2 Clases y paquetes
Paquetes (2)
import pblico public X B
visibilidad por defecto public Q B
import pri vado con renombramiento pri vate R B
public
pri vate
Visibility
los restantes elementos visibles de B Q A
import de elemento pri vado especfico
(de otro modo public reescribe pri vate)
X A
Element Package
private ElementImport public ElementImport
public PackageImport renaming private ElementImport
20
39
2 Clases y paquetes
Ejemplo 3: diagrama de clases de diseo
40
2 Clases y paquetes
Features (1)
visible para elementos
slo en el espacio de nombres a que pertenece
en el mismo paquete que el espacio de nombres
a que pertenece
con generalizacin al espacio de nombres a que
pertenece
que pueden acceder al espacio de nombres a
que pertenece (por pertenencia suya, mediante
importacin, o mediante acceso)
private -
package ~
protected #
public +
Tipos de visibilidad (no hay tipo por defecto)
21
41
son redefinibles (a menos que se decoren con { leaf })
en clases que especializan a la clase contexto
2 Clases y paquetes
features (2)
pertenecen a un espacio de nombres (p.e., clase o paquete)
pueden definirse en el nivel de instancia o de clase
isStatic
default value
42
2 Clases y paquetes
Propiedades (de propiedades) (1)
Set (default)
Bag
Sequence
OrderedSet
Tipo de coleccin { unique } { ordered }
/ ({ deri ved }) computable a partir de otra informacin (defecto: false)
{ readOnl y } pueden leerse, no escribirse (defecto: false = unrestricted)
{ union } union de propiedades de subconjuntos (implica derived)
{ subsets } de qu propiedad esta propiedad es subconjunto
22
43
2 Clases y paquetes
Propiedades (de propiedades) (2)
undefined (!) shared
value composite
reference none
Tipos de agregacin (defecto: none)
Ejemplo de propiedades
44
2 Clases y paquetes
Caractersticas comportamentales
realizadas por comportamientos (p.e., cdigo, mquina de
estados).
{ abstract }: (virtual) las features comportamentales no declaran
comportamiento
las especializaciones deben proporcionar el comportamiento
pueden declararse las excepciones que pueden ser lanzadas
23
45
2 Clases y paquetes
Operaciones
Una operacin especifica el nombre, tipo devuelto, parmetros
formales,y restricciones para invocar un comportamiento
asociado.
pre / post
las precondiciones restringen el estado del sistema al invocar
la operacin
las postcondiciones restringen el estado del sistema cuando se
ha completado la operacin
{ query }: la invocacin no tiene efectos laterales
body: la condicin body describe los valores devueltos
{ ordered, unique } como para las propiedades, pero para los
valores devueltos
las excepciones pueden declararse
nombre de parmetro
tipo de parmetro
multiplicidad del parmetro
46
2 Clases y paquetes
Interfaces
Declaran un conjunto de features pblicas y obligaciones
coherentes.
es decir, especifican un contrato para los implementadores
(realizadores)
cliente
servidor
features que se ofertarn
Existen varias notaciones para la relacin cliente/servidor
lollipop
joint
24
47
2 Clases y paquetes
Diagrama de objetos
Slot with
ValueSpecification
los adornos de subrayado y extremo de asociacin son opcionales
InstanceSpecification InstanceValue
enlace
48
2 Clases y paquetes
Conclusiones
Clases y sus relaciones describen el vocabulario de un sistema.
Clases describen conjuntos de instancias con features
(caractersticas) comunes
StructuralFeatures (Propiedades)
BehavioralFeatures (Operaciones, Recepciones)
Las asociaciones describen relaciones estructurales entre clases
los extremos de asociacin son propiedades.
Las generalizaciones relacionan clases con clases ms
generales.
Los paquetes agrupan elementos
y proporcionan un Namespace para elementos agrupados.
InstanceSpecifications y enlaces describen fotogramas del
sistema.
25
49
Part 4 - Arquitectura
50
4 - Arquitectura
Un primer vistazo
Arquitectura de contexto & dominio
Estructura compuesta
diagramas(assembly)
Colaboracin
Despliegue
26
51
4 - Arquitectura
Escenarios de uso / vistas arquitecturales
Diagrama de contexto
define los lmites de un sistema en trminos de sus usuarios y
sistemas vecinos
define nombres/abreviaturas para el sistema y sus vecinos
Arquitectura de dominio
proporciona una visin alto nivel de los componentes del dominio
define nombres/abreviaturas para los subsistemas
Diagrama de estructura compuesta (system assembly diagram)
define puertos (interfaces del sistema) con nombres y abreviaturas
define conexiones entre interfaces
Diagrama de estructura compuesta (class assembly diagram)
como el anterior, en un nivel de granularidad ms fino
define tambin interfaces (de lenguaje de programacin) para
puertos
Colaboracin
documenta decisiones de diseo (patrones) de cualquier nivel de
granularidad
Diagrama de estructura del sistema
nodos fsicos y conexiones entre ellos
52
4 Arquitectura
Conceptos principales: estructura compuesta
Part
Port, interfaz
de una Part
Connector
Actor
un sistema
tal como una
Clase
o un
Componente
Part con
estereotipo
visual
Port con
estereotipo visual
nombre mejor sera: assembly diagrams
27
53
4 Arquitectura
Uso: conexin de componentes
La conexin entre puertos equivale a dependencias
de tipo delegacin/ llamada
54
4 - Arquitectura
Uso: conexin de componentes
El uso de la notacin conjunta revela detalles sobre
el nmero y direccin de las conexiones.
De izquierda a derecha:
dos conectores, uno en
cada direccin
un conector con direccin
y un conector sin
direccin.
28
55
4 Arquitectura
Componentes
Los componentes de UML 1.x eran slo binarios. En
UML 2.0, los componentes se definen de forma
mucho ms completa.
Un componente representa una parte modular de un
sistema que encapsula sus contenidos y cuya manifestacin
es reemplazable dentro de su entorno.
Un componente define su comportamiento en trminos de
las interfaces proporcionadas y requeridas. Como tal, un
componente sirve como un tipo, cuya conformidad se define
mediante estas interfaces requeridas y proporcionadas (que
describen su semntica tanto esttica como dinmica). Un
componente puede por tanto substituirse por otro slo si los
dos tienen tipos conformes. []
Un componente se modela a travs de todo el ciclo de
desarrollo [].
56
4 Arquitectura
Metamodelo: Partes y puertos
trazo discontinuo:
definido en otro paquete
29
57
4 - Arquitectura
Colaboracin
Definen de forma abstracta
un tipo de vinculacin sin ser
especfico.
Se pretende constituyan la
forma de describir patrones
de anlisis y diseo.
Pueden ayudar en etapas
tempranas del diseo
arquitectnico.
Podran tambin usarse para
describir restricciones
globales.
Pueden anidarse y
componerse.
Metodologicamente, son los
equivalentes estructurales de
los casos de uso.
58
4 Arquitectura
Estructura del sistema
Node
Comentario
para informacin cuantitativa
CommunicationPath
es un tipo de
Association
30
59
4 Arquitectura
Despliegue
Un despliegue es una
correspondencia entre artefactos y
nodos del sistema.
puede incluir
binarios
instancias de componente
los nodos del sistema pueden incluir
hardware (Dispositivo)
software (ExecutionEnvironment)
Formalmente, un despliegue es una
DeploymentRelationship.
Puede representarse situando
las entidades desplegadas o sus
nombres sobre el objeto de
despliegue.
Artifact
Node puede especializarse en
Device o
ExecutionEnvironment
60
4 Arquitectura
Metamodelo: Despliegue
trazos discontinuos:
definido en otro paquete
31
61
4 - Arquitectura
Conclusiones
Los conceptos populares del modelado arquitectural
(cpsula/actor, puerto) por fin han sido incluidos
en el UML, aunque el metamodelado no es muy
slido.
Despliegues, artefactos y conceptos relacionados se
han extendido, y son ahora ciudadanos de primera
clase.
Los componentes tienen finalmente una definicin
decente como unidades a travs del ciclo de vida.
62
Part 5 - Actividades
32
63
5 - Actividades
Primer vistazo
Los diagrams presentan todo tipo de flujos de control y de flujos
de datos.
Son de alguna manera duales a las mquinas de estado: el
enfoque se sita sobre acciones en vez de sobre estados.
Se ha guardado y extendido la notacin de UML 1.x (aunque
cambiando el significado).
64
5 - Actividades
Escenarios de uso
Los diagramas de actividad se pueden aplicar con
mltiples fines a travs de todo el ciclo de vida.
Anlisis
disear o documentar procesos en el dominio de
aplicacin (procesos de negocio)
Diseo
disear o documentar procesos como
composiciones de elementos pre-existentes tales
como tareas manuales o tareas para automatizar.
Implementacin
documentar programas existentes (es decir,
funciones, servicios, )
disear procesos algortmicos con la intencin de
convertirlos en cdigo en un lenguaje de
implementacin
33
65
5 - Actividades
Conceptos principales
Partition
InitialState
FinalState
ActivityEdge
ObjectNode
ActivityNode
MergeNode
DecisionNode
JoinNode
ForkNode
ObjectFlow
66
5 - Actividades
FlowFinal
ObjectNode
estereotipado
Activity
refinado
Las
partitciones
pueden
representarse
explcitamente
34
67
5 - Actividades
Pins
Los flujos de datos pueden representarse
explcitamente,
con nodos de flujo de datos unidos a un flujo de control,
con Pins en las Actividades, o
como una combinacin de stos
Pin
68
5 - Actividades
Parmetros de actividades
Los pins actan como parmetros para actividades.
ActivityParameter
35
69
5 - Actividades
Detalles de flujos de datos
Un flujo de datos define el
transporte de datos entre
buffers por actividades.
Los buffers pueden tener
capacidades y estar ordenados.
Aparte del transporte como tal,
un flujo de datos puede definir
tambin
la seleccin de un dato
particular, y
la transformacin de datos.
Muchas veces es til denotar el
estado de un dato en un buffer.
70
5 Actividades
Streaming
Streaming significa que
los datos se procesan en
flujo continuo.
El comportamiento de tipo
stream no pudo
expresarse en UML 1.x.
Streaming se expresa por
Pins slidos negros
una anotacin explcita
en los pins.
cabezas de flecha
negras, o
con modo stream en una
regin de expansin.
36
71
5 - Actividades
Pins de streaming y de excepcin
Notaciones equivalentes para pins de streaming.
Notaciones equivalentes para excepciones.
72
5 - Actividades
Excepciones
ExceptionEdge
Actividad manejador Exception
Excepcin
no tratada
37
73
5 - Actividades
Lanzar excepciones
InterruptibleActivityRegion
74
5 - Actividades
Regiones de expansin para el
procesamiento de datos por lotes
Las actividades con
frecuencia se usan para
especificar procesamiento
de colecciones de datos
(lotes) y no de unidades
individuales.
UML ofrece
ExpansionRegions para
soportar esta posibilidad.
Una regin de expansin
declara la aplicabilidad de
una actividad a toda una
coleccin de unidades de
datos.
38
75
5 - Actividades
Regiones de expansin
Una regin de expansin puede procesarse de uno
de los siguientes modos
iterativo,
concurrente,
stream.
76
5 - Actividades
Nodos estructurados
Un nodo estructurado es aquel que puede
expansionarse en nodos subordinados
Existen nodos estructurados para representar
secuencias,
bucles,
condicionales.
Sintaxis definida por el estndar
inexistente/insuficiente (y no digamos semntica).
39
77
5 - Actividades
Conclusiones
Presentan flujos de control y de datos para modelos de los
niveles de anlisis, diseo e implementacin.
Ya no son tipos especiales de StateMachine como en UML 1.x.
La semntica est inspirada en las Redes de Petri, aunque
actualmente no est del todo clara.
Introducen muchos conceptos y notaciones nuevos, entre otros
gestin de excepciones
streaming de datos
gestin de datos de colecciones
nodos estructurados
notacin de pins para flujos de datos.
En definitiva: los diagramas de actividad son ahora el lenguaje
de descripcin de algoritmos y no slo dentro del UML.
78
Part 6 Mquinas de estados
40
79
Ciclo de vida de objeto
comportamiento de objetos de acuerdo a
reglas de negocio
en particular, para clases activas
Ciclo de vida de caso de uso
integracin de escenarios de casos de uso
alternativa: diagramas de actividad
Autmata de control
sistemas embebidos
Especificacin de protocolos
interfaces de comunicacin
6 Mquinas de estados
Escenarios de uso
80
Estados y transiciones
Estado simple
disparador (en este caso un CallEvent)
guarda (Constraint)
Estado inicial
Estado final
Efecto (en este caso un CallAction)
Transicin
Las mquinas de estado modelan comportamiento
mediante estados interconectados
con transiciones disparadas
por ocurrencias de eventos.
41
81
El contexto define qu
eventos pueden
ocurrir
features estn
disponibles
Relacin con diagramas de clase
Operacin
CallEvent provocado
por la invocacin
de la operacin
Operacin llamada
por la CallAction
CallAction
Las mquinas de estado se definen en el contexto de
un BehavioredClassifier.
82
Disparadores y eventos (1)
Evento de
cambio
Evento de
tiempo
(relativo)
Evento de
complecin
(esto es, sin
disparador
explcito)
Evento de seal
Evento
diferido
42
83
CallEvent (evento de llamada)
recepcin de una llamada a una operacin sncrona / asncrona
se dispara tras ejecutarse el comportamiento de la operacin
SignalEvent (evento de seal)
recepcin de una instancia de seal asncrona
reaccin declarada mediante una Reception para la Signal
TimeEvent (evento de tiempo)
referencia absoluta a un punto del tiempo (at t)
referencia relativa a la activacin del disparo (after t)
significado presumiblemente relativo a la entrada al estado
ChangeEvent (evento de cambio)
cada vez que la condicin temporal se hace cierta
puede producirse en cierto punto tras hacerse cierta la condicin
podra revocarse si la condicin se tornase falsa
84
Evento de complecin
producido cuando terminan todas las actividades internas de un
estado
do actividad, subregin
sin elemento del metamodelo asociado
dispatched antes del resto de eventos en el pool de eventos
Eventos diferidos
Eventos que no pueden gestionarse en un estado pero debieran
guardarse en el pool de eventos
reconsiderados tras el cambio de estado
no existe poltica de deferencia predefinida
Transiciones internas
se ejecutan sin abandonar/ entrar
en el estado que las contiene
normalmente, durante la ejecucin de transiciones se abandonan/entra
en estados
43
85
6 Mquinas de estado
Comportamientos
entry Behavior
(al entrar
en el estado)
exit Behavior
(al salir
del estado)
do Behavior
(concurrentemente,
mientras la
estancia
en el estado;
puede
interrumpirse)
86
Cmo se comunican
red
Pool de eventos Pool de eventos
Comienza nuevo
paso RTC
seales: asncronas (sin espera)
llamadas: asncronas o sncronas (esperando por RTC del llamado)
Como parte de un paso
run-to-completion (RTC)
No se hacen suposiciones sobre la temporizacin entre:
la ocurrencia de eventos, dispatching de eventos, consumo de
eventos.
Pueden descartarse las ocurrencias de eventos para las que no existe
disparador (si no se han especificados como diferidos).
44
87
Estados jerrquicos (1)
Estado
compuesto
La encapsulacin del comportamiento de los estados
jerrquicos facilita el reuso.
Sin embargo, en UML 1.x raras veces se aprovecha para reuso.
UML 2.0 proporciona conceptos para dar soporte a este uso.
los puntos de entrada y salida
El disparo de transiciones se prioriza de dentro a fuera, es decir, se
consideran primero las transiciones ms profundas en la jerarqua.
88
Estados jerrquicos (2)
Estado compuesto
(no-ortogonal)
detallado
Regin
subestados
Entrada por
defecto
45
89
6 Mquinas de estado
Regiones ortogonales
regiones ortogonales,
ambas activas si el
Client/Server est
activo
Estado simple: no contiene regin alguna
Estado compuesto: contiene al menos una regin
- estado compuesto simple: exactamente una
- estado compuesto ortogonal: al menos dos
Los estados ortogonales son concurrentes ya que un nico evento puede
disparar una transicin en cada regin ortogonal simultneamente
90
Forks y joins
Pseudo-estado fork
(una transicin entrante, al menos dos salientes; las transiciones salientes
deben alcanzar estados de diferentes regiones de un estado ortogonal)
Pseudo-estado join
(restricciones duales a las
de los fork)
se puede entrar en todas
las regiones
simultneamente
se abandonan todas las
regiones simultneamente
(si se alcanzan los estados
finales)
46
91
Puntos de entrada y salida (tipo de pseudo-estado)
proporcionan mejor encapsulacin de estados compuestos
ayudan a evitar transiciones desestructuradas
6 Mquinas de estado
Puntos de entrada y salida (1)
entry
point
punto de salida (en el borde de un
diagrama de mquinas de estado o
estado compuesto)
92
6 Mquinas de estado
Puntos de entrada y salida (2)
Alternativas notacionales
Semnticamente equivalentes
Transiciones desestructuradas
47
93
Conclusiones
Las mquinas de estados modelan comportamiento
ciclos de vida de objetos y casos de uso
autmatas de control
protocolos
Las mquinas de estados constan de
regiones y
(pseudo-)estados (con actividades entry, exit y do)
conectadas mediante transiciones (con disparadores,
guardas, y efectos)
Las mquinas de estados se comunican via pools de
eventos.
Las mquinas de estados se ejecutan mediante
pasos run-to-completion.
94
Parte 7 - Interacciones
48
95
7 - Interacciones
Un primer vistazo
diagrama de
secuencias
diagrama de
comunicacin
diagrama de
temporizacin
Tres presentaciones semnticamente equivalentes (?):
96
7 - Interacciones
Escenarios de uso
Interacciones de clase/objeto
diseo/documentacin de intercambio de msj entre objetos
expresin de mensajes sncronos/asncronos, seales y
llamadas, activacin, restricciones de temporizacin
Escenarios de casos de uso
ilustracin de caso de uso con un escenario concreto
til para el diseo/documentacin de procesos de negocio
(esto es, fase de anlisis y reingeniera)
Casos de prueba
descripcin de casos de prueba en todo nivel de abstraccin
Especificacin/documentacin de temporizacin
Interaction overview
estilo ms visual para representar gran n de interacciones
definido equivalente al uso de operadores de interaccin
49
97
7 - Interacciones
Variantes sintcticas
Diagrama de secuencias
el tradicional + operadores de interaccin
focaliza en el intercambio de muchos mensajes en patrones
complejos de entre unos pocos partners de interaccin
Diagrama de comunicacin
diagrama de colaboracin en UML 1.x
focaliza en el intercambio de unos pocos mensajes entre
(muchos) partners en configuracin compleja
Diagrama de temporizacin
nuevo en UML 2.0, representacin tipo osciloscopio, tiempo
no necesariamente mtrico
focaliza en el tiempo (real) y cambios de estado coordinados
de los partners en el tiempo
Diagrama de interaction overview
parece un diagrama de actividades restringido, pero no lo es
dispone interacciones elementales para destacar su
organizacin
98
7 Interacciones simples
lnea de vida
partner de interaccin
llamada
seal asncrona respuesta
OccurrenceSpecification
o EventOccurrence
50
99
Tipos de mensajes
evento de
terminacin
mensaje no instantneo
mensajes perdidos y encontrados
(esto es, mensajes muy lentos)
evento de
instanciacin
100
Activacin
barra de
activacin
activacin
suspendida
activacin anidada
lneas de
corte
(no-UML)
evento
externo
51
101
7 - Interacciones
Uso: Escenarios de casos de uso
Las participantes en una
interaccin son actores y
sistemas (en lugar de
clases y objetos).
Pueden refinarse
sucesivamente.
til tambin para
especificar requisitos no
funcionales de alto nivel
tales como tiempos de
respuesta.
Dependiendo de las
circunstancias puede
aplicarse todo tipo de
diagramas de interaccin.
102
7 - Interacciones
Uso: Interacciones entre clases
Los participantes en una
interaccin son clases y
objetos (en lugar de actores
y sistemas).
De nuevo pueden aplicarse
sucesivos refinamientos de
diferentes maneras:
descomposicin de mensajes
descomposicin de la
estructura de los participantes
en la interaccin.
Puede aplicarse todo tipo de
diagrama de interaccin,
dependiendo de las
circunstancias.
52
103
7 - Interacciones
Uso: Interaction overview
tambin permitido:
fork/join
(se dice equivalente
a par, pero )
choice/merge,
equivalente a alt/opt
secuenciacin,
probablemente
equivalente al
operador seq
Organizan gran n de interacciones en un estilo + visual
Definidas como equivalentes al uso de operadores de
interaccin en diagramas de secuencia bsicos
104
7 - Interacciones
Interacciones complejas
Operador de
interaccin
Fragmento de
interaccin
operando de
interaccin
Una interaccin compleja es como una expresin funcional:
un InteractionOperator,
uno/varios InteractionOperands (separados por lneas discontinuas),
(y a veces tambin nmeros o conjuntos de seales).
53
105
7 Interacciones
Operadores de interaccin (visin general)
strict
secuenciamiento por operandos
seq
secuenciamiento por lnea de
vida
loop
seq repetido
par
entrelazamiento de eventos
region (crtica)
suspende el entrelazado
consider
restringe el modelo a mensajes
especificos (esto es, permite
cualquier otro mensaje en
cualquier sitio)
ignore
dual a consider
ref
macro-expansin del fragmento
alt
ejecucin alternativa
opt
ejecucin opcional
azcar sintctico para alt
break
aborta la ejecucin
a veces escrito como brk
assert
elimina incertidumbre en la
especificacin (esto es, declara
toda traza vlida)
neg
declara toda traza invlida
( semntica tri-valuada)
106
7 - Interacciones
Conclusiones
Adicin de interacciones complejas parecidas a los MSC de
alto nivel.
Nuevos tipos de diagramas:
diagramas de temporizacin (tipo osciloscopio), y
interaction overview (similar a un diagrama de actividad
restringido)
diagrama de colaboracin renombrado como diagrama de
comunicacin
Metamodelo completamente nuevo.
Semntica tri-valuada casi formal (?) con trazas de eventos
entrelazados vlidas, invlidas e inconcluyentes.
Algunos problemas semnticos an no resueltos.
54
107
Part 8 Observaciones finales
108
8 Observaciones finales
Gestin de modelos grandes
Gestionar modelos grandes es un problema en s:
gestin de versiones, diff/patch, merge
migracin entre herramientas
mantenimiento de modelos a largo plazo
round-trip (ida y vuelta) con interferencia manual
medidas, consultas, comprobaciones, anlisis de modelos
simulacin, generacin de cdigo
documentacin
Hoy en da, no se dispone de herramientas de
soporte para la mayora de estas tareas.
Es muy engorroso hacerlas a mano.
55
109
Experiencias industriales
En contra de la creencia habitual, muchos expertos del dominio
se muestran bastante comodos ante los diagramas UML, slo
del nivel de anlisis, claro.
Con UML 2, es posible captar ahora muchas cosas que antes
resultaban difciles de captar.
El soporte de las herramientas an es insuficiente, no obstante,
en parte debido a la enorme complejidad del UML.
Por ltimo: se trata de un paso hacia delante, pero an no
hemos llegado.
110
Una mirada a la bola de cristal
Es bastante probable que sobrevenga una versin UML 2.1
para tratar los problemas actualmente presentes en el UML.
Habr probablemente un UML 2.2 y un UML 2.3 tambin pero,
habr un UML 3.0?
Slo puede haber un lenguaje de modelado unificado, aunque
habr, probablemente, lenguajes de modelado ms simples.
Los lenguajes especfico de un dominio ni estn unificados ni
(usualmente) son ms simples que el UML y apenas se han
visto en ningn sitio evidencias de sus pretendidos beneficios.

2 Uml

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

2 Uml

Загружено:

Авторское право:

Доступные форматы

1

Вам также может понравиться