homepage › Forums › BridgePoint/xtUML Usage and Training › Integrating xtUML Design Processes With Existing Legacy Code › Reply To: Integrating xtUML Design Processes With Existing Legacy Code
I’ve beat my head against this wall many times. :-) If nothing else, the practice of modeling can give a better understanding of the requirements and help identify possible re-factoring points.
Here’s some things I’ve done in the past:
1) Construct a domain chart for the system: this will help you identify the subject matters, but might not match the structure of the code.
2) Model a single subject matter domain and integrate it with existing code: this usually involves changing some existing code to better align with the domain boundaries. This works as either a code replacement or code addition task, but can be impossible if the code has really poor encapsulation.
3) Model a single subject matter as a way to document how the code should be meeting the requirements. If nothing else, this will give you a model you might be able to use at some future point when the legacy code gets too crufty. It also gives you a good point to design tests from; almost like having an independent test team working from requirements rather than your code.
I’ve never had any luck with auto reverse engineering. It either gave me a spaghetti model or a model that didn’t give much benefit over looking at the code. i.e., no abstraction.
The best path is to get buy-in from management and co-workers (also something I haven’t had much luck with), so you’re modeling effort isn’t viewed as wasted time. You’ll also get better help from subject matter experts within the company, if the effort is seen as value added.