Analysing code usage

ojfoggin wrote:
Hi Guys,
We have been migrating from an old system onto a shiny new GUI system for a number of years now and I am aware that there is potentially a hell of a lot of code that is now unused but still hanging around doing nothing.
Is there any way of anaylsing which programs aren't used (or which are used) so that I can work on how we can strip down any redundant code and reduce the size of our code?
Thanks for any help with this.
Oliver

Take a look at the-y, -yx, -yc, -yd parameters and the SHOW-STATS statement.

Or, just comment suspicious programs out and see who complains

-- peter

Or, just comment suspicious programs out and see who complains

Are you sure that’s feasible for large systems?

I haven’t used it myself (yet), but Joanju Analyst looks very capable of that. It lists which program is invoked from where (including resolution of dynamic programming constructs). So in theory it should as well be able to list programs that are not required anymore.

http://www.joanju.com/analyst/index.php

XREF might be another option.

Or, just comment suspicious programs out and see who complains

Are you sure that’s feasible for large systems?

I was being somewhat facetious (although I thought I'd 'smileyed' it); I don't think this is even feasible for small system.

If you're gathering information, you need to remember that certain code paths are only ever going to be exercised at certain times in the business cycle (year- or month-end).

So in theory it should as well be able to list programs that are not required anymore.

This approach will only show code that's not called/referenced anywhere. Sufficiently old systems will have swathes of code that's referenced somewhere, but never actually called in the course of the system's operation. For instance, when you have static code invoked from dynamic menus.

This conversation has the potential to go down a "Rumsfeld" route ... You have the code that's written and called and the code that's called but not written, and the code that's written and not called, and the code that's not written and not called.

-- peter

Analyst would certainly be a help, particularly if your code is full of dynamic calls, although I don't think John has done any dead code analysis features.  It might be possible to add that yourself, however.  The other alternative is to start with Analyst and add ABL2UML http://www.oehive.org/ABL2UML so that you would have an actual diagram of the code structure.  Since the UML diagram includes all the code to code and code to data links, it is a straightforward process to review for unused pieces.  It would also provide you with useful impact analysis to use in your migration.  In fact, if you used an OE database for the repository of the UML model, you can even write ABL queries to assist in your search.

In fact, if you used an OE database for the repository of the UML model,

you can even write ABL queries to assist in your search.

EA is great. But actually I do prefer to query the Enterprise Architect model using the automation interface. I do consider that like a business entity provided by Sparxx. I see a certain benefit for querying (let them know about the foreign key relations) and a large benefit for writing to the model. The automation interface does also provide certain validation of the data you are entering. I've wrapped the COM access in the data access layer of ABL business entities.

From an OO purist like you are Thomas, I'd have expected a preference for object access rather than direct database access.

I have used the -y approach with clients to log what actually gets run over long periods of time.

It isn't perfect and it takes some work to turn it into an actionable list of stuff to trim but it can be done.

I feel safe in predicting that any substantial code base that has been around for more than 5 years is at least 20% dead wood.

The automation interface is clearly preferrable ... *IF* you program in one of the applicable languages and are willing to learn the API.  One can build some clever tools that way.  However, for someone who is an ABL programmer only, my point is that it is possible to do some interesting queries based on the data structure, in particular one could identify code components with no links.

tamhas schrieb:
The automation interface is clearly preferrable ... *IF* you program in one of the applicable languages and are willing to learn the API.  

ABL is one of the applicable languages.

What difference does it make to use a built in ABL object / widget, an OOABL class that you don't have source code or a COM object that's well documented?

Ok you need to CREATE a COM object and can't NEW it - but that's the only difference. I didn't have any compability issues using the EA automation objects in the ABL.

Yeah, but Mike, you are fluent in the non-ABL side of that interface ... lots of ABLers aren't.

Were you to publish a bunch of ABL examples of how to interface with that API, maybe some of us would try that.  I sure would.

Were you to publish a bunch of ABL examples of how to interface

with that API, maybe some of us would try that.  I sure would.

I guess that's worth a chat when we meet in Rotterdam in a few days...

Sure!

I have a feeling that the amount of unused code from our "original" system is approaching the 50% mark.

I'll definitely have a look at the -y params and see what I can do with that first.

Thanks for the help!