How to communicate Architecture – Technical Architecture Modeling at SAP (part 3)
This blog post continues the previous posts from bernhard.groene in part1 and part2, which were giving an overview and an introduction to TAM block diagrams. The intent of this article is to present details about how to describe behavior using TAM.
The description of behavior can also be called the “Dynamic Structure” of a system. The focus can be on describing the behavior of a single agent or the interplay among multiple agents. TAM provides three UML diagram types to describe behavior which can be used depending on the purpose of the diagram; each type will be presented in this document:
Activity Diagrams:
Activity Diagrams show the logical sequence of actions (and events) which can be observed in a system, including alternatives and parallel branches. The example below contains most elements of an activity diagram (element names are in blue).
All activity diagrams must have one or more “Start of Activity” and one or more “End of Activity”. The most important element is the action which describes what happens in one step. The name of an action should be short but descriptive enough to get an idea what happens.
Arrows connect the elements, indicating the logical (causal) sequence. There may be multiple branches. In most cases alternative branches are used that are started at a decision diamond and end in a merge diamond. This also allows modeling loops. Please note that a decision always requires a condition to decide which branch to take.
Sometimes you have to show parallel branches where actions are performed concurrently. In this case the branches are started with a fork bar and synchronized with a join bar.
Swim lanes of Agent are useful in the case multiple agents are involved and you want to show who performs which action and which decision.
An important point is the symmetry rule:
Each action should only have one single input and one single output.
Branches opened by a diamond (decision) should also be closed by a diamond (merge), same is true for fork and join bars. The exception to these rules is the “End of flow” or “End of Activity”.
Sequence Diagrams
Sequence Diagrams show the sequence of communication steps between agents over time. They are used to show typical examples of sequences, since the time dimension limits this diagram type to instance level – you cannot show alternatives, loops or parallel processing without disrupting the time dimension. In addition, the diagram type focuses on communication among agents, therefore it does not fit to describe the behavior of a single agent.
As you see in the example above, the time dimension is in the y-axis. The message passing can be seen among the agents and it is possible to differentiate between asynchronous and synchronous messages. It can also be noted when an agent is active or waiting for an action or input (no focus of control).
Sequence diagrams provide a very compact notation, compared to an activity diagram.
State Diagrams
The state diagram is used to describe behavior which can be seen as a transition of states. This can be useful to depict the states and the transitions for a document or object inside a system. You can also show UI navigation using state diagrams.
As you see in the example above, state diagrams use similar elements like activity diagrams.
Similar to an activity diagram, there is a start and an end symbol. In a state diagram, only one start symbol is allowed.
At first glance, the state element looks similar to the action, but the name inside is different: It indicates a state using an adjective, not an action or processing step.
The arrows are important elements and must be labeled, at least with the event name. They show the transition from one state to the next; this transition has to be triggered by an event; in addition, a guard condition has to be fulfilled, if defined. Then the transition happens and an additional action is performed, if defined.
Finally there is the choice element; it can be used in case one event can lead to different states, depending on the guard condition.
Wrap up
Dynamic behavior of a system or software can be described using TAM using one of the 3 diagrams described before: activity, sequence and state diagrams.
The activity diagram provides are general-purpose way to describe behavior, either of a single agent or of the interplay between multiple agents.
Sequence diagrams can show typical examples how multiple agents communicate over time.
State diagrams can be used to describe possible states and what triggers state changes (transitions).
What’s next?
In the next post I will describe Entity-Relationship models using TAM Class Diagrams.
- SAP Managed Tags:
2 Comments
