Classes: Turning CRC Cards into UML Entities

Most teams rush to formalize CRC cards into UML class diagrams too early, treating the transition as a mechanical copy-paste task. But in reality, the real value comes from understanding the *intent* behind each class before drawing lines and rectangles. I’ve seen teams spend hours refining their UML diagrams, only to realize they misrepresented core domain logic because they skipped the mental model shift.

The most effective path isn’t to convert CRC cards into UML in one go, but to treat the CRC session as a collaborative discovery tool and the UML diagram as a structured documentation artifact. This chapter walks you through how to extract meaningful UML entities from CRC cards—focusing on naming, attributes, and namespace decisions that stand the test of time and team turnover.

By the end, you’ll know how to avoid common pitfalls like ambiguous names, inconsistent visibility, or over-engineered models. You’ll also see how CRC class mapping naturally leads to clean, maintainable UML entity extraction—without reinventing the wheel.

From CRC Card to UML Class: The Core Mapping Process

Step 1: Identify the Class and Refine Its Name

Start by reviewing all CRC cards from your brainstorming session. The class name on the card is your first draft—but rarely the final one.

Ask: Does this name reflect the domain’s language? Is it singular and unambiguous? In a logistics system, “Driver” is better than “Truck Operator” if the team uses “Driver” consistently. Avoid vague terms like “System” or “Thing.”

Naming UML classes should follow the same principles as naming variables: be precise, domain-aligned, and consistent with your team’s coding standards.

• Use camelCase or PascalCase (PascalCase is standard in UML).
• Prefer nouns over verbs—“Order” not “Ordering”
• Use plural only when the class represents a collection (e.g., “Customers”)

Step 2: Extract Attributes from Responsibilities

Each responsibility on a CRC card—like “calculate total cost” or “store delivery address”—can point to a method or an attribute. But not all are attributes.

Ask: Is this data something the class holds rather than something it does? If yes, it’s likely an attribute.

For example, “store delivery address” is an attribute. “Calculate total cost” is a method. “Track order status” is a state variable—so it’s an attribute.

Use these rules to guide your extraction:

• If the responsibility is about storing, holding, or containing data, extract as an attribute.
• If the responsibility is about transforming or computing something, it’s a method.
• If the responsibility involves managing state, consider it a property or state variable.

Step 3: Organize Classes into Logical Namespaces

A class like “Customer” might live in multiple contexts—sales, shipping, billing. Naming alone doesn’t tell the whole story.

Use namespaces (or packages in UML) to group related classes. I’ve seen teams use:

• com.example.sales for billing and order processing
• com.example.shipping for delivery tracking and logistics
• com.example.customer for profile, preferences, and contact

These namespaces aren’t just organizational—they help prevent naming conflicts and clarify responsibilities.

Tip: Use domain-driven design boundaries to guide your namespace structure. If your system has distinct domains, group classes accordingly.

Key Patterns in CRC Class Mapping

Not every CRC card translates to a standalone UML class. Some represent roles, interfaces, or collections. Let’s examine common patterns you’ll encounter.

Pattern 1: The Core Entity Class

These are the central actors in your domain—like “Order,” “Invoice,” or “User.” They often have multiple responsibilities involving state, behavior, and relationships.

They should appear as full UML class nodes with:

• Name in PascalCase
• Attributes extracted from storage responsibilities
• Operations from behavioral responsibilities
• Visibility: Public for public methods, private for internal state

Pattern 2: The Value Object

Some CRC cards represent values—like “Address,” “DateRange,” or “PaymentMethod.” These are not independently identifiable, but their state matters.

They should be modeled as value objects in UML, often with a dashed line to the owning class.

Key traits:

• No identity of its own
• Immutable or value-based comparison
• Not persisted independently

Pattern 3: The Role or Interface

Some CRC cards describe a role a class plays—“PaymentProcessor,” “NotificationHandler.” These often map to interfaces or abstract classes.

Ask: Is this a behavior that multiple classes can fulfill? If yes, extract it as an interface.

Example:

• CRC card: “Process payment” → becomes interface PaymentProcessor
• Classes that fulfill it: CreditCardProcessor, PayPalProcessor

Common Mistakes to Avoid

Even experienced teams make these errors when converting CRC class to UML. I’ve seen dozens of models fail because of them.

Mistake	Why It’s Bad	Fix
Using verbs in class names	Breaks consistency, confuses with methods	Change “CustomerOrdering” → “Order”
Forgetting to extract attributes from storage responsibilities	Leads to missing state and poor modeling	Review each “hold” or “store” responsibility
Grouping unrelated classes in the same namespace	Creates confusion, hard to maintain	Use domain boundaries to guide package structure
Misidentifying roles as full classes	Overloads models with unnecessary entities	Map roles to interfaces or abstract classes

Practical Checklist: UML Entity Extraction

Before finalizing your UML class diagram, run this checklist to ensure your CRC-to-UML conversion is sound.

1. Class names are singular, PascalCase, and align with domain language.
2. All storage responsibilities have been mapped to attributes.
3. Every behavioral responsibility is either a method or a related operation.
4. Classes are grouped into logical namespaces based on domain or function.
5. Value objects and roles are not modeled as independent entities unless required.
6. Visibility (public, private, protected) reflects encapsulation goals.

Run this checklist after each iteration. It becomes your design anchor.

Frequently Asked Questions

What’s the difference between CRC class mapping and UML entity extraction?

CRC class mapping is the initial conversion—matching CRC cards to UML elements. UML entity extraction is the deeper process of refining that mapping: deciding what the class truly holds, what it does, and how it fits into the broader system. The former is translation, the latter is design.

Can one CRC card become multiple UML classes?

Yes. If a CRC card lists responsibilities that belong to different concerns (e.g., “calculate total” and “send invoice”), it may need to be split. One class should focus on a single responsibility or domain role. Don’t force everything into one class.

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

Ask: “Does this data persist over time?” If yes → attribute. “Does it involve computation or action?” → method. If it’s both, the class likely has a state and a behavior.

Should I use singular or plural names in UML class diagrams?

Use singular names for classes. “Order” not “Orders.” Use plural only for collections (e.g., Set), not for class names. This keeps the model consistent with object-oriented principles.

What if two CRC cards have the same name?

They may represent the same concept, or different roles in different domains. Use namespaces to disambiguate. For example, “User” in auth vs billing can be auth.User and billing.User.

How do I handle ambiguous responsibilities during UML entity extraction?

When unsure, go back to the team. Ask: “What does this mean in the domain?” Use real examples from user stories or scenarios. The ambiguity often points to a missing abstraction, like a value object or interface.