Documentos de Académico
Documentos de Profesional
Documentos de Cultura
03 - Arquitectura de Software - Lenguajes ADL
03 - Arquitectura de Software - Lenguajes ADL
Acme
La estructura se define utilizando siete tipos
de entidades:
componentes
conectores
sistemas
puertos
roles
representaciones
rep-mapas (mapas de representacin).
Ejemplo Acme
El siguiente ejemplo define
una familia o estilo de la clase
ms simple, tubera y filtros
Ejemplo Acme
// Una familia Acme incluye un conjunto de tipos de componente,conector, puerto
//(port) y rol que definen el vocabulario propio del estilo.
Family PipeFilterFam =
{
// Declara tipos de componente.
// Una definicin de tipo de componente en Acme permite establecer la
//estructura requerida por el tipo. Esta estructura se define mediante la misma
//sintaxis que la instancia de un componente.
Component Type FilterT = {
// Todos los filtros definen por lo menos dos puertos
Ports { stdin; stdout; };
Property throughput : int;
};
Ejemplo Acme
// Extiende el tipo bsico de filtro con una subclase (herencia)
// Las instancia de WindowsFilterT tendrn todas las propiedades y puertos de las instancias de
// FilterT, ms un puerto stderr y una propiedad implementationFile.
Component Type WindowsFilterT extends FilterT with {
Port stderr;
Property implementationFile : String;
};
// Declara el tipo de conector de tubera. Igual que los tipos de componente, un tipo de conector
// tambin describe la estructura requerida.
Connector Type PipeT = {
Roles { source; sink; };
Property bufferSize : int;
};
// Declara algunos tipos de propiedad que pueden usarse en sistemas del estilo PipeFilterFam
Property Type StringMsgFormatT = Record [ size:int; msg:String; ];
Property Type TasksT = enum {sort, transform, split, merge};
};
Entornos Acme
AcmeStudio, entorno grfico.
Armani, utiliza Microsoft Visio como
front-end y un back-end Java.
AcmeLib (C++, Java)
No soporta generacin de cdigo
Ambiente de edicin de AcmeStudio con
diagrama de tubera y filtros
Ejemplo Acme ( Cliente/Servidor)
System simple_cs = {
Component client = {Port send-request}
Component server = {Port receive-request}
Connector rpc = {Roles {caller, callee}}
Attachments : {client.send-request to rpc.caller;
server.receive-request to rpc.callee}
}
Aesop: Software Architecture Design
Environment Generator
Desarrollado como parte del proyecto ABLE de la
Universidad Carnegie Mellon.
Objetivo: exploracin de las bases formales de la
arquitectura de software, el desarrollo del
concepto de estilo arquitectnico y la produccin de
herramientas tiles a la arquitectura.
ADLs - Rapide
Rapide
Desarrollado por David Luckham (Stanford)
ADL de propsito general
Su objetivo es facilitar la simulacin de eventos
Comportamientos aceptados y prohibidos
Las especificaciones Rapide son ejecutables
Lenguaje OO
Modela concurrencia
Requerimientos del sistema son expresados
como restricciones en el tiempo
ADLs - Rapide
Principales Elementos
Component
Interface Objects
Module (Implementan los Objetos Interface)
Connector
Interfaces de envo y recepcin
Los componentes se comunican a travs de conectores
Tres tipos de conecciones
Bsicas, Pipes y Agentes
Constraints
Se definen en las conecciones de la arquitectura
ADLs - Rapide
type Producer (Max : Positive) is interface
action out Send (N: Integer);
action in Reply(N : Integer);
behavior
Start => send(0);
(?X in Integer) Reply(?X) where ?X<Max => Send(?X+1);
end Producer;
type Consumer is interface
action in Receive(N: Integer);
action out Ack(N : Integer);
behavior
(?X in Integer) Receive(?X) => Ack(?X);
end Consumer
architecture ProdCon() return SomeType is
Prod : Producer(100); Cons : Consumer;
connect
(?n in Integer) Prod.Send(?n) => Cons.Receive(?n);
Cons.Ack(?n) => Prod.Reply(?n);
end architecture ProdCon;
ADLs - Wright
Desarrollado por David Garlan (CMU)
ADL de propsito general
Enfasis en anlisis de protocolos de
comunicacin
Elementos Principales
Componente
Conector
Herramientas de desarrollo limitadas
ADLs - Wright
System simple_cs
Component client =
port send-request = [behavioral spec]
spec = [behavioral spec]
Component server =
port receive-request= [behavioral spec]
spec = [behavioral spec]
Connector rpc =
role caller = (request!x -> result?x ->caller) ^ STOP
role callee = (invoke?x -> return!x -> callee) [] STOP
glue = (caller.request?x -> callee.invoke!x -> callee.return?x
-> callee.result!x-> glue) [] STOP
Instances
s : server
c : client
r : rpc
Attachments :
client.send-request as rpc.caller
server.receive-request as rpc.callee
end simple_cs.
ADLs - xADL
Lenguaje de Descripcin de Arquitecturas
basado en XML
Desarrollado por el Institute for Software
Research (Universidad de California)
Principales elementos
Componente
Conector
Interfaces
Configuraciones
Facilmente extensible (mdulos)
ADLs - xADL
<types:component xsi:type="types:Component" types:id="xArchADT">
<types:description xsi:type="instance:Description">xArchADT</types:description>
<types:interface xsi:type="types:Interface" types:id="xArchADT.IFACE_TOP">
<types:description xsi:type="instance:Description">xArchADT Top Interface</
types:description>
<types:direction xsi:type="instance:Direction">inout</types:direction>
<types:type xsi:type="instance:XMLLink" xlink:type="simple"
xlink:href="#C2TopType" />
</types:interface>
<types:interface xsi:type="types:Interface" types:id="xArchADT.IFACE_BOTTOM">
<types:description xsi:type="instance:Description">xArchADT Bottom Interface</
types:description>
<types:direction xsi:type="instance:Direction">inout</types:direction>
<types:type xsi:type="instance:XMLLink" xlink:type="simple"
xlink:href="#C2BottomType" />
</types:interface>
<types:type xsi:type="instance:XMLLink" xlink:type="simple"
xlink:href="#xArchADT_type" />
</types:component>
ADLs - xADL
ADLs - xADL
archInstance{
componentInstance{
(attr) id
= "comp1"
description = "Component 1"
interfaceInstance{
(attr) id = "comp1.IFACE_TOP"
description = "Component 1 Top Interface"
direction = "inout"
}
interfaceInstance{
(attr) id = "comp1.IFACE_BOTTOM"
description = "Component 1 Bottom Interface"
direction = "inout"
}
}
ADLs - xADL
XADL diferencia dos tipos de elementos
Instancias Arquitecturales (Ejecucin)
Estructura Arquitectural (Diseo)
Herramientas de Desarrollo - ArchStudio/
ArchEdit
Editor grfico para documentos xADL 2.0
Visualizacin de Arquitecturas
Anlisis de Arquitecturas
ADLs - xADL
Alternativas de integracin de UML con ADLs
Alternativa 1. Buscar correspondencia entre ADLs
existentes y UML
ADL : Para el diseo de alto nivel
UML : Para el diseo detallado
Correspondencia ADL & UML - Ejemplo en C2
Correspondencia ADL & UML - Ejemplo en C2
(2)
Alternativas de utilizacin de UML como ADL
Esta estrategia ha sido aplicada en lenguajes como C2 , Wright y
Rapide
Ventajas:
Representa de manera explcita las restricciones arquitecturales a
travs de OCL
Entendible por los desarrolladores y soportado por herramientas
CASE
Las tareas de ingeniera inversa a travs de estereotipos podran
simplificarse
Desventajas:
Dificultad para establecer los lmites entre el diseo de la arquitectura
y el diseo detallado
Incapacidad de las herramientas CASE para forzar el cumplimiento de
restricciones escritas en OCL
Dificultad para representar en UML la semntica particular de algunos
lenguajes de ADL
Alternativa 2. Adecuar UML por medio de estereotipos
Alternativas de utilizacin de UML como ADL
Extender el metamodelo de UML para soportar directamente los
constructores de arquitectura
Incorporar formalmente en UML nuevas capacidades de
modelado
Se puede simplificar las tareas de generar la arquitectura a partir
del diseo
Reto: Estandarizar el lenguaje sin incrementar demasiado la
complejidad de la especificacin (?)
Alternativa 3. Extender UML
Caractersticas de las extensiones de UML
2.0
Mayor riqueza semntica en la definicin del comportamiento
del sistema
Facilidad para definir composicin de elementos
Composicin estructural
Composicin del comportamiento
Conectores y puertos como constructores asociados a los
clasificadores (clases y componentes)
UML2.0: Extensiones en la definicin del
comportamiento en diagrama de secuencias
Variaciones para expresar
Paralelismo y alternativas
Iteraciones y opcionalidad
Excepciones
Este cambio reduce el nmero de
diagramas requeridos para
expresar la funcionalidad
sd ValidateCoin
:VendingMachine :User
Insert(coin)
Display(price)
RejectCoin()
alt
else
Operador
De la interaccin
UML2.0: Facilidad para especificar el
comportamiento en diferentes niveles de detalle
La lnea de vida de un
objeto puede ser
expandida con el
propsito de proveer
diferentes niveles de
abstraccin
sd Overview
:VendingMachine
ref Decomposition
Insert(coin)
RejectCoin()
:User
sd Decomposition
:Detector
:Controller
RejectCoin()
create
Insert(coin)
ValidateCoin()
UML2.0: Facilidad para factorizar
comportamientos comunes / alternativos
Evita duplicacin de
secuencias repetitivas
Mayor consistencia con
la definicin de flujos
obligatorios y opcionales
declarados en el caso de
uso
sd BuyScenario
:VendingMachine :User
Display(price)
ref
ChooseProduct
ref
ValidateCoin
UML2.0: Facilidad para composicin
estructural
La clase como una entidad stand-alone con
interfaces requeridas y provistas
VendingMachine
Display
InsertCoin
Interface
Requerida
Interface
Provista
UML2.0: Facilidad para composicin
estructural (2)
Una misma clase con diferentes comportamientos
Cada comportamiento representa un puerto de acceso a
la clase
El puerto actua como un nico punto de interaccin de la
clase
Detector
InsertCoin
CoinControl,
Counter
Maintenance
port
composite port
pCtrl
UML2.0: Facilidad para composicin
estructural (3)
Permite descomposicin jerrquica de la clase
Los conectores son utilizados como asociaciones contextuales
VendingMachine
InsertCoin
Display
:Detector
Connector
Part
Class
:Counter
:Controller
InsertCoin
pCtrl Counter
CoinControl
Display
El modelo de arquitectura de UML: 4+1 vistas
Logical View
End-user
Functionality
Implementation
View
Programmers
Software management
Process View
Performance
Scalability
Throughput
System integrators
Deployment View
System topology
Delivery, installation
Communication
System engineering
Use Case View
La promesa de MDA (Model Driven Architecture)
De desarrollo basado en cdigo a desarrollo basado en modelos
Vista general de MDA
Quin lidera la iniciativa de MDA?
El grupo OMG (Object Management
Group)
MDA: The new OMG baby
Nueva orientacin de las actividades
de la OMG
Ms all de las propuestas de
middleware (CORBA)
Influenciado por la amplia
aceptacin de UML
Estndares que ha impulsado la
OMG
Meta Object Facility
TM
(MOF)
Unified Modeling Language
TM
(UML)
Common Warehouse Metamodel
TM
(CWM)
XML Metadata Interchange
TM
(XMI)
Arquitectura de UML de cuatro niveles (OMG)
the MOF
MMM
the UML
MM
a UML
model m
a particular
use of m
the SPEM
MM
the CWM
MM
another UML
model m
another
use of m
Level M
3
Level M
2
Level M
1
Level M
0
E
B
N
F
t
h
e
P
a
s
c
a
l
g
r
a
m
m
a
r
a
P
a
s
c
a
l
p
r
o
g
r
a
m
P
a
n
e
x
e
c
u
t
i
o
n
X
o
f
p
r
o
g
r
a
m
P
Arquitectura de UML de cuatro niveles
(OMG): Ejemplo
Estructura de extensin de los lenguajes
El proceso de transformacion
La transformacin es la generacin automtica de un
modelo fuente en un modelo objetivo, de acuerdo a unas
definiciones de transformacin
Una definicin de transformacin esta conformada por
un conjunto de reglas que describen como el modelo en
el lenguaje fuente puede ser transformado en un
modelo en el lenguaje destino
Una regla de transformacin es una descripcin de uno
o ms constructores en el lenguaje fuente que pueden
ser transformados en uno o mas constructores en el
lenguaje destino
El proceso de transformacin
El proceso MDA: 1. Construccin del CIM
Modelo
Independiente
de
la Computacin
Modelo que representa
la semntica del
negocio
El proceso MDA: 2. Transformacin de CIM a PIM
El modelo representa
funcionalidad y
comportamiento sin
detalles de la
tecnologa,
Modelo
Independiente
De
Plataforma
Modelo detallado con
Pre y Post en (OCL) y
con semantica de
comportamiento (Action
Semantic)
CIM
El proceso MDA: 3. Probar PIM
Modelo
Independiente
De
Plataforma
Entorno de
Animacin del
Modelo
CIM
El proceso MDA: 4. Definir reglas de transformacin
Modelo
Independiente
De
Plataforma
Entorno de
Animacin del
Modelo
CIM
Reglas de
Transformacin
PIM - PSM
El proceso MDA: 5. Marcar el modelo
Modelo
Independiente
De
Plataforma
Entorno de
Animacin del
Modelo
CIM
Reglas de
Transformacin
PIM - PSM
+ Marcas para
transformacin
El proceso MDA: 6. Generar PSM (Platform-
Specific Model)
Platform-
Independent
Model
Mapear PIM a
tecnologa de
middleware especfica
CORBA
Model
Entorno de
Animacin del
Modelo
CIM
+ Marcas para
transformacin
El proceso MDA: 6. Mapear a mltiples tecnologas
Plataforma
Independiente
Modelo
CORBA
Modelo
Herramienta MDA, se
aplica un mapeo
estndar para generar
modelos de plataforma
especfica (PSM) de la
PIM. El cdigo es
parcialmente automtico,
parcialmente manual
Java/EJB
Modelo
XML/SOAP
Modelo
Otro
Modelo
Mapa de un PIM a
travs de tecnologas
middleware utiliza
asignaciones OMG
estndar
El proceso MDA: 7. Generacin de cdigo
Platforma
Independiente
Model
CORBA
Modelp
Las herramientas MDA
generan la mayor
parte del cdigo en la
tecnologa especfica
Java/EJB
Modelp
CORBA
XML/SOAP
Modelp
Java/EJB XML/SOAP Otro
Otro
Modelo
Mapea del PSM a las
interfaces de aplicacin, el
cdigo, los descriptores de
interfaz grfica de usuario,
consultas SQL, etc
El proceso MDA: 8. Integrar aplicaciones legado y COTS
Platforma
Independiente
Modelo
Legacy
App
Las herramientas
MDA para ingeniera
reversa apoyan el
proceso de integracin
de aplicaciones legado
COTS
App
Otro
Otro
Modelo
Ingeniera inversa de
aplicaciones existentes
en un modelo y
reimplementacin
El proceso MDA: 9. Generacin de adaptadores (bridges)
CORBA
Modelo
XML/SOAP
Modelo
Platforma
Independiente
Modelo
CORBA
Sistema
XML/SOAP
Sistema
Interope-
rabilidad
Puente
Herramientas
MDA, combinan
la aplicacin y el
conocimiento de
plataforma para
generar puentes
Herramientas MDA
Herramientas MDA (Libres)
UMT - (UML Model Transformation Tool)
Model Transformation Framework (MTF)
open Architectureware Eclipse plugin
iQgen 2.0
Metadata Transformer/Generator (MTG)
Motion Modeling
The ATL Engine
MTL Engine
ModFact
Generative Model Transformer (GMT) (Surge OMELET)
Kent Modelling Framework (KMF)
AndroMDA
OpenMDX
JunoMDA
Herramientas MDA (Comerciales)
ArcStyler
MCC (Model Component Compiler)
Codagen Architect
OptimalJ
Xactium XMF Mosiac
SosyInc Modeler and Transformation Engine
Model-in-Action
Clasificacin de soluciones existentes
De modelo a cdigo
Visitor based: mecanismo para recorrer la representacin interna del modelo y
generar el cdigo (Ej. Jamda)
Template based: (Ej: b+m Generator Framework, JET, FUUT-je, Codagen
Architect, AndroMDA, ArcStyler, OptimalJ and XDE)
De modelo a modelo
direct-manipulation: Generalmente implementadas como framework OO como
una estructura para organizar las transformaciones (Ej: jamda, jmi)
Relational:Aproximaciones declarativas basadas en relaciones matemticas
utilizando lenguajes lgicos (ej: F-Logic)
graph-transformation-based: Se utilizan grafos para expresar en un nico
formalismo los diferentes modelos (Ej:VIATRA, ATOM, GreAT, UMLX, and
BOTL)
structure-driven: Realiza la transformacin en dos fases: en la primera fase se
crea la estructura jerrquica del modelo destino y en la segunda fase se
actualizan las propiedades y referencias en el modelo destino (ej: OptimaJ,
IOPT). Practica para transformacin a plataformas como J2EE
hybrid approaches. Combinan diferentes tcnicas de las categoras anteriores
(Ej: TRL combina aproximacion declarativa e imperativa; ATL puede ser
completamente declarativa, hbidra o totalmente imperativa)
transformacin utilizando XSLT. Dificultades: baja escalabilidad, dificultad
para escribir las reglas de transformacin
Jamda, XDE, OptimalJ permite ambas transformaciones