1

OOHDM-Web: An Environment for Implementation ofHypermedia Applications in the WWW

Daniel Schwabe*, Rita de Almeida Pontes and Isabela MouraDept. of Informatics, PUC-Rio

[schwabe, rita, moura]@inf.puc-rio.br

Abstract

This paper shows an environment, OOHDM-Web, that allows template driven website forapplications designed using, OOHDM.. We show how this environment allows direct mapping ofnavigation and interface constructs of OOHDM into a library of functions in the CGI scriptingenvironment CGI-LUA, extended with the DB-LUA package. OOHDM-Web allows implementationof hypermedia applications as CGI scripts that produce dynamically generated pages, whose contentsare fed from a database and integrated with pre-defined templates. The paper presents theadvantages of combining the two techniques, template-driven implementations and design methods,reaping benefits of their respective strengths.

* Work partially supported by CNPq, MCT, Brazil.

1. Introduction

One of the prime implementationplatforms for hypermedia applicationsnowadays is the WWW. In this case, acollection of documents and CGI scripts ismade available to users, allowing both accessand in many cases processing of informationcontained in these documents. This collectionof pages usually shares a common coherentinterface appearance and behavior, and may bephysically located in one or more web servers.One example of such applications is theAmazon Books website (www.amazon.com).

However, much in the same way as inother platforms, there is no environment thatfacilitates the structured development of suchapplications. In spite of a number of designmethodologies having been proposed andadopted [OOHDM [Schwabe 98b, Schwabe 96,Rossi 96, Schwabe 95], HDM [Garzotto 93],RMM [Isakowitz 95], Matilda [Lowe 96],designers are still forced to map the primitivesin such methodologies to any givenimplementation platform, including the WWW.

The tools available in the market todayto aid in website design and implementationmay be classified in three main categories: pageeditors, web site editors, and website buildingenvironments.

Of these, the last offers the most supportfor developers, as they allow the constructionof sites where documents are defined usingtemplates which extend standard HTML withsome proprietary set of tags, typically allowingincluding of statements in some customdefined or standard programming/scripting

language. In such environments, documentsare dynamically assembled at run-time byinstantiating a template with data pulled offfrom a database. Documents can be created andmaintained using the same mechanisms,employing another set of appropriately definedtemplates. Examples in this category areMicrosoft Active Server Pages (ASP),StoryServer (www.vignette.com), Cold Fusion(www.allaire.com), CGILua [Hester 96],(www.tecgraf.puc-rio.br/~cgilua) and DBLua(www.tecgraf.puc-rio.br/~cgilua)

The major drawback of theseenvironments is the fact that they lack higherlevel abstractions that allow the user to designapplications without resorting to a node-and-link level of description of the whole system. Inspite of these drawbacks, template-basedapproaches present inumerous advantages:uniform treatment of pages, separation ofcontent and presentation, more efficient use ofstorage, etc... It would be interesting to have anenvironment that exploits such advantages,while adding higher level primitives that allowthe designer to express his design at a levelcloser to the application domain. From thispoint of view, these environments can be usedas basis for implementation of designs carriedout using one of the previously mentionedmethodologies. This paper presents how thishas been achieved for applications designedemploying the Object Oriented HypermediaDesign Method (OOHDM), using the CGI Luaweb site building environment.

The remainder of this paper presentsfirst a brief description of OOHDM, and thengives more detail about OOHDM-Web, theenvironment we have built. To conclude, we

2

present current research being conductedaround OOHDM-Web.

2. A Brief Overview of OOHDM

The Object-Oriented Hypermedia DesignMethod [Schwabe 98b, Schwabe 96, Rossi 96] isa model-based approach for building largehypermedia applications. It has been used todesign different kinds of applications such as:web sites and information systems, interactivekiosks, multimedia presentations, etc.

OOHDM comprises four differentactivities namely, Conceptual Design,Navigational Design, Abstract Interface Designand Implementation. They are performed in amix of incremental, iterative and prototype-based development styles. During each activitya set of object-oriented models describingparticular design concerns are built or enrichedfrom previous iterations. In Figure 1 we show asketch of the models and activities in OOHDM

Figure 1: OOHDM design models

Treating conceptual, navigational andinterface design as separate activities allows usto concentrate on different concerns, one at atime. Consequently, we get more modular andreusable designs, and we obtain a frameworkfor reasoning about the design process,encapsulating design experience specific toeach activity.

Design primitives can be mappedstraightforwardly onto non object-orientedimplementation languages or environments(such as HTML or Toolbook). Consequently,OOHDM can be used regardless of whether thetarget system is a pure object-orientedenvironment one or a hybrid one (as thoseusually found in the Internet).

In the next sub-sections, we describeeach phase in more detail.

2.1 Conceptual Modeling

The goal of the Conceptual Designactivity is to build a model of the applicationdomain, using well known object-orientedmodeling principles, using a notation similar toUML [UML 97]. The product of this step is aclass schema built out of Sub-Systems, Classesand Relationships. The major differences withUML are the use of multiple-valued attributes,and the use of directions explicitly in therelations.

Conceptual classes may be built usingaggregation and generalization/ specializationhierarchies. The main concern during this stepis to capture the domain semantics as“neutrally” as possible, with very little concernfor the types of users and tasks. If theapplication involves computations on objects,such as in Web-based Information Systems, theconceptual model will evolve into an objectmodel that will be implemented in the targetenvironment (for example in a WWW server).In this case, navigation objects will act asobservers [Gamma95] over these applicationobjects.

OOHDM does not prescribe anyparticular method to produce the ConceptualClass Schema; any of the well-knownmethodologies, such as OMT [Rumbaugh 91]may be employed.

3

Building

name: Stringaddress: Stringyear: Integerdescription: [Text+, Photo: Image]

Architect

name: Stringdescription: [Text+, Photo: Image]

Building Categoryname: Stringdescription: String

0..* designs 1..*

0..* classifies 1..*

Figure 2 – Conceptual schema for a site about architecture

Figure 2 shows a Conceptual Schemafor a Web site about architecture. Perspectives(multiple valued attributes) are denoted byenumerating the possible types, with a + nextto a default type. Thus, description: [Text+,Photo: Image] means attribute description has atext perspective (always present), and mayhave an image perspective containing a photo.

2.2 Navigational DesignIn OOHDM, an application is seen as anavigational view over the conceptual model.

This reflects one of the major innovations ofOOHDM, which recognizes that the objects(items) the user navigates are not the conceptualobjects, but other kinds of objects that are“built” from one or more conceptual objects.Therefore, node attributes are defined as object-oriented views of conceptual classes, using aquery language similar to the one in [Kim94].This allows a node to be defined by providingaccess to attributes of different related classes inthe conceptual schema. This view is orientedtowards a certain class of users and theirrespective tasks. Nodes generalize the Observerconcept from [Gamma95].

Building

name: Stringaddress: Stringyear: Integerdescription: Text+Photo: Image*Category: bc.name where bc:Building

Category,bc classifies self

Architect_name: list of(anchor (designs-1))

Architect

name: Stringphoto: Image*build-arch-ind: anchor (index

(Buiding by Architect(self)))

0..* designs 1..*

Figure 3 – The navigation class schema for the architecture application

Figure 3 shows the navigation class schemafor the architecture example. Navigation classes(called nodes) are denoted as classes, with asquare box on the top right corner. Notice thatmulti-valued attributes in the conceptualschema have been mapped onto differentnavigation class attributes.

This design also shows an example where thenavigational class (node) “Building” is actuallya view over conceptual classes “Building” and“Building Category”. It includes an attribute“Category”, whose value is taken from the“name” attribute of the “Building Category”conceptual class, in addition to all the attributesof the “Building” conceptual class.

4

The implementation of this functionalitydepends on the target implementationenvironment; in a full object-oriented system,nodes will contain a method that returns thebuilding’s category by collaborating with thecorresponding object. In a hybridimplementation, the architect’s name will beimplemented in the building’s node (and in itscorresponding interface).

A schema specifying navigational classesdefines the navigational domain of ahypermedia application. In OOHDM, there is aset of pre-defined types of navigational classes:nodes, links, anchors and access structures. Thesemantics of nodes, links and anchors are theusual in hypermedia applications. Accessstructures, such as indexes, represent possibleways for starting navigation.

In the same way as navigation objects, linksreflect conceptual relationships intended to beexplored by the final users. Differentapplications (over the same domain) maycontain different linking topologies accordingthe user’s profile. For example, the architecturewebsite could include the building categoryinfo for experts in the field, and not include thisinformation for casual users.

Once the navigation classes have been decided,it is necessary to structure the navigation spacethat will be made available to the user. InOOHDM, this structure is defined by groupingnavigation objects into sets called contexts. Eachcontext definition includes: the elements itcontains; the specification of its internalnavigation structure; an entry point; accessrestrictions in terms of user classes andoperations; and associated access structures.

There are six different ways to define contexts:

1. Simple class derived – includes all objects ofa class that satisfy some property; e.g., “buildings with address = Rio de Janeiro”. Avariant of this type is the query-basedcontext, where the user defines the propertyat navigation time.

Graphically:

2. Class derived group – is a set of simpleclass derived contexts, where the definingproperty of each context is parameterized;e.g. “building by location” (location canvary).

Graphically:

3. Simple link derived – includes all objectsrelated to a given object; e.g., “buildingsdesigned by Oscar Niemeyer”. Graphically,same as 1.

4. Link derived group - a set of link derivedcontexts, each of which is obtained byvarying the source element of the link; e.g.“buildings designed by architect” (architectvaries). Graphically, same as 2.

5. Arbitrary - is an enumerated set; e.g., aguided tour. Graphically, same as 1

6. Dynamic - is a set where the elementschange during navigation; e.g., history,shopping basket.

Graphically:

In any of the above, if there is an accessstructure defined for it, the correspondinggraphical notation contains a small black squarein the upper left corner.

Associated to the contexts, there are accessstructures (indices). They are denotedgraphically by:

Simple Index:

Dynamic Index:

Index with multipleorderings:

The navigation structure of theapplication is defined in a context diagram,which shows all the access structures andcontexts defined for this application, and thepossible navigations between them. Figure 4shows the context diagram for the architecturesite.

5

\ Architect

By name

Main Menu

Timeline

Buildings

Architects

Categories

Building

By architect

By category

By year

By name

Figure 4 – The context diagram for the architecture website

According to this diagram, the application’smain menu has four indices:

Architects allows access to an alphabeticallist of architects, which can betraversed in some order

Timeline allow access to buildings,grouped by years

Buildings allows access to buildings,grouped by name.

Categories allows access to buildings bycategories (monuments, hotels,convention centers, etc…)

In addition, buildings can also be groupedaccording to the architect that designed them.This context can only be accessed from othercontexts, such as architects.

It should also be noted that, when looking at abuilding in any of the contexts, it is possible to“switch” context. For example, while looking ata building by a certain architect, it is possible tonavigate to the “next building in the samecategory”, regardless of its architect.

Once contexts have been defined, it is possibleto extend the definition of navigation classes byspecifying “decorators”, i.e., attributes that areonly visible when an object is accessed within agiven context. Such attributes are defined in“InContext” classes.

2.3 Abstract Interface DesignIn the Abstract Interface Design activity, wespecify which interface objects the user will

perceive. It should be recognized that there is adistinction between navigation operations andinterface operations; not everything thathappens in the interface is navigation related.Furthermore, it is useful to design interfaces atan abstract level, to achieve, among otherthings, independence of implementationenvironment.

The Abstract Interface Specification includes theway in which different navigational objects willlook like, which interface objects will activatenavigation, the way in which multimediainterface objects will be synchronized andwhich interface transformations will take place.

User interface design is a critical activity ininteractive applications, including hypermedia.Though objects have been used for years in thefield of user-interface design, the focus has beenmainly applied to the software substrate (as forexample the MVC paradigm [Krasner88]) andnot to the specification of contents.

In OOHDM, we use the Abstract Data View(ADV) design approach for describing the userinterface of a hypermedia application[Cowan95]. Abstract Data Views are formalmodels of interface objects and they arespecified by showing:

a-The structural, static aspects of the interfaceobjects using composition.

b-The way in which they are statically relatedwith navigation objects (the Abstract DataObjects – ADOs – in the original formalism). Weuse Configuration Diagrams [Coleman92] forexpressing these relationships. An ADV isrelated with a corresponding application object,

6

which acts as a behavioral server for thoseoperations not specific to the interface. Thisobject is called the ADV owner and it is similarto the model object in the well-known model-view-controller object-oriented interfaceparadigm.

c-How they behave when reacting to externalevents; in particular, how they triggernavigation, and which interface transformationsoccur when the user interacts with theapplication. We use ADV-charts [Carneiro94], aderivative of Statecharts, that adds bothstructural and behavioral nesting and a Petri-Net like notation for expressingsynchronization issues usually found whendealing with multimedia data.

Implementation of ADVs in the WWW isdiscussed in the next section.

2.4 ImplementationIn this phase, the designer will actuallyimplement the design. Up to now, all modelswere deliberately constructed in such a way asto be independent of the implementationplatform; in this phase the particular runtimeenvironment is taken into account. We willbriefly indicate how OOHDM designs can beimplemented in the WWW by looking at oneparticular approach we have followed.

Although OOHDM is cast in terms of OOmodels, it does not require an OOimplementation environment; animplementation based on an OODMBS (O2)(but not on the web) is described in [Milet 96];Java-based implementations are underdevelopment.

We have designed and implemented anenvironment based on the scripting language

Lua [Ierusalimschy 96] and on the CGILuaenvironment [Hester 97] called OOHDM-Web[Pontes97, Schwabe 98a]. This environmentimplements templates that are a mixture ofplain HTML and calls to functions in a librarygiving access to the Navigation objects stored ina relational database, accessed via ODBC. Itshould be noted that, in this approach, the ADVis implemented by a combination of HTMLtemplates whose structure must be compatiblewith the ADV’s structure, and whose behavioris represented as calls to library functions in theLua/CGILua/OOHDM-Web environment.There is currently no support to automaticallyderive these templates and calls from theADV/ADV Charts specifications.

The OOHD-Web environment has threeinterfaces, all implemented using thiscombination of tools, discussed in greater detailin the next section. We have chosen the CGILuaenvironment mainly for reasons of portability(it is available for Windows and Unixenvironments), availability - it is free, andtherefore OOHDM-Web can be freelydistributed – and because it is based on a veryelegant, full fledged programming language. Inspite of this, it should also be clear that thisapproach could easily be reproduced using anyof the alternative commercially availableenvironments such as Cold Fusion or ASP.

3. The OOHDM-Web environment

The general architecture of OOHDM-Web isshown in Figure 5. Through the first interface,the designer defines the Navigation Schemaand the Interface templates, generating thedatabase definitions. Through the secondinterface, the designer can populate thedatabases with instance data, or make changesto existing data. Through the third, usersbrowse the resulting site.

7

HTML Pages

Browser

Interface Appearance OOHDM Navigation Schema

OOHDM-WebBrowsing

Environment

- Tables describingnavigation classes

- Tables describing contexts

Templatesmixing HTML

withcommands

usingOOHDM-Web

libraryfunctions and

CGI-Lua

HTTP Server

OOHDM-WebAuthoring

Environment

- Tables with instance data(nodes and contexts)

OOHDM-WebMaintenanceEnvironment

Figure 5 - The structure of the OOHDM-Web Environment

The first interface, the Authoring Environment,is currently under construction, and will havethree modes: graphical, forms-based, andtextual. The graphical interface allows directtranslation of schema diagrams, plusinformation entered via inspectors, into tabledefinitions. The forms-based interfaces achievethe same result by presenting several formsthrough which the designer can describe thedesign. The textual interface simply reads adescription of the design in a stylized notation.We will concentrate on the other interfaces, thebrowsing and maintenance environments.

When the implementation phase is reached, thedesigner has already defined the informationitems that are part of the problem domain. Healso has identified how these items should beorganized according to the user’s profile andtasks; he has decided what the interface willlook like, and how it will behave. In order toimplement all of this in the WWWenvironment, the designer has to decide howthe information items (both conceptual andnavigation objects) will be stored (see, forexample, [Varela 95, Hunter 95]). He must alsodecide how the interface appearance andbehavior will be realized using HTML andpossibly use some extensions. Notice that, ingeneral, the actual appearance will be definedby a graphics design professional that should bepart of the design team.

As previously said, the browsing interface isimplemented through HTML templates thatmix plain HTML tags with calls to functions inthe OOHDM-Web library. Before describingthese templates and functions, it is necessary toexplain how the information items in the designare represented in the environment. Thesefunctions will access this representation toretrieve the appropriate values for theinformation items to be displayed in thebrowser.

3.1 Representing the DesignMapping Information Items. The informationitems (which correspond to the ADOs in theAbstract Interface Model) may be stored in filesor in a database. Due to the nature andcomplexity of the types of applications forwhich OOHDM is most suited, we stronglyrecommend using a database to store theConceptual and Navigation objects. Since themajority of DBMSs available on the markettoday are relational, a mapping of the OOmodels onto equivalent relational models mustbe made. There are several techniques andheuristics for doing this – see for example,[Keller 97]. The methods associated with theclasses are implemented as a set of proceduresthat access the database to perform theircomputations.

In section 3, it was stated that the NavigationModel is a view over the conceptual model. The

8

designer has the option of reflecting thisorganization in the databases corresponding toeach model. In other words, he may define thedatabase containing the Navigation objects(nodes, links, etc...) as a view, supported by theDBMS, of the database corresponding to theconceptual model. In the case where the DBMSdoes not directly support the view mechanism,or for efficiency reasons, the designer has theoption of computing the view by hand. In thiscase, he will only implement the Navigationmodel, since it is the one the user will beaccessing.

Implementing views in the DBMS is usefulwhen companies already have corporate DBs,and want to use it as the basis for sites in theWWW or in Intranets. In such cases, the DBschema of the existing database should be taken

as the Conceptual Model, over which theNavigation Classes are defined.

OOHDM-Web assumes the view has beentranslated by hand, and takes the approach thatmaps each class in the OO (navigation) modelto be implemented onto a table, where eachcolumn stores an attribute, and each rowcorresponds to an object of that class. All suchclass tables must have a distinguished attributenamed “key”, which will, by definition, be usedas the table’s key field. If there are multi-valuedattributes, these are stored in a separate table,and a key for each value is stored in the originalclass table, in the appropriate column.

As an example, the tables corresponding to the“Architect” and “Building”, as well as the“designed” (called “build_arch”) relation classis shown in Figure 6.

architect

#key architect_name photo1 Lúcio Costa costa.gif2 Oscar Niemeyer niemeyer.jpg

building

#key building_name date building_photo address13 Hotel Sheraton 1978 sheraton.jpg Av. Niemeyer, 1217 Hotel Nacional 1968 nacional.jpg Av. Niemeyer 76919 Sede do Banco Aliança 1956 alianca.jpg Praça Pio X, 99

build_arch

architect_key building_key2 72 194 13

Figure 6 – Tables defining classes “Architect”, “Building” and relation “designed”

In addition to class tables, the designer may alsospecify InContext classes, which arerepresented by separate tables, not detailedhere.

Implementing Contexts. To support contexts, theunderlying database model or set of files mustalso contain their definitions. With theexception of arbitrary contexts (whosespecification is essentially an enumeration of itsmembers), other types of contexts include aquery or function specification that must beevaluated to compute the members of thecontext.

OOHDM-Web defines 6 tables that describe allcontexts in a design. There is one table called“context” which has two columns, the first witha context name, and the second with its type (1through 5, according to the types described in

section 2.2). For our example, this table wouldbe

context

#ctx_name typebuilding_alpha 1building_by_year 2building_architect 5

where:

ctx_name is the name that identifiesthe context, given by theuser

type identifies the kind ofcontext. The possiblevalues are:1 for simple class derived;2 for class derived groups;3 for arbitrary;4 for simple link derived;5 for link derived groups.

Figure 7: The table “context” for theexample.

9

Each of the five different types of context has adifferent type of table describing itsoccurrences. Thus, each context present in thedesign will have a tuple in the appropriatetable, depending on its type.

For example, “class derived groups” (type 2)are defined by the context table presented inFigure 8 (a)

Field Contentsctx_name Is the context nameclass_name class to which the elements belongclass_atr Attribute of class 'class_name' whose value is used

to select the elements to include in the contextorder Attribute of class 'class_name' used to sort the

elements in this contexttarget_page HTML template used to present elements in this

contextnav_type Specifies the possible navigation beween elements

in this context. Possible values are: 'sequential','circular', 'free' or 'index'.

(a)

type2

#ctx_name class_name

class_atr

order target_page

nav_type

building_by_year building date building_name build_yr.html sequential

(b)

Figure 8 – (a) Table implementing “classderived groups” (type 2), and (b) A row

in this table representing the context“building by year”

The context “building by year” would bedefined by the row in this table, shown inFigure 8 (b).

As a second example, a table as illustrated inFigure 9 can be used to represent link-derivedgroups of contexts. With this table defined, oncesuch context, for example, “Building byArchitect” , can be described by a tuple, alsoshown in Figure 9

Field Description

#Context Name Name identifying the context

Relation Table Name of table representing thelinks

SourceClass Class to which the source elementsof the link belongs

DestinationClass

Class to which the destinationelement of the link belongs

SourceField Field in the relation table used toselect the source element

DestinationField Field in the relation table used toselect the destination element

Dest. TargetPage

Name of the template page used toshow the elements of the context

Navigation Type Type of navigation allowed in thecontext

Source TargetPage

Name of the template page used toshow the elements that are thesource of the link

Source Context Name of the context that is formedby the sources of the links

type5

#ctx_name RelationTable SourceClass DestinationClassbuild_arch rel_arch_build architect building

. . . SourceField DestinationField Dest.TargetPagearch_key build_key build_arch.html

. . . NavigationType SourceTargePage SourceContextcircular arch.html arch_alpha

(b)

Figure 9: Table implementing a “LinkDerived Context Group” (type 5), and an

example tuple describing “Building byArchitect”.

Navigation operations within contexts requirekeeping state information. For example, todetermine “what is the next building by thisarchitect” requires knowing which building theuser is currently looking at, which projectsmake up the referenced context (“Buildings byarchitect”), and what is the ordering defined forthat context. This information is handled byfunctions provided by the OOHDM-Weblibrary, using state maintenance facilities in theCGI Lua environment.

3.2 Implementation of theBrowsing Environment.The actual interface organization and behavioris specified in the ADVs, and the physicallayout and appearance must be defined in thisphase. The implementation of ADVs requiresdefining page layouts in HTML that areconsistent with the ADV specifications. In thosecases when the values of instance variables arecomputed at runtime, pages must be generated

10

dynamically, based on HTML templatespreviously specified by the designer.

These templates usually contain a mixture ofHTML code and calls to functions in theOOHDM-Web library. The execution of thesefunctions will retrieve or compute the instancedata, to fill in the missing data that makes upthe final HTML page. This is achieved using theCGI Lua environment. It should be stressed thatall pages in the application will be either(arbitrary) static pages, or pages thatcorrespond to an index (access structure), orpages that show some attributes of objectswithin a given context.

For example, the OOHDM-Web function callbelow, which is an expression the LUAprogramming language, when embedded aspart of an HTML page, produces an index of“Buildings”in alphabetical order of their names,organized as a 2-column horizontal table.

Index {context = “build_alpha”, ,anchor=”building_name”, function‘Horizontal_Tab(col = 6; par_table= align-center cellspacing = 12 ,par_cel= <center> ) ’}

Functions “Index” and“Horizontal_Tab” are part of the OOHDM-Web library. The corresponding generatedpage, as seen by the user, is shown in Figure10.

Figure 10 – An index page to the“building_alpha” context (buildings in

alphabetical order)

Another example of use of this function is thecall below, which generates an index to thecontext “buildings by architect OscarNiemeyer” (“cgi.inst” is a variable of the CGILua environment that stores the id of thecurrent object, in this case an “architect”):

Index {context = ’build_arch’, group= “Oscar Niemeyer”, DestAnchor =‘name’, SourceAnchor=‘name’,function = ‘Horizontal_Tab(col = 2;par_table = BORDER=1)’}

The corresponding generated page, asseen by the user, is shown in Figure 11.

Figure 11 – The index to context“build_arch” = “Oscar Niemeyer””

(Buildings by architect Oscar Niemeyer)

In any of these indices, if the userchooses the building “Hotel Nacional”, he willnavigate to a page that shows an instance of“Building”, which is built through the templateshown in Figure 12. This figure also shows theactual page seen by the user.

11

Figure 12 – The template “build_arch.html”, which is used to show “buildings” in thecontext “Building by Architect” (see Figure 9).

Figure 13 – The page generated by the template “build_arch.html”, for the instance“Hotel Nacional”.

It should be noted that this example usesthe “PrevLink”, “NextLink” and “Atrib”library functions, applied to the current (“HotelNacional”) object. As shown in the examples,the templates may reference any Luaexpression. In order to allow the designer toabstract from implementation details, theOOHDM-Web environment provides functions

that enable the manipulation of the designelements without requiring knowledge of howthe information is actually stored. Thefollowing functions are defined in theOOHDM-Web library.

12

Function DescriptionIndex Generates an index (a structure with links) to

all elements in a given context. There areseveral kinds of indexes that can begenerated, depending on the type of context.

Attrib Retrieves the value of an attribute of a givenobject, when seen from within a givencontext. Notice that, depending on thecontext, attributes belonging to InContextclasses may be visible (accessible).

NextLink Generates a reference to the next element (tothe one represented by the page where thiscall appears) in the current context

PrevLink Generates a reference to the previouselement in the context

FirstLink Generates a reference to the first element inthe current context

LastLink Generate a reference to the last element inthe current context

In addition, there are formattingfunctions that take lists of references andgenerate various kinds of HTML tabledefinitions, with the elements of the suppliedlist inserted into individual table cells. Suchfunctions are useful as they relieve the designerfrom dealing with error-prone details.

3.3 Implementation of theMaintenance Environment

Since the complete design is described inthe OOHDM-Web tables and page templates, itis also possible to automatically derive browserinterfaces that allow the designer (or others) toenter instance data that will be perused byusers. This interface is forms-based, and againalleviates the designer from having to know allthe particular details of how objects are stored.Figure 14 show an example form to inputinstance data for class “Building”.

Figure 14 – A form to input instance datafor class “Building”. Notice the possibility

to specify links to “architects” via thecheckboxes at the bottom.

The environment also allows the user to checkthe design, by providing summary screens withinformation about classes and contextsspecified. This can be seen in Figure 15.

Figure 15 – Summary screen showingclasses and context defined in a design.

4. Conclusions

The combination of a powerful designmethodology with a template-basedenvironment allows the rapid developmentand deployment of sophisticated websites. Thedesigner can concentrate on the design byexpressing it in a high-level language, and hasan easy path to convert this design into aworking application.

We are currently extending OOHDM-Web (and OOHDM) in various directions. Thefirst class of extensions aims at supportingother primitives in OOHDM, such as therecently introduced primitives of user classesand access restrictions for contexts.

Another important direction beingexplored is the ability to “pre-compute” a site,either partially or completely. In the situationsin which all instances of objects are knownbefore deployment, it might be moreconvenient to pre-generate all pages, and storethe entire site as static pages. Clearly, this isonly interesting when the update frequency islow enough. In other cases, even if the site as awhole contains sections that cannot be pre-computed (e.g., search forms, or any form withdata input by the reader during navigation), itmight still be possible to pre-compute at least aportion of the site. We are currentlyimplementing this functionality into OOHDM-Web.

The CGI Lua environment has provenadequate in terms of functionality andperformance, for the several applications that

13

have already been developed and deployedwith OOHDM-Web. It is being upgraded tofunction as an API directly with the HTTPserver, in order to avoid inherent inefficienciesof the CGI architectures.

In order to be able to fully understandthe interplay between design methodologiesand website implementations, we have alsodeveloped a Java-based framework thatprovides similar functionality to OOHDM-Web, using Servlets [Pizzol 98]. Althoughrequiring a greater level of programming onthe part of the designer, this approach mightprove more flexible and efficient. We will beexperimenting with this environment, andcomparing both approaches.

5. References

[Carneiro 94] Carneiro, L.M.F.; Coffin, M.H.;Cowan, D.D.; Lucena, C.J.P.L; “ADVCharts:a Visual Formalism for Highly InteractiveSystems”, in M.D. Harrison, C. Johnson,eds., Software Engineering in Human-Computer Interaction, CambridgeUniversity Press, 1994.

[Coleman92] D. Coleman; F. Hayes; S. Bear,“Introducing Objectcharts or How to useStatecharts in Object-Oriented Design”,IEEE Transactions on Software Engineering,18(1), 9-18, January 1992.

[Cowan95] D. D. Cowan; C. J. P. .Lucena,“Abstract Data Views, An InterfaceSpecification Concept to Enhance Design forReuse”, IEEE Transactions on SoftwareEngineering, Vol.21, No.3, March 1995.

[Gamma95] Gamma, R. Helm, R. Johnsonand J. Vlissides: “Design Patterns: Elementsof reusable object-oriented software”,Addison Wesley, 1995.

[Garzotto93] F. Garzotto, D. Schwabe and P.Paolini: “HDM - A Model Based Approachto Hypermedia Application Design”. ACMTransactions on information Systems, 11 (1),Jan. 1993, pp. 1-26.

[Hester 97] A.M. Hester; R.C.Borges; R.Ierusalimschy; “CGILua: A Multi-Paradigmatic Tool for Creating DynamicWWW Pages”, Proceedings of the XIBrazilian Software Engineering Symposium(SBES’97) pp.347-360, Fortaleza, Brazil, 1997(available at http://www.tecgraf.puc-rio.br/~anna/ cgilua/cgilua.ps.gz)

[Hunter 95] A. Hunter, I. Ferguson, S.Hedges: “Swoop: An application generatorfor Oracle/WWW Systems”. Proceedings ofthe Fourth International World Wide WebConference. pp. 185-194, 1995.

[Isakowitz95] T. Isakowitz, E. Stohr and P.Balasubramanian. “RMM: A Methodologyfor Structured Hypermedia Design”.Communications of the ACM 38 (8), 1995,pp. 34-44.

[Ierusalimschy 96] R. Ierusalimschy, L. H.de Figueiredo and W. Celes, “Lua - anextensible extension language”, Software:Practice & Experience 26 #6 (1996) 635-652.(see also http://www.tecgraf.puc-rio.br/lua/).

[Keller 97] Keller, W.; “Mapping Objectsto Tables – A Pattern Language”, Proc. OfEuropean Conference on Pattern Languagesof Programming Conference(EuroPLOP)’97, Bushman, F. and Riehle, D.;(eds.), Irsee, Germany, 1997.(http://www.sdm.de/g/arcus/publicat/index.phtml# Mapping_Objects_To_Tables)

[ Kim 94] W. Kim, “Advanced Databasesystems”, ACM Press, 1994.

[Krasner 88] G. Krasner, S. Pope. “ Acookbook for using the model-view-controller user interface paradigm inSmalltalk-80”. Journal of Object-Orientedprogramming, 1(3), pp. 26-49,August/September, 1988.

[Lowe 96] D. Lowe, A. Ginige, M. Sifer, J.Potter, "The MATILDA Data Model and itsImplications", 3rd International Conferenceon Multimedia Modelling, November 12-15,1996, Toulouse, France

[Milet 96] J.Renato Milet; D. Schwabe; R.S. G. Lanzelote, “Hypermedia ApplicationAuthoring Using Object OrientedDatabases”, Proc. of the XI BrazilianSymposium on Databases (SBBD), SBC, SãoCarlos, Oct. 1996 (in Portuguese).

[Pizzol 98] Pizzol, A.M.; “A JavaFramework for Implementation ofHypermedia Applications using OOHDM”,MSc. Thesis, Dept. of Informatics, PUC-Rio,Dec. 1998. (in Portuguese).

[Pontes 97] Pontes, R.C.A., “AnEnvironment to Support Hypermedia

14

Applications in the WWW”, MSc thesis,PUC-Rio, 1997 (in Portuguese).

[Rossi 96] G. Rossi: “An Object-OrientedMethod for Designing HypermediaApplications”. PHD Thesis, Departamentode Informática, PUC-Rio, Brazil, July 1996(in Portuguese).

[Rumbaugh 91] Rumbaugh, M. Blaha, W.Premerlani, F. Eddy and W.Lorensen:“Object Oriented Modeling and Design”,Prentice Hall Inc. 1991.

[Schwabe 95] D. Schwabe and G. Rossi:,“The Object Oriented Hypermedia DesignModel”, Comm. of the ACM, Vol. 38, #8,pp45-46 Aug. 1995. (available at<http://irss.njit.edu:5080/cgi-bin/bin/option.csh?sidebars/schwabe.html>).

[Schwabe 96] Schwabe, G. Rossi and S.Barbosa: “Systematic Hypermedia Designwith OOHDM”. Proc. of the ACMInternational Conference on Hypertext(Hypertext'96), Washington, March 1996.

[Schwabe98a] Schwabe, D.; Pontes, R.A.;“Rapid Prototyping of HypermediaApplications in the Web”, Tech. ReportMCC 08-98, Dept. de Informática, PUC-Rio,1998. Available at ftp://ftp.inf.puc-rio.br/pub/docs/ techreports/98_08_schwabe.pdf.gz

[Schwabe 98b] Schwabe, D.; Rossi, G.; “AnObject Oriented Approach to Web-BasedApplication Design”, Theory and Practice ofObject Systems 4 (4), J. Wiley, 1998

[UML 97] UML Document Set. Version1.013 January, 1997, Rational, 1997.(available at http://www.rational.com/uml/references/index.html)

[Varela 95] C. Varela, D. Nekhayev, P.Chandrasekharan, C. Krishnan, V.Govindan, D. Modgil, S. Siddiqui, , D.Lebedenko, M. Winslett: “DB: BrowsingObject-Oriented Databases over the Web”.Proceedings of the Fourth InternationalWorld Wide Web Conference. pp. 209-220,1995.