jueves, 5 de diciembre de 2013

TIPOS DE DIAGRAMAS

Tipos de Diagramas de UML

Estructura

Diagrama de clases
Diagrama de objetos
Diagrama de componentes
Diagrama de estructura compuesta
Diagrama de paquetes
Diagrama de despliegue

Comportamiento

Diagrama de casos de uso
Diagrama de actividades
Diagrama de estado

Interacción

Diagrama de secuencia
Diagrama de colaboración
Diagrama de tiempo
Diagrama de interacción

DIAGRAMA DE COLABORACIÓN


DIAGRAMA DE COLABORACIÓN 

Un diagrama de colaboración sirve para describir un determinado escenario de un caso de uso al mostrar la interacción entre el conjunto de objetos que cooperan en la realización de dicho escenario.

Suele ser conveniente especificar en la parte izquierda del diagrama, el caso de uso que se está representando para que resulte más sencilla su validación.

Los diagramas de colaboración conforman, junto con los diagramas de secuencia, los diagramas de interacción para modelar el comportamiento dinámico de un sistema haciendo énfasis en la secuencia de los mensajes intercambiados por un conjunto de objetos para un caso de uso en particular.

Tanto los diagramas de colaboración como los diagramas de secuencia muestran la misma información pero destacando un aspecto particular.  Los diagramas de secuencia muestran de forma explícita la secuencia de los mensajes intercambiados por los objetos, mientras que los diagramas de colaboración muestran de forma más clara cómo colaboran los objetos, es decir, con qué otros objetos tiene vínculos o intercambia mensajes un determinado objeto.

¿Qué es una Interacción?

Es el conjunto de mensajes intercambiados por los roles de clasificador a través de los roles de asociación. Un mensaje es una comunicación unidireccional entre dos objetos, un flujo de objeto con la información de un remitente a un receptor. Un mensaje puede tener parámetros que transporten valores entre objetos. Un mensaje puede ser una señal (comunicación explícita entre objetos, con nombre y asíncrona) o una llamada (la invocación sincronía de una operación con un mecanismo para el control, que retorna posteriormente al remitente). Un patrón de intercambios de mensajes que se realizan para lograr un propósito específico es lo que se denomina una interacción.


Un diagrama de colaboración es una forma de representar interacción entre objetos, alterna al diagrama de secuencia. A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuáles temporales) y ciclos en la ejecución.  En general, un diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado para un caso de uso hoja.



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.

Los elementos que conforman un diagrama de colaboración son:

Instancias

Las instancias representan un objeto o instancia cualquiera de una clase determinada (no a una instancia real).

Una instancia u objeto se ilustra con un rectángulo, que contiene el nombre y la clase del objeto en un formato nombreObjeto: nombreClase.


Enlaces

Los enlaces representan una conexión entre instancias que indican navegabilidad y visibilidad entre ellas.  Establece una relación cliente-servidor entre las instancias









DIAGRAMAS DE SECUENCIA


DIAGRAMA DE SECUENCIA.

Un diagrama de secuencia sirve para describir en detalle un determinado escenario de un caso de uso al mostrar la interacción entre el conjunto de objetos que cooperan en la realización de dicho escenario.

Suele ser conveniente especificar en la parte izquierda del diagrama, el caso de uso que se está representando para que resulte más sencilla su validación.

Los diagramas de secuencia conforman, junto con los diagramas de colaboración, los diagramas de interacción para modelar el comportamiento dinámico de un sistema haciendo énfasis en la secuencia de los mensajes intercambiados por un conjunto de objetos para un caso de uso en particular.

Tanto los diagramas de secuencia como los diagramas de colaboración muestran la misma información pero destacando un aspecto particular.  Los diagramas de secuencia muestran de forma explícita la secuencia de los mensajes intercambiados por los objetos, mientras que los diagramas de colaboración muestran de forma más clara cómo colaboran los objetos, es decir, con qué otros objetos tiene vínculos o intercambia mensajes un determinado objeto.

Un diagrama de secuencia muestra la existencia y duración de las instancias, pero no sus relaciones.

Un diagrama de secuencia tiene dos dimensiones, el eje vertical que representa el tiempo y el eje horizontal que represente los diferentes objetos. El tiempo avanza desde la parte superior del diagrama hacia la inferior.

Normalmente, en relación al tiempo sólo es importante la secuencia de los mensajes, sin embargo, en aplicaciones de tiempo real se podría introducir una escala en el eje vertical. Respecto a los objetos, es irrelevante el orden en que se representan, aunque su colocación debería poseer la mayor claridad posible.


Los elementos que conforman un diagrama de secuencia son similares a la notación de los diagramas de colaboración.  Adicional mente se encuentran los siguientes aspectos:


Una línea de vida por cada objeto

Un objeto se representa como una línea vertical discontinua, llamada línea de vida, con un rectángulo de encabezado con el nombre del objeto en su interior. También se puede incluir a continuación el nombre de la clase, separando ambos por dos puntos. La línea de vida indica el intervalo de tiempo durante el que existe ese objeto.

Si el objeto es creado en el intervalo de tiempo representado en el diagrama, la línea comienza en el punto que representa ese instante y encima se coloca el objeto. Si el objeto es destruido durante la interacción que muestra el diagrama, la línea de vida termina en ese punto y se señala con un aspa de ancho equivalente al del foco de control.

En el caso de que un objeto existiese al principio de la interacción representada en el diagrama, dicho objeto se situará en la parte superior del diagrama, por encima del primer mensaje. Si un objeto no es eliminado en el tiempo que dura la interacción, su línea de vida se prolonga hasta la parte inferior del diagrama.

La línea de vida de un objeto puede desplegarse en dos o más líneas para mostrar los diferentes flujos de mensajes que puede intercambiar un objeto, dependiendo de alguna condición.

Uno o varios focos de control por cada objeto

Un foco de control o activación muestra el periodo de tiempo en el cual el objeto se encuentra ejecutando alguna operación, ya sea directamente o mediante un procedimiento concurrente.

Se representa como un rectángulo delgado superpuesto a la línea de vida del objeto. Su largo dependerá de la duración de la acción. La parte superior del rectángulo indica el inicio de una acción ejecutada por el objeto y la parte inferior su finalización.






DIAGRAMA DE CLASES


CONCEPTOS BÁSICOS DIAGRAMA DE CLASES

El diagrama de clase es el diagrama principal de diseño y análisis para un sistema, y en él se agrupan todas las clases y relaciones que existen entre ellas y que serán utilizadas dentro del sistema.  Los diagramas de Clases por definición son estáticos, esto es, representan que partes interactúan entre sí, sin indicar el momento en que ocurre.

Una clase agrupa los objetos que comparten estructura, comportamiento y relaciones similares. Una clase representa los conceptos del sistema que se desea modelar.

Gráficamente una clase se dibuja como un rectángulo con hasta tres (3) compartimentos:
Nombre de la clase
Lista de Atributos (opcional)
Lista de Operaciones (opcional)


Atributos de una clase

Los atributos representan alguna propiedad dentro de la clase.  Los atributos son valores que son instanciados de la clase. Una clase puede tener varios atributos o ninguno.

Los atributos de una clase no deberían ser manipulables directamente por el resto de objetos. Por esta razón se crearon niveles de visibilidad para los elementos que son:
  • (-)  Privado: Son accesibles sólo por métodos propios de la clase.
  • (#) Protegidos: Son accesible sólo por las clases derivadas de la original.
  • (+) Públicos: Son accesibles por cualquier clase


Operaciones de una clase

Una operación es la implementación de un servicio que podrá ser requerido por cualquier objeto de la clase para afectar su comportamiento. En otras palabras, una operación es una abstracción de algo que se quiera hacer sobre un objeto y sea compartido por todos los objetos de la clase.

Se puede diferenciar una operación colocando su firma:
  • Declarando el nombre de la operación
  • Declarando los parámetros
  • Declarando el valor retornado


Relaciones entre clases

Al construir abstracciones, descubrimos que muy pocas de las clases diseñadas actúan solas, y muchas otras colaboran con otras clases. Por lo que debemos conocer cómo se relacionan unas con otras. 


Existen en el modelado orientado a objetos tres tipos de relaciones:
  • Dependencia
  • Generalización
  • Asociación


La Dependencia representa el uso de las relaciones entre clases, La Generalización sirve para conectar las clases generales a otras más específicas, es decir, para relaciones subclase/superclase, y la Asociación indica relaciones estructurales entre los objetos.

La Agregación se deriva de la Asociación y la Especialización se deriva de la Generalización. Ambos tipos de relaciones forman jerarquías de clases.

Dependencia

La dependencia se usa para mostrar que una clase usa otra clase como un argumento, el cual se especifica en la firma de la operación. En el diagrama anterior la clase Event es utilizado por la clase Window por sus métodos.
Se dibuja como una flecha punteada.




Generalización

La Generalización consiste en factorizar las propiedades comunes de un conjunto de clases en una clase más general.  A la clase más general se le denomina “Superclase” o “Padre” y a la clase más específica se le denomina “Subclase” o “Hijo”.  A veces este tipo de relación es referenciada como "is-a-kind-of" o “es-un-tipo-de”.  Por ejemplo, la clase CuadroDialogo es un tipo de la clase Ventana.

Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones y asociaciones de la clase padre están disponibles en sus clases hijas.

Una clase puede tener cero, uno o más padres. Una clase que no tiene padre es llamada clase raíz o clase base. Una clase que no tiene hijos es una clase hoja. Una clase que tiene exactamente un padre se dice que usa herencia sencilla; una clase que tiene más de un padre se dice que tiene herencia múltiple.

La Generalización y Especialización son equivalentes en cuanto al resultado: la jerarquía y herencia establecidas. La Especialización es una técnica muy eficaz para la extensión y reutilización.



Asociación

Es la relación estructural que especifica que objetos de una cosa están conectados a objetos de otras. Dada una conexión de asociación en dos clases, se puede navegar desde un objeto de una clase a un objeto de la otra clase, y viceversa.

Una asociación que conecta exactamente dos clases se llama asociación binaria, aunque se pueden asociar más clases la cual se llamaría asociación n-aria. Se dibuja como una línea continua.

Existen cuatro conceptos que se aplican a la asociación:

  • Nombre
  • Rol
  • Multiplicidad

 Nombre

Una asociación puede tener un nombre para describir su naturaleza.


Rol

Cuando una clase participa dentro de una asociación, tiene un rol específico que juega en la relación.





Multiplicidad


En el modelado, es importante definir cuantos objetos pueden estar conectados en una instancia de la asociación. Mostrándose la multiplicidad en el rol de la asociación.

Puede determinarse por la especificación de multiplicidad (mínima...máxima)
Uno y sólo uno
0..1 Cero o uno
M...N Desde M hasta N (enteros naturales)
* Cero o muchos
0..* Cero o muchos
1..* Uno o muchos (al menos uno)
Un número específico (N)




El diagrama de clases se desarrolla a través de información obtenida en los Casos de Uso, Diagramas de Secuencia y Diagramas de Colaboración. Los objetos encontrados durante el análisis son modelados en términos de la clase a la que instancian, y las interacciones entre objetos son referenciados a relaciones entre las clases instanciadas.






UML

UML 


Lenguaje Unificado de Modelado

 (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

                                                                                                                             

HISTORIA 

Antes de UML 1.x


Después de que la Rational Software Corporation contratara a James Rumbaugh de General Electric en 1994, la compañía se convirtió en la fuente de los dos esquemas de modelado orientado a objetos más populares de la época: el OMT (Object-modeling technique) de Rumbaugh, que era mejor para análisis orientado a objetos, y el Método Booch de Grady Booch, que era mejor para el diseño orientado a objetos. Poco después se les unió Ivar Jacobson, el creador del método de ingeniería de software orientado a objetos. Jacobson se unió a Rational en 1995 después de que su compañía, Objectory AB, fuera comprada por Rational. Los tres metodologías eran conocidos como los Tres Amigos, porque se sabía de sus constantes discusiones sobre las prácticas metodológicas.

En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba alentando la adopción de la tecnología de objetos, y para orientarse hacia un método unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje Unificado de Modelado abierto. Se consultó con representantes de compañías competidoras en el área de la tecnología de objetos durante la OOPSLA '96; eligieron cajas para representar clases en lugar de la notación de Booch que utilizaba símbolos de nubes.

Bajo la dirección técnica de los Tres Amigos fue organizado un consorcio internacional llamado UML Partners en 1996 para completar las especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo como una respuesta al OMG RFP. El borrador de la especificación UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para finalizar las semánticas de la especificación y para integrarla con otros esfuerzos de estandarización. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997.


UML 1.x

Como notación de modelado, la influencia de la OMT domina UML (por ejemplo el uso de rectángulos para clases y objetos). Aunque se quitó la notación de "nubes" de Booch, si se adoptó la capacidad de Booch para especificar detalles de diseño en los niveles inferiores. La notación de Casos de Uso del Objectory y la notación de componentes de Booch fueron integradas al resto de la notación, pero la integración semántica era relativamente débil en UML 1.1, y no se arregló realmente hasta la revisión mayor de UML 2.0.

Conceptos de muchos otros métodos OO fueron integrados superficialmente en UML con el propósito de hacerlo compatible con todos los métodos OO. Además el grupo tomó en cuenta muchos otros métodos de la época, con el objetivo de asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es útil en una variedad de problemas de ingeniería, desde procesos sencillos y aplicaciones de un sólo usuario a sistemas concurrentes y distribuidos.


El Lenguaje de Modelado Unificado es un estándar internacional:

ISO / IEC 19501:2005 Tecnología de la información - Procesamiento distribuido abierto - Lenguaje de Modelado Unificado (UML) Versión 1.4.2


UML 2.x
UML ha madurado considerablemente desde UML 1.1. Varias revisiones menores (UML 1.3, 1.4 y 1.5) han corregido defectos y errores de la primera versión de UML. A estas le ha seguido la revisión mayor UML 2.0 que fue adoptada por el OMG en 2005.
Aunque UML 2.1 nunca fue lanzado como una especificación formal, las versiones 2.1.1 y 2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3 fue lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en agosto de 2011. UML 2.5 fue lanzado en octubre de 2012 como una versión "En proceso" y todavía tiene que ser formalmente liberada.