Responsibilities Become Operations and Attributes

Every operation in your class diagram started as a CRC responsibility. That’s the truth. No exceptions.

When you write “calculate total” on a CRC card, you’re not just brainstorming—you’re defining a method. The trick isn’t just recognizing this, but distinguishing whether that responsibility becomes a method, an attribute, or a constraint. It’s the difference between a sketch and a working design.

Over two decades of guiding teams through CRC-to-UML transitions has taught me this: the most common mistake isn’t over-engineering—it’s misclassifying what a responsibility actually is.

This chapter gives you the tools to turn every CRC responsibility into a precise UML operation or attribute. You’ll learn how to read the intention behind the wording, avoid common pitfalls, and build models that reflect real behavior—not just structure.

Understanding the Nature of CRC Responsibilities

Before mapping, you must understand what a CRC responsibility truly is.

It’s not a task. Not a feature. It’s an action or state tied to an object’s role in a collaboration.

Think of it as a promise: “This class will do X” or “This class will hold Y.” The key is whether it describes behavior (do) or data (hold).

How to Identify Behavioral vs. Data Responsibilities

Use this simple rule: if the responsibility involves an action verb, it’s likely a method. If it describes a value or property, it’s likely an attribute.

• Behavioral: calculate total, validate input, send confirmation → Operation
• Data-related: store customer details, track order status, keep payment records → Attribute

But don’t stop here. Some responsibilities are subtle. “Manage inventory levels” sounds behavioral—but if it refers to a state, it might be an attribute like inventoryCount.

From Responsibility to UML Method: The Three-Step Process

Turning a CRC responsibility into a UML method isn’t just renaming—it’s refining intent into proper syntax.

Step 1: Extract the Verb and Object

Look for the action and what it acts on. In “calculate total for order,” the verb is “calculate,” and the object is “total for order.”

That gives you:

• Operation name: calculateTotalForOrder
• Parameters: order: Order
• Return type: double or Money

Simple, but often missed when teams rush to code.

Step 2: Determine Visibility and Return Type

Use this decision tree:

• If the method modifies internal state or affects other objects → public or protected
• If it only retrieves information → public or private, depending on access needs
• If it returns a value, define the type explicitly. Don’t assume Object or String.

For example, “validate input” isn’t just boolean validateInput(). It’s better as boolean validateInput(String input), with a clear return meaning.

Step 3: Avoid Overloading with Vague Concepts

Weak responsibilities like “do something” or “handle data” are red flags.

Ask: What exactly is being done? Who is it done to? What’s the outcome?

Instead of:

handle data

Ask: What kind of data? Who triggers this? What should happen?

Refine it to:

• processPayment(Payment payment)
• updateInventoryAfterShipment(Shipment shipment)

This isn’t just cleaner—it’s testable and traceable.

From Responsibility to Attribute: When Data Rules

Not every responsibility becomes a method. Some are about state.

These are the ones that describe what the object stores, tracks, or maintains.

Recognizing Data-Centric Responsibilities

Look for these keywords:

• “keep”, “maintain”, “track”, “store”, “record”, “hold”
• “total”, “count”, “status”, “balance”, “date”

For example:

• track order status → status: OrderStatus
• store customer details → customerDetails: Map<String, Object>
• keep payment records → paymentHistory: List<Payment>

These aren’t methods. They’re state variables.

When to Extract Attributes: A Decision Matrix

Responsibility	Reason to Extract as Attribute	Example
track delivery date	State value, not an action	deliveryDate: LocalDate
calculate tax	Behavior → method	calculateTax(amount: double): double
store order history	Collection of data	orderHistory: List<Order>
manage inventory levels	State tracker	inventoryCount: int

This table isn’t just for reference—it’s a filter. Use it to avoid misclassifying responsibilities.

Handling Constraints and Implicit Rules

Some CRC responsibilities aren’t operations or attributes—they’re constraints.

They define invariants or business rules. For example:

• total must be positive
• order cannot be shipped if not approved
• customer must have valid ID

These don’t become methods or attributes directly. Instead, they become:

• Pre-conditions or post-conditions in method contracts
• Class-level invariant annotations (e.g., invariant: total > 0)
• Validation logic in constructors or setters

For example:

operation calculateTotal(): Money
  pre: order.isApproved()
  post: total > 0

This preserves the rule without bloating the class with unnecessary methods.

Best Practices for Consistent Responsibility Mapping

Here’s what I’ve seen work best across teams—no fluff, just principles.

1. Use active verbs for operations: “send email,” “update status,” “calculate tax.” Never “is sending” or “doing.”
2. Extract attributes only when they represent state: If the object doesn’t store it, don’t make it an attribute.
3. Be consistent with naming: Use camelCase or PascalCase uniformly. Avoid mixing “getTotal” and “get_total”.
4. Group related responsibilities during refinement: Don’t split “calculate total” and “apply discount” unless the logic is modular.
5. Review for redundancy: If two responsibilities do the same thing, merge them. If one is unused, question it.

These aren’t rules. They’re habits. And habits shape code quality more than any diagram.

Common Mistakes in Responsibility Mapping

Even experienced teams make these errors. Watch for them:

• Overloading methods: “handle data” or “do something” that leads to long, ambiguous methods.
• Creating attributes from behavior: “manage order” as an attribute instead of a method.
• Ignoring return types: Writing methods with no return type, especially when logic should return a value.
• Using attributes for complex logic: Storing “tax calculation” as a field instead of computing it on demand.
• Misreading collaboration cues: Confusing a responsibility for a class’s role in an interaction with a method.

Fix them early. The sooner you spot a mismatch, the less you’ll pay in rework.

Frequently Asked Questions

How do I know if a CRC responsibility should be a method or an attribute?

Ask: Does it describe an action (do) or a state (have)? If it’s an action, make it a method. If it’s a value the object holds, make it an attribute. Use the decision matrix above to guide you.

Can a single CRC responsibility become multiple UML operations?

Yes, but only if it’s ambiguous or covers multiple concerns. For example, “process order” should be split into “validateOrder,” “calculateTotal,” and “confirmShipment” if they’re independent. Keep methods focused.

What if my CRC responsibility is phrased as a noun, like “customer list”?

That’s a strong signal for an attribute. “customerList” → customerList: List<Customer>. But verify it’s not meant to be a method like “retrieveCustomerList()”.

Should I use the same method name as the CRC responsibility?

Not necessarily. Use the CRC as a starting point. Refine it into a proper, unambiguous method name. “get data” becomes “fetchOrderHistory()”. Clarity beats literalness.

Can I treat a constraint as a method?

Only if it involves behavior. A business rule like “total must be positive” should be enforced in a method (e.g., setTotal) via a validation check. But the rule itself is not a method—it’s a condition.

How do I avoid creating unnecessary methods from vague CRC responsibilities?

Apply the “intent test”: Ask, “What must the system do?” and “Who triggers this?” If the answer is vague, refine the responsibility before converting it. Use checklists like the one above to filter out weak concepts.

Remember: Every method should have a clear reason to exist. If you can’t explain its purpose in one sentence, it probably doesn’t belong.