Unit - III

Unified Modeling Language (UML) and it’s

Basic Structure
Unified Modeling Language (UML): A General Introduction
Unified Modeling Language (UML) is a standardized modeling
language used in software engineering for visualizing, specifying,
constructing, and documenting the artifacts of a software system.
UML was created by the Object Management Group (OMG) and
UML 1.0 specification draft was proposed to the OMG in January
1997. OMG is continuously making efforts to create a truly
industry standard.
It provides a standard way to visualize the design of a system, making
it easier to understand, communicate, and document complex
software architectures.
•UML stands for Unified Modeling Language.

•UML is different from the other common programming languages such as C+

+, Java, COBOL, etc.

•UML is a pictorial language used to make software blueprints.

•UML can be described as a general purpose visual modeling language to

visualize, specify, construct, and document software system.

•Although UML is generally used to model software systems, it is not limited

within this boundary. It is also used to model non-software systems as well.

•UML is not a programming language but tools can be used to generate code in
various languages using UML diagrams. UML has a direct relation with object
oriented analysis and design.
Features of UML:

1. Visual Representation:
UML uses various diagrams to represent different aspects of a system. These diagrams are
graphical representations of different elements within the system and their relationships.
2. Abstraction:
UML allows developers to create abstract models of a system, which means focusing on
the essential aspects of the system while ignoring the non-essential details. This
abstraction helps in understanding the system at a higher level without getting non-
essential details.
3. Modularity:
UML supports the modular representation of systems. Complex systems can be broken
down into smaller, manageable modules, and these modules can be represented and
understood individually, simplifying the overall system design process.
4. Standardization:
UML provides a standardized way of representing software designs. This standardization
ensures that developers, analysts, and stakeholders, regardless of their background,
can understand the system's structure and behavior using the same set of symbols and
diagrams.

5. Communication:
One of the primary purposes of UML is to facilitate communication between different
stakeholders involved in a software project. It acts as a common language that
developers, designers, clients, and other stakeholders can use to discuss and
understand the system's requirements and design.
UML Diagrams

UML supports various types of diagrams, each serving a specific purpose in the
software development lifecycle:
1. Class Diagrams:
Represent the static structure of the system, showing classes, their attributes,
methods, and relationships.
2. Use Case Diagrams:
Describe the interactions between the system and its users, depicting various use
cases and the actors (users) involved in the system.
3. Sequence Diagrams:
Illustrate how objects interact with each other and the order of these interactions,
displaying the messages exchanged between objects over time.
4. Activity Diagrams:
Depict the workflow in a system, representing the flow of activities and
actions within a process or a use case.
5. State Machine Diagrams:
Model the states of an object and the transitions between these states in
response to events.
6. Component Diagrams:
Show the physical components of the system and their relationships,
helping in understanding the system's architecture.
7. Deployment Diagrams:
Illustrate the physical deployment of software components in hardware
nodes, servers, and other computing devices.
Benefits of UML

1. Clarity and Understanding:

UML diagrams provide a clear and visual way to understand the system's architecture and
behavior, making it easier for stakeholders to comprehend complex software designs.
2. Effective Communication:
UML acts as a common language, enabling effective communication among team members
and stakeholders, leading to better collaboration and fewer misunderstandings.
3. Improved Design:
By using UML, developers can create well-structured, modular designs, leading to more
efficient and maintainable software systems.
4. Documentation:
UML diagrams serve as excellent documentation tools, helping developers and future
maintainers understand the system without delving into lengthy textual descriptions.
Goals of UML
• A picture is worth a thousand words, this idiom absolutely fits describing UML. Object-
oriented concepts were introduced much earlier than UML. At that point of time, there
were no standard methodologies to organize and consolidate the object-oriented
development. It was then that UML came into picture.

• There are a number of goals for developing UML but the most important is to define
some general purpose modeling language, which all modelers can use and it also
needs to be made simple to understand and use.

• UML diagrams are not only made for developers but also for business users, common
people, and anybody interested to understand the system. The system can be a
software or non-software system. Thus it must be clear that UML is not a
development method rather it accompanies with processes to make it a successful
system.

• In conclusion, the goal of UML can be defined as a simple modeling mechanism to

model all possible practical systems in today’s complex environment.
A Conceptual Model of UML

•A conceptual model can be defined as a model which is made of

concepts and their relationships.

•A conceptual model is the first step before drawing a UML diagram. It

helps to understand the entities in the real world and how they interact
with each other.

As UML describes the real-time systems, it is very important to make a

conceptual model and then proceed gradually.

In the conceptual model of there are following three major elements

−
•UML building blocks;
•Rules to connect the building blocks;
•Common mechanisms of UML.
 UML - Building
Blocksblocks of UML can be defined as −
The building
•Things
•Relationships
•Diagrams

Things
Things are the most important building blocks of UML.
Things can be −
•Structural
•Behavioral
•Grouping
•Annotational
Structural Things

Structural thing can be defined as the static part of the model. They represent the physical and
conceptual elements. Following are the brief descriptions of the structural things.

Class − Class represents a set of objects having similar responsibilities.

Interface − Interface defines a set of operations, which specify the responsibility of a class.

Collaboration −Collaboration defines an interaction between elements.

Use case −Use case represents a set of actions performed by a system for a specific goal.

Component −Component describes the physical part of a system.

Node − A node can be defined as a physical element that exists at run time.
Behavioral Things

A behavioral thing consists of the dynamic parts of UML models.

Following are the behavioral things −

Interaction − Interaction is defined as a behavior that consists of a group of messages

exchanged among elements to accomplish a specific task.

State − State is useful when the state of an object in its life cycle is important. It defines
the sequence of states an object goes through in response to events. Events are
external factors responsible for state change
Grouping Things

Grouping things can be defined as a mechanism to group elements

of a UML model together.

There is only one grouping thing available −

Package − Package is the only one grouping thing available for

gathering structural and behavioral things.
Annotational Things

Annotational things can be defined as a mechanism to capture remarks, descriptions, and

comments of UML model elements.

Note - It is the only one Annotational thing available. A note is used to render comments,
constraints, etc. of an UML element.
Relationship
Relationship is another most important building block of UML. It shows how the elements are
associated with each other and this association describes the functionality of an application.

There are four kinds of relationships available.

Dependency

Dependency is a relationship between two things in which change in one element also affects the other.

Association
Association is basically a set of links that connects the elements of a UML model. It also describes how many
objects are taking part in that relationship.

Generalization
Generalization can be defined as a relationship which connects a specialized element with a
generalized element. It basically describes the inheritance relationship in the world of objects.
UML Diagrams
UML diagrams are the ultimate output of the entire discussion. All the elements,
relationships are used to make a complete UML diagram and the diagram represents
a system.

The visual effect of the UML diagram is the most important part of the entire
process. All the other elements are used to make it complete.

UML includes the following nine diagrams -

•Class diagram
•Object diagram
•Use case diagram
•Sequence diagram
•Collaboration diagram
•Activity diagram
•Statechart diagram
•Deployment diagram
•Component diagram
UML - Architecture

Before designing a system, the architecture is made with different

perspectives in mind. The most important part is to visualize the
system from the perspective of different viewers.

The better we understand the better we can build the system.

UML plays an important role in defining different perspectives of a

system. These perspectives are −
•Design
•Implementation
•Process
•Deployment
The center is the Use Case view which connects all these four.

Use Case represents the functionality of the system. Hence, other perspectives are connected
with use case.

Design of a system consists of classes, interfaces, and collaboration. UML provides class
diagram, object diagram to support this.

Implementation defines the components assembled together to make a complete physical

system. UML component diagram is used to support the implementation perspective.

Process defines the flow of the system. Hence, the same elements as used in Design are also
used to support this perspective.

Deployment represents the physical nodes of the system that forms the hardware. UML
deployment diagram is used to support this perspective.
Modeling Techniques in UML
Unified Modeling Language (UML) provides several modeling techniques that allow
software developers to visually represent different aspects of a software system. Here
are some common modeling techniques used in UML:

1. Use Case Diagrams:

Use case diagrams depict the interactions between external actors and the system. They
show how users interact with a system to accomplish specific goals. Its elements are
Actors (represent external users or systems) and Use Cases (represent specific
functionalities or features).

2. Class Diagrams:
Class diagrams illustrate the structure of the system by showing classes, their attributes,
methods, and relationships between classes. Its elements are Classes, Attributes,
Methods, Associations, Generalization (Inheritance), Aggregation, Composition.
3. Sequence Diagrams:
Sequence diagrams visualize the interactions between objects or components over time.
They show the order of messages exchanged between objects. Its elements are Lifelines
(represent objects), Messages, Activation Bars, Combined Fragments, Interaction Use.

4. Activity Diagrams:
Activity diagrams illustrate the workflow within a system. They show the flow of activities,
actions, and decisions. Its elements are Initial Node, Activity, Decision Node, Merge Node,
Fork Node, Join Node, Swimlanes (represent organizational units).

5. State Machine Diagrams:

State machine diagrams depict the states and transitions of an object or a system. They
are useful for modeling the behavior of entities over time. Its elements are States,
Transitions, Initial State, Final State, Events, Actions, Guards.
6. Component Diagrams:
Component diagrams illustrate the physical components of a system and their
dependencies. They show how the system is decomposed into smaller components. Its
elements are Components, Interfaces, Dependencies, Ports.

7. Deployment Diagrams:
Deployment diagrams show the physical deployment of software components on hardware
nodes. They illustrate how software is mapped onto hardware. Its elements are Nodes
(represent hardware devices), Components, Associations.

8. Object Diagrams:
Object diagrams represent specific instances of classes at a particular moment in time. They
show the objects and their relationships during runtime. Its elements are Objects, Links,
Attributes, Associations.
9. Package Diagrams:
Package diagrams organize the elements of a system into packages, allowing for better
management of large systems. Its elements are Packages, Classes, Interfaces,
Dependencies.

10. Communication Diagrams:

Communication diagrams (also known as collaboration diagrams) show how objects
interact and collaborate to achieve a specific task. Its elements are Objects, Links,
Messages.

These UML modeling techniques are widely used in software engineering to visualize,
specify, construct, and document software systems. The choice of technique depends on
the aspect of the system being modeled and the level of detail required for
communication among stakeholders.
CLASS DIAGRAMS

Class diagrams in UML (Unified Modeling Language) are a type of static

structure diagram that provides a visual representation of the classes,
interfaces, associations, and relationships within a system. Class diagrams
are widely used in software engineering for modeling the structure of
object-oriented systems. They depict the static structure of a system,
capturing its entities and their relationships.
Elements of Class Diagrams:
1. Class:
Represents a blueprint for objects. It defines attributes (data members) and methods (functions) that
the objects of the class will have.
Example: `Person`, `Car`, `Book`.
2. Association:
Represents a relationship between classes. It shows how objects of one class are related to objects of
another class. Associations can have multiplicities (such as 1, 0..1, 0..), indicating how many instances
of each class are involved in the association.
Example: An association between `Student` and `Course` classes can represent the enrollment
relationship.
3. Multiplicity:
Indicates the number of instances participating in a relationship. It is denoted by numbers or asterisks
() and helps specify how many objects are involved in an association.
Example: `0..1` (zero or one), `1` (exactly one), `` (zero or more).
4. Inheritance (Generalization):
Represents an "is-a" relationship between classes. It shows that one class (subclass or
derived class) inherits properties and behaviors from another class (superclass or base
class).
Example: `Engineer` class inheriting from `Person` class.

5. Interface:
Represents a collection of abstract methods. Classes can implement interfaces, ensuring
they provide specific behaviors.
Example: `Drawable` interface might have methods like `draw()` and `resize()`.

6. Abstract Class:
Represents a class that cannot be instantiated on its own. It may contain abstract methods
(methods without implementations) that subclasses must implement. Abstract classes are
denoted by italicized class names.
7. Dependency:
Represents a relationship where one class relies on another class. It is a weaker
relationship compared to association.
Example: Class A depends on class B if class A uses class B as a parameter in one of its
methods.

Class diagrams provide a clear and concise way to represent the static structure of a
system, enabling developers to understand the relationships between different classes
and how they collaborate to achieve specific functionalities within the software
application.
Aggregation and composition in Class Diagram

Aggregation and composition are both types of associations in

UML class diagrams that represent relationships between
classes. They indicate how objects of one class are connected to
objects of another class.
Aggregation (Has-A Relationship):

Aggregation represents a weaker form of association where one class (the whole or
container) contains objects of another class (the part) as part of its state. The part class
objects can exist independently of the whole class. Aggregation is often represented by a
diamond shape on the class diagram. Aggregated objects have an independent lifecycle.
They can exist even if the whole object is destroyed. Aggregation is represented by a
diamond-shaped line connecting the classes, with a line connecting the diamond to the
part class.

Example:
Consider a `University` class and a `Department` class. A department is part of a university,
and it can exist independently even if the university is shut down. This is an example of
aggregation.
Composition (Part-Of Relationship):

Composition represents a stronger form of association where one class (the whole or
container) contains objects of another class (the part) as part of its state. The part class
objects cannot exist without the whole class. If the whole class is destroyed, all its
composed parts are also destroyed. Composition is represented by a filled diamond shape
on the class diagram. Composed objects have a dependent lifecycle. They cannot exist
independently of the whole object. Composition is represented by a filled diamond-
shaped line connecting the classes, with a line connecting the diamond to the part class.

Example:
Consider a `Car` class and an `Engine` class. An engine is a part of a car, and it cannot exist
without a car. If the car is dismantled, the engine is also no longer usable. This is an
example of composition.
So, aggregation and composition both represent relationships between
classes, but they differ in the strength of the relationship and the
lifecycle dependency between the whole and the part objects.
Aggregation implies a weaker, independent relationship, while
composition implies a stronger, dependent relationship. The choice
between aggregation and composition depends on the specific
requirements and semantics of the relationship being modeled in the
software system.
OBJECT DIAGRAM

An object diagram in UML (Unified Modeling Language) is a diagram that

provides a snapshot of the objects in a system at a particular point in time.
It shows instances of classes and their relationships, representing real-
world examples of objects and their interactions within the system. Object
diagrams are used to visualize and test the behavior of the system during
specific scenarios or use cases.
Components of Object Diagrams:
1. Objects: Objects represent instances of classes in the system. They have specific
attribute values and can be linked to other objects through associations.

2. Classes: While class diagrams represent the structure and blueprint of classes, object
diagrams show instances of these classes. Each object belongs to a specific class.

3. Attributes: Objects have attribute values, which are specific to the instances
represented in the object diagram. Attributes reflect the current state of the objects.

4. Associations: Associations between objects represent relationships between instances

of classes. Associations in object diagrams illustrate specific instances participating in
relationships.
Object Diagram Example:
Consider the following simplified class diagram:
- Classes: `Person`, `Address`
- Associations: `Person` has an association with `Address`.

In an object diagram, an example snapshot of objects might look like this:

- Objects:
- `person1` of class `Person`
- Attributes: Name = "Alice", Age = 30
- Association: Has an `address` object.
- `address1` of class `Address`
- Attributes: Street = "123 Main St", City = "Exampleville"

In this object diagram, `person1` is an instance of the `Person` class with specific attribute values ("Alice",
30), and it is associated with `address1`, an instance of the `Address` class with specific attribute values
("123 Main St", "Exampleville").
Use of Object Diagrams:
1. Testing Scenarios: Object diagrams can be used to represent specific test cases or
scenarios to ensure that the system behaves as expected in certain conditions.
2. Visualization: They provide a clear visualization of how objects interact with each other
and can help in understanding the runtime behavior of the system.
3. Communication: Object diagrams can be used for communication between stakeholders,
especially when discussing specific instances and relationships within the system.
4. Debugging: During the debugging process, object diagrams can aid in understanding the
state of specific objects and their relationships, helping developers identify issues more
effectively.

Object diagrams, along with class diagrams, sequence diagrams, and other UML diagrams,
provide a comprehensive view of an object-oriented system from different perspectives,
aiding in the understanding, design, and development of software systems.
USE CASES IN UML

In UML (Unified Modeling Language), a use case is a graphical and

textual representation of a system's functionality from an external
user's perspective. It describes a set of interactions between a
system (or subject) and external entities (called actors) to
accomplish a specific goal or task. Use cases are commonly
employed in software engineering to capture, define, and organize
system requirements, providing a clear understanding of the
system's behavior without delving into the internal details of the
system's implementation.
Components of a Use Case:
1. Use Case Name: A descriptive name that succinctly summarizes the specific functionality
or task being described.
2. Actors: External entities that interact with the system. Actors can be users, other systems,
or even hardware devices.
3. Description: A brief narrative describing the purpose and functionality of the use case.
4. Preconditions: Conditions that must be true before the use case can be executed.
5. Postconditions: Conditions that will be true after the use case has been executed
successfully.
6. Basic Flow: A sequence of steps representing the normal, expected flow of events in the
use case.
7. Alternative Flows: Sequences of steps that represent deviations from the basic flow,
often due to exceptional or error conditions.
8. Exceptions: Specific conditions that might cause the use case to fail or deviate from its
normal flow.
Example Use Case: Withdraw Cash from ATM
Use Case Name: Withdraw Cash
Actors: Customer, ATM System, Bank
Description: This use case allows a customer to withdraw cash from an ATM using a valid bank card.
Preconditions: Customer must have a valid bank card, and the ATM must have sufficient cash.
Postconditions: Customer receives the requested amount of cash, and the ATM deducts the amount from the
customer's account.
Basic Flow:
1. Customer inserts the bank card.
2. Customer enters the PIN.
3. Customer selects the withdrawal option and enters the desired amount.
4. ATM validates the PIN and checks the account balance.
5. If the balance is sufficient, ATM dispenses the cash.
6. Customer takes the cash and the card.
Alternative Flow (Incorrect PIN): If the customer enters an incorrect PIN, the system prompts for the correct
PIN, allowing three attempts. After three unsuccessful attempts, the card is retained.
So, Use cases are typically depicted graphically using UML diagrams, such as
use case diagrams, which provide a visual representation of the system's
use cases and actors, showing how they interact with each other. Use case
diagrams are valuable for communicating and understanding the functional
requirements of a system, making them an essential part of software
development processes.
NEED OF USE CASE DIAGRAM

Use case diagrams in UML (Unified Modeling Language) serve several crucial purposes in the
software development process, making them an essential tool for communication, analysis,
and design. Here are the key reasons for the need of use case diagrams:

1. Understanding User Requirements: Use case diagrams help in eliciting, organizing, and
understanding user requirements by capturing the interactions between users (actors) and
the system. They provide a clear and concise overview of what the system is supposed to do
from an external perspective.

2. Communication with Stakeholders: Use case diagrams provide a visual and intuitive way
to communicate complex system behavior to stakeholders, including clients, users, and
developers, who may have varying technical backgrounds. They facilitate discussions and
ensure a common understanding among different parties involved in the project.
3. Focus on User Goals: Use cases focus on the goals that users want to achieve with
the system. By identifying and modeling these goals, developers can prioritize features
and functionalities that directly contribute to fulfilling user needs.
4. Basis for System Design: Use case diagrams serve as a foundation for system design
and development. They provide a high-level view of system functionality, guiding the
design process and helping developers understand the system's overall structure and
behavior.
5. Identification of System Boundaries: Use case diagrams help define the boundaries
of the system by identifying external entities (actors) and their interactions with the
system. This clarifies what is inside the system and what is external to it.
6. Use in Requirements Analysis: Use case diagrams are instrumental in requirements
analysis. They aid in identifying, organizing, and prioritizing use cases, which are then
detailed further to capture detailed requirements, including system behaviors, data
flows, and user interactions.
 7. Basis for Test Cases: Use cases serve as the basis for generating test cases. Each use case
can be transformed into a series of test scenarios, allowing for systematic testing of the
system's functionalities.
8. Support for Iterative Development: In agile and iterative development methodologies,
use case diagrams provide a flexible framework for understanding user requirements and
adapting the system incrementally based on user feedback and changing needs.
9. Documentation: Use case diagrams, along with detailed use case descriptions, provide
essential documentation for the system. They serve as a reference for developers, testers,
and other stakeholders throughout the development lifecycle.

So, use case diagrams play a central role in capturing user requirements, facilitating
communication, guiding system design, and ensuring that the developed system aligns with
user needs. They provide a user-centered perspective, helping teams focus on building
features that matter most to the end-users of the software.
INTERACTION DIAGRAM IN UML

Interaction diagrams in UML (Unified Modeling Language) are used

to visualize the dynamic aspects of a system, specifically how objects
within the system interact with each other and how those
interactions occur over time. Interaction diagrams include sequence
diagrams and communication diagrams. Both types of diagrams
focus on the exchange of messages among objects but represent
these interactions differently.
Sequence Diagrams:
Sequence diagrams show the interactions between objects in a sequential manner,
representing the flow of messages and actions over time. They are particularly useful for
modeling scenarios where the order of interactions is important.

Components of Sequence Diagram:

1. Objects: Represent instances of classes involved in the interaction.
2. Lifelines: Vertical lines representing the lifespan of objects during the interaction.
3. Messages: Arrows indicating the flow of messages between objects.
4. Activation Bars: Horizontal bars on lifelines indicating the duration of an object's activity.

Sequence diagrams are useful for detailing the interactions between objects in a specific use
case, showing the order of method calls and the flow of data. They provide a clear visual
representation of the flow of control and data between objects, helping in understanding
complex system behavior.
Communication Diagrams (Collaboration Diagrams):

Communication diagrams, also known as collaboration diagrams, emphasize the relationships between objects
and their interactions, focusing on the structural organization of objects in the system. They are less concerned
with the sequence of messages and more concerned with the associations and links between objects.

Components of Collaboration Diagram:

1. Objects: Represent instances of classes participating in the interaction.
2. Links: Lines connecting objects to represent associations between them.
3. Messages: Arrows indicating the flow of messages between objects (optional).

Communication diagrams are useful for showing the relationships and associations between objects in a system,
providing a clear overview of how objects collaborate. Understanding Object Structure: They help in visualizing
the structural aspects of the system by showing how objects are connected and communicate with each other.
Use of Interaction Diagrams:
1. Use interaction diagrams when modeling complex scenarios where the
interaction between objects needs to be detailed and understood.
2. Use them to illustrate the behavior of objects during specific use cases or
scenarios, emphasizing the flow of messages and data.

So, interaction diagrams in UML are valuable tools for modeling dynamic
aspects of a system, illustrating how objects collaborate, communicate, and
interact over time. The choice between sequence diagrams and
communication diagrams depends on the specific focus of the modeling task:
sequence diagrams emphasize the sequence of messages, while
communication diagrams focus on structural relationships between objects.
Difference between Interaction Diagram and Use Case Diagram
Interaction Diagrams and Use Case Diagrams serve different purposes in the Unified Modeling Language (UML) and are
used to model different aspects of a software system.
Differences are:
Interaction Diagrams:
1. Purpose: Interaction diagrams (such as sequence diagrams and communication diagrams) focus on illustrating the
dynamic behavior of a system by showing how objects interact and communicate with each other over time. They depict
the flow of messages and the sequence of interactions between objects during specific scenarios or use cases.
2. Components:
- Objects: Instances of classes participating in the interaction.
- Messages: Represent the communication and interactions between objects.
- Lifelines: Show the lifespan of objects during the interaction.
- Activation Bars: Indicate the duration of an object's activity.
3. Usage:
1. Interaction diagrams are used to model specific scenarios, showing how objects collaborate to achieve specific
functionalities or tasks.
2. They are particularly useful for detailing the sequence of method calls, the flow of control, and data between objects
during a specific use case.
Use Case Diagrams:

1. Purpose: Use Case Diagrams focus on capturing the functional requirements of a system from an external
perspective. They provide a high-level view of the system's functionalities and how external actors (users, systems)
interact with the system. Use case diagrams do not delve into the internal interactions between objects.

2. Components:
1. Use Cases: Represent specific functionalities or tasks that the system provides to its users.
2. Actors: External entities (users, systems) that interact with the system.
3. Associations: Connect actors with use cases to indicate the relationships between them.

3. Usage:
4. Use case diagrams are used during the early stages of software development to capture, define, and organize
system requirements.
5. They provide a high-level overview of the system's features and the actors involved in using or interacting with
those features.
6. Use case diagrams are valuable for communicating with stakeholders, ensuring that developers and users have a
shared understanding of the system's functionality.
So, main differences between both type of diagrams are:

1. Focus: Interaction diagrams focus on the dynamic behavior and interactions between objects, while use
case diagrams focus on the external functionalities and interactions between actors and the system.
2. Granularity: Interaction diagrams are more detailed and specific, showing the sequence of object
interactions during specific use cases. Use case diagrams provide a high-level, abstract view of the system's
functionalities.
3. Representation: Interaction diagrams use objects, messages, and lifelines to represent interactions
between classes and objects. Use case diagrams use actors and use cases to represent external entities
and system functionalities.

So, interaction diagrams are used to model dynamic behavior and object interactions during specific use
cases, while use case diagrams provide an overview of the system's functionalities and external interactions.
Both types of diagrams are essential tools in software modeling, addressing different aspects of system
development.