SFWRENG 3K04

Software Development

Thomas Chiang
September – December 2023

Who am I?
1

1
 My Background
2

2013 – 2019 Undergraduate degree in Computer

Engineering at McMaster University

2019 – 2021 M.A.Sc. In Software Engineering at McMaster

University

2021 – present PhD in Software Engineering at McMaster

University

Areas of Research
3

• Safety Engineering
 Assruance Cases and Safety Cases
 Safety Requirements Engineering
 Risk Assessment and Safety Analysis

• Model Driven-Engineering
 Model based design
 Model based requirements
 Code generation

• Domain Specific Language Development

 Generation of custom languages for specific solutions
 Automation of software development processes
 Model based syntax and lanaguages

2
 Research in McSCert
4

• Automotive Software

 Safety & Model Management with GM – 2017-2021

 Project on Certification with Toyota ITC , US – 2015-2018

 Publication:
• Chiang, Thomas, et al. "Towards the adoption of model based system safety engineering in
the automotive industry." Proceedings of the 25th International Conference on Model
Driven Engineering Languages and Systems: Companion Proceedings. 2022.
• Paige, R. F., Polack, F. A., Zschaler, S., Chiang, T., & Annable, N. (2022). Interface
Contracts for Workflow+ Models: an Analysis of Uncertainty across Models. Journal of
Object Technology, 21(4).
• Annable, N., Chiang, T., Lawford, M., Paige, R. F., & Wassyng, A. (2022). Generating
Assurance Cases Using Workflow Models. In International Conference on Computer
Safety, Reliability, and Security (pp. 97-110). Springer, Cham.
• Chiang, T. (2021). Creating An Editor For The Implementation of WorkFlow+: A Framework
for Developing Assurance Cases (Doctoral dissertation).

COURSE INFO
5

• Recommended Reference:
“Fundamentals of Software Engineering” Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli,
Second Edition.

• 2 Assignments = 1 Project - 40%*

• Mid Term Exam - 25%*

• Final Exam - 35%*

3
 TA
6

 Mohamadreza Sabeghi – [email protected]

 Hunter Ceranic – [email protected]

 Aashwita Shah – [email protected]

 Xudong Wang – [email protected]

Course Description
7

• Comprehensive overview of and experience with system development,

model-driven engineering, and assurance for safety critical software-
intensive systems in general, and safe, secure and effective medical
devices in particular.
 Motivation
 Regulatory environment
 System development & assurance
 Basic concepts in safety & security
 What makes software different & challenging?
 Requirements & Validation
 Hazard analysis
 Design
 Implementation
 Verification
 Assurance cases

 Practical: Develop software for a heart pacemaker

4
 Important Explanation
8

Lectures Project
System development Simulink

Safety & security

Hazard analysis Cope with real

requirements
Requirements Details in building code

Design Communications

Implementation

Assurance Testing real-time system

THE ROLE OF SOFTWARE

9

• Most of the systems we are interested in these days are “software-

intensive”

• What does this imply?

• We need to pay special attention to software even though we are

eventually interested in “the system”

5
 Software Engineering - 1
10

• The application of engineering to software

• Built on mathematics & computer science dealing with software
systems

 large and complex

 built by teams

 exist in many versions

 active for many years

 undergo changes

10

Software Engineering - 2
11

• Application of a systematic, disciplined, quantifiable approach to the

development, operation, and maintenance of software (IEEE 1990)
•
• Multi-person construction of multi-version software (Rendall 1978,
remark to David Parnas)

11

6
 SE in system design
12

• SE part of larger projects

• Embedded software
 Software constrained to work in a very specific environment
 Need disciplined software development
 Cyber Physical Systems (CPS) have become very complex and require a very well-
trained work force

12

(Relatively) Recent software

failures 13

• The following are examples from news services in the past few years

13

7
 Health-care database
14

14

Pacemaker recall
15

15

8
 Car stall due to software
16

16

UK tax software
17

17

9
 Infusion pumps
18

18

Gamma Knife
19

19

10
 Therapy Planning
20

20

Radiation Overdose
21
From the New York Times

21

11
 And Again
22

22

Pacemaker Security
23

23

12
 Pacemaker Security
24

24

iPhones and pacemakers

25

25

13
 Medical Device Security
26

26

Insulin Pump Security

27

27

14
 Over-the-Air Updates
28

28

Over-the-Air Updates
for Cars! 29

29

15
 Self Driving Tesla
30

30

Tesla Autopilot Again

31

31

16
 Uber Self-driving Car
32

32

A Taste of Challenges
33

Taken by my wife on a trip

between Toronto and
Kingston

Scary! Especially when

you consider what
Machine Learning may
decide to do in this
situation

33

17
 A Taste of Challenges
34

What was really happening



34

The Bottom Line

- My Opinion - 35

• It is no longer a question as to whether or not we can build the

required software systems
• It is:
 HOW CAN WE BUILD COMPLEX SOFTWARE INTENSIVE
SYSTEMS SO THAT THEY ARE SAFE, SECURE AND
DEPENDABLE?

• That’s really what this course is about – focused on embedded

(medical) devices

• There is also a current grand challenge (my opinion, my supervisors

opinion, shared by many) – how do we demonstrate safety of
systems that employ machine learning components?

35

18
 Regulatory Environments
36

• A number of domains that involve safety-critical systems are

“regulated” – one or more government agencies are mandated to act
as “regulators” and are then empowered to “licence” or “approve”
systems/devices before they can be deployed

• Typical domains are:

 Nuclear power (Canada - CNSC, US - NRC)
 Civil aviation (FAA)
 Railways
and
 Medical devices (Canada – Health Canada & CNSC, US – FDA & NRC)

36

Example: US Nuclear Regulations

37

37

19
 Example: Medical Devices
38

38

Standards
39

• There are many international standards that govern the

development of software-dependent systems
 The three main international standards bodies in this regard are: IEEE, ISO
and IEC

• Current standards have a number of positive attributes

 They provide guidance for those who are new to the process
• And may be effective teaching tools for all users
 They aid forward progress by suggesting “next steps”
 They were designed to serve as a foundation for achieving and maintaining
quality products (unfortunately most standards are process-focused, and
following a good process is not guaranteed to produce a high quality
product)

39

20
 Standards (continued)
40

• Standards provide a means to capture international consensus on

what constitutes professional practice in their respective areas

• Many process oriented standards recommend ways to avoid

systematic errors

• Some years ago a number of “functional safety standards” were

introduced
 IEC 61508
 ISO 26262 - automotive
 IEC 62304 – medical (as we saw in Medical Devices Regulatory Environment)
 DO-178C – civil aviation

• IEC 61508 introduced the notion of “Safety Integrity Levels” (SILs).

These are used in the various domains to try and quantify the category
of safety that must be achieved for a specific system or component of
a system, and what needs to be done to achieve that level of safety

40

Regulatory Summary
41

• Regulation is not the same as standardization

• We need to be familiar with what is required

• In general, standards are not complete or precise enough to guide

everything you do

• Typically, software standards are (too) process focused – and it is

difficult to describe process in enough detail to ensure the outcome is
what we need, eg safe!

• Think of these standards as a minimum requirement! (ALARA &

ALARP are important and we will discuss them later)

41

21
 SOFTWARE DEVELOPMENT
STYLES 42

• How do you approach software development?

• How do you support software?

• How do you know when deliver software?

• How do you scope software?

42

The (traditional) software

lifecycle - 1 43

Traditional waterfall view

43

22
 The (traditional) software
lifecycle - 2 44

Integration
Testing
SRS
Design
Unit
Testing
SDD
Review & Code
Verify

Application
Review &
Verify

44

The (traditional) software

lifecycle - 3 45

HAR * Validation Test and

Reliability Qualification

*
System Reports
Requirements HAR
& Design Software Integration
Software Test Report
Requirements
Specification

* What happens in
a safety-critical
environment
Software
Design
Design Review and Description Unit Test
Verification Reports Report

Legend:
Documents produced in the
HAR

*
forward going development process

Documents produced by
verifications, reviews, analyses and
testing
* HAR

Code
Activities and data flow Code Review and
Verification Reports
HAR Hazard Analysis Report

45

23
 The (traditional) software
lifecycle - 4 46

Spiral
model:
Boehm
1988

46

The V Model
47

An overview of the major steps – this view helps to start putting together
a view of “assurance”. We are primarily interested in safety assurance

User Acceptance
Testing

Requirements Analysis User Acceptance Testing

System Testing

Functional Specification System Testing

Integration Testing

High Level Design Integration Testing

Unit Testing

Detailed Design Unit Testing

Implementation

47

24
 Agile Development
48

• More suitable to address changes in software development

• Incremental development, successive release of products

• Different versions:
 SCRUM
 Extreme Programming (XP)

• https://agilemanifesto.org/

48

SCRUM
49

• User involved:
 Product owner
 Scrum master
 Team members

• Workflow:
 Product Backlog (Product Owner – top items to the team)
 Sprint planning (Decide what goes to the next spring)
• Output: Sprint backlog (list of user stories for the next sprint)
 Sprint
• 1-3 weeks to finish the sprint backlog
• Each day Daily Scrum
• Output: potentially shippable product
 Sprint Review
• Show the project to the Owner
 Sprint Retrospective
• How can we improve the process

49

25
 Extreme Programming
50

• XP considers four basic activities: coding, testing,

listening, and designing
 Coding
• ``Without code, there is no working product.”
• Programming in pairs - code review,
 Testing
• Often Test-driven development is used
 Listening
• Planning Game. Once per iteration, typically once a week
• Release Planning: determining what requirements in the near-term
releases
• Iteration Planning: This plans the activities and tasks of the developers
 Designing
• Used to reduce dependencies, etc.

50

Extreme Programming cont’d

51

51

26
 Modern Trends
52

• Agile
 Some people are distrustful of how Agile can be used to handle safety critical
engineering
 Meant for smaller teams and smaller development cycles

• Waterfall
 Some people dislike how long it takes to develop in waterfall
 Bigger teams and bigger projects
 Tried and tested for development of critical components

• Model-Driven Engineering
 Likely to be THE development meth odology for the foreseeable future (in my
opinion)

52

Assurance
53

• What this means in the context of certification of systems is that we

make a statement or statements about properties of the system and
demonstrate that we have some adequate level of confidence that the
statements are true

• In the context of safety-critical systems, we typically want to “assure”

that the system is safe and secure and dependable

• In the past, developers would provide assurance by documenting the

details of the system as well as resulting tests and analyses – and
delivering all of that to a regulator
 We refer to this as “implicit assurance”

• These days, we aim to provide more explicit assurance. We will

discuss this throughout the course

53

27
 Summary: Development Life-Cycle
& Assurance 54

• A number of development life-cycle models have been used for safety

critical systems – spiral and V model are used often

• Take note of the iterative nature of hazard analysis in the life-cycle

• Model-Driven Development is prevalent in some industries (automotive

and aviation for example) – and its use is growing for good reasons

• We need to produce explicit assurance that the systems we develop

are safe, secure and dependable

54

SOFTWARE CHALLENGES
55

• Complexity

• Lack of continuity

• Software does not age in the way that hardware does

• In general it is difficult to automate tasks – and that is what we do all

the time in creating software solutions

• It is so easy to write software programs – so difficult to get them to be

correct, safe, secure and reliable

55

28
 Complexity
56

Three structures of
varying complexity

56

How does complexity affect us?

57

With some
experience I may be
able to build this
without
requirements and a
design

57

29
 How does complexity affect us?
58

Maybe we can build this without

requirements. Without a
design? (ha!)

58

How does complexity affect us?

59

No requirements.
No design.

No way!

59

30
 How does complexity affect us?
60

Without documentation how

do we maintain this building?

No way!

60

How does complexity affect us?

61

And the same is true Without documentation how

for software! do we maintain this building?

We accept that we No way!

need to “engineer”
these structures, but
many people resist
engineering software
applications

And the complexity is

at least comparable

61

31
 Complexity in Software
62

A class diagram

[Example from
bitstorm.org]

Each “method” will

consist of a number
of lines of code

Oracle e-Business
Suite has about 250K
classes, 6M methods!

62

Examples: Lines of Code

63

Lines of code may not be a great measure of complexity, but they do measure something about complexity.

Horizontal axis is in millions of lines of code

63

32
 Continuity property
64

• Most physical products exhibit a continuity property

• If we determine that a bridge can withstand a load of 100 tonnes it

means that the bridge will withstand loads ≤ 100 tonnes

Not likely If this is true

64

Lack of continuity property

65

procedure binary_search(key: in integer;

table: in integer array; found: out boolean)
begin
bottom := table.first; top := table.last;
table while bottom < top loop
if odd(bottom+top) then
163 middle := (bottom+top-1)/2;
2 else
-45 middle := (bottom+top)/2;
3 end if;
if key ≤ table[middle] then top := middle;
16
else bottom := middle+1;
9 end if;
end loop;
key = 3 then found := key = table[top];
found = true
end binary_search;
key = 13 then
found = false
from Ghezzi, Jazayeri, Mandrioli

65

33
 Lack of continuity property
66

procedure binary_search(key: in integer;

table: in integer array; found: out boolean)
begin
bottom := table.first; top := table.last;
table while bottom < top loop
if odd(bottom+top) then
163 middle := (bottom+top-1)/2;
2 else What happens if
-45 middle := (bottom+top)/2; we leave out the
end if; “else clause” by
3 mistake?
if key ≤ table[middle] then top := middle;
16
else bottom := middle+1;
9 end if;
end loop;
key = 3 then found := key = table[top];
found = true
end binary_search;
key = 13 then
found = false
from Ghezzi, Jazayeri, Mandrioli

66

Lack of continuity property

67

procedure binary_search(key: in integer;

table: in integer array; found: out boolean)
begin
bottom := table.first; top := table.last;
while bottom < top loop
This version works if odd(bottom+top) then
only for tables with an middle := (bottom+top-1)/2;
even number of else
elements. So, if we What happens if
middle := (bottom+top)/2; we leave out the
test it with 98 elements,
end if; “else clause” by
it will work. That does mistake?
not mean it works for all if key ≤ table[middle] then top := middle;
tables with ≤ 98 else bottom := middle+1;
elements. end if;
end loop;
found := key = table[top];
end binary_search;

Software is fragile!
from Ghezzi, Jazayeri, Mandrioli

67

34
 Does Software Age?
68

• It is clear that software does not behave differently as it gets older

68

Does Software Age?

69

• It is clear that software does not behave differently as it gets older

• Is that true? 

69

35
 Does Software Age?
70

• It is clear that software does not behave differently as it gets older

• Is that true?  Well, sort of!

• Software runs on hardware platforms. The platform can change – it

can age and malfunction – it also can be much faster!

• Malfunctions and speed changes have implications for the way that the
software behaves – and if we do our job right, we can plan for those
changes so that the software does not “age”

70

Summary:
Why is software different? 71

• The engineering world has found that software is versatile, and that the
difficult and complex functions we need are easier to do in software
than in hardware – so software has become incredibly complex!

• For centuries we have learned to build system and test them relying on
the fact that physical systems exhibit a continuity property – but
software systems do not!

• Software does not age in the way that hardware does, so people
disregarded this as a problem – but software platforms (and the
environment in which the software operates) do age and this does
affect the way the software behaves!

71

36
 Model-Driven Engineering
The Start 72

• The idea of model-driven (software) development originated many

years ago, (at the time called “case tools”), but only relatively recently
has it become a reality – and (my opinion) the future predominant way
of developing complex systems

• Models have been in use for decades in engineering and science – so

this is a natural progression

72

Model-Driven Engineering
(MDE) - 1 73

• Goes by many names (sometimes they mean something subtly

different (including)
 Model-Driven Engineering
 Model-Based Design

• Basic idea:
 Models of the system you want to build – and its environment
 Transformation of system model(s) through various phases, until we can generate
implementations (mechanical/electrical artifacts, code or other logic implementation)

73

37
 Model-Driven Engineering
(MDE) - 2 74

• Benefits
 Many types of analyses can be performed on the models to validate the initial model

 Correctness-by-construction all the way through to implementation

 Can also generate “proofs” or at least, checks, that correctness-by-construction is

achieved

 Can construct tools to help examine the models

 Can regenerate implementations when changes are introduced

 Relatively easy methods for designing and communicating about software and
software concepts – from back of the envelope to full on code generation

74

Model-Driven Engineering
(MDE) - 3 75

• Modern model-driven tool suites

 Most common one in North America and world-wide for automotive and avionics is
Matlab/Simulink, developed by The MathWorks

 Others include IBM Rational, and mainly in Europe, SCADE, and ANSYS

 We are going to explore/use Matlab/Simulink

 UML and its many profiles that are used for design and documentation of software

 Note: Simulink is really a design environment. The constructs in the language are
focused on design rather than requirements – it is important to realize and
remember this!

 Modularity: Up until recently Simulink designs did not use software engineering
principles to achieve effective modularity in the design. In particular, we would be
better off if we could design Simulink models so that they are more robust with
respect to future changes – we will discuss this in software design, in terms of
“information hiding”

75

38
 Simulink – from the MathWorks
Web Site 76

76

REQUIREMENTS & VALIDATION

77

• If we do not get the requirements “right” it does not matter how good we
are at building a system so that it complies with its requirements

• There are LOTS of ways of eliciting requirements (that is not the focus
of what we are going to do – but it is extremely important)

• There are lots of ways of documenting requirements. We are not going

to examine those either. We are going to look briefly at requirements
specifications – and introduce you to “formal” specifications
 “formal” simply means with well-define syntax and semantics – usually mathematical

• Validation is determining whether or not we got the requirements “right”

• (Verification is did we build the system “right”, ie does it comply with its
requirements)
• We often refer to Verification & Validation as V&V

77

39
 Requirements in Natural Language
78

• Most requirements are written in natural language

• Often they consist of a succession of points or paragraphs that do not

collect all related information

• Often a paragraph contains multiple items

• Natural language is notoriously ambiguous, imprecise, inconsistent …

• What do we require from requirements?

 For given inputs how should the system behave - ie what should its output be?

78

Clear, unambiguous,
understandable 79

• Example: specification fragment for a word-

processor

Selecting is the process of designating

areas of the document that you want to
work on. Most editing and formatting
actions require two steps: first you
select what you want to work on,
such as text or graphics; then you
initiate the appropriate action.

79

40
 Clear, unambiguous,
understandable 80

• Example: specification fragment for a word-

processor

Selecting is the process of designating

areas of the document that you want to
work on. Most editing and formatting
actions require two steps: first you
select what you want to work on,
such as text or graphics; then you
initiate the appropriate action.

can an area be scattered?

80

Precise, unambiguous, clear

81

• Another example (from a real safety-critical system)

The message must be triplicated. The three

copies must be forwarded through three
different physical channels. The receiver
accepts the message on the basis of a
two-out-of-three voting policy.

81

41
 Precise, unambiguous, clear
82

• Another example (from a real safety-critical system)

The message must be triplicated. The three

copies must be forwarded through three
different physical channels. The receiver
accepts the message on the basis of a
two-out-of-three voting policy.

can a message be accepted as soon as we receive 2 out

of 3 identical copies of message or do we need to wait for
receipt of the 3rd?

82

Consistent
83

• Example: specification fragment for a word-processor

The whole text should be kept in lines

of equal length. The length is specified
by the user. Unless the user gives an
explicit hyphenation command,
a carriage return should occur only
at the end of a word.

83

42
 Consistent
84

• Example: specification fragment for a word-processor

The whole text should be kept in lines

of equal length. The length is specified
by the user. Unless the user gives an
explicit hyphenation command,
a carriage return should occur only
at the end of a word.

What if the length of a word exceeds the length of the line?

84

A (necessary) digression
Formal Specifications 85

• Specifications are central to many aspects of software engineering

• A specification is just a precise description of behaviour

• Requirements specifications describe required behaviour

• Design specifications describe the behaviour prescribed in a design

85

43
 Specifications - 1
86

Find the real roots of the quadratic

ax2+bx+c=0

consider floating-
point problems

86

Specifications - 2
87

if (a=0 & b=0) then solution_caption := “Ill-conditioned”

else if (b≠0) then
solution_caption := “One root”; x1 := -c/b
else
d := b2-4ac
if (d<0) then solution_caption := “No real roots”
else if (d=0) then
solution_caption := “One real root”; x1 = -b/(2a)
else
solution_caption := “Two roots”
if (b≥0) then x1 := (-b-d)/(2a)
else x1 := (-b+d)/(2a)
x2 := c/(ax1)

87

44
 Specifications - 2
88

if (a=0 & b=0) then solution_caption := “Ill-conditioned”

else if (b≠0) then
solution_caption := “One root”; x1 := -c/b
else Is this a “good”
d := b2-4ac specification?
if (d<0) then solution_caption := “No real roots”
else if (d=0) then
solution_caption := “One real root”; x1 = -b/(2a)
else
solution_caption := “Two roots”
if (b≥0) then x1 := (-b-d)/(2a)
else x1 := (-b+d)/(2a)
x2 := c/(ax1)

88

Specifications - 2
89

if (a=0 & b=0) then solution_caption := “Ill-conditioned”

else if (b≠0) then
solution_caption := “One root”; x1 := -c/b
else Is this a “good”
2
d := b -4ac specification?
if (d<0) then solution_caption := “No real roots”
else if (d=0) then
solution_caption := “One real root”; x1 = -b/(2a)
else
solution_caption := “Two roots”
if (b≥0) then x1 := (-b-d)/(2a)
else x1 := (-b+d)/(2a) Is it easy to understand?
x2 := c/(ax1) Is it a requirement spec
or is it a design spec?
What’s the difference?

89

45
 Specifications - 3
90

Analysis
b = 0 Þ Ill defined
a=0: c
b¹0Þ x =-
b
b - 4ac < 0 Þ No real roots
2

b
a ¹ 0 : b2 - 4ac = 0 Þ x = -
2a
-b ± b 2 - 4ac
b 2 - 4ac > 0 Þ x =
2a

90

Specifications - 4
91

Tabular expression

Solution caption x1 x2
a = 0 b = 0 Ill defined — —
b ¹ 0 One root -c —
b
a ¹ 0 2
b - 4ac < 0 No real roots — —
-b
2
b - 4ac = 0 One root —
2a
2
b - 4ac > 0 b ³ 0 Two roots -b- b2 - 4ac c
2a ax1

b < 0 Two roots -b+ b2 - 4ac c

2a ax1

91

46
 Specifications - 4
92

Think about why this is

Tabular expression a great way to specify
behaviour …
Solution caption x1 x2
a = 0 b = 0 Ill defined — —
b ¹ 0 One root -c —
b
a ¹ 0 2
b - 4ac < 0 No real roots — —
-b
2
b - 4ac = 0 One root —
2a
2
b - 4ac > 0 b ³ 0 Two roots -b- b2 - 4ac c
2a ax1

b < 0 Two roots -b+ b2 - 4ac c

2a ax1

92

Specifications - 5
93

Another example
• The operator in a real-time application requests or cancels a setpoint,
c_sp, by pressing momentary pushbuttons. There are two
pushbuttons, called m_pbON and m_pbOFF. They can take on the
values e_pressed and e_notPressed. We specify the required
behaviour as follows:
if (m_pbON = e_pressed ^ m_pbOFF = e_notPressed)
c_sp = e_requested
else if (m_pbON = e_notPressed ^ m_pbOFF = e_pressed)
c_sp = e_cancelled

• This is clearly a simple example. Any problems with this?

93

47
 Specifications - 5
94

Another example
• The operator in a real-time application requests or cancels a setpoint,
c_sp, by pressing momentary pushbuttons. There are two
pushbuttons, called m_pbON and m_pbOFF. They can take on the
values e_pressed and e_notPressed. We specify the required
behaviour as follows:
if (m_pbON = e_pressed ^ m_pbOFF = e_notPressed)
then c_sp = e_requested
else if (m_pbON = e_notPressed ^ m_pbOFF = e_pressed)
then c_sp = e_cancelled
• This is clearly a simple example. Any problems with this?
• What if both pushbuttons are not pressed?
• What if both pushbuttons are pressed?

94

Specifications - 5
95

Another example
• The operator in a real-time application requests or cancels a setpoint,
c_sp, by pressing momentary pushbuttons. There are two
pushbuttons, called m_pbON and m_pbOFF. They can take on the
values e_pressed and e_notPressed. We specify the required
behaviour as follows:
if (m_pbON = e_pressed ^ m_pbOFF = e_notPressed)
then c_sp = e_requested
else if (m_pbON = e_notPressed ^ m_pbOFF = e_pressed)
then c_sp = e_cancelled

• This is clearly a simple example. Any problems with this?

• What if both pushbuttons are not pressed?
• What if both pushbuttons are pressed? No specified behaviour
then no change in the
current value of c_sp.
So that makes sense.

95

48
 Specifications - 5
96

Another example
• The operator in a real-time application requests or cancels a setpoint,
c_sp, by pressing momentary pushbuttons. There are two
pushbuttons, called m_pbON and m_pbOFF. They can take on the
values e_pressed and e_notPressed. We specify the required
behaviour as follows:
if (m_pbON = e_pressed ^ m_pbOFF = e_notPressed)
then c_sp = e_requested
else if (m_pbON = e_notPressed ^ m_pbOFF = e_pressed)
then c_sp = e_cancelled
• This is clearly a simple example. Any problems with this?
• What if both pushbuttons are not pressed?
• What if both pushbuttons are pressed? No specified behaviour
then no change in the
current value of c_sp.
And it is wrong!

96

Specifications - 5
97

Another example
• The operator in a real-time application requests or cancels a
setpoint, c_sp, by pressing momentary pushbuttons. There are two
pushbuttons, called m_pbON and m_pbOFF. They can take on the
values e_pressed and e_notPressed. We specify the required
behaviour as follows:
if (m_pbON = e_pressed ^ m_pbOFF = e_notPressed)
then c_sp = e_requested
else if (m_pbON = e_notPressed ^ m_pbOFF = e_pressed)
then c_sp = e_cancelled
• It is not clear to readers whether the unstated cases are really “no
action” cases, or oversights. In this example, if both pushbuttons
are not pressed it is reasonable (and correct) to assume there is no
change to c_sp. If both pushbuttons are pressed, the domain
experts (in the case I know about) required c_sp = e_requested!

97

49
 Specifications - 6
98

Again, a tabular expression makes the specification

clear
Result

Condition
c_sp
(m_pbON = e_notPressed) &
No Change
(m_pbOFF = e_notPressed)
(m_pbON = e_notPressed) &
e_cancelled
(m_pbOFF = e_pressed)
(m_pbON = e_pressed) &
e_requested
(m_pbOFF = e_notPressed)
(m_pbON = e_pressed) &
e_requested
(m_pbOFF = e_pressed)

98

Specifications - 6
99

Again, a tabular expression makes the specification

clear - and complete

Result

Condition
c_sp
(m_pbON = e_notPressed) &
No Change
(m_pbOFF = e_notPressed)
(m_pbON = e_notPressed) &
e_cancelled
(m_pbOFF = e_pressed)
(m_pbON = e_pressed) &
e_requested
(m_pbOFF = e_notPressed)
(m_pbON = e_pressed) &
e_requested
(m_pbOFF = e_pressed)

99

50
 Specifications - 6
100

Again, a tabular expression makes the specification

clear - and complete - and unambiguous
Result

Condition
c_sp
(m_pbON = e_notPressed) &
No Change
(m_pbOFF = e_notPressed)
(m_pbON = e_notPressed) &
e_cancelled
(m_pbOFF = e_pressed)
(m_pbON = e_pressed) &
e_requested
(m_pbOFF = e_notPressed)
(m_pbON = e_pressed) &
e_requested
(m_pbOFF = e_pressed)

100

Specifications - 6
101

Again, a tabular expression makes the specification

clear - and complete - and unambiguous.
Let’s see why …
Result

Condition
c_sp
(m_pbON = e_notPressed) &
No Change
(m_pbOFF = e_notPressed)
(m_pbON = e_notPressed) &
e_cancelled
(m_pbOFF = e_pressed)
(m_pbON = e_pressed) &
e_requested
(m_pbOFF = e_notPressed)
(m_pbON = e_pressed) &
e_requested
(m_pbOFF = e_pressed)

101

51
 Specifications - 7
102

• A general, very simple, tabular expression:

Result

Condition
function name
condition 1 result 1
condition 2 result 2
… …
condition n result n

• Is equivalent to:
if (condition 1) then function name = result 1
else if (condition 2) then function name = result 2
else if …
else if (condition n) then function name = result n
• Disjointness: (so it is unambiguous)
condition i  condition j  FALSE i,j = 1,..,n, i ¹ j
• Completeness:
condition 1  condition 2  …  condition n  TRUE

102

Another (necessary) digression

The 4 Variable Model 103

Describes the essential relationship between requirements and design

Illustrates why the software design has different inputs and outputs from
the requirements!

103

52
 The 4 Variable Model
104

NAT

M REQ C

IN I SOF O OUT
Software Design
Parnas, D.L., Madey, J.: Functional
documents for computer systems. C = REQ(M), and related to the
Science of
Computer Programming 25 software through
(1995) 41-61 I = IN(M) and C = OUT(O)
104

The 4 Variable Model

105

Variables
monitored NAT controlled
variables variables
M REQ C

input output
variables variables

IN I SOF O OUT

Software Design
Parnas, D.L., Madey, J.:
Functional documents for C = REQ(M), and related to the
computer systems. Science of
Computer Programming, 25 software through
(1995) 41-61 I = IN(M) and C = OUT(O)
105

53
 The 4 Variable Model
106

Relations/Functions environmental relation

NAT

M REQ C
requirements software
design
hardware hardware

IN I SOF O OUT
Software Design
Parnas, D.L., Madey, J.:
Functional documents for We now get a proof obligation:
computer systems. Science of
Computer Programming, 25 C=REQ(M)=OUT(SOF(IN(M)))
(1995) 41-61

106

Example of IN
107

• IN represents the function performed by the input hardware

• Assume we have hardware that converts physical temperature

(degrees Celsius) to an unsigned 12-bit integer

• Assume also we can determine that

i = round(m*4/5)
where m is the monitored variable (temp)
and i is the 12-bit integer that represents m in the computer

107

54
 Consequence
108

• Every time we want to use m (temp) in the software, we have to

remember that we actually have i in the software, not m!

• Once we know this, we can deal with it really well, using a modified
version of the 4 Variable Model

108

Modified 4 Variable Model

109

Mp and Cp help You will see later that SOFin

us deal with and SOFout are hardware
this! hiding functions, designed
to make it easy to change
They are called hardware without having to
Pseudo-M and change SOFreq, the major
Pseudo-C. part of the software design

109

55
 Modified 4 Variable Model
110

Continue example of input

hardware (IN) we used
previously where
i = round(m*4/5)

If m is temp and we want to

produce mp (temp) so that it is
close to the original m, we can
multiply i by 5/4, so we get:
i = round(m*4/5)
Mp = i*5.0/4.0

And we can bound abs(M-Mp)

110

Example: Home Alarm System

111

• We will now analyze a (scaled down) example of a home alarm system

• This example is meant to introduce you to the concepts and

advantages of greater precision in requirements specification – and
how we can build an implementation that we can demonstrate
complies with its requirements

111

56
 In Class Example
112

Light on when system is live

Button to make system

live

Buttons to enter 3-digit code

to stop alarm sounding &
deactivate alarm

Button to clear erroneous digit entry

Have to re-enter all digits
Sensors connect to panel and
alarm sounds when motion detected
and system is live

112

In Class Example
113

Light on when system is live

Let’s
Button to make system
live document
the
requirements
Buttons to enter 3-digit code
to stop alarm sounding &
deactivate alarm

Button to clear erroneous digit entry

Have to re-enter all digits
Sensors connect to panel and
alarm sounds when motion detected
and system is live

113

57
 Example Requirements
114

1. The security system has a detector that sends a trip signal when
motion is detected.
2. The security system is activated by pressing the SET button.
3. The SET button is illuminated when the system is active.
4. If a trip signal is detected while the system is active, an alarm is
sounded.
5. A three-digit code must be entered to turn off the alarm sound.
6. Correct entry of the three-digit code deactivates the device.
7. If a mistake is made when entering the code, the user must press the
CLEAR button before the entire code can be re-entered.

114

Notation
115

stimuli responses

trip signal
set pressed alarm sound (on/off)
clear pressed
good digit backlight (on/off)
bad digit

115

58
 Notation
116

M_trip
M_set c_alarmSound
M_clear
M_goodDigit c_backlight
M_badDigit

116

Input Sequence
117

• no stimulus What is special about

• M_set these sequences?
• M_set . M_trip
• M_set . M_badDigit
• M_set . M_goodDigit
• M_set . M_trip . M_badDigit
• M_set . M_trip . M_goodDigit
• M_set . M_trip . M_goodDigit . M_goodDigit
• M_set . M_goodDigit . M_goodDigit

117

59
 Input Sequence
118

What is special about

• no stimulus these sequences?
• M_set What if you append
• M_set . M_trip any of the stimuli to any
• M_set . M_badDigit of these sequences?
• M_set . M_goodDigit
• M_set . M_trip . M_badDigit
• M_set . M_trip . M_goodDigit
• M_set . M_trip . M_goodDigit . M_goodDigit
• M_set . M_goodDigit . M_goodDigit

118

Input Sequence
119

• no stimulus These are so-called

“canonical” sequences.
• M_set Append any (legal) stimulus to
• M_set . M_trip any of these sequences and you
• M_set . M_badDigit get one of these sequences
as a result.
• M_set . M_goodDigit
• M_set . M_trip . M_badDigit
• M_set . M_trip . M_goodDigit
• M_set . M_trip . M_goodDigit . M_goodDigit
• M_set . M_goodDigit . M_goodDigit

For example: M_set . M_badDigit . M_clear = M_set

(What about M_set . M_goodDigit . M_clear?

119

60
 So how did that help us?
120

• We now assign response values for each one of these canonical

sequences.

• Why does that help?

120

So how did that help us?

121

• We now assign response values for each one of these canonical

sequences.

• Why does that help?

• Because now, for any sequence of stimuli, we know what the response
should be.

121

61
 Responses
122

c_alarmSound c_backlight
no stimulus e_off e_off
M_set e_off e_on
M_set . M_trip e_on e_on
M_set . M_badDigit e_off e_on
M_set . M_goodDigit e_off e_on
M_set . M_trip . M_badDigit e_on e_on
M_set . M_trip . M_goodDigit e_on e_on
M_set . M_trip . M_goodDigit . M_goodDigit e_on e_on
M_set . M_goodDigit . M_goodDigit e_off e_on

Is that now sufficient to specify the required behaviour?

122

Responses
123

c_alarmSound c_backlight
no stimulus e_off e_off
M_set e_off e_on
M_set . M_trip e_on e_on
M_set . M_badDigit e_off e_on
M_set . M_goodDigit e_off e_on
M_set . M_trip . M_badDigit e_on e_on
M_set . M_trip . M_goodDigit e_on e_on
M_set . M_trip . M_goodDigit . M_goodDigit e_on e_on
M_set . M_goodDigit . M_goodDigit e_off e_on

Is that now sufficient to specify the required behaviour?

No - we need to show effect of any new stimulus! How?

123

62
 Responses
124

c_alarmSound c_backlight
no stimulus e_off e_off
M_set e_off e_on
M_set . M_trip e_on e_on
M_set . M_badDigit e_off e_on
M_set . M_goodDigit e_off e_on
M_set . M_trip . M_badDigit e_on e_on
M_set . M_trip . M_goodDigit e_on e_on
M_set . M_trip . M_goodDigit . M_goodDigit e_on e_on
M_set . M_goodDigit . M_goodDigit e_off e_on

Is that now sufficient to specify the required behaviour?

No – we need to show effect of any new stimulus! How?

One way: show current “state” & effect of each stimulus (try it)

124

Effect of each stimulus

125

Notation: Sequence Name (represents a state)

Behaviour (effect): Current state

Current stimulus

New state shown in the cells. - means no change

125

63
 Questions
126

• Why did we use M_, c_, e_ etc in our notation?

• Does it make sense to have M_badDigit and M_goodDigit as our

stimuli?

• How does the sensor value that detects motion get into our software?

• How about the “secret” code to switch off the device or alarm sound?
How is it conveyed to the device?

126

Notation
127

• We already saw Parnas and Madey’s 4 variable model that describes

how requirements are related to the software design. We call stimuli
“monitored variables”, and responses “controlled variables”.

• Our notation simply uses prefixes to describe the “kind” of identifier,

hence
 M_ or m_ for monitored variables (M_ for time discrete, m_ for time continuous),
 C_ or c_ for controlled variables, etc.
 e_ is used for enumerated tokens (think “enum” in C, C# etc)

127

64
 M_badDigit & M_goodDigit
128

• It does not make sense to use M_badDigit and M_goodDigit as

monitored variables. Why not?

128

M_badDigit & M_goodDigit

129

• It does not make sense to use M_badDigit and M_goodDigit as

monitored variables. Why not?
 They are not really monitored variables

 The true monitored variables are the digits ‘1’, ‘5’ etc

 We used M_badDigit and M_goodDigit because it simplified our description

 We should now determine how to “derive” badDigit and goodDigit given a monitored
variable M_digit for instance, where M_digit is one of ‘1’, ‘2’, ‘3’, ‘4’, ‘5’, ‘6’, ‘7’, ‘8’,
‘9’, ‘0’

129

65
 Determining badDigit & goodDigit
130

• Given that the system knows the secret code (assume a string
of 3 characters called secretCode):

• Assume we know M_digit represents c (a character)

which leads us to …

130

Determining badDigit & goodDigit

131

• So, for current state, given c from M_digit:

• One way to do this is to make a different monitored variable for each

digit, eg
M_one == > c = ‘1’, etc

131

66
 M_trip
132

• In a real device, there would be hardware that detects motion and then
an interface to the software that delivers the value (in this case just the
equivalent of a boolean) so that the software can work with it

• In our case, we will just make a button that the user can click to trigger
M_trip

• Think back to hardware hiding and the modified 4 variable model. Do

we need to consider this here?

132

The Secret Code

133

• There are many ways of entering the secret code

• To start, let us modify the requirements just a little, to say that a string
of 3 characters (numeric only) must be entered when the Set button is
pressed. Therefore, pressing the Set button will result in entering the
secret code and then switching the device on

• In a later version we will modify the requirements to make the

behaviour more realistic – the Set button will have 2 modes: Set and
Code. Set will start the device. Code will let the user enter the secret
code by pressing the digit buttons

133

67
 Anything Else?
134

• Have we coped with everything?

134

Anything Else?
135

• Have we coped with everything?

• No. We need some way of showing that the alarm is sounding

• At this stage, we will simply have a red area on the form to indicate the
alarm is sounding

• Later we could add sound …

135

68
 Using digits to enter secret code
136

• M_mode . M_digit(c0) . M_digit(c1) . M_digit(c2) 

M_set, secretCode = c0+c1+c2

• Replace M_set by M_mode in transition table

136

CAS Super Alarm in Visual Studio

137

Initial state

137

69
 CAS Super Alarm in Visual Studio
138

Entering the
secret code

138

CAS Super Alarm in Visual Studio

139

Device active

139

70
 CAS Super Alarm in Visual Studio
140

Alarm sounding
after Trip was
pressed

140

CAS Super Alarm in Visual Studio

141

• First attempt
 Use M_goodDigit and M_badDigit as inputs to the class that you create to
implement the CAS alarm.

 Use a textbox on the form to input the secret code – shown in the next slide. After
user enters the code, pressing “NEXT” will check that the code is legal. If yes it
starts the alarm device. If not, clears textbox and user tries again. (Display an
appropriate error message.)

141

71
 CAS Super Alarm in Visual Studio
142

• Now try the same thing but without making a textbox for the secret
code.

• This time:
 User presses “SET”, enters a mode where we can set the secret code.

 Button label changes to “CODE”.

 Next 3 digits pressed define the secret code.

 After the 3rd one is pressed, button changes to “SET” and is backlit in yellow.

• Also, use M_one, M_two etc as the variables input to the CAS alarm
class.

142

Requirements
143

143

72
 Summary: Requirements
(not much on Validation) 144

• Importance of requirements

• Natural language requirements & their pitfalls

• Brief introduction to formal requirements

• Tabular expressions

• 4 Variable model and the Modified 4 variable model

• An example (alarm system)

• Timing requirements

144

DESIGN
145

• Focus on software design and MDE techniques

• Include a discussion on system design at the end of the Design

content

145

73
 Software Architecture & Design
146

• What is design?

• How can a system be decomposed into modules?

• What is a module’s interface?

• What are the main relationships among modules?

• Prominent software design techniques and information

hiding

• Design notations

146

What is design?
147

• Provides structure to any artifact

• Decomposes system into parts (Structure), assigns responsibilities

(Behavior), ensures that parts fit together to achieve a global goal
(Interactions)
 Often, but not always the global goal will come from the specifications/requirements
for the system

• Design refers to both an activity and the result of the activity

147

74
 Two meanings of “design”
activity in our context 148

• Activity that acts as a bridge between requirements and the

implementation of the software

• Activity that gives a structure to the artifact

 e.g., a requirements specification document must be designed
• must be given a structure that makes it easy to understand and evolve

148

Two meanings of “design”

activity in our context 149

• Activity that gives a structure to the artifact

Requirements
SDD
Decomposed so
Decomposed so
domain experts
software will be
can read &
structured for
understand it
easy maintenance
easily

149

75
 The sw design activity
150

• Defined as system decomposition into modules

• Produces a Software Design Document

 describes system decomposition into modules

• Often a software architecture is produced prior to a software design

150

Software Architecture
151

• Shows gross structure and organization of the system to be

defined

• Its description includes description of

 main components of a system

 relationships among those components

 rationale for decomposition into its components

 constraints that must be respected by any design of the components

• Guides the development of the design

151

76
 Two important goals
152

• Design for change (Parnas)

 designers tend to concentrate on current needs

 special effort needed to anticipate likely changes

• Product families (Parnas) (now called “product lines”)

 think of the current system under design as a member of a program family

152

Module
153

• A well-defined component of a software system

• A part of a system that provides a set of services to other modules

 Services are computational elements that other modules may use

• A work assignment (Parnas)

153

77
 Modularity
154

• A complex system may be divided into simpler pieces called modules

• A system that is composed of modules is called modular

• Supports application of separation of concerns

 when dealing with a specific module we want to be able to ignore details of other
modules

154

Questions
155

• How to define the structure of a modular system?

• What are the desirable properties of that structure?

155

78
 Unified Modeling Language
156

156

Class Diagrams
157

• Class diagram
represents a software
entity
• A class is made of 3
parts:
 Name
 Attributes
[represents state]
 Methods [describes
behavior]

157

79
 Class Diagrams
158

• Visibility:
 + public: can be accessed by any
other class
 - private: access only within the
object permitted
 # protected: access by objects within
the same class and subclasses
permitted
 ~ friendly: access by objects within
the same package

• Attribute:
 Visibility name: type [multiplicity]

• Method:
 Visibility name (parameters): return
type

158

Class Diagrams
159

159

80
 Class Diagrams
160

• 5 types of references:
 Association

 Aggregation (sort of)

• Special type of association
• Think of it as a ‘part of’

 Composition
• Think of it as ownership (black
diamond owns the opposite end)
• Class on left is deleted, class on
right also deleted

160

Class Diagrams
161

• 5 types of references cont’d:

 Inheritance
• Inherits all the properties
from the white arrow

 Interface
• Needs the white arrow
class to be used by other
entities
• Can be thought of as ‘uses’

161

81
 Class Diagrams
162

162

State Machine Diagrams

163

163

82
 State Machine Diagrams
164

• Also referred to as Finite State Machines (FSM)

• Typically composed of a tuple <S, A, T>

 S: a finite set of States

 A: a finite set of Actions

 T: a transition relation where

• Typically FSM will have one initial state where everything starts

164

State Machine Diagrams

165

• Simulink example, notice the

initial state in the top state
• Every state has actions to
execute
• Transitions can have timing
conditions or other Boolean
conditions
• Transitions can also have
actions to complete during
transition (not common or
recommended for beginners)

165

83
 Sequence Diagrams
166

166

Sequence Diagrams
167

• Still a part of describing behavior of a system, but specialized for

interactions.

• Interactions can be everything from component interactions to user

interactions

• Models a system by considering:

 Entities

 Message exchanges between entities

167

84
 Sequence Diagrams
168

168

Sequence Diagrams
169

169

85
 Sequence Diagrams
170

170

Sequence Diagrams
171

171

86
 Sequence Diagrams
172

172

Sequence Diagrams
173

173

87
 Sequence Diagrams
174

174

Sequence Diagrams
175

175

88
 Sequence Diagrams
176

176

Sequence Diagrams
177

177

89
 Sequence Diagrams
178

178

Sequence Diagrams
179

179

90
 Sequence Diagrams
180

180

Relations 181

A hierarchy in a graph is a DAG (directed acyclic graph)

a graph

a DAG

181

91
 The USES Relation
182

• A uses B

 A requires the correct operation of B

 A can access the services exported by B through its interface

 it is “statically” defined

 A depends on B to provide services “promised” by A

• example: A calls a routine exported by B

• A is a client of B; B is a server

182

Desirable property
183

• USES should be a hierarchy

• Hierarchies make software easier to understand

 we can proceed from leaf nodes (who do not use others) upwards

• They make software easier to build

• They make software easier to test

• Not the only form of hierarchy in software…

183

92
 Other hierarchies
184

• Composition hierarchy
 Important to remember what modules are owned by others

 Allows for encapsulation, enables easier information hiding

• Inheritance hierarchy
 When you inherit from another class, you inherit everything

 Includes properties of a class that you might not want

 Often end up with a lot of bloat in the classes when too much is inherited

184

Cohesion and Coupling

185

• Each module should be highly cohesive

 module understandable as a meaningful unit

 Components of a module are closely related to one another

• Modules should exhibit low coupling

 modules have low interactions with others

 understandable separately

185

93
 Cohesion and Coupling
Visually 186

We can evaluate coupling from an external view (”uses”), but

need to see internal details to judge cohesion

(a)(b)

Usually an
indication of
reasonable
cohesion
high coupling low coupling

186

Module Decomposition (Parnas)

187

Conceptual App
modules

H/W S/W Behav.

hiding decision hiding

Leaf modules
contain
code

187

94
 Module Fundamentals
188

Name
Interface
Types
Constants
Access programs

188

Module Fundamentals
189

Name
Interface
Types
Constants
Access programs
Hidden
from Implementation
everyone Types
other Constants
than the Variables
designers
of the Details of access programs &
module local programs

189

95
 Module Fundamentals
190

Module A Module B
int getS1 int getV
int getS2 setValue(int n)
setValues(int v1,v2)

int S1, S2 int V

…. ….
setValues(int v1,v2) setValue(int n)
… …
q = B.getV V=n
S1 = v1
S2 = v2*q

190

Interface vs.
Implementation (1) 191

• To understand the nature of USES, we need to know what a used

module exports through its interface

• The client imports the resources that are exported by its servers

• Modules implement the exported resources

• Implementation is hidden to clients

191

96
 Interface vs.
Implementation (2) 192

• Clear distinction between interface and implementation is a key design

principle

• Supports separation of concerns

 clients care about resources exported from servers

 servers care about implementation

• Interface acts as a contract between a module and its clients

192

Interface vs.
Implementation (3) 193

interface is like the tip of the iceberg

193

97
 Interface vs.
Implementation (3) 194

interface is like the tip of the iceberg

- need to include “effects” as well

194

Interface vs.
Implementation (4) 195

• To describe the interface, we need to describe the relationship

between outputs (responses) and inputs (stimuli).

• There are lots of different ways of doing this, ranging from natural
language to formal notations – we will look at some of them briefly later
in the course

195

98
 Information Hiding
196

• Basis for design (i.e. module decomposition)

• Implementation secrets are hidden to clients

• They can be changed freely if the change does not affect the interface

• Golden design principle

 INFORMATION HIDING

• Encapsulate changeable (requirements &) design decisions as

implementation secrets within module implementations

196

Information Hiding
197

• Can you think of changes that may be likely in these areas?

• Hardware

• Behaviour

• Design decisions

Remember – changes may be in requirements or in design decisions

197

99
 Information Hiding
198

• Can you think of changes that may be likely in these areas?

• Hardware
 Sensors, input devices, actuators, output devices, floating point accelerators, the
computer platform/micro-controller

• Behaviour
 Number of items, algorithm, timing behaviour,

• Design decisions
 Data structures, algorithm, computer platform,

Remember – changes may be in requirements or in design decisions

198

Information Hiding
199

• Things to do:

 Make a list of anticipated changes while preparing requirements

 Make a list of changes that are not likely while preparing requirements (why?)
 For each likely change, decide on the “secret” you want to hide and document it
 As you finalize requirements and start design, update the above lists
 Apply information hiding principle in developing the design
 At the end of design make sure list is accurate
 At the end of the design “test” how well you have done with respect to
information hiding

199

100
 Interface Design
200

• Interface should not reveal what we expect may change later

• It should not reveal unnecessary details

• Interface acts as a firewall preventing access to hidden parts

• Interface should not expose internal data structures

200

Prototyping
201

• Once an interface is defined, implementation can be done

 first quickly but inefficiently (why?)

 then progressively turned into the final version

• Initial version acts as a prototype that evolves into the final product

201

101
 Design frameworks/notations
202

• Notations allow designs to be described precisely

• They can be textual or graphic

• We illustrate a sample framework/notation

 Parnas’ Rational Design Process (RDP) has 3 major components

Module Guide (MG), Module Interface Specification (MIS), and the
Module Internal Design (MID)

202

RDP - Module Guide

203

• When decomposing the system into modules (as per earlier

discussions), we need to document the module decomposition
so that the developers and other readers can understand the
decomposition

• Parnas proposed a Module Guide (MG) based on the

decomposition module tree shown earlier

203

102
 RDP - MG
204

• The MG consists of a table that documents each module’s

responsibility and secret

• Conceptual modules will have broader responsibilities and secrets

• The leaf modules that represent code will contain much more precise
responsibilities and secrets

204

RDP - MG Example
205

# Name Responsibility Secret

… … … …

1.3 AIs Interface with the A/I Hardware representation

hardware to produce of data & how to get data
software variables that from hardware
represent the field data
1.3.1 FlowSensors Software representation Relationship between
of flow measurements physical flow and software
representation
… … … …

205

103
 Example Overview of a MG
206

ID NAME RESPONSIBILITY SECRET

1 App Entire system All secrets
1.1 H/W hiding All hardware related behaviour List of h/w secrets
1.1.1 Analog input class 1 Behaviour for all analog I/O Secret for class 1
1.1.2 Digital I/O Behaviour for all digital I/O List of secrets
1.1.2.1 Digital inputs class 2 Behaviour for all digital inputs Secret for class 2
1.1.2.2 Digital outputs class 3 Behaviour for all digital outputs Secret for class 3
1.2 S/W decisions All behaviour for s/w decisions List of secrets
1.2.1 S/W decision class 4 Behaviour for class 4 Secret for class 4
1.2.2 S/W decision class 5 Behaviour for class 5 Secret for class 5
1.3 Behaviour hiding Most of the normal behaviour List of secrets
1.3.1 … … …
1.3.2 Behaviour class 6 Behaviour for that class Secret for class 6
1.3.3 Behaviour class 7 Behaviour for that class Secret for class 7
1.3.1.1 Behaviour class 8 Behaviour for that class Secret for class 8
1.3.1.2 Behaviour class 9 Behaviour for that class Secret for class 9
1.3.1.3 Behaviour class 10 Behaviour for that class Secret for class 10

206

RDP - MIS
207

• For each leaf module we need to document its interface and its
implementation.

• In RDP, the interfaces are documented in the Module Interface

Specification (MIS).

• We would aim to use some form of mathematical approach to

specify the MIS behaviour - as black-box as possible.

207

104
 MIS
208

• My opinion – MIS is the most important entity in your software design

• Describes what the interface to your class is – both syntax and

semantics

• List of items with parameters is the syntax

• Description of behaviour of each method is the semantics

 For each method describe the value of the outputs as they depend on the inputs

208

RDP - Views
209

• As well as the MG, the modular decomposition should be

displayed using a variety of views.

• An obvious one is a “Uses Hierarchy” - which can be formed

once the MIS for all modules is complete. It is not always
obvious how to achieve this - for complex systems graphical
representations are not successful without good tool support.

209

105
 RDP - MID
210

• Finally, we can document the Module Internal Design (MID) for

each module.

• This provides the implementation of the module, i.e. how we

deliver on what we promised in the MIS.

• The more complete this is, the better.

• But - it represents a requirement for the coder - so it is better

represented at a higher level of abstraction than the code.

210

RDP - Module Documents

211

• MG - shows module decomposition

• Uses hierarchy (produced after all MIS)

• Module Design for each module

 MIS
 MID

211

106
 Documentation of Modules 212

Note: in OOP
“modules” are Individual designers
“classes” and Program n+m Name

“access
programs” are ...
Interface design team
“methods”
Available to all designers
Program 2 Name
We will compare Defines design tasks for
module designers
modules and
classes later on, Program 1 Name

but this picture

would not change Module Internal Declarations
for classes Internal Constants
Module Cover Page Internal Types
State Data

Module Name & Number

Responsibility
System Inputs
System Outputs Module
Module
Export Constants
Export Types
Local Program 1 Name
Parameters
Description
Internal
Interface
Access Program 1 Name
Parameters
Description
References
...
Local Program m Name
Design
References Parameters

Spec ...
Access Program n Name
Parameters
Description
References

Description Module design team

References Available to module designers

212

How Can You Evaluate Your

Software Design? 213

• Complete
 Every software requirement is implemented in the design
 Functions are complete on their input domains
• Correct
 Every software requirement is correctly implemented – within tolerance
• Structure
 USES relationship is a hierarchy
 Modules (classes) exhibit low coupling and high cohesion
 Interfaces do not include state variables
 Interfaces do not disclose secrets
 MIS and MID are adequate requirements for the implementation
 The MID of a USED module is not required to design the internal of the module that
USES it
• Maintenance
 A list of likely requirements & design changes is provided
 Secrets are documented in the MG
 Each secret is encapsulated in a module

213

107
 System Design
214

• We need a brief overview of

 System Requirements

 System Design

 And how System Design can contain the Software Requirements

214

System Requirements - Review

215

What we want to do is specify REQ in terms of

NAT C and M without any intermediate
functions. This would give us a black-box
description of the required behaviour.
M REQ C

NAT
However, that is almost always not
possible. The behaviour is too complex to
describe it in a single function/relation.
So, we use intermediate functions to M C
describe behaviours that still make sense
to the domain expert, and the overall
behaviour is given by the composition of
those functions.

215

108
 System Design – Overview
216

Once we have the behaviour specified in the system requirements, we can

partition the behaviour into hardware and software functions. In most cases,
the hardware components will represent sensors and actuators and associated
hardware represented by IN and OUT in the 4 variable model*.
In a few cases, a
hardware component
may perform actual ✪
functional
* *
behaviour✪.
The software M * C
functions in the
* *
system design can be
used to specify the
software *
requirements – if they
are described
adequately in the Hardware Software
functions functions
system design.

216

System Design - Overview

217

Once we have the behaviour specified in the system requirements, we can

partition the behaviour into hardware and software functions. In most cases,
the hardware components will represent sensors and actuators and associated
hardware represented by IN and OUT in the 4 variable model.

The hardware
functions that M C
represent IN and
OUT must be
described by M-I
and O-C mappings.

Hardware described Hardware Software Hardware described

by M-I mappings functions functions by O-C mappings

217

109
 Traditional Modules vs Classes
218

• Older design paradigms and coding languages used coding units which
were procedural abstractions – they encapsulated a series of program
steps so that they could be used over-and-over. Sometimes those steps
returned values calculated in that unit much like a mathematical
function, and sometimes they did not. In older languages like FORTRAN
they were called functions (returned a value associated with the name
of the function) or procedures (did not return a value, or returned values
associated with variables in the parameter list)

• An example you may be familiar with is the c language

• int simple(int n) returns an integer value associated with the
name simple, given an integer value for n
• void simplest() returns nothing, just performs steps inside simpler
• int add1(int a, int b) returns an integer using input integers a
and b
• void add2(int a, int b, int *c) returns an integer value
called c using integer inputs a and b
218

Traditional Modules vs Classes

219

• Moving on from procedural abstractions we arrived at modules

• This was a huge move forward to providing structures that we can use
to put together procedural abstractions together with data that they
operate on, all in one package

• These are the modules we described in the earlier parts of these

notes. These modules are excellent for implementing information
hiding. However, they have one (sometimes serious) limitation – we
can implement only one module!
 So, if we make a module that implements an integer stack, called INTSTACK, for
example, if we actually need 2 stacks we would have to copy the definition of
INTSTACK, and call it INTSTACK2 for instance

• So, Object Oriented Design and Object Oriented Programming (OOP)

paradigms solve this problem

219

110
 Abstract data types (ADTs)
220

• A stack ADT
indicates that details of the data
structure are hidden to clients. A clumsy
way of doing it, not necessary in OOP
module STACK_HANDLER
exports
type STACK = ?;
This is an abstract data-type module; the data structure
is a secret hidden in the implementation part.
procedure PUSH (S: in out STACK ; VAL: in integer);
procedure POP (S: in out STACK ; VAL: out integer);
function EMPTY (S: in STACK) : BOOLEAN;
.
.
.
end STACK_HANDLER

220

Object-oriented design
221

• One kind of module, ADT, called class

• A class exports operations (procedures) to manipulate instance objects
 often called methods
• Instance objects are accessible via references

• You can think of it this way: “Class” acts as a kind of Type, and
Objects of the Class are really variables of that Type

• So, if we have Class STACK, with method push(int v), then we can
instantiate 2 objects of stacks, by
STACK S1, S2;
And
S1.push(3); S2.push(6);
pushes the number 3 onto stack S1 and pushes 6 onto stack S2. These
stacks are completely independent – they have their own storage areas

221

111
 Syntactic changes in OOP
222

• No need to export opaque types

 class name used to declare objects

• If a is a reference to an object
 a.op (params);

222

A further relation- inheritance

223

• Classes may be organized in a hierarchical structure

• Class B may specialize class A

 B inherits from A
conversely, A generalizes B

• A is a superclass of B

• B is a subclass of A

223

112
 An example - 1
224

224

An example - 2
225

225

113
 Inheritance
226

• A way of building software incrementally

• A subclass defines a subtype

 subtype is substitutable for parent type

• Polymorphism
 a variable referring to type A can refer to an object of type B if B is a subclass
of A

• Dynamic binding
 the method invoked through a reference depends on the type of the object
associated with the reference at runtime

226

Notation & Documentation

for the MIS 227

• The MIS can be documented in natural language or formally – but the

important thing is that it must be documented so that both syntax and
semantics are specified

• Essentials

 Overview of services provided by the module

 Syntax of the interface (exported types, constants and access programs)

 Explanations of types and constants

 For each access program, description of its black-box behaviour, not how it is
implemented. Assumptions and limitations must also be described. An excellent
way of describing black-box behaviour of the access program is to describe the
relation between outputs and inputs of the program

227

114
 Classification of specification
styles 228

• Informal, semi-formal, formal

• Operational
 Behavior specification in terms of some abstract machine

• Descriptive
 Behavior described in terms of properties

228

Example 1 229

• Specification of a geometric figure E:

E can be drawn as follows:

1. Select two points P1 and P2 on a plane
2. Get a string of a certain length and fix its ends to P1 and
P2
3. Position a pencil as shown in next figure
4. Move the pen clockwise, keeping the string tightly
stretched, until you reach the point where you started
drawing

this is an operational specification

229

115
 Example 1 230

P
1 P
2

Implementing the specification of a circle

230

A descriptive specification
231

• Geometric figure E is describe by the following equation

ax2 + by2 + c = 0
where a, b, and c are suitable constants

231

116
 Example 2 232

“Let a be an array of n elements. The result of its sorting is an

array b of n elements such that the first element of b is the
OP minimum of a (if several elements of a have the same value, any
one of them is acceptable); the second element of b is the
minimum of the array of n-1 elements obtained from a by
removing its minimum element; and so on until all n elements of
a have been removed.”

“The result of sorting array a is an array b which is a permutation

DES of a and is sorted.”

232

Data Flow Diagrams- (DFDs) 233

• A semi-formal operational specification

• System viewed as collection of data manipulated by “functions”

• Data can be persistent

 they are stored in data repositories

• Data can flow

 they are represented by data flows

• DFDs have a graphical notation

233

117
 DFDs - Graphical notation
234

 bubbles represent functions

 arcs represent data flows
 open boxes represent persistent store
 closed boxes represent I/O interaction

234

DFD Example
235

b a d
c
specifies evaluation of
+ * +
(a + b) * (c + a * d)

235

118
 An evaluation of DFDs - 1
236

• Easy to read, but …

• Informal semantics
 How to define leaf functions?
 Inherent ambiguities

• Outputs from A, B, C
are all needed?
• Outputs for E and F
are produced at the
same time?

236

An evaluation of DFDs - 2
237

• Control information is absent

Possible interpretations:
(a) A produces datum, waits until B consumes it
(b) B can read the datum many times without
consuming it
(c) a pipe is inserted between A and B

237

119
 Formalization/extensions 238

• There have been attempts to formalize DFDs

• There have been attempts to extend DFDs (e.g., for real-time
systems)

238

UML use-case diagrams

239

• Define functions on basis of actors and actions

borrow
book

return
book librarian
customer
library
update

239

120
 Finite state machines again 240

• Can specify control flow aspects

• Defined as
a finite set of states, Q;
a finite set of inputs, I;
a transition function d : Q x I  Q
(d can be a partial function)

State Transition
Diagram

240

Finite state machines - 2 241

q0 q1 q2 q3
a q1 q2 - -
b - q3 q3 -
c - - - q0
State Transition
Table

241

121
 Finite state machines - 2 242

q0 q1 q2 q3
a q1 q2 - -
b - q3 q3 -
c - - - q0
State Transition
Table

Cannot occur simultaneously

242

FSM Limitations
243

• Finite memory

• State explosion
 Given a number of FSMs with k1, k2, … kn states, their composition is a FSM with k1
* k2 *… * kn. This growth is exponential with the number of FSMs, not linear (we
would like it to be k1 + k2 +… + kn )

243

122
 Mills’ Black-Box
244

Mills, H.D.: Stepwise

refinement and
S1-1 S1
verification in box- R1 R1 -1
structured systems. S2-1 S2S2
-1

Computer 21 (1988) S3-1 S3 R2 R2 -1

23-36

System

R = f ( S, Sh )
S is the set of stimuli, Sh the set of
stimulus history, R the set of responses

244

Logic specifications
245

Examples of first-order theory (FOT) formulas:

• x > y and y > z implies x > z

• x=yy=x

• for all x, y, z (x > y and y > z implies x > z)

• x+1<x–1

• for all x (exists y (y = x + z))

• x > 3 or x < -6

Note: there are lots of different logic notations – do not be intimidated

just because the notations may look unfamiliar to you

245

123
 Logic specifications
246

Examples of first-order theory (FOT) formulas – different notation:

• (x > y) ∧ (y > z) ⟹ x > z

• x=yy=x

• ∀ (x, y, z) ((x > y) ∧ (y > z) ⟹ x > z)

• x+1<x–1

• ∀ (x) (∃ (y) | (y = x + z))

• (x > 3) ∨ (x < -6)

Note: there are lots of different logic notations – do not be intimidated

just because the notations may look unfamiliar to you

246

Specifying complete programs

247

A property, or requirement, for P is specified as

a formula of the type

{Pre (i1, i2,..., in) }

P
{Post (o1, o2,..., om, i1, i2,..., in)}

Pre: precondition
Post: postcondition

247

124
 Example - 1
248

• Division

{exists z(i1 = z * i2)}

P
{o1 = i1 / i2}

248

Example - 2
249

• Division - a “stronger” requirement

{i1 > i2 > 0}

P
{i1 = i2 * o1 and o1 ³ 0 and o1 < i2}

249

125
 Example - 3
250

• Program to compute greatest common divisor

{i1 > 0 and i2 > 0}

P
{(exists z1, z2 (i1 = o * z1 and i2 = o * z2)) and
not (exists h
(exists z1, z2 (i1 = h * z1 and i2 = h * z2) and h > o))}

250

Specifying procedures
251

 {n > 0} -- n is a constant value

procedure search (table: in integer_array; n: in integer;
element: in integer; found: out Boolean);
{found  (exists i (1  i  n and table (i) = element))}

 {n > 0 }
procedure reverse (a: in out integer_array; n: in integer);
{for all i (1 i  n) implies (a’(i) = ‘a(n - i +1))}

where ‘x means value of x on entry to procedure, x’ means value of x

on exit of procedure

251

126
 Specifying classes - 1
252

• Invariant predicates and pre/post conditions for each method

• Example of invariant specifying an array, IMPL, used to

implement an abstract data type SET

for all i, j (1  i  length and 1  j  length and i≠j)

implies IMPL[i]≠IMPL[j]
(no duplicates are stored)

252

Specifying classes - 2
253

• In general, for every operation (op) in the class:

{Invariant and pre-conditions}

Program for op
{Invariant and post-conditions}

• In the OO world we also have to worry about object initialization,

i.e. the constructor (cstr), so we also need
{true} Program for cstr {Invariant}

253

127
 Specifying classes - 3
254

Consider the earlier example where a class represents the abstract

data type SET, and is implemented using the array IMPL of size
length. An invariant was given earlier. Now consider what we
would specify for an operation DELETE which removes an element
x from SET.

{exists i (1  i  length) and IMPL[i] = x}

DELETE(x IN integer)
{for all i (1  i  length’ implies IMPL’[i] ≠ x) and
for all i ((1  i  ‘length and ‘IMPL[i] ≠ x) implies
exists j (1  j  length’ and IMPL’[j] = ‘IMPL[i]))}

254

Advantage of Function Tables

255

• Tabular expressions describe relations through pre and post

conditions - ideal for describing behaviour without sequences of
operations

• They make it easy to ensure input domain coverage

• They are easy to read and understand (you need just a little
practice to write them)

• Coding from tables results in extremely well structured code

• They facilitate identification of test cases

• Extremely good for real-time/embedded systems

255

128
 Disadvantage of Fn Tables
256

• We don’t know of any way of using tabular expressions to describe

typical algorithms. For example, how could we use a table to describe
the Gauss Elimination algorithm?

• As yet, we don’t know how to use tables to document the requirements

for a GUI, etc.

256

Aside: Events vs Conditions

257

• Events can be viewed as “pulses” in time - they do not last (retain their
values) – we have referred to this as “time-discrete”

event

time

• Conditions may retain their values indefinitely – we have referred to

this as ”time-continuous”

True condition
False
time

257

129
 VERIFICATION
258

• Why we do it

• How we do it

• How successful we can expect it to be

258

Outline 259

• What are the goals of verification?

• What are the main approaches to verification?

 What kind of assurance do we get through testing?
 How can testing be done systematically?
 How can we remove defects (debugging)?

• What are the main approaches to software analysis?

 informal vs. formal

259

130
 Need for verification
260

• Designers are fallible even if they are skilled and follow sound
principles

• Everything must be verified, every required quality, process and

products

 even verification itself…

260

Properties of verification
261

• May not be binary (OK, not OK)

 severity of defect is important

 some defects may be tolerated

• May be subjective or objective

 e.g., usability

• Even implicit qualities should be verified

 because requirements are often incomplete

 e.g., robustness

261

131
 Approaches to verification
262

• Experiment with behavior of product

 sample behaviors via testing

 goal is to find "counterexamples"

 dynamic technique

• Analyze product to deduce its adequacy

 analytic study of properties

 static technique

262

Testing and lack of "continuity"

263

• Testing samples behaviors by examining "test cases"

• Impossible to extrapolate behavior of software from a finite set

of test cases

• No continuity of behavior

 it can exhibit correct behavior in infinitely many cases, but may still be
incorrect in some cases

 We discussed this earlier in what makes software challenging

263

132
 Goals of testing
264

• To show the presence of bugs (Dijkstra, 1987)

• If tests do detect failures, we cannot conclude that software is defect-

free

• Still, we need to do testing

 driven by sound and systematic principles

264

Goals of testing (cont.)

265

• Should help isolate errors

 to facilitate debugging

• Should be repeatable
 repeating the same experiment, we should get the same results

• this may not be true because of the effect of execution environment on testing

• because of non-determinism

• Should be accurate

265

133
 Definitions (1)
266

• P (program), D (input domain), R (output domain)

 P: D  R (may be partial)

• Correctness defined by OR  D  R

 P(d) correct if <d, P(d)>  OR

 P correct if all P(d) are correct

266

Definitions (2)
267

• FAILURE
 P(d) is not correct

• may be undefined (error state) or may be the wrong result

• ERROR (DEFECT)
 anything that may cause a failure

• typing mistake

• programmer forgot to test “x = 0”

• FAULT
 incorrect intermediate state entered by program

Note: these are not universal definitions – lots of variations

267

134
 Definitions (3) 268

• Test case t
– an element of D

• Test set T
– a finite subset of D

• Test is successful if P(t) is correct

• Test set successful if P correct for all t in T

268

Definitions (4)
269

• Ideal test set T

 if P is incorrect, there is an element of T such that P(d) is incorrect

• if an ideal test set exists for any program, we could prove program
correctness by testing

269

135
 Test criterion
270

• A criterion C defines finite subsets of D (test sets)

 C  2D

• A test set T satisfies C if it is an element of C

Example
C = {<x1, x2,..., xn> | n ³ 3   i, j, k, ( xi<0  xj=0  xk>0)}
<-5, 0, 22> is a test set that satisfies C
<-10, 2, 8, 33, 0, -19> also does
<1, 3, 99> does not

270

Properties of criteria
271

• C is consistent
 for any pairs T1, T2 satisfying C, T1 is successful iff T2 is successful

• so either of them provides the “same” information

• C is complete
 if P is incorrect, there is a test set T of C that is not successful

• C is complete and consistent

 would identify an ideal test set

 would allow correctness to be proved!

271

136
 Properties of criteria
272

• C is consistent
 for any pairs T1, T2 satisfying C, T1 is successful iff T2 is successful

• so either of them provides the “same” information

• C is complete
 if P is incorrect, there is a test set T of C that is not successful

• C is complete and consistent – wishful thinking

 would identify an ideal test set

 would allow correctness to be proved!

272

Properties of definitions
273

• There is no algorithm to derive a test set that would prove program

correctness

 there is no constructive criterion that is consistent and complete

273

137
 Empirical testing principles
274

• Attempted compromise between the impossible and the

inadequate

• Find strategy to select significant test cases

 Significant = has high potential of uncovering presence of error

274

Complete-Coverage Principle
275

• Try to group elements of D into subdomains D1, D2, …, Dn where any

element of each Di is likely to have similar behavior
 D = D1  D2 …  Dn

• Select one test as a representative of the subdomain

• If Dj  Dk =  for all j ¹ k, (partition), any element can be chosen from

each subdomain

• Otherwise choose representatives to minimize number of tests, yet

fulfilling the principle

275

138
 Complete-Coverage Principle
276

example of a partition

276

Testing in the small (unit testing)

277

• We test individual modules

• BLACK BOX (functional) testing

 partitioning criteria based on the module’s specification

• WHITE BOX (structural) testing

 partitioning criteria based on module’s internal code

• In both cases, expected value of each test is based on the

module’s specification

277

139
 White Box Testing
278

Derive test cases from code (implementation)

From code
From spec
From code

Id Test case (inputs) Expected Result Observed Result Pass/Fail

Pass if observed
result matches
expected result
within expected
tolerance –
otherwise Fail

278

Structural Coverage Testing

279

• (In)adequacy criteria

 If significant parts of program structure are not tested, testing is inadequate

• Control flow coverage criteria

 Statement coverage

 Edge coverage

 Condition coverage

 Path coverage

279

140
 Statement-coverage criterion
280

• Select a test set T such that every elementary statement in P

is executed at least once by some d in T

 an input datum executes many statements  try to minimize the

number of test cases still preserving the desired coverage

280

Example 281

read (x); read (y); {<x = 2, y = -3>, <x = - 13, y = 51>,

if x > 0 then write ("1"); <x = 97, y = 17>, <x = - 1, y = - 1>}
else write ("2"); covers all statements
end if;
if y > 0 then write ("3"); {<x = - 13, y = 51>, <x = 2, y = - 3>}
else write ("4"); is minimal
end if;

281

141
 Weakness of the criterion
282

if x < 0 then x := -x; {<x = -3} covers all

end if; statements
z := x;
it does not exercise the
case when x is positive
and the then branch is
not entered

282

Edge-coverage criterion
283

• Select a test set T such that every edge (branch) of the control flow is
exercised at least once by some t in T
this requires formalizing the concept of the control graph, and how to
construct it

 edges represent statements

 nodes at the ends of an edge represent entry into the statement and exit

283

142
 Control graph construction rules
284

G1 G2 G1

I/O, assignment,
or procedure call
if-then-else if-then

G1

two sequential
statements
G1

G2

while loop

284

Simplification
285

a sequence of edges can be collapsed into just one edge

285

143
 Example: Euclid's algorithm
286

begin
read (x); read (y);
while x ≠ y loop
if x > y then x := x - y;
else y := y - x;
end if;
end loop;
gcd : = x;
end;

286

Weakness
287

found := false; counter := 1;

while (not found) and counter < number_of_items loop
if table (counter) = desired_element then found := true;
end if;
counter := counter + 1;
end loop;
if found then write ("the desired element is in the table");
else write ("the desired element is not in the table");
end if;

test cases: (1) empty table, (2) table with 3 items, second of which is
the item to look for

287

144
 Weakness
288

found := false; counter := 1;

while (not found) and counter < number_of_items loop
if table (counter) = desired_element then found := true;
end if; do not discover
counter := counter + 1; should have
end loop; used ≤
if found then write ("the desired element is in the table");
else write ("the desired element is not in the table");
end if;

test cases: (1) empty table, (2) table with 3 items, second of which is
the item to look for

288

Condition-coverage criterion
289

• Select a test set T such that every edge of P’s control flow is traversed
and all possible values of the constituents of compound conditions are
exercised at least once

 it is finer than edge coverage

289

145
 Weakness
290

if x ≠ 0 then y := 5; {<x = 0, z = 1>, <x = 1, z = 3>}

else z := z - x; causes the execution of all edges,
end if; but fails to expose the risk of a
if z > 1 then z := z / x; division by zero
else z := 0;
end if;

290

Path-coverage criterion
291

• Select a test set T which traverses all paths from the initial to the final
node of P’s control flow

 it is finer than previous kinds of coverage

 however, number of paths may be too large, or even infinite (see while loops)

• additional constraints must be provided

291

146
 The infeasibility problem
292

• Syntactically indicated behaviors (statements, edges, etc.) are

often impossible

 unreachable code, infeasible edges, paths, etc.

• Adequacy criteria may be impossible to satisfy

 manual justification for omitting each impossible test case

 adequacy “scores” based on coverage

• example: 95% statement coverage

292

Further problem
293

• What if the code omits the implementation of some part of the

specification?

• White box test cases derived from the code will ignore that part of the
specification!

293

147
 Black Box Testing
294

Derive test cases from specification

From spec
From spec
From code

Id Test case (inputs) Expected Result Observed Result Pass/Fail

Pass if observed
result matches
expected result
within expected
tolerance –
otherwise Fail

294

The specification
295

The program receives as input a record describing

an invoice. (A detailed description of the format of
the record is given.) The invoice must be inserted
into a file of invoices that is sorted by date. The invoice
must be inserted in the appropriate position: If other
invoices exist in the file with the same date, then the
invoice should be inserted after the last one. Also,
some consistency checks must be performed: The program should
verify whether the customer is already in a corresponding file of
customers, whether the customer’s data in the two files match, etc.

295

148
 Did you consider these cases?
296

• An invoice whose date is the current date

• An invoice whose date is before the current date

(This might be even forbidden by law)
This case, in turn, can be split into the two
following subcases:
• An invoice whose date is the same as that of
some existing invoice

• An invoice whose date does not exist in any

previously recorded invoice

• Several incorrect invoices, checking different types of

inconsistencies

296

Systematic black-box techniques

297

• Testing driven by logic specifications (pre and postconditions)

• Decision table based testing

• Function table based testing

297

149
 Logic specification of insertion
of invoice record in a file 298

for all x in Invoices, f in Invoice_Files

{sorted_by_date(f) and not exist j, k (j ≠ k and f(j) =f(k)}

insert(x, f)

{
sorted_by_date(f) and
for all k (old_f(k) = z implies exists j (f(j) = z)) and
for all k (f(k) = z and z ≠ x) implies exists j (old_f(j) = z) and
exists j (f(j). date = x. date and f(j) ≠ x) implies j < pos(x, f) and
result  x.customer belongs_to customer_file and
warning  (x belongs_to old_f or x.date < current_date or ....)
}

298

Apply coverage criterion to postcondition…

Rewrite in a more convenient way… 299

TRUE implies
sorted_by_date(f) and for all k old_f(k) = z
implies exists j (f(j) = z) and
for all k (f(k) = z and z ≠ x) implies exists j (old_f(j) = z)
and
(x.customer belongs_to customer_file) implies result
and
not (x.customer belongs_to customer_file and ...)
implies not result
and
x belongs_to old_y implies warning
and
x.date < current_date implies warning
and
....

299

150
 Function table-based testing
300

• Boundaries are obvious in table predicates

• Make test cases that exercise between and on boundaries

• Coverage already aided by function table “rules”

Is this too much?

Result

Condition
f_name
y5 res 1
x<0 y=5
y>5 res 2
x=0 res 3
x>0 res 4 x=0

300

Function table-based testing

301

• Boundaries are obvious in table predicates

• Make test cases that exercise between and on boundaries

• Coverage already aided by function table “rules”

Was this too much? YES

Result

Condition
f_name
y5 res 1
x<0 y=5
y>5 res 2
x=0 res 3
x>0 res 4 x=0

301

151
 Testing boundary conditions
302

• Testing criteria partition input domain in classes, assuming that

behavior is "similar" for all data within a class

• Some typical programming errors, however, just happen to be at the

boundary between different classes

302

Criterion
303

• After partitioning the input domain D into several classes, test the
program using input values not only “inside” the classes, but also at
their boundaries

• This applies to both white-box and black-box techniques

303

152
 MCDC Testing
304

• Very rigorous testing used in avionics and now in automotive

 Modified Condition/Decision Coverage

• Each entry and exit is covered
• Each decision exercises every possible outcome range
• Each condition in a decision takes on every possible outcome range
• Each condition in a decision must independently change the outcome

 Important side-benefit – makes people write better requirements

• Measure code coverage when tests are constructed black-box (from requirements)

304

The oracle problem

305

How to inspect the results of test executions to reveal failures

• Oracles are required at each stage of testing

• Automated test oracles are required for running large amounts

of tests

• Oracles are difficult to design - no universal recipe

305

153
 Testing in the large
306

• Module (unit) testing

 testing a single module (unit)

• Integration testing
 integration of modules and subsystems

• System testing
 testing the entire system

• Acceptance testing
 performed by the customer

306

Module testing
307

• Scaffolding needed to create the environment in which the module

should be tested

 stubs
• modules used by the module under test

 driver
• module activating the module under test

307

154
 Testing a functional module
308

PROCEDURE
STUB UNDER TEST DRIVER
CALL CALL

ACCESS TO NONLOCAL VARIABLES

308

Integration testing
309

• Big-bang approach

 first test individual modules in isolation

 then test integrated system

• Incremental approach

 modules are progressively integrated and tested

• can proceed both top-down and bottom-up according to the USES relation

309

155
 Integration testing and USES
relation 310

A If integration and test

proceed bottom-up
only need “drivers”
B C
Otherwise, if we proceed
top-down only “stubs” are
needed
D E

310

Example
311

M
1 M
2
M
2,
1 M
2,
2

M1 USES M2 and M2 is COMPOSED of {M2,1, M2,2}

CASE 1
Test M1, providing a stub for M2 and a driver for M1
Then provide an implementation for M2,1 and a stub for M2,2

CASE 2
Implement M2,2 and test it by using a driver,
Implement M2,1 and test the combination of M2,1 and M2,2
(i.e., M2) by using a driver
Finally, implement M1 and test it with M2, using a driver for M1

311

156
 Testing OO programs
312

• New issues
 inheritance
 genericity
 polymorphism
 dynamic binding

• Open problems still exist

312

Inheritance
313

Personnel

Consultant Employee

Manager Administrative_Staff Technical _Staff

313

157
 How to test classes of the
hierarchy? 314

• “Flattening” the whole hierarchy and considering every class as a

totally independent component
 does not exploit incrementality
• Finding an ad-hoc way to take advantage of the hierarchy

314

A sample strategy
315

• A test that does not have to be repeated for any heir

• A test that must be performed for heir class X and all of its further
heirs

• A test that must be redone by applying the same input data, but
verifying that the output is not (or is) changed

• A test that must be modified by adding other input parameters

and verifying that the output changes accordingly

315

158
 Separate concerns in testing
316

• Testing for functionality is not enough

• Overload testing

• Robustness testing

• Regression testing
 organize testing with the purpose of verifying possible regressions of
software during its life—that is, degradations of correctness or other
qualities due to later modifications

316

Testing concurrent and real-time

systems 317

• Non-determinism inherent in concurrency affects repeatability

• For real-time systems, a test case consists not only of input

data, but also of the times when such data are supplied

317

159
 Analysis
318

Verification can also be performed by analysis

318

Analysis vs. testing

319

• Testing characterizes a single execution

• Analysis characterizes a class of executions; it is based on a model

• They have complementary advantages and disadvantages

319

160
 Informal analysis techniques
Code walkthroughs 320

• Recommended prescriptions
 Small number of people (three to five)

 Participants receive written documentation from the designer a few days before
the meeting

 Predefined duration of meeting (a few hours)

 Focus on the discovery of errors, not on fixing them

 Participants: designer, moderator, and a secretary

 Foster cooperation; no evaluation of people

• Experience shows that most errors are discovered by the designer during the
presentation, while trying to explain the design to other people

320

Informal analysis techniques

Code inspection 321

• A reading technique aiming at error discovery

• Based on checklists; e.g.:

 use of uninitialized variables;

 jumps into loops;

 nonterminating loops;

 array indexes out of bounds;

 …

321

161
 Correctness Proofs
322

A particular type of analysis

322

Using tabular expressions

323

• Use (create if necessary) tables representing behaviour at

“requirements level”.

• Compare tables (create if necessary) tables representing

behaviour at “current level”.

• In some cases the verification can be automated - theorem

provers or specially designed tools.

323

162
 Model checking
324

• Correctness verification, in general, is an undecidable problem

• Model checking is a \verification technique based on the fact that most

interesting system properties become decidable (i.e., algorithmically
verifiable) when the system is modeled as a finite state machine

324

Principles 325

• Describe a given system—software or otherwise—as an FSM

• Express a given property of interest as a suitable formula

• Verify whether the system’s behavior does indeed satisfy the

desired property
 this step can be performed automatically

 the model checker either provides a proof that the property holds or gives a
counterexample in the form of a test case that exposes the system’s failure
to behave according to the property

325

163
 Properties and proofs
326

• Property to be verified given through a formula (in temporal logic)

• In the example, one can prove

 there is always a computation that allows the left process to enter the critical region

 there is no guarantee that the left process accesses the shared resource unless it
already owns it

326

Why so many approaches to

testing and analysis? 327

• Testing versus (correctness) analysis

• Formal versus informal techniques

• White-box versus black-box techniques

• Techniques in the small/large

• Fully automatic vs. semiautomatic techniques (for undecidable

properties)

• …
view all these as complementary

327

164
 Debugging
328

• The activity of locating and correcting errors

• It can start once a failure has been detected

• The goal is closing up the gap between a fault and failure

 memory dumps, watch points

 intermediate assertions can help

328

BASIC SAFETY & SECURITY

329

• Safety & security definitions

• Brief intro to hazard analysis

• Safety Integrity Levels (SILs)

• Important points about safety & security and how they are related

• Brief intro to redundancy, diversity & defence in depth

• Brief intro to assurance cases

• Recap of basic safety & security concepts

329

165
 Safety Related Definitions
330

• What is the definition of safety?

 Safety is freedom from harm (there are many definitions, but the good ones all
come down to this)

• It is not an absolute! Neither is security

• A hazard is a system state or set of conditions that, together with a

particular set of worst-case environmental conditions, will lead to a
loss. [N.G. Leveson, J.P.Thomas, “STPA Handbook”, 2018] There are
other definitions of “hazard” that are used very commonly.

• Hazard analysis is a process by which we identify hazards and their

causes, and then specify ways in which we can eliminate them or
mitigate their effect

330

Why is safety difficult to achieve?

331

• Safety and security are global properties of a system, and are not
“compositional”
 What does that mean? It means that if I take 2 components that are each safe on
their own, and put them together in some way, it is not necessarily true that their
composition is safe! Why does this happen? A primary culprit is emergent behaviour
– think of this as “feature interaction”
 When we put the components together, the resulting system may exhibit behaviour
caused by the interaction of the components. That unanticipated, new behaviour
may or may not be safe!
• Often referred to as emergent behavior
 Note: components not only interact with each other, they interact with the
environment as well

• Example: There is an epidemic in Canada – cars driving at night

without their rear lights on --- why? 

331

166
 Intro to Hazard Analysis
332

• Hazard analysis is designed to:

 Identify hazards in the system
 Determine the consequences of each hazard
 Determine the likelihood of the hazard (not appropriate in all domains)
 Determine how to eliminate each hazard or at least mitigate the consequence of
each hazard

• The method to eliminate or mitigate a hazard results in one or more

safety requirements for the system!

• There are many different methods in use for hazard analysis. For a
very complete list and discussion you can see Clifton Ericson’s book(s)

• Typical methods in use in the medical domain are HAZOP, FMEA,

FMECA, FTA and STPA (more detailed discussion on these to come
later)

332

Intro to Hazard Analysis

333

• HAZOP - HAZard and OPerability analysis

 Relies on guidewords and expertise in the domain. Systematic process but can still
result in different findings by different teams
• FMEA & FMECA - Failure Modes and Effects (and Criticality) Analysis
 FMEA was originally developed for hardware based systems. Typically applied
bottom-up when we know details of the system. It can include failure rates for each
identified failure mode. FMECA is an even more detailed version of this method
• FTA – Fault Tree Analysis
 Typically applied top-down. It is used to find root causes of undesired events. It can
also help estimate the probability of the undesired event occurring. It is often used
to find “single points of failure”
See Clifton A. Ericson, “Hazard Analysis Techniques for System Safety” 2nd edition 2015, original edition
in 2005. (Both are good and include detail on HAZOP, FMEA, FMECA, FTA and others.)

• STPA - System-Theoretic Process Analysis

 A relatively recent method that uses failures in control actions to perform the hazard
analysis. It was developed to take into account that safe components may interact
in a way that is hazardous.
 The STPA Handbook written by Nancy Leveson (she developed STPA) and John
Thomas is in the Files section for the course.

333

167
 How are safety & security
related? 334

• Consider a hazard and our attempts to eliminate it

Hazard Eliminated Design to

Design to eliminate H1 Accident
No Incident
eliminate (did not work) because H1
Hazard H2 was not
eliminated
Hazards
H2
H1

H3

Hazard Eliminated Design to

No Incident eliminate Vulnerabilities
Hazard H3

334

How are safety & security

related? 335

• And if we can mitigate the effect of H1

Hazard Eliminated Design to

Design to eliminate H1 Accident
No Incident
eliminate (did not work) because H1
Hazard H2 Ultimate
was not Consequence is
eliminated Less Severe Due
Hazards
H2 to Mitigation
H1

H3

Hazard Eliminated Design to

No Incident eliminate Vulnerabilities
Hazard H3

335

168
 What if there are malicious acts?
336

• Not as nicely behaved as hazards! Murphy apparently is not as

malicious as we may have thought

Design to Design to
eliminate eliminate H1
Hazard H2
Hazards
H2
H1

H3

Design to
eliminate Vulnerabilities
Hazard H3

• Hazards are not the same as security Threats!

• The Threats correspond to a means to exploit the vulnerabilities we

have in our system

336

What if there are malicious acts?

337

• Not as nicely behaved as hazards! Murphy apparently is not as

malicious as we may have thought

Design to Design to
eliminate eliminate H1
Hazard H2

Hazards
H2
H1

H3

Design to
eliminate Vulnerabilities Threat
Hazard H3

• Hazards are not the same as security Threats!

• The Threats correspond to a means to exploit the vulnerabilities we

have in our system
• Conclusion: Cannot have safety without security

337

169
 Intro Safety Points
338

• Safety is basically freedom from harm

• It is a global property of the system – you can take 2 components that

are provably safe on their own, but when you put them together the
resulting system may not be safe

• Developers of safety-critical software intensive systems must ensure

that
 system safety requirements are identified and complied with
 the software does not introduce behaviours that could contribute to the system
causing harm
 the software will maintain any equipment and processes the system controls in a
“safe state”, even when hardware fails
 must not allow inappropriate system inputs to result in the system causing harm

• Important: 1) Safety is not an absolute! Cannot achieve 100% safety

2) Safety ≠ Correctness
3) Need security to be safe

338

Safety Integrity Levels (SILs)

339

• When standards related to “Functional Safety” were introduced (ISO

61508 and its derivative standards, such as IEC 62304 and ISO 26262),
Safety Integrity Levels started to play an important role in safety critical
systems
• A “SIL” is a societal judgement on what constitutes tolerable risk in the
specific domain
• A system’s SIL is based on the level of risk associated with the
consequences that can result from failure.
• The SIL defines categories of criticality in an application domain, for
example ASIL D in automotive is the most critical, ASIL A is the least
critical. In medical devices SIL 3 is the most critical. SIL 1 is the least.
• For a specific SIL in a specific domain, there are requirements that must
be met in order to claim that the system is adequately safe. For
example, the coverage criteria for testing may be more onerous for a
higher level of criticality SIL than for a lower level.

See “Understanding Integrity Level Concepts” in the Background Files for this course.

339

170
 More (not so) Boring definitions
340

• Redundancy is the duplication of components or functions of a system

solely to increase reliability (lots of similar definitions)

• Diversity is the realization of a desired outcome by different means

(again, lots of similar definition)

• Defence-in-depth has many meanings. DiD in the nuclear industry

originally meant multiple physical barriers to prevent a nuclear
accident. The medical device community adopted it under the guise of
“the swiss cheese model” – but it had a very similar meaning. The
cyber security community now uses it to mean the use of multiple
layers of (security) controls inserted in a system. My meaning is close
to these, but it includes the development and assurance methods as
well

340

Why we need redundancy

341

• Redundancy is our primary tool in preventing malfunctions from

causing vulnerabilities that then allow hazards to cause harm
Multiplying
Relays
2/3 logic

or
Trip Computer Shutdown
Channel D Mechanism

Redundant
Redundant shutdown
Trip Computer
Channels Channel E mechanisms

or
Shutdown
Mechanism
Trip Computer
Channel F

Nuclear Shutdown System

341

171
 Why we need redundancy
342

• Redundancy is our primary tool in preventing malfunctions from

causing vulnerabilities that then allow hazards to cause harm

Some things to note:

1. “2” is a bad number for redundancy when voting is involved!
2. These components are typically clones or very close to clones – the
idea is to use probabilistic reasoning to improve our chances of
success
3. It is not used to prevent software failures – it is there to mitigate
against hardware failures

342

Why we need diversity

343

• Diversity is our mitigation against systemic errors

• Example 1: We may use different designs because we cannot be

100% sure that our design does not have a flaw in it. So, with that
previous picture on redundancy – if the software in channels D, E and
F are all identical, and that software has an error in it – having 3
channels will not protect against the error!

• Example 2: We have sensors to detect whether there is an obstacle in

front of an autonomous car. Different sensors have different
capabilities and different short comings. We use “sensor fusion” to
cope with this. Sensor fusion is the use of multiple different types of
sensors, carefully chosen so that they compensate for each others’
blind spots

343

172
 Why we need diversity
344

• To complete discussion on our nuclear shutdown system

Shutdown System 1 Shutdown System 2

Multiplying
Multiplying Relays
Relays 2/3 logic
2/3 logic

or
Trip Computer Shutdown
or
Trip Computer Shutdown Channel G Mechanism
Channel D Mechanism

Trip Computer
Trip Computer Channel H
Channel E

or
Shutdown
or
Shutdown Mechanism
Mechanism
Trip Computer
Trip Computer Channel I
Channel F

Diverse designs

344

Why we need diversity

345

• Caution:
 There was a great study years ago by Knight and Leveson that showed that simply
getting different teams to develop independent versions of a software application
(called N-version programming) typically does not help much, or at all, in avoiding
software design errors!

• We need to aim for something that has been called “enforced diversity”
 External factors that make real diversity more likely
• Different hardware & software platforms
• Slightly different requirements – functional objectives
• Independent development teams
• A group of high level observers (project managers) who can direct diversity without
violating team diversity

345

173
 We cannot live without DiD
346

• Building safe and secure complex systems is fraught with difficulties

 Uncertainty – probably number one issue to contend with

• We have to plan for the “unknown unknowns”!
• Emergent behaviour in complex systems is something that gives me nightmares

 Completeness – a pervasive problem in both development and assurance

• How do you know you found all the hazards?
• Can you test your system completely? (no)

 State of the art – we do not even have theories for how to do a lot of what we want
to do

 State of the practice – we do not even put into practice the things we do know how
to do

346

We cannot live without DiD

347

• So how does DiD help us?

 It helps us prevent single points of failure on a large scale

• Essential to cope with uncertainty & completeness

 Examples:
• Physically – layered containment of radiation exposure in the event of a nuclear accident in
a generating station
• Conceptually – diversity in designs; redundancy in components subject to malfunction
• Procedurally – more than one way of performing verification
 Testing to verify that implementation complies with requirements
 Mathematical verification that implementation complies with requirements

 Why do we need it?

• Simple: we are not capable of predicting 100% everything that can go wrong, so we must
have something to cope with unknown unknowns
 We see this clearly when we build assurance for our systems!
 Use it when we design mitigations especially!

347

174
 Assuring safety
348

• An “Assurance Case” – generalization of a safety case

 Show an explicit argument grounded in (product, process, people) evidence that
demonstrates the product is safe!
 Goal Structuring Notation (GSN) example:
Top claim

sub-claim

sub-claim

evidence
GSN COMMUNITY
STANDARD
VERSION 1 - 2011

348

Assuring completeness is tough!

349

349

175
 (Safety) Lessons we have learned
350

• We cannot achieve safety without adequate requirements

• We cannot “bolt on” safety after developing the system – it has to be
planned before we develop the system
• Safety culture of the developers is just as important as their technical
prowess
• A common refrain after an accident “we knew that could happen, we
just did not think it was likely”
• Effective documentation is essential
• Document rationale!
• Beware confirmation bias in evaluating your system
• We are never perfect – defence in depth is an essential principle
• We need security in order to achieve safety
 In the medical world we need both aspects of security – 1) protection against
malicious acts; 2) enforcing privacy but facilitating necessary access
• Design and assure with maintenance in mind!

350

HAZARD ANALYSIS
351

• Brief look at a few hazard analysis techniques

• The objective here is to get an idea of the purpose of hazard analysis,

its importance in safety critical systems, and an initial understanding of
some of the popular techniques

• Focus on:
 Fault Tree Analysis (FTA)
 Failure Modes and Effects Analysis (FMEA)
 Systems Theoretic Process Analysis (STPA)

351

176
 Fault Tree Analysis
352

• Developed in 1962 at Bell Labs for the US Air Force

• Used to determine root causes and probability of occurrence of

undesired events (hazards)

• Can determine combination of basic events that can cause the

specified undesired event (top event)

• Graphical notation (tree structure) is intuitive for most users

• One aim of FTA is to develop “Cut Sets”

• Another aim of FTA is to develop the probability of the top event

occurring

352

FTA Example for Insulin Pump

353

From ConceptDraw.com

353

177
 More than one way to do this
354

• Here is a an example done in our research unit some years ago – very
different from the one we just saw

• Should result in very similar outcomes

• Note 1: FTA is certainly top down

• Note 2: Developed level by level down the tree

354

Views of an Insulin Pump

355

Physician/ Patient
Technician

Insulin

User User
Control Flow
Settings Feedback

Controller
Infusion Delivery
Control
Writes to system log
Microcontroller
Status to Converting user
display on Ins tructions for input to system
LCD running the instructions
Context Diagram Actuator pump
Sensor
System Log LCD Mechanical Pump
User Input

Pump
transferring Controlled Process
insulin
Insulin Delivery

Insulin transfer
Display to to user
Available to User inputs
user
user through instructions
download Users

355

178
 Example FTA: Insulin Pump
• Insulin Pump Extract – top event FTA

356

Example FTA: Insulin Pump

• Insulin Pump Extract – FTA - expand under-dosed

357

179
 Example FTA: Insulin Pump
• Insulin Pump Extract – FTA - expand too low

358

Comparison

… …
…
… …
359

180
 Cut Sets
360

• A Cut Set is a set of events that together cause the top event to occur

• One of the most common fault tree algorithms for generating CSs is
the MOCUS (Method of Obtaining CUt Sets) algorithm, developed by
J. Fussell and W. Vesely (1972)

• These days there are tools that will calculate cut sets once you define
the fault tree

• Minimal cut sets (MCs) have become important. A Cut Set is said to be
a minimal cut set if, when any basic event is removed from the set, the
remaining events collectively are no longer a cut set

360

Calculating Cut Sets

361

MOCUS Example from Ericson’s 2005 Book

361

181
 Importance of Cut Sets
362

• The order of a Cut Set is the number of elements in the set

• What does it imply if the order of a Cut Set is 1?

 In the previous example the minimum Cut Sets are C, AB

 So order of the first Cut Set is 1

 Order of the second Cut Set is 2

 We know of one automotive OEM that has a rule that the minimum order allowed for
any Cut Set is 3

362

FTA Diagrams Can Get Large

363

363

182
 Failure Modes & Effects Analysis
364

• For years it has been the most popular hazard analysis technique

• Developed for the US military – used a lot in the aerospace industry

• It is a disciplined bottom up method

• It’s aim is to determine all possible failure modes for systems,

subsystems or components

• Usually performed by filling in a table that looks like this

Component Failure Failure Causal Immediate System RPN
Mode Rate Factors Effect Effect

364

Definitions (from Ericson)

365

• Failure: Departure of an item from its required or intended operation,

function, or behavior; problems that users encounter. The inability of a
system, subsystem, or component to perform its required function

• Failure Mode: The manner by which a failure is observed. Generally

describes the way the failure occurs and its impact on equipment
operation

• Failure effect: The consequence(s) a failure mode has on the

operation, function, or status of an item. It can be divided into
immediate effect and system effect

• Failure cause: The physical or chemical processes, design defects,

quality defects, part misapplication, or other processes which are the
basic reasons for failure or which initiate the physical process by which
deterioration proceeds to failure

365

183
 Definitions (from Ericson)
366

• Risk priority number (RPN): Risk ranking index for reliability.

RPN = (probability of occurrence) (severity ranking) (detection
ranking). Detection ranking ranks the ability of planned tests and
inspections to detect failure modes in time

Note: “Component” in the table is often interpreted as a functional

component not a physical one

366

Example: FMEA for Insulin Pump

367

Functional Decomposition of Insulin Pump

367

184
 Example: FMEA for Insulin Pump
368

368

Example: FMEA Zoomed-in Left

369

185
 Example: FMEA Zoomed-in Right

370

Example: FMEA  Safety

Requirements

371

186
 Systems Theoretic Process
Analysis - STPA 372

• Developed by Nancy Leveson at MIT

• STAMP (Systems-Theoretic Accident Model and Processes) is an

accident analysis methodology

• STPA is a hazard analysis methodology

• What I like about STPA

 Recognizes the non-compositional nature of safety
 Can lead to mitigating hazards at a higher abstraction level
 Guides the analyst to consider control flow in a systematic way - aiming for some
measure of completeness

• Some things to be aware of

 Highly dependent on the control diagram(s) you use to do the analysis
 Steep learning curve to do it well

372

Steps in STPA
373

• Specify the purpose of the analysis, ie what kinds of losses will be

involved in the analysis

• Model the control structure (create the control diagram(s) that govern
the analysis)

• Identify unsafe control actions

• Identify loss scenarios

373

187
 Purpose of the analysis
374

From
STPA Handbook

A hazard is a system state or set of conditions that, together with a particular set of
worst-case environmental conditions, will lead to a loss – Leveson

Then, turn hazards into system level constraints

374

Original Control Diagram

From Nancy Leveson

375

188
 Current Control Diagram
376

From
STPA Handbook

376

STPA Unsafe Control Actions

From Nancy Leveson
• Four categories of control actions to consider

 Not providing the control action leads to a hazard

 Providing the control action leads to a hazard

 Providing a potentially safe control action but too early, too late, or in the wrong
order

 The control action lasts too long or is stopped too soon (for continuous control
actions, not discrete ones)

• Note that there is some idea of completeness that helps us consider

“all” possibilities

377

189
 Control Diagram
378

These are what we From

consider for Unsafe STPA Handbook
Control Actions -
UCAs

378

Table of UCAs
379

Create a table of the following form

Control Not providing Providing causes Too early, too Stopped too
Action causes hazard hazard late, out of order soon, too late
Action 1 UCA-1: text UCA-2: text UCA-3: text UCA-4: text

UCA-5: text UCA-6: text UCA-7: text UCA-8: text

Action 2 UCA-9: text UCA-10: text UCA-11: text UCA-12:text

Notes: 1) It is possible that there is no UCA for a specific cell, then “ – “

2) Text should describe the UCA and then at the end refer back to
the system level hazards that the UCA can lead to in this
context.

379

190
 Example STPA: Insulin Pump

Viewed as a control system

380

Example STPA: Insulin Pump

Note: Example was

done years ago by
inexperienced analyst.
Shown here because it
is about the insulin
pump. The information
in the tables is very
close to what we would
do these days

381

191
 Example STPA: Insulin Pump

Zoomed-in
extract

382

Identify Loss Scenarios

383

The loss scenarios are

causal factors that can
lead to the UCAs (and thus
to hazards)
From
STPA Handbook

Note that we now explicitly

include sensors and
actuators

And include Feedback!

383

192
 Consider Control & Feedback
384

From
STPA Handbook

384

The Final Output from STPA

385

• Not obvious from the discussion and the STPA Handbook

• What I believe we need from the analysis is:

 Losses
 Hazards
 Safety constraints
 Unsafe control actions
 Loss scenarios

 Safety requirements

• What is also not obvious is: Controller, Controlled process, Sensors,

Actuators can be machines and/or people and/or anything else – do
not make the mistake of thinking this is only about machines. It is
much more conceptual than that!

385

193
 ASSURANCE CASES
386

• Motivation

• The basic idea

• A popular approach – Goal Structuring Notation (GSN)

• Examples

• Benefits of GSN

• Problems with GSN

• Some advances

386

Motivation for Safety Cases

• Pre-safety cases

 Processes planned to result in a safe product

 Processes included work products that documented development

as well as V&V including internal and external reviews

 The argument as to why all this evidence demonstrated the product

was safe was mostly implicit

387

194
 Motivation for Safety Cases
388

• One way of convincing a regulator that the system is safe

Safety argument was implicit
HAR Validation Test and
Reliability Qualification
System Reports
Requirements HAR
& Design Software Integration
Software Test Report
Requirements
Specification

Software
Design
Design Review and Description Unit Test
Verification Reports Report
So – regulators:
HAR
• Pre-approved approximately 20
Legend:
Documents produced in the
process documents
forward going development process
• Audited development to be in
Documents produced by HAR
verifications, reviews, analyses and
testing
compliance with processes
Activities and data flow Code Review and
Code
• Audited output of the
Verification Reports
HAR Hazard Analysis Report
processes
• Witnessed in-plant testing
• And then give the regulators all the documents you have created
 but the regulator then has to discover why we thought the system is safe

388

Process vs Product Assurance

• The most prevalent method for certifying software-intensive

systems has been to show that the system was developed in
compliance with an approved process

• A major problem is that processes are not specified in

sufficient (product) detail to give us confidence that the
product is safe

• Recently, standards have included more product based

assurance in addition to specifying requirements on the
process

 Helps but does not eliminate the problem

 DO-178C (software for civil aviation) is more prescriptive on process

and that also seems to help!

389

195
 (Safety) Assurance Cases

• Safety case paradigm

 Aim is to show an explicit argument grounded in (product, process,

people) evidence that demonstrates the product is safe!

 Was also supposed to deliver more focus on product assurance

than previous practice

 Safety cases have been in use in the UK for more than 50 years

 An Assurance Case is based on the idea of a safety case, just

more general in terms of what properties can be assured
• Safety, security, dependability, …

390

Notation for Assurance Cases

391

• Assurance cases can be documented in text, tabular formats and

graphics

• Most usual documentation in industry right now is probably an internal

text and tabular structure

• Graphical representations are becoming very popular and there are

two similar notations that both originated in the UK
 GSN (Goal Structuring Notation) was defined by Tim Kelly in his PhD thesis (1998)

 CAE (Claims Arguments Evidence) was introduced by the consulting company

Adelard

 GSN is the most popular assurance case notation in the research literature

391

196
 Basis for an Argument
392

• Toulmin’s Argument Structure

 Toulmin was a philosopher at King’s College in the UK

 His argument structure provided basic ideas of how an argument is formed, but the
structure was difficult to scale

• GSN and CAE look very similar – note one difference – the arrows

https://www.adelard.com/gsn.html https://www.adelard.com/asce/choosing-asce/cae.html

392

GSN
393

GSN COMMUNITY
STANDARD
VERSION 1 - 2011

393

197
 GSN
394

GSN COMMUNITY
- claim STANDARD
VERSION 1 - 2011

394

GSN
395

GSN COMMUNITY
- claim STANDARD
VERSION 1 - 2011
- evidence

395

198
 GSN
396

GSN COMMUNITY
- claim STANDARD
VERSION 1 - 2011
- evidence

What happened to the argument?

396

GSN
397

GSN COMMUNITY
- claim STANDARD
VERSION 1 - 2011
- evidence

What happened to the argument? It got transformed into decomposition strategies

397

199
 GSN
398

- claim Context GSN COMMUNITY

STANDARD
VERSION 1 - 2011
- evidence

Justification

Assumption

What happened to the argument? It got transformed into decomposition strategies

398

GSN
399

- claim Context The Property We

GSN COMMUNITY
STANDARD
Want to Claim
VERSIONto
1 - 2011
- evidence
be Achieved

Justification

Assumption

What happened to the argument? It got transformed into decomposition strategies

399

200
 GSN
400

- claim Context The Property We

GSN COMMUNITY
STANDARD
Want to Claim
VERSIONto
1 - 2011
- evidence
be Achieved

Justification
Evidence is
From the System
Assumption
Development

What happened to the argument? It got transformed into decomposition strategies

400

Starting the Argument

401

• Think about the GSN structure (for example)

• The top level of the assurance case determines the entire structure of
the “argument”

• Many safety assurance cases use the argument that all hazards have
been eliminated and/or mitigated
 Personally, I do not like or agree with this. There is more to safety than mitigating
hazards. We know that if the application does not deliver what is expected by users,
users look for workarounds. Sometimes those workarounds negate the safeguards
we have built into the system.

• I suggest it is better to depend on a long time proven approach

1. Demonstrate that the (system) requirements are such that they will result in a safe
system
2. Demonstrate that the system is implemented (built) in compliance with its
requirements – within tolerance
3. Demonstrate that the implemented system does not include behaviour not included
in the requirements – unless carefully justified

401

201
 Coffee Cup Example – Top Level
402

Shows an argument
rather than a strategy

Module

Variation on argument
in previous slide From Thomas Chowdhury
PhD Thesis, 2021

402

Coffee Cup Example – Top Level

403

Shows an argument
rather than a strategy

Variation on argument
in previous slide From Thomas Chowdhury
PhD Thesis, 2021

403

202
 Support for Claim CR
404

From Thomas Chowdhury

PhD Thesis, 2021

404

Support for Claim CR1

405

From Thomas Chowdhury

PhD Thesis, 2021

405

203
 GSN Benefits
406

• Benefits

 I think GSN and similar notations like CAE (Claims Arguments and Evidence,
developed by Adelard) have had a very positive effect in producing safe(r) systems

• It is appealingly intuitive – I have seen practicing engineers (and students) pick-up the
basic idea in a GSN assurance case as fast as you would ever want them to … sometimes
faster

• Its primary success (I think) is to get people to look critically at the “argument” and ask
important and usually overlooked questions – and this is invaluable

• It has motivated many more developers and certifiers to consider seriously what we need to
do to demonstrate that a system is safe (or secure or dependable etc)

406

GSN Shortcomings
407

• A personal view

• Cases tend to have an ad hoc structure dictated by experience &

preference
 Patterns help but they are not the “solution”

• Cross-cutting concerns abound

• There is an element of confirmation bias

• Provides a false sense of confidence (no matter how we “measure”

confidence) since we think our reasoning is rigorous (most never claim
formal) – but it is not really rigorous

• Effective safety impact analysis is difficult to impossible

 In general, effective traceability is tough

407

204
 Assurance Case Templates
408

• Still within GSN we came up with a variation that has some

advantages – we believe P
• Complete assurance case
produced before
development starts

• Optional argument paths

• Evidence nodes specify

type of evidence required 1
1-2
and acceptance criteria on
that evidence
exclusive or

non-exclusive or
• Requires explicit reasoning
(not shown here)
0-1 0-1
• Try to make it robust with
optional path

optional path
respect to change
Legend:
• Assume it will be developed - Claim or sub-claim
by a community in the - Evidence
same way that standards A B - A is claim
B is premise
are acceptance criteria on evidence required specified in the template

408

Assurance Case Templates

409

• Still within GSN we came up with a variation that has some

advantages – we believe P

Insulin pump examples

of “optional paths”
• Optional – built-in light

• Exclusive – standard Luer 1

1-2
connector for infusion set,
or not
exclusive or

non-exclusive or

• Non-exclusive – input
from glucose meter 0-1
0-1
and/or manual input
optional path

optional path

Legend:
- Claim or sub-claim
- Evidence
A B - A is claim
B is premise
acceptance criteria on evidence required specified in the template

409

205
 Why Assurance Case Templates?
410

Assurance Case Template Traditional Assurance Case

Designed to cope with a product family Designed to cope with a single product
Constructed before development of any Constructed during development (at
product in the family best) or afterwards
Kind of evidence and acceptance Evidence nodes contain evidence for a
criteria for evidence in evidence nodes – specific product
have to be instantiated for a specific
product
Specifically designed to be robust with Could be designed to cope better with
respect to change by using optional anticipated changes, but hampered by
paths to accommodate anticipated the rigidity of the notion of evidence
changes – in product, argument and
evidence
Designed to offer an ”easy” path to Lack of focus on argument and
incremental (safety) assurance if we inclusion of anticipated changes makes
make changes that were built-in as it much more difficult to implement
likely in the future incremental assurance

410

Our Latest Research – Workflow+

411

Initial assurance
nodes generated
Model by multiplicity and
other constraints
processes

Assurance nodes
generated from
initial assurance
nodes
(yellow & orange)
Model data produced
and used by processes

411

206
 Zoom-in to See Constraints
412

So, where did

the assurance
steps come
from?
There is a constraint that
says every hazard must be
“dealt with” by a safety
requirement

We then have 2 checks on

that:
1. semantic – needs
people
2. syntactic – can be
automated

20

412

Generate GSN from Workflow+

413

This was an
assumption in the
GSN example but
would not be in
practice

413

207
 Expansion from the previous slide
414

414

We Are Done – Stay Safe

415

415

208