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

(a) Object Orientation vs. Structured (Procedural) Approach

Object orientation is a software development paradigm that organizes a system as a collection of interacting objects, where each object bundles together data (attributes) and the behaviour (methods) that operates on that data. The system is built by modelling real-world entities as classes/objects that collaborate by sending messages.

Difference from the structured/procedural approach:

In short, procedural design centres on algorithms acting on passive data, whereas OO design centres on active objects that own their data, giving better modularity, reuse and maintainability.

(b) Four Fundamental Principles of Object Orientation

1. Abstraction — Representing the essential features of an entity while hiding unnecessary detail. We model only what is relevant to the problem. Example: A Car class exposes start(), accelerate(), brake() to the driver but hides the internal combustion details. A bank Account is abstracted by balance, deposit(), withdraw().

2. Encapsulation — Bundling data and the methods that operate on it within a single unit (the object) and restricting direct access to the internal state (information hiding). Access is provided only through a well-defined public interface. Example: In an Account class the balance attribute is declared private; clients can only change it via deposit()/withdraw(), which can enforce rules (e.g. balance must not go negative).

3. Inheritance — A mechanism by which a new class (subclass/derived class) acquires the attributes and behaviour of an existing class (superclass/base class), enabling reuse and an is-a hierarchy. The subclass may add or override features. Example: SavingsAccount and CurrentAccount inherit from Account, reusing deposit()/withdraw() and adding their own behaviour (e.g. interest calculation).

4. Polymorphism — "Many forms": the ability of different objects to respond to the same message (method call) in their own specific way; the correct method is selected at run time (dynamic binding). Example: Calling area() on a Shape reference invokes Circle.area(), Rectangle.area(), etc. depending on the actual object. A single for(Shape s : shapes) s.area(); works for every shape type.

Together these four principles allow systems that are modular, reusable, extensible and easy to maintain.

(a) Use Case Diagram — Library Management System

Actors: Member, Librarian. (Optionally a Catalogue/DB as a supporting actor.)

Use cases: Search Book, Borrow Book, Return Book, Reserve Book, Manage Catalogue, Register Fine, Login.

Relationships:

• Borrow Book «include» Search Book (you must locate a book before borrowing) and «include» Login.
• Return Book «extend» Register Fine (a fine is charged only if the book is overdue — a conditional extension).
• Reserve Book «include» Search Book; reservation applies only when the book is currently issued.

Textual layout of the diagram:

          ____________ Library Management System ____________
         |                                                   |
         |   (Login) <----«include»---- (Borrow Book)        |
         |      ^                          |                 |
Member --+------|------ (Search Book) <--«include»            |
         |                 ^               |                 |
         |      (Reserve Book)        (Return Book)           |
         |                                 |                  |
         |                            «extend» v              |
         |                            (Register Fine)         |
Librarian+----- (Manage Catalogue)        (Register Fine)     |
         |________________________________________________   |

• Member is associated with Search Book, Borrow Book, Return Book, Reserve Book.
• Librarian is associated with Manage Catalogue and Register Fine.

(b) Class Diagram — Domain Model

Key domain classes, attributes and operations:

• Member — memberId, name, address, finesDue ; searchBook(), borrow(), returnBook(), reserve()
• Librarian — staffId, name ; addBook(), removeBook(), registerFine()
• Book (catalogue title) — isbn, title, author, category ; getDetails()
• BookCopy (physical copy) — copyId, status ; markIssued(), markAvailable()
• Loan — loanId, issueDate, dueDate, returnDate ; isOverdue(), calculateFine()
• Reservation — reservationId, date, status ; cancel()
• Fine — fineId, amount, paid ; pay()

Relationships & multiplicities:

Book "1" ◇——————< "1..*" BookCopy        (composition: copies belong to a Book)
Member "1" ————————< "0..*" Loan
BookCopy "1" ———————< "0..*" Loan
Member "1" ————————< "0..*" Reservation
Book "1" ————————————< "0..*" Reservation
Loan "1" ◇——————— "0..1" Fine             (aggregation: a fine arises from a loan)
Librarian "1" ——————< "0..*" Fine          (registers)

• Composition (filled diamond): Book ◆—— BookCopy — physical copies cannot exist without their Book title; deleting the book deletes its copies.
• Aggregation (hollow diamond): Loan ◇—— Fine — a fine is associated with a loan but can exist/be tracked independently of it.
• Multiplicities such as 1..*, 0..*, 0..1 are shown at each association end.

This model captures borrowing (Loan), reservation, fining and the catalogue structure with proper associations, multiplicities and a composition/aggregation pair.

(a) Operation Contract for makePayment(amount, cardDetails)

Post-conditions are stated as declarations about the state of the system after the operation completes (instance creation, attribute changes, associations formed/broken).

(b) Sequence Diagram — "Book a ticket"

Participating objects: :Customer (actor), :BookingUI, :BookingController, :ShowCatalog, :Show, :PaymentGateway, :Ticket.

Textual sequence (top-to-bottom messages with return values):

Customer -> BookingUI : selectShow(showId)
BookingUI -> BookingController : requestSeats(showId)
BookingController -> ShowCatalog : getShow(showId)
ShowCatalog --> BookingController : show
BookingController -> Show : checkAvailability(seats)
Show --> BookingController : availableSeats

alt [seats available]
    BookingController -> Show : holdSeats(seats)
    Customer -> BookingUI : makePayment(amount, card)
    BookingUI -> BookingController : makePayment(amount, card)
    BookingController -> PaymentGateway : authorize(amount, card)
    PaymentGateway --> BookingController : authCode

    opt [payment approved]
        BookingController -> Show : confirmSeats(seats)
        BookingController -> Ticket : <<create>> (show, seats, customer)
        Ticket --> BookingController : ticket
        BookingController --> BookingUI : confirmedTicket
        BookingUI --> Customer : show ticket
    end
else [no seats]
    BookingController --> BookingUI : seatsUnavailable
    BookingUI --> Customer : error message
end

Notes on notation used:

• Solid arrows = synchronous messages; dashed arrows (-->) = return values.
• alt fragment handles the seat-available vs. unavailable alternatives.
• opt fragment handles the conditional payment-approved path.
• A loop fragment could wrap checkAvailability/seat selection if the customer retries.
• <<create>> denotes instance creation of the Ticket object.

Lifelines are drawn vertically with activation bars during each call, messages flow left-to-right in time order from top to bottom.

(a) Design Patterns and the GoF Categories

A design pattern is a general, reusable, named solution to a commonly occurring design problem within a given context. It is not finished code but a template/description of how to solve a problem that can be applied in many situations, capturing proven design experience. The Gang of Four (GoF) catalogued 23 such patterns in three categories:

1. Creational patterns — deal with object creation mechanisms, making a system independent of how its objects are created and represented. Example: Singleton (ensures a single instance) or Factory Method (defers instantiation to subclasses).

2. Structural patterns — deal with the composition of classes and objects to form larger structures while keeping them flexible and efficient. Example: Adapter (makes incompatible interfaces work together) or Decorator (adds responsibilities dynamically).

3. Behavioural patterns — deal with communication, responsibility and interaction between objects. Example: Observer (one-to-many notification) or Strategy (interchangeable algorithms).

(b) Observer Pattern

Intent: Define a one-to-many dependency between objects so that when one object (the Subject) changes state, all its dependents (Observers) are notified and updated automatically. It promotes loose coupling between the subject and its observers.

Structure (class diagram in text):

   +------------------+              +------------------+
   |     Subject      |<>----------->|    Observer      | (interface)
   +------------------+   observers  +------------------+
   | attach(o)        |   0..*       | update()         |
   | detach(o)        |              +------------------+
   | notify()         |                     ^
   +------------------+                     | implements
          ^                          +------------------+
          | extends                  | ConcreteObserver |
   +------------------+              +------------------+
   | ConcreteSubject  |              | update()         |
   | getState()       |  subject     | observerState    |
   | setState()       |<-------------|                  |
   +------------------+              +------------------+

• Subject keeps a list of Observers and provides attach(), detach(), notify().
• On a state change, ConcreteSubject calls notify(), which calls update() on every registered Observer.

Real-world scenario: A stock-market / weather dashboard where many display widgets (graph, table, mobile alert) must update whenever the underlying data changes. The data source is the Subject; each widget is an Observer that registers itself. This is also used in GUI event handling, the publish–subscribe model, and the Model-View-Controller pattern (Views observe the Model). It is the best choice precisely when multiple objects must stay consistent with one source of truth without tightly coupling the source to its consumers.

Association vs. Aggregation vs. Composition

All three model a structural relationship between classes; they differ in ownership strength and lifetime dependency.

Examples:

• Association: Student —— Course (a student takes courses; both exist independently). Notation: Student ──── Course.
• Aggregation: Department ◇—— Professor (a department has professors, but a professor still exists if the department is dissolved; professors may belong to several departments).
• Composition: House ◆—— Room (rooms cannot exist without the house; destroying the house destroys its rooms). Another classic: Order ◆—— OrderLine.

Key memory aid: Association = knows-a; Aggregation = has-a (weak, shared); Composition = owns-a / part-of (strong, exclusive lifetime).

Categories of UML Diagrams

UML 2.x defines 14 diagram types in two broad groups:

A. Structural diagrams (show the static structure):

1. Class diagram
2. Object diagram
3. Component diagram
4. Deployment diagram
5. Package diagram
6. Composite structure diagram
7. Profile diagram

B. Behavioural diagrams (show dynamic behaviour over time):

1. Use case diagram
2. Sequence diagram
3. Communication (collaboration) diagram
4. Activity diagram
5. State machine (statechart) diagram
6. Timing diagram
7. Interaction overview diagram

(Sequence, communication, timing and interaction-overview are sub-types of interaction diagrams.)

Purpose of Three Behavioural Diagrams

1. Use Case Diagram — Captures the functional requirements of a system by showing actors (external users/systems) and the use cases (services) they interact with, plus «include»/«extend» relationships. It defines what the system does from the user's viewpoint.

2. Sequence Diagram — Shows how objects interact over time through an ordered exchange of messages along vertical lifelines. It emphasises the time ordering of messages for a particular scenario and is useful for designing the realization of a use case.

3. Activity Diagram — Models the flow of control/work through a process or algorithm, showing actions, decisions (branches), and concurrency via fork/join nodes. It is ideal for describing business processes and workflows, similar to a flowchart with support for parallelism.

State Diagram vs. Activity Diagram

In short: a state diagram answers "what states can this object be in and what events move it between them?", while an activity diagram answers "what is the sequence and coordination of steps in this process?"

State Diagram for an Order Object

   ● (initial)
   |
   v
[Created] --pay()--> [Paid] --ship()--> [Shipped] --deliver()--> [Delivered] --> ◉ (final)
   |                   |
   | cancel()          | cancel()
   v                   v
[Cancelled] <----------+
   |
   v
  ◉ (final)

Description:

• Initial pseudostate → Created (order placed).
• pay() event: Created → Paid.
• ship() event: Paid → Shipped.
• deliver() event: Shipped → Delivered → final state.
• cancel() event: from Created or Paid → Cancelled → final state (an order can no longer be cancelled once shipped/delivered).

Each arrow is labelled with the triggering event; guard conditions (e.g. [stock available]) can be added in brackets where needed.

Collaboration (Communication) Diagram

A collaboration diagram (called a communication diagram in UML 2) is an interaction diagram that shows the objects participating in an interaction and the links (messages) exchanged between them, emphasising the structural organization of objects rather than time. Messages are numbered to indicate their sequence.

Difference from a Sequence Diagram

Both are semantically equivalent (one can be derived from the other) but highlight different aspects of the same interaction.

Collaboration Diagram — "Withdraw Cash from ATM"

               1: insertCard / enterPin
   :Customer ───────────────────────────► :ATM
                                            │ 2: validate(pin)
                                            ▼
                                        :BankServer
                                            │ 3: checkBalance(amount)
                                            ▼
                                         :Account

   Numbered messages:
   1 : Customer -> :ATM        : requestWithdrawal(amount)
   2 : :ATM -> :BankServer     : validate(card, pin)
   2.1: :BankServer --> :ATM   : ok
   3 : :ATM -> :Account        : debit(amount)
   3.1: :Account --> :ATM      : newBalance
   4 : :ATM -> :Customer       : dispenseCash(amount)

Here the objects :Customer, :ATM, :BankServer and :Account are linked, and the numbered messages (1, 2, 2.1, 3, 3.1, 4) convey the sequence of the withdraw interaction. The ATM validates the PIN, debits the account, and dispenses the cash.

Three SOLID Principles (with violation & fix)

SOLID is a set of five OO design principles (Single-responsibility, Open-closed, Liskov-substitution, Interface-segregation, Dependency-inversion) that promote maintainable, flexible designs. Any three:

1. Single Responsibility Principle (SRP)

A class should have only one reason to change — i.e. one responsibility.

• Violation: A Report class that both generates report data and prints/saves it to a file (two reasons to change).
• Fix: Split into Report (holds/produces data) and ReportPrinter/ReportRepository (handles output/persistence).

2. Open–Closed Principle (OCP)

Software entities should be open for extension but closed for modification. Add new behaviour without editing existing tested code.

• Violation: A Shape.area() method with a big if (type == circle) … else if (type == square) … that must be edited every time a new shape is added.
• Fix: Make Shape an abstract class/interface with an area() method and let each new shape (Circle, Square) override it. New shapes are added by extension only.

3. Liskov Substitution Principle (LSP)

Objects of a subclass must be usable wherever objects of the superclass are expected, without breaking correctness.

• Violation: Square extends Rectangle where setWidth() also forces height to change, breaking code that assumes width and height are independent (e.g. a test expecting area = w*h).
• Fix: Don't force the inheritance; model Square and Rectangle as separate types implementing a common Shape interface, so substitution never breaks invariants.

(Other principles: ISP — prefer many small client-specific interfaces over one fat interface; DIP — depend on abstractions, not concrete classes.)

Definitions

Actor — An external entity (a human role, another system, or a device) that interacts with the system and lies outside its boundary. An actor plays a role and exchanges information with the system, e.g. Member, Administrator, Payment Gateway.

Use Case — A description of a complete, valuable unit of functionality that the system provides to one or more actors to achieve a goal, e.g. "Withdraw Cash", "Place Order". It represents what the system does, not how.

Scenario — A specific single sequence of steps/instance of executing a use case. A use case has one main success scenario (the normal flow) plus several alternative/exception scenarios (e.g. "payment declined"). It is one concrete path through the use case.

Use Case Extension — An optional or conditional behaviour, captured as a separate (extending) use case that adds steps to a base use case at a defined extension point, only under certain conditions, via the «extend» relationship.

«include» vs. «extend»

Activity Diagram — User Registration with Email Verification

Textual description of the activity flow (drawn as an activity diagram with rounded-rectangle actions, a diamond for decisions, and a thick bar for fork/join):

  ● (start)
  |
  v
[Enter registration details]
  |
  v
[Validate input]
  |
  v
< Input valid? >----No----> [Show error message] ---> (back to Enter details)
  | Yes
  v
========== FORK ==========              (do two things in parallel)
  |                       |
  v                       v
[Create inactive account] [Send verification email]
  |                       |
  ========== JOIN ==========
  |
  v
[Wait for user to click verification link]
  |
  v
< Link clicked within time limit? >
   |                         |
   | Yes                     | No (timeout)
   v                         v
[Activate account]      [Delete/expire pending account]
   |                         |
   v                         v
[Show "Registration complete"]   [Show "Verification expired"]
   |                         |
   +-----------+-------------+
               |
               v
              ◉ (end)

Explanation of notation used:

• Initial node (●) starts the flow; activity final (◉) ends it.
• Decision node < Input valid? > (diamond) branches on a guard; an invalid input loops back, modelling re-entry.
• A fork (horizontal bar) splits the flow so that creating the inactive account and sending the verification email happen concurrently; a matching join synchronizes them before waiting for the click.
• A second decision node checks whether the user clicked the link in time, activating the account on success or expiring the pending account on timeout.
• Merge before the final node combines the alternative paths.

Singleton Design Pattern

Definition: Singleton is a creational design pattern that ensures a class has exactly one instance and provides a global point of access to that instance.

Why it is used:

• When exactly one object must coordinate actions across the system, e.g. a configuration manager, logging service, connection/thread pool, cache, or device driver.
• To provide controlled, global access to that single shared resource while preventing multiple conflicting instances.

Problems it can cause:

• Acts as a global state, introducing hidden dependencies and tight coupling that make code hard to unit-test and mock.
• Can hinder concurrency (needs thread-safe lazy initialization) and complicate dependency management; often considered an anti-pattern when overused. It also violates the Single Responsibility Principle (manages both its own lifecycle and its business logic).

Code skeleton (thread-safe lazy Singleton, Java-style):

public final class Singleton {
    // 1. Private static instance, lazily created
    private static volatile Singleton instance;

    // 2. Private constructor prevents external instantiation
    private Singleton() {
        // initialization
    }

    // 3. Global access point with double-checked locking
    public static Singleton getInstance() {
        if (instance == null) {                 // first check (no lock)
            synchronized (Singleton.class) {
                if (instance == null) {         // second check (with lock)
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

    public void doWork() { /* ... */ }
}

Key elements: a private constructor (so no one else can new it), a private static reference to the single instance, and a public static getInstance() that creates the instance once and returns the same object thereafter. (An even simpler thread-safe form initializes the field eagerly: private static final Singleton instance = new Singleton();.)

Short Notes (any two)

(a) Coupling and Cohesion

• Coupling is the degree of interdependence between modules/classes. Low (loose) coupling is desirable because modules can change independently, improving maintainability and reuse. High coupling makes one change ripple across many classes.
• Cohesion is the degree to which the elements within a single module belong together and serve a single, well-focused purpose. High cohesion is desirable (one class = one clear responsibility).
• Goal of good OO design: low coupling and high cohesion (supported by the GRASP principles).

(b) Polymorphism and Dynamic Binding

• Polymorphism ("many forms") lets a single interface/message produce different behaviour depending on the actual object type. Example: calling draw() on a Shape reference draws a circle or rectangle according to the real object.
• Dynamic (late) binding is the mechanism that makes run-time polymorphism work: the actual method to invoke is resolved at run time based on the object's true class, not at compile time (static binding). Overridden methods are dispatched via dynamic binding, enabling extensible, substitutable designs.

(c) Stereotypes in UML

• A stereotype is a UML extensibility mechanism that lets you define a new kind of model element based on an existing one, giving it specialized meaning. It is written in guillemets, e.g. «interface», «include», «extend», «entity», «boundary», «control».
• Stereotypes (along with tagged values and constraints) form UML profiles, allowing UML to be tailored to a particular domain or technology without changing the core metamodel.