Translating complex business requirements into a robust software architecture is one of the most challenging aspects of software engineering. How do you bridge the gap between human language and object-oriented code? The answer lies in Noun/Verb Analysis, also known as Grammatical Inspection.
This technique leverages the natural structure of the language used to describe a problem domain. By systematically extracting nouns to identify system classes and verbs to identify object behaviors, developers and analysts can create a comprehensive, accurate, and structured Domain Model. This guide will walk you through the methodology, core concepts, and practical application of noun/verb analysis to design effective UML class diagrams.
Before diving into the step-by-step process, it is essential to understand the foundational concepts of grammatical inspection:
Nouns (Entities & Classes): In object-oriented analysis, nouns and noun phrases typically represent the "things" in your system. These become your Classes, Objects, or Attributes.
Verbs (Behaviors & Operations): Verbs describe the actions, interactions, or state changes involving the nouns. These translate into Operations (Methods), Services, or Relationships between classes.
Domain Model: A visual representation (usually a UML Class Diagram) of the conceptual classes in the problem domain, their attributes, and their relationships, devoid of implementation-specific details.
Association Class: A special UML construct used to resolve many-to-many relationships. It acts as both an association (link) between two classes and a class itself, holding attributes specific to the relationship.
PascalCase Convention: The standard naming convention for classes in UML and most object-oriented languages, where a noun phrase is combined and each word is capitalized (e.g., ShippingInformation).
The fundamental strategy of this technique is to find as many nouns as possible at the start and wait until later stages of modeling to analyze, refine, and expand that list.
You cannot analyze what you do not have. Start by gathering all materials that define the "arena" or problem domain the new system is supposed to solve. Cast a wide net and collect:
High-level requirements documents: Business Requirement Documents (BRD), user stories, and use case descriptions.
Marketing materials: Brochures, product descriptions, and feature lists that highlight how the product is sold and perceived.
Rapid prototypes: Wireframes, HTML mockups, or UI sketches. These are invaluable as they help explore requirements directly with users and reveal implicit system interactions.
Read through your gathered materials line by line. Your goal is to identify and extract as many nouns and noun phrases as possible.
Rule of thumb: Do not filter or judge the nouns at this stage. Just extract them.
Formatting: Convert multi-word noun phrases into single PascalCase terms (e.g., "customer account" becomes CustomerAccount).
Example: A mental review of a prototype bookstore page might yield immediate candidates like:
Book
Author
Publisher
Review
Reviewer
Static documents only show a fraction of the system's reality. Move beyond what is visible on a single page and envision the dynamic workflows. How will a user actually interact with the system over time? This mental walkthrough reveals hidden, process-driven classes.
Example: If a user decides to purchase a Book, new nouns naturally emerge from the workflow:
The anonymous viewer becomes a registered Customer.
The selected Book is added to a shopping cart, becoming part of an Order.
To complete the Order, the system requires BillingInformation and ShippingInformation.
Once you have a massive initial list of nouns, it is time to put on your architect's hat. Analyze, filter, and expand the list to address technical, structural, and behavioral needs.
Filter Redundancies and Attributes: Remove duplicate nouns. Determine if a noun is actually just an attribute of another class (e.g., "Title" is likely an attribute of Book, not a class itself).
Resolve Relationships: Look for many-to-many relationships. If an Author has many Books, and a Book has many Authors, you need an association class like BookAuthorLink or Authorship to hold relationship-specific data (like the author's specific role, e.g., "Co-author").
Identify Infrastructure Needs: Consider external entities and system boundaries. You might need a Shipper class to handle third-party delivery integrations, or a PaymentGateway class.
Identify Operations (Verbs): Now, look at the verbs you ignored in Step 2. Verbs represent the operations or services the objects perform.
Requirement: "The system validates the password."
Analysis: Account is the class (noun), and verifyPassword() becomes the operation (verb).
Below are PlantUML examples demonstrating how the noun/verb analysis translates into a concrete UML Domain Model based on our Bookstore scenario.
This diagram represents the raw extraction of nouns from the prototype and initial process envisioning, before deep refinement.
@startuml Initial Noun Extraction
skinparam classAttributeIconSize 0
title Initial Domain Model: Noun Extraction
class Book
class Author
class Publisher
class Review
class Reviewer
class Customer
class Order
class BillingInformation
class ShippingInformation
' Basic initial relationships
Customer --> Order
Order --> Book
Book --> Author
Book --> Publisher
Review --> Reviewer
Review --> Book
@enduml
This diagram shows the final refined model. Notice how verbs have been translated into methods (e.g., verifyPassword), many-to-many relationships have been resolved using an association class (BookAuthorLink), and infrastructure needs (Shipper) have been added.
@startuml Refined Domain Model
skinparam classAttributeIconSize 0
title Refined Domain Model: Operations & Associations
class Customer {
+name: String
+email: String
+verifyPassword(pwd: String): Boolean
}
class Order {
+orderDate: Date
+calculateTotal(): Double
+processPayment(): Boolean
}
class Book {
+isbn: String
+title: String
+price: Double
}
class Author {
+name: String
+biography: String
}
class BillingInformation {
+cardNumber: String
+expiryDate: Date
}
class ShippingInformation {
+address: String
+trackingNumber: String
}
' Association class resolving many-to-many
class BookAuthorLink {
+role: String ' e.g., "Lead Author", "Contributor"
}
class Shipper {
+calculateRates(): Double
+generateLabel(): String
}
' Relationships
Customer "1" --> "0..*" Order : places >
Order "1" --> "1" BillingInformation : has >
Order "1" --> "1" ShippingInformation : requires >
ShippingInformation --> Shipper : fulfilled by >
' Resolving Many-to-Many
Book "1" --> "0..*" BookAuthorLink
Author "1" --> "0..*" BookAuthorLink
Order "0..*" --> "1..*" Book : contains >
@enduml
Delay Filtering: The biggest mistake beginners make is filtering out nouns too early. Extract everything first; refine later. You might discard a noun later, but you can't easily add a missed class once you've started coding.
Beware of Implementation Leakage: Keep your domain model focused on the business problem. Avoid adding technical nouns like Database, XMLParser, or MySQLTable unless they are explicitly part of the business domain.
Use a Glossary: As you extract nouns, maintain a "Domain Glossary." This ensures that all stakeholders and developers are using the exact same terminology for the same classes (e.g., ensuring everyone uses Client instead of mixing Client, Customer, and User).
Noun/verb analysis, or grammatical inspection, is much more than a simple highlighting exercise; it is a systematic bridge between human requirements and object-oriented design. By starting with a broad extraction of nouns to form your classes, envisioning the dynamic processes to uncover hidden entities, and refining the list by mapping verbs to operations, you ensure that your system's architecture is deeply rooted in the actual problem domain.
While it requires practice to distinguish between a true class and a mere attribute, mastering this technique will drastically improve the accuracy, clarity, and maintainability of your software designs. Remember: gather broadly, envision dynamically, and refine meticulously.
