1 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)

2 Institute for Software Research, International Are there any questions?

3 Institute for Software Research, International Overview: This course is about deciding what to design. Engineering approach Problem Solution Knowledge of past solutions Business & market constraints Regulations Here a Miracle Happens

4 Institute for Software Research, International Course contents  Identifying the problem v Problem frames is for representing problems. v Contextual inquiry is for studying & representing the context of use. v Use cases are for describing generalized scenarios that the software will support.  Designing a solution v Prototyping identifies ways to refine software designs. v Usability deals with making the software easy to use. v Business and regulatory issues constrain choices about which markets to enter, and how to enter them.

5 Institute for Software Research, International Moving on to today’s lesson…

6 Institute for Software Research, International A question to get you thinking…  Which of these problems is not like the others? 1. Writing a report for school 2. Creating a spreadsheet for a business 3. Browsing the web

7 Institute for Software Research, International A question to get you thinking…  Which of these problems is not like the others? 1. Making a heart pacemaker beat once per second 2. Steering a nuclear missile into a city 3. Encrypting a bank database

8 Institute for Software Research, International 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.

9 Institute for Software Research, International Problem frames are a way of representing certain software-related expertise.  The nature of expertise v Experts have about 50,000 chunks of knowledge v It takes them about 10 years to become experts v This is true across many domains v Experts recognize these chunks instead of deriving them v What passes for insight or intuition is often recognition  The idea in problem frames v Frames represent chunks of knowledge v Knowing more variations will allow you to recognize more pre-solved problems and apply prior art v This is easier and less risky than analyzing from scratch

10 Institute for Software Research, International Basic steps in applying problem frames 1. Break the context into pieces (called domains ). 2. Identify the shared phenomena (called interfaces ) among the domains. 3. Represent the domains and their interfaces in a context diagram 4. 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.

11 Institute for Software Research, International A sample problem diagram: editing a “periods & ranges” database Data entry Medical staff PREdit machine Periods & ranges n m m o m: MS! (EnterPeriod, EnterRange, EnterPatientName, etc) [C1] n: PM! (EditOperations) [C2] o: PR! (DataValues) [Y3] X B

12 Institute for Software Research, International The different types of domains  Causal (C) – has predictable relationships among physical phenomena v The machine domain, which has a double stripe, is always a causal domain.  Biddable (B) - physical but unpredictable v Humans are the most common biddable domain.  Lexical (X) – physical representation of data and symbolic phenomena v Designed domains, which have a single stripe, are usually lexical domains.

13 Institute for Software Research, International Examples of each type of domain  Causal (C) v LCD screens v Heart pacemakers v Nuclear missiles  Biddable (B) v Humans  Lexical (X) v Word documents v Spreadsheets v HTML documents v Bank databases

14 Institute for Software Research, International The different types of phenomena  Causal (C or E) – the events that one domain initiates in order to influence or control another domain v Causal phenomena deal with what happens.  Symbolic (Y) – values, truths, and states v Symbolic phenomena are encodings of other phenomena.

15 Institute for Software Research, International Examples of each type of phenomenon  Causal (C or E) v DrawLine(x1,y1,x2,y2), supported by LCD screens v MakeElectricalPulse(voltage), supported by pacemakers v FireThruster(duration), supported by nuclear missiles v InsertRow(), supported by Microsoft Excel v ClickHyperlink(url), supported by humans  Symbolic (Y) v ListOfParagraphs(), supported by Word documents v GridOfCells(), supported by spreadsheets v LevelOfEncryption(), supported by bank database

16 Institute for Software Research, International A sample problem diagram: editing a “periods & ranges” database Data entry Medical staff PREdit machine Periods & ranges n m m o m: MS! (EnterPeriod, EnterRange, EnterPatientName, etc) [C1] n: PM! (EditOperations) [C2] o: PR! (DataValues) [Y3] X B All machine domains are causal. Databases are lexical. Humans are biddable. The act of giving inputs to the machine is causal. Sending SQL to the database is causal. The values are symbolic.

17 Institute for Software Research, International 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

18 Institute for Software Research, International Required behavior  Machine sends commands (C1) to controlled domain, which may provide feedback (C2)  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. Control Machine Controlled Domain C CD ! C3 CM ! C1 CD ! C2 Required Behavior

19 Institute for Software Research, International Commanded behavior  Now a human operator sends certain events (E4) that implicitly specify the required behavior (C3). Control machine Controlled Domain C CM ! C1 CD ! C2 Obedience Operator B OP ! E4 CD ! C3 OP ! E4

20 Institute for Software Research, International  The real world (or sometimes a lexical domain) sends some phenomena (C1) to the machine, which sends commands (E2) to the display device.  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! Information display Information Machine Real World C RW ! C1 Show Status Display Device C IM ! E2 RW ! C3 DD ! Y4

21 Institute for Software Research, International  A user’s editing commands (E3) implicitly specify what the document’s symbolic state (Y4) should be.  In many cases, the symbolic state seen by the machine (Y2) matches the real symbolic state (Y4). Workpieces Editing Tool Work pieces X ET ! E1 Command effects User B US ! E3 WP ! Y4 US ! E3 WP ! Y2

22 Institute for Software Research, International  The machine reads the input document’s symbolic state (Y1) and actually constructs a totally new symbolic state (Y2) in an output document.  Usually the symbolic states seen by the machine (Y1 and Y2) match the true states (Y3 and Y4). Transformation Transform Machine Input X In ! Y1 IO Relation Output x TM ! Y2 IN ! Y3 OU ! Y4

23 Institute for Software Research, International 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? v Writing a report for school v Creating a spreadsheet for a business v Browsing the web v Making a heart pacemaker beat once per second v Steering a nuclear missile into a city v Encrypting a bank database

24 Institute for Software Research, International Things to think about on your own: Problem frames uses separation of concerns.  Separation of Concerns is a classic technique for managing complexity v Focus on one thing at a time, allocate responsibility v Assumes that partial solutions can be combined  In problem frames, v Different domains capture different concerns v 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?

25 Institute for Software Research, International Things to think about on your own: Problem Frames is a language.  A language has syntax - what the language looks like v Primitive elements – boxes, lines, and letters in this case v Primitive operations – hooking boxes, lines, etc together v Encapsulation, abstraction, and composition mechanisms – we’ll discuss this in another lecture  To be useful, it also has semantics – what it means v You need rules that describe the relationship between things in your notation and things in the real world. F Boxes are domains, lines are phenomena interfaces, etc.  Problem frames is a problem description language.  Can you think ways to improve the language?

26 Institute for Software Research, International Things to think about on your own: How would you apply this in a business?  Status of Problem Frames: a thoughtful proposal v Not actually in common use yet, no tools, not complete v But there’s a growing community of interest v 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?

27 Institute for Software Research, International Are there any questions?