L

D

A rchitecture

escription

anguages

Introduzione

ADLs : uno stato dell’arte

Non esiste pieno consenso su “cosa è” un ADL

Per iniziare, in assenza di definizioni esatte, come prima e generica connotazione possiamo assumere (almeno) questo:

“ADL result from a linguistic approach to the formal representation of architectures, and as such they address the shortcomings of informal representations”

Struttura

A Criteri di valutazioneIndividuazione di un insieme di categorie logiche in funzione delle quali strutturare la valutazione.

B Linguaggi consideratiIndividuazione dei linguaggi esaminati, breve presentazione di alcuni tra questi.

C RisultatiValutazione comparativa.

D Considerazioni conclusive

.: fase AApproccio adottato (1)

Domande possibili…

… considerando l’oggetto (descrizione architetturale)…

Vogliamo indagare la “bontà” di un ADL…

Q1: Cosa dovrebbe comunque essere possibile inserire nella descrizione?

Q2: Cosa dovrebbe, in funzione di esigenze particolari, essere possibile inserire nella descrizione?

.: fase AApproccio adottato (2)

… considerando il soggetto (utilizzatore del linguaggio)…

Q3(a): … inteso come lettura?

Q3(b): … inteso come scrittura?

Q3: Quali meccanismi dovrebbero essere presenti, in modo da agevolare l’utilizzo del linguaggio…

… ed in ogni caso…

Q4: Attraverso il supporto di quali strumenti dovrebbe essere possibile utilizzare il linguaggio?

Categorie .: fase A

Q1Espressività

Q2Applicabilità

Q3Usabilità

Q4Efficacia

Q3(a)Modularità, Evolvibilità

Q3(b)Comprensibilità

“cosa?”

“come?”

“attraverso quali strumenti?”

Espressività (1) .: fase A

descrizione SA = specifica strutturale ed extra-strutturale

Il linguaggio dovrebbe permettere di esprimere un’ontologia architetturale di base

+ componenti, dotate di interfacce

+ connettori, dotati di interfacce

+ configurazioni

+ comportamento

+ proprietà non funzionali

Usabilità .: fase A

Dovrebbe essere possibile, per un’utenza ragionevolmente esperta, accedere alla specifica

Accesso in scrittura: “write & draw”

Accesso in lettura: “read & look”

soggetto:architect soggetto:readeroggetto:modello

Comprensibilità

+ configurazione esplicita + notazione grafica + annotazioni

Modularità

+ componenti composte + connettori composti

Evolvibilità

+ tipi e stili, con relazioni + vincoli

Applicabilità (1) .: fase A

Il linguaggio dovrebbe permettere di esprimere una modifica architetturale che si verifica mentre il sistema è in esecuzione (high-availability)

riconfigurazione dinamica: tipo di cambiamento e variabilità

Creazione istanza

+ componente + connettore

Eliminazione istanza

+ componente + connettore

Riconfigurazione

+ programmata + ad hoc

Applicabilità (2)

Il linguaggio dovrebbe permettere di rappresentare il concetto di variabilità proprio di una famiglia di architetture (product line)

product line: punti di variazione

.: fase A

Entità architetturali

+ come opzioni + come alternative + associate a versione

Efficacia .: fase A

L’utilizzo del linguaggio dovrebbe realizzarsi attraverso il ricorso a tool di supporto “The usefulness of an ADL is directly related to the kinds of tools it provides to support architectural design, evolution, refinement, constraints, analysis, and executable system generation”

Scopo: comunicazione, analisi, generazione sistema

statica e dinamica

punti di vista multiplivisualizzazione grafica

animazione

Linguaggi

.: fase B

ABC/ADL

Rapide

MetaH

Darwin

Koala

xADL 2.0

Jacal

DAOP-ADL

Acme

C2

ADML

ArTek

Wright

Resolve

XADL 1.0

Adage

Aesop

GenVoca

LILEANNA

Little-JIL

SADL

Weaves

UniCon

considerati

ABC/ADL

ACME/Armani

DAOP-ADL

Darwin

Jacal

Koala

MetaH

Rapide

xADL 2.0

Ne vedremo alcuni…

ABC/ADL (1) .: fase B

“An ADL supporting component composition”

In sintesi

Descrizione strutturaleComponent, Connector, provide player, request player, Config

Descrizione extra-strutturalePropertiesSemanticDescription: <nomeLinguaggio> { descrizione }

Gerarchie di astrazioneComponenti e connettori composti

ESEMPI >

2002, Università di Pechino

ABC/ADL (2) .: fase B

Tipi, meccanismi di estensione e riuso:Distinzione tra tipo ed istanza, concetto di stileSistema di tipi estensibileRelazioni di subtypingRelazioni di refinement

Comprensibilità:Notazione testuale e graficaConfigurazione esplicita

2002, Università di Pechino

ACME/Armani (1)

.: fase B

“The primary purpose of ACME is to provide an interchange format for architectural development tools and environments”

“Armani is a FOPL-based sub-language that is used to express architectural constraints over ACME architectures”

In sintesi:

Descrizione strutturaleComponent, Connector, Port, Role, System

Descrizione extra-strutturaleProperties list

Gerarchie di astrazioneComponenti e connettori composti (Representation)

1995/1998, Carnegie Mellon University

ESEMPI >

ACME/Armani (2)

.: fase B

Tipi, meccanismi di estensione e riuso:Sistema di tipi estensibileDesign elements types, properties types, stylesConcetto di subtype e di subfamily: costrutto extends … with

Possibilità di specificare vincoli non predefiniti:Linguaggio ArmaniDistinzione tra Invariant ed Euristic

Comprensibilità:Notazione testuale e graficaConfigurazione esplicita

1995/1998, Carnegie Mellon University

Darwin/FSP (1) .: fase B

“Darwin has features which permit the description of dynamic structures which evolve as execution progresses”

In sintesi

Descrizione strutturale:Component, require, provide, bind, (configurazione)

Descrizione extra-strutturale:Comportamento espresso tramite Finite State Process

Gerarchie di astrazione:Componenti composte

1991, London’s Imperial College

ESEMPI >

Darwin/FSP (2) .: fase B

Tipi, meccanismi di estensione e riusoSistema di tipi estensibileTipi parametriciSubtyping tramite derivazione

ComprensibilitàNotazione testuale e grafica

Riconfigurazione dinamicaTipologia programmataCreazione istanza componente (lazy instatiation, direct dynamic instantiation)

1991, London’s Imperial College

Jacal .: fase B

“Our goal has been to build a tool that could be used to edit a system’s architecture and then graphically simulate its behavior”

Descrizione strutturaleComponent, link, socket, (configurazione)

Descrizione extra-strutturalePlace-transition net, specificate solo per le componenti (il comportamento di un connettore è da considerarsi implicitamente definito nel tipo di appartenenza)

Tipi, meccanismi di estensione e riusoTipi predefinitiRelazioni di ereditarietà tra componenti

ComprensibilitàConfigurazione esplicitaNotazione grafica

1997, University of Buenos Aires

ESEMPI >

Koala (1) .: fase B

“With an architectural description language, you can make an explicit description of a configuration’s structure in terms of its components. This description makes both the diversity of the product family and the complexity of the individual products visible; thus, it serves as valuable tool for software architects”

In sintesi:

Descrizione strutturaleComponent, provides, requires, (configurazione)

Descrizione extra-strutturaleAttributi di componenti inseriti nella clausola specials

Gerarchie di astrazioneStruttura interna introdotta dalla clausola contains

1997, Philips Consumer Electronics

ESEMPI >

Koala (2) .: fase B

Tipi, meccanismi di estensione e riusoSistema di tipi estensibileInterface subtyping

ComprensibilitàNotazione grafica

Riconfigurazione dinamicaTipologia programmataCreazione istanza componente (limitatamente alle alternative di uno switch)

Product lineInterfacce opzionaliComponenti alternative (tramite switch)

1997, Philips Consumer Electronics

Rapide (1) .: fase B

“Rapide allows the simulation and behavioral analysis of architectures of such systems at an early stage in the system development process”

In sintesi:

Descrizione strutturaleInterface, public action, extern action, connect, (configurazione)

Descrizione extra-strutturaleComportamento di componente: regole di transizione

Gerarchie di astrazioneStruttura interna implicitamente realizzata tramite encapsulation

ComprensibilitàNotazione testuale e grafica

1990, University of Stanford

ESEMPI >

Rapide (2) .: fase B

Tipi, meccanismi di estensione e riusoSistema di tipi estensibileTipi parametriciRelazione di ereditarietà tramite il costrutto include

Possibilità di specificare vincoli non predefinitiPattern constraints (Rapide Constraint Language)

Riconfigurazione dinamicaTipologia programmata, ad hoc(?)Creazione istanza componenteEliminazione istanza componente

1990, University of Stanford

xADL 2.0 (1) .: fase B

“An architect in need of a unique set of modeling features must either develop a new architecture description language from scratch or undertake the daunting task of modifing an existing language. […] To remedy this situation, we have developed an infrastructure for the rapid development of new architecture description languages”

In sintesi:

Descrizione strutturale<component>, <connector>, <interface>, <archStructure>

Gerarchie di composizione<subArchitecture>

2000, University of California

xADL 2.0 (2) .: fase B

Tipi, meccanismi di estensione e riusoSistema di tipi estensibile

ComprensibilitàConfigurazione esplicitaNotazione testuale e grafica

Product lineOpzione: <xsd:complexType name="OptionalComponent">

<xsd:complexType name="OptionalConnector"> <xsd:complexType name="OptionalInterface">

Alternativa: <xsd:complexType name="VariantComponentType">

<xsd:complexType name="VariantConnectorType">

Versione: <xsd:complexType name="ComponentTypeVersionGraph">

<xsd:complexType name="ConnectorTypeVersionGraph"> <xsd:complexType name="InterfaceTypeVersionGraph">

2000, University of California

Risultati: espressività

.: fase C

= “in parte”

Risultati: usabilità (1)

.: fase C

n.a. = non applicabile

Risultati: usabilità (2)

.: fase C

= “in un certo senso…”

Risultati: applicabilità

.: fase C

= “esternamente”

Risultati: efficacia .: fase C

-> = progetto proposto e correntemente assegnato

(-> ) = progetto proposto * = non built-in

Osservazioni conclusive (1)

Tutti i linguaggi prevedono la distinzione tra tipo ed istanza; alcuni consentono di stabilire delle relazioni tra tipi (tipicamente in termini di ereditarietà).

Si potrebbe fare di più?Potrebbe essere utile accrescere l’insieme di suddette relazioni, così da fornire maggiori possibilità nella scelta della direzione verso la quale far evolvere un’entità.

Abbiamo parlato di riconfigurazione dinamica (non di architettura dinamica…), ed abbiamo visto come, quasi sempre, si realizzi in forma programmata.

Si potrebbe pensare di estendere la possibilità di evoluzione a runtime al concetto di tipo, ovvero non vincolare la creazione di nuove istanze ai tipi definiti in fase di design.

.: fase D

Osservazioni conclusive (2)

Parlando di comprensibilità, abbiamo detto dell’importanza di poter ricorrere ad una rappresentazione grafica.

Sarebbe interessante strutturare meglio la valutazione di questo aspetto, capire quali caratteristiche potrebbero contribuire a rendere “più attraente” un diagramma.

Un ulteriore punto da considerare (per ovvie ragioni) è quello relativo alla capacità di un ADL di “coesistere” e di integrarsi con il linguaggio UML.

Per quanto riguarda Acme, ad esempio, è presente la proposta di un plugin per la generazione di documentazione UML.Similmente, il prototipo ABC Tool permette di realizzare il mapping di una descrizione architetturale (in ABC/ADL) nel framework UML.

.: fase D

Osservazioni conclusive (3)

Parlando di descrizione strutturale, l’assunzione è stata quella di identificare in componenti e connettori le entità architetturali di base.

Ma è proprio così?In realtà alcuni ritengono che sia necessario aggiungere un elemento ulteriore, un aspetto.Abbiamo scelto di non considerare, nella classificazione, questo nuovo termine: è comunque opportuno renderne conto, quantomeno in questa fase conclusiva.In particolare ne abbiamo riscontrato la presenza in due linguaggi, ABC/ADL e DAOP-ADL.

.: fase D

Esempi

ABC/ADL: componente

Component DatingManager is BLACKBOARD.BlackBoard {

Interfaces{

provide player DatingManager is BlackBoard.Entry {…}

request player Agenda is BlackBoard.Notification {…}

}

Attributes {…}

Properties {…}

Dependencies {…}

SemanticDescription {…}

Definizione del tipo DatingManager:

Indicazione dello stile di appartenenza:

“is” <nomeStile>.<nomeTemplate>

ABC/ADL: configurazione

Architecture DS_Architecture {

uses {

Component datingManager : DatingManager ;

…

}

Config main {

datingManager.Agenda connects

datingManagerToAgenda.Callee

}

nome istanza nome tipo

interfaccia componente interfaccia connettore

Prima sezione dichiarativa: istanze di componenti e connettori (ed aspetti)

Seconda sezione dichiarativa: topologia

ABC/ADL: composizione

Component Dating_System is System {

Structure { architecture DS_Architecture }

Mapping { self.makeMeeting to datingManager.makeMeeting }

}

Definizione della componente composta Dating_System:

Connessione tra l’interfaccia della componente composta e l’interfaccia della componente interna

<<

ACME/Armani: connettore

Definizione del tipo MessagePath:

Connector Type MessagePath = {

Roles {source; sink }

Property expectedThroughput : float = 512;

Invariant (queueBufferSize >= 512) and (queueBufferSize <= 4096);

Euristic expectedThroughput <= (queueBufferSize / 2);

}

Condizioni che devono o che possono essere osservate

Informazione non interpretata dal linguaggio: annotazione

ACME/Armani: configurazione

System SimplePF : PipeFilterFam = {

Component detectErrors : FilterT;

Connector firstPipe : PipeT;

Attachments { detectErrors.stdin to firstPipe.sink;}

}

Dichiarazione di un’istanza di una famiglia (precedentemente definita)

Dichiarazione delle istanze, di componenti e connettori, corrispondenti ai tipi definiti nella famiglia di appartenenza

ACME/Armani: composizione

Component Server = {

Port receiveRequest;

Representation serverDetails = {

System serverDetailsSys = {

Component {…} …

Connector {…} …

Attachment {…} …

}

Bindings { connectionManager.externalSocket to server.receiveRequest }

}

Definizione della componente composta Server:

Connessione tra l’interfaccia della componente composta e l’interfaccia della componente interna

<<

Darwin: comportamento

KOALA = (wake -> AWAKE),

AWAKE = (eucalyptus -> sleep -> KOALA

| sleep -> KOALA)

Definizione del processo Koala:

… all’automa LTS

Dalla specifica FSP …

0 1 2

wake eucalyptus

sleep

sleep

“The FSPprocess algebra-like notation is used asa concise way of describing the Labelled Transition System(LTS) of the component for analysis purposes”

Darwin: istanze dinamiche

Struttura lazy

inst a : atype;

inst b : dyn btype;

bind a.send -- b.wait;

Struttura dinamica

inst a : atype;

bind a.createB -- dyn B;

In condizioni “normali” l’istanziazione di una componente avviene in concomitanza della creazione di un’entità parente.

Sono possibili le seguenti due eccezioni:

Inizialmente è presente solo l’istanza a: l’istanziazione di b avverrà quando a proverà ad accedere al servizio wait

Replicazione: ogni volta che si verificherà una chiamata ad a.createB verrà istanziata una nuova componente B

<<

Jacal: connettori (predefiniti)

“ kill ”“ read ”

“ write ”

“ call ” “ fork ”

Il comportamento di un link non prevede una specifica esplicita, essendo implicitamente definito nel tipo di appartenenza:

calltrasferisce il controllo e resta in attesa di un risultato

Jacal: componenti (predefinite)

reentrant passivenon

reentrant

Non può essere connessa a link di tipo read o write

Non può essere connessa a link di tipo read, write, call o fork

Può essere connessa solo a link di tipo read o write

<<

Koala: componente

Definizione del tipo CTvPlatform:

component CTvPlatform {

provides IProgram pprg;

requires II2c slow, fast;

contains

component CFrontEnd cfre;

component CTunerDriver ctun;

connects

pprg – cfre.pprg;

cfre.rtun – ctun.ptun;

ctun.ri2c – fast;

}

struttura interna: componente composta

dettagli di connessione (non esiste un connettore esplicito)

Koala: connessioni

AA

B1B1 B2B2BB

AA

m

component C{provides …requires …contains …connectsswitch div.Fastin { a.r }out { b1.p } on false, { b2.p } on true;}

1 2 3

Interface = InterfaceInterface = ModuleModule = Interface

1,2: connessione tramite cable

3: connessione tramite switch

<<

Rapide: componente

Definizione del tipo Application:

type Application is interface

extern action Request (p : params);

public action Results (p : params);

behavior

(?M in String) Receive(?M) => Results(?M);

end Application

Regola di transizione:

Quando si osserva un evento di tipo Receive si genera in risposta un evento di tipo Results

L’utilizzo del placeholder ?M indica la presenza dello stesso parametro nei due eventi

Rapide: tipi derivati

Derivazione del tipo Colored Point dal tipo Point

type Colored_Point is interface

provides

include Point;

Color function() return Color_Map;

end Interface

Il meccanismo di derivazione, tramite il costrutto include, consente di “copiare” un insieme di dichiarazioni, quelle contenute nel tipo sorgente, nella definizione del tipo derivato

Possibilità di aggiungere, nella derivazione, ulteriori opzioni:only

except

replace… by… <<

type Point is interface

provides

X_val : Integer;

Y_val : Integer;

Distance function(P : Point)

return Integer;

end Interface