Dialog modelling with interactors and UML Statecharts - A hybrid ...

Dialog modelling with interactors and UML Statecharts - A hybrid approach Hallvard Trætteberg Dept. of Computer and Information Sciences (IDI), Norwegian University of Science and Technology (NTNU). Sem Sælands v. 7-9. 7491 Trondheim, Norway. Abstract The DiaMODL dialog modelling is a hybrid language, based on the Pisa interactor abstraction and UML Statecharts. By combining a dataflow-oriented language with one focussing on behavior, we get a flexible notation which may be used for different purposes, interaction styles and platforms. DiaMODL may be used as a pure abstract notation for modelling dialog or more directly for modelling concrete interaction objects, pointing towards hybrid tools for combining abstract modelling with concrete GUI-building. Keywords: user interface model, dialog model, UML, Statecharts

1 Introduction With the standardization of UML and its emergence as a de-facto industrial standard, modelling of systems and software artefacts seems to be accepted in the engineering community. User interface modelling and model-based user interface design has however, not reached the mainstream software developer [1]. One strategy for gaining wider acceptance for UI modelling is to build on and extend UML, like the Wisdom [2][3] and UMLi [4] approaches have done. Another approach is to make UI modelling more tightly coupled with concrete GUI design. Our dialog modelling language DiaMODL [5] targets both approaches by being integrated with UML and having a natural interpretation in terms of concrete interaction objects. DiaMODL has been validated on industrial cases and has been through several iterations with feedback from both industry and students. In this paper, we first present the language fundamentals, covering both data-oriented and behavioral aspects. Then the use of DiaMODL for modelling direct manipulation and JavaBean components is briefly presented. Finally, related and further work is discussed.

2 The DiaMODL language fundamentals The DiaMODL language is based on the extensional (black-box) description of the Pisa interactor as presented in [6] and the Statecharts notation [7], which is part of the UML [8]. The interactor abstraction was chosen because it has been revised several times and is mature [9], while Statecharts was favored as the formal basis instead of LOTOS due to it being part of UML. 2.1 Interactors and dataflow The interactors in DiaMODL is the means by which a component can mediate information between the user and the interactive system; input from the user to the system and output to the user from the system. An interactor receives and sends information through a set of gates, each consisting of a base and a tip. A generic interactor is shown in Figure 1, with the four different kinds of gates, as follows: input direction Interactor output/ receive

or

System

os

output/ send

ir

input/ receive

gates input/ send

is

User

output direction Figure 1. Generic interactor

1. Input/send (is): Input from the user results in information being sent out of the interactor towards the system. 2. Output/receive (or): Output from the system is received by the interactor, which is responsible for outputting it to the user. 3. Input/receive (ir): User input is received by the interactor for further processing/meditation. 4. Output/send (os): Output to the user is send out of the interactor. The value sent out from the tip is computed (by a function) from the value received at the base. Networks of interactors may be built by connecting the gates; data is sent through a connection from the source gate to the target gate. Similarly to gates, a connection may be labelled by a function, that results in a different value being delivered to the opposite gate. The functions themselves will typically be defined in domain modelling language like UML, either explicitly as operations or implicitly as attributes and relations that define mappings from objects to objects/values. Interactors are compositional, i.e. networks of connected interactors may be

composed into new interactors. Figure 2 shows an interactor for the output and input of integers, implemented as a composition of a string interactor and an integer-string/ string-integer converter. Both the inner STRING interactor and the composite INTEGER INTERACTOR are examples of what we term interactor devices; interactors used for the output and input of one datatype. Such devices have gates only on the system side, i.e. input/send and output/receive gates, since they interact directly with the user. This is indicated in our notation by opening up the interactor in the user side.1 The inner INTEGER2STRING interactor in the left variant works as an adaptor, by mediating/converting values in both directions. Details of interaction is not specified, for instance, STRING INTERACTOR may be a simple text field supporting Roman numerals, or natural language numbers in Norwegian. Super-interactor & device: Gate interface mediates values to and from internal structure of subinteractors.

Interactor device: Direct interaction through physical devices, so no user side gates.

Integer interactor

Integer interactor Integer2String or

int

is

int

or

os

is

Parsing and unparsing of integers

String

String

String

ir

or

or

String

is

String input

Integer2 String

is

String2 Integer

or

is

String input

Figure 2. Integer interactor composition; alternative representations of integer interactor

2.2 Interactors and concrete interaction objects One important use of interactors is for describing the functionality and behaviour of concrete interaction objects (CIOs), e.g. subclasses of Java Swing’s JComponent. Most concrete CIOs are interactor devices, i.e. they are used for input and output of specific data types with direct interaction with the user. A checkbox is a boolean interactor device, similar to the STRING interactor shown in Figure 2, but supporting boolean rather than String values. A text based date field is like the INTEGER interactor in the Figure 2, with the int type and INTEGER2STRING/STRING2INTEGER functions replaced by the appropriate date type and parsing/unparsing functions. In fact, the String device interactor can be used to implement interactors for any basic data type, by using suitable parsers and unparsers. In addition, there exists many special purpose interactors for these types, some of which are shown in Figure 3. The date device in this figure is another example of an interactor built from simpler ones, like number range (year and day) and option selec1. Simple as it may sound, this change has made the notation a lot easier to understand for students.

12

Figure 3. Device interactors, i.e. input and output of same value type, for date, integer and time values.

tion (month) devices. In principle, each part could be replaced by functionally equivalent interactors, without changing the composite interactor’s definition, e.g. radiobuttons for the months, a slider for the day and even a calculator or spreadsheet for the year. Although all these CIOs use the mouse and keyboard for interaction, the interactor description nicely abstracts this fact away, providing a CIO descriptions notation that is portable across platform and modality. red

Select color

green

colors

blue

∈ 1 * color

Select one color from set of colors

red red green blue

Figure 4. Color selection interactor (left) and two corresponding CIOs (right).

The CIOs shown above are simple in the sense that they are used for input/output of primitive types. However, interactors may be used for describing more complex functionality, like element selection. Figure 4 shows the interactor definition for a colour selection interactor and two corresponding CIOs. The output to the user (output/ receive gate of the interactor) is a set, and the input to the system (input/send gate) is an(y) element of this set. Note how UML’s multi-object and association link concepts are used for indicating sets and set membership/subset, respectively. The latter case may be used for describing multiple selection, as shown in Figure 5. More complex domain model structures require more complex interactors. The hierarchy is a very common structure, an interactor for which is shown in Figure 6. Using UML we can define a hierarchy in terms of interior and leaf nodes and their generalisation. As shown, interior nodes may contain1 both interior and leaf nodes. The 1. There is no specific notation for aggregation links in UML, so parent/child roles are used)

Subset selection set

1*

Select a subset of a set subset

Element 1 Element 2 Element 3 Element 4

... Element N

Figure 5. Subset selection interactor and corresponding CIO

output/receive gate of the interactor receives a set of interior containers, and one of the leaf nodes in the hierarchy may be selected and emitted from the input/send gate. parent

child

Hierarchical selection

interior

node

leaf

Select a leaf from a hierarchy

1* leaf

Figure 6. Selecting a leaf element from a hierarchy; interactor and CIO.

The prototypical interaction object for hierarchical selection is the folder view shown right in Figure 6. Different variants exist, and most toolkits lets the designer control if interior nodes also can be selected, corresponding to attaching the input/send gate to a NODE instance instead of a LEAF instance. In all these examples we have used UML for data modelling, but any sufficiently powerful language may be used. The notation may also be tailored (limited to) specific implementation languages, like Java or CORBA’s IDL, to make DiaMODL more suitable for application development. 2.3 Interactor dynamics and Statecharts We now turn to more dynamic aspects of DiaMODL, i.e. triggering of information flow and activation and deactivation of interactors. We leverage the Statechart language by defining that an interactor can be considered a composite Statechart state (see meta-model in Figure 15), which is entered to activate the interactor and exited to deactivate it. As a composite state, each interactor may be decomposed into a hierarchy of substates, using and- or or-decomposition. Substates may be connected by tran-

sitions to control activation and deactivation. Transitions may be labelled with triggering events, conditions that control when it can be triggered and actions that are performed when the transition is followed. Note that transitions may cross state boundaries. States may be referenced in both the event and condition part, the event corresponding to a state is emitted when the state is entered, while as a condition it refers to whether the state is active or not. Gates may similarly be used as events and conditions, for detecting when values are received, sent and present. A common usage of transition is for sequencing end-user actions, or rather, sequencing the activation of interactors that support specific end-user actions. Suppose an action requires the selection of two objects, from respective sets. This may be modelled by two selection interactors, composed into an interactor for that action. With two sub-interactors, there are several possible way of constraining the sequencing, two of which are shown in Figure 7. On the left, unconstrained interaction is shown, while on the right the interaction is constrained be means of an explicit transition from SELECTION 1 to SELECTION 2. In the left case, both sub-interactors are always active as long as their super-interactor is, while in the latter case SELECTION 1 is deactivated and SELECTION 2 is activated when the transition’s condition is satisfied, in this case when SELECTION 1’s input/send gate is fired.1 Relation selection

Relation selection

Selection 1 or

or

Selection 1 or

or

is

is

Selection 1.is relation

Selection 2

relation

or

is

Selection 2 or

is

is

is

Figure 7. And- (left) and or-composition (right)

The currently active substate of a composite state or interactor can be considered data that may be output and input by means of another interactor. Outputting the current state is achieved by connecting a state (which may also be an interactor) with an output/receive gate. This is relevant for indicating the state of a function invocation (functions and gates may be viewed as processes that may be decomposed), e.g. in a progress bar. Inputting a state is a way of explicitly forcing a composite state into one 1. In most cases, the lines separating the substates in an and-decomposition can be deduced, since there anyway cannot be transitions across the lines. Hence, we adopt the rule that each connected subgraph of states are implicitly separated by such lines.

of several substates, and is modelled by Statecharts’ special selection transition. Such a transition leads to several potential target states, and the input to the special selection symbol, an encircled S, specifies which target state to actually enter when the triggering event happens. Figure 8 shows an or-decomposed MODES state, with three substates, and a selection transition leading to them. Which of these three states to actually enter is determined by the value emitted by the input/send gate of the TOOLBAR interactor at the right. The current state is also shown by means of the output/receive gate. This mechanism is useful in cases where a user interface element is directly linked to the state of an object, e.g. the current tool in a toolbar as shown or a tab in a tabbed pane.

Toolbar

modes

S

Mode selection

Figure 8. The Visio 5 drawing tools (top) and interactor model using selection transition

2.4 Modelling system functionality Functions are mostly used for mapping between values, along connections or in-between the base and tip of gates. It is however possible to include functions without arguments inside an interactor. This is useful for providing access to global attributes or application services, i.e. information coming from the runtime context of the interface on the target platform, and not from the user. Object API

Globals

Method 1

Mapped Volumes

G1 volumes

Global attributes

M1

...

... Gn

Method n Mn

Figure 9. Standalone function, group of functions and COM-like object

Figure 9 shows typical usages: The top standalone MAPPEDVOLUMES function

supplies the set of disk volumes, e.g. as input to a file browser. In the bottom left, a set of global attributes are provided by means of output/send gates G1...GN of the GLOBALS interactor. Such an interactor mirrors the use of input devices, by providing values from “nothing”. Application or object services may be modelled as shown right in the figure. The OBJECTAPI interactor provides a set of methods by means of pairs of gates, the input/receive gate in the pair accepts a set of arguments and the output/send gate returns the result. By having separate argument and result gates, we suggest that the computation may be asynchronous. 2.5 Generic interactors and resource binding There are many cases where generic interactors may be useful, e.g. to enable reuse of previous designs, to capture design knowledge, or to model generic CIOs. Interactor resources and parameters are the main mechanisms for supporting this. An interactor resource is some part of or property of an interactor, that is explicitly made replaceable by binding it to a new value (as opposed to editing the model). When a resource does not have an initial/default value, it effectively becomes a parameter that must be assigned before the interactor may be used, similar to UML’s templates. Parsing interactor

Parser

Parsing interactor

String

or

or

os

is

is

ir

Parser

Integer interactor

or is

or

or

is

is

Parser

Integer2 String

Parsing interactor Integer format Parser

ir

Integer format selection interactor

Figure 10. Parameterised interactor (left), instantiation of parameterised interactor (middle) and customization of generic interactopr (right).

Left in Figure 10, a parameterised version of the integer interactor in Figure 2 is shown, where the parser/unparser interactor has been defined as a parameter. The parameterised interactor supports input and output of any type, e.g. date & time, colour or email address by appropriate binding of the parameter. The middle model fragment reconstructs the original integer interactor functionality by binding the parameter to the INTEGER2STRING interactor. Interactor resources are typically bound to actual values during model editing, like in the above case. As a template, the generic interactor can be seen as a convenience for the designer or developer, while not empowering the end-user. However, just as customisation of a product may happen during build, deployment or while in use, resources may be provided through model editing, interface configuration, or dynamically during use. To support the latter kind of customisation, the designer must provide the end-user with special interaction objects that

operate on the dialog/interactor domain instead of the application domain. An example would be an interactor used for selecting the numeric format to parse/unparse according to, e.g. a dropdown listbox populated with relevant formats. This situation can be modelled as shown right in Figure 10, where the input/receive gate for the selected value is connected to the PARSER resource of a parameterised interactor, thus changing the accepted integer syntax.

3 Modelling direct manipulation interfaces Interactor are well suited for modelMove File to Folder ling data-oriented forms-based user interfaces. Each concrete interacstart inSource over file icon button pressed tion object will typically support a specific datatype, and be modelled dragging move command issued by a corresponding device interactor. The end-user is normally free to move button released inTarget over folder icon switch between windows, within which CIOs normally occupy disjoint rectangles and hence are easy to identify and explore. Direct Move File to Folder manipulation interfaces, on the other hand, are based on more complex File sharing of space, e.g. by being triggered by different (parts of) potenover start file inSource tially overlapping objects, and time, icon act emitted by mode switching. In [10] we showed how Statecharts could be move used for modelling the modes that button pressed are typical of direct manipulation Folder interfaces. As illustrated in the top button released model fragment in Figure 11, each over inTarget dragging folder step of a mouse gesture was modicon elled as a state, and transitions were triggered by appropriate mouse events. In this case, the states model Figure 11. Direct manipulation mode for how a source file is dragged to and moving files to folders dropped upon a folder. End-user feedback like cursor changes, highlighting and rubber-banding, was modelled by transition actions (not shown). The main problem with the approach was its indirect handling of the objects that the mouse manipulates. After merging Statecharts with interactors, this has to some extent been solved.1 The bottom model in Figure 11, illustrates how the gesture states are grouped 1. Note that Figure 8 shows how to model the toolbar controlling several such modes.

according to their role in identifying the objects to operate upon. In the example, the first two states identify the source file, while the following two states identify the target folder. The last state is used to trigger the corresponding semantic action, i.e. move the source file to the target folder. An interesting feature of the bottom model is that apart from the five inner states, the interactor structure is quite independent of interaction style. E.g. a form- or command-based interface would share the same top-level interactor structure, but would lack the substates and transition that are included to handle the details of direct manipulation.

4 Modelling Java components and JavaBeans As previous examples show, interactors may be used for modelling the concrete interaction objects (CIOs), that are found in most modern toolkits like Java Swing. Most CIOs are used for presenting and editing specific values, e.g. checkboxes and textfields, some are used for invoking functions, e.g. buttons and menu items, and some are used for control and activation, e.g. toolbars and tabs. In [5], we have shown how many of these may be modelled by interactors, examples of which are shown in figures above. parent

JTree child

interior

node

leaf 1

javax.swing.JTree component

1* leaf

JLabel

node

Renderer

*

Figure 12. The renderer property of JTree

However, there is a difference between modelling how CIOs are used in a interface and the capabilities of a generic toolkit component like Swing’s JTree. For instance, JTree supports customizing how each line in the tree is drawn, by means of a renderer object. Each time JTree draws a line in the hierarchy, it delegates the actual drawing to the renderer object. Different objects in the tree may be drawn differently according to the logic of the renderer. This may be modelled as shown in Figure 12, where the renderer is included as an interactor resource capable of presenting a node (by means of its output/receive gate). The resource is by default bound to the JLabel

component. For in-line editing of values, a similar mechanism called editor is used. Each time editing is initiated, the editor returns an appropriate component, e.g. a text field or checkbox. Again, this may be modelled by adding a interactor resource with an appropriate signature, this time with both output/receive and input/send gates. The JTree component is one of many so-called JavaBeans, Java’s generic component technology. A client-side JavaBean is normally visual, and may both be used directly as sub-components of windows and panels, or indirectly via the renderer and editor mechanisms described above. New JavaBeans may be created from existing ones or made from scratch, for rendering and editing application specific objects. An important characteristic of JavaBeans is how a set of typed properties is exposed to other objects, properties that may be read and/or written through pairs of get/set methods. So-called bound properties will in addition generate a PropertyChangeEvent, that may be listened to by other objects. JCalendar

date

locale

Locale locale

Figure 13. The JCalendar JavaBean

When modelling JavaBeans with interactors, a property may show up as either one or two gates, depending on the read/write permission, or as resources. The main problem of properties when it comes to modelling, is that the role of each property is not formally defined, e.g. it may control the JavaBean’s behaviour, visual appearance or whatever the JavaBean programmer decided. Hence, the modeller must decide whether a particular property is gate-worthy or “just” a resource. However, bound properties normally indicate that the end-user may change it, so they will usually show up as gates, while simple properties usually end up as resources. Figure 13 shows an interactor model of a calendar bean, which lets the end-user browse the calendar by year and month and select a single date. The JavaBean has methods for getting and setting the selected date and will generate an event when changed, i.e. the selected date is a bound property and hence is modelled by a pair of output/receive and input/send gates. The calendar bean supports a “locale” property that controls the language used for both month and day abbreviation, which is modelled as a resource. As shown, the JCalendar bean is accompanied by a JavaBean for locale objects that may be used for

setting the locale property, i.e. it is an interactor for selecting one of many locale objects. The locale JavaBean is included in the model and connected to the corresponding LOCALE resource. The correspondence between JavaBean properties and gates/resources is the crucial point above. This correspondence may in fact be used for going the other way, i.e. defining a JavaBean for a particular composition of interactors. We have worked out a general approach for doing, as well as a way of implementing the internal connections by means of generated JavaBean methods.

5 Comparison and related work Our initial inspiration was the PhD thesis of Markopoulos [6], which used LOTOS as the underlying formalism. We focus less on the formal aspects and more on pragmatics, e.g. a flexible notation including domain objects and natural abstraction of CIOs. The reason for choosing Statechart is also pragmatic, it was already part of UML and we already had a Statecharts implementation in Java. Still, the formal LOTOS base has been utilised by e.g. Paternò’s LOTOS based CTT task models [11] for generating the user interface architecture, an ability we loose when moving to Statecharts. Statecharts have previously been used for both modelling and building user interfaces. Statemaster [12] is a UIMS based on Statecharts, while Horrocks [13] describes how Statecharts may be used for modelling user interface dialog. By merging the behaviour-oriented Statecharts with data-oriented interactors, we believe our approach better supports diverse interaction styles, e.g. both forms and direct manipulation. Use of UML for UI modelling and integration of UI modelling languages with UML has been a topic for some time, e.g. in the CHI’98 workshop [14]. In [15] the use of UML for user interface modelling is discussed. Its weak support for hierarchical models is noted with Statecharts as an exception, but no remedy is suggested. In the TUPIS workshop at UML’2000, several extension to UML were suggested, some of them based on LOTOS, e.g. [16], due to its use for both task and dialog modelling. Nunes’s Wisdom approach [2][3] is a broad attempt at extending UML with UI modelling constructs, based on UML’s lightweight extension mechanism. Although CTT is chosen for task modelling (implying that UML is extended with LOTOS?), no formal approach for dialog modelling is suggested. Silva’s UMLi approach [4] aims to be a minimal extension to UML’s meta-model, and uses Activity diagrams for modelling behaviour. Incidentally, their notation for abstract input/output elements (Displayers for presentation, Inputters for input and Editors for the combination) is similar to ours. UMLi has been implemented in the ARGOi tool, an extension to the open-source UML diagramming tool ArgoUML. Although we for technical and practical reasons follow a different path, we agree on extending the meta-model, since it provides better integration of notations and tools. Traditionally, UI modelling tools have targeted the engineering approach to user interface design, that of going from task descriptions, through abstract dialog specifications to concrete design. In [17] it is argued that support for a more used-cen-

tred design process is needed. Their solution is to combine task and dialog modelling tools with a GUI-builder. Since our DiaMODL notation is well suited for abstracting CIOs like JavaBeans, we want to take this one step further, as illustrated in Figure 14, where a mock-up of a hybrid tool based on Visio is shown.1 The idea is to combine abstract and concrete views of interaction objects in a common design window, to better utilise the strength of both, e.g. use the abstract notation for specifying functionality and behaviour and the CIOs for user-centred prototyping.

Figure 14. Combining abstract interactors and concrete interaction objects in one view

1. The mock-up is based on our previous non-UMLified DiaMODL language, with different notation.

6 Building tool support for DiaMODL Throughout the development of the results described in the previous sections, we have developed proof-of-concept prototypes along two lines, to show the feasibility of implementing tool support, based on interactors. First, we have used the Common Lisp-based CLIM and Garnet toolkits for building an interactor-based GUI-builder, with support for template-based composition of interactor models and live CIOs inside the interactors. Although this prototype predated our use of Statecharts, it showed the feasibility of combining abstract interactors and concrete interaction objects in one view. Second, we have used a Java implementation of Statecharts to implement a simple diagram editor. Although Statechart models were hand-translated to Java-code, this prototype showed that interactors can be the basis for implementing user interfaces, as well as describing them. However, we are still lacking a platform for exploring both these usages within a common environment. Our current approach and ongoing effort is briefly described below, not because it is novel, but to share experiences and reflections on providing tool support for a our modelling language. 6.1 Extending UML’s meta-model Compos it e State

f unct ions

Interactor

(from State_...)

Function arity : int

0.. n

1

1 0..n

classif ier

0.. n Type

(from Collaborations)

multiplicity : M ... 1 1 Attribute

classifierConnection

(from Core)

GateKind base

t ip 0..1 Classi fierRole

Gate kind : GateKind

0..n t ype

Computation

invok es 0..n

Operation (from Core)

0..1

1 0...

Connection

0..1 source

attribute 0..n

target

0..n Classifier End

Connection End

Figure 15. Main DiaMODL meta-model as extension of UML’s

After [5] was submitted, we have turned to UML for domain modelling, as presented in this paper, and for meta-modelling of the DiaMODL language itself. DiaMODL’s meta-model is shown in Figure 15, including the links into UML’s own meta-model. INTERACTOR inherits from STATE_MACHINE::COMPOSITESTATE, hence providing support for hierarchies of both states and interactors. Both CONNECTIONS and FUNCTIONS are COMPUTATIONS which may invoke CORE::OPERATIONS. Value mediation through FUNCTIONs and CONNECTIONs may be constrained by COLLABORATION::CLASSIFIERROLES Finally, the source and target of a CONNECTION, may be a COLLABORATION::CLASSIFIER with an optional CORE::ATTRIBUTE, i.e. the CONNEC-

TION’s

source and target may be either an object or one of an object’s attributes

6.2 Towards an open-source implementation The initial idea was to extend the open-source UML diagram editor ArgoUML, like UMLi did with ARGOi [4]. This was in principle straight-forward; since ArgoUML’s reliance on UML’s meta-model in its own implementation “only” required extending this meta-model with DiaMODL’s concepts. ArgoUML is however based on an old UML version (1.3 compared to the current 1.5) and is undergoing extensive change, so this path seemed thorny. In addition, the underlying graph editing framework GEF, has been difficult to integrate with our Statechart-based direct manipulation machinery. Instead, we are looking towards two other open-source projects, the NetBeans Meta Data Repository (MDR) for UML meta-modelling and JGraph (hosted by sourceforge) for graph editing. NetBeans MDR provides support for building a repository from an extended UML meta-model. JGraph, a Java Swing-based graph component and the JGraphpad application built upon it, will provide basic support for a diagram editor upon which a UML + DiaMODL diagram editor will be built. Based on our current experience, integrating JGraph/JGraphpad, NetBeans MDR and our own Statechart machinery seems feasible, although a lot of work remains. Technical issues aside, the use of open-source tools, UML as a core language and MOF/XMI for meta-modelling, is something the UI modelling community should consider and discuss, to make it easier to cooperate in our common struggle for building UI modelling languages and tools for real-life use.

7 Conclusion We have presented a language for modelling abstract dialog, DiaMODL, which is designed as a hybrid of Pisa interactors and UML Statecharts. As a hybrid, DiaMODL is a flexible notation with few basic concepts that may be used for many purposes and a range of interaction styles and platforms. It may be used as a pure abstract notation for modelling dialog or more directly for modelling concrete interaction objects, and hence, may be provide the basis for tools that combine modelling with GUI-building. DiaMODL is integrated with UML’s constructs for static modelling, to better support industrial projects. We are working on an open-source implementation of DiaMODL, based on an extension of the UML meta-model and existing open-source efforts. The goal is both to make the notation freely available and to get more empirical validation of our approach.

8 References [1] Myers, B., Hudson, S.E., Pausch, R. Past, Present and Future of User Interface Software Tools. ACM Transactions on Computer-Human Interaction, 7, 2000, p. 3-28.

[2] Nunes, N.J., Cunha, J.F. Wisdom - A UML-based architecture for interactive systems. In Proceedings of DSV-IS 2000. [3] Nunes, N.J., Cunha, J.F. Towards a UML profile for interaction design: the Wisdom approach. Third International Conference on the Unified Modeling Language (UML’2000), York, UK, October 2000. [4] da Silva, P.P., Paton, N.W. UMLi: The Unified Modeling Language for Interactive Applications. In 2000, York, United Kingdom, October, 2000. A. Evans, S. Kent and B. Selic (eds.). LNCS Vol 1939, p. 117-132, Springer, 2000. [5] Trætteberg, H. Model-based User Interface Design. Dr. ing thesis from the Dept. of Computer and Information Sciences, Norwegian University of Science and Technology, 2002. Available at http://www.idi.ntnu.no/~hal/publications/thesis/thesis.pdf. [6] Markopoulos, P. A compositional model for the formal specification of user interface software. PhD thesis at Department of Computer Science, Queen Mary and Westfield College, University of London. 1997. [7] Harel, D. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming 8, 1987. [8] UML 1.4. http://www.omg.org/technology/documents/formal/uml_2.htm [9] Duke, D., Faconti, G., Harrison, M., Paternó, F. Unifying views of interactors. In Proceedings of the workshop on Advanced visual interfaces, June, 1994, Bari Italy, pp. 143-152. [10] Trætteberg, H. Modelling Direct Manipulation with Referent and Statecharts. In Markopoulos, P., Johnson, P. (eds.): Proceedings of DSV-IS‘98, Springer-Verlag/Wien. 1998. [11] Paternò, F., Mancini, C., Meniconi, S. ConcurTaskTrees: A Diagrammatic Notation for Specifying Task Models. Proceedings of Interact ’97, Chapman & Hall (1997) 362-369. [12] Wellner, P.D. Statemaster: A UIMS based on Statecharts for Prototyping and Target Implementation. In Conference proceedings on Human Factors in Computing Systems. May 1989. [13] Horrocks, I.. Constructing the User Interface with Statecharts. Addison-Wesley, 1999. [14] Artim, J., et. al. Incorporating Work, Process And Task Analysis Into Commercial And Industrial Object-Oriented Systems Development. Workshop report from CHI’98, SIGCHI Bulletin, 4, 1998. [15] Markopoulos, P., Marijnissen, P. UML as a representation for Interaction Design. Presented at OZCHI 2000. [16] Paternò, F. ConcurTaskTrees and UML: how to marry them? Position paper at TUPIS Towards a UML Profile for Interactive Systems workshop at UML’2000, available at http://math.uma.pt/tupis00/programme.html. [17] Puerta, A.R., Cheng, E., Ou, T., Min, J. MOBILE: user-centered interface building. In Proceeding of the Conference on Human factors in computing systems, p. 426-433, 1999.