=Paper=
{{Paper
|id=None
|storemode=property
|title=Aspect-Oriented UI Modeling with State Machines
|pdfUrl=https://ceur-ws.org/Vol-617/MDDAUI2010_Paper12.pdf
|volume=Vol-617
}}
==Aspect-Oriented UI Modeling with State Machines==
https://ceur-ws.org/Vol-617/MDDAUI2010_Paper12.pdf
Aspect-Oriented UI Modeling with State Machines
Gefei Zhang∗
Ludwig-Maximilians-Universität München
gefei.zhang@pst.ifi.lmu.de
ABSTRACT modeled in its own UML state machine [11], separated from other
Separated modeling of User Interface (UI) widgets is a very natu- widgets. We call the state machines widget machines. Necessary
ral way to tackle the complexity of UI models. Due to interactions synchronization between widgets, if any, is left out of the widget
between widgets, however, this is not always an easy task. We pro- machines, which keeps them rather simple. The synchronization is
pose an aspect-oriented approach to widget-oriented UI modeling: then modeled using aspect-oriented techniques: we define aspects,
each widget’s behavior is modeled separately in a UML state ma- separately from the widget machines, to define constraints on or
chine; synchronization of the state machines is modeled in aspects additional behaviors of the widgets. The overall behavior of the UI
and is woven into the widget models automatically. The weaving is then obtained by the composition of the widget machines and the
process is transparent to the modeler. This way, we can strongly aspects. We refer to the composition process as weaving.
increase the degree of separation of concerns in UI modeling and
reduce the complexity of UI models. In our approach, the complexity of widget synchronization is hid-
den behind weaving, which is transparent to the modeler. This fact
Keywords and the increased separation of concerns make our approach easy
UI modeling, UML, State machine, Aspect-oriented Modeling to use and reduce the complexity of rich-UI models considerably.
The remainder of this paper is organized as follows: in the follow-
1. INTRODUCTION ing Sect. 2 we present our modeling approach, including separate
Modern User Interfaces (UI) are mostly interactive: the widgets modeling of the widgets and aspect-oriented modeling of their syn-
are no longer supposed to be sheerly receiving input from the user chronization; in Sect. 3 a brief discussion is given on how the as-
or presenting the data of the system, but may also have inner lives pects are woven to the state machines. Related work is discussed
themselves. They may have their own states, trigger events, and call in Sect. 4, some concluding remarks, as well as an outline of our
other widgets to execute certain behaviors. For instance, besides future research, are given in Sect. 5.
acting as an input terminal for strings, a text field is more often
than not supposed to be able to automatically fill in its value, or 2. MODELING APPROACH
trigger database queries and fill in other widgets.
Our modeling approach is very simple. It contains three steps:
Separation of concerns in modeling such rich UI is challenging. On
the one hand, it is appealing to model the widgets separately from 1. Construct a top-level state machine to model the basic con-
each other, each in its own model. On the other, the synchroniza- trol flow of the application, and use submachine states as
tion of the widgets’ behaviors obviously cross-cuts the widgets. An place holders for widgets.
example is the requirement that only one of the widgets in a win- 2. Model the behaviors of the widgets and complete the subma-
dow be focused at a given time. Modeling such requirements often chines, without considering inter-widget synchronization.
torpedos the natural, widget-based separation of concerns. As a re- 3. Define necessary aspects to synchronize the widgets.
sult, the complexity of UI models may increase rapidly as soon as
the UI gets non-trivial. We demonstrate this approach by means of a simple address book
application. The application should provide two windows: the first
We propose an aspect-oriented approach to rich-UI modeling. Our containing a list of the names of all contacts and a button to show
approach enables separation of widget modeling. Each widget is the second view, the second containing text fields for inputting data
∗ of a new contact. The second window is supposed to have a rich
Partially supported by the DFG Project M AEWA (WI 841/7–2)
UI.
2.1 Top-level state machine
Pre-proceedings of the 5th International Workshop on Model Driven Development of
The first step is to model the top-level widgets, i.e., the two win-
Advanced User Interfaces (MDDAUI 2010): Bridging between User Experience and dows, see Fig. 1. When the application is started, the list of all con-
UI Engineering, organized at the 28th ACM Conference on Human Factors in tacts (ContactList, details ignored in this paper) is presented.
Computing Systems (CHI 2010), Atlanta, Georgia, USA, April 10, 2010. The user can select to add a new contact (newContact), and then
enter the contact details in NewContact. This window is sup-
Copyright © 2010 for the individual papers by the papers' authors. Copying permitted
for
Proc. 5th and
private Int.academic purposes. Re-publication
Wsh. Model-Driven of material
Development from this volume
of Advanced User Inter- posed to have nine widgets: four input fields, four labels of the
requires permission by the copyright owners. This volume is published by its editors.
faces (MDDAUI’10). input fields, and an OK button to finish the input.
1
45
NewContact pull(newText) pull(newText)
/ text = newText; / text = newText;
NameLabel NameInput
gotfocus
WaitFor
NoFocus lostfocus Input
ZipLabel ZipInput
ContactList
newContact input(t) / text = text + t; push(text);
CityLabel CityInput
quit
Figure 4: State machines for ZipInput, CityInput and
StreetLabel StreetInput StreetInput
ok OK
to be in state WaitForInput simultaneously. Modeling such
synchronization in the widget machines would break the separa-
tion of concerns, therefore we source them out and model them in
Figure 1: Top-level state machine aspects.
An aspect is in our approach a first-class model element. It contains
2.2 Widgets in Separation a restriction to or an extension of the behavior defined in some wid-
The details of the widgets’ behaviors are modeled separately in the get machine. For instance, we model the requirement that only one
sub-machines. In this step, synchronization of widgets is not con- widget is supposed to be in NoFocus by two aspects:
sidered, which simplifies the widget modeling considerably.
In our address book example, the labels have a very simple be- (aspect non-simultaneous
havior: they display some predefined text, and do not react to any (mutual-exclusion
event. This behavior is modeled with a state machine given in (transition NoFocus WaitForInput)))
Fig. 2. It contains only one state Show, presenting the label show- (aspect send-others-away
ing its caption. (before WaitForInput)
(scope except-me (goto NoFocus)))
Show
where the aspect non-simultaneous defines a restriction: only
Figure 2: State machine for the label widgets one submachine (keyword mutual-exclusion) is allowed to
fire the transition from NoFocus to WaitForInput (keyword
transition) at a given time. This aspect prevents the widget
We ignore in this paper the state machine of OK, which is also very
machines from transitioning from NoFocus to WaitForInput
simple. More interesting are the state machines of the text input
at the same time. The aspect send-others-away defines an
widgets. Figure 3 models the behavior of NameInput: it may be
additional behavior of the input widgets, to be executed just be-
either unfocused (NoFocus) or focused (WaitForInput). If it
fore (keyword before) state WaitForInput gets active: tell
is focused it is ready for user input (input(t)), and updates its
the others (scope except-me) to go to state NoFocus (goto
text (text = text + t) upon each input; otherwise it does not
NoFocus). These two aspects thus models the above synchroniza-
react to any event.
tion rule concisely and separately from the widget machines.
gotfocus
NoFocus lostfocus
WaitFor Note that using these two aspects is not the only way of preventing
Input
the input widgets from being in WaitForInput simultaneously.
input(t) / text = text + t; A direct definition of mutual exclusion of states is also possible.
Actually, such an aspect would be implemented as a combination
of the two above aspects. We decided to use the more detailed
Figure 3: State machine for NameInput
aspects, since they are closer to the weaving (see below).
The state machines for the other three input widgets are slightly Another synchronization requirement in our sample application is
more complex, see Fig. 4. Additionally to the behavior of Name- that when the window NewContact is shown, NameInput should
Input, the other three input widgets also send the current text be the focused widget, i.e. in the state WaitForInput. We model
(push(text)) to whomever it concerns, and are, focused or not, this with the following aspect has-focus, which tells the sub-
ready to receive a call back (pull(newText) from whomever machine NameInput (by scope (NameInput)) to goto state
and to update the text (text = newText). This additional fea- WaitForInput just after NewContact gets active (after
ture models the capability of automatic completion of one widget NewContext.enter).
(e.g. CityInput) by another (e.g. ZipInput). Usually, getting
a Zip code is only possible from a combination of a city and a street.
We ignore such details here and assume they are implemented cor- (aspect has-focus
rectly in pull and push. (after NewContact.enter)
(scope NameInput (goto WaitForInput)))
2.3 Synchronization by aspects
The state machines so far are simple because they do not include 3. WEAVING
synchronization with each other, which is usually necessary in a As simple as the aspects are, the implementation of the synchro-
rich UI. For example, the input widgets obviously are not supposed nization requires rather complex modification to the widget models.
2
46
NewContact One of the (many) exceptions to the above general rule is after
entry f = 1;
X.enter. Obviously an interception to all transitions leaving
NameInput X does not help in this case. Therefore, we implement after
gotfocusN /
gotoZ; gotoC; gotoS; X.enter by introducing an entry action to X. In Fig. 5, aspect
NameLabel
[else]
NoFocus lostfocus WaitFor has-focus is implemented by NewContact’s entry action, set-
gotoN Input ting f to 1, and splitting the transition leaving NameInput’s ini-
[f == 1] tial vertex to active WaitForInput immediately if f == 1.
ZipInput
A brief glance at Fig. 5 suggests how cumbersome modeling wid-
pull(newText) pull(newText) get synchronization may get. In comparison, modeling with our
/ text = newText; / text = newText; aspects is simple and straight-forward. All the complexity of ac-
gotfocusZ /
gotoN; gotoC; gotoS; tually implementing the required synchronization is hidden behind
ZipLabel NoFocus lostfocus WaitFor
the weaving (once implemented) and invisible to the modeler.
gotoZ Input
input(t) / text = text + t; push(text); 4. RELATED WORK
Model driven development is a promising paradigm for UI devel-
CityInput opment. There are several proposals of UI modeling, see [1, 5, 6,
pull(newText) pull(newText) 10, 12, 17]. In particular, state machines are also used in [14, 16],
/ text = newText; / text = newText;
gotfocusC / where the former work describes a translation of Concurrent Task
gotoN; gotoZ; gotoS;
CityLabel
NoFocus lostfocus WaitFor Tree (CTT) models into UML state machines, and the latter defines
gotoC Input an extension of UML state machines to model navigation of web
applications. Compared with these approaches, the distinguish-
input(t) / text = text + t; push(text); ing feature of our approach is its use of aspect-oriented modeling
(AOM) to model synchronization of state machines. This makes
StreetInput the UI models of our approach easy to construct and easy to use,
pull(newText) pull(newText) since the cumbersome details of interaction between widgets are
/ text = newText; / text = newText;
gotfocusS / hidden behind a (yet-to-implement) automatic weaving process.
gotoN; gotoZ; gotoC;
StreetLabel NoFocus lostfocus WaitFor
gotoS Input AOM was also applied to reduce the complexity of design mod-
els in other application areas, such as adaptive systems [2, 13, 18]
input(t) / text = text + t; push(text);
or crisis management systems [7], see in [4] for a more general
overview of aspect-oriented techniques. Compared with other pro-
OK posals of aspect-oriented state machines, such as [15, 21], the as-
pect language used in this paper is high-level in the sense that it is
used to define modifications of behaviors on a more abstract level
Figure 5: Partial weaving result of the sample application than (syntactical) modifications of modeling elements, see [19, 20]
for a more thorough dicussion on the advantages of high-level as-
pect-oriented modeling.
This modification is taken care by an automatic weaving process, 5. CONCLUSIONS AND FUTURE WORK
which is still ongoing work. With the automatic weaving, the as- We presented a widget-oriented modeling approach for interactive
pects will be composed with the base machine “off stage”, i.e., the user interfaces. Our approach uses UML state machines, a very
modeler is refrained from the cumbersome details. We explain our popular language for modeling software behaviors. By supporting
weaving by means of the weaving result of the above aspects, see aspect-oriented modeling our approach achieves a high degree of
Fig. 5. separation of concerns, and thus increases the feasibility of widget-
oriented UI modeling considerably.
Mutual exclusion of transitions is implemented by a static renaming
the events of the transitions, so that the transitions are no longer We plan to integrate the aspect language into HiLA1 , our general
enabled at the same time. In Fig. 5, aspect non-simultaneous approach to aspect-oriented state machines. Using state machines
is therefore implemented by renaming the event gotfocus in the as the modeling language, and in particular the definition the weav-
widget models to gotfocusN, gotfocusZ, gotfocusI, and ing result in the form of a state machine, makes it possible to ver-
getfocusS. ify the weaving result by formal methods like model checking or
theorem proving. In particular, we plan to apply the UML model
Generally, before X and after X are woven by intercepting checker Hugo/RT [8] to verify temporal logical properties of our
all transitions leading to and leaving state X, respectively; goto UI models.
X is woven by introducing a new transition to X and sending a
signal to the respective state machine to fire that transition. In 6. REFERENCES
Fig. 5, aspect send-others-away is implemented as an addi- [1] Goetz Botterweck. A Model-Driven Approach to the
tional transition in the widget machines from WaitForInput to Engineering of Multiple User Interfaces. In Thomas Kühne,
NoFocus, triggered by a uniquely named event (gotoN, gotoZ, editor, Reps. and Rev. Sel. Papers Wshs and Symp. at
gotoC, gotoS), and an effect of the transition from NoFocus to
WaitForInput, firing the “right” events. 1
http://hila.pst.ifi.lmu.de
3
47
MoDELS’06, volume 4364 of Lect. Notes in Comp. Sci., [13] Andrea Schauerhuber. aspectUWA: Applying
pages 106–115. Springer, 2007. Aspect-Orientation to the Model-Driven Development of
Ubiquitous Web Applications. PhD thesis, Technische
[2] Sven Casteleyn, William Van Woensel, and Geert-Jan Universität Wien, 2007.
Houben. A Semantics-based Aspect-oriented Approach to
Adaptation in Web Engineering. In Simon Harper, Helen [14] Jan Van den Bergh and Karin Coninx. From Task to Dialog
Ashman, Mark Bernstein, Alexandra I. Cristea, Hugh C. Model in the UML. In Marco Winckler, Hilary Johnson, and
Davis, Paul De Bra, Vicki L. Hanson, and David E. Millard, Philippe A. Palanque, editors, Proc. 6th Int. Wsh. Task
editors, Proc. 18th ACM Conf. Hypertext and Hypermedia Models and Diagrams for User Interface Design
(HYPERTEXT’07), pages 189–198. ACM, 2007. (TAMODIA’07), volume 4849 of Lect. Notes Comp. Sci.,
pages 98–111. Springer, 2007.
[3] Gregor Engels, Bill Opdyke, Douglas C. Schmidt, and Frank
[15] Jon Whittle, Ana Moreira, João Araújo, Praveen K.
Weil, editors. Proc. 10th Int. Conf. Model Driven
Jayaraman, Ahmed M. Elkhodary, and Rasheed Rabbi. An
Engineering Languages and Systems (MoDELS’07), volume
Expressive Aspect Composition Language for UML State
4735 of Lect. Notes Comp. Sci. Springer, 2007.
Diagrams. In Engels et al. [3], pages 514–528.
[4] Robert E. Filman, Tzilla Elrad, Siobhán Clarke, and Mehmet [16] Marco Winckler and Philippe A. Palanque. StateWebCharts:
Aksit, editors. Aspect-Oriented Software Development. A Formal Description Technique Dedicated to Navigation
Addison-Wesley, 2004. Modelling of Web Applications. In Joaquim A. Jorge,
Nuno Jardim Nunes, and João Falcão e Cunha, editors, Proc.
[5] Guillaume Gauffre, Emmanuel Dubois, and Rémi Bastide. 10th Int. Wsh. Design Specification and Verification of
Domain-Specific Methods and Tools for the Design of Interactive Systems (DSV-IS’03), volume 2844 of Lect. Notes
Advanced Interactive Techniques. In Holger Giese, editor, Comp. Sci., pages 61–76. Springer, 2003.
Reps. and Rev. Sel. Papers Wshs and Symp. at MoDELS’07,
volume 5002 of Lect. Notes in Comp. Sci., pages 65–76. [17] Andreas Wolff and Peter Forbrig. Deriving User Interfaces
Springer, 2008. from Task Models. In Meixner et al. [9].
[6] Daniel Görlich and Kai Breiner. Useware Modeling for [18] Gefei Zhang. Aspect-Oriented Modeling of Adaptive Web
Ambient Intelligent Production Environments. In Andreas Applications with HiLA. In Gabriele Kotsis, David Taniar,
Pleuß, Jan Van den Bergh, Heinrich Hußmann, Stefan Sauer, Eric Pardede, and Ismail Khalil, editors, Proc. 7th Int. Conf.
and Daniel Görlich, editors, Proc. Workshop Model Driven Advances in Mobile Computing & Multimedia (MoMM’09),
Development of Advanced User Interfaces (MDDAUI’07), pages 331–335. ACM, 2009.
volume 297 of CEUR Workshop Proceedings. CEUR, 2007. [19] Gefei Zhang and Matthias Hölzl. HiLA: High-Level Aspects
for UML State Machines. In 14th Int. Wsh. Aspect-Oriented
[7] Matthias Hölzl, Alexander Knapp, and Gefei Zhang. Modeling (AOM@MoDELS’09), Denver, 2009.
Modeling the Car Crash Crisis Management System with
HiLA. Trans. Aspect-Oriented Software Development [20] Gefei Zhang, Matthias Hölzl, and Alexander Knapp.
(TAOSD), 7, 2010. Accepted. Enhancing UML State Machines with Aspects. In Engels
et al. [3], pages 529–543.
[8] Alexander Knapp, Stephan Merz, and Christopher Rauh.
Model Checking Timed UML State Machines and [21] Jing Zhang, Thomas Cottenier, Aswin van den Berg, and Jeff
Collaborations. In Werner Damm and Ernst Rüdiger Gray. Aspect Composition in the Motorola Aspect-Oriented
Olderog, editors, Proc. 7th Int. Symp. Formal Techniques in Modeling Weaver. Journal of Object Technology,
Real-Time and Fault Tolerant Systems, volume 2469 of Lect. 6(7):89–108, 2007.
Notes Comp. Sci., pages 395–416. Springer, 2002.
[9] Gerrit Meixner, Daniel Görlich, Kai Brainer, Heinrich
Hußmann, Andreas Pleuß, Stefan Sauer, and Jan Van den
Bergh, editors. Proc. 4th Wsh. Model Driven Development of
Advanced User Interfaces (MDDAUI’09), volume 439 of
CEUR Workshop Proceedings. CEUR, 2009.
[10] Gerrit Meixner, Marc Seissler, and Marcel Nahler. Udit—A
Graphical Editor for Task Models. In Meixner et al. [9].
[11] Object Management Group. OMG Unified Modeling
Language (OMG UML), Superstructure, Version 2.2. OMG
Available Specification, OMG, 2009. http://www.omg.
org/spec/UML/2.2/Superstructure.
[12] Andreas Pleuß, Arnd Vitzthum, and Heinrich Hußmann.
Integrating Heterogeneous Tools into Model-Centric
Development of Interactive Applications. In Engels et al. [3],
pages 241–255.
4
48