Web Engineering

Modeling Web
Applications

Muhammad Umair Naru

Department of Computer Science
COMSATS Institute of Information Technology
Overview
 Introduction
 Requirements Modeling
 Content Modeling
 Hypertext Modeling
 Presentation Modeling
 Customization Modeling
Why Create Models?
 Define an abstract view of a real-world entity
 Finding & discovering objects/concepts in a
domain
 Assigning responsibilities to objects
 Tool of thought
 Reduce complexity
 Document design decisions
 Means of communication
 Software Application Modeling
Levels

User interface

Application Logic

Phases
Structure Analysis Design Implementation

Behavior

Aspects

 Levels – the “how” & “what” of an application

 Aspects – objects, attributes, and relationships; function &
processes
 Phases – Development cycle
 Web Application Modeling
Levels

Presentation
Hypertext
Customization
Content

Phases
Structure Analysis Design Implementation

Behavior

Aspects

 Levels – Information, node/link structure, UI & page layout separate.

 Aspects – Same as Software Applications
 Phases – Approach depends upon type of application
 Customization – Context information
Web Modeling
 Modeling static & dynamic aspects of
content, hypertext, and presentation.
 We focus on object-oriented analysis &
design
 Analysis: Finding & discovering classes of
objects/ concepts in a domain
 Design: Defining software objects & how they
interact to fulfill requirements.
Objects
 Software entities – like real-world entities - that
consist of states and behaviors.
 States:
 Variables store the states of an object’s properties.
 Hidden from the outside world (data encapsulation)
 Behaviors:
 Methods define the object’s behaviors.

 Used by objects to communicate with other

objects.
 Classes – blueprints for creating objects of a
particular type.
Discovering Objects in a Domain
 The way we represent a domain’s software model should
resemble the physical model as closely as possible.
 To find key classes of objects:
 Reuse existing models, if they exist.
 Make a category list
People, places, things
 Transactions

 Events

 Identify noun phrases

 When naming classes, use terms that are commonly used

in the domain – terms users would understand.
Assigning Responsibilities
 Responsibilities are an object’s obligations, or
behaviors related to its role in the system.
 What does an object do?
 Doing something (to) itself
 Pass actions (messages) to other objects
 Controlling & coordinating the activities in other
objects
 What does an object know?
 Private, encapsulated data
 Its related objects
 Items it can derive or calculate
 Unified Modeling Language
(UML)
 “The Unified Modeling Language is a visual
language for specifying and documenting the
artifacts of systems.” [OMG03a]
 Language of choice (and ISO standard) for
diagramming notation in OO development.
 Structural – Class diagrams (domain models)
 Behavioral – Use Cases, Sequence diagrams
 Currently at version 2.0, although many analysts
and designers still use 1.0.
 UML for Web Engineering
 For Web-centric modeling, we will employ
the UML Web Engineering (UWE) notation.
 http://www.pst.ifi.lmu.de/projekte/uwe/
 UML-compliant
 Comprehensive modeling tool
 Not the only modeling language
 WebML, OOHDM, etc.
 p. 60 of Kappel lists a dozen alternatives
and their features.
Requirements Modeling
 Serves as a bridge between Requirements &
Design phases
 Uses cases – functional requirements written
as a collection of related success & failure
scenarios.
 Scenario – a sequence of actions &
interactions between actors and a system.
 Preferred means of modeling requirements
 Written descriptions are easy to understand
 Emphasize the users goals and perspective
 Use Cases
 Defining valid system use cases:
 The Boss Test – measurable value
 The EBP Test – one person, one place, one time
 The Size Test – more than one step
 Which is a valid use case?
 Negotiate a Supplier Contract
 Handle Returns
 Log In
 Move Piece on Game Board
 Use Cases
 Critical components
 Use Case Name – starts with a verb
 Level – “user-goal” or “subfunction”
 Primary Actor – the user whose goal is fulfilled
 Stakeholders & Interests – Who cares, and
what do they want?
 Preconditions – What must be true at the start
 Success Guarantee – defines the successful
completion of the use case for all stakeholders
 Main Success Scenario – the steps necessary
to complete the task successfully.
Use Case – Example 1
Use Case 1: Create User
 Scope: University or business network
 Level: user goal
 Primary Actor: user (system administrator)
 Stakeholders and Interests:
 System Administrator: Wants control over users’ access to system
resources.
 New User: Wants access to system resources for communication,
business, and research.
 Organization: Wants security and controlled access of organization
resources, data, intellectual property; wants employees/students to
have appropriate system access to fulfill the goals of the organization.
 Preconditions: User is identified, authenticated, and has opened
administration tool
 Success Guarantee: New user account is created and saved.
Username and password grant the new user access to network.
Use Case – Example 1 [cont.]
 Main Success Scenario:
1. System requests input for username & password
2. User enters username & password
3. System requests other identifiable user
information (ex. real name, SSN#, address)
4. User enters other identifiable user information
5. System verifies username & password
6. System stores new user information
7. System displays success message
8. System presents user options
Use Case Guidelines
 Use shorts sentences
 Delete “noise” words
 NO : “The System authenticates…”
 YES: “System authenticates…”
 Avoid technology-specific terms (initially, at
least)
 NO : “Cashier swipes Product ID across
scanner.”
 YES: “Cashier enters Product ID.”
Use Case – Example 2
 Make Withdrawal
 Use Case Diagrams
 Provide a graphical overview of a system’s use
cases, its external actors, and their relationships
 They are NOT requirements!
 Helpful in complex projects with
many actors, processes

Source: Web Engineering – Kappel et al.

Content Modeling
 Purpose: To model the information
requirements of a Web application
 Diagramming the structural (i.e., information
objects) & behavioral aspects of the
information.
 NOT concerned with navigation.
 Primary Models
 Class diagrams – enough for static
applications.
 State machine diagrams – captures dynamic
aspects
 Class Diagrams
 Notations

Class Name

Multiplicity
Attributes

Operations

Source: Web Engineering – Kappel et al.

 Class Diagrams
 Notations (continued)

Composition Derived Attribute Value

Invariant

Source: Web Engineering – Kappel et al.

 Class Diagram – Example 1
 Conference Paper Submission System

Source: Web
Engineering –
Kappel et al.
 Class Diagram – Example 2
 Online Library Application (PITTCat)
State Machine Diagrams
 For dynamic Web applications, they depict
important states and events of objects, and how
objects behave in response to an event
(transitions)
 Show the life-cycle of an object.
 Used only for state-dependent objects
 For pure UML modeling, can be very useful for
hypertext models (next section).
State Machine Diagram - Example
 The life-cycle of a Paper object in the conference
paper submission system.

Source: Web Engineering – Kappel et al.

Hypertext Modeling
 Purpose: To model the navigation paths
available to users.
 UWE Artifacts
 Hypertext Structure Model – navigating among
classes
 Access Model – UML-compliant site map
 Focuses on the structure of the hypertext &
access elements.
 Use “<<navigation class>>” annotation to
distinguish from content classes.
Hypertext Structure Model
 Conference Paper Submission System

Source: Web Engineering – Kappel et al.

Access Model
 Hypertext structure models describe
navigation, but not orientation.
 Access models describe both through
Navigation patterns, used to consistently
describe conventional elements.
 <<index>> (list of objects of the same type)
 <<menu>> (list of heterogeneous objects)
 <<guided-tour>> (sequential links)
 <<query>>
Access Model - Example

Source: Web
Engineering –
Kappel et al.
 Presentation Modeling
 Purpose: To model the look & feel of the
Web application at the page level.
 The design should aim for simplicity and self-
explanation.
 Describes presentation structure:
 Composition & design of each page
 Identify recurring elements (headers/footers)

 Describes presentation behavior:

 Elements => Events
 Levels of Presentation Models
 Presentation Page – “root” element;
equivalent to a page container.
 Presentation Unit
 A fragment of the page logically defined by
grouping related elements.
 Represents a hypertext model node

 Presentation Element
 A unit’s (node’s) informational components
 Text, images, buttons, fields
 Composition Model - Example
 Paper and Author Page Templates

Source: Web Engineering – Kappel et al.

 Sequence Diagrams
 Purpose: Depicts sequential interactions
(i.e., the flow of logic) between objects in an
application over time.
 What messages, what order, & to whom.
 Ex.: Object A calls method of Object B
 Ex.: Object B passes method call from Object
A to Object C.
 Result: Dynamic system interactions
diagrammed in a “fence” format.
 Sequence Diagram - Notation

Object Instance

Lifeline

Focus of Control

Synchronous
Message

Destroy Object

Source: Wikipedia – Sequence Diagram

Sequence Diagram – Example 1

Source: Web Engineering – Kappel et al.

Sequence Diagram – Example 2

Source: Web Engineering – Kappel et al.

 Customization Modeling
 Ubiquitous applications often require multi-
platform and/or personalized delivery.
 Purpose: To represent content adaptation
based on context information.
 Developed quite recently, so customization
models are often integrated with other
diagrams.
 Use <<customization>> annotation to denote
customization rules in adapted classes.
Customization Modeling Concepts
 User Profile – preferences & characteristics
 Physical context – user or location
 Logical context – situational knowledge
 Context adaptation
 Static – A unique model for every variant
 Dynamic – Rule-based transformation
 Events/Conditions/Actions
 Actual variants created at runtime, so model may
be harder to understand.
Customization Modeling - Approaches
 Integrated Modeling
 Applied as rules or filters at Web apps
customization points
 Used by most modeling schemes

 Aspect-Oriented Modeling (AOM)

 General system functionality separated from
customization aspects.
 UML aspects (pointcuts/advice) used to
graphically “weave” the main model with
custom features.
 Dynamic Adaptation - Integrated
 Filtering papers based on interest

Source: Web Engineering – Kappel et al.

 Dynamic Adaptation - Integrated
 Link Hiding example

Source: Web
Engineering
– Kappel et
al.
 Dynamic Adaptation - AOM
 Ex. Adaptive presentation (add “rejected” annotation)

Source: Web
Engineering –
Kappel et al.
 Dynamic Adaptation - AOM
 Previous example weaved into hypertext model.

Source: Web Engineering – Kappel et al.