1. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 1 Software engineering for real-time systems Section 9 Diagramming and design notations

2. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 2 Objectives To show:  The general role of diagrams as a design and modelling tool/language.  The diagrams used for structured/data flow and object-oriented design techniques.  The general syntax and semantics of commonly-used notations (specifically Yourdon and the Unified Modelling Language (UML).  Why extensions and modifications of basic diagram types are needed in certain real-time applications Objectives

3. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 3 Part 1 The importance of diagrams The importance of diagrams

4. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 4 Why use diagrams As a MAINTENANCE tool As a DESIGN tool As a DOCUMENTATION technique As a COMMUNICATION Medium Diagrams can be put to good use in four main areas. The role of diagrams in software development

5. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 5 Diagrams “model” reality. They “abstract” reality from a particular domain to a model. BUT - the model has to be the right one for the domain. Fig.(a): Vehicle electrical system - maintenance domain. Fig (b): Vehicle electrical system - design domain Domain-specific views

6. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 6 High-level and low-level views

7. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 7 Thinks As a design tool Producing a diagram requires an explicit action. Diagrams can’t “lie”. Implicit relationships cannot exist. There needs a clear understanding of the problem in order to express things graphically (in pictures). Diagrams for design - Initial design

8. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 8 To be effective diagrams must have an agreed set of rules - syntax (notation) and semantics (meaning). This introduces formality and rigour. It eliminates ambiguity and ambivalence. It facilitates peer review and assessment. Diagrams for design - meaning and notation

9. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 9 Good, clear diagrams: Allow the design as a whole - and the component parts - to be reviewed and analysed. Highlight incorrect or illogical design feature. Enable errors to be corrected at an early stage. Diagrams and design reviews

10. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 10 High-level diagrams: Show overall structure. Describe overall functioning. Show the interaction of the system with its environment. Describe the function and interactions of the sub-systems. Low-level diagrams: Show detail. Emphasize internal information. Diagrams for documentation

11. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 11 The essential features of design documents. Extremely important in the post-design phase. Best done as an integral part of the design process. Document requirements

12. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 12 Diagrams for communication Used by Designer User Maintainer 4 1 2 3 DialogueMain use 3 1 2 4 During tendering, design and system acceptance. During the design phase On completion of design Post-design service phase Different people use diagrams. Different people have differing needs. Diagrams are produced and used at various points in the project (or product) lifetime. “Pictures” enhance communication by eliminating ambiguity and ambivalence. Diagrams for communication of information

13. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 13 Diagrams bridge the gap between what is wanted and what is provided. Why use diagrams when developing software systems? Diagramming and software development

14. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 14 Specification to code - a two-stage process Designing and modellingImplementing

15. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 15 Overall diagram set for real-time systems

16. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 16 Part 2 Diagrams for structured and data flow designs Structured and data flow design

17. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 17 Context diagram

18. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 18 Entity relationship diagram

19. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 19 State transition diagram (part) State 1 2 Event 1 Response 1 Event 2 Response 2 (a) Basic state transition diagram Ready to start Start in progress Start button pressed Energize starter relay (b) Example state transition diagram

20. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 20 Basic data flow diagram

21. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 21 Combining data and control transformations

22. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 22 Reacting to external events

23. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 23 Message sequence diagram

24. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 24 Top-to-bottom decomposition - basic structure

25. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 25 Jackson structure charts - basic constructs

26. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 26 Jackson structure chart - gas turbine example

27. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 27 Yourdon structure chart - basic layout and components

28. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 28 Yourdon structure chart - additional components

29. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 29 Yourdon structure chart - gas turbine example

30. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 30 Structured text example

31. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 31 SDL diagrams - telecommunications industries A diagramming method widely used in the telecommunications industry. Shows both state and processing information. SDL diagram constructs SDL process diagram constructs

32. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 32 Modelling the behaviour of interacting processes - sequence and state diagrams

33. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 33 SDL process diagrams for process B

34. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 34 Specimen event-response list

35. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 35 Part 3 UML diagrams for object-oriented designs Outline of UML diagrams

36. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 36 Navigator Pilot Nav/Was systemAir data system Get Navigation Waypoints Set Airfield Altitude Navigator Pilot (a)(b) Detailing requirements - use case diagrams (recap)

37. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 37 Set airfield altitude Set autopilot mode Validate data range > Check alarm status Maintain generating systems Set alarm limits > (b) (a) The include and extend relationships

38. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 38 UML Deployment diagram Deployment diagrams are used to model the physical aspects of systems. A deployment diagram is a “graph of nodes connected by communication associations”. A node is a “run - time physical object that represents a processing resource”. Node

39. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 39 A package is nothing more than a holder for other items (e.g. objects, classes, other packages, etc.). The symbol is a “tabbed” rectangle. Its name is written either within the main area or the tab. The UML package diagram

40. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 40 The dependency relationship shows that packages “welding controller” and “cutting sequencer” somehow depend on the package “system operating parameters”. It indicates that changes made within “system operating parameters” may have consequential effects on the other packages. Package dependencies

41. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 41 In software terms: The class symbol translates to a source code declaration. It defines the form, content and behaviour of objects. Attributes become data items. Operations are implemented by subprograms. SpeedSensor WheelSpeed SendWheelSpeed Name of class Attribute Operation UML class notation

42. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 42 Example class diagram

43. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 43 Class structuring and inheritance - subclasses and superclasses

44. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 44 Structural models Informal UML model - class diagram In UML the has-a relationship is called ‘aggregation’. The diamond symbol is used to denote aggregation. Thus a software designer object is part of a project team object. Describing structures - aggregation

45. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 45 Objects and their collaborations - collaboration diagrams

46. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 46 Setting the scene for UML work. Statecharts are based on the Mealy machine. “Conditions” denote values which may be modelled as being either true or false. Semantics: “IF” event E occurs AND condition G is true at that time THEN: - action A is produced and - the system changes state Describing dynamic behaviour - the statechart (basic notation)

47. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 47 Substates - a form of stepwise refinement in state diagrams. Helps to reduce diagram complexity. Without this we would have a six-state diagram. Refinement and substates

48. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 48 The issue: here we have a pump unit which is made up of separate parts - but on the outside it is seen as a single unit. How do we model both the dynamics of the complete unit (a composite of parts) and those of the individual parts? Two state models are needed, one for the composite and the other for its component parts. Modelling composite units Collaboration and state diagrams for a composite unit The composite unit Pump unit

49. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 49 Here we model the component parts. Observe that these operate concurrently. But taken together they implement the behaviour of the overall (composite) unit. Concurrent states

50. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 50 UML notation for statecharts (1)

51. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 51 UML notation for statecharts (2) s State A (d) States with history Superstate Beta Substate B 2 Substate B 1 H Event X Event Y

52. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 52 Sequence diagram showing object interactions

53. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 53 Message notation

54. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 54 An object is shown as a vertical dashed line (“lifeline”). The lifeline shows when the object exists. For a permanent or “static” object it goes from the top to the bottom of the page. For a “transient” object it starts when the object is created and finishes when (if) the object is destroyed. An object symbol is drawn at the head of the lifeline. Focus of control: when an object is performing an action. This is also called an activation. It is denoted by a tall, thin rectangle. UML Sequence diagrams and focus of control

55. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 55 Both objects can run simultaneously (concurrently). They are assumed to exist for the duration of the program. All communication is via message passing. It can be deduced that the first two messages must be asynchronous ones. The “OpenHatch” message must be a synchronous one. This ‘OpenHatch message depicts the use of a remote procedure call from object 1 to object 2. UML Sequence diagram - concurrent operations

56. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 56 This introduces the “procedural” sequence diagram. Here a focus of control is when “an object is performing an action either directly or through a subordinate procedure”. In sequential programs one, and only one, object can be active at any one time. Thus all calls MUST be synchronous ones. NOTE: Procedure returns do not have to be shown; they can be IMPLICIT. UML Sequence diagram - procedural (sequential) operation

57. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 57 ‘An activity diagram is a variation of a state machine’ (UML definition). ‘It represents the state machine of a procedure itself’ (UML definition). ‘The purpose of this diagram is to focus on flows driven by internal processing’ (UMLspeak writ large). The states represent processing operations. Transitions are triggered by completion of the processing. UML Activity diagram constructs

58. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 58 Example activity diagrams

59. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 59 UML component diagram

60. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 60 Part 4 Extensions, variations and project-specific diagrams Non-standard diagrams

61. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 61 System configuration diagram

62. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 62 System architecture diagram

63. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 63 System scope diagram

64. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 64 Node architecture diagram

65. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 65 Processor architecture diagram

66. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 66 Tasking diagram Alarm Monitoring Task (AMT) Compressor Controller Task (CCT) Display and Communications Task (DCT) Timer Task (TT) flag mailbox channel flag channel flag inhibit LCFR inhibit HOGP inhibit LIGP 30s elapsed 40s elapsed stop start 180s elapsed Real-world Trips Real-world Devices Networks

67. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 67 Memory map diagram

68. SOFTWARE ENGINEERING for REAL-TIME SYSTEMS (© J.E.Cooling 2003) Diagramming and design notations - slide 68 Review of ‘Diagramming and design notation’