Corso di Analisi e Testing basato su componenti Acme e ArchJava: Studio e Integrazione Anna Lucia e Giuseppe Paoletti

Contesto Sviluppo di sistemi software sempre più complessi Elaborazione di SA rigorose e con un adeguato livello di astrazione; Conformità tra specifica architetturale ed implementazione.

Stato dell’arte (I) Attualmente, la maggior parte degli ADLs offrono un valido supporto solo per la descrizione e analisi di una SA a causa del decouple tra specifica ed implementazione. Problemi: inconsistenza e mancata rispondenza tra i due mondi; difficoltà legate all’evoluzione.

Stato dell’arte (II) I tools che realizzano questo collegamento non garantiscono che l’implementazione rispetti i vincoli architetturali. Gap evidente tra gli stili e regole dei linguaggi di specifica e i costrutti degli attuali linguaggi di programmazione.

Stato dell’arte (III) Uno dei primi approcci realizzati in questa direzione è quello che si propone di creare una sinergia tra due tecnologie: ACME e ARCHJAVA il primo appartenente al mondo degli ADLs e il secondo a quello dei linguaggi general- purpose.

ArchJava: introduzione Linguaggio general-purpose che integra i costrutti standard di Java con quelli espliciti di modellazione architetturale. Obiettivo: realizzare SA espressive, conformi alla relativa specifica e coerenti nelle diverse evoluzioni.

ArchJava: obiettivi di design Descrizione gerarchica di una SA; Rappresentazione di architetture dinamiche; Rigoroso controllo sulle comunicazioni inter- componenti; Conformità SA-implementazione a tempo di compilazione; Vincoli e rigidi checks sull’impiego di data sharing. Validazione formale.

ArchJava: obiettivi di design Supporto alla progettazione, visualizzazione e verifica iterative di SA incomplete; Applicabilità a qualunque genere di applicazione (anche esistenti): Attualmente testato solo per programmi con al massimo righe di codice. Copertura di tutte le fasi di sviluppo di una SA.

ArchJava: costrutti architetturali Nuove entità di programmazione: componenti: Elementi architetturali di computazione ; porte: Endpoints di comunicazione; Dichiarazione dei domini di possedimento; Visualizzazione delle funzionalità provides e requires di ciascuna componente; connessioni: Collegamento porte e dichiarazione protocolli impiegati.

ArchJava: Componenti Oggetti distinti della classe component class che comunicano in modo strutturato. Possono contenere dichiarazioni di: Una classe ordinaria; Porte; Connessioni.

ArchJava: componenti Memorizzare la component container che l’ha istanziata. Numerosi vincoli: Non possono implementare interfacce; Non possono avere classi interne statiche; Non possono estendere classi ordinarie ad eccezione di Object; Vietato qualunque cast a componente a meno che non venga eseguito dentro lo scope del genitore. Limitato accesso ai campi di tipo componente.

ArchJava: porte Canali (I/O) di comunicazione logica tra componenti. Porte vs interfacce Java: Dichiarazione di metodi: provides, requires e broadcast; Dichiarazione di domini ownership contenenti oggetti condivisi tra le componenti; Dichiarazione di porte multiple ognuna disciplinata da un protocollo di comunicazione distinto.

ArchJava: porte Distinzione tra attività di computazione e comunicazione facilita evoluzione e gestione dell’architettura. Vincoli: Definite solo all’interno delle component class; Non possono esistere due metodi provides e requires con la medesima signature; Invocazioni di metodi solo dopo che la relativa porta è stata connessa (collegamenti dinamici);

ArchJava: connessioni Connettono istanze di porte, collegando ogni metodo requires con uno provides avente la stessa signature. Argomenti della primitiva connect: Porte della componente; Porte delle sottocomponenti definite final; Relazione componente – connettore si basa su una normale chiamata a metodo: Indipendenza da uno specifico connettore.

ArchJava: connessioni Individua i domini condivisi tra le porte collegate. Vincoli: Istanziate immediatamente dopo l’istruzione super del costruttore; Considerati solo i campi final; Partecipazione delle porte alle connessioni esterne guidata dalla loro visibilità;

ArchJava: connessioni user-defined Alcune forme di connessioni non supportate (es: asincrona, broadcast multi-thread,…). Definizione connettori custom (estensioni class Connector) con nuove regole semantiche e di type checking (metodo typecheck). Pregi e difetti: Meccanismo flessibile e altamente riutilizzabile Staticamente non si può assicurare che un connettore custom realizzi una comunicazione safe.

ArchJava: gerarchie Sottocomponenti connesse che comunicano tramite porte collegate. Conformità verificata staticamente.

ArchJava: AliasJava Tipo di sistema di monitoraggio delle comunicazioni tramite alias e controllo conformità. annotazioni: unique: reference unico e non condiviso; owned: oggetto posseduto da un owner (definizione di sottosistemi); shared: reference globalmente condiviso; lent: reference condiviso per la durata di un metodo (time-bounded).

ArchJava: annotazione owned Dominio in cui si dichiarano tutti gli oggetti contenuti da una data componente; public component class WordProcessor { domain owned; private owned Document doc; private owned Interface ui; connect doc.doc, ui.doc; } Concessione esplicita di accesso al dominio a terzi realizzata tramite link e assume.

ArchJava: annotazioni Inizialmente erano presenti altre annotazioni ora ignorate. unique ownedx,y,z…..shared lent

ArchJava: proprietà (I) Communication Integrity: ogni componente nell’implementazione può comunicare DIRETTAMENTE solo con le componenti a cui è connessa nell’architettura. Comunicazione solo tramite porte connesse o domini condivisi. Proprietà fondamentale per assicurare la conformità tra SA e implementazione.

ArchJava: proprietà (II) Tipo di sistema: Checking statico e più rigoroso; Rispetto assoluto della communication integrity; Check locali che permettono di realizzare una compilazione incrementale.

ArchJava: proprietà (III) Linguaggio core ArchFJ che impiega tecniche formali per modellare e valutare formalmente i sistemi ArchJava. Capacità di rappresentare stili architetturali

ArchJava: architetture dinamiche (I) Creazione di nuove componenti tramite new; Connect pattern: descrizione di un insieme di connessioni tra sottocomponenti da istanziare a run-time; Expression connect: realizzazione del connect pattern; Porte interfacce: possono essere istanziate a run-time per diversi collegamenti che adottano il medesimo protocollo.

ArchJava: architetture dinamiche (II) Connessioni glue: collegamenti tra componente e sottocomponenti o tra le sue porte. Rimozione di componenti tramite garbage collection; Recupero di risorse impiegate da un connettore non più utilizzato.

ArchJava vs Java Alcuni costrutti rivisti ed estesi (cast, campi statici,…). Livello di safety e decoupling di ArchJava non raggiungibili con ArchJava. Java: maggiore overhead; maggiore numero di files sorgenti, maggiore sforzo per garantire la communication integrity. ArchJava: ad ogni modifica di un file.archj si rigenerano tutti i files dipendenti.

ArchJava: vantaggi Architetture complete e conformi (anche in fase di evoluzione) alle specifiche. Descrizione white box. Separazione computazione da comunicazione. Sviluppo di sistemi adattativi (run-time). SA esplicita gestione facilitata. Creazione incrementale di sistemi (incomplete).

ArchJava: limiti Descrizione esclusivamente topologica e non comportamentale; Dipendenza a livello di compilazione. Limiti di scalabilità. Vincoli pesanti alla programmazione. Livello di indirezione nelle comunicazioni. Vista architetturale poco astratta. Programmazione “monotematica”.

ArchJava: futuro Implementare alcuni costrutti ancora teorici: domini ownership; Connessioni user-defined; Determinati check,… Specificare proprietà di dominio. Realizzare sistemi di grandi dimensioni. Supporto esplicito a stili architetturali. Tools di editor grafico e analisi.

Acme: introduzione ADL di 2a generazione. Linguaggio di interscambio. Base per nuovi tools e analisi architetturali. Vocabolario base (ontologia) di elementi architetturali. Linguaggio semanticamente aperto. Template e famiglie per riusabilità. Ricco tooleset di analisi.

Acme: descrizione architetturale Definizione di quattro aspetti distinti: Struttura sistema. Specifica di proprietà (funzionali e non). Vincoli Tipi e stili

Acme: struttura Sette tipi architetturali: Componenti: computazione e memorizzazione; Porte: endpoints di comunicazione; Connettori: interazioni; Regole:definizione partecipanti alla comunicazione; Sistemi: topologia del sistema; Rappresentazioni: viste concettuali diverse di un elemento; Rep-maps: corrispondenza rappresentazione – elemento architetturale.

Acme: proprietà e vincoli Utilizzate dai tools di analisi; Tipo : Built-in (integer, string,…) Specific-domain (interpretati). Vincoli:disciplinano l’evoluzione di un sistema. Impiego di logica di primo ordine tools ad hoc per la loro validazione; Euristica o invarianti

Acme: stili, template e famiglie Stile: vocabolario specific-domain di entità e loro vincoli. Repository di esperienze, analisi,…. Base: tipo di sistema. Template: patterns architetturali parametrizzati ed estendibili. Famiglia: insieme di sistemi Vocabolario di progettazione; Vincoli; Struttura di default.

Acme: benefici Connettori espliciti: consente di definire nuovi “glue” architetturali. Rappresentazioni multiple; viste multiple, relazioni di raffinamento e schemi semplici di incapsulamento. L’uso di template e stili per incapsulare idiomi e pattern riutilizzabili.

Acme: svantaggi e futuro Non esistono meccanismi espliciti per descrivere le corrispondenze tra le diverse viste; attualmente il tipo Acme è piuttosto debole. Collegare Acme con UML; bisognerebbe sviluppare qualche tool per verificare la corrispondenza; completare implementazione template.

Differenze Acme – ArchJava (I) Non esiste una corrispondenza 1:1 tra i loro elementi architetturali (es: porte). Visione differente del tipo di sistema. Configurazione esplicita in Acme mentre è implicita in ArchJava. Differenti elementi required per una specifica architetturale.

Differenze Acme – ArchJava (II) Impossibilità tecniche di esprimere i vincoli Acme in ArchJava. Diversi livelli di astrazione. Acme consente evoluzioni indipendenti al contrario di ArchJava. ArchJava supporta le architetture dinamiche mentre Acme non ha la medesima capacità espressiva.

Sincronizzazione Conversione vista C&C in un albero; Addizione di informazioni alle viste; Confronto strutture; Visualizzazione edit script con suggerimenti e sua validazione. Strategie per colmare il gap strutturale e formale delle due tecnologie: Divieto di impiego di alcuni nomi; Uso proprietà; …. Perdita di alcune informazioni di Acme in ArchJava.

Sincronizzazione: esempio ArchJava public component class Capitalize { private final Upper upper = new Upper(); private final Lower lower = new Lower(); private final Split split = new Split(); private final Merge merge = new Merge(); public port portIn { requires char getChar();} public port portOut { provides char getChar();} connect lower.portOut, merge.portIn1; connect split.portOut2, lower.portIn; connect upper.portIn, split.portOut1; connect merge.portIn2, upper.portOut; glue portOut to merge.portOut; glue portIn to split.portIn; } Acme

Sincronizzazione: esempio 1) Si sincronizzano i tipi architetturali e le istanze; 2) Aggiungono informazioni per la comparazione;

Sincronizzazione: esempio Edit script segnala modifiche necessarie per sincronizzare le due strutture: Renames, Aggiunta rappresentazione in Acme. Confronto comportamentale condotto solo sulle interfacce e signature. Tipi e stili architetturali opzionali perché non realizzabili in ArchJava. Assegnamento tipo alle porte di ArchJava tramite port types di Acme.

Limiti approccio Controllo solo di operazioni di basso livello: Rename, Cancellazioni; Inserimenti. Manca supporto ai divide e merge di elementi architetturali. Solo architetture statiche. Tool ancora sotto sviluppo.

Nostro lavoro Installazione Eclipse e IDE AcmeArchJava. Realizzazione sistema Acme e traduzione in ArchJava tramite funzione “ArchJava translate”. Attività non funzionante; applicabile solo a sistemi Acme VUOTI. Mancato supporto e documentazione poco esauriente. Problemi rilevati da altri esperti del settore.