Les,
I understand perfectly your problems. When I entered the OO world, I was always perplexed by the word "message". In ordinary language "message" means basically "passing of information", while in OO languages it means mainly "passing of execution control", usually by invoking an operation on the receiver of the message. In simple systems, most messages are synchronous, that is, control is given and returned when the invoked operation finishes. This may be confusing at first, since a synchronous message, represented as a one-way arrow, means passing of control in both ways (pass and return), as well as passing of information also in both ways (parameters and return values). Asynchronous messages are more like ordinary language messages, in the sense that there is no implicit return in the message: if you want a response, you have to send another asynchronous message back to the original sender. Messages are usually named after the operation they invoke on the receiver (there are exceptions, like messages to create or delete objects). This explains the behavior you have observed in Rose, and that you can find in other CASE Tools. An event in a statechart diagram may be raised, among other possibilities, by the invocation of an operation or the reception of a signal in the receiver. Roughly, invoking an operation corresponds to a synchronous message, and sending a signal to an asynchronous message. I don't think this is clearly explained in the UML documentation (and I may be wrong). In the same way as you name the message after the operation it invokes or the signal it sends, you could wish to name the event after the operation or signal that raises it. Then, you can have a mapping messages-events, being operations and signals in the middle. You reasonably ask for a CASE Tool to present signals as well as operations for default names of messages in sequence diagrams. Your proposal is good: list all events as stereotyped operations in the class model. The Standard offers no standard stereotype, but the Reference Manual suggests the stereotype <<signal>> or a fourth compartment after the operations compartment, named Signals, in the class box (p. 408). You ask, why you should at all show your operations (and signals) in your class diagrams. Well, I think a class diagram is not only intended to represent a data structure: it also contains indications about the possibilities of behavior of the system: what behavior you can expect from every class (operations, signals), and how can this behavior be requested to objects of the class (associations, navigability, visibility, interfaces, and so on). In this sense it is good that the diagram shows the operations and signals and, of course, it must be checked for coherence that the same operations and signals are present in the interaction and state diagrams of the model. Many CASE Tools do this task for interaction diagrams/operations, but I don't know of anyone that does a similar task for statecharts/events. I think Jean has already explained how you can get different behavior in your example, depending on time (in general, depending on the state of the receiver), with the same operation signature, so I won't insist on it. But I would like to comment another aspect. In his answer to you, Jean seems to think that the relationship sender-receiver is one-to-one in operation calls, and one-to-many in signal sends. I don't agree that this is the case in UML. The sending of a message is the result of an action in the sender object. In the UML metamodel, each Action specifies the target of the action by means of an object set expression which resolves into zero or more instances [UML Standard, version 1.4, page 2-120], so that, in principle, both for a signal and for the invocation of an operation the receiver may be a set of objects [Reference Manual, page 334] (however, the documentation sometimes suggests that the receiver of an operation call must be a single object, while the receivers of a signal may be multiple [Reference Manual, page 333]). Finally, I agree that, in general, operations (as well as attributes) should be declared private as a default option. Public operations are available to other associated classes, but this leaves the problem that we cannot distinguish easily between different groups of operations being declared public for different associated classes. Example: class A has operations x, y, z, and it wants to make x, y public for class B, and operations y, z for class C. Visibility levels are of little help here, and we have to use interfaces (which are exactly this, groups of operations). The use of interfaces should be the standard way to communicate with a class. But then, what is the sense of having publicly declared operations? Gonzalo ************************************************************************ * 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/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * * To: [EMAIL PROTECTED] * Subject:<BLANK> * Body: unsubscribe rose_forum * *************************************************************************
