Kĩ thuật lập trình - Lecture 12: Problem frames - Part I: Decomposition

Ivan MarsicRutgers UniversityLECTURE 12: Problem FramesPart I: DecompositionTopicsTypical System Requirements and ProblemsFive Problem Frames:TransformationSimple WorkpiecesRequired BehaviorInformation DisplayCommanded BehaviorWhy 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 problemsThey are the most basic user stories or use casesTypical System RequirementsREQ-1: Map input data to output data as said by given rulesREQ-2: Allow repository (or document) editing, where “repository” is a collection of dataREQ-3: Automatically control a physical object/deviceREQ-4: Interactively control a physical object/deviceREQ-5: Monitor and display information about an objectTypical Software Eng. Problems1. 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 environmentUserSystemSystemEnvironmentUserSystemEnvironmentUserSystemRepositoryUserSystemEnvironmentUserSystemEnvironmentSystemIN docOUT doc1.a) System transforms input document to output document1.b) User edits information stored in a repository3.a) System observes the environment and displays information3.b) System controls the environment as commanded by the userREQ-1: Map input data to output data as said by given rulesREQ-2: Allow repository editing, where “repository” is a collection of dataREQ-3: Automatically control a physical object/deviceREQ-5: Monitor and display information about an objectREQ-4: Interactively control a physical object/deviceProblem ArchitectureControlling subsystemControlled subsystem3.b) Commanded behavior:OperatorMonitoring subsystemMonitored subsystem3.a) Information display:Display2. Required behavior:Controlling subsystemControlled subsystemFeeding subsystemTransformation subsystemReceiving subsystem1.a) Transformation:Data editorData repository1.b) Simple workpieces:UserREQ-1: Map input data to output data as said by given rulesREQ-2: Allow repository editing, where “repository” is a collection of dataREQ-3: Automatically control a physical object/deviceREQ-5: Monitor and display information about an objectREQ-4: Interactively control a physical object/deviceRequirements ProcessRequirements analysisRequirements gatheringRequirements specificationAgile Development User StoriesAspect-Oriented RequirementsObject-Oriented Analysis & DesignStructured Analysis & Design[ Recall Section 2.2: Requirements Engineering ]Requirements and SpecificationProblem domainSpecificationCustomerSoftware EngineerDescribesSpecifiesRequirementsProgramSoftware (Solution) domainAnalyzesDevelopsbSoftware-to-be(“Machine”)aProblem DomainRequirementMachine and Problem DomainSpecificationDomain propertiessensed by the software-to-beDomain propertiesenvisioned by the requirementRequirementa: specification interface phenomena (system inputs/outputs)b: requirement interface phenomena (user goals and interaction)(a)(b)bSoftware-to-be(“Machine”)aProblem DomainRequirementDescription 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 FramingProblem framing means dividing the problem at its “seams” into smaller sub-problemsThe difficulty is in recognizing the “seams”Problem frames are derived from commonly occurring software requirementsThey afford ready-made checklists for requirements analysis and system specificationWe look for such basic problems to help us discover the “seams” of our problemComplex Problem Decomposition(a)DomainARequirementiRequirementiiiDomainCDomainDDomainBRequirementiiDomainERequirementiv(b)Software-to-be(“Machine”)Problem DomainThe RequirementsMachine1Machine2Software-to-be(“Machine”)Machine4Machine3Problem decompositionNotation Syntaxfor Problem FramesC – causal domainpredictable causal relationships among its causal phenomenasuch as physical laws or business contracts or social normsB – biddable domainusually people: unpredictable, incoercibleX – lexical domaina physical representation of data (i.e., symbolic phenomena)[C] - causal phenomenaevents, states; directly produced or controlled by an entity;can give rise to other phenomena in turn[E] - events[Y] – symbolic requirement phenomenavalues, and truths and states relating only values;symbolize other phenomena and relationships among themCausal domainCBiddable domainBLexical domainXaMachineProblemDomaina: M ! E1 PD ! C2Example: Problem DecompositionPROBLEM DOMAINSoftware-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 accessesREQ1: 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 inquiriesDifficult to consider the whole system at onceExample: Problem DecompositionPROBLEM DOMAINSoftware-to-be(1) Tenant(4) List of valid keys(3) Lock(6) Photosensor(7) Light(8) Alarm bell(9) Desktop computerSubsystem-2Subsystem-1Subsystem-3Subsystem-4(2) Landlord(3) Key(5) Device preferences(10) Tenant accounts(11) Log of accessesREQ1, REQ2, REQ3, REQ4REQ3REQ5, REQ7, REQ8, REQ9REQ4REQ1: 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 requirementsExample: Problem DecompositionREQ1: 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 inquiriesRequired BehaviorCommanded BehaviorInformation Display (database is the “display”)Simple WorkpiecesInformation DisplaySimple WorkpiecesSimple Workpieces[ Case Study 1: Safe Home Access ]Example: Problem DecompositionREQ1: view market prices and volumesDomains: exchange, displayREQ2: place a tradeDomains: investor, tradable-securities, pending-tradesREQ3: execute trades when conditions matchedDomains: exchange, pending-tradesREQ4: generate periodic reportDomains: portfolio, reportREQ5: generate leaderboardDomains: all-portfolios, leaderboardREQ6: view leaderboardDomains: leaderboard, displayREQ7: start a trading group/cliqueDomains: investor, groupREQ8: invite to a trading group/cliqueDomains: investor, friends, groupRequired BehaviorCommanded BehaviorSimple WorkpiecesInformation DisplaySimple WorkpiecesInformation DisplayTransformationTransformation[ Case Study 2: Investment Fantasy League ]Broker SoftwareControl SoftwareBasic Frame 1: Required BehaviorControlled DomainRequired BehaviorCS!C1C3CD!C2C Stock ExchangeTrading orderhandling rulesCExample: Execute a Trading orderControlSoftwareControlledDomainRequiredBehaviorb: 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]CCausal domainXLexical domainCausal phenomenaEventsSymbolic requirement phenomena[C  ][E  ][Y  ]Key:abSystem outputs to the environmentEnvironment inputs to the system Description of the domain’s required behavior Required Behavior- Checklist of ConcernsRequired 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 disarmedRequired 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 commandCapabilities 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 WorksComputerLockVoltage:HIGHLOWlock armedlock disarmedlock armedWhat in case of power failure?- By default armed- By default disarmed (e.g., fire exit)Three DescriptionsWhat user wants:When valid keycode entered + Unlock pressed, open the lock;Automatically lock after a period of time.The requirementThe problem domainThe specificationHow 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.ArmedHIGH /DisarmedLOW /Required Behavior- Domain Model -Sensor1 Descriptor- sampling Rate- precision- Actuator1 Descriptor- acting Rate- magnitude- Control Rule- constraint 1- constraint 2- Control SoftwareControlled DomainRequired BehaviorCS!C1C3CD!C2CSystem outputs to the environmentEnvironment inputs to the system Description of the domain’s required behavior Commanded Behavior- Checklist of ConcernsCommanded Behavior Frame ChecklistRequested user commands:List of all possible user commands and their parametersCommand applicability under different scenarios:Description of scenarios for which each commandis applicableConsequences of unacceptable commands:What should happen if the user tries to execute a commandthat 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  maxNumOfAttemptsConsequences 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 ignoredDocument 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 ConcernsInformation Display Frame ChecklistRequired information to observe:Capabilities of available “sensors”Required information to visualize:Visualization descriptionRules for visualization of the observed information:The transformations needed to process the raw observedinformation to obtain displayable informationInformation to observe for REQ8:Database records of past accessesRequired information to visualize for REQ8:Access information will be displayed as stored, without post-processingRules 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 ConcernsSimple Workpieces Frame ChecklistData structures:Data types of elements (“workpieces”) of the documentRequested commands:List of all possible user commands and their parametersCommand applicability under different scenarios:For each command, exactly describe the preconditions for executionConsequences of unacceptable commands:What should system do if the user tries to executea command that is not supported/allowed under the current scenarioData 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 BehaviorControl softwareCommand behaviorsCS!C1C3CD!C2abExample: Submit a Trading orderControl softwareControlled domainCommandbehaviorc: TR! {Submit[i], Cancel[i], Executed[i], Expired[i]} [Y3]a: TS! {Create[i]} [E1]b: TR! {PriceQuotes, Submit[i]} [Y2]Controlled domainCOperatorBOP!E4E4CDACBBOperatorccBasic Frame 3: Information DisplayInformation softwareDisplay ~ Real worldC3RW!C1acExample: Place a Trading orderInformationsoftwareReal worldDisplay ~Real worldc: TR! {Place[i], Cancel[i], Executed[i], Expired[i]} [Y3]a: TS! {Create[i]} [E1]b: TR! {PriceQuotes, Place[i]} [Y2]RealworldCDisplayCIS!E2Y4CDACBCDisplaybdBasic Frame 4: Simple WorkpiecesEditing toolCommand effectsET!E1Y3WP!Y2acExample: Place a Trading orderEditing toolWorkpiecesCommandeffectsc: TR! {Place[i], Cancel[i], Executed[i], Expired[i]} [Y3]a: TS! {Create[i]} [E1]b: TR! {PriceQuotes, Place[i]} [Y2]UserBUS!E3E3Trading softwareOrder placing rulesTraderBUserbdWorkpiecesXTrading orderXTransformation- Checklist of ConcernsTransformation Frame ChecklistInput & output data structures:Data types of elements of the input document & of output docTraversal rules for data structures:E.g., breadth-first or depth-firstMapping rules for elements of data structures:How an input element is mapped/transformed to an output elementBasic Frame 5: TransformationIN!Y3IN!Y1Example: REQ4 - generate periodic reportTransform SoftwareInputsI/O Relationc: 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!Y2OU!Y4Reporting rulesInvestment PortfolioXPeriodic ReportXOutputsReport GeneratorabcdTransform softwareTransform SoftwareInputsXOutputsXI/O RelationSafe Home AccessTN!Y3TN!Y1LC!Y2LD!Y4Transform softwareLock Ctrl SoftwareTenantBLockDeviceCOpen doorBG!Y3BG!Y1MS!Y2AL!Y4Transform softwareMonitor SoftwareBurglarBAlarmCAlarm on dict. attackRequirement: Unlock the door for tenant and alarm on dictionary attackRequirement 1: Unlock the door for tenantRequirement 2: Alarm on dictionary attack