ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CON UML

( Parte IV )

Ing. Luis Zuloaga Rotta

Los Diagramas de ActividadesUn 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 OpcionesLas 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ónLos 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 actividadesLos 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.

AlumnoDocente Jurado

Enseñar

Aprender

Controlar conocimientos

Escribir

Evaluar

Actividades y estadosA 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

Iniciarun Pedido

Registrarse

Facturar

Hacerun Pedido

Pagar

TOMADO

PAGADOEntregar

FACTURADO

ENTREGADO

Los Diagramas de ComponentesDescriben 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

Cuerpo

Gené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áficasde los diferentes tipos demódulos.

Notación compactaLa 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 ComponentesLas 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 permiteenlazar los diferentes componentes.

Dependencias de CompilaciónEn 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 TareasLas 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 principalesEl 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 lasaplicaciones se identificancon el icono siguiente :

Los SubprogramasAgrupan 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 SubsistemasPara 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 SistemasLos 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ónProcedimientos

INTERFACESINTERFACES

CONTROLESCONTROLES

ENTIDADESENTIDADES

MAINMAIN

Ordenes.exe

OpcionesOrden

DetalleOrden

AdministradorOrdenes

AdministradorTransacciones

Main

Orden

ItemOrden

Producto

Cliente

ServidorOrdenes.exe

Los Diagramas de DespliegueMuestran 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.

PCMODEM DISCO

<<Dispositivo>> <<Procesador>> <<Memoria>>

Ejemplos de estereotipos de nodo

Dispositivos y procesadoresLa 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 ServidorSGBD

<<Procesador>>

<<Dispositivo>>

PUERTA

<<RDSI>>.

<<TCP/IP>>.

3

1

1

Consola

<<Dispositivo>>

1

*

1..10

1Piloto.exe

Controlador

Usos ComunesSe 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 UsoPara 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 servidorEs 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 distribuidosSon 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