Released 9/22/2022

Group Exercise #12: Sequence Diagrams

Educational objective: hands-on experience with sequence diagrams to prepare you for the project.

*** Caution: some othe faculty have recently started teaching a sequence diagram technique in which: (1) everything is a transaction, and (2) the point is to put code in the SD and synthesize software directly from there. While that might be useful for transaction processing, it is NOT the way we are using them to build embedded systems. Our SDs are going to be different. Please realize that there is more than one way to use these diagrams, and do not try to force fit diagrams in this course to match that transactional style. If you want to understand why we teach this way, see this research paper which explains why: Latronico, E. & Koopman, P., "Representing Embedded System Sequence Diagrams As A Formal Language," UML 2001, Toronto Ontario, 3-5 Oct. 2001, pp. 302-316. ***

Consider the digital alarm clock in the REQUIREMENTS group project. Also consider that the internal values, the outputs and the switches (inputs) are all objects that can receive data from other objects, send data to other objects, and/or store data. Objects can also perform computations. Remember that you cannot read actuator values. (You can store them internally if you need to remember them, but you have to explicitly do that; you can't simply read an LED on/off state from the LED itself.)

Remember that a sequence diagram needs to have a separate timeline for each object. For this exercise every output and input shall be an object. For internal memory values you can have a single controller object that manages all the values (TIME, ATIME, STATE), or you can make each internal memory value its own object -- your choice. We recommend you also include a user/person as an object to press buttons and read the display.

12-1. In general you'll all have different requirements from the previous week's group project. Take a look at what you have and agree on ONE set of requirements to use for this group exercise. You can just pick one of the sets, or you can make your own by combining -- or whatever makes sense. You might need to update these as you perform the next step. Don't spend a huge amount of time on picking one, since most of them will probably have a problem that you don't see until the next step.

12-2. Create sequence diagrams for the alarm clock: ONE sequence diagram per use case. Each sequence diagram should show all the objects involved in a particular operation. It will show one possible way that an operation can be performed, but not necessarily ALL possible ways. As an example, if you can set alarm time by pressing the button multiple times or holding down the button, it is likely that there are (at least) two sequence diagrams for setting time: one that shows a single quick press of the button, and one that shows what happens if the button is held down. (You would not need a sequence diagram for repeated button presses, because that is really just multiple invocations of the single-button sequence diagram invoked by the user.) There must be at least one sequence diagram for each use case except "housekeeping"

• Number and label the SD so it is clear what use case and scenario are represented. For example: "SD-4.1. Show Alarm State when SW-1 is pressed."
• Show all involved objects at top of sequence diagram with a descending vertical line under each object as you saw in the examples. Don't show objects that are uninvolved in the SD.
• Include arcs between objects with time going from top to bottom as you say in the examples. Label each arc to show what information is being passed, even if it is just "pressed/released" for a button
• The SD correctly shows all arcs involved to accomplish the defined operation. Inclusion of precondition, post-condition, and computation bubbles is encouraged but not required.

We suggest you first create one SD per use case so if you get stuck you have time to ask for questions. Then move on to the next question.

Hint: a straightforward way to determine what should be an "object" is each sensor, actuator, and internal memory value can be an object. Alternately, there might be a single "controller" object that sets the memory values as side effects, with inputs and outputs still individual objects.

Style requirements:

• Do NOT use "return" arcs in the sequence diagram. Some of you might have seen a particular style of using SDs that requires every arc to paired with a "return" arc. DO NOT DO THIS! That style is commonly used for enterprise/transaction type computing explanations (and often has procedure calls on the arcs). It also skips the statechart part of the design process, because it amounts to turning the sequence diagram into a multi-object flowchart. While that can be a valid use for transaction systems, it is NOT the design process we are going to follow. Similarly, do not use "optional" or "alternate" boxes in your SD. That leads to SDs that are too complex, and defeats the method we are using that will end with statecharts (again, those SDs have their place, but they lead off the path we are trying to follow in this course). There is no one single "right" way to use SDs in the real world, but there are many ways that lead away from the path we'd like you to follow for the learning exercises in this course.
• Use of "alt" is strictly forbidden in SDs, along with "if/else" and other similar logical alternative structures for SD notations. Multiple SDs should be submitted instead showing each alternative as a separate SD.
• Use of "loop" is strictly forbidden in SDs. Smaller SDs that can be executed multiple times should be used with no explicit "loop"/"while"/etc. structure

12-3. Add additional sequence diagrams to ensure you have a complete set. It is possible you'll want to completely re-do some of the SDs from the previous step, and that's OK. Some use cases might need only one SD, but some might need more.

RUBRIC

• Final version of high level requirements after any updates to match the SDs. (OK to base on previous-week solution provided by one of the students in the group.)
• Final version of SDs that cover all the use cases.
• Traceability table of SDs to Use Cases (rows: SD; columns: Use Case)
• Conform to the style requirements above regarding not using "return" arcs, no use of "alt" and no use of "loop"
• Remember to turn this in using landscape slide pages with legible font as in previous assignments.

SAVE THE SOURCE for your SDs. You might need to edit them for the group project next week.

High Level Design Supplemental Reading:

• Archived 18-649 lectures on UML-based design process and end-to-end design example.
• Some students find this sequence diagram tool useful: https://sequencediagram.org/#

Supplemental Reading on System Architecture:

• Latronico, E. & Koopman, P., "Representing Embedded System Sequence Diagrams As A Formal Language," UML 2001, Toronto Ontario, 3-5 Oct. 2001, pp. 302-316.
• Rechtin, Systems Architecting: Creating & Building Complex Systems 1st Edition. ISBN-10: 0138803455
  Don't get the later editions -- get the first edition (used). Single best book on system architecting I've read.
• Cole, Functional Analysis: a system conceptual design tool, IEEE Trans. Aerospace and Electronic Systems, April 1998. https://doi.org/10.1109/7.670319
• Koopman, P., "A taxonomy of decomposition strategies based on structures, behaviors, and goals", 1995 Conference on Design Theory and Methodology, Boston, September 1995.
  Describes the different types of architectural layers of abstractions.
• System Engineering Fundamentals, US Defense Aquisition University. A detailed look at how military system engineering happens.
• A newer system architecture book by Ed Crawley. http://www.system-architect.org
  I haven't had time to read this one, but given the lead author and the description it ought to be worth a look after you've looked at previous material.
• Herb Simon, The Sciences of the Artificial. https://mitpress.mit.edu/books/sciences-artificial
  Especially the part about bounded rationality, but really the whole book is worth looking at if you work with computer systems.
• INCOSE https://www.incose.org, and in particular their system engineering body of knowledge
• Garlan, D. & M. Shaw, An introduction to software architecture, Carnegie Mellon University Technical Report, CMU-CS-94-166, January 1994. (local)
  This is a seminal paper on the area. Read it for high-level understanding through Chapter 3; after that is more about the details that have evolved since then.
• “Design Patterns: Elements of Reusable Object-Oriented Software”, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley, 1995.
  An early comprehensive book on design patterns. Summary here: https://en.wikipedia.org/wiki/Design_Patterns

Revisions:

• 9/22/2022: fixed broken link to requirements project