Ben Kaizi-Lutu
CSE 584 Software Engineering
October 26, 1998
Reading Report 2 (Evolution)

R.W. Bowdidge and W.G. Griswold. Automated Support for Encapsulating Abstract Data Types. In Proceedings of the ACM SIGSOFT 1994 Symposium on the Foundations of Software Engineering, December 1994.

In general software systems are very dynamic and thus are subject to change. Continual modifications to large pieces of software tend to create hard to maintain code bases. Also after sometime it becomes difficult to apply changes in a safe manner without compromising program correctness. Eventually program restructuring becomes a necessity but in general is not a simple exercise. What is needed is a tool that can facilitate the restructuring process and ensure that resultant program has the same exact function as the original program. Simple traditional tools like grep are very limited in what they can do a more powerful tool is needed for such work.

A manipulable visualization program called the Star Diagram is presented. It supports the application of meaning-preserving restructuring transformations on the program using a graphical user interface. The Star Diagram doesn't fully automate the restructuring exercise but it presents information in such a way that a programmer's task of making restructuring decisions is significantly simplified. In restructuring a program one of the most common tasks is data encapsulation. This involves creating a new data type and encapsulating an old type in the new type. This gives us the advantage of isolating and localising changes to the program.

The Star Diagram is constructed using a program dependence graph (PDG) and an abstract syntax tree (AST). The Star Diagram is like a data flow graph. The nodes are operations and the edges are the data flows between them. Only the data flows generated by references to the data structure being encapsulated are shown and all references to a variable are denoted by a single node. By applying transformations to the graphical rendering of a generated Star Diagram, the program can easily perform data encapsulation and subsequently program restructuring. The Star Diagram has been proven to have good performance and to scale well

H.A. Müller, M.A. Orgun, S.R. Tilley and J.S. Uhl. A Reverse Engineering Approach to Subsystem Structure Identification. In Software Maintenance: Research and Practice 5, 4, pp. 181-204
(December 1993).

It has been twice in my career where I have joined a software development team and wished that there was more design documentation to help me understand the new system I was supposed to work one. In my experience, there is never enough design documentation. In the few cases that there is been any, it has always been outdated largely because as the implementation changed, the design documents were never updated to mirror the changes.

Techniques for discovering , restructuring and analyzing subsystem structures in software systems are presented. The strategy uses RIGI a system for reverse engineering which is a distributed, window-based, graph editor allowing editing ,maintenance and exploration of software objects. The RIGI system is used in a case study on a ray-tracing rendering system written in the C language. First a resource-flow graph (RFG) is generated and stored in a repository as a (k,2)-partite graph. The user can then interact with the graph structures using the RIGI editor to build subsystem hierarchies on top of the RFG and to finally compute exact interfaces. Therefore the reverse engineering process is not fully automated but is significantly simplified for the expert designer. The system has been used with great success on 57K line COBOL program and an 82K line C program.

D.L. Parnas. Software Aging. In Proceedings of the 16th International Conference on Software Engineering, Sorrento, Italy, 1994, pp. 279-287.

Unlike most other mathematical disciplines, software ages. Software ages both in correctness and in relevance. Aging is due to either the failure to modify software to meet changing needs or the result of changes to the software. As programs age they become bigger. It becomes a challenge just to be able to manage the size let alone manage modifications in a way that ensures program correctness. The original design ideas get progressively undermined as people come on to the project who are not well informed about the original design intentions. As programs become bigger they tend to run slower because of the increased demand on computer memory. Since the program is not well understood, changes may very well adversely affect performance due to the introduction of inefficient code. It has also been documented that in some cases an attempt to introduce code to correct a deficiency in a program generally introduces more than one error such that overall system reliability is gradually compromised.

To manage aging, we must "design for change" using object orientation also termed as information hiding, abstraction etc. Documentation of design must be a priority and there must be an ongoing effort to keep the documentation current. We need to be committed to a review process on the design preferrably by someone who will have along lasting presence on the project.

In some cases, deterioration has already happened to a great degree and the only thing that can be done is to slow it down. This can be done by recreating or restructuring the program. There is also room for retroactive documentation especially for areas that may seem to suffer most from degradation or cumulative complexity.
All in all aging is inevitable but we can plan for it, slow it down , work around it or restructure if we have to.

G.C. Murphy and D. Notkin. Reengineering with Reflexion Models: A Case Study. In Computer 30,8, pp. 29-35 (August 1997).

Reengineering of software can be costly and most times cumbersome. Reengineering with reflexion models is a technique that uses top-down and bottom-up approach to allow engineers to quickly isolate the systems they care about and to get information pertinent to these systems.

First off the engineer has to define a high-level model. This is a description of the various aspects of the system's structure that aid in reasoning about what they intend to do in the reengineering process. From the source code, the engineer extracts a source model using tools like a graph extractor. The next step is to define a map that describes how entities in the high-level mode and the source model relate. The engineer can now compute the reflexion model using the high-level model , the source model and the map. In the reflexion model, the engineer is able to see interactions in the source code from the view point of the high-level model. The exercise then becomes one of investigation and refining as the engineer progresses through the program.

A case study was performed in collaboration with a Microsoft engineer on Microsoft Excel a spreadsheet application of about 1.2 million lines of code. Results of the case study show great success in increasing understanding of the code base. It is not so clear wether the case study ever progressed to the
reengineering phase where as a result of the findings in the analysis phase, program modifications have been proposed.