See Heim

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

USER USER

lexical

syntactic

semantic

Presentation

Dialogue Control

Functionalit y (application interface)

APPLICATION

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.

5