Ave Coder!
¿Tienes una idea genial del producto, pero no quieres quedar empantanado en el código y perder toda la imagen debido a pequeños detalles? ¿Estás a punto de sentarte ante el charlatán de un servidor corporativo y necesitas rellenar algo genial y TI?
Esta serie de artículos estará dedicada a un conocimiento útil, pero a veces escurridizo del crecimiento joven: diagramas UML. Y comenzaré con una revisión de los diagramas existentes, hablemos un poco sobre la historia y por qué debería haber tantos diagramas.
UML es la abreviatura de Unified Modeling Language y, como sabemos, es un lenguaje de modelado estandarizado compuesto por un conjunto integrado de diagramas diseñados para ayudar a los desarrolladores de sistemas y software a definir, visualizar, diseñar y documentar artefactos de sistemas de software, y , por ejemplo, para el modelado de negocios.
UML es un conjunto de mejores prácticas de ingeniería que han demostrado ser efectivas en el modelado de sistemas grandes y complejos y es una parte muy importante del desarrollo de software orientado a objetos.
UML utiliza principalmente la notación gráfica para expresar el diseño de proyectos de software. El uso de UML ayuda a los equipos de diseño a comunicarse, explorar proyectos potenciales y validar el diseño arquitectónico del software.
El origen de UML
El objetivo del UML es proporcionar una notación estándar que pueda ser utilizada por todos los métodos orientados a objetos, y seleccionar e integrar los mejores elementos de las anotaciones predecesoras. UML ha sido desarrollado para una amplia gama de aplicaciones. En consecuencia, proporciona diseños para una amplia gama de sistemas y actividades (por ejemplo, sistemas distribuidos, análisis, diseño e implementación de sistemas).
El UML no surgió desde cero, fue precedido por varios eventos, personalidades y metodologías importantes. Por ejemplo:
- OMT [James Rumbaugh 1991], .
- Booch [Grady Booch 1994] — . - . , , , , .
- OOSE (- [Ivar Jacobson 1992]) — , — , , .
En 1994, Jim Rambo no debía confundirse con John Rambo, aunque Jim también era genial porque fue, por un momento, el creador de la técnica de modelado de objetos anterior, sorprendió al mundo del software cuando dejó General Electric y se unió a Grady Butch en Rational Corp. El objetivo de la asociación era combinar sus ideas en un único método unificado (el nombre de trabajo del método realmente era: "El método unificado").
En 1995, el creador de OOSE, Ivar Jacobson, también se había unido a Rational, y sus ideas (en particular, el concepto de "casos de uso") se incorporaron a un nuevo método unificado, ahora llamado Lenguaje Unificado de Modelado.
En contraste con la conocida Banda de los Cuatro, el Equipo Rumbo, Buch y Jacobson son conocidos como los Tres Amigos.
El UML también ha sido influenciado por otras notaciones orientadas a objetos:
- Mellor y Schlaer [1998]
- Coad y Yourdon [1995]
- Wirfs-Brock [1990]
- Martin y Odell [1992]
El UML también incluye nuevos conceptos que no se encontraban en otros métodos convencionales en ese momento, como los mecanismos de extensión y el lenguaje de restricción.
¿Por qué UML?
A medida que el valor estratégico del software aumentó para muchas empresas, la industria buscó métodos para automatizar la producción de software, así como para mejorar la calidad y reducir los costos y el tiempo de comercialización.
Estas técnicas incluyen tecnología de componentes, programación visual, plantillas y estructuras.
Las empresas también están buscando métodos para gestionar la complejidad de los sistemas a medida que se amplían.
En particular, reconocen la necesidad de abordar problemas arquitectónicos recurrentes como la distribución física, la concurrencia, la replicación, la seguridad, el equilibrio de carga y la tolerancia a fallas.
Además, el desarrollo web, si bien simplifica las cosas, generalmente agrava estos problemas arquitectónicos.
El lenguaje de modelado unificado (UML) se desarrolló para satisfacer estas necesidades.
Los objetivos principales del diseño UML son:
- Proporcione a los usuarios un lenguaje de modelado visual expresivo y listo para que puedan desarrollar y compartir modelos significativos.
- Proporcione mecanismos de extensibilidad y especialización para expandir los conceptos centrales.
- Sea independiente de lenguajes de programación específicos y procesos de desarrollo.
- Proporcionar un marco formal para comprender el lenguaje de modelado.
- Fomentar el crecimiento del mercado de herramientas orientadas a objetos.
- Soporte para conceptos de diseño de alto nivel como colaboración, estructuras, plantillas y componentes.
- Integrar las mejores prácticas.
Los diagramas UML se dividen en dos tipos: estos son diagramas estructurales y diagramas de comportamiento.
Los diagramas estructurales muestran la estructura estática del sistema y sus partes en diferentes niveles de abstracción e implementación, así como su relación. Los elementos en un diagrama de estructura representan conceptos significativos del sistema y pueden incluir conceptos abstractos, del mundo real y de implementación. Hay siete tipos de diagramas de estructura:
- Diagrama de estructura compuesta
- Diagrama de implementación
- Diagrama del paquete
- Gráfico de perfil
- Diagrama de clase
- Diagrama de objeto
- Diagrama de componentes
Los diagramas de comportamiento muestran el comportamiento dinámico de los objetos en un sistema, que puede describirse como una serie de cambios en el sistema a lo largo del tiempo. Los diagramas de comportamiento incluyen:
- Diagrama de actividad
- Use el diagrama del caso
- Diagrama de estado
- Diagrama de secuencia
- Diagrama de comunicaciones
- Cuadro general de interacción
- Tabla de tiempos
Ahora unas pocas palabras sobre cada uno de ellos.
Diagrama de clase
El diagrama de clases es una técnica de modelado central que se utiliza en casi todos los métodos orientados a objetos. Este diagrama describe los tipos de objetos en el sistema y los diferentes tipos de relaciones estáticas que existen entre ellos.
Los tres tipos de relaciones más importantes en los diagramas de clase (en realidad hay más de ellos) son:
Asociación, que representa la relación entre instancias de los tipos, por ejemplo, una persona trabaja para una empresa, una empresa tiene varias oficinas.
Herencia, que coincide estrechamente con la herencia en el diseño orientado a objetos.
Agregación, que es una forma de composición de objetos en diseño orientado a objetos.
Diagrama de componentes
En el lenguaje de modelado unificado, un diagrama de componentes muestra cómo los componentes se unen para formar componentes más grandes o sistemas de software.
Ilustra las arquitecturas de los componentes de software y las dependencias entre ellos.
Estos componentes de software incluyen componentes en tiempo de ejecución, componentes ejecutables y componentes de código fuente.
Diagrama de implementación
Un diagrama de implementación ayuda a simular el aspecto físico de un sistema de software orientado a objetos. Este es un diagrama de bloques que muestra la arquitectura del sistema como el despliegue (distribución) de artefactos de software.
Los artefactos son elementos específicos en el mundo físico que son el resultado de un proceso de desarrollo.
El diagrama modela la configuración de tiempo de ejecución en una vista estática y visualiza la distribución de artefactos en la aplicación.
En la mayoría de los casos, esto incluye modelar configuraciones de hardware junto con los componentes de software en los que se encuentran.
Diagrama de objeto
Un diagrama de objeto estático es una instancia de un diagrama de clase; Muestra una instantánea del estado detallado del sistema en un momento determinado. La diferencia es que un diagrama de clase es un modelo abstracto de clases y sus relaciones.
Sin embargo, un diagrama de objeto es una instancia en un momento particular que es de naturaleza específica. El uso de diagramas de objeto es bastante limitado, es decir, para mostrar ejemplos de estructura de datos.
Diagrama del paquete
Un diagrama de paquete es un diagrama estructural UML que muestra paquetes y las dependencias entre ellos.
Le permite mostrar diferentes vistas del sistema, por ejemplo, es fácil modelar una aplicación de varios niveles.
Diagrama de estructura compuesta
El diagrama de estructura compuesta es similar al diagrama de clase y es un tipo de diagrama de componentes que se usa principalmente en el modelado de sistemas a nivel micro, pero representa partes individuales en lugar de clases enteras. Es un tipo de diagrama de estructura estática que muestra la estructura interna de una clase y las interacciones que esta estructura hace posible.
Este diagrama puede incluir partes internas, puertos a través de los cuales las partes interactúan entre sí o mediante qué instancias de clase interactúan con partes y el mundo exterior, y conectores entre partes o puertos. Una estructura compuesta es una colección de elementos interrelacionados que interactúan en tiempo de ejecución para lograr un objetivo. Cada elemento tiene un papel en la colaboración.
Gráfico de perfil
El diagrama de perfil nos permite crear estereotipos específicos de dominio y de plataforma y determinar la relación entre ellos. Podemos crear estereotipos dibujando formas de estereotipos y asociándolos con la composición o generalización a través de una interfaz orientada a los recursos. También podemos definir y visualizar valores de estereotipo.
Use el diagrama del caso
Un diagrama de casos de uso describe los requisitos funcionales de un sistema en términos de casos de uso. En esencia, es un modelo de la funcionalidad prevista del sistema (casos de uso) y su entorno (actores).
Los casos de uso nos permiten vincular lo que necesitamos del sistema con cómo el sistema satisface esas necesidades.
Diagrama de actividad
Los diagramas de actividad son representaciones gráficas de flujos de trabajo paso a paso y paso a paso con soporte para selección, iteración y concurrencia.
Describen el flujo de control del sistema de destino, como el estudio de reglas y operaciones comerciales complejas, así como los casos de uso y los procesos comerciales.
En UML, los diagramas de actividad están diseñados para modelar procesos computacionales y organizacionales.
Diagrama de estado
Un diagrama de estado es un tipo de diagrama utilizado en UML para describir el comportamiento de los sistemas, que se basa en el concepto de diagramas de estado de David Harel. Los diagramas de estado muestran los estados y las transiciones habilitados, y los eventos que afectan esas transiciones. Le ayuda a visualizar todo el ciclo de vida de los objetos y, por lo tanto, le ayuda a comprender mejor los sistemas basados en estado.
Diagrama de secuencia
Un diagrama de secuencia modela la interacción de objetos basándose en una secuencia de tiempo. Muestra cómo algunos objetos interactúan con otros en un caso de uso específico.
Diagrama de comunicación
Al igual que un diagrama de secuencia, un diagrama de comunicación también se usa para modelar el comportamiento dinámico de un caso de uso. En comparación con un diagrama de secuencia, el diagrama de comunicación se centra más en mostrar la interacción de los objetos en lugar de una secuencia temporal. De hecho, el diagrama de comunicación y el diagrama de secuencia son semánticamente equivalentes y pueden fluir entre sí.
Cuadro general de interacción
El diagrama de resumen de interacción se centra en el resumen del flujo de gestión de interacción. Esta es una variante del Diagrama de actividad donde los nodos son interacciones o eventos de interacción. El diagrama de descripción general de interacciones describe las interacciones en las que se ocultan los mensajes y las líneas de vida. Podemos vincular diagramas "reales" y lograr un alto grado de navegación entre diagramas dentro de un diagrama de visión general de interacción.
Tabla de tiempos
El diagrama de tiempos muestra el comportamiento de los objetos en un período de tiempo determinado. De hecho, esta es una forma especial del diagrama de secuencia y las diferencias entre ellos son que los ejes se intercambian para que el tiempo aumente de izquierda a derecha, y las líneas de vida se muestran en compartimentos separados ubicados verticalmente.
¿Por qué hay tantos diagramas en UML?
La razón de esto es que puede ver el sistema desde diferentes puntos de vista, porque muchos interesados estarán involucrados en el desarrollo de software, tales como: analistas, diseñadores, codificadores, probadores, control de calidad, clientes, autores técnicos.
Todas estas personas están interesadas en diferentes aspectos del sistema, y cada una requiere un nivel de detalle diferente.
Por ejemplo, el codificador debe comprender el diseño del sistema y poder convertir el diseño en código de bajo nivel.
Por el contrario, un escritor técnico está interesado en el comportamiento del sistema en su conjunto y debe comprender cómo funciona el producto.
El UML intenta proporcionar un lenguaje de manera tan expresiva que todos los interesados puedan beneficiarse de al menos un diagrama UML.
Para aquellos que son demasiado flojos para leer:
¡Cra!