UNIT-IV

SYLLOBUS:
Behavioral Modeling: Interactions, Interaction diagrams. Use cases, Use case Diagrams, Activity
Diagrams.
Case Study:Web Application:Vacation Tracking System

BASIC BEHAVIORAL MODELING

INTERACTIONS:
An interaction is a behavior that comprises a set of messages exchanged among a set
of objects within a context to accomplish a purpose. Use these interactions to model the
dynamic aspect of collaborations, representing societies of objects playing specific roles,
represent prototypical instances of classes, interfaces, components, nodes, and use cases.
Model the interaction in two ways: by emphasizing its time ordering of messages, or by
emphasizing its sequencing of messages in the context of some structural organization of
objects.
The UML provides a graphical representation of messages, as in below figure shows.
This notation permits you to visualize a message in a way that lets you emphasize its most
important parts: its name, parameters (if any), and sequence. Graphically, a message is
rendered as a directed line and almost always includes the name of its operation.

Figure : Messages, Links, and Sequencing

Terms and Concepts
1. Objects and Roles
The objects that participate in an interaction are either concrete things or prototypical
things. As a concrete thing, an object represents something in the real world. For example, p,
an instance of the class Person, might denote a particular human. Alternately, as a
prototypical thing, p might represent any instance of Person. An object diagram as a
representation of the static aspect of an interaction, setting the stage for the interaction by
specifying all the objects that work together. An interaction goes further by introducing a
dynamic sequence of messages that may pass along the links that connect these objects.
2. Links
A link is a semantic connection among objects. In general, a link is an instance of an
association. wherever a class has an association to another class, there may be a link between
the instances of the two classes; wherever there is a link between two objects, one object can
send a message to the other object.
 Figure : Links and Associations

A link specifies a path along which one object can dispatch a message to another(or
the same) object. Most of the time, it is sufficient to specify that such a path exists. As an
instance of an association, a link may be rendered with most of the adornments appropriate
to associations, such as a name, association role name, navigation, and aggregation,
multiplicity, however, does not apply to links, since they are instances of an association. If
you need to be more precise about how that path exists, you can adorn the appropriate end of
the link with any of the following standard stereotypes.

association Specifies that the corresponding object is visible by association

self Specifies that the corresponding object is visible because it is the dispatcher of
the operation
global Specifies that the corresponding object is visible because it is in an enclosing
scope
local Specifies that the corresponding object is visible because it is in a local scope
parameter Specifies that the corresponding object is visible because it is a parameter

3. Messages
A message is the specification of a communication among objects that conveys
information with the expectation that activity will ensue. The receipt of a message instance may
be considered an instance of an event. When passing a message, the action that results is an
executable statement that forms an abstraction of a computational procedure. An action may
result in a change in state.

In the UML, you can model several kinds of actions.

Call Invokes an operation on an object; an object may send a message to itself,
resulting in the local invocation of an operation
Return Returns a value to the caller
Send Sends a signal to an object
Create Creates an object
Destroy Destroys an object; an object may commit suicide by destroying itself

Figure : Messages
An object can't just call any random operation. If an object, such as c, calls the operation
setItinerary on an instance of the class TicketAgent, the operation setItinerary must not only be
defined for the class TicketAgent (that is, it must be declared in the class TicketAgent or one of
its parents), it must also be visible to the caller c.

4. Sequencing
When an object passes a message to another object (in effect, delegating some action to
the receiver), the receiving object might in turn send a message to another object, which might
send a message to yet a different object, and so on. This stream of messages forms a sequence.
Any sequence must have a beginning; the start of every sequence is rooted in some process or
thread.
A nonstop system, such as you might find in real time device control, will continue to
execute as long as the node it runs on is up. Each process and thread within a system defines a
distinct flow of control, and within each flow, messages are ordered in sequence by time. To
better visualize the sequence of a message, you can explicitly model the order of the message
relative to the start of the sequence by prefixing the message with a sequence number set apart
by a colon separator.
There are two types of sequencing:
i. Procedural Sequence
Most commonly, specify a procedural or nested flow of control, rendered using a filled solid
arrowhead, as shown below.
.
 Figure : Procedural Sequence

In this case, the message findAtis specified as the first message nested in the second message of
the sequence (2.1).

ii. Flat Sequence

Less common but also possible specify a flat flow of control, rendered using a stick arrowhead,
to model the nonprocedural progression of control from step to step. In this case, the message
assertCall is specified as the second message in the sequence.

Figure : Flat Sequence

The distinction between flat and procedural sequences is subtle and is really an advanced
modeling issue. Typically, use flat sequences only when modeling interactions in the context of
use cases that involve the system as a whole, together with actors outside the system. To use
procedural sequences, because they represent ordinary, nested operation calls of the type you
find in most programming languages.

5. Creation, Modification, and Destruction

In some interactions, objects may be created (specified by a create message) and
destroyed (specified by a destroy message). The same is true of links: the relationships among
objects may come and go. During an interaction, an object typically changes the values of its
attributes, its state, or its roles. On a sequence diagram, place each variant of the object on the
same lifeline. In an interaction diagram, connect each variant with a become message.
To specify if an object or link enters and/or leaves during an interaction, attach one of
the following constraints to the element.
new Specifies that the instance or link is created during execution of the enclosing
interaction
destroyed Specifies that the instance or link is destroyed prior to completion of execution of
the enclosing interaction
transient Specifies that the instance or link is created during execution of the enclosing
interaction but is destroyed before completion of execution
6. Representation
Visualize the objects and messages involved in an interaction in two ways: by
emphasizing the time ordering of its messages and by emphasizing the structural organization of
the objects that send and receive messages. In the UML, the first kind of representation is called
a sequence diagram; the second kind of representation is called a collaboration diagram. Both
sequence and collaboration diagrams are kinds of interaction diagrams. Sequence diagrams and
collaboration diagrams are largely isomorphic, meaning that if you can take one and transform it
into the other without loss of information.

COMMON MODELING TECHNIQUES FOR INTERACTIONS

1. Modeling a Flow of Control
The most common purpose for interactions is to model the flow of control that
characterizes the behavior of a system as a whole, including use cases, patterns, mechanisms, and
frameworks, or the behavior of a class or an individual operation. Whereas classes, interfaces,
components, nodes, and their relationships model the static aspects of your system, interactions
model its dynamic aspects.
To model a flow of control,
 Set the context for the interaction, whether it is the system as a whole, a class, or an
individual operation.
 Set the stage for the interaction by identifying which objects play a role; set their initial
properties, including their attribute values, state, and role.
 If the model emphasizes the structural organization of these objects, identify the links
that connect them, relevant to the paths of communication that take place in this
interaction.
 In time order, specify the messages that pass from object to object. As necessary,
distinguish the different kinds of messages; include parameters and return values to
convey the necessary detail of this interaction.
 Also to convey the necessary detail of this interaction, adorn each object at every
moment in time with its state and role.
For example, the figure shows a set of objects that interact in the context of a publish and
subscribe mechanism (an instance of the observer design pattern). This figure includes three
objects: p (a StockQuotePublisher), s1, and s2 (both instances of StockQuoteSubscriber).
 Figure : Flow of Control by Time (Sequence diagram)

The below figure is semantically equivalent to the previous one, but it is drawn as a collaboration
diagram, which emphasizes the structural organization of the objects. This figure shows the same
flow of control, but it also provides a visualization of the links among these objects.

Figure : Flow of Control by Organization(Collaboration diagram)

INTERACTION DIAGRAMS:
An interaction diagram shows an interaction, consisting of a set of objects and their
relationships, including the messages that may be dispatched among them. A sequence diagram
is an interaction diagram that emphasizes the time ordering of messages; a collaboration diagram
is an interaction diagram that emphasizes the structural organization of the objects that send and
receive messages. Use interaction diagrams to model the dynamic aspects of a system.
Interaction diagrams may stand alone to visualize, specify, construct, and document the
dynamics of a particular society of objects, or they may be used to model one particular flow of
control of a use case. Interaction diagrams are not only important for modeling the dynamic
aspects of a system, but also for constructing executable systems through forward and reverse
engineering. Interaction diagrams commonly contains objects , links and messages.
In the UML, you model these storyboards by using interaction diagrams. As below figure
shows, you can build up these storyboards in two ways: by emphasizing the time ordering of
messages and by emphasizing the structural relationships among the objects that interact. Either
way, the diagrams are semantically equivalent; you can convert one to the other without loss of
information.
Figure: Interaction Diagrams
Terms and Concepts
1. Semantic Equivalence
Because they both diagrams derive from the same information in the UML's meta model,
sequence diagrams and collaboration diagrams are semantically equivalent. As a result, if the
taken diagram in one form and convert it to the other without any loss of information, as you can
see in the previous two figures, which are semantically equivalent.
2. Common Uses
You use interaction diagrams to model the dynamic aspects of a system. These dynamic
aspects may involve the interaction of any kind of instance in any view of a system's
architecture, including instances of classes (including active classes), interfaces, components,
and nodes.
To model the dynamic aspects of a system, typically use interaction diagrams in
two ways.
i). To model flows of control by time ordering
Here use sequence diagrams. Modeling a flow of control by time ordering
emphasizes the passing of messages as they unfold over time, which is a particularly
useful way to visualize dynamic behavior in the context of a use case scenario. Sequence
diagrams do a better job of visualizing simple iteration and branching than do
collaboration diagrams.
ii). To model flows of control by organization
Here use collaboration diagrams. Modeling a flow of control by organization
emphasizes the structural relationships among the instances in the interaction, along which
messages may be passed. Collaboration diagrams do a better job of visualizing complex
iteration and branching and of visualizing multiple concurrent flows of control than do
sequence diagrams.

3. Sequence Diagrams
A sequence diagram is an interaction diagram that emphasizes the time ordering of messages. A sequence
diagram shows a set of objects and the messages sent and received by those objects.

Figure : Sequence Diagram

4. Collaboration Diagrams
A collaboration diagram is an interaction diagram that emphasizes the structural organization of
the objects that send and receive messages. A collaboration diagram shows a set of objects, links
among those objects, and messages sent and received by those objects.

Figure : Collaboration Diagram

Collaboration diagrams have two features that distinguish them from sequence diagrams. First,
there is the path. To indicate how one object is linked to another, you can attach a path stereotype
to the far end of a link (such as <<local>>), indicating that the designated object is local to the
sender).
Second, there is the sequence number. To indicate the time order of a message, you prefix the
message with a number (starting with the message numbered 1), increasing monotonically for
each new message in the flow of control (2, 3, and so on).

COMMON MODELING TECHNIQUES FOR INTERACTION DIAGRAMS

1. Modeling Flows of Control by Time Ordering
To model a flow of control by time ordering,
 Set the context for the interaction, whether it is a system, subsystem, operation, or
class, or one scenario of a use case or collaboration.
 Set the stage for the interaction by identifying which objects play a role in the
interaction.
 Set the lifeline for each object. In most cases, objects will persist through the entire
interaction. For those objects that are created and destroyed during the interaction,
set their lifelines, as appropriate, and explicitly indicate their birth and death with
appropriately stereotyped messages.
 Starting with the message that initiates this interaction, lay out each subsequent
message from top to bottom between the lifelines, showing each message's
properties as necessary to explain the semantics of the interaction.
 If you need to visualize the nesting of messages or the points in time when actual
computation is taking place, adorn each object's lifeline with its focus of control.
 If you need to specify time or space constraints, adorn each message with a timing
mark and attach suitable time or space constraints.
 If you need to specify this flow of control more formally, attach pre and post
conditions to each message.
  For example, the below Figure shows a sequence diagram that specifies the flow of
control involved in initiating a simple, two-party phone call. At this level of
abstraction, there are four objects involved: two Callers (s and r), an unnamed
telephone Switch, and c, the reification of the Conversation between the two parties.
The sequence begins with one Caller (s) dispatching a signal (liftReceiver) to the
Switch object. In turn, the Switch calls setDialTone on the Caller, and the Caller
iterates on the message dialDigit.

Figure : Modeling Flows of Control by Time Ordering

2. Modeling Flows of Control by Organization

To model a flow of control by organization,
 Set the context for the interaction, whether it is a system, subsystem, operation, or
class, or one scenario of a use case or collaboration.
 Set the stage for the interaction by identifying which objects play a role in the
interaction.
 Set the initial properties of each of these objects. If the attribute values, tagged
values, state, or role of any object changes in significant ways over the duration of
the interaction, place a duplicate object on the diagram, update it with these new
values, and connect them by a message stereotyped as become or copy .
 Specify the links among these objects, along which messages may pass.
1. Lay out the association links first; these are the most important ones, because they
represent structural connections.
2. Layout other links next, and adorns them with suitable path stereotypes (such as
global and local) to explicitly specifies how these objects are related to one another.
 Starting with the message that initiates this interaction, attach each subsequent
message to the appropriate link, setting its sequence number, as appropriate.
  If you need to specify time or space constraints, adorn each message with a timing
mark and attach suitable time or space constraints.
 If you need to specify this flow of control more formally, attach pre and post
conditions to each message.




Figure : Modeling Flows of Control by Organization

3. Forward and Reverse Engineering

Forward engineering (the creation of code from a model) is possible for both
sequence and collaboration diagrams, especially if the context of the diagram is an
operation. For example, using the previous collaboration diagram, a reasonably clever
forward engineering tool could generate the following Java code for the operation
register, attached to the Student class.
public void register()
{
CourseCollection c = getSchedule();
for (int i = 0; i < c.size(); i++)
c.item(i).add(this);
this.registered = true;
}
Reverse engineering (the creation of a model from code) is also possible for both
sequence and collaboration diagrams, especially if the context of the code is the body of an
operation.

USE CASES
A use case specifies the behavior of a system or a part of a system and is a description of
a set of sequences of actions, including variants that a system performs to yield an observable
result of value to an actor. Apply these use cases to capture the intended behavior of the system
which is developing, without having to specify how that behavior is implemented.

Use cases provide a way for developers to come to a common understanding with the
system's end users and domain experts. In addition, use cases serve to help validate architecture
and to verify the system as it evolves during development. Apply use cases to whole system. And
also apply use cases to part of the system, including subsystems and even individual classes and
interfaces.
 Figure : Actors and Use Cases

Terms and Concepts

1. Names
A use case name must be unique within its enclosing package. Every use case must have
a name that distinguishes it from other use cases. A name is a textual string. That name alone is
known as a simple name; a path name is the use case name prefixed by the name of the package
in which that use case lives.

Figure : Simple and Path Names

2. Use Cases and Actors
An actor represents a coherent set of roles that users of use cases play when interacting
with these use cases. Typically, an actor represents a role that a human, a hardware device, or
even another system plays with a system. If one actor was taken as the specialization of other
was indicated as below. As Figure indicates, actors are rendered as stick figures. You can define
general kinds of actors (such as Customer) and specialize them (such as CommercialCustomer)
using generalization relationships.

Figure : Actors
3. Use Cases and Flow of Events
A use case describes what a system (or a subsystem, class, or interface) does but
it does not specify how it does it. When you model, it's important that you keep clear the
separation of concerns between this outside and inside view.
For any use case is having the two types of flow named as main and exceptional flow.
This flow can represent with three types .The first one is informal representation, second
one is pre and post conditions and last one is pseudo code.
For example, in the context of an ATM system, you might describe the use case
ValidateUser in the following way:
i. Main flow of events:
The use case starts when the system prompts the Customer for a PIN number.
The Customer can now enter a PIN number via the keypad. The Customer commits the
entry by pressing the Enter button. The system then checks this PIN number to see if it is
valid. If the PIN number is valid, the system acknowledges the entry, thus ending the use
case.
ii. Exceptional flow of events:
The Customer can cancel a transaction at any time by pressing the Cancel button, thus
restarting the use case. No changes are made to the Customer's account.
iii.Exceptional flow of events:
The Customer can clear a PIN number anytime before committing it and reenter a new
PIN number.
iv. Exceptional flow of events:
If the Customer enters an invalid PIN number, the use case restarts. If this happens three
times in a row, the system cancels the entire transaction, preventing the Customer from
interacting with the ATM for 60 seconds.

4. Use Cases and Scenarios

It is desirable to separate main (primary) versus alternative (secondary) flows
because a use case describes a set of sequences, not just a single sequence, and it would be
impossible to express all the details of an interesting use case in just one sequence. Each
sequence is called a scenario. A scenario is a specific sequence of actions that illustrates
behavior. Scenarios are to use cases as instances are to classes, meaning that a scenario is
basically one instance of a use case.

5. Use Cases and Collaborations

In implementation of use cases, and do so by creating a society of classes and other
elements that work together to implement the behavior of this use case. This society of
elements, including both its static and dynamic structure, is modeled in the UML as
collaboration. Figure : Use Cases and Collaborations
 As above Figure shows, you can explicitly specify the realization of a use case by a
collaboration. Most of the time, though, a given use case is realized by exactly one collaboration,
so you will not need to model this relationship explicitly.

6. Organizing Use Cases

Organize use cases by grouping them in packages in the same manner in which you
can organize classes and also organize use cases by specifying generalization, include, and
extend relationships among them. Apply these relationships in order to factor common
behavior (by pulling such behavior from other use cases that it includes) and in order to
factor variants (by pushing such behavior into other use cases that extend it).
Generalization among use cases is just like generalization among classes. Here it
means that the child use case inherits the behavior and meaning of the parent use case; the
child may add to or override the behavior of its parent; and the child may be substituted any
place the parent appears.
An include relationship between use cases means that the base use case explicitly
incorporates the behavior of another use case at a location specified in the base. include as
the base use case pulling behavior from the supplier use case. Use an include relationship to
avoid describing the same flow of events several times, by putting the common behavior in a
use case of its own (the use case that is included by a base use case). Used symbol for an
include relationship as a dependency, stereotyped as include.
An extend relationship between use cases means that the base use case implicitly
incorporates the behavior of another use case at a location specified indirectly by the
extending use case. The base use case may stand alone, but under certain conditions, its
behavior may be extended by the behavior of another use case. This base use case may be
extended only at certain points called, not surprisingly, its extension points. extend as the
extension use case pushing behavior to the base use case. Use the extend relationship to
model the part of a use case the user may see as optional system behavior. Use the extend
relationship to model several flows that may be inserted at a certain point, governed by
explicit interaction with an actor. Used symbol for an extend relationship as a dependency,
stereotyped as extend.

Figure : Generalization, Include, and Extend

COMMON MODELING TECHNIQUES FOR USE CASES
1. Modeling the Behavior of an Element:
To model the behavior of an element,
 Identify the actors that interact with the element. Candidate actors include groups that
require certain behavior to perform their tasks or that are needed directly or indirectly to
perform the element's functions.
 Organize actors by identifying general and more specialized roles.
 For each actor, consider the primary ways in which that actor interacts with the element.
Consider also the exceptional ways in which each actor interacts with the element.
 Organize these behaviors as use cases, applying include and extend relationships to factor
common behavior and distinguish exceptional behavior.
For example, a retail system will interact with customers who place and track orders. In
turn, the system will ship orders and bill the customer. As below Figure shows, you can
model the behavior of such a system by declaring these behaviors as use cases (Place
order, Track order, Ship order, and Bill customer). Common behavior can be factored
out (Validate customer) and variants (Ship partial order) can be distinguished, as well.

Figure : Modeling the Behavior of an Element

USE CASE DIAGRAMS:

Use case diagrams are central to modeling the behavior of a system, a subsystem, or
a class. Each one shows a set of use cases and actors and their relationships. use case
diagrams to model the use case view of a system. For the most part, this involves modeling
the context of a system, subsystem, or class, or modeling the requirements of the behavior
of these elements. Use case diagrams are important for visualizing, specifying, and
documenting the behavior of an element. Use case diagrams are also important for testing
executable systems through forward engineering and for comprehending executable
systems through reverse engineering.
 As Figure shows, you can provide a use case diagram to model the behavior of that
box-which most people would call a cellular phone.

Figure : A Use Case Diagram

Terms and Concepts

A use case diagram is a diagram that shows a set of use cases and actors and
their relationships.

1. Common Properties
A use case diagram is just a special kind of diagram and shares the same common
properties as do all other diagrams-a name and graphical contents that are a projection into a
model.
2. Contents
Use case diagrams commonly contain
 Use cases
 Actors
 Dependency, generalization, and association relationships
Like all other diagrams, use case diagrams may contain notes and constraints. Use case diagrams
may also contain packages, which are used to group elements of your model into larger chunks.

3. Common Uses
When you model the static use case view of a system, you'll typically apply use case
diagrams in one of two ways.
i.To model the context of a system
Modeling the context of a system involves drawing a line around the whole system
and asserting which actors lie outside the system and interact with it. Here, you'll apply use
case diagrams to specify the actors and the meaning of their roles.
ii. To model the requirements of a system
Modeling the requirements of a system involves specifying what that system should
do (from a point of view of outside the system), independent of how that system should do
it. Here, you'll apply use case diagrams to specify the desired behavior of the system.

COMMON MODELING TECHNIQUES FOR USE CASE DIAGRAMS

1. Modeling the Context of a System
To model the context of a system,
 Identify the actors that surround the system by considering which groups require
help from the system to perform their tasks; which groups are needed to execute the
system's functions; which groups interact with external hardware or other software
systems; and which groups perform secondary functions for administration and
maintenance.
 Organize actors that are similar to one another in a generalization/specialization
hierarchy.
 Where it aids understandability, provide a stereotype for each such actor.
 Populate a use case diagram with these actors and specify the paths of
communication from each actor to the system's use cases.

For example, below Figure shows the context of a credit card validation system, with an
emphasis on the actors that surround the system. You'll find Customers, of which there are two
kinds (Individual customer and Corporate customer). These actors are the roles that humans play
when interacting with the system. In this context, there are also actors that represent other
institutions, such as Retail institution (with which a Customer performs a card transaction to buy
an item or a service) and Sponsoring financial institution.

Figure : Modeling the Context of a System

2. Modeling the Requirements of a System
A requirement is a design feature, property, or behavior of a system. Requirements can be
expressed in various forms, from unstructured text to expressions in a formal language, and
everything in between.
To model the requirements of a system,
 Establish the context of the system by identifying the actors that surround it.
 For each actor, consider the behavior that each expects or requires the system to provide.
 Name these common behaviors as use cases.
 Factor common behavior into new use cases that are used by others; factor variant
behavior into new use cases that extend more main line flows.
 Model these use cases, actors, and their relationships in a use case diagram.
 Adorn these use cases with notes that assert nonfunctional requirements; you may have
to attach some of these to the whole system.
For example, Detect card fraud is a behavior important to both the Retail institution and the
Sponsoring financial institution. Similarly, Report on account status is another behavior required
of the system by the various institutions in its context. The requirement modeled by the use case
Manage network outage is a bit different from all the others because it represents a secondary
behavior of the system necessary for its reliable and continuous operation.

Figure : Modeling the Requirements of a System

3. Forward and Reverse Engineering
Forward engineering is the process of transforming a model into code through a mapping
to an implementation language. A use case diagram can be forward engineered to form tests for
the element to which it applies.
To forward engineer a use case diagram,
 For each use case in the diagram, identify its flow of events and its exceptional
flow of events.
 Depending on how deeply you choose to test, generate a test script for each flow,
using the flow's preconditions as the test's initial state and its post conditions as its
success criteria.
 As necessary, generate test scaffolding to represent each actor that interacts with
the use case.
  Use tools to run these tests each time you release the element to which the use
case diagram applies.
Reverse engineering is the process of transforming code into a model through a mapping from a
specific implementation language.
To reverse engineer a use case diagram,
 Identify each actor that interacts with the system.
 For each actor, consider the manner in which that actor interacts with the system,
changes the state of the system or its environment, or responds to some event.
 Trace the flow of events in the executable system relative to each actor. Start with
primary flows and only later consider alternative paths.
 Cluster related flows by declaring a corresponding use case.
 Render these actors and use cases in a use case diagram, and establish their relationships.

ACTIVITY DIAGRAMS:
An activity diagram is essentially a flowchart, showing flow of control from
activity to activity. Activity diagrams may stand alone to visualize, specify, construct, and
document the dynamics of a society of objects, or they may be used to model the flow of
control of an operation. Whereas interaction diagrams emphasize the flow of control from
object to object, activity diagrams emphasize the flow of control from activity to activity.
An activity diagram shows the flow from activity to activity. Activities ultimately
result in some action, which is made up of executable atomic computations that result in a
change in state of the system or the return of a value. Actions encompass calling another
operation, sending a signal, creating or destroying an object, or some pure computation, such
as evaluating an expression. Graphically, an activity diagram is a collection of vertices and
arcs.

Figure : Activity Diagrams

Terms and Concepts
Activity diagrams commonly contain
 Activity states and action states
 Transitions
 Objects
An activity diagram is basically a projection of the elements found in an activity graph, a
special case of a state machine in which all or most states are activity states and in which all
or most transitions are triggered by completion of activities in the source state. Because an
activity diagram is a kind of state machine, all the characteristics of state machines apply.
That means that activity diagrams may contain simple and composite states, branches, forks,
and joins.

1. Action States and Activity States

Action states and activity states are just special kinds of states in a state machine. When you
enter an action or activity state, you simply perform the action or the activity; when you
finish, control passes to the next action or activity. An activity state is semantically
equivalent to expanding its activity graph (and transitively so) in place until you only see
actions. As Figure shows, you represent an action state using a lozenge shape (a symbol with
horizontal top and bottom and convex sides). Inside that shape, you may write any
expression. Action states can't be decomposed.

Figure: Action states

As Figure shows, there's no notational distinction between action and activity states,
except that an activity state may have additional parts, such as entry and exit actions (actions
which are involved on entering and leaving the state, respectively) and submachine
specifications.

Figure: Activity states

2. Transitions
When the action or activity of a state completes, flow of control passes immediately to
the next action or activity state. You specify this flow by using transitions to show the path from
one action or activity state to the next action or activity state. In the UML, you represent a
transition as a simple directed line, as Figure shows. Triggerless transitions may have guard
conditions, meaning that such a transition will fire only if that condition is met.
 Figure: Triggerless transitions

3. Branching
Representation of a branch as a diamond (specifies alternate paths taken based on some
Boolean expression). A branch may have one incoming transition and two or more outgoing
ones. On each outgoing transition, you place a Boolean expression, which is evaluated only
once on entering the branch. Across all these outgoing transitions, guards should not overlap
(otherwise, the flow of control would be ambiguous), but they should cover all possibilities
(otherwise, the flow of control would freeze).

Figure: Branching

4. Forking and Joining

A fork represents the splitting of a single flow of control into two or more concurrent
flows of control. A fork may have one incoming transition and two or more outgoing transitions,
each of which represents an independent flow of control. Below the fork, the activities associated
with each of these paths continues in parallel. Conceptually, the activities of each of these flows
are truly concurrent, although, in a running system, these flows may be either truly concurrent (in
the case of a system deployed across multiple nodes) or sequential yet interleaved (in the case of
a system deployed across one node), thus giving only the illusion of true concurrency

A join represents the synchronization of two or more concurrent flows of control. A join
may have two or more incoming transitions and one outgoing transition. As the join, the
activities associated with each of these paths continues in parallel. At the join, the concurrent
flows synchronize, meaning that each waits until all incoming flows have reached the join, at
which point one flow of control continues on below the join.
 Figure: Forking and Joining
5. Swimlanes
To partition the activity states on an activity diagram into groups, each group
representing the business organization responsible for those activities. In the UML, each
group is called a swimlane because, visually, each group is divided from its neighbor by a
vertical solid line as shown in below figure. A swimlane specifies a locus of activities. Each
swimlane has a name unique within its diagram.
A swimlane really has no deep semantics, except that it may represent some real-
world entity. Each swimlane represents a high-level responsibility for part of the overall
activity of an activity diagram, and each swimlane may eventually be implemented by one
or more classes. In an activity diagram partitioned into swimlanes, every activity belongs to
exactly one swimlane, but transitions may cross lanes.

Figure : Swimlanes
6. Object Flow
Objects may be involved in the flow of control associated with an activity diagram.
For example, in the workflow of processing an order as in the previous figure, the
vocabulary of your problem space will also include such classes as Order and Bill. Instances
of these two classes will be produced by certain activities (Process order will create an
Order object, for example); other activities may modify these objects (for example, Ship
order will change the state of the Order object to filled).
As Figure shows, things that are involved in an activity diagram by placing these
objects in the diagram, connected using a dependency to the activity or transition that
creates, destroys, or modifies them. This use of dependency relationships and objects is
called an object flow because it represents the participation of an object in a flow of
control.

Figure : Object Flow

7. Common Uses:
Use activity diagrams to model the dynamic aspects of a system. These dynamic
aspects may involve the activity of any kind of abstraction in any view of a system's
architecture, including classes (which includes active classes), interfaces, components, and
nodes. Usage of these diagrams in virtual modeling of a system. Use activity diagrams in
the context of the system as a whole, a subsystem, an operation, or a class. Attach the
activity diagrams to use cases (to model a scenario) and to collaborations (to model the
dynamic aspects of a society of objects).

When you model the dynamic aspects of a system, you'll typically use activity
diagrams in two ways.
i.To model a workflow
Here you'll focus on activities as viewed by the actors that collaborate with the system.
Workflows often lie on the fringe of software-intensive systems and are used to visualize,
specify, construct, and document business processes that involve the system you are
developing.
ii.To model an operation
Here you'll use activity diagrams as flowcharts, to model the details of a computation. In
this use of activity diagrams, the modeling of branch, fork, and join states is particularly
important.

COMMON MODELING TECHNIQUES FOR ACTIVITY DIAGRAMS

1. Modeling a Workflow
To model a workflow,
 Establish a focus for the workflow. For nontrivial systems, it's impossible to show all
interesting workflows in one diagram.
 Select the business objects that have the high-level responsibilities for parts of
the overall workflow. These may be real things from the vocabulary of the
system, or they may be more abstract.
 Select the business objects that have the high-level responsibilities for parts of
the overall workflow. This is important in helping you model the boundaries of
the workflow.
 Beginning at the workflow's initial state, specify the activities and actions that
take place over time and render them in the activity diagram as either activity
states or action states.
 For complicated actions, or for sets of actions that appear multiple times,
collapse these into activity states, and provide a separate activity diagram that
expands on each.
 Render the transitions that connect these activity and action states. Start with
the sequential flows in the workflow first, next consider branching, and only
then consider forking and joining.
 If there are important objects that are involved in the workflow, render them in
the activity diagram, as well. Figure : Modeling a Workflow
2. Modeling an Operation
To model an operation,
 Collect the abstractions that are involved in this operation. This includes the
operation's parameters (including its return type, if any), the attributes of the
enclosing class, and certain neighboring classes.
 Identify the preconditions at the operation's initial state and the post conditions at the
operation's final state.
 Beginning at the operation's initial state, specify the activities and actions that take
place over time and render them in the activity diagram as either activity states or
action states.
 Use branching as necessary to specify conditional paths and iteration.
 Only if this operation is owned by an active class, use forking and joining as
necessary to specify parallel flows of control.

Figure shows an activity diagram that specifies the algorithm of the operation intersection,
whose signature includes one parameter (l, an in parameter of the class Line) and one return
value (of the class Point). The class Line has two attributes of interest: slope (which holds
the slope of the line) and delta (which holds the offset of the line relative to the origin).

Figure : Modeling an Operation

3. Forward and Reverse Engineering
Forward engineering (the creation of code from a model) is possible for activity
diagrams, especially if the context of the diagram is an operation. For example, using the
previous activity diagram, a forward engineering tool could generate the following C++
code for the operation intersection.
Point Line::intersection (l : Line) {
if (slope == l.slope) return Point(0,0);
int x = (l.delta - delta) / (slope - l.slope);
int y = (slope * x) + delta;return Point(x, y);
}
Reverse engineering (the creation of a model from code) is also possible for activity
diagrams, especially if the context of the code is the body of an operation. In particular,
the previous diagram could have been generated from the implementation of the class
Line.
Case Study:Web Application:Vacation Tracking System:
 The vision for this project can be summarized easily. A Vacation Tracking System
(VTS) will provide individual employees with the capability to manage their own
vacation time, sick leave, and personal time off, without having to be an expert in
company policy or the local facility's leave policies.
 The most important goal of this system is to give individual employees the capability
and responsibility to manage this particular aspect of their employment agreements
with the company.
 The underlying motivations for this desire include the need to streamline the
functions of the human resources (HR) department, to minimize noncore, business-
related activities of management, and to give a sense of empowerment to the
employees.
 These objectives will be met only if the system developed is easy to use, intuitive,
and intelligent. An overriding design goal can therefore be stated simply. The system
must be easy to use.

The system will provide the following key features:

■Implements a flexible rules-based system for validating and verifying leave time
requests
■ Enables manager approval (optional)Provides access to requests for the previous
calendar year, and allows requests to be made up to a year and a half in the future
■ Uses e-mail notification to request manager approval and notify employees of request
status changes
■ Uses existing hardware and middleware
■ Keeps activity logs for all transactions
■ Allows managers to directly award personal leave time (with system-set limits)
■ Provides a Web service interface for other internal systems to query any given
employee's vacation request summary Interfaces with the HR department legacy systems
to retrieve required employee information and changes.
The system contains the following actors:
■Employee: The main user of this system. An employee uses this system to manage his
or her vacation time.
■Manager: An employee who has all the abilities and goals of a regular employee, but
with the added responsibility of approving vacation requests for immediate subordinates.
A manager may award subordinates comp time, subject to certain limits set in the system.
■Clerk: A member of the HR department who has sufficient rights to view employees'
personal data and is responsible for ensuring that employees' information in all HR
systems is up to date and correct. An HR clerk can add or remove nearly any record in the
system. In the real world, HR clerks. may or may not be employees; however, if they are
employees, they use two separate login IDs to manage these two different roles.
■System Admin: A role responsible for the smooth running of the system's technical
resources (e.g., Web server, database) and for collecting and archiving all log files.

The main use cases are as follows:

■Manage Time: Describes how employees request and view vacation time requests.
■ Approve Request: Describes how a manager responds to a subordinate's request for
vacation time.
■Award Time: Describes how a manager can award a subordinate extra leave time (comp
time).
■ Edit Employee Record: Describes how an HR clerk edits anemployee's information in
the system. This includes setting all the leave time allowances and the maximum time that
can be awarded by the manager.
■ Manage Locations: Describes how an HR clerk manages location records and their
rules.
■Manage Leave Categories: Describes how an HR clerk manages leave categories and
their rules.
■ Override Leave Records: Describes how an HR clerk may override any rejection of
leave time requests made by the rules in the system.
■Back Up System Logs: Describes how the system administrator backs up the system's
logs.