Logo

Tool Support for the Transformation to Distributed Object-Oriented Systems


Tool Support for the Transformation

to Distributed Object-Oriented Systems


Ansgar Radermacher, Katja Cremer

Department of Computer Science III

Aachen, University of Technology

{ansgar,katja}@i3.informatik.rwth-aachen.de



Introduction


We are involved in a cooperation with two german companies: the Aachener und Münchener Versicherungs AG and the GEZ. The former is an insurance company, the latter a central institution in germany charging fees from TV viewers. In both companies the information systems are still based on a mainframe/terminal szenario. PCs are already in use, but not integrated into the systems other than via an IBM 3270 terminal emulator. The aim of the project is to examine means of a seamless migration process towards a distributed client/server system. The desired solution should be specific to an application domain, but embedded in a more general framework.

The software systems in both companies have been developed over the last two decades. Especially the older parts are considered as legacy applications, because the following statements hold:
  • the system is weakly structured - i.e. lack of separation, no abstract interfaces
  • documentation is poor or non-existent
  • distribution is almost impossible due to the monolithic system structure

Due to this reasons we want to re-engineer the legacy code, though it works (with known limitations) and fulfils mission-critic tasks. Distribution is becoming more important with the increasing power of workstations and networks. It offers the advantage that the capabilities of workstations CrRa96 can be effectively used in a client/server environment (here we use the term client to identify a specific personal workstation, in general we regard client and server as temporary roles of a program/process asking or serving a request, respectively). The re-engineering process should lead to a system with clearly separated components.

Strategy


The migration process of an existing system can be divided in different tasks/strategies ChCr90:
  • reverse engineering: comprises program analysis, comprehension, (formal) descriptions on other layers of abstraction - e.g. design recovery, re-documentation.
  • forward engineering: alteration of a subject system; we use the term re-engineering if both reverse and forward engineering is applied.

We aim to integrate these two steps in a common environment.

An important decision in a re-engineering process is the issue which parts of the system should be reused as a whole and which should be re-implemented. In general we want to reuse complex technical functions which are separated from the system from a logical point of view. Take for example the risk analysis in a life insurance system which might be wrapped to form a component of the new system (see distribution). Other parts of the legacy system, e.g. controlling functions, bear an implicit knowledge of the whole system structure and are often not flexible enough to adapt to a new system. In this case we want to extract ``knowledge'' from the exisiting code, for example a specification or a process net (There is the idea of reflection in the area of object-oriented systems: a system should have a representation of itself in order to ease adaption to a changing environment, see for example LoLi96).

The reuse of complete parts has a prerequisite: separation of functional distinct components. If we look at the risk analysis again, we will find that the associated code is, in general, not easy to separate or even to detect. The second form of reuse, the extraction of knowledge, also involves an analyse of the legacy code. Due to the complexity of the regarded systems both processes are only possible with tool support.

Tool Support


A multitude of tools that support reverse and re-engineering exist Arno93. These tools are not tailored towards a specific application domain (like CIM, business application systems, realtime systems etc.), but offer general functionality like the disentangling of GOTOs or the visualisation of the occurence of variables. These kind of tools commonly operate on program code level, change its structure or represent it in alternative style (for example: data flow charts, control flow diagrams, program slides).

Only few re-engineering tools to restructure a program system towards loosely coupled components are available Mako94. The extraction and separation process requires specific knowledge about the application area (and likely about the concrete application as well).

Distribution


The identification and separation of components was not only motivated by the idea to reuse parts. It is also a prerequiste for distribution, because the code can be wrapped (encapsulated) in an object.


Assume a structure in which communication is only done via interfaces, a technology to perform the actual distribution on a network of computers is still required. The network protocols and runtime support should comply to the standardized technology allowing the use of products from different vendors and guaranteeing interoperability in a heterogeneous environment. This technology is known as middleware, because it is located between the application and the underlying operating system. We will now have a closer look at the CORBA standard and its potential.

CORBA


The Common Object Request Broker Architecture is developed by the Object Management Group (OMG) since 1991. The goal of CORBA is to ease the creation of distributed, object-oriented/based applications. This is achieved by a uniform object model, in which each object has an interface consisting of operations. The invocation of operations is the only way to manipulate the objects internal state. The object model thus reflects the state of the art in most-object based and object-oriented languages without adhering to a specific language. The interfaces of objects are described in a standardized description language IDL (Interface Definition Language). The structure of CORBA is shown in figure 1. With the 2.0 revision of the CORBA standard OMG95, interoperability between the brokers of different vendors is addressed. Besides environment specific interoperability protocols, each object request broker must support the internet interoperability protocol (IIOP).

Image
Figure 1: CORBA

CORBA has a notion of object services. The services implement basic tasks which support the use and management of objects. The CORBA services, with their operation defined in IDL, are standardized in the Common Object Services Specification (COSS, OMG94). The OMG organizes the standardisation process by issueing a request for proposal (RFP) and evaluates the contributed submissions. The most important services comprise naming/trading, event management, life cycle, persistency and transaction.

The object services fulfil basic needs in an distributed system, higher services in CORBA are called Common Facilities. They are divided further in those facilities targeted for a horizontal and those for a vertical market. The former focus on general purpose tasks (e.g. user interface) the latter are specific for an application domain (say medical imaging).

Problems and Future Work


To sum up, CORBA is suitable to integrate components. The strict distinction between interface and implementation allows to exchange or add components that comply to a common interface. Application specific frameworks can be defined within the scope of the Common Facilities. However, this process has just started to gain momentum and there is no suitable framework for business applications yet.

Though the re-engineering tools we have in mind are specific to an application domain or even to a specific class of programs, they should comply to a common architecture and offer their services via an uniform interface. We are planning to use graph grammars to specify the operation of a re-engineering tool. The PROGRES environment -developed at our department- is able to execute a graph grammar specification in a generated prototype.

The re-engineering tools are ideally part of in an integrated development environment. It is desirable to model not only the applications, but also the environment itself as a distributed system, offering the possibility to dynamically incorporate the re-engineering facilities according to the developer's needs. Thus, the future vision is a light-weight and dynamically configurable environment.

References


Arno93
R.S. Arnold, Software Reengineering, IEEE Computer Society Press, 1993

ChCr90
E.J. Chikofsky, J.H. Cross, Reverse Engineering and Design Recovery, IEEE Software, Vol. 7, No. 1, pp. 13-17, January 1990

CrRa96
K. Cremer, A. Radermacher, Einsatz von Workstations bei der Restrukturierung von zentralistischen Informationssystemen, published in SIWORK '96, pp. 63-66, Hochschulverlag ETH Zürich, May 1996

LoLi96
C.V. Lopes, K.J. Lieberherr, AP/S++: A case study of a MOP for Purposes of Software Evolution, Proceedings of Reflection '96, April 1996

Mako94
L. Makosian et al., Using an Enabling Technology to Reengineer Legacy Systems, Communications of the ACM, Vol. 37, No. 5, May 1994

OMG94
Object Management Group, The Common Object Services Specification, Volume I, OMG Document 94-01-01, January 1994

OMG95
Object Management Group, The Common Object Request Broker: Architecture and Specification, Rev.2.0, OMG Document 96-03-04, July 1995

Created by: system last modification: Tuesday 30 of November, 2004 [11:45:04 UTC] by Sven