FREE ELECTRONIC LIBRARY - Abstract, dissertation, book

Pages:   || 2 |

«Abstract Frameworks are a key asset in large-scale object-oriented software development. They promise increased productivity, shorter development ...»

-- [ Page 1 ] --

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 [4]). 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 (baeumer@takefive.ch) can be reached at TakeFive Software, Eidmattstrasse 51, 8032 Zurich, Switzerland.

Guido Gryczan, Carola Lilienthal, and Heinz Züllighoven (first.last@informatik.uni-hamburg.de) work at University of Hamburg, Germany.

Rolf Knoll (rolf_knoll@rwg.e-mail.com) can be reached at RWG GmbH, Räpplenstrasse 17, 70191 Stuttgart, Germany.

Dirk Riehle (Dirk.Riehle@ubs.com or riehle@acm.org) 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

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 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 [6]). 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. [9]). This can be compared to the MVC framework (cf. [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.

• 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. [6]) 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.

Pages:   || 2 |

Similar works:

«CITY OF TARPON SPRINGS CURRENT OPENINGS EFFECTIVE APRIL 21, 2016 Position: HUMAN RESOURCES/RISK MANAGEMENT COORDINATOR (REVISED) Department: HUMAN RESOURCES Annual Salary Range: $47,112 $75,900 D.O.Q. Closing Date: OPEN UNTIL FILLED Under limited supervision, analyzes, develops and implements processes involved with human resources and risk management functions. Position involves a broad range of responsibility and requires the ability to work independently with considerable latitude for...»

«TECHNISCHE UNIVERSITÄT MÜNCHEN Fachgebiet für Raumordnung und Umweltrecht Politisch-historische Analyse des Ressourcenmanagements im Benediktbeurer Klosterland von 1648-1803 Nachhaltige Entwicklung im Wandel der Zeit Maximilian Loy Vollständiger Abdruck der von dem Promotionsausschuss der Studienfakultät für Forstwissenschaft und Ressourcenmanagement an der Fakultät Wissenschaftszentrum Weihenstephan für Ernährung, Landnutzung und Umwelt der Technischen Universität München zur...»

«Masaryk University Faculty of Arts Department of English and American Studies English Language and Literature Hana Kaplanová Singular Narrative Techniques and the Specificities of Female Perspective in Short Stories by Katherine Mansfield Bachelor's Diploma Thesis Supervisor: Stephen Paul Hardy, Ph.D. I declare that I have worked on this thesis independently, using only the primary and secondary sources listed in the bibliography... Author’s signature Acknowledgement The inception of this...»

«IJIRST –International Journal for Innovative Research in Science & Technology| Volume 2 | Issue 05 | October 2015 ISSN (online): 2349-6010 Study of Impact on Car Bumper-A Literature Review Bilal Abdullah Baig Hakimuddin. A. Hussain M. Tech Student Assistant Professor Department of Mechanical Engineering Department of Mechanical Engineering ACET Nagpur, Maharashtra, India ACET Nagpur, Maharashtra, India Dr. A. M. Langde Professor & Head of the Department Department of Mechanical Engineering...»

«Dokumentation Technische Parameter Modell Agrammon Thomas Kupper, Harald Menzi Version 20.03.2013 1. Einleitung Die verwendeten Emissionsraten und Annahmen zur Wirkung verschiedener Einflussgrössen beruhen soweit möglich auf wissenschaftlichen Untersuchungen in der Schweiz. Wo solche fehlten, wurden Daten aus dem Ausland beigezogen. Sie wurden soweit möglich und sinnvoll auf die von der UNECE (Wirtschaftskommission der Vereinten Nationen für Europa) vorgeschlagenen Werte abgestimmt (vgl....»

«A Contribution to the Analysis of Maritime Accidents with Catastrophic Consequence Lusic Zvonimir M. Sc., Erceg Tonci Faculty of Maritime Studies Split, Croatia Zrinsko-Frankopanska 38, 21000 Split Phone: +385 21 380 762 Keywords: Maritime accidents, environment pollution, oil tankers, ship’s crew. Abstract Maritime transport safety is being enhanced by introducing numerous technical measures, by building safer ships, developing new and more efficient methods of transportation, investing in...»

«TECHNICAL REPORT AND RESOURCE ESTIMATE ON THE GREAT BURNT COPPER PROPERTY, CENTRAL NEWFOUNDLAND FOR PAVEY ARK MINERALS INC. LATITUDE 48o 20’ 28” N LONGITUDE 56o 09’ 06” W UTM WGS84 Zone 21U 562869 mE 5354553 mN; NTS 12A/08 NI-43-101 & 43-101F1 TECHNICAL REPORT Eugene Puritch, P.Eng. Jarita Barry, P.Geo. P&E Mining Consultants Inc., Report 297 Effective Date: January 12, 2015 Signing Date: February 18, 2015 TABLE OF CONTENTS 1.0 SUMMARY 2.0 INTRODUCTION AND TERMS OF REFERENCE 2.1 TERMS...»

«Designing Mobile Applications for Official Statistics Antonino Virgillito1 Istat – Istituto Nazionale di Statistica, e-mail: virgilli@istat.it Abstract In this paper we discuss the problems in the design of applications targeted at running on mobile devices, such as smartphones and tablets, and their usage in the context of official statistics. First we briefly survey the experience in this field at international level and discuss general design guidelines and techniques. Then we specifically...»

«Proc. 39th International Conference and Exhibition on Technology of Object-Oriented Languages and Systems (TOOLS-USA 2001). O2BC: a Technique for the Design of Component-Based Applications Rajeshwari Ganesan and Shubhashis Sengupta Software Concept Laboratory, Infosys Technologies Ltd., Bangalore, India { rajeshwari, shubhashis_sengupta } @infy.com Abstract Component-based development (CBD) has become a much talked-about subject today. While the technology of CBDas exemplified by environments...»

«Simulation in Produktion und Logistik Entscheidungsunterstützung von der Planung bis zur Steuerung Wilhelm Dangelmaier, Christoph Laroque & Alexander Klaas (Hrsg.) Paderborn, HNI-Verlagsschriftenreihe 2013 Methoden zur teilautomatischen Generierung von Emulationsmodellen Methods for a Semiautomatic Generation of Emulation Models Torben Meyer, Volkswagen AG, Wolfsburg (Germany), torben.meyer@volkswagen.de Steffen Straßburger, Technische Universität Ilmenau, Ilmenau (Germany),...»

«CURRICULUM VITAE I. PERSONAL INFORMATION 1. Full Name: Endawoke Yizengaw 2. Address: Institute for Scientific Research, Boston College, 140 Commonwealth Ave Chestnut Hill, MA 02467-3862 E-mail: kassie@bc.edu; Tel: +1 617 552-0146, +1 310 384-2195 Fax: +1 617 552-2818 II. EDUCATIONAL BACKGROUND  Ph.D. in space physics, La Trobe University in Melbourne, Australia: May 2004. Thesis Title: Imaging the Ionosphere.  M.Sc. in atmospheric physics, Tromso University in Tromso, Norway: May 1998....»

«From Linear to Interactive Animation: How Autonomous Characters Change the Process and Product of Animating BILL TOMLINSON University of California, Irvine There are significant differences between the art of animating for linear media such as film and video and the art of animating for interactive media such as computer and video games. In particular, these differences arise from the shift from linear characters to autonomous interactive characters. This article describes differences between...»

<<  HOME   |    CONTACTS
2016 www.abstract.xlibx.info - Free e-library - Abstract, dissertation, book

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.