Checking and validation

Chapter 9

Checking and validation

Checking and validation

• All parts match and everything is included

• Validate that stakeholders are happy

• Where are the major risks?

• Quality product = meet the spec?

A good requirement

• Correct; reflects a need• Complete; all necessary

requirements included• Unambiguous; all parties agree on

meaning• Consistent; all parts match (E/R and

event list)• Ranked for importance

A good requirement

• Modifiable; easy to change

• Verifiable; possible to see whether requirement is met

• Traceable; to goals/purposes, to design/code

• Understandable; by customer and developer

Checking the spec in isolation

• When a check reveals a problem;– Simple – fix it– Important info missing – more

elicitation work required– Important info missing but not

important – ignore or comment that intentionally left out

– Two parts of the spec mismatch – look into simple mistake or more important

Contents check

• Introduction• System goals• Data requirements• Functional requirements• Handling of special cases• Quality requirements• Other deliverables• Glossary

Contents check

Structure check

• ID for each requirement• Verifiable requirements• Purpose• Examples of ways to meet requirement• Explanation of diagrams• Importance and stability • Cross references• Index• Electronic version

Structure check

Consistency checks and CRUD

• CRUD; can each entity class in the data model be created and deleted by an event or function or user task?

• Can each field in the data model be Read and Updated by an event or function or user task?

• Event check; are all events handled by a function or user task?

Consistency checks and CRUD

• Information needs; are the necessary data for each task or message flow available in the data model?

• Virtual windows checks; – are all data in the virtual windows

available in the data model an vice versa?

– Are all tasks conveniently supported through a few virtual windows?

Consistency checks

CRUD matrix

Checks against surroundings

• Review of the specification–Many issues are usually found– Not all lead to problems in development– Difficult to know which ones cause

problems – Resolving earlier saves a lot of time

later on

Checks against surroundings

• Goal-requirements tracing– Are all goals and critical issues covered

by requirements?– Are all requirements justified by

meaningful purposes?

Checks against surroundings

Risk assessment

• A requirement that is risky to the customer is often low risk for the developer and vice versa

• Customer risk; doesn’t get what is needed even if this is what is specified

• Developer risk; cannot fulfill requirement within reasonable cost

Unacceptable risk

• Choose another requirement style with lower risk

• Elicit more precise requirements

• Isolate the risk

• Keep the risk under observation

Validation via testing

• Tests

• Simulation/walkthrough

• Prototype test

• Pilot test

Checklist forms

• Convenient to plan and record the checks by means of a form

Checklists at work

Checklists at work

Checklists at work

Checklists at work

Checklists at work

Z(ed)

Zed

• Based on set theory, functions and discrete mathematics

• Standard symbols Special symbols• Four sections– Given sets, data types, and constants– State definition– Initial state– Operations

Zed• Set theory provides foundation to

construct an abstract structure of software product

• First-order predicate logic used to express behavior of the product

• Strongly typed; every object must be associated with a unique type– easier to develop tools to type check

– interpreted as maximal sets (subset relations)

Schema

• Encapsulated structure

• Associated with some properties

• Can specify parts of a system separately and compose larger systems– types– state spaces– operations

Abstraction

• Representational abstraction– type definitions– global constants– state space declaration

• Operational abstraction– operation definitions– function definitions

Representational Abstraction

• Schema– unique name– structure described by a set of declarations– property described by a set of predicates

• express invariant relationships among the structure components

• Allows specification to be split into manageable pieces for modular specifications

Types• Interpreted as sets

• Carrier set; set of values associated with a type– describes the collection of values an object of

that type can assume

• Every variable, constant, and expression must be associated with a type– easier to spot errors in the spec– enforces discipline in writing good specs

Simple types

• Primitive types; already defined in Z– integer type is only primitive type in Z

• Basic types; user defined– used in current spec and not further

elaborated– users of an automated teller machine can

be modeled as a basic type• [USERS]• [USERS, STAFF, CLIENTS]

Set operators in Z

Abbreviation

• New names can be used for complex expressions

• Title X Author X CallNumber X Year• Book == Title X Author X CallNumber

X Year• Room numbers between 100 and 199• r: RoomNumber 100 <= r <= 199

Operators on Sequences

Examples of sequences

Format of Z schema

(constraints)

Elevator Problem

• Given sets– do not need to be defined in detail– [Button] ; the set of all buttons

• floor buttons

• elevator buttons

• buttons (set of all buttons in the elevator problem)

• pushed (all buttons that have been pushed)

– PP; power set (set of all subsets of a given set)

Z schema Button_State

Initial State

• Abstract initial state; state when the system is first tuned on

• Vertical schema vs horizontal schema• When elevator is first turned on the set

pushed is initially empty (all buttons off)

Button_Init = [Button_State’ | pushed’ = ]^

Operations

operation changes the state of a variableinput variableoutput variable

` new value of a variable/ set difference such that

Z specification of operation Push_Button

Z specification of operation Floor_Arrival

Users of a computer system

Simple schema - no additional constraints

Schema with constraints

Users of a computer system

Schema represented in horizontal style

Analysis of Z• Z successfully applied on many projects– easy to find faults in the specification– specifier must be very precise which leads

to less ambiguity– developers can prove specification correct– requires no formal mathematical

background– decreases the cost of software development– can be rewritten in natural language

Summary of Specification Methods

Summary

• Summarize your present understanding of the problem and all your findings in a concise, complete, well-organized and polished statement (processing narrative )

• Important that this step is well done, since this first informal document will serve as anchor for your further work

Petri Nets

Concurrent Systems

• FSM not good at coping with timing– synchronization problems– race conditions– deadlock

• Poor specifications can cause timing related problems

• Petri Nets good at specifying systems with potential timing problems

Petri Nets

• Carl Adam Petri (automata theory)

• Now used in other areas– performance evaluation– operating systems– software engineering

• Use to specify concurrent interrelated activities

Components of a Petri Net

• Four parts– set of places, P– set of transitions, T– input function, I– output function, O

• Formally; C = (P, T, I, O)– P = {p1,p2,…,pn}, n >= 0– T = {t1,t2,…,tm}, m >= 0 (P and T disjoint)– I: T --> P is the input function– O: T --> P is the output function

Petri net example

• Petri net on next page– P = {p1, p2, p3, p4}– T = {t1, t2}– I(t1) = {p2, p4}– I(t2) = {p2}– O(t1) = {p1}– O(t2) = {p3, p3}

Petri Nets

p1p3

p4

p2

t1

t2

Marking

• Marking is an assignment of tokens to the Petri net

• Represented by a vector (1,2,0,1)• Transition is ready to fire (enabled) if each of

its input places has as many tokens in it as there are arcs from the place to that transition– number of tokens not conserved–marking before t1 fires is (1,2,0,1)–marking after t1 fires is (2,1,0,0) –marking after t2 fires is (2,0,2,0)

Marked Petri Net

p1p3

p4

p2

t1

t2

.

.

..

Petri Net after firing transition 1

p1p3

p4

p2

t1

t2

..

.

Petri Net after firing transition 2

p1p3

p4

p2

t1

t2

. .. .

More on Marking

• Petri nets are nondeterministic– if more than one transition is ready to

fire, any one of them may be fired

• Formally; C = (P,T,I,O) is a function from the set of places P to the set of nonnegative integers M: P --> {0,1,2,…}

• A marked Petri net is a 5 tuple (P,T,I,O,M)

Inhibitor Arc

• Small circle instead of an arrow head

• A transition is enabled if there is at least one token on each of its normal input arcs and no tokens on any of its inhibitor input arcs– Transition t1 is enabled because there

is a token in p3 but no token in p2

Petri Net with Inhibitor Arc

p1

p3

p2

t1

.

Petri Net Summary

• Abstract virtual machine (like FSM)

• Very well defined behavior

• Circles are “places”

• Lines are “transitions”

• Arrows (directed arcs) interconnect places and transitions

Petri Net Summary• Transition is enabled when all transition

arcs entering that transition emanate from places containing tokens (dots within places)

• “Enabled” is when the external stimulus associated with that transition occurs– tokens that enabled the transition are

consumed– new tokens created at the ends of the arcs

exiting from the transition node

Token merging in Petri Nets - Before and After

Fan-out in Petri Nets; Before, After T2, after T3

Petri Net example

• Starting configuration• Only one transition is enabled (T1)• If stimulus T1 occurs– token at P2 moves to P1– only one transition enabled (T4)

• If stimulus T4 occurs– tokens at P1 and P5 are consumed– two tokens created at the ends of the arcs

exiting T4

Petri Net Example - Initial configuration

Petri Net Example - After first firing

Petri Net Example - After second firing

Petri Net Example - After T2 occurs

Petri Net Example - After T2 occurs

Petri Net Example

• (e) is identical to (a)• Petri Net with a cycle of length 4• So how does this help us write a SRS?– assume that T1 - T4 are all associated with the

same 1 second clock– P2 and P3 are lights– Petri Net could be used to unambiguously

define the requirements for this 2 light system

Petri Net for a 2 light system

• 1. There are two light bulbs

• 2. Every other second, there shall be no lights on

• 3. Every other second, there shall be exactly one light on

• 4. Each time a light comes on, the lights alternate

Petri Net for a 2 light system

• Places P2 and P3 in the preceding Petri Net do just that

• Petri Net contains no ambiguity

• The English sentences may be misunderstood

• Same behavior shown on next page - but its simpler!

Another Petri Net to do the same thing

Another set of specifications

• 1. There are two light bulbs• 2. For the first two seconds one light

is on• 3. For the next two seconds, that

light goes off and the other light goes on

• 4. From then on every 2 seconds the lights alternate

Use the same Petri Net!• Associate the two light bulbs with

places P4 and P5

Or use a simpler one!

• Use a two second clock pulse...

Petri Nets

• Response-stimulus timing constraints can also be stated in Petri Nets

Response-stimulus timing constraint in equivalent

Petri Net

How to analyze this Petri Net

• Initially a token at P0• User is asked to do x• Once the user arrives a timer token

proceeds to P1 and arrives at P2 in exactly 15 seconds

• A token also sits at P3 waiting for either the 15 seconds to elapse (P3 token consumed by firing transition T1) or for the user to complete x (P3 token consumed by firing transition T2)

How to analyze this Petri Net

• If 15 seconds elapses P4 is fired activating the alternative system response (warning message perhaps)

• If the user completes x before 15 seconds, P5 is fired for the normal system response

• If the user completes x in precisely15 seconds the normal system response happens (benefit of the doubt)

How to analyze this Petri Net

• lo and hi priorities places on arcs from P3 to remove any doubt associated with nondeterminism

• Normal response spawns a timer token at P2–may force an alternative system response to

the next user that comes along– Place P6 added to remove these– Mission at T3 is to remove all “renegade”

timer tokens that reach P2

How to analyze this Petri Net

–arc connecting P2 and T3 is higher priority than arc connecting P2 and T1• ensures that the timer token is

removed if there is a token at P6 and never has a chance to give a subsequent user at P3 an alternative system response through T1 accidentally

Petri Net Extension

• Stimulus-response and response-response constraints required a Petri Net extension– required execution time recorded above

each Place– specified the maximum allowable time

for the system to perform the operations

A Petri Net showing execution times