Object-Oriented Analysis, Domain Modeling, and UML

Introduction

Object-oriented programming is not limited to writing classes and methods. Before implementation begins, developers must understand the problem domain, identify the concepts that matter, determine how those concepts collaborate, and communicate design decisions precisely. Object-oriented analysis (OOA) provides this bridge between requirements and software design. Unified Modeling Language (UML) supplies a standardized visual language for representing the resulting models.

A well-constructed model helps a development team answer questions such as: What objects exist? What responsibilities do they have? How are they related? What happens when a user performs an action? How does an object change over time? Which parts of the design are stable, and which are likely to change?

This chapter presents a practical and analytical approach to translating requirements and use cases into domain models and UML diagrams. It focuses on class, object, sequence, state, and package diagrams, as well as responsibility assignment and the distinctions among association, aggregation, composition, and dependency.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish requirements analysis, domain modeling, and software design;
• extract candidate concepts, attributes, operations, and relationships from requirements;
• construct and interpret UML class and object diagrams;
• model interactions with sequence diagrams;
• model object lifecycles with state-machine diagrams;
• organize model elements using package diagrams;
• assign responsibilities using cohesion, coupling, and GRASP-informed reasoning;
• distinguish association, aggregation, composition, generalization, and dependency;
• evaluate the strengths and limitations of UML models in professional development.

1. From Requirements to Object Models

1.1 Requirements as the source of the model

A requirement describes a capability, constraint, quality attribute, or business rule. A use case describes a goal-oriented interaction between an actor and a system. For example:

> A library member searches for a book, reserves an available copy, and receives a confirmation.

This statement contains possible actors, concepts, actions, and constraints. A model should not simply convert every noun into a class and every verb into a method. Natural language is ambiguous, and many words are incidental rather than domain concepts. Analysis requires interpretation.

A useful progression is:

1. Identify system scope and actors.

2. Read use cases and extract candidate concepts.

3. Classify concepts as entities, value objects, roles, events, or external systems.

4. Identify relationships and business rules.

5. Assign responsibilities.

6. Validate the model with scenarios.

7. Refine the model into an implementable design.

1.2 Analysis versus design

Object-oriented analysis concentrates on what exists in the problem domain and what the system must accomplish. Object-oriented design concentrates on how software components will realize those capabilities. A domain class such as `Book` may be meaningful during analysis, while design may later divide the implementation into `Book`, `BookRepository`, `SearchService`, and database-mapping components.

Analysis models should avoid premature commitment to programming-language details. Design models may include visibility, interfaces, persistence mechanisms, frameworks, and algorithms. Confusing these levels often produces models that reflect a particular database or user interface rather than the underlying business domain.

2. Domain Modeling

A domain model is a conceptual representation of important domain concepts, their properties, and their relationships. It is not necessarily a database schema, a complete class design, or executable code. Its principal purpose is shared understanding.

2.1 Candidate concepts

Candidate concepts commonly arise from:

• business nouns: `Member`, `Reservation`, `Invoice`;
• roles: `Customer`, `Librarian`, `Administrator`;
• tangible things: `BookCopy`, `Vehicle`, `Device`;
• places or organizational units: `Branch`, `Warehouse`;
• events or transactions: `Payment`, `Shipment`, `Booking`;
• descriptions and measurements: `Address`, `Money`, `DateRange`;
• external systems: `PaymentGateway`, `EmailService`.

The analyst then asks whether each candidate has a distinct identity, behavior, lifecycle, and business meaning. A word may be modeled as an attribute rather than a class if it has no independent behavior or identity. For example, a person's telephone number might initially be a string attribute; an address may deserve a value-object class when it has validation rules and is reused in several contexts.

2.2 Entity, value object, and service

An entity has continuity and identity over time. Two `Member` objects may have identical names but represent different members because their identifiers differ. An entity's identity remains significant even when its attributes change.

A value object is defined by its value rather than by an independent identity. Examples include `Money`, `EmailAddress`, and `DateRange`. Value objects are often immutable, which reduces accidental side effects and simplifies reasoning.

A service represents an operation or capability that does not naturally belong to one domain entity. For example, calculating a route between two locations may be represented by a `RoutePlanner` service. Services should not become a dumping ground for behavior that properly belongs to domain objects.

2.3 Attributes, operations, and constraints

An attribute describes a property, such as `memberId`, `title`, or `status`. An operation represents behavior, such as `reserve()` or `cancel()`. During early analysis, operations may be described informally; during design, their parameters, return types, visibility, and exceptions can be specified.

Constraints express rules that must remain true. Examples include:

• a reservation must refer to exactly one member;
• a loan must have one checkout date;
• a member may not exceed the permitted number of active loans;
• a payment amount must be positive.

UML constraints are often written in braces, such as `{activeLoans <= loanLimit}`. The notation communicates a rule, but the implementation must enforce it through validation, transactions, or domain logic.

3. UML Class and Object Diagrams

3.1 Class diagrams

A UML class is commonly drawn as a rectangle with compartments for the class name, attributes, and operations. A simplified textual representation is:

```

Member

-------------------------

• memberId: MemberId
• name: String
• status: MemberStatus

-------------------------

+ placeReservation(copy: BookCopy): Reservation

+ cancel(reservationId: ReservationId): void

```

The symbols `+` and `-` conventionally indicate public and private visibility. UML also supports protected (`#`) and package (`~`) visibility, although precise visibility is often deferred until design.

A class diagram can show:

• classifiers and interfaces;
• attributes and operations;
• multiplicity;
• navigability;
• generalization;
• associations and association classes;
• dependencies and package structure;
• constraints and notes.

3.2 Multiplicity

Multiplicity states how many instances may participate in a relationship. Common forms are:

• `1`: exactly one;
• `0..1`: zero or one;
• `` or `0..`: any number, including zero;
• `1..*`: one or more;
• `m..n`: between specified bounds.

For example, if a `Member` may have zero or more `Reservation` objects, the association end near `Reservation` has multiplicity `0..*`. If each reservation belongs to exactly one member, the end near `Member` has multiplicity `1`.

Multiplicity is a business statement, not merely a programming detail. It should be justified by requirements and validated against exceptional cases such as deletion, cancellation, or archival.

3.3 Association

An association represents a meaningful structural relationship between classifiers. `Member reserves BookCopy` is an association. It may be named, directed, qualified, or annotated with roles. A relationship can also have attributes of its own. If a member reserves a copy at a particular time and receives a queue position, the relationship may be modeled as a `Reservation` class rather than as a simple line.

Association does not automatically imply ownership. A `Doctor` may be associated with many `Patient` objects, but neither necessarily controls the lifecycle of the other.

3.4 Aggregation and composition

UML aggregation is a whole-part relationship. Shared aggregation, shown with a hollow diamond, indicates that parts participate in a whole but may exist independently. However, shared aggregation has weak and inconsistently interpreted semantics in practice. Many teams avoid it and use an ordinary association unless the distinction is useful.

Composition, shown with a filled diamond, is a stronger whole-part relationship. The composite controls the membership and typically the lifecycle of its parts. A `PurchaseOrder` may be composed of `OrderLine` objects: an order line has little meaning outside its order, and deleting the order normally removes its lines. Composition implies exclusive ownership of a part within the relevant model and should not be used merely because one class contains a collection of another.

The lifecycle implication is important but not absolute in every implementation. Persistence, archival, and audit requirements may preserve records after a business object is closed. Therefore, composition should reflect domain meaning, not assumptions about memory management.

3.5 Generalization and dependency

Generalization represents an “is-a” relationship. `PremiumMember` may specialize `Member` if it satisfies the substitutability expected of a member and adds or refines behavior consistently. Inheritance should not be used only to reuse code; composition and delegation are often safer alternatives.

A dependency indicates that one element uses another and may be affected if the supplier changes. For example, `CheckoutController` may depend on `PaymentGateway`. A dependency is weaker and less structurally permanent than an association. A method parameter, local variable, or temporary service call may create a dependency without establishing a long-lived link between objects.

3.6 Object diagrams

An object diagram shows instances at a particular moment. It is useful for validating a class diagram with concrete examples. For instance:

```

member1:Member {memberId = M17}

copy42:BookCopy {barcode = B42, status = Available}

reservation9:Reservation {status = Active}

```

Links among these objects test whether the proposed multiplicities and relationships make sense. Object diagrams are especially useful when explaining a design to stakeholders who find abstract class diagrams difficult.

4. Responsibilities and Design Quality

A model becomes useful when it explains not only what objects are, but also what they do. Responsibility assignment asks which object should know information, make a decision, or perform an operation.

4.1 Information expert

Assign a responsibility to the class that possesses the necessary information. If a `Reservation` knows its creation date and expiry policy, it is a strong candidate for determining whether it has expired. Moving all decisions into a controller can produce an anemic domain model in which domain objects contain data but little behavior.

4.2 Creator and controller

The creator principle suggests that a class should create another object when it aggregates it, records it, closely uses it, or has the data needed to initialize it. A `PurchaseOrder` may create an `OrderLine` because it owns and manages order lines.

A controller receives a system event and coordinates a use case. It should delegate domain decisions rather than implement every business rule. For example, `CheckoutController` may receive a checkout request, locate a loan, and ask the loan or member object to perform valid transitions.

4.3 Cohesion and coupling

Cohesion concerns how closely related a class's responsibilities are. High cohesion generally improves comprehensibility and maintainability. Coupling concerns dependence among classes. Excessive coupling makes change risky. Good designs seek focused classes with necessary, stable collaborations rather than either extreme of one giant class or hundreds of trivial classes.

The GRASP principles—such as information expert, creator, controller, low coupling, high cohesion, polymorphism, and protected variations—provide heuristics rather than mechanical rules. They must be interpreted in the context of requirements, framework constraints, team expertise, and operational needs.

5. Sequence Diagrams: Modeling Collaboration

A sequence diagram represents interactions ordered in time. Participants appear as lifelines, and messages are shown from top to bottom. An activation indicates a period during which a participant is executing an operation.

Consider the use case “reserve an available book copy.” A simplified interaction is:

```

Member -> ReservationController: reserve(memberId, copyId)

ReservationController -> MemberRepository: find(memberId)

ReservationController -> CopyRepository: find(copyId)

ReservationController -> Member: requestReservation(copy)

Member -> BookCopy: reserve()

Member -> Reservation: create()

ReservationController --> Member: confirmation

```

The diagram should show meaningful responsibilities, not every getter, database call, or framework operation. A message should correspond to a real collaboration or operation. The sequence can expose missing responsibilities: if the controller must inspect and modify many unrelated objects, the design may have poor cohesion.

5.1 Combined fragments

UML sequence diagrams support fragments such as:

• `alt`: alternatives, such as available versus unavailable copy;
• `opt`: optional behavior;
• `loop`: repeated behavior;
• `par`: parallel interactions;
• `ref`: reference to another interaction.

For example, an `alt` fragment can show that an unavailable copy produces a wait-list response, while an available copy creates a reservation. Guards such as `[copy.status = Available]` document the condition.

5.2 Synchronous and asynchronous messages

A synchronous call normally means the sender waits for completion. An asynchronous message allows the sender to continue independently, which is common for notifications, queues, and event-driven systems. The distinction matters because it affects ordering, failure handling, transaction boundaries, and user expectations.

6. State-Machine Diagrams

A state-machine diagram models how an object changes state in response to events. It is appropriate when an object's behavior depends strongly on its current condition.

A `BookCopy` might have these states:

`Available -> Reserved -> OnLoan -> Available`

It may also transition to `Lost` or `Withdrawn`. A transition can be represented as:

`event [guard] / action`

For example:

`checkout [memberEligible] / recordLoan`

The event triggers the transition, the guard must be true, and the action is performed during the transition. A state may include entry, do, and exit activities, but these should be used only when they clarify behavior.

State modeling prevents invalid operations. A withdrawn copy cannot be checked out; a cancelled reservation cannot be fulfilled. The analyst should identify initial and final pseudostates, guards, exceptional transitions, and whether concurrency is possible.

State diagrams are particularly valuable for orders, payments, service tickets, authentication sessions, workflow approvals, and IoT devices. They are less useful for passive data objects with no meaningful lifecycle.

7. Package Diagrams and Architectural Organization

A package groups related model elements and controls naming and dependency organization. A package diagram can show, for example:

```

Presentation --> Application --> Domain

\--> Infrastructure

```

The arrows indicate dependencies. A common layered organization separates user-interface concerns, application orchestration, domain rules, and technical infrastructure. The exact architecture may differ, but package diagrams help identify cycles and undesirable dependencies.

A domain package should not depend directly on a particular database driver if the design intends to preserve domain independence. Dependency inversion may place an interface such as `MemberRepository` in the domain or application layer while an infrastructure package supplies the implementation.

Packages should be cohesive and loosely coupled. Excessively fine-grained packages create navigation costs, while enormous packages hide boundaries. Package boundaries should reflect ownership, change patterns, architectural responsibilities, or domain subareas—not merely the number of files.

8. Worked Analysis: Community Library Reservation System

The following is an illustrative case, not a report of an actual organization.

Background

A community library wants members to search its catalog, reserve available copies, borrow items, return them, and receive overdue notifications. Librarians manage copies and may mark damaged items as unavailable.

Problem analysis

The central use cases are Search Catalog, Reserve Copy, Check Out Copy, Return Copy, and Manage Copy Status. Actors include `Member`, `Librarian`, and an external `NotificationService`.

Candidate concepts include `Member`, `BookTitle`, `BookCopy`, `Reservation`, `Loan`, `Catalog`, and `Notification`. `BookTitle` represents the bibliographic work; `BookCopy` represents a physical item. This distinction is essential because many physical copies may correspond to one title, while a reservation may target a title and later be fulfilled by a copy depending on policy.

Domain relationships

A plausible model includes:

• one `BookTitle` associated with zero or more `BookCopy` objects;
• one `Member` associated with zero or more `Loan` objects;
• one `Member` associated with zero or more `Reservation` objects;
• each `Loan` associated with exactly one member and one copy;
• each active reservation associated with one member and a title or copy, depending on the business rule;
• a `BookCopy` with a status such as Available, Reserved, OnLoan, Damaged, or Withdrawn.

`Loan` and `Reservation` are modeled as classes rather than simple associations because they have identity, dates, status, and rules. A `Loan` records checkout and due dates; a `Reservation` records creation time, expiry, and fulfillment status.

Responsibility assignment

`BookCopy` should determine whether it is available for reservation or checkout because it owns its status. `Member` should determine whether a new loan is permitted when the rule depends on member status and active-loan count. `Loan` should determine whether it is overdue based on its due date and a supplied current date. A `LibraryController` or application service may coordinate the use case, but it should not duplicate these rules.

Sequence for checkout

A checkout interaction can proceed as follows:

1. `LibrarianUI` sends a checkout request to `CheckoutController`.

2. The controller retrieves the member and copy.

3. The controller asks the member whether checkout is permitted.

4. The controller asks the copy to check out, subject to valid state.

5. A `Loan` is created and associated with the member and copy.

6. The transaction is saved and confirmation is returned.

An alternative path handles an ineligible member or a copy that is reserved for another member. These paths should be represented in an `alt` fragment or in the use-case specification.

State model for BookCopy

Initial state: `Available`.

• `reserve` moves `Available` to `Reserved`.
• `checkout` moves `Available` or an eligible `Reserved` copy to `OnLoan`.
• `return` moves `OnLoan` to `Available`, unless inspection marks it `Damaged`.
• `withdraw` moves an appropriate state to `Withdrawn`.

The state diagram reveals that “return” alone does not determine the next state; inspection and damage policy are relevant. It also exposes the need for guards and authorized transitions.

Outcome and learning points

The model separates bibliographic identity from physical inventory, assigns rules to information experts, and uses interaction and state diagrams to test behavior. It also identifies decisions requiring stakeholder clarification: whether reservations target titles or copies, whether expired reservations are automatically removed, and how audit records are retained.

9. Modeling Practices, Tools, and Validation

UML is a communication and reasoning tool, not an end in itself. Effective practice includes:

• begin with a specific question or scenario;
• model only details that support that question;
• keep names consistent with the domain vocabulary;
• distinguish concepts that stakeholders distinguish;
• show multiplicity explicitly when it affects correctness;
• validate diagrams through concrete examples and alternative flows;
• trace important requirements to model elements;
• update models when significant design decisions change;
• use version-controlled textual or diagram sources where possible.

Tools range from general diagram editors to UML-specific and text-based tools. The tool is less important than semantic accuracy, reviewability, and integration with requirements and code. Automatic reverse engineering can generate diagrams from code, but generated diagrams may reflect implementation structure rather than domain intent.

Model-driven development can use models to generate code or tests, but generation is effective only when models are precise, consistent, and maintained. Agile teams often prefer lightweight, scenario-focused diagrams over exhaustive documentation. Both formal and lightweight approaches benefit from clear modeling standards.

10. Challenges, Limitations, and Professional Considerations

Ambiguity and changing requirements

Domain language may differ among users, analysts, and developers. A shared glossary and frequent stakeholder validation reduce semantic errors. Models should record unresolved assumptions rather than conceal them.

Overmodeling and undermodeling

Overmodeling creates diagrams no one can understand or maintain. Undermodeling hides business rules and produces accidental complexity in code. The appropriate level of detail depends on audience, risk, project phase, and regulatory needs.

Inheritance misuse

Deep inheritance hierarchies can make behavior difficult to predict. Prefer inheritance when there is a stable substitutable abstraction; prefer composition when behavior varies independently or is configured at runtime.

Persistence and integration boundaries

A domain model should not blindly mirror tables, APIs, or message formats. At the same time, persistence and integration constraints are real design forces. Explicit mapping and anti-corruption boundaries can protect domain concepts when external models differ.

Ethics, privacy, and governance

Models may represent personal data, eligibility decisions, or surveillance-related behavior. Analysts should identify data minimization, access control, retention, consent, and audit requirements. UML does not guarantee ethical behavior; it merely makes some behavior visible. In systems using AI, model diagrams should also identify data sources, model services, human review points, failure handling, and accountability boundaries. Sensitive decisions should not be hidden behind a generic `PredictionService` without documenting its inputs, outputs, limitations, and governance controls.

11. Contemporary Relevance and Employability

Modern software teams use UML selectively alongside user stories, domain-driven design, event storming, architecture decision records, API specifications, and executable tests. Domain-driven design emphasizes bounded contexts, ubiquitous language, entities, value objects, aggregates, domain services, and domain events. These ideas complement UML but are not identical to it. For example, a UML composition relationship is not automatically the same as a domain-driven-design aggregate boundary.

Employable analysts and developers must translate between stakeholder language and technical artifacts, explain trade-offs, read unfamiliar diagrams, and challenge models that encode inconsistent assumptions. Skills in sequence reasoning, lifecycle analysis, and responsibility assignment are useful in object-oriented systems, microservices, enterprise integration, and AI-enabled applications.

Best-Practice Checklist

Before accepting an object-oriented model, ask:

1. Does every important element have a clear domain meaning?

2. Are names drawn from an agreed vocabulary?

3. Are multiplicities and lifecycle rules justified?

4. Are responsibilities assigned to information experts where practical?

5. Are controllers coordinating rather than accumulating business logic?

6. Are composition and inheritance used only when their semantics fit?

7. Do sequence diagrams cover normal and exceptional flows?

8. Do state diagrams prevent invalid transitions?

9. Are package dependencies acyclic or intentionally controlled?

10. Can stakeholders validate the model through concrete scenarios?

Chapter Summary

Object-oriented analysis translates requirements and use cases into a conceptual understanding of the problem domain. Domain models identify entities, value objects, services, attributes, operations, constraints, and relationships without prematurely committing to implementation details. UML class diagrams express structure through classes, multiplicities, associations, generalization, aggregation, composition, and dependencies. Object diagrams validate that structure with concrete instances.

Sequence diagrams model time-ordered collaboration, while state-machine diagrams model lifecycle behavior and guard against invalid transitions. Package diagrams organize model elements and expose architectural dependencies. Responsibility assignment uses principles such as information expert, creator, controller, high cohesion, and low coupling to produce maintainable designs.

A strong model is selective, consistent, validated through scenarios, and connected to stakeholder language. UML is valuable because it supports communication and reasoning, but it cannot replace clarification, testing, governance, or ethical judgment. In contemporary systems, including AI-enabled applications, modeling should make data flows, service boundaries, decisions, and accountability visible.

Key Terms

Domain model: A conceptual representation of important concepts and relationships in a problem domain.

Object-oriented analysis: The study of requirements in terms of objects, responsibilities, and collaborations.

Entity: An object with a persistent identity over time.

Value object: An object defined by its value rather than independent identity.

Service: A capability or operation that does not naturally belong to one domain object.

UML: A standardized visual modeling language for software and systems.

Class diagram: A UML diagram representing classifiers, features, and structural relationships.

Object diagram: A snapshot of instances and links at a particular time.

Association: A meaningful structural relationship between classifiers.

Multiplicity: A constraint stating how many instances may participate in a relationship.

Aggregation: A weak whole-part relationship whose parts may exist independently.

Composition: A strong whole-part relationship involving exclusive ownership in the model.

Generalization: An inheritance relationship expressing an “is-a” classification.

Dependency: A relationship in which one element uses and may be affected by another.

Sequence diagram: A diagram showing time-ordered messages among participants.

State machine: A model of states, events, guards, and transitions in an object's lifecycle.

Package diagram: A diagram showing organization and dependencies among packages.

Cohesion: The degree to which responsibilities within a class or module belong together.

Coupling: The degree of dependence between classes or modules.

GRASP: A set of responsibility-assignment principles for object-oriented design.

Review Questions

Short Answer Questions

1. What is the difference between an entity and a value object?

2. What does multiplicity communicate in a UML association?

3. Why should a sequence diagram include exceptional flows?

4. Distinguish aggregation from composition.

5. What is the role of a controller in responsibility assignment?

Long Answer Questions

1. Explain a systematic process for transforming a use case into a domain model.

2. Describe class, object, sequence, state-machine, and package diagrams and state when each is most useful.

3. Discuss how cohesion and coupling influence responsibility assignment.

4. Explain why inheritance should represent substitutable “is-a” relationships rather than merely code reuse.

5. Analyze the benefits and limitations of UML in an agile software-development environment.

Analytical / Application Questions

1. Design a textual domain model for an online examination system. Identify entities, value objects, associations, multiplicities, and at least three business constraints.

2. Create a sequence-diagram narrative for an e-commerce order cancellation, including normal and alternative flows. Assign each responsibility to an appropriate participant.

3. Model the states of an AI-based loan application from submission through approval, rejection, withdrawal, or manual review. Identify guards, ethical risks, and audit requirements.

Multiple Choice Questions with Answers

Question 1

Which concept is primarily defined by value rather than independent identity?

A. Entity

B. Value object

C. Controller

D. Actor

Correct Answer: B. Value object

Question 2

What does a multiplicity of 1..* mean?

A. Zero or one instance

B. Exactly one instance

C. One or more instances

D. Any number, including zero

Correct Answer: C. One or more instances

Question 3

Which relationship most strongly represents exclusive whole-part ownership?

A. Dependency

B. Association

C. Shared aggregation

D. Composition

Correct Answer: D. Composition

Question 4

What is the main purpose of a sequence diagram?

A. To show time-ordered interactions

B. To show database normalization

C. To define inheritance syntax

D. To list project risks

Correct Answer: A. To show time-ordered interactions

Question 5

Which principle assigns a responsibility to the class possessing the needed information?

A. Creator

B. Information expert

C. Protected variations

D. Polymorphism

Correct Answer: B. Information expert

Question 6

In a state-machine diagram, what is a guard?

A. A class visibility symbol

B. A package dependency

C. A condition that must be true for a transition

D. A final state marker

Correct Answer: C. A condition that must be true for a transition

Question 7

Which UML relationship indicates that one element uses another and may be affected by its change?

A. Dependency

B. Composition

C. Generalization

D. Aggregation

Correct Answer: A. Dependency

Question 8

Why are Loan and Reservation modeled as classes in the library case?

A. They are user-interface controls

B. They have identity, attributes, and business rules

C. They are always subclasses of BookTitle

D. They eliminate the need for multiplicity

Correct Answer: B. They have identity, attributes, and business rules

Question 9

Which design quality generally improves when a class has closely related responsibilities?

A. Coupling

B. Multiplicity

C. Cohesion

D. Navigability

Correct Answer: C. Cohesion

Question 10

Which sequence-diagram fragment represents alternative guarded paths?

A. loop

B. par

C. ref

D. alt

Correct Answer: D. alt