Se 4
Se 4
Se 4
& VERIFICATION
UNIT 2
Introduction
◦ Formal modeling and verification are techniques used in software engineering and computer
science to ensure the correctness and reliability of software systems Formal modeling involves
creating a mathematical or logical model of a software system, while formal verification
involves using mathematical or logical methods to check whether the model meets certain
specifications or requirements.
◦ Formal modeling is usually done using formal specification languages, such as Z B, or Alloy.
These languages provide a precise and unambiguous way of describing the behavior and
structure of software systems. Formal models can also be created using formal methods, such
as model checking, theorem proving, or abstract interpretation.
◦ Formal verification is the process of verifying that a formal model meets certain requirements
or specifications. There are several techniques used in formal verification, including model
checking, theorem proving, and static analysis. Model checking involves checking all possible
behaviors of a model to ensure that it satisfies a set of specified properties.
Formal modeling and verification are important for ensuring
the correctness and reliability of software systems, especially
in safety-critical applications such as aerospace, medical
devices, and nuclear power plants. These techniques can help
identify potential errors or bugs early in the software
development process, before they cause serious problems or
harm.
Formal Modeling & Verification
Formal modeling and verification is a process of developing mathematical
models of a software system and using formal methods to prove that the
system satisfies its functional and non-functional requirements. Formal
modeling and verification is a rigorous approach to software development that
can help ensure that the software behaves correctly and meets its intended
purpose.
The process of formal modeling and verification typically involves the
following steps:
◦ Modeling
◦ Verification
◦ Validation
◦ Refinement
Formal modeling and verification has
several benefits
◦ Increased reliability
◦ Improved maintainability
◦ Reduced development costs
◦ Improved communication
Functional Specification
A functional specification is a document that describes in detail the functional
requirements and features of a software system or product.
The functional specification typically includes information about the software's user
interface, input and output data, processing rules, algorithms, data structures error
handling, and other key features. It should also describe any performance or scalability
requirements, as well as any security or privacy concerns.
The purpose of a functional specification is to provide a clear and unambiguous
description of what the software should do, so that all stakeholders, including developers,
testers, and users, have a shared understanding of the system.
Creating a functional specification typically involves gathering requirements from
stakeholders, analyzing and prioritizing those requirements, and then creating a detailed
document that describes how the software will meet those requirements. The document
should be reviewed and approved by all stakeholders before development begins.
The Cleanroom Strategy
The cleanroom approach makes use of a specialized version of the
incremental software model A "pipeline of software increments" is
developed by small independent software engineering teams. As each
increment is certified, it is integrated in the whole. Hence,
functionality of the system grows with time. Once functionality has
been assigned to the software element of the system, the pipeline of
cleanroom increments is initiated.
1. Increment planning: A project plan that adopts the incremental strategy is developed. The
functionality of each increment, its projected size, and a cleanroom development schedule are
created. Special care must be taken to ensure that certified increments will be integrated in a timely
manner.
3. Box structure specification: A specification method that makes use of box structures is used to
describe the functional specification. Conforming to the operational analysis principles box structures
"isolate and separate the creative definition of behavior, data, and procedures at each level of
refinement.“
4. Formal design: Using the box structure approach, cleanroom design is a natural and seamless
extension of specification. Although it is possible to make a clear distinction between the two activities,
specifications (called black boxes) are iteratively refined (within an increment) to become analogous to
architectural and component-level designs (called state boxes and clear boxes, respectively).
5. Correctness verification: The cleanroom team conducts a series of rigorous correctness
verification activities on the design and then the code. Verification begins with the highest-level box
structure (specification) and moves toward design detail and code. The first level of correctness
verification occurs by applying a set of "correctness questions" If these do not demonstrate that the
specification is correct, more formal (mathematical) methods for verification are used.
6. Code generation, inspection and verification: The box structure specifications, represented in a
specialized language, are translated into the appropriate programming language. Standard
walkthrough or inspection techniques are then used to ensure semantic conformance of the code and
box structures and syntactic correctness of the code. Then correctness verification is conducted for
the source code.
7. Statistical test planning: The projected usage of the software is analyzed and a suite of test cases
that exercise a "probability distribution of usage are planned and designed. Referring to figure, this
cleanroom activity is conducted in parallel with specification, verification, and code generation.
8. Statistical use testing: Recalling that exhaustive testing of computer software is
impossible, it is always necessary to design a finite number of test cases. Statistical use
techniques execute a series of tests derived from a statistical sample of all possible
program executions by all users from a targeted population.
9. Certification: Once verification, inspection, and usage testing have been completed
(and all errors are corrected), the increment is certified as ready for integration.
Process of Cleanroom Development
◦ Management
◦ Specification
◦ Development
◦ Certification
1. Management: It is persistent throughout the whole project lifetime
which consists of project mission, schedule, resources, risk
analysis, training, configuration management, etc.
2. Specification: It is considered the first process of each increment
which consists of requirement analysis, function specification, usage
specification, increment planning, etc.
3. Development: It is considered the second process of each
increment which consists of software reengineering, correctness
verification, incremental design, etc.
4. Certification: It is considered the final process of each increment
which consists of usage modeling and test planning, statistical
training and certification process etc.