The single-user architecture or basis of a multiuser architecture describes those aspects of the latter that implement single-user semantics. In this discussion, of course, we are concerned mainly with those aspects that influence/are influenced by collaboration semantics. We consider single-user architectures here because the design of the collaborative aspects is often dependent on the basis.
Strictly speaking, the basis is a view of a collaboration architecture that may not have an independent existence. In practice, however, collaboration architectures are designed by extending existing single-user architectures. A large variety of single-user architectures have been devised in the context of single-user user-interface software. We will focus here only on those that we know have formed the bases of existing collaboration architectures. Our architectural descriptions are a set of assumptions regarding the nature of a single-user architecture. Thus, they apply to a family of architectures rather than a specific architecture.
The most general architecture is one that makes no assumption about the nature or number of application layers. By making no assumptions about an application, we can cover arbitrary applications, but cannot reason about any of them. The architecture of these applications can be described as a single level of Figure 9.2 that contains arbitrary abstractions/ interactors.
It is possible to subclass this architecture in several ways depending on the assumptions we make about the kinds of user-interface layers used. Four main kinds of general layers have been identified so far: window, widget, view, and model [Mye95,KP88], which would have increasing levels in a layered architecture that includes them (Figure 9.4).
Figure 9.4: Common user interface layers.
An architecture that supports one of these levels does not necessarily have all the potential levels below it. For instance, a view layer may be implemented directly on top of the workstation without defining a widget layer. We can distinguish among these architectures by defining a layering degree, L, which gives the number of software layers in the architecture. For instance, Team Workstation [IO90] has a layering degree of 2, since it assumes workstation and application layers; XTV [AWJ94], Rapport [EAHL88], Shared X [GWY94], and MMConf [CF89] have layering degrees of 3, since they assume an additional window layer; GroupKit [RG96] has a layering degree of 4, since it assumes an additional widget layer; and Suite [DC92], Weasel [GU92], and Clock [GUN96] have a layering degree of 5, since they assume an additional view layer. The application layers in all cases may be further subdivided into other layers. The layering and other degrees we associate with a tool (infrastructure) give the minimum degrees of client applications that use the tool. As we shall see later, the layering degree of an architecture bounds its awareness, replication, concurrency, and distribution degrees.
It is possible to further specialize these architectures by classifying them according to the specific instances of the abstract layers used in their implementation. For instance, an early version of GroupKit was based on InterViews widgets [LVC89] while the current one is based on Tk widgets [Ous94]. However, we will not distinguish among these specific instances, since from the architectural point of view, these differences are not important.