Según sus creadores, UML (Lenguaje Unificado de Modelado) es un lenguaje gráfico para visualizar, especificar, construir y documentar los componentes de un sistema software. UML permite tanto la especificación conceptual de un sistema como la especificación de elementos concretos, como pueden ser las clases o un diseño de base de datos.

Según su definición, los objetivos de UML son los siguientes:

• Visualizar: UML permite representar mediante su simbología el contenido y la estructura de un sistema software. La notación UML permite definir modelos que serán claramente comprensibles por otros desarrolladores facilitando así el mantenimiento del sistema que describe.
• Especificar: UML permite especificar los procesos de análisis, diseño y codificación de un sistema software. También permite determinar modelos precisos, sin ambigüedades, detallando las partes esenciales de los mismos.
• Construir: Las anteriores características permiten que UML pueda generar código en distintos lenguajes de programación y tablas en una base de datos a partir de modelos UML. Además permite simular el comportamiento de sistemas software.
• Documentar: Como ya se comentó antes, UML permite especificar los procesos de análisis, diseño y codificación y también permite documentar los mismos, dejando clara la arquitectura del sistema.

Tras la aparición de los lenguajes orientados a objetos se buscaron nuevas metodologías que permitiesen el análisis y diseño de aplicaciones bajo dichos lenguajes; estas metodologías fueron los primeros lenguajes de modelado orientados a objetos. Al no poder cubrir éstos todas las necesidades de los desarrolladores, surgió una nueva generación de lenguajes más potentes liderados por el método de Booch, el método OOSE de Jacobson y el método OMT de Rumbaugh; cada uno de estos métodos destacaba en algunos puntos pero fallaba en otros.

UML se comenzó a gestar en la empresa Rational cuando Booch y Rumbaugh decidieron unir sus métodos para conseguir un lenguaje estándar y sólido. Más tarde se incorporó Jacobson, lo que dio lugar a la versión 0.9 de UML en 1996; posteriormente se creó un consorcio con varias organizaciones interesadas en UML. La versión 1.0 de UML surgió en 1997 con la contribución de IBM, HP, Oracle, Microsoft y otras organizaciones.

El desarrollo de UML continúa actualmente bajo el control de IBM (que adquirió Rational); la última versión de UML es la 2.0.

Los tres elementos que forman el modelo conceptual de UML son: los bloques básicos de construcción del lenguaje, las reglas que se aplican sobre esos bloques y los mecanismos comunes de UML.

Existen tres tipos de bloques de construcción:

• Elementos: Son los modelos UML (clases, casos de uso, estados, anotaciones…)
• Relaciones: Ligan elementos entre sí, establecen la forma en que interactúan.
• Diagramas: Representación gráfica de un grupo de elementos y sus relaciones.

A continuación vamos a describir los elementos, relaciones y diagramas que se han utilizado para el análisis y diseño del proyecto.

• Clases: En una clase se agrupan todos los objetos que comparten los mismos atributos, métodos y relaciones. Los atributos son características y propiedades comunes en todos los objetos de la clase. Los métodos son operaciones que deben cumplir las instancias de la clase. Las clases se representan como un rectángulo donde figuran el nombre de la clase, sus atributos y sus métodos.

• Casos de uso: Un caso de uso es una descripción de un conjunto de acciones ejecutadas por el sistema tras la orden de un agente (llamado actor) que puede ser el usuario de la aplicación, la propia aplicación, otro caso de uso o un elemento externo (hardware). Los casos de uso suelen representar funcionalidades del sistema; se representan como una elipse en cuyo interior figura el nombre (lo más descriptivo posible) del caso de uso.

• Interfaz: Es una colección de operaciones (sin su implementación) que especifican un servicio de una determinada clase. Describe el comportamiento visible externamente de ese elemento (completamente o sólo una parte). Se representa con un círculo y, generalmente, se encuentra conectada a la clase que realiza.

• Dependencia: Una dependencia es una relación de uso entre dos elementos (un elemento utiliza a otro). Una relación de dependencia entre dos elementos implica que los cambios que se produzcan en un elemento pueden afectar al otro pero no necesariamente a la inversa. Las dependencias se representan con una línea dirigida discontinua.

• Asociación: Una asociación es una relación estructural entre varios elementos. Una relación de asociación implica que los objetos de los distintos elementos de la relación están conectados entre sí y se pueden comunicar. Una relación de asociación se representa gráficamente con una línea continua entre los elementos relacionados.

• Generalización: Una generalización es una relación de especialización. Los elementos especializados (hijos) son elementos que derivan de un elemento general (padre). Los elementos hijos mantienen la estructura y el funcionamiento del elemento padre pero de una forma más especializada. Su representación gráfica es la de una línea dirigida con punta triangular.

• Diagramas de casos de uso: Un diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso con sus relaciones y los actores implicados. Es un diagrama que sirve para modelar la vista estática de un programa. La vista estática nos permite visualizar el comportamiento externo del programa; de esta forma conseguimos conocer qué es lo que debe hacer el programa independientemente de cómo lo haga y sabremos los elementos que interactúan con el sistema. Los elementos implicados en un diagrama de casos de uso son los casos de uso, las relaciones y los actores. Las relaciones y los casos de uso ya han sido explicados anteriormente y el papel del actor también ha sido comentado pero merece la pena detallarlo más: Un actor es un rol que interactúa con el sistema. Lo definimos como rol porque un actor puede ser tanto un usuario de la aplicación como otro sistema o dispositivos externos.

• Diagramas de secuencia: Un diagrama de secuencia es un diagrama de interacción UML. Estos diagramas muestran la secuencia de mensajes que se van lanzando los objetos implicados en una determinada operación del programa. Dentro del diagrama los objetos se alinean en el eje X respetando su orden de aparición. En el eje Y se van mostrando los mensajes que se envían, también respetando su orden temporal. Cada objeto tiene una línea de vida donde se sitúa su foco de control. El foco de control es un rectángulo que representa el tiempo durante el que un objeto está activo ejecutando una acción. Con este sencillo esquema podemos visualizar la comunicación y sincronización bajo un estricto orden temporal de los objetos implicados en las distintas funcionalidades de un sistema.

• Diagramas de clases: Un diagrama de clases es un diagrama que muestra un conjunto de clases y sus colaboraciones y relaciones. Estos diagramas sirven para visualizar las relaciones existentes entre las distintas clases y la forma en que colaboran unas con otras. Las relaciones entre las distintas clases son las relaciones comunes existentes en UML aunque con matices: Una asociación se traduce como que desde los objetos de una clase se puede acceder a los objetos de otra. Una dependencia se puede visualizar como que la clase utilizada usa parámetro o métodos de la clase que la utiliza. Una generalización se traduce como una herencia entre clases.

• Diagramas de colaboración: Esencialmente es un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboración muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de colaboración no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes.

Los bloques de construcción se deben combinar siguiendo las normas que establece UML. UML establece una serie de normas sobre cómo nombrar a los elementos, relaciones y diagramas; la visibilidad y alcance de dichos nombres y sobre su integridad (cómo diseñar relaciones consistentes). Podremos decir que un modelo está bien formado cuando cumpla estas reglas.

* Nombres: como llamar a los elementos, relaciones y diagramas.

* Alcance: el contexto que da un significado específico a un nombre.

* Visibilidad: como se pueden ver y utilizar esos nombres por otros.

* Integridad: como se relacionan apropiada y consistentemente unos elementos con otros.

* Ejecución: que significa ejecutar o simular un modelo dinámico.

Bajo una serie de mecanismos que se aplican durante todo el proceso de desarrollo de modelos en UML, se consiguen diseños simples y eficientes. Estos mecanismos son los siguientes:

• Especificaciones: UML no es simplemente un lenguaje que proporciona elementos gráficos para modelado, tras cada elemento existe una especificación que nos va a permitir detallar textualmente el comportamiento de los mismos; de esta forma con los elementos gráficos conseguimos una visualización global del sistema y con la especificación conseguimos una visualización detallada del mismo.
• Adornos: Todos los elementos gráficos en UML poseen una notación gráfica que representa los aspectos más importantes de éstos; aún así existe una notación que permite representar los aspectos más específicos a través de adornos, consiguiendo así una especificación aún más detallada.
• Divisiones comunes: UML permite representar las distintas divisiones que presenta el diseño orientado a objetos. Por ejemplo la división clase/objeto donde un objeto es la manifestación concreta de la clase. UML permite el modelado conjunto de los mismos a través de una notación específica.
• Mecanismos de extensibilidad: UML proporciona un lenguaje abierto en el que se pueden expresar los matices de los distintos sistemas, para ello hace uso de tres mecanismos que permiten extender el lenguaje:

- Estereotipo: Permite crear nuevos bloques de construcción partiendo de los ya existentes.

- Valor etiquetado: Permite añadir nuevas propiedades a un bloque de construcción.

- Restricción: Permite añadir o modificar las reglas referidas a los bloques de construcción.

• Original http://www.metricasweb.com

• [BOOC, 1999] BOOCH, G., RUMBAUGH, J., JACOBSON, I. “El lenguaje unificado de modelado”. Ed. Addison Wesley Iberoamericana, Madrid, 1999.

• [LARM, 1999] LARMAN, C. “UML y Patrones, introducción al análisis y diseño orientado a objetos”. Ed. Prentice Hall, México, 1999