Re: UMLsemantics questions

i couldn't have hoped for a better response. thanks for taking the
time to write it, it was very useful for me.

On Jan 25, 3:33 pm, "H. S. Lahman" <h.lah...@xxxxxxxxxxx> wrote:
Responding to Pourias...



I am confused. B-( If C has an object state machine to describe
behavior, then the only behavior operations would be state machine
actions associated with states (Moore FSM model) or transitions (Mealy
FSM model). Transitions would be triggered by events and events are
generated outside the FSM. (Purists consider self-directed events
generated by a machine's own actions to be a no-no.)

In the UML is it not possible to have the behaviour of an object
specified as both actions on transitions of the object statechart as
well as methods of the object class? For example in Rhapsody, for a
class one can specify event receptions (or signals for asynchronous
comm.), triggered operations (or calls for synchronous comm.), or
primitive operations. The reception of events and triggered operations
are queued by the object statechart and can trigger transitions of the
statechart. The same is not true for primitive operations. I believe
the OMG UML specification (which cannot claim to fully understand) has
similar notions. This has lead me to wonder about the semantics of
receiving a primitve operation call.I think the issue here is methodological. Notations like 3GLs and UML
allow one quite a bit of latitude for shooting oneself in the foot.
That's because they only express designs; they don't provide designs.
The problem is that synchronous services accessing knowledge can be
algorithmically complex so there is no convenient way to distinguish
knowledge and behavior "operations".

/IF/ one is using object state machines, then all behavior
responsibilities of an object should be captured in state machine
actions. Any other responsibilities the object has, even if represented
syntactically at the OOPL level as a procedure, are knowledge accessors.
The state machines allow one to use well-established DbC-based
techniques for enforcing sequencing rules. If one is not using object
state machines, then one has to provide one's own enforcement of
sequencing rules in the operation implementations.

Thus in a Matrix object one would probably not have a object state
machine because all the "operations" like 'transpose' and 'invert' are
really just smart setters for the cell values the Matrix is responsible
for knowing. Those operations may require complex algorithms to
manipulate the knowledge, but they are still just setters that do not
capture business rules and policies that are unique to the problem in
hand (i.e., the algorithms are defined in the more general context of
mathematics). In an OO context behavior responsibilities execute rules
and policies that are unique to the problem space.

[I've dealt with OO applications where as much as 60% of the code was
"realized" outside the OO context, often procedurally in language like
FORTRAN or C. That realized code was encapsulated behind object
methods. That's because the code was largely algorithmic and defined
outside the context of the particular problem in hand so it wasn't
directly relevant to solving the customer's problem. It wasn't going to
change as requirements in the problem space changed so OO's
maintainability benefits were wasted and it was easier to use a more
intuitive computational approach. A classic example is using a linear
programming package to do some optimization. How the LP algorithms work
is not relevant to whatever the problem is that the OO application is
solving by providing (among other things) optimization.]

Methodologically it is important to keep straight the difference between
behavior and knowledge responsibilities in an object. Behavior is
inherently dynamic because it must occur within a specific context
(sequence) in the overall solution. Conversely, the responsibility for
knowledge is pretty much static; the object either knows something or it
doesn't. If it has the responsibility, it always knows it. OTOH,
changing the knowledge is always <triggered by> a dynamic activity
captured in a behavior responsibility because there are problem space
rules and policies that determine When it should be changed. If there
are also problem space rules and policies about How it should change,
those will be captured in a behavior elsewhere to determine the new
values. But if the rules and policies exist in a broader context than
the problem space, they can be captured in a knowledge setter
(synchronous service).

Consequently, methodologically there are limitations on what one should
can do in a synchronous service to access knowledge. In particular, it
can't synchronously invoke behavior responsibilities. However complex
its algorithm may be, it can only touch knowledge attributes within its
scope. (This is particularly important for managing data integrity in a
concurrent implementation during OOP or for optimizing by a full code
generator from OOA/D models.)

Behaviors happen to be ideally suited to representation with state
machines because the transitions represent constraints on the relative
sequencing of the behaviors in the overall problem context. In effect
the state machine allows part of the dynamic context to be expressed in
terms of <specialized> static structure. That makes the executable code
simpler (albeit at the cost of figuring out how to make the state
machines interact properly) and, consequently, smaller and more reliable
(once one gets the state machine interactions right).

As I mentioned, in OOA/D one assumes synchronous access for knowledge
(otherwise managing data integrity would turn the developer's mind to
mush) and asynchronous access for behavior. The reason is that an
asynchronous solution in the OOA/D is the most general solution for
managing sequencing constraints. One can always implement asynchronous
communications in a truly synchronous environment. But one cannot
always unambiguously implement a synchronous solution in an inherently
asynchronous environment.

So methodologically when one constructs the design in the OOA/D, one
wants to keep behavior and knowledge responsibilities separate for a
variety of reasons. The fact that particular OOPLs and tools allow one
to provide both an object state machine and synchronously accessed
behaviors doesn't mean one should do that. Doing so just opens a
Pandora's Box of potential side effects that must be dealt with outside
the normal techniques for managing state machine interactions.

[BTW, Rhapsody has another issue because the action language it uses is
an augmented OOPL rather than a true abstract action language (AAL).
That allows a lot of implementation pollution to be included in the
OOA/D model that a language at the same level of abstraction as the rest
of UML would simply not allow. The current AALs for OOA/D aren't
perfect but they go a long way towards enforcing the separation of
behavior and knowledge management. But the OOPLs don't provide that
separation at all because they are 3GLs.]

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

H. S. Lahman
h...@xxxxxxxxxxxxxxxxx
Pathfinder Solutionshttp://www.pathfindermda.com
blog:http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
i...@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring:http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

.

Relevant Pages

  • Re: UMLsemantics questions
    ... Transitions would be triggered by events and events are ... /IF/ one is using object state machines, then all behavior responsibilities of an object should be captured in state machine actions. ... Any other responsibilities the object has, even if represented syntactically at the OOPL level as a procedure, are knowledge accessors. ... Those operations may require complex algorithms to manipulate the knowledge, but they are still just setters that do not capture business rules and policies that are unique to the problem in hand (i.e., the algorithms are defined in the more general context of mathematics). ...
    (comp.object)
  • Re: State Machine/Class Granularity
    ... >> Say I have a state machine with two superstates. ... > indicate poor abstraction of object responsibilities (i.e., ... I haven't used an STT explicitly yet. ... >> superstate in another class. ...
    (comp.object)
  • Re: Attaching a behavior only to multiple classes.
    ... responsibilities are important to the problem, ... specific solution context. ... The point is that GoF uses delegation to separate the behavior from ... >>concerns of instantiation, implementation, and navigation. ...
    (comp.object)
  • Re: Design advice needed
    ... describing a graph and the other is executing some behavior that is dependent on context not directly expressible in terms of the graph. ... Loading/saving from/to persistence is one suite of responsibilities. ...
    (comp.object)
  • Re: Can I have Interface & Inheritance together for same class?
    ... Instead they provide a bunch of cookbook guidelines for defining responsibilities that get to the same place. ... Saying it is distracting when the entire static structure of OOA/D notations is based on set theory's relational model bothers me even more. ... A class is full of procedural code, ... At the risk of being pedantic, the AALs are specification languages, not implementation languages. ...
    (comp.object)