Hi guys Good discussion about interaction diagrams and the connection to state machines. Just to straighten out some terminology, in UML - the "operation" is name, parameters and return value, while the "method" is the internals of the operation (algorithm or code). The "message" (on a sequence diagram) is indicated by the arrow, showing "The conveyance of information from one object (or other instance) to another" [UML Reference, Rumbaugh et. al, p333]. So the comment below about "Messages can be implemented as Method calls" should read " Messages can be implemented as operations" and so on. regards anthony > -----Original Message----- > From: Shields James [mailto:[EMAIL PROTECTED]] > Sent: 12 April 2001 08:21 > To: '[EMAIL PROTECTED]' > Cc: [EMAIL PROTECTED] > Subject: RE: (ROSE) Rose vs Together J > > > > Les > > (I got the name right this time.) > > 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. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 11, 2001 8:16 PM > Cc: [EMAIL PROTECTED] > Subject: RE: (ROSE) Rose vs Together J > > > > > 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. > > > > > > Shields James > > <jshields@cargolux. To: "'Johan Galle'" > > com> <[EMAIL PROTECTED]>, > > Sent by: [EMAIL PROTECTED] > > owner-rose_forum@ra cc: > > tional.com Subject: > RE: (ROSE) Rose > vs Together J > > > > > 04/11/2001 01:15 AM > > Please respond to > > 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 > > -----Original Message----- > From: Johan Galle [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 11, 2001 9:48 AM > To: [EMAIL PROTECTED] > Subject: RE: (ROSE) Rose vs Together J > > > > 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 > * > ************************************************************** > *********** > ************************************************************** > ********** > * 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 > * > ************************************************************** > *********** > > > > > > ************************************************************** > ********** > * 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 > * > ************************************************************** > *********** > ************************************************************** > ********** > * 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 > * > ************************************************************** > *********** > ************************************************************************ * 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 * *************************************************************************
