Chapter 6

Case Study: Banking System

Outline

• Business Case• Context diagram and requirements• Existing architectural documentation• The Design Process– Step 1: Review Inputs– Iteration 1

• Summary

Business Case

• In 2010, the government of a Latin American country issued a regulation that required banking institutions to digitally sign bank statements.

• To comply with the regulation, “ACME Bank” decided to commission the development of a software system, which we will call BankStat, whose main purpose was the generation of digitally signed bank statements.

Context diagram• At its core, the system executes a batch process: bank

statements are retrieved from external data source, the data is validated and then sent to an external system to be digitally signed. The signed statements are then retrieved.

Key drivers for the first release• The batch process is triggered automatically once a month and ≈

2Million statements are processed• Primary quality attribute scenarios

– Reliability: Under normal operating conditions, the batch process is executed in its entirety 100% of the time.

– Performance: Under normal operating conditions, when the batch process starts, 2 million bank statements are read, processed, and sent to the signing provider in at most one hour.

– Availability: During normal processing, a failure may occur when reading information from the data source or when sending information for digital signature. A notification is then sent to the administrator, who manually restarts the process. When it is restarted, only the information that had not already been processed is treated.

• The first release only covered the batch process. A second release involves introducing an interface to monitor the state of the process to request reprocessing of incorrect statements and to generate reports

Use Cases for second release• UC-1: The user manually

requests the reprocessing of a number of statements according to some criteria (e.g. Period or status)

• UC-2: The user logs into the system

• UC-3: The user generates a report regarding the process

• UC-4: The administrator queries user logs to display activities of a particular user or group of users. Information can be filtered using criteria (e.g date, type of operation)

Quality Attribute Scenarios

ID Quality Attribute

Scenario Associated Use Case

QA-1 Security A user performs any operation on the system, at any moment, and 100% of the operations performed by the user are recorded by the system in the operations log

UC-4

ConstraintsID Constraint

CON-1 The user’s accounts and permissions are handled by an existing user directory server that is used by various applications in the bank.

CON-2 Communication with the data source must be realized using JDBC.

CON-3 Communication with the digital signature provider system is performed using web services. These web services receive and return the information in an XML format that adheres to specifications established by the government.

CON-4 The system must be accessed from a web browser, although the access is available only from the bank’s intranet.

Architectural ConcernsID Concern

CRN-1 The system shall be programmed using Java and Java-related technologies to leverage the expertise of the development team.

CRN-2 The introduction of new functionality must, as far as possible, avoid modifications to the existing batch processing core.

The existing design is an input to the design process

ADDSteps

Existing documentation: module view

• Layers and modules

Module view elementsElement Responsibility

Batch Processing Layer

This layer contains modules that perform the batch process. These components are developed using the Spring Batch framework.

Data Access Layer

This layer contains modules that store and retrieve data from a local database, which is used by the modules in the Batch Processing Layer.

Communications Layer

This layer contains modules that support communication with the external digital signature provider and the bank statement data source.

Batch Job Coordinator

This module is responsible for coordinating the execution of the batch process, including launching the process and invoking the different steps associated with it.

Job Steps This module contains the “steps” that are part of the batch job. These steps perform activities such as validating the information retrieved from the data source and generating the bank statements. Such steps generally read, process, and write data. Data is read from and written to the local database.

Module view elementsElement Responsibility

Local Database Connector

This module is responsible for accessing a local database used by the job steps to exchange information while performing the batch process. We refer to this databaseas “local” to differentiate it from the external data source; this database is used only locally (i.e., internally) by the application, even if it is deployed in a different node (see the next section).

Notifications Manager

This module manages logs and sends notifications in case of issues such as a communication failure with the external system.

Data Source Connector

This module is responsible for connecting with the external database that provides the raw bank statement information.

Digital Signature Provider Connector

This module is responsible for accessing the external system that performs the digital signing of the bank statements.

Existing documentation: Allocation View

• Deployment diagram

Allocation view elementsElement Responsibility

Data Source Server

This server hosts a database that contains the raw data used to produce the bank statements.

BankStat ServerDatabase

This server hosts the main batch process that is responsible for retrieving information from the Data Source Server, validating the information, and sending the information to the Digital Signature Server for signing.

ServerDigital

This server hosts a database that is used locally by the batch process in the BankStat Server to hold the state and information used in the execution of the batch process.

Signature Server

This server, which is provided by an external entity, is responsible receiving, digitally signing, and returning the bank statements. The server exposes web services that receive and produce XML information.

ADD Step 1: Review InputsCategory Details

Design purpose This is a brownfield system in a mature domain. The purpose is to design for the next system release.

Primary functional requirements

The primary use case for this release is UC-1.

Quality attribute scenarios

This extension of the system involves only a few quality attribute scenarios, so they are all considered as primary.

Constraints See slide 8

Architectural concerns See slide 9

Existing architecture design

Since this is brownfield development, an additional input is the existing architecture design, which was described in the previous section.

Iteration 1

Iteration 1: Step 2

• Since there are few drivers, a single design iteration has been decided

• Iteration goal: Modify the existing design to support all of the new drivers

Iteration 1: Steps 3 & 4

• Elements of the system to refine (step 3):– Main modules from BankStat– Node where the system is currently deployed

• Selection of design concepts (step 4):– Use the Web Application Reference Architecture– Use the Spring Security framework for Authorization and

Authentication– Use the Shared Database Integration pattern to obtain

information about the state of bank statements– Deploy following the three-tier deployment pattern

Iteration 1: Step 5

• Step 5: Instantiate Architectural Elements, Allocate Responsibilities,and Define Interfaces

• Decisions:– Host the web application in a separate web server– Configure Spring Security to use an external user

directory server

Iteration 1: Step 6

• Refined deployment diagram– Web/App Server: Hosts the

interactive part of the application

– Auth Server: Existing server that manages users and permissions for multiple applications in the bank (CON-1)

Iteration 1: Step 6

• Modules introduced to support UC-1

Iteration 1: Step 6Element ResponsibilityBank Statement Reprocessing View

This module displays a view that allows the user to query the state of bank statements that have been processed. It also allows the user to select from these statements the ones that need to be reprocessed.

Bank Statement Reprocessing Service

This module manages requests from the view, which include requesting bank statement information, marking bank statements that need to be reprocessed, and triggering the restart of the batch job.

Security Manager

This module, which is implemented using Spring Security, handles authentication, authorization, and the activity log (QA-1). It is also integrated with the external user directory server (CON-1).

Iteration 1: Step 6

• Sequence diagram for UC-1 (UML)

Iteration 1: Step 6

• From the interaction identified in the sequence diagram, initial methods for the interfaces of the interacting elements can be identified

Method Name Description

BankStatement [] get BSStatus(criteria)

Retrieves a collection of bank statements according to diverse criteria, including periods in time or status. 

boolean reprocess(BankStatement [])

Requests the reprocessing of a collection of bank statements.

Iteration 1: Step 7Not Addressed

Partially Addressed

Completely Addressed

Design decisions made during the iteration

UC-1 Modules that support the use case and their interfaces were identified anddefined based on the Web Application Reference architecture.

QA-1 Security logs are handled by Spring Security.

CON-1 Spring Security connects to the existing user directory server and uses itsinformation to support authorization and authentication.

CON-2 No changes have been made to the module that connects to the datasource.

CON-3 No changes have been made to the module that connects to the digitalsignature provider.

CON-4 The Web Application Reference architecture that was used specificallysupports access from web browsers.

CRN-1 The technologies that have been selected are Java related.

CRN-2 Integration with the existing functionality was made through the database (usingthe Database Integration pattern); changes to the existing functionality were not needed.

Summary• We presented a simple (but real-world) example of the use

of ADD in the context of a brownfield system• The steps of ADD are followed in the same sequence as in

greenfield systems but the main difference is that one additional input is the existing architecture

• This example highlights the importance of documenting the architecture

• Design in the context of brownfield systems usually involves more extensive changes than the ones in this example so an analysis of the proposed design changes is recommended before committing them