close

Вход

Забыли?

вход по аккаунту

?

70

код для вставкиСкачать
Editorial
Nowadays, software development is being increasingly viewed as the process of creating families of systems instead of building individual applications. In domains such as telecommunications or logistics, application variants have to be produced to fulfil the changing
needs of widely different markets, comply with a great
variety of standards, and run on a broad range of platforms.
Object-orientation has often been promoted as the
most effective approach to master software variability.
Inheritance, late binding, and genericity make it possible to extend and customize software without having to
modify any existing code. It is this capability for incremental modification more than anything else that differentiates object-oriented languages from other modern
programming languages. While its benefits are apparent and largely recognized, this technology has also led
many software engineers to rely on incremental modification as an easy way to delay hard design decisions. This incremental modification syndrome is compounded by the fact that object-oriented analysis and design methods have so far provided little, if any, support
for evolutionary software development and reuse. The
results are systems overloaded with patches and workarounds, and exhibiting poor flexibility and adaptability.
When a reorganization ends up being inescapable, these
systems have usually become so large and are so widely
used that modifications are extremely time-consuming,
error-prone, and, thereby, very expensive.
Early adopters of object-orientation are already facing the challenging task of managing the evolution of
large, long-lived systems with little methodological or
tool support. For example, software engineers at Nokia
have to maintain object-oriented systems consisting of
over 10,000 classes and several millions of lines of
C++ code. In a sense, it can be said that legions of
C++ and Smalltalk—and now Java—programmers have
been diligently at work to develop the legacy systems
of tomorrow—with a productivity far exceeding that
of the C, Fortran, or Cobol coders of the past. Nowadays, engineering, telecommunications, and manufacturing companies are the hardest hit by this problem.
Given the pace at which all economic sectors are taking
up object-orientation, re-engineering object-oriented sys-
c 1997 John Wiley & Sons, Inc.
tems is quickly becoming a strategical consideration for
companies that rely extensively on this technology. The
banking sector, which has been investing significantly in
it for advanced financial services, and small and medium
sized enterprises, that have migrated to Delphi and Visual C++ from their earlier C, Basic, or Pascal environments, should experience similar difficulties in a not too
distant future.
The fact that applications must be re-engineered to
correct an inadequate design had been noticed quite early
on in the history of object-oriented programming. The
first proposals addressing this issue (mainly in the area of
object-oriented databases) were widely published about
ten years ago. Since then, several techniques have been
developed, though very few have been tested in real cases
[1]. However, the topic left its status of an arcane research theme only in the past couple of years. Workshops have been organized by the editors of this special
issue at OOPSLA in 1995 and 1996, and at ECOOP in
1997, gathering an attendance that has grown regularly
at each edition. The organization of a technical session
devoted to refactoring and reuse at OOPSLA’96 further
demonstrates that software evolution and re-engineering
is emerging as an important area in the object-oriented
community. It is in this context that Nokia, together
with Daimler-Benz (Germany), TakeFive Software (Austria), SEMA Group (Spain), FZI (Germany), and the University of Bern (Switzerland) launched “FAMOOS”1 in
1996, a project to elaborate practical methods and tools
for object-oriented software evolution, and to apply them
concretely to the re-engineering of very large C++ and
Ada systems.
Besides raising the awareness about the darker side of
object-oriented technology, the goal of this special issue
is to present solutions and ideas for the management and
reengineering of mature, large-scale object-oriented systems. The three contributions to the special issue highlight different facets of the problem, and provide original
approaches to tackle the problem of object-oriented software evolution.
Inheritance has many different uses in object-oriented
programming: conceptual specialization, subtyping, code
sharing [2]. The incremental modification syndrome is
closely related to the distinction between these concepts,
as resorting to incremental alterations instead of a more
comprehensive overhaul often leaves a system with grave
design problems unresolved. In his paper, Hernán As-
THEORY AND PRACTICE OF OBJECT SYSTEMS, Vol. 3(4), 233–234 1997
CCC 1074-3227/97/040233-02
tudillo shows how the various usages of inheritance can
be reconciled in a single conceptual framework. He proposes a technique to reorganize an inheritance graph that
achieves both optimal code sharing and clean conceptual
relationships among classes. His method draws on previous results from biological sciences and from type theory; the underlying idea of restructuring a class relation
along multiple dimensions simultaneously should open
new directions to the development of class reorganization algorithms—which has been a major field of study
in the area of object-oriented software evolution since
the very beginning.
In general, the transformation of a first-generation
object system into a flexible, reusable framework must
deal with all aspects of object-orientation, not just inheritance. In this context, reorganizations become much
more intricate, seemingly trivial changes such as modifying the name of a class can have far-reaching implications, and knowledge of reorganization strategies
plays a major role in the success of the re-engineering
process. The interactive tool described by Don Roberts,
John Brant, and Ralph Johnson in their article represents, therefore, a good example of the kind of environment that is needed to support re-engineering tasks
efficiently. Their refactoring browser provides a set of
common transformations that can be combined to form
high-level, complex re-engineering procedures. Special
routines detect the impact of changes and alter the software to preserve its behavior—possibly at run time,
should the extensive analysis and immediate modification of the source code be impractical. The refactoring
browser has found acceptance in the Smalltalk community, and is in use throughout industry and academia;
we hope that future generations of development environments for languages such as Java and C++ will have
browsers and programming tools extended with similar
refactoring facilities.
In contrast to corrective measures, preventive approaches cope with software evolution by providing software engineers with the knowledge required to build
object-oriented systems that are inherently adaptable and
maintainable. Such a knowledge is often formalized as
234
THEORY AND PRACTICE OF OBJECT SYSTEMS–1997
software structures, design patterns, or system architectures. In their paper, Kai-Uwe Mätzel and Walter
Bischofberger build upon this body of knowledge to
handle both anticipated and unanticipated changes during object-oriented design. The article classifies various
mechanisms to introduce flexible coupling in a system,
and provides guidelines as to their appropriate utilization. These mechanisms can also serve as targets for
re-engineering operations. The paper documents (partly)
the rich experience of the developers of Sniff and Beyond Sniff in building flexible frameworks, and should,
therefore, be a worthwhile reading for all object-oriented
software engineers and re-engineers alike.
Managing the evolution of object-oriented software
will probably always remain a hard, on-going process for
experienced software engineers. The contributions to this
special issue do not claim to bring a definitive solution
to this problem; nevertheless, they demonstrate that substantial progress has been made towards a comprehensive
methodology and scaleable tools that should ultimately
alleviate the pains of a growing number of developers
struggling with the maintenance of their object-oriented
software legacy.
Eduardo Casais
Antero Taivalsaari
Guest Editors
Notes
1. FAMOOS stands for Framework-based Approach for Mastering Object Oriented Software evolution. The project (No.
21975) is carried out in the context of the ESPRIT-IV
IT programme of the European Union, and described in
http://dis.sema.es/projects/FAMOOS.
References
[1] Casais, E. (1995). Managing class evolution in object-oriented systems, in Object-Oriented Software Composition, O. Nierstrasz and
D. Tsichritzis, (Eds.) Prentice Hall, 201–244.
[2] Taivalsaari, A. (September 1996). On the notion of inheritance.
ACM Computing Surveys 28(3), 438–479.
Документ
Категория
Без категории
Просмотров
0
Размер файла
33 Кб
Теги
1/--страниц
Пожаловаться на содержимое документа