SAS as a Legacy System

Software Engineering (CSC 175)

By Parag Jain

A Legacy System (or historic system) is a computer system or application program which continues to be used because of the cost of replacing or redesigning it and often despite its poor competitiveness and compatibility with modern equivalents. The implication is that the system is large, monolithic, difficult and expensive to modify. SAS is going to be a legacy system one day. It follows that we should prepare the system accordingly since that is going to happen -- it is essential that we structure the system in such a way that it becomes easier for future programmers to work with the system. We should look ahead for possible major changes in computing environments and platforms; there should be no problems in interfacing the system to other systems if we put an effort to make the compilers, etc. usable with the future versions of the operating systems. Not only this, there are other things that we should do also, here are a few of them -- encapsulate the current system because we want to move to a more modern computing platform; have a coherent system documentation, i.e. have a complete, consistent and up to date documentation so that the future users (system managers and end users) have something to refer to and get help from.

Another aspect that we should remember is understandability of the code -- we should try and make the source code for the system fairly easy to understand. A good way of doing this is by using JAVADOCS utility that creates a class hierarchy with descriptions of all the classes and methods used in the code, with the help of the comments provided in the source code. Also, we should remember that the control structures used in the system should not be too complex, and the variables should have meaningful names that reflect their functions.

All versions of all parts of the system should be managed by a configuration management system, and there should be an explicit description of the versions of components that are used in the current system. Apart from this, we should have some form of test data for the system available for future programmers and there should be an explicit data model for the system, i.e. extent to which data is duplicated in different files should be known. All of these will help the future programmer understand the system better and make him familiar with it. If we are not able to implement all of these techniques in the code due to time constraints (which is quite probable), we should put our best effort to incorporate as many of these as possible in the system.