James,
Interaction diagrams can be used at different phases in the modeling:
1)Exploration in order to validate whether a particular set of classes that
the modeler has in mind would be adequate for some behaviour. Interaction
diagrams are a great way to move towards a good model. Details are omitted.
Specific scenarios are assumed. No loops or tests. A lot of text explaining
what happens.
2)Detailing the model to show exactly the sequencing of activities to be
done based on some trigger.
Here you need to show tests, loops, object creation, object destruction,
etc... I call this "graphical programming" and if there is a one to one
mapping possible between code and the sequence or collaboration diagram,
then UML is not adding any value, in my personal opinion.
Interaction diagrams are mainly popular for their phase 1 contribution.
I find
if (condition1) {
object.message1;
object.message2;
}
else {
object.message2;
object.message1;
}
a very concise description. I do not need to use phase 2 constructs for
that.
Johan
=========================================
Johan Galle
mailto:[EMAIL PROTECTED]
HOORA, the practical approach to UML: http://www.hoora.org
=========================================
> -----Original Message-----
> From: Shields James [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 11, 2001 09:23
> To: 'Francois Toubol (Private Mail)'; [EMAIL PROTECTED]
> Subject: RE: (ROSE) Rose vs Together J
>
>
>
> Francois
>
> I have replied to some of you points below.
>
> James
>
> -----Original Message-----
> From: Francois Toubol (Private Mail) [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 11, 2001 12:28 AM
> To: Shields James; [EMAIL PROTECTED]
> Subject: Re: (ROSE) Rose vs Together J
>
>
> James,
>
> I understand your approach. Nevertheless, there are some points to
> pounder here :
>
> 1. That's OK that with interaction diagram, as you
> say : "In the
> MyClass code there will be a line: otherObject.prepare();".
> You could also
> add that this line is in a particular method, which correspond to the
> message that triggered it. But the point is that my forward
> engineering
> motor could say "// consider here a call to
> otherObject.prepare()", and only
> that, because if I already have some LOC in my method, he
> couldnt know where
> to put the otherObject.prepare() method call.
>
> <<<< Personally, I would place the call where I thought it belonged,
> <<<< with a comment stating that it may not belong there,
> <<<< knowing that eventually (in the end), I would find its
> proper place.
> <<<< (I don't understand your comment around the word LOC.)
>
> 2. Also, as you mentioned, these diagrams involve
> "dynamic". Is to
> say, for eg., that a message may occur before another or at
> the oposite,
> depending on the runtime configuration. Is to say that in one
> scenario and
> from a same object, I will send message 1 and then message 2,
> and in another
> scenario and from the same object, message 2 and then message
> 1. And this
> cannot be traduced in code right? (code is not design :o) LOL)
>
> <<<< This isn't what I meant by dynamic.
> <<<< In your example, if you send message 1 then message 2 in
> some scenario,
> and the reverse in another,
> <<<< you must have something like:
> <<<< if (condition1) {
> <<<< object.message1;
> <<<< object.message2;
> <<<< }
> <<<< else {
> <<<< object.message2;
> <<<< object.message1;
> <<<< }
> <<<< This can be shown on the Interaction Diagram.
> <<<< i.e. it shows the TOTAL possibilities (as you say below)
>
> All is that in this optic interaction diagrams are
> reduced to function
> graphs. And more ever, Static function graphs that represent
> the great TOTAL
> possibilities diagram, rather than specific scenarios...
>
> <<<< I must admit I only use Interaction Diagrams for the TOTAL
> possibilities, rather than for specific scenarios.
>
>
> ----- Original Message -----
> From: "Shields James" <[EMAIL PROTECTED]>
> To: "'Francois Toubol (Private Mail)'" <[EMAIL PROTECTED]>
> Sent: Tuesday, April 10, 2001 03:07
> Subject: RE: (ROSE) Rose vs Together J
>
>
> > Francois
> >
> > In Java, sending messages is achieved by method calls.
> > So, messages on the interaction diagram are translated into
> method calls
> > between objects.
> >
> > E.g.
> > In the diagram, where(MyClass)myObject sends a prepare() message to
> > (OtherClass)otherObject.
> > In the MyClass code there will be a line: otherObject.prepare();
> >
> > Iterations, represented by *, become 'for', 'while' or 'do
> while' loops.
> > Conditions, represented by [], become if statements.
> >
> > When the number of objects created is dynamic, I believe
> you can configure
> > how many objects appear on the diagram.
> >
> > I know this is not a concrete example, but perhaps it helps.
> >
> > You could always go to www.togethersoft.com for a proper
> explanation.
> >
> > James
> > -----Original Message-----
> > From: Francois Toubol (Private Mail) [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, April 09, 2001 5:51 PM
> > To: Moin Ahmad; Vu, Hai; [EMAIL PROTECTED]
> > Subject: Re: (ROSE) Rose vs Together J
> >
> >
> >
> > Could someone explain me what is "to forward engineer
> interaction
> > diagrams"??
> >
> > Since they represent a sequence of message between
> objects (is to say
> > run-time), How can if be forward engineer?? Could you give
> a concrete
> > example of what does this does?
> >
> > Francois.
> > ----- Original Message -----
> > From: "Moin Ahmad" <[EMAIL PROTECTED]>
> > To: "Vu, Hai" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > Sent: Monday, April 09, 2001 09:05
> > Subject: RE: (ROSE) Rose vs Together J
> >
> >
> > >
> > > Does rose support code generation from interaction
> diagrams? together
> does
> > > but does rose?
> > >
> > > --moin
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Vu, Hai
> > > Sent: Monday, April 09, 2001 2:07 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: (ROSE) Rose vs Together J
> > >
> > >
> > >
> > > We are in the process of ditching Rose in favour of
> Together J. I have
> > been
> > > using Rose successfully for 5+ years for industrial C++ embedded
> software
> > > development. I have recently moved to a new company where
> most designers
> > are
> > > new to O-O and modelling tools. I was successful in
> introducing Rose to
> a
> > > small number of our developers (5-6). The feedback has been the
> difficulty
> > > at which proficiency is achhieved in using Rose.
> Furthermore there exist
> > an
> > > enormous body of legacy work that we would like to pull
> into our model.
> > Now
> > > my understanding is that the C++ Analyzer performs
> reverse engiuneering
> on
> > > C++ source code. The C++ Analyzer cannot seem to grok our
> legacy C++
> code
> > > for VxWorks (in fact after 5+ years of using Rose I am
> only recently
> able
> > to
> > > reverse engineer some simple stuff). After some tentative
> with Rational
> > > people I discovered that the C++ Analyzer actually
> attempted to compile
> > our
> > > code. What we want was something that sucks in our code,
> adds annotated
> > > comments, and spi!
> > > !
> > > !
> > > t it out in the model. We don't want it to compile our
> code, we don't
> want
> > > it to analyze header files that are #included inside our
> code (unless
> > > instructed to do so). This brings us to the Together J
> tool. The first
> > time
> > > I attempted to reverse engineer our legacy C++ code I was
> absolutely
> > > astounded to find Together J digested in a few seconds
> something that
> > caused
> > > the Rose Analyzer to go into cardiac arrest. After a week
> of use most of
> > our
> > > developers achieved the same proficiency in Together J
> that took others
> > > months to attain with Rose.
> > >
> > > Here is what I found after about a month worth of using
> Together J:
> > > + Together J is comparable to Rose in most modelling features,
> supporting
> > > use case modelling, class modelling, relationship
> modelling, interaction
> > > modelling.
> > > + Together J supports code gen from interaction model.
> > > + Together J supports design by pattern, i.e. you can pick from a
> handfull
> > > of predefined patterns and Together J populate your
> design with the
> > > foundation (classes) with which to build your design.
> > > + The Together J reverse engineering tool is a quantum leap beyond
> Rose's
> > > (the source code is the model!). There is practically no annotated
> > comments
> > > (you know, those annoying comments that Rose inserts
> everywhere in your
> > > code). As you change the C++ code you can see the model
> keep pace with
> the
> > > code change. Likewise changes in the model are reflected
> immediately in
> > the
> > > code, no code gen is required!
> > > + Together J has a much more user-friendly interface.
> > >
> > > - Rose is marginally more powerfull in that a few things cannot be
> > modelled
> > > in Together J and must be specified in the code. But
> these are small and
> > > most of our developers are more of the programmers variety than
> > architects,
> > > and they would rather work with code anyways (I am trying
> to change
> this).
> > > - Together J is written in Java and as such has an
> enormous run-time
> > > footprint, requiring the user to have at least 128Mb RAM (512
> > recommended),
> > > Pentium 233Mhz+. This may place it out of reach for most
> home system in
> > case
> > > someone want to work from home.
> > >
> > > Personally I would like to stick with Rose since I spent
> many years
> > working
> > > with it and that it supports a tad bit more C++ feature
> (Together J
> > started
> > > life as a Java tool for Java development). But Together has made
> > significant
> > > strides and I cannot argue with its ease of use and that
> most of our
> > > developers would vote for it over Rose. So basically I
> don't care what
> > tool
> > > we end up using going forward, I want one that best support our
> company's
> > > goal of churning out high quality product at break-neck
> pace, and on
> that
> > > front Together seems to have an edge at the moment.
> > >
> > > Hai Vu
> > > Mitel Networks
> > > 613-592-2122
> > > [EMAIL PROTECTED]
> > >
> > >
> > > -----Original Message-----
> > > From: Ryan C. [mailto:[EMAIL PROTECTED]]
> > > Sent: Saturday, April 07, 2001 9:50 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: (ROSE) Rose vs Together J
> > >
> > >
> > >
> > > Hi,
> > > Does anyone here use TogetherJ to develop their project?
> Why would you
> > > choose Together over Rose or Rose over TogetherJ?
> > > Thanks,
> > > -Ryan C.
> > >
> > >
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
