ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CON UML
( Parte IV )
Ing. Luis Zuloaga Rotta
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
Las transiciones entre
actividades pueden vigilarse con condiciones booleana mutuamente exclusivas. Los guardas se representan cerca de las transiciones cuyo
desencadenamiento validan.
UML define un estereotipo opcional para la visualización de las condiciones. Una
condición se materializa por un rombo de donde salen varias transiciones.
Medir la Temperatura
Calentar Enfriar
[demasiado frio] [demasiado calor]
Medir la Temperatura
Calentar Enfriar
[demasiado frio] [demasiado calor]
Barras de sincronización
Los diagramas de actividades representan las sincronizaciones entre flujos de control por medio de barras de sincronización.
Una barra de sincronización permite abrir y cerrar ramas paralelas dentro de un flujo de jecución de un método o de un caso de uso.
Las transiciones al principio de una barra de sincronización se desencadenan simultáneamente.
Enfriar el ambiente
Parar calefaccion
Ventilar
Medir la Temperatura
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.
Alumno
Docente Jurado
Enseñar
Aprender
Controlar
conocimientos Escribir
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
Iniciar un Pedido Registrarse
Facturar Hacer
un Pedido
Pagar
TOMADO
PAGADO
Entregar FACTURADO
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 CuerpoGenérico
Representan todos los tipos de elementos físicos que entran en la fabricación de las aplicaciones informáticas.
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
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 caso de las clases parametrizadas.
Representaciones gráficas de los diferentes tipos de 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
notación.
Cada cuerpo depende entonces implícitamente de su especificación.
Representaciones gráficas de los diferentes tipos de módulos.
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 dependencia se representa por una flecha punteada que apunta desde el usuario hacia el
proveedor.
La realización de dependencia permite enlazar los diferentes componentes.
Dependencias de Compilación
En un diagrama de componentes, las
relaciones de dependencia representan generalmente las dependencias de
compilación. El orden de compilación viene dado por el grafo de relaciones de dependencias.
Especificación A
Especificación B
Cuerpo A
Cuerpo B
Los Procesos y las Tareas
Las tareas corresponden a componentes que poseen su propio flujo (thread) de control.
Como en todos los elementos de modelado, la adición de
estereotipos permite precisar la 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.
Especificación Tarea
Especificación Cuerpo
Los programas principales
El nombre del programa principal es utilizado a menudo por el enlazador para dar nombre al
programa ejecutable correspondiente a la
aplicación. Esto permite, entre otras cosas, unir el modelo de componentes con el modelo de procesos.
Los puntos de entrada en las aplicaciones se identifican con el icono siguiente :
Los Subprogramas
Agrupan los
procedimientos y las funciones que no
pertenecen a ninguna clase.
Estos componentes pueden contener
declaraciones de tipos de base necesarios para la compilación de los
subprogramas. Sin
embargo nunca contienen clases.
Representaciones gráficas de las especificaciones y realizaciones de los subprogramas.
Los Subsistemas
Para facilitar la realización de
aplicaciones, los diferentes componentes pueden agruparse en paquetes según un 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.
<<Subsistema>>
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.
Relaciones de dependencia entre diferentes tipos de
componentes y subsistemas. B
Main
A
Especificación Procedimientos
INTERFACES INTERFACES
CONTROLES CONTROLES
ENTIDADES ENTIDADES MAINMAIN
Ordenes.exe
Opciones Orden
Detalle Orden
Administrador Ordenes
Administrador Transacciones Main
Orden
Item Orden
Producto Cliente
ServidorOrdenes.exe
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 equipo en el sistema. Todo sistema se describe por un pequeño número de
diagramas de despliegue; a menudo basta con un sólo diagrama.
Los diagramas de despliegue pueden mostrar clases de
nodos o instancias de nodos.
NODO
Representación gráfica de los nodos.
PC
MODEM DISCO
<<Dispositivo>> <<Procesador>> <<Memoria>>
Ejemplos de estereotipos de nodo
Dispositivos y procesadores
La distinción entre un
dispositivo y un procesador depende en gran medida del punto de vista del analista.
Un terminal X será visto como un dispositivo por el
usuario del terminal, mientras que un desarrollador lo verá como un procesador dado que actúa como servidor X al ejecutar sus tareas sobre el procesador ubicado en el terminal X.
Sistema de gestión de accesos a un edificio
IMPRESORA PC
Terminal X Servidor
SGBD
<<Procesador>>
<<Dispositivo>>
PUERTA
<<RDSI>>.
<<TCP/IP>>.
3
1
1
Consola
<<Dispositivo>>
1
*
1..10 1
Piloto.exe
Controlador
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
