Ivan Marsic Rutgers University LECTURE 12: Problem Frames Part 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 UserSystem Environment UserSystemEnvironment User System Repository UserSystemEnvironment UserSystem Environment SystemIN docOUT 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 subsystem 3.b) Commanded behavior: Operator Monitoring subsystem Monitored subsystem 3.a) Information display: Display 2. Required behavior: Controlling subsystem Controlled subsystem Feeding subsystem Transformation subsystem Receiving subsystem 1.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 Specifi cation Customer Software Engineer Describes Specifies RequirementsProgram Software (Solution) domain AnalyzesDevelops

b Software-to-be (“Machine”) a Problem Domain Requirement Machine and Problem Domain Specification Domain properties sensed by the software-to-be Domain properties envisioned by the requirement Requirement a: specification interface phenomena (system inputs/outputs) b: requirement interface phenomena (user goals and interaction) (a) (b) b Software-to-be (“Machine”) a Problem 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 givenThis 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) Domain A Requirement i Requirement iii Domain C Domain D Domain B Requirement ii Domain E Requirement iv (b) Software-to-be (“Machine”) Problem Domain The Requirements Machine 1 Machine 2 Software-to-be (“Machine”) Machine 4 Machine 3 Problem decomposition

Notation Syntax for 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 Machine Problem Domain 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-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 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, REQ4 REQ3 REQ5, REQ7, REQ8, REQ9 REQ4 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  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 [ 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 [ Case Study 2: Investment Fantasy League ]

Broker Software Control Software Basic Frame 1: Required Behavior Controlled Domain Required Behavior CS!C1C3 CD!C2 C Stock Exchange Trading order handling rules C Example: Execute a Trading order Control Software Controlled Domain Required Behavior 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: ab 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 disarmed If 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 disarmed If 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 Lock Voltage: HIGH LOW lock armedlock disarmedlock 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 requirement The 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 /

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!C1C3 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” 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 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 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 [ 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 C3 CD!C2 ab Example: Submit a Trading order Control software Controlled domain Command behavior 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 Operator B OP!E4 E4 C D A C B B Operator cc

Basic Frame 3: Information Display Information software Display ~ Real world C3RW!C1 ac Example: Place a Trading order Information software 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] Real world C Display C IS!E2 Y4 C D A C B C Display bd

Basic Frame 4: Simple Workpieces Editing tool Command effects ET!E1 Y3 WP!Y2 ac Example: Place a Trading order Editing tool Workpieces Command effects c: TR! {Place[i], Cancel[i], Executed[i], Expired[i]} [Y3] a: TS! {Create[i]} [E1] b: TR! {PriceQuotes, Place[i]} [Y2] User B US!E3 E3 Trading software Order placing rules Trader B User bd Work pieces 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 Inputs X Outputs X I/O Relation

Safe Home Access TN!Y3 TN!Y1 LC!Y2 LD!Y4 Transform software Lock Ctrl Software Tenant B Lock Device C Open door BG!Y3BG!Y1 MS!Y2AL!Y4 Transform software Monitor Software Burglar B Alarm C 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