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 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:

2

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 PatternsAbstract 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  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

3

  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.

// Proxy pattern -- Structural exampleusing System;

5

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 Called RealSubject.Request()

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

6

// Proxy pattern -- Real World exampleusing 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()    {      math = new Math();    }

    public double Add(double x, double y)    {       return math.Add(x,y);

7

    }    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 = 64 - 2 = 24 * 2 = 84 / 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 organisationOrganisation Hierarchy Defines a hierarchy of operational units within an organisation

 AccountabilityDefines responsibility relationships within the organizational hierarchy

Observations and Measurements Patterns

QuantityUsed to record measurements, combining both magnitude and units

Conversion Ratio Enables convertion of quantities from one unit to anotherCategory (discussed as observation)1

Records a category observation, a qualitative statement about a person or a situation

Inventory and Accounting Patterns

AccountRecords the current value of an entity as well as the history of changes that affect its value by entries made. We differentiate between internal and customer accounts

Chart of accounts2 Defines the structure of internal and customer accounts,

1 Slightly modified to reflect author’s perspective2 Included by author

8

include items like totaling levels

TransactionLinks an entry in one account to a corresponding but opposite entry in another account

Summary AccountGroups balances in a set of accounts as entries in another account. Also referred to as interface account

Memo AccountUsed to record entries that are purely for record and documentation purposes

Posting Rule Defines rules that are used to make (post) entries into accounts

Product3 A set of related accounts in terms of attributes such as interest rates, charges applicable, interface (summary) account, etc

Balance Sheet and Income Statement

Defines the networth of a person or organization by considering his assets against his liabilities

Trading Patterns

ContractRepresents the simplest financial deal, namely, buying some instrument from another party

PortfolioConsiders contracts collectively for the purpose of risk management

QuoteExpresses the price of an item traded in the financial market as two numbers; the price to buy (which is the bid) and the price to sell (the offer)

ScenarioShows how prices change over time and keeps a history of those changes

Derivative Contracts Patterns

Forward Contracts

Defines contracts where the agreement is to do the delivery sometime in the future. Differs from a normal contract, usually called a spot contract, where the delivery date is as close as possible to the trade date

OptionA sub-type of contract where the buyer is given the option to buy at a pre-arranged price or the spot market price

ProductUsed for trading purposes to separate a salesperson’s (or customer) view from the trader’s (risk manager) perspective

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.

3 included by author

9

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.

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.

10

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?

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?

11

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 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.

12

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

SIGNIFICANCE OF STUDYIn 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

13

hundred thousand US dollars) for annual maintenance fees*. This situation has subsisted because of the lack of indigenous efforts to develop banking 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.

* Sourced from subject matter experts

14