CentralCampus. Jeremiah Evans David Loutsch Kristen Muehlenthaler Micah Beeman Adam Lemker. Manimaran Govindarasu

Transcription

1 CentralCampus Team: Client: Advisor: Jeremiah Evans David Loutsch Kristen Muehlenthaler Micah Beeman Adam Lemker Google Manimaran Govindarasu

2 Version Editor Date Peer Reviewers Notes 0.1 Jeremiah Evans Nov 4, 2011 Draft Jeremiah Evans Dec 2, 2011 Revision for presentation ii

3 Table of Contents 1 Introduction! Executive Summary! Acknowledgment! Problem Statement! Term, Acronym, and Abbreviation Definitions! Operating Environment! Intended Users and Intended Uses! Assumptions and Limitations! Expected End Product and Other Deliverables! Approach and Product Design Results! Approach Used! Design Objectives! Functional Requirements! Non-Functional Requirements! Design Constraint! Testing Approach Considerations! Recommendations Regarding Project Continuation or Modification! Detailed Design! Structured Search Tool! Data Web Service & Database! Web UI!... 9 iii

4 3 Closure Material! Project Team Information! Client! Advisor! Team Members! Closing Summary! iv

5 1 Introduction 1.1 Executive Summary This document defines the scope and implementation plan of project Central Campus. Concept diagrams and Gantt charts have been included to aid in the visualization of this project, and initial milestones and goals have been included, as well as future directions. 1.2 Acknowledgment The team members of project CentralCampus would like to thank Muthu Muthusrinivasan of Google for the opportunity to work on this project and for assistance in its implementation. In addition, we are grateful to Professor Manimaran Govindarasu for his support, advice, and assistance throughout this project. Further, thank you to Travis Ballstadt in the relations department of Iowa State University for recommendations and ideas to make this product work. 1.3 Problem Statement There is much information currently available that is of interest to current students regarding campus life, but it is widely dispersed and can be inconvenient to access There is no centralized source for the required data There is no existing site to comprehensively gather and provide students thoughts about campus life (classes, clubs, etc.) 1.4 Term, Acronym, and Abbreviation Definitions 1.5 Operating Environment This system will need to be hosted, physically or virtually. The main requirements of the host platform are that it can run the code of every module hosted on it, and that it is able to make the various web services publicly available. It will need to be secure so that private data will not be compromised, and it will need to have a static IP address or DNS to ensure consistent access 1

6 In addition, the hosting server will need to interact with a large numbers of concurrent users, and handle content updates from both the web crawler and the web UI. Ideally, this product will be very modular and cross platform, so that different components can be hosted on different systems, allowing for components to receive more targeted computational resources. 1.6 Intended Users and Intended Uses Currently enrolled students at Iowa State University are the primary intended users of this product. This product will need site administrators to handle upkeep and abuse reports, however the primary use is the communication of crowd-sourced data. CentralCampus will be a tool to connect students taking the same classes or involved in the same student organizations, providing them with a focused means of communication. In addition, professors will be identified as resources for classes they are indexed to by our web crawling. Professors will be able to specify students as current members of their class, and to create private content specific to the class, abiding by rules in the Federal Educational Right to Privacy Act. 1.7 Assumptions and Limitations Assumptions All publicly accessible university data will be available at all times Students want a central source of information for all things related to campus life Project will be driven by user feedback Limitations Required resources may not be available (servers, hard drives, etc.) Limited product exposure Competing social networks Senior Design timelines and requirements Number of institutions is too great for immediate comprehensive support 2

7 1.8 Expected End Product and Other Deliverables Web Crawler Database Web Services (Interface Layer) Web UI Our product is composed of a database model, web services controller, and a Web UI view, following the MVC design pattern. The database will be populated by the web crawler and user input from the Web UI. All interactions between the various tiers will be standardized and document to allow for modularity in the addition of new features and tools. 2 Approach and Product Design Results 2.1 Approach Used Design Objectives Functional Requirements 1. System shall autonomously traverse publicly available information regarding the university 2. System shall parse information from sites traversed and store the data for later retrieval 3. System shall allow users to view and edit their personal information 4. System shall allow users to view and edit information pertaining to Groups with which they re associated 5. System shall allow for a moderation system to preserve integrity of data 6. System shall expose functionality through web services 7. System shall provide a list of classes being offered during the current or upcoming semester 8. System shall index professors with the classes they re currently teaching 9. System shall provide professors with controls to mark students as being members of the current semester. 3

8 10.System shall provide professors with controls to create private threads on forums which are specific to their authenticated class members. 11.System shall provide users with an interface to select the class in which they re enrolled 12.System shall allow users to contribute to or initiate discussion threads on pages with which they re associated 13.System shall allow users to provide feedback to site admins 14.System shall allow users to search site Non-Functional Requirements 15.System shall return requested information within 3 seconds 16.System shall support up to 25,000 concurrent users 17.System shall be modular in construction to allow replacement of components to accommodate new requirements without a complete overhaul of the system 18.System shall be completed by end of Spring semester, May Design Constraint University website may alter layout or be unavailable Product may not gain enough exposure to thoroughly populate groups Product must handle many simultaneous user interactions Networking security must be integrated Must consider using a Virtual Private Server Must consider purchasing domain names and site certificates Testing Approach Considerations Large server load - will need to simulate 1000 s of simultaneous users. Consistent UI - UI testing needs to verify that the flow is smooth, all use cases behave as expected, with no breaks in the flow. Structured web crawler - are we getting accurate data? Data collection and merging - are we handling conflicting data correctly? Ranking - are we representing post and user reputation correctly, accurately, and fairly? 4

9 Private zone access - are users restricted to editing their own profiles? Are users restricted from seeing private info in other users profiles? Are users restricted/ allowed to view private content as matches their authorization? Professor indexing - are professors accurately matched with their classes? Recommendations Regarding Project Continuation or Modification Student Groups, indexing officers. Homework/assignment posting for professors. Homework/assignment collection for students. Grading & Grade Reports GPA Calculator (tying into class history) Full hybrid reputation model which indexes reputations by class, department, college, and role. Ability to find friends based on contact lists, Facebook account, or Gmail/Google+ University, College, and Department discussion/rating pages Integration with TAs. Gather anonymous grades received data to get class/professor grade statistics Tie in with class planner, major/minor flowcharts, other class planning models. Mobile apps (iphone/ipad/android/blackberry/windows Phone). Mobile site (m.centralcamp.us). Expand to multiple universities. Research Groups. Campus Housing. 5

10 2.2 Detailed Design Figure Detailed Flow Design 6

11 2.2.1 Structured Search Tool The structured search tool looks to a configuration file which details things like targets, frequencies, and behaviors. Based on this, the tool navigates to targets, and gathers the page HTML. Based on config info regarding the target, the scraped HTML is passed to an XSLT style sheet which converts the HTML to its component data which can be understood by the data web service, and is submitted Figure Structured Search Detail 7

12 2.2.2 Data Web Service & Database The data submission/retrieval web service manages the data, handling all requests for data, or to submit data, as well as handling conflicts. In addition, it queries the authentication server to verify that the user requesting data is authorized to access it, so that data is only retrieved given valid user authentication. Figure Database WebService Diagram 8

13 Figure Database Diagram Web UI The product will be exposed to customers through a web based user interface. All functionality will be accomplished through this interface, including signing on, editing personal profile information, subscribing to classes, posting to comment boards, et cetera. First iteration pages will include profile and class pages. Class pages and profile pages of a user associated as a TA or professor of a class will include a rating system and feedback board. 9

14 3 Closure Material 3.1 Project Team Information Client Google Muthu Muthusrinivasan Advisor Manimaran Govindarasu 3227 Coover Ames, IA (Office) Team Members Jeremiah Evans Software Engineering (515) David Loutsch Software Engineering (712) Kristen Muehlenthaler (515) Computer Engineering 10

15 Micah Beeman Computer Engineering (515) Adam Lemker Software Engineering (641) Closing Summary This project plan demonstrates our proposal for both the CentralCampus social networking product, and the implementation thereof. This project can be broken down into multiple iterations, with each iteration adding more features, maintaining the overall integrity of the site. The project has been broken down into four distinct modules to improve compatibility with future improvements. The implementation will utilize free tools and languages, but we will require dedicated server systems to handle the hosting of this site, especially considering the potential user scope of any social networking site. 11