1. JSD Networking Building the System Specification

2. 2SSPD - Week 7 What are we building? Not a DFD, or an ERM But a network of concurrently running processes

3. 3SSPD - Week 7 The Network Diagram Shows all entity model processes Their inputs Their outputs Their relationships All viewed from the client’s point of view - remember, this is a real world model.

4. 4SSPD - Week 7 Diagram Components TGM Time Grain Marker DS Data Stream SVState Vector Customer Entity/Process Fixed Merge Rough Merge ClockClock Process Connection 1: Many Connection 1:1

5. 5SSPD - Week 7 Key Concepts Datastream connection State vector connection Time grain marker

6. 6SSPD - Week 7 Datastreams Imagine a drainpipe –Into one end of which you put coloured balls –In what order do they come out the other end? –How do you retrieve the fifth ball? Essentially this is a FIFO queue

7. 7SSPD - Week 7 Datastream Rules All messages must be read in the order they were written Writer dependent Writing process can cause blocking of reading process Imagine washing dishes...

8. 8SSPD - Week 7 State Vectors A means of interrogating the current state of a process Provide a snap shot Initiative lies with inspecting process Cannot cause blocking, always available

9. 9SSPD - Week 7 Time Grain Marker A special form of the datastream Contains timing signals generated by a clock process Used to trigger the execution of real- world-time-dependent processes

10. 10SSPD - Week 7 Datastream vs State Vector Datastream long term connection, state vector loosely coupled Datastream connection controlled by writing process, state vector by reading process Datastream messages are queued, state vector info must be fetched at right time otherwise it is lost

11. 11SSPD - Week 7 Metaphor State vector Datastream What happens in each case if you need to get up at 4.30 a.m. to catch early train to job interview?

12. 12SSPD - Week 7 An Example See handout for entity models

13. 13SSPD - Week 7 Initial Model This initial model provides a view of the real world without having considered functional requirements Now we need to specify the system At last, time think of the functional requirements

14. 14SSPD - Week 7 Elaborating the Model If the model is a simulation of the real world Then information outputs (functional requirements) should simply be the result of inspecting the state of the model e.g., how many hirings were there?

15. 15SSPD - Week 7 Adding functions We can add function to the model in two ways: –embedded functions: information requests that can be satisfied by existing process logic –imposed functions: requests that do not map onto existing model process, e.g. time-dependent functions. I.F. basically result from identifying a structure clash.

16. 16SSPD - Week 7 Requirements List Any system produced must allow for the provision of output in a timely manner, in respect of cars due for replacement or servicing. Also, management information to allow the regulation of the servicing and replacement policies may well be required. The hire fees collection and accounting is not to be considered at this time.

17. 17SSPD - Week 7 Distills to... Report1: Generated weekly to list all vehicles that have been serviced or replaced that week Report2: Generated upon user request to list all cars in need of servicing & replacement Report3: Additionally, management wants to know each time customer returns a car

18. 18SSPD - Week 7 Embed or Impose? Report 1 must be imposed as model processes are not structured around notion of a week Report 2 must be imposed as its execution is triggered ad-hoc Report 3 can be embedded into existing CUSTOMER process

19. 19SSPD - Week 7 Elaborated Network

20. 20SSPD - Week 7 Complete the Model Draw structure diagrams and write structure text for new imposed functions Update existing model processes to include any new embedded functions Now we have a system specification It remains now to design the implementation