Responding to Abreu...


The first thing to note is that knowledge (what an object is responsible
for knowing) and behavior (what an object is responsible for doing) are
treated differently in the OO paradigm. Knowledge attributes are
assumed to be accessed synchronously on an as-needed basis by the
methods (state actions) that need them. (If the object owning the
attribute is distributed, then the implementation will have to provide
additional infrastructure to make it appear as if the attribute is
immediately accessible.) So knowledge accessors do wait for a response.

Behavior responsibilities are handled with an asynchronous model in the
OOA because that is the most general model. (A synchronous model is
just a special case of asynchronous where the message order is
deterministic.) An asynchronous model can always be implemented in a
synchronous computational environment but a synchronous model cannot
always be implemented in an asynchronous computing environment. The
eUML profile enforces this by requiring that all behavior
responsibilities be described with object state machines.

Another reason is the decoupling provided by separating message (event)
and method (action) in OOA/D. This allows messages to be announcements
of something the sender did with no expectation of what will happen.
This decoupling is fundamental to the OO paradigm because it eliminates
the hierarchical dependencies that plagued traditional functional
decomposition developments (aka Spaghetti Code).

So the bottom line is that one does not want an object behavior to wait
for the results of some other object behavior because (A) that may not
be implementable if the computing environment is asynchronous and (B) it
creates and immediate hierarchical dependency, which is an OO no-no.

Now as far as your examples are concerned, my initial question is: What
do you mean by 'condition'? If you mean a state variable (knowledge
attribute) value, then there is no problem because you can access
attributes of other objects synchronously.

There is a problem, though, if the accessor for B's knowledge must
access C's knowledge to compute a value. In that situation you have
dependent variable, which the eUML book talks about in section 11.4.
The answer to that is to ensure that the independent variable
(presumably in B here) should be updated synchronously whenever the
dependent variables are modified. Then when A accesses the dependent
variable, it always gets a timely value. Alas, extending the change to
D suggests that your definition of 'condition' here is not simply a
knowledge value, since that sort of compound dependency would be quite rare.

If you mean 'condition' in the sense of a DbC postcondition for
behaviors in D, C, and D, then one has a quite different problem. Two
problems, actually. The first is that there is a sequencing constraint
that requires the behaviors to be executed in a particular order: D -> C
-> B-> A. The second is that each behavior's postcondition must persist
until A executes.

There are two approaches to the sequencing problem. One is to
daisy-chain the events in the correct order. For example, the initial
event that triggers A's action goes to D instead. When D completes, it
sends an event to C, and so on. One way to handle persisting the
postconditions is to place the result in the event data packet that is
passed on. So A gets and event data packet with three data elements,
one for each postcondition.

The second approach is to capture the sequencing constraints in an
object state machine, presumably A's, as transitions. So one might
have A's state machine look something like:

[State1] // send do_it event to D
|
| D_done
|
V
[State2] // send do_it event to C
|
| C_done
|
V
[State3] // send do_it event to B
|
| B_done
|
[State4] // original A action

The X_done events are sent back to A by D, C, and B. Each event's data
could hold the postcondition value that A needs.

In both cases there is an alternative to sending the postcondition value
back to A via event data packets. One can have D, C, and B cast the
postcondition result into a knowledge attribute. Then when the sequence
is complete A will access all three values to decide what to do.
Personally I prefer this way because it is more flexible. For example,
if D's behavior must get executed long before C for other reasons AND
the larger context guarantees that it will have been executed before C
anyway, getting the postcondition value to A would be much less messy.

> Hi,
>
> I'm trying to apply the concepts from the book in a real world
> application, wich main domain is access control. But I got stuck on
> early stages with a basic question: what about functions? The book
> talks a lot about communicating objects throught asynchronous signals,
> which trigger non-blocking procedures on the receiving objects. It
> seems there isn't any single case through all the book case study
> (order management) of an object needing to wait for another object
> response before taking some execution path decision (if/then/else).
> Instead, all the decisions showed there were based on query (select)
> results.
>
> Initialy I thought there is no need to an object to wait a response
> from another, because the second object would send a signal to the
> former when it had arrived at some state or condition that the former
> needs to know, which seems to corroborate to the idea of no controller
> objects too. But my system has a lot of decision points of the form:
>
> In object A:
> if some condition related to object B holds true, then do this; else
> do that.
>
> ...and in object B:
> if some condition related to object C holds true, then return true;
> else return false.
>
> ...and in object C:
> if some condition related to object D holds true, then return true;
> else return false.
>
> And so on.
>
> This compounds a hierarquical decision tree, where the action taken by
> an object depends on a query on another object, wich dependes on a
> query on another, and so on. The way I modeled, object A only needs to
> talk to C. It doesn't need to know anything about B or D's existence
> nor implementation, and vice-versa. How can this be re-frased using
> asynchronous signals and non-blocking, non-value-returning procedures?
> I can only think about it in terms of functions and hierarquical
> communication.
>
> How should this be handled using the Executable UML concepts provided
> in the book?
>
> I would appreciate any enlightenment or opinion. Thanks.
>
> Regards,
> Charles Abreu
>
>


--

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

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