See discussions, stats, and author profiles for this publication at: [Link]

net/publication/3419231

Object-Oriented Web Application Development.

Article in IEEE Internet Computing · February 1999

DOI: 10.1109/4236.747323 · Source: IEEE Xplore

CITATIONS READS
159 2,212

2 authors:

Hans Gellersen Martin Gaedke

Lancaster University Technische Universität Chemnitz
274 PUBLICATIONS 11,337 CITATIONS 250 PUBLICATIONS 2,507 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Search Interaction Optimization: A Human-Centered Design Approach View project

Accessing data in RDF graph structures View project

All content following this page was uploaded by Martin Gaedke on 12 April 2016.

The user has requested enhancement of the downloaded file.

. IEEE Internet Computing, vol. 3(1), pp. 60-68, 1999

WEB OBJECT MODELS

OBJECT-
ORIENTED WEB
APPLICATION
DEVELOPMENT

Most Web applications H ANS -W. G ELLERSEN AND M ARTIN G AEDKE

University of Karlsruhe

are still developed ad hoc.

One reason is the gap

T
he Web has evolved into a global environment for delivering all
kinds of applications, ranging from small-scale and short-lived ser-
vices to large-scale, enterprise workflow systems distributed over
between established many servers. Applications that use HTML-based front ends benefit from
the pervasive distribution of Web browsers for universal, cross-platform
access. Another striking advantage of Web delivery lies in the concept of
software design concepts thin clients and centralized maintenance, facilitating instantaneous deploy-
ment of software updates at minimal cost. While the popularity of the
Web and its advantages as a client-server platform have led to countless
and the low-level Web HTML-based applications, the development of Web applications is still
mostly ad hoc. There is no rigorous, systematic approach, and most current
Web application development and management practices rely on the
implementation model. knowledge and experience of individual developers.
One reason for the lack of a structured approach may be in the Web’s
legacy as an information medium rather than an application platform.
Web development is seen primarily as an authoring problem rather than a
software development problem to which well-established software engi-
neering principles should apply.
We believe another reason is that the Web implementation model does
not relate well to state-of-the-art software development models. Web
implementation is based on low-level technologies that do not provide
high-level abstractions for sharing and reuse. The lack of suitable abstrac-
tions makes it difficult to construct frameworks that capture architectur-
al design decisions for reuse in different parts of an application or in dif-
ferent application projects. The lack of abstraction also makes it difficult to
maintain and evolve Web-based applications. Design decisions are very
hard to track in a low-level implementation; as the application evolves,
changes can easily lead to inconsistencies. Because Web-based applications
tend to evolve quickly, with frequent updates and redesigns, poor main-
tainability is a critical problem.

60 JANUARY • FEBRUARY 1999 [Link] 1089 -7801/ 9 9 /$10.00 ©1999 IEEE IEEE INTERNET COMPUTING
 .
IEEE Internet Computing, vol. 3(1), pp. 60-68, 1999

W E B A P P L I C A T I O N D E V E L O P M E N T

In this article we summarize work reported ear- a Web-based software solution and must accom-
lier on WebComposition,1 a model for Web appli- modate this.
cation development, then introduce the Web- The implementation transforms the design into
Composition Markup Language—an XML-based actual software. For Web applications, this phase has
language that implements the model. WCML to rely on available Web implementation technology.
embodies object-oriented principles such as mod- Finally, maintenance is concerned with modifi-
ularity, abstraction, and encapsulation. It facilitates cations to the software, which may occur at the
the description of higher level concepts and frame- implementation, design, or even analysis levels.
works for reuse that can bridge the gap we currently General software processes are hard to relate to the
perceive in Web application development between Web implementation model, as will be discussed
high-level design and low-level implementation. below. The Web implementation model is based on
We begin with a discussion of why the basic flat decomposition of applications into resources.
Web implementation model does not work as a Resources have a unique address, and they are
development model for Web applications. Related delivered on request from Web server to Web
work is presented in the sidebar, “Structured Web client. They can be static or dynamically generat-
Application Development,” on page 62. ed from a script, but they are inherently specific,
which means that they cannot capture abstractions.
WEB APPLICATION
DEVELOPMENT PROCESS Document Delivery Applications
We define a Web application as any software appli- The World Wide Web was originally designed as
cation that depends on the Web for its correct exe- an information medium for distributed research
cution. Obviously, software explicitly designed for teams.4 A key objective was to make it as easy as
delivery over the Web falls under this definition— possible for authors to deliver documents, and the
for example, Web sites or Web-based journals. notion of Web application development essential-
These kinds of software are characterized by a ly boiled down to document development by an
strong notion of content. author or small group of authors. For this kind of
We also include software that uses the Web development, the life cycle comprises informal
infrastructure for its execution. For example, many analysis of what is to be presented, informal design
information systems that were designed and built of how to structure it into hyperlinked chunks of
prior to the Web are now made available as Web information, and implementation through
applications through the use of browsers. Beyond markup. Following implementation, the docu-
legacy information systems, there is also software ments are maintained by the authors themselves.
that is less typical for delivery over the Web but still The Web implementation model was designed
dependent on it as the client-server platform for its to meet these life-cycle requirements. It is deliber-
execution. Two recently reported examples ately simple, based on the notion of resources that
addressed the coordination of distributed applica- model mostly self-contained chunks of informa-
tions2 and remote monitoring.3 tion. Resources are authored and maintained
rather independently of other resources, and links
General Software Development are the means by which resources can be combined
Conventional software processes usually address into coherent sets of documents—for example, a
four development phases: analysis, design, imple- Web site.
mentation, and maintenance/evolution. The resource concept fits the document-devel-
During analysis, developers build a model of an opment life cycle very well, and resources support
application in terms of the domain. Ideally, this the principles of modularity in this context. How-
analysis concentrates on the application’s problem ever, the use of the Web has moved far beyond its
space—separate from software considerations, original scope, even in document delivery. It has
which are part of the solution space. Accordingly, become a tool for high-end publishing with com-
this phase should not be affected by whether or not plex requirements related to layout, corporate iden-
the application is to be delivered over the Web. tity, and the integrity of large webs of information.
Based on the analysis, a model of the software The life cycle of a company Web site is now typi-
solution is defined during the design phase. Obvi- cally based on intensive requirements analysis in
ously, the Web application development process— terms of content, structure, access, and corporate
in contrast to a general software process—assumes identity. The design must decompose these require-

IEEE INTERNET COMPUTING [Link] JANUARY • FEBRUARY 1999 61

.
IEEE Internet Computing, vol. 3(1), pp. 60-68, 1999

W E B O B J E C T M O D E L S

ments into resources and hyperlinks, and also ical. The resource model requires separate concerns
address layout. Maintenance must focus on the evo- such as user interfaces, application logic, and—for
lution of content, but also on site integrity. example—database back-ends to be embedded in
The life cycle is no longer author-centric. an intermingled way.
Requirements analysis involves, for example, infor- Because of the request-response style protocol
mation analysts as well as marketing people and between client and server, Web applications are
other stakeholders. Design addresses both database structured, in effect, as finite state machines (FSM):
development and graphic presentation. Imple- The nodes correspond to resources and the transi-
mentation requires Web programmers to use fea- tions leading away from a node correspond to
tures beyond simple markup, and maintenance hyperlinks or form elements within the node. This
involves site managers and Webmasters. distributes the application logic over a number of
The resource notion underlying the Web imple- resources in chunks of script code, in document-
mentation model does not meet the requirements embedded links, and in form elements. Content is
of this kind of life cycle. Most notably, there is no mixed with application logic and typically embed-
separation of concerns regarding content and lay- ded in script code that implements the application
out. Further, the Web implementation model does logic. Further, the user interface is declarative and
not provide abstractions to capture structural specified as documents to be rendered in standard
design for reuse, even though layout and naviga- browsers. A Web application typically generates the
tion structures are commonly reused in different user interface declaration dynamically to reflect
parts of a site. application and interaction state.
In summary, the delivery of applications in the
Life Cycle of General Applications Web environment is radically different from the
Delivered over the Web usual ways of delivering software, and imposes a
Nor does the resource model address the life cycle completely different structure and approach on
of general applications delivered over the Web. application development. Obviously, design and
Decomposing applications into resources is not log- maintenance of such applications should be in

STRUCTURED WEB APPLICATION DEVELOPMENT

Several communities are addressing the need for more ples are OOHDM1 and RMM.2 The proposed methods
structured development of Web applications. address primarily analysis and design. The underlying mod-
els are powerful but geared toward the hypermedia appli-
Commercial IDEs. There is a wide range of commercial cation domain. For example, RMM is based on the notion of
products. Integrated development environments (IDEs), how- entities and relations, which suit information system devel-
ever, fall far short of covering the whole development process opment but not software applications modeling in general.
and are mostly geared toward ad hoc implementation based CASE tools based on hypermedia development models
on tool-specific abstractions. Further, they are rather self- use automated code generation for mapping a design to a
contained and thus difficult to integrate with other tools and Web implementation; see, for instance, RMCase.3 To ensure
methods in a development process. The models underlying integrity throughout the life cycle, all maintenance/evolu-
IDEs do, in general, abstract from low-level technologies but tion activity must be carried out at design level, prohibiting
not to the extent required to establish conceptual integrity access to implementation detail. This is a serious constraint
from the design to the implementation and maintenance considering the general drive of Web applications to take
phases of development. For example, some IDEs address up the latest implementation technologies during evolution.
separation of general layout from content, but there are no
general mechanisms for separation of concerns. Object-Oriented Development. There is also work considering
Web development from a more general software process per-
Hypermedia Process Models. In contrast to commercial con- spective. We have described initial work on an object-orient-
tributions toward disciplined Web development, which are ed Web component model, WebComposition, and its role in
focused on products, the hypermedia community has pro- the Web application life cycle.4 The model (summarized in the
posed development models focused on processes. Two exam- main text) is an abstraction of the Web implementation model,

62 JANUARY • FEBRUARY 1999 [Link] IEEE INTERNET COMPUTING

 .
IEEE Internet Computing, vol. 3(1), pp. 60-68, 1999

W E B A P P L I C A T I O N D E V E L O P M E N T

terms of user interface, application logic, and data- ∗

base back end rather than resources. Current Web HTML screen Screen elements
implementation technology is too low level to sup-
port a proper development process.

Case Study in Web Application Screen platform1 Screen platform2

Development
To illustrate some problems we’ve found to be typ- Figure 1. HTML user interface pattern for browser-adapted appli-
ical of Web application development, we will cation delivery.
describe a small part of a travel assistant system that
we developed over the past year. The application
integrates travel booking and routing systems for ered accordingly. The user interfaces obviously dif-
intermodal travel planning. The Web was chosen fer primarily in page layout, while the content—
as the integration platform to capitalize on already messages, form elements, and so on—remain the
existing travel information systems and on HTML same. Thus, the user interface design includes a
browsers as a means of global system access. recurring pattern, based on the well-known decora-
One requirement was for the application to sup- tor pattern.6 Figure 1 illustrates this simple pattern:
port system access from mobile handheld comput- an HTML-based user interface screen is defined on
ers.5 In principle, state-of-the-art handheld com- an abstract level by a set of screen elements—basi-
puters support HTML browsing, but the small cally the content of the screen. From this abstract
displays pose problems in rendering HTML. A screen, specific screens (that is, HTML pages) are
one-size-fits-all design is obviously not satisfactory derived for each target browser platform. Figure 2
for delivering Web-based user interfaces over both applies this pattern to the design of the login screen
standard desktop browsers and handheld browsers. for two platforms in the travel assistant system.
Instead, Web-based user interfaces must be adapt- Because the Web implementation model does not
ed to the different browser characteristics and deliv- support abstraction, it cannot capture general frame-

with each component encapsulating its mapping to a Web 2. T. Isakowitz, E.A. Stohr, and P. Balasubramaninan, “RMM: A Method-
implementation in a dedicated method or service. ology for Structured Hypermedia Design,” Comm. ACM, Vol. 38, No.
Similar work was presented by Barta and Schranz5 and 8, Aug. 1995, pp. 34-44; also available online at [Link]
by Coda et al.6 Barta and Schranz take a language-based [Link]/rmm/[Link].
approach for object-oriented description of Web applications. 3. A. Diaz et al., “RMC: A Tool to Design WWW Applications,” World
For analysis and design, they adopt RMM concepts, which Wide Web J., Vol. 1, No. 1, Dec. 1995; available online at
reflects their focus on hypermedia information systems. In con- [Link]
trast, Coda et al. propose a general software process to bridge [Link].
the gap between design and Web implementation. Their pro- 4. H.-W. Gellersen, R. Wicke, and M. Gaedke, “WebComposition: An
posed object-oriented implementation technology, WOOM, Object-Oriented Support System for the Web Engineering Lifecycle,”
is a generative model based on objects that model Web imple- Proc. Sixth Int’l WWW Conf. (WWW6), Computer Networks and ISDN
mentation primitives—in particular, HTML elements. Systems, Vol. 29, 1997, pp. 1,429-1,437; also available online at
Like the objects in WebComposition, WOOM objects [Link]
encapsulate the mapping to a Web implementation in a 5. R.A. Barta and M.W. Schranz, “Jessica: An Object-Oriented Hyper-
dedicated method. media Publishing Processor,” Proc. Seventh Int’l WWW Conf.
(WWW7), Computer Networks and ISDN Systems, Vol. 30, Elsevier
REFERENCES WITH URLS Science, Amsterdam, 1998, pp. 281-290; also available online at
1. D. Schwabe, G. Rossi, and S. Barbosa, “Systematic Hypermedia Design [Link]
with OOHDM,” Proc. ACM Int’l Conf. Hypertext, ACM Press, New York, 6. F. Coda et al., “Towards a Software Engineering Approach to Web Site
1996, pp. 116-128; also available online at [Link] Development,” Proc. Ninth Int’l Workshop on Software Specification and
~barman/HT96/[Link]. Design (IWSSD-9), IEEE Computer Society, Los Alamitos, Calif., 1998.

IEEE INTERNET COMPUTING [Link] JANUARY • FEBRUARY 1999 63

. IEEE Internet Computing, vol. 3(1), pp. 60-68, 1999

W E B O B J E C T M O D E L S

of the original design. The development process is

Logo
not reversible, which means that design decisions
Login screen
are difficult to track and to access in the imple-
Form mentation.

AN OBJECT-ORIENTED MODEL
Desktop login WindowsCE login FOR WEB APPLICATIONS
WebComposition is an approach to structured Web
Figure 2. Design of HTML-based login screens for two browser development that applies established object-orient-
platforms. ed software development principles to the World
Wide Web. The approach is based on a Web com-
works that are defined in terms of abstract objects, ponent model that abstracts from low-level Web
such as the one described in Figure 1. Nor can it implementation technologies to support seamless,
model the more specific design in Figure 2, which is reversible development of Web applications.
also based on an abstract object and the notion of Figure 3 illustrates the overall WebComposition
specialization by inheritance. The lack of abstraction architecture. A resource generator maps the com-
means that a Web implementation cannot factor ponent model to a standard Web implementation.
properties shared between objects into a generalized The model is maintained throughout the Web
object but must build them into each specific object. application’s life cycle, facilitating component reuse
The alternative of delegating shared code to a third and application evolution at a higher level of
object is also only minimally supported through abstraction. In other words, the component model
extensions such as server-side includes. maintains the developer’s view of an application,
Obviously, the lack of abstraction hampers con- from which the Web view is derived incrementally.
struction of general components and frameworks. We will briefly describe the component model
Further, it does not support the modular separation and the concepts for resource generation (for more
of concerns: Code for user interface elements can- detail, see Gellersen et al.1). Then we present a new
not be separated from code for page layout. development, the WebComposition Markup Lan-
Another problem, also illustrated in our small guage, that implements the WebComposition con-
example, is the gap between higher level design and cepts based on the World Wide Web Consortium’s
implementation. There is a drastic transition from eXtensible Markup Language (XML).7
the design—as represented in the object model
shown in Figure 2—to its implementation. It is dif- WebComposition Component Model
ficult to redesign during system evolution because WebComposition defines an object-oriented model
a Web implementation cannot capture the concepts that uses components as a uniform concept for

DBMS
HTML
HTML
HTML

File
system
XML-based WCML WCML HTML
description parser compiler documents

WWW
server
generated

Figure 3. Overall WebComposition architecture. A resource generator maps the component model to a standard Web
implementation.

64 JANUARY • FEBRUARY 1999 [Link] IEEE INTERNET COMPUTING

 .
IEEE Internet Computing, vol. 3(1), pp. 60-68, 1999

W E B A P P L I C A T I O N D E V E L O P M E N T

modeling Web entities at arbitrary levels of granu- <wcml>

larity and abstraction. In contrast to resources, <component id=’CHeader’>
components are not fixed to a certain grain size but <property name=’text’ value=“/>
designed instead to capture design artifacts at their <property name=’level’ value=“/>
natural granularity. For example, components can <property name=’content’>
capture a content unit as design artifact indepen- <H<<refprop name=’level’/>>
dently of a Web page, which is a separate design <refprop name=’text’>
artifact. </H<<refprop name=’level’/>>
Support of arbitrary granularity means that </property>
components can model Web entities as small as </component>
individual links or layout resource fragments. They <component id=’CFooHeader’>
can also be associated with a complete resource— <prototype is=’CHeader’/>
for instance, an HTML document or a script gen- <property name=’text’ value=’This is a level 2 header’/>
erating a Web document. In contrast to other pro- <property name=’level’ value=’2’/>
posed object-oriented Web models, such as </component>
WOOM,8 WebComposition does not require </wcml>
object-components to be composed or derived
from a given set of primitives; any set of primitives Figure 4. Code describing the structure of a WCML document.
can be modeled as application building blocks—
for instance, user interface primitives or primitives
related to a specific design method. to HTML; for example, components can in prin-
Components can reference other components ciple also be mapped to technologies such as CSS10
to model aggregation (has-part) or specialization and XSL.11 Further, WebComposition defines a
(inherits-from). For example, a component mod- resource generator as a function that incrementally
eling a page can reference components modeling maps a WebComposition model of an application
header, body, or other parts for the purpose of del- to resources in the operational Web environment.
egation—in particular, delegation of the imple- Incremental mapping is based on evaluation of
mentation. As another example, a component component dependencies and tracking of changes
modeling a navigation structure can reference the committed in the component model.
components modeling the involved links and The WebComposition model capitalizes on the
anchors. well-known properties of object-oriented design—
By means of a special reference type, compo- modularity, abstraction, encapsulation, and exten-
nents can reference so-called prototype components sibility, while also retaining generality. The model is
from which they inherit state and behavior. Any clearly defined, both on a conceptual level and as
component can function as a prototype. Thus, the XML-based implementation technology in the
WebComposition model is based on a prototype- WebComposition Markup Language.
instance paradigm, which eliminates the distinction
of instances and classes as known in most object WebComposition Markup Language
models.9 We find this paradigm naturally suited to WCML is based on XML,7 a metalanguage that
Web application modeling, first because many Web facilitates definition of a tag-based textual format
entities—namely, those modeling content—are for semantic markup of documents or data. The
unique and, second, because prototyping reflects XML document type definition of WCML
the copy-and-modify type of reuse often applied in describes a markup notation for WebComposition
Web development. Because it is easy to emulate a concepts—that is, for component descriptions,
class-oriented view from prototypes, the Web- properties, and relationships. Figure 4 presents code
Composition model aligns conceptually with any that describes the structure of a WCML document.
object-oriented design model. A WCML document contains one or more
The WebComposition model is a development components. Each component has an identifier for
model, not a runtime model. Implementation of a referencing; by convention, the identifier starts
Web application from the model requires each with a capital C. Notably, the structuring of com-
component to implement a service for mapping its ponents into documents is independent of whether
state to a representation in the standard Web imple- the components relate to the same document in the
mentation model. This mapping is not restricted target Web implementation. WCML documents

IEEE INTERNET COMPUTING [Link] JANUARY • FEBRUARY 1999 65

. IEEE Internet Computing, vol. 3(1), pp. 60-68, 1999

W E B O B J E C T M O D E L S

XML HTML HTML

XML-based WCML WCML HTML

description parser compiler documents

Figure 5. Compiling WCML to map component model to Web implementation.

mapping of CHeader’s state to a representation in

<component id=’CLogin’> HTML. The second component, CFooHeader, is
<property name=’image’ value=“/> derived from CHeader, which is specified with the
<property name=’version’>Version 1.122.58</property> prototype tag. Components inherit properties of
</component> their prototypes but can override them. In this case,
CFooHeader defines specific values for text and
Figure 6. Code defining general login level, and inherits the content property from
CHeader.
The example shows the use of abstraction. Spe-
cific headers can be defined while simply inherit-
<component id=’CDesktopLogin’> ing the content property that defines the Web
<prototype is=’CLogin’/> implementation. General changes to how a header
<property name=’image’ value=’[Link]’/> is implemented in the Web could be carried out at
<property name=’content’> an abstract level by modifying CHeader’s property
<refprop name=’content’ content. Such a change would affect all compo-
from=’CLogo’ prototype=’CDesktopLogin’/> nents derived from CHeader unless these compo-
<refprop name=’content’ from=’CApplicationTitle’/> nents define their own content property.
<refprop name=’content’ from=’CForm’/> WCML code generation is based on the content
<refprop name=’content’ from=’CRegister’/> property and takes advantage of the availability of
<refprop name=’content’ from=’CCopyright’/> XML parsers for all major development platforms.
</property> Figure 5 illustrates the compilation process. As an
</component> XML-based description language, WCML enables
exchange of components across operating system
Figure 7. Code for the desktop login screen. platforms. XML itself is based on Standard Gener-
alized Markup Language technology for creation of
interchangeable, structured documents, and so
can be used to organize components into modules parsing of XML documents in general, and
that, for instance, capture a specific framework or WCML in particular, is straightforward.
a set of domain-specific building blocks. While
HTML documents are a unit of application deliv- Abstraction and Reuse in WCML
ery at runtime, WCML documents are a unit of Applications
application development that support modularity Let’s return to the example login screen earlier.
and reuse. WCML can directly implement the login screen
A component is defined by a set of properties, design shown in Figure 2. The generalized login
which are simple name-value pairs. For instance, screen defines properties that are shared by the
the component CHeader models an HTML head- browser-specific login screens. These are an image
er with properties defining text and heading level. and a version number, both to be displayed in the
According to the WebComposition model, every logo, which is part of the login screen. Figure 6
component must specify its own Web implemen- shows the code defining these properties.
tation. In WCML, this is accomplished with a spe- Figure 7 is the code describing the desktop login
cial kind of property, content. In the Figure 4 code screen. The CDesktopLogin component uses the
for CHeader, the content property describes the CLogin component as a prototype to inherit the

66 JANUARY • FEBRUARY 1999 [Link] IEEE INTERNET COMPUTING

 .
IEEE Internet Computing, vol. 3(1), pp. 60-68, 1999

W E B A P P L I C A T I O N D E V E L O P M E N T

version and image properties; it overrides the image

property. In addition, CDesktopLogin defines a <component id=’CWindowsCELogin’>
content property. <prototype is=’CLogin’/>
In the definition of its content, CDesktopLogin <property name=’image’ value=’[Link]’/>
refers to other components that model parts of the <property name=’content’>
login screen: a logo component based on an image <table border=”0” cellspacing=”5”><tr><td>
and a version number, and components for the <refprop name=’content’
application title, a form element, a registration con- from=’CLogo’ prototype=’CWindowsCELogin’/>
trol, and a copyright note. CDesktopLogin dele- </td><td>
gates the content definition to these components <refprop name=’content’ from=’CApplicationTitle’/>
by means of the refprop tag, and defines its con- </td><td>
tent as a simple concatenation of the delegated con- <refprop name=’content’ from=’CForm’/>
tents. In the case of the logo component, CDesk- </tr></td></table>
topLogin passes on its own state by defining itself <refprop name=’content’ from=’CCopyright’/>
as a prototype of CLogo within the scope of the ref- </property>
prop reference. </component>
The component for the Windows CE login
screen is likewise derived from CLogin, inheriting Figure 8. Code for the Windows CE login screen.
the version number and defining an image for the
logo, as shown in Figure 8.
By using the same prototype as CDesktopLogin, number captured in CLogin can be modified with-
both components effectively share the code that is out touching the specific login screen components.
generalized in CLogin. Further code sharing occurs New components can be added to WCML
by delegation to the same components referred to in implementations of Web applications easily by
the content property. In contrast to CDesktopLo- reusing and modifying any component code in the
gin, this login screen arranges the content of its parts system. For instance, a new login screen for anoth-
horizontally in a table, adapting to the Windows CE er browser does not have to be defined as a proto-
display. Another difference is that the Windows CE type of CLogin but can use a more specific login
login does not contain a registration control, as reg- screen as prototype, as shown in Figure 10.
istration of new users is not supported from mobile Conceptually, CPsionLogin is derived from CLo-
devices in the travel assistance system. gin, but for more effective code sharing it derives its
Figure 9 shows the two resulting screens, pro- implementation from CWindowsCELogin.
viding the same interface with different layout
adapted to the platform requirements. CONCLUSION
The phenomenal popularity of the Web and its
WCML Applications: advantages as a client-server software platform have
Modifiable and Extensible
WCML components can have arbitrary granular-
ity, which means that an application can be decom-
posed to the actual units of change. Regarding our
example, the decomposition of login screens into
smaller parts is a contribution both to reuse and to
modifiability. Changes in parts of the login screen
can be encapsulated in a component. For example,
a modification of the form element would be local-
ized in the CForm component and leave the defi-
nition of the login screen untouched.
Besides modification at different levels of
decomposition, WCML supports modification at
different levels of abstraction. General design deci-
sions can be captured in abstract components, facil-
itating reconsideration in abstraction from imple- Figure 9. Travel assistant login screens for desk-
mentation detail. As a simple example, the version top browser and handheld browser.

IEEE INTERNET COMPUTING [Link] JANUARY • FEBRUARY 1999 67

. IEEE Internet Computing, vol. 3(1), pp. 60-68, 1999

W E B O B J E C T M O D E L S

5. M. Gaedke et al., “Web Content Delivery to Heterogeneous

<component id=’CPsionLogin’> Mobile Platforms,” paper presented at the Workshop on
<prototype is=’CWindowsCELogin’/> Mobile Data Access at the 17th Int’l Conf. on Conceptual
<property name=’image’ value=’[Link]’/> Modeling, Singapore, 1998; available online at
</component> [Link]
6. E. Gamma et al., Design Patterns: Elements of Reusable Object-
Figure 10. Code for a specific login screen as a prototype. Oriented Software, Addison-Wesley, Reading, Mass., 1994.
7. World Wide Web Consortium, Extensible Markup Lan-
guage (XML) 1.0 Specification, tech. report, available online
led to a wide range of Web applications, but devel- at [Link]
opment is still largely ad hoc. The Web implemen- 8. F. Coda et al., “Towards a Software Engineering Approach
tation model imposes a structure on Web applica- to Web Site Development,” Proc. Ninth Int’l Workshop on
tions that does not relate well to established Software Specification and Design (IWSSD-9), IEEE Com-
software development models, rendering it difficult puter Society, Los Alamitos, Calif., 1998.
to adopt structured software processes for the Web 9. D. Ungar and R.B. Smith, “Self: The Power of Simplicity,”
domain. Existing development environments and Proc. OOPSLA 87, ACM Press, New York, 1987, pp. 227-
design methods provide abstractions from low-level 242.
implementation technology but lack generality and 10. World Wide Web Consortium, Cascading Style Sheets (CSS)
do not sufficiently address system maintenance and Level 1 Specification, tech. report, available online at
evolution. [Link]
The WebComposition model defines an object- 11. World Wide Web Consortium, Extensible Style Sheets
oriented model for Web applications that abstracts (XSL), Working Draft, available online at [Link]
from the Web implementation model and gives org/TR/WD-xsl.
developers the power of object-oriented concepts 12. H.-W. Gellersen et al., “Patterns and Components: Cap-
for constructing reusable frameworks, for reuse by turing the Lasting amidst the Changing,” paper presented
inheritance and delegation, and for improved mod- at The Active Web, British HCI Day Conf., Staffordshire
ifiability and extensibility. Univ., 1999, available at [Link]
We believe that WCML, which is based on
XML technology, contributes further toward a Hans-W. Gellersen is a research scientist at the University of
more seamless and reversible development process Karlsruhe, leading the Telecooperation Office (TecO) for
by enabling the definition of higher level abstrac- applied computing research with partners in industry. His
tions for design-level modeling in a markup lan- research interests are in methods and tools for disciplined
guage. To investigate this claim, we are in the development, operation, and evolution of WWW applica-
process of building a CASE tool based on tions, and handheld and ubiquitous computing technolo-
OOHDM for analysis and design, and WCML for gies. Gellersen received a doctoral degree in 1996 and a
implementation.12 ■ master’s degree in computer science in 1992 from the Uni-
versity of Karlsruhe.
REFERENCES
1. H.-W. Gellersen, R. Wicke, and M. Gaedke, “WebCom- Martin Gaedke is a research assistant at the Telecooperation
position: An Object-Oriented Support System for the Web Office of the University of Karlsruhe, and the technical lead
Engineering Lifecycle,” Computer Networks and ISDN Sys- in collaborative Web engineering projects. His research
tems, Vol. 29, 1997, pp. 1,429-1,437; also available online interest is in application of software engineering practice to
at [Link] applications in the WWW, and specifically in design pat-
2. P. Ciancarini et al., “Coordinating Multiagent Applications terns and component technology for the WWW. Gaedke
on the WWW: A Reference Architecture,” IEEE Trans. Soft- obtained a master’s degree in computer science from the
ware Eng. (special issue on Mobility and Network Aware University of Karlsruhe in 1997.
Computing), Vol. 24, No. 3, 1998, pp. 362-366.
3. R. Itschner, C. Pommerell, and M. Rutishauser, “GLASS: Readers may contact Gellersen at Telecooperation Office
Remote Monitoring of Embedded Systems in Power Engi- (TecO), University of Karlsruhe, Vincenz-Priessnitz Str. 1,
neering,” IEEE Internet Computing, Vol. 2, No. 3, May 76131 Karlsruhe, Germany; e-mail hwg@[Link].
1998, pp. 46-52.
4. T. Berners-Lee et al., “The World-Wide Web,” Comm.
ACM, Vol. 37, No. 8, Aug. 1994, pp. 76-82.

68 JANUARY • FEBRUARY 1999 [Link] IEEE INTERNET COMPUTING

View publication stats