Reusable Object-Oriented Patterns in Banking Applications

ABSTRACT

A pattern describes a proven solution to a recurring software design

problem, placing particular emphasis on the context and forces
surrounding the problem, and the consequences and impact of the
solution. Patterns are expressive. They provide a common vocabulary of
software solutions that can express large solutions succinctly. Patterns are
reusable. They provide a ready-made solution that can be adapted to
different problems as necessary. In relation to object models, they bring
reuse and consistency to the entire Object-oriented software development
process.

The banking domain is characterized by transaction processing [3].

Banking transactions in its simplest form represent events such as
customer withdrawing or depositing money. Transaction processing
therefore implies the update of customers accounts master file using the
transactions that occurred with respect to individual accounts. When such
updates are done at the instance of the transaction, we say processing is
real-time. To achieve this, the system must be online, which is facilitated
by a communication medium between client computers and the database
server. Another strategy is batch processing which involves collating
transactions over some period of time and then processing the whole batch
of transactions. Batch processing is restricted to just a few banking
transactions that are safe for such mode of processing. For security
reasons banking transactions processing must be online real-time as the
transactions occur in multiple locations (branches) and from multiple
channels (such as ATMs, the internet, etc).

In this work, we examine the general concept and usefulness of software

design patterns. In this regard, we consider the work done by Erich
Gamma, Richard Helm, Ralph Johnson and John Vlissides, known as the
"Gang of Four" or simply "GoF"[6]. Our study of banking software design
patterns will be based on the work done by Martin Fowler[5] evolving from
his experience in banking projects. Our results will be highly customised by
the Nigerian banking regulatory framework and supervisory guidelines of
the Central Bank of Nigeria [8].

Key words: Software design Patterns, Gang of four, banking transactions,

regulations, software reusability, Central Bank of Nigeria, Object-oriented
model, Unified Modelling Language

INTRODUCTION
Early in the 1990s many software engineers were seeking ways in which
design knowledge could be represented and shared between practitioners
[11]. This led to an interest in the works of Christopher Alexander and
resulted in early workshops on Object-Oriented Programming, Systems,
Languages and Applications (OOPSLA ) [12, 13]. Christopher Alexander, an
architect, along with his colleagues originally developed the pattern
concept as a theoretical account of the properties of a human or ‘living’,
built environment [10]. Discussed at these workshops are patterns that
address many topics including the organisation of software projects and
teams, design of user interaction, and software architectural design. The
approach to patterns adopted in these software engineering efforts have
significantly improved on Alexander’s original work.

Perhaps the best known work associated with these series of workshops
and conferences is Gamma et al.’s book ‘Design Patterns: Elements of
Reusable Object Oriented Software’ [6]. Gamma et al. state that a pattern
has four essential elements, a pattern name, the description of a problem,
a solution and a discussion of the consequences, i.e. costs and benefits, of
applying the pattern. Examples of object-oriented design patterns include
‘Observer’ (a generalisation of the familiar ‘model-view-controller’
architecture for user interface construction), and ‘Command’ (a software
design to implement undoability). Although Gamma et al.’s patterns do
contain cross references to each other; the patterns do not form a
generative language. Rather, the authors refer to their collection as a
“catalog”. Coplien & Schmidt [14] discusses the differences between
pattern languages and pattern catalogues in software engineering.

Banking processes and operations are very elaborate and incorporate

control mechanisms aimed at guaranteeing secure transactions. These
features make banking applications very complex. This in turn makes
applying software engineering principles (design patterns) to their design a
necessary step. Our broad aim is to examine the general field of design
patterns and explore the applicability of these concepts to the specific area
of automation of banking operations. This study should result in design
patterns for building banking applications.

AIMS AND OBJECTIVES

Banking is a highly regulated industry. In addition, banking operations are

complex, involving a lot of control mechanisms and segregation of duties.
Regulation means that banking practices adhere to the laws of the country
or locality. This is however done in addition to applicable international laws
where transactions are of international dimension. Our broad aim therefore

2
is to construct and document design patterns that will be useful in
architecting banking applications aimed at automating banking operations.

To achieve this aim, our objectives include the following among others:

• A study of the contributions of the Gang of four to the general area of

design patterns
• We will classify design patterns in banking taking note of work
already done in this particular area [3, 4] and the influence of the
Nigerian regulatory framework[8] for banking operations.
• Document our contributions arising from the above stated objectives
such that it can be modified and made reusable for implementing
banking applications suitable for any locality (outside the Nigerian
context).

The Gang of Four: Design patterns are recurring solutions to software

design problems one finds again and again in real-world application
development. Patterns are about design and interaction of objects, as well
as providing a communication platform concerning elegant, reusable
solutions to commonly encountered programming challenges. The Gang of
Four (GoF) patterns are generally considered the foundation for all other
patterns. These four top-notch researchers show how object-oriented
systems exhibit recurring patterns and structures of objects that solve
particular design problems, allowing designers to reuse successful designs
and architectures without having to rediscover the design solutions. Central
to their thesis is a catalog of 23 design patterns that have seen successful
practical application and are representative of good object-oriented design.
Each pattern describes the circumstances in which it is applicable, when it
can be applied in view of other design constraints, and the consequences
and trade-offs of using the pattern in a larger design. They are categorized
in three groups: Creational, Structural, and Behavioral. The categories are
listed below [16].

Creational Patterns
Abstract Factory Creates an instance of several families of classes
Builder Separates object construction from its representation
Factory Method Creates an instance of several derived classes
Prototype A fully initialized instance to be copied or cloned
Singleton A class of which only a single instance can exist

Structural Patterns

3
 Adapter Match interfaces of different classes
Bridge Separates an object’s interface from its implementation
Composite A tree structure of simple and composite objects
Decorator Add responsibilities to objects dynamically
Facade A single class that represents an entire subsystem
Flyweight A fine-grained instance used for efficient sharing
Proxy An object representing another object

Behavioural Patterns
Chain of Resp. A way of passing a request between a chain of objects
Command Encapsulate a command request as an object
Interpreter A way to include language elements in a program
Iterator Sequentially access the elements of a collection
Mediator Defines simplified communication between classes
Memento Capture and restore an object's internal state
Observer A way of notifying change to a number of classes
State Alter an object's behavior when its state changes
Strategy Encapsulates an algorithm inside a class
Template Method Defer the exact steps of an algorithm to a subclass
Visitor Defines a new operation to a class without change

Next, we will do a classification of banking patterns as currently exists in

literature. Before then, let us illustrate our basic understanding of patterns
using the proxy pattern [17] as an example. The proxy pattern provides a
surrogate or placeholder for another object to control access to it [6,
p207]. It uses an extra level of indirection to support distributed,
controlled, or intelligent access. It adds a wrapper and delegation to
protect the real component from undue complexity. It is presented as
follows:

UML class diagram

4
Participants: The classes and/or objects participating in this pattern are:

Proxy (MathProxy)
• maintains a reference that lets the proxy access the real subject.
Proxy may refer to a Subject if the RealSubject and Subject
interfaces are the same.
• provides an interface identical to Subject's so that a proxy can be
substituted for for the real subject.
• controls access to the real subject and may be responsible for
creating and deleting it.
• other responsibilites depend on the kind of proxy:
 remote proxies are responsible for encoding a request and its
arguments and for sending the encoded request to the real
subject in a different address space.
 virtual proxies may cache additional information about the real
subject so that they can postpone accessing it. For example,
the ImageProxy from the Motivation caches the real images's
extent.
 protection proxies check that the caller has the access
permissions required to perform a request.
Subject (IMath)
• defines the common interface for RealSubject and Proxy so that a
Proxy can be used anywhere a RealSubject is expected.
RealSubject (Math)
• defines the real object that the proxy represents.

Sample code in C#
This structural code demonstrates the Proxy pattern which provides a
representative object (proxy) that controls access to another similar object.

5
// Proxy pattern -- Structural example
using System;

namespace DoFactory.GangOfFour.Proxy.Structural
{

// MainApp test application

class MainApp
{
static void Main()
{
// Create proxy and request a service
Proxy proxy = new Proxy();
proxy.Request();

// Wait for user

Console.Read();
}
}

// "Subject"

abstract class Subject

{
public abstract void Request();
}

// "RealSubject"

class RealSubject : Subject

{
public override void Request()
{
Console.WriteLine("Called RealSubject.Request()");
}
}

// "Proxy"

class Proxy : Subject

{
RealSubject realSubject;

public override void Request()

{
// Use 'lazy initialization'
if (realSubject == null)
{
realSubject = new RealSubject();
}

realSubject.Request();
}
}
}

Output

6
Called RealSubject.Request()

This real-world code demonstrates the Proxy pattern for a Math object represented by a
MathProxy object.

// Proxy pattern -- Real World example

using System;

namespace DoFactory.GangOfFour.Proxy.RealWorld
{

// Mainapp test application

class MainApp
{
static void Main()
{
// Create math proxy
MathProxy p = new MathProxy();

// Do the math
Console.WriteLine("4 + 2 = " + p.Add(4, 2));
Console.WriteLine("4 - 2 = " + p.Sub(4, 2));
Console.WriteLine("4 * 2 = " + p.Mul(4, 2));
Console.WriteLine("4 / 2 = " + p.Div(4, 2));

// Wait for user

Console.Read();
}
}

// "Subject"

public interface IMath

{
double Add(double x, double y);
double Sub(double x, double y);
double Mul(double x, double y);
double Div(double x, double y);
}

// "RealSubject"

class Math : IMath

{
public double Add(double x, double y){return x + y;}
public double Sub(double x, double y){return x - y;}
public double Mul(double x, double y){return x * y;}
public double Div(double x, double y){return x / y;}
}

// "Proxy Object"

class MathProxy : IMath

{
Math math;

public MathProxy()

7
 {
math = new Math();
}

public double Add(double x, double y)

{
return math.Add(x,y);
}
public double Sub(double x, double y)
{
return math.Sub(x,y);
}
public double Mul(double x, double y)
{
return math.Mul(x,y);
}
public double Div(double x, double y)
{
return math.Div(x,y);
}
}
}
Output

4 +2=6
4 -2=2
4 *2=8
4 /2=2

Classification of Banking Application Patterns: Marsura in [4]

discussed extensively a classification of banking patterns based on the
work of Martin Fowler in the book, Analysis Patterns: Reusable Object
Models [5]. Some of the patterns described were primarily used in other
domains but seemed appropriate for modeling banking problems. The
classification is given as follows:

Accountability Patterns
Party Captures the notion of the entity, person or organisation
Organisation Hierarchy Defines a hierarchy of operational units within an organisation
Defines responsibility relationships within the organizational
Accountability
hierarchy

Observations and Measurements Patterns

Used to record measurements, combining both magnitude and
Quantity
units
Conversion Ratio Enables convertion of quantities from one unit to another
Category (discussed as Records a category observation, a qualitative statement about a
observation)1 person or a situation

1
Slightly modified to reflect author’s perspective

8
 Inventory and Accounting Patterns
Records the current value of an entity as well as the history of
Account changes that affect its value by entries made. We differentiate
between internal and customer accounts
Defines the structure of internal and customer accounts,
Chart of accounts2
include items like totaling levels
Links an entry in one account to a corresponding but opposite
Transaction
entry in another account
Groups balances in a set of accounts as entries in another
Summary Account
account. Also referred to as interface account
Used to record entries that are purely for record and
Memo Account
documentation purposes
Posting Rule Defines rules that are used to make (post) entries into accounts
A set of related accounts in terms of attributes such as interest
Product3
rates, charges applicable, interface (summary) account, etc
Balance Sheet and Defines the networth of a person or organization by
Income Statement considering his assets against his liabilities

Trading Patterns
Represents the simplest financial deal, namely, buying some
Contract
instrument from another party
Considers contracts collectively for the purpose of risk
Portfolio
management
Expresses the price of an item traded in the financial market as
Quote two numbers; the price to buy (which is the bid) and the price
to sell (the offer)
Shows how prices change over time and keeps a history of
Scenario
those changes

Derivative Contracts Patterns

Defines contracts where the agreement is to do the delivery
sometime in the future. Differs from a normal contract, usually
Forward Contracts
called a spot contract, where the delivery date is as close as
possible to the trade date
A sub-type of contract where the buyer is given the option to
Option
buy at a pre-arranged price or the spot market price
Used for trading purposes to separate a salesperson’s (or
Product
customer) view from the trader’s (risk manager) perspective

2
Included by author
3
included by author

9
This classification is not exhaustive. Secondly, it is not universal as banking
practices are highly influenced by local laws and regulatory guidelines. We
intend to examine the concepts and suggest a classification and design
patterns that take the Nigeria context of banking into consideration but still
complying with international standards. This helps us quickly come up with
a framework that is well-known and can be easily customized for banking
application development for any environment.

Documentation Framework: The pioneering work on design patterns by

Christopher Alexander [10,15] in addition to giving examples, described his
rationale for documenting patterns. Patterns are devices that allow
developers to share knowledge about their design. Documenting patterns is
one way that you can reuse and possibly share the information that you
have learned about how it is best to solve a specific program design
problem. Essay writing is usually done in a fairly well defined form, and so
is documenting design patterns. The general form for documenting
patterns is to define items such as:

• The motivation or context that this pattern applies to.

• Prerequisites that should be satisfied before deciding to use a
pattern.
• A description of the program structure that the pattern will define.
• A list of the participants needed to complete a pattern.
• Consequences of using the pattern...both positive and negative.
• Examples and sample code

This general form for documenting patterns has been modified by several
authors to suit their purposes. Whatever the variations, the documentation
for a design pattern should contain enough information about the problem
that the pattern addresses, the context in which it is used, and the
suggested solution. That is, the layouts used to document design patterns,
must usually resemble the essential parts. The authors usually include
additional sections to provide more information, and organize the essential
parts in different sections, possibly with different names.

A commonly used format is the one used by the Gang of Four [6]. It
contains the following sections for describing a pattern:

Pattern Name and Classification: Every pattern should have a

descriptive and unique name that helps in identifying and referring to it.
Additionally, the pattern should be classified according to a classification
such as the one described earlier. This classification helps in identifying the
use of the pattern.

10
Intent: This section should describe the goal behind the pattern and the
reason for using it. It resembles the problem part of the pattern. A short
statement that answers the following questions: What does the design
pattern do? What is its rationale and intent? What particular design issue or
problem does it address?

Also Known As: A pattern could have more than one name. These names
should be documented in this section.

Motivation: This section provides a scenario consisting of a problem and a

context in which this pattern can be used. By relating the problem and the
context, this section shows when this pattern is used. A scenario that
illustrates a design problem and how the class and object structures in the
pattern solve the problem. The scenario will help us understand the more
abstract description of the pattern that follows.

Applicability: This section includes situations in which a pattern is usable.

It represents the context part of the pattern. What are the situations in
which the design pattern can be applied? What are examples of poor
designs that the pattern can address? How can one recognize these
situations?

Structure: A graphical representation of the pattern. Class diagrams and

Interaction diagrams can be used for this purpose.

Participants: A listing of the classes and objects used in a pattern and

their roles in the design.

Collaboration: Describes how classes and objects used in a pattern

interact with each other. How the participants collaborate to carry out their
responsibilities.

Consequences: This section describes the results, side effects, and trade
offs caused by using a pattern. How does the pattern support its
objectives? What are the trade-offs and results of using the pattern? What
aspect of system structure does it let you vary independently?

Implementation: This section describes the implementation of a pattern,

and represents the solution part of the pattern. It provides the techniques
used in implementing this pattern, and suggests ways for this
implementation. What pitfalls, hints, or techniques should you be aware of
when implementing the pattern? Are there language-specific issues?

11
Sample Code: An illustration of how this pattern can be used in a
programming language code fragment that illustrates how you might
implement the pattern in a language of your choice.

Known Uses: This section includes examples of real usages of this

pattern. Examples of the pattern found in real systems.

Related Patterns: This section includes other patterns that have some
relation with this pattern, so that they can be used along with this pattern,
or instead of this pattern. It also includes the differences this pattern has
with similar patterns. What design patterns are closely related to this one?
What are the important differences? With which other patterns should this
one be used?

RESEARCH METHODOLOGY

Our research methodology will involve discussions with Subject Matter

Experts (SME) in the banking domain to establish domain requirements.
User specifications and the design patterns will be modeled using object-
oriented techniques as we examine the issues as they relate to design
patterns. The Unified Modeling Language and related class diagrams, use
case realizations and other techniques for modeling objects will come
handy. We intend to also explore the documentation format of the Gang of
Four [6] which incorporates UML concepts in presenting our results. These
techniques are described below:

Object-Oriented Design – UML: Fundamentally, design patterns are

studied with the aim of reusing object models. A design pattern therefore is
an object model that describes the realization of use cases, and it serves as
an abstraction of the implementation model and its source code [7]. An
object model consists of the following artifacts:

Class diagram: This diagram contains the implementation view of the

entities in the domain model. Each object in the design model should,
ideally, be exactly traceable to one or more entities in the domain model.
This property ensures that the requirements, as specified in use cases
containing entities defined in the domain model, are realized by
corresponding classes in the design model. The design model also contains
non-core business classes such as persistent storage and security
management classes.
Use case realizations: Use case realizations are described in
collaboration diagrams that use the class diagram to identify the objects
that participate in the collaboration diagrams. If the class diagram of the
design model is created as a derivative of the class diagram of a domain

12
model, each class in the design model traces to a corresponding class in
the domain model. There can be one-to-one, one-to-many, and many-to-
many relationships between design classes and domain classes. Because it
should be possible to implement a domain model in more than one way,
the direction of this class tracing should normally be only from the design
model to the domain model.

The traceability of a design model to the domain model aids IT architects

and application designers by providing a realization of the use cases that
closely corresponds to the business entities defined in the domain model.
In other words, there is no confusion over domain model entities used to
describe business use cases, since their corresponding design classes also
exist in the design model.

A high-level view of a banking application model is given below.

13
 Retail Channel - Teller

Customer Service Officer

«uses» «uses»

Creates Customer Post a transaction

«uses»

«uses»

Customer Accounts
«extends»
«extends» «uses»
Creates accounts

«extends»

Record Transactions
GL Accounts

SIGNIFICANCE OF STUDY
In Nigeria today so much of our hard-earned foreign exchange is spent
purchasing foreign software. In the banking sector, this situation is most
acute as it costs an average of $4million (Four million US dollars) to license
a banking application. It costs a bank an average of $300,000 (three
hundred thousand US dollars) for annual maintenance fees*. This situation
has subsisted because of the lack of indigenous efforts to develop banking
*
Sourced from subject matter experts

14
applications that will meet the stringent requirements of the regulatory
authorities as well as the operational complexities of banking operations.
This is large due to the lack of appropriate development practice that will
guarantee quality product considering how large and complex banking
applications are. Against this background, the significance of this study can
be summarized as follows:
• Primarily, we intend to extend and customize existing classification of
banking patterns [4] and make them reusable within the context of
banking application development for the Nigerian market and beyond
• Introduce software design patterns as a tool for introducing
consistency to the banking application software development process
as well as enable the reuse of banking software artifacts.
• Construct banking applications design patterns that take the specific
regulatory requirements of the Nigerian banking industry into
consideration
• This study is also expected to make inroads into other areas of
software development where the Nigerian practice is seriously lacking
behind. In particular, our framework for the banking application
should find application in the general financial services industry and
beyond.
• The high cost of developing a banking application has fundamentally
discouraged local efforts at developing one. Our results are expected
to form a knowledge base of software artifacts that can be reused by
developers thereby reducing cost of development and increasing
speed to market. It will become a basis for banking application
developers to share their design and be able to improve on the
patterns.
• Having access to a collection of patterns related to the banking
domain makes the development of banking applications more
efficient and helps us address the problem of banking application
development efforts failing after so much have been invested[4].
• Adopting the documentation format of the Gang of Four, we shall be
improving on earlier documentations of design patterns in the
banking and general financial domain.

CONCLUSION

We have broadly examined the issues to be discussed in the course of this

work. The general area of design patterns was introduced and pioneering
work in the area surveyed. The next step is a detailed study of these
outlines and articulation of our contribution to design patterns in the
banking domain.

15