When diving into the world of software development, one of the most important tasks is identifying the key components or classes that will form the foundation of your system. This process can seem daunting, but with the right approach, it becomes manageable and even intuitive. In this article, I’ll walk you through a simple and effective method for identifying classes, using practical examples and visual aids to make the process clear and straightforward.
Collect all nouns
When it comes to identifying classes, one of the easiest methods is to define a class for every noun found in the requirements. I prefer this approach because it provides a clear starting point. However, as straightforward as it seems, this method quickly generates an overwhelming number of classes. These need to be refined further. Notably, many classes you find initially might only describe the properties of another class. For example, you might find a noun like “color,” which doesn’t deserve to be a class on its own but rather an attribute of another class like “vehicle.”
First, let’s consider a practical example to clarify this process. Imagine we’re working on a project where we’ve identified several nouns: person, age, car, gender, color, vehicle, and man. Now, I need to decide which of these should actually be modeled as classes.
Breaking Down the List
In this list, only two terms — person and vehicle — are genuinely worth modeling as classes. Here’s why:
- Age: This isn’t an independent class; it’s a property of a “person.”
- Car: This is another word for “vehicle,” so we don’t need a separate class.
- Gender: Again, this is a property of a “person,” not a class by itself.
- Color: This is a property of a “vehicle.”
- Man: This is simply a synonym for “person.” Therefore, there’s no need to create a separate class for it.
Thus, we narrow down the nouns to two key classes: Person and Vehicle.
Making Assumptions
Next, I need to confirm some assumptions to ensure consistency in the context of a real development project:
- The concept of “person” must be used consistently throughout the project, not “man.”
- The concept of “vehicle” must be used consistently, not “car.”
- The term “color” should always refer to the color of a vehicle.
These assumptions may seem minor, but they are crucial for maintaining clarity and consistency. If a project or company has a standard language, sticking to that can help avoid confusion.
Final Thoughts
In conclusion, identifying classes is a crucial step in modeling any system. By following a systematic approach—starting with every noun and then refining the list—you can ensure that your model is both accurate and efficient. I find this method, supported by a few well-thought-out assumptions, provides a strong foundation for any development project.
Remember, the key is consistency. When you consistently use terms and concepts, your entire project benefits. Thus, what begins as a simple exercise in identifying nouns evolves into a robust structure for your application or system. So, when you next set out to identify classes, remember: Start with nouns, refine, and confirm assumptions.
This text is based on content from the source: International Requirements Engineering Board (ireb.org). The International Requirements Engineering Board is the owner of the copyright.
| Read more about Jira and How to Use Shortcuts in Jira to Boost Your Productivity Create a Project in Jira Create a Jira Issue: A Step-by-Step Guide Access Confluence and Jira for free |
| Read more about Requirements Modeling Fundamentals Why Model Requirements? Leveraging Applications in Requirements Modeling Modeling Languages for Requirements Modeling Terms and Concepts in Requirements Modeling Requirements modeling vs. design models |