Object-Oriented User Interface

I use the term "Object-Oriented User Interface" to describe an interface paradigm where the user first selects an object and then chooses an action from a context menu or via direct manipulation. The Macintosh user interface is an example of such an interaction paradigm: The user first selects a document and then decides what to do with it. She can either manipulate it via double click or drag it over the printer icon to print it or do other fancy things. The term "object-oriented" here refers to the interaction style rather than to the implementation technique - though it is usually a good idea to use object-oriented design and programming to build this kind of interface. For more details refer to [Col95] for example.

Form-Based User Interface

The term "Form-Based User Interface" denotes interfaces where the user starts with selecting a certain business process. The application then guides the user though this process with a series of forms. Most user interfaces on mainframe systems work this way. See [CoK97] for further discussion.

Object-Oriented Systems

I use this term to refer to applications that have been designed and implemented using object-oriented techniques. In the context of this paper the most important feature of these systems is a set of objects with their own life-cycles that interact to perform the functionality. Hence single use cases or transactions are not relevant to the architecture.

Transaction-Oriented Systems

In these systems the architecture usually is organized around transactions. Every transaction invokes a different program that manipulates a database. Most programs using transaction processors, such as CICS, are build that way. See [GrR93] for further discussion.

Thumbnail

Driving a user interfaces is complex and more prone to changes than the domain usually is,...therefore separate domain level issues from user interface software and encapsulate the user interface in a separate layer.

Context

When you design the architecture of a complex business system you usually have to start with the coarsest architectural decisions: What are the large chunks I have to design? In former days technological considerations drove the first decision, ending up in large applications with a technical interior structure. Those were the days of 'The Standard Architecture' for certain families of systems, and the days of 100 people working on one project. Today many architects first use domain level aspects to chop the system into smaller parts they call business objects, before they care for technical considerations.

No matter which of these two ways you go, sooner or later you have to consider technological aspects to further subdivide your system. One of these technological aspects is presentation of the system towards the users. That is where this pattern steps in. It applies to object-oriented systems as well as to transaction-oriented designs, to systems using the tool-material metaphor [Rie97] as well as to form-based applications [CoK97]. So...

Problem

...how do you place user interface issues of large systems into the overall architecture?

There are several things you have to take care of:

Forces

The user interface presents the same functional requirements as your analysis model,...
...but it has different non-functional requirements that lead to a lot of details the user does not want to be molested with.

A standard technique to fulfill different non-functional requirements is to separate the different concerns into subsystems on their own,...
...but a user interface needs a lot of domain level information to meet high ergonomic standards, so separated subsystems would be coupled closely.

Modern development environments offer convenient ways to access the user interface in a particular way,...
... but complex systems often need several different user interfaces to satisfy different needs and these interfaces may need different designs to meet their respective requirements.

Finally, the domain level software may contain abstractions the users do not understand,...
...but the domain level structure always shows through to the user interface.

Solution

Therefore separate user interface issues from domain level aspects and put them into two different subsystems. Make sure the domain level subsystem has no notion of the user interface part, thus forming a layered architecture.

It is important to note the layered aspect of the solution: The user interface layer is allowed to call the domain layer but not vice versa. When a 'callback' is inevitable, we need special mechanisms to ensure the layered approach. Access Domain Layer addresses these issues.

Consequences

With this architecture it is easy to optimize the two layers for different non-functional requirements,...
...still you will have to take care not to implement functional requirements twice.

Both layers may now have a totally different design. For instance, the user interface layer may use a Widget Model with the various views as the backbone of the design while the domain layer is based on the analysis model. With this design changes of the layout result in local changes of the user interface layer while changes of performance requirements concentrate on the domain layer. However, a new topic comes up you have to take care for: There is a high risk to implement functional requirements in both layers redundantly. For instance, consider an OK button that has to be disabled as long as the dialog box does not contain consistent data with respect to some business rules. It is tempting to put this rule into the dialog box class. On the other hand you also need the criterion somewhere in your domain logic. Now the mess happens as soon as the rule changes: You have to change on two places or even more. To fight this risk, the domain layer usually provides meta information about the domain. Availability Method and Domain Level Type deal with these problems.

The layered design provides separation of concerns,...
...still you have to take precautions to keep the coupling between both layers manageable.

Read-only context information about objects the user currently works with,

Rules for formatting,

Information whether a particular action is allowed in the current context,

Information on status and progress of the domain layer,

Triggering (trans)actions, and

Error information

Known Uses

Nearly all popular user interface architectures use this pattern. I will pick three examples:

1. The Seeheim user interface architecture features an application kernel as domain layer and a user interface layer. It subdivides the latter in two more layers, called the presentation layer and the dialog control layer. Because this architecture has its roots in transaction oriented systems, there are no callback mechanisms from the application kernel back to the user interface.
2. Perhaps the most popular example is the Model-View-Controller architecture [BMR+96]. The View and the Controller classes form the user interface layer while the Model classes form the domain layer. Views and Controllers are allowed to send specific messages to Models but not vice versa. An Observer serves to provide a callback mechanism from the Model to the Views.
3. IBM Visual Age for Smalltalk lets the programmer assemble the application from Parts. There are Visual Parts, such as menus, tree views, and windows, and there are Nonvisual Parts that usually wrap ordinary Smalltalk classes. Used in a disciplined way, the Visual Parts correspond to the user interface layer while the Nonvisual Parts correspond to the domain layer.

See Also

[BMR+96] discusses layered architectures in depth.

Thumbnail

Presenting information on the screen and processing user actions are two different complex tasks, ... therefore separate the transformation of domain information to the screen from the transformation of user actions to domain layer calls.

Context

After you have decided to use a User Interface Layer, the work has just begun. You have to define the detailed structure of the user interface. Often input and output are clearly separable concerns. Especially when you are using direct manipulation and the Tool-Material metaphor, displaying the information and processing manipulations can both become quite complex. So...

Problem

...how do you assign input and output processing to subsystems?

To decide for a solution you have to take several forces into account:

Forces

Visualization and manipulation are complex tasks,...
...but they are closely coupled.

Visualization and manipulation address different domain layer features,...
...but usually work on the same domain level objects.

Your design may suggest a straight forward separation,...
...but often the framework already dictates a certain separation

Solution

Therefore, separate user interface processing into two subparts: A View displays the data on the screen and a Controller handles user input. Let the current Selection define the context both objects work upon. Usually every single view has its own controller.

Consequences

The design successfully separates the different tasks ,...
...still both parts are closely coupled

The Controllers mainly address the setter methods of the domain level objects while the views usually use the getters and navigate though the network of objects,...
...still both objects tend to work with the same domain level instance, so you have to provide Context Support for the context common to both - an extra effort.

In a naive approach (and many 4GLs) the controllers just set the attributes of the domain level object. In a more sophisticated system, manipulations are not that easy. Before the user chooses any action you have to set up menus and to enable menu items and buttons depending on domain level states and the current selection, and you may have to restrict parameters. After the user has submitted an action, you may have to retrieve additional parameters, check them for validity, save undo information, and so on. As you might already guess, this often is too much for a single class. Hence the Controller often uses Command, Availability Methods, and Domain Level Type.
Frequently The task of the View is more complex than just initializing a label with a string retrieved with a getter method: The result has to be formatted and the presentation may vary depending on the concrete subclass of the object retrieved. For instance, consider a view for a circuit diagram: The symbol depends on whether you are showing a transistor or a capacity. Domain Level Type help to do the formatting.
As a bottomline, Views and Controllers address different parts of the domain level object's protocol. However, they still address the same domain object, usually the one the user has selected. There are two possibilities: The selection can be a direct selection in a navigation widget, such as the tree of postings in the example above. In a form-based user interface, the user often has to select the object using some form of query, such as match code search. In general there is an additional context that defines on which objects the View and the Controller works. Therefore you will have additional effort for Context Support.

In any case, be sure your architecture conforms to the separation.

It is usually very unwise to implement a design which does not comply to the architecture your framework supports. If you think that Separate Transformation is the right choice for your application but your framework supports a Widget Model you can either use another framework or change your user interface. Do not try to build a skyscraper on the foundations of a cathedral. Only rather low-level frameworks, such as AWT, permit both architectures.

Known Uses

1. Model View Controller [BMR+96] is the classic example of this pattern. The Model is the domain level object and the context at the same time while Views and Controllers exactly conform to the pattern.
2. http, the Hyper Text Transfer Protocol also uses this pattern in a slightly different variant. Consider the html pages as the Views, while the CGI scripts are the controllers. The arguments of the script contain the context. Whether you have a clearly defined domain level object depends on the purpose of the page.
   More advanced pages use Java applets to perform complex user interfaces. Because the AWT supports Widget Models, this usually results in a mixed architecture. However, AWT is rather low-level, so it is still possible to use Separate Transformation using AWT.
3. CICS also offers two completely different mechanisms for visualization and manipulation: Transaction codes determine what program you start - and therefore what manipulation you do. Maps encapsulate output to the terminals. Because CICS is transaction-oriented rather than object-oriented, it does not maintain any context. There are several ways to provide Context Support, I will discuss below.
4. Dirk Riehle describes this pattern as "Trennung von Interaktion und Funktion" (Split between interaction and function) in the context of the tool material metaphor [Rie97]

Related Patterns

Widget Model is an Alternative architectural strategy that is useful if the coupling between View and Controller becomes too tight. In fact, user interface architectures often use Widget Model on an architectural level while they use Separate Transformation on a lower level. If manipulation becomes too complex you also find the opposite order.

Thumbnail

Every widget on the screen has its own data and functionality ,... therefore let a set of objects of the user interface model the widgets on the screen.

Context

Most graphic user interfaces consist of a hierarchy of widgets: Windows contain subwindows, which contain areas, which contain elementary widgets, and so on. Most widgets display some information and do some manipulation. Often every elementary widget presents a certain domain level object or an attribute of it. Aggregating widgets often present aggregations of domain level objects. So...

Problem

...how do you model the user interface if the structure of your widgets is closely coupled to your domain model structure.

To decide for a solution you have to take several forces into account:

Forces

You want the architecture to define as much of the structure as possible,...
...but it is usually hard to find a simple architecture that covers all topics.

You want classes to be coupled loosely,...
...but you would also like them to have as few responsibilities as possible.

You want to reuse classes directly if you encounter a similar widget,...
...but sometimes you achieve the best reuse by exploiting meta information.

Solution

Therefore, have a single Widget class for every item on the user interface. The Widget class is linked to a complete domain level object or a single attribute of it. It handles both presentation and manipulation of the domain level object. The Widget objects form a hierarchy that corresponds to the item hierarchy on the user interface with the root object modeling the main window. Every node in this Widget hierarchy controls the lifecycle of its children. The figure below demonstrates this design for the news reader.

Consequences

This architecture smoothly defines a fine grained structure of the user interface,...
...still there are important issues left open.

If you can draw a picture of your user interface, this pattern defines most of the structure of its software: Transform the picture into a hierarchy of items, such as windows, subwindows and so on. This is the instance tree you have while the window is active. However, there are still some topics left: Most applications have a context that spans the windows. Consider the Clipboard as an example. There is no visible item you can attach this clipboard to, so you need additional classes to provide Context Support. Another issue left open is an overall control that cares for initialization before you open the first window and clean-up after you have closed the last window. A separate Application class addresses this topic.

You only have to change a single class if you change the domain object,...
...still this class has a bunch of complex responsibilities.

With an object-oriented user interface the widget model also means to reflect domain objects. A widget usually presents a single domain object or parts of it. Because the widget is responsible for all interaction with this object, the knowledge about it is quite concentrated on this class. However, this may lead to complex classes. To make things even worse, a widget not only has to care for both directions of domain object communication, but it also has to manage its children's lifecycles - including the layout. With a complex widget this usually leads to classes that suffer from elephantiasis. Hence, complex widgets often use Separate Transformation as micro architecture. Another measure is to use Automatic Layout to support layout management. Other patterns that help to break up the classes are Domain Layer Access, Command, Availability Method, and Domain Level Type.

A Widget Model leads to a natural reuse of widgets,...
...still it is not suited very well for variants.

It is hard to generate widgets from meta information about the domain object you have to present

With some form-based interfaces it is sufficient to know the objects and attributes you want to include in a form to generate it. You give the form class a property list, run an Automatic Layout and display it. You can generate a large share of "insert, update, delete" forms this way. It is important to note that the manipulation part here is nearly stable, only the data presented varies. This approach also needs highly standardized protocols for every form. A Widget Model does not encourage both requirements. For this approach Separate Transformation is the better architecture.

Known Uses

1. Application Document View is the most popular example of this approach. The Macintosh first used this architecture and most window libraries have adopted it. While Application and Document manage the context, the Views are the roots of the opened Windows. Every View consists of subviews, consisting of widgets, and so on.
2. Presentation Abstraction Control [BMR+96] extends this concept into the domain level with a hierarchy of collaborating "Agents".
3. AWT, Java's GUI library, assembles the user interface of "Components" which manage presentation as well as manipulation of the data they display.
4. Visual Basic is the most popular non-OO environment that uses this architecture: A "Form" recursively consists of "Subforms" which finally contain "Controls". All of them have certain events that are called when the user chooses to do something. The lack of mechanisms to implement further micro-architectures for every form is one of the main problems with Visual Basic for large projects.

Related Patterns

Separate Transformation is an alternative if you can separate input and output clearly. Often both patterns are combined, forming a hierarchy of View-Controller pairs.
Chain of Responsibility [GHJ+94] is the classic design pattern to manage the communication between widgets.
Mediator [GHJ+94] is a common way to reduce coupling between several subwidgets.

Thumbnail

The interface to the domain layer sometimes is quite sophisticated,... therefore designate a special set of objects to access the domain kernel.

Context

If you have decided to use a User Interface Layer, the structure of this layer not only has to tell you how to construct the classes for user interface control, but also has to contribute to the functional requirements of the system. Fancy windows and forms help the user to access the system but they do not represent any value in itself. So...

Problem

...how do you access domain layer functionality from the user interface software?

Solution

Introduce a set of methods and classes to access the domain layer. Be sure you consider the following topics when you design these classes:

• Commands to domain objects. The Command pattern addresses this topic.
• Handling errors during the execution of commands. Command also is a good place to care for errors. Error Handler [Ren96] is suitable for a more sophisticated error handling.
• Retrieving information about the availability of commands. You can use Availability Methods as a unified protocol.
• Retrieving information about the possible values of entry fields. Domain Data Types discuss a solution for this problem.

Thumbnail

Sometimes you want to enable the user to display several views of the same domain object at once but you want to avoid to call the user interface from the domain object if the object changes,... therefore let the views register at the domain object, which sends a change notification to all registered objects whenever it changes.

See Also

[GHJ+94]

Thumbnail

Issuing a command to a domain level object often is related with additional responsibilities, such as determining availability of the manipulation, retrieving additional parameters, error handling, undoing, and setting the boundaries of transactions,... therefore model the commands as separate classes with these responsibilities.

See Also

[GHJ+94]

Thumbnail

In most user interfaces you have to check whether a certain action is legal in the current context without actually performing the action,... therefore add an Availability Method for every manipulation method to the domain object, taking the same parameters as the manipulation method but answering a Boolean without any change of the domain layer.

Thumbnail

Formatting and legal values of entry fields are often determined by the nature of the data to be displayed or entered,... therefore use separate classes with a common protocol for your domain level types that have these issues as their sole responsibility.

Also Known As

Whole Value [Cun95]

Thumbnail

Especially in a transaction based environment the system does not store context information you need to support the user optimally,... therefore take care to support a context for every user.

Context

User interfaces usually have to maintain some context while the user stares on the screen and scratches his head. You have to store information about the displayed objects, the current selection and the state of dialogs. So...

Problem

...where do you store this information?

Solution

Introduce mechanisms that store the context. The mechanisms depend on your distribution architecture, the available bandwidth between client and server, and the scalability your system has to provide. For single-user systems and fat client architectures Application, Document, and Selections help to deal with specific context information. For thin-client architectures you can either use Session Memory to optimize bandwidth on the expense of scalability or Cookies to optimize for scalability on the expense of bandwidth. For highly sophisticated systems you can combine both to enable fine-tuning.

Thumbnail

In a window environment you need a place to store general information you cannot assign to a window,... therefore have an Application object as a Singleton [GHJ+94], caring for initializing, cleaning up, and storing general information.

Thumbnail

In most window environments the user is able to open several views on the same set of domain objects,... therefore assign each window to a Document which manages the root of the presented set of domain objects.

Thumbnail

Because the current selection controls most elements of a user interface, it is hard to assign it to any other element,... therefore introduce a selection class that contains the references to the domain objects currently selected. Send all manipulative actions to domain objects using these references.

Thumbnail

In a transaction based environment the system does not maintain context information between two transactions, but often dialogs span several transactions,... therefore allocate a session memory for every client on the host that stores the context.

Thumbnail

In client/server environments with a very large or unpredictable number of clients the resources of the server may not suffice to store the context information of every client,... therefore send the status as data to the client and let the client store it. These little chunks of context information are called Cookies.

Thumbnail

Form-Based user interfaces usually feature a complex state model with many common events and a high change rate on the states while the single steps of a dialog are quite generic,... therefore introduce a centralized dialog control to maintain the state.

Thumbnail

The mutual placement of widgets in forms is an awkward work if you have a lot of forms, but it follows computable rules,... therefore implement these rules in an layout component rather than drawing each form by hand.