Heuristics for Determining Attributes

Class box titled “Student” listing “Student Number” and “Average Mark,” with underlined “Is Eligible To Enroll” and “Get Seminars Taken”; partial “Professor” box on the right.

When working in object-oriented design, identifying the right attributes can seem challenging at first. But with the right guidance, it becomes much simpler. Heuristics for determining attributes provide practical rules to distinguish between classes and their properties, ensuring a clear and consistent model. These heuristics help refine system structure and improve design quality. In this article, I’ll share my personal approach to applying heuristics for determining attributes effectively.

Nouns Combined With a Genitive

First, I look for structures such as “the X of the Y.”

For example:

  • the date of the order
  • the diameter of the circle
  • the color of the car

Here, date, diameter, and color are strong attribute candidates. Order, Circle, and Car represent the related classes.

The “X of Y” structure often shows that X describes a property of Y.

Sentences With “Has”

Another useful pattern is a sentence in which something “has” a property.

For example:

  • a person has a date of birth
  • an address has a postal code
  • a process has a transition time

In these cases, date of birth, postal code, and transition time can become attributes.

However, I still check the meaning. A “has” relationship can also describe a relationship between two classes.

Adjectives Combined With Nouns

Adjectives often reveal attributes indirectly.

For example:

  • a fast car
  • a large display
  • a red car

The adjective describes a characteristic. Therefore, I translate the characteristic into an attribute.

For “large display,” I can identify Display as the class and Size as the attribute. Large then represents a possible value of Size.

An adjective often points to an attribute, while the adjective itself represents a possible value.

Example showing how the phrase large display can be modeled as a Display class with a Size attribute.
The phrase “large display” can lead to the class Display with Size as an attribute and large as its value.

Sentences With “Is”

I also examine statements that use “is.”

For example:

  • the person is an adult
  • the application is approved

Here, adult and approved usually represent values rather than attributes.

Therefore, I need to identify the underlying attribute. Adult may relate to age or an adult status. Approved may relate to the status of an application.

The value mentioned in a requirement can help me discover an attribute that the sentence does not name directly.

Attributes Can Help Distinguish Objects

Finally, I check whether the attributes provide enough information to distinguish relevant objects.

For example, first name and last name may not uniquely distinguish two people named James Miller. A date of birth can add another distinguishing property.

Therefore, requirements about identification can reveal additional attributes.

However, I only add such attributes when the system actually needs them.

Conclusion

I use language patterns as practical heuristics for identifying UML attributes.

Genitive constructions can reveal ownership of a property. “Has” statements often point directly to attributes. Adjectives can reveal an attribute and its value. Finally, “is” statements can expose values that lead me to the underlying property.

These heuristics give me useful attribute candidates, but I always confirm them against the meaning of the requirements.

What’s Next?!

Now that you’ve learned how heuristics for determining attributes can sharpen your object-oriented models, it’s time to take the next step. In my upcoming article, “How to Determine Simple UML Relationships with Heuristics,” I’ll show how to apply similar principles to identify meaningful connections between classes. Join me to discover how these techniques make your UML diagrams clearer, more consistent, and easier to understand.

Build a Clearer System View with Requirements Modeling

If I want to understand requirements in a structured and visual way, I need more than text alone. In the main article on Requirements Modeling, I explore Modeling Concepts, Process Modeling with BPMN, and UML to show how these perspectives work together. Therefore, I can make workflows, relationships, and system structures much easier to understand. Click through to see how Requirements Modeling helps me turn complex requirements into clear, practical, and useful models.


This article covers concepts that are also included in the CPRE certification syllabus.

Scroll to Top
WordPress Cookie Plugin by Real Cookie Banner