UML


UML

UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método.


Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo ¾ los símbolos utilizados en los modelos ¾ y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas.


 

Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:
  • Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos.
  • Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema.
  • Vista de Componentes: Muestra la organización de los componentes de código.
  • Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente.
  • Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos llamados nodos.
Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.

Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.

Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.

2.0 ¿Porque es necesario UML?

Hoy en día, UML ("Unified Modeling Language") esta consolidado como el lenguaje estándar en el análisis y diseño de sistemas de computo. Mediante UML es posible establecer la serie de requerimientos y estructuras necesarias para plasmar un sistema de software previo al proceso intensivo de escribir código.

En Software se deben realizar diseños en UML previa codificación de un sistema, ahora, aunque UML es un lenguaje, éste posee más características visuales que programáticas, mismas que facilitan a integrantes de un equipo multidisciplinario participar e intercomunicarse fácilmente, estos integrantes siendo los analistas, diseñadores, especialistas de área y desde luego los programadores.

2.1 ¿Cuales son las Versiones de UML?
Los antecedentes de UML se sitúan en la década de los 90 con distintos estándares para modelado de software, no obstante podemos hablar de dos grandes versiones:
UML 1.X (comprende UML 1.1, 1.2, 1.3, 1.4, 1.5): desde finales de los 90 se empezó a trabajar con el estándar UML. En los años sucesivos fueron apareciendo nuevas versiones que introducían mejoras o ampliaban a las anteriores.
UML 2.X (comprende UML 2.1 hasta UML 2.5, 2.6, etc.): en torno a 2005 se difundió una nueva versión de UML a la que podemos denominar UML 2.X. Comprenden varias revisiones.
UML 3.X: evolución que se espera para UML 2.X.
Hay que tener en cuenta que UML es un conjunto muy amplio de normas. Prácticamente nadie las conoce todas. Según la empresa o universidad, institución o centro de trabajo se usan determinados programas para crear diagramas y se conocen ciertas partes de UML, pero no el conjunto de UML.
3.0 ¿Cual es la version actual de UML?

Version actual  2.5

4.0 Tipos de Diagramas UML:

4.1 Estructurales:
Representan elementos componiendo un sistema o una función. Estos diagramas pueden reflejar las relaciones estáticas de una estructura, como lo hacen los diagramas de clases o de paquetes, o arquitecturas en tiempo de ejecución, tales como diagramas de Objetos o de Estructura Compuesta.  

Los diagramas estructurales incluyen

basicelements2

 4.1.1 Diagrama de Clases: El diagrama de Clases captura la estructura lógica del sistema - las clases y cosas que constituyen el modelo -. Es un modelo estático, describiendo lo que existe y qué atributos y comportamiento tiene, más que cómo se hace algo. Los diagramas de Clases son los más útiles para ilustrar las relaciones entre las clases e interfaces. Las generalizaciones, las agregaciones y las asociaciones son todas valiosas para reflejar la herencia, la composición o el uso y las conexiones respectivamente. 
classdiagram Resultado de imagen para diagrama de clases


4.1.2 Diagrama de Estructura Compuesta: refleja la colaboración interna de clases, interfaces o componentes para describir una funcionalidad. Los diagramas de estructura compuesta son similares a los diagramas de clase, a excepción de que estos modelan un uso especifico de la estructura.  Los diagramas de clase modelan una vista estática de las estructuras de clase, incluyendo sus atributos y comportamientos. Un diagrama de Estructura Compuesta se usa para expresar arquitecturas en tiempo de ejecución, patrones de uso, y las relaciones de los elementos participantes, los que pueden no estar reflejados por diagramas estáticos.

Diagrama de ejemplo
El siguiente diagrama muestra una colaboración usada en diagramas de Estructura Compuesta para modelar patrones comunes. Este ejemplo en particular muestra un relación para realizar una instalación.
collaboration Resultado de imagen para diagrama de estructura compuesta

4.1.3 Diagrama de Componentes: lustra los fragmentos de software, controladores embebidos, etc. que conformarán un sistema. Un diagrama de componentes tiene un nivel de abstracción más elevado que un diagrama de clase - usualmente un componente se implementa  por una o más clases (u objetos) en tiempo de ejecución. Estos son bloques de construcción, como así eventualmente un componente puede comprender una gran porción de un sistema.  

Diagrama de ejemplo
El siguiente diagrama muestra algunos componentes y sus relaciones internas. Los conectores emsamble "vinculan" las interfaces proporcionadas suministrada por Producto y Cliente a las interfaces requeridas especificadas por Orden. Una relación de dependencia asigna los detalles de cuenta asociados del cliente a la interfaz requerida, "pago", indicado por Orden.

componentdiagram Resultado de imagen para diagrama de componentes

4.1.4 Diagrama de Despliegue: muestra cómo y dónde se desplegará el sistema. Las máquinas físicas y los procesadores se representan como nodos, y la construcción interna puede ser representada por nodos o artefactos embebidos. Como los artefactos se ubican en los nodos para modelar el despliegue del sistema, la ubicación es guiada por el uso de las especificaciones de despliegue. 

Diagrama de ejemplo
Debajo hay un diagrama de Despliegue. Los dos nodos tienen una ruta de comunicación TCP/IP indicada. Las relaciones de Despliegue indican el despliegue de artefactos. Además, una especificación de despliegue define el proceso de despliegue para el artefacto networkScanner. Las relaciones manifestadas revelan la implementación física de los componentes ReposCustomer y ReposInternalRecords.

deploymentdiagram Resultado de imagen para diagrama de despliegue

4.1.5 Diagrama de Objetos:  está relacionado de cerca con un diagrama de Clases, con la diferencia de que éste describe las instancias de los objetos de clases en un punto en el tiempo. Esto podría parecer similar al diagrama de Estructura Compuesta, que modela el comportamiento en tiempo de ejecución; la diferencia es que el diagrama de Objetos ejemplifica al diagrama de Clases estático, mientras que los diagramas de Estructura Compuesta refleja las arquitecturas diferentes de sus contrapartes estáticas. Los diagramas de Objetos no presentan arquitecturas que varíen de sus correspondientes diagramas de Clases, pero reflejan la multiplicidad y los roles a los que las clases instanciadas podrían servir. 
object--classifiers Resultado de imagen para diagrama de objeto

4.1.6 Diagrama de paquetes:  se usan para reflejar la organización de los paquetes y sus elementos, y para proveer una visualización de sus correspondientes nombres de espacio.

packagediagram Resultado de imagen para diagrama de paquetes


4.2 De Comportamiento:
Los diagramas de comportamiento describen las características de comportamiento de un sistema o proceso de negocios. Los diagramas de comportamiento incluyen:  



basicelements

4.2.1 Diagrama de Actividades: se usan para modelar el comportamiento de un sistema, y la manera en que éste comportamiento está relacionado con un flujo global del sistema. Se usan los caminos lógicos que sigue un proceso basado en varias condiciones, concurrencia en el proceso, los datos de acceso, interrupciones y otras alternativas del camino lógico para construir un proceso, sistema o procedimiento. 

iagrama de Ejemplo
El siguiente diagrama muestra algunas características de los diagramas de Actividades, incluyendo actividades, acciones, nodos de inicio, nodos de finalización y puntos de decisión.

activity - main1 Resultado de imagen para diagrama de actividades

4.2.2 Diagrama de Maquinas de Estado:  ilustra cómo un elemento (a menudo una clase) se puede mover entre estados, clasificando su comportamiento de acuerdo con los disparadores de transiciones y las guardas de restricciones.  Otros aspectos de los diagramas de Máquinas de Estados describen y explican el movimiento y el comportamiento.  Las representaciones de máquinas de estado en UML se basan en la notación de cuadro de estado Harel.
statediagram1 Resultado de imagen para diagrama de  maquina de estado

4.2.3 Diagrama de Comunicaciones:  muestra las interacciones entre los elementos en tiempo de ejecución en forma semejante a un diagrama de Secuencia. No obstante, los diagramas de Comunicación se usan para visualizar relaciones inter-objetos, mientras que los diagramas de Secuencia son más efectivos para visualizar procesamiento a lo largo del tiempo. 

Los diagramas de Comunicaciones emplean asociaciones ordenadas y etiquetadas para ilustrar el procesamiento. Es importante la numeración para indicar el orden y el anidamiento del procesamiento. Un esquema de numeración podría ser 1, 1.1, 1.1.1, 1.1.2, 1.2, etc. Comienza un nuevo segmento de números para una nueva capa de procesamiento, y sería equivalente a la invocación de un método. 

communicationdiagram2 Resultado de imagen para diagrama de comunicacion

4.2.4 Diagrama de la Descripcion de Iteraccion:  muestran la cooperación entre otros diagramas de interacción para reflejar el flujo de control que responde a un propósito abarcativo. Como los Diagramas de Descripción de las Interacciones son una variante de los diagramas de actividades, la mayor  parte de la notación es similar, al igual que el proceso de construcción del diagrama. 

interactionoverview
4.2.5 Diagrama de Secuencia: Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. A menudo es útil para complementar a un diagrama de clases, pues el diagrama de secuencia se podría describir de manera informal como "el diagrama de clases en movimiento", por lo que ambos deben estar relacionados entre sí (mismas clases, métodos, atributos...). Mientras que el diagrama de casos de usopermite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.

ocaloptions-sequence Resultado de imagen para diagrama de secuencia uml

4.2.6 Diagrama de Tiempo: 
define el comportamiento de los diferentes objetos con una escala de tiempo. Provee una representación visual de los objetos cambiando de estado e interactuando a lo largo del tiempo. Puede usar diagramas de tiempos para definir componentes de software dirigidos por hardware o embebidos; por ejemplo, aquellos usados en un sistema de inyección de combustible, un controlador de microondas. También puede usar diagramas de tiempo para especificar procesos de negocio dirigidos por tiempo.
timingdiagram Resultado de imagen para diagrama de tiempo

4.2.7 Diaframa de Casos de Uso: captura las interacciones de los casos de uso y los actores. Describe los requisitos funcionales del sistema, la forma en la que las cosas externas (actores) interactúan a través del límite del sistema y la respuesta del sistema. 


 usecasediagram2  Resultado de imagen para diagrama de casos de uso

4.3 Diagrama de Iteraccion: 
El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente.
Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o el de Casos de Uso (son diferentes).
Los componentes de un diágrama de interacción son:

  • Un objeto actor.
  • Mensaje de un objeto a otro objeto.
  • Mensaje de un objeto a si mismo.
4.3.1 Un objeto actor:
El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto.

4.3.2 Mensaje de un objeto a otro objeto: 

Se representa por una flecha entre un objeto y otro, representa la llamada de un método (operación) de un objeto en particular.

4.3.3 Mensaje de un objeto a si mismo:  

No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos desde el mismo objeto en estudio.


INFOGRAFIA UML


fuentes:
https://www.osmosislatina.com/lenguajes/uml/basico.htm
https://users.dcc.uchile.cl/~psalinas/uml/interaccion.html#message
http://www.sparxsystems.com.ar/download/ayuda/index.html?structuraldiagrams.htm
http://profesores.fi-b.unam.mx/carlos/aydoo/uml.html
https://www.aprenderaprogramar.com/index.php?option=com_content&view=article&id=688:ique-es-y-para-que-sirve-uml-versiones-de-uml-lenguaje-unificado-de-modelado-tipos-de-diagramas-uml&catid=46&Itemid=163

Comentarios

Entradas populares de este blog

Prototipo

Requerimientos