Ivan MarsicRutgers University

LECTURE 12: Problem FramesPart I: Decomposition

Topics

• Typical System Requirements and Problems

• Five Problem Frames:– Transformation– Simple Workpieces– Required Behavior– Information Display– Commanded Behavior

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 user stories or use cases

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: Automatically control a physical object/device

• REQ-4: Interactively control a physical object/device

• REQ-5: Monitor and display information about an object

Typical Software Eng. Problems

1. User works with computer system (environment irrelevant/ignored)

2. Computer system controls the environment (user not involved)

3. Computer system intermediates between the user and the environment

User System

System Environment

User System Environment

User

System

Repository

User System Environment

User System Environment

SystemIN doc OUT doc

1.a) System transforms input document to output document

1.b) User edits information stored in a repository

3.a) System observes the environment and displays information

3.b) System controls the environment as commanded by the user

REQ-1: Map input data to output data as said by given rules

REQ-2: Allow repository editing, where “repository” is a collection of data

REQ-3: Automatically control a physical object/device

REQ-5: Monitor and display information about an object

REQ-4: Interactively control a physical object/device

Problem Architecture

Controlling subsystem

Controlled subsystem3.b) Commanded behavior:

Operator

Monitoring subsystem

Monitored subsystem3.a) Information display:

Display

2. Required behavior:Controlling subsystem

Controlled subsystem

Feeding subsyste

m

Transformation subsystem

Receiving subsystem1.a) Transformation:

Data editor

Data repository

1.b) Simple workpieces:

User

REQ-1: Map input data to output data as said by given rules

REQ-2: Allow repository editing, where “repository” is a collection of data

REQ-3: Automatically control a physical object/device

REQ-5: Monitor and display information about an object

REQ-4: Interactively control a physical object/device

Requirements Process

Requirements analysis

Requirements gathering

Requirements specification

Agile Development User

Stories

Aspect-Oriented Requirements

Object-Oriented Analysis & Design

Structured Analysis & Design

[ Recall Section 2.2: Requirements Engineering ]

Requirements and Specification

Problem domain

SpecificationCustomer

Software Engineer

Describes

Specifies

Requirements Program

Software (Solution) domain

Analyzes Develops

bSoftware-to-be

(“Machine”) aProblem Domain

Requirement

Machine and Problem Domain

Specification Domain propertiessensed by the software-to-be

Domain propertiesenvisioned by the requirement

Requirement

a: specification interface phenomena (system inputs/outputs)b: requirement interface phenomena (user goals and interaction)

(a)

(b)

bSoftware-to-be

(“Machine”) aProblem Domain

Requirement

Description of what actually happens in the problem domain versus in what form it will appear as system input;as well as what output will the system issue versus what should happens in the problem domain.

Description of what the user is trying to achieve in the problem domain and how is the user supposed to interact with the system to make it happen.

This is given This is a condition to satisfyThis we need to find(solution)

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 checklists for requirements

analysis and system specification

– We look for such basic problems to help us discover the “seams” of our problem

Complex Problem Decomposition

(a)

Dom

ain

A

Req

uire

men

t

i

Req

uire

men

tiii

Dom

ain

C

Dom

ain

D

Dom

ain

BR

equi

rem

ent

ii

Domain

E

Requirement

iv

(b)

Software-to-be(“Machine”)

Problem Domain

The Requirements

Mac

hine

1

Mac

hine

2

Software-to-be(“Machine”)

Machine

4Mac

hine

3

Problem decomposition

Notation Syntaxfor Problem Frames

• C – causal domain• predictable causal relationships among its causal phenomena

such as physical laws or business contracts or social norms

• B – biddable domain• usually people: unpredictable, incoercible

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

• [C] - causal phenomena• events, states; directly produced or controlled by an entity;

can give rise to other phenomena in turn

• [E] - events

• [Y] – symbolic requirement phenomena• values, and truths and states relating only values;

symbolize other phenomena and relationships among them

Causal domain C

Biddable domain B

Lexical domain X

a

Ma

chin

e

Pro

ble

mD

om

ain

a: M ! E1 PD ! C2

Example: Problem Decomposition

PROBLEM DOMAIN

Software-to-be

(1) Tenant(4) List of valid keys

(3) Lock

(6) Photosensor(7) Light

(8) Alarm bell

(9) Desktop computer

(2) Landlord

(3) Key

(5) Device preferences

(10) Tenant accounts

(11) Log of accesses

REQ1: Keep door locked and auto-lockREQ2: Lock when “LOCK” pressedREQ3: Unlock when valid key providedREQ4: Allow mistakes but prevent dictionary attacksREQ5: Maintain a history logREQ6: Adding/removing users at runtimeREQ7: Configuring device activation preferencesREQ8: Inspecting the access historyREQ9: Filing inquiries

Difficult to consider the whole system at once…

Example: Problem Decomposition

PROBLEM DOMAIN

Software-to-be

(1) Tenant(4) List of valid keys

(3) Lock

(6) Photosensor(7) Light

(8) Alarm bell

(9) Desktop computer

Subsystem-2

Subsystem-1

Subsystem-3

Subsystem-4

(2) Landlord

(3) Key

(5) Device preferences

(10) Tenant accounts

(11) Log of accesses

REQ1, REQ2, REQ3, REQ4REQ3

REQ5, REQ7, REQ8, REQ9

REQ4

REQ1: Keep door locked and auto-lockREQ2: Lock when “LOCK” pressedREQ3: Unlock when valid key providedREQ4: Allow mistakes but prevent dictionary attacksREQ5: Maintain a history logREQ6: Adding/removing users at runtimeREQ7: Configuring device activation preferencesREQ8: Inspecting the access historyREQ9: Filing inquiries

Decompose the system based on its requirements

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

Required Behavior

Commanded Behavior

Information Display (database is the “display”)

Simple Workpieces

Information Display

Simple Workpieces

Simple Workpieces

[ Case Study 1: Safe Home Access ]

Example: Problem Decomposition

• REQ1: view market prices and volumes– Domains: exchange, display

• REQ2: place a trade– Domains: investor, tradable-securities, pending-trades

• REQ3: execute trades when conditions matched– Domains: exchange, pending-trades

• REQ4: generate periodic report– Domains: portfolio, report

• REQ5: generate leaderboard– Domains: all-portfolios, leaderboard

• REQ6: view leaderboard– Domains: leaderboard, display

• REQ7: start a trading group/clique– Domains: investor, group

• REQ8: invite to a trading group/clique– Domains: investor, friends, group

Required Behavior

Commanded Behavior

Simple Workpieces

Information Display

Simple Workpieces

Information Display

Transformation

Transformation

[ Case Study 2: Investment Fantasy League ]

Broker Software

Control Software

Basic Frame 1: Required Behavior

Controlled Domain

Required Behavior

CS!C1 C3

CD!C2 C

Stock Exchange

Trading orderhandling rulesC

Example: Execute a Trading order

ControlSoftware

ControlledDomain

RequiredBehavior

b: SE! {Submit[i], Cancel[i], [C3] Executed[i], Failed[i], Expired[i]}

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

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

C Causal domain

X Lexical domain

Causal phenomena

Events

Symbolic requirement phenomena

[C ]

[E ]

[Y ]

Key:

a b

System outputs to the environment

Environment inputs to the system

Description of the domain’s required behavior

Required Behavior- Checklist of Concerns

Required Behavior Frame Checklist

Existing behavior of the controlled domain: Behavioral rules of the domain without system-to-be

Required behavior of the controlled domain: Behavioral rules to be effected by our system

Capabilities of available “sensors”: Sensed parameters: type, sampling rate, precision, …

Capabilities of available “actuators”: Actuation parameters: type, acting rate, magnitude, …

Existing behavior for REQ1:Currently, the lock armed mechanically and remains so until mechanically disarmedIf the user unlocks, but forgets to lock, the lock remains disarmed

Required behavior for REQ1:The lock will be armed electronically and periodically checked that it remains so until explicitly disarmedIf the user unlocks, but forgets to lock, the lock will be automatically disarmed after an interval “autoLockInterval”

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 slide in or out, as commanded via USB protocol, using a command

[ Case Study 1: Safe Home Access — REQ1: keep door locked and auto-lock ]

Problem Domain:How Electronic Lock Works

Computer

1

2

3

4

5

X

Y

1

2

3

4

5

X

Y

Lock

Voltage:HIGH

LOW

lock armed lock disarmed lock armed

What in case of power failure?- By default armed- By default disarmed (e.g., fire exit)

Three Descriptions

What user wants:

When valid keycode entered + Unlock pressed, open the lock;

Automatically lock after a period of time.

The requirementThe problem domain

The specification

How software-to-be behaves:

If entered number matches one of stored numbers + Button-1 pressed, put HIGH voltage on Output-port-1;

Start a timer countdown;

When timer expires, put LOW voltage on Output-port-1.

Armed

HIGH /

Disarmed

LOW /

1

2

3

4

5

X

Y

1

2

3

4

5

X

Y

Required Behavior- Domain Model -

Sensor1 Descriptor

- sampling Rate- precision- …

Actuator1 Descriptor

- acting Rate- magnitude- …

Control Rule

- constraint 1- constraint 2- …

Control Software

Controlled Domain

Required Behavior

CS!C1 C3

CD!C2 C

System outputs to the environment

Environment inputs to the system

Description of the domain’s required behavior

Commanded Behavior- Checklist of Concerns

Commanded Behavior Frame Checklist

Requested user commands: List of all possible user commands and their parameters

Command applicability under different scenarios: Description of scenarios for which each command

is applicable

Consequences of unacceptable commands: What should happen if the user tries to execute a command

that is not supported/allowed under the current scenario

[ Case Study 1: Safe Home Access — REQ2: lock when “LOCK” pressedREQ3: unlock when valid key providedREQ4: 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

Document what the user can (cannot) do and how the system can help them do it (or prevent them from doing other things)

Information Display- Checklist of Concerns

Information Display Frame Checklist

Required information to observe: Capabilities of available “sensors”

Required information to visualize: Visualization description

Rules for visualization of the observed information: The transformations needed to process the raw observed

information to obtain displayable information

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

[ Case Study 1: Safe Home Access — REQ8: inspecting the access history ]

[ Case Study 1: Safe Home Access — REQ5: maintain a history log (database is the “display”) ]

Simple Workpieces- Checklist of Concerns

Simple Workpieces Frame Checklist

Data structures: Data types of elements (“workpieces”) of the document

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

Data structures for REQ6:Database tables for each user, containing name, demographics, apartment number, keycode, …

Requested commands for REQ6:Add new tenantModify information of existing tenantMove tenant to a past-tenants table (no permanent deletion allowed)

Command applicability under different scenarios:Applicable for a user type Landlord

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

[ Case Study 1: Safe Home Access — REQ9: filing inquiries ]

Basic Frame 2: Commanded Behavior

Control software

Command behaviors

CS!C1

C3CD!C2

a b

Example: Submit a Trading order

Control software

Controlled domain

Commandbehavior

c: TR! {Submit[i], Cancel[i], Executed[i], Expired[i]} [Y3]

a: TS! {Create[i]} [E1]

b: TR! {PriceQuotes, Submit[i]} [Y2]

Controlled domain C

OperatorB

OP!E4 E4

C D

AC

BB

Operator

c c

Basic Frame 3: Information Display

Information software

Display ~ Real world

C3RW!C1

a c

Example: Place a Trading order

Informationsoftware

Real world

Display ~Real world

c: TR! {Place[i], Cancel[i], Executed[i], Expired[i]} [Y3]

a: TS! {Create[i]} [E1]

b: TR! {PriceQuotes, Place[i]} [Y2]

Realworld C

DisplayC

IS!E2 Y4

C D

AC

BC

Display

b d

Basic Frame 4: Simple Workpieces

Editing tool

Command effects

ET!E1

Y3WP!Y2

a c

Example: Place a Trading order

Editing tool

Workpieces

Commandeffects

c: TR! {Place[i], Cancel[i], Executed[i], Expired[i]} [Y3]

a: TS! {Create[i]} [E1]

b: TR! {PriceQuotes, Place[i]} [Y2]

UserB

US!E3 E3

Trading software

Order placing rules

TraderB

User

b d

Workpieces X

Trading order X

Transformation- Checklist of Concerns

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

Basic Frame 5: Transformation

IN!Y3IN!Y1

Example: REQ4 - generate periodic report

Transform Software

Inputs

I/O Relation

c: IP! {Stock[i], Balance} [Y3]d: PR! {Line Data} [Y4]

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

b: RG! {Report Line, Char} [Y2]

TS!Y2 OU!Y4

Reporting rules

Investment Portfolio X

Periodic Report X

Outputs

Report Generator

a

b

c

d

Transform software

Transform Software

InputsX

OutputsX

I/O Relation

Safe Home Access

TN!Y3TN!Y1

LC!Y2 LD!Y4

Transform softwareLock Ctrl Software

TenantB

LockDevice C

Open door

BG!Y3BG!Y1

MS!Y2 AL!Y4

Transform softwareMonitor

Software

BurglarB

AlarmC

Alarm on dict. attack

Requirement: Unlock the door for tenant and alarm on dictionary attack

Requirement 1: Unlock the door for tenant

Requirement 2: Alarm on dictionary attack