View
901
Download
0
Category
Tags:
Preview:
DESCRIPTION
Presentation of the paper "Modelling Safe Interface Interactionsin Web Applications" by Marco Brambilla, Jordi Cabot, Michael Grossniklaus at ER- Conceptual Modeling 2009. Presentation given by Jordi Cabot in Gramado, Brasil, 2009.
Citation preview
Modelling Safe Interface Interactionsin Web Applications
Marco Brambilla1, Jordi Cabot2 and Michael Grossniklaus1
Politecnico di Milano1
Open University of Catalonia2
Index
Introduction
Goal
Modeling Safe Interfaces
Tracking user-interaction
Methodology
Implementation
Related work
Conclusions
Introduction
Web has evolved from navigation of simple hypertext documents to a a platform for complex business applications
Now, complex events and business logic + RIAs and AJAX
Original interaction paradigm (static content pages + hyperlinks) is not valid anymore
Browsers themselves are inadequate for the current web complexity Back and forward button
The same application behaves differently depending on the
browser and settings defined
Examples: GMail and Amazon bug
… but many more
Linkedin, iGoogle, survey monkey, gap, hostel world, lastminute,….
Solutions are site-specific (e.g. GMail moving from using a single URL for the application to a different URL for each message; blocking of browser buttons)
But still, sites are unable to – Preserve the complete navigation history– Offer rollback/compensation of side effects when backward navigation– Fine-grained back and forward management
Index
Introduction
Goal
Modeling Safe Interfaces
Tracking user-interaction
Methodology
Implementation
Related work
Conclusions
Goal
Proposing a method for modeling and running web applications with a safe interface interaction behaviour
1. Users can freely navigate through Web applications
2. Tool developers do not need to implement this safe behaviour from scratch
3. Our method is complementary to existing web modeling approaches
1. Moving from a browsing paradigm based on Pages with related Back and
Forward buttons to a full-fledged interactive paradigm based on States
2. Offering design-time and run-time support to create web applications
under this new paradigm
Benefits
Index
Introduction
Goal
Modeling Safe Interfaces
Tracking user-interaction
Methodology
Implementation
Related work
Conclusions
Modeling safe interfaces
MOF-compliant metamodel based on the state machines sublanguage of the UML
Adapted to the web application domain by means of adding web concepts like Page and GraphicalElement
Concrete syntax for the language not yet formally defined
Graph Transformation by Example: Metamodel
PredefinedActionType
GraphicalElement
-id-name-type
ActionParameters
-name-type
Action
-id-type-do_specification-undo_specification
PageParameters
-type-name
TriggerEvent
-type : EventType
Transition
-id
<<enumeration>>EventType
ButtonClickListSelect...
ExceptionState
Page
-id-url
State
-name-id
Transaction
Application
-id-name
InitialState FinalState
Contains
1..*
1
-outgoing0..*
-target
1
-source
1-incoming
0..* TriggeredBy1..*1
Effect
{ordered}0..*
1
1..*1
On
1
0..*1..*
0..1
Includes1..*
1
Has1..*1
0..* 1
/ LinksTo
**
Modeling safe interfaces – Example (1)
Show the internal workflow of the Mail page It is now clear when to go back to the previous page and when to stay
Modeling safe interfaces – Example (2)
The transaction (dashed box) clarifies that an undo in the Delete message state should undo the delete and move the user back to the show inbox page
Index
Introduction
Goal
Modeling Safe Interfaces
Tracking user-interaction
Methodology
Implementation
Related work
Conclusions
Run-time support
We need to insure that the web application behaves as expected
This requires to keep the execution trace of all events, visited states, accessed pages and executed actions executed so far
Mandatory to be able to retrieve previous states of the application when moving back and forth (or undoing Txs)
We provide:– The data structures to store this information– An API to manipulate and query these data structures
The API facilitates the development of web applications
Metamodel for the run-time support
ActionExecutionParam
-value
TransactionExecution
-startTime-endTime
ApplicationExecution
-id-startTime-endTime
TransitionExecution
-timestamp GraphicalElement
ActionParameters
PageParameters
ActionExecution
-timestamp
EventExecution
-timestamp
TriggerEvent
PageAccess
-timestampTransaction
InputParam
-value
Application
Transition
Page
User
-id-name
Visit
-id-timestamp
Action
State
0..*
1
10..*
-value
ElementState
ElementState
0..*
1
0..*1
1..*1
CurrentVisit1
0..1
TriggeredBy
1..*
1
1
1..*ExecutedBy
1 0..*
1 0..*
1
10..*
1
1..*
1
1
0..*
-from1
-next
1
-to
1
-previous
1
1
PartOf0..1
1..*
Some API functions
State::getNextState(Event e): State informs about the next state to go based on the current one and the given event
Visit::getNext(): Visit queries next visit Visit::getPrevious(): Visit queries previous visit ApplicationExecution::do (EventExec e, Parameter[] p): Visit moves to
next visit ApplicationExecution::redo():Visit moves to the (previously visited) next
visit ApplicationExecution::undo():Visit moves to previous visit reversing all
executed actions Visit::clone():Visit creates a clone of the visit ActionExecution::do (ActionExecutionParam[] params) executes the
action ActionExecution::undo (ActionExecutionParam[] params) undoes the
effect of the action TransitionExecution::undo() undoes all actions associated to the transition TransactionExecution::rollback() rollbacks the transaction
Let’s see now how with our API we can force a correct behaviour
of the “Back” browser action
[ ]
loop
in : TransitionExecution : ApplicationExecution : ActionExecutionprevious : Visitcurrent : Visit
cloned : Visit
: User
undo()10:
undo()2:
cloned12:
getCurrentVisit()3:
getPrevious()4:
assignNextVisit(current)7:
clone()5:
getIncomingTransition()8:
undo()9:
getPageAccessAndParams()11:
6:
Back()1:
Index
Introduction
Goal
Modeling Safe Interfaces
Tracking user-interaction
Methodology
Implementation
Related work
Conclusions
Methodology
Two ways of using the method
Standalone approach: More oriented to traditional developers that may use the API for
getting immediate benefits during the development The most they are willing to do is to adopt a simple notation to
describe the basic structure of the application
Integration with existing Web Development Methods: Decide whether to create a new view or blend with existing views
(e.g. navigation model) Add new primitives and resolve semantic conflicts
Methodology: Integration with existing methods
Index
Introduction
Goal
Modeling Safe Interfaces
Tracking user-interaction
Methodology
Implementation
Related work
Conclusions
Implementation
Screenshot?
Index
Introduction
Goal
Modeling Safe Interfaces
Tracking user-interaction
Methodology
Implementation
Related work
Conclusions
Related work
Several other approaches have proposed using state machines to specify the interface of web applications.
Recent extensions to existing Web Eng. Methods have covered RIAs
Specific solutions to the problem of using the back button in a browser have been proposed as well
We propose A generic method For the fine-grained definition of web interfaces With predefined support for their implementation With undo/redo support and taking into account the interaction
with the browser
Index
Introduction
Goal
Modeling Safe Interfaces
Tracking user-interaction
Methodology
Implementation
Related work
Conclusions
Conclusions and further work
We have presented a new method for the modeling and implementation of safe interface interactions in web applications
Based on state semantics and with transactional and full-fledged undo/redo capabilities to improve the browsing user experience
As future work we would like to test the methodological guidelines by – extending the code generator of WebML to support our new features and validate
the scalability and completeness of our primitives– Developing a simple code generator for the standalone approach that transforms
the models to skeletons of JEE code that invoke our API
Recommended