Chapter 8:
Summary
In this chapter, we discuss the programming support that is provided for the
implementation of an interactive system. We have spent much effort up to this point
considering design and analysis of interactive systems from a relatively abstract perspective.
Window systems provide only the crudest level of abstraction for the programmer,
allowing her to gain device independence and multiple application control. They
do not, however, provide a means of separating the control of presentation and
application dialog. We described two paradigms for interactive programming, and
saw that these relate to two means of controlling that dialog – either internal to the
application by means of a read–evaluation loop or external to the application by
means of notification-based programming. Toolkits used with particular windowing
systems add another level of abstraction by combining input and output behaviors
to provide the programmer with access to interaction objects from which to build
the components of the interactive system. Toolkits are amenable to external dialog
control by means of callback procedures within the application. Other dialog control
techniques are provided with yet another level of abstraction in interactive system
development: user interface management systems. UIMS provide a conceptual architecture for dividing up the relationship between application and presentation, and
various techniques were described to implement the logical components of a UIMS.
An interesting additional means of dialog control can be seen to emerge in the use of
graphical specification languages which move dialog control all the way across the
spectrum to reside entirely within the presentation language. This presentation control opens up interactive programming to the non-expert programmer, but at the
cost of a loss of expressiveness.
A programming tools for interactive systems
provide a means of effectively translating abstract designs and usability
principles into an executable form. These tools provide different levels of
services for the programmer. Windowing systems are a central environment for
both the programmer and user of an interactive system, allowing a single
workstation to support separate user-system threads of action simultaneously. Interaction toolkit abstract away from the
physical separation of input and output devices, allowing the programmer to
describe behaviors of objects at a level similar to how the user perceives
them. User interface management systems are the final
level of programming support tools, allowing the designer and programmer to
control the relationship between the presentation objects of a toolkit with
their functional semantics in the actual application.
8.2 ELEMENTS OF WINDOWING SYSTEMS
A windowing system is its ability to provide programmer independence from the specifics of the hardware devices. A typical workstation will involve some visual display screen, a keyboard and some pointing device,
such as a mouse. Any variety of these hardware devices can be used in any interactive system and they are all different in terms of the data they communicate and the
commands that are used to instruct them.
A given windowing system will have a fixed generic language for the abstract
terminal which is called its imaging model. The imaging models are sufficient
to describe very arbitrary images. For efficiency reasons, specific primitives are
used to handle text images, either as specific pixel images or as more generic font
definitions.
Examples of imaging models
Pixels
The display screen is represented as a series of columns and rows of points – or pixels – which
can be explicitly turned on or off, or given a color. This is a common imaging model for personal
computers and is also used by the X windowing system.
Graphical kernel system (GKS)
An international standard which models the screen as a collection of connected segments, each of
which is a macro of elementary graphics commands.
Programmer’s hierarchical interface to graphics (PHIGS)
Another international standard, based on GKS but with an extension to model the screen as
editable segments.
PostScript
A programming language developed by Adobe Corporation which models the screen as a collection of paths which serve as infinitely thin boundaries or stencils which can be filled in with various colors or textured patterns and images.
8.2.1 ARCHITECTURE OF WINDOWING SYSTEMS
Bass and Coutaz [29] identify three possible architectures for the software to implement the roles of a windowing system.
Window systems provide only the crudest level of abstraction for the programmer, allowing her to gain device independence and multiple application control. They do not, however, provide a means of separating the control of presentation and application dialog. We described two paradigms for interactive programming, and saw that these relate to two means of controlling that dialog – either internal to the application by means of a read–evaluation loop or external to the application by means of notification-based programming. Toolkits used with particular windowing systems add another level of abstraction by combining input and output behaviors to provide the programmer with access to interaction objects from which to build the components of the interactive system. Toolkits are amenable to external dialog control by means of callback procedures within the application. Other dialog control techniques are provided with yet another level of abstraction in interactive system development: user interface management systems. UIMS provide a conceptual architecture for dividing up the relationship between application and presentation, and various techniques were described to implement the logical components of a UIMS. An interesting additional means of dialog control can be seen to emerge in the use of graphical specification languages which move dialog control all the way across the spectrum to reside entirely within the presentation language. This presentation control opens up interactive programming to the non-expert programmer, but at the cost of a loss of expressiveness.
A programming tools for interactive systems provide a means of effectively translating abstract designs and usability principles into an executable form. These tools provide different levels of services for the programmer. Windowing systems are a central environment for both the programmer and user of an interactive system, allowing a single workstation to support separate user-system threads of action simultaneously. Interaction toolkit abstract away from the physical separation of input and output devices, allowing the programmer to describe behaviors of objects at a level similar to how the user perceives them. User interface management systems are the final level of programming support tools, allowing the designer and programmer to control the relationship between the presentation objects of a toolkit with their functional semantics in the actual application.
8.2 ELEMENTS OF WINDOWING SYSTEMS
A windowing system is its ability to provide programmer independence from the specifics of the hardware devices. A typical workstation will involve some visual display screen, a keyboard and some pointing device, such as a mouse. Any variety of these hardware devices can be used in any interactive system and they are all different in terms of the data they communicate and the commands that are used to instruct them.
A given windowing system will have a fixed generic language for the abstract terminal which is called its imaging model. The imaging models are sufficient to describe very arbitrary images. For efficiency reasons, specific primitives are used to handle text images, either as specific pixel images or as more generic font definitions.
Examples of imaging models
Graphical kernel system (GKS)
An international standard which models the screen as a collection of connected segments, each of which is a macro of elementary graphics commands.
Programmer’s hierarchical interface to graphics (PHIGS)
Another international standard, based on GKS but with an extension to model the screen as editable segments.
PostScript
A programming language developed by Adobe Corporation which models the screen as a collection of paths which serve as infinitely thin boundaries or stencils which can be filled in with various colors or textured patterns and images.
8.2.1 ARCHITECTURE OF WINDOWING SYSTEMS
Bass and Coutaz [29] identify three possible architectures for the software to implement the roles of a windowing system.
A classic example of a window system based on the client–server architecture is the
industry-standard X Window System (Release 11), developed at the Massachusetts
Institute of Technology (MIT) in the mid-1980s. Figure 8.3 shows the software
architecture of X. X (or X11), as we mentioned earlier, is based on a pixel-based
imaging model and assumes that there is some pointing mechanism available. What
distinguishes X from other window systems, and the reason it has been adopted
as a standard, is that X is based on a network protocol which clearly defines the
server–client communication. The X Protocol can be implemented on different computers and operating systems, making X more device independent.
The X server performs the following tasks:
* allows (or denies) access to the display from multiple client applications;
* interprets requests from clients to perform screen operations or provide other information;
* demultiplexes the stream of physical input events from the user and passes them to the appropriate client;
* minimizes the traffic along the network by relieving the clients from having to keep track of certain display information, like fonts, in complex data structures that the clients can access by ID numbers.
* allows (or denies) access to the display from multiple client applications;
* interprets requests from clients to perform screen operations or provide other information;
* demultiplexes the stream of physical input events from the user and passes them to the appropriate client;
* minimizes the traffic along the network by relieving the clients from having to keep track of certain display information, like fonts, in complex data structures that the clients can access by ID numbers.
Evaluation
1. It is the core support for separate and
simultaneous user-system activity.
(a). windowing systems b. programming tools
c. programming applications d. interaction toolkit
2. It has levels of services for
programmers.
a. windowing systems (b). programming
tools
c. programming applications d. interaction toolkit
3. It brings programming closer to level
of user perception
a. windowing systems b. programming
tools
c. programming applications (d) . interaction toolkit
4. It controls relationship between
presentation and functionality.
a. windowing systems b. programming
tools
(c). user interface management system d. interaction toolkit
5. Which of the following is NOT part of
the layers of development tools?
a. windowing systems b. interaction toolkits
c. user interface management systems (d.). system model
6. It is about programming the abstract
terminal device drivers
image models for output and (partially) input.
a. device update b. system
update
(c). device independence d. software quality
7. It is achieving simultaneity of user
tasks.
a. communication point b. file back up
c. file sharing (d).
resource sharing
8. Which of the following is NOT part of
the possible software architecture.
a. each application manages all processes
b. management role within kernel of operating
system
c. management role as separate application
(d). each devices are connected to a network
9. It has pixel imaging model with some
pointing mechanism.
a. Pixel Software architecture b. System
architecture
c. Mac architecture (d). X Windows
architecture
10. It affects the interfaces especially
modal dialogue box and non-modal dialogue box.
a. system file (b).
system style
c. program information d. file
category
11. It can be an input, output and
intrinsically linked.
(a). interaction object b. linked object
c. attached object d .embedded
objects
12. It is a type of AWT (abstract
windowing toolkit) .
(a). Java toolkit b. Web
toolkit
c. Electrical Toolkit d. Mechanical
Toolkit
13. This toolkit built on top of AWT with
higher level features.
a. run toolkit (b).
swing toolkit
c. error toolkit d. function
toolkit
14. Which of the following is NOT part of
the concern of User Interface Management Systems (UIMS)?
a. conceptual architecture (b). manual techniques
c. implementation techniques d. support
infrastructure
15. It is an example of a UI development
environment
a. web sitemaps b. C
programming language
(c). Visual Basic d. COBOL
(Common Business-
Oriented Language
16. It has separation between application
semantics and presentation.
a. UIMS model algorithms b. UIMS system design
(c). UIMS conceptual architecture d. UIMS interface
17. Which of the following is an example
of lexica under Seeheim model?
a. dialogue control (b). presentation
c. functionality d. dependence
18. Which of the following is an example
of syntactic under Seeheim model?
(a). dialogue control b. Presentation
c. Functionality d. Dependence
19. Which of the following is an example
of semantic under Seeheim model?
a. Dialogue control b. Presentation
(c). Functionality d. Dependence
20. It arose out of implementation
experience but principal contribution is conceptual.
a. Arch model b. Waterfall
model
(c). Seeheim model d. Slinky
model
21. It draws components on screen and set
actions with scripts or links to program.
a. graphical identification b. graphical user
c. graphical interaction (d). graphical
specification
22.
Which of the following is NOT a technique for a
dialogue controller?
a. menu networks b. grammar
notations
c. declarative language (d). manual errors
23. It manages hierarchy and multiple
views.
(a). PAC model b. Seeheim
model
c. MVC model d. Slinky
model
24. It is largely a pipeline model with
graphics interface.
a. PAC model b. Seeheim
model
(c). MVC model d. Slinky
model
(a). windowing systems b. programming tools
a. windowing systems (b). programming tools
a. windowing systems b. programming tools
a. windowing systems b. programming tools
a. each application manages all processes
a. Pixel Software architecture b. System architecture
(a). interaction object b. linked object
(a). Java toolkit b. Web toolkit
a. conceptual architecture (b). manual techniques
a. web sitemaps b. C programming language
Oriented Language
a. dialogue control (b). presentation
a. Dialogue control b. Presentation
a. Arch model b. Waterfall model
a. graphical identification b. graphical user
a. menu networks b. grammar notations
(a). PAC model b. Seeheim model
a. PAC model b. Seeheim model
(c). MVC model d. Slinky model
25. It has more layers and distinguishes
lexical/physical like a ‘slinky’ spring different layers may be thicker (more
important) in different systems.
a. PAC model b. Seeheim
model
c. MVC model (d).
Slinky model
26.
It is a kind of feedback like a movement of
mouse.
(a). lexical b. syntactic
c. Semantic d. logical
27. It is a kind of feedback like a menu
highlights.
a. Lexical (b).
syntactic
c. Semantic d. logical
28. It is a kind of feedback like a sum of
numbers changes.
a. Lexical b. syntactic
(c). semantic d. logical
29. It has independent of application
semantics or presentation.
a. internal control b. presentation
control
(c). external control d. input control
30. It has read-evaluation loop for a
system software.
(a). internal control b. presentation
control
c. external control d. input control
a. PAC model b. Seeheim model
a. Lexical (b). syntactic
a. Lexical b. syntactic
a. internal control b. presentation control


Comments
Post a Comment