UML BEHAVIOURAL DIAGRAMS

UML behavioral diagrams visualize, specify, construct, and document the dynamic aspects of a
system. The behavioral diagrams are categorized as follows: use case diagrams, interaction
diagrams, state–chart diagrams, and activity diagrams.

Use Case Model

a Use case
A use case describes the sequence of actions a system performs yielding visible results. It shows
the interaction of things outside the system with the system itself. Use cases may be applied to the
whole system as well as a part of the system.

b Actor
An actor represents the roles that the users of the use cases play. An actor may be a person
e. g. student, customer, a device e. g. workstation, or another system e. g. bank, institution.

The following figure shows the notations of an actor named Student and a use case called
Generate Performance Report.

c Use case diagrams

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.

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 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:

Sequence Diagrams
Collaboration Diagrams

Interaction diagrams are used for modeling:

the control flow by time ordering using sequence diagrams.

the control flow of organization using collaboration diagrams.

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.

Example : A sequence diagram for the Automated Trading House System is shown in the following
figure.
Collaboration Diagrams
Collaboration diagrams are interaction diagrams that illustrate the structure of the objects that
send and receive messages.

Notations : In these diagrams, the objects that participate in the interaction are shown using
vertices. The links that connect the objects are used to send and receive messages. The message
is shown as a labeled arrow.

Example : Collaboration diagram for the Automated Trading House System is illustrated in the
figure below.

State–Chart Diagrams
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.

Activity Diagrams
An activity diagram depicts the flow of activities which are ongoing non-atomic operations in a
state machine. Activities result in actions which are atomic operations.

Activity diagrams comprise of:

Activity states and action states

Transitions
Objects

Activity diagrams are used for modeling:

workflows as viewed by actors, interacting with the system.
details of operations or computations using flowcharts.

Example

The following figure shows an activity diagram of a portion of the Automated Trading House
System.
Loading [MathJax]/jax/output/HTML-CSS/jax.js
2.7.1 Package Diagram

In the section 2.3.4, you have learnt about the class diagram. Generally, a single class
diagram can contain too many classes. UML permits us to place a set of related
classes together into a group is called package. It is a kind of structural diagram that
displays the system's structure at the level of packages. A package is used for
organizing elements into groups. A package can have a sub package also. The
package diagram can display structure as well as dependencies between sub-systems.
This diagram is used two types of dependencies as import and access. The
dependencies are shown by using dotted arrows like in figure-2.15. In import
dependency, functionality has been imported from one package to another, while
access dependency designates that one package needs assistance from the functions
of another package. For example, many packages have only library files i.e. lib
directory and these types of packages are used by other packages. You can just import
and use it in your application. It is a depending package that your package needs in
order to work. Sometimes your package is accessed by another package, or a package
that is dependent on your package is called a dependent package. A plus sign (+)
within a circle is drawn at the end attached to the package indicating that the package
has branches or sub-packages.

Figure 2.15: Package and dependencies

Package is more helpful to organize a large model. Packages are supported by Java.
Classes in one package cannot access the classes and services in another package
unless the package is imported.
A package is depicted as a folder and is displayed as a rectangle with a tab at the top
left. You must define a package name that differentiates it from other packages; it
comes on the tab or inside the rectangle. You can define a package name as a simple
text string is known as a simple name or defined as a qualified name. A package may
own other elements, including classes, interfaces, components, nodes, collaborations,
use cases, diagrams, and other packages. Ownership is a composite relationship which
means that the element is declared in the package. If the package is destroyed, it
means all the elements of that package are destroyed. Every element is uniquely
owned by exactly one package.
Basic components of a package diagram
Package is a namespace used to combine logically related elements within a system
and each element should be a packageable element that consists of components, use
cases, and packages themselves. The basic components of the packages are package,
import, access, use and merge. These basic elements are shown in figure-2.16. A
keyword “import” and “access” is used in package diagram as a dashed arrow that
indicates accessing type of package. The keyword ‘import’ is used for a public
package import and “access” for a private package import. By default, it is public. A
package merge component is directed relationship in which the contents of one
package are extended by the contents of another package. Basically, the contents of
the two packages are logically combined to produce a new package. For example, Cart
is a combined package, as shown in figure-2.16.
Visibility of Package
The visibility of the package element can only be public or private, which indicates by
"+" for public and "-" for private. Protected or package visibility is not allowed. The
public visibility of a package will be visible outside the package, whereas private
visibility of a package will not be visible outside.
Package diagram example
The following package diagram illustrates you how packages are interconnected for
importing and accessing data. The package diagram shows five elements: package,
import, access, use, and merge. The package diagram shown in figure 2.16 consists
of Web Store and Book Store packages. These two packages merge the Cart package
and use the Payment package. The Payment and Cart package import the packages
like the Customer and Inventory package.

Figure 2.16: Package Diagram