Modeling Safe Interface Interactions in Web Applications (ER´09)

886 views

Published on

Moving the Web (and the supporting browsers) from the browsing paradigm based on Pages, with related Back and Forward actions, to a full-fledged interactive application paradigm, based on the concept of State, that features Undo and Redo capabilities, and transactional properties

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
886
On SlideShare
0
From Embeds
0
Number of Embeds
47
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • To present you a method that helps the designer during the specification of the software system by automatically generating a set of operations for a given class diagram.
  • Simple is more or less as public
  • Simple is more or less as public
  • Simple is more or less as public
  • Simple is more or less as public
  • In particular we will represent rules as pre/postcondition contracts
    E.g. once expressed in OCL we can apply code-generation techniques to the rules
  • Simple is more or less as public
  • Simple is more or less as public
  • Transactions not exaclty in the database sense
  • Simple is more or less as public
  • Basically, we create a class to store the information of each element
  • Strong executability: r is strongly executable if, for any legal instantiation that satisfies the pre-condition, there is another legal instantiation that satisfies the post-condition.
     I :  I’ : (INV[I] and PREr[I])  (INV[I’] and POSTr[I, I’])
  • Simple is more or less as public
  • Simple is more or less as public
  • Simple is more or less as public
  • Simple is more or less as public
  • Indeed, once GT rules are expressed in OCL, we can benefit from all tools designed for managing OCL expressions when dealing with the GT rules.
    VAlidation: here an initial host graph is passed as an additional parameter to the verification tool)
  • Modeling Safe Interface Interactions in Web Applications (ER´09)

    1. 1. Modelling Safe Interface Interactions in Web Applications Marco Brambilla1 , Jordi Cabot2 and Michael Grossniklaus1 Politecnico di Milano1 Open University of Catalonia2
    2. 2. Index  Introduction  Goal  Modeling Safe Interfaces  Tracking user-interaction  Methodology  Implementation  Related work  Conclusions
    3. 3. 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
    4. 4. Examples: GMail and Amazon bug
    5. 5. … 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
    6. 6. Index  Introduction  Goal  Modeling Safe Interfaces  Tracking user-interaction  Methodology  Implementation  Related work  Conclusions
    7. 7. 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
    8. 8. Index  Introduction  Goal  Modeling Safe Interfaces  Tracking user-interaction  Methodology  Implementation  Related work  Conclusions
    9. 9. 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
    10. 10. 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 ButtonClick ListSelect ... ExceptionState Page -id -url State -name -id Transaction Application -id -name InitialState FinalState Contains 1..* 1 -outgoing 0..* -target 1 -source 1 -incoming 0..* TriggeredBy 1..*1 Effect {ordered}0..* 1 1..*1 On 1 0..* 1..* 0..1 Includes 1..* 1 Has 1..*1 0..* 1 / LinksTo * *
    11. 11. 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
    12. 12. 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
    13. 13. Index  Introduction  Goal  Modeling Safe Interfaces  Tracking user-interaction  Methodology  Implementation  Related work  Conclusions
    14. 14. 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
    15. 15. 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 -timestamp Transaction 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 CurrentVisit 1 0..1 TriggeredBy 1..* 1 1 1..* ExecutedBy 1 0..* 1 0..* 1 1 0..* 1 1..* 1 1 0..* -from 1 -next 1 -to 1 -previous 1 1 PartOf 0..1 1..*
    16. 16. 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
    17. 17. [ ] 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:
    18. 18. Index  Introduction  Goal  Modeling Safe Interfaces  Tracking user-interaction  Methodology  Implementation  Related work  Conclusions
    19. 19. 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
    20. 20. Methodology: Integration with existing methods
    21. 21. Index  Introduction  Goal  Modeling Safe Interfaces  Tracking user-interaction  Methodology  Implementation  Related work  Conclusions
    22. 22. Implementation  Screenshot?
    23. 23. Index  Introduction  Goal  Modeling Safe Interfaces  Tracking user-interaction  Methodology  Implementation  Related work  Conclusions
    24. 24. 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
    25. 25. Index  Introduction  Goal  Modeling Safe Interfaces  Tracking user-interaction  Methodology  Implementation  Related work  Conclusions
    26. 26. 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

    ×