Printer Friendly

Framework development for large systems.

Experiences with successful large-scale industrial banking projects provide the basis for the concepts and techniques presented here.

In the present business climate, many establishments such as hospitals, banks, and insurance companies tailor their services to the individual customer. Customers' needs become the center of attention and the service is adapted to address their needs. The more specific the required service, the more specialized the software solutions have to be. To achieve such flexibility, computer support is indispensable.

We have been designing and implementing software solutions for various application domains and by 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 [5]). In this article, 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 RWG(1) [2, 3], a company providing software and computing services to a heterogeneous group of approximately 450 banks in southern Germany. The projects have produced a family of applications covering almost the entire area of banking: tellers, loans, stocks and investment departments as well as self-service facilities. The entire Gebos(2) system, including several frameworks, consists of 2,500 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 applied to any kind of graphic workplace system embedded in the context of human work.

We begin by looking at the main problems encountered when designing large software systems. A large software system addresses and correlates the various tasks needed to run a business. It should be possible to configure and adapt the system to the requirements of 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 two parts: concept and implementation. These parts are combined to form concept and implementation libraries. Finally, we examine the Role Object Design Pattern that is used to make an object play different roles in different departments while remaining an integrated component.

Framework Layering in Large Systems

A framework models a specific relevant domain aspect using classes and objects. Abstract 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.

We describe an object-oriented software architecture using framework layers, the integration of different frameworks and the customization of the frameworks 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.

Application Domain Concepts. The services offered by a business enterprise such as a bank can be divided 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 - [ILLUSTRATION FOR FIGURE 1 OMITTED]).

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 [ILLUSTRATION FOR FIGURE 1 OMITTED]. Examples of workplace contexts in the banking business are:

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

* 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 consultants need to have access to both the loan and investment sections when they are advising their customers. 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, all systems should be built on the same basis. Consider 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 these differences and similarities into account.

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 [ILLUSTRATION FOR FIGURE 1 OMITTED]. 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.

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 an 'account' can actually be seen. Considering the relevance of the business domain, we need to reconstruct the core concepts providing the basis for the different business sections in order to build an integrated system.

We believe that frameworks for these types 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.

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 [ILLUSTRATION FOR FIGURE 2 OMITTED]:

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

The framework layers in Figure 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.

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 [6]). The frameworks in this layer can be classified as: Wrapper frameworks including 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); and 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 domain-specific knowledge.

The Desktop Layer comprises frameworks that specify the common behavior of applications, for example, the type of support for interactive workplaces. Examples of frameworks in this layer are: the Tool Construction Framework, describing the general architecture of tools and their integration into an electronic workplace [9]. This can be compared to the MVC framework [8]; 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; and the Value Framework that 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 [6] by subclassing and implementing abstract methods (see the discussion of the Business Section Layers). Frameworks belonging to this layer can be reused in any kind of office-like business domain with graphic workplace systems.

The Business Domain Layer defines and implements the business's core concepts as a set of frameworks based on the Desktop and Technical Kernel layers. It thus forms the basis for every application system in this domain. It is crucial to make an appropriate division or separation between the 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.

The Business Section Layers are composed of separate partitions for each business section. The frameworks in these partitions are based on the Business Domain, the Technical Kernel, and the Desktop Layers. They are implemented by subclassing the Business Domain and Desktop Layer classes. Usually, each subclass only implements the abstract methods predefined in the respective superclass. In this layer, we find classes like Borrower, Investor, Guarantor, Loan, Loan Account, and tools for specific tasks within the business section.

Business section frameworks change more frequently than business domain frameworks. A business domain framework should therefore only incorporate those core concepts that are relevant to most business sections. It should, however, provide hooks that can be easily extended and customized for applications that use one or more business sections. To relate the core concepts of the Business Domain Section to their extensions in the Business Section Layers the Role Object Pattern has been developed.

The separation of the Application Layers from the Business Section Layers is motivated by the need to configure application systems corresponding to different workplaces. The Gebos system has to support business activities in a wide range of banks, from those with only a few branches to large ones with over a hundred. Applications configured to meet the different workplace context requirements of an individual bank can be found in these layers.

Framework Construction for Large Systems

The internal structure of frameworks has to be chosen to minimize the coupling between different frameworks and application systems. Reopening frameworks during application-system development should also be avoided. In the following section we therefore introduce library layers. Moreover, the design and implementation of business domain frameworks should be independent of any business section framework. We have employed various patterns in the Gebos system, but the Role Object Pattern is crucial for the integration of the business domain and business sections. This pattern will therefore be described in detail.

Structuring of Frameworks in Library Layers. Based on the preceding discussion, we group class hierarchies to form frameworks. A framework of the Gebos system does not match a specific class hierarchy, but contains parts of different class hierarchies. This contrasts with the traditional way [7] of aligning class hierarchies and frameworks [ILLUSTRATION FOR FIGURE 5 OMITTED].

Each framework of the Gebos System is divided into a concept part and one or more implementation parts [ILLUSTRATION FOR FIGURE 3 OMITTED]. The concept part is modeled according to the concepts of the application domain. The implementation part subclasses the corresponding classes of the concept part. The former is developed with technical aspects in mind. Without this separation one cannot discuss the various dependencies between classes with an explicit focus on either the technical or the conceptual part.

After dividing each framework into concept and implementation parts, we physically package concept parts into concept libraries, and implementation parts into implementation libraries. The structure of the concept libraries need not correspond to the structure of the implementation libraries. In our example, Framework A is divided into two implementation parts, each forming a separate implementation library. The concept parts of Framework A and B are packaged into one concept library.

The framework parts themselves are organized in layers according to application domain concepts. Concept and implementation parts of one framework do not therefore necessarily belong to the same layer ([ILLUSTRATION FOR FIGURE 3 OMITTED], Framework B). This enables us to describe a concept in the Business Domain Layer and provide different implementations according to specific business sections. The frameworks in the Business Domain Layer in Figure 2, for example, consist only of concept parts for the core concepts. The implementation parts are located in the frameworks of the Business Section Layers.

The use of classes belonging to other layers is restricted to the concept classes of a framework. Implementation parts of frameworks can then be changed without affecting those classes that use the concept part. To avoid cyclic dependencies a framework should only be used by classes contained in frameworks of higher layers.

By offering libraries that include either several concept or implementation parts of frameworks per layer, the configuration of different application systems is facilitated. Each application system consists of only those libraries needed for operation. The different frameworks are provided in DLLs to ensure that framework classes cannot be changed at will. All application systems are thus built according to the same schema. This is extremely important for classes that predefine and partially implement the flow of control for an application system (see the discussion of the Desktop Layer).

To realize the decoupling between concept and implementation parts, clients should use a creational pattern, such as Factory Method or Prototype [4], to hide the selection of a particular implementation of a concept class. A pattern that has proved to be particularly effective is the Product Trader pattern [1].

The division into concept and implementation parts is a prerequisite for developing an integrated system because we can supply a concept part in the Business Domain Layer and several implementation parts in the Business Section Layers. In the following section, we describe how to connect the classes of the concept part with those of the various implementation parts.

The Role Object Pattern. A simple way to connect concept and implementation parts is to subclass a class from the Business Domain Layer. This, of course, means that two instances of different subclasses are not identical. If they are meant to be conceptually identical, however, it becomes hard to use them as a consistent representation of one logical object. We apply the Role Object Pattern to make one logical object span one or more layers. The core object, which resides in the Business Domain Layer, is extended by role objects, which reside in the Business Section Layers.

A role is a client-specific view of an object playing that role. One object may play several roles, and the same role can be played by different objects. An instance of a core concept belonging to the business domain may play several roles in different business sections. For example, in the loan business section, 'customer' could play the role of 'borrower' or 'guarantor'. In the investment business section, 'customer' could play the role of investor. These three roles could also be played by the same customer, in real life as well as in the system model.

We use a combination of design patterns, collectively called the Role Object Pattern, to attach business section roles to core concept objects. Figure 4a illustrates the design of the customer example. Using the Decorator pattern, a core concept such as 'customer' is defined as an abstract Customer superclass - as a pure interface without any implementation state. The class CustomerRole is a subclass of Customer and "decorates" a Customer object at runtime. The CustomerCore class implements the core of the Customer abstraction. We use Product Trader to create and manage role objects at runtime [1].

At runtime, instances of CustomerRole forward calls to the decorated Customer object [ILLUSTRATION FOR FIGURE 4B OMITTED], which is a CustomerCore instance. Clients work either with objects of the CustomerCore class, using the interface class Customer, or with instances of CustomerRole subclasses. By asking the CustomerCore object for a specific role, a client can obtain the respective role object. The Role Object Pattern allows the handling of a complex logical object spanning several layers as one coherent integrated object. Role objects from different business sections (e.g., borrower, guarantor, or investor) share the same CustomerCore object. Business section-specific role objects can be created on demand.

We view roles and classes as complementary domain-modeling concepts. Others have chosen to ban classes as pure implementation constructs (most notably [8]). For us, a role defines a context-specific view of an object. On this level, we have to distinguish between technical and conceptual identities. The entire logical object has an identity of its own, even though its role objects maintain their own technical identities.

Combining Roles and Frameworks. Using the Role Object Pattern enables us to locate a concept part and its implementation parts in different layers [ILLUSTRATION FOR FIGURE 3 OMITTED]. The concept framework of the Business Domain Layer consists of the Customer, CustomerCore and CustomerRole classes, as well as other core concepts such as Account and Product. Their implementation can be found in implementation frameworks of different Business Section Layers.

This organization of frameworks into concept and implementation parts [ILLUSTRATION FOR FIGURE 5 OMITTED] ensures that extensions to any business domain concepts can be made without reopening the concept part of a framework. If a new business section is to be supported (e.g., housing loans or foreign currency), a new layer with various implementation parts for the concept part of a framework is added to the system. Based on the added Business Section Layer, new applications and extensions of existing applications can be implemented without affecting other layers.

Changes to one business section concern only the classes in the corresponding Business Section Layer. If a new type of savings service is to be added to the investment layer, the implementation frameworks must be extended by a new product and a new savings account. None of other Business Section Layers will have to be changed.

Changes to the core concepts in the Business Domain Layer are the only ones that affect all other layers. A change in the classes Customer, Account, or Product will change all other layers [ILLUSTRATION FOR FIGURE 5 OMITTED]. However, changes to a stable and well designed Business Domain Layer do not occur very often. Such changes can only be caused by a major reorientation of the entire business strategy and services of a company.

Figure 5 is a simplified representation of the Gebos system's layers and frameworks. The Business Domain Layer does not consist of one framework only, but contains several of them [ILLUSTRATION FOR FIGURE 2 OMITTED].

Conclusion

As we have shown, frameworks can be categorized and layered to match their application domains and the business's organizational structures. We defined the categories business domain, business section, and application framework, and, based on these distinctions, showed how frameworks can be layered in order to manage their dependencies and reduce their coupling. We pointed out how to split a framework into a concept part and several implementation parts, and how to support this split by the use of design patterns.

A particularly important issue is building and maintaining logical objects that span several layers. We use the Role Object Pattern to adapt a core concept from the business domain to different business sections. Using role objects allows us to extend a core concept without having to change it, and thus without having to touch the business domain frameworks. The presented approach supports the development of frameworks and systems that are both stable and capable of evolving elegantly at different speeds.

1 RWG stands for "Rechenzentrale Wurttembergischer Genossenschaften"/"Wurttemberg Co-operative Bank Computer Center."

2 Gebos stands for "Genossenschaftliches Buro-, Kommunikations- und Organisation-system"/"Banking Co-operative Office, Communication, and Organization System."

REFERENCES

1. Baumer, D. and Riehle, D. Product trader. In R.C. Martin, D. Riehle, and F. Buschmann, Eds., Pattern Languages of Program Design 3. Addison-Wesley, Reading, Mass., 1997.

2. Baumer, D., Knoll, R., Gryczan, G. and Zullighoven, H. Large-scale object-oriented software development in a banking environment - An experience report. In ECOOP '96 (Linz, Austria, July 11-12). Springer-Verlag, Berlin, 1996.

3. Burkle, U., Gryczan, G. and Zullighoven, H. Object-oriented system development in a banking project: Methodology, experience, and conclusions. Human-Computer Interaction, Special Issue: Empirical Studies of Object-Oriented Design 2 & 3, 10 (1995), 293-336.

4. Gamma, E., Helm, R., Johnson, R. and Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, Mass., 1995.

5. Garlan, D., Allen, R., and Ockerbloom, J. Architectural mismatch: Why reuse is so hard. IEEE Software 12, 6 (Nov. 1995), 17-26.

6. Johnson, R. E. and Foote, E. Designing reusable classes. J. Object-Oriented Programming 1, 2 (June/July 1988), 22-35.

7. Lewis, T. Object-Oriented Application Frameworks. Prentice-Hall, NY, 1995

8. Reenskaug, T. Working with Objects. Prentice-Hall, NY, 1996.

9. Riehle, D. and Zullighoven, H. A pattern language for tool construction and integration. In J.O. Coplien and D.C. Schmidt, Eds., Pattern Languages of Program Design. Addison-Wesley, Reading, Mass., 1995.

DIRK BAUMER (baeumer@takefive.ch) is a research scientist at TakeFive Software, in Zurich, Switzerland.

GUIDO GRYCZAN (Guido.Gryczan@informatik.uni-hamburg.de) is a research assistant at the University of Hamburg, Germany.

ROLF KNOLL (rolf_knoll@rwg.e-mail.com) is the team leader for technical architecture at RWG GmbH in Stuttgart, Germany.

CAROLA LILIENTHAL (Carola.Lilienthal@informatik.uni-hamburg.de) is a research assistant at the University of Hamburg, Germany.

DIRK RIEHLE (Dirk.Riehle@ubs.com) is a researcher at Ubilab, the information technology research laboratory of Union Bank of Switzerland.

HEINZ ZULLIGHOVEN (Heinz.Zuellighoven@informatik.uni-hamburg.de) is a professor of software engineering at the University of Hamburg, Germany.
COPYRIGHT 1997 Association for Computing Machinery, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1997 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:object-oriented software development projects
Author:Baumer, Dirk; Gryczan, Guido; Riehle, Dirk; Zullighove, Heinz
Publication:Communications of the ACM
Date:Oct 1, 1997
Words:4012
Previous Article:Systematic framework design by generalization.
Next Article:Design guidelines for 'tailorable' frameworks.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters