Web-Based Instructional Information Management System
Web-Based Instructional Information Management System
(WIIMS)
PROJECT REPORT
BY
John Xavier
Project Guides:
Mr. Vinod. P
Dr. Vineeth Kumar P
APRIL . 2005
National Institute of Technology Calicut
CERTIFICATE
This is to certify that the work reported in this project report entitled ‘Web-based
Instructional Information Management System’ is a bonafide record of the work done by
John Xavier(Y2M016), a student in the Department of Computer engineering, National
Institute of Technology Calicut from December 2004 to April 2005 in partial fulfillment for the
award of the degree of Master of Computer Applications of the National Institute of
Technology Calicut.
Guides:
Dr.Vineeth Kumar P Mr.Vinod P
Asst.Professor Lecturer
Dept. of Computer Engineering Dept. of Computer Engineering
NIT, Calicut NIT, Calicut
First of all I would like to thank my guide and our project co.ordinator, Dr.Vineeth Kumar P,
Asst.Professor and guide Mr.Vinod P, Lecturer Department of Computer Engineering, National
Institute of Technology, Calicut, for there guidance and support through out my project work.
I would also like to thank Dr. V.K Govindan, Head of the Department, Department of Computer
Engineering, National Institute of Technology, Calicut, for all the help he has extended to me.
Last but not the least, I would like to sincerely thank all my friends especially Sandeep, for his
moral support, valuable suggestions and help during the course of this work.
ABSTRACT
2 SYSTEM SPECIFICATION................................................................................2
2.1 Introduction.....................................................................................................2
2.2 Problem Specification.....................................................................................2
2.3 System Requirements......................................................................................2
2.3.1 Functional Requirements.................................................................... 2
2.3.2 Nonfunctional Requirements...............................................................3
2.3.3 External Interface Requirements..................................................…...4
3 SYSTEM DESIGN..................................................................................................5
3.1 Purpose and scope.................................................................................................. 5
3.2 Definition and acronyms........................................................................................ 5
3.3 Design overview.....................................................................................................5
3.3.1 System Overview.................................................................................................5
3.3.2 Assumptions and Dependencies..........................................................................7
3.3.3 Design issues....................................................................................................... 7
3.4 Detailed System Design...........................................................................................8
3.4.1Architecture Design.............................................................................................. 8
3.4.2 Object Oriented Design........................................................................................ 8
3.5 Data Base Design...........................................................................................10
4 IMPLEMENTATION.......................................................................................................15
4.1 Introduction..............................................................................................................15
4.2 Databases and Development tools used...................................................................15
4.3 Client side programming..........................................................................................16
4.4 Implementation Issues..............................................................................................18
5 SYSTEM TESTING..........................................................................................................19
5.1 Introduction.........................................................................................................…..19
5.2 Testing Methods........................................................................................................20
6 SECURITY PROCEDURES...........................................................................................22
7 CONCLUSION................................................................................................................23
APPENDIX A- Sequence Diagrams ..........……..................................................................24
A-1 Adding Course..........................................................................................24
A-2 Assigning Course to students...................................................................25
A-3 Entering marks and viewing grades..........................................................26
A-4 course material..........................................................................................27
APPENDIX B- Screen Shots...........................................................................................29
REFERENCES.....................................................................................…………...35
1. INTRODUCTION
The system has currently three modules, Administrator, Instructor and Students.
The Administrator module contains the functionalities like adding course, adding instructor,
adding student, assigning and de.assigning courses to instructor/student. The Instructor module
contains the functionalities like Enter/Edit marks, sending messages, Posting course materials.
The student module contains the functionalities like sending messages, viewing course materials,
viewing marks.
The next chapter gives a detailed description about System analysis done for this
project. That gives a view about the various requirements for this project. Then comes system
design. That gives a view about the design methods accepted for this project. The chapter
implementation gives a view about the implementation techniques adopted for this project.
Since we(myself and Ajesh Kumar P.G) have done this project as a group, we have
divided this implementation into two parts.part 1 and part 2. I have done the part 2 and part 1 by
Ajesh.[7].Part 1 is for implementing all the functionalities for instructor. Part 2 is for
implementing the functionalities of student and administrator. Since this is a group project I am
including part 1 also in this report. .
1
2 SYSTEM SPECIFICATION
2.1 Introduction
1. Administrator
Input of the system to the administrator is the login form. There he can enter his
login id and password .If the identification is correct, the administrator gains control over the
system. He has the options to
1) Provide login to instructor.
2) Provide login to student.
3) Add course.
4) Assigning instructor to course.
5) Assigning student to course.
6) De.assigning instructor from course.
7) De.assigning student from course.
2
8) Remove course.
9) Remove instructor.
10) Remove student.
2. Instructor
Input of the system to the instructor is the login form. There he can enter his login id
and password .If the identification is correct, the instructor gains control over the system. He
has four options
1) Enter/Edit marks of the students for the course he is taking.
2) Sent and view messages.
3) Post course materials.
4) Take printout of mark.list.
3. Student
Input of the system to the student is the login form. There he can enter his login id
and password .If the identification is correct, the student gains control over the system. He
has four options
1) Sent and view messages
2) View course materials.
3) View Marks and grade.
.
1 Hardware requirements
The minimum requirements will be as follows
128 MB RAM
Processor with speed 500MHz
3
100 Mbps LAN connection.
2 Software requirements
Web Server, database
4 Portability
Deliverable formats
The system is delivered as Java Server Pages(JSP) .The needed classes are provided as JAR
files and CLASS files. The java source code for the class files is also provided.
1 User Interfaces
All the interfaces are provided as web Pages.
2 Communication interfaces
The communication protocol HTTP is required.
4
3 SYSTEM DESIGN
This section outlines the expected contents of the system. The deliverable
document from the System Design process will include a set of technical specifications that will
be used to generate (build) and implement the new system. The System Design Document must
be complete and in sufficient detail to allow a technical resource unfamiliar with the project to be
able to construct the system based solely on this document and materials referenced herein.
Users:
Main users are Students and Instructors.
5
Instructors:
1.Course management
Instructors can enter the marks for the students who have registered for a particular
course. He can decide upon the name of evaluation conducted (assignment/quiz etc) and also
upon the grades. Later he may also edit the previously entered marks.
2.Mailing option
Instructors can send short messages to students who are registered for a particular
course. He can either send messages to each student individually or as a whole class.
Students:
2.Mailing option
Students can send short messages to the instructor who is teaching that particular course.
6
3.3.2 Assumptions and dependencies
1. We have given Administrator, Instructor and Student without any inheritance. So the class
diagram we had to represent the same functionalities under different classes (Admin,
Instructor and Student).
2. We have given the whole database as a single class. It reduced the readability of the class
diagram.
3. Interaction of instructor with student.
The interaction can be of two types.messages and course materials. The issue was on how
to send these messages and course materials, whether it should be of the same format or not.
7
3.4.1 Architecture Design
Client HTTP
interaction
Client
Object Oriented Design is a design strategy where system designers think in terms of
‘things’ instead of operations or functions. It is a part of object.oriented development, where an
object.oriented strategy is used throughout the development process.
8
Student
ID:String Course
Passwd:String C_name:string
Login_form Name: String C_ID:string
E.mail:String C_inst:String
Check_login() Sent_msg()
View_msg()
ViewCM()
1 1 m
ViewMarks()
checks access Add/remove
n manage
1..* has
Security_system
Instructor
Validate_login() * n
Add_mark()
Edit_mark() Course material
PostCM() C_ID:String
C_Name:String
Type :attachment
n n
Administrator
Add_User()
Add_Course()
Remove_User() manages
Remove_Course()
Assign_Inst_to course()
Remove_Inst_from_course()
Sent/View Assign_stud_to Course() m
Remove_stud_from_course()
*
Mark
Message Mark1:float
Msg_sent_to:ID Weightage1:int
Message:text Out of 1 :int
…………
Mark8:float
Weightage8:int
Out of 8: int
Grade :char
Figure 2: Class diagram for WIIMS
Calculate_Tot_Mark()
CM =Course material
Msg = message
9
3.5 Data base design
A good design of the database is the base for any application side project. The database
is designed with RDBMS concepts. Special cares have been taken for not going for too much
of normalization so as to make queries faster.
Course
Course_ID Course_Name
INSTRUCTOR
Instr_ID Instr_Name
STUDENT
Stud_ID Stud_Name
MARKS
M_1 M_2 M_3 … … M_7 Total Grade Stud_ID Course_ID
Outof
N_1 O_1 w_1 … … n_8 o_8 w_8 Course_I
D
sms
Course_ID Student_id Message Type Subject msgdate msgtime expdate
10
Abbreviations used
11
The tables used in WIIMS are as follows
1. Course table
This table is used to store the details for each course conducted. It has the
following structure
2. Student table
This table is used to store the details for each student. It has the
following structure
3. Instructor table
12
4. Course.Instructor table
5. Course.Student table
7. Mark table
13
8. Out.of table
14
4. IMPLEMENTATION
4.1 Introduction
The implementation phase translates a detailed design representation of the
problem into programming language realization. The following section describes the software
used for development, coding standards and the practical issues involved in implementing the
software.
JSP
JSP is entirely based on java programming language. Internally, JSP pages are
dynamically converted into java servlets, which are simply java classes. This means JSP
enjoys all the capabilities that java programming supports. The first time that page is loaded
off the server; it is compiled into a java servlet & loaded into memory. Each time a
subsequent request is made to the page, the server just uses the already.compiled page that it
has in memory to do its stuff.
JSP is a great deal more efficient than many other scripting languages, such as CGI
and ASP. Tags can be defined in tag libraries and then used within any JSP page. This makes
for a better separation of page content from its code, which leads to less scattered code and
hence, the site is easier to maintain.
Java is platform and browser independent. Since Java is platform independent JSP
pages can be run on any machine regardless of operating system without recompilation.
There are other advantages as well, JSP allows you to keep much more of your code
separate from the html than other html embedded languages, by using java beans.
15
MySQL
• Fully multi.threaded using kernel threads. This means it easily can use multiple CPUs if
available.
• It works on many different platforms with C, C++, Eiffel, Java, Perl, JSP and Python .
• SQL functions are implemented through a highly.optimized class library.
• A privilege and password system which is very flexible and secure, and which allows
host.based verification
• ODBC (Open.DataBase.Connectivity) support for Windows (with source).
• Handles large databases . tables with over a million rows can be created in MySQL with
no problems.
• Full support for several different character sets.
The most important phase of project from the point of view of an end user is nothing
but interface design. Actually the application communicates with the user through the interfaces.
This work also gives a special attention towards the interface design. A self explanatory GUI is
adopted –Self explanatory in the sense if any one see a button he will get an idea about what is
going to happened next if he or she press that button.
Since we(myself and Ajesh Kumar P.G) have done this project as a group, we have
divided this implementation into two parts.part 1 and part 2. I have done the part 2 and part 1 by
Ajesh Kumar(y2m018) [7] ,a student in the Department of Computer engineering, Master of
Computer Applications, National Institute of Technology Calicut, April 2005
Part 1 is for implementing all the functionalities for instructor. Part 2 is for implementing the
functionalities of student and administrator.
For the sake of completion of the report the first part is also included in the report.
16
Part 1:
Input of the system to the instructor is the instructor.login form. He logins to the
system using the login.id and password pre.assigned to him by the administrator. If the login
is valid then the course page loads automatically. This course page contains a list of courses
that he teaches. On selection of any course the course home page loads automatically. From
this page instructor can send messages and course materials to his students, view messages
sent by students, enter/edit individual marks, take print outs of mark sheet and also can
change his password.
Part 2:
Input of the system to the student is the student.login form. He logins to the system
using the login.id and password pre.assigned to him by the administrator. If the login is valid
then the course page loads automatically. This course page contains a list of courses for
which he has registered. On selection of any course the course home page loads
automatically. From this page student can send messages to his course instructor, view
messages and course materials sent by his course instructor, view his/her individual marks
and also can change his password.
Input of the system to the administrator is the admin.login form. The administrator
has full control over the system. If the login is valid then the admin home page loads
automatically. This page contains options like add ne w student, instructor and course,
assigning and de.assigning course to instructors and students, removing instructor, student
and course and change password.
17
4.4 Implementation Issues
Entering marks for multiple students at the same time was made possible. These marks can
be edited in the same page itself.
5. The inheritance property provided in the class diagram has not been implemented. This is for
providing security.
18
5. SYSTEM TESTING
5.1 Introduction
No program or system design is perfect. The number and nature of errors in a new
design depends on such factors like the communication between the user and the designer, the
programmer’s ability to generate a code that reflects exactly the system specifications and the
time frame for the design. The purpose of system testing is to consider all the likely variations to
which it will be subjected and to push the system to its limits. It is a tedious but necessary step in
system development. Testing is vital to the success of the system. System testing makes the
logical assumption that if all the parts of the system are correct, the goal will be successfully
achieved. The system is to be tested to see whether the outputs are correct to a known specific
input.
1 Unit testing
2 Module testing
3 Sub.system testing
4 System testing
5 Acceptance testing
Unit testing : Individual components are tested to ensure that they operate correctly. Each
component is tested independently, without other component
Sub.system testing : This phase involves testing collection of modules, which have been
integrated into sub.systems. Sub.system may be independently designed and implemented. The
most common problem, which arises in large software systems, is sub.system mismatches. The
sub.system test process should therefore concentrate on the detection of interface errors by
rigorously exercising these interfaces
19
System testing : The sub.system is integrated to make up the entire system. The testing process is
concentrated with finding errors, which result from unanticipated interaction between
sub.systems and system components. It is also concerned with validating that the system meets
its functional and non.functional requirements.
Acceptance testing : This is the final stage in the testing process before the system is accepted
for operational use. The system is tested with data supplied by the system procurer rather than
simulated test data. Acceptance testing may reveal errors and omission in the system
requirements definition because the real data exercises the system in different ways from the test
data. Acceptance testing may also reveal requirements problems where the system’s facilities do
not really meets the users needs or the system performance is unacceptable.
Also known as functional testing. A software testing technique whereby the tester
does not know the internal workings of the item being tested. For example, in a black box test on
software design the tester only knows the inputs and what the expected outcomes should be and
not how the program arrives at those outputs. The tester does not ever examine the pro code and
does not need any further knowledge of the program other than its specifications.
• The test is unbiased because the designer and the tester are independent of each
other.
• The tester does not need knowledge of any specific programming languages.
• The test is done from the point of view of the user, not the designer.
• Test cases can be designed as soon as the specifications are complete.
20
Also known as glass box, structural, clear box and open box testing. A software
testing technique whereby explicit knowledge of the internal workings of the item being tested
are used to select the test data. Unlike black box testing, white box testing uses specific
knowledge of programming code to examine outputs. The test is accurate only if the tester knows
what the program is supposed to do. He or she can then see if the program diverges from its
intended goal. White box testing does not account for errors caused by omission, and all visible
code must also be readable.
We have adopted a testing method, which is a mix of both white box and black box
testing. For the units we have adopted white box testing. Then we integrated the units into
modules and further into the system. There we adopted black box testing for checking the
correctness of the system
21
6. SECURITY PROCEDURES
22
7. CONCLUSION
23
APPENDIX-A
addCourse(courseId, courseName)
checkIfExist(courseId)
addtoDB(course)
Return Successful
Scenario
Scenario 1: Course gets added successfully.
Scenario 2: Adding the course fails because the course is already in the
database.
24
A:2 Sequence Diagram for assigning courses to students
Department Record
System
stu :=
cou :=getStudent()
getCourse()
Administrator Student
[ if stu != NULL
and cou != NULL]
enroll(stuID, courseID) addCourse(cou)
Return Successful
Return Successful
Scenario
Scenario 1: Student enrolls in the course successfully.
Scenario 2: Enrolling fails because the student is already enrolled in the course.
25
A:3 Sequence Diagram for entering Marks and viewing grade
Department
Instructor Student Record System
EnterMarks
Total calculated
EditMark and stored
Return Successful
Get Marks/Grade
View Marks/Grade
Scenario
Scenario 1: Enter marks/Edit marks successfully.
Scenario 2: Viewing Marks/grade.
26
A:4 Sequence diagram for Course.Material
Department
Instructor Student Record System
Sent_CM/Msg AddtoDB ( )
View_CM/Msg
Sent Msg
addtoDB( )
View Msg
Abbrevations
CM.Course Material
Msg.messages
Scenario
Scenario 1: Sending and viewing course material/messages by instructor.
Scenario 2: Sending and viewing messages by student.
27
WIIMS
Add_course
Add_User
Assign cou_stud
Assign cou_inst
Administrator
Enter_mark
Edit_mark
Send_msg
Post CM
Instructor View_msg
View_msg
Send_msg
View_CM
View_Grade
Student
28
APPENDIX :B
ADMINISTRATOR
29
B:2 Adding instructor form
30
INSTRUCTOR
31
B: 4 View Marks form for instructor
32
STUDENT
33
B:6 Sending message form for student
34
REFERENCE
[1] Ian Somerville. “Software Engineering”. Sixth Edition, Pearson Education Ltd, 2002.
[2] Page Jones. “Fundamentals of Object Oriented design in UML”. Addison Wesley
Longman Pvt Ltd.,2001
[3] Elamsri and Navathe. “Fundamentals of Database Systems”. Pearson Asia Edition, 2000
[4] V.K Jain. ”Java Server Pages and Servlets”. Pearson Asia Edition ,2000.
[5] http://jdstiles.com/javamain.html
[6] http://www.jsptut.com/index.html
[7] Ajesh Kumar P.G. Project Report titled “Web-based Instructional Information
Management System”,S6 MCA,NITC,April 2005
35