T01: Defining Classes

4.1.1 What Is a Class Diagram?

A class diagram models the static structure of a system.

Unlike:

• Flowcharts → model process flow

• Sequence diagrams → model interaction over time

Class diagrams model:

• Objects

• Attributes

• Methods

• Visibility

• Static structure

They are fundamental to:

• Object-Oriented Design (OOD)

• Domain modeling

• API contract documentation

• System architecture planning

In Mermaid, every class diagram begins with:

---

4.1.2 Basic Class Declaration

The simplest possible class:

This creates a class named User.

At this level, we are defining only the existence of the class.

---

4.1.3 Adding Attributes

Attributes define the state of a class.

Syntax:

class ClassName {
    type attributeName
}

Example:

This models a User with three attributes.

---

4.1.4 Adding Methods

Methods define behavior.

Syntax:

returnType methodName()

Example:

Here:

• login() and logout() are methods.

• + indicates public visibility.

---

4.1.5 Visibility Modifiers

Mermaid supports UML-style visibility symbols:

Symbol	Meaning
+	Public
-	Private
#	Protected
~	Package/Internal

Example:

This indicates:

• password is private

• login() is public

• validateCredentials() is protected

Visibility helps communicate encapsulation principles.

---

4.1.6 Full Class Definition Example

This class includes:

• Public attributes

• Private attributes

• Public methods

It represents a typical domain entity.

---

4.1.7 Data Types in Class Diagrams

Mermaid does not enforce strict typing, but common conventions include:

• int

• string

• float

• boolean

• Date

• List<Type>

Example:

Use consistent data type conventions throughout your diagram.

---

4.1.8 Parameterized Methods

Methods can include parameters.

This resembles real-world service contracts.

---

4.1.9 Static Methods and Attributes

Static members can be shown using $.

Example:

Static members belong to the class, not the instance.

---

4.1.10 Real-World Example — E-Commerce Domain

At this stage, we are defining classes only — relationships will be covered later.

---

4.1.11 Organizing Large Classes

For clarity:

• Group attributes first

• Then methods

• Keep consistent indentation

• Avoid excessive detail

Bad practice:

int id
+login()
string name

Good practice:

int id
string name
+login()

Consistency improves readability.

---

4.1.12 Minimal vs Detailed Class

Minimal:

Detailed:

Choose level of detail based on purpose:

• High-level architecture → minimal

• Design documentation → detailed

---

4.1.13 Refactoring Example (Hands-On)

Start simple:

Enhance it:

Now it resembles a real service model.

---

4.1.14 Common Beginner Mistakes

1. Forgetting classDiagram keyword

2. Mixing relationship syntax prematurely

3. Inconsistent indentation

4. Overloading classes with too many attributes

5. Ignoring visibility

Incorrect:

class User
    int name

Correct:

class User {
    string name
}

---

4.1.15 Hands-On Exercise

Design a Library System with:

Classes:

• Book

• Member

• Loan

Requirements:

• Each class must have at least 2 attributes

• Each class must have at least 1 method

• Use visibility modifiers

• Keep types consistent

Focus only on defining classes — do not add relationships yet.

---

4.1.16 Best Practices for Class Definition

• Use meaningful class names

• Follow consistent naming convention (PascalCase)

• Keep attributes grouped

• Include only relevant methods

• Model domain logic, not implementation detail

Remember:

A class diagram represents structure, not runtime behavior.

---

4.1.17 Key Takeaways

Defining classes in Mermaid involves:

• Declaring class names

• Adding attributes

• Adding methods

• Applying visibility modifiers

• Maintaining structural clarity

You are modeling static system structure, not execution flow.

In the next topic, we will explore Relationships and Multiplicity, which define how classes connect and interact structurally.