Firstly, thankyou to everyone who sent examples of how to implement a solution to the Foreman/Worker problem. I am now enlightened.
The first lesson I learnt from this BIG question is that, if you're going to cross post a message to several users groups post to each one individually. Posting to several groups at once encourages multiple duplicate replies. Someone suggested that my problem is with the tools I'm using. I think it's pretty much agreed that the problem is with the UML notation first and secondly with those tools that implement that notation. I think that most people (not all) agreed that events are not methods. Methods are a possible way of implementing events. Events are messages that pass between objects allowing them to communicate. UML describes sequence diagrams as showing the messages being passed between instances. By allowing me to select from a set of methods in order to describe these messages is giving me a solution not the specification. (Ok, that's part of my tools problem.) An event is an instantaneous message passed from one object instance to another that may or may not contain data. I think a method call is the execution of a function that takes time to execute and includes a return to the original calling instance (I'm guessing here, so feel free to correct me.) Someone asked about returns to an event. I.e. supposing the originating instance needs to know the result of sending the event. The consequence of an object receiving an event is for that object to respond with either and action (otherwise know as Operation) or for that object to generate its own event, or any combination of the two things. So in order to inform the calling object of the action taken, the receiving object will send an event back in response. [As an aside: An interesting point that Mr Lahman, brought up is that by using messages to communicate, allows the receiving object to ignore the sent event in case that it is not in a state to respond to the event. I've often questioned if this is a good idea. Should an object instance be allowed to ignore an event that is sent to it? I get the impression that if this occurs then the system was not analysed properly, because a thorough analysis effort will consider every possibility of every event being received in every state and hence some sort of response will have been considered. See http://home1.gte.net/res0hbt4/documents/requirementsprocessstep0 9.pdf for an example of how I might do this. If interested in continuing this discussion I recommend we start a new thread.] Someone else pointed out that my Foreman/Worker events were not well named. I agree that event names generally should describe an event that has taken place, so they should be in the past tense. So instead of 'TakeABreak' the event same event would be more appropriately named 'BreakTimeStarted'. Operations, on the other hand, describe the action that is taking place and as such are written in the present tense. Just a point of clarification about terminology: as I understand it Operations are the actions that are taken in response to events and as such are the functional requirements on my system. Methods, on the other hand are the implementation of functions that satisfy the requirements of my system. (I encourage someone to start another thread on discussing the difference between Operations and Methods if interested.) So in my analysis model, I have Classes, which contain attributes, operations and a state machine that responds to events. Now the operations form the requirements on my system, so although they are not visible to other classes they are externally visible to someone reading the analysis model. A classes events though, are visible to other classes, but not externally visible to an external user. Events are the internal mechanism I use to put my classes together in order to make my system work. They are effectively a design solution inside my analysis model. As I think I suggested in the original posting, I could list my events in the operations/methods compartment of the appropriate class and add an <<event>> stereotype to the event name. All events would be given public access while operations ill be private. Personally I'm not convinced that this is the best solution and so.. The answer is, (and it was not me that originally suggested this, I'm just the messenger here) - A Proposal to the OMG, to add a fourth compartment to the class specification for listing events that can be accepted by that class. Just as current UML tools allow you to hide or display a classes attributes compartment or operations compartment, so it would be possible to hide the events compartment if you do not wish to use event message passing in your model. Again, I thank everyone who took the time to respond. Responses were very positive and I've probably got more education as a result, than any previous posting of mine. It's nice to talk about Object Technology sometimes. :-) Les. -------End of Message-------- P.S. I�m still unemployed and open to offers of money or beer in exchange for my services. Just send me an email, to [EMAIL PROTECTED] ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag ************************************************************************ * 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 * *************************************************************************
