Introduction

to UML
Views and
Diagrams
Part VIII
Introduction to State Chart
Diagram and Deployment
Diagram

[email protected]
Preface
State diagram is also a dynamic UML diagram, and if you recall from the previous papers, Activity
diagram is a variation of State diagram as UML specifications states, so you will not feel stranger though
while learning this diagram.

After understanding State diagram, we will move to a completely different area of UML which is the
Physical area and to be precise, the deployment view. Deployment diagram is an easy to grasp and easy
to learn diagram, since it concerns the implementation of your system in a physical way, so we are going
to learn the basic concepts and aspects of that diagram.
State Diagram
Introduction
You may find that the State diagram referred to it as State Chart diagram or State Machine diagram, but
whatever you call them, State diagrams shows the behavior of your system.

I hear you saying Well Activity diagram does the same isnt it? well Activity diagrams and State
diagrams are related, Activity diagram focuses on the flow of activities involved in a single process
while a State diagram focuses attention on an object undergoing a process (or on a process as an
object).

For example, you can create a State diagram from several use cases. You can use State diagram to show
the behavior of a Class, a Subsystem or a System as a whole.

We have two kinds of State diagrams:

1- Behavioral State diagram: shows specific implementation of elements such as objects.

2- Protocol State Machines: these are not intended to be implemented; instead they describe the
event protocol; that is they show sequences of events of state and transitions without showing
objects actual behavior.

And in this paper we are going to concern only Behavioral State diagram type.

Let us have a closer look to State diagram by looking at the Fig.1:

State_1 State_2

do / activity

Fig.1. State diagram simple example

As you may notice, sequence diagrams dont have a ton of elements. A State is represented as a
rounded rectangle having two compartments, State name, and Activity of the State, the arrow
represents Transitions, and it shows transition from one State to another.

And important thing to note here is that showing the activity and variables of the state are OPTIONAL.

You can label transitions as shown in Fig.2:

State_1 State_2
event [guard]/ effect
do / activity

Fig.2. Transition signature

This label which you see on the Transition is also called Transition Signature and it contains:

- Event: which sometimes referred to it as Trigger or Trigger Event; simply an Event initiates a
change of the State, which causes the object to change from State1 to State2 for example.
- Guard: which also referred to it as Condition and it is similar to the Guard Condition in activity
diagram. You show a guarding condition by inclosing it in square brackets. And a guard is a
Boolean condition which defines whether the condition can proceed or not.
- Effect: also sometimes referred to it as an Action or Activity. Effect is a behavior happens during
a transition (something happens to the objects once it transfers from one state to another).

Note that the labeling of transition is optional, and showing any part of the transition label is optional.
Let us look briefly at a very simple example of a refrigerator light State diagram shown in Fig.3:

OFF ON
open door/ .

close door/ .

Fig.3. Fridge door light State diagram

Noticing the diagram above, the refrigerator light has two States, ON and OFF, and responds to two
Events, open door and close door and from the transition direction we can understand that when you
open the refrigerator door, the light goes on, and when you close the refrigerator door the light goes
off.

So generally in State diagram basically shows the different states that an object reacts to events, and if
you keep that in mind reading and creating State diagram will be whole lot easier for you.

STATE ACTIVITIES
State can have activities, and State is either Active or Inactive; while state is active, and activity can
occur, think of State Activity as a process, some functionality executed by the system that happens while
the object is in a certain state, that means of course that State Activity will not occur if the State is
Inactive, to show an Activity of a state, you apply to the following template (or formula if you would like
to name it like that) label/activity, you write the label and then the Activity Name or Activity Expression
separated by a forward slash.

We have in UML three labels for the State Activities as shown in Fig.4:

State1
entry / action1
do / action2
exit / action3

Fig.4. State Activities

Entry: entry label means that an Activity happens when the object enters the State and it happens
before any other state activities.

Do: do label indicates that the Activity happens as long as the State is Active. Do activities can be
interrupted by some events.

Exit: exit label shows that the Activity happens when the object is leaving the State. The Exit activity will
be executed whether the Do activity finishes, or being interrupted.

These are activity types which you can find in a state. So let us look to a simple example of a fax in a
Receiving state shown in Fig.5:

Recieving
entry / connect
do / print
exit / disconnect

Fig.5. Fax in receiving state

So once the Fax is in the receiving state, Fax has these three activities as shown in Fig.5, its entry activity
will be to connect, and while receiving print the fax letter, until the printing is finished then the Fax is
going to disconnect, or if the printing activity has been interrupted, then the exit activity will happen.
So the state activities are very useful in showing the objects activity while it is in a certain state.

PSEUDO STATES: INITIAL AND FINAL STATES

Pseudo states is a UML concept that let you add information about what happens during transitions in
your State diagram.

I hear you asking What is the difference between a Pseudo State and a State?

A State is a condition or situation of an object in a State Machine,

Pseudo State IS NOT the actual state of an object, instead a Pseudo state shows that something that
happens on the way from one State to another, so Pseudo States happens during the transition.

For example, you may encounter some situations while designing your diagram, like coming to decision
points, or couple States merges into a merging point and transits to another state.

Let us have a look at the Start (or Initial) Pseudo State, which shown in Fig.6:

State1

Fig.6. Start Pseudo State

Initial Pseudo State is represented as a filled circle (like Activity diagram Start Node), and if you think
about it, it is not the state of the machine, really it represents the start of the diagram. Of course you
can label the transition according the template that is mentioned earlier.

A similar concept is the Final Pseudo State which is shown in Fig.7:

State1 State2

Fig.7. Final Pseudo State

Final Pseudo State is similar to the Activity Final Node in Activity Diagram, which of course determines
the end of the State diagram.

PSEUDO STATES: JUNCTION AND CHOICE

Junction Pseudo state is represented by a filled circle exactly like Start Pseudo state, and of course the
difference is that the Start Pseudo state happens at the beginning of the diagram and nothing pointing
into it, and Junction as represented in Fig.8 found in the middle of the diagram, Joining couple transition
into one pseudo state, and will have transitions, both Entering and Exiting that filled in circle.

State1 State2 State3

State4 State5

Fig.8. Using Junction to join transitions (note that in Power Designer is represented as white circle)
Or you can use the junction to split a single transition into couple transitions as shown in Fig.9:
State1

State4 State5

Fig.9. Using Junctions to split transitions (note that in Power Designer is represented as white circle)

On the other hand and Condition Pseudo State is in fact a decision point (exactly like which we have in
Activity diagram) and it is represented as shown in Fig.10:

[[tempreture>7c]/turn circuits on]

Running

Sensing Decision_8

Idle
[[tempreture<=7c]/turn circuits off]

Fig.10. Temperature sensors of refrigerator State diagram

The starting of the State diagram is the sensors are Sensing, if the temperature is higher than 7 degrees,
then start the circuits and begin cooling, else if the temperature is below or equal to 7 degrees, turn off
the circuits and dont start cooling process, and at the end, just return to the Sensing state.

COMPOSITE STATE
All states that weve been working on were simple states, and it doesnt have any sub-states. On the
other hand, Composite state is a state that does contain other states. You can think about composite
state as general state made up of number of more specific states. And these more specific states that
are inside the Composite state, is called Sub-States. By looking to washing machine example while it is
running shown in Fig.11:

Running

Filling

Washing

Spenning

Fig.11. Washing machine in Running State

It is always preferred to have a Starting Pseudo state to show which of the sub-states will start first, then
you show the transitions between the sub-states.

So observing the above diagram, Running state is made up of the Filling, Washing and Spinning sub-
states, and Running state will not end before the other states finishes.

If you are using power designer, then it is going to look like in Fig.12:

Running

Fig.12. Composite state in power designer

Deployment Diagram

Introduction
Deployment diagram offers you a physical view of your system. Deployment diagram:

Maps systems software artifacts to the hardware that will execute them.
Shows a static view of software components and hardware in their runtime configurations.
Models the system logical elements, their physical location, and how they communicate.

In other words, this diagram will show how the software is going to be installed across the system, and
shows the physical relationships between the hardware and software.

Looking to Fig.1 will show you how a Deployment diagram could look like:

Node1

<<Artifact>>
Artifact1 <<device>>
Node2

<<Artifact>>
Artifact2

Fig.1. Simple Deployment diagram

As you may notice from the diagram above, Deployment diagram contains Nodes, Artifacts and
Connection among them. A Node is represented as 3D cube, and it is a Physical Entity that is very often
hardware that can execute Artifacts. An Artifact represented by classifier rectangular box, and it is a
Physical File, such as executable library or source file that a system components use or executes, in
other words, they are pieces of information related to the system software.

In practical world Deployment diagram shows the number and location of Database servers or Web
Servers in your system as well as how these elements are connected in the system, and what physical
devices such workstations the system comprises.

NOTE: In the world of Deployment diagrams system refers to a software you develop AND the
software and hardware that enable you developed software to run.
Well a question pops! When do we use Deployment diagram?

They are very useful throughout the software development stages life cycle, particularly at the end, so
we can summarize it in the following points:

To create a rough sketch of the physical layout of the system early in the development lifecycle.
To discover issues involved in the deployment process of your system.
To revise and refine at later stages.
To identify and explore the dependency between this system and other systems in its
environment.
To visualize the physical topology of your systems deployment.

Let us talk about practical stuff, shall we?

NODES
Deployment diagram is very simple diagram, you dont need to learn a lot of notations there, there is
just Nodes, and Artifacts.

A Node: is a physical resource of some kind that can host software, and it is represented as shown in
Fig.2:

Node

Fig.2. Node in Deployment diagram

As you may notice, it is very simple 3D cube with the node name written inside it. There are two types of
nodes that you can specify in Deployment diagram: Devices and Execution Environments.

The device stereotype shows that the node is hardware of some kind, so if you see device above the
node name as shown in Fig.3 then you know that it is hardware:

<<device>>
Node

Fig.3. Device node

Very often you dont need to use <<device>> stereotype to represent a hardware, it is very often it is
very obvious that the node is hardware from the node name, so if you called your node as DBServer,
then of course it is a hardware.

Execution Environment refers to software. Software can be a Node if it contain or hosts other software,
as shown Fig.4:

<<ExecutionEnvironment>>
OperatingSystem
Of course you may notice the <<ExecutionEnvironment>> stereotype, and the software could be an
Operating system.

ARTIFACTS
NOTE: Unfortunately in power designer, I couldnt find an Artifact symbol so I used the Component Interface symbol and
stereotyped it as an Artifact, usually the artifact has a File icon in located in the upper right corner instead of the Component
Interface Icon.

In deployment diagram, nodes host artifacts. Artifacts represent the physical file that your system
deploys. To represent an artifact, you use a rectangular box with the <<artifact>> stereotype and the
artifact name on it as shown in Fig.5:

<<artifact>>
Artifact

Fig.5. Artifact in Deployment diagram.

Artifacts can be jar files, dll file, html files, exe files; they can be documents, scripts, binary files, etc
whatever your system deploys. So you may have an artifact named run.exe which contains code for
running the application for example.

In order to show the relationship between the Node and the Artifacts, we have three ways to do that.
First way of showing the relationship between the Node and Artifact is put the Artifact inside the node
as shown in Fig.6:

Node1

<<Artifact>>
Artifact1

<<Artifact>>
Artifact2

Fig.6. Relationships between the artifact and the node

Another way to show this is to use dependency to connect artifacts with the node as shown in Fig.7:

<<Artifact>>
Artifact1

Node1

<<Artifact>>
Artifact2

Fig.7. Using dependency to show the relationship between node and artifact

The other way of representing this relationship is simply to fill in the Artifacts name without using the
Artifact classifiers, and at the end it will give us very compact results.
You have to choose between those three representations of the relationships between the node and the
artifact. And your choice will be defined based on your Deployment diagram complexity, so if your
diagram contains lots and lots of artifacts, then you should use the third way of displaying the
relationships just by list the artifact names in the node.

COMMUNICATION PATHS
In all previous deployment diagrams, we used only one Node, if your system has on Node, then you
dont need to create a deployment diagram for it.

Deployment diagram used to show the communications between these nodes, in order to do that we
use which is called a Communication Paths, also sometimes referred to it as Communication
Association or Connections.

A communication path is a simple association line that connects two nodes stereotyped with
appropriate protocol of communication. Fig.8 shows an example of how it could look like:

<<HTTP>>
Node1 Node2

Fig.8. Communication between nodes using HTTP

So in this example we could say that we have internet and these two nodes communicate with each
other using HTTP.

So looking at a simple and strait forward example of how a Deployment diagram could look like in Fig.9:

Application Server
<<HTTP>> <<RMI>>
Browser Client Web Server
<<ExecutionEnvironment>>
EJB

<<ODBC>>

DBMS

Fig.9. Browser communicate with application server

So the browser client uses HTTP protocol to connect to the web server which uses RMI to connect to the
application server to generate a web page using data from the Database management system using
ODBC.

So communication paths are helpful to show the communication between nodes, and also the
communication protocols that those nodes use to communicate along that path with each other.