UNIT- 4

Class Design and Class Diagrams

I. Essentials of UML Class Diagrams

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.

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.

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

Visibility
Visibility allows to constrain the usage of a named element, either in namespaces or in
access to the element. It is used with classes, packages, generalizations, element
import, package import.

UML has the following types of visibility:

 public
 package
 protected
 private

Note, that if a named element is not owned by any namespace, then it does not have a visibility.
A public element is visible to all elements that can access the contents of
the namespace that owns it. Public visibility is represented by '+' literal.

A package element is owned by a namespace that is not a package, and is visible to

elements that are in the same package as its owning namespace. Only named elements that are
not owned by packages can be marked as having package visibility. Any element marked as
having package visibility is visible to all elements within the nearest enclosing package (given
that other owning elements have proper visibility). Outside the nearest enclosing package, an
element marked as having package visibility is not visible. Package visibility is represented by
'~' literal.

A protected element is visible to elements that have a generalization relationship to

the namespace that owns it. Protected visibility is represented by '#' literal.
 A private element is only visible inside the namespace that owns it. Private visibility is
represented by '-' literal.

Operation executeQuery is public, isPoolable - protected,

getQueryTimeout - with package visibility, and clearWarnings is private.

In object-oriented design, there is a notation of visibility for attributes and operations.

UML identifies four types of visibility: public, protected, private, and package.
The +, -, # and ~ symbols before an attribute and operation name in a class denote the
visibility of the attribute and operation.
 + denotes public attributes or operations
 - denotes private attributes or operations
 # denotes protected attributes or operations
 ~ denotes package attributes or operations

Access for each of these visibility types is shown below for members of different classes.
Access Right public (+) private (-) protected (#) Package (~)
Members of the same class Yes Yes yes yes
Members of derived classes Yes No yes yes
Members of any other class Yes No no in same package

Multiplicity
Multiplicity in class diagram should be indicated at each end of the association. This
specifies the minimum and maximum number of instances that can be linked.
For example, a car has 3 or 4 wheels, but each wheel belongs to exactly one car. Place
multiplicity notations near the ends of an association. These symbols indicate the number of
instances of one class linked to one instance of the other class.
For example, one company will have one or more employees, but each employee works for one
company only.
 The minimum and maximum values are separated by two dots.
 An asterisk (*) represents an indeterminate maximum value.
 In the case that the minimum and maximum values are the same, the number is displayed only
once.
 In addition, zero or more (0… *) is also referred to as a simple asterisk (*) because it is
common.
Finally, ranges and/or individual values can be separated by commas to list alternative values,
i.e. 1..3, 5..8

Class Diagram Example

Relationships between classes

In class diagrams, relationships between classes describe how classes are connected or
interact with each other within a system. There are several types of relationships in object-
oriented modeling, each serving a specific purpose. Here are some common types of
relationships in class diagrams:
1. Association
An association represents a bi-directional relationship between two classes. It indicates
that instances of one class are connected to instances of another class. Associations are
typically depicted as a solid line connecting the classes, with optional arrows indicating the
direction of the relationship.

Let’s understand association using an example:

Let’s consider a simple system for managing a library. In this system, we have two
main entities: Book and Library. Each Library contains multiple Books, and
each Book belongs to a specific Library. This relationship
between Library and Book represents an association. The “Library” class can be considered
the source class because it contains a reference to multiple instances of the “Book” class. The
“Book” class would be considered the target class because it belongs to a specific library.

2. Directed Association
A directed association in a UML class diagram represents a relationship between two
classes where the association has a direction, indicating that one class is associated with
another in a specific way.
 In a directed association, an arrowhead is added to the association line to indicate the
direction of the relationship. The arrow points from the class that initiates the association to
the class that is being targeted or affected by the association.
 Directed associations are used when the association has a specific flow or directionality,
such as indicating which class is responsible for initiating the association or which class
has a dependency on another.
Consider a scenario where a “Teacher” class is associated with a “Course” class in a
university system. The directed association arrow may point from the “Teacher” class to the
“Course” class, indicating that a teacher is associated with or teaches a specific course.
 The source class is the “Teacher” class. The “Teacher” class initiates the association by
teaching a specific course.
 The target class is the “Course” class. The “Course” class is affected by the association as
it is being taught by a specific teacher.
3. Aggregation
Aggregation is a specialized form of association that represents a “whole-part” relationship. It
denotes a stronger relationship where one class (the whole) contains or is composed of another
class (the part). Aggregation is represented by a diamond shape on the side of the whole class.
In this kind of relationship, the child class can exist independently of its parent class.
Let’s understand aggregation using an example:
The company can be considered as the whole, while the employees are the parts. Employees
belong to the company, and the company can have multiple employees. However, if the
company ceases to exist, the employees can still exist independently.

4. Composition
Composition is a stronger form of aggregation, indicating a more significant ownership or
dependency relationship. In composition, the part class cannot exist independently of the
whole class. Composition is represented by a filled diamond shape on the side of the whole
class.
Let’s understand Composition using an example:
Imagine a digital contact book application. The contact book is the whole, and each contact
entry is a part. Each contact entry is fully owned and managed by the contact book. If the
contact book is deleted or destroyed, all associated contact entries are also removed.

This illustrates composition because the existence of the contact entries depends entirely on the
presence of the contact book. Without the contact book, the individual contact entries lose their
meaning and cannot exist on their own.

5. Generalization (Inheritance)
Inheritance represents an “is-a” relationship between classes, where one class (the
subclass or child) inherits the properties and behaviors of another class (the superclass or
parent). Inheritance is depicted by a solid line with a closed, hollow arrowhead pointing from
the subclass to the superclass.

In the example of bank accounts, we can use generalization to represent different types of
accounts such as current accounts, savings accounts, and credit accounts.

The Bank Account class serves as the generalized representation of all types of bank accounts,
while the subclasses (Current Account, Savings Account, Credit Account) represent
specialized versions that inherit and extend the functionality of the base class.
6. Realization (Interface Implementation)
Realization indicates that a class implements the features of an interface. It is often
used in cases where a class realizes the operations defined by an interface. Realization is
depicted by a dashed line with an open arrowhead pointing from the implementing class to the
interface.
Let’s consider the scenario where a “Person” and a “Corporation” both realizing an “Owner”
interface.
 Owner Interface: This interface now includes methods such as “acquire (property)” and
“dispose (property)” to represent actions related to acquiring and disposing of property.
 Person Class (Realization): The Person class implements the Owner interface, providing
concrete implementations for the “acquire (property)” and “dispose (property)” methods.
For instance, a person can acquire ownership of a house or dispose of a car.
 Corporation Class (Realization): Similarly, the Corporation class also implements the
Owner interface, offering specific implementations for the “acquire (property)” and
“dispose (property)” methods. For example, a corporation can acquire ownership of real
estate properties or dispose of company vehicles.
Both the Person and Corporation classes realize the Owner interface, meaning they provide
concrete implementations for the “acquire (property)” and “dispose (property)” methods
defined in the interface.
7. Dependency Relationship
A dependency exists between two classes when one class relies on another, but the
relationship is not as strong as association or inheritance. It represents a more loosely coupled
connection between classes. Dependencies are often depicted as a dashed arrow.

Let’s consider a scenario where a Person depends on a Book.

 Person Class: Represents an individual who reads a book. The Person class depends on the
Book class to access and read the content.
 Book Class: Represents a book that contains content to be read by a person. The Book
class is independent and can exist without the Person class.
The Person class depends on the Book class because it requires access to a book to read its
content. However, the Book class does not depend on the Person class; it can exist
independently and does not rely on the Person class for its functionality.
8. Usage (Dependency) Relationship
A usage dependency relationship in a UML class diagram indicates that one class (the
client) utilizes or depends on another class (the supplier) to perform certain tasks or access
certain functionality. The client class relies on the services provided by the supplier class but
does not own or create instances of it.
 Usage dependencies represent a form of dependency where one class depends on another
class to fulfill a specific need or requirement.
 The client class requires access to specific features or services provided by the supplier
class.
 In UML class diagrams, usage dependencies are typically represented by a dashed arrowed
line pointing from the client class to the supplier class.
 The arrow indicates the direction of the dependency, showing that the client class depends
on the services provided by the supplier class.

Consider a scenario where a “Car” class depends on a “FuelTank” class to manage fuel
consumption.
 The “Car” class may need to access methods or attributes of the “FuelTank” class to check
the fuel level, refill fuel, or monitor fuel consumption.
 In this case, the “Car” class has a usage dependency on the “FuelTank” class because it
utilizes its services to perform certain tasks related to fuel management.

Benefits of Class Diagrams

 Modeling Class Structure:
 Class diagrams help in modeling the structure of a system by representing
classes and their attributes, methods, and relationships.
 This provides a clear and organized view of the system’s architecture.
 Understanding Relationships:
 Class diagrams depict relationships between classes, such as associations,
aggregations, compositions, inheritance, and dependencies.
  This helps stakeholders, including developers, designers, and business analysts,
understand how different components of the system are connected.
 Communication:
 Class diagrams serve as a communication tool among team members and
stakeholders. They provide a visual and standardized representation that can be
easily understood by both technical and non-technical audiences.
 Blueprint for Implementation:
 Class diagrams serve as a blueprint for software implementation. They guide
developers in writing code by illustrating the classes, their attributes, methods,
and the relationships between them.
 This can help ensure consistency between the design and the actual
implementation.
 Code Generation:
 Some software development tools and frameworks support code generation from
class diagrams.
 Developers can generate a significant portion of the code from the visual
representation, reducing the chances of manual errors and saving development
time.
 Identifying Abstractions and Encapsulation:
 Class diagrams encourage the identification of abstractions and the
encapsulation of data and behavior within classes.
 This supports the principles of object-oriented design, such as modularity and
information hiding.

How to draw Class Diagrams

Drawing class diagrams involves visualizing the structure of a system, including classes,
their attributes, methods, and relationships. Here are the steps to draw class diagrams:
1. Identify Classes:
 Start by identifying the classes in your system. A class represents a blueprint for objects
and should encapsulate related attributes and methods.
2. List Attributes and Methods:
 For each class, list its attributes (properties, fields) and methods (functions, operations).
Include information such as data types and visibility (public, private, protected).
3. Identify Relationships:
 Determine the relationships between classes. Common relationships include
associations, aggregations, compositions, inheritance, and dependencies. Understand
the nature and multiplicity of these relationships.
4. Create Class Boxes:
 Draw a rectangle (class box) for each class identified. Place the class name in the top
compartment of the box. Divide the box into compartments for attributes and methods.
5. Add Attributes and Methods:
 Inside each class box, list the attributes and methods in their respective compartments.
Use visibility notations (+ for public, – for private, # for protected, ~ for
package/default).
6. Draw Relationships:
 Draw lines to represent relationships between classes. Use arrows to indicate the
direction of associations or dependencies. Different line types or notations may be used
for various relationships.
7. Label Relationships:
 Label the relationships with multiplicity and role names if needed. Multiplicity
indicates the number of instances involved in the relationship, and role names clarify
the role of each class in the relationship.
8. Review and Refine:
 Review your class diagram to ensure it accurately represents the system’s structure and
relationships. Refine the diagram as needed based on feedback and requirements.
9. Use Tools for Digital Drawing:
 While you can draw class diagrams on paper, using digital tools can provide more
flexibility and ease of modification. UML modeling tools, drawing software, or even
specialized diagramming tools can be helpful.
 II. Instance or Object Diagrams

1. What are Object Diagrams?

An Object Diagram can be referred to as a screenshot of the instances in a system and the
relationship that exists between them.
 An object diagram in UML is useful because it provides a clear and visual representation of
specific instances of classes and their relationships at a particular point in time, aiding in
understanding and communicating the structure and interactions within a system.
 In other words, “An object diagram in the Unified Modeling Language (UML), is a
diagram that shows a complete or partial view of the structure of a modeled system at a
specific time.

Object diagrams in UML are depicted using a simple and intuitive notations to show a
snapshot of a system at a specific point in time, displaying instances of classes and their
relationships.

What is an Object?
An object refers to a specific instance of a class within a system. A class is a blueprint or
template that defines the common attributes and behaviors shared by a group of objects. An
object, on the other hand, is a concrete and individual occurrence of that class, possessing
unique values for its attributes.

What is a Classifier?
In UML a classifier refers to a group of elements that have some common features like
methods, attributes and operations. A classifier can be thought of as an abstract meta class
which draws a boundary for a group of instances having common static and dynamic features.

For example:
We refer a class, a component, or a deployment node as classifiers in UML since they define a
common set of properties. We are able to design object diagrams by instantiating classifiers.

4. Object Diagram Notations

The object diagram in UML uses specific notations to represent instances of classes and
their relationships at a particular moment in time.
1. Objects or Instance specifications
When we instantiate a classifier in a system, the object we create represents an entity
which exists in the system. We can represent the changes in object over time by creating
multiple instance specifications. We use a rectangle to represent an object in an object
diagram.

2. Attributes and Values

Inside the object box, attributes of the object are listed along with their specific values.

3. Link
We use a link to represent a relationship between two objects. We represent the number
of participants on the link for each, at the end of the link. The term link is used to specify a
relationship between two instance specifications or objects. We use a solid line to represent a
link between two objects.

For Example – In the figure below, an object of class Student is linked to an object of class
College.
4. Dependency Relationships
We use a dependency relationship to show when one element depends on another element.
A dependency is used to depict the relationship between dependent and independent entities in
the system.
 Any change in the definition or structure of one element may cause changes to the other.
 This is a unidirectional kind of relationship between two objects.
 Dependency relationships are of various types specified with keywords like Abstraction,
Binding, Realization, Substitution and Usage are the types of dependency relationships
used in UML.

For example – In the figure below, an object of Player class is dependent (or uses) an object
of Bat class.

5. Association
Association is a reference relationship between two objects (or classes). An association
line connects two object boxes, representing a relationship between instances of two classes.
We use association when one object references members of the other object. Association can
be uni-directional or bi-directional. We use an arrow to represent association.

For example – The object of Order class is associated with an object of Customer class.
6. Aggregation
Aggregation represents a “has a” or ‘whole-part’ relationship. We use a hollow diamond
on the containing object with a line which joins it to the contained object.
 Aggregation is a specific form of association.
 It is a kind of parent-child relationship however it isn’t inheritance.
 Aggregation occurs when the lifecycle of the contained objects does not strongly depend on
the lifecycle of container objects.
For example – A library has an aggregation relationship with books. Library has books or
books are a part of library. The existence of books is independent of the existence of
the library.

7. Composition
Composition is a type of association where the child cannot exist independent of the
other. We use a filled diamond on the containing object with a line which joins it to the
contained object. Composition is also a special type of association. It is also a kind of parent
child relationship but it is not inheritance. So whenever independent existence of the child is
not possible we use a composition relationship.

Consider the example of a boy Gurkaran: Gurkaran is composed of legs and arms.
Here Gurkaran has a composition relationship with his legs and arms. Here legs and arms
can’t exist without the existence of their parent object.
5. Purpose of Object Diagrams
The main purpose of using object diagrams is:
 They offer a detailed view of how objects interact with each other in specific scenarios.
 Proper design and analysis of applications can be faster and efficient.
 Object diagrams are beneficial during the implementation phase of software development.
 Promoting a shared understanding of specific instances and their relationships, facilitating
collaboration among team members.

6. Benefits of Object Diagrams

 Detailed Insight into Relationships:
 They offer a detailed view of relationships and collaborations between instances
of classes. This helps in understanding the specific interactions and
dependencies among objects.
 Implementation Guidance:
 During the system implementation phase, object diagrams assist developers in
building and testing the actual instances of classes. They provide guidance on
how to represent objects in code.
 Integration Testing Assistance:
 They are valuable for integration testing, allowing testers to evaluate how
different objects collaborate and exchange information. This ensures that
integrated components of the system work seamlessly.
 Validation of Code Implementation:
 Developers can use object diagrams to validate that the actual code aligns with
the intended relationships and interactions specified in the design. This helps
maintain consistency between the design and the implementation.
 Scenario Illustration:
 Object diagrams are useful for illustrating and documenting specific scenarios or
use cases, providing a clear visual representation of how objects behave in
different situations.
7. How to draw an Object Diagram?
1. Identify Classes: Determine the classes relevant to the scenario you want to depict.
Classes are the blueprints that define the attributes and behaviors shared by their instances.
2. Identify Objects: Identify specific instances or objects of each class that you want to
include in the diagram. These represent the actual things in your system.
3. Create Object Boxes: Draw rectangles to represent the specific instances or objects of
each class. Write the name of each object inside the box.
4. Add Attributes and Values: Inside each object box, list the attributes of that object along
with their specific values.
5. Draw Relationships: Connect the object boxes with lines to represent relationships or
associations between instances. Use arrows to indicate the direction of the association if
necessary.
6. Label Relationships: Label the relationships with multiplicity and role names if needed.
Label the association lines with a verb or phrase to describe the nature of the relationship.
7. Review and Refine: Review your Object diagram to ensure it accurately represents the
system’s structure and relationships. Refine the diagram as needed based on feedback and
requirements.
8. Use Tools for Digital Drawing: While you can draw class diagrams on paper, using digital
tools can provide more flexibility and ease of modification. UML modeling tools, drawing
software, or even specialized diagramming tools can be helpful.
 III. Advanced Features of Class Diagrams

1. Aggregation
2. Composition
3. Derived Properties
4. Interfaces and Abstract Classes
5. Multiple Classification
6. Association Class
7. Enumeration
8. Active Class
9. Visibility

Note: Where Aggregation, Composition and Visibility are explained in the above content.
Please refer to it.

3. Derived Properties

Derived properties can be calculated based on other values. When we think about a date
range (Figure 5.5), we can think of three properties: the start date, the end date, and the number
of days in the period. These values are linked, so we can think of the length as being derived
from the other two values.
Figure 5.5. Derived attribute in a time period

Derivation in software perspectives can be interpreted in a couple of different ways. You

can use derivation to indicate the difference between a calculated value and a stored value. In
this case, we would interpret Figure 5.5 as indicating that the start and end are stored but that the
length is computed.
4. Interfaces and Abstract Classes
One of the great qualities of object-oriented development is that you can vary the
interfaces of classes independent of the implementation. Much of the power of object
development comes from this property. However, few people make good use of it.
Programming languages use a single construct, the class, which contains both interface
and implementation. When you subclass, you inherit both. Using the interface as a separate
construct is rarely used.
A pure interface, as in Java, is a class with no implementation and, therefore, has
operation declarations but no method bodies and no fields. Interfaces are often declared through
abstract classes. Such classes may provide some implementation, but often they are used
primarily to declare an interface. The point is that sub-classing or some other mechanism will
provide the implementation, but clients will never see the implementation, only the interface.
The text editor represented in Figure 6-10 is a typical example of this. To allow the editor
to be platform-independent, we define a platform-independent abstract Window class. This class
has no method bodies; it only defines an interface for the text editor to use. Platform-specific
subclasses can be used as desired.
Figure 6-10. Window as Abstract Class

If you have an abstract class or method, the UML convention is to italicize the name of
the abstract item. You can use the {abstract} constraint, as well (or instead).
Java provides an interface construct, and the compiler checks that the implementing class
provides implementations of all of the interface's operations
In Figure 6-11, we see InputStream, DataInput, and DataInputStream (defined in the
standard [Link] package). InputStream is an abstract class; DataInput is an interface.
 Figure 6-11. Interfaces and Abstract Class: An Example from Java

Some client class, say, OrderReader, needs to use DataInput's functionality. The
DataInputStream class implements both the DataInput and InputStream interfaces and is a
subclass of the latter.
The link between DataInputStream and DataInput is a realization relationship.
Realization is deliberately similar to generalization; it indicates that one class implements
behavior specified by another. It is permissible for one implementation class to realize another;
this means that the realizing class must conform to the interface, but need not use inheritance.
In a specification model, there is no difference between realization and subtyping.
The link between OrderReader and DataInput is a dependency. In this case, the dependency
indicates that if the DataInput interface changes, the OrderReader may also have to change. One
of the aims of development is to keep dependencies to a minimum so that the effects of changes
are minimized. Figure 6-12 shows an alternative, more compact notation. Here, the interfaces are
represented by small circles (often called lollipops) coming off the classes that implement them.
Figure 6-12. Lollipop Notation for Interfaces

With lollipops, there is no distinction between realizing an interface and sub-classing an

abstract class. Although the notation is more compact, you cannot show the operations of the
interface or any generalization relationships between interfaces.
 Abstract classes and interfaces are similar, but there is a difference. Both allow you to define
an interface and defer its implementation until later. However, the abstract class allows you to
add implementation of some of the methods; an interface forces you to defer definition of
all methods.

4. Multiple Classification
 Classification refers to the relationship between an object and its type. Mainstream
programming languages assume that an object belongs to a single class. But there are
more options to classification than that.
 In single classification, an object belongs to a single type, which may inherit from super-
types. In multiple classification, an object may be described by several types that are not
necessarily connected by inheritance.
 Multiple classification is different from multiple inheritance. Multiple inheritance says
that a type may have many super-types but that a single type must be defined for each
object. Multiple classification allows multiple types for an object without defining a
specific type for the purpose.
 For example, consider a person subtyped as either man or woman, doctor or nurse,
patient or not (see Figure 5.11). Multiple classification allows an object to have any of
these types assigned to it in any allowable combination, without the need for types to be
defined for all the legal combinations.
 Figure 5.11. Multiple classification

 If you use multiple classification, you need to be sure that you make it clear which
combinations are legal. UML 2 does this by placing each generalization relationship into
a generalization set. On the class diagram, you label the generalization arrowhead with
the name of the generalization set, which in UML 1 was called the discriminator.
Generalization sets are by default disjoint: Any instance of the super-type may be an
instance of only one of the subtypes within that set. If you roll up generalizations into a
single arrow, they must all be part of the same generalization set, as shown in Figure
5.11. Alternatively, you can have several arrows with the same text label.
  To illustrate, note the following legal combinations of subtypes in the diagram: (Female,
Patient, Nurse); (Male, Physiotherapist); (Female, Patient); and (Female, Doctor,
Surgeon). The combination (Patient, Doctor, Nurse) is illegal because it contains two
types from the role generalization set.
6. Association Class
 Association classes allow you to add attributes, operations, and other features to
associations, as shown in Figure 5.12. We can see from the diagram that a person may
attend many meetings. We need to keep information about how awake that person was;
we can do this by adding the attribute attentiveness to the association.
Figure 5.12. Association class

 Figure 5.13 shows another way to represent this information: Make Attendance a full
class in its own right. Note how the multiplicities have moved.
Figure 5.13. Promoting an association class to a full class

 What benefit do you gain with the association class to offset the extra notation you have
to remember? The association class adds an extra constraint, in that there can be only one
instance of the association class between any two participating objects.

7. Enumerations
Enumeration is a useful concept in programming that refers to creating datasets or lists
of related data values. Enumerations are helpful in programming to make our code readable and
understandable by classifying similar data in a single enumeration.

Enumeration representation
We represent the enumeration in UML by a rectangle with two sections:
The enumeration name and the data section.
Enumeration in a class diagram
 <<enumeration>>: The keyword mandatory to use in the enumeration to make it
different from the other classes.
 EnumerationName: The name of the enumeration.
 value1, value2, value3: The distinct data values of the enumeration also known as
enumeration literals.

Note: An enumeration is considered meaningful if it consists of a minimum of two enumeration

literals.

We can define values for the enumeration literals in an enumeration as well.

Enumeration with defined values in a class diagram

 Here the name of the enumeration is Day. It consists of seven enumeration literals
defined with some values for each one.

Example

Let's consider an example of an enumeration for storing the types of a task based on its current
status. The name of the enumeration is TaskStatus, consisting of enumeration literals: Pending,
InProgress, and Completed.
Now let's understand how we can associate this enumeration with an attribute of a class.

In the above diagram, we have a class Task, containing three public attributes: name, dueDate,
and status. The status attribute can have any one of the values present in the enumeration
TaskStatus. We connect our enumeration with the Task class using an association.

Defining enumeration inside a UML class

We can define an enumeration inside a UML class using the following UML representation.

Now we can directly define the enumeration values for the status attribute in the Task class using
a containment relationship.
 By concluding, the enumeration in UML class diagrams offers a powerful tool for
representing distinct values within a class structure. With enumerations, UML class diagrams
become clearer, helping us design and build our software systems efficiently.

8. Active Class
 An active class has instances, each of which executes and controls its own thread of
control. Method invocations may execute in a client's thread or in the active object's
thread. A good example of this is a command processor that accepts command objects
from the outside and then executes the commands within its own thread of control.
 The notation for active classes has changed from UML 1 to UML 2, as shown in Figure
5.21. In UML 2, an active class has extra vertical lines on the side; in UML 1, it had a
thick border and was called an active object.
Figure 5.21. Active class

IV. Interaction Diagrams

From the term Interaction, it is clear that the diagram is used to describe some type of
interactions among the different elements in the model. This interaction is a part of dynamic
behavior of the system.

This interactive behavior is represented in UML by two diagrams known as Sequence

diagram and Collaboration diagram. The basic purpose of both the diagrams are similar.

Sequence diagram emphasizes on time sequence of messages and collaboration diagram

emphasizes on the structural organization of the objects that send and receive messages.
Purpose of Interaction Diagrams

The purpose of interaction diagrams is to visualize the interactive behavior of the system.
Visualizing the interaction is a difficult task. Hence, the solution is to use different types of
models to capture the different aspects of the interaction.

Sequence and collaboration diagrams are used to capture the dynamic nature but from a
different angle.

The purpose of interaction diagram is −

 To capture the dynamic behaviour of a system.
 To describe the message flow in the system.
 To describe the structural organization of the objects.
 To describe the interaction among objects.

How to Draw an Interaction Diagram?

As we have already discussed, the purpose of interaction diagrams is to capture the

dynamic aspect of a system. So to capture the dynamic aspect, we need to understand what a
dynamic aspect is and how it is visualized. Dynamic aspect can be defined as the snapshot of
the running system at a particular moment.

We have two types of interaction diagrams in UML. One is the sequence diagram and the
other is the collaboration diagram. The sequence diagram captures the time sequence of the
message flow from one object to another and the collaboration diagram describes the organization
of objects in a system taking part in the message flow.

Following things are to be identified clearly before drawing the interaction diagram
 Objects taking part in the interaction.
 Message flows among the objects.
 The sequence in which the messages are flowing.
 Object organization.

1. UML 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

Communication between objects is depicted using messages. The messages appear in a

sequential order on the lifeline.
 We represent messages using arrows.
 Lifelines and messages form the core of a sequence diagram.
Messages can be broadly classified into the following categories:

1. Synchronous messages
A synchronous message waits for a reply before the interaction can move forward. The
sender waits until the receiver has completed the processing of the message. The caller
continues only when it knows that the receiver has processed the previous message i.e. it
receives a reply message.
 A large number of calls in object oriented programming are synchronous.
 We use a solid arrow head to represent a synchronous message.

2. Asynchronous Messages
An asynchronous message does not wait for a reply from the receiver. The interaction moves
forward irrespective of the receiver processing the previous message or not. We use a lined
arrow head to represent an asynchronous message.

3. Create message
We use a Create message to instantiate a new object in the sequence diagram. There are
situations when a particular message call requires the creation of an object. It is represented
with a dotted arrow and create word labelled on it to specify that it is the create Message
symbol.
For example:
The creation of a new order on a e-commerce website would require a new object of Order
class to be created.
4. Delete Message
We use a Delete Message to delete an object. When an object is deallocated memory or is
destroyed within the system we use the Delete Message symbol. It destroys the occurrence of
the object in the system. It is represented by an arrow terminating with a x.
For example:
In the scenario below when the order is received by the user, the object of order class can be
destroyed.

5. Self Message
Certain scenarios might arise where the object needs to send a message to itself. Such
messages are called Self Messages and are represented with a U shaped arrow.
Another example:
Consider a scenario where the device wants to access its webcam. Such a scenario is
represented using a self message.

6. Recursive Message: A self-message sent for recursive purpose is called a recursive message.
In other words, it can be said that the recursive message is a special case of the self-message as it
represents the recursive calls.

7. Reply Message
Reply messages are used to show the message being sent from the receiver to the
sender. We represent a return/reply message using an open arrow head with a dotted line.
The interaction moves forward only when a reply message is sent by the receiver.
For example:
Consider the scenario where the device requests a photo from the user. Here the message
which shows the photo being sent is a reply message.

8. Found Message
A Found message is used to represent a scenario where an unknown source sends the
message. It is represented using an arrow directed towards a lifeline from an end point.
For example:
Consider the scenario of a hardware failure.

It can be due to multiple reasons and we are not certain as to what caused the hardware failure.
9. Lost Message
A Lost message is used to represent a scenario where the recipient is not known to the
system. It is represented using an arrow directed towards an end point from a lifeline.
For example:
Consider a scenario where a warning is generated.

The warning might be generated for the user or other software/object that the lifeline is
interacting with. Since the destination is not known before hand, we use the Lost Message
symbol.

10. Guards
To model conditions we use guards in UML. They are used when we need to restrict the
flow of messages on the pretext of a condition being met. Guards play an important role in
letting software developers know the constraints attached to a system or a particular process.
For example:
In order to be able to withdraw cash, having a balance greater than zero is a condition that
must be met as shown below.
 11. 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.

Note

A note is the capability of attaching several remarks to the element. It basically carries useful
information for the modelers.
The above sequence diagram depicts the sequence diagram for an emotion based music player:
1. Firstly the application is opened by the user.
2. The device then gets access to the web cam.
3. The webcam captures the image of the user.
4. The device uses algorithms to detect the face and predict the mood.
5. It then requests database for dictionary of possible moods.
6. The mood is retrieved from the database.
7. The mood is displayed to the user.
8. The music is requested from the database.
9. The playlist is generated and finally shown to the user.

Sequence Fragments
1. Sequence fragments have been introduced by UML 2.0, which makes it quite easy for the
creation and maintenance of an accurate sequence diagram.
2. It is represented by a box called a combined fragment, encloses a part of interaction inside
a sequence diagram.
3. The type of fragment is shown by a fragment operator.
 Types of fragments

Following are the types of fragments enlisted below;

Operator Fragment Type

Alt Alternative multiple fragments: The only fragment for which the condition is true, will execute.

Opt Optional: If the supplied condition is true, only then the fragments will execute. It is similar to alt
with only one trace.

Par Parallel: Parallel executes fragments.

Loop Loop: Fragments are run multiple times, and the basis of interaction is shown by the guard.

Region Critical region: Only one thread can execute a fragment at once.

Neg Negative: A worthless communication is shown by the fragment.

Ref Reference: An interaction portrayed in another diagram. In this, a frame is drawn so as to cover the
lifelines involved in the communication. The parameter and return value can be explained.

Sd Sequence Diagram: It is used to surround the whole sequence diagram.

Example of a Sequence Diagram

An example of a high-level sequence diagram for online bookshop is given below.
Any online customer can search for a book catalog, view a description of a particular book, add a
book to its shopping cart, and do checkout.
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.

How to create Sequence Diagrams?

Creating a sequence diagram involves several steps, and it’s typically done during the
design phase of software development to illustrate how different components or objects
interact over time. Here’s a step-by-step guide on how to create sequence diagrams:
1. Identify the Scenario:
 Understand the specific scenario or use case that you want to represent in the sequence
diagram. This could be a specific interaction between objects or the flow of messages in
a particular process.
2. List the Participants:
 Identify the participants (objects or actors) involved in the scenario. Participants can be
users, systems, or external entities.
3. Define Lifelines:
 Draw a vertical dashed line for each participant, representing the lifeline of each object
over time. The lifeline represents the existence of an object during the interaction.
4. Arrange Lifelines:
 Position the lifelines horizontally in the order of their involvement in the interaction.
This helps in visualizing the flow of messages between participants.
5. Add Activation Bars:
 For each message, draw an activation bar on the lifeline of the sending participant. The
activation bar represents the duration of time during which the participant is actively
processing the message.
6. Draw Messages:
 Use arrows to represent messages between participants. Messages flow horizontally
between lifelines, indicating the communication between objects. Different types of
messages include synchronous (solid arrow), asynchronous (dashed arrow), and self-
messages.
7. Include Return Messages:
 If a participant sends a response message, draw a dashed arrow returning to the original
sender to represent the return message.
8. Indicate Timing and Order:
 Use numbers to indicate the order of messages in the sequence. You can also use
vertical dashed lines to represent occurrences of events or the passage of time.
9. Include Conditions and Loops:
 Use combined fragments to represent conditions (like if statements) and loops in the
interaction. This adds complexity to the sequence diagram and helps in detailing the
control flow.
10. Consider Parallel Execution:
 If there are parallel activities happening, represent them by drawing parallel vertical
dashed lines and placing the messages accordingly.
11. Review and Refine:
 Review the sequence diagram for clarity and correctness. Ensure that it accurately
represents the intended interaction. Refine as needed.
12. Add Annotations and Comments:
 Include any additional information, annotations, or comments that provide context or
clarification for elements in the diagram.
13. Document Assumptions and Constraints:
 If there are any assumptions or constraints related to the interaction, document them
alongside the diagram.
14. Tools:
 Use a UML modeling tool or diagramming software to create a neat and professional-
looking sequence diagram. These tools often provide features for easy editing,
collaboration, and documentation.

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

V. State Machine Diagram/State Diagram

The state machine diagram is also called the State Chart or State Transition diagram, which
shows the order of states underwent by an object within the system. It captures the software
system's behavior. It models the behavior of a class, a subsystem, a package, and a complete
system.

It tends out to be an efficient way of modeling the interactions and collaborations in the external
entities and the system. It models event-based systems to handle the state of an object. It also
defines several distinct states of a component within the system. Each object/component has a
specific state.

Following are the types of a state machine diagram that are given below:
1. Behavioral state machine
The behavioral state machine diagram records the behavior of an object within the
system. It depicts an implementation of a particular entity. It models the behavior of the
system.
2. Protocol state machine
It captures the behavior of the protocol. The protocol state machine depicts the change in
the state of the protocol and parallel changes within the system. But it does not portray
the implementation of a particular component.
Why State Machine Diagram?

Since it records the dynamic view of a system, it portrays the behavior of a software
application. During a lifespan, an object underwent several states, such that the lifespan exist until
the program is executing. Each state depicts some useful information about the object.

It blueprints an interactive system that response back to either the internal events or the
external ones. The execution flow from one state to another is represented by a state machine
diagram. It visualizes an object state from its creation to its termination.

The main purpose is to depict each state of an individual object. It represents an interactive
system and the entities inside the system. It records the dynamic behavior of the system.

Notation of a State Machine Diagram

Following are the notations of a state machine diagram enlisted below:

a. Initial state: It defines the initial state (beginning) of a system, and it is represented by a
black filled circle.
b. Final state: It represents the final state (end) of a system. It is denoted by a filled circle
present within a circle.
c. Decision box: It is of diamond shape that represents the decisions to be made on the basis
of an evaluated guard.
d. Transition: A change of control from one state to another due to the occurrence of some
event is termed as a transition. It is represented by an arrow labeled with an event due to
which the change has ensued.
e. State box: It depicts the conditions or circumstances of a particular object of a class at a
specific point of time. A rectangle with round corners is used to represent the state box.
Types of State

The UML consist of three states:

1. Simple state: It does not constitute any substructure.
2. Composite state: It consists of nested states (substates), such that it does not contain more
than one initial state and one final state. It can be nested to any level.
3. Submachine state: The submachine state is semantically identical to the composite state,
but it can be reused.

How to Draw a State Machine Diagram?

The state machine diagram is used to portray various states underwent by an object. The
change in one state to another is due to the occurrence of some event. All of the possible states of
a particular component must be identified before drawing a state machine diagram.

The primary focus of the state machine diagram is to depict the states of a system. These
states are essential while drawing a state transition diagram. The objects, states, and events due to
which the state transition occurs must be acknowledged before the implementation of a state
machine diagram.

Following are the steps that are to be incorporated while drawing a state machine diagram:
1. A unique and understandable name should be assigned to the state transition that describes
the behavior of the system.
2. Out of multiple objects, only the essential objects are implemented.
3. A proper name should be given to the events and the transitions.

When to use a State Machine Diagram?

The state machine diagram implements the real-world models as well as the object-oriented
systems. It records the dynamic behavior of the system, which is used to differentiate between the
dynamic and static behavior of a system.

It portrays the changes underwent by an object from the start to the end. It basically
envisions how triggering an event can cause a change within the system.

State machine diagram is used:

1. For modeling the object states of a system.
2. For modeling the reactive system as it consists of reactive objects.
3. For pinpointing the events responsible for state transitions.
4. For implementing forward and reverse engineering.
Example of a State Machine Diagram

An example of a top-level state machine diagram showing Bank Automated Teller

Machine (ATM) is given below.

Initially, the ATM is turned off. After the power supply is turned on, the ATM starts
performing the startup action and enters into the Self-Test state. If the test fails, the ATM will
enter into the Out Of Service state, or it will undergo a trigger less transition to the idle state.
This is the state where the customer waits for the interaction.

Whenever the customer inserts the bank or credit card in the ATM's card reader, the ATM
state changes from Idle to Serving Customer, the entry action readCard is performed after
entering into Serving Customer state. Since the customer can cancel the transaction at any instant,
so the transition from Serving Customer state back to the idle state could be triggered
by cancel event.

Here the Serving Customer is a composite state with sequential sub-states that
are Customer Authentication, Selecting Transaction, and Transaction.

Customer Authentication and Transaction are the composite states itself is displayed by
a hidden decomposition indication icon. After the transaction is finished, the Serving
 Customer encompasses a trigger less transition back to the Idle state. On leaving the state, it
undergoes the exit action ejectCard that discharges the customer card.

State Machine vs. Flowchart

State Machine Flowchart

It portrays several states of a system. It demonstrates the execution flow of a program.

It encompasses the concept of WAIT, i.e., wait for an It does not constitute the concept of WAIT.
event or an action.

It is for real-world modeling systems. It envisions the branching sequence of a system.

It is a modeling diagram. It is a data flow diagram (DFD)

It is concerned with several states of a system. It focuses on control flow and path.

VI. 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.
Activity partition /swimlane

The swimlane is used to cluster all the related activities in one column or one row. It can
be either vertical or horizontal. It used to add modularity to the activity diagram. It is not necessary
to incorporate swimlane in the activity diagram. But it is used to add more transparency to the
activity diagram.

Forks

Forks and join nodes generate the concurrent flow inside the activity. A fork node consists of one
inward edge and several outward edges. It is the same as that of various decision parameters.
Whenever a data is received at an inward edge, it gets copied and split crossways various outward
edges. It split a single inward flow into multiple parallel flows.

Join Nodes
 Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all of
the inward edges as it synchronizes the flow of input across one single output (outward) edge.

Pins

It is a small rectangle, which is attached to the action rectangle. It clears out all the messy
and complicated thing to manage the execution flow of activities. It is an object node that precisely
represents one input to or output from the action.

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 them self 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 swim-lanes, 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.

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

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