=Paper=
{{Paper
|id=Vol-159/paper-7
|storemode=property
|title=Using UML 2.0 and Profiles for Modelling Context-Sensitive User Interfaces
|pdfUrl=https://ceur-ws.org/Vol-159/paper7.pdf
|volume=Vol-159
|dblpUrl=https://dblp.org/rec/conf/uml/BerghC05
}}
==Using UML 2.0 and Profiles for Modelling Context-Sensitive User Interfaces==
https://ceur-ws.org/Vol-159/paper7.pdf
Using UML 2.0 and Profiles for Modeling Context-Sensitive
User Interfaces
Jan Van den Bergh Karin Coninx
Hasselt University
Expertise Centre for Digital Media
and
transnationale Universiteit Limburg
School of Information Technology
Wetenschapspark 2
BE-3590 Diepenbeek
Belgium
{jan.vandenbergh, karin.coninx}@uhasselt.be
ABSTRACT the semantics of the MB-UID models. The reason for this
Significant work has been established in both the HCI com- approach is that usage of the same (basic) meta-model al-
munity and the software engineering community to structure lows easier integration of the different approaches, which can
and to rationalize development within their respective fields be necessary to create truly usable (context-sensitive) appli-
using abstractions that are crystallized into a limited set of cations. After all, usability issues are related to application
models. Each of these models gives a precise definition of characteristics beyond the user interface.
one of the aspects of the design. In this position paper we For the modeling of context-sensitive user interfaces, we
present a more detailed analysis describing how UML 2.0 consider a limited set of models as shown in figure 1. In this
and its light-weight extension mechanism, profiles, can be paper we will shortly discuss the different models and how
used to model both the dynamic and structural aspects of they can be represented in UML 2.0. We will focus on the
context-sensitive user interfaces. core models that deal with the representation of the dynamic
and structural aspects of the user interface. The dynamics
are described in the task and dialog model, while the struc-
Categories and Subject Descriptors ture is described in the abstract and concrete presentation
H.5.2 [User Interfaces]: Screen design—Abstract User In- models, optionally complemented with a user interface de-
terfaces; D.2.2 [Design Tools and Techniques]: User ployment model. Finally, conclusions and future work are
Interfaces, Flow charts, Object-Oriented design methods— presented in section 5.
UML 2.0, Model-Driven Design, Model-based Design of User
Interfaces 2. MODEL OVERVIEW
In figure 1, the different models we consider to be impor-
General Terms tant for model-driven design of user interfaces are graphi-
Model Driven Development of User Interfaces, UML 2.0, cally depicted. The figure is divided into four sections. The
profiles upper half of the figure contains the platform independent
models (PIM), while the lower half contains the platform-
specific models (PSM). Similarly, the models at the left de-
1. INTRODUCTION scribe some structural aspects, while the right-hand side de-
The number of devices and their capabilities is very divers scribes the behavioral models. All models are specified using
and becoming even more so. Model-based Design of User In- UML 2.0, except the one with the gray background.
terfaces (MB-UID) is a methodology often proposed to sup- In the upper right part of the figure, the task model is
port the design and development of multi-platform, and even shown. It describes the tasks that have to be performed to
context-sensitive user interfaces. In the software engineer- reach a certain goal. The dialog model is a more concrete
ing camp, model-driven development is proposed for solving version of the task model in that it describes how the user
similar problems. Both approaches use different models, but can perform the tasks through a user interface and how the
sometimes they have similar semantics. system responds to these actions. The task (and dialog)
As part of our effort to model context-sensitive interactive model is discussed into more detail in section 3, the reason
applications, we want to express the models used in MB-UID for having two instances of the task model is explained in
using the UML 2.0 and extend it using profiles where neces- section 3.4.
sary. In this paper, we present an analysis describing which The structural platform independent models consist of the
diagrams in UML 2.0 [8] have semantics that correspond context model and application model, which can be con-
best to most used models in MB-UID. Based on this analysis sidered to grossly correspond to the domain model used
we present our choice of UML-diagrams for abstract/high- in software engineering approaches, and the (abstract) pre-
level models and the profiles we designed to extend the se- sentation model. The latter describes the structure of the
mantics of the UML 2.0 models so that they better reflect user interface in a way that is independent of platform and
3.3 Corresponding diagram
Since the task model defines the required behavior of the
user (and the system), only behavior models can have the
required semantics. Another criterion is that a single task
model can be used in multiple scenario’s. Furthermore, the
users and their actions are central in this model. These
properties can only be matched by two diagram types. The
use case diagram highlights the system and the users for
specific use cases. Therefore, the use case diagram can be
useful for initial discovery and requirements analysis. It is
not suitable to make a detailed design.
The activity diagram is the most suitable to represent the
task model for the following reasons:
• Actions and the temporal relations between them are
the focus of this diagram type.
• Links with the concepts that are manipulated by the
Figure 1: Models for specification of context- actions can be specified.
sensitive user interfaces • One can specify the actor for each action.
• One can establish hierarchies to cope with complexity;
modality and is discussed into more detail in section 4. actions can be bundled in activities. Each activity
can be shown in a separate diagram, but also within a
containing diagram.
3. TASK AND DIALOG MODEL
• The semantics using token-flow allow a tool or designer
3.1 Generic Model Description to verify which actions can be performed at a certain
A task model describes the tasks of a user interacting with moment in time (and thus allow derivation of a dialog
a system to accomplish a certain goal. It is a hierarchically diagram, something which is also possible using CTT).
structured model that describes the compositional and of- In related work, Nobrega et al. [6] already used the activ-
ten also temporal relationships of a certain activity. The ity diagram as the basis for a new diagram type to express
dialog model describes how the tasks can be performed by the CTT in a tree-based UML diagram. Pinheiro da Silva
the user (in interaction with the system); it thus is a lower- and Paton [2] defined a flow-based diagram type that de-
level, platform-dependent version of a task model and can fined special object flows to objects that represented user
be derived to a great extend of the task model. interface elements. It was based on the State Machine pack-
In case of context-sensitive applications, a task model can age, to create a special form of activity diagram 1 . The use
also contain references to context. A task and dialog model case diagram [2, 7] and the class diagram [7] — it was ex-
can contain references to concepts since many tasks involve tended using stereotypes to define a semantical equivalent of
some kind of object: e.g. the name of a person, (the date the CTT notation in UML 1.x — were also used to express
of) an appointment. the task model.
3.2 Properties 3.4 ConcurTaskTrees and Activity Diagrams
One of the well accepted task notations for MB-UID is
the graphical ConcurTaskTrees (CTT) notation [4]. This The ConcurTaskTrees notation is one of the most well ac-
notation uses a tree structure to decompose a task into sub- cepted task modeling notations. We investigated whether
tasks, which are either performed by the user, the system or mapping this tree-based structure with different task cat-
by the user in interaction with the system. A fourth category egories and temporal operators to the flow-based notation
of task (abstract task) is used when a task has subtasks of used in the activity diagram is possible. The mapping of the
a different type. Sibling tasks are connected using temporal temporal operators could pose problems [6]. Although two
operators and each task can have a loose, more fine-grained temporal operators from the CTT notation, suspend/resume
specification of the type of task, the involved objects, per- and order independence, do not have direct corresponding
formance statistics, etc. elements in UML, their behavior can be modeled using the
Some adapted notations have been proposed for specific activity diagram notation. The suspend/resume behavior
purposes. The Contextual CTT [9] is one such notation, can be modeled by nesting the suspending actions in a Struc-
which introduces “environment tasks/actions” which are per- turedActivityNode with its attribute mustIsolate set to true,
formed by an entity which is nor the system nor the user. and placing it in parallel to the suspended actions. The or-
Examples of environment actions can be location changes der independent operator can be modeled in a similar fash-
(in case of interaction with a mobile device) or a change in ion.
privacy (e.g. someone entering the room) or an incoming It is possible to create a hierarchy using the combination of
phone call while interacting with a mobile phone applica- actions and (invoked) activities. Furthermore, the categories
tion. 1
In UML 1.x the activity diagram was based on the state
machine diagram.
(a) (b) (c) (d)
Figure 2: Action stereotypes: (a) user, (b) device,
(c) interact and (d) environment
of tasks in (Contextual) CTT can be provided by extending
the activity diagram with a profile containing a stereotype
for each type of task/action (see figure 2 and 4). Note that
we opted to specify no special stereotype for the category of
abstract tasks. A more detailed explanation of the reasons
for this decision can be found in [10].
As can be seen in figure 1, we opted to keep two represen- Figure 3: Example presentation model
tations for the task model; one, the (Contextual) Concur-
TaskTrees, gives a tree-based representation of the model
and highlights the user’s mental model, while the second, number of different interactors is still limited.
using the activity diagram, uses a flow-based structure and
gives the interactive system and the manipulated objects a 4.3 Corresponding Diagram
more prominent place. In this way, the advantages of both Presentation models, both abstract and concrete 2 , define
notations can be combined. the structure of a user interface by specifying relationships
between different classes of objects, which can be expressed
4. PRESENTATION MODEL using class diagrams as is done in the Wisdom approach [7].
UMLi [2] on the other hand, defines a new diagram-type
4.1 Generic Model Description similar to a UML deployment diagram. Usage of a stereo-
The presentation model represents the structure of a user typed deployment diagram as introduced in [10] to define
interface. It can be modeled at three levels of abstraction: the presentation structure was confusing for the software
abstract user interface, concrete user interface and final user engineering community due to the differences in semantics.
interface. In the following sections we will only discuss Just as in the Wisdom approach, we propose to model the
the abstract presentation model. The concrete presenta- user interface structure using the class diagram. We however
tion model already deals with the real appearance of a user use a different set of stereotypes as we have different priori-
interface, which can be represented more adequately using ties for the presentation diagram (a subset of the stereotypes
specialized tools that can offer better support for all avail- can be seen in figure 4). We want to emphasize the cate-
able widgets and style options. The final user interface is gories of the user interface parts a user will interact with:
the running, deployed user interface. actionComponent (part of the user interface that triggers
The goal of the abstract presentation model is to define the activation of a function in the application’s functional
the structure of the user interface in a platform-independent core), inputComponent (part of the user interface that al-
manner. This implies that no assumptions can be made re- lows the user to specify values) or outputComponent (part of
garding platform, toolkit or modality. One reason to have the user interface that presents data, such as search results
such a model is to derive interfaces for different platforms or a system notification, to the user). We do this by provid-
and/or toolkits that have a consistent structure. Another ing alternative representations for these stereotyped classes
reason is that the focus can be kept on structure and the and by not specifying them as attributes of groupCompo-
functionality a user expects rather than on low-level imple- nents, but as separate classes. By defining them as separate
mentation details. This is especially important when multi- classes, we can also show the type of data that inputCom-
platform designs are made. ponents manipulate and outputComponents present, as well
as the operations that actionComponents can present. We
4.2 Properties do this because the type of data that is manipulated can
be important to determine an effective representation for a
There isn’t as much consensus about the contents of the
specific context (platform, user, etc.).
abstract presentation model as there is about for example
An example of a very simple abstract presentation model
the task model. The number of concepts that are avail-
is shown in figure 3. We can see from this example that
able as well as their exact nature differs greatly. Some ap-
at the abstract level, a class-name refers to the function
proaches [3, 10] offer a very limited set of abstract inter-
of the class, not to how it is represented in an actual user
actors, while others [5, 1] offer a larger set of interactors.
interface. A groupComponent is connected with the user
While [3] focuses on aspects of the abstract interactors, oth-
interface components it contains (in this case two input-
ers[10, 5, 1] offer a hierarchically structured set of interac-
Components) through containment associations. These as-
tors. Another distinction is that some authors focus on the
abstraction of concrete interactors [3, 5], others focus on 2
We will only discuss the abstract presentation diagram
the related actions of the user [1, 10]. All these approaches since the concrete presentation diagram can be modeled
however have in common that due to the abstraction the without extensions using profiles if desired.
In the near future, we will investigate how the different
models can be combined or synchronized so that the designer
can more easily identify where a specific diagram belongs in
the overall design. This will involve combining the structural
models into a single view that combines both the context
and the abstract presentation model and will define several
associations (such as update, enable or disable) that can
be used to express the relationships across and within the
models.
6. ACKNOWLEDGEMENTS
Part of the research at Expertise Centre for Digital Media
is funded by the ERDF (European Regional Development
Fund), the Flemish Government and the Flemish Interdis-
ciplinary institute for BroadBand Technology (IBBT).
7. REFERENCES
[1] Larry L. Constantine. Canonical abstract prototypes
for abstract visual and interaction design. In
Proceedings of DSV-IS 2003, number 2844 in LNCS,
Figure 4: Relevant parts of the UML profile
pages 1 – 15, Funchal, Madeira Island, Portugal, June
11-13 2003. Springer.
sociations can have multiplicities, allowing effective speci- [2] Paulo Pinheiro da Silva and Norman W. Paton. User
fication of a variable set of inputComponents, such as the interface modelling in umli. IEEE Software,
“Enter Company Info” inputComponent in the example. An 20(4):62–69, July–August 2003.
inputComponent, such as “Enter PersonalInfo”, can have [3] Quentin Limbourg and Jean Vanderdonckt.
several aspects that will be represented by a set of user in- Engineering Advanced Web Applications, chapter
terface components in a final user interface. UsiXML: A User Interface Description Language
We are investigating the use of additional profiles to ex- Supporting Multiple Levels of Independence. Rinton
press meta-information. This meta-information can specify Press, December 2004.
how public the data or controls in some parts of the inter- [4] Giulio Mori, Fabio Paternò, and Carmen Santoro.
face are. For example: the interface of presentation-software CTTE: support for developing and analyzing task
might have marked the part that displays the presentation models for interactive system design. IEEE
as public, while the controls to manipulate the presentation Transactions on Software Engineering, 28(8):797–813,
are private and thus are only shown on the monitor of the 2002.
person giving a talk. Similarly, a log in can be marked pri- [5] Giulio Mori, Fabio Paternò, and Carmen Santoro.
vate, while the password can be marked secret to denote Design and development of multidevice user interfaces
that its contents should be masked or hidden. The use of through multiple logical descriptions. IEEE
such meta data can help the designer (or a transformation Transactions on Sofware Engineering, 30(8):507–520,
tool) to choose concrete user interface elements and/or to aug 2004.
allocate those elements to interaction devices. [6] Leonel Nobrega, Nuno Jardim Nunes, and Helder
Another profile can contain the level to which a part of a Coelho. Mapping concurtasktrees into uml 2.0. In
user interface can be affected by context information. Such Proceedings of DSV-IS 05, 2005.
a profile might contain stereotypes such as: ”context-init”, [7] Nuno Jardim Nunes and Joao Falcao e Cunha.
initialized by a value provided by a source in the environ- Towards a uml profile for interaction design: the
ment of the system and the user, ”context-updated”, up- wisdom approach. In UML 2000, pages 117–132.
dated with context information while active, etc. Awareness Springer, 2000.
of parts of the user interface that are influenced by external [8] Object Management Group. UML 2.0 Superstructure
factors or initialized by external entities can be benifitial Specification, October 8 2004.
to the overall feel of the application. It can persuade the [9] Jan Van den Bergh and Karin Coninx. Contextual
software engineer to introduce the necessary measures that ConcurTaskTrees: Integrating dynamic contexts in
ensure that responsiveness is maintained and that the user task based design. In Second IEEE Conference on
interface reacts appropriately when the context input lacks Pervasive Computing and Communications
besides ensuring that the influences of the context are pos- WORKSHOPS, pages 13–17, Orlando, FL, USA,
sible. March 14–17 2004. IEEE Press.
[10] Jan Van den Bergh and Karin Coninx. Towards
5. CONCLUSIONS AND FUTURE WORK Modeling Context-Sensitive Interactive Applications:
the Context-Sensitive User Interface Profile (CUP). In
We presented an approach to create context-sensitive user
SoftVis ’05: Proceedings of the 2005 ACM symposium
interfaces using models expressed in UML 2.0. The approach
on Software visualization, pages 87–94, New York,
is being tested by creating a limited context-sensitive user
NY, USA, 2005. ACM Press.
interface using the presented approach.