2ª Parte: Marcos de Trabajo



Descargar 20,92 Kb.
Fecha de conversión02.07.2017
Tamaño20,92 Kb.

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

Contenido:

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

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

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

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

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

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)

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

Extensión de MTs

  • Atendiendo a la forma en que un MT puede ser extendido podemos clasificar éstos en:

Ejemplo de MT: MultiTel

  • ClassEvent
  • type : String
  • from : String
  • args : Object[]
  • Component
  • usp :
  • LocalUSP
  • type : 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);
  • ...
  • }
  • ...
  • }

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

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)

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
  • 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
  • USP r=getRemoteUSP(remoteusp);
  • if(r.isThisConnector(to).booleanValue()){
  • transmitEvent(remote,to,renamed);
  • }
  • else // URL
  • ....
  • }

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

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.

Clasificación De Los Marcos De Trabajo (II)

  • Software de base
    • Infraestructuras de comunicaciones
    • Plataformas de componentes
  • Generales
    • Programación de GUIs
    • Entornos de programación visual
    • Programación de redes
  • De Empresa
    • específicos de un dominio, a medida

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

¿ 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

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

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

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.

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

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

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.

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/


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal