Documenting legacy systems

[bsudhindra]

Hi all,

Is there anyone in the group who has experience in documenting legacy
applications? I would like to discuss certain approaches..

- Sudhindra

[freeman3101]

The documentation of legacy systems is a tricky one, since we are
trying to recreate a specification after the fact. It is almost like
drawing the plans of a skyscraper after it has been built without any
plans. The situation is often compounded by the fact that the original
developers of the system has moved on to bigger and better things and
cannot provide the insight needed for a proper analysis of the legacy
system.

Documenting legacy systems is almost like a fine murder mystery. The
thinking, motives and intentions behind many of the system features
and functions need to be deduced or assumed. Simple approaches to
documenting the legacy system may include the following techniques:

For the first Iteration:
Use case view
Use case diagrams may be developed from the menu structures of the
system. Different parts/modules of the system can be modelled as
separate packages. The menu options of those parts/modules can then be
modelled as the first cut use cases. Use cases will typically be named
with a verb and noun.
Actors can be found in the setup of all users to the system. Often by
examining the rights of users in the system additional use cases may
be discovered.

Logical view
Classes can be deduced from the use cases where the classes are
created from the nouns in the use case name. Operations may be deduced
from the verbs of the use cases as a first iteration.
Should the modelling tool used for the modelling of the legacy system,
support reverse engineering, you may also choose to reverse engineer
the tables into a class diagram. Bear in mind that this is a physical
model, and will not be directly related to the use cases created.
Reverse engineering the tables may be useful in understanding new
business entities that may lead to discovery of additional use cases
if the understanding is that a use case is needed to create, update,
read or delete an entity in the system.

Dynamic view
In the dynamic view we look at system behaviour. Unfortunately the
only way to properly document the behaviour would be to read code.
From the code abstracted sequence diagrams and/or activity diagrams
may be modelled. There are some tools available in the market that
will allow the reverse engineering of code to activity diagrams, but
in my experience this creates an activity version of the code which is
not terribly helpful.

Conclusion
In conclusion - it serves the modeller well to model the dimensions/
views defined above. It is important to review the different views and
ensure that the model is consistent across the views. Good luck!