ADVANED

SOFTWARE
ENGINEERING
LECTURE 3: Testing, Modeling and System
Specification
Asst.Prof.Dr Ervin Domazet
International Balkan University
 Software Testing - Topics
• Overview of Software Testing
1. Make a plan for systematic testing
2. Write and run tests; test automation
• Designing Tests for High Coverage
• Practical Aspects of Unit Testing
• Integration and System Testing
• Security Testing

2
 Do I Need to Do Testing?
• Everyone who develops software does testing—that’s
unavoidable
• The only question is whether testing is conducted
haphazardly by random trial-and-error, or systematically,
with a plan
• Why it matters? —The goal is to try as many “critical” input
combinations as possible, given the time and resource
constraints
– i.e., to achieve as high coverage of the input space as is practical,
while testing first the “highest-priority” combinations
– Key issue: strategies for identifying the “highest priority” tests

3
 Overview of Software Testing
• “Testing shows the presence, not the absence of bugs.” —Edsger
W. Dijkstra
• A fault, also called “defect” or “bug,” is an erroneous hardware
or software element of a system that can cause the system to fail
• Test-Driven Development (TDD)
• Every step in the development process must start with a plan of how to verify
that the result meets a goal
• The developer should not create a software artifact (a system requirement, a UML
diagram, or source code) unless they know how it will be tested

• A test case is a particular choice of input data to be used in

testing a program and the expected output or behavior
• A test is a finite collection of test cases
White-box testing exploits structure within the program (assumes program code available)
Black-box testing explores input space of functionality defined by an interface specification 4
 Why Testing is Hard
• Any nontrivial system cannot be completely tested
– Example: testing 4-digit numeric keycodes
• You never know with certainty that all 4-digit codes work as expected unless you try all
• But, what happens with “incomplete” (3-digit, 2-digit) codes? Will all of them timeout to reset state?
• Or, will all tuples (pairs, triplets, etc.) of successive incomplete codes timeout to the reset state?
• Our goal is to find faults as cheaply and quickly as possible.
– Ideally, we would design a single “right” test case to expose each fault and run it
• In practice, we have to run many “unsuccessful” test cases that do not expose any
faults
• A key tradeoff of testing:
– testing as many potential cases as possible (high degree of “test coverage”) while keeping
the economic costs limited
• Underlying idea of software testing:
– the correct behavior on “critical” test cases is representative of correct behavior on untested parts
of the state space

5
 Logical Organization of Testing
( Usually not done in a linear step-by-step order and completed when the last step is reached! )

Component
(unit) code
Unit White box testing Black box testing
test (by developer) (by customer)
Component
(unit) code
Unit
test Integrated
modules
Integration System
test test
System
in use
Ensures that all
Component components
(unit) code work together
Unit
test

Ensure that each Function Quality Acceptance Installation

component works test test test test
as specified

Verifies that functional Verifies non- Customer Testing in

requirements are functional verifies all user
satisfied requirements requirements environment
6
(“platform”)
 Acceptance Tests – Safe Home Access Examples
( “black box” testing: focus on the external behavior )
[ Recall Section 2.2: Requirements Engineering ] Input data

• Test with the valid key of a current tenant on his/her apartment

(pass)
Expected result
• Test with the valid key of a current tenant on someone else’s
apartment (fail)
• Test with an invalid key on any apartment (fail)
• Test with the key of a removed tenant on his/her previous
apartment (fail)
• Test with the valid key of a just-added tenant on his/ her
apartment (pass)

7
 Example: Test Case for Use
Case
[ Recall Section 2.3.3: Detailed Use Case Specification ]

Test-case Identifier: TC-1

Use Case Tested: UC-1, main success scenario, and UC-7

Pass/fail Criteria: The test passes if the user enters a key that is contained in the database,
with less than a maximum allowed number of unsuccessful attempts

Input Data: Numeric keycode, door identifier

Test Procedure: Expected Result:

Step 1. Type in an incorrect System beeps to indicate failure;

keycode and a valid door records unsuccessful attempt in the database;
identifier prompts the user to try again

Step 2. Type in the correct System flashes a green light to indicate success;
keycode and door identifier records successful access in the database;
disarms the lock device

8 8
 Test Coverage
• Test coverage measures the degree to which the
specification or code of a software program has
been exercised by tests
– “Big picture”: Specification testing focuses on the
coverage of the input space, without necessarily
testing each part of the software  Acceptance tests
– “Implementation details”: Code coverage measures
the degree to which the elements of the program
source code have been tested  Unit tests

9
 Heuristic: Some Tests are
More “Critical” than Others
• Test cases should be prioritized—some tests are more
likely to uncover faults
• Tests are about finding developer errors, and people are
prone to make certain kind of errors
• Some tests can easier pinpoint problems than others
• (some) Heuristics for achieving high coverage:
(could be applied individually or in combination)
– equivalence testing
– boundary testing mostly for “black-box” testing
– control-flow testing
– state-based testing mostly for “white-box” testing

10
 Input Space Coverage:
Equivalence Testing
• Equivalence testing is a black-box testing method that divides
the space of all possible inputs into equivalence groups such
that the program is expected to “behave the same” on each
input from the same group
• Assumption: A well-intentioned developer may have made mistakes that affect a
whole class of input values
• Assumption: We do not have any reason to believe that the developer intentionally
programmed special behavior for any input combinations that belong to a single class
of input values
• Two steps:
1. partitioning the values of input parameters into equivalence groups
2. choosing the test input values from each group

Equivalence classes:
valid equivalence class

0 100

11
invalid equivalence classes
 Heuristics for
Finding Equivalence Classes
• For an input parameter specified over a range of values, e.g., a
number or a letter, partition the value space into one valid and
two invalid equivalence classes
• For an input parameter specified with a single value, e.g., a
unique “security code,” partition the value space into one valid
and two invalid equivalence classes
• For an input parameter specified with a set of values, e.g., day or
month names, partition the value space into one valid and one
invalid equivalence class
• For an input parameter specified as a Boolean value, partition the
value space into one valid and one invalid equivalence class

12
 Input Space Coverage:
Boundary Testing
• Boundary testing is a special case of equivalence
testing that focuses on the boundary values of
input parameters
– Based on the assumption that developers often
overlook special cases at the boundary of
equivalence classes (e.g., Microsoft Zune bug:
https://en.m.wikipedia.org/wiki/Leap_year_bug )

• Selects elements from the “edges” of each

equivalence class, or “outliers” such as
• zero, min/max values, empty set, empty string, and null
• confusion between > and >=
• palindromes (impossible to build an FSM to recognize a palindrome code)
• etc.
13
 Code Coverage:
Control-flow Testing
• Statement coverage
• Each statement executed at least once by some test case
• Edge coverage
• Every edge (branch) of the control flow is traversed at least once by some test case
• Condition coverage
• Every condition takes TRUE and FALSE outcomes at least once in some test case
• Path coverage
• Finds the number of distinct paths through the program to be traversed at least once

Constructing the control graph of a program for Edge Coverage:

a; a; b; if a then b; if a then b else c; while a do b;

a a not a a not a
a a not a
b
b b c
b

* Exceptions are also a form of control flow, as is concurrency or multithreading 14

 Code Coverage:
State-based Testing
• State-based testing defines a set of abstract states that a
software unit (object) can take and tests the unit’s behavior
by comparing its actual states to the expected states
– This approach is popular with object-oriented systems
– Like equivalence classes, state diagrams usually are mind
constructs and may be incomplete (not showing all possible
states and transitions) or incorrect
• The state of an object is defined as a constraint on the values
of its attributes
– Because the methods use the attributes in computing the
object’s behavior, the behavior depends on the object state
– An object without attributes does not have states, but still can
be unit-tested (shown later)

15
 State-based Testing Example
(Safe Home Access System)

• Define the relevant states as combinations of object attribute

values:
1. “Locked” ≡ defined as:
(lockDeviceArmed == true) && (numOfAttempts == 0)
2. “Accepting” ≡ defined as(*):
(lockDeviceArmed == true) && (0 < numOfAttempts < maxNumOfAttempts)
3. “Unlocked” ≡ defined as:
(lockDeviceArmed == false) && (numOfAttempts == 0)
4. “Blocked” ≡ defined as:
(lockDeviceArmed == true) && (numOfAttempts == maxNumOfAttempts)
5. “Undefined” ≡ defined as:
((numOfAttempts < 0) || (maxNumOfAttempts < numOfAttempts)) ||
((lockDeviceArmed == false) && (numOfAttempts != 0))
• Define the relevant events:
1. User entered a valid key
2. User entered an invalid key

(*) One may argue that “Locked” is a sub-state of “Accepting” … 16

 State-based Testing Example

event guard condition

invalid-key [numOfAttemps  maxNumOfAttempts] /

signal-failure
action
invalid-key / invalid-key
signal-failure [numOfAttemps  maxNumOfAttempts] /
Locked Accepting sound-alarm

state valid-key /
signal-success

transition Blocked
valid-key /
signal-success

Unlocked

17
State-based Testing Example

invalid-key [numOfAttemps  maxNumOfAttempts] /

signal-failure

invalid-key / invalid-key
signal-failure [numOfAttemps  maxNumOfAttempts] /
Locked Accepting sound-alarm
(counting attempts)

valid-key /
signal-success

valid-key / Blocked
signal-success

Unlocked

18
Controller State Diagram Elements
• Four states
{ Locked, Unlocked, Accepting, Blocked }
• Two events
{ valid-key, invalid-key }
• Five valid transitions
{ LockedUnlocked, LockedAccepting,
AcceptingAccepting, AcceptingUnlocked,
AcceptingBlocked }
19
 Ensure State Coverage Conditions

Cover all identified states at least once

(each state is part of at least one test case)

Cover all valid transitions at least once

Trigger all invalid transitions at least once

20
 Practical Aspects of Unit Testing
• Mock objects:
– A test driver simulates the part of the system that invokes
operations on the tested component
– A test stub simulates the components that are called by the
tested component
• Mock objects needed because:
– The corresponding actual objects are not available
– Easier to locate faults using mock objects that are trivial
and therefore not a source of faults
• The unit to be tested is also known as the fixture
• Unit testing follows this cycle:
1. Create the thing to be tested (fixture), the driver, and the
stub(s)
2. Have the test driver invoke an operation on the fixture
3. Evaluate that the actual state equals expected state
21
 Testing the KeyChecker (Unlock Use
Case)

Test driver Tested component Test stubs

: Controller k : Key : Checker : KeyStorage testDriver : : Checker k : Key : KeyStorage

enterKey() start()
k := create() k := create()

loop [for all stored keys]

val := checkKey(k) result :=
sk := getNext() checkKey(k) loop [for all stored keys]
compare() sk := getNext()
compare()

display
result

(a) (b)

22
 Example Test Case
Listing 2-1: Example test case for the Key Checker class.

public class CheckerTest {

// test case to check that invalid key is rejected
@Test public void
checkKey_anyState_invalidKeyRejected() {

// 1. set up // no states defined for Key Checker

Checker fixture = new Checker( /* constructor params */ );

// 2. act // test driver (this object) invokes tested object (Key Checker)
Key invalidTestKey = new Key( /* setup with invalid code */ );
boolean result = fixture.checkKey(invalidTestKey);

// 3. verify // check that invalid key is rejected

assertEqual(result, false);
}
}
23
 Test Case Method Naming

1. Set up
methodName_startingState_expectedResult
2. Act
3. Verify

Example test case method name:

checkKey_anyState_invalidKeyRejected()

24
 xUnit / JUnit
• Verification of the expected result is usually
done using the assert_*_() methods that
define the expected state and report errors if
the actual state differs
• http://www.junit.org/
• Examples:
– assertTrue(4 == (2 * 2));
– assertEquals(expected, actual);
– assertNull(Object object);
– etc. 25
Another Test Case Example
Listing 2-2: Example test case for the Controller class.

public class ControllerTest {

// test case to check that the state Blocked is visited
@Test public void
enterKey_accepting_toBlocked() {

// 1. set up: bring the fixture to the starting state

Controller fixture = new Controller( /* constructor params */ );
// bring Controller to the Accepting state, just before it blocks
Key invalidTestKey = new Key( /* setup with invalid code */ );
for (i=0; i < fixture.getMaxNumOfAttempts(); i++) {
fixture.enterKey(invalidTestKey);
}
assertEqual( // check that the starting state is set up
fixture.getNumOfAttempts(), fixture.getMaxNumOfAttempts() – 1
);

// 2. act
fixture.enterKey(invalidTestKey);

// 3. verify
assertEqual( // the resulting state must be "Blocked"
fixture.getNumOfAttempts(), fixture.getMaxNumOfAttempts()
);
assertEqual(fixture.isBlocked(), true);
}
26
}
 Integration Testing
• Key Issue:
– How to assemble individually-tested “units” and quickly locate faults that
surface during integration
• Horizontal Integration Testing
– “Big bang” integration
• Problem: hard to isolate individual unit(s) that caused an integration fault
– Bottom-up integration
– Top-down integration
– Sandwich integration

• Vertical Integration Testing

– Vertically slice the system by use cases and first integrate within each
slice (using any of the horizontal integration techniques)
27
 Horizontal Integration Testing
Controller
Level-4

Level-3 KeyChecker
System
hierarchy: Level-2 KeyStorage Key

Level-1 Logger PhotoSObsrv DeviceCtrl

Implementation and testing proceeds from Level-1 (bottom) to Level-4 (top)

Test
Logger Test Controller &
Bottom-up Test
KeyChecker & KeyStorage &
Key & Logger & PhotoSObsrv

integration PhotoSObsrv & DeviceCtrl

testing: Test
DeviceCtrl Test KeyChecker
Advantages:
& KeyStorage & • only few mock objects need to be implemented
Key
Test Key & Drawbacks:
KeyStorage
• end user cannot see any functionality
until late in the development process
Implementation and testing proceeds from Level-4 (top) to Level-1 (bottom)
Top-down Test Controller &
Test Test Controller &
integration Test
Controller
Controller &
KeyChecker
KeyChecker &
KeyStorage & Key
KeyChecker & KeyStorage &
Key & Logger & PhotoSObsrv
& DeviceCtrl
testing: 28
 Vertical Integration Testing
User User User
story-1 story-2 story-N inner feedback loop

Write a
Write a failing Make the
failing
acceptance test test pass
unit test

Refactor
outer feedback loop

Developing user stories:

Whole system Each story is developed in a cycle that integrates
unit tests in the inner feedback loop and the
acceptance test in the outer feedback loop
29
 Logical Organization of Testing
( Not necessarily how it’s actually done! )
Component
code
Unit
test

Component
code
Unit
test Integrated
modules
Integration System
test test
System
in use
Ensures that all
Component components
code work together
Unit
test

Ensure that each Function Quality Acceptance Installation

component works test test test test
as specified

Verifies that functional Verifies non- Customer Testing in

requirements are functional verifies all user
satisfied requirements requirements environment
30
 System Testing
• To test the whole system in our case study of
safe home access,
we need to work with a locksmith and
electrician to check that the lock and electrical
wiring are properly working,
or with a third party software developer (if 3rd
party software is used)
 Security Honeypots

• A deception used to detect and study network

attacks
– Part of security testing of software systems
 Honeypot Access Control

Who are the users?

• Attackers:
– Access the VM set up for them

• Researchers
– Access the host, the attackers’ VM
– Should not erase files by mistake…
33
Honeypot Access Control Matrix

Asset Access Control List

Role\ Asset Attacker VM Others Attack’s VM HOST

Attacker Deploy, Read, Write None None

Researcher None Full Full, with confirmation

Role capabilities

34
 Honeypot Access Control

Who are the users?

• Attackers
– Script kiddies: 95%
• Untrusted
• Run malware found on the internet
• Easy to protect against
– Advanced attackers: 5%
• Untrusted
• Are able to understand and evade the system
• Harder to protect against
• Researchers  Refine the access control for the new distinction!
– Trusted
– Can erase file by mistake…
35
System Specifications Intro - Topics
• Domains, Phenomena
• States, Events
• Context Diagrams
• Systems and System Descriptions
• Basic Formalisms for Specifications
– Boolean Logic
– Finite State Machines
36
World, Parts, Phenomena
WORLD

Part/Domain I Part/Domain J

Phenomena in Part i

Phenomena in Part j
Shared
phenomena

Phenomena in Part k

Part/Domain K

37
Example of a Problem Domains
PROBLEM WORLD & DOMAINS (PARTS)

(5) Device
(6) Photosensor
preferences
(3) Key
(7) Light

(1) Tenant (4) List of

valid keys
(3) Lock

(8) Alarm bell (11) Log of

accesses
Software-to-be

(2) Landlord
(10) Tenant
(9) Desktop computer accounts

38
Example of Problem Domains
PROBLEM WORLD & DOMAINS (PARTS)

(5) Device
(6) Photosensor
preferences
(3) Key
(7) Light

(1) Tenant (4) List of

valid keys
(3) Lock

(8) Alarm bell (11) Log of

accesses
Software-to-be

(2) Landlord
(10) Tenant
(9) Desktop computer accounts

39
Example of Problem Domains

(5) Device
(6) Photosensor
preference
(3) Key
s (7) Light

(1) Tenant (4) List of

valid
keys (3) Lock

(8) Alarm bell (11) Log

of
Software-to-be accesses

(2) Landlord
(10) Tenant
(9) Desktop computer accounts

40
 Definitions …
• A phenomenon is a fact, or object, or occurrence that
appears or is perceived to exist

• An event is an individual happening, occurring

at a particular point in time
– Events are indivisible and instantaneous
• A state is a relation among individual entities
and values, which can change over time
• Individuals are in relation if they share a
certain characteristic
– RelationName(Individual1, …, Individualn) 41
 Events
Events take place at transitions between the states

2 Event: Kick

Elevation of the ball

3 State:
Ball flying
Event: Kick

1
State:
Ball standing 4
Event: Splash

Event: Splash
State:
5 Ball floating 42
Time
 Relations: Examples
Set of all pairs of persons

Set of neighbors

Relation: Neighbors (Person_i, Person_j) Set of all 3-tuples of bread slices

and ham

Set of sandwiches

Relation:
Sandwich (Bread-slice, Ham-slice, Bread-slice)
43
 Example: States of a DVD Player
State 1: NotPowered (the player is not powered up)
State 2: Powered (the player is powered up)
State 3: Loaded (a disc is in the tray)
State 4: Playing

State 1: NotPoweredEmpty (the player is not powered up and contains no disc)

State 2: NotPoweredLoaded (the player is not powered up and a disc is in the t
State 3: PoweredEmpty (the player is powered up and contains no disc)
State 4: PoweredLoaded (the player is powered up and a disc is in the tray)
State 5: Playing
44
 Different Abstractions
(Level of detail)

DVD player

Power Disc
button tray

DVD player Play

button …

Atomic object Object composed of parts

45
Example: States of a DVD Player

System Part (Object) State Relations

Power button {Off, On}

Disc tray {Empty, Loaded}

Play button {Off, On}

… …

46
 State Variables
State variable = a physical part or an attribute of an obje

State Variable State Relations

Door lock {Disarmed, Armed}

Light bulb {Unlit, Lit}

Counter of failed attempts {0, 1, …, maxNumOfAttempts}

Auto-lock timer {0, 1, …, autoLockInterval}

47
 Hidden States

Observable state:
apple’s appearance

Goal:

Find the likelihood of

different hidden states,
Hidden state: for given observable
contains a worm states

48
 States Example: Stock Market

Market
index
Market
Open Closed
gate
1.00 1.01 1.02

Stock_1_Price Stock_1_Shares Stock_2_Price Stock_2_Shares

1.00 1 1.00 1

1.01 2 1.01 2

1.02 3 1.02 3
( prices & number of
shares
for all listed stocks )

49
 Defining States

• CountingDown(Timer) =
The relation Equals(Timer, ) holds true for 
decreasing with time

• Idle(Timer) =
The relation Equals(Timer, ) holds true for 
remaining constant with time

50
 Microstates and Macrostates
Microstates representing the number of offered shares are aggregated:

OrderPending OrderExecuted

x2 x 1 x x 1 x2

51
 Events
Events marking transitions between the states of a trading order:

submit matched archive

InPreparation Pending Executed Archived

Event Description
trade Causes transition between stock states Buy, Sell, or Hold
submit Causes transition between trading-order states
InPreparation  OrderPending
matched Causes transition between trading-order states
OrderPending  OrderExecuted
… …
… … 52 52
 Context Diagram: DVD Player

Play Context diagram symbols:

enable button
disable notify A box with a double
start stripe is a software-to-be
stop domain
(or, machine domain)
activate activate
shut down Power shut down A box with a single
Disc tray Display stripe is a designed
eject (?) button
domain

eject
A box with no stripe
load
is a given domain
enable notify
disable Eject
button

53
 Context Diagram: Stock Trading

Investmen Trading
t portfolio order

Software-to- Stock
Trader be exchang
(Machine) e

ith stock

Bank

54
 Problem Decomposition
REQ1, REQ2,
REQ3 REQ3, REQ4
PROBLEM DOMAIN

(5) Device
(6) Photosensor
preferences
(7) Light
Subsystem-2
(3) Key

(1) Tenant (4) List of

Subsystem-1
valid keys
(3) Lock

REQ4
Subsystem-3 (8) Alarm bell (11) Log of
accesses
Software-to-be

(2) Landlord
(10) Tenant
Subsystem-4 (9) Desktop computer accounts

REQ5, REQ7,
REQ8, REQ9
55
Machine and Problem Domain

(a) Software-to- a Problem

b The
be
Domain Requirement
(The Machine)

Domain properties
seen by the requirement
(b)
Software-to- a Problem
b The
be
Domain Requirement
(The Machine)

Specification Domain properties Requirement

seen by the software-to-be
a: specification interface phenomena
b: requirement interface phenomena

56
 Boolean Logic

Propositional Logic

 conjunction (p and q)  implication (if p then q)

 disjunction (p or q)  biconditional (p if and only if q)

 negation (not p)  equivalence (p is equivalent to q)

Predicate Logic (extends propositional logic with two quantifiers)

 universal quantification (for all x, P(x))

 existential quantification (there exists x, P(x))

57 57
Example: From Req’t to Propositions

Label Declarative sentence (not necessarily a proposition!)

a The investor can register with the system
b The email address entered by the investor exists in real world
c The email address entered by the investor is external to our website
d The login ID entered by the investor is unique
e The password entered by the investor conforms to the guidelines
f The investor enters his/her first and last name, and other demographic info
g Registration is successful
h Account with zero balance is set up for the investor

REQ1 represented as a set of propositions

a
( email)( id)( pwd) [B(email)  C(email)  D(id)  E(pwd)  g]
f
gh 58 58
 Example: From Req’t to Propositions
Label Propositions (partial list)
m The action specified by the investor is “buy”
n The investor specified the upper bound of the “buy” price
o The investor specified the lower bound of the “sell” price

Label Propositions (they complete the above list)

p The investor requests to place a market order
q The investor is shown a blank ticket where the trade can be specified (action, symbol, etc.)
r The most recently retrieved indicative price is shown in the currently open order ticket
s The symbol SYM specified by the investor is a valid ticker symbol
t The current indicative price that is obtained from the exchange
u The system executes the trade
v The system calculates the player’s account new balance
w The system issues a confirmation about the outcome of the transaction
x The system archives the transaction
REQ2 represented as a set of propositions
pqr
s
y = v  {(n  o)  [(o  p  o  q)  ( IP)(LB  IP  UB)]}
z = m  {[n  (VOL  IP  BAL)]  [n  (VOL  UB  BAL)]}
yzu
59 59
uvwx
FSM State Transition Diagram
lock unlock unlock

Closed Open

lock

Start v = (input-key  Valid-keys)

i = (input-key  Valid-keys)
v i i M = maxNumOfAttempts

0 1 2 M

60
 FSMs with Outputs
lock unlock / beep unlock

(a) Closed Open

lock / beep

lock unlock [key  Valid-keys] / beep unlock

(b) Closed Open

lock / beep

61
Sys. Specifications - State Diagrams
Topics
• UML State Machine Diagrams
– State Activities: Entry, Do, and Exit Activities
– Composite States and Nested States
– Concurrency
• UML Object Constraint Language (OCL)
– OCL Syntax
– OCL Constraints and Contracts

62
 State Machine Diagram:
Basic Notation
States of Stock_i
event
trade bankruptcy,
merger,
initial-listing acquisition, …
Listing
Traded Delisted
planned

transition
initial state terminal state

indicated by indicated by

These are not states:

They are only labels that indicate the actual initial/terminal states
63
 UML Diagrams Differ from FSMs
• Modularization of states
• Concurrent behaviors
• State activities

64
 States of Stock_i
trade bankruptcy,
merger,
initial-listing acquisition, …
Listing
Traded Delisted
planned

composite state

Traded

Listing
Delisted
planned Buy Hold Sell

sub-states:
(based on analyst recommendations)

trade
trade trade

trade trade
Buy Hold Sell
trade trade

65
trade
 States of Stock_i
trade bankruptcy,
acquisition,
initial-listing merger, …
IPO
Traded Delisted
planned
IPO = initial public offering

Traded
bankruptcy,
trade
acquisition,
initial- trade trade merger, …
listing
IPO trade trade
Delisted
planned Buy Hold Sell
trade trade

nested
trade
composite state state

66
 State Activities:
Entry, Do, and Exit Activities
States of a Trading Order
completion transition

view
Pending
submit matched
do: check_price & supply [buy]
InPreparation Executed Archived
check_price & demand [sell]

data cancel,
entry reject
trade Cancelled
“do”
state
activity
(order placed and waiting for
the specified market conditions)

67
 State Diagram for Controller
[ Recall Section 2.7.4: Test Coverage and Code Coverage ]

How state diagram motivates you to consider alternative usage scenarios and provides “crutches”:

User leaves without succeeding or blocking

invalid-key [numOfAttemps  maxNumOfAttempts] /
signal-failure

invalid-key /
signal-failure invalid-key
[numOfAttemps  maxNumOfAttempts] /
sound-alarm
Locked Accepting
timer-expired /
signal-reset,
set numOfAttemps := 0
autoLockInterval
-expired /

valid-key /
signal-success valid-key / Blocked
signal-success,
set numOfAttemps := 0

Unlocked

Note how the object responds differently to

Auto-locking feature not shown! the same event (invalid-key in Accepting state),
depending on which events preceded it 68
 State Diagram for Controller

invalid-key [numOfAttemps  maxNumOfAttempts] /

signal-failure

invalid-key /
signal-failure invalid-key
Accepting [numOfAttemps  maxNumOfAttempts] /
sound-alarm
Locked entry: start timer
do: countdown
timer-expired /
signal-reset,
set numOfAttemps := 0
autoLockInterval
-expired /

valid-key /
signal-success Blocked
valid-key /
signal-success
Unlocked
entry: start timer
do: countdown

Need “entry” and “do” state activities

for countdown timers 69
 State “Accepting” Refined

Accepting
timer-expired /
signal-reset,
set numOfAttemps := 0

invalid-key / invalid-key /
invalid-key / signal-failure signal-failure invalid-key /
signal-failure sound-alarm
One Two MaxNumOfAttempts

valid-key / valid-key /
signal-success signal-success valid-key /
signal-success

Or, get rid of state “Accepting” and introduce state “Zero” …

70
Problem: States of a Hotel Room
Problem:
- but a guest may be occupying the room
make-reservation / while it is reserved by a future guest!?
Reserved
- or the room may be vacant
while reserved by a future guest!?

Vacant arrive /

depart /
Occupied

 need a notion of time (“timing diagram”)

71
 Problem: States of a Hotel Room

C make-reservation
B make-reservation
Reserved Reserved
by guest B by guest C
Reserved
States

Occupied

Vacant

Time [days]
A depart

B depart
C arrive
A arrive

B arrive

C depart

72
 Problem: States of a Hotel Room

C make-reservation
B make-reservation
 What if the guest is late? – “Holding” state?
 What if the room is overbooked?
Reserved Reserved
 What when it is being cleaned?
by guest B by guest C
Reserved
Issue: state transitions
What state? are weird—”Reserved” is a
future state but
Occupied transitioned to by a
current event!

Vacant

Time [days]
A arrive

B arrive
A depart

B depart
C arrive

C depart

73
 Problem: States of a Hotel Room
SOLUTION:

C make-reservation
B make-reservation
Introduce a new object!
Reserved Reserved
by guest B by guest C
Reserved
Object:
Reservation table
Available
reserve

free

Occupied

Object:
Room occupancy
Vacant
current time

Time [days]
A arrive

A depart

Objects send messages that change states

74
 Problem: States of a Hotel Room
We need two objects:
One tracks room’s current state (occupancy)
and the other its future state (reservation)

Reserved
Object 2:
Reservation table
Available

Occupied

Object 1:
Room occupancy
Vacant
current time

Time [days]
A arrive

B arrive
A depart

B depart
C arrive

C depart

75
 OCL: Object Constraint Language
• OCL is used in UML diagrams to
– write constraints in class diagrams
– guard conditions in state and activity diagrams
• based on Boolean logic
• Boolean expressions (“OCL constraints”) used
to state facts about elements of UML diagrams
• The implementation must ensure that the
constraints always hold true
76
 Basic OCL Types and Operations

Type Values Operations

Boolean true, false and, or, xor, not, implies, if-then-else

Integer 1, 48, 3, 84967, … *, , , /, abs()

Real 0.5, 3.14159265, 1.e+5 *, , , /, floor()

String 'With more exploration comes more text.' concat(), size(), substring()

77 77
 OCL: Types of Navigation

(a) Local attribute (b) Directly related class (c) Indirectly related class
Class_A Class_A Class_A
– attribute1 * assocBA * assocBA
– attribute2
– …

* assocAB * assocAB

Class_B Class_B

* assocCB

* assocBC

Class_C

Within Class_A: Within Class_A: Within Class_A:

self.attribute2 self.assocAB self.assocAB.assocBC
78
 Accessing Collections in OCL
OCL Notation Meaning
EXAMPLE OPERATIONS ON ALL OCL COLLECTIONS
c->size() Returns the number of elements in the collection c.
c->isEmpty() Returns true if c has no elements, false otherwise.
c1->includesAll(c2) Returns true if every element of c2 is found in c1.
c1->excludesAll(c2) Returns true if no element of c2 is found in c1.
Returns true if the Boolean expression expr true for all elements in c. As an element is being
c->forAll(var | expr) evaluated, it is bound to the variable var, which can be used in expr. This implements universal
quantification .
Same as above, except that expr is evaluated for every possible pair of elements from c, including the
c->forAll(var1, var2 | expr)
cases where the pair consists of the same element.

Returns true if there exists at least one element in c for which expr is true. This implements existential
c->exists(var | expr)
quantification .

c->isUnique(var | expr) Returns true if expr evaluates to a different value when applied to every element of c.

c->select(expr) Returns a collection that contains only the elements of c for which expr is true.

EXAMPLE OPERATIONS SPECIFIC TO OCL SETS

s1->intersection(s2) Returns the set of the elements found in s1 and also in s2.
s1->union(s2) Returns the set of the elements found either s1 or s2.
s->excluding(x) Returns the set s without object x.
EXAMPLE OPERATION SPECIFIC TO OCL SEQUENCES
79 79
seq->first() Returns the object that is the first element in the sequence seq.
 OCL Constraints and Contracts
• A contract specifies constraints on the class state that must be
valid always or at certain times, such as before or after an operation is
invoked
• Three types of constraints in OCL: invariants, preconditions, and
postconditions
 An invariant must always evaluate to true for all instance objects
of a class, regardless of what operation is invoked and in what
order
• applies to a class attribute
 A precondition is a predicate that is checked before an operation
is executed
• applies to a specific operation; used to validate input parameters
 A postcondition is a predicate that must be true after an
operation is executed
• also applies to a specific operation; describes how the object’s state was
changed by an operation
80
 Example Constraints (1)
• Invariant: the maximum allowed number of
failed attempts at disarming the lock must be a
positive integer
– context Controller inv:
self.getMaxNumOfAttempts() > 0

• Precondition: to execute enterKey() the

number of failed attempts must be less than
the maximum allowed number
– context Controller::enterKey(k :
Key) : boolean pre:
self.getNumOfAttempts()  81
 Example Constraints (2)
• The postconditions for enterKey() are
– (Poc1) a failed attempt is recorded
– (Poc2) if the number of failed attempts reached the maximum allowed, the system
blocks and the alarm bell blurts
– Reformulate (Poc1) to:
(Poc1) if the key is not element of the set of valid keys, then the counter of failed
attempts after exiting from enterKey() must be by one greater than before
entering enterKey()
• context Controller::enterKey(k : Key) : Boolean
-- postcondition (Poc1):
post: let allValidKeys : Set = self.checker.validKeys()
if allValidKeys.exists(vk | k = vk) then
getNumOfAttempts() = getNumOfAttempts()@pre
else
getNumOfAttempts() = getNumOfAttempts()@pre + 1
• -- postcondition (Poc2):
post: getNumOfAttempts() >= getMaxNumOfAttempts() implies
self.isBlocked() and self.alarmCtrl.isOn()

82
 xUnit / JUnit assert_*_()
• Verification is usually done using the
assert_*_() methods that define the
expected state and raise errors if the actual
state differs
• http://www.junit.org/
• Examples:
– assertTrue(4 == (2 * 2));
– assertEquals(expected, actual);
– assertNull(Object object);
– etc. 83
 TLA+ Specification

lock,
unlock(invalid key)

unlock(valid key)
[closed, unlit] [open, lit]

lock unlock(valid key)

turnLightOff
(?) [closed, lit]

lock,
unlock(invalid key)
MAIN CONFUSION:
What is this state diagram representing?
The state of _what_ object?

84
 Problem Frames – Decomposition
Topics
• Typical System Requirements and Problems
→ Analysis Reuse
• Five Problem Frames:
• Transformation
• Simple Editing (a.k.a. “Simple Workpieces”)
• Required Behavior
• Information Display
• Commanded Behavior
• Frame Concern
 Why Problem Frames?
• Because the best way to start solving your problem
is by understanding it first
– Problem frames help us analyze and understand the
problem that we are to solve
• Problem frames are the building blocks of SE
problems
– They are the most basic types of system requirements
• Purpose: problem frames allow reuse of existing
generic analyses of typical problems
– Benefits: speed up the analysis and make the result more
correct and complete
 Software Engineering Problem
• User has business goals in the problem domain
• System-to-be will help the user achieve these goals
• Problem domain can be imagined or physical world
System-to-be
 User’s business
goals determine the
system
User
requirements
Requirement

Problem Domain
 Requirements and Specification
Problem domain Software (Solution) domain

Describes

Specifi
Requirements Program (System)
Customer cation

Specifies

Analyzes Develops

Software Engineer
 Problem Domain:
How Electronic Lock Works
We may need separate
1
2
3
4
descriptions/models of
5
X
Y
door vs. lock.
Door state is what the
Computer user cares about; lock is
Lock
one way of achieving it.

Voltage:
HIGH Physical domain (lock)
description; used in
LOW
specification
lock armed lock disarmed lock armed Semantic meaning
defined by user’s
goals; used in
requirements

The behavior of the system-to-be determined not only by user’s actions

but also by the context (“situation”).
E.g., what in case of power failure?
- By default armed
- By default disarmed (e.g., fire exit)
 Analyst’s Task: Three Descriptions
The requirement
The problem domain
What user The specification
How problem
wants:
domain behaves: What software-to-
When valid keycode entered +
Unlock pressed, open the be will do (at
lock;
Automatically lock after a
Armed interface):
period of time. If entered number matches one of
LOW / HIGH / stored numbers + Button-1
pressed, put HIGH voltage on
Output-port-1;
Disarmed Start a timer countdown;
When the timer expires,
1
2
3
Concern:
put LOW voltage on Output-port-1.
Electromechanical lock 4
5

It is not obvious that this is the

X
Y

only or even “correct” solution

to the requirement-posed
problem.
Problem Frames tell us what each description should contain and how to verify the concern.
 Problem Framing

• Problem framing means dividing the problem at

its “seams” into smaller sub-problems
– The difficulty is in recognizing the “seams”
• Problem frames are derived from commonly
occurring software requirements
– They afford ready-made templates for requirements
analysis and system specification
– We look for such basic problems to help us discover
the “seams” of our problem
 Complex Problem Decomposition
Problem Business Goal
(a) Software-to-be
Domain (User’s Requirement)

Problem decomposition
Frame Approach:
Split the big “black

Requirement
ii
box” into several
smaller “black
boxes”, each

Domain
addressing a
B
subset of the
requirements and
representing a(b)
Subsystem
2

mini-project.
During the Software-to-be

analysis, we
 Typical Software Eng. Problems
1.a) System transforms input document to output document
1. User works with computer system
(problem domain is “virtual”, not physical)
REQ-1: Map input data to IN doc
output data as said by given
rules
User System OUT doc

1.b) User edits information stored in a repository

User System Problem domain

REQ-2: Allow repository editing,

where “repository” is a collection of
data User System Repository

2. Computer system controls the (physical) problem domain

(user not involved) REQ-3: Autonomously
control a physical
object/device
User System Problem domain

3. Computer system intermediates between 3.a) System observes the problem domain and displays informatio
the user and the problem domain
REQ-5: Monitor and
display information about
an object User System Problem domain

User System Problem domain 3.b) System controls the problem domain as commanded by the us

REQ-4: Interactively
control a physical 93
object/device User System Problem domain
 5-dimensional Problem Space
• The five elementary problem types
represent the coordinate system of
(“Simple workpieces”)

Software
the problem space
(“Required behavior”)

Simple editing

problem
Autonomous control

to solve
• The “axis” projections represent the
degree to which the whole problem
contains a subproblem of this type
• Each subproblem can be analyzed
independently and eventually
recombined into the whole problem
• The structure of the solution should
be selected to fit the problem
structure

94
 Typical System Requirements
• REQ-1: Map input data to output data as said by given
rules
• REQ-2: Allow repository (or document) editing, where
“repository” is a collection of data
• REQ-3: Autonomously control a physical object/device
• REQ-4: Interactively control a physical object/device
• REQ-5: Monitor and display information about an object
Critical insight: there are known approaches for analyzing
each of these requirement types, including the information
that should be specified for each type
 Example: Problem Decomposition
REQ1: Keep door locked and auto-lock
REQ2: Lock when “LOCK” pressed
REQ3: Unlock when valid key provided
REQ4: Allow mistakes but prevent dictionary attacks
REQ5: Maintain a history log
REQ6: Adding/removing users at runtime
REQ7: Configuring device activation preferences
REQ8: Inspecting the access history
REQ9: Filing inquiries

PROBLEM DOMAIN

(5) Device
(6) Photosensor preference
s (7) Light
(3) Key

(1) Tenant (4) List of

valid
keys (3) Lock

(8) Alarm bell (11) Log

of
Software-to-be accesses

(2) Landlord
(10) Tenant
(9) Desktop computer accounts

Difficult to consider the whole system at once…

 Example: Problem Decomposition
REQ1: Keep door locked and auto-lock
REQ2: Lock when “LOCK” pressed
REQ3: Unlock when valid key provided
REQ4: Allow mistakes but prevent dictionary attacks
REQ5: Maintain a history log
REQ6: Adding/removing users at runtime
REQ7: Configuring device activation preferences
REQ8: Inspecting the access history REQ1, REQ2,
REQ9: Filing inquiries REQ3 REQ3, REQ4
PROBLEM DOMAIN

(5) Device
(6) Photosensor preference
s (7) Light
Subsystem-2
(3) Key

(1) Tenant (4) List of

Subsystem-1
valid
keys (3) Lock

REQ4
Subsystem-3 (8) Alarm bell (11) Log
of
Software-to-be accesses

(2) Landlord
(10) Tenant
REQ5, REQ7, Subsystem-4 (9) Desktop computer accounts
REQ8, REQ9

 Decompose the system based on its requirements

Problem and Solution Domain
This we need to find This is given This is a condition to satisfy
(solution)
(a) Problem
Software-to-be a Domain
b Business Goal

Domain properties
envisioned by the requirement
(b)

Problem
Software-to-be a Domain
b Business Goal

Specification Domain properties Requirement

sensed by the software-to-be
a: specification interface phenomena (system inputs/outputs)
b: requirement interface phenomena (user goals and interaction)
Description of what actually happens in the problem
Description of what the user is trying to achieve
domain versus in what form it will appear as system
in the problem domain and how is the user
input;
supposed to interact with the system to make it
as well as what output will the system issue versus
happen.
what should happens in the problem domain.
 Notation Syntax
for Problem Frames
• C – causal domain Causal
domain
• predictable causal relationships among its causal phenomena C

such as physical laws or business contracts or social norms

• B – biddable domain Biddable

domain
B
• usually people: unpredictable, incoercible
• X – lexical domain Lexical
• a physical representation of data (i.e., symbolic phenomena) domain
X

• [C] - causal phenomena

• events, states; directly produced or controlled by an entity;
can give rise to other phenomena in turn
• [E] - events

Problem
System

Domain
a
• [Y] – symbolic requirement phenomena
a: S ! E1
• values, and truths and states relating only values; PD ! C2
symbolize other phenomena and relationships among them
 Example: Problem Decomposition
[ Case Study 1: Safe Home Access ]
• REQ1: keep door locked and auto-lock Required Behavior
• REQ2: lock when “LOCK” pressed
• REQ3: unlock when valid key provided Commanded Behavior
• REQ4: allow mistakes but prevent dictionary attacks

• REQ5: maintain a history log Information Display (database is the “di

• REQ6: adding/removing users at runtime
Simple Editing
• REQ7: configuring device activation preferences
Simple Editing
• REQ8: inspecting the access history
Information Display
• REQ9: filing inquiries
Simple Editing
 Example: Problem Decomposition
[ Case Study 2: Investment Fantasy League ]
• REQ1: view market prices and volumes Information Display
– Domains: exchange, display
• REQ2: place a trade Simple Editing
– Domains: investor, tradable-securities, pending-trades
•
Required Behavior
REQ3: execute trades when conditions matched
– Domains: exchange, pending-trades
• REQ4: generate periodic report
– Domains: portfolio, report Transformation
• REQ5: generate leaderboard
– Domains: all-portfolios, leaderboard Transformation
• REQ6: view leaderboard
– Domains: leaderboard, display Information Display
• REQ7: start a trading group/clique
– Domains: investor, group Simple Editing
• REQ8: invite to a trading group/clique
– Domains: investor, friends, group Commanded Behavior
 Basic Frame 1: Required Behavior
System outputs
to the Description of the
environment domain’s required
behavior
Control
CS!C1 Controlled
C3 Required
Software Domain Behavior
CD!C2 C

Environment Key:
inputs to the
system
C Causal domain
X Lexical domain
[C  ] Causal phenomena
[E  ] Events

Example: Execute a Trading order [Y  ] Symbolic requirement phenomena

Control Controlled Required

Software Domain Behavior

Broker Stock Trading order

Software
a Exchange
b handling rules
C

a: BS! {Execute[i], Cancel[i]} [C1] b: SE! {Submit[i], Revoke[i], [C3]

SE! {PriceQuotes, Ack[i], Failed[i]} [C2] Fulfilled[i], Failed[i], Expired[i]}
 Required Behavior
- Frame Concern Checklist
Required Behavior Frame Checklist
 Frame requirement: Autonomously control an object (“domain”)
 Describe the business goals to be achieved
 Description of the controlled domain:
 Describe the (relevant) behavioral rules of the domain
What the three
 Specification of the system-to-be: descriptions of a
 What inputs the system will receive and outputs produce

 Capabilities of the available “sensors” (inputs):

“Required Behavior”
 Sensed parameters: type, sampling rate, precision, … Frame should contain
 Capabilities of available “actuators” (outputs):
 Actuation parameters: type, acting rate, strength, …

[ Case Study 1: Safe Home Access — REQ1: keep door locked and auto-lock ]
Business goal for REQ1:
The lock will be armed electronically and periodically checked that it remains so until explicitly disarmed
If the user unlocks, but forgets to lock, the lock will be automatically disarmed after a specified interval
Description of the electromechanical lock (problem domain):
A low or none voltage keeps the latch extended (“armed”);
A high voltage causes mechanical retraction of the latch (“disarmed”) and remains retracted until low voltage.
Capabilities of available “sensors”:
The lock device will report current status when queried via USB protocol, using a command
Capabilities of available “actuators”:
The lock device’s latch will extend or retract, as commanded via USB protocol, using a command
 Requirement:
REQ1 - keep door locked and auto-lock

Locked

“Unlock” pressed [valid-key] /

after autoLockInterval/

“Lock” pressed /

Unlocked
entry: start autoLock timer
do: countdown

Need “entry” and “do” state

activities for countdown timers 104
 Problem Domain Properties:
How Electronic Lock Works

1
2
3
4
5
X
Y

Computer
Lock

The system-to-be will set one

Voltage: of its output lines to “high
HIGH
voltage”, but only the human
LOW user will know the semantic
meaning of this action (i.e.,
lock armed lock disarmed lock armed “disarm the lock”)

This information is not given.

These are deliberate decisions that the
What in case of power failure? developer needs to make, based on
understanding of the problem domain.
- By default armed It is not enough to consider how the
physical device behaves; we may also
- By default disarmed (e.g., fire exit) need to consider state laws, public safety
 Required Behavior
- Domain Model -

System outputs
to the Description of the
environment domain’s required
behavior
Control
CS!C1 Controlled
C3 Required
Software Domain Behavior
CD!C2 C
Environment
inputs to the
system

Problem Frame
checklist helps
Sensor1 Descriptor Actuator1 Descriptor

- sampling Rate - acting Rate

with identifying
- precision
-…
- magnitude
-… the conceptual
software objects
Control Rule during Object-
- constraint 1
- constraint 2
Oriented Analysis
-…
 Basic Frame 2: Commanded Behavior
CS!C1 Controlled
CD!C2 domain
C C3

Control Command
software behaviors

OP!E4 Operator E4
B

Example: Submit a Trading order

Controlled domain

A Command
Control software a b behavior
C

C D

c B c
B

Operator
a: TS! {Create[i]} [E1] c: TR! {Submit[i], Cancel[i],
b: TR! {PriceQuotes, Submit[i]} [Y2] Executed[i], Expired[i]} [Y3]
 Commanded Behavior
- Frame Concern Checklist
Commanded Behavior Frame Checklist Document what the user will be
able to do and how the system
Requested user commands: will help them do, or what the
 List of desired user commands and their parameters user should not do and how the
Command applicability under different scenarios: system will prevent these
 Description of scenarios for which each command actions
is applicable
Consequences of unacceptable commands:
 What should happen if the user tries to execute a command
that is not supported or not allowed in the current scenario

[ Case Study 1: Safe Home Access — REQ2: ℓock when “LOCK” pressed
REQ3: unlock when valid key provided
REQ4: allow mistakes but prevent dictionary attacks
Requested user commands (REQ2, REQ3):
Lock, Unlock(key, door-ID)
Command applicability under different scenarios (REQ2 - REQ4):
Lock has no restrictions (always applicable)
Unlock applicable only if numOfAttemps  maxNumOfAttempts
Consequences of unacceptable commands (REQ4):
When entered key does not correspond to the door-ID, increment numOfAttemps (block if > maxNumOfAttempts)
When not applicable, Unlock will be ignored
 Requirement:
REQ3, REQ4, REQ5 - unlock when valid key provided but allow few mistakes

invalid-key [numOfAttemps  maxNumOfAttempts] /

signal-failure

invalid-key /
signal-failure Accepting invalid-key
[numOfAttemps  maxNumOfAttempts] /
Locked entry: start quit timer sound-alarm
do: countdown
timer-expired /
signal-reset,
set numOfAttemps := 0

“Lock” pressed /
valid-key /
signal-success Blocked
valid-key /
signal-success

Unlocked

Need “entry” and “do” state

activities for countdown timer 109
 Safe Home Access
Requirement: Unlock the door for tenant and alarm on dictionary attack

Requirement 1: Unlock the door for tenant

Tenant
TN!Y1 B TN!Y3
Transfor
Lock Ctrl
m Open door
Software
software

LC!Y2 Lock LD!Y4

Device
C

Requirement 2: Alarm on dictionary attack

Burglar
BG!Y1 B BG!Y3
Transfor
Monitor Alarm on
m
Software dict. attack
software

MS!Y2 Alarm AL!Y4

C
 Basic Frame 3: Information Display
Real
RW!C1 world
C C3

Informatio Display ~
n software Real world

IS!E2 Display Y4
C

Example: Place a Trading order

Real world

Information A Display ~
software a c Real world
C

C D

b B d
C

Display
a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i],
b: TR! {PriceQuotes, Place[i]} [Y2] Executed[i], Expired[i]} [Y3]
 Information Visualization
- Frame Concern Checklist
Information Display Frame Checklist
Required information to observe:
 Capabilities of available “sensors”
[ Case Study 1: Safe Home Access
Required information to visualize:
 Visualization description
— REQ5: maintain a history log
(database is the “display”) ]
Rules for visualization of the observed information:
 The transformations needed to process the raw observed
information to obtain displayable information

[ Case Study 1: Safe Home Access — REQ8: inspecting the access history ]
Information to observe for REQ8:
Database records of past accesses
Required information to visualize for REQ8:
Access information will be displayed as stored, without post-processing
Rules for visualization for REQ8:
Render the result of the query as an HTML table
 Basic Frame 4: Simple Editing
ET!E1 Work
WP!Y2 pieces
X Y3

Editing Command
tool effects

US!E3 User E3
B

Example: Place a Trading order

Workpieces

Tradin Command
Editing tool a g order c effects
X
Order
Trading
placing
software
rules

b Trader d
B

User
a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i],
b: TR! {PriceQuotes, Place[i]} [Y2] Executed[i], Expired[i]} [Y3]
 Simple Editing
- Frame Concern Checklist
Simple Editing Frame Checklist
Data structures:
[ Case Study 1: Safe Home Access
 Data types of elements (“workpieces”) of the document
— REQ9: filing inquiries ]
Requested commands:
 List of all possible user commands and their parameters

Command applicability under different scenarios:

 For each command, exactly describe the preconditions for execution

Consequences of unacceptable commands:

 What should system do if the user tries to execute
a command that is not supported/allowed under the current scenario

[ Case Study 1: Safe Home Access — REQ6: adding/removing users at runtime ]

Data structures for REQ6:
Database tables for each user, containing name, demographics, apartment number, keycode, …
Requested commands for REQ6:
Add new tenant
Modify information of existing tenant
Move tenant to a past-tenants table (no permanent deletion allowed)
Command applicability under different scenarios:
Applicable for a user type Landlord
 Basic Frame 5: Transformation
Inputs
IN!Y1 X IN!Y3
Transfor
Transform
m I/O Relation
Software
software

TS!Y2 Outputs OU!Y4

X

Example: REQ4 - generate periodic report

Inputs

Investment
Portfolio
Transform Software X I/O Relation
a c
Report Reporting
Generator rules
b d
Periodic
Report
X
Outputs

a: IP! {Shares[i], Price[i], Balance} [Y1] c: IP! {Stock[i], Balance} [Y3]

b: RG! {Report Line, Char} [Y2] d: PR! {Line Data} [Y4]
 Transformation
- Frame Concern Checklist
Transformation Frame Checklist
Input & output data structures:
 Data types of elements of the input document & of output doc

Traversal rules for data structures:

 E.g., breadth-first or depth-first

Mapping rules for elements of data structures:

 How an input element is mapped/transformed to an output element
 Problem Frames – Modeling &
Recombination - Topics
• Problem Domain Modeling
• Recombining Problem Frames

117
 Typical System Requirements
• REQ-1: Map input data to output data as said
by given rules Transformation

• REQ-2: Allow repository (or document) editing,

where “repository” is a collection of Workpieces
Simple data
• REQ-3: Automatically control a physical
object/device Required Behavior

• REQ-4: Interactively control a physical

object/device Commanded Behavior

• REQ-5: Monitor and display information about

Information Display
an object 118
Machine and Problem Domain

(a) Software-to-be
a
Problem
b Requirement
(“Machine”) Domain

Domain properties
seen by the requirement
(b)

Software-to-be Problem
(“Machine”)
a Domain
b Requirement

Specification Domain properties Requirement

seen by the software-to-be
a: specification interface phenomena
b: requirement interface phenomena

119
 Basic Frame 1: Required Behavior

Control
CS!C1 Controlled
C3 Required
software domain behavior
CD!C2 C

Key:
C Causal domain
B Biddable domain
X Lexical domain
[C  ] Causal phenomena
Example: Execute a Trading order [E  ] Events
[Y  ] Symbolic requirement phenomena
Control Controlled Required
Software Domain Behavior

Broker
a Stock
b Order
handling
software exchange
C rules

a: BS! {Execute[i]} [C1] b: SE! {Place[i], Cancel[i],

SE! {PriceQuotes, Ack[i], Failed[i]} [C2] Executed[i], Expired[i]} [C3]

120
 Notation Syntax
for Shared Phenomena
• C – causal domain Causal
domain
C
• predictable causal relationships among its causal phenomena
such as physical laws or business contracts or social norms
• B – biddable domain Biddable
domain
B
• usually people: unpredictable, incoercible
• X – lexical domain Lexical

• a physical representation of data (i.e., symbolic phenomena) domain

X

• [C] - causal phenomena

• events, states; directly produced or controlled by an entity;
can give rise to other phenomena in turn
• [E] - events

Machine

Problem
Domain
a

• [Y] – symbolic requirement phenomena a: M ! E1

• values, and truths and states relating only values; PD ! C2

symbolize other phenomena and relationships among them 121

 Basic Frame 2: Commanded Behavior
CS!C1 Controlled
CD!C2 domain
C C3

Control Command
software behavior

OP!E4 Operator E4
B

Example: Place a Trading order

Controlled domain

A Command
Control software a b behavior
C

C D

c B c
B

Operator
a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i],
b: TR! {PriceQuotes, Place[i]} [Y2] Executed[i], Expired[i]} [Y3]
122
 Basic Frame 3: Information Display

Real
RW!C1 world
C C3

Informatio Display ~
n software Real world

IS!E2 Display Y4
C

Example: Place a Trading order

Real world

Information A Display ~
software a c Real world
C

C D

b B d
C

Display
a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i],
b: TR! {PriceQuotes, Place[i]} [Y2] Executed[i], Expired[i]} [Y3]
123
 Basic Frame 4: Simple Workpieces
ET!E1 Work
WP!Y2 pieces
X Y3

Editing Command
tool effects

US!E3 User E3
B

Example: Place a Trading order

Workpieces

Tradin Command
Editing tool a g order c effects
X
Order
Trading
placing
software
rules

b Trader d
B

User
a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i],
b: TR! {PriceQuotes, Place[i]} [Y2] Executed[i], Expired[i]} [Y3]
124
 Basic Frame 5: Transformation
Inputs
IN!Y1 X Y3
Transfor
m IO relation
software

TS!Y2 Outputs Y4
X

Example: Place a Trading order

Inputs

a A c
Transform software X IO relation

C D

b B d
X

Outputs
a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i],
b: TR! {PriceQuotes, Place[i]} [Y2] Executed[i], Expired[i]} [Y3]
125
 Example: Personal Health Monitoring

• REQ1: keep track of person’s data (vital signs,

activities, food, etc.) [Information Display] or
[Simple Workpieces] when user enters food data
• REQ2: Calculate statistics of the data
[Transformation?] but also [Model Building] in real time
• REQ3: Allow the user to query for trends and
issues [Model Operating]
• REQ4: Propose a fitness regime suitable for
this user [Information Display] or [Model Operating]? 126
 Personal Health Monitoring

BP Sensor a
c
e Monitorin
Person’s
User g
Body
Software

d HR Sensor b

a = blood vessel pressure (upper right arm)

b = pulse (upper right arm)
c = blood pressure values (systolic/diastolic) measured every x minutes
d = heart rate values, measure every y minutes
e = querying commands

127
128
129