When building software, it’s essential to break a system into clear, manageable parts. One of the most important steps is identifying classes that represent the system’s core structure. While it may seem challenging at first, a structured approach makes it much easier. By analyzing objects, their roles, and their functions, we can systematically identify meaningful classes. In this article, I’ll guide you through a practical and effective method to make identifying classes both logical and intuitive. If you haven’t read the first article yet, open it here: Identifying Classes (1): A Heuristical Approach.
Finding Classes Through Objects
I first look for tangible and intangible objects that matter to the system.
Typical examples include:
- Person
- Book
- Club
A Person represents something physical. A Club does not. However, both can represent relevant concepts with their own information and relationships.
Therefore, physical existence does not determine whether something should become a class.
I consider an object a useful class candidate when the system needs to store, process, or relate information about it.
In article Identifying Classes (1): A Heuristical Approach I present the heuristic approach to identifying classes. Check out this article if you want to learn more about identifying classes.
Finding Classes Through Roles
Next, I examine roles.
A role describes the position or responsibility that something has within a particular context. For example, a Person may act as a Driver or Student. Likewise, a user may act as an Administrator.
Whether I model the role as its own class depends on whether the distinction matters to the requirements.
For example, Student becomes useful as a separate concept when the system needs student-specific information such as a student number or enrollment date.
Example: Defining the Student Class
In the example, I model Student as a class with three attributes:
- Student number
- Name
- Enrollment date
I also add a textual description that defines what Student means within this particular system.
The description gives the class additional context, while the attributes define relevant information about its instances.
The Student class combines relevant attributes with a textual description that clarifies its meaning in the system.
Finding Classes Through Functions
Finally, I examine the functions that the system must support.
A function itself does not automatically become a class. However, it often points me toward information that needs representation.
For example, a system may support placing and processing an Order. The activity is not the class. However, Order can become a class because the system needs information such as an order number, date, or ordered items.
The same reasoning can apply to Delivery or Report when these concepts contain information that the system needs to manage.
I use functions to discover the information objects that those functions create, use, or change.
Context Determines the Meaning
Class names alone are often not enough.
Therefore, I define important concepts within the context of the system. Attributes already provide part of this meaning. However, I can add a textual description when the intended interpretation needs further clarification.
The Student example demonstrates this approach. Student has a specific meaning in the modeled system. The additional description makes that meaning explicit.
As a result, stakeholders do not have to guess what I mean by the class.
Conclusion
I use objects, roles, and functions as practical perspectives for identifying UML classes.
Objects often provide direct candidates. Roles help me identify context-specific concepts such as Student. Functions help me discover information that the system must manage.
However, I always check whether the candidate has an independent meaning within the requirements.
I create a class when a concept represents relevant information that the system needs to understand and distinguish.
In article Identifying Classes (1): A Heuristical Approach I present the heuristic approach to identifying classes. Check out this article if you want to learn more about identifying classes.
See How Requirements Modeling Brings Structure to Complexity
If I want to make requirements easier to understand, I need more than text alone. I need models that show how ideas, processes, and system structures connect. In the main article on Requirements Modeling, I explore essential Modeling Concepts, Process Modeling with BPMN, and the structural perspective of UML. Together, these topics help me visualize requirements more clearly, communicate them more effectively, and build a stronger foundation for analysis, design, and successful system development.
This article covers concepts that are also included in the CPRE certification syllabus.