1. SEMANA 2
Diagramas de Clases
David Chaverri, PMP, MBA
dfchaverri@gmail.com

2. UML
 UML define una notación que se expresa
como diagramas sirven para representar
modelos/subsistemas o partes de ellos
 El 80 por ciento de la mayoría de los
problemas pueden modelarse usando
alrededor del 20 por ciento de UML-- Grady
Booch
Apr-11 MTIAP 2

3. Clases y relaciones
entre clases

4. Clases
 La clase define el ámbito de definición de
un conjunto de objetos
 Cada objeto pertenece a una clase
 Los objetos se crean por instanciación de
las clases
Apr-11 MTIAP 4

5. Clases: Notación Gráfica
 Cada clase se representa en un rectángulo con tres
compartimientos:
– nombre de la clase
– atributos de la clase
– operaciones de la clase
Motocicleta
color
cilindrada
velocidad máxima
arrancar()
acelerar()
frenar()
Apr-11 MTIAP 5

6. Clases: Notación Gráfica
 Otros ejemplos:
lista
pila
primero()
apilar()
ultimo()
desapilar()
añadir()
cardinalidad()
quitar()
cardinalidad()
Apr-11 MTIAP 6

7. Clases: Encapsulación
 La encapsulación presenta dos ventajas básicas:
– Se protegen los datos de accesos indebidos
– El acoplamiento entre las clases se disminuye
– Favorece la modularidad y el mantenimiento
 Los atributos de una clase no deberían ser
manipulables directamente por el resto de
objetos
Apr-11 MTIAP 7

8. Relaciones entre Clases
 Los enlaces entre de objetos pueden representarse entre
las respectivas clases
 Formas de relación entre clases:
– Asociación
– Agregación y Composicion
– Generalización/Especialización
 Las relaciones de Agregación y Generalización forman
jerarquías de clases
Apr-11 MTIAP 8

9. Asociación
 La asociación expresa una conexión bidireccional
entre objetos
 Una asociación es una abstracción de la relación
existente en los enlaces entre los objetos
Univ. de Murcia : Universidad Un enlace Antonio : Estudiante
Universidad Estudiante
Una asociación
Apr-11 MTIAP 9

10. … Asociación
 Ejemplo:
marido
casado-con
0..1
mujer
0..1 Persona Compañía
nombre * trabaja-para nombre
s.s. dirección
emplea-a *
jefe 0..1
*
Administra
empleado
Apr-11 MTIAP 10

11. … Asociación
 Especificación de multiplicidad (mínima...máxima)
1 Uno y sólo uno
0..1 Cero o uno
M..N Desde M hasta N (enteros naturales)
* Cero o muchos
0..* Cero o muchos
1..* Uno o muchos (al menos uno)
 La multiplicidad mínima >= 1 establece una restricción
de existencia
Apr-11 MTIAP 11

12. Agregación y Composicion
 La agregación representa una relación parte_de
entre objetos
 En UML se proporciona una escasa caracterización
de la agregación
 Puede ser caracterizada con precisión
determinando las relaciones de comportamiento y
estructura que existen entre el objeto agregado y
cada uno de sus objetos componentes
Apr-11 MTIAP 12

13. … Ejemplos
Agregación
Polígono 1 contiene Punto
3..*
{ordenado}
Persona
*
*
Cuenta
or Asociación excluyente
* Empresa
1
Usuario está-autorizado-en Estación
* *
Autorización
Clase de asociación prioridad
privilegios
camb_privil()
Apr-11 MTIAP 13

14. ... Ejemplos
Member-of * Committee
Person *
{ subset }
1 Chair-of *
Represents an
incorporated entity.
worker Person employee employer Company
0..1
* *
0..1
boss
{Person.employer =
Person.boss.employer}
Apr-11 MTIAP 14

15. Composicion
Denotada por rombo relleno, pertenencia obligatoria
Window
scrollbar[2] : Slider
title : Header
body : Panel
Window
1 1
1
scrollbar
2 title 1 body 1
Slider Header Panel
Apr-11 MTIAP 15

16. Clases y Objetos
 Diagrama de Clases y Diagramas de Objetos
pertenecen a dos vistas complementarias del
modelo
 Un Diagrama de Clases muestra la abstracción de
una parte del dominio
 Un Diagrama de Objetos representa una situación
concreta del dominio
 Las clases abstractas no son instanciadas
Apr-11 MTIAP 16

17. Apr-11 MTIAP 17

18. Generalización
 Permite gestionar la complejidad mediante un
ordenamiento taxonómico de clases
 Se obtiene usando los mecanismos de abstracción
de Generalización y/o Especialización
 La Generalización consiste en factorizar las
propiedades comunes de un conjunto de clases
en una clase más general
Apr-11 MTIAP 18

19. ... Generalización
 Nombres usados: clase padre - clase hija. Otros
nombres: superclase - subclase, clase base -
clase derivada
 Las subclases heredan propiedades de sus
clases padre, es decir, atributos y operaciones (y
asociaciones) de la clase padre están disponibles
en sus clases hijas
Apr-11 MTIAP 19

20. ... Generalización
Vehículo
Veihículo Terrestre Vehículo Aéreo
Coche Camión Avión Helicóptero
Apr-11 MTIAP 20

21. ... Generalización
 La especialización es una técnica muy eficaz para la extensión y
reutilización
Coche
Funcionando Estropeado
 Restricciones predefinidas en UML:
– disjunta - no disjunta
– total (completa) - parcial (incompleta)
Apr-11 MTIAP 21

22. ... Generalización
 La noción de clase está próxima a la de conjunto
 Dada una clase, podemos ver el conjunto
relativo a las instancias que posee o bien
relativo a las propiedades de la clase
 Generalización y especialización expresan
relaciones de inclusión entre conjuntos
Apr-11 MTIAP 22

23. ... Generalización
 Particionamiento del espacio de objetos =>
Clasificación Estática
 Particionamiento del espacio de estados de los
objetos => Clasificación Dinámica
 En ambos casos se recomienda considerar
generalizaciones/especializaciones disjuntas
Apr-11 MTIAP 23

24. ... Generalización
 Un ejemplo de Clasificación Estática:
Vehículo Aéreo
{ estática }
Avión Helicóptero
Apr-11 MTIAP 24

25. ... Generalización
 Un ejemplo de Clasificación Dinámica:
Coche
{ dinámica }
Funcionando Estropeado
Apr-11 MTIAP 25

26. ... Generalización
 Ejemplo: varias especializaciones a partir de la
misma clase padre, usando discriminadores:
Comercial Militar
uso
Vehículo Aéreo
estructura
Avión Helicóptero
Apr-11 MTIAP 26

27. Clasificación Múltiple
(herencia múltiple)
 Se presenta cuando una subclase tiene más de
una superclase
 La herencia múltiple debe manejarse con
precaución. Algunos problemas son el conflicto
de nombre y el conflicto de precedencia
 Se recomienda un uso restringido y disciplinado
de la herencia. Java y Ada 95 simplemente no
ofrecen herencia múltiple
Apr-11 MTIAP 27

28. … Herencia Múltiple
 Uso disciplinado de la herencia múltiple: clasificaciones
disjuntas con clases padre en hojas de jerarquías
alternativas
Bípedo Cuadrúpedo
nro patas nro patas
Con Pelos Herbívoro
cubertura comida
Animal
Con Plumas cobertura
comida
cobertura Carnívoro
Con Escamas
Conejo
Apr-11 MTIAP 28

29. Principio de Sustitución
 El Principio de Sustitución de Liskow afirma que:
“Debe ser posible utilizar cualquier objeto
instancia de una subclase en el lugar de
cualquier objeto instancia de su superclase sin
que la semántica del programa escrito en los
términos de la superclase se vea afectado.”
Apr-11 MTIAP 29

30. … Principio de Sustitución
 Dado que los programadores pueden introducir
código en las subclases redefiniendo las
operaciones, es posible introducir involuntaria-
mente incoherencias que violen el principio de
sustitución
 El polimorfismo que veremos a continuación no
debería implementarse sin este principio
Apr-11 MTIAP 30

31. Polimorfismo
 El término polimorfismo se refiere a que una
característica de una clase puede tomar varias
formas
 El polimorfismo representa en nuestro caso la
posibilidad de desencadenar operaciones
distintas en respuesta a un mismo mensaje
 Cada subclase hereda las operaciones pero tiene
la posibilidad de modificar localmente el
comportamiento de estas operaciones
Apr-11 MTIAP 31

32. … Polimorfismo
 Ejemplo: todo animal duerme, pero cada clase lo
hace de forma distinta
Animal
dormir()
?
dormir
?
León Oso Tigre
Apr-11 MTIAP 32

33. … Polimorfismo
Animal Dormir()
{
dormir()
}
León Oso Tigre
dormir() dormir() dormir()
Dormir() Dormir() Dormir()
{ { {
sobre el vientre sobrela espalda en un árbol
} } }
Apr-11 MTIAP 33

34. … Polimorfismo
 La búsqueda automática del código que
en cada momento se va a ejecutar es
fruto del enlace dinámico
 El cumplimiento del Principio de
Sustitución permite obtener un
comportamiento y diseño coherente
Apr-11 MTIAP 34

35. Class Diagram for ATM
• The basic structure of the class diagram arises from the responsibilities and
relationships discovered when doing the CRC cards and Interaction
Diagrams. (If a class uses another class as a collaborator, or sends a
message to an object of that class during an Interaction, then there must
either be an association linking objects of those classes, or linking the
"sending" class to an object which provides access to an object of the
"receiving" class.)
• In the case of the ATM system, one of the responsibilities of the ATM is to
provide access to its component parts for Session and Transaction objects;
thus, Session and Transaction have associations to ATM, which in turn has
associations to the classes representing the individual component parts.
(Explicit "uses" links between Session and Transaction, on the one hand,
and the component parts of the ATM, on the other hand, have been
omitted from the diagram to avoid making it excessively cluttered.)
Apr-11 MTIAP 35

36. • An initial reading of the use cases suggests that the following will be part of the system.
– A controller object representing the ATM itself (managing the boundary objects listed
below.)
– Boundary objects representing the individual component parts of the ATM:
• Operator panel.
• Card reader.
• Customer console, consisting of a display and keyboard.
• Network connection to the bank.
• Cash dispenser.
• Envelope acceptor.
• Receipt printer.
• Controller objects corresponding to use cases. (Note: class ATM can handle the Startup
and Shutdown use cases itself, so these do not give rise to separate objects here.)
– Session
– Transaction (abstract generalization, responsible for common features, with concrete
specializations responsible for type-specific portions)
• An entity object representing the information encoded on the ATM card inserted by
customer.
• An entity object representing the log of transactions maintained by the machine.
• OO design is not a "waterfall" process - discoveries made when doing detailed design and
coding can impact overall system design.
Apr-11 MTIAP 36

37. Apr-11 MTIAP 37