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
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
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
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
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.