Modelado de Software: Comprensión Profunda de los Diagramas de Clases UML

Diagramas de Clases: Fundamentos y Componentes

Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema. Está compuesto por:

• CLASES: atributos, métodos y visibilidad.
• RELACIONES: Herencia, Composición, Agregación, Asociación y Uso.

La Clase: Unidad Fundamental

Una clase es la unidad básica que encapsula toda la información de un objeto (un objeto es un ejemplar de una clase). A través de ella podemos modelar el entorno en estudio (una casa, un coche, una cuenta corriente, etc.). En el lenguaje UML, una clase es representada por un rectángulo que posee tres divisiones:

Atributos y Visibilidad

Los atributos o características de una clase pueden ser de varios tipos, los cuales definen el grado de comunicación y visibilidad con el entorno. Estos son:

• public (+): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde cualquier lugar.
• private (-): Indica que el atributo solo será accesible desde dentro de la clase (solo sus métodos pueden acceder a él).
• protected (#): Indica que el atributo no será accesible desde fuera de la clase, pero sí podrá ser accedido por métodos de la clase, además de las subclases que se deriven (herencia).
• package (~): El atributo empaquetado o de paquete es solo visible en las clases del mismo paquete.

Relaciones entre Clases UML

Herencia (Especialización/Generalización)

Indicado con la flecha con el borde vacío (triángulo hueco apuntando a la superclase).

Indica que una subclase hereda los métodos y atributos especificados por una superclase. Por ende, la subclase, además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la superclase (aquellos marcados como public y protected).

Multiplicidad

La multiplicidad es una propiedad similar a la cardinalidad en los diagramas Entidad-Relación (E/R).

Se sitúa en un extremo de una asociación e indica a cuántas instancias de la clase situada en ese mismo extremo está vinculada una instancia de la clase situada en el extremo opuesto.

• 0..1 → Cero o una vez
• 1 → Una y solo una vez
• * → De cero a varias veces
• 1..* → De una a varias veces
• M..N → Entre M y N veces
• N → N veces

Dependiendo de la herramienta de modelado, las multiplicidades destino mayores que 1 se implementan como un atributo.

Asociación

La asociación permite asociar objetos que, sin compartir atributos ni métodos, colaboran entre sí.

No es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Un cliente puede tener asociadas muchas órdenes de compra; en cambio, una orden de compra solo puede tener asociado un cliente.

Si la asociación es bidireccional, ambas clases conocen su existencia, por lo que se dice que ambas clases son navegables.

Si fuese unidireccional (por ejemplo, de Cliente a OrdenCompra), solo la clase Cliente conocería la existencia de la clase OrdenCompra.

• Cliente a OrdenCompra sería navegable.
• OrdenCompra a Cliente no sería navegable.

Clase Asociación

Una clase asociación se utiliza cuando una asociación entre dos clases lleva información necesaria para esa asociación. Sus instancias son elementos de la asociación, por lo que pueden tener atributos y operaciones, y estar vinculadas a otras clases.

Asociación Reflexiva

Una asociación reflexiva es una asociación que une entre sí instancias de una misma clase.

Por ejemplo, una persona puede ser pariente de otras personas.

Agregación y Composición (Relaciones Parte-Todo)

Estos son casos particulares de asociación que establecen una relación entre un todo y sus partes, asociando un objeto con los objetos que lo constituyen.

Agregación (Relación Débil - Por Referencia)

Es un tipo de relación dinámica donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento). Las partes pueden formar parte de distintos agregados.

Composición (Relación Fuerte - Por Valor)

Es un tipo de relación estática donde el tiempo de vida del objeto incluido está condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el objeto base se construye a partir del objeto incluido, representando una relación parte/todo). Es una agregación estricta. Las partes solo existen si existe el todo y solo se accede a ellas a través del compuesto.

Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias). Cuando se destruye el objeto Almacén, también son destruidos los objetos Cuenta asociados; en cambio, los objetos Cliente asociados no son afectados.

Uso o Dependencia

Es una relación más débil que una asociación. Representa un tipo de relación muy particular en la que una clase es instanciada desde otra (su instanciación es dependiente de otro objeto/clase). El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra.

Por ejemplo: una aplicación gráfica que crea un ejemplar de ventana (la creación del objeto Ventana está condicionada a la creación del ejemplar proveniente desde el objeto Aplicación). Cabe destacar que el objeto creado (en este caso la ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación).

Casos Particulares y Estructura de Paquetes

La relación entre estos paquetes es de Uso/Dependencia.

• El paquete control depende del paquete datos: sus clases acceden a atributos o invocan operaciones de las clases del paquete datos.
• El paquete ventanas depende del paquete control: invoca a operaciones del paquete control.

Ingeniería Inversa

P. Hall la define como un proceso que recorre hacia atrás el ciclo de desarrollo de software:

A partir del código fuente, se busca llegar a la fase de análisis (un ciclo inverso al tradicional modelo en cascada).

Se han considerado dos tipos principales de ingeniería inversa:

• Basada en el código fuente: El código fuente está disponible, pero se desconocen los aspectos de más alto nivel.
• Basada en el programa ejecutable: No existe código fuente disponible; se concentran los esfuerzos en descubrirlo.