A re-engineering evaluation of Software Refinery: architecture, process and technology

Abstract

The qualiry of software re-engineering tools deperids on that of the generic environments used in their construction. Because re-engineering is extremely challenging, too rnitch so for full automation, generic re-engineering environment design criteria emphasise linguistic expressiveness and interaction with persistent repositories for program representations. Existing quality re-engineering environments, such as the Scftware Refinery, go a long way to satisfying these criieria, but fail to meet open systems criieria. One remedial approach is to recreate some of the functionality of these environments by modifying public donmin iechnology, but which runs the risk of limired interoperability and over-investnzent in devc~lopm~nt. 1: IntroductionThis paper has aims as follows: 0 to articulate, beyond the issues of first-order quality of specific re-engineering tools, the essential second-order infrastructure quality criteria for the design of re-engineering environments;to exemplify the importance of these criteria by analysis of a leading software reengineering environment: Reasoning Systems Inc.'s Software RefineryTM; to identify opportunities for improvement upon the interworking capabilities of existing environments (and by the way, their support for multiple very-high-level programming paradigms) by discovering open repository 0 0 implementations and facilitating the construction of different (meta-)language interfaces to them.In other words, we develop a general requirementsoriented framework for re-engineering tools assessment, and apply it to the assessment of Software Refinery and in the synthesis of possible altemative/companion technology. 2: Distinctive Re-Engineering Requirements, Architecture and TechnologyBy "re-engineering" [l, 21, we mean the full range of activities: code improvement or restructuring, i.e., eliminating coding standards violations by using better constructs, e.g. replacement of gotos with "structured" branches and loops; code enhancement, i.e., introduction of some new programming paradigm and consequent code restructuring, e.g. object-orientation; code conversion, i.e. translation from an old language and environment with limited maintenance prospects to a more modern one, e.g. COBOL and hierarchical databases to 4GLs and relational databases: design recovery, i.e., extraction of high-level specification and design information from implementation-level code; re-documentation, i.e., synthesis of comments etc. in un-or poorly-documented code.Rather than concentrating on subtle differences in emphasis between these facets (e,g, any distinction between code enhancement and design recovery begs the 0 0 0 0 191 0-8186-5660-3/94 $03.00 0 1994 IEEEquestion of what is "implementation" and what is "design"), more useful to us is recognising the essential conceptual unity of these various re-engineering themes.We posit that the single concept of "transition" -intcrlanguage translation (most apparent in code conversion) -actually pervades them all, as follows. Transition is a kind of metaprogr...

Towards an Intelligent Software Maintenance Network

“…As a result, software reverse-engineering tools used to support software maintenance have to facilitate the application of the maximum amount of intelligence to the design recovery problem, with specific technical implications for reverse-engineering tool development environments as follows (Atkinson et al, 1994).…”