OOHDM's Design Process


3. OOHDM's Design Process

The Object-Oriented Hypermedia Design Method is a model-based approach for building hypermedia applications. It comprises four different activities namely conceptual design, navigational design, abstract interface design and implementation. They are performed in a mix of incremental, iterative and prototyped-based development style, as discussed in [22]. During each activity, except for the last one (implementation), a set of object-oriented models describing particular design concerns are built or enriched from previous iterations.

3.1 Conceptual Design

During Conceptual Design a model of the application domain is built using well known object-oriented modeling principles (OMT, [26]), augmented with some primitives such as attribute perspectives and sub-systems. Conceptual classes may be built using aggregation and generalization/specialization hierarchies typical of object orientation. The main concern during this step is to capture the domain semantics as "neutrally" as possible, with very little concern for the types of users and tasks. The product of this step is a class and instance schema built out of Sub-Systems, Classes and Relationships.

Figure 6 shows (a simplified version of) the conceptual schema for the example application, where, for the sake of conciseness, we have not shown all attributes of all classes. A brief inspection of this schema shows that it has information that can be used by many different types of users for many different purposes. Conceptual Schema

Figure 6. Then conceptual schema for the "Portinari Project"

In this example, class "Artwork" has attribute "Description" which has two perspectives, "Text" and "Picture", corresponding to textual (which may be used for full text search) and pictorial representations of the artwork, exemplifying an extension OOHDM makes to OMT. The arrow between "Reference" and the dashed box is a shorthand to indicate that "Reference" is related to all other classes within the dashed box via the "references" relation; the same holds for "Historical Comments".

3.2 Navigational Design

In order to have an application that can be used by a set of intended users, trying to accomplish a certain set of tasks, it is necessary, in general, to reorganize the information represented in the conceptual model. In OOHDM, this is achieved by defining a navigational model that is a view (in the sense of databases) of the conceptual model. This reflects the point of view that one of the key distinguishing features of hypermedia applications is the notion of navigation, and the navigation space must be designed taking into account the types of intended users and the set of tasks they are to perform using the application. Different navigational models may be built for the same conceptual schema, entailing possibly several applications, each catering to different set of users and tasks.

Navigation design is expressed in two schemas, the navigational class schema, and the navigation context schema. The navigable objects of a hypermedia application are defined by a navigational class schema whose classes reflect the chosen view over the application domain. In OOHDM, similarly to HDM [9] and RMD [15], there is a set of pre-defined types of navigational classes: nodes, links, and access structures. The semantics of nodes and links are the usual in hypermedia applications; access structures such as indexes and guided tours represent possible ways of accessing nodes.

Nodes are defined as object-oriented views of conceptual classes defined during conceptual design, using a query language similar to the one in [17], allowing a node to be defined by combining attributes of different related classes in the conceptual schema. They contain single typed attributes and link anchors, and may be atomic or composites as in [11]. Links reflect relationships intended to be explored by the final user and are also defined as views on relationships in the conceptual schema.

Figure 7 shows three navigational class definitions for the example. Although there is some similarity with the conceptual classes, several differences are worth noting. For example, node class "Artwork" does not contain several attributes of the "Artwork" conceptual class &endash; e.g., photographer's name, date of visit (by photographer), name of researcher, etc.... &endash;, as they represent information deemed of no interest to the intended audience. Navigational classes

Figure 7: Navigational Class Schema for the Portinari Project application

Note also that attributes with multiple perspectives become different attributes of the node class, for example "Description"/"Text" becomes "Description" and "Description"/"Image" becomes "Picture"

Navigational class "Person" also shows an example of "cutting and pasting" of attributes, since it essentially enriches conceptual class "Person" with the "Description"/"Image" perspective taken from the corresponding attribute of a "Photograph" (or "Artwork") to which the "Person" is related via the "is referenced" (or "depicted in") relation. Similarly, navigational class "Guided Tour Commentary" is built by combining the "Description"/"Text" attribute of conceptual class "Historical Commentary" with an aggregation of "Illustration"s, whose "Picture" attribute is derived from the "Description"/"Image" attribute of "Photograph" or of "Artwork". It should also be noted that node classes include "Anchor" attributes for all the outgoing links, which in turn are views of relations in the conceptual schema. The anchors corresponding to "previous" and "next" in some of the examples shown in section one will be further explained after we discuss navigational contexts.

In well-designed hypermedia applications the author must take into account the way in which the user explores the hypermedia space in order to avoid redundant information and to prevent the user from getting "lost in hyperspace". For example, one may access artworks in chronological order. When examining one artwork, the user may decide that he is interested in looking at other artworks with a similar theme. At that point, it should be made clear to the user that there are now options of continuing to examine the artworks by theme or in chronological order, and the user should have the means to indicate his choice of navigation. As a consequence, a different situation arises when presenting the same material in different contexts, as exemplified in figures 3 and 5.

In OOHDM the navigation space is structured using the notion of navigational context (see [1, 29] for a more extensive discussion). A navigational context is a set of nodes, links, context classes and other (nested) navigational contexts. They are induced from navigation classes &endash; nodes, links, indexes, and guided tours. They may be defined intentionally by defining a property that all nodes and links in the context holder, or extensionally by enumerating its members. For example, a 1-to-n link induces a navigational context that allows traversing sequentially all the link targets (e.g., all references to an artwork). In the same way an index (e.g., all paintings about childhood) or a guided tour (some selected paintings) defines a navigational context. Navigational contexts play a similar role as collections [10] and have been inspired in the concept of nested contexts [5]

Figure 8 shows the navigation context schema for the Portinari Project application, and figure 9 shows the definition of one of the contexts that appear in the navigation schema.

Context schema

Figure 8: Navigational Schema for the Portinari Project application

In the diagram in figure 8, the actual navigation contexts are boxes with light gray border (e.g., "Artwork by Theme"); boxes with darker gray borders are used to group contexts for referencing purposes, such that arrows pointing to solid boxes indicate links to any enclosed item; the hierarchical indexes drawn with light dashed lines were not drawn in detail, as they would be very complex. The boxes on the left ("Main Menu" items) are just place-holders to indicate the nesting of the elements pointed to by the gray arrows.

Context definition

Figure 9: Definition of Navigational context "Artwork by Event"

Context classes complement the definition of a navigational class (a node) indicating which information is shown and which anchors are available when accessing the object in a particular context. This mechanism achieves a "layering" effect whereby the information in a node can be further customized depending on the context in which the node is being looked at. There is no equivalent mechanism in traditional object oriented models. Context Class definition

Figure 10: Context class ³Artwork in Event² extends class ³Artwork² within the ³Artwork by Event² context

The navigational context defined in figure 9 collects the artworks that were shown in a given exhibit; its elements are instances of navigational class "Artwork". Navigation within the context is achieved by extending this class with the context class "Artwork in Event", whose definition is shown in figure 10 below. This context class essentially adds the context navigation anchors that allow the user to browse through the elements of this context (see figure 5, bottom row on the left). A common use for context classes is to add comments (oftentimes as narration) that are only visible within the particular context, for example in a guided tour.

The dynamic navigational structure is completely specified by defining the navigational transformations that occur while traversing links. In some cases, for instance, we may want specify that the source node remains active, and the target node becomes active as well; or that all destination nodes of a one-to-many link become active simultaneously. In OOHDM we use an object-oriented state-transition model derived from Statecharts [14], that we call Navigation Charts, supporting structural and behavioral nesting and allowing expressing dynamic navigational behavior. The Navigation Chart definition is complemented with a set of predicates expressed in Temporal Logic that allow querying the specification against desired properties such as safety, livenesss, etc.

3.3 Abstract Interface Design

Once the navigational structure has been defined, it must be made perceptible to the user through the application interface, which is done in this step by defining an abstract interface model. This means defining which interface objects the user will perceive, and in particular the way in which different navigational objects will appear, which interface objects will activate navigation, the way in which multimedia interface objects will be synchronized and which interface transformations will take place.

A clean separation between both concerns, navigational and abstract interface design, allows building different interfaces for the same navigational model, leading to a higher degree of independence from user-interface technology. In addition, this separation allows a better understanding of the overall application structure by clearly indicating which transformations in the interface are also navigational transformations and which are simply local interface transformations that do not affect the state of the navigation.

In spite of the previously mentioned interest in hypermedia design methods, and even though interface design is a critical aspect of the creation of large hypermedia applications [27], human-computer interfaces are usually described using implementation and environment dependent tools, and design decisions at the interface level are seldom documented.

In OOHDM we use the Abstract Data View (ADV) design approach for describing the user interface of a hypermedia application [7]. Abstract Data Views are formal, object-oriented models of interface objects and they are specified by showing:

The modeling constructs we use during navigational and abstract interface design are very similar &endash; in fact we use classes and objects with a formal connection model &endash; and thus we obtain a seamless transition between both activities, allowing incremental construction of the navigational and abstract interface models. At the same time, crucial design decisions are recorded using a notation that is powerful and concise. Navigation- and ADV-charts may be easily related and combining information in interface and navigation classes results in a strong traceability model. The reader may find a complete description of our approach in [24].

We give brief example using the navigation class "Artwork" (from the schema in figure 7) and its associated interface objects, by presenting the behavioral specification of the corresponding Abstract Data View in just enough detail to show that we can build a formal but nevertheless simple and readable specification.

Figure 11 shows a simplified Configuration Diagram specifying some abstract interactions among interface and navigational objects (called "owners" of the interface object). Dashed lines are required services while full ones are provided services. Attributes "theme", "date" and "technique" act as static interface objects, i.e. they do not react to external events.

Nested Abstract Data Views "Picture", "Description", "Context Interface", "Show Description" and "Show References" exhibit a user-perceivable behavior. For example when the user clicks on "Show Description" the ADV "Description" is displayed. "Context Interface" is in turn composed of nested ADVs implementing anchors for context navigation as previously discussed.

Configuration Diagram

Figure 11: Configuration Diagram for ADV "artwork"

This dynamic description is specified using ADV-Charts, that extend StateCharts to user interface specification (see 25). We can specify the behavior of each nested ADV using a different statechart or use a concise specification as shown in figure 12. For example, ADV "Artwork" can react to external events MouseOn, MouseClicked and Display, while node "Artwork" provides "GetDate", "Subject" and "Name" and "AnchorSelected". When both ADV and node attributes have the same name and type we can omit specifying services like "GetDate" because it can be unambiguously understood by implementors. Note that "Show Description" and "Show References" do not trigger navigation, they just implement local interface behavior.

ADV-Chart for Artwork

Figure 12: ADV Chart for ADV "Artwork"

In the figure above some interface objects (such "References") may have embedded anchors triggering navigation; in this case the owner (node "Artwork") is sent the message "anchorSelected" with corresponding anchor as argument and the interface objects are removed from the perception context ("Artwork" in state "Off").

3.4. Implementation

To obtain a running implementation, the designer has to map the navigational and abstract interface models into concrete objects available in the chosen implementation environment. The model generated after performing previously defined activities can be implemented in a straightforward way using many of the currently available hypermedia platforms such as Hypercard, Toolbook, Director, HTML, etc.

The object-oriented style of the abstract interface specification allows simplifying the interface in implementations in different platforms. For example, figure 13 shows the Toolbook version of the same node shown in figure 5. In this implementation, the anchors "Description", "History", "References" and "Persons and Entities", when activated, produce different behavior than the HTML version. In the Toolbook-based one the expression: self Display is implemented by a scrollable "pop-up" field which shows the corresponding information, while in the HTML implementation this effect is achieved by a local scroll effect using a local anchor (see figure 4a). Similarly the expression "self ShowLargeImage" (in "Picture") is implemented in different ways in both implementations. The condition "not Focus" in "Description", easily implemented in Toolbook, is changed in the HTML implementation by providing a button for scrolling back, although it could also be implemented using the "back" button of the browser.

Screen from Toolbook version

Figure 13. Toolbook version of the screen for "Artwork" "Artwork"

There are other differences in each implementation of the example. For instance, the guided tour in the Toolbook version has additional transition effects, as well as soundtrack. The observing reader will have noticed that the Toolbook version has a "back" button in the bottom right set of controls, which is not present in the HTML version. The reason is that the semantics of the "back" function in the web browser is exactly the same as the "previous" link in navigation contexts, whereas the same function in Toolbook has different semantics, and therefore it has to be programmed explicitly.

Another interesting kind of implementation for OOHDM-based projects is the one provided by object-oriented frameworks [16]. We have designed an implemented a framework that allows adding hypermedia functionality to object-oriented applications. In this case the conceptual model is finally implemented using an object-oriented language and navigational classes are instantiated from the framework (see [25, 4]).


Intro | Example | OOHDM | Discussion | Conclusion | Refs | previous | next