firefox 6 architectural enhancement (fully optimized favourites )
Post on 14-Feb-2016
30 Views
Preview:
DESCRIPTION
TRANSCRIPT
FIREFOX 6 ARCHITECTURAL ENHANCEMENT (FULLY OPTIMIZED FAVOURITES)By Fully Optimized eXperience (FOX)James Brereton - 06069736Katie Tanner - 06060472Gordon Krull - 06003108Rob Staalduinen - 06009513
PRESENTATION OVERVIEW Introduction Enhancement Implementations Stakeholders & NFRs SAAM Analysis Sequence Diagrams Testing Limitations Lessons Learned & Team Issues Conclusions
INTRODUCTION Everyone uses bookmarks for quicker access
to their favourite pages, but we felt that we could improve upon this
Therefore, our enhancement is a way to give users very fast access to their favourite pages
Will work in conjunction with the current system so that it will not hinder performance when loading other web pages but still allow for faster access
ENHANCEMENT The main goal of our enhancement is to allow
for instant access of a user’s favourite pages by ensuring that pre-rendered, cached versions of the page are continuously updated
Implementation of this enhancement requires the addition of modules and function calls in the UI, Gecko and the Data Persistence
The rationale behind this enhancements is the large amount of unused idle time that tends to exist in a user’s web-browsing session
The UI would see the addition of button next to the “awesome bar” presenting the user with a drop down of their favourite pages
ORIGINAL CONCEPTUAL ARCHITECTURE
IMPLEMENTATION 1 Proposed Design:
Add Favourites Data Component to Data Persistence which holds pre-parsed data, header files, and address of top favourites
Every X amount of time, Favourites Data makes a request to Necko for the header for one of its top favourites and checks for differences
If different, gets full website data and then sends it to Content Model and replaces header file in Favourites Data
After Content Model has manipulated data, the data is sent to Frame Constructor for final rendering before being send back to Favourites Data for storage
IMPLEMENTATION 1 CONCEPTUAL ARCHITECTURE
IMPLEMENTATION 2 Proposed Design:
Would also add Favourites Data component to Data Persistence, but only store parsed data and addresses
An Update Module would be added to Gecko, which would store header files and addresses
Update Module would poll Necko for updates to the favourite sites whenever Necko had idle time
As before, compares header files and retrieves data if they differ
Sends to Content Model for rendering, header files are stored in the module and rendered data gets sent to Favourites Data
IMPLEMENTATION 2 ARCHITECTURE
STAKEHOLDERS & NFRSStakeholders Non-Functional
RequirementsEnd Users •Performance
•Security•Availability•Integration
Developers •Scalability•Modifiability•Security•Availability•Integration
SAAM ANALYSIS: IMPLEMENTATION 1NFR Implementation 1Performance +Loading of favourite page is
faster than other approach-Could reduce overall browsing performance
Availability +Doesn’t affect the overall availability of Firefox
Modifiability +Single module that needs to be updated-Increased architectural complexity
Integration -Must modify functionality of Data Persistence subsystem
SAAM ANALYSIS: IMPLEMENTATION 2NFR Implementation 1Performance +No impact on browser
performance-Updating of favourite websites not consistent
Availability +Doesn’t affect the overall availability of Firefox
Modifiability +Limits dependencies between subsystems-Two modules to update rather than one
Integration +No change in overall functionality of existing Firefox subsystems
CHOSEN DESIGN Based on our SAAM Analysis, we have
decided to choose Implementation 2
Deciding factors: Elimination of impact on browser performance,
as this feature should never affect standard browsing
Fewer dependencies between subsystems eases modifiability and integration
SEQUENCE DIAGRAM: ADDING A NEW FAVOURITE PAGE
SEQUENCE DIAGRAM: LOADING A FAVOURITE PAGE
TESTING Subsytems the enhancement would interact
with that need to be tested include: User Interface Necko Data Persistence
Tests planned for each subsystem User Interface- Measure time required to render the
page, ensure it’s not hindering performance Necko- Ensure resource allocation is being handled
correctly and not interfering with the retrieval of non-favourite sites
Data Persistence- Make sure cached websites don’t inflate data persistence and hinder standard browsing
LIMITATIONS Limitations:
Impossible to determine the full impact on the system without actually having the time to implement the feature
We have no prior experience developing for a large-scale project such as Firefox
LESSONS LEARNED AND TEAM ISSUES Lessons Learned:
Knowledge of concrete architecture made it much easier to determine how our enhancement would affect each component of Firefox as well as how it would affect NFRs
Trade-offs between NFRs are unavoidable Team Issues:
Found it much easier to collaborate on Brain-Storming potential enhancements and implementation details compared to previous deliverable
CONCLUSIONS We chose to implement a ‘Top Favourites”
feature to Firefox which allows users to select approx. 5 pages to be continually updated in cache
Stakeholders: end users and developers Considered 2 alternatives, and based on a
SAAM analysis, chose one consisting of adding a Favourites Data component to Data Persistence and an Update Module to Gecko
Overall layered architecture is preserved; no significant changes to the design other than the addition of components
top related