The first question is should you be producing an OO representation of a non-OO (probably structured) system. If you are not going to make any changes to the non-OO system, but only use the legacy system with a new set of OO components, there is good reason to simply treat the legacy system as an actor in the UML context. Your new OO system, will have objects that fulfill the interface requirements of that actor.
Assuming that you are not going to refactor the old system, and that the non-OO system will be significantly changed, the usefulness of an OO/UML model of it depends a lot on the design rules that the non-OO developers used. Before there were objects, some software people were taught to use "abstract data types," which were data structures that were accessed via a strict discipline -- a set of access functions. Together, the data and the functions made up the abstract data type. Does this sound familiar? Sounds like an object to me. I've never done it, but a non-OO system written this way should be *very* translatable into logical class diagrams, at least. Even if the developers were not using a specific discipline like abstract data types, they were probably at least somewhat aware of coupling and cohesion. The idea was that subsystems in the system should be made of functions that have a minimal (emphasize minimal), well-defined interface with each other, and that each function should have one well-defined use. This approach tends to produce calling hierarchies of functions, with one holding most of the data structure definitions and business rules, and the others acting as services for sub-goals. In this second kind of non-OO system, you can visualize chosen data structures and their function hierarchies as objects. Obviously, this system is less convenient to visualize as objects than the system using abstract data types, so there will be a higher cost in analytical work, but it could be feasible if the system exhibits good coupling and cohesion. The common key in both of these situations is that the non-OO system is highly conformant to one design strategy or another. Portions of the system that bypass the design strategies will equate to very ugly objects, that you will find harder to visualize and harder to stomach, the more object-oriented you are in your own approach. Analyze the system according to whether you can identify a strategy for assimilating the whole thing to an OO model. Estimate the cost of doing the work for the strategy, and estimate high, because this will be unfamiliar work in the extreme. Consider the effect of investing your time and the risk of failing. -Eric Christel Geldenhuys wrote: > > I need to produce system documentation of an existing non-OO system, and I > am not sure whether I should use Rose (and UML) for this. > I can see that I can use use case diagrams and activity diagrams on a high > level, but would it make sense to use classes and objects (in class > diagrams and sequence diagrams) to document existing procedural code? > > I would really appreciate your comments ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * Only plain-text messages are supported. * HTML or Rich-Text messages may be rejected. * * Post or Reply to: [EMAIL PROTECTED] * Subscription Requests: [EMAIL PROTECTED] * Archive of messages: * http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * To: [EMAIL PROTECTED] * Subject: <BLANK> * Body: unsubscribe rose_forum *************************************************************************
