Re: Code generation from CASE tools
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 12/19/03
- Next message: Roger Browne: "Re: Modularity without Abstraction is no more than Syntactic Sugar"
- Previous message: Val: "Daniel T."
- In reply to: Cristiano Sadun: "Re: Code generation from CASE tools"
- Next in thread: Cristiano Sadun: "Re: Code generation from CASE tools"
- Reply: Cristiano Sadun: "Re: Code generation from CASE tools"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 19 Dec 2003 19:31:10 GMT
Responding to Sadun...
>>[Ironically there is a very viable strategy for incremental legacy
>>replacement that is based upon the same sort of application partitioning
>>emphasized by translation. It is much more manageable and has lower
>>risk than conventional strategies like minimum-cut-set. However, the
>>vendors grew up in R-T/E so they are still reluctant to push it into a
>>new problem space.]
>
>
> Could you elaborate a bit on the strategy?
(1) Design the entire replacement system as if the legacy did not exist.
Be sure to provide good application partitioning.
(2) Select a subsystem in the replacement system.
(3) Build and test the subsystem from (2).
(4) Identify the corresponding functionality in the legacy system.
(5) Provide a decoupling Facade that allows the rest of the legacy
system to talk to the corresponding functionality and that functionality
to talk to the rest of the legacy code. IOW, artificially insert an
interface into the legacy code to isolate the functionality.
(6) Test the legacy code with old functionality encapsulated by the Facade.
(7) Excise the corresponding functionality from the legacy and
substitute the new subsystem. Use the Facade from (4) to talk to the
new subsystem.
(8) Test the legacy system with the new subsystem.
(9) If there are are unreplaced subsystems, go to (2).
There is no free lunch and incremental replacement of legacy code will
tend to be messy. What this approach provides is a systematic and
incremental approach to do so where each step is well defined, has
limited scope, and is manageable. In so doing it reduces risk, makes
estimating easier, and generally facilitates project management.
Through step (3) one completely ignores the legacy system. The goal
here is to get where one wants to be and that can only be done if one
doesn't repeat the mistakes of the legacy code. Good application
partitioning will ensure that the subsystem has a pure by-value data
transfer interface. That same disciplined partitioning ensures that it
can be well tested functionally -- certainly better than one could test
similar changes embedded in the legacy system.
Steps (4) and (5) will be a mess because of the spaghetti code in the
legacy system. However, this is a very limited task so it is quite
manageable and relatively low risk even though it will be messy.
Step (6) ensures that the functionality can be properly isolated and the
the Facade itself -- which is likely to be the most difficult thing to
get right -- is working properly.
Step (7) should be pretty simple if one has carefully designed the
Facade because of the disciplined nature of the new subsystem interface.
Nonetheless the Facade will probably have to modified. But, again,
this is limited task that should be manageable.
[Note that this strategy has nothing directly to do with translation.
However, it is enabled by applying good discipline to defining
application partitions and providing "firewall" subsystem interfaces.
The discipline to make this strategy a success is practiced routinely in
translation, mainly because of its R-T/E heritage.]
[BTW, I have a draft of a paper on this that I haven't gotten around to
publishing yet. If you would like a copy subject to the usual copyright
provisos, contact me off line.]
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH
- Next message: Roger Browne: "Re: Modularity without Abstraction is no more than Syntactic Sugar"
- Previous message: Val: "Daniel T."
- In reply to: Cristiano Sadun: "Re: Code generation from CASE tools"
- Next in thread: Cristiano Sadun: "Re: Code generation from CASE tools"
- Reply: Cristiano Sadun: "Re: Code generation from CASE tools"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
