The year 2000 issue and the introduction of the Euro cause substantial software maintenance challenges. The importance of those events for the survival of organizations and the degree of impact on organization's existing software systems require the application of a mixture of already well known but also additional approaches and techniques. In this paper we are going to point out the major issues and possible approaches for their solution based on our experiences and observations from several industrial projects.

In 1999 and 2000, major business events such as European monetary union (EMU) and the Year 2000 problem will force organizations, in those situations where IT is critical to business survival, to set up and adequately fund relevant projects. The ability of the organization's IT departments to deliver timely and appropriate solutions will be critical to those companies. While most companies and governmental organizations can use a period until 2002 to become Euro-compliant, financial industries such as banks especially face an extreme time pressure, since they need to be Euro-compliant by the beginning of 1999. There is no single best technical or business approach to making a system Euro-compliant. Based on the current situation in each organization, companies must choose from a wide range of strategies and approaches with different costs and benefits. Our experiences in Euro projects have shown that the overall goal of a Euro-conversion project is to choose the most appropriate mix of technical and business solutions to implement timely Euro-compliance. Costs have been shown to be of minor importance in this context.

Component programming is a multiparadigm approach to software construction based on highly generic components. Because component programming is concerned with source-code components, it is assumed by many to be a low-level approach to software development that affects only the development of source code libraries. On the contrary, this paper shows that the concepts of component programming go beyond library and source code issues and define a new conceptual attempt to software development with generic components. We show that component programming is an architectural style that supports the building of classes of software architectures in a specific domain. Component programming can be applied in the early stages of software development when architectural issues are to be determined. All the benefits of using an architectural style, therefore, can also be gained by using component programming: it guides the engineer in the problem decomposition towards the design and implementation of a system. The paper presents the architectural style of component programming and the insights we gained about component programming as we tried to define it as an architectural style.

No abstract available.

Large software systems evolve slowly but constantly. In this paper, we examine the structure of several releases of a telecommunication switching system (TSS) based on information stored in a database of product releases. We tracked the historical evolution of the TSS structure and related the adaptations made (e.g. addition of new features, etc.) to the structure of the system. Such a systematic examination can uncover potential shortcomings in the structure of the system and identify modules or subsystems that should be subject to restructuring or reengineering. Further, we have identified additional information that would be useful for such investigations but is currently lacking in the database

Integrating application domain knowledge into reverse engineering is an important step to overcome the shortcomings of conventional reverse engineering approaches that are based exclusively on information derivable from source code. In this paper, we show the basic concepts of a program transformation process from a conventional to an object-oriented architecture which incorporates extraneous higher-level knowledge in its process. To which degree this knowledge might stem from some general domain knowledge, and to which extent it needs to be introduced as application dependent knowledge by a human expert is discussed. The paper discusses these issues in the context of the architectural transformation of legacy systems to an object-oriented architecture.

Whenever a reverse engineering method is applied to an old software system, the results are mainly limited to its degree of automation. Additional domain knowledge via a human expert helps to overcome this limitation. Modernizing old procedural software for object-oriented reuse requires domain knowledge as well us a balancing of the recovered information. We have developed a reverse engineering method for a gradual transition of procedural programs to an object-oriented architecture based on those aspects. This paper describes the balancing of the various generated models in our reverse engineering method and discusses this balancing in comparison to the balancing process in conventional object-oriented systems development. We also point out the links between these two engineering approaches. Furthermore the advantages of our reverse engineering process for reusability as well as maintainability of old procedural software based on object-oriented concepts are indicated.>

The authors describe a comprehensive approach that supports reuse in the software development process, especially the production of software from reusable components. For this purpose well-known strategies like reverse engineering and design recovery are combined with a generalization mechanism to develop the reuse engineering process. This process includes both the phase of isolating reusable modules from existing software and the phase of retrieving such modules from a software component library and combining them to new software. The definition of a reuse engineering life-cycle, which integrates reuse into the conventional software life-cycle is considered.>