Software Architecture-based Testing and Model-checking

Software Architecture-based 

Testing and Model-checking 

- ECI 2005, University of Buenos Aires - 

Course Web-site: [www.di.univaq.it/muccini/ECI05/] 

Lecture 4(part 1): Charmy 

SEA Group 

2 

SEA Group 

3 

Lecturer: 

Henry Muccini 

Assistant Professor, Computer Science Department 

University of L'Aquila -Italy 

muccini@di.univaq.it 

[www.di.univaq.it/muccini] – [www.HenryMuccini.com] 

Copyright Notice 

» The material in these slidesmaybe freelyreproduced and 

distributed, partiallyor totally, asfar asan explicit reference 

or acknowledge to the material author ispreserved. 

© 2005 by H. Muccini / ECI 2005 Course 

Acknowledgment 


Henry Muccini 

» This work is joined with Patrizio Pelliccione and Paola 

Inverardi, University of L’Aquila. 

» The CharmyWebsite isavailable online: 

www.di.univaq.it/charmy 

1

SEA Group 

4 

SEA Group 

5 

SEA Group 

6 

Agenda 

» Model-Checking 

» Charmy 

» SPIN 


Software Model Checking 

» Model Checking: 

- It checks whether a certain property isvalid for a certain 

model of a system [Ruys_PhDThesis] 

> Model checkingis a model-based, automatic techniquethat, 

given a finite-state model M of a system and a propertyP, 

checks the validity of P in M 


Model Checking steps 

» Used in studying behaviors of reactive systems 

» Typically involves three steps: 

1. Create a finite state model (FSM) of the system design 

> Formal languages 

2. Specify critical correctness properties 

> Formal languages 

3. Validate the model w/r to the specifications 

- It checks whether a certain property is valid for a certain model of a 

system [Ruys_PhDThesis] 


2

SEA Group 

7 

SEA Group 

8 

SEA Group 

9 

Model Checking Activities and Artifacts 

Input Model Checker Output 

System 

Specification 

Properties 

Formal 

Languages 


Create a FSM 

» FSM languages 


Internal 

representation 

Internal 

representation: 

Properties 

feedback 

Model Checking 

Algorithm 

- focus on expressing concurrency, synchronization, and 

communication 

- abstract details of internal computations 

- must be precise and unambiguous (formally defined syntax and 

semantics) 

» We will use Promela for giving system 

descriptions 

Specify correctness properties 

» Safety properties: 

- Nothing “bad” ever happens 

> Formalized using state invariants 

- execution never reaches a “bad” state 

» Liveness properties: 

- Something “good” eventually happens 

> Formalized using temporal logic 

- special logic for describing sequences 


Exhaustive and 

automated 

True or false 

with 

counter-example 

3

SEA Group 

10 

SEA Group 

11 

SEA Group 

12 

Validate the model 

» “Execute” the model to test it 

- simulate executions of the system 

- check satisfaction of safety properties along simulated executions 

» Exhaustive analysis 

- generate reachability graph to verify safety and livenessproperties 

» Generate counterexamples to illustrate failures 


Model Checking and Design Validation 

» Model Checker 

- advantages: 

> automatic 

> exhaustive 

> it produces a counter-example(in the case of fail) 

- limitations: 

> state explosionproblem 

> skills on formal methods are required 


Model-Checking limitation and solutions 

» State Explosion Problem 

» Solutions: 

- Compress 

> BDDs (Binary DecisionDiagrams) [Bryant 1986] 

- Reduce 

> Partial-Order Reduction 

- Exploresonly relevantportions of the state space 

- Idea: usually the validity of a search is independentfrom the 

orderof intearleavingof concurrentevents 


4

SEA Group 

13 

14 

Model Checker: BDDs 


Model Checker: other solutions to state explosion 

» Compositional reasoning 

- Idea: to decompose a propertyinto sub-properties which maybe checkedon 

sub-systems. 

Assumptionon the environment are necessary: 

> Assume-guarantee paradigm 

» Abstraction 

- Cone of influence reduction: 

> Idea: to eliminate unnecessary variables 

- Data abstraction 

» Symmetry 

» Induction 

SEA Group 

SEA Group 

15 

> Idea: substitute current variables with abstract ones 


Charmy 


5

SEA Group 

16 

SEA Group 

17 

Model Checking Activities and Artifacts 

Input Model Checker Output 

System 

Specification 

Properties 

Formal 

Languages 



Internal 

representation 

Internal 

representation: 

Properties 

feedback 

CHARMY: CHARMY Model-checking SAs 

System 

Specification Properties 

Engines: 

SEA Group diagrams to formal 

18 © 2005 by languages H. Muccini / ECI 2005 Course 

Model Checking 

Algorithm 

properties 

SA validation wrt Requirements [CharmyWeb] 

Notations: 

UML-based 

SA spec 

Step1 

SA spec properties 

Step3 

Exhaustive and 

automated 

True or false 

with 

counter-example 

(www.di.univaq.it/charmy) 

Step2 

6

SEA Group 

19 

SEA Group 

20 

SEA Group 

21 

CHARMY 

» Iterative process 

» Tool support: 

- offers a graphicaluser interface to drawstate diagrams and 

scenarios 

- a plugin which allows to input existingdiagram in the XMI 

format 

- a translation engine to automatically derive Promela code and 

Buchi Automaton 


Experience 

» SA-based Model-Checking 

- Telcordia [FIDJI02] 

- Marconi [FME03] 

- Siemens C.N.X. 

- TermaGmbH 

» SA-based Code Testing: 

- PSTDA Italy[ICSE00,ICSE01] 

- The Whiteboard study [BookChapter03] 

» ModTest: 

- Siemens [ITM04, Subm05] 

- TermaGmbH 


The ModTest/Charmy Team 

» SEA Group, University of L’Aquila: 

- Paola Inverardi, Henry Muccini, Patrizione Pelliccione (Caporuscio, Cortellessa, Di Marco) 

- Ezio di Nisio (funded by Siemens C.N.X.) and Maya Cardone (funded by Terma GmbH) 

- Currently: 10 bachelor and master thesis 

» CurrentIndustrialpartners: 

- Siemens C.N.X. 

- Terma GmbH 

» Currentaccademiccollaborations: 

- ISTI, CNR (Pisa) 

- ITM, Lucca 

- University of Luxembourg 

- University of California, Irvine 

- University of Paderborn 


7

SEA Group 

22 

SEA Group 

23 

SEA Group 

24 

Challenge 1 : informal but formal 

» Formal ADLs 

+ Automatic analysis 

- Time, cost and skills 

» Informal or Semi-Formal description 

+ Faster and easier 

- Low automation 

» Charmy: 

- model-based specifications used to specify the SA topology and 

behavior 

- a formal Promela prototype is automatically generated 


Challenge 2 : incremental analysis 

» SA-based software process: 

- It is not clear how to incrementally identify and analyze components 

and connectors 

- Refinement and Analysis 

- Goal: 

> To identify a way to detect faulty components that can be successively 

refined and analyzed again 

» Charmy: 

- An high-level architecture is analyzed; 

- Faulty components are refined and re-analyzed 


Challenge 3 : Automation 

» To generate Promela specification automatically from 

model-based specifications 

» Goal: to help the industry to meet model checking and 

formal analysis 

» Charmy: 

- A tool is under development 


8

SEA Group 

25 

SEA Group 

26 

SEA Group 

27 

Summarizing 

» Model-checking analysis without formal specification 

knowlege 

» Incremental analysis of refined components 

» Deadlock, liveness, inconsistency, incompleteness 

detected at the architecture level 

» Testing and Model-checking of Software Architecture 


SPIN 

† The selected Model Checker [BellLabs 1980] 

† The specification language is Promela (PROcess MEtaLAnguage) 

† The properties can be expressed using the temporal logic LTL (Linear-time 

Temporal Logic) 

† Features: 

† on-the-fly verification i.e. it no need to construct a global state graph as 

a prerequisite for the verification 

† random, interactive e guided simulations 

† partial order reduction techniques, and (optionally) BDD-like storage 

techniques to optimize the verification runs 


SPIN: Promela 

† Promela supports the not-determinism 

† A Promela program consists of: 

† Processes 

† Communication channels 

† Variables 

† Concurrent processes communication: 

† Shared memory 

† Buffered channels (asynchronous communication) 

† 0 dimension channels (rendez-vous communication) 


9

SEA Group 

28 

SEA Group 

29 

SEA Group 

30 

CHARMY (www.di.univaq.it/charmy) 

Step1 



Step3 

Step2 

Step 1: Promela code 

† Each components state diagram is translated in a Promela process, 

proctype 

† A special process connector is added to manipulate the communication 

between the components 

† The translation maintain the connectors only for the complex 

communications 

† Synchronous /Asynchronous communications are realized with 

Promelaprimitives 

Component transparency 

to connectors 


a 

?ch1 

!ch2 

b 

c 

… 

Statecharts 

!ch1 

x 

?ch2 


y 

Ch1Connector 

Q P 

!ch1 

OP() 

?ch1 

proctypeComponente1() 

{ 

s0: 

sn: 

} 

. 

. 

;goto si ; 

. 

. 

;goto sj ; 

proctypeComponenteM () 

{…} 

proctypeConnettore() 

{…} 

10

SEA Group 

31 

SEA Group 

32 

SEA Group 

33 


Basic 

† : 

messages exchange 

Complete 

† : 

messages exchange + 

stored the exchange time 

†Generated states 

8 states for the basic 

15 states for the complete 


Step2: LTL Formula 

Algorithm: 


Expressing power: 

•After m1 eventually m2 message 

•Invalid end-states 

•Unreachable code 

•Invariants 

Expressing power: 

•All basic verifications 

•The message is exchanged at the time t 

•Message ordered punctually 

•Used principally for the “negative 

scenarios” 

9684 states for the basic 

2263030 states for the complete 

† To analyze the message order in the scenario 

† To analyze the arrows type (synchronous, asynchronous,…) 

† To identify “when” a send or receive action is performed over 

each channel 

† To generate an LTL formula containing the same message order 

Step2: LTL formula 

† Other information used: 

† The only allowed actions are expressed in the scenario: Strict check 

† It is allowed only with the Complete translation algorithm 

† Also other actions not expressed in the scenario are allowed: Loose check 

† These checks type are embedded in the LTL formula. To define the LTL 

formula we are interested in, we need information not expressed in the 

scenarios 


11

SEA Group 

34 

SEA Group 

35 

Step3: SPIN 

† Is the temporal order described in the scenarios satisfied 

by “some” paths in the model generated from SPIN? 

† Two verifications type: 

1. Exist at least one behavior satisfying the LTL formula 

2. All architectural paths are conform with the selected scenario 


Summarizing the parameters 

EXIST 

FOR 

ALL 

SEA Group 

36 

» Frequency: High 

STRICT 

» Use: negative scenarios 

» Algorithm: Complete 

Do not sound 


Tool Support 


LOOSE 

» Frequency: Very High 

» Use: negative scenarios 

» Algorithm: Basic 

» Frequency: Very High 

» Use: Properties that the 

system must satisfy 

» Algorithm: Basic 

www.di.univaq.it/charmy 

12

SEA Group 

37 

SEA Group 

38 

SEA Group 

39 

Case Studies 

† NICE (Naval Integrated Communication Environment) [FME03] 

† Work developed with Marconi-Selenia-L’Aquila 

† Found malfunctioning caused by message loosing 

† Cometa [MasterThesis 

MasterThesis] 

† Extension to the mobility for Siena, a publish/subscribe middleware 

† Analyzed two solutions in order to select the better 

† AOJ2EE [FIDJI02] 

† Active Object on J2EE reference implementation 

† Analyzed two solutions in order to select the better 


Advantages 

» Model complexityand the state explosion reduction 

obtained bySA-levelmodel checking; 

» Iterative approach: continuousrefinement 

» Charmy → easy to use, practicalapproach to modelchecking, 

hidingthe modelingcomplexity; 

» Test specificationsare identified from the architectural 

model (not from requirements) 

- Easiest alignment betweenSA and Test specifications; 

- Easiest control of the design steps and evolution 


Future work (1/2) 

†Possible solution at the state explosion problem 

† Compositional reasoning 

Idea: it is interesting to decompose the system specification into properties that 

describe the behavior of a system's subset. 

To make it, we need of assumptions over the environment: 

† Assume-guarantee paradigm 

† Slicing-Abstraction 

Idea: to cut from the system behaviors not interesting for the verification 

† More abstraction level zooming in the subparts 

† Supported by the tool in the static architecture part 


13

SEA Group 

40 

SEA Group 

41 

SEA Group 

42 

Future work (2/2) 

†What formulas we can derive starting from the scenarios? 

Message Sequence Charts 

UML Sequence Diagrams 

Extensions 

†Considering other properties 

†Tool 

Introducing the time 

Increasing the usability 

Integrate the tool with other tools (ArgoUML, LTSA,…) 

†Integrated analysis 


Some (of our) References 

• [Straw01] P. Inverardi, H. Muccini and P. Pelliccione. "Checking 

consistency between architectural models using SPIN". In Proc. ICSE2001 Workshop ``From Software 

Requirements to Architectures" (STRAW'01), May 2001. 

• [ASE2001] P. Inverardi, H. Muccini and P. Pelliccione. "Automated Check ofArchitectural Models 

Consistency using SPIN”. In Proc. 

Automated Software Engineering conference, ASE2001, year 2001. 

» [PhDThesis PhDThesis] H. Muccini. Software Architecture for Testing, Coordination Models and Views Model 

Checking, PhD thesis, year 2002. 

» [FIDJI02] P. Inverardi, F. Mancinelli, H. Muccini, and P. Pelliccione. An Experience in Architectural 

Extensions: Active Objects in J2EE. In Proc. Int. Workshop on Scientific Engineering of Distributed Java 

Applications (FIDJI'2002), November 2002, Luxembourg. Lecture Notes in Computer Science (LNCS) 

2604, pp. 87 ff. 

» [FME03] D.Compare, P. Inverardi, P. Pelliccione and A. Sebastiani. Integrating model-checking 

architectural analysis and validation in a real software life-cycle. In Proc. FM 2003: the 12th International 

FME Symposium, September 2003, Pisa. LNCS series. 

» [MasterThesis 

MasterThesis] ] M.Caporuscio. CoMETA-mobility support in the Siena publish/subscribe middleware. 

Master’s thesis, Università degliStudi dell’Aquila -Dipartimento di Informatica, L’Aquila- Italy, March 

2002. 

» [ITB03] P. Inverardi, M. Tivoli, and A. Bucchiarone. Coordinators synthesis for COTSgroup-ware systems: an 

example. Published in DMC 2003. Also Technical Report, University of LAquila, Department of Computer Science, 

http://www.di.univaq.it/tivoli/cscw techrep.pdf, March 2003. 


Required Readings 

» Required reading: 

P. Inverardi, H. Muccini, and P. Pelliccione. Charmy: 

A framework for model based consistency checking. 

Technical Report, Dept. of Comp. Science, Univ. of 

L'Aquila, May 2004. http://www.di.univaq.it/charmy 


14

Software Architecture-based 

Testing and Model-checking 

- ECI 2005, University of Buenos Aires - 

Course Web-site: [www.di.univaq.it/muccini/ECI05/] 

Lecture 4(part 2): Charmy in Practice 

SEA Group 

2 

SEA Group 

3 

Lecturer: 

Henry Muccini 

Assistant Professor, Computer Science Department 

University of L'Aquila -Italy 

muccini@di.univaq.it 

[www.di.univaq.it/muccini] – [www.HenryMuccini.com] 

Copyright Notice 

» The material in these slidesmaybe freelyreproduced and 

distributed, partiallyor totally, asfar asan explicit reference 

or acknowledge to the material author ispreserved. 


Agenda 

» The CharmyTool 

» Toolextensibility 

» Get Started 

» An Example 


Henry Muccini 

1

SEA Group 

4 

SEA Group 

5 

SEA Group 

6 

Introduction –Charmy tool 

» Charmy tool allowsthe descriptionof software 

architecturesand propertiesthrougha UML based 

specification 

- Structural Model usedto specifycomponentsand 

connections 

- State Diagrams are used to specifycomponentsbehaviour 

- Scenarios (Sequence Diagrams) are used to specify 

properties 

» Charmy generates Promela code (formal prototypes) 

from models 

» Formal prototypescanbe validated usingthe model 

checkerSPIN 


Case Study –The TC Chain modeling 

» WithinSA·X we modeleda simplified version of thereal 

SCOS-2000 TC Chain 

» Somesimplificationhave beendone, the most relevent of 

thoseare: 

- No blocksand sequences 

- No interlock 

- Onlyone CEV stage 

» We focusedon theVerifier and CEV stage components 


The Charmy Plugin Architecture 


2

SEA Group 

7 

SEA Group 

8 

SEA Group 

9 

Tool Support [ESEC/FSE05 Demo] 


Charmy Notation 

» SA Topology: 


Promela Code 

generation 

- The SA topology is modeled via UML-like 

component diagrams 

> UML 2.0 component diagrams 

» SA Behavior: 

- The behavior of each single component is 

modeled via Charmy annotatedState Diagrams 

» Propertiesto be validated: 

- Properties are modeled via Property Sequence 

- Charts (PSCs) 

SA Topology 


: Notation 

SA and 

properties 

specification 

Buchi 

Automaton 

generation 

SA Topology 

SA Behavior 

Properties 

SA 

components 

Messages 

Next release 

with UML 2.0 

component 

diagrams 

3

!m1(e) 

S0 s1 

SA Behavior 

: Notation 

?m3 ?m2 

!m2 

S0 s1 

S2 

[x!=0]?m1(e)/Op(); 

!m3 

Properties 

Comp P Comp Q 

e: m1 

f: m2 

r: m3 

Component P Component Q 

State machine State machine 

b) 

Between a pair of messages we can 

Regular Fail specify messages: if other messages messages that constituting can should occur 

Constraints: define a set of messages 

Send (“!”) or Receive (“?”) the 

Required (loose never precondition relation) exchanged, 

messages: or for not a 

if 

when desired 

the (strict precondition 

their relation) 

that must never occur in between (or an the 

of a message 

is 

precondition 

satisfied, 

undesired) 

then 

becomes behavior 

the system 

true 

must 

message containing the constraint 

exchange this message. 

SEA Group 

and its predecessor 

‘[‘ 10 guard © ’]’event 2005 by H. Muccini channel_name / ECI 2005 Course ‘/’ op1 ‘;’op2 ‘;’… ‘;’opn 

SEA Group 

11 

SEA Group 

12 

Charmy notation - Topology 

» Each System component is represented by a box 

labeled with its name 

» The relation that lies between two components is 

represented by an arrow 

» With a topology diagram we can only describe the 

System from a statical point of view. 


Scenarios and LTL formulae 

» In an industrial context it is unfeasible to write by hand 

complex LTL formulae, as pointed out by Holzmann 

[Holzmann, FSE02]. 

To this extent, he proposes a tool to write temporal 

properties in a graphical notation. 

» An alternative approach to the specification of LTL 

formulae is presented in [Dwyer, ICSE99], where the user 

may choose an LTL formula from a library of predefined 

formulae. 

» Differently from both approaches, we specify behavioral 

properties using the familiar formalism of sequence 

diagrams and automatically translate them into B¨uchi 

automata 


C1 

4

13 

Charmy notation – Scenarios 

PSC 

Property Sequence Charts 

•Regular messages: are identified by the e label and they denote a set of 

messages that constitute the precondition for a desired (or an undesired) 

behavior. A Regular message must not necessary happen in every system 

execution. However, if it happens, it is relevant 

•Required messages: are identified by the r label. If the precondition for a 

Required message is satisfied, then this message must occur 

•Fail messages: are identified by the f label and identify messages that must 

never occur when its precondition becomes true 

SEA Group 

SEA Group 

14 

SEA Group 

15 


Charmy notation – Scenarios 

» Between a pair of messages we can select 

if other messages can occur (loose 

relation) or not (strict relation). 

Graphically, the strict relation is realized 

whit a thick line that lies the messages 

pair 

» Constraints, graphically represented as a 

filled circle, are introduced to define a set 

of messages that must never occur in 

between the message containing the 

constraint and its predecessor 


Charmy Scenario Editor 


5

SEA Group 

16 

SEA Group 

17 

SEA Group 

18 

Charmy notation – State machines 

To allow the translation process we need to add some semantics 

to make state diagrams close to the Promela sintax 

‘[‘ guard ’]’event channel_name ‘/’ op1 ‘;’op2 ‘;’… ‘;’opn 


Charmy State Editor 


Some examples on scenarios 

» (desired behaviour) 

- if A is followed by B than C must happen 

» (undesired behaviour) 

- A must be never followed by B 


6

SEA Group 

19 

SEA Group 

20 

SEA Group 

21 

Step 1: From State Machine to Promela code 

#define SMN 

#define AMN 

#define TMN 

#define CMN 

#define 0 

: 

a) 

#define MN-1 

» Each components 

state diagram is 

translated in a 

Promela proctype 

» A special process 

connector is added 

to manipulate the 

communication 

between the 

components 


!ch1 

s0 s1 

?ch3 

s2 

?ch1 



!ch2 

State description 

Component P 

?ch2 

s0 s1 

!ch3 

Component Q 

chan syncChannel[SMN] = [0] of {byte}; 

chan asyncChannel[AMN] = [1] of {byte}; 

chan tauChannel[TMN] =[1] of {byte}; 

bool communicationReq[CMN]; 

b) 

bool communicationOk[CMN]; 

active proctype P() 

{s0: 

 

if 

::atomic{; goto s1}; 


fi; 

s1: 

atomic{; goto s0}; 

s2: 

skip; 

} 

c) 

active proctype Q() 

{so: 

if 




fi; 

s1: 

skip; 

} 

Step 2: PSC2BA - From PSC to Buchi Automaton 

» The algorithm: 

- analyzes the message 

order in the scenario 

- analyzes the arrows type 

- identifies “when” a send 

or receive action is 

performed over each 

channel 

- generates a Buchi 

Automaton containing 

the same message order 

PSC 

Property 

Sequence 

Charts 

User 

e: a 

b,c 

e: d 

f: c 

r: e 

ATM 

PSC2BA 

b,c 

e: a 

e: d 

f: c 

r: e 

!b&!c 

S0 

a 

b||c 

1 

S1 

S0 

d 

!d 

1 

S1 

S0 

S1 

S0 

S1 

c 

e 

!c 

1 

!e 

1 

S2 

S2 

1 

1 

7

SEA Group 

22 

SEA Group 

23 

SEA Group 

24 


Step 3: SPIN Verification 


Properties – Validation results (1) 

(Spin Version 4.2.3 -- 5 February2005) 

+ Graph Encoding(-DMA=173) 

Full statespacesearchfor: 

never claim + 

assertionviolations + (if withinscopeof claim) 

acceptance cycles + (fairness disabled) 

invalid end states -(disabledbynever claim) 

State-vector 432 byte, depthreached273, errors: 0 

MA stats: -DMA=165 is sufficient 

Minimized Automaton: 243572 nodes and 819532 edges 

5.00225e+07 states, stored(5.11589e+07 visited) 

2.85938e+08 states, matched 

3.37097e+08 transitions (= visited+matched) 

5.71893e+07 atomic steps 

hashconflicts: 0 (resolved) 

Stats on memoryusage(in Megabytes): 

21809.831 equivalent memoryusage for states (stored*(State-vector + overhead)) 

16.463 actualmemoryusagefor states (compression: 0.08%) 

0.280 memoryusedfor DFS stack(-m10000) 

0.072 other (proc and chan stacks) 

0.104 memorylost to fragmentation 

16.638 total actualmemoryusage 

5837.50user 0.38system 1:37:18elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 

0inputs+0outputs (0major+4227minor)pagefaults 0swaps 


8

SEA Group 

25 

SEA Group 

26 

SEA Group 

27 





never claim + 





MA stats: -DMA=165 is sufficient 

Minimized Automaton: 239561 nodes and 833865 edges 

4.98823e+07 states, stored 


3.29462e+08 transitions (= stored+matched) 










4908.76user 0.30system 1:21:51elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 




pan: acceptancecycle(at depth139) 

pan: wrotepan_in.trail 


Warning: Searchnot completed 



never claim + 





1.50845e+06 states, stored 


9.60326e+06 transitions (= stored+matched) 










148.38user 0.00system 2:28.40elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 



Error investigation – Guided simulation 


9

SEA Group 

28 

SEA Group 

29 

SEA Group 

30 

Tool extensibility 


Tool Extension: Charmy Studio 


Our experience with Plugin Systems: CHARMY 


10

SEA Group 

31 

SEA Group 

32 

SEA Group 

33 

Plugin Systems 

» A plugin is a component, which can optionally be added 

to an existing system at runtime, to extend its 

functionality 

» By using a plugin architecture, we may incrementally 

build software systems, by adding new components to the 

initial core 


Eclipse 

» IBM Eclipse 

- Is a platform which provides the engine to implement systems as 

extensions to the platform itself, by means of plugins 

- To have an idea of the success of this platform, readers can refer 

to several plugins developed for Eclipse, and open source 

projects based on it 

> Eclipse Community Projects and plug-ins. 

http://www.eclipse.org/community/index.html. 


Other plugin systems 

» Text editor Jedit 

» the integrated environment for Java developers NetBeans 

» the music player Nullsoft Winamp 

» the browser Mozilla 

» the model checker Bogor 

- extensible in both the input language and the search and 

optimization engine. 


11

SEA Group 

34 

SEA Group 

35 

SEA Group 

36 

Why Plugin Systems 

» i) we want to be able to extend the kind of analysis we may perform on an 

SA. 

- We recently extended the approach in order to integrate compositional 

verification techniques for architectural analysis, for formal analysis of 

architectural patterns and charmyintegration in the standard life-cycle process. 

» ii) We want charmy to be integrated with other existing tools. 

- We developed a plug which allows to describe the SA through standard UML 

tools, by means of an XMI representation, which may be imported/exported 

from charmy. 

- We developed a plug that, exploiting JSpin, a java interface for SPIN, aims at 

embedding SPIN in charmy. 

» iii) Moreover, we want charmy to be open with respect to the engines used to 

perform analysis. 

- Since we are not tied down to use the model checker SPIN, we are planning to 

use the model checker SMV or the model checker Bogor. 


Get Started 


How to Install 

» Needed Files: 

- Download the latest Charmy version from 

http://www.di.univaq.it/~charmy. Extract the zip folder where 

you want. To run Charmy, you need only to click on runCharmy 

file; 

- Download SPIN from http://spinroot.com/spin; 

> The easiest way to get started with SPIN is to use the graphical interface 

XSPIN. If you want to use the GUI you need to download the Tcl/Tk 

libraries (easy to search on google); 

- You also need a working C-compiler and a C-preprocessor 


12

SEA Group 

37 

SEA Group 

38 

SEA Group 

39 

Charmy use example (1/2) 

» Start Charmy; 

» In the Topology Editor you can create the software architecture 

component diagram using processes and channels; 

» For each process created in the topology editor, you must specify its 

bahaviorthrough the State Editor using State Machine models; 

» At this point, it’s possible to generate the Promela Code (Plug -> 

Promela specified -> Promela Code); if there aren’t errors, in the 

Promela Window is displayed the Promela Source Code referred to 

the architecture; 

» Now you have to copy the Promela Code into a txt file (ex. 

promela.txt); take a look at the code and add (if not done) variables 

used in the pre condition section (ex. bit elapsed; bit time; bit ok; ...); 


Charmy use example (2/2) 

» At this moment, it’s possible to run either a simulation with SPIN 

(see next paragraph) or to create verification properties; 

» To create verification properties you need to define Sequence 

Diagrams from the Sequence Editor; 

- After that it’s possible to generate the BuchiAutomata from the 

Sequence Diagram (Plug -> BuchiAutomata Menu -> BuchiAutomata 

Generation); 

» Copy the code displayed in the BuchiAutomata Window in a txt file 

(ex. automata.txt); 

» It is the moment to validate the SA model conformance with respect 

to selected properties. 


Spin use example (1/4) 

» To start SPIN click on Xspin423 file; 

» You should now have the main Spin control window on 

the display; The main text window that you see offers 

some rudimentary edit and search capabilities. 

» Load the Promela Code: File -> Open -> select file 

promela.txt 

» Next, press the “Run..” button and then select Set 

Simulation Parameters... 


13

SEA Group 

40 

SEA Group 

41 

SEA Group 

42 


» For now, just accept the default settings that are shown, and press the 

Start button, to start a first simulation run. 

- A number of new windows appear. 

> The large panel to the right, labeledMessage Sequence Chart is empty at first, but 

it will display all messages sent and received during the simulation that we are 

about to start. 

> The lower panel, labeledVariable Values, will print the current values of all 

variables and channels that are used during the simulation run. 

> The main panel that appears is labeledSimulation Output. It allows you to 

perform either a single-step simulation, or a continuous random simulation run. 

Choose the latter, by pressing the Run button. Let the run proceed until 

completion. The main panel will show the raw printout from Spin (which is 

running in the background to perform the actual simulation), prefixed by a stepnumber 

in the left margin; 

» When the run completes, the main panel will print the number of 

processes that has been created; 



» Make the main Spin control window that displays the 

Promela text of the leader election protocol visible again; 

» Move the mouse cursor over the boxes and arrows in the 

Message Sequence Chart display on the right. 

- When the mouse cursor is over a square box in the message 

sequence chart, the corresponding Promela source line in the text 

window is indicated, and the source text is shown in the 

sequence chart. 

- The number that is shown in the square boxes if the mouse is not 

hovering over them is a simulation step number, that matches the 

numbers in the left margin of the Simulation Output panel. 



» Now let’s verify the system: 

» Add the buchiautomata source code at the bottom of the Promela 

Code; then select the Set Verification Parameters option from the 

Run.. menu. Accept the default settings of the parameters, or, click 

Advanced Option in order to allow Partial Order Reduction and 

Compression, and press the Run button. Notice again the commands 

that Xspin synthesizes, printed in the log. At this time, Spin is asked 

to generate a verifier, the verifier is compiled and executed, and the 

results are fed back to Xspin for display. 

- If all is well, the results show that there are no errors detected in the 

specification. 

- If in the verification run, Spin detects that some statements are 

unreachable for the given parameters, those statements are highlighted 

in the main Xspin control window with the text of the specification; 

Wait for the simulation completed…. and look at the results!!! 


14

SEA Group 

43 

SEA Group 

44 

SEA Group 

45 

Example: SCOS-2000 TC Chain - 

with Terma GmbH 

PIF 

TCP/IP 

TCP/IP 

User 

MMI 

TC Chain 

TCP/I 

P 

NCTRS 


Example 

» Read the TermaSAXProject.pdf document: 

- It describes the SA.X project 

» Use the TermaBuffer060705.Charmy example to learn 

how Charmyand SPIN work 

- This specification is related to the TermaSAXProject.pdf 

document 


References: Charmy 

» [FIDJI02] P. Inverardi, F. Mancinelli, H. Muccini, and P. Pelliccione. An Experience in 

Architectural Extensions: Active Objects in J2EE. In Proc. Int. Workshop on Scientific 

Engineering of Distributed Java Applications (FIDJI'2002), November 2002, Luxembourg. 

Lecture Notes in Computer Science (LNCS) 2604, pp. 87 ff. 

» [FME03] D.Compare, P. Inverardi, P. Pelliccione and A. Sebastiani. Integrating modelchecking 

architectural analysis and validation in a real software life-cycle. In Proc. FM 2003: 

the 12th International FME Symposium, September 2003, Pisa. LNCSseries. 

» [CharmyWeb] CHARMY Project. University of L’Aquila. CharmyWeb Site. 

http://www.di.univaq.it/charmy, 2005. 

» [CBSE05] Patrizio Pelliccione, Henry Muccini, Antonio Bucchiarone, and Fabrizio 

Facchini. TeStor: Deriving Test Sequences from Model-based Specifications“. Eighth 

International SIGSOFT Symposium on Component-based Software Engineering (CBSE 

2005), St. Louis, Missouri (USA), 15-21 May, 2005. Lecture Notes in Computer Science, 

LNCS 3489, pp. 267-282. 

» [ITM04] A Bucchiarone, H.Muccini, P.Pelliccione, and P.Pierini. Model-Checkingplus 

Testing: fromSoftware Architecture Analysis toCode Testing. Proc. International Testing 

Methodologyworksho, LNCS vol. 3236, pp. 351 -365 (2004), October 

» [Subm05] H.Muccini, P.Pelliccione, P.Pierini and A Bucchiarone, An Architecture-centric 

Approach for Model-checking based Testing in Industrial Contexts. Submitted, April 05 


15

Software Architecture-based Testing and Model-checking

Create successful ePaper yourself

Delete template?

Save as template?