Maybe a job for Summer Intern System Engineer keen to finding out what life
after College is really like.
Your right in that some of the clean-up is done when we run our model
checkout scripts which capture the dangling relations.
The hard one is where the dependencies have been deleted in the Model but
not in the diagram or where the association has been deleted in the Model
but not in the Graphic.
In discussion with our Senior Engineer, we came to the decision that we
what to find a way to monitor these conditions. Since we do Detail Design
prior to coding, changes like these need to be caught and sent through
design review to decide if the dependency/association should be dropped and
not allow it to just happen in the heat of the battle, ie process
controlled development.
Thanks for the discussion.
"Angay, Huseyin"
<Huseyin.Angay@egg. To: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
com> cc:
Sent by: Subject: RE: (ROSE) (M) search
owner-rose_forum@ra
tional.com
02/07/02 08:38 AM
Please respond to
"Angay, Huseyin"
I'm afraid I'm out of ideas. If Rose is being really ~helpful~ by stripping
out the classes that are not loaded, you may well be stuck.
One distant possibility:
Do many of these classes have associations? If the modellers haven't
committed the other cardinal Rose sin (spreading the associations outside
their package of origin), you might be able to enumerate through the
associations in a diagram and see which ones have roles whose classes are
not valid. I have this distinct memory of one of my scripts persistently
crashing when looking at some associations, which I traced to classes whose
controlled units had not been loaded. This method might not pick them all,
but it might give you some mileage, at least.
Otherwise, best of luck. Looks like a visual check may be your only
recourse. Do you have some brave office juniors keen to ruin their eyesight
for the good of the company?
H�seyin
> -----Original Message-----
> From: Ronald W Townsen [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, February 07, 2002 2:39 PM
> To: Angay, Huseyin
> Cc: [EMAIL PROTECTED]; '[EMAIL PROTECTED]'
> Subject: RE: (ROSE) (M) search
>
>
> Thanks for the reply.
>
> If you get all the ClassViews, you end up with a list of only the valid
> objects, Apparently Rose has already sorted out the offenders when it
> presents the list. From what I was able to learn from the support
people,
> when a Class diagram is drawn, the list of objects defined in the .cat
> file
> for the graphic is compared to the list in the model and those not found
> are labled with the (M). The .cat file contains a id number (not the
one
> referenced in the model) and when a class diagram is being drawn, any of
> these id's which can not be related to actual model id numbers result in
> the (M) being applied.
>
> What I need is that difference list. The normal functions as far as I've
> found, only return lists relative to the valid loaded model without the
> offending objects since there were eliminated during loading.
>
> I did investigate some of the model checking (which we periodically do)
> but
> again, they only report on objects existing in the model, not those which
> exist only on the diagram (dropped dependencies, association...).
>
> We've got a little more complex condition in that our model is under
> ClearCase control, all the controlled units are checked into ClearCase.
> With a model this large, we have multiple sub-model views into the
overall
> model and multiple controlled units in each sub-model (all under
ClearCase
> Control). I feel its the cost of being under version control and the
need
> for sub-model views that caused our problem, developers did not
> "check-out" all the controlled units when making updates so graphics were
> left with the (M)'s because the classes they refering too existed in
> different controlled units and the .cat file with the graphic had not
been
> checked out of clearcase.
>
> Your right, while having my focus on all the other topics needed to keep
> the developers going, I let this one slip through and now its coming back
> to bite me since this is a major portion of the documentation we have to
> deliver to our customer when done.
>
> Short of developing an automated way of stripping down a Class diagram
and
> rebuilding it, do you have any ideas on how they could be eliminated?
>
> I have been lucky in one sense, the Sequence diagrams can be validated
and
> I was able to create lists of invalid Sequence Diagrams and what needs to
> be fixed for the development team.
>
>
>
>
> "Angay, Huseyin"
>
> <Huseyin.Angay@egg. To:
> "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> com> cc:
>
> Sent by: Subject: RE: (ROSE)
> XMI/MOF support in Rose / XDE
> owner-rose_forum@ra
>
> tional.com
>
>
>
>
>
> 02/07/02 02:14 AM
>
> Please respond to
>
> "Angay, Huseyin"
>
>
>
>
>
>
>
>
>
>
> By (M)s, I suspect you mean the classes and associations that appear on
> the
> diagram but have not been loaded, because they belong to another unit
that
> is not loaded.
>
> Now, this is clutching at straws and I haven't checked it, but you might
> be
> able to do this:
> - Get all the ClassViews on the diagram.
> - Try to navigaet to their classes.
> - If you can't find the corresponding class, it hasn't been loaded.
>
> Alternatively, you might try to see if the class' package has been
loaded.
> (This works only if there is a corresponding class in the first place.)
>
> These Ms also appear when you have a view element but no corresponding
> model
> element -- i.e. somebody's deleted the model element but the diagrams
> where
> that model element appeared were not updated as their package had not
been
> loaded at the time of the deletion. The first method should definitely
> work
> for this. I think the check is:
>
> aClass = aClassView.GetClass ' or something like that. I haven't
> got
> Rose on this machine.
> IF aClass IS NOT NULL THEN
> aClass.DoWhatever
> ELSE
> ' Display the name of the ClassView here as it has no
> corrsponding
> model element
> ENDIF
>
> If I remember it right, "IF aClass IS NULL THEN" does not work. Or was it
> the other way round? Well, you'll have to experiment.
>
> The model checker at www.rationalrose.com does a pretty good job of
> checking
> stuff like this. Even if it doesn't do everything, it's a good place to
> start.
>
>
>
> To avoid the problem in the future, you need to be more proactive: you
> need
> to force your modellers to check out all the diagrams a class appears in,
> before doing a "delete from model". You might write a script that lists
> all
> the diagrams that a class appears in, for instance. I had a bunch of
these
> scripts a while ago, but they disappeared in the mists of the last
> century.
> Don't make it too easy for them, though: force them to look at those
> diagrams. You could write a script to check all those controlled units
> out,
> delete the class from the model, then check the controlled units back in;
> but that makes it too easy to get carried away with pruning jobs.
>
> All this sounds like a drag. Why the hell should you have to have to go
> through all these hoops just to delete a lousy class?
> Well, when you are deleting classes from a model, you should also be
doing
> some dependency management. If a class is referenced from another
diagram,
> there must have been a reason for it -- and if you think there is no good
> reason, you better make sure that others agree. We often get very
cavalier
> with classes on diagrams, whereas we would have thought more than twice
> about deleting a hundred lines of code even after some investigation.
> With 11,000 classes to manage, I suspect you will not disagree.
>
> Although Rose's controlled units are a clunky way of implementing a
> repository, most of the problems come from relaxed dependency management.
> When you stop Rose's controlled units from getting in the way, you've
> generally got your dependency management spot on.
>
>
> Good luck.
> H�seyin Angay
> Karabash Ltd.
> www.karabash.co.uk
>
>
> > -----Original Message-----
> > From: Ronald W Townsen [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, February 06, 2002 6:49 PM
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: (ROSE) XMI/MOF support in Rose / XDE
> >
> >
> >
> > Perhaps someone can help.
> >
> > I am working with a large Rose Model (~11,000 objects). I am trying
to
> > find some automated way to identify Class Diagrams with (M)'s so they
> can
> > be reviewed and updated by the development team.
> >
> > My main work is using VB Script to manage the model, but I'm flexable.
> >
> > In checking with the Rational Support group, nothing was found to
> provide
> > this type of feedback information.
> >
> > Does anyone have an Idea on how this could be done?
> >
> >
> >
************************************************************************
> > * 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 comprises Prudential 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. All members of the Egg group
> are registered in England and Wales. Registered offices: 142
> Holborn Bars, London EC1N 2NH
>
> 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
> *************************************************************************
>
>
>
>
************************************************************************
* 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
*************************************************************************
************************************************************************
* 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
*************************************************************************
