Charles -
I agree with H.S. Lahman's comments on the intentions of the real-time, model compiler/MDA oriented Executable UMLs (eUML, iUML, xtUML, * UML, etc.). By the way, when I use the term "Executable UML" I am referring to all of these. And also his inciteful comments about system design and function/hierarchy vs. asynchronous objects in domains.
That aside, let me try to address a few of the specifics:
--- In executableuml@yahoogroups.com, "Charles Abreu" <charlesabreu@...> wrote:
>
> 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.
Right - since Executable UML was designed with real-time embedded and/or distributed systems in mind, the object-state-asynchrony model is the primary framework. This makes it easier to compile a set of models onto an arbitarily distributed platform without having to change them. It also encourages as much parallel behavior as possible which tends to move us away from the single thread function calls function calls function paradigm.
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.
The Executable UML book might not mention this, but most, if not all of the Executable UMLs support synchronous operations and domain services which can be called, and blocked on without the need for a wait state and attendant synchronization. If you download my latest elevator example you will see that I do make use of this mechanism. For example, the elevator application domain will invoke a motor transport service to transit to a specific floor and expect a returned value indicated whether or not that stop is physically possible given the current acceleration and position of the cabin.
>
> 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.
You can do this in Executable UML. You could define an operation on a class which returns a boolean. So you might select A's neighbor (which happens to be B, for example) and say:
if A_neighbor.report_status then ... else ...
>
> 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.
Not knowing anything about your application, I'm really reaching here, but you might actually model the decision tree with classes "Tree", "Decision Node", etc. and have a data driven solution. I suspect, however, that this is not what you want to do either.
If you can come up with a more specific example it would be easier to help. (There are just so many directions we can go with your example that I prefer to get more data before proceeding). Can you state the example with two or three "real world" classes?
- Leon
>
> 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
>