1. - 0 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Message sequence charts (MSC) Graphical means for representing schedules; time used vertically, geographical distribution horizontally. No distinction between accidental overlap and synchronization

2. - 1 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Time/distance diagrams as a special case © www.opentrack.ch

3. - 2 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Example 1: establishing an (old-fashioned) modem connection According to Stallings

4. - 3 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Example 2: setting up a TCP connection © Eventhelix.com

5. - 4 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund PROs: Appropriate for visualizing schedules, Proven method for representing schedules in transportation. Standard defined: ITU-TS Recommendation Z.120: Message Sequence Chart (MSC), ITU-TS, Geneva, 1996. Semantics also defined: ITU-TS Recommendation Z.120: Message Sequence Chart (MSC)—Annex B: Algebraic Semantics of Message Sequence Charts, ITU-TS, Geneva. CONS: describes just one case, no timing tolerances: "What does an MSC specification mean: does it describe all behaviors of a system, or does it describe a set of sample behaviors of a system?” * * H. Ben-Abdallah and S. Leue, “Timing constraints in message sequence chart specifications,” in Proc. 10th International Conference on Formal Description Techniques FORTE/PSTV’97, Chapman and Hall, 1997. PROs: Appropriate for visualizing schedules, Proven method for representing schedules in transportation. Standard defined: ITU-TS Recommendation Z.120: Message Sequence Chart (MSC), ITU-TS, Geneva, 1996. Semantics also defined: ITU-TS Recommendation Z.120: Message Sequence Chart (MSC)—Annex B: Algebraic Semantics of Message Sequence Charts, ITU-TS, Geneva. CONS: describes just one case, no timing tolerances: "What does an MSC specification mean: does it describe all behaviors of a system, or does it describe a set of sample behaviors of a system?” * * H. Ben-Abdallah and S. Leue, “Timing constraints in message sequence chart specifications,” in Proc. 10th International Conference on Formal Description Techniques FORTE/PSTV’97, Chapman and Hall, 1997. Message sequence charts

6. - 5 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Life Sequence Charts * (LSCs) * W. Damm, D. Harel: LSCs: Breathing Life into Message Sequence Charts, Formal Methods in System Design, 19, 45–80, 2001 Key problems observed with standard MSCs: During the design process, MSC are initially interpreted as “what could happen” (existential interpretation, still allowing other behaviors). Later, they are frequently assumed to describe “what must happen” (referring to what happens in the implementation). Key problems observed with standard MSCs: During the design process, MSC are initially interpreted as “what could happen” (existential interpretation, still allowing other behaviors). Later, they are frequently assumed to describe “what must happen” (referring to what happens in the implementation). More in-depth:

7. - 6 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Extensions for LSCs (1) Extension 1: Introduction of pre- charts: Pre-charts describe conditions that must hold for the main chart to apply. Extension 1: Introduction of pre- charts: Pre-charts describe conditions that must hold for the main chart to apply. Pre-chart Example:

8. - 7 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Extensions (2) Extension 2: Mandatory vs. provisional behavior LevelMandatory (solid lines)Provisional (dashed lines) Chart All runs of the system satisfy the chart At least one run of the system satisfies the chart LocationInstance must move beyond location/time Instance run need not move beyond loc/time MessageIf message is sent, it will be received Receipt of message is not guaranteed ConditionCondition must be met; otherwise abort If condition is not met, exit subchart

9. - 8 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Provisional charts: Behavior may be this one: Dashed charts

10. - 9 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund … or this one: ≠ Message does not need to arrive

11. - 10 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Extensions on other levels “run” does not need to continue Don’t enter main chart, if condition is not met.

12. - 11 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Exploiting distinction in tools Mandatory behavior can be used to generate StateCharts models from LSC models.  LSCs enable link between “timing” spec and FSMs (no real link possible with standard MSCs). Mandatory behavior can be used to generate StateCharts models from LSC models.  LSCs enable link between “timing” spec and FSMs (no real link possible with standard MSCs). Provisional behavior can be checked against mandatory. Error messages can be generated of the two are not consistent. Provisional behavior can be checked against mandatory. Error messages can be generated of the two are not consistent. ring DTR RS 232 interface Ring is input to FSM, FSM outputs DTR, transitions into new state No precise timing! End of addi- tional material

13. - 12 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Use in UML Heavy usage of MSCs in UML (known as sequence diagram); No precise timing. Many kinds of additional elements Heavy usage of MSCs in UML (known as sequence diagram); No precise timing. Many kinds of additional elements from: http://www.gentleware.com/products/documentation/PoseidonUsersGuide/x1462.html

14. - 13 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund UML (Unified modeling language) - designing with a sequence of refinements - From: www.sdmagazine.com/documents/s=815/sdm0012c/

15. - 14 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund State machine diagrams (UML 2.x) State diagrams (UML 1.x) State machine diagrams/State diagrams: UML includes variant of StateCharts © Scott Ambler, Agile Modeling, //www.agilemodeling.com, 2003

16. - 15 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Activity diagram © Cris Kobryn: UML 2001: A Standardization Odyssey, CACM, October, 1999 Extended Petri nets. Include decisions (like in flow charts). Graphical notation similar to SDL. „swimlane“

17. - 16 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Deployment diagram Describe execution architecture of systems (HW or SW). Important for embedded systems. Example including some details: © Scott Ambler, Agile Modeling, //www. agilemodeling. com, 2003

18. - 17 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Deployment diagram - More concise example - © Scott Ambler, Agile Modeling, //www. agilemodeling. com, 2003

19. - 18 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Use case diagram Captures typical application scenarios //sds.hss.cmu.edu/courses/Syllabi/ids/271/ umlfaq.asp#ucdefinition © Scott Ambler, Agile Modeling, //www.agilemodeling.com, 2003

20. - 19 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Package diagram Represents the partitioning into packages. Introduces hierarchy. Example: Use case package diagram. © Scott Ambler, Agile Modeling, //www.agilemodeling.com, 2003

21. - 20 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Class diagrams Describe object classes. Example: © Scott Ambler, Agile Modeling, //www.agilemodeling.com, 2003

22. - 21 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Timing diagrams Can be used to show the change of the state of an object over time. © Scott Ambler, Agile Modeling, //www.agilemodel ing.com, 2003

23. - 22 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Component diagram © Scott Ambler, Agile Modeling, //www.agilemodeling.com, 2003.. model the business software architecture, the technical software architecture, …. Physical architecture issues, in particular hardware issues, are better addressed via UML deployment diagrams.. Represent components used in applications:

24. - 23 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Additional diagrams Communication diagram (called collaboration diagram in UML 1.x) Object diagrams Interaction overview diagrams Composite structure diagrams Communication diagram (called collaboration diagram in UML 1.x) Object diagrams Interaction overview diagrams Composite structure diagrams Less frequently used

25. - 24 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Evaluation Precise specification of semantics? Typically combined with SDL or C++

26. - 25 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund UML for real-time? Initially not designed for real-time. Lacking features (1998): Partitioning of software into tasks and processes specifying timing specification of hardware components Projects on defining real-time UML based on previous work ROOM [Selic] is an object-oriented methodology for real- time systems developed originally at Bell-Northern Research. „UML profile for schedulability, performance and time“ http://www.rational.com/uml/resources/documentation … Initially not designed for real-time. Lacking features (1998): Partitioning of software into tasks and processes specifying timing specification of hardware components Projects on defining real-time UML based on previous work ROOM [Selic] is an object-oriented methodology for real- time systems developed originally at Bell-Northern Research. „UML profile for schedulability, performance and time“ http://www.rational.com/uml/resources/documentation …

27. - 26 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Process networks Many applications can be specified in the form of a set of communicating processes. Example: system with two sensors: mux temperature sensor humidity sensor FIFO Alternating read loop read_temp; read_humi until false; of the two sensors no the right approach.

28. - 27 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund The case for multi-process modeling in imperative languages MODULE main; TYPE some_channel = (temperature, humidity); some_sample : RECORD value : integer; line : some_channel END; PROCESS get_temperature; VAR sample : some_sample; BEGIN LOOP sample.value := new_temperature; IF sample.value > 30 THEN.... sample.line := temperature; to_fifo(sample); END END get_temperature; PROCESS get_humidity; VAR sample : some_sample; BEGIN LOOP sample.value := new_humidity; sample.line := humidity; to_fifo(sample); END END get_humidity; BEGIN get_temperature; get_humidity; END; Blocking calls new_temperature, new_humidity Structure clearer than alternating checks for new values in a single process How to model dependencies between tasks/processes?

29. - 28 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Dependences between processes/tasks Get_tem- perature Get_ humidity FIFO  General discussion of process networks main

30. - 29 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Task graphs Def.: A dependence graph is a directed graph G=(V,E) in which E  V  V is a partial order. If (v1, v2)  E, then v1 is called an immediate predecessor of v2 and v2 is called an immediate successor of v1. Suppose E* is the transitive closure of E. If (v1, v2)  E*, then v1 is called a predecessor of v2 and v2 is called a successor of v1. Def.: A dependence graph is a directed graph G=(V,E) in which E  V  V is a partial order. If (v1, v2)  E, then v1 is called an immediate predecessor of v2 and v2 is called an immediate successor of v1. Suppose E* is the transitive closure of E. If (v1, v2)  E*, then v1 is called a predecessor of v2 and v2 is called a successor of v1. Nodes are assumed to be a „program“ described in some programming language, e.g. C or Java. Sequence constraint

31. - 30 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Task graphs 1. Timing information - Task graphs may contain additional information, for example: Timing information Task graphs may contain additional information, for example: Timing information ] Arrival timedeadline

32. - 31 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Task graphs 2. I/O-information

33. - 32 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Task graphs 3. Shared resources

34. - 33 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Task graphs 4. Periodic schedules.. infinite task graphs

35. - 34 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Task graphs 5. Hierarchical task graphs -

36. - 35 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Multi-thread graphs (IMEC) Def.: A multi-thread graph M is defined as an 11-tuple (O, E, V, D,, , , E lat, E resp,  i,  av ) with: O: set of operation nodes, E: set of control edges, V, D : refer to the access of variables,  : is the set of input/output nodes,  : associates execution latency intervals with all threads, E lat, E resp,  i,  av are timing constraints. Def.: A multi-thread graph M is defined as an 11-tuple (O, E, V, D,, , , E lat, E resp,  i,  av ) with: O: set of operation nodes, E: set of control edges, V, D : refer to the access of variables,  : is the set of input/output nodes,  : associates execution latency intervals with all threads, E lat, E resp,  i,  av are timing constraints. Used in codesign system described in the codesign chapter.

37. - 36 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund MTG graphs: graphical notation

38. - 37 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Multi-thread graph (Example)

39. - 38 -  P. Marwedel, Univ. Dortmund, Informatik 12, 2005/6 Universität Dortmund Summary  Message sequence charts -Original (ITU) version, Time-Distance diagrams -Life sequence charts, Sequence diagram in UML  UML -State machine diagram (StateChart-like) -Activity diagram (extended Petri nets) -Deployment diagram (exec. arch.), Use case diagram -Package diagram (hierarchy), Class diagrams, -Timing diagrams (UML 2.0), UML for real-time?  Process networks -motivation, task graphs, multi thread graph (IMEC)  Message sequence charts -Original (ITU) version, Time-Distance diagrams -Life sequence charts, Sequence diagram in UML  UML -State machine diagram (StateChart-like) -Activity diagram (extended Petri nets) -Deployment diagram (exec. arch.), Use case diagram -Package diagram (hierarchy), Class diagrams, -Timing diagrams (UML 2.0), UML for real-time?  Process networks -motivation, task graphs, multi thread graph (IMEC)