Responding to Waheed...

It is actually fairly straight forward. There are two situations: with
a tool and manually. All of the tools that support eUML provide test
harnesses that allow test case vectors to be executed, so that is quite
routine. The tools make it relatively easy to provide test vectors and
identify events expected from other subsystems.

Manual execution is tedious but also straight forward. The team sits
around a <really big> conference table and each team member is assigned
a subset of object state machines. Each team member uses a handful of
coins or other tokens to mark the current state in each state machine.
(Different denominations are used to mark the current state in multiple
instances.) The team member also keeps a table of current values of the
instance attributes. An external stimulus event is provided and it put
on a "queue" that the exercise leader maintains. The exercise leader
"pops" and event and directs it to the team member with the relevant
object state machine. The team member with that state machine uses the
state model to determine the transition, new state, and the action to
execute. The team member "walks" the state action language to determine
how attributes are modified and what events are generated. The events
are placed in the "queue" and the exercise leader "pops" the next event
and dispatches it to the next object. And so on.

As far as how a tool would actually execute the model, it does it
basically the same way the manual testing does it. The tool parses the
abstract action language for each state action to determine what to do.
The tool maintains its own list of objects and their attributes that it
gets from the drawing tool repository just like the manual testers.
Everything is known except for any realized code invoked from state
machine actions.

One way realized code is handled is to have it already available in a
library and the test harness simple invokes it the same way the action
language would. How one does this would depend upon the 3GL used to
implement the model simulator (e.g., it would clearly be easier is the
language were one of the OOPLs based on scripting languages because the
realized code could be accessed directly by name). Alternatively, one
can also stub realized code in the test harness since all it can do is
return values.

You will note, though that there is a lot of parsing (action language,
model relationships, etc.) that the model simulator must do that is
pretty much the same as it would have to do to generate code. As a
result, almost all eUML tools actually generate code in a target 3GL and
instrument it with GUI hooks and whatnot as the code is generated in
order to maximize code reuse between the model simulator and the code
generator. This is essentially the same thing that a 3GL IDE like
Visual C/C++ does when it creates a debug version of the application
(e.g., the main() and other infrastructure is provided by the model
simulator rather than the normal code generator). AFAIK, Bridgepoint is
the only translation tool that uses a "pure" model simulator without
direct code generation.


*************
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