semana 2 (1)
TRANSCRIPT
Apr-11 MTIAP 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
Clases y relaciones entre clases
Apr-11 MTIAP 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 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 6
Clases: Notación Gráfica
Otros ejemplos:
lista
primero()
ultimo()
añadir()
quitar()
cardinalidad()
pila
apilar()
desapilar()
cardinalidad()
Apr-11 MTIAP 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 sermanipulables directamente por el resto de objetos
Apr-11 MTIAP 8
Relaciones entre Clases
Los enlaces entre de objetos pueden representarse entrelas 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 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
Universidad Estudiante
Una asociación
Univ. de Murcia : Universidad Antonio : EstudianteUn enlace
Apr-11 MTIAP 10
Ejemplo:
… Asociación
Compañía
nombre
dirección
Persona
nombre
s.s.
0..1
*
jefe 0..1
Administra
empleado
*
0..1
0..1mujer
0..1
casado-con
marido
0..1
*
* trabaja-para
*emplea-a
*
Apr-11 MTIAP 11
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ónde existencia
… Asociación
Apr-11 MTIAP 12
La agregación representa una relación parte_deentre 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
Agregación y Composicion
Apr-11 MTIAP 13
… Ejemplos
Asociación excluyente
Clase de asociación
Agregación
Persona
Cuenta
*
*
*
*
Empresa
1
*
1
*
or
Polígono Punto1
3..*
1
3..*{ordenado}
contiene
EstaciónUsuario
** **
Autorización
prioridad
privilegios
camb_privil()
está-autorizado-en
Apr-11 MTIAP 14
... Ejemplos
Person Committee** **Member-of
1 *1 *Chair-of
{ subset }
{Person.employer =
Person.boss.employer}
Represents an
incorporated entity.
CompanyPerson
*
0..1
worker
*
boss
0..1
0..1*
employer
0..1
employee
*
Apr-11 MTIAP 15
ComposicionDenotada por rombo relleno, pertenencia obligatoria
Window
scrollbar[2] : Slider
title : Header
body : Panel
Slider Header
Window
1
2
1
2scrollbar
1
1
1
1title
Panel
1
1
1
1body
Apr-11 MTIAP 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 17
Apr-11 MTIAP 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 laspropiedades comunes de un conjunto de clases en una clase más general
Apr-11 MTIAP 19
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
... Generalización
Apr-11 MTIAP 20
... Generalización
Vehículo
Veihículo Terrestre Vehículo Aéreo
Coche Camión Avión Helicóptero
Apr-11 MTIAP 21
La especialización es una técnica muy eficaz para la extensión y reutilización
Restricciones predefinidas en UML:
– disjunta - no disjunta
– total (completa) - parcial (incompleta)
... Generalización
Funcionando Estropeado
Coche
Apr-11 MTIAP 22
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
... Generalización
Apr-11 MTIAP 23
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
... Generalización
Apr-11 MTIAP 24
Un ejemplo de Clasificación Estática:
... Generalización
Vehículo Aéreo
Avión Helicóptero
{ estática }
Apr-11 MTIAP 25
Un ejemplo de Clasificación Dinámica:
... Generalización
Funcionando Estropeado
Coche
{ dinámica }
Apr-11 MTIAP 26
Ejemplo: varias especializaciones a partir de la misma clase padre, usando discriminadores:
... Generalización
Vehículo Aéreo
Avión Helicóptero
Comercial Militar
estructura
uso
Apr-11 MTIAP 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 28
… Herencia Múltiple
Uso disciplinado de la herencia múltiple: clasificaciones disjuntas con clases padre en hojas de jerarquías alternativas
Animal
Bípedo Cuadrúpedo
Con Pelos
Con Plumas
Con Escamas
Herbívoro
Carnívoro
cubertura
cobertura
cobertura
comida
nro patas nro patas
comida
Conejo
Apr-11 MTIAP 29
Principio de Sustitución
El Principio de Sustitución de Liskow afirma que:
“Debe ser posible utilizar cualquier objetoinstancia de una subclase en el lugar decualquier objeto instancia de su superclase sinque la semántica del programa escrito en lostérminos de la superclase se vea afectado.”
Apr-11 MTIAP 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 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 32
… Polimorfismo
Ejemplo: todo animal duerme, pero cada clase lo hace de forma distinta
dormir
?
?
Animal
dormir()
León Oso Tigre
Apr-11 MTIAP 33
… Polimorfismo
Dormir(){en un árbol}
Dormir(){sobrela espalda}
Dormir(){sobre el vientre}
Dormir(){
}
Animal
dormir()
León
dormir()
Oso
dormir()
Tigre
dormir()
Apr-11 MTIAP 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
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
• 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
Apr-11 MTIAP 37