1
Design Patterns – Individual Assignment
Full Name: Felix Elbert Lawin
TP No: TP045308
Abstract — This individual assignment report aims to
justify and implement, as well as prove that the effective use of
the Façade and Singleton design patterns leads to better
working software and ultimately enhances the Testability
quality attribute of a software by first introducing a scenario,
implementing a non-design pattern solution, then onwards
introducing a solution with design patterns embedded and
analyzing the software’s code to draw a comparison between
the two solutions. First off, an introduction to explain about the
Testability Factor will be given, next, several research and
studies related to Testability will be drawn up to gather the
reader’s attention on current achievements made in the field.
Moving on, a suitable methodology to measure and gauge the
solutions’ testability will be conducted and will be later
debriefed. A case scenario where two forms of implementation:
simple and refined will be given where the former has design
patterns absent while the latter has them present. The later
section will compare these two solutions and evaluate the
effectiveness of design patterns onto software. Finally, a
conclusion on what has been discovered will be placed at the
end of this document.
I. INTRODUCTION
This report aims to outline the importance of Testability
from Jim McCall’s Software Quality Model as well as
incorporating it into a solution though implementing the
effective use of Software Design patterns that further adds
input to an already existing rich body of knowledge. The
term Testability defined by IEEE Standard Glossary of
Software Engineering Terminology [1] is: 1) degree to which
a system or component facilitates the establishment of test
criteria and the performance of tests to determine whether
those criteria have been met. (2) The degree to which a
requirement is stated in terms that permit establishment of
test criteria and the performance of tests to determine
whether those criteria have been met.
Meanwhile, the same term in McCall’s Software Quality
Model refers to how adaptable the software is in newer
environments, and how resistant it should be in terms of
being tested again over and over again to ensure that the
software does not fail, as well as the completed software
meeting its original requirements thus working as intended. It
is placed under the pillar of Software Revision along with
two other pillars which are Software Transition and
Operation. In this report, Testability for software will be
demonstrated with and proven on with the use of two design
patterns known as Y and X, as well as the method for
empirical value of testability being presented and calculated.
The following contents of this report will first immerse
the reader with an extensive literature review showcasing
contributions towards Testability from different sources and
their applicability towards different respects of software in
general, then moving on to represent a methodology used to
calculate an empirical value for Testability. This
methodology will then be further reflected in the next section
where a scenario is constructed, then a simple solution (SS)
is brought forth by implementing it first without the use of
Quality Factor: Testability
Email: TP045308@mail.apu.edu.my
effective Design Patterns, and its weaknesses thoroughly
explained. Whereas only later a refined solution (RS) would
come in and a solution to the design flaws in the SS would be
highlighted on and scrutinized, then compared against the
RS.
Finally, a conclusion that closes this report will be written
to provide a summary of what has been achieved and what
the outcome of the report is.
II. LITERATURE REVIEW
Over the years, numerous studies and research have been
conducted when it comes to comprehending the importance
of Design Patterns towards Testability. The vast amount of
research conducted has otherwise led to a period where
software is more robust and testable as ever, meeting
stakeholder requirements and being able to execute with
minimal chance of failure or breakdown.
A. Designs for Testability
In a study aimed to identify and formulate solutions towards
common occurrences and caveats that are present in
software design for its testability, Jungmayr [2] has
formulated a list of items present in Object Oriented
Software Development that might pose problems in testing
to occur upon compilation, then proceeding to highlight
several comprehensive solutions that can either solve or
mitigate the shortcomings he mentioned. Such examples of
problems hindering software testability primarily focus on
Object Dependencies – which is to say that Class A depends
on Class B to execute a method that triggers it, such as
classes being hard-wired to each other (a class is considered
as hard wired if it cannot be substituted by another class
during testing), high coupling and cyclic dependencies
(classes cannot be tested in isolation and hence must be
broken down). While as the solutions highlighted involved
usage of Design Patterns, refined methods to call functions
without other classes being affected and solutions that can
lead to loose coupling.
To further relate and contribute to this aspect of testability
on coming up with ways to improve testability in software
and programs in general, another study conducted by
Pettichord [3] who has over a decade of experience in
automating test cases has brought forward his own
suggestions as well on how to design testability for software.
The study has claimed that methods such as Logging
specific events that are considered crucial, employing
diagnostics tools through assertions which are lines of code
that if violated, return a negative result indicating that a bug
has occurred, as well as fault injections that relate to testing
a software’s robustness in an irregular or a not standard
manner that may introduce newer errors to fix and verify.
Furthermore, the study has also stressed the importance of
Visibility in software testing – that is to ensure that
developers are able to observe outputs, side effects and

internal states of the software under testing circumstances by
simply having enough access privileges towards the source
code of the program. The contributions of the studies above
had otherwise pitched in wonderful methods on improving
testability as a whole in software.
B. Testability Models and frameworks for Verification
One of the earliest forms of studies conducted on Software
Testability is researched for in the year 1995. A published
study [4] introduced a new approach towards measuring
design for Testability through a different perspective
through a program’s dynamic aspects instead of its syntax.
These new approaches involve not testing the program as a
whole as it could take too much time and iterations,
moreover, identifying which areas of the program are most
prone to software faults and failures. To prove this, a new
devised method called “Sensitivity Analysis” was
constructed. Sensitivity Analysis works by injecting faulty
code into a program, then estimating the chance of failure on
that code segment injected through observation. Several
other forms of Testability Analysis brought forward by the
authors includes Execution Analysis where the program is
repeatedly executed with different inputs, and Infection
Analysis, where a piece of syntactically legal code is
inserted onto a segment of the program to measure whether
the data input type is changed upon testing.
Though software testability in general is crucial towards
deploying robust products that will satisfy requirements and
stakeholders, testability in re-usable software components is
also as important. In component-based systems, reusable
components are essential as they are often re integrated in
and repurposed for other software fit for different means.
With defects in any re-usable components that fail for
testability, it would mean a disastrous result for validation
costs and overall re-testing and validation for such software
that should be ready from the get-go. Another study
emphasizing on this aspect of software testability [5] aims to
address how software testability could be further improved
by designing highly testable components and systems, as
well as analyzing how to control testability aspects of
components and systems across a software’s life cycle. The
results of this study have produced a model that is based on
five factors of software components which are: Document
availability, Document readability, Document testability,
Requirements’ measurability, and Component usability, then
aims to further refine these attributes by providing practical
and measurable detailed factors towards existing ones.
Moving on, as software testing is usually being performed
on systems that are already complete, a study [6] has
showcased and constructed measurement guidelines
theoretical measurement framework for software testability
focused on the early stages of its development, showing that
if software testing is conducted during the analysis and
design phases, it would be much more efficient on
improving testability before implementation of the software
itself. This is done by coming up with several hypotheses,
2
identifying their relationships and analyzing what impact
they might have on software.
Another study [7] that has proposed a framework to define
software metrics for software dependencies has been
brought forward, citing that testing needs to be focused on
parts of a system that critical for test complexity. This is
done by finding out reduction metrics in order to give
evaluation of the impact that a particular dependency has
towards software qualities. Whereas the results could show
that if the dependency is removed, testability could improve.
The results of this study have shown that throughout four
separate test cases, it has been shown that even a small
number of dependencies could largely influence a program’s
testability.
C. Testability of Software Components
Although the study above has shown scrutinizing the aspect
through introducing new perspectives as well as changing
how the test for testability works, another study conducted
by Freedman [8] shows that testability could be measured
through a new concept, a technique defined as Domain
Testing that applies existing computing concepts which are
observability which refers to measuring if specified inputs
affects outputs, while controllability refers to the ease of
producing selected or targeted outputs based on inputs. The
study of discussion aims to prove that programs built out of
domain-testable specifications are much quicker and more
efficient to build than programs that are not. Their research
has borne fruit whereas they have found out that building
programs based on domain-testable specifications is 27%
faster than non-domain-testable specifications. Thus, from
this result, it has been shown that producing domain-testable
software leads towards less redundant test cases meaning
less testing required to perform for programs, thus clearing
the way for easier testability.
D. Usage of Design Patterns for Software Testability
Measuring testability feasibility in Object-Oriented software
designs where control flows are primarily not hierarchical
and distributed across the whole working program itself, is
as important as analyzing any other program. A conducted
study [9] has suggested working improvements towards
programs that are built in such a way where they are prone
to be too complex at a global level due to a multitude of
classes involved that makes severe use of polymorphism by
employing two design patterns: Abstract Factory Pattern and
State Pattern. The result of this study shows that risks
associated with testing as well as problem occurrences can
be avoided through effective usage of the two methods
pitched by said study.
E. Testability Analysis
With respect towards OO-designed programs, their testing
however does not only focus onto the software itself, but far
beyond that. A study published [10] has took a deeper dive

onto examining testability analysis for UML Class Diagrams
which serves to represent software in a high-level fashion.
The study in question aims to address potential testing
weaknesses that can be found in UML Class Diagrams of
Software, where the most prominent factor is called “class
interaction” which is defined in their study as
client/customer interactions between classes. This factor will
then be measured based on how many polymorphic uses
causes these class interactions and a model will be produced
to capture and pinpoint classes mainly responsible for class
interactions that occur within a UML Class Diagram. The
model produced from this contribution is named as a class
dependency graph, which its main features are to detect,
count and evaluates maximum complexity of class
interactions.
Another study [11] that deals with respect to analysis in
testability has highlighted three main factors that are
considered towards analyzing testability which are: test
costs, sensitivity, and testable characteristics of a program.
Their research has found out through a plotted table
populated with analysis methods that testability methods for
object-oriented software has gotten more traction than
structural software over the past years and has claimed that
current trends are shifting more towards OO-based software,
whereas testability analysis for integration testing is an area
that the study claims more research should be poured into.
Out of all these research that has proven to improve
Testability in Software, this conducted study aims to do the
same through the implementation of effective Design
Patterns which are the Singleton and Façade pattern. Details
about these respective design patterns will be revealed later
on in this document. This resear
III. METHODOLOGY
The methodology to be employed when measuring
Testability of a program will refer to a formula originating
from SPAWAR System Center Pacific [12]. The formula is
showcased as follows:
It is mentioned that Testability would be deemed high and
sustainable whenever there exists a suitable degree of
controllability. A program’s ability to uncover faults as well
as being able to observe states and behavior of the program
are desirable characteristics to achieve high testability. The
formula above shows Testability being calculated by
considering Modularity, Cyclomatic Complexity as well as
Dead/Duplicate Code. An indication shown in this formula is
that the lower the value of T denotes better Testability for the
Software.
To highlight other terms, Cyclomatic Complexity (Vg) refers
to the number of taken paths or decisions necessary to
exercise all branches or sections of the software, whereas a
higher Vg count leads to the code being more complex [13].
To explain further, a program that has no control flows will
have a Vg of 1, where was if a program has a single if
statement, it would have a Vg value of 2 as there are 2 paths
that highlight true and false, respectively. The formula for
Cyclomatic Complexity is shown as follows:
The formula also highlights another variable present in the
calculation which shows Duplicate/Dead Code. Duplicate
2
code refers to code that is similar or copy pasted, thus posing
a maintainability risk, and leading to erratic behavior. It also
prevents the chance for reusability in the software. Whereas
dead code highlights code that is never utilized or used at all,
including methods and variables. Having too much dead
code in a program will often lead to bugs and difficulty in
understanding the general program.
To further break down the general formula, the
Modularity of the program is also considered and explained
in detail. Whereas the formula for Modularity is as follows:
In the formula above, modularity is calculated by considering
the number of modules present in the program (Classes) as
well as the module size that highlights the number of lines
present in the code. A software is described as modular when
modules inside of it are independent and collaborative, and
organizable into a software architecture. Having the software
being modular allows for better testability result as smaller
and less complex modules accounts for better results.
To achieve calculations by applying the formula above, an
open-source evaluation tool named SonarQube will be
utilized to calculate for program testability. SonarQube is a
free open-source tool that helps users identify and analyze
their code, analyze code quality and providing room for
better refinements. Steps and guide on how to install and
utilize SonarQube in order to measure code efficiency and to
evaluate other performance metrics such as Testability,
Portability, Maintainability, etc. will be visible in the
Appendix section of this document.
This formula, along with the testing tool for Empirical
Evaluation will be further discussed and entailed in chapter
VII of this document.
IV. CASE SCENARIO
Northland Bank is an esteemed banking company with
branches existing across Malaysia. They have been in
operation since the early 2000s and have garnered over 20
million concurrent users where approximately 500,000
interested users are based in Malaysia. The Bank is seeking
to open its services in Malaysia through implementing a
special interface for their ATMs to fit the Malaysian
population. In order to counter this issue, although a simple
solution has been implemented in place. However, upon
doing so, they have realized that there are a few breaches in
its system whereas data vulnerability and accessibility
concerns have appeared in its system, as well as times
whereas there could be more than one instance of a bank
interface appearing in the system as reported by customers,
thus leading to some ATMs that Northland Bank has
requiring severe maintenance or even a total reset to ensure
that functions return to normal. This leads the Northland
Bank development team to implement a furthermore refined
solution through the implementation of design patterns to
solve the current ongoing issues,
V. SIMPLE SOLUTION
A. Simple Solution - UML based Design
A simple solution of the ATM program is provided and
visible in the Appendix labelled as Appendix A. The class
diagram entails 4 main classes, whereas the BankDemo class
represents the Main Class that will run when customers start

up the ATM for the first time. Meanwhile, the BankMenu
class will be used to display a main interface for the
customer, BankSecurity will be used for processes related to
payment authorizations and user info verification, while
BankAccount will be used to house user actions inside the
class.
B. Simple Solution – Java Based Implementation
Appendix C shows the Java Based Implementation of the
simple solution.
C. Simple Solution – Design Issues
Upon careful inspection of the simple solution provided,
there appears to be numerous issues surrounding the code.
a) Coupling and Complexity Issues
High coupling is seen among classes in this part of the class
Diagram whereas in the code, the BankAccount class would
require to call on the BankSecurity class to utilize its
verifyTransfer() method as seen in the figure below.
Furthermore, although there are little classes seen in the
whole part of the system, the classes are highly coupled as
some classes know too much about other classes.
2
An example is proven here as the BankMenu class has
access to almost every component of the BankSecurity class
as it can directly manipulate variables that are present in an
object instantiation of the BankSecurity class. This is caused
due to the fact that variables in the BankSecurity class have
no implemented proper access restrictions. High coupling
has impact on modularity and is not good for overall
software Testability as if the number of modules and more
features gets added into the bank and adopts this kind of
practice, there will be problems that the developers will face
in trying to find which method invokes which class and so
on.
Cohesion, Coupling, Modularity Concerns, Accessibility
Concerns, Multiple Instance, Complexity Concerns.
b) Possibility of Multiple Instantiations
As the software is to be implemented into a piece of
hardware that is the ATM itself, there might be a possibility
of more than one BankMenu object being instantiated by the
user intentionally or unintentionally through the use of
excessive input or responses. This creates further confusion
and concerns in software Testability as this will render the
overall software less testable as it is prone to errors.
c) Accessibility Concerns
Furthermore, other weaknesses in the simple solution are
detected in the improper use of access modifiers. In the
below code example, it is seen that a part of the code does
not hide its variables from other classes. This could lead to
poor obscurity practices and can let instantiations of other
classes gain too much data/visibility on the class itself.
To illustrate, the BankAccount.java class has all funds and
targetFunds variables set as public. Although this does not
really affect the current solution as the module being shown
is only a simple ATM machine, further refinements made to
the overall software would prove difficult as incorrect access
modifiers leading to poor modularity will allow accidental
changes to a part of a Class being made, or high potential
towards poor data security practices that could eventually
lead to breaches that will incur losses to the bank.
VI. REFINED SOLUTION
A. Solution to the Design Issues
After applying refinements towards the original simple
solution, Northland Bank has come up with a more
sophisticated form of development and programming that
entails the use of design patterns in order to solve the issue.
a) Façade

In order to counteract the possibility of ever-growing
libraries or modules that the bank system will further adopt
in the future, a Façade design pattern is implemented as a
solution to provide an intuitive and simple interface, hiding
the implementation of complex processes behind the scenes.
It is best used when interlinking a number of methods at
once and group them into a single Façade class that serves
as the main point of interaction. Implementing a façade
solves the problem of tight coupling and minimizes
dependencies between classes [14]. A simple façade solution
is enough to tackle the complexity and coupling problems
that the current system has by creating a new Façade class,
and decoupling all subclasses that depend on each other,
then interlink them to the one façade class. With this,
regardless on how complex future subclasses will be added
later on to the overall program, the program will remain
testable through the implementation of a façade as less time
and effort is taken in order to test a simplified interface. The
implementation of a Façade pattern also reinforces the
Single Responsibility Principle – that is to denote that every
module of a program’s contents should hold one sole
responsibility over its functionality.
b) Singleton
In order to combat the testability problem that is when
multiple ATM programs are instantiated at once thus
causing errors, a singleton design pattern is adopted. This
design pattern involves generating an instance of the class at
first upon execution, then preventing other instances of the
same class from ever being initialized. This design pattern
will work in tandem with the Façade pattern, as a façade
class could be further transformed into a singleton class by
implementing a single method, which is getInstance() as
shown below.
The Singleton design pattern is also further implemented by
creating an instance variable of the Class, then changing its
default constructor by giving it a private access modifier
[25]
2
The above code denotes that whenever the program fires, an
instance of the BankFacadeSingleton class is initialized.
Further “starts” of the program is not allowed as the
singleton design pattern blocks them from ever initializing,
securing the bank interface to only one per customer,
preventing unnecessary inputs by customers.
With the combination of these 2 design patterns, Façade and
Singleton, this solves most of Northland Bank’s security
concerns.
B. Refined Solution - UML based Design
The Refined solution that was implemented towards the
bank’s current existing problems are represented with a
UML Class Diagram in Appendix B. As seen, there is
one extra class that is named BankFacadeSingleton. This
class is responsible for providing the functionalities and
benefits of both design patterns at once in a class.
C. Refined Solution – Java Based Implementation
The refined solution’s Java Based Implementation is
provided in Appendix D. Upon closer inspection, an extra
class named BackFacadeSingleton will be implemented to
achieve the implementation of 2 design patterns, which are
Façade and Singleton to achieve Testability.
VII. EMPIRICAL EVALUATION
In this section, you are required to present detailed results
based on the evaluation of design pattern based solutions and
their equivalent simple solutions (i.e., solutions without using
design patterns) so as to quantify which of them is more
suitable towards improving the selected quality attribute.
You are required to provide the empirical evidence to
support the claims of improved quality factor when applying
design patterns.
A. Quality Factor Measurement
8. Apply the measuring technique/tool and calculate
value of your Quality Factor for both Simple Solution and
Refined Solution. The measurements and evaluation
processes should be clearly shown with complete steps.
The measuring tool used in this document is known as
SonarQube, which its steps to install, setup and run the
program and implementing its use towards the simple and
refined solutions will be shown in the Appendix section of E
and F in this document. Tutorials on how to run the simple
B. Analysis
Based on the previously mentioned formula in the
beginning sections, a lower score for the value T indicates
better Testability of the Software in general.
The results of both solutions are shown as of below:
a) Simple Solution:
Modularity:
The Modularity for the Simple Solution is shown to be 76.
While through SonarQube’s analysis, the Cyclomatic
Complexity of the code is shown to be 30.

There are no duplicated lines/dead code present in the
simple solution provided.
From the general formula for Testability Provided.
Testability for the Simple Solution is 50.
b) Refined Solution
For the refined solution, as the Façade class acts as an
interface that controls all methods that are there in other
classes which remain untouched, only the Façade and Main
class will be counted along inside of the formula.
Modularity:
The Modularity for the Refined Solution is shown to be 42.
While as Cyclomatic Complexity for the BankInterface
package that houses the main class and Façade+Singleton
pattern shows to be 16.
Furthermore, no duplications nor dead code are found in the
Refined Solution.
Based on the above formula, the Testability for the Refined
Solution is shown to be 27.4
It is shown that this value of 27.4 for the Refined solution
carrier a lower weightage than the T value of the Simple
Solution, which is shown to be 50. This proves that by
applying Design Patterns Façade and Singleton, Testability
is further improved in the Refined Solution.
VIII. CONCLUSION
In conclusion, it is shown that applying and effectively
utilizing design patterns assists in producing better quality
software metrics and conclusions when measuring for
software factors such as Testability and many others. It
should be noted that further improvements towards this case
study could be achieved should more modules and
functionalities for Northland Bank’s software be added such
as other classes that entails other functions to fully test for
Testability of the whole system. Furthermore, as the bank
system has a lot of if else or switch cases, cyclomatic
2
complexity will be always placed at a high value, thus
leading to challenges in automating the software for testing.
REFERENCES
[1] "IEEE Standard Glossary of Software Engineering
Terminology." Available:
10.1109/ieeestd.1990.101064 [Accessed 15 May
2021].
[2] S. Jungmayr, "Design for Testability", CONQUEST,
2008. Available: 10.1.1.72.6895 [Accessed 14 May
2021].
[3] B. Pettichord, "Design for Testability", 2002. [Accessed
16 May 2021].
[4] J. Voas and K. Miller, "Software testability: the new
verification", IEEE Software, vol. 12, no. 3, pp. 17-28,
1995. Available: 10.1109/52.382180 [Accessed 15
May 2021].
[5] J. Gao and M. Shih, "A Component Testability Model
for Verification and Measurement", 29th Annual
International Computer Software and Applications
Conference (COMPSAC'05), 2005. Available:
10.1109/compsac.2005.17 [Accessed 15 May 2021].
[6] S. Mouchawrab, L. Briand and Y. Labiche, "A
measurement framework for object-oriented software
testability", Information and Software Technology, vol.
47, no. 15, pp. 979-997, 2005. Available:
10.1016/j.infsof.2005.09.003 [Accessed 15 May
2021].
[7] S. Jungmayr, "Testability Measurement and Software
Dependencies", ISWM, 2003. [Accessed 16 May
2021].
[8] R. Freedman, "Testability of software
components", IEEE Transactions on Software
Engineering, vol. 17, no. 6, pp. 553-564, 1991.
Available: 10.1109/32.87281 [Accessed 15 May
2021].
[9] B. Baudry, Y. Le Traon, G. Sunyé and J. Jézéquel,
"Towards a ’safe’ use of design patterns to improve oo
software testability", HAL, 2013. [Accessed 16 May
2021].
[10] B Baudry and Y. Traon, "Measuring design testability
of a UML class diagram", Information and Software
Technology, vol. 47, no. 13, pp. 859-879, 2005.
Available: 10.1016/j.infsof.2005.01.006 [Accessed 16
May 2021].
[11] F. Jianping, L. Bin and L. Minyan, "Present and future
of software testability analysis", 2010 International
Conference on Computer Application and System
 2
Modeling (ICCASM 2010), 2010. Available: %20advantages%20of%20the%20facade,the
10.1109/iccasm.2010.5622622 [Accessed 16 May %20principle%20of%20loose%20coupling.
2021]. [Accessed: 25-May-2021].

[12] C. Johnson, "Establishing Quantitative Software

[15] SourceMaking, “Design Patterns and Refactoring,”
Metrics in Department of the Navy Programs", 2016.
SourceMaking. [Online]. Available:
Available: 10.21236/ad1008159 [Accessed 18 May
2021]. https://sourcemaking.com/design_patterns/singleto
n. [Accessed: 25-May-2021].
[13] S. Fricker, "What exactly is cyclomatic complexity? •
froglogic", froglogic, 2021. [Online]. Available:
https://www.froglogic.com/blog/tip-of-the-week/what-
is-cyclomatic-complexity/. [Accessed: 19- May-
2021].

[14] IONOS, “Facade pattern: unified interface for software

projects,” IONOS Digitalguide. [Online]. Available:
https://www.ionos.com/digitalguide/websites/web-
development/whats-the-facade-pattern/#:~:text=The

IX. APPENDIX

A. UML Class Diagram – Simple Solution

2
 2

B. UML Class Diagram – Refined Solution

 2

C. Simple Solution – Java Implementation

BankDemo.java

public class BankDemo {

public static void main(String[] args) throws Exception {

try{
BankMenu bankMenu = new BankMenu();
bankMenu.displayLogin();
}catch(Exception e){
e.printStackTrace();
}

BankMenu.java

import java.util.Scanner;

public class BankMenu {

public int acctNum;
public int acctCode;
public int choice;

Scanner bankScanner = new Scanner(System.in);

BankAccount bacc = new BankAccount();

public void displayLogin() throws Exception{

try {
System.out.println("Welcome to Northland Bank");
System.out.println("Please enter your account number");
acctNum = bankScanner.nextInt();
System.out.println("Please enter your 6-digit security code");
acctCode = bankScanner.nextInt();

BankSecurity bs = new BankSecurity();

bs.acctNum = acctNum;
bs.secCode = acctCode;

if(bs.acctExists(acctNum) && bs.secCodeConfirm(acctCode)){

displayChoice();
}
}catch(Exception e){
e.printStackTrace();
System.exit(0);
}
}

public void displayChoice(){

while(true){
System.out.println("==========================");
 2
System.out.println("1 - Deposit Cash");
System.out.println("2 - Withdraw Cash");
System.out.println("3 - Funds Transfer");
System.out.println("4 - Check Funds");
System.out.println("5 - Exit");
System.out.println("==========================");
System.out.println("Selection : ");
choice = bankScanner.nextInt();
int choice = getChoice();

if(choice == 1){
bacc.makeDeposit();
displayChoice();
}

if(choice == 2){
bacc.makeWithdrawal();
displayChoice();
}

if(choice == 3){
bacc.makeTransfer();
displayChoice();
}

if(choice == 4){
bacc.makeBalanceCheck();
displayChoice();
}

if(choice > 4)
System.out.println("Thank you for using Northland Bank");
break;
}
}

public int getAcctNum() {

return acctNum;
}

public int getAcctCode() {

return acctCode;
}

public int getChoice(){

return choice;
}

}
 2

BankAccount.java

import java.util.Scanner;

public class BankAccount {

public double funds = 0;

public double targetFunds = 0;
public int targetAccount;
Scanner accScanner = new Scanner(System.in);

public void makeDeposit(){

System.out.println("Please enter deposit value");
targetFunds = accScanner.nextDouble();
if(targetFunds > 50)
funds += targetFunds;
System.out.println("Funds successfully added.");
System.out.println("Your new balance is now: MYR " + funds);
}

public void makeWithdrawal(){

System.out.println("Enter withdrawal amount");
targetFunds = accScanner.nextDouble();
if(funds < targetFunds)
System.out.println("You do not have enough balance to make this
withdrawal.");
else {
funds -= targetFunds;
System.out.println("MYR" + targetFunds + " has been withdrawn from your
account.");
System.out.println("Your new balance is now: MYR " + funds);
}
}

public void makeTransfer(){

System.out.println("Please enter recipient account number.");
targetAccount = accScanner.nextInt();
System.out.println("Please enter transfer amount to this account number.");
targetFunds = accScanner.nextDouble();
if(verifyTransfer(targetFunds, funds)) {
funds -= targetFunds;
System.out.println("Transfer of MYR" + targetFunds + " to account " +
targetAccount + " is completed.");
System.out.println("Your new balance is now : MYR " + funds);
}else{
System.out.println("You do not have enough funds to make this
transaction.");
}
}

public void makeBalanceCheck(){

System.out.println("Your balance is : MYR " + funds);
}

public boolean verifyTransfer(double transferFunds, double funds){

 2
return BankSecurity.verifyTransfer(transferFunds, funds);
}

BankSecurity.java

public class BankSecurity {

public int secCode;

public int acctNum;

public boolean acctExists(int acctNum){

return acctNum == getAcctNum();
}

public boolean secCodeConfirm(int secCode){

return secCode == getSecCode();
}

public void setAcctNum(int acctnum){

this.acctNum = acctnum;
}

public void setSecCode(int secCode){

this.secCode = secCode;
}

public int getSecCode(){return secCode;}

public int getAcctNum(){return acctNum;}

public static boolean verifyTransfer(double transferFunds, double funds){

if(funds < transferFunds){
return false;
}else{
return true;
}
}

}
 2

D. Refined Solution – Java Implementation

BankDemo.java

public class BankDemo {

public static void main(String[] args) {

BankFacadeSingleton bs1 = BankFacadeSingleton.getInstance();
}
}

BankFacadeSingleton.java

public class BankFacadeSingleton {

static private BankFacadeSingleton instance;

private int acctNum;
private int secCode;
BankMenu bankMenu;
BankSecurity acc;
BankAccount bacc;
private BankFacadeSingleton(){
try{
bankMenu = new BankMenu();
acc = new BankSecurity();
bacc = new BankAccount();

bankMenu.displayLogin();

acctNum = bankMenu.getAcctNum();
secCode = bankMenu.getAcctCode();

acc.setAcctNum(acctNum);
acc.setSecCode(secCode);

if(bankVerifyAccount()){
bankDisplayMenu();
}else{
System.out.println("Incorrect account number or security code.");
System.exit(0);
}
}catch(Exception e){
e.printStackTrace();
}
}
//Singleton Implementation
public static BankFacadeSingleton getInstance(){
if(instance == null) {
instance = new BankFacadeSingleton();
}
else{
System.out.println("Instance already running!");
}
return instance;
}
 2
public boolean bankVerifyAccount(){
return acc.acctExists(acctNum) && acc.secCodeConfirm(secCode);
}

public void bankDisplayMenu(){

bankMenu.displayChoice();
int choice = bankMenu.getChoice();
switch (choice) {
//Deposit Cash
case 1 -> makeDeposit();

//Withdraw Cash
case 2 -> makeWithdrawal();

//Funds Transfer
case 3 -> makeTransfer();

//Check Funds
case 4 -> makeBalanceCheck();

}
}

public void makeBalanceCheck(){

bacc.makeBalanceCheck();
bankDisplayMenu();
}

public void makeDeposit(){

bacc.makeDeposit();
bankDisplayMenu();
}

public void makeTransfer(){

bacc.makeTransfer();
bankDisplayMenu();
}

public void makeWithdrawal(){

bacc.makeWithdrawal();
bankDisplayMenu();
}

BankMenu.java

import java.util.*;
 2
public class BankMenu {

private int acctNum;

private int acctCode;
private int choice;

Scanner bankScanner = new Scanner(System.in);

public void displayLogin() throws Exception{

try {
System.out.println("Welcome to Northland Bank");
System.out.println("Please enter your account number");
acctNum = bankScanner.nextInt();
System.out.println("Please enter your 6-digit security code");
acctCode = bankScanner.nextInt();
}catch(Exception e){
e.printStackTrace();
System.exit(0);
}
}

public void displayChoice(){

while(true){
System.out.println("==========================");
System.out.println("1 - Deposit Cash");
System.out.println("2 - Withdraw Cash");
System.out.println("3 - Funds Transfer");
System.out.println("4 - Check Funds");
System.out.println("5 - Exit");
System.out.println("==========================");
System.out.println("Selection : ");
choice = bankScanner.nextInt();
if(choice > 4)
System.out.println("Thank you for using Northland Bank");
break;
}
}

public int getAcctNum() {

return acctNum;
}

public int getAcctCode() {

return acctCode;
}

public int getChoice(){

return choice;
}

BankSecurity.java

public class BankSecurity {

 2
private int secCode;
private int acctNum;

public boolean acctExists(int acctNum){

return acctNum == getAcctNum();
}

public boolean secCodeConfirm(int secCode){

return secCode == getSecCode();
}

public void setAcctNum(int acctnum){

this.acctNum = acctnum;
}

public void setSecCode(int secCode){

this.secCode = secCode;
}

public int getSecCode(){return secCode;}

public int getAcctNum(){return acctNum;}

public static boolean verifyTransfer(double transferFunds, double funds){

if(transferFunds < funds){
return true;
}else{
return false;
}
}

BankAccount.java

import java.util.*;

public class BankAccount {

private double funds = 0;

private double targetFunds = 0;
private int targetAccount;
Scanner accScanner = new Scanner(System.in);

public void makeDeposit(){

System.out.println("Please enter deposit value");
targetFunds = accScanner.nextDouble();
if(targetFunds > 50)
funds += targetFunds;
System.out.println("Funds successfully added.");
System.out.println("Your new balance is now: MYR " + funds);
}

public void makeWithdrawal(){

System.out.println("Enter withdrawal amount");
targetFunds = accScanner.nextDouble();
if(funds < targetFunds)
 2
System.out.println("You do not have enough balance to make this
withdrawal.");
else {
funds -= targetFunds;
System.out.println("MYR" + targetFunds + " has been withdrawn from your
account.");
System.out.println("Your new balance is now: MYR " + funds);
}
}

public void makeTransfer(){

System.out.println("Please enter recipient account number.");
targetAccount = accScanner.nextInt();
System.out.println("Please enter transfer amount to this account number.");
targetFunds = accScanner.nextDouble();
if(targetFunds < funds) {
funds -= targetFunds;
System.out.println("Transfer of MYR" + targetFunds + " to account " +
targetAccount + " is completed.");
System.out.println("Your new balance is now : MYR " + funds);
}else{
System.out.println("You do not have enough funds to make this
transaction.");
}
}

public void makeBalanceCheck(){

System.out.println("Your balance is : MYR " +funds);
}

E. Setting Up SonarQube for Projects

 2
1) Download SonarQube from https://www.sonarqube.org/downloads/ , select the Community Edition
2) Ensure that you are using JDK 8 or 11. Download their latest releases here:
- https://www.oracle.com/java/technologies/javase-jdk11-downloads.html
- https://www.oracle.com/java/technologies/javase/javase-jdk8-downloads.html

3) Download Apache Maven from: https://maven.apache.org/download.cgi - Select the Binary Zip Archive selection.
 2

4) Create an environment variable called “MAVEN_HOME” under System Variables in Environment Variables

5) Edit the PATH environment variable under System variables and add the following paths:

NOTE: It is important to have JDK 8 or 11 set up as Apache Maven only supports those versions. Apache Maven is
required to run SonarQube and for it to perform its testing and analyzing features to its max.
F. Executing SonarQube
1) Execute the StartSonar.bat service by navigating through the bin folder of the SonarQube setup folder.
 2
2) Once the service has started running, users can verify whether it is successful or not based on the command prompt’s
results.

3) Once SonarQube’s services are running, access any web browser and type in “localhost:9000” and click enter. Login
using the username and password “admin” and “admin” respectively. It is advised to change your password after the first
login.

4) Manually add a project. This option can be found in the top right hand section of the “Projects” page in the
SonarQube dashboard.
 2
5) Type in the Project Title you wish to set up. Click “Set Up” when finalizing.

6) Generate an access token. Access tokens are unique and can be used to access the project. Click on “Generate” once
changes are finalized and click on the “Continue” button.
 2

7) Click on “Maven” as the project’s build type.

8) Open the command prompt and navigate to the project folder. Use the commands cd or .. in order to navigate through
folders and subfolders (above and below). For this case, we are going to navigate to the simple solution’s directory.

9) Run this command in the command prompt. Ensure that you are at the target directory.

mvn clean install

10) Once no errors are detected, run the second command in the command prompt.

Mvn sonar:sonar -Dsonar.login=myAuthenticationToken

Replace the myAuthenticationToken variable from the token that was generated in Step 6
 2
11) Select the “Projects” tab on SonarQube, and the Solution should appear. Under this solution section, several
analyses, charts and graphs will be shown. Click on “Measures” to gain an overall insight of the project build. Exact details
about variables concerning the formula for Testability is seen under the “Size” and “Complexity” section of this menu.

12) Repeat steps 4 to 11 for other solutions.

G. Important Notes and Fixes.

It is important to ensure that Maven is running on the Java Project that is going to be analyzed with SonarQube, otherwise an
error stating that a “pom.xml” file will not be found. In order to solve this, Maven integration would be required towards the
project. This is accessible through configuring the project and adding framework support for Maven.

The user must have a pom.xml file available in their project for Apache Maven and SonarQube to work.