In the previous chapter, we introduced the Unified Modeling Language (UML) as a visual language for communicating software designs.

One of the most useful UML diagrams during the early stages of software design is the Class Diagram.

While requirements, use cases, and wireframes help us understand what a system should do and how users will interact with it, class diagrams help us understand what information the system must manage and how different pieces of information relate to one another.

Before writing code, software teams need to decide what data will be stored, how those data are organized, and how different objects within the system interact. Class diagrams provide a visual model that helps answer these questions.

What Is A Class Diagram?

A Class Diagram is a UML diagram that describes the structure of a software system.

It shows:

• the classes that make up the system,
• the information stored within each class,
• the behaviours associated with each class, and
• the relationships between classes.

Together, these elements provide a blueprint for the software’s structure.

Although class diagrams are closely associated with object-oriented programming, they are valuable long before implementation begins. They help development teams think carefully about how information should be organized and often reveal missing requirements or inconsistencies in the design.

What Is A Class?

A class is a description or blueprint for a particular type of object.

For example, imagine designing software for a public library.

You might identify classes such as:

• Book
• Member
• Loan
• Librarian

Each class represents a type of thing the system must understand.

Individual books, members, and loans become objects or instances created from these classes during execution of the software.

Think of a class as the architectural blueprint for a house.

The blueprint describes what every house should contain, while each house that is built from the blueprint is an individual object.

The Three Parts Of A Class

A class is usually represented as a rectangle divided into three sections.

Class Name

The top section contains the name of the class.

Class names are usually written as singular nouns because they describe one type of object.

Examples include:

• Student
• Appointment
• Invoice
• Volunteer

Good class names are descriptive and easy to understand.

Attributes

The middle section lists the attributes of the class.

Attributes describe the information stored about each object.

For a Student class, the attributes might include (and often its type):

• studentID
• firstName
• lastName
• email
• program

Each object created from the Student class would have its own values for these attributes.

When identifying attributes, ask yourself:

What information must the system remember about this object?

Methods

The bottom section lists the methods (sometimes called operations).

Methods describe the actions that objects of the class can perform.

For example, a Student class might include method such as:

• registerForCourse()
• updateEmail()
• viewGrades()

During early design, it is common to identify only the most important operations.

Depending on the project, each method might also include input and output types.

The purpose of the class diagram is to communicate the overall design rather than every implementation detail.

Relationships Between Classes

Class diagrams become most useful when they show how different classes relate to one another.

For example:

• A Student enrolls in many Courses.
• A Library Member borrows many Books.
• An Order contains one or more Products.

These relationships help software teams understand how information moves through the system.

As you develop your class diagram, continually ask:

• Which classes need to know about each other?
• How are they connected?
• Is this relationship one-to-one, one-to-many, or many-to-many?

Thinking carefully about these relationships often uncovers missing requirements or design problems before implementation begins.

Identifying Classes

Many classes can be identified directly from your requirements and use cases.

A useful starting point is to review your requirements and look for nouns.

For example, consider the requirement:

Users can reserve a tennis court online.

Possible classes include:

• User
• Reservation
• Tennis Court

Not every noun should become a class, but this approach often provides a helpful starting point.

After identifying possible classes, ask:

• Does the system need to store information about this?
• Does it have multiple attributes?
• Does it participate in important relationships?
• Does it have behaviours of its own?

If the answer is yes, it is likely a good candidate for a class.

Developing A Class Diagram

Class diagrams are rarely perfect on the first attempt.

As your understanding of the system improves, your diagram will evolve.

A typical process might look like this:

1. Review the requirements and use cases.
2. Identify potential classes.
3. Determine the attributes each class should contain.
4. Identify important operations.
5. Draw the relationships between classes.
6. Review the diagram with your team and revise it based on feedback.

Like every prototype in this course, a class diagram is intended to support discussion and refinement.

It is much easier to modify a diagram than to redesign working software.

Class Diagrams In CIS3750

Throughout this course, class diagrams will help you organize the information managed by your software.

They should reflect everything you have learned through:

• your requirements,
• user stories,
• use cases,
• paper prototyping sessions,
• wireframes, and
• conversations with your community partner.

As your design evolves, your class diagram should evolve with it.

Remember that a class diagram is not simply documentation.

It is a design tool that helps your team think critically about the structure of the system before implementation begins.

Looking Ahead

Class diagrams describe what information exists within a system and how that information is organized.

In the next chapter, we’ll explore Sequence Diagrams, which focus on how objects communicate with one another while carrying out a particular task.

Together, class diagrams and sequence diagrams provide complementary views of a software system—one describing its structure, the other its behaviour.