Transcript Servicios Avanzados Multimedia Basados en Componentes

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}@lcc.uma.es
http://www.lcc.uma.es/~{lff,av}
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
2
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

3
Sistemas Abiertos
Concurrentes
 Reactivos
 Independientemente extensibles
 Heterogéneos
 Evolutivos
 Distribuidos

4
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

5
Arquitectura del Software
AS

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)
6
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)7
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
8
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.
9
Arquitectura
Productor/Consumidor
Emisor
Buffer
Receptor
10
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

11
Niveles de Abstracción

Estilos arquitectónicos


Modelos y arquitecturas de referencia


arquitectura reutilizable en aplicaciones de un mismo dominio
Familias y líneas de productos


particularizan un estilo y definen los conceptos asociados
MTs


familias de sistemas que siguen el mismo patrón estructural
arquitectura de una aplicación con diferentes configuraciones
Instancias

arquitectura de una aplicación concreta
12
Estilos Arquitectónicos

Componentes


Conectores


invariantes del estilo
Mecanismos de control


mecanismos de interacción entre componentes
Patrones y restricciones de interconexión


unidades computacionales y de datos
coordinación entre componentes
Propiedades

ventajas e inconvenientes
13
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
14
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
15
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
16
Descripción de Arquitecturas

Diagramas informales de cajas y líneas
•

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)
•

Imprecisos, ambiguos y no analizables
Implican un determinado mecanismo de interacción
UML como notación arquitectónica
Lenguajes de Descripción de Arquitectura (LDAs)
17
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)

18
Arquitectura
Productor/Consumidor
Sender
storage
Enlaces
puertos/roles ¿
analizables ?
Puertos: describen
el comportamiento
de las componentes
Receiver
Buffer
retrieval reader
Roles: describen el
comportamiento
de los conectores
19
Requisitos de un ADL

Composición


Configuración


Debe permitir reutilizar componentes, conectores, y arquitecturas
Heterogeneidad


Debe describir los roles abstractos que juegan los componentes
Reutilización


Debe describir la arquitectura independientemente de los componentes
Abstracción


Debe describir el sistema como una composión de partes
Debe permitir combinar descripciones heterogéneas
Análisis

Debe permitir diversas formas de análisis de la arquitectura
20
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
21
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
22
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
23
Ejemplos de LDAs : RAPIDE
type Application is interface
extern action Receive(p:params); // evento de entrada
public action Results(p:params); // evento de salida
behaviour
(?M in String) Receive(?M) => 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 i:Integer 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;
24
Ejemplos de LDAs : Darwin
cabeza : Filtro
entrada
ant
cauce : Pipeline
sig
salida
entrada
salida
: Pipeline
salida
25
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
26
Lenguajes de especificación de servicios
LDC: Componentes
Propagación de eventos
 Interfaz

Tipo
Atributos
Mensajes + eventos
Componente: Tipo
Atributos
Método()----->
27
Lenguajes de especificación de servicios
LDC: Componentes
def component DoM(fich:”String”)
propagates
listMovies(list-movies=”List”)
end
interface is
type File
fich:”String”
getlistMovies(category=”String”)
throws listMovies(list-movies=”List”)
end
enddef DoM
28
Lenguajes de especificación de servicios
LDC: Conectores

Parametrización
 Componentes participantes
Gestión de eventos
Relación de uso
Conector
componente,
set(componente)
Protocolo
Tipo ASTM
Protocolo en TDF
29
Lenguajes de especificación de servicios
LDC: Conectores
def connector MSelector(newphase:component)
handles
listMovies(list-movies=”List”),service(movie=”String”)
service(category-movie=”Command”)
end
messages
DoM.getlistMovies(category=”String”)
Participant.initService(panel=”DoMpanel”)
Participant.displayService(data=”List”)
Participant.service(command=”Command”)
end
protocol is
type Service
std(SDL) {...}
end
enddef MSelector
30
Lenguajes de especificación de servicios
LDS

Parámetros globales
Configuración con
LCF
Componentes
simples
conjunto
lista de tipos
components
chair
: Manager(name)
audience : set(Participant)
===>
devices
: {TextualChat,FileMovie}
end
item(audience)
31
Lenguajes de especificación de servicios
LDS: Conexiones

Conexiones
 En base a eventos
 Instanciación de la relación de uso
Adaptar componentes
a conectores
Renombrar
métodos y
eventos
32
Lenguajes de especificación de servicios
LDS: Conexiones
participant
scaccess1
subscribed,
non-subscribed
access(params)
Participant
getAccessParams() -->
joinResponse()
join() ------------------->
acdb
SCAccess
ACDB: File
<--------- checkAccess()
join
(scaccess1 : SCAccess(nombre))
scaccess1[acdb] to participant with {access(params), join}
acdb
with {subscribed,non-subscribed};
33
Lenguajes de especificación de servicios
LCF


Organización de servicios genéricos
Servicio de organización común
ConfiguratedDataBase:File
readParameter() ------>
readLocation() -------->
close()
VoD genérico
Organización
ConfiguratedService:File
addFile()
addParties()
addLocation()
addParameter()
close()
VoD versión1
34
Lenguajes de especificación de servicios
LCF
Tipo de servicio
Asignación de nombres lógicos a físicos
Configuración de parámetros globales
Clases de componentes y conectores
set parties unicast
set msap <url>
set movie remote
set participant local
put text “Fich.clientes” parname acdb::acdbfich value=””
put text “Tipo acceso” implementation scaccess value=””
35
Un ejemplo en LEDA (I)
component Buffer
{
interface
storage : Storage;
retrieval : Retrieval;
}
role Storage(put)
{ spec is
put?(x).Storage(put)
}
role Retrieval(get)
{ spec is
get?(item,empty).
. (x) item!(x). Retrieval(get)
+
. empty!(). Retrieval(get);
}
36
Un ejemplo en LEDA (II)
component Sender
{
interface
writer : Writer;
}
component Receiver
{
interface
reader : Reader;
}
role Writer(write)
{ spec is
(data) write!(data). Writer(write);
}
role Reader(read)
{ spec is
(return,empty) read!(return,empty).
( return?(item).Reader(read)
+ empty?().Reader(read) );
}
37
Un ejemplo en LEDA (III)
component ProducerConsumer
{ interface
...
composition
p: Sender;
c: Receiver;
b: Buffer;
attachments
p.writer(write) <> b.storage(write);
b.retrieval(read) <> c.reader(read);
}
38
Comparación de LDAs
Entidades
Dinamismo Verificación
Propiedades
Desarrollo
Reutilizac.
Ejecución
UniCon
Comp/Con
No
No
No
Gen.Cod.
Wright
Comp/Con
No
Compat.
No
No
Darwin
Comp
Sí
Seg./Viveza
No
Gen.Cod.
Rapide
Comp
Limitado
Análisis
Herencia
Restricciones
Simul./
Gen.Cod.
LDS
Comp/Con
Sí
Posible
Extensión
Gen.Cod.
LEDA
Comp
Sí
Compat./Ext.
Ext./Gener. Simul./
Gen.Cod.
39
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
40
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


Tiempo de Diseño


Elementos para generar una aplicación a partir de
COTS
Interfaces funcionales y dependencias de
componentes
Tiempo de Ejecución

Servicios de composición dinámica en runtime
41
AS: problemas y líneas abiertas
1.
2.
3.
4.
5.
6.
Definición de AS
Expresión de parámetros de calidad
Medidas
Herramientas
Relación con el dominio de aplicación
‘Vistas’ arquitectónicas
42
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”
43
P2. Parámetros de Calidad

Actualmente no se tienen en cuenta.



Propios del tiempo de ejecución (dinámicos):


“...ilities”: portability, traceability,...
“...nesses”: correcness, robustness, ...
Performance, security, availability, functionality,
usability, etc.
Intrínsecos a la AS (estáticos):

Modifiability, portability, reusability, integrability,
testability, etc.
44
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

45
P4. Herramientas
Diseño
 Documentación
 Pruebas
 Análisis de propiedades (formales)
 Generación de código/prototipos

46
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

47
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
48
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):269–274.

D. Garlan, R. Allen y J. Ockerbloom (1995), Architectural
Mismatch: Why Reuse is So Hard, IEEE Software, Nov. 1995,
pp. 17–26.

I. Jacobson, G. Booch y J. Rumbaugh (1999), The Unified
Software Development Process, Addison-Wesley
49
Bibliografía

D. Krieger y R. M. Adler (1998), The Emergence of
Distributed Component Platforms, IEEE Computer, March
1998, pp. 43–53.

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. 336–
355.

J. Magee y J. Kramer (1996), Dynamic Structure in Software
Architectures, Software Engineering Notes, vol. 21, no. 6,
Nov. 1996, pp. 3–14.

N. Medvidovic y D. Rosenblum (1997), A Framework for
Classifying and Comparing Architecture Description
Languages, Proc. ESEC/FSE, LNCS, Springer, pp. 60–76.
50
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.
314–334.

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. 52–61.

C. Szyperski (1998), Component Software: Beyond ObjectOriented Programming, Addison-Wesley.

A.W. Brown and K.C. Wallnau, The Current State of CBSE,
IEEE Software, Sept/Oct. 1998
51
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
52
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
53
Desarrollo de Software basado
en MTs
Diseño del MT

 Orientado a objetos (C++, Java)
 Composicional
Ventajas:
 Aumenta la reutilización
 Minimiza riesgos
 Reducción de los costes de producción
 Mejora de la calidad final del producto
54
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
55
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)
56
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
57
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
58
Ejemplo de MT: MultiTel
Componente
Component
usp : LocalUSP
type : String
event (e : ClassEvent)
SetLocalUSP (usp : LocalUSP)
ClassEvent
type : String
from : String
args : Object[]
•public•class•VCManager•extends•Component {
•public•void•showSchedControl(){
•if(
•sched==null){
• •try{
•sched=new•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);
•...
•}
•...
•}
59
MultiTel: Conectores
Conector
Connector
State
sender : Pid
catchEvent (e : ClassEvent)
public void catchEvent(ClassEvent e) throws
Exception {
try {
synchronized(state) {
Method m;
m=(state.getClass().getMethod(e.type,e.args));
state=(State)m.invoke(state,e.args);}
if (state=null)
finalizeConnector();
else
startState();
} catch (Exception e) {}
}
start ()
...
...
SConn_Prot
Event1 ()
...
SConn_State1
Event1 ()
Event2 ()
Paquete reflective de Java
SConn_State2
Event3 ()
Event4 ()
Patrón de diseño State
60
MultiTel: Conectores
•Connector
•package•mtsb.vc;
•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•,"turnRequest",arg);
•sendMessage(
•}
•public•State •takeTurn(){
•Object[]•arg={
•usp.user};
•s•endMessage("•VirtualConnection","emit",arg);
•return •
(State) •new SSchedMPTU1_Speaking(
•usp);
•}
•...
•}
61
MultiTel: Composición dinámica
de componentes y conectores
cc1=Access
P1=Participant
Event(e)
catchEvent(e)
Composición
dinámica
AS
P1,P2,cc1,cc2
=CA
Búsqueda del contexto
global
C3P
USP
event(ClassEvent event){
for(i=0;i<numberOfConnectors();i++){
if(service.catchEvent(i,
event.type,event.from,role)){
String location =service.connectorLocation(i);
String to
=service.connectorName(i);
Connector ref =service.connectorRef(i);
String newname=service.getEventRenaming(...);
ClassEvent renamed=event.rename(newname);
if(location.equals("local")){
if(ref!=null){
propagateEvent(to,renamed);
}
if (location.equals(“remote”)) {
Vector usps=getGlobalContext();
for(int j=0;j<usps.size();j++){
USP r=getRemoteUSP(remoteusp);
if(r.isThisConnector(to).booleanValue()){
transmitEvent(remote,to,renamed);
}
else // URL
....
}
62
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.SCAccess1");
•connector("
•SMAccess",{"
•participant,remote","manager,local"},"mtsb.vc.SMAccess1");
•...
•}
•public•void•loadConnections
•(){
•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();}
•}
•public•void•loadOrganizationParameters
•(){
•// Load•value•for•the •
"scheduler"•parameter•of SSchedMP•connector
•}
•...
•}
63
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.
64
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
65
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

66
¿ 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
67
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
68
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.

69
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.
70
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
cliente
Destino
Servidor
Peticion()
OtraPeticion()
Adapter
Peticion()
p.OtraPeticion()
71
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
Abstraccion
Implementacion
Operacion()
OperacionImpl()
imp.OperacionImpl()
OperacionRedefinida
ImplementaA
ImplementaB
OperacionImpl()
OperacionImpl()
72
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 ECOOP’97.
73
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 ECOOP’97, pp.511-529, 1997.
D. Schmidt, A Family of Design Patterns For Flexibly
Configuring Network Services in Distributed Systems, actas
del ICCDS’96, 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/
74