Reusable Object-Oriented Patterns in Banking Applications
By   ENOH JOHN ENOH (B.Sc (Hon) Computer sc, Diploma in Industrial Computing and Software Engineering (DIP) )    
(e-mail @ enojoneno@yahh.co.uk or call  08057039876)


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:

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

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 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
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()
    {
      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
Accountability Defines responsibility relationships within the organizational hierarchy

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


Inventory and Accounting Patterns
Account Records 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, include items like totaling levels
Transaction Links an entry in one account to a corresponding but opposite entry in another account
Summary Account Groups balances in a set of accounts as entries in another account. Also referred to as interface account
Memo Account Used 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
Contract Represents the simplest financial deal, namely, buying some instrument from another party
Portfolio Considers contracts collectively for the purpose of risk management
Quote Expresses 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)
Scenario Shows 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
Option A sub-type of contract where the buyer is given the option to buy at a pre-arranged price or the spot market price
Product Used 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.

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

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

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

References :

1 White Paper A. Dearden, J. Finlay, E. Allgar, B. McManu Using Pattern Languages in Participatory Design To appear           June 23 - 25, 2002
2 Technical Report J.M.Perry Perspective on Software Reuse Carnegie Melon University, Technical Report (CMU/SEI-88-TR-022, ESD-TR-88-023)1988
3 website Buchi, Martins The B Bank: A Complete Case Study www.abo.fi/~mbuechi/
4 website Joseph Yoder Banking Patterns www.joeyoder.com
5 Book M. Fowler Analaysis Patterns: Reusable Object ModelsReading MA: Addison Wesley 1997
6 Book E. Gamma, R. Helm, R. Johnson, J. VlissidesDesign Patterns: Elements of Reusable Software Reading MA: Addison     Wesley1995
7 book I. Jacobsson, G. Booch, J. Rumbaugh The Unified Software Development Process Addison-Wesley 1999
8 website Central Bank of Nigeria Official Website of the Central Bank of Nigeria www.cenbank.org
9 book J.W.Cooper The Design Patterns Java Companion Addison-Wesley 1998
10 Book Alexander C.The Timeless Way of Building Oxford University Press, NY, USA 1979
11 Journal Anderson B. Addendum to the Proceedings of OOPSLA '92. Workshop Report: Towards an Architecture Handbook OOPS Messenger 4(2) 1993 109 - 113
12 Journal Coad P., and Mayfield M.Addendum to the Proceedings of OOPSLA '93. Workshop Report: Patterns OOPS Messenger 4(2) 1993 93 - 95
13 Journal Anderson B., Coad P., and Mayfield M. Addendum to the Proceedings of OOPSLA '92. Workshop Report: Patterns: Building Blocks for Object Oriented Architecture OOPS Messenger 4(2)1994 107 - 109
14 Book Coplien, J & Schmidt, D. Pattern Languages of Program Design. Reading MA:, USA 1995
15 Book Alexander C., Ishikawa S., Silverstein M., Jacobson M., Fiksdahl-King I., and Angel S.A Pattern Language    Oxford University Press, NY, USA 1977
16 Website Data & Object FactoryDesign Patterns www.dofactory.com
17 website Vince Huston OO Design, Java, C++[/b]http://home.earthlink.net/~huston2/
18 Journal Michael Duell [b]Non-software examples of software design patterns Object Magazine Jul-9754

Nice research article there. But there is one thing I have to say. The ability to know and implement these patterns is as a result of long experience in software development. One cannot just pick up a design pattern book or article and read it, learn it, memorise them and voila! No way man. Infact you can't even learn it within the four walls of the university.You have to garner a vast knowledge and experience in application development. And when I mean application development, I do not mean programming. They r 2 of a kind. So in order to be well versed in Design Patterns and UML, you need to know have come accross the different scenarios/pitfalls one encounters when developing applications. After all Design Patterns are just Best Laid Options that have been prooven to be the best way out in certain application development scenarios by fellow developers who encountered certain pitfalls just b4 u got there.

DONT"T WORRY NIGERIA WILL CATCH UP WITH THE INDIANS COS I'VE SEEN SOME OF THIER BANKING APPLICATION CODE STRUCTURES.

@ScottN

"You hit the nail at the head". You can easily learn the fundamentals in School, but experience is needed to master design patterns and software engineering as a whole.

@enohj2ee
- Not bad write up though,
But, you didnt site your sources or references. That only forces readers to conclude that their is a lot of plagarism going.

U̶̲̥̅̊ guys are ryt, U̶̲̥̅̊ cnt just pick up a book and do all this.. You must know all †ђξ concepts of OOP design A̶̲̥̅̊₪d̶̲̥̅̊ implementation.many programmers today still apply thesame rules of procedural programming to OOP, I am guilty of dsame at times. Wonderful writeup really

but then its all good on paper...

I thought you would make a mini-banking application, explain the core functionalities of your app, and them implement it using the patterns described. That would have demonstrated your understanding of the concepts your are reasearching on or trying to explain.