---
title: "KUKL customer system design and code"
subject: "Object Oriented Analysis and Design"
chapter: 4
key: "semester_6/object_oriented_analysis_and_design:kukl-use-case-class-diagram-code"
source: https://www.bctengineer.com/q/semester_6/object_oriented_analysis_and_design/kukl-use-case-class-diagram-code
site: BCT Engineering
---

# KUKL customer system design and code

Object Oriented Analysis and Design · Chapter 4: Implementation

- Asked in: 2071 Magh, 13 marks
- Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_6/object_oriented_analysis_and_design/kukl-use-case-class-diagram-code
- Whole chapter: https://www.bctengineer.com/md/semester_6/object_oriented_analysis_and_design/chapter-4

## Question

Kathmandu Upatyaka Khane Pani Limited (KUKL) has hired you as a system analyst of an online customer management system and payment system. The system keeps track of all the customers and the payment they make for the service provided. The system has the option for electronic payment. Analyze and prepare the use case and design class diagram for the system. Map the design into code.

## Short answer

Use case diagram: Customer, Staff, Admin, Payment Gateway actors; Register Connection, View Bill, Pay Bill (extended by Pay Electronically) etc. Class diagram: Customer–Bill 1–*, Bill–Payment 1–*, with CashPayment/ElectronicPayment subclasses. Code uses collections for associations and polymorphic payment processing.

## Answer

**Assumptions:** customers are registered with a connection; bills are generated monthly from meter readings; payment is made either in cash at the counter or electronically (card/e-wallet). Actors: Customer, Cashier/Staff, Admin, Payment Gateway (external).

#### Use case diagram

```text
              +------------------------------+
              |   KUKL Customer Management   |
 [Customer] --|-( Register Connection )      |
 [Customer] --|-( View Bill )                |
 [Customer] --|-( Pay Bill )                 |
              |      ^ <<extend>>            |
              |      |                       |
              |  ( Pay Electronically )------|--[Payment Gateway]
 [Customer] --|-( View Payment History )     |
 [Staff] -----|-( Record Meter Reading )     |
 [Staff] -----|-( Generate Bill )            |
 [Staff] -----|-( Accept Cash Payment )      |
 [Admin] -----|-( Manage Customers )         |
 [Admin] -----|-( Generate Reports )         |
              +------------------------------+
```
`Pay Bill` is extended by `Pay Electronically` (an optional choice of payment mode). All customer use cases `<<include>>` a `Login` use case, which is left out of the diagram for clarity.

#### Design class diagram

```text
 +---------------+ 1    * +----------------+
 | Customer      |--------|     Bill       |
 |---------------| gets   |----------------|
 | -id: int      |        | -billNo: int   |
 | -name: String |        | -month: String |
 | -address      |        | -units: double |
 | -connectionNo |        | -amount: double|
 |---------------|        | -paid: boolean |
 | +getBills()   |        |----------------|
 | +makePayment( |        | +calculate()   |
 |   bill, mode) |        +----------------+
 +---------------+               | 1
                                 | *
                      +------------------+
                      |    Payment       |
                      |------------------|
                      | -amount: double  |
                      | -date: Date      |
                      |------------------|
                      | +process()       |
                      +------------------+
                           ^         ^
                 CashPayment    ElectronicPayment
                                 -transactionId
                                 +process()
```

#### Mapping to code (Java)

```java
import java.util.*;

class Customer {
    private int id;
    private String name, address, connectionNo;
    private List<Bill> bills = new ArrayList<>();       // 1 - *
    public Customer(int id, String name, String addr, String conn) {
        this.id = id; this.name = name; this.address = addr; this.connectionNo = conn;
    }
    public void addBill(Bill b) { bills.add(b); }
    public List<Bill> getBills() { return bills; }
    public void makePayment(Bill bill, Payment p) { bill.addPayment(p); }
}

class Bill {
    private int billNo; private String month;
    private double units, amount; private boolean paid;
    private List<Payment> payments = new ArrayList<>(); // 1 - *
    public Bill(int no, String month, double units) {
        this.billNo = no; this.month = month; this.units = units;
        this.amount = calculate();
    }
    public double calculate() { return units * 25.0; }  // assumed rate per unit
    public void addPayment(Payment p) {
        p.process();
        payments.add(p);
        double paidSum = 0;
        for (Payment x : payments) paidSum += x.getAmount();
        paid = paidSum >= amount;
    }
    public boolean isPaid() { return paid; }
}

abstract class Payment {
    protected double amount; protected Date date = new Date();
    public Payment(double amount) { this.amount = amount; }
    public double getAmount() { return amount; }
    public abstract void process();
}

class CashPayment extends Payment {
    public CashPayment(double a) { super(a); }
    public void process() { System.out.println("Cash received: " + amount); }
}

class ElectronicPayment extends Payment {
    private String transactionId;
    public ElectronicPayment(double a, String tid) { super(a); transactionId = tid; }
    public void process() { System.out.println("E-payment " + transactionId + ": " + amount); }
}

public class KuklApp {
    public static void main(String[] args) {
        Customer c = new Customer(1, "Hari", "Patan", "C-101");
        Bill b = new Bill(1001, "Baisakh", 20);
        c.addBill(b);
        c.makePayment(b, new ElectronicPayment(500, "TX77"));
        System.out.println("Paid: " + b.isPaid());
    }
}
```
The one-to-many associations (multiplicity 1 to `*`) became `List` fields; generalization became `extends`; and the abstract `Payment.process()` is overridden in each subclass (polymorphism). The payment mode in `makePayment(bill, mode)` is represented by passing a `CashPayment` or `ElectronicPayment` object.

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. In the KUKL use case diagram, how is electronic payment related to Pay Bill?
   A. It extends Pay Bill as an optional choice of payment mode
   B. It replaces Login
   C. It is an actor
   D. It is a class attribute
   Answer: A. Pay Bill is extended by Pay Electronically, an optional payment mode, and the Payment Gateway is the external actor. (Key point: Extend relationship)

2. How is the 1-to-many association between Customer and Bill mapped to code?
   A. A single Bill field in Customer
   B. A List<Bill> field in Customer
   C. A Customer field in a static method
   D. An integer count only
   Answer: B. The 'many' side is held as a collection, so Customer has List<Bill> bills. (Key point: Multiplicity to collection)

3. How are CashPayment and ElectronicPayment related to Payment in the code?
   A. They are interfaces implemented by Payment
   B. They extend the abstract Payment class and override process()
   C. They contain Payment as a list
   D. They are unrelated
   Answer: B. Generalisation maps to extends, and the abstract process() is overridden in each subclass (polymorphism). (Key point: Generalization and polymorphism)

4. How does the code decide a Bill is paid?
   A. When any single payment is added
   B. When the sum of its payments is at least the bill amount
   C. When the customer logs in
   D. When units are greater than zero
   Answer: B. addPayment sums all payments and sets paid = paidSum >= amount. (Key point: Paid status)

## Related in Object Oriented Analysis and Design

- [Bus service use cases with elaboration](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Agre-bus-service-use-cases) — Object Oriented Analysis and Design, chapter 2
- [Event management system summary and class diagram](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Aoems-executive-summary-class-diagram) — Object Oriented Analysis and Design, chapter 2
- [Explain online order sequence diagram](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Aorder-processing-sequence-diagram-explain) — Object Oriented Analysis and Design, chapter 2
- [Development process and mapping design to code](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Adevelopment-process-map-design-code) — Object Oriented Analysis and Design, chapter 4
- [Rental car system candidate objects](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Arental-car-system-candidate-objects) — Object Oriented Analysis and Design, chapter 2
- [Map sequence diagram to pseudo code](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Aorder-model-mapping-pseudocode) — Object Oriented Analysis and Design, chapter 4

## Related in other subjects

- [CRM plan for online shop](https://www.bctengineer.com/question.md?key=semester_8%2Finformation_system%3Acrm-online-shop-plan) — Information System, chapter 3
- [SQL: customers with account in Dharan](https://www.bctengineer.com/question.md?key=semester_6%2Fdatabase_management_system%3Asql-customers-dharan-branch) — Database Management System, chapter 3
- [Doubly linked list: bank customer records](https://www.bctengineer.com/question.md?key=semester_4%2Fdata_structure_and_algorithm%3Adoubly-bank-customer) — Data Structure and Algorithm, chapter 4
- [Contracts by payment: lump sum and cost plus](https://www.bctengineer.com/question.md?key=semester_8%2Fconstruction_management%3Alump-sum-cost-plus) — Construction Management, chapter 5
