1

Assignment On
"Modeling Web Applications"
Course Title: Web Engineering

Submitted By (Group-3)
Submitted To
S/L Name ID
Prodip Kumar Sarkar
01 Milan Kumar 1306039
Assistant Professor Sarker
Department of Computer 02 Sourove Sarker 1306030
03 MD Zahid Hasan 1306014
Science and Engineering
04 Tapu Chandra 1306045
Begum Rokeya University, Roy
Rangpur. 05 Sharmin Sultana 1306020

06 Tazqira Jannat 1209065

Tulona
07 Shaibal Hossain 1209061
Shuvo

Date of Submission: 5th October, 2020

1
 2

INDEX

1. Modeling Specific in Web Engineering……………………………………………………………………………………….………04

1.1 Fundamental of Modeling Specifics in Web Engineering…………………………………………….……..04

2. Levels and Aspects…………………………………………………………………………………………………………………………….05

2.1 Levels………………………………………………………………………………………………………………………………………....05

2.2 Aspects………………………………………………………………………………………………………………………………….…...06

3. Phase…………………………………………………………………………………………………………………………….……..……………07

4. Customization………………………………………………………………………………………………………………….………………..07

5. Modeling Requirements…………………………………………………………………………………………………..……………..…07

6. Content Modeling……………………………………………………………………………………………………………….….……...…08

6.1 Objectives………………………………………………………………………………………………………..…………….……..…..08

6.2 Concepts……………………………………………………………………………………………………………..…………………....09

7. Hypertext Modeling……………………………………………………………………………………………………..……………….….10

7.1 Objectives……………………………………………………………………………………………………………….………………....10

7.2 Hypertext Structure……………………………………………………………………………………………………………….…..10

7.3 Modeling Concepts………………………………………………………………………………………………………………….…13

7.4 Relation to Context Modeling…………………………………………………………………………………………….………14

8. Presentation Modeling……………………………………………………………………………………………………………………..14

8.1 Objectives………………………………………………………………………………………………………………………..……..…15

8.2 Concepts…………………………………………………………………………………………………………………………………….16

8.3 & 8.4 Relation to Concept, Hypertext and Presentation Modeling……………………………………..………18

9. Customization Modeling……………………………………………………………………………………………………………...……18

9.1 Objectives……………………………………………………………………………………………………………………………....….18

9.2 Concepts………………………………………………………………………………………………………………………………..…..19

9.3 Relation to Concepts……………………………………………………………………..………………………..………..……….21

2
 3

9.4 Hypertext and Presentation Modeling…………………………………………………………………..……..……..…….21

10. Methods and Tools……………………………………………………………………………………………………………..…….…….22

10.1 Modeling Methods: An Overview………………………………………………………………………………….…….……22

10.2 MDD…………………………………………………………………………………………………………………………………………23

10.3 Tools Support…………………………………………………………………………………………………………………..…….24

10.3.1 WebRatio Site Development Studio………………………………….……………………………24

10.3.2 VisualWADE………………………………………………………………………………………24

10.3.3 OpenUWE……………………………………………………………………………….………….24

3
 4

1. Modeling Specifics in Web Engineering

A web application is known as a computer application that uses web technology and web
browsers to complete tasks over the Internet. This sector is becoming progressively more tangled
as well as mission condemning. Modeling can help to manage this growing complexity. The
current standard for modelling software-intensive systems is the Unified Modeling Language
(UML).
Diagrams make it possible to share, present and collect information as a source of intellect for
the development of the web application. Data models describe the representation of the related
business domain which is the target problem area of our application’s functionality.
Without data model and diagrams it’s hard to fix and focus on the target scope of the
development; the scope is often changing development which result delay and not calculated
costs of risk and effort.
With ‘modeling’ we draw, represent and describe what we want to implement and we can talk
about a fix and more compact package of software design during development.
So, in our project we’ll discuss about model-based development of Web applications.

1.1 Fundamental of Modeling Specifics in Web Engineering:

Models help us understand the system by simplifying some of the details. The choice of what to
model has an enormous effect on the understanding of the problem and the shape of the solution.
Web applications, like other software intensive systems are typically represented with a set of
models; use case model, implementation model, deployment model, security model, etc. An
additional model used exclusively by web systems is the site map, an abstraction of the web
pages and navigation routes throughout the system.
Most modeling techniques practiced today are well suited to development of the various models
of a web application, and do not need further discussion. One very important model however; the
Analysis/Design Model (ADM) does present some difficulties when an attempt is made to
include web pages, and the executable code associated with them, alongside the other elements
in the model. When deciding how to model something determining the correct level of
abstraction and detail is critical to providing something that will be of benefit to the users of the
model. Generally speaking it is best to model the artifacts of the system; those real life entities
that will be constructed and manipulated to produce the final product. Modeling the internals of
the web server, or the details of the web browser is not going to help the designers and architects
of a web application. Modeling the pages, their links to each other, all the dynamic content that
went into creating the pages, and the dynamic content of the pages once on the client is important
however very important. It is these artifacts that designers design, and implementers implement.
Pages, hyperlinks, and dynamic content on the client and server are what need to be modeled.
The next step is mapping these artifacts to modeling elements. Hyperlinks for example map
naturally to association elements in the model. A hyperlink represents a navigational path form

4
 5

one page to another. Extending this thought, pages might map to classes in the logical view of
the model. If a web page is a class in the model, then the page’s scripts would map naturally to
operations of the class. Any page scoped variables in the scripts would map to class attributes. A
problem arises when you consider that a web page may contain a set of scripts that execute on
the server (preparing the dynamic content of the page) and a completely different set of scripts
that only execute on the client (i.e. JavaScript). In this scenario when we look at a web page class
in the model there is confusion over what operations, attributes and even relationships are active
on the server (while the page is being prepared) and which ones are active when the user is
interacting with the page on the client. Additionally a web page as delivered in a web application
is really better modeled as a component of the system. Simply mapping a web page to a UML
class does not help us understand the system better.

Figure: Requirements of Web Application.

The creators of the UML realized that there would always be situations where the UML, out of
the box, would not be sufficient to capture the relevant semantics of a particular domain or
architecture. To address this purpose, a formal extension mechanism was defined to allow
practitioners to extend the semantics of the UML. The mechanism allows us to define
stereotypes, tagged values and constraints that can be applied to model elements.
One final point on modeling, a very clear distinction needs to be made between business logic
and presentation logic. For the typical business application, only the business logic should be
part of the ADM. Presentation details like animated buttons, fly-over help and other UI
enhancements do not normally belong in the ADM. If a separate UI model is constructed for the
application, then this is the place for such things. The ADM needs to remain focused on the
expression of the business problem and solution space. In this day of web artists the look and feel
of a web page is better designed and implemented by a specialist (technical graphic artist) and
not by the traditional developer.
2. Levels and Aspects
2.1 Levels
To model Web applications, the document-like character of its content as well as its non-linear
hypertext navigation has to be taken into account. This is the reason why we distinguish three
levels when modeling Web applications, in contrast to the two levels used in the modeling
methods for traditional applications. The three levels are content, i.e., the information and
application logics underneath the Web application, hypertext, i.e., the structuring of the content
into nodes and links between these nodes, and the presentation, i.e., the user interface or page

5
 6

layout. Most methods which are used to model Web applications follow this separation into three
levels.
A clear separation of these three levels allows reuse and helps to reduce complexity. For
example, we could specify a number of different hypertext structures that will do justice to the
specific requirements of different user groups and used devices for a given content. The aim of a
content model is the explicit definition of the information structure. Comparable to a database
schema in data modeling this eliminates redundancies. This means that the structure of the
information will remain unchanged, even if the information itself changes frequently.
To design efficient navigation, content may be offered redundantly on several nodes on the
hypertext level. Due to the separation of concerns, content is just modeled once in the content
model and the hypertext structure model just references the corresponding content. In this way,
users can find this information over several access paths. To prevent users from getting lost while
navigating and to keep the cognitive stress on users as low as possible, hypertext modeling
should rely on recurring navigation patterns (Bernstein 1998).In turn, when modeling the
presentation level, the focus is on a uniform presentation structure for the pages to achieve a
brand recognition effect for the Web application among its users. Although the visual appearance
of a Web application is of importance, aesthetic aspects are not within the major focus of
modeling. Despite a separation of concerns and the different objectives at the three levels, we
would like to map the levels to one another. To achieve this mapping between levels, level inter-
dependencies have to be captured explicitly. For example, different personalized hypertext
access paths could be mapped onto one single content model. A comprehensive model of a Web
application includes all three levels discussed here, however, the emphasis can vary depending
on the type of Web application. Web applications that provide a purely hypertext-oriented user
interface to a large data set will probably require the modeling focus to be on content and
hypertext structure. In contrast, presentation-oriented Web applications, e.g., corporate portals or
online shopping malls, will most likely have larger demands on presentation modeling.

2.2 Aspects:

Structure and behavior are modeled at each of the three levels, i.e. at content, hypertext and
presentation , following the object-oriented principles. The relevance of the structure and
behavior models depends on the type of Web application to be implemented. Web applications
which make mainly static information available require less behavior modeling compared with
highly interactive Web applications, such as for example e-commerce applications which provide
search engines, purchase order functions, etc. With respect to mapping the different levels, itis
recommended to use a uniform modeling formalism for structure and behavior, which might
allow relying on one single CASE tool. Naturally, this modeling formalism has to cope with the
specific characteristics of each of the three levels.

6
 7

3. Phases
There is no consensus in literature about a general modeling approach for the development of
Web applications.In any case, the sequence of steps to model the levels should be decided by the
modeler.
Depending on the type of Web application, it should be possible to pursue an information-driven
approach, i.e., starting with content modeling, or a presentation-driven approach, i.e., starting
with modeling of the application’s presentation aspects.
Model-based development in Web engineering contradicts somewhat the often found practices in
Web projects comprising, e.g., short-lived development cycles and the desire for ‘‘agile
methods’’.A model-based approach counters this situation with a comprehensive specification of
a solution model and, if appropriate case tool support is available, the possibility to automatically
generate the (prototypical) Web application. Models also ensure the sustainability of solution
ideas, in contrast to shorter-lived software solutions. In addition, the communication amongst the
developers of a team as well as between customers and developers is improved.
4. Customization
The inclusion of context information in the development of Web applications plays a significant
role to allow for e.g. personalization, multi-delivery and location-based services. Customization
considers the context, e.g., users’ preferences, device characteristics, or bandwidth restrictions,
and allows to adapt the Web application accordingly. It influences all three Web modeling
dimensions of content, hypertext, and presentation with respect to structure and behavior and
should be taken into account in all phases of the development process. Handling context
information is, therefore, treated as an independent modeling dimension.
5. Modeling Requirements
Various techniques can be used to identify, analyze, describe, evaluate,and manage Web
application requirements. The overall functionality of a Web application is modeled as a set of
use cases, which describe the Web application requirements from the actors’ (people and other
systems) perspectives. Additionally, use cases can be supplemented by UML activity diagrams to
describe the functional requirements in more detail.(Baresi et al. 2001) suggests separating the
functional from the navigational use cases, creating two distinct models. Another approach
(UWE), selected herein, is to create one single use case model, which uses the UML
navigationstereotype to denote the difference between functional and hypertext-specific use
Cases.
All Web applications have at least one human user, most often anonymous. In our example of
an online conference paper reviewing system (referred to as ‘‘the reviewing system’’ in the
following), four actors can be identified: users of the reviewing system, authors submitting
papers to the conference, members of the program committee (reviewers) reviewing papers
submitted, and the chair of the program committee (PC chair). Figure 3-3 shows a use case

7
 8

diagram representing part of the use case model for the reviewing system, which will serve as the
starting point for further modeling.
Use cases should be described in detail. We can describe each use case in textual form or by
use of a behavior diagram, e.g. an activity diagram. Activity diagrams are mainly used when use
cases are based on more complex application logic. Such a use case, for example, might be
implemented as a Web service. The Figure below is an example of a simplified paper submission
Process.

Figure: Use case diagram of the reviewing system

Figure :Activity diagram of the submission process

6. Content Modeling
6.1 Objectives
The information provided by a Web application is one of the most important factors for the
success of that application, not least due to the origins of the Web as an information medium .

8
 9

Modeling the content in the sense of pure data modeling is normally sufficient for static Web
applications.
Complex Web applications additionally require the modeling of behavioral aspects.In addition
the following Web application characteristics have to be taken into account:
• Document centric character and multimedia: It is necessary to take all kinds of different
media formats into account when modeling the content, including the structures the information
is based on.
• Integration of existing data and software: Many Web applications build on existing data
repositories and software components, which were not created for Web applications originally.
Content modeling has to satisfy two potentially contradicting objectives, i.e., it should cover the
content requirements of the Web application to the best possible extent,and it should include
existing data structures and software components.
6.2 Concepts
Content modeling is aimed at transferring the information and functional requirements
determined by requirements engineering to a model. The hypertext character of a Web
application and the requirements of its presentation will not be considered in this effort.
Content modeling produces a model that comprises both the structural aspects of the content,e.g.,
in the form of a class diagram, and, depending on the type of Web application, the behavioral
aspects, e.g., in the form of state and interaction diagrams.
Figures below shows a very simplified UML class diagram for the reviewing system example.

Figure: Class diagram for the reviewing system

9
 10

The diagram models a conference to be held on a number of topics, and users who can sign into
the conference and submit their papers. A paper is subject to a review by three reviewers.
Notice the invariant attached to the class ‘‘Paper’’: it ensures that authors won’t be able to
review their own papers. This class diagram will later serve as the basis to model the hypertext
and the presentation for the example application.
In addition to the class diagram, Figure below shows a state machine diagram used to model the
various states of a paper in the reviewing system. It shows that a submitted paper will be
assigned to three reviewers for review after the submission deadline has expired. If a pre-set
threshold value is reached, the paper is accepted; otherwise, it is rejected. In both cases the
authors are notified via e-mail about the outcome of the review. Finally, an accepted paper will
be printed once the final version has been submitted.

Figure : State machine diagram for the states of a paper

7. Hypertext Modeling
7.1 Objectives
The objective of hypertext modeling – also known as navigation modeling – is to specify the
navigability through the content of a Web application, i.e., the navigation paths available to the
users. Hypertext modeling generates a two-fold result: First, it produces the hypertext structure
model, also known as navigation structure model which defines the structure of the hypertext,
i.e., which classes of the content model can be visited by navigation. Second, it refines the
hypertext structure model by access elements in the form of an access model. Hypertext
modeling focuses on the structural aspects of the hypertext and the access elements. The
navigational behavior of a Web application is normally not represented explicitly, because it
provides very little additional information for the developer.
7.2 Hypertext Structure
In contrast to the content level, for which ER diagrams or class diagrams are used, specialized
notations are often employed to model the hypertext structure. Hypertext structure modeling is
based on the concepts of hypertext, i.e., on nodes (also called pages or documents) and links
between these nodes.

10
 11

The starting point used for the creation of a hypertext structure model is usually the content
Model which contains the classes and objects to be made available as nodes in the hypertext.
Often the hypertext structure model is specified as a view on the content model and is therefore
sometimes also called the navigational view. Thereby a node is specified as a view on the
content model selecting one or more objects from the content. Some methods even define
transformation rules to derive links on the basis of relationships on the content level. Additional
links can be added by explicit design decision.
In any case, we can create various hypertext structure models that define hypertext views on the
content. For example, if we take into account the access rights of different users for the hypertext
structure modeling, we can obtain personalized hypertext views in the reviewing system example
hypertext views are required for the following user roles: author, reviewer, and PC chair.The
Figure below shows the hypertext structure model for the PC chair’s view. A PC chair can view
all submitted papers. In addition, the PC chair can access the list of accepted or rejected papers,
and the reviewer profiles. In line with the UWE modeling method.
The Figure below, shows how the UML stereotype <<navigation class>>is used to mark classes
representing nodes in the hypertext structure model to distinguish them from content classes.
Links are modeled by directed associations with the stereotype <<navigation link>>.
The literature defines various specific types of links to further refine the semantics of the
hypertext structure model. For example, the HDM (Hypertext Design Model) method
(Garzottoet al. 1995) specifies the following types of links:
• Structural links connect elements of the same node, e.g., from a review summary to the review
details.
• Perspective links put various views of a node in relation to each other, e.g., the PostScript and
the PDF versions of a paper.
• Application links put different nodes in relation to each other, depending on the application,
e.g., a link pointing to ‘‘best paper’’.

11
 12

Figure :Hypertext structure model of the PC’s view on the reviewing system.

Other classifications are based on the possible transport of information during navigation.
For example, the WebML (Web Modeling Language) method (Ceri et al. 2003) specifies the
following types of links:
• Contextual links carry context information, e.g., the unique number of a reviewer, to
navigate from one reviewer to the reviews he or she created.
• Non-contextual links have no associated context information, e.g., links pointing from a single
review to the list of all reviews.
With regard to the distribution of nodes on the hypertext level over pages on the presentation
level, WebML specifies additionally the following types of links:
• Intra-page links are used when the source and the destination of a link belong to the same page,
e.g., when a link allows the user to directly navigate to the summary of a paper, which is
displayed further down on the page.
• Inter-page links are used when the source and the destination are on different pages, e.g., when
detailed information about the authors and their papers are on different pages.
Based on the functional requirements of Web applications, the UWE (Koch and Kraus 2002)
modeling method defines the following types of links:
• Navigation links are used to navigate between nodes, e.g., links between papers and their
authors.
• Process links point to the start node of a process, e.g., to the beginning of the review

12
 13

Submission.
• External links point to a node not directly belonging to the application, e.g., to the
formatting guidelines established by the publisher of the conference proceedings, which
are not directly stored in the reviewing system.
The OO-H (Object-Oriented Hypermedia) modeling method (G´omez and Cachero 2003) defines
five types of links as follows:
• I-links (internal links) point to nodes inside the boundaries of a given navigational
requirement, e.g., internal links to review details of one of the reviewers.
• T-links (traversal links) point to nodes covering other navigational requirements, e.g. from
an author to his or her papers.
• R-links (requirement links) point to a start of a navigational path, e.g., to add a new review.
• X-links (external links) point to external nodes, e.g., to external formatting guidelines.
• S-links (service links) point (with their corresponding response links) to services, e.g., to
an external search engine.

7.3 Modeling Concept

The hypertext structure model built so far alone is not sufficient to describe how nodes can be
reached by navigation. To allow users to navigate to nodes the users need navigation and
orientation aids. These are formulated in the form of access structures refining the hypertext
structure model. Recurring access structures are described in (German and Cowan 2000,
Lyardetet al. 1999, Rossi et al. 1998, Akanda and German 2005) as design patterns, also called
‘‘hypermedia design patterns’’ or ‘‘navigation patterns’’. The use of these navigation patterns
helps to increase the quality of the hypertext model tremendously.
In our reviewing system example, if one wants to navigate from a reviewer to a paper assigned to
this reviewer, one will have to identify this specific paper during navigation. For example, this
could be realized in the form of a list showing all papers. Such a selection list for navigational
support is also known as an ‘‘index’’. An index is an access structure which allows users to
select a single object (i.e. one object of the content) out of a homogeneous list of objects. In
contrast, a menu allows users to access heterogeneous nodes, or further menus (i.e. submenus).
Other access structures are the guided tour and the query. A guided tour allows users to
sequentially walk through a number of nodes. A query allows users to search for nodes. Most
modeling methods offer dedicated model elements for the most frequently used navigation
patterns. Special navigation patterns include home, which points to the home page of a Web
application, and landmark, which points to a node that can be reached from within all nodes.

13
 14

Figure below shows a simplified access model of the PC chair’s view specified in the hypertext
structure model in our reviewing system.

Figure : Simplified access model of the hypertext structure model from above figure

7.4 Relation to Content Modeling

Depending on the underlying modeling method, the hypertext model is more or less strongly
dependent on the content model. There exists both a dependence at the type level, e.g., which
classes in the content model form which node in the hypertext model, and at the instance level,
i.e., which sets of objects in the content model populate that node in the hypertext model. Not all
methods describe dependencies between the content model and the hypertext model exactly.
Nevertheless, some methods specify a direct derivation of the hypertext from the content by
defining nodes on the basis of views (in the sense of ‘‘database views’’) (Schwabe et al. 2002,
Koch and Kraus 2002).

8. Presentation Modeling
Presentation modeling defines where and how navigation objects will be presented to user by
distinguishes between two types of presentation static and dynamic presentation .To model the

14
 15

look & feel of the Web application at the page level .The design should aim for simplicity and
self-explanation.
It expresses the layout and graphic appearance of pages, independently. It present presentation
specification also. Presentation specification are either pages specific or generic.
Describes presentation structure: – Composition & design of each page – Identify recurring
elements (headers/footers)
Describes presentation behavior: – Elements => Events
In contrast to traditional applications, the central element of the presentation in Web applications
is the page as a visualization unit.
8.1 Objectives
The main objective of this research is to study the Web Application Architecture Modeling based
on UWE and WebML. The purpose of the research will be to make web developers are about the
new modeling language WebML and UML profile UWE. It will also help web developers an
insight in documenting and designing a system before building the solution.
The following objectives will be achieved:
1.Comprehensive understanding of Web Architecture and its modeling techniques.
2.Enhancing the knowledge about model driven approach of Web Architecture.
3.Suggesting improvement in Web Architecture modeling.
4.The research work will assists the web designers to efficiently model the complex web
Application.
5.Comparison of both the techniques and showing the results based on their applicability.
Presentation modeling is aimed at designing the structure and behavior of the user interface to
ensure that interaction with the Web application is simple and self-explanatory. In addition, the
communication and representation task of the Web application are taken into account.
Presentation modeling generates a two-fold result: First, it produces a uniform presentation
concept by modeling recurring elements on the pages, e.g., headers and footers. It should ideally
show the composition of each page and the design of the fields, texts, images, forms, etc.,
included in these pages. Second, in addition to the structure of the pages, the presentation model
describes the behavior-oriented aspects of the user interface, e.g., which button to click to
activate a function of the application logic. Due to the wide variety of navigation options and the
inherent risk of getting lost, care should be taken to give users appropriate orientation help on the
presentation level. This can be achieved, for example, by displaying the current navigation path,
or pages visited during the active session.
Not all methods available for modeling Web applications support technology-independent
presentation modeling concepts; some rather use technology-specific concept, XS.

15
 16

8.2 Concepts
Model elements are described on three hierarchical levels:
1. A presentation page describes a page presented to the user as a visualization unit. It can be
composed of different presentation units.
2. A presentation unit serves to group related user interface elements, representing a logical
fragment of the page. It presents a node stemming from the hypertext model.
3. A presentation element is the basic building block of the presentation model. Presentation
elements represent a node’s set of information and can include text, images, audio, etc.
We can visualize the composition of presentation pages on the basis of a nested UML class
diagram representation known as ‘‘composition’’, as in the example shown in Figure. This
example uses the stereotype class page and presentation unit to depict presentation page and
presentation units. Notice that all types of presentation elements are also design by appropriate
UML stereotypes.

A paper is positioned on the page is “Paper Page” with the appropriate fields as will as a link to
the paper’s full version and a link to display the paper’s authors. Moreover, the user can press a
button to add a new review. The page ‘‘Author Page’’ has two presentation units, i.e., the list of
all authors and each author’s detailed information. Behavioral aspects of the user interface, such
as a reviewer’s interaction to navigate to the papers assigned to him or her review can be
modeled by means of behavior diagrams, as shown in this Figures. In general, a user’s
interaction with the Web application does not only involve the presentation level; it is also
forwarded to the hypertext level and the content level, depending on the type of interaction. We
can see in the simplified sequence diagrams in Figures that a reviewer activates the navigation to
the index of assigned papers by using the navigation bar from within the conference home page.
This information is, in turn, composed of the relevant papers on the content level. The list allows
the user to select a paper out of the list of assigned papers. The user can then navigate to select
one paper, which will be displayed in the details view.

16
 17

8.3 Relation to Hypertext Modeling

Presentation modeling is representation of layout for the underlying navigation and process
models is an abstract presentation.Concrete presentation requires specification of additional
physical properties of the layout color, position.
Presentation classes represent Web pages or part of pages.Composition of user interface
elements and hierarchical composition of presentation element.UML class diagram for the
structure of the presentation using UML container notation.UML interaction diagram or
sequence diagram used for modeling behavior of presentation classes and develop of a prototype.

Figure: Interaction overview diagram of the reviewing system

Similarly to mapping the content model to the hypertext model, we also have to specify how
hypertext elements should be mapped to presentation elements. This is normally done under the
assumption that all instances of a node will be displayed on the presentation level.
As mentioned before, the interactions triggered by a user are not necessarily limited to the
presentation level only. For this reason, we have to additionally consider their correspondences
to the other links. This correspondence may be in the form of objects and application logic on the
content level, and for navigation on the hypertext level.

17
 18

Figure: Sequence diagram for retrieving a list of assigned papers

9. Customization Modeling
Since ubiquitous Web applications increasingly gain importance, the consideration of context
information and an appropriate adaptation of the application as early as possible in the modeling
phase are required.

Figure Sequence diagram for displaying selected papers.

9.1 Objectives
Customization modeling is aimed at explicitly representing context information, and the
adaptations derived from it. Depending on the modeling method the result is not always an
explicit customization model. In most cases, customization modeling is intermingled with
content, hypertext, and presentation models.
Customization has to be distinguished from maintenance or re-engineering. Customization
modeling considers context information that can be predicted at modeling time which can
assume different values when the Web application is run. In contrast, adaptation due to changes

18
 19

in the organizational or technological environment is part of maintenance or re-engineering

activities.

9.2 Concepts
Customization requires examining the Web application’s usage situation, i.e., dealing with the
questions of ‘‘what’’ should be adapted and ‘‘when’’. To be able to personalize a Web
application we have to model and manage the preferences and characteristics of a user in a so-
called user profile. For example, to adapt a Web application in the field of mobile computing, we
have to consider device profiles, location information, and transmission bandwidth. This
information is then represented within the context model in form of a class diagram. At runtime,
context can change, e.g., users change their preferences, or the application is ‘‘consumed’’ at
different locations. This situation, in turn, is the reason why we have to adapt the Web
application.
Figures below, show how the hypertext and presentation levels of the reviewing system
example can be dynamically adapted. We use annotations – stereotyped with customization – to
add customization rules to the adapted class. The rules described informally in this example can
be specified in more detail by using a formal language, e.g., the Object Constraint Language
(OCL) (Baer dick et al. 2004), in further refining steps. These shows an example of how the
hypertext structure can be customized so that the papers a user can read are limited to those with
topics of interest to that user. The elements of the access structure, ‘‘Interesting Papers’’, are
adapted dynamically by transformation rules based on personal topics of interest.
The example in Figure shows how elements of the presentation model can be adapted by the use
of transformation rules. Specifically, the button ‘‘Enter Review’’ should be visible only for users
with the ‘‘Reviewer’’ role.Most of the currently existing methodologies tackle the modeling of
customization by defining rules or a filter for each point in the Web application where
customization applies as has been shown in the previous examples. A different approach is to
consider customization as across-cutting concern. UWE follows such an approach using aspect-
oriented modeling (AOM) techniques (Baumeister et al. 2005). AOM allows on the one side for
a systematic separation of the system functionality from the customization aspects, and on the
other side it allows for reduction of redundancy.

19
 20

Figure:Dynamic adaptation of an index in the hypertext model.

Figure: Dynamic adaptation of a page in the presentation model

UWE materializes the cross-cutting concern by the use of stereotyped UML packages for the
point cut part and the advice part of an aspect. An aspect is a (graphical) statement saying that in
addition to the features specified in the principal models, each model element of the package
point cut also has the features specified by the advice. In other words, a complete description
including both general system functionality and additional, cross-cutting features is given by the
composition – so-called weaving – of the main model and the aspect.

Figure below shows how the designer used the Navigation Annotation to add an attribute (Pres
Style) included in the advice part to the set of links included in the point cut part. Figure shows
the results of the weaving Process.

20
 21

Figure:Modeling adaptation with aspects.

Figure:Results of the waving process

Dynamic customization can be achieved including rules written in OCL in the advice part of the
aspect.

9.3 and 9.4 Relation to Content, Hypertext, and Presentation Modeling

As shown in Figure customization can influences all levels of a Web application modeling
process. Changes can be limited locally to one level or affect several levels. Separation of the
customization model from the content, hypertext, and presentation models are recommended
with regard to changeability, flexibility, and encapsulation, but most existing methods don’t
provide for this separation. And sometimes, as in the reviewing system, such a separation is

21
 22

difficult. For example, the user of a Web application and his or her preferences are context
modeling issues, but the user may also be an issue in content modeling, as the reviewing system
example shows.
10. Methods and Tools
All modeling methods offer a set of modeling elements tailored to the requirements of Web
applications (Retschitzegger 2000). Almost all methods offer a specific notation for the modeling
elements. In addition, many methods define a process and are supported by a tool that (semi)
automatically generates an implementation from the created models.
10.1 Modeling Methods: An Overview
Methods available for Web application modeling are normally based on traditional methods,
such as ER, or they enhance an object-oriented modeling language, e.g., UML. More recent
methods usually build on the strengths of earlier methods. Consequently, we can describe the
history of Web application modeling methods as shown in Figure 3-17 (based on Escalona
2004).Modeling methods follow different paradigms, depending on their origin and focus:
• Data-oriented methods originate from the field of database systems; they are mainly based
on the ER model enhanced by specific concepts for modeling on the hypertext level. The primary
focus of these methods is the modeling of database-driven Web applications.Examples of data-
oriented methods include the Relationship Management Methodology (RMM) (Isakowitz et al.
1998), Hera (Houben et al. 2004) and the Web Modeling Language(Web ML) (Ceri et al. 2003,
Brambilla et al. 2005).
• Hypertext-oriented methods center on the hypertext character of Web applications; they
emerged mainly from the field of hypertext systems (Lowe and Hall 1999). Representatives of
this group are the Hypertext Design Model (HDM) (Garzotto et al. 1995), which has been
extended into W2000 (Baresi et al. 2001), and HDM-lite (Fraternali and Paolini 1998),or the
Web Site Design Method (WSDM) (DeTroyer and Decruyenaere 2000, Plessers et al. 2005).
• Software-oriented methods look at Web applications mainly from the perspective of
traditional software development, using techniques that strongly follow classical Software
Engineering. Good examples for this category are Web Application Extension (WAE), or
WAE2, its enhanced version (Conallen 2003).

22
 23

Figure:Historical development of methods for Web application modeling.

10.2 Model-Driven Development

The Model-Driven Development (MDD) approach not only advocates the use of models (such
as those described in the previous sections) for the development of software, but also emphasizes
the need of transformations in all phases of the development, from system specification to
implementation and testing. Transformations between models provide a chain that enables the
automated implementation of a system in successive steps right from the different models
defined for it.
The development of Web applications is a specific domain in which MDD can be successfully
applied, due to the Web specific characteristic separation of concerns – content, hypertext,
presentation and customization. Methods such as WebML, OO-H and UWE constitute a good
basis for model-driven approaches for the development of Web applications. They already
include some semi-automated model-based transformations.
WebSA (Web Software Architecture) is another specific model-driven approach for the Web
domain, which is based on theMDA(Model-Driven Architecture) paradigm.WebSA – analogous
to MDA (OMG2005) – emphasizes the construction of platform independent models (PIMs) and
the subsequent automated building of platform specific models (PSMs), where PSMs constitute
the basis for the generation of executable code (Meli´a and Cachero 2004).The WebSA
methodology proposes a development process made up of a set of UML models used to represent
the Web application and QVT1 (OMG 2005) transformations.

23
 24

In a first step the transformations (T1) are a mechanism to integrate architectural models and the
structural and behavioral models of a Web application.
10.3 Tools Support
Due to short development cycles and the complexity of Web applications, it is recommended to
use tools that support not only the modeling itself, but also and particularly automatic code
generation and model consistency check. The following subsections describe Web Ratio Site
Development Studio, VisualWADE, and the OpenUWE Suite as examples for this type of Tools.

Figure: WebSA Development Process

10.3.1 WebRatio Site Development Studio

The WebRatio Site Development Studio (www.webratio.com) is a model-based development
tool that builds on the Web Modeling Language (WebML) (www.webml.org). This tool uses its
own notation for hypertext modeling and additionally supports the ER notation and UML. The
tool’s code generator uses XSL to transform content and hypertext models represented in XML
into the required database representation and database connections as well as software
components and different output formats (HTML, WML, PDF,Microsoft Word).

10.3.2 VisualWADE
The Visual WADE tool is based on the OO-H method. This tool supports modeling and
automatic generation of applications based on XML, ASP, JSP, and PHP.VisualWADE
augments a UML model with two additional models: ‘‘Navigation View’’ is used to model the

24
 25

hypertext aspect of a Web application, and ‘‘Presentation View’’ represents interaction elements
of the user interface with regard to its structure and behavior using a number of template
structures.
10.3.3 OpenUWE
The OpenUWE tool suite is a development environment for the design and generation of Web
applications using the UWE methodology. The main feature
of this suite is its open architecture based on established standards. These standards are
supported by both open-source and commercial tools. In its current version (still under
development),this development environment includes the ArgoUWE case tool and the
UWEXML framework,consisting of a model consistency checker, a layout editor, and code
generators for the Cocoon XML Publishing Framework (Ziegeler and Langham 2002) and Java
Server Pages. The common data exchange language within this architecture is based on the
extensible UWE meta-model.

25