Architecting FT Componentbased Systems: from requirements to testing

1
Architecting FT Component-based Systems from
requirements to testing

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

• Introduction
• Key points
• Our proposal
• Fault Tolerance Requirements
• Fault Tolerance Architecture
• Testing generation and execution
• Mining Control System Application
• Conclusions
• Future Work

3
Introduction

• Complex and critical component-based SW systems
• Aerospace, transportation, energy, etc..
• Denial of services can have economics
  consequences and can endanger human life

• To prevent the introduction of faults
• To avoid service failures when faults occur

Fault Prevention
Fault Removal
Dependability
Fault Tolerance

• To reduce the number and severity of faults
• To estimate present and future incidence and
  consequences of faults

Fault Forecasting
4
Key points

• Fault tolerance (FT)
• One of the most important means to avoid service
  failure in the presence of faults
• Error detection and system recovery
• Software Testing (ST)
• One of the major fault removal techniques
• To evaluate system dependability at run-time
• FT Testing
• Validation of complex component-based systems
• FT support during the entire system life cycle
• Architectural level (FT Component Based SA)

5
Our proposal - I
To complement fault tolerance with fault removal
techniques in order to reduce the number and
severity of all such unexpected faults.

• An approach for developing and validating CBS
  systems according to FT requirements
• It starts with requirements (critical services)
• Fault tolerant component-based SA (CBSA) model is
  realized
• Test case specifications are extracted from CBSA
  to validate the implementation adherence to
  fault tolerance requirements
• We introduce the test strategy to evaluate and
  improve system dependability at run-time
• Running Example Mining Control Case Study

6
Activity A1
A3. Fault tolerance Testing
A1. Fault tolerance Requirements Identification

• Fault tolerance requirements are specified
• Primary is the one that must be always satisfied
• Auxiliary can be set aside in degraded operating
  modes
• Fault scenarios are selected to evidence how the
  system should behave in case of faults
• Use cases are specified and extended in order to
  specify critical services
• Normal Use Cases (N_UCs)
• Exceptional Use Cases (exc_UCs)

A2. Fault-tolerant Architecture Specification
7
Activity A2
A2. Fault-tolerant Architecture Specification

• Identified requirements guide the selection of a
  suitable and FT-SA
• A description of both how the CBSA behaves in
  normal and exceptional situations
• Model-checking techniques in order to prove the
  CBSA conformance to FT requirements

8
FT Architecture Specification

• High-level behavioral abstraction of components
  and their interactions (connectors)
• Description of the static structure of the system
• Typical SA specifications model only normal
  behaviors, while ignoring exceptional ones
• The system may fail in unexpected ways due to
  some faults
• To introduce fault tolerance information at the
  sw architectural level
• Idealized fault tolerant component model Lee et
  al. and Rubira et al

9
Idealized FT component model
4
4

• The normal behavior raises an exception (local
  exception)
• The exception handling part is automatically
  invoked
• The component resumes its normal behavior
• Otherwise an external exceptions is signaled

3
2
1

• Failure exceptions due to a failure in
  processing a valid request
• Interface exceptions due to an invalid service
  request

10
Activity A3
A3. Fault tolerance Testing

• Model-based test generation
• Inputs model of software under test and a set of
  test generation directives
• Output test specification
• Set of stimuli that the tester introduce in the
  system together with expected output

11
Mining Control System

• A simplified system for the mining environment
  which handles the mineral extraction from a mine
• The mine produces water and releases methane gas
  on the air
• The system is composed by three main sub-systems
• Pump Control
• Air Extractor Control
• Mineral Extractor Control
• We apply the methodology to the Air Extractor
  Control sub-system

12
FT Requirements
REQ1 The component must be able to extract air
from the mine
REQ2 If the level of methane becomes high the
pump that extracts the air have to be switched
on
Primary Requirements
REQ3 When the air extraction process is on, if
the methane level becomes acceptable then it has
to be Switched off
Auxiliary Requirement
REQ4 the air extraction process must be monitored
13
Use Case Diagram

• From the auxiliary and primary requirements we
  define N_UCs and exc_UCs.

14
FT Architecture specification and validation

• Structural Part describes how components and
  connectors are composed
• Normal and exceptional part and relationships
  among them
• Modeling tool UML 2.0
• Defining a profile for fault-tolerance
• Behavioral Part specifies how components and
  connectors are intended to interact
• UML state diagrams
• The FT-SA is verified with respect to its
  requirements
• Charmy Framework (from UNIV-AQ)
• The model-checker SPIN is the verification engine
  in Charmy
• Fault-tolerant scenarios are expressed in terms
  of Properties Sequence Charts (PSC) an extension
  of UML2.0 sequence diagrams
• SPIN is used to validate the Promela Code
  (architectural specification) conformance to
  requirements (Buchi Automata)

15
FT Architecture specification and validation
Exceptional Behavior
Normal Behavior
16
FT Testing - I

• We would like to test if the system
  implementation conforms to the selected
  architecture
• Test selection at the architectural level
• Identification of suitable abstract test cases to
  be run on the system implementation
• Architectural Test Cases (ATC)
• A test case is defined as a path, covering the
  critical behaviors of the FT SA
• Test execution
• Forcing the system to raise the under-test
  exceptional situations
• Evaluate how the system reacts according to the
  architecturally specify expected behavior

17
FT Testing - II

• During the test execution, the four exceptional
  events modeled in the four ATC are forced
• If the system execution does not conform to
  architectural specification, an architectural
  error is found

18
Conclusions

• We presented how FT and Testing can be jointly
  used in order to improve and validate CBS
• From requirements to testing through FT-SA
• Generation of Architectural Test Cases (ATC)

19
Future Work

• To improve the activity in which FT-SA adequacy
  to FT is validated
• To extend Charmy tool for the specification and
  checking of FT-SA
• To study the impact in the state space
• To validate the approach in the context of
  service oriented architectures (SOA)
• Mechanisms to replace services
• Dynamic architecture

20
Questions? ?
antonio.bucchiarone_at_isti.cnr.it