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

Transcripción

1 ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CON UML ( Parte IV ) Ing. Luis Zuloaga Rotta

2 Los Diagramas de Actividades Un diagrama de actividades es una variante de los diagramas de estadostransiciones, 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.

3 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. [demasiado frio] Calentar [demasiado frio] Calentar Medir la Temperatura [demasiado calor] Medir la Temperatura Enfriar [demasiado calor] Enfriar

4 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. Parar calefaccion Enfriar el ambiente Medir la Temperatura Ventilar

5 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.

6 Docente Alumno Jurado Enseñar Aprender Controlar conocimientos Escribir Evaluar

7 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.

8 Cliente Vendedor Expedidor Registrarse Iniciar un Pedido Hacer un Pedido TOMADO FACTURADO Facturar Pagar PAGADO Entregar ENTREGADO

9 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.

10 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).

11 Componente

12 Componentes e Interfaces

13 Los Módulos 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. Especificación Cuerpo Genérico Representaciones gráficas de los diferentes tipos de módulos.

14 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.

15 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.

16 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 Cuerpo A Especificación B Cuerpo B

17 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

18 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 :

19 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.

20 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>>

21 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.

22 Especificación Procedimientos A Relaciones de dependencia entre diferentes tipos de componentes y subsistemas. B Main

23

24 MAIN Ordenes.exe Main INTERFACES ENTIDADES Opciones Orden Detalle Orden CONTROLES ServidorOrdenes.exe Administrador Ordenes Administrador Transacciones Orden Item Orden Cliente Producto

25 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.

26 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. MODEM PC DISCO <<Dispositivo>> <<Procesador>> <<Memoria>> Ejemplos de estereotipos de nodo

27 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. Terminal X 3 Consola PC Piloto.exe <<TCP/IP>>. Controlador PUERTA Servidor SGBD <<Procesador>> 1 <<RDSI>>. * IMPRESORA <<Dispositivo>> Sistema de gestión de accesos a un edificio 1 1

28 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.

29 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

30 Componentes y Nodos