A Component- and Message-Based Architectural Style for GUI Software Research Paper Richard N. Taylor Nenad Medvidovic Kenneth M. Anderson E. James Whitehead Jr. Jason E. Robbins Department of Information and Computer Science University of California, Irvine Irvine, California 92717-3425 {taylor,neno,kanderso,ejw,jrobbins}@ics.uci.edu Abstract ically made use of two primary run-time architectures: the While a large fraction of application system code is client-server style (as exemplified by X windows) and the devoted to user interface (UI) functions, support for reuse in call-back model, a control model in which application func- this domain has largely been confined to creation of UI tool- tions are invoked under the control of the user interface. kits (“widgets”). We present a novel architectural style Also well known is the model-view-controller (MVC) style directed at supporting larger grain reuse and flexible system [KP88], which is commonly exploited in Smalltalk applica- composition. Moreover, the style supports design of distrib- tions. The Arch style is more recent, and has an associated uted, concurrent, applications. A key aspect of the style is meta-model [Wor92]. that components are not built with any dependencies on This paper presents a new architectural style. It is what typically would be considered lower-level components, designed to support the particular needs of applications that such as user interface toolkits. Indeed, all components are have a graphical user interface aspect, but the style clearly oblivious to the existence of any components to which notifi- has the potential for supporting other types of applications. cation messages are sent. Asynchronous notification mes- This style draws its key ideas from many sources, including sages and asynchronous request messages are the sole basis the styles mentioned above, as well as specific experience for inter-component communication. While our focus has with the Chiron-1 user interface system [TJ93]. In the fol- been on applications involving graphical user interfaces, lowing exposition, the style is referred to as the Chiron-2, or the style has the potential for broader applicability. Several C2, style. trial applications using the style are described1. A key motivating factor behind development of the C2 style is the emerging need, in the user interface world, for a 1.0 Introduction more component-based development economy. User inter- Software architectural styles are key design idioms face software frequently accounts for a very large fraction [PW92][GS93]. Unix’s pipe-and-filter style is more than of application software, yet reuse in the UI domain is typi- twenty years old; blackboard architectures have long been cally limited to toolkit (widget) code. The architectural style common in AI applications. User interface software has typ- presented supports a paradigm in which UI components, such as dialogs, structured graphics models (of various lev- els of abstraction), and constraint managers, can more 1. This material is based upon work sponsored by the Air Force Materiel Command, Rome Laboratory and the readily be reused. A variety of other goals are potentially Advanced Research Projects Agency under contract number supported as well. These goals include the ability to com- F30602-94-C-0218. The content of the information does not pose systems in which: components may be written in dif- necessarily reflect the position or policy of the Government and no official endorsement should be inferred. ferent programming languages, components may be running in a distributed, heterogeneous environment without shared address spaces, architectures may be changed dynamically, multiple users may be interacting with the system, multiple toolkits may be employed, multiple dialogs may be active (and described in different formalisms), multiple media types may be involved, and multiple user tasks (“pro- cesses”) supported. We have not yet demonstrated that all FIGURE 1. An audio-visual stack manipulation these goals are achievable or especially supported by this system. style. We have examined several key properties and built several diverse experimental systems, however. The focus Stack of this paper, therefore, is to present the style and describe Manipulator the evidence we have to date. We believe our preliminary Stack findings are encouraging and that the style has substantial ADT utility “as is.” Further studies will examine the degree to Connector which the style supports attainment of the various goals. The new style can be informally summarized as a net- Cafeteria Stack work of concurrent components hooked together by mes- Artist & Abstract Graphics sage routing devices. Central to the architectural style is a principle of limited visibility: a component within the hier- Connector archy can only be aware of components “above” it, i.e., components typically closer to the “application,” and thus Rendering Agent further from, e.g., the windowing system2. Components are and X Server totally unaware of the components—including toolkits— Connector which reside “beneath” them. All components have their own thread(s) of control and there is no assumption of a Sound shared address space. It is also important to recognize that Server this conceptual architecture is distinct from the implementa- tion architecture. There are many ways of realizing a given I/O Devices I/O Devices conceptual architecture, and this topic will be briefly dis- cussed later. Visual depiction of the stack is performed by the “art- A small example serves to illustrate several of these ist” that receives notification of operations on the stack and points. In Figure 1, we diagram a system in which a pro- creates an internal abstract graphics model of the depiction. gram alternately pushes and pops items from a stack; the The rendering agent monitors manipulation of this model system also displays the stack graphically, using the visual and ultimately creates the pictures on the workstation metaphor of a stack of plates in a cafeteria. The human user screen. To produce the audio effects, the sound server at the can “directly” manipulate the stack by dragging elements to bottom of the hierarchy monitors the notifications sent from and from it, using a mouse. As the user drags elements the artist and the graphics server; depending on the events around on the display, a scraping sound is played. Whenever detected, the various sounds are played. Performance is the stack is pushed, a sound of a spring being compressed is such that playing of the sound is very closely associated played; whenever the stack is popped, the sound of a plate with mouse movement; there is no perceptible lag. The art- breaking is played. ist and rendering agent are completely unaware of the activ- ities of the sound server; similarly, the stack manipulator is completely unaware that its stack object is being visualized. The paper is organized as follows. Section 2.0 presents the new architectural style. Section 3.0 presents a set of 2. It is sometimes convenient to consider an application sys- sample applications that have been built to investigate vari- tem as being subdivided into two parts: one part being those ous aspects of the style. Section 4.0 discusses related work. aspects of the system which do not directly perform any user Discussion of a large list of open issues and a conclusion interface functions (the “application”), and the other part being those aspects concerned with interacting with the user round out the paper. (the “user interface”). Such a distinction is rather arbitrary, and can usually be read as “those parts of an application sys- 2.0 A UI architectural style supporting tem constructed according to our architectural style and prin- heterogeneity, concurrency, and ciples, and those parts which are not” Notions of above and below are used in this paper to sup- composition port an intuitive understanding of the architectural style. In In this section we present the architectural style and its this discussion the application code is (arbitrarily) regarded as being at the top while user interface toolkits, windowing sys- rationale. Key elements of the C2 architectural style are tems, and physical devices are at the bottom. (The human user components and connectors. A configuration of a system of is thus at the very bottom, interacting with the physical connectors and components is an architecture. There is also devices of speaker, keyboard, mouse, microphone, and so forth.) While this vertical orientation may be helpful in devel- a set of principles governing how the components and con- oping understanding, it should be noted that the precise uses nectors may be legally composed. We attempt to provide a of top and bottom, provided below, do not rest on assumption rationale for the desired properties of the components and of this particular vertical orientation. connectors, as well as the choice of principles. Due to space nal semantic domain and that of the connector above it. constraints, our presentation is largely informal. The architectural style consists of components and con- FIGURE 2. The Internal Architecture of a C2 nectors. Components and connectors both have a defined Component. top and bottom. The top of a component may be connected to the bottom of a single connector. The bottom of a compo- nent may be connected to the top of a single connector. Domain There is no bound on the number of components or connec- Translator Wrapper tors that may be attached to a single connector. Components can only communicate via connectors; direct communica- tion is disallowed. When two connectors are attached to Internal Dialog each other, it must be from the bottom of one to the top of & Object the other. Both components and connectors have semanti- Constraints cally rich interfaces. Components communicate by passing messages: notifi- cations travel down an architecture and requests up. Con- nectors are responsible for the routing and potential multi- cast of the messages.