Problems and Frames III

1. Problems and FramesIII Recap and More Concepts

2. Definition “A problem frame is a kind of pattern. It define an intuitively identifiable problem in terms of its context and the characteristics of its domains, interfaces and requirement. Domain and interface characteristics are based on a classification of phenomena.” • Jackson, M.A., “Problem Frames”, Addison-Wesley, 2000, p.76

3. Decomposition • Software development projects are not all the same. • Decomposition = more manageable chunks • Good decomposition helps you to: • Solve the problem • Capture the problem • Describe the problem • Understand the problem • Analyse the problem

4. Dysfunctional Decomposition • Why not top-down? • TD = arrange functions in a hierarchy. At each level each fn is decomposed into a number of smaller functions until each fn is elementary • Takes no explicit account of the problem to be decomposed • Not familiar with the problem? -> unlikely to get a good decomposition

5. Use Case decomposition • Whole problem seen as building a machine to support a set of use cases • Use case = actor interacts with system and obtains an observable result • Withdraw cash • Open account, etc. • But many problems don’t consist of use cases. What are the use cases in a traffic light problem?

6. Problem decomposition • Sub problems are complete. You regard all the other sub problems as already solved. • Sub problems fit into a parallel structure not a hierarchical structure • Parallelism = some interaction between sub problems • Composite frames = standard decomp. into elementary frames (clock radio)

7. Decomposition Cont. • This type of decomposition is: • Heterogeneous: each of the simple problems needs a different problem frame. Few problems are homogeneous structures where all parts are of the same kind • Non-hierarchical: sub problems are parallel and may overlap -> projection vs partition.

8. Projection/Partition • We think of sub problems as projections of the full problem rather than partitions of the full problem • Projection is about overlapping • Some of the domains and their phenomena will also appear in other sub problems. • Eg., the clock in the VCR

9. Partition

10. Projection

11. Five Elementary Frames • Required behaviour • Behaviour controlled by machine • Controlled behaviour • Operator instructs controlling machine • Information display • Obtain info from RW and display it • Workpieces • Tool to create & edit objects • Transformation • Deriving formatted output from specified input

12. Domain types • Causal domains • Predictable causal relationships amongst phenomena, e.g. between motor and lift • Biddable domains • Consists (usually) of people. Lacks predictive internal causality: can’t compel people to initiate an event, such as returning overdue book • Lexical domains • Physical representation of data

13. Descriptions • With problem frames we must make three descriptions, one each for: • Requirement • Specification • Domain • Success when we make descs. that fit together properly. Needed to convince customer that you have mastered the problem: • Specified m/c behaviour combined with given domain properties achieves required behaviour

14. Machine Specification • Reversing the argument helps us to devise machine specification: • Capture the requirement • Investigate the domain to identify all causal properties, etc. • Devise a machine that exerts the correct control, behaviour, etc.

15. Frames and Methods • Ideally, each frame associated with systematic method known to be effective for analysing and solving any problem that fits the frame • Don’t look for general-purpose methods that address all development problems

16. Frame Misfits • When a frame starts to demand a description that doesn’t make much sense, or leaves out some other necessary description • E.g. making a sluice gate control problem fit an information display frame

17. VCR Problem • Finish your frame analysis of the VCR control problem