UML digrams

Unified modeling language, there are multiple places where this is used.

Can be divided into 2 types --

Out of all, we mostly use the class digram for LLD.

Class diagrams provide a high-level overview of a system's design, helping to communicate and document the structure of the software.

Class digram --

• 

• class Name

• attributes

• Metods/operations

• Visibility notations

  • Visibility notations indicate the access level of attributes and methods. Common visibility notations include:

    • + for public (visible to all classes)

    • - for private (visible only within the class)

    • # for protected (visible to subclasses)

    • ~ for package or default visibility (visible to classes in the same package)

Now if there are multiple classes we can interlink them to make a suitable working scenario. to do that we use notations --

We have following relation ships --

• Composition --

  • Composition is a stronger form of aggregation, indicating a more significant ownership or dependency relationship.

  • In composition, the part class cannot exist independently of the whole class.

  • ex — Imagine a digital contact book application. The contact book is the whole, and each contact entry is a part. Each contact entry is fully owned and managed by the contact book. If the contact book is deleted or destroyed, all associated contact entries are also removed.

• Directed Association --

  • A directed association in a UML class diagram represents a relationship between two classes where the association has a direction, indicating that one class is associated with another in a specific way.

  • ex — Consider a scenario where a "Teacher" class is associated with a "Course" class in a university system. The directed association arrow may point from the "Teacher" class to the "Course" class, indicating that a teacher is associated with or teaches a specific course.

• Usage(Dependency) Relationship

  • A usage dependency relationship in a UML class diagram indicates that one class (the client) utilizes or depends on another class (the supplier) to perform certain tasks or access certain functionality.

  • The client class relies on the services provided by the supplier class but does not own or create instances of it.

  • ex — Consider a scenario where a "Car" class depends on a "FuelTank" class to manage fuel consumption.

• Generalization(Inheritance)

  • Inheritance represents an "is-a" relationship between classes, where one class (the subclass or child) inherits the properties and behaviors of another class (the superclass or parent).

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

• Aggregation

  • Aggregation is a specialized form of association that represents a "whole-part" relationship.

  • It denotes a stronger relationship where one class (the whole) contains or is composed of another class (the part).

  • Aggregation is represented by a diamond shape on the side of the whole class. In this kind of relationship, the child class can exist independently of its parent class.

  • ex — The company can be considered as the whole, while the employees are the parts. Employees belong to the company, and the company can have multiple employees. However, if the company ceases to exist, the employees can still exist independently.

• Association

  • An association represents a bi-directional relationship between two classes. It indicates that instances of one class are connected to instances of another class.

  • Associations are typically depicted as a solid line connecting the classes, with optional arrows indicating the direction of the relationship.

  • ex — Let's consider a simple system for managing a library. In this system, we have two main entities: Book and Library. Each Library contains multiple Books, and each Book belongs to a specific Library. This relationship between Library and Book represents an association.

• Dependency Relationship

  • A dependency exists between two classes when one class relies on another, but the relationship is not as strong as association or inheritance. It represents a more loosely coupled connection between classes.

  • Let's consider a scenario where a Person depends on a Book.

    • Person Class: Represents an individual who reads a book. The Person class depends on the Book class to access and read the content.

    • Book Class: Represents a book that contains content to be read by a person. The Book class is independent and can exist without the Person class.

    The Person class depends on the Book class because it requires access to a book to read its content. However, the Book class does not depend on the Person class; it can exist independently and does not rely on the Person class for its functionality.

• Realization (Interface Implementation)

  • Realization indicates that a class implements the features of an interface. It is often used in cases where a class realizes the operations defined by an interface.

  • Let's consider the scenario where a "Person" and a "Corporation" both realizing an "Owner" interface.

    • Owner Interface: This interface now includes methods such as "acquire(property)" and "dispose(property)" to represent actions related to acquiring and disposing of property.

    • Person Class (Realization): The Person class implements the Owner interface, providing concrete implementations for the "acquire(property)" and "dispose(property)" methods. For instance, a person can acquire ownership of a house or dispose of a car.

    • Corporation Class (Realization): Similarly, the Corporation class also implements the Owner interface, offering specific implementations for the "acquire(property)" and "dispose(property)" methods. For example, a corporation can acquire ownership of real estate properties or dispose of company vehicles.

    Both the Person and Corporation classes realize the Owner interface, meaning they provide concrete implementations for the "acquire(property)" and "dispose(property)" methods defined in the interface.

CHATGPT --

Here’s a comprehensive UML Class Diagram Cheat Sheet with definitions, symbols, and examples for every concept.

---

UML Class Diagram Cheat Sheet (with Examples)

1. Class Declaration Syntax

+-----------------------------+
|         ClassName          |
+-----------------------------+
| - attribute1: Type         |
| # attribute2: Type         |
| + attribute3: Type         |
+-----------------------------+
| + method1(param: Type): ReturnType |
| - method2(): void         |
+-----------------------------+

Visibility Modifiers

Symbol	Meaning
+	Public
-	Private
#	Protected
~	Package

✅ Example

+-----------------------------+
|         Person             |
+-----------------------------+
| - name: String             |
| - age: int                 |
+-----------------------------+
| + getName(): String        |
| + setName(name: String): void |
+-----------------------------+

---

2. Relationships

🔗 Association

Represents a “has-a” relationship.

Person ---------> Car

Example: A Person owns a Car.

+--------+       +------+
| Person |       | Car  |
+--------+       +------+
| name   |       | make |
+--------+       +------+

---

3. Aggregation (Shared Ownership)

“Whole-part” relationship where the part can exist independently.

School <>------ Student

Example:

A School has Students, but a Student can exist without a School.

---

4. Composition (Strong Ownership)

“Whole-part” relationship where the part cannot exist without the whole.

House ◼------ Room

Example: A Room cannot exist without a House.

---

5. Inheritance / Generalization

A “is-a” relationship

Employee ⬆
     ▲
  Manager

Example:

Employee
+ name
+ salary

Manager : Employee
+ department

---

6. Realization (Interface Implementation)

Driver ◁──── Drivable (interface)

Example:

interface Drivable
+ drive(): void

class Driver implements Drivable
+ drive(): void

---

7. Dependency

One class uses another temporarily (parameter, local variable).

Order --> PaymentProcessor

Example:

Order
+ processOrder(p: PaymentProcessor): void

---

3. Multiplicity

Symbol	Meaning
1	Exactly one
0..1	Zero or one
*	Zero or more (many)
1..*	One or more
n..m	From n to m

Example

Customer "1" -------- "0..*" Order

A Customer can place multiple Orders.

---

4. Abstract Class & Method

• Italicize class name or method name to show it’s abstract.

Example:

__________________________
|      *Shape*          |
|------------------------|
| + color: String        |
|------------------------|
| + *draw(): void*       |
|________________________|

     ▲
     |
__________________________
|     Circle             |
|------------------------|
| + radius: double       |
|------------------------|
| + draw(): void         |
|________________________|

---

5. Interface

• Represented like a class but with <<interface>>

Example:

<<interface>> Drawable
+ draw(): void

---

6. Static vs Instance Members

• Underline static methods or attributes

Example:

Class Utils
---------------------
+ __PI__: double
+ __calculate(): int

---

Summary Table

Concept	Symbol	Example
Class	Box	Person
Association	—	Person — Car
Aggregation	◇	School ◇— Student
Composition	◼	House ◼— Room
Inheritance	▲	Employee ⬆ Manager
Realization	◁	Driver ◁— Drivable
Dependency	dashed	Order --> PaymentProcessor
Interface	<< >>	<<interface>> Drawable
Abstract	italic	*draw()*
Multiplicity	1..*, 0..1	Customer 1 — 0..* Order
Static	Underline	__calculate()

---