Transcript Institute for Software Research, International

Methods of Software Development
Problem Frames 1
(This lecture is largely based on material graciously
provided by Professor Mary Shaw)
Institute for Software Research, International
1
Are there any questions?
Institute for Software Research, International
2
Overview: This course is about
deciding what to design.
Problem
Engineering approach
Knowledge of past solutions
Business & market constraints
Here a
Miracle
Happens
Regulations
Solution
Institute for Software Research, International
3
Course contents
 Identifying
the problem
 Problem
frames is for representing problems.
 Contextual inquiry is for studying & representing the
context of use.
 Use cases are for describing generalized scenarios that
the software will support.
 Designing
a solution
 Prototyping
identifies ways to refine software designs.
 Usability deals with making the software easy to use.
 Business and regulatory issues constrain choices about
which markets to enter, and how to enter them.
Institute for Software Research, International
4
Moving on to today’s lesson…
Institute for Software Research, International
5
A question to get you thinking…

Which of these problems is not like the others?
1.
Writing a report for school
Creating a spreadsheet for a business
Browsing the web
2.
3.
Institute for Software Research, International
6
A question to get you thinking…

Which of these problems is not like the others?
1.
Making a heart pacemaker beat once per second
Steering a nuclear missile into a city
Encrypting a bank database
2.
3.
Institute for Software Research, International
7
The key idea in problem frames is
recurring problem types
 Different
problems share characteristics.
 If
you stand back from the details of your current
problem, you may recognize it as a known problem.
 Many
known types of problems are already solved.
A
problem frame represents a “well-known” type of
software problem.
Institute for Software Research, International
8
Problem frames are a way of representing
certain software-related expertise.
 The
nature of expertise
 Experts
have about 50,000 chunks of knowledge
 It takes them about 10 years to become experts
 This is true across many domains
 Experts recognize these chunks instead of deriving them
 What passes for insight or intuition is often recognition
 The
idea in problem frames
 Frames
represent chunks of knowledge
 Knowing more variations will allow you to recognize
more pre-solved problems and apply prior art
 This is easier and less risky than analyzing from scratch
Institute for Software Research, International
9
Basic steps in applying problem frames
1.
2.
3.
4.


Break the context into pieces (called domains).
Identify the shared phenomena (called interfaces)
among the domains.
Represent the domains and their interfaces in a
context diagram
Add the conditions (called requirements) that the
software must bring about.
A context diagram that has been augmented with
requirements is called a problem diagram.
A problem diagram that recurs a lot is called a
problem frame.
Institute for Software Research, International
10
A sample problem diagram:
editing a “periods & ranges” database
n
Periods &
ranges
X
o
PREdit
machine
Data entry
m
Medical
staff
m: MS! (EnterPeriod, EnterRange,
EnterPatientName, etc) [C1]
m
B
n: PM! (EditOperations) [C2]
o: PR! (DataValues) [Y3]
Institute for Software Research, International
11
The different types of domains
 Causal
(C) – has predictable relationships among
physical phenomena
 The
machine domain, which has a double stripe, is
always a causal domain.
 Biddable
(B) - physical but unpredictable
 Humans
are the most common biddable domain.
 Lexical
(X) – physical representation of data and
symbolic phenomena
 Designed
domains, which have a single stripe, are
usually lexical domains.
Institute for Software Research, International
12
Examples of each type of domain
 Causal
(C)
 LCD
screens
 Heart pacemakers
 Nuclear missiles
 Biddable
(B)
 Humans
 Lexical
(X)
 Word
documents
 Spreadsheets
 HTML documents
 Bank databases
Institute for Software Research, International
13
The different types of phenomena
 Causal
(C or E) – the events that one domain
initiates in order to influence or control another
domain
 Causal
phenomena deal with what happens.
 Symbolic
(Y) – values, truths, and states
 Symbolic
phenomena are encodings of other phenomena.
Institute for Software Research, International
14
Examples of each type of phenomenon
 Causal
(C or E)
 DrawLine(x1,y1,x2,y2),
supported by LCD screens
 MakeElectricalPulse(voltage), supported by pacemakers
 FireThruster(duration), supported by nuclear missiles
 InsertRow(), supported by Microsoft Excel
 ClickHyperlink(url), supported by humans
 Symbolic
(Y)
 ListOfParagraphs(),
supported by Word documents
 GridOfCells(), supported by spreadsheets
 LevelOfEncryption(), supported by bank database
Institute for Software Research, International
15
A sample problem diagram:
editing a “periods & ranges” database
n
Periods &
ranges
o
X
Databases are lexical.
PREdit
machine
All machine domains
are causal.
Data entry
m
Medical
staff
m
B
Humans are biddable.
Sending SQL to the database is causal.
m: MS! (EnterPeriod, EnterRange,
EnterPatientName, etc) [C1]
The act of giving inputs to the machine is causal.
n: PM! (EditOperations) [C2]
o: PR! (DataValues) [Y3]
The values are symbolic.
Institute for Software Research, International
16
There are 5 basic problem frames.
 Required
behavior
Control part of the physical world to satisfy a condition.
 Commanded
behavior
Control part of the physical world according to operator
instructions.
 Information
display
Obtain state/behavior information from the physical world
and present it as required.
 Simple
workpieces
Build a tool to create & edit persistent information objects
 Transformation
Transform information inputs to required outputs
Institute for Software Research, International
17
Required behavior
 Machine
sends commands (C1) to controlled
domain, which may provide feedback (C2)
Control
Machine
CM ! C1
CD ! C2
Controlled
Domain
C
CD ! C3
Required
Behavior
 The
requirement is that the controlled domain must
demonstrate some behavior (C3).
 Note that the required behavior (C3) is different
from the commands (C1) that are sent to try and
cause that behavior.
Institute for Software Research, International
18
Commanded behavior
 Now
a human operator sends certain events (E4)
that implicitly specify the required behavior (C3).
Control
machine
CM ! C1
CD ! C2
OP ! E4
Controlled
Domain
CD ! C3
Obedience
C
OP ! E4
Operator
B
Institute for Software Research, International
19
Information display
 The
real world (or sometimes a lexical domain)
sends some phenomena (C1) to the machine, which
sends commands (E2) to the display device.
Information
Machine
RW ! C1
IM ! E2
Real
World
RW ! C3
C
Show
Status
DD ! Y4
Display
Device
C
 Note
that the real state of the world (C3) might not
be entirely visible to the machine, yet the symbolic
state (Y4) of the display should still be right!
Institute for Software Research, International
20
Workpieces
A
user’s editing commands (E3) implicitly specify
what the document’s symbolic state (Y4) should be.
Editing
Tool
ET ! E1
WP ! Y2
US ! E3
Work
pieces
WP ! Y4
X
Command
effects
US ! E3
User
B
 In
many cases, the symbolic state seen by the
machine (Y2) matches the real symbolic state (Y4).
Institute for Software Research, International
21
Transformation
 The
machine reads the input document’s symbolic
state (Y1) and actually constructs a totally new
symbolic state (Y2) in an output document.
Transform
Machine
In ! Y1
TM ! Y2
Input
IN ! Y3
X
IO
Relation
OU ! Y4
Output
x
 Usually
the symbolic states seen by the machine (Y1
and Y2) match the true states (Y3 and Y4).
Institute for Software Research, International
22
Things to think about on your own:
Problem Frames and some sample problems.
 What
should the problem diagram look like for
each of the following example problems?
 Writing
a report for school
 Creating a spreadsheet for a business
 Browsing the web
 Making a heart pacemaker beat once per second
 Steering a nuclear missile into a city
 Encrypting a bank database
Institute for Software Research, International
23
Things to think about on your own:
Problem frames uses separation of concerns.
 Separation
of Concerns is a classic technique for
managing complexity
 Focus
on one thing at a time, allocate responsibility
 Assumes that partial solutions can be combined
 In
problem frames,
 Different
domains capture different concerns
 Domains scope the problem (ie: if it’s not in the
diagram, then the developers can ignore it)
 What
other mechanisms do we have in software
engineering for separation of concerns?
Institute for Software Research, International
24
Things to think about on your own:
Problem Frames is a language.
A
language has syntax - what the language looks like
 Primitive
elements – boxes, lines, and letters in this case
 Primitive operations – hooking boxes, lines, etc together
 Encapsulation, abstraction, and composition
mechanisms – we’ll discuss this in another lecture
 To
be useful, it also has semantics – what it means
 You
need rules that describe the relationship between
things in your notation and things in the real world.
 Boxes
are domains, lines are phenomena interfaces, etc.
 Problem
frames is a problem description language.
 Can you think ways to improve the language?
Institute for Software Research, International
25
Things to think about on your own:
How would you apply this in a business?
 Status
of Problem Frames: a thoughtful proposal
 Not
actually in common use yet, no tools, not complete
 But there’s a growing community of interest
 So at present, it’s a good conceptual tool
 How
would you need to modify Problem Frames so
that you could use it in a software development
organization?
 What kind of information would you need from
your clients so that you could apply Problem
Frames?
Institute for Software Research, International
26
Are there any questions?
Institute for Software Research, International
27