Documentos de Académico
Documentos de Profesional
Documentos de Cultura
12anexo 1 UML
12anexo 1 UML
la introduccin de ambigedad
Anexo 1
245
247
Elementos
248
Elementos estructurales
248
Elementos de comportamiento
251
Elementos de agrupacin
252
Elementos de anotacin
252
Relaciones
253
Diagramas
255
258
Diagrama de clases
267
Diagrama de objetos
275
Diagrama de secuencias
276
Diagrama de colaboracin
278
Diagrama de estados
280
Diagrama de actividades
286
Diagrama de componentes
290
Diagrama de despliegue
292
Paquetes
294
246
UML es una gramtica para expresar diseos de software orientado a objetos. Sus siglas
significan, en espaol, Lenguaje Unificado de Modelado. No es la nica notacin
que existe, pero es el estndar actual del llamado Object Management Group
(OMG). Por tanto, conviene saber cmo expresarse en este lenguaje, advirtiendo
que los lenguajes son dinmicos y que, a veces, no se utilizan de la misma forma
por diferentes autores. Nosotros aprovecharemos UML para profundizar en los
conceptos del software orientado a objetos.
247
Elementos
Hay cuatro tipos de elementos en UML
Elementos estructurales.
Elementos de comportamiento.
Elementos de agrupacin.
Elementos de anotacin.
Elementos estructurales
Los elementos estructurales son la parte esttica de los modelos de UML. Representan
cosas que son conceptuales o materiales. Hay siete tipos de elementos estructurales:
clases, interfaces, colaboraciones, casos de uso, clases activas, componentes y nodos.
Clases: una clase es una descripcin de un conjunto de objetos que comparten los
mismos atributos, operaciones, relaciones y semntica. Grficamente una clase
se representa como un rectngulo, dividido en tres zonas que contienen el
nombre, los atributos y las operaciones.
Nombre Clase
-atributos
+operaciones()
NombreInterfaz
248
Nombre
colaboracin
Clase activa: una clase activa es una clase cuyos objetos tienen uno o ms procesos o
hilos de ejecucin y, por lo tanto, pueden dar origen a actividades de control. Los
objetos de una clase activa representan elementos cuyo comportamiento es concurrente
con otros elementos. Grficamente una clase activa se representa como una clase pero
con lneas ms gruesas.
Nombre clase
- atributos
+operaciones
249
componente
Nodo
250
Elementos de comportamiento
Los elementos de comportamiento son las partes dinmicas de los modelos. Representan
comportamiento en el tiempo y en el espacio. Hay dos tipos de elementos de
comportamiento: interacciones y mquinas de estados.
Interacciones: una interaccin es un comportamiento que comprende un conjunto de
mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular
para alcanzar un propsito especfico. El comportamiento de una sociedad de objetos o
una operacin individual puede especificarse mediante una interaccin. Una interaccin
involucra
otros
elementos,
incluyendo
mensajes,
secuencias
de
accin
(el
operacin()
Mquinas de estados: una mquina de estados especifica las secuencias de estados por
las que pasa un objeto o una interaccin durante su vida en respuesta a eventos. El
comportamiento de una clase individual o una colaboracin de clases puede
especificarse con una mquina de estados. Una mquina de estados involucra otros
elementos, incluyendo estados, transiciones (el flujo de un estado a otro), eventos (que
disparan una transicin) y actividades (la respuesta a una transicin). Grficamente un
estado se representa como un rectngulo de esquinas redondeadas, incluyendo su
nombre y sus subestados si los tiene.
estado
251
Elementos de agrupacin
Los elementos de agrupacin son las partes organizativas de los modelos de UML, es
decir, las cajas en las que puede descomponerse un modelo. Slo hay un elemento de
agrupacin: el paquete.
Paquetes: un paquete es un mecanismo de propsito general para organizar los
elementos en grupos. Los paquetes son puramente conceptuales, slo existen en tiempo
de desarrollo. Un paquete puede contener elementos estructurales, elementos de
comportamiento e incluso otros paquetes. Grficamente un paquete se representa como
una carpeta.
Paquete
Elementos de anotacin
Los elementos de anotacin son la parte explicativa de los modelos de UML. Son
comentarios que se pueden aplicar para describir, clarificar y hacer observaciones sobre
cualquier elemento de un modelo. El principal elemento de anotacin es la nota.
Notas: una nota es simplemente un smbolo para mostrar restricciones y comentarios
junto a un elemento o una coleccin de elementos. Grficamente una nota se representa
como un rectngulo con la esquina doblada.
Comentario
252
Relaciones
Asociacin
Una asociacin es una relacin estructural que describe un conjunto de enlaces, los
cuales son conexiones entre objetos. La agregacin es un tipo especial de asociacin,
que representa una relacin estructural entre un todo y sus partes. Grficamente, una
asociacin se representa como una lnea continua, posiblemente dirigida, que a veces
incluye una etiqueta, y a menudo incluye otros adornos, como la multiplicidad y los
nombres de rol. La agregacin se representa mediante un rombo situado en la parte del
todo.
Asociaciones y agregaciones
Generalizacin
253
Realizacin
Una realizacin es una relacin semntica entre clasificadores, en donde un clasificador
especifica un contrato que otro clasificador garantiza que cumplir. Se pueden encontrar
relaciones de realizacin en dos sitios: entre interfaces y las clases y componentes que
las realizan, y entre los casos de uso y las colaboraciones que los realizan.
Grficamente, una relacin de realizacin se representa como una lnea discontinua con
una punta de flecha vaca.
254
Diagramas
Un diagrama es la representacin grfica de un conjunto de elementos, en general
visualizado como un grafo conexo de nodos (elementos) y arcos (relaciones). Los
diagramas se dibujan para visualizar un sistema desde diferentes perspectivas, de forma
que un diagrama es una proyeccin de un sistema. Para todos los sistemas, excepto los
ms triviales, un diagrama representa una vista resumida de los elementos que
constituyen un sistema. En teora, un diagrama puede contener cualquier combinacin
de elementos y relaciones. En la prctica, sin embargo, slo surge un pequeo nmero
de combinaciones, las cuales son consistentes con las vista ms tiles que comprenden
la arquitectura de un sistema con gran cantidad de software. Por esta razn, UML
incluye nueve de estos diagramas:
1. Diagrama de casos de uso.
2. Diagrama de clases.
3. Diagrama de objetos.
4. Diagrama de secuencias.
5. Diagrama de colaboracin.
6. Diagrama de estados.
7. Diagrama de actividades.
8. Diagrama de componentes.
9. Diagrama de despliegue.
255
Mecanismos de extensibilidad
UML proporciona un lenguaje estndar para escribir planos software, pero no es posible
que un lenguaje cerrado sea siempre suficiente para expresar todos los matices posibles
de todos los modelos en todos los dominios y en todos los momentos. Por esta razn,
UML proporciona tres mecanismos para extender el lenguaje de manera controlada.
Estos mecanismos permiten configurar y extender UML a las necesidades de un
proyecto y adaptarse a nuevas tecnologas de software. Los mecanismos de extensin de
UML son:
Estereotipos.
Valores etiquetados.
Restricciones.
Estereotipos
256
Valores etiquetados
ColaEventos
{versin = 3.2,
autor = ABC}
aadir( )
quitar( )
vaciar( )
Valores etiquetados
Restricciones
{ordenado}
257
Casos de Uso
Los casos de uso son una tcnica de modelizacin de requisitos funcionales que facilitan
la comunicacin entre los desarrolladores, los clientes y los usuarios finales del sistema.
Su lenguaje sencillo es comprensible por todos los implicados en el proceso de
desarrollo de un sistema software.
Los casos de uso, en su conjunto, describen los distintos usos que se le quiere dar al
sistema. Por ejemplo, extraer dinero, ingresar dinero y consultar saldo, en un cajero
automtico. Cada uno de ellos constituye un Caso de Uso.
Ingresar Dinero
Cliente
258
Consultar Saldo
En el diagrama de casos de uso, se delimitan las fronteras del sistema mediante una
caja. Los elementos que queden fuera de la caja forman parte del entorno. Sus roles, es
decir, los actores nunca son parte del sistema, aunque interacten con l.
Los actores y los casos de uso se relacionan mediante asociaciones. Una relacin de
asociacin entre un actor y un caso de uso indica que existe comunicacin entre ellos y
que pueden intercambiar informacin en ambos sentidos.
Es posible que el nmero de casos de uso que necesitemos para modelar un sistema sea
demasiado grande para mostrarse en un nico diagrama sin perder visibilidad y
comprensibilidad. En ese caso, el diagrama se puede organizar agrupando los casos de
uso en paquetes.
Actores
Los actores, como se mencion, representan los distintos roles que los elementos del
entorno desempean respecto al sistema. Un actor representa a todos los elementos que
desempean el mismo rol. En el ejemplo del cajero automtico, el actor Cliente
representa a todos los clientes del banco que pueden utilizar el cajero.
Un mismo elemento puede desempear varios roles distintos, es decir, un elemento
puede actuar como distintos actores en funcin del uso del sistema en cada momento. Es
importante observar que los caso de uso estn asociados con los actores, y no con los
elementos concretos.
Supongamos por ejemplo, que los empleados del banco pueden utilizar el sistema
software del cajero para consultar su estado y realizar estadsticas sobre su uso.
Tendramos entonces un nuevo actor del sistema, Empleado, relacionado con dos
nuevos casos de uso, Consultar Estado y Realizar Estadsticas. Si los empleados del
banco son adems clientes del banco, podran tambin utilizar el cajero como el resto de
los clientes, para sacar o ingresar dinero y consultar sus cuentas. Esto quiere decir que
259
los empleados del banco actuarn unas veces como el actor Empleado y otras como el
actor Cliente. Pero, no implica que el actor Empleado est relacionado con los casos de
uso Extraer Dinero, Ingresar Dinero y Consultar Saldo.
261
Actores: Cliente.
Precondiciones: Ninguna
Postcondiciones:
En caso de xito: el cliente obtiene la cantidad de dinero que ha
solicitado, la operacin queda registrada y su saldo actualizado.
En caso de fallo:
Si el cliente introduce un nmero de PIN errneo tres veces, su tarjeta
queda invalidada.
Si el cliente cancela la operacin no hay ninguna postcondicin.
Flujo de Eventos Principal:
1. El cliente introduce la tarjeta en el cajero.
2. El cajero solicita el nmero de PIN.
3. El cliente introduce el nmero de PIN.
4. El cajero comprueba el nmero de PIN
5. Si el PIN es correcto, el cajero solicita la cantidad a retirar.
6. El cliente introduce la cantidad a retirar.
7. El cajero comprueba si el cliente dispone de esa cantidad en su cuenta
y si hay suficiente dinero en el cajero.
8. Si el cliente dispone de esa cantidad y el cajero tiene suficiente
dinero, el cajero actualiza la cuenta del cliente, registra la operacin,
le entrega la tarjeta y el dinero al cliente y acaba el caso de uso.
Flujos de Eventos Alternativos:
3.a.
5.a.
5.b.
6.a.
8.a
Los casos de uso pueden organizarse mediante las relaciones de uso (o inclusin),
extensin y generalizacin entre ellos.
Uso
Esta relacin significa que un caso de uso, llamado base, incorpora explcitamente el
comportamiento de otro caso de uso. El caso de uso incorporado nunca se encuentra
aislado. Es instanciado slo como parte de algn caso de uso base que lo utiliza. La
relacin de uso se representa como una dependencia estereotipada con la etiqueta
<<usa>>.
263
Cajero Automtico
Extraer Dinero
uses
uses
Validar Usuario
Ingresar Dinero
uses
Cliente
Consultar Saldo
Extensin
La relacin de extensin se utiliza para modelar la parte de un caso de uso que puede
considerarse como un comportamiento opcional. De esta forma se separa el
comportamiento opcional del obligatorio. Esta relacin se representa como una
dependencia estereotipada como <<extiende>>.
extends
Caso Base
Extensin
Los puntos de extensin pueden indicarse en el diagrama con una etiqueta en la relacin
de extensin, indicando en el flujo de eventos del caso base la localizacin del punto de
extensin.
Generalizacin
La relacin de generalizacin entre casos de uso es como la generalizacin entre clases.
Significa que el caso de uso hijo hereda el comportamiento y el significado del caso de
uso padre. El hijo puede aadir o redefinir el comportamiento del padre y puede ser
colocado en cualquier lugar donde aparezca el padre.
Supongamos que el cajero automtico pudiese validar al cliente de dos formas distintas:
comprobando el PIN de la tarjeta o examinando la retina. El caso de uso padre Validar
Usuario podra tener dos casos de uso hijos especializados Comprobar PIN y Examinar
Retina.
La relacin de generalizacin se representa igual que la generalizacin entre clases, con
una lnea continua con la punta de flecha vaca.
Caso General
Caso Especfico
265
Los actores slo pueden tener entre ellos relaciones de generalizacin. Se pueden definir
categoras generales de actores y especializarlos mediante relaciones de especializacin.
La relacin de generalizacin entre actores se representa igual que la generalizacin
entre clases y entre casos de uso, con una lnea continua con la punta de flecha vaca.
Actor General
Actor Especfico
266
Diagrama de clases
Un diagrama de clases muestra las clases que componen el sistema y las relaciones que
existen entre ellos. Este diagrama se utiliza para modelar la vista de diseo estructural
de un sistema. Los diagramas de clases adems, pueden contener paquetes.
Clases
Nombre Clase
Nombre Clase
-atributos
+operaciones()
Para especificar que una clase es abstracta, es decir que contiene al menos una
operacin abstracta, se escribe el nombre de la clase en cursiva.
El nmero de instancias que pueden crearse de una clase es su multiplicidad.
Generalmente la multiplicidad de una clase es ilimitada, en un sistema suele haber
muchas instancias u objetos de una clase ejecutndose. Sin embargo, a veces es
necesario restringir a un nmero determinado el nmero de instancias de una clase. En
estos casos, la multiplicidad se escribe en la esquina superior derecha de la clase.
UML permite especificar dos caractersticas importantes de los elementos (atributos y
operaciones) de una clase: la visibilidad y el alcance.
267
Visibilidad: los elementos de una clase pueden ser pblicos, protegidos o privados.
Los elementos pblicos son visibles para los objetos de todas las clases del
sistema. Un elemento pblico va precedido del signo +.
Los elementos protegidos slo son visibles dentro de la clase y de las clases
hijas. Un elemento protegido va precedido del signo #.
Clase: slo hay un valor del elemento para todas las instancias de la clase. (El
alcance de clase es equivalente al uso de static en C++ y Java). Para indicar
que un elemento tiene alcance de clase se subraya.
Atributos
La sintaxis de un atributo en UML es:
[visibilidad] nombre [multiplicidad] [:tipo] [= valor inicial] [{propiedades}]
La visibilidad, como se explic anteriormente, indica si el atributo es pblico, protegido
o privado.
La multiplicidad de un atributo es el nmero de instancias del atributo que se pueden
crear. Se especifica mediante una expresin encerrada entre corchetes. Por ejemplo:
impresora [1..5]: Impresora
indica que pueden existir de 1 a 5 instancias del atributo impresora. La multiplicidad
suele utilizarse para especificar vectores de atributos.
268
Operaciones
La sintaxis de una operacin en UML es:
[visibilidad] nombre [(lista de parmetros)] [:tipo de retorno] [{propiedades}]
La visibilidad indica si la operacin es pblica, protegida o privada.
Para especificar que una operacin es abstracta se escribe el nombre en cursiva. Una
operacin abstracta no tiene implementacin, slo tiene cabecera. La implementacin la
proporcionan las clases hijas redefiniendo la operacin.
La sintaxis de un parmetro es:
[direccin] nombre [:tipo] [= valor por omisin]
La direccin de un parmetro puede tomar tres valores:
269
Relaciones
Una clase puede tener una relacin consigo misma, indicando que los objetos de esa
clase estn conectados entre s.
Las relaciones se dibujan con una lnea, empleando un tipo distinto de lnea para cada
tipo de relacin o un smbolo especfico.
Dependencia
Cuando objetos de una clase utilizan objetos de otra clase existe una relacin de
dependencia entre sus clases respectivas. Esta relacin se representa en el diagrama de
clases con una flecha discontinua en el sentido del elemento que se usa. Las clases,
cuyos objetos usan los de otra clase, dependen de la especificacin de la clase usada. Si
cambia la especificacin, habr que hacer cambios en las clases que la usan.
270
Las dependencias generalmente se utilizan para indicar que una clase utiliza a otra como
argumento en alguna operacin o sus objetos utilizan alguna de las operaciones de la
otra clase.
LectorTarjeta
Tarjeta
Se puede poner nombre a las dependencias para mejorar la comprensin del diagrama,
pero generalmente no es necesario.
Asociacin
Una asociacin es una relacin estructural. Esta relacin expresa que se puede navegar
desde los objetos de una clase hasta los objetos de la otra clase. La asociacin se
representa con una lnea continua.
Cliente
Persona
Las asociaciones se suelen emplear para indicar que una clase contiene un atributo de la
otra clase. En UML se puede especificar el nombre de una asociacin, el rol de cada
clase y su multiplicidad o cardinalidad.
Clave
Usuario
conceptualmente ninguna de las clases tiene ms importancia que otra. Sin embargo, a
veces conviene destacar que una de las clases es un todo del que la otra clase forma
parte. A esta relacin todo/partes se le llama agregacin simple. Grficamente se
representa con un rombo vaco en el extremo de la clase todo.
Biblioteca
Libro
Libro
Estado Libro
Generalizacin
La generalizacin o herencia expresa una relacin entre una clase genrica y una o
varias clases especficas. A la clase genrica se le llama clase madre y a las clases
especficas hijas. La generalizacin indica que las hijas heredan los atributos,
operaciones y relaciones de la clase madre (slo se heredarn los elementos que sean
pblicos o protegidos). Las hijas pueden redefinir los elementos que heredan del padre y
aadir sus propios atributos, operaciones y relaciones. Grficamente, la generalizacin
se representa con una lnea continua acabada en una punta de flecha vaca.
272
Figura
#color
+dibujar()
+borrar()
Rectngulo
Circulo
-punto1
-punto2
+dibujar()
-centro
-radio
+dibujar()
Triangulo
-punto1
-punto2
-punto3
+dibujar()
UML permite especificar herencias mltiples, es decir que una clase herede el
comportamiento de varias clases madre. Pero, hay que tener cuidado con el uso de la
herencia mltiple. Afortunadamente no todos los lenguajes permiten su implementacin.
Interfaces y realizaciones
A las clases abstractas puras, es decir, a las clases que no contienen ninguna
implementacin, se les llama interfaces.
En UML una interfaz es una coleccin de operaciones que sirven para especificar los
servicios de una clase o un componente. Una interfaz slo contiene las cabeceras de las
operaciones, no su implementacin. (Una interfaz de UML se corresponde con una clase
virtual pura de C++ y con una interface de Java). Grficamente una interfaz se puede
representar de forma expandida como una clase estereotipada con la etiqueta
<<interface>> o, en su forma abreviada, con una figura en forma de piruleta.
interface
NombreInterfaz
NombreInterfaz
273
En los diagramas de clases se suele utilizar la forma expandida para representar las
interfaces. La forma abreviada generalmente se usa en los diagramas de componentes.
Hay dos relaciones que pueden existir entre una clase y una interfaz: la dependencia y la
realizacin.
La dependencia entre una clase y una interfaz tiene el mismo significado y
representacin que entre dos clases, indica que la clase usa la interfaz.
Para que una interfaz se pueda usar hace falta que otra clase implemente las operaciones
que la interfaz especifica. A esta relacin entre la interfaz y la clase que la implementa
se le llama realizacin. La realizacin indica que la clase implementa todas las
operaciones de la interfaz. Grficamente la realizacin se representa como una
generalizacin con la lnea discontinua.
Objetivo
-id
-posicionActual
+establecerPosicin()
+establecerVelocidad()
+posicinEsperada()
interface
Observador
+actualizar()
RastreadorDeObjetivo
+actualizar()
274
Diagrama de objetos
c : Compaa
d1 : Departamento
d2 : Departamento
p : Persona
nombre : String = "Francisco"
ID_Empleado : unsigned long(idl) = 3421
cargo : String = "Director de Ventas"
Los diagramas de objetos pueden contener paquetes y, cuando se quiere mostrar la clase
que hay detrs de cada instancia, tambin pueden contener clases.
275
Diagramas de interaccin
Diagrama de secuencias
276
c:Cliente
p:ProxyODBC
<<create>>()
:Transaccion
establecerAcciones(a, d, o)
estableceValores(d, 3.4)
estableceValores(a, "CO")
xito()
destroy()
Los objetos que participan en la interaccin se dibujan en la parte superior del diagrama
horizontalmente. Los objetos se representan igual que las clases pero con el nombre
subrayado.
Debajo de cada objeto se dibuja una lnea vertical discontinua llamada lnea de vida.
Esta lnea indica el tiempo de existencia del objeto.
Los mensajes se representan con una flecha desde la lnea de vida del objeto que enva
el mensaje haca la lnea de vida del objeto que lo recibe. La etiqueta de la flecha indica
la operacin del objeto receptor que se invoca, incluyendo los parmetros. Si la
operacin devuelve algn valor se dibuja una flecha discontinua apuntando hacia el
objeto emisor, etiquetada con el nombre del valor de retorno.
Generalmente, los objetos que participan en una interaccin existen durante todo el
tiempo que dura dicha interaccin. Siendo as, los objetos se sitan en la parte superior
y sus lneas de vida se prolongan a lo largo de todo del diagrama. Sin embargo, tambin
pueden crearse y destruirse objetos durante la interaccin. La creacin y la destruccin
de un objeto se indican mediante mensajes estereotipados con <<create>> y
277
278
c:Cliente
1: <<create>>
2: establecerAcciones(a,d,o)
3: <<destroy>>
p:ProxyODBC
:Transaccion
2.1: establecerValores(d,3.4)
2.2: establecerValores(a,"CO")
Los mensajes se escriben junto a los enlaces, indicando el sentido con una flecha que
apunta hacia al objeto receptor y numerndolos para expresar el orden temporal. Se
pueden representar mensajes anidados utilizando la numeracin decimal de Dewey (1 es
el primer mensaje, 1.1 es el primer mensaje dentro del mensaje 1, 1.2 es el segundo
mensaje dentro del mensaje 1,...)
Las iteraciones se representan anteponiendo al nmero del mensaje el smbolo *.
Opcionalmente, se puede aadir una expresin que indique hasta cuando se repite la
iteracin.
Para modelar una bifurcacin, el nmero de secuencia del mensaje se precede de una
clusula de condicin. Los caminos alternativos de una bifurcacin tendrn el mismo
nmero de secuencia. Pero, cada camino debe ser distinguible de forma nica por una
condicin que no se solape con las otras.
279
Diagrama de estados
En UML los diagramas de estados se utilizan para modelar el comportamiento de un
objeto dirigido por eventos. Aunque tambin pueden utilizarse para mostrar el
comportamiento del sistema global o de subsistemas.
Un diagrama de estados modela la vida de un objeto mediante una mquina de estados.
Cada estado representa una situacin durante la cual el objeto satisface alguna
condicin, realiza alguna actividad o espera algn evento. Los estados se dibujan con
una caja con las esquinas redondeadas.
Se pueden definir dos estados especiales:
Las transiciones entre estados se dibujan con una flecha continua desde el estado origen
al estado destino. En cada transicin se puede especificar:
A las transiciones en las cuales el estado origen y el destino son el mismo se les llama
autotransiciones.
estado inicial
agotado(producto)/renovarStock(producto)
evento
autotransicin
Procesar Pedido
estado final
guarda
Esperando
**Fig
accin
estado
transicin
Confirmar Crdito
rechazado
Cancelar Pedido
Caractersticas Avanzadas
Utilizando solamente las caractersticas bsicas de los estados y las transiciones se
puede modelar la mayora de los comportamientos de los objetos. Sin embargo, las
281
mquinas de estados de UML tienen varias caractersticas avanzadas que pueden ayudar
a modelar comportamientos complejos.
En UML los estados pueden incluir:
282
Rastreando
accin de entrada
accin de salida
transicin interna
actividad
evento diferido
entry/activarModo(enRastreo)
exit/activarModo(noRastreo)
nuevoObjetivo/rastreador.Adquirir( )
do/seguirObjetivo
autoTest/defer
Adems, en UML los estados de una mquina pueden contener subestados o estados
anidados. A un estado que contiene subestados se le llama estado compuesto. Los
estados compuestos se representan igual que los simples, pero contienen en su interior
una mquina de estados que describe el flujo de control entre los subestados.
Las transiciones de entrada a un estado compuesto pueden activar el propio estado
compuesto o uno de sus subestados. Para activar el estado compuesto es necesario que
la mquina de subestados tenga definido un estado inicial. En tal caso, cuando se
dispara una transicin de entrada al estado compuesto, se ejecuta la accin de entrada y
el flujo de control pasa al subestado inicial. Si no se define un subestado inicial, las
transiciones de entrada deben dirigirse a los subestados y no al estado compuesto.
Cuando se dispara una transicin de entrada a un subestado, primero se ejecuta la accin
de entrada del estado compuesto, a continuacin el flujo de control pasa al subestado y
se ejecuta su accin de entrada.
Las transiciones de salida pueden tener como origen el estado compuesto o un
subestado. Si el origen es un subestado, cuando se dispara la transicin se ejecuta
primero la accin de salida del subestado, a continuacin la accin del estado
compuesto y por ltimo la accin asociada a la transicin. Si el origen de la transicin
de salida es el estado compuesto, cuando se dispara la transicin se interrumpe la
ejecucin de la mquina anidada; ejecutndose primero la accin de salida del subestado
que tuviese el control en ese momento, despus la del estado compuesto y por ltimo la
accin asociada a la transicin.
283
estado compuesto
Inactivo
llamada
Recibiendo
colgar
cabeceraOK
enviar
Procesando
Conectado
verificacinOK
Transmisin
Limpiando
subestado
entry/ descolgar
exit/ desconectar
Cada vez que se dispara una transicin de entrada a un estado compuesto, la mquina de
estados anidada comienza de nuevo su ejecucin en el estado inicial. Sin embargo, en
algunas ocasiones puede resultar til que la mquina recuerde el ltimo estado en el que
se encontraba y comience su ejecucin desde ese estado. Para modelar este tipo de
comportamiento UML introduce los estados de historia. Un estado de historia se
representa con un crculo con el smbolo H.
estado de historia
CopiaDeSeguridad
H
Orden
Recoger
consulta
Copiar
transicin inicial
Limpiar
El estado de historia debe tener una nica transicin de salida hacia otro subestado. La
primera vez que se activa el estado compuesto, an no hay historia, y se ejecuta esta
transicin. Si se dispara una transicin de salida, el estado de historia recordar el
ltimo estado que estaba ejecutndose en la mquina antes de salir del estado
compuesto. A partir de ese momento ya hay historia. Cuando se produzca una nueva
transicin de entrada el control pasar al ltimo estado activo.
284
divisin
Inactivo
unin
Subestados
concurrentes
mantener
Mantenimiento
Pruebas
Probar
perifricos
ManejoOrdenes
Espera
Autodiagnosis
teclaPulsada
[continuar]
[no continuar]
Orden
285
Diagrama de actividades
Los diagramas de actividades de UML son similares a los diagramas de flujo
tradicionales. Generalmente se utilizan para modelar flujos de trabajo o para describir
detalladamente una operacin.
En UML los diagramas de actividades son un caso particular de los diagramas de estado
que muestran un flujo de control. En estos diagramas los estados representan
actividades o acciones. Una accin es una operacin atmica indivisible que no puede
ser interrumpida durante su ejecucin. Una actividad es una operacin no atmica que
puede descomponerse en otras actividades o acciones y que puede ser interrumpida
durante su ejecucin. Grficamente no hay ninguna diferencia entre un estado de
actividad y un estado de accin, ambos se representan con una caja de bordes
redondeados.
Para indicar el estado inicial y final de la actividad global se utilizan los mismos
smbolos que en los diagramas de estado: un crculo negro para el estado inicial y un
crculo negro dentro de un crculo blanco para el estado final.
Cuando se completa la actividad o la accin de un estado, el flujo de control pasa
inmediatamente al estado siguiente. La transicin de un estado a otro se indica con una
flecha continua.
Como en un cualquier diagrama de flujo se pueden especificar bifurcaciones
dibujndolas con un rombo. Una bifurcacin tiene una transicin de entrada y dos o ms
transiciones de salida. En cada transicin de salida se escribe una expresin entre
corchetes, llamada guarda, que indica las condiciones bajo las que se sigue esa
transicin. Las guardas deben cubrir todas las condiciones posibles de salida para que el
flujo de control no se interrumpa en ningn caso. Pero, para evitar ambigedades en el
flujo de control, las guardas no deben solaparse.
286
Establecer pedido
[pedido nico]
[suscripcin]
Cargar a la cuenta
287
Solicitar producto
Procesar pedido
Extraer artculos
Enviar Pedido
Recibir pedido
Facturar al cliente
Pagar factura
Cerrar pedido
288
Cliente
Ventas
Almacn
Solicitar producto
Procesar pedido
Extraer artculos
o:Pedido
[en progreso]
Enviar pedido
o:Pedido
[completado]
RecibirPedido
Pagar Factura
b:Factura
[pagada]
Facturar al cliente
b:Factura
[impagada]
Cerrar pedido
289
Diagrama de componentes
En UML los componentes representan elemento fsicos del sistema, por ejemplo
ejecutables, pginas HTML, libreras, tablas, ficheros, etc. Grficamente, un
componente se dibuja mediante una caja con pestaas.
Componente
interface
ObservadorDeImagen
+actualizarImagen()
imagen.java
componente.java
Figura 1.
290
imagen.java
Observador
De Imagen
componente.java
Figura 2.
UML define cinco estereotipos estndar aplicables a los componentes:
find.html
index.html
find.exe
291
Diagrama de despliegue
Los diagramas de despliegue modelan la topologa del hardware sobre el que se ejecuta
el sistema software. Este tipo de diagramas suele utilizarse para modelar sistemas
distribuidos o sistemas empotrados. En los sistemas monolticos, generalmente, resultan
innecesarios.
Un diagrama de despliegue muestra la configuracin de los nodos del sistema. En UML,
un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso
computacional que, generalmente, tiene alguna memoria y, a menudo, capacidad de
procesamiento. Habitualmente los nodos representan procesadores y dispositivos
hardware.
Grficamente, un nodo se dibuja como un cubo. Las conexiones fsicas entre los nodos
se representan mediante relaciones de asociacin.
terminal
servidor
unidad
RAID
consola
Figura 1
Los diagramas de despliegue pueden contener paquetes para organizar los nodos.
Cuando se modela la topologa de los sistemas distribuidos y empotrados, es importante
especificar la distribucin fsica de los componentes software sobre los nodos. A
menudo, resulta til visualizar esta distribucin en el diagrama de despliegue. Para ello,
UML proporciona dos alternativas:
292
terminal
Despliega
user.exe
servidor
unidad RAID
Despliega
dbadmin.exe
consola
Despliega
admin.exe
config.exe
Figura 2.
user.exe
terminal
servidor
admin.exe
consola
dbadmin.exe
config.exe
Figura 3.
293
unidad
RAID
Paquetes
Un paquete es un mecanismo de propsito general para organizar elementos en grupos.
Grficamente se representa como una carpeta.
<<Nombre >>
Los paquetes se utilizan para organizar los elementos de los diagramas en grupos a los
que se puede dar un nombre y manejar como un conjunto.
Si estamos desarrollando una aplicacin trivial, probablemente podremos representar
todo el sistema en un diagrama que contenga unos cuantos elementos y resulte fcil de
entender e interpretar. Pero, en un sistema complejo, el nmero de elementos y de
relaciones necesarias para modelar el sistema completo puede exceder la capacidad
humana de comprensin. Por esta razn se agrupan los elementos en paquetes y el
contenido de cada paquete se muestra en un diagrama distinto.
Los paquetes pueden tener relaciones de dependencia y generalizacin. La relacin de
dependencia indica que los elementos de un paquete utilizan o importan los elementos
del paquete del que dependen. La generalizacin entre paquetes es similar a la
generalizacin entre clases, los paquetes hijos heredan los elementos del paquete padre.
La generalizacin entre paquetes suele utilizarse para especificar familias de paquetes.
Existen dos estereotipos de la relacin de dependencia entre paquetes, <<import>> y
<<access>>. Ambos especifican que el paquete origen tiene acceso a los elementos del
paquete destino. La diferencia es que <<import>> aade al espacio de nombres del
origen el contenido del destino, evitando la calificacin de nombres.
294
Aplicacion
IGU
IGU Windows
IGU Mac
Protegido: slo es visible dentro del paquete que lo contiene y de sus hijos.
295
296