DISTANCE LEARNING CENTRE

AHMADU BELLO UNIVERSITY

ZARIA, NIGERIA

COURSE MATERIAL

FOR

Course Code/Title: COSC 402 - FORMAL METHODS AND SOFTWARE

DEVELOPMENT

Programme Title: B.Sc. COMPUTER SCIENCE

1
 ACKNOWLEDGEMENT
We acknowledge the use of the Courseware of the National Open University of
Nigeria (NOUN) as the primary resource. Internal reviewers in the Ahmadu Bello
University have also been duly listed.

2
 COPYRIGHT PAGE
© 2018 Ahmadu Bello University (ABU) Zaria, Nigeria

All rights reserved. No part of this publication may be reproduced in any

form or by any means, electronic, mechanical, photocopying, recording or
otherwise without the prior permission of the Ahmadu Bello University,
Zaria, Nigeria.

First published 2018 in Nigeria.

ISBN:

Ahmadu Bello University Press.

Zaria, Nigeria.

Tel: +234

E-mail:

3
COURSE WRITERS/DEVELOPMENT TEAM
Editor
Prof. M.I Sule
Course Materials Development Overseer
Dr. Usman Abubakar Zaria

Subject Matter Expert

Dr. Olaide Nathaniel Oyelade

Subject Matter Reviewer

Dr. Aliyu Salisu

Language Reviewer
Enegolonu Adakole

Instructional Designers/Graphics
Emmanuel Ekoja / Ibrahim Otukoya

Proposed Course Coordinator

Emmanuel Ekoja

ODL Expert
Dr. Abdulkarim Muhammad

4
INTRODUCTION
Welcome to COSC402: Formal Methods and Software Development. COSC402 is
a three-credit unit course that has minimum duration of one semester. It is a core
course for B.Sc. Computer Science students. The course guides you to develop
skills on how to use formal methods (FM) to produce high-quality software and
also, learn about formal modelling and specification languages. Making use of case
studies and self-assessment exercises gives you competence in the subject area.

PREAMBLE
To successfully complete this course, read the study units, do all assessments, open
the links and read, participate in discussion forums, read the recommended books
and other materials provided and participate in the online facilitation.
Each study unit has introduction, intended learning outcomes, the main content,
conclusion, summary and references/further readings. The introduction will tell
you the expectations in the study unit. Read and note the intended learning
outcomes. The intended learning outcomes tell you what you should be able to do
at the completion of each study unit. So, you can evaluate your learning at the end
of each unit to ensure you have achieved the intended learning outcomes. The
conclusion gives you the theme of the knowledge you are taking away from the
unit.
There are two main forms of assessments – the formative and the summative. The
formative assessments will help you monitor your learning. This is presented as
in-text questions and Self-Assessment Exercises. The summative assessments
would be used by the university to evaluate your academic performance.

5
 COURSE STUDY GUIDE

i. COURSE INFORMATION
Course Code: COSC 402
Course Title: Formal Methods and Software Development
Credit Units: 3
Year of Study: 4
Semester: 2

ii. COURSE INTRODUCTION AND DESCRIPTION

Introduction: You are all welcome to COCS 402, Formal Methods and Software
Development which is a three (3) unit course. In this course, you will understand
how formal methods (FM) help produce high-quality software; learn about formal
modelling and specification languages; write and understand formal requirement
specifications; learn about main approaches in formal software verification; know
which formal methods to use and when; use specification language (Z) to validate
models and code.

Description: Formal methods are not a panacea, but can help, and are increasingly
becoming necessary to achieve high assurance. We will learn several formal
methods - different development stages, different methodologies and different
application domains. We will emphasize strong formal methods.

iii. COURSE PREREQUISITES

You should note the following as the prerequisite to taking this course:
1. Having passed COSC202
2. Satisfactory level of English proficiency

6
 3. Basic Computer Operations proficiency

iv. COURSE LEARNING RESOURCES

i. Course Textbooks:
- Jonathan Bowen, Formal Specification and Documentation Using Z:
A Case Study of Approach, International Thomson Computers Press
(ITCP), 1996.
- Huth M. and Ryan M. Logic in Computer Science: Modelling and
Reasoning about Systems. Cambridge University Press 1999.
- CliffB. Jones, Systematic Software Development Using VDM, 2 nd
Edition, Prentice Hall, 1990.

ii. Other Resources

- http://www.cschalmers.se/cs/grundutb/kurser/form/
- http://www.freetechbooks.com/forum-28.html

v. COURSE AIM/OBJECTIVES AND OUTCOME

After studying this course, you should be able to:
1. Use Z specification language to check the correctness of a system
2. Use logic to check the correctness of a source code
3. Adopt an approaching for proofing a system

vi. ACTIVITIES TO MEET COURSE OBJECTIVES

Specifically, this course shall comprise of the following activities:
1. Studying courseware
2. Listening to course audios

7
 3. Watching relevant course videos
4. Field activities, industrial attachment or internship, laboratory or
studio work (whichever is applicable)
5. Course assignments (individual and group)
6. Forum discussion participation
7. Tutorials (optional)
8. Semester examinations (CBT and essay based).

vii. TIME (TO COMPLETE SYLABUS/COURSE)

To cope with this course, you would be expected to commit a minimum of 3 hours
weekly for the Course (study, assignments & Forum discussions).

viii. GRADING CRITERIA AND SCALE

Grading Criteria
A. Formative assessment
Grades will be based on the following:
Individual assignments/test (C.A 1, 2 etc) 20
Group assignments (G.C.A 1, 2 etc) 10
Discussions/Quizzes/Out of Class Engagements etc 10

B. Summative assessment (Semester examination)

CBT based 30
Essay based 30
TOTAL 100%

8
 C. Grading Scale:

A = 70-100
B = 60 – 69
C = 50 - 59
D = 45-49
F = 0-44

i. Feedback
Courseware based:
1. In-text questions and answer (answers preceding references)
2. Self-assessment questions and answer (answers preceding references)

Tutor based:
1. Discussion Forum tutor input
2. Graded Continuous assessments

Student based:
1. Online programme assessment (administration, learning resource,
deployment, and assessment).

ix. LINKS TO OPEN EDUCATION RESOURCES

OSS Watch provides tips for selecting open source, or for procuring free or open
software.
SchoolForge and SourceForge are good places to find, create, and publish open
software. SourceForge, for one, has millions of downloads each day.

9
 Open Source Education Foundation and Open Source Initiative, and other
organisation like these, help disseminate knowledge.
Creative Commons has a number of open projects from Khan
Academy to Curriki where teachers and parents can find educational materials for
children or learn about Creative Commons licenses. Also, they recently launched
the School of Open that offers courses on the meaning, application, and impact of
"openness."
Numerous open or open educational resource databases and search engines
exist. Some examples include:
 OEDb: over 10,000 free courses from universities as well as reviews of colleges
and rankings of college degree programmes
 Open Tapestry: over 100,000 open licensed online learning resources for an
academic and general audience
 OER Commons: over 40,000 open educational resources from elementary school
through to higher education; many of the elementary, middle, and high school
resources are aligned to the Common Core State Standards
 Open Content: a blog, definition, and game of open source as well as a friendly
search engine for open educational resources from MIT, Stanford, and other
universities with subject and description listings
 Academic Earth: over 1,500 video lectures from MIT, Stanford, Berkeley,
Harvard, Princeton, and Yale
 JISC: Joint Information Systems Committee works on behalf of UK higher
education and is involved in many open resources and open projects including
digitising British newspapers from 1620-1900!

10
 The University of Cambridge's guide on Open Educational Resources for Teacher
Education (ORBIT)
 OpenLearn from Open University in the UK
Global
 Unesco's searchable open database is a portal to worldwide courses and research
initiatives
 African Virtual University (http://oer.avu.org/) has numerous modules on subjects
in English, French, and Portuguese
 https://code.google.com/p/course-builder/ is Google's open source software that is
designed to let anyone create online education courses
 Global Voices (http://globalvoicesonline.org/) is an international community of
bloggers who report on blogs and citizen media from around the world, including
on open source and open educational resources.
Individuals (which include OERs)
 Librarian Chick: everything from books to quizzes and videos here, includes
directories on open source and open educational resources
 K-12 Tech Tools: OERs, from art to special education
 Web 2.0: Cool Tools for Schools: audio and video tools
 Web 2.0 Guru: animation and various collections of free open source software
 Livebinders: search, create, or organise digital information binders by age, grade,
or subject (why re-invent the wheel)

11
 x. ABU DLC ACADEMIC CALENDAR/PLANNER

PERIOD
Semester Semester 1 Semester 2 Semester 3
Activity JAN FEB MAR APR MAY JUN JUL AUG SEPT OCT NOV DEC
Registration
Resumption
Late Registn.
Facilitation
Revision/
Consolidation
Semester
Examination

N.B: - All Sessions commence in January

- 1 week break between semesters and 6 weeks vocation at end of session.
- Semester 3 is OPTIONAL (Fast-tracking, making up carry-overs & deferments)

12
 xi. COURSE STRUCTURE AND OUTLINE
WEEK MODULE STUDY SESSION ACTIVITY

1. Read Courseware for the corresponding Study Session.

2. View the Video(s) on this Study Session
Study Session 1: 3. Listen to the Audio on this Study Session
Week 1 Title: Introduction 4. View any other Video/U-tube https://bit.ly/2U1HSLb
5. View referred OER
6. View referred Animation https://bit.ly/2TDNgin

1. Read Courseware for the corresponding Study Session.

2. View the Video(s) on this Study Session
Week 2 Study Session 2 3. Listen to the Audio on this Study Session
Title: Mechanical 4. View any other Video/U-tube https://bit.ly/2HVqkcg
STUDY Methods and Step 5. View referred OER
MODULE 1 Towards Abstraction 6. View referred Animation https://bit.ly/2Ws0d0s

1. Read Courseware for the corresponding Study Session.

2. View the Video(s) on this Study Session
Week 3 Study Session 3 3. Listen to the Audio on this Study Session
Title: Logic and Set 4. View any other Video/U-tube https://bit.ly/2WmHRho
Theory 5. View referred OER
6. View referred Animation https://bit.ly/2Yw7I8s

Week 4 Study Session 4: 1. Read Courseware for the corresponding Study Session.
Soundness, 2. View the Video(s) on this Study Session
Completeness, Model 3. Listen to the Audio on this Study Session
and Interpretation 4. View any other Video/U-tube https://bit.ly/2UXkz1i
5. View referred OER
6. View referred Animation https://bit.ly/2TE4bBl

1. Read Courseware for the corresponding Study Session.

2. View the Video(s) on this Study Session
Week 5 Study Session 1 3. Listen to the Audio on this Study Session
Title: Traditional 4. View any other Video/U-tube https://bit.ly/2CGeTS9
Program Proof and 5. View referred OER
Proof System 6. View referred Animation https://bit.ly/2HXhtGW

STUDY
MODULE 2 1. Read Courseware for the corresponding Study Session.
2. View the Video(s) on this Study Session
Week 6 Study Session 2 3. Listen to the Audio on this Study Session
Title: Lambda Calculus 4. View any other Video/U-tube https://bit.ly/2WrDEZN
and Probabilistic Proof 5. View referred OER
6. View referred Animation https://bit.ly/2UZgLNa

13
 1. Read Courseware for the corresponding Study Session.
2. View the Video(s) on this Study Session
Study Session 3 3. Listen to the Audio on this Study Session
Week 7 Title: Hoare Logic and 4. View any other Video/U-tube https://bit.ly/2TYKN7f
Weakest Precondition 5. View referred OER
Calculus 6. View referred Animation https://bit.ly/2OwZc4p

1. Read Courseware for the corresponding Study Session.

Study Session 1 2. View the Video(s) on this Study Session
Week 8 Title: Turing Machines 3. Listen to the Audio on this Study Session
and Church Thesis 4. View any other Video/U-tube https://bit.ly/2FGCJze
5. View referred OER
6. View referred Animation https://bit.ly/2FAGjtj
STUDY
MODULE 3
1. Read Courseware for the corresponding Study Session.
2. View the Video(s) on this Study Session
Week 9 Study Session 2 Title: 3. Listen to the Audio on this Study Session
Finite State Automata 4. View any other Video/U-tube https://bit.ly/2Ous2Tl
5. View referred OER
6. View referred Animation https://bit.ly/2YuWLEj

1. Read Courseware for the corresponding Study Session.

2. View the Video(s) on this Study Session
Week 10 Study Session 3 3. Listen to the Audio on this Study Session
Title: Refinement 4. View any other Video/U-tube https://bit.ly/2CFN5xe
5. View referred OER
6. View referred Animation https://bit.ly/2V1kVE2

1. Read Courseware for the corresponding Study Session.

Study Session 1 2. View the Video(s) on this Study Session
Week 11 Title: Introduction Z 3. Listen to the Audio on this Study Session
and LATEX 4. View any other Video/U-tube https://bit.ly/2uxEzfs
5. View referred OER
6. View referred Animation https://bit.ly/2TZqtCT
STUDY
MODULE 4
Study Session 2 1. Read Courseware for the corresponding Study Session.
Title: Operations in Z 2. View the Video(s) on this Study Session
and Algorithmic 3. Listen to the Audio on this Study Session
Translation of Z 4. View any other Video/U-tube https://bit.ly/2FwFvWt
Week 12 5. View referred OER
6. View referred Animation https://bit.ly/2HKzhpA

14
 Study Session 3 1. Read Courseware for the corresponding Study Session.
Title: Verification and 2. View the Video(s) on this Study Session
Abstract data types 3. Listen to the Audio on this Study Session
4. View any other Video/U-tube https://bit.ly/2FAEpZE
5. View referred OER
6. View referred Animation https://bit.ly/2V0BJv1

Week 13 REVISION/TUTORIALS (On Campus or Online) & CONSOLIDATION WEEK

Week 14 & SEMESTER EXAMINATION

15

15
Table of Contents
INTRODUCTION.................................................................................................................... 5
PREAMBLE ............................................................................................................................. 5
COURSE STUDY GUIDE ...................................................................................................... 6
i. COURSE INFORMATION ............................................................................................ 6
ii. COURSE INTRODUCTION AND DESCRIPTION ................................................... 6
iii. COURSE PREREQUISITES ...................................................................................... 6
iv. COURSE LEARNING RESOURCES ........................................................................... 7
v. COURSE AIM/OBJECTIVES AND OUTCOME ....................................................... 7
vi. ACTIVITIES TO MEET COURSE OBJECTIVES .................................................... 7
vii. TIME (TO COMPLETE SYLABUS/COURSE) ....................................................... 8
viii. GRADING CRITERIA AND SCALE ........................................................................ 8
ix. LINKS TO OPEN EDUCATION RESOURCES ......................................................... 9
x. ABU DLC ACADEMIC CALENDAR/PLANNER .................................................... 12
xi. COURSE STRUCTURE AND OUTLINE .................................................................. 13
xii. STUDY MODULES .................................................................................................... 17
MODULE 1: ....................................................................................................................... 17
Study Session 1: Introduction .............................................................................................. 17
Study Session 2: Mechanical Methods and Steps Towards Abstraction ............................. 31
Study Session 3: Logic and Set Theory ............................................................................... 47
Study Session 4: Soundness and Completeness, and Model and Interpretation .................. 62
MODULE 2......................................................................................................................... 70
Study Session 1: Traditional Program Proof and Proof System .......................................... 70
Study Session 2: Lambda Calculus and Probabilistic Proof ................................................ 86
Study Session 3: Hoare Logic and Weakest Precondition Calculus .................................... 97
MODULE 3....................................................................................................................... 114
Study Session 1: Turing Machines and Church Thesis ..................................................... 114
Study Session 2: Finite State Automata ............................................................................. 139
Study Session 3: Refinement ............................................................................................. 162
MODULE 4....................................................................................................................... 176
Study Session 1: Introduction to Z and LATEX ................................................................ 176
Study Session 3: Verification and Abstract data types ...................................................... 214
xiii. GLOSSARY............................................................................................................... 233

16
 xii. STUDY MODULES
MODULE 1:
Study Session 1: Introduction
Study Session 2: Mechanical Methods, Steps towards Abstraction
Study Session 3: Logic and Set Theory
Study Session 4: Soundness and Completeness, and Model and Interpretation

Study Session 1: Introduction

Introduction
1.0 Learning Outcome
2.0 Main Content
2.1- Errors or bugs?
2.2- Therac 25
2.3- Improving Software Quality
2.4- Formal Methods in Industry
3.0 Tutor Marked Assignments (Individual or Group assignments)
4.0 Study Session Summary and Conclusion
5.0 Self-Assessment Questions and Answer
6.0 Additional Activities (Videos, Animations & Out of Class Activities)
7.0 References/Further Reading

Introduction:
Welcome to the first session of the first module in this course. In this session,
we shall give an overview of the reason for studying the formalization of
software engineering. I expect you to have generated interest in learning such
formalism at the end of this session. Now, let us start by looking at the
following warranty information: PC Manufacturer warrants that (a) the
SOFTWARE will perform substantially in accordance with the accompanying
17
written materials for a period of ninety (90) days from the date of receipt, and
(b) any Microsoft hardware accompanying the SOFTWARE will be free from
defects in materials and workmanship under normal use and service for a period
of one (1) year from the date of receipt and ACCTON warrants to the original
owner that the product delivered in this package will be free from defects in
material and workmanship for the lifetime of the product.
Did you notice that the first warranty applies to a large software product
(Windows NT), the product of hundreds of person-years of software development
effort, and containing millions of separate components? The second warranty
applies to a large hardware product (an intelligent hub), the product of tens of
person-years of software and hardware development effort, and containing
millions of separate components.
Taken together, it is clear that the reliability of software is viewed as poor - even
by the largest software companies in the world - in comparison with hardware.
One explanation often given for this sad state of affairs is that the software is more
complicated than the hardware, and hence there is more opportunity for failure.
However, this explanation is not particularly good - it is clear that even small1
software is inherently unreliable. We have to recognize that most commercial
software in use today contains large numbers of errors, and the software industry
must improve. Another way of restating this is say that software engineers must
improve.
I want you to consider the following problem:
―The sum of the ages of my three sons is five times the age of the smallest son.
The sum of the ages of the two youngest sons is six years younger than the sum of
the ages of the two oldest sons. The oldest son has the next birthday, and when he
has it, he will be two years older than twice the age of the youngest son. What are
the ages of my three sons?”

Dear reader, note that if a school child was presented with this problem, he or she

18
would immediately reach for a piece of paper, and represent the problem in an
abstract manner as shown below:
a+b+c=5*a
a + b = (b + c) € 6
(2 * a) + 2 = c + 1
Having done this, the set of equations are then reduced using well known
methods. The general strategy taught at school is that ―if a problem is too
complicated to understand all at once, rewrite it in an abstract notation and then
use a set of rules to solve it”

For contrast, I want you to consider the following problem:

A file consists of two sorts of records - unprocessed records and processed
records. It contains at least one record, and we cannot tell the type of a record
without first accessing it. A program randomly accesses two of the records. If they
are of different types, the program amalgamates the data in the records, deletes
them, and writes a new unprocessed record back to the file. If the records are of
the same type, the program processes the data in the records, deletes them, and
writes a new processed record back to the file. This process continues until the
program cannot get two records from the file. Given a starting state of the file:
Does the program terminate?
What is in the file when it terminates?
If a software engineer is presented with this problem, he or she might ‘model it
using a small Pascal program‘, ‘Run it a few times and see what happens‘, or
perhaps ‘Start with a file with one record of each type, then try a bigger file until a
pattern emerges‘. (Actual responses) In this case the software engineer is
completely wrong - the problem can be easily abstracted and solved.
When chemists, physicists or biologists meet a problem that is too large or
difficult to understand, they turn to mathematics for help. When software
engineers meet a problem that is too large or difficult to understand, they try to

19
code it a few different ways to see what happens, or perhaps develop a few
subassemblies.

1.0 Study Session Learning Outcome

After studying this session, I expect you to be able to:
1. Describe the necessity for formal methods of software engineering
2. Define what formalization is all about
3. Analyze correction and reliability of a system
4. Contrast safety critical systems

2.0 Main Content

2.1. Errors or bugs?
For many years the software industry has referred to software errors as bugs.
This trivializes the issue, and gives the software developer a false sense of
security. (“Once I’ve removed these last few bugs, it will be perfect!”) In
reality, the software developer may stand on very shaky ground: “Once I’ve
removed these last few bugs, it will be:”
i. a system that has been known to work for 11 minutes continuously... (!)
ii. a system that has no written documentation describing it’s architecture...
iii. a system that no-one else in the world could repair without spending
months looking at my code...
iv. a system that still contains code that I put in last month that I don’t know
why it is there...
v. a system that stops occasionally, but I can’t reproduce it so let’s call it
hardware...
vi. a system that is still using legacy code that no one has checked for about
12 years, but it has worked for a really long time so it must be OK...
vii. a system that is using a commercial windowing package that should be
really reliable - well certainly better than code I would produce myself...

20
The Internet newsgroup comp.risks reports on “Risks to the Public in the Use
of Computer Systems and Related Technology”, and makes interesting reading.
In the January 1999 risks digest we find that:

a. from the Toronto ’Globe and Mail’ (Canada) on 22 Jan 1998:

supposedly confidential records of up to 50,000 Canadians were

accidentally left accessible to the general public on the website of Air
Miles, Canada’s second largest customer loyalty program.
Previous digests have reported that:
i. The Arizona lottery never picked the number 9 (a bad random number
generator).
ii. The LA counties pension fund has lost US$1,200,000,000 through
programming error.
iii. Windows NT corrupts file space and deletes directories under some
circumstances.
iv. A Mercedes 500SE with graceful no-skid brake computers left 200 metre
skid marks. A passenger was killed.
v. A woman killed her daughter, and attempted to kill herself and her son,
after a computer error led to her being told that all her family had an
incurable cancer.
vi. A computer controlled elevator door in Ottawa killed two people.
vii. An automated toilet seat in Paris killed a child.
viii. The Amsterdam air-freight computer software crashed, killing giraffes.
ix. Two Russ Hamilton‘s had the same birthdate. The wrong one was jailed
as a result of a software error.
x. A software patch to an unrelated system miraculously added $10 to $30
to 300,000 auto tax bills in Georgia.
xi. The Panasonic children‘s Internet watchdog software regularly spews
out vulgarities.

21
xii. General Motors recalled over 1,000,000 cars for a software change to
stop erratic air bag deployment.
xiii. the 22nd of August 1999 might be a very dangerous date - don‘t rely on
GPS or the time on that day.
There are thousands more of these sort of stories documented over the last 20 or
so years, and in the following section we look at just one.

2.2. Therac 25
The Atomic Energy Commission Limited‘s Therac-25 was a machine
programmed to dispense the right amount of radiation to fight cancer. The
machine was based on a linear particle accelerator and was first delivered in
1985. It was used until January 1987, during which time there were six
instances of extreme harm or death. The Therac-25 was a development over
earlier Therac-6 and Therac-20 models, and was the first to rely completely on a
computer (the earlier models had hardware interlocks). The software for Therac
machines was originally produced by a French company called CGR, and some
of the software faults were present in the early models, but gave no problems
due to the hardware interlocks.
On the Therac-25, when the software failed, the machine caused severe
radiation burns – and instead of normal 200 rad doses, people received an
estimated 25,000 rad dose.
Occasional peculiar behaviour of the system was observed immediately after
commissioning of the first Therac-25s, and even resulted in lawsuits from
unhappy patients. AECL responded with modifications to the systems in
September 1985, which ―resulted in an improvement in safety of 10,000,000%‖
(according to AECL).
Four months later the first death occurred after the following incident at the East
Texas Cancer Clinic in Tyler, Texas.

22
2.3. Improving Software Quality
Now, look at this excerpt ‗He ... said something was wrong. She asked him what
he felt, and he replied, “fire” on the side of his face... something had hit him on
the side of his face, he saw a flash of light, and he heard a sizzling sound
reminiscent of fried eggs... He was very agitated and asked “What happened to
me, what happened to me?’
Other deaths followed and the systems were eventually shutdown for extensive
hardware and software modifications. The deaths are directly attributable to
poor programming. In particular, the software consisted of multiple tasks that
accessed shared variables in memory. In the time between testing and setting
the value of a shared variable (commonly called a critical section), other tasks
could modify it‘s value. It is likely that the software writers were completely
unaware of this type of problem and general methods for their solution.
In Leveson‘s analysis of the Therac-25 software failure [1], the following
general lessons are emphasized:
i. don‘t put too much confidence in software
ii. don‘t confuse reliability with safety.
iii. design defensively - that is, for the worst case.
iv. don‘t focus on bugs.
v. be vigilant.

She also outlined the following good software engineering practices:

i. don‘t do specifications and documentation as an afterthought.
ii. KISS - Keep It Simple Stupid.
iii. testing and analysis at all levels, rigorous quality assurance.
iv. careful design of user interfaces.
v. don‘t assume that re-used software is safe.

The following points may help in improving the quality of delivered software:

23
 i. design software before building it - You would not pay much for a
house without plans or that had not been designed first - why would you
pay for software without similar sureties?
ii. reduce the complexity - By localizing variables, use of modularity, well
defined interfaces and so on.
iii. enforce compatibility with design - Easier to say than to do.
In each of the above points, we can use mechanical (or formal) methods. Other
engineering disciplines have embraced formal methods, but the software
industry (perhaps it should still be called a homecraft) has not yet to any great
extent.
Why is this?
i. Software engineers are afraid of mathematically based methods.
ii. A steep learning curve.
iii. Ignorance of the benefits.
iv. A belief that there are few tools available.
The use of formal methods twenty years ago was seen as unworkable outside of
the classroom, but now there are many well established cases of successful use
of formal methods, resulting in products delivered under budget and under time.
Hall [2] outlines the following seven myths relating to formal methods:
i. guarantee perfect software
ii. all about proving programs correct
iii. only useful in safety critical systems
iv. needs mathematicians
v. increases development cost
vi. unacceptable to users
vii. not used on large scale systems
Bowen [3] adds seven more:
i. delays development
ii. no tools available

24
iii. mustn‘t be mixed with traditional methods
iv. only applies to software
v. not needed
vi. not supported
vii. FM people always use FM
The above myths are fully recognized as such these days, and formal methods
are gradually becoming more common.
Formal software specification techniques are replacing flow charts and pseudo-
code. The distinct advantages of formal specifications are:
i. the formal software specifications can easily feedback modifications to
the requirements specification as needed.
ii. the formal software specification can be mechanically progressed through
to a design and even implementation.
iii. the formal software specification can be analyzed, modelled and checked
with a range of automated checkers.
In summary: formal techniques reduce the time to product delivery, and
improve the products. This is true even without tool support.

2.4. Formal Methods in Industry

The use of formal methods in industry is at least 19 years old. In at least two
cases, products have been developed by competing teams of developers - one
set using formal methods, and the other not. In both of these cases, the design
phase took about 25% longer with the team using formal methods, but the
overall development time was reduced (despite having to learn a new
paradigm), and the resultant products were considered qualitatively better.
In the following sections we look at some examples of successful use of formal
methods in industry.

25
2.4.1 CICS
CICS (Customer Information Control System) is a large IBM software product
fully licensed at over 40,000 major organizations around the world for
managing and processing their business. CICS is in use in the banking industry,
airline reservations, and stock control and so on. CICS provides OLTP (On Line
Transaction Processing) support, and a well-developed API for customer
applications. The first versions of CICS were in use over 30 years ago, and it
has undergone continual improvement and refinement over the years.

Fig 1.1.2: CICS

From 1982 through to the present day, mathematical methods have been applied
to the development of CICS, including heavy use of the Z specification
language. Z is used in the specification of all new CICS modules. This process
invariably results in extra work in the specification stages of the new products,
but this extra work is completely offset by the later reduction in detailed design
and coding times. Early CICS Z development was largely done without tool
support, but even so the final products are significantly better than other CICS
modules - requiring low software service cost after delivery.
Analyses of IBM‘s use of specification in CICS clearly show that:
i. Total development time is reduced
ii. Product service time is dramatically reduced.

26
And perhaps more significantly, IBM continue to broaden their use of formal
methods.

2.4.2 Chip development

Various groups have performed specification, design and verification of
microprocessor systems and subassemblies.
At Inmos, a group developed the T800 FPU (Floating Point Unit) using formal
methods. While doing this they uncovered a hitherto unknown fault in the
specification of IEEE floating point numbers.
The overall time from beginning design to delivery was reduced from that of
similar chips delivered by the same engineers previously. During testing of the
first prototype of the T800, a single error was identified - caused by a (human)
transcription failure, and no other faults have been found in the chip.
This should be put in perspective - the testing phase of similar chips normally
identifies 10 to 100 errors, and lead to 4 to 10 chip mask iterations spread over a
year or so. The Inmos T800 was tested, and the second iteration of the mask
was the one used in production.

2.4.3. NASA
NASA‘s DEEP SPACE 1 mission to Mars launched in December 1998 is
heavily reliant on computer software. The Millenium Remote Agent software is
an AI system written in various languages that sit on top of LISP, and manage
the control, guidance and autonomous robotic systems on board. The software is
considered mission critical, and has been developed over many years with an
essentially unlimited budget, and with extremely experienced software
engineers.

27
In 1997, a small inexperienced six (6) group used formal methods to analyse
components of the software. Most of their time was spent trying to understand
the complex systems and find useful ways to model them. Once they had a
working model, they quickly found five (5) errors, four of which were
considered important, and one of these revealing a significant design flaw in the
system.
NASA‘s software engineers:
You’ve found a number of bugs that I am fairly confident would not have been
found otherwise. One of the bugs revealed a major design flaw... so I’d say you
have had a substantial impact...
I used to be very skeptical of the utility of formal methods... I believed (and still
believe) that it is impossible to prove correctness of software systems. However,
what you have been doing is finding places where software violates design
assumptions...
To me you have demonstrated the utility of this approach beyond any question.
Let‘s hope DEEP SPACE 1 makes it!

In-text Question:
Explain what you understand by formal specification with respect to software development
and state its advantages to each category of software development team members.

Answer
Formal specification is the use of mathematical notation to describe in a precise way the
properties which an information system must have, without unduly constraining the way in
which these properties are achieved. They describe what the system must do without saying
how it is to be done.
A formal specification can serve as a single, reliable reference point for those who investigate
the customer‘s needs, those who implement programs to satisfy those needs, those who test
the results, and those who write instruction manuals for the system. Although it might need
to be changed as the design team gains in understanding and the perceived needs of the

28
customer evolve, it can be a valuable means of promoting a common understanding among
all those concerned with the system.

3.0 Tutor Marked Assignment (Individual or Group)

1. Conduct a review of ten (10) critical safety systems that are known to fail
and state what the source of the system failure was.

4.0Self-Assessment Questions

1. Explain what you understand by the term safety critical software.

2. State why testing alone is not enough in achieving the correctness of critical
software
3. Differentiate between program testing and formal specification of a system
in checking the correctness of the system.

Answers to Self-Assessment Questions

1. Software is said to be safety critical if a failure can cause loss of life or severe
injury.

2. Although testing is used to ensure correctness of a system, it has some

limitations:
 Testing can show the presence of errors, but not their absence. exhaustive
testing viable only for trivial systems.
 Representativeness of test cases/injected faults is subjective.
 There is no clear specification on how to test for the unexpected? Rare
cases?
 Testing is labor intensive, hence expensive.

3. As a complement to testing, we need a formal specification and verification of a

system in order to ensure a high level of correctness in safety critical system

5.0 Conclusion/Summary
In conclusion of this session, I have taken you through the following: the
increasingly complex, increasingly ubiquitous nature of software; that we
29
cannot trust safety critical software to careful design, programming, and testing
alone; that formal methods are not a panacea, but can help, and are increasingly
becoming necessary to achieve high assurance; that we will learn several formal
methods—different development stages, different methodologies, different
application domains as the course progresses; and lastly, that we will emphasize
strong formal methods. So, I want you to expect a rigorous exposure to some
formalism in subsequent sessions and modules.

6.0 Additional Activities (Videos, Animations & Out of Class activities) e.g.
a. Visit YouTube add https://bit.ly/2U1HSLb , https://bit.ly/2TDNgin . Watch
the video & summarise in 1 paragraph
b. View the animation on add/site and critique it in the discussion forum
c. Take a walk and engage any 3 students on failed systems in software and
systems engineering; In 2 paragraphs summarise their opinion of the discussed
topic. etc.

7.0 References/Further Reading

Jonathan Bowen, Formal Specification and Documentation Using Z: A Case

Study of Approach, International Thomson Computers Press (ITCP),
1996.
Huth M. and Ryan M. Logic in Computer Science: Modelling and Reasoning
about Systems. Cambridge University Press 1999.
CliffB. Jones, Systematic Software Development Using VDM, 2nd Edition,
Prentice Hall, 1990.

30
 Study Session 2: Mechanical Methods and Steps Towards Abstraction
Introduction
1.0 Learning Outcome
2.0 Main Content
2.1- Recursive descent parsing from (E)BNF
2.2- Encoding STDs
2.3- Assertions, declarations, specifications, code...
3.0 Tutor Marked Assignments (Individual or Group Assignments)
4.0 Study Session Summary and Conclusion
5.0 Self-Assessment Questions and Answer
6.0 Additional Activities (Videos, Animations & Out of Class Activities)
7.0 References/Further Reading

Introduction:
Welcome to the second session of the first module and hope the last session was
very illuminating on the necessity of studying formalisms for checking the
correctness and reliability of systems. In this section we will briefly look at
simple mechanical methods for producing software that exactly match a
specification given in some form or other. You will recall that the specification of
the system describes what the expected functionalities of the to-be system are. So,
I want you to begin to consider formalizing a system.

1.0 Study Session Learning Outcomes

After studying this session, I expect you to be able to:
1. Describe the representation and recognition of formal language sentences.
2. Create parsing recognition of formal language sentences.
3. Creating encode and make specification of a system.

31
2.0 Main Content
2.1. Recursive descent parsing from (E)BNF
The recognition of correct sentences in formal languages (i.e. computer
languages) is well understood. The definition of correct sentences is called the
grammar, and the process of recognition is called parsing.
If we express our grammar formally, we can generate programs that recognise
correct sentences automatically from the formal specification. In the following
example, we limit our grammar to ―one which can be recognised by just looking
at the next symbol‖. Our language is one which specifies mathematical
expressions such as (3* 4) + 2, or a - (b/3). We express this in (E)BNF [5] like
this:

Fig 1.2.1: Recursive descent parsing from (E)BNF

i. <math-exp> ::= <term> { ’+’ <term> | ’-’ <term> }

A <math-exp> is a <term> followed by zero or more occurences of either a
’+’ followed by a <term> or a ’-’ followed by a <term>.

ii. <term> ::= <factor> { ’*’ <term> | ’/’ <term> }

32
A <term> is a <factor> followed by zero or more occurences of either a ’*’
followed by a <term> or a ’/’ followed by a <term>.

iii. <factor> ::= ’(’ <math-exp> ’)’ | <identifier>

A <factor> is either a ’(’ followed by a <math-exp> followed by a ’)’, or an
<identifier>.
The EBNF definition language uses the special symbols ‘{‘, ‘}‘, ‘|‘, ‘::=‘ and
‘<....>‘ to represent various things.
i. The ’|’ bar represents choice: A|B means A or B
ii. <....> represents a non-terminal: <A> means that <A> must appear as
the left hand side of the BNF expression.
iii. <lhs> ::= ..... represents a rule of the grammar: the <lhs> can be
replaced by the right hand side wherever it appears.
iv. { ... } represents iteration: You may have ... repeated zero or more
times.
This can be translated to:

33
Our rules for producing this code are given loosely as follows:
i. Create a procedure for each non-terminal (or left hand side).
ii. A sequence of terms on the right hand side of a BNF expression generates
a sequence of code within the corresponding procedure.
• If a component of the right hand side of a BNF expression is { ... }, generate
code like the following. The termination condition is when none of the internal
items are possible.
iteration := true;
while iteration do

i. If a component of the right hand side of a BNF expression is ‘a‘ <A> |

‘b‘ <B>, generate code like this:
if nextsym in [ ‘a‘,‘b‘] then
case getsym of
‘a‘ : A;
‘b‘ : B
end
ii. Function getsym consumes the next symbol, nextsym just looks at it
without consuming it.
This automatic technique for generating code from BNF is very easy to do, and
generates a recursive descent parser. In languages, such as Pascal, that require
you to declare procedures before using them, you may need to restructure the
code:

34
You can also note that the rules given here correctly parse arithmetic
expressions according to the arithmetic rules of precedence - In figure 2.1
A*B+3 correctly evaluates to (A*B)+3.
The principal applications for this technique would be in any system
recognizing a ‘language‘ - for example:
i. compilers,
ii. the acceptable keystrokes on a cash register,
iii. an input text file format,

In-text Question:
What is the major difference between BNF and EBNF?

Answer
EBNF is an extended version of BNF that allows the usage of other special
symbols.

2.2. Encoding STDs

The state transition diagram (STD) is another method used for (hopefully)
unambiguously describing small systems.
State transition diagrams consist of:
i. A set of states, and
ii. A set of transitions, consisting of
a. Events which allow you to change states, and

35
 b. Actions which may be performed when a particular pairing of states and
events occur.

Figure 1.2.2: State transition diagram for real numbers

In figure 1.1.2, we see a state transition diagram. The circles represent the
states, so our diagram has three states. The lines indicate the allowable
transitions - in this case there are seven allowable transitions. Each transition
arc is marked with an event label in diamond brackets which indicates the event
that will cause the transition, and an action which indicates what to do.
We may specify the STD in the following way:

We may translate the STD to code by adopting the following set of rules:
i. Write a CASE statement for each of the states:
case state of
WAITING : ...

36
 GETNUM : ...
GETDP : ...
end;

ii. Within each state item, write a case statement for each of the events:
GETNUM : case event of
digit : ...
’.’ : ...
otherwise
...
end;

iii. Within each event item, write the actions and then set the state variable:
GETNUM : case event of
digit : begin
temp := (temp*10)+digit;
state := GETNUM
end;

Again we have a simple way to translate a reasonably formal description

directly to code. However, the descriptions are fairly detailed, and can
themselves be difficult to understand, or be open to misinterpretation.
In the following sections, more abstract formal descriptive methods are
introduced, leading to more useful ways of manipulating and verifying software.

2.3. Assertions, Declarations, Specifications and Code

Each of the above mathematical formalisms has been used as the basis for one
or more programming languages. Common to many of these languages is a
reduction in the gap between the specification and the implementation of a

37
problem. It is perhaps easier to show this by example, so here are a few
examples.

2.3.1 Predicate logic: prolog

There are various automatic ways of transforming predicates into statements.
One of these automatic methods [4] is the basis of the prolog engine - a
different sort of computer, and a different sort of computer language.
When you use a prolog system, your program statements are turned into
predicate logic theorems, which are then solved if possible:

In this example, we have

i. written nine lines of prolog, of which
ii. four of the lines created data (1,2,3 & 8),
iii. two lines described the grandfather relationship (6 & 7), and
iv. the other three lines queried the resulting structure.
There are no extra variables or constants or program constructs except for those
needed in the system.
Here is another example of equally terse code implementing a stack in prolog.
This code can be viewed as a specification of a stack.

top(push(*x,*y),*x);
is(pop(push(*x,*y)),*y);
38
empty(S,TRUE);
empty(push(*x,*y),FALSE);

Then, if we query the specification:

empty(S,*x)-w("The new stack is empty: ")-w(*x)-line;
empty(push(apples,S),*x)-w("If we push apples: ")-
w(*x)-line;
empty(*y,*x)-is(pop(push(apples,S)),*y)-w("And then
pop them: ")-w(*x)-line;
top(*y,*x)-is(push(apple,push(pear,S)),*y)-
w("Push a pear then an apple, on top is: ")-w(*x)-
line;
top(*y,*x)-is(pop(push(apple,push(pear,S))),*y)-
w("Push a pear then an apple, pop once, on top is:
")-w(*x)-line;
We get the following results:
The new stack is empty: TRUE
If we push apples: FALSE
And then pop them: TRUE
Push a pear then an apple, on top is: apple
Push a pear then an apple, pop once, on top is: pear

In this example, we can see that there is very little difference between a
specification of a stack, and its implementation. Compare it with the following
partial stack implementation in a conventional Von-Neumann style language:

Const
StackSize = 100;
Type

39
 Stack : array [ 1..StackSize ] of integer;
Var
S : Stack;
index : 1..StackSize;
procedure push(item:integer);
begin
index := index+1;
S[index] := item
end;
...
A summary of comparisons:

2.3.2 Lambda Calculus: FP

One example of a language based on Lambda calculus is Backus‘s FP language.
The following code defines a function which adds together two arrays. It uses
two other functions - AA (Apply to all) and trans (Transpose):
def Add = (AA,+).trans
Read backwards - say ―transpose the arrays and add each item‖.
If we apply this function to two arrays, our FP machine successively rearranges
the expression:
{Add:(1,2,3,4),(4,3,5,9)
{((AA,+).trans):(1,2,3,4),(4,3,5,9)}
{(AA,+):trans:(1,2,3,4),(4,3,5,9)}

40
{(AA,+):(1,4),(2,3),(3,5),(4,9)}
{+:(1,4),+:(2,3),+:(3,5),+:(4,9)}
5,5,8,13
Note that at each stage of the computation of the expression, we have a
complete readable FP expression.
Compare this with the following Von-Neumann program:
Procedure Add;
Var
i : Integer;
begin
for i:=1 to size do
C[i]:= A[i]+B[i]
end;

A summary of comparisons:

2.3.3 Lambda calculus: LISP

Another functional programming language is LISP (Short for List Processing
language). LISP expressions look just like ⋋-expressions except that the ⋋ is
replaced by the word LAMBDA, and infix expressions must be given in prefix
form:

41
LISP is often hard to read due to the large number of brackets in LISP
expressions, and more readable alternatives to LISP are often used:

We can observe the reduction of the LISP expression for the factorial of 2:
FAC 2
COND ((EQ X 0) 1)(TIMES X FAC (MINUS X 1)) 2
Simplification/Use definition
COND ((EQ 2 0) 1)(TIMES 2 FAC (MINUS 2 1))
Reduction
COND (FALSE 1) (TIMES 2 FAC (1))
Simplification
(TIMES 2 FAC (1))
Simplification
(TIMES 2 COND ((EQ X 0) 1)(TIMES X FAC (MINUS X 1))1)
Simplification/Use definition
(TIMES 2 COND ((EQ 1 0) 1)(TIMES 1 FAC (MINUS 1 1)))
Reduction

42
(TIMES 2 COND (FALSE 1) (TIMES 1 FAC (0)))
Simplification
(TIMES 2 (TIMES 1 FAC (0)))
Simplification
(TIMES 2 (TIMES 1 COND ((EQ X 0) 1)(TIMES X FAC
(MINUS X 1))0))) Simplification/Use definition
(TIMES 2 (TIMES 1 COND ((EQ 0 0) 1)(TIMES 0 FAC
(MINUS 0 1))) Reduction
(TIMES 2 (TIMES 1 COND (TRUE 1) (TIMES 0 FAC (-1)))
Simplification
(TIMES 2 (TIMES 1 1))
Simplification
(TIMES 2 1)
Simplification
2
Canonical or normal form
Note that:
i. at each point of the execution of the LISP machine we have a LISP
expression.
ii. there are no von-Neumann style variables
iii. there are only two operations - reduction and simplification
We can also perform program transformations with the same ease found in the
program execution. If we assumed that we had the following three LISP
functions:
S fgx = fx(gx)
B fgx = f(gx)
C fgx = f x g

And the following pure function (i.e. it has no variables or parameters):

43
(DEF FACV
S (C (B COND (EQ 0)) 1 0 (S TIMES (B FAC (C MINUS 1))))
We can transform it into the LISP FAC function as follows:

FACV N
S (C (B COND (EQ 0)) 1 0 (S TIMES (B FACV (C MINUS 1
))) N
C (B COND (EQ 0)) 1 N (S TIMES (B FACV (C MINUS 1 ))
N
(B COND (EQ 0) N 1 )(TIMES N (B FACV (C MINUS 1 )) N
(COND ((EQ 0 N) 1 )(TIMES N (FACV (MINUS N 1 ))) N

What have we just done?

i. We have demonstrated the equivalence of two different LISP programs
ii. Our original program was a pure function (no variables), our final one has
an N variable.
iii. The proof was done without stepping outside of the language.

3.0 Tutor Marked Assignment (Individual or Group)

Use the LISP language to demonstrate the equivalence of two different
representations of FIBONACCI programs such that one takes variable while the
other does not.

4.0 Conclusion/Summary
You have come to the end of this session. In this session, I have discussed with
you two major ways for representing a system in a formal way so as to support
the process of correction checking. First, formal specification programming
languages were presented to you, and then state transition diagram (STDs) were
also discussed. You will be taught some other methods for formalisation of

44
software in subsequent sessions.

5.0 Self-Assessment Questions

For each of the following statements indicate whether they are true or
false. Explain your answer briefly.
1. EBNF is a more expressive notation than BNF, therefore some
languages that can be defined using EBNF cannot be defined using BNF
notation.

2. Every language that can be defined by a grammar (BNF) can also be

defined by a regular expression.

Answers to Self-Assessment Questions

1. False, EBNF is more expressive only in the sense that it is more

convenient to use, but all EBNF specifications can be converted into
equivalent BNF specifications.

2. False, regular expression languages can only specify languages that do

not have "selfembedding"

6.0 Additional Activities (Videos, Animations & Out of Class activities) e.g.
a. Visit YouTube add https://bit.ly/2HVqkcg , https://bit.ly/2Ws0d0s . Watch the video
& summarise in 1 paragraph.
b. View the animation on add/site and critique it in the discussion forum

45
c. Take a walk and engage any 3 students on State Transition Diagrams (STD)
to represent a system and then summarize the process of representing a program
that checks the gender of its users; In 2 paragraphs summarise their opinion of
the discussed topic. etc.

7.0 References/Further Reading

Jonathan Bowen, Formal Specification and Documentation Using Z: A Case
Study of Approach, International Thomson Computers Press (ITCP),
1996.
Huth M. and Ryan M. Logic in Computer Science: Modelling and Reasoning
about Systems. Cambridge University Press 1999.
CliffB. Jones, Systematic Software Development Using VDM, 2 nd Edition,
Prentice Hall, 1990.

46
 Study Session 3: Logic and Set Theory
Introduction
1.0 Learning Outcome
2.0 Main Content
2.1- Propositional logic
2.2- Predicate logic
2.3- Sets Theory
3.0 Tutor Marked Assignments (Individual or Group Assignments)
4.0 Study Session Summary and Conclusion
5.0 Self-Assessment Questions and Answer
6.0 Additional Activities (Videos, Animations & Out of Class Activities)
7.0 References/Further Reading

Introduction:
Dear learner, you are welcome to the third session of the first module. Most
formalization methods (both in Mathematics and Computer Science) are mostly
titled towards logic and algebra (even set theory). I have recognized this and so I
felt it was necessary that the basis of logic and set theory be carefully lay and
presented to you at this onset of the course. Meanwhile, let me make you think out
some notions on logic that you hold. So, why study logic? Well, may be coolness
popped-up from mind? Logic is cool and interesting. Considering hardware,
binary logic is logical and very relevant in its implementation. In software,
programming languages have logical constructs, and in specification and
semantics, the language of logic is unambiguous and can be used to give meaning
to programs. Finally, in proof, arguments are usually logical. Logic is also
relevant in clearer thinking and more effective communication in everyday
situations. For set theory, they are very relevant in building complex mathematical
structures; as they provide means for housing or grouping related components that
can they be manipulated through operators. Much of modern formal specification

47
and proof is performed with the use of propositional and predicate calculi while
set theory also lends a helping hand. In this session, we review some relevant
terminology. You should keep in mind that the calculi here are no more complex
than simple mathematics, and the relevant laws are similar. It may be useful to
compare expressions in various logics - only the symbols change:

1.0 Study Session Learning Outcomes

After studying this session, I expect you to be able to:
1. Describe how to translate prepositional statements using correct notations
2. Explain the need for predicate logic
3. Describe the set notations and operators for specifying systems
2.0 Main Content
2.1. Propositional logic
A proposition is a logical sentence. A proposition is either true or false, but not
both and of type Boolean: T or F. Examples: I am the smartest person in the
room; John had toast for breakfast; and even mathematical expression like 2+2
= 5. Questions, commands and expletives are not propositions. In propositional
logic we construct expressions which evaluate to one of two values: TRUE or
FALSE.
Definition: A proposition P is a statement that is either TRUE or FALSE:

Fig 1.3.1: Propositional logic

48
Conjunction is defined to be the function specified by this table. Disjunction,
negation, implication are similarly defined.

Compound propositions are constructed from simple propositions using the

following symbols:

A propositional formula is said to be a tautology if it is true for all possible

assignments of truth values to its variables. In general, to prove a tautology, one
can construct a truth table for the proposition and checks that its column is all
T‘s.

Contradictions and Contingencies

49
Contradiction: A contradiction is a compound proposition which evaluates to F
for all values of its elementary propositions.
Contingency: A contingency is a compound proposition which may evaluate to
T or F for different values of its elementary propositions.

Limitations of propositional logic

Consider this ―argument‖:

Is this useful? No! This is not a valid argument form in terms of propositional
logic, since p ^ q =>r is not a tautology. There is no relationship between the
propositions.

2.2. Predicate logic

In propositional calculus, we are unable to express things such as classes,
classes of objects, or set membership. We can for instance state that all
machines are operating, and that pc0131 is a machine, but the obvious
conclusion that pc0131 is operating cannot be drawn; because the calculus
cannot express the concept that pc0131 belongs to the class of machines.
Lisa studies predicate calculus! What are the predicates?

50
 Fig 1.3.2: Predicate logic

p(x ) ≡ x is a COMP2600 student.

q(x ) ≡ x is happy.

Now the argument looks like: ∀x.p(x) => q(x)

p(Lisa), therefore q(Lisa)
which we might be able to deal with.

In predicate logic, we introduce two quantifiers:

1. The existential quantifier - ∃ - which means ―There exists‖
2. The universal quantifier - ∀ - which means ―For all‖
We construct expressions using these quantifiers with the following syntax:
∀ x : S ⦁ P - For all x of type S, the predicate P holds.
∃ x : S ⦁ P - There exists an x of type S such that the predicate P holds.
These expressions look like simple propositions, but contain variables. If you
can replace the variables in an expression and get a proposition, the original
expression is called a predicate.
We also have syntaxes for substitution - where we substitute an expression for x
wherever it occurs in the body of the predicate:
P[T/x] - The substitution of T for x in predicate P.
The term bound variable is used for x in the expressions given above.

51
We have:
∀x : S ⦁ P ∧ Q , (∀x : S ⦁ P) ∧ (∀x : S ⦁ Q)
And if x doesn‘t occur in N:
∀ x : S ⦁ N , ∃x : S • N , N
∀ x : S ⦁ P ∧ N , (∀x : S ⦁ P) ∧ N
Along with all the duals of course...
We can also remove quantifiers if x does not occur in T:
∃x : S ⦁ x = T ∧ P ⟺ (T ∈ S) ∧ P[T/x]
∀x : S ⦁ x = T ⇒ P ⟺ (T ∈ S) ⇒ P[T/x]

Universal quantification — Definitions

They have the general form: ∀x ∈ D: P(x). x D.P(x): means that for any x
chosen from D, P(x) is a true proposition. In ∀x ∈ D.P(x):
– ∀ is the quantifier;
– x is the bound variable;
– D is the domain;
– P(x) is a predicate (possibly) involving the bound variable x.
Abbreviations and rules used in universal quantification are:
i. The domain can be omitted if it can be inferred from the context: ∀x: P(x).
ii. ∀x,y ∈ D: P(x,y) is an abbreviation for ∀x ∈ D.( ∀y ∈ D.P(x,y))
iii. Unnecessary parenthesis may be omitted: ∀x ∈ D: ∀y ∈ D.P(x,y)
iv. (∀x. ∀y: P(x,y)) ≡ (∀y. ∀x.P(x,y))
For example, (∀x. ∀y. x+y=y+x) ≡ (∀y. ∀x x+y=y+x)

Existential quantification
The existential quantifier is denoted by ∃, and is pronounced for some or there
exists.

52
Examples: ―Some students are happy‖, ―There is a happy student‖, ∃ s ∈
Student. s is happy; and ∃x. (∃y. x+y=y-x). Existential quantification is defined
by: General form: ∃x ∈ D.P(x). ∃x ∈ D.P(x): means that for one or more x
chosen from D, P(x) is a true proposition. In ∃x ∈ D.P(x):
i. ∃ is the quantifier;
ii. x is the bound variable;
iv. D is the domain
iv. p(x) is a predicate (possibly) involving the bound variable x.

In-text Question: Translate the statement “Not all 400 Level Computer Science Students are
rich” into appropriate predicate logic representation:

Answer
¬ (Ɐx ComputerScience400LStudents(x) → Rich(x) )

2.3. Sets and relations

The concept of a set is a familiar one, with immediate natural understanding of
such terms as
i. The set of integers, or
ii. The set of library books.
A set is a defined aggregation of values, and the members of the set are not in
any particular order. In formal methods, we limit our use of sets and set
variables to typed values, in order to avoid Russell‘s paradox. Set is the
foundation of many formal methods.
Sets:
The following base sets are defined:

53
It is common to use capital letters to refer to sets, with small letters used for set
variables. Sets may be specified using ‘{item1, item2;…}‘, or just identified:
[BOOKS]. A set variable x of type BOOKS may be written x : BOOKS.
This table introduces some elemental features of set theory:

We may tabulate the properties of the new set operations, but the table may
soon become quite large. For the first few features:

A set is a well-defined collection of objects considered as a whole. The objects

of a set are called elements. Sets are conventionally denoted with capital letters,
A, B, C, etc. Two sets A and B are said to be equal, written A = B, if they have
the same elements.
We write
i. x ∈ A if x is an element of A
ii. x ∉ A if x is not an element of A
iii. A is a subset of B (A ⊆ B), if for all x ∈ A: x ∈ B

54
iv. A is a proper subset of B (A ⊂ B), if A ⊆ B and A ≠ B

If A ∈ F, then the cardinality of A is the number of elements in A:

i. Traditional: |A| is the cardinality of A
ii. In Z notation, we use #A is the cardinality of A

Let A be a set. The power set ℙA is the set of all subsets of A, i.e. ℙA = {B | B
⊆ A}. ℙ1 A is the set of non-empty subsets of A. Also, 𝔽 is the (infinite) set of
finite sets, and 𝔽1 is the set of non-empty finite sets.

Functions
Definition: Let A, B be sets and f : A ↔ B a relation. f is called a (partial)
function if f (a, b) and f (a, c) implies b = c. In that case, we write f : A B and
f (a) = b.
dom f = {a | (a, b) ∈ f } is called the domain of f
ran f = {b | (a, b) ∈ f } is called the range of f
If dom f = A, then f is called a total function, and we write f : A → B
If ran f = b, then f is called surjective, and we write f : A ↠ B or f : A ↠ B (if f
is total)
If f (a) = c and f (b) = c imply a = b, then f is called injective.
If f is both injective and surjective, it is called bijective or a one-to-one
mapping.

Relations:
A relation can be modelled by a set of ordered pairs, and so operators defined
on sets may be used on relations. There are various notations used for
representing relations. We may just list the pairs { ⟼ ; ⟼ ,…, ↦
}, or we can write:

R: X ⟼ Y

55
X ⟼ Y is the set of relations from X to Y – 𝕡 (X × Y)

To express the idea that a variable x is related to y by a relation R, we write xRy

or x ⟼ y, and we write the domain of the relation:
dom R ≡ {x : X | (∃x : X ⦁ xRy)}

Set comprehension (or comprehensive specification), may be used to specify a

set:
{D | P ⦁ E }or {D | P}
D is the signature, or declaration part,
P is the predicate, or constraint part, and
E is the term,

For example:
{x: ℕ | x ≤ 5 ⦁ } = f0 1 4 9 16 25}
{x: ℕ | x ≤ 5} = {0 1 2 3 4 5}
{x: ℕ ⦁ } = {0 1 4 9 16 25…}

We can also use existential and universal quantifiers, with syntax similar to that
given before:
∃ D | P ⦁ Q and ∀D | P ⦁ Q

We may negate a quantifier as follows:

¬ (∃D | P ⦁ Q) , (∀D | P ⦁ (¬Q)), and
¬ (∀D | P ⦁ Q) , (∃D | P ⦁ (¬Q))

Theorem notation:
A common activity in any formal mathematical transformation is the proof of
theorems. Mathematicians start with givens (which they call hypotheses, and
assume are true), and progress towards conclusions, using deductive rules.

56
Again there are various notations for this. It is common to use the turnstile (`) to
separate a hypothesis and a conclusion:
If the conclusion has free variables, they must be declared in the hypothesis - if
not it is unnecessary:
⊢ ∀x : N | x > 5 ⦁ > 25
A proof is a sequence of theorems derived from hypotheses establishing the
conclusion. Each step in the proof must be either a fundamental property, or
follow on from previous theorems by using a rule of deduction. We use the
following notation:

If our hypothesis is H, and P and Q are predicates, the following rules (and
others) may be used:

Schema:
The schema notation is a signature/predicate pair, either written as [S | P] if the
signature and predicate are small, or inside the schema construct:

If we wanted to declare a boolean set BOOL, we can use the following

shorthand notation, or the schema (which declares much the same thing).
BOOL ::= TRUE | FALSE
or:

57
2.4. Lambda Calculus
The lambda (⋋) calculus is a notation for relating functions and their arguments.
It has rules for combining functions.
Definition: A lambda (⋋) expression is made up of variables and the three
symbols ⋋, (and).
1. A single variable is a ⋋ -expression.
2. If A is a ⋋-expression, then ⋋ xA is also one.
3. If B and C are ⋋-expressions, then so is (BC).
4. In ⋋ xA, ⋋ x is the bound variable part, and A is called the body.
5. In (BC), B is the operator and C is the operand.
Associated with this notation is a set of rules (a calculus). The main rule is
similar to ―Parameter passing using call by name‖.
Definition: In ((⋋ xB) A), the effect of the application of the operator ⋋ xB to
the operand A is the substitution of A for all free occurrences of x in B. This rule
is also called reduction.
The bound variables in ⋋-calculus do not imply memory locations as variables
in Von-Neumann languages do. They are just used to make expressions easier
to read. One of the core theorems of ⋋-calculus demonstrates that all such
variables may be removed. The ⋋-calculus encompasses the range of
computable functions:
⋋ x (x + 1) is the successor function,

58
⋋ x (0) is the zero function
⋋ xyz (y) is the identity function
Programming languages based on ⋋-calculus are called reduction, functional or
applicative languages.

3.0 Tutor Marked Assignment (Individual or Group)

1. Show: If A, B ∃ (a finite set), then #(A × B) = #A × #B.

4.0 Conclusion/Summary
You have come to the end of this session where we have focused on the concept
of logic and set theory. I have dwelt on some forms of logic representation
(predicate and propositional logics) and set theory (and its operators). On logic,
you were taught on both prepositional and predicate logics and why the later
over the former. Secondly, we looked into some set notations and their
operations, and also the concepts of relations and functions which we shall later
use in understanding Z specification language.

5.0 Self-Assessment Questions

1. Explain what you understand by tautology and prove the completeness of the
tautology (p⋀ (p→q)→q)

Answers to Self-Assessment Questions

1. A propositional formula is said to be a tautology if it is true for all possible

assignments of truth values to its variables.

Proving the completeness of ⋀

We could write down it‘s truth table and prove each line separately.

59
That is, we need to prove each of the following:

as shown below

6.0 Additional Activities (Videos, Animations & Out of Class activities) e.g.
a. Visit YouTube add https://bit.ly/2WmHRho , https://bit.ly/2Yw7I8s . Watch the
video & summarize in 1 paragraph
b. View the animation on add/site and critique it in the discussion forum

60
c. Take a walk and engage any 3 students on Comparisons of predicate logic
and propositional logic; In 2 paragraphs summarize their opinion of the
discussed topic. etc.

7.0 References/Further Reading

Jonathan Bowen, Formal Specification and Documentation Using Z: A Case
Study of Approach, International Thomson Computers Press (ITCP),
1996.
Huth M. and Ryan M. Logic in Computer Science: Modelling and Reasoning
about Systems. Cambridge University Press 1999.
CliffB. Jones, Systematic Software Development Using VDM, 2 nd Edition,
Prentice Hall, 1990.

61
 Study Session 4: Soundness and Completeness, and Model and Interpretation
Introduction
1.0 Learning Outcome
2.0 Main Content
2.1- Soundness and Completeness
2.2- Model and Interpretation
3.0 Tutor Marked Assignments (Individual or Group Assignments)
4.0 Study Session Summary and Conclusion
5.0 Self-Assessment Questions and Answer
6.0 Additional Activities (Videos, Animations & Out of Class Activities)
7.0 References/Further Reading

Introduction
You have now come to the last session in module 1 of this course. Recall that so
far, we have gone through the introductory notes to this course, to methods of
abstraction, and on logic and set theory. In this last session, we shall be
considering two important concepts for measuring the acceptability of logic
system: soundness and completeness. Meanwhile, we shall also consider how to
represent the model of a system and decide which (of all interpretations in a
model) are the correct interpretations of the system. Soundness is among the
most fundamental properties of mathematical logic. The soundness property
provides the initial reason for counting a logical system as desirable. The
completeness property means that every validity (truth) is provable. Together
they imply that all and only validities are provable. Most proofs of soundness
are trivial. Most axiomatic systems have only the rule of modus ponens (and
sometimes substitution), so it requires only verifying the validity of the axioms
and one rule of inference. The idea behind proving completeness is that we can
use the law of excluded middle and ∨ introduction (as in the example proof
from the previous lecture) to separate all of the rows of the truth table into

62
separate sub-proofs; for the interpretations (rows) that satisfy the assumptions
(and thus the conclusion) we can do a direct proof; for those that do not we can
do a proof using ―reductio ad absurdum‖. In other words, we can build a proof
tree corresponding to each row of the truth table and snap them together using
the law of excluded middle and ∨ elimination.

1.0 Learning Outcome

After going through this section, you are expected to be able to do the
following:
a. Explain it means for a system to be sound
b. Describe it means for a system to be complete
c. Highlight implication of a consistent system
d. Create an interpretation of a system using truth table and list its model

1.0 Main Content

2.1 - Soundness and Completeness
Soundness
Soundness means that you cannot prove anything that's wrong; Soundness is the
property of only being able to prove "true" things. This can be written as shown
below
if g |- KB is provable, then g |= A
Every theorem of propositional logic proved with Gentzen‘s rules is a tautology.
If you can prove it, then it‘s true. Soundness properties come in two main
varieties: weak and strong soundness, of which the former is a restricted form of
the latter. So a given logical system is sound if and only if the inference rules of
the system admit only valid formulas. Or another way, if we start with valid
premises, the inference rules do not allow an invalid conclusion to be drawn.

63
Soundness of a deductive system is the property that any sentence that is
provable in that deductive system is also true on all interpretations or structures
of the semantic theory for the language upon which that theory is based. In
symbols, where S is the deductive system, L the language together with its
semantic theory, and P a sentence of L: if ⊢S P, then also ⊨L P
Completeness
Completeness means that you can prove anything that's right; Completeness is
the property of being able to prove all true things. This can be written as shown
below:
if g |= KB is provable, then g |- A
Every tautology in propositional logic is a theorem provable with Gentzen‘s
rules. If it‘s true, then you can prove it. A system is complete if and only if all
valid formula can be derived from the axioms and the inference rules. So there
is no valid formula that we can't prove. In both cases, we are talking about some
fixed system of rules for proof (the one used to define the relation ⊢). In more
detail: Think of Σ as a set of hypotheses, and Φ as a statement we are trying to
prove. When we say Σ⊨Φ, we are saying that Σ logically implies Φ, i.e., in
every circumstance in which Σ is true, then Φ is true. Informally, Φ is "right"
given Σ. When we say Σ⊢Φ, on the other hand, we must have some set of rules
of proof (sometimes called "inference rules") in mind. Usually these rules have
the form, "if you start with some particular statements, then you can derive
these other statements". If you can derive Φ starting from Σ, then we say that
Σ⊢Φ, or that Φ is provable from Σ.
We are thinking of a proof as something used to convince others, so it's
important that the rules for ⊢ are mechanical enough so that another person or a
computer can check a purported proof (this is different from saying that the
other person/computer could create the proof, which we do not require).
Soundness states: Σ⊢Φ implies Σ⊨Φ. If you can prove Φ from Σ, then Φ is true
given Σ. Put differently, if Φ is not true (given Σ), then you can't prove Φ from

64
Σ. Informally: "You can't prove anything that's wrong." Completeness states:
Σ⊨Φ implies Σ⊢Φ. If Φ is true given Σ, then you can prove Φ from Σ.
Informally: "You can prove anything that's right." Ideally, a proof system is
both sound and complete.

Fig 1.4.1: Soundness and Completeness

For example: A positive program is a program with an error. A negative

program is a program without an error. So there are four types of programs: A
positive program analysed as positive -> true positive (TP). A positive program
analysed as negative -> false negative (FN). A negative program analysed as
positive -> false positive (FP). A negative program analysed as negative -> true
negative (TN). A system is sound, if it never accepts a positive program. A
system is complete, if it never rejects a negative program.

In-text Question:
Using appropriate notations to differentiate between completeness and soundness of a logic
system.

Answer
Soundness: A sound system does not produce any bad results. If you can prove it, then it’s
true. If g is an axiom and KB is a knowledge base, then if g |- KB is provable, then g |= A

65
Completeness: A complete system can produce all the good results. f it’s true, then you can
prove it. If g is an axiom and KB is a knowledge base, then if g |= KB is provable, then g |-
A

Consistency: A consistent system does not produce conflicting results.

i. For some formula P, we cannot prove both P and ¬P.
ii. For natural deduction this follows from soundness, though the formal proof is
more involved.

If the specification (say Γ) is consistent, then, as you rightly said, there will be
a row of the truth table that assigns 'true' to all ϕ∈Γ. If, however, Γ is not
consistent, then some formulas ϕ,ψ∈Γ are such that ϕ≡ψ. This means that no
row in the truth-table can satisfy both ϕ and ψ. But since ϕ and ψ are members
of Γ, any row of the truth-table will then be a counter-model of Γ. For example,
suppose Γ={P,¬P}. Since Γ contains an inconsistent pair, it's not satisfiable.
Therefore, both assignments of truth-values to P will be counter-models for Γ,
so you could just give the following assignment as an answer: 'true' ↦ 'P'.

2.2 - Model and Interpretation

The truth value of a compound sentence is determined by the interaction of the
truth value of its component sentences and the logical connectives linking these
components. A truth table is a convenient format for displaying the semantics
of a formula by showing its truth value for every possible interpretation of the
formula. Here is a truth table for the formula (p→q)↔(¬q →¬p):

We compute the truth table for (p ∧ q) → r. The three distinct statement

variables p, q and r generate the 2×2×2=23=8 permutations of truth values in the

66
corresponding truth table. For this sentence, the innermost connective is ∧ and
the outermost is →. The construction of the truth table proceeds as above,
starting with the computation for the innermost connective (the conjunction of
the first and second columns) in the fourth column and working outward to the
next connective (the implication of the fourth and third columns) in the final
(fifth) column.

Intuitively an interpretation is a situation: it contains the kind of things we want

to speak about. It gives us two pieces of information: It tells us which collection
of atomic propositions we are talking about (domain, D), and for each formula it
gives us an appropriate semantic value, this is done by means of a function
called interpretation function (I). Thus an interpretation is a pair: (D, I). An
interpretation function (or truth value assignment) of the atoms in D is a
function I : I:D→{T,F}.The truth value of a complex formula depends on the
truth values of its parts. We have seen that for each connective this is prescribed
in a truth table. An interpretation m is a model of a sentence α if α is true in m.
M(α) is the set of all models of α.i.e. the set of all the interpretations where α is
true.

The main concepts to focus attention on are: (1) Entailment and (2)
Satisfiability.
a. Entailment: KB|=α iff M(KB) ⊆ M(α) in words, Knowledge Base (KB)
entails sentence α if and only if α is true in all models of the KB (i.e. for all
interpretations where KB is true).

67
b. Satisfiability: A set of statements is satisfiable if the statements can all be
true simultaneously (i.e. there is one model of all statements). Otherwise it
is unsatisfiable (i.e. there is no model of all statements). A set of statements
is a tautology if the statements are always all true simultaneously (i.e. for
every interpretation.

3.0 Tutor Marked Assignments (Individual or Group)

1. Compute the truth table for each sentence and identify each sentence as a
tautology, a contradiction, or a contingency.
i. p ↔ (∼p)
ii. p ∧ (p → p)
iii. ∼ [(∼p) → p]

4.0 Conclusion/Summary
In this session, you have studied the relevance of soundness and completeness
in checking logical systems. Furthermore, the use of truth table was also
demonstrated to you so as to show situations where a logical system is
satisfiable or not by listing the models of the logical system.

5.0 Self-Assessment Questions

1. Given the following knowledge-based { use a truth table to

show which interpretation is a model.

Answer to Self-Assessment Questions

P Q R

68
 T T T Not a Model
T T F Is a Model
T F T Not a Model
T F F Not a Model
F T T Not a Model
F T F Is a Model
F F T Is a Model
F F F Is a Model

6.0 Additional Activities (Videos, Animations & Out of Class activities) e.g.
a. Visit YouTube add https://www.youtube.com/watch?v=0rpuAcnccFM ,
https://www.youtube.com/watch?v=rY1Ydj7ExPs ,
https://www.youtube.com/watch?v=rY1Ydj7ExPs , and
https://www.youtube.com/watch?v=hBpmh4J7ptA ,
b. View the animation on add/site and critique it in the discussion forum
c. Take a walk and engage any 3 students on soundness and completeness; In 2
paragraphs summarize their opinion of the discussed topic. etc.

7.0 References/Further Reading

Jonathan Bowen, Formal Specification and Documentation Using Z: A Case
Study of Approach, International Thomson Computers Press (ITCP),
1996.
Huth M. and Ryan M. Logic in Computer Science: Modelling and Reasoning
about Systems. Cambridge University Press 1999.
CliffB. Jones, Systematic Software Development Using VDM, 2 nd Edition,
Prentice Hall, 1990.

69
 MODULE 2
Study Session 1: Traditional Program Proof and Proof System
Study Session 2: Lambda Calculus and Probability Proof
Study Session 3: Hoare Logic and Weakest Precondition Calculus

Study Session 1: Traditional Program Proof and Proof System

Introduction
1.0 Learning Outcome
2.0 Main Content
2.1- Informal reasoning about programs
2.2- Formal reasoning about programs
2.3- Simple imperative language
2.4- Example
2.5 – Natural Deduction
3.0 Tutor Marked Assignments (Individual or Group Assignments)
4.0 Study Session Summary and Conclusion
5.0 Self-Assessment Questions and Answer
6.0Self-Assessment Question Answers
7.0 References/Further Reading

Introduction:
Welcome to the first session of the second module. In the first module, I
concentrated on letting you understand the different methods for representing a
system in a formal way. But why do you need to understand those methods?
Except a system is formally represented, you may not be able to efficiently
reason with it. Now that you know some formalism strategies, we shall build on
that both in the sessions in this module and subsequent modules. Meanwhile, in

70
this session you shall be taken through the methods of proof systems. Most
software engineers reason about their programs in some form or other. In this
section, we develop the form of a program proof. We must first make clear what
is meant by correctness. In this context, we always mean ―correctness with
respect to a specification‖. The program may have glaring errors which cause
all output to be corrupt, but if the program matches the specification, it is
deemed to be correct. We break down our definition of program correctness
into two sorts:
Partial correctness: The implementation matches the specification. When our
program runs, it gives a correct result if it gives a result. However it is possible
for our program to run and just never give an incorrect result.
Total correctness: The implementation is partially correct, and it terminates.
The proof methods for termination are normally quite different from the proof
methods for partial correctness, and so breaking our concept of correctness into
two parts allows us to prove parts of our program independently.
Sometimes it is extremely hard to prove either.
while x>1 do
if even(x) then
x := x/2
else
x := (3*x)+1

Question: Under what initial conditions does the above program segment
terminate?

1.0 Study Session Learning Outcome

After studying this session, I expect you to be able to:
1. Describe the proof system techniques.
2. Use some proof methods to proof a logical system

71
2.0 Main Content
2.1. Informal reasoning about programs
With a mathematical theorem we argue that ―Given a specified hypothesis P,
the conclusion Q is true‖ (P ⊢ Q). We use the same style for reasoning about
the correctness of programs, using the terminology precondition to refer to P,
and postcondition to refer to Q.

Fig 2.1.1: Informal reasoning about programs

The precondition and postcondition of a program segment can be viewed as a

specification of the program segment.
sample := SomeNumberLargerThan2;
while sample>=2 do
sample := sample-2
Informally, we reason that:
If sample starts off even, it remains even. If sample starts off odd, it remains
odd.
We can say that the evenness or oddness (parity) is an invariant of the loop.
After executing the loop, sample will be less than 2, and will be of the same
parity as the original.

72
2.2. Formal reasoning about programs
If we have {P}segment1 {Q}segment2 {R}, then:
i. If {R} is our correct final state, then we are interested mostly in {Q}, the
set of states that result in {R}.
ii. We are concerned also with {P}, the weakest precondition for (segment1;
segment2) which results in {R}.
We can define the weakest precondition wp as the set of initial states that
guarantee the post-condition.

wp:(segment2):{R} = {Q}

wp:(segment1):{Q} = {P}

wp:(segment1; segment2):{R} = {P}

if {P} is {TRUE}, then all states lead to {R}.

{even} {P}

while sample>=2 do while (R)

sample := sample-2 Z (where {P}Z {P})

endwhile

{even ∧ sample < 2} {P ∧:R}

Most programmers reason about their programs in this way even if they have
not met Hoare‘s terminology, but with larger programs, the reasoning becomes
much harder. It takes quite a while to ensure yourself of the correctness or
otherwise of the following program fragment for ensuring that two processes do
not simultaneously enter a critical section.

73
procedure P(boolean i);
begin
want[i] := true;
exit := false;
while not exit do
begin
if turn<>i then
begin
while not want[i] do;
turn := i;
end
else
if turn=i then
exit := true
end;
want[i] := false
end;

2.3. Simple Imperative Language

The following simple imperative language is used when reasoning about
programs.
Program ::= abort
| skip
| x := E (Assignment)
| seg; seg (Sequence)
| if B then seg1 else seg2 fi (Choice)
| seg1 ⊓ seg2 (Non-deterministic choice)
| (𝜇 X:C) (Recursion)

74
 Fig 2.1.2: Simple Imperative Language

We have not included iteration, as it is just a simple case of recursion:

i. do B seg od ≡ (𝜇 X:if B then (seg; X) else skip fi)

We also commonly shorten:

ii. x := ⊓ x := ⊓ … to x ∈ { , ,…}.

The above language has associated with it a weakest precondition semantics:

wp.abort.Q ≡ false
wp.skip.Q ≡ Q
wp.(x := E).Q ≡ Q[x := E]
wp.(seg1; seg2).Q ≡ wp.seg1.(wp.seg2.Q)
wp.(if B then seg1 else seg2 fi).Q ≡ (B ∧ wp.seg1.Q)⋁(:B ∧ wp.seg2.Q)
wp.(seg1 ⊓ seg2).Q ≡ wp.seg1.Q ∧ wp.seg2.Q
... and so on ...

One case associated with the use of the iterative construct is commonly used in
proofs, and is commonly called the loop invariance theorem:
iii. {P}do B seg od {P ∧ ¬B} ⇔ wp.(do B seg od).{P ∧ ¬B} := {P}

75
2.4. Example
In RSA encryption and authentication, we often have to solve large integer
equations. The numbers involved may easily be larger than the number of
molecules in the universe (about ).
Question - What is the remainder after you divide 111 into ?
One solution to this sort of problem is the following code fragment, which
calculates C =
mod( ,N) for all P,Q,N > 0.
c := 1;
x := 0;
while x<>Q do
x:=x+1;
c:=mod(c*P,N)
end

We can write this in our language as:

Line 1: c := 1;
Line 2: x := 0;
Line 3: do x<>Q x:=x+1; c:=mod(c*P,N) od

We would like our final state to be c = mod( ,N), and looking at the final line,
we notice that it is a do…od, so we rewrite the final state to follow the form
found in the loop invariance theorem:
{c = mod( ; N) ∧ x = Q} , {c = mod( ,N)}
If the assignments in line 3 of our program leave c = mod( , N) unchanged2,
then using the
loop invariance theorem:
wp.(line 3).{c = mod( , N)g . {c = mod( , N)}

76
Now we know the weakest precondition for line 3, we can find the weakest
precondition for line 2:
wp.(line 2).{c = mod( , N)} . c = {mod( , N)}
Now we know the weakest precondition for line 2, we can find the weakest
precondition for line 1, and hence the whole program fragment:
wp.(line 1).{c = mod( , N)} . {1 = mod( , N)} and of course, {1 = mod( ,
N)} . {true}.
This argument shows that the weakest precondition for our whole program
segment is {true}, but there is one step that we have not justified – we must be
sure that line 3 leaves c = mod( , N) unchanged.
We can just apply the same reasoning to the smaller program fragment within
the do::od loop:
{c = mod( , N)g
x := x+1;
{c = mod( , N)g
c := mod(c*P,N)
{c = mod(mod( , N) * P,N)g ⇒ {c = mod(mod( , N)
+ (K * N), N)}
{c = mod( , N)}

We have proved each step of the program and demonstrated that the desired
post-condition will be reached from all initial states ({true}). This is partial (not
total) correctness.

2.5 Natural Deduction

There exist several ways to write the derivations done with natural deduction. I
will use the Fitch style, because it's the one I used when learning, it's easy to
understand, and occupies little space. It's something like this:
77
This is sufficient to prove the validity of . That
figure is to be done line by line, from top to the bottom. The numbers from the
left show the number of each line, and are always in natural order. The first
lines contain each of the formulas which are written in the left part of the

sequent. In this case, they are two: and . From these we will have

to achieve the formula . On each line we write what new thing we

have just discovered to be true, and to the right we note how did we discover
that. Those symbols from the right side ( and ) are the abbreviations of the
names of the 9 rules. For example, here we can see implication elimination (
), conjunction introduction ( ), and implication introduction ( ). The
numbers that go with them give us information about from where did we extract
each necessary formula which is needed to apply the rule. They are line
numbers, so, to be able to apply a rule, one has to use information only from the
lines already written.
Finally, that vertical line which goes from line 3 to 6 it's a hypothesis (that's
why we put to the right). Everything which is inside it, is not always true, but
only when happens (the heading of the hypothesis, at line 3). So, all of the
work we do inside the hypothesis cannot be used outside it, because it can't be
assured to be always true. The procedure finishes when we discover that it's true

78
the formula at the right side of the sequent, in this case (it appears at
the last line).
The derivation rules
Here, the derivation rules are defined and explained the nine basic rules which
are used in natural deduction. Their objective is to tell us when and how can we
add new formulas which continue being true.
1. Iteration: This is a very simple rule:

Well, I know, written like this is a bit strange, but I put it this way to make it
useful as the definition of the rule. What is contained in the above formulation
is that if on line number we have written (whatever expression it is) then we
have the option to write again , but in the current line, and to justify that, we
must write at the right .
2. Conjunction introduction: The conjunction (that's the and) can be created
easily:

You should be able to understand the meaning of figures like this one. When we
put a long horizontal line, normally it's to separate the premises (top) from the
conclusion (bottom). Premises are conditions which must be fulfilled in order to
apply the rule, and conclusion (or resolvent) is the result of the application of
the rule.
3. Conjunction elimination: This is just the inverse operation of the previous
one. It has two parts; firstly:

79
And secondly, for the case you wanted :

So, you can separate in several lines the conjunctands of a conjunction. That's
why this rule is called conjunction elimination, because from one line which has
conjunction symbols ( ) you can extract several which don't have it,
supposedly trying to approach to the formula which we want proved.
4. Implication introduction: This is more interesting, since it allows doing
something useful with hypothesis (those sub-demonstrations which have
a vertical bar to the left). It's:

And what it does mean is that if we supposed something (call it ), and we just
discovered (by using the rules) that supposing made true (whatever it is),
then we have something clear: we can't assure that always is true, but we can
assure that implies , which is written .
5. Implication elimination: This one is simpler than the previous, since it
does not deal with suppositions but with facts:

Simply, if we are told that when also happens (that's what it means ),
and they also tell us that now happens , then we can assure that .

80
 6. Disjunction introduction: The disjunction (that's the or) is very easy but
not obvious:

Well, to be exact, I will say that it's also available in the other order:

That's wonderful, isn't it? If we know that ``it's Thursday'' we also know that
``it's Thursday or cows can fly'', ``it's Thursday or Friday'', or even ``it's
Thursday... or not''. All of them are true.

7. Disjunction elimination: This is the most complicated rule, mainly

because if we are given a phrase with or, like ``it's Thursday or Friday'',
what can we deduce from it? That it's Thursday? No, it may be Friday.
That it's Friday? No, it may be Thursday. That it's Thursday or Friday?
Well, yes, but we already knew that... The rule (now I explain it):

We need more information besides the . If, luckily, we happen to know

, and also , then we do know what happens when : both one
option and the other drive us to , so is true. This type of things only happen
when the exercise is prepared so that the disjunction elimination appears, or
when and are similar (then we will find some which is implied by both).

81
 8. Negation introduction: This one is nice and interesting:

If after supposing , you achieved the conclusion that both and are true,
you're not lost, since you just discovered another truth: that it's not possible for
to be true, that's it, it's true.
For instance, I confess that if I use Windows, I don't profit the time I am with my
computer. Since some years, I do profit it, so the conclusion is that I don't use
Windows. To achieve that conclusion, the path that you would follow (maybe
without thinking) is precisely the one that this rule needs: suppose that I do use
Windows, in that case I wouldn't profit my computer. But I said that I do profit
it, so that supposition must be wrong.
9. Negation elimination: This one is too simple, but we also have to know it:

So, when we see the negation of the negation of something, we can take off
these two following negations.

82
In-Text Questions

1. Use natural deduction to proof the following:

⊢ ∧

Answer

3.0 Tutor Marked Assignments (Individual or Group)

1. Using natural deduction, proof the validity of the following
⊢ ⋀

4.0 Conclusion/Summary
In this session, I have taken you through proof systems and techniques that I
discussed in detail. In addition, you will observe that I concentrated our
discussion around natural deduction method of carrying out proof, even as I
discussed both informal reasoning and formal reasoning about programs. In the
next session, I shall show you another proof system.

5.0 Self-Assessment Questions

1. Use natural deduction to proof the following:
i. P⋁(Q⋀R) ⊢ P⋁Q
ii. ∃ ( ⋁ ) ⊢ (∃ )⋁ ∃

83
Answers to Self-Assessment Questions
i.

ii.

6.0 Additional Activities (Videos, Animations & Out of Class activities)

a. Visit YouTube add https://bit.ly/2CGeTS9 , https://bit.ly/2HXhtGW . Watch

the video & summarize in 1 paragraph

b. View the animation on add/site and critique it in the discussion forum

84
c. Take a walk and engage any 3 students on proof by natural deduction and
argumentation, and contrast the two methods; In 2 paragraphs summarize their
opinion of the discussed topic. etc.

9.0 References/Further Reading

Jonathan Bowen, Formal Specification and Documentation Using Z: A Case
Study of Approach, International Thomson Computers Press (ITCP),
1996.
Huth M. and Ryan M. Logic in Computer Science: Modelling and Reasoning
about Systems. Cambridge University Press 1999.
CliffB. Jones, Systematic Software Development Using VDM, 2nd Edition,
Prentice Hall, 1990.

85
 Study Session 2: Lambda Calculus and Probabilistic Proof
Introduction
1.0 Learning Outcome
2.0 Main Content
2.1- Lambda Calculus
2.2-Probabilistic Proof
2.3- Example
3.0 Tutor Marked Assignments (Individual or Group Assignments)
4.0 Study Session Summary and Conclusion
5.0 Self-Assessment Questions and Answer
6.0 Additional Activities (Videos, Animations & Out of Class Activities)
7.0 References/Further Reading

Introduction:
Welcome to the second session of module two where you shall be carried
through the concept of lambda calculus and proof by probability technique. The
λ-calculus is, at heart, a simple notation for functions and application. The main
ideas are applying a function to an argument and forming functions by
abstraction. The lambda calculus can appear arcane on first encounter. Viewed
purely as a ―naming device‖, however, it is a straightforward extension of
ordinary mathematical notation. The benefit of lambda calculus is that it's an
extremely simple model of computation that is equivalent to a Turing machine.
But while a Turing machine is more like assembly language, lambda calculus is
more a like a high-level language. And if you learn Church encodings that will
help you learn the programming technique called continuation-passing style,
which is quite useful for implementing backtracking search and other neat
tricks. The main use of lambda calculus in practice is that it is a great laboratory
tool for studying new programming-language ideas. If you have an idea for a
new language feature, you can add the new feature to the lambda calculus and

86
you get something that is expressive enough to program while being simple
enough to study very thoroughly. This use is really more for language designers
and theorists than for programmers. Lambda calculus is also just very cool in its
own right: just like knowing assembly language, it will deepen your
understanding of computation. It's especially fun to program a universal Turing
machine in the lambda calculus. But this is foundational mathematics, not
practical programming. In computer science we want to analyse and understand
source-code with mathematical rigor. That's the only way to prove interesting
properties (such as termination) with absolute certainty. For that we need a
language with a very well-defined meaning for every construct. In theory this
could be any language with a good formal semantics. But to make things less
complicated and less prone to error, it's best to use a language that is as simple
as possible but still able to express any program (i.e. is Turing complete). For
reasoning about imperative code, there are Turing machines. But for reasoning
about functional programming, there is the λ-calculus.

On the other hand, the probabilistic method is an efficient technique to prove

the existence of combinatorial objects having some specific properties. It is
based on the probability theory but it can be used to prove theorems which have
nothing to do with probability. The probabilistic method is now widely used and
considered as a basic knowledge.

1.0 Study Session Learning Outcome

After studying this session, I expect you to be able to:
1. Describe the concept of Lambda calculus.
2. Make proofs on system using the technique probability.

87
2.0 Main Content
2.1. Lambda Calculus
Have you ever imagined what programs are made from? The examples in
Figure 2.2.1 show two definitions which are very similar. There are some
features that are common to most languages. These includes variable names,
function parameters, pattern matching, function bodies, function application,
sequencing, substitution, choice, exceptions, data structures, state, parallelism,
data types, primitive operations, templates, objects, polymorphism, reflection,
input/output, operator, overloading, and multiple inheritance. But consider that
we want to create a very simple/smallest possible programming language. What
features would it absolutely, positively, have to have? I think that should
include variable names, functions, and function application.

Figure 2.2.1: Specifying Functions in C/C++ and Haskell

In Lambda Calculus, variable names could take the form x, y, z, and

expressions take the form
e = x (variable)
e = λx. e (function abstraction)
e = | e e (function application)

Also, evaluation takes the form (λx. e1) e2 → e1[e2/x]

88
All computable functions can be expressed in the lambda calculus (l). l
Substitution is all you need!
Example Evaluations
Choose a reducible expression and substitute the argument into the function
body. A reducible expression is also called a redex. Make sure to pair the
correct lambda with each argument. Add the parenthesis back in if you‘re not
sure.

(λx.xy) ((λz.z)u) (λx. λy.yxx) a b c

→ (λx.xy)u → (λy.yaa) b c
→ uy →baac

When the expression can be reduced no further it is in normal form.

Syntactic Conventions
Function abstraction associates to the right:
λx. λy. λz. x y z ≡ λx.( λy.( λz. x y z))
Function application associates to the left:
f g h x ≡ (( f g) h) x
Sequences of ls may be collapsed:
λx. λy. λz. e ≡ λx y z. e
Application has precendence over abstraction:
λx. e1 e2 ≡ λx. (e1 e2)

Evaluation (b-reduction)
(λx. e1) e2 → e1[e2/x]
where x is the formal parameter, e1 is the function body, e2 is the function
argument, and e1[e2/x] means: ―e1 with e2 substituted for x‖

Confluence: Each expression has at most one normal form. Reduction order
does not matter. The lambda calculus is confluent

89
 (λx.xy) ((λz.z) u) (λx.xy) ((λz.z) u)
→ (λx.xy) u → ((λz.z) u) y
→ uy → uy

Free, Bound and Binding Variables: In the expression (λx. xy), the variable y
is free because there is no enclosing λy, the first x is the binding occurrence, the
second x is a bound occurrence, an expression with no free variables is closed.
A function to compute the free variables in an expression:
fv(x) = {x}
fv(λx.e) = fv(e) − {x}
fv(e1 e2) = fv(e1) U fv(e2)
α-conversion: A function‘s behaviour should be independent of the name of its
bound variable. Renaming the bound variable is called a-conversion. The
identity function always returns its argument:
(λx.x) u → u
Renaming the bound variable yields the same result:
(λy.y) u → u
A bound variable belongs to the inner-most binding occurrence: We can safely
a-convert: λx. λx. x to λx. λy.y e.g: (λx. λy.y) u → (λy.y) but not λy. λx. y eg:
(λy. λx. y) u → (λx. u).

Evaluation order: The choice of evaluation order affects which expressions

diverge. Call-by-name: Substitute arguments directly into function bodies. If an
argument is not used in the function body it is never evaluated.
(λy. a) ((λx. x x) (λx. x x))
→a
Call-by-value: Evaluate arguments to normal form before substituting into
function bodies. If an argument diverges, so will the whole expression.
(λy. a) ((λx.x x) (λx.x x))

90
 → (λy. a) ((λx.x x) (lx.x x))
→ (λy. a) ((λx.x x) (λx.x x))
Expression Trees: Figure 2.2.1 demonstrates how expression trees are
represented in Lambda calculus

Figure 2.2.2: Expression Trees

2.2. Probabilistic Proof

Recently, the traditional predicate transformer approach has been extended to
include probabilistic choice. The probabilistic imperative language is
summarized below.

Program ::= abort

| skip
| x: = E (Assignment)
| seg; seg (Sequence)
| if B then seg1 else seg2 fi (Choice)
| seg1 ⊓ seg2 (Non-deterministic choice)
| seg2 (Probabilistic choice)
| (𝜇 X.C) (Recursion)

91
Probabilistic choice between three or more choices can be expressed as a nested
binary choice:

( )

or with this shorthand: @ , @ , ...

Traditional predicates may be viewed as functions from program states to {0; 1}
(or {false; true} if you prefer). To deal with probabilistic choice, we generalise
the predicates as functions from states to .
in a traditional predicate:
wp. (n: = 1 ⊓ n := 2).(n = 2) ≡ false
In our generalised predicates:
wp. (n: = n := 2).(n = 2) ≡

The weakest precondition semantics for our probabilistic language:

wp.abort.Q ≡ ∅
wp.skip.Q ≡ Q
wp.(x := E):Q ≡ Q[x := E]
wp.(seg1; seg2).Q ≡ wp.seg1.(wp.seg2.Q)
wp.(if B then seg1 else seg2 fi).Q ≡ (B * wp.seg1. Q) + (¬B * wp.seg2.Q)
wp.(seg1 ⊓ seg2).Q ≡ wp.seg1.Q ⊓ wp.seg2.Q
wp.(seg seg2).Q ≡ P * wp.seg1.Q + (1 P) . wp.seg2.Q
... and so on ...

2.3. Example
The principal use of the Monty Hall problem is to demonstrate how angry
people get when they do not agree with the answer (!)

92
Statement of the problem:
i. You are a contestant in a TV show asked to select one of three curtains -
we refer to your curtain as cc - the contestant curtain.
ii. Behind one of the curtains is a prize - we refer to this curtain as pc - the
prize curtain.
iii. The announcer for the show knows where the prize is located, and opens
one of the other two curtains, showing you that the prize is not behind it.
We refer to this curtain as ac – the announcer curtain.
iv. You are then asked if you want to change your mind - you can either stick
to your original curtain, or change to the other curtain. Which one (1)
should you do?

A program model of Monty Hall:

If we are to win the Monty Hall game, the desired post condition is [pc = cc],
and we just follow the same sort of argument as given before.
We work backwards through the program establishing the wp for line 4, then
line 3 and so on:

93
The initial non-deterministic choice of line 1 leaves this wp unchanged, so we
can say that the weakest precondition for the program segment is .

3.0 Tutor Marked Assignments (Individual or Group)

Translate the following Haskell expressions and functions into λ-calculus
notation:
a. sin (x+3)
b. (length y) + z
c. power a n = times (n-1) (\x -> a*x) 1

4.0 Conclusion/Summary
In this session, you have studied λ-calculus and as I noted that it is of the set of
terms and equations between the terms. Both these concepts (terms and
94
equations) are defined inductively. We began by introducing the terms and
explaining the role of the symbol λ as a binding operator which performs
substitution. In addition, Probabilistic methods prove was discussed and was
used to prove the existence results in a non-constructive fashion, by showing the
chance of randomly selecting a solution is greater than zero.

5.0 Self-Assessment Questions

1. The following function has been given an uninformative name:

Answer to Self-Assessment Question

95
6.0 Additional Activities (Videos, Animations & Out of Class activities) e.g.
a. Visit YouTube add https://bit.ly/2WrDEZN , https://bit.ly/2UZgLNa . Watch the
video & summarize in 1 paragraph
b. View the animation on add/site and critique it in the discussion forum
c. Take a walk and engage any 3 students on Lambda Calculus and Probabilistic
Proof; In 2 paragraphs summarize their opinion of the discussed topic. etc.

7.0 References/Further Reading

Jonathan Bowen, Formal Specification and Documentation Using Z: A Case
Study of Approach, International Thomson Computers Press (ITCP),
1996.
Huth M. and Ryan M. Logic in Computer Science: Modelling and Reasoning
about Systems. Cambridge University Press 1999.
CliffB. Jones, Systematic Software Development Using VDM, 2 nd Edition,
Prentice Hall, 1990.

96
 Study Session 3: Hoare Logic and Weakest Precondition Calculus
Introduction
1.0 Learning Outcome
2.0 Main Content
2.1- Components of Hoare Logic Specifications
2.2- Hoare‘s Notation; Partial and Total Correctness;
2.3-Weak and Strong Conditions; Strengthening Preconditions;
2.4- Weakening Postconditions
2.5- The wp Function, Intuition;
2.6- Guaranteeing Termination and Proof of Conjunction Theorem
3.0 Tutor Marked Assignments (Individual or Group Assignments)
4.0 Study Session Summary and Conclusion
5.0 Self-Assessment Questions and Answer
6.0 Additional Activities (Videos, Animations & Out of Class Activities)
7.0 References/Further Reading

Introduction:
In session three (3) of module one, I brought to you some forms of logic namely
predicate and propositional logic. Also, in session two (2) of module two, you saw
another form of logic named the lambda calculus. In this section, you shall be
exposed to the notion of Hoare logic and its relevance over the previous forms of
logic studied. In addition, I shall show you the weakest precondition calculus in
this session.
Now, what is verification? Verification involves checking that the system matches
its specification that is, building the system right. Validation is checking that the
specification reflects intentions that are building the right system. Reliability is
sometimes important, and in fact sometimes very important. This relevance is
easily seen in chemical plants, aircraft controls, pacemakers, railway networks,
and so many other sectors. High reliability requires rigorous verification. When

97
doing verification, the following get verified: Hardware, compilers, application
programs, and specifications. So therefore, we will need to carry out systematic
testing, structured walkthroughs, assertion testing and formal verification in order
to achieve verification. Formal program verification is about proving properties of
programs. In particular, it is about proving they meet their specifications
(requirements).
Examples:
i. If fib(n) is a function to compute the nth Fibonacci number, and k is a non-
negative integer, then fib(k +2) = fib(k +1)+fib(k).
ii. The routine avoid-melt-down should complete within 600msec.
iii. The OS process called File System never terminates.
Verification in Imperative Languages is peculiar because such languages are built
around an implicit store, and imperative programs are sequences of commands
that modify the store. To prove properties of imperative programs, we must find a
way to make the store explicit. Therefore, unlike Haskell, we cannot use the
language itself as the proof language. We therefore need a system for reasoning
about state-based programs. In doing so, we need: a way of expressing assertions
about programs and the state; rules for manipulating and proving those assertions

1.0 Study Session Learning Outcome

After studying this session, I expect you to be able to:
1. Describe Hoare logic
2. Describe weakest precondition calculus
3. List the difference between Hoare logic and weakest precondition

2.0 Main Content

2.1 - Components of Hoare Logic Specifications
There are three components of Hoare logic namely;
1. A code fragment

98
2. A precondition
3. A post-condition
The precondition is a predicate asserting something of interest about the state
before the code is executed. The postcondition is a predicate asserting
something of interest about the state after the code is executed.
Preconditions and Postconditions: Preconditions are predicates that are
deemed to hold before the execution of a code fragment. Postconditions are
predicates that are deemed to hold after the execution of a code fragment. For
example, If (x > 2) before y := x*(x+1) is executed, then (y +x > 8) is true
afterwards. So (x > 2) is a precondition, and (y +x > 8) is a postcondition.

2.2- Hoare’s Notation; Partial and Total Correctness;

The Hoare triple is made of {P} A {Q}. This triple means: If P is true in the
initial state and A terminates then Q will hold in the final state. Let's consider
the following examples:
1. {x = 2} x := x+1 {x = 3}
2. {x = a} x := x+1 {x = a +1}
3. {x > 2} y := x*(x+1) {y > 8}
Hoare logic expresses partial correctness in a very elegant way. We say a
program is partially correct if it gives the right answer whenever it terminates.
This implies that such system never gives a wrong answer, but it may give no
answer at all.
Note that,
{P} A {Q} does NOT imply that A terminates, even if P holds initially.
Let's look at this example for further understanding: The triple
{x = 1} while x=1 do y:=2 {x = 3}
is true in Hoare logic. Again consider the following example:
{n >= 0}
fib := 1;

99
 while (n >0)
fib := fib * n;
n := n -1;
{fib = n!}

Now imagine that n < 0, what will the code snippet above result into?
Remember design by contract? We are only guaranteeing the postcondition if
the precondition is satisfied. So, we must understand that partial correctness is
alright and acceptable. For instance, why not insist on termination? The reasons
are: we may not want termination; it simplifies the logic; and if necessary, we
can prove termination separately.
Initial Value Convention
In the following Hoare triple, we shall see that the loop does not terminate
because the initial value always results to true. By the way, note that the triple is
true even though the loop will not terminate for some initial (xα;yα) pairs.
{True}
while (x<>y)
if (x>y) x := x-y
else y := y-x
{x = gcd(xα;yα)}

xα and yα indicate the initial values of x and y.

Subscripting a variable with α indicates the value it had in the precondition.

2.3-Weak and Strong Conditions; Strengthening Preconditions;

The condition (x > 0) says less about a state than the condition (x = 5). It is the
weaker condition. But the statement
{x > 0} x := x+1 {x > 1}
says more about the code than:

100
 {x = 5} x := x+1 {x > 1}
If a precondition P1 is weaker than P2, then {P1}A{Q} is stronger than
{P2}A{Q}. Usually we are interested in strong postconditions and weak
preconditions, because they say more about the code.

A condition P is stronger than Q in the cases where P => Q. Similarly Q is

weaker than P. For example:
(x = 6) => (x > 0) so (x = 6) is stronger than (x > 0)
In addition, the statement:
{x = 5} x := x+1 {x = 6}
says more about the code than:
{x = 5} x := x+1 {x > 0}
If a postcondition Q1 is stronger than Q2, then {P}A{Q1} is a stronger
statement than {P}A{Q2}

Proof rule for Strengthening Preconditions

It is safe to make a precondition more specific (stronger). The rule for doing
that is
{Pw} S {Q} Ps => Pw
{Ps} S {Q}
To exemplify this, let's take this as an instance:
{x > 2} x := x+1 {x > 3} (x = 4) => (x > 2)
{x = 4} x := x+1 {x > 3}

2.4- Weakening Postconditions

101
 Fig 2.3.1: Weakening Postconditions

Proof rule for Weakening Postconditions

It is safe to weaken a postcondition so it says less. The rule for doing such is
given as:
{P} S {Qs} Qs => Qw
{P} S {Qw}

To exemplify this, let's take this as an instance:

{x > 2} x := x+1 {x > 3} (x > 3) => (x > 1)
{x > 2} x := x+1 {x > 1}
Example
Consider the statement x:=y+3 and suppose the desired postcondition is (x > 3).
Then:
{y +3 > 3} x:=y+3 {x > 3}
is an instance of the assignment axiom, so an appropriate precondition is (y >
0). That is:
{y > 0} x:=y+3 {x > 3}
Notice how we worked backwards from postcondition to precondition. This is
the usual practice in Hoare Logic.

The Assignment Axiom

Assignments change the state so we expect Hoare triples for assignments
always to reflect that change. Suppose Q(x) is a formula involving a variable x,

102
and that Q(e) indicates the same formula with all occurrences of x replaced by
the expression e. The assignment axiom of Hoare Logic is of the form:
{Q(e)} x := e {Q(x)}
If we want x to have some property Q after the assignment, then that property
must hold for the value (e) being assigned to x before the assignment is
executed.
Let's consider another example. The following is an instance of the assignment
axiom:
{(x +1) > 5} x := x+1 {x > 5}
So (x > 4) is sufficient to guarantee (x > 5) after x:=x+1.
Again consider this other example: Take the assignment
x:=x+b+1
Suppose the desired postcondition (the Q(x ) of the rule) is:
(b = 2) ˄ (x = y +b)
Then substituting (x +b +1) for x gives a precondition:
(b = 2) ˄ (x +b +1 = y +b)
Therefore, the postcondition simplifies to (b = 2) ˄ (y = x - 2) and the
precondition simplifies to (b = 2) ˄ (y = x +1). The assignment axiom of Hoare
Logic is:
{Q(e)} x := e {Q(x)}
The reason for this is explained below:
i. Let v be the value assigned — i.e. v is the value of expression e in the
initial state.
ii. If Q(e) is true initially, then so is Q(v).
iii. Since the variable x has value v after the assignment (and nothing else is
changed in the state), Q(x ) must be true after that assignment.

So, the variable b is not changed by the assignment, so if we require (b = 2)

after it is executed, then b must already be 2 before it is executed. Intuitively

103
therefore, the effect of the assignment is to increase the value of x by 3. Now
variable y is not changed by the assignment, so if we require (y = x - 2) after it
is executed, then y must already be 3 more than the initial value of x - 2. That
is, y = x - 2 + 3.

We need to note that the assignment axiom is optimal. Now consider the Hoare
triple in the assignment axiom is as strong as possible.
{Q(e)} x := e {Q(x )}
That is, Q(e) is the weakest precondition which guarantees the postcondition.
This is based on the following argument.
i. Again, let v be the value assigned.
ii. If Q(e) is false initially, then so is Q(v).
iii. Since the variable x has value v after the assignment (and only the value
of x is changed), Q(x) cannot hold after that assignment.
iv. So Q(e) is too weak a precondition to guarantee postcondition Q(x).

Proof rule for Sequencing

Imperative programs consist of a sequence of statements, affecting the store
one after the other.
{P} S1 {Q} {Q} S2 {R}
{P} S1; S2 {R}
Consider the example below:
{x > 2} x:= x+1 {x > 3} {x > 3} x:= x+2 {x > 5}
{x > 2} x := x+1; x := x+2 {x > 5}
Using the assignment axiom, we can establish the weakest Q:
{x*x >= 16} x := x * x {x >= 16}
so we have:
{P} x := x+1 {x * x >= 16} {x * x >= 16} x:= x * x {x >= 16}
{P} x := x+1; x := x * x {x >= 16}

104
Notice how we are working backwards through the code. This is the standard
approach.
Proof Rule for Conditionals
Let's consider the rule below:
{P ˄ b} S1 {Q} {P ˄ ¬b} S2 {Q}
{P} if b then S1 else S2 {Q}
When a conditional is executed, either S1 or S2 is executed. Therefore, if the
conditional is to establish Q, both S1 and S2 must establish Q. Similarly, if the
precondition for the conditional is P, then it must also be a precondition for the
two branches S1 and S2. The choice between S1 and S2 depends on evaluating b
in the initial state, so we can also assume b to be a precondition for S1 and ¬b
to be a precondition for S2.

A Simpler Proof Rule for Conditionals

Consider this rule:
{P} S1 {Q} {P} S2 {Q}
{P} if b then S1 else S2 {Q}

It looks simpler, but it isn‘t the standard rule because subgoals may not be true,
even if the conclusion is true. That is, the precondition P may be too weak to
establish Q as a postcondition of S1 and S2.
Example of Conditional Rule: Suppose we wish to prove:
{x > 2} if x>2 then y:=1 else y:=-1 {y > 0}
The proof rule for conditionals suggests we prove:
{x > 2 ˄ x > 2} y:=1 {y > 0}
{x > 2 ˄ ¬ (x > 2)} y:=-1 {y > 0}
Simplifying:
{x > 2} y:=1 {y > 0} (1)
{False} y:=-1 {y > 0} (2)

105
Proof Rule for While Loops
Consider the rule below:
{P ˄ b} S {P}
{P} while b do S {P ˄ ¬b}
P is called the loop invariant. P remains true each time around the loop (but not
necessarily during execution of the loop body. If the loop terminates the control
condition must be false, so ¬b appears in the postcondition. In the premise of
the rule, the body of the loop S is only executed if b is true, so it appears in the
precondition

Suppose we want to find a precondition P such that:

{P} while (n>0) do n:=n-1 {n = 0}
We need to find the loop invariant P. From the conclusion of the while rule, we
can deduce:
P ˄ ¬ (n > 0) ≡ (n = 0)
So this looks a reasonable loop invariant:
P ≡ (n >= 0)
The premise becomes:
{(n >= 0) ˄ (n > 0)} n := n-1 {(n >= 0)}
Which follows from the assignment axiom.
Let‘s prove the program below:
{True}
i:=0;
s:=0;
while (i ≠ n) do
i:=i+1;
s:=s+(2*i-1)
{s = n2}

106
2.5- The wp Function, Intuition;
Dijkstra‘s Weakest Precondition Calculus is a variant on Hoare Logic. Hoare
Logic is a relational calculus:
i. For each Q, there are many P such that {P} S {Q}
ii. For each P, there are many Q such that {P} S {Q} WP is a functional
calculus:
iii. For each Q there is exactly one P which is the weakest precondition for S
and Q.

The wp Function: If Q is a predicate on states and S is a code fragment, then the

weakest precondition for S with respect to Q is a predicate that is true for
precisely those initial states from which:
i. S must terminate, and
ii. executing S must produce a state satisfying Q.

That is, the weakest precondition P is a function of S and Q:

P = wp(S,Q)
wp is sometimes called a predicate transformer, but it‘s just a higher-order
function:
wp :: Code x (State → Bool) → (State → Bool)

Example
Consider code x:=x+1 and postcondition (x > 0)
One valid precondition is (x > 0), so in Hoare Logic the following is true:
{x > 0} x:=x+1 {x > 0}
Another valid precondition is (x > -1), so:
{x > -1} x:=x+1 {x > 0}
(x > -1) is weaker than (x > 0) (because (x > 0) => (x > -1))
In fact, (x > -1) is the weakest precondition:
wp(x:=x+1; x > 0) = (x > -1)

107
Weakest Precondition of Assignment
We should not be surprised that the Assignment axiom of Hoare Logic is
designed to give the ―best‖ — i.e. the weakest precondition:
{Q(e)} x:=e {Q(x)}
Therefore we should expect that the rule for Assignment in the weakest
precondition calculus corresponds closely:
wp(x:=e, Q(x )) ≡ Q(e)

Assignment wp Examples
wp(x:=y+3; (x > 3)) ≡ y +3 > 3 (substitute y +3 for x )
≡y>0 (simplify)

Weakest Preconditions for Sequences

As in Hoare Logic, we expect the rule for sequencing to compose the effect of
the consecutive statements. The rule is:
wp(S1; S2, Q) ≡ wp(S1, wp(S2, Q))
Example:
wp(x:=x+2; y:=y-2, (x +y = 0))
≡ wp(x:=x+2; wp(y:=y-2; (x +y = 0)))
≡ wp(x:=x+2; (x +(y -2) = 0))
≡ ((x +2)+y -2 = 0)
≡ (x +y = 0)

Weakest Preconditions for Conditionals

If the condition b is true, wp for the conditional is the weakest precondition for
S1. If the condition b is false, wp for the conditional is the weakest precondition
for S2. The value of b depends on the initial state so we include it in the
precondition, giving the following rule:
wp(if b then S1 else S2, Q) ≡ (b => (wp(S1)) ˄ (¬b => wp(S2,Q))

108
Example:
wp(if x>2 then y:=1 else y:=-1, (y > 0))
≡ ((x > 2) => wp(y:=1, (y > 0)) ^ (-(x > 2) => wp(y:=-1; (y > 0))
≡ ((x > 2) => (1 > 0)) ^ (-(x > 2) => (-1 > 0))
≡ ((x > 2) => T) ^ ((x <= 2) => F)
≡x>2
Loops
Suppose we have a while loop and some postcondition Q. The precondition P
we seek is the weakest that:
i. establishes Q
ii. guarantees termination
We can take hints for the first requirement from the corresponding rule for
Hoare Logic. That is, think in terms of loop invariants.

2.6- Guaranteeing Termination and Proof of Conjunction Theorem

If a loop is not entered, then the postcondition must already be true and the
control expression false. We‘ll call that precondition P0.
P0 ≡ wp(while b do S,Q) ≡ ¬b ˄ Q
Now suppose the loop executes exactly once. In that case:
i. b must be true initially;
ii. after the first time through the loop, P0 must become true (so that the loop
terminates next time through):
P1 ≡ b ˄ wp(S, P0)

Similarly,
P2 ≡ b ˄ wp(S,P1)
P3 ≡ b ˄ wp(S,P2)
This is an inductive definition:
P0 ≡ ¬b ˄ Q

109
 Pk+1 ≡ b ˄ wp(S,Pk)

If any of the Pk is true in the initial state, then we are guaranteed that the loop
will terminate and establish the postcondition Q.

In-text Question:
1. For each of the following, show if the specified precondition is valid
a. { } { }
b.{ } { }
{ } { }

Answer
a) {a>1} i=b+1;k=a+2 {k>-1}

= i=b+1{a+2>-1}
={a>-3} i=b+1; k=a+2 {k>-1}
Since =a>1 →a>-3, thus {a>1} is a valid stronger precondition.
{a>1} is a valid preconditions.

b) {true} z=x+1;p=y-1 {x×y>0}

The assignment does not change the value of x and y.

Thus {x×y>0} z=x+1;p=y-1 {x×y>0}
Since true is weaker than x×y>0, TRUE is not a valid precondition

3.0 Tutor Marked Assignment (Individual or Group)

Let C be the program fragment

while ( x>0){
x=x-1
110
 }
y=x+3;
Find the wp(C, )

4.0 Conclusion/Summary
Welcome to the end of this session which is also the end of this second module.
In this session, we have studied Hoare logic and weakest precondition.
Specifically, you the learner have been exposed to the components of Hoare
Logic Specifications; Hoare‘s Notation; Partial and Total Correctness; Weak
and Strong Conditions; Strengthening Preconditions; Weakening
Postconditions; the wp Function, Intuition; Weakest Precondition of
Assignment; Weakest Preconditions for Sequences; Weakest Preconditions for
Conditionals; Loops; Guaranteeing Termination and Proof of Conjunction
Theorem.

5.0 Self-Assessment Questions

1. Find the set of states for which the execution of the program fragment
below terminates
While ( x!=2){
x=x-1
}
2. Prove that, there is no initial state for which, the program fragment below
will terminate and its output satisfying the property n= -100
While( n!=0){
n=n-1
}

Answer to Self-Assessment Questions

1. Since we are only interested on termination, the postcondition is any

111
value therefore, the postcondition=true
Let pk be that precondition which assures termination after k iterations.
P0= ⋀ that is P0 ( (x! 2) ⋀ )) = x=2
P1= ⋀
=( x!=2) ⋀ x=x-1, x=2)
=(x!=2) ⋀ )=x=3
P2= ⋀
=( x!=2) ⋀ x=x-1, x=3)
=( x!=2) ⋀ )=x=4
By induction, Pk= x=k+4 for all k>0
so, wp(W, true )=k.(k )⋀
=(x=2) ∨ (x=3) ∨ ∨......
=x 2
The program terminates when starting with the input of x 2

2.
The postcondition is n=-100
Let pk be that precondition which assures termination after k iterations.
P0= ⋀ that is P0 ( (n! 0) ⋀ )) = false
P1= ⋀
=( n!=0) ⋀ n=n-1, false)
=( n!=0) ⋀false= false
P2= ⋀
=( n!=0) ⋀ n=n-1, false)
=( n!=0) ⋀false= false
By induction, Pk false for all k>0

112
 So, wp =k.(k )⋀
=false ∨ false ∨ ∨... false
=false
Thus, there is no initial condition for which the program terminates and
satisfy n= -100

6.0 Additional Activities (Videos, Animations & Out of Class activities)

a. Visit YouTube add https://bit.ly/2TYKN7f? , https://bit.ly/2OwZc4p . Watch the
video & summarize in 1 paragraph
b. View the animation on add/site and critique it in the discussion forum
c. Take a walk and engage any 3 students on Hoare logic and weakest
precondition; In 2 paragraphs summarize their opinion of the discussed topic.
etc.

7.0 References/Further Reading

Jonathan Bowen, Formal Specification and Documentation Using Z: A Case
Study of Approach, International Thomson Computers Press (ITCP),
1996.
Huth M. and Ryan M. Logic in Computer Science: Modelling and Reasoning
about Systems. Cambridge University Press 1999.
CliffB. Jones, Systematic Software Development Using VDM, 2nd Edition,
Prentice Hall, 1990.

113
 MODULE 3
Study Session 1: Turing Machines and Church Thesis
Study Session 2: Finite State Automata
Study Session 3: Refinement

Study Session 1: Turing Machines and Church Thesis

Introduction
1.0 Learning Outcome
2.0 Main Content
2.1- What is a Turing Machines?
2.2- Church Turing Thesis
3.0 Tutor Marked Assignments (Individual or Group Assignments)
4.0 Study Session Summary and Conclusion
5.0 Self-Assessment Questions and Answer
6.0 Additional Activities (Videos, Animations & Out of Class Activities)
7.0 References/Further Reading

Introduction:
You have now gone half-way in the study of this course, for you have
completed two modules and you have only two modules left. However, I do
hope you are understanding and knowing how to embark on using formal
methods to check the correctness of software? So, welcome to the first session
of module three (3) where we shall be considering another important topic
called Turing machine and Church Thesis. Why do you need to understand how
the Turing machine works? And what is the relevance of this (Church) Thesis in
formalism for reasoning about the correctness of software? All these I shall seek
to dwell on in this session.
A Turing Machine is an accepting device which accepts the languages
(recursively enumerable set) generated by type 0 grammars. It was invented in
114
1936 by Alan Turing. The Church–Turing thesis, is a hypothesis about the
nature of computable functions, and is also known as computability thesis, the
Turing–Church thesis, the Church–Turing conjecture, Church's thesis, Church's
conjecture, and Turing's thesis. The notion of algorithm, computation, a step-
by-step procedure or a defined method to perform calculations has been used
informally and intuitively in mathematics for centuries. However, attempts to
formalize the concept only begun in the beginning of the 20th century. Three
major attempts were made: λ-calculus, recursive functions and Turing
Machines. These three formal concepts were proved to be equivalent; all three
define the same class of functions. Hence, Church-Turing thesis also states that
λ-calculus and recursive functions also correspond to the concept of
computability. Since the thesis aims to capture an intuitive concept, namely the
notion of computation, it cannot be formally proven. However, it has gain
widely acceptance in the mathematical and philosophical community.

1.0 Study Session Learning Outcome

After studying this session, I expect you to be able to:
1. Describe how to use informal methods when working in Computability
Theory
2. Explain the equivalence between the mathematical concepts of algorithm or
computation and Turing-Machine
3. Define a Turing machine.
4. List types of Turing machines are there.

2.0 Main Content

2.1. What is a Turing Machines?
A Turing Machine (TM) is a mathematical model which consists of an infinite
length tape divided into cells on which input is given. It consists of a head
which reads the input tape. A state register stores the state of the Turing

115
machine. After reading an input symbol, it is replaced with another symbol, its
internal state is changed, and it moves from one cell to the right or left. If the
TM reaches the final state, the input string is accepted, otherwise rejected. The
concept of Turing machines is one of the founding principles of modern
computing. Although somewhat complicated for first time learners, Turing
machines (along with several other models) are vital for representing the
underlying logic behind all computers. This lesson will give a brief overview of
the subject. The illustration below represents a simple Turing machine.

Fig 3.1.1: What is a Turing Machines?

Turing machines are theoretical constructs, first described and then expanded
upon by their namesake Alan Turing. These machines can be represented
through diagrams and formulas but due to physical limitations can never be
built. Various forms of Turing machines have been adapted to analyse
complexity among other things. Turing machines are types of finite state
machines. Determinism and Non-Determinism are vital concepts for
understanding the functioning of Turing Machines. For a more thorough
understanding, students should consult information about Automata Theory.
When a Turing machine begins running, it is in its start state and its tape head is
positioned over one of the cells on the tape; the symbol on this cell is the current
symbol.
The operation of a Turing machine proceeds as follows:
1. The Turing machine reads the tape symbol that is under the Turing
machine's tape head. This symbol is referred to as the current symbol.
2. The Turing machine uses its transition function to map the current state
and current symbol to the following: the next state, the next symbol and
the movement for the tape head. If the transition function is not defined
for the current state and current symbol, then the Turing machine crashes.
116
 3. The Turing machine changes its state to the next state, which was
returned by the transition function.
4. The Turing machine overwrites the current symbol on the tape with the
next symbol, which was returned by the transition function.
5. The Turing machine moves its tape head one symbol to the left or to the
right, or does not move the tape head, depending on the value of the
'movement' that is returned by the transition function.
6. If the Turing machine's state is a halt state, then the Turing machine halts.
Otherwise, repeat sub-step #1.
A Turing machine can be formally described as a 7-tuple (Q, X, ∑, δ, q0, B, F)
where −
i. Q is a finite set of states
ii. X is the tape alphabet
iii. ∑ is the input alphabet
iv. δ is a transition function; δ : Q × X → Q × X × {Left_shift, Right_shift}.
v. q0 is the initial state
vi. B is the blank symbol
vii. F is the set of final states
Notation for the TM: This notation for a Turing machine is demonstrated in
Figure 3.1.2 and listed below.

Figure 3.1.2: Demonstration of notation for TM

Finite control: can be in any of a finite set of states

117
Tape: divided into cells; each cell can hold one of a finite number of symbols.
Initially the input (a finite-length string) is placed on the tape. All other tape
cells initially hold a special symbol: blank. Blank is tape symbol (not an input
symbol). Tape head: always positioned at one of the tape cell. Initially, the tape
head is at the leftmost cell that holds the input.
Deterministic Turing Machine
Automata are often used to represent Turing machines. This is a deterministic
Turing machine which calculates the two's complement of some binary input. A
deterministic Turing machine is one that uses the concept of determinism to
calculate a solution to a problem. Determinism is the concept of being only in
one state at a given time and determining what the next state will be from that
state. In simpler terms, determinism would be being in state, and only holding
that state until moving onto the next state, In determinism we would be able to
predict without any doubt that the head would move from state to state. A
Turing machine does not have to even halt, or stop execution, in order for it to
be considered deterministic.

Non-deterministic Turing Machine

A non-deterministic Turing machine is one that uses the concept of non-
determinism to calculate a solution to a problem. A non-deterministic Turing
Machine differs from a deterministic Turing Machine in the sense that a non-
deterministic Turing Machine can have several possible states to which it can
transition from any given state. One way to think of it would be to think that,
given the possibility of choosing from several subsequent states, the non-
deterministic Turing machine guesses the next iteration that will bring it to a
‗yes‘ answer. Put a different way, the non-deterministic Turing machine
branches out into holding many states at the same time in a sort of tree fashion
until one of the many paths leads it to a ‗yes‘ answer. In perspective a non-

118
deterministic Turing machine may, for instance, be in state and then hold both
state as one of the branches and state as another branch.
For example, consider the Turing machine M = (Q, X, ∑, δ, q 0, B, F) with Q =
{q0, q1, q2, qf}, X = {x, y}, ∑ = {1}, q0 = {q0}, B = blank symbol, and F = {qf }.
Solution: δ is given by −
Tape alphabet Present State Present State Present State
symbol ‘q0’ ‘q1’ ‘q2’
X 1Rq1 1Lq0 1Lqf

Y 1Lq2 1Rq1 1Rqf

Here the transition 1Rq1 implies that the write symbol is 1, the tape moves right,
and the next state is q1. Similarly, the transition 1Lq2 implies that the write
symbol is 1, the tape moves left, and the next state is q 2.
Another example of Turing machine: As a trivial example to demonstrate
these operations, let's try printing the symbols "1 1 0" on an initially blank tape:

First, we write a 1 on the square under the head:

Next, we move the tape left by one square:

Now, write a 1 on the new square under the head:

We then move the tape left by one square again:

119
Finally, write a 0 and that's it!

Now, with the symbols "1 1 0" printed on the tape, let's attempt to convert the
1s to 0s and vice versa. This is called bit inversion, since 1s and 0s are bits in
binary. This can be done by passing the following instructions to the Turing
machine, utilizing the machine's reading capabilities to decide its subsequent
operations on its own. These instructions make up a simple program.
Symbol read Write instruction Move instruction
Blank None None
0 Write 1 Move tape to the right
1 Write 0 Move tape to the right
The machine will first read the symbol under the head, write a new symbol
accordingly, then move the tape left or right as instructed, before repeating the
read-write-move sequence again. Let's see what this program does to our tape
from the previous end point of the instructions:

The current symbol under the head is 0, so we write a 1 and move the tape right
by one square.

120
The symbol being read is now 1, so we write a 0 and move the tape right by one
square:

Similarly, the symbol read is a 1, so we repeat the same instructions.

Finally, a 'blank' symbol is read, so the machine does nothing apart from read
the blank symbol continuously since we have instructed it to repeat the read-
write-move sequence without stopping.
It's fairly easy to create a Turing machine that converts a string on the tape from
lower case to upper case. However, for many simple tasks that can be
performed with a few lines of Java or C, it's difficult and tedious to create
Turing machines that perform these tasks.
Finite Automata
All texts and classes on the Theory of Computation start out with something
called ―Finite Automata.‖ The basic idea behind them is pretty easy. You just
imagine a simple ‗machine‘ that is able to make choices and move between
states. Figure 3.1.2 is an example of a very simple one that represents the
―logic‖ of a coin-operated turnstile. In plain English, this says that if you try to
push through a turnstile that is locked, you can‘t if you haven‘t first put in a
coin. If you have put in a coin but haven‘t pushed through yet, it will accept no
more coins.
If you have put in a coin, then

121
you can push through. It then locks again for the next person. It was probably
easier to understand from the diagram than from the description. Finite
Automata are capable of performing far more complicated logic than this.
But this should give you a basic feel for how a finite automata works.

Figure 3.1.3: Demonstration of notation for TM

Context-free languages and pushdown automata: The strings in a context-

free language can be generated by a context-free grammar. We also discussed
the problem of parsing: given an input string and a context-free grammar, find
derivations (sequence of productions) that derive the input string from the
grammar's start symbol. Parsing is thus a problem of recognizing whether or
not an input string is a member of the language defined by a grammar. Various
parsing algorithms exist to solve this problem. You might wonder whether or
not there is a kind of automaton that can serve as a recognizer for context-free
languages. Pushdown automata (PDAs) are a class of automaton that are
powerful enough to serve as recognizers for context-free languages. Pushdown
automata are similar to finite automata: they consist of states and
transitions. However, an infinitely long "tape" is added to the automaton. The
tape can serve as storage for data that the automaton needs to remember. In any
state, the automaton chooses to do one of three things:
1. Read a symbol from the input string
2. Push a symbol on the tape
3. Pop a symbol from the tape

122
Symbols are written to and read from the tape in last-in, first-out order. In other
words, the symbol popped from the tape by the automaton will be the one most
recently pushed. This is exactly equivalent to a stack data structure. Let's
describe a PDA that recognizes the language: anbn (All strings of the form n a's
followed by n b's, for n >= 0). Note that the PDA a special symbol Δ, which is
not part of the language's alphabet, is used in two ways
1. It is pushed onto the tape as the automaton's first action
2. It is appended to the input string, meaning that it will be the last symbol
read from the input string

2.2- Church Turing Thesis

The Church-Turing thesis (formerly commonly known simply as Church's
thesis) says that any real-world computation can be translated into an equivalent
computation involving a Turing machine. In Church's original formulation
(Church 1935, 1936), the thesis says that real-world calculation can be done
using the lambda calculus, which is equivalent to using general recursive
functions. The Church-Turing thesis encompasses more kinds of computations
than those originally envisioned, such as those involving cellular automata,
combinators, register machines, and substitution systems. It also applies to other
kinds of computations found in theoretical computer science such as quantum
computing and probabilistic computing.
The Church-Turing thesis concerns the concept of an effective or systematic or
mechanical method in logic, mathematics and computer science. ‗Effective‘ and
its synonyms ‗systematic‘ and ‗mechanical‘ are terms of art in these disciplines:
they do not carry their everyday meaning. A method, or procedure, M, for
achieving some desired result is called ‗effective‘ (or ‗systematic‘ or
‗mechanical‘) just in case:
i. M is set out in terms of a finite number of exact instructions (each
instruction being expressed by means of a finite number of symbols);

123
 ii. M will, if carried out without error, produce the desired result in a finite
number of steps;
iii. M can (in practice or in principle) be carried out by a human being
unaided by any machinery except paper and pencil;
iv. M demands no insight, intuition, or ingenuity, on the part of the human
being carrying out the method.
A well-known example of an effective method is the truth table test for
tautology. In principle, a human being who works by rote could apply this test
successfully to any formula of the propositional calculus—given sufficient time,
tenacity, paper, and pencils (although the test is unworkable in practice for any
formula containing more than a few propositional variables).
Formulations of Turing’s thesis in terms of numbers
Computable numbers are (real) numbers whose decimal representation can be
generated progressively, digit by digit, by a Turing machine. Examples are:
i. any number whose decimal representation consists of a finite number of
digits (e.g., 109, 1.142)
ii. all rational numbers, such as one-third, two-sevenths, etc.
iii. some irrational real numbers, such as π and e.
As well as formulations of Turing‘s thesis like the one given above, Turing
also formulated his thesis in terms of numbers:
i. The ―computable numbers‖ include all numbers which would naturally
be regarded as computable. (Turing 1936: 58).
ii. It is my contention that these operations [the operations of an L.C.M.]
include all those which are used in the computation of a number. (Turing
1936: 60)
In the first of these two formulations, Turing is stating that every number
which is able to be calculated by an effective method (that is, ―all numbers
which would naturally be regarded as computable‖) is included among the
numbers whose decimal representations can be written out progressively by

124
 one or another Turing machine. In the second, Turing is saying that the
operations of a Turing machine include all those that a human mathematician
needs to use when calculating a number by means of an effective method.
The meaning of ‘computable’ and ‘computation’ in Turing’s thesis
Turing introduced his machines with the intention of providing an idealized
description of a certain human activity, the tedious one of numerical
computation. Until the advent of automatic computing machines, this was the
occupation of many thousands of people in business, government, and research
establishments. These human rote-workers were in fact called computers.
Human computers used effective methods to carry out some aspects of the work
nowadays done by electronic computers. The Church-Turing thesis is about
computation as this term was used in 1936, viz. human computation. For
instance, when Turing says that the operations of an L.C.M. include all those
needed ―in the computation of a number‖, he means ―in the computation of a
number by a human being‖, since that is what computation was in those days.
Similarly ―numbers which would naturally be regarded as computable‖ are
numbers which would be regarded as computable by a human computer, a
human being who is working solely in accordance with an effective method.
Church’s thesis
A function of positive integers is effectively calculable only if lambda-definable
(or, equivalently, recursive). The reverse implication, that every lambda-
definable function of positive integers is effectively calculable, is commonly
referred to as the converse of Church’s thesis, although Church himself did not
so distinguish (bundling both theses together in his ‗definition‘). If attention is
restricted to functions of positive integers, Church‘s thesis and Turing‘s thesis
are extensionally equivalent. ‗Extensionally equivalent‘ means that the two
theses are about one and the same class of functions: in view of the previously
mentioned results by Church, Kleene and Turing, the class of lambda-definable
functions (of positive integers) is identical to the class of recursive functions (of

125
positive integers) and to the class of computable functions (of positive integers).
Notice, though, that while the two theses are equivalent in this sense, they
nevertheless have distinct meanings and so are two different theses. One
important difference between the two is that Turing‘s thesis concerns computing
machines, whereas Church‘s does not.

Let us consider the matter of computation, which is the ability to transform

some input information into some output information. We‘ll leave it as vague
as that for now, where information might be anything from a statement of the
average body-mass index of a yearling holmesina to the exact nerve signals
needed to cause a healthy glyptodon to breathe. An example computation might
be estimating the life expectancy of a minmi given a variety of fossil evidences.
For now we‘re not going to worry about any particular computation. Instead
we‘ll ask, what tools do we need to perform the computation? Is there a lan-
guage in which we can describe every task that can be performed? Is there a set
of techniques we can combine to do absolutely everything?
The Church-Turing thesis, named after Alan Turing and Alonzo Church in the
1930s, states that yes, there is such a language, a set of techniques that can
describe every computation. Turing posed the Turing Machine, Church had
(several versions of) the λ-calculus; since then we‘ve shown untold hundreds of
other such basis sets, some of them quite silly (such as the computer game
minesweeper). Such universal bases are commonly called Turing-complete.
Demonstrating that any particular set of operations is Turing-complete is often a
lengthy process, but is generally not overly difficult to follow with sufficient
patience.
The Church-Turing thesis has not and cannot be proven. The only way to know
that every computation can be expressed in some language is to know what
every computation is. But it is almost universally believed. We‘ve found myriad
ways of describing computations and all of them have been reducible to Turing

126
machines. We have no evidence that any more powerful means of describing
processes exists.
Summary of Turing Thesis: Any mechanical computation can be performed
by a Turing Machine. There is a TM-n corresponding to every computable
problem. We can model any mechanical computer with a TM. The set of
languages that can be decided by a TM is identical to the set of languages that
can be decided by any mechanical computing machine. If there is no TM that
decides problem P, there is no algorithm that solves problem P.
Church-Rosser Theorem
The Church-Rosser theorem states that lambda calculus as a reduction system
with lambda conversion rules satisfies the Church-Rosser property. In
mathematics and theoretical computer science, the Church–Rosser theorem
states that, when applying reduction rules to terms in the lambda calculus, the
ordering in which the reductions are chosen does not make a difference to the
eventual result. More precisely, if there are two distinct reductions or sequences
of reductions that can be applied to the same term, then there exists a term that
is reachable from both results, by applying (possibly empty) sequences of
additional reductions. The theorem was proved in 1936 by Alonzo Church and
J. Barkley Rosser, after whom it is named. The theorem is symbolised by the
adjacent diagram: If term a can be reduced to both b and c, then there must be a
further term d (possibly equal to either b or c) to which both b and c can be
reduced. Viewing the lambda calculus as an abstract rewriting system, the
Church–Rosser theorem states that the reduction rules of the lambda calculus
are confluent. As a consequence of the theorem, a term in the lambda calculus
has at most one normal form, justifying reference to "the normal form" of a
given normalisable term.
Lambda-calculus and Turning Thesis
The ―Church-Turing Thesis‖ is by itself is one of the most important ideas on
computer science, but the impact of Church and Turing‘s models goes far

127
beyond the thesis itself. Oddly, however, the impact of each has been in almost
completely separate communities.
Turing Machine ⇔ Algorithms and Complexity
λ-Calculus ⇔ Programming Languages

Turing Machine ⇔ Algorithms and Complexity: Well suited for measuring

resources (efficiency). Ideas or fields developed from the Turing machine:
Axiomatic complexity theory, P vs. NP, polynomial hierarchy, P-space, RAM
model and asymptotic analysis of algorithms, Cryptography (based on hardness
of computation), Learning theory (learning power of Turing machines),
Algorithmic game theory, and Hardness of approximation.

λ-Calculus ⇔ Programming Language Theory: Well suited for composition

and abstraction (structure). Ideas or fields developed from the λ-calculus: Call-
by-value, lexical scoping, recursion, lambda, higher-order-functions (just now
in C++ and Java), denotational semantics, type theory (the theory of
abstraction), implicit-memory management, polymorphism, proof-checkers:
LCF, NuPRL, Coq, Isabelle, and Languages: Lisp, FP, ML, Haskell, Scala
(Java, Python, C++).

Figure 3.1.3 illustrates the opportunities in combination of Turing machine and

Lambda Calculus

128
 Figure 3.1.5: Opportunities in combination of Turing machine and Lambda Calculus

Next 50 years need to integrate Complexity/Algorithms and Programming

Language Theory. Cost models based on languages, not machines, and are
particularly needed for parallelism. Other opportunities: Verification, type-
theory and complexity, probabilistic programming, programs-as-data,
cryptography and PL, game-theory and PL.

Natural Numbers as Church Numerals

Natural numbers are non-negative. Given a successor function, next, which adds
one, we can define the natural numbers in terms of zero and next:

1 = (next 0)
2 = (next 1)
= (next (next 0))
3 = (next 2)
= (next (next (next 0)))

and so on. Therefore a number n will be that number of successors of zero. Just
as we adopted the convention TRUE = first, and FALSE = second, we adopt the
following convention:
129
 zero = Lf.Lx.x
one = Lf.Lx.(f x)
two = Lf.Lx.(f (f x))
three = Lf.Lx.(f (f (f x)))
four = Lf.Lx.(F (f (f (f x))))

Therefore we have a "unary" representation of the natural numbers, such that n

is represented as n applications of the function f to the argument x. This
representation is referred to as
Church numerals: We can define the function next as follows:
next = Ln.Lf.Lx.(f ((n f) x))
and therefore one as follows:
one = (next zero)
=> (Ln.Lf.Lx.(f ((n f) x)) zero)
=> Lf.Lx.(f ((zero f) x))
=> Lf.Lx.(f ((Lg.Ly.y f) x)) (* alpha conversion avoids clash *)
=> Lf.Lx.(f (Ly.y x))
=> Lf.Lx.(f x)

and two as follows:

two = (next one)
=> (Ln.Lf.Lx.(f ((n f) x)) one)
=> Lf.Lx.(f ((one f) x))
=> Lf.Lx.(f ((Lg.Ly.(g y) f) x)) (* again, alpha conversion *)
=> Lf.Lx.(f (Ly.(f y) x)
=> Lf.Lx.(f (f x))

val next = fn n => fn f => fn x => (f ((n f) x));

130
Note that ((two g) y) = (g (g y)). So if we had some function, say one that
increments n:

inc = Ln.(n+1)

then we can get a feel for a Church Numeral as follows:

((two inc) 0)
=> ((Lf.Lx.(f (f x)) inc) 0)
=> (Lx.(inc (inc x) 0)
=> (inc (inc 0))
=> (Ln.(n+1) (Ln.(n+1) 0))
=> (Ln.(n+1) (0 + 1))
=> ((0 + 1) + 1)
=> 2

We are now in a position to define addition in terms of next:

add = Lm.Ln.Lf.Lx.((((m next) n) f) x);

Therefore four may be computed as follows:

four = ((add two) two)
=> ((Lm.Ln.Lf.Lx.((((m next) n) f) x) two) two)
=> (Ln.Lf.Lx.((((two next) n) f) x)
=> Lf.Lx.((((two next) two) f x)
=> Lf.Lx.((((Lg.Ly.(g (g y)) next) two) f x)
=> Lf.Lx.(((Ly.(next (next y)) two) f) x)
=> Lf.Lx.(((next (next two)) f) x)
=> Lf.Lx.(((next (Ln.Lf.Lx.(f ((n f) x)) two)) f) x)

131
Multiplication is defined as follows:
mult = Lm.Ln.Lx.(m (n x))

six = ((mult two) three)

=> ((Lm.Ln.Lx.(m (n x)) two) three)
=> (Ln.Lx.(two (n x) three)
=> Lx.(two (three x))
=> Lx.(two (Lg.Ly.(g (g (g y))) x))
=> Lx.(two Ly.(x (x (x y))))
=> Lx.(Lf.Lz.(f (f z)) Ly.(x (x (x y))))
=> Lx.Lz.(Ly.(x (x (x y))) (Ly.(x (x (x y))) z))
=> Lx.Lz.(Ly.(x (x (x y))) (x (x (x z))))
=> Lx.Lz.(x (x (x (x (x (x z))))))

And exponentiation as follows:

power = Lm.Ln.(m n);

nine = ((power two) three)

=> ((Lm.Ln.(m n) two) three)
=> (Ln.(two n) three)
=> (two three)
=> (Lf.Lx.(f (f x)) three)
=> Lx. (three (three x))
=> Lx. (three (Lg.Ly.(g (g (g y))) x))
=> Lx. (three Ly.(x (x (x y))))
=> Lx. (Lg.Lz.(g (g (g z))) Ly.(x (x (x y))))
=> Lx.Lz.(Ly.(x (x (x y)))
(Ly.(x (x (x y)))
(Ly.(x (x (x y))) z)))

132
 => Lx.Lz.(Ly.(x (x (x y)))
(Ly.(x (x (x y)))
(x (x (x z)))))
=> Lx.Lz.(Ly.(x (x (x y)))
(x (x (x (x (x (x z)))))))
=> Lx.Lz.(x (x (x (x (x (x (x (x (x z)))))))))

Recursive Functions
Recursive functions are another class of effectively-computable functions.
Unlike for Turing machines and abacus machines, the description of recursive
functions is inductive: certain basic functions are recursive, and functions build
from recursive functions in a certain way are also recursive. Because TMs can
simulate abacus machines, we get a cycle of simulations. So all three kinds of
computable functions are the same. In particular, Church‘s thesis and Turing‘s
thesis are equivalent.
First, we introduce the primitive recursive functions. Then we introduce the
recursive function by adding a construct called minimisation. Intuitively,
primitive recursive functions can do only FOR loops and always terminate,
whereas minimisation corresponds to a WHILE loop that may not terminate.
Consider the function exp(x, y)=xy:

The two ―rewriting rules‖ below are enough to define the exp function
x0=1 (1)
xy+1=x·xy (2)
The rules for expreduce exponentiation to multiplication; now consider

133
x·0=0 (3)
x·(y+1)=x+x·y (4)
So the rules for · reduce multiplication to addition.
Now consider
x+0=x (5)
x+(y+1)=1+(x+y) (6)
So the rules for + reduce addition to adding 1.
Primitive recursion is in the spirit of our ―computation by rewriting‖ definitions
of exp, ·, and +. It consists of one rule for y=0 and one rule for y>0. y acts as a
―countdown‖ for the number of remaining steps in the computation.
Reasons for accepting the thesis
Every effectively calculable function that has been investigated in this respect
has turned out to be computable by Turing machine. All known methods or
operations for obtaining new effectively calculable functions from given
effectively calculable functions are paralleled by methods for constructing new
Turing machines from given Turing machines. All attempts to give an exact
analysis of the intuitive notion of an effectively calculable function have turned
out to be equivalent, in the sense that each analysis offered has been proved to
pick out the same class of functions, namely those that are computable by
Turing machine.

In-text Question:
The following instructions specify a Turing Machine which recognizes the language given
by the regular expression a*b*. Assume that the head is initially located at the leftmost
end of the input.
< 0,, , S,Halt >
< 0, a, a,R, 0 >
< 0, b, b,R, 1 >
< 1, b, b,R, 1 >
< 1, ,, S,Halt >
Draw the state change diagram for this machine, and explain how it recognizes the strings

134
abb, bbb, and , but not the string ba.

If the data is abb then the TM, starting in state 0, moves right, leaving the symbol a alone and
remains in state 0. Having moved right, it finds itself in state 0 looking at a b and so it leaves the
symbol unchanged, moves right and enters state 1. etc. etc. until it goes to the Halt state. We say,
therefore, the string the string abb is accepted by this TM. The string ba is not accepted because
it gets into the state 1 with an a under the read-head. There is no transition leading away from
state 1 which reads a from the tape.

3.0 Tutor Marked Assignments (Individual or Group)

1. Construct a TM computing the successor function s(n) =n+ 1.
2. Let f be a two-place recursive total function. Show that the function is
also recursive: h(x)= f(x,x)
3. Show that the factorial function is primitive recursive.

135
4.0 Conclusion/Summary
You have come to the end of this session. Was the Church Thesis difficult for
you to understand? I don‘t think it was difficult though I tried to make it easy
for you to assimilate. However, let‘s recap this session: In this session, the
following have been discussed: Church Thesis (lambda-calculus, Church-
Rosser Theorem; Computation; Church Numerals; Successors; Additions;
Recursion. Also, we have elaborated on Turing machines: Push Down
Automata; Single tape Turing Machines; Representing the Finite State Control
and Turing Machine Programs.

5.0 Self-Assessment Questions

1. State and explain the Church thesis

2. Describe the functionality of a typical Turing machine

Answers to Self-Assessment Questions

1. A problem is said to be computable if and only if it is effectively
computable. This means that a problem is computable, if it is possible to
construct a Turing machine or its equivalent for the problem.

2. Conceptually a Turing machine, like finite automata, consists of a finite

control and a tape. At any time it is in one of the finite number of states. The
tape has the left end but it extends infinitely to the right. It is also divided into
squares and a symbol can be written in each square. However, unlike finite
automata, its head is a read-write head and it can move left, right or stay at the
same square after a read or write.

136
Given a string of symbols on the tape, a Turing machine starts at the initial
state. At any state it reads the symbol under the head, either erases it or
replaces it with a symbol (possibly the same symbol). It then moves the head
to left or right or does not move it and goes to the next state which may be the
same as the current state. One of its states is the halt state and when the Turing
machine goes into the halt state, it stops its operation.

6.0 Additional Activities (Videos, Animations & Out of Class Activities) e.g.
a. Google made a small online game which illustrates Turing Machines in a fun
and interesting way. Try out this Google Doodle (at
https://www.google.com/doodles/alan-turings-100th-birthday) and see if you
can solve some of the puzzles. Pay attention to what the interface of the game
is, it will help your understanding of some issues discussed in this session.

7.0 References/Further Reading

Jonathan Bowen, Formal Specification and Documentation Using Z: A Case
Study of Approach, International Thomson Computers Press (ITCP),
1996.

137
Huth M. and Ryan M. Logic in Computer Science: Modelling and Reasoning
about Systems. Cambridge University Press 1999.
CliffB. Jones, Systematic Software Development Using VDM, 2nd Edition,
Prentice Hall, 1990.

138
 Study Session 2: Finite State Automata
Introduction
1.0 Learning Outcome
2.0 Main Content
2.1- Finite State Automata
2.2- Deterministic Finite Automaton (DFA)
2.3- Non Deterministic Finite Automaton (NDFA)
2.4- Formal Language Theory
2.5- Regular expressions
2.6- Pushdown Automata
2.7- Context Free Grammars
3.0 Tutor Marked Assignments (Individual or Group Assignments)
4.0 Study Session Summary and Conclusion
5.0 Self-Assessment Questions and Answer
6.0 Additional Activities (Videos, Animations & Out of Class Activities)
7.0 References/Further Reading

Introduction:
In the last session, I described the Turing machine to you and even gave you
some examples. I want to welcome you to the consideration of another
‗machine‘ Finite Automata (FA) which I shall be describing in detail in this
session. As you read on in this session, you might establish a linkage between
the TM studied in the last session and FA to be studied in this session. Finite
Automata are a simple, but nonetheless useful, mathematical model of
computation. In this chapter, we look at this model and at the languages that
they can accept. A finite state machine (sometimes called a finite state
automaton) is a computation model that can be implemented with hardware or
software and can be used to simulate sequential logic and some computer
programs. Finite state automata generate regular languages. Finite state

139
machines can be used to model problems in many fields including mathematics,
artificial intelligence, games, and linguistics. Finite automata (FA), also widely
known as finite state automata (FSA), are a mathematical model of computation
based on the ideas of: A system changing state due to inputs supplied to it
(Transitions from state to state are governed); Some of these states being
acceptor or final states. This is a computation model of somewhat limited
power. Not all things that we regard as ―computation‖ can be done with FAs. It
is, however, powerful enough to have quite few practical applications, while
being simple enough to be easily understood.

1.0 Study Session Learning Outcome

After studying this session, I expect you to be able to:
1. Describe and construct finite state automata (FSA).
2. List the types of FSA.
3. Apply FSA to model software/systems.

2.0 Main Content

2.1. Finite State Automata
There are two types of finite state machines (FSMs): deterministic finite state
machines, often called deterministic finite automata, and nondeterministic finite
state machines, often called nondeterministic finite automata. There are slight
variations in ways that state machines are represented visually, but the ideas
behind them stem from the same computational ideas. By definition,
deterministic finite automata recognise, or accept, regular languages, and a
language is regular if a deterministic finite automaton accepts it. FSMs are
usually taught using languages made up of binary strings that follow a particular
pattern. Both regular and non-regular languages can be made out of binary
strings. An example of a binary string language is: the language of all strings
that have a 0 as the first character. In this language, 001, 010, 0, and 01111 are

140
valid strings (along with many others), but strings like 111, 10000, 1, and
11001100 (along with many others) are not in this language.
The operation of a finite-state automaton is always illustrated in a state
diagram. For instance, a finite automaton M is shown in the state diagram in

Figure 3.2.1: Finite state automata diagram

In this case, Q = {q0, q1, q2}, I (alphabet)= {0, 1}, F(set of accept states)= {q1}
and q0 is the start state. The transition function can be represented as T(current
state, current input symbol) next state. For instance if q0 is the current state
and 0 is the current input symbol, then the transition function is T(q0, 0) q1.
You can check this by comparing the transition table with the above state
diagram.
Suppose you want to write a program to recognise the word "main" in an input
program. Logically, your program will look something like this:
1. cin >> char
2. while (char != "m") cin >> char
3. if (cin >> char != "a") go to step 1
4. if (cin >> char != "i") go to step 1
5. if (cin >> char != "n") go to step 1
6. done

We can explain each step in this program as follows:

1. initialisation
2. looking for "m"
141
 3. recognised "m", looking for "a"
4. recognised "ma", looking for "i"
5. recognised "mai", looking for "n"
6. recognised "main"
Each step in the program corresponds to a different place in the recognition
process. We can capture this behavior in a graph
i. each node in the graph represents a step in the process
ii. arcs in the graph represent movement from one step to another
iii. labels on the arcs correspond to the input required to make a transition
A finite automaton (FA) is a simple idealised machine used to recognise
patterns within input taken from some character set (or alphabet) C. The job of
an FA is to accept or reject an input depending on whether the pattern defined
by the FA occurs in the input.
A finite automaton consists of:
i. a finite set S of N states

ii. a special start state

iii. a set of final (or accepting) states
iv. a set of transitions T from one state to another, labelled with chars in C
As noted above, we can represent a FA graphically, with nodes for states, and
arcs for transitions.
We execute our FA on an input sequence as follows:
i. begin in the start state

ii. if the next input char matches the label on a transition from the current
state to a new state, go to that new state
iii. continue making transitions on each input char
o If no move is possible, then stop
o If in accepting state, then accept
Real world examples: Let‘s see what could be a Finite State Machine in the
real world:

142
 i. Example1: Coin-operated turnstile:
States: locked, unlocked
Transitions: pointing a coin in the slot will unlock the turnstile, pushing
the arm of the unlocked turnstile will let the costumer pass and lock the
turnstile again
ii. Example 2: Traffic Light
States: Red, Yellow, Green
Transitions: After a given time, Red will change to Green, Green to
Yellow, and Yellow to Red
iii. Example 3: A Safe
States: Multiple ―locked‖ states, one ―unlocked‖ state
Transitions: Correct combinations move us from initial locked states to
locked states closer to the unlocked state, until we finally get to the
unlocked state. Incorrect combinations land us back in the initial locked
state
iv. Example 4: Programming example
Knowing what we know, let‘s make a simple and basic programming
example. Let‘s say we have our friend Mario in our favourite video game.
So, Mario can do the following actions: Stand still, Run, Jump, Duck,
We can see that Mario can do a lot of things and all of those things should
be a specific state. Before writing any single line of code, we should ask
ourselves how all of our different states fit together. We need to know
exactly what Mario can do and how and when he can do these actions.
For example, Mario can stand still then run when we push the
corresponding button, but cannot run while he is jumping. So, an input
that doesn‘t cause a change of state is ignored.

We could start first by defining a ―State Interface‖:

143
interface State
{
void enter(Character character);
State handleInput(Character character, Input
input);
void update(Character character);
}
Then, we can a create a class for each state:
class RunningState : State
{
void enter(Character character)
{
// Various operations like
// setting the graphics
}
State handleInput(Character character, Input
input)
{
// Various operations like
// checking the input
// Returning a state after all the operations
return new StandingState();
}
void update(Character character)
{
// Various operations
}
}
So, our character, here our dear Mario, could have the following code:

144
class Mario : Character, Player
{
private State _state;
void handleInput(Input input)
{
_state.handleInput(this, input);
}
void update()
{
_state.update(this);
}
}

Finite Automaton can be classified into two types −

i. Deterministic Finite Automaton (DFA)
ii. Non-deterministic Finite Automaton (NDFA / NFA)
2.2. Deterministic Finite Automaton (DFA)
In DFA, for each input symbol, one can determine the state to which the
machine will move. Hence, it is called Deterministic Automaton. As it has a
finite number of states, the machine is called Deterministic Finite Machine or
Deterministic Finite Automaton.
Formal Definition of a DFA: A DFA can be represented by a 5-tuple (Q, ∑, δ,
q0, F) where
i. Q is a finite set of states.
ii. ∑ is a finite set of symbols called the alphabet.
iii. δ is the transition function where δ: Q × ∑ → Q
iv. q0 is the initial state from where any input is processed (q 0 ∈ Q).
v. F is a set of final state/states of Q (F ⊆ Q).

145
Graphical Representation of a DFA: A DFA is represented by digraphs called
state diagram. The vertices represent the states; the arcs labelled with an input
alphabet show the transitions; the initial state is denoted by an empty single
incoming arc; and the final state is indicated by double circles.

Example: Let a deterministic finite automaton be → Q = {a, b, c}, ∑ = {0, 1},

q0 = {a}, F = {c}, and transition function δ as shown by the following table −
Present State Next State for Input 0 Next State for Input 1
A A B
B C A
C B C
Its graphical representation would be as follows −

Fig 3.2.2: Deterministic Finite Automaton (DFA)

2.3. Non Deterministic Finite Automaton (DFA)

NFA is similar to DFA except following additional features:
1. Null (or ε) move is allowed i.e., it can move forward without reading
symbols.
2. Ability to transmit to any number of states for a particular input.
However, these above features don‘t add any power to NFA. If we compare
both in terms of power, both are equivalent.
Due to above additional features, NFA has a different transition function, rest is
same as DFA.
δ: Transition Function

146
δ: Q X (∑ U ϵ ) --> 2 ^ Q.
As you can see in transition function is for any input including null (or ε), NFA
can go to any state number of states.
For example, Figure 3.2.2 shows a NFA for above problem.

Fig 3.2.2: NFA Diagram

One important thing to note is, in NFA, if any path for an input string leads to
a final state, then the input string accepted. For example, in above NFA, there
are multiple paths for input string ―00‖. Since, one of the paths leads to a final
state, ―00‖ is accepted by above NFA.
Example of an NDFA: An NDFA to accept strings containing the word
"main":
-> s0 -m-> s1 -a- > s2 -i-> s3 -n-> (s4)
-> s0 -any character-> s0
This is an NDFA because, when in state s0 and seeing an "m", we can choose to
remain in s0 or go to s1. (In effect, we guess whether this "m" is the start of
"main" or not.)
If we simulate this NDFA with input "mmainm" we see the NDFA can end up
in s0 or s1 after seeing the first "m". These two states correspond to two
different guesses about the input: (1) the "m" represents the start of "main" or
(2) the "m" doesn't represent the start of "main".
-> s0 -m-> s0
-m-> s1
On seeing the next input character ("m"), one of these guesses is proven wrong,
as is there is no transition from s1 for an "m". That path halts and rejects the

147
input. The other path continues, making a transition from s0 to either s0 or s1, in
effect guessing that the second "m" in the input either is or is not the start of the
word "main".
-> s0 -m-> s0 -m-> s0
-m-> s1
-m-> s1
Continuing the simulation, we discover that at the end of the input, the
machine can be in state s0 (still looking for the start of "main"), s1 (having seen
an "m" and looking for "ain"), or s4 (having seen "main" in the input). Since at
least one of these states is an accepting state (s4), the machine accepts the input.
s0 -m-> s0 -m-> s0 -a-> s0 -i-> s0 -n-> s0 -m-> s0
-m-> s1
-m-> s1 -a-> s2 -i-> s3 -n-> s4
-m-> s1

In-text Question
Simply state the difference between the deterministic and non- deterministic FSA

Answer
NFA is similar to DFA except following additional features:
1. Null (or ε) move is allowed i.e., it can move forward without reading symbols.
2. Ability to transmit to any number of states for a particular input.
However, these above features don’t add any power to NFA. If we compare both in terms of
power, both are equivalent.

2.4 Formal Language Theory

A formal language is a set of strings over a finite alphabet. Formal language
theory is the study of formal languages, or often more accurately the study of
families of formal languages. It deals with hierarchies of language families
defined in a wide variety of ways. Formal language theory is concerned with the

148
purely syntactical aspects, rather than a semantics or meaning of the strings. It
is closely related to automata theory, which deals with formally defined
machines that accept (or generate, according to the viewpoint) formal
languages. It is also related to complexity theory, because once a formal system
capable of universal computation is fixed, a computational problem is nothing
but a formal language containing all the descriptions of problem instances, and
the answer to the problem is the subset of instances that would be accepted
(could be derived) -- which need not be effective, and need not be a computable
set, of course.
In formal language theory, a language is defined as a (possibly infinite) set of
strings over some finite alphabet of symbols. Hence formal language literacy
requires a working knowledge of sets, relations (both regular and rational),
strings, and languages; set operations like union, negation, intersection,
complementation, and Cartesian product; and the closure properties of
languages. This supports a detailed understanding of strings, languages, and
operations on strings and languages (like concatenation, composition, reversal,
iteration, Kleene-closure, and so on). It also provides background for
understanding regular grammars.

2.5 Regular expressions

If you have done any type of programming, you‘ve probably encountered
regular expressions. Regular expressions and finite state machines are
functionally equivalent. Anything you can accept or match with a regular
expression can be accepted or matched with a state machine. For example, the
pattern described above could be matched with the regular expression:
a(b*c|c*d). Regular expressions and finite state machines also have the same
limitations. In particular, they both can only match or accept patterns that can be
handled with finite memory. So what type of patterns can‘t they match? Let‘s
say you want to only match strings of ‗a‘ and ‗b‘, where there are a number of

149
‗a‘s followed by an equal number of ‗b‘s. Or n ‗a‘s followed by n ‗b‘s, where n
is some number.
Examples would be: ab, aabb, aaaaaabbbbbb,
aaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbb
At first, this looks like an easy job for a finite state machine. The problem is that
you‘ll quickly run out of states, or you‘ll have to assume an infinite number of
states — at which point it is no longer a finite state machine. Let‘s say you create
a finite state machine that can accept up to 20 ‗a‘s followed by 20 ‗b‘s. That
works fine, until you get a string of 21 ‗a‘s followed by 21 ‗b‘s — at which point
you will need to rewrite your machine to handle a longer string. For any string
you can recognize, there is one just a little bit longer that your machine can‘t
recognize because it runs out of memory. This is known as the Pumping Lemma
which basically says: ―if your pattern has a section that can be repeated (like the
one) above, then the pattern is not regular‖.
In other words, neither a regular expression nor a finite state machine can be
constructed that will recognize all the strings that do match the pattern. If you
look carefully, you‘ll notice that this type of pattern where every ‗a‘ has a
matching ‗b‘, looks very similar to HTML. Within any pair of tags, you may
have any number of other matching pairs of tags. So, while you may be able to
use a regular expression or finite state machine to recognize if a page of HTML
has the <html>, <head> and <body> elements in the correct order, you can‘t use
a regular expression to tell if an entire HTML page is valid or not — because
HTML is not a regular pattern.
Think of an identifier in C++ (such as this, temp_var2, assert etc.). How
would you describe what qualifies for an identifier? Let's see if we remember...
an identifier consists of letters, digits and the underscore character (_), and must
start with a letter (it's possible to start with an underscore, but better not to, as
these identifiers are reserved by the language). A regular expression is a
notation that allows us to define such things precisely: letter (letter | digit |

150
underscore) * In regular expressions, the vertical bar | means "or", the
parentheses are used to group sub expressions (just like in math) and the
asterisk (*) means "zero or more instances of the previous". So the regular
expression above defines the set of all C++ identifiers (a letter followed by zero
or more letters, digits or underscores). Let's see some more examples:
I. abb*a - all words starting with a, ending with a, and having at least one b
in-between. For example: "aba", "abba", "abbbba" are words that fit, but
"aa" or "abab" are not.
II. 0|1|2|3|4|5|6|7|8|9 - all digits. For example: "1" is a digit, "fx" is not.
III. x(y|z)*(a|b|c) - all words starting with x, then zero or more y or z, and
end with a, b or c. For example: "xa", "xya", "xzc", "xyzzzyzyyyzb".
IV. xyz - only the word "xyz".
There is another symbol we'll use: eps (usually denoted with the Greek letter
Epsilon) eps means "nothing". So, for example the regular expression for "either
xy or xyz" is: xy(z|eps). People familiar with regexes know that there are more
complicated forms than * and |. However, anything can be built from *, | and
eps. For instance, x? (zero or one instance of x) is a shorthand for (x|eps). x+
(one or more instances of x) is a shorthand for xx*. Note also the interesting fact
that * can be represented with +, namely: x* is equivalent to (x+)|eps. [Perl
programmers and those familiar with Perl syntax (Python programmers, that
would include you) will recognize eps as a more elegant alternative to the
numerical notation {m, n} where both m and n are zero. In this notation, x* is
equivalent to x{0,} (unbound upper limit), x+ is x{1,} and all other cases can be
built from these two base cases.
Let‘s see some popular regular expressions and how we can convert them to
finite automata.
Example 1: Even number of a‘s: The regular expression for even number of a‘s
is (b|ab*ab*)*. We can construct a finite automata as shown in Figure 3.3.3.
The automata will accept all strings which have even number of a‘s. For zero

151
a‘s, it will be in q0 which is final state. For one ‗a‘, it will go from q0 to q1 and
the string will not be accepted. For two a‘s at any positions, it will go from q0 to
q1 for 1st ‗a‘ and q1 to q0 for second ‗a‘. So, it will accept all strings with even
number of a‘s.

Figure 3.3.3: Finite automata for (b|ab*ab*)*

Example 2: String with ‗ab‘ as substring: The regular expression for strings with
‗ab‘ as substring is (a|b)*ab(a|b)*. We can construct finite automata as shown in
Figure 3.3.4. The above automata will accept all string which have ‗ab‘ as
substring. The automata will remain in initial state q0 for b‘s. It will move to q1
after reading ‗a‘ and remain in same state for all ‗a‘ afterwards. Then it will
move to q2 if ‗b‘ is read. That means, the string has read ‗ab‘ as substring if it
reaches q2.

Figure 3.3.4: Finite automata for ‘ab’

2.6 Pushdown Automata

A stack can be thought of as a stack of plates, one is stacked on top of the
other, and plates can be taken off of the top of the stack. To get to the bottom
of the stack of plates, all others must be removed first. Stacks are a last-in-
first-out, or LIFO data structure. In pushdown automata, state transitions
include adding a symbol to the string generated, like in FSMs, but state
transitions can also include instructions about pushing and popping elements

152
to and from the stack. One can walk through the pushdown automata
diagram to see what kinds of strings can be produced by the transition
functions describing the language the pushdown automata generates, or you
can feed it an input string and verify that there exists a set of transitions that
end in an accepting state that creates the input string. At each transition, a
pushdown automaton can push a symbol to the stack, pop a symbol from the
stack, do both, or do no operations to the stack. This transition symbol is e. e
also represents the empty string and can be used as a symbol. If the
instructions say that e is the symbol read, this means that the stack/input is
empty. If the instructions say to replace the symbol on top of the stack with
an e this means to delete the symbol on top of the stack (this is popping).
A pushdown automaton has three components − an input tape, a control unit,
and a stack with infinite size. The stack head scans the top symbol of the
stack. A stack does two operations − Push − a new symbol is added at the
top; Pop − the top symbol is read and removed; A PDA may or may not read
an input symbol, but it has to read the top of the stack in every transition.

Figure 3.3.4: Structure of pushdown automata

The pushdown automaton starts with an empty stack and accepts if it ends in
an accepting state at the end. The contents of the stack at the end do not
matter unless the problem specifies that the stack must be empty at the end.
If no transition from the current state can be made, reject. For example, if the
transition from state A to state B requires popping an x from the stack, if
there is no x on the top of the stack to pop, reject.
153
 Pushdown automata can be modelled as a state machine diagram with added
instructions about the stack. Where in the finite state machine, the arrows
between states were labelled with a symbol that represented the input symbol
from the string; a pushdown automaton includes information in the form of
input symbol followed by the symbol that is currently at the top of the stack,
followed by the symbol to replace the top of the stack with. These
instructions are sometimes separated by commas, slashes, or arrows as
shown in Figure 3.3.5

Figure 3.3.5: Pushdown automata modeled as state machine

A Pushdown Automata (PDA) can be defined as:

i. Q is the set of states
ii. ∑ is the set of input symbols
iii. Γ is the set of pushdown symbols (which can be pushed and popped from
stack)
iv. q0 is the initial state
v. Z is the initial pushdown symbol (which is initially present in stack)
vi. F is the set of final states
vii. δ is a transition function which maps Q x { ∑ ∪ ɛ } x Γ into Q x Γ
*. In a given state, PDA will read input symbol and stack symbol (top of
the stack) and move to a new state and change the symbol of stack.

154
2.7 Context Free Grammars
A context-free grammar (CFG) is a set of recursive rewriting rules (or
productions) used to generate patterns of strings. A CFG consists of the
following components: a set of terminal symbols, which are the characters of
the alphabet that appear in the strings generated by the grammar; a set of
nonterminal symbols, which are placeholders for patterns of terminal symbols
that can be generated by the nonterminal symbols; a set of productions, which
are rules for replacing (or rewriting) nonterminal symbols (on the left side of the
production) in a string with other nonterminal or terminal symbols (on the right
side of the production); a start symbol, which is a special nonterminal symbol
that appears in the initial string generated by the grammar.
For emphasis, we note that a context-free grammar (CFG) consisting of a finite
set of grammar rules is a quadruple (N, T, P, S) where
i. N is a set of non-terminal symbols.
ii. T is a set of terminals where N ∩ T = NULL.
iii. P is a set of rules, P: N → (N ∪ T)*, i.e., the left-hand side of the
production rule P does have any right context or left context.
iv. S is the start symbol
To generate a string of terminal symbols from a CFG, we: begin with a string
consisting of the start symbol; apply one of the productions with the start
symbol on the left hand side, replacing the start symbol with the right hand side
of the production; repeat the process of selecting nonterminal symbols in the
string, and replacing them with the right hand side of some corresponding
production, until all nonterminal have been replaced by terminal symbols.
An example grammar that generates strings representing arithmetic expressions
with the four operators +, -, *, /, and numbers as operands is:
1. <expression> --> number
2. <expression> --> ( <expression> )
3. <expression> --> <expression> + <expression>

155
 4. <expression> --> <expression> - <expression>
5. <expression> --> <expression> * <expression>
6. <expression> --> <expression> / <expression>
The only nonterminal symbol in this grammar is <expression>, which is also the
start symbol. The terminal symbols are {+,-,*,/,(,),number}. (We will interpret
"number" to represent any valid number). The first rule (or production) states
that an <expression> can be rewritten as (or replaced by) a number. In other
words, a number is a valid expression. The second rule says that an
<expression> enclosed in parentheses is also an <expression>. Note that this
rule defines an expression in terms of expressions, an example of the use of
recursion in the definition of context-free grammars. The remaining rules say
that the sum, difference, product, or division of two <expression>s is also an
expression.
Example: Consider the following examples:
i. The grammar ({A}, {a, b, c}, P, A), P : A → aA, A → abc.
ii. The grammar ({S, a, b}, {a, b}, P, S), P: S → aSa, S → bSb, S → ε
iii. The grammar ({S, F}, {0, 1}, P, S), P: S → 00S | 11F, F → 00F | ε
iv. A CFG describing strings of letters with the word "main" somewhere in
the string:
<program> --> <letter*> m a i n <letter*>
<letter*> --> <letter> <letter*> | epsilon
<letter> --> A | B | ... | Z | a | b ... | z

v. A CFG for the set of identifiers in Pascal:

<id> --> <L> <LorD*>
<LorD*> --> <L> <LorD*> | <D> <LorD*> | epsilon
<L> --> A | B | ... | Z | a | b ... | z
<D> --> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

vi. A CFG describing real numbers in Pascal:

156
 <real> --> <digit> <digit*> <decimal part>
<exp>
<digit*> --> <digit> <digit*> | epsilon
<decimal part> --> '.' <digit> <digit*> |
epsilon
<exp> --> 'E' <sign> <digit> <digit*> | epsilon
<sign> --> + | - | epsilon
<digit> --> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
9

vii. A CFG for C++ compound statements:

<compound stmt> --> { <stmt list> }
<stmt list> --> <stmt> <stmt list> | epsilon
<stmt> --> <compound stmt>
<stmt> --> if ( <expr> ) <stmt>
<stmt> --> if ( <expr> ) <stmt> else <stmt>
<stmt> --> while ( <expr> ) <stmt>
<stmt> --> do <stmt> while ( <expr> ) ;
<stmt> --> for ( <stmt> <expr> ; <expr> )
<stmt>
<stmt> --> case <expr> : <stmt>
<stmt> --> switch ( <expr> ) <stmt>
<stmt> --> break ; | continue ;
<stmt> --> return <expr> ; | goto <id> ;

157
In-text Question:
What are the three components of a PDA?

Answer
A pushdown automaton has three components − an input tape, a control unit,
and a stack with infinite size.

3.0 Tutor Marked Assignments (Individual or Group)

1. Consider the finite-state automaton M defined by the state diagram shown
below:

a. What are the states (Q) of M?

b. What is the alphabet ( ) of M?
c. What is the start state of M?
d. What are the accept states (F) of M?
e. Find T(q2, 1).
f. Create the transition table of M.

2. Consider the finite-state automaton A defined by the following transition

table.

158
a. What are the states (Q) of A?
b. What is (the alphabet of A)?
c. What is the start state of A?
d. What are the accept states (F) of A?
e. Find T(q2, b).
f. Draw a state diagram for A.

4.0 Conclusion/Summary
Welcome to the end of this section on finite automata or finite state automata
(FSA). In this session, I have discussed with you the basis of finite state
automata. In the process of achieving that, I brought to you the following:
formal language theory; determinism & non-determinism; regular expressions
and corresponding finite state machines; pushdown automata and context free
grammars. I do hope that given any system you will be able to formalize its
representation using the model of FSA.

6.0Self-Assessment Questions

1. Given an alphabet ={a, b,c,d} construct:

i. A NFA over that accepts any string in which baba is a substring.
ii. DFA over that accepts any string starting with ba and ending which ba.

Answers to Self-Assessment Questions

i.

159
 a
b a
b

b a b a
S S S S
0 1 S4
2 3
c
c d
d

ii.

c,d
a,c,d b
b a b a
S S S S
0 1 S5
3 4
a,c,d b,c,d b

S a,c,d
2

6.0 Additional Activities (Videos, Animations & Out of Class activities) e.g.
a. Visit YouTube add https://bit.ly/2Ous2Tl , https://bit.ly/2YuWLEj . Watch the video
& summarize in 1 paragraph
b. View the animation on add/site and critique it in the discussion forum
c. Take a walk and engage any 3 students on Finite State Automata; In 2
paragraphs summarize their opinion of the discussed topic. etc.

7.0 References/Further Reading

Jonathan Bowen, Formal Specification and Documentation Using Z: A Case
Study of Approach, International Thomson Computers Press (ITCP),
1996.

160
Huth M. and Ryan M. Logic in Computer Science: Modelling and Reasoning
about Systems. Cambridge University Press 1999.
CliffB. Jones, Systematic Software Development Using VDM, 2 nd Edition,
Prentice Hall, 1990.

161
 Study Session 3: Refinement
Introduction
1.0 Learning Outcome
2.0 Main Content
2.1- Refinement Calculus
2.2- Refinement laws
2.3- Example refinement
3.0 Tutor Marked Assignments (Individual or Group Assignments)
4.0 Study Session Summary and Conclusion
5.0 Self-Assessment Questions and Answer
6.0 Additional Activities (Videos, Animations & Out of Class Activities)
7.0 References/Further Reading

Introduction:
Welcome to the last session of the third module of this course titled formal
methods of software engineering. You see, I deliberately reminded you of the
title of this course. Actually, my desire as often is to help student to be able to
relate each piece of a course with the title/aim of the course. This helps you as a
student to appreciate the course as a whole. By the way, let me quickly inform
you that this session shall teach you the concepts of refinement. But, wait a
minute, refinement of what? I meant the refinement of already specified
systems. In Study session 3 of module two, the Hoare notation was introduced:
{P}prog {Q}. In this notation, {P} represents a precondition and {Q} the post-
condition. The pair {P},{Q} may be viewed as a specification of prog, and the
(new) notation [P,Q] is used for a specification of this form.
An example of this might be the following specification: [true, c = mod( ,N)].
The program given in previous Section has been shown to meet this
specification. In this session I introduced the reverse process - starting from a
specification, we derive a program which implements the specification.
162
Refinement is a process of refining a specification S to an implementation I by
applying a series of transformations that preserve the specification. We write:
S⊑ ⊑ ⊑…⊑ ⊑I
The ⊑ symbol refers to refinement, and our resultant implementation I is
guaranteed to match its specification S. At each stage of the process, we have a
choice of possible refinements, but not all refinements will lead to an
implementation. However, the process is a mechanical one, and various
heuristics can be applied to improve the choice of refinements at each stage.
Figure 3.3.1 shows the relevance of refinement beginning from the specification
to the implementation of a system.

Figure 3.3.1: From specification to source code

1.0 Study Session Learning Outcome

After studying this session, I expect you to be able to:
1. Define refinement and its associated laws
2. Apply refinement to the process of program construction

2.0 Main Content

163
2.1- Refinement Calculus
The refinement calculus is a formalization of the stepwise refinement method of
program construction. The required behaviour of the program is specified as an
abstract, possibly non-executable, program which is then refined by a series of
correctness-preserving transformations into an efficient, executable program.
We give an introduction to the application of the refinement calculus by using it
to derive a few example programs. You may need to take a quick look at the
Logical Notation and Mathematical Notation used in this tutorial, before going
on to the Specification and Programming Notation. Note that the specification
notation used here is closer to the style of Back and Morris, rather than that of
Morgan, though the differences are minor. In the refinement calculus,
specifications are written as abstract programs usually in the form of
specification statements. For example, a program that assigns x an arbitrary
element from set S, provided S is not empty, may be specified as:
{ ~(S = {}) } x := x' | x' in S.
We write
P1 [= P2
to say that program P1 is refined by program P2. This means that P2 is a correct
implementation of P1. Since refinement is transitive, a refinement step can
always be broken up into a number of smaller steps, i.e.,
P1 [= P2 /\ P2 [= P3
--------------------------
P1 [= P3
Also, if a program consists of some sub-programs, e.g., P1;P2, then the sub-
programs can be refined separately, in order to refine the composite program.

2.2. Refinement laws

164
The refinement process exhibits the following two properties:

A. Safety: pre S ⊢ pre I - We can rephrase this as:

Fig 3.3.2: Safety

―The precondition for S must also be an acceptable precondition for I‖. The
safety property indicates that refinement can safely weaken the precondition.

B. Liveness: (pre S) ∧ I ⊢ S - We can rephrase this as:

―Given the precondition for S, the behaviour of I must be allowed by S‖.
The liveness property indicates that refinement can safely strengthen the
postcondition.
These are our proof obligations if we assert that S ⊑ I. We must ensure both
safety and liveness.
The refinement table below gives some sample laws that preserve the
specification and can be used to derive a program.

165
2.2. Example refinement
The specification [ X ≥ 0, f = fac(X) ] specifies a factorial function, and an
implementation can be derived as follows:
If P ⇒ Q, we say that P is stronger than Q, and Q is weaker than P.

166
In a similar fashion, we could derive other implementations using a different
ordering of refinements.
Linear Search Example: This example involves the development of a
procedure that searches for an entry in a lookup table. The table is implemented
as an array of records:

167
TYPE Table = ARRAY OF RECORD
key:Key;
item:Item
END;
We are not interested in the type of keys and items, so we don't specify it here.
Given a key, the search procedure will try to find an item corresponding to that
key. We assume that each key has at most one entry in the table; this property is
satisfied by a table t for which uniqueness t holds:
uniqueness t == (! m,n < #t. t[m].key = t[n].key
==> m = n)
We can abstract away from the ordering of the records, and just think of a table
as a mapping from keys to items using the abs function:
abs t = { (k,i) | ?m<#t. t[m].key = k /\
t[m].item = i }
That is, k is mapped to i in table t, if there exists an entry whose key is k and
whose item is i. The uniqueness property ensures that abs t is a partial
function rather than a relation. A key k has an entry in table t if k in (dom
(abs t)) holds and we can specify the item associated with key k simply as
(abs t)(k).
The search procedure, with full error reporting, is specified as follows:
PROCEDURE Search( t:Table;
k:Key;
i:Item;
r:String )
IF k in (dom (abs t))
THEN i:= (abs t)(k) ;
r:= "Found"
ELSE r:= "Not Found"
FI

168
We will implement this by simply traversing the table from the start until we
either find the key or reach the end of the table. We refine the IF-statement by
preceding it with a statement that sets an index m to the appropriate position in
the table (using Introduce Local Variable):
VAR m:Nat .
m:=m' | (m' < #t /\ t[m'].key = k)
\/ (m' = #t /\ ~(k in (dom (abs t))) )
;
IF k in (dom (abs t)) ... FI
The postcondition for the assignment to m says that either m should be given a
value less than #t, in which case m should index the table entry for k, or m
should index beyond the end of the table, in which case k has no entry.
Before refining the assignment to m further, we introduce an assertion between
it and the IF-statement. This will be important for refining the IF-statement:
m:=m' | setm' ; <--1
{ setm } ; <--2
IF k in (dom (abs t)) ... FI <--2

where setm == (m < #t /\ t[m].key = k)

\/ (m = #t /\ ~(k in (dom
(abs t))) )
setm' == setm[m\m']
We need to refine both statements 1 and 2, but we can now do this in either
order. Let us proceed with the second statement. Because of the assertion, we
know that the key will have been found if m<#t so we introduce an IF-
statement with this condition as its guard:
IF m < #t
THEN
{ m < #t /\ setm } ; <--

169
 IF k in (dom (abs t)) ... FI <--
ELSE
{ m = #t /\ setm } ;
IF k in (dom (abs t)) ... FI
FI

We continue with the first branch:

{ m < #t /\ setm } ;
IF k in (dom (abs t)) ... FI
Since
m < #t /\ setm ==> (abs t)(k) = t[m].item
and
(abs t)(k) = t[m].item ==> k in (dom (abs
t))
the assertion can be weakened to:
{ k in (dom (abs t)) /\ t(k) = t[m].item } ;
IF k in (dom (abs t)) ... FI
or in expanded form:
{ k in (dom (abs t)) /\ t(k) = t[m].item } ;
IF k in (dom (abs t))
THEN i:= t(k) ;
r:= "Found"
ELSE r:= "Not Found"
FI
Using the Remove IF-statement Law, this can be refined to
{ t(k) = t[m].item } ;
i:= t(k) ;
r:= "Found"

170
and the assignment to i can be rewritten:
i:= t[m].item ;
r:= "Found"
In a similar fashion, the second branch of the IF-statement that we introduced
can be refined to:
r:= "Not Found"
So statement 2 is refined by:
IF m < #t
THEN
i:= t[m].item ;
r:= "Found"
ELSE
r:= "Not Found"
FI
We now refine statement 1. We want to start searching for the key from the first
position of the table, so we introduce a leading assignment to initialise m to 0:
m:=0;
{m=0} m:=m' | setm' ; <--
We will implement this with a loop that iterates until the key is found, or the
end of the table is reached, so we choose the following guard:
G == m<#t /\ ~(t[m].key = k)
We choose an invariant which says that m is within its legal range, and that the
key is not in any of the entries that have already been checked:
inv == 0 <= m <= #t /\ (!n<m . ~(t[n].key =
k) )
As a variant, we use the difference between m and the size of t:
V = (#t - m)
In order to apply the loop introduction law, we need to show that the following
conditions hold:

171
 m=0 ==> inv

inv /\ ~G ==> setm

The refined statement is then

DO m<#t /\ ~(t[m].key = k) ->
{ m<#t /\ ~(t[m].key = k) /\ inv }
<--
m:=m' | inv[m\m'] /\ 0 <= #t-m' < #t-m
<--
OD
We focus on the loop body, and strengthen it so that m is incremented by 1:
{ m<#t /\ ~(t[m].key = k) /\ inv }
m:=m' | inv[m\ m' ] /\ 0 <= #t- m' < #t-m /\ m'=m+1
We do some rewriting to get:
{ m<#t /\ inv }
m:=m' | inv[m\m+1] /\ 0 <= #t-(m+1) < #t-m /\
m'=m+1
Now we can show that
m<#t /\ ~(t[m].key = k) /\ inv ==>
inv[m\m+1]

m<#t ==> 0 <= #t-(m+1) < #t-m

so we remove conjuncts to get:
m:=m' | m'=m+1
This is of course implemented by:
m:=m+1
Gathering all the refined components together, we get:
PROCEDURE Search( t:Table;

172
 k:Key;
i:Item;
r:String )
VAR m:Nat . m:=0;
DO m<#t /\ ~(t[m].key = k) ->
m:=m+1
OD ;
IF m < #t
THEN
i:= t[m].item ;
r:= "Found"
ELSE
r:= "Not Found"
FI

In-text Question 1:
What is the general rule of thumb for refinement?

Answer
A general rule of thumb for refinement is that a refinement should:
1. Weaken pre-conditions, so that the operation will succeed in more states; and/or
2. Strengthen post-conditions, so there is less ambiguity in the effect of operations.

3.0 Tutor Marked Assignment (Individual or Group)

1. Use the concept of refinement to walk through a program that finds the
maximum of two numbers.

4.0 Conclusion/Summary
In this session, I have introduced the concept of refinement and its relation with
Hoare logic (I hope you recall Hoare logic and even the concept of weakest

173
precondition? Should have lost some concepts from that topic, you may want to
refresh yourself by going to session three of module 2). Furthermore, I also
concentrated on helping you understand the refinement and its associated laws
have been discussed, with some examples also given. I do hope you have found
refinement as a useful technique in ensuring that a software correctness
checking is successful.

5.0 Self-Assessment Question

1. What are the limitations of refinement.

Answer to Self-Assessment Questions

 The downside is that refinement can be difficult and expensive to prove.
 There are also cases where refinement cannot be applied. For example,
the vending machine was specified such that it could always accept more
coins.
 In reality there is a physical limitation on the number of coins that can be
entered into a machine, so this constraint would need to be added. This is
not refinement as it violates the first condition.

6.0 Additional Activities (Videos, Animations & Out of Class Activities)

a. Visit U-tube study the tutorial in
https://www.youtube.com/watch?v=gDdFRlCLS_E
b. Read the following journals:
i. Wang, Y., Pang, J., Zha, M. et al. J. (2001). A formal software
development approach using refinement calculus. Comput. Sci. &
Technol. (2001) 16: 251. https://doi.org/10.1007/BF02943203
ii. A. J. Dix (1989). Software engineering implications for formal
refinement. In Proceedings ESEC'89, Ed. C. Ghezzi &. J. McDermid.
Springer-Verlag. p.243-259.

174
 http://www.hcibook.com/alan/papers/ESEC89-SE-refine/

7.0 References/Further Reading

Jonathan Bowen, Formal Specification and Documentation Using Z: A Case
Study of Approach, International Thomson Computers Press (ITCP),
1996.
Huth M. and Ryan M. Logic in Computer Science: Modelling and Reasoning
about Systems. Cambridge University Press 1999.
CliffB. Jones, Systematic Software Development Using VDM, 2 nd Edition,
Prentice Hall, 1990.

175
 MODULE 4
Study Session 1: Introduction to Z and LATEX
Study Session 2: Operations in Z and Algorithmic Translation of Z
Study Session 3: Verification and Abstract data types

Study Session 1: Introduction to Z and LATEX

Introduction
1.0 Learning Outcome
2.0 Main Content
2.1- LATEX
2.2- LATEX and Z
2.3- Z specifications
2.4- Some points
2.5- Code generation
2.6- Tool support
2.7- Reading on Z
3.0 Tutor Marked Assignments (Individual or Group Assignments)
4.0 Study Session Summary and Conclusion
5.0 Self-Assessment Questions and Answer
6.0 Additional Activities (Videos, Animations & Out of Class Activities)
7.0 References/Further Reading

Introduction:
Dear learner, you are welcome to the first module of the last session. In this last
module, I shall be bringing you an interesting lesson centered on Z specification
language. Often, I always try to get my students‘ attention by promising them
that we are about to learn a new programming language. But you know what?
176
Though Z is a ‗programming language‘ but not as conventional as your Java
and PHP. However, it is very interesting. I will be showing you how you can
use Z to specify a whole system using some units call schema. In fact, this
lesson on Z shall be spread through the first and second sessions of this last
module. Again, recall that in session three of module one (1), I brought to you
the concepts of logic and set theory. Now, you are about to deploy the skill and
knowledge you gathered in that session during your study of Z.
Z is a specification language developed by the Programming Research Group at
Oxford University around 1980. It can describe and model a wide range of
computing systems. Z is based on axiomatic typed set theory and first order
predicate logic. It is written using many non-ASCII symbols, and Z
specifications should normally be properly typeset using a typesetting language
like LATEX. Tools for analysis and animation of Z specifications normally
work directly on the LATEX files, ignoring extra non-Z parts of the file.

1.0 Study Session Learning Outcome

After studying this session, I expect you to be able to:
1. Describe Z as a specification language.
2. Construct the specification a system with Logic and Sets
3. Describe how to use Z and LATEX.

2.0 Main Content

2.1. LATEX
A first LATEX document is given below:
\documentclass[12pt]{article}
\begin{document}
A very short document. Tradition dictates that we
include “Hello World”!

177
\end{document}

This document may be processed into a device independent form (a dvi file)
with the following command:

opo 427% latex first.tex

This is TeX, Version 3.14159 (C version 6.1)
(first.tex
LaTeX2e <1996/06/01> Hyphenation patterns for
english, german, loaded.

(/usr/local/teTeX/texmf/tex/latex/base/article.cls
Document Class: article 1996/05/26 v1.3r
Standard LaTeX document class

(/usr/local/teTeX/texmf/tex/latex/base/size12.clo))
No file first.aux.
[1] (first.aux) )
Output written on first.dvi (1 page, 244 bytes).
Transcript written on first.log.
opo 428%

This creates a file (first.dvi) which may be directly viewed using a dvi viewer:

opo 428% xdvi first.dvi

Note: overstrike characters may be incorrect.
opo 429%

We can also convert this dvi file to a postscript file for printing:

178
opo 429% dvips -o first.ps first.dvi
This is dvipsk 5.58f Copyright 1986, 1994 Radical Eye
Software
’ TeX output 1999.04.30:1056’ -> first.ps <tex.pro>.
[1]
opo 430%

And then we can view this:

opo 430% gv first.ps

2.2. LATEX and Z

When using Z in a document, we use special Z style files which contain
standard styles for each of the Z constructs. One of the main constructs is the Z
schema, which ties together declarations with predicates that constrain them:

\documentclass[12pt]{article}
\usepackage{oz}
\begin{document}
First we introduce the basic type we will use:
\begin{zed}
[Student]
\end{zed}

And then our first schema:

\begin{schema}{Class}
enrolled, tested: \power Student
\where
\# enrolled \leq size \\
tested \subseteq enrolled

179
\end{schema}
\end{document}

When we run this through LATEX, we get something like the following:
First we introduce the basic type we will use:
[Student]
And then our first schema:

Many of the special symbols used in Z specifications are written with short
mnemonics. The following table shows some of the more common ones.

Paul King‘s ―Printing Z and Object-Z LATEX documents‖ contains a complete

list.

2.3. Z specifications
Z is a formal specification language based on logic, sets, relations and functions
for stating what a system should do and in what order it should be done without
stating how it should be done. Hence Z is known as a declarative language.

180
A customer requirements specification given in natural language will usually be
ambiguous, inconsistent, incomplete and not structured. This is corrected by
using a formal specification language such as Z.

Advantages of using Z
i. The use of formal notation provides the precise statement of what the
system is to do.
ii. Z specifications can be checked for syntactic correctness, consistency and
contradiction by support tools.
iii. Certain amount of partial completeness can be checked.
iv. Finding errors early in requirements specification will save substantial
time and effort.
v. Formal specifications can be used to perform verification throughout the
phases of the life cycle.

Disadvantages of Z
i. Most customers do not understand a formal specification document.
i. Lack of technical knowledge in formal methodology.
ii. Lack of integrated support environments for analyst and designers using
formal techniques.

Types and Declarations: Z is a strongly typed language, meaning sets are used.
Z contains three kinds of types:
i. Built in: consisting of the set Z of integers.
ii. Basic or given: depending on the sets used in the various applications
being modelled.
iii. Free type : specifications

181
The integer set Z can be restricted to the natural numbers, represented by N, and
the positive integers, represented by N1. Real numbers are and Z‘s character set
are not considered a basic type. Z‘s character set can be represented as a free
type. The basic types in a specification are stated in a somewhat abstract
manner. It is not concerned with the details of the elements of the basic types.
For example, in a course registration system, a specification may refer to the set
of all possible students, regardless of how student records might be represented
in the software product that eventually would result. The set of students could
be called Student and written in brackets as [ Student] the set of all uniquely
identifiable students.
Examples of other basic types include:
[Book] the set of all possible books
[Person] the set of all uniquely identifiable people
[ Subject] the set of all possible subject areas

Examples of free types include:

Reply ::= no | yes
Transaction_type ::= add | delete | change
Student_type ::= undergraduate | graduate

All identifiers representing variables in a Z specification must be declared

example patron: Person declares that the variable patron is of type Person and x,
y, z : Z declares three integer types. A z specification of a system contain three
kinds of entities.
States: A state is given by the values associated with a mathematical structure
that models the system for example it can be a set, a relation, a function or a
sequence.
Event: An event is an occurrence, for example adding a student to a class.

182
Observation: An observation is associated with the examination of the value of
some variable before or after an event has occurred. For example in the
specification of a stack structure, looking at its top element or inquiring as to
whether the stack is empty are examples of observations.

A Z specification normally consists of free format text descriptions, and the

following formal descriptions:
1. Declarations of the basic types (or sets) along with global variables, and
general rules (axioms)
related to the system to be specified. First - a basic type:
[Student]
and an axiomatic definition for the system:

2. Abstract state schema describing the major system components:

3. Schemas for initialisation:

183
4. Operational schemas describing aspects of the normal operation of the
system:

2.3.1. Z declarations
Here are some sample Z declarations, given with the LATEX source. We can
declare simple types as:

[Student] \begin{zed}
[Student]
\end{zed}

Free types as:

Position ::= off j on \begin{syntax}

Position ::= off | on
\end{syntax}

A declaration:
x:ℕ \begin{zed}
x : \nat
\end{zed}

Another declaration:

184
8n : ℕ ⦁ n + n ∈ even: \begin{zed}
\all n: \nat \dot n+n
\mem even.
\end{zed}

An axiomatic definition:

\begin{axdef}
size : \nat
\where
size = 6
\end{axdef}

Schemas describe the state of the system components, and the operations on
them:

2.3.2. Example specification

Here is a partial specification of a video library system. We begin by
introducing the given sets:
[Video; Borrower]

185
And we can then specify the maximum number of videos that an individual may
borrow, in this case 4:

We interpret this specification as a declaration of four sets - the set of stock

items, those items in stock, those videos that have been issued and the set of
borrowers. The issued declaration is a partial function from the videos to the
borrowers. We constrain the state space by asserting that:
instock ∪ dom issued = stock - the union of the instock set and the domain of
the issued function is just the total stock.
instock ∩ dom issued = ∅ - the intersection of the instock set and the domain of
the issued
function is the empty set.
ran issued ⊆ borrowers - the range of the issued function is a subset of the
borrowers.
∀ b : borrowers # ⦁ (issued ⊳ {b}) ≤ maxvids - Each borrower must have
borrowed less
than or equal to maxvids.
Finally we can start specifying the operational schema. A first one might
specify the operation of issuing a video:

186
2.4. Some Points
The following points are made about the Z specifications given here:
Implied AND: When we have a specification such as

We can also write it as:

There is an implied conjunction of the lines in the predicate part of the schema.
Domain and range: The domain and range of a function may be specified by
using \dom and \ran respectively.
Input and output: Input and output variables are identified by ? and !
respectively. For example, the declaration
x? : ℕ
marks x as an input variable.
Prime character: The prime character ― ‘ ‖ indicates the new value of a
changed item. In our example, we refer to issued’ - the changed value of the
function after the Issue Video operation.

187
Delta (Δ and Xi (Ξ : The Δ character is used to suggest that the state is
changed by the schema in which it is included. The Ξ character is used to
suggest that the state is unchanged by the schema in which it is included.
Δ is coded with \Delta,
Ξ is coded with \Xi.
Size: The number of items in a set S is given by #S.
Empty set: The empty set may be written in three ways:
x=
x=𝜙
x = {}
Range and domain restriction: In our declarations, we may restrict the
function: issued ⊳ {b?} is domain of the function restricted to the range {b?} (a
set of videos). We also may do the same thing by restricting the domain: {v?} ⊲
issued is the range of the function restricted to the domain {v?} (a set of
borrowers). The symbols ⊳ and ⊲are coded as \rres and \dres respectively.
Functional updating: To update a function, we use the symbol (\fovr).
Functions: There are many sorts of functions that can be expressed in Z. Here
is a partial list:

2.5. Code Generation

When implementing systems from specifications, the predicates in the abstract
state specification correspond to system invariants in the code. Some
programming languages2 support the concept of system invariants.

188
The predicates in operational schema may also correspond to the preconditions
and postconditions of our code. We can improve our code, and ensure that it
never deviates from the specification, by encoding the predicates as checks on
our code.

Fig 4.1.1: Code Generation

i. Those predicates that indicate requirements on the input states lead to

require checks before executing the code.
ii. Those predicates that indicate requirements on the output states lead to
ensure checks after executing the code.

If we had the following schema:

Our code might be something like:

function ClassManager.Testok( s : Student ):Response;

begin
{ ’requires’ section }

189
 require( s in enrolled );
require( not (s in tested) );
{ ’implementation’ section }
... your code ...

{ ’ensures’ section }
ensure( ... an independant check on tested’ ... );
ensure( ... an independant check on enrolled’ ...
)
Testok := success
end;

The language Eiffel supports this sort of check directly in the language. The pre
and post conditions may be specified for each feature, and the class declaration
has an invariant clause.

class TEST feature

scale is
require
...
do
...
ensure
...
end;
invariant
...
end -- class TEST

190
2.6. Tool Support
There are numerous commercial Z tools, including RoZeLink, Zola and FuZZ.
There are also active research activities at many universities around the world,
embedding Z within theorem proving systems such as HOL and Isabelle with a
view to in-depth analysis and refinement of Z specifications.
As a result of all this activity, there are freely available tools for a range of
platforms.
2.6.1. ZTC
ZTC is a Z type checker available for UNIX,Win95 and NT. It accepts Z
specifications in either LATEX format:

ZTC is also able to translate from each of these formats to the other. It can find
errors in Z specifications - the type checker ensures that the specification is
consistent in its use of types, and that the syntax of the components are correct.

2.6.2. ZANS
ZANS is a Z animation system available for UNIX, Win95 and NT. Like ZTC,
it accepts Z specifications as shown in Figure 4.1.2

191
 Figure 4.1.2: Z in ZANS

i. LATEX format, or
ii. ZSL - the ASCII only format.
When a Z specification is input to ZANS, it type checks the specification, and
then allows an interactive animation process to be performed.
In the ZANS tutorial, a specification for a ―Class Manager’s assistant‖ is
animated – adding students to the class, testing them and so on. In the process,
an error in the original specification is discovered.

In-text Question 1
What is the role of LATEX in learning Z specification language?

Answers
Z specifications should normally be properly typeset using a typesetting language like
LATEX. Tools for analysis and animation of Z specifications normally work directly on the
LATEX files, ignoring extra non-Z parts of the file.

Z Notations
∧ logical-and (conjunction)
∨ logical-or (disjunction)

192
¬ negation
⇒logical implication
(∃x•P) exists an x such that P
(∀x•P) for all x, P holds
{···} set delimiters
{x|P} set of x satisfying P
∈, ∉ set membership, non-membership
∪, ∩ set union, set intersection
\ set subtraction
𝕡S powerset of S
𝕫, ℕ set of integers, set of natural numbers
S⊆T S is a subset of T
S×T cartesian product of S and T
S↔T set of relations from S to T
S T set of partial functions from S to T
S→T set of total functions from S to T
x ↦ y mapping of element x to element y
f(x) application of function f to element x
domf, ranf domain of f, range of f
f⊕g function f overridden by function g
S R relation (or function) R with all elements in S removed from its domain
A R Domain anti-restriction A B Partial functions
A R Range restriction A B Total functions
A R Range anti-restriction A B Partial injections
R A Relational image A B Total injections
R~ Inverse of relation A B Bijections
R+ Transitive closure Function application (or
fx
Q R Relational overriding f(x))

193
a R b Infix relation

2.7. Reading on Z
The following papers are provided.
1. Peter Lindsay‘s ―A Tutorial Introduction to Formal Methods‖.
2. Xiaoping Jia‘s ―A Tutorial of ZANS‖.
3. Paul King‘s ―Printing Z and Object-Z LATEX documents‖.
4. The ―Class Manager’s Assistant‖ specification.
5. The ―Z FAQ‖

3.0 Tutor Marked Assignment (Individual or Group)

Write a state space schema for specification of an ATM system for cash deposit
by bank customers.

4.0 Conclusion/Summary
We have studied the Z specification and its notations. The use of LATEX in
describing Z was also discussed. However, there various operations that can be
done with Z in specifying a system. This we hall consider in the next section.

5.0 Self-Assessment Questions

1. Use Z specification to describe a birthday book that records the names
and date of births of individuals.

194
Answer to Self-Assessment Question
1.

6.0 Additional Activities (Videos, Animations & Out of Class activities)

a. Visit YouTube add https://bit.ly/2uxEzfs , https://bit.ly/2TZqtCT ,
https://www.youtube.com/watch?v=qfEe9luJmVE , . Watch the video &
summarize in 1 paragraph
b. View the animation on add/site and critique it in the discussion forum
c. Take a walk and engage any 3 students on Z specification; In 2 paragraphs
summarize their opinion of the discussed topic. etc.

7.0 References/Further Reading

Jonathan Bowen, Formal Specification and Documentation Using Z: A Case
Study of Approach, International Thomson Computers Press (ITCP),
1996.
Huth M. and Ryan M. Logic in Computer Science: Modelling and Reasoning
about Systems. Cambridge University Press 1999.
CliffB. Jones, Systematic Software Development Using VDM, 2nd Edition,
Prentice Hall, 1990.

195
 Study Session 2: Operations in Z and Algorithmic Translation of Z
Introduction
1.0 Learning Outcome
2.0 Main Content
2.1- Operations in Z
2.2- Algorithmic Translation of Z
3.0 Tutor Marked Assignments (Individual or Group Assignments)
4.0 Study Session Summary and Conclusion
5.0 Self-Assessment Questions and Answer
6.0 Additional Activities (Videos, Animations & Out of Class Activities)
7.0 In-text Answer
8.0 Self-Assessment Question Answers
9.0 References/Further Reading

Introduction
Welcome to the continuation on Z. In the last session, I purposefully focused on
helping you know the basis of Z. We shall now use those basic notations and
building block of Z to march on in this session as I seek to illustrate the use of Z
language. I have explained how schemas may be used to describe the behaviour of
a system. This application of the schema language revolves around the concept of
an abstract data type: a collection of variables, and a list of operations that may
change their values. We encapsulate these variables within a schema, so that an
object of the corresponding schema type represents a state of the system. An
operation that affects the state can be seen as a relation upon objects of schema
type: bindings of the state variables. The schema notation provides a convenient
way of describing such a relation: we may use a schema to express the
relationship between the state before and the state after an operation. After
studying the operations and notations of Z which can be used to specify software
modules, and how the schema calculus allows us to put together the specification

196
of a module from pieces which describe various facets of its function. We shall
also in this section turn our attention to the techniques used in Z to document the
design of a program which implements the specification.
1.0 Study Session Learning Outcome
After studying this session, I expect you to be able to:
1. Describe the operation possible in Z to put together different schemas to
compose a larger system.
2. Construct the documentation of the design of the description made in Z.

2.0 Main Content

2.1. Operations in Z
Renaming components/schema: Schemas can be renamed to another name
such that the new schema inherits the declarations/predicate of the old schema.

Fig 4.2.1: Operations in Z

Suppose a library interprets a Blocks as Books in a memory manger schema

which assigns blocks to books, the two schemas below implies the first has been
renamed to the second schema.

197
Quantification: we shall see how to use the universal an existential
quantification:
i. Universal Quantification is written as follows: (Ɐx: T • A). This is true
when A holds for all values x of type T. Here x is a said to be a quantified or
bound variable. Example: (Ɐx: 𝕫• x − x = 0).
ii. Existential Quantification is written as follows: (∃x : T • A). This is true
when A holds for some value x of type T. Example: (∃x : Z • x * x = 16).
This can be further described below:

Example: Let‘s assume that our memory manager is economical such that
we can describe it by a directory, and the free blocks are those not allocated
to users.

Then we can show that this hold:

198
Schema decorations: Suppose that the state of a system is modelled by a
schema state with two components a and b, and that these are introduced under
a constraint P. Each object of schema type state represents a valid state: a
binding of a and b in which predicate P is satisfied. We say that P forms part of
the state invariant for the system: a constraint that must always be satisfied. The
symbol ` is used to denote decoration.

Example: The state of a storage manager schema SM after some operations is

represented by the schema SM` below.

Schema Inclusion: Schema inclusion supports the reuse of an already described

schema; something like inhering a schema. It can be specified as shown below

Example: Suppose that a super memory manage schema keeps a complicated

account of occupancy of the memory manager system described above, and then
we will have:
Which is equivalent to:

199
Conventions using schema: There are four conventions are: ∆, ?, ! and
a. ∆ Convention: Is a notation used to state that the state of schema can be.
For example, the schema below renames our memory manager
specification

But this can be made more concise by using schema inclusion and
decoration as shown below

However, even schema inclusion can be used in another direction using ∆.

Let the schema below describe a state change for the memory manager.

Then our rest schema can then be written as shown below.

200
b. ? Convention: Used to denote variable as an input. The example below
demonstrates the use of this notation.
c. ! Convention: Uses to denote variable as an output. Now suppose we want
our memory manager to be able to display status message upon completion
of a task, we will first define the likely values of the message in a variable,
say Report.

This output message can then be described thus in our schema.

Example: The following schema describes user making request and a

message is output to the use.

d. Convention: Is used to use the state schema of a system without

changing its state. This notation helps us to be able to interrogate/query a
schema for some item.
Example: We can check our storage manager state to know the number of
free blocks.

201
Logical Schema Operators
Schema conjunction: We may combine the information contained in two
schemas in a variety of ways: the simplest of these is conjunction. Suppose that
S and T are the schemas introduced by

We write S ^ T to denote the conjunction of these two schemas: a new

schema formed by merging the declaration parts of S and T and conjoining
their predicate parts.
Example: Assume that we have a memory manager that restricts some
blocks of memory to operating system and the remaining blocks for users,
then the specification

202
 Now suppose that we want to state that
only a certain group of users are
allowed to owned blocks in the

Or even better stated as: memory,

Then with the aid of the conjunction

operator, we will have:

Schema disjunction: Schema disjunction allows us to describe alternatives in

the behaviour of a system. We may describe a variety of ways in which a
system may evolve, and then combine them to produce a complete description.
If S and T are the schemas introduced by

then S V T is the schema

203
As with conjunction, the declaration parts are merged. This time, however, the
predicate parts are disjoined.

Example: There are situations when requests for blocks may be denied due to
unavailable memory space. We can use the disjunction operator to show an
error message in an event of failure to secure block for user.

Schema Negation: The negation of a schema introduces the same set of

components under a negated constraint. If S is a normalised schema, then its
negation ¬S may be obtained by negating the predicate part. For example, if A
and B are types and S is introduced by
The negation is

Example: The initial state of our memory manager is:

204
 However, when the state of the
memory manager schema changes
later than it was before, then we shall

have:

2.2 Algorithmic Translation of Z

From specifications to designs: Data Refinement
The central idea is to describe the concrete data structures which the program
will use to represent the abstract data in the specification, and to derive
descriptions of the operations in terms of the concrete data structures. We call
this process data refinement. Often, a data refinement will allow some of the
control structure of the program to be made explicit, and this is achieved by one
or more steps of operation refinement or algorithm development. For simple
systems, it is possible to go from the abstract specification to the final program
in one step, a method sometimes called direct refinement. In more complex
systems, however, there are too many design decisions for them all to be
recorded clearly in a single refinement step, and the technique of deferred
refinement is appropriate. Instead of a finished program, the first refinement
step results in a new specification, and this is then subjected to further steps of
refinement until a program is at last reached. The result is a sequence of design
documents, each describing a small collection of related design decisions. As
the details of the data structures are filled in step by step, so more of the control

205
structure can be filled in, leaving certain sub-tasks to be implemented in
subsequent refinement steps. These sub-tasks can be made into subroutines in
the final program, so the step-wise structure of the development leads to a
modular structure in the program.

Implementing the Birthday Book Example

In the implementation, the data structures of our schema must be chosen with an
opposite set of criteria, but they can still be modelled with mathematical data
types and documented with schemas.

Example: a birthday book schema below

We describe the state space of the program as a schema. There is another

variable hwm (for ‗high water mark‘); it shows how much of the arrays is in use.

206
Below are the implementations of the AddBirthday and FindBirthDay schemas.

Here is a schema AbsCards that defines the abstraction relation:

207
The concrete operation can now be described: it produces as outputs cardlist and
ncards:

Below is the implementation:

The initial state of the program has hwm = 0:

208
The implementation of the schema is given as:

In-text Question
1. A video renter wants to computerize his shop. The database must keep a record of all
videos in the shop. The system must provide a possibility of performing and accounting for
daily activities such as renting a video or returning a video. Propose a state schema for the
system.

Answer
We have a set all videos of objects of type VIDEO a subset of them in_stock which are held at
the video store.
a subset booked_out which have been booked out. A video owned by the shop must be in one
of the latter two sets.

209
3.0 Tutor Marked Assignments (Individual or Group)
Write a state space schema for specification of an ATM system for cash
withdrawal by bank customers. Also, specify a schema of a customer withdrawing
from his/her account.
4.0 Conclusion/Summary
In conclusion, I want you to know that learning the notations of Z is not
sufficient to use Z language to specify a system. Therefore it became necessary
to use this session to introduce the operations possible in Z and their usage. In
addition, we presented how a system specified in Z can be translated into a
format that speeds up implementation.

5.0 Self-Assessment Questions

1. A teacher wants to keep a register of students enrolled in her class and to
record which of them has submitted their homework. For the submission, the
register must keep a record of the student as well as the date his homework was
submitted. Assume that each student is uniquely identified by his registration
number.
a. Propose a state schema for the system. The state schema should
specify an invariant for the system.
b. Define Z schemas for the following operations
i. Enrolling a new student.
ii. Recording that a student has completed the homework
iii. An operation to enquire whether a student has finished the
homework.
iv. An operation to generate the list of students who submitted their
assignment on or before the deadline.
v. Define a subroutine algorithm to perform the operation of

210
 recording that a student has completed the homework defined in
b.ii above.

Answers to Self-Assessment Questions

a. Data type [STUDENT, DATE, MESSAGE]

Register
enrolled: P STUDENT
date: P DATE
completed: STUDENT DATE

Domain(completed)⊆ enrolled

b.
i. Enrolling a new student.

enrols
Δ Register
Newstudent?: STUDENT

Newstudent? ∉ enrolled
Enrolledʹ= Enrolled ∪{ Newstudent?}
completedʹ = completedʹ

ii. Recording that a student has completed the homework

AddCompleted
Δ Register
completedstudent?: STUDENT
datecompleted?: DATE

completedstudent? ∉ dom(completed)
completedʹ = completed ∪{ completedstudent? datecompleted?}

iii. An operation to enquire whether a student has finished the

homework.

211
 Findifcompleted
Ξ Register
student?: STUDENT
report!: MESSAGE

(student? ∈ Domain(completed)⋀report!=yes ) ∨
(student? ∉ Domain(completed)⋀ ∉report!=no )

iv. An operation to generate the list of students who submitted their

assignment on or before the deadline.

SubmitedOnTime
Ξ Register
List!: P STUDENT
Deadline!: DATE

List! ={x| completed(x) <=deadline?

v. Define a subroutine algorithm to perform the operation of

recording that a student has completed the homework defined in
b.ii above.

AddCompleted(completedstudent:STUDENT, datecompleted: DATE) {

Count=count+1;
completed[count] completedstudent
date[count] datecompleted

6.0 Additional Activities (Videos, Animations & Out of Class Activities) e.g.
Visit U-tube and follow the tutorials in the following videos:
i. https://www.youtube.com/watch?v=pVcvYhDSzJg
ii. https://www.youtube.com/watch?v=_6ZLCSPmgc8

212
 iii. https://www.youtube.com/watch?v=bUD4nwHqVDI
1. Read this journal: D‘Inverno, M., & Priestley, M. (1995). Structuring
specification in Z to build a unifying framework for hypertext systems.
Lecture Notes in Computer Science, 83–102. doi:10.1007/3-540-60271-
2_114

7.0 References/Further Reading

Jonathan Bowen, Formal Specification and Documentation Using Z: A Case
Study of Approach, International Thomson Computers Press (ITCP),
1996.
Huth M. and Ryan M. Logic in Computer Science: Modelling and Reasoning
about Systems. Cambridge University Press 1999.
CliffB. Jones, Systematic Software Development Using VDM, 2 nd Edition,
Prentice Hall, 1990.

213
 Study Session 3: Verification and Abstract data types
Introduction
1.0 Learning Outcome
2.0 Main Content
2.1- Spin
2.2- Promela language
2.3- Simple example
2.5- Example ADT
2.6- LOTOS
3.0 Tutor Marked Assignments (Individual or Group Assignments)
4.0 Study Session Summary and Conclusion
5.0 Self-Assessment Questions and Answer
6.0 Additional Activities (Videos, Animations & Out of Class Activities)
7.0 References/Further Reading

Introduction:
This is the last session of the last module in your journey of the study of formal
methods of software engineering. All through the four modules treated so far, I
have systematically brought to you different formal methods. The last was Z, a
specification language for reasoning about the correctness of a system. In this
last session, I shall be teaching you on verification and also listing some
(abstract) data typing methods. So, you are welcome to this session. The
language promela is for: constructing models, with attached specifications. The
spin tool can compare the model with the specification - This is called
verification.
i. The language promela is ‘C‘ like, with an initialisation procedure. The
formal basis for promela is that it is a guarded command language similar
to that presented in the chapters on program proof, with extra statements
which either make general assertions or test for reachability.

214
ii. It can be used to model asynchronous or synchronous, deterministic or
non-deterministic systems, and has a special data type called a channel
which assists in modelling communication between processes.

There are four types of specification:

i. Algebraic for sequential systems - (Larch)
ii. Algebraic for concurrent systems - (LOTOS)
iii. Model-based for sequential systems - (Z)
iv. Model-based for concurrent systems - (CSP)
The model-based systems may use algebraic notation as in Z, but the underlying
view is that a model of a system is being constructed. In an algebraic
specification, the sub-systems are defined in terms of their interfaces to other
sub-systems.

Common to all the methods is some terminology for defining an abstract data
type (ADT).
For each ADT we define:
i. the sort - the type of the contained objects
ii. the interface syntax
iii. the axioms - the defined operations on the ADT

1.0 Study Session Learning Outcome

After studying this session, I expect you to be able to:
1. Describe how to verify systems suing formal approach.
2 Describe how abstract data types are declared and used

2.0 Main Content

2.1. Spin
Spin can be used in three basic modes:

215
1. Simulator - for rapid prototyping with a random, guided, or interactive
simulation.
2. State space analyser - exhaustively proving the validity of user specified
correctness requirements (using partial order reduction theory to optimise the
search).
3. Bit-state space analyser - validates large protocol systems with maximal
coverage of the state space (a proof approximation technique).

Fig 4.3.1: Spin

2.2. Promela Language

The language is a general purpose one, not restricted to modelling of boolean or
digital systems. We would be able to use it to model systems with analog inputs
for example;
Statements block until they can be executed - so for example the test a = b
would block until a was equal to b (It does not return a boolean). The atomic
construct allows sequences of code to be treated as an atomic unit.

2.2.1 Data types

The language has a small set of data types, with similar meaning to those found
in C:
i. int - an integer,
ii. bool - a boolean,

216
iii. byte - byte value,
iv. short - a short unsigned integer, and
v. chan - a FIFO channel.

2.2.2 Channels
The channel data type is declared as follows:

chan name = [size] of { .... };

We can use variables of this type in various ways:

i. ch!expr - puts expr into a channel

ii. ch!expr,expr,... - puts expr,expr,... into a channel
iii. ch!expr(expr) - puts expr,expr into a channel
iv. ch?expr - waits for something from channel
v. ch?expr,expr,... - waits for something from channel
vi. ch?expr(expr) - waits for something from channel

2.2.3 Specifications
We can prepare our code with assertions to test the correctness of our model.
Given a specification in [pre, post] form, we can just put one assertion for every
component of the precondition, and one assertion for every component of the
post-condition.

assert(some boolean condition);

If the asserted condition is not TRUE then the simulation or verification fails,
indicating the assertion that was violated.

2.2.4 Temporal claims

217
We may also make temporal claims - for example a claim such as ―we got here
again without making any progress‖. The support for temporal claims takes the
form of:
•

Fig 4.3.2: Temporal claims

i. Endstate labels - for determining valid endstates

ii. Progress labels - claim the absence of non-progress cycles
iii. Never claims - express impossible temporal assertions

2.2.5 Control structures

We have a fairly normal set of structures for model/simulation control. The
selection structure is:

if
:: (a != b) -> .....
:: .....
fi

Repetition is modelled by:

do
:: ... option 1 ...
:: ... option 2 ...

218
od

There is even a bad goto:

goto label
2.2.6. Processes
There are facilities to declare and create processes:

proctype A () { } - process A, with parameters as needed

init {} - the mainline
run A () - start up process A with parameters as needed
atomic {} - enclosed items are atomic

2.3. Simple Example

In this example, we model a simple system with two application processes (A
and B), communicating with each other using a protocol implemented with two
other transfer processes. We may visualise this as shown in Figure 4.3.3

Figure 4.3.3: modeling a system

2.3.1. Code
The following code segment specifies the simple protocol, and a simple
application to ‘exercise‘ the protocol.

219
#define MAX 10
mtype = { ack, nak, err, next, accept }
proctype transfer( chan in, out, chin, chout )
{
byte o,i;
in?next(o);
do
:: chin?nak(i) -> out!accept(i); chout!ack(o)
:: chin?ack(i) -> out!accept(i); in?next(o);
chout!ack(o)
:: chin?err(i) -> chout!nak(o)
od
}
proctype application( chan in, out )
{
int i=0, j=0, last i=0;
do
:: in?accept(i) ->
assert( i==last i );
if
:: (last i!=MAX) -> last i = last i+1
:: (last i==MAX)
fi
:: out!next(j) ->
if
:: (j!=MAX) -> j=j+1
:: (j==MAX)
fi

220
od
}
init
{
chan AtoB = [1] of { mtype,byte };
chan BtoA = [1] of { mtype,byte };
chan Ain = [2] of { mtype,byte };
chan Bin = [2] of { mtype,byte };
chan Aout = [2] of { mtype,byte };
chan Bout = [2] of { mtype,byte };
atomic {
run application( Ain,Aout );
run transfer( Aout,Ain,BtoA,AtoB );
run transfer( Bout,Bin,AtoB,BtoA );
run application( Bin,Bout )
};
AtoB!err(0)
}

2.3.2. Simulation
The spin tool may then be used to either exhaustively check the model, or to
simulate and display the results as shown in Figure 4.3.2

221
 Figure 4.3.4: SPIN result output

2.5. Example ADT

In an earlier chapter, we met a specification of a stack given using the axioms
for the stack operation.
Here is a more formal specification of a stack using an ADT terminology:

222
2.6. LOTOS
LOTOS (Language of Temporal Ordering Specification) is a specification
language which is an ISO standard, and is intended for use in specification of
protocols. It has:
i. process and type definitions
ii. Actions and events specified in behaviour expressions
a. ; ⇒ action prefix (behaviour expression prefixed by an action)
b. [] ⇒ choice
c. loop ⇒ recursion
d. exi t⇒ termination of process
e. stop ⇒ inactivity
f. >> ⇒ sequential composition
g. B1|[a,b...]|B2 ⇒ parallel composition

LOTOS specifications may be animated, and there is tool support for direct
conversion of LOTOS specifications to EFSMs and hence to code. LOTOS

223
syntax and structure bears some relationship to Ada, and one of the LOTOS
tools produces Ada code directly.

2.6.1. LOTOS example

We use the example given in Bustard, Norris and Orr [8], the ‘pass-the-parcel‘
game:
Parcel, children, layers of paper, music, unwrapping, tea, circulation direction
and so on...
Natural language descriptions may have many loopholes, and there are various
ways we could formalise the description:
i. State variables:
a. music on or off,
b. number of layers of paper,
c. child identity (and so on)
ii. Abstract data types
a. Functions given meaning through equations as we saw before. LOTOS
can support either method. It has:
b. An abstract data type language, and
c. A process algebra for describing system behaviour
We can pass the parcel like this:

process Circulate [ParcelPassed, MusicStarts,

MusicStops, LayerRemoved, PresentFound]: exit :=
( ParcelPassed;
Circulate [ParcelPassed, MusicStarts, MusicStops,
LayerRemoved, PresentFound])
[]
( MusicStops;
LayerRemoved;
(( MusicStarts;
224
ParcelPassed;
Circulate [ParcelPassed, MusicStarts, MusicStops,
LayerRemoved, PresentFound])
[] ( PresentFound;
exit)))
endproc (* Circulate *)

2.6.2. LOTOS Specification

The LOTOS specification for the AB - alternating bit - protocol.

SPECIFICATION DataLink [get, give] : NOEXIT

TYPE Boolean IS
SORTS
bool
OPNS
true, false: -> bool
not: bool -> bool
and , or , xor , implies
, iff : bool, bool -> bool
equal , ne : bool, bool -> bool
EQNS
FORALL x, y: bool
OFSORT bool
not (true) = false ;
not (not (x)) = x ;
x and true = x ;
x and false = false ;
x or true = true ;
x or false = x ;
x xor y = (x and not (y)) or (y and not (x)) ;

225
x implies y = y or not (x) ;
x iff y = (x implies y) and (y implies
x) ;
x equal y = x iff y ;
x ne y = x xor y ;
ENDTYPE
TYPE sequenceNumber IS
Boolean
SORTS
SeqNum
OPNS
0: -> SeqNum
inc: SeqNum -> SeqNum
equal : SeqNum, SeqNum -> bool
EQNS
OFSORT SeqNum
FORALL x: SeqNum
inc (inc (x)) = x ;
OFSORT bool
FORALL x, y: SeqNum
x equal x = true ;
x equal inc (x) = false ;
inc (x) equal x = false ;
inc (x) equal inc (y) = (x equal y) ;
ENDTYPE
TYPE BitString IS
sequenceNumber
SORTS
BitString

226
OPNS
empty: -> BitString
add: SeqNum, BitString -> BitString
ENDTYPE
TYPE FrameType IS
Boolean
SORTS
FrameType
OPNS
info, ack: -> FrameType
equal: FrameType, FrameType -> bool
EQNS
OFSORT bool
FORALL x: FrameType
equal (info, ack) = false ;

equal (ack, info) = false ;

equal (x, x) = true ;
ENDTYPE
BEHAVIOUR
HIDE tout, send, receive IN
( ( transmitter [get, tout, send, receive]
(0)
|||
receiver [give, send, receive] (0)
)
|[tout, send, receive]|
line [tout, send, receive]

227
)
WHERE
PROCESS transmitter
[get, tout, send, receive]
(seq: SeqNum) : NOEXIT :=
get ?data: BitString;
sending [tout, send, receive]
(seq, data)
>>
transmitter [get, tout, send, receive]
(inc (seq))
WHERE
PROCESS sending [tout, send, receive]
(seq: SeqNum,
data: BitString) : EXIT :=
send !info !seq !data;
( receive !ack !inc (seq) !empty;
EXIT
[]
tout;
sending [tout, send, receive]
(seq, data)
)
ENDPROC (* sending *)
ENDPROC (* transmitter *)
PROCESS receiver [give, send, receive]
(exp: SeqNum) : NOEXIT :=
receive !info ?rec: SeqNum ?data: Bit-
String;

228
( [rec equal exp = true]->
give !data;
send !ack !inc (rec) !empty;
receiver [give, send, receive]
(inc (exp))
[]
[inc (rec) equal exp = true]->
send !ack !inc (rec) !empty;
receiver [give, send, receive]
(exp)
)
ENDPROC (* receiver *)
PROCESS line [tout, send, receive]
: NOEXIT :=
send ?f: FrameType ?seq: SeqNum
?data: BitString;
( receive !f !seq !data;
line [tout, send, receive]
[]
I;
tout;
line [tout, send, receive]
)
ENDPROC (* line *)
ENDSPEC

229
2.6.3. Tool Support
The GLD tool can be used to view/edit/create a G-LOTOS (Graphical LOTOS)
version of the specification. The G-LOTOS graphical specification can be
directly converted to a textual version of the specification when needed.
The tool looks like this:

Figure 4.3.5: GLD tool

The GLA tool can be used to animate a LOTOS speciation

Figure 4.3.6: Animating system with GLA and LOTOS

In-text Question:
What is the role of LOTOS in formal method of software specification?

230
Answer
LOTOS is intended for use in the specification of protocols

3.0 Tutor Marked Assignments (Individual or Group)

1. How many reachable states do you predict the following naive Promela
model generates?
init { /* file: ex.1a */
byte i = 0;
do
:: i = i+1
od
}
2. Try a simulation run:
$ spin -p -l ex.1a # print out local vars at
every step
...
Will the simulation terminate? []

4.0 Conclusion/Summary
Welcome to the end of this session and this last module leading to the end of the
course. Meanwhile, in this session, I have discussed on how to verify systems.
Furthermore, I have shown you how abstract data types are declared and used.

5.0 Self-Assessment Questions

1. Write a hello world program in Promela SPIN

231
Answer to Self-Assessment Question

active proctype Hello(){

printf(“Hello process, my pid is: %d\n”, _pid);
}
init{
int lastpid;
printf(“init process, my pid is: %d\n”, _pid);
lastpid = run Hello();
printf(“last pid was: %d\n”, lastpid);
}

6.0 Additional Activities (Videos, Animations & Out of Class activities) e.g.
a. Visit YouTube add https://bit.ly/2FAEpZE , https://bit.ly/2V0BJv1 . Watch the
video & summarize in 1 paragraph
b. View the animation on add/site and critique it in the discussion forum
c. Take a walk and engage any 3 students on systems verification using formal
method approach and draw comparison between the approaches; In 2
paragraphs summarize their opinion of the discussed topic. etc.

7.0 References/Further Reading

Jonathan Bowen, Formal Specification and Documentation Using Z: A Case
Study of Approach, International Thomson Computers Press (ITCP),
1996.
Huth M. and Ryan M. Logic in Computer Science: Modelling and Reasoning
about Systems. Cambridge University Press 1999.
CliffB. Jones, Systematic Software Development Using VDM, 2 nd Edition,
Prentice Hall, 1990.

232
xiii. GLOSSARY

ALU. arithmetic logic unit.

ASCII. American Standard Code for Information Interchange.

algorithm. (IEEE) (1) A finite set of well-defined rules for the solution of a problem in a
finite number of steps. (2) Any sequence of operations for performing a specific task.

application software. (IEEE) Software designed to fill specific needs of a user; for example,
software for navigation, payroll, or process control. Contrast with support software; system
software.

array. (IEEE) An n-dimensional ordered set of data items identified by a single name and
one or more indices, so that each element of the set is individually addressable; e.g., a matrix,
table, or vector.

assembly language. (IEEE) A low level programming language, that corresponds closely to
the instruction set of a given computer, allows symbolic naming of operations and addresses,
and usually results in a one-to-one translation of program instructions [mnemonics] into
machine instructions.

BIOS. basic input/output system.

bandwidth. The transmission capacity of a computer channel, communications line or bus. It

is expressed in cycles per second [Hz], and also is often stated in bits or bytes per second.

bug. A fault in a program which causes the program to perform in an unintended or

unanticipated manner.

bus. A common pathway along which data and control signals travel between different
hardware devices within a computer system.

byte. A sequence of adjacent bits, usually eight, operated on as a unit.

central processing unit. The unit of a computer that includes the circuits controlling the
interpretation of program instructions and their execution.

client-server. A term used in a broad sense to describe the relationship between the receiver
and the provider of a service.

clock. (ISO) A device that generates periodic, accurately spaced signals used for such
purposes as timing, regulation of the operations of a processor, or generation of interrupts.

code review. (IEEE) A meeting at which software code is presented to project personnel,
managers, users, customers, or other interested parties for comment or approval.

233
coding. (IEEE) (1) In software engineering, the process of expressing a computer program in
a programming language. (2) The transforming of logic and data from design specifications
(design descriptions) into a programming language.

compiler. (1) (IEEE) A computer program that translates programs expressed in a high-level
language into their machine language equivalents. (2) The compiler takes the finished source
code listing as input and outputs the machine code instructions that the computer must have
to execute the program.

completeness. (NIST) The property that all necessary parts of the entity are included.
Completeness of a product is often used to express the fact that all requirements have been
met by the product.

complex instruction set computer. Traditional computer architecture that operates with
large sets of possible instructions.

complexity. (IEEE) (1) The degree to which a system or component has a design or
implementation that is difficult to understand and verify. (2) Pertaining to any of a set of
structure based metrics that measure the attribute in (1).

computer. (IEEE) (1) A functional unit that can perform substantial computations, including
numerous arithmetic operations, or logic operations, without human intervention during a
run. (2) A functional programmable unit that consists of one or more associated processing
units and peripheral equipment, that is controlled by internally stored programs, and that can
perform substantial computations, including numerous arithmetic operations, or logic
operations, without human intervention.

computer aided design. The use of computers to design products. CAD systems are high
speed workstations or personal computers using CAD software and input devices such as
graphic tablets and scanners to model and simulate the use of proposed products.

computer instruction set. (ANSI) A complete set of the operators of the instructions of a
computer together with a description of the types of meanings that can be attributed to their
operands.

computer system. (ANSI) a functional unit, consisting of one or more computers and
associated peripheral input and output devices, and associated software, that uses common
storage for all or part of a program and also for all or part of the data necessary for the
execution of the program; executes user-written or user-designated programs; performs user-
designated data manipulation, including arithmetic operations and logic operations; and that
can execute programs that modify themselves during their execution.

constant. A value that does not change during processing.

correctness. (IEEE) The degree to which software is free from faults in its specification,
design and coding. The degree to which software, documentation and other items meet
specified requirements. The degree to which software, documentation and other items meet
user needs and expectations, whether specified or not.

crash. (IEEE) The sudden and complete failure of a computer system or component.

234
DFD. data flow diagram.

DMA. direct memory access.

DOS. disk operating system.

data. Representations of facts, concepts, or instructions in a manner suitable for

communication, interpretation, or processing by humans or by automated means.

data flow diagram. (IEEE) A diagram that depicts data sources, data sinks, data storage, and
processes performed on data as nodes, and logical flow of data as links between the nodes.

data item. (ANSI) A named component of a data element. Usually the smallest component.

data set. A collection of related records.

data validation. (1) (ISO) A process used to determine if data are inaccurate, incomplete, or
unreasonable. The process may include format checks, completeness checks, check key tests,
reasonableness checks and limit checks. (2) The checking of data for correctness or
compliance with applicable standards, rules, and conventions.

database. (ANSI) A collection of interrelated data, often with controlled redundancy,

organized according to a schema to serve one or more applications. The data are stored so
that they can be used by different programs without concern for the data structure or
organization. A common approach is used to add new data and to modify and retrieve
existing data.

dead code. Program code statements which can never execute during program operation.
Such code can result from poor coding style, or can be an artifact of previous versions or
debugging efforts. Dead code can be confusing, and is a potential source of erroneous
software changes.

debugging. (Myers) Determining the exact nature and location of a program error, and fixing
the error.

design. (IEEE) The process of defining the architecture, components, interfaces, and other
characteristics of a system or component.

design description. (IEEE) A document that describes the design of a system or component.
Typical contents include system or component architecture, control logic, data structures,
data flow, input/output formats, interface descriptions and algorithms.

design phase. (IEEE) The period of time in the software life cycle during which the designs
for architecture, software components, interfaces, and data are created, documented, and
verified to satisfy requirements.

design requirement. (IEEE) A requirement that specifies or constrains the design of a

system or system component.

235
developer. A person, or group, that designs and/or builds and/or documents and/or
configures the hardware and/or software of computerized systems.

development methodology. (ANSI) A systematic approach to software creation that defines

development phases and specifies the activities, products, verification procedures, and
completion criteria for each phase.

diagnostic. (IEEE) Pertaining to the detection and isolation of faults or failures. For example,
a diagnostic message, a diagnostic manual.

different software system analysis. (IEEE) Analysis of the allocation of software

requirements to separate computer systems to reduce integration and interface errors related
to safety. Performed when more than one software system is being integrated.

digital. Pertaining to data [signals] in the form of discrete [separate/pulse form] integral
values.

digital-to-analog converter. Output related devices which translate a computer's digital

outputs to the corresponding analog signals needed by an output device such as an actuator.
Contrast with ADC [Analog-to-Digital Converter].

direct memory access. Specialized circuitry or a dedicated microprocessor that transfers data
from memory to memory without using the CPU.

directed graph. (IEEE) A graph in which direction is implied in the internode connections.

disk. Circular rotating magnetic storage hardware. Disks can be hard [fixed] or flexible
[removable] and different sizes.

disk drive. Hardware used to read from or write to a disk or diskette.

disk operating system. An operating system program; e.g., DR-DOS from Digital Research,
MS-DOS from Microsoft Corp., OS/2 from IBM, PC-DOS from IBM, System-7 from Apple.

documentation, software. (NIST) Technical data or information, including computer listings

and printouts, in human readable form, that describe or specify the design or details, explain
the capabilities, or provide operating instructions for using the software to obtain desired
results from a software system. See: specification; specification, requirements; specification.
design; software design description; test plan, test report, user's guide.

driver. A program that links a peripheral device or internal function to the operating system,
and providing for activation of all device functions.

embedded computer. A device which has its own computing power dedicated to specific
functions, usually consisting of a microprocessor and firmware. The computer becomes an
integral part of the device as opposed to devices which are controlled by an independent,
stand-alone computer. It implies software that integrates operating system and application
functions.

236
embedded software. (IEEE) Software that is part of a larger system and performs some of
the requirements of that system; e.g., software used in an aircraft or rapid transit system. Such
software does not provide an interface with the user.

emulator. (IEEE) A device, computer program, or system that accepts the same inputs and
produces the same outputs as a given system.

encapsulation. (IEEE) A software development technique that consists of isolating a system

function or a set of data and the operations on those data within a module and providing
precise specifications for the module.

end user. (ANSI) (1) A person, device, program, or computer system that uses an
information system for the purpose of data processing in information exchange. (2) A person
whose occupation requires the use of an information system but does not require any
knowledge of computers or computer programming.

error. (ISO) A discrepancy between a computed, observed, or measured value or condition

and the true, specified, or theoretically correct value or condition.

exception. (IEEE) An event that causes suspension of normal program operation. Types
include addressing exception, data exception, operation exception, overflow exception,
protection exception, underflow exception. See: anomaly, bug, defect, error, fault.

fiber optics. Communications systems that use optical fibers for transmission.

file transfer protocol. (1) Communications protocol that can transmit binary and ASCII data
files without loss of data. See: Kermit, Xmodem, Ymodem, Zmodem. (2) TCP/IP protocol
that is used to log onto the network, list directories, and copy files. It can also translate
between ASCII and EBCDIC.

firmware. (IEEE) The combination of a hardware device; e.g., an IC; and computer
instructions and data that reside as read only software on that device. Such software cannot be
modified by the computer during processing.

functional design. (IEEE) (1) The process of defining the working relationships among the
components of a system. See: architectural design. (2) The result of the process in (1).

functional requirement. (IEEE) A requirement that specifies a function that a system or

system component must be able to perform.

GB. gigabyte.

gigabyte. Approximately one billion bytes; precisely 230 or 1,073,741,824 bytes.

hard disk drive. Hardware used to read from or write to a hard disk.

hardware. (ISO) Physical equipment, as opposed to programs, procedures, rules, and

associated documentation.

237
high-level language. A programming language which requires little knowledge of the target
computer, can be translated into several different machine languages, allows symbolic
naming of operations and addresses, provides features designed to facilitate expression of
data structures and program logic, and usually results in several machine instructions for each
program statement. Examples are PL/1, COBOL, BASIC, FORTRAN, Ada, Pascal, and "C".
Contrast with assembly language.

implementation. The process of translating a design into hardware components, software

components, or both.

incremental integration. A structured reformation of the program module by module or

function by function with an integration test being performed following each addition.

incremental development. (IEEE) A software development technique in which requirements

definition, design, implementation, and testing occur in an overlapping, iterative [rather than
sequential] manner, resulting in incremental completion of the overall software product.
Contrast with rapid prototyping, spiral model, waterfall model.

input/output. Each microprocessor and each computer needs a way to communicate with the
outside world in order to get the data needed for its programs and in order to communicate
the results of its data manipulations.

inspection. A manual testing technique in which program documents [specifications

(requirements, design), source code or user's manuals] are examined in a very formal and
disciplined manner to discover errors, violations of standards and other problems.

installation. (ANSI) The phase in the system life cycle that includes assembly and testing of
the hardware and software of a computerized system.

instruction. (1) (ANSI/IEEE) A program statement that causes a computer to perform a

particular operation or set of operations. (2) (ISO) In a programming language, a meaningful
expression that specifies one operation and identifies its operands, if any.

instruction set. (1) (IEEE) The complete set of instructions recognized by a given computer
or provided by a given programming language. (2) (ISO) The set of the instructions of a
computer, of a programming language, or of the programming languages in a programming
system.

integrated circuit. Small wafers of semiconductor material [silicon] etched or printed with
extremely small electronic switching circuits.

interpreter. (IEEE) A computer program that translates and executes each statement or
construct of a computer program before translating and executing the next. The interpreter
must be resident in the computer each time a program [source code file] written in an
interpreted language is executed.

interrupt. (1) The suspension of a process to handle an event external to the process. (2) A
technique to notify the CPU that a peripheral device needs service, i.e., the device has data
for the processor or the device is awaiting data from the processor.

238
KB. kilobyte.

kilobyte. Approximately one thousand bytes. This symbol is used to describe the size of
computer memory or disk storage space. Because computers use a binary number system, a
kilobyte is precisely 210 or 1024 bytes.

LAN. local area network.

LSI. large scale integration.

large scale integration. A classification of ICs [chips] based on their size as expressed by the
number of circuits or logic gates they contain. An LSI IC contains 3,000 to 100,000
transistors.

life cycle methodology. The use of any one of several structured methods to plan, design,
implement, test. and operate a system from its conception to the termination of its use.

loader. A program which copies other [object] programs from auxiliary [external] memory to
main [internal] memory prior to its execution.

local area network. A communications network that serves users within a confined
geographical area. It is made up of servers, workstations, a network operating system, and a
communications link.

machine code. (IEEE) Computer instructions and definitions expressed in a form [binary
code] that can be recognized by the CPU of a computer.

macroinstruction. (IEEE) A source code instruction that is replaced by a predefined

sequence of source instructions, usually in the same language as the rest of the program and
usually during assembly or compilation.

main memory. A non-moving storage device utilizing one of a number of types of electronic
circuitry to store information.

main program. (IEEE) A software component that is called by the operating system of a
computer and that usually calls other software components.

mainframe. Term used to describe a large computer.

maintainability. (IEEE) The ease with which a software system or component can be
modified to correct faults, improve performance or other attributes, or adapt to a changed
environment.

megabit. Approximately one million bits. Precisely 1024 K bits, 220 bits, or 1,048,576 bits.

megabyte. Approximately one million bytes. Precisely 1024 K Bytes, 220 bytes, or
1,048,576 bytes.

megahertz. A unit of frequency equal to one million cycles per second.

239
memory. Any device or recording medium into which binary data can be stored and held,
and from which the entire original data can be retrieved.

menu. A computer display listing a number of options; e.g., functions, from which the
operator may select one. Sometimes used to denote a list of programs.

microcomputer. A term used to describe a small computer.

microprocessor. A CPU existing on a single IC. Frequently synonymous with a

microcomputer.

million instructions per second. Execution speed of a computer. MIPS rate is one factor in
overall performance.

minicomputer. A term used to describe a medium sized computer.

modeling. Construction of programs used to model the effects of a postulated environment

for investigating the dimensions of a problem for the effects of algorithmic processes on
responsive targets.

modem. (ISO) A functional unit that modulates and demodulates signals. One of the
functions of a modem is to enable digital data to be transmitted over analog transmission
facilities.

modem access. Using a modem to communicate between computers. MODEM access is

often used between a remote location and a computer that has a master database and
applications software, the host computer.

multi-processing. (IEEE) A mode of operation in which two or more processes [programs]

are executed concurrently [simultaneously] by separate CPUs that have access to a common
main memory.

multi-programming. (IEEE) A mode of operation in which two or more programs are

executed in an interleaved manner by a single CPU.

multi-tasking. (IEEE) A mode of operation in which two or more tasks are executed in an
interleaved manner.

network. (ISO) An arrangement of nodes and interconnecting branches. (2) A system

[transmission channels and supporting hardware and software] that connects several remotely
located computers via telecommunications.

object code. (NIST) A code expressed in machine language ["1"s and "0"s] which is
normally an output of a given translation process that is ready to be executed by a computer.

object oriented design. (IEEE) A software development technique in which a system or

component is expressed in terms of objects and connections between those objects.

object oriented programming. A technology for writing programs that are made up of self-
sufficient modules that contain all of the information needed to manipulate a given data

240
structure. The modules are created in class hierarchies so that the code or methods of a class
can be passed to other modules. New object modules can be easily created by inheriting the
characteristics of existing classes.

on-line. (IEEE) Pertaining to a system or mode of operation in which input data enter the
computer directly from the point of origin or output data are transmitted directly to the point
where they are used. For example, an airline reservation system.

operating system. (ISO) Software that controls the execution of programs, and that provides
services such as resource allocation, scheduling, input/output control, and data management.

optical character recognition. An information processing technology that converts human

readable data into another medium for computer input.

optical fiber. Thin glass wire designed for light transmission, capable of transmitting billions
of bits per second.

optimization. (NIST) Modifying a program to improve performance; e.g., to make it run

faster or to make it use fewer resources.

PC. personal computer.

PROM. programmable read only memory.

personal computer. Synonymous with microcomputer, a computer that is functionally

similar to large computers, but serves only one user.

program. (1) (ISO) A sequence of instructions suitable for processing. Processing may
include the use of an assembler, a compiler, an interpreter, or another translator to prepare the
program for execution. The instructions may include statements and necessary declarations.
(2) (ISO) To design, write, and test programs. (3) (ANSI) In programming languages, a set of
one or more interrelated modules capable of being executed. (4) Loosely, a routine. (5)
Loosely, to write a routine.

programming language. (IEEE) A language used to express computer programs.

project plan. (NIST) A management document describing the approach taken for a project.

proof of correctness. (NBS) The use of techniques of mathematical logic to infer that a
relation between program variables assumed true at program entry implies that another
relation between program variables holds at program exit.

protocol. (ISO) A set of semantic and syntactic rules that determines the behavior of
functional units in achieving communication.

prototyping. Using software tools to accelerate the software development process by

facilitating the identification of required functionality during analysis and design phases.

241
pseudocode. A combination of programming language and natural language used to express
a software design. If used, it is usually the last document produced prior to writing the source
code.

RAM. random access memory.

RISC. reduced instruction set computer.

ROM. read only memory.

random access memory. Chips which can be called read/write memory, since the data stored
in them may be read or new data may be written into any memory address on these chips.

rapid prototyping. A structured software requirements discovery technique which

emphasizes generating prototypes early in the development process to permit early feedback
and analysis in support of the development process.

read only memory. A memory chip from which data can only be read by the CPU. The CPU
may not store data to this memory.

real time. (IEEE) Pertaining to a system or mode of operation in which computation is

performed during the actual time that an external process occurs, in order that the
computation results can be used to control, monitor, or respond in a timely manner to the
external process.

real time processing. A fast-response [immediate response] on-line system which obtains
data from an activity or a physical process, performs computations, and returns a response
rapidly enough to affect [control] the outcome of the activity or process; e.g., a process
control application.

record. (1) (ISO) a group of related data elements treated as a unit. [A data element (field) is
a component of a record, a record is a component of a file (database)].

recursion. (IEEE) (1) The process of defining or generating a process or data structure in
terms of itself. (2) A process in which a software module calls itself.

register. A small, high speed memory circuit within a microprocessor that holds addresses
and values of internal operations; e.g., registers keep track of the address of the instruction
being executed and the data being processed. Each microprocessor has a specific number of
registers depending upon its design.

relational database. Database organization method that links files together as required..

release. (IEEE) The formal notification and distribution of an approved version.

reliability. (IEEE) The ability of a system or component to perform its required functions
under stated conditions for a specified period of time.

reliability assessment. (ANSI/IEEE) The process of determining the achieved level of

reliability for an existing system or system component.

242
requirement. (IEEE) (1) A condition or capability needed by a user to solve a problem or
achieve an objective. (2) A condition or capability that must be met or possessed by a system
or system component to satisfy a contract, standard, specification, or other formally imposed
documents. (3) A documented representation of a condition or capability as in (1) or (2).

requirements analysis. (IEEE) (1) The process of studying user needs to arrive at a
definition of a system, hardware, or software requirements. (2) The process of studying and
refining system, hardware, or software requirements.

requirements phase. (IEEE) The period of time in the software life cycle during which the
requirements, such as functional and performance capabilities for a software product, are
defined and documented.

requirements review. (IEEE) A process or meeting during which the requirements for a
system, hardware item, or software item are presented to project personnel, managers, users,
customers, or other interested parties for comment or approval.

risk. (IEEE) A measure of the probability and severity of undesired effects. Often taken as
the simple product of probability and consequence.

risk assessment. (DOD) A comprehensive evaluation of the risk and its associated impact.

robustness. The degree to which a software system or component can function correctly in
the presence of invalid inputs or stressful environmental conditions.

routine. (IEEE) A subprogram that is called by other programs and subprograms. Note: This
term is defined differently in various programming languages.

SCSI. small computer systems interface.

SQL. structured query language.

safety critical. (DOD) A term applied to a condition, event, operation, process or item of
whose proper recognition, control, performance or tolerance is essential to safe system
operation or use; e.g., safety critical function, safety critical path, safety critical component.

safety critical computer software components. (DOD) Those computer software

components and units whose errors can result in a potential hazard, or loss of predictability or
control of a system.

server. A high speed computer in a network that is shared by multiple users. It holds the
programs and data that are shared by all users.

simulation. (1) (NBS) Use of an executable model to represent the behavior of an object.
During testing the computational hardware, the external environment, and even code
segments may be simulated. (2) (IEEE) A model that behaves or operates like a given system
when provided a set of controlled inputs. Contrast with emulation.

243
simulation analysis. (IEEE) A software V&V task to simulate critical tasks of the software
or system environment to analyze logical or performance characteristics that would not be
practical to analyze manually.

simulator. (IEEE) A device, computer program, or system that behaves or operates like a
given system when provided a set of controlled inputs. Contrast with emulator. A simulator
provides inputs or responses that resemble anticipated process parameters. Its function is to
present data to the system at known speeds and in a proper format.

software. (ANSI) Programs, procedures, rules, and any associated documentation pertaining
to the operation of a system. Contrast with hardware.

software development process. (IEEE) The process by which user needs are translated into
a software product. the process involves translating user needs into software requirements,
transforming the software requirements into design, implementing the design in code, testing
the code, and sometimes installing and checking out the software for operational activities.

software documentation. (NIST) Technical data or information, including computer listings

and printouts, in human readable form, that describe or specify the design or details, explain
the capabilities, or provide operating instructions for using the software to obtain desired
results from a software system.

software engineering. (IEEE) The application of a systematic, disciplined, quantifiable

approach to the development, operation, and maintenance of software; i.e., the application of
engineering to software.

software item. (IEEE) Source code, object code, job control code, control data, or a
collection of these items.

software life cycle. (NIST) Period of time beginning when a software product is conceived
and ending when the product is no longer available for use. The software life cycle is
typically broken into phases denoting activities such as requirements, design, programming,
testing, installation, and operation and maintenance.

software reliability. (IEEE) (1) the probability that software will not cause the failure of a
system for a specified time under specified conditions. The probability is a function of the
inputs to and use of the system in the software. The inputs to the system determine whether
existing faults, if any, are encountered. (2) The ability of a program to perform its required
functions accurately and reproducibly under stated conditions for a specified period of time.

software review. (IEEE) An evaluation of software elements to ascertain discrepancies from

planned results and to recommend improvement. This evaluation follows a formal process.

source code. (1) (IEEE) Computer instructions and data definitions expressed in a form
suitable for input to an assembler, compiler or other translator. (2) The human readable
version of the list of instructions [program] that cause a computer to perform a task.

source program. (IEEE) A computer program that must be compiled, assembled, or

otherwise translated in order to be executed by a computer.

244
specification. (IEEE) A document that specifies, in a complete, precise, verifiable manner,
the requirements, design, behavior, or other characteristics of a system or component, and
often, the procedures for determining whether these provisions have been satisfied.

state. (IEEE) (1) A condition or mode of existence that a system, component, or simulation
may be in; e.g., the pre-flight state of an aircraft navigation program or the input state of a
given channel.

state diagram. (IEEE) A diagram that depicts the states that a system or component can
assume, and shows the events or circumstances that cause or result from a change from one
state to another.

state-transition table. (Beizer) A representation of a state graph that specifies the states, the
inputs, the transitions, and the outputs.

static analysis. (1) (NBS) Analysis of a program that is performed without executing the
program. (2) (IEEE) The process of evaluating a system or component based on its form,
structure, content, documentation.

static analyzer. (ANSI/IEEE) A software tool that aides in the evaluation of a computer
program without executing the program. Examples include checkers, compilers, cross-
reference generators, standards enforcers, and flowcharters.

stepwise refinement. A structured software design technique; data and processing steps are
defined broadly at first, and then further defined with increasing detail.

string. (IEEE) (1) A sequence of characters. (2) A linear sequence of entities such as
characters or physical elements.

structure chart. (IEEE) A diagram that identifies modules, activities, or other entities in a
system or computer program and shows how larger or more general entities break down into
smaller, more specific entries.

structured design. (IEEE) Any disciplined approach to software design that adheres to
specified rules based on principles such as modularity, top-down design, and stepwise
refinement of data, system structure, and processing steps.

structured programming. (IEEE) Any software development technique that includes

structured design and results in the development of structured programs.

structured query language. A language used to interrogate and process data in a relational
database.

subprogram. (IEEE) A separately compilable, executable component of a computer

program.

syntax. The structural or grammatical rules that define how symbols in a language are to be
combined to form words, phrases, expressions, and other allowable constructs.

245
system. (1) (ANSI) People, machines, and methods organized to accomplish a set of specific
functions. (2) (DOD) A composite, at any level of complexity, of personnel, procedures,
materials, tools, equipment, facilities, and software. The elements of this composite entity are
used together in the intended operational or support environment to perform a given task or
achieve a specific purpose, support, or mission requirement.

system administrator. The person that is charged with the overall administration, and
operation of a computer system. The System Administrator is normally an employee or a
member of the establishment.

system analysis. (ISO) A systematic investigation of a real or planned system to determine

the functions of the system and how they relate to each other and to any other system.

system design. (ISO) A process of defining the hardware and software architecture,
components, modules, interfaces, and data for a system to satisfy specified requirements.

system design review. (IEEE) A review conducted to evaluate the manner in which the
requirements for a system have been allocated to configuration items, the system engineering
process that produced the allocation, the engineering planning for the next phase of the effort,
manufacturing considerations, and the planning for production engineering.

system documentation. (ISO) The collection of documents that describe the requirements,
capabilities, limitations, design, operation, and maintenance of an information processing
system.

system integration. (ISO) The progressive linking and testing of system components into a
complete system.

system life cycle. The course of developmental changes through which a system passes from
its conception to the termination of its use; e.g., the phases and activities associated with the
analysis, acquisition, design, development, test, integration, operation, maintenance, and
modification of a system.

system safety. (DOD) The application of engineering and management principles, criteria,
and techniques to optimize all aspects of safety within the constraints of operational
effectiveness, time, and cost throughout all phases of the system life cycle.

system software. (1) (ISO) Application- independent software that supports the running of
application software. (2) (IEEE) Software designed to facilitate the operation and
maintenance of a computer system and its associated programs; e.g., operating systems,
assemblers, utilities.

TCP/IP. transmission control protocol/Internet protocol.

terabyte. Approximately one trillion bytes; precisely 240 or 1,099,511,627,776 bytes.

test case. (IEEE) Documentation specifying inputs, predicted results, and a set of execution
conditions for a test item.

246
testing. (IEEE) (1) The process of operating a system or component under specified
conditions, observing or recording the results, and making an evaluation of some aspect of
the system or component. (2) The process of analyzing a software item to detect the
differences between existing and required conditions, i.e. bugs, and to evaluate the features of
the software items.

testing, system. (IEEE) The process of testing an integrated hardware and software system to
verify that the system meets its specified requirements. Such testing may be conducted in
both the development environment and the target environment.

testing, unit. (1) (NIST) Testing of a module for typographic, syntactic, and logical errors,
for correct implementation of its design, and for satisfaction of its requirements. (2) (IEEE)
Testing conducted to verify the implementation of the design for one software element; e.g., a
unit or module; or a collection of software elements.

testing, usability. Tests designed to evaluate the machine/user interface. Are the
communication device(s) designed in a manner such that the information is displayed in a
understandable fashion enabling the operator to correctly interact with the system?

time sharing. (IEEE) A mode of operation that permits two or more users to execute
computer programs concurrently on the same computer system by interleaving the execution
of their programs.

top-down design. Pertaining to design methodology that starts with the highest level of
abstraction and proceeds through progressively lower levels. See: structured design.

touch screen. A touch sensitive display screen that uses a clear panel over or on the screen
surface. The panel is a matrix of cells, an input device, that transmits pressure information to
the software.

transaction. (ANSI) (1) A command, message, or input record that explicitly or implicitly
calls for a processing action, such as updating a file. (2) An exchange between and end user
and an interactive system. (3) In a database management system, a unit of processing activity
that accomplishes a specific purpose such as a retrieval, an update, a modification, or a
deletion of one or more data elements of a storage structure.

translation. (NIST) Converting from one language form to another.

transmission control protocol/Internet protocol. A set of communications protocols

developed for the Defense Advanced Research Projects Agency to internetwork dissimilar
systems.

trojan horse. A method of attacking a computer system, typically by providing a useful

program which contains code intended to compromise a computer system by secretly
providing for unauthorized access, the unauthorized collection of privileged system or user
data, the unauthorized reading or altering of files, the performance of unintended and
unexpected functions, or the malicious destruction of software and hardware.

247
truth table. (1) (ISO) An operation table for a logic operation. (2) A table that describes a
logic function by listing all possible combinations of input values, and indicating, for each
combination, the output value.

unambiguous. (1) Not having two or more possible meanings. (2) Not susceptible to
different interpretations. (3) Not obscure, not vague. (4) Clear, definite, certain.

unit. (IEEE) (1) A separately testable element specified in the design of a computer software
element. (2) A logically separable part of a computer program.

UNIX. A multitasking, multiple-user (time-sharing) operating system developed at Bell Labs

to create a favorable environment for programming research and development.

usability. (IEEE) The ease with which a user can learn to operate, prepare inputs for, and
interpret outputs of a system or component.

user. (ANSI) Any person, organization, or functional unit that uses the services of an
information processing system.

user's guide. (ISO) Documentation that describes how to use a functional unit, and that may
include description of the rights and responsibilities of the user, the owner, and the supplier
of the unit.

utility program. (ISO) A computer program in general support of the processes of a

computer; e.g., a diagnostic program, a trace program, a sort program.

V&V. verification and validation.

VLSI. very large scale integration.

valid. (1) Sound. (2) Well grounded on principles of evidence. (3) Able to withstand criticism
or objection.

validation, software. (NBS) Determination of the correctness of the final program or

software produced from a development project with respect to the user needs and
requirements. Validation is usually accomplished by verifying each stage of the software
development life cycle.

validation, verification, and testing. (NIST) Used as an entity to define a procedure of

review, analysis, and testing throughout the software life cycle to discover errors, determine
functionality, and ensure the production of quality software.

valid input. (NBS) Test data that lie within the domain of the function represented by the
program.

variable. A name, label, quantity, or data item whose value may be changed many times
during processing.

vendor. A person or an organization that provides software and/or hardware and/or firmware
and/or documentation to the user for a fee or in exchange for services.

248
verifiable. Can be proved or confirmed by examination or investigation.

verification, software. (NBS) In general the demonstration of consistency, completeness,

and correctness of the software at each stage and between each stage of the development life
cycle.

version. An initial release or a complete re-release of a software item or software element.

very large scale integration. A classification of ICs [chips] based on their size as expressed
by the number of circuits or logic gates they contain. A VLSI IC contains 100,000 to
1,000,000 transistors.

virus. A program which secretly alters other programs to include a copy of itself, and
executes when the host program is executed. The execution of a virus program compromises
a computer system by performing unwanted or unintended functions which may be
destructive.

volume. (ANSI) A portion of data, together with its data carrier, that can be handled
conveniently as a unit; e.g., a reel of magnetic tape, a disk pack, a floppy disk.

waterfall model. (IEEE) A model of the software development process in which the
constituent activities, typically a concept phase, requirements phase, design phase,
implementation phase, test phase, installation and checkout phase, and operation and
maintenance, are performed in that order, possibly with overlap but with little or no iteration.

worm. An independent program which can travel from computer to computer across network
connections replicating itself in each computer. They do not change other programs, but
compromise a computer system through their impact on system performance.

249