RE: My BIG Question(long).



Date view Thread view Subject view Author view

J.A.Flower@bton.ac.uk
Mon, 26 Nov 2001 09:16:51 -0000


I hope I have understood your question - early on a Monday morning, it seems to be describing a choice of using event-driven programming versus directly calling operations on classes. One the one hand, the Foreman object generates an event, which the Worker object is listening for, and reacts to, and on the other hand, the Foreman object send a message directly to the Worker object (takeABreak()). Using events give great flexibility in a design - one of the plusses of EJB - the classes have low coupling, and a Foreman can function properly in the presence of zero or many Worker objects. The event-listener relation is many-to-many. The reason for using direct operation calls, in preference to event-handling, would be that if the design called for object o1 to trigger method m in object o2, then it's overly complex to handle this step using events. It also allows for situations which we might want to ban (like the absence of object o1, or the presence of multiple objects playing the role of object o1). Reasoning about the effect of a direct method call must be easier than reasoning about the effect of an event. So, I would say that direct method calls are simpler for small, controllable parts of an oo design, and event handling has great benefits for gluing together larger parts of the design. Jean. NB the code for Workers having breakfast lunch or afternoon tea would have to rely on a Worker object knowing the time - same for if the Worker responded to an event - and would go something like public void takeABreak( ) { if ( theTime.isRoughly ( new Time( "8.00am" ) ) { goAndHaveAFryUpAtTheCaff( ); } else if ( theTime.isRoughly ( new Time( "12.30am" ) ) { goAndHavePieAndChipsAtTheCaff( ); } else if ( theTime.isRoughly ( new Time( "4.00pm" ) ) { goAndHaveaCupOfTea( ); } }// end of TakeABreak method > -----Original Message----- > From: Les Munday [SMTP:baldrick@ureach.com] > Sent: Monday, November 26, 2001 12:51 AM > To: otug@Rational.Com; puml-list@cs.york.ac.uk; rose_forum@Rational.Com > Subject: My BIG Question(long). > > The reason why I named this message my BIG question is that > this issue has been bothering me for years. It's only recently > that I've understood the issue fully enough to be able to make > an argument for either side of the question. > > This question comes about as a result of me trying to integrate > a Shlaer/Mellor type process into UML modeling tools (Rational > Rose to be specific, which is why I am posting this to both the > OTUG and Rose forums). > > [If you are not familiar with S/M or if you want to see what > S/M looks like when implemented on Rose, take a look at: > http://home1.gte.net/res0hbt4/html/Process.htm > where I give a very simple example of a system design in Rose, > but using a S/M type process to analyze the requirements.] > > Let me start phrasing my question by giving a possible solution > to my problem. > > Answer: "All class operations should be private to the class > that implements those operations, no class should be able to > directly access the operations of another class." > > [Is this a radical statement, or have I just re-stated > something that is already well known in the OO world?] > > I'm going to assume that this is a conclusion that most OO > programmers would not agree with, so I'm going to have to put > forward some pretty strong arguments to justify this statement. > > My arguments are based on the knowledge that my background is > Shlaer/Mellor and that S/M is a process that was derived > topdown, as apposed to something like Booch or Rumbaugh whose > methods were driven by existing OO programming languages (C++ > in the case of Booch, for example). > > My problem first arose when I came across the need to draw > sequence diagrams in Rational Rose. In the S/M method there is > a diagram called the OCD that is used to show the external > event flows between classes and 'actors'. This diagram is not > supported by the UML, but I figured that I could use the > sequence and collaboration diagrams supported by Rose to derive > the OCD. [See > http://home1.gte.net/res0hbt4/documents/requirementsprocessappc. > pdf > for a process description of how to go about this.] > > I want to use the sequence diagram to show the events passing > between a class and its interfacing classes/actors. When I draw > a line between two instances on a Rose sequence diagram and > right-click the line to bring up a menu, the menu includes a > list of the operations that are part of the class instance into > which the 'event' line is heading. The reason for this had me > confused for a very long time. Since then, I have become more > familiar with OO languages such as Java and I now understand > that the reason for the operations list is that this how one > class communicates with another - by making a call to that > classes operations. > > Although I understand why, it doesn't help me with my problem, > which is that when I right-click an event flow entering a class > instance, I want to see a list of the events that enter that > classes state/activity model. (UML supports event flows between > instances on sequence diagrams, so why is the support for this > so lacking in Rose?) > > So now you understand the origin of my problem you may be > saying to yourself, 'how did I reach such a radical conclusion > as to make the statement at the beginning of this composition?' > > Well I got thinking about how I could take advantage of the > fact that I get a list of operations, in a menu, on my sequence > diagram, perhaps by listing events entering the class as > operations, but somehow marking them with an <<event>> > stereotype. (Actually I posted this question to OTUG about a > year ago and someone replied with a similar suggestion, so I > can't take all the credit.) > > Now I have the problem that I have my events listed in two > places, the state/activity model and the class specification, > and I have to do more than twice as much work in order maintain > them in both places. So then I got to thinking 'why do I need > to have my class operations listed in my class anyway?' In S/M > the only way to execute an operation is to generate an event. > So if my 'Car' class needs to make the associated 'Wheel' class > instances rotate in order to move forward, my 'Car' will send > an event to my 'Engine' called 'MoveForward' and my 'Engine' > class will run the appropriate operations and send the > appropriate events, in order to make the wheels move forward. > My 'Car' class does not know what these operations are, nor > does it care so long as the car moves forward. > > Then I got thinking about a more complicated example, where the > same event can cause different operations to execute dependent > upon the state that the system is in. Consider that I have > a 'Worker' class that interfaces to a 'Foreman' class. Now > the 'Foreman' is responsible for ensuring that the 'Worker' > takes the appropriate breaks at the appropriate time, but > the 'Foreman' is not responsible for knowing what the 'Worker' > is doing during those breaks, that's up to the 'Worker'. So > the 'Foreman' sends a 'TakeBreak' event to the 'Worker' after > every 4 hours of work. Now the 'Worker' responds to this event > by having a drink and food. Depending upon the time of day that > this event is received the 'Worker' will execute three > different operations. If it received in the morning the worker > will execute 'HaveBreakfast', in the afternoon 'HaveLunch' and > in the evening 'HaveSupper' (or 'HaveTea' if he's an English > worker :-) ). > > So the 'Foreman' can send the same event to trigger three > different operations. The foreman doesn't need to know, nor > does he care, what the 'Worker' is eating only that > the 'Worker' takes the appropriate breaks. The 'Worker' can > change his schedule and if he decides he wants tea in the > morning one day and coffee in the morning the next, he can > change without interfering with anyone else. > > So my question is, 'If I have a class communication scheme that > only allows classes to communicate via calls to public > operations, how do I implement the 'Foreman'-'Worker' scenario > described above?' > > In fact I would go so far as to suggest that any operations > that are implemented by the 'Worker' are the workers business > alone, and as such should be hidden from the 'Foreman'. If > the 'Foreman' needs to know of an operation that affects > the 'Worker' then there should be a 'Foreman' operation that > sends the required events to the 'Worker' in order for the > worker to carry out the desired operations. > > By now you've probably guessed that I've never written one > class of OO code, so I'm probably ignorant of lots of good > reasons why a 'Workers' operations could need to be made public. > > My question is, please put me out of my misery and tell me what > these reasons are. > > Thank you for reading this far, if you did. > > Les. > > > ________________________________________________ > Get your own "800" number > Voicemail, fax, email, and a lot more > http://www.ureach.com/reg/tag > > > > To remove yourself from this list please mail > puml-list-request@cs.york.ac.uk > with a message containing the word "unsubscribe".


Date view Thread view Subject view Author view