2ª Parte: Marcos de Trabajo

1. 2ª Parte:Marcos de Trabajo 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 av@lcc.uma.es

2. Contenido: • Marcos de trabajo (Frameworks) orientados a objetos y a componentes • Clasificación de los MTs • Patrones de Diseño: su utilidad

3. Marcos de Trabajo(ApplicationFrameworks) • 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 • Define interfaces de componentes • Establece reglas de interacción entre ellos • Implementa alguno de los componentes • El usuario encaja sus componentes en el marco

5. Orientado a objetos (C++, Java) • Composicional Diseño del MT 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

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 • 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: • MTs de caja de cristal • MTs de caja blanca • MTs de caja negra • MTs de caja gris

10. 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( • 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 Conector Connector State sender : Pid catchEvent (e : ClassEvent) start () ... ... 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) {} } SConn_Prot Event1 () ... SConn_State2 SConn_State1 Event3() Event1 () Event4 () Event2 () Patrón de diseño State Paquete reflective de Java

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

13. 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 .... } Event(e) catchEvent(e) Composición dinámica MultiTel: Composición dinámica de componentes y conectores cc1=Access P1=Participant AS USP P1,P2,cc1,cc2 =CA Búsqueda del contexto global C3P

14. Extensión de MultiTel: programación de un servicio • public • class • TeleUni • extends • ServiceUSP{ • defComponents • public • void • (){ • 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"); • ... • } • defConnectors • public • void • (){ • connector(" • SCAccess",{" • participant,local","manager,remote"},"mtsb.vc.SCAccess1"); • connector(" • SMAccess",{" • participant,remote","manager,local"},"mtsb.vc.SMAccess1"); • ... • } • loadConnections • public • void • (){ • String[] events1={" • join"}; • handlesEventsFrom("SMAccess",events1,"Manager"); • String[] events2={" • access"}; • handlesEventsFrom("SCAccess",events2,"Participant"); • ... • } • participantInitialContext • public • void • (){ • try{ • createComponent(" • Participant,SCAccess"); • } • catch( • Exception e){ • System.out.println(" • InitialContext Error"); } • } • managerInitialContext • public • void • (){ • 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 • } • ... • }

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

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

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 • Plazos de desarrollo muy cortos • Dominio de aplicación complejo • Solucionar problemas repetitivos Ej: aplicaciones multimedia distribuidas

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

20. Patrones de Diseño(Design Patterns) • 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. • 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: • 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.

22. cliente Destino Servidor Peticion() OtraPeticion() Adapter Peticion() p.OtraPeticion() 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

23. Abstraccion Implementacion Operacion() OperacionImpl() imp.OperacionImpl() ImplementaA ImplementaB OperacionRedefinida OperacionImpl() OperacionImpl() 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

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

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