Re-engineering of old systems to an object-oriented architecture.

handprintΛογισμικό & κατασκευή λογ/κού

18 Νοε 2013 (πριν από 3 χρόνια και 4 μήνες)

70 εμφανίσεις

Re-engineering of old systems to an
object-oriented architecture.
Ivar Jacobson
Fredrik Lindstriim
Objective Systems SF AB
Torshamnsgatan 39
BOX 1128
S-164 22 Kista, Sweden
Fax: +46 8 751 30 96
Most of our present-day information systems have
been in use for a long time. They have been developed
using the system development methods, programming
tools, data base handlers, etc. that were available when
the development work started. Even if the systems are
adapted to changed requirements from the surrounding
world, the basic structure and the original technical
and methodological ties have been retained. Our goal
is to show how an object-oriented development met-
hod can be used to gradually modernize an old system,
i.e re-engineer the system. We do this by showing how
three typical cases of re-engineering are related to
object-oriented development. The technique is based
on experiences from real projects.
The basis of our technology is system development
using object-oriented technique. The technology imp-
lies that occurrences from the application domain are
modelled as objects and associations between objects.
The resulting system model will be used as a mapping
between the occurrences of the application domain and
programming elements in the existing system.
Changes in the objects of the application domain can
be traced directly to the same objects in the model.
Different discussions about changes in the system will
therefore be more precise. For example, if a new type
of communication protocol shall be used, you can easi-
ly identify which program elements in the existing sys-
tem are candidates for a change.
More and more system owners face the following que-
The technique is founded on two assertions:
stions: How do you build a model of your system that
A change in the application domain is fre-
enables you to reason about modifications? How do
quently local in the sense that it concerns a
you gradually replace parts of the system? How can
behaviour or an occurrence with a clear deli-
you integrate a modern programming technique such
as object-oriented programming into an existing sy-
2. An object-oriented system model can be used
stem? This paper will summarize a technology that
to describe a system designed in a non object-
will answer these questions.
oriented manner.
Permission to copy without fee all or part of this material is
granted provided that the copies are not made or distributed for
direct commercial advantage, the ACM copyright notice and the
title of the publication and its date appear, and notice is given
that copying is by permission of the Association for Computing
Machinery. To copy otherwise, or to republish, requires a fee
and/or specific permission.
@ 1991 ACM 89791-446-5/91/0010/0340...$1.50
00PSLR91? pp. 330-350
It is generally unrealistic to replace an old system by a
completely new system; such a change requires too
much resources. You must find ways of gradually rep-
lacing older system parts without completely losing
the investments made so far. Our basic principle is that
an old system must be modernized gradually. Figure
[l] shows how changes successively can carve out the
original system. Eventually, the entire system will be
The rest of this paper is organized in the following
way. First, a presentation of re-engineering, its goals
and definitions. Next, we introduce a combination of
object-oriented system development and re-enginee-
ring. Third, experiences from three projects are presen-
ted. Last, a conclusion. Throughout this paper we
assume a familiarity of concepts like object, inheritan-
ce, encapsulation, analysis, and design.
All systems have a limited lifetime. Each implemented
change erodes the structure which makes the following
change more expensive. As time goes on, the cost to
implement a change will be too high, and the system
will then be unable to support its intended task. This is
Figure [ 11. We gradually want to replace an existing implemen-
tation with an object-oriented.
true of all systems, independent of their application
domain or technological base.
Before the system reaches this state something must be
done. Depending on its position in a changeability -
business value matrix one of four actions is possible,
see figure [2].
We will assume that the old system is difficult to
change but has a high business value, in this case we
choose to re-engineer the system. A system with a sa-
tisfactory degree of changeability or a low business
value either does not need the re-engineering invest-
ment or is not worth it. What then is re-engineering?
Re-engineering is the process of creating an abstract
description of a system, reason about a change at the
higher abstraction level, and then re-implement the sy-
stem. Re-engineering is subsequently defined in terms
--- I------
Discard 1
Business value
Figure [2]. Decision matrix, what to do with an old system
of relations between different levels of abstraction.
Intuitively and similar to (1), this can be expressed
with the following formula:
Re-engineering =
Reverse engineering+ A + Forward
The first element of t-e-engineering, Reverse enginee-
ring, is the activity of defining a more abstract, and
easier to understand, representation of the system.
The second, A represents change of the system.
Changes have two major dimensions, change of func-
tionality and change of implementation technique.
The third, Forward engineering (i.e normal system
development) is the activity of creating a representa-
tion that is executeable, e.g. finally a program written
in Smalltalk or C. Since the concept of forward engi-
neering is familiar to most readers we will not discuss
it further in this section.
2.1. Reverse engineering
The goal of reverse engineering is to capture an under-
standing of the behavior and the structure of the sy-
stem and be able to communicate this to others. To do
this we need at least the three following things:
A concrete graph that describes the compo-
nents of the system and their interrelationship.
An abstract graph showing the behavior and
the structure of the system.
A mapping between the two, i.e how somet-
hing in the abstract graph relates to the concre-
te graph and vice versa.
The abstract graph should be free of implementation
details. For example, mechanisms for persistent stora-
ge or partitioning into processes should not appear on
this graph . The concrete graph must, on the other
hand, show these details. The mapping between the
two should tell us how the ideal world of analysis is
implemented the way the concrete graph describes.
2.2. Change
From the perspective of re-engineering we classify
changes into two orthogonal dimensions, change of
functionality and change of implementation technique.
The first is the most common of the two but a change
of implementation technique seems to be in increasing
demand, see (2) and (3).
A change of functionality comes from a change of the
business rules. Thus, modifications of the busines rules
results in modifications of the system. Change of func-
tionality doesnt affect how the system is implemen-
ted, i.e how the forward engineering is carried out: an
end user of a system need never know if the system is
implemented with Smalltalk or C.
A new implementation technique of an information
management system could mean that the organization
will use C++ instead of C, or use an object-oriented
database management system instead of a relational
one. Needless to say, a change of implementation tech-
nique is not an easy process, even if there are tools that
can do part of the job automatically.
The dimensions are orthogonal in the sense that it is
meaningful to talk about changes in one without
changes in the second. We can change the functionali-
ty without changing the implementation technique and
vice versa. When only part of the system changes its
implementation technique it is necessary to enable
communication between the two parts. Different lang-
uages and operating systems are more or less supporti-
ve in this task, a basic functionality that must be sup-
ported is that an application can be called on request
from another application. (General reasoning about
this is found in (4)).
2.3. A small example
Let us consider an invoice system as a small and trivial
example to illustrate the process of re-engineering.We
assume that the only available description of the sys-
tem is a number of files of C-code and a database
description in SQL. The changes involve both
functionality and implementation technique. The
change in functionality is that two limitations of the
current system have to be removed. It only allows one
address per customer and a user can only work with
one invoice at the time. The change of implementation
technique will be to rewrite part of the system in C++.
The first step, reverse engineering, means that we
identify how the components of the system relate to
each other and then create a more abstract description
of the system. The relationships between components
are identified, e.g. the dependencies between the files
and the C-functions, the C-functions and the database
descriptions, etc. After that, an abstract description (in
the sense that we deliberately leave out implementa-
tion relevant information) of the system is created, e.g.
a dataflow diagram for the C-functions and an entity
relationship model of the database description. The
process of creating a more abstract description can in
theory be repeated as many times as necessary. Practi-
cally, it is enough with two levels (design and analy-
After the first step, we will have an abstract model that
shows the business rules of the invoice system and a
number of mappings between the different levels of
abstraction. Part of the abstract model represents how
invoices are regulated by the legal system, other parts
represent how the organization that once ordered the
system wanted the invoice system to work. The map-
pings comprise the design decisions that occur when
transforming an abstract representation to a concrete
The second step, reasoning about the changes in func-
tionality, is done at a more abstract level. Without the
abstract model we would have to reason with low-le-
vel non-problem domain concepts and make state-
ments like add one more table that contains the refe-
rences between customers and addresses. Instead, at
the higher level of abstraction, we can say change the
association between the entities Customer and Ad-
Next, we redesign the system from the abstract repre-
sentation to the more concrete representation, i.e for-
ward engineering. In this process we must take the
changes of implementation technique into considera-
tion. Since we only change the technique for part of
the system we have to answer the question Where
should the border between the old and the new system
be? When we formulate the answer we have to consi-
der what mechanisms there are available that make the
communication possible. When implementing the sy-
stem we also must take all recaptured design decisions
into consideration.
To summarize, when we re-engineer a system we
A representation of the system as it is, at
some level of abstraction.
A logical representation of the system, at a le-
vel that makes it possible to reason about
changes in functionality.
A way to capture design decisions, or knowing
why the system is implemented the way it is.
A technique that enables two different imple-
mentations to communicate.
A technique to delimit the part of the system
that we want to explore (without this it is im-
possible to re-engineer a large sytem)
3. Different scenarios for
re-engineering .
This chapter outlines a combination of object-oriented
system development and re-engineering. Since there
are many issues involved in the process we introduce
the necessary concepts one at the time using three dif-
ferent scenarios. Scenarios that can be combined in a
straightforward manner. We will describe re-enginee-
ring with:
A complete change of implementation techni-
que and no change in the functionality.
A partial change in implementation technique
and no change in functionality.
A change in functionality.
Complete re-engineering with no change
in functionality.
A complete change of implementation technique will
seldom occur for a large system. Nevertheless, we will
use the scenario to illustrate part of the re-engineering
process, namely reverse engineering and introduce
some concepts. Figure [3] shows an overview of the
transformation process. In the figure, the rectangles
describe different representations of the system. The
dark grey represents the existing system, the light grey
O 0 O
O0 \
Figure [3]. The figure describes how all of the old system is
transformed into an object-oriented implementation.
represents the analysis model, and the middle grey rep
resents the object-oriented implementation, i.e the
lighter a rectangle is, the more abstract it is. Rectan-
gles inside the existing system represent the primitive
description elements(defined in 3.1.1). Circles inside
the analysis model represent analysis objects. Rectan-
gles inside the object-oriented implementation repre-
sent design objects.
The main steps of the re-engineering process are:
1. Prepare an analysis model. Described in 3.1.1.
2. Map each analysis object to the implementa-
tion of the old system. Described in 3.1.2
Redesign the system using a forward enginee-
ring technique for object-oriented system de-
velopment. The last step of this re-engineering
scenario is to implement the analysis model.
This is achieved through a forward enginee-
ring process as described in (5).
3.1.1, me an analysis model
The first step, prepare an analysis model, requires that
we assimilate the existing information about the sy-
stem. The existing information has many different
forms, e.g. requirements specifications, user operating
instructions, maintenance manuals, training manuals,
design documentation, source code files, and database
schema descriptions. We call them here description
elements. An important subset of the description ele-
ments is the set of description elements that represent
the true system, e.g. source code or documentation that
is consistent with the source code, these are called
primitive description elements.
What is then a primitive description element? Natural-
ly, their nature depends on the quality of the documen-
tation. In the worst case, e.g. when we only trust the
source code, their granularity is on the level of met-
hods of a class.
D is the set of all description
DpntiliVC is a subset of D, where DRimirivc
represents a description of the system
that is consistent with the source code.
From the set of description elements we prepare an
analysis model, see figure [4]. This is done by using
the critetias for finding objects that are described in
the object-oriented method we use, e.g. see (5), (6),
(7), (8). The resulting analysis model can be regarded
as a graph, we have a number of analysis objects Ai
that are connected to one another with a set of directed
edges, E. The edges have different semantics in the
analysis model, but these are ignored at this stage
(they all imply some kind of dependency of the termi-
nal object).
Analysis model
of the system
Existing documentation
Figure [4]. Preparation of the analysis model.
The analysis model is represented by a
directed graph (A, E, f(ai , aj)).
A, the nodes, is the set of all analysis
objects identified from the description
elements, E is the set of all arcs
between the nodes, and f is a function
that associates an arc with an ordered
pair of nodes. The function represents
a dependency between the analysis
3. 1.2. Map each analysis object to the implemen-
ption of the old svstem,
Part of the reverse engineering process is to have a
mapping between the analysis model and the system.
We have two constraints on the analysis model:
All analysis objects must be motivated by at
least one primitive description element. We
can express that with is-motivated-by, a map-
ping from the analysis model to the set of pri-
mitive description elements.
For each analysis object A. there mus
exist at least one element D,,,, i such
that is-motivated-by(Ai,D,m,) exists.
All edges in the analysis model must be moti-
vated by at least one primitive description ele-
This is also expressed with
For each edge E, of the analysis
model, there must exist at least one
element D,.j such that
is-motivated-by(E,, DRimj) exists.
Also abstract analysis objects and inheritance associa-
tions can be motivated by description elements.
We use the analysis objects, the description elements
(both primitive and non-primitive), and the guidance
from the experts of the system to map the analysis
objects to the implementation of the old system.This is
comparable with the normal process of analyzing a
system, except for the vast amount of information.
After this step we have a situation as described in figu-
re [S].
Partial re-engineering with no
change in functionality.
,fXd system
Figure [5] All analysis objects and edges must be motivated
by at least one primitive description element. Note that they
also can be motivated by non-primitive description elements.
The goal is to make the object-oriented application be-
lieve that the whole system consists of objects, the
process is visualized in figure [6]. The thick arrows
symbolizes the transformations between different le-
vels of abstraction. The thin lines shows the communi-
cation between the object-oriented system and the
remaining part of the old system.
The main steps of this process are:
Identify the part of the system that will be
reimplemented using object-oriented techni-
Prepare an analysis model of the part to be
exchanged and its environment.
Map each object to the old implementation of
the system .
Iterate the previous steps until the interface
between the part to be exchanged and the rest
of the existing system is acceptable.
In parallel:
Design the new subsystem and its interface to
the rest of the old system.
Modify the old system and add an interface to
the new subsystem.
Integrate and test the new subsystem and the
modified old system.
Figure [6]. Part of the system is implemented with an
object-oriented technique. The thick arrows symbolizes
the transformations between different levels of abstraction.
The thin lines shows the communication between the
object-oriented system and the remaining part of the old
3.2.1. Identifv the Dart of the old system that will
be reimtAemented using obiect-oriented
Two subsets of DRimitivc are created. The first is D,,
which contains the elements that the new subssystem
exchange. The second subset is DEnv, which contains
the neighbours of D,. A neighbour is an element that:
isnt already included in D,.
is adjacent to elements in Dxin a dependency
graph, i.e either a terminal or a initial node.
Thus, there must be a graph that shows the dependen-
cies between the primitive description elements. The
graph is either implicit, i.e exists in the minds of the
technical experts, or explicit, i.e exists in a readable
form. In an ideal situation, we would like to have the
complete graph. However, due to the size of such a
graph we only make it explicit for the part we need to
A readable form is always preferable. Although advan-
ced tools and techniques exist, technical experts will
always make the task substantially easier.
A directed graph (DRimiliVC, E,, g(D,,
D,)) is created.
DRitilivc, the nodes, is the set of all
primitive description elements, E,is
the set of arcs between the nodes, and
g is a function that associates an arc
with an ordered pair of nodes. The
function represents a dependency
between the primitive description
3.2.2, Prenare an analysis model of the part to be
exchanged and its environment.
This step is similar to the corresponding step in the
previous scenario. The difference is that we only have
to concentrate our efforts of understanding the system
to a limited part of D. Thus, prepare an analysis model
representing the union of D, and D,.
3.2.3, Map each analysis object to the implemen-
I&ion of the old svstem,
We use the function is-motivated-By(x, DJ to map
the objects and edges of the analysis model to the ele-
ments in DRimitivc. We can then divide the analysis mo-
del into two subsets:
a) A,, which represents the part of the model that defi-
nitely will be implemented with the new technique.
b) A, analysis objects will serve as wrappers of the
old system. They represent objects that A, is related to.
3.2.4, Evaluate the interface between the part to
be exchanged and the remaining nart of
the old system,
When we have decided what part of the old system
that we want to change, we can create an interface be-
tween the new and the old system. At this stage, when
a better understanding of the old system is reached, it
is time to evaluate the interface, i.e we have to exami-
ne the partition of DRimitin. Through changing the set
Dx it is possible to get a set D, that, through DIPmv, gi-
ves a better interface between the old and new subsy-
stems. When we do this we have to repeat the previous
steps until we have an interface that is acceptable in
terms of implementation cost.
During the evaluation of the interface we must take
technical aspects in consideration, e.g. see (9) who
describes the technical problems that occurred when
an object-oriented language was built on top of an exi-
sting system. In general, most of these aspects arises
from the problem of communicating the state of one
instance between the new and the old subsystem. The
basic problem is atomicity of transactions, i.e no inter-
mediate states of the instance should be visible for its
clients. As a goal, the cut between the subsystems
should be made so that only one of them manages the
state of an object and works as a server to the other
subsystems. Despite this goal, implementation restric-
tions may make it unattainable. In that case, we must
allow multiple copies of the instance.
3.25 Design the new subsystem and its interfa-
ge to the old system,
The new system is implemented as the object-oriented
method prescribes. Objects in AEnv are implemented
with a set of classes that let the object communicate
with the old system, see figure [7].
Figure [7]. The objects half-b&ed in the interface encapsulate
the old system.
lnls way, me olher object; OK lhc application only sees
objects. The objects of A, behave like objects from
the new subsystem and like old software from the old
Thus, the encapsulation property of objects makes it
possible to successively move the plane further and
further into the old system. This way it is possible to
gradually replace the old system with an object-orien-
ted system.
3.2.6, Modify the old system and add an intex-fa-
ce to the new svstem.
In parallel, we have to modify the old system. All parts
that communicate with D, , i.e. calls procedures or
uses data in D, ,
are replaced. Instead of their original
code, they have to use the interface to the new system.
The set D, contains these parts. Also, we must modi-
fy the parts in D, so that a call or an access to them
results in an error. An activation of them means that
we have missed redirecting communication meant for
the new subsystem.
Re-engineering with change of
This scenario is a normal forward engineering process.
We add changes in functionality in the analysis model
and implement them using the object-oriented techni-
que. The result of this process is described in figure
The main steps of the process are:
1. Change the analysis model according to requi-
2. Design the system.
Only the first step is described, for a description of the
second see (5).
Figure [8] A change of functionality. In this case an addition
is depicted.
3.3.1. Change analvsis model accordinP to
We change the analysis model in accordance with the
requirements on changes in functionality. New objects
and edges are added as described in the normal for-
ward engineering process. Objects identified from the
old system either are deleted or receive new attributes
and edges. Thus, the resulting analysis model can be
partitioned into three subgraphs, one that contains all
the new objects, one that contains the changed ones,
and one that contains the unchanged. We then have
three different subsets of the analysis model:
A Ncw, which represents the new objects.
b) J%f& 
which represents the elements with a
new functionality.
A Nobtiac., which represents the elements not af-
fected by the change in functionality.
4. Case studies
We have used ObjectOry to re-engineer a number of
systems, including two major systems. The first sy-
stem was a military system for handling spare parts,
and the second system was a telecommunication sy-
stem. One of the others, a traffic control system is also
Our experiences with re-engineering come from using
ObjectOryTM (see (5)), an industrial software develop-
ment process. ObjectOry is a mature object-oriented
technique with many important features for supporting
the reverse engineering process. Particulary, one uni-
que concept of ObjectOry, use cases, have been an ex-
cellent tool for reverse engineering. Briefly, a use case
is a sequence of user interactions with the system. Its
purpose is to define a typical way of using the system.
In the context of reverse engineering, we explore an
old system with use cases. That is, together with an ex-
pert of the old system, the system analyzer identify a
use case. Then, they follow the use case through the
existing documentation of the system.
Another important aspect of ObjectOry is the separa-
tion of analysis and design. As a result of the projects
with re-engineering, our belief in this has been enfor-
ced. With an analysis model that clearly, without imp-
lementation details, captures the business rules of an
organization, it is much easier to understand and
change a system. The role of the design model is to
capture all the necessary modifications dependent on
the implementation environment. Today, all the sy-
stems we have reversed or re-engineered have only
been documented with at most a design model, They
have completely lacked an analysis model.
Before the project had started, the organisation respon-
sible for the system had planned to replace the whole
system at once. However, after evaluating the initial
results of the project they changed their minds. The
effort to replace the whole system was found too large.
Instead it was decided that a way of gradual replace-
ment must be found.
4.2. Telecommunication system
4.1. Spare part system
The goal of the first project was to demonstrate practi-
cally how an object-oriented system development met-
hod can be used when designing distributed informa-
tion systems. The example used for the work was
DELTA, a system for redistribution of stock. The sy-
stem is used by all defence branches in the Swedish
Armed Forces. The project was executed on assign-
ment from the Defence Materiel Administration FMV,
and our work amounted to about 4 to 5 manyears.
The re-engineering has been done down to class level
on a smaller part of the system that concerns spare
parts, for example customer orders and redistribution
of material between storage places. These functions
have been implemented in an object-oriented environ-
ment including an object-oriented data base.
We have also specified and implemented the changes
required to make the system a geographically distribu-
ted system.
The same DELTA system has been used in a parallel
study to demonstrate how a conventional, form-based
user interface in a terminal environment can be exten-
ded with window handling, graphics, and direct mani-
pulation in a personal computer environment.
The main categories of the description elements of the
project were:
database schemas
Cob01 code
user manuals
interviews with users and technical experts
The communication system was reverse engineered in
a small project of about 1 manyear. The original work
of the system was about 120 manyears and it was de-
veloped with an object-based technology. The purpose
of the project was to make an analysis model that will
be used to restructure the system. After the project, the
organisation responsible for the system estimated that
a complete reverse engineering process would take
about 10 manyears. Due to the understandibility of the
analysis model, they also concluded that the model
should make it possible to reduce the time to get expe-
rienced system engineers from 5 to 2 years.
4.3. Traffic control system
Basically, the traffic contol system involves three dif-
ferent systems. A resource allocation system, a traffic
control system, and a communication system. Histori-
cally, the traffic control system was developed first,
then the resource allocation system, and last the com-
munication system.
Related to figure [2], the traffic control system is the
most difficult to change, closely followed by the re-
source allocation system. But, the resource allocation
system has a high business value and it depends on the
traffic control system. Therefore, the company has
choosen to re-implement part of the traffic control sy-
stem and part of the resource allocation system. The
communication system is left untouched since its de-
gree of changeability is considered sufficiently high.
The project has both a partial change of implementa-
tion technique and a change in functionality. To get a
complete understanding of the three systems we stu-
died functions that spanned over all of the systems .
After that, we created an analysis model and its
motivations,see figure [9].
Resource allocation system Traffic control system
Communication system
Figure [9]. The delimitations and the objects of the trafic
control system.
The desired result is found in figure [lo]. Part of the
resource allocation system and part of the traffic con-
trol system will be implemented with object-oriented
technology. The change is that the new technology
will only be used for a part of the traffic control sy-
stem, the other part will be left out. Thus, we have to
create an interface between the different subsystems
and modify them accordingly. On the other hand, the
communication system will not be effected by any
changes and can be left as it is.
Modified Resource
Communication system
Figure [lo]. The desired result of the re-engineering of the
resource allocation system.
Based on these projects, we estimate that it requires l/
10 - l/20 of the total development time of the old sys-
tem to create an analysis model. That is, if the total
development time of a system is 10 manyears, the ana-
lysis model takes about 0.5 - 1 manyear to reverse eng-
ineer. Of course this figure is uncertain, but we believe
that the magnitude is correct.
The life span of an information system comprises spe-
cification, design and maintenance. The maintenance
phase dominates in time and often also with respect to
resources. During this phase the system is subjected to
a number of changes and additions. The gap between
the older technology in the system and the new techno-
logy that becomes available increases successively.
Changes in the activities of an organization also mean
that systems grow old.
Gradually the system approaches a limit where it no
longer is cost-efficient or even technically motivated
to continue the maintenance. But the cost of enforcing
the required changes is usually very high. This poses a
serious dilemma for system managers and similar per-
sonnel. A possible way out of this dilemma is to define
well delimited system parts that are candidates for
modernization. Provided this delimitation is made in
an efficient manner, replacement can be made with
moderate changes in the existing system. This is where
re-engineering can help.
We have described a practical method for re-enginee-
ring. The method is based on an object-oriented mo-
delling. We have described how the work can be divi-
ded into a number of steps from analysis to design and
finally design and testing, i.e. the method can be per-
formed in a systematic manner.
We have achieved the following: In a simple manner
and with limited efforts you can make a model of an
existing system. By means of the model you can rea-
son about where a change can be made, its extent and
how it shall be mapped on the existing system. The
new model is object-oriented and can serve as a basis
for a future development plan. The extensions can be
designed as additions outside the existing systems with
a minimum of adaptations in the form of interfaces.
Today, we think that the subject of re-engineering is
too focused on tools. Despite their importance they are
not sufficient. We think it is necessary to change the
focus of re-engineering to the complete life-cycle of
the system, i.e. try to incorporate re-engineering as a
part of a development process, and not as a substitute
for it.
In the long run, we want to industrilize reenginering
techniques so that they will
be incorporated as a part
of ObjectOry. We belive that Objectory has a good
foundation for this. Besides beeing object-oriented, it
is based on a mature forward enginering process (see
5). This means that a new system will
keep a high
degree of changeability.
6. References
(1) J. Chikovsky and J. H. Cross. Reverse enginee-
ring and Design Recovery: A Taxonomy.. IEEE Soft-
ware 1990;(January):13-17.
(2) Economist. How computers can choke compa-
nies. 1990 June 9:71-72.
(3) J. Duntemann and C. Marinacci. New objects for
old structures. Byte 1990 April:261-266.
(4) P. Zave. A Compositional Approach to Multipara-
digm Programming. IEEE Software 1989;(Septem-
(5) I. Jacobson. Object Oriented Development in an
Industrial Environment.. In: Proc. OOPSLA. Orlan-
do, Florida.: ACM Press, 1987: 183-191.
(6) P. Coad. Object-Oriented Analysis.Englewood
Cliffs, New Jersey: Prentice-Hall, 1990:232. (E. Your-
don, ed.) Yourdon Press Computing Series
(7) G. Booth. Object Oriented Design.Redwood City,
California: The Benjamin/Cummings Publishing Com-
pany, Inc., 1990:580. (G. Booth, ed.) The Benjamin/
Cummings Series in Ada and Software Engineering
(8) R. Wirfs-Brock, B. Wilkerson and L. Wiener. De-
signing Objet-Oriented Su@vare.Englewood Cliffs,
New Jersey: Prentice-Hall, 1990:341.
(9) C. Dietrich, L. R. Nackman and F. Grater. Saving
a Legacy with objects.
In: Proc. OOPSLA. New Or-
leans: ACM Press, 1989: 77-83.