Tipos de Diagramas en UML
Posted by: Iván Garcerant on: 20-07-08
- In: Artefactos| UML
- Comment!
Grandes clásicos conocidos por todos, los diagramas de clases, distan mucho de ser los únicos definidos en el lenguaje. De hecho en la versión UML 2 existen trece (13) diagramas concretos y varias categorías de diagramas abstractos, creados como toda clase abstracta, para articular la presentación de los diagramas.
La siguiente figura UML muestra los tipos de diagramas:
Fig. 1 – Tipos de diagramas en UML2
En su momento detallaré cada uno de los tipos de diagramas, lo importante por ahora es señalar que existen dos grandes grupos: estructurales y de comportamiento; esto conforme a lo dicho sobre la presentación de modelos en UML.
Los diagramas estructurales presentan elementos estáticos del modelo, tales como clases, paquetes o componentes; en tanto que los diagramas de comportamiento muestran la conducta en tiempo de ejecución del sistema, tanto visto como un todo como de las instancias u objetos que lo integran.
Por otra parte, en la figura se ve que hay tres tipos de diagramas señalados en un color distinto: los diagramas de estructura compuesta, de tiempo y de resumen de interacción. Se han resaltado dado que son nuevos dentro del UML por lo que resultan ser de los menos conocidos. También aspiro a tener una descripción de ellos en los días por venir.
Hay que tener en cuenta, que cada diagrama sirve para documentar un aspecto distinto del sistema; el criterio para usarlos es el de tener algo que decir, una historia sobre nuestro sistema que debe ser contada; el tipo de diagrama que utilizaremos será el que nos dé mayor poder expresivo y solo muy difícilmente, la construcción de una serie de diagramas puede ser explicitamente ordenada por un método de desarrollo. Algunos sistemas simples serán bien documentados con pocos diagramas, en tanto que algunos sistemas grandes bien podrían beneficiarse de un conjunto mayor.
Entonces que valga la advertencia: no hacemos diagramas porque un método nos lo ordene, hacemos diagramas para contar algo importante de nuestro modelo, por lo que indicar que en un sistema haya que hacer tantos de tal o cual diagrama es una declaración objetable.
9 comentarios para "Tipos de Diagramas en UML"
[...] UML; este elemento es equivalente a un plano individual del sistema. Existen gran variedad de diagramas dentro de UML por lo que estos a su vez, son objeto de clasificación, conociendo en forma inicial los diagramas [...]
[...] De entre todos los tipos de diagramas UML, el más común y conocido es el diagrama de clases. Dicho diagrama ilustra una vista de los [...]
30-09-08 a 2:11 pm
Oh Sandra gracias por el comentario. La verdad lo único que he querido decir en este post es enumerar la lista de diagramas que se incluyen en UML 2. Algunos de estos son nuevos y otros son conocidos por todos…
Si quieres un poco más de información te invito a que recorras el resto del blog. En particular tengo bastante sobre casos de uso. Poco a poco iré alimentando al blog también con información de los demás diagramas.
4-10-08 a 3:39 pm
bueno en si mi9 pregunra fue cuantos tipos ahy ,cuales son y en que consiste cada uno eso no me ayuda en nada ya que me dice lo que ya se . mejor cambien el titulo no cren !
4-10-08 a 9:54 pm
Buen punto. La verdad es que esperaba tener un post para cada tipo de diagrama con algunos ejemplos. En tanto tenga dichos posts, sirva este comentario para responder la inquietud:
- Diagrama de Clases: sirve para mostrar la estructura estática de un sistema, ya sean estas las clases como los paquetes.
- Diagrama de Estructura Compuesta: nuevo en UML2, este diagrama muestra la estructura INTERNA de un elemento o clase.
- Diagrama de Componente: muestra el sistema como una colección de componentes tecnológicos, ejecutables, DLLs, páginas de HTML, etc.
- Diagrama de Despliegue: muestra como el los componentes de un sistema se distribuyen entre los computadores que los ejecutan. Útil en el caso de sistemas distribuidos.
- Diagrama de Objeto: muestra instancias de clases y sus nexos.
- Diagrama de Paquete: muestra paquetes y sus relaciones, suele ser útil para la gestión de un modelo grande en UML.
- Diagrama de actividad: suerte de diagrama de flujo, indican actividades, decisiones y bifurcaciones.
- Diagrama de Secuencia: muestra la interacción entre elementos indicando claramente el eje de tiempo (hay un ejemplo en “Analisis de Casos de Uso”)
- Diagrama de Comunicación: equivale a un diagrama de secuencia, pero colapsa el eje del tiempo.
- Diagrama de Resumen de Interacción: dado que no hay paquetes de actividades se muestran las partes de un diagrama de actividad agrupando estas a la manera de un paquete, pero con un símbolo distinto.
- Diagrama de Tiempo: muestra la evolución de uno o más componente como líneas de vidas que se cruzan en un eje de tiempo. Esto es útil en desarrollo de sistemas en tiempo real.
- Diagrama de Casos de Uso: sirve para ilustrar un modelo de casos de uso. En el blog hay muchos ejemplos de estos.
- Diagrama de Maquina de Estado: muestra el sistema como estados y transiciones entre estos. Las maquinas de estado son un concepto muy bien establecido en ingeniería. En UML2 se usa un formalismo basado en redes de petri, con lo que estos diagramas adquieren mucho mayor poder.
El total de diagramas es de trece.
Ahora que no veo la razón por la cual la especificación diferencia entre diagrama de clases y diagrama de paquetes. En la práctica uno puede hacer un diagrama con clases y paquetes, dando a lugar a un diagrama mixto. Muchas herramientas de UML no diferencian entre estos dos tipos de diagramas.
Los diagramas nuevos suelen tener muy poco soporte. Especialmente los diagramas de Tiempo. Aún estoy esperando encontrar una herramienta que le de soporte y los use para algo más que tener el diagrama.
La diferencia entre los diagramas de secuencia y los de comunicación es solo de gusto. Son por completo equivalentes y de hecho las herramientas suelen poder convertir automaticamente entre estos dos. Ya que es de gusto, a mí me gustan más los de secuencia.
Los diagramas de maquina de estado son en extremo útiles, pero solo si uno esta haciendo un sistema con este concepto en mente. Si lo que uno hace es un sistema de información (un CRM, un CMS, un ERP, etc) entonces posiblemente no se le encuentre uso.
Finalmente los diagramas de actividad son un legado de otras metodologías de desarrollo. Son útiles para documentar procesos y otras cosas como esas, pero no lo son tanto para el desarrollo de software.
Cualquier otra cosa pues solo preguntar. Con el tiempo voy a tener esos posts en los que voy a detallar cada diagrama. Tiempo al tiempo entonces… poco a poco los voy a ir teniendo.
Y gracias por el comentario.
en febrero del 2009 se actualizo y ahora existen 14 diagramas , debes actualizar 
pero igual muy buen post se agradece la informacion pero actualiza pues! 
4-10-08 a 10:00 pm
Ah! Por cierto gente, ¿se nota que el diagrama de clases del post enumera a los tipos de diagramas que existen? Quizás sea un poco abstracto utilizar un diagrama de clases para expresar esta lista, pero la verdad es que es una forma por completo valida.
Las clases son clasificadores de los conceptos, por lo que al clasificar a los diagramas es muy natural utilizar un diagrama de clases.
En cualquier caso, preguntar en caso de dudas.
20-01-09 a 4:48 pm
¡Hola! Gracias por la información. Aunque algunos visitantes presentan sus quejas. La imagen adjunta a este artículo (la que lista los diagramas comunes de UML y los nuevos introducidos al Lenguaje Unificado de Modelado), por lo menos a mí me sirve de consulta rápida. ¡Hasta pronto!
Escribe un comentario
- Ejemplo de caso de uso
- Ejemplo de análisis de caso de uso
- Tipos de Diagramas en UML
- Plantillas: Documento de Visión del Sistema
- Plantillas: Plan de Desarrollo de Software
- Tipos de requisitos: Funcional vs. No Funcional
- Modelo de Dominio
- Casos de Uso Avanzados: Relación de Extensión
- Casos de Uso Avanzados: Relación de Inclusión
- Modelado de Casos de Uso
- Ismael Soto: Hola, Escribo para agradecerles el esfuerzo que han venido realizado en la publicación de este blog, y felicitarles por la calidad del mismo. S
- Marcelo: Muy buen artículo, simple y concreto que es lo necesario para comprender metodologías que en muchas ocaciones terminan siendo expuestas o muy vagame
- Iván Garcerant: Exacto! Estoy muy de acuerdo contigo. Un buen diagrama no estaría nada mal. :-) ... siempre y cuando los casos de uso estén correctamente documen
ClustrMaps
30-09-08 a 10:58 am
ni se dice nada de eso se me hace super chafa esta informacion pues tiene un titulo y no se habla de acuerdo con el…… con todo respeto ….gracias