Web Application Models are more than Conceptual
Models
Gustavo Rossi
1,3
, Daniel Schwabe
2
, Fernando Lyardet
1
1
LIFIA, Departamento de Informática, UNLP. Argentina
E-mail: [gustavo,fer]@sol.info.unlp.edu.ar
2
Depto de Informática, PUC-Rio, Brazil.
E-mail: schwabe@inf.puc-rio.br
3
also at CONICET and UNLM
Abstract. In this paper, we argue that web applications are a particular kind of
hypermedia applications and show how to model their navigational structure.
We motivate our paper discussing the most important problems in the design of
complex Web applications. We argue that if we need to design applications
combining hypermedia navigation with complex transactional behaviors (as in
E-commerce systems), we need a systematic development approach. We next
present the main ideas underlying the Object-Oriented Hypermedia Design
Method (OOHDM). We show that Web applications are built as views of
conceptual models. We next present the abstraction primitives we use to design
the conceptual and navigational structure of Web applications and describe the
view definition language. We introduce navigational contexts as the structuring
mechanism for the navigational space. Some further work on designing Web
applications with OOHDM is finally presented.
1 Introduction: Web Applications are Hypermedia Applications
The emergence of the World Wide Web has made the hypertext paradigm more
popular than ever. Web applications combine navigation through a heterogeneous
information space with operations querying or affecting that information.
The WWW is based on the hypertext paradigm, inasmuch as it is composed of
pages (in HTML) which can be linked to each other through URLs (links). Regardless
of how a reader has reached a page, he will normally have the option of accessing the
pages linked to the current page; by choosing a particular link, he will cause the page
pointed to by the link to be exhibited; this process can repeats itself indefinitely. This
succession of steps is know as “navigation”, and is intrinsic to hypertext, and hence to
the WWW.
However, this second generation of hypermedia applications is rather different
from the first one, in which applications, usually delivered in CD-ROMs, were not
supposed to be updated and, in general, were not critical for any organization. Web
applications, on the other hand, are constantly modified, are permanently enriched
with new services, and new navigation and interface features are added, e.g.,
according to the organization’s marketing policy.
In this paper we argue that good Web applications should be, first of all, good
hypermedia applications, i.e. they should provide easy navigational access to large
information resources, preventing users from being lost in the cyberspace, and
providing consistent navigation operations even when other kind of transactional
behavior is involved. As navigation problems have been largely discussed in
hypertext literature (see for example [12]) we should be able to reuse existing
knowledge on building good Web applications.
Unfortunately, state-of-the art conceptual modeling approaches neglect navigation
modeling as they do not provide useful abstractions capable of easing the task of
specifying applications that embody the hypertext metaphor. For example, they do not
provide any notion of linking and very little is said about how to incorporate
hypertext into the interface. For example, we could easily model the domain of an
electronic commerce application using UML [UML97]. However we can not specify
critical aspects for this kind of application, such as which nodes will be navigated or
which paths or indexes the application will contain. Even if we specify all this
hypermedia functionality using UML primitives, we will be using low-level
primitives whose semantics were not intended to model navigation.
At the same time, we could model this kind of applications by considering
navigation as just another kind of interface behavior; this is the approach followed by
some recent (object-oriented) tools like VisualWave [27]. In this case, applications
built using the well-known model-view-controller interface metaphor are published in
the Web by just translating views into HTML pages; only some aspects related with
concurrent access with shared databases are taken into account. However this
approach fails to consider the most powerful feature of the Web: its linking
capabilities.
If we want to profit from the potential of the Web platform we need to consider
both aspects of Web applications: navigation and transactional (or other kind of
conventional) behaviors.
Web applications provide a powerful mechanism for building different views (in
fact navigational views) to corporate databases. For example, while customers access
the Amazon.com bookstore using a particular Web interface, managers or technical
staff can access the same information resources through a different Web application
(and obviously different access rights) in an Intranet. However, these views are more
than simple database views as they involve different navigation paths, indexes, etc. In
this paper we show how to design Web applications as views of (shared) conceptual
models. In addition, it will be argued that the links provided for navigation are more
than a representation of conceptual relations, as a more naive approach would
suggest.
To summarize the discussion above, we can intuit that there are distinguishing
features in Web applications that present new design requirements vis-a-vis
traditional systems. In a broad sense, we can categorize them in three groups. The first
group of design issues has to do with navigation, addressing questions such as:
• What constitutes an “information unit” with respect to navigation?
• How does one establish what are the meaningful links between information units?
• Where does the user start navigation?
• How does one organize the navigation space, i.e., establish the possible sequences
of information units the user may navigate through?
• If we are adding a WWW interface to an existing system, how do we map the
existing data objects onto “information units”, and what relationships in the
problem domain should be mapped onto links?
The second group of design issues has to do with the organization of the interface,
addressing questions such as:
• What interface objects the user will perceive? How do these objects relate to the
navigation objects?
• How will the interface behave, as it is exercised by the user?
• How will navigation operations be distinguished from interface operations and
from “data processing” (i.e., application operations)?
• How will the user be able to perceive his location in the navigation space?
The third group of design issues has to do with implementation, addressing questions
such as:
• How are information units mapped onto pages?
• How are navigation operations implemented?
• How are other interface objects implemented?
• How are existing databases integrated into the application?
In this paper we will concentrate on discussing our approach for solving the first
group. A discussion on the third group of issues can be found in [Segor99].
The rest of this paper is structured as follows: we first introduce the Object-
Oriented Hypermedia Design Method. We next discuss how we build navigational
models as views on conceptual models; then we introduce navigational contexts as a
structuring mechanism for navigation. Finally, we discuss some ongoing work on
mining navigation patterns and present some further work on designing and
implementing these kind of systems.
2 The OOHDM Design Framework
The Object-Oriented Hypermedia Design Method [Schwabe 98, Schwabe 96] is a
model-based approach for building large hypermedia applications. It has been
extensively used to design different kinds of applications such as: Web sites and
information systems, interactive kiosks, multimedia presentations, etc. It should be
stressed the OOHDM has been applied outside the academic environment, such as in
government agencies, telecommunications companies, oil companies, IT service
companies, etc…
OOHDM comprises four different activities namely, Conceptual Design,
Navigational Design, Abstract Interface Design and Implementation. During each
activity a set of object-oriented models describing particular design concerns are built
or enriched from previous iterations.
We explicitly separate conceptual from navigation design since they address
different concerns in Web applications. Whereas conceptual modeling and design
must reflect objects and behaviors in the application domain, navigation design is
aimed at organizing the hyperspace taking into account users’ profiles and tasks.
Though applications views are not new in the literature [4], the hypermedia paradigm
as it appears in the Web raises additional concerns such as orientation, cognitive
overhead, etc. that should be treated in a separate design activity.
Considering conceptual, navigational and interface design as separate activities
allows us not only to concentrate on different concerns at a time, but mainly to obtain
a framework for reasoning about the design process, encapsulating design experience
specific to each activity. As we explain below, navigational design is a key activity in
the implementation of Web applications and it must be explicitly separated from
conceptual modeling
OOHDM design primitives can be mapped onto non object-oriented
implementation settings using some simple heuristics [22]. We next discuss the first
three activities in more detail.
2.1 Conceptual Modeling
During this step we build a model of the application domain, using well known
object-oriented modeling principles and primitives similar to those in UML [24]. The
product of this step is a class schema built out of Sub-Systems, Classes and
Relationships.
We chose UML because it is a modeling standard whose syntax and semantic are
clear and well-understood. The major differences with UML are the use of multiple-
valued attributes, and the use of directions explicitly in the relationships. Aggregation
and generalization/specialization hierarchies are used as abstraction mechanisms.
Conceptual Modeling is aimed at capturing the domain semantics as “neutrally” as
possible, with little or no concern for the types of users and tasks. When the
application involves some sophisticated behavior in conceptual objects, it may evolve
into an object model in the implementation environment. However it can be
implemented in a straightforward way in current Web platforms combining for
example a relational database with some stored procedures. The main thesis in this
paper is that the conceptual model may not reflect the fact that the application will be
implemented in the WWW environment, since the key application model will be built
during navigational design. This view allows using the same strategy for
implementing “legacy” applications in the Web, by considering their conceptual
model as the product of this OOHDM activity.
Classes in the conceptual model will be mapped to nodes in the navigational model
using a viewing mechanism and relationships will be used to define links among
nodes. It will also be shown that there are other links that do not correspond to
relationships in the conceptual model.
Using a behavioral object-oriented model for describing different aspects of Web
applications allows to express a rich variety of computing activities, such as dynamic
queries to an object-base, on-line object modifications, heuristics-based searches, etc.
The kind of behavior required in the conceptual model depends upon the desired
features of the application. For many Web applications, in particular those
implementing plain browsing (i.e. read-only) functionality, class behavior beyond
linking functionality is unnecessary and does not need to be specified.
Name: string
Equipment
Name: string
UrlSponsor: string
Sponsor
Name: string
Description: string
Budget: real
Research Project
Name: string
Description: string
Area of Research
OnLineContent: string
Students Production
Name: string
Description: string
Laboratory
N
advises
funds
conducted in
0..N
0..N
belongs
0..N
participates
N
0..N
belongs
N
N
N
belongs
N
related
belongs
N
produces
N
produces
NN
Semester: string
Schedule: string
Classroom: string
Course Offering
OnLineContent: string
Location: string
Complementary Material
N
teaches
1
N
attend
N
N
Name: string
Description: string
NumberOfCredits: integer
SuggestedPeriod : string
Syllabus : text
Course
offered
1
N
belongs
N
N
1
N
requires
0..N 0..N
Name: string
RequiresAmount : integer
ElectivesAmount : integer
Degree
has elective
has required
N
N
N
N
N
pursues
requires
requires
requires
1
1 1
1
1
N
Degree: string
Student
StudentID: integer
BeginningDate: date
EndingDate: date
AdministrativeTechnicalAcademic
Thesis
MScPhD
Graduation
Project
PhDMSc
Graduate Undergraduate
0..N
Slide WorkBook Exercise
Eva luation: integer
N
N
N
belongs
N
N
N
Title: string
PublicationDate: date
Abstract: text
Autors: set of string
Research Result
Edition: string
Publishing: string
Book
Code: string
OnLineContent: string
Technical Report
BiblioReference: string
OnLineContent: string
Paper
UrlConference: string
Conference Paper
UrlJournal : string
Journal Paper
OnLineContent: string
Software
N
Hardware
0..N
1
Name: string
Degree: string
Description: [text+, image]
Email: string
HomePage: string
Personel
Rank: string
Professor
Fig. 1. Conceptual Schema of the Academic Department Site.
Figure 1 shows the Conceptual Schema for an Academic Department Web site.
Perspectives (multiple valued attributes) are denoted by enumerating the possible
types, with a + next to a default type. Thus, description: [text+, image] means that
attribute description has a text perspective (always present), and may have also an
image perspective.
