Course Code: 2040237201

Course Name: Software

Engineering
SEMESTER: 3

UNIT NO. 03
OVERVIEW OF UML

TOPICS TO BE COVERED

⮚ Class Diagram

⮚ Object Diagram

⮚ Use case Diagram

⮚ Sequence Diagram

⮚ Activity Diagram

⮚ Component Diagram

⮚ Collaboration Diagram

By Asst. Prof. Mitul Ghediya Page | 1

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

⮚ Class Diagram

A UML Class Diagram provides a static view of a system by showing the types of objects,
their attributes, methods, and the relationships between them. It is widely used in object-
oriented software design to visualize, describe, and document different aspects of the system
and can also help generate code for software development.

Purpose of Class Diagrams

Class diagrams are mainly used to:

• Analyze and design the static structure of a system.

• Document system architecture by showing the relationships between objects.
• Create executable code in object-oriented programming languages like Java or C++.
• Facilitate forward and reverse engineering by translating a design into code and vice versa.

Benefits of Class Diagrams

• Provide a clear overview of the system's structure.

• Help understand complex systems.
• Allow quick reference to a system's object model before writing code.
• Assist both developers and stakeholders in visualizing the system.
• Simplify maintenance by offering a blueprint of the system's classes and relationships.

Vital Components of a UML Class Diagram

A class diagram consists of three main sections, which help in representing the structure and
behavior of a system. Each section plays a key role in visualizing the system's objects and
their relationships.

1. Upper Section: Class Name

The upper section contains the name of the class. This is the main identifier for the class
and represents a group of similar objects with shared attributes, behaviors, and relationships.

Rules for Naming Classes:

• Capitalize the first letter of the class name (e.g., Customer, Order).

By Asst. Prof. Mitul Ghediya Page | 2

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

• Bold format should be used to write the class name.

• Abstract class names should be written in italics to indicate that they cannot be instantiated
directly.
• Center the class name in the upper section.

2. Middle Section: Attributes

The middle section contains the attributes of the class, which represent the properties or
data that define the characteristics of an object.

Characteristics of Attributes:

• Visibility: Indicated by symbols:

o + for public (accessible by all)
o - for private (accessible only within the class)
o # for protected (accessible within the class and its subclasses)
o ~ for package (accessible within the same package)
• Meaningful Names: Each attribute should have a clear, meaningful name that describes its
purpose (e.g., name, age, price).
• Example: +customerID : int, -balance : double.

3. Lower Section: Methods (Operations)

The lower section contains the methods (or operations) that describe the behavior of the
class. These are the functions that define how the class interacts with its attributes and other
objects.

Characteristics of Methods:

• Visibility: Similar to attributes, methods have visibility factors (+, -, #, ~) indicating how
accessible they are.
• List Format: Methods are listed one by one, each on a new line.
• Methods typically include:
o Method name (e.g., calculateTotal(), updateStock())
o Parameters (if any) inside parentheses
o Return type (optional), which indicates the data type the method will return.

Example: +addProduct(productID: int): void

By Asst. Prof. Mitul Ghediya Page | 3

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

1. Dependency

• Definition: A dependency is a weak relationship between two or more classes, where a

change in one class might affect the other class. It shows that one class depends on another
but does not tightly bind them.

• Example: A Student class might depend on a StudentID class. If the structure of

StudentID changes, the Student class may also need to be updated.

2. Generalization (Inheritance)

• Definition: Generalization represents an inheritance relationship between a parent class

(superclass) and its child class (subclass). The child class inherits attributes and methods
from the parent class.

By Asst. Prof. Mitul Ghediya Page | 4

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

• Example: A BankAccount class can be generalized into subclasses such as

CurrentAccount, SavingsAccount, and CreditAccount. These subclasses inherit
common properties from the BankAccount superclass.

3. Association

• Definition: Association defines a static or physical relationship between two or more

objects. It shows how objects are connected and how many instances of one class are
associated with instances of another class.

• Example: A Department is associated with College, meaning the department belongs to a

college.

Multiplicity

• Definition: Multiplicity defines the number of instances of one class that can be associated
with a single instance of another class. If no range is specified, the default multiplicity is one.

By Asst. Prof. Mitul Ghediya Page | 5

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

• Example: A hospital can admit multiple patients, meaning one hospital can have many
patients.

4. Aggregation

• Definition: Aggregation is a special form of association that represents a whole-part

relationship where the part can exist independently of the whole. It indicates a loose
relationship between objects.

• Example: A Company consists of multiple Employees. Even if an employee leaves, the

company still exists. The relationship is "has-a", where the company has employees, but
they are independent.

5. Composition

• Definition: Composition is a stronger form of aggregation where the child object’s existence
depends on the parent object. If the parent object is deleted, the child object also gets
deleted.

• Example: A ContactBook contains multiple Contacts. If the contact book is deleted, all its
contacts are also deleted.

Abstract Classes

• Definition: An abstract class is a class that cannot be instantiated directly. It acts as a

template for other classes to inherit from. Abstract classes contain methods that must be
implemented by subclasses. The name of an abstract class is written in italics.

By Asst. Prof. Mitul Ghediya Page | 6

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

• Example: Suppose there is an abstract class called Vehicle with a method drive().
Different subclasses like Car, Bike, and Scooter can implement the drive() method
according to their own behavior.

Summary of Relationships

• Dependency: A weak relationship where one class depends on another.

• Generalization: An inheritance relationship between a superclass and its subclasses.
• Association: A static relationship between objects, indicating how they interact.
• Aggregation: A whole-part relationship where the parts can exist independently of the
whole.
• Composition: A whole-part relationship where the parts depend on the whole for their
existence.

These relationships help define the structure and interaction in object-oriented systems,
making it easier to visualize how different parts of the system work together.

By Asst. Prof. Mitul Ghediya Page | 7

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

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

• Activity diagrams are mainly used as a flowchart that consists of activities performed
by the system. Activity diagrams are not exactly flowcharts as they have some
additional capabilities. These additional capabilities include branching, parallel flow,
swimlane, etc.

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

• In activity diagrams, the notations are like visual symbols that help represent different
elements and actions in a simple way.

➢ Activity Diagram Notations

By Asst. Prof. Mitul Ghediya Page | 8

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

Initial State
• The starting state before an activity takes place is depicted using the initial state

Action or Activity State

• An activity represents execution of an action on objects or by objects. We represent
an activity using a rectangle with rounded corners. Basically any action or event that
takes place is represented using an activity.

Action Flow or Control flows

• Action flows or Control flows are also referred to as paths and edges. They are used to
show the transition from one activity state to another activity state.

• An activity state can have multiple incoming and outgoing action flows. We use a line
with an arrow head to depict a Control Flow. If there is a constraint to be adhered to
while making the transition it is mentioned on the arrow.

By Asst. Prof. Mitul Ghediya Page | 9

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

For example: Here both the states transit into one final state using action flow symbols
i.e. arrows.

Decision node and Branching

• When we need to make a decision before deciding the flow of control, we use the
decision node. The outgoing arrows from the decision node can be labelled with
conditions or guard expressions. It always includes two or more output arrows.

For example: We apply the conditions on input number to display the result :
If number is odd then display the number.
If number if even then display the error.

By Asst. Prof. Mitul Ghediya Page | 10

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

Guard
• A Guard refers to a statement written next to a decision node on an arrow sometimes
within square brackets.

• The statement must be TRUE/FASLE for the control to shift along a particular
direction. Guards help us know the constraints and conditions which determine the flow
of a process.

Fork
• Fork nodes are used to support concurrent activities. When we use a fork node when
both the activities get executed concurrently i.e. no decision is made before splitting
the activity into two parts. Both parts need to be executed in case of a fork statement.
We use a rounded solid rectangular bar to represent a Fork notation with incoming
arrow from the parent activity state and outgoing arrows towards the newly created
activities.

By Asst. Prof. Mitul Ghediya Page | 11

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

For example: In the example below, the activity of making coffee can be split into two
concurrent activities and hence we use the fork notation.

Join
• Join nodes are used to support concurrent activities converging into one. For join
notations we have two or more incoming edges and one outgoing edge.

For example: When both activities i.e. steaming the milk and adding coffee get
completed, we converge them into one final activity.

By Asst. Prof. Mitul Ghediya Page | 12

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

Merge or Merge Event

• Scenarios arise when activities which are not being executed concurrently have to be
merged. We use the merge notation for such scenarios. We can merge two or more
activities into one if the control proceeds onto the next activity irrespective of the path
chosen.

For example: In the diagram below: we can’t have both sides executing concurrently, but
they finally merge into one. A number can’t be both odd and even at the same time.

By Asst. Prof. Mitul Ghediya Page | 13

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

Swimlanes
• We use Swimlanes for grouping related activities in one column. Swimlanes group
related activities into one column or one row. Swimlanes can be vertical and horizontal.
Swimlanes are used to add modularity to the activity diagram. It is not mandatory to
use swimlanes. They usually give more clarity to the activity diagram. It’s similar to
creating a function in a program. It’s not mandatory to do so, but, it is a recommended
practice.

For example: Here different set of activities are executed based on if the number is odd or
even. These activities are grouped into a swimlane.

Time Event
• This refers to an event that stops the flow for a time; an hourglass depicts it. We can
have a scenario where an event takes some time to completed.

By Asst. Prof. Mitul Ghediya Page | 14

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

For example: Let us assume that the processing of an image takes a lot of time. Then it can
be represented as shown below.

Final State or End State

• The state which the system reaches when a particular process or activity ends is known
as a Final State or End State. We use a filled circle within a circle notation to represent
the final state in a state machine diagram. A system or a process can have multiple final
states.

For Example: An process is terminating

By Asst. Prof. Mitul Ghediya Page | 15

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

➢ How to Draw an Activity Diagram in UML?

Step 1. Identify the Initial State and Final States:

• This is like setting the starting point and ending point of a journey.
• Identify where your process begins (initial state) and where it concludes (final states).
• For example, if you are modelling a process for making a cup of tea, the initial state
could be “No tea prepared,” and the final state could be “Tea ready.”

Step 2. Identify the Intermediate Activities Needed:

• Think of the steps or actions required to go from the starting point to the ending
point.
• These are the activities or tasks that need to be performed.
• Continuing with the tea-making , intermediate activities could include “Boil water,”
“Pour tea into a cup”.

Step 3. Identify the Conditions or Constraints:

• Consider the conditions or circumstances that might influence the flow of your
process.
• These are the factors that determine when you move from one activity to another.
• Using the tea-making scenario, a condition could be “Water is boiled,” which
triggers the transition to the next activity.

Step 4. Draw the Diagram with Appropriate Notations:

• Now, represent the identified states, activities, and conditions visually using the
appropriate symbols and notations in an activity diagram. This diagram serves as a
visual map of your process, showing the flow from one state to another.

By Asst. Prof. Mitul Ghediya Page | 16

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

➢ What are Activity Diagrams used for?

Activity diagrams are used in software development and system design to model and visualize
the dynamic aspects of a system. Here are some common uses of activity diagrams:
• Dynamic modelling of the system or a process.
• Illustrate the various steps involved in a UML use case.
• Model software elements like methods, operations and functions.
• We can use Activity diagrams to depict concurrent activities easily.
• Show the constraints, conditions and logic behind algorithms.
• During the requirements analysis phase, activity diagrams assist in capturing and
documenting the dynamic aspects of user interactions.
Example: A manufacturer uses a flow chart to explain and illustrate how a particular product
is manufactured.

By Asst. Prof. Mitul Ghediya Page | 17

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

⮚ Object Diagram

• Object diagrams are a visual representation in UML (Unified Modeling Language) that
illustrates the instances of classes and their relationships within a system at a specific
point in time. They display objects, their attributes, and the links between them,
providing a snapshot of the system’s structure during execution. Since object diagrams
depict behavior when objects have been instantiated, we can study the behavior of the
system at a particular instant.

• What are Object Diagrams?

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

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

o Imagine you’re taking a snapshot of a group of people interacting at a party. An

object diagram is like that photo, capturing who’s talking to whom and how
they’re connected at that moment. In programming, these “people” are objects,
and the diagram shows how these objects (pieces of data) are connected at a
specific point in time. It’s a frozen view of the system in action, helping you see
how everything fits together.

• What is an Object?

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

By Asst. Prof. Mitul Ghediya Page | 18

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

o An object is a specific thing made from a general idea. If you think of a class as
a design for a toy (like a toy car), then an object is one of the actual toy cars
built from that design. Each toy car might have a different color or speed, but
they’re all built from the same basic design. In programming, an object is a real
piece of data created from the class, holding specific values.

• What is a Classifier?

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

o A classifier is a broad category that groups things with similar traits. For
example, in a zoo, you might have a section for mammals. “Mammals” is like
a classifier—it groups together animals like lions, elephants, and monkeys
because they share common features. In programming, a classifier helps group
objects that have similar properties, making it easier to manage and understand
them.

➢ Object Diagram Notations

By Asst. Prof. Mitul Ghediya Page | 19

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

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.

Attributes and Values

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

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.

By Asst. Prof. Mitul Ghediya Page | 20

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

For Example – In the figure below, an object of class Student is linked to an object of class
College.

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.
o Any change in the definition or structure of one element may cause changes
to the other.
o This is a unidirectional kind of relationship between two objects.
o 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.

By Asst. Prof. Mitul Ghediya Page | 21

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

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.

Aggregation
• Aggregation represents a “has a” relationship. We use a hollow diamond on the
containing object with a line which joins it to the contained object.
o Aggregation is a specific form of association.
o It is a kind of parent-child relationship however it isn’t inheritance.
o Aggregation occurs when the lifecycle of the contained objects does not
strongly depend on the lifecycle of container objects.

By Asst. Prof. Mitul Ghediya Page | 22

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

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.

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.

By Asst. Prof. Mitul Ghediya Page | 23

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

Purpose of Object Diagrams

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

How to draw an Object Diagram?

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

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

• Create Object Boxes: Draw rectangles to represent the specific instances or objects of
each class. Write the name of each object inside the box.

• Add Attributes and Values: Inside each object box, list the attributes of that object along
with their specific values.

By Asst. Prof. Mitul Ghediya Page | 24

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

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

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

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

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

By Asst. Prof. Mitul Ghediya Page | 25

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

⮚ Collaboration Diagram

What is a Collaboration Diagram?

A Collaboration Diagram (or Communication Diagram) is like a map that shows
how different parts of a system work together by talking to each other.
Imagine a group of friends working on a project—they need to communicate and
share tasks.
A collaboration diagram helps visualize who is talking to whom and what they’re
saying.

Key Parts of a Collaboration Diagram

1. Objects:
What They Are: Think of objects as the different friends in the group project.
Each friend has a specific job, like “John the Developer” or “Emma the Tester.”
- Example: John (who is coding) and Emma (who is testing the code) are objects.

2. Actors:
What They Are: Actors are like the project leader or client who asks the team to
do something. They start the action, like asking the team to build a new feature.
- Example: The client asks John to write a piece of code, and then Emma to test
it.

3. Links:
What They Are: Links are the connections between the friends. It’s like drawing
a line from John to Emma to show that they’re communicating.
- Example: A line between John and Emma shows that John sends the code to
Emma for testing.

By Asst. Prof. Mitul Ghediya Page | 26

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

4. Messages:
What They Are: Messages are what the friends are saying to each other. For
example, John might say, “Emma, can you test this code?” This message has a
sequence, like who says what first.
- Example: John sends a message to Emma to start testing after he finishes
coding.

When to Use a Collaboration Diagram?

Collaboration diagrams are helpful when you need to see how different parts of a
system (or people in a project) are connected and work together. It’s like looking
at how your friends split tasks in a project and communicate with each other.

Examples:
- Organizing a Team Project: Visualize how each team member (like John and
Emma) communicates and shares tasks.
- Designing a System: See how different parts of a software system interact, like
how the login page talks to the database.

How to Create a Collaboration Diagram?

1. Decide the Scenario: Choose what action or task you want to map out, like a
customer placing an order online.
2. Identify the People/Objects Involved: Find out who’s involved—maybe the
customer, the online store, and the payment processor.
3. Set the Scene: Focus on a specific part, like just the payment process.
4. Consider Alternatives: Think about what could happen differently, like what if
the payment doesn’t go through?

By Asst. Prof. Mitul Ghediya Page | 27

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

5. Draw the Diagram: Map out how each part (or person) is connected and how
they communicate.

Benefits of a Collaboration Diagram

- Shows Connections: It’s great for seeing how different parts of a system or
project are linked together.
- Easy to Understand: It simplifies understanding of who is connected to whom,
like mapping out friendships in a group.

Example: Imagine turning a list of steps (like a recipe) into a diagram that shows
which ingredients or tools interact with each other.

Drawbacks
- Can Get Complicated: If there are too many people (or parts), the diagram can
become messy, like a big group chat that’s hard to follow.
- Takes Time to Make: Creating these diagrams can be slow, especially if the
system or project is large.

In short, a collaboration diagram is like a visual map that shows who in a

system (or project) is talking to whom and what they’re saying to each other. It
helps understand the connections but can get complex with too many elements.

By Asst. Prof. Mitul Ghediya Page | 28

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

⮚ Component Diagram

o A Component Diagram is like a blueprint that shows the parts of a system

and how they fit together.

o A Component-Based Diagram, often called a Component Diagram, is a

type of structural diagram in the Unified Modeling Language (UML) that
visualizes the organization and interrelationships of the components within
a system.

o Imagine building a machine with different parts, where each part has a
specific job and connects to others. In the same way, a component diagram
shows different pieces of a software system, like files, libraries, or
programs, and how they connect to make the system work. It helps you
understand what parts are needed and how they interact, without getting
into the details of how each part is made. It's useful for organizing and
understanding the structure of a system.

Notations

1. Component:

o Role: Represent modular parts of the system that encapsulate

functionalities. Components can be software classes, collections of
classes, or subsystems.

o Symbol: Rectangles with the component stereotype («component»).

o Function: Define and encapsulate functionality, ensuring modularity

and reusability.

By Asst. Prof. Mitul Ghediya Page | 29

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

2. Interfaces:

o Role: Specify a set of operations that a component offers or requires,

serving as a contract between the component and its environment.

o Symbol: Circles (lollipops) for provided interfaces and half-circles

(sockets) for required interfaces.

o Function: Define how components communicate with each other,

ensuring that components can be developed and maintained
independently.

By Asst. Prof. Mitul Ghediya Page | 30

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

3. Relationships:

o Role: Depict the connections and dependencies between components

and interfaces.
o Symbol: Lines and arrows.
o Dependency (dashed arrow): Indicates that one component relies on
another.
o Association (solid line): Shows a more permanent relationship between
components.
o Assembly connector: Connects a required interface of one component
to a provided interface of another.
o Function: Visualize how components interact and depend on each
other, highlighting communication paths and potential points of failure.

4. Ports:
o Role: Represent specific interaction points on the boundary of a component
where interfaces are provided or required.
o Symbol: Small squares on the component boundary.
o Function: Allow for more precise specification of interaction points,
facilitating detailed design and implementation.

By Asst. Prof. Mitul Ghediya Page | 31

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

5. Artifacts:
o Role: Represent physical files or data that are deployed on nodes.
o Symbol: Rectangles with the artifact stereotype («artifact»).
o Function: Show how software artifacts, like executables or data files,
relate to the components.

By Asst. Prof. Mitul Ghediya Page | 32

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

6. Nodes:
o Role: Represent physical or virtual execution environments where
components are deployed.
o Symbol: 3D boxes.
o Function: Provide context for deployment, showing where components
reside and execute within the system’s infrastructure.

Steps to Create a Component-Based Diagram

1. Understand the System:

- Define Scope: Know what the system does and what parts to include in the
diagram.

2. Identify Components:
- List Components: Identify the key parts of the system.
- Define Roles: Specify what each component does.

3. Define Interfaces:

By Asst. Prof. Mitul Ghediya Page | 33

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

- Provided Interfaces: Identify what services each component offers.

- Required Interfaces: Determine what services each component needs.

4. Map Relationships:
- Connections: Show how components connect and depend on each other.

5. Identify Artifacts:
- List Artifacts: Identify files, executables, or documents associated with each
component.
- Map Usage: Show how components use these artifacts.

6. Identify Nodes:
- Deployment Locations: Determine where components will be deployed, like
on servers or devices.

7. Draw the Diagram:

- Use Tools: Use software like Lucidchart or Visio.
- Add Components: Draw rectangles for each component.
- Connect Interfaces: Link components using lollipop (provided) and socket
(required) symbols.
- Add Artifacts and Nodes: Place artifacts and nodes in the diagram to show
deployment.

8. Review and Improve:

- Check Accuracy: Ensure everything is correct.
- Get Feedback: Ask others to review it and make improvements as needed.

By Asst. Prof. Mitul Ghediya Page | 34

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

Best practices for creating Component Based Diagrams

Creating Component-Based Diagrams involves several best practices to ensure

clarity, accuracy, and effectiveness in communicating the system’s architecture.
Here are some best practices to follow:

Understand the System:

o Gain a thorough understanding of the system’s requirements,
functionalities, and constraints before creating the diagram.
o Work closely with stakeholders to gather requirements and clarify any
ambiguities.
Keep it Simple:
o Aim for simplicity and clarity in the diagram. Avoid unnecessary
complexity that may confuse readers.
o Break down the system into manageable components and focus on
representing the most important aspects of the architecture.
Use Consistent Naming Conventions:
o Use consistent and meaningful names for components, interfaces, artifacts,
and nodes.
o Follow a naming convention that reflects the system’s domain and is
understandable to all stakeholders.
Group Related Components:
o Group related components together to create cohesive packages or
subsystems.
o Use package diagrams or namespaces to organize components into
logical groupings.
Define Clear Interfaces:
o Clearly define the interfaces provided and required by each component.

By Asst. Prof. Mitul Ghediya Page | 35

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

o Specify the operations and functionalities exposed by each interface in a

concise and understandable manner.
Use Stereotypes and Annotations:
o Use UML stereotypes and annotations to provide additional information
about components, interfaces, and relationships.
o For example, use stereotypes like «component», «interface», «artifact»,
etc., to denote different elements in the diagram.
Maintain Consistency with Other Diagrams:
o Ensure consistency between Component-Based Diagrams and other types
of diagrams (e.g., class diagrams, sequence diagrams).
o Use the same terminology, notation, and naming conventions across all
diagrams to avoid confusion.

By Asst. Prof. Mitul Ghediya Page | 36

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

➢ Use Case Diagram

A UML Use Case Diagram is a visual representation of the interactions between actors (users
or systems) and use cases (functions or features) within a system. It captures the dynamic
behavior of a system, showing what functionalities are provided and how external entities
interact with them. It is mainly used to understand system requirements and is essential for the
analysis phase of software development.

Purpose of Use Case Diagrams

The main purposes of a use case diagram are:

1. Gather System Requirements: It captures all functional requirements by showing the use
cases.
2. Depict External View: It shows how external users or systems (actors) interact with the
system.
3. Identify Influencing Factors: It helps recognize both internal and external factors affecting
the system.
4. Show Actor Interaction: It visualizes the interaction between various actors and the system.

How to Draw a Use Case Diagram?

Follow these steps when drawing a use case diagram:

1. Identify the System’s Functionalities: Before drawing, analyze the system and
identify its major functions. These will become your use cases.
2. Identify the Actors: List the entities (users, external systems) that will interact with
the system. Actors can be people, other systems, or devices that trigger the system’s
functionality.
3. Define the Relationships: Once you know the use cases and actors, define how the
actors interact with the use cases. An actor can interact with multiple use cases, and a
use case can involve multiple actors.
4. Assign Names and Notations: Each actor and use case should have a clear and
meaningful name. Use the appropriate UML notations to show actors, use cases, and
relationships.

By Asst. Prof. Mitul Ghediya Page | 37

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

Key Elements in Use Case Diagram

• Actor: An external entity that interacts with the system (e.g., Customer, Admin).
Represented by a stick figure.

• Use Case: A specific function or feature of the system (e.g., Place Order, Register
Account). Represented by an oval.

• System Boundary: Represents the system or part of the system being modeled. It groups
related use cases.

By Asst. Prof. Mitul Ghediya Page | 38

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

• Relationships:
o Association: A line connecting actors and use cases to show interaction.

o Include: Shows that one use case includes the behavior of another (e.g., Checkout
includes Payment).

o Extend: Shows optional or conditional functionality (e.g., Browse Items extends

View Items).

By Asst. Prof. Mitul Ghediya Page | 39

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

Example of a Use Case Diagram

Online Shopping System Use Case Diagram:

In an Online Shopping System, the Web Customer actor interacts with various use cases
like:

• View Items: Allows customers to browse or search for products.

• Make Purchase: Involves placing an order, which includes:
o Checkout: This involves logging in and confirming the order.
o Payment: Can be done using methods like credit card or PayPal.
• Client Register: Enables customers to create an account for personalized services.

Important Tips for Drawing a Use Case Diagram

• Keep it Simple: The diagram should be easy to understand, focusing on the key interactions.
• Focus on Important Interactions: Highlight the most significant interactions between actors
and the system.
• Generalize Complex Diagrams: If the diagram becomes too complex, consider breaking it
down or generalizing it.
• Represent a Complete Module: Ensure that each use case diagram represents at least one
complete module or functionality of the system.

Example Breakdown (Online Shopping):

In the Online Shopping Use Case Diagram:

• Actors: Web Customer, Payment Service.

• Use Cases:
o View Items (extended by Search Items, Browse Items).

By Asst. Prof. Mitul Ghediya Page | 40

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

o Add to Cart.
o Checkout (which includes Customer Authentication and Payment).
• Relationships:
o Include: Checkout includes Payment.
o Extend: View Items can be extended by Add to Wish List for logged-in users.

This example shows how actors interact with a system to perform tasks like browsing items,
adding them to a cart, and making a purchase. Use cases like Checkout and Payment are
often reused across different parts of the system using include and extend relationships.

Conclusion

A UML Use Case Diagram helps in understanding the system's behavior by showing how
external entities (actors) interact with system functionalities (use cases). It provides a high-
level overview of the system and is a useful tool for gathering requirements and designing
systems efficiently.

By Asst. Prof. Mitul Ghediya Page | 41

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

➢ Sequence Diagram

A UML Sequence Diagram is a type of interaction diagram that shows how processes operate
with one another and in what order. It visualizes the flow of messages between different objects
in a system during a particular interaction. It is also known as an event diagram and helps
model dynamic behavior by portraying the sequence of interactions over time.

Purpose of a Sequence Diagram

• Model High-Level Interactions: It captures how active objects in a system interact over
time.
• Model Object Interactions: It describes the communication between objects within a
system, especially in the context of realizing a use case.
• Depict Specific Scenarios: It can be used to model specific instances or generic interactions
between objects.

Notations in a Sequence Diagram

1. Lifeline:
o Represents an individual participant in the interaction.
o Drawn as a vertical bar below the object's name, showing the timeline of that
object.

2. Actor:
o Represents a role played by an external entity (e.g., user, system, or device)
interacting with the system.
o Actors are represented outside the system’s boundary, usually drawn as stick
figures.

By Asst. Prof. Mitul Ghediya Page | 42

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

3. Activation:
o A thin vertical rectangle on the lifeline that shows when an object is performing an
operation.
o The rectangle's height corresponds to the duration of the operation.

4. Messages:
o Messages are arrows that depict the communication between lifelines (objects or
actors).
o The sequence of messages is the core of the sequence diagram.

By Asst. Prof. Mitul Ghediya Page | 43

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

Types of Messages in a Sequence Diagram

1. Call Message:
o Definition: Represents an invocation of an operation by a lifeline.

o Example: A customer lifeline sending a placeOrder() message to an order system

lifeline.
2. Return Message:
o Definition: Represents the return of data from a called operation back to the caller.

o Example: The order system returns an order confirmation message to the customer
lifeline.
3. Self Message:
o Definition: A message where a lifeline calls an operation on itself.

o Example: A method within a lifeline calling another internal method.

4. Recursive Message:
o Definition: A special case of a self message where a method calls itself recursively.

By Asst. Prof. Mitul Ghediya Page | 44

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

o Example: A method factorial() calling itself for recursive computation.

5. Create Message:
o Definition: A message that creates an instance of a lifeline.

o Example: A createOrder() message creating a new instance of an order.

6. Destroy Message:
o Definition: A message that terminates the lifecycle of a lifeline.

o Example: A closeConnection() message to terminate a session object.

7. Duration Message:
o Definition: Represents the time taken for a message to complete between two
lifelines.

o Example: Modeling a message that takes 5 seconds to send data between two
systems.

By Asst. Prof. Mitul Ghediya Page | 45

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

Sequence Fragments

• Purpose: Sequence fragments make it easier to model complex interactions and maintain
the diagram.

• Fragment Operators: The type of fragment is represented by an operator, such as:

o Alt: Represents alternative paths (like an if-else condition).
o Opt: Represents optional behavior.
o Loop: Represents looping behavior.

Important Tips for Drawing a Sequence Diagram

1. Keep It Simple: Focus on the most important interactions.

2. Use Descriptive Labels: Ensure all actors, messages, and objects are labeled clearly.
3. Follow the Flow: The message flow should be top-down in a logical order.
4. Use Sequence Fragments: To handle complex interactions like conditions or loops.
5. Show Lifetimes: Use activation bars to show when objects are active during the interaction.

Conclusion

A UML Sequence Diagram is a powerful tool for visualizing the flow of messages and
interactions between objects over time. It is commonly used for modeling system behavior
during specific use cases, helping both developers and stakeholders understand how parts of
the system work together.

By Asst. Prof. Mitul Ghediya Page | 46

 Course Code: 2040237201
Course Name: Software
Engineering
SEMESTER: 3

By Asst. Prof. Mitul Ghediya Page | 47