Proyecto Práctico de Diseño de Software · Por ejemplo, queremos saber en ... Final: 5-jun 30-may...

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


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)


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


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)


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


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


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


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


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.


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


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


Cohesión y acoplamiento

1

2 3 4

5 6Alta cohesión Bajo acoplamientoPuente

componente

componente


Software Engineering: An Object-Oriented Perspective


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



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


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?


Arquitectura de tuberías y filtros

filter

filter

filter

filter filter

filter

pipe

< stream

stream >



pipe


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


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






Arquitectura de sistema de eventos

Sub-system

1

Event and messagehandler

Sub-system

2

Sub-system

3

Sub-system

4


Arquitectura de máquina virtual

260Mhz & 64MB

400Mhz & 128MB

260Mhz & 32MB

assemble {

{ 260MHz & 64MB }and{ { 400MHz & 128MB } and { 260MHz & 32MB } }

}






Arquitectura de repositorio

Project

repository

Design

translatorProgram

editor

Design

editor

Code

generator

Design

analyser

Report

generator


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




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




Arquitectura modelo-vista-controlador



Controlador

Modelo

Vista

Acciones del

usuario

Modificaciones en la vista

Modificaciones

en el modelo

Consultas al

modelo

C

M

V


Arquitectura en Cuatro Capas


Arquitectura en Tres Escalones


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


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


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))


Descomposición basada en marcos de trabajo

Java.awt

MiAplicación

Window

VentanaDialogo Empleado

1 ventanaEmpleado

Capa de marcos

Capa de aplicación


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


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


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


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


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


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


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


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}


• 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


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;

…

}


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?


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


Generalización múltiple vs. Clasificación múltiple

CuentaCorriente

CuentaPersonal CuentaEuro

CuentaPersonalEuro

miCuenta

«instance of»

CuentaCorriente

CuentaPersonal CuentaEuro

miCuenta

«instance of» «instance of»


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)


CuentaDebito

sacarDinero(cantidad)

CuentaCorrientesaldo


sacarDinero( )

CuentaCreditocredito


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)


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


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


• 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


«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


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


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


CuentaDebito


CuentaCorrientesaldo


sacarDinero( )

CuentaCreditocredito


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


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)


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


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


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


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


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


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


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( )


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.



• 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



• 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



• 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()



• 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()



• 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();


Patrones de Diseño: Decorator


Patrones de Diseño: Command

Proyecto Práctico de Diseño de Software · Por ejemplo, queremos saber en ... Final: 5-jun 30-may...

Documents

Transcript of Proyecto Práctico de Diseño de Software · Por ejemplo, queremos saber en ... Final: 5-jun 30-may...