Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!uunet!mcvax!ukc!axion!jfoster
From: jfoster@zaphod.axion.bt.co.uk (john foster)
Newsgroups: comp.software-eng
Subject: Re: maintenance strategies/tools
Message-ID: <2134@zaphod.axion.bt.co.uk>
Date: 2 Aug 89 17:15:57 GMT
References: <217@ssp1.idca.tds.philips.nl>
Sender: news@axion.bt.co.uk
Reply-To: jfoster@zaphod.axion.bt.co.uk
Distribution: comp.software-eng
Lines: 102

From article <217@ssp1.idca.tds.philips.nl>, by roelof@idca.tds.PHILIPS.nl (R. Vuurboom):
> 
> A large institute here in Holland is looking at ways to document/channel 
> expertise for maintenance of very large transaction processing programs.  
> 	[ ... ]
> Due to programmer turnover and program size and inadequate documentation
> the usual maintenance woes are being felt.
> 
> The institute wants to "reverse engineer" to an adequate maintenance
> environment.
> 
> Does anyone have any experience with trying to "reverse engineer" to 
> a proper maintenance environment? (or know anybody who does?)

My group here at British Telecom Research Labs has a strong interest
in reverse engineering (as part of more general research into
software maintenance). We also have past experience of using reverse
engineering in the maintenance of switching system software. I hope
the following, fairly general, comments might be of some use.

> 
> What methods/strategies were employed?
> 

There are (at least) three broad strategies to consider:
1. Reverse documentation, involving the use of static analysis
etc to create information to help the maintainers
2. Reverse engineering, where you start with the code and
attempt to recreate the design/spec information
3. Re-engineering, where you perform step (2) and then recreate
the system from the new spec.
(BTW, I don't claim that my use of these terms is definitive).

Identifier cross-referencing is the lowest level of our
reverse documentation work, and we then build on that to
gain higher levels of documentation. Parts of that work
are described in:
Foster, J. R. and Munro, M. "A Documentation Method Based on
Cross-Referencing" Proc Conf Software Maintenance 1987, Austin,
Texas
Fletton, N. T. and Munro, M. "Redocumenting Software Systems
Using Hypertext Technology" Proc Conf Software Maintenance 1988,
Phoenix, Arizona
(John Foster is me; Nigel Fletton is another member of the
group here; Malcolm Munro is at the University of Durham (UK)
and runs the Centre for Software Maintenance there).
We have found reverse documentation extremely useful, even though
it can't tell you _all_ the things you want to know (like the
reasons behind design decisions).
This isn't a commercial plug, incidentally, because we are not
in the market as tool suppliers in this area.

Reverse engineering (as I define it here) is a more difficult
task, but there's a lot of interest and activity. A good example
paper is:
Sneed, H. M. and Jandrasics, G. "Inverse Transformation of Software
from Code to Specification" Proc Conf Software Maintenance 1988
The paper describes a system for reverse engineering from COBOL.

Re-engineering is the most expensive of the lot, but of course it
also offers the greatest potential gain. IBM have an interesting
project involving re-engineering via formal methods: see eg
Nix, C. J. and Collins, B. P. "The Use of Software Engineering,
including the Z Notation, in the Development of CICS" Quality
Assurance, vol 14 no 3, September 1988

> 
> What other tools did you use/can you get on the market for this sort 
> of work?
> 
There's a regularly updated survey on software maintenance tools,
published by Software Maintenance News, Staten Island, New York.
Sorry I can't quote the full reference right now, but their
phone number is (USA) 718-816-5522.

>
> I believe the current idea is to come up with some sort of "expert system"
> to handle (some of) the maintenance problems. I personally have my doubts
> about such an approach and would be glad to hear any positive or negative
> experiences/opinions in this (or related) areas.
>

I'm convinced that expert systems have a lot to offer, although these
are early days yet. But people are certainly talking about, and/or
experimenting with:
- systems to help users register their change requests (with
some problem analysis capability)
- systems to aid code analysis
- systems to aid people writing documentation
There are some papers in the proceedings of the software maintenance
conferences mentioned above, that give an idea of what's going on.

Hope this helps.


+--------------------------------------------------------------------+
| Who:    John Foster                                                |
| Where:  RT3151, Room G44C, SSTF, British Telecom Research Labs,    |
|         Martlesham Heath, Ipswich, IP5 7RE, UK.                    |
| Phone:  +44 473 646019                     Fax:  +44 473 643019    |
| E mail: jfoster@axion.bt.co.uk             Telex: 987137 (ISSEC G) |
+--------------------------------------------------------------------+