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 2ª Parte: Marcos de Trabajo

2 Contenido: Marcos de trabajo (Frameworks) orientados a objetos y a componentes Marcos de trabajo (Frameworks) orientados a objetos y a componentes Clasificación de los MTs Clasificación de los MTs Patrones de Diseño: su utilidad Patrones 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ón Arquitectura especializada para un dominio de aplicación Define interfaces de componentes Define interfaces de componentes Establece reglas de interacción entre ellos Establece reglas de interacción entre ellos Implementa alguno de los componentes Implementa alguno de los componentes El usuario encaja sus componentes en el marco El usuario encaja sus componentes en el marco

5 Desarrollo de Software basado en MTs Ventajas: Ventajas:  Aumenta la reutilización  Minimiza riesgos  Reducción de los costes de producción  Mejora de la calidad final del producto è Orientado a objetos (C++, Java) è Composicional Diseño del MT

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

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

8 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

9 Extensión de MTs Atendiendo a la forma en que un MT puede ser extendido podemos clasificar éstos en: 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

10 Ejemplo de MT: MultiTel ClassEvent type : String from : String args : Object[] Component usp :LocalUSP type : String event (e :ClassEvent) SetLocalUSP (usp :LocalUSP) Componente publicclassVCManagerextendsComponent { publicvoidshowSchedControl(){ if(sched==null){ try{ sched=newScheduleFrame(usp,this); sched.show(); }catch(Exception e){ System.out.println("Exception"+e); e.printStackTrace(); } } } publicvoidturnRequest(Stringuser){ message("User "+user+" hasrequestedtheturn"); Objectargs[]={user}; if (/*Managerdecision */) 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) {} } State sender : 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 packagemtsb.vc; publicclass SSchedMPTU1_Idleextends SSchedMPTU1_Prot{ public SSchedMPTU1_Idle(LocalUSPusp){ super(usp); } publicvoidstart(){ sendMessage("Manager","showSchedControl"); sendMessage("Manager","showClassControl"); broadcast(“Participant”,”initTurn”); } publicvoidturnRequest(Stringuser){ message("User "+user+" hasrequestedtheturn"); Objectarg[]={user}; sendMessage( scheduler,"turnRequest",arg); } publicStatetakeTurn(){ Object[]arg={usp.user}; sendMessage("VirtualConnection","emit",arg); return (State)new SSchedMPTU1_Speaking(usp); }... } Connector Statestate; catchEvent(ClassEvent e)

13 MultiTel: Composición dinámica de componentes y conectores C3P USP P1,P2,cc1,cc2 =CA cc1=Access P1=Participant AS Búsqueda del contexto global Event(e)catchEvent(e) Composición diná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 publicclassTeleUniextendsServiceUSP{ publicvoid 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");... } publicvoid defConnectors (){ connector("SCAccess",{"participant,local","manager,remote"},"mtsb.vc.SCAccess1"); connector("SMAccess",{"participant,remote","manager,local"},"mtsb.vc.SMAccess1");... } publicvoid loadConnections (){ String[] events1={"join"}; handlesEventsFrom("SMAccess",events1,"Manager"); String[] events2={"access"}; handlesEventsFrom("SCAccess",events2,"Participant");... } publicvoid participantInitialContext (){ try{ createComponent("Participant,SCAccess"); }catch(Exception e){System.out.println("InitialContext Error"); } } publicvoid managerInitialContext (){ try{ createComponent("Manager, ACDB,SMAccess, SSchedMP,..."); }catch(Exception e){ System.out.println("InitialContext Error ");e.printStackTrace();} } publicvoid loadOrganizationParameters (){ // Loadvalueforthe "scheduler"parameterof SSchedMPconnector }... }

15 Clasificación De Los Marcos De Trabajo (I) Horizontales: Horizontales:  Infraestructuras de comunicaciones  Interfaces de usuario  Entornos visuales  Plataformas de componentes distribuidos, etc Verticales: Verticales:  Telecomunicaciones (TINA, MultiTEL)  Fabricación  Multimedia (JMF), etc.

16 Clasificación De Los Marcos De Trabajo (II) Software de base Software de base  Infraestructuras de comunicaciones  Plataformas de componentes Generales Generales  Programación de GUIs  Entornos de programación visual  Programación de redes De Empresa De Empresa  específicos de un dominio, a medida

17 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

18 ¿ Cuándo resulta conveniente definir un MT ? Mercado competitivo Mercado competitivo Plazos de desarrollo muy cortos Plazos de desarrollo muy cortos Dominio de aplicación complejo Dominio de aplicación complejo Solucionar problemas repetitivos Solucionar problemas repetitivos Ej: aplicaciones multimedia distribuidas

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

20 Patrones de Diseño (Design Patterns) Complementarios con los MT Complementarios con los MT Granularidad más fina que los MT Granularidad más fina que los MT Un MT suele estar compuesto por una colección de patrones de diseño. Un MT suele estar compuesto por una 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 comunes.  Están probados y son lo suficientemente flexibles para adaptarse a necesidades específicas. Inconvenientes: Inconvenientes:  Su elevado número (falta de catalogación).  Su complejidad.  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 clienteDestino 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. Schmidt, Building Application Framework, Wiley & Sons,  M. Fayad, R. Johnson y D. Schmidt, Implementing Application Frameworks, Wiley & Sons,  M. Fayad y R. Johnson, Domain-Specific Application Frameworks, Wiley & Sons,  M. Fayad, Object-Oriented Application Frameworks, Communications of the ACM, Vol. 40, No. 10, Octubre  E. Gamma et. al., Design Patterns, Addison-Wesley,  J. Bosch, Design Patterns & Frameworks: On the Issue of Language Support, Actas del Workshop “Language Support for Design Patterns and Frameworks” del ECOOP’97.

25 Bibliografía  M. Mattsson, J. Bosch y M. Fayad, Framework Integration, problems, causes, solutions, Communication of the ACM, Vol. 42, no. 10, octubre  G. Odenthal y K. Quibeldey-Cirkel, Using Patterns for Design and Documentation, actas del ECOOP’97, pp ,  D. Schmidt, A Family of Design Patterns For Flexibly Configuring Network Services in Distributed Systems, actas del ICCDS’96,  A. Deimel, The SAP R/3 Business Framework, software - Concepts & Tools, Vol. 19, pp.29-36,  Research on Design Patterns for Concurrent, Parallel, and Distributed Systems.  