Software Engineering basics - Proposals for Identifying Object Classes

Identifying object classes is a fundamental step in object-oriented analysis and design (OOAD). The goal is to determine the key entities (objects) that represent real-world concepts within the system being modeled. Over time, several proposals and techniques have been developed to help systematically identify these classes.

1. Using Tangible Things (Objects in the Real World)

This approach identifies classes based on real, physical entities in the problem domain.

Idea: Each tangible item or concept that can be distinctly identified in the system is considered a potential object.
Example: In a Library Management System, tangible object classes might be:
Book, Member, Librarian, LibraryCard, Shelf.

Advantage: Easy to visualize and relate to the real world.
Limitation: May miss abstract or control-related classes that don’t have physical existence.

2. Using Grammatical (Noun–Verb) Analysis

This is a linguistic approach proposed by Abbott, Booch, and others.

Idea: Analyze the problem statement or requirements description.
- Nouns → Potential classes or attributes.
- Verbs → Potential methods or operations.
Example:
Sentence: “A member borrows a book using a library card.”
- Nouns → Member, Book, LibraryCard (candidate classes)
- Verb → borrows (method or interaction)

Advantage: Simple and systematic for textual requirements.
Limitation: Can lead to too many classes; requires human judgment to filter relevant ones.

3. Using Scenarios or Use Cases

Idea: Study use cases or system scenarios to identify objects that participate in various system interactions.
Example:
In the use case “Issue Book”, the objects involved are: Member, Book, Librarian, and Transaction.
These become candidate classes.

Advantage: Ensures all classes are functionally relevant.
Limitation: Might miss passive or background classes not directly mentioned in use cases.

4. Using the Responsibility-Driven Approach

Proposed by Wirfs-Brock, this approach identifies classes based on responsibilities and collaborations.

Idea:
- Identify what responsibilities exist in the system.
- Assign these responsibilities to classes that can logically perform them.
Example:
Responsibility: “Keep track of book due dates” → BookLoan or Transaction class.

Advantage: Focuses on behavior and role distribution.
Limitation: May overlook structural or data-based classes.

5. Using Domain Knowledge and Expert Consultation

Idea: Use knowledge of the problem domain (and experts’ input) to identify key entities.
Example: In a banking system, experts can help identify classes like Account, Customer, Transaction, Loan, etc.

Advantage: Produces accurate and domain-relevant classes.
Limitation: Depends heavily on expert availability and understanding.

6. Using Data-Driven Analysis

Idea: Identify data elements that the system must store and manage; each major data entity can be modeled as an object class.
Example: Database entities such as Customer, Order, Product, and Invoice become classes.

Advantage: Suitable for data-intensive systems.
Limitation: Focuses more on structure than on behavior.

Summary Table

Approach	Basis of Identification	Example Classes	Main Advantage
Tangible Things	Physical entities	Book, Member	Intuitive and concrete
Grammatical Analysis	Nouns/verbs in requirements	Book, Librarian	Simple and systematic
Scenario-Based	Use cases or interactions	Transaction, Member	Ensures functional relevance
Responsibility-Driven	System responsibilities	BookLoan, Account	Focuses on behavior
Domain Knowledge	Expert understanding	Account, Loan	Domain accuracy
Data-Driven	Data entities	Product, Customer	Suitable for data-heavy systems

In summary:
Identifying object classes is a creative yet systematic process. A combination of these approaches—particularly grammatical analysis, use-case review, and domain knowledge—often yields the most complete and effective set of object classes for a system.