Università degli Studi dell’Aquila FACOLTA’ DI SCIENZE MM.FF.NN . Corso di Laurea in Informatica

1. FUJABA vs. CHARMY: confronto della feature model checking(Analisi e Testing di Sistemi a Componenti) Università degli Studi dell’Aquila FACOLTA’ DI SCIENZE MM.FF.NN. Corso di Laurea in Informatica ANNO ACCADEMICO 2005 – 2006 Prof. Henry MucciniStud.ssa: Romina Spalazzese matr.162992

2. Road Map • Cos’è il Model Checking (MC) • Caratteristiche dell’approccio Fujaba • Caratteristiche dell’approccio Charmy • Confronto e considerazioni • Future works

3. 1. Model Checking • Tecnica automatica basata sul modello: controlla se una determinata proprietà è valida per un certo modello di un sistema. • Risultato: true o false + controesempio • STEP 1 - Crea un finite state model (FSM) del sistema • STEP 2 - Specifica proprietà critiche di correttezza (safety, liveness) • STEP 3 – Valida il modello rispetto alle specifiche VANTAGGI - Automatico - Esaustivo - Genera controesempio SVANTAGGI - State explosion problem - Skills in metodi formali

4. 2. FUJABA: cos’è CASE tool open-source che supporta modellazione e verifica di modelli UML • Tra tutte le feature [2] di Fujaba Real-Time Tool Suite, consideriamo la • progettazione e model checking di modelli per safety-critical systems (UML/RealTime) • Probleminel model checking di modelli UML/RT: 1.State explosion problem 2. Difficile integrazione standard model checking nel processo di design incrementale ed iterativo • Soluzioneproposta: applicare un approccio di verifica formale composizionale ed iterativo su un sottinsieme di nozioni UML 2.0

5. 2. FUJABA: approccio MC [3] • Basato su modelli UML 2.0 • Incrementale: design e model checking • Iterativo: design e model checking • Composizionale: model checking • Cosa • STRUTTURA: Real-Time Component Diagram • COMPORTAMENTO: Real-Time State Chart (RTSC) + formule Timed Computation Tree Logic (TCTL) • Come • Modella pattern e componenti sw=> sistema

6. 2. FUJABA overview [1] • Input Uppaal : • - Flat Timed Automata • Timed Computation Tree Logic

7. 2. Esempio: mechatronic rail system [3] • Shuttles autonomi applicano una tecnologia di guida lineare • Viaggiano sul sistema ferroviario dei treni standard • Problema: ridurre consumo energetico coordinando gli shuttles per formare convogli on-demand • Per ottenere economia piccole distanze tra shuttles • SAFETY-CRITICAL ASPECT: coordinazione tra le unità di controllo della velocità degli shuttles =>HARD RT CONSTRAINT

8. 2. Coordination pattern in FUJABA [3] [4] COORDINATION PATTERN = ROLES + CONNECTORS • collegano PORTS che raffinano i roles e permettono la comunicazione • comportamento specificato tramite RTSC • attori della comunicazione descritta dal pattern • devono soddisfare invariantseconstraints • comportamento specificato tramite RTSC • descrivono comunicazione, interazioni tra le componenti del sistema • vincolati da constraintsspecificati in formule

9. 2. Componenti e sistema in FUJABA • COMPONENTI SW: costruite integrando e raffinando role del pattern coinvolto. Devono rispettare comportamento specificato dai roles invariants • SISITEMA: costituito istanziando un insieme di componenti e pattern Comportamento necessario per coordinare due shuttle successivi ES. Non ci dev’essere collisione in caso di frenata improvvisa ES. RearRole non può essere in mode convoy se FrontRole è in mode no convoy (pattern constraint) Comportamento specifico per il tipo di role ES. Deve frenare con piena potenza (invariant) ES. Deve frenare con potenza ridotta se è in modalità convoglio

10. 2. Fujaba screen shots

11. 2. Approccio composizionale Pattern constraints in ATCTL formulas • Progettazione patterns e roles • Verifica di ogni pattern individualmente • Progettazione dei tipi di componenti e del loro comportamento • Verifica di ogni tipo di componente • Costruzione del sistema istanziando componenti e connettendo porte Model checking per verificare constraints Componente corretta se soddisfa invariants dei refined roles e se non ci sono deadlock DA NOTARE: assicura corretta composizione semantica a partire dalla corretta composizione sintattica (rigorosa)

12. 2. Approccio incrementale [1] • STEP 1)seleziona pattern o componenti composti minimali che contengono tutti gli elementi referenziati dalla proprietà • STEP 2)controlla la proprietà : • se è soddisfatta, fine • altrimenti estende aggiunge componenti interconnesse a quelle già selezionate se non ci sono più componenti interconnesse, seleziona i vicini uno ad ogni passo e li aggiunge

13. 2. Consistency management [4] • Consistenza tra proprietà ed elementi strutturali e comportamentali • Mantenuto lo stato della proprietà • - TRUE proprietà rispettata • - FALSE proprietà non rispettata • - UNSAFE elementi del modello nell’ultimo check potenzialmente inconsistenti • Regole: • Comportamento di un pattern o di un role è cambiato => marcate UNSAFE le sue proprietà + quelle associate alle componenti coinvolte • 2) Componente o il suo comportamento è modificato => marcate UNSAFE le proprietà correlate • Check solo sulla parte unsafe

14. 2. Sintesi di pattern da scenari [5] [6] • SceBaSy Plugin per Fujaba Real Time Tool Suite per sintetizzare real-time coordination pattern da Sequence Diagram UML 2.0 • Idea: • esprimere il comportamento desiderato tramite scenari parametrizzati con vincoli sul tempo • sintetizzare automaticamente gli scenari in TCG • sintetizzare automaticamente TCG in RTSC • fae analisi per evidenziare errori (sintattici, conflitti tra scenari, deadlock) • quando RTSC sono verificati, sintetizzare automaticamente i coordination pattern Sequence diagram Time constraint graph TCG Model chedcking Coordination pattern RTSC

15. 3. CHARMY: cos’è • Charmy è un framework che permette la progettazione e la verifica formale di sistemi software • Tra tutte le festure di Charmy tool [7] consideriamo • progettazione e model checking di architetture software rispetto a requisiti funzionali • Probleminel fare model checking: 1.State explosion problem 2. Skills in formal specification • Soluzioneproposta [8]: applicare un approccio di verifica iterativo su modelli basati su UML senza dover dare una specifica formale

16. 3. CHARMY: approccio MC e overview • Modelli basati su UML • Check a livello architetturale • Incrementale: design e model checking • Iterativo: processo • Composizionale: model checking di sa basate su middleware Cosa • STRUTTURA: Component Diagram • COMPORTAMENTO: State Diagrams + Scenari PSC Come • Modella architettura software, comportamento delle componenti e proprietà [8]

17. 3. Property Sequence Chart (PSC) [9] [10] [14] Wizard W_PSC: domande testuali per la traduzione dei requisiti in scenari

18. 3. Charmy’s screen shots

19. 3. Approccio composizionale [11] Idea:decomporre verifica di un insieme di proprietà dell’architettura sw in verifica di proprietà locali sulle singole componenti architetturali per mezzo del compositional reasoning Def: A architettura sw, Z insieme di proprietà soddisfatte da A, M middleware, P insieme di proprietà soddisfatte da M, S sistema risultante da A + M + I (interfacce) Scopo: dimostrare che anche S soddisfa Z (sotto alcune assunzioni) • proprietà locali alle componenti • proprietà sulle interazionicomponenti-interfacce • proprietà di comportamento di M • -proprietà sulle interazioni interfacce-middleware

20. 3. Approccio iterativo ed incrementale[8] • Specifica architettura e proprietà iniziali • Verificare se l’architettura garantisce requisiti funzionali espressi dalle proprietà. Soddisfatti ? • 3a. Termina il processo • 3b. Raffina i modelli e le proprietà focalizzandosi su parti critiche dell’architettura e torna a verificare la SA

21. 3. Consistency checks [12][13] • Valida modello dinamico della SA rispetto a coordination requirements • STEP 1- Coordination policies catturate a livello requisiti • STEP 2- Coordination policies usate per guidare descrizione architetturale • STEP 3- SA validata rispetto ai coordination requirements • STEP 4- SA utilizzata per guidare coordination model • INPUT • Macchina a stati delle componenti (tradotte in Promela) • Scenari (tradotti in formule LTL) • Spin verifica se il comprtamento espresso degli scenari è ben implementato sul modello Promela • - prima validazione del modello architetturale che dopo può essere usato per fare analisi di safety e liveness • Spin può verificare proprietà di deadlock o violazioni di constraint siulle macchine a stati

22. 3. Consistency checks [12][13] • Assunzione: gli scenari iniziali riflettono il flusso di esecuzione desiderato (non desiderato) • Check tra modelli architetturali per evitare errori di specifica statici: • identificatori degli stati univoci negli state diagram; • ogni state diagram deve avere un solo stato iniziale; • per ogni send (receive) in una componente, deve esistere un receive (send) in un’altra; • sequence diagrams può contenere solo messaggi già inseriti nello state; • sender e receiver di un msg devono essere gli stessi (componenti) nel sequence e nello state; • messaggi con lo stesso nome devono avere lo steso numero di parametri;

23. 3. Approccio di slicing ed abstraction [15] • Program Slicing:tecnica definita sui linguaggi di programmazione che cerca di decomporre un sistema, estraendo elementi basici, come variabili o statement, correlati ad una particolare computazione • Slicing architetturale: sottinsieme del comportamento della SA che cerca di isolare le parti coinvolte nel criterio di slicing • Architectural abstraction:tecnica per astrarre parti del sistema coinvolte nel criterio di astrazione ma che non sono direttamente legate alla sua formulazione.

24. 4. Confronto

25. 4. Confronto

26. 5. Future works (Charmy) • Considerare tempo: timed automata, real-time model checker ed estensione PSC e W_PSC • oppure profilo per real-time in UML, real-time model checker ed estensione PSC e W_PSC • Inserire ulteriori model checker per confronti sull’efficienza • Approfondire approccio composizionale per generalizzarlo • Indagare maggiormente tecniche di slicing ed abstraction • Effettuare studio di fattibilità su modellazione ed analisi di Service Oriented Architecture e Dynamic Architecture • Sviluppare un CVS Miglioramenti dell’usabilità • scaricare ed installare plugin automaticamente • uniformare notazione ad UML 2.0 • plugin per Eclipse • maggiore documentazione • case study di esempio nel tool

27. 5. Future works (Fujaba) • Considerare model checking architetturale: plugin per rappresentare architettura + plugin per proprietà • Integrare l’analisi di sistemi real-time con quella di sistemi concorrenti • case study industriali Miglioramenti dell’usabilità • maggiore documentazione ed in lingua inglese • case study di esempio nel tool

28. References [1] Hirsch, M., Giese, H.: Towards the Incremental Model Checking of Complex RealTime UML Models. In: Proc. of the Fujaba Days 2003, Kassel, Germany. (2003) [2] Fujaba Website: www.fujaba.de [3] Sven Burmester, Holger Giese, Martin Hirsch, and Daniela Schilling, “Incremental Design and Formal Verification with UML/RT in the FUJABA Real-Time Tool Suite”, in Proc. of SVERTS2004, pp. 1--20, October 2004. [4] Sven Burmester, Holger Giese, Martin Hirsch, Daniela Schilling, and Matthias Tichy, 'The Fujaba Real-Time Tool Suite: Model-Driven Development of Safety-Critical, Real-Time Systems', in Proc. of ICSE 2005, pp. 670--671, ACM Press. [5] H. Giese and S.Tissen. The SceBaSy PlugIn for the Scenario-Based Synthesis of Real-Time Coordination Patterns for Mechatronic UML. In Proc. of the 3rd International Fujaba Days 2005, Paderborn, Germany, pp. 67--70, September 2005. [6] Holger Giese, Stefan Henkler, Martin Hirsch, and Florian Klein, “Nobody's perfect: Interactive Synthesis from Parametrized Real-Time Scenarios”, in Proc. of the 5th ICSE 2006 Workshop SCESM'06, pp. 67--74, ACM Press, May 2006. [7] Charmy Website: http://www.di.univaq.it/charmy/

29. References [8] P. Pelliccione, P. Inverardi, H. Muccini, “ Charmy: A framework for Designing and Validating Architectural Specifications”. Tech. Report April 2005. Submitted for publication. [9] M. Autili, P. Inverardi, and P. Pelliccione, “A Scenario Based Notation for Specifying Temporal Properties”. SCESM'06. [10] PSC Project WebSite: http:// www.di.univaq.it/psc2ba [11] M. Caporuscio, P. Inverardi, P. Pelliccione, "Compositional Verification of Middleware-Based Software Architecture descriptions". In ICSE 2004. [12] P. Inverardi, H. Muccini, P. Pelliccione, "Checking consistency between architectural models using Spin". In Proc. of STRAW2001. [13] P. Inverardi, H. Muccini, P. Pelliccione, "Automated Check of Architectural Models Consistency using Spin". In ASE 2001. [14] M. Autili, and P. Pelliccione, “Towards a Graphical Tool for Refining User to System Requirements”. GT-VMT06. To appear in ENTCS. [15] Daniela Colangelo, Daniele Compare, Paola Inverardi, and Patrizio Pelliccione “Reducing Software Architecture Models Complexity: a Slicing and Abstraction Approach”.FORTE 2006.