Module 2

(11 hours)

Architectural Design—Guidelines for User Interface Architectures,

Design Space and Rules, Applying Design Space with an Example, A
Validation Experiment.

Applying Design Space with an Example, A Validation Experiment.

The Quantified Design Space- Background, Quantified Design Space.

1
 Architectural Design
• Provide interactive user interface for
software functions
• Design space is large including
25 functional dimensions
19 structural dimensions

2
 Basic Structural Model
for User Interface Software

Device Shared Application

Dependent User Interface Specific
Component Component Component

Device Application
Interface Interface
• Device Dependent Component:
– contains code specific to that particular device.
• Shared User Interface Component:
– contains code supporting UI of multiple application program.
• Application Specific Component:
– contains code specific to one particular application program.
– Cannot be reused in other applications
– Contains functions core to application & application specific UI code.
3
 Function Dimensions
• Identify the requirements for a user
interface system that most affect its
structure.
• Function dimensions are grouped into 3
1. External Requirements
2. Basic Interactive Behaviour
3. Practical Consideration

4
 Function Dimensions
1. External Requirements
– Includes requirements of the particular
applications+ users+ I/O devices+ constraints
imposed by surrounding computer system.
2. Basic Interactive Behavior
– Includes key decisions about User Interface
behavior influencing internal structure.
3. Practical Consideration
– Development cost+ degree of adaptability of the
system
5
 External Requirements
External Event Handling User Customizability

• No external events • High

• process events while • Medium
waiting for input. • Low
• External event preempt user
commands

User adaptability across devices Computer System

Organization
• None • Uniprocessing
• Local behaviour change. • Multiprocessing
• Global behaviour change • Distributed Processing
• Application Semantic
change

6
Interactive Behaviour

1. Menu Selection.
2. Form Filling.
3. Command Language.
4. Natural Language.
5. Direct Manipulation.

7
 Practical Consideration
Application Portability across UI Styles.
1. High
2. Medium
3. Low

8
 Structural Dimensions
• Design alternatives for the overall structure of
system grouped to 3 classes.
1. Division of functions+ knowledge among modules.
– Considers how system functions are divided into modules, the
interfaces between modules and information contained within
each module
2. Representation Issues
– Consider data representation used within the system.
3. Control flow, Communication & Synchronization issues
– Consider dynamic behavior of user-interface code

9
Division of functions+ knowledge
among modules
Application Interface Abstract Device variability
Abstraction level (Device interface)

• Monolithic program
• Abstract device • Ideal device
• Tool Kit
• Parameterized device
• Interaction manager with fixed
datatype. • Device with variable
operation
• Interaction manager with
extensible datatype. • Adhoc device
• Extensible Interaction
Manager.

10
 Representation Issues
Notation for user-interface definition is a representation dimension
-> It classifies the techniques used for defining the appearance and behavior of the
user interface.

1. Implicit in shared user-interface code

2. Implicit in application code
3. External Declarative notation
4. External Procedural notation
5. Internal Declarative notation
6. Internal Procedural notation

11
 Representation Issues
1. Implicit in shared user-interface code:
Information is associated with shared code.
 Ex: visual appearance of menu might be implicit in menu routines supplied by
toolkit.

2. Implicit in application code:

 Information is associated with application code.
Not available for shared code access.
 Ex: handling semantic feedback in direct-manipulation system

12
 Representation Issues

3. External Declarative notation:

Information is stored as a non procedural specification separate from the

body of the application program.

 ex: a grammar or tabular specification, Graphical specification methods

4. External Procedural notation:

 Information is stored as a procedural specification separate from the body

of the application program.

 Ex: macro definition capability

13
 Representation Issues
5. Internal Declarative notation:
 Information is stored as a non procedural specification within the
application program.
 Ex: List of menu entries provided to a toolkit menu routine.

6. Internal Procedural notation:

 Information is stored as a procedural specification within the body of
application program.
 Ex: useful in handling application-specific feedback in direct manipulation
interfaces since it has adequate flexibility and efficient access to application
semantics.

14
Control Flow, communication and
Synchronization issues.
Basis of communication is a Communication Dimension.

• Communication Dimension classifies system according to whether the

communication between modules depends on shared state, events or both.
• Classification:
1. Events : communication through events.
2. Pure State : communication through shared state. Recipient repeatedly check
the state variables to detect changes.
3. State with Hints : communication through shared state. Changes of state
variables were informed to receiver by events.
4. State plus events : both shared state and events are used.

15
Control Flow, communication and
Synchronization issues.
Control Thread Mechanism.

• Control Thread Mechanism describe method to support multiple logical

threads of control.
• Classification
1. None : Single control thread is used.
2. Standard Processes :
• Independently scheduled process in separate address space.
• Provide security against other processes
• Inter process communication is costly.

16
Control Flow, communication and
Synchronization issues.
Control Thread Mechanism.
Classification:

3. Light weight processes:

• Independently scheduled entities with shared address space.
• Suitable only for mutually trusting process due to lack of security.
• Inter process communication cost is less.
4. Nonpreemptive processes:
• Processess without preemptive scheduling in shared address space.
• Simple to implement.

17
Control Flow, communication and
Synchronization issues.
Control Thread Mechanism.
Classification:

5. Event Handlers:
• Pseudoprocesses that are invoked through a series of subroutine calls.
• Each call should return before another event handler process call.
• Control flow is restricted. Ex: waiting for another process cannot occur
inside a subroutine called by an event handler.
6. Interrupt-service routines:
• Hardware level event handling.
• Allow for preemptive scheduling.

18
 Design Rules for User Interface
Architecture
Connections between dimensions is given as

- Choice along one dimension favours / disfavours

particular choice in another dimension.

- Ex: large amount of memory disfavours high speed of

processing.

- Designers Task: is to consider all correlations possible

and select the one suitable for the system.

19
 Notation of Design Rule:

- A +ve or –ve weight is associated with particular

combinations of alternatives from 2 (or more)
dimensions.

- Summing the weights of all applicable rules.

- Best design is the one with highest score.

20
 Two Categories of Design Rule

Linking functional Interconnecting structural

dimension to structural dimensions
dimensions
-Ensures internal
- Indicates how the system consistency of the design.
Li Li
requirements leads to
structural design. -Complicates the task of
finding highest score
design.

21
 Sample Rules:
Rules linking functional dimension & structural dimension

- If external event handling requires preemption of user

commands, then a preemptive control-thread
mechanism is used.

- High user customizability favors external notations for

user-interface behavior.

- Stronger requirements for user-interface adaptability

across devices favor higher levels of application-
interface abstraction.

- A distributed system organization favors event-based

communication.
22
 Sample Rules:
Rules linking functional dimension & structural dimension

- The basic user-interface class affects the choice of

application-interface abstraction.

- A high requirement for application portability across

user-interface styles favors the higher levels of
application-interface abstraction.

23
 Sample Rules:
Rules interconnecting structural dimension

- Choice of application interface abstraction influence

choice of notation of user interface behavior.

- Monolithic programs favors implicit data

representation.

- Toolkit system favor implicit + internal declarative

notation.

- Interaction manager favors implicit + internal

declarative notation.

- Extensible Interaction manager favors procedural

notation.

24
 Applying Design Space: Example
- Sample System: CT programming language and environment.

- CT language is designed for creation of high quality,

interactive educational application.

- Ex: physics simulation, instruction in musical notation.

- System is used by : Authors who are expert in their subject

but have limited programming experience.

- Implementation : on a variety of computer + workstations

- Portability of application program is an important goal.

25
 CT’s FUNCTIONAL REQUIREMENTS IN
TERMS OF THE DESIGN SPACE:
- No requirement for external event handling.

- No end-user customizability is needed.

- User-interface adaptability across devices may require local

behavior changes.

- Computer system organization may be uniprocessing or

multiprocessing. CT does not make provision for distributed
system.

- Basic interface class is usually direct manipulation, but menu

selection is also used.

- Medium portability of applications across user-interface styles is

required.

26
Architecture of CT :classified in structural
dimensions
- Application-interface abstraction level falls in the
toolkit class.

- Device interface uses a parameterized abstract device.

- User-interface notation is mostly implicit; some aspects

are implicit in shared code, others are implicit in the
application. Limited use is made of internal procedural
notation.

- Communication is based on events; no shared state

variables are used.

- CT uses single thread of execution

27
 Validation Experiment
- Is done to Test the Validity of design space and rules

Rule’s Actual designs of

recommendation UI system
compared

- Six systems were taken for study and test was carried
as follows:

- Step 1: Designer of each system describe s/m in terms

of design space.

- Design space means by describing functional and

structural dimension

28
 Validation Experiment
- Step 2: Functional requirements given to program.

- Searched structural alternatives that are most highly

rated by rule set.

- Step 3:

Rule’s Actual system

recommendation description
Compared to

- Tests showed moderate to substantial degree of

agreement between Rule prediction and actual system
designs.

29
 Quantified Design Space

- Purpose: To analyze and compare the software

designs in an application domain.
- Existing Techniques:
1) Prototyping Techniques: demonstrate feasibility or
investigate the questions about a design.
2) Formal software Inspection: find errors in design
3) Formal Specification language: make assertions
about design

30
 Quantified Design Space

–QDS is a mechanism for translating system

requirements into functional and structural
design alternatives, and for analyzing these
alternatives in a quantitative manner.

– 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.

31
 Quality Function Deployment

- Is a Quality Assurance Technique.

Customer Technical requirements

at each stage of product
needs
development

translated to

- Used by Japanese automobile companies

32
 Quality Function Deployment

- 6 Benefits:

1. Issues in development are raised in timely fashion, and

can be dealt with before they become problems

2. Decisions are recorded in a structural framework, and

can be traced when necessary.

3. Requirements are less likely to be misinterpreted at

any step in the development process.

33
 Quality Function Deployment

4. Rework is reduced, and the need for changes is

minimized, resulting in shorter time to market.

5. Product knowledge is captured in a defined structure,

and is accessible both for the current product
development and for future work.

6. Customer needs are more closely matched by the final

product.

34
 QFD Process

- Use graphical notation

Realizations
Requirements

Translated at
each stage of
product
development

35
 QFD Framework

1. Customer requirements :

● Representatives from each stakeholder are recruited to

participate in QFD.

● Customers explain their requirements in their own

words/language.

● Cross functional team analyze these requirements and

specify the requirements in understanding vocabulary.

36
 QFD Framework

2. Realization mechanism : QFD team identifies

realization mechanisms to meet customer
requirements.

3. Object Target values :

● For each realization mechanism target values are

established.

● Target values may be qualitative/ quantitative goals

37
 QFD Framework

4. Relationship between each realization mechanism and

customer requirement is established.

5. -ve/ +ve correlation between realization mechanism is

determined:

6. Organizational difficulty :

38
 QFD Framework

7. Technical importance rating:

8. After relationships and correlations are determined

the QFD team analyze the framework, to select the
realization mechanisms to be used in product.

39