1
Arquitectura software y patrones
“Una arquitectura orientada a objetos bien estructurada está llena de patrones. La calidad de un sistema orientado a objetos se mide por la atención que los diseñadores han prestado a las colaboraciones entre sus objetos.”
“Los patrones conducen a arquitecturas más pequeñas, más simples y más comprensibles”
G. Booch
2
Diseño orientado a objetos
“Diseñar software orientado a objetos es difícil pero diseñar software orientado a objetos reutilizable es más difícil todavía. Diseños generales y flexibles son muy difíciles de encontrar la primera vez”
¿Qué conoce un programador experto que desconoce uno inexperto?
Reutilizar soluciones que funcionaron en el pasado: Aprovechar la experiencia
3
Patrones
Describen un problema recurrente y una solución.
Cada patrón nombra, explica, evalúa un diseño recurrente en sistemas OO.
Elementos principales:
Nombre
Problema
Solución: Descripción abstracta
Consecuencias
4
Patrones
Patrones de código
Nivel de lenguaje de programación
Frameworks
Diseños específicos de un dominio de aplicaciones.
Patrones de diseño
Descripciones de clases cuyas instancias colaboran entre sí que deben ser adaptados para resolver problemas de diseño general en un particular contexto.
Un patrón de diseño identifica: Clases, Roles, Colaboraciones y la distribución de responsabilidades.
5
Patrones y frameworks
Un framework es una colección organizada de clases que constituyen un diseño reutilizable para una clase específica de software.
Necesario adaptarlo a una aplicación particular.
Establece la arquitectura de la aplicación
Diferencias:
Patrones son más abstractos que los frameworks
Patrones son elementos arquitecturales más pequeños
Patrones son menos especializados
6
Observer
Estructura
7
Observer
Colaboración
8
Modelo-Vista-Control
Utilizado para construir interfaces de usuario en Smalltalk-80.
Basado en tres tipos de objetos:
Modelo: objetos del dominio
Vista: objetos presentación en pantalla (interfaz de usuario)
Controlador: define la forma en que la interfaz reacciona a la entrada del usuario.
Desacopla el modelo de las vistas.
1tr
3tr
4tr
2tr
(Gp:) 1tr. 2tr. 3tr. 4tr.
Este 20 25 90 20
Oeste 30 38 32 32
Norte 47 47 45 45
Vistas
t1=20
t2=25
t3=90
t4=20
Modelo
10
Modelo-Vista-Control
Utiliza los siguientes patrones:
Observer
Composite
Strategy
Decorator
Factory method
11
Plantilla de definición
Nombre
Propósito
¿Qué hace?, ¿Cuál es su razón y propósito?, ¿Qué cuestión de diseño particular o problema aborda?
Sinónimos
Motivación
Escenario que ilustra un problema particular y cómo el patrón lo resuelve.
12
Plantilla de definición
Aplicabilidad
¿En qué situaciones puede aplicarse?, ¿Cómo las reconoces?, ejemplos de diseños que pueden mejorarse.
Estructura
Diagramas de clases que ilustran la estructura
Participantes
Clases que participan y sus responsabilidades
Colaboraciones
Diagramas de interacción que muestran cómo colaboran los participantes.
13
Plantilla de definición
Consecuencias
¿Cómo alcanza el patrón sus objetivos?, ¿Cuáles son los compromisos y resultados de usar el patrón?, Alternativas, Costes y Beneficios
Implementación
Técnicas, heurísticas y consejos para la implementación
¿Hay cuestiones dependientes del lenguaje?
Ejemplo de Código
Usos conocidos
Patrones relacionados
14
Clasificación
Ámbito
(Gp:) Propósito
(Gp:) Estructural
(Gp:) Comportamiento
(Gp:) Creación
(Gp:) Herencia
(Gp:) Compo-
sición
(Gp:) Factory Method
(Gp:) Adapter
(Gp:) Interpreter
Template Method
(Gp:) Abstract Factory
Builder
Prototype
Singleton
(Gp:) Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
(Gp:) Chain of Responsability
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
15
¿A qué ayudan los patrones?
Encontrar clases de diseño
Especificar interfaces
“Programar hacia la interfaz, no hacia la implementación”
No declarar variables de clases concretas sino abstractas.
Patrones de creación permiten que un sistema esté basado en términos de interfaces y no en implementaciones.
Favorecen la reutilización a través de la composición en vez de la herencia
16
Herencia vs. Clientela
Relación fija
Reuso “caja blanca”
Relación variable
Reuso “caja negra”
Clase abstracta
Interfaz
Página siguiente  |