schutten@prls.UUCP (Rindert Schutten) (06/01/90)
I am interested in re-engineering, transformation and porting PROBLEMS for *real* (commercal) applications from a practical point of view, i.e. what are the problems one encounters when an existing piece of software has to be ported to a different platform, operating system, language (dialect), window system, database etc. I therefore would like to hear from people who have practical experience, or can refer me to articles and or books on this subject. Actually one of the languages I think provides a rich source of problems is COBOL, since so much software has been written in it, so long ago. Similarly FORTRAN will probably provide the necessary problems. But also problems regarding other languages C, C++, ADA etc. most definitely have my interest, i.e. I am NOT restricting this request to particular programming languages. When I get sufficient response I will post a summary of the problems on the net, which will be beneficial for anyone I who wants to provide tools to alleviate the maintenance process. Rindert Schutten Philips Research Sunnyvale schutten@prls.uucp (pyramid!prls!schutten)
baxter@zola.ICS.UCI.EDU (Ira Baxter) (06/01/90)
In comp.software-eng you write: >I am interested in re-engineering, transformation and porting PROBLEMS for >*real* (commercal) applications from a practical point of view, i.e. what are >the problems one encounters when an existing piece of software has to be >ported to a different platform, operating system, language (dialect), window >system, database etc. >I therefore would like to hear from people who have practical experience, >or can refer me to articles and or books on this subject. ... We did a semiautomatic port, of a moderate size tool from one LISP dialect on a DEC-10 to another quite different LISP dialect on a VAX, several years ago. We did *not* change a single line of source code. The analysis and ideas that made the process work are documented in: @article(Baxter86a:transformational-model-of-maintenance, title = "{TMM: Software Maintenance by Transformation}", author = "Guillermo Arango and Ira Baxter and Peter Freeman and Christopher Pidgeon", journal = "IEEE Software", volume = 3, number = 3, month = may, year = 1986, pages = "27-39" ) A logical extension of the ideas appears to be presented in: @inproceedings(Ward89a:maintenance-by-backward-transform, title = "{The Maintainer's Assistant}", author = "M. Ward and F. W. Calliss and M. Munro", booktitle = "{Proceedings of Conference on Software Maintenance 1989}", address = "Miami, Florida", publisher = "IEEE Computer Society Press", month = oct, year = 1989, note = "ISBN 0-8186-1965-1, IEEE Catalog Number 89CH27441-1", pages = "307-315", annotation = {Describes the Maintainer's Assistant, a tool to help a maintainer understand and modify a given program. A wide-spectrum language is used to describe programs, mostly so that a formal denotational semantics can be given. The language has a simple core, with extensions defined in terms of the core constructs. A program to be maintained can have transformations applied backwards to convert optimized code into unoptimized code, or to convert a code fragment into a specification for that code; with the maintainer's help, a program can be backward engineered to a spec (a la TMM). Forward transforms can be applied to re-implement. Defines refinement of a spec1 to be another spec2 which terminates for each input state which spec1 terminates, and terminates in one of the possible (if spec1 nondeterministic [what a neat way to handle a random number generator!], or the only possible if spec1 is deterministic) states in which spec1 would have terminated. Claims that other systems \cite{Bauer78a} ``cannot cope with general specifications or with transforming programs into specifications.'' (p. 308) Suggest that his denotational approach is better than axiomatic approaches, where addition of axioms require consistency checks; Ward claims to have quite a library of proved transformations. Suggests that an interactive system is needed to that maintainer can guide the inverse transformations (i.e., no control!). He allows direct editing via a structure editor of the program source to introduce functional changes. There is a mechanism for recording the history of transformations and structure-edits that are applied, but it isn't clear what you can do with it. There is some mumbling about converting other programming languages into his special notation for manipulation, and contradictory mumbling about why he can't do that (C semantics too complex because of aliasing, for example). Claims work has started on a version to recover high-level specs of assembly code!}) I thought the following references might also be relevant: @article(Chikofsky90a:reverse-engineering-definitions, author = "Elliot J. Chikofsky and James H. Cross", title = "{Reverse Engineering and Design Recovery: A Taxonomy}", journal = "IEEE Software", volume = 7, number = 1, month = jan, year = 1990, annotation = {Quick introduction to reverse engineering, design recovery, and code restructuring (re-engineering). @article(Rugaber90a:recognizing-design-decisions-by-hand, author = "Spencer Rugaber and Stephen B. Ornburn and LeBlanc, Jr., Richard J.", title = "{Recognizing Design Decisions in Programs}", journal = "IEEE Software", volume = 7, number = 1, month = jan, year = 1990, annotation = {Discusses recognition of design decisions in existing code for the purpose of various types of maintenance. A discussion of how code instances realize various types of specifications and programming plans A sidebar discusses a port-by-abstraction for Cobol-to-Ada which sounds very much like our TMM paper.} ) Ira Baxter - ------- End of Unsent Draft ------- End of Forwarded Message