Research Work : Updating Hypermedia Object Oriented Design Method (OOHDM) to systematice the process of designing Web applications

Rubn Tous
Abstract
The aim of this document is to analyze the different known research works about the use of an Object Oriented Methodology in the design of web-based or other kind of hypermedia applications. Of these research works we will focus on the Object Oriented Hypermedia Design Method (OOHDM), an approach that considers Web applications as navigational views over an object model. We will study this methodology and its latest releases and add-ins, such as the adaptation of the Unified Software Process and the use of Design Patterns and Design Frameworks.

Objectives

There has been passed a long time from 1993, when D. Schwabe, F. Garzotto and P. Paolini released the first version of HDM (Hypertext Design Model) [1]. They identified the necessity to rationalize the process of capture an organize the structure of a complex subject matter to offer the users a clear and accessible way to access information. Even in its first release, HDM uses terminology from software engineering (as authoring-in-the-large), because hypermedia applications share some important features with software applications. The two kinds of applications have in common the existence of an underlying conceptual model, an user interface, and statedependent components. All those things must be modeled and some language and methodology must be used for obvious reuse and changeability reasons. The object oriented methodology has been used in software engineering since the early 70s, and nowadays has become the standard way to develop software applications. Since UML 1.0 (Unified Model Language) was released in 1997, it has become the standard language of the object oriented community. In 1995 D. Schwabe and G. Rossi published the first OOHDM specification, an object oriented methodology for hypermedia applications design. Since then, a lot of extensions and changes have been released, basically these are the reasons: 1) In 1995 UML was being forged as a convergence of other model languages (Boochs Booch method, Rumbaughs OMT (Object Modeling Technique) and Jacobsons OOSE (Object Oriented Software Engineering)). OOHDM took then some elements from those l nguages, and as UML has evolved, a OOHDM has adapted to be compliant with the UML specification. The evolution of the WWW, the most important hypermedia system nowadays, has forced the different design methodologies to adapt to the new environment. The people of OOHDM have published a lot of extensions of the methodology to satisfy the requirements of the new applications. The software engineering community has generated some new strategies, as Design Patterns and Design Frameworks, that can be applied to the design of new hypermedia applications, and must be reflected in OOHDM.

2)

3)

This work aims to distill the different OOHDM resources to identify what are the interesting features of the methodology and how could be applied to modern hypermedia design.

Why a model?

Its not the aim of this document to analyze the reasons to use a model in the design of hypermedia applications, but its interesting to remember the main one: Communication. A model provides a common

language between clients, analysts, designers and implementers. A way to document the architecture of applications that can be reused in other projects. A common way to name the things that facilitates the task of specify methodologies and to develop design tools. Communication is the reason because a model not only has to be rich in expressiveness, it has also to be easy to understand and to use.

Why not HDM?

The foundational document of Hypermedia Design Model, "HDM- A Model Based Approach to Hypermedia Application Design" was released in January of 1993. The model wasnt constrained to any particular hypermedia system, but all the samples introduced were implemented using an old version of Hypercard. In its older versions Hypercard was a hypermedia system with a very specific and limited capabilities that motivated a common design style when developing applications. The samples present in the foundational document of HDM have in common that, once implemented, they show to the user only one kind of media at a time (text, image, etc.). In my opinion this feature conditioned the process of defining the model and thats the reason because the most recent reviews and applications, focused on the Web, present a confusing terminology. In HDM the main object is the entity, an entity is composed by a hierarchy of components and each component can be shown under a set of different perspectives called units. This is very easy to understand if we consider for example an entity newspaper N, a component section S, a subcomponent article A, and two units: text and photo. Thats the style of old HyperCard applications and in that context the model terminology is very clear. Although, when trying to apply this concepts to a modern web page the concepts of unit, perspective and component becomes ambiguous. By other way, HDM is a very poor model to specify the underlying information structure of an application. The authors say that it is not intended to be a semantic model [1] but they are providing terminology to model the semantics of the core domain of the application, that they call hyperbase. They say that HDM share some similarities with the Entity Relationship (E-R) model, but that HDM Entities are much more structured than E-R Entities, which are essentially flat and do not have structural links [1]. With this affirmation they demonstrate an unknowing of the E model because E entities can have relationship with other entities, and this -R -R relationship can be of type part-of, providing a mechanism to structure entities in subparts. In fact E-R is more flexible because E-R entities can be composed by other entities while HDM entities can be only composed by its own components, that cannot be used as components for other entities. HDM offers a tree to structure the information but the people of the world of databases know since a long time ago that information must be modeled with graphs. In conclusion, HDM became obsolete when hypermedia systems and applications evolved, diverging from its original forms and requiring a more powerful and clear model.

Why Object-Oriented?

The core of a hypermedia application is information that, independently from how is presented or stored, ever has some implicit structure that allows to divide it into smaller parts. A systems design process implies the resolution of a comple x problem by partitioning this problem into less complex sub-problems. When partitioning a problem that is related to a considerable quantity of information its needed also to divide this information. The software engineering discipline has studied the modeling of information since its beginnings. In 1965 Ole -Johan Dahl and Kristen Nygaard released Simula, the first object-oriented programming language. The object-oriented paradigm is based on encapsulating information and its related processes into single units called objects. The Simula language was followed by others, as SmallTalk, Eiffel, C++ or Java. The new programming languages motivated a new design methodology where data modeling plays a very important role. As a part of this methodology was defined the Object Oriented Data Model, that shares some features with the Entity-Relationship model from the world of databases. In 1997 was released UML, a standard language for the Object Oriented Methodology that includes a standard graphical notation for describing a data model. UML, and overall its data model, proved to be very expressive and intuitive, and its success was absolute. Nowadays the UML data model is used in every application design and, in the world of databases, has substituted the E-R model. There are millions of persons familiarized with the Object Oriented Data Model and the UML notation: programmers, analysts, software architects, computer science students and in general anyone from the science and engineering fields. If the target of at model is to improve communication there is no doubt of what are the reasons to use a Object Oriented Methodology in hypermedia applications design.

UML

The Unified Modeling Language (UML) is a modeling language used to describe software systems. It was the evolution of various second-generation object-oriented methods and was developed during the 1990s, starting with Rational Software Corporation and three of the most prominent methodologists in the information systems and technology industry, Grady Booch, James Rumbaugh, and Ivar Jacobson. The language has gained significant industry support from various organizations via the UML Partners Consortium and was approved by the Object Management Group (OMG) as a standard in 1997. The last release of UML is the 1.3 version. It includes a lot of new features like a meta-model and XMI, a XML application to serialize UML models. Commonly, when people thinks in UML, they think in four different abstraction tools: The Use Cases Diagram, The Class Diagram, the Sequence Diagram and the Statechart Diagram. The Use Cases Diagram shows the relationship among actors and use cases within a system.

The Class Diagram shows the graph representing the classes, attributes and relationships of the system.

A Sequence Diagram presents an interaction, which is a set of calls between objects to effect a desired operation or result.

Statechart diagrams represents the behavior of entities capable of dynamic behavior by specifying response to the receipt of event instances.

its

Although there are a lot of other abstraction tools , less used, like Collaboration Diagrams, Activity Diagrams, etc.

Why not simply UML?

Traditional Software Engineering methodologies do not provide the needed abstractions for specifying applications that embody the hypertext metaphor. From Software Engineering point of view, the concepts of linking and hypertext are just a part of the user interface design, and no specific abstraction tools have been provided to model them. By other hand, the increasing complexity of web applications, and the time constraints of the projects, evidence the need of a specific design methodology that provide a systematic approach and improve reusability. Experience in Software Engineering shows the success of object oriented approach specially in the case of large implementations. Nowadays many companies are transforming their old interactive applications to supply them with a web layer, which implies the addition of hypertext to the user interface. To design these kind of applications is needed to describe the navigational issues, but object oriented methods do not provide primitives for this purpose. The question now is: Is OOHDM a good adaptation of the Object Oriented Methodology to the hypermedia design field? Answer this question is one of the targets of this research work. Its important to remember that he first papers talking about OOHDM were re leased in 1993, four years before UML 1.0. Although, the latest releases and add-ins perform interesting changes and improvements that must be taken in consideration.

OOHDM methodology

Following I will describe and evaluate the sequence of steps to develop an Web application according to the latest releases of OOHDM. The next diagram shows the stages of the methodology:

7.1 Requirements gathering

The stage of capturing and specifying the functional requirements of an application is the previous step to de design process. UML provide some abstraction mechanisms for this purpose, as the Use Cases Diagram, but other diagrammatic tools as the Interaction Diagram (Sequence or Collaboration) or the Statechart Diagram can also be used to gather requirements even theyre usually used only at design time. The next figure shows the five phases of the requirements gathering according to [8].

7.1.1. Role and Task identification

The target of this first phase is to identify the different roles/actors of the domain and their related tasks. This process is achieved through analysis of documents and interviews of users. Examples of roles/actors can be: Student, Manager, etc. Examples of tasks (for the role Student) can be: Search information about a course, Get the course material, etc.

7.1.2. Scenario Specification

Once obtained the set of roles and their tasks we must describe the possible application scenarios. Scenarios are narrative descriptions of how the application may be used to allow actors to perform each task. The next figure shows some possible scenarios, specified by students and managers.

7.1.3. Use Case Specification

Scenarios must be grouped in functional units defined in UML as Use Cases. Because a set of related scenarios can have been defined for different actors, the use case for this set must identify the actors it belongs to.

7.1.4. User Interaction Diagram Specification

Daniel Schwabe and other researchers [4] identified in 2000 the necessity to provide analysts with a new diagrammatic tool that allows to capture and specify the interaction between the users and the system, complementing the Use Cases in a more comprehensible way that other UML notations. This new tool was named User Interaction Diagram, UID, and its purpose is to represent the interaction between the user and the system. UID is a tool used mainly to support the communication between the designer and users in requirements gathering. In addition, in the analysis activity UIDs also serve as input for obtaining the class diagram.[4] For each use case we must define a UID. The next figure shows the UID defined to represent the interaction in the task Browsing a course given a subject.

7.1.5. Use Case Validation

The designer must interact with each user to validate the use cases and the UIDs generated. Each user validates only those use cases and diagrams related with the roles he plays.

7.2 Conceptual Design

The starting point of the design process is the specification of a conceptual model. The target of this model is the enumeration of the object classes of the domain, their attributes and their relationships. The output of this

stage is the Conceptual Class Schema, a graph of classes with the notation specified in UML. The Conceptual Class Schema shows the underlying structure of the information that is going to be presented to the users, independently of the presentation form. This schema has more relationship to the way the data will be stored than to the way it will be presented. The next figure shows a sample of a Conceptual Class Schema from [7]

7.3 Navigational Design

Previous phases have produced, for each task, several scenarios, a use case and a UID. OOHDM describes a method to derive the navigational topology of an application that supports each task. The main output of this method are a Navigational Class Schema and a Context Diagram.

7.3.1. Navigational Class Schema

If the Conceptual Class Schema describes the underlying structure of the applications domain , the Navigational Class Schema hide this underlying structure and shows only a partial view over it. The view showed corresponds to the explicit hypertext nodes of the application and their relationships, the links. Every node is built by combining and filtering the attributes of some conceptual objects in the same way that views are defined in the world of databases. To be compliant with the object-oriented notation OOHDM provides pre-defined classes like Node, Link and other access structures to perform this task. The next figure shows the specification of a node corresponding to the navigational class schema of the previous example.

7.3.2. Navigational Context Schema

There are tasks where the user needs to work with sets of objects, which can be explored in different ways according to the users objective. OOHDM has a design primitive for such sets, called navigational context. The next figure shows a possible navigational context schema for the previous sample. Dashed boxes show access structures (indexes) while boxes inside Class CD (and comment) indicate possible contexts in which a CD (or comment) can be accessed

7.4 Abstract Interface Design

As we mention before, most of the efforts in Web design nowadays are placed in the user interface while the navigational structure is considered of low relevance. OOHDM provides tools to correct this situation though it also offer a model to improve the design of user interfaces. To specify the way the user will perceive the navigational objects OOHDM uses the Abstract Data View (ADV) design approach, that allows to specify interfaces with the advantages of object-oriented methodologies: reusability and changeability. Because the design of user interfaces is not specific for hypermedia applications, and because therere other works most recent covering this issue, we arent going to enter this stage in detail.

Web Design Patterns

The idea of patterns was originally developed by Christopher Alexander in the field of urban architecture, an was adapted to object-oriented software in October of 1994: ``Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.''[3] Design patterns can be also applied to Web design, avoiding that Web designers must face the same problems again. Following are described a set of some design patterns for designing Web applications.

8.1 Portal Pattern

Problem: Sometimes is interesting to give the user a comprehensive description about what he will find in the web site. Bad designs often offer only a home page with a simple index, acting as the root of the navigation tree. This solution hides to the user the information of the leaves of the navigation tree, as products, services and latest news. Solution A possible solution is to design the home page as aggregates of different information items, anchors and access structures. Dedicate space to news, suggestions, general indexes, special offers, etc. The information showed mustnt be semantically connected. Sample The web-site of IBM (www.ibm.com) is a good sample of Portal Pattern.

8.2 Set-based Navigation Pattern

Problem When a collection of nodes may be explored in different ways, depending on the navigation flow, designers usually provide an index to set members w here users are forced to go back when they want to navigate to the next member in the set. One sample of this problem is the web-site www.gaudi202.bcn.es, where its showed an index of photos of buildings but no way to traverse them in a guided tour fashion.

Solution Provide intra-set navigation facilities, to let user traverse nodes without having to return to the index

Sample The web-site of the MOMA is a sample of this pattern. Paintings of a collection can be accessed by index or traversed using the arrows.

8.3 Nodes in Context Pattern

Problem When a node can be accessed from different navigational paths, could be interesting that the content and links presented would be different. For example, when traversing a collection of paintings of a specific painter, could be interesting to hide the name of the painter, that could be redundant. But when traversing some of these paintings within another collection, for example paintings of any specific year, the author must appear. Solution The solution proposed in [6] is to use what in Software Engineering is known as the Decorator Pattern. This pattern consists in decouple the navigational objects from the context in which they are to be explored. The context -dependent peculiarities of a navigational object are encapsulated within another object, called Decorator. If OOHDM is used the Decorator Pattern is already applied under the form of Navigational Contexts. Sample A sample of this pattern is Amazon (www.amazon.com). When we select a book, its presented in detail as we see in the next figure.

By other hand, the same book can appear in a list of books related to the subject J2EE. In that case the information about the back cover, excerpt and index is hidden.

8.4 Active Reference Pattern

Problem Sometimes, in hypermedia applications, we need to provide the user with a way to understand where he is and how to go to another location. For example, in a digital Museum, we would want the reador to see the artworks and meanwhile he should know in which place of the museum he is. The usual solution is to simply use indexes, forcing the user to backtrack from the current node to the index to see where he is or to move to another node. Sample One of the most representative samples of this pattern is the web-site of Yahoo (www.yahoo.com), where we had ever a line with the navigation path followed.

8.5 News Pattern

Problem Most users navigate a web-site neither thoroughly nor regularly. When we add changes (new products, services or resources) to some part of the navigation tree it would be desirable to establish some mechanism to communicate that theres new information available. Solution A possible solution is to present descriptive headlines regarding the newest additions. This headlines must be anchors to link the related pages, allowing the designer to preserve a good organization of the information while giving users feedback of the changes. When several News are to be presented, they can be organized according to their relevance in a set of different sections. Nowadays this pattern is used practically in every web-site.

Sample The web-site of Gamasutra (www.gamasutra.com) is a good sample of this pattern, the underlined red lines of text are the latest news in the world of videogame development.

8.6 Landmark Pattern

Problem Most web-sites can be divided in different and low related sub-systems. When navigating through one of this sub-systems, the user may want to jump to other sub-system. If we build the navigational schema linking every navigational class of one sub-system to every navigational class of the other we will obtain an undesirable chaotic structure. Those links are outside the model. Solution A possible solution is to define a set of landmarks and make them accessible form every node in the application. The interface of anchors of the landmarks must look uniform. Landmarks use to be implemented using lashes.

Sample The web-site of the OMG (www.omg.org) is a good sample of this pattern, The green labels allow at any time to move to other unrelated part of the web.

8.7 Shopping Basket Pattern

Problem There are some kinds of web-sites, like the electronic-commerce sites, where users can find products or services of interest in different locations. In these cases, the decision to buy could depend in the whole set of products and services desired, instead of depend on every single purchase. By other hand, it will be desirable to provide a mechanism to avoid that users must remember all the products and services of interest. Solution The solution proposed is to provide the users a persistent store for those items (a virtual shopping basket) accessible as another navigation object and associate commercial operations to it. At the end the user will decide if the set of operations must be executed or if they must be discarded. This mechanism can be enriched with services of budgeting, validation, etc. Sample The web-site of the Amazon (www.amazon.com) is a good sample of this pattern.

Web Design Frameworks

Patterns allow the reuse of specific parts of architectures in Web applications, but combined with other design primitives they also may be used to express larger reusable design structures called frameworks. A framework is a reusable design for a family of applications in a particular domain. Frameworks must be customized by developers when applied to concrete applications. While patterns provide abstract reuse of design experience, frameworks allow reusing concrete designs in a domain. Web design frameworks are different from application frameworks because while the latter are programmed in a specific language, Web design frameworks are environment and language-independent. In [7] OOHDM is used as the basis architecture for specifying Web design frameworks, providing abstraction tools as a Generic Conceptual Model, a Generic Navigation Schema and a Generic Context Schema.

9.1 OOHDM -Frame

The extension of OOHDM that allows the specification of design frameworks is called OOHDM -Frame [7]. The following sections are based in the notation described by this extension.

9.2 Generic Conceptual Model

The next sample is a generic conceptual model for electronic stores. Apparently is not different to a concrete model, but some classes appear in gray. These classes are abstract classes, and must be concretized when applying the model to a specific application.

9.3 Generic Navigational Model

In analogy to OOHDM, in OOHDM -Frame to define a generic navigational model we must specify a Generic Navigation Schema and a Generic Context Diagram.

9.3.1. Generic Navigation Schema

The next figure shows a generic navigation schema corresponding to the previous sample. T only he difference with a concrete navigation schema is that some Node attributes (those marked with *) and some relations (dashed) may be optional. An optional attribute may or may not appear in an instantiated application.

Another possibility is sub-classing, allowing a more subtle way of achieving genericity. In the sample we may create a sub-class of Product as shown below.

The Refine operator takes the query in the corresponding super-class and replaces Comment with its sub-class EditorialComment. With that we are saying that Books must only show editorial comments.

9.3.2. Generic Context Diagram

The next figure shows a possible generic context diagram for the previous sample. Dashed boxes and rounded boxes indicate generic access structures and contexts. For example, Product by Property is a generic context that will be typically instantiated into one or more contexts that allow navigation among products according to certain properties (price, color, etc.).

10 Conclusions
The first releases of OOHDM incorporate the power of object oriented models to hypermedia design. Although, in despite of presenting an interesting set of new and adapted diagrammatic tools for designing hypermedia applications, the method evidenced the lack of a systematic process in the development of such applications, becoming just a set of interconnected abstraction tools. In software engineering, the way the UML tools must be used is defined in the Unified Software Process, that clearly identifies the phases of the development of a software application, and how each phase must be mapped into the next . Last releases of OOHDM solve this problem providing an hypermedia adaptation of the Unified Software Process, that has been shortly described above. According to [8] we can obtain the design specification of a web-based application just gathering the requirements into User Interaction Diagrams and applying the method systematically. In addition, a set of design patterns, and a design framework notation have been incorporated, in parallel with what is happening in the world of software engineering, to improve reusability and optimize the development time. In conclusion, web designers have now a powerful but slightly complex object oriented methodology to develop Web applications and an useful set of patterns and frameworks to avoid reinventing the wheel.

11 References
[1] D. Schwabe, F. Garzotto, P. Paolini, "HDM - A Model Based Approach to Hypermedia Application Design", ACM Transaction on Information Systems, Vol. 11, #1, Jan. 1993, pp. 1-26.

[2] D. Lange, "An Object-Oriented design method for hypermedia information systems", Proceedings of the 27th. Annual Hawaii International Conference on System Science, January 1994.

[3]

Design Patterns, Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (The Gang of Four). D. Schwabe "A Diagrammatic Tool for Representing User Interaction in UML", Lecture Notes in Computer Science, forthcoming, Proc. UML2000, York, 2000. D. Schwabe "Systematic Hypermedia Application Design with OOHDM", March 1996 D. Schwabe, Gustavo Rossi, Fernando Lyardet "Patterns for Designing Navigable Information Spaces", 1999. D. Schwabe, Gustavo Rossi, Fernando Lyardet "Abstraction and Reuse Mechanisms in Web Application Models", 2000 D. Schwabe, Patricia Vilain, Natacha Gell "Modeling Interactions and Navigation in Web Applications", October 2000

[4]

[5] [6] [7]

[8]