Project Modeling

Concept Definition

Project modeling is the process of turning requirements into classes, methods, and relationships. You start with problem language, identify candidate nouns and verbs, then decide which objects own data and which objects perform behavior. The result is a design that can guide implementation.

Think of it as translating a story into a cast list and responsibility chart.

Why It Matters

Students often jump from requirements directly into main(). That leads to long procedural code, duplicated logic, and weak class boundaries. Modeling helps you see the system before writing too much code.

Good modeling also supports testing. When responsibilities are separated, you can test Book, Member, Loan, and Library behavior without running a giant menu program.

Syntax Block

class Entity {};      // noun from requirement
class Service {};     // coordinator behavior
class Interface {};   // variation point

Explained Code

Example: Library Requirement to Classes

#include <string> // std::string
#include <vector> // std::vector

class Book {
private:
    int id;                    // book identity
    std::string title;         // book information
};

class Member {
public:
    virtual ~Member() = default;       // polymorphic base
    virtual int borrowLimit() const = 0; // variation point
};

class Loan {
private:
    int bookId;                // connects book
    int memberId;              // connects member
};

class Library {
private:
    std::vector<Book> books;   // library owns book collection
    std::vector<Loan> loans;   // library tracks loans
};

The requirement says a library can add books, register members, checkout books, return books, and apply different borrowing limits. That suggests Library, Book, Member, and Loan.

Key Points / Rules

• Nouns often suggest classes, but not every noun deserves a class.
• Verbs often suggest methods or services.
• Variation in behavior may suggest inheritance, Strategy, or an interface.
• Ownership should be explicit before implementation.
• Testing needs should influence class boundaries.

Common Mistakes

1. Turning every noun into a class. Some nouns are only fields or values.
2. Putting every verb in one manager class. That creates a God Class.
3. Ignoring ownership. If you do not know who owns data, cleanup and updates become messy.
4. Designing only for the current sample input. Requirements usually grow.

Quick Check

1. Why does Member have a virtual borrowLimit() method?
2. Which class should own the collection of books?

Viva Answer

Project modeling converts requirements into candidate classes, methods, relationships, and tests. It helps keep responsibilities clear before code grows large.