1 Institute for Software Research, International Methods of Software Development Problem Frames 2 (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 Today’s lesson: All about models  One of the most important techniques of computer science – and hence of software engineering – is the creation of new models that address specific projections of a problem  Good models highlight important details and leave out unimportant details.  Example from programming: v A good OO model includes only important members and omits useless members.  Examples from problem frames: 1. Domains are models of real world concerns 2. Phenomena are models of interactions 3. Frames are models of stereotypical problems

4 Institute for Software Research, International Types of models  Analytic models versus analogic models v Analytic models (like problem frames) are just simplified descriptions of the real world. v Analogic models (like databases) are lexical descriptions of the real world, but they also create a “new reality” that must be kept in sync with the real world.  Example: v A textbook drawing of a binary tree helps us to visualize data, but the drawing exists outside the machine—so there is no burden on the machine to maintain the drawing’s accuracy.

5 Institute for Software Research, International Types of models  Analytic models versus analogic models v Analytic models (like problem frames) are just simplified descriptions of the real world. v Analogic models (like databases) are lexical descriptions of the real world, but they also create a “new reality” that must be kept in sync with the real world.  Example: v A library database has “member” and “card” records. These are real records (they take up hard drive space!) The machine must ensure that these records are related to one another in the same way that real-life people are related to cards. This is because an analogic model is physically real to the machine.

6 Institute for Software Research, International Some variant frames (but not all) contain an analogic model  Problem frames can be extended by frame variants.  Typically, a variant adds a domain to the diagram.  The three variants we will consider: v Description variant v Model variant v Connection variant Jackson describes a few others in addition to these. Variants are not part of your required reading but may be useful when you do your project.

7 Institute for Software Research, International Example of a description variant  Sometimes your machine needs to behave slightly differently each time it executes.  The required behavior (or other descriptive info, which might be an analogic model) can be stored in a file or other lexical representation. Control machine Controlled Domain C CM ! C1 CD ! C2 Descriptive File X DF ! Y3 CM ! E4 Behavior CD ! C2 DF ! Y3

8 Institute for Software Research, International Example of a model variant  Consider a Commanded Behavior problem…  Sometimes the Controlled Domain (CD) is a real hassle to control.  In that case, it is often helpful to think of breaking the problem into two parts. Control machine Controlled Domain C CM ! C1 CD ! C2 Obedience Operator B OP ! E4 CD ! C3 OP ! E4

9 Institute for Software Research, International Example of a model variant  First, we detach the machine from the operator. Control machine Controlled Domain C CM ! C1 CD ! C2 Obedience Operator B OP ! E4 CD ! C3 OP ! E4

10 Institute for Software Research, International Example of a model variant  Next, we insert an analogic model of CD’s behavior. Control machine Controlled Domain C CM ! C1 CD ! C2 Obedience Operator B OP ! E4 CD ! C3 OP ! E4 Behavior Model X

11 Institute for Software Research, International Example of a model variant  Then, we insert a machine that acquires commands. Control machine Controlled Domain C CM ! C1 CD ! C2 Obedience Operator B OP ! E4 CD ! C3 OP ! E4 Behavior Model X Editing Tool

12 Institute for Software Research, International Example of a model variant  Last, we link tool to model, and model to CM. Control machine Controlled Domain C CM ! C1 CD ! C2 Obedience Operator B OP ! E4 CD ! C3 OP ! E4 Behavior Model X Editing Tool ET ! E5 BM ! Y6 CM ! E7

13 Institute for Software Research, International Example of a model variant  Subproblem #1: editing the model. Look familiar? Operator B OP ! E4 Behavior Model X Editing Tool ET ! E5 BM ! Y6 Command effects BM ! Y6 OP ! E4 Control machine Controlled Domain C CM ! C1 CD ! C2 BM ! Y6 CM ! E7

14 Institute for Software Research, International Example of a model variant  Subproblem #2: executing the model. Look familiar? Control machine Controlled Domain C CM ! C1 CD ! C2 Behavior Model X BM ! Y6 CM ! E7 Obey Commands CD ! C2 BM ! Y6 Operator B OP ! E4 Editing Tool ET ! E5 BM ! Y6

15 Institute for Software Research, International Example of a model variant  The real problem is a composition of subproblems. Control machine Controlled Domain C CM ! C1 CD ! C2 Obedience Operator B OP ! E4 CD ! C3 OP ! E4 Behavior Model X Editing Tool ET ! E5 BM ! Y6 CM ! E7

16 Institute for Software Research, International Example of a connection variant  Sometimes an interface is unreliable, slow, or problematic in a way that will affect your solution.  Then you need a domain to show this concern!  Example: inserting a Terminal Server into an Information Display problem Information Machine Real World C RW ! C1 Show Status Display Device C IM ! E2 RW ! C3 DD ! Y4

17 Institute for Software Research, International Example of a connection variant  First, detach the interface from the machine. Information Machine Real World C RW ! C1 Show Status Display Device C RW ! C3 DD ! Y4

18 Institute for Software Research, International Example of a connection variant  Next, insert a domain to represent the new concern.  Finally, hook the new domain to the machine via an interface that the machine will see.  Note: The server is causal, not lexical, so it is a device, not an analogic model. Information Machine Real World C RW ! C1 Show Status Display Device C TS ! E6 RW ! C3 DD ! Y4 Terminal Server C IM ! E2 TS ! E5

19 Institute for Software Research, International Recap: Use variants to describe aspects of the problem that affect the solution.  Q: How do you know if you have left anything out?  A: Ask yourself whether implementing the problem, as depicted, will lead to a correct solution. v If a detail doesn’t affect your solution, you can omit it. v If a detail affects your solution, you must include it. v Chapter 5 of Problem Frames deals with how you argue the correctness of your analysis v With experience, you will have an easier time knowing if the real problem is a variant of a basic problem frame.  But sometimes, using a variant is not enough!

20 Institute for Software Research, International Domain flavors & other characteristics  Sometimes, your description of the problem must include extra information about the domains.  You can sometimes just write this information on a piece of paper next to the diagrams.  What information might affect your solution? v What is the domain’s structure, if any? v Does the domain always behave the same? v Can the domain ever change state?

21 Institute for Software Research, International We already looked at the 3 basic properties  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.  Causal, biddable, and lexical are mutually exclusive

22 Institute for Software Research, International Other properties include “flavours”  Domain characteristics need finer discriminations to describe the particular concerns of specific domains v Structural characteristics (Sequence? Tree?) v Behavioral characteristics F Static: causes no events, and has no changeable states F Inert/Passive: may react, never initiates events F Active/Stoppable: can initiate inhibitable events F Autonomous/Unstoppable: can initiate uninhibitable events v Other properties of domain descriptions F Formal or informal? F Optative or indicative?

23 Institute for Software Research, International (The labelling of “activeness” is kind of a mess.) Clarification from M. Jackson (2004) Q: What is the difference, if any, between inert (p.97) and passive / state-reactive (pp.156-7)? A (from M. Jackson to M. Shaw): I originally intended to use 'inert' of domains and 'passive' of states. An inert domain is always in one of the varieties of passive state. But, as you see, I fell into the habit of sometimes speaking of a domain as passive. This is an error, and I am grateful for the correction.  Bottom line: you can use the labels on the preceding page, or you can precisely define labels of your own

24 Institute for Software Research, International Main lesson: Good problem models include all details that might affect the solution  Analytic models describe the world; analogic models describe the world and create a new world  Problem frames are analytic models; problem diagrams sometimes include analogic models  To accurately represent the real world… v … break problems into subproblems as needed v … use variant frames as needed v … describe domain flavors as needed  Omit any details that won’t affect the solution.

25 Institute for Software Research, International Things to think about on your own: Do you understand analytic vs analogic? Analytic, analogic, both, or neither?...  Air traffic controllers use a display of plane positions. Is the model behind the display an analytic or analogic model?  When solving physics problems, students draw diagrams. Are these analytic or analogic models?  During a fashion show, models wear the new designs to show off what the designs look like. Are these people analytic or analogic models?  A test harness executes a program and generates a description of the program’s behavior. Is this description an analytic or analogic model?

26 Institute for Software Research, International Things to think about on your own: Your model can make or break your project. Suppose you’re in a software development firm.  When designing a problem model, would you… v … work with a team or work alone? Why / why not? v … talk with the customers? Why / why not?  How would a problem model help you… v … design a solution? v … discuss designs with other people? v … evaluate designs prior to implementation? v … implement a selected design? v … test the implementation? v … refine the design and implementation?

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