Class Diagram Concepts

A Class Diagram is one of the most commonly used UML diagrams in software design. It provides a static view of a system by depicting its classes, attributes, operations, and the relationships among objects. Class diagrams are vital for object-oriented modeling, as they define the blueprint of a system’s structure.

Core Components of a Class Diagram

1. Class

A class represents a blueprint for objects in the system. It is defined by:

Name: The name of the class (mandatory).
Attributes: The data fields of the class.
Methods (Operations): The functionality or behavior of the class.

Syntax Example:

+----------------+
|    ClassName   |
+----------------+
| - attribute1   |
| - attribute2   |
+----------------+
| + method1()    |
| + method2()    |
+----------------+

Visibility Modifiers:
- + Public
- # Protected
- - Private
Static Fields are underlined. mTotalEmployeeCount, getInstance()

Example:

+------------------------+
|   Employee             |
+------------------------+
| - name: String         |
| - id: int              |
+------------------------+
| + getName(): String    |
| + setId(id: int): void |
+------------------------+

Interfaces (Either in Italics or <<>> brackets)
+-------------------------------+
| <<ClickListenerInterface>>    |
+-------------------------------+
+-------------------------------+
| + onClick(): void             |
+-------------------------------+

2. Relationships

Relationships define how classes are connected. Key relationships in class diagrams include:

2.1. Association

Represents a relationship between two classes.
Example: An Employee works in a Department.

Notation: Solid line between classes. (e.g Employee ―――> Department)

2.2. Aggregation

A specialized association that represents a "whole-part" or "has-a" relationship.
The part can exist independently of the whole.

Notation: Solid line with a hollow diamond near the whole. (Person ―――◇ House, both Person & House can exist independently)

2.3. Composition

A stronger form of aggregation where the part cannot exist without the whole.

Notation: Solid line with a filled diamond near the whole. (RC ―――◆ Vechicle, Nose ―――◆ Human)

2.4. Inheritance (Generalization)

Represents an "is-a" relationship.
Example: A Manager is an Employee.

Notation: Solid line with a hollow arrow pointing to the parent class. (Employee ――(extends)――|> Manager)

2.5. Dependency

Represents a "uses-a" relationship where one class depends on another.
Mostly for implementational uses.

Notation: Dotted line with an open arrow. (--(implements)--|> or Button --(uses a)--|> ClickListener)

Example Class Diagram

Here is an example of a class diagram for a simple employee management system:

+-----------------------------------+
|   Employee                        |
+-----------------------------------+
| - name: String                    |
| - id: int                         |
| - salary: double                  |
+-----------------------------------+
| + getName(): String               |
| + setSalary(salary: double): void |
+-----------------------------------+
       ▲
       |(extends)
+----------------------+
|   Manager            |
+----------------------+
| - department: String |
+----------------------+
| + assignTask(): void |
+----------------------+

+-----------------+       +-----------------+
|   Department    |<――――――|    Employee     |
+-----------------+       +-----------------+
| - name: String  |       |                 |
| - id: int       |       |                 |
+-----------------+       +-----------------+

Steps to Create a Class Diagram

Identify Classes:
- Analyze the requirements to identify classes that represent real-world entities.
Define Attributes and Methods:
- Specify the data and behaviors for each class.
Establish Relationships:
- Determine how the classes interact and connect.
Use a Modeling Tool:
- Use tools like StarUML, Lucidchart, or Microsoft Visio to create the diagram.
Iterate and Review:
- Refine the diagram based on feedback and ensure it aligns with the system’s requirements.

Tools for Class Diagrams

StarUML: A popular open-source UML tool.
Lucidchart: A web-based diagramming tool.
Microsoft Visio: A comprehensive diagramming tool.
Draw.io: A free, web-based tool for creating diagrams.

1. Classes and Their Roles

Vehicle: A base class representing general vehicle attributes (engine, wheel, fuel, and vehicleColor). It is extended by specific types of vehicles.
MotoCycle and Car: Subclasses extending the Vehicle class. These inherit attributes and methods from Vehicle.
VehicleRC: Associated with Car or Motocycle as part of a composition relationship (i.e, the RC details cannot exist without car).
Gender: An enumeration that categorizes gender values (e.g., Male, Female, Other).
Person: A base class representing general details like name, age, and gender. It contains methods for retrieving personal data.
Employee: A subclass of Person, adding specific attributes like id, jobType, and a Vehicle (showing aggregation). Employees can have vehicles linked to them, but vehicles can exist independently.
Manager: A subclass of Employee, inheriting all its properties and methods.
Department: Represents organizational units with attributes like id and name. It has a one-to-many association with Employee, indicating a department can have multiple employees.
EmployeeChangeEvent: Shows an interface used by Department to manage events like onEmployeeAdded and onEmployeeRemoved.

2. Key Relationships

2.1. Inheritance (Generalization):

MotoCycle and Car inherit from Vehicle.
Employee and Manager inherit from Person.

2.2. Association:

Department has a one-to-many association with Employee (indicated by 1 and many).
Person has a dependency relationship with Gender.

2.3. Aggregation:

MotorCycle has a aggregaring relationship with Employee. (indicated by a hollow diamond to whole class).

2.4. Composition:

VehicleRC has a composition relationship with Vehicle (solid diamond with whole class), meaning a registration details cannot exist without vehicle.

2.5. Dependency:

Department depends on the EmployeeChangeEvent interface to trigger employee-related events.

3. Notations and Symbols

Solid lines: Represent associations.
Hollow diamonds: Represent aggregation.
Solid diamonds: Represent composition.
Hollow arrows: Represent inheritance (generalization).
Dotted lines with open arrows: Represent dependencies.
Enumeration (Gender): A special class type with predefined constant values.

The above UML image is generate from PlantUML plugin in android studio. Here is the below code for cited image

@startuml
'https://plantuml.com/sequence-diagram

enum Gender {
    + Male: Int = 0
    + Female: Int = 1
    + Other: Int = 2
}

abstract Person {
    - name: String
    - age: Int
    - gender: Gender
    + getName(): String
    + getAge(): String
    + getGender(): Int
    + {abstract} getJobDescription(): String
}
Gender "1" <-- "1" Person : Uses

class Employee {
    - id : Int
    - gender: Gender
    - vehicle: Vehicle
    - jobType: String
    + {static} LOG_EVENT_ID: Int
    + Employee(id: Int, name: String, age: Int, gender: Gender)
      super(name, age, gender)
    + getId(): Int
    + setJob(type: String):
    + getJob(): String
}

Person <|-- Employee : (extends)

class Manager {
}
Employee <|-- Manager :  (extends)

class Department {
    - id: Int
    - name: String
    - employees: List<Employee>
    + getEmployees(): List<Employee>
    + getEmployee(id: Int): Employee
}

Department "1" -- "many" Employee

interface EmployeeChangeEvent {
    + onEmployeeAdded(): Unit
    + onEmployeeRemoved(): Unit
}
Department ..> EmployeeChangeEvent : (uses a)

abstract class Vehicle {
    + engine: Engine
    + wheel: Wheel
    + fuel: Fuel
    + vehicleColor: Int
}
class MotoCycle {
}
Vehicle <|- MotoCycle : (extends)
MotoCycle --o Employee : (has a)

Class Car {
}
Vehicle <|-- Car : (extends)
Car --o Manager : (has a)

class VehicleRC {
   + vehicleId: Int
   + rcId: Int
}
Vehicle "1" *-- "1" VehicleRC
@enduml

rajeshsahu09/Class Diagram Concepts.md