Patrones diseño de software

Introducción
Análisis y diseño con patrones
Patrones de Diseño y Calidad del Software

Desarrollo Utilizando Patrones Software
M.I. Capel
ETS Ingenierías Informática
y Telecommunicación
Universidad de Granada
Email: manuelcapel@ugr.es

Desarrollo de Software
Ingeniería de Software (3er curso de Grado)

M.I.Capel

Tema 1

Introducción

Índice

1

Introducción
Tipos de patrones de diseño
Resolución de problemas de diseño utilizando patrones
Utilización de los patrones de diseño con UML
Patrones Arquitectónicos
Patrones a Nivel de Componentes

2


M.I.Capel

Tema 1

Introducción


Conceptos básicos y motivación
Un patrón permite capturar el conocimiento más
importante acerca del diseño de la solución a un
problema, que permite su posterior reutilización
1
2
3

Se aplica en un contexto
Resuelve un problema
Generan indirectamente la solución

La idea de patrón procede de la Arquitectura:
Chistopher Alexander (Buildings Architect)
Each pattern describes a problem that occurs over and over again
in our environment and then describes the core of the solution to
that problem in such a way that you can use the solution a million
times over without ever doing it the same way twice
M.I.Capel

Tema 1

Introducción


Marcos de trabajo

Para desarrollar un diseño completo de un sistema
complejo hay que proporcionar una infraestructura
parecida a un esqueleto de la implementación del sistema
Los marcos de trabajo no son patrones de diseño:
Los patrones de diseño son más abstractos que los marcos
de trabajo
Los patrones de diseño son elementos arquitectónicos más
pequeños que los marcos de trabajo
Los patrones de diseño son más especializados que los
marcos de trabajo

M.I.Capel

Tema 1

Introducción


Deﬁnition (Framework)
“Reusable minimum architecture that provides the generic
structure and behaviour for a family of software abstractions,
along with a context . . . that speciﬁes their collaboration and
their use within a given domain"

M.I.Capel

Tema 1

Introducción


Caracterización

Los marcos de trabajo se suelen aplicar sin cambios
Proporcionan una estructura de clases para adaptar
Son generalmente mucho más grandes
arquitectónicamente que los patrones
Son más concretos que los patrones

M.I.Capel

Tema 1

Introducción


Caracterización II

Un patrón de diseño es mucho más que un diagrama de
clases en UML
Son más abstractos que los marcos de trabajo
Los patrones capturan las abstracciones del espacio del
problema que son relevantes para encontrar una solución
Una “metodología de diseño orientada" a objetos ayuda a
obtener una descomposición del sistema

M.I.Capel

Tema 1

Introducción


Clasificación basada en su funcionalidad

Patrones arquitectónicos: intentan reflejar la estructura de
los problemas que resuelven
Patrones de datos: relacionados con la organización de la
información en aplicaciones
Patrones de Diseño Orientado a Objetos:descomposición,
intercomunicación y ubicación de los componentes de un
sistema dentro de una jerarquía de clasificación
Patrones de diseño de interfaces
Patrones para aplicaciones Web

M.I.Capel

Tema 1

Introducción


Patrones de Diseño Orientado a Objetos

Patrones Creacionales: instanciación de objetos
reforzando las restricciones en el tipo y número de objetos
Patrones Estructurales: organización en integración de
clases de objetos dentro de grandes estructuras de
información
Patrones Comportamentales: asignación de
responsabilidades y comunicación entre los objetos

M.I.Capel

Tema 1

Introducción


Ámbito de los patrones actuales

Segundo criterio de clasiﬁcación de los patrones de diseño
Las relaciones entre clases y subclases es estática
Los patrones que se reﬁeren a objetos tratan de relaciones
dinámicas
Patrones creacionales de clases vs. de objetos
Patrones comportamentales de clases vs. de objetos

M.I.Capel

Tema 1

Introducción


Tipos de metodologías de diseño orientadas a objetos

Enfocadas hacia la subclasiﬁcación
Enfocadas hacia las colaboraciones y responsabilidades
en el sistema objetivo
Enfocada hacia el modelado
Los enfoques anteriores son complementarios

M.I.Capel

Tema 1

Introducción


Aspectos generales comunes

Los patrones de diseño ayudan a determinar
qué es un objeto y hasta donde descomponerlos en
objetos más simples (granularidad)
Determinación de la jerarquía y tipos de clases de objetos
Determinación de la interfaces
Diferencias entre el mecanismo de herencia de las clases
y de las interfaces
Deﬁnition (Principio de diseño)
“Program to an interface not to an implementation"

M.I.Capel

Tema 1

Introducción


Descripción de un patrón
Contexto

Problema
Fuerzas

Solución
Intención
Anti-patrones
Patrones relacionados
Referencias

Plantilla
describe el entorno en el que se
ubica el problema incluyendo el
dominio de aplicación
una o dos frases que explican lo que
se pretende resolver
lista el sistema de fuerzas que afectan a la
manera en que ha de resolverse el problema
incluye las limitaciones y restricciones
que han de respetarse
proporciona una descripción detallada
de la solución propuesta para el problema
describe el patrón y lo que hace
“soluciones" que no funcionan en el contexto
o que son peores; suelen ser errores
cometidos por principiantes
referencias cruzadas relacionadas
con los patrones de diseño
reconocimientos a aquellos desarrolladores
que desarrollaron o inspiraron el patrón que se propone
M.I.Capel

Tema 1

Introducción


Lenguajes de patrones
Modelo de Requisitos
Describe el conjunto del problema.
Establece el contexto e identiﬁca
los intereses que dominan en la
búsqueda de un patrón.
Se trata de una colección de patrones de diseño que
colaboran para resolver los problemas dentro de un
dominio de aplicaciones
Se ha de deﬁnir una arquitectura software o un marco de
trabajo
Hasta llegar al nivel de patrones de diseño que implican
clases y componentes relacionados
M.I.Capel

Tema 1

Introducción


Diseño basado en patrones dentro de un contexto

Principios Generales de Diseño
I

II
III

IV
V

Descubrir el contexto del problema a partir del modelo de
requerimientos
Extraer los patrones del nivel actual de abstracción
Escoger un esqueleto de implementación que reﬂeje el
contexto
Trabajar siempre hacia dentro del contexto
Reﬁnar el prototipo adaptándolo a las características del
software

M.I.Capel

Tema 1

Introducción


Catálogos de Patrones de Diseño
Existen varios catálogos actualmente:
El denominado "The Gang of Four":
Gamma–Helm–Johnson-Vlissides [Gamma et al., 1995]

Pero no es el único:Coad–North–
Mayﬁeld, [Bass et al., 2012], [Booch, 2008],
Buschmann [Buschmann et al., 1995],
Lethbridge [Lethbridge and Laganiere, 2005], etc.
GoF y “Code Complete" (Steve McConnell, Microsoft) son
los catálogos de patrones de diseño de referencia
M.I.Capel

Tema 1

Introducción


Tareas de diseño

Desarrollar una jerarquía de entidades de análisis del
problema [Bruegge and Dutoit, 2013]
Determinar existencia de un lenguaje de patrones aplicable
Determinación de patrones arquitectónicos candidatos
Utilizar las colaboraciones entre patrones de más bajo nivel
Buscar los patrones de diseño de interfaces adecuados
Independientemente del nivel de abstracción, compararlo con
otras soluciones pre-existentes

M.I.Capel

Tema 1

Introducción


Abstracción–caso

Contexto
Problema
Fuerzas
Solución
Ejemplos
Anti–patrones
Patrones Relacionados
Referencias

M.I.Capel

Tema 1

Introducción


Abstracción–caso-2

Titulo
Nombre
Autor
ISBN
fechaPublicacion
bibliotecaNacional

Ejemplar
materializacionnumeroCodigodeBarras

1..*

Plantilla–ejemplo para el patrón Abstracción-caso

M.I.Capel

Tema 1

Introducción


Ejemplar

Titulo
Nombre
Autor
ISBN
fechaPublicacion
bibliotecaNacional

Titulo
Autor
ISBN
fechaPublicacion
bibliotecaNacional
numeroCodigoBarras

Viajes Gulliver

Mobby Dick

Ejemplar
numeroCodigoBarras

Forma inapropiada de representar abstracciones y casos

M.I.Capel

Tema 1

Introducción



El catálogo GoF propone los patrones: Prototype y
Flyweight que pueden considerarse como relacionados
con Abstracción–Caso
El patrón de diseño Prototype: especiﬁca la tipología de
los objetos a crear utilizando una clase de prototipo
Los nuevos objetos se crean copiando el prototipo
El patrón de diseño Flyweight utiliza compartición del
estado intrínseco de objetos de granularidad ﬁna para
evitar creación masiva de estos objetos en una aplicación

M.I.Capel

Tema 1

Introducción


Actor–Papel

Contexto
Problema
Fuerzas
Solución
Ejemplos
Anti–patrones
Referencias

M.I.Capel

Tema 1

Introducción

interpreta

Actor


RolAbstracto

1..*

Rol-2

Rol-1

Plantilla del patrón Actor–Papel

M.I.Capel

Tema 1

Introducción

SituacionAcademica

TiempoParcial

asiste
1


Alumno

DedicacionCompleta

acredita
1

Graduado

Ejemplo del patrón Actor–Papel

M.I.Capel

Tema 1

NivelEstudios

PreGraduado

Introducción


Adaptador

Contexto
Problema
Fuerzas
Solución
Ejemplos
Anti–patrones
Referencias

M.I.Capel

Tema 1

Introducción


Superclase
metodoPolimorﬁco()
Nota
metodoPolimorﬁco()()
{
return
adaptado.metodoAdaptado();
}

Adaptador

Adaptado
1

metodoAdaptado()

Plantilla del patrón de diseño Adaptador

M.I.Capel

Tema 1

Introducción


Figura3D
volumen()
Toro
volumen()
{
return
toroPrev.calcVolumen();
}

Toro

Esfera

ToroPrev
1

Ejemplo con el patrón de diseño Adaptador

M.I.Capel

Tema 1

calcVolumen()

Introducción


Composite

Se trata de un patrón de diseño para el particionamiento
Mediante este patrón, un grupo de objetos es tratado de la
misma forma que un solo objeto
“Componer" objetos en estructuras en forma de árbol
abstracto para representar jerarquías todo–parte
Con este tipo de representación las aplicaciones–cliente
pueden procesar de manera uniforme los objetos
individuales y las composiciones de objetos

M.I.Capel

Tema 1

Introducción

Client


Component
Operation()
Add(Component)
Remove(Component)
GetChild(int)
children
Leaf

Composite

Operation()

Operation()
Add(Component)
Remove(Component)
GetChild(int)

Diagrama de clases del patrón Composite

M.I.Capel

Tema 1

Introducción


¿Cuándo utilizar el patrón “Composite"?

Es necesario componer objetos para formar árboles que
representen jerarquías
Hay que representar (abstractamente) objetos primitivos
(leaf) y sus contenedores
Los contenedores pueden ser agregados de otros
contenedores o de objetos
Hay operaciones del contenedor que aplican a todos los
descendientes (children)

M.I.Capel

Tema 1

Introducción


¿Para qué utilizar el patrón “Composite"

Para conseguir que los clientes ignoren la diferencia entre
objetos individuales y agregaciones de objetos
(Composite)
Para que los clientes traten a todos los objetos de una
agregación de manera uniforme
Para hacer más fácil la inclusión de nuevos componentes
Para hacer el diseño más general

M.I.Capel

Tema 1

Introducción


Componente

contiene
*

Contenedor

Panel

Etiqueta

Boton

Ventana

Ejemplo utilización patrón Composite

M.I.Capel

Tema 1

Lista

Introducción


Delegación

Contexto
Problema
Fuerzas
Solución
Ejemplos
Anti–patrones
Referencias

M.I.Capel

Tema 1

Introducción


Delegante
Nota
metodoDelegador()
{
delegado.metodo();
}

metodoDelegador()

Delegado
1

Plantilla del patrón Delegación

M.I.Capel

Tema 1

metodo()

Introducción


Pila

ListaEnlazada

push()
pop()
estaVacia()

Nota
push()
{

1

lista.insertaPrimero();
}

insertaPrimero()
insertaUltimo()
insertaDetras()
eliminaPrimero()
eliminaUltimo()
elimina()
estaVacia()

Ejemplo del patrón de diseño Delegación

M.I.Capel

Tema 1

Introducción


Fachada

Contexto
Problema
Fuerzas
Solución
Ejemplos
Anti–patrones
Referencias

M.I.Capel

Tema 1

Introducción


PackageClase1
1
Fachada

*

1
1

PackageClase2
*
*

Nota
Contiene un subconjunto de
métodos públicos tal que
los otros subsistemas no
tendrán que acceder a las
clases dentro de los paquetes

Plantilla del patrón Fachada

M.I.Capel

Tema 1

PackageClase3

Introducción


VueloRegular
1

LineaAerea

*
Pasajero

1

encuentraVuelo()
hacerReserva()
eliminarReserva()

*

Ejemplo con el patrón de diseño Fachada

M.I.Capel

Tema 1

Introducción


Factoría Abstracta
Definition (Intención del Patrón)
Proporcionar una interfaz para crear familias de objetos
relacionados sin tener que especificar las clases a las que
pertenecen.
Definition
Queremos ofrecer una biblioteca de clases de productos pero
revelar sólo sus interfaces, no sus implementaciones
Definition
Queremos imponer que una familia de productos relacionados
sean utilizados conjuntamente por las aplicaciones
M.I.Capel

Tema 1

Introducción


Factoría Abstracta 2

Contexto
Problema
Fuerzas
Solución
Ejemplos
Anti–patrones
Referencias

M.I.Capel

Tema 1

Introducción


Plantilla del patrón Factoria Abstracta

DemandanteCreacion

<<interface>>
Factoria
1
crearInstancia()

*
ClaseGenerica

ClaseEspeciﬁcaApl

FactoriaEspeciﬁcaApl

crear

M.I.Capel

Tema 1

Introducción


Factoría Abstracta
Factoría: declara una interfaz para las operaciones de
creación de productos abstractos
Factoría Especíﬁca de la Aplicación: programan las
operaciones para crearse objetos–producto concretos
Clase Genérica: declara una interfaz para un tipo concreto
de objetos–producto
Clase Especíﬁca de la Aplicación: programa el
objeto–producto que va a ser creado por la factoría
correspondiente; implementa la interfaz en clase genérica
Demandante Creación: sólo usa las interfaces declaradas
en ClaseGenerica y Factoria

M.I.Capel

Tema 1

Introducción


¿Cuándo utilizar “Flyweight"
Han de darse todas las condiciones siguientes
La aplicación utiliza un número grande de objetos (baja
granularidad)
Altos costes de almacenamiento debido a la cantidad de
objetos
La mayoría del estado de un objeto se puede convertir en
extrínseco
Después de encapsular el estado extrínseco, muchos
grupos de objetos pueden ser reemplazados por un
número relativamente pequeño de objetos compartidos
No se depende de la identidad de los objetos

M.I.Capel

Tema 1

Introducción

FactoriaFlyweight


Flyweight

ﬂyweights

Operacion(estadoExtrinseco)

FlyweightConcreto

FlyweightConcretoNoCompartido

estadoIntrinseco

todosEstados

Cliente

Ejemplo del patrón Flyweight

M.I.Capel

Tema 1

Introducción


¿Para qué utilizar el patrón “Flyweight"

Para ahorrar espacio: mayor cuanto más estado intrínseco
de los objetos se pueda compartir
Para negociar el espacio del estado extrínseco por tiempo
de cómputo (si se puede calcular el estado)
Para representar estructuras jerárquicas combinado con el
patrón Composite
Pero, los nodos–hojas representados por “ﬂyweights" no
pueden contener un puntero a su nodo superior

M.I.Capel

Tema 1

Introducción


ElementoEscritura
Dibujar(Contexto)
Intersectar(Punto,Contexto)
descend

Fila
Dibujar(Contexto)

descend

Caracter
char c
Dibujar(Contexto)

Columna

Dibujar(Contexto)

Ejemplo de aplicación susceptible de utilizar “ﬂyweights"

M.I.Capel

Tema 1

Introducción


Inmutable

Contexto
Problema
Fuerzas
Solución
Ejemplos
Anti–patrones
Referencias

M.I.Capel

Tema 1

Introducción


Interfaz Sólo–Lectura

Contexto
Problema
Fuerzas
Solución
Ejemplos
Anti–patrones
Referencias

M.I.Capel

Tema 1

Introducción


ClaseSinPrivilegio
<<interface>>
SoloLectura

*

*

consigueAtributo()

Mutante
Mutable

*

*

private
consigueAtributo()
ﬁjaAtributo()

Plantilla del patrón de diseño Interfaz Sólo–Lectura

M.I.Capel

Tema 1

Introducción


Método Factoría

Se trata de programar un Constructor Virtual incluido en
un marco de trabajo
El patrón Metodo Factoria deja la responsabilidad de crear
los objetos a las subclases del marco de trabajo
El metodoFactoría está incluido en una clase abstracta
El conocimiento necesario para crear los objetos que se
precisa está encapsulado fuera del marco de trabajo

M.I.Capel

Tema 1

Introducción


Creador

<<interface>>
Producto

metodoFactoria()
unaOperacion()

ProductoConcreto

CreadorConcreto
metodoFactoria()
Plantilla del patrón Método Factoría

M.I.Capel

Tema 1

Nota
...
{
producto= metodoFactoria();
}

Nota
...
{
return new ProductoConcreto();
}

Introducción


Una vez que se ha instanciado CreadorConcreto, puede
crear ya el producto concreto sin tener que conocer qué
clase de producto va a crear
Existirá otra jerarquía de clases “helper" que contienen el
conocimiento para crear los productos concretos

M.I.Capel

Tema 1

Introducción


Observador

Contexto
Problema
Fuerzas
Solución
Ejemplos
Anti–patrones
Referencias

M.I.Capel

Tema 1

Introducción

Observable
incluirObervador()
notiﬁcarObservadores()


*
*

ObservableConcreto

<<interface>>
Observador
actualizar()

ObservadorConcreto

Plantilla de patrón de diseño Observador

M.I.Capel

Tema 1

Introducción


Observable

*
*

Pronosticador

<<interface>>
Observador

MonitorTiempo

Los obervadores son notiﬁcados cuando cambia el tiempo

Ejemplo con el patrón Observador

M.I.Capel

Tema 1

Introducción


Cuándo utilizar “Prototype"

Un sistema ha de ser independiente de cómo se crean,
componen y representan sus productos
Los objetos se crean en tiempo de ejecución, después de
cargar dinámicamente las clases en la aplicación
Evitando la redundancia de crear una jerarquía de clases
de factorías que se empareje con la jerarquía de productos
Resulta más práctico clonar que instanciar una clase para
crear objetos en las aplicaciones

M.I.Capel

Tema 1

Introducción

Cliente
Operacion()

prototipo

1

1..*


Prototype
Clonar()

PrototipoConcreto1

PrototipoConcreto2

Clonar()

Clonar()

Diagrama de clases del patrón Prototype

M.I.Capel

Tema 1

Introducción


Para qué utilizar “Prototype"

Para añadir y eliminar productos en tiempo de ejecución
Para definir nuevos objetos sólo cambiando valores
Clonar un prototipo es como instanciar una clase, sólo que
con este patrón se puede ver bastante reducido el número
de clases que necesita un sistema
Para definir nuevos objetos sólo variando la estructura
Para reducir la subclasificación
Para configurar dinámicamente una aplicación con clases

M.I.Capel

Tema 1

Introducción


Proxy

Contexto
Problema
Fuerzas
Solución
Ejemplos
Anti–patrones
Referencias

M.I.Capel

Tema 1

Introducción


<<interface>>
ClassIF

Cliente

*

Proxy

*

ClasePesada
0..1
0..1

Plantilla del patrón de diseño Proxy

M.I.Capel

Tema 1

Introducción


“Singleton"

Contexto
Problema
Fuerzas
Solución
Ejemplos
Anti–patrones
Referencias

M.I.Capel

Tema 1

Introducción


Visitante

Para representar a una operación que ha de ser realizada
sobre los elementos de una estructura de objetos
Las aplicaciones crearán objetos VisitanteConcreto y
después atraviesan la estructura de objetos
Al ser visitados los objetos, el visitante llamará al método
adecuado para cada objeto
Se ha de evitar cambiar las clases de los elementos sobre
los que opera

M.I.Capel

Tema 1

Introducción


Cliente

Visitante

VisitanteConcreto1

VisitanteConcreto2

visitarElemConcretoA(...)
visitarElemConcretoB(...)

visitarElemConcretoA(...)
visitarElemConcretoB(...)
Elemento

Estructura

aceptar(Visitante)

ElemConcretoA

ElemConcretoB

aceptar(Visitante v)
operacionA()

aceptar(Visitante v)
operacionB()

M.I.Capel

Tema 1

Introducción


Visitante 2

Los VisitanteConcreto programan cada operación
declarada en Visitante, proporcionan el contexto para
ejecutar la operación y almacenan su estado durante el
recorrido de la estructura
Los objetos del tipo Elemento deﬁnen una operación
aceptar() a la que se le pasa un VisitanteConcreto como
argumento
A la operación visitar() hay que pasarle la referencia del
elemento que envía la petición a un VisitanteConcreto

M.I.Capel

Tema 1

Introducción


Características de estos patrones
Una clasificación [Booch, 2008] atendiendo a características para cumplir con los requisitos de seguridad,
rendimiento, despliegue y almacenamiento
Control de accesos: el acceso a determinadas partes de la
arquitectura software ha de ser controlado rigurosamente.
Concurrencia: diferentes formas de permitir que los
componentes de la aplicación sean concurrentes.
Distribución: la comunicación entre entidades software es
muy diversa y afecta al diseño, la ubicación de los
componentes ha de ser optimizable (configurabilidad).
Persistencia: la supervivencia de los objetos (atributos y
estado) entre distintas ejecuciones es algo diseñable. Una
mala solución puede dañar la eficiencia gravemente
M.I.Capel

Tema 1

Introducción


Categorías
Whole UI ⇒ TopLevelNavigation
Page Layout ⇒ CardStack
Forms and Input ⇒ Fill-in-the-blanks
Tables ⇒ SortableTable
Direct Data Manipulation ⇒ BreadCrumbs
Navigation ⇒ EditInPlace
Searching ⇒ SimpleSearch
Page Elements ⇒ Wizard
E–Commerce ⇒ ShoppingCart
Miscellaneous ⇒ ProgressIndicator

M.I.Capel

Tema 1

Introducción


Patrones de Diseño WebbApp
Dimensiones a considerar para resolver los problemas de diseño
(a) Enfoque con el que diseñamos el patrón
(b) Nivel de granularidad de lo que estamos diseñando
Enfoque de diseño
Patrones de la Arquitectura de Información: estructura de
la información y formas de acceso
Patrones de navegación: estructuras de enlaces
Patrones de interacción: cómo desarrollar interfaces
basándose en el contexto e informando de las
consecuencias
Patrones de presentación: organización interna de
funciones de control para conseguir usabilidad
Patrones funcionales: ﬂujos y algorítmica

M.I.Capel

Tema 1

Introducción


Granularidad del diseño
El nivel de abstracción distinto según el tamaño del
elemento (aplicación, página, componente, etc.) a diseñar.
Esto afectará al tipo de patrón a utilizar.
Patrones arquitectónicos: definen la estructura global y las
reglas de las relaciones entre elementos
Patrones de diseño: resuelven un problema específico a un
determinado de nivel diseño
Patrones de componentes: aplicables a elementos de
pequeña escala de los componentes o páginas
Patrones de pruebas:aplicables al software desarrollado
específicamente para realizar pruebas

M.I.Capel

Tema 1

Introducción

Conceptos Generales
Objetivo: conseguir componentes y servicios software
“evolutivos"
Definition (Software Evolutivo)
En la medida que incorpore, de manera estable, los cambios en
los requerimientos que pueden aparecer en cualquier momento
del proceso de desarrollo y la vida del sistema software.
Para producir “software evolutivo": una arquitectura que
propicie la facilidad de modificación, la flexibilidad, y la
extensibilidad del software.
Los anteriores atributos de calidad dependen directamente
de la arquitectura software utilizada para desarrollar el
sistema.
M.I.Capel

Tema 1

Introducción

Patrones y Mantenibilidad del Software

Se estudian los patrones de diseño que propician
conseguir el atributo de calidad mantenibilidad del software
Referencia ISO 9126 (ISO/IEC 2002):
Deﬁnition (Mantenibilidad del Software)
Facilidad de cambio, Facilidad de análisis, Facilidad de prueba,
y Estabilidad del software
Esta característica de calidad no se limita sólo a la fase del
Mantenimiento: relacionada concepto Evolución software

M.I.Capel

Tema 1

Introducción

Fachada

Deﬁnition (–Contexto)
Mejorar la portabilidad de una aplicación al encapsular las
APIs de bajo nivel del sistema operativo
Encapsular mecanismos o servicios proporcionados por
APIs existentes, no orientadas a objeto
Aumentar la cohesión de componentes

M.I.Capel

Tema 1

Introducción

Fachada

M.I.Capel

Tema 1

Introducción

Implicaciones en la calidad del patrón Fachada

Beneficios
Encapsular APIs bajo nivel
Decrementar probabilidad errores
Acceso uniforme a APIs
Aislar de efectos “no portables"
Mejora la configurabilidad
Mejora la comprensión
Clases más cohesivas
Manejo excepciones

Atributo Calidad
Encapsulamiento, cohesión
Integridad
Accesibilidad
Adaptabilidad
Independencia plataforma
Modificabilidad
Reusabilidad
Integridad

M.I.Capel

Tema 1

Característica ISO 9216
Mantenibilidad, cambios
Fiabilidad, madurez
Funcionalidad, adecuación
Portabilidad, adaptabilidad
Adaptabilidad
Cambios y pruebas
Cambios, análisis
Fiabilidad, Tolerancia Fallos

Introducción

Implicaciones en la calidad 2
Perjuicios
Perder funcionalidad
Degradar el rendimiento
Limitaciones de integración
Estaticidad del patrón

Atributo Calidad
Accesibilidad
Desempeño
Compatibilidad
Dinamismo

Eﬁciencia, tiempo respuesta
Mantenibilidad
Facilidades

Implementar una abstracción sobre otra pre-existente
puede ocasionar que se pierda funcionalidad
Incrementar el coste en recursos (salvar contextos) si los
métodos de la nueva API incluyen mucha funcionalidad
Problemas de integración de interfaces nativas en los
lenguajes de programación que implementan la nueva API
La reusabilidad de las clases de este patrón, una vez
implementado, es muy limitada
M.I.Capel

Tema 1

Introducción

Resumen Características de calidad
Característica

Sub-característica
Facilidad de cambio

Impacto
+

Facilidad de análisis

+

Mantenibilidad

Funcionalidad
Fiabilidad

Eficiencia
Portabilidad

Facilidad de prueba
Conformidad
con
estándares
Adecuación
Madurez
Tolerancia a Fallas
Tiempo de respuesta
Uso de recursos
Adaptabilidad
M.I.Capel

Tema 1

+
+
+

Atributo
Reusabilidad
Modificabilidad
Encapsulamiento
Cohesión
Dinamismo
Reusabilidad
Modificabilidad
Dinamismo
Modificabilidad
Compatibilidad
Accesibilidad
Accesibilidad
Encapsulamiento
Integridad
Desempeño
Independencia
plataforma

de

Introducción

Resumen Características de calidad 2

M.I.Capel

Tema 1

Introducción

Adaptador

Deﬁnition (Contexto)
Reutilizar clases existentes cuya interfaz no es adecuada
para lo que necesita la aplicación cliente
Crear clases reutilizables que cooperen con otras clases
Utilizar varias subclases de manera conjunta

M.I.Capel

Tema 1

Introducción

Adaptador

M.I.Capel

Tema 1

Introducción

Implicaciones en la calidad del patrón Adaptador

Beneﬁcios
Coordinación mínima con adaptado
Funcionalidad inclusiva
Múltiples adaptadores

Atributo Calidad
Desempeño
Extensibilidad
Reusabilidad

M.I.Capel

Tema 1

Eﬁciencia, tiempo respuesta
Mantenibilidad, facilita cambios
Mantenibilidad, cambios, análisis

Introducción


Perjuicios
No transparencia adaptador
Mala adaptación de subclases
Invalidar comportamiento adaptado
Trabajo adaptación variable

Atributo Calidad
Complejidad
Modiﬁcabilidad
Correctitud
Complejidad

Manten., cambios,pruebas,análisis

Los adaptadores no son transparentes a todos los clientes
Una clase adaptadora se limita a la adaptación de clase
origen a clases destino
La cantidad de trabajo a realizar para cada adaptador
dependerá del grado de similitud con el adaptado

M.I.Capel

Tema 1

Introducción


Característica

Sub-característica
Facilidad de cambio

Impacto
+

Mantenibilidad

Facilidad de prueba

Eficiencia

Tiempo de respuesta

Funcionalidad

+
+

Adecuación

-

M.I.Capel

Tema 1

Atributo
Extensibilidad
Reusabilidad
Complejidad
Modificabilidad
Complejidad
Reusabilidad
Complejidad
Desempeño
Correctitud

Introducción

Visitante

Estructuras de objetos de muchas clases y con interfaces
diferentes
Ejecutar operaciones distintas y no relacionadas sobre los
objetos de la estructura
Deﬁnir nuevas operaciones sobre los objetos

M.I.Capel

Tema 1

Introducción

Visitante

M.I.Capel

Tema 1

Introducción

Implicaciones en la calidad del patrón Visitante

Beneﬁcios
Fácil adición operaciones
Comportamiento centralizado
Visitar objetos independientes
Extensibilidad interfaces visitantes

Atributo Calidad
Modiﬁc., extens.
Cohesión
Flexibilidad
Flexibilidad

M.I.Capel

Tema 1

Manteniblidad, cambios, análisis
Mantenibilidad, cambios, pruebas

Introducción


Perjuicios
Deterioro jerarquía visitantes
Acumulación estados visitados
Compromiso encapsulamiento objetos

Atributo Calidad
cohesión
Modif., complj.
Complej., desempeño

Manten., cambios, pruebas
Manten., cambios, análisis
Eﬁciencia, recursos

Cuando se añaden con frecuencia nuevas clases de
elementos concretos, se puede afectar al Visitante
Acumulación de distintos estados en los visitantes como
consecuencia de visitar por diferentes motivos
Acceder al estado interno de los objetos visitados puede
romper su encapsulamiento

M.I.Capel

Tema 1

Introducción

Resumen Características de calidad Visitante
Característica

Sub-característica
Facilidad de cambio

Impacto
+

Mantenibilidad

+
-

Fiabilidad
Eficiencia

Estabilidad
Facilidad de prueba
Madurez
Uso de recursos

+
-

Funcionalidad

Adecuación

+

M.I.Capel

Tema 1

Atributo
Modificabilidad
Extensibilidad
Flexibilidad
Cohesión
Modificabilidad
Complejidad
Modificabilidad
Extensibilidad
Modificabilidad
Complejidad
Encapsulamiento
Cohesión
Encapsulamiento
Complejidad
Desempeño
Extensibilidad

Introducción

Cadena de responsabilidad

Objetos “manejadores" son asignados dinámicamente
para que atienda peticiones de aplicaciones–cliente
Delegar el atender las peticiones a uno o varios objetos sin
que éstos sean determinados a priori
Inclusión dinámica de objetos–“manejadores"
Patrones relacionados: Composite

M.I.Capel

Tema 1

Introducción

Cadena de responsabilidad

M.I.Capel

Tema 1

Introducción

Implicaciones en la calidad de cadena de
responsabilidad

Beneﬁcios
Simplicar interconexiones objetos
Cambio dinámico responsabilidad
Detección errores fácil
Mejor control peticiones
Escalabilidad de la cadena

Atributo Calidad
Acoplamiento
Modif., ﬂexibilidad
Toler.fallas
Manejo error, precisión
Escalab., modif.

M.I.Capel

Tema 1

Manten., cambios, análisis
Manten., cambios
Fiabilidad
Fiabilidad
Manten., cambios

Introducción


Perjuicios
Pérdida peticiones
Funcionalidad por herencia

Atributo Calidad
Adecuación, disponib.
Dinamismo

Funcion.,fiab.,madurez
Mantenib., cambios

Una petición podría llegar al final de la cadena sin ser
atendida
Para que funcione bien, la cadena ha de estar bien
configurada
El funcionamiento o el comportamiento necesitan de la
herencia para poder ser manejados

M.I.Capel

Tema 1

Introducción

Característica

Sub-característica
Facilidad de cambio

Impacto
+

Mantenibilidad

Fiabilidad
Funcionalidad

+
+
+/-

Madurez
Tolerancia a fallas
Adecuación

M.I.Capel

Tema 1

Atributo
Escalabilidad
Simplicidad
Bajo Acoplamiento
Modificabilidad
Flexibilidad
Dinamismo
Bajo acoplamiento
Disponibilidad
Manejo de errores
Precisión

Introducción

Bass, L., Clemens, P., and Kazman, R. (2012).
Software Architecture in Practice.
Addison-Wesley, 3rd edition.
Booch, G. (2008).
Handbook of software architecture.
Addison-Wesley, http:
//www.handbookofsoftwarearchitecture.com/.
Bruegge, B. and Dutoit, A. (2013).
Object–Oriented Software Engineering Using UML,
Patterns and Java.
Prentice-Hall, Upper Saddle River, NJ.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P.,
and Stal, P. (1995).
Pattern-Oriented Software Architecture: a system of
patterns, volume I.
M.I.Capel

Tema 1

Introducción

Wiley and sons.
Gamma, E., Helm, R., Johnson, R., and Vlissides, J.
(1995).
Design patterns elements of reusable object-oriented
sofware.
Addison-Wesley, Reading, Mass.
Lethbridge, T. and Laganiere, R. (2005).
Object-Oriented Software Engineering: Practical Software
Development Using UML and Java.
McGraw,-Hill.

M.I.Capel

Tema 1

Patrones diseño de software

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Patrones diseño de software

Ähnlich wie Patrones diseño de software (20)

Mehr von Manuel Capel-Tunon

Mehr von Manuel Capel-Tunon (8)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Patrones diseño de software