Re: WHERE ARE ALL THE OT EXPERTS???

[Michael E. Lee, II <mlee@primenet.com>]

> >>trivial as to be completely useless, and (2) it's *worse* than 
useless 
> >>because it's a completely action-centered approach.  Urgh.
> >
> >2) Define "action-centered" in this context. I don't understand what
> >   you're trying to tell me. What is the alternative 
("passive-centered" :-)?
> 
> 
> A book I recently read points out that most people who use
> action-oriented design when using an O-O language tend to have roots
> in procedural programming.  I don't know anything about CRC cards, 
but
> if it is action-oriented, it wouldn't surprise me that managers tend
> to like them.  Most of these managers were probably promoted out of
> the programming ranks while they were still using a procedural
> language.  Unfortunately, the different duties of a manager tend to
> separate them from the current technical happenings, so they're not 
as
> up-to-date as when they were programming.


Knowing the inherent risk of jumping into a thread mid-stream, here 
goes...

The whole notion of CRC revolves around a single basic understanding:  
things (people, organizations, objects, systems, etc.) work together to 
accomplish tasks (business processes, workflows, Use Cases, methods, 
etc.).  Granted, Responsibility-Based Design (RBD) focuses on behavior, 
but it is _always_  the behavior of things.  Never, never, is this 
behavior "stand-alone" or strictly functional in nature.

The hard-time RBD has been getting is very much related to our 
perception of "analysis" and "design".  RBD splits-hairs in this area.
From one perspective, RBD deals with the external reference of 
objects - i.e. what are they and what do they do?  From another 
perspective it deals with the internal nature of the behavior - i.e. 
how are things accomplished.  It is this internal view that defines the 
collaborations.

> Action-centered design is usually associated with procedural
> programming, because it encourages this approach.  Basically, it
> centers on the actions of the user, with each of the user's paths
> modeled in the software.  Object-oriented programming can capture 
this
> sort of model, too, but doing so doesn't take advantage of the
> paradigm.  For one thing, it tends to destroy reusability, because it
> ties the design to one specific domain.  So, action-oriented design 
is
> to OOP what unstructured design was to procedural programming.


Horse s---!!!!!

Where do I start?


Leaving aside the red-hearing of "action-centered", let's switch our 
focus back to Responsibility-Based Design (which CRC is a short-hand 
mechanism).

First, one doesn't have to fit in a CRC model into an OO paradigm 
anymore than one would have to fit a Fusion, Booch, OMT, or Use Case 
model into the OO paradigm.  RDB _is_ OO!  Period.

Second,  how does RBD destroy reusability?  How does it tie one to a 
specific domain?  There seems to be a misunderstanding that RBD is 
strictly de-compositional in nature.  It's not.  Granted, identifying 
and establishing collaborations may force us to "de-compose" a 
Responsibility's behavior, but this does not mean that we have to 
identify, define, and build the servicing objects from scratch!  In may 
circumstances, the process is one of synthesis rather than 
decomposition.  We have an existing set of objects (many, if not all, 
of which can be domian-independent) which supply a set of services 
(which themselves can be modelled using RBD - if so desired).  We then 
build higher-level methods, tasks, workflows, or processes from these 
objects (we could also derive new objects from the existing ones, and 
synthesize from these).

Finally, I come full circle.  Objects and their behavior do not 
stand-alone.  An object is useless unless it interacts with its 
environment.  RBD allows us to define these interactions - in the same 
model we define the objects.  And RBD is not the only way.  The 
popularity of Use Cases is another example of our hunger to put objects 
into an overall perspective.  (Altough one can view Use Cases as 
Responsibilities of the systme being analyzed, and the Actors as 
objects establishing collaborations with the system Responsibilities).



+----------------------------------------------------------------------
-
Michael E. Lee, II                         mlee@primenet.com
Agincourt Engineering