Introducción a UML

Forma parte de la vista est�tica del sistema. En el diagrama de clases como ya hemos comentado ser� donde definiremos las caracter�sticas de cada una de las clases, interfaces, colaboraciones y relaciones de dependencia y generalizaci�n. Es decir, es donde daremos rienda suelta a nuestros conocimientos de dise�o orientado a objetos, definiendo las clases e implementando las ya t�picas relaciones de herencia y agregaci�n.

En el diagrama de clases debemos definir a estas y a sus relaciones.

.�La Clase

Una clase esta representada por un rect�ngulo que dispone de tres apartados, el primero para indicar el nombre, el segundo para los atributos y el tercero para los m�todos.

Cada clase debe tener un nombre �nico, que las diferencie de las otras.

Un atributo representa alguna propiedad de la clase que se encuentra en todas las instancias de la clase. Los atributos pueden representarse solo mostrando su nombre, mostrando su nombre y su tipo, e incluso su valor por defecto.

Un m�todo o operaci�n es la implementaci�n de un servicio de la clase, que muestra un comportamiento com�n a todos los objetos. En resumen es una funci�n que le indica a las instancias de la clase que hagan algo.

Para separar las grandes listas de atributos y de m�todos se pueden utilizar estereotipos.

Una clase

Aqu� vemos un ejemplo. La clase usuario contiene tres atributos. Nombre que es public, direcci�n que es protected y situaci�n que es private. Situaci�n empieza con el valor 3. Tambi�n dispone de tres m�todos Entrar, Salir y Trabajar.

.�Relaciones entre clases

Existen tres relaciones diferentes entre clases, Dependencias, Generalizaci�n y Asociaci�n. En las relaciones se habla de una clase destino y de una clase origen. La origen es desde la que se realiza la acci�n de relacionar. Es decir desde la que parte la flecha, la destino es la que recibe la flecha. Las relaciones se pueden modificar con estereotipos o con restricciones.

.�Dependencias

Es una relaci�n de uso, es decir una clase usa a otra, que la necesita para su cometido. Se representa con una flecha discontinua va desde la clase utilizadora a la clase utilizada. Con la dependencia mostramos que un cambio en la clase utilizada puede afectar al funcionamiento de la clase utilizadora, pero no al contrario. Aunque las dependencias se pueden crear tal cual, es decir sin ning�n estereotipo (palabreja que aparece al lado de la l�nea que representa la dependencia) UML permite dar mas significado a las dependencias, es decir concretar mas, mediante el uso de estereotipos.

  • Estereotipos de relaci�n Clase-objeto.
    • Bind: La clase utilizada es una plantilla, y necesita de par�metros para ser utilizada, con Bind se indica que la clase se instancia con los par�metros pas�ndole datos reales para sus par�metros.
    • Derive: Se utiliza al indicar relaciones entre dos atributos, indica que el valor de un atributo depende directamente del valor de otro. Es decir el atributo edad depende directamente del atributo Fecha nacimiento.
    • Friend: Especifica una visibilidad especial sobre la clase relacionada. Es decir podr� ver las interioridades de la clase destino.
    • InstanceOF: Indica que el objeto origen es una instancia del destino.
    • Instantiate: indica que el origen crea instancias del destino.
    • Powertype: indica que el destino es un contenedor de objetos del origen, o de sus hijos.
    • Refine: se utiliza para indicar que una clase es la misma que otra, pero mas refinada, es decir dos vistas de la misma clase, la destino con mayor detalle.

.�Generalizaci�n

Pues es la herencia, donde tenemos una o varias clases padre o superclase o madre, y una clase hija o subclase. UML soporta tanto herencia simple como herencia m�ltiple. Aunque la representaci�n com�n es suficiente en el 99.73% de los casos UML nos permite modificar la relaci�n de Generalizaci�n con un estereotipo y dos restricciones.

  • Estereotipo de generalizaci�n.
    • Implementation: El hijo hereda la implementaci�n del padre, sin publicar ni soportar sus interfaces.
  • Restricciones de generalizaci�n.
    • Complete: La generalizaci�n ya no permite mas hijos.
    • Incomplete: Podemos incorporar mas hijos a la generalizaci�n.
    • Disjoint: solo puede tener un tipo en tiempo de ejecuci�n, una instancia del padre solo podr� ser de un tipo de hijo.
    • Overlapping: puede cambiar de tipo durante su vida, una instancia del padre puede ir cambiando de tipo entre los de sus hijos.

.�Asociaci�n

Especifica que los objetos de una clase est�n relacionados con los elementos de otra clase. Se representa mediante una l�nea continua, que une las dos clases. Podemos indicar el nombre, multiplicidad en los extremos, su rol, y agregaci�n.

Diagrama de ejemplo

En este diagrama se han creado cuatro clases. La clase principal es Usuario, que tiene dos clases hijas UsuarioADM y UsuarioINF. El usuario mantiene una relaci�n de asociaci�n con la clase Clave, se indica que es propietario de una clave, o de un n�mero indeterminado de ellas. Se le crea tambi�n una relaci�n de dependencia con la clase Perfil, es decir las instancias de usuario contendr�n como miembro una instancia de Perfil.

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP
ARTÍCULO ANTERIOR