Modeling Solutions with Object-Oriented Thinking

Modeling is not a bureaucratic chore. It is the foundation for effective communication between you, your stakeholders, and your developers. The mismatch between what users want and what developers deliver often traces back to poor modeling and unclear requirements. Right modeling provides a step-by-step procedure that ensures your requirements are complete, correct, and unambiguous.

Many IT projects experience time and cost overruns because a single change in the business cascades into numerous changes in deliverables — the “ripple effect.” Object-oriented modeling helps minimize this by enforcing the principle of “one fact in one place,” making requirements easier to revise and maintain.

Why modeling is your most critical communication tool

You will hear many PMs say, “I just write user stories or talk to engineers.” That is not enough. Your actual job is to communicate effectively and unambiguously — across teams, time zones, and organizational layers.

A business model is an abstract representation of a clearly delimited area of business. It can take many forms: plain text, wireframes, diagrams, or pictures. The goal is to create a shared mental model that everyone agrees on, especially the developers who will build the system.

When you model well, you reduce miscommunication and the risk of costly rework. You also make it easier to respond to changes in the business environment without triggering chaos in your project plan.

Two fundamental types of models: Behavior and Structure

Modeling comes in two flavors — each answering a different question about the system you are building:

• Behavioral (Dynamic) models answer: What does the system do?
  They focus on actions, workflows, and processes. Examples include use case diagrams, activity diagrams, and decision trees.

• Structural (Static) models answer: What is the system?
  They focus on the nouns — the objects, entities, and their relationships. Examples include class diagrams and package diagrams.

Both are essential. Behavioral models capture user interactions and system responses; structural models capture the data and business objects involved.

Object orientation: the bridge from business to software

As a PM, your task is to get inside the heads of your stakeholders — to extract their knowledge of the business system — and pass it on to your developers in a way they can translate into software.

Object orientation (OO) is a conceptual framework that matches how people naturally think about the world. It starts with the idea that the basic unit of knowledge is an object — a distinct thing with attributes and behaviors.

This approach covers the entire software lifecycle — from requirements gathering through design and coding — using consistent concepts and terminology. OO reduces the risk of miscommunication by using diagrams and language familiar to both business and IT.

Objects: the building blocks of your model

Objects represent business entities that your system must track or act upon. For example, in an e-commerce system, objects might include:

• Invoice
• Customer
• Order
• Product

When you perceive the world, you naturally distinguish individual objects. In modeling, you ask stakeholders to identify these objects because they form the vocabulary of your system.

Attributes and operations: what objects know and what they do

Objects have two essential parts:

• Attributes: Properties or data values that describe the object. For example, a Customer object might have attributes like name, address, and phone number.

• Operations: Actions or functions the object can perform or that can be performed on it. For example, an Account object might support operations like deposit and withdraw.

Your job is to discover which attributes and operations apply to each object. This ensures your model captures both the state and behavior of the system components.

Methods: how operations are carried out

Operations describe what can be done with an object. Methods describe how those operations are performed.

For example, placing a call on a mobile phone is an operation. The procedure — entering the number and pressing send — is the method.

When gathering requirements, ask stakeholders not only what operations exist but also how they are executed. Document these procedures clearly, as developers will use them to build the system logic.

Encapsulation: hiding complexity behind clear interfaces

You use objects every day without knowing their internal workings. This is the principle of encapsulation — only an object’s operations are visible to others, while its internal attributes and methods remain hidden.

Encapsulation helps manage complexity by allowing you to change an object’s internals without affecting other parts of the system, as long as the external interface remains consistent.

When modeling, do not expose or rely on the internal details of other objects. This reduces dependencies and keeps your model adaptable.

Classes: categories of objects with shared properties

A class is a category of objects that share the same attributes and operations but may have different values.

For example, all iPhone X phones belong to the class iPhone X. They share attributes like serial number and camera settings, and operations like placing a call. Each phone object has its own specific values for these attributes.

You will spend most of your modeling time defining classes, especially entity classes that represent business objects such as Account, Customer, or Invoice.

Relationships between classes: organizing your model

Objects and classes rarely exist in isolation. They relate to each other in several ways:

• Generalization (Inheritance): A specialized class inherits attributes and operations from a generalized class. For example, Savings Account and Checking Account inherit from Account.

• Association: A general relationship where objects of one class link to objects of another. For example, a Customer places an Order.

• Aggregation: A whole-part relationship where the parts can exist independently. For example, a Car has Passengers who may come and go.

• Composition (Composite Aggregation): A strong whole-part relationship where parts belong to only one whole and are destroyed with it. For example, a House has Rooms; when the house is demolished, so are the rooms.

• Polymorphism: One interface with many implementations. For example, the operation accept deposit behaves differently for Savings Account and Checking Account.

Generalization: simplifying rules with inheritance

Generalization lets you define common attributes and operations once on a superclass and specialize them in subclasses.

For example, all Accounts have a balance and can accept deposits. Savings Accounts might add interest calculations, while Checking Accounts might add overdraft protection.

This reduces duplication and makes your requirements easier to maintain.

Association: linking objects with meaningful names

Associations express how objects relate. For example, a Personal Computer may have a Monitor, Keyboard, and Mouse.

You must name associations clearly to reflect the nature of the relationship. For example, “contains” vs. “has a.”

Missing or incorrect associations cause software to fail business rules, so this is a critical part of modeling.

Aggregation and composition: modeling whole-part relationships

Use aggregation when parts can exist independently of the whole. Use composition when parts depend on the whole.

For example:

• Car aggregates Passengers — passengers come and go.

• Car composes Engine — every car has an engine, and the engine does not exist separately.

When unsure, default to aggregation. It is better to be less specific than wrong.

Polymorphism: one interface, many implementations

Polymorphism means that operations can behave differently depending on the object subtype.

For instance, the operation investCapital() applies to all Funds but the method varies by subtype — Asia Fund vs. Domestic Fund.

This lets you write flexible and maintainable requirements without enumerating every variation explicitly.

Use cases and scenarios: capturing user requirements behaviorally

A use case describes a meaningful interaction with the system that produces an observable result.

A scenario is one path through a use case — one way it might play out.

For example, in a banking system:

• Use case: Make bill payment

• Scenario 1: Payment succeeds.

• Scenario 2: Payment fails due to insufficient funds.

Use cases and scenarios are your behavioral requirements. They should be documented clearly to guide development and testing.

Business use cases vs. system use cases

• Business use case: Interaction with the business process (e.g., Process Claim in insurance).

• System use case: Interaction with the IT system supporting the business use case (e.g., Record Claim, Validate Coverage).

System use cases are often just called use cases and describe user-computer interactions in a single session.

How to apply use cases and scenarios in your work

• Identify business use cases by focusing on the business impact of proposed changes.

• Analyze these into system use cases — group activities that deliver real user benefits.

• Use system use cases to drive development: design, coding, and implementation.

This approach ensures each release delivers features that improve users’ jobs.

Where to go next

• If you want to master user requirements and discovery: User Research Methods
• If you want to write clear product requirements: Product Requirements Documents (PRD)
• If you want to learn UML diagramming basics: UML for PMs
• If you want to understand product strategy fundamentals: Product Vision and Strategy