UML Parte 1

Como he comentado en posts anteriores, en el proceso del desarrollo de software el diseño es una parte muy importante y completamente necesaria sin importar el tamaño del proyecto que se tenga que hacer, ya que este ayuda con el manejo de la complejidad de proyectos extensos, pero a su vez es necesario para proyectos pequeños. Se ha hablado de la gran cantidad de herramientas que existen que facilitan este proceso, pero la más importante, con mayor alcance y la más predominante en el área es UML (Lenguaje Unificado de Modelado por sus siglas en inglés).

Al haber tantas herramientas que se pueden usar se llega a la discusión entre las personas que quieren usar uno y las otra que quieren usar otro, por lo que la utilización de UML ha hecho que esto sea cosa del pasado, se ha llegado a este acuerdo debido a las siguientes razones:

Se ha adoptado de manera positiva y general el uso de UML ya que este incluye diagramas los cuales modelan la información más importante para el desarrollo de un proyecto, por esto mismo se puede pensar que son diagramas complejos y difíciles de entender, pero por lo contrario, son fáciles de entender y de plasmar la información en ellos, la cual es otra razón por la que son tan usados. Y la ultima razón es el gran alcance que tiene UML, al tener una gran cantidad de diagramas para el modelado de los proyectos.

Este tema se va a dividir en dos partes debido a la gran cantidad de diagramas que ofrece UML y el uso de cada uno, por lo que presentaré 3 diagramas en este post y otros cuantos en el siguiente.

La página Lucidchart es una gran página para la creación de diagramas UML, ya que ofrece la plantilla así como la explicación de cada diagrama, por lo que después de cada tipo incluiré una liga por si se quiere conocer más sobre el diagrama y la herramienta para hacerlos.

• Diagramas Secuenciales

Con estos diagramas se describen las acciones entre los objetos de un sistema, se describe el orden que siguen esta acciones para poder tener una idea clara de lo que se tiene que hacer, así no saltar pasos y tener de una manera ordenada y clara lo que cada objeto produce, recibe, de quien recibe y a quien pasa su producto. Con esto se logra un análisis más eficiente si es que una parte del programa falla o si se quiere hacer un cambio aún después de la implementación de todas las partes del sistema, ya que se puede ver “con lupa” el proceso cuál es el punto donde se debe de hacer el cambio. Página de Lucidchart.

• Diagramas de Clase

Debido a que el diseño de un sistema de software puede llegar a ser muy grande en un principio, he incluso crecer aún más con el tiempo, el diseño de este se debe de dividir para que sea entendido por el personal que está desarrollando el proyecto, ya sea solo por el completo entendimiento o también para poder organizar el proyecto en partes y así poder dividir el trabajo entre varias personas, ya que es poco probable que un proyecto sea hecho por una sola persona. Los diagramas de clase nos ayudan en esta parte al poder modelar las clases necesarias para el proyecto, cuáles son atributos que tiene cada uno, los métodos, así como la comunicación con otras clases, permitiéndonos tener las especificaciones necesarias antes de empezar a programar. Página de Lucidchart.

• Diagrama de Objetos

Estos diagramas pueden llegar a confundirse con los diagramas de clase, pero son diferentes, ya que estos modelan al objeto cuando ya fue creado y ya tiene datos que lo pueden diferenciar de otros, así como la relación que tiene con otros objetos que pueden ser del mismo tipo u otro, mientra que el diagrama de clases solo modela la clase de donde viene al objeto, por lo que este diagrama se puede ver como la instancia de la clase, donde puede haber varios objetos del mismo tipo. Página de Lucidchart.

En esta imagen se muestra la diferencia entre el diagrama de clase la clase BankAccount y el diagrama de objeto del objeto Account1, donde se muestra que el objeto tiene los mismos tipos de datos que la clase, ya que este sale de la clase, pero ya tiene valores para cada atributo. Así dejando en claro que es una instancia de la clase, de la cual podría haber varias.