CT070-3-3-DPAT
APD3F2411SE
INDIVIDUAL ASSIGNMENT
TECHNOLOGY PARK MALAYSIA
CT070-3-3-DPAT
Design Patterns
HAND OUT DATE: 24 January 2025
HAND IN DATE:
30 March 2025
WEIGHTAGE:
40%
INSTRUCTIONS TO CANDIDATES:
1
Submit your assignment at the administrative counter
2
Students are advised to underpin their answers with the use of
references (cited using the APA System of Referencing)
3
Late submission will be awarded zero (0) unless Extenuating Circumstances (EC)
are upheld
4
Cases of plagiarism will be penalized
5
The assignment should be bound appropriately (comb bound or stapled).
6
Where the assignment should be submitted in both hardcopy and softcopy, the
softcopy of the written assignment and source code (where appropriate) should be
on a CD in an envelope / CD cover and attached to the hardcopy.s
Name: TAN YANN SHAW
TP_Number: TP063396
Intake Code: APD3F2411SE
CT070-3-3-DPAT
APD3F2411SE
Table of Contents
Design and Implementation for Simple Solution....................................................................... 3
Design and implementation with Observer Pattern ................................................................... 6
Design and implementation with State Pattern ........................................................................ 10
Measuring Techniques ............................................................................................................. 14
Analysis of results .................................................................................................................... 15
CT070-3-3-DPAT
APD3F2411SE
Design and Implementation for Simple Solution
The initial design of the bus booking system showcases a straightforward and procedural
approach to managing bus seat bookings without using any design patterns. The system
provides very basic functions such as booking seat, viewing seat availability and manage seat
status.
UML Class Diagram
Figure 1 – Simple Solution Class Diagram
Implementation details
The implementation comprises a single “SimpleBusBookingSystem” class that encapsulates
all the functions. The functions include booking a seat, viewing seat availability, and getting
the total seats available on the bus.
CT070-3-3-DPAT
APD3F2411SE
Figure 2 – Simple solution java implementation
Design Characteristics
1. Simple State Representation
•
Uses a Boolean array to track seat status
•
false indicates an available seat
•
true indicates a booked seat
2. Basic Error Handling
•
The system performs validity checks on seat numbers
•
Prevents double booking of seats
•
Provides console-based feedback messages
3. Direct Implementation
•
No separation of concerns
CT070-3-3-DPAT
APD3F2411SE
•
Single responsibility for all booking operations
•
Monolithic class structure
Reliability Considerations
The initial design provides basic reliability through:
1. Input Validation
•
Checks for invalid seat numbers that are out of range
•
Validates if a seat is already booked before attempting to book it again
2. Operation Feedback
•
Returns Boolean values to indicate success or failure of operations
•
Provides console messages for error conditions
3. State Management
•
Uses a simple Boolean array to maintain consistent seat state
•
Direct access to state information
The initial implementation, “SimpleBusBookingSystem” is a basic functional approach to
booking seats. However, this approach lacks advanced reliability features, which would only
serve as our baseline for comparison when we implement design patterns to enhance the
reliability of the system.
In the following sections below, we will implement two appropriate design patterns to
specifically enhance and improve the reliability of the bus booking system and conduct
empirical evaluations to measure the impact of the patterns.
CT070-3-3-DPAT
APD3F2411SE
Design and implementation with Observer Pattern
In this design, I’ve implemented the observer pattern to enhance reliability for the bus
booking system. The observer pattern will establish a one-to-many dependency between
objects. When an object changes its state, all its dependencies will be notified and updated.
Observer pattern implementation
Design rationale
The observer pattern has been chosen to improve the reliability of the bus booking system
through:
1. Decoupled Notification System: Which helps separate core booking logic from
notification mechanisms
2. Consistent State Updates: Helps to ensure all observers are informed of state changes
3. Validation and Error Tracking: Provides mechanisms to track notification failures
4. Extensible Monitoring – Which allows easy addition of new monitoring and logging
components
CT070-3-3-DPAT
APD3F2411SE
UML Class Diagram (Observer Pattern)
Figure 3 –
The Class diagram in Figure 3 shows the refined design with the observer pattern
implementation. These details include the subject interface, which defines the observer
management methods, the observer interface for components that need to be notified of
changes, “BusBookingSystem” as the concrete subject, and Booking Logger as a concrete
observer.
CT070-3-3-DPAT
APD3F2411SE
Java Implementation (Observer Pattern)
Figure 4 – subject Interface
Figure 4 showcases the “Subject interface” defines the methods required for managing
observers. It includes methods to register, remove, and notify observers when a seat’s status
changes.
Figure 5 – Observer Interface
Figure 5 showcases the “Observer interface” is implemented by components that need to be
notified of seat status changes. It includes an “update()” method that receives notifications
and a “validateNotification()” method to check if the notification was successful.
CT070-3-3-DPAT
APD3F2411SE
Figure 6- BookingLogger
Figure 6 showcases the” BookingLogger” class implements the “Observer” interface and
serves as a logging mechanism for seat booking events. It keeps track of notifications and
potential failures, ensuring a record of seat bookings and releases.
Summary
The Observer Pattern is used to establish a one-to-many dependency between objects, where
a change in one object triggers updates in its dependent objects. This implementation
demonstrates a seat booking system that notifies observers when a seat’s status changes.
CT070-3-3-DPAT
APD3F2411SE
Design and implementation with State Pattern
In this design, I have implemented the State Pattern into the bus booking system. The “State
Design Pattern” allows an object to alter its behavior when its internal state changes. This
pattern is particularly useful for bus booking systems. This is due to it enabling a seat to
exhibit different behaviors based on its current booking status.
State Pattern Design Implementation
Design Rationale
1. Ensuring that seat operations are always consistent with the current state
2. Preventing invalid state transitions (e.g., canceling a seat that isn't booked)
3. Localizing state-specific behavior in dedicated classes for better error containment
4. Providing clear state-dependent behavior without complex conditional logic
CT070-3-3-DPAT
APD3F2411SE
UML Class Diagram (State Pattern)
Figure 7 – State Pattern Class Diagram
The UML Class Diagram in Figure 7 represents a Bus Booking system using the State
Pattern, which allows dynamic state transitions for booking and cancelling seats. The
“StateBusBookingSystem” class manages multiple Seat objects and provides methods to
book, cancel, and check seat availability without directly handling state transitions. Each Seat
maintains a reference to a “SeatState”, which defines the behavior for booking and
cancellation. The “SeatState” interface is implemented by two concrete states:
“AvailableState” and “BookedState”. The design in the diagram encapsulates state-specific
behavior inside a class to make the system more modular, maintainable and extensible
CT070-3-3-DPAT
APD3F2411SE
Java Implementation (State Pattern)
Figure 8 – SeatState interface
Figure 8 depicts the “SeatState” interface that defines the contract for different seat states. It
includes methods for booking, canceling, and retrieving the seat status.
Figure 9 – BookedState class
Figure 9 depicts a “BookedState” class that represents a seat that has already been booked.
Attempting to book an already booked seat will result in a message indicating that the seat is
not available. However, the seat can be canceled, transitioning it back to an AvailableState.
CT070-3-3-DPAT
APD3F2411SE
Figure 10 – Available state
Figure 10 depicts the “AvailableState” class represents a seat that is available for booking.
Once a booking is made, the seat transitions to a “BookedState”. Attempting to cancel an
available seat is not allowed.
Summary
This implementation effectively demonstrates the State Pattern by allowing a seat to
transition between Available and Booked states dynamically. The pattern helps encapsulate
state-specific behavior and ensures that seat actions are handled appropriately depending on
its current state.
CT070-3-3-DPAT
APD3F2411SE
Measuring Techniques
Mean Time to Failure (MTTF)
Mean Time to Failure (MTTF) is a key metric used to measure the reliability of a system by
assessing how long an operation operates before encountering a failure (Understanding Mean
Time to Failure for Measuring Reliability | Atlassian, n.d.). This metric is useful when
evaluating systems that are expected to perform a set of tasks over time without any
interruptions.
𝑴𝑻𝑻𝑭 =
𝑻𝒐𝒕𝒂𝒍 𝑺𝒖𝒄𝒆𝒔𝒔𝒇𝒖𝒍 𝒐𝒑𝒆𝒓𝒂𝒕𝒊𝒐𝒏𝒔 𝒃𝒆𝒇𝒐𝒓𝒆 𝒇𝒊𝒓𝒔𝒕 𝒇𝒂𝒊𝒍𝒖𝒓𝒆
𝑻𝒐𝒕𝒂𝒍 𝒕𝒆𝒔𝒕 𝒓𝒖𝒏𝒔
Success-Failure Rate Analysis
This method for measuring reliability is based on calculation success and failure rates across
different design patterns. This measurement method evaluates how often the system
successfully processes bookings and considers additional factors like observer notification
failure and state transitions.
The Reliability Scores are calculated as follows:
Simple System: Reliability is based on percentage of successful operations out of total
operations
𝑅𝑒𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡𝑦 𝑆𝑐𝑜𝑟𝑒 = (
𝑆𝑢𝑐𝑒𝑠𝑠𝑓𝑢𝑙 𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑜𝑛𝑠
) 𝑋 100
𝑇𝑜𝑡𝑎𝑙 𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑜𝑛
Observer System: Reliability accounts for observer notification failures, measuring how
consistently notifications are delivered.
𝑂𝑏𝑠𝑒𝑟𝑣𝑒𝑟 𝑅𝑒𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡𝑦 𝑆𝑐𝑜𝑟𝑒 = (1 −
𝑂𝑏𝑠𝑒𝑟𝑣𝑒𝑟 𝑁𝑜𝑡𝑖𝑓𝑖𝑐𝑎𝑡𝑖𝑜𝑛 𝐹𝑎𝑖𝑙𝑢𝑟𝑒𝑠
) 𝑋 100
𝑇𝑜𝑡𝑎𝑙 𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑜𝑛
State System: Reliability considers invalid state transitions, reflecting how well the system
prevents incorrect state changes.
CT070-3-3-DPAT
APD3F2411SE
Analysis of results
To evaluate the effectiveness of design pattern-based solutions in terms of reliability, we
should compare their performance based on empirical evidence from observed results. To
accurately compare the effectiveness of each booking system, we collect data from
simulations of 100 booking attempts for each system. Below are figures that show the
empirical evidence collected.
Figure 11 – Reliability Test (Simple solution)
Figure 1 Demonstrates a code that attempts to book a random seat. If the seat is taken, the
operation fails because the system does not allow double booking. Each seat is stored in a
basic array or list, and once a seat is marked as booked, subsequent attempts to book the same
seat will be rejected.
CT070-3-3-DPAT
APD3F2411SE
Figure 12 – Reliability Test (Observer Pattern)
Figure 12 Introduces an observer pattern to track bookings. However, a small probability of
observer notification failure is included. This means that while the core functionality remains
the same as the Simple System, additional errors might arise when notifying external
components (e.g., logging systems or monitoring tools).
CT070-3-3-DPAT
APD3F2411SE
Figure 13 – Reliability Test (State Pattern)
Figure 13 uses a state pattern to regulate seat bookings. This approach ensures that
operations are only executed if they are in the correct state, preventing many forms of
booking errors. While this reduces failure rates, it introduces potential invalid state transitions
when unexpected behaviours occur, such as attempting to book a seat that has already been
confirmed.
CT070-3-3-DPAT
APD3F2411SE
Metric
Simple Solution
Observer Pattern
State Pattern
Total Operations
100
100
100
Successful
10(10%)
10(10%)
100(100%)
Not available
1
Not available
Failed Bookings
90(90%)
90(90%)
0(0%)
Invalid Transitions
0
0
7(7%)
Reliability Score
10%
99%
93%
Bookings
Observer Failed
notification
Table 1 – Reliability Metrics Table
The Observer System and Simple System have the same success rate (10%), but the Observer
System provides additional reliability by notifying external components. Despite one
observer failure, it still maintains high reliability (99%). The State System, while preventing
failures, introduces a 7% invalid state transition rate, slightly lowering its reliability score
(93%) compared to the Observer System. This comparison highlights the trade-offs in system
design between simplicity, notification mechanisms, and strict state management.
CT070-3-3-DPAT
Conclusion
APD3F2411SE
CT070-3-3-DPAT
APD3F2411SE