=Paper=
{{Paper
|id=Vol-407/paper-4
|storemode=property
|title=Preparing Usability Supporting Architectural Patterns for Industrial Use
|pdfUrl=https://ceur-ws.org/Vol-407/paper4.pdf
|volume=Vol-407
|dblpUrl=https://dblp.org/rec/conf/iused/StollJBG08
}}
==Preparing Usability Supporting Architectural Patterns for Industrial Use==
https://ceur-ws.org/Vol-407/paper4.pdf
Preparing Usability Supporting Architectural Patterns for
Industrial Use
Pia Stoll Bonnie E. John, Len Bass, Elspeth Golden
ABB Corporate Research Carnegie Mellon University
Forskargränd 6 5000 Forbes Ave.
SE 72178 Västerås, Sweden Pittsburgh, PA, USA 15213
Tel: +46 21 32 30 00 Tel: 1+412 268 2000
pia.stoll@se.abb.com bej@cs.cmu.edu, ljb@sei.cmu.edu,
egolden@cmu.edu
ABSTRACT
Usability supporting architectural patterns (USAPs) have been
1. INTRODUCTION
The Software Engineering community has recognized that
shown to provide developers with useful guidance for producing a
usability affects not only the design of user interfaces but
software architecture design that supports usability in a laboratory
software system development as a whole. In particular, efforts are
setting [7]. In close collaboration between researchers and
focused on explaining the implications of usability on software
software developers in the real world, the concepts were proven
architecture design [3, 4, 5, 6, 10].
useful [2]. However, this process does not scale to industrial
development efforts. In particular, development teams need to be One effort in this area is to produce artifacts that communicate
able to use USAPs while being distributed world-wide. USAPs usability requirements in a form that can be effectively used for
also must support legacy or already partially-designed software architecture evaluation and design. These usability
architectures, and when using multiple USAPs there could be a supporting architectural patterns (USAPS) have been shown to
potentially overwhelming amount of information given to the improve the ability of software architects to design higher quality
software architects. In this paper, we describe the restructuring of architectures to support usability features such as the ability to
USAPs using a pattern language to simplify the development and cancel a long-running command [7, 8]. Other uses of USAPs in
use of multiple USAPs. We also describe a delivery mechanism industrial settings have been productive [2] but have revealed
that is suitable for industrial-scale adoption of USAPs. The some problems that prevent scaling USAPs to widespread
delivery mechanism involves organizing responsibilities into a industrial use. These problems include:
hierarchy, utilizing a checklist to ensure responsibilities have
been considered, and grouping responsibilities in a fashion that 1. Prior efforts have involved personal contact with USAP
both supports use of multiple USAPs simultaneously and also researchers, either face to face or in telephone conversations.
points out reuse possibilities to the architect. This process does not scale to widespread industrial use.
2. The original USAPs included UML diagrams modifying the
Categories and Subject Descriptors MVC architectural pattern to better support the usability
D.2.2 [Design Tools and Techniques] User interfaces; D.2.11 concern. Although intended to be illustrative, not
[Software Architectures]: Patterns; H.5.2 [User Interfaces] prescriptive, software architects using other overarching
Theory and Methods patterns (e.g., legacy systems, SOA) viewed these UML
diagrams as either unrelated to their work or as an unwanted
recommendation to totally redesign their architecture.
General Terms
Design, Human Factors. 3. The original use of USAPs was as a collection of individual
patterns. Even using one pattern involved processing a large
amount of detailed information. Applying multiple USAPs
Keywords simultaneously is likely to overwhelm software architects
Software Architecture, Usability, Human-Computer Interaction, with information.
HCI
In this paper, we introduce a pattern language [1] for USAPs that
reduces the information that architects must absorb and produces
Permission to make digital or hard copies of all or part of this work for information at a level that applies to all architectures. We also
personal or classroom use is granted without fee provided that copies are discuss the design of a delivery mechanism suitable for industrial-
not made or distributed for profit or commercial advantage and that scale adoption of USAPs.
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee. 2. BACKGROUND
A USAP has six types of information. We illustrate the types with
I-USED’08, September 24, 2008, Pisa, Italy information from the cancellation USAP [9]
1. A brief scenario that describes the situation that the USAP is
intended to solve. For example, “The user issues a command
then changes his or her mind, wanting to stop the operation “Alarms, Events and Alerts”, “User Profile” and “Environment
and return the software to its pre-operation state.” Configuration” is shown in Figure 1.
2. A description of the conditions under which the USAP is
relevant. For example, “A user is working in a system where
the software has long-running commands, i.e., more than one
second.”
3. A characterization of the user benefits from implementing
the USAP. For example, “Cancel reduces the impact of
routine user errors (slips) by allowing users to revoke
accidental commands and return to their task faster than
waiting for the erroneous command to complete.”
4. A description of the forces that impact the solution. For
example, “No one can predict when the users will want to
cancel commands”
5. An implementation-independent description of the solution,
i.e., responsibilities of the software. For example, one
implication of the force given above is the responsibility that
“The software must always listen for the cancel command.”
6. A sample solution using UML diagrams. These diagrams Figure 1 USAP Pattern Language for “User Profile”,
were intended to be illustrative, not prescriptive, and are, by “Alarms, Events and Alerts”, and “Environment
necessity, in terms of an overarching architectural pattern Configuration”
(e.g., MVC). The pattern language has two types of USAPs. “End-User
It is useful to distinguish USAPs from other patterns for software USAPs” follow the structure given in Section 2. Their purpose
design and implementation. USAPs are not user interface patterns, from a user’s point of view can be expressed in a small scenario,
that is, they do not represent an organization or look-and-feel of a they have conditions under which they are relevant, benefits for
user interface [e.g., 11]; they are software architecture patterns the user can be expressed and they require the fulfillment of
that support UI concerns. Nor are USAPs structural software software responsibilities in the architecture design. End-User
architecture patterns like MVC; they are patterns of software USAPs are used by the requirements team to determine which are
responsibilities that can be applied to any structure. As such, they applicable to the system being developed. In this example, they
can be applied to any legacy architecture and can support the are “User Profile”, “Alarms, Events and Alerts”, and
functionality called for in UI patterns. “Environment Configuration”.
The pattern language also contains what we are calling
“Foundational USAPs”. These do not have the same six portions
3. A PATTERN LANGUAGE FOR USAPs as the End-User USAPS. For example, there is no scenario, no
Through collaboration among academic and industrial researchers
description of conditions, and no benefits to the user for the
and usability engineers, we are constructing three USAPs for
Foundational USAPs. Rather, they act as a framework to support
process control and robotics applications. The first author and her
the construction of the End-User USAPs that make direct contact
colleagues in the industry research team drafted an “Alarms,
to user scenarios and usability benefits. For example, all of the
Events and Alerts” USAP while, independently, the last three
End-User USAPs that we present have an authoring portion and
authors drafted a “User Profile” USAP and an “Environment
an execution portion, that is, they are specializations of the
Configuration” USAP. When these three USAPs were considered
Authoring Foundational USAP and the Execution with Authored
together, it was clear that there was an enormous amount of
Parameters Foundational USAP. These foundational USAPs make
redundancy in the responsibilities necessary for a good solution.
use of other foundational USAPs, Authorization and Logging. We
In addition, in preliminary discussions, industry software
abstracted the commonalities of the End-User USAPs to derive
architects reacted negatively to the large amount of information
the responsibilities of the Foundational USAPs. The
required to implement any one of the USAPs.
responsibilities in the Foundational USAPs are parameterized,
Our early work [4] recognized the possibility of reusing such where the parameters reflect those aspects of the End-User
software tactics as separating authoring from execution and USAPs that differ.
recording (logging), but our subsequent work had not
An example of the parameterization is that the Authoring
incorporated that notion, treating each USAP as a separate
Foundational USAP and the Execution with Authored Parameters
pattern. A consequence of focusing on industrial use is that reuse
Foundational USAP each have a parameter called
in constructing and using USAPs was no longer an academic
SPECIFICATION. The value of SPECIFICATION is “Conditions
thought experiment, but a necessity if industrial users are to
for Alarm, Event and Alerts”, “User profile”, and “Configuration
construct and use USAPs themselves.
description” for the three End-User USAPs, respectively.
We observed that both the industry research team and the
In addition to parameterization, End-User USAPs explicitly list
academic research team independently grouped their
assumptions about decisions the development team must make
responsibilities into very similar categories. This led us to
prior to implementing the responsibilities. For example, in the
construct a pattern language [2] that defines relationships between
“Alarms, Events and Alerts” End-User USAP, the development
USAPs with potentially reusable sets of responsibilities that can
team must define the syntax and semantics for the conditions that
lead to potentially reusable code. Our pattern language relating
will trigger alarms, events or alerts. End-User USAPs may also
have additional responsibilities beyond those of the Foundational The design includes a set of radio buttons for each responsibility
USAPs they use. For example, the “Alarms, Events and Alerts” that are initially set to “Not yet considered.” The architect reads
End-User USAP has an additional responsibility that the system each responsibility and determines whether it is not applicable to
must have the ability to translate the names/ids of externally the system being designed, already accounted for in the
generated signals (e.g., from a sensor) into the defined concepts. architecture, or that the architecture must be modified to fulfill the
Both the assumptions and additional responsibilities will differ for responsibility. If “Not applicable”, “Must modify architecture to
the different End-User USAPs. address this” or “Architecture addresses this” is selected, then the
There are three types of relationships among the Foundational responsibility’s checkbox is automatically checked. If “Not
USAPs and these are shown in Figure 1 as different color arrows. considered”, “Must modify architecture or “Discuss status of
The Generalization relationship (turquoise) says that the responsibility”, is selected, the responsibility will be recorded in
Foundational USAP is a generalization of part of the End-User To-Do list generated from the website (Figure 3). We expect this
USAP. The End-User USAP passes parameters to that lightweight reminder to consider each and every responsibility
Foundational USAP and, if there are any conditionals in the will not be too much of a burden for the architect, but will
responsibilities of the Foundational USAP, the End-User USAP increase the coverage of responsibilities, which is correlated with
may define the values of those conditionals. The Uses relationship the quality of the architecture solution [8].
(black) also passes parameters, but the USAPs are at the same As Figure 2 show, the responsibilities are arranged in a hierarchy,
level of abstraction (the foundational level). The Depends-On which reflects both the relationship of End-User and Foundational
relationship (red) implies a temporal relationship. For example, USAPs and the internal structure within a Foundational USAP.
the system cannot execute with authored parameters unless those This hierarchy divides the responsibilities into manageable sub-
parameters have first been authored. The double headed arrow parts. The checkboxes enforce this structure by automatically
between authoring and logging reflects the possibility that the checking off a higher-level box when all its children have been
items being logged may be authored and the possibility that the checked off, and conversely, not allowing a higher-level box to be
identity of the author of some items may be logged. checked when one or more of its children are not. Thus, this
Foundational USAPs each have a manageable set of mechanism simultaneously addresses the problems of providing
responsibilities (Authorization has 11; Authoring, 12; Execution guidance without intervention by USAP researchers and
with authored parameters, 9; and Logging 5), as opposed to the 21 simplifying the information provided to the software architect.
responsibilities of the Cancel USAP that seemed to be too much Another mechanism for simplifying the information delivered to
for our experiment participants to absorb in one sitting [7]. These an architect is that each responsibility has additional details
responsibilities are further divided into groups for ease of available only by request of the architect. These details include
understanding, e.g., Authoring is separated into Create, Save, more explanation, rationale about the need for the responsibility
Modify, Delete and Exit the authoring system. This division into and the forces that generated it, and some implementation details.
manageable Foundational USAPs simplifies the creation of future This information is easily available, but not “in the face” of the
USAPs that use them. For example, the User Profile End-User software architect. As well as simplifying the presentation, this
USAP requires only the definition of parameters and the values mechanism de-emphasizes the role of illustrative examples
for one conditional, and pointers to the Authoring and Execution situated in reference architecture like MVC. We expect that this
Foundational USAPs. presentation decision will reduce the negative reactions to generic
example UML diagrams. When using the tool in-house in
4. DELIVERING A SINGLE USAP TO industry, the reference architecture used in example solutions
SOFTWARE ARCHITECTS could be changed to an architecture used by that industry. This
The roadblocks to widespread use of USAPs in industry identified would both accelerate understanding of the examples and increase
in the introduction were (1) the need for contact with USAP the possibility of re-using the sample solution. This presumes that
researchers in the development process, (2) reactions to examples the tool is constantly managed and updated by in-house usability
using a particular overarching architectural pattern (MVC) and (3) experts and software architects, a presumption facilitated by
an overwhelming amount of information delivered to the software delivering the examples in separate web pages.
architect. Data from our laboratory study and the pattern language Although the hierarchy of responsibilities reflects the relationship
outlined above put us in a position to solve these problems. of the End-User USAPs and the Foundational USAPs, the
Our laboratory study [7] showed that a paper-based USAP could difference between the types of USAPs is not evident in the
be used by software engineers 1 without researcher intervention, to presentation of responsibilities. It was a deliberate design choice
significantly improve their design of an architecture to support the to express each responsibility in terms of the End-User USAP’s
users’ need to cancel long-running commands. Although vocabulary. Thus, the responsibilities in Figure 2 are couched in
significantly better than without a USAP, these software terms of “User Profile”, “Configuration Description”, “Conditions
engineers seemed to disregard many of the responsibilities listed for Alarms, Events, and Alerts” and this string replaces the
in the USAP in their designs. To enhance attention to all parameter SPECIFICATION in the Foundational Authoring
responsibilities, we have chosen to design a web-based system USAP.
that presents responsibilities in an interactive checklist (Figure 2).
1
The participants in our lab study had a Masters in SE or IT, were
trained in software architecture design, and had an average of
over 21 months in industry.
Figure 2: Prototype of a web-based interface for delivering USAP responsibilities to industry software architects.
Figure 3: Prototype “to do” list produced from those responsibilities that are marked as requiring architectural modification.
In the next section, we discuss how we anticipate managing the responsibilities and hence the reuse possibilities of fulfilling
situation when the architect chooses multiple USAPs as being them through a single piece of parameterized code.
relevant to the system under construction. This will allow The problem introduced by this form of the presentation is that
distribute architecture teams both to record rationale for their now the radio buttons becomes ambiguous. Does the entry
choice and to discuss potential solutions. Attaching design “Architecture addresses this” mean that all of the three
rationale and discussion is optional so our delivery tool will responsibilities have been addressed or only some of them? We
support discussion, but not require it, keeping the tool resolve this ambiguity by repeating the radio buttons three
lightweight. times, once for each occurrence of the responsibility. Thus, the
At any point in the process of considering the different three responsibilities will be combined into one textual
responsibilities, the architect can generate a “to do” list. This is description of the responsibility but three occurrences of the
a list of all of the responsibilities that have been checked as “Not radio buttons.
yet considered” or “Must modify architecture”. See Figure 3 for
an example. The list can then be entered into the architect’s 6. CURRENT STATUS AND FUTURE
normal task list and will be considered as other tasks are WORK
considered. At this writing, we have developed the pattern language for
Supporting world wide distribution of the architecture team in three End User USAPs and four Foundational USAPs (Figure 1)
the use of USAPs has two facets. and have fleshed out all the responsibilities for these seven
USAPs. We have constructed a prototype delivery tools for a
• Enable world wide access browser based checklist and “to do” list generator.
• Reduce the problems associated with simultaneous updates We plan to test the delivery mechanism in an ongoing industrial
by different members of the team. development effort. This will demonstrate strengths and
The use of the World Wide Web for delivery allows world wide weaknesses of our approach and we will iterate to resolve any
access with appropriate access control. Standard browsers problems or capitalize on any opportunities. One suggestion put
support the concept of check lists and producing the “to do” forth in early industry feedback is to enhance the to-do list by
lists. assigning expected effort to each responsibility. One
Allowing simultaneous updates is not supported by standard requirements engineer at ABB said that her perception of the
browsers. Some Wikis do support simultaneous updates, e.g. effort needed to implement a scenario had been thoroughly
MediaWiki [www.mediawiki.org], but we do not yet know revised just be looking at the to-do list. By adding estimated
whether these wikis directly support checklists and the hours to the responsibilities, industry would get a better estimate
generation of “to do” lists. We are currently investigating which of the usability improvements’ translation into software
tool or combination of tools will be adequate for our needs and implementation cost. These estimates would vary depending on
what modifications might have to be made to those tools. many factors such as underlying architectural style,
implementation language, skill of programmers, etc. but a large
5. DELIVERING MULTIPLE USAPS TO organization may have enough data from previous projects to
make such estimates for their organization. In addition, such a
SOFTWARE ARCHITECTS feature could emphasize the savings realized by reuse;
Our motivation for developing the USAP Pattern Language was responsibility-implementations that serve multiple End-User
partially to simplify the delivery of USAPs when multiple USAPs would show up as requiring very little effort after the
USAPs are relevant to a particular system. We also want to first implementation.
indicate to the architect the possibilities for reuse. In this
section, we describe how we anticipate accomplishing these two The delivery platform that we have described here, to be used by
goals. software architects, is envisioned to be the final portion of a tool
chain. There are two additional roles involved in the
Recall that the Foundational USAPs are parameterized and each development and use of USAPs. First, USAP developers will
End User USAP provides a string that is used to replace the have to create USAPs within the stylized context of the USAP
parameter. For instance, consider a responsibility from the Pattern Language. Tool support for USAP developers will
Authoring Foundational USAP “The system must provide a way greatly simplify the creation of USAPs.
for an authorized user to create a SPECIFICATION”. When
three End User USAPs are relevant to the system under design, The second role is the requirements definers; often a team
such as “User Profile”, “Environment Configuration”, and comprised of technologists and human factors engineers,
“Alarms, Events and Alerts”, the three responsibilities are usability engineers, designers, or other users or user advocates.
displayed to the architect as “The system must provide a way for Figure 4 shows how we envision a tool supporting this role.
an authorized user to create a [User Profile, Configuration
description, Conditions for Alarm, Event and Alerts].
This presentation satisfies two goals and introduces one
problem. Presenting three responsibilities as one reduces the
amount of information displayed to the architect since every
Foundational USAP responsibility is displayed only once, albeit
with multiple pieces of information. This presentation also
indicates to the architect the similarity of these three
[2] Adams, R. J., Bass, L., & John, B. E. (2005) Applying
general usability scenarios to the design of the software
architecture of a collaborative workspace. In A. Seffah, J.
Gulliksen and M. Desmarais (Eds.) Human-Centered
Software Engineering: Frameworks for HCI/HCD and
Software Engineering Integration. Kluwer Academic
Publishers.
[3] Bass, L., John, B., & J. Kates, (2001), “Achieving Usability
through Software Architecture,” Technical Report
CMU/SEI-2001-TR-005, Software Eng. Inst., Carnegie
Mellon Univ., 2001.
Figure 4: Tool to support the requirements elicitation [4] Bass, L., & John, B. (2003) “Linking Usability to Software
process Architecture Patterns through General Scenarios,” The J.
The requirements team has available to them a repository of Systems and Software, vol. 66, no. 3, pp. 187-197, 2003.
USAPs. They select the ones that are appropriate for the system [5] Folmer, E. (2005) Software Architecture Analysis of
being constructed. In our experience, the USAP end-user Usability, Ph.D. thesis. Department of Computer Science,
scenarios are very general and can be used to invoke ideas about University of Groningen, Groningen.
how they apply to the system at hand. However, industrial teams
would like to tailor these scenarios to match their everyday [6] Folmer, E., van Gurp, J., Bosch, J. (2003) A Framework for
usability issues. Thus, the tool supporting requirements definers capturing the relationship between usability and software
will allow them to re-write the general scenarios to suit their architecture; Software Process: Improvement and Practice,
specific application. Volume 8, Issue 2. Pages 67-87. April/June 2003.
The tool then creates input for the delivery tool while [7] Golden, E, John, B. E., & Bass, L. (2005) The value of a
simultaneously combining redundant responsibilities. The usability-supporting architectural pattern in software
output of the requirements definition process will then be architecture design: A controlled experiment. Proceedings
presented to software architects, as described in this paper, to of the 27th International Conference on Software
aid in their architecture design process. Engineering, ICSE 2005 (St. Louis, Missouri, May, 2005).
In summary, USAPs have been proven to be useful to software [8] Golden, E., John, B. E., Bass, L. (2005) Quality vs.
architects but have also demonstrated some problems that hinder quantity: Comparing evaluation methods in a usability-
industrial use. Definition of a USAP Pattern Language and an focused software architecture modification task.
appropriate selection of tools supporting the roles involved in Proceedings of the 4th International Symposium on
the creation and use of USAPs should simplify industrial use. Empirical Software Engineering (Noosa Heads, Australia,
We are currently constructing versions of these tools and testing November 17-18 2005).
the extent to which they do, in fact, enable the industrial use of [9] John, B. E., Bass, L. J., Sanchez-Segura, M-I. & Adams,
USAPs. R. J. (2004) Bringing usability concerns to the design of
software architecture. Proceedings of The 9th IFIP Working
7. ACKNOWLEDGMENTS Conference on Engineering for Human-Computer
We would like to thank Fredrik Alfredsson and Sara Lövemark Interaction and the 11th International Workshop on
for their contributions to the “Alarms, Events and Alerts” Design, Specification and Verification of Interactive
USAP. This work was supported in part by funds from ABB Inc. Systems, (Hamburg, Germany, July 11-13, 2004).
The views and conclusions in this paper are those of the authors [10] Juristo, N., Moreno, A. M., Sanchez-Segura, M. (2007),
and should not be interpreted as representing the official “Guidelines for Eliciting Usability Functionalities”, IEEE
policies, either expressed or implied, of ABB. Transactions on Software Engineering, Vol. 33, No. 11,
November 2007, pp. 744-758.
8. REFERENCES [11] Tidwell, J. (2006), Designing Interfaces: Patterns for
[1] Alexander, C. (1977). A Pattern Language: Towns, Effective Interaction Design. O’Reilly Media: Sebastopol,
Buildings, Construction. USA: Oxford University Press. CA.
ISBN 978-0195019193.