Desarrollo de Aplicaciones basado en Componentes y Frameworks (página 3)

Partes: 1, 2, 3, 4

31
LDC: Componentes
Propagación de eventos
Interfaz
(Gp:) Componente: Tipo
(Gp:) Método()—–>
(Gp:) Atributos

(Gp:) Tipo

(Gp:) Atributos

(Gp:) Mensajes + eventos

32
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
LDC: Conectores
Parametrización
Componentes participantes
(Gp:) Relación de uso

(Gp:) Gestión de eventos

(Gp:) Conector
(Gp:) componente,
set(componente)

(Gp:) Protocolo
Tipo ASTM
Protocolo en TDF

34
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
LDS: Conexiones
Conexiones
En base a eventos
Instanciación de la relación de uso
(Gp:) Renombrar
métodos y eventos

(Gp:) Adaptar componentes
a conectores

36
LDS: Conexiones
(scaccess1 : SCAccess(nombre))
scaccess1[acdb] to participant with {access(params), join}
acdb with {subscribed,non-subscribed};
(Gp:) subscribed,
(Gp:) non-subscribed
(Gp:) Participant
(Gp:) getAccessParams() –>
(Gp:) joinResponse()
(Gp:) join() ——————->
(Gp:) SCAccess
(Gp:) ACDB:
(Gp:) File
(Gp:) <——— checkAccess()
(Gp:) join
(Gp:) access(params)

participant
acdb
scaccess1

37
LCF
Organización de servicios genéricos
Servicio de organización común
(Gp:)
(Gp:) readLocation() ——–>
(Gp:)
(Gp:) close()
(Gp:) ConfiguratedDataBase:
(Gp:)
(Gp:) File
(Gp:)
(Gp:) readParameter() ——>
(Gp:) ConfiguratedService:
(Gp:)
(Gp:) File
(Gp:)
(Gp:) addFile()
(Gp:)
(Gp:) addParties()
(Gp:)
(Gp:) addLocation()
(Gp:)
(Gp:) addParameter()
(Gp:)
(Gp:) close()
(Gp:) Organización
(Gp:) VoD genérico

(Gp:) VoD versión1

38
LCF
(Gp:) Asignación de nombres lógicos a físicos
(Gp:) set msap
set movie remote
set participant local

(Gp:) Configuración de parámetros globales
(Gp:) put text “Fich.clientes” parname acdb::acdbfich value=””

(Gp:) Clases de componentes y conectores
(Gp:) put text “Tipo acceso” implementation scaccess value=””

(Gp:) set parties unicast
(Gp:) Tipo de servicio

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;
}
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) );
}
component Receiver
{
interface
reader : Reader;
}

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
LDS
Parámetros globales
Componentes
simples
conjunto
lista de tipos
components
chair : Manager(name)
audience : set(Participant) ===> item(audience)
devices : {TextualChat,FileMovie}
end
(Gp:) Configuración con LCF

43
Comparación de LDAs

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

46
AS: problemas y líneas abiertas
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.
“…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.

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