Unified Modeling Language (UML)
Diagrams
Unified Modeling Language (UML) is a standardized visual
modeling
language that is a versatile, flexible, and user-friendly method for
visualizing a system’s design. Software system artifacts can be
specified, visualized, built, and documented with the use of UML.
Types of UML Diagrams
UML is linked with object-oriented design and analysis. UML
makes use of elements and forms associations between them to
form diagrams. Diagrams in UML can be broadly classified as:
CLASS DIAGRAM
In object-oriented programming (OOP), a class is a blueprint
or template for creating objects. Objects are instances of
classes, and each class defines a set of attributes (data
members) and methods (functions or procedures) that the
objects created from that class will possess. The attributes
represent the characteristics or properties of the object, while
the methods define the behaviors or actions that the object
can perform.
UML Class Notation
class notation is a graphical representation used to depict
classes and their relationships in object-oriented modeling.
1. Class Name:
The name of the class is typically written in the top
compartment of the class box and is centered and bold.
2. Attributes:
Attributes, also known as properties or fields, represent
the data members of the class. They are listed in the
second compartment of the class box and often include
the visibility (e.g., public, private) and the data type of
each attribute.
3. Methods:
Methods, also known as functions or operations,
represent the behavior or functionality of the class. They
are listed in the third compartment of the class box and
include the visibility (e.g., public, private), return type,
and parameters of each method.
4. Visibility Notation:
Visibility notations indicate the access level of attributes
and methods. Common visibility notations include:
o + for public (visible to all classes)
o - for private (visible only within the class)
o # for protected (visible to subclasses)
o ~ for package or default visibility
(visible to classes in the
same package)
Relationships between classes
In UML diagrams, relationships are used to link several things. It is a
connection between structural, behavioral, or grouping things.
Following are the standard UML relationships enlisted below:
o Association
o Dependency
o Generalization
Association
Association relationship is a structural relationship in which different
objects are linked within the system. It exhibits a binary relationship
between the objects representing an activity. It depicts the relationship
between objects, such as a teacher, can be associated with multiple
teachers.
Example:
1) A single teacher has multiple students.
2) A single student can associate with many teachers.
Aggregation
Aggregation is a subset of association, is a collection of different
things. It represents has a relationship. It is more specific than an
association. It describes a part-whole or part-of relationship. It is a
binary association, i.e., it only involves two classes. It is a kind of
relationship in which the child is independent of its parent.
For example:
Here we are considering a car and a wheel example. A car cannot
move without a wheel. But the wheel can be independently used with
the bike, scooter, cycle, or any other vehicle. The wheel object can
exist without the car object, which proves to be an aggregation
relationship.
Composition
The composition is a part of aggregation, and it portrays the whole-
part relationship. It depicts dependency between a composite (parent)
and its parts (children), which means that if the composite is
discarded, so will its parts get deleted. It exists between similar
objects.
As you can see from the example given below, the composition
association relationship connects the Person class with Brain class,
Heart class, and Legs class. If the person is destroyed, the brain, heart,
and legs will also get discarded.
Class Diagram Example: Order System
UML - Object Diagrams
Object diagrams are derived from class diagrams
so object diagrams are dependent upon class
diagrams.
Object diagrams represent an instance of a class
diagram.
Use Case Diagrams
In the Unified Modeling Language (UML), a use case diagram
can summarize the details of your system's users (also known
as actors) and their interactions with the system.
Use Case Diagram Notations
UML notations provide a visual language that enables
software developers, designers, and other stakeholders
to
communicate and document system designs, architectures,
and behaviors in a consistent and understandable manner.
1. Actors
Actors are external entities that interact with the system.
These can include users, other systems, or hardware devices.
In the context of a Use Case Diagram, actors initiate use
cases and receive the outcomes. Proper identification and
understanding
of actors are crucial for accurately modeling system behavior.
2. Use Cases
Use cases are like scenes in the play. They represent specific
things your system can do. In the online shopping system,
examples of use cases could be "Place Order," "Track
Delivery," or "Update Product Information". Use cases are
represented by ovals.
3. System Boundary
The system boundary is a visual representation of the scope
or limits of the system you are modeling. It defines what is
inside the system and what is outside. The boundary helps to
establish a clear distinction between the elements that are part
of the system and those that are external to it. The system
boundary is typically represented by a rectangular box that
surrounds all the use cases of the system.
The purpose of system boundary is to clearly outlines the
boundaries of the system, indicating which components are
internal to the system and which are external actors or
entities interacting with the system.
Use Case Diagram Relationships
In a Use Case Diagram, relationships play a crucial role in
depicting the interactions between actors and use cases. These
relationships provide a comprehensive view of the system's
functionality and its various scenarios. Let's delve into the
key
types of relationships and explore examples to illustrate their
usage.
1. Association Relationship
The Association Relationship represents a communication or
interaction between an actor and a use case. It is depicted by a
line connecting the actor to the use case. This relationship
signifies that the actor is involved in the functionality
described by the use case.
Example: Online Banking System
Actor: Customer
Use Case: Transfer Funds
Association: A line connecting the "Customer" actor to the
"Transfer Funds" use case, indicating the customer's
involvement in the funds transfer process.
2. Include Relationship
The Include Relationship indicates that a use case includes
the functionality of another use case. It is denoted by a
dashed arrow pointing from the including use case to the
included use
case. This relationship promotes modular and reusable
design.
Example: Social Media Posting
Use Cases: Compose Post, Add Image
Include Relationship: The "Compose Post" use case
includes the functionality of "Add Image." Therefore,
composing a post includes the action of adding an image.
3. Extend Relationship
The Extend Relationship illustrates that a use case can be
extended by another use case under specific conditions. It is
represented by a dashed arrow with the keyword "extend."
This relationship is useful for handling optional or
exceptional behavior.
Example: Flight Booking System
Use Cases: Book Flight, Select Seat
Extend Relationship: The "Select Seat" use case may
extend the "Book Flight" use case when the user wants to
choose a specific seat, but it is an optional step.
4. Generalization Relationship
The Generalization Relationship establishes an "is-a"
connection between two use cases, indicating that one use
case
is a specialized version of another. It is represented by an
arrow pointing from the specialized use case to the general
use case.
Example: Vehicle Rental System
Use Cases: Rent Car, Rent Bike
Generalization Relationship: Both "Rent Car" and "Rent
Bike" are specialized versions of the general use case "Rent
Vehicle."