Antonio VallecilloAntonio VallecilloGISUM: Grupo de Ingeniería del Software GISUM: Grupo de Ingeniería del Software

de la Universidad de Málagade la Universidad de Málaga

Departamento de Lenguajes y Ciencias de la ComputaciónDepartamento de Lenguajes y Ciencias de la Computación

Universidad de Málaga. EspañaUniversidad de Málaga. España

av@lcc.uma.esav@lcc.uma.es

2ª Parte:Marcos de Trabajo

2

Contenido:

Marcos de trabajo (Marcos de trabajo (FrameworksFrameworks) orientados ) orientados a objetos y a componentesa objetos y a componentes

Clasificación de los MTsClasificación de los MTs Patrones de Diseño: su utilidadPatrones de Diseño: su utilidad

3

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

4

Caracterización de los MTs Arquitectura especializada para un dominio de aplicaciónArquitectura especializada para un dominio de aplicación Define interfaces de componentesDefine interfaces de componentes Establece reglas de interacción entre ellosEstablece reglas de interacción entre ellos Implementa alguno de los componentesImplementa alguno de los componentes El usuario encaja sus componentes en el marcoEl usuario encaja sus componentes en el marco

5

Desarrollo de Software basado en MTs

Ventajas:Ventajas: Aumenta la reutilizaciónAumenta la reutilización Minimiza riesgosMinimiza riesgos Reducción de los costes de producciónReducción de los costes de producción Mejora de la calidad final del productoMejora de la calidad final del producto

Orientado a objetos (C++, Java) Composicional

Diseño del MTDiseño del MT

6

Utilización de un MT Valorar la adecuación de un MT a un problemaValorar la adecuación de un MT a un problema Comprender su arquitecturaComprender su arquitectura Identificar los “Identificar los “hot spotshot spots”” Adaptar/Extender el MTAdaptar/Extender el MT

El El problema de la documentaciónproblema de la documentación No existe documentación o es pobreNo existe documentación o es pobre No es estándarNo es estándar No tiene una semántica formalNo tiene una semántica formal Dirigida a diferentes tipos de usuariosDirigida a diferentes tipos de usuarios

7

Documentación de MT (I) Entornos gráficosEntornos gráficos

Grafos (Eusel et al. 1997, Florijn et al. 1997)Grafos (Eusel et al. 1997, Florijn et al. 1997) Secuencias de mensajes (Lange et al. 1995)Secuencias de mensajes (Lange et al. 1995) Aportan conocimiento más profundo del MTAportan conocimiento más profundo del MT Sin una metodología para usar ese conocimientoSin una metodología para usar ese conocimiento Útil sólo en la fase de identificación del MTÚtil sólo en la fase de identificación del MT

Contratos de ReutilizaciónContratos de Reutilización Definen la cooperación entre los diseñadores del Definen la cooperación entre los diseñadores del

MT y los encargados de extenderlo o adaptarlo MT y los encargados de extenderlo o adaptarlo (Steyaert et al. 1996, Codenie et al. 1997)(Steyaert et al. 1996, Codenie et al. 1997)

8

Documentación De MT(II) Patrones de Diseño (Patrones de Diseño (Design PatternsDesign Patterns))

Útil tanto para diseñar la arquitectura de un MT como Útil tanto para diseñar la arquitectura de un MT como para documentar el diseñopara documentar el diseño

Lange y Nakamura, 1995Lange y Nakamura, 1995 Odenthal y Quiebel-Cirkel, 1997Odenthal y Quiebel-Cirkel, 1997 Meijler y Engel, 1997Meijler y Engel, 1997

Herramientas visualesHerramientas visuales Enfoque de mayor aceptación actualmenteEnfoque de mayor aceptación actualmente Notaciones visuales para representar componentes, Notaciones visuales para representar componentes,

conectores y enlacesconectores y enlaces Tendencia: Complementar con LDAsTendencia: Complementar con LDAs

9

Extensión de MTs

Atendiendo a la forma en que un MT puede Atendiendo a la forma en que un MT puede ser extendido podemos clasificar éstos en:ser extendido podemos clasificar éstos en: MTs de caja de cristalMTs de caja de cristal MTs de caja blancaMTs de caja blanca MTs de caja negraMTs de caja negra MTs de caja grisMTs de caja gris

10

Ejemplo de MT: MultiTelClassEvent

type : Stringfrom : Stringargs : Object[]

Component

usp : LocalUSPtype : String

event (e : ClassEvent)SetLocalUSP (usp : LocalUSP)

Componente

•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);•...

•}•...•}

11

MultiTel: Conectores

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) {} }

Statesender : Pid

start ()

SConn_State1

Event1 ()Event2 ()

SConn_State2

Event3 ()Event4 ()

Connector

catchEvent (e : ClassEvent)

SConn_Prot

Event1 ()

... ...

...

Conector

Paquete reflective de Java

Patrón de diseño State

12

MultiTel: Conectores•package •mtsb.vc;

•public •class SSchedMPTU1_Idle •extends SSchedMPTU1_Prot{

•public SSchedMPTU1_Idle(•LocalUSP •usp){•super(•usp);

•}

•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};•sendMessage(•scheduler•,"turnRequest",arg);

•}

•public •State •takeTurn(){•Object[] •arg={•usp.user};•s•endMessage("•VirtualConnection","emit",arg);•return (•State) •new SSchedMPTU1_Speaking(•usp);

•}

•...•}

•Connector

•State •state;

•catchEvent(•ClassEvent e)

13

MultiTel: Composición dinámica de componentes y conectores

C3P

USPP1,P2,cc1,cc2 =CA

cc1=Access

P1=Participant

AS

Búsqueda del contextoglobal

Event(e) catchEvent(e)

Composicióndinámica

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....

}

14

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•}

•...•}

15

Clasificación De Los Marcos De Trabajo (I) Horizontales:Horizontales:

Infraestructuras de comunicacionesInfraestructuras de comunicaciones Interfaces de usuarioInterfaces de usuario Entornos visualesEntornos visuales Plataformas de componentes distribuidos, etcPlataformas de componentes distribuidos, etc

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

16

Clasificación De Los Marcos De Trabajo (II)

Software de baseSoftware de base Infraestructuras de comunicacionesInfraestructuras de comunicaciones Plataformas de componentesPlataformas de componentes

GeneralesGeneralesProgramación de GUIsProgramación de GUIsEntornos de programación visualEntornos de programación visualProgramación de redesProgramación de redes

De EmpresaDe Empresa específicos de un dominio, a medidaespecíficos de un dominio, a medida

17

Components Frameworks Específicos para el desarrollo de Específicos para el desarrollo de

aplicaciones basadas en componentes aplicaciones basadas en componentes reutilizablesreutilizables

Presentan características especiales:Presentan características especiales:Composición tardía, interconexión Composición tardía, interconexión

dinámica, extensibilidad dinámica, extensibilidad black-boxblack-box, etc, etc Suelen definirse como implementación Suelen definirse como implementación

concreta de varios patrones de diseño sobre concreta de varios patrones de diseño sobre una plataforma de componentes concretauna plataforma de componentes concreta

18

¿ Cuándo resulta conveniente definir un MT ?

Mercado competitivoMercado competitivo Plazos de desarrollo muy cortosPlazos de desarrollo muy cortos Dominio de aplicación complejoDominio de aplicación complejo Solucionar problemas repetitivosSolucionar problemas repetitivos

Ej: aplicaciones multimedia distribuidasEj: aplicaciones multimedia distribuidas

19

Interacción de MTs

ProblemasProblemas Cohesión entre las clases de un MTCohesión entre las clases de un MT Solapamiento de dominioSolapamiento de dominio Falta de estándares de MTFalta de estándares de MT

SolucionesSoluciones Adaptadores o Adaptadores o wrapperswrappers Patrones de diseñoPatrones de diseño Mediadores softwareMediadores software

20

Patrones de Diseño(Design Patterns)

Complementarios con los MTComplementarios con los MT Granularidad más fina que los MTGranularidad más fina que los MT Un MT suele estar compuesto por una Un MT suele estar compuesto por una

colección de patrones de diseño.colección de patrones de diseño.

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

21

Ventajas e Inconvenientes Ventajas:Ventajas:

Permiten reutilizar soluciones de problemas Permiten reutilizar soluciones de problemas comunes.comunes.

Están probados y son lo suficientemente Están probados y son lo suficientemente flexibles para adaptarse a necesidades flexibles para adaptarse a necesidades específicas.específicas.

Inconvenientes:Inconvenientes: Su elevado número (falta de catalogación).Su elevado número (falta de catalogación). Su complejidad.Su complejidad. Composición poco definida.Composición poco definida.

22

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

Peticion()

Adapter

Peticion()

Servidor

OtraPeticion()

p.OtraPeticion()

23

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

Operacion()

OperacionRedefinida

Implementacion

OperacionImpl()

ImplementaA

OperacionImpl()

ImplementaB

OperacionImpl()

imp.OperacionImpl()

24

Bibliografía M. Fayad, R. Johnson y D. SchmidtM. Fayad, R. Johnson y D. Schmidt, Building Application , Building Application

Framework, Framework, Wiley & Sons, 1999.Wiley & Sons, 1999. M. Fayad, R. Johnson y D. SchmidtM. Fayad, R. Johnson y D. Schmidt, Implementing Application , Implementing Application

Frameworks, Frameworks, Wiley & Sons, 1999.Wiley & Sons, 1999. M. Fayad y R. JohnsonM. Fayad y R. Johnson, Domain-Specific Application , Domain-Specific Application

Frameworks, Frameworks, Wiley & Sons, 1999.Wiley & Sons, 1999. M. Fayad, Object-Oriented Application Frameworks, M. Fayad, Object-Oriented Application Frameworks,

Communications of the ACMCommunications of the ACM, Vol. 40, No. 10, Octubre 1997., Vol. 40, No. 10, Octubre 1997.

E. Gamma et. al., E. Gamma et. al., Design PatternsDesign Patterns, Addison-Wesley, 1995., Addison-Wesley, 1995.

J. Bosch, Design Patterns & Frameworks: On the Issue of J. Bosch, Design Patterns & Frameworks: On the Issue of Language Support, Actas del Workshop “Language Support Language Support, Actas del Workshop “Language Support for Design Patterns and Frameworks” del ECOOP’97.for Design Patterns and Frameworks” del ECOOP’97.

25

Bibliografía M. Mattsson, J. Bosch y M. FayadM. Mattsson, J. Bosch y M. Fayad, , Framework Integration, Framework Integration,

problems, causes, solutions, problems, causes, solutions, Communication of the ACMCommunication of the ACM, Vol. 42, , Vol. 42, no. 10, octubre 1999.no. 10, octubre 1999.

G. Odenthal y K. Quibeldey-Cirkel, Using Patterns for Design and G. Odenthal y K. Quibeldey-Cirkel, Using Patterns for Design and Documentation, Documentation, actas del ECOOP’97actas del ECOOP’97, pp.511-529, 1997., pp.511-529, 1997.

D. Schmidt, A Family of Design Patterns For Flexibly Configuring D. Schmidt, A Family of Design Patterns For Flexibly Configuring Network Services in Distributed Systems, Network Services in Distributed Systems, actas del ICCDS’96actas del ICCDS’96, , 1996.1996.

A. Deimel, The SAP R/3 Business Framework, A. Deimel, The SAP R/3 Business Framework, software - Concepts software - Concepts & Tools& Tools, Vol. 19, pp.29-36, 1998., Vol. 19, pp.29-36, 1998.

Research on Design Patterns for Concurrent, Parallel, and Research on Design Patterns for Concurrent, Parallel, and Distributed Systems. Distributed Systems. http://siesta.http://siesta.cscs..wustlwustl..eduedu/~/~schmidtschmidt//patternspatterns..htmlhtml

http://http://hillsidehillside..netnet//patternspatterns// http://http://hillsidehillside..netnet//patternspatterns//booksbooks//