A Practical Architecturalcentric Analysis Process

1
A Practical Architectural-centric Analysis Process

• Antonio Bucchiarone
• PhD Student IMT Graduate School
• Via S. Micheletto, 55100 Lucca (Italy)
• and
• Henry Muccini and Patrizio Pelliccione
• Dipartimento di Informatica, Università
  dellAquila

2
My CV

• PhD Student of IMT Graduate School of Lucca
  Italy.
• Member of ISTI-CNR of Pisa.
• Working jointly with S.Gnesi, A. Bertolino
  (ISTI-CNR) and H. Muccini, P. Pelliccione
  (UnivAQ).
• Research Areas
• Formal Methods
• Software Architecture
• Dynamic Software Architecture

3
Agenda

• Our Context
• Main Goals of Industries and Academia
• Our proposal ModTest
• Integrating Analysis Techniques
• ModTest
• Tool Support and Our Experience
• Siemens Case Study
• Conclusions (advantages and limitations)
• Future Work

4
Our Context

• Complex and distributed SW and HW systems
• Model-based specification of an SA
• There is a huge relationship between what we
  specify and what kind of analysis we may perform
• Modeling for documenting
• Modeling for analysis
• Integration of analysis techniques
• Testing, model-checking analysis require specific
  formalisms and annotations on UML-based models

5
Industry and Academia Main Goals

• G1 to produce highly-dependable systems and
  limiting analysis costs
• ADL for rigorous and formal SA modeling and
  analysis
• Model-based (semi-formal) notations
• Many extensions and profiles to adapt UML to
  model SAs
• G2 to create an architecture-centric suitable
  process from requirements to deployment
• How SA may be integrated with other phases of the
  SW life-cycle
• Results propagation to lower levels
• Tool supported process is missing
• Model-checking and Testing
• To analyze SW systems and identify hidden faults
• An adequate developers expertise and skills on
  formal methods
• Difficult automation
• Industries are not encouraged to use these
  techniques

6
Our Proposal ModTest

• Permits to verify SAs and to produce
  high-dependable systems
• UML-based specifications without formal languages
• Model-checking and Testing integration
• Tool support from SA specification to test
  procedures generation
• Bridges the gap between requirements,
  architecture and coding

7
Integrating Analysis Technique
validate the SA model conformance with respect
to selected functional properties
Charmy Project www.di.univaq.it/charmy
provide confidence on the implementation
fulfillment to its architectural spec SA-based
Testing
8
ModTest Model-Checking driven Testing
a1 Requirements are identified and analyzed a2
The SA is designed using UML-based notation for
SA modeling utilized in Charmy a3 validation of
SA conformance to certain properties a4 SA
Revision a5 extraction of test sequences (by
TeStor) a6 Test cases implementation a7 SA
implementation (Java/A or ArchJava) a8 Test
execution (industrial test execution process)
9
Tool Support - I

• a1
• W_PSC a speculative tool that facilitates
  understanding and structuring requirements
• Input a set of sentences
• Output temporal property expressed in Property
  Sequence Chart (PSC)
• PSC2BA translates PSC in Büchi automata
• a2-a3-a4
• Charmy an extensible tool for Architectural
  Analysis
• SA specification through state diagrams of
  architectural components
• Integration with PSC and PSC2BA (properties)
• Translation into Promela (SPIN Model-Checker)

10
Tool Support - II

• a5
• TeStor TEst Sequence generaTOR
• Input UML state and sequence diagrams
  (properties)
• Output OutSD, test sequence specifications

11
Experience

• SA-based Model-Checking
• Telcordia
• Marconi
• Siemens C.N.X
• Terma Gmbh
• SA-based Code Testing
• PSTDA Italy
• The Whiteboard study (Academia)
• ModTest
• Siemens
• Terma Gmbh

12
Siemens Case Study

• The standard TLC functional model in Siemens in
  the Synchronous Digital Hierarchy (SDH), standard
  by ETSI and ITU-T
• The functional model is built around two specific
  concepts
• network layering, with a client/server
  relationship between adjacent layers, and
• the atomic functions, to specify the behavior
  of each layer.

13
The OS Layer Requirements (a1)

• Based on OS specification documents
• REQ1 when the OS_TT atomic function detects LOS
  defect (dLOSon), dLOS condition is reported as a
  failure (cLOSon) to the Manager. Moreover, a dLOS
  active condition is reported to the OS_A using
  the Trail Signal Fail (aTS-Foff) message
• REQ2 if the OS_RS_A atomic function detects a
  LOF defect (dLOFon) and no dLOS occur, dLOF
  condition is reported as failure (cLOFon) to the
  Manager

PSC notation
14
The OS Layer SA model (a2)
15
Charmy Application

• The requirements to be proven have been
  formalized in the form of Charmy scenarios (PSCs)
• The scenarios are automatically translated in
  Büchi Automata
• The architectural state machine model is
  automatically translated into Promela code
• SPIN has then been run and no errors have been
  detected

16
TesTor Application

• Taking in input the properties validated in
  Charmy (PSCs that are named inSD)
• TeStor outputs more informative scenarios usable
  as test specifications (outSD)
• Starting from a test scripts database it would be
  possible to associate to an outSD event the
  related script(s) able to inject (detect) the
  event itself into (out) from the system under
  test.

17
Conclusions - I

• Advantages
• Reduction of modeling complexity and the state
  explosion problem by model-checking at the
  architectural level
• Hiding the formal model complexity
• The knowledge on SPIN is not required
• Test specifications from the architectural model
• Instead of directly from requirements
• Useful synergy between model-checking and testing
• Automation Charmy, TeStor, PSC, and W_PSC are
  implemented inside the same framework

18
Conclusions - II

• Main limitations
• Initial investment required (time and human
  resources) to model and validate the system
• Terma 700 Man/Hours
• Tool support
• Charmy and TeStor are initially developed as
  academic tools
• Hiding the formal model complexity
• Modeling and analysis effort will be re-paid with
  a better documented architecture
• Improved alignment among validation techniques

19
Future Works

• We plan to develop new versions of Charmy and
  TeStor improving our industry collaborations
• To have real relations with current UML
  distributions commonly used in the industry
  collaborations
• An ADL UML, called DUALLy is developing

20

• Thank you for your attention!
• Antonio Bucchiarone
• PhD Student IMT Graduate School
• Via S. Micheletto, 55100 Lucca (Italy)
• antonio.bucchiarone_at_imtlucca.it