Content uploaded by Ebru Özdoğru Kandırmaz
Author content
All content in this area was uploaded by Ebru Özdoğru Kandırmaz on Apr 13, 2019
Content may be subject to copyright.
A Reference Model for Low-Level Design
Ebru Özdoğru Kandırmaz1 Ufuk Tiryaki2
Ali Hikmet Doğru3
1,2 IBTECH A.Ş. Tübitak MAM Teknoloji Serbest Bölgesi, Gebze/Kocaeli
3 Orta Doğu Teknik Üniversitesi, Bilgisayar Mühendisliği Bölümü, Ankara
1 ebru.ozdogrukandirmaz@ibtech.com.tr
2 ufuk.tiryaki@ibtech.com.tr
3 dogru@ceng.metu.edu.tr
Abstract. This research presents a reference model to improve the effectiveness
of low-level design activities. This model is supported with methodological steps
and has been realized as a result of real industrial problems and is explained here
using an example case. This work shows that low-level design activity is very
important to meet quality attribute requirements of systems as much as high-level
design activity. As a case study, re-engineering process of a legacy banking sys-
tem is presented.
Keywords: Low-level design, Software re-engineering, Quality attributes.
1 Introduction
Banking systems are enterprise systems. Financial technology companies have been
still using mainframe-based systems implemented by low-level and procedural pro-
gramming languages.
With developing technology and rising needs, banks have been studying to re-engi-
neer their systems. These new systems can have three basic properties:
1. Using high-level programming languages,
2. Fast-adapting architecture to meet changing/rising needs,
3. Easy access to data and mobile systems.
Digital banking systems in Turkey leads systems in Europe [1]. With this motivation,
architectural and design issues of systems are very important. Software architecture and
low-level design focused in this paper are issues having potential to develop in banking
systems as in every field.
2
2 Requirements and Quality Attributes
2.1 System Requirements
Analysis of non-functional requirements defines quality attributes of the systems. Qual-
ity attributes are very important in designing software architecture [2, 3]. The non-
functional requirements of the banking system can be summarized as follows:
Customer-Focused. There are two main groups of customers: those who define re-
quirements and use the system. Customers defining requirements are hereafter called
business lines.
Business lines are impatient due to the competitive environment for meeting the re-
quirements. There is no standard reference document for requirements. As the person-
nel in the lines of business change, the expectation from the system varies for the same
function.
Customers using the system are defined as end users who use banking transactions
as personnel or who receive services from the system. Customers receiving service
want not lose their money and standards of life because of changing market conditions.
They use social media effectively. Such users expects system owners to fix bugs
quickly and shorten time-to-market of the application.
Time-Focused. The systems in this field are alive systems used constantly in the pro-
duction environment. They include functions that need to provide uninterrupted, 7/24
service to customers. System owners want to fix errors in the production environment
as quickly as possible.
Software requirements change very rapidly because of the global financial market,
competitive environment and frequently changing legal regulations. Time-to-market of
developments becomes always a big constraint.
Performance-Focused. As adding new functions to system, daily transaction volume
increases at a very high speed. System scales out horizontally and vertically.
It is important that the system respond quickly. For example, when markets are very
volatile, customers need to see the exchange rate changes in near real time and process
fast. Boom in the financial market creates high processing volume and therefore con-
siderable amount of load in the systems.
2.2 Quality Attributes
Table 1 shows a classification list of non-functional requirements according to quality
attributes.
Table 1. Architectural Quality Attributes
Requirement
Quality Attribute
3
Alive systems
7/24 service
Performance/load
Availability / Reliability
Frequent changing requirements
Reusability / Extendibility / Maintainability
Short time-to-market
Reusability
Growing system
Extendibility / Scalability
3 System Re-engineering Process
3.1 Re-engineering Activities
Since system owners aim to deploy re-engineered systems to production environment
as quickly as possible, they primarily focus on the high-level design of the system in
the process. For this reason, they generally evaluate the issues related to low-level de-
sign as future working steps and postpone that activity.
Software architecture is a multi-tiered work that divides system into a number of
sub-systems from top to down. High-level design aims to identify main components of
the whole system and interfaces between them. On the other hand, low-level design is
the activity that designs components of the system determined in the high-level design
in detail.
System owners has chosen service oriented architecture (SOA) as architecture of the
example system presented in this study. It is possible to consider SOA as a high-level
architectural design pattern based on use of reusable and loosely coupled services [3].
System designers prioritized the following issues in high-level design activities:
Service pool,
Use-case scenarios and service orchestration,
Basic business-module components.
4
Figure 1. High-level architecture of the new system– Service Oriented Architecture (SOA)
Service pool contains necessary definitions for the services being used by the appli-
cations. It holds relation between the business-module component and source code of
the service.
The basic modules that make up the business layer provide the partitioning of the
system from a business point of view. This partitioning is generally consistent with the
organizational structure of the organization. The components inside the modules are the
source codes. Separation of the modules according to the business logic forms the com-
ponents.
In the system presented as an example, after the high-level architectural design, sys-
tem designers and developers transferred the legacy source code to the new software
language without detailed design. They planned detailed designing and rewriting of
legacy source code as further activities. At the end of this process, although a high-level
programming language is used, there exists a new loosely coupled system still main-
taining procedural source code.
3.2 Observed Remaining Problems
After the new system has been alive, business lines expect new functions running ac-
cording to their requirements. System owners still postpone re-designing and re-writing
of legacy code of the software.
Newcomers to the teams continue their customary adaptations in the codes. As code-
base becomes larger and developers’ habits settle, it is more difficult to include low-
level design activities.
In order to meet a changing requirement, developers can copy existing source code
with the intention of not affecting the working system. Therefore, software becomes
5
more complex by increasing number of service. It is difficult for the developers to write
code on the same functional module simultaneously.
Designers focus on high-level design of newly developed applications due to their
habits. This behavior becomes into corporate culture with time.
4 A Reference Model for Low-Level Design
A simple reference model is proposed to activate low-level design activities. This
model intends following purposes:
1. To eliminate deficiencies due to lack of low-level architectural activities after re-
engineering of a legacy system and thus, to direct re-engineering process by remov-
ing side effects of inherited procedural source code
2. To force low-level architectural design activities for software developed from
scratch in the system.
The focal point of reference model is to facilitate development of software appropri-
ate to design, which can manage dependencies by creating a framework compatible
with the principles known as package design principles and first five principles of class
design for object orientation [6,7]. This reference model aims to achieve the goal by
applying the following two issues:
1. Building correct package structure, and
2. Using design patterns.
4.1 Correct Package Structure
The functions within the component have to be grouped in accordance with the nature
of design activities that divide systems into sub-systems from top to bottom. Ensuring
the integrity within a package according to business perspective is one of the most im-
portant criteria. The orientation of business perspective should naturally support mod-
ularity principles. Packages should be created by considering dependency principles [6,
7]. High cohesion and low coupling principles [6, 7] determine dependency principles
between packages:
Related with high cohesion:
Release Reuse Equivalency Principle (REP): The granule of reuse is the granule of
release.
The Common Closure Principle (CCP): Classes that change together are packaged
together.
The Common Reuse Principle (CRP): Classes that are used together are packaged
together.
Related with coupling:
6
The Acyclic Dependencies Principle (ADP): The dependency graph of packages
must have no cycles.
The Stable Dependencies Principle (SDP): Depend in the direction of stability.
The Stable Abstractions Principle (SAP): Abstractness increases with stability.
The correct creation of the package structure provides the following benefits:
Meeting software quality attribute requirements more effectively,
Understanding the functions in the component more quickly,
Deployment and license of functionalities independently,
Simultaneous development within the same module.
When sub-functions exist in the functional packages, creating sub-package is bene-
ficiary. There are sub-packages for end-of-day and database operations.
4.2 Design Patterns
Design patterns are reusable solution to a commonly occurring problem in software
design [5]. With their properties, they affect software quality metrics positively [15].
Using a template defined and including design patterns has an effect that supporting
software development in accordance with first five design principles. These principles
focus on architecture that aims to develop software that can more easily adapt to
changes and developers can maintain the software more easily. They are known with a
mnemonic name S.O.L.I.D [6,7]:
Single Responsibility Principle (SRP): A class should have one, and only one, reason
to change.
Open/Close Principle (OCP): A class behavior can be extended, without modifying
it.
Liskov Substition Principle (LCP): Derived classes must be substitutable for their
base classes.
Interface Segregation Principle (ISP): Interfaces should be fine grained that are cli-
ent specific.
Dependency Inversion Principle (DIP): Dependencies should be on abstractions, not
on concretions.
Table 2 presents a mapping of software quality attributes with package and
S.O.L.I.D principles:
Table 2. Mapping of quality attributes and S.O.L.I.D principles
Attribute
Package Principles
S.O.L.I.D Principles
Usability
Availability
-
-
Reusability
REP, CCP, CRP
S, I
Extendibility
ADP, SDP, SAP
O, L, I, D
7
Maintainability
REP, CCP, CRP, ADP, SDP, SAP
S, O, L, I, D
Scalability
-
S, I
It has been observed that the use of these design patterns has been beneficial in reducing
the side effects of the changes occur later in the projects and facilitating the manage-
ment of these changes.
4.3 Reference Model
Package Decomposition in Components. Figure 2 shows the division of module com-
ponents applying the reference model in accordance with the package principles. Pack-
age decomposition has been determined as similar and common structures created in
the projects developed over time. Below is a list of common examples of such struc-
tures:
Figure 2. Package decomposition in components
Function / Sub-function package: They are function groups that have integrity within
the component from a business point of view.
Service Facade: In a function/sub-function package that is compliant with SOA, they
are packages, which contain source code as entry point of services, provided by the
system to the other components.
Control: These packages contain control logic related with functions. These control
structures exist in almost every application module in the organization. As an exam-
ple, these structures can include logic such as verification of data.
Calculation: These packages contain calculations related with functions. Almost
every banking software has calculations, such as interest, return of investment etc.
Operation: These packages contain operations related to functions. Credit applica-
tion is an example for these operations.
8
Transformation: These packages contain structures for creation of data models and
transformation between them.
Model: These contain data models related to functions.
End-of-Day: In banking software applications, batch process runs at the end of the
day. For example, batch processes interest returns in to accounts for term deposits.
Database: These packages contain classes to access database related to functions.
Proposed Design Patterns. Reference model suggests a number of defined design pat-
ters for determined functions. Reference model determines design patterns, used as so-
lutions of common problems in projects over time as generalized solutions in its own
scope. In this way, reference model presents ready-to-use solution templates for appli-
cation development.
Following is a list of proposed design patterns in the scope of the reference model:
Dependency injection (DI) and Inversion of Control (IoC) [4]: Dependencies are
removed by using interfaces. Objects are passed to dependent at run time.
Façade [5] is used for entry points of services in the source code: It makes simple
changing source code according to changing requirements. It does not need to
change service pool and definitions. It eliminates side effects of refactoring in source
code. It protects applications that service serves from the side effects of code and
design improvements. It is proposed to use a Façade for every functional package.
Chain of Responsibility (CoR) [5] is used in control packages.
Decorator [5] is used in calculation packages.
Decorator [5] is used for operation packages.
Builder [5] is used for Transformation packages.
Factory [5] is used for creating objects in control and calculation packages.
Adapter [5] is used for writing to database and reading from database. By using this
pattern, database abstraction is implemented.
Table 3 shows an evaluation of design patterns used in the reference model in terms of
S.O.L.I.D principles:
Table 3. Mapping of Proposed design patterns and S.O.L.I.D principle
Proposed Design Pattern
S.O.L.I.D Principle
Dependency Injection ve IoC
I, D
Façade
I, D
Chain of Responsible
S, O, L, I, D
Decorator
S, O, L, I, D
Factory
S, O, I, D
Builder
S, I, D
Adapter
S, I, D
9
5 Evaluation of Reference Model in Practice
In the institution where this study is guided, the reference model implementation pro-
cess for the low-level design activities in the components of the business modules in a
field has been going on for the last few years.
When designers decided development in an existing component in the high-level
design process, developers applied reference model into these components and refac-
tored the legacy source code. On the other hand, when designers decided to develop a
new component, developers developed the component from the scratch in accordance
with reference model since there is no legacy code.
5.1 Analysis of Software Quality Metrics:
Software quality is evaluated by predetermined properties [9]. Within the scope of
determined metrics in the organization, SONAR, which is a code quality tool, is used.
Designers and developers applied reference model to “Risk” component while de-
veloping “Collaterals of Derivative” project. Software quality metrics of “Risk” com-
ponent before the project were compared with the values after the project developed by
applying the reference model. Table 4 summarizes the effects of reference model usage
in software quality metrics:
Table 4. Analysis of software quality metrics
Metric
Effect
Change (%)
Source line of code
Increase
15.82
# of classes
Increase
7.09
Source line of class code
Decrease
34.16
McCabe complexity
Decrease
8.09
McCabe class complexity
Decrease
26
Package cycle
No newly created
-
Package dependencies
No newly created
-
# of Package cycle
Decrease
43.17
# of issues
Decrease
11.75
Technical debt
No newly created
-
According to the table, although source line of code increases, class line of code, com-
plexity values, # of package cycles, and # of issues decrease. Increase in # of classes
and decrease in lines of class code, are compliant with SRP and ISP in S.O.L.I.D prin-
ciples. A software having small number of lines of class code, complexity, number of
packet conversions and dependencies is modular and software maintenance is easier.
Decrease in # of issues and no newly created technical debt give an idea of decrease
in the rate of error production using the reference model.
10
5.2 Project Costs:
Projects in compliant with the common fund infrastructure in banks have been devel-
oped across the sector. For this purpose, two projects, addition of Turkish Lira (TL)
Fund and Foreign Currency (FX) Fund functions, were planned to deploy into produc-
tion environment in two phases in the institution.
In TL Fund project, developers added needed functionalities according to common
fund infrastructure in the TL Fund module, which is currently in the system, by apply-
ing the reference model. In this context, a code and database model, which is compat-
ible with the reference model, has been formed on the modules where the fund purchase
and sales flow is managed.
In FX Fund Project, there has already been a Fund Module developed in a previous
project by applying the reference model. For the common fund infrastructure, develop-
ers added new functionalities by continuing the usage of reference model in this com-
ponent. In contrast to the TL fund project, the Foreign Currency Fund project was de-
veloped on a module with a reference model applied.
Table 5 shows that the foreign currency fund project is realized with less cost alt-
hough there are close numbers of screen and table in two projects.
Table 5. Comparison of Project Costs
Project
Cost (Man/Day)
#of Screen
# of Database Tables
TL Fund project
960
24
18
FX Fund Project
320
21
14
5.3 Meeting Non-functional Requirements:
We can examine in two ways how reference model meets non-functional require-
ments:
1. Table 1 shows the relation between non-functional requirements and quality attrib-
utes. Table 2 and Table 3 present the mapping of the quality attributes to principles
that reference model is based on. In this context, the effect of meeting the non-
functional requirements with the reference model can be done by evaluating the ta-
bles.
2. The analysis in Table 4 and Table 5 refers the effect of reference model in meeting
non-functional requirements in practice.
Following paragraphs include these evaluations:
Performance/Load: The availability of the system increases due to the decrease in
the number of issue given in Table 4. System performance increases since there are
less erroneous service.
11
Frequent change of requirements: By evaluating Table 1, Table 2 and Table 3; the
reference model has a positive effect on addressing frequently changing require-
ments. According to results in Table 4, the reference model provides system with
easier maintainability. Therefore, making changes in system is easier.
Short time-to-market: Reference model has a positive effect on shortening the time
to market by taking Table 1, Table 2 and Table 3. According to the results presented
in Table 5, the duration shortens with the use of the reference model. Within the
scope of evaluations in the quality criteria analysis, the development and the changes
affect a specific code classes. Therefore, this shortens both the development and the
test period.
Growing system: Based on Table 1, Table 2 and Table 3, the reference model meets
this requirement.
5.4 Observations:
The use of the reference model makes it necessary to apply certain principles in the
software. With this obligation, we have gotten the following achievements:
Number of procedural code has begun to decrease. The increase in the number of
classes in Table 4 and the decrease in the number of lines of class codes are indica-
tors of this condition. In addition, the developers develop structural thinking, top-
down design perspective, and design patterns.
There are now reusable codes in components. Based on the evaluations in Table 5,
the project developed after using the reference model accelerated the deployment
process to the production environment by using some classes in the first project.
The codes are easier to understand and they shorten understanding the design. Im-
provements in quality criteria in Table 4 support this observation. Maintenance pro-
cesses are easier in the institution where agile processes exist and detailed documen-
tation does not exist. Developers can detect code blocks that cause errors using the
debugger program less frequently and in less time.
Developers can implement new improvements without having to take into account
the workflow in a very large code block and the software can extend more easily.
The number of issue and the duration of the regression test reduced due to the ease
of developing code, which produces less side effects. Improvements in the quality
criteria in Table 4 and the durations in Table 5 support this observation.
6 The Effects of Process on Developers
Because the transition to a new model requires the need to change the software de-
velopment culture and learn new topics, its adoption takes time.
For the software developers who have worked in the organization for many years,
there have been difficulties in the process of adaptation to the model. Since those de-
velopers accepts accustomed software development approach as a faster solution with
12
the effect of time-to-market pressure, transition process have been taking place in a
longer period.
The application of the reference model by newly joined software developers helped
them adapt to lower level design activities more easily. At the same time, the badly
effect of the legacy codes that are maintained and inherited was also still in place.
The reference model has been used more effectively with the continuation of the use
of the reference model in time and the reduction of the legacy codes.
7 Related Works
With the use of the reference model presented in the scope of this study, completing the
low-level architectural deficiencies of the old systems and implementing low-level de-
sign activities in the newly designed systems are the main purposes. The reference
model seeks to achieve this goal by providing a template model based on software prin-
ciples and predetermined design patterns.
Redesigning systems as forward reengineering and reverse engineering are the ap-
proaches used in reengineering.
For the reengineering process of legacy systems, there are some studies in different
sectors, such as defense and medical, which use forward reengineering approach using
design patterns like the reference model discussed in this study [9, 10, 11, 12]. There
are also studies that show the use of design patterns in the reengineering process affects
the software quality positively [13]. These studies emphasize the extensibility and
maintainability of the software. On the other hand, using reverse engineering method,
studies that produce object-oriented codes from procedural codes are also mentioned
[14].
The reference model differs from these studies in terms of suggesting a model that
would force low-level architectural activities for systems, which are developed from
scratch besides reengineering of legacy systems.
8 Conclusion and Future Works
Low-level design activity is an important factor in meeting the quality requirements of
the system. Using of more flexible and reusable building blocks supports the activity
positively.
The postponement of low-level design activities in the reengineering process of en-
terprise systems creates many negative side effects in the alive systems.
The use of a reference model facilitates the realization of low-level design activities.
The proposed reference model bases on the use of certain design patterns [5] with the
principles of Package and S.O.L.I.D [6, 7].
Business modules using reference model has achieved the goals that are shorter time-
to-market, quick adaptation to changing requirements and less error with less side ef-
fects. It also has a positive effect on the formation of the corporate culture for the living
system.
13
The use of the reference model requires a transformation process for procedural leg-
acy systems. On the other hand, in a newly developed system, it is easier since new
system adopts the model from the scratch.
In the present process, adaptation to the model depends on the control and guidance
of the designers. In order to reduce the dependence on the person, designers are plan-
ning the automation of the model as future work. A software that enables the use of a
model template within components can help save time by reducing the burden on de-
signers. It can allow developers to develop model adaptability on their own.
The reference model is a model that has been developed and implemented for the
requirement of the institution. However, it has the potential to be applied in other sec-
tors with the qualifications it covers. In this context, the application experiments of the
reference model in other sectors and comparison of results in two sectors can be a future
work.
References
1. https://www2.deloitte.com/content/dam/Deloitte/global/Documents/About-Deloitte/cen-
tral-europe/ce-digital-banking-maturity-study-emea.pdf?nc=1, last access 2018/09.
2. O’Brien L., Bass L., Merson P.: Quality Attributes and Service-Oriented Architectures,
CMU/SEI-2005-TN-014.
3. Kaur P., Sing H.: An Analytical Review of Quality Attributes of Service-Oriented Architec-
ture, Trends in Information Management (TRIM), ISSN: 0973-4163, pp. 40-50, (2014).
4. https://martinfowler.com/articles/injection.html. , last access 2018/09.
5. Gamma E., Helm R., Johnson R., and Vissides J.: Design Patterns: Elements of Reusable
Object-Oriented Software, Addison-Wesley, 1995
6. Design Principles Page Papers by Bob Martin, http://condor.de-
paul.edu/dmumaugh/OOT/Design-Principles, last access 2018/11.
7. http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod, last access 2018/10.
8. IEEE, ‘Standards for a Software Quality Metrics Methodology’, P-1061-1998 (R2009),
IEEE Press, New York, 2005.
9. Barkataki S., Harte S., Dinh T., Reengineering A Legacy System Using Design Patterns and
Ada-95 Object-Oriented Features, http://www.sigada.org/conf/sa98/papers/barkataki.pdf,
last access 2018/11
10. Re-engineering Legacy Code with Design Patterns:A Case Study in Mesh Generation Soft-
ware,https://pdfs.sematicscholar.org/1aa8/ba2e3cd596f3c501e0966530ab24c6bb190e.pdf,
last access 2018/11.
11. Jung-Eun Cha, ChulüHong Kim, Young-Jong Yang, Architecture Based Software Reengi-
neering Approach for Transforming from Legacy System to Component Based System
through Applying Design Patterns, International Conference on Software Engineering Re-
search and Applications, SERA 2003: Software Engineering Research and Applications pp
266-278.
12. Usability of Software Architecture Design Pattern in Medical Process Re-engineering
Model, http://www.ijaiem.org/Volume2Issue6/IJAIEM-2013-06-26-084.pdf, last access
2018/11.
13. On the Role of Design Patterns in Quality-Driven Re-engineering, http://www.star-
group.uwaterloo.ca/pubs/conf/Tahvildari_et_al_CSMR02.pdf, last access 2018/11.
