Crossing the Gap

C. Segor, M. Gaedke (2000): Crossing the Gap - From Design to Implementation in Web-Application Development. In Proceedings of Information Resources Management Association International Conference, Anchorage, Alaska, USA.

Crossing the Gap From Design to Implementation in Web-Application Development Christian Segor, Martin Gaedke Telecooperation Office (TecO), Universität Karlsruhe Vincenz-Prießnitz Str. 1, 76131 Karlsruhe, Germany {segor, gaedke}@teco.edu The understanding of Web application development mostly neglects approaches to Hypermedia concepts and manageable structures of the information space, resulting in Web sites that fail in achieving typical goals that are important for evolving applications. The implementation model of the Web burdens the application of design methodologies like object-orientation due to the document-centric granularity. To overcome this gap a disciplined engineering approach is necessary. In this paper we present a dedicated process model, which enables a software-engineer to map an object-oriented design to the Web implementation model using a component-based implementation technology and a supporting framework. Keywords: Web Engineering, Framework, Evolution, Hypermedia Design

1 Introduction In every engineering process there is a point where the theoretical design of the product must be implemented and the product itself created. This is true not only for softwareengineering but also for any other engineering discipline. In software-engineering the step from design to implementation usually imposes little burden on the engineers [2]. A large number of well-defined processes exist and help simplifying this task. This situation changes when it comes to the development of hypermedia applications, and especially of Web-based applications [4], [9], [1]. Although a number of design methodologies exist for the hypermedia domain (such as [13], [10]), Web applications are usually developed right from the scratch in an “ad-hoc” manner [11]. The reason for this nuisance is the lack of a continuous “implementation path” from the very first design sketch to the final product. The software-engineer is rather left alone facing a gap between the design of the Web-based application and the targeted implementation. This problem then is solved in uncountable different ways, according to the preferences of the respective personnel involved. Certainly, this leads to obscure implementation strategies and results in code which is almost untraceable. To close this gap we propose a collection of heuristic implementation rules, which can be used to map the outcome of a hypermedia design process to an implementation language without loosing the structure of the original design. We fall back upon the Object-Oriented Hypermedia Design Method (OOHDM) for creating the abstract specifications for a Webbased application, and use the component-based WebComposition Markup Language (WCML) – which is object-oriented as well – as implementation base.


The next two sections briefly introduce these technologies, which serve as a foundation for the proposed mapping process described in section 4. Section 5 gives an example of the whole procedure.

2 OOHDM In this section we take a brief look at the Object-Oriented Hypermedia Design Method (OOHDM), which is used in our mapping process to cover the design of a Web-based application. Since a detailed exploration of OOHDM definitely lies far beyond the scope of this paper, we focus on the Navigational Design process within OOHDM and refer to [13] for further details. In OOHDM, designing a Web application is a four-step-process: •

Conceptual Modelling includes building a model of the application domain by using well-know OO modelling principles similar to UML [5].

•

Navigational Design transforms the conceptual model into a navigational model by applying a view over it.

•

Abstract Interface Design specifies which interface objects the user will perceive and how the interface will behave.

•

Implementation converts the design into platform-specific code. OOHDM does not provide any fixed guideline on how this step should be accomplished.

When designing navigation in OOHDM, two different schemas have to be defined. The Navigational Class Schema is derived from the Conceptual Schema built in the previous step. Its main primitives are nodes and links, which are used to specify objects the user should have access to and their relations. These relation then are used to derive a coarse navigational structure, which is refined in the second schema to be defined during the Navigational Design. The Navigational Context Schema falls back upon the notion of a navigation context. Such a context (defined by a context class) consist of nodes, links and eventually other navigation contexts. Each context has at least one access point, where navigation within the context should begin. Furthermore, a path is defined along which a user can navigate (intra-contextnavigation) and the type of access structure is declared. Generally, there are six basic types of navigation contexts [12]: •

Simple class based includes all objects that belong to the same class. (e.g. all stories)

•

Class based group contains several nested simple class based contexts. (e.g. stories sorted by author)

•

Link based includes all objects belonging to the same class, which satisfy a given predicate. (e.g. stories by author xyz)


•

Link based group analogous to class based group.

•

Enumerated is the most general type of a context; elements are stated explicitly. (e.g. today’s headlines)

•

Dynamic includes a changing set of objects according to user action. (e.g. navigational history)

The Navigational Context Schema unites all contexts defined for a application. Additionally, it contains all links that exist between different contexts (inter-context-navigation) – therefore, it provides a quick survey of the navigational space of the designed Web application. Furthermore, the context must define how the objects contained in the context are presented to the user. This is done by so-called InContext classes. These classes are used to decorate (in the sense of [8]) the contexts and to provide information regarding the appearance of objects within the context. An object can be displayed in completely different manners according to the context within it is found. For example, if a user navigates through the class based group context “Stories by Authors” it is not necessary to display the author’s name an background together with each story – the user already knows by whom the respective story was written, because it has been accessed through the list of authors.

3 WCML In this section we give a short overview of the Web Composition Markup Language (WCML) that is used as implementation language in the proposed mapping procedure. Again, we cannot provide detailed information about this technology, but refer to the literature [7]. WCML is an implementation of WebComposition introduced in [9], which defines an objectoriented component model abstracting from the actual implementation in the Web. The component model is based on components as a uniform concept for modelling web entities at arbitrary granularity and level of abstraction. In contrast to resources (which can be either static, i.e. file-based, or dynamically generated by a script), components are not fixed to a certain grain size but designed to capture design entities at their natural granularity. For example, in contrast to resources, components can represent a content unit as design entity independent of a web page, which itself is a separate design entity. Support of arbitrary grain-size means that components may model web entities as small as individual links or layout fragments. Of course, a component may also be associated with a complete resource, for instance an HTML document or a script generating a web document. The WebComposition Markup Language is an application of the eXtensible Markup Language (XML) [3] and allows a tag-based definition of components, properties, and relationships between components. Because of being entirely XML based, WCML has all desired characteristics of XML. It is • • •

easy to parse rigidly enforcing documents to be well-formed and valid with regard to the defined syntax platform independent.

Furthermore, WCML is component-based. Therefore, existing code can be reused easily when creating new components by constructing them from already existing ones. This is achieved using fundamental principles of object-orientation: specialisation (inheritance), aggregation, and polymorphism. Inheritance has not been realised according to the class-


based inheritance approach used in many programming languages such as Java. Instead, a prototype-instance model – similar to that proposed in [14] – is utilised. An very basic example for using WCML can be found in Figure 1. Here, a component is defined that represents version information (CVersion). Then, CVersion is used to provide the actual version information for a second component, which adds some HTML-like layout to the version string (CVersionNice), demonstrating aggregation. Finally, a third component (CVersionNice2) uses inheritance to change the characteristics of the layout defined in CVersionNice by overwriting the respective property. Further information on WCML and a more detailed explanation of this example can be found in [6]. WCML code

Value of content-property

Interpreted HTML

Version 2.23

Version 2.23

Version 2.23

Version 2.23

Version 2.23

Version 2.23

Version 2.23

Figure 1: Inheritance and aggregation in WCML

A wide-spread class of Web applications are Web-based information systems, designed to provide access to more or less extensive information usually stored in a database system. Conventional applications therefore require some mechanism to retrieve the data from the database; some well-known solutions include cgi-based database integration, server-side scripting for dynamic page generation or client-side approaches like JDBC. In any case, a great number of information pages is generated, which usually look all the same but contain different data. To realise this “information display” in WCML one component is defined for each information page. This strategy requires some mechanism to create the information components automatically, based on given data. In WCML, the notion of a factory provides such a mechanism.


In general, a factory is a special component that contains the required information for producing any number of components according to a production schema. The main elements of a factory are: • • •

the data source a query expression to select data sets from the source a template defining how the “products” of the factory should look like

The data source is stated as a URL addressing an XML-file that contains the data. Using this approach, data can be stored in the file system, but also can be dynamically derived from a database using a simple mapping server. A subset of this data can be selected by stating an XQL (XML Query Language) expression, which is evaluated by the compiler. The results are taken dataset by dataset and inserted into the template, so that a new component is created for every dataset.

4 Mapping from design to implementation 4.1 General strategy We propose a structured “implementation path” that provides a possibility to transform a OOHDM design of a Web application into a WCML-based implementation by bridging the gap between the design and the implementation. The resulting code can easily be maintained, because every step in the implementation process is rule-based and therefore can be traced. The whole process grants a close relation between the components of the application itself and the corresponding design entities. Since we regard navigation as the main issue in the development process of Web applications, the focus is set on navigation contexts and how to implement them. Implementation is done following a number of rules that make sure that traceability is not lost during the process. Additionally, a framework consisting of WCML components is provided. These component implement a number of often used functionality and can be parameterised and reused in the implementation process. The data, on which the Web application should operate, must be provided as an XML file in order to be processed in a WCML factory (see above). To fully benefit from the flexibility provided by XML an additional server instance should be used, which translates XQL queries into the query language used by a (more powerful) relational database system and to convert its answers into XML. Anyway, the details of such a mapping server are not discussed further in this paper. In the following paragraphs we assume that the data is either stored in XML files or accessed through a mapping server and simply refer to an “XML data source”.

4.2 Handling navigation contexts In order to reduce complexity, we model the most frequently used types of contexts (see section 2) by using one general navigation context, which corresponds to the “enumerated context”. Enumerated contexts include all elements of a data source that fulfil a give predicate P. We use this property to model the remaining four contexts by simply stating a suitable P: •

Simple class based contains all elements E of the data source, which belong to the same class C. P := (classOf(E) = C)


•

Link based contains all elements E of the data source, which belong to the same class C and satisfy an additional predicate Q. Q is used to filter elements according to their properties. P := (classOf(E) = C) and Q

•

Class based group and Link based group are modelled by nesting simple class based or link based contexts.

Consequently, it is sufficient to define a matching predicate and to allow nested contexts to model any desired type of navigation context. Both predicate definition and nesting of contexts is realised by using WCML factories and will be explained in more detail in section 4.4.

4.3 Mapping the Navigational Class Schema Basically, a Web application consists of similar elements as a “traditional” application. Especially, it includes a more or less complex data structure on which it operates. Like in conventional applications, it makes sense to define this data structure explicitly before using it and to control the consistency of data with this definition during usage. To achieve this, we use the Navigational Class Schema of OOHDM to derive an XML document type definition (DTD) that governs the structure of the data source. The following rules describe how to create a DTD from the Navigational Class Schema: 1. Root element An XML document is structured as a tree. Therefore, there must be exactly one root element, which contains the remaining data. For the data source we are using ; any other element would do as well: . . . Figure 2: Basic structure of the data source

Therefore, the following lines must always be present in the DTD. In order not to define a fixed order for the data elements, we define the entity data.elements, which includes a certain type of elements. Figure 3: DTD – data

2. Data elements The data elements are directly derived from the Navigational Class Schema. Each class is represented by one element; the attributes of the class are modelled as the content of the element, together with a unique identifier. Those elements, which do not inherit from others (“basic elements”), are added to data.elements. The


remaining elements (“derived elements”) only can be referred to through their parent elements (see rule 4). Figure 4: DTD - data elements

3. Attributes Additionally, the attributes mentionend in rule 2 must also be declared in the DTD. Since these entries contain the actual data, type definitions could be used here. For the sake of simplicity, we only use textual data and therefore state CDATA as content.
id CDATA > attr1 CDATA > attr2 CDATA > attrN CDATA > Figure 5: DTD - class attributes

4. Inheritance Data elements that belong to classes that inherit from other classes are nested within the data source. Figure 6 gives an example of this “inheritance by nesting”: Here, the data source contains an element belonging to ClassB and one belonging to ClassC, which both inherit from ClassA. Please note that the schema on the left depicts classed, whereas the data source on the right represents instances of these classes.

. . . . . . . . .

AttrA1 AttrA2

AttrB1

. . . . . . . . .

AttrC1

Figure 6: Inheritance by nesting

To achieve this nesting, additional attributes must be added to all data elements that have successors. These attributes define the respective successor; Figure 7 shows an example in which de2, de3 and de4 inherit from de1. Figure 7: DTD - inheritance by nesting


5. Aggregation Aggregation is carried out using a similar mechanism: In the DTD, the “aggregated” elements must be defined as valid content of the “aggregating” element. So, “aggregated” elements are repeated explicitly (again, the data source on the right contains instances of the classes depicted on the left): . . . . . . . . . .

AttrA1 AttrA2

AttrB1

. . . .

. .

. .

Figure 8: Aggregation by repetition

This results in the following rule for the DTD: The “aggregated” data elements are defined as valid content of the “aggregating” elements; Figure 9 gives an example. Here, de1 “aggregates” de2 to deN. Figure 9: DTD - aggregation by repetition

6. Aggregation of derived elements When aggregating derived elements, a special construction becomes necessary. The reason for this is the special manner in which inheritance is mapped to the DTD (see rule 4).Since a derived element is represented by a specialisation of its predecessor in the data source, the respective predecessor must be used for the aggregation as well. Figure 10 gives an example.

AttrA1 AttrA2

AttrB1

AttrC1

. . . . . . . . . . . . . . . . . . . . .

Figure 10: Aggregation of derived elements


7. Relations To map relations to the DTD, additional elements are added. These elements state the identifier of the two related data elements: Figure 11: DTD – relations

By applying these rules to the Navigational Class Schema the related DTD can be derived easily and safely. Each entry in the DTD has its well defined counterpart in the schema, which makes reengineering work quite simple: changes in the schema can be mapped directly to the DTD by re-applying the rules. This approach efficiently closes the mentioned gap between the Navigational Class Schema and its implementation. In the next session we explore how to bridge the remaining gap between the Navigational Context Schema and the implementing WCML components. Furthermore, we show how to implement navigation and navigation contexts with WCML factories.

4.4 Mapping the Navigational Context Schema Generally, mapping the Navigational Context Schema to a WCML implementation is a threestep-process: • • •

Defining the predicate P Creating the WCML factory component Defining inter- and intra-context-navigation

For every context a factory component is created; the different parts of that factory directly refer to the respective OOHDM concepts: •

The context class corresponds to the factory component itself. Since a factory component is “degraded” to a usual WCML component after the production process has been completed, it can be used to model the context class. This implies two tasks: First, a unique context identifier must be defined; second, the access structure(s) for the context must be created. The following Figure 12 gives an example of a WCML factory used to model a context class.


. . . . . . Output of access structure . . . Access structure Figure 12: Factory as context class

In this example, a navigation context called nc1 is created, the different objects belonging to that context are read from the data source (which has been verified to comply with the rules defined by the DTD given in the wcml.factory.useDTD statement) and produced as WCML components one by one using the template defined by the factory component. The access structure is created by iterating over the member components of the content and generating a reference to each of them. This list then is regarded as the content of the factory component itself. •

The InContext class is modelled using the template defined in a factory component. Here, the actual way of displaying information in the respective context is defined, and the context identifier is included into the “products” generated according to the template. The template can be regarded as the WCML implementation of the “Decorator” design pattern [6].

•

Furthermore, the factory template defines both inter- and intra-context-navigation according to the respective definitions in the OOHDM schema. Both is done by stating XQL queries to select the required WCML components.

Using factories to implement navigation and navigation contexts closes the remaining gap between OOHDM and WCML. The proposed heuristics allow a structured and controlled implementation of the OOHDM design.

4.5 Framework component architecture In order to provide a well-defined frame in which the implementation of a Web application can be performed, we introduce a framework consisting of WCML components in this section. This components form an inheritance tree, which is depicted in Figure 13. The different tasks of the framework components (FWCs) are explained below.


FWC_Navigation

FWC_Style

FWC_Page

FWC_Layout

Context1

...

ContextN

Figure 13: Component framework

The root of the framework tree is formed by a component called FWC_Navigation, which generates all elements required for navigation. Its successor is called FWC_Page; this component creates all HTML tags necessary to form a valid Web document. The style information (such as background colour, font face, etc.) are defined in a third component called FWC_Style, which is used by FWC_Page. Finally, FWC_Layout defines the general page layout that will be applied to all information pages. Here, corporate identity elements can be defined; this is also the place to perform HTML adaptation that goes beyond the possibilities of Cascading Style Sheets. The factories (creating the different navigation contexts) are direct successors of FWC_Layout and therefore incorporate the complete layout structure defined there. With this approach, functionality is kept at the topmost possible position in the tree, which reduced complexity and enhances the reuse of code.

5 Example In this section we demonstrate the mapping process with a simple example. We chose a very basic online newspaper system as sample application; the respective Navigational Class Schema and a corresponding data source can be found in Figure 14. Figure 15 shows the Navigational Context Schema of our application, and Figure 16 depicts a WCML factory generating one of the navigation contexts: “Story sorted by author”. Finally, Figure 17 shows two screenshots form the resulting Web application: Both are derived from the same data source entry, the left one is accessed within the context “Story sorted by author”, the right one in the context “Highlights”.


Story Title: string Date: date Summary: string Author: string Text: string

Report

Interview

Illustration: image

Interviewee: string Recording: audio Illustration: image

Q&A Question: string Answer: string

. . . story975Q56 Stay healthy with Papaya 991008 This will give you an overview of different techniques used in the art of eating papaya seeds. Foo Bar And here comes the marvellous text. Don’t miss it! /images/papaya.gif . . .

Figure 14: Navigational Class Schema and data source of the sample application

Story

Main Menu

Query

Author Index

by Author

Query Index

by Query

Highlights

Highlights

Figure 15: Navigational Context Schema of the sample application

. . . .html


. . . . . .

All stories by -------------------------------------- Abstract: --------------------------------------- Figure 16: WCML factory generating "Story by author"

Figure 17: Screenshots of the sample application

6 Conclusion The development of Web-based applications usually suffers from an implementation path that is disrupted by a gap between the design of the application and the actual implementation. To close this gap, we have proposed a set of heuristic implementation rules along with a supporting framework of WCML components. By using this technique, software engineers are able to implement Web applications following one well-defined way from the first sketchy design to the final code. Because of the structural similarities between the design method (OOHDM) and the implementation language (WCML), the OO design can easily be mapped to the componentbased implementation – thereby keeping traceability and maintainability of the final code.

7 References [1]

R. A. Barta and M. W. Schranz, “JESSICA: an object-oriented hypermedia publishing processor,” Computer Networks and ISDN Systems, vol. 30(1998), pp. 239-249, 1998.


[2]

D. M. Berry, “Academic Legitimacy of the Software Engineering Discipline”, Technical Report CMU/SEI-92-TR-34, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, USA, November 1992.

[3]

T. Bray, J. Paoli, and C. M. Sperberg-McQueen, “Extensible Markup Language (XML)” , vol. 1997: W3, 1997.

[4]

F. Coda, C. Ghezzi, G. Vigna, and F. Garzotto, “Towards a Software Engineering Approach to Web Site Development”, 9th International Workshop on Software Specification and Design (IWSSD), Ise-shima, Japan, 1998.

[5]

M. Fowler and K. Scott, "UML distilled: applying the standard object modeling language", Addison Wesley Longman, Reading, Mass., USA, 1997.

[6]

M. Gaedke, M. Beigl, H.-W. Gellersen, and C. Segor, “Web Content Delivery to Heterogeneous Mobile Platforms”, Lecture Notes in Computer Science (LNCS), vol. 1552, 1998.

[7]

M. Gaedke, D. Schempf, and H.-W. Gellersen, “WCML: An enabling technology for the reuse in object-oriented Web Engineering”, Poster-Proceedings of the 8th International World Wide Web Conference (WWW8), Toronto, Ontario, Canada, 1999.

[8]

E. Gamma et al., "Design patterns : elements of reusable object-oriented software", Addison-Wesley, Reading, Mass., USA, 1995.

[9]

H.-W. Gellersen, R. Wicke, and M. Gaedke, “WebCompostion: an object-oriented support system for the Web engineering lifecycle”, Computer Networks and ISDN Systems, vol. 29 (1997), pp. 1429-1437, 1997.

[10]

T. Isakowitz, E. A. Stohr, and P. Balasubramaninan, “RMM: A Methodology for Structured Hypermedia Design”, Communications of the ACM, vol. 38, No. 8, pp. 3444, 1995.

[11]

D. Lowe and W. Hall, "Hypermedia & the Web : an engineering approach", John Wiley, Chichester, New York, USA, 1999.

[12]

D. Schwabe and G. Rossi, “An Object Oriented Approach to Web-Based Applications Design”, TAPOS - Theory and Practice of Object Systems, vol. 4, pp. 207-225, 1998.

[13]

D. Schwabe, G. Rossi, and S. Barbosa, “Systematic Hypermedia Design with OOHDM”, ACM International Conference on Hypertext’ 96, Washington, USA, 1996.

[14]

D. Ungar and R. B. Smith, “Self: The Power of Simplicity”, OOPSLA ’87, 1987.