Ian Peake

Support for modular parsing in software reengineering

As reengineering increasingly contributes to software engineering, so can software engineering principles contribute to cost-effective reengineering tool development. The cost of modelling languages motivates support for modular parsers which can, like program modules, be assembled cheaply from smaller, tested components. We describe a scheme which achieves this by extending the expressive and flexible combinator parsing scheme using object-oriented constructs (class inheritance and dynamic method dispatch). Related schemes either do not fully support code sharing or sacrifice flexibility. The scheme has been implemented in a prototype reengineering environment and successfully tested on grammars such as Modula-2. The generation time for extensions is linear in the size of the extension. The run-time performance is potentially as bad as for general parsing algorithms, but can be linear (10 times slower than LALR for Modula-2) after optimization.

TOWARDS AN OPEN SOFTWARE CONVERSION ARCHITECTURE

A generic architecture for the development and application of software conversion tools exposes the requirements set for appropriate enabling technologies. Extrapolation of this set beyond its satisfaction by existing proprietary technology then exposes the opportunity/need for open interfaces between separate components providing orthogonal dimensions of the overall functionality. Some novel aspects of the solutions considered include retrofitting persistence to an open compiler-compiler, and using the Unix file system as a persistent object store, while in the background the advent of standard interfaces to persistence technology suggests that the overall goal is feasible.

A generic, knowledge-based re-engineering architecture

A generic architecture for semi-automated reengineering and conversion of legacy systems is motivated, devised, applied, and evaluated. The motivation for mere semi-automation (as opposed to full automation) is that perfectly automatic conversion is unattainable and that explicit attention should be paid to handling the residue gracefully. The architecture needs to satisfy a number of specific application-oriented constraints, and depends heavily on the Software Refinery metaprogramming environment for its realization.

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

The quality of software re-engineering tools depends on that of the generic environments used in their construction. Because re-engineering is extremely challenging, too much 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 Software Refinery tool, go a long way to satisfying these criteria, but fail to meet open systems criteria. One remedial approach is to recreate some of the functionality of these environments by modifying public domain technology, but which runs the risk of limited interoperability and over-investment in development.<<ETX>>

GRIT-an extended REFINE for more executable specifications

Knowledge-based software engineering (KBSE) languages should be as expressive as possible and should allow the reflection in executable programs of their non-executable specification origins. REFINE is the KBSE language for the Software Refinery metaprogramming environment. REFINEs expressiveness is extended with recursively-enumerable sets and parallel logical connectives. A subtype system was developed for the otherwise typeless functional language G, hence the name GRIT (G-REFINE InTegration) for this effort. The relationships between REFINE programs and original specifications is made possible by using the recursively-enumerable sets as the basis for a comprehensive system of run-time-checked assertions, which are subject to both set- and type-theoretic compositions.<<ETX>>

Towards an Intelligent Software Maintenance Network

The extreme difficulty of software maintenance means that specialised support tools are required. There are however potential disadvantages of inaccessibility and non-standard presentations. The presentation problem can be solved by interfacing intelligent maintenance tools to standard presentation environments, such as WWW hypertext browsers. This then poses the question: why not also use WWW technology to make intelligent maintenance tools more accessible?

Proprietary vs. "open systems" options in the construction of knowledge-based software reengineering environments

The quality of software reengineering tools depends on that of the generic environments used in their construction. Some existing quality reengineering environments, such as the Software Refinery, go a long way to satisfying their particular design criteria, but fail to meet general open systems criteria. One remedial approach is to recreate some of the functionality of these environments by modifying public domain technology, but which runs the risk of limited interoperability and over-investment in development. Our preferred approach however is to develop interfaces to general persistent object bases, to which bindings from existing languages, tools and proprietary environments can be made.<<ETX>>