25 February 2009Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Formal Methods Introduction

25 February 2009Instructor: Tasneem Darwish2 Outlines Formal Methods. The CICS experience. The Z notation. The importance of proof. Abstraction.

25 February 2009Instructor: Tasneem Darwish3 Formal Methods Today’s software comes with extensive documentations. The behaviour of a software is often a surprise to users and designers alike: Components interact and interfere. Undesirable properties emerge. System fail to meet their requirements. The consequences of software faults may cause Aircrafts crashes, fatal doses of radiation for patients or more... Also time and money are wasted, effort is expanded to no avail and our health is damaged by frustration.

25 February 2009Instructor: Tasneem Darwish4 Formal Methods There are many explanations for software faults: The requirements are hard to define. The ways in which a system may be used are hard to anticipate. There is always demand for additional functionality. One way to improve the quality of software is to change the way in which it is documented: at the design stage, during development and after release.

25 February 2009Instructor: Tasneem Darwish5 Formal Methods Existing methods of documentation offer large amount of text, pictures and diagrams, but these are often imprecise and ambiguous: Important information is hidden amongst irrelevant details. The alternative documentation method is the Formal Method.

25 February 2009Instructor: Tasneem Darwish6 Formal Methods Formal methods is used to produce precise and unambiguous documentation. In formal methods information is presented at an appropriate level of abstraction. The formal documentation can be used: To support the design process, And as a guide to subsequent development, testing and maintenance.

25 February 2009Instructor: Tasneem Darwish7 The CICS experience CICS is one of the most successful pieces of software in the world. CICS stands for Customer Information Control System CICS is a transaction processing product. Since 1970s their have been regular releases of the CICS. Each release has: Introduced additional features. Extended the structure of the existing code.

25 February 2009Instructor: Tasneem Darwish8 The CICS experience In the 1980s, the complexity of the system started to become a problem. A decision was made to re-design some of the CICS modules with the aim of making extensions easier. An important part of the proposed solution was to find a more precise way to specify functionality.

25 February 2009Instructor: Tasneem Darwish9 The CICS experience Such precision require the use of mathematical techniques. A particular formal method, the Z notation was used to specify the new functionality. The first CICS product to be designed using Z was announced in 1989 (CICS/ESA). The use of the Formal Method: Reduced the development costs. Enhanced quality and reliability.

25 February 2009Instructor: Tasneem Darwish10 The Z notation The Z notation is a mathematical language based upon: Set theory. Mathematical logic. Another aspect of Z is the way in which mathematics can be structured. In Z, mathematical objects and their properties can be collected together in schemas.

25 February 2009Instructor: Tasneem Darwish11 The Z notation The schema language can be used to describe: The state of a system. The ways in which the state may change. System properties. To reason about possible refinements of a design. Another feature of Z is the use of types. Every object in mathematical language has a unique type.

25 February 2009Instructor: Tasneem Darwish12 The Z notation A third aspect of Z is the use of natural language: mathematical language is used to state the problem, to discover solutions and to prove that the chosen design meets the specifications. Natural language is used to relate the mathematical objects to the real world. A fourth aspect of Z is refinement.

25 February 2009Instructor: Tasneem Darwish13 The Z properties It is a mathematical language with a powerful structuring mechanism. In combination with natural language it can be used to produce formal specifications. we may reason about these specifications using the proof techniques of mathematical logic. We may refine specifications yielding another description that is closer to executable code.

25 February 2009Instructor: Tasneem Darwish14 The Z properties Z can not describe the non-functional properties such as: Usability. Performance. Reliability. There are other formal methods that are will suited for these purpose and they may be used in combination with Z.

25 February 2009Instructor: Tasneem Darwish15 The Importance of proof If we reason about a specification or attempt to construct a proof about its properties, then we are more likely to detect problems at an early stage of system development. At design stage, a proof can show us not only that the design is correct, but also why it is correct. At the implementation stage, a proof can help us to ensure that a piece of code behaves according to the specifications.

25 February 2009Instructor: Tasneem Darwish16 The Importance of proof A specification without proofs is untested: It may be inconsistent. It may describe properties that were not intended. It may omit desired properties. It may make inappropriate assumptions.

25 February 2009Instructor: Tasneem Darwish17 Abstraction

25 February 2009Instructor: Tasneem Darwish18 Abstraction In 1933, the map was replaced by a more abstract representation, called the Diagram, which showed only the connectivity of stations. Abstracted were: surface detail distances between stations orientation of lines

25 February 2009Instructor: Tasneem Darwish19 Abstraction

25 February 2009Instructor: Tasneem Darwish20 Abstraction The success of the diagram is due to: an appropriate choice of abstraction an elegant presentation The diagram properties (the good specification properties): abstract and complete clear and unambiguous concise and comprehensible easy to maintain and cost-effective