1 of 16A Component- and Message-Based Architectural Style for GUI SoftwareRichard N. Taylor, Nenad Medvidovic,Kenneth M. Anderson, E. James Whitehead Jr., Jason E. Robbins, Kari A. Nies,Peyman Oreizy and Deborah L. DubrowAbstract -- While a large fraction of application code is devoted tographical user interface (GUI) functions, support for reuse in thisdomain has largely been confined to the creation of GUI toolkits(“widgets”). We present a novel architectural style directed at sup-porting larger grain reuse and flexible system composition. More-over, the style supports design of distributed, concurrentapplications. Asynchronous notification messages and asynchronousrequest messages are the sole basis for inter-component communica-tion. A key aspect of the style is that components are not built withany dependencies on what typically would be considered lower-levelcomponents, such as user interface toolkits. Indeed, all componentsare oblivious to the existence of any components to which notificationmessages are sent. While our focus has been on applications involv-ing graphical user interfaces, the style has the potential for broaderapplicability. Several trial applications using the style are described.1Index Terms -- architectural styles, message-based architectures,graphical user interfaces (GUIs), heterogeneity, concurrency.I. INTRODUCTIONSoftware architectural styles are key design idioms [8, 24].UNIX’s pipe-and-filter style is more than twenty years old; black-board architectures have long been common in AI applications.User interface software has typically made use of two primaryruntime architectures: the client-server style (as exemplified by Xwindows) and the call-back model, a control model in whichapplication functions are invoked under the control of the userinterface. Also well known is the model-view-controller (MVC)style [15], which is commonly exploited in Smalltalk applica-tions. The Arch style is more recent, and has an associated meta-model [38].This paper presents a new architectural style. It is designed tosupport the particular needs of applications that have a graphicaluser interface aspect, but the style clearly has the potential forsupporting other types of applications. This style draws its keyideas from many sources, including the styles mentioned above,as well as specific experience with the Chiron-1 user interfacedevelopment system [14, 34]. In the following exposition, thestyle is referred to as the Chiron-2, or C2, style.A key motivating factor behind development of the C2 style isthe emerging need, in the user interface community, for a morecomponent-based development economy [37]. User interfacesoftware frequently accounts for a very large fraction of applica-tion software, yet reuse in the UI domain is typically limited totoolkit (widget) code. The architectural style presented supports aparadigm in which UI components, such as dialogs, structuredgraphics models of various levels of abstraction, and constraintmanagers, can more readily be reused. A variety of other goalsare potentially supported as well. These goals include the abilityto compose systems in which: components may be written in dif-ferent programming languages, components may be running con-currently in a distributed, heterogeneous environment withoutshared address spaces, architectures may be changed at runtime,multiple users may be interacting with the system, multiple tool-kits may be employed, multiple dialogs may be active anddescribed in different formalisms, and multiple media types maybe involved. We have not yet demonstrated that all these goals areachievable or especially supported by this style. We have exam-ined several key properties and built several diverse experimentalsystems, however. The focus of this paper, therefore, is to presentthe style and describe the evidence we have to date. We believeour preliminary findings are encouraging and that the style hassubstantial utility “as is.”The new style can be informally summarized as a network ofconcurrent components hooked together by message routingdevices. Central to the architectural style is a principle of limitedvisibility: a component within the hierarchy can only be aware ofcomponents “above” it and completely unaware of componentswhich reside “beneath” it. Notions of above and below are used inthis paper to support an intuitive understanding of the architec-tural style. As is typical with virtual machine diagrams found inoperating systems textbooks, in this discussion the applicationcode2 is arbitrarily regarded as being at the top while user inter-face toolkits, windowing systems, and physical devices are at thebottom. The human user is thus at the very bottom, interactingwith the physical devices of keyboard, mouse, microphone, andso forth.31. This material is based upon work sponsored by the Air Force Materiel Com-mand, Rome Laboratory, and the Advanced Research Projects Agency under con-tract number F30602-94-C-0218. The content of the information does notnecessarily reflect the position or policy of the Government and no officialendorsement should be inferred.2. It is sometimes convenient to consider an application system as being subdi-vided into two parts: one part are those aspects of the system which do not directlyperform any user interface functions (the “application”), and the other part arethose aspects concerned with interacting with the user (the “user interface”). Sucha distinction is rather arbitrary, and can usually be read as “those parts of an appli-cation system not constructed according to our architectural style and principles,and those parts which are.”IEEE Transactions on Software Engineering, vol. 22, no. 6, pages 390-406 (June 1996).2 of 16All components have their own thread(s) of control and thereis no assumption of a shared address space. At minimum, thismeans that components may not assume that they can directlyinvoke other component’s operations or have direct access toother components’ data. It is important to recognize that this con-ceptual architecture is distinct from the implementation architec-ture. There are many ways of realizing a given conceptualarchitecture, and this topic will be further discussed inSection III.E.A small example serves to illustrate several of these points. InFig. 1, we diagram a system in which a program alternatelypushes and pops items from a stack; the system also displays thestack graphically, using the visual
View Full Document
Unlocking...