Responding to Ashley,

>
>There is a free version of the same paper at
http://www.metamaxim.com/download/documents/OEPM.pdf .
>
>

First, let me say that I think this version is a nice try at reconciling
the notion of distributing a protocol state machine over multiple
objects to address my concerns about object cohesion when using Harel.
But of course I have some comments. B-)

Quibble: 2.2.4.a This implies that an event will simply be ignored if
it is presented to a machine but it is not in the repertoire. If an
event is presented to a state machine that is not in its repertoire,
then the software is broken because the event was addressed incorrectly
for the given OID. Ignoring events is a rather special situation for
events that are in the repertoire but the machine is not in a local
state that is appropriate for consuming them.

[In the OO paradigm collaboration messages are addressed by navigating
relationships to the right class' set of objects and selecting the
specific object from that set (via OID). If an event message is not in
the class' state machine repertoire, then the relationship navigation
was incorrect and the software has a defect. (Note that this is just a
detailed manifestation of my Big Problem below.)]

Quibble: 2.2.6. I don't like the dependence on environment for the same
reason I don't like history in Harel. (I assume you are talking about
preserving state machine environmental variables rather than object
knowledge attributes, which are completely orthogonal to object
behaviors.) It is fundamental to FSAs that a state cannot depend on
knowing the last or next state and I see history as a violation of that
notion, at least in principle.

Quibble: 3.2. I was confused by this discussion. In the 3rd paragraph
you seem to be making a distinction between objects of the same class
(Account). However, in Fig 3 you are showing quite different objects
that have different machines. Different machines implies different
behavior responsibility properties and that means that they are not of
the same class. But I think this just segues to...

Big Problem: 3.1. This is where our fundamental disagreement lies. I
have no problem with protocol state machines as a specification of
requirements or if one is doing procedural or functional development.
However, I have a big problem with them as design implementations in an
OO development environment because of the properties that you describe
in this section. Specifically, an object should not have more than one
state machine under the OO paradigm. (More precisely, there should be
only one repertoire defined for an OID.)

In previous discussions the context was different (e.g., Mealy vs.
Moore) but we ended up in the same place. I outline my objections for
this particular description below because I think it is interesting that
we get to the same place from Yet Another Description. But, we've been
down this road before and I am not sanguine about any imminent
conversions. B-(

One abstracts objects from identifiable problem space entities by
identifying /intrinsic/ knowledge and behavior properties that are
relevant to the problem in hand. Those properties are logically
indivisible and they are independent of the problem context (other than
being necessary to solve it). (In fact, in OOA/D one defines objects
and their properties /before/ defining state machines or behavior
implementations.) Typically there are hard constraints on the
sequencing of the those intrinsic object behaviors within the overall
problem solution context. Those constraints can often be expressed
statically in the form of state machine transitions among conditions
where those behavior rules and policies prevail. So far, no problem.

However, there are four key notions in the OO paradigm that play
together here. My contention is that it is the construction methodology
where these things play together that is the real issue. The first
notion is that the entities one abstracts are identifiable (OID) in the
problem space. The second is that one identifies /intrinsic/ behaviors
of the underlying entity necessary to solving the problem in hand.
These two notions combine to ensure that an object abstraction
represents a logically indivisible entity and has a /cohesive/ suite of
properties relative to the problem in hand The third is that the
solution context provides a set of static constraints on the sequencing
of /all/ those behaviors because they are cohesive by the nature of the
object abstraction. The fourth is that object collaborations are
defined at the object level (i.e., a set of messages the object will
accept, a set of relationships for navigation, and a sender context).

Those four notions combine in the OO paradigm to mean that an object has
one cohesive set of behavior properties that are constrained _as a set_
and collaboration is defined at the object level among the property
/sets/ rather than individual properties. That is, there is one set of
sequencing constraints to apply to all the properties because the object
exists in a single solution context (i.e., from the object's perspective
everything outside the object is lumped into External World). So if one
represents object behaviors with a state machine, there should be only
one state machine with one repertoire (i.e., the object collaborates,
not individual behaviors) for all the behaviors. Thus the depiction in
your Fig. 3 of an OID having multiple independent state machines
represents a /functional/ organization of the object behaviors that is
antithetical to the OO construction paradigm.

Bottom line: this is why whenever I am tempted to use Harel I will
delegate responsibilities until I get down to the simpler world of one
object = one state machine. (Delegation in the problem space, not
artificially breaking up object abstractions; the need for an
identifiable problem space entity under every object remains.)



*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@...
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH