UNIT II
FORMAL MODELLING AND VERIFICATION
FORMAL MODELLING AND VERIFICATION
Formal modelling and verification methods use specialized techniques to
ensure software quality from start.
Without the right modelling approach verification isn’t possible.
THE CLEANROOM STRATEGIES
Cleanroom software engineering involves the integrated use of software
engineering modeling, program verification, and statistical software quality
assurance.
It is an engineering approach which is used to build correctness in developed
software.
The main concept behind the cleanroom software engineering is to remove
the dependency on the costly processes.
CLEANROOM PROCESS MODEL
The sequence of cleanroom tasks for
each increment is given below:
Increment Planning—adopts the incremental strategy
Requirements Gathering—defines a description of customer level requirements (for each
increment)
Box Structure Specification—describes the functional specificationFormal
Design—specifications (called “black boxes”) are iteratively refined (with an increment) to
become analogous to architectural and procedural designs (called “state boxes” and “clear
boxes,” respectively).
Correctness Verification—verification begins with the highest level box structure (specification)
and moves toward design detail and code using a set of “correctness questions.” If these do not
demonstrate that the specification is correct, more formal (mathematical) methods for
verification are used.
Continue….
Code Generation and Inspection :the box structure specifications, represented in a
specialized language, are transmitted into the appropriate programming language.
Statistical Testing —a suite of test cases that exercise of “probability distribution” of
usage are planned and designed. Execute a series of tests derived from a statistical
sample (the probability distribution noted above) of all possible program executions by
all users from a targeted population
Certification—once verification, inspection and usage testing have been completed
(and all errors are corrected) the increment is certified as ready for integration.
Functional Specification: Box Structure
Specification
Box structure specification specification is technique used in clean room s/w
engineering to describe and model the functional of a software.
Helps in understanding , designing and verifying the system by focusing on different
levels of abstraction.
Three main types of boxes are:
Black box : It describe the expected behavior of the system based on the inputs
provided and the corresponding outputs produced.
Example : Withdraw cash from ATM
Clear box : Provides detailed view ,how system works
Example: E-commerce site(updation of amount in cart after adding items)
State box : represents the internal states of the software system and how they change
over time
Example : Traffic light
Box Structure Refinement : Breakdown complex
software system into smaller more manageable parts.
Types of Box Structure Specification :
Three types of box structure specifications
Black Box Specification : Focuses on the abstraction , Stimuli andresponse of
a software system.
Here f is the function
S* is a sequence of inputs
R is the output
f is described using natural
Language or a formal specification
language to capture the intended
behavior of the system
Continue….
State Box specification:
The function ‘g’ works with the inputs and the current state to figure out the
response ‘R’ and the next state’T’.
CLEANROOM DESIGN
It is an approach emphasizes the need to build correctness into software
Breaking down designs into smaller parts and verifying before testing
Involves two main steps:
1. Design Refinement
2. Design Verification
Continue…
Clear – Box Specification
Replaces the black box ‘g’ with sequence of steps
provide a detailed view of the s/w system’s
functionality
CLEANROOM TESTING
Centered around validating software requirements by using statistical approach
Creating test cases
Statistical use testing test s/w how real users use it
Process involves understanding user interaction,assigning probabilities ,test
case
Ensure s/w meets the needs of its users
Certification
After the verification, inspection and correctness of all errors, the increments are
certified and ready for integration.
Certification Steps
1. Usage scenarios must be created.
2. Usage profile is specified.
3. Test cases generated from the usage profile.
4. Tests are executed and failure data are recorded and analyzed.
5. Reliability is computed and recorded.
Cleanroom Certification Models
• Sampling model - determines the number if random cases that need to be
executed to achieve a particular reliability level.
• Component model - allows analyst to determine the probability that a given
component in a multi-component system fails prior to completion.
• Certification model - projected overall reliability of system.
Cleanroom Video
https://www.youtube.com/watch?v=XNENtRpYy2o
Formal Methods
Define the data invariant, state, and operations for each system function
Data invariant -condition true throughout execution of function that contains
a collection of data
State- stored data accessed and altered by function
Operations - system actions that take place when data are read or written to
the state (an invariant, a precondition and a post condition are associated
with each operation)
• Specification is represented in some set theoretic type notation from some
formal language (e.g. Z or OCL)
• Specification correctness can be verified using mathematical proofs (set
operations, logic operations, sequences, induction)
Writing Formal Specifications
• Begin by defining state in terms of abstract items to be manipulated by the
function (similar to variable declaration in a programming language)
• Define the data invariant by writing the data relations that will not change
during the execution of the function using mathematical notation
• Write the precondition and post condition for the function using
mathematical notation to show the system state before and after function
execution
Formal Specification Language
Components(FSL)
• Syntax that defines the specific notation used to represent a specification
• Semantics that help to define the universe of objects that will be used to
describe the system
Relations that define the rules that indicate which objects properly satisfy the
specification
Different Type of FSL:Object Constraint
Language (OCL)
Notation developed to allow users to add more precision to UML specifications
OCL is a modeling language that has all the attributes of a formal language
Typically one begins with a set of UML diagrams (class, state, activity)
OCL Boolean expressions (constraints) are created for the diagram elements
OCL constraint expressions involve operators operating on objects
Any implementation derived from UML model must ensure that each
constraint always remains true
OCL can be used to specify the preconditions and post conditions for
operations
Z Specification Language
Applies typed sets, relations, and functions within the context of first-order
predicate logic to build schemas
Schemas are box-like structures that introduce variables and specify the
relationships between these variables
Schemas are the formal specification analog of a programming language
component
Schemas describe the stored data used to define the state of a system and
describes what data the operations alter to define a new state
Advantages of FSL
It provide a precise and unambigious description of a system’s behavior and
properties.
It can help catch errors early in the design process,when they are easier and
less expensive to fix.
It can improve communication between stakeholders involved in the sytem
design process
Disadvantages of FSL
It is complex and difficult to learn,especially for user who are less
mathematically inclined.
It is time-consuming and may require a significant amount of effort.
It is not easy to interpret,which can lead to errors or misunderstandings.
