Back to Jackson

1. Back to Jackson • Consider how JSP views programming- • Describe structure I/O datastreams • Combine to produce a program structure • List operations necessary to produce outputs; put each operation in place in program structure • Write the program text adding conditions as needed for controlling iterations & selections. SSPD

2. Description First • In JSP we first describe the subject matter of the problem. • Then we turn attention to functional details • Notice how technical detail is relegated. SSPD

3. Abstraction in JSP • Notice that the models we build (the data structure) are abstract descriptions of the real world. • Whatever we include in the model can be used to produce system outputs. • If it isn’t in the model, we can’t produce outputs in respect of it. SSPD

4. JSD Same Foundations • The subject matter in JSD is the real world, strongly ordered in time, outside the system • Detailed function is production of system outputs • Early development concerned with description of real world. • Explicit consideration of function deferred. SSPD

5. JSD • JSD does not start from a given specification, nor does it decompose the system into sequential processes. • Instead, development begins by creating a specification for the system, building it up from parts which are themselves sequential processes. SSPD

6. Synthesis • Therefore, we say that JSD is an activity of synthesis rather than decomposition. • Used to develop systems in whose real world subject matter it is important to recognise occurrence of events within a time dimension. SSPD

7. KEY IDEA • It is claimed that easier to build moremaintainable systems with JSD… • …because the model of real world is a stable basis for development, being less likely to change than the functions built upon it. SSPD

8. Model & Function • In JSD we say that • the model implies function • i.e., we can specify any function in terms of members of the model. • But in dysfunctional decomposition • the functions imply the model • i.e., we build a model in terms of required functions. This is inherently less flexible. SSPD

9. SSPD

10. Car Hire Revisited • Let’s take a JSD view of the car hire problem. • What is the real world of the car hire firm’s manager? • The hiring and returning of vehicles. • Thus we can model a vehicle SSPD

11. VEHICLE WORKING LIFE PURCHASE DISPOSE RETURN HIRE Model of Vehicle HIRING * SSPD

12. Model Implies Function • The requirements for the system were (in order):- • Display number of hirings • Display average hiring duration • Functional spec:- • Inspect model and count all hire events • Inspect model and evaluate period for each vehicle. • etc. SSPD

13. Model Implies Function II • Second requirement:- • Display longest hiring • Functional spec:- • Inspect model, for each hiring evaluate duration • Calculate longest period SSPD

14. Model Implies Function III • The third requirement was:- • Display hirings < 1 week • Display hirings >= 1 week • Functional spec:- • Inspect model. For each hiring, calculate duration. If 6 days or less put in one batch else put in the other. SSPD

15. Model Implies Function IV • The final requirement was:- • Allow the system to run at any time even when there are outstanding returns • Functional specification:- • Inspect the model. For each of the above requirements, ignore any hiring which has a hire event but no matching return event. SSPD

16. Immortality? • Is a JSD system therefore immortal? SSPD

17. Jackson System Development Introduction SSPD

18. Warning! • Some of the concepts in JSD are not easy to grasp at first SSPD

19. Data Modelling • Recall the data modelling relation: What does is-a-supplier-of mean? Discuss relation in terms of events. SSPD

20. Understanding Relations • Natural way to understand meaning of relation is to consider the real worldevents that affect it. • Natural way to explain relation is in terms of those real world events. • Event occurrence more basic than existence of a relation, thus that is where we will start our modelling. SSPD

21. Events in JSD • Events are: • atomic • instantaneous (both ideas are abstractions) • Example: lending a book in a library system SSPD

22. Event Attributes • What, who, when, where etc… • E.g., what was lent? When was it lent? Who lent it and to whom? etc. • Gives us attributes such as: • date, • ISBN • Borrower id etc. etc. for the LEND event SSPD

23. Define Event Classes • LEND (Book_Id, Member_Id, Resvn_Id, Date) • A book, whose identifier is Book_Id, is lent to the member whose membership number us Member_Id; date is the date of removal of the book from the library's premises; Resvn_Id is the identifier of the relevant reservation if the cook is borrowed against a previous reservation. SSPD

24. Importance of Events • Initial description in terms of what happens in the real world • Doing this begins to scope the eventual system • Narrative gives link between the formal system spec we are building and the real world as understood by its users SSPD

25. Objects & Event Orderings • Picture is not complete. Events are participated in by real world objects (e.g. librarians and borrowers) • We want to describe these objects that persist over time • Analysing event traces helps us to identify the objects of interest SSPD

26. Event Trace Analysis …Hire (Veh 3), Ret (Veh 2), Purchase (Veh 9), Hire (Veh 2), Hire (Veh 9), Hire (Veh 3), Ret (Veh 2), Ret (Veh 3), Ret (Veh 9)…Dispose (Veh 2), Hire (Veh 9), Ret (Veh 9), Dispose (Veh 9)… • Analysis of this elicits time ordered event lists • From this we derive candidate entities SSPD

27. VEHICLE WORKING LIFE PURCHASE DISPOSE HIRE Entities Entity persists over time & participates in time ordered event traces. * HIRING RETURN SSPD

28. Entity State • Entities have state. • State is recorded in entity’s fields (its instance variables) • The entity state vector will store info about the entity’s event history • E.g., Vehicle’s present state is ‘ON HIRE’, previous states include PURCHASE, HIRE, RETURN etc. SSPD

29. Entity Attributes • Attributes specified in terms of events • E.g., HIRE_COUNT • Also need to specify what attributes mean • E.g., is HIRE_COUNT incremented upon hiring out, or upon return? • What does attribute in-the-company mean? SSPD

30. Definitions of Event • Something that happens to which the system has to respond…they cause a response in the system and an update to the information stored within the system [Sutcliffe] • An event in the world that forms the subject matter of the system and about which the system must produce or use information [Cameron] SSPD

31. Definitions of Entity • Object of interest in the system which will undergo or cause change during system’s activity [Sutcliffe] • Object in the real world which participates in a time-ordered set of actions [Jackson] • Person, organisation or object that performs or suffers an interesting time sequence of actions [Cameron] SSPD

32. Finding Events • Events are atomic so reject those actions that are vague or that imply continuous actions • Ignore (for the moment) any actions which imply output or responses in the real world. In the modelling phase events are those actions which respond in some way to input messages SSPD

33. Guidelines • Decide on the external events which happen in the real world (e.g. customer orders goods) • Define how these events are communicated to the system as input (e.g. phone call is made) • Identify system inputs (action attributes) (e.g. a verbal order) • Define actions necessary to respond to messages in action attributes (e.g. despatch goods). SSPD

34. Action Attributes • Are answers to reasonable questions we might ask about an event • e.g., what was lent, who lent it etc. SSPD

35. Finding Entities • Start by analysing event traces (could be a lot of work here!) • Look for real world objects with which the system must interact • What is the main thing for which the system exists? • Entities could be the nouns in event descriptions SSPD

36. Try this Out • Have a go at the Stitch in Time company. SSPD