Software Design Description

Transcription

1 CSL740 Software Engineering Course, IIT Delhi Software Design Description Submitted By Abhishek Srivastava (2011EEY7511) Anil Kumar (2009CS10180) Jagjeet Singh Dhaliwal (2008CS50212) Ierum Shanaya (2010SIY7570) Supervised By Dr. S. C. Gupta National Informatics Centre India This document gives a detailed Design Description for a new academic portal for IIT Delhi. The document follows the IEEE 1016 format

2 Table of Contents 1. Introduction Purpose Scope Definitions, Acronyms and Abbreviations References Overview System Architecture Description Overview of Modules/Components Brief Overview of Modules Database File Sharing System Notification System Discussion forum Interface Module Module Dependencies Detailed Description of Components Database Data Interface Notification Users Groups Content Sharing Module Content Upload (Sub-Module) Content Download (Sub-Module) Discussion Forum Assignment Module Design Decisions Use Of PHP Use Of MySQL Use Of Apache User Interface P a g e

3 5.1 Login Screen Main Screen Time Table View Assignment View Discussion Thread Notification View Seminar Info Group Info Blog View Online Survey Search Old Paper Content Sharing P a g e

4 1. Introduction 1.1 Purpose The purpose of this document is to propose the Detailed Software Design of the Academic portal that we are going to build (STUB). 1.2 Scope This software system will be an online academic portal for any university wishing to manage their academic needs online. More specifically to design and develop a simple and intuitive system which shall cater the academic needs of any institute. The system shall provide features to the user of an educational institute to be part of different types of groups, share data and documents amongst different users, have discussion threads, instant notifications via /message, assignment submissions, blogs, share old papers, availability of books and other useful stuff (buy/sell), online survey etc 1.3 Definitions, Acronyms and Abbreviations Academic Portal Academic Portal is software meant to help facilitate electronic classroom management and provide for electronic grading, assignment submission, discussion, and other learning tools Course Administrator Course administrator is a user who can be a professor or system administrator and who has the ability to manage courses and course pages Academic Groups An academic group is a set of users which can belong to the same course, same department, and same year System System refers to the existing academic portal or a new academic portal Acronyms and abbreviations TYPE DB HTTP HTML LDAP STUB SQL DESCRIPTION Database Hyper Text Transfer Protocol Hyper Text Markup Language Lightweight Directory Access Protocol Student University Board Structured Query Language 4 P a g e

5 1.4 References 1. Moodle Requirements Brainstorming.pdf 2. University of Melbourne Student Portal (Getting Started Guide) 3. Stakeholder Requirements for Institutional Portals by Liz Pearce, Leona Carpenter, Ruth Martin 4. Detlor, B. (2000). "The corporate portal as information infrastructure: Towards a framework for portal design", International Journal of Information Management, 20(2) IEEE 1016 Format for Design Description Format 1.5 Overview This is a working document and, as such, is subject to change. In its initial form, it is incomplete by definition, and will require continuing refinement. Requirements may be modified and additional requirements may be added as development progresses and the system description becomes more refined. This information will serve as a framework for the current definition and future evolution of the University Academic Portal. 2. System Architecture Description 2.1 Overview of Modules/Components (STUB) system follows a n-tier design. Our system is designed with extensibility and Scalability in mind. We are taking great care in designing a framework which can be updated easily. Many of the anticipated changes to our system in future phases will only require adding few functions in the modules which we will be intuitively clear. There are four basic, logical components of the system: the Database Engine, the File Sharing System, Controller, the notification system, discussion forum system, the User Interface modules. 1. Database Engine 1..1 Existing open source software: MySQL Hosts the backend database which is used for storing information about users and content 2. Content Sharing System 2..1 Stores the Content uploaded by the users Content retrieved from the storage for users with permission to see the content. 3. The notification system 3..1 Provide notifications for users who want to get notifications 5 P a g e

6 3..2 Provide settings for getting notifications 4. The User Module 4..1 Provide functions for user management and user settings. 5. The Groups Module 5..1 Provides functions for groups management. 6. Discussion Forum system 6..1 Discussion Forum interface to discuss on different topics 6..2 Reply functionality for threads 7. User Interface module 7..1 User Interface to interact with users, groups 7..2 Reply functionality for thread 8. Assignment module 8..1 Professor puts up an assignment as a discussion thread with a submission link 8..2 Students submits the assignment via submission link 9. Seminar Info module 9..1 Information about the Upcoming Seminar/Conference with Data, Time and Venue 10. FAQ module FAQ questions about the usage of the portal and also the Institute where used 11. Campus News Campus News 12. Time Table 6 P a g e

7 Figure 1: System Architecture View 2.2 Brief Overview of Modules Database Provides data management and stores information about users, files, directories. It is divided into two logical partitions, User database and file database. These two partitions do not interact with each other and are different in nature. Metadata of files is managed in Database and not in the file system. Database used is MySQL. Exploits transaction processing capability to avoid race conditions. All modifications in the database will be performed through PHP File Sharing System It stores files uploaded by users. 7 P a g e

8 There is a root directory in which the main directory of each user is present. All files of a user are stored in the user s main directory. There is a user permission database that has file ID and user permission information Notification System This module will provide notifications for users who want to get notifications Notification will be in the form of Discussion forum Provide an interface for Discussion Forum interface to discuss on different topics. Discussion thread will be stored on the database with the access permission information Interface Module It acts as an interface to the database, providing simple methods to access data in database in logical manner. It is divided into two logical partitions, User Interface and File Interface, which do not interact with each other. These logical partitions interact with their corresponding sections in the Backend Database. It has classes like Database class, User class which provide a set of accessor and mutator methods as well as logic for retrieving, inserting, updating, and deleting data from the database. The module does processing to abstract out the underlying database design. It requires PHP for connection to Database. It also provides classes to logically represent Attribute Collections. 2.3 Module Dependencies Some modules are dependent on other modules. For instance, the Database Module will get request, it will process them and constitute queries for Database or manipulate the data Storage. Once results to a query are obtained from the Database, they will be passed on to the user interface via Data Interface. Database and content Sharing System are not directly related and Data Interface module provides the required interface 8 P a g e

9 3. Detailed Description of Components 3.1 Database Identification Type Purpose Function Subordinates Database Module Provides means of Data Management Takes SQL QUERY and UPDATE commands from the User and File data modules, and stores and retrieves the data according to those commands The database will store the following data in tables. Users user_id* group_id# permission_level 0: Student 1: Professor 2: Administrator notification_setting user_quota user_password(encoded) department_name personal_info Groups group_id* user_nos group_name department name course name year (These groups will be added at the startof the semester by System Administrator.) Files global_file_id* owner_id# file_name file_path date size Shared_group_id Shared_user_id Discussion thread_id* heading user_id# thread_permission Shared_group_id# Shared_user_id# start_time end_time Comment 9 P a g e

10 Dependencies Interfaces Resources Data comment_id* thread_id user_id comment time Notification notification_id* group_id notification * table primary key # foreign key. An administrator must perform database setup functions, adding and modifying the structure of tables so that the backend can store the data as appropriate. Apart from administrative setup, all modification of the database items will be performed via PHP. There are two separate partitions in data interfaces to handle the two types of database, User, Discussion and File database The database we are using is MySQL. All tables will be created by an administrator (us). We will use the MySQL interface to set up and enter initial data in the following tables: Users, Files, Discussion Threads, Access Permissions, Shared Files. These tables are broadly classified into two logical partitions, User Database and File Database. Once these are entered, we will use the data held in these fields as a baseline for our backend processing and retrieval. Our Data Interface module will connect to the database using PHP language. Once the server gets a request for a certain data type from a client it will create a valid SQL statement. Once it has generated a valid SQL statement, the server will connect to the database, execute the query and get a Result Set back. At this point, it will convert the Result Set to the Object which will be passed on to the Controller module. The data in the database will be filled by the server. We will use valid SQL statements called through PHP to execute these commands. In every case we will get a Result Set (for queries) or a SQL Exception if the command does not work for any reason. We will handle these appropriately 10 P a g e

11 Figure 2: Entity Relation Diagram 3.2 Data Interface Identification Type Purpose Function Subordinates Dependencies (STUB) Data Interface Package Acts as an interface to the database, providing simple methods to access data in database in logical manner This class has a set of accessor and mutator methods as well as logic for retrieving, inserting, updating, and deleting data from the database The Userdata interface includes the following functions get_record($table, $cond) get_record_sql($sql) count_records($table, $cond) count_records_sql($sql) record_exists($table, $cond) delete_records($table, $cond) insert_records($table, $data) update_record($table, $cond) The module depends on the database 11 P a g e

12 Resources Processing Data Remarks and file system to be in a consistent state The specific resources required for the class library are mysql library for MYSQL The module does enough processing to abstract out the underlying database design, and also exposes some higher level functions like search etc The module stores an in-memory copy of the data stored in the database The Modules that access the database directly shall use transactions to get around the issues of race conditions 3.3 Notification Identification Type Purpose Function Dependencies Interfaces Resources (STUB) Notification Class Abstracts away the functionalities required to send and receive notifications Implements the functions related to sending and receiving notifications User Class Database Class The class defines the following functions: send_notifications(user_id, notification_id) get_all_notifications(user_id) enable_notifications(user_id) disable_notifications(user_id) is_notification_enabled(user_id) delete_notification(notifications_id) delete_all_notifications(user_id) get_notifications_text(notification_id) Requires Database class to connect with the database 3.4 Users Identification Type (STUB) User Class 12 P a g e

13 Purpose Function Dependencies Interfaces Abstracts away the functionalities required for user management and authentications Implements the functions related to user management and authentication Group Class Database Class The class defines the following functions: login(username, password) logout(user_id) get_user(user_id) get_username(user_id) get_name(user_id) get_ (user_id) get_userid(username) set_ (new_ , user_id) set_password(new_password, user_id) set_name(new_name, user_id) 3.5 Groups Identification Type Purpose Function Depedency Interfaces Resources (STUB) Group Class Abstracts away the functionalities required for group management Implements the functions related to group management User Class Database Class class defines the following functions: get_grouplist(user_id) get_group(group_id) get_group_ (group_id) set_group_ (new_ , group_id) set_group_password(new_password, group_id) set_group_name(new_name, group_id) add_new_member(group_id,user_id) delete_existing_member(group_id,user_id) Requires Database class to connect to database 3.6 Content Sharing Module Content Upload (Sub-Module) Identification Content Sharing Upload 13 P a g e

14 Type Purpose Function Dependency Interfaces Class Provides means for Uploading data Implements the functions related to content uploading and content permission. User Class Group Class Content Sharing Super class Database Class The class defines the following functions: Resources Data Send_content(content_name, sender user_id, receiver userid) add_content(content_name,user_id,group_ids) delete_content(user_id,group_id,content_name) is_duplicate(content_name,group_id) update_content(new_name, old_content_name) Requires Database class to connect to database The uploaded files will be saved on the server Content Download (Sub-Module) Identification Content Sharing Download Type Class Function Implements the functions related to content downloading Dependency User Class Group Class Content Sharing Super Class Database Class Interfaces The class defines the following functions: Resources Data download_content(content_name, user_id) is_content_downladable(content_name, user_id) download_multiple_copies(content_name, no. of copies) Requires Database class to connect to database The downloaded files will be saved on the machine 14 P a g e

15 3.7 Discussion Forum Identification Type Purpose Function Dependency (STUB) Discussion Forum Module Provides means for hosting a discussion forum Implements the functions related to discussion forums and required permission level User Class Group Class Database Class Interfaces Resources Data The Module provides the functionality to start a discussion thread. The corresponding functions are: Start_discussion(user_id,group_id,topic,data) Delete_discussion(user_id,group_id,topic_id) Post_comment(user_id,discussion_id,comment) Delete_comment(user_id, discussion_id, comment_id) None Requires Database class to connect to database 3.8 Assignment Module Identification Type Purpose Function Dependency Interfaces (STUB) Assignment Module Provides means for Assignment Submission Implements the functions related to Posting Assignment Question by the professor using a higher permission level and student Submitting the Assignment file with a lower permission level Group Class Discussion Class Database Class Content Sharing Super class Content Sharing Upload class The Module provides the functionality for assignment submission. The corresponding functions are: Start_assignment(user_id,group_id,topic,data,fi le,end_time) 15 P a g e

16 Resources Data Submit_assignment(thread_id,user_id,data,file) is_assignment_active(thread_id) None Requires Database class to connect to database 4. Design Decisions 4.1 Use of PHP We decided to use PHP for our website because it provides for more flexibility in comparison to JSP in terms of design and background processing. We could also have used ASP.NET but decided instead to use PHP, because our team-members are more familiar with PHP than.net 4.2 Use of MySQL We decided to use MySQL for our website because it provides more speed and is lightweight in comparison to other database engines. It is also free and open-source 4.3 Use of Apache We decided to use Apache for our website because it s free, open-source and extremely stable web server. Several modules are already available for apache. It is also used by most large websites 16 P a g e

17 5. User Interface 5.1 Login Screen Figure 3: Login Screen 17 P a g e

18 5.2 Main Screen Figure 4: Main View 18 P a g e

19 5.3 Time Table View Figure 5: Time Table View 19 P a g e

20 5.4 Assignment View Figure 6: Assignment View 20 P a g e

21 5.5 Discussion Thread Figure 7: Discussion Thread View 21 P a g e

22 5.6 Notification View Figure 8: Notifications View 22 P a g e

23 5.7 Seminar Info Figure 9: Seminar Info View 23 P a g e

24 5.8 Group Info Figure 10: Group Info View 24 P a g e

25 5.9 Blog View Figure 11: Blog View 25 P a g e

26 5.10 Online Survey Figure 12: Online Survey View 26 P a g e

27 5.11 Search Old Paper Figure 13: Search Old Paper View 27 P a g e

28 5.12 Content Sharing Figure 14: Content Sharing View 28 P a g e