UML

The Unified Modeling Language (UML) is a standard language for specifying, visualizing,
constructing, and documenting the artifacts of software systems, as well as for business
modeling and other non-software systems. The UML represents a collection of best
engineering practices that have proven successful in the modeling of large and complex
systems. The UML is a very important part of developing object oriented software and the
software development process. The UML uses mostly graphical notations to express the
design of software projects. Using the UML helps project teams communicate, explore
potential designs, and validate the architectural design of the software.

Goals of UML

The primary goals in the design of the UML were:

1. Provide users with a ready-to-use, expressive

visual modeling language so they can develop and
exchange meaningful models.
2. Provide extensibility and specialization
mechanisms to extend the core concepts.
3. Be independent of particular programming
languages and development processes.
4. Provide a formal basis for understanding the
modeling language.
5. Encourage the growth of the OO tools market.
6. Support higher-level development concepts
such as collaborations, frameworks, patterns and
components.
7. Integrate best practices.

Why Use UML?

As the strategic value of software increases for many companies, the industry
looks for techniques to automate the production of software and to improve
quality and reduce cost and time-to-market. These techniques include
component technology, visual programming, patterns and frameworks.
Businesses also seek techniques to manage the complexity of systems as they
increase in scope and scale. In particular, they recognize the need to solve
recurring architectural problems, such as physical distribution, concurrency,
replication, security, load balancing and fault tolerance. Additionally, the
development for the World Wide Web, while making some things simpler, has
exacerbated these architectural problems. The Unified Modeling Language
(UML) was designed to respond to these needs.

History of UML

Identifiable object-oriented modeling languages began to appear between mid-1970 and

the late 1980s as various methodologists experimented with different approaches to
object-oriented analysis and design. The number of identified modeling languages
increased from less than 10 to more than 50 during the period between 1989-1994. Many
users of OO methods had trouble finding complete satisfaction in any one modeling
language, fueling the "method wars." By the mid-1990s, new iterations of these methods
began to appear and these methods began to incorporate each other’s techniques, and a
few clearly prominent methods emerged.

The development of UML began in late 1994 when Grady Booch and Jim Rumbaugh of
Rational Software Corporation began their work on unifying the Booch and OMT (Object
Modeling Technique) methods. In the Fall of 1995, Ivar Jacobson and his Objectory
company joined Rational and this unification effort, merging in the OOSE (Object-
Oriented Software Engineering) method.

As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch, Jim
Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling language for
three reasons. First, these methods were already evolving toward each other
independently. It made sense to continue that evolution together rather than apart,
eliminating the potential for any unnecessary and gratuitous differences that would further
confuse users. Second, by unifying the semantics and notation, they could bring some
stability to the object-oriented marketplace, allowing projects to settle on one mature
modeling language and letting tool builders focus on delivering more useful features.
Third, they expected that their collaboration would yield improvements in all three earlier
methods, helping them to capture lessons learned and to address problems that none of
their methods previously handled well.

The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the UML 0.9
and 0.91 documents in June and October of 1996. During 1996, the UML authors invited
and received feedback from the general community. They incorporated this feedback, but
it was clear that additional focused attention was still required.
While Rational was bringing UML together, efforts were being made on achieving the
broader goal of an industry standard modeling language. In early 1995, Ivar Jacobson
(then Chief Technology Officer of Objectory) and Richard Soley (then Chief Technology
Officer of OMG) decided to push harder to achieve standardization in the methods
marketplace. In June 1995, an OMG-hosted meeting of all major methodologists (or their
representatives) resulted in the first worldwide agreement to seek methodology
standards, under the aegis of the OMG process.

During 1996, it became clear that several organizations saw UML as strategic to their
business. A Request for Proposal (RFP) issued by the Object Management Group
(OMG) provided the catalyst for these organizations to join forces around producing a
joint RFP response. Rational established the UML Partners consortium with several
organizations willing to dedicate resources to work toward a strong UML 1.0 definition.
Those contributing most to the UML 1.0 definition included: Digital Equipment Corp., HP,
i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational
Software, TI, and Unisys. This collaboration produced UML 1.0, a modeling language that
was well defined, expressive, powerful, and generally applicable. This was submitted to
the OMG in January 1997 as an initial RFP response.

In January 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich

Technologies and Softeam also submitted separate RFP responses to the OMG. These
companies joined the UML partners to contribute their ideas, and together the partners
produced the revised UML 1.1 response. The focus of the UML 1.1 release was to
improve the clarity of the UML 1.0 semantics and to incorporate contributions from the
new partners. It was submitted to the OMG for their consideration and adopted in the fall
of 1997.

Types of UML Diagrams

UML diagrams are designed to let developers and customers view a software system from a

different perspective and in varying degrees of abstraction.UML defines nine types of diagrams: class
(package, object), use case, interaction (sequence, collaboration), statechart, activity, physical (component,

and deployment).

Class Diagrams

Class diagrams are the backbone of almost every object oriented method, including UML. They describe the

static structure of a system. Class Diagram models class structure and contents using design
elements such as classes, packages and objects. It also displays relationships such as

containment, inheritance, associations and others.

Package Diagrams

Package diagrams are a subset of class diagrams, but developers sometimes treat them as a separate

technique. Package diagrams organize elements of a system into related groups to minimize dependencies

between packages.

Object Diagrams

Object diagrams describe the static structure of a system at a particular time. They can be used to test class

diagrams for accuracy.

Use Case Diagrams

Use case diagrams model the functionality of system using actors and use cases.

Sequence Diagrams

Sequence Diagram displays the time sequence of the objects participating in the interaction.

This consists of the vertical dimension (time) and horizontal dimension (different objects).This
diagrams actually describe interactions among classes in terms of an exchange of messages over time.
Collaboration Diagrams

Collaboration Diagram displays an interaction organized around the objects and their links to

one another. Numbers are used to show the sequence of messages.This diagram represent
interactions between objects as a series of sequenced messages. Collaboration diagrams describe both the

static structure and the dynamic behavior of a system.

Statechart Diagrams

State Diagram displays the sequences of states that an object of an interaction goes through

during its life in response to received stimuli, together with its responses and actions Statechart
diagrams describe the dynamic behavior of a system in response to external stimuli. Statechart diagrams

are especially useful in modeling reactive objects whose states are triggered by specific events.
Activity Diagrams

Activity Diagram displays a special state diagram where most of the states are action states and

most of the transitions are triggered by completion of the actions in the source states. This

diagram focuses on flows driven by internal processing.Activity diagrams illustrate the dynamic nature
of a system by modeling the flow of control from activity to activity. An activity represents an operation on

some class in the system that results in a change in the state of the system. Typically, activity diagrams are

used to model workflow or business processes and internal operation.

Component Diagrams

Component Diagram displays the high level packaged structure of the code itself.

Dependencies among components are shown, including source code components, binary code

components, and executable components. Some components exist at compile time, at link time,

at run times well as at more than one time.Component diagrams describe the organization of physical
software components, including source code, run-time (binary) code, and executables.
Deployment Diagrams

Deployment Diagram displays the configuration of run-time processing elements and the

software components, processes, and objects that live on them. Software component instances

represent run-time manifestations of code units.Deployment diagrams depict the physical resources in
a system, including nodes, components, and connections.

UML Diagram Classification—Static, Dynamic, and Implementation

A software system can be said to have two distinct characteristics: a structural, "static" part and a

behavioral, "dynamic" part. In addition to these two characteristics, an additional characteristic

that a software system possesses is related to implementation. Before we categorize UML

diagrams into each of these three characteristics, let us take a quick look at exactly what these

characteristics are.

• Static: The static characteristic of a system is essentially the structural aspect of the

system. The static characteristics define what parts the system is made up of.
 • Dynamic: The behavioral features of a system; for example, the ways a system behaves

in response to certain events or actions are the dynamic characteristics of a system.

• Implementation: The implementation characteristic of a system is an entirely new

feature that describes the different elements required for deploying a system.

The UML diagrams that fall under each of these categories are:

• Static

o Use case diagram

o Class diagram

• Dynamic

o Object diagram

o State diagram

o Activity diagram

o Sequence diagram

o Collaboration diagram

• Implementation

o Component diagram

o Deployment diagram

The 4+1 View of UML Diagrams

Considering that the UML diagrams can be used in different stages in the life cycle of a system,

let us take a look at the "4+1 view" of UML diagrams. The 4+1 view offers a different perspective

to classify and apply UML diagrams. The 4+1 view is essentially how a system can be viewed

from a software life cycle perspective. Each of these views represents how a system can be

modeled. This will enable us to understand where exactly the UML diagrams fit in and their

applicability.

These different views are:

• Design View: The design view of a system is the structural view of the system. This

gives an idea of what a given system is made up of. Class diagrams and object diagrams

form the design view of the system.

• Process View: The dynamic behavior of a system can be seen using the process view.

The different diagrams such as the state diagram, activity diagram, sequence diagram,

and collaboration diagram are used in this view.

• Component View: Next, you have the component view that shows the grouped modules

of a given system modeled using the component diagram.

• Deployment View: The deployment diagram of UML is used to identify the deployment

modules for a given system. This is the deployment view of the

• Use case View: Finally, we have the use case view. Use case diagrams of UML are

used to view a system from this perspective as a set of discrete activities or transactions.
Diagrams in detail.
Class Diagram
What is a UML Class Diagram?

Class diagrams are the backbone of almost every object-oriented method including UML. They describe the

static structure of a system.

When to Use: Class Diagrams

Class diagrams are used in nearly all Object Oriented software designs. Use them to
describe the Classes of the system and their relationships to each other.

Basic Class Diagram Symbols and Notations

Classes represent an abstraction of entities with common characteristics. Associations represent the

relationships between classes.Illustrate classes with rectangles divided into compartments. Place the name

of the class in the first partition (centered, bolded, and capitalized), list the attributes in the second partition,

and write operations into the third.

Active Class

Active classes initiate and control the flow of activity, while passive classes store data and serve other

classes. Illustrate active classes with a thicker border.

Visibility
Use visibility markers to signify who can access the information contained within a class. Private visibility

hides information from anything outside the class partition. Public visibility allows all other classes to view

the marked information. Protected visibility allows child classes to access information they inherited from a

parent class.

Links and Associations

Links and associations are the means of establishing relationships among objects and classes.A link shows
a relationship between two or more objects and classes.For example,Joe Smith works for Simplex company.

(person) Works for (Company)

Joe Smith Simplex

The association link indicates that two classes have a relationship.Associations are bidirectional,that
means can be traversed in both direction.The direction implied by the name is forward direction.The
opposite direction is inverse direction.For example

(person) Works for Employs (Company)

Joe Smith Simplex

Associations may be binary, ternary or higher order. Each association link has two ends which are called
roles. Each role has a name, a multiplicity, a navigability and a type.

For example a student attends a school; a student takes courses.

Multiplicity:

The multiplicity of a role indicates how many objects can participate in the relationship. These symbols

indicate the number of instances of one class linked to one instance of the other class. In the example

above, a school has many students and each student attends only one school. Multiplicity can be of different

type.

Common multiplicity values:

Symbol Meaning

1 One and only one

0..1 /Hollow ball ( ) Zero or one

M…N From M to N (natural integer)

0..* /Solid Ball( ) From zero to any positive integer

1..* From one to any positive integer

* Many

Navigability:

Sometimes a role has an arrow indicating its navigability. This shows which class has the responsibility for
maintaining the relationship between the classes. In the example above, the school class has a
responsibility for knowing which students attend. Therefore, you don't have to explicitly define a getStudents
operation in the school class (although you may) since it is already implicitly defined by the navigability of
the association.
Type:

The role can have one of three types: association, composition or aggregation. Associations indicate
that the two classes have a relationship as discussed above. Composition and aggregation indicate
something more about the relationship:

Composition indicates that one class belongs to the other.Composition is a special type of aggregation that
denotes a strong ownership between Class A, the whole, and Class B, its part. Illustrate composition with a
filled diamond. For example, A polygon is made up of several points. If the polygon is destroyed, so are the
points.

Point Polygon

Aggregation is similar to composition, but is a less rigorous way of grouping things. Aggregation is the

“Whole part” or “a-part-of” relationship in which objects representing the components of something are

associated with an object representing the entire assembly. We use a hollow diamond to represent a simple

aggregation relationship, in which the "whole" class plays a more important role than the "part" class, but the

two classes are not dependent on each other. The diamond end in both a composition and aggregation

relationship points toward the "whole" class or the aggregate. For example, an order is made up of several

products, but a product continues to exist even if the order is destroyed.

Products Purchase
Order

Constraint

Place constraints inside curly braces {}.

 Simple Constraint

Generalization

Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship between

two classes where one class is a specialized version of another. The notation for generalization is a triangle

connecting a superclass to it’s subclass.For example, Honda is a type of car. So the class Honda would

have a generalization relationship with the class car.

Car

Honda Maruti

Note: In real life coding examples, the difference between inheritance and aggregation can be confusing. If

you have an aggregation relationship, the aggregate (the whole) can access only the PUBLIC functions of

the part class. On the other hand, inheritance allows the inheriting class to access both the PUBLIC and

PROTECTED functions of the superclass.

 Class diagram [for withdrawal of cash, normal flow]

What is a UML Package Diagram?

Package diagrams organize the elements of a system into related groups to minimize dependencies among

them.

Basic Package Diagram Symbols and Notations

Packages
Use a tabbed folder to illustrate packages. Write the name of the package on the tab or inside the folder.

Similar to classes, you can also list the attributes of a package.

Visibility

Visibility markers signify who can access the information contained within a package. Private visibility means

that the attribute or the operation is not accessible to anything outside the package. Public visibility allows an

attribute or an operation to be viewed by other packages. Protected visibility makes an attribute or operation

visible to packages that inherit it only.

Dependency

Dependency defines a relationship in which changes to one package will affect another package. Importing

is a type of dependency that grants one package access to the contents of another package.

Learn how to draw dependencies and add arrows to your diagram.

What is a UML Object Diagram?

Object diagrams are also closely linked to class diagrams. Just as an object is an instance of a class, an

object diagram could be viewed as an instance of a class diagram. Object diagrams describe the static

structure of a system at a particular time and they are used to test the accuracy of class diagrams.

Basic Object Diagram Symbols and Notations

Object names

Each object is represented as a rectangle, which contains the name of the object and its class underlined

and separated by a colon.

Object attributes

As with classes, you can list object attributes in a separate compartment. However, unlike classes, object

attributes must have values assigned to them.

Active object

Objects that control action flow are called active objects. Illustrate these objects with a thicker border.

Multiplicity

You can illustrate multiple objects as one symbol if the attributes of the individual objects are not important.

Links
Links are instances of associations. You can draw a link using the lines used in class diagrams.

Self-linked

Objects that fulfill more than one role can be self-linked. For example, if Mark, an administrative assistant,

also fulfilled the role of a marketing assistant, and the two positions are linked, Mark's instance of the two

classes will be self-linked.

USE Case diagram

A use case is a set of scenarios that describing an interaction between a user and a system. A use
case diagram displays the relationship among actors and use cases. The two main components of
a use case diagram are use cases and actors.
An actor is represents a user or another system that will interact with the system you are modeling.
A use case is an external view of the system that represents some action the user might perform in
order to complete a task.

When to Use: Use Cases Diagrams

Use cases are used in almost every project. The are helpful in exposing requirements
and planning the project. During the initial stage of a project most use cases should be
defined, but as the project continues more might become visible.

Basic Use Case Diagram Symbols and Notations

System

Draw your system's boundaries using a rectangle that contains use cases. Place actors outside the system's

boundaries.

Use Case

Draw use cases using ovals. Label with ovals with verbs that represent the system's functions.
Actors

Actors are the users of a system. When one system is the actor of another system, label the actor system

with the actor stereotype.

Relationships

Illustrate relationships between an actor and a use case with a simple line. For relationships among use
cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that one use case is
needed by another in order to perform a task. Notation used to show the relationships << >>. Relationship
between two use cases is refereed as either uses or extends. USES or includes: Multiple use cases share a
piece of same functionality. This functionality is placed in a separate use case rather than documenting in
every use case that needs it. A uses relationship shows behavior that is common to one or more use
cases. An "extends" relationship indicates alternative options under a certain use case. EXTENDS: It is
used to show optional behavior, which is required only under certain condition.
How to Draw: Use Cases Diagrams

We start by listing a sequence of steps a user might take in order to complete an action.
For example a user placing an order with a sales company might follow these steps.

1. Browse catalog and select items.

2. Call sales representative.
3. Supply shipping information.
4. Supply payment information.
5. Receive conformation number from salesperson.

These steps would generate this simple use case diagram:

This example shows the customer as a actor because the customer is using the ordering
system. The diagram takes the simple steps listed above and shows them as actions the
customer might perform. The salesperson could also be included in this use case
diagram because the salesperson is also interacting with the ordering system.

From this simple diagram the requirements of the ordering system can easily be derived.
The system will need to be able to perform actions for all of the use cases listed. As the
project progresses other use cases might appear. The customer might have a need to
add an item to an order that has already been placed. This diagram can easily be
expanded until a complete description of the ordering system is derived capturing all of the
requirements that the system will need to perform.

Interaction Diagram

Interaction diagrams model the behavior of use cases by describing the way groups of objects
interact to complete the task. The two kinds of interaction diagrams are sequence and
collaboration diagrams.

When to Use: Interaction Diagrams

Interaction diagrams are used when you want to model the behavior of several objects in
a use case. They demonstrate how the objects collaborate for the behavior. Interaction
diagrams do not give a in depth representation of the behavior. If you want to see what a
specific object is doing for several use cases use a state diagram. To see a particular
behavior over many use cases or threads use an activity diagrams.
How to Draw: Interaction Diagrams

Sequence diagrams, collaboration diagrams, or both diagrams can be used to

demonstrate the interaction of objects in a use case. Sequence diagrams generally show
the sequence of events that occur. Collaboration diagrams demonstrate how objects are
statically connected. Both diagrams are relatively simple to draw and contain similar
elements.

Basic Sequence Diagram Symbols and Notations

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.

Various message types for Sequence and Collaboration diagrams

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 [ ].

Sequence diagrams:

Sequence diagrams demonstrate the behavior of objects in a use case by

describing the objects and the messages they pass. the diagrams are read left
to right and descending. The example below shows an object of class 1 start the
behavior by sending a message to an object of class 2. Messages pass between
the different objects until the object of class 1 receives the final message.

Below is a slightly more complex example. The represents when the object is
destroyed. This diagrams also shows conditions for messages to be sent to
other object. The condition is listed between brackets next to the message. For
example, a [condition] has to be met before the object of class 2 can send a
message() to the object of class 3.

The next diagram shows the beginning of a sequence diagram for placing an
order. The object an Order Entry Window is created and sends a message to an
Order object to prepare the order. Notice the the names of the objects are
followed by a colon. The names of the classes the objects belong to do not have
to be listed. However the colon is required to denote that it is the name of an
object following the objectName:className naming system.

Next the Order object checks to see if the item is in stock and if the [InStock]
condition is met it sends a message to create an new Delivery Item object.

The next diagrams adds another conditional message to the Order object. If the
item is [OutOfStock] it sends a message back to the Order Entry Window object
stating that the object is out of stack.
This simple diagram shows the sequence that messages are passed between
objects to complete a use case for ordering an item.

Remember to use numbers in each sequence of actions.

Collaboration diagrams:

Collaboration diagrams are also relatively easy to draw. They show the
relationship between objects and the order of messages passed between them.
The objects are listed as icons and arrows indicate the messages being passed
between them. The numbers next to the messages are called sequence
numbers. As the name suggests, they show the sequence of the messages as
they are passed between the objects.

Basic Collaboration Diagram Symbols and Notations

Class roles

Class roles describe how objects behave. Use the UML object symbol to illustrate class roles, but don't list

object attributes.

Association roles

Association roles describe how an association will behave given a particular situation. You can draw

association roles using simple lines labeled with stereotypes.

Messages

Unlike sequence diagrams, collaboration diagrams do not have an explicit way to denote time and instead

number messages in order of execution. Sequence numbering can become nested using the Dewey

decimal system. For example, nested messages under the first message are labeled 1.1, 1.2, 1.3, and so
on. The a condition for a message is usually placed in square brackets immediately following the sequence

number. Use a * after the sequence number to indicate a loop.

There are many acceptable sequence numbering schemes in UML. A simple 1,

2, 3... format can be used, as the example below shows, or for more detailed and
complex diagrams a 1, 1.1 ,1.2, 1.2.1... scheme can be used.

The example below shows a simple collaboration diagram for the placing an
order use case. This time the names of the objects appear after the colon, such
as :Order Entry Window following the objectName:className naming
convention. This time the class name is shown to demonstrate that all of objects
of that class will behave the same way.
State Diagram

State diagrams are used to describe the behavior of a system. State diagrams describe all of the
possible states of an object as events occur. Each diagram usually represents objects of a single
class and track the different states of its objects through the system.

When to Use: State Diagrams

Use state diagrams to demonstrate the behavior of an object through many use cases of
the system. Only use state diagrams for classes where it is necessary to understand the
behavior of the object through the entire system. Not all classes will require a state
diagram and state diagrams are not useful for describing the collaboration of all objects in
a use case. State diagrams are other combined with other diagrams such as interaction
diagrams and activity diagrams.

Basic Statechart Diagram Symbols and Notations

States

States represent situations during the life of an object. You can easily illustrate a state in SmartDraw by
using a rectangle with rounded corners.

Transition

A solid arrow represents the path between different states of an object. Label the transition with the event
that triggered it and the action that results from it.

Initial State

A filled circle followed by an arrow represents the object's initial state.

Final State

An arrow pointing to a filled circle nested inside another circle represents the object's final state.

Synchronization and Splitting of Control

A short heavy bar with two transitions entering it represents a synchronization of control. A short heavy bar
with two transitions leaving it represents a splitting of control that creates multiple states.

How to Draw: State Diagrams

State diagrams have very few elements. The basic elements are rounded boxes
representing the state of the object and arrows indicting the transition to the next state.
The activity section of the state symbol depicts what activities the object will be doing
while it is in that state.
All state diagrams being with an initial state of the object. This is the state of the object
when it is created. After the initial state the object begins changing states. Conditions
based on the activities can determine what the next state the object transitions to.

Below is an example of a state diagram might look like for an Order object. When the
object enters the Checking state it performs the activity "check items." After the activity is
completed the object transitions to the next state based on the conditions [all items
available] or [an item is not available]. If an item is not available the order is canceled. If
all items are available then the order is dispatched. When the object transitions to the
Dispatching state the activity "initiate delivery" is performed. After this activity is complete
the object transitions again to the Delivered state.
State diagrams can also show a super-state for the object. A super-state is used when
many transitions lead to the a certain state. Instead of showing all of the transitions from
each state to the redundant state a super-state can be used to show that all of the states
inside of the super-state can transition to the redundant state. This helps make the state
diagram easier to read.

The diagram below shows a super-state. Both the Checking and Dispatching states can
transition into the Canceled state, so a transition is shown from a super-state named
Active to the state Cancel. By contrast, the state Dispatching can only transition to the
Delivered state, so we show an arrow only from the Dispatching state to the Delivered
state.

Activity Diagram

Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar to state
diagrams because activities are the state of doing something. The diagrams describe the state of
activities by showing the sequence of activities performed. Activity diagrams can show activities
that are conditional or parallel.

When to Use: Activity Diagrams

Activity diagrams should be used in conjunction with other modeling techniques such as
interaction diagrams and state diagrams. The main reason to use activity diagrams is to
model the workflow behind the system being designed. Activity Diagrams are also useful
for: analyzing a use case by describing what actions need to take place and when they
should occur; describing a complicated sequential algorithm; and modeling applications
with parallel processes.

However, activity diagrams should not take the place of interaction diagrams and state
diagrams. Activity diagrams do not give detail about how objects behave or how objects
collaborate.

Basic Activity Diagram Symbols and Notations

Action states

Action states represent the noninterruptible actions of objects. You can draw an action state in SmartDraw
using a rectangle with rounded corners.

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 that 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.
Initial State

A filled circle followed by an arrow represents the initial action state.

Final State

An arrow pointing to a filled circle nested inside another circle represents the final action state.

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."

Synchronization

A synchronization bar helps illustrate parallel transitions. Synchronization is also called forking and joining.
Swimlanes

Swimlanes group related activities into one column.

How to Draw: Activity Diagrams

Activity diagrams show the flow of activities through the system. Diagrams are read from
top to bottom and have branches and forks to describe conditions and parallel activities.
A fork is used when multiple activities are occurring at the same time. The diagram below
shows a fork after activity1. This indicates that both activity2 and activity3 are occurring at
the same time. After activity2 there is a branch. The branch describes what activities will
take place based on a set of conditions. All branches at some point are followed by a
merge to indicate the end of the conditional behavior started by that branch. After the
merge all of the parallel activities must be combined by a join before transitioning into the
final activity state.
Below is a possible activity diagram for processing an order. The diagram shows the flow
of actions in the system's workflow. Once the order is received the activities split into two
parallel sets of activities. One side fills and sends the order while the other handles the
billing. On the Fill Order side, the method of delivery is decided conditionally. Depending
on the condition either the Overnight Delivery activity or the Regular Delivery activity is
performed. Finally the parallel activities combine to close the order.
Physical Diagram

There are two types of physical diagrams: deployment diagrams and component diagrams.
Deployment diagrams show the physical relationship between hardware and software in a system.
Component diagrams show the software components of a system and how they are related to each
other. These relationships are called dependencies.

When to Use: Physical Diagrams

Physical diagrams are used when development of the system is complete. Physical
diagrams are used to give descriptions of the physical information about a system.

Basic Component Diagram Symbols and Notations

Component

A component is a physical building block of the system. It is represented as a rectangle with tabs.

Interface

An interface describes a group of operations used or created by components.

Dependencies

Draw dependencies among components using dashed arrows.

Example.
 • A simple example showing 3 dependent components

• The Web browser communicates customer orders to a shopping cart

• The shopping cart accesses a database for persistance and for transactions

Basic Deployment Diagram Symbols and Notations

Component

A node is a physical resource that executes code components.

Association

Association refers to a physical connection between nodes, such as Ethernet.

Components and Nodes

Place components inside the node that deploys them.

How to Draw: Physical Diagrams

Many times the deployment and component diagrams are combined into one physical
diagram. A combined deployment and component diagram combines the features of both
diagrams into one diagram.

The deployment diagram contains nodes and connections. A node usually represents a
piece of hardware in the system. A connection depicts the communication path used by
the hardware to communicate and usually indicates a method such as TCP/IP.
The component diagram contains components and dependencies. Components
represent the physical packaging of a module of code. The dependencies between the
components show how changes made to one component may affect the other
components in the system. Dependencies in a component diagram are represented by a
dashed line between two or more components. Component diagrams can also show the
interfaces used by the components to communicate to each other.

The combined deployment and component diagram below gives a high level physical
description of the completed system. The diagram shows two nodes which represent two
machines communicating through TCP/IP. Component2 is dependant on component1, so
changes to component 2 could affect component1. The diagram also depicts component3
interfacing with component1. This diagram gives the reader a quick overall view of the
entire system.

Example.

• Captures the distinct number of computers involved

• Shows the communication modes employed

 • Component diagrams can be embedded into deployment diagrams effectively

Note: For Examples on above

mentioned diagrams see Class notes.