FUJABA vs. CHARMY: confronto della feature model checking (Analisi e Testing di Sistemi a Componenti) Università degli Studi dell’Aquila FACOLTA’ DI SCIENZE.

Presentazione sul tema: "FUJABA vs. CHARMY: confronto della feature model checking (Analisi e Testing di Sistemi a Componenti) Università degli Studi dell’Aquila FACOLTA’ DI SCIENZE."— Transcript della presentazione:

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 Muccini Stud.ssa: Romina Spalazzese matr.162992

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

3 Tecnica automatica basata sul modello: controlla se una determinata proprietà è valida per un certo modello di un sistema. Risultato: true o false + controesempio finite state model STEP 1 - Crea un finite state model (FSM) del sistema proprietà STEP 2 - Specifica proprietà critiche di correttezza (safety, liveness) Valida STEP 3 – Valida il modello rispetto alle specifiche 1. Model Checking 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) Problemi nel model checking di modelli UML/RT: 1. State explosion problem 2. Difficile integrazione standard model checking nel processo di design incrementale ed iterativo Soluzione proposta: 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] SAFETY-CRITICAL ASPECT: coordinazione tra le unità di controllo della velocità degli shuttles =>HARD RT CONSTRAINT Problema: ridurre consumo energetico coordinando gli shuttles per formare convogli on-demand Per ottenere economia piccole distanze tra shuttles Shuttles autonomi applicano una tecnologia di guida lineare Viaggiano sul sistema ferroviario dei treni standard

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

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. Deve frenare con potenza ridotta se è in modalità convoglio Comportamento specifico per il tipo di role ES. Deve frenare con piena potenza (invariant) ES. RearRole non può essere in mode convoy se FrontRole è in mode no convoy (pattern constraint)

10 2. Fujaba screen shots

11 2. Approccio composizionale 1. Progettazione patterns e roles 2. Verifica di ogni pattern individualmente 3. Progettazione dei tipi di componenti e del loro comportamento 4. Verifica di ogni tipo di componente 5. Costruzione del sistema istanziando componenti e connettendo porte Model checking per verificare constraints corretta 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) Pattern constraints in ATCTL formulas

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: 1) 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 RTSC Model chedcking Coordination pattern

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 Problemi nel fare model checking: 1. State explosion problem 2. Skills in formal specification Soluzione proposta [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 interazioni componenti- interfacce - proprietà di comportamento di M -proprietà sulle interazioni interfacce- middleware

20 3. Approccio iterativo ed incrementale [8] 1. Specifica architettura e proprietà iniziali 2. 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 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; 3. Consistency checks [12][13]

23 3. Approccio di slicing ed abstraction [15] o Program Slicing: o 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 o Slicing architetturale: o Slicing architetturale: sottinsieme del comportamento della SA che cerca di isolare le parti coinvolte nel criterio di slicing o Architectural abstraction: o 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 CaratteristicheFujabaCharmy UMLUML 2.0UML 1.x based, UML 2.0 Tecnologia del toolA plugin Sistemi verificatiReal-time systemsConcurrent systems Tipo di verifica Safety, liveness a livello disegno Safety, liveness a livello architettura software Modelli verificatiCompleti o incompleti Numero di verifiche Verifica 1 volta ogni tipo di componente non ogni istanza Verifica sistemi ma prevede tecniche di slicing ed absraction State explosion problem Mitiga state explosion problem Riduce state explosion problem

25 CaratteristicheFujabaCharmy Usabilità Nasconde complessità di modellazione ma proprietà espresse in formule Nasconde complessità di modellazione soprattutto delle proprietà Specifica di input Component Diagram, coordination pattern, RTSC, formule TCTL Component, state machine, PSC Caratteristiche del MC Compositional ed incremental model checking Compositional MC di sistemi middleware based ed incremental model checking Applicazioni Casi studio teorici e di progetti di ricerca Numerosi casi studio industriali StilePermette di inserire vincoli Non permette di inserire vincoli 4. Confronto

26 + 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 5. Future works (Charmy) 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 [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.dewww.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/http://www.di.univaq.it/charmy/ References

29 [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/psc2bawww.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. References