Composition of Web Technologies and Web Engineering Method€¦ · 4 component web JSP, Servlet,...

Comparison of Web Technologies and Web Engineering Methodologies

Author: Andreas Burner

Guided by: Clemens Kerer

Distributed Systems Group, Technische Universitä t Wien

August 2002

Table of content

Introduction .....................................................................................................................................2

1 Evolution of Web Technologies..............................................................................................3

1.1 Comparison of Web Technologies ..................................................................................3

1.2 Static Web .......................................................................................................................4

1.3 Stylish Web .....................................................................................................................6

1.4 Dynamic Web..................................................................................................................7

1.5 Component Web..............................................................................................................8

1.6 Separation of Concerns (SoC).........................................................................................9

1.7 Dynamic Separation of Concerns (SoC) .......................................................................10

1.8 Contract-based Web ......................................................................................................11

1.9 Summary .......................................................................................................................11

1.10 References .....................................................................................................................12

2 Web Engineering Methodologies..........................................................................................13

2.1 Comparison of Engineering Methodologies .................................................................15

2.2 OOHDM (Object-Oriented Hypermedia Design Method)............................................16

2.3 RMM (Relationship Management Methodology).........................................................18

2.4 WSDM (Web Site Design Method) ..............................................................................20

2.5 JESSICA........................................................................................................................22

2.6 WebML (Web Modeling Language).............................................................................23

2.7 W3DT (World Wide Web Design Technique) .............................................................24

2.8 WebComposition...........................................................................................................26

2.9 Summary .......................................................................................................................28

2.10 References .....................................................................................................................29

3 Outlook and future work .......................................................................................................30

Andreas Burner Page 2 08 / 2002

Introduction

Since its creation, the Internet development tremendously: It started from publishing of simple text documents and today most of the software applications are Web-enabled. Various techniques have been invented to deal with several requirements and make this evolution happen. All Internet-techniques presented in this piece of work are in use and still development takes place based on them. The reason is that the latest technology also has its shortcomings and it is important to be aware of them. As the Internet is a rapidly growing environment with applications that have a short life cycle, fast time-to-market is important. To meet this requirement, Web-Engineering (WE) methodologies emerged.

Like the widely accepted Software-Engineering (SE) methodologies WE methodologies provide a number of benefits compared to ad hoc development: WE methodologies guide through the process of software-creation, provide a complete documentation, take into consideration the users’ needs, and ensure quality. Further, by forcing modularity and support re-use, the designed applications are more flexible, robust, and reliable. Through the homogenous structure of engineered Web-applications, complexity decreases and maintenance eases. All these issues of WE methodologies help to reduce the development costs, which certainly is an ultimate goal in software development. In addition to common SE-methodologies, WE methodologies are specially designed to meet the requirements of the Web.

This document will provide an overview of today’s Internet development mechanisms:

Chapter 1 presents the historical evolution of the Web-technologies. It describes the approaches, and gives an overview of certain technologies. Besides, it shows certain techniques, and it will explain the cause why a further evolutionary step took place. It goes on with an explanation which technology is the one to prefer when developing a certain Web application. Finally, it gives reason why the latest technology is not necessarily the best one.

Chapter 2, looks closely at Web-Engineering methodologies. First, an overview is given, by comparing the common methodologies by a number of criteria. Afterwards, based on this overview, every methodology is inspected in detail. Finally, the techniques are described, and specific features, as well as advantages are compared to each others. As a summary, a connection to the first chapter is made: Which methodology best suits a certain Web-technology?


1 Evolution of Web Technologies

1.1 Comparison of Web Technologies technology description + - software

1 static web pure HTML static pages simple mix of

content, layout static web server

2 stylish web CSS & HTML client side formatting

separation of content, layout

input - equals output structure

HTML is not content only

static web server

3 dynamic web CGI, SSI

(& CSS)

dynamic pages

(can be combined with 2) dynamic content

content generation in code

“content-in-logic”

web server with dynamic calls

4 component web JSP, Servlet,

ASP software engineering,

usage of patterns CLL separation

e.g., by using MVC

for one target only (e.g., HTML)

“ logic-in-content”

J2EE, IIS

5 separation of concerns

XML, XSL server side formatting

clean separation of content / layout

any target platform

no logic

more complex than HTML

XML parser, XSL transformer

6 dynamic separation of concerns

XML, XSL, XSP dynamic server side formatting

clean separation of CLL

logicsheets generate dynamic content

more complex than HTML

Cocoon (Java), AxKit (PHP)

7 contract-based web

XML, XSL, XSP, contracts

through contracts a parallel design process

can be achieved

better time-to-market

contracts involve specification

complexity demand tool

support


1.2 Static Web HTML [1] is the standard that led to the breakthrough of the Internet that we know today. Most documents on the Web are stored and transmitted in HTML. Originally, scientists invented HTML at the European Laboratory for High-Energy Physics (CERN) in 1990. They were seeking a way to publish and share scientific articles over the Internet. It never was thought of reaching today’s expansions and never was designed for it.

HTML was invented by structure, but influenced by presentational document formats. This means that it concentrates on logical document layout, e.g., headers, titles, and paragraphs, but also has elements such as <B> (for bold) or <I> (for italics), which encode document presentation rather than structure.

This breaks with the SGML principle of separating structure from presentation. Nevertheless, HTML was formally specified as an SGML DTD in 1992.

Most HTML-browsers accept invalid HTML-document syntax (i.e., not adequate to the HTML-specification), which is why even today few documents are valid to the HTML specification. An invalid syntax is, for example, when HTML-tags are not validly interlocked:

<TABLE> <TR> <TD> <B> name </TD> <TD> phone number </TD> </TR> </B> </TABLE>

Example 1. Invalid HTML-document syntax

A valid HTML-syntax requires closing recently opened tags first: <TABLE> <TR> <TD> <B> name </B> </TD> <TD> <B> phone number </B> </TD> </TR> </TABLE>

Example 2. Valid HTML-document syntax

Even worse, many HTML pages contain markup which can only be processed by specific browsers and viewed by a specific resolution (“Best viewed with browser X version Y. Best displayed in resolution Z”). This means that there is no separation of physical layout and logical layout tags.


Moreover, authors abuse HTML elements in order to perform tasks they were never intended to do.

Example 3 shows the abuse of HTML elements: The HTML code for round buttons. This gimmick can be seen on many of today’s Web sites. The trick is to use an invisible 9 by 9 HTML-table. The table has an assigned background, each of the corner-cells contains a round-edge image covering the table’s edges, and the center-cell has the caption of the button. Figure 1 shows the output. For better demonstration, the four images do not match to the background color.

Figure 1. HTML-gimmick: Round button

<table border=”0” cellspacing=”0” cellpadding=”0” bgcolor=”#AAAAAA”> <tr> <td> <img src=”upperleft.gif”> </td> <td> </td> <td> <img src=”upperright.gif”> </td> </tr> <tr> <td> </td> <td> Caption of Button </td> <td> </td> </tr> <tr> <td> <img src=”lowerleft.gif”> </td> <td> </td> <td> <img src=”lowerright.gif”> </td> </tr> </table>

Example 3. Abuse of HTML-elements: a Round button

This example shows how elements can be to achieve graphical effects. This is the reason why it is difficult to extract the structure of the content automatically (i.e., by a program) in most of today’s HTML pages.

In summary, HTML is a simple language to publish information on the Web. On the server side, a Web service is needed that is able to provide HTML pages to the user. The main drawback of HTML is the missing separation of content and layout that avoids HTML of being directly reusable and causes problems (e.g., maintenance).


1.3 Stylish Web The approach of separating structure from layout led to the CSS standard. This standard was developed at CERN too, and it is an extension to HTML. CSS (Cascading Style Sheets) is a language for the purpose to describe the layout of an HTML document, allowing the separation of layout and content.

CSS1 [2] became a W3C Recommendation in 1996 and soon major browsers supported it. By using CSS1, it is possible to specify styles for HTML elements, like color and font-properties. Further, the layout of the entire page can be described (margin, border, padding, etc.).

CSS2 [3] became a W3C Recommendation in 1998. The difference to CSS1 mainly is the specification of classes of devices, which makes CSS more device-independent. Further, it provides a selection mechanism for elements to filter information.

Moreover, CSS does not need any server enhancements. A static Web-service is sufficient. Additionally to the HTML-page, there is a reference to a CSS stylesheet. The client device requests the CSS-document and is then responsible to format the HTML content using the CSS layout.

The client’s responsibility of doing formatting has further advantages: the server does not have to know all the devices and their features, privacy and security, and high-level information of the client [4]. Butler [16] describes, how clients can communicate their supported features, e.g., by HTTP-Request Header Field or CC/PP (Composite Capability Preferences Profile by W3C), which is based on RDF.

Nevertheless, with the CSS standard there is a demand for supporting the CSS-technology on the user’s device. Today’s common Web-browsers implement CSS1 (more or less, because not all features are implemented similar). CSS2 still is not supported by any browser completely.

Moreover, the major drawback is that the HTML syntax is still a mixture of structural tags and layout (e.g., tables). CSS does only lightweight formatting and layouting, but leaves the document structure. Technically, the target-tree equals the source tree [5]. Although in CSS2 the processing of selecting-functions is possible, powerful mechanisms like element re-ordering and scripting with conditions, loops, and states cannot be processed. This can become an issue when dealing with various screen sizes, formats, and customized screen layout.

Further, since CSS is a client-side formatting technology, selecting data does not decrease the network-load. This means that even when filtering elements, both HTML and CSS must be transferred as a whole.

Considering these facts, HTML with CSS together is not an optimal solution for device independent Web technology.


1.4 Dynamic Web It is often requested to assemble content on demand. A common dynamic requirement for a Web site is a search function. Usually the user submits a search term (figure 2), a program on the server searches the data, and the result is presented to the user (figure 3).

Figure 3. A typical search dialog

Figure 3. A typical search result page

This evolutionary-step was also driven by the requirement to create DB-backed Web applications. Since most of today’s structured data is stored in database systems, it was mandatory to connect the Web to these huge information sources.

Today, many technologies exist that execute code on the server. The most common interface is CGI (Common Gateway Interface) [6], which describes an interface for programs. Further, SSI (Server Side Includes) is a term for scripts, embedded in the HTML-pages, and executed in the server’s environment.

These technologies require a Web server that is able to execute code when a user’s request is received. The output of these programs usually is HTML. This leads to another issue: the mixture of logic and content, called ‘content-in-logic’ . The function of the following C program (example 4) is adding up two given numbers. The printf-command writes content mixed with HTML-structure (shown bold). Logic, structure, and content is mixed:


main() { int val1, val2; char *str1, *str2; printf("Content-type: text/html\n\n"); printf("<html><head><title>the sum of two numbers</title></head>\n"); printf("<body><h1> the sum of two numbers</h1>\n"); str1 = getval("number1"); str2 = getval("number2"); if(str1 == NULL || str2 == NULL)

printf("<p>Input data error.</p>\n"); else { val1 = atoi(str1); val2 = atoi(str2); printf("<p>The sum of %d and %d is %d</p>\n",val1, val2, val1+val2); } printf("</body></html>\n"); }

Example 4. A CGI program in C to calculate the sum of two numbers

The reason for the evolution taking a further step is that these simple technologies are useful for handy Applications, but, when implementing large projects, development and maintenance increase in complexity exponentially. Besides, it is more difficult to use software engineering methodologies on such low-level technologies.

1.5 Component Web At this phase of Web-technologies high level languages have been adopted to Web-languages. JSP (Java Server Pages) and Java Servlet technologies [7] are based on Sun’s Java specification, specialized to deal with Web issues. ASP (Active Server Pages) [8] is based on the Microsoft Basic language. These advanced technologies allow software engineering for Web applications by using design tools and patterns.

JSP and ASP have logic parts embedded in the content. Vice verse, Java Servlet technology has content in its logical components.

Overall, this step does not explicitly support, but allow content, layout, and logic separation (e.g., by using the MVC design pattern). Although, a clean separation is achieved, these technologies suffer an architectural issue:

The content that is dynamically created usually is generated in the target language (e.g., HTML) rather than device-independent. By dynamically creating the target’s device language, the processing architecture is usually nested processing (figure 4, left graphic). I.e., the generation is based on sub-calls, which return the content in the target language. However, nesting processing has a major drawback: output is created once by appending pieces, and sent to the end-user. It cannot be re-processed as a whole, since most of the target languages lack in being reusable (e.g., HTML).


Figure 4. Nested processing vs. chaining processing

Botterweck argues [9] that an architecture is preferable where the content is created first, regardless of the target-device. Finally, the generic content is transformed to the requested target format. That issue leads to the next step.

1.6 Separation of Concerns (SoC) XML (eXtensible Markup Language) [10] is a data definition language (evolved from SGML) designed to structure data and describe information. Unlike the predefined tags of HTML, the author can define his own tags without constraints. XML is highly versatile and can be used to describe virtually every information-content.

The Document Type Definition (DTD) or more recently XML Schemas [11], which itself is XML, are part of the XML specification. These standards are used to define the vocabulary and the syntax of the employed XML tags.

XSL (eXtensible Stylesheet Language) [12] is an XML compliant language, which enables the transformation of XML documents into other types of documents e.g., HTML, plain text, or PDF. XSL is derived from DSSSL and CSS. It consists of two languages: XSL-T and XSL-FO. XSL-T is a processor that transforms from one to another XML document. XSL-FO renders a page output of a document.

These standards are more extensive and difficult than HTML, but the advantages are worth it:

By describing the content in XML and using XSL to specify the layout, a complete layout-content (LC) separation can be achieved. This means, that content and layout can be re-used independently. The layout can be applied to several content, to achieve consequent layout formatting. In addition, by using several stylesheets on a single content, it can be layouted manifold, and by generating different target formats, device independence can be achieved.

The transformation is done either on the server, or on the client side. For the transformation, XML technology like parser and transformer is required. The transformation on the server brings the benefit that there are fewer requirements for the user’s apparatus: the client device is not affected by the complexity, and less data is transferred. When the client does the transformation, the transfer volume is higher, but the server’s load is less.

There are a number of systems providing this technology. However, basically any technology where XML/XSL components exist can be used. Nevertheless, dynamics are not implied in this phase. Thus, the next step takes place.


1.7 Dynamic Separation of Concerns (SoC) This phase enhances the above technology with dynamic logic. Figure 5 depicts a pipeline for information processing where concerns are decoupled:

1. The request comes in and its content is extracted.

2. Business logic is processed, e.g., calculations are started, or data is updated.

3. Content of the reply message is generated, e.g., data is read from a database. In the figure, chaining processing is depicted, where the content can be generated from multiple sources, every one extending the prior one.

4. The content is selected and/or transformed, e.g., sorted or filtered. In this step, multiple filters or generators can process the data several times.

5. The layout according to the needs of the target devices is processed, and the message is sent to the client device.

6. The client device does the layouting and presents the message to the user. If the user interacts, a further request is started.

Figure 5. Pipeline of information processing

The technology is achieved by XSP (eXtensible Server Pages) [13], which are based on JSP. The difference is that the output is XML. Stylesheets with logic are often referred to as logicsheets. In contrast to JSP, XSP allows chaining processing (Figure 4, right graphic), i.e., generated content can be modified in succeeding steps.


On the server side, a publishing framework is preferable, due to the system’s complexity. It combines all the technologies (XML, XSL, XSP, etc.) and eases their usage. There are a couple of frameworks, two are most improved: Cocoon [13] and AxKit [14]. The main difference between these two is that Cocoon (developed by the Apache Group) is based on Java, and even more advanced. AxKit is based on PERL (‘Practical Extraction and Report Language’), which is a common scripting language for Web-Applications.

Finally, the claim for a preferred architecture, where the content is generated first and the transformation is done afterwards, is accomplished [9]. A clean separation of content, layout, and logic is achieved.

1.8 Contract-based Web Nevertheless, due to the increased system’s complexity the time-to-market must be considered. To shorten the development time of a Web application, parallelism of the development steps should be aimed at. Contract-based Web technology [15] achieves parallelism by specifying ‘contracts’ , which are clear interfaces between the concerns of involved people. Contracts mirror the interface concept of software engineering on Web technologies. These contracts are defined at design time, thus from then development can be take place in parallel. Additionally, contracts can be seen as specifications for Web sites, which is a step tending Web engineering methodologies.

1.9 Summary The evolution of Web technologies, which was driven by manifold requirements, has gone through several phases. It started with simple publishing techniques and headed to technologies that imply recent engineering methodologies.

Designing a Web site today not necessarily mean using the most advanced technology, but rather using the appropriate one:

For example, if the HTML functionality is sufficient for a Web application, the component Web technology usually is the chosen one: keeping things simple with the usage of engineering methodologies.

Moreover, when designing Web-Applications for various devices, a more sophisticated technology should be chosen to avoid publishing and maintenance problems. If multiple target systems are required, the ‘Separation of Concern’ technology should be taken into consideration. It is the basic technology to developing platform independent applications.


1.10 References [1] World Wide Web Consortium: Dave Raggett, Arnaud Le Hors, Ian Jacobs: HTML 4.01

Specification, 24 December 1999 available online http://www.w3.org/TR/html401

[2] World Wide Web Consortium, Håkon W. Lie, Bert Bos: Cascading Style Sheets (CSS1) Level 1 Specification, 11 January 1999 available online http://www.w3.org/TR/REC-CSS1

[3] World Wide Web Consortium: Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs: Cascading Style Sheets, level 2 (CSS2) Specification, 12 May 1998 available online http://www.w3.org/TR/REC-CSS2

[4] Bert Bos: Using CSS to achieve device-independence, Position paper for “device context” workshop (W3C), March 2002 available online http://www.w3.org/2002/02/DIWS/submission/

[5] Michael Reimann: XSL, November 2000 [6] David Robinson: The WWW Common Gateway Interface Version 1.1, 16th October 1995. [7] Sun Microsystems, Inc.: JavaTM 2 Platform, Enterprise Edition 1.3 Specification, 24 Sep, 2001

available online http://java.sun.com [8] Microsoft Corporation: Active Server Pages Guide [9] Gö tz Botterweck: Ensatz von XML und WAP zur Realisierung strukturierter, ubiquitä rer

Informationsdienste, Universität Koblenz-Landau [10] World Wide Web Consortium: Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler:

Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation, 6 October 2000 available online http://www.w3.org/TR/REC-xml

[11] World Wide Web Consortium: XML Schema Part 0: Primer, W3C Recommendation, 2 May 2001 available online http://www.w3.org/TR/xmlschema-0/

[12] World Wide Web Consortium: James Clark: XSL Transformations (XSLT) Version 1.0, 16 November 1999 available online http://www.w3.org/TR/xslt

[13] Apache Group: Apache Cocoon available online http://xml.apache.org/cocoon/

[14] Matt Sergeant: AxKit – XML Application Server, 2000, available online http://axkit.org/

[15] C. Kerer: Contract Based Web Development, Distributed System Group, University of Vienna [16] Mark H. Butler, Hewlett-Packard: Current Technologies for Device Independence, 4 April 2001


2 Web Engineering Methodologies Gaedke and Graef [11] describe Web-Engineering (WE) as “The application of systematic, disciplined and quantifiable approaches to the cost-effective development and evolution of high-quality applications in the World Wide Web”. Table 1 provides an overall view of today’s most common Web-Engineering methodologies, evaluated by a number of aspects: 1. Supported phases In classical software engineering, the development process is divided into these phases: analysis, design, implementation, and finally test and maintenance (the so called waterfall model). These phases can be reflected on the Web-Engineering development process and it can be examined, which of them are supported. However, because WE methodologies support generation rather than implementation, a separation between construction and realization is made:

The difference is that after the construction phase the generated application is rather a skeleton than the final application. Subsequently, after generating the application the need for further modifications leads to an implementation phase. The resulting applications tend to have maintenance problems.

In contrast, when speaking of realization, the result of the generation is the final, working application. 2. Paradigm based on WE methodologies are more or less derived from either software engineering, or database engineering, or both. Since the early development of dynamic Web applications was driven by the requirement to integrate databases, the earlier WE methodologies concentrate more on traditional database-backed hypertext applications. The latter WE methodologies tend towards Software-Engineering methodologies, based on an object-oriented paradigm. 3. Primarily designed for Most of the WE methodologies have been developed to support a certain kind of application. Earlier methodologies were intended for applications with a structured information domain, and a database as data-source. The latter ones supported all kinds of Web applications. 4. Methodology approaches from The different methodologies start their process from different points. Some describe the domain by specifying a model consisting of objects and relations. Others start by describing the structure of the data by an Entity-Relationship model, or they begin with examining the user’s requirements. 5. Level of Abstraction The analyses in the development process take place at different levels of abstraction. The abstraction is said to be high, if a methodology does not commit to an architectural details in its phases. In contrast, the abstraction is low if architectural details are considered from the beginning of the process.


6. Output of tools and compilers All WE methodologies provide more or less good mapping from the design phase to the actual implementation. This criterion evaluates the supported target formats (e.g., HTML, XML, etc.) of the methodology’s tools and compilers. 7. Content and layout separation This issue evaluates whether the methodology considers the separation of content and layout, discussed in the last chapter. Earlier WE methodologies support the decoupling only in the way of data from databases. 8. UI design Today, usability of software applications is an important matter. Since high usability is derived from structured navigational design as well as self-explaining user-interfaces (UI), WE methodologies should consider the analysis of the audience in their early design phases, followed by a navigational design, and a user-interface design. 9. Modularity and explicit support for reuse Modularity is the notion that software is partitioned in distinctive functions or modules. These modules can be developed and maintained independently. Due to high modularity, the factor of re-use increases. While code re-use today is the most common form, design-modules, navigational models, use-cases, interfaces, documentation, etc. can be re-used. This issue investigates, whether the WE methodology supports modularity and re-use in its phases. 10. Maintenance and re-generation Most applications are not static and change their requirements with time. Thus, maintenance and the possibility to adapt to changes easily is an important cost-factor. It is known that maintenance of a Web application consists more than 60% of the total costs. That fact even more leads maintenance to be a serious task. Since all WE methodologies provide a functionality to generate applications, the effort of maintenance depends on the quality of generation. If the generated code makes further (i.e., post-generation) modifications necessary, then changing the design and consequently re-generating cause a lost of post-generation modifications and make them necessary again. Either a WE methodology must preserve post-generation modifications, or the quality of the output is sufficiently high, so that no further changes are needed. 11. Dynamics and business-logic All of today’s Web-applications have in common, that they provide dynamic functionality. This functionality can be simple calculations, database functionality, interface calls, site layout, or processing and business logic. Since dynamics are a main concern of application development, a WE methodology should be able to imply dynamic functionality in a wide scope. 12. Support of the ‘Separation of Concerns’ (SoC) technology As described in the previous chapter, the ‘Separation of Concerns’-technology has certain benefits during development as well as for maintaining applications. Here, the issue is addressed, if the methodology does separate between content, layout, and logic, and if the methodology’s phases reflect this separation.


2.1 Comparison of Engineering Methodologies

OOHDM RMM

(+ RMC) WSDM JESSICA WebML W3DT Web

Composition

Reference [1], [2], [3] [4], [5] [6] [7] [8] [9] [10], [11], [12]

supported phases 1

analysis, design

analysis, design,

construction design

analysis, design, realization,

maintenance

analysis, design

design, construction

design, realization,

maintenance

paradigm based on 2

database, object

oriented

database design

user interface design

object oriented

object based,

relations

object based

object oriented

primarily designed for 3

Applications with structured

information domain

Applications with database

kiosk Web sites (information &

navigation)

large, generated web sites

Applications with structured

information domain

Web applications

(unstructured)

Web applications

approach from 4

structural model

data (bottom up: E-R to UI)

user (i.e., UI)

structural model ??

structural model

structural model

(top down)

structural model ??

level of abstraction 5

high & low high very

high low high & low high high &

low

output of tools & compilers 6

HTML, Director,

Toolbook, Hypercard

RMC: HTML x

not explicit but tools for HTML

primary HTML, but any

HTML, WML, also XML; JSP, ASP

HTML, CGI-Script

WCML: HTML, XML,

etc.

CL separation 7

+ (database)

+ (database)

x + + ~

equivalent to CSS-level

+

UI design 8 + (ADV)

~ (nav. design)

++ - + + -

modularity / explicit reuse

9 +

~ (limited to

data) + + + + +

maintenance / re-

generation 10 - - x + + - +

dynamics / logic 11 ~

~ primary DB

x + + +

CGIs +

separation of concerns 12 - - x + + - +

+: supported, ~: partly supported, -: not supported, x: no requirement


2.2 OOHDM (Object-Oriented Hypermedia Design Method) OOHDM is based on HDM (Hypermedia Design Model). HDM is based on the idea, that Hypertext can be seen as entities and their relations (links i.e., navigational paths).

The idea behind HDM is that there are two different kinds of views [1]: ‘authoring-in-the-large’ and ‘authoring-in-the-small’ , where authoring-in-the-small deals with the application’s details of behavior and implementation, and authoring-in-the-large deals with the overall application’s organization and behavior. However, HDM has shortcomings in re-using the model and provide little support for building user views.

OOHDM extends HDM in the way of the object-oriented paradigm, where the design activities allow composition mechanisms (e.g., classification, aggregation, and inheritance hierarchies), which leads to abstraction and reuse. Further, OOHDM introduces several visual schemas to enhance the expressively of the model.

One interesting feature of OOHDM is that of ‘navigational contexts’ [2, 3] explained in step 2.

The methodology of OOHDM comprise four different activities [3]: (1) Conceptual Design: during this design phase the application domain is specified. First

object-oriented classes are defined, where aggregation and generalization/specialization hierarchies may be used. The product of this step is a conceptual schema (Figure 6 shows and example), which consists of these classes, sub-systems, and relationships. UML [14] notation is used in this step.

Figure 6. Example of a conceptual schema


(2) Navigational Design: in this phase a navigational model is specified, which can be seen as a view (in the sense of databases) of the conceptual model. The navigation model consists of a navigational class schema and a navigational context schema. In a navigational class schema the navigable objects of the hypertext application are defined, i.e., nodes, links, and access structures. A node is an object-oriented view of one or more (i.e., combined) conceptual classes (defined in step 1), links reflect navigational relationships, and access structures can be indexes or guided tours. A navigational context schema consists of context classes, which complement the navigational classes with the information, which information is shown, and which links are available, depending on a particular context. A navigational context is depending on how the user explores the hypermedia space. For example, a Web page may look different depending whether a user accessed the page in a guided tour (showing a link to the next page of the tour), or from an index page (showing a link back to the index).

(3) Abstract Interface Design: this step deals with the (user) interface objects. The Abstract Data View (ADV) design approach is used for describing the user interface.

(4) Implementation: deals with the mapping of the designed application to a concrete application. Unfortunate, this step is described in not much detail.

Since HDM and OOHDM methodologies were intended to develop applications with structured information domain behind, they are primarily useful for creating traditional Hypertext systems. The major drawback is the weak mapping functionality (activity 4). This results in poor construction of the application and serious maintenance issues. Further, HDM and OOHDM do not intend SoC for the generated application.


2.3 RMM (Relationship Management Methodology) RMM is a methodology for the structured design of hypertext systems. It is used to design and manage the relationships among various information domains to produce structured hypermedia documents.

RMM is focusing on the design phase and is a ‘data driven’ approach, which means that the available data is the starting point of the modeling approach. Thus, the design process is primary bottom-up, from the data structure to the user interface design. The methodology is heavily DB centered, and looks at Hypermedia as a relationship among objects.

To describe this relationship, RMM introduces a graphical design model called RMDM (Relationship Management Data Model – figure 7), which is based on the Entity-Relationship (E-R) Model. RMDM uses the notation, which is widely accepted for E-R diagrams, and enhances it by additional notation. In figure 1, there are three groups of notations: E-R primitives (“how the information is structured” - design step 1), which are inherited from E-R diagrams, slices (“how the information is to be presented” - design step 2), and access primitives (“how the navigation is modeled” – design step 3). Access primitives are navigational notation elements, describing how the user will navigate through the application using hypertext links, grouping, and indexes.

Figure 7. Relationship Management Data Model (RMDM) primitives

There is a separation of data, structure, and user-interface, which is reflected in the seven design and development stages [4] (figure 8):

(1) E-R Design: entities and relations are defined based on database-design. (2) Slice Design: a slice exists of a number of attributes of an entity (i.e., a group of attributes)

to be presented to the user. It can be compared to the view-concept in database domain: for example, a person entity with attributes name, age, picture, and resume may have a general slice with name, age, and picture, and a resume slice with name, and resume.


(3) Navigation Design: the navigational structure (links, indices, guided tours, etc.) is defined using the RMDM’s access primitives.

(4) Conversion protocol design: E-R and Navigational Design are transformed to the target platform by mapping each element on an object of the target system (e.g., HTML, Toolbook, etc.). The mapping is marginally touched in RMM [4], but is a major concern of RM-CASE (see below).

(5) User Interface screen design: based on the RMDM diagram, the screen layout is designed. This step is mainly covered by the RM-CASE tool explained later.

(6) Run-time behavior design: define which information is static and which is dynamically generated during runtime.

(7) Construction and testing: the application is generated and tested.

Figure 8. The RMM design methodology

These steps are supported by RM-CASE [5]: a computer-aided environment to guide through the steps of the RMM. For example, when designing the user interface (step 5), for each node and anchors of the RMDM an HTML template can be defined.

There is an extension of RMM called e-RMM (Extended RMM) [15], which introduces an application diagram depicting the entire application. This diagram replaces RMM’s navigation diagram. Further, an advanced slice design called m-slices is introduced, which allows combining elements from any entity in the E-R diagram.

As OOHDM, RMM has the drawback that the design is restricted to a specific class of applications and the SoC technology is not intended. However, RMM is less expressive than OOHDM, since RMDM provides a single view of the domain only.


2.4 WSDM (Web Site Design Method) This methodology is ‘user centered’ rather than ‘data centered’ . The starting point is the set of potential visitors and their information requirements. Through this, WSDM ease usability problems. WSDM is a high-level method, specifying the overall design. The concept does not imply the design and structure of the data. Therefore, the process is not tied to any technology. Nevertheless, WSDM was invented to design kiosk-type Web sites, where the presentation of the information stands in first place.

The methodology consists of four steps [6] (figure 12): (1) User Modeling: visitors and their activities are analyzed (figure 9). Additionally, user

classes are defined and their information requirements (the “what”) and their characteristics (how the information should be presented – the “who”) are specified.

Figure 9. An example of an environment analysis

(2) Conceptual Design: this phase consists of two sub-phases: Object Modeling and

Navigational Design. In Object Modeling, informational requirements and perspectives are formally described by choosing one of several methods (e.g., E-R, OMT - figure 10).

Figure 10. Example of a Object Modeling diagram


In the Navigational Design, the navigational structure of the Web site is designed, by using a Perspective OT (figure 11).

Figure 11. Example of a Navigational Design Diagram

(3) Implementation Design: design of the “ look and feel” of the Web site and creation of a

consistent, pleasing, and efficient look. WSDM refer to other literature, but gives a number of guidelines for this phase.

(4) Actual Implementation: the actual realization of the Web site.

Figure 12. Overview of the WSDM phases

In Summary, WSDM is good to design front-ends and design the “ look and feel”, but it does not either explicitly design, or manage dynamic data. It is advisable to combine it with a second methodology to design the structure of the data and dynamics.


2.5 JESSICA JESSICA is a system to describe components in an object-oriented language. To publish a Web site, these abstract definitions are compiled into a dynamic Web service (Figure 13). The JESSICA system follows the RMM methodology and its methodical steps. Use Cases are designed for analysis; UML [14] is used to specify the design of a specific application.

Figure 13. The architecture of the JESSICA compiler

The syntax [7] is based on SGML, and objects, templates, packages, pragmas, and interrelationships can be defined and managed. By definition, every object has a MIME type (e.g., “ text/html”), which allows using various output formats. Templates are objects with variable parts (Example 5). When instantiating (Example 6), these parts are replaced, which allows the creation of dynamic pages and layouts. Moreover, templates are used to manage the content - layout separation. This is done by packing the layout into templates and instantiating them several times with different content.

<<OBJECT NAME=”CuteLayout”>> <HTML> <HEAD><TITLE><<VAR NAME=”title” />></TITLE></HEAD> <BODY>Yet another <<VAR NAME=”title” />> example.</BODY> </HTML> <</OBJECT>>

Example 5. A JESSICA template encapsulating HTML-syntax

<<OBJECT NAME=”HelloWorld” SRC=”package:this.CuteLayout”>> <<PACKAGE>> <<OBJECT DST=”package:this.HelloWorld.title>> HelloWorld <</OBJECT>> <</PACKAGE>> <</OBJECT>>

Example 6. A JESSICA object instanciation


A major advantage of JESSICA over other WE methodologies is the ability to integrate static hypermedia documents into the development process, even if they include server side scripts. This feature enhances the ability to re-use existing content dramatically. JESSICA was primarily designed to generate HTML as output format. Although it is not explicitly described, the SoC technique would fit into the concept of JESSICA.

2.6 WebML (Web Modeling Language) WebML is a Web model language designed to support high-level, platform independence specification of data-intensive Web applications. There is a supporting CASE environment, called Toriisoft, which consists of a number of design tools.

In WebML there are four orthogonal perspectives [8] which mirror the concerns of the individuals of an separation of concern schema:

(1) Structural Model: expresses the data content by using entities and relations:

Figure 14. Example of structure schema

(2) Hypertext Model: describes the hypertext structure by using a Composition Model and a

Navigation Model. A Composition Model defines the content of a page, e.g., information, index, menu, etc. This is done, by defining a data model (Example 7), which is defined in Object-Oriented XML syntax.

<ENTITY id="Album"> <ATTRIBUTE id="title" type="String"/> <ATTRIBUTE id="cover" type="Image"/> <RELATIONSHIP id="Album2Track to="Track" inverse="Track2Album" minCard="1" maxCard="N"/> </ENTITY> <ENTITY id="Track"> <ATTRIBUTE id="number" type="Integer"/> <ATTRIBUTE id="title" type="String"/> </ENTITY>

Example 7. An example of a WebML Composition Model


A Navigation Model expresses the links between the content units. The typical process separates between: Hypertext design ‘in the large’ (develops a skeleton site structure), and ‘in the small’ (considering each page individually).

(3) Presentation Model: expresses the layout, independent of the output device by using a style sheet. WebML pages are rendered according to a given style sheet for a specified device.

(4) Personalization Model: describe group or user specific design to describe individual content (e.g., personal favorites).

The Toriisoft tool suite translates the given input into a concrete markup language (HTML, WML, etc.) and the dynamic parts into a server side scripting language (JSP, ASP, etc.). The generator converts the final application. Modifications for maintenance are applied to the model, which does not raise the re-generation issue.

Since XML is supported as a target format, the SoC technique can be applied easily.

2.7 W3DT (World Wide Web Design Technique) W3DT consists of a modeling technique as well as a computer based design environment. In contrast to RMM and OOHDM, W3DT was designed to support the requirements of unstructured, hierarchical domains.

The design consists of two phases [9]:

(1) Designing a graphical representation of a Web-site’s structure with a notation that is derived from the functionality of HTML and dynamic content generation. To model a Web site, the following design primitives are defined [9] (figure 16): To define a Site a Diagram is defined. Diagrams enable a collaborative design that

consists of (1) Layout: formatting specification like header, background, etc. (2) Link: a hypertext reference (3) Page: the content itself, which can be a Form, Index, or Menu.

Figure 15. The W3DT Meta Model


The modularity of the model is gained by sub-diagrams that can be re-used. W3DT also supports dynamics (figure 15): The oval icons shown in the second column are so called Templates, representing dynamically generated page. Further, a difference is made between static and dynamic links.

Figure 16. W3DT design primitives

(2) Using a computer based environment for generating and running prototypes, called

WebDesigner. This CASE-tool is capable to generate HTML pages and CGI-Script (e.g., for accessing DB content).

In Summary, W3DT is a visual high-level methodology that reflects the functionality of HTML. Further, WebDesigner is the only tool, capable to generate dynamic applications. Re-use is supported well. W3DT and the extended version eW3DT [16] can be used complementary to RMM to provide a better mapping from the model to the final application. However, due to the primary support of HTML, the ‘Separation of Concerns’ technique is not supported.


2.8 WebComposition WebComposition is based on today’s widely accepted object-oriented model. According to this model, a Web-application is hierarchically decomposed into components [13]. These components may be of arbitrary granularity: ‘higher’ components may describe a document, ‘lower’ components just a specific link on a page. The components’ definition is based on the OO-model, thus aggregation (‘has-part’) and specialization (‘inherits-from’) is possible.

WCML (WebComposition Markup Language) is an application of XML to describe WebComposition components, their properties, and their relationships [12]. Example 8 depicts a simple WCML component definition to show how components are described, and how the object hierarchy works.

Example 8. A simple WCML example

Unlike most of the other WE methodologies, WebComposition supports a variety of target systems. Also multi-platform publishing is supported, by reusing a single content for different target languages. Therefore, the decorator design pattern can be adopted (figure 17), which easily uses different navigation and layout for one existing content [18].


Figure 17. Decorator use for Navigation and Layout

Figure 18 depicts WebComposition’s overall architecture. The WCML parser is responsible to generate the target format (e.g. HTML) from the repository’s component description.

Figure 18. WebComposition’s overall architecture

Similar to WebML, maintenance issues are avoided by doing changes in the model and re-generating. Because the output is intended to be the final application, no further changes have to be applied.

In summary, WCML is independent of the target language. By using XML-namespaces even XML itself can be generated. Further, by allowing embedded dynamics (e.g., XSP), WebComposition is capable to fulfill the ‘Separation of Concerns’ requirement.


2.9 Summary This chapter’s purpose was to prove that when developing reliable Web applications nowadays, the use of a Web-Engineering methodology is superior to the widely used ad-hoc programming. Most of the discussed methodologies provide models for a well-guided design phase, clear and understandable graphical representation of the structure, and finally a mapping to the desired target system. These utilities simplify the development and maintenance of complex Web sites, and further more support distributed development.

OOHDM and RMM have a well-guided design-phase with expressive visual models and diagrams. They are useful for Web applications with a structured information domain behind. For example, when designing a Web interface for an existing database, these methods provide good support. Their problem is the weak mapping from design to the application.

In contrast, WSDM is a user-centered methodology, having a strong usability design phase. Due to its high level of abstraction, its weakness lies in the area of data and structural design, and dynamics.

JESSICA follows the RMM methodology. JESSICA uses a scripting language to describe objects, which makes an early implication of implementation issues possible. The advantage over RMM is the object orientation and the mapping from the design to the final implementation. The better mapping, which is the weak point of RMM and OOHDM, results in easier maintenance and better reusability.

W3DT is a visual abstraction layer to HTML, primarily supporting the construction phase. It is capable of designing static as well as dynamic Web applications of various domains. WebDesigner is the only WE environment providing a generation of both static HTML pages and dynamic CGI-Scripts. Therefore, its sophisticated mapping functionality makes W3DT a methodology that may be used complementary to others (RMM, OOHDM).

WebComposition, WebML, and JESSICA are the latest approaches. They are object oriented in a way software engineers are used to think, and they have a properly designed mapping from the abstract definitions to the desired output format. Further, they are the only methodologies that completly support the ‘Separation of Concern’ technique. As stated in chapter one, SoC Web technology is the key concept to achieve device independence.

Nevertheless, depending on the desired Web-Application, some of the methodologies might be too complex. If the project does not have a certain extent, due to the overhead the time spent might exceed the profit earned. Thus, it should be well considered which methodology is taken, because some are more time consuming than others, and finally don’t provide running application as a result (OOHDM, RMM, etc.).

For a less time consuming engineering phase, the technologies that support scripting (WebML, JESSICA, and WebComposition) seem to be a better choice than the ones providing visual models only. Since the used scripting language is closer or even implies the implementation phase, the time spent is recovered when generating the application. Since the scripting languages are design oriented, still these methodologies provide the benefits of Web methodologies.


2.10 References [1] Garzotto, F.; Mainetti, L.; Paolini, P.: Hypermedia design, analysis, and evaluation issues. In:

Communications of the ACM 38 (1995) 8, pp. 74-86. [2] Garzotto, F.; Paolini, P.; Schwabe, D.: HDM – A model for the Design of Hypertext Applications.

Hypertext’91. (1991), pp. 313-326 [3] Schwabe, D.; Rossi, G.; Barbosa, S.: Systematic Hypermedia Design with OOHDM. ACM

International Conference on Hypertext’ 96. Washington, USA (1996). [4] Isakowitz, T.; Stohr, E. A.; Balasubramaninan, P.: RMM: A Methodology for Structured

Hypermedia Design. In: Communications of the ACM 38, No. 8 (1995), pp. 34-44. [5] Díaz, A.; Isakowitz, T.; Maiora, V.; Gilabert, G.: RMC: A Tool To Design WWW Applications. In:

The World Wide Web Journal 1 (1995). [6] De Troyer, O. M. F.; Leune, C. J.: WSDM: a user centered deseign method for Web sites. In:

Computer Networks and ISDN Systems 30 (1998) Special Issue on the 7th Intl. World-Wide Web Conference, Brisbane, Australia.

[7] Barta, R. A.; Schranz, M. W.: JESSICA: an object-oriented hypermedia publishing processor. In: Computer Networks and ISDN Systems 30(1998) (1998) Special Issue on the 7th Intl. World-Wide Web Conference, Brisbane, Australia, S. 239-249.

[8] Ceri, S., Fraternali, P., A. Bongio: Web Modeling Language (WebML): a Modeling Language for Designing Web Sites, Proceedings of the WWW9 Conference, Amsterdam (2000)

[9] Bichler, M.; Nusser, S.: Modular Design of Complex Web-Applications with W3DT. In: IEEE 5th Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, Stanford University, California, June 19 – 21, 1996

[10] H.-W. Gellersen; M. Gaedke: Object-Oriented Web Application Development. In: IEEE Internet Computing. Vol. 3, No. 1, p. 60-68, Jan/Feb, (1999)

[11] M. Gaedke, G. Graef (2000): Development and Evolution of Web-Applications using the WebComposition Process Model. International Workshop on Web Engineering at the 9th International World-Wide Web Conference (WWW9), Amsterdam, The Netherlands, May 15, 2000.

[12] Gaedke, M.; Schempf, D.; Gellersen, H.-W.: 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).

[13] Hans-Werner Gellersen, Robert Wicke, and Martin Gaedke. WebComposition: an object oriented support system for the Web engineering lifecycle. In the proceeding of the 6 th international World wide Web conference, April 97, Santa Clara CA

[14] OMG: Unified Modeling Language Specification available online http://www.rational.com/uml/, June 1999

[15] T. Isakowitz, A. Kamis, and M. Koufaris: The Extended RMM Methodology for Web Publishing. Working Paper IS-98-18, Center for Research on Information Systems, 1998

[16] Arno Scharl: Reference Modeling of Commercial Web Information Systems Using the Extended World Wide Web Design Technique (eW3DT). HICSS (4) 1998: 476-484

[17] Martin Gaedke, Chrstian Segor, Hans-Werner Gellersen: WCML: Paving the Way for Reuse in Object-Oriented Web Engineering. 2000 ACM Symposium on Applied Computing (SAC 2000), Villa Olmo, Como, Italy, March 19-21, 2000.

[18] Martin Gaedke, Fernando Lyardet, Hans-Werner Gellersen: Hypermedia Patterns and Components for Building better Web Information Systems. Proceedings of the Hypertext99 (HT99) Workshop on Hypermedia Development - Design Patterns in Hypermedia, February 21, 1999.


3 Outlook and future work

WE scripting languages and the concept of ‘Separation of Concerns’ grew very close to each other. However, both suffer in certain details: None of the WE methodologies provide support for the design of dynamic functionality (i.e., design of business-logic). On the other hand, SoC is a concept, which does not provide an engineering methodology and is more likely an ad-hoc approach.

Ultimately, if these concepts are used complementary (e.g., Cocoon technology with WebComposition methodology) it would connect different approaches and combine their advantages.

Composition of Web Technologies and Web Engineering Method€¦ · 4 component web JSP, Servlet,...

Documents

Transcript of Composition of Web Technologies and Web Engineering Method€¦ · 4 component web JSP, Servlet,...