What is an Activity Diagram?

An activity diagram visually presents a series of actions or flow of control in a system similar
to a flowchart or a data flow diagram. Activity diagrams are often used in business process
modeling. They can also describe the steps in a use case diagram. Activities modeled can be
sequential and concurrent.
Activity Diagrams describe how activities are coordinated to provide a service which can
be at different levels of abstraction. Typically, an event needs to be achieved by some
operations, particularly where the operation is intended to achieve a number of different
things that require coordination, or how the events in a single use case relate to one another,
in particular, use cases where activities may overlap and require coordination. It is also
suitable for modeling how a collection of use cases coordinate to represent business
workflows
1. Identify candidate use cases, through the examination of business workflows
2. Identify pre- and post-conditions (the context) for use cases
3. Model workflows between/within use cases
4. Model complex workflows in operations on objects
5. Model in detail complex activities in a high level activity Diagram
The purpose of an activity diagram can be described as −
 Draw the activity flow of a system.
 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the system.
  captures the dynamic behavior of the system.

 Other four diagrams are used to show the message flow from one object to another
but activity diagram is used to show message flow from one activity to another.
 Activity is a particular operation of the system. Activity diagrams are not only used
for visualizing the dynamic nature of a system, but they are also used to construct the
executable system by using forward and reverse engineering techniques. The only
missing thing in the activity diagram is the message part.
 It does not show any message flow from one activity to another. Activity diagram is
sometimes considered as the flowchart.
Student enrolment number.
Synchronization
A fork node is used to split a single incoming flow into multiple concurrent flows. It is
represented as a straight, slightly thicker line in an activity diagram.
A join node joins multiple concurrent flows back into a single outgoing flow.
A fork and join mode used together are often referred to as synchronization.

Time Event
This refers to an event that stops the flow for a time; an hourglass depicts it.
Merge Event
A merge event brings together multiple flows that are not concurrent.

Sent and Received Signals

Signals represent how activities can be modified from outside the system. They usually
appear in pairs of sent and received signals, because the state can't change until a response is
received, much like synchronous messages in a sequence diagram. For example, an
authorization of payment is needed before an order can be completed.

Interrupting Edge
An event, such as a cancellation, that interrupts the flow denoted with a lightning bolt.

Swimlanes
Swimlanes group related activities into one column.
Activity Diagram - Swimlane
A swim lane diagram, also called a cross functional flow chart, or swim lane process map, is
an element used in mapping process workflows. It groups components into a distinct
sequence, or lane, in the visual presentation of workflow and process charts. Swimlane
diagrams distinguish capabilities, roles, and responsibilities for each sub-process in business
process workflows.
In swim lane maps, parallel lines divide the chart into lanes, hence the name, with one lane
for each person, group or sub process.
For example, a vertical lane may represent a sequence of events, while the horizontal lanes
depict what department, person, or material is involved, with arrows and other standard
symbols to show how the actual process workflow takes place.

BENEFIT

Clarify Complex Processes

Organising processes into swim lanes can provide easy visual explanations even for complex
relationships. 
Swim lane diagrams help identify and organize

 bottlenecks and inefficiencies 

 department and team responsibility 
 redundancies
  the relationship between teams, steps and overall process 

Better Understanding and Communication btween team.

Easy Analysis for Continuous Improvement

As the flowchart progresses, it’s repeatedly checked for issues such as missing steps,
duplication of effort, poor time management and activities that add no real value. Eliminating
any or all of these results in a better process. 
Here is an example of a swinlane activity diagram for modeling Staff Expenses
Submission:

Swinlane and Non-Swinlane Activity Diagram

The activity diagram example below describes the business process for meeting a new
client using an activity Diagram without swinlane.
This figure below describes the business process for meeting a new client using an activity
Diagram with swinlane.
INTERACTION DIAGRAM –
his interactive behavior is represented in UML by two diagrams known as Sequence
diagram and Collaboration diagram. The basic purpose of both the diagrams are similar.
Sequence diagram emphasizes on time sequence of messages and collaboration diagram
emphasizes on the structural organization of the objects that send and receive messages.

• Can be modelled at different level of abstraction

– At high level, Use cases describes how a system interacts with outside actors

– Sequence diagrams provide more detail and show the messages exchanged
among a set of objects over time
Activity diagrams provide details and show the flow of control among the steps of a
computation

Purpose of Interaction Diagrams

The purpose of interaction diagrams is to visualize the interactive behavior of the system.
Visualizing the interaction is a difficult task. Hence, the solution is to use different types of
models to capture the different aspects of the interaction.
Sequence and collaboration diagrams are used to capture the dynamic nature but from a
different angle.
The purpose of interaction diagram is −
 To capture the dynamic behaviour of a system.
 To describe the message flow in the system.
 To describe the structural organization of the objects.
 To describe the interaction among objects.
WHERE TO USE THEM –

equence diagrams are used to capture the order of messages flowing from one object to
another. Collaboration diagrams are used to describe the structural organization of the
objects taking part in the interaction. A single diagram is not sufficient to describe the
dynamic aspect of an entire system, so a set of diagrams are used to capture it as a whole.
Interaction diagrams are used when we want to understand the message flow and the
structural organization. Message flow means the sequence of control flow from one object to
another. Structural organization means the visual organization of the elements in a system.
Interaction diagrams can be used −
 To model the flow of control by time sequence.
 To model the flow of control by structural organizations.
 For forward engineering.
 For reverse engineering.

SEQUENCE DIAGRAM-

Sequence Diagrams captures:

 the interaction that takes place in a collaboration that either realizes a use case or an
operation (instance diagrams or generic diagrams)
 high-level interactions between user of the system and the system, between the
system and other systems, or between subsystems (sometimes known as system
sequence diagrams)
Purpose of Sequence Diagram
 Model high-level interaction between active objects in a system
 Model the interaction between object instances within a collaboration that realizes a
use case
 Model the interaction between objects within a collaboration that realizes an operation
 Either model generic interactions (showing all possible paths through the interaction)
or specific instances of a interaction (showing just one path through the interaction)

Sequence Diagrams at a Glance

Sequence Diagrams show elements as they interact over time and they are organized
according to object (horizontally) and time (vertically):
Object Dimension
 The horizontal axis shows the elements that are involved in the interaction
 Conventionally, the objects involved in the operation are listed from left to right
according to when they take part in the message sequence. However, the elements on
the horizontal axis may appear in any order
Time Dimension
 The vertical axis represents time proceedings (or progressing) down the page.

ADVANTAGE-

 Sequence diagrams are language neutral

 Non-coders can do sequence diagrams
 Easier to do sequence diagrams as a team
 Can be used for testing and/or UX Wireframing

Messages – Communication between objects is depicted using messages. The messages

appear in a sequential order on the lifeline. We represent messages using arrows. Lifelines
and messages form the core of a sequence diagram.
Messages can be broadly classified into the following categories :

Figure – a sequence diagram with different types of messages

 Synchronous messages – A synchronous message waits for a reply before the
interaction can move forward. The sender waits until the receiver has completed the
processing of the message. The caller continues only when it knows that the receiver
has processed the previous message i.e. it receives a reply message. A large number of
calls in object oriented programming are synchronous. We use a solid arrow head to
represent a synchronous message.

Figure – a sequence diagram using a synchronous message

 Asynchronous Messages – An asynchronous message does not wait for a reply from
the receiver. The interaction moves forward irrespective of the receiver processing the
previous message or not. We use a lined arrow head to represent an asynchronous
message.

Uses of sequence diagrams –

 Used to model and visualise the logic behind a sophisticated function, operation or
procedure.
 They are also used to show details of UML use case diagrams.
 Used to understand the detailed functionality of current or future systems.
 Visualise how messages and tasks move between objects or components in a system.
COLLABORATION OR COMMUNICATION DIAGRAM –
Collaboration diagrams (known as Communication Diagram in UML 2.x) are used to show how
objects interact to perform the behavior of a particular use case, or a part of a use case. Along with
sequence diagrams, collaboration are used by designers to define and clarify the roles of the objects
that perform a particular flow of events of a use case.  They are the primary source of information
used to determining class responsibilities and interfaces.

 A Collaboration is a collection of named objects and actors with links connecting

them. They collaborate in performing some task.
 A Collaboration defines a set of participants and relationships that are meaningful
for a given set of purposes
 A Collaboration between objects working together provides emergent desirable
functionalities in Object-Oriented systems
 Each object (responsibility) partially supports emergent functionalities
 Objects are able to produce (usable) high-level functionalities by working together
 Objects collaborate by communicating (passing messages) with one another in order
to work together

Why Collaboration Diagram?

Unlike a sequence diagram, a collaboration diagram shows the relationships among the
objects. Sequence diagrams and collaboration diagrams express similar information, but
show it in different ways.
Because of the format of the collaboration diagram, they tend to better suited for analysis
activities. Specifically, they tend to be better suited to depicting simpler interactions of
smaller numbers of objects.  However, if the number of objects and messages grows, the
diagram becomes increasingly hard to read.  In addition, it is difficult to show additional
descriptive information such as timing, decision points, or other unstructured information
that can be easily added to the notes in a sequence diagram. So, here are some use cases
that we want to create a collaboration diagram for:
 Model collaborations between objects or roles that deliver the functionalities of use
cases and operations
 Model mechanisms within the architectural design of the system
 Capture interactions that show the messages passing between objects and roles
within the collaboration
 Model alternative scenarios within use cases or operations that involve the
collaboration of different objects and interactions
 Support the identification of objects (hence classes) that participate in use cases
 Each message in a collaboration diagram has a sequence number.
 The top-level message is numbered 1. Messages sent during the same call have the
same decimal prefix but suffixes of 1, 2, etc. according to when they occur.
CHAPTER 4

STATES AND EVENTS

In state machines (sequence of states), we use events to model the occurrence of a stimulus
that can trigger an object to move from one state to another state. Events may include signals,
calls, the passage of time or a change in state.

In UML, each thing that happens is modeled as an event. An event is the specification of a
significant occurrence that has a location in time and space. A signal, passing of time and
change in state are asynchronous events. Calls are generally synchronous events, representing
invocation of an operation.
UML allows us to represent events graphically as shown below. Signals may be represented
as stereotyped classes and other events are represented as messages associated with
transitions which cause an object to move from one state to another.

Types of Events
Events may be external or internal. Events passed between the system and its actors are
external events. For example, in an ATM system, pushing a button or inserting a card are
external events. Internal events are those that are passed among objects living inside the
system. For example, a overflow exception generated by an object is an internal event.

In UML, we can model four kinds of events namely: signals, calls, passing of time and
change in state.

Signals

A signal is a named object that is sent asynchronously by one object and then received by
another. Exceptions are the famous examples for signals. A signal may be sent as the action
of a state in a state machine or as a message in an interaction. The execution of an operation
can also send signals.
In UML, we model the relationship between an operation and the events using a dependency
stereotyped with “send”, which indicates that an operation sends a particular signal.

 
Call Events
A call event represents the dispatch of an operation from one object to another. A call event
may trigger a state change in a state machine. A call event, in general, is synchronous.

This means that the sender object must wait until it gets an acknowledgment from the
receiver object which receives the call event. For example, consider the states of a customer
in an ATM application:

Time and Change Events 

A time event represents the passage of time. In UML, we model the time event using the
“after” keyword followed by an expression that evaluates a period of time.
A change event represents an event that represents a change in state or the satisfaction of
some condition. In UML, change event is modeled using the keyword “when” followed by
some Boolean expression.

Sending and Receiving Events

 Any instance of a class can receive a call event or signal. If this is a synchronous call event,
the sender is in locked state with receiver. If this is a signal, then the sender is free to carry its
operations without any concern on the receiver.

In UML, call events are modeled as operations on the class of an object and signals that an
object can receive are stored in an extra component in the class as shown below:
Statechart diagram -

A Statechart diagram describes a state machine. State machine can be defined as a machine
which defines different states of an object and these states are controlled by external or
internal events.
Activity diagram explained in the next chapter, is a special kind of a Statechart diagram. As
Statechart diagram defines the states, it is used to model the lifetime of an object.

Purpose of Statechart Diagrams

Statechart diagram is one of the five UML diagrams used to model the dynamic nature of a
system. They define different states of an object during its lifetime and these states are
changed by events. Statechart diagrams are useful to model the reactive systems. Reactive
systems can be defined as a system that responds to external or internal events.
Statechart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is triggered.
The most important purpose of Statechart diagram is to model lifetime of an object from
creation to termination.
Statechart diagrams are also used for forward and reverse engineering of a system. However,
the main purpose is to model the reactive system.
Following are the main purposes of using Statechart diagrams −
 To model the dynamic aspect of a system.
 To model the life time of a reactive system.
 To describe different states of an object during its life time.
 Define a state machine to model the states of an object.

Statechart diagrams are used to model the states and also the events operating on
the system. When implementing a system, it is very important to clarify different
states of an object during its life time and Statechart diagrams are used for this
purpose. When these states and events are identified, they are used to model it and
these models are used during the implementation of the system.
If we look into the practical implementation of Statechart diagram, then it is mainly
used to analyze the object states influenced by events. This analysis is helpful to
understand the system behavior during its execution.
The main usage can be described as −
 To model the object states of a system.
 To model the reactive system. Reactive system consists of reactive objects.
 To identify the events responsible for state changes.
 Forward and reverse engineering.

There are a total of two types of state machine diagrams:

1. Behavioral state machine

 It captures the behavior of an entity present in the system.

  It is used to represent the specific implementation of an
element.
 The behavior of a system can be modelled using behavioral
state machine diagrams.

2. Protocol state machine

 These diagrams are used to capture the behavior of a

protocol.
 It represents how the state of protocol changes concerning
the event. It also represents corresponding changes in the
system.
 They do not represent the specific implementation of an
element.

Types of State
Unified Modeling Language defines three types of states:

 Simple state
o They do not have any substrate.
 Composite state
o These types of states can have one or more than one
substrate.
o A composite state with two or more substates is called
an orthogonal state.
 Submachine state
o These states are semantically equal to the composite
states.
o Unlike the composite state, we can reuse the
submachine states.

Statemachine FlowChart

It represents various states of a The Flowchart illustrates the progra

system. execution flow.

The state machine has a WAIT The Flowchart does not deal with
concept, i.e., wait for an action or waiting
an event.
 for a concept.

State machines are used for a live Flowchart visualizes branching

running system. sequences

of a system.

The state machine is a modeling A flowchart is a sequence flow or a

diagram. DFD diagram.

The state machine can explore Flowchart deal with paths and contr
various states of a system. flow.

Basic Concepts of State Machine Diagram

What is a State?

Rumbaugh defines that:

"A state is an abstraction of the attribute values and links of an object. Sets of values are
grouped together into a state according to properties that affect the gross behavior of the
object."
State Notation

Characteristics of State Machine Notations

There are several characteristics of states in general, regardless of their types:

 A state occupies an interval of time.
 A state is often associated with an abstraction of attribute values of an entity
satisfying some condition(s).
 An entity changes its state not only as a direct consequence of the current input, but it
is also dependent on some past history of its inputs.

Kinds of Events

• Change event
– Event caused by satisfaction of a Boolean expression
– Intent: Expression continually tested; when changes from
false to true, the event happens
– UML Notation: keyword when followed by
parenthesized boolean expression
• when(room temperature < heating set point)
• when(room temperature > cooling set point)
• when(battery power < lower limit)
• when(tire pressure < minimum pressure
 • Time event
– Event caused by the occurrence of an absolute time or the
elapse of a time interval
– for absolute time the UML Notation: keyword when
followed by parenthesized expression involving time
• when (date = Jan 1, 2013)
– for time interval the UML Notation: keyword after
followed by parenthesized expression that evaluate to a
time duration
• after (n timeUnits)
after(10 seconds)

Symmetry between Events and States

• Events represent points in time
• State represent intervals of time. A state corresponds to the
interval between two events received by an object

state machine
 A state machine is a behavior that specifies the sequences of states an object goes
through during its lifetime in response to events.
 Graphically, a state is rendered as a rectangle with rounded corners. A transition is
rendered as a solid directed line.
 Figure 1 shows State Machines
 state machine are used to specif the behavior of objects that must respond to
asynchronous stimulus or whose current behavior depends on their past.
 state machines are used to model the behavior of entire systems, especially
reactive systems, which must respond to signals from actors outside the system.

Processes and Threads

 A process is a heavyweight flow that can execute concurrently with other
processes.
 A thread is a lightweight flow that can execute concurrently with other threads
within the same process.
 An active object is an object that owns a process or thread and can initiate control
activity.
 An active class is a class whose instances are active objects.
 Graphically, an active class is rendered as a rectangle with thick lines. Processes
and threads are rendered as stereotyped active classes. Figure 1:Active class

Figure 1: Active Class

Flow of Control
In a sequential system, there is a single flow of control. i.e, one thing, and one thing only,
can take place at a time.
In a concurrent system, there is multiple simultaneous flow of control i.e, more than one
thing can take place at a time.
Classes and Events
 Active classes are just classes which represents an independent flow of control
 Active classes share the same properties as all other classes.
 When an active object is created, the associated flow of control is started; when
the active object is destroyed, the associated flow of control is terminated
 two standard stereotypes that apply to active classes are, <<process>> –
Specifies a heavyweight flow that can execute concurrently with other processes.
(heavyweight means, a thing known to the OS itself and runs in an independent address
space) <<thread>> – Specifies a lightweight flow that can execute concurrently with other
threads within the same process (lightweight means, known to the OS itself.)
 All the threads that live in the context of a process are peers of one another
Communication
 In a system with both active and passive objects, there are four possible
combinations of interaction
 First, a message may be passed from one passive object to another
 Second, a message may be passed from one active object to another
 In inter-process  communication there are two possible styles of
communication. First, one active object might synchronously call an operation of
another. Second, one active object might asynchronously send a signal or call an
operation of another object
 a synchronous message is rendered as a full arrow and an asynchronous message
is rendered as a half arrow
 Figure 2: shows Communication
 Third, a message may be passed from an active object to a passive object
 Fourth, a message may be passed from a passive object to an active one
 Figure 2: Communication

Synchronization
 synchronization means arranging the flow of controls of objects so that mutual
exclusion will be guaranteed.
 in object-oriented systems these objects are treated as a critical region
 Figure 3 Synchronization
 three approaches are there to handle synchronization:
 Sequential – Callers must coordinate outside the object so that only one flow is in
the object at a time
 Guarded – multiple flow of control is sequentialized with the help of object’s
guarded operations. in effect it becomes sequential.
 Concurrent – multiple flow of control is guaranteed by treating each operation as
atomic
 synchronization are rendered in the operations of active classes with the help of
constraints

Figure 3: Synchronization

Process Views
 The process view of a system encompasses the threads and processes that form
the system’s concurrency and synchronization mechanisms.
 This view primarily addresses the performance, scalability, and throughput of the
system.
Modeling Multiple Flows of Control
To model multiple flows of control,
 · Identify the opportunities for concurrent action and reify each flow as an active
class. Generalize common sets of active objects into an active class. Be careful not to
overengineer the process view of your system by introducing too much concurrency.
 · Consider a balanced distribution of responsibilities among these active classes,
then examine the other active and passive classes with which each collaborates statically.
Ensure that each active class is both tightly cohesive and loosely coupled relative to these
neighboring classes and that each has the right set of attributes, operations, and signals.
 · Capture these static decisions in class diagrams, explicitly highlighting each
active class.
 · Consider how each group of classes collaborates with one another dynamically.
Capture those decisions in interaction diagrams. Explicitly show active objects as the root
of such flows. Identify each related sequence by identifying it with the name of the active
object.
 · Pay close attention to communication among active objects. Apply synchronous
and asynchronous messaging, as appropriate.
 · Pay close attention to synchronization among these active objects and the
passive objects with which they collaborate. Apply sequential, guarded, or concurrent
operation semantics, as appropriate.
Figure 4 shows part of the process view of a trading system.

Figure 4: Modeling Flows of Control

Modeling Interprocess Communication

To model interprocess communication,
 · Model the multiple flows of control.
 · Consider which of these active objects represent processes and which represent
threads. Distinguish them using the appropriate stereotype.
 · Model messaging using asynchronous communication; model remote procedure
calls using synchronous communication.
 · Informally specify the underlying mechanism for communication by using notes, or
more formally by using collaborations.
Figure 5 shows a distributed reservation system with processes spread across four nodes.
State

A state is a constraint or a situation in the life cycle of an object, in which a constraint holds,
the object executes an activity or waits for an event.
A state machine diagram is a graph consisting of:
 States (simple states or composite states)
 State transitions connecting the states
Example:

Characteristics of State
 State represent the conditions of objects at certain points in time.
 Objects (or Systems) can be viewed as moving from state to state
 A point in the lifecycle of a model element that satisfies some condition, where some
particular action is being performed or where some event is waited

Initial and Final States

 The initial state of a state machine diagram, known as an initial pseudo-state, is
indicated with a solid circle. A transition from this state will show the first real state
 The final state of a state machine diagram is shown as concentric circles. An open
loop state machine represents an object that may terminate before the system
terminates, while a closed loop state machine diagram does not have a final state; if it
is the case, then the object lives until the entire system terminates.
Example:
Events

An event signature is described as Event-name (comma-separated-parameter-list). Events

appear in the internal transition compartment of a state or on a transition between states. An
event may be one of four types:
1. Signal event - corresponding to the arrival of an asynchronous message or signal
2. Call event - corresponding to the arrival of a procedural call to an operation
3. Time event - a time event occurs after a specified time has elapsed
4. Change event - a change event occurs whenever a specified condition is met
Characteristics of Events
 Represents incidents that cause objects to transition from one state to another.
 Internal or External Events trigger some activity that changes the state of the system
and of some of its parts
 Events pass information, which is elaborated by Objects operations. Objects realize
Events
 Design involves examining events in a state machine diagram and considering how
those events will be supported by system objects

Transition

Transition lines depict the movement from one state to another. Each transition line is labeled
with the event that causes the transition.
 Viewing a system as a set of states and transitions between states is very useful for
describing complex behaviors
 Understanding state transitions is part of system analysis and design
 A Transition is the movement from one state to another state
 Transitions between states occur as follows:
1. An element is in a source state
2. An event occurs
3. An action is performed
4. The element enters a target state
 Multiple transitions occur either when different events result in a state terminating or
when there are guard conditions on the transitions
 A transition without an event and action is known as automatic transitions
Actions

Action is an executable atomic computation, which includes operation calls, the creation or
destruction of another object, or the sending of a signal to an object. An action is associated
with transitions and during which an action is not interruptible - e.g., entry, exit

Activity

Activity is associated with states, which is a non-atomic or ongoing computation. Activity

may run to completion or continue indefinitely. An Activity will be terminated by an event
that causes a transition from the state in which the activity is defined
Characteristics of Action and Activities
 States can trigger actions
 States can have a second compartment that contains actions or activities performed
while an entity is in a given state
 An action is an atomic execution and therefore completes without interruption
 Five triggers for actions: On Entry, Do, On Event, On Exit, and Include
 An activity captures complex behavior that may run for a long duration - An activity
may be interrupted by events, in which case it does not complete occur when an
object arrives in a state.
Simple State Machine Diagram Notation

DO ACTIVITIES-

• continue for an extended time

• can occur only within a state & can not be attached to a transition
• include
• continuous operations, such as displaying a picture on a television screen
• Sequential operations that terminate by themselves after an interval of time
• may be performed for all or part of time that an object is in a state
 • may be interrupted by event received during execution; event may or may not cause
state transition
• A robot moving a part may encounter resistance, causing it to cease moving
• ORDER OF ACTIVITIES-
• activities on incoming transition
• entry activities
• do-activities
• exit activities
• activities on outgoing transition
Events that cause transitions out of the state can interrupt do-activities. If a do-activity is
interrupted, the exit activity is still performed

Entry and Exit Actions

Entry and Exit actions specified in the state. It must be true for every entry / exit occurrence.
If not, then you must use actions on the individual transition arcs
 Entry Action executed on entry into state with the notation: Entry / action
 Exit Action executed on exit from state with the notation: Exit / action
Example - Entry / Exit Action (Check Book Status)
This example illustrates a state machine diagram derived from a Class - "BookCopy":

Note:
1. This state machine diagram shows the state of an object myBkCopy from a
BookCopy class
2. Entry action : any action that is marked as linked to the entry action is executed
whenever the given state is entered via a transition
3. Exit action : any action that is marked as linked to the exit action is executed
whenever the state is left via a transition
Substates

A simple state is one which has no substructure. A state which has substates (nested states) is
called a composite state. Substates may be nested to any level. A nested state machine may
have at most one initial state and one final state. Substates are used to simplify complex flat
state machines by showing that some states are only possible within a particular context (the
enclosing state).
Substate Example - Heater

State Machine Diagrams are often used for deriving testing cases, here is a list of possible test
ideas:
 Idle state receives Too Hot event
 Idle state receives Too Cool event
 Cooling/Startup state receives Compressor Running event
 Cooling/Ready state receives Fan Running event
 Cooling/Running state receives OK event
 Cooling/Running state receives Failure event
 Failure state receives Failure Cleared event
 Heating state receives OK event
 Heating state receives Failure event

History States

Unless otherwise specified, when a transition enters a composite state, the action of the
nested state machine starts over again at the initial state (unless the transition targets a
substate directly). History states allow the state machine to re-enter the last substate that
was active prior to leaving the composite state. An example of history state usage is
presented in the figure below.

Concurrent State

As mentioned above, states in state machine diagrams can be nested. Related states can be
grouped together into a single composite state. Nesting states inside others is necessary when
an activity involves concurrent sub-activities. The following state machine diagram models
an auction with two concurrent substates: processing the bid and authorizing the payment
limit.
Concurrent State Machine Diagram Example - Auction Process
In this example, the state machine first entering the Auction requires a fork at the start into
two separate start threads. Each substate has an exit state to mark the end of the thread.
Unless there is an abnormal exit (Canceled or Rejected), the exit from the composite state
occurs when both substates have exited.
ADVANCE STATE DIAGRAM-

NESTED STATE DIAGRAM

• Expanding state

– Organize the model by having high-level diagram with sub diagrams

expanding certain states

– Submachine: a state diagram that may be invoked as part of another state

diagram (lower-level state diagram).

– UML Notation for submachine: list a local name followed by a colon and
the submachine name.

NESTED STATE-

– Nest states to show their commonality and share behavior

– Composite state: state that encloses the nested states.

– Labels in the outer contour

– A nested state receives the outgoing transitions of its composite states

Transitions and Conditions

• Transition: an instantaneous change in state

– triggered by an event

– Transition is said to fire upon the change from source to target state

– Origin and target state of a transition are different states but may be the
same

– e.g., when a phone line is answered, the phone line transitions from the
Ringing state to the Connected state.

• Guard Condition:

– boolean expression that must be true for transition to occur

– checked only once, at the time event occurs; transition fires if true

– E.g., when you go out in the morning (event), if the temperature is below
freezing (condition), then put on your gloves (next state).

SIGNAL GENREALISATION-
• Organize signals into generalization hierarchy with inheritance of signal
attributes

• View every actual signal as a leaf on a generalization tree of signals.

• Received signal triggers transitions that are defined for any ancestor signal type.

– E.g., typing an ‘a’ would trigger a transition on signal Alphanumeric as

well as signal KeyboardCharacter.

• A signal hierarchy permits different levels of abstraction to be used in a model.

– E.g., some state might handle all i/p characters the same; other states
might treat control characters differently from printing characters .
AGGREGATION CURRENCY-

• State Aggregation means collection of state diagrams , one for each part

• “and” relationship

• Aggregate state is one state from first diagram & a state from second diagram &
state from each other diagram.

• Transition for one object depend on another object, allows interaction between
the state diagram.

CONCURENCY WITHIN AN OBJECT-

• Some objects can be partitioned into subsets of attributes or links.

• Each of the partitioned subset has its own subdiagram.

• The state of the object comprises one state from each subdiagram.
• The sub diagrams need not be independent; the same event can cause transitions
in more than one subdiagram

• UML Notation- partition the composite state into regions with dotted lines.

Relation of class model, state model

• A state diagram describes all or part of the behavior of the objects of a given
class.

• States = classes of values & link for an object

• State model of a class is inherited by its subclasses. Subclass inherits both the
state & Transitions.

• It is also possible to refine an inherited state diagram by expanding state into

nested state or concurrent sub diagrams.

• State structure is related to and constrained by class structure.

 • A composite state is the aggregation of more than one concurrent
substate.

• Try to make the state diagrams of subclasses independent of the state

diagrams of their superclasses.

COMPONENT DIAGRAM _

Component diagrams are used to model the physical aspects of a system. Now the
question is, what are these physical aspects? Physical aspects are the elements
such as executables, libraries, files, documents, etc. which reside in a node.
Component diagrams are used to visualize the organization and relationships
among components in a system. These diagrams are also used to make executable
systems.

Purpose of Component Diagrams

Component diagram is a special kind of diagram in UML. The purpose is also
different from all other diagrams discussed so far. It does not describe the
functionality of the system but it describes the components used to make those
functionalities.
Thus from that point of view, component diagrams are used to visualize the physical
components in a system. These components are libraries, packages, files, etc.
Component diagrams can also be described as a static implementation view of a
system. Static implementation represents the organization of the components at a
particular moment.
A single component diagram cannot represent the entire system but a collection of
diagrams is used to represent the whole.
The purpose of the component diagram can be summarized as −
 Visualize the components of a system.
 Construct executables by using forward and reverse engineering.
 Describe the organization and relationships of the components.
Component diagrams are very important from implementation perspective. Thus,
the implementation team of an application should have a proper knowledge of the
component details
Component diagrams can be used to −
 Model the components of a system.
 Model the database schema.
 Model the executables of an application.
 Model the system's source code.
LOGICAL VIEW-
• a system model is intended to show the logical and design aspects of the system
independent of its final packaging in an implementation medium
• The implementation aspects are also important for both reusability and performance
purposes
• UML includes two kinds of views for representing implementation units
– the implementation view
– the deployment view.
IMPLEMENTATION VIEW-
shows the physical packaging of the reusable pieces of the system into substitutable
units, called components
• A component is a physical unit of implementation with well-defined interfaces that is
intended to be used as a replaceable part of a system
• Each component embodies the implementation of certain classes from the system
design
• a component in a system can be replaced by another component that supports the
proper interfaces
• The component view shows the network of dependencies among components
DEPLOYMENT VIEW-
• shows the physical arrangement of run-time computational resources, such as
computers and their interconnections called nodes
• A node is a run-time physical object that represents a computational resource,
generally having at least a memory and often processing capability
 DEPLOYMENT DIAGRAM -
Deployment diagrams are used to visualize the topology of the physical
components of a system, where the software components are deployed.
Deployment diagrams are used to describe the static deployment view of a system.
Deployment diagrams consist of nodes and their relationships.

Purpose of Deployment Diagrams

The term Deployment itself describes the purpose of the diagram. Deployment
diagrams are used for describing the hardware components, where software
components are deployed. Component diagrams and deployment diagrams are
closely related.
Component diagrams are used to describe the components and deployment
diagrams shows how they are deployed in hardware.
UML is mainly designed to focus on the software artifacts of a system. However,
these two diagrams are special diagrams used to focus on software and hardware
components.
Most of the UML diagrams are used to handle logical components but deployment
diagrams are made to focus on the hardware topology of a system. Deployment
diagrams are used by the system engineers.
The purpose of deployment diagrams can be described as −
 Visualize the hardware topology of a system.
 Describe the hardware components used to deploy software components.
  Describe the runtime processing nodes.
 They show the structure of the run-time system
 They capture the hardware that will be used to implement the system
and the links between different items of hardware.
 They model physical hardware elements and the communication paths
between them
 They can be used to plan the architecture of a system.
 They are also useful for Document the deployment of software
components or nodes


Deployment diagrams can be used −

 To model the hardware topology of a system.
 To model the embedded system.
 To model the hardware details for a client/server system.
 To model the hardware details of a distributed application.
 For Forward and Reverse engineering.