In Object-Oriented Analysis and Design (OOAD), the most challenging leap is often translating ambiguous, natural-language business requirements into a rigorous, structured software architecture. Noun/verb analysis, also known as grammatical inspection, is the foundational bridge for this translation.
By systematically dissecting the grammar of problem domain descriptions, software architects and business analysts can discover the core classes, attributes, and relationships that form the backbone of a Unified Modeling Language (UML) Class Diagram. This guide provides a comprehensive, step-by-step methodology for applying noun/verb analysis, complete with key concepts, advanced filtering techniques, and practical UML diagram examples.
To master noun/verb analysis, one must first understand the linguistic mapping between natural language and object-oriented paradigms.
Nouns and Noun Phrases represent the Classes and Objects (the "things" in the system). Example: "Customer", "Order", "Shipping Address".
Verbs and Verb Phrases represent the Operations/Methods (the "behaviors") or Relationships/Associations (the "connections"). Example: "calculates total", "ships to", "writes review".
Adjectives often represent the Attributes (the "properties" or data values) of a class. Example: "premium customer", "digital book".
The primary goal of this technique is not just to find classes, but to establish a shared vocabulary. The resulting nouns define the basic terms of the system, facilitating agreement among project stakeholders, developers, and domain experts regarding their exact meanings and boundaries.
Grammatical inspection is not a one-pass compiler; it is an iterative process. The initial extraction of nouns is a brainstorming exercise. The true engineering happens in the refinement phase, where you filter out noise, resolve ambiguities, and elevate raw nouns into formal UML constructs.
Begin by poring through materials that provide insight into the arena the new system is intended to solve. Do not rely on a single document. Relevant materials include:
High-level requirements documents and user stories.
Marketing materials and business pitches.
Rapid prototypes, such as wireframes or prototype HTML pages.
Transcripts of interviews with domain experts.
A fundamentally sound approach is to find as many nouns and noun phrases as possible at the start. Treat these as obvious candidates for your system's classes.
Rule of Thumb: In the early stages, focus on accumulation rather than perfection. Highlight every noun. You will analyze, refine, and expand this list in later steps.
Using an Internet Bookstore as an example, a mental review of a prototype book details page and checkout process reveals several candidate classes:
Initial Obvious Nouns: From looking at a product page, you might identify Book, Author, Publisher, Review, and Reviewer.
Envisioning Interactions (Verbs in Action): By envisioning a user purchasing a book (the verb "purchases"), additional nouns come into view: Customer, Account, Order, BillingInformation, and ShippingInformation.
Deepening the Analysis: Thinking about complex relationships might reveal more nuanced needs. For instance, a book can have multiple authors, and an author can write multiple books. This might reveal a BookAndAuthor class (an association class to manage the many-to-many relationship and store metadata like "author role"). Furthermore, fulfilling the "ships" verb might reveal a Shipper class for handling various delivery companies (FedEx, UPS, etc.).
The result of this analysis is a raw set of nouns. You must now apply filtering rules to refine them into a formal UML model. (See Advanced Filtering Techniques below). Once refined, these nouns become formal UML class boxes, to which you will add attributes (data values) and operations (services requested of an object).
Not every noun should become a class. Applying the following filters will save your architecture from becoming bloated and illogical:
Redundant Nouns: Synonyms should be merged. If the text mentions both "Customer" and "Client", pick one and stick to it to maintain the ubiquitous language.
Irrelevant or Vague Nouns: Words like "System", "Information", "Data", or "Screen" are usually implementation details or too vague to be domain classes. Discard them.
Out-of-Scope Nouns: If the system is only handling online sales, a noun like "Warehouse Forklift" might be out of scope and should be excluded.
Attributes Disguised as Nouns: If a noun merely describes a property of another noun, make it an attribute. Example: "Customer Name" or "Book Price" should be attributes of Customer and Book, not separate classes.
Operations Disguised as Nouns: Nouns that imply an action should be converted into methods. Example: "Payment Calculation" should not be a class; "calculatePayment()" should be an operation within the Order class.
Below is the evolution of the Internet Bookstore model, transitioning from raw concepts to a refined UML Class Diagram.
This diagram demonstrates the refined nouns from our analysis, complete with attributes, operations, and the resolution of complex relationships (like the many-to-many relationship between Books and Authors).
@startuml
skinparam classAttributeIconSize 0
skinparam shadowing false
skinparam roundcorner 10
title Refined Internet Bookstore Domain Model
class Customer {
- customerId: String
- name: String
- email: String
+ register(): void
+ placeOrder(cart: Cart): Order
}
class Account {
- accountId: String
- balance: Decimal
- status: String
+ updateBalance(amount: Decimal): void
}
class Order {
- orderId: String
- orderDate: Date
- totalAmount: Decimal
+ calculateTotal(): Decimal
+ processPayment(): boolean
}
class Book {
- isbn: String
- title: String
- price: Decimal
- publishDate: Date
+ getDetails(): String
}
class Author {
- authorId: String
- name: String
- biography: String
}
class Authorship {
- role: String 'e.g., "Co-Author", "Editor"
- contributionPercentage: int
}
class Shipper {
- shipperId: String
- companyName: String
- trackingUrlBase: String
+ calculateShippingCost(weight: Decimal): Decimal
}
class Review {
- reviewId: String
- rating: int
- comment: String
- reviewDate: Date
}
' Relationships
Customer "1" -- "1" Account : has >
Customer "1" -- "0..*" Order : places >
Order "1" -- "1..*" Book : contains >
Book "1" -- "0..*" Authorship : written via >
Author "1" -- "0..*" Authorship : participates in >
Order "1" -- "1" Shipper : shipped by >
Book "1" -- "0..*" Review : has >
Customer "1" -- "0..*" Review : writes >
@enduml
Classes: Customer, Account, Order, Book, Author, Shipper, Review.
Association Class: Authorship is used to resolve the many-to-many relationship between Book and Author, holding specific data about their collaboration (like their specific "role").
Attributes & Operations: Notice how nouns that were originally adjectives or verbs in the text (e.g., "calculates total", "shipping cost") have been transformed into operations (calculateTotal(), calculateShippingCost()).
Noun/verb analysis remains one of the most effective, accessible, and powerful techniques for discovering classes and defining the architecture of a software system. By systematically extracting nouns from requirements and rigorously filtering them through the lens of object-oriented principles, teams can build a robust, shared domain model. This grammatical inspection ensures that the final UML diagrams are not just technically sound, but deeply aligned with the actual business problem being solved.
However, a methodology is only as good as the tools used to execute it. Once your noun/verb analysis is complete and your classes are refined, you need a robust environment to visualize, document, and share your UML models. Visual Paradigm is highly recommended for this phase. As an industry-leading UML tool, Visual Paradigm provides an intuitive, drag-and-drop interface for creating complex Class Diagrams, seamlessly integrating your refined domain vocabulary into professional, standardized architectural blueprints that can be easily shared with stakeholders and development teams.
