Transcript Servicios Avanzados Multimedia Basados en Componentes

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
[email protected]
Raúl Monge
Departamento de Informática
Universidad Técnica Federico Santa María. Chile
[email protected]
Contenido Global del Curso:
Arquitecturas de Software
 Marcos de Trabajo (Frameworks)
 Programación orientada a Componentes

2
1ª Parte:
Arquitecturas 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
[email protected]
Contenido
Estilos Arquitectónicos
 Lenguajes de Descripción de Arquitecturas
 Programación Orientada a Componentes

4
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

5
Sistemas Abiertos
Concurrentes
 Reactivos
 Independientemente extensibles
 Heterogéneos
 Evolutivos
 Distribuidos

6
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

7
Arquitectura del Software
AS

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)
8
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)
9
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
10
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.
11
Arquitectura
Productor/Consumidor
Emisor
Buffer
Receptor
12
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

13
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

14
El “territorio” de las AS
Adaptado de P. Kruchten, B. Selic, W. Kozaczynski. “Describing Software Architecture with UML”, 2001
15
Modelo, Vista y Punto de Vista

Modelo (model)


Vista (view)



Una descripción completa de un sistema a un
determinado nivel de abstracción
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
16
Niveles de Abstracción

Estilos arquitectónicos


Modelos y arquitecturas de referencia


arquitectura reutilizable en aplicaciones de un mismo dominio
Familias y líneas de productos


particularizan un estilo y definen los conceptos asociados
Marcos de Trabajo


familias de sistemas que siguen el mismo patrón estructural
arquitectura de una aplicación con diferentes configuraciones
Instancias

arquitectura de una aplicación concreta
17
Estilos Arquitectónicos

Componentes


Conectores


invariantes del estilo
Mecanismos de control


mecanismos de interacción entre componentes
Patrones y restricciones de interconexión


unidades computacionales y de datos
coordinación entre componentes
Propiedades

ventajas e inconvenientes
18
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
19
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
20
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
21
Descripción de Arquitecturas

Diagramas informales de cajas y líneas
•

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)
•

Imprecisos, ambiguos y no analizables
Implican un determinado mecanismo de interacción
UML como notación arquitectónica
Lenguajes de Descripción de Arquitectura (LDAs)
22
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)

23
Arquitectura
Productor/Consumidor
Sender
storage
Enlaces
puertos/roles ¿
analizables ?
Puertos: describen
el comportamiento
de las componentes
Receiver
Buffer
retrieval reader
Roles: describen el
comportamiento
de los conectores
24
Requisitos de un ADL

Composición


Configuración


Debe permitir reutilizar componentes, conectores, y arquitecturas
Heterogeneidad


Debe describir los roles abstractos que juegan los componentes
Reutilización


Debe describir la arquitectura independientemente de los componentes
Abstracción


Debe describir el sistema como una composición de partes
Debe permitir combinar descripciones heterogéneas
Análisis

Debe permitir diversas formas de análisis de la arquitectura
25
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
26
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
27
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
28
Ejemplos de LDAs : RAPIDE
type Application is interface
extern action Receive(p:params); // evento de entrada
public action Results(p:params); // evento de salida
behaviour
(?M in String) Receive(?M) => 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 i:Integer 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;
29
Ejemplos de LDAs : Darwin
cabeza : Filtro
entrada
ant
cauce : Pipeline
sig
salida
entrada
salida
: Pipeline
salida
30
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
31
Lenguajes de especificación de servicios
LDC: Componentes
Propagación de eventos
 Interfaz

Tipo
Atributos
Mensajes + eventos
Componente: Tipo
Atributos
Método()----->
32
Lenguajes de especificación de servicios
LDC: Componentes
def component DoM(fich:”String”)
propagates
listMovies(list-movies=”List”)
end
interface is
type File
fich:”String”
getlistMovies(category=”String”)
throws listMovies(list-movies=”List”)
end
enddef DoM
33
Lenguajes de especificación de servicios
LDC: Conectores

Parametrización
 Componentes participantes
Gestión de eventos
Relación de uso
Conector
componente,
set(componente)
Protocolo
Tipo ASTM
Protocolo en TDF
34
Lenguajes de especificación de servicios
LDC: Conectores
def connector MSelector(newphase:component)
handles
listMovies(list-movies=”List”),service(movie=”String”)
service(category-movie=”Command”)
end
messages
DoM.getlistMovies(category=”String”)
Participant.initService(panel=”DoMpanel”)
Participant.displayService(data=”List”)
Participant.service(command=”Command”)
end
protocol is
type Service
std(SDL) {...}
end
enddef MSelector
35
Lenguajes de especificación de servicios
LDS: Conexiones

Conexiones
 En base a eventos
 Instanciación de la relación de uso
Adaptar componentes
a conectores
Renombrar
métodos y
eventos
36
Lenguajes de especificación de servicios
LDS: Conexiones
participant
scaccess1
subscribed,
non-subscribed
access(params)
Participant
getAccessParams() -->
joinResponse()
join() ------------------->
acdb
SCAccess
ACDB: File
<--------- checkAccess()
join
(scaccess1 : SCAccess(nombre))
scaccess1[acdb] to participant with {access(params), join}
acdb
with {subscribed,non-subscribed};
37
Lenguajes de especificación de servicios
LCF


Organización de servicios genéricos
Servicio de organización común
ConfiguratedDataBase:File
readParameter() ------>
readLocation() -------->
close()
VoD genérico
Organización
ConfiguratedService:File
addFile()
addParties()
addLocation()
addParameter()
close()
VoD versión1
38
Lenguajes de especificación de servicios
LCF
Tipo de servicio
Asignación de nombres lógicos a físicos
Configuración de parámetros globales
Clases de componentes y conectores
set parties unicast
set msap <url>
set movie remote
set participant local
put text “Fich.clientes” parname acdb::acdbfich value=””
put text “Tipo acceso” implementation scaccess value=””
39
Un ejemplo en LEDA (I)
component Buffer
{
interface
storage : Storage;
retrieval : Retrieval;
}
role Storage(put)
{ spec is
put?(x).Storage(put)
}
role Retrieval(get)
{ spec is
get?(item,empty).
. (x) item!(x). Retrieval(get)
+
. empty!(). Retrieval(get);
}
40
Un ejemplo en LEDA (II)
component Sender
{
interface
writer : Writer;
}
component Receiver
{
interface
reader : Reader;
}
role Writer(write)
{ spec is
(data) write!(data). Writer(write);
}
role Reader(read)
{ spec is
(return,empty) read!(return,empty).
( return?(item).Reader(read)
+ empty?().Reader(read) );
}
41
Un ejemplo en LEDA (III)
component ProducerConsumer
{ interface
...
composition
p: Sender;
c: Receiver;
b: Buffer;
attachments
p.writer(write) <> b.storage(write);
b.retrieval(read) <> c.reader(read);
}
42
Lenguajes de especificación de servicios
LDS

Parámetros globales
Configuración con
LCF
Componentes
simples
conjunto
lista de tipos
components
chair
: Manager(name)
audience : set(Participant)
===>
devices
: {TextualChat,FileMovie}
end
item(audience)
43
Comparación de LDAs
Entidades
Dinamismo Verificación
Propiedades
Desarrollo
Reutilizac.
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
Herencia
Restricciones
Simul./
Gen.Cod.
LDS
Comp/Con
Sí
Posible
Extensión
Gen.Cod.
LEDA
Comp
Sí
Compat./Ext.
Ext./Gener. Simul./
Gen.Cod.
44
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
45
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


Tiempo de Diseño


Elementos para generar una aplicación a partir de
COTS
Interfaces funcionales y dependencias de
componentes
Tiempo de Ejecución

Servicios de composición dinámica en runtime
46
AS: problemas y líneas abiertas
1.
2.
3.
4.
5.
6.
Definición de AS
Expresión de parámetros de calidad
Medidas
Herramientas
Relación con el dominio de aplicación
‘Vistas’ arquitectónicas
47
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”
48
P2. Parámetros de Calidad

Actualmente no se tienen en cuenta.



Propios del tiempo de ejecución (dinámicos):


“...ilities”: portability, traceability,...
“...nesses”: correcness, robustness, ...
Performance, security, availability, functionality,
usability, etc.
Intrínsecos a la AS (estáticos):

Modifiability, portability, reusability, integrability,
testability, etc.
49
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

50
P4. Herramientas
Diseño
 Documentación
 Pruebas
 Análisis de propiedades (formales)
 Generación de código/prototipos

51
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

52
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
53
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):269–274.

D. Garlan, R. Allen y J. Ockerbloom (1995), Architectural
Mismatch: Why Reuse is So Hard, IEEE Software, Nov. 1995,
pp. 17–26.

I. Jacobson, G. Booch y J. Rumbaugh (1999), The Unified
Software Development Process, Addison-Wesley
54
Bibliografía

D. Krieger y R. M. Adler (1998), The Emergence of
Distributed Component Platforms, IEEE Computer, March
1998, pp. 43–53.

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. 336–
355.

J. Magee y J. Kramer (1996), Dynamic Structure in Software
Architectures, Software Engineering Notes, vol. 21, no. 6,
Nov. 1996, pp. 3–14.

N. Medvidovic y D. Rosenblum (1997), A Framework for
Classifying and Comparing Architecture Description
Languages, Proc. ESEC/FSE, LNCS, Springer, pp. 60–76.
55
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.
314–334.

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. 52–61.

C. Szyperski (1998), Component Software: Beyond ObjectOriented Programming, Addison-Wesley.

A.W. Brown and K.C. Wallnau, The Current State of CBSE,
IEEE Software, Sept/Oct. 1998
56