UML – Introducción Tardía

El otro día les refrrescaba acerca de los conectores en los gráficos UML; y no me avivé que quizás muchos de ustedes ni siquiera sepan que es el UML… Mala mía.

Así que me voy a tomar un rato y les voy a contar o a refrescar.

Unified Modeling Language (UML) es un lenguaje de modelado de propósito general. El objetivo principal de UML es definir una forma estándar de visualizar la forma en que se ha diseñado un sistema. Es bastante similar a los planos utilizados en otros campos de la ingeniería.

UML no es un lenguaje de programación, es más bien un lenguaje visual. Usamos diagramas UML para representar el comportamiento y la estructura de un sistema. UML ayuda a los ingenieros de software, empresarios y arquitectos de sistemas con modelado, diseño y análisis. El Object Management Group (OMG) (sí, en su momento yo también pensé que era joda y que era el Oh My God!) adoptó el lenguaje de modelado unificado como estándar en 1997. Desde entonces, ha sido administrado por OMG. La Organización Internacional de Normalización (ISO) publicó el UML como un estándar aprobado en 2005. El UML se ha revisado a lo largo de los años y se revisa periódicamente.

¿Realmente necesitamos UML?

Las aplicaciones complejas necesitan colaboración y planificación de múltiples equipos y, por lo tanto, requieren una forma clara y concisa de comunicarse entre ellas.

Los hombres de negocios no entienden el código. Por lo tanto, UML se vuelve esencial para comunicarse con los requisitos, funcionalidades y procesos esenciales del sistema.

Además, se ahorra mucho tiempo cuando los equipos pueden visualizar los procesos, las interacciones del usuario y la estructura estática del sistema.

UML está vinculado con el diseño y análisis orientado a objetos. UML hace uso de elementos y asociaciones de formas entre ellos para formar diagramas.

Los diagramas en UML se pueden clasificar como:

Diagramas estructurales: captura aspectos estáticos o estructura de un sistema. Los diagramas estructurales incluyen: Diagramas de componentes, diagramas de objetos, diagramas de clases y diagramas de despliegue.
Diagramas de comportamiento: captura aspectos dinámicos o el comportamiento del sistema. Los diagramas de comportamiento incluyen: Diagramas de casos de uso, Diagramas de estados, Diagramas de actividades y Diagramas de interacción.

La imagen a continuación muestra la jerarquía de diagramas de acuerdo con UML 2.2

Conceptos orientados a objetos utilizados en UML

Clase: Una clase define la impresión azul, es decir, la estructura y las funciones de un objeto.
Objetos: los objetos nos ayudan a descomponer los sistemas grandes y nos ayudan a modularizar nuestro sistema. La modularidad ayuda a dividir nuestro sistema en componentes comprensibles para que podamos construir nuestro sistema pieza por pieza. Un objeto es la unidad fundamental (bloque de construcción) de un sistema que se utiliza para representar una entidad.
Herencia: la herencia es un mecanismo por el cual las clases secundarias heredan las propiedades de sus clases principales.
Abstracción: mecanismo mediante el cual los detalles de implementación están ocultos para el usuario.
Encapsulación: vincular datos juntos y protegerlos del mundo exterior se conoce como encapsulación.
Polimorfismo – Mecanismo por el cual las funciones o entidades pueden existir en diferentes formas.

Adiciones en UML 2.0

Se han incorporado metodologías de desarrollo de software ágiles y se ha ampliado el alcance de la especificación UML original.
Originalmente UML especificó 9 diagramas. UML 2.x ha aumentado el número de diagramas de 9 a 13. Los cuatro diagramas que se agregaron son: diagrama de tiempo, diagrama de comunicación, diagrama de descripción general de interacción y diagrama de estructura compuesta. UML 2.x renombró diagramas de estado para indicar diagramas de máquina.
UML 2.x agregó la capacidad de descomponer el sistema de software en componentes y subcomponentes.

Diagramas UML estructurales

Diagrama de clase: el diagrama UML que más se usa es el diagrama de clases. Es el componente básico de todos los sistemas de software orientados a objetos. Usamos diagramas de clase para representar la estructura estática de un sistema al mostrar las clases del sistema, sus métodos y atributos. Los diagramas de clase también nos ayudan a identificar la relación entre diferentes clases u objetos.

Diagrama de estructura compuesta: utilizamos diagramas de estructura compuesta para representar la estructura interna de una clase y sus puntos de interacción con otras partes del sistema. Un diagrama de estructura compuesta representa la relación entre las partes y su configuración que determina cómo se comporta el clasificador (clase, componente o nodo de implementación). Representan la estructura interna de una clase estructurada que hace uso de partes, puertos y conectores. También podemos modelar colaboraciones usando diagramas de estructura compuesta. Son similares a los diagramas de clases, excepto que representan partes individuales en detalle en comparación con toda la clase.

Diagrama de objeto: un diagrama de objeto se puede denominar como una captura de pantalla de las instancias de un sistema y la relación que existe entre ellas. Como los diagramas de objetos representan el comportamiento cuando los objetos han sido instanciados, podemos estudiar el comportamiento del sistema en un instante particular. Un diagrama de objeto es similar a un diagrama de clase, excepto que muestra las instancias de las clases en el sistema. Representamos Clases reales y sus relaciones haciendo uso de diagramas de clase. Por otro lado, un diagrama de objetos representa instancias específicas de clases y relaciones entre ellos en un punto de tiempo.

Diagrama de componentes: los diagramas de componentes se utilizan para representar cómo se han organizado los componentes físicos en un sistema. Los usamos para modelar detalles de implementación. Los Diagramas de componentes representan la relación estructural entre los elementos del sistema de software y nos ayudan a comprender si los requisitos funcionales han sido cubiertos por el desarrollo planificado. Los Diagramas de componentes se vuelven esenciales para usar cuando diseñamos y construimos sistemas complejos. Las interfaces son utilizadas por los componentes del sistema para comunicarse entre sí.

Diagrama de implementación: los diagramas de implementación se utilizan para representar el hardware del sistema y su software. Nos dice qué componentes de hardware existen y qué componentes de software se ejecutan en ellos. Ilustramos la arquitectura del sistema como distribución de artefactos de software sobre objetivos distribuidos. Un artefacto es la información que genera el software del sistema. Se usan principalmente cuando se distribuye o implementa un software en varias máquinas con diferentes configuraciones.

Diagrama de paquete: utilizamos diagramas de paquete para representar cómo se han organizado los paquetes y sus elementos. Un diagrama de paquete simplemente nos muestra las dependencias entre diferentes paquetes y la composición interna de los paquetes. Los paquetes nos ayudan a organizar diagramas UML en grupos significativos y hacen que el diagrama sea fácil de entender. Se usan principalmente para organizar clases y diagramas de casos de uso.

Diagramas de comportamiento

Diagramas de máquina de estado: un diagrama de estado se usa para representar la condición del sistema o parte del sistema en instancias de tiempo finitas. Es un diagrama de comportamiento y representa el comportamiento utilizando transiciones de estado finito. Los diagramas de estado también se conocen como máquinas de estado y diagramas de gráfico de estado. Estos términos a menudo se usan indistintamente. De manera simple, un diagrama de estado se usa para modelar el comportamiento dinámico de una clase en respuesta al tiempo y el cambio de estímulos externos.

Diagramas de actividad: utilizamos diagramas de actividad para ilustrar el flujo de control en un sistema. También podemos usar un diagrama de actividad para referirnos a los pasos involucrados en la ejecución de un caso de uso. Modelamos actividades secuenciales y concurrentes usando diagramas de actividad. Entonces, básicamente representamos los flujos de trabajo visualmente usando un diagrama de actividad. Un diagrama de actividad se enfoca en la condición del flujo y la secuencia en la que ocurre. Describimos o representamos lo que causa un evento en particular usando un diagrama de actividad.

Diagramas de casos de uso: los diagramas de casos de uso se utilizan para representar la funcionalidad de un sistema o una parte de un sistema. Se usan ampliamente para ilustrar los requisitos funcionales del sistema y su interacción con agentes externos (actores). Un caso de uso es básicamente un diagrama que representa diferentes escenarios donde se puede usar el sistema. Un diagrama de casos de uso nos proporciona una visión de alto nivel de lo que hace el sistema o una parte del sistema sin entrar en detalles de implementación.

Diagrama de secuencia: un diagrama de secuencia simplemente representa la interacción entre objetos en un orden secuencial, es decir, el orden en el que tienen lugar estas interacciones. También podemos usar los términos diagramas de eventos o escenarios de eventos para referirnos a un diagrama de secuencia. Los diagramas de secuencia describen cómo y en qué orden funcionan los objetos en un sistema. Estos diagramas son ampliamente utilizados por empresarios y desarrolladores de software para documentar y comprender los requisitos de los sistemas nuevos y existentes.

Diagrama de comunicación: un diagrama de comunicación (conocido como Diagrama de colaboración en UML 1.x) se usa para mostrar mensajes secuenciados intercambiados entre objetos. Un diagrama de comunicación se enfoca principalmente en los objetos y sus relaciones. Podemos representar información similar usando diagramas de Secuencia, sin embargo, los diagramas de comunicación representan objetos y enlaces en forma libre.

Diagrama de sincronización: son una forma especial de diagramas de secuencia que se utilizan para representar el comportamiento de los objetos en un marco de tiempo. Los usamos para mostrar las restricciones de tiempo y duración que rigen los cambios en los estados y el comportamiento de los objetos.

Diagrama de visión general de interacción: un diagrama de visión general de interacción modela una secuencia de acciones y nos ayuda a simplificar interacciones complejas en casos más simples. Es una mezcla de actividad y diagramas de secuencia.