> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, May 29, 2002 12:26 PM
> To: Jo Crew
> Cc: [unknown]
> Subject: Re: (ROSE) Reverse engineering legacy code
>
>
> (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.
>
Once you've answered this question, I would ask another one:
What are you going to do once you've completed the modelling
exercise?
(1) Keep the model for reference and update it as the code changes?
(2) Use the model to drive the future maintenance work?
(3) Refactor your code if the model indicates problems?
(1) and (2) will probably go hand in hand. My warning would be that,
unless you discover at the end of the exercise that there is not a lot of
architectural drift, it will be difficult to keep both models still in synch
even as new functionality is added or code is fixed. Given the sizes that
you quote, I'm not sure if it would be cost-effective to maintain the links,
in fact.
(3) can be expensive. Are you prepared for the surprise? If you do
not plan to spend more money to fix/refactor your model and code, the
initial expenditure for the reverse-engineering exercise may be wasted and
may help demoralise people by pointing out all the flaws they never knew
existed.
Am I optimistic today or what?
More coming up...
> 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.
>
I agree completely with this. The extra detail hardly ever pays for
itself. And it's much better to have a 100% correct but abstract model than
one that is 100% detailed but not quite correct. You'll spend a lot of time
reading a detailed model, but even more time verifying that what you read is
correct. In this case, more is less. Most detailed models end up as the
latter because either the will or the funds to maintain the correctness runs
out well before the model's useful life.
> 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'll propose a third approach of combining the two approaches:
Take the first approach and model the domain. Keep it short.
Absolute detail is not essential.
Then, take the second approach and use packages to split your
reverse engineered model into domain classes and those that are only
design/implementation artefacts. Use the first domain model to guide your
efforts in extracting this structure from the reverse engineered model.
Where there are mismatches, take note and fix. That may involve refactoring
your application or revising your use cases, depending on the situation.
At the end, you should end up with code that has less architectural
drift and meets the requirements better.
Intesrestingly enough, I spoke exactly about this with a client last
week. The question has been coming up more and more over the last couple of
years. It makes me wonder whether our ability to produce code is
outstripping our ability to model our requirements. I think we really need
to streamline the use case modelling approach if we want to avoid this
scenario of wasted requirements effort on one side and brand-new legacy
applications on the other.
Regards,
H�seyin Angay
Karabash Ltd.
www.karabash.co.uk
> 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
> *************************************************************************
This private and confidential e-mail has been sent to you by Egg.
The Egg group of companies includes Egg Banking plc
(registered no. 2999842), Egg Financial Products Ltd (registered
no. 3319027) and Egg Investments Ltd (registered no. 3403963) which
carries out investment business on behalf of Egg and is regulated
by the Financial Services Authority.
Registered in England and Wales. Registered offices: 1 Waterhouse Square,
138-142 Holborn, London EC1N 2NA.
If you are not the intended recipient of this e-mail and have
received it in error, please notify the sender by replying with
'received in error' as the subject and then delete it from your
mailbox.
************************************************************************
* 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
*************************************************************************
