1. Problems and Frames III 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