1. INTRODUCTION
Recently, model-based approaches to complex (software)
systems development have gained popularity. Putting
models (rather than code) central in the development process
does indeed offer many advantages. It raises the level of
abstraction; it enables formal analysis (through model
checking for example), simulation (for performance analysis), as
well as automated, consistent code synthesis for multiple
target platforms. Modelling complex systems is a difficult
task, as these systems often have components and aspects
which cannot be described in a single formalism (such as
Class Diagrams, Statecharts, or Petri Nets). User interfaces
are a very pertinent example of such complex systems, in
particular as there are many facets to their structure and
behaviour. Multi-Paradigm Modelling [
9
] captures the
notions that (1) models may have components described in
different formalisms, and span different level of abstraction
and that (2) model transformations are used to map models
onto domains and formalisms where certain questions can
be easily answered. The sequel demonstrates by means of
a digital watch example how CAMPaM principles can be
consistently applied to the design and synthesis of User
Interfaces.
ure shows three levels. The top level will not be used in our
digital watch example. It uses Domain-Specific Formalisms
(DSF) to optimally model structure and behaviour of the
different parts of the application. These models are
subsequently transformed into models in more general-purpose
formalisms such as Class Diagrams (CD) and Statecharts
(SC). The models thus obtained specify not a single
application but rather a class of applications. For example, in a
class diagram, a multiplicity * may be used to indicate the
number of allowed buttons in a digital watch. The models
may be used to synthesize a visual and interactive analysis
and simulation environment. Using such an environment,
the modeller may come up with a refinement of the model,
thus specifying a smaller language. The above multiplicity
may for example be refined to 4 indicating that the final
application must have exactly four buttons. This refined
model can then be used to synthesize application code.
3. DIGITAL WATCH EXAMPLE
In this section, we use the example of a digital watch
application to illustrate the various steps in the process. On
the abstract syntax side, the essential parts of structure and
behaviour of a digital watch are depicted in Figure 2. Due
to space restrictions, the figure does not explicitly show
behaviour for all elements of the model. Only for the Button
class, Figure 3 shows the associated behaviour in the form of
a Statechart. The simple statechart has two states: ButtonOn
and ButtonOff. Transitions between these states are
triggered by an event or trigger T:, but only if the guard G: is
True. When taken, a transition has an action A: as
sideeffect. Guards and actions can refer to attributes of the
class (and at instance level object) whose behaviour is
described. Note that as this model is on the Abstract Syntax
side, it does not contain nor refer to any concrete (visual)
information. Rather, a press or release event received
(from the concrete syntax) is forwarded to the Watch
object of which the button is part. The Watch (known under
the role name watch here) will subsequently take
appropriate action. On the concrete syntax side, a button needs to
Bu t t on
be visualized. This is done by means of a Button2D visual
object which in this case can turn gray or green to
indicate the state of the abstract Button. The actual changing
of colour is done by calling upon the methods setGray and
setGreen of Button2D. In our concrete prototype
implementation, we use Scalable Vector Graphics (SVG) to render
visual objects. As such, Button2D specializes SVGObject. As
such, the setGray and setGreen are actually implemented
by means of SVG instructions. Figure 4 shows structure and
behaviour of Button2D.
S V GO b j e c t
+id: string Bu t t on 2 D
-SVGData: dictionary
+set(attribute,value) +isActive: bool
+create(id,SVGData) +setGray()
+delete(id) +setGreen()
Button Behaviour
ButtonO ff
T: create
InitialA: self= eventhandler.get_event_param s()
T: press
G : self.concrete.set(self.type,’isActive’,True)
A: self.setG ray()
ButtonO n
T: release
G : self.concrete.set(self.type,’isActive’,False)
A: self.setG reen()
Watch
1
level. Some of the classes in the abstract syntax have no
concrete representation. Other classes are related to concrete
visual representations (vector graphics drawings). Some
associations in the abstract syntax are related to connection
splines connecting the visual representations of the classes.
Another alternative is to relate abstract syntax associations
to geometric or topological relations such as insideness or
relative positioning on the concrete side.
Once the above models have been built, an appropriate
meta-modelling and model transformation tool such as AToM3
[
3, 4
] can be used to synthesize an interactive modelling and
simulation environment as shown in Figure 6. Synthesis
is possible thanks to the information available in both the
Class Diagrams and (Rhapsody) Statecharts. Note that our
current code generator generates Python code which
explains the syntax of guards and actions in the Statecharts.
As the models upto now still leave a lot of freedom (in
multiplicities at the abstract side and in visual layout on the
the concrete side), the modelling and simulation
environment allows the modeller to experiment with various model
refinements. A modeller might for example decide to
create a watch which only shows time, and has no chrono nor
alarm. Referring back to our discussion about modelling
languages, the various alternative models are all sentences in
the language defined by the design model. As such, the
synthesized modelling and simulation environment is a highly
domain-specific visual modelling environment (DSVME). It
is interesting to note that the modeller refines the design by
manipulating concrete visual (instance) objects.
Eventually, after refinements are complete, an actual
application can be synthesized as shown in Figure 7. In our
prototype we synthesize a real-time, reactive application
whose user-interaction part runs in an SVG-rendering
capable browser such as firefox. We use an “Asynchronous
JavaScript + CSS + DOM + XMLHttpRequest” (AJAX)
[
6
] framework supporting both push and pull interaction as
shown in Figure 8 As XMLHttpRequest can be initiated from
the browser side, we need a means of “pushing” information
from the abstract side to the browser. This is particularly
necessary for the autonomous, timed digital watch
application where time gets updated every second on the abstract
side (as specified by the Statechart of the Time class in
Figure 2). This “push” is achieved by polling the server (every
50ms) in the Javascript JS_Eval_Poll inside the browser.
+pollForever()
+AJAX(url)
+do_GET()
+do_POST()
Queue
+queuedSVGRequests: list
+set(id,attribute,value)
+create(id,SVGDataString)
queryUpdates1 +delete(id)
+getAndClearQueue()
1
sendEvent
1
1
A
b
s
r
a
c
t