1 / 14

Ivan Marsic Rutgers University

LECTURE 13: Problem Frames Part II: Modeling & Recombination. Ivan Marsic Rutgers University. Topics. Problem Domain Modeling Recombining Problem Frames. Typical System Requirements. REQ-1 : Map input data to output data as said by given rules

varuna
Download Presentation

Ivan Marsic Rutgers University

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LECTURE 13: Problem FramesPart II: Modeling & Recombination Ivan Marsic Rutgers University

  2. Topics • Problem Domain Modeling • Recombining Problem Frames

  3. 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 Transformation Simple Workpieces Required Behavior Commanded Behavior Information Display

  4. Software-to-be (“Machine”) Problem Domain Requirement a b Machine and Problem Domain (a) Software-to-be (“Machine”) Problem Domain Requirement a b Domain properties seen by the requirement (b) Requirement Specification Domain properties seen by the software-to-be a: specification interface phenomena b: requirement interface phenomena

  5. Control software Broker software Basic Frame 1: Required Behavior CS!C1 C3 Controlled domain Required 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 Software Controlled Domain Required Behavior a b Stock exchange Order handling rules C a: BS! {Execute[i]} [C1] b: SE! {Place[i], Cancel[i], Executed[i], Expired[i]} [C3] SE! {PriceQuotes, Ack[i], Failed[i]} [C2]

  6. a Problem Domain Machine a: M ! E1 PD ! C2 Notation Syntaxfor Shared Phenomena • C – causal domain • predictable causal relationships among its causal phenomenasuch 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

  7. Operator Controlled domain B A B B C C C Control software Basic Frame 2: Commanded Behavior CS!C1 CD!C2 C3 Command behavior E4 OP!E4 Example: Place a Trading order Controlled domain Command behavior a b Control software D c c Operator a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i], Executed[i], Expired[i]} [Y3] b: TR! {PriceQuotes, Place[i]} [Y2]

  8. Real world B A Display Information software C C C C C Basic Frame 3: Information Display RW!C1 C3 Display ~ Real world Y4 IS!E2 Example: Place a Trading order Real world Information software Display ~ Real world a c D b d Display a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i], Executed[i], Expired[i]} [Y3] b: TR! {PriceQuotes, Place[i]} [Y2]

  9. Work pieces Trading order X X Trader User B B Editing tool Trading software Basic Frame 4: Simple Workpieces ET!E1 WP!Y2 Y3 Command effects E3 US!E3 Example: Place a Trading order Workpieces Command effects a c Editing tool Order placing rules b d User a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i], Executed[i], Expired[i]} [Y3] b: TR! {PriceQuotes, Place[i]} [Y2]

  10. Inputs B A Outputs Transform software X X X X C Basic Frame 5: Transformation IN!Y1 Y3 IO relation Y4 TS!Y2 Example: Place a Trading order Inputs a c Transform software IO relation D b d Outputs a: TS! {Create[i]} [E1] c: TR! {Place[i], Cancel[i], Executed[i], Expired[i]} [Y3] b: TR! {PriceQuotes, Place[i]} [Y2]

  11. 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]?

  12. Monitoring Software Personal Health Monitoring BP Sensor a c e User Person’s Body HR Sensor d 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

More Related