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

Slides:



Advertisements
Similar presentations
Architecture Tutorial 1 Overview of Today’s Talks Provenance Data Structures Recording and Querying Provenance –Break (30 minutes) Distribution and Scalability.
Advertisements

Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications University (ICU) iko.AT. icu.ac.kr Fall 2005 ICE0575 Lecture.
Problem Frames 8 - Variant frames. Variants Model Operator Description Connection Control.
1 SWE Introduction to Software Engineering Lecture 22 – Architectural Design (Chapter 13)
1 Institute for Software Research, International Methods of Software Development Problem Frames 1 (This lecture is largely based on material graciously.
Application architectures
Software Architecture Patterns (2). what is architecture? (recap) o an overall blueprint/model describing the structures and properties of a "system"
Effects of exercise on the cardiovascular system 1 Effects of exercise on the cardiovascular system.
About the Presentations The presentations cover the objectives found in the opening of each chapter. All chapter objectives are listed in the beginning.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 10 Slide 1 Formal Specification.
Ivan Marsic Rutgers University LECTURE 12: Problem Frames Part I: Decomposition.
Application architectures
UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine1 CSE 503 – Software Engineering Lecture 2: Jackson Problem Frames Rob DeLine 31 Mar 2004 Thanks.
1 Functions and Limits ..
VirtualWorks.
Problem Analysis and Structure Models and Frames.
Architecture Tutorial 1 Overview of Today’s Talks Provenance Data Structures Recording and Querying Provenance –Break (30 minutes) Distribution and Scalability.
Introduction to Theory of Automata
Functional Modeling – Requirement Patterns (Problem Frames)
University of Toronto Department of Computer Science © Steve Easterbrook. This presentation is available free for non-commercial use with attribution.
11 CORE Architecture Mauro Bruno, Monica Scannapieco, Carlo Vaccari, Giulia Vaste Antonino Virgillito, Diego Zardetto (Istat)
1 Institute for Software Research, International Methods of Software Development Problem Frames 2 (This lecture is largely based on material graciously.
The Unified Modeling Language Part II Omar Meqdadi SE 2730 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
11 CORE Architecture Mauro Bruno, Monica Scannapieco, Carlo Vaccari, Giulia Vaste Antonino Virgillito, Diego Zardetto (Istat)
Problem Frames 7 - Model domains and real worlds.
Problems and Frames III Recap and More Concepts. Definition “A problem frame is a kind of pattern. It define an intuitively identifiable problem in terms.
CS223: Software Engineering
1 Specification A broad term that means definition Used at different stages of software development for different purposes Generally, a statement of agreement.
CSC480 Software Engineering Lecture 7 September 16, 2002.
Chapter – 8 Software Tools.
Problems and Frames IV Heuristics. Heuristics? Serving or helping to find out or discover; Guidelines; But connotations of trial and error.
Ivan Marsic Rutgers University LECTURE 3: Understanding the Problem and Dividing the Work.
Application architectures Advisor : Dr. Moneer Al_Mekhlafi By : Ahmed AbdAllah Al_Homaidi.
Application architectures 1. Topics covered In the previous chapter, the discussion of system arcitectures focused on architectural issues such as control,
Ivan Marsic Rutgers University LECTURE 4: Software Architecture.
Application architectures. Objectives l To explain the organisation of two fundamental models of business systems - batch processing and transaction processing.
Software architecture
Business System Development
Software Engineering Lecture 4 System Modeling The Analysis Stage.
HARDWARE The hardware is the part you can see the computer, ie all components of their physical structure. The screen, keyboard, and mouse tower of the.
Object-Oriented Analysis and Design
User Interface Design The Golden Rules: Place the user in control.
Advanced Scientific Visualization
Developing Information Systems
LECTURE 6: Domain Modeling
Week 12 Option 3: Database Design
Lecture 6. Information systems
Structured Analysis and Dataflow Diagrams
Business Intelligence Design and Development Michael A. Fudge, Jr.
Analysis and Design with UML: Discovering Classes and Relationships
Application of ODP for Space Development
LECTURE 4: Understanding the Problem and Dividing the Work
Chapter 2: Input and output devices
LECTURE 4: Software Architecture
International Scientific Consortium "Information and Marketing Centre“
Analysis and Design with UML: Discovering Classes and Relationships
Chapter 6 System and Application Software
Software Architecture
LECTURE 12: Problem Frames Part I: Decomposition
An Introduction to Software Architecture
Object and class structuring
Analysis and Design with UML: Classes and Relationships
Spreadsheets, Modelling & Databases
Sylnovie Merchant, Ph.D. MIS 161 Spring 2005
Software Analysis.
Plan of the talk Basic Specification blocks
Chapter 6 System and Application Software
Chapter 6 System and Application Software
Chapter 6 System and Application Software
Lecture 23 CS 507.
Presentation transcript:

1 Ivan Marsic Rutgers University LECTURE 13: Problem Frames Part II: Modeling & Recombination

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

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

5 Basic Frame 1: Required Behavior Control software Controlled domain Required behavior CS!C1C3 CD!C2 C Broker software Stock exchange Order handling rules ab C Example: Execute a Trading order Control Software Controlled Domain Required Behavior b: SE! {Place[i], Cancel[i], Executed[i], Expired[i]} [C3] a: BS! {Execute[i]} [C1] SE! {PriceQuotes, Ack[i], Failed[i]} [C2] C Causal domain Key: B Biddable domain X Lexical domain Causal phenomena Events Symbolic requirement phenomena [C  ] [E  ] [Y  ]

6 Notation Syntax for Shared Phenomena 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

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

8 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

9 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

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

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

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

13

14