Re: UMLsemantics questions
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Tue, 23 Jan 2007 18:01:11 GMT
Responding to Pourias...
consider a class "C" with operation "o" and a method to implement this
operation. also suppose that "C" has a statechart that specifies the
reactive behaviour of its instances, but no transitions of this
statechart are triggered by "o".
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.)
Therefore "o" is either: (A) a behavior responsibility implemented as a state machine action triggered by a transition or (B) 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.]
if the statechart of an instance of "C" is blocked in the middle of a
run-to-completion step waiting for a synchronous call action to return,
and receives a request from another object to invoke "o", will it
execute the method of "o" or queue the request until the its
run-to-completion step is complete?
At the OOA/D level one assumes there is an event queue that controls when events are consumed. One of the relevant rules the modeler can assume is that only one event at a time will be consumed for any state machine. Thus a C state machine will consume only one event at time to completion of the action triggered by the transition. So if "o" is a behavior responsibility, it will not get triggered until the current action completes.
If "o" is a synchronous service and concurrency is possible, then one needs to provide infrastructure in the concurrency implementation to ensure that invoking "o" is blocked for other objects while any C event is being consumed. (An object synchronous service could access the same object knowledge as the state action so data integrity requires blocking if "o" is invoked externally.)
However, concurrency is not directly an OOA/D issue. (One can express parallel processing constraints via Activity Diagrams.) That's because concurrency implementation is a pure OOP issue since it depends upon tactical facilities like threads, semaphores, hardware interrupts, etc..) So one doesn't need to worry about "o" being invoked by another object.
For example, when using object state machines in the OOA/D one assumes a single event queue exists in the implementation. (The event queue never appears explicitly in the OOA/D model.) The rules for that queue ensure only one event is consumed at a time. If another object is to invoke "o" it would do so from one of its actions. But the single queue ensure only one action at a time is executing.
However, 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. Now one can have time slicing by doing a round robin of popping an event from each queue in turn. Or one can have concurrency on multiple processors by allowing each queue to pop events in parallel.
If one does concurrency this way, one needs to ensure proper blocking of knowledge access. One would do that at the OOP level with a set of semaphores that would pause particular event queues for blocking or would block invocation of particular synchronous services. One can pretty much handle that by having the event queues talk to each other as they consume events.
So all one really has to worry about at the OOA/D level is solving the asynchronous message problem with proper handshaking to ensure the objects will be in the right state to accept events. If that asynchronous communication is provided correctly for the single event queue assumption, it will be <relatively> easy to map it into a concurrent environment at OOP time using threads, multiple event queues, and whatnot. [It is also crucial that one distinguishes between state actions (behavior) and synchronous services (knowledge access). Limiting synchronous services to knowledge access allows one to map blocking scope to action scope, which makes data integrity a /lot/ easier.]
*************
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
.
- Follow-Ups:
- Re: UMLsemantics questions
- From: pourias
- Re: UMLsemantics questions
- From: pourias
- Re: UMLsemantics questions
- References:
- UMLsemantics questions
- From: pourias
- UMLsemantics questions
- Prev by Date: Re: Simples Rules make creating Big Balls of Mud impossible.
- Next by Date: Re: Simples Rules make creating Big Balls of Mud impossible.
- Previous by thread: UMLsemantics questions
- Next by thread: Re: UMLsemantics questions
- Index(es):
Relevant Pages
|