Unit 2:

Basic Structural Modeling: Classes, Relationships, common Mechanisms, and diagrams.

Class &Object Diagrams: Terms, concepts, modelling techniques for Class & Object Diagrams.
Collaboration Diagrams: Terms, Concepts, depicting a message, polymorphism in collaboration Diagrams,
iterated messages, use of self in messages.
Sequence Diagrams: Terms, concepts, depicting asynchronous messages with/without priority, call-back
mechanism, broadcast messages.
Basic Behavioural Modeling: Use cases, Use case Diagrams, Activity Diagrams, State Machine , Process and
thread, Event and signals, Time diagram, interaction diagram, Package diagram.
Architectural Modeling: Component, Deployment, Component diagrams and Deployment diagrams.

The UML diagrams are categorized into structural diagrams, behavioral diagrams, and also
interaction overview diagrams. The diagrams are hierarchically classified in the following
figure:

1. Structural Diagrams

Structural diagrams depict a static view or structure of a system. It is widely used in the
documentation of software architecture. It embraces class diagrams, composite structure
diagrams, component diagrams, deployment diagrams, object diagrams, and package diagrams.
It presents an outline for the system. It stresses the elements to be present that are to be modeled.

o Class Diagram: Class diagrams are one of the most widely used diagrams. It is the
backbone of all the object-oriented software systems. It depicts the static structure of the
system. It displays the system's class, attributes, and methods. It is helpful in recognizing
the relation between different objects as well as classes.
o Composite Structure Diagram: The composite structure diagrams show parts within the
class. It displays the relationship between the parts and their configuration that ascertain
the behavior of the class. It makes full use of ports, parts, and connectors to portray the
 internal structure of a structured classifier. It is similar to class diagrams, just the fact it
represents individual parts in a detailed manner when compared with class diagrams.
o Object Diagram: It describes the static structure of a system at a particular point in time.
It can be used to test the accuracy of class diagrams. It represents distinct instances of
classes and the relationship between them at a time.
o Component Diagram: It portrays the organization of the physical components within the
system. It is used for modeling execution details. It determines whether the desired
functional requirements have been considered by the planned development or not, as it
depicts the structural relationships between the elements of a software system.
o Deployment Diagram: It presents the system's software and its hardware by telling what
the existing physical components are and what software components are running on
them. It produces information about system software. It is incorporated whenever
software is used, distributed, or deployed across multiple machines with dissimilar
configurations.
o Package Diagram: It is used to illustrate how the packages and their elements are
organized. It shows the dependencies between distinct packages. It manages UML
diagrams by making it easily understandable. It is used for organizing the class and use
case diagrams.

2. Behavioral Diagrams:

Behavioral diagrams portray a dynamic view of a system or the behavior of a system, which
describes the functioning of the system. It includes use case diagrams, state diagrams, and
activity diagrams. It defines the interaction within the system.

o State Machine Diagram: It is a behavioral diagram. it portrays the system's behavior

utilizing finite state transitions. It is also known as the State-charts diagram. It models
the dynamic behavior of a class in response to external stimuli.
o Activity Diagram: It models the flow of control from one activity to the other. With the
help of an activity diagram, we can model sequential and concurrent activities. It visually
depicts the workflow as well as what causes an event to occur.
o Use Case Diagram: It represents the functionality of a system by utilizing actors and use
cases. It encapsulates the functional requirement of a system and its association with
actors. It portrays the use case view of a system.

3. Interaction Diagrams

Interaction diagrams are a subclass of behavioral diagrams that give emphasis to object interactions
and also depicts the flow between various use case elements of a system. In simple words, it
shows how objects interact with each other and how the data flows within them. It consists of
communication, interaction overview, sequence, and timing diagrams.

o Sequence Diagram: It shows the interactions between the objects in terms of messages
exchanged over time. It delineates in what order and how the object functions are in a
system.
o Communication Diagram: It shows the interchange of sequence messages between the
objects. It focuses on objects and their relations. It describes the static and dynamic
behavior of a system.
 o Timing Diagram: It is a special kind of sequence diagram used to depict the object's
behavior over a specific period of time. It governs the change in state and object behavior
by showing the time and duration constraints.
o Interaction Overview diagram: It is a mixture of activity and sequence diagram that
depicts a sequence of actions to simplify the complex interactions into simple
interactions.

UML-Relationship

Relationships depict a connection between several things, such as structural, behavioral, or grouping
things in the unified modeling language. Since it is termed as a link, it demonstrates how things
are interrelated to each other at the time of system execution. It constitutes four types of
relationships, i.e., dependency, association, generalization, and realization.

Dependency

Whenever there is a change in either the structure or the behavior of the class that affects the other
class, such a relationship is termed as a dependency. Or, simply, we can say a class contained in
other class is known as dependency. It is a unidirectional relationship.

Links & Association Link

 It can be understood as the physical connection between objects.

 It helps tell about the relationship among objects.
 It is represented using line segment between objects.
 They can’t be referenced.
 It is used in UML designs.

Association

 It is a specification about the collection of links.

 The connections are related to classes.
 It is a general relationship between classes.
 They are implemented using programming languages as a reference model.
 It shows connections between classes using line segments.

Association relationship is a structural relationship in which different objects are linked within the
system. It exhibits a binary relationship between the objects representing an activity. It depicts
the relationship between objects, such as a teacher, can be associated with multiple teachers.

It is represented by a line between the classes followed by an arrow that navigates the direction, and
when the arrow is on both sides, it is then called a bidirectional association. We can specify the
multiplicity of an association by adding the adornments on the line that will denote the
association.

Example:

1) A single teacher has multiple students.

 2) A single student can associate with many teachers.

The composition and aggregation are two subsets of association. In both of the cases, the object of
one class is owned by the object of another class; the only difference is that in composition, the
child does not exist independently of its parent, whereas in aggregation, the child is not
dependent on its parent i.e., standalone. An aggregation is a special form of association, and
composition is the special form of aggregation.

Aggregation

Aggregation is a subset of association, is a collection of different things. It represents has a

relationship. It is more specific than an association. It describes a part-whole or part-of
relationship. It is a binary association, i.e., it only involves two classes. It is a kind of relationship
in which the child is independent of its parent.

For example:

Here we are considering a car and a wheel example. A car cannot move without a wheel. But the
wheel can be independently used with the bike, scooter, cycle, or any other vehicle. The wheel
object can exist without the car object, which proves to be an aggregation relationship.

Composition

The composition is a part of aggregation, and it portrays the whole-part relationship. It depicts
dependency between a composite (parent) and its parts (children), which means that if the
composite is discarded, so will its parts get deleted. It exists between similar objects.

As you can see from the example given below, the composition association relationship connects the
Person class with Brain class, Heart class, and Legs class. If the person is destroyed, the brain,
heart, and legs will also get discarded.
Association vs. Aggregation vs. Composition

Association Aggregation Composition

Association relationship Aggregation relationship is The composition relationship is

is represented using an represented by a straight line represented by a straight line
arrow. with an empty diamond at one with a black diamond at one end.
end.

In UML, it can exist It is a part of the association It is a part of the aggregation

between two or more relationship. relationship.
classes.
It incorporates one-to- It exhibits a kind of weak It exhibits a strong type of
one, one-to-many, many- relationship. relationship.
to-one, and many-to-
many association
between the classes.
It can associate one more In an aggregation relationship, In a composition relationship,
objects together. the associated objects exist the associated objects cannot
independently within the scope exist independently within the
of the system. scope of the system.
In this, objects are linked In this, the linked objects are Here the linked objects are
together. independent of each other. dependent on each other.
It may or may not affect Deleting one element in the It affects the other element if
the other associated aggregation relationship does one of its associated element is
element if one element is not affect other associated deleted.
deleted. elements.
Example: A tutor can Example: A car needs a wheel Example: If a file is placed in a
associate with multiple for its proper functioning, but folder and that is folder is
students, or one student it may not require the same deleted. The file residing inside
can associate with wheel. It may function with that folder will also get deleted
multiple teachers. another wheel as well. at the time of folder deletion.
UML-Generalization

In UML modeling, a generalization relationship is a relationship that implements the concept of

object orientation called inheritance. The generalization relationship occurs between two entities
or objects, such that one entity is the parent, and the other one is the child. The child inherits the
functionality of its parent and can access as well as update it.

Generalization relationship is utilized in class, component, deployment, and use case diagrams to
specify that the child inherits actions, characteristics, and relationships from its parent.

To meet UML's standard, it necessitates usage of the same types of model elements in the
generalization relationship, i.e., generalization relation can either be used between actors or
between use cases, but not between an actor and a use case.

The generalization relationship is incorporated to record attributes, operations, and relationships

in a parent model element so that it can be inherited in one or more child model elements.

The parent model element can have as many children, and also, the child can have one or more
parents. But most commonly, it can be seen that there is one parent model element and multiple
child model elements. The generalization relationship does not consist of names. The
generalization relationship is represented by a solid line with a hollow arrowhead pointing
towards the parent model element from the child model element.

Example:

As we know, the bank account can be of two types; Savings Account and Credit Card Account.
Both the savings and the credit card account inherits the generalized properties from the Bank
Account, which is Account Number, Account Balance, etc.
Generalization and specialization :

Generalization and specialization represent a hierarchy of relationships between classes, where

subclasses inherit from super-classes.

1. Generalization : i. In the generalization process, the common characteristics of classes are

combined to form a class in a higher level of hierarchy, i.e., subclasses are combined to form a
generalized super-class. ii. It represents an “is - a - kind - of” relationship. For example, “car is a
kind of land vehicle”, or “ship is a kind of water vehicle”.

2. Specialization : i. Specialization is the reverse process of generalization. Here, the

distinguishing features of groups of objects are used form specialized classes from existing
classes. ii. It can be said that the subclasses are the specialized versions of the super-class. The
following figure shows an example of generalization and specialization.

Q Categorize the following relationship into generalization, aggregation, or association :

1. A country has a capital city 2. Files contain records.

Answer 1. A country has a capital city : It is an association relationship. A capital city and a
country are distinct things so generalization certainly does not apply. You could argue that a
capital city is a part of a country and thus they are related by aggregation.

2. Files contain records : It is an aggregation relationship. The word “contain” is a clue that the
relationship may be aggregation. A record is a part of a file. Some attributes and operations on
files propagate to their constituent record

UML-Realization

In UML modeling, the realization is a relationship between two objects, where the client (one
model element) implements the responsibility specified by the supplier (another model element).
The realization relationship can be employed in class diagrams and components diagrams.
The realization relationship does not have names. It is mostly found in the interfaces. It is
represented by a dashed line with a hollow arrowhead at one end that points from the client to
the server.

Interface Realization

Interface realization is a kind of specialized relation between the classifier and the interface. In
interface realization relationship, realizing classifiers conforms to the contract defined by the
interface.

A classifier implementing an interface identifies the objects that conform to the interface and any
of its ancestors. A classifier can execute one or more interfaces. The set of interfaces that are
implemented by the classifier are its given interfaces. The given interfaces are the set of services
offered by the classifiers to its clients.

The interface realization relationship does not contain names, and if you name it, then the name
will appear beside the connector in the diagram.

The interface realization relationship is represented by a dashed line with a hollow arrowhead,
which points from the classifier to the given interface.

UML Class Diagram

The class diagram depicts a static view of an application. It represents the types of objects
residing in the system and the relationships between them. A class consists of its objects, and
also it may inherit from other classes. A class diagram is used to visualize, describe, document
various different aspects of the system, and also construct executable software code.

It shows the attributes, classes, functions, and relationships to give an overview of the software
system. It constitutes class names, attributes, and functions in a separate compartment that helps
in software development. Since it is a collection of classes, interfaces, associations,
collaborations, and constraints, it is termed as a structural diagram.

Purpose of Class Diagrams

The main purpose of class diagrams is to build a static view of an application. It is the only
diagram that is widely used for construction, and it can be mapped with object-oriented
languages. It is one of the most popular UML diagrams. Following are the purpose of class
diagrams given below:

1. It analyses and designs a static view of an application.

2. It describes the major responsibilities of a system.
3. It is a base for component and deployment diagrams.
4. It incorporates forward and reverse engineering.
Benefits of Class Diagrams

1. It can represent the object model for complex systems.

2. It reduces the maintenance time by providing an overview of how an application is
structured before coding.
3. It provides a general schematic of an application for better understanding.
4. It represents a detailed chart by highlighting the desired code, which is to be
programmed.
5. It is helpful for the stakeholders and the developers.

Vital components of a Class Diagram

The class diagram is made up of three sections:

o Upper Section: The upper section encompasses the name of the class. A class is a
representation of similar objects that shares the same relationships, attributes, operations,
and semantics. Some of the following rules that should be taken into account while
representing a class are given below:
a. Capitalize the initial letter of the class name.
b. Place the class name in the center of the upper section.
c. A class name must be written in bold format.
d. The name of the abstract class should be written in italics format.
Middle Section: The middle section constitutes the attributes, which describe the quality
of the class. The attributes have the following characteristics:
. The attributes are written along with its visibility factors, which are public (+), private (-),
protected (#), and package (~).
a. The accessibility of an attribute class is illustrated by the visibility factors.
b. A meaningful name should be assigned to the attribute, which will explain its
usage inside the class.
Lower Section: The lower section contain methods or operations. The methods are
represented in the form of a list, where each method is written in a single line. It demonstrates
how a class interacts with data.

How to draw a Class Diagram?

The class diagram is used most widely to construct software applications. It not only represents a
static view of the system but also all the major aspects of an application. A collection of class
diagrams as a whole represents a system.

Some key points that are needed to keep in mind while drawing a class diagram are given below:
 1. To describe a complete aspect of the system, it is suggested to give a meaningful name to
the class diagram.
2. The objects and their relationships should be acknowledged in advance.
3. The attributes and methods (responsibilities) of each class must be known.
4. A minimum number of desired properties should be specified as more number of the
unwanted property will lead to a complex diagram.
5. Notes can be used as and when required by the developer to describe the aspects of a
diagram.
6. The diagrams should be redrawn and reworked as many times to make it correct before
producing its final version.

Class Diagram Example

A class diagram describing the sales order system is given below.

Usage of Class diagrams

The class diagram is used to represent a static view of the system. It plays an essential role in the
establishment of the component and deployment diagrams. It helps to construct an executable
code to perform forward and backward engineering for any system, or we can say it is mainly
used for construction. It represents the mapping with object-oriented languages that are C++,
Java, etc. Class diagrams can be used for the following purposes:

1. To describe the static view of a system.

2. To show the collaboration among every instance in the static view.
3. To describe the functionalities performed by the system.
4. To construct the software application using object-oriented languages.
UML Object Diagram

Object diagrams are dependent on the class diagram as they are derived from the class diagram. It
represents an instance of a class diagram. The objects help in portraying a static view of an
object-oriented system at a specific instant.

Both the object and class diagram are similar to some extent; the only difference is that the class
diagram provides an abstract view of a system. It helps in visualizing a particular functionality of
a system.

Notation of an Object Diagram

Purpose of Object Diagram

The object diagram holds the same purpose as that of a class diagram. The class diagram provides an
abstract view which comprises of classes and their relationships, whereas the object diagram
represents an instance at a particular point of time.

The object diagram is actually similar to the concrete (actual) system behavior. The main purpose is
to depict a static view of a system.

Following are the purposes enlisted below:

o It is used to perform forward and reverse engineering.

o It is used to understand object behavior and their relationships practically.
o It is used to get a static view of a system.
o It is used to represent an instance of a system.

Example of Object Diagram

How to draw an Object Diagram?

1. All the objects present in the system should be examined before start drawing the object
diagram.
2. Before creating the object diagram, the relation between the objects must be
acknowledged.
3. The association relationship among the entities must be cleared already.
 4. To represent the functionality of an object, a proper meaningful name should be assigned.
5. The objects are to be examined to understand its functionality.

Q Give the general layout of a class diagram. Also prepare a class diagram for the instance
diagram shown in the Fig. 2.9.1. Explain your multiplicity decisions. How does your diagram express
the fact that points are in sequence ?

Solution :

UML Use Case Diagram

A use case diagram is used to represent the dynamic behavior of a system. It encapsulates the
system's functionality by incorporating use cases, actors, and their relationships. It models the
tasks, services, and functions required by a system/subsystem of an application. It depicts the
high-level functionality of a system and also tells how the user handles a system.

Purpose of Use Case Diagrams

The main purpose of a use case diagram is to portray the dynamic aspect of a system. It accumulates
the system's requirement, which includes both internal as well as external influences. It invokes
persons, use cases, and several things that invoke the actors and elements accountable for the
implementation of use case diagrams. It represents how an entity from the external environment
can interact with a part of the system.

Following are the purposes of a use case diagram given below:

1. It gathers the system's needs.

2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.

How to draw a Use Case diagram?

It is essential to analyze the whole system before starting with drawing a use case diagram, and
then the system's functionalities are found. And once every single functionality is identified, they
are then transformed into the use cases to be used in the use case diagram.

After that, we will enlist the actors that will interact with the system. The actors are the person or
a thing that invokes the functionality of a system. It may be a system or a private entity, such that
it requires an entity to be pertinent to the functionalities of the system to which it is going to
interact.

Once both the actors and use cases are enlisted, the relation between the actor and use case/
system is inspected. It identifies the no of times an actor communicates with the system.
Basically, an actor can interact multiple times with a use case or system at a particular instance
of time.

Following are some rules that must be followed while drawing a use case diagram:

1. A pertinent and meaningful name should be assigned to the actor or a use case of a
system.
2. The communication of an actor with a use case must be defined in an understandable
way.
3. Specified notations to be used as and when required.
4. The most significant interactions should be represented among the multiple no of
interactions between the use case and actors.

Example of a Use Case Diagram

A use case diagram depicting the Online Shopping website is given below.

Here the Web Customer actor makes use of any online shopping website to purchase online. The
top-level uses are as follows; View Items, Make Purchase, Checkout, Client Register. The View
Items use case is utilized by the customer who searches and view products. The Client
Register use case allows the customer to register itself with the website for availing gift
vouchers, coupons, or getting a private sale invitation. It is to be noted that the Checkout is an
included use case, which is part of Making Purchase, and it is not available by itself.

The View Items is further extended by several use cases such as; Search Items, Browse Items,
View Recommended Items, Add to Shopping Cart, Add to Wish list. All of these extended use
cases provide some functions to customers, which allows them to search for an item. The View
Items is further extended by several use cases such as; Search Items, Browse Items, View
Recommended Items, Add to Shopping Cart, Add to Wish list. All of these extended use cases
provide some functions to customers, which allows them to search for an item.

Both View Recommended Item and Add to Wish List include the Customer Authentication
use case, as they necessitate authenticated customers, and simultaneously item can be added to
the shopping cart without any user authentication.

Following are some important tips that are to be kept in mind while drawing a use case diagram:

1. A simple and complete use case diagram should be articulated.

2. A use case diagram should represent the most significant interaction among the multiple
interactions.
3. At least one module of a system should be represented by the use case diagram.
4. If the use case diagram is large and more complex, then it should be drawn more
generalized.

Sequence Diagram

The sequence diagram represents the flow of messages in the system and is also termed as an
event diagram. It helps in envisioning several dynamic scenarios. It portrays the communication
between any two lifelines as a time-ordered sequence of events, such that these lifelines took part
at the run time. In UML, the lifeline is represented by a vertical bar, whereas the message flow is
represented by a vertical dotted line that extends across the bottom of the page. It incorporates
the iterations as well as branching.

Purpose of a Sequence Diagram

1. To model high-level interaction among active objects within a system.

2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.

Notations of a Sequence Diagram

Lifeline

An individual participant in the sequence diagram is represented by a lifeline. It is positioned at

the top of the diagram.

Actor

A role played by an entity that interacts with the subject is called as an actor. It is out of the
scope of the system. It represents the role, which involves human users and external hardware or
subjects. An actor may or may not represent a physical entity, but it purely depicts the role of an
entity. Several distinct roles can be played by an actor or vice versa.

Activation

It is represented by a thin rectangle on the lifeline. It describes that time period in which an
operation is performed by an element, such that the top and the bottom of the rectangle is
associated with the initiation and the completion time, each respectively.

Messages

The messages depict the interaction between the objects and are represented by arrows. They are
in the sequential order on the lifeline. The core of the sequence diagram is formed by messages
and lifelines.

Following are types of messages enlisted below:

o Call Message: It defines a particular communication between the lifelines of an

interaction, which represents that the target lifeline has invoked an operation.

o Return Message: It defines a particular communication between the lifelines of

interaction that represent the flow of information from the receiver of the corresponding
 caller message.

o Self Message: It describes a communication, particularly between the lifelines of an

interaction that represents a message of the same lifeline, has been invoked.

o Destroy Message: It describes a communication, particularly between the lifelines of an

interaction that depicts a request to destroy the lifecycle of the target.

o Duration Message: It describes a communication particularly between the lifelines of an

interaction, which portrays the time passage of the message while modeling a system.

An example of a high-level sequence diagram for mail server is given below..

Benefits of a Sequence Diagram

1. It explores the real-time application.

2. It depicts the message flow between the different objects.
3. It has easy maintenance.
4. It is easy to generate.
5. Implement both forward and reverse engineering.
6. It can easily update as per the new change in the system.

The drawback of a Sequence Diagram

1. In the case of too many lifelines, the sequence diagram can get more complex.
2. The incorrect result may be produced, if the order of the flow of messages changes.
3. Since each sequence needs distinct notations for its representation, it may make the
diagram more complex.
4. The type of sequence is decided by the type of message.

UML Collaboration Diagram

The collaboration diagram is used to show the relationship between the objects in a system. Both
the sequence and the collaboration diagrams represent the same information but differently.
Instead of showing the flow of messages, it depicts the architecture of the object residing in the
system as it is based on object-oriented programming. An object consists of several features.
Multiple objects present in the system are connected to each other. The collaboration diagram,
which is also known as a communication diagram, is used to portray the object's architecture in
the system.

Notations of a Collaboration Diagram

Following are the components of a component diagram that are enlisted below:

1. Objects: The representation of an object is done by an object symbol with its name and
class underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
 o The object is represented by specifying their name and class.
o It is not mandatory for every class to appear.
o A class may constitute more than one object.
o In the collaboration diagram, firstly, the object is created, and then its class is
specified.
o To differentiate one object from another object, it is necessary to name them.
2. Actors: In the collaboration diagram, the actor plays the main role as it invokes the
interaction. Each actor has its respective role and name. In this, one actor initiates the use
case.
3. Links: The link is an instance of association, which associates the objects and actors. It
portrays a relationship between the objects through which the messages are sent. It is
represented by a solid line. The link helps an object to connect with or navigate to
another object, such that the message flows are attached to links.
4. Messages: It is a communication between objects which carries information and includes
a sequence number, so that the activity may take place. It is represented by a labeled
arrow, which is placed near a link. The messages are sent from the sender to the receiver,
and the direction must be navigable in that particular direction. The receiver must
understand the message.

When to use a Collaboration Diagram?

The collaborations are used when it is essential to depict the relationship between the object.
Both the sequence and collaboration diagrams represent the same information, but the way of
portraying it quite different. The collaboration diagrams are best suited for analyzing use cases.

Following are some of the use cases enlisted below for which the collaboration diagram is
implemented:
 1. To model collaboration among the objects or roles that carry the functionalities of use
cases and operations.
2. To model the mechanism inside the architectural design of the system.
3. To capture the interactions that represent the flow of messages between the objects and
the roles inside the collaboration.
4. To model different scenarios within the use case or operation, involving a collaboration
of several objects and interactions.
5. To support the identification of objects participating in the use case.
6. In the collaboration diagram, each message constitutes a sequence number, such that the
top-level message is marked as one and so on. The messages sent during the same call are
denoted with the same decimal prefix, but with different suffixes of 1, 2, etc. as per their
occurrence.

Steps for creating a Collaboration Diagram

1. Determine the behavior for which the realization and implementation are specified.
2. Discover the structural elements that are class roles, objects, and subsystems for
performing the functionality of collaboration.
o Choose the context of an interaction: system, subsystem, use case, and operation.
3. Think through alternative situations that may be involved.
o Implementation of a collaboration diagram at an instance level, if needed.
o A specification level diagram may be made in the instance level sequence
diagram for summarizing alternative situations.

Example of a Collaboration Diagram

Benefits of a Collaboration Diagram

1. The collaboration diagram is also known as Communication Diagram.

2. It mainly puts emphasis on the structural aspect of an interaction diagram, i.e., how
lifelines are connected.
 3. The syntax of a collaboration diagram is similar to the sequence diagram; just the
difference is that the lifeline does not consist of tails.
4. The messages transmitted over sequencing is represented by numbering each individual
message.
5. The collaboration diagram is semantically weak in comparison to the sequence diagram.
6. The special case of a collaboration diagram is the object diagram.
7. It focuses on the elements and not the message flow, like sequence diagrams.
8. Since the collaboration diagrams are not that expensive, the sequence diagram can be
directly converted to the collaboration diagram.
9. There may be a chance of losing some amount of information while implementing a
collaboration diagram with respect to the sequence diagram.

The drawback of a Collaboration Diagram

1. Multiple objects residing in the system can make a complex collaboration diagram, as it
becomes quite hard to explore the objects.
2. It is a time-consuming diagram.
3. After the program terminates, the object is destroyed.
4. As the object state changes momentarily, it becomes difficult to keep an eye on every
single that has occurred inside the object of a system.

UML Activity Diagram

In UML, the activity diagram is used to demonstrate the flow of control within the system rather
than the implementation. It models the concurrent and sequential activities.

The activity diagram helps in envisioning the workflow from one activity to another. It put emphasis
on the condition of flow and the order in which it occurs. The flow can be sequential, branched,
or concurrent, and to deal with such kinds of flows, the activity diagram has come up with a fork,
join, etc.

It is also termed as an object-oriented flowchart. It encompasses activities composed of a set of

actions or operations that are applied to model the behavioral diagram.

Components of an Activity Diagram

Following are the component of an activity diagram:

Activities

The categorization of behavior into one or more actions is termed as an activity. In other words, it
can be said that an activity is a network of nodes that are connected by edges. The edges depict
the flow of execution. It may contain action nodes, control nodes, or object nodes.

The control flow of activity is represented by control nodes and object nodes that illustrates the
objects used within an activity. The activities are initiated at the initial node and are terminated at
the final node.
Notation of an Activity diagram

Activity diagram constitutes following notations:

Initial State: It depicts the initial stage or beginning of the set of actions.

Final State: It is the stage where all the control flows and object flows end.

Decision Box: It makes sure that the control flow or object flow will follow only one path.

Action Box: It represents the set of actions that are to be performed.

Why use Activity Diagram?

An event is created as an activity diagram encompassing a group of nodes associated with edges.
To model the behavior of activities, they can be attached to any modeling element. It can model
use cases, classes, interfaces, components, and collaborations.

It mainly models processes and workflows. It envisions the dynamic behavior of the system as
well as constructs a runnable system that incorporates forward and reverse engineering. It does
not include the message part, which means message flow is not represented in an activity
diagram.

It is the same as that of a flowchart but not exactly a flowchart itself. It is used to depict the flow
between several activities.
How to draw an Activity Diagram?

An activity diagram is a flowchart of activities, as it represents the workflow among various

activities. They are identical to the flowcharts, but they themself are not exactly the flowchart. In
other words, it can be said that an activity diagram is an enhancement of the flowchart, which
encompasses several unique skills.

Since it incorporates swimlanes, branching, parallel flows, join nodes, control nodes, and forks,
it supports exception handling. A system must be explored as a whole before drawing an activity
diagram to provide a clearer view of the user. All of the activities are explored after they are
properly analyzed for finding out the constraints applied to the activities. Each and every
activity, condition, and association must be recognized.

After gathering all the essential information, an abstract or a prototype is built, which is then
transformed into the actual diagram.

Following are the rules that are to be followed for drawing an activity diagram:

1. A meaningful name should be given to each and every activity.

2. Identify all of the constraints.
3. Acknowledge the activity associations.

Example of an Activity Diagram

An example of an activity diagram showing the business flow activity of order processing is
given below.

Here the input parameter is the Requested order, and once the order is accepted, all of the
required information is then filled, payment is also accepted, and then the order is shipped. It
permits order shipment before an invoice is sent or payment is completed.

When to use an Activity Diagram?

An activity diagram can be used to portray business processes and workflows. Also, it used for
modeling business as well as the software. An activity diagram is utilized for the followings:

1. To graphically model the workflow in an easier and understandable way.

2. To model the execution flow among several activities.
3. To model comprehensive information of a function or an algorithm employed within the
system.
4. To model the business process and its workflow.
5. To envision the dynamic aspect of a system.
6. To generate the top-level flowcharts for representing the workflow of an application.
7. To represent a high-level view of a distributed or an object-oriented system.

UML Component Diagram

A component diagram is used to break down a large object-oriented system into the smaller
components, so as to make them more manageable. It models the physical view of a system such
as executables, files, libraries, etc. that resides within the node.

It visualizes the relationships as well as the organization between the components present in the
system. It helps in forming an executable system. A component is a single unit of the system,
which is replaceable and executable. The implementation details of a component are hidden, and
it necessitates an interface to execute a function. It is like a black box whose behavior is
explained by the provided and required interfaces.

Notation of a Component Diagram

a) A component

b) A node

Purpose of a Component Diagram

Since it is a special kind of a UML diagram, it holds distinct purposes. It describes all the
individual components that are used to make the functionalities, but not the functionalities of the
system. It visualizes the physical components inside the system. The components can be a
library, packages, files, etc.

The component diagram also describes the static view of a system, which includes the
organization of components at a particular instant. The collection of component diagrams
represents a whole system.

The main purpose of the component diagram are enlisted below:

1. It envisions each component of a system.

2. It constructs the executable by incorporating forward and reverse engineering.
3. It depicts the relationships and organization of components.

Why use Component Diagram?

The component diagrams have remarkable importance. It is used to depict the functionality and
behavior of all the components present in the system, unlike other diagrams that are used to
represent the architecture of the system, working of a system, or simply the system itself.

In UML, the component diagram portrays the behavior and organization of components at any
instant of time. The system cannot be visualized by any individual component, but it can be by
the collection of components.

Following are some reasons for the requirement of the component diagram:

1. It portrays the components of a system at the runtime.

2. It is helpful in testing a system.
3. It envisions the links between several connections.

When to use a Component Diagram?

It represents various physical components of a system at runtime. It is helpful in visualizing the

structure and the organization of a system. It describes how individual components can together
form a single system. Following are some reasons, which tells when to use component diagram:

1. To divide a single system into multiple components according to the functionality.

2. To represent the component organization of the system.

How to Draw a Component Diagram?

The component diagram is helpful in representing the physical aspects of a system, which are
files, executables, libraries, etc. The main purpose of a component diagram is different from that
of other diagrams. It is utilized in the implementation phase of any application.

Once the system is designed employing different UML diagrams, and the artifacts are prepared,
the component diagram is used to get an idea of implementation. It plays an essential role in
implementing applications efficiently.

Following are some artifacts that are needed to be identified before drawing a component
diagram:
 1. What files are used inside the system?
2. What is the application of relevant libraries and artifacts?
3. What is the relationship between the artifacts?

Following are some points that are needed to be kept in mind after the artifacts are identified:

1. Using a meaningful name to ascertain the component for which the diagram is about to
be drawn.
2. Before producing the required tools, a mental layout is to be made.
3. To clarify the important points, notes can be incorporated.

Example of a Component Diagram

A component diagram for an online shopping system is given below:

Where to use Component Diagrams?

The component diagram is a special purpose diagram, which is used to visualize the static
implementation view of a system. It represents the physical components of a system, or we can
say it portrays the organization of the components inside a system. The components, such as
libraries, files, executables, etc. are first needed to be organized before the implementation.

The component diagram can be used for the followings:

1. To model the components of the system.

2. To model the schemas of a database.
 3. To model the applications of an application.
4. To model the system's source code.

UML Deployment Diagram

The deployment diagram visualizes the physical hardware on which the software will be deployed. It
portrays the static deployment view of a system. It involves the nodes and their relationships.

It ascertains how software is deployed on the hardware. It maps the software architecture created in
design to the physical system architecture, where the software will be executed as a node. Since
it involves many nodes, the relationship is shown by utilizing communication paths.

Purpose of Deployment Diagram

The main purpose of the deployment diagram is to represent how software is installed on the
hardware component. It depicts in what manner a software interacts with hardware to perform its
execution.

Both the deployment diagram and the component diagram are closely interrelated to each other as
they focus on software and hardware components. The component diagram represents the
components of a system, whereas the deployment diagram describes how they are actually
deployed on the hardware.

The deployment diagram does not focus on the logical components of the system, but it put its
attention on the hardware topology.

Following are the purposes of deployment diagram enlisted below:

1. To envision the hardware topology of the system.

2. To represent the hardware components on which the software components are installed.
3. To describe the processing of nodes at the runtime.

Symbol and notation of Deployment diagram

The deployment diagram consist of the following notations:

1. A component
2. An artifact
3. An interface
4. A node
How to draw a Deployment Diagram?

The deployment diagram portrays the deployment view of the system. It helps in visualizing the
topological view of a system. It incorporates nodes, which are physical hardware. The nodes are
used to execute the artifacts. The instances of artifacts can be deployed on the instances of nodes.

Since it plays a critical role during the administrative process, it involves the following parameters:

1. High performance
2. Scalability
3. Maintainability
4. Portability
5. Easily understandable

One of the essential elements of the deployment diagram is the nodes and artifacts. So it is necessary
to identify all of the nodes and the relationship between them. It becomes easier to develop a
deployment diagram if all of the nodes, artifacts, and their relationship is already known.

Example of a Deployment diagram

A deployment diagram for the Apple iTunes application is given below.

The iTunes setup can be downloaded from the iTunes website, and also it can be installed on the
home computer. Once the installation and the registration are done, iTunes application can easily
interconnect with the Apple iTunes store. Users can purchase and download music, video, TV
serials, etc. and cache it in the media library.
Devices like Apple iPod Touch and Apple iPhone can update its own media library from the
computer with iTunes with the help of USB or simply by downloading media directly from the
Apple iTunes store using wireless protocols, for example; Wi-Fi, 3G, or EDGE.

When to use a Deployment Diagram?

The deployment diagram is mostly employed by network engineers, system administrators, etc.
with the purpose of representing the deployment of software on the hardware system. It
envisions the interaction of the software with the hardware to accomplish the execution. The
selected hardware must be of good quality so that the software can work more efficiently at a
faster rate by producing accurate results in no time.

The software applications are quite complex these days, as they are standalone, distributed, web-
based, etc. So, it is very necessary to design efficient software.

Deployment diagrams can be used for the followings:

1. To model the network and hardware topology of a system.

2. To model the distributed networks and systems.
3. Implement forwarding and reverse engineering processes.
4. To model the hardware details for a client/server system.
5. For modeling the embedded system.

What is a package diagram?

 Package diagrams are structural diagrams used to show the organization and arrangement of
various model elements in the form of packages. A package is a grouping of related UML
elements, such as diagrams, documents, classes, or even other packages. Each element is nested
within the package, which is depicted as a file folder within the diagram, then arranged
hierarchically within the diagram. Package diagrams are most commonly used to provide a visual
organization of the layered architecture within any UML classifier, such as a software system.

Benefits of a package diagram

A well-designed package diagram provides numerous benefits to those looking to create a

visualization of their UML system or project.
 They provide a clear view of the hierarchical structure of the various UML elements within
a given system.
 These diagrams can simplify complex class diagrams into well-ordered visuals.
 They offer valuable high-level visibility into large-scale projects and systems.
 Package diagrams can be used to visually clarify a wide variety of projects and systems.
 These visuals can be easily updated as systems and projects evolve.

Here are the basic components you’ll find within a package diagram:
 Package: A namespace used to group together logically related elements within a
system. Each element contained within the package should be a packageable element and
have a unique name.
 Packageable element: A named element, possibly owned directly by a package. These can
include events, components, use cases, and packages themselves. Packageable elements can
also be rendered as a rectangle within a package, labeled with the appropriate name.
 Dependencies: A visual representation of how one element (or set of elements) depends on
or influences another. Dependencies are divided into two groups: access and import
dependencies. (See next section for more info.)
 Element import: A directed relationship between an importing namespace and an imported
packageable element. This is used to import select individual elements without resorting to
a package import and without making it public within the namespace.
 Package import: A directed relationship between and importing namespace and an
imported package. This type of directed relationship adds the names of the members of the
imported package to its own namespace
 Package merge: A directed relationship in which the contents of one package are extended by
the contents of another. Essentially, the content of two packages are combined to produce a
new package.


