---- On Thu, 29 Nov 2001, Eric D. Tarkington 
([EMAIL PROTECTED]) wrote:

> 
> Re: (ROSE) RE: My BIG Question(long).
> Les Munday <[EMAIL PROTECTED]> wrote:
> > Answer: =93All class operations should be private to the 
class=20
> > that implements those operations, no class should be able 
to=20
> > directly access the operations of another class.=94
> 
> I have corresponded privately with Les about objects and how 
they model
> events.  He is proposing a radical change to our sense of how 
an object
> works, and the only way to assess it would be to apply it for 
a few
> months.  Even that may not be conclusive, though, because 
existing tools
> are not fully adapted to the revised object.
> 
> As an old automation and communications guy from the bronze 
age, I am
> sympathetic to much of what Les says, but it runs contrary to 
what I
> think most people visualize as an object.
> 
> In the conventional view, an event is modeled as a message, 
which is
> modeled as an operation on some receiving object.  Good 
coupling is
> mainly achieved by a careful selection of what operations are 
public and
> what private.  If a message in a sequence diagram can be 
understood by a
> pure domain expert, it is generally realized as a public 
operation (or,
> at least, it is not private).
> 
> Although we avoid functional decomposition, there is no harm 
in
> perceiving that objects may be created to be shallowly or 
deeply nested,
> and that shallowly-nested objects are usually 
more "architectural" (more
> clearly related to the use case diagram, for instance).
> 
> Although people make countless mistakes in applying this 
model, the
> facts remain that it is very powerful and that a large number 
of people
> have been able to gain an understanding of the model that is 
largely
> shared.  To the degree that the understanding is shared, we 
have culture
> and industry.
> 
> Les needs to demonstrate powerfully the benefits of his 
approach, which
> may be superior to common practice.  How he does this is a 
mystery to
> me, but until he does it, the proposition falls to 
Tarkington's
> principle:  "It's better that it be standard than that it be 
good."
> 

Eric, You give me too much credit. Because I posted the 
original question to many users groups, you won't have seen all 
the responses that I got to my original questions. In fact 
other people had spotted a similar flaw with the UML, and at 
least one company (small plug for Pathfinder here) claim to 
have come up with an add-in for Rose that helps alleviate my 
problem.

> Tarkington's principle is irritating, and it is as much 
sociological and
> psychological as technical, but I keep finding useful 
applications.
> 
> At the level of practical suggestions, I think Les should 
develop a very
> simple manual of how to apply his ideas to one or two popular
> domains.=20
> He may also consider suggesting extensions to the UML, or 
drawing up an
> altogether new language.
> 

Eric, It's already done. At least the inital version. I'm stil 
collecting feedback. I have received a little from some 
readers, but not enough to convince me that I have explained my 
principles sufficiently.
This URL was in the original email.
http://home1.gte.net/res0hbt4/html/Process.htm

Ok, I'm going to collate a summary of responses now, so don't 
disturb me for the next hour.

Les.

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

Reply via email to