Re: UMLsemantics questions

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
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: UMLsemantics questions
    ... then the only behavior operations would be state machine ... Any other responsibilities the object has, ... In an OO context behavior responsibilities execute rules ... in OOA/D one assumes synchronous access for knowledge ...
    (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: UMLsemantics questions
    ... then the only behavior operations would be state machine actions associated with states or transitions. ... a behavior responsibility implemented as a state machine action triggered by a transition or a knowledge responsibility implemented as a synchronous service to be executed synchronously. ... [A synchronous service does not generate events (trigger transitions) or modify the state machine state.] ... a sort of poor man's time slicing can be implemented during OOP quite efficiently at the action level by providing multiple event queues to service different groups of object state machines. ...
    (comp.object)
  • Re: learning vhdl - state machines
    ... ones (except the register itself, which is almost free in most FPGA ... clocked process for the state machine and its outputs. ... erroneous transitions based on asynchronous inputs. ... In a gray coded state machine for asynchronous inputs, ...
    (comp.lang.vhdl)
  • Re: implementing roles in OOP......
    ... On state machine states vs. state variables: ... the notion of 'state' becomes that of a state machine. ... IOW, state machine states are inherently dynamic in nature. ... > I still can't see a real difference - at least in this context. ...
    (comp.object)