Illustrating CPU Pipeline with UML Sequence Diagrams

UML: Sequence Diagram Tutorial

The data is included as the parameters within the messages. For example the instance buyersBank of the Bank class takes an accountNumber and returns the balance for the buyersBank instance.

Update:

I have highlighed the key points from the OMG specification. pg 491-494

• Asynchronous Messages have an open arrow head.
• (Default) Synchronous Messages typically represent operation calls and are shown with a filled arrow head -The reply message from a method has a dashed line.
• Object creation Message has a dashed line with an open arrow.
• Lost Messages are described as a small black circle at the arrow end of the Message.
• Found Messages are described as a small black circle at the starting end of the Message.

<messageident> ::= 
([<attribute> ‘=’] <signal-or-operation-name>
[‘(‘ [<argument>[‘,’<argument>]* ‘)’]
[‘:’ <return-value>]) | ‘*’

Examples of syntax:

mymessage(14, - , 3.14, “hello”)  // second argument is undefined
v=mymsg(16, variab):96 // this is a reply message carrying the return value 96 assigning it to v
mymsg(myint=16)  // the input parameter ‘myint’ is given the argument value 16

Where:

v = attribute
mymessage = signal-or-operation-name
(16,vairab) = arguments
:96 = return value

Note:

Visual Studio 2010 Ultimate will auto-generate sequence diagrams. You can reverse engineer existing methods by right-clicking and selecting auto-generate sequence diagram.

DevCurry

Keep in mind that you are just drawing diagrams. This is not coding in some graphic language. If you use the timer-mechanism in all your communication with the device, just model it once (a suggestion for this can be found at the end of this answer). Leave out the timer in most diagrams. You should model at a specific level of abstraction. Don't leave this level or your diagram will get bloated and readers will miss the point you're trying to make. State clearly what case you are modelling. If communication failure does not matter to the situation, don't model it. If you want to explain behavior after a communication failure, don't model the error free case. If you want to model both, consider using multiple diagrams. And again, state clearly what case you are modelling.

For the actual timer I don't see much of a problem. I suggest you create one lifeline for your timer, one for the device and one for whoever talks to the device (let's call it controller) and the timer. Draw a message "reset" from the controller to the device followed by a message "countdown" from the controller to the timer. If you want to model the case of the answer received, draw a message "reset finished" from the device to the controller. Now the controller tells the timer to stop. In the no response case you can draw a message "time up" from the timer to the controller. You can combine both of these with an alt fragment and guards like "device not connected".