Virtual Classroom: Snakes

Virtual Classroom Software Requirement Specification Snakes
Version 1 29/12/2010
SNAKES
Virtual Classroom
Software Requirement Specification
Version 1
Team Guide : Members:
Sourav Mitra Shoubhik Bose Shamik Ray Sumon Sadhukhan Sudipta Ghosh
College Name: Department: State:
Netaji Subhash Engineering College. Computer Science Engineering. Westbengal
1 Snakes/Netaji Subhash Engineering College
Version 1 29/12/2010
Revision History
Date 29/12/2010 Version 1 Description Basic Structure and design of the project Author Snakes
Version 1 29/12/2010
Table of Contents
Description 1.0 Introduction 1.2 Scope 1.3 Definition, Acronyms, and Abbreviations 1.4 References 1.5 Technologies to be used 1.6 Overview Page No.
2.0 Overall Description 2.1 Product Perspective 2.2 Software Interface 2.3 Hardware Interface 2.4 Product Function 2.5 User Characteristics 2.6 Constraints 2.7 Architecture Design 2.8 Use Case Model Description Class Diagram ........................................................................ Sequence Diagram s ...............................................................
2.10 Database Design ....................................................................

Version 1 29/12/2010
2.11.1 ER Diagram ............................................................... 2.11.2 Schema ...................................................................... 2.12 Assumptions and Dependencies 3.0 Specific Requirements 3.1 Use Case Reports 3.2 Supplementary Requirements
Version 1 29/12/2010
Software Requirements Specification

1.0
Introduction:
1.1 Purpose:
Gaining motivation from ONLP ( One Laptop Per Child ) project and NPTel(National Programme on Technology Enhanced Learning ) , we yearn to provide good quality education to the masses through the use of technology.
Give a man a fish and you feed him for a day. Teach him to fish, you feed him for a lifetime !
Making education accessible for all mankind, our project would help to spread literacy to places where it becomes difficulty to maintain the quality of education, due to economic, social and polictical problems.
1.2 Scope:
The Scope of the virtual classroom includes:
The users need to be connected to the internet. The students act as consumers for the information produced by the teachers. They(the students) take exams , view lectures and participate in exams. The management appoints the teachers. The administrator assures a smooth running of the system.
1.3 Definitions, Acronyms, and Abbreviations:

HTML (Hyper Text Markup Language): It is used to create static web pages. JSP (Java Server Pages): It is used to create dynamic web content. J2EE (Java 2 Enterprise Edition): It is a programming platform, belonging to the Java platform, which is used for developing and running distributed java applications. WASCE (WebSphere Application Server Community Edition): It is an application server that runs and supports the J2EE and the web service applications.
Version 1 29/12/2010
WSAD (WebSphere Studio Application Developer ): It is a designer toolkit which is designed to develop more complex projects by providing a complete dynamic web service. DB2 (IBM Database 2): It is a database management system that provides a flexible and efficient database platform to raise a strong "on demand" business applications. HTTP (Hyper Text Transfer Protocol): It is a transaction oriented client/ server protocol between a web browser and a web server. XML (Extensible Markup Language): It is a markup language that was designed to transport and store data. Ajax (Asynchronous Java Script and XML): It is a technique used in java script to create dynamic web pages. Web 2.0: It is commonly associated with web applications which facilitate interactive information sharing, interoperability, user-centered design and collaboration on the World Wide Web.
1.4

References:
Database System Concepts - 6th edition by Avi Silberschatz Henry F. Korth S. Sudarshan
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/ http://www.magicdraw.com/files/case_studies/magiclibrary/requirements/MagicLibrary%20System%20 Requirements.pdf?NMSESSID=
UML DISTILLED by Martin Fouler. www.csc.villanova.edu/~tway/courses/csc4181/srs_template-1.doc
1.5 Technologies to be used:

J2EE: (Servlet, JSP, JAXP, Java Beans) Application architecture. JAVA: Application architecture. WASCE: (WebSphere Application Server Community Edition) Web Server DB2: IBM Database. Ajax: Asynchronous Java Script and XML.
XML: Extension Markup Language. Web 2.0: RSS Feed 2.0.

Version 1 29/12/2010
RAD 7.0: Development tool. Localization: 3 Languages - Hindi, Kannada, and English 1.6
Overview
The SRS will include two sections, namely: -I- Overall Description: This section will describe major components of the system, interconnections, and external interfaces.
-I- Specific Requirements: This section will describe the
functions of actors, their roles in the system and the constraints faced by the system.
Version 1 29/12/2010
2.0 Overall Description:

2.1 Product Perspective
Education is our birthright. With a motivation to provide education to people worldwide, the virtual classroom system provides a user-friendly interface to celebrate the spirit of learning , collaborating and thereby taking mankind one step forward to a no-strings attached mode of acquiring knowledge. On the client side, the users see HTML content . Communication is via HTTP/HTTPS protocols. The Server side web server is J2EE compliant. The DATABASE server is IBM DB2 Universal Database Server.
2.2 Software Interface:

-I- Front End Client: Web browser ( IE, NN, Mozzila, and Firefox. ) -I- Web Server: WebSphere Application Server CE -I- Data Base Server: IBM DB2 UDB
2.3 Hardware Interface:

Client Side:
MINIMUM SYSTEM REQUIREMENTS PENTIUM 4 AT 1 GHz , 256 MB RAM , DISC SPACE : 100MB
Server Side:
MINIMUM SYSTEM REQUIREMENTS SOFTWARES: IBM DB2 , WASCE PENTIUM 4 AT 1 GHz , 512 MB RAM , DISC SPACE: 1GB 8 Snakes/Netaji Subhash Engineering College
Version 1 29/12/2010
2.4 Product Functions

Students can choose courses, attend lectures, take exams, view their attendance records, progress reports etc as per their convenience. Registration for multiple courses. Attend lectures either at the scheduled time or on request view lecture at a later time. Faculties can take lectures, upload assignments, announcements, evaluate answer sheets and also can upload lectures and other discussions in various formats as in videos, power point presentation etc. Upload and Download of various assignments, college notices, student's notices, journals, videos. Asynchronous communication in the form of Emails, discussion boards that enable communication to occur at "convenient-times" that suit student schedules and are not accessed at simultaneous or prearranged times. There can be forums, blogs etc to discuss various queries and to put up suggestions posted both by students and teachers. Administrator can generate reports, log files, backup/recovery of data at any time. Shared documents and media library that can help in active learning of a student. One-to-Many (B->A), Many-to-One(A->B) and Many-to-Many (B->B) information sharing. Provision of resources to arouse the interest of students in extracurricular activities like public speaking etc and to grasp the chance to enhance their personalities. Users must have valid User ID and password to login thus creating their individual profiles.
( more functions will be implemented during the coding phase )
2.5 User Characteristics

The user needs to be able to use the computer ,connect to the internet. The technologies used in this project need not be known to the user. The GUI will support upto language translation upto 25 languages ( using Google Translate). The user needs to have average sensory ability.
Version 1 29/12/2010
2.6 Constraints: No provision for guest users. User must be registered as a STUDENT , FACULTY , MANAGEMENT , ADMINISTRATOR. Only HTTP/HTTPS protocols will be used. The database server needs to secure. ( physically as well). The Faculty can register only on permission from the Management. The Management user can register only on permission from the Administrator.
2.7 Architecture Design:
2.8 Use Case Diagram

A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram defined by and created from aUse-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases.
Following is our
use case diagram.

Version 1 29/12/2010
Version 1 29/12/2010
2.9 CLASS DIAGRAM

A class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. Following is out class diagram.
Version 1 29/12/2010
Version 1 29/12/2010
2.10 SEQUENCE DIAGRAM
CREATING A NEW LECTURE: ACTOR: FACULTY
Version 1 29/12/2010
TAKING AN EXAM ACTOR: STUDENT
Version 1 29/12/2010
USER AUTHENTICATION ACTORS: STUDENT,FACULTY,MANAGEMENT,ADMINISTRATOR
Version 1 29/12/2010
POST TO A FORUM: ACTORS: STUDENT,FACULTY,MANAGEMENT,ADMINISTRATOR
Version 1 29/12/2010
READ A MESSAGE ( ASYNCHRONOUS MESSAGING SERVICE) ACTORS: STUDENT,FACULTY,MANAGEMENT,ADMINISTRATOR
2.10.1 DATABASE DESIGN
Version 1 29/12/2010
2.10.2 E-R DIAGRAM
Version 1 29/12/2010
TABLES USED IN THE DATABASE:
SYSTEM ACCESS
USER( uid , password,active, privilege ,doj ) PRIMARY KEY: uid FOREIGN KEY: uid references uid of USER
STUDENT (sid,name) PRIMARY KEY and FOREIGN KEY: sid references uid of USER STUDENT_CONTENT(sid,name,content) FOREIGN KEY: sid references sid of STUDENT FACULTY(fid,fname) PRIMARY KEY and FOREIGN KEY: fid references uid of USER FACULTY_CONTENT(fid,content) FOREIGN KEY: fid references uid of FACULTY MANAGEMENT(mid,designation) PRIMARY KEY and FOREIGN KEY: mid references uid of USER MANAGEMENT_CONTENT(mid,content) FOREIGN KEY: mid references uid of MID ADMINISTRATOR(aid) PRIMARY KEY and FOREIGN KEY: aid references uid of USER ADMINISTRATOR_CONTENT(aid,content) FOREIGN KEY: aid references aid of USER
Version 1 29/12/2010
EXAM MANAGEMENT
EXAM( eid,cid,fid,arr_questions ) During implementation , EXAM is normalized to EXAM_DETAILS AND EXAM_QUESTIONS EXAM( eid,cid,fid,arr_questions,arr_answers ) decomposed EXAM_DETAIL( eid , cid , fid ) foreign key: cid references cid of COURSE_DETAIL EXAM_QUESTION( eid , arr_questions ) EXAM_ANSWER(eid , arr_answers ) foreign key: eid references eid of EXAM_DETAIL SOLUTION(soln_id , eid , sid , arr_solns , result ,checked) decomposed SOLUTION_DETAIL(soln_id , eid , sid , checked) SOLUTION_CONTENT(soln_id, arr_solns) SOLUTION_RESULT(soln_id,result) PRIMARY KEY: soln_id FOREIGN KEY: soln_id references soln_id of SOLUTION_DETAIL eid references eid of EXAM_DETAIL
Version 1 29/12/2010
DEPARTMENT MANAGEMENT
DEPARTMENT( did, hod , dname , content ) PRIMARY KEY: did decomposed DEPARTMENT_DETAIL( did , hod , dname ) , DEPARTMENT_CONTENT ( did , content )
COURSE MANAGEMENT
COURSE ( cid , did , fid , info ) decomposed COURSE_DETAIL(cid,did,fid) PRIMARY KEY: cid FOREIGN KEY: did references did of DEPARTMENT_DETAIL COURSE_INFO(cid,...)
LECTURE MANAGEMENT
LECTURE ( lid , cid , fid , lcontent , date) PRIMARY KEY: lid FOREIGN KEY: cid references cid of COURSE fid references fid of FACLUTY can be decomposed as
LECTURE_DETAIL(lid,cid,fid) and LECTURE_CONTENT(lid,lcontent)
Version 1 29/12/2010
FORUM MANAGEMENT
FORUM ( fo_id , cid ) PRIMARY KEY: fo_id FOREIGN KEY: cid references cid of COURSE_DETAILS TOPIC( tid , fo_id , user_id , date_created , date_modified,content ) PRIMARY KEY: tid FOREIGN KEY: fo_i references fo_id of FORUM. user_id refernces uid of USER. POST(po_id , tid , user_id , content, date ) PRIMARY KEY: po_id FOREIGN KEY: tid references tid od TOPIC user_id references uid of USER
MESSAGING SERVICE
MESSAGE ( mid , sender , recipient , subject , content ,date) PRIMARY KEY: mid FOREIGN KEY: sender,recipent references uid of USER. decomposed MESSAGE_DETAIL( mid , sender , recipent , subject ,date) MESSAGE_BODY(mid , content ) 23 Snakes/Netaji Subhash Engineering College
Version 1 29/12/2010
BLOG MANAGEMENT
BLOG(bid,uid) PRIMARY KEY: bid FOREIGN KEY: uid references uid of USER BLOG_POST(bid,bpid,content) PRIMARY KEY: bpid FOREIGN KEY: bid BLOG_POST(bid,bpid,content) decomposed
BLOG_POST_DETAIL(bpid,bid)
BLOG_POST_CONTENT(bpid,content)
NOTE:Content stands for multiple attributes, LOB(large objects) .i.e, related attributes for a table. (to be decided during coding)
Version 1 29/12/2010
2.11 ASSUMPTIONS AND DEPENDENCIES Staying synchronised with the vision of the project, registration of a student does not require
prior permission of any other user with a higher access privilege/role.
Faculty members are registered strictly by the Management.

The Virtual Classroom system is affiliated to an organisation who can appoint teachers from anywhere in the world , but only after processing their application. As far as contacts are concerned, every student has every other course-mate as her 'contact' which shows up in her conact list. The USER_ID is unique. The Student_id, faculty_id , management_id and admin_id references UER_ID. The virtual classroom does not create discriminate on grounds of Grade or Standard, the only grounds of distinction,however, are the courses being taken. In the implementation phase of this project , it is being thought that every student will be given a rating based on a specific criteria. The Messaging service is used for INTRA-APPLICATION electronic mail transfer . An email notification will be sent to the public email account of recipient.
Version 1 29/12/2010
3.0 SPECIFIC REQUIREMENTS 3.1 USE CASE REPORT

USER AUTHENTICATION
OPERATION: REGISTRATION ( STUDENT ) : DESCRIPTION: Non-registered students need to first register before accessing the virtual classroom. Precondition User requests to login to the system and fails / and clicks Register as a Student BASIC FLOW OF EVENTS: USER_ID forwarded to registerUser.jsp registerUser.jsp accesses database and checks privilege . If Student, fetch registerForm.jsp and display in web browser. After student fills up the form, the HTTP POST sends the attribute values to the web container. The web container sends the HTTPRequest object to the insertForm.jsp , A new entry is inserted into the USER table , the (generated)user_id is returned. The HTTPRequest object attributes and the user_id is collectively inserted into the STUDENT_DETAILS table. The user_id is returned to the client and and a confirmation email is sent. Actors Student Postcondition After user registration, the appropriate HOME page is generated.
Version 1 29/12/2010
OPERATION: REGISTRATION ( FACULTY ) : DESCRIPTION: Faculty registration , unlike student registration requires verification, hence, needs human interception. The prospective-faculty sends his request to the management user-in-charge , who reviews it before accepting the prospective-faculty into the organisation. Precondition User requests to login to the system and fails / and clicks Register as a FACULTY BASIC FLOW OF EVENTS: The user is provided with the email address of the management user-in-charge for recruitment. The faculty ( asynchronously) sends her CV by email. The user-in-charge after acknowledging the letter, creates a new USER object ( with active = false) and inserts the tuple in the USER database. The user-in-charge sends the user_id and the system generated password to the faculty. The faculty logs in to the system using the newly acquired user_id and password, consequently, the ACTIVE is changed to TRUE.
Actors Faculty PostCondition After user registration, the appropriate HOME page is generated.
Version 1 29/12/2010
OPERATION: REGISTRATION ( MANAGEMENT) : DESCRIPTION: The prospective management user logs in only by verification from the director. Precondition The user registers her request by email to the 'Director' BASIC FLOW OF EVENTS: The 'Director' (also a management user , but highest in the hierarchy tree) creates a new entry in the User table and sets it as ACTIVE= FALSE. He , then sends the user_id and (system generated) password to the prospective management user. The management user, on a successful first time login, fills out his profile. Concurrently, the system also sets ACTIVE=TRUE. Actors Faculty PostCondition After user registration, the appropriate HOME page is generated.
Version 1 29/12/2010
OPERATION: LOGIN: DESCRIPTION: Only registered user can to Log in. Users use the USERID and PASSWORD pair to login to the system. The USER database is searched for the USERID , PASSWORD pair and SYSTEM access is allowed if such a pair is found, else denied. Actors All Users. Student Faculty Management Administrator
Precondition User requests to login to the system by POSTing the user_id and password. BASIC FLOW OF EVENTS: The table USER is checked whether the corresponding USER_ID and PASSWORD pair is correct. If yes, then ACTIVE attribute is checked. If ACTIVE = TRUE, then the corresponding HOMEPAGE is generated. Otherwise, ACTIVE is set to TRUE , and the create profile page is generated at the client side NOTE: ACTIVE = FALSE signifies First-time log-in
Version 1 29/12/2010
Alternative Flow of Events USERID and PASSWORD is incorrect. System informs USER that incorrect password or user_id is entered. Postcondition After user login, the appropriate HOME page is generated.
OPERATION:LOGOUT: Description After the user ends working with the system, he logs out in order none can use his profile to add new reading items or for any other reason to pretend someone else. Actors All Users PreCondition The user requests to log out from the system. Basic Flow of Events USER SETTINGS are saved. Session is invalidated. POST CONDITION The user is logged out from the system.
Version 1 29/12/2010
COURSE MANAGEMENT
OPERATION: TAKE A LECTURE. Description: The user( student) logins to the system, visits his home page. Opens the course and then clicks on the Lecture URL to visit the corresponding Lecture Home Page. Actor: Student PreCondition The user clicks on the Lecture name from the Lectures table(not database) in the user interface . The lecture data is then requested from the Web Server. Basic Flow of events Check whether the student is enrolled to the course to which the lecture belongs. If not, go to STEP 3 , else JUMP to step 4. (Enroll)Register for the Course Seek the data corresponding to the LECTURE_ID from the TABLE: LECTURE_DETAILS Display it as showLecture.jsp
Alternative flow of events The student is not enrolled to the corresponding course. Enroll. Postcondition Send the HTML response for the showLecture.jsp to the web browser(client side)
Version 1 29/12/2010
OPERATION: CREATE COURSE
Description The Management user logs in to the system and creates a new course to create the new course. Actors: Institution management ONLY. Precondition The user requests the newCourse.jsp( to create a new course) Basic flow of events The user fills out the details of the course. The details are sent to the web server as a HTTP Post ( directed to insertCourse.jsp ). The web container created the HTTPRequest object and sends the request to the insertCourse.jsp. The insertCourse.jsp interacts with the Database and enters the new entry into the table COURSE.
PostCondition: The User is shown the Course home page for the corresponding Course_id , which was just created by her.
Version 1 29/12/2010
OPERATION: REGISTER FOR A COURSE Description: The user visits/browses the ALL COURSES and opens the COURSE Home page and requests to join. Actors: Student PreCondition Request to enroll to a course. ( identified with Course_name and Course_id ) Basic Flow of Events The entry < Enrollement_id,Student-id,Course_id> is sent as HTTP Post to the insertEnroll.jsp in the web server from the web browser(client). The database connection is made and the the new entry is updated in the Enroll table. An email acknowledgement is sent to the User's inbox on success. Alternate Flow of Events. The user may have been removed from the course previously for inappropriate behaviour, and hence wouldn't be allowed to register. The user shall have to send the course enrollement request to the HOD by email.
PostCondtition The User sees the course Home page.
Version 1 29/12/2010
ASYNCHRONOUS MESSAGING SERVICE
OPERATION: Send a message.
Description:
The User of the system shall open the messaging service. Then on clicking the COMPOSE button, Users will be shown his contacts, and The user is required to selects the contact(s) she wishes to send a message.Or, he may skip the contacts page. Actors: Student. Faculty. Management. Administrator.
PreConditions The logged in user opens the messaging service and clicks on 'compose a message'.
Basic Flow of Events The form to type in the message is generated with the FROM field set as the user's email address. The TO field is filled with the synchronously if the user has selected reicipents form the contacts list. Otherwise , she enters it manually. The form input fields are sent to the web server as HTTP POST ( directed to sendEmail.jsp ) The web container creates the HTTPRequest object and calls the sendEmail.jsp sendEmail.jsp inserts the entry < message_id,sender_id,recipient email address,recipent_id,subject,time>into the message_details table.
Version 1 29/12/2010
SendEmail.jsp inserts the entry < message_id , body > into the message_body table. The INBOX page of the user's account is generated. PostCondition The User is acknowledged by a message (in the inbox) whether the message was successfully sent. Included use cases Reply to a message. Forward a message.
Version 1 29/12/2010
OPERATION: Read incoming message.
Description: The Users of the system is notified in the HOME page , the number of unread messages.
The User opens the messaging service, browses to the INBOX, and clicks on the message she wishes to read from the list of messages. Actors: Student. Faculty. Management. Administrator.
PreConditions The logged in user opens the messaging service and clicks on 'INBOX'. Basic Flow of Events The user clicks on the INBOX from the MESSAGING SERVICE page . The Web container fetches the showMessageList.jsp and supplies the parameter <userid> showMessageList.jsp queries the database table message_details and returns the tuple(s) where <user_id> equals <recipent_id> The List of messages is ordered(descending order TIME) and generated dynamically corresponding to the attributes <sender, subject, time> The HTML reponse is generated and sent to the web browser. The User clicks on the message subject she wishes to view .
Version 1 29/12/2010
The request for showMessage.jsp ( along with <message_Id> using URL rewriting) is sent to the web Server. The Web container sends the HTTPRequest object( containing <message_id>) and queries the message_body for the corresponding message_id from the MESSAGE_BODY table. The dynamic web page is generated containing the message_body and sent to the client(Web browser). PostCondition
The User views the message in her web browser.
EXAM MANAGEMENT
OPERATION: TAKE AN EXAM
Description: The user selects an exam and the system generates an interface for the user to answer the examination. Then on submission, the solution is passed as attributes to insertSolution.jsp , which inserts the data into the database.
Actors: Student.
Version 1 29/12/2010
PreConditions: The user requests an exam listed in the corresponding home page of the course. Basic Flow of Events: The user visits the Course Home page . Clicks on the Exam from the list of available exams. The request is sent to the web server as HTTP POST. The web container creates a HTTPRequest object and sends it to insertExam.jsp , which in turn inserts the entry <solution_id,exam_id,user_id,solution> into the database table EXAM. The user is sent a notification as a message to the user. PostCondition
The web server generates the COURSE home page for the USER.
OPERATION: CREATE AN EXAM Description: The faculty who's administering the corresponding course visits the course home page and fetches the new exam template . PreCondition The Following (minimal)information is provided to the system : Course_id and faculty_id of the corresponding exam. Actors Faculty Basic flow of Events Course_id and Faculty_id is saved as session attributes. The user requests for the new exam template . The web server sends it to the web browser.
Version 1 29/12/2010
The user sets the questions and sends it to the web server as a HTTP Post . The web server creates a HTTPRequest object and forwards it to insertExam.jsp insertExam.jsp inserts the tuple <exam_id,course_id,faculty_id> into the EXAM_DETAILS table and <exam_id , questions> into the EXAM_QUESTIONS table. Note: The questions are stored in CSV format. PostConditions New exam is created and shows up in the list of exams in the list of exams for the corresponding course.
Version 1 29/12/2010
FORUM MANAGEMENT OPERATION: POST TO A FORUM Description: The User creates a post for a particular forum_id and topic_id (of database table TOPIC) and inserts the post into the database table: POST PreCondition The Following (minimal)information is provided to the system : Course_id and faculty_id of the corresponding exam.
Actors 1)Faculty 2)Student 3)Management 4)Administrator
Basic flow of Events user requests the createPost.jsp and send the <forum_id> and <topic_id> as request parameters. The create-a-new-post page contains the text field for the post, as well as topic_id and forum_id as HIDDEN FIELDS. On submitting the form , the parameters <post_data>,<topic_id> and <forum_id> is sent to the web server. The web container creates a HTTPRequest object and forwards it to insertPost.jsp insertPost.jsp inserts the request parameters to the database and returns an acknowledgement.
Version 1 29/12/2010
PostConditions
The post is inserted into the database and it is up for viewing for any user reading that particular forum topic.
Version 1 29/12/2010
BLOG MANAGAMENT OPERATION:POST TO A BLOG Description: The user view the blog and clicks on POST-TO-BLOG. The system checks if the blog belongs to the User and then redirects her to the page where the user can create her post. Then the post is added to the database. Finally, on re-opening the blog , the new post shows up. Actors: STUDENT FACULTY MANAGEMENT ADMINISTRATOR
PreCondition The user requests the createBlogPost.jsp . The user_id and blog_id is known to the system.
Basic flow of events: The client sends the user_id and blog_id to createBlogPost.jsp as a request parameter. The database table is checked whether there is a tuple containing the user_id and blog_id pair. If no such tuple is found then, an error message is sent to the client. Else, createBlogPost.jsp generates an interface to type in a new post at the client side.
Version 1 29/12/2010
PostCondition: The new post shows up in the blog.
ASSUMPTIONS AND DEPENDENCIES

Staying synchronised with the vision of the project, registration of a student does not require prior permission of any other user with a higher access privilege/role. Faculty members are registered strictly by the Management. The Virtual Classroom system is affiliated to an organisation who can appoint teachers from anywhere in the world , but only after processing their application. As far as contacts are concerned, every student has every other course-mate as her 'contact' which shows up in her conact list. The USER_ID is unique. The Student_id, faculty_id , management_id and admin_id references UER_ID.The virtual classroom does not create discriminate on grounds of Grade or Standard, the only grounds of distinction,however, are the courses being taken. In the implementation phase of this project , it is being thought that every student will be given a rating based on a specific criteria. The Messaging service is used for INTRA-APPLICATION electronic mail transfer . An email notification will be sent to the public email account of recipient.

Virtual Classroom: Snakes

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Virtual Classroom: Snakes

Uploaded by

Copyright:

Available Formats

Virtual Classroom Software Requirement Specification Snakes

Team Guide : Members:

College Name: Department: State:

Netaji Subhash Engineering College. Computer Science Engineering. Westbengal

1 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

2 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

2.10 Database Design ....................................................................

Virtual Classroom Software Requirement Specification Snakes

4 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

Software Requirements Specification

1.3 Definitions, Acronyms, and Abbreviations:

5 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

UML DISTILLED by Martin Fouler. www.csc.villanova.edu/~tway/courses/csc4181/srs_template-1.doc

1.5 Technologies to be used:

XML: Extension Markup Language. Web 2.0: RSS Feed 2.0.

Virtual Classroom Software Requirement Specification Snakes

7 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

2.0 Overall Description:

2.2 Software Interface:

2.3 Hardware Interface:

Virtual Classroom Software Requirement Specification Snakes

2.4 Product Functions

( more functions will be implemented during the coding phase )

2.5 User Characteristics

9 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

2.7 Architecture Design:

2.8 Use Case Diagram

use case diagram.

Virtual Classroom Software Requirement Specification Snakes

11 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

2.9 CLASS DIAGRAM

12 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

13 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

2.10 SEQUENCE DIAGRAM

CREATING A NEW LECTURE: ACTOR: FACULTY

14 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

TAKING AN EXAM ACTOR: STUDENT

15 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

USER AUTHENTICATION ACTORS: STUDENT,FACULTY,MANAGEMENT,ADMINISTRATOR

16 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

POST TO A FORUM: ACTORS: STUDENT,FACULTY,MANAGEMENT,ADMINISTRATOR

17 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

READ A MESSAGE ( ASYNCHRONOUS MESSAGING SERVICE) ACTORS: STUDENT,FACULTY,MANAGEMENT,ADMINISTRATOR

2.10.1 DATABASE DESIGN

18 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes

2.10.2 E-R DIAGRAM

19 Snakes/Netaji Subhash Engineering College

Virtual Classroom Software Requirement Specification Snakes