Antonio Vallecillo

1
2ª ParteMarcos 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_at_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(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
• 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
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(

• schednull)

• try

• schednew

• 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
State
Connector
sender Pid
catchEvent (e ClassEvent)
start ()
...
...
public void catchEvent(ClassEvent e) throws
Exception try synchronized(state)
Method m m(state.getClass().getMet
hod(e.type,e.args)) state(State)m.invoke(s
tate,e.args) if (statenull)
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
MultiTel Composición dinámica de componentes y
conectores
cc1Access
P1Participant
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

• 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.SCAc
  cess1")

• connector("

• SMAccess","

• participant,remote","manager,local","mtsb.vc.SMAc
  cess1")

• ...

• loadConnections

• public

• void

• ()

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

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

• 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

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

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

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 ECOOP97,
  pp.511-529, 1997.
• D. Schmidt, A Family of Design Patterns For
  Flexibly Configuring Network Services in
  Distributed Systems, actas del ICCDS96, 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/