Developing Hypermedia Applications using OOHDM

Daniel Schwabe* and Gustavo Rossi** (*)Departamento de Informtica. PUC-RIO, Brazil E-mail: schwabe@inf.puc-rio.br (**)LIFIA, Fac Cs. Exactas, UNLP, Argentina; CONICET; UNLM E-mail: gustavo@sol.info.unlp.edu.ar

Abstract
In this paper we discuss the use of an object-oriented approach for hypermedia applications design, including web-based, based on the Object Oriented Hypermedia Design Method (OOHDM). We first motivate our work discussing the problems encountered while designing large scale, dynamic web-based applications, which combine complex navigation patterns with sophisticated computational behavior. We argue that a method providing systematic guidance to design is needed. Next, we introduce OOHDM, describing its main activities, namely: conceptual design, navigational design, abstract interface design and implementation, and discuss how OOHDM designs can be implemented in the WWW. Finally, related work and future research in this area are further discussed.

1. A Brief Overview of OOHDM

The Object-Oriented Hypermedia Design Method is a model-based approach for building large hypermedia applications. It has been used to design different kinds of applications such as: web sites and information systems, interactive kiosks, multimedia presentations, etc. OOHDM comprises four different activities namely, Conceptual Design, Navigational Design, Abstract Interface Design and Implementation. They are performed in a mix of incremental, iterative and prototype-based development styles. During each activity a set of object-oriented models describing particular design concerns are built or enriched from previous iterations. As we explain below, treating conceptual, navigational and interface design as separate activities allows us to concentrate on different concerns one at a time. As a consequence we get more modular and reusable designs, and we obtain a framework to reason on the design process, encapsulating design experience specific to that activity. Besides, the interface design primitives can be easily mapped to non object-oriented implementation languages or environments (such as HTML or Toolbook) and thus OOHDM can be used regardless of whether the target system is a pure object-oriented environment one or a hybrid one (as those we usually find in the Internet). In Figure 1 we show a sketch of the activities in OOHDM and in Figure 2 we briefly describe OOHDM activities, primitives, concerns and abstraction mechanisms (an extension of the one shown in [Schwabe 95]).

Figure 1: OOHDM design models Activities Products Formalisms Mechanisms Design Concerns
Model the semantics of the application domain

Conceptual Modeling

Classes, subsystems, relationships, attribute perspectives

Object-Oriented Modeling constructs (classes, relationships, use cases) Object-Oriented Views Object-Oriented State charts Context Classes User centered Scenarios Design Patterns

Classification, aggregation, generalization and specialization

Navigational Design

Nodes, links, access structures, navigational contexts, navigational transformations

Classification Aggregation, generalization and specialization

Users profile and task. Emphasis on cognitive aspects.

Abstract Interface Design

Abstract interface objects, responses to external events, interface transformations

Abstract Data Views Configuration Diagrams ADV-Charts Design Patterns

Mapping between navigation and perceptible objects. Composition and generalization/ specialization

Model perceptible objects, implementing chosen metaphors. Describe interface for navigational objects Define lay-out of interface objects Performance, completeness

Implementation

Running application

Those supported by the target environment

Those provided by the target environment

Figure 2: Summary of the OOHDM Methodology

In the next sections, we describe each phase in more detail.

2. Conceptual Modeling
During Conceptual Design a model of the application domain is built using well known object-oriented modeling principles, with a notation similar to UML. The product of this step is a class schema built out of Sub-Systems, Classes and Relationships. The major differences with UML are the use of multiple-valued attributes, and the use of directions explicitly in the relations Conceptual classes may be built using aggregation and generalization/ specialization hierarchies. 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. If the application involves operations on those objects as in dynamic Web-applications, the conceptual model will evolve into an object model that will be implemented in the target environment (for example in a W W W server). In this case, navigation objects will act as observers [Gamma95] of these application objects. OOHDM does not prescribe any particular method to produce the Conceptual Class Schema; any of the well known methodologies (OMT, UML) may be employed. Figure 3 shows a Conceptual Schema for the Academic Department Web site. Perspectives (multiple valued attributes) are denoted by enumerating the possible types, with a + next to a default type. Thus, description: [text+, image] means attribute description has a text perspective (always present), and may have also a photo perspective.

belongs produces Sponsor Name: string UrlSponsor: string

0..N 0..N 0..N

Laboratory Name: string Description: string

N

Personel Name: string Degree: string Description: [text+, image] Email: string HomePage: string
N

conducted in funds
N

Equipment Name: string

belongs

Research Project
N

Name: string Description: string Budget: real

0..N N N

participates
0..N N

Academic
N

Technical

Administrative
N

Professor
N

advises
Degree: string

N N

Student
N

produces

Students Production OnLineContent: string

belongs Area of Research Name: string Description: string

N 1

Rank: string belongs

1

teaches
N N

Course Offering
N

Semester: string Schedule: string Classroom: string

N

attend pursues
StudentID: integer BeginningDate: date EndingDate: date

Graduation Project
1

Thesis

Evaluation: integer

PhD
1

MSc
1

Complementary Material related OnLineContent: string Location: string offered Slide WorkBook Exercise

belongs

requires
N N

has elective

Degree Name: string RequiresAmount : integer ElectivesAmount : integer

1

Course
0..N N 1 N

belongs

Research Result Title: string PublicationDate: date Abstract: text Autors: set of string

Name: string Description: string NumberOfCredits: integer SuggestedPeriod : string Syllabus : text
0..N

has required
N

Graduate

Undergraduate

requires

0..N

MSc
1

PhD

requires

requires Book Edition: string Publishing: string Technical Report Code: string OnLineContent: string Paper BiblioReference: string OnLineContent: string Software OnLineContent: string Hardware

Conference Paper UrlConference: string

Journal Paper UrlJournal : string

Figure 3: Conceptual Schema of the Academic Department Site

3. Navigational Design
In OOHDM, an application is seen as a navigational view over the conceptual model (see Figure 2). This reflects one of the major innovations of OOHDM, which recognizes that the objects (items) the user navigates are not the conceptual objects, 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 a query language similar to the one in [Kim94], allowing a node to be defined by providing access to attributes of different related classes in the conceptual schema. This view is oriented towards a certain class of users and their respective tasks. Nodes generalize the Observer concept from [Gamma95].

For example, in the conceptual model a research project is linked to its sponsors (a separate class). However, for most classes of users, there is no need to have a separate node describing the sponsor; it suffices to have their respective names and URLs to their sites as a reference. Therefore, in the navigational node corresponding to research project is defined as having two virtual attributes whose values are respectively a list of sponsors names and URLs, mapped from the corresponding attributes of the conceptual class sponsor. The implementation of this functionality depends on the target implementation environment; in a full object-oriented system, nodes will contain a method that returns the sponsors name and URL by collaborating with the corresponding object. In a hybrid implementation, the sponsor's name and URL will be implemented in the sponsors node (and in its corresponding interface). The navigational structure of a hypermedia application is defined by a schema specifying navigational classes. In OOHDM there is a set of pre-defined types of navigational classes: nodes, links, anchors and access structures. The semantics of nodes, links and anchors are the usual in hypermedia applications. Access structures, such as indexes, guided tours, etc represent possible ways of accessing nodes. In the same way as navigation objects, links reflect conceptual relationships intended to be explored by the final users. Different applications (over the same domain) may contain different linking topologies according the users profile. For example an Academic Web site may have a view for use by students and researchers, and another view for use by administrators. In the second view, a professor's node may contain salary information, which would not be visible in the first view.

belongs
N N

conducted in

0..N

Research Project
0..N

Laboratory Name: string Description: string Equipments: set of string PrfsIdx : index (Professor by Laboratory) Sts : anchor( index (Student by Laboratory) ) Prjs : anchor( index (Research Project by Laboratory) )
0..N

Students Production OnLineContent: string

Name: string Description: string Budget: real SponsorNames: list of anchor ( UrlSponsor )
N 0..N

Personel Name: string Degree: string Description: image Bio: text Email: string HomePage: string produces Technical Administrative

Graduation Project
1

Thesis

participates
N N

PhD
1

MSc
1

belongs Academic Rsts : anchor ( index (Research Result + Students Production by Author) ) Prjs : anchor ( index (Research Project by Person) )
N

produces belongs belongs

N N

Professor
N

Student

Rank: string 1 ArsIdx : index (Area of Research by Professor) Crs : anchor ( index (Course Offering by Professor) ) Sts : anchor ( index (Supervised Student by Professor) )
1 1

PrdsIdx: index (Students Production by Student) CrsIdx : index(Course Student by Student)

1 1 1

Area of Research Name: string Description: string PrfsIdx : index (Professor by Area of Research) Crs : anchor ( index (Course by Area of Research) ) Prjs: anchor ( index (Research Project by Area of Research) ) Rsts: anchor ( index (Research Result + Students Production by Area of Research) ) Lbs: anchor ( index (Laboratory by Area of Research) )
N 1

supervised advises
N N

took degree
N

teaches
N

requires

related

Course Offering CourseName: string NumberOfCredits: integer SuggestedPeriod : string ResearchArea: string ProfessorName: string N Semester: string Schedule: string Classroom: string
N

Supervised Student StudentName: string ProfessorName: string Degree: string

1

Degree Student attend StudentName: string DegreeName: string StudentID: integer BeginningDate: date EndingDate: date
N N

enrolled
N

Course Student StudentName: string Semester: string CourseName: string Evaluation: integer

Complementary Material OnLineContent: string Location: String

pursues

belongs

offered

Slide

WorkBook

Exercise Course
1 N

N N

Research Result Title: string PublicationDate: date Abstract: text Autors: set of string

belongs

0..N

Name: string 1 Description: string NumberOfCredits: integer SuggestedPeriod : string N ResearchArea: string Syllabus : text RqsIdx : index (Course by Requirement) Offs : anchor ( index( CourseOfferings by Course) )
0..N 0..N

has elective

Degree Name: string RequiresAmount : integer ElectivesAmount : integer CrsIdx : index (Course by Degree)
1

has required

Graduate

Undergraduate

requires Technical Report Code: string OnLineContent: string Paper BiblioReference: string OnLineContent: string Software OnLineContent: string MSc
1

PhD

requires requires

Book Edition: string Publishing: string

Conference Paper UrlConference: string

Journal Paper UrlJournal : string

Hardware

Figure 4 Navigation Class Schema for the Academic Web site. Note the conversion of relations with attributes into classes (e.g., Professor advises Students on a Degree)

Once the navigation classes have been decided, it is necessary to structure the navigation space that will be made available to the user. In OOHDM this structure is defined by grouping navigation objects into sets called contexts. Each context definition includes, besides which elements are included in it, the specification of its internal navigation structure, an entry point, access restrictions in terms of user classes and operations, and an associated access structure. There are six different ways to define contexts: 1- Simple class derived - all objects of a class that satisfy some property; e.g., professors with rank equal associate. A variant of this type is the query based context, where the property is defined by the user at navigation time. Graphically:

2- Class derived group - a set of simple class derived contexts, where the defining property of each context is parameterized; e.g. professors by rank (rank can vary). Graphically: 3- Simple link derived - all objects related to a given object; e.g., courses taught by professor Smith. Graphically, same as 1. 4- Link derived group - a set of link derived contexts, each of which is obtained by varying the source element of the link; e.g. courses taught, by professor (professor varies). Graphically, same as 2. 5- Arbitrary - is an enumerated set; e.g., a guided tour. Graphically, same as 1 6- Dynamic - is a set where the elements change during navigation; e.g., history. Graphically: Associated to the contexts, there are access structures (indices). They are denoted graphically by: Index: Dynamic Index: Index with multiple orderings: In any of the above, if there is an access structure defined for it, the corresponding graphical notation contains a small black square in the upper left corner. The navigation structure of the application is defined in a context diagram, which shows all the access structures and contexts defined for this application, and the possible navigations between them. Figure 5 shows the context diagram for the academic site.

Supervised Student by Professor

Personel

Personel Category Menu

Professors

Academic Professor

Courses Menu

Courses

Professors

Alphabetic by Laboratory

Current Offerings Offerings for Next Semester

by Research Project by Area of Research

Students

Student Students Alphabetic by Laboratory Employees by Research Project Course Student by Student Research Result + Students Production by Author

Main Menu Course Offering by Semester Enrollment Choices Currents by Professor by Course

Employees

Technical + Administrative Alphabetic

Course Alphabetic by Requirement Courses

by Area of Research
To consult results

Results

by Query Research Project

by Area of Research by Degree

Research Project

Research Projects

Alphabetic by Person by Laboratory

Courses Degree Degree Alphabetic

Degrees Laboratories

by Area of Research Degrees Laboratory Laboratories Alphabetic by Area of Research

Areas of Research

Areas of Research

Area of Research Alphabetic by Professor

Figure 5: The Context Schema for the Academic Department Example

The context diagram does not contain all the information needed to specify all contexts; each context and access structure must be further detailed in a CRC Card such as the one shown in Figure 6 and Figure 7.

Type: dynamic Context: Course Offering Enrollment Choices Attributes: Parameters: <period> Include: co Course Offering | co.inContext(Course Offering by Semester ) Selected(co) not SchedulesConflict(co) Methods: RemoveCourseOffering (co) if Selected(co) not Obligatory(co, <period>) then Context( Course Offering Enrollment Choices ) = Context (Course Offering Enrollment Choices ) - co end_if end RemoveCourseOffering Classes in context: Context changes: Entry points: (1 node default): Any element of the context. Ordering: [ (by Time Slot)+, (by Name) ] Path: To index. Type of context link: Export / Import: Use restrictions: Permission: User: Comments: Group of courses that has been selected during a session to configure a enrollment (organized by name or by scheduling -days of week -). Trace forward: Trace backward:

Figure 6: An example of a CRC Card for a context Access Structure: Offerings for Next Semester Type: class derived Attributes: NameCourse: string, NumberOfCredits: integer; SuggestedPeriod: string; ResearchArea: string; ProfessorName: string Selectors: NameCourse: string Structure: Set ordered Ordering: [ (by CourseName ascending)+, (by NumberOfCredits), (by SuggestedPeriod), (by ResearchArea), (by Professor) ] by NumberOfCredits: ordered by NumberOfCredits asc NameCourse asc by SuggestedPeriod: ordered by SuggestedPeriod asc NameCourse asc by ResearchArea: ordered by ResearchArea asc NameCourse asc by Professor: ordered by ProfessorName asc NameCourse asc Destination: co Course Offering inContext(Course Offering by Semester ) Parameters: Predicate: co Course Offering | co.Semester = next_semester() Comportment: Refined in: Comments: Index of the course offerings to the next semester. Trace backward: Trace forward: Figure 7: An example CRC card for an access structure

Once contexts have been defined, it is possible to extend a class definition with a decorator (see [Gamma 95]), which is called an InContext class. This class adds attributes to an existing class, when accessed from within a specified context. For example, the attribute professors name may be included in projects when 9

accessed within research projects by research area, but not when accessed within context research projects by professor, since the professor's name is implicit. OOHDM itself does not prescribe any particular procedure to synthesize navigation designs. To aid the designer, we have developed a method based on user specified scenarios to guide this process [Gell 98]. According to this method, navigation design proceeds in the following steps (see Figure 8): 1. Determination of user profiles (types of users); identification of user tasks 2. Scenario collection 3. Analysis of scenarios, producing a simple diagrammatic representation of the navigation path described in the scenario. In most cases, in this step the designer has to fill in incomplete information such as implied indexes, missing orderings, exception handling, etc The designer may use Design Patterns to help in this step. A second result of this step is a revision of the preliminary navigation class diagram, as well as a description of how each class used in the scenario is viewed in it. 4. Synthesis of a partial context diagram, specifying navigation in contexts that support the task described in the scenario. Again, design patterns describing known navigation solutions may be employed in this step. 5. Synthesis of final context diagram, through a process of union and amalgamation of partial schemas produced in the analysis of each scenario in step 4. Once this final context diagram has been defined, it also possible to define the navigation class and its InContext classes (decorators). Eventually, a revision of the navigation class schema may be done.

10

Preliminary Navigation Class Schema Scenarios Cenrios Cenrios Scenario Analysis For each scenario: Graphic Para cada cenrio: Esboo grfico, Para cada cenrio: Alternatives; Esboo grfico, sketch; Questions;Questes, Argumentos, Argumentos, Questes, Argumentation; Solues Alternativas e Solutions
Alternativas e Solues

Design Patterns

Refined Navigation Class Schema

Design Patterns

Synthesis of Partial Navigation Schema

For each scenario:Esquema Para cada cenrio: Partial Para cada Context Esquema cenrio: Navigationde contextos de parcial parcial de contextos de Schema, InContext Class navegao, Vises das classes navegao, Vises das definitions for contexts classes nos contextos in nos contextos the scenario

Union of partial solutions

Final Context Schema; Final InContext Class Schema

Revised Navigation Class Schema

Figure 8: Steps in synthesizing navigation design using scenarios

In the table below, we summarize user categories and tasks to be supported in the example. User Class Currents Students
TASK

Find out the information necessary to select classes for enrollment in the coming semester Find out information about a given course being offered Choose an advisor Find out the professors that have taught a given course, and look at the material used in each offering

11

User Class Prospective Students

TASK

Find general information about the department

Choose a potential advisor

Sponsors

Get the status of a project he sponsors

Find out if there is some research of interest that can be sponsored

Find out a known professor, in order to get in touch with him or her. Find out information about a given student Find out a professor to teach a course Find information about the Laboratories Find information about employees Look at the academic production of the department

For each category, one must select representative user(s), and ask them to write a scenario describing how they envisage the system helping them to perform the task. Figure 9 shown an example.
Task: Peruse the required courses for obtaining an undergraduate degree in Computer Science Context: I am a CS student and I want to study the required courses for my degree credits and prerequisites in order to plan which courses I will take next semester. Actions: 1. I look for a Course Structure section, possibly under the Computing Engineering area; 2. I select one course, and I get information on the number of credits, the prerequisite courses and the suggested semester within the course in which it should be taken. Figure 9 An example of a scenario description for the Academic Site.

After collecting scenarios, the designer represents them in a simple graphical notation, to validate it with the user; Figure 10 (a) shows an example. In sequence, he analyses each one of them, looking for missing information. Users 12

All

typically omit several types of details, such as access structures, selection attributes to be used in indexes, orderings, treatment of exceptions, etc The designer can either supply the missing information out of his own understanding of the problem domain, or ask the user, or use a previously seen solution for a similar problem effectively applying a design pattern (see Figure 10 (b)).
Computing Engineering Computing Engineering Courses Course X {Pre-requisites} Suggested semester

(a)
(1) Undergraduate Courses

Undergratuate Courses Computing Engineering

Computing Engineering Course Offerings

(2) Course Offerings CourseX

Course X {Pre-requisites} Suggested semester

(b) Figure 10: (a) Simple graphical representation of a scenario; (b) a revised scenario where missing information has been filled in by the designer

As an example of the use of Design Pattern, consider the following fragment of the Navigation Context Diagram shown in Figure 5. This part of the site supports the enrollment task by providing an index to the courses being offered in the next semester; this index can have multiple ordering of its entries (box with a triangle at left). Once the user has chosen the semester, he can browse the course offerings grouped by semester (for this semester). As the user browses the courses, he can select some to enroll, building the dynamic context enrollment choices (box with black bar at right). This is an instance of the Configuration navigation design pattern, which describes the situation when a user chooses elements from a set, according to some restriction, and can later perform computation with the set of chosen items. A well known use of this pattern is the Shopping Basket found in many websites. More details on the use of Design Patterns for hypermedia applications can be found in [Rossi 97, Rossi 98a].

13

Course Offering

Offering for Next Semester

by Semester

Enrollment Choices

Figure 11: A Navigation Pattern employed in the Academic Web site

4. Abstract Interface Design

In the Abstract Interface Design activity we specify which interface objects the user will perceive. It should be recognized that there is a distinction between navigation operations and interface operations; not everything that happens in the interface is navigation related. Furthermore, it is useful to design interfaces at an abstract level, to achieve, among other things, independence of implementation environment. The Abstract Interface Specification includes the way in which different navigational objects will look like, which interface objects will activate navigation, the way in which multimedia interface objects will be synchronized and which interface transformations will take place. User interface design is a critical activity in interactive applications, including hypermedia. Though objects have been used for years in the field of user-interface design, the focus has been mainly applied to the software substrate (as for example the MVC paradigm [Krasner88]) and not to the specification of contents. In OOHDM we use the Abstract Data View (ADV) design approach for describing the user interface of a hypermedia application [Cowan95]. Abstract Data Views are formal models of interface objects and they are specified by showing: a-The structural, static aspects of the interface objects using composition. b-The way in which they are statically related with navigation objects. We use Configuration Diagrams [Coleman92] for expressing these relationships. An ADV is related with a corresponding application object which acts as a behavioral server for those operations not specific to the interface. This object is called the ADV owner and it is similar to the model object in the well known model-viewcontroller object-oriented interface paradigm. c-How they behave when reacting to external events; in particular how they trigger navigation and which interface transformations occur when the user interacts with the application. We use ADV-charts [Carneiro94], a derivative of Statecharts, that adds both structural and behavioral nesting and a Petri-Net like notation for expressing synchronization issues usually found when dealing with multimedia data.

14

In Figure 12 we show the ADV Professors by Laboratory together with a mock-up of the actual interface.
Professor by Laboratory ADV Professor ADV Back_Lab : anchor ( Laboratory Alfabetic (<laboratory>) ) Next_Prof : anchor( next( Professor by Laboratory ) ) SelectedAnchor() Professor by Laboratory SelectedAnchor() Academic ADV SelectedAnchor() Laboratory Alfabetic

Prev_Prof : anchor( previous( Professor by Laboratory ) )

Personel ADV Results: anchor( index(Results by Producer ) ) Projects: anchor ( index(Research Project by Person) )

Area of Research by Professor

SelectedAnchor() Professor ADV Academic ADV AreasIdx : list of ( anchor( Area of Research by Professor ) ) Courses: anchor ( index(Course Offering by Professor) ) Students: anchor ( index(Supervised Student by Professor) )

Personel ADV PersonelCategoryIdx:list of ( anchor( Personel) ) Name: string Degree:string Bio: text Description: Image Email: anchor(self. Email) HomePage: anchor(self.UrlHomePage)

Figure 12: ADV Professor by Laboratory and its actual interface

See [Schwabe 96, Rossi 96, Schwabe 98b] for further details.

5. Implementation
In this phase, the designer will actually implement the design. Up to now, all models were deliberately constructed in such a way as to be independent of the implementation platform; in this phase the particular runtime environment is taken into account. We will briefly indicate how OOHDM designs can be implemented in the W W W by looking at one particular approach we have followed. 15

Although OOHDM is cast in terms of OO models, it does not require an OO implementation environment; an implementation based on an OODMBS (O2) (but not on the web) is described in [Milet 96]; Java-based implementations are under development. When the implementation phase is reached, the designer has already defined the information items that are part of the problem domain. He also has identified how these items should be organized according to the users profile and tasks; he has decided what the interface will look like, and how it will behave. In order to implement all of this in the WWW environment, the designer has to decide how the information items (both conceptual and navigation objects) will be stored. He must also decide how the interface appearance and behavior will be realized using HTML and possibly use some extensions. Notice that, in general, the actual appearance will be defined by a graphics design professional that should be part of the design team. 5.1.1 Mapping Information Items The information items (which correspond to the ADOs in the Abstract Interface Model) may be stored in files or in a database. Due to the nature and complexity of the types of applications for which OOHDM is most suited, we strongly recommend using a database to store the Conceptual and Navigation objects. Since the majority of DBMSs available on the market today are relational, a mapping of the OO models onto equivalent relational models must be made. There are several techniques and heuristics for doing this see for example, [Keller 97]. The methods associated with the classes are implemented as a set of procedures that access the database to perform their computations. One mapping alternative that can be used maps each class in the OO model to be implemented onto a table, where each column stores an attribute, and each row corresponds to an object of that class. The database key can be a distinguished attribute, or an internal identifier can be generated. In section 3 it was stated that the Navigation Model is a view over the Conceptual model. The designer has the option of reflecting this organization in the databases corresponding to each model. In other words, he may define the database containing the Navigation objects (nodes, links, etc...) as a view, supported by the DBMS, of the database corresponding to the Conceptual model. In the case where the DBMS does not directly support the view mechanism, or for efficiency reasons, the designer has the option of computing the view by hand. In this case, he will only implement the Navigation model, since it is the one the user will be accessing. Implementing views in the DBMS is useful when companies already have corporate DBs, and want to use it as the basis for sites in the WWW or in Intranets. Once the databases are defined, they must be integrated in the W W W environment. There are many ways in which this can be done [Hunter 95, Varela 95], and we will not elaborate this further; it suffices to say that any of these techniques may be employed. In this respect, the criteria for choosing the integration method are the same as other applications, as discussed in the literature. 16

5.1.2 Implementing Contexts To support contexts, the underlying database model or set of files must also contain the their definitions. With the exception of arbitrary contexts (whose specification is essentially an enumeration of its members), other types of contexts include a query or function specification that must be evaluated to compute the members of the context. Navigation operations within contexts require keeping state information. For example, to determine what is the next paper by this author requires knowing which paper the user is currently looking at, which papers make up the referenced context (Papers by author), and what is the ordering defined for that context. 5.1.3 Implementation of the Interface The actual interface organization and behavior is specified in the ADVs, and the physical layout and appearance must be defined in this phase. The implementation of ADVs requires defining page layouts in HTML that are consistent with the ADV specifications. In those cases when the values of instance variables are computed at runtime, pages must be generated dynamically, based on HTML templates previously specified by the designer. These templates usually contain a mixture of HTML code and calls to functions in some scripting language. The execution of these functions will retrieve or compute the instance data to fill in the missing data that make up the final HTML page. We have designed and implemented an environment based on the scripting language Lua [Ierusalimschy 96] and on the CGILua environment [Hester 97] called OOHDM-Web [Pontes97]. This environment implements templates that are a mixture of plain HTML and calls to functions in a library giving access to the Navigation objects stored in a relational database, accessed via ODBC. Figure 13 contains a schematic representation of the architecture of the OOHDM-Web environment.
Interface Appearance OOHDM-Web Environment OOHDM Navigation Schema

Template mixing HTML with commands using OOHDM-Web library functions and CGI-Lua

HTML Pages

- Tables describing navigation classes - Tables identifying contexts - Tables describing contexts

HTTP Server

Browser

Figure 13 - The structure of the OOHDM-Web Environment

17

More details about OOHDM Web can be found in [Pontes 97, Schwabe 98a].

6. Conclusions
We are now pursuing several lines of research, as outgrowth or continuation of the research reported here: development of a rich and dense set of design patterns that will allow complete designs to be expressed almost entirely in terms of pattern compositions and instantiations; development of a direct manipulation language that will allow rapid prototyping of interface specifications for HTML documents; design and implementation of a set of tools that will constitute a development environment based on OOHDM, for web-based applications, so that designers are able to deal with entire sites at the more appropriate level of abstraction; a first component in this environment is OOHDM-Web; design and implementation of a Java-based substrate to support direct implementation of OOHDM designs; extension of OOHDM to incorporate user models and tasks, a security model and definition of dynamic contexts; a first definition can be found in [Gell 98]. extension of OOHDM to support groupware, and investigation on support for distributed group authoring using OOHDM.

Acknowldedgment: We would like to thank Natacha Gell Barroso and Patricia Vilain for their help in preparing the example. Daniel Schwabe is partially supported by a grant from CNPq;

7. References
[Bieber95] [Carneiro 94] M. Bieber; C. Kacmar, Designing Hypertext Support Applications, Comm ACM, August 1995, pp. 99-107. for Computational

Carneiro, L.M.F.; Coffin, M.H.; Coewan, D.D.; Lucena, C.J.P.L; ADVCharts: a Visual Formalism for Highly Interactive Systems, in M.D. Harrison, C. Johnson, eds, Software Engineering in Human-Computer Interaction, Cambridge University Press, 1994. D. Coleman; F. Hayes; S. Bear, Introducing Objectcharts or How to use Statecharts in Object-Oriented Design, IEEE Transactions on Software Engineering, 18(1), 9-18, January 1992. D. D. Cowan; C. J. P.Lucena, Abstract Data Views, An Interface Specification Concept to Enhance Design for Reuse, IEEE Transactions on Software Engineering, Vol.21, No.3, March 1995. Gamma, R. Helm, R. Johnson and J. Vlissides: Design Patterns: Elements of reusable object-oriented software, Addison Wesley, 1995. Gell B., N; User centered design of hypermedia applications, MSc thesis, Dept. of Informatics, PUC-Rio, 1998 (in Portuguese). A.M. Hester; R.C.Borges; R. Ierusalimschy; CGILua: A Multi-Paradigmatic Tool for Creating Dynamic WWW Pages, Proceedings of the XI Brazilian Software Engineering Symposium (SBES97) pp.347-360, Fortaleza, Brazil, 1997 (available at

[Coleman92]

[Cowan95]

[Gamma95] [Gell 98] [Hester 97]

18

http://www.tecgraf.puc-rio.br/~anna/cgilua/ cgilua.ps.gz) [Hunter 95] A. Hunter, I. Ferguson, S. Hedges: Swoop: An application generator for Oracle/WWW Systems. Proceedings of the Fourth International World Wide Web Conference. pp. 185-194, 1995.

[Ierusalimschy 96]R. Ierusalimschy, L. H. de Figueiredo and W. Celes, Lua - an extensible extension language, Software: Practice & Experience 26 #6 (1996) 635-652. (see also http://www.tecgraf.puc-rio.br/lua/). [Keller 97] Keller, W.; Mapping Objects to Tables A Pattern Language, Proc. Of European Conference on Pattern Languages of 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) W. Kim, Advanced Database systems, ACM Press, 1994. G. Krasner, S. Pope. A cookbook for using the model-view-controller user interface paradigm in Smalltalk-80. Journal of Object-Oriented programming, 1(3), pp. 26-49, August/September, 1988. J.Renato Milet; D. Schwabe; R. S. G. Lanzelote, Hypermidia Application Authoring Using Object Oriented Databases, Proc. of the XI Brazilian Symposium on Databases (SBBD), SBC, So Carlos, Oct. 1996 (in Portuguese). Pontes, R.C.A., An Environment to Support Hypermedia Applications in the WWW, MSc thesis, PUC-Rio, 1997 (in Portuguese). G. Rossi: An Object-Oriented Method for Designing Hypermedia Applications. PHD Thesis, Departamento de Informtica, PUC-Rio, Brazil, July 1996 (in Portuguese). G. Rossi, D. Schwabe and A. Garrido: Design Reuse in Hypermedia Applications Development Proceedings of ACM International Conference on Hypertext (Hypertext97), Southampton, April 7-11, 1997, ACM Press. G. Rossi, A. Garrido and D. Schwabe: Navigating between Objects: Lessons from an Object-Oriented Framework Perspective, to appear in ACM Computing Surveys. G. Rossi and A. Garrido: Capturing Hypermedia Functionality in an ObjectOriented Framework, to appear in Object-Oriented Frameworks, Wiley 1998. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W.Lorensen: Object Oriented Modeling and Design, Prentice Hall Inc. 1991. D. Schwabe and G. Rossi:, The Object Oriented Hypermedia Design Model, 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, G. Rossi and S. Barbosa: Systematic Hypermedia Design with OOHDM. Proceedings of the ACM International Conference on Hypertext (Hypertext'96), Washington, March 1996. Schwabe, D.; Pontes, R.A.; Rapid Prototyping of Hypermedia Applications in the Web, Technical Report MCC 08-98, Dept. de Informtica, PUC-Rio, 1998. Available at ftp://ftp.inf.puc-rio.br/pub/docs/techreports/98_08_schwabe.pdf.gz Schwabe, D.; Rossi, G.; An Object Oriented Approach to Web-Based Application Design, accepted for publication, Theory and Practice of Object Systems 4 (4), J. Wiley, 1998 UML Document Set. Version 1.013 January, 1997, Rational, 1997. (available at

[ Kim 94] [Krasner 88]

[Milet 96]

[Pontes 97] [Rossi96]

[Rossi97]

[Rossi 98 a] [Rossi 98 b] [Rumbaugh91] [Schwabe 95b]

[Schwabe96]

[Schwabe98a]

[Schwabe 98b]

[UML 97]

19

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: Browsing Object-Oriented Databases over the Web. Proceedings of the Fourth International World Wide Web Conference. pp. 209-220, 1995.

20