Diagrama de estructura compuesta
Diagrama de estructura compuesta

Curriculum Vitae
Diagrama de estructura compuesta
Album de fotos nuevo
Cuestionario
Imagen
Contextualizar
Se emplea para visualizar de manera gráfica las partes que definen la estructura interna de un clasificador. Cuando se utiliza en el marco de una clase, este diagrama permite elaborar un diagrama de clases donde se muestran los diferentes atributos (partes) y las clases, a partir de las cuales se definen los atributos, indicando principalmente las asociaciones de agregación o de composición de la clase a la que se le elabora el diagrama.




Diagramas UML. ¿Qué es UML? UML es un conjunto de herramientas, que permite modelar (analizar y diseñar) sistemas orientados a objetos.


Ahora la frase más importante de todo el artículo: "El 80% de los problemas se pueden resolver usando tan solo el 20% de UML"

Herramientas UML

Pero volviendo a la definición de UML como "conjunto de herramientas", si nos imaginamos UML como una caja de herramientas con su martillo, destornillador, alicates, etc. Veamos qué contiene nuestra caja de herramientas:
Cómo nació UML

Durante los ochenta y principios de los noventa Grady Booch, James Rumbaugh, e Ivar Jacobson trabajaban por separado en desarrollo de notaciones para el análisis y diseño de sistemas orientados a objetos. Los tres llegaron por separado a obtener bastante reconocimiento.
Booch había escrito "Object-Oriented Analysis and Designe with Applications " un libro de referencia en el análisis y diseño orientado a objetos desarrollando su propia notación.
Por su parte James Rumbaugh había desarrollado su propia notación de diseño orientado a objetos llamada OMT (Object Modeling Technique) en su libro "Object-Oriented Modeling and Designe ".
Por otro lado Jacobson se había revelado como un visionario del análisis (padre de los casos de uso) y sobre todo del diseño orientado a objetos, sorprendiendo a todo el mundo en "Object-Oriented Software Engineering: A Use Case Drive Approach ".
A mediados de los noventa empezaron a intercambiar documentos y trabajar en conjunto produciendo grandes avances en el modelado de sistemas orientados a objetos.
En 1994 Racional contrató a Rumbaugh en donde ya trabajaba Booch, un año después Jacobson se unía a ellos en Racional.
En 1997 salió a la luz la versión 1.0 de UML.








Modelo conceptual de UML
El lenguaje Unificado de Modelado (Unified Modeling Language) es un lenguaje estar para escribir planos de software. UML puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software.

Tipos de diagramas

Existen los siguientes tipos de diagramas: Diagrama de clases, diagrama de objetos, diagrama de casos de uso, diagrama de secuencia, diagrama de colaboración ,diagrama de estados, diagrama de actividades, diagrama de componentes, diagrama de despliegue.
DIAGRAMAS UML
Clases
UML está compuesto por los siguientes diagramas:
Diagramas de Clases.

Este diagrama describe la estructura (simplificada) de un sistema de restauración. El sistema tiene cualquier cantidad de platillos, una cocina, comedor y cualquier número de empleados, todos estos objetos asociados a un restauracion.El UML muestra las relaciones es un con un triángulo y las relaciones contiene con un rombo.

Presentación de su simbología:


Diagrama de Caso de Uso.
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.


Diagrama de notación siguiente:


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:



Procesos detallados de los fragmento:

1. Captura de Cliente:


2. Captura de Factura:


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.

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 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 las transiciones. El Diagrama de Estado de la Máquina puede tener un punto de inicio y severos puntos de término.

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.

1. Considere los siguientes trazos de estados de una clase de factura:


1. Simbología en este tipo de diagramas:

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.

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

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.

1. Uso de particiones para indicar las áreas del sistema de ejecución y la gerencia de error.


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 un entero

1. Representación de un rectángulo con una pequeña lengüeta donde el nombre del paquete es marcado.

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

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

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.

1. Ejemplo:

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



Diagramas de Secuencias.

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.


Diagramas de Colaboración.
El Diagrama de Colaboración presenta una alternativa al diagrama de secuencia para modelar interacciones entre objetos en el sistema. 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.


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. La distribución general del hardware del sistema se modela usando el Diagrama de Implementación.




Un Modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle.

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés.

El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos. Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos.

Un Diagrama es una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos del modelo). Un diagrama no es un elemento semántico, un diagrama muestra representaciones de elementos semánticos del modelo, pero su significado no se ve afectado por la forma en que son representados.

Un diagrama está contenido dentro de un paquete.

La mayoría de los diagramas de UML y algunos símbolos complejos son grafos que contienen formas conectadas por rutas.

La información está sobre todo en la topología, no en el tamaño o la colocación de los símbolos (hay algunas excepciones como el diagrama de secuencia con un eje métrico de tiempo). Hay tres clases importantes de relaciones visuales: conexión (generalmente de líneas a formas de dos dimensiones), contención (de símbolos por formas cerradas de dos dimensiones), y adhesión visual (un símbolo que está "cerca" de otro en un diagrama).

Estas relaciones geométricas se reasignan a conexiones entre nodos en un gráfico en la forma analizada de la notación.
La notación de UML está pensada para ser dibujada en superficies bidimensionales.

Algunas formas bidimensionales son proyecciones de formas tridimensionales tales como cubos, pero todavía se representan como íconos en una superficie bidimensional.

Hay cuatro clases de construcciones gráficas que se usan en la notación de UML:
1. íconos,
2.símbolos bidimensionales,
3.rutas y
4. cadenas.

Un icono es una figura gráfica con un tamaño y forma fijos.

No se amplía para contener a su contenido. Los iconos pueden aparecer dentro de símbolos de área, como terminadores en las rutas o como símbolos independientes que puedan o no conectar con las rutas.


Los símbolos de dos dimensiones tienen altura y anchura variables, y pueden ampliarse para permitir otras cosas tales como listas de cadenas o de otros símbolos.

Muchos de ellos están divididos en compartimientos similares o de tipos diferentes.

Las rutas se conectan con los símbolos, el arrastrar o suprimir uno de ellos afecta a su contenido y las rutas conectadas.





Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus puntos finales.

Conceptualmente una ruta es una sola entidad topológica, aunque sus segmentos se pueden manipular gráficamente. un segmento no debería existir separado de su ruta. Las rutas siempre van conectadas en ambos extremos.

Las cadenas presentan varias clases de información en una forma "no analizada", UML asume que cada uso de una cadena en la notación tiene una sintaxis por la cual pueda ser analizada la información del modelo subyacente.

Las cadenas pueden existir como el contenido de un compartimiento, como elementos en las listas, como etiquetas unidas a los símbolos o a las rutas, o como elementos independientes en un diagrama.





UML está compuesto por los siguientes diagramas:

Área Vista Diagramas Conceptos Principales
Estructural Vista Estática Diagrama de Clases Clase, asociación, generalización, dependencia, realización, interfaz.
Vista de Casos de Uso Diagramas de Casos de Uso Caso de Uso, Actor, asociación, extensión, generalización.
Vista de Implementación Diagramas de Componentes Componente, interfaz, dependencia, realización.
Vista de Despliegue Diagramas de Despliegue Nodo, componente, dependencia, localización.
Dinámica Vista de Estados de máquina Diagramas de Estados Estado, evento, transición, acción.
Vista de actividad Diagramas de Actividad Estado, actividad, transición, determinación, división, unión.
Vista de interacción Diagramas de Secuencia Interacción, objeto, mensaje, activación.
Diagramas de Colaboración Colaboración, interacción, rol de colaboración, mensaje.
Administración o Gestión de modelo Vista de Gestión de modelo Diagramas de Clases Paquete, subsistema, modelo.
Extensión de UML Todas Todos Restricción, estereotipo, valores, etiquetados

.
BIBLIOGRAFIA

[Booch99] El Lenguaje Unificado de Modelado. G. Booch, J. Rumbaugh, I. Jacobson. Addison Wesley Iberoamericana, 1999.
[Fowler99] UML Distilled. M. Fowler, K. Scott. Addison-Wesley, 99.
[Larman99] UML y Patrones. C. Larman. Prentice Hall, 1999.
[OMG99] Unified Modeling Language Specification, v1.3. Object Management Group (OMG), 1999.
[OMG02] UML Home Page. Object Management Group (OMG). http://www.uml.org/