Object-Oriented and UML Modeling

Introduction

Object-oriented analysis and design (OOAD) is an approach to understanding and constructing information systems as collections of interacting objects. An object combines data, called state, with operations, called behavior. Instead of describing a system only as a sequence of data-processing functions, OOAD asks: What entities exist? What responsibilities do they have? How do they collaborate to achieve a business goal?

The Unified Modeling Language (UML) provides a standardized visual language for expressing these ideas. UML models do not replace requirements, programming, testing, or database design. They provide a precise communication medium between users, analysts, designers, developers, testers, and project managers. A good model reduces ambiguity while remaining at an appropriate level of detail.

This chapter uses a library-management scenario to illustrate modeling techniques. The same principles apply to banking, e-commerce, healthcare, education, and enterprise systems.

Learning Objectives

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

1. Explain object-oriented concepts including abstraction, encapsulation, inheritance, polymorphism, association, aggregation, and composition.
2. Distinguish conceptual, analysis, design, and implementation models.
3. Identify actors, use cases, classes, attributes, operations, and relationships.
4. Create and interpret use-case, class, sequence, activity, and state-machine diagrams.
5. Apply UML modeling to a realistic system problem.
6. Evaluate models for correctness, consistency, traceability, usability, and maintainability.
7. Recognize ethical, security, governance, and practical limitations of modeling.

1. Foundations of Object Orientation

1.1 Objects and classes

An object is a distinguishable entity with identity, state, and behavior. In a library system, a particular book copy, member, or loan is an object. A class is a specification from which objects are created. The class BookCopy may specify attributes such as barcode and status, and operations such as markLoaned() and markAvailable().

Objects are often represented using the notation objectName:ClassName. For example, copy104:BookCopy identifies one object of the BookCopy class. A class describes common characteristics; objects contain particular values.

1.2 Abstraction

Abstraction focuses attention on essential characteristics and suppresses irrelevant detail. A circulation clerk needs to know that a book copy is available or on loan, but does not need to know how a barcode scanner encodes its signal. Abstraction is relative to purpose: the same object may be modeled differently for circulation, finance, or inventory management.

1.3 Encapsulation

Encapsulation places data and the operations that govern it within one unit and limits inappropriate access. Rather than allowing any component to assign status = 'available', the BookCopy class can expose returnCopy() and validate the transition. Encapsulation protects invariants—conditions that must remain true—such as the rule that a copy cannot be loaned while already on loan.

Visibility symbols commonly used in UML are:

1.4 Inheritance and polymorphism

Inheritance defines a generalization relationship in which a specialized class reuses and extends a more general class. For example, StudentMember and StaffMember may specialize Member. The specialized classes inherit common attributes such as member ID and common behavior such as renewLoan().

Polymorphism allows a common operation to have different implementations. A calculateLoanPeriod() operation might return 14 days for a student and 28 days for staff. Code can invoke the operation through the common Member type without depending on every subtype's internal implementation.

Inheritance should represent a genuine “is-a” relationship. A StudentMember is a Member; a Loan is not a Member. Excessive inheritance creates rigid designs. Composition and interfaces are often preferable when behavior varies independently of a class hierarchy.

1.5 Associations, aggregation, and composition

An association is a structural relationship between classes. A Member borrows a BookCopy, and a Librarian registers a Loan. Associations may have role names, navigability, and multiplicities.

Multiplicity describes how many instances may participate:

• 1 — exactly one
• 0..1 — zero or one
• or 0.. — zero or many
• 1..* — one or many
• 2..5 — between two and five

Aggregation is a weak whole–part relationship. A department may aggregate employees, but an employee can exist independently of that department. Composition is a strong whole–part relationship. A LoanLine created solely as part of a Loan normally has no independent life; if the loan is deleted, its lines are deleted as well. Composition should be used only when ownership and lifecycle dependence are real.

1.6 Interfaces and dependency

An interface specifies operations that a class promises to provide, without prescribing implementation. A NotificationService interface may be implemented by EmailNotification and SmsNotification. A dependency indicates that one element temporarily uses another. For example, LoanController may depend on NotificationService without owning it.

2. UML as a Modeling Language

UML has structural diagrams, which describe what exists, and behavioral diagrams, which describe what happens. The diagrams in this chapter are complementary, not competing alternatives.

A model may be conceptual, showing business concepts without software implementation; analysis-oriented, clarifying responsibilities and collaborations; or design-oriented, including interfaces, controllers, data types, and technical components. Mixing these levels without explanation causes confusion.

UML is not a programming language and does not guarantee a correct implementation. A diagram is useful only when its elements have clear meaning, consistent names, and a connection to requirements.

3. Use-Case Modeling

3.1 Purpose and elements

A use case describes a goal that an external actor achieves by interacting with a system. An actor is a person, organization, device, or external system that exchanges information with the system. Actors are defined by roles, not job titles; the same person may act as both Member and Librarian in different circumstances.

A system boundary distinguishes the system being modeled from its environment. Use cases are named with goal-oriented verb phrases such as Borrow Book, Return Book, and Search Catalogue.

A textual use-case specification normally contains:

• Name and goal
• Primary actor and supporting actors
• Trigger
• Preconditions
• Main success scenario
• Alternative and exception flows
• Postconditions
• Business rules and special requirements

3.2 Relationships

An include relationship indicates behavior that is always reused by another use case. Borrow Book may include Authenticate Member. An extend relationship represents optional or conditional behavior. Calculate Fine may extend Return Book when the return is late. Generalization can relate a specialized actor or use case to a generalized one.

Use cases should describe externally observable behavior, not internal program steps. “Validate loan eligibility” can be a step in a scenario; “execute SQL query” is usually an implementation detail.

3.3 Example: Borrow Book

Primary actor: Member

Supporting actor: Payment Gateway (only if an unpaid fine exists)

Trigger: The member requests to borrow a selected book copy.

Preconditions: The member is registered; the copy is recorded in the catalogue.

Main success scenario:

1. The member presents an identification token.
2. The system authenticates the member.
3. The member presents a book copy.
4. The system verifies that the copy is available and that the member has borrowing capacity.
5. The system creates a loan, assigns a due date, and changes the copy status to OnLoan.
6. The system displays or sends confirmation.

Alternative flows: If the copy is unavailable, the system offers a reservation. If the member has unpaid fines, the system requests payment or refuses the loan according to policy.

Postconditions: A valid loan exists, or no loan is created and the reason is communicated.

A use-case model establishes scope and user goals, but it does not show the detailed order of messages. That is the role of a sequence diagram.

4. Class Modeling

4.1 Finding candidate classes

Candidate classes can be discovered from requirements by examining nouns, but every noun is not automatically a class. A useful candidate should have meaningful identity, attributes, behavior, or relationships. In the library scenario, likely candidates include Member, Book, BookCopy, Loan, Reservation, and Catalogue. Terms such as “system,” “information,” and “screen” may be too vague or may belong to a later design model.

A class is more than a data record. Responsibilities should be assigned to the class possessing the information needed to perform them. This is often called the information expert principle. For example, Loan is a natural place to determine whether its due date has passed, while a controller should coordinate rather than contain every business rule.

4.2 Class notation

A UML class rectangle is divided into name, attributes, and operations:

+--------------------------------+
| BookCopy                       |
+--------------------------------+
| - barcode: String              |
| - status: CopyStatus           |
+--------------------------------+
| +checkout(): void              |
| +returnCopy(): void            |
| +isAvailable(): Boolean        |
+--------------------------------+

An attribute has a name and type; an operation may include parameters and a return type. Visibility and types should be shown when they contribute to design clarity. Avoid displaying every getter and setter in an analysis model because excessive detail hides important relationships.

4.3 Example domain relationships

A Book may have one or more BookCopy objects. Each BookCopy represents a physical or licensed copy of a title. A Member may have zero or many Loan objects over time, while each Loan belongs to exactly one member and concerns one copy in a simple circulation model.

The class Loan can preserve historical facts such as checkout date, due date, and return date. Modeling a loan merely as an association between Member and BookCopy would lose these attributes and make history difficult to represent. This is an example of an association class or, more practically, a domain class created from a relationship with its own data and behavior.

4.4 Responsibility-driven design

A class should have cohesive responsibilities and limited dependence on unrelated classes. Useful principles include:

• High cohesion: related responsibilities remain together.
• Low coupling: classes depend on as few implementation details as possible.
• Single responsibility: a class has one coherent reason to change.
• Open–closed principle: behavior should be extendable without repeatedly modifying stable code.
• Dependency inversion: high-level policy should depend on abstractions rather than concrete technical services.

These principles are guidelines, not mechanical rules. A design must also consider performance, security, usability, transaction boundaries, and organizational constraints.

5. Sequence Diagrams

A sequence diagram emphasizes the time ordering of messages among actors and objects. Participants appear horizontally; time progresses downward. A vertical dashed line is a lifeline. A narrow rectangle indicates an activation during which an object is executing an operation. Solid arrows generally represent calls, while dashed arrows often represent returns.

Example for Borrow Book:

Member     BorrowUI       LoanController       Member       BookCopy       Loan
  |           |                  |                |             |             |
  |--borrow()->|                |                |             |             |
  |           |--request------->|                |             |             |
  |           |                  |--isEligible()->|             |             |
  |           |                  |--isAvailable()--------------->|             |
  |           |                  |--createLoan------------------------------->|
  |           |                  |--checkout()------------------>|             |
  |           |<--confirmation---|                |             |             |

A robust sequence diagram identifies the system event, assigns responsibilities, and exposes missing operations. The controller should coordinate the interaction, while domain objects should enforce business rules. The diagram should not imply that a user interface directly edits database tables.

Important design questions include: What happens if authentication fails? Is loan creation transactional with the status change? How is a concurrent attempt to borrow the same copy prevented? What message is sent when a payment service is unavailable? Sequence diagrams can reveal these issues before implementation.

6. Activity Diagrams

An activity diagram models workflow, control flow, and sometimes object flow. It uses initial and final nodes, actions, decisions, merges, forks, joins, and swimlanes. Swimlanes assign actions to roles or systems.

A simplified return process is:

[Start] → Receive copy → Identify loan → [Loan found?]
                         ├─ No → Report exception → [End]
                         └─ Yes → Record return → [Late?]
                                      ├─ Yes → Calculate fine → Request payment
                                      └─ No ───────────────────┐
                                                             ↓
                                             Mark copy available → [End]

A decision must have guards such as [yes] and [no]. A merge brings alternative paths together; it is not the same as a join. A fork creates concurrent flows, while a join waits for concurrent flows to complete. For example, after a successful return, the system might update inventory and send a notification concurrently, but it must join them if a later step requires both to finish.

Activity diagrams are particularly useful for business-process analysis, approval workflows, exception handling, and identifying manual–automated boundaries.

7. State-Machine Diagrams

A state-machine diagram models the lifecycle of one object or class. A state is a condition during which an object satisfies an invariant. A transition occurs in response to an event and may have a guard and an effect.

A transition can be expressed as:

event [guard] / effect

For a BookCopy, a useful lifecycle is:

[Initial] → Available
Available --checkout [eligible] / create loan--> OnLoan
OnLoan --return / record return--> Available
OnLoan --report damaged / record damage--> Damaged
Available --withdraw / record withdrawal--> Withdrawn
Damaged --repair complete--> Available

States should be stable conditions, not actions. CheckingOut may be appropriate if the process is long-running or interruptible; otherwise checkout is better modeled as an event causing a transition. State models help prevent invalid operations, such as returning a copy that is already available or lending a withdrawn copy.

A state machine can include entry actions, exit actions, internal transitions, composite states, and history. It should be used when an object’s behavior depends significantly on its current state; it is unnecessary for every simple class.

8. Maintaining Consistency Across Diagrams

Models are valuable when they form a traceable set. A use case should be realized by one or more activity or sequence diagrams. Messages in sequence diagrams should correspond to operations in class diagrams. States in a state machine should explain constraints referenced by use cases. Requirements should be traceable to model elements and eventually to tests.

A practical consistency review asks:

1. Does every major actor have a legitimate system goal?
2. Does every important use case have normal and exceptional flows?
3. Are association multiplicities compatible with business rules?
4. Do sequence messages name operations that the receiving class owns or exposes?
5. Are state transitions triggered by events present in requirements or interactions?
6. Are terminology and identifiers consistent across diagrams?
7. Are security, audit, privacy, and failure behavior represented where relevant?

Version control, model repositories, naming standards, and lightweight review checklists improve model quality. Models should be updated as understanding changes; they are not documents to be produced once and abandoned.

Applied Case: Community Library Renewal Service

Background

This illustrative case concerns a university library that permits members to borrow physical books and renew loans online. A member may renew a loan only if no reservation exists for the book, the maximum renewal count has not been reached, and the account is not blocked.

Problem

The existing system stores loans but applies renewal rules inconsistently. Staff sometimes renew loans manually, while the web application omits reservation checks. Members receive conflicting due dates, and there is no clear audit trail.

Analysis

The principal actor is Member; Librarian is a supporting actor for assisted renewal. Candidate domain classes include Member, Loan, Book, Reservation, and RenewalPolicy. The policy should not be duplicated in several screens. Loan can record renewal count and due date, while a policy service can evaluate rules that depend on reservations and member status.

The Renew Loan use case has the following preconditions: the member is authenticated and the loan belongs to that member. The main scenario verifies account status, checks reservation absence, evaluates the renewal limit, calculates a new due date, records the renewal, and sends confirmation. Alternative flows explain blocked accounts, existing reservations, expired loans, and service failure.

A sequence model would show RenewalUI sending a request to LoanController, which obtains the loan, asks RenewalPolicy to evaluate eligibility, invokes Loan.renew(), stores the result, and sends notification. The state model for a loan may distinguish Active, Overdue, Returned, and RenewalRejected; rejection is often an event outcome rather than a persistent state, so the model should not add it as a state without a business reason.

Approach and outcome

The team creates a conceptual class model first, then adds design classes only where implementation decisions are needed. A single policy component is used by both the web and staff interfaces. Every renewal produces an audit record containing actor, time, old due date, new due date, and decision reason. Acceptance tests are traced to use-case alternatives.

The expected outcome is consistent rule enforcement, explainable decisions, and improved maintainability. The model also exposes a governance question: audit records should be protected from unauthorized alteration and retained only for the period justified by institutional policy.

Learning points

The case demonstrates that modeling is not merely drawing boxes. It clarifies responsibility, identifies inconsistent rules, supports test design, and raises questions about auditability and privacy. It also illustrates why a domain concept such as RenewalPolicy may be more useful than placing all logic in a user-interface controller.

Professional, Ethical, and Contemporary Considerations

Modeling decisions affect real people. Systems should not silently encode discriminatory eligibility rules, excessive surveillance, or inaccessible workflows. Analysts must identify who is represented and who may be excluded. Use-case actors should include relevant external organizations and support roles, not only the system’s paying sponsor.

Privacy requirements should influence models: personal data classes need ownership, access controls, retention rules, and audit behavior. Security use cases such as Authenticate User, Authorize Action, and Review Audit Log should be modeled when they are significant system goals. Threat modeling can complement UML by examining misuse cases, trust boundaries, and attack paths.

AI-assisted modeling tools can extract candidate classes, generate draft diagrams, or translate text into UML-like notation. Such output requires human review because language models may invent requirements, confuse actors with objects, or produce syntactically plausible but semantically false relationships. Sensitive requirements and personal data should not be submitted to unapproved tools. The accountable analyst remains responsible for accuracy, traceability, accessibility, and compliance.

Contemporary development often uses iterative modeling, domain-driven design, model-based testing, and architecture descriptions alongside UML. Agile teams need not model everything upfront; they should model the decisions whose misunderstanding would be costly. Executable specifications, automated tests, and code analysis can supplement diagrams, but they do not eliminate the need for stakeholder conversation.

Common Errors and Best Practices

Common errors include treating every noun as a class, using vague use-case names, confusing aggregation with composition, omitting multiplicities, putting database tables in a conceptual model, showing implementation detail too early, and drawing sequence diagrams whose messages do not correspond to class operations.

Best practices are to:

• Begin with stakeholder goals and system boundaries.
• Use a consistent vocabulary and maintain a glossary.
• Separate conceptual, analysis, and design concerns.
• Model alternatives, exceptions, and failure conditions.
• Assign behavior to information-owning objects where appropriate.
• Prefer simple, justified relationships over decorative complexity.
• Review models with both domain experts and technical specialists.
• Trace diagrams to requirements, acceptance criteria, and tests.
• Treat models as evolving communication artifacts.
• Record assumptions and unresolved questions.

Chapter Summary

Object-oriented modeling represents a system as collaborating objects with identity, state, and behavior. Abstraction controls complexity; encapsulation protects state and invariants; inheritance and polymorphism support specialization and substitutable behavior; associations express relationships and multiplicities; aggregation and composition distinguish weak and strong ownership.

UML supplies complementary views. Use-case diagrams capture actor goals and system scope. Class diagrams represent structural concepts, attributes, operations, and relationships. Sequence diagrams show time-ordered collaboration. Activity diagrams represent workflows, decisions, and concurrency. State-machine diagrams describe the lifecycle of an individual object. Effective analysis maintains consistency and traceability across all views.

Professional modeling requires more than notation. Models must reflect real requirements, support maintainable responsibility allocation, address exceptions and security, respect privacy and accessibility, and be reviewed by stakeholders. UML is most useful when it communicates decisions clearly and is connected to implementation and testing without pretending to replace them.

Key Terms

Object: An entity with identity, state, and behavior.

Class: A specification describing a set of objects.

Abstraction: Focusing on essential characteristics while omitting irrelevant detail.

Encapsulation: Bundling state and behavior while controlling access.

Inheritance: A generalization mechanism by which a specialized class reuses a general class.

Polymorphism: The ability to use a common operation with type-specific implementations.

Association: A structural relationship between classes.

Aggregation: A weak whole–part relationship in which parts may exist independently.

Composition: A strong whole–part relationship involving ownership and lifecycle dependence.

Multiplicity: The permitted number of instances participating in a relationship.

Actor: An external role that interacts with a system.

Use case: A goal-oriented description of valuable system behavior.

Class diagram: A UML diagram describing structural elements and relationships.

Sequence diagram: A diagram showing ordered messages among participants.

Activity diagram: A diagram describing workflow and control flow.

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

Guard: A condition that must be true for a transition or flow to occur.

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

Coupling: The degree of dependence between software elements.

Traceability: The ability to connect requirements to models, implementation, and tests.

Review Questions

Short Answer Questions

1. What are the three essential characteristics of an object?
2. Distinguish aggregation from composition.
3. What is the purpose of a system boundary in a use-case model?
4. What information does a multiplicity such as 0..* communicate?
5. When is a state-machine diagram especially useful?

Long Answer Questions

1. Explain abstraction, encapsulation, inheritance, and polymorphism using examples from a library-management system.
2. Describe the elements of a complete use-case specification and explain why alternative flows matter.
3. Compare use-case, class, sequence, activity, and state-machine diagrams.
4. Explain how high cohesion and low coupling influence responsibility assignment in an object-oriented design.
5. Discuss how UML models should evolve from conceptual analysis to software design.

Analytical / Application Questions

1. Model an online food-ordering system by identifying at least four actors, six use cases, and two include or extend relationships. Justify each relationship.
2. A hospital appointment may be requested, confirmed, cancelled, missed, or completed. Propose a state-machine model and identify events, guards, and invalid transitions.
3. In the library renewal case, evaluate whether renewal eligibility should belong entirely to Loan, entirely to Member, or to a separate policy component. Defend your decision using cohesion, coupling, changing requirements, and testability.

Multiple Choice Questions with Answers

Question 1

Which concept protects an object's internal state by controlling access to it?

A. Encapsulation

B. Inheritance

C. Multiplicity

D. Generalization

Correct Answer: A. Encapsulation

Question 2

In a use-case model, an actor is best defined as:

A. A database table used by the system

B. An external role that interacts with the system

C. A private method inside a class

D. A state in an object lifecycle

Correct Answer: B. An external role that interacts with the system

Question 3

What does the multiplicity 0..* mean?

A. Exactly one

B. One or more

C. Zero or many

D. Zero or one

Correct Answer: C. Zero or many

Question 4

Which UML diagram primarily shows time-ordered messages among objects?

A. Activity diagram

B. Class diagram

C. State-machine diagram

D. Sequence diagram

Correct Answer: D. Sequence diagram

Question 5

Which relationship indicates strong ownership and lifecycle dependence between a whole and its parts?

A. Dependency

B. Composition

C. Generalization

D. Association

Correct Answer: B. Composition

Question 6

Which use-case relationship represents behavior that is always reused by another use case?

A. extend

B. include

C. aggregation

D. composition

Correct Answer: B. include

Question 7

In a state transition written as event [guard] / effect, the guard is:

A. The resulting state

B. The condition that must be true

C. The object that sends the event

D. The class attribute being changed

Correct Answer: B. The condition that must be true

Question 8

Which principle recommends assigning behavior to the class that has the information needed to perform it?

A. Information expert

B. Least privilege

C. Model-view separation

D. Interface segregation

Correct Answer: A. Information expert

Question 9

Which diagram is most appropriate for showing parallel workflow branches and their synchronization?

A. Activity diagram

B. Use-case diagram

C. Class diagram

D. Object diagram

Correct Answer: A. Activity diagram

Question 10

Why should every noun in a requirements document not automatically become a class?

A. UML prohibits nouns as class names

B. Some nouns are merely attributes, actions, roles, or vague terms

C. Classes may only represent hardware

D. Nouns can only be used in sequence diagrams

Correct Answer: B. Some nouns are merely attributes, actions, roles, or vague terms