Report on Assigned Reading2 – Evolution

By - Anju Gupta

University of Washington, CSE584 – Software Engineering

11/02/98

I found this paper very informative on software aging. One more reasons of the software aging not covered in the paper are the growth of the company. Few years back I worked in the MIS department of the company, the new employee hire rate for the company was around 200% every year. The software applications could be upgraded to some extent, but overall it couldn't keep up with its performance. Even with the experienced and knowledgeable software professionals in the department it was impossible to convince the management to invest in software solutions keeping in mind the growth of the company.

The Reflexion model is a technique by which a software engineer can quickly learn the existing system's source code without spending to much time or money. In this technique, the user defines a high-level model, extracts a source model, states a map, and then computes a reflexion model. Upon investigation of the reflexion model, the user may iteratively refine the inputs and recompute a new refelexion model. The paper then discusses how this technique was applied in experimental reengineering of Excel. The results of the experiment were very positive. The lessons learned were: Task-specific views are important; Graphical and text interfaces are needed; Explicit, declarative maps help task performance; Tools and process must adapt to the task. The success of the experiment was largely due to use of approximation.

It was enlightening to learn a formal technique in understanding a source code of existing systems. I found this task is to very tedious and times gets very boring. If possible, I have preferred to write new modules for a system rather than spending time trying to understand others code. I remember when I was asked to write reports on a 3^rd party client -server database. It was very difficult to understand the system as all the business logic was client level and the source code was not provided for it. The technique I used to understand this system was writing triggers on all the database tables. This helped me understand the system. Other techniques I have used to quickly understand others code are, adding print statements, step by step compiling code, reading design documents and talking to people with the knowledge on the system.

Restructuring a system is a complex, program –wide activity that is error – prone when performed manually. A meaning –preserving program-restructuring tool can be used during maintenance to change a program’s structure. Data Encapsulation is a commonly used restructuring activity because it simplifies modification by isolating changes to the implementation and behavior of an abstract data type. The paper then discusses program visualization, called star diagram. The star diagram helps detail information regarding encapsulation and supports the application of meaning-preserving restructuring transformations on the program through a direct – manipulation user interface. The visualization helps programmer to choose the functions that completely encapsulate it and to identify frequently occurring code fragments. With the help of design and example the paper concludes that the star diagram reduces the amount of information displayed and allows the tool user to focus on the task at hand. Other subject criteria that can be applied to a system when evaluating its structure are Coupling and Cohesion.

I found the paper little difficult to follow. Although example with the star diagram concludes with the positive results, I believe we in the real world are far away to accept such tools for our benefits. The reason could/may be the managers are looking for market proven tools due to time and resource pressures.

Reverse engineering is the process of first identifying the existing software system’s current components and their interrelationships and then extracting system abstractions and design information. The paper discusses techniques for discovering, restructuring and analyzing subsystem structures in software systems using Rigi, a system for reverse engineering. The stages of a subsystem composition methodology are discussed. Software structures such as control flow, data flow, resource flow, as well as aggregation and generalization hierarchies are often modeled by directed weighted graphs. Partite graphs, a special class of directed graphs are used to represent the structure of software systems. Resource-flow graphs and multiple subsystem hierarchies can be modeled using these layered graphs. The software engineering concepts of coupling and cohesion are the software composition measure for resource flow graphs. Low coupling among the subsystems and high cohesion within subsystems minimizes the number of paths through which changes and errors can be propagated throughout the system, and localized both change and impact analyses. The paper then discusses, the Rigi system, which is distributed, window based and has graph editor. Rigi system is used to discover, compose, explore, visualize and analyze layered subsystem structures. A 30-module software system is analyzed using Rigi system. The conclusion is composing subsystem structure cannot be fully automated however, subsystem composition methods are objective with respect to a given similarity measure, but usually take only one measure into account at a time.

The paper provided me with good information on reverse engineering. The case study covered by the paper was informative too. This paper help me do comparative study of Reverse Engineering and Re-engineering. In my experience, I have worked on a project where I was asked to re-design and code an existing Mac - Fox Base application to a new Windows - Microsoft Access database application. It was a small 4-5 people database; still it took me around two months to understand the existing system completely. A formal technique would have helped me understand the system faster and better.