No abstract

No abstract

Maintenanceraditional maintenance has proven difficult in the absence of design information [19]; maintainers often spend considerable energy trying to recover this design information before making changes [15]. Capture and reuse of certain kinds of design information should consequently improve the maintenance process. Updating the design information is as important as revising the software itself, for the revised design information is necessary for further maintenance. Four major software engineering efforts that ended in disaster precisely because trying to maintain their designs was perceived as impractical are described by [23]. Consequently, each design was abandoned and the projects spiraled into chaos.

Abstract

Abstract

Porting an1 v aintaining software with woe-* The original author was not available undocumented profully out-of-date design for consultation.documents-or none at allThe complexity of the task (and the grm without any is an unfortunate reality for many software desire to practice what we preach about source changes practitioners. As needs change, software reuse) compelled us to look for means of must be amended, or maintained, to adapt conversion other than manual reimdemonstrates the to the new environment. Often, such adap-plementation. Our problem was twofold:value of a transformra-tation involves porting programs from one (1) we had to determine what the code was tional theory of main-machine to another. If there is no informa-doing (leading to the idea of abstraction tenance. The theory , tion about original design decisions or recovery), and (2) we had to reimplement trance. aTne theory iS abstractions, the software becomes obso-it (here, we could use Draco, since it supbased on the reuse of lete, and the enormous resources invested ports a paradigm for the implementation knowledge. in its construction are lost.of software from components). Our portTo avoid this waste, we propose a ing effort proved successful. method that will allow practitioners to recover abstractions and design decisions that were made during implementation. General vs. domainThis method, called the transformation-specific languages based maintenance model, or TMM,1 is ' -'~After successful application of abstracnot just theory; it has enormous practical tion recovery, we began to develop the value as we proved when we successful value-as we proved when we succesfully TMM as a formal model of software mainported an undocumented, complex software system without any source changes. frlan ipulto of problem in formal manipulation of problem domain We developed the TMM as a result of 5 and software design knowledge. Hague our own software maintenance frustra-discusses the idea of a "super" language tions. During our research on the reuse of customized for the application domain. software engineering artifacts and knowl---~~~~~~~~~~~~~~~~~S uch a language would then map onto a edge, we relied heavily on a prototype s~~~~~~~~~r eal language. Hague claims that any gain system, called Draco.24 Because the com-in flexibility may be lost because the lanputer on which the Draco system was developedandopertedhad o b remved weguage may not compile on a real machine. oped and operated had to be removed, we Thus, he rejects the idea of a super lanwere forced to consider porting the system guage. The Draco paradigm suggests an to another operating environment. In other a t *alternative that makes compilation pOSSIwords, we had all the makings of a classic ble for domain-specific languages. We maintenance problem; namely,-maintenanc problem namthink the idea of a super language should * Other than technical reports and pub-be reconsidered-one for each domain. lications describing the conceptual F a aFollowing an approach similar to ideas behind the system...

No abstract

No abstract