Bank Account

Introduction

System 1:
This example is about a small bank. The bank wants to replace old cashless payment system with a new one. One important concept in the system is an account.

account_class.jpg

System 2:
Another bank wants a system that can distinguish between accounts for cashless payments and savings accounts. A savings account does not support money transfer. Also, there should be two kinds of accounts for cashless payments: checking account, which doesn't provide an overdraft credit, and an open account which does. So you cannot directly reuse the original account class in the new system because it implements money transfer, which credit savings accounts do not provide. So you design an appropriate class hierarchy.

accounts2.jpg

System 3:
Another bank, needs to allow for different balancing periods depending on the account type and possible an individual arrangement with the customer. You use the strategy pattern to accomplish that. Balancing is the common abstract class of all balancing strategies. It declares the abstract method close() for balancing an account. The concrete subclasses provide concrete implementations of close(). The points at which variation occurs, are called variation points.

While working you realize that there are some more variations. These variations make the UML diagram complex. Also you know that a UML class diagram doesn't let you model variation points without deciding which mechanisms to use for their implementation.

account3.jpg

Domain Engineering

Design patterns, frameworks, and components are attempts to get something out of an approach for developing single applications that you can use for developing further, similar applications. On the other hand, domain engineering is designed to model application families. The results of Domain Engineering provide a completely different basis for developing concrete applications within the family, that is, Application Engineering.

In Generative Programming, the variation is covered by a set of elementary components that implement the different aspects of a domain concept and which you can combine in a vast number of ways.

Feature Modeling

A feature diagram is produced.

In contrast to a UML diagram, a feature diagram allows you to represent variability in an implementation-independent way. Each feature diagram you develop should be accompanied by additional information including the source where you got each feature from, its stakeholder, rationale for its use, constraints and dependencies between features etc.

Architecture Design

First, we need to get some order by classifying the needed implementation components into component categories. Here, each variation point has a corresponding component category, and there is an implementation component for each sub-feature.

component_categories.jpg

Each variation point has a corresponding component category, and there is an implementation component for each subfeature. In the case of account number type, there are two implementations: StaticNo, whose creation involves incrementing a class variable, and PersistentNo, whose creation involves incrementing a number stored in a file.
The dependencies can be shown with the following dependency diagram.

Every account has an owner, an opening date, a number, and a balance. Furthermore, it keeps track of the number of transactions and its currency. There are no dependencies between these basic categories. But all other categories depend on them. Therefore, we collect the basic categories into a configuration repository. Whether you can perform a payment or not, depends on overdraft, which results in an arrow from Payment to Overdraft. Payment keeps track of each transaction, and Balancing needs this information. Therefore, Balancing has access to Payment.

Then, we can sort the component categories into a GenVoca layered architecture. Each layer corresponds to a component category, and the categories with the most incoming dependency arrows go toward the bottom. The layer at the very bottom is the configuration repository. Each layer contains one or more parameterized components. Alternative components are separated by vertical bars. Components separated by commas have "or" semantics.

genVoca.jpg

Given this grammar, you can define a savings account as follows:

CalendarYear[CashIn[CashOut[NoCredit[PersonalAccount[C1]]]]]

An open account:

Quarter[Transfer[CashIn[CashOut[Credit[PersonalAccount[C2]]]]]

Implementation Components

The parameterized components will be implemented as class templates.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.