ANÁLISIS Y DISEÑO ORIENTADO A
OBJETOS CON UML
( Parte IV )
Los Diagramas de Actividades
Un diagrama de actividades es una
variante de los diagramas de estados-
transiciones, organizado respecto a las
acciones.
Estan destinados a representar el
comportamiento interno de un método
(la realización de una operación) o de
un caso de uso.
Transiciones y Opciones Medir la
Temperatura
Las transiciones entre
actividades pueden vigilarse
[demasiado frio] [demasiado calor]
con condiciones booleana
mutuamente exclusivas. Los
Calentar Enfriar
guardas se representan cerca
de las transiciones cuyo
desencadenamiento validan.
Medir la
UML define un estereotipo Temperatura
opcional para la visualización
de las condiciones. Una [demasiado calor]
[demasiado frio]
condición se materializa por
un rombo de donde salen Calentar Enfriar
varias transiciones.
Barras de sincronización
Enfriar el
Los diagramas de actividades ambiente
representan las sincronizaciones
entre flujos de control por medio
de barras de sincronización.
Una barra de sincronización Parar Ventilar
permite abrir y cerrar ramas calefaccion
paralelas dentro de un flujo de
jecución de un método o de un
caso de uso.
Las transiciones al principio de Medir la
una barra de sincronización se Temperatura
desencadenan simultáneamente.
Pasillos de actividades
Los Diagramas de actividades pueden dividirse en
pasillos de actividades para mostrar las diferentes
responsabilidades dentro de un mecanismo o de una
organización.
Cada responsabilidad viene asegurada por uno o más
objetos y cada actividad se asigna a un pasillo dado.
Es posible incluir los objetos en un diagrama de
actividades, bien dentro de los pasillos, o bien
independientemente de dichos pasillos.
Los objetos se representan por barras verticales. Las
actividades aparecen objeto por objeto sobre la línea de
vida de dichos objetos.
Docente Alumno Jurado
Enseñar
Aprender
Controlar Escribir
conocimientos
Evaluar
Actividades y estados
A menudo diferentes actividades manipulan un
mismo objeto que cambia de estado según el grado
de avance del mecanismo.
En este caso los flujos de objetos se representan
por flechas punteadas. Una flecha enlaza un objeto
a la actividad que la ha creado. Asimismo una
flecha vincula un objeto a las actividades que lo
ponen en juego.
Los diagramas de actividades pueden contener
también estados y eventos representados de la
misma manera que en los diagramas estados –
transiciones.
Cliente Vendedor Expedidor
Registrarse
Iniciar
un Pedido
Hacer
un Pedido TOMADO
Facturar
FACTURADO
Pagar
Entregar
PAGADO
ENTREGADO
Los Diagramas de Componentes
Describen los elementos físicos y sus
relaciones en el entorno de realización.
Muestran las opciones de realización.
Muestran las dependencias del
compilador y del “runtime” entre los
componentes del software; por ejemplo,
los archivos del código fuente y los DLL.
Qué es un Componente ?
Es un módulo físico de código.
Los componentes pueden incluir
librerias de código fuente y “run time”
files (archivos exe, DLL’s y tareas).
Componente
Componentes e Interfaces
Los Módulos Especificación
Representan todos los tipos de elementos
físicos que entran en la fabricación de las
aplicaciones informáticas.
Cuerpo
Los módulos pueden ser simples archivos,
paquetes de lenguaje o bibliotecas de
enlace dinámico.
En principio, cada clase del modelo lógico
se realiza con dos componentes: la Genérico
especificación y el cuerpo.
La especificación contiene la interfaz de la
clase, mientras que,
El cuerpo contiene la realización de la clase.
La especificación puede ser genérica en el Representaciones gráficas
de los diferentes tipos de
caso de las clases parametrizadas. módulos.
Notación compacta
La especificación y el
cuerpo de una misma
clase pueden
superponerse en los
diagramas para hacer
más compacta la
Representaciones gráficas de los
notación. diferentes tipos de módulos.
Cada cuerpo depende
entonces implícitamente
de su especificación.
Las dependencias entre Componentes
Las relaciones de dependencia
se utilizan en los diagramas de
componentes para indicar que un
componente se refiere a los
servicios ofrecidos por otro
componente.
Este tipo de dependencia es el
reflejo de las opciones de
realización. Una relación de
La realización de dependencia permite
dependencia se representa por enlazar los diferentes componentes.
una flecha punteada que apunta
desde el usuario hacia el
proveedor.
Dependencias de Compilación
En un diagrama de Especificación A Cuerpo A
componentes, las
relaciones de dependencia
representan generalmente
las dependencias de
compilación. El orden de Especificación B Cuerpo B
compilación viene dado
por el grafo de relaciones
de dependencias.
Los Procesos y las Tareas
Las tareas corresponden a
Especificación Tarea
componentes que poseen su
propio flujo (thread) de control.
Como en todos los elementos de
modelado, la adición de
estereotipos permite precisar la
Especificación Cuerpo
semántica de un componente
dinámico.
UML predefine los estereotipos
<<Proceso>> y <<Flujo>>. Varios
flujos pueden compartir el mismo
espacio de direccionamiento
dentro de un proceso.
Los programas principales
El nombre del programa
principal es utilizado a
Los puntos de entrada en las
menudo por el enlazador aplicaciones se identifican
para dar nombre al con el icono siguiente :
programa ejecutable
correspondiente a la
aplicación. Esto permite,
entre otras cosas, unir el
modelo de componentes
con el modelo de procesos.
Los Subprogramas
Agrupan los
procedimientos y las
funciones que no
pertenecen a ninguna
clase.
Estos componentes
pueden contener
Representaciones gráficas de las
declaraciones de tipos de especificaciones y realizaciones
base necesarios para la de los subprogramas.
compilación de los
subprogramas. Sin
embargo nunca contienen
clases.
Los Subsistemas
Para facilitar la realización de
aplicaciones, los diferentes componentes
pueden agruparse en paquetes según un <<Subsistema>>
criterio lógico. A menudo son
estereotipados en subsistemas para
añadir las nociones de bibliotecas de
compilación y de gestión de configuración
a la semántica de partición ya vehiculada
por los paquetes.
Los susbsistemas cumplen para los
componentes la misma función que las
categorías para las clases.
La Descomposición en Sub Sistemas
Los subsistemas organizan la vista de realización de un
sistema; cada subsistema puede contener componentes y
otros subsistemas.
Por convención, todo componente del modelo se coloca
bien en la raiz o bien en un subsistema.
La descomposición en subsistemas no es una
descomposición funcional. Las funciones del sistema se
expresan desde el punto de vista del usuario en la vista de
los casos de uso.
Los objetos que realizan las interacciones se distribuyen en
las diferentes categorías; el código correspondiente se
almacena en módulos y subsistemas.
Especificación
Procedimientos
Main
Relaciones de dependencia
entre diferentes tipos de
componentes y subsistemas. B
MAIN
Main
[Link]
ENTIDADES Detalle
INTERFACES
Orden
Opciones
Orden
CONTROLES
[Link]
Administrador
Transacciones
Administrador
Ordenes
Orden
Item
Orden
Cliente
Producto
Los Diagramas de Despliegue
Muestran la disposición fisica de los
distintos dispositivos (nodos) que entran
en la composición de un sistema y el
reparto de los programas ejecutables
sobre estos nodos.
Muestran la configuración de los nodos
de procesamiento “run time” y los
componentes que residen sobre ellos.
Representación de los nodos.
Cada dispositivo o recurso se
representa por un cubo que
evoca la presencia física del NODO
equipo en el sistema. Todo
sistema se describe por un Representación gráfica de los nodos.
pequeño número de
diagramas de despliegue; a
menudo basta con un sólo
diagrama. MODEM PC DISCO
Los diagramas de despliegue <<Dispositivo>> <<Procesador>> <<Memoria>>
pueden mostrar clases de
nodos o instancias de nodos. Ejemplos de estereotipos de nodo
Dispositivos y procesadores
La distinción entre un
dispositivo y un procesador Terminal X <<TCP/IP>>.
Consola
Servidor
3 SGBD
depende en gran medida del <<Procesador>>
punto de vista del analista. 1
1
Un terminal X será visto PC <<RDSI>>.
como un dispositivo por el [Link] *
usuario del terminal, mientras 1 Controlador
IMPRESORA
que un desarrollador lo verá <<Dispositivo>>
como un procesador dado 1
que actúa como servidor X al
ejecutar sus tareas sobre el 1..10 PUERTA
procesador ubicado en el
terminal X.
Sistema de gestión de accesos a un edificio
Usos Comunes
Se utilizan para modelar la vista estática de un
sistema. Esta vista direcciona primariamente la
distribución, suministros e instalación de las partes
que constituyen el sistema físico.
Si usted esta desarrollando una pieza de software
que residirá sobre una máquina y sólo interfaces
con dispositivos estándar sobre esta máquina que
son siempre administrados por elsistema operativo
(teclado, monitor y modem), usted puede ignorar
los diagramas de despliegue.
Tres formas de Uso
Para modelar sistemas embebidos
Involucran software que controlan dispositivos tales como
motores, actuadores, y monitores, y que en su momento, es
controlado por un estimulo externo tal como sensores de
entrada, movimiento y cambios en la temperatura.
Para modelar sistemas cliente servidor
Es una arquitectura centrada en hacer una clara separación
entre las interfaces de usuario del sistema (residente en el
cliente) y la data persistente del sistema (residente en el
servidor).
Para modelar sistemas distribuidos
Son frecuentemente hosts de múltiples versiones de
componentes de software, algunos de los cuales pueden incluso
migrar de un nodo a otro
Componentes y Nodos
