rchitecture

1. A rchitecture D escription L anguages

2. Introduzione

3. Struttura

4. Q1: Cosa dovrebbe comunque essere possibile inserire nella descrizione? Q2: Cosa dovrebbe, in funzione di esigenze particolari, essere possibile inserire nella descrizione? Approccio adottato (1) .: fase A ÚVogliamo indagare la “bontà” di un ADL… Domande possibili… … considerando l’oggetto (descrizione architetturale)…

5. Q3(a): … inteso come lettura? Q3(b): … inteso come scrittura? Q3: Quali meccanismi dovrebbero essere presenti, in modo da agevolare l’utilizzo del linguaggio… Q4: Attraverso il supporto di quali strumenti dovrebbe essere possibile utilizzare il linguaggio? Approccio adottato (2) .: fase A … considerando il soggetto (utilizzatore del linguaggio)… … ed in ogni caso…

6. Categorie .: fase A Q1ÚEspressività “cosa?” Q2ÚApplicabilità Q3ÚUsabilità Q3(a)ÚModularità, Evolvibilità “come?” Q3(b)ÚComprensibilità Q4ÚEfficacia “attraverso quali strumenti?”

7. Il linguaggio dovrebbe permettere di esprimere un’ontologia architetturale di base Espressività (1) .: fase A descrizione SA = specifica strutturale ed extra-strutturale + componenti, dotate di interfacce + connettori, dotati di interfacce + configurazioni + comportamento + proprietà non funzionali

8. Dovrebbe essere possibile, per un’utenza ragionevolmente esperta, accedere alla specifica Accesso in scrittura: “write & draw” Accesso in lettura: “read & look” oggetto:modello soggetto:architect soggetto:reader Usabilità .: fase A Evolvibilità + tipi e stili, con relazioni + vincoli Comprensibilità + configurazione esplicita + notazione grafica + annotazioni Modularità + componenti composte + connettori composti

9. Il linguaggio dovrebbe permettere di esprimere una modifica architetturale che si verifica mentre il sistema è in esecuzione (high-availability) Applicabilità (1) .: fase A riconfigurazione dinamica: tipo di cambiamento e variabilità Creazione istanza + componente + connettore Riconfigurazione + programmata + ad hoc Eliminazione istanza + componente + connettore

10. Il linguaggio dovrebbe permettere di rappresentare il concetto di variabilità proprio di una famiglia di architetture (product line) Entità architetturali + come opzioni + come alternative + associate a versione Applicabilità (2) .: fase A product line: punti di variazione

11. statica e dinamica punti di vista multipli visualizzazione grafica animazione Efficacia .: fase A Scopo: comunicazione, analisi, generazione sistema

12. XADL 1.0 Wright SADL Weaves ArTek LILEANNA ADML Resolve Adage UniCon C2 Aesop GenVoca Little-JIL Linguaggi considerati .: fase B DAOP-ADL xADL 2.0 • ABC/ADL • ACME/Armani • DAOP-ADL • Darwin • Jacal • Koala • MetaH • Rapide • xADL 2.0 Ne vedremo alcuni… Koala Darwin Rapide Jacal MetaH ABC/ADL Acme

13. ABC/ADL (1) .: fase B 2002, Università di Pechino Ú “An ADL supporting component composition” ESEMPI >

14. ABC/ADL (2) .: fase B 2002, Università di Pechino

15. ACME/Armani (1) .: fase B 1995/1998, Carnegie Mellon University ESEMPI >

16. ACME/Armani (2) .: fase B 1995/1998, Carnegie Mellon University

17. Darwin/FSP (1) .: fase B 1991, London’s Imperial College ESEMPI >

18. Darwin/FSP (2) .: fase B 1991, London’s Imperial College

19. Jacal .: fase B 1997, University of Buenos Aires ESEMPI >

20. Koala (1) .: fase B 1997, Philips Consumer Electronics ESEMPI >

21. Koala (2) .: fase B 1997, Philips Consumer Electronics

22. Rapide (1) .: fase B 1990, University of Stanford ESEMPI >

23. Rapide (2) .: fase B 1990, University of Stanford

24. xADL 2.0 (1) .: fase B 2000, University of California

25. xADL 2.0 (2) .: fase B 2000, University of California

26. Risultati: espressività .: fase C J J J º =“in parte”

27. Risultati: usabilità (1) .: fase C J J J J n.a. = non applicabile

28. Risultati: usabilità (2) .: fase C J ¢ = “in un certo senso…”

29. Risultati: applicabilità .: fase C »º = “esternamente”

30. Risultati: efficacia .: fase C J J l-> l = progetto proposto e correntemente assegnato l(-> l) = progetto proposto * = non built-in

31. Osservazioni conclusive (1) .: fase D

32. Osservazioni conclusive (2) .: fase D

33. Osservazioni conclusive (3) .: fase D

35. Esempi

36. ABC/ADL: componente Definizione del tipo DatingManager: Component DatingManager is BLACKBOARD.BlackBoard { Interfaces{ provide player DatingManager is BlackBoard.Entry {…} request player Agenda is BlackBoard.Notification {…} } Attributes {…} Properties {…} Dependencies {…} SemanticDescription {…} Indicazione dello stile di appartenenza: “is” <nomeStile>.<nomeTemplate>

37. Prima sezione dichiarativa: istanze di componenti e connettori (ed aspetti) nome istanza nome tipo Seconda sezione dichiarativa: topologia interfaccia componente interfaccia connettore ABC/ADL: configurazione Architecture DS_Architecture { uses { Component datingManager : DatingManager ; … } Config main { datingManager.Agenda connects datingManagerToAgenda.Callee }

38. Connessione tra l’interfaccia della componente composta e l’interfaccia della componente interna ABC/ADL: composizione Definizione della componente composta Dating_System: Component Dating_System is System { Structure { architecture DS_Architecture } Mapping { self.makeMeeting to datingManager.makeMeeting } } <<

39. Informazione non interpretata dal linguaggio: annotazione Condizioni che devono o che possono essere osservate 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); }

40. Dichiarazione delle istanze, di componenti e connettori, corrispondenti ai tipi definiti nella famiglia di appartenenza Dichiarazione di un’istanza di una famiglia (precedentemente definita) ACME/Armani: configurazione System SimplePF : PipeFilterFam = { ComponentdetectErrors : FilterT; Connector firstPipe : PipeT; Attachments { detectErrors.stdin to firstPipe.sink;} }

41. Connessione tra l’interfaccia della componente composta e l’interfaccia della componente interna ACME/Armani: composizione Definizione della componente composta Server: Component Server = { Port receiveRequest; Representation serverDetails = { System serverDetailsSys = { Component {…} … Connector {…} … Attachment {…} … } Bindings { connectionManager.externalSocket to server.receiveRequest } } <<

42. wake eucalyptus 0 1 2 sleep sleep Darwin: comportamento Definizione del processo Koala: “The FSP process algebra-like notation is used as a concise way of describing the Labelled Transition System (LTS) of the component for analysis purposes” Dalla specifica FSP … KOALA = (wake -> AWAKE), AWAKE = (eucalyptus -> sleep -> KOALA | sleep -> KOALA) … all’automa LTS

43. Struttura lazy inst a : atype; inst b : dyn btype; bind a.send -- b.wait; • Struttura dinamica inst a : atype; bind a.createB -- dyn B; Darwin: istanze dinamiche 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 <<

44. Jacal: connettori (predefiniti) “ kill ” “ write ” “ read ” “ call ” “ fork ” Il comportamento di un link non prevede una specifica esplicita, essendo implicitamente definito nel tipo di appartenenza: callÚtrasferisce il controllo e resta in attesa di un risultato

45. Non può essere connessa a link di tipo read o write Può essere connessa solo a link di tipo read o write Non può essere connessa a link di tipo read, write, call o fork Jacal: componenti (predefinite) reentrant non reentrant passive <<

46. struttura interna: componente composta dettagli di connessione (non esiste un connettore esplicito) 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; }

47. A A m B1 B2 B Koala: connessioni component C { provides … requires … contains … connects switch div.Fast in { a.r } out { b1.p } on false, { b2.p } on true; } 1 2 3 Interface = Interface Interface = Module Module = Interface 1,2: connessione tramite cable 3: connessione tramite switch <<

48. 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: 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

49. 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 type Point is interface provides X_val : Integer; Y_val : Integer; Distance function(P : Point) return Integer; end Interface <<