State Diagrams

In next lessons you'll work with elements that you haven't worked before. That would
be behavioral elements, that show how parts of a UML model change over time. As the
system interacts with users and possibly with other systems, the objects that make up the
system go through necessary changes to acommodate the interactions. If you're going to
model systems, you must have a mechanism to model change. That mechanism in UML is
State diagrams.
- When you pull a switch, a light changes its state from off to on.
- When you make keystroke or mousemovement in screen saver mode on your computer,
your computer leaves screen saver mode and returns to working - active mode.
The UML State diagram presents the states an object can be in along with the transitions
between the states, and shows the starting point and endpoint of a sequence of state
changes.
A state diagram shows the states of a single object.
States in the state diagram are represented with a rounded rectangle, and the symbol for the
transition is a solid arrowhead line. A solid circle stands for starting point of a sequence of
states, and bull's eye represents the endpoint.

The UML symbols in a state diagram. The top area

stands for the state's name, middle area is for state
variables, and the bottom is for activities. Transitions are
represented with solid arrowhead lines, and circles are
for starting and ending state.
Also you can add details to a state icon by dividing it to a three areas. The top area holds the
name of the state (this name you must supply whatever the class is divided or not), the
middle area hold state variables (timers, counters, dates...), and the bottom area hold
activities (entry-what happenes when the system enters the state, exit-what happenes when
the system leaves the state, do-what happenes when the system is in the state).

State Details and Transitions

You can indicate an event that causes a transition to occur (a trigger event) and the
computation (the action) that executes and makes the state change happen.
To add events and actions you write them near the transition line, using a slash to separate a
triggering event from an action.
Sometimes an event causes a transition without an associated action, and
sometimes a transition occurs because a state completes an activity (rather than because of
an event). This type of transition is caled triggerless transition.
Also possible is a guard condition. When it's met, the transition takes place. (For example
screen saving mode is activated when time interval of n idle minutes has passed).

Some of the states may be more complex that is represented with a rounded rectangle. It is
possible to have states inside one state. These states are called substates (sequential and
concurrent).
Sequential substates come in sequences of states which occur one after another.
Concurrent substates must consist of two or more sequential substates which occur at the
same time. This is represented with dotted line between the concurent states.
If you have any problems understanding these concepts please refer to the State
Diagram - Example lesson.
The UML supplies a symbol that shows that a composite state remembers its active substate
when the object transitions out of the composite state. The symbol is
connected by a solid
line to the remembered substate, with an arrowhead that points to the substate.
A message that triggers a transition in the receiving object's state diagram is called a signal.
In the object-oriented world, sending a signal is the same as creating a signal object and
transmitting it to the receiving object. The signal object has properties that are represented
as attributes. Because a signal is an object, it's possible to create inheritance hierarchies of
signals.

State Diagram - Example

Suppose you're designing a toaster. You would build a plenty of UML diagrams, but here
only state diagrams will be of our interest.
- What are the steps of making a toast?
First of all we must turn on the toaster, put in the bread and wait for several minutes to bake
it. The initial state diagram is shown below:

The initial state diagram for making a toast

But this is not the final state diagram. To prevent burning out the bread, heater of the toaster
must produce heat in temperature interval (upper and lower temperature limits). For this
purpose thermometer measures the temperature of heater, and when the upper limit of
temperature is reached then heater must go into idle state. This state resists until heater's
temperature decreases to lower limit, and then working state is again aimed. With this new
state, extended state diagram will be:

The extended state diagram for making a toast

Transition between working and idle state is not presented in details. To do this substates
must be added.

Substates in Working and Idle states

Substates in working and idle states are very similar. both had measure and compare states,
but differentiates in process of temperature comparison. Working state must compare
current temperature with upper temperature limit (if it is reached, working state goes into idle
state), and idle state compares current temperature with lower temperature limit (idle state is
replaced with working state when temperature falls under lower limit).
It's necessary to have state diagrams because they help analysts, designers and
developers understand the behavior of the objects in a system. Developers, in
particular, have to know how objects are supposed to behave because they have to
implement these behaviors in software. It's not enough to implement an object:
Developers have to make that object do something.

Sequence Diagrams
In previous lesson we learned state diagrams, which focus on the states of na object. But it's
necessary to have communication between objects. The UML sequence diagram goes the
next step and shows how objects communicate with one another over time. In this expanded
field of view, you'll include an important dimension: time. The key idea here is that

interactions among objects take place in a specified sequence, and the sequence takes time
to go from beginning to end.
The sequence diagram consists of objects represented in the usual way - as named
rectangles (with the name underlined), messages represented as solid-line arroes,
and time represented as a vertical progression.
Let's take a close look at this parts of sequence diagrams.
Objects
The objects are laid out near the top of the diagram from left to right. They're arranged in any
order that simplifies the diagram. Extending downforward from each object is a dashed line
called the object's lifeline. Along the lifeline is narrow rectangle called an activation. The
activation represents an execution of an operation the object carries out. The length of the
rectangle signifies the activation's duration. This is shown on next picture.

Representing an object in a sequence diagram

Messages
A message that goes from one object to another goes from one object's lifeline to the other
object's lifeline. An object can send a message to itself-that is, from its lifeline back to its own
lifeline. This is called recursion. See recursion example.
Following table lists all of possible messages existing in the UML sequence diagrams, with
their graphical representations:
simple

This is a transfer of control from one object to another.

If an object sends a synchronous message, it waits for an
synchronous
answer to that message before it proceeds with its business.
If an object sends an asynchronous message, it doesn't wait for
asynchronous
an answer before it proceeds.
Time
The diagram represents time in the vertical direction. Time starts at the top and progresses
toward the bottom. A message that's closer to the top occurs earlier in time than a message
that's closer to the bottom.

The essential symbol set of the sequence diagram, with the

symbols working together.

The actor-symbol initiates the sequence, but the stick figure isn't part of the sequence
diagram symbol set.
In a sequence diagram, the objects are laid out from left to right across the
top. Each object' lifeline is a dashed line extending downward from the object. A solid
line with an arrowhead connects one lifeline to another, and represents a message
from one object to another. Time starts at the top an proceeds downward. Although an
actor typically initiates the sequence, the actor symbol isn't part of the sequence
diagram's
symbol set.

Ways

of Creating Sequences

As use case diagram can show either an instance (one scenario) of a use case, or it can be
generic and incorporate all of the use case's scenarios, and sequence diagrams can
beinstance or generic sequence diagrams. Generic sequence diagrams often provide
opportunities to represent if statements and while loops. Enclose each condition for an "if"
statement in square brackets. Do the same for the condition that satisfies a "while" loop, and
prefix the left bracket with an asterisk. See Sequence Diagram - Example.
It's possible in sequence diagrams to create an object. When this occurs, you represent a
created object in the usual way - as a named rectangle.
The difference is that you don't position it at the top of the sequnce diagram as you do with
the other objects. Instead, you position it along the vertical dimension so that its location
corresponds to the time when it's created. The message that creates the object is
labeled Create().
Sometimes an object has an operation that invokes itself. This is
called recursion.
Suppose one of the objects in your system is a calculator, and suppose one of its operations
computes interest. In order to compute compound interest for a timeframe that
encompasses several compouding periods, the object's interest-computation operation has
to invoke itself a number of times. Sequence diagram for this is following:

Representing recursion in a sequence diagram

Sequence Diagram - Example

In this example, a sequence diagram for one of the privious examples - Self-service machine
will be given. See Use Case Diagram - Example.
Let's assume that in the self-service machine, three objects do the work we're concerned
with:
the front
the money register

the interface the self-service machine presents to the customer

part of the machine where moneys are collected

the dispenser

which delivers the selected product to the customer

The instance sequence diagram may be sketched by using this sequences:

1
2
3
4
5
6

The customer inserts money in the money slot

The customer makes a selection
The money travels to the register
The register checks to see whether the selected product is in the dispenser
The register updates its cash reserve
The register has a dispenser deliver the product to the front of the machine

The "Buy a product" scenario. Because

this is the best-case scenario, it's an
instance sequence diagram
But, when use case diagrams were developed, two additional scenarios were introduced to
represent out-of-product case and incorrect-amount-of-money case. If you consider all of a
use case's scenarios when you draw a sequence diagram, you create a generic sequence
diagram.
The out-of-product scenario will produce this sequences:
1
2
3
4
5

After selecting a sold-out brand, the "SOLD OUT" message flashes

Prompt for another selection must be displayed
The customer has the option of pushing a button that returns money
If the customer selects an in-stock brand, everything proceeds as in the best-case
scenario if the input amount is correct. If not, the machine follows the incorrectamount-of-money scenario
If the customer selects another sold-out brand, the process repeats until the
customer selects an in-stock brand or pushes a button that returns his or her money

The "Out of product"

scenario
Make attention on "fork" of control in the message, caused by if conditions. Because each
path goes to the same object, the fork causes a "branch" of control in the receiving object's

lifeline, separating the lifeline into separate paths. At some point in the sequence, the
branches in the message merge, as do the forks in the lifeline.
For the incorrect-amount-of-money scenario, the list of sequences is given in the following
table:
1
2
3
4
5

The register checks customer's input with the price of the product
If the amount is greater then the price, the difference is calculated, and register
checks its cash reserve
If the difference is present in the cash reserve, the register returns the change to the
customer and everything proceeds as before
Otherway, the register returns the input amount and displays a message that prompts
the customer for the correct amount
If the amount is less than the price, the register does nothing and the machine waits
for more money

The "Incorrect amount

of money" scenario

Collaboration Diagrams
Collaboration diagrams like the sequence diagrams, shows how objects interact. It shows
the objects along with the messages that travel from one to another. But, if sequence
diagram does that, why UML need another diagram? Don't they do the same thing?
The sequence diagram and the collaboration diagram are similar. They're semantically
equivalent, that is, the present the same information, and you can turn a sequence to a
collaboration diagram and vice versa. The main distinction between them is that the
sequence diagram is arranged according to time, the collaboration diagram according to
space.
A collaboration diagram is an extension of object diagram. In addition to the
associations among objects, collaboration diagram shows the messages the objects send
each other.
Messages among objects are represented with arrows that points to receiving object, near
the association line between two objects. A label near the arrow shows what the message is.
The message typically tells the receiving object to execute one of its operations. A pair of

parentheses ends the message. Inside the parentheses, you put the parameters the
opearation works on.
Collaboration diagrams can be turned into sequence diagrams and vice versa.
Thus, you have to be able to represent sequence information in a collaboration diagram. To
do this you must know that:
Add a number to the label of a message, with the number corresponding to the
message's order in the sequence. A colon separates the number from the
message.
This is the basis of collaboration diagrams. In addition next two lessons will describe the
process of writing collaboration diagrams.

Writing Collaboration Diagrams

You can show an object's change of state in a collaboration diagram, also you can
show conditions the same way you represent them in sequence diagram.
In the object rectangle, indicate the state of the object. To the diagram, add another
rectangle that stands for the object and indicate the changed state. Connect the two with the
dashed line and label the line with a <<become>> stereotype.
You put the condition inside a pair of square brackets, and the conditionprecedes the
message-label. The important thing is to coordinate the conditions with the
numbering.
To get closer to this concepts please refer to the Collaboration Diagram - Example.
Also you can present object creation.

In object's creation process you add a <<create>> stereotype to the message

that creates the object.
In the collaboration diagram, you can represent multiple objects and returned results.
The representation of multiple objects is a stack of rectangles extending "backward". You
add a bracketed condition preceded by an asterisk to indicate that the message goes to all
objects.
Returned results are written as expression that has a name of the returned value on the left,
followed by :=, followed by the name of the operation, and a list of possible attributes that
operation can accept, to produce the result.The right side of the expression is called
a message-signature.
A proffesor asks a group of
students to hand in an
assignment.

A message can be a request for an

object to perform a calculation and
return a value.
In some interactions, a specific object controls the flow. This active object can send
messages to passive objects and interact with other active objects. Also you might run into
an object sending a message only after several other (possibly nonconsecutive) messages
have been sent. That is, the object must sinchronize its message with a set of other
messages.
The collaboration diagram represents an active object the same way as other, except that its
border is thick and bold.
Sinchronizing messages, are precede with a list of the messages that have to be completed
prior to that message take place. A comma separates one list-item from another, and the list
ends with a slash.
Now when you have all this concepts, you're ready to go to the next lesson
the Collaboration Diagram - Example.

Collaboration Diagram - Example

Self-service machine again will be target for this example. In previos example
(See, Sequence Diagram - Example) the sequence diagram for this system was built. This is
good time to try the ways of converting sequences into collaboration diagrams.
The best-case scenario consists of several steps:
1
2
3

The customer inserts money in the machine and makes selection of one or more
product(s) present in the machine.
When the register gets the money (in this case customer puts the correct amount of
money, and there is allways a product in the selected brand), the selected product is
delivered to the dispenser.
The dispenser delivers the product to the front of the machine, and the customer gets
that product.

But when we examined this machine and its work in detail, new scenarios were introduced:
incorect-amount-of-money and out-of-product scenario. While building the sequence
diagrams, conditions were introduced to display the work of the machine. Here conditions
will be used too.
You put the condition inside a pair of square brackets, and the condition precedes the
message-label. The important thing is to coordinate the conditions with the numbering.
When you're modeling if statement there are two possible conditions. Messages for these
conditions have a same number, and you add a decimal point and another number. This is
called nesting.
In out-of-product scenario, the machine has to display an out of product
message, and prompt the customer for another product or return the money back. If
customer makes another selection this process must be repeated. Also a correct-amount-ofmoney scenario may be introduced. Collaboration diagram for this case is shown on the
picture:

As you can see, from this picture two possible scenarios may happen. Out-ofproduct and Product-in are that two possibilities. If we assume that this happened after
message1:add(input,selection), the number for this messages will be 2, and we add 1 for the
Product-in and 2 for the out-of-product scenarios, after the decimal point.
What happens when the machine doesn't have the correct change? The machine has to
display an out of change message, return the money, and prompt the customer for the
correct change. In effect, the transaction is over. When the machine has the correct change,
it returns the change to the customer and delivers selected product.
Two branches that are produced from nesting process are numbered with 2.1 and 2.2. And
three posibilities in condition-message 3 will be:3.1, 3.2 and 3.3. Collaboration diagram is
shown on the following picture:

Thats all for this example, and for this day. All you have to do now is answering the
questions given in Questions & Answers and Workshop part from this day. Next day will
introduce to you the last three UML diagrams.

Activity Diagrams
If you've ever taken an introductory course in programming, you've probably encountered
the flowchart. The flowchart shows a sequence of steps, processes, decision points and
branches. Novice programmers are encouraged to use flowcharts to conceptualize problems
and derive solutions.
The UML activity diagram is much like the flowcharts of old. It shows steps (called,
appropriately enough, activities) as well as decision points and branches. It's useful for
showing what happens in a business process or an operation. You'll wind it an integral part
of system analysis.
First and foremost, an activity diagram is designed to be a simplified look at what happens
during an operation or a process. It's an extension of the state diagram. The state diagram
shows the states of an object and represents activities as arrows connecting the states. The
activity diagram highlight the activities.
Each activity is represented by a rounded rectangle - narrower and more oval-shaped than
the state icon. The processing within an activity goes to completion and then an automatic
transmission to the next activity occurs. An arrow represents the transition from one activity
to the next. Also an activity diagram has a strating point represented by filled-in circle, and
endpoint represented by a bull's eye.

Transition from one activity to another in the Activity Diagram

In next lesson will be explained ways of creating an activity diagram, rules between
activities, and at the end an example for this diagram will be given to you.

The activity diagram is an extension of the state diagram. State diagrams highlight
states and represent activities as arrows between states. Activity diagrams put the
spotlight on the activities. Each activity is represented as a rounded rectangle, more
oval in appearance than the state icon. The activity diagram uses the same symbols
as the state diagram for the startpoint and the endpoint.

Building an Activity Diagram

In this lesson will be explained ways of representing decisions, concurrent paths, signals and
swimlanes in the activity diagrams.
Decisions
Decision point can be represented in two ways, it's all to you to make decision what way to
use in your activity diagrams.
One way is to show the possible paths coming directly out of an activity. the other is to have
the activity transition to a small diamond and have the possible paths flow out of the
diamond. Either way, you indicate the condition with a bracketed condition statement near
the appropriate path.
Imagine that you have to go to the work. You get your car, put the key in the
ignition, and there are two possible situations: your car will start or it will not start it's engine.
These possible cases will produce two other activities: drive a car, or go by a bus, taxi, bike
or go walking. This scenario is shown on this picture (make attention of two ways showing a
decision):

Activity diagram showing two ways of

decision
Concurrent paths
When you modeling activities, very frequently you'll have a occasion to separate a transition
into two separate paths that run at the same time (concurrently), and the come together.
Split is represented by a solid bold line perpendicular to the transition and show the paths
coming out of the line. To represent the merge, show the paths pointing at another solid bold
line.

Activity diagram representing a transition split into two

paths that run concurrently and then come together
Signals
During a sequence of activities, it's possible to send a signal. When received, the signal
causes an activity to take a place.
The symbol for sending a symbol is a convex pentagon, and the symbol for receiving a
signal is a concave polygon.

Sending and receiving a signal

Swimlanes
The activity diagram adds the dimension of vizualizing roles. To do that, you separate the
diagram into parallel segments called swimlanes. Each swimlane shows the name of a role
at the top, and represents the activities of each role. Transitions can take place from one
swimlane to another.
It's possible to combine the activity diagram with the symbols from other diagrams and thus
produce a hybrid diagram.
Following lesson will give you a written example for an activity diagram.

Activity Diagram - Example

This example will deal with mathematics. Sometimes (when calculating combinations) you'll
need to calculate a factoriel of n - n!.
The formula for this is n!=n*(n-1)*(n-2)*...*2*1.
Let's dive into the problem. From definition of factoriels we have 0!=1 and 1!=1. For the rest
of the numbers we must use the given formula. In computer programming this problem is
written with recursion. Here also when building an activity diagram recursion will be
introduced. You might call the operation computeFact(n). You'll need a counter to keep track
of whether or not the operation has reached the nth factoriel, a variable that keep a track of
your computations, and two more to store the values of 0! and 1!.
The complete activity diagram is shown on next picture:

If you're dealing with computer programming you will conclude that this activity diagram is
very similar with a procedure (function) that computes factoriels.