Released 9/22/2022
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"
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.
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.
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
SAVE THE SOURCE for your SDs. You might need to edit them for the group project next week.
High Level Design Supplemental Reading:
Supplemental Reading on System Architecture:
Revisions: