INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

INDIVIDUAL ASSIGNMENT

TECHNOLOGY PARK MALAYSIA

CT070-3-3-DPAT

DESIGN PATTERN

SECTION 1: DESIGN REFINEMENTS

APU3F2308SE

NAME : LIM CONG YUE

STUDENT ID : TP063962

LECTURER : ASSOC. PROF. DR. MUHAMMAD

EHSAN RANA

HAND IN DATE : 20 DECEMBER 2023

Page 1 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

Abstract
The software industry's growth hinges on the adaptability and scalability of software
systems. This study delves into the critical aspect of software modifiability, investigating its
essence, significance, sub-attributes, and impact on design. The literature review surveys
existing studies, shedding light on how design principles and patterns influence Modifiability
and exploring measurement techniques.

Within this framework, a scenario is presented, complete with a descriptive overview

and a corresponding use case diagram. A simple solution, illustrated via a class diagram and
Java implementation devoid of design patterns, serves as a foundational point for analysis.

Subsequently, a refined solution is crafted, meticulously identifying flaws within the

initial approach. Appropriately selected design patterns are incorporated, driving the
refinement of the class diagram and the Java implementation.

This research contributes to comprehending the intricacies of software modifiability,

offering insights into its correlation with design principles and patterns. By elucidating
techniques for measuring Modifiability and presenting a progression from a basic to a refined
solution, this study aims to enhance our understanding and approach toward developing
adaptable and scalable software systems.

Page 2 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

Table of Contents
1.0 Introduction..........................................................................................................................7

2.0 Literature Review.................................................................................................................8

2.1 Software Modifiability.....................................................................................................8

2.2 Important of Modifiability in Software Systems.............................................................8

2.3 Modifiability sub-attributes............................................................................................10

2.4 How does Modifiability affect the software design?......................................................11

2.5 Impact of Design Principles on Modifiability................................................................11

2.6 Impact of Design Pattern on Modifiability....................................................................13

2.7 Techniques of Measuring Modifiability.........................................................................14

3.0 Scenario..............................................................................................................................15

3.1 Description.....................................................................................................................15

3.2 Use case Diagram...........................................................................................................16

4.0 Simple Solution..................................................................................................................18

4.1 Class Diagram................................................................................................................18

4.2 Java Implementation (without Design Patterns)............................................................19

4.2.1 Main Class...............................................................................................................19

4.2.2 Administrator Class.................................................................................................19

4.2.3 SmartDrinkMachine Class......................................................................................20

5.0 Refined Solution.................................................................................................................21

5.1 Identify problems in the Simple Solution......................................................................21

5.2 Identify appropriate Design Patterns..............................................................................22

5.3 Refined Solution.............................................................................................................23

5.3.1 Refined Class Diagram...........................................................................................23

Page 3 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

5.3.1.1 Abstract Factory...............................................................................................23

5.3.1.2 Template Method..............................................................................................24

5.3.2 Refined Java Implementation..................................................................................25

5.3.2.1 Abstract Factory...............................................................................................25

5.3.2.1.1 Main Class.................................................................................................25

5.3.2.1.2 Beverage Interface....................................................................................25

5.3.2.1.3 Tea Class...................................................................................................26

5.3.2.1.4 Coffee Class..............................................................................................26

5.3.2.1.5 AbstractBeverageFactory Class................................................................27

5.3.2.1.6 TeaFactory Class.......................................................................................27

5.3.2.1.7 CoffeeFactory Class..................................................................................27

5.3.2.1.8 Administrator Class...................................................................................28

5.3.2.1.9 SmartDrinkMachine Class........................................................................28

5.3.2.1.10 Customer Class........................................................................................29

5.3.2.2 Template Method..............................................................................................29

5.3.2.2.1 Main Class.................................................................................................29

5.3.2.2.2 BeveragePreparation Class........................................................................30

5.3.2.2.3 Coffee Class..............................................................................................30

5.3.2.2.4 Tea Class...................................................................................................31

5.3.2.2.5 SmartDrinkMachine Class........................................................................31

5.3.2.2.6 Administrator Class...................................................................................32

5.3.2.2.7 Customer Class..........................................................................................32

6.0 References..........................................................................................................................34

Page 4 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

Table of Figure
Figure 1 - SOLID Principle......................................................................................................10

Figure 2 - Adding New Beverage Categories Use case Diagram............................................15

Figure 3 – Simple Solution: Class Diagram.............................................................................17

Figure 4 - Main Class Implementation (without Design Patterns)..........................................18

Figure 5 - Administrator Class Implementation (without Design Patterns)............................18

Figure 6 - SmartDrinkMachine Class Implementation (without Design Patterns)..................19

Figure 7 - Refined Solution: Class Diagram by Abstract Factory...........................................22

Figure 8 - Refined Solution: Class Diagram by Template Method..........................................23

Figure 9 - Main Class Implementation (Abstract Factory)......................................................24

Figure 10 - Beverage Interface Implementation (Abstract Factory)........................................24

Figure 11 - Tea Class Implementation (Abstract Factory).......................................................25

Figure 12 - Coffee Class Implementation (Abstract Factory)..................................................25

Figure 13 - AbstractBeverageFactory Class Implementation (Abstract Factory)....................26

Figure 14 - TeaFactory Class Implementation (Abstract Factory)...........................................26

Figure 15 - Coffee Class Implementation (Abstract Factory)..................................................26

Figure 16 - Administrator Class Implementation (Abstract Factory)......................................27

Figure 17 - SmartDrinkMachine Class Implementation (Abstract Factory)............................27

Figure 18 - Customer Class Implementation (Abstract Method).............................................28

Figure 19 - Main Class Implementation (Template Method)...................................................28

Figure 20 - BeveragePreparation Class Implementation (Template Method)..........................29

Figure 21 - Coffee Class Implementation (Template Method)................................................29

Figure 22 - Tea Class Implementation (Template Method).....................................................30

Figure 23 - SmartDrinkMachine Class Implementation (Template Method)..........................30

Page 5 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

Figure 24 - Administrator Class Implementation (Template Method).....................................31

Figure 25 - Customer Class Implementation (Template Method)............................................31

Page 6 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

1.0 Introduction
In today's cutthroat business environment, delivering top-notch software to users is
crucial for any company aiming to survive and thrive amidst fierce market competition. The
pursuit of software excellence has deep roots in software engineering, with significant
contributions dating back to the late 1970s. One pivotal advancement in this pursuit is Barry
Boehm's quality model from 1978 (GeeksforGeeks, 2020). With its structured approach, this
model lays down the groundwork for evaluating software quality based on specific aspects,
setting a standard for software development practices.

Boehm's model pinpoints five core quality factors, each playing a vital role in
determining a software application's overall quality (GeeksforGeeks, 2020):

Reliability: These measures how dependable a system is in operating without glitches. It is all
about assessing the software's trustworthiness in ensuring smooth functionality.

Modifiability: It gauges how easily a software system can adapt to changes. This reflects the
software's ability to flexibly adjust to new requirements and market shifts (Bitew & Singh,
2019).

Testability: This factor focuses on how easily a software program can be thoroughly tested to
match specified requirements. It is crucial for identifying and fixing errors.

Efficiency: This evaluates how well software optimises resource usage like memory, CPU
time, and throughput. Efficiency is key in delivering a responsive and resource-savvy
solution.

Portability measures the effort required to move a software program from one environment to
another. It is vital in a world where adaptability across various platforms is increasingly
important.

Moreover, in pursuing top-notch software, studies have shown that design patterns
significantly elevate the quality of object-oriented software systems (Bitew & Singh, 2019).
Design patterns are battle-tested solutions to recurring design issues, offering a structured
way to develop software. As we explore software quality attributes, we will focus on one of
these aspects, delving into how design patterns can bolster its impact and contribute to
creating better software solutions (Bitew & Singh, 2019).

Page 7 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

2.0 Literature Review

2.1 Software Modifiability

Software modifiability pertains to the extent to which a software system can be

altered easily and swiftly without encountering issues or compromising the current level of
quality (Oquendo et al., 2016). The primary emphasis is on the expenses and duration needed
to implement alterations (Bellamkaddem, 2021). Modifiability is the quantity of elements
requiring modification (Oquendo et al., 2016).

Modifying the software involves making alterations, enhancements, or adjustments to

ensure compatibility with the new context, specifications, or updates in functional criteria
(Bengtsson et al., n.d.). In simple terms, the architectural quality of system modifiability
pertains to the amount of time and resources required to make changes to the system
(Modifiability by Example - António Rito Silva, 2015).

For example, for a system that controls indoor temperature, modifiability may mean
that you can easily make some changes, such as adding a temperature sensor to improve
accuracy, removing a broken sensor and replacing it with a new one, or even replacing the
Fahrenheit sensor with a Celsius sensor without affecting its function (Oquendo et al., 2016).

Software modifiability is a crucial quality attribute determining the difficulty level in

adapting a software system to changes (Bengtsson et al., n.d.). This, in turn, impacts the
system's overall life cycle cost.

2.2 Important of Modifiability in Software Systems

Modifiability is an essential attribute in software systems. This attribute also holds

significant importance in software systems.

Adaptability

Software adaptability holds significant importance in the dynamic realm of science and
technology. It signifies the ability to modify the software efficiently and promptly without
causing issues or diminishing its initial quality (Oquendo et al., 2016). Thus, the software can
adapt dynamically to evolving times and is not constrained by swift technological
advancements. Our ability to adapt allows us to promptly address emerging needs or
technological advancements, ensuring our competitiveness in the fiercely competitive market.

Page 8 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

Evolutionary Design

Modifiability refers to the capacity of a system to undergo gradual changes and

improvements over time, like its adaptability. Like how organisms undergo adaptation to their
environment, software systems can be gradually modified to address new demands or resolve
emerging issues. The adaptability of a software system allows it to meet changing
requirements effectively and efficiently over time, ensuring its continued usefulness
(Software Engineering: The Four Types of Modifiability | Ipl.org, n.d.).

Cost-Effective Maintenance

Throughout the entire life cycle of a software system, a substantial amount of funds is
allocated to enhance the software system (Bengtsson et al., n.d.). Modifiability is a crucial
factor that enhances the system's adaptability during development and allows it to handle
potential changes. This entails proactively preparing for different scenarios beforehand and
minimizing the financial impact of any alterations. This capability facilitates the system's
ability to adjust to changes in requirements, thereby reducing expenses and enhancing
efficiency and cost-effectiveness in software development (Bengtsson et al., n.d.).

Quality Improvement

Modification encompasses altering the function and enhancing various facets of system
quality (Bellamkaddem, 2021). For instance, they can enhance the system's speed, increase
its adaptability, and bolster its safety and dependability. Like enhancing a car, upgrading it
enhances its speed, fuel efficiency, and maneuverability. These modifications not only
enhance the system's capabilities but also enhance its flexibility in various scenarios and
improve its security and dependability (Bellamkaddem, 2021).

Error and Performance Issue Resolution

Occasionally, it may be necessary to modify the software to address issues not identified
during the testing phase or rectify performance deficiencies (Gomaa, 2011). It is akin to
performing the last refinements, ensuring that the software operates flawlessly, or optimizing
its performance for enhanced efficiency (Gomaa, 2011). These alterations enhance the
software's dependability, optimize its performance, and enhance the user experience.

In general, software systems' long-term success and sustainability are closely tied to the
crucial aspect of modifiability. It facilitates the system's ability to adapt to evolving

Page 9 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

requirements and surroundings, simplifies maintenance, and yields substantial long-term cost
savings. It is akin to incorporating a malleable framework within a dwelling, capable of being
modified as required, thereby reducing superfluous upkeep expenses, and enhancing the
longevity and comfort of the house. This also applies to software systems. Modifiability
enhances adaptability to changes, simplifies maintenance, and improves long-term cost-
effectiveness.

2.3 Modifiability sub-attributes

The quality attribute of modifiability encompasses sub-attributes such as correctness,

maintainability, reusability, and others. These sub-attributes precisely define the system's
performance and characteristics in certain areas.

Correctness

Correctness refers to the ability of software to perform its intended functions consistently and
correctly (Kitakabee, 2023). If the program functions are intended, it implies that it does not
need frequent modifications, indirectly improving its modifiability (Thales, n.d.). Like a well-
executed school assignment, if you approach it correctly from the outset, there is no need for
repetitive revisions. This also applies to software (Boye, 2017). Software operating flawlessly
from the outset requires less frequent modifications, enhancing its modifiability.

Maintainability

Maintainability pertains to simplicity and convenience in modifying the software system (The
SeaLights Software Metrics, n.d.). A simple system can be upgraded or changed efficiently,
directly impacting its modifiability (Henson, 2018). Like several automobiles that are simple
to fix and have easily replaceable components, they are also more straightforward to
maintain. This also applies to software systems. If the system is easily maintainable, updating
and modifying it will be more seamless, and later adjustments and enhancements to its
modifiability will be facilitated (Thales, n.d.).

Reusability

Reusability pertains to the capacity to use preexisting code while creating novel software
applications (Sakshi Pandey, 2022). This enables the use of the same code in other
applications, hence improving the software's capacity to be modified (Doglio, 2023). It
functions as a versatile tool for many home decoration tasks, eliminating the need to create a

Page 10 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

new tool for each job saving significant time and energy. This also applies to software. By
reusing the current code, developing new features may be expedited while enhancing the
software's flexibility for future modifications and modifiability (Bellairs, 2017).

2.4 How does Modifiability affect the software design?

Modifiability has a significant impact on software design and serves as an important

basis for decision-making. This happens, for example, when a modular structure is used to
make individual components easier to modify or replace (Oquendo et al., 2016). It is critical
to anticipate changes in user requirements, technological changes, and the system
environment to make system design modifications easier and more cost-effective (Bengtsson
et al., n.d.). Modifiability, on the other hand, can have an impact on other aspects of the
system, increasing flexibility but potentially increasing complexity (Bellamkaddem, 2021).
Modifiability facilitates updates, modifications, and improvements in system maintenance
and development, reducing maintenance time and costs (Modifiability by Example - António
Rito Silva, 2015). Modifiability designs, on the other hand, usually necessitate compromises
in other aspects of the design, such as increased initial development time and system
complexity (Gay, 2021).

2.5 Impact of Design Principles on Modifiability

Software Modifiability is a set of rules that guide developers in crafting robust

systems. Writing code accounts for only 20% to 40% of the development process; the rest
involves maintaining and understanding the existing codebase. Therefore, system design
plays a vital role (Lee, 2020). An effective system should possess a clean codebase that's easy
to understand, update, and scale as the system evolves. This can streamline development
time, cut costs, and boost team efficiency (Lee, 2020).

Figure 1 - SOLID Principle

The most important design principle is the SOLID principle, which is a principle
consisting of five basic design principles that can greatly impact the modifiability of a

Page 11 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

software system. These five principles are the Single Responsibility Principle
(Modifiabilityosed Principle (OCP), Liskov Substitution Principle (LSP), Interface
Segregation Principle (ISP), and Dependency Inversion Principle (DIP). In addition to the
most important SOLID principle, DRY(Do not Repeat Yourself), KISS (Keep it simple,
Stupid! ), and YAGNI (You are not going to need it). These principles are also part of the
design principles, but in this report, only the influence of the SOLID principle on
modifiability is studied.

Single Responsibility Principle (SRP)

Software design principle Single Modifiability Principle (SRP) states that every class,
module, and function in a program should serve a purpose. This principle helps design
maintainable, reusable, and flexible software (Vincent Abba, 2022). On modifiability, if a
class or module is responsible for multiple tasks, making changes to one modifiability
frequently impacts other parts and raises the likelihood of errors (CodeWithHonor, 2022).
Implementing the single responsibility principle (SRP) and assigning each function to a
separate class can enhance code comprehension (Vincent Abba, 2022). By assigning each
function its distinct class, the code becomes more lucid and comprehensible.

Open-Closed Principle (OCP)

The Open Closed Principle (OCP) is a software design principle that emphasizes the
importance of making software entities (such as classes, modules, etc.) easy to extend while
avoiding the need for frequent modifications (Bertrand Meyer, 1995). The key principle of
good object-oriented design is to reduce maintenance costs and improve product stability. The
Open-Closed Principle (OCP) has a beneficial effect on modifiability. By enabling the
extension of software entities without the need to modify their Modifiability effectively
minimizes the potential for introducing new errors into the system (Stack et al.). This is due
to the act of introducing the new code without making any modifications to the existing code.
OCP facilitates the seamless addition of new functionalities to the system, as it allows for the
incorporation of new code without the risk of compromising the integrity of the existing code
(Stack et al.).

Liskov Substitution Principle (LSP)

The Liskov substitution principle (LSP) is a fundamental principle within the SOLID
principles. The principal highlights that when there is a class and its subclasses, the program

Page 12 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

should avoid errors or produce unexpected outcomes, regardless of whether the program uses
objects from the subclasses or the parent class (Thorben, 2018). Subclasses can function as a
replacement for the parent class without causing any disruption to the program's regular
functioning. Changes to the base class will not impact the derived class code. The derived
class inherits the base class behavior and extends it. This minimizes the need to fix the code
after altering the base class and enhances the code's adaptability (Gamma, 1996).

Interface Segregation Principle (ISP)

The Interface Segregation Principle highlights the importance of avoiding unnecessary

dependencies between clients and interfaces. The objective is to improve the manageability
and adaptability of software by establishing smaller and more specialized interfaces (Fowler,
2006). The ISP mitigates the interdependence between classes by establishing concise
interfaces. Consequently, altering one class is improbable to have an impact on other classes,
thereby simplifying code modification (Kumar Malik, 2023).

Dependency Inversion Principle (DIP)

Dependency inversion involves prioritizing the use of interfaces or abstract entities over
concrete functions and classes in programming (Luca Cambi, 2023). The Dependency
Inversion Principle enhances the maintainability of software by impacting its modifiability.
Enhancing maintainability enables developers to modify the software with confidence.
Modifiability needs not to be concerned about disrupting the functionality of other system
components (Professional, 2018). This ultimately results in the creation of more stable and
easily manageable software.

2.6 Impact of Design Pattern on Modifiability

Design patterns are crucial for ensuring high-quality attributes. These templates are
utilized to attain precise quality objectives in system design (Carnegie Mellon University,
2018). These patterns serve as the foundation for constructing most systems and the
fundamental architectural patterns (Bass et al., n.d.). Although design patterns are
implemented in a system, they do not guarantee a high degree of modifiability of the code.
For example, certain classes that employ specific design patterns (such as adapters, monads,
and template methods) may be more error-prone than classes that do not employ these
patterns (Alfadel et al., 2020).

Page 13 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

There are several methods to enhance the modifiability of the system (Oquendo et al.,
2016). These methods offer a structured approach to modifying system parameters, thereby
enhancing the performance quality of the system in certain aspects. This implies that we can
modify the system in a more adaptable manner to fulfil the quality characteristics of
behaviours (Bachmann et al., 2007). Modifiability is related to cause and effect. The purpose
of architecture is to modify it to meet non-functional requirements, while the outcome is how
each modification affects other architectural elements. To clarify, system architecture changes
are made to meet criteria, and the results affect other system components (Oquendo et al.,
2016). This causal relationship can help us understand the causes and effects of system
changes.

In conclusion, modifiability is essential for the utilization and impact of design

patterns. When choosing and implementing design patterns, it is important to consider the
system's modifiability to guarantee that the software system is more manageable and capable
of adapting to alterations.

Existing studies mentioning the impact of design principles and patterns on Modifiability

Based on the twenty-three common design patterns presented in written by Gamma’s

book, design patterns play a key role in flexibility, reusability, and elegant modifiability
(Gamma & Addison-Wesley Publishing Company, 1998). Design patterns help designers
reuse successful designs and architectures based on previous experience.

According to written by Clement’s book, the key role of improving software

modifiability is emphasized. It introduces a method that can clearly record the software
structure so that developers can understand and improve the software more easily (Clements,
2011). This method is especially helpful for designing reusable object-oriented software.
Using design patterns can make the design more flexible, modular, reusable and easy to
understand.

These studies have analysed the impact of design patterns on software development
and demonstrated the key role of design patterns in improving software quality, maintainabil-
ity and adaptability. As a result, design patterns have become a valuable resource for software
design and development. Design patterns are an invaluable tool for providing developers with
solutions and proactively improving the flexibility and adaptability of software systems.

Page 14 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

2.7 Techniques of Measuring Modifiability

Modifiability is an important aspect of software design and architecture. There are various
techniques for measuring modifiability.

Modifiability scenarios: Describe how the system changes. The following factors are
considered when evaluating the response to these changes: the number, size, complexity, and
workload of the artefacts involved, the time to completion, the cost (direct or opportunity
cost), the impact of the change on other functional or quality attributes, and the number of
new problems that arise (Bass et al., 2013).

Modifiability Tactics: This approach manages the complexity of change to save time and
money. Strategies include reducing module size, increasing intra-module relevance, reducing
inter-module relevance, encapsulating functionality, maintaining semantic coherence, using
intermediaries, limiting dependencies, refactoring, using shared services, and deferring
change (Bass et al., 2013).

Task Complexity Model: The model uses Wood's Task Complexity Model, which provides
a general framework for the analysis. It describes aspects that affect maintenance tasks and
modifiability but does not consider the impact of each maintenance manager (He & Carver,
2009).

Maintainability Metrics: According to Boehm's model, modifiability is one of the main

characteristics of maintainability and can be assessed by looking at the class diagram
(Kiewkanya & Muenchaisri, 2011).

Page 15 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

3.0 Scenario
Adding New Beverage Categories: Responding To Market Changes

3.1 Description

When new flavours of beverages, such as flavoured teas, come onto the market, smart drink
machine manufacturers may take this into account. This makes adding new tea varieties to
the machine very simple. This demonstrates the adaptability of the machine's design to
quickly add new beverage options without major changes to the system.

3.2 Use case Diagram

Figure 2 - Adding New Beverage Categories Use case Diagram

Page 16 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

Page 17 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

Administrator

 Add New Beverage Category:

The Administrator can add new beverage categories to the Smart Drink Machine in
response to market changes.
 Update Beverage Information
The Administrator can update information about existing beverage categories (such as
name, description, price) in the Smart Drink Machine.
 Remove Beverage Category
The Administrator can remove a beverage category from the Smart Drink Machine if
it's no longer available or relevant.
 View Available Beverage Category
The Administrator can view the list of available beverage categories in the Smart
Drink Machine.
 Monitor Machine Status
The Administrator can monitor the status of the Smart Drink Machine, including its
operational status, inventory levels, and maintenance needs.
 Perform Maintenance
The Administrator can initiate maintenance tasks on the Smart Drink Machine when
necessary.

Smart Drink Machine

 Prepare Beverage:
The Smart Drink Machine can prepare a beverage selected by the Administrator or
customer.
 Customer Interaction:
Customers can interact with the Smart Drink Machine to select and purchase
beverages.

Page 18 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

4.0 Simple Solution

4.1 Class Diagram

Figure 3 – Simple Solution: Class Diagram

This is a system for managing beverage supply and distribution. The administrator
oversees managing the different types of drinks as well as maintaining the intelligent
beverage machine, whereas the intelligent beverage machine oversees making drinks and
interacting with customers. The customer is the last to receive the drink. The goal of this
system is to automate the entire process. Customers obtain drinks by interacting with the
machines, while administrators oversee ensuring that the machines have enough inventory
and that they are updated and well maintained.

Page 19 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

4.2 Java Implementation (without Design Patterns)

4.2.1 Main Class

Figure 4 - Main Class Implementation (without Design Patterns)

The Main class is a simple simulation of the administrator's interaction with the
intelligent beverage machine. It should be noted that this code is only used as an example and
serves no purpose other than to display messages on the console. In practice, these methods
will use practical logic to manage the types of drinks and customer interactions.

4.2.2 Administrator Class

Figure 5 - Administrator Class Implementation (without Design Patterns)

The Administrator class seems to be a part of a larger system for managing beverage
options and the operational status of a smart drink machine, providing administrative controls

Page 20 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

like adding or removing beverage options, updating information, monitoring the machine,
and performing maintenance tasks.

4.2.3 SmartDrinkMachine Class

Figure 6 - SmartDrinkMachine Class Implementation (without Design Patterns)

SmartDrinkMachine class mainly deals with the operation of the beverage dispenser,
which can prepare beverages according to the choice and interact with customers. The
concept of user interface or interaction is provided in the code, but how these methods realize
the function is not explained in detail.

Page 21 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

5.0 Refined Solution

5.1 Identify problems in the Simple Solution

a) Lack of Interaction:
The Administrator and SmartDrinkMachine classes aren't communicating with each
other. In a real situation, the administrator typically guides or gives instructions to the
machine, but in this setup, they're working separately without much interaction.
b) Single Responsibility Violation:
The Administrator class appears to manage both administrative tasks and machine
monitoring. This goes against the Single Responsibility Principle, which recommends
that a class should focus on handling only one type of responsibility or task. This way,
if changes are needed, they are isolated to a single area rather than affecting multiple
functionalities within the class.
c) Maintenance Ambiguity
The performMaintenance method is not clear about the available maintenance actions
or how they should be conducted. There is a lack of specific information on what
tasks can be performed during maintenance or the steps involved in executing them.

Page 22 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

5.2 Identify appropriate Design Patterns

a) Abstract Factory
The Abstract Factory is an object-oriented programming design pattern. It offers an
interface for generating groupings of related items without explicitly mentioning their
exact kinds. This enables for the creation of object families that function together
without being bound by their implementations (Freeman & Robson, 2014). It is like a
blueprint for creating various sorts of items without needing to know what those
objects are.
This pattern separates the implementation of a collection of objects from how they are
frequently utilised (Freeman & Robson, 2014). It is dependent on the use of methods
in a factory interface to construct objects. Using this pattern allows you to switch
between multiple specialised implementations of objects without having to change the
code that uses them, even while the programme is running. However, like with other
design patterns, employing this one may make the code more complex and take more
work when first developing it.
b) Template Method
The Template Method is like a blueprint used in object-oriented programming. It lays
out the main structure of how something should be done in a method but leaves some
specific parts to be filled in by different subgroups later (Gamma et al., 1994).
Lots of folks in framework development use this pattern to dodge repeating chunks of
code. It's like a flexible recipe that lets different groups tweak bits of how things get
done without messing up the plan (Gamma et al., 1994). But like with anything fancy,
using it might make things a tad more tangled at the start, needing more work to set
up.

Page 23 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

5.3 Refined Solution

5.3.1 Refined Class Diagram

5.3.1.1 Abstract Factory

Figure 7 - Refined Solution: Class Diagram by Abstract Factory

The class diagram demonstrates how the Abstract Factory pattern decouples the
creation of beverage objects from the customer code (SmartDrinkMachine), allowing the
system to easily add new beverage types in the future without modifying existing classes.

Page 24 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

5.3.1.2 Template Method

Figure 8 - Refined Solution: Class Diagram by Template Method

Based on this class diagram, SmartDrinkMachine can use the template method pattern
to handle the preparation of various beverages while keeping the structure of the preparation
steps consistent.

Page 25 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

5.3.2 Refined Java Implementation

5.3.2.1 Abstract Factory

5.3.2.1.1 Main Class

Figure 9 - Main Class Implementation (Abstract Factory)

This implementation follows the class diagram structure to manage different beverage
types, their creation, and serving through a machine, adhering to a design pattern for
flexibility and extensibility.

5.3.2.1.2 Beverage Interface

Figure 10 - Beverage Interface Implementation (Abstract Factory)

This interface fosters a clear separation of concerns, allowing for easy extensibility by
adding new beverage types while maintaining a uniform way to interact with and manipulate
beverages within the system.

Page 26 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

5.3.2.1.3 Tea Class

Figure 11 - Tea Class Implementation (Abstract Factory)

This Tea class demonstrates adherence to the contract specified by the Beverage
interface, outlining behaviours specific to serving tea while indicating the need for further
definition regarding the tasting functionality for tea instances.

5.3.2.1.4 Coffee Class

Figure 12 - Coffee Class Implementation (Abstract Factory)

The Coffee class demonstrates conformity to the contract specified by the Beverage
interface, outlining behaviours specific to serving coffee while signalling the necessity for
additional definition regarding the tasting functionality for coffee instances.

Page 27 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

5.3.2.1.5 AbstractBeverageFactory Class

Figure 13 - AbstractBeverageFactory Class Implementation (Abstract Factory)

The AbstractBeverageFactory interface sets the blueprint for factories responsible for
creating beverages in a way that allows for different implementations to produce specific
types of beverages, contributing to the flexibility and maintainability of the system by
abstracting the creation process.

5.3.2.1.6 TeaFactory Class

Figure 14 - TeaFactory Class Implementation (Abstract Factory)

The TeaFactory class demonstrates the Factory Method pattern within the Abstract
Factory design, providing a specialized factory for creating Tea instances while maintaining
conformity with the broader factory interface structure.

5.3.2.1.7 CoffeeFactory Class

Figure 15 - Coffee Class Implementation (Abstract Factory)

The CoffeeFactory class demonstrates the Factory Method pattern within the Abstract
Factory design paradigm, providing a specialized factory for creating Coffee instances while
maintaining conformity with the broader factory interface structure.

Page 28 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

5.3.2.1.8 Administrator Class

Figure 16 - Administrator Class Implementation (Abstract Factory)

The Administrator class acts as a control centre for administrative tasks, providing a
set of functionalities to oversee and manage the beverage system, ensuring its functionality
and adaptability to changes in beverage offerings or machine maintenance needs.

5.3.2.1.9 SmartDrinkMachine Class

Figure 17 - SmartDrinkMachine Class Implementation (Abstract Factory)

Page 29 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

The SmartDrinkMachine class acts as an abstraction layer responsible for preparing

beverages by leveraging an abstract factory, offering a flexible and scalable solution within a
beverage-serving system.

5.3.2.1.10 Customer Class

Figure 18 - Customer Class Implementation (Abstract Method)

The Customer class is more of a starting point or a placeholder, awaiting further

implementation or extension to define the specific behaviours and attributes relevant to
customers within the context of the application or system being developed.

5.3.2.2 Template Method

5.3.2.2.1 Main Class

Figure 19 - Main Class Implementation (Template Method)

The code involves a smart drink machine capable of preparing drinks, an

administrator responsible for monitoring and maintenance, and the preparation of drinks
within the machine utilizing coffee type. The code sequence demonstrates the functionality of
the machine from setup to serving drinks.

Page 30 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

5.3.2.2.2 BeveragePreparation Class

Figure 20 - BeveragePreparation Class Implementation (Template Method)

This abstract class sets a framework for preparing beverages, allowing different types
of beverages (e.g., coffee, tea) to implement their specific steps of brewing, pouring, and
adding condiments while following a predefined sequence outlined in the prepareBeverage()
template method.

5.3.2.2.3 Coffee Class

Figure 21 - Coffee Class Implementation (Template Method)

The Coffee class customizes the steps outlined in the BeveragePreparation abstract
class to specifically cater to the process of preparing coffee, offering a concrete
implementation for each step required in making a cup of coffee. This design adheres to the

Page 31 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

template method pattern, providing a structured way to prepare different types of beverages
while allowing each beverage type to define its specific preparation steps.

5.3.2.2.4 Tea Class

Figure 22 - Tea Class Implementation (Template Method)

Like the Coffee class, the Tea class customizes the steps defined in the
BeveragePreparation abstract class to specifically cater to the process of preparing tea. This
follows the template method pattern, providing a structured way to prepare different types of
beverages by allowing each beverage type to define its specific preparation steps while
sharing a common preparation framework.

5.3.2.2.5 SmartDrinkMachine Class

Figure 23 - SmartDrinkMachine Class Implementation (Template Method)

Page 32 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

This class encapsulates the functionality of a smart drink machine that can be
configured with different beverage preparation strategies and perform the preparation process
based on the selected strategy, allowing for flexibility and reusability of beverage preparation
logic.

5.3.2.2.6 Administrator Class

Figure 24 - Administrator Class Implementation (Template Method)

The Administrator class provides a structure to manage and perform administrative

actions on the beverage categories and interact with specific drink machines. However, it
currently lacks the detailed logic for handling these actions beyond displaying simple
messages. The next step would involve implementing the actual functionality within these
methods to enable effective administration of the drink machine system.

5.3.2.2.7 Customer Class

Figure 25 - Customer Class Implementation (Template Method)

Page 33 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

The Customer class is more of a starting point or a placeholder, awaiting further

implementation or extension to define the specific behaviours and attributes relevant to
customers within the context of the application or system being developed.

Page 34 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

6.0 References
Alfadel, M., Aljasser, K., & Alshayeb, M. (2020). Empirical study of the relationship between
design patterns and code smells. PLOS ONE, 15(4), e0231731.
https://doi.org/10.1371/journal.pone.0231731

Bachmann, F., Bass, L., & Nord, R. (2007, September 1). Modifiability Tactics.
Figshare.com. https://figshare.com/articles/report/Modifiability_Tactics/6575696/1

Bass, L., Clements, P., & Kazman, R. (2013). Software Architecture in Practice (3rd ed.).
Addison-Wesley.

Bass, L., Klein, M., & Bachmann, F. (n.d.). Quality Attribute Design Primitives and the
Attribute Driven Design Method 1. Retrieved December 14, 2023, from
https://insights.sei.cmu.edu/documents/184/2001_019_001_29612.pdf

Bellairs, R. (2017, July 7). What Is Code Reuse? Code Reuse Best Practices. Perforce
Software. https://www.perforce.com/blog/qac/what-code-reuse-code-reuse-best-
practices

Bellamkaddem, A. (2021, July 28). Introduction to Software Architecture — Quality

Attributes Requirements (Part 2). Geek Culture.
https://medium.com/geekculture/introduction-to-software-architecture-quality-
attributes-requirements-part-2-7d22eab57e58

Bengtsson, P., Lassing, N., Bosch, J., & Van Vliet, H. (n.d.). Analyzing Software
Architectures for Modifiability. Retrieved December 12, 2023, from
https://www.janbosch.com/Articles/SAAModifiability.pdf

Bertrand Meyer. (1995). Object-oriented software construction. New York Prentice Hall.

Bitew, N., & Singh, J. (2019). A Study on Software Quality Factors and Metrics to Enhance
Software Quality Assurance. International Journal of Productivity and Quality
Management, 1(1), 1. https://doi.org/10.1504/ijpqm.2019.10025496

Boye, A. (2017). How Do I Create Meaningful and Effective Assignments? | TLPDC

Teaching Resources | Teaching Resources | TLPDC Home | TTU. Ttu.edu.
https://www.depts.ttu.edu/tlpdc/Resources/Teaching_resources/TLPDC_teaching_reso
urces/CreatingEffectiveAssignments.php

Page 35 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

Carnegie Mellon University. (2018, February 13). Reasoning About Software Quality
Attributes. Insights.sei.cmu.edu. https://insights.sei.cmu.edu/library/reasoning-about-
software-quality-attributes/

Clements, P. (2011). Documenting software architectures : views and beyond. Addison-

Wesley.

CodeWithHonor. (2022, December 22). Single Responsibility Principle. Medium.

https://medium.com/@CodeWithHonor/single-responsibility-principle-7f9875f1bef3

Doglio, F. (2023, June 6). Building With Components: Unleashing the Power of Clean Code
and Maintainability. Medium. https://blog.bitsrc.io/why-building-with-components-
is-the-best-way-to-ensure-clean-code-aa840b31c03d

Fowler, M. (2006, December 22). bliki: RoleInterface. Martinfowler.com.

https://martinfowler.com/bliki/RoleInterface.html

Freeman, E., & Robson, E. (2014). Headfirst design patterns : a brain-friendly guide.
O’reilly, Edition: 10Th Anniversary Ed.

Gamma, E. (1996). Entwurfsmuster : Elemente wiederverwendbarer objektorientierter

Software. Addison-Wesley.

Gamma, E., & Addison-Wesley Publishing Company. (1998). Design patterns CD : elements
of reusable object-oriented software. Addison-Wesley.

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design patterns : elements of
reusable object-oriented software. Addison-Wesley.

Gay, G. (2021). Lecture 2: Quality Attributes and Measurement.

https://greg4cr.github.io/courses/spring21dit635/Lectures/Spring21-Lecture2-
QualityMetrics.pdf

GeeksforGeeks. (2020, July 4). Boehm’s Software Quality Model. GeeksforGeeks.

https://www.geeksforgeeks.org/boehms-software-quality-model/

Gomaa, H. (2011). Software Quality Attributes. Cambridge University Press EBooks, 357–
368. https://doi.org/10.1017/cbo9780511779183.022

He, L., & Carver, J. C. (2009). Modifiability measurement from a task complexity
perspective: A feasibility study. https://doi.org/10.1109/esem.2009.5316023

Page 36 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

Henson, M. (2018, March 16). 17 Essential Steps In The Software Upgrade Process.
ELearning Industry. https://elearningindustry.com/software-upgrade-process-
essential-steps

Hombergs, T. (2020, February 26). Single Responsibility Principle Unpacked.

Reflectoring.io. https://reflectoring.io/single-responsibility-principle/

Kiewkanya, M., & Muenchaisri, P. (2011). Constructing Modifiability Metrics by

Considering Different Relationships. Special Issue) Chiang Mai J. Sci, 38, 82–98.
https://www.thaiscience.info/journals/Article/CMJS/10905409.pdf

Kitakabee. (2023, May 2). 15 Techniques to Improve Software Quality. BrowserStack.

https://www.browserstack.com/guide/how-to-improve-software-quality

Kumar Malik, S. (2023, August 9). Interface Segregation Principle in Software Design.
Www.linkedin.com. https://www.linkedin.com/pulse/interface-segregation-principle-
software-design-sanjoy-kumar-malik/

Lee, P. (2020, June 19). Software Design Principles Every Programmer Should Know.
Medium. https://medium.com/@peterlee2068/software-design-principles-every-
programmer-should-know-c164a83c6f87

Luca Cambi. (2023, December 5). System Design: Dependency Inversion Principle.
Baeldung. https://www.baeldung.com/cs/dip

Modifiability by example - António Rito Silva. (2015, November 29).

https://antonioritosilva.org/software-engineering-companion/software-architecture/
modifiability-by-example/

Oquendo, F., Leite, J., & BatistaT. (2016). Designing Modifiability in Software Architectures.
Undergraduate Topics in Computer Science, 127–141. https://doi.org/10.1007/978-3-
319-44339-3_9

Professional, D. (2018, April 18). SOLID violations in the wild: The Dependency-Inversion
Principle. Devonblog. https://www.devonblog.com/software-development/solid-
violations-in-the-wild-the-dependency-inversion-principle/

Sakshi Pandey. (2022, October 3). Importance Of Code Reusability In Software Development.
BrowserStack. https://www.browserstack.com/guide/importance-of-code-reusability

Page 37 of 38
INDIVIDUAL ASSIGNMENT CT070-3-3-DPAT

Software Engineering: The Four Types Of Modifiability | ipl.org. (n.d.). Www.ipl.org.

Retrieved December 12, 2023, from https://www.ipl.org/essay/The-Importance-Of-
Modifiability-In-Software-Engineering-PCY752EPU

Stack Overflow. (n.d.). What is the meaning and reasoning behind the Open/Closed
Principle? Stack Overflow. Retrieved December 14, 2023, from
https://stackoverflow.com/questions/59016/what-is-the-meaning-and-reasoning-
behind-the-open-closed-principle

Thales. (n.d.). The 4 Types of Software Maintenance-What is Software Maintenance.

Cpl.thalesgroup.com. https://cpl.thalesgroup.com/software-monetization/four-types-
of-software-maintenance

The SeaLights Software Metrics. (n.d.). Software Maintainability: What it Means to Build
Maintainable Software. Sealights. https://www.sealights.io/software-quality/software-
maintainability-what-it-means-to-build-maintainable-software/

Thorben. (2018, December 17). SOLID Design Principles Explained: The Liskov Substitution
Principle with Code Examples. Stackify. https://stackify.com/solid-design-liskov-
substitution-principle/

Vincent Abba, I. (2022, April 26). SOLID Definition – the SOLID Principles of Object-
Oriented Design Explained. FreeCodeCamp.org.
https://www.freecodecamp.org/news/solid-principles-single-responsibility-principle-
explained/

Page 38 of 38