Modelling Internet Applications

1
Modelling Internet Applications

• Part VIUbiquitous Web Applications

2
Motivation
Demand for Ubiquitous Web Applications

• additionally to the chriteria of "traditional Web
  applications" allow for ubiquitous access to
  services anytime / anywhere / anymedia

• Applications
• Personalized web applications
• Multi-delivery
• Nomadic computing
• Accessibility / Special-needs

3
Motivation

• Ubiquitous Web Applications
• have to be "aware" of their context - "Situation
  of Use"
• Context is not what is explicitely provided but
  which comes aside
• e.g. device, network, user, location, time
• have to adapt accordingly
• changing the "standard" Web application

Customisation Adaptation to Context
4
CustomizationFrom Context to Adaptation
description of situations of use
Core Web Application
description of which situation requires which
adaptation
Mapping
Customization
description of changes to the Web application
Ubiquitous Web Application
"Customisation for Ubiquitous Web Applications -
A Comparison of Approaches". Co-Authors Kappel
Gerti, Pröll Birgit, Retschitzegger Werner. In
INTERNATIONAL JOURNAL OF WEB ENGINEERING AND
TECHNOLOGY (IJWET), Vol. 1, Issue 1, Inderscience
Publishers, ISSN 1476-1289, January 2003.
5
Goals of Customization

• "Semantic Enhancement"
• increasing the user value of the applications
• each particular user is provided with a specific
  added value
• e.g. personalization
• give me just the information I am interested in
• "Semantic Equivalence"
• keeping the user value equivalent across despite
  restrictions of the context of usage
• the user's value is maintained despite
  constraints in the environment
• e.g. multi-delivery
• give me the news information regardless whether I
  use my PC or a smart phone

6
Customization RequirementsCustomizability
Context

Adaptation
7
Customization RequirementsCustomizibility
Examples

8
Customization RequirementsStatic vs. Dynamic

• Static and Dynamic may vary depending on the
  point of view
• For particular objects the adaptation might be
  static whereas the overall application could be
  dynamic
• Static / Dynamic regarding Modeling time vs.
  run-time
• Modeling time the ability to define the
  outcome(s) at definition time
• Run-time the adapted result is already
  avaliable or needs to
• be computed during run-time
• Historic context is definitely dynamic context
• Current context can be static (web / wap) but
  also dynamic context (time).

9
Customization Requirements

• Often context information is considered in
  isolation
• Personalization, location-awareness,
  multi-delivery

• But, example

• Requirement

"Show me those mutimedia presentations of PoI
currently visitablewithin my vicinity I am
interested in, which I have not jet seen taking
into account my current device's capabilites."

• Necessary to consider diverse context information
  in terms of time, location, device, users
  preferences, etc. in combination

10
Customization Modeling

• Goal regarding all requirements of customization
• Designed from the start to take the ubiquitous
  nature into account
• Customization as the uniform mechanism to enable
  ubiquity
• by adapting towards a particular
• context which reflects the environment
• Holistic view on the development
• process by introducing
• customization as additional design dimension
• effecting all dimension of traditional web
  application modeling

11
Where does Customisation Take Place?

• Is the application
• customisation-aware or not?

HTTP-Response
HTTP-Request
12
Customisation by Static Adaptation

• along user group

13
Customisation by Static Adaptation

• along user group

device category
14
Customisation by Static Adaptation

• Customisation by means of static adaptation
• The designer can produce a series of statically
  adapted design versions with respect to a
  (distinguishing) context property, i. e.,
  explicitly defining the results of customisation
• e.g., making different designs for "PC_Chair" and
  "Author", both encountering a very distinct
  application (i. e. different information,
  different navigation, and different presentation)
• Suffers from the "combinatoric explosion" problem
  ? nm different design versions

n .... number of distinct context property values
m ... number of considered context properties

• Advantage
• outcome of customisation is seen at design time
• Disadvantage
• limited number of statically adapted version

15
Customisation by Dynamic Adaptation

• customisation along user group

16
Customisation by Dynamic Adaptation

• customisation along user group

device category
17
Customisation by Dynamic Adaptation

• Customisation by means of dynamic adaptation
• The designer specifies customisation rules which
  dynamically apply adaptation operations to
  potentially statically adapted design versions,
  i. e., defining transformation process of
  customisation
• e.g. modelling a general model and just
  specifying the variations according to the
  dynamically found type of user.
• linear growth instead of combinatory explosion
  ? n m different customisation
  rules

n .... number of distinct context property values
m ... number of considered context properties

• Advantage
• required for customisation towards context
  properties encountering a virtually unlimited
  number of context property values
• Disadvantage
• outcome of customisation is not seen at design
  time
• difficult to detect conflicting adaptations

18
Customisation by Static and Dynamic Adaptation

• customisation along user group device category

• Static and dynamic adaptation can be used
  complementary
• Statically adapted designs should only be used
  for context properties requiring "fundamentally"
  different designs
• Dynamic adaptation necessary for an unlimited
  number of variations

19
Static and Dynamic Customisation

• Customisation along user group device category

static
dynamic

• Static and dynamic adaptation can be used
  complementary
• Statically adapted designs should only be used
  for context properties requiring "fundamentally"
  different designs
• Dynamic adaptation necessary for an unlimited
  number of variations

20
Degree of Customization Design
Degree of Customizability

static
dynamic
21
The UWA Approach to Customisation

• EU-funded Fifth Framework Program project
  (IST-2000-25131)
• Objectives
• Define a set of methodologies, notations, and
  tools to support the design and fast prototyping
  of complex ubiquitous web applications
• Propose a set of notations based, along with a
  set of heuristics and guidelines to help
  developers
• Provide tool support to make the design activity
  more efficient
• Approach
• Explicit requirement elicitation, hypermedia
  modelling, transaction support and ubiquity
  modelling
• UML profile for UWA-specific concepts
• Dynamic rules as a means to deal with ubiquity
• Extension of existing UML tool to facilitate an
  integrated development process

22
The UWA Approach to Customisation
ModellingCustomisation Architecture
operationalise
Requirements
CustomisationModel
Logical Context
Physical Context
Web Application
maschine
world
realises
satisfies
Service
Goals
23
The UWA Approach to Customisation
ModellingCustomisation Architecture

• Reification of the environment in terms of an
  explicit
• physical context model information sensed from
  the environment
• logical context model high-level descriptions of
  the situation of use
• Separation of the core functionality of a web
  application (stable part) from its
  context-dependent part (variable part)
• Adaptation of all aspects of content, hypertext,
  presentation
• Specification of dynamic customisation in terms
  of event-condition-action rules to reflect
  dynamicity

24
The UWA Approach to Customisation
ModellingPhysical Context Model

• Manageable description of the environment and the
  Web application itself
• At a very low level of abstraction (e.g. what is
  provided by sensors)
• Open and extensible to include new properties
  (e.g. temperature, altitude, battery level ) in
  the sense of an object-oriented framework
• Updates outside the scope of the Web application

25
The UWA Approach to Customisation
ModellingPhysical Context Model
26
The UWA Approach to Customisation
ModellingLogical Context Model

• Logical context represents more stable,
  abstracted information
• Can be provided simply by means of profiles or by
  using abstraction mechanisms such as aggregation
  and inference
• Needed to enrich the physical context, e.g. to
  derive the street name from a sensed X/Y-position
• Modelled as profiles and organized in UML
  packages
• Open and extensible to include new profile
  information and abstractions

27
The UWA Approach to Customisation
ModellingLogical Context Model - Profiles
LogicalContextModel aLogicalContextModel
ProfileModel aLocationProfile
ProfileModel aTimeProfile
ProfileModel aUserAgentProfile
ProfileModel aUserProfile
ProfileModel aNetworkProfile
ProfileModel anApplicationProfile
28
The UWA Approach to Customisation
ModellingLogical Context Model - Location
PhysicalContextModel aPhysicalContextModel
ProfileModel LocationContextModel
access
GenericLocationContextModel
interfaceLocationMapper
Country
GeoPos
name
xCoordinateyCoordinate
getGeoPos(cellID)getCellID(x,y)

District
LocationService

name famousFor
partOf
ApplicationSpecificLocationContextModel

interfacePoliticalCartography




LogicalLocation

getCountry(x,y)getStreetName(x,y)getDistrict(x,y
)getTown(x,y)getDistance(x1,y1,x2,y2)
AtBanquet
name
get()
OnTour



InLectureRoom
Town
name inhabitants
interfacePhysicalCartography

getAltitude(x,y)getLandscape(x,y) getDistance(x1,
y1,x2,y2)
Street
AtHome
name
AtWork
29
The UWA Approach to Customisation
ModellingLogical Context Model - Time
LogicalContextModel TimeProfile

aLocationProfileTown
GenericTimeProfile
aLocationProfileGeoPos

TimeZone
1

aLocationProfileCountry
id name differenceToGMT
1

aLocationProfileDistrict
1

getLocalTime(GMT, x, y) getLocalDate(GMT, x,
y) getGMTTime(localTime, x, y) getGMTDate(localDat
e, x, y)
ApplicationSpecifcTimeProfile
OpeningHours
date openingTime closingTime
1
DaylightSavingTime
isOpen(date, time) openFromTo(date)
startDate endDate timeDifference
1
dayOfTheWeek
getNormalTime(x, y, localTime) getCurrentTime(x,
y, localTime)
DistrictOpeningHours
ConferenceOpeningHours
highLiveTime
break
isHighLiveTime(date, time)
isBreak(date, time)
30
The UWA Approach to Customisation
ModellingLogical Context Model - Device
LogicalContextModel UserAgentProfile
ApplicationIndependent DeviceProfile
DeviceCategoryHierarchy

DeviceProperty
isOfType
DeviceCategoryComponent

isPartOf

get()
Hardware
Software
displaySize colourSupport memory cpu avgBandwidth
maxBandwidth
type name version vendor

DeviceType
DeviceCategory
1
name
name
isOfCategory(name)
e.g. Nokia 6xxx-series, WAP-enabled mobile, WAP
e.g. Nokia 6120
supports

supports

MarkupLanguage
MIMEType
type version
type name


31
The UWA Approach to Customisation
ModellingLogical Context Model - User
LogicalContextModel UserProfile
GenericUserProfile
roleOf
User


Role
login password phoneNumber currentRole

currentRole
1
ExpertiseRole
ActorRole
get()
Novice
Expert
xor
ApplicationSpecificUserProfile
1
1
1
1

1
1
1
aDeviceProfileDeviceCategory
PC_Member
PC_Chair

1
Author
Staff


1
1



1
1

1
BirdsOfAFeather
1
date time
getNumberOfParticipants()
32
The UWA Approach to Customisation
ModellingLogical Context Model - Network
LogicalContextModel NetworkProfile
supportedConnectionTypes
aUserAgentProfileDeviceCategory


Connection
maxThroughput
Throughput
type
1
1
bandwidth


providedConnectionTypes
1

ThroughputLevel
MobileTelephoneProvider
name
Low
Mid
High
33
The UWA Approach to Customisation
ModellingLogical Context Model - Application
34
The UWA Approach to Customisation
ModellingAdaptation Modelling

• Adaptation activates the variable part of the Web
  application
• Modelling Adaptation shall provide for
• Generic adaptation operations
• depending on the model elements, e.g.,
• pictures may be resized,
• links might be enabled,
• collections may be sorted,
• content may be filtered
• Application-specific adaptation operations
• the designer is enabled to introduce arbitrary
  adaptation operations

35
The UWA Approach to Customisation
ModellingCustomization Modelling

• Customisation Rules are
• formulated in terms of event/condition/action-rule
  s
• allow declarative specification of dynamic
  customisation
• Event
• identifies the potential need for customisation
• predefined in a generic Event Model
• extensible by additional primitive events and
  composite events
• Condition
• identifies if customisation is actually needed
• very often reasons about the context
• specified in OCL
• Action
• activates a certain adaptation operation

36
The UWA Approach to Customisation ModellingEvent
Model
EventModelanEventModel
2..
Event

1..
1..
PrimitiveEvent
EventOperator
CompositeEvent
AND
OR
SEQ
ChangeOfLogicalContext
ChangeOfPhysicalContext
ChangeOfTime
ChangeOfDevice
ChangeOfNetwork
ChangeOfUser
ChangeOfApplicationState
ChangeOfBrowser
ChangeOfLocation
37
The UWA Approach to Customisation
ModellingAdaptation Modelling

• Micro Adaptation (a single model element is
  adapted)

38
The UWA Approach to Customisation
ModellingAction Model
ActionModelanActionModel
1
1..
1
Action
ActionList
0..1

BlockAction
AtomicAction
1
1
ifBlock
elseBlock


Operation
Assignment

SimpleBlock
IterationBlock
IfBlock
.

ApplicationSpecificAO
WhileBlock
UntilBlock
GenericAO
1
1
aConditionModelLogicalExpression


InformationDesignAO
PresentationDesignAO
OperationDesignAO
NavigationDesignAO
EnablePage
EnableEnitity
...
...
DisableEnitity
DisablePage
EnableCluster
EnableOperation
...
...
SetEntityFilter
DisableCluster
SetPageEntrance
DisableOperation
AddNode
SetPreCondition
39
The UWA Approach to Customisation
ModellingCustomization Rules

• Example 1/3 - Requirements

Context Device used is not graphics enabled
Adaptation Change the description to text mode
40
The UWA Approach to Customisation
ModellingCustomization Rules

• Example 1/3

Event changeOfDevice Condition
session.historycurrent.context.userAgent.device
Type profile.device.type AND
profile.device.graphicEnabled 'FALSE'
Action textMode description.switchTo('text')

41
The UWA Approach to Customisation
ModellingCustomization Rules

• Example 2/3

Context Moved more than 5 km
Adaptation Recompute the route description
42
The UWA Approach to Customisation
ModellingCustomization Rules

• Example 2/3

Event changeOfLocation Condition
session.historycurrent.context.location.distan
ce(session.history'StartTime'.context.location)
gt '5 km'
Action recomputeRoute routeDescription.comput
e(context.location)
43
The UWA Approach to Customisation
ModellingCustomization Rules

• Example 3/3

Context Bandwith fallen below 10kb
Adaptation Adapt the graphics accordingly
44
The UWA Approach to Customisation
ModellingCustomization Rules

• Example 3/3

Event changeOfBandwidth Condition
session.historycurrent.context.bandwidth lt
'10 KB'
Action resizeGraphics overviewMap.resize(cont
ext.bandwidth) detailMap.resize(context.bandwidt
h)
45
The UWA Approach to Customisation
ModellingCritical Reflection

• What belongs to content and what belongs to
  context is sometimes blured
• Very "fine grained" - concernd may be too much
  with the details of formulating constraints
• Notation hard to understand and to communicate to
  the user
• Way of annotating clutters the customization
  model
• e.g. what if I want to see all personalization
• No "semantics" of how the context is actually
  filled
• Event-driven approach might not be "feasible" way
  of thinking for often changing context
• Static adaptation realization quite artificial

46
The UWA Approach to Customisation
ModellingCritical Reflection

• Let it be said in the words of the user
• Notation matters - need for easy to understand
  icons and graphic representation
• Understandability prevails detailed semantics
• Need to see customization as cross-cutting
  concern
• Modeling can be either
• full specification prior to implementation
• pragmatic approach to communicate to the user

47
Design Space of Customisation
48
ContextKind of Context

• Property aspects of the context which are
  relevant
• Natural context location time
• Technical context device, browser, network
  bandwidth, application itself
• Social context user, user groups
• Genericity how generic certain context
  information is
• Application specific only needed for a
  particular web application only
• Application independent / generic applies for a
  series of applications
• External source / third party provider
  information is available outside the application

49
ContextSubject of Context

• Time Span for which time span the context is
  considered
• Current context context at the time of the
  request, e.g. current user
• Historical context previous context, e.g.
  previously visited locations
• Future context prediction of future context,
  e.g. prediction of throughput
• Abstraction at which level the context
  information is considered
• Physical context can be directly sensed for the
  environment, e.g. cellID
• Logical context additional explicit information,
  e.g. street name

50
ContextQuality of Context

• Automation how automatic the context information
  is considered
• Automatic context information is collected
  automatically, e.g. usage analysis
• Manual explicitly given information, e.g. user
  specifies his/her preferences
• Semi-automatic combination of automatic and
  manual
• Availability how unavailability of context
  information is treated
• Default context a default is assumed, e.g.
  user's ID is not available assume default user
• Provide context manually query for the context,
  e.g. if the current location is not available,
  prompt the user
• Denial of the service service won't work without
  the context, e.g. "service only available for
  registered users"

51
ContextQuality of Context

• Dynamicity how frequently the context is
  considered
• Static determined once at application start up,
  e.g. the device used to select the appropriate
  interaction style
• Dynamic determined during runtime, e.g. the
  bandwidth to adapt the resolution accordingly
• Validity how valid the context information is
• Context properties may not be valid during the
  complete period until they are sensed again,
  e.g. if the location information doesn't change
  within a certain period, the device might not be
  online any longer, thus the location information
  might no longer be valid

52
AdaptationKind of Adaptation

• Effect what is the effect of the adaptation
• Enhance adding to the service, e.g. displaying
  personalised ads
• Reduce removing certain parts of the service,
  e.g. disabling video sequences
• Transform combination of enhancement and
  reduction, e.g. showing a textual description
  instead of a road map
• Complexity atomicity of the adaptation
• Atomic is performed as a whole, e.g. disabling
  a picture
• Composed combination of a series of adaptations,
  e.g. showing a textual description instead of a
  road map is composed of the removal of the road
  map and the presentation of the textual
  description
• Genericity reusability of adaptation
• Application specific just meaningful for a
  certain web application
• Generic independent of the actual web
  application

53
AdaptationSubject of Adaptation

• Application level which levels are adapted
• Content level domain dependent data, e.g.
  discount calculation
• Hyperbase level logical composition of the
  hypertext and access structures, e.g. guided
  tour navigation rather then free navigation
• Presentation level layout to each page, e.g.
  use adequate grey scale representation for colour
  blind
• Application element which elements are adapted
• Elements of content, hyperbase, and presentation
  level e.g. like pages, links, access
  structures, input fields, lists
• Granularity which level of detail the adaptation
  is applied
• Micro adaptation fine-grained adaptation
  effecting a single element, e.g. disable a
  single link
• Macro adaptation large parts are adapted
  effecting multiple application elements, e.g.
  change from a screen oriented presentation to a
  print oriented presentation
• Abstraction which level of abstraction the
  adaptation addresses
• Type level adaptation through schema evolution,
  e.g. removing attributes
• Instance level certain instances are adapted,
  e.g. filtering certain restaurants complying
  with the user's price category

54
AdaptationQuality of Adaptation

• Dynamicity how frequently the context is
  considered
• Static results of adaptation are already defined
  at design time, e.g. two predefined version of
  an image with high and low resolution intended
  for a desktop computer and a handheld,
  respectively
• Dynamic results of adaptation are generated
  during runtime, e.g. adapting an image according
  to bandwidth during runtime
• Automation how automatic the adaptation is
• Automatic the user cannot take influence on the
  adaptation
• Manual the user decides which adaptation to
  apply
• Semi-automatic combination of automatic and
  manual

55
AdaptationQuality of Adaptation

• Visibility to whom the adaptation is visible
• Globally all users within the same session
  perceive the adaptation
• Group of users a certain group of users perceive
  the adaptation, e.g. authorized users
• Individual users adaptation is perceivable only
  for an individual user, e.g. regarding personal
  preferences
• Reusability how the adaptation can be reused
• From scratch adaptation is done on bases of the
  original (non-adapted) version, e.g.
  transforming a video to a series of picture
  scenes needs to be conducted from the original
  video
• Incrementally subsequent adaptations are
  conducted on bases of the previously adapted
  version, e.g. continuously adaptation towards
  the user's usage habits

56
Customisation

• Semantic value in which way the semantics are
  effected
• Enhance customisation realises a better service,
  e.g. location-awareness and personalisation
• Reduce customisation produces a reduced service,
  e.g. restriction for non-authorised user
• Preserve maintain the service, e.g. throughout
  the restricted capabilities of devices
• Initiation which point in time the customisation
  is initiated
• Immediate initiated each time a change in the
  context is detected independently of any user's
  request , e.g. pre-generation
• Deferred not before a user request for a certain
  page, e.g. on demand
• Periodic customisation is triggered periodically