Una introducción al lenguaje de modelado unificado
En el siglo XX, en 1997, para ser exactos, el Object Management Group (OMG) lanzó el Lenguaje de modelado unificado (UML). Uno de los propósitos de UML era proporcionar a la comunidad de desarrollo un lenguaje de diseño estable y común que pudiera usarse para desarrollar y construir aplicaciones informáticas. UML presentó una notación de modelado estándar unificada que los profesionales de TI habían estado buscando durante años. Usando UML, los profesionales de TI ahora pueden leer y difundir la estructura del sistema y los planes de diseño, tal como lo han estado haciendo los trabajadores de la construcción durante años con planos de edificios.
Ahora es el siglo XXI, 2003 para ser precisos, y UML ha ganado fuerza en nuestra profesión. En el 75 por ciento de los currículos que veo, hay un punto de viñeta que afirma tener conocimiento de UML. Sin embargo, después de hablar con la mayoría de estos candidatos de trabajo, queda claro que realmente no conocen UML. Por lo general, lo usan como una palabra de moda o han tenido un poco de exposición a UML. Esta falta de comprensión me inspiró a escribir esta rápida introducción a UML, centrada en los diagramas básicos utilizados en el modelado visual. Cuando termine de leer, no tendrá suficiente conocimiento para incluir UML en su currículum, pero tendrá un punto de partida para profundizar en el lenguaje.
Un poco de fondo
Como mencioné, UML estaba destinado a ser un lenguaje unificador que permitiera a los profesionales de TI modelar aplicaciones informáticas. Los autores principales fueron Jim Rumbaugh, Ivar Jacobson y Grady Booch, quienes originalmente tenían sus propios métodos de competencia (OMT, OOSE y Booch). Eventualmente, unieron fuerzas y lograron un estándar abierto. (¿Le suena familiar? Un fenómeno similar generó J2EE, SOAP y Linux). Una razón por la que UML se ha convertido en un lenguaje de modelado estándar es que es independiente del lenguaje de programación. (Las herramientas de modelado UML de IBM Rational se usan ampliamente en las tiendas J2EE y en las tiendas .NET). Además, el conjunto de notación UML es un lenguaje y no una metodología. Esto es importante, porque un lenguaje, a diferencia de una metodología, puede encajar fácilmente en la forma en que una empresa realiza negocios sin necesidad de cambios.
Dado que UML no es una metodología, no requiere ningún producto de trabajo formal (es decir, "artefactos" en la jerga de IBM Rational Unified Process®). Sin embargo, proporciona varios tipos de diagramas que, cuando se utilizan dentro de una metodología determinada, aumentan la facilidad de comprensión de una aplicación en desarrollo. UML es más que estos diagramas, pero para mis propósitos aquí, los diagramas ofrecen una buena introducción al lenguaje y los principios detrás de su uso. Al colocar diagramas UML estándar en los productos de trabajo de su metodología, hace que sea más fácil para las personas con conocimientos de UML unirse a su proyecto y convertirse rápidamente en productivos. Los diagramas UML estándar más útiles son: diagrama de casos de uso, diagrama de clases, diagrama de secuencia, diagrama de estado, diagrama de actividades, diagrama de componentes y diagrama de implementación.
Está fuera del alcance de este artículo introductorio entrar en gran detalle sobre cada tipo de diagrama. En su lugar, le proporcionaré información suficiente para una comprensión general de cada uno y luego proporcionaré más detalles en artículos posteriores.
Diagrama de caso de uso
Un caso de uso ilustra una unidad de funcionalidad proporcionada por el sistema. El propósito principal del diagrama de casos de uso es ayudar a los equipos de desarrollo a visualizar los requisitos funcionales de un sistema, incluida la relación de los "actores" (seres humanos que interactuarán con el sistema) con los procesos esenciales, así como las relaciones entre diferentes casos de uso. Los diagramas de casos de uso generalmente muestran grupos de casos de uso, ya sea todos los casos de uso para el sistema completo o un desglose de un grupo particular de casos de uso con funcionalidad relacionada (por ejemplo, todos los casos de uso relacionados con la administración de seguridad). Para mostrar un caso de uso en un diagrama de casos de uso, dibuje un óvalo en el centro del diagrama y ponga el nombre del caso de uso en el centro, o debajo, del óvalo. Para dibujar un actor (que indica un usuario del sistema) en un diagrama de casos de uso, dibuje una persona del palo a la izquierda o derecha del diagrama (y en caso de que se lo pregunte, algunas personas dibujan personas del palo más bonitas que otras). Use líneas simples para representar relaciones entre actores y casos de uso, como se muestra en la Figura 1.
 |
| Figura 1: Ejemplo de diagrama de caso de uso
|
Un diagrama de casos de uso se usa normalmente para comunicar las funciones de alto nivel del sistema y el alcance del mismo. Al observar nuestro diagrama de casos de uso en la Figura 1, puede ver fácilmente las funciones que proporciona nuestro sistema de ejemplo. Este sistema le permite al administrador de la banda ver un informe de estadísticas de ventas y el informe Billboard 200 para los CD de la banda. También le permite al administrador de registros ver un informe de estadísticas de ventas y el informe Billboard 200 para un CD en particular. El diagrama también nos dice que nuestro sistema entrega informes de Billboard desde un sistema externo llamado Billboard Reporting Service.
Además, la ausencia de casos de uso en este diagrama muestra lo que el sistema no hace. Por ejemplo, no proporciona una forma para que un administrador de banda escuche canciones de los diferentes álbumes en el Billboard 200, es decir, no vemos ninguna referencia a un caso de uso llamado Listen to Songs from Billboard 200. Esta ausencia no es una trivialidad. Con las descripciones de casos de uso claras y simples proporcionadas en dicho diagrama, un patrocinador del proyecto puede ver fácilmente si la funcionalidad necesaria está presente o no en el sistema.
Diagrama de clase
El diagrama de clase muestra cómo las diferentes entidades (personas, cosas y datos) se relacionan entre sí; en otras palabras, muestra las estructuras estáticas del sistema. Se puede usar un diagrama de clase para mostrar las clases lógicas, que suelen ser el tipo de cosas de las que hablan los empresarios de una organización: bandas de rock, CD, juegos de radio; o préstamos, hipotecas, préstamos para automóviles y tasas de interés. Los diagramas de clase también se pueden usar para mostrar las clases de implementación, que son las cosas con las que los programadores suelen lidiar. Sin embargo, un diagrama de clase de implementación probablemente mostrará algunas de las mismas clases que el diagrama de clases lógicas. Sin embargo, el diagrama de clase de implementación no se dibujará con los mismos atributos, ya que probablemente tenga referencias a cosas como Vectores y HashMaps.
Una clase se representa en el diagrama de la clase como un rectángulo con tres secciones horizontales, como se muestra en la Figura 2. La sección superior muestra el nombre de la clase; la sección del medio contiene los atributos de la clase; y la sección inferior contiene las operaciones de la clase (o "métodos").
 |
Figura 2: Ejemplo de objeto de clase en un diagrama de clase
|
|
En mi experiencia, casi todos los desarrolladores saben qué es este diagrama, pero me parece que la mayoría de los programadores dibujan las líneas de relación incorrectamente. Para un diagrama de clase como el de la Figura 3, debe dibujar la relación de herencia 1 utilizando una línea con una punta de flecha en la parte superior que apunta a la superclase, y la punta de flecha debe ser un triángulo completado. (Nota: Para obtener más información sobre la herencia y otros principios orientados a objetos, consulte el tutorial de Java ¿Qué es la herencia?) Una relación de asociación debe ser una línea sólida si ambas clases se conocen entre sí y una línea con una punta de flecha abierta si la asociación Es conocido por una sola de las clases.
 |
Figura 3: un diagrama de clase completo, que incluye el objeto de clase que se muestra en la Figura 2
|
|
En la Figura 3, vemos tanto la relación de herencia como las dos relaciones de asociación. La clase CDSalesReport se hereda de la clase Report. Un CDSalesReport está asociado con un CD, pero la clase de CD no sabe nada sobre la clase CDSalesReport. El CD y las clases de banda se conocen entre sí, y ambas clases pueden estar asociadas a una o más de la otra.
Un diagrama de clase puede incorporar muchos más conceptos, que cubriremos más adelante en esta serie de artículos.
Diagrama de secuencia
Los diagramas de secuencia muestran un flujo detallado para un caso de uso específico o incluso solo una parte de un caso de uso específico. Son casi autoexplicativos; muestran las llamadas entre los diferentes objetos en su secuencia y pueden mostrar, a un nivel detallado, diferentes llamadas a diferentes objetos.
Un diagrama de secuencia tiene dos dimensiones: la dimensión vertical muestra la secuencia de mensajes / llamadas en el orden de tiempo en que ocurren; La dimensión horizontal muestra las instancias de objeto a las que se envían los mensajes.
Un diagrama de secuencia es muy simple de dibujar. En la parte superior de su diagrama, identifique las instancias de clase (objetos) colocando cada instancia de clase dentro de un cuadro (consulte la Figura 4). En el cuadro, coloque el nombre de la instancia de la clase y el nombre de la clase separados por un espacio / dos puntos / espacio ”:” (por ejemplo, myReportGenerator: ReportGenerator). Si una instancia de clase envía un mensaje a otra instancia de clase, dibuje una línea con una punta de flecha abierta apuntando a la instancia de clase receptora; coloque el nombre del mensaje / método sobre la línea. Opcionalmente, para mensajes importantes, puede dibujar una línea de puntos con una punta de flecha apuntando hacia la instancia de la clase de origen; etiqueta el valor de retorno por encima de la línea de puntos. Personalmente, siempre me gusta incluir las líneas de valor de retorno porque encuentro que los detalles adicionales facilitan la lectura.
Leer un diagrama de secuencia es muy simple. Comience en la esquina superior izquierda con la instancia de clase "controlador" que inicia la secuencia. Luego sigue cada mensaje en el diagrama. Recuerde: aunque el diagrama de secuencia de ejemplo de la Figura 4 muestra un mensaje de retorno para cada mensaje enviado, esto es opcional.
 |
Figura 4: un diagrama de secuencia de muestra
|
|
Al leer nuestro diagrama de secuencia de muestra en la Figura 4, puede ver cómo crear un Informe de ventas de CD. El objeto aServlet es nuestro controlador de ejemplo. aServlet envía un mensaje a la instancia de la clase ReportGenerator denominada gen. El mensaje está etiquetado genera CDSalesReport, lo que significa que el objeto ReportGenerator implementa este controlador de mensajes. En una inspección más cercana, la etiqueta del mensaje generateCDSalesReport tiene cdId entre paréntesis, lo que significa que aServlet está pasando una variable llamada cdId con el mensaje. Cuando la instancia gen recibe un mensaje generateCDSalesReport, luego realiza llamadas subsiguientes a la clase CDSalesReport, y se devuelve una instancia real de un CDSalesReport llamado aCDReport. La instancia gen luego realiza llamadas a la instancia aCDReport devuelta, pasándole parámetros en cada llamada de mensaje. Al final de la secuencia, la instancia gen devuelve aCDReport a su llamador aServlet.
Tenga en cuenta que: el diagrama de secuencia en la Figura 4 es posiblemente demasiado detallado para un diagrama de secuencia típico. Sin embargo, creo que es lo suficientemente simple de entender, y muestra cómo se dibujan las llamadas anidadas. Además, con los desarrolladores junior, a veces es necesario dividir las secuencias a este nivel explícito para ayudarles a comprender lo que se supone que deben hacer.
Diagrama de estado
El diagrama de estados modela los diferentes estados en los que puede estar una clase y cómo esa clase hace la transición de un estado a otro. Se puede argumentar que cada clase tiene un estado, pero que todas las clases no deberían tener un diagrama de estado de cuenta. Solo se deben modelar las clases con estados "interesantes", es decir, las clases con tres o más estados potenciales durante la actividad del sistema.
Como se muestra en la Figura 5, el conjunto de notación del diagrama de estado de la carta tiene cinco elementos básicos: el punto de inicio inicial, que se dibuja utilizando un círculo sólido; una transición entre estados, que se dibuja utilizando una línea con una punta de flecha abierta; un estado, que se dibuja utilizando un rectángulo con esquinas redondeadas; un punto de decisión, que se dibuja como un círculo abierto; y uno o más puntos de terminación, que se dibujan utilizando un círculo con un círculo sólido dentro de él. Para dibujar un diagrama de estado, comienza con un punto de inicio y una línea de transición que apunta al estado inicial de la clase. Dibuje los estados en cualquier lugar del diagrama y luego conéctelos utilizando las líneas de transición de estado.
 |
Figura 5: Diagrama de Statechart que muestra los diversos estados por los que pasan las clases en un sistema que funciona
|
|
El ejemplo del diagrama de estado de la figura 5 muestra parte de la información potencial que pueden comunicar. Por ejemplo, puede indicar que el procesamiento del préstamo comienza en el estado de Solicitud de préstamo. Cuando se realiza el proceso de aprobación previa, dependiendo del resultado, se pasa al estado Preaprobado del préstamo o al estado Rechazo del préstamo. Esta decisión, que se toma durante el proceso de transición, se muestra con un punto de decisión: el círculo vacío en la línea de transición. Al observar el ejemplo, una persona puede decir que un préstamo no puede pasar del estado de preaprobación de préstamo al estado de mantenimiento de préstamo sin pasar por el estado de cierre de préstamo. Además, al observar nuestro diagrama de ejemplo, una persona puede decir que todos los préstamos finalizarán en el estado de Préstamo rechazado o en el Estado de Préstamo en mantenimiento.
Diagrama de actividad
Los diagramas de actividad muestran el flujo de control de procedimiento entre dos o más objetos de clase al procesar una actividad. Los diagramas de actividad se pueden usar para modelar procesos de negocios de nivel superior a nivel de unidad de negocios o para modelar acciones de clase internas de bajo nivel. En mi experiencia, los diagramas de actividad se utilizan mejor para modelar procesos de nivel superior, como la forma en que la empresa está haciendo negocios actualmente, o cómo le gustaría hacer negocios. Esto se debe a que los diagramas de actividad tienen una apariencia "menos técnica" en comparación con los diagramas de secuencia, y las personas con mentalidad comercial tienden a entenderlos más rápidamente.
El conjunto de notación de un diagrama de actividad es similar al que se usa en un diagrama de gráfico de estado. Al igual que un diagrama de estado, el diagrama de actividad comienza con un círculo sólido conectado a la actividad inicial. La actividad se modela dibujando un rectángulo con bordes redondeados, encerrando el nombre de la actividad. Las actividades se pueden conectar a otras actividades a través de líneas de transición o a puntos de decisión que se conectan a diferentes actividades protegidas por las condiciones del punto de decisión. Las actividades que terminan el proceso modelado están conectadas a un punto de terminación (igual que en un diagrama de estado). Opcionalmente, las actividades se pueden agrupar en swimlanes, que se utilizan para indicar el objeto que realmente realiza la actividad, como se muestra en la Figura 6.
 |
| Figura 6: Diagrama de actividad, con dos swimlanes para indicar el control de la actividad por dos objetos: el administrador de la banda y la herramienta de informes
|
En nuestro diagrama de actividades de ejemplo, tenemos dos columnas porque tenemos dos objetos que controlan actividades separadas: un administrador de banda y una herramienta de informes. El proceso comienza cuando el gerente de la banda elige ver el informe de ventas de una de sus bandas. La herramienta de informes luego recupera y muestra todas las bandas que la persona maneja y le pide que elija una. Después de que el administrador de la banda selecciona una banda, la herramienta de informes recupera la información de ventas y muestra el informe de ventas. El diagrama de actividad muestra que mostrar el informe es el último paso del proceso.
Diagrama de componentes
Un diagrama de componentes proporciona una vista física del sistema. Su propósito es mostrar las dependencias que el software tiene de los otros componentes del software (por ejemplo, bibliotecas de software) en el sistema. El diagrama se puede mostrar a un nivel muy alto, solo con los componentes de grano grande, o se puede mostrar a nivel de paquete de componentes. (Nota: el nivel de paquete de componente de frase es una forma neutral de lenguaje de programación de referirse a niveles de contenedor de clase como los espacios de nombres de .NET (por ejemplo, System.Web.UI) o los paquetes de Java (por ejemplo, java.util).)
Modelar un diagrama de componentes se describe mejor a través de un ejemplo. La Figura 7 muestra cuatro componentes: Herramienta de informes, Servicio de cartelera, API de Servlet 2.2 y API de JDBC. Las líneas con flechas del componente Reporting Tool al servicio Billboard Service, Servlet 2.2 API y JDBC API significan que Reporting Tool depende de esos tres componentes.
 |
| Figura 7: un diagrama de componentes muestra las interdependencias de varios componentes de software que comprende el sistema
|
Diagrama de despliegue
El diagrama de implementación muestra cómo se implementará físicamente un sistema en el entorno de hardware. Su propósito es mostrar dónde se ejecutarán físicamente los diferentes componentes del sistema y cómo se comunicarán entre sí. Dado que el diagrama modela el tiempo de ejecución físico, el personal de producción de un sistema hará un uso considerable de este diagrama.
La notación en un diagrama de implementación incluye los elementos de notación utilizados en un diagrama de componentes, con un par de adiciones, incluido el concepto de nodo. Un nodo representa una máquina física o un nodo de máquina virtual (por ejemplo, un nodo de mainframe). Para modelar un nodo, simplemente dibuje un cubo tridimensional con el nombre del nodo en la parte superior del cubo. Use la convención de nomenclatura utilizada en los diagramas de secuencia: (nombre de instancia): (tipo de instancia) (por ejemplo, "w3reporting.myco.com: Servidor de aplicaciones").
 |
Figura 8: Diagrama de despliegue
|
|
El diagrama de implementación en la Figura 8 muestra que los usuarios acceden a la herramienta de informes mediante el uso de un navegador que se ejecuta en su máquina local y se conectan a través de la intranet de su compañía a través de HTTP a la herramienta de informes. Esta herramienta se ejecuta físicamente en el servidor de aplicaciones llamado w3reporting.myco.com. El diagrama muestra el componente Reporting Tool dibujado dentro de IBM WebSphere, que a su vez se dibuja dentro del nodo w3.reporting.myco.com. Reporting Tool se conecta a su base de datos de informes utilizando el lenguaje Java a la interfaz JDBC de IBM DB2, que luego se comunica con la base de datos DB2 real que se ejecuta en el servidor llamado db1.myco.com mediante la comunicación nativa de DB2. Además de hablar con la base de datos de informes, el componente Report Tool se comunica a través de SOAP a través de HTTPS al Servicio de Billboard.
Conclusión
Aunque este artículo proporciona solo una breve introducción a Unified Modeling Language, lo aliento a comenzar a aplicar la información que ha aprendido aquí a sus propios proyectos y a profundizar más en UML. Existen varias herramientas de software que lo ayudan a integrar los diagramas UML en su proceso de desarrollo de software, pero incluso sin herramientas automatizadas, puede usar marcadores en una pizarra o papel y lápices para dibujar sus diagramas UML y aún así obtener beneficios.
