Advanced Software Engineering ( -Formal specification, verification, transformation, and application-

Transcription

1 Advanced Software Engineering ( -Formal specification, verification, transformation, and application- Shaoying Liu Faculty of Computer and Information Sciences Hosei Univeresity, Tokyo, Japan sliu@k.hosei.ac.jp URL:

2 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.

3 Part one: Overview of Software Engineering Problems and Solutions

4 1. Introduction Software engineering process What are the problems? What are formal methods? What are problems with formal methods? What are formal engineering methods?

5 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.

6 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.

7 Software Engineering Process Abstractly, a software engineering process can be perceived as a black-box: User requirements Software Development Software system Question: how to ensure that the software system satisfies the user requirements?

8 Software life cycle Waterfall model: R equirem ents analysis and sp e cifica tio n D e s i g n Im plem entation T e s t i n g D e lie v e r a n d m aintenance

9 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 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 requirements.

10 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).

11 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.

12 Mizuho Bank ATM troubles

13 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 (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 (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

14 (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

15 (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 developers.

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

17 (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?

18 (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. ITS Intelligent Transport Systems.

19 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.

20 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:

21 full name address telephone number passport number (if applicable) period of stay type of the room to reserve check in state check out state

22 The following functions must be provided: (1) Make a reservation (2) Cancel a reservation (3) Change a reservation (4) Check in (5) Check out

23 A possible solution to this problem: Formal Methods!

24 1.3 What are formal methods? Formal methods = Formal Specification + Formal Verification Set theory, logics, algebra etc.

25 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

26 From the abstract to the concrete Refinement Specification What to do Implementation How to do it Verification Check the correctness

27 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; end

28 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.

29 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.

30 Validation Requirements analysis Verification Formal Specification Design Verification and validation Verification Coding 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.

31 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.

32 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

33 For example, Add(x : nat) y : nat ext rd z : nat /*z is a state variable */ pre true post y > x + z VDM is one of the earliest formal methods.

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

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

36 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).

37 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.

38 What is the solution to those problems? Formal Engineering Methods!!!

39 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.

40 Formal Methods Formal Engineering Methods Application of Formal Methods

41 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.

42 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.

43 SOFL: a specific formal engineering method!

44 SOFL (Structured Object-oriented Formal Language) Started at the University of Manchester, UK in Completed at Hiroshima City University. Finalized at Hosei University, Japan. SOFL = Language + Method + Process

45 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)

46 (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 the entire CDFD.

47 (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 objectoriented method for detailed design and programming.

48 (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 semiformal, 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.

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

50 A general structure of a SOFL specification class S1; const; type; var; inv; method Init; module SYSTEM; const; type; var; inv; process Init; A1 A2 method P1; method P2; method P3; end_class; process A1; process A2; end_module; B2 B1 class S2; const; type; var; inv; method Init; method Q1; method Q2; method Q3; end_class; module A2_Decom; const; type; var; inv; process Init; process B1; process B2; process B3; end_module; B3

51 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.