Patrones diseño de software

IntroducciónAná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áticay Telecommunicación

Universidad de GranadaEmail: [email protected]

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

M.I.Capel Tema 1



Índice

1 IntroducciónTipos de patrones de diseñoResolución de problemas de diseño utilizando patronesUtilización de los patrones de diseño con UMLPatrones ArquitectónicosPatrones a Nivel de Componentes

2 Patrones de Diseño y Calidad del Software

M.I.Capel Tema 1



Tipos de patrones de diseñoResolución de problemas de diseño utilizando patrones

Conceptos básicos y motivación

Un patrón permite capturar el conocimiento másimportante acerca del diseño de la solución a unproblema, que permite su posterior reutilización

1 Se aplica en un contexto2 Resuelve un problema3 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 againin our environment and then describes the core of the solution tothat problem in such a way that you can use the solution a milliontimes over without ever doing it the same way twice

M.I.Capel Tema 1




Marcos de trabajo

Para desarrollar un diseño completo de un sistemacomplejo hay que proporcionar una infraestructuraparecida a un esqueleto de la implementación del sistemaLos marcos de trabajo no son patrones de diseño:

Los patrones de diseño son más abstractos que los marcosde trabajoLos patrones de diseño son elementos arquitectónicos máspequeños que los marcos de trabajoLos patrones de diseño son más especializados que losmarcos de trabajo

M.I.Capel Tema 1




Definition (Framework)“Reusable minimum architecture that provides the genericstructure and behaviour for a family of software abstractions,along with a context . . . that specifies their collaboration andtheir use within a given domain"

M.I.Capel Tema 1




Caracterización

Los marcos de trabajo se suelen aplicar sin cambiosProporcionan una estructura de clases para adaptarSon generalmente mucho más grandesarquitectónicamente que los patronesSon más concretos que los patrones

M.I.Capel Tema 1




Caracterización II

Un patrón de diseño es mucho más que un diagrama declases en UMLSon más abstractos que los marcos de trabajoLos patrones capturan las abstracciones del espacio delproblema que son relevantes para encontrar una soluciónUna “metodología de diseño orientada" a objetos ayuda aobtener una descomposición del sistema

M.I.Capel Tema 1




Clasificación basada en su funcionalidad

Patrones arquitectónicos: intentan reflejar la estructura delos problemas que resuelvenPatrones de datos: relacionados con la organización de lainformación en aplicacionesPatrones de Diseño Orientado a Objetos:descomposición,intercomunicación y ubicación de los componentes de unsistema dentro de una jerarquía de clasificaciónPatrones de diseño de interfacesPatrones para aplicaciones Web

M.I.Capel Tema 1




Patrones de Diseño Orientado a Objetos

Patrones Creacionales: instanciación de objetosreforzando las restricciones en el tipo y número de objetosPatrones Estructurales: organización en integración declases de objetos dentro de grandes estructuras deinformaciónPatrones Comportamentales: asignación deresponsabilidades y comunicación entre los objetos

M.I.Capel Tema 1




Ámbito de los patrones actuales

Segundo criterio de clasificación de los patrones de diseñoLas relaciones entre clases y subclases es estáticaLos patrones que se refieren a objetos tratan de relacionesdinámicas

Patrones creacionales de clases vs. de objetosPatrones comportamentales de clases vs. de objetos

M.I.Capel Tema 1




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

Enfocadas hacia la subclasificaciónEnfocadas hacia las colaboraciones y responsabilidadesen el sistema objetivoEnfocada hacia el modeladoLos enfoques anteriores son complementarios

M.I.Capel Tema 1




Aspectos generales comunes

Los patrones de diseño ayudan a determinarqué es un objeto y hasta donde descomponerlos enobjetos más simples (granularidad)Determinación de la jerarquía y tipos de clases de objetosDeterminación de la interfacesDiferencias entre el mecanismo de herencia de las clasesy de las interfaces

Definition (Principio de diseño)“Program to an interface not to an implementation"

M.I.Capel Tema 1




Descripción de un patrónPlantilla

Contexto describe el entorno en el que seubica el problema incluyendo el

dominio de aplicación

Problema una o dos frases que explican lo quese pretende resolver

Fuerzaslista el sistema de fuerzas que afectan a la

manera en que ha de resolverse el problemaincluye las limitaciones y restricciones

que han de respetarse

Solución proporciona una descripción detalladade la solución propuesta para el problema

Intención describe el patrón y lo que hace

Anti-patrones“soluciones" que no funcionan en el contexto

o que son peores; suelen ser errorescometidos por principiantes

Patrones relacionados referencias cruzadas relacionadascon los patrones de diseño

Referencias reconocimientos a aquellos desarrolladoresque desarrollaron o inspiraron el patrón que se propone

M.I.Capel Tema 1




Lenguajes de patrones

Modelo de RequisitosDescribe el conjunto del problema.Establece el contexto e identificalos intereses que dominan en labúsqueda de un patrón.

Se trata de una colección de patrones de diseño quecolaboran para resolver los problemas dentro de undominio de aplicacionesSe ha de definir una arquitectura software o un marco detrabajoHasta llegar al nivel de patrones de diseño que implicanclases y componentes relacionados

M.I.Capel Tema 1



Utilización de los patrones de diseño con UMLPatrones ArquitectónicosPatrones a Nivel de Componentes

Diseño basado en patrones dentro de un contexto

Principios Generales de DiseñoI Descubrir el contexto del problema a partir del modelo de

requerimientosII Extraer los patrones del nivel actual de abstracciónIII Escoger un esqueleto de implementación que refleje el

contextoIV Trabajar siempre hacia dentro del contextoV Refinar el prototipo adaptándolo a las características del

software

M.I.Capel Tema 1




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–Mayfield, [Bass et al., 2012], [Booch, 2008],Buschmann [Buschmann et al., 1995],Lethbridge [Lethbridge and Laganiere, 2005], etc.GoF y “Code Complete" (Steve McConnell, Microsoft) sonlos catálogos de patrones de diseño de referencia

M.I.Capel Tema 1




Tareas de diseño

Desarrollar una jerarquía de entidades de análisis delproblema [Bruegge and Dutoit, 2013]Determinar existencia de un lenguaje de patrones aplicableDeterminación de patrones arquitectónicos candidatosUtilizar las colaboraciones entre patrones de más bajo nivelBuscar los patrones de diseño de interfaces adecuadosIndependientemente del nivel de abstracción, compararlo conotras soluciones pre-existentes

M.I.Capel Tema 1




Abstracción–caso

ContextoProblemaFuerzasSoluciónEjemplosAnti–patronesPatrones RelacionadosReferencias

M.I.Capel Tema 1




Abstracción–caso-2

TituloNombreAutorISBNfechaPublicacionbibliotecaNacional

Ejemplar

numeroCodigodeBarrasmaterializacion

1..*

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

M.I.Capel Tema 1




Ejemplar

TituloAutorISBNfechaPublicacionbibliotecaNacionalnumeroCodigoBarras

Viajes Gulliver Mobby Dick

TituloNombreAutorISBNfechaPublicacionbibliotecaNacional

Ejemplar

numeroCodigoBarras

Forma inapropiada de representar abstracciones y casos

M.I.Capel Tema 1




Patrones Relacionados

El catálogo GoF propone los patrones: Prototype yFlyweight que pueden considerarse como relacionadoscon Abstracción–CasoEl patrón de diseño Prototype: especifica la tipología delos objetos a crear utilizando una clase de prototipoLos nuevos objetos se crean copiando el prototipoEl patrón de diseño Flyweight utiliza compartición delestado intrínseco de objetos de granularidad fina paraevitar creación masiva de estos objetos en una aplicación

M.I.Capel Tema 1




Actor–Papel


M.I.Capel Tema 1




Actor RolAbstracto

Rol-2 Rol-1

interpreta

1..*

Plantilla del patrón Actor–Papel

M.I.Capel Tema 1




SituacionAcademica Alumno

DedicacionCompletaTiempoParcial

NivelEstudios

Graduado PreGraduado

asiste1

acredita1

Ejemplo del patrón Actor–Papel

M.I.Capel Tema 1




Adaptador


M.I.Capel Tema 1




Superclase

metodoPolimorfico()

Adaptador Adaptado

metodoAdaptado()1

NotametodoPolimorfico()(){

returnadaptado.metodoAdaptado();

}

Plantilla del patrón de diseño Adaptador

M.I.Capel Tema 1




Figura3D

volumen()

Esfera Toro ToroPrev

calcVolumen()1

Torovolumen(){

returntoroPrev.calcVolumen();

}

Ejemplo con el patrón de diseño Adaptador

M.I.Capel Tema 1




Composite

Se trata de un patrón de diseño para el particionamientoMediante este patrón, un grupo de objetos es tratado de lamisma forma que un solo objeto“Componer" objetos en estructuras en forma de árbolabstracto para representar jerarquías todo–parteCon este tipo de representación las aplicaciones–clientepueden procesar de manera uniforme los objetosindividuales y las composiciones de objetos

M.I.Capel Tema 1




Component

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

Leaf

Operation()

Composite

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

Client

children

Diagrama de clases del patrón Composite

M.I.Capel Tema 1




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

Es necesario componer objetos para formar árboles querepresenten jerarquíasHay que representar (abstractamente) objetos primitivos(leaf) y sus contenedoresLos contenedores pueden ser agregados de otroscontenedores o de objetosHay operaciones del contenedor que aplican a todos losdescendientes (children)

M.I.Capel Tema 1




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

Para conseguir que los clientes ignoren la diferencia entreobjetos individuales y agregaciones de objetos(Composite)Para que los clientes traten a todos los objetos de unaagregación de manera uniformePara hacer más fácil la inclusión de nuevos componentesPara hacer el diseño más general

M.I.Capel Tema 1




Componente

ListaBotonEtiquetaContenedor

Panel Ventana

contiene*

Ejemplo utilización patrón Composite

M.I.Capel Tema 1




Delegación


M.I.Capel Tema 1




Delegante

metodoDelegador()

Delegado

metodo()1Nota

metodoDelegador(){

delegado.metodo();}

Plantilla del patrón Delegación

M.I.Capel Tema 1




Pila

push()pop()estaVacia()

ListaEnlazada

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

1Nota

push(){

lista.insertaPrimero();}

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

M.I.Capel Tema 1




Fachada


M.I.Capel Tema 1




Fachada

PackageClase1

PackageClase2

PackageClase3

*1

*

1

*

1

NotaContiene un subconjunto demétodos públicos tal quelos otros subsistemas notendrán que acceder a lasclases dentro de los paquetes

Plantilla del patrón Fachada

M.I.Capel Tema 1




LineaAerea

encuentraVuelo()hacerReserva()eliminarReserva()

VueloRegular

Pasajero*1

*1

Ejemplo con el patrón de diseño Fachada

M.I.Capel Tema 1




Factoría Abstracta

Definition (Intención del Patrón)Proporcionar una interfaz para crear familias de objetosrelacionados sin tener que especificar las clases a las quepertenecen.

DefinitionQueremos ofrecer una biblioteca de clases de productos perorevelar sólo sus interfaces, no sus implementaciones

DefinitionQueremos imponer que una familia de productos relacionadossean utilizados conjuntamente por las aplicaciones

M.I.Capel Tema 1




Factoría Abstracta 2


M.I.Capel Tema 1




Plantilla del patrón Factoria Abstracta

DemandanteCreacion <<interface>>Factoria

crearInstancia()

ClaseGenerica

ClaseEspecificaApl FactoriaEspecificaApl

*

crear

1

M.I.Capel Tema 1




Factoría Abstracta

Factoría: declara una interfaz para las operaciones decreación de productos abstractosFactoría Específica de la Aplicación: programan lasoperaciones para crearse objetos–producto concretosClase Genérica: declara una interfaz para un tipo concretode objetos–productoClase Específica de la Aplicación: programa elobjeto–producto que va a ser creado por la factoríacorrespondiente; implementa la interfaz en clase genéricaDemandante Creación: sólo usa las interfaces declaradasen ClaseGenerica y Factoria

M.I.Capel Tema 1




¿Cuándo utilizar “Flyweight"

Han de darse todas las condiciones siguientesLa aplicación utiliza un número grande de objetos (bajagranularidad)Altos costes de almacenamiento debido a la cantidad deobjetosLa mayoría del estado de un objeto se puede convertir enextrínsecoDespués de encapsular el estado extrínseco, muchosgrupos de objetos pueden ser reemplazados por unnúmero relativamente pequeño de objetos compartidosNo se depende de la identidad de los objetos

M.I.Capel Tema 1




FactoriaFlyweight Flyweight

Operacion(estadoExtrinseco)

flyweights

FlyweightConcreto

estadoIntrinsecoOperacion(estadoExtrinseco)

FlyweightConcretoNoCompartido

todosEstadosOperacion(estadoExtrinseco)

Cliente

Ejemplo del patrón Flyweight

M.I.Capel Tema 1




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

Para ahorrar espacio: mayor cuanto más estado intrínsecode los objetos se pueda compartirPara negociar el espacio del estado extrínseco por tiempode cómputo (si se puede calcular el estado)Para representar estructuras jerárquicas combinado con elpatrón CompositePero, los nodos–hojas representados por “flyweights" nopueden contener un puntero a su nodo superior

M.I.Capel Tema 1




ElementoEscritura

Dibujar(Contexto)Intersectar(Punto,Contexto)

Fila


Caracterchar cDibujar(Contexto)Intersectar(Punto,Contexto)

Columna


descend descend

Ejemplo de aplicación susceptible de utilizar “flyweights"

M.I.Capel Tema 1




Inmutable


M.I.Capel Tema 1




Interfaz Sólo–Lectura


M.I.Capel Tema 1




<<interface>>SoloLectura

consigueAtributo()

ClaseSinPrivilegio

Mutableprivate

consigueAtributo()fijaAtributo()

Mutante

**

**

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

M.I.Capel Tema 1




Método Factoría

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

M.I.Capel Tema 1




Nota. . .{

producto= metodoFactoria();}

Nota. . .{

return new ProductoConcreto();}

<<interface>>Producto

ProductoConcreto

Creador

metodoFactoria()unaOperacion()

CreadorConcreto

metodoFactoria()

Plantilla del patrón Método Factoría

M.I.Capel Tema 1




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

M.I.Capel Tema 1




Observador


M.I.Capel Tema 1




ObservableincluirObervador()notificarObservadores()

<<interface>>Observador

actualizar()

ObservableConcreto ObservadorConcreto

**

Plantilla de patrón de diseño Observador

M.I.Capel Tema 1




Observable <<interface>>Observador

Pronosticador MonitorTiempo

**

Los obervadores son notificados cuando cambia el tiempo

Ejemplo con el patrón Observador

M.I.Capel Tema 1




Cuándo utilizar “Prototype"

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

M.I.Capel Tema 1




Cliente

Operacion()

Prototype

Clonar()

PrototipoConcreto1

Clonar()

PrototipoConcreto2

Clonar()

prototipo

1..*1

Diagrama de clases del patrón Prototype

M.I.Capel Tema 1




Para qué utilizar “Prototype"

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

M.I.Capel Tema 1




Proxy


M.I.Capel Tema 1




<<interface>>ClassIF

Cliente Proxy ClasePesada**

0..10..1

Plantilla del patrón de diseño Proxy

M.I.Capel Tema 1




“Singleton"


M.I.Capel Tema 1




Visitante

Para representar a una operación que ha de ser realizadasobre los elementos de una estructura de objetosLas aplicaciones crearán objetos VisitanteConcreto ydespués atraviesan la estructura de objetosAl ser visitados los objetos, el visitante llamará al métodoadecuado para cada objetoSe ha de evitar cambiar las clases de los elementos sobrelos que opera

M.I.Capel Tema 1




Cliente Visitante

VisitanteConcreto1

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

VisitanteConcreto2

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

EstructuraElemento

aceptar(Visitante)

ElemConcretoA

aceptar(Visitante v)operacionA()

ElemConcretoB

aceptar(Visitante v)operacionB()

M.I.Capel Tema 1




Visitante 2

Los VisitanteConcreto programan cada operacióndeclarada en Visitante, proporcionan el contexto paraejecutar la operación y almacenan su estado durante elrecorrido de la estructuraLos objetos del tipo Elemento definen una operaciónaceptar() a la que se le pasa un VisitanteConcreto comoargumentoA la operación visitar() hay que pasarle la referencia delelemento que envía la petición a un VisitanteConcreto

M.I.Capel Tema 1




Patrones ArquitectónicosCaracterísticas de estos patrones

Una clasificación [Booch, 2008] atendiendo a caracterís-ticas para cumplir con los requisitos de seguridad,rendimiento, despliegue y almacenamiento

Control de accesos: el acceso a determinadas partes de laarquitectura software ha de ser controlado rigurosamente.Concurrencia: diferentes formas de permitir que loscomponentes de la aplicación sean concurrentes.Distribución: la comunicación entre entidades software esmuy diversa y afecta al diseño, la ubicación de loscomponentes ha de ser optimizable (configurabilidad).Persistencia: la supervivencia de los objetos (atributos yestado) entre distintas ejecuciones es algo diseñable. Unamala solución puede dañar la eficiencia gravemente

M.I.Capel Tema 1




Categorías

Whole UI ⇒ TopLevelNavigationPage Layout ⇒ CardStackForms and Input ⇒ Fill-in-the-blanksTables ⇒ SortableTableDirect Data Manipulation ⇒ BreadCrumbsNavigation ⇒ EditInPlaceSearching ⇒ SimpleSearchPage Elements ⇒ WizardE–Commerce ⇒ ShoppingCartMiscellaneous ⇒ ProgressIndicator

M.I.Capel Tema 1




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ñoPatrones de la Arquitectura de Información: estructura dela información y formas de accesoPatrones de navegación: estructuras de enlacesPatrones de interacción: cómo desarrollar interfacesbasándose en el contexto e informando de lasconsecuenciasPatrones de presentación: organización interna defunciones de control para conseguir usabilidadPatrones funcionales: flujos y algorítmica

M.I.Capel Tema 1




Granularidad del diseñoEl nivel de abstracción distinto según el tamaño delelemento (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 lasreglas de las relaciones entre elementosPatrones de diseño: resuelven un problema específico a undeterminado de nivel diseñoPatrones de componentes: aplicables a elementos depequeña escala de los componentes o páginasPatrones de pruebas:aplicables al software desarrolladoespecíficamente para realizar pruebas

M.I.Capel Tema 1



Conceptos Generales

Objetivo: conseguir componentes y servicios software“evolutivos"

Definition (Software Evolutivo)En la medida que incorpore, de manera estable, los cambios enlos requerimientos que pueden aparecer en cualquier momentodel proceso de desarrollo y la vida del sistema software.

Para producir “software evolutivo": una arquitectura quepropicie la facilidad de modificación, la flexibilidad, y laextensibilidad del software.Los anteriores atributos de calidad dependen directamentede la arquitectura software utilizada para desarrollar elsistema.

M.I.Capel Tema 1



Patrones y Mantenibilidad del Software

Se estudian los patrones de diseño que propicianconseguir el atributo de calidad mantenibilidad del softwareReferencia ISO 9126 (ISO/IEC 2002):

Definition (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 delMantenimiento: relacionada concepto Evolución software

M.I.Capel Tema 1



Fachada

Definition (–Contexto)Mejorar la portabilidad de una aplicación al encapsular lasAPIs de bajo nivel del sistema operativoEncapsular mecanismos o servicios proporcionados porAPIs existentes, no orientadas a objetoAumentar la cohesión de componentes

M.I.Capel Tema 1



Fachada

M.I.Capel Tema 1



Implicaciones en la calidad del patrón Fachada

Beneficios Atributo Calidad Característica ISO 9216Encapsular APIs bajo nivel Encapsulamiento, cohesión Mantenibilidad, cambiosDecrementar probabilidad errores Integridad Fiabilidad, madurezAcceso uniforme a APIs Accesibilidad Funcionalidad, adecuaciónAislar de efectos “no portables" Adaptabilidad Portabilidad, adaptabilidadMejora la configurabilidad Independencia plataforma AdaptabilidadMejora la comprensión Modificabilidad Cambios y pruebasClases más cohesivas Reusabilidad Cambios, análisisManejo excepciones Integridad Fiabilidad, Tolerancia Fallos

M.I.Capel Tema 1



Implicaciones en la calidad 2

Perjuicios Atributo Calidad Característica ISO 9216Perder funcionalidad Accesibilidad Funcionalidad, adecuaciónDegradar el rendimiento Desempeño Eficiencia, tiempo respuestaLimitaciones de integración Compatibilidad MantenibilidadEstaticidad del patrón Dinamismo Facilidades

Implementar una abstracción sobre otra pre-existentepuede ocasionar que se pierda funcionalidadIncrementar el coste en recursos (salvar contextos) si losmétodos de la nueva API incluyen mucha funcionalidadProblemas de integración de interfaces nativas en loslenguajes de programación que implementan la nueva APILa reusabilidad de las clases de este patrón, una vezimplementado, es muy limitada

M.I.Capel Tema 1



Resumen Características de calidad

Característica Sub-característica Impacto Atributo

Mantenibilidad

Facilidad de cambio + Reusabilidad Modificabilidad Encapsulamiento Cohesión

- Dinamismo

Facilidad de análisis + Reusabilidad Modificabilidad

- Dinamismo

Facilidad de prueba + Modificabilidad

Conformidad con estándares

- Compatibilidad

Funcionalidad Adecuación - Accesibilidad

Fiabilidad Madurez +

Accesibilidad Encapsulamiento Integridad

Tolerancia a Fallas

Eficiencia Tiempo de respuesta Uso de recursos

- Desempeño

Portabilidad Adaptabilidad + Independencia de plataforma

M.I.Capel Tema 1



Resumen Características de calidad 2

M.I.Capel Tema 1



Adaptador

Definition (Contexto)Reutilizar clases existentes cuya interfaz no es adecuadapara lo que necesita la aplicación clienteCrear clases reutilizables que cooperen con otras clasesUtilizar varias subclases de manera conjunta

M.I.Capel Tema 1



Adaptador

M.I.Capel Tema 1



Implicaciones en la calidad del patrón Adaptador

Beneficios Atributo Calidad Característica ISO 9216Coordinación mínima con adaptado Desempeño Eficiencia, tiempo respuestaFuncionalidad inclusiva Extensibilidad Mantenibilidad, facilita cambiosMúltiples adaptadores Reusabilidad Mantenibilidad, cambios, análisis

M.I.Capel Tema 1




Perjuicios Atributo Calidad Característica ISO 9216No transparencia adaptador Complejidad Manten., cambios,pruebas,análisisMala adaptación de subclases Modificabilidad Mantenibilidad, cambiosInvalidar comportamiento adaptado Correctitud Funcionalidad, adecuaciónTrabajo adaptación variable Complejidad Mantenibilidad, cambios

Los adaptadores no son transparentes a todos los clientesUna clase adaptadora se limita a la adaptación de claseorigen a clases destinoLa cantidad de trabajo a realizar para cada adaptadordependerá del grado de similitud con el adaptado

M.I.Capel Tema 1





Mantenibilidad

Facilidad de cambio + Extensibilidad Reusabilidad

- Complejidad Modificabilidad

Facilidad de prueba - Complejidad

Facilidad de análisis + Reusabilidad

- Complejidad

Eficiencia Tiempo de respuesta + Desempeño

Funcionalidad Adecuación - Correctitud

M.I.Capel Tema 1




M.I.Capel Tema 1



Visitante

Definition (–Contexto)Estructuras de objetos de muchas clases y con interfacesdiferentesEjecutar operaciones distintas y no relacionadas sobre losobjetos de la estructuraDefinir nuevas operaciones sobre los objetos

M.I.Capel Tema 1



Visitante

M.I.Capel Tema 1



Implicaciones en la calidad del patrón Visitante

Beneficios Atributo Calidad Característica ISO 9216Fácil adición operaciones Modific., extens. Manteniblidad, cambios, análisisComportamiento centralizado Cohesión Mantenibilidad, cambios, pruebasVisitar objetos independientes Flexibilidad Mantenibilidad, cambiosExtensibilidad interfaces visitantes Flexibilidad Mantenibilidad, cambios

M.I.Capel Tema 1




Perjuicios Atributo Calidad Característica ISO 9216Deterioro jerarquía visitantes cohesión Manten., cambios, pruebasAcumulación estados visitados Modif., complj. Manten., cambios, análisisCompromiso encapsulamiento objetos Complej., desempeño Eficiencia, recursos

Cuando se añaden con frecuencia nuevas clases deelementos concretos, se puede afectar al VisitanteAcumulación de distintos estados en los visitantes comoconsecuencia de visitar por diferentes motivosAcceder al estado interno de los objetos visitados puederomper su encapsulamiento

M.I.Capel Tema 1



Resumen Características de calidad Visitante


Mantenibilidad

Facilidad de cambio + Modificabilidad Extensibilidad Flexibilidad Cohesión

- Modificabilidad Complejidad

Facilidad de análisis + Modificabilidad Extensibilidad

- Modificabilidad Complejidad

Estabilidad - Encapsulamiento

Facilidad de prueba + Cohesión

Fiabilidad Madurez - Encapsulamiento

Eficiencia Uso de recursos - Complejidad Desempeño

Funcionalidad Adecuación + Extensibilidad

M.I.Capel Tema 1




M.I.Capel Tema 1



Cadena de responsabilidad

Definition (–Contexto)Objetos “manejadores" son asignados dinámicamentepara que atienda peticiones de aplicaciones–clienteDelegar el atender las peticiones a uno o varios objetos sinque éstos sean determinados a prioriInclusión dinámica de objetos–“manejadores"Patrones relacionados: Composite

M.I.Capel Tema 1



Cadena de responsabilidad

M.I.Capel Tema 1



Implicaciones en la calidad de cadena deresponsabilidad

Beneficios Atributo Calidad Característica ISO 9216Simplicar interconexiones objetos Acoplamiento Manten., cambios, análisisCambio dinámico responsabilidad Modif., flexibilidad Manten., cambiosDetección errores fácil Toler.fallas FiabilidadMejor control peticiones Manejo error, precisión FiabilidadEscalabilidad de la cadena Escalab., modif. Manten., cambios

M.I.Capel Tema 1




Perjuicios Atributo Calidad Característica ISO 9216Pérdida peticiones Adecuación, disponib. Funcion.,fiab.,madurezFuncionalidad por herencia Dinamismo Mantenib., cambios

Una petición podría llegar al final de la cadena sin seratendidaPara que funcione bien, la cadena ha de estar bienconfiguradaEl funcionamiento o el comportamiento necesitan de laherencia para poder ser manejados

M.I.Capel Tema 1





Mantenibilidad

Facilidad de cambio + Escalabilidad Simplicidad Bajo Acoplamiento Modificabilidad Flexibilidad

- Dinamismo

Facilidad de análisis + Bajo acoplamiento

Fiabilidad Madurez - Disponibilidad

Tolerancia a fallas + Manejo de errores

Funcionalidad Adecuación +/- Precisión

M.I.Capel Tema 1




M.I.Capel Tema 1



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 ofpatterns, volume I.

M.I.Capel Tema 1

http://www.handbookofsoftwarearchitecture.com/

http://www.handbookofsoftwarearchitecture.com/



Wiley and sons.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.(1995).Design patterns elements of reusable object-orientedsofware.Addison-Wesley, Reading, Mass.

Lethbridge, T. and Laganiere, R. (2005).Object-Oriented Software Engineering: Practical SoftwareDevelopment Using UML and Java.McGraw,-Hill.

M.I.Capel Tema 1

Patrones diseño de software

Technology

Transcript of Patrones diseño de software