![](bg6.png)
Therefore, usability was explicitely chosen to derive
the taxonomy presented in the following section.
5.2 Experiences
The following discussion is split into the dimensions
expressiveness and usability. Whereas the first di-
mension refers to the amount of problem knowledge
embodied in a domain model the latter incorporates
the effectiveness, efficiency, and satisfaction (Interna-
tional Organization for Standardization, 1998) with
which users can fulfil a task. The evaluation of the
selected meta-CASE tools shows that in general de-
signing graphical DSLs and thus developing specific
tool support is reasonably straightforward in com-
parison to building a CASE-tool from scratch. At
the beginning of this process experienced domain ex-
perts together with a programmer have to identify
and abstract the essential domain concepts result-
ing in a domain metamodel. This process is sup-
ported by the meta-CASE tools METAEDIT+ and
GME respectively. With respect to the expressive-
ness dimension both tools were comparably power-
ful within the scope of the pilot project. The tools’
meta-metamodelling languages MetaGME (Emerson,
2004) (GME) and GOPRR (Smolander et al., 1991)
(METAEDIT+) provide mechanisms for describing
entities, attributes and relationships. Moreover, con-
cepts for information reuse (e.g. modularization and
inheritance) are provided. With these mechanisms
and concepts both meta-CASE tools were capable to
create metamodels that completely reflect the identi-
fied domain concepts. Nevertheless, there is evidence
that further refinement could be advisable. For in-
stance, in METAEDIT+ the possibilities for defining
complex constraints are limited. Thus it was impossi-
ble to define a minimum of connections between enti-
ties ensuring that a certain object is at least connected
with a minimal number of corresponding instances.
Furthermore, it was not possible to define constraints
prescribing that relationships between entities should
depend on specific values of particular object proper-
ties. In this respect GME offers more flexibility due
to the implementation of the UML’s object constraint
language (OCL) (Alanen et al., 2005).
Regarding usability aspects the evaluated meta-
CASE tools reveal potentials for further enhance-
ments both on the metamodelling and the modelling
level. Thus in METAEDIT+ metamodelling must be
carried out textually by means of numerous dialogs.
In contrast GME allows for metamodelling via direct
manipulation of graphical objects using the drag-and-
drop paradigm. Nevertheless, constraints also have to
be defined textually by specifying OCL expressions.
Therefore, integrated graphical support for building
OCL expressions as proposed in the VISUALOCL
project (Fish et al., 2005), (TFS, 2004) would be
beneficial.
Concerning modelling issues – that is to say the
instantiation of metamodels – the evaluation in daily
project work has proven that the graphical represen-
tation of domain concepts was of major impact to
the decrease of HMI developers’ reservation against
the unfamiliar paradigms of DSLs and model-driven
specifications. In particular, the direct manipulation
of objects relevant to their current task context gives
developers the impression of operating with real ob-
jects. Moreover, by means of visual DSLs developers
are enabled to create specifications in an intuitive way
by using objects corresponding to their anticipated
mental model (Jacob, 1986). Consequently, due to
the close semantic distance between domain concepts
and their graphical representation in the DSL the ac-
ceptance of this new approach could significantly be
increased.
Besides the graphical representation of a DSL the
support for established and familiar workflow was im-
portant for acceptance among developers. Thus it
soon became apparent that developers were hardly
willing to resign functionality of traditional specifi-
cation tools. For instance, a frequently used speci-
fication instrument is the insertion of comments and
memos. While on the metamodelling level it is ob-
viously possible to provide a DSL with textual notes
and an appropriate graphical representation the eval-
uated meta-CASE tools did not possess means for
adding graphical comments such as rough sketches
which do not possess any semantic meaning. Unfor-
tunately, developers make heavy use of this feature in
current projects. Experience has shown that in daily
work such tool flexibility is vitally important. There-
fore, tool flexibility can hardly be offset by the indis-
putable advantages of more formal specifications, if
these have to be created with less easy-to-use tools.
Furthermore, developers strongly demanded the
implementation of the widespread operating philos-
ophy of standard office applications. Among other
things this includes object inspectors, tree views for
object hierarchy or discretely colored grids for align-
ment. Moreover also powerful auto layout for com-
plex diagrams would be desirable. While GME meets
the two last-mentioned requirements an editor for the
definition of domain concepts’ graphical representa-
tion is missing. Although GME supports the assign-
ment of bitmap files to abstracted domain concepts
METAEDIT+ with its integrated symbol editor was
considered superior in this respect. But, the features
of this rudimental symbol editor are limited to only
elementary geometric and freeform shapes. Unfor-
tunately, this implementation appears to be too cum-
bersome at first glance. Even at closer inspection
support for complex constraints and dependencies or
nested graphical objects is missing. Finally, besides
GUI related topics also enhanced features for model
MODEL-DRIVEN HMI DEVELOPMENT - CAN META-CASE TOOLS RELIEVE THE PAIN?
317