Programacin Orientada a Objetos

Notacin UML para modelado Orientado a Objetos

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

Notacin UML para modelado Orientado a Objetos

ndice

1.1. Qu es UML?.................................................................................................. 3 1.2. Por qu interesa UML en la asignatura de Programacin Orientada a Objetos? ........................................................................................................................ 3 1.3. Qu se va a modelar? ...................................................................................... 3 1.4. Diagramas......................................................................................................... 4 1.4.1. Diagramas de Clases................................................................................. 4 1.4.2. Diagramas de Objetos............................................................................... 5 1.4.3. Diagramas de Interaccin ......................................................................... 6 1.4.3.1. Diagramas de secuencia........................................................................ 6 1.4.3.2. Diagramas de colaboracin .................................................................. 8 1.5. Clases................................................................................................................ 8 1.5.1. Clases Abstractas...................................................................................... 9 1.5.2. Interfaces .................................................................................................. 9 1.6. Objetos............................................................................................................ 10 1.7. Relaciones....................................................................................................... 10 1.7.1. Detalles ................................................................................................... 10 1.7.1.1. Navegabilidad..................................................................................... 11 1.7.1.2. Multiplicidad ...................................................................................... 11 1.7.1.3. Rol ...................................................................................................... 12 1.7.2. Composicin........................................................................................... 13 1.7.3. Uso.......................................................................................................... 13 1.7.4. Asociacin .............................................................................................. 13 1.7.5. Herencia.................................................................................................. 14 1.8. Recapitulacin ................................................................................................ 15 1.9. Consideraciones.............................................................................................. 16 1.10. Bibliografa................................................................................................. 17

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

Programacin Orientada a Objetos

1.1.

Qu es UML?

El Lenguaje Unificado de Modelado (UML, Unified Modeling Language) es un lenguaje estndar, basado en una notacin grfica, que se utiliza para modelar software. Es un lenguaje de propsito general que pretende ser un estndar mundial y se utiliza para visualizar, especificar, construir y documentar las diferentes piezas de un sistema. Qu es un modelo? Una simplificacin de la realidad. Por qu se modela? Se construyen modelos para poder entender mejor el sistema a desarrollar, o bien, un sistema desarrollado. 1.2. Por qu interesa UML en la asignatura de Programacin Orientada a Objetos? En la asignatura de Programacin Orientada a Objetos se aprende un nuevo paradigma de programacin: el paradigma orientado a objetos. A su vez, se utiliza el lenguaje Java para implementar el cdigo de los programas orientados a objetos. Para modelar los programas de forma grfica, viendo las relaciones entre las clases y cmo colaboran unos objetos con otros, se prefiere utilizar una notacin estndar. De esta manera, el alumno va conociendo parte de la notacin, UML en este caso, lo cual le ser til por varias razones: Le permite ir familiarizndose con un lenguaje de modelado estndar que ver en otras asignaturas de la titulacin. Le permite entender modelos con esta notacin.

Por todo ello, se ver cmo implementar en cdigo Java un modelo diseado con UML. De esta manera, se podrn hacer diagramas modelando los programas orientados a objetos que se implementen con el lenguaje Java. 1.3. Qu se va a modelar?

Se presentar una seleccin de las caractersticas ms representativas de UML. De stas no se detallar todo de forma completa, sino slo aquello que nos interese para representar nuestros diseos orientados a objetos implementados con el lenguaje Java.

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

Notacin UML para modelado Orientado a Objetos

Adems, conviene dejar claro que: UML es un lenguaje de modelado Java es un lenguaje de implementacin

Por lo tanto, no existe una representacin nica para cdigo Java, ni tampoco unas reglas exactas de dado cierto cdigo, entonces cierta representacin, que se puedan seguir siempre. De hecho, dos modelados diferentes pueden tener el mismo cdigo asociado, por lo que no hay viaje de vuelta. Es decir, dado un cdigo no es posible determinar las relaciones entre las diferentes clases y, por lo tanto, cual es la representacin UML. Se trata de un modelado a nivel conceptual. El estndar UML no pide que se indique todo en los diagramas, sino que lo que se refleje en ellos sea cierto. En nuestro caso, dado un programa orientado a objetos nos interesa tanto su visin esttica como su visin dinmica. La visin esttica se puede ver como un conjunto de clases que permiten alcanzar altas cotas de abstraccin, encapsulacin, modularidad y jerarqua. Por otra parte, la visin dinmica de un programa se puede ver como un conjunto de objetos, los cuales colaboran entre s mediante el desencadenamiento de instanciaciones y de paso de mensajes. Por ello, se van a modelar tanto los aspectos estticos como los aspectos dinmicos de un programa orientado a objetos. Los aspectos estticos se modelan mediante diagramas de clases y diagramas de objetos. Los primeros se componen de un conjunto de clases y las relaciones entre ellas, mientras que en los segundos las relaciones se dan entre un conjunto de objetos. Los aspectos dinmicos se modelan mediante diagramas de interaccin. stos, presentan la forma en la que interactan los diferentes objetos del diagrama. 1.4. Diagramas

1.4.1. Diagramas de Clases Los diagramas de clases proporcionan una perspectiva esttica del cdigo. Se componen de: Clases o Grficamente se representan mediante un rectngulo con el nombre de la clase. Relaciones o De forma grfica se trata de una lnea que une las clases que relaciona. Un ejemplo de diagrama de clases se presenta en la figura 1.

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

Programacin Orientada a Objetos

Ter

Turno Jugador

Tablero

Ficha

Coordenada

Figura 1. Diagrama de clases 1.4.2. Diagramas de Objetos Los diagramas de objetos proporcionan una perspectiva esttica de una ejecucin del cdigo. Presentan instantneas de instancias de los elementos que aparecen en los diagramas de clases. En definitiva, muestran un conjunto de objetos y sus relaciones en un momento concreto (fotografa de un momento determinado). Bsicamente se componen de: Objetos o De forma grfica se representa mediante un rectngulo con el nombre del objeto. Relaciones Un ejemplo de diagrama de objetos se presenta en la figura 2.

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

Notacin UML para modelado Orientado a Objetos

:Ter :Turno :Tablero

:Coordenada
...

:Jugador :Jugador :Ficha

:Coordenada

:Ficha :Ficha

Figura 2. Diagrama de objetos La diferencia clara entre un diagrama de clases y un diagrama de objetos es que el primero representa los aspectos estticos del sistema, y el segundo los aspectos estticos de una interaccin concreta entre los objetos. 1.4.3. Diagramas de Interaccin En los diagramas de interaccin se puede ver el patrn de comportamiento de un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto para lograr un propsito. Son dos los tipos de diagramas de interaccin: secuencia y colaboracin. Ambos estn basados en la misma informacin, aunque cada uno enfatiza un aspecto diferente: el diagrama de secuencia destaca la ordenacin temporal de los mensajes y el diagrama de colaboracin destaca la organizacin estructural (qu objetos colaboran con otros) de los objetos que intercambian mensajes. 1.4.3.1. Diagramas de secuencia

Estos diagramas presentan, ordenados temporalmente, los objetos que participan en una interaccin y los mensajes que se intercambian. En el diagrama, en cada eje vertical se coloca un objeto. Los mensajes se representan mediante flechas horizontales de un objeto a otro, donde el retorno se representa mediante una lnea punteada del objeto pasivo al objeto agente del mensaje. El tiempo fluye de arriba hacia abajo. Un ejemplo de diagrama de secuencia de presenta en la figura 3.

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

Programacin Orientada a Objetos

ter:Ter
jugar()

turno:Turno

t:Tablero

j:Jugador

mostrar()

poner(t)

cambiar()

mostrar()

...

Figura 3. Diagrama de secuencia Para especificar quin y cundo se crean los objetos, se utiliza el estereotipo1 <<create>>. Como ejemplo se presenta el diagrama de la figura 4.

j:Jugador
poner(t) <<create>>

t:Tablero

c:Coordenada

recoger()

poner(c,f)

...

Figura 4. Diagrama de secuencia con estereotipos

1

Estereotipo: mecanismo de extensibilidad de UML para representar una distincin de uso. Es aplicable a cualquier elemento de modelado.

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

8 1.4.3.2.

Notacin UML para modelado Orientado a Objetos

Diagramas de colaboracin

Un diagrama de colaboracin tambin muestra la interaccin entre los objetos, pero basndose en las relaciones entre ellos. En la figura 5 se puede ver un ejemplo de diagrama de colaboracin.
5: mostrar() 2: mostrar()

1: jugar()

ter:Ter
4: c am bi ar( )

t:Tablero

3: poner(t)

turno:Turno j:Jugador
Figura 5. Diagrama de colaboracin El diagrama de secuencia y el diagrama de colaboracin son equivalentes, ambos muestran una interaccin entre los objetos. Simplemente uno de ellos destaca la ordenacin temporal y el otro la estructura de la interaccin. 1.5. Clases

Las clases de Java se representarn tal como aparece en la figura 6. Se trata de un rectngulo dividido en tres partes: la parte superior indica el nombre de la clase; la parte central contiene los atributos y, por ltimo, la parte inferior presentar las operaciones de la clase.

NombreClase

Atributos

Operaciones

Figura 6. Representacin de una clase con UML Los niveles de visibilidad de los elementos se representan como sigue: UML. Privado: Protegido: # Pblico: +

En la figura 7 se presenta un ejemplo de clase Java junto con su representacin

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

Programacin Orientada a Objetos

Ficha
-color:char

class Ficha { private char color; public void mostrar() {...} public boolean igual(Ficha ficha) {...} }

+mostrar() +igual(Ficha):boolean

Figura 7. Ejemplo de representacin de una clase con UML 1.5.1. Clases Abstractas La representacin para las clases abstractas es igual que para las clases normales, salvo que el nombre de la clase se escribe en cursiva, como se puede apreciar en la figura 8.

ClaseA abstract class ClaseA { ... }

Figura 8. Representacin de una clase abstracta con UML 1.5.2. Interfaces Una interfaz se representa exactamente igual que una clase normal, salvo que se aade un estereotipo (<<interface>> en este caso) en la parte superior del rectngulo, indicando, precisamente, que se trata de una interfaz y no de una clase normal. En la figura 9 se presenta un ejemplo.

<<interface>> InterfazA

interface InterfazA { ... }

Figura 9. Representacin de un interfaz con UML

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

10 1.6. Objetos

Notacin UML para modelado Orientado a Objetos

Para representar una instancia concreta de una clase con la notacin UML tambin se utiliza un rectngulo con tres partes. En la primera se especifica el nombre del objeto separado por dos puntos del nombre de la clase, todo ello subrayado. En la segunda parte aparecern los atributos del objeto con sus valores. Aquellos atributos compartidos por todas las instancias de una clase no se aaden aqu. Por ltimo, en la parte inferior del rectngulo van las operaciones que puede realizar el objeto por pertenecer a una clase determinada, aunque stas se pueden omitir. Tambin es posible, entre otras cosas, omitir la parte central del rectngulo e, incluso, poner slo la clase del objeto sin hacer referencia a su nombre. Ejemplos de esta notacin se pueden ver en la figura 10.
f:Ficha

f:Ficha

color=`

:Ficha

Figura 10. Notacin UML para representar objetos En nuestro caso utilizaremos la notacin en la que aparece simplemente el nombre de la clase a la que pertenece el objeto (ver figura 11). La razn es porque realmente qu nombre tienen los objetos?, es decir, qu ocurre si se tienen muchas referencias al mismo objeto? (cul de todos los nombres de esas referencias se refleja en el diagrama?).

:Ficha

Figura 11. Notacin UML para objetos con nombre de clase nicamente 1.7. Relaciones

Cuando se realizan abstracciones son pocas las clases que actan solas; lo normal es que existan diferentes relaciones entre las clases. Entre clases pueden existir cuatro tipos de relacin: composicin, asociacin, uso y herencia. Las tres primeras se dan cuando objetos de las clases colaboran entre s. Sin embargo, el hecho de que exista una relacin de herencia entre dos clases no implica que los objetos de dichas clases colaboren, puede que nunca lo hagan. 1.7.1. Detalles Se tendrn en cuenta una serie de detalles para todas las relaciones. Estos detalles debern acompaar a la relacin en los diagramas.

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

Programacin Orientada a Objetos

11

1.7.1.1. Navegabilidad Se contemplar la navegabilidad en las relaciones, es decir, el sentido de las mismas. Se representar mediante una flecha, la cual indica que es posible navegar desde el objeto de la clase origen al objeto de la clase destino. Por tanto, el objeto de la clase origen conoce a los objetos de la clase destino, de manera que podr invocar operaciones de stos. En la figura 12 se presenta un ejemplo de navegabilidad.

Jugador

Ficha

class Jugador { private Ficha ficha; }

Figura 12. Navegabilidad entre clases Si se observa la figura anterior, atendiendo solo a la navegabilidad, se puede ver que un objeto de la clase Jugador conoce a un objeto de la clase Ficha, por consiguiente, le puede lanzar mensajes, y no al revs. 1.7.1.2. Multiplicidad La multiplicidad consiste en especificar el rango de cardinalidades que puede asumir un conjunto, de forma que se indica cuntos objetos de una clase se relacionan con objetos de la otra clase que forma parte de la relacin. Las restricciones de multiplicidad se debern indicar en el diagrama. En UML es posible especificar la multiplicidad de una clase mediante una expresin en la esquina superior derecha de la misma e, incluso, tambin se puede especificar la multiplicidad para los atributos. En nuestro caso, simplemente reflejaremos la multiplicidad en los diagramas de clases a nivel de las relaciones entre clases. Por lo tanto, se especificar el nmero de instancias de una clase que se relaciona con instancias de otra clase, y se indicar al lado de la clase cuyo nmero de instancias se intenta precisar. En la figura 13 se puede ver un ejemplo.
Jugador Ficha

class Jugador { private Ficha ficha; }

Figura 13. Multiplicidad de la relacin entre clases Las multiplicidades con valor 1 no se suelen representar, lo cual queda patente mediante el diagrama presentado en la figura anterior. En este caso, un objeto de la clase Ficha forma parte de un nico objeto de la clase Jugador y, a su vez, un objeto de la clase Jugador tiene un nico objeto de la clase Ficha. Para representar una multiplicidad de varios elementos, donde no se sabe el nmero exacto que tienen, se suele indicar mediante el rango posible. Por ejemplo: 0..

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

12

Notacin UML para modelado Orientado a Objetos

*,1..*, etc. En nuestro caso, simplemente indicaremos la parte mxima del rango y, adems, utilizaremos una restriccin2 para indicar el tipo de secuencia de elementos que es. Por ejemplo: {array} (si es una tabla normal), {ArrayList} (si se trata de un objeto de la clase ArrayList de Java), {List} (si se trata de un objeto de la clase List de Java), etc. Un ejemplo se presenta en la figura 14.
Ter
{array} 2

Jugador

class Ter { private final Jugador [ ] JUGADORES = new Jugador[2]; }

Figura 14. Uso de restricciones en la multiplicidad de la relacin entre clases En el ejemplo presentado en la figura 14 se conoce el nmero exacto de la multiplicidad. En caso de ser mayor que 1 y no conocerse con exactitud se indicar con *. 1.7.1.3. Rol Por ltimo, con respecto al nombre de la relacin, ste no ser especificado. Lo que si se reflejar en los diagramas ser el rol que juega en la relacin la clase destino de la navegacin. El rol es el comportamiento de una entidad que participa en un contexto particular. Es decir, se indica el rol que juega una clase dentro de la relacin con otra clase. De forma general se presenta un ejemplo en la figura 15. El nombre del rol que desempea la clase se especifica al lado de sta.
Empresa
trabajador

Empleado

Figura 15. Roles de las clases Adems, en nuestro caso, el rol de la clase ser el nombre del atributo. Un ejemplo se presenta en el diagrama de la figura 16.
Jugador Ficha

class Jugador { private Ficha ficha; }

ficha

Figura 16. Rol de la clase Ficha en la relacin con Jugador

Restriccin: restriccin de la semntica de un elemento de UML, que permite aadir nuevas reglas o modificar las existentes.
2

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

Programacin Orientada a Objetos

13

1.7.2. Composicin La relacin de composicin es la relacin entre el todo y la parte, siendo responsabilidad del todo lo que le ocurra a cada una de las partes. En UML, para referirse a este tipo de relacin, se hace distincin entre Composicin y Agregacin. Nosotros simplemente vamos a referirnos a composicin, representando la relacin como una lnea acabada en un rombo en el extremo de la clase que representa el todo (ver figura 17).
tablero

Tablero

Ter Jugador

class Ter { private Tablero tablero; private final Jugador [ ] JUGADORES; }

2 JUGADORES

Figura 17. Relacin de composicin entre clases 1.7.3. Uso La relacin de uso (en UML se denomina de dependencia) es una relacin momentnea que se establece entre un cliente y un servidor. La responsabilidad de manejar un objeto servidor no tiene porqu depender nicamente de la clase cliente. En UML se representa mediante una lnea punteada que une ambas clases. En la figura 18 se presenta un ejemplo de relacin de uso.
class Jugador {

Jugador

Coordenada

public void mover(Tablero tablero) { Coordenada c = new Coordenada(); c.recoger(); ... }

Figura 18. Relacin de uso entre clases En el caso de la relacin de uso no hay posible rol a establecer (siguiendo la pauta de que el rol sea el nombre del atributo). 1.7.4. Asociacin La relacin de asociacin es una relacin que perdura entre un cliente y un servidor, donde la responsabilidad de manejar el objeto de la clase servidor no tiene porqu depender, nicamente, de la clase cliente. Esta relacin se representa en UML mediante una lnea que une ambas clases, como se puede apreciar en la figura 19.

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

14

Notacin UML para modelado Orientado a Objetos

Jugador
ficha

class Jugador {
Ficha

private Ficha ficha; ... }

Figura 19. Relacin de asociacin entre clases 1.7.5. Herencia La relacin de herencia (en UML denominada Generalizacin) es aquella que se establece entre dos clases, transmitiendo tanto atributos como mtodos de la clase padre a la clase hija. La clase hija ser una especializacin de la clase padre. En este caso la representacin UML se realiza mediante un tringulo en el extremo de la relacin donde se encuentra la clase ms general, la clase padre (ver figura 20).
ClasePadre

class ClaseHija extends ClasePadre { ... }

ClaseHija

Figura 20. Relacin de herencia entre clases La representacin es la misma si la relacin de herencia se da entre interfaces (ver figura 21), o si una clase hereda por implementacin de una interfaz (ver figura 22).

<<interface>> InterfazPadre

interface InterfazHijo extends InterfazPadre { ... }

<<interface>> InterfazHijo

Figura 21. Relacin de herencia entre interfaces

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

Programacin Orientada a Objetos

15

<<interface>> InterfazPadre

class ClaseHija implements InterfazPadre { ... }

ClaseHija

Figura 22. Relacin de herencia por implementacin 1.8. Recapitulacin

Una vez estudiados todos los detalles de clases, objetos y relaciones, en este apartado se presentan de nuevo los diagramas de clases y objetos mostrados en el apartado 1.4. Dichos diagramas se han completado indicando los tipos de relaciones entre las clases, la navegabilidad, la multiplicidad, los roles, etc. El diagrama de clases completo se presenta en la figura 23.
Ter

turno

Turno

JUGADORES 2 {array}

tablero

Tablero

Jugador

ficha FICHAS *
{array}

Ficha

Coordenada

Figura 23. Diagrama de clases completo El diagrama de objetos que se tena se ha completado aadiendo la navegabilidad, quedando como se muestra en la figura 24.

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

16

Notacin UML para modelado Orientado a Objetos

:Ter :Turno :Tablero :Coordenada

...

:Jugador :Jugador :Ficha

:Coordenada

:Ficha :Ficha

Figura 24. Diagrama de objetos completo 1.9. Consideraciones

Observando la notacin grfica de UML para las clases, se puede apreciar que se indican los diferentes atributos de una clase. Estos atributos pueden ser objetos de otras clases, lo que va a marcar seguro algn tipo de relacin entre ellas. Por lo tanto, es necesario tomar una decisin con respecto al lugar en el que se ponen dichos atributos, de forma que en el diagrama de clases no sea redundante. Un ejemplo de esta situacin se muestra en la figura 25.

Persona fechaNacimiento: Fecha

Libro publicacion: Fecha

(a)

Persona

Fecha

Libro

fechaNacimiento

publicacion

(b)

Figura 25. Equivalencia parcial entre notaciones

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo

Programacin Orientada a Objetos

17

Como se puede apreciar, en la figura 25(a) el atributo que hace referencia a la fecha de nacimiento de una persona va incluido en la parte central de la notacin grfica de la clase Persona. Sin embargo, en la figura 25(b) la fecha de nacimiento de la persona se manifiesta a travs de una relacin entre clases. Para intentar unificar la forma de representar nuestros programas orientados a objetos, en principio se va a optar por la segunda opcin (figura 25(b)), y slo en aquel caso en el que el diagrama est muy cargado, se optar por representar algunos atributos mediante la primera opcin (figura 25(a)). 1.10. Bibliografa

G. Booch, I. Jacobson, J. Rumbaugh; El Lenguaje Unificado de Modelado. Manual de Referencia. Addison Wesley.

Universidad Rey Juan Carlos curso 04/05 Soto Montalvo