🚀 go-pugleaf

On Sunday, April 14, 1996, Bradley K. Sherman wrote...
> In article <4kr166$1ep@news.nstn.ca>, dbshapco <dbshapco@fox.nstn.ca>
wrote:
> ...
> >In a nutshell, any anticipation of the solution domain pollutes
analysis, to 
> >the worst case in which analysis is nothing more than an alternate way
of 
> >describing implementation (ditto design).  OOP should generate objects
which 
> >correspond to entities in the problem domain and the relationships
suggested 
> >by a well defined taxonomy, and the quality of the classes and class 
> >hierarchy vary directly with the quality of analysis.  Puerile and 
> >simplisitic analysis based on inappropriate or forced correspondences
usually 
> >results in crippled and incomprehensible classes and class hierarchies.
> ...
> Excellent article.  Obviously written by a practitioner.
> 
> However, well defined taxonomies are not easy to come by.  The
> problem is that the taxonomy of the woman on the warehouse floor
> is *not* the same as the taxonomy of the guy in accounts
> receivable which differs yet again from the salesman, ad 
> nauseum throughout the customer's organization.  Each person
> chops up the flow of work in a different way.
> 
>     --bks
> 

The difficulty of determining what the taxonomy is is the foundation of a
whole OOA methodology I've read of but not actually used or seen in use.
The methodology is called "OO-RAM" and is defined in the book "Working
with Objects" by Trygve Reenskaug. The oo-ram method proposes coming up
with various "role models" (scenarios based around the point of view of
one object "role" in the system). You come up with role models for all the
important points of view and then split or merge various roles into your
object taxonomy. The whole idea has a lot of intellectual appeal imho, but
I wonder how usable it actually is?

I'm interested in hearing any commentary from people who know of or have
used the OORAM methodology.