UML I: el inicio

A lo largo de lo que llevo de formación universitaria en ciencias computacionales, la insistencia de algunos profesores en el uso de diagramas UML ha sido avasallante. Por mucho tiempo se nos enseñó e insistió en crear diagramas UML de todo tipo para el diseño y documentación de nuestros proyectos.

Sin embargo, cuando me enfrento al mundo laboral ( y escucho experiencias de compañeros, familiares y amigos cercanos en la industria) no se suele escuchar que, durante el proceso de modelación se utilice UML de forma explícita.

Por lo que, al enfrentarme a la tarea de esta semana me genera la duda: ¿Deberíamos estar preguntándonos porqué usar UML o más bien la pregunta adecuada será porqué no usarlo? Y si no debiéramos usarlo, que deberíamos hacer para reemplazarlo?

Durante los post anteriores utilicé la analogía de la construcción de una casa para explicar la importancia del proceso unificado de software (click AQUI). Sin embargo, luego de pensar durante las próximas semanas me di cuenta de que la analogía no es del todo exacta.

En software, puedes construir componentes de forma modular y con débiles conexiones con otros componentes. En un hogar no es así, no puedes reemplazar recámaras así no más, quitando y poniendo baños, ensanchando paredes y alargando techos. No funciona así. En los planos arquitectónicos viene expresada la forma final de la edificación.

Con software, para bien o para mal, al crear un sistema compuesto por otros sistemas ( que podemos soñar considerarlos como cajas negras ) podríamos reemplazar estilos, componentes y elementos del sistema de forma rápida y simple. Lo cual implica que el proyecto tiene una alta probabilidad a ser mutado y en la práctica suele ser así.

Por lo que, como podemos inferir, el proyecto final quizá no quede como en los planos iniciales y si estos servirán como documentación es posible que haya que también modificarlos. Por lo que, ¿Es útil crear planos de productos que no terminarán siendo como dice el diagrama?

Por lo tanto, partí de estas ideas para adentrarme en la red y aprender sobre las opiniones de la gente, lo que dicen por ahí, desde en blogs, tutoriales hasta . . . en Reddit.
Para empezar creo que debo indicar, el bias evidente que hallo sobre las páginas que hablan en favor total del uso de UML, todas ellas portales de herramientas para generación de diagramas y modelos. Sin embargo, sus argumentos no dejan de ser válidos.

Argumentos a favor de UML

Uno de los argumentos a favor es que los diagramas son más fáciles de entender que el texto. Tiene mucho sentido, no por nada dicen que una imagen vale más que mil palabras. ( Sin embargo, esto no sustituye comentar el código de vez en cuando ).

Además, al utilizar un lenguaje bien definido, podemos transmitir ideas a miembros nuevos o ajenos, además es fácil de comprender la estructura del proyecto, incluso para clientes o personas que no posean conocimiento en software. (Draw.io defiende el uso de UML. Tu que opinas? Aqui te dejo sus argumentos. Draw.io es una excelente herramienta online para hacer diagramas. En lo personal, me ha sacado de más de un apuro ).

Una razón interesante para utilizar UML es que es difícil hallar como suplantarlo. UML es un lenguaje de modelado bien definido por lo que, en el modelado de software supera con creces en su simpleza, coherencia y los diagramas UML son excelente referente a lo que se refiere a documentación.

UML para bien o para mal, es el lenguaje estándar para la modelación de software. Por lo tanto, existen infinidad de herramientas y software para la creación de diagramas y que son compatibles para generar ingeniería inversa, modificar diagramas a tiempo real y una infinidad de aplicaciones útiles para diseñar la arquitectura de la aplicación. Además, UML al llevar más de dos décadas en el mercado se ha perfeccionado para cubrir las necesidades de casi cualquier proyecto. ( Razones para usar o no usar UML, un excelente post ).

Razones para no usar UML . . . (?)

Tanto reddit o stackoverflow son buenos lugares para hallar la voz de los programadores. Es interesante que, a pesar de los tantos beneficios que posee UML ( de unificación, estandarización y simpleza ) los programadores en sus ambientes de trabajo utilicen al mínimo estas herramientas. En general la voz pública indica que el uso de UML es bueno, sin embargo la mayoría de las veces es suficiente con el uso de diagramas en pizarrón, además pocos conocen o utilizan muchos de los diagramas. Con los diagramas de clase, secuencia y casos de uso cubren la mayoría de las necesidades de los proyectos.

Algunos otros solamente utilizan los diagramas UML ( más formales ) como documentación. Durante el proceso de diseño y creación ( que constantemente requiere de iteraciones ) prefieren diagramas en pizarrón, y si hay una modificación solo se enfoca en dicha área a cambiar.
Otros desarrolladores dejan los diagramas en la fase de diseño. Otros más extremistas dicen que UML está muerto!

( Si quieres leer más? da click en este foro de reddit o aqui, para hallar los diálogos en StackOverflow).

En este punto que hallo polarizadas opiniones, es necesario desenredar el mar de puntos de vista y de forma atrevida dar una opinión.

Creo que el mayor problema con UML es que no sabemos utilizarlo. Y con saber utilizarlo, me refiero a aprender correctamente todas sus simbologías y tener un entendimiento del significado de estas; como consecuencia de un mal aprendizaje del uso del paradigma orientado a objetos es que no aplicamos UML correctamente.

Por otro lado, a pesar de que existan múltiples herramientas para aplicar UML sea necesaria alguna que transforme la escritura directa y los diagramas a mano que se realizan en las fases de diseño a diagramas digitalizados y formales.

Finalmente, considero que el uso de UML depende mucho de la culturalización de la comunidad de desarrolladores, de darle valor a la fase de diseño de software. Actualmente se considera que el intentar diseñar en su totalidad una aplicación es prácticamente imposible, sin embargo, el constantemente rediseñar una aplicación (sin crecerla o mejorarla, tan solo redefiniendola ) no es viable.

Si en realidad aplicáramos una correcta conceptualización del paradigma orientado a objetos, lo que se requeriría cambiar son tan solo subsistemas aislados, no la totalidad de un producto.
Quizá sea necesario discretizar el diseño de la producción, para tener ingenieros mejor capacitados en ambas áreas ( como el análogo en la construcción con el ingeniero civil y el arquitecto).

Creo que podría concluir con esto: La informalidad de los diagramas depende directamente de que tan probable sea que el proyecto sea mutado considerablemente durante el proceso de construcción. Si en un proyecto no se sabe lo que quiere, ni se tiene una buena formación en el diseño del producto, además de que se utilice un proceso dinámico para la producción del software, es posible que los diagramas formales sean despreciados.

Diagramas UML más comunes

Los diagramas UML se clasifican en dos tipos: Diagramas de estructura y diagramas de comportamiento. Los diagramas de estructura definen la arquitectura del sistema, mientras que los diagramas de comportamiento definen como se relacionarán los componentes internos del sistema entre sí o elementos externos.

Diagramas de clases

Siendo un diagrama estructural, define la construcción del sistema a través de las distintas clases, interfaces, métodos y tipos de datos que contendrá el sistema. Con estos elementos podremos definir que y como está compuesto el sistema, ya que estos elementos representan «el esqueleto» del sistema.

Una definición interesante y sencilla que hallé (aqui )es: Los diagramas de clases explayan los bloques de construcción que constituirán el sistema orientado a objetos.

Los diagramas de clases definen las relaciones entre clases ( componentes ) estas relaciones pueden ser de agregación ( tiene) herencia (generalización, es ) entre otras.

Cada clase contiene los parámetros que describen a la clase, así como los comportamientos permitidos. De esta forma se describe exitosamente las características de la clase y lo que puede hacer. Para nosotros no nos importa por ahora como va a realizar dichos comportamientos, solo se trata de una descripción.

En mi experiencia, es el diagrama que más he utilizado a lo largo de mi desarrollo profesional.

IBM tiene detalladas explicaciones sobre notaciones y los tipos de relaciones en un diagrama de clases. Te recomiendo le des una leída aqui. Explicar un diagrama de clases implica lidiar directamente con conceptos ligados profundamente al paradigma a objetos ( lo cual va más allá del alcance de este post).

Diagramas de objetos

Así como escribí más arriba que un diagrama de clases es el esqueleto de un componente, ya que detalla tipos de comportamientos y datos, un diagrama de objetos sería análogo a un muñeco que haga uso de dicho esqueleto.

Un diagrama de objetos es la representación de un objeto ( la instancia de una clase ) en un instante dado. Es decir, a todos los atributos especificados en el diagrama de clases, se les personaliza, se les asigna valores. De esta forma podemos analizar un objeto ( y su evolución deseada ) en el sistema.

Diagramas de secuencia

Los diagramas de secuencia determinan la evolución de la interacción entre componentes de un sistema a lo largo del tiempo. Los diagramas pretenden mostrar el orden de la secuencia de interacciones entre elementos externos al sistemas y componentes de este.

En resumidas cuentas podría describirlos como: Dado un conjunto de partes discretas de un sistema y elementos ajenos a este, se representa la vida (linea de tiempo) de cada uno de ellos por medio de una linea vertical hacia abajo. Las interacciones entre sistemas (mensajes entre subsistemas) se representan con flechas horizontales direccionadas, en ellas se describe brevemente el mensaje a transmitir. El tiempo t=0 se presenta en la parte superior de la hoja, por lo que, entre más abajo se encuentre una interacción, más al futuro se halla. Los diagramas de secuencia llevan una especie de lógica de escalera.

Los diagramas de secuencia son útiles ya que describe el comportamiento del sistema a lo largo del tiempo, así como muestra la respuesta desencadenada del sistema a un agente externo.

De igual forma, IBM tiene un post muy detallado sobre Diagramas de Secuencia. Sinceramente, creo que por más que mis manos se deshagan en escribir, no podré hacerle justicia a ese post.

Conclusiones

UML ofrece diagramas que, a pesar de estar formalmente establecidos, mantienen un formato intuitivo para su construcción. En mi opinión, si invertimos en aprender adecuadamente a utilizar el paradigma orientado a objetos, obtendremos una ganancia ( y será fácil de utlizar) los diagramas UML.