I. E. S.

MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

INTRODUCCIN
AL MODELADO
CON UML

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 1 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

Contenido
1. Introduccin ........................................................................................................................... 3
2. Diseo orientado a objetos .............................................................................................. 4
3. Elementos de la POO .......................................................................................................... 5
3.1. Clases y objetos............................................................................................................. 5
3.2. Mensajes y mtodos ................................................................................................... 6
3.3. Atributos y estado ........................................................................................................ 6
3.4. Herencia y polimorfismo............................................................................................ 7
4. Lenguaje unificado de modelado (UML) ..................................................................... 9
5. Diagramas de clases.......................................................................................................... 12
5.1. Clases .............................................................................................................................. 12
5.2. Interfaces ....................................................................................................................... 14
5.3. Relaciones entre clases ............................................................................................. 15
5.3.1. Asociacin ............................................................................................................. 15
5.3.2. Agregacin ........................................................................................................... 16
5.3.3. Composicin ........................................................................................................ 17
5.3.4. Generalizacin ..................................................................................................... 17
5.3.5. Clases de asociacin ......................................................................................... 18
6. Ejemplos ................................................................................................................................ 19
6.1. Ejemplo 1 ....................................................................................................................... 19
6.2. Ejemplo 2 ....................................................................................................................... 20
7. Anexo: Implementacin en C# ...................................................................................... 21
7.1. Herencia ......................................................................................................................... 21
7.2. Sobreescritura .............................................................................................................. 23
7.3. Clases y mtodos abstractos .................................................................................. 24

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 2 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

1 Introduccin

En la unidad 1 (punto 1.7) hemos visto las diferentes etapas que hemos de
seguir a la hora de realizar cualquier desarrollo software. La primera etapa (y la
ms importante) es la etapa de anlisis, en la cual hemos de traducir los
requisitos recogidos del cliente (generalmente recogidos mediante entrevistas,
en lenguaje natural) a algn tipo de especificacin que sea no ambigua (es
decir, no usando el lenguaje natural). Esto por lo general se consigue
expresando dichos requisitos mediante un modelo.

Anlisis

Llamaremos modelo a una simplificacin de la realidad. El modelo nos

proporciona los planos de un sistema, desde los ms generales, que
proporcionan una visin general del sistema, hasta los ms detallados. En un
modelo se han de incluir los elementos que tengan ms relevancia y omitir los
que no son interesantes para el nivel de abstraccin que se ha elegido. A travs
del modelado conseguimos cuatro objetivos:

Los modelos nos ayudan a visualizar cmo es o queremos que sea un

sistema.
Los modelos nos permiten especificar la estructura o el comportamiento
de un sistema.
Los modelos nos proporcionan plantillas que nos guan en la
construccin de un sistema
Los modelos documentan las decisiones que hemos adoptado

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 3 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

Para elegir el modelo adecuado, primero tendremos que tener claro qu

paradigma de programacin vamos a utilizar (ver unidad 1, punto 1.3.6). De
entre los diferentes paradigmas de programacin, el ms difundido actualmente
es el Paradigma de Programacin Orientado a Objetos (POO). De hecho, el
lenguaje con el que nosotros realizaremos las prcticas tanto en la asignatura
de programacin como en esta asignatura es un lenguaje orientado a objetos
(C#). Pero en qu consiste la programacin orientada a objetos?

2 Diseo orientado a objetos

El Paradigma de Programacin Orientado a Objetos (POO) es una tcnica de

programacin que usa objetos y sus interacciones para disear aplicaciones y
programas de ordenador. Este paradigma proporciona una forma particular de
programar, ms cercana a la manera en que expresamos las cosas en la vida
real.

En la programacin orientada a objetos tenemos que disear nuestros

programas en trminos de objetos, propiedades y mtodos. Estos conforman
los elementos principales de este paradigma. La programacin orientada a
objetos expresa un programa como un conjunto de estos objetos, que
colaboran entre ellos para realizar tareas. Esto permite hacer los programas y
mdulos ms fciles de escribir, mantener y reutilizar.

En la programacin convencional los programas se dividen en dos

componentes: Procedimientos y Datos. Las estructuras de datos utilizadas en
programacin son globales o se pasan como parmetros. En esencia los datos

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 4 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

se tratan separadamente de los procedimientos. En la programacin orientada a

objetos se combinan los datos y los procedimientos en una entidad nica.

Podemos decir tambin, que este paradigma es una disciplina de diseo de

software que facilita la construccin de sistemas a travs de componentes
individuales llamados clases de objetos.

3 Elementos de la POO
3.1. Clases y objetos

La POO concibe el universo del problema como un conjunto de objetos que

interactan entre s. Para poder entender qu es un objeto, primero hemos de
explicar qu es una clase y un objeto.

Una clase es un tipo de datos que agrupa unas determinadas estructuras de

datos y la funcionalidad relativa a esos datos. Pensemos por ejemplo en una
lavadora: puede tener una serie de propiedades como la marca, el modelo, la
capacidad. Todos estos datos constituiran la estructura de datos de la clase. A
su vez, podemos tener una funcionalidad asociada a esta clase: encender,
apagar, centrifugar,

Un objeto constituira una instancia concreta de una clase. En nuestro ejemplo,

de la clase lavadora, podramos tener diferentes instancias: {Balay,BL-
001,5kg}, {Bosch, CH-401, 7kg}, Cada una de estas diferentes
instancias seran los objetos que interactuaran en el universo del problema.

Podemos ver las clases como el molde genrico a partir del cual se crean las
instancias concretas que constituyen los objetos. Las clases son las definiciones
de las propiedades y comportamiento de un conjunto de objetos concretos. La
instanciacin es la lectura de estas definiciones y la creacin de un objeto a
partir de ellas. Cada vez que se construye un objeto de una clase, se crea una
instancia de esa clase.

Lavadora INSTANCIACIN MiLavadora:

Lavadora
Marca Marca: Bosch
Modelo Modelo: CH-401
Capacidad Capacidad: 7KG
Encender() Encender()
Apagar() Apagar()
Centrifugar() Centrifugar()

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 5 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

3.2. Mensajes y mtodos

Un mensaje es la invocacin de una operacin sobre un

objeto. En el ejemplo anterior, el objeto MiLavadora podra recibir el mensaje de
puesta en marcha: MiLavadora.Encender().

Un objeto es el agente activo que lanza el mensaje y otro

objeto es el agente pasivo que recibe el mensaje. El objeto que recibe el
mensaje debe contemplar dicha operacin entre las definidas por la clase a la
que pertenece. Puede verse como la solicitud de un servicio a un objeto.

Un mtodo es la definicin de una operacin de una clase. Consiste en la

descripcin formal del comportamiento asociado a una clase. Puede entenderse
como un servicio que ofrece la clase. La invocacin de un mtodo de un objeto
produce un mensaje.

Podemos encontrar diferentes tipos de mtodos:

Mtodos que producen un cambio en el estado del objeto sobre el que

se ejecuta el mtodo procedimientos y asignacin
Mtodos que sin producir ningn cambio en el estado del
objeto calculan cierto valor funciones y operadores
Mtodos especficos para la inicializacin y finalizacin de la
vida de un objeto constructores y destructores

Toda clase debe tener de manera obligatoria un constructor y un destructor. Si

el usuario no lo define explcitamente, se genera uno por defecto.

3.3. Atributos y estado

Llamamos atributo a cada uno de los datos de una clase. Representan las
diferentes caractersticas que tiene nuestra clase. En el ejemplo de la lavadora,
los atributos seran la marca, el modelo y la capacidad.

Los atributos pueden hacer referencia a informacin que no cambia durante la

vida del objeto (por ejemplo, la marca de la lavadora) o por el contrario pueden
contener informacin cambiante. Recurriendo a nuestro ejemplo, podramos
tener en la lavadora un atributo status que indicara que operacin se encuentra
haciendo en estos momentos la lavadora: parada, llenando tanque, lavando,

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 6 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

aclarando, centrifugando. Este tipo de atributos estara describiendo el estado

del objeto.

3.4. Herencia y polimorfismo

Una de las propiedades fundamentales cuando definimos un atributo consiste

en la visibilidad del mismo, es decir, quin va a poder hacer uso de ese atributo.
Existen tres tipos de visibilidad:

Pblica: cualquier objeto puede acceder al atributo.

Privada: slo la propia clase que lo define puede acceder al atributo.
Protegido: el atributo es accesible para la clase que lo define y sus
derivadas.

Para entender este ltimo tipo de visibilidad, debemos explicar el mecanismo de

herencia. La herencia es el mecanismo mediante el cual podemos definir una
clase a partir de la definicin de otra clase. Continuando con el ejemplo anterior,
podramos haber empezado definiendo una clase electrodomstico, cuyos
atributos podran ser la marca, el modelo, la clasificacin energtica (A++, A+,
etc) y el nmero de serie. A partir de esta clase y aplicando el mecanismo de
herencia, podramos definir la clase lavadora y otras clases, como el frigorfico.

Electrodomstico
Marca
Modelo
Clase energtica
Num. Serie
Encender()
Apagar()

Lavadora Frigorfico
Capacidad (kilos) Capacidad (litros)
Centrifugar() Descongelar()

INSTANCIACIN

MiLavadora: Lavadora
Marca: Bosch
Modelo: CH-401
Clase Energtica: A++
Num.Serie: LBCH4212
Capacidad: 7 KG
Encender()
Apagar()
Centrifugar()

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 7 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

En este ejemplo, si asumimos que los atributos de la clase electrodomstico

tienen visibilidad pblica o protegida, la clase lavadora constara de los
siguientes atributos: marca, modelo, clase energtica, num. Serie y capacidad
(kilos). Es decir, hereda la informacin de su clase base. Si, por el contrario, el
atributo num. serie fuera privado, esto implicara que la clase lavadora no
dispondra del mismo (ni tampoco la clase frigorfico).

Siguiendo con el ejemplo, llamaremos a Electrodomstico clase base, padre o

superclase, y a Lavadora y Frigorfico clases derivadas, hijas o subclases. Al
proceso de crear una clase derivada a partir de una clase base lo
denominaremos especializacin. El proceso contrario (deducir una clase base a
partir de una o ms derivadas) lo denominaremos generalizacin.

El otro mecanismo fundamental de la programacin orientada a objetos

asociado con la herencia es el polimorfismo. El polimorfismo es el mecanismo
por el cual una misma operacin es resuelta de manera diferente en funcin del
objeto que reciba el mensaje. Este mecanismo est estrechamente relacionado
con el mecanismo de herencia: no se puede aplicar de forma efectiva el
polimorfismo sino es con un conjunto de clases que constituyan un rbol de
herencia.

Para explicar ste mecanismo vamos a partir de un ejemplo diferente:

supongamos que tenemos una clase polgono con mtodos rea() y permetro().
A partir de esta clase polgono (que es virtual, y que no tiene una definicin real
de los mtodos) creamos otras dos clases, una clase tringulo y otra cuadrado.
Cada una de ellas implementa los mtodos rea() y permetro() de manera
diferente:

tringulo.area() { return (base*altura/2); }

cuadrado.area() { return base*altura; }

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 8 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

Polgono

Area()
Permetro()

Tringulo Rectngulo

Area() Area()
Permetro() Permetro()

Si declaramos un objeto de la clase polgono, est podr contener tanto

tringulos como rectngulos. El siguiente orden de ejecucin proporcionara el
resultado que se muestra:

Tringulo t = new Tringulo;

Rectngulo r = new Rectngulo;
Polgono p;

p = r; // Asignacin correcta, una superclase siempre puede contener

// a una subclase

p.area(); devolvera base*altura, ya que ahora el polgono es un

rectngulo

p = t; // Ahora el polgono es un tringulo

p.area(); ahora devolvera (base*altura)/2

Como hemos visto en este ejemplo, en la POO es posible definir una superclase
(polgono) que defina un comportamiento (rea(), permetro()) pero que no lo
implemente, delegando esta responsabilidad en las subclases. A este tipo de
superclases se les denomina clases abstractas. No se pueden crear instancias
(objetos) de una clase abstracta, pero s se les puede asignar una instancia
concreta de una clase derivada.

4 Lenguaje unificado de modelado (UML)

El Lenguaje Unificado de Modelado (UML) es un lenguaje grfico para visualizar,

especificar, construir y documentar un sistema. UML ofrece un estndar para
describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales
tales como procesos de negocio, funciones del sistema, y aspectos concretos
como expresiones de lenguajes de programacin, esquemas de bases de datos
y componentes reutilizables.

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 9 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

Es importante resaltar que UML es un "lenguaje de modelado" para especificar

o para describir mtodos o procesos. Se utiliza para definir un sistema, para
detallar los artefactos en el sistema y para documentar y construir. En otras
palabras, es el lenguaje en el que est descrito el modelo.

Puede ser utilizado con cualquier metodologa de desarrollo (MERISE, METRICA,

...) a lo largo del proceso de desarrollo de software, y con cualquier plataforma
tecnolgica de implementacin (Unix, Windows etc.). Es un sistema notacional
(que, entre otras cosas, incluye el significado de sus notaciones) destinado a los
sistemas de modelado que utilizan conceptos orientados a objetos. Es
importante resaltar que un modelo UML describe lo que supuestamente har un
sistema, pero no dice cmo implementar dicho sistema.

El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y

diagramas estndar para modelar sistemas orientados a objetos, y describe la
semntica esencial de lo que estos diagramas y smbolos significan. Mientras
que ha habido muchas notaciones y mtodos usados para el diseo orientado a
objetos, ahora los modeladores slo tienen que aprender una nica notacin.

Los diferentes tipos de diagramas que se pueden realizar en UML son:

Diagrama de Casos de Uso: modela la funcionalidad del sistema

agrupndola en descripciones de acciones ejecutadas por un sistema
para obtener un resultado. Se utiliza para entender el uso del sistema
Muestra el conjunto de casos de uso y actores (Un actor puede ser tanto
un sistema como una persona) y sus relaciones: es decir, muestra quien
puede hacer qu y las relaciones que existen entre acciones (casos de
uso). Son muy importantes para modelar y organizar el comportamiento
del sistema.

Diagrama de Clases: muestra las clases (descripciones de objetos que

comparten caractersticas comunes) que componen el sistema y cmo se
relacionan entre s.

Diagrama de Objetos: muestra una serie de objetos (instancias de las

clases) y sus relaciones. Adiferencia de los diagramas anteriores, estos
diagramas se enfocan en la perspectiva de casos reales o prototipos. Es
un diagrama de instancias de las clases mostradas en el diagrama de
clases.

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 10 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

Diagrama de Secuencia: enfatiza la interaccin entre los objetos y los

mensajes que intercambian entre s junto con el orden temporal de los
mismos.

Diagrama de Colaboracin: igualmente, muestra la interaccin entre los

objetos resaltando la organizacin estructural de los objetos en lugar del
orden de los mensajes intercambiados. El diagrama de secuencia y el
diagrama de colaboracin muestran a los diferentes objetos y las
relaciones que pueden tener entre ellos, los mensajes que se envan
entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a
otro sin prdida de informacin, pero que nos dan puntos de vista
diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama
de Interaccin.

Diagrama de Estados: Se utiliza para analizar los cambios de estado de

los objetos. Muestra los estados, eventos, transiciones y actividades de
los diferentes objetos. Son tiles en sistemas que reaccionen a eventos.

Diagrama de Actividades: Es un caso especial del diagrama de estados,

simplifica el diagrama de estados modelando el comportamiento
mediante flujos de actividades. Muestra el flujo entre los objetos. Se
utilizan para modelar el funcionamiento del sistema y el flujo de control
entre objetos.

Diagrama de Componentes: muestra la organizacin y las dependencias

entre un conjunto de componentes. Se usan para agrupar clases en
componentes o mdulos.

Diagrama de Despliegue (o implementacin): muestra los dispositivos que

se encuentran en un sistema y su distribucin en el mismo. Se utiliza para
identificar Sistemas de Cooperacin: Durante el proceso de desarrollo el
equipo averiguar de qu sistemas depender el nuevo sistema y que
otros sistemas dependern de l.

Como se puede ver, el conjunto de diagramas que se pueden realizar en UML es

muy amplio. A lo largo de este curso, nos limitaremos a ver los diagramas de
clases, de casos de uso, de secuencia y de colaboracin.

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 11 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

5 Diagramas de clases
Los diagramas de clases se utilizan para modelar la visin esttica de un
sistema. Esta visin soporta los requisitos funcionales del sistema, es decir, los
servicios que el sistema debera proporcionar a sus usuarios finales.
Normalmente contienen: clases, interfaces y relaciones entre ellas: de
asociacin, de dependencia y/o de generalizacin.

5.1. Clases

Tal y como se ha visto en el punto dedicado a la POO, una clase es un tipo de

datos que agrupa unas determinadas estructuras de datos (atributos) y la
funcionalidad relativa a esos datos (mtodos). La forma de representar una clase
es mediante un rectngulo con tres filas o compartimentos:

Nombre de la clase Electrodomstico

Marca
Atributos Modelo
Num. Serie
Mtodos Encender()
Apagar()

A la hora de representar los atributos, hemos de indicar no slo el nombre del

mismo, sino tambin su visibilidad (ver punto 3.4), su tipo de datos y su
multiplicidad. La sintaxis concreta para representar un atributo en UML es la
siguiente:

[visibilidad][/]nombre[:tipo][multiplicidad][=valor]

Donde:

visibilidad puede ser:

+ (pblica)
- (privada)
# (protegida)

nombre es una cadena de texto que representa el nombre del atributo

tipo es un tipo de atributo tpico: string (cadena de texto), boolean

(booleano), integer (entero), float (real), double, point, area y
enumeration. Se llaman tipos primitivos. Tambin pueden ser especficos

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 12 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

de un cierto lenguaje de programacin, aunque se puede usar cualquier

tipo, incluso otras clases.

multiplicidad es un indicador de la multiplicidad del atributo, que va

encerrado entre corchetes. La ausencia de multiplicidad significa que
tiene exactamente valor 1, mientras que una multiplicidad de 0..1
proporciona la posibilidad de valores nulos (la ausencia de un valor, o lo
que es lo mismo, el atributo es opcional). Por defecto, la visibilidad es
pblica y la multiplicidad es [1..1]

valor-inicial es una expresin con el valor inicial que va a contener el

atributo cuando se crea de nuevo el objeto

Ejemplos:

+ tamao: rea = (100,100)

+ color-actual: Color = blanco {blanco, rojo}
+ localidad: String[0..1]
# visibilidad: Boolean = false
+ tamao-mximo: Rectngulo

El atributo tamao-mximo tienen por tipo la clase Rectngulo, mientras que el

resto corresponde a tipos primitivos: rea, Color y Boolean. Asimismo, el
atributo que aparece subrayado, es un atributo cuyo mbito es la clase, es decir,
son atributos estticos.

La sintxis para representar los mtodos es similar:

[visibilidad] nombreOperacin [(listaParmetros)][:tipoRetorno]

La visibilidad se maneja de igual manera que en los atributos. El tipo de retorno

es la clase de valor que devuelve el mtodo. La lista de parmetros son el
argumento o argumentos que necesita el mtodo como valores de entrada para
realizar su funcin.

A continuacin podemos ver un ejemplo de clase definida en notacin UML:

Polgono
#vertices: point[]
+void AddVertex( point )
+float Area()
+float Permetro()

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 13 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

En esta clase podemos ver que los vrtices son un conjunto (se expresa
mediante los corchetes) que no es accesible (protegido). Para aadir un vrtice
se usa el mtodo AddVertex, el cual no tiene valor de retorno (void).

5.2. Interfaces

Una interfaz es una coleccin de operaciones que sirven para especificar los
servicios de una clase. Una interfaz slo contiene las cabeceras de las
operaciones, no su implementacin, y suelen estar asociadas a clases abstractas.
En otras palabras, una interfaz solo contiene un conjunto de mtodos que
deben implementar todas las clases que derivan de ella. Las interfaces no
contienen implementacin de los mtodos, tan solo la declaracin de los
mismos.

Grficamente una interfaz se puede representar de forma expandida como una

clase estereotipada con la etiqueta <<interface>> o, en su forma abreviada, con
una figura en forma de piruleta. En los diagramas de clases se suele utilizar la
forma expandida para representar las interfaces. La forma abreviada
generalmente se usa en los diagramas de componentes.

Hay dos relaciones que pueden existir entre una clase y una interfaz: la
dependencia y la realizacin. La dependencia entre una clase y una interfaz
tiene el mismo significado y representacin que entre dos clases, indica que la
clase usa la interfaz. Para que una interfaz se pueda usar hace falta que otra
clase implemente las operaciones que la interfaz especifica. A esta relacin entre
la interfaz y la clase que la implementa se le llama realizacin. La realizacin
indica que la clase implementa todas las operaciones de la interfaz.
Grficamente la realizacin se representa como una generalizacin con la lnea
discontinua.

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 14 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

5.3. Relaciones entre clases

5.3.1. Asociacin

Una asociacin es una relacin estructural que especifica que los objetos de una
clase estn conectados con los objetos de otra. Una asociacin es una conexin
semntica entre los objetos de dos clases, se llama asociacin binaria. Aunque
no es lo comn, se pueden tener asociaciones que conecten ms de dos clases;
stas se llaman asociaciones n-arias. Tambin es posible que, dado un objeto de
una clase, se pueda enlazar con otros objetos de la misma clase. A este tipo de
relaciones se les denomina reflexivas.

Puesto de trabajo 1 * Empleado 0..1

desempea

*
supervisa

En el ejemplo vemos dos asociaciones, una binaria entre empleado y puesto de

trabajo (un empleado desempea un puesto, y un puesto lo pueden ocupar
muchos empleados) y otra reflexiva (un empleado supervisa a 0 o ms
empleados).

Normalmente una asociacin es binaria y bidireccional (se puede navegar en

ambas direcciones). Se dibuja como una lnea slida entre dos clases. Tambin
se puede representar una asociacin binaria y unidireccional, aadiendo una
flecha al final de la lnea. Esta flecha indica la navegabilidad de la asociacin: la
clase con la punta de flecha es accedida por la otra clase. A la hora de pasarlo a
cdigo, esto se traduce en que la clase con el origen de la asociacin contiene
un atributo del tipo de la otra clase.

class Empleado {

public PuestoDeTrabajo puestoOcupado;

}

Resumiendo, los atributos de una asociacin son:

Nombre (Rol): Una asociacin puede tener un nombre, que se usa para
describir la naturaleza de la relacin. As no hay ambigedad sobre su

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 15 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

significado. Para indicar la direccin en que se debe leer el nombre se

emplea un tringulo.

Multiplicidad: La multiplicidad describe la cardinalidad de la relacin, es

decir, cuntos objetos estn conectados en una instancia de una
asociacin (enlace). Cuando se establece una multiplicidad al final de la
lnea de una asociacin, indica que para cada objeto de la clase en el
lado opuesto existen varios objetos en el otro extremo. El rango puede
ser tres (3), cero-a-uno (0..1), cero-a-muchos (0..* *), uno-a-muchos
(1..*), etc.

Navegabilidad: la navegabilidad indica la posibilidad de ir desde el objeto

fuente al objeto destino. En un extremo de una asociacin se puede
indicar la navegabilidad mediante una flecha. Significa que es posible
navegar desde el objeto de la clase origen hasta el objeto de la clase
destino y por tanto puede llamar a alguna de sus operaciones.

5.3.2. Agregacin

Una agregacin sirve para modelar una relacin todo-parte, lo que significa
que un objeto del todo tiene objetos de la parte. Se denota dibujando una lnea
con un rombo sin rellenar al final de la misma del lado del todo (del lado de la
clase que contiene a la otra clase). Tambin puede tener un nombre (con
direccin) y ser navegable, as como aadir roles en el lado de la parte (lado de
la clase contenida).

Se trata de una relacin de pertenencia no muy fuerte.

Ejemplo:

Barco * Flota

contiene

La flota contiene muchos barcos de guerra. Algunos barcos pueden ser

eliminados y todava es una flota. Lo mismo ocurre si se aaden barcos, pues
sigue siendo una flota. Un barco puede existir aunque no exista flota. Las partes
(los barcos de guerra) componen el todo (flota). El rombo sin rellenar en el lado
del todo, junto con la multiplicidad 1, nos indica que se trata de una agregacin
normal.

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 16 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

5.3.3. Composicin

La composicin es una forma fuerte de agregacin. En la composicin tanto el

todo como las partes tienen el mismo ciclo de vida. Esto quiere decir que las
clases en el extremo de la composicin no pueden existir sin la clase situada en
el rombo. Veamos un ejemplo:

Reserva * 1 Cliente

realiza

Imaginemos un sistema de reservas de un hotel, en la que los clientes pueden

realizar reservas de habitaciones. Si damos de baja a un cliente (termina su ciclo
de vida), automticamente hemos de dar de baja todas sus reservas, ya que no
podemos tener una reserva a nombre de nadie.

Aunque no es estrictamente obligatorio, por lo general, en la composicin la

clase que determina el ciclo de vida (en este caso, cliente) suele tener
cardinalidad uno (es decir, una reserva ha de estar obligatoriamente asignada a
un cliente).

5.3.4. Generalizacin

La generalizacin es la asociacin que permite representar una relacin de

herencia en un diagrama de clases UML. Para representar dicha asociacin se
dibuja un tringulo en la superclase.

Polgono

Tringulo Rectngulo

Una generalizacin puede tener dos posibles tipos de restricciones:

Complete / Incomplete: una generalizacin es completa si todas las

instancias de la superclase estn en una subclase, incompleta en caso
contrario.

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 17 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

Overlapping / disjoint: una generalizacin es disjunta (disjoint) si cada

instancia de la superclase est en como mucho una subclase. En caso
contrario se considera overlapping (superpuesta).

En el ejemplo de la pgina anterior, la generalizacin sera disjunta (un tringulo

no puede ser tambin un cuadrado) e incompleta (hay ms tipos de polgonos
adems de los tringulos y los cuadrados).

5.3.5. Clases de asociacin

Cuando se modela una asociacin entre clases, a veces es necesario incluir otra
clase que contiene informacin valiosa acerca de la relacin. Ello es debido a
que la informacin a incluir no se puede incluir en ninguna de las dos clases
asociadas. Se representa como una clase normal solo que la lnea que la une
con la lnea que conecta las asociaciones primarias es punteada.

Supongamos que queremos modelar un sistema de prstamos bibliotecarios,

en el que necesitamos conocer en qu fecha se realiza cada prstamo. Una
posible solucin sera la siguiente:

Prstamo
#fecha: date;

Socio * * Libro

En este caso, la informacin correspondiente a la fecha de alquiler no puede ir

en el socio (ya que un socio puede tener ms de un alquiler) ni en el libro (ya
que un libro se puede alquilar muchas veces). Por tanto, tendr que ir en una
clase aparte.

Este tipo de asociaciones suelen ir vinculadas a relaciones muchos a muchos

(*,*).

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 18 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

6 Ejemplos
A la hora de realizar un diagrama de clases, debemos tener en cuenta los
siguientes pasos:

1. Detectar las clases. Para ello, veremos que informacin es necesario

almacenar. Por ejemplo, si el enunciado nos dice de los clientes es
necesario conocer el nombre y los apellidos, se har necesario crear una
clase cliente que incorporar dos atributos. Obviamente, si en nuestro
diseo aparece una clase sin mtodos ni atributos, hemos cometido un
error.

2. Establecer relaciones entre las clases. Para ello deberemos detectar las
partes del enunciado en que se relacionan nuestras clases. Por ejemplo, si
el enunciado nos dice los clientes realizan pedidos deber existir una
relacin entre la clase cliente y la clase pedido.

3. Detectar posibles generalizaciones. Si tenemos en nuestra solucin dos o

ms clases que comparten una serie de mtodos y/o atributos,
posiblemente sea necesario crear una clase base (generalizacin) o un
interfaz.

6.1. Ejemplo 1

Realizar un diagrama de clase que responda a las siguientes

especificaciones:

Las reas metropolitanas tienen una serie de hoteles, algunos de

los cuales pertenecen a una determinada cadena de hoteles. Los hoteles
aceptan diferentes tipos de tarjetas de crdito.

De las reas metropolitanas interesa conocer el nombre del rea, el nombre del
estado o provincia a la que pertenece y el nombre del pas. De los hoteles
interesa conocer el nombre, la direccin, el n de habitaciones, el n de telfono,
el n de estrellas, el precio de la habitacin simple y el precio de la habitacin
doble. De las cadenas de hoteles interesa conocer el nombre y el director. De las
tarjetas de crdito slo interesa conocer el nombre.

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 19 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

La aplicacin necesita mostrar el nombre de las reas metropolitanas, el nombre

de los hoteles, el nombre del director de las cadenas de hotel y el nombre de
las tarjetas de crdito.

6.2. Ejemplo 2

Una compaa de Seguros vende plizas. De cada empleado conocemos su DNI

y nombre. En particular, para cada vendedor conocemos su n de vendedor,
zona en la que opera; y de cada jefe conocemos su salario. Respecto a las
plizas conocemos su n de pliza, importe y el beneficiario. Adems se ha de
guardar la fecha en la que se vendi la pliza. Realizar un diagrama de clases
para dichas condiciones. La aplicacin necesita mostrar el nombre de los
empleados,el salario de los jefes, el nmero de los vendedores, y el
nombre de los beneficiarios.

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 20 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

7 Anexo: Implementacin en C#

Este anexo se incluye a ttulo informativo, ya que los contenidos que

corresponden al mismo se vern en el mdulo de programacin ms adelante.
As, el nico objetivo de este anexo es que el alumno visualice la
correspondencia entre los contenidos tericos de la unidad y su aplicacin
prctica en programacin.

7.1. Herencia

En C# la herencia se implementa escribiendo el nombre de la clase base a

continuacin de la declaracin de la subclase, separadas por :

public class Perro : Animal //Perro hereda de Animal.

Supongamos que tenemos el diseo de clases UML de la figura:

La codificacin de la clase Forma podra quedar de la siguiente manera:

public class Forma

{
private int posicionX;
private int posicionY;

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 21 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

public int PosicionX

{
get { return posicionX; }
set { posicionX = value; }
}

public int PosicionY

{
get { return posicionY; }
set { posicionY = value; }
}

// Constructor de la clase Forma

//
public Forma(int x, int y)
{
posicionX = x;
posicionY = y;
}

public void QuienSoy()

{
Console.WriteLine("Soy la forma situada en (" +
PosicionX + ","+ PosicionY + ")");
}

public float Area()

{
// Una forma generic no tiene rea
Return 0;
}

Y la clase Crculo quedara de la siguiente forma:

1 public class Circulo : Forma

{
private int radio;

public int Radio

{
get { return radio; }
set { radio = value; }
}

// Constructor de la clase Crculo

//
3 public Circulo(int x, int y, int radio) : base (x, y)
{
this.radio = radio;

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 22 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

}
4 public new void QuienSoy()
{
2 Console.WriteLine("Soy el crculo de centro (" +
PosicionX + ", " + PosicionY + ") y radio " + radio);
}

public new float Area()

{
return PI * radio * radio; // PI se define en
System.Double
}
}

Podemos destacar varias cosas:

1. La manera en que Circulo hereda de Forma: class Circulo : Forma

2. La manera en que la clase derivada usa las propiedades pblicas de la

clase base (Console.WriteLine(PosicionX + ...). Esto puede hacerse porque
las propiedades de Forma son pblicas y, por tanto, pueden usarse desde
otra clase. Qu pasara si intentramos llamar directamente al campo
posicionX? La respuesta es que no se puede porque es privado Y si fuera
protegido?

3. Cmo el constructor de Circulo llama al constructor de Forma ( : base (x,

y) ). Esto se hace para pasarle al constructor de la clase base los
parmetros x e y del constructor de la clase derivada. El constructor de
Forma los recibe y los asigna a los campos.

4. El uso de new en el mtodo QuienSoy() y Area(). Esto es para

sobreescribir el mtodo dibujar de la clase base, es decir, en lugar de
usar QuienSoy()/Area() de Forma (que no hace nada), usamos el de
Circulo que imprime por consola los datos del crculo y su rea.

7.2. Sobreescritura

Una subclase sobreescribe un mtodo de su superclase cuando define un

mtodo con las mismas caractersticas ( nombre, nmero y tipo de argumentos)
que el mtodo de la superclase. Las subclases emplean la sobreescritura de
mtodos la mayora de las veces para agregar o modificar la funcionalidad del
mtodo heredado de la clase padre.

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 23 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

En C# se puede sobreescribir un mtodo anteponindole la palabra new al

mtodo que sobreescribe en la subclase (como en el ejemplo). Otra forma de
sobreescribir es marcando el mtodo de la clase base que queremos
sobreescribir con la palabra clave virtual y marcar el mtodo de la clase derivada
con override. De esta forma tendramos:

public virtual void QuienSoy() //Clase Forma

public override void QuienSoy() //Clase Circulo

7.3. Clases y mtodos abstractos

Una clase abstracta es una clase que no puede ser instanciada directamente,
pero s se pueden crear clases derivadas, las cuales se pueden instanciar. Se usa
la palabra clave abstract.

Un mtodo abstracto es un mtodo que tiene tipo, modificadores, nombre y

argumentos, pero no tiene implementacin. Se usa la palabra clave abstract y en
lugar del cuerpo con {} se termina con ;

Una clase que contenga uno o varios mtodos abstractos debe ser declarada
como abstracta. Una clase que herede de una clase abstracta debe implementar
todos los mtodos abstractos o ser declarada abstracta tambin.

Las clases abstractas se usan para definir clases base que generalizan a varias
subclases, pero que no tienen una utilidad directa, normalmente porque no
estn lo suficientemente definidas al ser tan generales. En determinadas
ocasiones, realizan las mismas funciones que un interfaz, pero incorporando
adicionalmente atributos.

En el ejemplo anterior, el mtodo Area() de la clase Forma no hace nada, por lo

que debera ser declarado como abstracto. Adems, la clase Forma en s es
abstracta, porque no podemos saber cmo es una forma sin saber que tipo de
forma es. Con esto lo que hacemos es indicar que todas las clases que deriven
de Forma deben implementar un mtodo para calcular su rea.

Entonces, la declaracin quedara as:

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 24 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

public abstract float Area();

y la de la clase:

public abstract class Forma

Ahora, debemos sobreescribir el mtodo Area de la clase Circulo, pero debemos

usar la palabra override en lugar de new:

public override float Area()

{

7.4. Polimorfismo

Tal y como se ha explicado en el punto 3.3, el polimorfismo es la caracterstica

de la herencia por la cual un mismo mtodo puede invocar a funciones
diferentes segn el tipo de objeto concreto al que est apuntando la clase base
en ese momento. Para ver un ejemplo prctico de polimorfismo, debemos
definir una segunda forma en el rbol de herencia:

public class Cuadrado : Forma

{
private int lado;

public int Lado

{
get { return lado; }
set { lado = value; }
}

// Constructor de la clase Cuadrado

//
public Cuadrado(int x, int y, int lado) : base (x, y)
{
this.lado = lado;
}

public override void QuienSoy()

{
Console.WriteLine("Soy el cuadrado de centro (" +
PosicionX + ", " + PosicionY + ") y lado " + lado);
}

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 25 de 26
 I. E. S. MARE NOSTRUM
Beato Fco. Castell Aleu s/n 965936520
03008 ALICANTE
www.iesmarenostrum.com
[email protected]

public override float Area()

{
return lado * lado;
}
}

Una vez definida la nueva clase, podramos escribir el cdigo siguiente:

Forma miForma;

miForma = new Circulo(5, 5, 5);

miForma.QuienSoy();
Console.WriteLine(miForma.Area());

miForma = new Cuadrado(5, 5, 5);

miForma.QuienSoy();
Console.WriteLine(miForma.Area());

Aunque el objeto miForma es siempre del mismo tipo, primero le asignamos un

objeto de tipo Circulo y a continuacin un objeto del tipo Cuadrado. Las
llamadas a QuienSoy() y Area() son exactamente las mismas, pero en cada caso
producen un efecto diferente, en funcin del tipo de Forma que alberga
miForma. La potencia del polimorfismo radica en sto exactamente, en poder
utilizar diferentes funcionalidades con el mismo objeto base (Forma).

7.5. Ejercicios

Como ejercicio, se propone al alumno, una vez haya adquirido los suficientes
conocimientos programativos, la implementacin de esta jerarqua de clases, as
como su expansin (incorporar nuevos tipos de formas tringulos, rectngulos,
elipses, ) y nuevos mtodos (mover, dibujar, permetro, ).

Entornos de desarrollo Unidad 7 J. R. Garca / R. Snchez

Introduccin al modelado con UML Pgina 26 de 26