Lidia Fuentes y Antonio Vallecillo

1
Arquitecturas Software y Marcos de Trabajo

• Lidia Fuentes y Antonio Vallecillo
• GISUM Grupo de Ingeniería del Software de la
  Universidad de Málaga
• Departamento de Lenguajes y Ciencias de la
  Computación
• Universidad de Málaga. España
• lff,av_at_lcc.uma.es
• http//www.lcc.uma.es/lff,av

2
Contenido

• Arquitectura del Software
• Estilos Arquitectónicos
• Lenguajes de Descripción de Arquitecturas
• Programación Orientada a Componentes
• MTs y Patrones de Diseño
• Patrones de Diseño su utilidad
• MTs (Frameworks) orientados a objetos y a
  componentes
• Clasificación de los MTs

3
Arquitectura del Software Introducción

• Sistemas Abiertos
• Características y Problemática
• Estilos Arquitectónicos
• Lenguajes de Descripción de arquitecturas
• Ingeniería del Software basada en Componentes
  (CBSE)
• Arquitectura Software y COTS

4
Sistemas Abiertos

• Concurrentes
• Reactivos
• Independientemente extensibles
• Heterogéneos
• Evolutivos
• Distribuidos

5
Problemas específicos

• Gestión de la evolución (del sistema y de sus
  componentes)
• Compatibilidad de componentes
• Falta de visión global del sistema
• Dificultad para garantizar la seguridad
• Retrasos y errores en las comunicaciones
• Fallos y errores en los propios componentes

6
Arquitectura del Software

• Estructura de los componentes de un programa o
  sistema, sus interrelaciones, y los principios y
  reglas que gobiernan su diseño y evolución en el
  tiempo.
• (Garlan y Perry, 1995)
• Estructura o estructuras de un sistema, lo que
  incluye sus componentes software, las propiedades
  observables de dichos componentes y las
  relaciones entre ellos.
• (Bass, Clements y Kazman, 1998)

7
Disciplina

• Nivel del diseño del software donde se definen la
  estructura y propiedades globales del sistema.
• (Garlan y Perry, 1995)
• La Arquitectura del Software se centra en
  aquellos aspectos del diseño y desarrollo que no
  pueden tratarse de forma adecuada dentro de los
  módulos que forman el sistema.
• (Shaw y Garlan, 1996)

8
Caracterización

• Arquitectura vs. Algoritmos Datos
• organización del sistema
• Interacción de componentes vs. Definición/uso
• componentes y conectores
• Estilo Arquitectónico vs. Instancia
• restricciones en la forma de una familia de
  instancias
• Arquitectura vs. Métodos de Diseño
• espacio de diseños arquitectónicos

9
Descripción de una AS

• Representación de alto nivel de la estructura de
  un sistema o aplicación, que describe
• partes que la integran,
• interacciones entre ellas,
• patrones que supervisan su composición, y
• restricciones para aplicar dichos patrones.

10
Arquitectura Productor/Consumidor
11
Objetivos de la A.S.

• Comprender y manejar la estructura de las
  aplicaciones complejas
• Reutilizar dicha estructura (o parte de ella)
• Planificar la evolución de la aplicación
• Analizar la corrección de la aplicación y su
  grado de cumplimiento frente a los requisitos
  iniciales
• Permitir el estudio de propiedades específicas

12
Niveles de Abstracción

• Estilos arquitectónicos
• familias de sistemas que siguen el mismo patrón
  estructural
• Modelos y arquitecturas de referencia
• particularizan un estilo y definen los conceptos
  asociados
• MTs
• arquitectura reutilizable en aplicaciones de un
  mismo dominio
• Familias y líneas de productos
• arquitectura de una aplicación con diferentes
  configuraciones
• Instancias
• arquitectura de una aplicación concreta

13
Estilos Arquitectónicos

• Componentes
• unidades computacionales y de datos
• Conectores
• mecanismos de interacción entre componentes
• Patrones y restricciones de interconexión
• invariantes del estilo
• Mecanismos de control
• coordinación entre componentes
• Propiedades
• ventajas e inconvenientes

14
Clasificación de estilos

• Sistemas de flujo de datos
• Sistemas basados en llamada y retorno
• Sistemas de componentes independientes
• Sistemas centrados en los datos
• Máquinas virtuales
• Sistemas heterogéneos

15
Estilos y subestilos (I)

• Sistemas de flujo de datos
• Sucesión de transformaciones de los datos de
  entrada
• Subestilos pipe filter y procesamiento por
  lotes
• Sistemas basados en llamada y retorno
• Reflejan la estructura del lenguaje de
  programación
• Subestilos programa principal-subrutina, OO,
  capas
• Sistemas de componentes independientes
• Componentes distribuidos que se comunican por
  paso de mensajes
• Subestilos sistemas cliente/servidor y de eventos

16
Estilos y subestilos (II)

• Sistemas centrados en los datos
• Acceso compartido a un banco de datos central
• Subestilos repositorio y pizarras (blackboards)
• Máquinas virtuales
• Simulan una funcionalidad no nativa del entorno
• Subestilos intérpretes y sistemas basados en
  reglas
• Sistemas heterogéneos
• Localmente, jerárquicamente o simultáneamente
  heterogéneos

17
Descripción de Arquitecturas

• Diagramas informales de cajas y líneas
• Imprecisos, ambiguos y no analizables
• Lenguajes de programación modular
• Mezclan aspectos de programación y estructurales
• El análisis se basa en emparejamiento de nombres
• Lenguajes de interconexión de módulos (MILs o
  IDLs)
• Implican un determinado mecanismo de interacción
• UML como notación arquitectónica
• Lenguajes de Descripción de Arquitectura (LDAs)

18
Lenguajes de Descripción de Arquitecturas (LDAs)

• Un LDA es un lenguaje o notación para describir
  una arquitectura software
• Descripción de componentes, conectores y enlaces
  entre ellos.
• Herramientas para la verificación de la
  arquitectura y el prototipado rápido.
• Existen LDAs de propósito general y otros de
  dominio específico (DSLs)

19
(No Transcript)
20
Requisitos de un ADL

• Composición
• Debe describir el sistema como una composión de
  partes
• Configuración
• Debe describir la arquitectura independientemente
  de los componentes
• Abstracción
• Debe describir los roles abstractos que juegan
  los componentes
• Reutilización
• Debe permitir reutilizar componentes, conectores,
  y arquitecturas
• Heterogeneidad
• Debe permitir combinar descripciones heterogéneas
• Análisis
• Debe permitir diversas formas de análisis de la
  arquitectura

21
Ejemplos de LDAs

• Ejemplos
• UNICON (Shaw et al. 1995)
• Rapide (Luckham et al. 1995)
• Darwin (Magee y Kramer, 1996 1999)
• Wright (Allen y Garlan, 1997 1998)
• Executable Connectors (Ducasse y Richner, 1997)
• Problema No cubren todo el ciclo de vida de las
  aplicaciones software (sólo diseño preliminar),
  no llegan a la implementación

22
Ejemplos de LDAs UNICON

• Una pipe de Unix
• connector Unix-pipe
• protocol is
• type pipe
• role source is Source
• MaxConns(1)
• end source
• role sink is Sink
• MaxConns(1)
• end sink
• end protocol

• ...
• implementation is
• builtin
• end implementation
• end Unix-Pipe

23
Ejemplos de LDAs Wright

• Una pipe de Unix
• connector Pipe
• role WRITER write ? WRITER ? close ? ?
• role READER let ExitOnly close ??
• in let DoRead (read ? READER ? readEoF ?
  ExitOnly
• in DoRead ? ExitOnly
• glue let ReadOnly READER.read ? readOnly
• ? READER.readEoF ? READER.close ??
• ? READER.close ??
• in let WriteOnly WRITER.write ? WriteOnly ?
  WRITER.close??
• in WRITER.write ? glue ? READER.read ? glue
• ? WRITE.close ? ReadOnly ? READER.close
  ? WriteOnly

24
Ejemplos de LDAs RAPIDE

• type Application is interface
• extern action Receive(pparams) // evento de
  entrada
• public action Results(pparams) // evento de
  salida
• behaviour
• (?M in String) Receive(?M) gt Results(?M) //
  transición de eventos
• end Application
• architecture DistrApp(Num Integer) return
  InterfaceDistrApp is
• P array(Integer) of Application
• Q array(Integer) of Resource //Dual of
  Application
• connect
• for iInteger in 1..Num generate
• (?M in String) P(i). Receive(?M) to
  Q(i).Results(?M)
• P(i).Results(?M) to
  Q(i). Receive(?M)
• end generate
• end DistrApp

25
Ejemplos de LDAs Darwin
26
LDAs del grupo GISUM

• LDC LDS (Fuentes y Troya, 1998)
• Modelo de componentes pasivos y conectores
  reactivos
• Formalismo de especificación de comportamiento de
  conectores (TDFs, ?-cálculo, etc.)
• LEDA (Canal, Pimentel y Troya, 2000)
• Basado en el álgebra de procesos ?-cálculo
• Permite especificar arquitecturas dinámicas

27
LDC Componentes
Lenguajes de especificación de servicios

• Propagación de eventos
• Interfaz

28
LDC Componentes
Lenguajes de especificación de servicios
def component DoM(fichString) propagates li
stMovies(list-moviesList) end interface
is type File fichString getlistMovies(
categoryString) throws
listMovies(list-moviesList) end enddef DoM
29
LDC Conectores
Lenguajes de especificación de servicios

• Parametrización
• Componentes participantes

30
LDC Conectores
Lenguajes de especificación de servicios
def connector MSelector(newphasecomponent) hand
les listMovies(list-moviesList),service(movie
String) service(category-movieCommand) en
d messages DoM.getlistMovies(categoryString)
Participant.initService(panelDoMpanel) Par
ticipant.displayService(dataList) Participant
.service(commandCommand) end protocol
is type Service std(SDL) ... end enddef
MSelector
31
LDS
Lenguajes de especificación de servicios

• Parámetros globales

Componentes simples conjunto lista de tipos
components chair Manager(name) audienc
e set(Participant) gt item(audience) de
vices TextualChat,FileMovie end
32
LDS Conexiones
Lenguajes de especificación de servicios

• Conexiones
• En base a eventos
• Instanciación de la relación de uso

33
LDS Conexiones
Lenguajes de especificación de servicios
participant
acdb
scaccess1
(scaccess1 SCAccess(nombre)) scaccess1acdb
to participant with access(params), join
acdb with subscribed,non-subscribed
34
LCF
Lenguajes de especificación de servicios

• Organización de servicios genéricos
• Servicio de organización común

35
LCF
Lenguajes de especificación de servicios
36
Un ejemplo en LEDA (I)
component Buffer interface storage
Storage retrieval Retrieval
role Storage(put) spec is put?(x).Storage(pu
t)
role Retrieval(get) spec is
get?(item,empty). ?. (x) item!(x).
Retrieval(get) ?. empty!().
Retrieval(get)
37
Un ejemplo en LEDA (II)
component Sender interface writer Writer
role Writer(write) spec is (data)
write!(data). Writer(write)
role Reader(read) spec is (return,empty)
read!(return,empty). ( return?(item).Reader(r
ead) empty?().Reader(read) )
component Receiver interface reader
Reader
38
Un ejemplo en LEDA (III)
component ProducerConsumer interface ... comp
osition p Sender c Receiver b
Buffer attachments p.writer(write) ltgt
b.storage(write) b.retrieval(read) ltgt
c.reader(read)
39
Comparación de LDAs
40
Arquitectura Software vs. COTS

• Arquitectura del Software
• Orientados a la reutilización independiente de
  patrones arquitectónicos y de componentes
• Modelos formales
• Tecnología desarrollada en el entorno académico
• COTS
• Componentes con interfaces estándares (IDLs)
• No aparece la noción de conector o enchufe
• Mercado global de componentes centrado en la
  reutilización de componentes
• Tecnología madura OpenDoc/CORBA, OLE/COM

41
Ingeniería del Software Basada en Componentes

• Componentes unidos a una arquitectura
• Partes de la interfaz de un componente para
  soportar la noción de arquitectura
• Tiempo de Composición
• Elementos para generar una aplicación a partir de
  COTS
• Tiempo de Diseño
• Interfaces funcionales y dependencias de
  componentes
• Tiempo de Ejecución
• Servicios de composición dinámica en runtime

42
AS problemas y líneas abiertas

• Definición de AS
• Expresión de parámetros de calidad
• Medidas
• Herramientas
• Relación con el dominio de aplicación
• Vistas arquitectónicas

43
P1. Definición de AS

• Una AS es algo más que una descripción de la
  estructura de una aplicación
• Qué es ese algo más?
• Cómo se expresa?
• Otras definiciones alternativas de AS
• A Software Architecture is a collection of
  categories of elements that share the same
  likelihood of change. Each category contains
  software elements that exhibit shared stability
  characteristics

44
P2. Parámetros de Calidad

• Actualmente no se tienen en cuenta.
• ...ilities portability, traceability,...
• ...nesses correcness, robustness, ...
• Propios del tiempo de ejecución (dinámicos)
• Performance, security, availability,
  functionality, usability, etc.
• Intrínsecos a la AS (estáticos)
• Modifiability, portability, reusability,
  integrability, testability, etc.

45
P3. Medidas

• Necesarias para poder hablar de Ingeniería del
  Software
• Deberían estimar, de forma cuantitativa
• Tamaño
• Estructura
• Calidad del diseño
• ...
• Funcionales (estructuradas)/Orientadas a Objeto

46
P4. Herramientas

• Diseño
• Documentación
• Pruebas
• Análisis de propiedades (formales)
• Generación de código/prototipos

47
P5. Dominio de aplicación

• Análisis de los dominios de la aplicación y de la
  solución para derivar AS
• Mejor y más estable estructura
• Mejor capacidad de evolución
• AS solución más natural e integrada en el entorno
  de la aplicación

48
P6. Vistas Arquitectónicas

• Varias vistas arquitectónicas
• Algunas técnicas, otras específicas del dominio,
  otras tecnológicas
• RM-ODP o TINA ya las definen
• Problemas consistencia e integración

49
Bibliografía

• P. Clements (1996), Coming Attractions in
  Software Architecture, Technical Report, Software
  Engineering Institute, Carnegie Mellon University
  (USA).
• P. Donohoe (Ed.) (1999), Software Architecture,
  Kluwer Academic Publishers.
• D. Garlan y D. E. Perry (1995), Introduction to
  the Special Issue on Software Architecture, IEEE
  Transactions on Software Engineering,
  21(4)269274.
• D. Garlan, R. Allen y J. Ockerbloom (1995),
  Architectural Mismatch Why Reuse is So Hard,
  IEEE Software, Nov. 1995, pp. 1726.
• I. Jacobson, G. Booch y J. Rumbaugh (1999), The
  Unified Software Development Process,
  Addison-Wesley

50
Bibliografía

• D. Krieger y R. M. Adler (1998), The Emergence of
  Distributed Component Platforms, IEEE Computer,
  March 1998, pp. 4353.
• D. Luckham et al. (1995), Specification and
  Analysis of System Architecture Using Rapide,
  IEEE Transactions on Software Engineering, vol.
  21, no. 4, April 1995, pp. 336355.
• J. Magee y J. Kramer (1996), Dynamic Structure in
  Software Architectures, Software Engineering
  Notes, vol. 21, no. 6, Nov. 1996, pp. 314.
• N. Medvidovic y D. Rosenblum (1997), A Framework
  for Classifying and Comparing Architecture
  Description Languages, Proc. ESEC/FSE, LNCS,
  Springer, pp. 6076.

51
Bibliografía

• W. Pree (1996), Framework Patterns, SIGS
  Publications.
• M. Shaw et al. (1995), Abstractions for Software
  Architecture and Tools to Support Them, IEEE
  Transactions on Software Engineering, vol. 21,
  no. 4, April 1995, pp. 314334.
• M. Shaw y D. Garlan (1996), Software
  Architecture Perspectives on an Emerging
  Discipline, Prentice Hall.
• S. Sparks et al. (1996), Managing Object-Oriented
  Framework Reuse, IEEE Computer, Sept. 1996, pp.
  5261.
• C. Szyperski (1998), Component Software Beyond
  Object-Oriented Programming, Addison-Wesley.
• A.W. Brown and K.C. Wallnau, The Current State of
  CBSE, IEEE Software, Sept/Oct. 1998

52
Marcos de Trabajo(Application Frameworks)

• Un MT es un diseño reutilizable de todo o parte
  de un sistema, representado por un conjunto de
  clases abstractas y la forma en la que sus
  instancias interactúan

• Un MT es el esqueleto de una aplicación que debe
  ser adaptado a necesidades concretas por el
  programador de la aplicación

53
Caracterización de los MTs

• Arquitectura especializada para un dominio de
  aplicación
• Define interfaces de componentes
• Establece reglas de interacción entre ellos
• Implementa alguno de los componentes
• El usuario encaja sus componentes en el marco

54
Desarrollo de Software basado en MTs

• Ventajas
• Aumenta la reutilización
• Minimiza riesgos
• Reducción de los costes de producción
• Mejora de la calidad final del producto

55
Utilización de un MT

• Valorar la adecuación de un MT a un problema
• Comprender su arquitectura
• Identificar los hot spots
• Adaptar/Extender el MT
• El problema de la documentación
• No existe documentación o es pobre
• No es estándar
• No tiene una semántica formal
• Dirigida a diferentes tipos de usuarios

56
Documentación de MT (I)

• Entornos gráficos
• Grafos (Eusel et al. 1997, Florijn et al. 1997)
• Secuencias de mensajes (Lange et al. 1995)
• Aportan conocimiento más profundo del MT
• Sin una metodología para usar ese conocimiento
• Útil sólo en la fase de identificación del MT
• Contratos de Reutilización
• Definen la cooperación entre los diseñadores del
  MT y los encargados de extenderlo o adaptarlo
  (Steyaert et al. 1996, Codenie et al. 1997)

57
Documentación De MT(II)

• Patrones de Diseño (Design Patterns)
• Útil tanto para diseñar la arquitectura de un MT
  como para documentar el diseño
• Lange y Nakamura, 1995
• Odenthal y Quiebel-Cirkel, 1997
• Meijler y Engel, 1997

• Herramientas visuales
• Enfoque de mayor aceptación actualmente
• Notaciones visuales para representar componentes,
  conectores y enlaces
• Tendencia Complementar con LDAs

58
Extensión de MTs

• Atendiendo a la forma en que un MT puede ser
  extendido podemos clasificar éstos en
• MTs de caja de cristal
• MTs de caja blanca
• MTs de caja negra
• MTs de caja gris

59
Ejemplo de MT MultiTel
Componente
Component
ClassEvent
usp
LocalUSP
type String
type String
from String
args Object
event (e
ClassEvent)
SetLocalUSP (
usp
LocalUSP)

• public

• class

• VCManager

• extends

• Component

• public

• void

• showSchedControl()

• if(

• schednull)

• try

• schednew

• ScheduleFrame(

• usp,this)

• sched.show()

• catch(

• Exception e)

• System.out.println("

• Exception"e)

• e.printStackTrace()

• public

• void

• turnRequest(

• String

• user)

• message("

• User "

• user" has

• requested

• the

• turn")

• Object

• args

• user

• if (/

• Manager

• decision /)

• event("

• takeTurn",args)

• ...

• ...

60
MultiTel Conectores
Conector
State
Connector
sender Pid
catchEvent (e ClassEvent)
start ()
...
...
public void catchEvent(ClassEvent e) throws
Exception try synchronized(state)
Method m m(state.getClass().getMet
hod(e.type,e.args)) state(State)m.invoke(s
tate,e.args) if (statenull)
finalizeConnector() else
startState() catch (Exception e)
SConn_Prot
Event1 ()
...
SConn_State2
SConn_State1
Event3 ()
Event1 ()
Event4 ()
Event2 ()
Patrón de diseño State
Paquete reflective de Java
61
MultiTel Conectores

• package

• mtsb.vc

• Connector

• public

• class SSchedMPTU1_Idle

• extends SSchedMPTU1_Prot

• State

• state

• public SSchedMPTU1_Idle(

• LocalUSP

• usp)

• super(

• usp)

• catchEvent(

• ClassEvent e)

• public

• void

• start()

• sendMessage("

• Manager","showSchedControl")

• sendMessage("

• Manager","showClassControl")

• broadcast(

• Participant,initTurn)

• public

• void

• turnRequest(

• String

• user)

• message("

• User "

• user" has

• requested

• the

• turn")

• Object

• arg

• user

• scheduler

• sendMessage(

• ,"turnRequest",arg)

• public

• State

• takeTurn()

• Object

• arg

• usp.user

• s

• endMessage("

• VirtualConnection","emit",arg)

• return (

• State)

• new SSchedMPTU1_Speaking(

• usp)

• ...

62
MultiTel Composición dinámica de componentes y
conectores
cc1Access
P1Participant
AS
USP
P1,P2,cc1,cc2
CA
Búsqueda del contexto
global
C3P
63
Extensión de MultiTel programación de un servicio

• public

• class

• TeleUni

• extends

• ServiceUSP

• public

• void

• defComponents

• ()

• component("

• Participant","

• participant,local","manager,remote","

• mtsb.vc.TUParticipant")

• component("

• Manager","

• participant,remote","manager,local","

• mtsb.vc.TUManager")

• component("ACDB","

• participant,local","manager,remote","

• mtsb.vc.VCACDB")

• ...

• public

• void

• defConnectors

• ()

• connector("

• SCAccess","

• participant,local","manager,remote","mtsb.vc.SCAc
  cess1")

• connector("

• SMAccess","

• participant,remote","manager,local","mtsb.vc.SMAc
  cess1")

• ...

• loadConnections

• public

• void

• ()

• String events1"

• join"

• handlesEventsFrom("SMAccess",events1,"Manager")

• String events2"

• access"

• handlesEventsFrom("SCAccess",events2,"Participant"
  )

• ...

• public

• void

• participantInitialContext

• ()

• try

• createComponent("

• Participant,SCAccess")

• catch(

• Exception e)

• System.out.println("

• InitialContext Error")

• public

• void

• managerInitialContext

• ()

• try

• createComponent("

• Manager, ACDB,

• SMAccess, SSchedMP, ...")

• catch(

• Exception e)

• System.out.println("

• InitialContext Error ")

• e.printStackTrace()

• loadOrganizationParameters

• public

• void

• ()

• // Load

• value

• for

• the "

• scheduler"

• parameter

• of SSchedMP

• connector

• ...

64
Clasificación De Los Marcos De Trabajo (I)

• Horizontales
• Infraestructuras de comunicaciones
• Interfaces de usuario
• Entornos visuales
• Plataformas de componentes distribuidos, etc

• Verticales
• Telecomunicaciones (TINA, MultiTEL)
• Fabricación
• Multimedia (JMF), etc.

65
Clasificación De Los Marcos De Trabajo (II)

• Generales
• Programación de GUIs
• Entornos de programación visual
• Programación de redes

• Software de base
• Infraestructuras de comunicaciones
• Plataformas de componentes

• De Empresa
• específicos de un dominio, a medida

66
Components Frameworks

• Específicos para el desarrollo de aplicaciones
  basadas en componentes reutilizables
• Presentan características especiales
• Composición tardía, interconexión dinámica,
  extensibilidad black-box, etc
• Suelen definirse como implementación concreta de
  varios patrones de diseño sobre una plataforma de
  componentes concreta

67
Cuándo Resulta Conveniente Definir Un MT ?

• Mercado competitivo
• Plazos de desarrollo muy cortos
• Dominio de aplicación complejo
• Solucionar problemas repetitivos
• Ej aplicaciones multimedia distribuidas

68
Interacción de MTs

• Problemas
• Cohesión entre las clases de un MT
• Solapamiento de dominio
• Falta de estándares de MT
• Soluciones
• Adaptadores o wrappers
• Patrones de diseño
• Mediadores software

69
Patrones de Diseño(Design Patterns)

• Un patrón de diseño ofrece una solución
  abstracta a un problema de diseño que aparece muy
  frecuentemente, expresada mediante un conjunto de
  relaciones e interacciones entre sus componentes

• Complementarios con los MT
• Granularidad más fina que los MT
• Un MT suele estar compuesto por una colección de
  patrones de diseño.

70
Ventajas e Inconvenientes

• Ventajas
• Permiten reutilizar soluciones de problemas
  comunes.
• Están probados y son lo suficientemente flexibles
  para adaptarse a necesidades específicas.
• Inconvenientes
• Su elevado número (falta de catalogación).
• Su complejidad.
• Composición poco definida.

71
PD Adaptador

• El PD Adapter o Wrapper se utiliza para
  convertir la interfaz de una clase en otra
  interfaz, que es la esperada por el objeto
  cliente. Adapta interfaces incompatibles

72
PD Puente

• El PD Bridge se utiliza para desacoplar la
  definición abstracta de un objeto de su
  implementación. De esta forma ambas pueden
  evolucionar independientemente

73
Bibliografía

• M. Fayad, R. Johnson y D. Schmidt, Building
  Application Framework, Wiley Sons, 1999.
• M. Fayad, R. Johnson y D. Schmidt, Implementing
  Application Frameworks, Wiley Sons, 1999.
• M. Fayad y R. Johnson, Domain-Specific
  Application Frameworks, Wiley Sons, 1999.
• M. Fayad, Object-Oriented Application Frameworks,
  Communications of the ACM, Vol. 40, No. 10,
  Octubre 1997.
• E. Gamma et. al., Design Patterns,
  Addison-Wesley, 1995.
• J. Bosch, Design Patterns Frameworks On the
  Issue of Language Support, Actas del Workshop
  Language Support for Design Patterns and
  Frameworks del ECOOP97.

74
Bibliografía

• M. Mattsson, J. Bosch y M. Fayad, Framework
  Integration, problems, causes, solutions,
  Communication of the ACM, Vol. 42, no. 10,
  octubre 1999.
• G. Odenthal y K. Quibeldey-Cirkel, Using Patterns
  for Design and Documentation, actas del ECOOP97,
  pp.511-529, 1997.
• D. Schmidt, A Family of Design Patterns For
  Flexibly Configuring Network Services in
  Distributed Systems, actas del ICCDS96, 1996.
• A. Deimel, The SAP R/3 Business Framework,
  software - Concepts Tools, Vol. 19, pp.29-36,
  1998.
• Research on Design Patterns for Concurrent,
  Parallel, and Distributed Systems.
  http//siesta.cs.wustl.edu/schmidt/patterns.html
• http//hillside.net/patterns/
• http//hillside.net/patterns/books/