Advanced Software Engineering(ソフトウェア工学特論）

-Formal specification, verification, transformation, and application-

Shaoying LiuFaculty of Computer and Information

SciencesHosei Univeresity, Tokyo, Japan

Email: sliu@k.hosei.ac.jpURL: http:/cis.k.hosei.ac.jp/~sliu/

The goals of this courseStudy 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

Solutions

1. IntroductionSoftware engineering processWhat 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 ProcessAbstractly, a software engineering process

can be perceived as a black-box:

SoftwareDevelopment

User requirements Software system

Question: how to ensure that the software systemsatisfies the user requirements?

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 e

Requirements 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 requirementsImplementation 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 requirements.

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

boundary, and file operations).

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.

.

Mizuho Bank ATM troubles

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.

Computer Weekly (UK), 10 Oct. 1991

(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.”

The Times (UK), 11 August 1992

(2) Software projects are often over budget and behind schedule.

(3) Software requirements are usually not well understood before systems areimplemented.

• 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 developers.

(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 ofsoftware.

• 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 propertiesif they are not correct with respect to theirrequirements specifications.

aircraft control systems.nuclear power plant control systems.medical systems.railway control systems.ITS – Intelligent Transport Systems.

An important reason for the above problems

Specifications are written using informallanguages (e.g., English) or semi-formal notation (e.g., DFD or UML).

Such specifications can be ambiguousand offer no foundation for automatedformal transformation and verification.

For instance: A software system for hotel reservationis required. The hotel has the following resources:

single: 100twin: 50double: 100

The reservation list must record the followingpieces of information of customers:

full nameaddresstelephone numberpassport number (if applicable)period of staytype of the room to reservecheck in statecheck out 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:

Formal Methods!

1.3 What are formal methods?

Formal methods = Formal Specification+

Formal Verification

Set theory, logics, algebra etc.

Formal methods can also be understood as the following

three components:Formal notation (or language) for writing specificationsLogical 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

VerificationCheck the correctness

For example,

Specification: squareroot(x: nat0) y: realpost: y ** 2 = x

Program1: squareroot(x: nat0)beginy: real;y = Math.sqrt(x);return y;end

Program2: squareroot(x: nat0)beginy: real;y = Math.sqrt(x);return –y;end

Both Program1 and Program2 satisfythe 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 shown next.

Requirements analysis

Design

Coding

Formal Specification

Validation

Verification andvalidation

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 anddesign may need more time and cost more money.

The questions are:How to write a formal specification?How to do refinement? In other words, what are the rules for refinement?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)outputext State variablepreconiditonpostcondition

For example,

Add(x : nat) y : natext rd z : nat /*z is a state variable */pre truepost y > x + z

VDM is one of the earliest formal methods.

(2) Z, Oxford University, UKTony Hoare groupSchema notation

age: Nage > 0

declarationpredicate

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 specificationand 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 communication between human and machine).

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 validation of systems.

What is the solution to those problems?

Formal Engineering Methods!!!

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 harmonyof methodology, human, and software tool.

Application of Formal Methods

Formal EngineeringMethods

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

Integration of formal notations and diagrams (e.g., VDM-SL, Z and DFD, Structure chart, flowchart, finite state machine), as well as natural languages. Integration of formal proof and practical verification methods, such as testing and reviews. Integration of prototyping and formal development process. Supporting evolution (which includes modification, extension, and refinement) rather than only strict refinement.Provide effective software tool supports for the use of the integrated formal techniques.

SOFL: a specific formal engineering method!

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 = Language + Method + Process

SOFL has been used for several applications:

(1) Railway Crossing Controller

(2) University Information System

(3) Hotel Reservation System

(4) Research Award Policy System

(5) Online ATM (Automated Teller Machine)

(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 thespecification, 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 ofthe entire CDFD.

(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;method Init;method P1;method P2;method P3;

const; type; var; inv;method Init;method Q1;method Q2;method 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 11.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.