System Level Design Languages:Communication Diagram

Communication Diagram

Another category of interaction diagrams is a communication diagram. This diagram is very similar to the sequence diagrams and in the older versions it was referred to as a collaboration diagram. The difference between a communication and an interaction diagram is that in communication diagrams the main focus is on the relationship between objects and not on the sequence of the messages. The other difference between these two kinds of diagrams is that none of the structuring mechanisms in the sequence diagrams (such as combined fragments) can be found in communication diagrams. In UML, a communication diagram is represented by objects and messages.

In a communication diagram, an example of which is shown in Figure 86.11, objects are shown with rectangles. Between two related objects, a line is drawn. Messages are shown with small arrows on each line, and are identified by a number, e.g., 1a.1 in Figure 86.11 is the number for EnterCKT message. A sequence of messages has a numbering sequence that identifies the originating objects, and the complete path of objects receiving and replying to the message. The name of a message follows a colon that comes after its number sequence. An example message is 1a.2.1: CheckInput. This message originates by the actor; it is message 2 for the actor, and message 1 that GUI has issued. The example of Figure 86.11 shows a communication diagram of the SSimBoard system.

Activity Diagram

Up to this point, we have discussed UML diagrams that deal with higher levels of system modeling. In this and the following sections, we will describe diagrams that express more details about designs. An activity diagram is one of the UML diagrams that model a system in more detail than use-case, sequence, deployment, and communication diagrams. It shows the flow of activities and the different

paths that may be passed at run-time in a system. It has a starting point and an end point. This diagram also has the capability to show that two different paths execute concurrently. The elements constructing activity diagrams include activities, actions, initial and end nodes, control flows, object and data flows, decision nodes, concurrency nodes, expansion regions, exception handlers, interruptible activity regions, and partitions. As evident from the elements mentioned, they are suitable for modeling hardware designs.

Figures 86.12–86.20 highlight various concepts used in this diagram. A complete activity diagram is shown in Figure 86.21. An activity is the specification of a sequence of behaviors. In UML, each activity is shown by a rounded rectangle containing the name of the activity. An activity includes several actions, each of which is considered a step in the activity. Figure 86.12 shows an action displayed in UML.

Constraints can be put on an action (Figure 86.13). These constraints can be preconditions describing the conditions that must be true before the flow reaches an action, or postconditions describing conditions that must be true after the flow reaches an action. For example, to write a data in a memory module, the address applied to that memory must be in a valid data segment of that memory. This condition depicted in Figure 86.13 is used as a precondition for the MemoryWrite action.

Activity diagrams start from a special node called the initial node displayed by a filled circle. An end node for an activity diagram (called final node) is shown with a circuit containing a filled circle inside. In addition to the activity final node, each flow can have its own final node. The final node of each flow is shown with a circle with a cross inside. The activity final node shows the end of all flows in an activity diagram.

An activity diagram consists of various control and object flows. The control flow is simply shown with an arrowed line between two actions. An object flow is used in an activity diagram to pass data and objects through actions. Two ways to demonstrate an object flow are demonstrated in Figure 86.14.

Decisions made in an activity diagram cause branching out to different flows. A decision, which is represented by a decision node, generates a different path in an activity diagram. All decisions must be merged in merge nodes. Decision and merge nodes are shown with diamond shaped nodes, illustrated in Figure 86.15.

Although it is possible to have several paths with decision and merge nodes, only one of these paths can have an active flow. For concurrent paths, a fork-join node must be used. A fork node receives a

single flow and produces several concurrent flows. In contrast, a join node waits on several input flows and when it receives all these flows it generates a single output flow. Symbols for fork-join nodes are depicted in Figure 86.16.

An expansion region in an activity diagram is a region in which the activity must be executed more than one time. Multiple times, here, has several meanings. An activity can be executed in iteration mode, parallel mode, or in stream mode. The input and output in an expansion region are shown as three-box groups, representing multiple data sets. Figure 86.17 shows an expansion region in iterative mode.

A facility of activity diagrams that makes them useful for hardware design is the ability to express exception handling and interruptible activity regions, an example of which is shown in Figure 86.18. Special actions are defined as exception handlers in an activity diagram (e.g., ResetBoard). If at any time a specified exception occurs (e.g., AddressOutOfBoundary) in a specified action (e.g., WriteMem), a specified handler will be executed.

Having an interruptible activity region is another facility of activity diagrams. If at any point of a flow in this region, a condition becomes true (an interrupt occurs), then the current flow will be broken and another predefined flow begins. The flow that has become active is usually outside the interruptible region. Figure 86.19 shows that while in the ReceiveData–ProcessData flow, if ResetSignal condition becomes true, the ResetAction is taken.

In some cases, different activities are done in different places or by different people in a system. In this situation, if an activity diagram is partitioned, its flow becomes clearer. An example of SSimBoard partition diagram is depicted in Figure 86.20.

An activity diagram for our SSimBoard example system is shown in Figure 86.21. This diagram illustrates various structures of activity diagrams discussed in this section.