OOAD Unit-IV PDF

Subject: OOAD Semester: 8TH Course No: CSE-802
Lecture Notes
On
UML
UNIT-IV
UML DIAGRAMS: TERMS AND CONCEPTS, RELATIONSHIP, DIAGRAMS.
ADVANCED CLASS DIAGRAM: ADVANCED RELATIONSHIP, INTERFACE TYPES
AND RULES, PACKAGES COMMON MODELLING TECHNIQUES, MODELLING
GROUPS ELEMENTS, MODELLING ARCHITECTURAL VIEWS. - INSTANCES AND
OBJECT DIAGRAMS: MODELLING CONCRETE/PROTOTYPICAL INSTANCES.
LINKS, OBJECTS INTERATION. -COLLABORATIONS, USE CASES,
INTERACTION DIAGRAMS, STATE TRANSITION DIAGRAMS. –
ARCHITECTURAL MODELLING: COMPONENT DIAGRAM, DEPLOYMENT
DIAGRAM, PATTERN AND FRAME WORK.
KHALID AMIN AKHOON 1

UML Diagrams:
In UML 2.0 there are 13 types of diagrams. To understand them, it is
sometimes useful to categorize them hierarchically:
Structure Diagrams emphasize what things must be in the system being
modeled:
 Class diagram
 Component diagram
 Composite structure diagram
 Deployment diagram
 Object diagram
 Package diagram
Behavior Diagrams emphasize what must happen in the system being
modeled:
 Activity diagram
 State Machine diagram
 Use case diagram
Interaction Diagrams, a subset of behavior diagrams, emphasize the flow of
control and data among the things in the system being modeled:
 Interaction overview diagram (UML 2.0)
 *Communication diagram (Collaboration Diagram)
 Sequence diagram
 UML Timing Diagram (UML 2.0)


Class Diagrams:
A Class defines the attributes and the methods of a set of objects. All objects
of this class (instances of this class) share the same behavior, and have the
same set of attributes (each object has its own set).
The term “Type” is sometimes used instead of Class, but it is important to
mention that these two are not the same, and Type is a more general term. In
UML, Classes are represented by rectangles, with the name of the class, and
can also show the attributes and operations of the class in two other
“compartments” inside the rectangle.
Graphical Notation, example:

POS System

Advanced Classes:
Classes are indeed the most important building block of any object-oriented
system. However, classes are just one kind of an even more general building
block in the UML• classifiers. A classifier is a mechanism that describes
structural and behavioral features. Classifiers include classes, interfaces,
datatypes, signals, components, nodes, use cases, and subsystems.
Classifiers (and especially classes) have a number of advanced features
beyond the simpler properties of attributes and operations described in the
previous section: You can model multiplicity, visibility, signatures,
polymorphism, and other characteristics. In the UML, you can model the
semantics of a class so that you can state its meaning to whatever degree of
formality you like.
In the UML, there are several kinds of classifiers and classes; it's important
that you choose the one that best models your abstraction of the real world.
Advance Classes
The UML provides a representation for a number of advanced properties, as
Figure shows. This notation permits you to visualize, specify, construct, and
document a class to any level of detail you wish, even sufficient to support
forward and reverse engineering of models and code.

A classifier is a mechanism that describes structural and behavioral features.

Classifiers include classes, interfaces, datatypes, signals, components, nodes,
use cases, and subsystems.
The most important kind of classifier in the UML is the class. A class is a
description of a set of objects that share the same attributes, operations,
relationships, and semantics. Classes are not the only kind of classifier,
however. The UML provides a number of other kinds of classifiers to help you
model.
Graphically, the UML distinguishes among these different classifiers, as shown

in the below figure.

Classifiers:
Visibility:
A classifier can see another classifier if it is in scope and if there is an explicit

or implicit relationship to the target.
Scope:
Another important detail you can specify for a classifier's attributes and
operations is its owner scope. The owner scope of a feature specifies whether
the feature appears in each instance of the classifier or whether there is just a
single instance of the feature for all instances of the classifier. In the UML, you
can specify two kinds of owner scope.

Abstract and Concrete Classes and Operations

Component Diagram:
Component diagrams show the organization and dependencies among a
group of components. Component diagrams comprise of:
 Components
 Interfaces
 Relationships
 Packages and Subsystems (optional)
Component diagrams are used for:
 Constructing systems through forward and reverse engineering.

 Modeling configuration management of source code files while
developing a system using an object-oriented programming language.
 Representing schemas in modeling databases.
 Modeling behaviors of dynamic systems.
Example
The following figure shows a component diagram to model a system’s source

code that is developed using C++. It shows four source code files, namely,
myheader.h, otherheader.h, priority.cpp, and other.cpp. Two versions of
myheader.h are shown, tracing from the recent version to its ancestor. The
file priority.cpp has compilation dependency on other.cpp. The file other.cpp
has compilation dependency on otherheader.h.

Composite structure Diagrams:

A composite structure diagram is a diagram that shows the internal structure
of a classifier, including its interaction points to other parts of the system. It
shows the configuration and relationship of parts, which together, perform the
behavior of the containing classifier. Class elements have been described in
great detail in the section on class diagrams. This section describes the way
classes can be displayed as composite elements exposing interfaces and
containing ports and parts.

Part:
A part is an element that represents a set of one or more instances which are
owned by a containing classifier instance. So for example, if a diagram
instance owned a set of graphical elements, then the graphical elements could
be represented as parts; if it were useful to do so, to model some kind of
relationship between them. Note that a part can be removed from its parent
before the parent is deleted, so that the part isn't deleted at the same time.
A part is shown as an unadorned rectangle contained within the body of a
class or component element.
Port:
A port is a typed element that represents an externally visible part of a
containing classifier instance. Ports define the interaction between a classifier
and its environment. A port can appear on the boundary of a contained part, a
class or a composite structure. A port may specify the services a classifier
provides as well as the services that it requires of its environment.
A port is shown as a named rectangle on the boundary edge of its owning
classifier.

Interfaces:
An interface is similar to a class but with a number of restrictions. All interface
operations are public and abstract, and do not provide any default
implementation. All interface attributes must be constants. However, while a
class may only inherit from a single super-class, it may implement multiple
interfaces.
An interface, when standing alone in a diagram, is either shown as a class
element rectangle with the «interface» keyword and with its name italicized to
denote it is abstract, or it is shown as a circle.
Note that the circle notation does not show the interface operations. When
interfaces are shown as being owned by classes, they are referred to as
exposed interfaces. An exposed interface can be defined as either provided or
required. A provided interface is an affirmation that the containing classifier
supplies the operations defined by the named interface element and is defined
by drawing a realization link between the class and the interface. A required
interface is a statement that the classifier is able to communicate with some
other classifier which provides operations defined by the named interface
element and is defined by drawing a dependency link between the class and
the interface.
A provided interface is shown as a "ball on a stick" attached to the edge of a
classifier element. A required interface is shown as a "cup on a stick" attached
to the edge of a classifier element.

Delegate:
A delegate connector is used for defining the internal workings of a
component's external ports and interfaces. A delegate connector is shown as
an arrow with a «delegate» keyword. It connects an external contract of a
component as shown by its ports to the internal realization of the behavior of
the component's part.
Collaboration:
Collaboration defines a set of co-operating roles used collectively to illustrate
a specific functionality. Collaboration should only show the roles and attributes
required to accomplish its defined task or function. Isolating the primary roles
is an exercise in simplifying the structure and clarifying the behavior, and also

provides for re-use. Collaboration often implements a pattern. A collaboration

element is shown as an ellipse.
Role Binding:
A role binding connector is drawn from collaboration to the classifier that
fulfils the role. It is shown as a dashed line with the name of the role at the
classifier end.
Represents:
A represents connector may be drawn from collaboration to a classifier to
show that collaboration is used in the classifier. It is shown as a dashed line
with arrowhead and the keyword «represents».

Occurrence:
An occurrence connector may be drawn from collaboration to a classifier to
show that collaboration represents the classifier. It is shown as a dashed line
with arrowhead and the keyword «occurrence».
Deployment diagram:
A deployment diagram puts emphasis on the configuration of runtime
processing nodes and their components that live on them. They are
commonly comprised of nodes and dependencies, or associations between
the nodes. Deployment diagrams are used to:
 Model devices in embedded systems that typically comprise of software-
intensive collection of hardware.
 Represent the topologies of client/server systems.
 Model fully distributed systems.
Example
The following figure shows the topology of a computer system that follows
client/server architecture. The figure illustrates a node stereotyped as server
that comprises of processors. The figure indicates that four or more servers
are deployed at the system. Connected to the server are the client nodes,
where each node represents a terminal device such as workstation, laptop,
scanner, or printer. The nodes are represented using icons that clearly depict
the real-world equivalent.

Object Diagram:
An object diagram models a group of objects and their links at a point of
time. It shows the instances of the things in a class diagram. Object diagram
is the static part of an interaction diagram.
Example: The following figure shows an object diagram of a portion of the

class diagram of the Banking System.

Package Diagram:
Package diagrams are used to reflect the organization of packages and their
elements. When used to represent class elements, package diagrams provide
a visualization of the namespaces. The most common use for package
diagrams is to organize use case diagrams and class diagrams, although the
use of package diagrams is not limited to these UML elements.
The following is an example of a package diagram.
Elements contained in a package share the same namespace. Therefore, the

elements contained in a specific namespace must have unique names.
Packages can be built to represent either physical or logical relationships.
When choosing to include classes in specific packages, it is useful to assign
the classes with the same inheritance hierarchy to the same package. There is
also a strong argument for including classes that are related via composition,
and classes that collaborate with them, in the same package.
Packages are represented in UML 2.1 as folders and contain the elements that
share a namespace; all elements within a package must be identifiable, and

so has a unique name or type. The package must show the package name and
can optionally show the elements within the package in extra compartments.
Package Merge:
A «merge» connector between two packages defines an implicit generalization
between elements in the source package, and elements with the same name
in the target package. The source element definitions are expanded to include
the element definitions contained in the target. The target element definitions
are unaffected, as are the definitions of source package elements that don't
match names with any element in the target package.
Package Import:
The «import» connector indicates that the elements within the target
package, which in this example is a single class, use unqualified names when
being referred to from the source package. The source package's namespace
gains access to the target classes; the target's namespace is not affected.
Nesting Connectors:
The nesting connector between the target package and source packages
shows that the source package is fully contained in the target package.

Behavior Diagrams:
Activity diagram:
Overview:
Activity diagram is another important diagram in UML to describe dynamic

aspects of the system. Activity diagram is basically a flow chart to represent
the flow form one activity to another activity. The activity can be described
as an operation of the system. So the control flow is drawn from one
operation to another. This flow can be sequential, branched or concurrent.
Activity diagrams deals with all type of flow control by using different
elements like fork, join etc.
Purpose:
The basic purposes of activity diagrams are similar to other four diagrams. It
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 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 activity diagram is the message part.
It does not show any message flow from one activity to another. Activity
diagram is some time considered as the flow chart. Although the diagrams
looks like a flow chart but it is not. It shows different flow like parallel,
branched, concurrent and single.

So the purposes 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.
How to draw Activity Diagram?
Activity diagrams are mainly used as a flow chart consists of activities

performed by the system. But activity diagram are not exactly a flow chart as
they have some additional capabilities. These additional capabilities include
branching, parallel flow, swim lane etc.
Before drawing an activity diagram we must have a clear understanding

about the elements used in activity diagram. The main element of an activity
diagram is the activity itself. An activity is a function performed by the
system. After identifying the activities we need to understand how they are
associated with constraints and conditions.
So before drawing an activity diagram we should identify the following

elements:
 Activities
 Association
 Conditions
 Constraints
Once the above mentioned parameters are identified we need to make a
mental layout of the entire flow. This mental layout is then transformed into
an activity diagram.
The following is an example of an activity diagram for order management
system. In the diagram four activities are identified which are associated with
conditions. One important point should be clearly understood that an activity
diagram cannot be exactly matched with the code. The activity diagram is
made to understand the flow of activities and mainly used by the business
users.
The following diagram is drawn with the four main activities:
 Send order by the customer
 Receipt of the order
 Confirm order
 Dispatch order
After receiving the order request condition checks are performed to check if it
is normal or special order. After the type of order is identified dispatch
activity is performed and that is marked as the termination of the process.

• Activity diagram commonly contains
o Activity states & action states
o Transitions
o Objects
Action states & Activity states:
 Action states represent the non interruptible actions of objects which can’t be
further decomposed & takes insignificant execution time.
 Activity states can be further decomposed, their activity being represented by

other activity diagram. Also activity states are not atomic, so they may be
interrupted & takes some time to complete.
 There is no notational distinction between action & activity states, except that an
activity state may have additional parts, such as entry & exit action.
Action Flow:
 Action flow arrows illustrate the relationships among action states.

Object Flow:
 Object flow refers to the creation and modification of objects by activities.
 An object flow arrow from an action to an object means t hat the action creates or
influences the object.
 An object flow arrow from an object to an action indicates that the action state
uses the object.
Branching:
 A diamond represents a decision with alternate paths. The outgoing alternates

should be labeled with a condition or guard expression. You can also label one of
the paths "else."

Symbols used in Activity Diagram

Where to use Activity Diagram?
The basic usage of activity diagram is similar to other four UML diagrams.
The specific usage is to model the control flow from one activity to another.
This control flow does not include messages.
The activity diagram is suitable for modeling the activity flow of the system.
An application can have multiple systems. Activity diagram also captures
these systems and describes flow from one system to another. This specific
usage is not available in other diagrams. These systems can be database,
external queues or any other system.
Now we will look into the practical applications of the activity diagram. From
the above discussion it is clear that an activity diagram is drawn from a very
high level. So it gives high level view of a system. This high level view is
mainly for business users or any other person who is not a technical person.
This diagram is used to model the activities which are nothing but business
requirements. So the diagram has more impact on business understanding
rather implementation details.
Following are the main usages of activity diagram:
 Modeling work flow by using activities.
 Modeling business requirements.
 High level understanding of the system's functionalities.
 Investigate business requirements at a later stage.

State Machine diagram:

A state–chart diagram shows a state machine that depicts the control flow of
an object from one state to another. A state machine portrays the sequences
of states which an object undergoes due to events and their responses to
events. State–Chart Diagrams comprise of:
 States: Simple or Composite
 Transitions between states
 Events causing transitions
 Actions due to the events
State-chart diagrams are used for modeling objects which are reactive in
nature.
Example
In the Automated Trading House System, let us model Order as an object

and trace its sequence. The following figure shows the corresponding state–
chart diagram.

Purchase Drink
Waiting Insert Coin[ valid ] / Make Selection Selection Dispensing

Select Drink[ ckeck available ] / Display Message
do/ Display Menu to Insert Coin do/ Display Message Select Drink... do/ Dis pence drink
Select Drink[ not available ]
Insert Coin[ invalid ] Receive Drink
Example of vending Machine

Use case diagram:

Use case diagrams present an outside view of the manner the elements in a
system behave and how they can be used in the context.
Use case diagrams comprise of:
 Use cases
 Actors
 Relationships like dependency, generalization, and association
Use case diagrams are used:

 To model the context of a system by enclosing all the activities of a
system within a rectangle and focusing on the actors outside the
system by interacting with it.
 To model the requirements of a system from the outside point of view.
 Requirements Capture
 Building Blocks of a Use Case Diagram
o Actors
o Use Cases
o Relationships between Use Cases
Actors:
 A role that interacts with the system.
 Represents a role, not individuals; can be a person or a device or
another system.
 Communicate with the system by sending and/or receiving messages.
 An actor may participate in many use cases; a use case may have
several actors participating in it.

Use-Case:
Is an abstraction of a set of sequences that yield some functionality?
 Represents some user-visible function.
 Is always initiated by an “actor”.
 Describes the interaction between the actors and the system for a
system function.
 Achieves a discrete goal for the actor.
Relationships between Use Cases:

 Uses/Includes
 Extends
“Extend” relationship: «extend»
 Use Case B extends Use Case A when Use Case B describes the
behavior of Use Case A under a particular condition.
 An extending Use Cases is used to describe variations in the

normal flow of events described by a general use case

“Include” relationship: «include»
 Use Case A uses (or “uses”) Use Case B when Use Case B is a
behavior/functionality that is required by Use Case A. That
behavior has been factored out into a separate Use Case because
it is required across several use cases.
 Common behavior in several use cases can be factored out into a

single use case that is used by the other use cases

Example:
Let us consider an Automated Trading House System. We assume the

following features of the system:
 The trading house has transactions with two types of customers,

individual customers and corporate customers.
 Once the customer places an order, it is processed by the sales

department and the customer is given the bill.
 The system allows the manager to manage customer accounts and

answer any queries posted by the customer.

Interaction overview diagram (UML 2.0):

An interaction overview diagram is a form of activity diagram in which the
nodes represent interaction diagrams. Interaction diagrams can include
sequence, communication, interaction overview and timing diagrams. Most of
the notation for interaction overview diagrams is the same for activity
diagrams. For example, initial, final, decision, merge, fork and join nodes are
all the same. However, interaction overview diagrams introduce two new
elements: interaction occurrences and interaction elements.
Interaction Occurrence:
Interaction occurrences are references to existing interaction diagrams. An
interaction occurrence is shown as a reference frame; that is, a frame with
"ref" in the top-left corner. The name of the diagram being referenced is
shown in the center of the frame.
Interaction Element:
Interaction elements are similar to interaction occurrences, in that they
display a representation of existing interaction diagrams within a rectangular
frame. They differ in that they display the contents of the references diagram
inline.

Putting it all Together:

All the same controls from activity diagrams (fork, join, merge, etc.) can be
used on interaction overview diagrams to put the control logic around the
lower level diagrams. The following example depicts a sample sale process,
with sub-processes abstracted within interaction occurrences.

Interaction Diagrams:
Interaction diagrams depict interactions of objects and their relationships.
They also include the messages passed between them.
There are two types of interaction diagrams:
 Communication diagram (Collaboration Diagram)
 Sequence Diagram
Interaction diagrams are used for modeling:
 The control flow by time ordering using sequence diagrams.

 The control flow of organization using collaboration diagrams.
Communication Diagram:
A communication diagram, formerly called a collaboration diagram, is an
interaction diagram that shows similar information to sequence diagrams but
its primary focus is on object relationships.
In communication diagrams, objects are shown with association connectors
between them. Messages are added to the associations and show as short
arrows pointing in the direction of the message flow. The sequence of
messages is shown through a numbering scheme.
The following diagrams are the examples of communication diagram.

2: Check coin
1: Insert coin
Customer Coin
Reader
8: Acknowledgement of availablility 5: select item 3: Request for menu

10: Recieved item 9: Request of item
7: Checking
4: Display menu
Dispencer System
interface
6: Check for availability

Sequence Diagrams:
Sequence diagrams are interaction diagrams that illustrate the ordering of
messages according to time.
Notations:
These diagrams are in the form of two-dimensional charts. The objects that
initiate the interaction are placed on the x–axis. The messages that these
objects send and receive are placed along the y–axis, in the order of
increasing time from top to bottom.
Sequence Diagrams: the basic elements:
Class roles:
Class roles describe the way an object will behave in context. Use the UML
object symbol to illustrate class roles, but don't list object attributes.
Activation:
Activation boxes represent the time an object needs to complete a task.

Messages
Messages are arrows that represent communication between objects. Use
half-arrowed lines to represent asynchronous messages. Asynchronous
messages are sent from an object that will not wait for a response from the
receiver before continuing its tasks.
Lifelines:
Lifelines are vertical dashed lines that indicate the object's presence over
time.

Destroying Objects:
Objects can be terminated early using an arrow labeled "< < destroy > >"
that points to an X.
Loops:
A repetition or loop within a sequence diagram is depicted as a rectangle.
Place the condition for exiting the loop at the bottom left corner in square
brackets [ ].

Customer Coin Reader System Dispencer

interface
Insert coin Check coin
Request for menu
Display menu
select item
Check for availability
Checking
Acknowledgement of availablility
Request of item
Recieved item
Vending Machine Sequence Diagram


UML Timing Diagram (UML 2.0):
Timing Diagrams:
UML timing diagrams are used to display the change in state or value of one
or more elements over time. It can also show the interaction between timed
events and the time and duration constraints that govern them.
State Lifeline:
A state lifeline shows the change of state of an item over time. The X-axis
displays elapsed time in whatever units are chosen, while the Y-axis is labeled
with a given list of states. A state lifeline is shown below.
Value Lifeline:
A value lifeline shows the change of value of an item over time. The X-axis
displays elapsed time in whatever units are chosen, the same as for the state
lifeline. The value is shown between the pair of horizontal lines which crosses
over at each change in value. A value lifeline is shown below.

Putting it all Together:

State and value Lifelines can be stacked one on top of another in any
combination. They must have the same X-axis. Messages can be passed from
one lifeline to another. Each state or value transition can have a defined
event, a time constraint which indicates when an event must occur, and a
duration constraint which indicates how long a state or value must be in effect
for. Once these have all been applied, a timing diagram may look like the
following.
Pattern:
Patterns help you to visualize, specify, construct, and document the artifacts
of a software intensive system. You can forward engineer a system by
selecting an appropriate set of patterns and applying them to the abstractions
specific to your domain. You can also reverse engineer a system by
discovering the patterns it embodies, although that's hardly a perfect process.
Even better, when you deliver a system, you can specify the patterns it
embodies so that when someone later tries to reuse or adapt that system, its
patterns will be clearly manifest.

Framework:
A framework is an architectural pattern that provides an extensible template
for applications within a domain. For example, one common architectural
pattern you'll encounter in real time systems is a cyclic executive, which
divides time into frames and sub frames, during which Processing takes place
under strict deadlines. Choosing this pattern versus its alternatives (an even-
driven architecture) colors your entire system. Because this pattern (and its
alternative) is so common, it makes sense to name it as a framework
Reference Books:
1. Booch/rambaugh, Jachobson-UML User guide, Addison Wesley.

2. Rambaugh: Object Oriented modeling and design PHI
Online References:
1. http://www.sparxsystems.com/resources/uml2_tutorial
2. https://www.tutorialspoint.com/object_oriented_analysis_design/ooad_object_oriented_ana
lysis.htm

OOAD Unit-IV PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OOAD Unit-IV PDF

Uploaded by

Copyright:

Available Formats

Subject: OOAD Semester: 8TH Course No: CSE-802

KHALID AMIN AKHOON 1

KHALID AMIN AKHOON 2

KHALID AMIN AKHOON 3

KHALID AMIN AKHOON 4

KHALID AMIN AKHOON 5

KHALID AMIN AKHOON 6

A classifier is a mechanism that describes structural and behavioral features.

Graphically, the UML distinguishes among these different classifiers, as shown

KHALID AMIN AKHOON 7

A classifier can see another classifier if it is in scope and if there is an explicit

KHALID AMIN AKHOON 8

Abstract and Concrete Classes and Operations

KHALID AMIN AKHOON 9

 Packages and Subsystems (optional)

Component diagrams are used for:

 Constructing systems through forward and reverse engineering.

The following figure shows a component diagram to model a system’s source

KHALID AMIN AKHOON 10

Composite structure Diagrams:

KHALID AMIN AKHOON 11

KHALID AMIN AKHOON 12

KHALID AMIN AKHOON 13

KHALID AMIN AKHOON 14

provides for re-use. Collaboration often implements a pattern. A collaboration

KHALID AMIN AKHOON 15

KHALID AMIN AKHOON 16

Example: The following figure shows an object diagram of a portion of the

KHALID AMIN AKHOON 17

Elements contained in a package share the same namespace. Therefore, the

KHALID AMIN AKHOON 18

KHALID AMIN AKHOON 19

Activity diagram is another important diagram in UML to describe dynamic

KHALID AMIN AKHOON 20

So the purposes 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.

How to draw Activity Diagram?

Activity diagrams are mainly used as a flow chart consists of activities

Before drawing an activity diagram we must have a clear understanding

So before drawing an activity diagram we should identify the following

KHALID AMIN AKHOON 22

• Activity diagram commonly contains

o Activity states & action states

Action states & Activity states:

 Activity states can be further decomposed, their activity being represented by

 Action flow arrows illustrate the relationships among action states.

KHALID AMIN AKHOON 23

 Object flow refers to the creation and modification of objects by activities.

 A diamond represents a decision with alternate paths. The outgoing alternates

KHALID AMIN AKHOON 24

Symbols used in Activity Diagram

KHALID AMIN AKHOON 25

Where to use Activity Diagram?

Following are the main usages of activity diagram:

 Modeling work flow by using activities.

 Modeling business requirements.

 High level understanding of the system's functionalities.

 Investigate business requirements at a later stage.

KHALID AMIN AKHOON 26

State Machine diagram: