Design Patterns in an Object-Oriented Framework for Hypermedia S. Carvalho, G. Rossi* and A. Garrido** Departamento de Informatica, Pontificia Universidade Católica R. M. de S. Vicente, 225 Rio de Janeiro, RJ 22453-900, Brazil Fax: +55-21-511 5645. Telephone: +55-21-529 9531 e-mail: [sergio,rossi]@inf.puc-rio.br * also LIFIA-UNLP, and CONICET, Argentina **LIFIA, Fac. de Ciencias Exactas. UNLP, Argentina E-mail:
[email protected]
Abstract In this paper we analyze design patterns generating the architecture of an object-oriented framework for hypermedia. We briefly discuss our problem: building a software substrate for seamlessly extending object-oriented applications with a hypermedia interface and navigational styles; we next present the outstanding components of an object-oriented framework providing the desired functionality. The framework structure is then analyzed, showing in which way well known object-oriented design patterns cooperate in the generation of a solid, extensible architecture, based on highly reusable components. Finally, we briefly show the way in which those patterns are implemented in two objectoriented languages, Smalltalk and TOOL, discussing how particular language features have slightly modified the architecture. 1 Introduction It is widely known that using the hypermedia metaphor for accessing an information base may allow viewing the system’s knowledge with a different perspective than that nowadays provided in conventional styles for building application interfaces [Malcolm91]. This fact is particularly evident in application areas where it is necessary to combine formal with informal knowledge, such as software engineering environments or decision support systems [Bigelow88], [IEEE92]. However, extending an application with hypermedia constructs is not easy; for example we may subsume the whole application's behavior into a hypermedia network, provide a navigational style for performing common tasks, or just include annotation facilities and/or access structures to information such as indexes and guided tours [Garzotto93]. A key problem in designing these "hybrid" applications is how to factor out the hypermedia structure from the application specific behavior. Solving this problem we can obtain software components that are more reusable, adaptable and easy to extend. In this paper we show how to achieve this objective by building an object-oriented framework for hypermedia. We analyze the architecture of this framework in terms of well-known object-oriented design patterns [Gamma94]. In this sense this paper is an interesting and real example on how design patterns lead to well-formed architectures. The structure of this paper is as follows: We first give a clear statement of our problem, using some examples, and analyze the rationale for building an object-oriented framework for hypermedia.
We next present the framework architecture as perceived by an external user (the application builder). The framework architecture is then presented in terms of design patterns and some of them are analyzed in detail. We briefly show the impact of the architecture on two different implementation environments, Smalltalk [Goldberg83] and TOOL [Carvalho93] and finally we discuss some further work in this area. 2 Incorporating hypermedia functionality in Object-Oriented applications As previously exposed, extending applications with navigation facilities may be fruitful, even in those applications that were not conceived as "hypermedia-based". These facilities are being used increasingly in commercial applications (Microsoft's Windows standard help system, Lotus selflearning guide, etc.). In all cases the underlying application "maintains" control, though giving the user the chance of exploring an information base, built as a stand-alone hypermedia application. Another different approach is that of "link-servers" like Microcosms [Hall93], allowing inter-application linking. In this paper, however, we are interested in a richer use of hypermedia: as a way of improving access to information resources available in a non-hypermedia object-oriented application, extracting and reflecting object’s data and interactions, as well as their behavior. We have been working in two different types of applications: Management Information Systems (MIS) [Schwabe95] and Computer-Aided Software Engineering (CASE) Environments [Amandi93], [Alvarez95]. In both cases it is evident that hypermedia-based navigation should be integrated with the application's behavior and that we need a flexible architecture combining hypermedia objects such as nodes, links, indices and the like with application objects such as editing tools, documents, consistency checkers, etc. In fact we need a software substrate such that: - applications can associate nodes to objects and links to relationships among objects. - different views of the same object can be explored. - the hypermedia components can be navigated following links. - navigational operations (browsing, querying, etc.) can be performed without affecting the application's semantics. Moreover, the objects' semantics (in particular their behavior) can be preserved and when necessary combined with navigational operations. - both the application and the hypermedia components can evolve independently. - it is possible to build high-level tools to simplify the process of hypermedia-application connection. In this context we decided to build an object-oriented framework supporting hypermediaapplication linking. We next discuss some general ideas about object-oriented frameworks and present the architecture of ours in terms of design patterns. 3 An object-oriented framework for hypermedia A framework is a set of cooperating classes that make up a reusable design for a specific kind of software. Frameworks have been implemented in different domains such as user interfaces [Krasner88], graphical editors [Beck94], and operating systems [Johnson91]. An object-oriented framework defines the patterns of objects communication in the application that uses the framework. In this sense we can say that a framework dictates the architecture of an application. It defines its overall structure and the collaboration between classes, dictating the thread of control imposed over the domain, by capturing the design decisions that are common in that domain. In this way, the applications designer can concentrate on the specifics of the application, defining methods that tailor the framework to the application. We will later discuss in which ways design patterns may help in the process of framework design. The use of frameworks usually leads to an inversion of control between the framework and the software that uses it. The framework usually plays the role of the main program coordinating and sequencing application activity. In this way, frameworks serve as extensible skeletons, and while the user supplies methods to tailor generic algorithms defined in the framework for a particular application,
the framework itself can be extended by adding new subclasses that conform to the protocol defined in their abstract super-classes [Johnson88]. Using frameworks results in faster application building and easier maintenance, due to the fact that all applications using the framework will exhibit a common design structure. Unfortunately frameworks are very difficult to design. Designing a framework requires a deep knowledge both of the target domain and the kind of applications that may use the framework. Moreover, as a framework defines the architecture of the overall application, selecting the right architecture is critical and so is designing flexible and extensible frameworks. Defining a framework for building rich applications that support hypermedia-style navigation implies deciding first which will be the overall underlying architecture of object collaboration in this kind of applications, and then building some class hierarchies of hypermedia components. In the next section we describe the architecture induced by the framework, which is mainly based on the ObjectOriented Hypermedia Design Model [Schwabe95]. 3.1 The Framework's Architecture As previously discussed we need to fulfill some functional requirements such as providing seamless integration among hypermedia and application operations, i.e. navigation and objects' behavior. Besides, the architecture must guarantee some design quality aspects such as high decoupling among components leading to easier extension and reuse of both application and hypermedia components. Documenting a framework and/or explaining its use and structure is usually quite difficult because of the complex and dynamic relationships that exist in this kind of object-oriented architecture. We will use here an approach that is similar to the one presented in [Beck94], in which an objectoriented framework is described in different levels of abstraction focusing on each micro-architecture inside the framework. We describe the main components of each micro-architecture presenting the initial design of their classes. The application's architecture as induced by the framework contains three main components: the Object Model, the Hypermedia View and the Interface. Different implementations (as we will discuss later) may further divide the Interface component (using for example an extension of the ModelView-Controller framework [Krasner88]).
Object Level
{
Methods
AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAA
Hypermedia Level
View 1
Interface Level
View 3 AAAA AAAA AAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA
Application
OK
Cancel
View 2
Link Level association Figure 1. The framework's architecture In Figure 1 we can see an outline of the architecture of an application using the hypermedia framework, and a simplified sketch of the kind of object interactions that we will find in it. We may
associate zero, one or more nodes to each object in the object model (the model of the underlying application). Each node in turn will have different views, one for each possible user profile or need (we can see a node as a prism, such that each face shows a particular view). For each meaningful relationship in the object model we will create links connecting the corresponding nodes. We will also define indexes and other access structures [Garzotto93] providing access to nodes by querying attributes in the corresponding object. Each node-view will be in turn connected to one or more interface objects. These objects implement interface controls that will allow either activating link anchors in the node, or triggering methods in one or more objects associated with that node. Once an application with this architecture begins, its behavior is mainly interface-driven. There will be some interface objects that depending on the application style will be either simple nodes, the representation of an access structure or even complex browsers. When the user generates an interface event, for example pressing a button or selecting a menu option, some node receives a message that in turn will require either sending another one to the associated object or to another hypermedia object (a link for example). Each time a link is traversed, a new interface object is required (the one corresponding to the node at the end of the link). We will not describe in this paper particular user-interface features in detail because they are extremely language and environment dependent; we will instead analyze the abstract responsibilities of the interface layer and will give a deeper description while discussing Smalltalk and Tool implementations. The next subsection presents as an example a Management Information System (MIS) application, in order to make this discussion more concrete. The framework is built from three main class hierarchies: Node, Link and Access-Structure. Nodes may be associated or not with application objects (See Figure 2). The former ones (ObjectNodes) will extract from the application objects related, the data an behavior to be perceived. ObjectNodes may be Atomic or Composites (see Section 4.1), the later capturing hierarchy, nonlink-based organizations of information, extracted from aggregations of the underlying application. There is another type of composition reflected in Collection-Nodes, that aggregate a set of nodes with a userdefined navigational pattern, (resembling the idea of Collections of [Garzotto94]). Moreover, nodes are themselves aggregations of views, where each view represents a different understanding of an application object. Each view in turn may have one or more interfaces (according for example to different user preferences or interaction styles).
Node
MultiViews-Node
Object-Node
Atomic-Node
SingleView-Node
Hyper-Node
Navigator
Composite-Node
Collection-Node
Virtual-Node
Figure 2: Node hierarchy. An interesting design problem arises when dealing with the class hierarchy of Object-Node. When an application developer creates new application specific classes and he wants to view them as hypermedia nodes, he may need to specialize class Object-Node: for example for application class
Project (see section 3.2) he would define ProjectNode describing which Project attributes he wants to view, which anchors will lead to other nodes, etc. However, as Node is the root of a complex and evolvable hierarchy (See Figure 2), merging application-specific classes with classes that specify the abstract behavior of different kinds of nodes is not a good design choice. Instead we have separated node specifications (the hierarchy in Figure 2) from node implementations, i.e. particular kinds of nodes in an application, by defining the class NodeClass; this is an abstract class which is specialized with application-specific classes (See Section 4). Node-Views contain anchors that represent the origin of links and allow their activation. Anchors have their own representation, either as active interface objects (e.g. buttons) or sensible areas merged in the data. The end-points of a link may be defined statically (i.e. while configuring the hypermedia-application association) or dynamically, by querying an appropriate application object. This suggests decoupling the link itself from the algorithm used to find its end-point so we can make it change dynamically. Moreover we can build families of such algorithms, e.g. for accessing a database of links (as in Microcosm [Hall93]), or using complex approaches such as information retrieval algorithms [Salton93]. (See Section 4.1). Links may be classified according to the origin and destination node-classes (see Figure 3). We may also define attributes inside them, such as meaning or purpose, and even more, these attributes may be obtained from objects of the application which represent associations (Object-Link).
Link
Classified Link
Unclassified Link
O bject Link
Figure 3: Link hierarchy. The last hierarchy presented here is that of Access Structures. They represent means of accessing the nodes or provide short-cuts to the desired information. We have provided three kinds of access structures: Guided-Tour (with which the author may recommend a path to follow across the web), Index and Iconic-Structure, but the user of the framework may add new sub-classes (as for example a Conditional Index including a predicate on the target nodes), maintaining the standard protocol and redefining some methods. As nodes represent views on application objects they must reflect changes occurring in those objects. Reciprocally, when the user interacts with a node (in fact with the node's interface), the result of such interaction may have to be reflected in the application object. However, nodes and application classes belong to different design domains and as such they must evolve independently. As we discuss in Section 4, we solve this situation by making nodes "observe" application objects. 3.2 Example: The Academic MIS Consider a software system for an academic department, including: general department information, professors, courses, research projects, budgets, funding information, publications, equipment, etc. Figure 4 shows the complete, abstract model. This software system involves several
applications supporting different kinds of users, each with different information needs. Possible users are visitors to the department, students, and funding agencies. It should be clear that visitors accessing information about projects and courses will have an understanding of the domain different than that of a manager of a funding agency, who wants to explore research projects to decide whether to give financial support to the department. See [Schwabe95] for a more detail explanation of the example.
Equipment type description
Research S.S does research
has Department name location summary
involved in Personnel S.S has
teaches Courses S.S
Dep. Images description presentation
Figure 4: The whole model of the Academic MIS.
Given this model, we can think in an interface aimed at exploring the information base by navigating through different data objects. For instance, department-node, professor-node, project-node, course-node, etc., may be defined as Node-Classes, from which the different Object-Nodes will be automatically generated. Link classes will be also instantiated for each relationship found in the model. From them, links will be also automatically derived. Relationship mean will be mapped as a link attribute. Moreover, different context describing different node-views may be define for the three type of users already analyzed: visitors, students and funding-agency. Finally, we must fill each view of a node-class with the selectors for getting the data and behavior from the object level, and specify the desired interface including information about anchor’s representation.
4 Design Patterns in the Hypermedia Framework While designing the framework we found very useful to discuss and communicate design alternatives in terms of design patterns and their vocabulary [Gamma94]. Design Patterns are a good means of recording design experience. A design pattern systematically names, explains and evaluates an important and recurring design in object-oriented systems. Design Patterns make it easier to reuse successful designs and architectures. Patterns describe problems which occurs over and over and describe the core of a solution to that problem, in such a way that we can use this solution many times in different contexts and applications (See [Gamma94]).
In this paper we introduce design patterns with examples from our framework, showing the effects of using them in terms of the whole design architecture. In particular we briefly analyze the following patterns: Observer, Composite, Strategy, Prototype and Mediator, which are described in [Gamma94]. 4.1 Describing the Architecture with Patterns It soon became clear that nodes were “observers” for application objects and that interfaces were “observers” for views in a node, so we use the Observer design pattern. The same application object may be attached to different nodes, and the same is true for node interfaces. As said before, each time an object changes it must notify the hypermedia layer (i.e. its observers) that it was updated. On the other hand, as we wanted to provide an interface combining navigation with the application behavior, user input may either cause navigation in the hypermedia structure or trigger a method in the node's subject depending on the kind of association established in the chain of observers. Nodes are described using the Composite pattern, i.e. object-nodes may be atomic or composites (of other object-nodes), and on the other hand collection-nodes are composites of any kind of node (See Figure 2). The relationship between links and the algorithm used to find their end-points is that established by the Navigation Strategy pattern [Rossi95], in which each link contains an object representing an algorithm to be used when the link is navigated. This pattern is a variation of the Strategy pattern in [Gamma94] that also have an Abstract Factory strategy as a possible algorithm intended for creating the endpoint at the same link activation moment. (See Figure 5) Link
endpointSolver
- activate ()
EndpointSolver - getEndpoint ()
Fixed-Endpoint - getEndpoint ()
Computed-Endpoint - getEndpoint ()
Dangling-Endpoint
Endpoint-Factory
- getEndpoint ()
- getEndpoint ()
DBEndpoint-Factory Endpoint
- getEndpoint ()
Figure 5: Pattern Navigation Strategy between Link and Endpoint Solver hierarchy
As discussed in Section 3, when using the framework the application developer must define node classes, i.e. concrete observers for object classes. As the structure of nodes is applicationdependent it is undesirable to include new node classes as part of the Node hierarchy; moreover if node classes were created by the application developer as sub-classes of AtomicNode (Figure 2) it would be difficult to add new types of atomic nodes without re-factoring. We then decided to use a variant of the Bridge design pattern (Figure 6); there are two separate hierarchies: Node and NodeClass, the former is application-independent and the latter is application-specific. Furthermore we used the Prototype pattern to design the implementation hierarchy of NodeClass. NodeClass acts as a template and new kinds of application-specific types of nodes are created by instantiating either Atomic or Composite-
NodeClass and filling the template rather than by creating new classes; instances are later cloned and used by object-nodes in the form of node views.
Node-Class
Object-Node
- createNode()
Composite-Node
Atomic-Node Atomic-Node-Class - createNode()
Composite-Node-Class - createNode()
Node-View n := Atomic-Node new. for each nodeView do clone(nodeView) in n. Figure 6: Relationship between Object-Node and Node-Class
5 Implementation Issues We have first implemented the framework using Smalltalk, and in particular the MVC framework for defining node interfaces. While working on the implementation we realized that the process of associating node classes with application classes and node instances with objects required adding a lot of application-specific code. We then began thinking in using mediators among objects and nodes, following the collaboration scheme defined for the Mediator design pattern. They would concentrate all code defining the communication mechanisms between objects and their observers. However, when working in our second implementation using TOOL [Carvalho93], a strongly typed, object and event-oriented language, we did need mediators because we could not use message selectors as objects as we had done in Smalltalk. Moreover, as TOOL supports asynchronous message passing and an interesting ownership mechanism, in which objects may send messages to their owners without explicitly knowing them, the Mediator design pattern happened to be an excellent choice for achieving even higher levels of decoupling among the application and the hypermedia level. Also, as a side-effect, the communication style between observers and their subjects by means of mediators (we called them connection objects) allows extending the framework such that nodes can obtain information from different sources, e.g. a relational database, thus yielding a more flexible hypermedia architecture. In this case we would define an abstract Mediator with two abstract subclasses: ObjectMediators and RelationalMediators, being the task of the application developer to further specialize these classes when creating new applications (See Figure 5).
Mediator ApplicationClass
ConcreteAppClass
mediator
- getData (node)
ObjectMediator
RelationalMediator
- getData (node)
- getData (node)
Figure 5: Objects, Nodes and their Mediators
Node - getData ( )
mediator getData (self)
6 Further Work and concluding remarks We have briefly described some of the object-oriented patterns that we use in the design and implementation of a framework for adding hypermedia functionality to object-oriented applications. The use of patterns helped us during the design process by providing a common vocabulary for communicating our ideas. We used patterns in order to check out our design decisions and many times we found simple and elegant design micro-architectures by comparing our ideas with those in [Gamma94]. We have also experienced some trade-offs during implementation, particularly when working with a strongly-typed object-oriented language. We have not addressed in this paper some important issues such as documenting the whole design using a patterns-based formalism as in [Johnson92]. Understanding how to use or extend an object-oriented framework is generally difficult. We are now working in two directions: we are building a set of tools for supporting the process of associating an object-oriented application with its hypermedia views with the style of visual applications or interface builders (as VisualWorks*), and we are also producing a pattern-based documentation for application developers wanting to use or extend our framework. * VisualWorks is a trademark of ParcPlace Systems. 7 References [Alvarez95] X. Alvarez, G. Dombiak, A. Garrido, M. Prieto and G. Rossi: "Objects on Stage. Animating and Visualizing Object-Oriented Architectures in a CASE environment". Proceedings of the International Workshop on Next Generation CASE Tools, Finland, 1995. [Amandi93] A. Amandi, L. Alvarez, M. Prieto and G. Rossi: "Combining hypermedia and objects in domain modelling". TOOLS'93, Europe, Versailles, March 1993. [Beck94] K. Beck and R. Johnson: "Patterns generate architectures". Proceedings of the European Conference on Object-Oriented Programming, Italy, July 1994. [Bigelow88] J. Bigelow: "CASE and Hypertext" .IEEE Software, March 1988. [Carvalho93] S. E. R. Carvalho, "The Object and Event Oriented Language TOOL", Monografias em Ciência da Computação, Departamento de Informática, PUC/RJ, 6/93. [Gamma94] E. Gamma, R. Helm, R. Johnson and J. Vlissides: "Design Patterns: Elements of reusable object-oriented software", Addison Wesley, 1994. [Garzotto93] F. Garzotto, D. Schwabe, P. Paolini: "HDM- A Model Based Approach to Hypermedia Application Design", ACM Transaction on Information Systems, Vol. 11, #1, Jan 1993, pp 1-26. [Garzotto94] F.Garzotto, L. Mainetti, P. Paolini. "Adding Multimedia Collections to thye Dexter Model". ECHT'94 Proceedings. [Goldberg83] A. Goldberg and D. Robson: "Smalltalk-80: The language and its implementation". Addison Wesley, 1983. [Hall93] W. Hall, G. Hill and H. Davis: "The Microcosm link Service", Proceedings of the ACM International Conference, Hypertext'93, Seattle, 1993 [IEEE92] IEEE Software: "Special issue on Integrated CASE", March 1992. [Johnson88] R. Johnson and B. Foote: "Designing reusable classes", Journal of Object-Oriented Programming, 1(2), 1988. [Johnson91] R. Johnson: "Reusing Object-Oriented Designs". Technical Report, University of Illinois,1991.
[Johnson92] R. Johnson: "Documenting frameworks using patterns". In Object-Oriented Programming Systems, Languages, and Applications Conference Proceedings, pages 63-76, Vancouver, British Columbia, Canada, October 1992. ACM Press. [Krasner88] G. Krasner and Stephen Pope: "A Cookbook for Using the MVC interface paradigm in Smalltalk-80", Journal of Object-Oriented Programming, 1(3), 1988. [Malcolm91] K.C. Malcolm, S.E. Poltrock and D. Schuler: "Industrial Strength Hypermedia: Requirements for a large engineering enterprise", Proceedings of the Third ACM Conference on Hypertext, San Antonio, 1991. [Rossi95] G. Rossi, A. Garrido and S. Carvalho. “Design Patterns for Object-Oriented Hypermedia Applications”. Accepted for review at the Second Annual Conference on the Pattern Languages of Programs. Monticello, Illinois. September, 1995. [Salton93] G. Salton and J. Allan: "Selective Text Utilization and Text Traversal". Proceedings of ACM International Conference of Hypertext. Seattle, Washington USA. 1993. [Schwabe95] D. Schwabe and G. Rossi: "Building Hypermedia applications as navigational views of an information base", Proceedings of the IEEE Hawaii International Conference on System Science 1995.
