Advanced Software Engineering
(
ソフトウェア工学特論）
-Formal specification, verification,
transformation, and
application-Shaoying Liu
Faculty of Computer and Information Sciences
Hosei Univeresity, Tokyo, Japan Email: [email protected]
The goals of this course
Study SOFL (Structured Object-Oriented Formal Language) as both a specification language and a method for developing software systems.
Study rigorous review and specification testing for verification and validation of formal specifications. Study techniques for transforming formal
specifications into Java programs.
Carry out two projects to apply SOFL to specify a simplified library system and to verify and validate an ATM (Automated Teller Machine) Specification.
Part one: Overview of Software
Engineering Problems and
1. Introduction
Software engineering process
What are the
problems
?
What are formal methods?
What are problems with formal methods?
What are
formal engineering methods
?
1.1. What is Software
Engineering?
Software Engineering (SE) is the field of computer science that deals with the development and
maintenance of complex and large scale software systems.
Two views:
(1) Research view: SE is the field of computer
science that develops principles, methods, and tools to deal with the building and maintenance of software systems.
(2) Application view: SE is a process and activity of building and maintaining software systems using the technologies available in computer science.
The appearance of Software Engineering has
changed the conventional views in producing
software systems:
(1) Redefine the concept of “software”:
Software =
Documentation
+ Program +
Data
(2) Software quality should be ensured not only
by means of testing, but more importantly by
means of quality development processes.
(3) Understanding user requirements and
producing a quality design become more
important than programming.
Software Engineering Process
Abstractly, a software engineering process
can be perceived as a black-box:
Software Development
User requirements Software system
Question: how to ensure that the software system
Software life cycle
Waterfall model: R e q u i r e m e n t s a n a l y s i s a n d s p e c i f i c a t i o n T e s t i n g D e s i g n I m p l e m e n t a t i o n D e l i e v e r a n d m a i n t e n a n c eRequirements analysis and specification is a study aiming to discover and document the exact
requirements for the software system to be constructed.
Design is an activity to construct a system, at a high
level, to meet the system requirements
Implementation is where the design specification is
transformed into a program written in a specific
programming language, such as Pascal, C, or Java.
Testing is a way to detect potential faults in the
program by running the program with test cases.
Deliver and maintenance is where the ultimate
system is delivered to the customer for operation, and is modified either to fix the existing faults when they occur during operation or to meet the new
1.2 What are the problems?
1. The overall problem is that software systems often do not operate as expected. In other words,
software systems usually (or correctly speaking, always) contain faults (or bugs).
The faults can be roughly classified into three categories:
(1) Implementation does not satisfy the user requirements.
(2) Incorrect design (e.g., architecture problem) (2) Implementation bugs (e.g., type, array
Examples of software quality
problems
National Aerospace Laboratory of Japan has conducted an
airplane flight test of the supersonic experimental
airplane (The rocket-powered experimental plane NEXST-1) in Woomera, Australia as part of the Next generation Supersonic Aircraft Technology Research and Development, but failed possibly due to software
malfunction, according to the news paper report after the test flight.
Historical examples:
(1)“A UK bank has accidentally transferred 2 billion
sterling pounds to UK and US companies because a
software design flaw allowed payment instructions to be duplicated.”
Computer Weekly (UK), 19 Oct. 1989
(2) “American Airlines reckons it has lost $50 million in passenger bookings due to a software design error in its own computer reservation system.”
Computer Weekly (UK), 22 Sept. 1988.
(3) “A marine surveying and salvage company which claims a 300,300 sterling pounds computerized
accounting system was plagued (affected) by hundreds of faults and unusable from day one has begun a high court claim for almost 1 million sterling pound in
compensation.
(4) “On 1 July [1991] there was a 6-hour [telephone system] outage (non-operating period) affecting over 1 million
customers in the Pittsburgh area … [It] had finally been attributed to a hitherto (until this time) undetected but reproducible software fault.”
Risks Forum, ACM Software Engineering Notes, July 1991
(5) “The … Bank’s five million credit card customers were yesterday urged to check their statements for mistakes caused by a computer bug.”
(2) Software projects are often over
budget and behind schedule.
(3) Software requirements are usually not well
understood before systems are
implemented.
• The user usually has only a rough idea about the software system he or she wants.
• The user requirements are not defined precisely, and therefore are often misinterpreted by the
(4) Software development process is
usually not well controlled.
• The obligations of system analysts, designers, and programmers are not precisely defined.
• Documents are often changed without a rigorous procedure, and such changes are often not rigorously verified.
(5) Program testing is too late and has limited
power in ensuring the correctness of
software.
• Testing can only show the presence of bugs, but never show the absence of bugs.
• Testing is usually costing, around 60% or more of the total cost of software development.
• What do you do after you find out that the software cannot be used at all by testing?
(6) Software systems for safety-critical systems
may result in the loss of life and/or properties
if they are not correct with respect to their
requirements specifications.
aircraft control systems.
nuclear power plant control systems. medical systems.
railway control systems.
An important reason for the
above problems
Specifications are written using
informal
languages (e.g., English) or semi-formal
notation (e.g., DFD or UML).
Such specifications can be
ambiguous
and offer no foundation for
automated
formal transformation and verification.
For instance:
A software system for hotel reservation
is required. The hotel has the following
resources:
single: 100
twin: 50
double: 100
The reservation list must record the following
pieces of information of customers:
full name
address
telephone number
passport number (if applicable)
period of stay
type of the room to reserve
check in state
The following functions must be provided:
(1) Make a reservation
(2) Cancel a reservation
(3) Change a reservation
(4) Check in
(5) Check out
A possible solution to this
problem:
1.3 What are formal methods?
Formal methods = Formal Specification
+
Formal Verification
Formal methods can also be
understood as the following
three components:
Formal notation (or language) for writing
specifications
Logical calculus for formal verification
(or proof)
Method for developing software
systems
From the abstract to the concrete
Refinement
Specification
Implementation
What to do How to do it
Verification
For example,
Specification: squareroot(x: nat0) y: real post: y ** 2 = x
Program1: squareroot(x: nat0) begin
y: real;
y = Math.sqrt(x); return y;
Program2: squareroot(x: nat0) begin y: real; y = Math.sqrt(x); return –y; end
Both Program1 and Program2 satisfy
the specification, although the results
are different.
This means:
Specification: y ** 2 = x
Refinement 1: y ** 2 = x and y >= 0
Refinement 2: y ** 2 = x and y <= 0
Software development process using formal
methods has changed considerably, as
Requirements analysis Design Coding Formal Specification Validation Verification and validation Verification Verification Testing
The change is not only at the increase of activities, but also at the cost and the schedule. For example, formal specification and design may need more time and cost more money.
The questions are:
z
How to write a formal specification?
z
How to do refinement? In other words,
what are the rules for refinement?
z
How to do formal verification?
To support those activities, many formal
methods have been developed. The
most commonly used formal methods
are briefly introduced next.
The most commonly used
formal methods
(1) VDM (Vienna Development Method), IBM Research Laboratory in Vienna, and
Cliff B. Jones, UK Operation definition:
Operation(input)output ext State variable
preconiditon postcondition
For example,
Add(x : nat) y : nat
ext rd z : nat /*z is a state variable */
pre true
post y > x + z
(2) Z, Oxford University, UK
Tony Hoare group
Schema notation
age: N
age > 0
declaration
predicate
Application: IBM’s Customer Information Control System (CICS), about 500,000 lines of code.
(3) B-Method,
Jean-Raymond Abrial, France A specification is set of related
Abstract Machines. Each abstract machine is a module that contains many operation
definitions.
Application: a computerized signaling system in Paris, which involves specification
and verification of 63% of the 21,000 line system.
1.4 What are problems with
formal methods
Formal specifications of large scale software
systems can be difficult to write, to read, and to understand for many engineers in industry.
Formal methods are not well-integrated into the traditional software development process
(e.g., how to use DFD or flowchart with formal notations).
Formal methods are not effective in modeling the dynamic properties of software systems
(e.g., GUI, system efficiency, the way of
Formal proof is too difficult to conduct
by engineers in industry. Its cost is
usually very high (e.g., labor, time).
Formal proof is not effective in
What is the solution to those
problems?
1.5 What are Formal
Engineering Methods?
Formal Engineering Methods (FEM) provide a way to incorporate Formal Methods into the software development process to enhance the rigor
(methodology), comprehensibility (human), and tool supportability (software tools) of software
development process and consequently the quality of the final software product.
In other words, FEM helps to achieve the harmony of methodology, human, and software tool.
Application of Formal Methods Formal Engineering Methods Formal Methods
The difference between Formal
Methods (FM) and Formal
Engineering Methods (FEM)
FM addresses the problem of “what we should
do and why”.
FEM attacks the problem of “what we can do
and how”.
The features of formal
engineering methods
z Integration of formal notations and diagrams (e.g., VDM-SL, Z and DFD, Structure chart, flowchart,
finite state machine), as well as natural languages. z Integration of formal proof and practical
verification methods, such as testing and reviews. z Integration of prototyping and formal development
process.
z Supporting evolution (which includes modification, extension, and refinement) rather than only strict refinement.
z Provide effective software tool supports for the use of the integrated formal techniques.
SOFL (Structured Object-oriented Formal
Language)
Started at the University of Manchester, UK in
1989.
Completed at Hiroshima City University.
Finalized at Hosei University, Japan.
SOFL has been used for several applications:
(1) Railway Crossing Controller
(2) University Information System
(3) Hotel Reservation System
(4) Research Award Policy System
(1) SOFL as a language.
It is an integration of the following three:
(a) VDM-SL (VDM specification language) (b) Petri Nets
(c) Data Flow Diagrams (DFD)
The DFD provides a comprehensible architecture of the specification, while Petri nets are used to provide an
operational semantics for the DFD, and VDM-SL is used for defining processes, data flows, and data stores.
A SOFL CDFD (Condition Data Flow Diagrams) is a unified concept of traditional data flow and control flow diagrams. It uses “data availability” to control the execution of
(2) SOFL as a method.
It integrates the
Structured Method
,
Object-Oriented Method
, and
Formal Method
.
SOFL supports the use of structured
method for user requirements analysis and
abstract design, and the use of
object-oriented method for detailed design and
programming.
(3) For the development process, SOFL emphasizes the following principles:
(1) Support evolution rather than only strict refinement.
When building a SOFL specification, we use
evolution (that means we can use one of
extension, modification, and refinement), but
when decomposing a process and transforming a specification into an implementation, we use
refinement.
(2) Gradual transformation from informal, to semi-formal, and finally to formal specifications. Usually informal specification and semi-formal
specifications are constructed to document user requirements, and formal specifications are used to document design.
(3) Using rapid prototyping as a tool to
discover dynamic properties of the
system and the initial user requirements,
and use formal notation for the
development of the primary functionality
(4) Using testing and rigorous reviews for
the verification and validation of formal
specifications and the correctness of
programs.
A general structure of a SOFL
specification
const; type; var; inv;
m ethod Init;
m ethod P1; m ethod P2;
m ethod P3;
const; type; var; inv;
m ethod Init;
m ethod Q1;
m ethod Q2;
m ethod Q3;
const; type; var; inv;
const; type; var; inv;
A1 A2 B1 B2 B3 class S1; class S2; end_class; end_class; module SYSTEM ; module A2_Decom ; end_module; end_module; process Init; process A1; process A2; process Init; process B1; process B2; process B3;
Exercise 1
1.Answer the following questions.
a.What is software life cycle?
b.What is the problem with informal approaches to software development?
c.What are formal methods?
d.What are the major features of formal engineering methods?
e.What is SOFL?
2.Explain the role of specification in software development.
3.Give an example of using the similar principle of formal methods to build other kinds of systems rather than software systems.
