BE Computer Engineering (IOE, TU) Object Oriented Analysis and Design (IOE, CT 651) Question Paper 2078 Nepal

Object Orientation

Object orientation is a software-development paradigm that models a system as a collection of interacting objects, where each object bundles together data (attributes/state) and the behaviour (operations/methods) that act on that data. A class is the blueprint from which objects (instances) are created.

Core principles of the OO paradigm

The four pillars are abstraction, encapsulation, inheritance and polymorphism.

(a) The four core concepts

Key distinctions: Abstraction is a design-level idea (what to expose); encapsulation is the implementation mechanism (how it is hidden). Inheritance establishes relationships between classes for reuse; polymorphism exploits those relationships so that client code works uniformly across a family of types.

(b) Why OO is more suitable than the structured/procedural approach for large, evolving systems

1. Modularity & maintainability — Behaviour is localized inside the objects that own the data. A change to how a Customer is stored affects only the Customer class, not scattered functions, so the system is easier to modify and debug as it grows.
2. Reusability — Inheritance, composition and design patterns let existing, tested classes be reused across projects, reducing development effort and duplication, whereas procedural code tends to copy-paste logic.
3. Extensibility (resilience to change) — New requirements are met by adding new subclasses and overriding behaviour (open–closed principle) without modifying existing code. Polymorphism lets new types plug into existing client code seamlessly.
4. Better real-world mapping & data integrity — Objects map naturally onto real-world entities (Member, Book, Account), making models intuitive; encapsulation protects invariants, which is critical in large teams.

In the structured approach, data and functions are separated and global data is shared widely, so a small change can ripple unpredictably through the whole program — this becomes unmanageable as systems scale.

Library Management System

(a) Actors, use cases and use case diagram

Actors: Member (borrows/returns books, pays fines), Librarian (manages catalogue, issues/returns), System Clock/Timer (optional, for overdue detection).

Use cases (≥5): Search Catalogue, Borrow Book, Return Book, Manage Catalogue (add/update/remove book), Compute Fine, Pay Fine, Register Member.

Use case diagram (described):

            ┌───────────────── Library System ─────────────────┐
            │                                                  │
  Member ───┼──> (Search Catalogue)                            │
            │                                                  │
  Member ───┼──> (Borrow Book) ----<<include>>--> (Verify      │
            │          |                            Membership)│
            │          '----<<include>>--> (Check Availability)│
            │                                                  │
  Member ───┼──> (Return Book) ----<<extend>>--> (Compute Fine)│
            │                                                  │
  Member ───┼──> (Pay Fine)                                    │
            │                                                  │
Librarian──┼──> (Manage Catalogue)                            │
Librarian──┼──> (Register Member)                             │
            └──────────────────────────────────────────────────┘

• Borrow Book <<include>> Verify Membership and Check Availability — these sub-behaviours are always performed as part of borrowing.
• Return Book <<extend>> Compute Fine — fine computation happens only when the item is overdue (a conditional extension).

(b) Fully-dressed use case: Borrow Book

Main success scenario:

1. Member presents membership card and the book to be borrowed.
2. System verifies the membership is valid and active (<<include>> Verify Membership).
3. System checks the book copy is available (<<include>> Check Availability).
4. System checks the member has not exceeded the borrowing limit and has no blocking unpaid fines.
5. System creates a loan record, sets the due date, and marks the copy as issued.
6. System issues a receipt/confirmation to the member.

Alternative / exception flows:

• 2a. Membership invalid or expired: System notifies the member and aborts; the book is not issued.
• 4a. Borrowing limit exceeded or unpaid fine above threshold: System refuses the loan and prompts the member to return books or clear fines.
• 3a. Copy unavailable / already issued: System informs the member and offers to place a reservation/hold.

(c) Class diagram (described)

  Member                 Loan                  Book
 ----------          ------------          ----------
 -memberId           -loanId               -isbn
 -name               -issueDate            -title
 -address            -dueDate              -author
 -active:bool        -returnDate           -copiesAvailable
 +borrow()           +calcFine():double    +isAvailable()
 +returnBook()       +isOverdue():bool     +updateStock()
 +payFine()
     │ 1                  │ *   1   │
     └───────< 1   *>─────┘─────────┘
     Member 1 ── * Loan          Loan * ── 1 Book

  Librarian              Fine
 -----------         ------------
 -staffId            -amount
 -name               -paid:bool
 +manageCatalogue()  +pay()
 +issueBook()
        Loan 1 ── 0..1 Fine

Associations with multiplicities:

• Member "1" ── "*" Loan : one member can have many loans.
• Book "1" ── "*" Loan : one book (copy) appears in many loans over time.
• Loan "1" ── "0..1" Fine : a loan may generate at most one fine (only if overdue).
• Librarian manages Book (catalogue) and processes Loan records.

Interaction Diagrams

(a) Purpose and sequence vs collaboration diagram

Interaction diagrams model how objects collaborate by exchanging messages to realize a use case or operation. They capture the dynamic behaviour of a system. UML provides two equivalent forms — sequence and communication (collaboration) diagrams.

(b) Sequence diagram: ATM Cash Withdrawal (with insufficient-balance failure)

Objects involved: :Customer, :ATM, :CardReader, :Bank (server), :Account.

Customer    ATM         CardReader    Bank          Account
   │         │              │           │             │
   │ insertCard()           │           │             │
   │────────>│ readCard()   │           │             │
   │         │─────────────>│           │             │
   │ enterPIN()             │           │             │
   │────────>│ validatePIN(pin)         │             │
   │         │─────────────────────────>│             │
   │         │<───── PIN OK ─────────────│             │
   │ enterAmount(amt)       │           │             │
   │────────>│ requestWithdraw(amt)     │             │
   │         │─────────────────────────>│ getBalance()│
   │         │                          │────────────>│
   │         │                          │<── balance ──│
   │         │                          │             │
   │  ── alt [amt <= balance] ───────────────────────  │
   │         │                          │ debit(amt)   │
   │         │                          │────────────>│
   │         │<──── approved ───────────│             │
   │<─ dispenseCash(amt) ─ │            │             │
   │  ── else [amt > balance] (FAILURE) ─────────────  │
   │         │<── insufficientFunds ────│             │
   │<─ showError("Insufficient balance")│             │
   │  ── end alt ──────────────────────────────────── │
   │ ejectCard()            │           │             │
   │<────────│              │           │             │

Explanation: Messages flow top-to-bottom in time order. After the balance is fetched, an alt combined fragment branches: if amt <= balance the account is debited and cash dispensed; in the failure case amt > balance, the bank returns insufficientFunds and the ATM displays an error without dispensing cash. Finally the card is ejected in both paths.

Design Patterns (GoF)

(a) Classification of GoF patterns

The 23 Gang-of-Four patterns are grouped by purpose into three categories:

(b) Observer pattern

Problem it solves: When one object (the subject) changes state, a varying number of dependent objects (observers) must be notified and updated automatically — without the subject being tightly coupled to the concrete observers. It defines a one-to-many dependency between objects.

Participants:

• Subject — maintains a list of observers; provides attach(), detach(), notify().
• Observer — defines the update() interface.
• ConcreteSubject — stores state of interest; calls notify() on change.
• ConcreteObserver — implements update() to keep itself consistent with the subject.

UML class diagram (described):

    Subject                          Observer (interface)
  -------------                      ----------------
  -observers: List<Observer>  o───>  +update()
  +attach(o)                              △
  +detach(o)                              │ implements
  +notify()                               │
      △                            ConcreteObserver
      │ extends                     ----------------
  ConcreteSubject ----observes----> -observerState
  ---------------                   +update()
  -subjectState
  +getState()/+setState()

• Subject aggregates many Observers (1-to-*).
• notify() iterates the observer list and calls update() on each.
• ConcreteObserver holds a reference back to ConcreteSubject to query its new state.

Real-world scenario: A spreadsheet / stock-ticker GUI: a data model (subject) is observed by several views — a bar chart, a table and a pie chart. When the underlying data changes, all charts refresh automatically. Other examples: event-listener mechanisms in GUIs, and publish–subscribe / model-view in MVC frameworks.

Association vs Aggregation vs Composition

All three are structural relationships between classes; they differ in the strength of the connection and in ownership/lifetime semantics.

Examples:

• Association: Student —— Course. A student takes courses and a course has students, but they exist independently.
• Aggregation: Department ◇—— Professor. A department has professors, but a professor still exists if the department is dissolved (can move elsewhere).
• Composition: House ◆—— Room. Rooms are part of a house; if the house is demolished, its rooms cease to exist.

Summary: Association < Aggregation < Composition in coupling strength. Aggregation and composition are special kinds of association; composition implies exclusive ownership and coincident lifetime, aggregation does not.

Statechart Diagram for an Order Object

A statechart shows the states of a single object, the events/transitions that move it between states, and guard conditions on those transitions.

        ●  (initial)
        │ placeOrder
        ▼
   ┌──────────┐  confirmPayment [payment == success]   ┌───────────┐
   │ Created  │ ─────────────────────────────────────> │ Confirmed │
   └──────────┘                                         └───────────┘
        │                                                  │
        │ cancel                                  ship [stockAvailable]
        ▼                                                  ▼
   ┌──────────┐ <──── cancel [before shipment] ────  ┌──────────┐
   │ Cancelled│                                       │ Shipped  │
   └──────────┘                                       └──────────┘
        │                                                  │ deliver
        ▼                                                  ▼
        ⊙  (final)                                  ┌───────────┐
                                                     │ Delivered │
                                                     └───────────┘
                                                          │
                                                          ▼
                                                          ⊙ (final)

States: Created, Confirmed, Shipped, Delivered, Cancelled.

Transitions (event [guard] / action):

• initial → Created : on placeOrder.
• Created → Confirmed : on confirmPayment [payment == success].
• Created → Cancelled : on cancel.
• Confirmed → Shipped : on ship [stockAvailable].
• Confirmed → Cancelled : on cancel [before shipment].
• Shipped → Delivered : on deliver.
• Delivered → final state; Cancelled → final state.

The guard conditions (in square brackets) ensure a transition fires only when the condition is true — e.g., an order can only ship if stockAvailable, and can only be cancelled before it has shipped.

Activity Diagram: Withdraw Money from an ATM

An activity diagram models the workflow/control flow of a process using initial/final nodes, actions, decision/merge nodes and fork/join bars for concurrency.

          ● (initial)
          │
   [Insert Card]
          │
   [Read Card & Prompt PIN]
          │
   [Enter PIN]
          │
        ◇ <PIN valid?>
        ├── No ──> [Show "Invalid PIN"] ──┐
        │                                  │
        └── Yes                            │
          │                               (merge)
   [Enter Withdrawal Amount]               │
          │                                │
        ◇ <Amount <= Balance?>             │
        ├── No ──> [Show "Insufficient"] ──┤
        │                                  │
        └── Yes                            │
          │                               ◇ (merge)
   ═══════╪═══════  (FORK - concurrent)    │
   │              │                        │
[Dispense Cash] [Update Account Balance]   │
   │              │                        │
   ═══════╪═══════  (JOIN)                  │
          │                                │
   [Print Receipt]                         │
          │                                │
   [Eject Card] <───────────────────────────┘
          │
          ⊙ (final)

Notation used:

• Initial node ● and final node ⊙.
• Action nodes: rounded rectangles (Insert Card, Enter PIN, Dispense Cash, etc.).
• Decision (branch) nodes ◇ with guard conditions [PIN valid?] and [Amount <= Balance?]; failing branches flow to error actions.
• Merge nodes ◇ recombine the alternate flows so the card is ejected in all cases.
• Fork / Join (the double bars ═══): after a valid amount, Dispense Cash and Update Account Balance happen concurrently, then synchronise at the join before printing the receipt.

SOLID Design Principles

SOLID is an acronym for five OO design principles that make software easier to maintain and extend.

1. S — Single Responsibility Principle (SRP): A class should have only one reason to change, i.e. exactly one responsibility. This keeps classes focused and reduces ripple effects when requirements change.
2. O — Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification — add new behaviour by adding new code (e.g. subclasses/strategies), not by editing existing, tested code.
3. L — Liskov Substitution Principle (LSP): Objects of a subclass must be substitutable for their base class without breaking correctness; a subtype must honour the contract of its supertype.
4. I — Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use; prefer many small, specific interfaces over one large "fat" interface.
5. D — Dependency Inversion Principle (DIP): High-level modules should depend on abstractions, not on concrete low-level details; both should depend on interfaces.

(Any four of the above are required.)

SRP example — violation and refactoring

Violation — a class doing two unrelated jobs:

class Employee {
    void calculateSalary() { /* business logic */ }
    void saveToDatabase()  { /* persistence logic */ }
    void generateReport()  { /* reporting/printing logic */ }
}

This class changes if salary rules change, or if the database changes, or if the report format changes — three reasons to change.

Refactored — split responsibilities:

class Employee { void calculateSalary() { ... } }      // domain logic
class EmployeeRepository { void save(Employee e) { ... } } // persistence
class EmployeeReport { void generate(Employee e) { ... } } // reporting

Now each class has a single responsibility and a single reason to change.

UML Diagram Types

(a) Structural and behavioural diagrams

Structural (static) diagrams — show the static structure/parts of a system:

1. Class diagram
2. Object diagram
3. Component diagram
4. Deployment diagram (also Package diagram, Composite Structure diagram, Profile diagram)

Behavioural (dynamic) diagrams — show the dynamic behaviour/interactions:

1. Use case diagram
2. Sequence diagram
3. Activity diagram
4. State (statechart) machine diagram (also Communication, Interaction Overview, Timing diagrams)

(b) Object diagram and how it differs from a class diagram

An object diagram shows a snapshot of the system at a particular instant: actual instances of classes (objects) with concrete attribute values and the links between them. It is essentially an instance of a class diagram at run time.

Example: A class diagram has a Student class with attribute name; the object diagram shows ram : Student with name = "Ram" linked to cs101 : Course.

Use Case Relationships

Use case generalization

One use case (child) inherits and specializes the behaviour of a parent use case — an is-a relationship between use cases. Shown by a solid line with a hollow triangle pointing to the parent. Example: Pay by Card and Pay by Cash are specialized children of a general Make Payment use case.

<<include>>

The base use case always incorporates the behaviour of the included use case; the included behaviour is mandatory and is typically common functionality factored out to avoid duplication. Arrow points from base to the included use case. Example: Withdraw Cash <<include>> Authenticate User — every withdrawal must authenticate.

<<extend>>

The extending use case adds optional/conditional behaviour to a base use case at a defined extension point; the base use case is complete on its own and the extension runs only when a condition holds. Arrow points from the extension to the base use case. Example: Withdraw Cash is **<<extend>>**ed by Print Receipt — printing a receipt happens only if the user requests it.

When to prefer <<extend>> over <<include>>

Use <<extend>> when the additional behaviour is optional, conditional, or exceptional and the base use case must remain meaningful without it (e.g. an error handler or an extra feature triggered only in some scenarios). Use <<include>> when the behaviour is always required and shared by multiple use cases.

Factory Method vs Abstract Factory

Both are creational patterns that decouple client code from the concrete classes it instantiates, but they differ in scope and structure.

Factory Method

• Intent: Define an interface (a factory method) for creating an object, but let subclasses decide which concrete class to instantiate. Creation of one product is deferred to subclasses.
• Structure: A Creator declares the abstract method createProduct(); each ConcreteCreator overrides it to return a specific Product. Uses inheritance.
• Example: A Dialog class has createButton(); WindowsDialog returns a WindowsButton, WebDialog returns an HtmlButton.

Abstract Factory

• Intent: Provide an interface for creating families of related/dependent objects without specifying their concrete classes — ensures the products used together are compatible.
• Structure: An AbstractFactory declares multiple creation methods (one per product). Each ConcreteFactory produces a whole family of products. Often uses object composition and internally several factory methods.
• Example: A GUIFactory with createButton() and createCheckbox(); WindowsFactory produces Windows-style button + checkbox, MacFactory produces Mac-style button + checkbox — guaranteeing a consistent look.

Key differences

In short, Abstract Factory is often implemented using several Factory Methods; Factory Method handles one product, Abstract Factory handles whole families.

Short Notes (any two)

(a) Coupling and Cohesion

Cohesion measures how strongly the responsibilities of a single module/class are related; high cohesion (a class doing one well-defined job) is desirable because it improves readability, reuse and maintainability. Coupling measures the degree of interdependence between modules/classes; low (loose) coupling is desirable because changes in one class then have minimal impact on others. Good OO design aims for high cohesion and low coupling, e.g. by programming to interfaces and reducing direct dependencies.

(b) Singleton Design Pattern

A creational pattern that ensures a class has exactly one instance and provides a global point of access to it. It is implemented by making the constructor private and exposing a static getInstance() method that lazily creates and returns the single object.

class Logger {
    private static Logger instance;
    private Logger() {}
    public static Logger getInstance() {
        if (instance == null) instance = new Logger();
        return instance;
    }
}

Typical uses: logging, configuration managers, database-connection pools, caches. (Thread safety must be handled, e.g. with synchronization or eager initialization.)

(c) GRASP Patterns

GRASP (General Responsibility Assignment Software Patterns) are nine principles by Craig Larman that guide which class should be assigned a given responsibility during OO design:

• Information Expert — assign a responsibility to the class that has the information needed to fulfil it.
• Creator — the class that aggregates/contains B should create B.
• Controller — assign handling of system events to a controller class.
• Low Coupling and High Cohesion — keep dependencies low and responsibilities focused.
• Others: Polymorphism, Pure Fabrication, Indirection, Protected Variations.

GRASP provides the reasoning behind responsibility assignment, complementing the GoF design patterns.