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
*
*************************************************************************
