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 Compuesta.
* Diagrama de Oportunidad.
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 la
descripció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:
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
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:
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.