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>>

[1]  James H. Cross,et al.  Reverse engineering and design recovery: a taxonomy , 1990, IEEE Software.

[2]  P. J. Landin,et al.  Correspondence between ALGOL 60 and Church's Lambda-notation , 1965, Commun. ACM.

[3]  Robin Milner,et al.  A Theory of Type Polymorphism in Programming , 1978, J. Comput. Syst. Sci..

[4]  Graham Hutton,et al.  Parsing Using Combinators , 1989, Functional Programming.

[5]  Peter Henderson,et al.  A lazy evaluator , 1976, POPL.

[6]  Richard L. Piazza,et al.  Separating parsing and analysis in reverse engineering tools , 1993, [1993] Proceedings Working Conference on Reverse Engineering.

[7]  I. Peake,et al.  A generic, knowledge-based re-engineering architecture , 1993, Proceedings of 6th International Workshop on Computer-Aided Software Engineering.

[8]  L. Markosian,et al.  Automating software analysis and testing using a program transformation system , 1989 .

[9]  Lawrence Markosian,et al.  Automating the modularization of large COBOL programs: application of an enabling technology for reengineering , 1993, [1993] Proceedings Working Conference on Reverse Engineering.

[10]  E. Lohse,et al.  A Correspondence Between ALGOL 60 and Church's Lambda- Notation: Part I* , 1965 .

[11]  Paul A. Bailes,et al.  Full functional programming in a declarative Ada dialect , 1992, TRI-Ada '92.

[12]  John Hughes,et al.  Why Functional Programming Matters , 1989, Comput. J..

[13]  Simon L. Peyton Jones,et al.  Report on the programming language Haskell: a non-strict, purely functional language version 1.2 , 1992, SIGP.

[14]  Jean-Francois Girard,et al.  Reverse engineering of user interfaces , 1993, [1993] Proceedings Working Conference on Reverse Engineering.

[15]  J. Grosch,et al.  A Tool Box for Compiler Construction , 1990, CC.

[16]  Richard Mark Soley,et al.  Object Management Architecture Guide , 1993 .

[17]  R. S. Arnold,et al.  Software restructuring , 1989, Proc. IEEE.

[18]  Ronald Morrison,et al.  An Approach to Persistent Programming , 1989, Comput. J..

[19]  Brad J. Cox,et al.  Object-oriented programming ; an evolutionary approach , 1986 .

[20]  Robert Cartwright,et al.  Soft typing , 2004, SIGP.

[21]  D. A. Turner,et al.  Miranda: A Non-Strict Functional language with Polymorphic Types , 1985, FPCA.

[22]  Ivan Bratko,et al.  Prolog Programming for Artificial Intelligence , 1986 .

[23]  Richard S. Bird,et al.  Introduction to functional programming , 1988, Prentice Hall International series in computer science.

[24]  Paul A. Bailes,et al.  GRIT-an extended REFINE for more executable specifications , 1993, Proceedings of 8th Knowledge-Based Software Engineering Conference.