0% found this document useful (0 votes)
17 views

Module5 Implementation Support

This document discusses windowing systems and programming tools for interactive systems. It describes the key elements of a windowing system interface and benefits. It also covers client-server architecture, toolkits, user interface management systems, and different approaches for modeling dialogs between applications and presentations.

Uploaded by

202202214
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views

Module5 Implementation Support

This document discusses windowing systems and programming tools for interactive systems. It describes the key elements of a windowing system interface and benefits. It also covers client-server architecture, toolkits, user interface management systems, and different approaches for modeling dialogs between applications and presentations.

Uploaded by

202202214
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 26

Module:5

Design Process:
Implementation
Support

1
WINDOWING SYSTEM:
• Windowing system is a graphical user interface (GUI)
that allows multiple software applications or documents
to be displayed simultaneously on a single screen.

• Windowing systems are an essential component of


modern operating systems, allowing users to work with
multiple applications at once in a multitasking
environment.

• Windowing system provides a convenient way to switch


between different tasks and to organize information
visually.
WINDOWING SYSTEM:
WIMP interface is characterized by four key graphical
elements:

1. Windows: A window is a rectangular area on the screen


that displays the contents of an application, such as a
word processor application or a web browser. It can
contain text, icons, images, and graphics.
WINDOWING SYSTEM:
WIMP interface is characterized by four key graphical
elements:

2. Icons: An icon is a small graphical symbol that represents


an application, a file, a folder, or a device. Icons are typically
displayed on the desktop or in a file manager, and users can
click an icon to launch an application or open a file or folder.
WINDOWING SYSTEM:
WIMP interface is characterized by four key graphical
elements:

3. Menus: A menu is a list of commands or options that are


displayed on the screen when a user clicks on a menu bar or
a context menu. Menus are used to access an application’s
various features and settings, such as File, Edit, View, and
Help.
WINDOWING SYSTEM:
WIMP interface is characterized by four key graphical
elements:

4. Pointers: A pointer is a graphical symbol, such as an


arrow or a hand, used to interact with the interface. Users
can move the pointer around the screen using a mouse or a
touchpad, and they can click, double-click, right-click, and
drag to perform various actions, such as selecting text,
opening a file, or resizing a window.
BENEFITS WINDOWING SYSTEM:
• Optimize the utilization of display area.

• Use multiple sources simultaneously to accomplish a task, such as


opening multiple windows at a time.

• The windows provide visual and textual information to facilitate


various interactions. For example, the icons on the desktop have
pictures and their name under them.

• Protect users from the complexities of command languages by


enabling specification through pointing and selecting, since we do not
need to use complex commands or programming languages to carry
out a task.

• Establish a consistent interface across numerous applications to


enhance the learning curve for new users.
ELEMENTS OF WINDOWING SYSTEM:

1. Device Independence
1.1 programming the abstract terminal device drivers.
1.2 image models for output and (partially) input

2. Resource Sharing
2.1 achieving simultaneity of user tasks
2.2 window system supports independent processes
2.3 isolation of individual applications
ROLES OF WINDOWING:
CLIENT SERVER ARCHITECTURE:
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
X Window System Architecture:
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.
Programming the Application:
The read–evaluate loop paradigm
The application has complete
control over the processing of
events that it receives.
Programming the Application:
The read–evaluate loop paradigm
The downside is that the programmer must
execute this control over every possible event
that the client will receive, which could prove a
very cumbersome task.
Programming the Application:
The notification-based
Control flow is centralized in the
notifier, which relieves the
application program of much of
the tedium of processing every
possible event passed to it by
the window system.
Using Toolkits
A toolkit provides the programmer with a set of ready-made
interaction objects – alternatively called interaction
techniques, gadgets or widgets – which she can use to
create her application programs.
Using Toolkits
A toolkit provides the programmer with a set of ready-made
interaction objects – alternatively called interaction
techniques, gadgets or widgets – which she can use to
create her application programs.

Toolkits exist for all windowing


environments:
• OSF/Motif and XView for the X
Window system
• Macintosh Toolbox
• Software Development Toolkit for
Microsoft Windows
User Interface Management Systems/UIMS
• A toolkit provides the programmer with a set of ready-
made interaction objects – alternatively called interaction
techniques, gadgets or widgets – which she can use to
create her application programs.

• A set of programming and design techniques which are


supposed to add another level of services for interactive
system design beyond the toolkit level.
User Interface Management Systems/UIMS
The main concerns of a UIMS, for our purposes, are:

• A conceptual architecture for the structure of an interactive


system which concentrates on a separation between
application semantics and presentation;

• Techniques for implementing a separated application and


presentation whilst preserving the intended connection
between them;

• Support techniques for managing, implementing and


evaluating a run-time interactive environment
UIMS as a conceptual architecture
• Portability To allow the same application to be used on
different systems it is best to consider its development
separate from its device-dependent interface.

• Reusability Separation increases the likelihood that


components can be reused in order to cut development
costs.

• Multiple interfaces: To enhance the interactive flexibility of


an application, several different interfaces can be developed
to access the same functionality.

• Customization: The user interface can be customized by


both the designer and the user to increase its effectiveness
without having to alter the underlying application.
Logical Components of UIMS:
• Presentation: The component responsible for the appearance of the
interface, including what output and input is available to the user.

• Dialog control: The component which regulates the communication


between the presentation and the application.

• Application interface: The view of the application semantics that is


provided as the interface.
Dialog Modelling of UIMS:
• Menu networks: The communication between application and
presentation is modeled as a network of menus and submenus. To
control the dialog, the programmer must simply encode the levels of
menus and the connections between one menu and the next submenu
or an action. The menu is used to embody all possible user inputs at
any one point in time.

• Grammar notations: The dialog between application and


presentation can be treated as a grammar of actions and responses,
and, therefore, described by means of a formal context-free grammar
notation, such as BNF (Backus–Naur form). These are good for
describing command-based interfaces, but are not so good for more
graphically-based interaction techniques.
Dialog Modelling of UIMS:
• State transition diagrams: State transition diagrams can be used as
a graphical means of expressing dialog

• Event languages : Event languages are similar to grammar notations,


except that they can be modified to express directionality and support
some semantic feedback. Event languages are good for describing
localized input–output behavior in terms of production rules. A
production rule is activated when input is received and it results in
some output responses.

• Declarative languages : All of the above techniques (except for


menu networks) are poor for describing the correspondence between
application and presentation because they are unable to describe
effectively how information flows between the two. They only view the
dialog as a sequence of events that occur between two
communicating partners. A declarative approach concentrates more
on describing how presentation and application are related.
Dialog Modelling of UIMS:
• Constraints: Constraints systems are a special subset of declarative
languages. Constraints can be used to make explicit the connection
between independent information of the presentation and the
application.

• Graphical specification: These techniques allow the dialog


specification to be programmed graphically in terms of the
presentation language itself. This technique can be referred to as
programming by demonstration since the programmer is building up
the interaction dialog directly in terms of the actual graphical
interaction objects that the user will see, instead of indirectly by means
of some textual specification language that must still be linked with the
presentation objects.
SUMMARY:
• 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.
SUMMARY:
• Interaction toolkits 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.
END OF MODULE

26

You might also like