Servicios Avanzados Multimedia Basados en Componentes
Download
Report
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