Module 2

Architectural DesignGuidelines for User Interface Architectures, Design Space and Rules,
Applying Design Space with an Example, A Validation Experiment. The Quantified Design
SpaceBackground, Quantified Design Space.

Architectural Design
Guidelines for user-interface architectures by Thomas G Lane
1) Design spaces and rules
Design Space is the multidimensional combination and interaction of input variables (e.g. material
attributes) and process parameters that have been demonstrated to provide assurance of quality.
A design space identifies the key functional and structural choices made in creating a system design,
and it classifies the alternatives available for each choice.
Within a design space, we can formulate design rules that indicate good and bad combinations of
choices and use them to select appropriate system design based on functional requirements. The
design space is useful in its own right as a shared vocabulary for describing and understanding
systems.
This work should be viewed as a means of codifying software design knowledge for use
in day-to-day practice and in the training of new software engineers. For this purpose, a set of design
rules need not produce a perfect or best possible design. The rules will make a valuable contribution
if they can help a journeyman designer to make choices comparable to those that a master designer
would make or even just help the journey man to choose a reasonable design with no major errors.
With sufficient experience, designers may create a set of such rules that is complete and reliable
enough to serve as the basis for automated system design, but the rules can be applied in practice
long before that stage is reached.
2) The utility of codified knowledge
The underlying goal of this work is to organize and express software design knowledge in a useful
form. One way of doing this is to develop a vocabulary of well-understood, reusable design concepts
and patterns. If widely adopted, a design vocabulary has three major benefits. First, it aids in
creating a system design by providing mental building blocks. Second, it helps in understanding or
predicting the properties of a design by offering a context for the creation and application of
knowledge. Third, it reduces the effort needed to understand another persons design by reducing
the number of new concepts to be learned.

3) The notion of a design space

The central concept is that of a multidimensional design space that classifies system architectures.
Each dimension of a design space describes variation in one system characteristic or design choice.
Values along a dimension correspond to alternative requirements or design choices.
For example, required response time could be a dimension; so could the means of interprocess
synchronization (e.g., messages or semaphores). A specific system design corresponds to a point in
the design space, identified by the dimensional values that correspond to its characteristics and
structure.

The different dimensions are not necessarily independent; in fact it is important to discover
correlations between dimensions, in order to create design rules describing appropriate and
inappropriate combinations of choices. One empirical way of discovering such correlations is to see
whether successful system designs cluster in some parts of the space and are absent from others.
A key part of the design space approach is to choose some dimensions that reflect requirements
or evaluation criteria, while other dimensions reflect structure. Correlations found among such
dimensions can provide direct design guidance: they show which design choices are most likely to
meet the functional requirements for a new system.
The dimensions that describe functional and performance requirements make up the functional
design space, while those that describe structural choices make up the structural design spaces. The
dimensions of a design space are usually not continuous and need not possess may useful metric. A
dimension that represents a structural choice is likely to have a discrete set of possible values, which
may or may not have any meaningful ordering.
A basic structural model of user interface architecture
To describe structural alternatives, we need some terminology that identifies the components of a
system. The terminology must be quite general, or it will not apply to some structures. A useful
scheme for user-interface systems divides any complete system into three components or groups of
modules:
2

1. An application specific component: This consists of code that is specific to one particular
application program and is not intended to be reused in another applications. In particular, this
component includes the functional core of the application. It may also include applicationspecific user-interface code.
2. A shared user interface: This consists of code that is intended to support the user interface of
multiple application programs. If the software system can accommodate different types of I/O
devices, only code that applies to all device types in included here.
3. A device-dependent component: This consists of code that is specific to a particular I/O
device class.
In a simple system the second and third component might be empty: there might be no
shared code other than device drivers, or the system might not provide support for multiple device
types.
The inter module divisions that the design space considers are the division between
application-specific code and shared user-interface code on the one hand, and between devicespecific code and shared-user interface on the other. These divisions are called the application
interface and device interface respectively.

A Design Space for User Interface Architectures

User interface software are systems whose main focus is on providing an interactive user interface
for some software functions.
The design space reported here, together with its associated rules, describes architectural alternatives
for user interface software.
The complete design space contains 25 functional dimensions, 6 of which are described here. Three
to five alternatives are recognized in each of these dimensions. There are 19 structural dimensions
(5 of which are described here), each offering two to seven alternatives.
3

Sample functional dimensions

The functional dimensions identify the requirements for a user-interface system that most affect its
structure. These dimensions fall into three groups:
1) External requirements. This group includes requirements of the particular applications,
users, and I/O devices to be supported, as well as constraints imposed by the surrounding
computer system.
2) Basic interactive behavior. This group includes the key decisions about user interface
behavior that fundamentally influence internal structure.
3) Practical considerations. This group covers development cost considerations; primarily, the
required degree of adaptability of the system.
1) External Requirements
External event handling is an example of a dimension reflecting an application-imposed
external requirement. This dimension indicates whether the application program needs to respond to
external events (defined as events not originating in the user interface), and if so, on what time
scale. The design space recognizes three alternative choices:
No external events
Process events while waiting for input
External events preempt user commands
User customizability is an example of a user-imposed external requirement. The design space
recognizes three levels of end user customizability of a user interface:
High
Medium
Low
User interface adaptability across devices depends on the expected range of I/O devices that
the user interface system must support. This dimension indicates the extent of change in user
interface behavior that may be required when changing to a different set of I/O devices.
None
Local behavior changes
Global behavior changes
Application semantics changes
Computer system organization is an example of a dimension describing the surrounding
computer system. This dimension classifies the basic nature of the environment as follows:
Uniprocessing
Multiprocessing
Distributed processing

2) Basic interactive behavior

Basic interface class identifies the basic kind of interaction supported by the user interface
system. The design space includes:
Menu selection
Form filling
Command language
Natural language
Direct manipulation
3) Practical Considerations
Application portability across user interface styles is an example of a dimension defining
the required degree of adaptability of a user interface system. This dimension specifies the degree to
which application-specific code is insulated from user interface style changes.
High
Medium
Low
Sample Structural Dimensions
The structural dimensions represent the decisions determining the overall structure of a user
interface system. These dimensions also fall into three major groups:
1) Division of functions and knowledge between modules. This group considers how system
functions are divided into modules, the interfaces between modules, and the information contained
within each module.
2) Representation issues. This group considers the data representations used within the system. We
must consider both actual data, in the sense of values passing through the user interface, and metadata that specifies the appearance and behavior of the user interface.
3) Control flow, communication, and synchronization issues. This group considers the dynamic
behavior of the user interface code.
1) Division of Functions and Knowledge Between Modules
Application interface abstraction level is in many ways the key structural dimension. The design
space identifies six general classes of application interface, which are most easily distinguished by
the level of abstraction in communication:
Monolithic program
Abstract device
Toolkit
Interaction manager with fixed data types
Interaction manager with extensible data types
Extensible interaction manager

Abstract device variability is the key dimension describing the device interface. We view the
device interface as defining an abstract device for the device-independent code to manipulate. The
design space classifies abstract devices according to the degree of variability perceived by the
device-independent code.
Ideal device
Parameterized device
Device with variable operations
Ad-hoc device
2) Representation Issues
Notation for user interface definition is a representation dimension. It classifies the techniques
used for defining user interface appearance and behavior.
Implicit in shared user interface code
Implicit in application code
External declarative notation
External procedural notation
Internal declarative notation
Internal procedural notation
3) Control Flow, Communication, and Synchronization Issues
Basis of communication is a communication dimension. This dimension classifies systems
according to whether communication between modules depends upon shared state, events, or both.
An event is a transfer of information occurring at a discrete time, for example via a procedure call
or message. The classification is
Events
Pure state
State with hints
State plus events
Control thread mechanism describes the method, if any, used to support multiple logical threads
of control. This dimension classifies the possibilities as follows:
None
Standard processes
Lightweight processes
Non-preemptive processes
Event handlers
Interrupt service routines

Design rules for user-interface architecture

These are very few hard-and-fast rules at this level of design. Most connections between design
dimensions are better described by saying that a given choice along one dimension favors or
disfavors particular choices along another dimension: the strength of this correlation varies from
6

case to case. The designers task is to consider all such correlations and to select alternative favored
by the preponderance of the evidence.
Therefore, a natural notation for a design rule is positive or negative weight associated
with particular combinations of alternatives from two dimensions. A given design can be evaluated
by summing the weights of all applicable rules. The best design is then the one with the highest
score. The author prepared a set of design rules of this form that could be mechanically evaluated
and an evaluation program that would rank the structural alternatives when given a set of values for
the functional dimensions.
It is useful to distinguish two categories of rules: those linking functional to structural dimensions,
and those interconnecting structural dimensions. The first group allows system requirements to
drive a structural design, while the second group ensures the internal consistency of the design.
Sample rules
The following are some of the specific design rules that connect the sample dimensions.
1. If external event handling requires preemption of user commands, then a preemptive controlthread mechanism is strongly favored. Without, such a mechanism, very severe constraints
must be placed on all user-interface and application processing in order to guarantee adequate
response time.
2. High user customizability requirements favor external notations for user-interface behavior.
Implicit and internal notations are usually more difficult to access and more closely coupled to
application logic than external notations.

3. Stronger requirements for user-interface adaptability across devices favor higher levels of
application interface abstraction, so as to decouple the application from user-interface details
that may change across devices. If the requirement is for global behavior or application
semantics changes, then parameterized abstract devices are also favored.
4. A distributed system organization favors event-based communication. State-based
communication requires shared memory or some equivalent, which is often expensive to
access in such environment.
5. The basic user-interface class affects the best choice of application-interface abstraction level.
6. A high requirement for application portability across user-interface styles favors the higher
levels of application-interface abstraction.
The preceding rules all relate functional to structural dimensions. Following is an example of the
rules interconnecting structural dimensions.

1. The choice of application interface abstraction level influences the choice of notation for
user interface behaviour
2. In monolithic programs and abstract device application interfaces, implicit representation is
usually sufficient.
3. In toolkit systems, implicit and internal declarative notations are found (parameters to
toolkit routines being of the latter class).
4. Interaction managers of all types use external and/or internal declarative notations.
5. Extensible interaction managers rely heavily on procedural notations, particularly internal
procedural notation, since customization is often done by supplying procedures.

Applying the design space: an example

The sample system is the cT programming language and environment. It is designed for the
creation of high-quality, interactive educational applications for eg , physical simulations or
instruction in musical notation.
It must accommodate authors who are expert in their particular subject matter but have only
limited programming experience.
cTs functional requirements:
1. There is no requirement for external event handling: its not needed in the target class of
applications.
2. Little or no-end-user customizability is needed.
3. User-interface adaptability across devices may require local behavior changes.
4. Computer system organization may be uniprocessing or multiprocessing.
5. Basic interface class is usually direct manipulation, but menu selection is also used.
6. Medium portability of applications across user-interface styles is required.

To describe cT structurally, we classify the cT programming system itself as the shared user
interface code, instructional programs written in cT as application-specific code, and the
underlying platform (including graphics packages, etc.) as device-specific code.
cTs structural dimensions
1. The application-interface abstraction level falls in the toolkit class. Toolkit elements are
provided for common constructs such as menus or scrolling text boxes.
2. The device interface uses a parameterized abstract device.

3. User-interface notation is mostly implicit; some aspects are implicit in the shared code,
while others are implicit in the application.
4. Communication is based on events; no shard state variables are used.
8

5. cT uses basically a single thread of execution.

A validation experiment
To test the validity of the design space and rules, the rules recommendations were
compared to the actual designs of some user-interface systems. This experiment used six
systems that had not been studied in the course of preparing the design space and rules. The
test was carried out as follows:
1. A designer of each system was asked to describe his system in the terms of the design
space; that is, to choose the most descriptive category in each functional and structural
dimension.
2. Each systems functional; description was fed into a program that searched for the
structural alternatives that were most highly rated by the rule set.

3. The resulting structural recommendations were compared to the actual system

descriptions.
The six systems covered a fairly wide range of user interface requirements. Among them were two
radically different UIMSs, an integrated programming environment for teaching novice
programmers, the cT system described above, a system for automatic creation of graphical database
displays, and a flight simulator control program.

This experiment compared the rules to the judgments of a completely separate group of designers.
The extent of correlation is therefore especially striking: it depends not only on the rules
successfully representing the knowledge on which they were based, but on agreement between two
unrelated groups of designers. Therefore, this experiment shows that:
There is a significant body of agreement among expert user interface system designers about
structural choices.
The design space and rules capture (at least part of) that agreement.

The Quantified Design space

1.Overview
The increasing attention paid to software design has not been accompanied by the
development of tools to analyze these designs. Formal specification languages allow designers to
make assertions about a design, but there are still no tool for the systematic and quantitative analysis
of designs. QDS is a tool which was developed to analyze and compare software designs in a
specific application domain.
9

It was developed by the authors while working as a project team in the Master of Software
Engineering (MSE) program at Carnegie Mellon University(CMU).
The purpose of the QDS is to analyze and compare software designs in a specific application
domain. It is structured encapsulation of design knowledge, implemented in a software spreadsheet,
for use by system and software designers.
Based on the concept of QFD(Quality function deployment) and design space , the QDS is a
mechanism for translating system requirements into functional and structural design alternatives,
and for analyzing the alternatives in a quantitative manner. The QDS can also be used to produce a
model design for a desired system, analyze and compare existing designs, or suggest improvements
for an existing product.
2. Background
The quantified design space is based on two foundation concepts, the design space and quality functional
deployment.
Design Space
The use of design space for software system design was proposed by Lane.
It identifies the key functional and structural dimensions used to create a system design in a specific
application domain. The design space is multidimensional, and each dimension describes a variation in one
system characteristic or requirement. Values along a dimension correspond to different design alternatives.
Rules are used to encapsulate design knowledge in the form of relationships between Alternatives in
different dimensions of the design space.
Dimensions
The dimension of a design space may be functional or structural in nature. Functional dimensions
describe aspects of the problem space as functional and performance related design alternatives while
structural dimensions describe the solution space as a set of alternative implementation characteristics.
Rules
Some dimensions of the design space are related to each other, and some are independent. Lane describes
the relationships between dimensions as a set of rules that can be categorized as those linking functional to
structural dimensions, and those interconnecting structural dimensions. The first category allows the system
requirements to drive a structural design while the latter ensures the internal consistency of the design.
Lane also discusses automated application of the rules of a design space. Rules may be expressed as
positive or negative weights assigned to a combination of design alternatives. Once, a set of design choices
is selected, we can calculate the score of the design by summing up the weights of the application rules.
Lane prepared a set of rules which could be evaluated mechanically, and validated the design space and
rules in an experiment using six different user-interface systems.
10

Quality function deployment(QFD)

Quality Function Deployment is a quality assurance technique that helps translate customer needs
into the technical requirements needed at each stage of product development - from req. analysis
through design, implementation and into manufacturing and support.
Fundamental to QFD is the goal that the Voice of the customer must be manifested in each step of
product development process. The QFD philosophy focuses on achieving a common understanding
among all stakeholders in the product development process. This approach brings the following
benefits
1. Issues in development process are raised in timely fashion and can be dealt with before they
become problems.
2. Decisions are recorded in structured framework and can be traced when necessary
3. Requirements are less likely to be misinterpreted at any step of development process
4. Rework is reduced and the need for changes is minimized resulting in shorter time to market
5. Product knowledge is captured in a definite structure and is accessible for future work
6. Customer needs are more closely matched by final product
QFD process
QFD is supported by a specific graphical notation and a well defined process for translating
requirements to realization mechanisms at each stage of product development. The steps of QFD
process is described below
1. The scope of the product or service being developed is established, and representatives from each
stakeholder in the development process is recruited to participate in the QFD.
Customer needs are gathered as stated by the customers in their own language.
The team analyses these requirements to reach a common understanding of terms and
vocabulary.
These requirements are entered on left side column in QFD chart.
2. QFD team identifies realization mechanisms that will help meet the customer requirements.
These are entered across top of the QFD chart, thus creating a matrix relating customer
requirements to realization mechanisms.
3. Target values are established for realization mechanisms and are entered along the bottom of
correlation matrix
4. The relationship between each mechanism and customer needs are established to determine
which mechanisms are important in achieving customer needs.
Each relationship is denoted by a graphical symbol indicating a strong, medium or weak
relationship between a requirement and a realization mechanism in the QFD matrix.

11

These relationships are given a numerical weight that is used in calculating the technical
importance of each mechanism.
5. Any Positive or negative correlation between realization mechanisms is determined.
A positive correlation indicates that two realization mechanisms complement each other, while a
negative correlation denotes that one realization mechanism may interfere with the
implementation of other.
These correlations are expressed on the roof of QFD chart by graphical symbols denoting
strongly positive, weakly positive, strongly negative or weakly negative.
6. Difficulty of implementing each realization mechanism is assessed based on the strengths and
weakness of the organization.
The difficulty rating for each realization mechanism is recorded in a row just above the objective
target values.
7. Technical importance rating is calculated by multiplying the customer weighting for each
requirements by the relationship factor for each realization mechanism.
Absolute value for technical importance is translated to relative ranking, indicating the
contribution of a realization mechanism in meeting the needs of the customer
8. After relationships and correlations have been determined , the QFD team analyses the
framework to select realization mechanisms to be used in the product.
a. Target values for each mechanisms are finalized.
b. Correlation factors are inspected to spot conflicts between realization mechanisms
c. Mechanisms with negative correlation factors or high difficulty are good in early prototyping
model and those with negative correlation but low importance are removed.
d. Unneeded mechanisms are removed and any needs that are not addressed are re-examined
Given below is a QFD framework for a multiuser design system for cooperative engineering

12

Fig: Sample QFD framework

3. Quantified Design space

QDS is based on the concept of design space and QFD. QDS takes from the concept of design space
the decomposition of a design into dimensions and alternatives and positive or negative correlation
between design dimensions.
The translation of requirements to realization mechanisms and the analysis of relationships between
mechanisms come from QFD. The implementation of design space on the QFD framework is called
QDS.
Implementation of design space on a QFD framework
The capture of design knowledge can be implemented by using QFD chart as a framework
for the dimensions and alternatives of the design space.
The design space organizes the choices available for a particular design into a hierarchy of
dimensions and alternatives. The result of QFD process represents a particular set of these choices.

13

By explicitly including all alternatives of each dimension in the QFD framework, each alternative
can be analyzed for its ability to meet the customer needs and for its correlations to alternatives in
other dimensions.
The rules of the design space can then be captured in the relationships and correlation factors of the
QFD framework.
The matrix organization of both the design space and the QFD framework is handled by software
spreadsheets.
Functional design space on QFD framework
Customer needs are listed in the cells at the left of the spreadsheet. The weights assigned for
these requirements by customers are placed in separate column.
The functional dimensions and alternatives are placed along the top axis of the QDS.
The relationship of each alternative to the customer requirements is entered in the corresponding
cells of the spread sheet and a series of linear equations produces calculated weights for each
alternative. A higher weight indicates a greater contribution towards meeting the customer needs.
Calculated Weights are further broken down by customer requirements, so the effect of an
alternative on any single customer need can be analyzed easily
A binary design decision mask (0 or 1) represents the designers choice. 1 means selection of an
alternative from the dimension of design space. This decision helps in finding the effective weight.
These effective weights serve as input to structural design space.
Fig below shows a generalized functional level of design space.

14

Structural design space on QFD framework

Structural design space is similar to functional design space, but will large and more complex
because of large number of inputs. The effective weights of the functional dimension and
alternatives are used in the same way as customer weights in the functional design space.
The calculated weights for each structural alternative can be further broken down by customer
requirement. Then the design decisions are made.
Fig below shows a sample structural design space

Sample structural design space

Before final score for a particular design are calculated, the Calculated weights and design decisions
are modified by the correlations between structural design choices.
A correlation factor of 0.5 indicates the alternatives are compatible in the same design,
1 indicates strong positive correlation, and 0 indicates two alternatives are mutually exclusive.
Correlation factors are used to find the final score of the design
The following process is used to apply the correlation factors to each structural design selection
1. Let E1 En be the effective weight of each selected structural alternative
2. Let Cmn be the correlation factor for the alternatives m and n
3. For each selected structural design alternative, add the effective weight of the design alternative
to that of each other selected alternative and multiply each term of the sum by the Correlation
factor from the matrix. The product sums are added together to get the final score.
Ie score = SCij(Ei +Ej)
15

Using a Quantified design space

The most straightforward use of QDS is to compare two existing designs and determine how
well each meets a particular set of customer needs. QDS also serves as an exploratory tool for
designers.
QDS can be used to design a model or ideal system in a particular application domain by selecting a
design with highest possible score. Similarly it can also be used to design a worst system.
Statistical Analysis Techniques are useful when analyzing designs with Quantified design space
Four techniques are
1. Spectrum analysis
2. Contribution analysis
3. Design selection analysis
4. Direct comparison analysis
1. Spectrum analysis
It is based on the position of a particular set of design choices within the range between best
and the worst possible designs. This method can be used to evaluate the overall goodness of a
particular set of designs choices.
The procedure for spectrum analysis is
1. Design a model system. Let Sb be the score of the model system
2. Let Sw be the score of the worst possible set of design choices
3. Let S be the score of the set of design choices to be analysed
4. The spectrum index Is is calculated as
Is

S Sw
*100
Sb S w

Is = 100 indicates that the set of choices is ideal

Is = 0 indicates that the set of choices is that of worst possible system.
2. Contribution analysis
It is used to identify the reasons that one set of design choices get a lower score than other.
This method can be used to identify possible improvements for a particular set of design choices.
It is based on the premise that the difference between two sets of score comes from the
differences between the individual choices of each design. The contribution analysis is performed as
follows:
1. Compare the best design choices with the design choices of a particular system and identify
the QDS dimensions where the choices of the two systems are different.
16

2. Perform the following for each dimension identified in step 1

a. In the dimension i of the ideal system change the design choice from the best
choice to the choice of the system being measured.(all the other choices remains
best)
b. Calculate the new score of the design choices obtained in step 2a
c. The contribution factor of dimension i (Fi) is the difference between the best
score and the score obtained in step 2b
d. The contribution index of the ith dimension (Ci) is

Ci

Fi
Fn

nnumber of dimensions

If Ci is large then the system could be improved if the design choice of the ith dimension is changed
to the best choice
3. Design selection analysis
Design selection analysis computes the no. of dimensions where a particular system
implements the best choices. This method can also be used to evaluate the overall goodness of the
system. Design selection analysis is performed as follows
1. Let Ns be the no. of dimensions where a particular system implements the same choice
as the ideal system.
2. Let Na be the total no. of dimensions in the design space
3. The design selection index d is calculated as
d

Ns
*100
Na

4. Direct comparison analysis

Direct comparison analysis is based on Spectrum analysis. It compares two sets of design
choices to determine the amount by which one is an improvement over the other. Direct comparison
analysis is performed as follows:
1. Let I1 and I2 be the spectrum indices of two systems to be compared.
2. The improvement index Imp is calculated as:
Imp = I1 - I2
In other words , the index is calculated by using scores of the two systems S 1 and S2 and those of
the best/worst system Sb and Sw
If Imp is positive them system 1 has improved by Imp over system 2.
If Imp is negative them system 1 has regressed from system 2.

17