A ToolBus Application
As example we have an application consisting of two tools. Tool1 can either send a 'message' to Tool2 and then waits for an acknowledgement from Tool2, or it can send a 'quit' after which the application will shutdown.
Component1
has just sent a message to
Component2
,
which is ready to send an acknowledgement back.
We refine the architecture specification into a specification of a ToolBus application.
Component1 = send-message . snd(c1 >> c2, message) . rec(c2 >> c1, ack) . Component1 + stop . snd-quit
Component1
from the architecture of our toy example.
We can make a vertical implementation by applying the following mapping.
send-message -> tb-rec-event(T1, tbterm(message)) snd(c1 >> c2, message) -> tb-snd-msg(t1, t2, tbterm(message)) rec(c2 >> c1, ack) -> tb-rec-msg(t2, t1, tbterm(ack)) . tb-snd-ack-event(T1, tbterm(message)) stop -> tb-rec-event(T1, tbterm(quit)) snd-quit -> snd-tb-shutdown
PT1 = tb-rec-event(T1, tbterm(message)) . tb-snd-msg(t1, t2, tbterm(message)) . tb-rec-msg(t2, t1, tbterm(ack)) . tb-snd-ack-event(T1, tbterm(message)) . PT1 + tb-rec-event(T1, tbterm(quit)) . snd-tb-shutdown
Component1
into
PT1
gives the following result.
In a similar way an implementation (PT2) for
Component2
can be obtained.
PTool1 = Tool1Adapter || PT1 PTool2 = Tool2 || PT2
PT1
and
PT2
by constraining them with
Tool1Adapter
, the specification of Tool1 with a separate
adapter,
and
Tool2
, the specification of Tool2 with a built-in adapter.
Note that
Tool1Adapter
is itself a constraining of
AdapterTool1
with
Tool1
.

AdapterTool1
has just sent a message it had received from
Tool1
to ToolBus process
PT1
.
We can make an implementation consisting of three Tcl/Tk programs (Tool1, its adapter, and Tool2), and a ToolBus script. The ToolBus script is derived from the specification of the ToolBus processes in the specification of the example as ToolBus application.
We show a screendump of this application at work together with the viewer of the ToolBus.