Some Ideas about. Developing and Comprehending. Requirements for. Computer-Based Systems

Some Ideas about Developing and Comprehending Requirements for Computer-Based Systems Michael Jackson The University of Newcastle and The Open Univer...
Author: Melvyn Ball
5 downloads 0 Views 50KB Size
Some Ideas about Developing and Comprehending Requirements for Computer-Based Systems

Michael Jackson The University of Newcastle and The Open University [email protected] 9/23/2011

WG2.3 Working Group on Programming Methodology Winchester September 22 2011 WG2.3Sep11  1

With ideas stolen from … • Newcastle • Cliff Jones, Ian Hayes • Open University • Jon Hall, Lucia Rapanotti • Bosch • Felix Loesch, Rainer Gmehlich, Katrin Grau • Deploy project • Michael Butler, Stefan Hallerstede • MIT • Daniel Jackson, Robert Seater • Praxis • Anthony Hall • …

9/23/2011

WG2.3Sep11  2

Computer-based systems • Radiotherapy machines

• Lifts • Access control • Library management • Traffic control • Chemical plants • Power plants • Automotive systems • Avionic systems • Banks • ...

9/23/2011

WG2.3Sep11  3

Computer-based systems Lobby Display Lift Equip’t Lift Controller

Buttons

Users Light Units

Floors

Building Manager

Traffic Controller

Crossing Buttons

Pedestrians

Road Layout

Vehicles & Drivers

Road Sensors

• • • • • 9/23/2011

The ‘machine’ and the ‘problem world domains’ System behaviour is the joint machine + world behaviour Domains are non-formal, heterogeneous Domains have given behaviours and properties Requirement is a condition on whole system behaviour WG2.3Sep11  4

Requirements and problem diagrams Lobby Display Lift Equip’t Lift Controller

Buttons

Convenient & Safe Lift Service

Users

Floors

Building Manager

Light Units Traffic Controller

Crossing Buttons

Pedestrians

Road Layout

Orderly, Safe Traffic

Vehicles & Drivers

Road Sensors

• System is closed: everything relevant appears in the diagram • Requirement constrains some problem domains, mentions others • Problem is to devise machine to satisfy requirement 9/23/2011

WG2.3Sep11  5

Some sources of complexity • Characteristics of the whole system • Heterogeneous, unreliable, etc • Many problem domains are stateful • Multiple functional features • Problem domain  function is n-to-n • Feature interactions include conflicts • Multiple modes and contexts of operation • Mode switching may be unpredictable • Domain properties may depend on context • eg time, season, affect human behaviour • eg physical devices deteriorate, fail, … 9/23/2011

WG2.3Sep11  6

Lift control: some candidate functions • • • • • • • • • • • •

9/23/2011

Normal lift service Firefighter, test, maintenance service Reduced service on certain failures Maintain lobby display Door operation Overload protection Equipment failure detection Failure mitigation Emergency braking Creating service priority schemes Priority scheme management ...

WG2.3Sep11  7

Needs for human comprehension • Stakeholders • To agree requirements • System developers • To master complexity • Users • To use easily and reliably • Operators • To act effectively • Patients • To be treated comfortably • Certification agency • To identify risks easily • ... 9/23/2011

WG2.3Sep11  8

Human comprehension “Would a naturalist imagine that he had an adequate knowledge of the elephant if he had never studied the animal except through a microscope? “It is the same in mathematics. When the logician has resolved each demonstration into a host of elementary operations, all of them correct, he will not yet be in possession of the whole reality; that indefinable something that constitutes the unity of the demonstration will still escape him completely.” Henri Poincaré; Science et Methode; Flammarion 1908; tr Francis Maitland, p126, Nelson 1914

9/23/2011

WG2.3Sep11  9

In search of simplicity: decompositions • By software modules • Properties for model checking • Fragmented requirements • Local program assertions • Global invariants • Scenarios • Animations • Subproblems • Behaviours • ‘How it works’ • Some concerns • ... 9/23/2011

WG2.3Sep11  10

In search of simplicity: loose decomposition A

A A D

B C

Embedded (eg procedure call hierarchy)

B

C D

Jigsaw (eg OO, relational schemas, CSP)

?

? B

? ?

C ?

? D

Loose (eg subproblem decomposition)

• Loose decomposition • Separates intrinsic from interaction complexity • Defers combination until parts are understood • Allows useful oversimplifications

9/23/2011

WG2.3Sep11  11

Functions and domains Failure detection and diagnosis Creating service priority scheme Emergency braking Maintaining lobby display Normal lift service Lift Equip’t

X

Users

X

Buttons

X

X

Floors

X

X

X

Building Manager

X

X

X X

Lobby Display Priority Scheme

X

X X

X

X

Lift Equip’t Model

9/23/2011

WG2.3Sep11  12

Some subproblems Lift Equip’t Brake on Critical Danger

Emergency Braking Floors

Lobby Display

Priority Rules Editor

Building Manager Priority Rules

EditAction Effects

Users

Lift Equip’t Lobby Display Controller

Buttons

Display  Lift Position, Direction & Requests

Floors

• Subproblem • To be considered in isolation • Behaviour  projection of system behaviour • Further decomposition if needed 9/23/2011

WG2.3Sep11  13

Subproblem analysis for comprehension a

Lift Equip’t

c Brake on Critical Danger

e

Emergency Braking

b

Floors

d

• Interface phenomena • At a, b, c, d, e • The operational principle • Causal chain explaining how it works • Problem domain properties and roles • Participation in causal chains • Behaviours • Lift car movement as detected by sensors • Subproblem concerns (failure possibilities) • Initialisation, breakage, totality, identities, … 9/23/2011

WG2.3Sep11  14

More formal subproblem analysis a

Lift Equip’t

c Brake on Critical Danger

e

Emergency Braking

b

Floors

d

• Interface phenomena • Here, at a, b, c, d, e • Given ‘indicative’ domain properties Wi • Relating each domain’s interface phenomena • Required ‘optative’ behaviour R • Relating phenomena at c and d • Proposed software specification S • Relating phenomena at a and b • Overall Proof Obligation: M,Wi,Wj,.. |= R 9/23/2011

WG2.3Sep11  15

Criteria of subproblem simplicity • Subproblem is closed • External stimuli internalised • eg Lift moves autonomously • Operational principle • Simple requirement-to-requirement traversal • Comprehensible requirement • Not conditional (cf ATC aircraft separations) • Domain properties • Consistent over whole behaviour • Domain role • Single role in this subproblem • Behaviour structure • Simple (eg regular grammar) • …

9/23/2011

WG2.3Sep11  16

Subproblem recombination • Two recombination tasks • Combining subproblem machines • This is implementation • Combining subproblem behaviours • This is requirements development • Combining subproblem behaviours • Controlling behaviour activation • What behaviours should coexist? • Handling interactions • eg simplifications, priorities, … • Solving behaviour switching concerns • When a domain passes between regimes

9/23/2011

WG2.3Sep11  17

Lift control: some candidate functions • • • • • • • • • • • •

9/23/2011

Normal lift service Firefighter, test, maintenance service Reduced service on some failure Maintain lobby display Door operation Overload protection Equipment failure detection Failure mitigation Emergency braking Creating service priority scheme Priority scheme management ...

WG2.3Sep11  18

Controlling behaviour activation • Like switching among system ‘modes’, except: • Each ‘mode’ value is a set of behaviours • Mode-switching is a distinct function • A distinguished subproblem • Subproblem activation events • External activation • External preemptive termination • Internal termination on success • Internal termination on failure • …?

9/23/2011

WG2.3Sep11  19

Handling subproblem interactions • Interleaving • eg: Priority Rules Editor vs Lift Service • Removing a simplification • eg: Book loans vs member status • Requirement conflict • eg: Service vs Emergency Braking • Switching • eg: Normal to Firefighter Lift Service • Domain sharing • eg: Phone display: camera vs gps vs email …

9/23/2011

WG2.3Sep11  20

A work in progress • A structure for human comprehension • Subproblem granularity • Subproblem simplicity • Identifying error opportunities • Separating concerns • Subproblem from subproblem • Intrinsic from interaction complexity • Behaviours from behaviour control • Totally non-formal • A structure for formal reasoning

9/23/2011

WG2.3Sep11  21

Thank you

9/23/2011

WG2.3Sep11  22