has been achieved for applications designed employing the Object Oriented Hypermedia. Design Method (OOHDM), using the CGI Lua web site building ...
OOHDM-Web: An Environment for Implementation of Hypermedia Applications in the WWW Daniel Schwabe*, Rita de Almeida Pontes and Isabela Moura Dept. of Informatics, PUC-Rio [schwabe, rita, moura]@inf.puc-rio.br Abstract This paper shows an environment, OOHDM-Web, that allows template driven website for applications designed using, OOHDM.. We show how this environment allows direct mapping of navigation and interface constructs of OOHDM into a library of functions in the CGI scripting environment CGI-LUA, extended with the DB-LUA package. OOHDM-Web allows implementation of hypermedia applications as CGI scripts that produce dynamically generated pages, whose contents are fed from a database and integrated with pre-defined templates. The paper presents the advantages of combining the two techniques, template-driven implementations and design methods, reaping benefits of their respective strengths.
1. Introduction One of the prime implementation platforms for hypermedia applications nowadays is the WWW. In this case, a collection of documents and CGI scripts is made available to users, allowing both access and in many cases processing of information contained in these documents. This collection of pages usually shares a common coherent interface appearance and behavior, and may be physically located in one or more web servers. One example of such applications is the Amazon Books website (www.amazon.com). However, much in the same way as in other platforms, there is no environment that facilitates the structured development of such applications. In spite of a number of design methodologies having been proposed and adopted [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 primitives in such methodologies to any given implementation platform, including the WWW. The tools available in the market today to aid in website design and implementation may be classified in three main categories: page editors, web site editors, and website building environments. Of these, the last offers the most support for developers, as they allow the construction of sites where documents are defined using templates which extend standard HTML with some proprietary set of tags, typically allowing including of statements in some custom defined or standard programming/scripting
*
language. In such environments, documents are dynamically assembled at run-time by instantiating a template with data pulled off from a database. Documents can be created and maintained using the same mechanisms, employing another set of appropriately defined templates. Examples in this category are Microsoft 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 these environments is the fact that they lack higher level abstractions that allow the user to design applications without resorting to a node-andlink level of description of the whole system. In spite of these drawbacks, template-based approaches present inumerous advantages: uniform treatment of pages, separation of content and presentation, more efficient use of storage, etc... It would be interesting to have an environment that exploits such advantages, while adding higher level primitives that allow the designer to express his design at a level closer to the application domain. From this point of view, these environments can be used as basis for implementation of designs carried out using one of the previously mentioned methodologies. This paper presents how this has been achieved for applications designed employing the Object Oriented Hypermedia Design Method (OOHDM), using the CGI Lua web site building environment. The remainder of this paper presents first a brief description of OOHDM, and then gives more detail about OOHDM-Web, the environment we have built. To conclude, we
Work partially supported by CNPq, MCT, Brazil. 1
present current research being conducted around OOHDM-Web.
2. A Brief Overview of OOHDM The Object-Oriented Hypermedia Design Method [Schwabe 98b, Schwabe 96, Rossi 96] 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 prototypebased development styles. During each activity a set of object-oriented models describing particular design concerns are built or enriched from previous iterations. In Figure 1 we show a sketch of the models and activities in OOHDM
Figure 1: OOHDM design models
Treating conceptual, navigational and interface design as separate activities allows us to concentrate on different concerns, one at a time. Consequently, we get more modular and reusable designs, and we obtain a framework for reasoning about the design process, encapsulating design experience specific to each activity.
Design primitives can be mapped straightforwardly onto non object-oriented implementation languages or environments (such as HTML or Toolbook). Consequently, OOHDM can be used regardless of whether the target system is a pure object-oriented environment one or a hybrid one (as those usually found in the Internet). In the next sub-sections, we describe each phase in more detail.
2.1 Conceptual Modeling The goal of the Conceptual Design activity is to build a model of the application domain, using well known object-oriented modeling principles, using a notation similar to UML [UML 97]. 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 computations on objects, such as in Web-based Information Systems, the conceptual model will evolve into an object model that will be implemented in the target environment (for example in a WWW server). In this case, navigation objects will act as observers [Gamma95] over these application objects. OOHDM does not prescribe any particular method to produce the Conceptual Class Schema; any of the well-known methodologies, such as OMT [Rumbaugh 91] may be employed.
2
0..*
designs
1..*
Architect name: String description: [Text+, Photo: Image]
Building name: String address: String year: Integer description: [Text+, Photo: Image]
Building Category 0..*
classifies
1..*
name: String description: String
Figure 2 – Conceptual schema for a site about architecture
Figure 2 shows a Conceptual Schema for a Web site about architecture. Perspectives (multiple valued attributes) are denoted by enumerating the possible types, with a + next to a default type. Thus, description: [Text+, Photo: Image] means attribute description has a text perspective (always present), and may have an image perspective containing a photo. 2.2 Navigational Design In OOHDM, an application is seen as a navigational view over the conceptual model.
0..*
designs
1..*
Building
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 objectoriented views of conceptual classes, using a query language similar to the one in [Kim94]. This allows 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].
Architect name: String photo: Image* build-arch-ind: anchor (index (Buiding by Architect(self)))
name: String address: String year: Integer description: Text+ Photo: Image* Category: bc.name where bc:Building Category, bc classifies self -1 Architect_name: list of(anchor (designs ))
Figure 3 – The navigation class schema for the architecture application
Figure 3 shows the navigation class schema for the architecture example. Navigation classes (called nodes) are denoted as classes, with a square box on the top right corner. Notice that multi-valued attributes in the conceptual schema have been mapped onto different navigation class attributes.
This design also shows an example where the navigational class (node) “Building” is actually a 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 attributes of the “Building” conceptual class. 3
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 building’s category by collaborating with the corresponding object. In a hybrid implementation, the architect’s name will be implemented in the building’s node (and in its corresponding interface). A schema specifying navigational classes defines the navigational domain of a hypermedia application. 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, represent possible ways for starting navigation. 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 user’s profile. For example, the architecture website could include the building category info for experts in the field, and not include this information for casual users. 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: the elements it contains; the specification of its internal navigation structure; an entry point; access restrictions in terms of user classes and operations; and associated access structures. There are six different ways to define contexts: 1.
Simple class derived – includes all objects of a class that satisfy some property; e.g., “ buildings with address = Rio de Janeiro”. A variant of this type is the query-based context, where the user defines the property at navigation time. Graphically:
2.
Class derived group – is a set of simple class derived contexts, where the defining property of each context is parameterized; e.g. “building by location” (location can vary). Graphically:
3.
Simple link derived – includes all objects related to a given object; e.g., “buildings designed by Oscar Niemeyer”. 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. “buildings designed by architect” (architect 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, shopping basket. Graphically:
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. Associated to the contexts, there are access structures (indices). They are denoted graphically by: Simple Index: Dynamic Index: Index with multiple orderings: 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 4 shows the context diagram for the architecture site.
4
Architect
\ Architects
By name
Building Timeline
By year
Main Menu By name Buildings
Categories
By architect By category
Figure 4 – The context diagram for the architecture website
According to this diagram, the application’s main menu has four indices: Architects
allows access to an alphabetical list of architects, which can be traversed in some order
Timeline
allow access to grouped by years
buildings,
Buildings
allows access to grouped by name.
buildings,
Categories
allows access to buildings by categories (monuments, hotels, convention centers, etc…)
In addition, buildings can also be grouped according to the architect that designed them. This context can only be accessed from other contexts, such as architects. It should also be noted that, when looking at a building in any of the contexts, it is possible to “switch” context. For example, while looking at a building by a certain architect, it is possible to navigate to the “next building in the same category”, regardless of its architect. Once contexts have been defined, it is possible to extend the definition of navigation classes by specifying “decorators”, i.e., attributes that are only visible when an object is accessed within a given context. Such attributes are defined in “InContext” classes.
2.3 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 (the Abstract Data Objects – ADOs – in the original formalism). We use Configuration Diagrams [Coleman92] for expressing these relationships. An ADV is related with a corresponding application object, 5
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 modelview-controller 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 PetriNet like notation for expressing synchronization issues usually found when dealing with multimedia data. Implementation of ADVs in the WWW is discussed in the next section.
2.4 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 WWW by looking at one particular approach we have followed. 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. 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, Schwabe 98a]. 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. It should be noted that, in this approach, the ADV is implemented by a combination of HTML templates whose structure must be compatible with the ADV’s structure, and whose behavior is represented as calls to library functions in the Lua/CGILua/OOHDM-Web environment. There is currently no support to automatically derive these templates and calls from the ADV/ADV Charts specifications. The OOHD-Web environment has three interfaces, all implemented using this combination of tools, discussed in greater detail in the next section. We have chosen the CGILua environment mainly for reasons of portability (it is available for Windows and Unix environments), availability - it is free, and therefore OOHDM-Web can be freely distributed – and because it is based on a very elegant, full fledged programming language. In spite of this, it should also be clear that this approach could easily be reproduced using any of the alternative commercially available environments such as Cold Fusion or ASP.
3. The OOHDM-Web environment The general architecture of OOHDM-Web is shown in Figure 5. Through the first interface, the designer defines the Navigation Schema and the Interface templates, generating the database definitions. Through the second interface, the designer can populate the databases with instance data, or make changes to existing data. Through the third, users browse the resulting site.
6
Interface Appearance
OOHDM Navigation Schema
OOHDM-Web Authoring Environment Templates mixing HTML with commands using OOHDM-Web OOHDM-Web Browsing library Environment functions and CGI-Lua HTML Pages
- Tables describing navigation classes - Tables describing contexts
OOHDM-Web Maintenance Environment
- Tables with instance data (nodes and contexts) Browser
HTTP Server
Figure 5 - The structure of the OOHDM-Web Environment
The first interface, the Authoring Environment, is currently under construction, and will have three modes: graphical, forms-based, and textual. The graphical interface allows direct translation of schema diagrams, plus information entered via inspectors, into table definitions. The forms-based interfaces achieve the same result by presenting several forms through which the designer can describe the design. The textual interface simply reads a description of the design in a stylized notation. We will concentrate on the other interfaces, the browsing and maintenance environments.
As previously said, the browsing interface is implemented through HTML templates that mix plain HTML tags with calls to functions in the OOHDM-Web library. Before describing these templates and functions, it is necessary to explain how the information items in the design are represented in the environment. These functions will access this representation to retrieve the appropriate values for the information items to be displayed in the browser.
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 user’s 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 (see, for example, [Varela 95, Hunter 95]). 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.
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.
3.1 Representing the Design
In section 3, it was stated that the Navigation Model is a view over the conceptual model. The 7
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. In such cases, the DB schema of the existing database should be taken
as the Conceptual Model, over which the Navigation Classes are defined. OOHDM-Web assumes the view has been translated by hand, and takes the approach that maps each class in the OO (navigation) model to be implemented onto a table, where each column stores an attribute, and each row corresponds to an object of that class. All such class tables must have a distinguished attribute named “key”, which will, by definition, be used as the table’s key field. If there are multi-valued attributes, these are stored in a separate table, and a key for each value is stored in the original class 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 class is shown in Figure 6.
architect #key 1 2
architect_name Lúcio Costa Oscar Niemeyer
photo costa.gif niemeyer.jpg
building #key 13 7 19
building_name Hotel Sheraton Hotel Nacional Sede do Banco Aliança
date 1978 1968 1956
building_photo sheraton.jpg nacional.jpg alianca.jpg
address Av. Niemeyer, 121 Av. Niemeyer 769 Praça Pio X, 99
build_arch architect_key 2 2 4
building_key 7 19 13
Figure 6 – Tables defining classes “Architect”, “Building” and relation “designed”
In addition to class tables, the designer may also specify InContext classes, which are represented by separate tables, not detailed here. Implementing Contexts. To support contexts, the underlying database model or set of files must also contain 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. OOHDM-Web defines 6 tables that describe all contexts in a design. There is one table called “context” which has two columns, the first with a context name, and the second with its type (1 through 5, according to the types described in
section 2.2). For our example, this table would be context #ctx_name building_alpha building_by_year building_architect
type 1 2 5
where: ctx_name
type
is the name that identifies the context, given by the user identifies the kind of context. The possible values 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 the example.
8
Each of the five different types of context has a different type of table describing its occurrences. Thus, each context present in the design will have a tuple in the appropriate table, depending on its type.
Field
Description
#Context Name
Name identifying the context
Relation Table
Name of table representing the links
SourceClass
Class to which the source elements of the link belongs
For example, “class derived groups” (type 2) are defined by the context table presented in Figure 8 (a)
Destination Class
Class to which the destination element of the link belongs
SourceField
Field in the relation table used to select the source element
DestinationField
Field in the relation table used to select the destination element
Dest. Target Page
Name of the template page used to show the elements of the context
Navigation Type
Type of navigation allowed in the context
Source Target Page
Name of the template page used to show the elements that are the source of the link
Source Context
Name of the context that is formed by the sources of the links
Field ctx_name class_name class_atr order target_page nav_type
Contents Is the context name class to which the elements belong Attribute of class 'class_name' whose value is used to select the elements to include in the context Attribute of class 'class_name' used to sort the elements in this context HTML template used to present elements in this context Specifies the possible navigation beween elements in this context. Possible values are: 'sequential', 'circular', 'free' or 'index'.
type5
(a) type2
#ctx_name building_by_year
class_ name building
class_ order target_ atr page date building_name build_yr.html
nav_ type sequential
(b)
Figure 8 – (a) Table implementing “class derived groups” (type 2), and (b) A row in this table representing the context “building by year”
The context “building by year” would be defined by the row in this table, shown in Figure 8 (b). As a second example, a table as illustrated in Figure 9 can be used to represent link-derived groups of contexts. With this table defined, once such context, for example, “Building by Architect” , can be described by a tuple, also shown in Figure 9
#ctx_name RelationTable SourceClass DestinationClass build_arch rel_arch_build architect building ...
SourceField arch_key
DestinationField Dest.TargetPage build_key build_arch.html
...
NavigationType SourceTargePage SourceContext circular arch.html arch_alpha (b)
Figure 9: Table implementing a “Link Derived Context Group” (type 5), and an example tuple describing “Building by Architect”.
Navigation operations within contexts require keeping state information. For example, to determine “what is the next building by this architect” requires knowing which building the user is currently looking at, which projects make up the referenced context (“Buildings by architect”), and what is the ordering defined for that context. This information is handled by functions provided by the OOHDM-Web library, using state maintenance facilities in the CGI Lua environment.
3.2 Implementation of Browsing Environment.
the
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 9
dynamically, based on HTML templates previously specified by the designer. These templates usually contain a mixture of HTML code and calls to functions in the OOHDM-Web library. The execution of these functions will retrieve or compute the instance data, to fill in the missing data that makes up the final HTML page. This is achieved using the CGI Lua environment. It should be stressed that all pages in the application will be either (arbitrary) static pages, or pages that correspond to an index (access structure), or pages that show some attributes of objects within a given context.
Another example of use of this function is the call below, which generates an index to the context “buildings by architect Oscar Niemeyer” (“cgi.inst” is a variable of the CGI Lua environment that stores the id of the current 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, as seen by the user, is shown in Figure 11.
For example, the OOHDM-Web function call below, which is an expression the LUA programming language, when embedded as part 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= ) ’} Functions “Index” and “Horizontal_Tab” are part of the OOHDMWeb library. The corresponding generated page, as seen by the user, is shown in Figure 10.
Figure 11 – The index to context “build_arch” = “Oscar Niemeyer”” (Buildings by architect Oscar Niemeyer)
In any of these indices, if the user chooses the building “Hotel Nacional”, he will navigate to a page that shows an instance of “Building”, which is built through the template shown in Figure 12 . This figure also shows the actual page seen by the user.
Figure 10 – An index page to the “building_alpha” context (buildings in alphabetical order)
10
Figure 12 – The template “build_arch.html”, which is used to show “buildings” in the context “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 uses the “PrevLink”, “NextLink” and “Atrib” library functions, applied to the current (“Hotel Nacional”) object. As shown in the examples, the templates may reference any Lua expression. In order to allow the designer to abstract from implementation details, the OOHDM-Web environment provides functions
that enable the manipulation of the design elements without requiring knowledge of how the information is actually stored. The following functions are defined in the OOHDM-Web library.
11
Function Description Index Generates an index (a structure with links) to all elements in a given context. There are several kinds of indexes that can be generated, depending on the type of context. Attrib Retrieves the value of an attribute of a given object, when seen from within a given context. Notice that, depending on the context, attributes belonging to InContext classes may be visible (accessible). NextLink Generates a reference to the next element (to the one represented by the page where this call appears) in the current context PrevLink Generates a reference to the previous element in the context FirstLink Generates a reference to the first element in the current context LastLink Generate a reference to the last element in the current context
In addition, there are formatting functions that take lists of references and generate various kinds of HTML table definitions, with the elements of the supplied list inserted into individual table cells. Such functions are useful as they relieve the designer from dealing with error-prone details.
3.3 Implementation of Maintenance Environment
the
Since the complete design is described in the OOHDM-Web tables and page templates, it is also possible to automatically derive browser interfaces that allow the designer (or others) to enter instance data that will be perused by users. This interface is forms-based, and again alleviates the designer from having to know all the particular details of how objects are stored. Figure 14 show an example form to input instance data for class “Building”.
Figure 14 – A form to input instance data for class “Building”. Notice the possibility to specify links to “architects” via the checkboxes at the bottom.
The environment also allows the user to check the design, by providing summary screens with information about classes and contexts specified. This can be seen in Figure 15.
Figure 15 – Summary screen showing classes and context defined in a design.
4. Conclusions The combination of a powerful design methodology with a template-based environment allows the rapid development and deployment of sophisticated websites. The designer can concentrate on the design by expressing it in a high-level language, and has an easy path to convert this design into a working application. We are currently extending OOHDMWeb (and OOHDM) in various directions. The first class of extensions aims at supporting other primitives in OOHDM, such as the recently introduced primitives of user classes and access restrictions for contexts. Another important direction being explored is the ability to “pre-compute” a site, either partially or completely. In the situations in which all instances of objects are known before deployment, it might be more convenient to pre-generate all pages, and store the entire site as static pages. Clearly, this is only interesting when the update frequency is low enough. In other cases, even if the site as a whole contains sections that cannot be precomputed (e.g., search forms, or any form with data input by the reader during navigation), it might still be possible to pre-compute at least a portion of the site. We are currently implementing this functionality into OOHDMWeb. The CGI Lua environment has proven adequate in terms of functionality and performance, for the several applications that 12
have already been developed and deployed with OOHDM-Web. It is being upgraded to function as an API directly with the HTTP server, in order to avoid inherent inefficiencies of the CGI architectures. In order to be able to fully understand the interplay between design methodologies and website implementations, we have also developed a Java-based framework that provides similar functionality to OOHDMWeb, using Servlets [Pizzol 98]. Although requiring a greater level of programming on the part of the designer, this approach might prove more flexible and efficient. We will be experimenting with this environment, and comparing 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 Interactive Systems”, in M.D. Harrison, C. Johnson, eds., Software Engineering in HumanComputer Interaction, Cambridge University Press, 1994. [Coleman92] 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. [Cowan95] 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. [Gamma95] Gamma, R. Helm, R. Johnson and J. Vlissides: “Design Patterns: Elements of reusable object-oriented software”, Addison Wesley, 1995. [Garzotto93] F. Garzotto, D. Schwabe and P. Paolini: “HDM - A Model Based Approach to Hypermedia Application Design”. ACM Transactions on information Systems, 11 (1), Jan. 1993, pp. 1-26. [Hester 97] A.M. Hester; R.C.Borges; R. Ierusalimschy; “CGILua: A MultiParadigmatic Tool for Creating Dynamic WWW Pages”, Proceedings of the XI Brazilian Software Engineering Symposium (SBES’97) pp.347-360, Fortaleza, Brazil, 1997 (available at http://www.tecgraf.pucrio.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. [Isakowitz95] T. Isakowitz, E. Stohr and P. Balasubramanian. “RMM: A Methodology for 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 - an extensible extension language”, Software: Practice & Experience 26 #6 (1996) 635-652. (see also http://www.tecgraf.pucrio.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/in dex.phtml# Mapping_Objects_To_Tables) [ Kim 94] W. Kim, “Advanced Database systems”, ACM Press, 1994. [Krasner 88] G. Krasner, S. Pope. “ A cookbook for using the model-viewcontroller user interface paradigm in Smalltalk-80”. Journal of Object-Oriented programming, 1(3), pp. 26-49, August/September, 1988. [Lowe 96] D. Lowe, A. Ginige, M. Sifer, J. Potter, "The MATILDA Data Model and its Implications", 3rd International Conference on Multimedia Modelling, November 12-15, 1996, Toulouse, France [Milet 96] J.Renato Milet; D. Schwabe; R. S. G. Lanzelote, “Hypermedia Application Authoring Using Object Oriented Databases”, Proc. of the XI Brazilian Symposium on Databases (SBBD), SBC, São Carlos, Oct. 1996 (in Portuguese). [Pizzol 98] Pizzol, A.M.; “A Java Framework for Implementation of Hypermedia Applications using OOHDM”, MSc. Thesis, Dept. of Informatics, PUC-Rio, Dec. 1998. (in Portuguese). [Pontes 97] Pontes, R.C.A., “An Environment to Support Hypermedia
13
Applications in the WWW”, MSc thesis, PUC-Rio, 1997 (in Portuguese). [Rossi 96] G. Rossi: “An Object-Oriented Method for Designing Hypermedia Applications”. PHD Thesis, Departamento de 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 Design Model”, Comm. of the ACM, Vol. 38, #8, pp45-46 Aug. 1995. (available at ). [Schwabe 96] Schwabe, G. Rossi and S. Barbosa: “Systematic Hypermedia Design with OOHDM”. Proc. of the ACM International Conference on Hypertext (Hypertext'96), Washington, March 1996. [Schwabe98a] Schwabe, D.; Pontes, R.A.; “Rapid Prototyping of Hypermedia Applications in the Web”, Tech. Report MCC 08-98, Dept. de Informática, PUC-Rio, 1998. Available at ftp://ftp.inf.pucrio.br/pub/docs/ techreports/ 98_08_schwabe.pdf.gz [Schwabe 98b] Schwabe, D.; Rossi, G.; “An Object Oriented Approach to Web-Based Application Design”, Theory and Practice of Object Systems 4 (4), J. Wiley, 1998 [UML 97] UML Document Set. Version 1.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: Browsing Object-Oriented Databases over the Web”. Proceedings of the Fourth International World Wide Web Conference. pp. 209-220, 1995.
14
