When exploring software development, one crucial task is identifying classes that form the system’s foundation. At first, this can feel complex, but with the right mindset, it becomes clear and intuitive. By focusing on real-world elements and their relationships, we can uncover the classes that define structure and behavior. In this article, I’ll guide you through a simple, practical approach to identifying classes, using relatable examples to make the process easy to understand and apply. This article is part of a two-part series. Check out the second article: Identifying Classes (2): with Objects, Roles, and Functions.
I Start With Nouns
When I analyze requirements, I first collect important nouns.
This gives me possible class candidates. However, it is only a starting point.
A noun may represent:
Therefore, I refine the list before I create the UML class model.
I use nouns to find class candidates, but I never assume that every noun represents a class.
I Look for Types and Their Objects
A strong class candidate describes a type of object rather than one individual object.
For example, Person represents a general concept. Sally Brown, Jim Wiener, and Charly Green represent individual persons.
The same principle applies to Car. The class Car can describe several concrete cars.
Therefore, I can use concrete objects to test whether a possible class makes sense.
If several individual objects belong to the same general concept, that concept is a strong class candidate.
Reading the Example
The image shows two classes on the left: Person and Car.
On the right, I see concrete examples.
Sally Brown, Jim Wiener, and Charly Green are individual persons. Therefore, they belong to the general concept Person.
Likewise, the individual cars belong to the class Car.
This distinction helps me identify the correct abstraction level.
I do not create separate classes for Sally Brown, Jim Wiener, or Charly Green. Instead, I recognize them as objects of Person.
Likewise, I do not need a separate class for every individual car.
A class captures what several objects have in common, while an object represents one concrete instance.
I Remove Attributes and Duplicate Concepts
Next, I refine the remaining candidates.
Some nouns describe properties rather than independent concepts. In that case, I model them as attributes instead of classes.
Likewise, different words may describe the same domain concept. Then I choose one clear term and use it consistently.
This step prevents unnecessary classes and keeps the information model understandable.
I keep separate classes only when the concepts have an independent meaning in the requirements.
I Confirm the Terminology
Finally, I check whether I use the selected terms consistently.
If I choose Person as the class name, I use Person consistently for that concept. If I choose Car, I avoid introducing alternative terms unless they represent a meaningful distinction.
This matters because inconsistent terminology can create apparent differences that do not exist in the domain.
Therefore, class identification also helps me establish a clearer project vocabulary.
Conclusion
Identifying classes starts with nouns, but noun collection alone does not create a useful class model.
I first collect possible concepts. Then, I distinguish general types from concrete objects, attributes, and duplicate terms.
The Person and Car example shows this principle clearly. Person and Car represent general classes, while Sally Brown, Jim Wiener, Charly Green, and the individual cars represent concrete objects.
I identify a useful UML class when a term represents a relevant general concept that can have concrete instances.
Now jump to the second part: Identifying Classes (2): with Objects, Roles, and Functions.
Discover the Complete Picture with Requirements Modeling
If I want to understand requirements in a clearer and more structured way, I need more than text alone. I need models that make ideas, workflows, and relationships visible. 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 analyze systems more effectively, communicate requirements more clearly, and create a stronger foundation for successful system design.
This article covers concepts that are also included in the CPRE certification syllabus.