(responding to Jo Crew)
> For reasons that are not important to the question, our > project has created a Use Case model and has received > code to match the model. The client part of our system is > written in Delphi and the server part in Java - both of these > have been reverse engineered into Rose to give Class > models - 365 components on the server side and over 1500 > on the client side to give some idea of scale. Our task now > is to fill the gap between the static Class model and the Use > Case model that we've created with some dynamic models. > Obviously this will be labor and time intensive - agreement > has been reached to 'freeze' the code in order for this effort > to take place. > > Has anyone ever tried to do this? Anyone have any > advice on an approach? Recommendations? Papers > (I've read the Rational Edge article)? I'd appreciate hearing > any input that might be relevant. First, get it clear in your own minds precisely what you hope to achieve by this exercise. A model is useful basically for 3 things... (1) as an aid to thinking through a current problem. (2) as an aid to communication of thoughts with respect to a current problem. (3) as a way of communicating with those people who are going to need to learn about the system in the future. I must assume that you need the models for this third purpose - you are freezing the code and not doing any development, so the first two seem to be ruled out. I must also assume there will be further development work - possibly enhancements, certainly maintenance, at some later stage. At some abstract level, the Use Case realizations will be fairly invariant. As long as the Use Case doesn't change, the domain objects that are needed to realize the use case won't change, and provided you don't need to redistribute responsibilties among these domain objects, the responsibilities of the domain objects that are accessed to realize the Use Case won't change. For this reason, I am going to suggest that you should limit yourself to describing the dynamics of the system at this abstract level, and do not attempt to describe the detailed dynamics. The detailed dynamics are a lot of tedious work, they are already described in the code, and they are subject to change as enhancements and maintenance work are carried out. You get a high-level road map of the system, sufficient to direct future visitors to the areas of code they are interested in. Assuming you take this advice, there are two approaches possible. I don't particularly like either. Other people may be able to suggest other approaches. First approach - model the domain/business objects independently of the reverse-engineered implementation level model. These domain objects form an analysis level model of the system, and abstract away all detail of design. Now map whatever the Use Case needs to do as interaction diagrams between the actors and these abstract business objects. Hopefully the interactions will match those that are implemented. Where they don't, either the code or the interaction diagram should be changed so they match up. Second Approach - use packages and controlled units, etc., to separate out implementation-level, design-level and analysis-level classes. Analysis-level classes should be those that represent meaningful concepts within the domain. Now show the key interactions that exist in the code and that realize the use cases in terms of these Analysis-level classes. The second approach is fraught with difficulties. In cases where analysis and design has dealt adequately with separation of concerns, the separation of classes into layers will be relatively easy. However in most cases, the concerns are inextricably entangled, and attempting this approach without running a massive refactoring program in advance will end in tears. Those few cases where I have observed good separation of concerns in code, already had analysis and design models available, so you would not be asking how to create them. Most likely, the interaction diagrams will be very disjoint, and to make any sense of them you would need to introduce more and more classes, and thus more and more detail that is subject to change. I hope some of this is of help to you; Good Luck. Paul Oldfield any opinions expressed herein are not necessarily those of Mentors of Cally ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * 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 *************************************************************************
