Schemas, Frames and Knowledge in Systems Development

1. Schemas, Frames and Knowledgein Systems Development Lecture 9

2. Topics • Prize giving • Bus example answer • Schemas, Frames, Pre-structuring • A problem • Kinds of systems • Repository • Simulation • Decision support • Next week – Matching problems

3. Bus Display • The enhanced model to handle time • The simplest possible data model • Relations and Business Objects • Test-driven development • Route as a Schema

4. route routeno serviceno destination bay onlinesched departure dtime runperiod startdate enddate The enhanced model select * from route natural join departure natural join runperiod where dtime > current_time and current_date between startdate and enddate

5. The simplest possible modelOccam’s Razor • ‘do the simplest thing possible to meet the requirements’ • A single routeno identifies a ‘route’ • Code incorporates variations such as • Direction • In term/out of term • New releases of timetables • But no requirement to display such data, so don’t model as separate attributes

6. Objects and relations • route or Route* ? • The route base record • Or the ‘closure’ of route relations • base+runperiods+departures • Route* is the Business object – the unit of creation, retrieval and deletion • Object-relational databases provide some support for Route* as a Class • Both the Relational and the Object-oriented data models impose a structure on the DoD

7. Automated Testing • Test-driven development • tests (input + expected output) written BEFORE the code • the code is written to make the tests work • tests automated • Tests run when a change is made – regression testing • In the example solution: • A test script sets up minute amount of data • Each test defines the expected outcome • Script can be run repeatedly until all tests pass • Issues • What kinds of system functionality can be tested this way? • Should developers be responsible for devising their own tests? • Can software be adequately tested?

8. Schema Development descriptive What is a route? DoD schema Use prescriptive A route is a …

9. Schema in Use • Schema has a fixed structure with a set of place holders to allow variation: • A slot for the single destination of all buses on the route • So a route can’t have multiple destinations • But the last 70 goes to Muller Road Depot, not Centre • So this will have to be a different route • Or alter schema to allow over-ride destination in departure • A Schema structures our perception of the world • We change the schema when the fit is poor

10. Minsky’s Frames • Marvin Minsky is one of the fathers of artificial intelligence • “When one encounters a new situation (or makes a substantial change in one's view of the present problem) one selects from memory a structure called a Frame. This is a remembered framework to be adapted to fit reality by changing details as necessary” • “A frame is a data-structure for representing a stereotyped situation, like being in a certain kind of living room, or going to a child's birthday party. Attached to each frame are several kinds of information. Some of this information is about how to use the frame. Some is about what one can expect to happen next. Some is about what to do if these expectations are not confirmed.” • “Thinking always begins with suggestive but imperfect plans and images; these are progressively replaced by better–but usually still imperfect–ideas.” • Marvin Minsky, A Framework for Representing Knowledge, MIT-AI Laboratory Memo 306, June, 1974

11. Gestalt psychology • ‘Gestalt’ – form; pattern; shape; organised whole or unit • notion of pre-existing schemata, or organisational frameworks for structuring information, as opposed to perception built up from visual stimulus alone. • In the case of visual perception, a schemata provides a framework within which external stimuli are sensible. [A frog’s visual and motor system is pre-programmed for fly-recognition]

12. Design Studies • Cognitive psychologists observe that for an experienced analyst designing a familiar object in a familiar domain, the overall task could be characterised as being dominated by the retrieval of previously-stored knowledge (Adelson and Soloway). • Research by Curtis et al has shown the importance of domain knowledge in design, where domain knowledge entails understanding of the problems which occur in a specific application field and the tried and tested (and the failed) solutions. • Brown and Chandrasekaran identify the strategy of 'Design by Critiquing and Modifying Almost Correct Designs' as one of four main design processes (decomposition, design plans, and constraint solving are the others).

13. Pre-structuring • Hillier, Musgrove and O'Sullivan suggest that [building] design is essentially a matter of prestructuring problems based on the designer's knowledge : • of solution types • of the 'latencies of the instrumental set' (the raw materials + time) in relation to solution types • of informal 'codes' which relate problems to solution types • “it is not a matter of whether the problem is pre-structured but how it is pre-structured, and whether the designer is prepared to make this prestructuring the object of his critical attention” • Hillier Musgrove and O’Sullivan Knowledge and Design 1972

14. “A Pattern Language” • Christopher Alexander and colleagues wrote an influential collection of 253 ‘patterns’ for living – good solutions to recurring problems in architecture. • Language intended to provide a basis for community architecture • Gamma et al picked up this work and applied it to the emerging area of Object-oriented Programming. • Provides a language for developers to use within a project • ‘We need the Observer pattern here’ • Pattern conferences develop a rich array of patterns encapsulating the experience of developers in many software and organisational contexts.

15. Jackson’s Problem Frames • “An inability to discuss problems explicitly has been one of the most glaring deficiencies of software practice and theory. Again and again writers on development methods claim to offer an analysis of a problem when in fact they offer only an outline of the solution, leaving the problem unexplored and unexplained” • Jackson adopts a more formal, analytic approach to problem analysis and has identified a small number of Problem Frames. [more in a later lecture]

16. Problem: Police Identity Parade • See handout

17. What kind of System is it? • a repository of data • a model of a Domain of Discourse • an advisor – classifying, matching • a co-ordinator of human activity • a tool for the construction of an artefact • a learning system • ..... • Real systems have aspects of several kinds but it helps to focus of each viewpoint in turn, then integrate them – divide and rule

18. Repository Frame • Common to view an information as a simple repository of data. • Data is collected, stored, kept safe from falling into the wrong hands, from being lost. • Data can be extracted, reorganised, removed if no longer relevant • Data should only be accepted if it conforms to rules for good data -‘integrity rules’ • CRUD (Create, Retrieve, Update, Destroy)

19. Repository Frame (2) • In the problem, we need to be able to • store data about suspects and volunteers • readily retrieve data when required • keep the data secure from loss, or access by the wrong people • Metaphor : SYSTEM IS A BANK

20. Model Frame • System contains a model of the ‘domain of discourse’ • Issues: • how much of the real world to model, in what detail to support needs of users, now and in the future? • how to ensure that the model and the real world stay closely in synchrony - that changes to the real world (a volunteer moves house) are reflected in the model (address field updated) quickly and accurately

21. Model Frame • Now we must consider the process by which the model and the domain are connected, as well as the way the model supports the user’s needs • Jackson calls this the ‘Information Display’ Frame • E.g. a real-time bus information system – how is the changing bus position reported and used to predict an arrival time • Metaphor: SYSTEM IS A MAP

22. Resource Manager Frame • Allocation of scarce resources, such as • seats on flights • rooms for lectures • beds for patients • volunteers to identity parades • Problem is to maximise utilisation of resources whilst minimising delay and inconvenience to parties • Common Issues • Granularity of resource units • Handling time • Modelling and visualising allocations • Cancellation policy • Over-booking policy • Allocation policy - priorities, up-grading … • A common sub-problem is to match a client’s needs to available resources

23. Matching Frame • E.g. Shazam (2580) • Matching typically involve: • two sets of individuals : e.g. • the sample of music / suspect - Requirement • the database of tracks /volunteers - Resources • ‘adequate’ representations of both • a ‘fitness’ function which calculates how well matched a Requirement is to a Resource • More on Matching next week

24. Frame Approach to Development • Rough description of Problem • Select suitable Frame(s) to fit Problem • A well-fitting Frame provides: • standard terminology • checklist of issues which need to be addressed, questions which need to be asked • index of solutions to commonly occurring sub-problems • Frame allows us to draw upon relevant prior knowledge of this problem type • Identifying appropriate Frames is a Matching Problem!

25. Tutorial Questions • Skim Read Minsky’s paper on Frames • Identify aspects of the Identity Parade problem which map into these Frames: • Repository • Model • Resource Allocation • Matching • What analysis questions do these frames suggest? • What is left out?

26. Related Reading • Adelson, Beth and Soloway, Eliot, The Role of Domain Experience in Software Design, IEEE Trans. Soft. Eng. SE-11 Nov 1985 1351-1360 • David C. Brown and B. Chandrasekaren, Design Problem Solving : Knowledge Structures and Control Strategies, Pitman 1989 • Eric Gamma, Richard Helm, Ralph Johnson and John Vlissides Design Patterns, Addison-Wesley 1994 • Bill Hillier, John Musgrove and Pat O'Sullivan Knowledge and Design in Developments in Design Methodology ed Nigel Cross Wiley 1984 • Michael Jackson Software Requirements and Specifications Addison-Wesley 1994 • Michael Jackson Problem Frames, Addison-Wesley 2001 • Marvin Minsky, A framework for representing knowledge MIT 1974 • Peter Rowe, Design Thinking, MIT Press 1987