Desarrollo de Aplicaciones basado en Componentes y Frameworks

1
Desarrollo de Aplicaciones basado en Componentes
y Frameworks

• 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
• Raúl Monge
• Departamento de Informática
• Universidad Técnica Federico Santa María. Chile
• rmonge_at_inf.utfsm.l

2
Contenido Global del Curso

• Arquitecturas de Software
• Marcos de Trabajo (Frameworks)
• Programación orientada a Componentes

3
1ª ParteArquitecturas del Software

• 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

4
Contenido

• Estilos Arquitectónicos
• Lenguajes de Descripción de Arquitecturas
• Programación Orientada a Componentes

5
Introducción

• Sistemas Abiertos
• Características y Problemática
• Estilos Arquitectónicos
• Lenguajes de Descripción de arquitecturas
• Ingeniería del Software basada en Componentes
  (CBSE)
• Arquitectura Software y COTS

6
Sistemas Abiertos

• Concurrentes
• Reactivos
• Independientemente extensibles
• Heterogéneos
• Evolutivos
• Distribuidos

7
Problemas específicos

• Gestión de la evolución (del sistema y de sus
  componentes)
• Compatibilidad de componentes
• Falta de visión global del sistema
• Dificultad para garantizar la seguridad
• Retrasos y errores en las comunicaciones
• Fallos y errores en los propios componentes

8
Arquitectura del Software

• Estructura de los componentes de un programa o
  sistema, sus interrelaciones, y los principios y
  reglas que gobiernan su diseño y evolución en el
  tiempo.
• (Garlan y Perry, 1995)
• Estructura o estructuras de un sistema, lo que
  incluye sus componentes software, las propiedades
  observables de dichos componentes y las
  relaciones entre ellos.
• (Bass, Clements y Kazman, 1998)

9
Disciplina

• Nivel del diseño del software donde se definen la
  estructura y propiedades globales del sistema.
• (Garlan y Perry, 1995)
• La Arquitectura del Software se centra en
  aquellos aspectos del diseño y desarrollo que no
  pueden tratarse de forma adecuada dentro de los
  módulos que forman el sistema.
• (Shaw y Garlan, 1996)

10
Caracterización

• Arquitectura vs. Algoritmos Datos
• organización del sistema
• Interacción de componentes vs. Definición/uso
• componentes y conectores
• Estilo Arquitectónico vs. Instancia
• restricciones en la forma de una familia de
  instancias
• Arquitectura vs. Métodos de Diseño
• espacio de diseños arquitectónicos

11
Descripción de una AS

• Representación de alto nivel de la estructura de
  un sistema o aplicación, que describe
• partes que la integran,
• interacciones entre ellas,
• patrones que supervisan su composición, y
• restricciones para aplicar dichos patrones.

12
Arquitectura Productor/Consumidor
13
Objetivos de la AS

• Comprender y manejar la estructura de las
  aplicaciones complejas
• Reutilizar dicha estructura (o parte de ella)
• Planificar la evolución de la aplicación
• Analizar la corrección de la aplicación y su
  grado de cumplimiento frente a los requisitos
  iniciales
• Permitir el estudio de propiedades específicas

14
Ventajas de las A.S.

• Resaltan aquellos aspectos estucturalmente
  importantes, tanto funcionales como no
  funcionales
• Eliminan muchos riesgos y errores de diseño,
  desarrollo e implantación
• Permiten un desarrollo paralelo, aumentando la
  productividad

15
El territorio de las AS
Adaptado de P. Kruchten, B. Selic, W.
Kozaczynski. Describing Software Architecture
with UML, 2001
16
Modelo, Vista y Punto de Vista

• Modelo (model)
• Una descripción completa de un sistema a un
  determinado nivel de abstracción
• Vista (view)
• Una proyección de un modelo desde una perspectiva
• Omite las entidades y elementos que no son
  relevantes
• Punto de vista (viewpoint)
• La definición (o descripción) de una vista
• Prescribe su contenido, significado y
  representación

17
Niveles de Abstracción

• Estilos arquitectónicos
• familias de sistemas que siguen el mismo patrón
  estructural
• Modelos y arquitecturas de referencia
• particularizan un estilo y definen los conceptos
  asociados
• Marcos de Trabajo
• arquitectura reutilizable en aplicaciones de un
  mismo dominio
• Familias y líneas de productos
• arquitectura de una aplicación con diferentes
  configuraciones
• Instancias
• arquitectura de una aplicación concreta

18
Estilos Arquitectónicos

• Componentes
• unidades computacionales y de datos
• Conectores
• mecanismos de interacción entre componentes
• Patrones y restricciones de interconexión
• invariantes del estilo
• Mecanismos de control
• coordinación entre componentes
• Propiedades
• ventajas e inconvenientes

19
Clasificación de estilos

• Sistemas de flujo de datos
• Sistemas basados en llamada y retorno
• Sistemas de componentes independientes
• Sistemas centrados en los datos
• Máquinas virtuales
• Sistemas heterogéneos

20
Estilos y subestilos (I)

• Sistemas de flujo de datos
• Sucesión de transformaciones de los datos de
  entrada
• Subestilos pipe filter y procesamiento por
  lotes
• Sistemas basados en llamada y retorno
• Reflejan la estructura del lenguaje de
  programación
• Subestilos programa principal-subrutina, OO,
  capas
• Sistemas de componentes independientes
• Componentes distribuidos que se comunican por
  paso de mensajes
• Subestilos sistemas cliente/servidor y de eventos

21
Estilos y subestilos (II)

• Sistemas centrados en los datos
• Acceso compartido a un banco de datos central
• Subestilos repositorio y pizarras (blackboards)
• Máquinas virtuales
• Simulan una funcionalidad no nativa del entorno
• Subestilos intérpretes y sistemas basados en
  reglas
• Sistemas heterogéneos
• Localmente, jerárquicamente o simultáneamente
  heterogéneos

22
Descripción de Arquitecturas

• Diagramas informales de cajas y líneas
• Imprecisos, ambiguos y no analizables
• Lenguajes de programación modular
• Mezclan aspectos de programación y estructurales
• El análisis se basa en emparejamiento de nombres
• Lenguajes de interconexión de módulos (MILs o
  IDLs)
• Implican un determinado mecanismo de interacción
• UML como notación arquitectónica
• Lenguajes de Descripción de Arquitectura (LDAs)

23
Lenguajes de Descripción de Arquitecturas (LDAs)

• Un LDA es un lenguaje o notación para describir
  una arquitectura software
• Descripción de componentes, conectores y enlaces
  entre ellos.
• Herramientas para la verificación de la
  arquitectura y el prototipado rápido.
• Existen LDAs de propósito general y otros de
  dominio específico (DSLs)

24
(No Transcript)
25
Requisitos de un ADL

• Composición
• Debe describir el sistema como una composición de
  partes
• Configuración
• Debe describir la arquitectura independientemente
  de los componentes
• Abstracción
• Debe describir los roles abstractos que juegan
  los componentes
• Reutilización
• Debe permitir reutilizar componentes, conectores,
  y arquitecturas
• Heterogeneidad
• Debe permitir combinar descripciones heterogéneas
• Análisis
• Debe permitir diversas formas de análisis de la
  arquitectura

26
Ejemplos de LDAs

• Ejemplos
• UNICON (Shaw et al. 1995)
• Rapide (Luckham et al. 1995)
• Darwin (Magee y Kramer, 1996 1999)
• Wright (Allen y Garlan, 1997 1998)
• Executable Connectors (Ducasse y Richner, 1997)
• Problema No cubren todo el ciclo de vida de las
  aplicaciones software (sólo diseño preliminar),
  no llegan a la implementación

27
Ejemplos de LDAs UNICON

• Una pipe de Unix
• connector Unix-pipe
• protocol is
• type pipe
• role source is Source
• MaxConns(1)
• end source
• role sink is Sink
• MaxConns(1)
• end sink
• end protocol

• ...
• implementation is
• builtin
• end implementation
• end Unix-Pipe

28
Ejemplos de LDAs Wright

• Una pipe de Unix
• connector Pipe
• role WRITER write ? WRITER ? close ? ?
• role READER let ExitOnly close ??
• in let DoRead (read ? READER ? readEoF ?
  ExitOnly
• in DoRead ? ExitOnly
• glue let ReadOnly READER.read ? readOnly
• ? READER.readEoF ? READER.close ??
• ? READER.close ??
• in let WriteOnly WRITER.write ? WriteOnly ?
  WRITER.close??
• in WRITER.write ? glue ? READER.read ? glue
• ? WRITE.close ? ReadOnly ? READER.close
  ? WriteOnly

29
Ejemplos de LDAs RAPIDE

• type Application is interface
• extern action Receive(pparams) // evento de
  entrada
• public action Results(pparams) // evento de
  salida
• behaviour
• (?M in String) Receive(?M) gt Results(?M) //
  transición de eventos
• end Application
• architecture DistrApp(Num Integer) return
  InterfaceDistrApp is
• P array(Integer) of Application
• Q array(Integer) of Resource //Dual of
  Application
• connect
• for iInteger in 1..Num generate
• (?M in String) P(i). Receive(?M) to
  Q(i).Results(?M)
• P(i).Results(?M) to
  Q(i). Receive(?M)
• end generate
• end DistrApp

30
Ejemplos de LDAs Darwin
31
LDAs del grupo GISUM

• LDC LDS (Fuentes y Troya, 1998)
• Modelo de componentes pasivos y conectores
  reactivos
• Formalismo de especificación de comportamiento de
  conectores (TDFs, ?-cálculo, etc.)
• LEDA (Canal, Pimentel y Troya, 2000)
• Basado en el álgebra de procesos ?-cálculo
• Permite especificar arquitecturas dinámicas

32
LDC Componentes
Lenguajes de especificación de servicios

• Propagación de eventos
• Interfaz

33
LDC Componentes
Lenguajes de especificación de servicios
def component DoM(fichString) propagates li
stMovies(list-moviesList) end interface
is type File fichString getlistMovies(
categoryString) throws
listMovies(list-moviesList) end enddef DoM
34
LDC Conectores
Lenguajes de especificación de servicios

• Parametrización
• Componentes participantes

35
LDC Conectores
Lenguajes de especificación de servicios
def connector MSelector(newphasecomponent) hand
les listMovies(list-moviesList),service(movie
String) service(category-movieCommand) en
d messages DoM.getlistMovies(categoryString)
Participant.initService(panelDoMpanel) Par
ticipant.displayService(dataList) Participant
.service(commandCommand) end protocol
is type Service std(SDL) ... end enddef
MSelector
36
LDS Conexiones
Lenguajes de especificación de servicios

• Conexiones
• En base a eventos
• Instanciación de la relación de uso

37
LDS Conexiones
Lenguajes de especificación de servicios
participant
acdb
scaccess1
(scaccess1 SCAccess(nombre)) scaccess1acdb
to participant with access(params), join
acdb with subscribed,non-subscribed
38
LCF
Lenguajes de especificación de servicios

• Organización de servicios genéricos
• Servicio de organización común

39
LCF
Lenguajes de especificación de servicios
40
Un ejemplo en LEDA (I)
component Buffer interface storage
Storage retrieval Retrieval
role Storage(put) spec is put?(x).Storage(pu
t)
role Retrieval(get) spec is
get?(item,empty). ?. (x) item!(x).
Retrieval(get) ?. empty!().
Retrieval(get)
41
Un ejemplo en LEDA (II)
component Sender interface writer Writer
role Writer(write) spec is (data)
write!(data). Writer(write)
role Reader(read) spec is (return,empty)
read!(return,empty). ( return?(item).Reader(r
ead) empty?().Reader(read) )
component Receiver interface reader
Reader
42
Un ejemplo en LEDA (III)
component ProducerConsumer interface ... comp
osition p Sender c Receiver b
Buffer attachments p.writer(write) ltgt
b.storage(write) b.retrieval(read) ltgt
c.reader(read)
43
LDS
Lenguajes de especificación de servicios

• Parámetros globales

Componentes simples conjunto lista de tipos
components chair Manager(name) audienc
e set(Participant) gt item(audience) de
vices TextualChat,FileMovie end
44
Comparación de LDAs
Entidades Dinamismo Verificación Propiedades DesarrolloReutilizac. Ejecución
UniCon Comp/Con No No No Gen.Cod.
Wright Comp/Con No Compat. No No
Darwin Comp Sí Seg./Viveza No Gen.Cod.
Rapide Comp Limitado Análisis Restricciones Herencia Simul./ Gen.Cod.
LDS Comp/Con Sí Posible Extensión Gen.Cod.
LEDA Comp Sí Compat./Ext. Ext./Gener. Simul./ Gen.Cod.
45
Arquitectura Software vs. COTS

• Arquitectura del Software
• Orientados a la reutilización independiente de
  patrones arquitectónicos y de componentes
• Modelos formales
• Tecnología desarrollada en el entorno académico
• COTS
• Componentes con interfaces estándares (IDLs)
• No aparece la noción de conector o enchufe
• Mercado global de componentes centrado en la
  reutilización de componentes
• Tecnología madura OpenDoc/CORBA, OLE/COM

46
Ingeniería del Software basada en Componentes

• Componentes unidos a una arquitectura
• Partes de la interfaz de un componente para
  soportar la noción de arquitectura
• Tiempo de Composición
• Elementos para generar una aplicación a partir de
  COTS
• Tiempo de Diseño
• Interfaces funcionales y dependencias de
  componentes
• Tiempo de Ejecución
• Servicios de composición dinámica en runtime

47
AS problemas y líneas abiertas

1. Definición de AS
2. Expresión de parámetros de calidad
3. Medidas
4. Herramientas
5. Relación con el dominio de aplicación
6. Vistas arquitectónicas

48
P1. Definición de AS

• Una AS es algo más que una descripción de la
  estructura de una aplicación
• Qué es ese algo más?
• Cómo se expresa?
• Otras definiciones alternativas de AS
• A Software Architecture is a collection of
  categories of elements that share the same
  likelihood of change. Each category contains
  software elements that exhibit shared stability
  characteristics

49
P2. Parámetros de Calidad

• Actualmente no se tienen en cuenta.
• ...ilities portability, traceability,...
• ...nesses correcness, robustness, ...
• Propios del tiempo de ejecución (dinámicos)
• Performance, security, availability,
  functionality, usability, etc.
• Intrínsecos a la AS (estáticos)
• Modifiability, portability, reusability,
  integrability, testability, etc.

50
P3. Medidas

• Necesarias para poder hablar de Ingeniería del
  Software
• Deberían estimar, de forma cuantitativa
• Tamaño
• Estructura
• Calidad del diseño
• ...
• Funcionales (estructuradas)/Orientadas a Objeto

51
P4. Herramientas

• Diseño
• Documentación
• Pruebas
• Análisis de propiedades (formales)
• Generación de código/prototipos

52
P5. Dominio de Aplicación

• Análisis de los dominios de la aplicación y de la
  solución para derivar AS
• Mejor y más estable estructura
• Mejor capacidad de evolución
• AS solución más natural e integrada en el entorno
  de la aplicación

53
P6. Vistas Arquitectónicas

• Varias vistas arquitectónicas
• Algunas técnicas, otras específicas del dominio,
  otras tecnológicas
• RM-ODP o TINA ya las definen
• Problemas consistencia e integración

54
Bibliografía

• P. Clements (1996), Coming Attractions in
  Software Architecture, Technical Report, Software
  Engineering Institute, Carnegie Mellon University
  (USA).
• P. Donohoe (Ed.) (1999), Software Architecture,
  Kluwer Academic Publishers.
• D. Garlan y D. E. Perry (1995), Introduction to
  the Special Issue on Software Architecture, IEEE
  Transactions on Software Engineering,
  21(4)269274.
• D. Garlan, R. Allen y J. Ockerbloom (1995),
  Architectural Mismatch Why Reuse is So Hard,
  IEEE Software, Nov. 1995, pp. 1726.
• I. Jacobson, G. Booch y J. Rumbaugh (1999), The
  Unified Software Development Process,
  Addison-Wesley

55
Bibliografía

• D. Krieger y R. M. Adler (1998), The Emergence of
  Distributed Component Platforms, IEEE Computer,
  March 1998, pp. 4353.
• D. Luckham et al. (1995), Specification and
  Analysis of System Architecture Using Rapide,
  IEEE Transactions on Software Engineering, vol.
  21, no. 4, April 1995, pp. 336355.
• J. Magee y J. Kramer (1996), Dynamic Structure in
  Software Architectures, Software Engineering
  Notes, vol. 21, no. 6, Nov. 1996, pp. 314.
• N. Medvidovic y D. Rosenblum (1997), A Framework
  for Classifying and Comparing Architecture
  Description Languages, Proc. ESEC/FSE, LNCS,
  Springer, pp. 6076.

56
Bibliografía

• W. Pree (1996), Framework Patterns, SIGS
  Publications.
• M. Shaw et al. (1995), Abstractions for Software
  Architecture and Tools to Support Them, IEEE
  Transactions on Software Engineering, vol. 21,
  no. 4, April 1995, pp. 314334.
• M. Shaw y D. Garlan (1996), Software
  Architecture Perspectives on an Emerging
  Discipline, Prentice Hall.
• S. Sparks et al. (1996), Managing Object-Oriented
  Framework Reuse, IEEE Computer, Sept. 1996, pp.
  5261.
• C. Szyperski (1998), Component Software Beyond
  Object-Oriented Programming, Addison-Wesley.
• A.W. Brown and K.C. Wallnau, The Current State of
  CBSE, IEEE Software, Sept/Oct. 1998