From: wgg@cs.ucsd.edu (William Griswold)
Newsgroups: comp.object
Subject: Re: OBJECTIFYING STRUCTURED APPS
Date: 14 Oct 92 23:51:30 GMT
Organization: CSE Dept., U.C. San Diego

In article <1501@rand.mel.cocam.oz.au> mquinn@auzodt3.mel.cocam.oz.au (Michael Quinn) writes:
>
>To all comp.object and comp.software-eng  netters
>
>I have a dillemma
>
>Our division will be undergoing a gradual transition to an Object oriented
>philosohpy (appropriate to the project of course).  As part of 
>this transition is the "objectifying" of an existing system that was 
>built from the ground-up using the following
>	1 Structured Analysis and Design ( ER and DFDs )
>	2 Implemented in 4GL and SQL
>	3 Relational database
>	4 Screen forms definitions for user interface
>
>...  Note that we will also be enhancing this existing
>system to provide additional functionality.
>
>Another aim of the project is to develop a "library" of re-usable
>code and extract this from the existing system (one of the many aims of
>"objectification" !!!! ).
>
> ...
>	Is this approach fraught with dangers and pitfalls
>
>Personal replies would be appreciated to the address below and perhaps we
>could start a discusionn of "OBJECTIFYING STRUCTURED APPS"
>
> ...

William Opdyke recently finished his PhD at Illinois on "Refactoring
Object-Oriented Frameworks", under Ralph Johnson.  Also, Tony Davis
(ted@cs.brown.edu) is working on problems similar to yours in moving
programs from C to C++.

My own work, with David Notkin, addresses the problem of evolving the
structure of systems while their behavior evolves (but not specifically
evolving to another language).  Structural evolution is beneficial because
new concepts a system that deserve representation in the system structure.
Due to cost, time and complexity, these, unfortunately, do not evolve
hand-in-hand, leading eventually to structurally inadequate systems.

In investigating the enhancement process, the methodology I discovered
was that it is very advantageous to first *restructure* the system into the
desired structural form, without modifying the system's behavior.  Then,
*enhance* the system with the desired new behavior.  There are several
advantages to this:

	1) By separating structural from behavioral enhancement, each
	   is simplified, since their goals and methods do not become
	   intertwined.  The remaining points are actually a consequence of
	   this separation.

	2) After restructuring (and before enhancement), the system can be
	   tested without creating a new test suite (since behavior should be
	   identical).

	3) The significant tedium of restructuring can be automated because
	   the requirements (preserve meaning) are not difficult to encode
	   in a tool.  I have implemented such a tool for a Pascal-like
	   language.  The basic model is that the software engineer
	   describes a local structural (interface) change, and the tool
	   modifies the uses of those interfaces to assure that the same
	   data is passed and the same operations are performed as before.
	   This, in general, requires powerful data flow analysis or similar
	   techniques to be assured that the tool's compensating change is
	   sufficient to preserve meaning.  This does not mean that such a
	   tool has to be slow, however.

	   Even without a tool, such a methodology can be effective.  I
	   restructured by-hand a 5000 line C system in a couple of weeks.

	4) By restructuring first, the appropriate conceptual structures
	   are present to aid description of your enhancements, and each
	   behavior that will be modified or added can be localized
	   within a module.


I have successfully restructured (with my tool) a small program from a
functional decomposition to a data decomposition.  With such a tool,
the choice of the new structure and how to restructure it were the
primary challenges.

					Bill Griswold
					UCSD, Computer Science and Engr
					wgg@cs.ucsd.edu