Johan
In response to:
<<James also says the confusion can come from the fact that,
often, events and operations will be named almost the same. Do you mean the
operation and its related call event? Or another event?>>
I meant Operation and the Event that triggered it, not another Event.
Your message is spot on, especially the request for better support for
Events in the tools.
James
-----Original Message-----
From: Johan Galle [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 12, 2001 10:59 AM
To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'; Shields James
Cc: '[EMAIL PROTECTED]'
Subject: Re: (Rose) Methods vs Operations and events (was Rose vs
Together J)
Les says:
- the arrows on "analysis phase sequence diagrams" are events (I assume you
mean a message, linked to a call of an operation causing a call event; I do
not see a UML rule that allows to link a message to any type of event)
- the arrows on "implementation phase sequence diagrams" are method calls
(you mean a message, linked to a call of an operation).
And let us add state diagrams:
- the arrows on a state diagrams are transitions, linked to an event that
could be a call event (leading to a call of an operation)
Why does Les feel we need one concept in analysis and the other concept in
implementation ? James also says the confusion can come from the fact that,
often, events and operations will be named almost the same. Do you mean the
operation and its related call event? Or another event?
We should validate all this theory about messages, actions, events,
activities, operations, and decide how we want to use it. An event right
now, means free text and no checks at all in most tools. Tools need to give
adequate support to the modelling activity.
This is an area where there are many different interpretations of using UML,
and modelers do not need this freedom here. They do want something clear and
understandable. So, I suggest to start providing some examples so that we
can sort this out.
And when we come to a conclusion, then let us summarize what tool support is
required:
- sequence/collaboration diagrams. Arrows can be signal sending or (most
importantly) the call of an operation. So, the way Rose, HAT, TogetherJ,...
support this, is fine. You can pick the operation.
- state diagrams. Arrows can be several types of events, a very important
one of them the call of an operation. I have never understood why Rose and
TogetherJ do not allow to select an operation here.
Johan
=========================================
Johan Galle, mailto:[EMAIL PROTECTED]
HOORA, the practical approach to UML: http://www.hoora.org
=========================================
> From: Shields James [mailto:[EMAIL PROTECTED]]
> Interaction Diagrams
> --------------------
> Interaction Diagrams show the Messages passed between Objects.
> Passing Messages can be implemented as Method calls.
>
> Is there really a problem here?
> For analysis, I just consider the Method calls to be the sending of a
> Messages between business Objects.
>
> Events
> ------
> As far as Events are concerned, these represent something
> that happens at a
> point in time.
> Events can trigger Operations on objects.
> (Operations can be Methods in the implementation.)
>
> This all used to cause me no end of confusion. I couldn't see
> the link.
>
> Actually, the link between Events and Operations is in the Actions and
> Activities, defined in the Statechart for the Class.
> The Event triggers an Action or Activity, which correspond to
> Operations of
> the Class.
> This is shown by stating:
>
> State A
> entry/ do this action or activity
> anEvent/ do this action or activity
> anotherEvent/ do this action or activity
> exit/ do this action or activity
>
> So, you are right where you say:
> <<Now I could put events as methods in my class, but this doesn't seem
> appropriate. Events are not methods, and I already use
> methods, so doing
> this will make my classes confusing.>>
>
> But, it is right to put the Operations (implemented as
> Methods) that are
> executed in response to the Event in your Class.
> I think the confusion can come from the fact that, often,
> these will be
> named almost the same.
>
> HTH
>
> James
>
> PS the clarification on the link between Events and
> Operations came from
> 'Instant UML' by Pierre-Alain Muller.
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> I have a comment about sequence diagrams that may go some way
> to answering
> a question from Johan about HAT.
>
> Sequence diagrams as implemented by Rose show method calls
> between objects.
>
> This may be adequate for implementation, but during analysis
> I want to use
> sequence diagrams to show the flow of events between objects.
>
> Now I could put events as methods in my class, but this doesn't seem
> appropriate. Events are not methods, and I already use
> methods, so doing
> this will make my classes confusing.
>
> So where are events described in Rose? The only place I know
> of is in the
> state/activity model attached to the class. What I need is
> the ability to
> drop down the events attached to the sending object when I
> draw a line on a
> sequence diagram.
>
> As it is I have to type in the event name and then do a
> manual check to
> make sure that events on sequence diagrams correlate to
> events generated by
> classes.
>
> Not really adequate for an analysis tool. Any suggestions?
>
> Les.
>
> P.S. My first comment is because I don't believe that HAT
> supports events
> on sequence diagrams either.
>
>
> From: Shields James
>
> Johan
>
> I entirely agree that you don't need phase 2 (as you call it)
> constructs
> when you are working at phase 1.
> So, you just don't use them at that point. You omit the details.
> However, you can use what you produce at phase 1 to go on and add the
> details at phase 2 (or you can start again).
>
> In general, I agree with our other point that at phase 2 UML
> diagrams may
> not be as effective as code.
> However, in some cases the picture, will make something
> apparent that the
> text does not.
> It is good to be able to get a picture of the code, with no
> extra effort,
> for when you are stuck.
>
> James
>
> From: Johan Galle [mailto:[EMAIL PROTECTED]]
>
> 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
*
*************************************************************************
