5.3 Understanding Conceptual Modeling in Object-Oriented Analysis

From Functional Decomposition to Conceptual Decomposition

One of the major shifts from traditional structured analysis to object-oriented analysis (OOA) lies in how we decompose systems. While structured analysis breaks systems down by functions, OOA decomposes systems based on concepts—essentially objects. The goal is to identify what entities can behave, and only later define how they behave through design and implementation.

In other words, OOA focuses on identifying the things in the system first—whether they are tangible like a "Car" or abstract like "Hunger"—and then builds a model of the problem domain around these things. This model is called the conceptual model or domain model.

What Is Conceptual Modeling?

Conceptual modeling is the process of discovering and organizing the important concepts of a system. It helps both software developers and stakeholders understand the system's problem space more clearly. A concept in this context refers to an idea, object, or thing relevant to the system.

Each concept has:

A symbol – the word or image that represents it.
An intention – its definition or meaning.
An extension – the set of instances it applies to.

For instance, consider the concept "Module" in a university:

Symbol: "Module"
Intention: A course offered in the degree program
Extension: All courses/modules like CS101, MA202, etc.

In UML (Unified Modeling Language), concepts are often referred to as classes. The terms class and concept are used interchangeably during the requirements phase. Each class represents a group of similar objects.

Class vs. Object

An object is a concrete entity—it exists in time and space.
A class is an abstraction of a group of such objects.

For example:

"Student" is a class.
"John Smith" and "Jane Brown" are objects (instances) of the class "Student".

According to UML, a class is defined as a “description of a set of objects that share the same attributes, operations, methods, relationships, and semantics.”

Identifying Concepts from Requirements

The requirements document—which includes goals, use cases, diagrams, and descriptions—is a great source for identifying candidate concepts. There are two main tasks in object-oriented analysis:

Identify as many candidate objects as possible.
Select the most significant ones to form a meaningful object model.

Example Concept Categories

Category	Examples
Physical Objects	House, Car, Airplane
People Roles	Doctor, Pilot, Student
Places	Store, Airport
Documents	Module Description, Product Spec
Transactions	Sale, Reservation
Organizations	Club, Department
Events	Crash, Meeting
Abstract Concepts	Hunger, Fear
Services	Line of Credit, Stock
Manuals	Repair Manual, Employee Handbook

Another simple way to find concepts is by scanning for nouns and noun phrases in use cases and functional requirements. However, not every noun is a concept—some may be attributes or operations.

Example: POS System Concepts

From a use case like "Buy Items with Cash" in a POS (Point of Sale) system, we can extract noun phrases such as:

Customer
Item
Receipt
Sale
Cash
Payment
Cashier
POST (POS terminal)

Some of these become classes (concepts), while others may be attributes of those classes.

Associations in Conceptual Modeling

A useful conceptual model doesn't just contain isolated concepts. The objects in these classes must interact. UML models these relationships using associations.

Multiplicity

Multiplicity defines how many instances of one class can be associated with another at a given time. For example:

One Cashier operates exactly one POST terminal
One Sale includes multiple Items

Associations can also represent:

Aggregation (a part-whole relationship)
Composition (stronger form of aggregation)
Inheritance (one class is a specialized type of another)

Below is a simplified UML diagram illustrating such associations in a POS system:

lua

Sale -------- includes --------> Item
Cashier ----- operates -------> POST
Sale -------- handled by -----> Cashier

Adding Attributes to Classes

Attributes describe properties of concepts. For example:

A Sale has a date and time
A Payment has an amount
A Module has a code, title, and credit value

Each object of a class has exactly one value per attribute at any given time, although the value can change.

Example:

Sale.time = "13:30"
Module.code = "CS206"
Student.name = "John Smith"

Important Tip:

Do not use attributes as foreign keys to relate concepts. For example, don’t use currentPOSTNumber in Cashier to link it to a POST. Instead, model this using an association.

Steps to Build a Conceptual Model

Identify Concepts
- Use noun extraction and the concept category table.
Draw Classes
- Represent each concept with a class box.
Add Associations
- Draw links between related classes.
Add Attributes
- Inside each class, list its relevant attributes.

Conceptual Model of a POS System (Illustration)

Imagine a class diagram with the following elements:

Class: Sale
- Attributes: date, time
Class: Payment
- Attributes: amount
Class: Cashier
- Attributes: name
Class: Item
- Attributes: price, description
Class: POST
- Attributes: id

Associations:

A Sale includes multiple Items
A Sale is handled by one Cashier
A Cashier operates one POST
A Sale results in one Payment

This forms a static view of the domain that supports future system functionality.

Conclusion

Object-oriented analysis and conceptual modeling allow us to describe systems in terms of the real-world concepts that make them up. By identifying classes, defining their attributes, and showing their relationships, we gain a clearer understanding of the domain and a stronger foundation for software design.

Avoid premature decisions about implementation. Don’t use foreign keys like in relational databases—rely on associations. Focus on the real-world objects involved in the use cases, and model how they are connected. The result will be a powerful conceptual model that serves as a bridge between stakeholders, designers, and developers.

Let the concepts guide the functionality—not the other way around.

Overview

This topic addresses the analysis of software requirements, aiming to:

Detect and resolve conflicts
Define system boundaries and environmental interactions
Refine high-level system requirements into precise software requirements

Requirements Analysis

Goes beyond conceptual modeling (e.g., SADT) to include:
- Requirements classification: Helps inform trade-offs.
- Requirements negotiation: Resolves conflicts among stakeholders or constraints.
Emphasizes precise requirement descriptions to support validation, verification, and cost estimation.

Requirements Classification

Requirements can be classified by various dimensions (e.g., functional vs. non-functional). These classifications help:

Understand priorities and constraints
Support requirement trade-offs and negotiation
Often overlap with requirement attributes (like priority, risk, etc.)

Conceptual Modeling

Models are created to understand the problem domain, not to begin solution design. Models may include:

Data/control flows
State models
Event traces
User interactions
Object/data models

Factors influencing model choice:

Problem nature (e.g., real-time systems need control flow models)
Engineer's expertise
Customer-imposed methods
Tool/method availability

UML is a widely accepted standard. Formal modeling may be used in critical domains. Standards like IEEE 1320.1 (IDEF0) and IEEE 1320.2 (IDEF1X97) offer structured modeling support.

Architectural Design & Requirements Allocation

Begins blending with design: defines software structure while refining requirements.
Requirements Allocation: Assigns responsibilities to components, enabling deeper subsystem analysis.
Architecture must reflect real-world domain entities and their software representations.

Requirements Negotiation

Involves resolving:
- Conflicts between stakeholders
- Resource vs. requirement conflicts
- Functional vs. non-functional requirement clashes
Requires consensus, traceability, and stakeholder involvement.

Requirements Specification

Focuses on documenting and formalizing requirements for review and agreement. Types of documents include:

System Definition Document: High-level system view for stakeholders (IEEE 1362).
System Requirements Specification: Covers software and non-software components (IEEE 1233).
Software Requirements Specification (SRS): Defines software behavior, limitations, and scope.

Specification Methods:

Natural language
Structured language
Design/requirement specification languages
Graphical/formal notations

Quality indicators for specs include:

Statement-level: Imperatives, options, weak phrases
Document-level: Readability, structure, depth, size

Purpose and Value of SRS

Sets mutual understanding for customers and developers
Enables rigorous requirement assessment
Supports estimation, planning, testing, and maintenance
Facilitates software reuse, enhancement, and transfer

Software Engineering

Search This Blog