sábado, 30 de marzo de 2013

DIAGRAMAS DE UML

Su Utilización.
El estándar UML 2.0 está con nosotros. En Julio de 2003la superestructura UML2.0 fue publicado y desde entonces éste tuvo
 abundante especulación sobre los cambios y su impacto sobre la comunidad UML.
Los cambios más obvios del UML 1.x al 2.0 fueron la introducción de nuevos diagramas. Los nuevos diagramas incluyen:
* Diagrama de Estructura.
* Diagrama Compuesta.
* Diagrama de Comunicación.
* Diagrama de Oportunidad.
* Diagrama de Interacción por Repaso.
El siguiente Diagrama de Estructura aplica:




Diagramas de Modelado UML.
UML está compuesto por los siguientes diagramas:
J Diagramas de Clases.













Diagrama de clases mostrando la disposición del patrón Strategy.
Este diagrama describe la estructura (simplificada) de un sistema de restaurante. El sistema tiene
cualquier cantidad de platillos, una cocina, comedor y cualquier número de empleados, todos estos
 objetos asociados a un restaurante.]] El UML muestra las relaciones es_un con un triángulo y las
relaciones contiene con un rombo.
A continuación presentaremos su simbología:












J Diagrama de Caso de Uso.
Los casos de uso son los óvalos y las figuras con forma "humana" son los actores.
La OMG define una notación gráfica para los casos de uso, pero se abstiene de definir algún formato
escrito para describir la funcionalidad de los casos de uso en detalle; debido a esto algunas personas
 tienen el concepto erróneo acerca de que un caso de uso es su notación gráfica, cuando es ladescripción
 escrita de escenarios la que da el verdadero valor al caso de uso.





























En este diagrama se lleva la notación siguiente:



















J Diagrama de Interacción por Repaso.
El Diagrama de Interacción por Repaso es un diagrama variante de la actividad. En este diagrama las
diferentes secuencias son incluidas en una actividad que fluyen en orden para mostrar el flujo de trabajo
por las secuencias. Ejemplo:














Detrás de los procesos detallados, los fragmentos están representados por los siguientes:
1. Captura de Cliente:





























2. Captura de Factura:



J Diagrama de Estados.
El Diagrama de Estado de la Máquina captura los ciclos de vida de los objetos, subsistemas y sistemas.
Ellos indican qué estado de un objeto puede tener y qué eventos diferentes afectan aquellos estados
 fuera de tiempo.
Éste diagrama podría ser adherido a clases que tienen claramente estados identificables y es gobernado
por un comportamiento complejo.
Un estado es mostrado como un rectángulo redondeado con comportamientos opcionales de los
atributos, eventos y actividades internas. El flujo de estado o transiciones son dibujados entre los
 Estados, usualmente guardan condiciones y reglas gobernando cómo y donde un objeto puede
 transicionar de un estado a otro.
Los estados son usualmente nombrados según a sus condiciones, por ejemplo: "Chocando", "Esperando"
 y "Despachando" son totalmente condiciones activas, un objeto lo puede hacer mientras espera una
transición a otro estado o terminar el ciclo completamente.
Los nodos iniciales y terminales son representados como círculos sombreados o vacíos que son usados
para representar el inicio y término de todas ls transiciones. El Diagrama de Estado de la Máquina puede
tener un punto de inicio y severos puntos de término.
La transición de estados puede ser disparado por eventos. Estos eventos pueden tener palabras claves
 (guardar) asociándolo para clarificar el evento. Esto no es siempre necesario para mostrar esos eventos.
Los estados pueden ser anidados. Estos implican aquellos estados (sub estados) que puedan existir dentro
 de un estado total. Los estados Paralelos pueden ser también definidos donde un objeto pueda tener
estados serios al mismo tiempo. Por ejemplo: Una persona puede tener en cualquier momento muchos
estados paralelos. Estos pueden ser: "Caminando", "Pensando", "Joven", etc.
Considere los siguientes trazos de estados de una clase de factura:



J Diagramas de Actividad.
Los Diagramas de Actividad son primordialmente usados para describir el comportamiento.
 Éstos son representados como un conjunto de flujo secuencial de las actividades, éstas describen
conceptos como flujo de trabajo.
Una actividad describe una unidad lógica de trabajo. Las actividades pueden ser rotas bajo acciones.
Una acción es la más pequeña unidad de trabajo que no es descompuesta ninguna lejana. Un diagrama
 de actividad tiene un inicio y puede tener múltiples puntos de terminación. El UML 2.0 también
proviene de un flujo final (un círculo con una cruz), estos indican aquellos procesos de detención.
Las actividades son unidas por flujos de procesos o eventos. En adición, un nodo de decisión puede
modelar diversos comportamientos basados sobre una condición. Típicamente un nodo Inicial y Final
son definidos para completar totalmente la representación del diagrama de actividad.
Los puntos de sincronización pueden también ser definidos para ilustrar como procesamiento puede ser
cargado fuera en paralelo, entonces sincronizó aquel punto antes lejano la actividad está emprendido.
 Los parámetros de Entrada y Salida pueden ser mostrados. Esto es hecho por vía rectángulos que sujetan
 a las actividades.
Las particiones permiten el modelaje para crear vistas en el diagrama de actividad. Estas pueden mostrar
 las áreas de responsabilidad, los departamentos organizacionales y el mismo.
El siguiente ejemplo muestra lo que sucede si un sistema cambia invaluablemente mientras un usuario lo
está usando. Éste usuario recibirá un mensaje donde el sistema está invaluable. El sistema tratará de
reconectarse tres veces. Si esto no sucede, mostrará un mensaje de error. La actividad del mensaje hace
 uso de un parámetro de entrada: estado de conexión. Éste parámetro indica la actividad que ocurrió e
l error. La actividad del mensaje de error mostrada se rompe bajo las acciones ejecutadas.
Nosotros tenemos hecho el uso de particiones para indicar las áreas del sistema de ejecución y
 la gerencia de error.

























J Diagramas de Paquetes.
Los paquetes son usados para organizar y manipular la complejidad de los modelos largos. Un grupo
de paquetes modelan elementos y los diagramas semejantes como el uso de casos, clases, actividades,
 procesos, estados, etc., y sus diagramas asociados; en tal camino que eso puede ser remitido como uno
 entero. Los paquetes pueden ser representados en un diagrama, remitido como Diagrama de Paquete.
Un paquete es representado por un rectángulo con una pequeña lengüeta donde el nombre del paquete
es marcado.
Los paquetes pueden tener relación con otros paquetes para mostrar que las dependencias están entre los paquetes. Las Relaciones de Dependencia son usadas qué paquetes están dependiendo sobre cada otro.




















J Diagramas de Componentes.
El diagrama de componentes ilustra los componentes del software que serán usados para construir el
 sistema. Estos pueden ser construidos para el modelo de clase y escritos para satisfacer los requisitos
del nuevo sistema, o puede ser dada para otros proyectos o vendedores de tercera persona. Los
omponentes son de nivel de agregación altos de las piezas más pequeñas del software, y provee una "caja
 negra" construyendo un block para el aprovechamiento de la construcción del software. Un componente
 puede ser siempre considerado como una unidad autónoma dentro de un sistema o sub sistema. Este
 tiene una o más provisiones e interfaces requeridas (portales vías potencialmente expuestas) y esta
 internas son ocultas y otras inaccesibles que estas provinieron por estas interfaces. Todo esto puede ser
 dependiente sobre otros elementos en términos de interfaces que son requeridas, un componente está
 encapsulado y estas dependencias son asignadas lejos que pueden ser tratados como un posible
independiente. Como resultado, los componentes y los sub sistemas pueden ser flexiblemente rehusados
y reemplazados por conexiones ("instalación eléctrica") para unirlos en vía sus provisiones e interfaces
 requeridas.
El Diagrama de Componente muestra la relación entre los componentes del software, sus dependencias,
 comunicaciones, localización y otras condiciones. Los Diagramas de Componentes son usados para
 estructurar los componentes en los sistemas del software. Ellos examinan y controlan las dependencias
 entre componentes o interfaces de los componentes. Un componente representa una parte modular,
desplegable y reutilizables de un sistema.
Una o más clasificaciones que residen sobre el componente típicamente especifican un componente. Sub
puesto de esa clasificación, explícitamente define la interface externa del componente. Un componente
se conforma de la interface que esta expone, donde la interface representa los serviciosprovistos por los
elementos que residen sobre el componente. Ejemplo:






























J Diagramas de Despliegue.
El modelo de despliegue describe cómo una aplicación se despliega a través de una infraestructura. La intención del modelo de despliegue no es para describir la infraestructura, pero mejor dicho el camino en cual los componentes específicos deben corresponder a una aplicación que despliega a través de él.
En el ejemplo, un despliegue físico de una aplicación financiera es mostrado. Las múltiples computadoras del cliente/usuario con el "runtime" de componentes Windows 2000 y el componente del cliente de la aplicación financiera puede conectarse por vía TCP/IP a cualquier aplicación del servidor, ya que estos son múltiples. La aplicación Server/s- corriendo SCO – Unix y la aplicación financiera –conectados por vía TCP/IP hacia el servidor de la base de datos central- corriendo HP-UX –Oracle y tiene la base de datos maestra de la financiera sobre este.
Mensaje ando y flujo de trabajo entre el cliente- PC’s y entre la aplicación del servidor son ejecutados usando MS-Outlook y MS-Exchange. MS-Exchange soporte de flujo de trabajo y mensaje ando. Ejemplo:

J Diagramas de Secuencias.
Diagrama de secuencia. Este diagrama describe la secuencia (simplificada) de mensajes de un sistema de restaurante. El diagrama representa a un cliente pidiendo comida y pagando.
Las líneas punteadas extendiéndose hacia abajo indican la línea de tiempo de cada objeto. Las flechas representan mensajes (estímulos) de un"actor" u objeto a otros objetos.
J Diagramas de Colaboración.
El Diagrama de Colaboración presenta una alternativa al diagrama de secuencia para modelar interacciones entre objetos en el sistema. Mientras que el diagrama de secuencia se centra en la secuencia cronológica del escenario que estamos modelando, el diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario. Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una asociación entre las clases implicadas. El enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y 'time-out'), y la visibilidad de un objeto con respecto a los otros.
Diagrama de Colaboración para un grupo de Objetos
J Clases y Diagramas de Implementación
Conforme se van encontrando los objetos, pueden ser agrupados por tipo y clasificados en un Diagrama de Clase. Es el diagrama de clase el que se convierte en el diagrama central del análisis del diseño orientado a objetos, y el que muestra la estructura estática del sistema. El diagrama de clase puede ser dividido en capas: aplicación, y datos, las cuales muestran las clases que intervienen con la interfaz de usuario, la lógica del software de la aplicación, y el almacenamiento de datos respectivamente. Los Diagramas de Componentes se usan para agrupar clases en componentes o módulos. La distribución general del hardware del sistema se modela usando el Diagrama de Implementación.
Modelando la Distribución y la Implementación
Los Diagramas de Implementación se usan para modelar la configuración de los elementos de procesado en tiempo de ejecución (run-time processing elements) y de los componentes, procesos y objetos de software que viven en ellos. En el diagrama 'deployment' (despliegue), empiezas modelando nodos físicos y las asociaciones de comunicación que existen entre ellos. Para cada nodo, puedes indicar qué instancias de componentes viven o corren (se ejecutan) en el nodo. También puedes modelar los objetos que contiene el componente.
Los Diagramas de Implementación se usan para modelar sólo componentes que existen como entidades en tiempo de ejecución; no se usan para modelar componentes solo de tiempo de compilación o de tiempo de enlazado. Puedes también modelar componentes que migran de nodo a nodo u objetos que migran de componente a componente usando una relación de dependencia con el estereotipo 'becomes' (se transforma)
Modelando la Distribución del Sistema con el Diagrama de Implementación
J Diagramas de Objetos.
Un diagrama de objeto está hecho para las instancias de tiempo real de los diagramas de clase o partes de los diagramas de clase. Como tal, un diagrama de objeto puede ser visto para ser un ejemplo de un diagrama de clase. Los diagramas de objetos pueden ser dibujados para explicar los diagramas de clase o para capturar ciertos escenarios de la vida real como ejemplos para demostrar conceptos y/o ciertos estados de los diagramas de clase como un punto de tiempo. Ejemplo:


Para el diagrama de clase:


J Diagramas de Estructura Compuesta.
El diagrama de estructura compuesta toma el modelo para describir las relaciones entre los elementos para trabajar junto a una clasificación. Este es similar al diagrama de clase, pero muestra partes y conectores. Las partes no son necesariamente clases en el modelo y ellos no representan las instancias particulares, pero ellos pueden tener roles donde las clasificaciones pueden jugar.
Las partes son mostradas de una manera similar a los objetos. El diagrama de estructura compuesta es usado para mostrar el "runtime" de la arquitectura de cualquier tipo de clasificación.
Ejemplo:
J Diagramas de Comunicación.
Un diagrama de comunicación muestra la colaboración dinámica entre los elementos. Es similar al diagrama de secuencia y la intención es para enfocar cómo los objetos colaboran con cada otro.
Los diagramas de comunicación muestran los intercambios de mensajes (o interacciones) entre los objetos tan bueno como la relación (poco llamado como "contexto")
Para una elección debe ser hecha para usar el diagrama de secuencia o el diagrama de comunicación. Si mostraran el tiempo o la secuencia de los eventos más importantes, el diagrama de secuencia podría ser usada. Si mostraran conceptos más importantes, el diagrama de colaboración sería usada.
El diagrama de comunicación es dibujada como un diagrama de objeto, donde un número de objetos se muestran con la relación entre ellos. Las flechas de mensajes son dibujadas en medio entonces para mostrar el flujo de los mensajes entre los objetos. Las etiquetas son puestas sobre el mensaje para mostrar el orden dentro de los mensajes que son puestos. Ejemplo:

Un ejemplo usando estereotipos:

J Diagrama de Coordinación.
Los diagramas de coordinación son usados para mostrar cambios y sus relaciones en tiempo de reloj. Este provee de una representación visual de los objetos cambiando el estado y la interacción fuera de tiempo. Los diagramas de coordinación pueden ser usados para definir el funcionamiento del hardware o la implementación de los componentes del software.
El X-axis del diagrama de coordinación normalmente tiene las unidades del tiempo con el Y-axis mostrando los objetos y sus estados. Los estados son normalmente cambiados por algún tipo de evento que causa el cambio de estado.
Los diagramas de coordinación pueden ser dibujados para una evaluación o un punto de vista basado en el tiempo. Ejemplo:
Diagrama de Coordinación basada en el tiempo.
Diagrama de Coordinación basada en la evaluación.

No hay comentarios.:

Publicar un comentario