Upload
rodolfo-navarro
View
1
Download
0
Embed Size (px)
Citation preview
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
[email protected]@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//