CISC 322 - WordPress
CISC 322Assignment 3Social Media Hub FeatureThe KoalasAawista Chaudhry 18ac20 20129987Alexander Salgo 18ajbs 20138440Emily Kaczmarek 13ek38 10138915Matthew Eliot 12mne1 10100789Rita Alsattah 14ra6 10154610Scarlett Taviss 12st65 10092062
ABSTRACTAs a follow up to the previous two reports, this report provides a proposal for the implementationof a new social media hub feature for Google Chrome. This feature provides a set of dynamic iconsthat allow the user to view the number of unread notifications from each social media site on theirtoolbar. Two potential architectural implementations for this feature are proposed, and the two arecompared using the Software Architecture Analysis Method (SAAM). A single implementation isselected via this method.The impact of this feature on Chrome’s architecture and other Chrome features is examined.Control flow during specific tasks is illustrated using a sequence diagram. The risks and limitationsof the chosen implementation are examined in more detail, including its effect on concurrency.Several methods for testing the feature are also proposed. Lastly, this report examines the Chrometeams that would be best suited to implement this feature, and discusses potential issues that theseteams may face.This report was limited by several factors, including the similarity between multiple NFRs and theauthors’ inexperience with the code-level implementation of certain features. Despite this, thereport presents a comprehensive overview of the proposed feature, and provides enoughinformation that an experienced team could likely begin code-level development for it.1
Table Of ContentsABSTRACT . 11. Introduction & Overview . 32. Social Media Hub Feature . 43. Implementations . 53.1.3.2.Implementation 1 . 5Implementation 2 . 74. Software Architecture Analysis Method (SAAM) . 84.1.4.2.4.3.4.4.Scenarios . 8Stakeholders & Quality Attributes. 8Non-Functional Requirements. 9Comparison of Implementations . 95. Use Cases . 105.1.5.2.Use Case 1 . 11Use Case 2 . 116. Risks & Limitations of Approach . 127. Concurrency . 128. Testing Impact of Interactions . 139. Team Issues . 1310.Conclusion . 1411.Limitations & Lessons Learned. 1412.Glossary. 1413.References . 152
1. Introduction & OverviewThis report is a continuation from two previous reports titled “Conceptual Architecture of GoogleChrome” (found at a1-report.pdf) and“Concrete Architecture of Google Chrome” (found 1/a2-report.pdf). In the first report, theconceptual architecture of the Chrome browser was created by researching reference web browserarchitecture and sources that discussed the flow of data within Chrome. In the second report, theconcrete architecture of Chrome was derived from the actual source code, and was then comparedto the conceptual architecture created in the first report. In this report, the implementation of a newsocial media hub feature for Google Chrome is proposed through performing a SoftwareArchitecture Analysis Method (SAAM).The function of the social media hub feature is first introduced, and two proposed implementationsfor the feature are discussed. The impacted subsystems used in each implementation are described,and the differences in the two implementations are outlined. Some of the actual Chrome files arethat will need adjustments are presented.SAAM is performed to determine which of the two implementations performs better in terms ofchosen non-functional quality attributes. Five quality attributes are defined for the feature, and theaffected stakeholders are identified for each attribute. Both implementations are then analyzed forhow well they meet each quality attribute. From the result of this analysis, the final proposedimplementation is determined.Two use cases of the new feature are established, and sequence diagrams are shown to demonstratethe flow of information through the subsystems. The two use cases that are analyzed are: an autoupdate is performed for one social media site and the user clicks on one of their chosen socialmedia icons.The risks and limitations of the new feature are also outlined in the report. These include difficultyin updating the feature, the possibility of choking the network, high usage of resources, and thereduction of concurrency.Chrome implements concurrency through the use of multi-process architecture, and multi-threadexecution. The effects of the new feature on concurrency of the entire system are examined. Thenew feature has the potential of lowering the concurrency of the system due to the chosenimplementation. The concurrency of the feature itself is also evaluated.The new feature must be tested to ensure it performs the correct functions and does not affect anyof the other features of Chrome. Five tests are proposed; two relate to when the user receives anotification, two pertain to the user clicking on a social media icon, and one is associated with theuser changing their social media preferences.Team issues could arise due to the implementation of the new feature between the affectedsubsystem teams. The best team to implement the new feature is discussed, along with a secondary3
team to aide in the specific implementation details. Other teams affected in the implementation arealso mentioned in this section.The limitations of the project and lessons learned are the concluding section of the report. Thelimitations of the project focus on the difficulty of differentiating between certain similar nonfunctional quality attributes. The lessons learned discuss the discoveries made during the project,all of which are related to the process of implementing a new feature in Google Chrome.2. Social Media Hub FeatureThe purpose of this new feature for Chrome is to enhance the user experience by facilitating accessto the user’s notifications for the social media sites they visit most. Figure 1 is mock-up of theappearance of the social media icons on the User Interface. The user can select sites they wish tohave easy access to from a list of supported websites. The feature automatically checks fornotifications, updating number displayed on the icon dynamically. If a user wishes to visit the site,clicking on the icon will take them there. This opens a new tab to the homepage of that website.Figure 1: Mock up of the display for the social media hub feature.4
3. Implementations3.1. Implementation 1Figure 2: Implementation 1 for the proposed social media hub feature.Implementation 1 realizes the feature by making changes to the UI, Browser Engine, and Renderersubsystems. The resulting feature maintains the object-oriented architecture style of the Chromesystem, with two-way connections between each involved subsystem.This feature is implemented by taking advantage of “Headless Chrome”, a feature that allows thebrowser to partially render webpages without displaying them (Bidelman, 2017). Although theoverall architecture of Chrome is not changed, the internal architecture of the Renderer subsystemis altered for the feature-specific rendering process. Normal rendering processes utilize a mix ofpipe-and-filter and object-oriented architectures in order to facilitate the linear page-renderingprocedure along with the dynamic nature of webpages that allow user interaction. This feature willutilize a dedicated headless renderer, the conceptual architecture of this specialized process wouldonly be pipe-and-filter, with only HTML parser and DOM Tree filters.This information is extracted via headless rendering instead of an API call for sites that supportthat such as Facebook (Facebook for Developers, 2018, User Notifications). This is to avoidpermission-based issues that can be faced when dealing with these sites (Facebook for Developers,2018, Permissions Reference).5
Impacted SubsystemsThe UI is modified to display the notification icons and play sounds when a new notification isreceived. The icon is updated to display the number of notifications dynamically via thechrome/browserAction/setIcon function. It also handles the “button” functionality of the icon,allowing the user to click the icon to go to the relevant social media site. This is delegated to theUI because it already manages all icons that are displayed in the toolbar. Menu functionality foruser customization is also in the UI domain. The UI already handles all existing settingsfunctionality, so adding this requires minimal code. The primary folder of files that will be directlyimpacted within the Chrome code is src/ui/display where layouts and other information are foundwith regards to displays for different operating systems.The Browser engine handles the data persistence portion of the feature. Although user settings aremodified via the UI, the changes are saved in the Browser. This allows the Browser to initiate thenotification update process, because it contains the list of social media sites that the user issubscribed to. Lastly, the Browser handles intersystem communication between the UI, Renderer,and the Network, as it does for other Chrome functions. A self timer is set up to activate an autoupdate every ten seconds. Some of the folders affected by the new feature includesrc/chrome/browser/browser data and src/chrome/browser/password manager asbrowser data deal with cached website and password manager handles password storagewithin the Data Persistence subsystem of the Browser and authentications. The auto checks andnotification comparisons will need new files introduced to the Browser engine.The core subsystem is the Renderer subsystem. When the browser performs an automated checkfor a social media site, it fetches the HTML for that site using the Networking system, and thencalls a rendering process specifically dedicated to this feature. This headless rendering processextracts the DOM information from the webpage without using any GPU resources or CSS info(Google Open Source, 2018). The rendering process is modified to extract the notificationinformation from the site, and then to return the information to the Browser. Because this featurewill essentially be taking over an entire renderer, there is no specific folder(s) that will be affected.Many of the files involved in the rendering process will have to be adjusted for it to work asdesired.The Networking subsystem is not changed, however it is used to make web requests to socialmedia sites in order to check current notifications and allow authorization. Although the pages arenot fully rendered, the HTML for the full pages is loaded using standard network operations.6
3.2. Implementation 2Figure 3: Implementation 2 for the proposed social media hub feature.Implementation 2 shares several common elements of implementation 1, but leans significantly onplugin functionality instead of the browser engine or the renderer. It also maintains the objectoriented architecture of Chrome.Impacted SubsystemsThis implementation alters the User Interface in the same way that implementation 1 did. AlthoughPlugins could have implemented the icons, the UI was chosen to take advantage of additional iconflexibility that the UI subsystem allows for and ease of code reuse.The Browser engine is used only for inter-process communication, as all update requests and datapermanence is handled by the Plugins subsystem in this implementation. Similarly, Networking isnot changed in order to implement this feature, but it is used to fetch the HTML.The Plugins subsystem is the core subsystem of this implementation. In addition to datapersistence, this implementation involves adding an entire headless rendering system to Plugins.Rather than using an existing render process, this allows the page to be partially rendered to extractthe notification information from the HTML without the additional overhead associated with aregular renderer process, even a headless one. It would be optimized to perform only the renderfunctions that are necessary to extract notifications.7
4. Software Architecture Analysis Method (SAAM)The purpose of SAAM is to evaluate different quality attributes of software architectures by meansof scenarios. A set of use scenarios are proposed which examine the core functionality of thedesired feature. Several implementations can be compared using SAAM to produce a relativeranking for them. (Ionita, 2018) The following steps were taken to complete the SAAM analysis(Kazman, 1994):1. Characterize the functionality for the feature in scenarios.2. Map the functions onto the architecture’s structure.3. Choose a set of quality attributes with which to assess the architecture as well as list thestakeholders for each one.4. Choose a set of concrete tasks that test the desired quality attributes.5. Evaluate the degree to which each architecture provides support for each task.4.1. ScenariosFive scenarios were chosen to represent the functionality of the new implemented feature:1. Display notifications for multiple different social media accounts.2. Access websites every ten seconds to update notifications.3. User can personalize which social media accounts to display on the UI.4. Click icon to open relevant social media website homepage in new tab.5. Play sound when new notification is received is enabled by user.4.2. Stakeholders & Quality AttributesThe following quality attributes were considered to be the most important with regards to anevaluation of the two feature architectures: Maintainability, Evolvability, Testability,Performance, and Security. Three groups of people were determined as the possible stakeholdersfor these quality attributes, which include the Developing Team (Dev Team) of the feature, theUsers themselves, and the Chrome Team. Each quality attribute has its own set of stakeholdersfrom the list, which are presented below.MaintainabilityThe stakeholders for this quality attribute include the Dev Team and the Chrome Team. The DevTeam wants to ensure the feature is always up and running without interfering with the user. TheChrome Team wants to ensure the feature isn’t affecting other parts of the browser.EvolvabilityThe Dev Team is the only stakeholder for this quality attribute because they would be responsiblefor updating the feature as it evolves.8
TestabilityThe Dev Team is the only stakeholder for testability. This team wants to be able to easily test thecurrent version of the feature as well as updated versions in the future and any added elements ofthe feature as is evolves.PerformanceThe stakeholders for performance include the Dev Team and the Users. The Dev Team want thefeature to provide the best performance possible to the user.SecurityAll three groups are concerned about the security of the feature. The Dev Team wants to ensurethe security of the browser is not affected by the new feature. The Chrome Team cares aboutmaintaining the security of the browser they have already designed. The Users don’t want to worryabout the security of their device or personal information when the feature is implemented.4.3. Non-Functional RequirementsMaintainability: “99% of updates can be performed without any interruption to user experience.”Evolvability: “New information can be interpreted and displayed from a supported website by ajunior developer.”Testability: “Tests run when opening supported social media sites do not result in an increase inpage load time of more than 50ms.”Performance: “95% of newly received notifications result in an icon update within 10 seconds.”Security: “No information about the partially rendered social media sites is unsecured duringnotification check portion.”4.4. Comparison of ImplementationsOnce the non-functional requirements were created, some of the key advantages and disadvantagesof the models, based on the previously mentioned criteria was brought to light (Table 1). In termsof the maintainability of the system, Implementation 2 outperformed implementation 1. In theformer, the code for the implementation is contained within one specific subsystem, designed anddedicated to the implementation only – the plugin subsystem. Here, the code is easy to locate, sinceit only belongs to the various parts of the implementation, and thus has reduced coupling with theother subsystems of Chrome, allowing for an easier update of the system. On the other hand, thecode for Implementation 1 is dispersed throughout the various subsystems of Chrome itself. Basedon the functionality that is required, the code either exists in the User Interface, Browsing orRendering subsystem. Based on the high coupling between the subsystems, changing the code inone results, and sometimes requires the change in another.Then, Implementation 1 had a better performed better in comparison to Implementation 1 in terms9
of evolvability, and testability. Given that the code for Implementation 1 is dispersed throughoutthe various subsystem of Chrome, this opens the possibility of code reuse. There may be otherimplementations and features that exist already in Chrome that the new implementation can takeadvantage of, in terms of updating or evolving their own system. This can be made easy if there isalready a code that provides an example on how this is implemented, making it easier for the Devteam to reuse this code. This become a lot harder for the Plugin subsystem in Implementation 2,where the team would have to explore the various aspects of the code in all the subsystems to beable to reuse it. Furthermore, since in Implementation 1 there is the ability of the process to reuserenderer processes for page loading, sending notification information, etc. However,Implementation 2 mandates that the page is both rendered, and partially rendered when testingoccurs. In terms of performance, there is only the slight incurring of overhead in Implementation1 with the added partial rendering, which 2 does not have. However, last but most importantly, thesecurity of the system in Implementation 2 which has pages rendered in a non-sandboxedenvironment breaches the confidentiality of customer information, and results in a failing grade tothe Implementation. On the contrary, in Implementation 1, there is never any sensitive informationleaving the sandboxed environment of the, and only the notification information is sent out. Sincethe information never risks explore in this implementation, this was the one chosen to proceedforward with. Given the huge breech caused by implementation 2, it was not further explored norrefined in terms of the implementation.Table 1: Evaluation of the two proposed implementations for the feature.QAImplementation 1Implementation 2MaintainabilityCUpdate difficult, codedistributed within subsystemsAUpdate easy, most codewithin Plugin, less couplingwith ChromeEvolvabilityB Existing rendering system easier to interpret/renderCPartial rendering subsystem may require significant changesTestabilityAReuse renderer processes forpage loading, sendingnotification info, etc.BPage rendered and partiallyrendered when testing occursPerformanceB Additional renderer process: overhead (slightly)ANo major issues expectedARenderer sandboxed, onlynotification info sent outsideFPages rendered in nonsandboxed environment major security riskSecurity10
5. Use Cases5.1. Use Case 1Figure 4: Sequence diagram for the Browser auto updating the notifications.The first use case in Figure 4 depicts the auto update for the notifications. AutoCheck() is triggeredby a self-timer located in the Browser engine. The Browser then calls the Networking subsystemto retrieve the code for the specified social media site, which is then returned to the Browser. Thisinformation is then sent to the Renderer to parse the code and extract the number of notificationsfor this site, which is returned to the Browser. This value is compared with the current value beingdisplayed and updated if necessary, sending the display to the UI as appropriate, where it isdisplayed and if enabled, will make a sound.5.2.Use Case 2Figure 5: Sequence diagram for the user clicking on one of the social media icons.11
Figure 5 depicts the second use case; a user clicking on one of the social media icons on the UI,which will open a new tab to the homepage of that webpage. It is assumed that the user’scredentials for logging into the site have already been stored within the Browser engine. Upon theuser clicking the icon, a new tab will be opened; the Browser will call to the Networkingsubsystem, sending the authorization information for the requested webpage. The code for thatsocial media site will be returned to the Browser where it is then sent to the Rendering engine tocreate a bitmap. The bitmap is returned the Browser where the auto test is triggered to ensure thenumber being displayed on the UI matches the actual number of notifications on the site. It is thensent to the UI to be displayed for the user.6. Risks & Limitations of ApproachDespite this implementation being determined as the most effective way to implement the socialmedia hub feature, there are still risks and limitations associated with it. Firstly, thisimplementation is difficult to update. Plugins can be updated easily and automatically, juxtaposethe renderer must be updated within larger system updates. Regular updates to the Renderersubsystem could also interfere with the implementation of the feature.Each social media account being managed by the social media hub must make requests to thenetwork in order to check for new notifications. If many accounts are being managed and all aremaking requests to the network, the network could easily become choked. Therefore, the featuremust deploy a strategy to limit the risk of choking the network. Staggering the network requestsfrom the different social media platforms easily does this. Furthermore, if the social media hub ismanaging a large number of platforms, the regularity of checking for new notifications may bereduced to ensure adequate staggering.Another negative attribute of this implementation is an increase in resources used by Chrome. Theconstant loading and rendering of pages from the network uses both Random Access Memory(RAM) and bandwidth. To reduce the impact of this, pages are only partially rendered to retrievethe minimum amount of information necessary.Another risk associated with this implementation is a reduction in concurrency. This is a result ofa renderer being used for the social media hub feature instead of rendering webpages. This isfurther discussed in Section 7.7. ConcurrencyConcurrency is the ability for components within a program to be executed in parallel and withoutaffecting each other. As discussed in previous reports, Chrome utilizes its multi-processarchitecture to run many renderers in parallel. This gives Chrome high concurrency. However, thisimplementation removes one renderer to be used specifically for the social media hub. Therefore,since less renderers and being used for webpages, the system has lower concurrency. If Chromehas numerous renderers this reduction may be insignificant. However, Chrome analyses thecomputers resource availability to determine how many renderers it can have. As a result, thisimplementation will have a larger negative affect on smaller machines, since they have fewerrenderers.12
Within a process, Chrome uses multiple threads to increase concurrency. This causes manypositive attributes for the social media hub. Specifically, testing can be done without negativelyaffecting the performance of the system. For example, when a social media site is opened a testcan be run to ensure the number of notifications matches what is being shown in the social mediahub. Using multiple threads also allows for concurrently checking the notifications of multiplesocial media sites. For instance, while a network request is being made for one site, another couldbe rendering.8. Testing Impact of InteractionsOnce the feature has been implemented, it will be tested to ensure it performs the proper functionsand does not affect any of the other features of Chrome. To test the feature, a tester will choosethe social media sites they wish to receive notifications from and will log into those sites. Thefollowing five tests were chosen at minimum to examine the performance and effects of the feature.Two tests can be done when a notification is received. First, when a notification is received, theicon on the screen should update without affecting the current webpage. The current webpageshould not freeze and the data on the page should not be altered. The second test for when a userreceives a notification is that only the correct social media icon is updated. For example, if a userreceives a new message on Facebook, the Facebook icon should display a new notification, butother social media icons, such as Twitter or Instagram, should not change.There are also two tests that can be done when a user clicks on one of the social media icons. First,when a user clicks on an icon, the social media site of that icon should open in a new tab withoutcausing the Chrome browser to crash or any other problems to arise. The second test for clickingon an icon is that the number of notifications that are shown on the icon in the toolbar should matchthe number of new notifications present when the webpage is opened. If the Facebook icon showsthree new notifications, there should be three notifications for the user to see on the actualFacebook homepage when it is opened.The final test performed will ensure that when a user changes their social media preferences, thechanges become visible in the Chrome toolbar, and do not interfere with other icons present.9. Team IssuesFigure 6: The concretearchitecture of Chrome'sRenderer subsystem. Greenarrows represent divergencesfromtheconceptualarchitecture. For clarity,external dependencies are notshown.13
10. ConclusionThe motivation behind our enhancement feature idea for a social media notifications hub is anenhanced user experience. The purpose of which is to provide users with easier and quicker accessto their notifications. We began by creating two possible implementations for our feature and thenperforming a SAAM analysis on each to determine what our final approach will be. After analyzingboth our models, we were able to determine our final approach by weighing their advantages anddisadvantages. In addition, based on the implementation we chose to go forward with, we alsodetermined that the impacted subsystems would be the UI, Browser, and Renderer. Further stepsof our project included coming up with two use cases regarding the feature that would betterdescribe the functionality of it in more depth.11. Limitations & Lessons LearnedUnlike past assignments, this assignment relied on our previous knowledge and understanding ofGoogle Chrome’s conceptual and concrete architecture in order for us to come up with an originalfeature idea and analyze it thoroughly.The research conducted in this assignment was minimal in comparison to other assignments dueto the fact that the team was to come up with their own design and implementation based on thearchitectures previously presented in past assignments. However, most of the research conductedfocused on how to perform a SAAM analysis on
4. Software Architecture Analysis Method (SAAM) The purpose of SAAM is to evaluate different quality attributes of software architectures by means of scenarios. A set of use scenarios are proposed which examine the core functionality of the desired feature. Several implementations can be compared using SAAM to produce a relative
Computer Architecture 7 Chapter-1 Anatomy of a Computer Q.1. What is CISC Microprocessor? Ans.: CISC stands for complex instruction set computer. It was developed by Intel. CISC is a type of design for the computers. CISC based computer will have shorter programs w
Microcontrollers with small instruction set are called reduced instruction set computer (RISC) machines and those with complex instruction set are called complex instruction set computer (CISC). Intel 8051 is an example of CISC machine whereas microchip PIC 18F87X is an example of RISC machine. RISC CISC
the ARM ISA (a RISC ISA) has dominated mobile and low-power embedded computing domains and the x86 ISA (a CISC ISA) has dominated desktops and servers. Recent trends raise the question of the role of the ISA and make a case for revisiting the RISC vs. CISC question. First, the computing landscape has quite radically changed from when the
1.1.3 WordPress.com dan WordPress.org WordPress menyediakan dua alamat yang berbeda, yaitu WordPress.com dan WordPress.org. WordPress.com merupakan situs layanan blog yang menggunakan mesin WordPress, didirikan oleh perusahaan Automattic. Dengan mendaftar pada situs WordPress.com, pengguna tidak perlu melakukan instalasi atau
x Introduction to RISC and CISC: LECTURE 15 RISC (Reduced Instruction Set Computer) RISC stands for Reduced Instruction Set Computer. To execute each instruction, if there is separate electronic circuitry in the control unit, which produces all the necessary signals, this approach of the
Design considerations (II) Compiler design is influenced by architectures CISC vs. RISC CISC designed for days when programmers wrote in assembly For a compiler to take advantage of string manipulation instructions, it must be able to recognize them RISC has
AVR PIC Intel 8051 Motorola HC11 Architecture Harvard Harvard Harvard Von Neumann Instruction Set RISC RISC CISC CISC Avg. Clock Cycles 1 4 24 16 per Instruction Std. Clock Speeds 8,16Mhz 10,20,40Mhz 12Mhz 8Mhz MIPS 8,16 2.5,5,10 0.5 0.5 Memory ash ash,OTP ash,OTP ash,OTP Technologies EEPROM,ROMless EEPROM,ROMless Typ. Program ROM 16KB 4KB 4KB 8KB
A ARM B x86 C MIPS D VLIW E CISC 2. Was the full x86 instruction set we have today carefully planned out? Letter Answer A Yes B I wish I could unlearn everything I know about x86. I feel unclean. C Are you kidding? I’ve never seen a more poorly planned ISA! D *sob* E B, C, or D 3.
