Notación UML para modelado Orientado a Objetos

1 Notación UML para modelado Orientado a Objetos

2 Notación UML para modelado Orientado a Objetos Índice 1.1. Qué es UML?.. 3 1.2. Por qué interesa UML en la asignatura de Programación 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 Interacción. 6 1.4.3.1. Diagramas de secuencia 6 1.4.3.2. Diagramas de colaboración 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. Composición. 13 1.7.3. Uso. 13 1.7.4. Asociación. 13 1.7.5. Herencia.. 14 1.8. Recapitulación 15 1.9. Consideraciones. 16 1.10. Bibliografía. 17

3 1.1. Qué es UML? El Lenguaje Unificado de Modelado (UML, Unified Modeling Language) es un lenguaje estándar, basado en una notación gráfica, que se utiliza para modelar software. Es un lenguaje de propósito general que pretende ser un estándar mundial y se utiliza para visualizar, especificar, construir y documentar las diferentes piezas de un sistema. Qué es un modelo? Una simplificación 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 Programación Orientada a Objetos? En la asignatura de Programación Orientada a Objetos se aprende un nuevo paradigma de programación: el paradigma orientado a objetos. A su vez, se utiliza el lenguaje Java para implementar el código de los programas orientados a objetos. Para modelar los programas de forma gráfica, viendo las relaciones entre las clases y cómo colaboran unos objetos con otros, se prefiere utilizar una notación estándar. De esta manera, el alumno va conociendo parte de la notación, UML en este caso, lo cual le será útil por varias razones: Le permite ir familiarizándose con un lenguaje de modelado estándar que verá en otras asignaturas de la titulación. Le permite entender modelos con esta notación. Por todo ello, se verá cómo implementar en código Java un modelo diseñado con UML. De esta manera, se podrán 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 selección de las características más representativas de UML. De éstas no se detallará todo de forma completa, sino sólo aquello que nos interese para representar nuestros diseños orientados a objetos implementados con el lenguaje Java.

4 Notación UML para modelado Orientado a Objetos Además, conviene dejar claro que: UML es un lenguaje de modelado Java es un lenguaje de implementación Por lo tanto, no existe una representación única para código Java, ni tampoco unas reglas exactas de dado cierto código, entonces cierta representación, que se puedan seguir siempre. De hecho, dos modelados diferentes pueden tener el mismo código asociado, por lo que no hay viaje de vuelta. Es decir, dado un código no es posible determinar las relaciones entre las diferentes clases y, por lo tanto, cual es la representación UML. Se trata de un modelado a nivel conceptual. El estándar 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 visión estática como su visión dinámica. La visión estática se puede ver como un conjunto de clases que permiten alcanzar altas cotas de abstracción, encapsulación, modularidad y jerarquía. Por otra parte, la visión dinámica 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 estáticos como los aspectos dinámicos de un programa orientado a objetos. Los aspectos estáticos 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 dinámicos se modelan mediante diagramas de interacción. Éstos, presentan la forma en la que interactúan los diferentes objetos del diagrama. 1.4. Diagramas 1.4.1. Diagramas de Clases Los diagramas de clases proporcionan una perspectiva estática del código. Se componen de: Clases o Gráficamente se representan mediante un rectángulo con el nombre de la clase. Relaciones o De forma gráfica se trata de una línea que une las clases que relaciona. Un ejemplo de diagrama de clases se presenta en la figura 1.

5 Ter Turno Tablero Ficha Coordenada Figura 1. Diagrama de clases 1.4.2. Diagramas de Objetos Los diagramas de objetos proporcionan una perspectiva estática de una ejecución del código. Presentan instantáneas 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 ( fotografía de un momento determinado). Básicamente se componen de: Objetos o De forma gráfica se representa mediante un rectángulo con el nombre del objeto. Relaciones Un ejemplo de diagrama de objetos se presenta en la figura 2.

6 Notación UML para modelado Orientado a Objetos :Ter :Turno :Tablero :Coordenada : : :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 estáticos del sistema, y el segundo los aspectos estáticos de una interacción concreta entre los objetos. 1.4.3. Diagramas de Interacción En los diagramas de interacción se puede ver el patrón de comportamiento de un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto para lograr un propósito. Son dos los tipos de diagramas de interacción: secuencia y colaboración. Ambos están basados en la misma información, aunque cada uno enfatiza un aspecto diferente: el diagrama de secuencia destaca la ordenación temporal de los mensajes y el diagrama de colaboración destaca la organización 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 interacción 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 línea 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.

7 ter:ter turno:turno t:tablero j: jugar() mostrar() poner(t) cambiar() mostrar() Figura 3. Diagrama de secuencia Para especificar quién y cuándo se crean los objetos, se utiliza el estereotipo 1 <<create>>. Como ejemplo se presenta el diagrama de la figura 4. j: t:tablero poner(t) <<create>> c:coordenada recoger() poner(c,f) Figura 4. Diagrama de secuencia con estereotipos 1 Estereotipo: mecanismo de extensibilidad de UML para representar una distinción de uso. Es aplicable a cualquier elemento de modelado.

8 Notación UML para modelado Orientado a Objetos 1.4.3.2. Diagramas de colaboración Un diagrama de colaboración también muestra la interacción entre los objetos, pero basándose en las relaciones entre ellos. En la figura 5 se puede ver un ejemplo de diagrama de colaboración. 1: jugar() ter:ter 5: mostrar() 2: mostrar() t:tablero 4: cambiar() j: 3: poner(t) turno:turno Figura 5. Diagrama de colaboración El diagrama de secuencia y el diagrama de colaboración son equivalentes, ambos muestran una interacción entre los objetos. Simplemente uno de ellos destaca la ordenación temporal y el otro la estructura de la interacción. 1.5. Clases Las clases de Java se representarán tal como aparece en la figura 6. Se trata de un rectángulo 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. Representación de una clase con UML Los niveles de visibilidad de los elementos se representan como sigue: Privado: - Protegido: # Público: + En la figura 7 se presenta un ejemplo de clase Java junto con su representación UML.

9 Ficha class Ficha { -color:char +mostrar() +igual(ficha):boolean private char color; public void mostrar() { public boolean igual(ficha ficha) { Figura 7. Ejemplo de representación de una clase con UML 1.5.1. Clases Abstractas La representación 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. Representación de una clase abstracta con UML 1.5.2. Interfaces Una interfaz se representa exactamente igual que una clase normal, salvo que se añade un estereotipo ( <<interface>> en este caso) en la parte superior del rectángulo, 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. Representación de un interfaz con UML

10 Notación UML para modelado Orientado a Objetos 1.6. Objetos Para representar una instancia concreta de una clase con la notación UML también se utiliza un rectángulo 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 aparecerán los atributos del objeto con sus valores. Aquellos atributos compartidos por todas las instancias de una clase no se añaden aquí. Por último, en la parte inferior del rectángulo van las operaciones que puede realizar el objeto por pertenecer a una clase determinada, aunque éstas se pueden omitir. También es posible, entre otras cosas, omitir la parte central del rectángulo e, incluso, poner sólo la clase del objeto sin hacer referencia a su nombre. Ejemplos de esta notación se pueden ver en la figura 10. f:ficha f:ficha color=` :Ficha Figura 10. Notación UML para representar objetos En nuestro caso utilizaremos la notación en la que aparece simplemente el nombre de la clase a la que pertenece el objeto (ver figura 11). La razón es porque realmente qué nombre tienen los objetos?, es decir, qué ocurre si se tienen muchas referencias al mismo objeto? ( cuál de todos los nombres de esas referencias se refleja en el diagrama?). :Ficha Figura 11. Notación UML para objetos con nombre de clase únicamente 1.7. Relaciones Cuando se realizan abstracciones son pocas las clases que actúan solas; lo normal es que existan diferentes relaciones entre las clases. Entre clases pueden existir cuatro tipos de relación: composición, asociación, uso y herencia. Las tres primeras se dan cuando objetos de las clases colaboran entre sí. Sin embargo, el hecho de que exista una relación de herencia entre dos clases no implica que los objetos de dichas clases colaboren, puede que nunca lo hagan. 1.7.1. Detalles Se tendrán en cuenta una serie de detalles para todas las relaciones. Estos detalles deberán acompañar a la relación en los diagramas.

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. Ficha class { 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 conoce a un objeto de la clase Ficha, por consiguiente, le puede lanzar mensajes, y no al revés. 1.7.1.2. Multiplicidad La multiplicidad consiste en especificar el rango de cardinalidades que puede asumir un conjunto, de forma que se indica cuántos objetos de una clase se relacionan con objetos de la otra clase que forma parte de la relación. Las restricciones de multiplicidad se deberán indicar en el diagrama. En UML es posible especificar la multiplicidad de una clase mediante una expresión en la esquina superior derecha de la misma e, incluso, también 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 número de instancias de una clase que se relaciona con instancias de otra clase, y se indicará al lado de la clase cuyo número de instancias se intenta precisar. En la figura 13 se puede ver un ejemplo. Ficha class { private Ficha ficha; Figura 13. Multiplicidad de la relación 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 y, a su vez, un objeto de la clase tiene un único objeto de la clase Ficha. Para representar una multiplicidad de varios elementos, donde no se sabe el número exacto que tienen, se suele indicar mediante el rango posible. Por ejemplo: 0..

12 Notación UML para modelado Orientado a Objetos *, 1..*, etc. En nuestro caso, simplemente indicaremos la parte máxima del rango y, además, utilizaremos una restricción 2 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 class Ter { private final [ ] JUGADORES = new [2]; Figura 14. Uso de restricciones en la multiplicidad de la relación entre clases En el ejemplo presentado en la figura 14 se conoce el número 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 relación, éste no será especificado. Lo que si se reflejará en los diagramas será el rol que juega en la relación la clase destino de la navegación. 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 relación con otra clase. De forma general se presenta un ejemplo en la figura 15. El nombre del rol que desempeña la clase se especifica al lado de ésta. Empresa Empleado trabajador Figura 15. Roles de las clases Además, en nuestro caso, el rol de la clase será el nombre del atributo. Un ejemplo se presenta en el diagrama de la figura 16. ficha Ficha class { private Ficha ficha; Figura 16. Rol de la clase Ficha en la relación con 2 Restricción: restricción de la semántica de un elemento de UML, que permite añadir nuevas reglas o modificar las existentes.

13 1.7.2. Composición La relación de composición es la relación 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 relación, se hace distinción entre Composición y Agregación. Nosotros simplemente vamos a referirnos a composición, representando la relación como una línea acabada en un rombo en el extremo de la clase que representa el todo (ver figura 17). tablero Tablero Ter class Ter { 2 JUGADORES private Tablero tablero; private final [ ] JUGADORES; Figura 17. Relación de composición entre clases 1.7.3. Uso La relación de uso (en UML se denomina de dependencia) es una relación momentánea 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 línea punteada que une ambas clases. En la figura 18 se presenta un ejemplo de relación de uso. Coordenada class { public void mover(tablero tablero) { Coordenada c = new Coordenada(); c.recoger(); Figura 18. Relación de uso entre clases En el caso de la relación de uso no hay posible rol a establecer (siguiendo la pauta de que el rol sea el nombre del atributo). 1.7.4. Asociación La relación de asociación es una relación 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 relación se representa en UML mediante una línea que une ambas clases, como se puede apreciar en la figura 19.

14 Notación UML para modelado Orientado a Objetos ficha Ficha class { private Ficha ficha; Figura 19. Relación de asociación entre clases 1.7.5. Herencia La relación de herencia (en UML denominada Generalización) es aquella que se establece entre dos clases, transmitiendo tanto atributos como métodos de la clase padre a la clase hija. La clase hija será una especialización de la clase padre. En este caso la representación UML se realiza mediante un triángulo en el extremo de la relación donde se encuentra la clase más general, la clase padre (ver figura 20). ClasePadre ClaseHija class ClaseHija extends ClasePadre { Figura 20. Relación de herencia entre clases La representación es la misma si la relación de herencia se da entre interfaces (ver figura 21), o si una clase hereda por implementación de una interfaz (ver figura 22). <<interface>> InterfazPadre <<interface>> InterfazHijo interface InterfazHijo extends InterfazPadre { Figura 21. Relación de herencia entre interfaces

15 <<interface>> InterfazPadre ClaseHija class ClaseHija implements InterfazPadre { Figura 22. Relación de herencia por implementación 1.8. Recapitulación 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 ficha FICHAS Ficha {array * Coordenada Figura 23. Diagrama de clases completo El diagrama de objetos que se tenía se ha completado añadiendo la navegabilidad, quedando como se muestra en la figura 24.

16 Notación UML para modelado Orientado a Objetos :Ter :Turno :Tablero :Coordenada : : :Ficha :Coordenada :Ficha :Ficha Figura 24. Diagrama de objetos completo 1.9. Consideraciones Observando la notación gráfica 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 algún tipo de relación entre ellas. Por lo tanto, es necesario tomar una decisión 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 situación 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

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 notación gráfica de la clase Persona. Sin embargo, en la figura 25(b) la fecha de nacimiento de la persona se manifiesta a través de una relación entre clases. Para intentar unificar la forma de representar nuestros programas orientados a objetos, en principio se va a optar por la segunda opción (figura 25(b)), y sólo en aquel caso en el que el diagrama esté muy cargado, se optará por representar algunos atributos mediante la primera opción (figura 25(a)). 1.10. Bibliografía G. Booch, I. Jacobson, J. Rumbaugh; El Lenguaje Unificado de Modelado. Manual de Referencia. Addison Wesley.