When building software, understanding how to break down your system into manageable parts is crucial. One of the key tasks is identifying the right classes. This can seem daunting, but with a structured approach, it becomes much simpler. Today, I’ll walk you through a practical method for identifying classes using objects, roles, and functions.
Finding Classes by Focusing on Objects, Roles, and Functions
When I’m trying to identify classes, I begin by categorizing potential candidates into three main areas:
- Objects (tangible or intangible)
- Roles
- Functions
By narrowing down the options to these categories, I can quickly cut through the noise and focus on the essentials. This approach significantly reduces the overwhelming list of nouns that typically emerge during the analysis phase.
Tangible and Intangible Objects
Objects, both tangible and intangible, are often the easiest starting point. Tangible objects are physical things we can touch and see. Intangible objects, while not physically present, are just as important in our systems.
For instance, when I think about a car, it’s clearly a tangible object. But what about a leave application? It’s intangible, yet it’s crucial for a system that manages employee time off. Both tangible and intangible objects play a vital role in system requirements. They either interact with the system or the system represents the respective objects.
Example objects:
- Person: A user of the system or an entity that the system tracks.
- Book: Something that can be borrowed, returned, or searched in a library system.
- Club: A group or association that has members and activities.
Roles as Separate Classes
Roles add another layer of understanding to our class identification. When I consider a role, I think about how an object might take on different forms or responsibilities within the system.
For example, imagine a person who takes on the role of a driver. In this case, the driver is not just any person but a person specifically in charge of driving a car. Another example is the residence: while it might seem like just an address, in a system, the address of a person’s primary home could define the residence.
Example roles:
- Driver: A specific role that a person might play in a transportation system.
- Student: A person in the role of a learner within an educational platform.
- Administrator: A user with elevated privileges in a software application.
Functions in the Information Model
Finally, I turn my attention to functions. In any system, there are processes that need support, and these often require relevant information. However, it’s important to remember that a function itself isn’t necessarily a class. Instead, it’s the information related to the function that might turn into a class.
Let’s take an order as an example. The order itself is a function that involves placing, processing, and completing it. However, the order, as a noun, represents something concrete that might be a class in the information model.
Example functions:
- Delivery: A process where a package transfers from one location to another, with relevant information like delivery date and recipient.
- Order: A request for products or services, where details like order number, date, and items occur as part of the class.
- Report: A document or summary created based on data, which could be modeled as a class storing the report’s details.
Clearly present the context
An information model’s key feature is that the terms it defines are placed within a clear context. This, along with the attribute definitions, usually provides much of the meaning needed. If more explanations are required, you can add text descriptions and link them to the relevant class.
In this example, the class “Student” has the attributes Student number, Name and Enrollment date. To the left, the corresponding description is shown graphically as a modeling addition.
Wrapping It All Up
Identifying classes by focusing on objects, roles, and functions is a method that simplifies the design process. It’s all about starting broad and then narrowing down. By carefully considering each category, I can systematically develop a robust class structure that accurately reflects the real-world processes my system needs to support.
In your projects, try visualizing the connections between these elements. Whether it’s a role diagram, a flowchart, or a simple list, these visuals can provide clarity and direction as you refine your system’s design.
Remember, this is just one approach. But it’s a powerful one that has served me well. So next time you’re faced with the task of identifying classes, give this method a try. You might find it’s exactly what you need to bring order to the chaos of system design.
In article Identifying Classes (1): A Heuristical Approach I present a heuristic approach to identifying classes (opens in a new tab). Check out this article if you want to learn more about identifying classes.
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.