Arquitectura de Software lenguajes de especificacion

Prof. Viviana Alvarez

Agosto 2011
introduccin
La arquitectura debera expresarse en una
convencin grfica o en algn lenguaje avanzado
de alto nivel de abstraccin

de alto nivel de
abstraccin

Introduccin
Son NECESARIOS Modelos formales para
describir una arquitectura de Software.

Los ADLs han sido propuestos como una
posible alternativa.

Los ADLs se usan para satisfacer
requerimientos descriptivos de alto nivel
que las notas basadas en objetos y UML
no cumplen satisfactoriamente.

Contar con un ADL le permite al arquitecto
razonar sobre propiedades del sistema con
precisin.

Propiedades:

protocolos de interaccin
anchos de banda y latencia
localizacin del almacenamiento
conformidad con estndares arquitectnicos
evolucin


Introduccin
Definicin de ADL
Un ADL es un lenguaje que provee caracteristicas para
modelar un sistema de software a nivel arquitectnico.

Caracteristicas esenciales:
Especificacin explcita de
Componentes
Interfaces
Conectores
Configuraciones

Caracteristicas deseables:
Especificar aspectos de componentes, conectores,
y configuraciones
Herramientas de soporte

Qu es un ADL (Architecture Definition Language)?

Un ADL se enfoca en la descripcin de la estructura de la
aplicacin a alto nivel, en lugar de la descripcin de la
implementacin de cualquier mdulo especfico.

ADL es un lenguaje que provee elementos para modelar la
arquitectura conceptual de un sistema software, distinguindola
de la implementacin del sistema (Medvidovic&Taylor)

Constructores bsicos de un ADL: Componentes, Conectores,
Configuraciones y Restricciones (Tracz, 1993).


Qu es un ADL (Architecture Definition Language
El problema: Los lenguajes formales son
difciles de entender y manejar en
aplicaciones industriales


Reto: Convertir a UML en un lenguaje
suficientemente preciso para especificar
una arquitectura

Relacin de ADLs con otras notaciones y herramientas
Principales ADLs
Criterios de definicin de un
ADL
Los ADLs se remontan a los lenguajes de
interconexin de mdulos (MIL) de la dcada
de 1970.

Tracz [Wolf97] define un ADL como una
entidad consistente en cuatro Cs:
componentes, conectores, configuraciones y
restricciones (constraints).
La especificacin
ms completa y sutil
es la de Medvidovic
Definiciones
Interfaz

modela los servicios ofrecidos y requeridos
Tipos

provee el rehso y la multiple instanciacin de la
misma funcionalidad

Semntica

facilita el anlisis, el manejo de restricciones y el
mapeo de la arquitectura a travs de los diferentes
niveles de refinamiento

Definiciones...
Restricciones (Constraints)

Condiciones de diseo que se deben mantener en el
tiempo (p.e. # clientes conectados a un servicio).

Evolucin
Los componentes son elementos de diseo
evolucionan (derivacin de subtipos)

Soporte a traves del refinamiento
Propiedades No-Funcionales

Simulacin de comportamiento en tiempo de
ejecucin, anlisis, imponer restricciones,
despliegue(deployment) y manejo del proyecto

Lenguajes - Acme
Herramienta capaz de soportar el mapeo de
especificaciones arquitectnicas entre
diferentes ADLs.
Creado en 1995
Objetivo principal intercambio entre
arquitecturas e integracin de ADLs.
Acme soporta la definicin de cuatro tipos
de arquitectura

La estructura (organizacin de un sistema en
sus partes constituyentes)
Las propiedades de inters (informacin que
permite razonar sobre el comportamiento local o global,
tanto funcional como no funcional)
Las restricciones (lineamientos sobre la posibilidad
del cambio en el tiempo)
Los tipos y estilos

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