Visión

Todo gira en torno a un visión. Un sistema complejo toma forma cuando alguien tiene la visión de cómo la tecnología puede mejorar las cosas. Los desarrolladores tienen que entender completamente la idea y mantenerla en mente mientras crean el sistema que les dé forma. [1]

Necesidad del UML

A medida que los problemas a resolver se vuelven más complejos es necesario mejorar los procesos de análisis y evitar entrar al proceso de desarrollo sin saber a ciencia cierta cómo resolver el problema principal.

UML: Historia

Es la creación de Grady Booch, James Rumbaugh e Ivar Jacobson. Cada uno de ellos tenía un modelo propio para el análisis de software, pero finalmente lograron unificarlo. Luego de esto, se crea un consorcio, el Object Management Group (OMG), que se encarga de la conservación del UML, y de la creación de nuevas versiones y certificaciones para el UML. Actualmente la versión es la 2.5, la cual cuenta con 14 diversos diagramas.

Dicha cantidad de diagramas, garantiza la visualización de un problema en varios aspectos diferentes, con lo cual se logra una solución más clara y amplia.

UML: Diagrama de Clases

Una clase, en este diagrama, se representa como un conjunto de rectángulos: el primero se describe el nombre de la clase, en segundo el conjunto de atributos y en el tercero el conjunto de métodos.

En los atributos se tiene el siguiente formato: [nivel de acceso][nombre atributo][:][tipo de dato]. Este mismo formato puede utilizarse con los métodos, sabiendo que si es del tipo void se puede dejar sin tipo de retorno.

Nivel de acceso

• Público: +
• Privado: -
• Protegido: #

Relaciones

Además de establecer la definición de la estructura de las clases, el diagrama de clases define las relaciones que pueden existir entre dichas clases. Entre las relaciones más conocidas tenemos:

Cardinalidad o multiplicidad

La cardinalidad es el número de instancias de una clase que se relacionan con una instancia de otra clase. Cada relación tiene dos multiplicidades, por cada objeto al extremo de la relación.[2]

Cuando la multiplicidad mínima es cero, indica que la relación es opcional. Cuando es uno, la multiplicidad mínima es mayor o igual a uno indica que la relación es obligatoria.

Dirección

En las relaciones de asociación se puede establecer que los objetos que están al extremo de una relación puede «conocerse» entre sí (relación bidireccional), o que solamente uno de ellos «conoce» a otro (relación unidireccional).

Qué un objeto conozca a otro, indica que dentro de los atributos del objeto o en el uso de sus métodos, está contenido el otro objeto. En relaciones bidireccionales ambos objetos están contenidos entre sí.

En el primer ejemplo, podemos notar que un objeto Cuenta conoce al objeto Dinero, sin embargo el objeto Dinero desconoce a que objeto Cuenta está asignado. En el segundo caso, tanto Cuenta como Cliente, se conocen mutuamente.

Definir el tipo de relación en un diagrama de clases

Referencias

[1] https://es.scribd.com/doc/179376861/uml-pdf

[2] http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf