Proyecto Práctico de Diseño de Software 1
Ingeniería del Software IIIngeniería Informática, 4°Curso
Proyecto Práctico de Diseño de Software
Curso 2005-2006
Gonzalo Génova y Vicente Palacios
Proyecto Práctico de Diseño de Software 2
Presentación
• Profesores (despacho 2.1 B08)
– Gonzalo Génova ([email protected]) - Coordinador
– Vicente Palacios ([email protected])
– Eduardo Barra ([email protected])
– Anabel Fraga ([email protected])
– Isidro Hernanz ([email protected])
• http://www.ie.inf.uc3m.es
�Docencia, Reglada, Ingeniería del Software II
• Un curso de Análisis y Diseño en dos asignaturas:
– IS1: requisitos del usuario (captura) y requisitos del software (análisis)
– IS2: diseño arquitectónico (alto nivel) y diseño detallado (bajo nivel)
Proyecto Práctico de Diseño de Software 3
Objetivos de la asignatura
• Especificación del diseño de alto y bajo nivel de una aplicación informática
• Aprender...
– Redacción de un documento completo de diseño
– Desarrollo dirigido por modelos (MDA-MDD-MDE), evolución de USDP
– Estándares de documentación de proyectos
– Técnicas del diseño orientado a objetos para diseño arquitectónico y detallado
• Desarrollar capacidades
– Abstracción
– Resolución de problemas
– Trabajo en equipo
– Exposición de resultados propios
– Revisión de trabajos ajenos
– Aprendizaje a partir de errores propios y ajenos
Proyecto Práctico de Diseño de Software 4
Programa de la asignatura: teoría
• Tema I – Diseño arquitectónico (diseño de alto nivel)
– Unidad 1 – Introducción al diseño arquitectónico
– Unidad 2 – ¿Qué es diseño orientado a objetos?
• Examen teórico en clase sobre el artículo de Haythorn
– Unidad 3 – Estilos arquitectónicos (1)
– Unidad 4 – Estilos arquitectónicos (2)
• Tema II – Diseño detallado (diseño de bajo nivel)
– Unidad 5 – Técnicas generales, marcos y patrones de diseño
– Unidad 6 – Dependencias: generalizaciones, asociaciones y mensajes
– Unidad 7 – Patrones de diseño (1)
– Unidad 8 – Patrones de diseño (2)
Proyecto Práctico de Diseño de Software 5
Programa de la asignatura: prácticas
• Equipos de 4 alumnos, trabajo en 2+2 fases (URD/SRD + ADD/DDD)
• Actividades
– Desarrollo y documentación del proyecto: recuento de horas
– Sesiones de tutoría por equipo
– Exposiciones en público y defensa del proyecto: entrega de transparencias– Revisiones cruzadas
– Propuesta de preguntas teóricas para el examen de test
• Documentación entregada (5 documentos en total)
– Dos documentos parciales: ej. ADD-E05.doc [ADD / DDD]
• envío por correo a profesores y miembros del grupo revisor
– Dos documentos de revisión: ej. ADD-E05-R07.doc [ADD / DDD]
• envío por correo a profesores y miembros del grupo revisado
– Documento final del proyecto con revisiones: ej. IS1-E05.doc
• envío por correo a profesores
• ejemplar impreso, encuadernado en espiral, tapas duras
Proyecto Práctico de Diseño de Software 6
Descripción de la práctica
• Continuación de la práctica del Ingeniería del Software 1
• “Necesitamos algo para llevar con orden nuestra contabilidad doméstica, saber en qué nos gastamos el dinero, si vamos a necesitar ingresos extras...Por ejemplo, queremos saber en qué momento nos van a llegar las facturas al banco, y si vamos a necesitar ingresar dinero en nuestra cuenta, etc.”
• Libertad para escoger plataforma y modo de interacción con el usuario
• Extensión de los documentos (orientativa):
– ADD: 20 a 40 páginas.
– DDD: 20 a 40 páginas.
– TOTAL: 40 a 80 páginas
Calidad, no cantidad
Proyecto Práctico de Diseño de Software 7
Programa de la asignatura: calendario
• Entregas: grupos y documentos (parciales, revisiones, final)
Revisión DDD1-junRevisión DDD30-mayFinal: 5-jun
Exposición DDD25-mayExposición DDD23-mayrDDD: 29-may
Exposición DDD18-mayLibre16-mayDDD: 17-may
Tutoría DDD11-mayTutoría DDD9-may
Tutoría DDD4-mayFiesta2-may
Teoría DDD 427-abrTeoría DDD 325-abr
Teoría DDD 220-abrTeoría DDD 118-abr
Semana Santa13-abrSemana Santa11-abr
Revisión ADD6-abrRevisión ADD4-abrrADD: 3-abr
Exposición ADD30-marExposición ADD28-mar
Exposición ADD23-marLibre21-marADD: 22-mar
Tutoría ADD16-marTutoría ADD14-mar
Tutoría ADD9-marTeoría ADD 47-mar
Teoría ADD 32-marTeoría ADD 228-febGrupos: 3-mar
Teoría ADD 123-febPresentación21-febEntregas
Proyecto Práctico de Diseño de Software 8
Evaluación de la asignatura
• 70% Parte práctica de la calificación
– A. 40% Evaluación de la documentación presentada
• corrección formal (estándar) y material (contenido)
– B. 20% Evaluación de las presentaciones en público
• preparación y ejecución, respuesta a las preguntas del público
– C. 10% Evaluación de los informes de revisión
• ayuda para el grupo revisado, no influye en su calificación
• 30% Parte teórica de la calificación
– D. 10% Evaluación de la propuesta de preguntas de test (3 preguntas cada grupo)
– E. 10% Calificación del examen final de test
– F. 10% Calificación del examen teórico en clase de la Unidad 2
• Calificaciones de grupo e individuales
– 60% calificación global de grupo: A, C y D
– 40% calificación individual de cada alumno: B, E y F
Proyecto Práctico de Diseño de Software 9
Bibliografía
• Diseño arquitectónico, diseño detallado
– Eric Braude. Software Engineering. An Object-Oriented Perspective. JohnWiley & Sons, 2001.
• Capítulos 5 y 6
– Ian Sommerville. Software Engineering, 7th ed. Pearson-Addison Wesley, 2004.
• Capítulos 11-16
– ESA Board for Software Standardisation and Control (BSSC). ESA Software Engineering Standards. European Space Agency, February 1991.
• Modelado con UML
– Martin Fowler, Kendall Scott. UML Distilled. A Brief Guide to the Standard Object Modeling Language. Addison-Wesley, 2004.
– Jim Arlow, Ila Neustadt. UML and the Unified Process. Practical Object-Oriented Analysis & Design. Addison-Wesley, 2002.
– Perdita Stevens, Rob Pooley. Using UML. Software Engineering with Objectsand Components. Addison-Wesley, 2000.
– Craig Larman. Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design and the Unified Process. Prentice Hall, 1998.
Proyecto Práctico de Diseño de Software 10
Introducción al diseño arquitectónico
• La transición del análisis al diseño– modelo del entorno, modelo de análisis, modelo de diseño
– niveles de abstracción en el diseño
• Arquitectura del software– analogía con la arquitectura civil: requisitos � diseño
– madurez de la arquitectura del software
• Criterios para la selección de una arquitectura– extensibilidad
– modificabilidad
– simplicidad
– eficiencia
• ¿Cómo lograr una descomposición modular eficaz?– cohesión y acoplamiento
– diseñar para el mantenimiento
Proyecto Práctico de Diseño de Software 11
1. Análisis
“Los vehículos deben
poder viajar desde la
parte alta a 120 km/h
en línea recta y llegar
a la parte baja en no
más de 3 minutos.”
3. Arquitectura2. Clases de
Dominio
Vehículo
Camino
vehículo
Camino
4. Diseño
Detallado
Cable
Cable
Columna
Columna
Barandilla
Adaptado de E. Braude,
Software Engineering:
An Object-Oriented Perspective
Relación entre Análisis, Arquitectura y Diseño Detallado
Proyecto Práctico de Diseño de Software 12
Cohesión y acoplamiento
1
2 3 4
5 6Alta cohesión Bajo acoplamientoPuente
componente
componente
Adaptado de E. Braude,
Software Engineering: An Object-Oriented Perspective
Proyecto Práctico de Diseño de Software 13
Cómo lograr una buena descomposición modular
A B C
D E F
Mal
A D E
B C F
Bien
¿Cómo acertar de antemano? � Estilos arquitectónicos
Proyecto Práctico de Diseño de Software 14
Proyecto Práctico de Diseño de Software 15
Estilos arquitectónicos (Shaw & Garlan)
• Flujo de datos– Tuberías y filtros– Secuencial por lotes
• Componentes independientes– Sistemas cliente-servidor– Procesos paralelos – Sistemas de eventos
• Máquinas virtuales
• Repositorios– Bases de datos– Entornos de desarrollo– Editores– Sistemas hipertexto
• Arquitectura en capas– Arquitectura MVC / RUP
– Arquitectura en cuatro capas– Arquitectura en tres escalones
Proyecto Práctico de Diseño de Software 16
Arquitectura de flujo de datos: DFDs
crear
cliente
cajero
finaliza con
cliente
asignar
cliente a
cajero
informar
log de estadísticas
lista de clientes / cajeros
lista de cajeros libres cola de clientes
tiempo de llegada de clientes
tiempo medio entre
llegadas de clientes
- nº de cajeros
- velocidad media de cada cajero
- tiempo medio de llegada entre clientes
crear
banco
Adaptado de W. Haythorn,
What Is Object-Oriented Design?
Proyecto Práctico de Diseño de Software 17
Arquitectura de tuberías y filtros
filter
filter
filter
filter filter
filter
pipe
< stream
stream >
Adaptado de E. Braude,
Software Engineering: An Object-Oriented Perspective
pipe
Proyecto Práctico de Diseño de Software 18
Arquitectura cliente-servidor
Catalogue
server
Librarycatalogue
Video
server
Film clip
files
Picture
server
Digitised
photographs
Web server
Film and
photo info
Client 1 Client 2 Client 3 Client 4
Internet
Adaptado de I. Sommerville,
Software Engineering
Proyecto Práctico de Diseño de Software 19
Arquitectura de procesos paralelos
Customer:customer n
withdraw
Customer:customer n+1
Session:session k
Session:session m
deposit
create
Account:customer n+1 saving
Account:customer nchecking
create retrieve
retrieve
Adaptado de E. Braude,
Software Engineering: An Object-Oriented Perspective
Proyecto Práctico de Diseño de Software 20
Adaptado de I. Sommerville,
Software Engineering
Arquitectura de sistema de eventos
Sub-system
1
Event and messagehandler
Sub-system
2
Sub-system
3
Sub-system
4
Proyecto Práctico de Diseño de Software 21
Arquitectura de máquina virtual
260Mhz & 64MB
400Mhz & 128MB
260Mhz & 32MB
assemble {
{ 260MHz & 64MB }and{ { 400MHz & 128MB } and { 260MHz & 32MB } }
}
Adaptado de E. Braude,
Software Engineering: An Object-Oriented Perspective
Proyecto Práctico de Diseño de Software 22
Adaptado de I. Sommerville,
Software Engineering
Arquitectura de repositorio
Project
repository
Design
translatorProgram
editor
Design
editor
Code
generator
Design
analyser
Report
generator
Proyecto Práctico de Diseño de Software 23
Arquitectura en capas: modelo OSI
Presentation
Session
Transport
Network
Data link
Physical
7
6
5
4
3
2
1
Communications medium
Application
Presentation
Session
Transport
Network
Data link
Physical
Application
Network
Data link
Physical
Adaptado de I. Sommerville,
Software Engineering
Proyecto Práctico de Diseño de Software 24
Arquitectura en capas: juegos interactivos
Definición de reglas
del juego
Jugador TurnoMovimiento
Lanzamiento
de Dado
Selección
de Ficha
Avance y Captura
Ejecución de movimientos
Representación
gráfica
Adaptado de E. Braude,
Software Engineering: An Object-Oriented Perspective
Proyecto Práctico de Diseño de Software 25
Arquitectura modelo-vista-controlador
Adaptado de E. Braude,
Software Engineering: An Object-Oriented Perspective
Controlador
Modelo
Vista
Acciones del
usuario
Modificaciones en la vista
Modificaciones
en el modelo
Consultas al
modelo
C
M
V
Proyecto Práctico de Diseño de Software 26
Arquitectura en Cuatro Capas
Proyecto Práctico de Diseño de Software 27
Arquitectura en Tres Escalones
Proyecto Práctico de Diseño de Software 28
El diseño arquitectónico en el Estándar ESA
• ESA software engineering standards (PSS-05-0)
– Chapter 4. The architectural design phase
• 4.3. Actividades: modelo físico (estático y dinámico)
• Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1)
– Chapter 3. Using Object-Oriented Methods with PSS-05• 3.5. Modelo físico, reutilización, criterios de calidad del diseño
• Guide to the software architectural design phase (PSS-05-04)
– Chapter 2. The architectural design phase
• 2.3. Construcción del modelo físico (descomposición, NFR, calidad...)
• 2.4. Especificación del diseño arquitectónico (funciones – componentes)
• 2.7. Revisión de los requisitos del software
– Chapter 5. The architectural design document• 5.1. Introducción: lo que debe ser, lo que no debe ser
• 5.2. Estilo: claridad, consistencia, modificabilidad
• 5.6. Contenido
Proyecto Práctico de Diseño de Software 29
Introducción al diseño detallado
• Qué es el diseño detallado
• Diseño detallado orientado a objetos
• Dos técnicas generales de diseño
– diseño por contratos
– reutilización de componentes
• Especificación de algoritmos
– diagramas de actividad
– pseudocódigo
• Marcos de trabajo (frameworks)
– descomposición en paquetes marco y paquetes de aplicación (capas...)
– marcos generales y marcos específicos
• El diseño detallado en el Estándar ESA
Proyecto Práctico de Diseño de Software 30
Especificación de algoritmos
m4
m100
m400
no bisiesto bisiesto
[sí]
[sí]
[no]
[no]
[no]
[sí]
Bisiesto (x) =
m4(x)
AND (
(NOT m100(x)
OR
(m100(x) AND m400(x))
)
= m4(x) AND (NOT m100(x) OR m400(x))
NoBisiesto (x) =NOT m4(x) OR (m100(x) AND NOT m400(x))
Proyecto Práctico de Diseño de Software 31
Descomposición basada en marcos de trabajo
Java.awt
MiAplicación
Window
VentanaDialogo Empleado
1 ventanaEmpleado
Capa de marcos
Capa de aplicación
Proyecto Práctico de Diseño de Software 32
El diseño detallado en el Estándar ESA
• ESA software engineering standards (PSS-05-0)
– Chapter 5. The detailed design and production phase
• 5.3. Actividades: diseño detallado / no producción
– 5.3.1. Descomponer componentes arquitectónicos en módulos programables
• 5.4. Salidas: omitir código y manual de usuario
• Guide to applying the ESA SE-Std to projects using OO Methods (BSSC98-1)
– Chapter 3. Using Object-Oriented Methods with PSS-05
• 3.6. Conversión automática modelo ⇔ código (round-trip engineering)
• Guide to the software detailed design and production phase (PSS-05-05)
– Chapter 2. The detailed design and production phase• 2.3. Descomposición, diseño defensivo, optimización, etc.
– Chapter 5. The detailed design and production document• 5.1. Introducción: lo que debe ser, lo que no debe ser
• 5.2. Estilo: claridad, consistencia, modificabilidad
• 5.6. Contenido
Proyecto Práctico de Diseño de Software 33
Diseño detallado con UML
• Objetos y clases– Notación básica de objetos y clases
– Tipos de clases
– Diagramas de clases y de objetos
• Atributos– Asociación vs. Atributo
– Subclase vs. Atributo
• Operaciones– Redefinición de operaciones
– Operaciones abstractas
• Interfaces
• Visibilidad
• Invariantes
• Dependencias inducidas por otras relaciones
Proyecto Práctico de Diseño de Software 34
Objetos y clases
• Dos niveles de abstracción:
– objeto: una entidad concreta con identidad, estado y comportamiento
– clase: un conjunto de entidades con estructura y comportamiento comunes
• La relación de clasificación / instanciación
– un objeto es instancia de una clase
– la clase se usa como plantilla para construir (instanciar) objetos
• Objetos y clases en análisis y diseño:
– Análisis = especificación, vista externa, caja negra
• clases, atributos y operaciones corresponden a conceptos del dominio
• es habitual usar una notación simplificada al máximo
– Diseño = implementación, vista interna, caja blanca
• clases, atributos y operaciones corresponden a fragmentos de código
• nuevos artefactos y soluciones que dependen del lenguaje y la plataformade implementación y no tienen por qué corresponder a conceptos del dominio
Proyecto Práctico de Diseño de Software 35
Notación básica de objetos y clases
PuntoposiciónXposiciónYsituar( )
mover( )
p1 : Punto
posiciónX = 3
posiciónY = -5
p2 : Punto
posiciónX = 0
posiciónY = 2
«instance of»«instance of»
p1 : Punto
p1
: Punto
PuntoposiciónX
posiciónY
Punto
situar( )
mover( )
Punto
Proyecto Práctico de Diseño de Software 36
Tipos de clases
• Tipos de clases según los objetos representados: – objetos físicos: avión, persona, libro...
– objetos lógicos: cuenta corriente, asignatura, número complejo
– objetos históricos: asiento bancario, reserva de habitación
– objetos tipo: producto a la venta, ingrediente de una receta
• Para entender lo que es una clase, hace falta entender cuáles serán sus instancias.
• Un mismo concepto del mundo real puede ser modelado como objeto o clase según los casos:– “Pastor Alemán”
– “Lata de Atún”
– “El Lenguaje Unificado de Modelado”
• Un objeto representa una “entidad concreta”, pero esto no significa necesariamente entidad física o tangible
Proyecto Práctico de Diseño de Software 37
Diagramas de clases y de objetos
• Diagrama de clases
– captura y especifica el vocabulario del sistema:
• elementos: clases, atributos, operaciones...
• relaciones: asociaciones, generalizaciones...
• estructura del sistema, fundamento de su comportamiento– sugerencias para mejorar la comunicación:
• nombres adecuados: clases, atributos, operaciones, asociaciones, roles
• distribución espacial de los elementos
• evitar cruces de líneas
• distinto nivel de detalle según el propósito y nivel de abstracción
• Diagrama de objetos
– ilustra la estructura del sistema mediante situaciones particulares
– “fotografía” del sistema: objetos, valores de atributos; enlaces
– las instancias deben conformarse a sus especificaciones
• objetos, enlaces � clases, asociaciones
• las especificaciones pueden estar representadas en distintos diagramas
Proyecto Práctico de Diseño de Software 38
Diagrama de clases vs. Diagrama de objetos
Sociedad
Anónima Limitada
Sociedad Personaaccionista
empleado
Acme : Sociedad
Emca : Limitada
Ana : Persona
Clara : Persona
Pedro : Persona
accionista
empleado
empleado
accionista
Proyecto Práctico de Diseño de Software 39
Atributos
• Atributo: propiedad compartida por los objetos de una clase
– cada atributo tiene un valor (probablemente diferente) para cada objeto
• Atributo derivado (concepto propio del análisis):
– propiedad redundante que puede ser calculada a partir de otras
– /área ( = base * altura)
– pueden implementarse como operaciones al pasar a diseño
• Notación – pueden suprimirse todos los elementos excepto el nombre de atributo
• visibilidad nombre multiplicidad : Tipo = valorInicial {propiedades}
– propiedades predefinidas de los atributos: changeable, addOnly, frozen
– ejemplos
• saldo : Moneda = 0
• teléfonoOficina [0..2] {addOnly}
Proyecto Práctico de Diseño de Software 40
• Un atributo es equivalente a una asociación unidireccional
• Es incorrecto duplicar la representación
PuntoposiciónX: Coordenada
posiciónY: Coordenada
PuntoposiciónX: CoordenadaposiciónY: Coordenada
Coordenada
posiciónY
posiciónX
Asociación vs. Atributo
PuntoCoordenada
posiciónY
posiciónX
Proyecto Práctico de Diseño de Software 41
Diseño e implementación de asociaciones binarias
• Los lenguajes OO no proporcionan una construcción adecuada
– combinación de atributos y operaciones para gestionar los enlaces
– colecciones para manejar la multiplicidad (comprobación de tipo...)
– referencias cruzadas sincronizadas para manejar la bidireccionalidad
Hombre Mujer0..1 0..1
esposo esposa
{sincronizado}
0..1esposa
0..1
esposo
Hombre Mujer
Diagrama
de análisis
Diagrama
de diseño
Código demasiado simple:
public class Hombre {
private Mujer esposa;
…
}
public class Mujer {
private Hombre esposo;
…
}
Proyecto Práctico de Diseño de Software 42
Subclase vs. Atributo
• ¿Cómo modelar las propiedades de los objetos? Regla general:
– propiedad cambiante o rango de valores muy grande: atributo– propiedad fija con valores enumerados: especialización (cada propiedad se
traduce en un criterio de especialización, cada valor en una subclase)
• también se puede modelar como un atributo con valor fijo
• Problema de la clasificación dinámica: ¿puede un objeto cambiar de clase?
– permitiría modelar un cambio de propiedad como una reclasificación del objeto
– especialmente interesante para aprovechar el polimorfismo (cambiar de subclase)
– no es habitual en los lenguajes de programación, aunque UML lo permite
• Criterio final de especialización: comportamiento
CuentaCorrientetitularmoneda
Coche
CocheRojoCocheVerdeCocheAzul
color
Alternativa a la doble
especialización
¿Especialización
exagerada?
Proyecto Práctico de Diseño de Software 43
CuentaCorriente
CuentaPersonal CuentaSocial CuentaEuro CuentaDólar
titular {disjoint, complete} moneda {disjoint, incomplete}
Dimensiones de especialización
• Una superclase puede ser especializada en distintos grupos de subclases de acuerdo con criterios independientes: discriminadores
• Restricciones:
– disjoint/overlapping: las subclases no pueden tener instancias en común / o sí
– complete/incomplete: no hay otras subclases / o sí
• Valor por defecto: disjoint, incomplete
• Partición propiamente dicha: disjoint, complete
Proyecto Práctico de Diseño de Software 44
Generalización múltiple vs. Clasificación múltiple
CuentaCorriente
CuentaPersonal CuentaEuro
CuentaPersonalEuro
miCuenta
«instance of»
CuentaCorriente
CuentaPersonal CuentaEuro
miCuenta
«instance of» «instance of»
Proyecto Práctico de Diseño de Software 45
Operaciones
• Operación: función o transformación que puede aplicarse a los
objetos de una clase
– pueden ser invocadas por otros objetos, o por el mismo objeto
– método: especificación procedimental (implementación) de una operación
• Notación – pueden suprimirse todos los elementos excepto el nombre de operación
• visibilidad nombre (param: Tipo = valDef,…) : TipoRet {propiedades}
– propiedades predefinidas de las operaciones: isQuery
– ejemplos:
• obtenerSaldo ( ) : Moneda {isQuery}
• marcar (número : Teléfono; reintentos : Integer)
Proyecto Práctico de Diseño de Software 46
CuentaDebito
sacarDinero(cantidad)
CuentaCorrientesaldo
sacarDinero(cantidad)
sacarDinero( )
CuentaCreditocredito
sacarDinero(cantidad)
Polimorfismo de operaciones
• Capacidad de ejecutar distintas operaciones en respuesta al mismo mensaje
• Una operación polimórfica es aquélla que tiene muchas implementaciones
• No confundir sobreescritura con sobrecarga de operaciones
– sobreescribir: redefinir en otra clase el significado de la misma operación
• el método se selecciona en tiempo de ejecución– sobrecargar: reutilizar el nombre de operación, pero con distintos parámetros
• el método se selecciona en tiempo de compilación, no es polimorfismo
sobrecargasobreescritura
(polimorfismo)
Proyecto Práctico de Diseño de Software 47
Signatura de operaciones
• Define los elementos que identifican unívocamente una operación:
– nombre de operación, número (orden) y tipo de los parámetros
• Una clase no puede tener dos operaciones con la misma signatura o firma
• Los nombres de los parámetros no pertenecen a la signatura
• ¿Pertenece el tipo del valor de retorno a la signatura? Depende...
– Según el estándar de UML, sí.
– Pero el tipo del retorno no sirve para distinguir qué operación hay que ejecutar
�No se puede usar para sobreescribir o sobrecargar operaciones
p1 : Punto
posiciónX = 3
posiciónY = -5
PuntoposiciónX: CoordenadaposiciónY: CoordenadaobtenerPosición( ): CoordenadasPolaresobtenerPosición( ): CoordenadasCartesianas
c := obtenerPosición ( )¿Qué operación se invoca?
Depende del tipo de “c”...
«instance of»
Clase mal
definida
Proyecto Práctico de Diseño de Software 48
Figuraposición
dibujar( )
Rectángulobase
altura
dibujar( )
Cuadrado{base=altura}
dibujar( )
Círculoradio
dibujar( )
Clases y operaciones abstractas
• Operación abstracta: sólo se especifica la signatura, no la implementación
– una clase con una o varias operaciones abstractas está incompleta: no puede tener instancias directas
– tanto las operaciones abstractas como las concretas pueden ser sobreescritas (polimórficas)
– es más seguro sobreescribir una operación abstracta que una operación concreta (no hay peligro de cambiar su significado)
• Clase abstracta: está incompleta, no puede tener instancias directas
– puede tener instancias indirectas a través de sus subclases concretas
– una clase concreta...
• no puede tener operaciones abstractas
• debe proporcinar implementaciones para todas las operaciones abstractas heredadas
Proyecto Práctico de Diseño de Software 49
• Encapsulamiento: separación de interfaz e implementación en una clase
– una clase puede realizar una o varias interfaces
– una interfaz puede ser realizada por una o varias clases
• Interfaz: conjunto de operaciones que ofrecen un servicio coherente
– no contiene la implementación de las operaciones (métodos)
– una interfaz no puede tener atributos ni asociaciones navegables (esta restricción ha desaparecido en UML 2.0)
– análoga a una clase abstracta sin atributos ni asociaciones, y con todas sus operaciones abstractas: no puede tener instancias directas
– distinta de “interfaz natural”: conjunto de operaciones públicas de una clase (accesibles a través de cualquier asociación navegable hacia la clase)
Notaciones para uso y realización de interfaces
Documento
ImprimibleImpresora
Interfaces
Documento
«interface»Imprimible
imprimir( )
Impresora
Proyecto Práctico de Diseño de Software 50
«interface»
Figura
Círculo Rectángulo
Cuadrado
«interface»
Imprimible
Generalización vs. Realización• La realización puede entenderse como una
“generalización débil”: se hereda la interfaz, pero no la implementación:
– reduce la dependencia
– disminuye la reutilización
– alternativa a la generalización múltiple, no soportada por muchos lenguajes
• Las interfaces son elementos generalizables
– jerarquías mixtas de interfaces y clases
• Criterio de diseño: comprometerse sólo con la interfaz
– declarar el tipo de las variables y parámetros de operaciones como interfaces, no como clases
– servirá cualquier instancia compatible con la interfaz
• Ejemplo:Figura f = new Cuadrado ( );
f.imprimir
Proyecto Práctico de Diseño de Software 51
Visibilidad
• Niveles de visibilidad (diferentes en cada lenguaje):+ public: visible para todas las clases (opción por defecto para operaciones)
~ package: visible para todas las clases que estén en el mismo paquete
# protected: visible para las subclases
– private: visible sólo para la clase (opción por defecto para atributos)
Protected
Protected
PrivatePrivatePrivate
Friendfriendly
Protected-FriendProtected
Package
PublicPublicPublic
.NETJavaUML
Proyecto Práctico de Diseño de Software 52
Visibilidad privada entre objetos de la misma clase
public class Elemento {
private Elemento siguiente;
private String nombre;
private void escribir() {
System.out.println(this.nombre);
}
public void prueba() {
siguiente.escribir();
}
public Elemento(String n) {
nombre=n;
}
}
class Principal {
public static void main(String[] args) {
Elemento e1=new Elemento("e1");
Elemento e2=new Elemento("e2");
e1.siguiente=e2;
e1.prueba();
}
}
Ejecución y resultado:
C:\java Principal
e2
� El objeto e1 invoca la operación privada
escribir del objeto e2.
• La visibilidad es una propiedad de las clases, no de los objetos: un objeto puede acceder a operaciones y atributos privados de otros objetos de la misma clase
Proyecto Práctico de Diseño de Software 53
CuentaDebito
sacarDinero(cantidad)
CuentaCorrientesaldo
sacarDinero(cantidad)
sacarDinero( )
CuentaCreditocredito
sacarDinero(cantidad)
Invariantes de clases y de operaciones
• Invariantes de clase
– CuentaDebito: saldo ≥ 0
– CuentaCredito: saldo + credito ≥ 0
• Invariantes de operación
– CuentaDebito.sacarDinero(cantidad)
• Pre: saldo – cantidad ≥ 0
• Post: saldo’ = saldo - cantidad
– CuentaCredito.sacarDinero(cantidad)
• Pre: saldo + credito – cantidad ≥ 0
• Post: saldo’ = saldo - cantidad
Proyecto Práctico de Diseño de Software 54
Figura
FiguraColoreada Color1
miColor
Dependencias inducidas por otras relaciones
public class FiguraColoreada extends Figura {
private Color miColor;
public void desplazar (Vector desplazamiento) {
Posicion p = new Posicion ( );
...
}
...
}
Figura
FiguraColoreada Color
PosicionVector
generalización
asociación
variable localparámetro
(asociaciones contextuales)
Proyecto Práctico de Diseño de Software 55
Patrones de diseño
• El catálogo de patrones de diseño
• Descripción de los patrones
• Relaciones entre patrones de diseño
• Cómo resolver problemas con patrones de diseño
• Patrones de diseño
– Abstract Factory
– Decorator
– Command
Proyecto Práctico de Diseño de Software 56
El catálogo de patrones de diseño
Chain of Responsibility
CommandIterator
Mediator
Memento
Observer
State
Strategy
Visitor
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Abstract Factory
Builder
Prototype
SingletonObjeto
(Ejecución)
Interpreter
Template Method
AdapterFactory MethodClase(Compilación)
Ámbito
De ComportamientoEstructuralesDe Creación
Propósito
Proyecto Práctico de Diseño de Software 57
Descripción de los patrones
1. El nombre
2. Problema
3. Solución
4. Consecuencias
1. Nombre y clasificación
2. Propósito
3. También conocido como
4. Motivación
5. Aplicabilidad
6. Estructura
7. Participantes
8. Colaboraciones
9. Consecuencias
10.Implementación
11.Código de ejemplo
12.Usos conocidos
13.Patrones relacionados
Proyecto Práctico de Diseño de Software 58
Relaciones entre patrones de diseñoMemento
Iterator
Builder
Command
Composite
Decorator Flyweight
Visitor
Interpreter
Chain of ResponsibilityStrategy
Mediator
Observer
State
Template Method
Prototype
Singleton
Facade
Abstract Factory
Factory Methodinstancia única
instancia única
configurar fabricas dinámicas
definir los pasos de un algoritmo
cambiar la piel en vez de las tripas
Implementado usando
gestión de dependencias
complejas
suele usar
crear compuestos
añadir responsabilidades a objetoscompartir
compuestos
compartir estrategias
compartir estados
añadir operaciones
añadir operaciones
compartir símbolos
terminales
definir la gramática
guardar el estado de la
iteración
evitar la histéresis
enumerar los hijos
combinadas usando
definir la cadena
definir recorridos
Proyecto Práctico de Diseño de Software 59
Cómo resolver problemas con patrones de diseño (1)
• Encontrar los objetos apropiados
– Composite ► abstracción
– Strategy ► algoritmos
– State ► estado
• Determinar la granularidad de los objetos
– Facade ► subsistemas
– Flyweight ► granularidad fina
– Abstract Factory, Builder ► crear otros objetos
– Visitor, Commad ► petición
• Especificar las interfaces de los objetos
– Memento ► estado interno
– Decorator, Proxy ► interfaces idénticas
– Visitor ► clases de objetos visitados
Proyecto Práctico de Diseño de Software 60
Cómo resolver problemas con patrones de diseño (2)
• Especificar las implementaciones de los objetos
– Herencia de clases vs. herencia de interfaces
• Chain of Resposibility ► tipo común, diferente implementación
• Composite ► interfaz común, implementación común
• Command, Observer, State, Strategy ► clases abstractas
– Programar para interfaces y no para implementación
• Abstrac Factory, Builder, Factory Method, Prototype y Singleton ►
instancias clases concretas
• Mecanismos de reutilización
– Herencia vs. Asociación (composición de objetos)
– Delegación
• State ► peticiones en estado actual
• Strategy ► petición objeto estrategia
• Visitor ► operación objeto visitante
Proyecto Práctico de Diseño de Software 61
Cómo resolver problemas con PD: Herencia vs. Delegación
c.x( ) c.x( )
A
x( )
B
x( )
C
x( )
1
c
1
c
Dos formas de reutilizar / refactorizar
A B
C
x( )
Proyecto Práctico de Diseño de Software 62
Patrones de Diseño: Abstract Factory
Proyecto Práctico de Diseño de Software 63
Patrones de Diseño: Abstract Factory
• Suponga que se desea desarrollar una aplicación con interfaz
de usuario gráfica (GUI), que sea fácil de portar a dos sistemas operativos: Windows y Macintosh.
• Las GUI tienen una serie de objetos, generalmente conocidos
como Widgets, tales como: ScrollBar, List, Button, etc.
• Se presenta el problema de que la interfaz de usuario (look and
feel) de estos objetos es diferente en cada sistema operativo.
• La aplicación debe poder crear los objetos con la apariencia
apropiada para cada sistema operativo.
Proyecto Práctico de Diseño de Software 64
Patrones de Diseño: Abstract Factory
• Para crear un Widget se puede usar la instrucción new:
– ScrollBar sb = new WindowsScrollBar();
• Si se desea un ScrollBar para el Macintosh la operación es
diferente:
– ScrollBar sb = new MacScrollBar();
• Si se crean muchos Widgets (como suele ocurrir en aplicaciones
de cierta complejidad) será muy difícil cambiar de un "look and feel" a otro, dado que hay que modificar muchas instrucciones
que están diseminadas por diferentes partes del programa
Proyecto Práctico de Diseño de Software 65
Patrones de Diseño: Abstract Factory
• Este problema se puede solucionar con el patrón de diseño
conocido como Fábrica Abstracta.
• Una fábrica es un objeto que se encarga de crear otros objetos.
• Los elementos de este patrón son:
– Una fábrica abstracta y varias subclases que representan las fábricas
concretas
– Un producto abstracto y varias subclases que representan los productos
concretos
Proyecto Práctico de Diseño de Software 66
Patrones de Diseño: Abstract Factory
• Para la aplicación GUI se tiene:
• Una fábrica abstracta denominada GUIFactory,
• Dos fábricas concretas: WindowsFactory (crea Widgets con
apariencia “Windows”) y MacFactory (crea Widgets con
Apariencia “Macintosh”).
W indowsFactoryW indowsFactoryW indowsFactoryW indowsFactory
+ createScrollBar()
+ createButton()
+ createMenu()
MacFactoryMacFactoryMacFactoryMacFactory
+ createScrollBar()
+ createButton()
+ createMenu()
GUIFac toryGUIFac toryGUIFac toryGUIFac tory
+ createScrollBar()
+ createButton()
+ createMenu()
Proyecto Práctico de Diseño de Software 67
Patrones de Diseño: Abstract Factory
• Los productos son los Widgets.
• Se necesita una clase Widget (el producto abstracto) y varias subclases que correspondientes a los diferentes elementos de
una GUI: ScrollBar, Button, Menu, etc:
W idgetW idgetW idgetW idget
W indowsScrollBarW indowsScrollBarW indowsScrollBarW indowsScrollBar
+ scrollTo()
MacScrollBarMacScrollBarMacScrollBarMacScrollBar
+ scrollTo()
Sc rollBarSc rollBarSc rollBarSc rollBar
+ scrollTo()
ButtonButtonButtonButton
+ press()
MenuMenuMenuMenu
+ popUp()
Proyecto Práctico de Diseño de Software 68
Patrones de Diseño: Abstract Factory
• Para crear un ScrollBar en lugar de invocar la operación newdirectamente:
– ScrollBar sb = new WindowsScrollBar();
• Podemos invocar la fábrica:
– ScrollBar sb = guiFactory.createScrollBar();
• La variable guiFactory debe ser inicializada al comienzo del
programa con una de las fábricas concretas:
– GUIFactory guiFactory = new MacFactory();