hiho,
Doh! Nope that is not what I'm saying.
Quoting the UML Spec???? That's my move! Awright, let me check your
reference... okay, I'm looking at figure 3-47... well, I gotta say some
aspects of this diagram don't make sense to me...
Let me first restate my original thoughts in light of your response. I'm
saying that the message "liftReceiver" should originate from Client and end
at CardReader. I am saying that a message ending at CardReader implies that
the CardReader class is expected to provide the liftReceiver operation. I
am saying this makes perfect sense since the person building the actual card
reader will have to make sure you can insert a card into it.
In looking at Figure 3-47 of the UML 1.3 spec, I keep thinking it looks more
like a data flow diagram than a depiction of collaborating objects invoking
each other's behavior. It shows "dial tone" as a message from Exchange to
Caller.
Maybe I am too operation-literal and I need to open my mind up to a more
signal-centric viewpoint. I have typically not modeled with signals, but
messages can represent either operations (as I was originally discussing) or
signals. Note that in Rose (standard Rose -- I can't speak for RoseRT) ,
there is no particular support for signals; each message is either an
operation or just a named message with no other modeling linkages.
If I was to examine the diagram you referenced, I suppose I could accept it
as s signal-centric view of what is going on. I moreso use sequence (and
collaboration) diagrams to identify and communicate the responsibilities
(typically implemented as operations) and relationships (typically links
turned into class relationships) required to support some behavior
(typically a use case). Therefore, I want to end up with an idea of "To
support the requirements I'll need these classes to support these operations
and have these relationships" (the basic goal of Use-Case Analysis).
------- b
--
Brian G. Lyons
Number Six Software - Voted Rational's Best Complementary Service Provider
1655 North Fort Myer Drive, Suite 1100
Arlington, VA 22209-3196
http://www.numbersix.com
-----Original Message-----
From: Chris Condos [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 23, 2001 8:59 AM
To: [EMAIL PROTECTED]; Rose Forum
Subject: Re: (ROSE) operations on sequence diagrams
ok, so you are saying that the message should originate from CardReader and
invoke the operation 'insertCard' which should appear on the Client class.
have a look at the UML 1.3 spec, page 3-99, figure 3-47. the Caller object
sends a message to the Exchange object to 'liftReceiver'. According to your
example the direction of the message should be the other way around (the
Exchange should invoke the 'liftReceiver' operation in the Caller class),
correct?
Chris
---
Chris Condos,
School Of Mathematical & Information Sciences,
Computer Science Subject Group,
Coventry University,
Priory Street, CV1 5FB,
Coventry,
UK
Tel: +44 - 24 - 76 88 8519
e-mail: [EMAIL PROTECTED]
----- Original Message -----
From: "Brian G. Lyons" <[EMAIL PROTECTED]>
To: "Chris Condos" <[EMAIL PROTECTED]>; "Rose Forum"
<[EMAIL PROTECTED]>
Sent: Friday, March 23, 2001 1:25 PM
Subject: RE: (ROSE) operations on sequence diagrams
| hiho,
|
| In a traditional, functional mindset a designer more often focuses on
"What
| should my unit do" and the actions of the unit in question are created as
| functions associated with that unit. In an object-oriented mindset a
| designer more often focuses on "What should my unit ask other units to do
to
| support what mine is being asked to do" and the designer more often
focuses
| on how utilizing the behavior of other units can support the needs.
|
| In a traditional mindset if a window had the responsibility to save
Customer
| data, it might have "SaveCustomer" as a function on the window. In an
| object-oriented mindset if a window had the responsibility to save
Customer
| data, it would ask the Customer to Save itself. So the sequence diagram
| would have a message from CustWindow to Customer labeled Save and the Save
| operation would be added to the Customer class. The Save operation is the
| responsibility of the Customer and might be accessed by many other
| collaborating client classes.
|
| This is a significant portion of the idea of distributing responsibilities
| in an OO system. It is less "I'll do it" and more "Can you do this for
| me?".
|
| In your example, someone is going to have to implement a CardReader (via
| whatever hardware and software mechanisms are required) that can support
the
| behavior implied by "insertCard". Now in your particular scenario you
have
| that behavior being requested by the Client, but the person responsible
for
| the CardReader component is the one who ultimately has to do implement
this.
| Another use case might have the MaintenanceWorker invoke insertCard to
| identify him/herself for the sake of some maintenance-centric use case.
| When doing that subsequent sequence diagram in Rose you would right-click
on
| the message between the MaintenanceWorker and the CardReader and select
the
| "insertCard" operation that had been defined in the first use case. Here
| this starts to pay off in speed and consistency of the model.
|
| ------ b
|
| --
| Brian G. Lyons
| Number Six Software - Voted Rational's Best Complementary Service Provider
| 1655 North Fort Myer Drive, Suite 1100
| Arlington, VA 22209-3196
| http://www.numbersix.com
|
|
| -----Original Message-----
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED]]On Behalf Of Chris Condos
| Sent: Friday, March 23, 2001 6:30 AM
| To: Rose Forum
| Subject: (ROSE) operations on sequence diagrams
|
|
|
| folks,
|
| I've noticed the following strange thing happening for quite sometime, and
I
| just wanted to see if someone else has some good explanation about it...
|
| say you want to produce a sequence diagram for the use case 'withdraw
money'
| (from ATM). so at some point you have your actor (Client) sending a
message
| 'insertCard' to the object CardReader. so the message arrow originates
from
| the Client actor and points towards the CardReader object. everything fine
| so far.
|
| however, when you then proceed to produce the class diagram for the model
| you will find that the 'insertCard' operation has been assigned to the
| CardReader class! why??
|
| to put it frankly, I don't understand why Rose assigns the operations to
the
| objects which receive the message and not the ones who originate it... any
| thoughts?
|
| Chris
|
| ---
| Chris Condos,
| School Of Mathematical & Information Sciences,
| Computer Science Subject Group,
| Coventry University,
| Priory Street, CV1 5FB,
| Coventry,
| UK
|
| Tel: +44 - 24 - 76 88 8519
| e-mail: [EMAIL PROTECTED]
************************************************************************
* 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
*
*************************************************************************
