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