Goals of User Interface Architecture

• Separation of concerns
• Multiplicity of presentation options
• Coordination for interaction

Main categories of User Interface architecture are

• Compiler mentality
Lexical/Syntactic/Semantic
Seeheim, ARCH
• Object mentality
Interface as collection of objects
PAC, MVC

Seeheim
Seeheim metamodel and its successor, the Arch metamodel were proposed to foster the
principle of separation between interactive code (i.e., dialogue control) and non
interactive code (i.e.,functional core) of computer-based applications. These models
influenced early research efforts in the area of User Interface Management Systems
(UIMSs) .
There have also been alternative, implementation oriented proposals, some of which
have resulted from mainstream tools. For instance, the Model View
Controller (MVC)

The seeheim model

lexical syntactic semantic

Functionalit
Dialogue y
USER
USER Presentation APPLICATION
Control (application
interface)

switch

Model-view-controller (MVC)
It is a software architecture that separates an application's data model, user interface,
and control logic into three distinct components so that modifications to one component
can be made with minimal impact to the others.
MVC is often thought of as a software design pattern. However, MVC encompasses more
of the architecture of an application than is typical for a design pattern.

Constructing an application using an MVC architecture involves defining three classes

of modules.

• Model: The domain-specific representation of the information on which the

application operates. The model is another name for the domain layer. Domain logic
adds meaning to raw data (e.g. calculating if today is the user's birthday, or the
totals, taxes and shipping charges for shopping cart items).

1
• View: Renders the model into a form suitable for interaction, typically a user
interface element. MVC is often seen in web applications, where the view is the
HTML page and the code which gathers dynamic data for the page.
• Controller: Responds to events, typically user actions, and invokes changes on the
model and perhaps the view.
• Many applications use a persistent storage mechanism (such as a database) to store
data. MVC does not specifically mention this data access layer, because it is
understood to be underneath or encapsulated by the Model.

The control flow generally works as follows:

• The user interacts with the user interface in some way (e.g., user presses a button)
• A controller handles the input event from the user interface, often via a registered
handler or callback.
• The controller accesses the model, possibly updating it in a way appropriate to the
user's action (e.g., controller updates user's shopping cart). Complex controllers are
often structured using the command pattern to encapsulate actions and simplify
extension.
• A view uses the model to generate an appropriate user interface (e.g., view produces
a screen listing the shopping cart contents). The view gets its own data from the
model. The model should have no direct knowledge of the view. However, the
observer pattern can be used to provide some indirection between model and view,
allowing the model to notify interested parties of a change. A view object can register
itself with the model and listen for changes but the model itself remains unaware of
the view. The controller does not pass domain objects (the model) to the view
although it might issue a command telling the view to update itself.
• The user interface waits for further user interactions, which begins the cycle anew.

Advantages and disadvantages

Benefits

• Supports multiple views. Because the view is separated from the model and there is
no direct dependency from the model to the view, the user interface can display
multiple views of the same data at the same time. For example, multiple pages in a
Web application may use the same model objects. Another example is a Web
application that allows the user to change the appearance of the pages. These pages
display the same data from the shared model, but show it in a different way.
• Accommodates change. User interface requirements tend to change more rapidly
than business rules. Users may prefer different colors, fonts, screen layouts, and
levels of support for new devices such as cell phones or PDAs. Because the model
does not depend on the views, adding new types of views to the system generally
does not affect the model. As a result, the scope of change is confined to the view.
This pattern lays the foundation for further specializations of this pattern such as
Page Controller rand Front Controller.
• Complexity. The MVC pattern introduces new levels of indirection and therefore
increases the complexity of the solution slightly. It also increases the event-driven
nature of the user-interface code, which can become more difficult to debug.
• Cost of frequent updates. Decoupling the model from the view does not mean that
developers of the model can ignore the nature of the views. For example, if the
model undergoes frequent changes, it could flood the views with update requests.

2
 Some views, such as graphical displays, may take some time to render. As a result,
the view may fall behind update requests. Therefore, it is important to keep the view

in mind when coding the model. For example, the model could batch multiple updates
into a single notification to the view.

View instability vs. model stability

• If constructed correctly, models can enjoy a fair degree of stability (owing to the
stability of the domain model), whereas user interface code usually undergoes
frequent and sometimes dramatic change (typically because of usability
problems, the need to support growing classes of users, or simply the need to
keep the application looking "fresh"). Separating the view from the model makes
the model more robust, because the developer is less likely to "break" the model
while reworking the view.
• Attempting to join these two worlds in a hand coded method without
architecture is very common, and results in the model object being polluted with
knowledge of the interface, and vice-versa. This makes the code very inflexible
and difficult to maintain. For this reason (among others), many programming
shops develop the user interface design early in the process of design, and freeze
the interface early. Swing Features and Concepts

The Java Swing Arhictecture

The Java Development Kit (JDK) contains a library of classes useful to software
engineers – the Java Foundation Classes (JFC)
Part of the JFC is the Swing package.

• Swing Components and the Containment Hierarchy

This section shows you all the Swing components and tells you how, in general, to
combine them to create a GUI. Swing provides many standard GUI components such as
buttons, lists, menus, and text areas. It also includes containers such as windows and
tool bars.

• Layout Management
Containers use layout managers to determine the size and position of the components
they contain. Borders affect the layout of Swing GUIs by making Swing components
larger. You can also use invisible components to affect layout.

• Event Handling
Event handling is how programs respond to external events, such as the user pressing a
mouse button. Swing programs perform all their painting and event handling in the
event-dispatching thread.

• Painting
Painting means drawing the component on-screen. Although it's easy to customize a
component's painting, most programs don't do anything more complicated than
customizing a component's border.

• Threads and Swing

If you do something to a visible component that might affect or depend on its state, then
you need to do it from the event-dispatching thread. This isn't an issue for many simple
programs, which generally refer to components only in event-handling code. However,

3
other programs need to use the invoke Later method to execute component-related calls
in the event-dispatching thread.

Serpent
Serpent is a UIMS that supports the incremental development of the user interface
from prototyping through production and maintenance. It does this by providing an
interactive layout editor for prototyping, by integrating the layout editor with a dynamic
specification language for production and maintenance, and by having an open
architecture so that new user interface functionality can be added during the
maintenance phase.

The basic features of Serpent are simple enough for use during the prototyping phase,
yet sophisticated enough for use in developing the prototype into an operational system.
Serpent is designed to be extensible in the user interface toolkits that can be supported.
Hence, a system developed using Serpent can be migrated to new technologies without
time consuming and expensive re-engineering of the application portion.

Serpent consists of:

• A language designed for the specification of user interfaces.

• A language to define the interface between the application and Serpent.

• A transaction processing library.

• An interactive editor for the specification of dialogues and for the

• Construction and previewing of displays.

• Input/output (I/O) technologies.

Features found in serpent are

Serpent provides many features to address the requirements, development, and

maintenance phases of a project. For the requirements phase, Serpent provides a
language and an editor to define the user interface.
For the development phase, Serpent provides a set of tools that simplify the
development of the user interface. For the maintenance phase, Serpent allows
integration of new technologies as well as the ability to modify the user interface.
Specifically, Serpent:

• Provides generality in supporting a wide range of both applications and I/O

toolkits through its use of database-like schemas.
• Provides a set of tools that simplify the user interface implementation process.
• Encourages the separation of software systems into user interface and "core"
application portions, a separation which will decrease the cost of subsequent
modifications to the system.
• Supports rapid prototyping and incremental development of user interfaces.
• Facilitates the integration of new user interface toolkits into the user interface
portion of a system.
• Supports both synchronous and asynchronous communication. This allows
real-time applications to satisfy timing constraints without waiting for user
input.

4
Serpent Architecture is as follows
Presentation Layer
The presentation layer controls the end user interactions and generates low-level
feedback. The presentation layer consists of various I/O toolkits that have been
incorporated into Serpent. A standard interface is used that simplifies the addition of
new toolkits.
Each I/O toolkit defines a collection of interaction objects visible to the end user. The
interaction objects that exist at this level depend upon which I/O toolkits have been
integrated into Serpent at a particular installation. Currently, Serpent supports the X
Window System, Version 11, with the Athena Widget set and the OSF Motif Widget set.

Dialogue Layer
The dialogue layer specifies the user interface and provides the mapping between the
presentation and application layers.
The data that is passed between the application layer and the dialogue layer is referred
to as application shared data. The application shared data definition provides the
format of the data, while the application shared data represents the actual value of the
data.

The dialogue layer determines which information is currently available to the end user
and specifies the form that the presentation will take as previously defined by the
dialogue specifier (individual responsible for creating the dialogue). The dialogue layer
acts as a traffic manager for
communications between the application and I/O toolkits. The presentation layer
manages the presentation; the dialogue layer tells the presentation layer what to do. For
example, the presentation layer will display a button that the end user can select; the
dialogue layer will tell the presentation layer the position and the contents of the
button, and will respond when the button is selected.

Application Layer
The application layer performs those functions that are specific to the application. Since
the other two layers are designed to take care of all the user interface details, the
application should be written to be presentation-independent: there should be no
dependency upon a specific I/O toolkit. While the application developer should be
aware that there is an end user and should provide the end user with information, that
information should be presented in application terms.
The application layer is not part of the Serpent system. Serpent currently supports
applications developed in C or Ada.