En pocos días estaré dictando un taller de "Modelado de Sistemas usando UML" y me dí cuenta que no había escrito nada sobre esto, a pesar que siempre me preguntan acerca del modelado de sistema. Por eso me decidí a escribir algo muy breve para introducir a quienes esten interesado.
UML Unified Modeling Language, es un lenguaje de modelado que nos permite representar y comunicar conocimiento respecto a un sistema. La OMG es el organismo que respalda UML y a pesar de ser un lenguaje independiente de la metodología, se le relaciona mucho con RUP debido a que en ambos participaron los mismos expertos: Jacobson, Rumbaugh y Booch.
UML Unified Modeling Language, es un lenguaje de modelado que nos permite representar y comunicar conocimiento respecto a un sistema. La OMG es el organismo que respalda UML y a pesar de ser un lenguaje independiente de la metodología, se le relaciona mucho con RUP debido a que en ambos participaron los mismos expertos: Jacobson, Rumbaugh y Booch.
UML es
usado tanto por los practicantes de métodos tradicionales, como también por los
Agilistas, la frase: “en los métodos ágiles no se modela” fue un punto de
debate durante mucho tiempo, pero finalmente resultó ser un mito, ya que en
muchos casos la complejidad de la arquitectura de un sistema no permite que
obvies el modelado.
UML es
evolutivo, actualmente va por la versión actual 2.4.1. la cual fue liberada en
Agosto 2011.
La versión más reciente contiene 13 diagramas, sin embargo, aquí también aplica la ley de pareto o 20-80, ya que en la mayoría de los casos se puede modelar un sistema con 3 0 4 de estos diagramas.
A
continuación les dejo una tabla de los diagramas ordenados por su
probabilidad de uso:
Diagrama
|
Descripción
|
Tipo
|
Uso
|
Clases
|
Muestra una colección de elementos del modelo
estático, como las clases y tipos,
su contenido, y sus relaciones.
|
Estructura
|
Alto
|
Secuencia
|
Muestra los objetos,
sus relaciones y los mensajes que fluyen entre ellos de manera cronológica
|
Comportamiento
|
Alto
|
Actividad
|
Representan
los procesos de negocio de alto nivel.
|
Comportamiento
|
Alto
|
Casos
de Uso
|
Muestra los casos de
uso (servicios o funcionalidades), actores y sus relaciones.
|
Comportamiento
|
Alto
|
Componente
|
Representan
los distintos componentes que forman parte de una aplicación, sistema o
empresa.
|
Estructura
|
Medio
|
Despliegue
|
Muestra la arquitectura de
ejecución de los sistemas. Esto
incluye nodos, ya sea de hardware o software
entornos de ejecución, así como
el middleware que
los conecta.
|
Estructura
|
Medio
|
Paquete
|
Muestra
como los elementos del modelo están organizados y la dependencia entre ellos.
|
Estructura
|
Medio
|
Máquina
de estado
|
Describe
los estados de un objeto, así como su transición
|
Comportamiento
|
Medio
|
Objeto
|
Representa objetos y sus relaciones al momento de
ejecución
|
Estructura
|
Bajo
|
Comunicación
|
Muestra los objetos,
sus relaciones y los mensajes que fluyen entre ellos.
|
Comportamiento
|
Bajo
|
Estructura
compuesta
|
Representa la estructura interna de un clasificador (tal como una clase, componente, o caso de uso)
|
Estructura
|
Bajo
|
Vistas
de interacción
|
Una
variante de un diagrama de actividad que una visión general del flujo de control dentro de un proceso del sistema o de negocios
|
Bajo
|
|
Tiempo
|
Normalmente se utiliza para mostrar el cambio en el estado de un objeto a través del tiempo
en respuesta a eventos externos.
|
Bajo
|
P: ¿Por qué tengo que modelar?
R: porque..
- Ayuda a visualizar el sistema que se requiere
- Permite especificar la estructura o comportamiento de un sistema
- Conforma una plantilla que guía la construcción de un sistema
- Documenta decisiones
R: No, solo los que se adapten a tu sistema (recuerda 20-80), que mejor lo representen y también con los que te sientas más a gusto.
P: ¿Siempre debo modelar con UML?
R: Siempre y cuando le agregue valor al proyecto!!
Nos seguimos leyendo.
Comentarios