Diagramas de Clases

1. Diagramas de Clases Javier Garzás jgarzas@altransdb.com jgarzas@acm.org

2. Situación... Análisis ...Diseño

3. Diagramas de Clases • Dentro de los métodos OO, es la técnica central y, en la mayoría de los casos, la más importante. • Un diagrama de clases describe: • Los tipos de objetos en el sistema • Las relaciones estáticas que existen entre ellos • Los atributos y operaciones de las clases • Las restricciones a las clases y a sus asociaciones.

4. Conceptos básicos y de notación

5. Diagrama de Clases Existen 3 formas de ver un diagrama de clases (Cook & Daniels 1994) Conceptual:representan conceptos de dominio, relacionados con las clases del mismo. Puede no existir un “mapeo” directo. Independientes y con poco detalle. Especificación: donde se buscan las interfaces software (aún no la implementación) Implementación: con máximo nivel de detalle y muy cercano al programador.

6. Clases... Notación Gráfica • En UML las clases se representa mediante un rectángulo que puede estar dividido en tres partes. Nombre Atributos Servicios

7. Clases... Encapsulación • Algunas ventajas: • Se protegen los datos. • Se posibilita una reducción del acoplamiento • Los atributos de una clase NUNCA, NUNCA, NUNCA deben ser accesibles por objetos de otra clase.

8. Clases... Encapsulación • Los niveles de encapsulación están heredados de los niveles de C++: • “-” Privado: es el más fuerte. Esta parte es totalmente invisible (excepto para los “friends” en terminología C++) • “#”Protegido: visibles para los friends y para las clases hijas de una superclase. • “+”Pública: visibles a todas las clases.

9. Clases... Encapsulación • Ejemplo: Reglas de visibilidad + Atributo público : int # Atributo protegido : int - Atributo privado : int + "Operación pública" # "Operación protegida" - "Operación privada"

10. Clases... Encapsulación • Heurística:  Perro # raza + colorPelo # nombre + guardarHueso() + marcaTerritorio() + orinar()

11. Estereotipos • Creados por Wirfs - Brock (1990) • Sugieren cierto nivel de responsabilidad a las clases • Jacobson en 1994 clasificó las clases con tres clasificadores (boudary, control y entity), bien aplicados son los coordinators de Wirfst - Brock • En UML se muestran entre comillas españolas <<>>, pero también pueden definirse mediante iconos especiales. • Definen muchas de las restricciones de UML

12. Clases Abstractas • Las clases y servicios abstractos se notan mediante formato itálico • También puede usarse la restricción {abstract}, junto al nombre de la clase, evitándose así el escribir en itálica • Las asociaciones entre una clase “cliente” y un tipo (como es una clase abstracta o una interface) se representan mediante dependencias:

13. Interfaces • Son clases sin ninguna implementación. Declaran operaciones (servicios) pero NI métodos NI atributos. Pueden declararse mediante clases abstractas que no tienen ningún método. • Existen dos posibles notaciones: • Mediante un estereotipo <<interface>> • Simbolizando el estereotipo mediante un circulo.

14. Interfaces • Como las clases abstractas, son tipos y, por tanto, sus clientes se relacionan por dependencias. • La clase que implementa una interfaz (subtipos) se relaciona mediante “refinamiento” (existen dos notaciones para el refinamiento).

15. Clases Abstractas e Interfaces

16. Relaciones entre Clases

17. Relaciones entre clases • Los enlaces a nivel de objetos pueden verse en el mundo de las clases • Las dos principales relaciones estáticas son: • Asociación • Generalización

18. Asociación

19. Asociación • Representan relaciones entre instancias de clases • Desde la perspectiva conceptual representan relaciones entre clases.

20. Elementos de una Asociación • Nombre • Rol(es) • Multiplicidad 1 Uno y sólo uno 0..1 Cero o uno M..N De M a N (enteros naturales) * De cero a varios 0..* De cero a varios 1..* De uno a varios La multiplicidad puede establecer restricciones de existencia para los objetos de las clases asociadas

21. Elementos de una Asociación

22. Asociación y los estratos del diseño En las asociaciones también se notan las diferentes formas de ver un diagrama de clases (conceptual, especificación implementación), así, en fases cercanas al diseño, por lo general... • Se definen direccionalidades • Se decide la forma de implementar las cardinalidades: • A n mediante Vectores. • A 1, 0 mediante apuntadores. • Etc.

23. Implementación de Asociaciones Public class Amo { Vector misPerros = new Vector(); ... misPerros.addElement(new Perro(“Kika”); ... }

24. Asociación Cualificada 0..1 * Aerolínea Viajero nro_viajero 1 1 Tablero Ajedrez Cuadro fila columna • Un objeto y un cualificador identifican a un único objeto en la asociación (forma una clave compuesta) • Reduce la multiplicidad del rol opuesto. La nueva multiplicidad es 0 ó 1 (si hay mapeo para todos los valores del dominio del cualificador)

25. Caso especial… la Agregación • Representa un objeto compuesto por otros objetos • Relación parte_de • Podemos tener agregaciones (paso por referencia) y composiciones (paso por valor) contiene 3.. * 1 Polígono Punto {ordenado}

26. Asociaciones de clase • Aparecen cuando la propia asociación tiene atributos • Son raras y poco frecuentes • ¿Os recuerda en algo a los E/R de Chen?

27. Jerarquías

28. Jerarquías de Clases +General +Específico

29. Jerarquías de Clases • Una posible clasificación: • Particionamiento del espacio de objetos Especialización Estática • Particionamiento del espacio de estados de los objetos Especialización Dinámica

30. Jerarquías de Clases • En la Especialización Estática • El objeto es instancia desde su creación de la subclase y la superclase en las que fue creado. • Esta pertenencia es inmutable • Un objeto sólo puede ser instancia de una subclase en una Especialización Estática

31. Jerarquías de Clases • En la Especialización Dinámica: • Un objeto puede migrar durante su vida entre las distintas subclases de la especialización. • La migración puede definirse en función de su estado o de los eventos que le acontezcan

32. Jerarquías de Clases • Un ejemplo de Especialización Estática:

33. Jerarquías de Clases • Un ejemplo de Especialización Dinámica:

34. Jerarquías de Clases • Puede haber más de una especialización estática o dinámica a partir de la misma superclase

35. Jerarquías de Clases • Clasificación no equilibrada:

36. Cómo no usar la herencia

37. Regla de herencia: “Es_un” Regla #1: El ES_UN “Nunca haga que B herede de A a no ser que pueda argumentarse de alguna forma que se puede ver toda instancia de la clase B como instancia de la clase A” Todo B es_un A Problema: Es condición necesaria pero no suficiente ¿Es toda cuenta de ahorros una cuenta corriente?

38. ¿Tener o Ser? • Para decidir entre las dos posibles relaciones entre módulos, la regla es: • “Tener”, para asociaciones. • “Es”, para la herencia. Fácil elección ¿no?

39. ¿Tener o Ser? • Por ejemplo: • Todo Alumno de este curso es un Consultor de Altran • En todo alumno de este curso hay un consultor de Altran • Todo alumno de este curso tiene un cierto componente de consultor de Altran… ¡EL ES puede parafrasearse SIEMPRE como TIENE! ¿Y al contrario?

40. Entonces… ¿cómo saber qué aplicar? Regla #2: Del Cambio “Nunca modele una relación mediante herencia si los componentes objeto correspondientes pudieran tener que ser modificados en tiempo de ejecución”

41. Regla del cambio • Recordemos que la herencia es una relación entre clases • Si B hereda de A, todo objeto de B es un objeto A. • Los objetos NO pueden modificar la anterior propiedad… ¡es una relación estructural! • La relación “tiene” permite el dinamismo en tiempo de ejecución.

42. Regla del Polimorfismo Regla #3: Del Polimorfismo “La herencia es adecuada para describir estructuras donde los componentes más generales pueden tener la necesidad de asociarse a otros más específicos”

43. Ejercicio • Se pretende modelar en UML un sistema para crear ventanas gráficas en una interfaz de usuario. • Este sistema debe contemplar: • La posibilidad de que las ventanas creadas se ejecuten en distintas plataformas (Linux, Windows, etc.). • Que los clientes de estas ventanas estén mínimamente acoplados a una ventana concreta. Las ventanas podrán ser frames, windows, etc.

44. Solución 1

45. Problemas a la solución 1 • Se puede violar una de las reglas anteriores… una vez que una ventana es una ventana “Linux” NUNCA dejará de serlo • Esto puede no ser tan malo… las ventanas Linux no creo que pretendan transformarse en Windows • Pero si en vez de plataformas fuesen formatos (*.pdf, *.ppt o *.ps) la cosa podría se mas sería

46. Solución 2

47. Problemas a la solución 2 • ¿Y si ahora queremos una ventana para OS/2? 

48. Solución 3 • De todas formas no habría hecho falta pensar nada… es una versión del pattern Bridge (Gamma et al 95)

49. Regla de la Taxomanía Regla #4: De la Taxomanía “Al heredar, una clase debe introducir una característica, redeclarar una característica heredada o añadir un nuevo comportamiento”

50. Ejemplo de una Taxomanía • Gestionar los prestamos de la biblioteca de Altran El propósito de la herencia es ayudar a manejar la complejidad y no introducir complejidad al modelado. Los niveles inútiles son contraproducentes…