Design for Change Patterns and Component 001
Design for Change: Patterns and Components
for Flexible UI Development
Daniel Sinnig1,2, Homa Javahery2, Jovan Strika3, Peter Forbrig1 and Ahmed Seffah2
(1) Software Engineering Group
University of Rostock
Albert-Einstein-Str.21
18051 Rostock, Germany
{dasin, pforbrig}@
informatik.uni-rostock.de
(2) HC SE Group
Concordia University
1455 De Maisonneuve Blvd.
Montreal, Canada H3G 1M8
{h_javahe,seffah}@
cs.concordia.ca
(3) Dotalis R & D Group
2121 St. Mathieu, Suite 506
Montreal, Canada
H3H 2J3
jstrika@dotalis.com
Abstract
The paper studies relations between patterns and components for user-interface
design. It demonstrates how components can be considered as implementations
of patterns. It also discusses the support of patterns for reverse- and
reengineering of existing software. This can especially support the transfer of
software to new platforms and devices.
Introduction
Software applications, in general, have become more and more complex. User interfaces are
no exception to this rule, and current trends in user interface (UI) design are rapidly evolving.
The web, as a vital medium for information transfer, has had an impact on UI design.
Although software application logic development has become increasingly driven by
engineering techniques and principles, the development of the UI has remained “ad-hoc” and
thus has resulted – from a software engineering point of view – in applications of poor
architectural quality, causing tremendous costs for maintenance and further evolution [Gaedke
et al. 00]. Writing code from scratch is no longer a viable solution. The lack of standards and
the broad diversity of technologies have led to the fact that no efficient concept for reuse of
solutions and designs has been established yet.
To support systematic UI development, a process incorporating a disciplined form of reuse is
needed. The lack of methods in UI development motivated us to explore the combination of
components and patterns as core constituents for a novel reuse approach. Patterns help in the
reuse of well-known and proven design solutions, and play a significant role throughout the
whole UI development process. Components embody reusable solutions at the
implementation level.
Core constituents: Patterns and Components
Patterns in UI development are an effective way to transmit experience about recurrent
problems in the HCI domain. They have the potential to inherently promote the reuse of ideas
and knowledge. From experiences with implementation reuse, it is known that an effective
concept of reuse should include these three different dimensions: Encapsulation,
Composition, and Customization. The concept of patterns addresses all three reuse
dimensions. Naturally and by definition, patterns are encapsulations of solutions to problems
in a specific context of use. In addition, the concept of pattern languages implies that patterns
can be combined and nested depending on their relationships. Last but not least, patterns
embody solutions, which occur over and over again in different situations. Therefore patterns
are not static, and must be customized to the current context of use.
A software component can be defined as a unit of composition with a clearly defined
interface, enabling independent deployment and third-party reuse. As a result, it enables
practical reuse across multiple applications [Szyperski 98]. Components are a suitable means
to implement patterns on a particular platform [Sinnig 04]. Once an appropriate pattern has
been chosen and instantiated, a suitable component can be picked to implement the particular
pattern instance. In the same way as patterns, components can also be customized and adapted
to different contexts of use. Patterns, in general, are of rather conceptual nature and abstract
from concrete implementation language independent issues. This generic nature of patterns
allows the designer to think “outside” the toolkit at hand [Tidwell 04]. When it comes down
to the implementation, the previously conceptually designed aspects for the application must
be carried out using a particular programming environment and framework.
In the following we will suggest a UI development process, which incorporates both patterns
and components. It will be shown that due to these two core constituents, the process is highly
flexible and adaptable. Furthermore, such an integrated approach of using patterns with
software components can be a practical step in bridging the conceptual gap that currently
exists between the domains of Software Engineering and Human-Computer Interaction;
where patterns act as the conceptual design solution used by HCI practitioners and
components are the concrete realization and implementation of such design solutions,
produced and used by Software Engineers.
The Pattern and Component – Based UI Development Process
The Pattern and Component-Based (PCB) process allows for flexible and systematic UI
development, by unifying pattern and component-based methodologies into one systematic
process. As portrayed in Figure 1 the process consists of six logical and mutually successive
steps going from the conceptual to implementation level.
Step 1: Pattern Selection.
The PCB process begins after the analysis phase and the requirements specification. It is
assumed that the problem domain has already been precisely specified. A set of appropriate
patterns is selected to tackle different design aspects of the UI. Patterns are problem oriented,
proposing a solution to a problem, which is applicable in a certain context of use. As
demonstrated in chapter 2 different kinds of UI patterns (task, dialog, presentation and layout)
exist for tackling different aspects of the UI. Choosing appropriate patterns correctly depends
strongly on the experience and the creativity of the designer; these selected patterns will shape
the basic nature of the future UI.
Step 2: Pattern Instantiation.
A pattern is an abstraction that must be instantiated. Before the pattern solution stated in the
pattern is really tangible and applicable, it must be adapted to the current context of use. The
second step of the PCB process consists of adjusting the patterns of step 1 according to the
context of use resulting in a set of pattern instances.
At this point it is noteworthy that there is no universal accepted definition of “context”.
Researchers from different fields have given their own definitions of context. For instance,
Shilit and Theimer defined context as the location, the identities of people around, and the
equipment nearby [Shilit et al. 93]. Schmidt defined the context as the user’s social and
physical environments, as well as the task being performed [Schmidt et al. 99].
The term “context” addresses a very broad field. However, patterns are platform and
implementation independent, therefore the context factors to be considered in this step focus
on conceptualities such as the target user groups, target devices or environmental factors.
This pattern adaptation phase can be seen as a first “basic” tuning of the further application,
without being specific about the implementation and/or the programming language.
Step 3: Model Construction.
In this step the various patterns instances are associated to different declarative UI models. In
particular as described in chapter 2 the pattern instances are used as building blocks to form
the various models; these models contain declarative descriptions of the UI facets. If
necessary, other artifacts and information may be consulted as well to form the models. For
example, personae and archetypes help in the creation of a user task model. Many facets exist
as well as related models: Task, domain, user, device, platform, application, presentation,
dialogue, navigation, etc. [Vanderdonckt et al. 03]. For the sake of simplicity, Figure 1 shows
only the User-Task, the Navigation, the Presentation and the Layout model. We summarize
the models, which are related to the user interface under the term UI Multi-Model.
[Vanderdonckt et al. 03].
Step 4: Component Selection.
Until now, the user interface is viewed and defined by the UI Multi-Model at a conceptual
level. The remaining steps of the process, however, are concerned with the concrete
implementation issues of the user interface. Therefore, components are picked in order to
implement the UI according to the UI Multi-Model. In particular, since the models are mainly
formed and established by patterns, components to implement the various patterns are chosen.
If such a component does not exist, it must be developed and implemented. At this point it is
to be noted that one component may serve as an implementation for several related patterns.
Step 5: Component Adaptation.
The various components are adapted to the context of use in order to meet two different goals:
(1) To insure that the components match the proposed design solutions contained within the
UI Multi-Model and described by the pattern instances, and (2) To address issues that have
not been considered during the phase of pattern adaptation, such as platform and
programming language dependencies. This phase can be seen as a “fine tuning” of the later
user interface.
Step 6: Application Assembling.
The adapted components are inter-linked with each other and are used to assemble the UI of
the host application.
In the next section we will show that artifacts that have been developed according to PCB
process are particularly likely to be reused. We will demonstrate that UIs that are developed
according to the process are easy to adapt to new context requirements and that a migration of
the UI to a new platform can be undertaken without starting from the scratch.
Case Study: IP-Phone Management Application
We will illustrate an example of a study on developing the UI of a web application for selling
and managing IP-Phone service using the PCB process. In the first step of the PCB process, a
set of appropriate patterns is selected and mapped to the requirements (see Figure 2).
Examples of requirements for the IP-Phone Management Application are: (1) Functional
requirements such as support for user tasks including registration and signing up for a
particular package, and (2) Non-functional requirements such as users always knowing where
they are within the web application (navigation support).
Figure 1: The Patterns and Components - Based UI Development Process
Figure 2: Requirements, Patterns, and Pattern Instances
In the second step, selected patterns are instantiated to the context of use in order to be reused
as building blocks for the models in Step 3. We can illustrate this with the Multi-value Input
Form Pattern [Paternò 00],[Sinnig 04], which provides a task structure for entering several
values into an input form. In order to apply the pattern to our application, it must be adapted
to the particular input fields that should be provided by the form: (1) Registration and editing
personal information, and (2) Modifying package features (see Figure 3).
Figure 3: Instance of Multi-value Input Form Pattern
In the third step, the created pattern instances are used as building blocks to form various UI
models: The user task model, dialog model and presentation model (see Figure WW). It can
be seen that even though the amount of UI patterns is constantly growing, there will always be
requirements that are too specific and will not be covered by any pattern. In such a case, other
artifacts and information need to be consulted to complete the models.
Figure 4: Models and related Patterns
The fourth step entailed the selection of appropriate components to implement our application
with the ASP.NET framework. Table 1 summarizes the components, with the associated
pattern(s) they implement.
Table 1: Components Used
Name
E-Form
Brief Description
The E-Form generates and groups a set of input
interaction elements.
Navigator The Navigator implements three different types
of navigation aids: (1) Main menu, (2) Hot
Spots and (3) Breadcrumbs.
Tabler
The Tabler displays dynamically retrieved or
generated information using a table grid.
Impl. Patterns
Multi-value Input Form,
Unambiguous Format, Login
Main Navigation, Quick
Access, Breadcrumbs
Browse
In the fifth step, the components are adapted to the context of use, including requirements of
our application and technological constraints. For the sake of the IP-Phone Management
application, all three selected components generate the UI code based on an XML
specification. CSS (stylesheets) were used to determine the layout and style of the rendered
UI. Figure TT displays a subset of the XML specification used to adapt the E-form
component to serve as a Login Dialog.
Figure 5: Model and Screenshot of E-Form component for Login dialog
In the final step, the adapted components are inter-linked with each other and are used to
assemble the UI of the host application. Since we are using ASP.NET technology, the adapted
components are embedded into ASP pages. In addition, other UI elements such as labels,
descriptions and images are added to the pages and interlinked with the components.
Figure 6: Screenshot of the Modify Package Features Page
Figure 6 shows a screenshot of the “Modify Package” ASP page of the IPPhone Management
application. The page embeds four different instances of the previously introduced
components:
• The Navigator adapted as Main Menu (left),
• The Navigator adapted as Hot Spots (top),
• The Navigator adapted as Breadcrumbs and
• The E-Form adapted as an Input form for customizing the IPPhone package (center)
UI Reengineering
Systems inevitably change over time. Original requirements have to be modified to account
for changing user needs and advances in technology. User interfaces are no exception to this
rule, and current trends in user interface (UI) design are rapidly evolving. The web, as a vital
medium for information transfer, has had an impact on UI design. Furthermore, the
introduction of new platforms and devices, in particular mobile phones and PDAs, has added
an extra layer of complication to UI system changes. In the migration of interactive systems to
new platforms and architectures, many modifications have to be made to the UI.
Tools are needed to support UI reengineering. Writing code from scratch is no longer a viable
solution, and many techniques concentrate on reuse. The lack of methods in UI reengineering
motivated us to explore the combination of components and patterns as a reengineering tool.
On one hand the use of patterns helps in the reuse of well-known and proven design solutions,
and plays a significant role throughout the whole UI reengineering process. On the other hand
components embody reusable solutions for the implementation level.
Patterns are an interesting reengineering tool because the same pattern can be instantiated
differently on various platforms, such as a Web browser and a Personal Digital Assistant
(PDA). For example, the Quick Access pattern helps the user to reach the most commonly
used pages quickly from any location in the interface. It can provide direct access to
frequently used pages such as What’s New, Search, Contact Us, Home Page, and Site Map.
For the purpose of this chapter, we define the Quick Access pattern as a pattern for web
environments. However, other application domains are also possible. For a PDA, the Quick
Access pattern can be implemented as a combo box using the Wireless Markup Language
(WML). For a Web browser, it is implemented as a toolbar using embedded scripts or a Java
applet in HTML. Pattern descriptions should provide advice to pattern users for deriving the
most suitable instantiation for a given context.
In order to re-adapt the user interface of an application to different requirements, platforms or
contexts of use, most of the user interface code has to be modified. UI reengineering
techniques can facilitate such a transition. According to Chikofsky [Chikofsky et. al. 90]
reengineering is “the examination and alteration of a subject system to reconstitute it in a new
form and the subsequent implementation of the new form. In general UI reengineering
consists of a reverse engineering phase, a transformation phase, and a forward engineering
phase.
•
•
In reverse engineering, the challenge is to understand the interface code for
abstracting high-level UI design representations are summarized in the UI Multi
Model.
Transformation consists of redesigning the UI model to accommodate new platform
constraints and user needs.
•
Forward engineering is the process of generating and implementing the user
interface from high-level models.
Figure 7 portrays the essence of the UI reengineering process in which the original UI is
abstracted into a UI Multi-Model. The UI Multi Model is then transformed and modified in
order to meet the new requirements. Eventually the new UI Multi-Model serves as a basis for
the re-implementation of the new UI.
Figure 7: Three Phases of UI Re-Engineering
In what follows we will define in greater detail each phase of the general UI reengineering
process. In addition we will describe how to readapt respectively retarget a UI using the PCB
process.
Reverse Engineering
Chikofsky [Chikofsky et. al. 90] defines reverse engineering as the process of analyzing a
subject system to:
“identify the system’s components and their interrelationships, and create representations
of the system in another form or at a higher level of abstraction.”
Reverse Engineering is the process of analyzing software code with the objective of
recovering its design and specification. In the reverse engineering of the UI of interactive
systems, the ideal behavioral specification of the system is an abstract UI model with enough
detail to allow appropriate user interface techniques, in particular model-based approaches, to
be chosen in the new interface domain [Moore 1996].
There are two main aspects of an interface that need to be analyzed during the reverse
engineering process. The first aspect is structural, which consists of identifying the interface
components and the possible relationships between them. Second are the behavioral aspects,
which describe the dynamic aspects of the interface, including the dialogue and user feedback.
All these different facets of the UI are abstracted in to the various high level UI models,
which in turn constitute the UI Multi-Model.
Transformation
Transformation is a change to design characteristics. Possible changes include restructuring
design architecture, altering a system’s data model or changes to accommodate new
requirements. Requirement changes include the addition of new requirements, or the deletion
or alteration of existing requirements [Program-Transformation.Org 2004].
For the scope of this thesis the transformation phase consists of redesigning the UI MultiModel according to the new context of use, such as to accommodate new platform constraints
and user needs. The transformation process tries to first identify the problems of the old UI
Multi-Model, obtained during reverse engineering, and then attempts to come up with viable
solutions that can help create a new UI Multi-Model. The goal of the transformation process
is to change the UI Multi-Model in order to meet the new requirements. It is important to note
that in the new UI Multi-Model, some of the components of the old model may be reused.
Forward Engineering
Chikowsky defines forward engineering as the “traditional process of moving from high-level
abstractions and logical, implementation-independent designs to the physical implementation
of the interface.” [Chikofsky and Cross 1990] This last step of UI re-engineering results in
the generation of a new UI. This new interface must provide all required services and tasks to
the user, and must convey all information exchanged between the user and the system.
Several factors must be satisfied during forward engineering, which are indicative of the
success of the UI reengineering process [Moore 1994]:
•
•
•
The new UI has to be consistent with the reengineered UI, in particular in terms of
functionality. We are not referring to exact functionality, but rather that the new UI
should contain all original functionality even if enhancements or changes are made.
The forward engineering phase should start where the transformation phase left off. In
other words, the new UI abstract model should allow for forward engineering.
Certain relationships exist between user interface components and pieces of code. It is
important to ensure the preservation of these relationships.
Until now, we were looking at the UI re-engineering process from a rather theoretical point of
view. In what follows I will describe from a practical point of view how to reengineer a UI,
which has been developed according to the PCB process. First I will outline how to re-adapt a
UI to new requirements, without changing its target platform (UI adaptation). Second I will
show the process of retargeting or migrating a UI to different platforms (UI migration).
UI Adaptation
This section will describe the process of UI adaptation to new requirements without changing
its target platform. It is assumed that the UI has been developed according to the PCB
process. Generally the adaptation of a User Interface can be distinguished into two cases:
On one hand, the UI is solely changed and adapted at a very low level. Only language and
implementation related aspects such as bug fixing or platform specifics layouts (i.e. changing
the Look and Feel of Java applications from Metal to Motif [SWING 2002] are tackled. No
new UI requirements are added or changed. As a result, the UI adaptation is handled at the
“Fine tuning” level (see Figure 1). It is merely necessary to re-adapt the various components
of the host application. Reengineering, as defined in the previous section, is not necessary. In
this case the used patterns, the UI Multi-Model and the deployed components can be reused.
On the other hand, the UI is reengineered as a cause of changed requirements. In this case the
UI needs to be reverse engineered in order to abstract the UI Multi-Model and to identify the
patterns used to design the interface.
The PCB process explicitly defines connections between its steps, which are helpful for
tracing back the UI development (reverse engineering). As portrayed in Figure 1, the outcome
of one step is used as input for the next step of the PCB process. Thus, it is easy to grasp the
conceptualities of the UI by simply retracing the connections between the UI artifacts defined
during the various steps of the PCB process.
Typical UI re-engineering examples are (among others): Changes of the navigational structure
(i.e. separate navigation for novice and expert users), re-structuring or re-introduction of UI
elements and the introduction of new functions that should be supported by the UI. In each
case the UI needs to be reverse engineered.
UI reengineering starts with reverse engineering the implementation of the UI until the pattern
level. Each used pattern is then analysed to determine its suitability to the new context of use.
Even though it is likely that most of the already used patterns are eligible for reuse, some
modifications may require that certain patterns are added, replaced or removed from the UI
design. For example the support of new functionality may trigger the incorporation of a new
task pattern.
Next, according to the second step of the PCB process, the pattern set is re-instantiated
according to the new requirements. As a result the new set of pattern instances will be used to
re-create the UI Multi-Model. It is to be noted that only the models, which are affected by the
modification at the pattern level and their dependent models are recreated. The remaining
models remain unchanged.
Different models have different levels of abstraction. Early stages of software engineering of
the user interface focus on general, implementation-independent concepts, which are
described at a rather high level or with more abstract models. Later stages of software
engineering emphasize implementation details using low-level or less abstract models. Lowlevel models must take into account platform-specific attributes, whereas high-level models
are rather platform independent. Changes made at the conceptual modeling stage (high-level
model) will affect all lower levels [Chikofsky et. al. 90].
According to the definition of the task, dialog, presentation and layout model (see chapter 2),
the following inter-model dependencies exist:
•
•
•
The dialog model depends on the task model: Structural and temporal relations
between tasks are reused to design the dialog graph.
The presentation model depends on dialog model: Dialog views and dialog tasks
are associated with abstract interaction elements.
The Layout model depends on presentation model: Concrete style attributes are
attached to the abstract interaction elements.
Figure 8 portrays the inter-model dependency chain between the four models. The same
dependencies exist between different kinds of patterns. The usage of a particular high-level
pattern (such as a task pattern) may affect the usage of one or several lower level patterns (i.e.
dialog, presentation and layout patterns)
Figure 8: Inter-Model Dependencies
At this point it is noteworthy that that different frameworks (JANUS [Balzert 1996], AME
[Märtin 96], MOBI-D [MOBI-D 99], TERESA [TERESA 04]) may have different model
definitions and thus different inter-model dependencies.
After re-establishing the UI Multi-Model the previously chosen components are re-evaluated
according to their suitability to implement the “new” design. If necessary, new components
may be selected or existing components, which are not appropriate anymore, are dismissed.
Before re-deployment each components needs to be customized in order to match the design
proposed by the various patterns and captured by the UI Multi-Model. Finally the re-adapted
the UI is re-assembled.
Altogether the following artifacts may be reused during UI adaptation:
•
•
•
Appropriate patterns, which remain applicable in the new context of use
A sub-set of the UI Multi-Model which does not directly or indirectly depend on the
modification of the pattern set
Components, which are re-deployed to implement the new UI Multi-Model
UI Migration
UI Migration is the process of retargeting the UI from one source-computing platform to
another target-computing platform that poses different constraints [Bouillon et al. 04].
Examples of possible retargeting scenarios are: Migration of a GUI-based application to the
web or transformation of a desktop web portal to the PDA environment.
Similar to the UI adaptation approach the UI migration process starts with reverse engineering
of the source UI. Step by step the source implementation is abstracted into the UI MultiModel and the corresponding set of patterns.
During the transformation phase, the patterns are examined for their suitability to new
requirements and new contexts of use. Within the context of UI migration this includes
primarily factors such as the computing platform capabilities and constraints, the UI Lookand-Feel and the dialog style. Inappropriate patterns are replaced by appropriate patterns or
removed.
The following scenario illustrates possible transformation of the pattern set:
Let us assume that a source desktop application had a feature for previewing images before
opening them. During reverse engineering this feature is traced back to the Preview task
pattern [Welie 2004]. As the requirements change, the choice of patterns also changes. For
instance, when retargeting the application to a mobile device, such as a mobile telephone, we
may not have the ability to preview images due to the platform constraint of a smaller screen
size and lower resolution. The Preview pattern is appropriate for the desktop, but not for the
mobile phone, and should therefore be removed in the design of the mobile phone. As a result,
the user-task model for the new system does not contain a “preview” task structure and thus
the preview feature will not be re-implemented on the target platform.
During forward engineering, the new pattern set is re-instantiated and used to re-establish the
UI Multi-Model. In contrast to UI adaptation the original components may not be reused if the
target implementation platform changes (since components are platform specific). Altogether
a good part of the original pattern set as well as fragments of the UI Multi-Model may be
reused.
Brief Example: Re-engineering the CBC Web-Site to Small Devices
Web applications are usually designed for a browser running on a standard desktop computer.
It is common to see the reminder “This Website is better viewed or optimized with/for
Internet Explorer or Netscape Communicator”. With the rapid shift towards wireless
computing, these Web sites need to be customized and migrated to different devices with
different capabilities. In the context of designing for a big versus a small screen, strategies for
displaying information need to be re-thought.
In this section we re-engineer the CBC Website (CBC 2004) to fit the constraints of a PDA
and of a mobile phone. In particular we focus on re-engineering one particular aspect of
navigation; the navigation by hot spots. If we have a closer look at the screenshot of the CBC
front page (displayed by Figure 9) we can identify the “Hot Spot” toolbar in upper right
corner (highlighted by the shady ellipse). This toolbar is used to display links to the most
frequently sub pages of the CBC Web Site.
Figure 9: CBC Front-page
The migration starts with UI reverse engineering in order to abstract the underlying high-level
design models (UI Multi-Model) and the corresponding patterns. The implementation of the
hot spot toolbar component can be directly traced back to two models. On one hand the hot
spots are a navigation aid and affect the navigational structure of the website, which is
captured by the dialog model. On the other hand the presentation model describes the
presentment (as a toolbar) of the hot spots.
The Quick Access pattern is identified by further abstracting the “hot spot” related aspects of
the dialog and presentation model. In order to migrate the hot spot toolbar to the PDA and the
mobile phone environment the Quick Access pattern needs to be re-instantiated. For the sake
of this example, the pattern is instantiated as a combo box for the PDA platform whereas on
the mobile phone the pattern is presented as a simple list.
During forward engineering the effected models are re-established and eventually reimplemented Figure 10 displays a possible implementation of the “hot spots” for the PDA and
mobile phone.
Figure 10: Hot Spot Implementation for PDA and Mobile Phone
Conclusions
It was demonstrated how components can be used to implement knowledge captured by
patterns. The relation between patterns and components was discussed in detail and a patterns
and components based development process model was provided. Additionally, it was
discussed how tool support could be provided. Two case studies of the usage of UI patterns
were discussed. The first one was a project to develop a software system. The second one
described the reengineering process of a CNN web page to develop user interfaces for mobile
devices. We strongly believe that pattern and components are very important for the software
development of the future. The outlined development models provide a lot of advantages.
References:
[Balzert 96] Balzert, H.: From OOA to GUIs: The JANUS System. Journal of Object-Oriented
Programming, (Febr. 1996), pp.43-47.
[Bouillon et. al. 04] Bouillon, L., J. Vanderdonckt and C. K. Chow: Flexible re-engineering of web
sites. In Proceedings of Intelligent User Interfaces (IUI), Madeira, Portugal, pp. 132-139.
[CBC 2004] CBC.ca -- Canada's Online Information Source [Internet]. Available from
[Accessed July 2004, 2004].
[Chikofsky et. al. 90] Chikofsky, E. J. and J. H. Cross: Reverse Engineering and Design Recovery - A
Taxonomy. IEEE Software, pp.13-17.
[Gaedtke et. al 2000] Gaedke, M., C. Segor and H.-W. Gellersen: WCML: Paving the Way for Reuse
on Object-oriented Web-Engineering. In Proc. of SAC 2000, Villa Olmo, Como, Italy, pp. 74-77.
[Märtin 96] Märtin, C.: Software Life Cycle Automation for Interactive Applications: The AME
Design Environment. In Proc. of CADUI'96, Namur, Belgium, Namur University Press, pp. 57-76.
(MOBI-D 99]MOBI-D: The MOBI-D Interface Development Environment [Internet]. Available from
[Accessed February, 2004].
[Moore 94] Moore, M.: A Technique for Reverse Engineering User Interfaces. In Proceedings of
Fourth Reverse Engineering Forum, November, 1994, Victoria, British Columbia.
[Moore 96] Moore, M.: Representation Issues for Reengineering Interactive Systems. ACM
Computing Surveys, 28/4.
[Paternò00] Paternò, F.: Model-Based Design and Evaluation of Interactive Applications, Springer.
[Program-Transformation.Org 04] Program-Transformation.Org: Reengineering [Internet].
Available from [Accessed May, 2004].
[Schmidt et. al. 99] Schmidt, A., M. Beigl and A. Gellersen: There is more to Context than Location.
Computers & Graphics Journal, 23, pp.893-902.
[Shilit et. al. 93] Shilit, B., M. Theimer and B. Welch: Customizing Mobile Applications. In
Proceedings of USENIX symposium on Mobile and Location-independent Computing, pp. 129-138.
[Sinnig 04] Sinnig, D.: The Complicity of Patterns and Model-Based UI Development. Master Thesis
in the Department of Computer Science, Concordia University, Montreal.
[SWING
02]
SWING:
Pluggable
Look
&
Feel
[Internet].
Available
from
[Accessed May, 2004].
[Szyperski 98] Szyperski, C.: Component Software - Beyond Object-Oriented Programming, AddisonWesley / ACM Press.
[TERESA 04] TERESA: Transformation Environment for Interactive Systems Representations
[Internet]. Available from [Accessed February, 2004].
[Tidwell 04] Tidwell, J.: UI Patterns and Techniques [Internet].
Available from [Accessed January, 2004].
[Vanderdonckt 03] Vanderdonckt, J., E. Furtado, J. Furtado and Q. Limbourg: Multi-Model and
Multi-Level Development of User Interfaces. Multiple User Interfaces, Cross-Platform Applications
and Context-Aware Interfaces, London, Wiley, pp. 193-216.
[Welie 04] Welie, M.: Patterns in Interaction Design, [Internet]. Available from
[Accessed February, 2004].
for Flexible UI Development
Daniel Sinnig1,2, Homa Javahery2, Jovan Strika3, Peter Forbrig1 and Ahmed Seffah2
(1) Software Engineering Group
University of Rostock
Albert-Einstein-Str.21
18051 Rostock, Germany
{dasin, pforbrig}@
informatik.uni-rostock.de
(2) HC SE Group
Concordia University
1455 De Maisonneuve Blvd.
Montreal, Canada H3G 1M8
{h_javahe,seffah}@
cs.concordia.ca
(3) Dotalis R & D Group
2121 St. Mathieu, Suite 506
Montreal, Canada
H3H 2J3
jstrika@dotalis.com
Abstract
The paper studies relations between patterns and components for user-interface
design. It demonstrates how components can be considered as implementations
of patterns. It also discusses the support of patterns for reverse- and
reengineering of existing software. This can especially support the transfer of
software to new platforms and devices.
Introduction
Software applications, in general, have become more and more complex. User interfaces are
no exception to this rule, and current trends in user interface (UI) design are rapidly evolving.
The web, as a vital medium for information transfer, has had an impact on UI design.
Although software application logic development has become increasingly driven by
engineering techniques and principles, the development of the UI has remained “ad-hoc” and
thus has resulted – from a software engineering point of view – in applications of poor
architectural quality, causing tremendous costs for maintenance and further evolution [Gaedke
et al. 00]. Writing code from scratch is no longer a viable solution. The lack of standards and
the broad diversity of technologies have led to the fact that no efficient concept for reuse of
solutions and designs has been established yet.
To support systematic UI development, a process incorporating a disciplined form of reuse is
needed. The lack of methods in UI development motivated us to explore the combination of
components and patterns as core constituents for a novel reuse approach. Patterns help in the
reuse of well-known and proven design solutions, and play a significant role throughout the
whole UI development process. Components embody reusable solutions at the
implementation level.
Core constituents: Patterns and Components
Patterns in UI development are an effective way to transmit experience about recurrent
problems in the HCI domain. They have the potential to inherently promote the reuse of ideas
and knowledge. From experiences with implementation reuse, it is known that an effective
concept of reuse should include these three different dimensions: Encapsulation,
Composition, and Customization. The concept of patterns addresses all three reuse
dimensions. Naturally and by definition, patterns are encapsulations of solutions to problems
in a specific context of use. In addition, the concept of pattern languages implies that patterns
can be combined and nested depending on their relationships. Last but not least, patterns
embody solutions, which occur over and over again in different situations. Therefore patterns
are not static, and must be customized to the current context of use.
A software component can be defined as a unit of composition with a clearly defined
interface, enabling independent deployment and third-party reuse. As a result, it enables
practical reuse across multiple applications [Szyperski 98]. Components are a suitable means
to implement patterns on a particular platform [Sinnig 04]. Once an appropriate pattern has
been chosen and instantiated, a suitable component can be picked to implement the particular
pattern instance. In the same way as patterns, components can also be customized and adapted
to different contexts of use. Patterns, in general, are of rather conceptual nature and abstract
from concrete implementation language independent issues. This generic nature of patterns
allows the designer to think “outside” the toolkit at hand [Tidwell 04]. When it comes down
to the implementation, the previously conceptually designed aspects for the application must
be carried out using a particular programming environment and framework.
In the following we will suggest a UI development process, which incorporates both patterns
and components. It will be shown that due to these two core constituents, the process is highly
flexible and adaptable. Furthermore, such an integrated approach of using patterns with
software components can be a practical step in bridging the conceptual gap that currently
exists between the domains of Software Engineering and Human-Computer Interaction;
where patterns act as the conceptual design solution used by HCI practitioners and
components are the concrete realization and implementation of such design solutions,
produced and used by Software Engineers.
The Pattern and Component – Based UI Development Process
The Pattern and Component-Based (PCB) process allows for flexible and systematic UI
development, by unifying pattern and component-based methodologies into one systematic
process. As portrayed in Figure 1 the process consists of six logical and mutually successive
steps going from the conceptual to implementation level.
Step 1: Pattern Selection.
The PCB process begins after the analysis phase and the requirements specification. It is
assumed that the problem domain has already been precisely specified. A set of appropriate
patterns is selected to tackle different design aspects of the UI. Patterns are problem oriented,
proposing a solution to a problem, which is applicable in a certain context of use. As
demonstrated in chapter 2 different kinds of UI patterns (task, dialog, presentation and layout)
exist for tackling different aspects of the UI. Choosing appropriate patterns correctly depends
strongly on the experience and the creativity of the designer; these selected patterns will shape
the basic nature of the future UI.
Step 2: Pattern Instantiation.
A pattern is an abstraction that must be instantiated. Before the pattern solution stated in the
pattern is really tangible and applicable, it must be adapted to the current context of use. The
second step of the PCB process consists of adjusting the patterns of step 1 according to the
context of use resulting in a set of pattern instances.
At this point it is noteworthy that there is no universal accepted definition of “context”.
Researchers from different fields have given their own definitions of context. For instance,
Shilit and Theimer defined context as the location, the identities of people around, and the
equipment nearby [Shilit et al. 93]. Schmidt defined the context as the user’s social and
physical environments, as well as the task being performed [Schmidt et al. 99].
The term “context” addresses a very broad field. However, patterns are platform and
implementation independent, therefore the context factors to be considered in this step focus
on conceptualities such as the target user groups, target devices or environmental factors.
This pattern adaptation phase can be seen as a first “basic” tuning of the further application,
without being specific about the implementation and/or the programming language.
Step 3: Model Construction.
In this step the various patterns instances are associated to different declarative UI models. In
particular as described in chapter 2 the pattern instances are used as building blocks to form
the various models; these models contain declarative descriptions of the UI facets. If
necessary, other artifacts and information may be consulted as well to form the models. For
example, personae and archetypes help in the creation of a user task model. Many facets exist
as well as related models: Task, domain, user, device, platform, application, presentation,
dialogue, navigation, etc. [Vanderdonckt et al. 03]. For the sake of simplicity, Figure 1 shows
only the User-Task, the Navigation, the Presentation and the Layout model. We summarize
the models, which are related to the user interface under the term UI Multi-Model.
[Vanderdonckt et al. 03].
Step 4: Component Selection.
Until now, the user interface is viewed and defined by the UI Multi-Model at a conceptual
level. The remaining steps of the process, however, are concerned with the concrete
implementation issues of the user interface. Therefore, components are picked in order to
implement the UI according to the UI Multi-Model. In particular, since the models are mainly
formed and established by patterns, components to implement the various patterns are chosen.
If such a component does not exist, it must be developed and implemented. At this point it is
to be noted that one component may serve as an implementation for several related patterns.
Step 5: Component Adaptation.
The various components are adapted to the context of use in order to meet two different goals:
(1) To insure that the components match the proposed design solutions contained within the
UI Multi-Model and described by the pattern instances, and (2) To address issues that have
not been considered during the phase of pattern adaptation, such as platform and
programming language dependencies. This phase can be seen as a “fine tuning” of the later
user interface.
Step 6: Application Assembling.
The adapted components are inter-linked with each other and are used to assemble the UI of
the host application.
In the next section we will show that artifacts that have been developed according to PCB
process are particularly likely to be reused. We will demonstrate that UIs that are developed
according to the process are easy to adapt to new context requirements and that a migration of
the UI to a new platform can be undertaken without starting from the scratch.
Case Study: IP-Phone Management Application
We will illustrate an example of a study on developing the UI of a web application for selling
and managing IP-Phone service using the PCB process. In the first step of the PCB process, a
set of appropriate patterns is selected and mapped to the requirements (see Figure 2).
Examples of requirements for the IP-Phone Management Application are: (1) Functional
requirements such as support for user tasks including registration and signing up for a
particular package, and (2) Non-functional requirements such as users always knowing where
they are within the web application (navigation support).
Figure 1: The Patterns and Components - Based UI Development Process
Figure 2: Requirements, Patterns, and Pattern Instances
In the second step, selected patterns are instantiated to the context of use in order to be reused
as building blocks for the models in Step 3. We can illustrate this with the Multi-value Input
Form Pattern [Paternò 00],[Sinnig 04], which provides a task structure for entering several
values into an input form. In order to apply the pattern to our application, it must be adapted
to the particular input fields that should be provided by the form: (1) Registration and editing
personal information, and (2) Modifying package features (see Figure 3).
Figure 3: Instance of Multi-value Input Form Pattern
In the third step, the created pattern instances are used as building blocks to form various UI
models: The user task model, dialog model and presentation model (see Figure WW). It can
be seen that even though the amount of UI patterns is constantly growing, there will always be
requirements that are too specific and will not be covered by any pattern. In such a case, other
artifacts and information need to be consulted to complete the models.
Figure 4: Models and related Patterns
The fourth step entailed the selection of appropriate components to implement our application
with the ASP.NET framework. Table 1 summarizes the components, with the associated
pattern(s) they implement.
Table 1: Components Used
Name
E-Form
Brief Description
The E-Form generates and groups a set of input
interaction elements.
Navigator The Navigator implements three different types
of navigation aids: (1) Main menu, (2) Hot
Spots and (3) Breadcrumbs.
Tabler
The Tabler displays dynamically retrieved or
generated information using a table grid.
Impl. Patterns
Multi-value Input Form,
Unambiguous Format, Login
Main Navigation, Quick
Access, Breadcrumbs
Browse
In the fifth step, the components are adapted to the context of use, including requirements of
our application and technological constraints. For the sake of the IP-Phone Management
application, all three selected components generate the UI code based on an XML
specification. CSS (stylesheets) were used to determine the layout and style of the rendered
UI. Figure TT displays a subset of the XML specification used to adapt the E-form
component to serve as a Login Dialog.
Figure 5: Model and Screenshot of E-Form component for Login dialog
In the final step, the adapted components are inter-linked with each other and are used to
assemble the UI of the host application. Since we are using ASP.NET technology, the adapted
components are embedded into ASP pages. In addition, other UI elements such as labels,
descriptions and images are added to the pages and interlinked with the components.
Figure 6: Screenshot of the Modify Package Features Page
Figure 6 shows a screenshot of the “Modify Package” ASP page of the IPPhone Management
application. The page embeds four different instances of the previously introduced
components:
• The Navigator adapted as Main Menu (left),
• The Navigator adapted as Hot Spots (top),
• The Navigator adapted as Breadcrumbs and
• The E-Form adapted as an Input form for customizing the IPPhone package (center)
UI Reengineering
Systems inevitably change over time. Original requirements have to be modified to account
for changing user needs and advances in technology. User interfaces are no exception to this
rule, and current trends in user interface (UI) design are rapidly evolving. The web, as a vital
medium for information transfer, has had an impact on UI design. Furthermore, the
introduction of new platforms and devices, in particular mobile phones and PDAs, has added
an extra layer of complication to UI system changes. In the migration of interactive systems to
new platforms and architectures, many modifications have to be made to the UI.
Tools are needed to support UI reengineering. Writing code from scratch is no longer a viable
solution, and many techniques concentrate on reuse. The lack of methods in UI reengineering
motivated us to explore the combination of components and patterns as a reengineering tool.
On one hand the use of patterns helps in the reuse of well-known and proven design solutions,
and plays a significant role throughout the whole UI reengineering process. On the other hand
components embody reusable solutions for the implementation level.
Patterns are an interesting reengineering tool because the same pattern can be instantiated
differently on various platforms, such as a Web browser and a Personal Digital Assistant
(PDA). For example, the Quick Access pattern helps the user to reach the most commonly
used pages quickly from any location in the interface. It can provide direct access to
frequently used pages such as What’s New, Search, Contact Us, Home Page, and Site Map.
For the purpose of this chapter, we define the Quick Access pattern as a pattern for web
environments. However, other application domains are also possible. For a PDA, the Quick
Access pattern can be implemented as a combo box using the Wireless Markup Language
(WML). For a Web browser, it is implemented as a toolbar using embedded scripts or a Java
applet in HTML. Pattern descriptions should provide advice to pattern users for deriving the
most suitable instantiation for a given context.
In order to re-adapt the user interface of an application to different requirements, platforms or
contexts of use, most of the user interface code has to be modified. UI reengineering
techniques can facilitate such a transition. According to Chikofsky [Chikofsky et. al. 90]
reengineering is “the examination and alteration of a subject system to reconstitute it in a new
form and the subsequent implementation of the new form. In general UI reengineering
consists of a reverse engineering phase, a transformation phase, and a forward engineering
phase.
•
•
In reverse engineering, the challenge is to understand the interface code for
abstracting high-level UI design representations are summarized in the UI Multi
Model.
Transformation consists of redesigning the UI model to accommodate new platform
constraints and user needs.
•
Forward engineering is the process of generating and implementing the user
interface from high-level models.
Figure 7 portrays the essence of the UI reengineering process in which the original UI is
abstracted into a UI Multi-Model. The UI Multi Model is then transformed and modified in
order to meet the new requirements. Eventually the new UI Multi-Model serves as a basis for
the re-implementation of the new UI.
Figure 7: Three Phases of UI Re-Engineering
In what follows we will define in greater detail each phase of the general UI reengineering
process. In addition we will describe how to readapt respectively retarget a UI using the PCB
process.
Reverse Engineering
Chikofsky [Chikofsky et. al. 90] defines reverse engineering as the process of analyzing a
subject system to:
“identify the system’s components and their interrelationships, and create representations
of the system in another form or at a higher level of abstraction.”
Reverse Engineering is the process of analyzing software code with the objective of
recovering its design and specification. In the reverse engineering of the UI of interactive
systems, the ideal behavioral specification of the system is an abstract UI model with enough
detail to allow appropriate user interface techniques, in particular model-based approaches, to
be chosen in the new interface domain [Moore 1996].
There are two main aspects of an interface that need to be analyzed during the reverse
engineering process. The first aspect is structural, which consists of identifying the interface
components and the possible relationships between them. Second are the behavioral aspects,
which describe the dynamic aspects of the interface, including the dialogue and user feedback.
All these different facets of the UI are abstracted in to the various high level UI models,
which in turn constitute the UI Multi-Model.
Transformation
Transformation is a change to design characteristics. Possible changes include restructuring
design architecture, altering a system’s data model or changes to accommodate new
requirements. Requirement changes include the addition of new requirements, or the deletion
or alteration of existing requirements [Program-Transformation.Org 2004].
For the scope of this thesis the transformation phase consists of redesigning the UI MultiModel according to the new context of use, such as to accommodate new platform constraints
and user needs. The transformation process tries to first identify the problems of the old UI
Multi-Model, obtained during reverse engineering, and then attempts to come up with viable
solutions that can help create a new UI Multi-Model. The goal of the transformation process
is to change the UI Multi-Model in order to meet the new requirements. It is important to note
that in the new UI Multi-Model, some of the components of the old model may be reused.
Forward Engineering
Chikowsky defines forward engineering as the “traditional process of moving from high-level
abstractions and logical, implementation-independent designs to the physical implementation
of the interface.” [Chikofsky and Cross 1990] This last step of UI re-engineering results in
the generation of a new UI. This new interface must provide all required services and tasks to
the user, and must convey all information exchanged between the user and the system.
Several factors must be satisfied during forward engineering, which are indicative of the
success of the UI reengineering process [Moore 1994]:
•
•
•
The new UI has to be consistent with the reengineered UI, in particular in terms of
functionality. We are not referring to exact functionality, but rather that the new UI
should contain all original functionality even if enhancements or changes are made.
The forward engineering phase should start where the transformation phase left off. In
other words, the new UI abstract model should allow for forward engineering.
Certain relationships exist between user interface components and pieces of code. It is
important to ensure the preservation of these relationships.
Until now, we were looking at the UI re-engineering process from a rather theoretical point of
view. In what follows I will describe from a practical point of view how to reengineer a UI,
which has been developed according to the PCB process. First I will outline how to re-adapt a
UI to new requirements, without changing its target platform (UI adaptation). Second I will
show the process of retargeting or migrating a UI to different platforms (UI migration).
UI Adaptation
This section will describe the process of UI adaptation to new requirements without changing
its target platform. It is assumed that the UI has been developed according to the PCB
process. Generally the adaptation of a User Interface can be distinguished into two cases:
On one hand, the UI is solely changed and adapted at a very low level. Only language and
implementation related aspects such as bug fixing or platform specifics layouts (i.e. changing
the Look and Feel of Java applications from Metal to Motif [SWING 2002] are tackled. No
new UI requirements are added or changed. As a result, the UI adaptation is handled at the
“Fine tuning” level (see Figure 1). It is merely necessary to re-adapt the various components
of the host application. Reengineering, as defined in the previous section, is not necessary. In
this case the used patterns, the UI Multi-Model and the deployed components can be reused.
On the other hand, the UI is reengineered as a cause of changed requirements. In this case the
UI needs to be reverse engineered in order to abstract the UI Multi-Model and to identify the
patterns used to design the interface.
The PCB process explicitly defines connections between its steps, which are helpful for
tracing back the UI development (reverse engineering). As portrayed in Figure 1, the outcome
of one step is used as input for the next step of the PCB process. Thus, it is easy to grasp the
conceptualities of the UI by simply retracing the connections between the UI artifacts defined
during the various steps of the PCB process.
Typical UI re-engineering examples are (among others): Changes of the navigational structure
(i.e. separate navigation for novice and expert users), re-structuring or re-introduction of UI
elements and the introduction of new functions that should be supported by the UI. In each
case the UI needs to be reverse engineered.
UI reengineering starts with reverse engineering the implementation of the UI until the pattern
level. Each used pattern is then analysed to determine its suitability to the new context of use.
Even though it is likely that most of the already used patterns are eligible for reuse, some
modifications may require that certain patterns are added, replaced or removed from the UI
design. For example the support of new functionality may trigger the incorporation of a new
task pattern.
Next, according to the second step of the PCB process, the pattern set is re-instantiated
according to the new requirements. As a result the new set of pattern instances will be used to
re-create the UI Multi-Model. It is to be noted that only the models, which are affected by the
modification at the pattern level and their dependent models are recreated. The remaining
models remain unchanged.
Different models have different levels of abstraction. Early stages of software engineering of
the user interface focus on general, implementation-independent concepts, which are
described at a rather high level or with more abstract models. Later stages of software
engineering emphasize implementation details using low-level or less abstract models. Lowlevel models must take into account platform-specific attributes, whereas high-level models
are rather platform independent. Changes made at the conceptual modeling stage (high-level
model) will affect all lower levels [Chikofsky et. al. 90].
According to the definition of the task, dialog, presentation and layout model (see chapter 2),
the following inter-model dependencies exist:
•
•
•
The dialog model depends on the task model: Structural and temporal relations
between tasks are reused to design the dialog graph.
The presentation model depends on dialog model: Dialog views and dialog tasks
are associated with abstract interaction elements.
The Layout model depends on presentation model: Concrete style attributes are
attached to the abstract interaction elements.
Figure 8 portrays the inter-model dependency chain between the four models. The same
dependencies exist between different kinds of patterns. The usage of a particular high-level
pattern (such as a task pattern) may affect the usage of one or several lower level patterns (i.e.
dialog, presentation and layout patterns)
Figure 8: Inter-Model Dependencies
At this point it is noteworthy that that different frameworks (JANUS [Balzert 1996], AME
[Märtin 96], MOBI-D [MOBI-D 99], TERESA [TERESA 04]) may have different model
definitions and thus different inter-model dependencies.
After re-establishing the UI Multi-Model the previously chosen components are re-evaluated
according to their suitability to implement the “new” design. If necessary, new components
may be selected or existing components, which are not appropriate anymore, are dismissed.
Before re-deployment each components needs to be customized in order to match the design
proposed by the various patterns and captured by the UI Multi-Model. Finally the re-adapted
the UI is re-assembled.
Altogether the following artifacts may be reused during UI adaptation:
•
•
•
Appropriate patterns, which remain applicable in the new context of use
A sub-set of the UI Multi-Model which does not directly or indirectly depend on the
modification of the pattern set
Components, which are re-deployed to implement the new UI Multi-Model
UI Migration
UI Migration is the process of retargeting the UI from one source-computing platform to
another target-computing platform that poses different constraints [Bouillon et al. 04].
Examples of possible retargeting scenarios are: Migration of a GUI-based application to the
web or transformation of a desktop web portal to the PDA environment.
Similar to the UI adaptation approach the UI migration process starts with reverse engineering
of the source UI. Step by step the source implementation is abstracted into the UI MultiModel and the corresponding set of patterns.
During the transformation phase, the patterns are examined for their suitability to new
requirements and new contexts of use. Within the context of UI migration this includes
primarily factors such as the computing platform capabilities and constraints, the UI Lookand-Feel and the dialog style. Inappropriate patterns are replaced by appropriate patterns or
removed.
The following scenario illustrates possible transformation of the pattern set:
Let us assume that a source desktop application had a feature for previewing images before
opening them. During reverse engineering this feature is traced back to the Preview task
pattern [Welie 2004]. As the requirements change, the choice of patterns also changes. For
instance, when retargeting the application to a mobile device, such as a mobile telephone, we
may not have the ability to preview images due to the platform constraint of a smaller screen
size and lower resolution. The Preview pattern is appropriate for the desktop, but not for the
mobile phone, and should therefore be removed in the design of the mobile phone. As a result,
the user-task model for the new system does not contain a “preview” task structure and thus
the preview feature will not be re-implemented on the target platform.
During forward engineering, the new pattern set is re-instantiated and used to re-establish the
UI Multi-Model. In contrast to UI adaptation the original components may not be reused if the
target implementation platform changes (since components are platform specific). Altogether
a good part of the original pattern set as well as fragments of the UI Multi-Model may be
reused.
Brief Example: Re-engineering the CBC Web-Site to Small Devices
Web applications are usually designed for a browser running on a standard desktop computer.
It is common to see the reminder “This Website is better viewed or optimized with/for
Internet Explorer or Netscape Communicator”. With the rapid shift towards wireless
computing, these Web sites need to be customized and migrated to different devices with
different capabilities. In the context of designing for a big versus a small screen, strategies for
displaying information need to be re-thought.
In this section we re-engineer the CBC Website (CBC 2004) to fit the constraints of a PDA
and of a mobile phone. In particular we focus on re-engineering one particular aspect of
navigation; the navigation by hot spots. If we have a closer look at the screenshot of the CBC
front page (displayed by Figure 9) we can identify the “Hot Spot” toolbar in upper right
corner (highlighted by the shady ellipse). This toolbar is used to display links to the most
frequently sub pages of the CBC Web Site.
Figure 9: CBC Front-page
The migration starts with UI reverse engineering in order to abstract the underlying high-level
design models (UI Multi-Model) and the corresponding patterns. The implementation of the
hot spot toolbar component can be directly traced back to two models. On one hand the hot
spots are a navigation aid and affect the navigational structure of the website, which is
captured by the dialog model. On the other hand the presentation model describes the
presentment (as a toolbar) of the hot spots.
The Quick Access pattern is identified by further abstracting the “hot spot” related aspects of
the dialog and presentation model. In order to migrate the hot spot toolbar to the PDA and the
mobile phone environment the Quick Access pattern needs to be re-instantiated. For the sake
of this example, the pattern is instantiated as a combo box for the PDA platform whereas on
the mobile phone the pattern is presented as a simple list.
During forward engineering the effected models are re-established and eventually reimplemented Figure 10 displays a possible implementation of the “hot spots” for the PDA and
mobile phone.
Figure 10: Hot Spot Implementation for PDA and Mobile Phone
Conclusions
It was demonstrated how components can be used to implement knowledge captured by
patterns. The relation between patterns and components was discussed in detail and a patterns
and components based development process model was provided. Additionally, it was
discussed how tool support could be provided. Two case studies of the usage of UI patterns
were discussed. The first one was a project to develop a software system. The second one
described the reengineering process of a CNN web page to develop user interfaces for mobile
devices. We strongly believe that pattern and components are very important for the software
development of the future. The outlined development models provide a lot of advantages.
References:
[Balzert 96] Balzert, H.: From OOA to GUIs: The JANUS System. Journal of Object-Oriented
Programming, (Febr. 1996), pp.43-47.
[Bouillon et. al. 04] Bouillon, L., J. Vanderdonckt and C. K. Chow: Flexible re-engineering of web
sites. In Proceedings of Intelligent User Interfaces (IUI), Madeira, Portugal, pp. 132-139.
[CBC 2004] CBC.ca -- Canada's Online Information Source [Internet]. Available from
[Accessed July 2004, 2004].
[Chikofsky et. al. 90] Chikofsky, E. J. and J. H. Cross: Reverse Engineering and Design Recovery - A
Taxonomy. IEEE Software, pp.13-17.
[Gaedtke et. al 2000] Gaedke, M., C. Segor and H.-W. Gellersen: WCML: Paving the Way for Reuse
on Object-oriented Web-Engineering. In Proc. of SAC 2000, Villa Olmo, Como, Italy, pp. 74-77.
[Märtin 96] Märtin, C.: Software Life Cycle Automation for Interactive Applications: The AME
Design Environment. In Proc. of CADUI'96, Namur, Belgium, Namur University Press, pp. 57-76.
(MOBI-D 99]MOBI-D: The MOBI-D Interface Development Environment [Internet]. Available from
[Accessed February, 2004].
[Moore 94] Moore, M.: A Technique for Reverse Engineering User Interfaces. In Proceedings of
Fourth Reverse Engineering Forum, November, 1994, Victoria, British Columbia.
[Moore 96] Moore, M.: Representation Issues for Reengineering Interactive Systems. ACM
Computing Surveys, 28/4.
[Paternò00] Paternò, F.: Model-Based Design and Evaluation of Interactive Applications, Springer.
[Program-Transformation.Org 04] Program-Transformation.Org: Reengineering [Internet].
Available from [Accessed May, 2004].
[Schmidt et. al. 99] Schmidt, A., M. Beigl and A. Gellersen: There is more to Context than Location.
Computers & Graphics Journal, 23, pp.893-902.
[Shilit et. al. 93] Shilit, B., M. Theimer and B. Welch: Customizing Mobile Applications. In
Proceedings of USENIX symposium on Mobile and Location-independent Computing, pp. 129-138.
[Sinnig 04] Sinnig, D.: The Complicity of Patterns and Model-Based UI Development. Master Thesis
in the Department of Computer Science, Concordia University, Montreal.
[SWING
02]
SWING:
Pluggable
Look
&
Feel
[Internet].
Available
from
[Accessed May, 2004].
[Szyperski 98] Szyperski, C.: Component Software - Beyond Object-Oriented Programming, AddisonWesley / ACM Press.
[TERESA 04] TERESA: Transformation Environment for Interactive Systems Representations
[Internet]. Available from [Accessed February, 2004].
[Tidwell 04] Tidwell, J.: UI Patterns and Techniques [Internet].
Available from [Accessed January, 2004].
[Vanderdonckt 03] Vanderdonckt, J., E. Furtado, J. Furtado and Q. Limbourg: Multi-Model and
Multi-Level Development of User Interfaces. Multiple User Interfaces, Cross-Platform Applications
and Context-Aware Interfaces, London, Wiley, pp. 193-216.
[Welie 04] Welie, M.: Patterns in Interaction Design, [Internet]. Available from
[Accessed February, 2004].