Henry Muccini and Patrizio Pelliccione Software Engineering and Architecture SEA Group,

1
USING MODEL-CHECKING TECHNIQUES FOR
ARCHITECTURE ANALYSIS AND FORMAL PROTOTYPING

• Henry Mucciniand Patrizio PelliccioneSoftware
  Engineering and Architecture (SEA) Group,
• Computer Science Department
• University of LAquila, Italy
• http//www.di.univaq.it

2
Outline

• The Context and Motivations
• Who are we
• Software Architecture (SA)
• Charmy outline
• Our proposal
• Model Checking
• Charmy

3
Who are we

• SEA Group
• Software Engineering and Architecture
  GroupDipartimento di InformaticaUniversity of
  LAquila Italy
• Our interests
• Software Architecture
• Analysis Model Checking, Testing, Performance
• Non-functional properties Performance,
  Adaptability, Security
• Coordination and Software Architecture
• Modeling notations
• Software Engineering
• UML and Software Architecture, performance, Web
• Web applications and Data Modeling
• Security and Requirements/Architectures

4
Software Architecture (SA)
A bit of History PhDThesis, Ch2

• 1992 and 1993
• SA is recognized as an independent area of
  research
• 1993-1995
• SA described through box and line, informal,
  diagrams
• 1995-2002
• Architectural Description Languages (ADLs) are
  introduced to formally describe SA
• 1997-2003
• more interest on dynamic aspects of SA
• SA used in academic and research
• SA recognized as a valid tool to describe
  complex, concurrent, real systems
• ...

5
Software Architecture

• Perry and Wolf, 92 PerryWolf92
• Architecture is concerned with the selection of
  architectural elements, their interactions, and
  the constraints on those elements and their
  interactions necessary to provide a framework in
  which to satisfy the requirements and serve as a
  basis for the design.
• elements are divided into processing elements,
  data elements and connection elements
• Garlan and Shaw, 93 GarlanShaw93
• SA for a specific system may be captured as a
  collection of computational components - or
  simply components - together with a description
  of the interactions between these components -
  the connectors

6
In general terms

• Describes (in a formal language) how a system is
  structured into components and connectors
• ?
• Components
• computation
• Connectors
• interaction
• Ports, Interfaces,
• how these
• components interact

SA Structure (topology)
SA Dynamics (behavior)
7
Architecture Description Languages (ADLs) and
Views

• ADLs ADL_Neno97, NenoTaylor 2000
• Darwin FSP ? Distributed systems
• Rapide ? Events
• Wright ? Behavioral Properties
• Chemical Abstract Machine (Cham) ? Reactions
• C2SADL ? Dynamic Systems
• Koala ? Product Families
• xADL1.0 ? Implementation mappings
• ...
• Architectural Views Kruchten SAInPractice
• Different concepts specified/modeled from
  different viewpoints
• Different perspectives

8
Chat example

• Many users can chat using a connection to a chat
  server.
• The user needs to be registered to communicate
• The chat system keeps track of the users
  connected, storing information on when they were
  connected, their locations and the time.
• Other information cannot be stored for privacy
  reasons

9
Chat, SA v1
Chat, SA v2
10
A Real Software Architecture Telecom Italia
Network Architecture
WDM
WL
WL
STM-16 Ring
STM-16 Ring
ADM
ADM
ADM
ADM
ADM
ADM
ADM
ADM
ADM
National Level
ADM
ADM
STM-4/16
STM-4/16
SXC 4/1
SXA
SXA
SXA
ADM
ADM
STM-1/4
ADM
STM-4/16
Regional level
ADM
ADM
STM-1/4
ADM
ADM
ADM
ADM
ADM
STM-1/4
ADM
ADM
ADM
ADM
Urban Level
ADM
11
Why SA

• Management of Real Systems (concurrency,
  complexity, ) using high level of Abstraction
• Compositionality
• Static and dynamic views
• To discover errors as early as possible (e.g.,
  deadlock SCP99)
• To drive the software system evolution

12
Why SA (2)

• For Analysis PhDThesis
• SA management is expensive and time consuming
• ? maximize the benefits
• ? Analyze SA as much as possible
• SA and Testing
• Model checking SA
• SA and Coordination models
• SA and Performance Analysis
• Deadlock detection on SA-based specification
• SA and Security
• SA-based development processes
• ADL- based analysis of SA

13
Charmy Outline

• Charmy
• CHeching ARchitectural Models ConsistencY
• Initial Goal
• Validate consistency among scenarios and state
  machines...

Component Q
Component P
14
The Charmy approach
Statecharts, LTS, Automaton
b
Promela Specification
y
c
S P I N
P
Q
Q
P
LTL Formulae
ch1
ch3
ch3
ch2
ch2
Scenarios
UML Sequence, MSC, Scenarios
15
Subsequent goals

• Multiple view SA ASE01
• State machines and scenarios are the most common
  used tools to model behavioral aspects
• Some view modeled by different models -gt
  inconsistency?
• Requirements and SA Straw01
• state diagrams are used to model the system
  dynamics
• scenarios are used to formalize requirements.
• Comparing SAs FIDJI02
• state machines model different architectures for
  the same system
• scenarios model the behavioral properties we are
  interested
• the architecture meets.

16
Current Challenges by Example

• Collaborative writing is defined in LK91 as
  "the process in which authors with different
  expertise and responsibilities interact during
  the invention and revision of a common document".
• Informal high-level requirements
• Authors can write/read a part of the document
• Solve synchronization problems
• Interaction and cooperation
• Awareness and information
• Make the document visible/available to other
  users
• Make a list of involved authors

17
A Users Perspective

• The Manager
• it is connected to a set of computers used by the
  authors
• divides the document in paragraphs
• assigns paragraphs to authors
• waits for the finished files
• The authors
• can be directly connected to other authors
• Elaborates only his part of the document
• Work in a semi-synchronous way

18
CW SA
ITB03
19
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

20
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

21
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

22
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

23
Model Checking and Design Validation

• Simulation (abstract model) Testing (real
  system)
• These techniques explore only some of the
  possible behaviors
• Formal Verifications
• Conduct an exhaustive exploration of all possible
  behaviors
• Examples theorem provers, term rewriting
  systems, proof checkers for verification, model
  checkers
• Model Checker advantages
• Automatic, no supervision or mathematical
  expertise (for analysis)
• In the case of fail the process of Model Checking
  produce a counter-example

24
Model Checker
Model Checker
Specifications
Model Checker Input
Internal representation
Model Checking Algorithm
True or false with counter-example
Internal representation Properties
Properties
feedback
25
SPIN

• The selected Model Checker SpinHome
• The specification language is Promela (PROcess
  MEta LAnguage)
• 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

26
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)

27
The software process in Charmy

• The starting point is an UML specification of the
  system (use case diagrams, activity diagrams,
  etc..) and a requirement document expressed in
  natural language
• To identify system components and describe their
  behavioral and architectural aspects by using
  state diagrams
• To define component interactions by using
  sequence diagrams
• To derive a SA described by Promela model by
  composing the two views obtained in the previous
  steps
• To translate sequence diagrams in LTL formulas
• To check if the Promela model satisfies the LTL
  formulas
• To identify critical subsystems and local
  behavioral properties
• To refine the subsystems SA and to iterate the
  process

28
The software process in Charmy

• How to select the LTL formulas?
• From the specification can be extracted only the
  global behavioral properties
• The properties are obtained with the refinement
  steps focusing on the architectural interactions
• Not exists an automatic way

29
Charmy
30
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 Promela primitives

Component transparency to connectors
31
Step 1 Promela code

• proctype Componente1()
• s0
• ltstate descriptiongtgoto si
• .
• .
• sn
• ltstate descriptiongtgoto sj
• .
• .
• proctype ComponenteM ()
• proctype Connettore()

b

y
c
Statecharts
Q
P
Q
P
m1
m2
m2
m5
Simple connectors
m3
Scenarios
Complex connectors
32
Step 1 Promela code

• Expressing power
• After m1 eventually m2 message
• Invalid end-states
• Unreachable code
• Invariants

• Basic
• ltstate descriptiongt
• messages exchange
• Complete
• ltstate descriptiongt
• messages exchange
• stored the exchange time
• Generated states

• 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
8 states for the basic 15 states for the complete
33
Step2 LTL Formula

• Algorithm
• 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

34
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

35
Step3 SPIN

• Is the temporal order described in the scenarios
  satisfied by some paths in the model generated
  from SPIN?
• Two verifications type
• Exist at least one behavior satisfying the LTL
  formula
• All architectural paths are conform with the
  selected scenario

36
Summarizing the parameters
37
Charmy Tool
38
Case Studies

• NICE (Naval Integrated Communication Environment)
  FME03
• Work developed with Marconi-Selenia -LAquila
• Found malfunctioning caused by message loosing
• Cometa 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

39
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

40
Future work (2/2)

• What formulas we can derive starting from the
  scenarios?
• Message Sequence Charts
• UML Sequence Diagrams
• Extensions
• Considering other properties
• Introducing the time
• Tool
• Increasing the usability
• Integrate the tool with other tools (ArgoUML,
  LTSA,)
• Integrated analysis

41
Some References

• GarlanShaw93 D. Garlan and M. Shaw. An
  Introduction to Software Architecture. World
  Scientific Publishing Company, New Jersey, 1993.
• GarlanPerry95 D. Garlan and D. Perry.
  Introduction to the special issue on software
  architecture. IEEE Trans. on Software
  Engineering, 21(4), April 1995.
• Kruchten P. Kruchten. Architectural Blueprints
  - The 41 View Model of Software Architecture.
  IEEE Software 12 (6), November 1995, pp. 42-50
• ADL_Neno97 N. Medvidovic and R.N. Taylor. A
  Framework for Classifying and Comparing
  Architecture Description Languages. In Proc.
  ESEC/FSE'97, LNCS vol1301, Spet 1997.
• NenoTaylor00 N. Medvidovic and R. N. Taylor.
  A Classification and Comparison Framework for
  Software Architecture Description Languages.
  IEEE Transactions on Software Engineering, vol.
  26, no. 1 (January 2000).
• PerryWolf92 D. Perry and A.L. Wolf. Foundations
  for the Study of Software Architecture. ACM
  SIGSOFT Software Engineering Notes, vol. 17, n.
  4, pp. 40-52, October 1992.
• Kruchten P. Kruchten. Architectural Blueprints
  - The 41" View Model of Software Architecture.
  IEEE Software, 12(6) November 1995, pp. 42-50.
• SAInPractice L. Bass, P. Clements and R.
  Kazman. Software Architecture in Practice. SEI
  Series, Addison-Wesley, 1998.
• LK91 M. Lay and M.Karis. Collaborative writing
  in industry Investigations in theory and
  practice. Baywood Publishing Company, Amityville,
  1991.
• Spin Spin Home Page. http//spinroot.com/spin/wh
  atispin.html

42
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 of Architectural
  Models Consistency using SPIN. In
  Proc.Automated Software Engineering conference,
  ASE2001, year 2001.
• 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 M.Caporuscio. CoMETA - mobility
  support in the Siena publish/subscribe
  middleware. Masters thesis, Università degli
  Studi dellAquila - Dipartimento di Informatica,
  LAquila- 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.