«Abstract Frameworks are a key asset in large-scale object-oriented software development. They promise increased productivity, shorter development ...»
Framework Development for Large Systems
Dirk Bäumer1, Guido Gryczan2, Rolf Knoll3, Carola Lilienthal2, Dirk Riehle4, and Heinz Züllighoven2
Frameworks are a key asset in large-scale object-oriented software development. They promise increased
productivity, shorter development times, and higher quality of applications. To fulfill this, frameworks
should be designed in such a way that they can evolve, be easily reused, adapted and configured. Drawing
on experience with large-scale industrial banking projects, we present concepts and techniques for domain partitioning, framework layering, and framework construction. In particular, we discuss how domain aspects relate to framework structure, how frameworks are layered to accommodate domain needs, and how the resulting framework layers are integrated without tight coupling.
1 Introduction These days, many businesses such as hospitals, banks and insurance companies tailor their services to the individual customer. Customer needs become the center of attention, the service being adapted to meet their needs. The more specific the service required, the more specialized the software solutions have to be. To achieve such flexibility, computer support is indispensable.
For some years, we have been designing and implementing such software solutions for various application domains.
Using object-oriented technology, frameworks now largely support the development of new applications. However, frameworks alone don’t solve all the problems. The construction and use of frameworks is so highly complex that software developers are confronted with almost insurmountable difficulties (see ). In this paper, we describe the problems encountered, and the concepts and techniques used to overcome them.
The work reported here is based on a series of object-oriented software projects that were conducted at the RWG5 (cf.
[2, 3]), a company providing software and computing services to a heterogeneous group of approx. 450 banks in Southern Germany. The projects have produced a family of applications covering almost the whole area of banking tellers, loans, stocks and investment departments as well as self-service facilities. The entire Gebos6 system, including several frameworks, consists of 2500 C++-classes and was developed over the past five years. Against this background, conclusions can be drawn about how to further develop, reuse and adapt frameworks. The presented solution could be transferred to any kind of graphic workplace system embedded in the context of human work.
First, we look at the main problems encountered, when designing large software systems. Such a large software system addresses and correlates the various tasks found in a business. It should be possible to configure and adapt the system to the requirementsof individual workplaces in several different enterprises. This can only be achieved by employing framework technology. The framework layers of the Gebos system are therefore described and discussed in detail. The following section describes layering techniques and divides frameworks into a concept and an implementation part.
These parts are combined to form concept and implementation libraries. Finally, we examine the Role Object design pattern, which is used to make an object play different roles in different departments while remaining an integrated component.
2 Framework Layering in Large Systems A framework models a specific relevant domain aspect using classes and objects.
classes define the model and the interaction of their instances. Concrete classes provide default behavior and implementations of the abstract classes.
The abstract classes specify the flow of execution and can be tailored to specialized implementations by subclassing.
Dirk Bäumer (firstname.lastname@example.org) can be reached at TakeFive Software, Eidmattstrasse 51, 8032 Zurich, Switzerland.
Guido Gryczan, Carola Lilienthal, and Heinz Züllighoven (email@example.com) work at University of Hamburg, Germany.
Rolf Knoll (firstname.lastname@example.org) can be reached at RWG GmbH, Räpplenstrasse 17, 70191 Stuttgart, Germany.
Dirk Riehle (Dirk.Riehle@ubs.com or email@example.com) can be reached at Ubilab, UBS, Bahnhofstrasse 45, 8021 Zurich, Switzerland.
RWG stands for “Württemberg Co-operative Bank Computer Center”.
Gebos stands for “Banking Co-operative Office, Communication and Organization System”.
Appeared in Communications of the ACM 40, 10 (October 1997). Page 52-59.
We describe an object-oriented software architecture using framework layers, the integration of different frameworks and their customization making up the resulting system. Frameworks and framework layering must be rooted in the application domain in order to meet business needs. We therefore begin by discussing how to relate application domains to frameworks.
2.1 Application Domain Concepts The services offered by a business enterprise such as a bank can be divided up into different areas of responsibility.
Traditionally, banks have organized their departments according to these different areas. Each department consists of specialists, whose work is confined to their own field of expertise. We call these areas business sections (e.g., teller, loan, investment, see Fig. 1). Today, the division into different departments is often supplemented by so-called service centers offering customers an “all-in-one” service. Service center clerks can perform most of the common tasks encountered in the various business sections. Business reorganization, thus, creates new types of workplaces. A concrete form of work will be referred to as the workplace context (see Fig. 1). Examples of workplace contexts in the banking
• Customer service center: A customer receives advice on loans, bonds or investments.
• Teller service: Customers should receive a fast and qualified service for frequent and standard requests. Here, a clerk has to deal with deposits, withdrawals, transfers and foreign currency.
• Automatic Teller Machines and home banking: The services of the bank are made directly available to its customers.
For every workplace context, a different application system may potentially be required. For a workplace in a customer service center, support is needed for the mixture of services from the different business sections. The customer consultant needs access to both the loan and investment sections when advising a customer. At the same time, the system must allow a simple money transfer.
Although each application system is tailored to the needs of a particular workplace context, all should be built on the same basis. Take the following example: Customer profiles exist in all departments of a bank. In the loans department, sureties are an essential part of the customer profile. A surety serves to minimize the bank’s losses in the case of a customer’s inability to pay. In the investments department, savings accounts form part of the customer profile. In both departments, though, the customer’s name, address and date of birth are an integral part of the profile. Software development for different workplace contexts needs to take into account these differences and similarities.
Our approach is to identify the core or common parts of the concepts and terms that are essential to running the business as a whole. We call these common parts the business domain (see Fig. 1). Cooperation within an organization is only possible through the existence of these core elements in the business domain. In a bank, ‘account’, ‘customer’ and ‘interest rate’ are examples of overlapping business domain concepts.
Figure 1: Organizational concepts in the application domain Modeling of the business domain can only be done if at least two business sections are already supported by software
systems. Although the business domain forms the basis for the business enterprise as a whole, it is not tangible as such:
there is no place in a bank where ‘account’ or ‘ customer’ can actually be seen. Considering the relevance of the business domain, we need to “reconstruct” the core concepts behind the different business sections in order to build an integrated system.
We believe that frameworks for this type of applications should be organized along business-domain, business-section and workplace-context lines. In order to avoid unnecessary duplication, frameworks should be designed so as to encourage or even enforce reuse of the business domain in the various sections. The reuse of framework components then yields the basis for uniform and coherent application systems. In the following sections, we describe the close correlation between application domain concepts and the framework architecture.
2.2 Layers of the Gebos system The layers of the Gebos system take into account the distinction between the business section, the business domain, and the workplace context. Several application systems can be based on the different business sections, and different business sections can be based on the same business domain. Two additional framework layers offering general support
complete the Gebos system (see Fig. 2):
• Application Layers provide the software support for the different workplace contexts.
• Business Section Layers consist of frameworks with specific classes for each business section.
• Business Domain Layer contains the core concepts for the business as a whole.
• Desktop Layer comprises frameworks that specify the common behavior and general characteristics of applications.
• Technical Kernel Layer offers middleware functionality and includes specific object-oriented concepts.
Figure 2: Layers and frameworks of the Gebos system The framework layers in Fig. 2 are not arranged with the Application Layers at the top end and the Technical Kernel Layer at the bottom. We have, instead, chosen a U-shape consisting of the Technical Kernel Layer, the Business Domain Layer and the Desktop Layer. The U-shape of the layers represents a frame for the Business Section Layers and the Application Layers. By enforcing the integration of the Business Section Layers and the Application Layers, further development can only take place within this U-shaped frame, leading to a fast and efficient implementation of new application systems. The Gebos system makes it possible to configure and adapt new application systems for a new bank in a comparatively short time. We now go on to look at the basic functionality of each layer and the relations between them.
2.2.1 The Technical Kernel Layer The Technical Kernel Layer provides services to other layers and is used by the other framework layers - like a class library with an API interface. Within the Gebos system, this layer encapsulates and stabilizes middleware functionality.
It consists of black box frameworks (see ). The frameworks in this layer can be classified as:
• Wrapper frameworks that include frameworks interacting with the underlying operating system, the window system, client-server middleware, and data stores (such as relational databases, CD-ROM drives or host databases).
• Basic frameworks that comprise specific object-oriented concepts such as a meta-object protocol, late creation, garbage collection including trace tool support, and a container library.
The main idea is to reuse the functionality encapsulated by the Technical Kernel Layer. These frameworks are used by all other layers, especially the Desktop Layer. They can be largely reused, as they do not incorporate any domainspecific knowledge.
2.2.2 The Desktop Layer The Desktop Layer comprises frameworks that specify the common behavior of applications, i.e the type of support for
interactive workplaces. Examples of frameworks in this layer are (see Fig. 2):
• The Tool Construction Framework, describing the general architecture of tools and their integration into an electronic workplace (cf. ). This can be compared to the MVC framework (cf. ).
• The Folder Framework, offering classes such as File, Folder and Tray. Following the desktop metaphor, the Folder Framework provides the familiar look and feel of interactive applications pioneered by the Macintosh system.
• The Value Framework enriches the standard value types offered by programming languages like C++ (e.g., Integer, Char and Boolean). It provides classes containing the basic mechanism for domain specific value types (e.g.
AccountNumber), which can only be used with value semantics.
The Desktop Layer thus defines the basic architecture of interactive application systems and their look and feel. This design decision ensures uniform behavior in the application systems as well as technical consistency. The Desktop Layer frameworks are therefore used like white box frameworks (cf. ) by subclassing and implementing abstract methods (see Business Section Layer). Frameworks belonging to this layer can be reused in any kind of office-like business domain with graphic workplace systems.
2.2.3 The Business Domain Layer The Business Domain Layer defines and implements the business’s core concepts as a set of frameworks based on the Desktop and Kernel layer. It thus forms the basis for every application system in this domain. It is crucial to make an appropriate division/separation between that part of a core concept that belongs to the business domain and the parts belonging to the business sections. If the core concept in the business domain is too small, the missing parts have to be duplicated for each business section, and consistency becomes a problem. If a core concept in the business domain becomes overloaded, transporting an appropriate object between the various applications becomes cumbersome.
This layer consists of classes such as Account, Customer, Product and various domain-specific value types. Although some implementations exist in this layer, most frameworks are white box and rather “thin”. The final implementation is postponed to the Business Section Layers.