Separated modeling of User Interface (UI) widgets is a very natural way to tackle the complexity of UI models. Due to interactions between widgets, however, this is not always an easy task. We propose an aspect-oriented approach to widget-oriented UI modeling: each widget's behavior is modeled separately in a UML state machine; synchronization of the state machines is modeled in aspects and is woven into the widget models automatically. The weaving process is transparent to the modeler. This way, we can strongly increase the degree of separation of concerns in UI modeling and reduce the complexity of UI models.
Separation of concerns in modeling such rich UI is challenging. On the one hand, it is appealing to model the widgets separately from each other, each in its own model. On the other, the synchronization of the widgets’ behaviors obviously cross-cuts the widgets. An example is the requirement that only one of the widgets in a window be focused at a given time. Modeling such requirements often torpedos the natural, widget-based separation of concerns. As a result, the complexity of UI models may increase rapidly as soon as the UI gets non-trivial.
We propose an aspect-oriented approach to rich-UI modeling. Our approach enables separation of widget modeling. Each widget is ∗Partially supported by the DFG Project MAEWA (WI 841/7–2) Copyright © 2010 for the individual papers by the papers' authors. Copying permitted th fPorropcri.va5te aInndt.acWadesmh.icMpuordpoesl-eDs.rRivee-pnubDliecvaetiloonpomf emnatteorfiaAlfdrovmantcheisdvUolsuemreInterrfeaqcueirse(sMpeDrmDiAssUionI’b1y0)th.e copyright owners. This volume is published by its editors. modeled in its own UML state machine [11], separated from other widgets. We call the state machines widget machines. Necessary synchronization between widgets, if any, is left out of the widget machines, which keeps them rather simple. The synchronization is then modeled using aspect-oriented techniques: we define aspects, separately from the widget machines, to define constraints on or additional behaviors of the widgets. The overall behavior of the UI is then obtained by the composition of the widget machines and the aspects. We refer to the composition process as weaving. In our approach, the complexity of widget synchronization is hidden behind weaving, which is transparent to the modeler. This fact and the increased separation of concerns make our approach easy to use and reduce the complexity of rich-UI models considerably. The remainder of this paper is organized as follows: in the following Sect. 2 we present our modeling approach, including separate modeling of the widgets and aspect-oriented modeling of their synchronization; in Sect. 3 a brief discussion is given on how the aspects are woven to the state machines. Related work is discussed in Sect. 4, some concluding remarks, as well as an outline of our future research, are given in Sect. 5.
Our modeling approach is very simple. It contains three steps: 1. Construct a top-level state machine to model the basic control flow of the application, and use submachine states as place holders for widgets. 2. Model the behaviors of the widgets and complete the submachines, without considering inter-widget synchronization. 3. Define necessary aspects to synchronize the widgets. We demonstrate this approach by means of a simple address book application. The application should provide two windows: the first containing a list of the names of all contacts and a button to show the second view, the second containing text fields for inputting data of a new contact. The second window is supposed to have a rich UI.
The first step is to model the top-level widgets, i.e., the two windows, see Fig. 1. When the application is started, the list of all contacts (ContactList, details ignored in this paper) is presented. The user can select to add a new contact (newContact), and then enter the contact details in NewContact. This window is supposed to have nine widgets: four input fields, four labels of the input fields, and an OK button to finish the input. ContactList quit newContact NameLabel
NameInput
The details of the widgets’ behaviors are modeled separately in the sub-machines. In this step, synchronization of widgets is not considered, which simplifies the widget modeling considerably. In our address book example, the labels have a very simple behavior: they display some predefined text, and do not react to any event. This behavior is modeled with a state machine given in Fig. 2. It contains only one state Show, presenting the label showing its caption.
Show We ignore in this paper the state machine of OK, which is also very simple. More interesting are the state machines of the text input widgets. Figure 3 models the behavior of NameInput: it may be either unfocused (NoFocus) or focused (WaitForInput). If it is focused it is ready for user input (input(t)), and updates its text (text = text + t) upon each input; otherwise it does not react to any event. The state machines for the other three input widgets are slightly more complex, see Fig. 4. Additionally to the behavior of NameInput, the other three input widgets also send the current text (push(text)) to whomever it concerns, and are, focused or not, ready to receive a call back (pull(newText) from whomever and to update the text (text = newText). This additional feature models the capability of automatic completion of one widget (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 correctly in pull and push.
The state machines so far are simple because they do not include synchronization with each other, which is usually necessary in a rich UI. For example, the input widgets obviously are not supposed pull(newText) / text = newText;
gotfocus NoFocus lostfocus WaitFor
Input to be in state WaitForInput simultaneously. Modeling such synchronization in the widget machines would break the separation of concerns, therefore we source them out and model them in aspects.
An aspect is in our approach a first-class model element. It contains a restriction to or an extension of the behavior defined in some widget machine. For instance, we model the requirement that only one widget is supposed to be in NoFocus by two aspects: (aspect non-simultaneous (mutual-exclusion
(transition NoFocus WaitForInput))) (aspect send-others-away (before WaitForInput) (scope except-me (goto NoFocus))) where the aspect non-simultaneous defines a restriction: only 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 machines from transitioning from NoFocus to WaitForInput at the same time. The aspect send-others-away defines an additional behavior of the input widgets, to be executed just before (keyword before) state WaitForInput gets active: tell the others (scope except-me) to go to state NoFocus (goto NoFocus). These two aspects thus models the above synchronization rule concisely and separately from the widget machines. Note that using these two aspects is not the only way of preventing the input widgets from being in WaitForInput simultaneously. 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 aspects, since they are closer to the weaving (see below). Another synchronization requirement in our sample application is that when the window NewContact is shown, NameInput should be the focused widget, i.e. in the state WaitForInput. We model this with the following aspect has-focus, which tells the submachine NameInput (by scope (NameInput)) to goto state WaitForInput just after NewContact gets active (after NewContext.enter). (aspect has-focus (after NewContact.enter) (scope NameInput (goto WaitForInput)))
As simple as the aspects are, the implementation of the synchronization requires rather complex modification to the widget models. entry f = 1; This modification is taken care by an automatic weaving process, which is still ongoing work. With the automatic weaving, the aspects will be composed with the base machine “off stage”, i.e., the modeler is refrained from the cumbersome details. We explain our weaving by means of the weaving result of the above aspects, see Fig. 5.
Mutual exclusion of transitions is implemented by a static renaming the events of the transitions, so that the transitions are no longer enabled at the same time. In Fig. 5, aspect non-simultaneous is therefore implemented by renaming the event gotfocus in the widget models to gotfocusN, gotfocusZ, gotfocusI, and getfocusS.
Generally, before X and after X are woven by intercepting all transitions leading to and leaving state X, respectively; goto X is woven by introducing a new transition to X and sending a signal to the respective state machine to fire that transition. In Fig. 5, aspect send-others-away is implemented as an additional transition in the widget machines from WaitForInput to NoFocus, triggered by a uniquely named event (gotoN, gotoZ, gotoC, gotoS), and an effect of the transition from NoFocus to WaitForInput, firing the “right” events.
One of the (many) exceptions to the above general rule is after X.enter. Obviously an interception to all transitions leaving X does not help in this case. Therefore, we implement after X.enter by introducing an entry action to X. In Fig. 5, aspect has-focus is implemented by NewContact’s entry action, setting f to 1, and splitting the transition leaving NameInput’s initial vertex to active WaitForInput immediately if f == 1. A brief glance at Fig. 5 suggests how cumbersome modeling widget synchronization may get. In comparison, modeling with our aspects is simple and straight-forward. All the complexity of actually implementing the required synchronization is hidden behind the weaving (once implemented) and invisible to the modeler.
Model driven development is a promising paradigm for UI
development. There are several proposals of UI modeling, see [
We presented a widget-oriented modeling approach for interactive user interfaces. Our approach uses UML state machines, a very popular language for modeling software behaviors. By supporting aspect-oriented modeling our approach achieves a high degree of separation of concerns, and thus increases the feasibility of widgetoriented UI modeling considerably.
We plan to integrate the aspect language into HiLA1, our general approach to aspect-oriented state machines. Using state machines as the modeling language, and in particular the definition the weaving result in the form of a state machine, makes it possible to verify the weaving result by formal methods like model checking or theorem proving. In particular, we plan to apply the UML model checker Hugo/RT [8] to verify temporal logical properties of our UI models. 1http://hila.pst.ifi.lmu.de [7] Matthias Ho¨lzl, Alexander Knapp, and Gefei Zhang.
Modeling the Car Crash Crisis Management System with HiLA. Trans. Aspect-Oriented Software Development (TAOSD), 7, 2010. Accepted.