Why?: Documenting the Missing Interrogative Using an Essential Logic Model

Size: px

Start display at page:

Download "Why?: Documenting the Missing Interrogative Using an Essential Logic Model"

Chad Ray
6 years ago
Views:

1 Why?: Documenting the Missing Interrogative Using an Essential Logic Model R.J.Collins Abstract This paper describes a diagramming convention called an Essential Logic Model (ELM). An ELM tells the story of the system and the decisions that were made during its construction. The ELM shows the relationship between broad classes of requirements and how these relate to the explanatory concepts developed and used during system development. The diagram also shows the important processes that exist within the system and the objects that the new system will interface to and on which it is dependent. During some stage of development, requirements for a system as a whole are normally decomposed and attributed to sub-system components. The ELM relates this information. It shows how the collection of requirements, existing real-world objects, processes and the explanatory concepts map onto the new design objects proposed as part of the system. It is argued that, if safe systems are to be produced and maintained then there must be harmony in the design decisions made by groups of software engineers. An implementation is the realisation of a design process. Project documentation may record the realisation but may lose the essence of the logical process that resulted in that realisation. An ELM is a didactic tool to be employed between software developers to externalise and record a logical series of thought processes that result in a design realisation. Experience suggests that this process of externalisation and documentation serves to highlight errors and inconsistencies in thinking. This seems to be particularly true in the case of large, complex systems when individuals are unlikely to be experts in all aspects of the system. Page 1

2 Introduction A number of system specification, design, analysis and implementation methods may be characterised with respect to simple interrogatives. For example, it has been argued that formal specifications employ a powerful abstracting mechanism by defining what a function should achieve without stating how it should be implemented. For example in talking about the formal language Z, Potter, Sinclair and Till have argued: In short, the concerns of specifications are the issues which describe what a system must offer rather than the prescription of how these things are to be achieved. Rann, Turner and Whitworth have re-iterated: (Potter, Sinclair and Till 1991) Formal specifications are used to define in a precise way the properties of a system. A specification describes what a system must do, not how it is to be done. (Rann, Turner and Whitworth 1994) Similar claims are made of other structured systems analysis techniques (Ashworth and Goodland 1990; Longworth 1992) Object Oriented designs employ the notion of encapsulation. The published operations of an object inform the client of what the object will do, whilst hiding the implementation level how information and hence protecting the user from details of construction. In talking about object-oriented programming, Cox has said: Encapsulation is the foundation of the whole approach... Whereas consumers once specified how each operation should be performed by naming a specific piece of code, they now specify only what should be done, leaving the object to choose code that is appropriate to its type or class (Cox, 1994) In a similar manner Who information is a vital component of human-computer interface design. Users must be characterised so that their specific needs can be adequately catered for. Software project management regimes must cater for the identification of personnel to complete specific development tasks. In this case the Who information refers to the developer rather than the user. The distinction of real-time software design compared to other types of software may be considered to be its time (or order) critical nature. The various methods of specifying dynamic behaviour, such as State-Transition Diagrams, address the when question for processes. Page 2

3 It is considered that existing documentation methods that encode what a system must do and how that function is achieved may fail to record why specific design decisions were made. If software updating efforts are to be consonant with an original design process effort then software engineers must understand why things are they way they are. This paper considers the role of the missing interrogative Why? and proposes a method for documenting the why information of system development Rann, Turner and Whitworth have argued:..a large part of software development effort is spent on making programs evolve to fit new needs. It is common to find that small changes take much longer to implement than would be expected. One reason for this is that it takes programmers some time to understand the system before they can even think about making changes (Rann, Turner and Whitworth 1994) It is considered that this issue may be particularly problematic in the case of safety critical software developments. Errors may be introduced into software designs during the modification and update processes because software engineers fail to appreciate the logic behind particular aspects of the design. Skills may be very diverse within an extended development team on a large system development. It may be argued that to increase harmony between design decisions made by different groups, each group must be able to both communicate and understand why particular decisions have been made. The following text presents a straight-forward method for expressing and documenting why things are, as they are, within a system design. The Essential Logic Model An Essential Logic Model (ELM) tells the story of the system and the decisions that were made during its construction. The ELM shows the relationship between broad classes of requirements and the explanatory concepts developed and used during system development. The diagram also shows the important processes that exist within the system and the objects that the new system will interface to and on which it is dependent. It often the case that during some stage of a large system development, requirements for the system as a whole are decomposed and attributed onto components of the system. The ELM relates this information in a concise manner. The ELM shows how the collection of requirements, existing objects, processes and the explanatory concepts applied to them lead onto the new objects proposed as part of the system. It is considered that the ELM finds a natural place within the collection of Object Oriented Analysis (OOA) conventions and techniques. The relationships between the defined objects and the existing system objects may be documented in an Information Page 3

4 Model (IM) or Entity Relationship Diagram (ERD) (Shlaer and Mellor 1992). This diagram and its accompanying documentation shows how the various components will relate to each other and highlights their important interfaces. If an ERD shows what a system is, then the ELM shows why the system is as it is. The ELM Symbology An ELM consists of four types of boxes as illustrated in figure 1. 1 An Object 2 A Process 3 A Requirement 4 A Concept Figure 1: The Four Symbols of an Essential Logic Model In this diagram Objects are exactly synonymous with the objects of OOA. Processes are synonymous with the processes of Data-Flow Diagrams. Requirements are intended to capture important constraints on system implementation. Concepts are the explanatory notions we introduce to make sense of the system and of the problem domain in general. Each box is given a unique number to facilitate referencing. In an ERD boxes contain short, explicit textual descriptions. Boxes are joined by lines intended to represent the flow of logic. In other words, the lines are not strongly typed in the sense that they represent data-flow or relationships. Rather, they connote the way in which one idea leads to another. The idea in this case may be an abstract concept, but it may also be an explicit requirement, a process or an object. Page 4

5 Accompanying an ELM diagram is a narrative text that provides more details of the story or logic of the design evolution. The next section presents an extended example of this narrative text and the ELM that accompanies it. An Extended Example of an ELM for a Automatic Train Control System The following list of numbered items refer to the ELM in Figures 2a and 2b: 1. There exist such things as 'Trains'. 2. There exist such a things as a 'Railway Network' (tracks and points with topology). 3. Trains must not make contact with each other. 4. Trains must be time-tabled around the network. 5 Time-Tabling (4) and train avoidance (3) represent constraints on train 'time and position'. 6. It is desirable to have a high packing density of trains within the network in order to increase utilisation and average speed. 7. Packing Density may be achieved by utilisation of 'Moving Block Principles'. 8. There are two broad schemes for handling time and position constraints: (1) Autonomous trains with knowledge of piers following avoidance strategy; or (2) A Central Control function with knowledge of all trains issuing nonintersecting paths. The later scheme was chosen 9. The concept of non-intersecting time and position (3+5) coupled with the concept of a central control (8) and of moving block principles (7) leads to a concept of centrally issued, non-intersecting paths (Limit of Movement Authority). 10. The central control (8) mechanism by which Limit of Movement Authorities (LMA) (9) and other moving block principles (7) are implemented is termed a Moving Block Processor. 11. For reasons of speed and safety It is required that trains be driven automatically. 12. The train (1) is subject to physical properties (such as momentum and wheel traction) that introduce time/speed/position constraints into the process of following an LMA. This leads to a concept of Safe Braking Distance. Page 5

6 13. In order to implement a 'Safe Braking Distance' algorithm it is necessary for a 'train' to have accurate information of its location and its speed. 14. Numerical safety requirements (and high-integrity design principles) can only be satisfied with diverse control and protection. 15. The diversity concept (14) has implications for speed and location measurement (13) and this results in diverse mechanisms for speed and location determination. 16. LMAs must be communicated from a central control system to the 'Train'; 17. The mechanism for transporting information from the central control mechanism to the train is are communications units; 18. In order to implement a safe braking distance (12) scheme there has to be a process of braking the train. 19. It is important that the diversity concept (14) be applied to the braking process (18) because braking is a key area of safety. 20. In order for an LMA to have meaning it must relate to a 'known' railway topology. 21. Different railways may have different topologies and topologies may change over time, this implies that such a thing as Configuration Data exists. 22. Configuration data (21) must necessarily be produced. 23. The mechanism for the production of configuration data (22) is a Data Generation Facility. 24. As well as being produced (22), configuration data (21) must be distributed to the various part of the system. 25. It is required that data describing the operational characteristics of should be collected from the various part of the system for the purpose of analysis. 26. The process of distributing data to system components (24) and of collecting data from them (25) is similar enough for both tasks to be efficiently accomplished by a single mechanism. 27. If data is to be analysed (25) then some mechanism must exist for performing this analysis. 28. Trains are fitted with doors. 29. There is a requirement for safe operation of doors that means that doors must reliably, only open under specific circumstances (Train position and time). 30. Platforms may be fitted with Platform Screen Doors (PSDs). 31. As is the case for train doors, there is a requirement for safe operation of the PSD. 32. The general concept of diversity coupled with the requirements for safe door operation leads to a concept of diverse door control. Page 6

7 33. The requirements for safe door opening (29) leads to a concept that there are special, safe positions for door opening. 34. The concept of safe positions for door opening (33) leads to a requirement that the train position must not move away from a safe location whilst the doors are open. 35. The requirement to not move whilst the doors are open (34) leads to the concept that door state must be communicated to the train control system 36. The general concept of diversity (14), the concept of diverse control for door opening (32) and the requirement for automated train driving (11) leads to separate implementations for train control and train protection. Conclusion The ELM has so far been used on two major systems developments by the author. Space does not permit a detailed description of these projects, however the diagrams were generally found to be easy to learn and straightforward to use. At an informal level the ELM was considered to be a useful addition to the armoury of system analysis and documentation tools. The method is tentatively offered here in the hope that it will be applied on further projects and that its usefulness will be measured in a more systematic manner by other workers. Ashworth, C. And Goodland, M. (1990) SSADM: A Practical Approach McGraw-Hill: Berkshire, UK ISBN Cox, B. (1944) Object-Oriented Programming Addison-Wesley ISBN Longworth, G. (1992) A User s Guide to SSADM NCC Blackwell: Manchester ISBN X References Potter, B., Sinclair, J. And Till, D. (1991) An Introduction to Formal Specification and Z Prentice Hall : New York ISBN Page 7

8 Rann, D., Turner, J. And Whitworth, J. (1994) Z: A Beginner s Guide Chapman and Hall: London ISBN X Shlaer, S. and Mellor, S.J. (1992) "Object-Lifecycles: Modelling the World in States" Prentice Hall: Englewood Cliffs Page 8

9 2 Railway Network 3 Train Avoidence 5 Time and Position 11 For reasons of speed and safety It is required that trains be driven automatically 1 Trains 6 Efficiency=> Packing density of trains 4 Time-Tabling Requirement 7 Moving Block Principles 9 Limit of Movement Authority 12 Safe Braking Distance 20 Topological Information about Railway 25 Operational Charatersitics of system must be observed/recorded and analysed 8 Central Control 21 Configuration Data 22 Preparation of data 24 Distribution of Data 10 MBP 23 Data Generation Facility 26 Data Update Unit (DDU) 16 Track to Train Comms 27 Data analysis system 17 MCU/FCU Figure 2 Page 9

10 36 ATP/ATO 14 Diversity 19 Service Brake/ Emergency Brake 18 Train Braking Speed and Location Measurement Tacho's, Dopplers and APRs (APRs) 35 Train control must have door state communicated to it 28 Train Doors 29 Requirement for Safe Operation of Train Doors 32 Diverse Control of Door Opening 34 Train must not move away from safe location when Doors open 30 Platform Screen Doors 31 Requirement for safe operation of PSD 33 Safe opening only possible when train at specific locations Figure 3 Page 10

Software Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1

Software Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be