A Semi-Formal Approach to
Introducing Formal Methods
A. J. Cowling
Structure of Presentation
Background
n Principles underlying the introduction of formal methods;
n Context for the approaches to be discussed.
Fully Formal Approaches
n The traditional approach;
n Translating diagrams.
The Semi-Formal Approach
n The role of eXtreme X-Machine models;
n Development of the principles;
n Description of the approach, with an example.
Department of Computer Science
University of Sheffield
Evaluation and Conclusions
SEEFM 2007
Pedagogical Principles
Why Introduce Formal Methods?
n Because we believe in them!
n This is for all the usual reasons, but:
– the reasons must also appear convincing to students, so
– the role of the methods must be clearly explained, and
– the formal methods must be applicable in the students’ work.
n Students must see some need for them;
n Hence, they must come early in the curriculum:
– otherwise students learn implicitly that they do not need them,
– whatever we might try to teach them explicitly;
n These needs must come from the links with other topics:
– where the use of the methods is seen to be of some value;
n Hence, these topics must relate to developing software.
University of Sheffield
Department of Computer Science
Core Elements of Formal Methods
Formal Notations
Computational Models
n How data structures are represented in specifications;
n How operations and behaviour are represented.
Processes
n How to structure a specification;
n The procedure for creating a specification;
n These are often neglected in teaching formal methods.
University of Sheffield
FM in Software Development
Creating Specifications
n The core activity for formal methods;
n It must come in the context of the development lifecycle;
n But, specifications must then be used as well as created:
– in later activities in the lifecycle.
n Design:
– involves introducing some form of design method,
– which needs precise descriptions of what the system must do,
– and so must be based on the specification, and not just on the
requirements;
n Testing:
– should introduce both functional and structural methods,
– functional methods have to start from a specification.
SEEFM 2007
University of Sheffield
Department of Computer Science
The Sheffield Curriculum 1
Overall Structure
n Underlying mathematical concepts and notations;
n Their use in specification languages:
– variables, types, predicates, etc;
n Specification language constructions and notations:
– eg Z’s schemas.
SEEFM 2007
Department of Computer Science
Links with Development Activities
Applying Formal Methods
SEEFM 2007
University of Sheffield
Department of Computer Science
n UK three-year honours bachelors degree:
– assumes no prior knowledge of informatics;
n Based round a spine of practical projects:
– one in each year of the curriculum;
n Focus here on the first year:
– and on the aim of developing skills in software development,
– ie of creating feasible solutions for sets of functional
requirements.
Level 1 Structure
n
n
n
n
Six parallel strands, each worth 10 ECTS credits;
Two strands relevant here, each spread over two semesters;
One strand is a conventional programming course;
One strand teaches software development:
– mainly via the “crossover” project.
SEEFM 2007
University of Sheffield
Department of Computer Science
1
The Sheffield Curriculum 2
The Crossover Project Structure
n Carried out by teams of students;
n Supported by lectures and related classes;
n Follows a strict waterfall lifecycle:
– requirements analysis, formal specification, design,
construction, system evaluation;
n Teams switch scenarios at the end of each stage:
– emphasises to them the importance of reading documentation,
– as well as the activities of creating it;
n Teams evaluate the system for which they wrote the requirements.
The Evolution of the Crossover Project
n Key drivers in recent years have been:
– achieving better integration of the formal methods, and
– developing a systematic approach to software design.
SEEFM 2007
University of Sheffield
Department of Computer Science
Approaches to Formal Methods 2
Improving the Approach
The Approach of Translating Diagrams
n Structure the specifications to match the UML diagrams:
– ie data model based on the class diagram for business classes,
– operations identified from the use case diagram;
n Build them up in a systematic fashion:
– using standard translations into Z for features of the data model
(eg multiplicities, etc,),
– deriving details of the operations from prototype GUIs
that had been produced for the requirements.
University of Sheffield
Department of Computer Science
Approaches to Formal Methods 4
Results From This Approach
Weaknesses of This Approach
n CaDiZ was showing its age:
– a command-line tool with no GUI,
– a notable contrast with Eclipse;
n The incompleteness of many specifications;
n A mismatch with the testing process:
– a robust specification “flattens” the set of alternatives,
– and is difficult to map back into the sequence of steps.
University of Sheffield
n Fully formal, using Z as the specification language;
n A conventional textbook treatment:
– focussing on the language itself,
– with some use of CaDiZ as a support tool,
– but virtually no attention to process.
Problems with This Approach
n Huge variations in the quality of the specifications:
– a few good ones,
– a few that were almost meaningless,
– most captured some key features, but
– very little consistency in the structures;
n Few benefits from using the tool support;
n Consequently, very little subsequent use of the specifications.
SEEFM 2007
University of Sheffield
Department of Computer Science
Approaches to Formal Methods 3
n Specify the data model from the class diagram;
n Specify the processing model.
Creating A Data Model
n
n
n
n
n
Define
Define
Define
Define
Define
types for the attributes;
schemas for the classes;
schemas for the collections of instances and the keys;
schemas for the associations and multiplicities;
a schema to assemble these into a complete model.
Creating A Processing Model
n Identify the inputs and outputs for each operation;
n Define the behaviour of each operation:
– how it changes the data model, and what the preconditions are;
n Specify the normal course of the operation;
n Specify the error courses and construct a robust specification.
SEEFM 2007
University of Sheffield
Department of Computer Science
A Newer Approach 1
Possible Alternatives
n The quality of specifications improved:
– except where associations were being modelled by functions;
n The completeness of specifications improved:
– but often the more important operations were not completed;
n The links with other activities improved:
– the specifications were being used in the design and testing.
SEEFM 2007
Initial Approach
The Process of Translating Diagrams
n Developed a process for creating the specifications:
– attempted to make this systematic,
– so as to produce more uniform structures;
n Borrowed concepts from the research area of methods integration.
SEEFM 2007
Approaches to Formal Methods 1
Department of Computer Science
n Adopt Object-Z:
– some advantages, but not enough;
n Explore different computational models:
– to produce specifications top-down rather than bottom-up,
– to represent the sequencing of inputs and outputs.
EXtreme X-Machine (XXM) Models
n Machine states match input (or output) screens;
n Transitions match processing of individual inputs;
n Transitions may be guarded:
– corresponding to components of the preconditions;
n The sets of guards must cover all possibilities:
– ensuring completeness of the operation specifications.
SEEFM 2007
University of Sheffield
Department of Computer Science
2
A Newer Approach 2
The Semi-Formal Approach 1
An Approach Based on XXM Models
Principles for Revising the Approach
n Essentially a top-down approach, viz:
n Stage 1: construct the XXM models for the operations;
n Stage 2: construct a relational data model:
– a table for each class,
– associations represented by foreign keys;
n Stage 3: specify the XXM functions for each operation:
– using a simplified form of relational calculus.
n Retain the features that support the curriculum goals:
– the top-down structure of the specifications,
– the use of XXM models;
n Revise the treatment of the data model:
– specify the structure in the diagram, but other details formally;
n Treat the functions uniformly where possible.
Applications of These Principles
Results From This Approach
n The XXM models were constructed well;
n They linked well with the design and testing stages;
n There was little improvement in the specification of behaviour:
– operations were still left incomplete,
– in particular, associations were not handled well.
SEEFM 2007
University of Sheffield
Department of Computer Science
The Semi-Formal Approach 2
n Associations:
– represent primarily in terms of relations;
n Multiplicities:
– represent primarily in terms of relational images;
n Preconditions:
– identify standard constructions for common forms.
SEEFM 2007
University of Sheffield
Department of Computer Science
The Semi-Formal Approach 3
Example: A Simple Library System
Example: The Checkout Operation
n Model the following concepts:
– entities: books, copies of books, and users (borrowers);
– associations: copies are copies of books, users borrow copies;
– operations: loan (check out) and return (check in) copies,
add and remove entities, catalogue search.
n The XXM diagram
Domain Class Diagram
Book
ISBN : int
author : string
title : string
SEEFM 2007
Copy
copyOf
1
0..*
copyid : int
shelf : string
University of Sheffield
User
borrowedBy
0..limit 0..1
name : string
address : string
limit : int
Department of Computer Science
The Semi-Formal Approach 4
The Formal Data Model
University of Sheffield
University of Sheffield
Department of Computer Science
The Semi-Formal Approach 5
Business Rules in the Formal Data Model
n Attribute types are specified in the diagram:
– using Java rather than Z notations, to fit with our tools;
n The groups of attributes for classes are specified in the diagram;
n Keys for classes are defined as a separate section:
– eg: Keys
The key for class Book is ISBN. The key for class Copy is
copyid. The key for class User is name.
n Variables for the collections of objects of each class are defined as
a separate section:
– eg: Collections
bs : P Book ; cs : P Copy ; us : P User
n Variables for associations are defined as a separate section:
– eg: Associations
copyOf : Copy § Book ; borrowedBy : Copy § User
SEEFM 2007
SEEFM 2007
Department of Computer Science
n Multiplicities are specified by stating the appropriate axioms;
n These are included in the Associations section;
n For lower bounds, classify associations as compulsory or optional:
– express optional as eg: dom borrowedBy z cs
– express compulsory as eg: dom copyOf = cs
n For upper bounds, constrain the relational image:
– eg: A u : User • # ( borrowedBy ~ á { u } â ) ≤ u.limit
– which normally involves the inverse of a function;
n Could include system-wide invariants:
– would be a separate section,
– would need a more elaborate example to illustrate it.
SEEFM 2007
University of Sheffield
Department of Computer Science
3
The Semi-Formal Approach 6
The Formal Model for an Operation
n A sub-section defines conditions formally, for use in guards:
– treat the inputs as parameters to the expressions,
– eg: BookExists ( isbn : int ) = E b : Book • b e bs ¦ b.ISBN = isbn ;
n A sub-section declares input and output variables:
– use the Z naming conventions,
– eg: newc? : copy ; isbn? : int ;
n A transition specifies guards in terms of the conditions:
– eg: Known book accepts isbn?, has guard BookExists (isbn?) ;
n It specifies changes to the data model, both formally and informally:
– add an instance x of an entity c: cs' = cs U {x}
– remove an instance x of an entity c: cs' = cs \ {x}
Рadd an instance of a relation r: r' = r U { x Πy }
– add an instance of a function f: f' = f ± { x Œ y }
– remove an instance of an association a between x and y:
a' = a \ { x Πy }
SEEFM 2007
University of Sheffield
Department of Computer Science
Evaluation of This Approach
Criteria For Evaluation
n Success within the crossover projects:
– completeness and quality of the specifications,
– the extent of their subsequent use for design and testing;
n Success beyond the crossover projects:
– will the students continue to use these methods?
State of Evaluation
n The approach is being taught at the moment:
– students start creating their specifications next week,
– they will be completed within three weeks,
– then we can evaluate their quality;
n Subsequent stages will follow next semester:
– then we can evaluate links with these;
n The students undertake further projects next year:
– then we can evaluate whether they still use these methods.
SEEFM 2007
Conclusions
University of Sheffield
Department of Computer Science
The End
The Semi-Formal Approach to Specification
n Has evolved through action research:
– each step in the development so far has been evaluated;
n As a result, it has clear pedagogical advantages:
– provides a top-down approach to specification,
– reflects the underlying computational models,
– avoids unnecessary duplication of information,
– while allowing precise descriptions of behaviour;
n It is designed to avoid overloading students’ knowledge of discrete
mathematics;
n It is also intended be a scalable approach.
Thanks for your attention!!
Any Questions?
Possible Future Developments
n Compare more rigorously with the B method and with OCL;
n This method needs tool support:
– a project has been set up to create a suitable tool.
SEEFM 2007
University of Sheffield
Department of Computer Science
SEEFM 2007
University of Sheffield
Department of Computer Science
4