Mathematical Teaching Software Systemseniord.ece.iastate.edu/projects/archive/ongo08/SASF... · Web view515-292-5249 [email protected] Jason Wilkinson Computer Engineering

Software Application Support FrameworkStatus Report

Ongo8d

Client:Ames Community Schools

Faculty Advisors:Dr. John Lamont

Professor Ralph Patterson

CprE/EE 492 Team Members:Tim Adkisson, CprE ● Kevin Wendzel, CprE

CprE/EE 491 Team Members:Mark Klein, CprE ● Jason Wilkinson, CprE/ComS

REPORT DISCLAIMER NOTICEDISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge

12 November 2004

Ongo8d Status Report CprE/EE 492 Revision 3.0

of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.

ii


Table of Contents

LIST OF FIGURES..........................................................................................................iii

LIST OF TABLES............................................................................................................iv

LIST OF DEFINITIONS..................................................................................................v

INTRODUCTION.............................................................................................................1Executive Summary...........................................................................................................1

Project Necessity..............................................................................................................1Project Description...........................................................................................................1Results to Date.................................................................................................................1Future Work.....................................................................................................................2

Acknowledgements............................................................................................................4Problem Statement............................................................................................................5

General Problem Statement.............................................................................................5General Solution-Approach Statement............................................................................5

Operating Environment....................................................................................................7Intended Users and Uses...................................................................................................8

Intended Users.................................................................................................................8Intended Uses...................................................................................................................8

PROJECT ACCOMPLISHMENTS AND STATUS....................................................12Previous Accomplishments.............................................................................................12Present Accomplishments...............................................................................................19Future Required Activities..............................................................................................23

All Future Semesters......................................................................................................23Spring 2005....................................................................................................................23Fall 2005........................................................................................................................23Spring 2006....................................................................................................................24Fall 2006........................................................................................................................24

Current Project and End-Product Status......................................................................25Overall Project...............................................................................................................25File CD for Future Semesters........................................................................................25Framework Document...................................................................................................25Status Report..................................................................................................................25

Recommendation for Continued Effort.........................................................................25

DOCUMENTATION OF CURRENT EFFORT AND RESULTS.............................26Project Definition Activities............................................................................................26Research Activities...........................................................................................................26Design Activities...............................................................................................................26Implementation Activities...............................................................................................27Testing and Modification Activities...............................................................................27

RESOURCES AND SCHEDULE..................................................................................28Resource Requirements...................................................................................................28

i


Personnel Effort Requirements......................................................................................28Other Required Resources.............................................................................................29Financial Requirements.................................................................................................30

Schedules..........................................................................................................................31

CONCLUSION................................................................................................................33Lessons Learned...............................................................................................................33Risks and Risk Management..........................................................................................34

Anticipated Risks...........................................................................................................34Anticipated Risks Encountered......................................................................................35Unanticipated Risks Encountered..................................................................................35Changes in Risk Management.......................................................................................35

Project Team Information..............................................................................................36Client Information..........................................................................................................36Faculty Advisor Information..........................................................................................36

Closing Summary.............................................................................................................37References.........................................................................................................................37

APPENDIX A...................................................................................................................38

Appendix B.......................................................................................................................39

ii


List of Figures

Figure 1: Application Framework Integration Diagram.................................................................6Figure 2: Three-Tier Architecture Diagram...................................................................................7Figure 3: Class Diagram...............................................................................................................14Figure 4: Library File Diagram.....................................................................................................15Figure 5: Quizzing Tables Diagram.............................................................................................18Figure 6: Overall Tables Diagram................................................................................................23Figure 7: Gantt Chart....................................................................................................................31Figure 8: Deliverables Schedule...................................................................................................32Figure 9: WinSCP3 Session Screen Example..............................................................................38

iii


List of Tables

Table 1: List of Acronyms and Definitions....................................................................................vTable 2: User Groups and Descriptions...........................................................................................8Table 3: Assumptions and Their Basis............................................................................................9Table 4: Limitations and their Basis................................................................................................9Table 5: Current Feature List........................................................................................................11Table 6: Spring 2004 functionality list.........................................................................................16Table 7: Fall 2004 functionality list..............................................................................................19Table 8: CD Status........................................................................................................................25Table 9: Estimated Personnel Effort (Hours)...............................................................................28Table 10: Actual Personnel Effort (Hours, as of October 31st).....................................................28Table 11: Estimated Personnel Effort for Spring 2005................................................................29Table 12: Estimated Other Required Resources...........................................................................29Table 13: Actual Other Required Resources (as of October 31st)................................................29Table 14: Estimated Financial Budget..........................................................................................30Table 15: Actual Financial Budget (as of October 31st)...............................................................30

iv


List of DefinitionsTable 1 below will help define technical and project-specific terms used throughout this document.

Table 1: List of Acronyms and Definitions

Acronym DefinitionACS Ames Community SchoolsApplication framework

A pseudo top-layer operating system providing applications with a library of common functions and modules

Apache A software product that serves web pages to clients requesting them. Apache can be used in conjunction with PHP in order to produce dynamic web pages that are built and delivered to the requesting client on the fly

CVS Concurrent Version System — a version control system used to keep track of all work and changes in a set of files.

HTML Hyper Text Markup Language — the language used to describe the formatting and presentation of a web page

LAMP A development environment utilizing Linux, Apache, MySQL, and PHPLinux An open-source operating system that is optimized for use as a web

application serverMySQL An open-source implementation of an SQL serverPC-compatible Personal computers that run a Microsoft Windows operating systemOpen-source Software with public copyrightsPHP A recursive acronym for PHP Hypertext Preprocessor. A computer language

that enables Apache web server to dynamically generate HTML documentsSASF Software Application Support Framework — provides standard

functions for use by the educational software applications to store and manage student information within a centralized database

SQL Structured Query Language — a language used to retrieve information from SQL-compliant databases

v


IntroductionThis section will introduce the background information behind the software application support framework and includes an executive summary, acknowledgements, the problem statement, operating environment, intended users and uses, assumptions and limitations, and the expected end product.

Executive SummaryThis section includes a general summary about the framework, including an explanation of need, project overview, results to date, and future potential work.

Project Necessity The Ames Community School (ACS) district has been concerned with the performance of their students’ math problem solving abilities on standardized tests. In addition, the ISU Senior Design team added additional applications to the project with the intention of finding more creative ways to teach students. The Ongo08 senior design team has been dedicated to working on applications to help ACS, including a Mathematical Teaching Software System (MTSS), a world geography application called Globey’s World, and a United States geography program called Uncle Sam’s America (USA). However, for each of these applications, common functionality needs to be created. Each educational software application developed must manage student and other user information and provide a way to only allow authorized access to the applications. There needs to be a common method for teachers to easily create quizzes for the applications. Also, quizzing results must be stored and maintained to make it easy for teachers and parents to track a student’s progress.

Project DescriptionTo meet the functionality needs listed above, a PHP Software Application Support Framework (SASF) is being developed. The SASF will provide standard functions for use by the mentioned educational software applications to store and manage student information within a centralized database. Student access to educational applications will be controlled by the SASF through a web interface. The SASF will standardize the applications, in turn helping teachers track student progress to improve student performance.

Results to DateResults of the fall 2004 team’s efforts include a variety of aspects on the project. The different levels on which the project was worked over has brought great shape to the project and is shown in the listing of items below.

Code RevisionThe quizzing functionality that was designed and created during Spring 2004 was thoroughly tested and validated before being released to the other Ongo08 sub-teams. In addition, several features were added to the quizzing functionality at the request of the other sub-teams. Additional fields were added to the quizzing table that would allow a quiz to both remain private and be controlled by the person who created the quiz. Also, additional global variables were created representing the applications being developed. This allowed for greater commonalities in the table entries being made by the quiz creators.

1


Software ReleasesSeveral changes were made to the way that both Ongo08d released its framework to the other sub-teams and the way the other sub-teams made their applications accessible to the clients. In past semesters, the other sub-teams had to download the framework code from the Ongo08d website, extract and reference that code stored in their own directories, and create their own databases to store their data. This semester, a new method of framework distribution has been defined. All other sub-teams reference the code that is stored in the framework sub-team’s directory. Two code locations exist, one for stable code and one for testing code, and all data is stored in common databases. Also in previous semesters, each sub-team had a different web link to access their application. This semester, a single sign-on page was created which allowed a user to go to one page to access any of Ongo08’s applications, with links to each individual application on that page.

IntegrationIntegration of the framework began September 19th after the framework team’s quizzing training session. This session covered in detail and provided examples on how to use the functions that were part of the quizzing framework. In addition, a separate training session was held on September 12th to educated 491 members on the basics of PHP. All bug fix and additional functionality requests were received by the framework team by October 31st.

Grading FunctionalityThe primary goal for Fall 2004 was to create a set of functions and SQL table entries to allow for the addition, removal, and modification of grading, along with additional functions and SQL tables that would allow all three major tasks of the framework team; authentication/ registration, quizzing, and grading; to be tied together. Based on meetings held in past semesters with the other sub-teams, a list of proposed functions and calls were generated (see Appendix B). From these functions a set of tables was created that holds the information the applications required. These proposed functions and tables were presented to the other sub-teams for approval, and an agreed upon set was completed on October 14th. Coding began that day on the grading functionality and was completed November 4th.

New Testing FunctionsTesting methods for the new release of the framework, were created by the developers of the framework for the framework team to be able to quickly view if the scripts had any errors or issues that could cause the code to become unstable.

New DocumentationNew documentation of the framework was created to be in a format that can be easily updated and maintained in future semesters. Additionally a cookbook was generated from which the software developers (Ongo08 a-c) can read to ascertain how to use a given function. Along with the presently existing deliverables (project plan, project poster, project Power-Point presentation, and a status report) a grading requirements document and a chart detailing all the functionality of quizzing were created. With the addition of these new documents, it was easier to determine where groups were placing their goals and enhanced the application support for the framework.

2


Future WorkSeveral tasks need to be completed in the coming semesters. Large-scale testing of the framework, in which every conceivable issue that could come up in the framework’s usage, needs to be performed. Ongo08a needs a method to have student’s responses to questions converted so that it can be determined if the answer is accurate enough to be considered correct. A database garbage collection utility, which goes through the databases and removes any unreferenced data entries, needs to be created. Authentication needs to be changed to provide a method for logging out. Registration also needs to be amended so that additional fields can be added. A timing feature needs to be created so that individual problems or quizzes as a whole can be timed. A method to classify the difficulty of quizzes/problems also needs to be created. Additional security needs to be built into the quizzing tables so that a user of the system cannot modify or delete quizzes or problems being used by another user. End-user documentation on how to use the framework functionality needs to be created. Developer documentation for the framework needs to be improved and updated. And the framework team also needs to be prepared to handle any other feature requests made by the other sub-teams or the clients in the future.

3


AcknowledgementsThe framework group would like to thank Dr. John Lamont, Professor Ralph Patterson III, and the senior design Ongoing Project Eight for their cooperation and assistance. Allowing the team privileged access to their MTSS, Globey’s World, and USA’s software provided a great deal of insight on how to go about planning and implementing this project. Lastly, thanks go to the project client, the teachers of the Ames Community School District, for their guidance toward the final product.

4


Problem StatementThis section includes both a general problem statement and the general solution-approach statement that will respectively provide a general overview of the problem and the approach that was used to solve it.

General Problem StatementACS is currently looking for a method of development and deployment for an educational application targeted at grades 3-6 to aid them in learning problem solving abilities. In addition, the ISU Senior Design team is looking for a similar method of development and deployment for the two applications they added to the project. Currently, each educational software application must provide a method for quizzing students. Also, the applications must manage student information, grades, and users to make it easier for teachers to track student progress. User access to applications must also be controlled. For example, there needs to be a method at application startup that guarantees that only authorized users can use the application. Furthermore, this method must restrict certain users from certain areas of the application, as students shouldn’t be able to create quizzes and parents shouldn’t be able to see the progress of any student except for their own child.

A PHP software application support framework will be developed to facilitate the future creation of educational software applications, manage student, parent, teacher, and administrative access, and provide tracking of student progress. The SASF will facilitate future development by providing a standard set of PHP functions that can manipulate user information, provide login capability as well as the framework upon which the application will run, and provide support utilities. These functions will simplify application development since each program would no longer be responsible for implementing these actions individually.

General Solution-Approach StatementThe framework will provide a platform for the applications by allowing the applications to make function calls to a standard PHP library. This library will contain methods common to the supported applications. It will interact with a server-side MySQL database where the student information will be kept. Student permissions for the applications will be controlled by the PHP library and access provided through a web interface. Students can login to the system and view a list of available applications. Teachers and parents will be able to monitor student progress through a separate web interface. School administrators will be able to monitor their school’s overall performance. The teacher, parent and school administrator web interfaces will utilize SASF to indicate which applications the student has completed, their resulting scores and overall school performance. See Figure 1 below for a

5


representation of how SASF interacts with the applications.

Figure 1: Application Framework Integration Diagram

6

Student Workstation

Graphical User Interface

Software Engine

PHP Support Framework

MySQL API

Application Specific Libraries

Page Templates

GradesQuizzesUser Information

Application Specific Solution


Operating EnvironmentSASF will exist and run on a Linux server. The PHP framework libraries will provide a set of objects and methods that will aid the focus specific application. This structure will provide a powerful open-standards environment for the web applications. The SASF code will be stored on a server in an environmentally controlled room and accessed on client workstations found primarily in lab environments. All applications built under the PHP framework libraries will use the three-tier architecture model shown in Figure 2 when designing their application.

7


Figure 2: Three-Tier Architecture Diagram

8


Intended Users and UsesThis section identifies the intended users and uses of SASF and the characteristics of each. There is a hierarchy of user levels within the educational software. The specified application interface is personalized depending on the group membership of the authenticated user.

Intended UsersThe intended users of the SASF range over a broad group of people and include:

Developers—Members of the Ongo08 senior design project team and future application designers and maintainters

Computer administrators—School staff in technical positions School administrators – School staff in managerial positions Curriculum coordinators—School faculty in charge of generating course

content Teachers—School faculty directly involved with teaching students

course material Students—Third through sixth graders using the Ongo08 educational

software Parents—Guardians of the students described above Guests—Anyone outside the persons above who have permission to

test the educational software

Intended UsesThe application framework will be run in a web-based environment. Table 2 below shows the access levels of the major user groups.

Table 2: User Groups and DescriptionsUser Group User DescriptionSystem administrators

System administrators will maintain the system the framework is running on and provide technical support to other users.

School administrators

School administrators will use the data to see how students are doing, and compare this to the national average.

Curriculum coordinators

Curriculum coordinators will use the data to see how a certain teaching method worked as compared to the previous tested methods and add general problems to the database.

Teachers Classroom teachers will use the data to see how a particular student is doing, and possibly view the class average. Teachers can also add more student users, parent users, and class-specific problems to the database.

Students Students can view their own scores and run applications.Parents Parents of enrolled students can see their child’s score and the class average.Guests Non-school affiliated visitors can browse example student records and view

class averages. They can also run the applications without being tracked.Developers Software developers can do testing and development of SASF as well as

9


utilize SASF methods.

10


Assumptions and LimitationsThis section provides information about the project assumptions, or engineering inferences, and limitations, or the physical limits imposed by the client or technology.

AssumptionsBelow is Table 3, a table of several assumptions being made with regard to SASF.

Table 3: Assumptions and Their BasisAssumption BasisThe final product will be composed of PHP, HTML, and MySQL code and documentation.

The goal is to build web based applications based on PHP.

The framework will be utilized by web developers to create future educational applications.

The framework does not provide a finished product; rather, it provides code, documentation, and tools for creating finished products.

PHP will continue to be available on the majority of web server platforms.

Historical trends in usage and accelerated growth in PHP development indicate that PHP will exist throughout the scope of this project.

It is expected that a limited number of applications will be running on the framework at one time to prevent overloading the server.

This assumption will allow for simplified application stress and server utilization calculations for this initial release of the framework.

The end product will not utilize proprietary web browser extensions and enhancements.

If the extensions were used, they would destroy the goal of a platform-independent solution.

The total number of users among all participating school districts will be no more than 40,000.

MySQL tables typically are limited to 4GB in size, and each user account can take up to 100KB in size in the table.

The framework must have a high level of stability.

If there are stability issues with the framework, those issues will likely affect the applications.

LimitationsBelow is Table 4, a table of several limitations being made with regard to SASF.

Table 4: Limitations and their BasisLimitation BasisPHP’s object-oriented features are inferior to those in other languages such as C++

PHP is not a true programming language.

There are some known bugs with PHP’s session management modules and version inconsistencies.

Reports and brief research into PHP document some known bugs that the framework will have to work around.

It is impossible to foresee all future applications of the PHP framework.

Historical perspective and rapid developments in the technology sector will

11


bring about new ideas for future applications.

Response time of the PHP framework will be limited to the speed of the internet connection between the client browser and the Linux server.

The framework must communicate with the database on the server to obtain user information, quiz questions, etc.

The Apache web server, the MySQL database or the PHP parser may contain unintended privilege escalations during authentication, data corruptions, buffer overflows or cross site scripting attacks.

These risks are known to unexpectedly appear in any software regardless of the server, database or server-side scripting chosen.

Expected End Product and Other DeliverablesThe eventual end product will be a library of PHP code consisting of class definitions, functions, and table references. The end product will also include MySQL database table skeletons. The framework library will present a common framework for web-based educational application development. It will also include functionality for authenticating application users, working with quizzes, and tracking grades and student progress. Developers will be able to utilize the framework to build highly innovative and customizable applications for web-based training, instruction, assessment, and other forms of education. The framework will be highly customizable and will be open to changes, additions, or corrections. The key to this end product will be detailed documentation and further development. The framework is a low-cost alternative to traditional specialized educational software. Thus, it should provide for an improved return on investment for both existing and future computer networks. The savings incurred should allow schools to further enhance or expand their technology base throughout the school system.

Table 5 on the next page is a table of scheduled features for the entire team and priorities associated with each. This semester, the main deliverable will be code that allows for storage and retrieval of grades generated by quizzes. Security will be incorporated so that only authorized users are able to retrieve these grades.

12


Table 5: Current Feature List

Feature List MTSS GW USA SASFAdding Additional Registration Fields (class, teacher etc.) N/A N/A N/A LAnswer Conversion and Translation Utilities N/A N/A N/A MApplication HTML to PHP Transition (GW) N/A M L N/AApplication Removing Javascript M L L N/AAutomatic Database Updating N/A M N/A N/ACleaning Server Software M M M MCode Reviews / Fix H M N/A HDocumentation Update H H N/A HEducational Performance Test (Software vs Teach) L L L N/AFramework Authentication Implementation H H H N/AGames N/A L N/A N/AGrading Functionality Creation N/A N/A N/A HGrading Functionality Implementation L L L N/AGrading Functionality Testing L L L MImage Repository Centralization N/A L L N/ALarge Scale Testing N/A N/A N/A LMath Problems L L N/A N/AOff-Site Backup Management L N/A N/A HOperational Environment Research (School Visit) H H H N/APrioritize feature matrix N/A N/A N/A MProblem Solving Algorithm H L L N/APrototype Testing M M M HQuizzing and Problem Data Migration H L L N/AQuizzing Functionality Implementation M M N/A HQuizzing Functionality Testing M L N/A HSecuring Authentication N/A N/A N/A LStylesheet Integration L H H N/AStylesheet Standardization L H M N/ATest Server Upgrade M M M MUnited States Map Changes N/A L N/A N/AUser Progress Tracking L L L H

MTSS = Mathematical Teaching Software System (8a) L =LowGW = Globey’s World (8b) M =MediumUSA = Uncle Sam’s America (8c) H =HighSASF = Software Application Support Framework (8d) N/A =Not Applicable

13


Project Accomplishments and StatusThis section identifies the work that has been accomplished in the past, the work accomplished on this project this semester, the required activities for future semester teams, the current project and end product status, and recommendations for continued effort.

Previous AccomplishmentsThis Ongo08d sub team was initially formed in the fall of 2003. Previously, the May03-01 team, a single-year project team, was responsible for the framework. They left behind a variety of files that provided some insight into how the framework could be approached but no working prototype or initial release of the framework. The fall 2003 semester’s team checked their files into CVS on the sd6 server as a repository named Mercury. The Ongo08d group does not know the successes and failures of this project team. After which the fall 2003 team made several important achievements.

The accomplishments of the Ongo08d sub team for fall 2003 include: Project initialization

o The group tracked down and obtained the existing skeleton code from the May03-01 sub team.

o The group reviewed the skeleton code and determined that is was not useable as a first release of the framework.

Feature list prioritizationo The group received a list of features from the other three Ongo08 sub teams and

discussed possible features to be implemented in the framework with the team’s advisors and generated a prioritized feature list. This list includes everything that eventually needs to be implemented in the framework and not just the features to be implemented this semester. The following is the feature list:

1.) Basic authentication functionality for the users2.) Registration functionality to add/delete/modify users in database3.) Grade books only teachers would be able to view 4.) Ability to modify/add/delete questions by the teacher5.) Quizzing functions with a library of math based questions6.) Teacher/parent able to login and view student's progress7.) Timing feature for quizzes & documentation of number of tries8.) Different classifications of problems (different difficulty levels)

Creation of CVS repositoryo The group placed the repository on the sd6.eng.iastate.edu in the

/home/framework foldero The group checked the May03-01 skeleton code into the repository as Mercury.o The group created a new folder for the current semester’s files, called Venus.o Appendix A contains further information on accessing the sd6.eng.iastate.edu

server to store or retrieve files pertinent to the Ongo08 sub team by using the WinSCP3 application.

Creation of authentication library (Figure 4)

14


o The group created a library with methods for authenticating users in the applications. The following method can be used by the applications to authenticate users:

1.) authenticate(MySQL connection, string username, string password) Creation of registration library (Figure 4)

o The group created a library with methods for registering users with the system. The following methods can be used to register, unregister, or update users with the system:

1) registerUser(connection, object user)2) unregisterUser(connection, string username)3) updateUser(connection, string username, object newUser)

2.) Creation of User Class (Figure 3)3.) Allows for the authentication and registration of all users. Without this

class neither of these libraries would function. Creation of test cases for the above two libraries

o The group created test cases for both the authentication and registration libraries. The test cases are described further in the “Testing and Modifications” section found later in this document

Documentationo The group created instructions on how to access the framework files.o The group created an overall framework document, included in a separate

document, to be given to the other Ongo08 sub teams as a reference for the framework libraries. The document is included on the CD to be delivered to Dr. Lamont and Professor Patterson.

Fall 2003 Semester Successes: The team created a working release of the framework with libraries (seen below in figure

4) for user authentication and registration. This was successful because the team members had to work together to coordinate how the code was to be written (to ensure consistency) as well as how the modules were to work together.

The team worked hard to create useful documentation for subsequent semesters so the groups can immediately begin work.

Fall 2003 Semester Failures: The team was disappointed in the initial stages of the project. Several obstacles were hit

that included not being able to track down the previous team’s code in a timely manner and not knowing PHP; thus the team got a late start with the project.

15


Figure 3: Class Diagram

16


Figure 4: Library File Diagram

17


The accomplishments of the Ongo08d sub team for spring 2004 include: Project initialization

o Obtained materials from the previous term, fall 2003.o Reviewed PHP and written framework code for new members.o Taught PHP to new members of application groups.o Taught integrating framework methods.

Feature list prioritizationo The group received a list of precompiled features from the previous framework

team. Based upon this previous prioritized feature list an updated copy is seen below. This list includes everything that eventually needs to be implemented in the framework and not just the features to be implemented this semester. Table 6 below is the feature list:

Table 6: Spring 2004 functionality list

# Functionality Completed1 Basic authentication functionality for the users fall 20032 Registration functionality to add/delete/modify users in database fall 20033 Grade books only teachers would be able to view TBA4 Ability to modify/add/delete questions by the teacher spring 20045 Quizzing functions with a library of math based questions spring 20046 Teacher/parent able to login and view student's progress TBA7 Timing feature for quizzes & documentation of number of tries TBA8 Different classifications of problems (different difficulty levels) TBA

Collection of necessary quizzing functionalityo The group met and discussed with the application groups (Ongo08 a-c) to

determine the methods required/requested. o Upon meeting with all three groups the framework team found the base set of

functions necessary to implement every action requested by all applications. Database requirements document

o From the discussions with the groups, the framework team created and revised a list of functions, SQL tables, and uses for all actions requested.

o The list was distributed to all groups and was revised based upon needs and wants the groups expressed.

o The final database requirements documented was completed and distributed to the application developer groups.

Creation of quizzing libraryo The group created a library with methods for adding, removing, and modifying

quizzes/questions/images. o The library is tested and is now found in the current stable distribution of the

framework. Creation of SQL database tables

o The group created a series of SQL tables to store data within for quizzing functionality.

o These tables include (as shown in Figure 5):

18


1.) Quiz Table2.) Quiz Problems Table3.) Problems Table4.) Problem Choices Table5.) File Catalog Table

Creation of test cases for the quizzing libraryo The group created test cases for the quizzing library to allow for stability and

error testing.o These functions can be found within the CVS repository under

/home/framework/repository/venus/test Previous library code improvements

o Improvements were made to the existing library code to allow for greater flexibility and ease of implementation.

1.) By storing the server address into the globals file, it allowed for greater flexibility within the authentication and registration library functions

If it was necessary to change the server name A user would not have to go through each file to change the server

name.o Improved authentication to work properly

Documentationo The group created a project focus matrix to determine every groups goals and

focus for a given term. The matrix is found on page 11.o The group created an overall framework document, included in a separate

document, to be given to the other Ongo08 sub teams as a reference for the framework libraries. The document is included on the CD to be delivered to Dr. Lamont and Professor Patterson.

Application supporto The group initiated and supported the groups during their integration of the

framework into their applications.

Spring 2004 Semester Successes: The team created a working release of the framework by adding the new quizzing library

to the existing libraries for user authentication and registration. This was successful because the team members had to work together to coordinate how the code was to be written (to ensure consistency) as well as how the newer and older modules were to work together.

The team worked to create useful documentation for subsequent semesters so the groups can immediately begin work.

The team worked well together to create documentation and support the application groups in their integration of the authentication and registration routines.

19


Spring 2004 Semester Failures: The team was surprised to find that they had now attained rights to administrate the

server. o In order to successfully administrate the server, project duties had to be

abandoned. A conscious decision was made to spend the majority of the time working on the project the team had set out to do.

Application team integration of the framework (venus)o A hard deadline of March 26th was set to integrate the framework.o A request by the framework team to start as soon as possible was made early on in

the semester.o An abundance of questions were made near the final deadline date despite the

request.

Quiz

PK QuizID

QuizName QuizSubject QuizOwner QuizWeight

QuizProblems

PK QuizIDPK ProblemNumber

ProblemID ProblemWeight

Problems

PK ProblemID

Category SubCategory Difficulty ProblemType QuestionText RandomizingAllowed IsSubProblem SubProblemOwner AllowCalculator SubProblemNumber FileID EvaluationType AllowedDeviation Answer

ProblemChoices

PK ProblemIDPK ChoiceNumber

ChoiceText ChoiceFileID

FileCatalog

PK FileID

Subject Category FileName FileDescription IsLink FileType Link BinaryData

Figure 5: Quizzing Tables Diagram

20


Present AccomplishmentsThe accomplishments of the Ongo08d sub team for fall 2004 include:

Project initializationo Obtained materials from the previous term, spring 2004.o Reviewed PHP and written framework code for new members.o Taught PHP to new members of application groups.o Taught integrating quizzing framework methods.

Feature list prioritizationo The group received a list of precompiled features from the previous framework

team. Based upon this previous prioritized feature list an updated copy is seen below. This list includes everything that eventually needs to be implemented in the framework and not just the features to be implemented this semester. The following is the feature list:

Table 7: Fall 2004 functionality list

# Functionality Completed1 Basic authentication functionality for the users fall 20032 Registration functionality to add/delete/modify users in database fall 20033 Basic quizzing functionality for students and teachers spring 20044 Basic quiz grading functionality for students fall 20045 Functionality to relate authentication, quizzing, and grading into

one large systemfall 2004

6 Improve authentication so it is more secure and can store a greater number of user fields

TBA

7 Answer conversion functionality for text answers TBA8 Timing functionality for quizzes TBA9 Garbage collection utility to remove unreferenced data from tables TBA10 Additional security to guarantee that users can not modify

quizzes/problems of other usersTBA

11 Optimize code so that it uses less resources TBA12 Large-scale testing to guarantee that framework will work in

multiple environments under multiple conditionsTBA

13 Improved developer documentation TBA14 End-user documentation TBA

Collection of necessary grading functionalityo The group met and discussed with the application groups (Ongo08 a-c) to

determine the methods required/requested. o Upon meeting with all three groups the framework team found the base set of

functions necessary to implement every action requested by all applications. Database requirements document

o From the discussions with the groups, the framework team created and revised a list of functions, SQL tables, and uses for all actions requested.

21


o The list was distributed to all groups and was revised based upon needs and wants the groups expressed.

o The final database requirements documented was completed and distributed to the application developer groups.

o This document is found in Appendix B Creation of grading/overall library

o The group created a library with methods for adding, removing, and modifying the process of keeping track and recalling results of a quiz that a student took.

Creation of SQL database tableso The group created a series of SQL tables to store data within for grading/overall

functionality.o These tables include (as shown in Figure 6):

1.) School2.) Administrator3.) Course Coordinator4.) Teacher5.) Parent6.) ParentsToStudents7.) Student8.) SectionsToStudents9.) Section10.) SectionQuizzes11.) QuizRecords12.) ProblemsAnswered13.) More information can be obtained from Appendix B

Creation of test cases for the quizzing libraryo The group created test cases for the grading library to allow for stability and error

testing.o These functions can be found within the CVS repository under

/home/framework/repository/venus/test Previous library code improvements

o Improvements were made to the existing library code to allow for greater flexibility and ease of implementation.

1.) An improved method of obtaining errors from the framework was created. In particular, the ability to return an error saying exactly what value passed into a framework function was invalid was added.

2.) A quizCreator field was added to the quiz table to allow the creator of the quiz to be remembered.

3.) A quizPrivate field was added to the quiz table to allow a quiz to not be viewable by anyone except for the owner and creator of the quiz.

4.) Additional global variables, representing the different applications, were added to the globals file, allowing a more standard way of storing the subject of a quiz and problem.

5.) A getUserByCriteria method, which allowed searching for users, was created.

Documentation

22


o The group updated a project focus matrix to determine every group’s goals and focus for the given term. The matrix is found on page 11.

o The group created an overall framework document, included in the appendices of this status report and also existing as a separate document, to be given to the other Ongo08 sub teams as a reference for the framework libraries. The document is located in Appendix B and is also included on the CD to be delivered to Dr. Lamont and Professor Patterson.

Application supporto The group initiated and supported the groups during their integration of the

quizzing framework into their applications.

Current Semester Successes: The team created a new grading library. This was successful because the team members

had to work together to coordinate how the code was to be written (to ensure consistency) as well as how the newer and older modules were to work together.

The team also created a library which would allow for grading, quizzing, and user authentication libraries to all be tied together in one big relational database.

The team worked hard to create useful documentation for subsequent semesters so the groups can immediately begin work.

The team worked well together to create documentation and support the application groups in their integration of the quizzing routines.

Current Semester Failures: The sub-teams failed to specifically define what types of features would be included in

the quizzing framework and what types wouldn’t. This resulted in disagreements between the different sub-teams.

Several activities were not started as soon as they should have. As a result, there was a pileup of work during key dates throughout the semester.

23


Figure 6: Overall Tables Diagram

24


Future Required ActivitiesThis section includes information about what is required in terms of activities and deliverables for future sessions. It is divided into separate semesters and looks ahead one year. The summary does not include Gantt charts for work as the exact dates of each activity and deliverable should be decided upon by the team. Estimated resources should closely match the exact resources occurring this semester and are shown in the resources section of this document.

All Future Semesters Review existing code

Objective: To look at code that was written by the previous groupApproach: Review what has been written and what its purposes areResults: To have members learn what coding has been done and how it was done

Continue code documentationObjective: To lower the learning curve of using the frameworkApproach: Follow the format of the framework documentation as shown in Appendix B and update the documentation accordingly throughout the semesterResults: More complete documentation of the framework

Support feature list for Ongo08Objective: To support the required features for the existing applicationsApproach: Use the PHPBB application to have other sub teams file feature or support requests to the team. The team will then delegate the tasks to be done if the feature is accepted for the framework, and propose a deadline of the next stable release with any accepted feature.Results: Future and ongoing support of new common features between applications

Write test cases for new codeObjective: To test the reliability and stability of the codeApproach: Each member performs their own testing on a selection of the code (which they have not written) to test for any possible bugs in the code.Results: The framework should be more stable and reliable after exhaustive testing

Spring 2005Accomplish the above activities for “all semesters” as well as begin working on more items in the feature list presented in the present accomplishments sections:

Improve authentication so it is more secure and can store a greater number of user fields Answer conversion functionality for text answers

Fall 2005Accomplish the above activities for “all semesters” as well as begin working on more items in the feature list presented in the present accomplishments sections:

Timing feature for quizzes & documentation of number of tries Garbage collection utility to remove unreferenced data from tables

25


Spring 2006Accomplish the above activities for “all semesters” as well as begin working on more items in the feature list presented in the present accomplishments sections:

Additional security to guarantee that users can not modify quizzes/problems of other users

Optimize code so that it uses less resources

Fall 2006Accomplish the above activities for “all semesters” as well as begin working on more items in the feature list presented in the present accomplishments sections:

Large-scale testing to guarantee that framework will work in multiple environments under multiple conditions

Improved developer documentation

26


Current Project and End-Product StatusThis section will detail the status of the overall framework project as well as the subcomponents within each of the three main deliverables mentioned in the end product description section described previously.

Overall ProjectThe tables below describe the status of the prioritized feature list encompassing the framework goals. These tables will need to be updated and reprioritized on a semester-by-semester basis to meet the needs of the future teams.

File CD for Future SemestersTable 8 below describes the status of the CD and its contents that will be delivered to the project advisors to be given to next semester’s team.

Table 8: CD Status

Deliverable StatusOverall CD Awaiting completion of other tasksProject plan CompletedProject poster CompletedIRP presentation In progress, updated version by the end of the semesterStatus report Awaiting initial correctionFramework document OngoingFramework files In progress, completed by the end of the month

Framework DocumentThe framework document is an ongoing document that will be updated and delivered to the Ongo08 sub teams each semester. The current version contains descriptions of the authentication and registration libraries, quizzing libraries, grading libraries, installation instructions, references, globals, and other information.

Status ReportThis report contains information in the appendices that will be pertinent for getting next semester’s team off to an early start. All sections mentioned in the end-product description are up to date.

Recommendation for Continued EffortThree possible recommendations exist for the next phase of this ongoing project:

1) Continue the project as originally envisioned2) Alter the range of the project in a logical direction before continuing3) Abandon the project

The Ongo08d sub-team has decided to recommend the first alternative: continuing with the project as originally envisioned. The main goal of the project; implementing authentication, quizzing and grading functionality; has been completed and appears to be working correctly. However, several improvements still need to be made so that the framework can meet all application and client requirements.

27


Documentation of Current Effort and ResultsThis section contains a description of the project definition, research activities, design activities, implementation activities, and testing and modification activities that occurred during the semester. Categories of activities where no significant effort was put forth will not be elaborated upon.

Project Definition ActivitiesThe project definition was not redefined this semester. Some effort by all team members was put into understanding the original project definition and elaboration upon it by the creation of the prioritized feature list previously mentioned.

Research ActivitiesResearch activities this semester included:

1) Meeting with groups to discuss current application needs.a. The needs of the group were documented.b. The current application programming standards were documented.

2) Based upon the feedback from the groups, a hierarchy of functions and database tables were devised.

a. A documented was created to outline the framework developers’ ideas and thoughts on how to structure the quizzing functionality.

b. The document can be found in Appendix B.3) More feedback was attained from the application groups.

a. Minor adjustments were made to complete satisfaction of the application developers.

Design ActivitiesDesign activities this semester included:

1) Restructuring the quizzing database SQL tables to support several new features.a. An additional table, “Problem Answers”, was added to address a feature requested

by other sub teams.i. This table makes it possible to implement randomization of multiple select

checkbox problems. The current framework only supported randomization of multiple choice problems.

ii. The “Answer” column of “Problems” became obsolete and was removed.b. Auto-numbering fields were added to “Quiz Problems” and “Problem Choice”

tables to address the dangerous possibility of duplicate records.i. Several sub teams requested this as a safeguard although it was not

deemed a risk by the framework team.2) Creating a hierarchy of SQL tables to hold the information processed and collected from

the applications for grading.a. All the information collected by the applications will be stored into these series of

tables.i. “Schools” table

ii. “Teachers” table

28


iii. “Parents” tableiv. “Parents to Students” tablev. “School Administrators” table

vi. “Sections” tablevii. “Students” table

viii. “Course Coordinators” tableix. “Section Students” tablex. “Section Quizzes” table

xi. “Quiz Records” tablexii. “Problems Answered” table

b. The information will be stored and retrieved from these tables.c. The tables are linked through fields within each table.

3) Creating a multitude of functions to handle the requests of the application developers.a. Functions to address adding, retrieving, removing, modifying and linking

students, teachers, quiz records, student grades and parent information.b. The functions were approved by each application developer group.

Implementation ActivitiesImplementation activities this semester included:

1) Previous library integration into current applications.a. The framework team demonstrated the library code to be used to the application

developers on September 19th.b. A hard deadline of October 31st was set to have any feature requests or bug fixes

sent to the framework team.c. Until that point, the framework team would do anything to help them integrate the

library.2) Creating of a database requirements document for the grading functions.

a. All the tables, functions, and uses were written to explain to the application developer how the tools can / are used.

b. The developers could then begin implementing prior to the final release of the code.

Testing and Modification ActivitiesTesting activities this semester included implementing test cases and test scenarios by generating a list of the dependencies for a given library file using the PHP command, "get_included_files." After a list of dependencies was created, another list was created that displayed every function in the library set. With a list of functions, a series of tests were designed to challenge the library in specific areas of interaction and data management. Based upon each test, an output was displayed. Each test was run through html using the PHP parser in order to have any easy manner to test the code; thus the team did not have to know PHP or UNIX to test the libraries’ capabilities.

No major issues were found during the testing phase. Several small issues did come up though, including incorrect parameters being passed into functions and invalid functions being used. All issues were corrected and updated code was loaded into CVS.

29


Resources and ScheduleThis section includes estimates of project resources and the project schedule.

Resource RequirementsThe estimated resource requirements section is composed of the following three components: personnel effort requirements, other resource requirements, and financial requirements.

Personnel Effort RequirementsTable 9 below shows the estimated effort given by each team member during the fall 2004 semester. The attributes of the table and their descriptions include:

Meetings – Time spent in meetings with faculty advisors, client contacts, or other team members.

Project reporting – Time spent working on project documentation, poster, presentation, and weekly status reports.

Project initialization – Time spent doing preliminary work on the project and learning PHP.

Project development – Time spent going through existing code, writing test cases, and creating a feature list.

Overall –Total anticipated time spent on the project.

Table 9: Estimated Personnel Effort (Hours)

Member Project Reporting Project Development OverallPrevious Sessions 520 260 760Tim Adkisson 55 30 85Mark Klein 55 25 80Kevin Wendzel 70 20 90Jason Wilkinson 50 35 85Total 750 370 1120

Table 10 below shows the actual effort expended by each team member during the fall 2004 semester. The attributes of the table are the same as in the table above. The team leader monitored time expenditures by each member throughout the semester and adjusted member assignments accordingly to try to maintain equality.

Table 10: Actual Personnel Effort

Member Project Reporting Project Development OverallPrevious Sessions 455 258 713Tim Adkisson 45 29 74Mark Klein 36 32 68Kevin Wendzel 75 44 119Jason Wilkinson 39 32 71Total 650 395 1045

30


Table 11 below show the estimated effort necessary for the spring 2005 semester. The attributes for the table are the same as in the two tables above. These estimates are based on the actual time spent this semester by the team.

Table 11: Estimated Personnel Effort for Spring 2005

Member Project Reporting Project Development OverallPrevious Sessions 620 335 955Current Session 248 115 363Total 868 450 1318

Other Required ResourcesTable 12 below shows the estimates of other required resources during the fall 2004 semester. “Other required resources” include items such as parts and materials required to conduct the project. The attributes of the table and their descriptions include:

Resource—A description of the resource Team Hours—Total team hours dedicated to the resource Other Hours—Non team hours dedicated to the resource Cost—Cost of the resource, not including man-hours

Table 12: Estimated Other Required Resources

Resource Team Hours Other Hours CostPrevious Sessions 24 0 $90.00Printing of Poster 12 0 $45.00Printing of Project Plan 2 0 $5.00Printing of Status Report 2 0 $5.00Total 40 0 $145.00

Table 13 below shows the actual figures for other required resources during the fall 2004 semester.

Table 13: Actual Other Required ResourcesResource Team Hours Other Hours CostPrevious Sessions 20 0 $90.00Printing of Poster 8 0 $50.00Printing of Project Plan 2 0 $5.30Printing of Status Report 2 0 $5.30Total 20 0 $150.60

31


Financial RequirementsTable 14 below shows the estimated financial budget during the fall 2004 semester. The budget includes items such as parts and materials required to conduct the project, and also estimated labor costs based upon departmental senior undergraduate wages. The attributes of the table and their descriptions include:

Item: A description grouped into categories of parts and materials and Labor W/O labor: Cost of the item not figuring in labor charges With labor: Cost of the item figuring in labor charges

Table 14: Estimated Financial Budget

Item W/O Labor With Labor

Parts and Materials Previous Sessions $90.00 $90.00 Poster $45.00 $45.00 Project Plan $5.00 $5.00 Status Report $5.00 $5.00

Subtotal $145.00 $145.00Labor at $10.50 per hour Previous Sessions $7980.00 Tim Adkisson $892.50 Mark Klein $840.00 Kevin Wendzel $945.00 Jason Wilkinson $892.50

Subtotal $11550.00

Total $145.00 $11695.00

Table 15 below shows the actual financial budget during the fall 2004 semester.

Table 15: Actual Financial Budget

Item W/O Labor With Labor

Parts and Materials Previous Sessions $90.00 $90.00 Poster $50.00 $50.00 Project Plan $5.30 $5.30

Subtotal $145.30 $145.30Labor at $10.50 per hour Previous Sessions $7486.50 Tim Adkisson $777.00 Mark Klein $714.00 Kevin Wendzel $1249.50 Jason Wilkinson $745.50

Subtotal $100972.50

Total $145.30 $11117.80

32


SchedulesFigure 7 below show a timeline of events for Ongo8d. The first chart references the activities performed during the semester, while the second chart references the project deliverables. There are two lines for each item in the chart: the first line is the estimated time for the activity or deliverable, while the second line is the actual time spent on the activity or deliverable.

For the most part, there are no major discrepancies between the estimated and actual timeline. The team ended up dividing up the work so that they were able to start preparation for the quizzing training earlier than anticipated. Requests for assistance with the implementation of the current framework came in later than expected. The team was able to complete a first draft of the grading documentation ahead of schedule, and so they were able to start and complete grading a week ahead of time. The Linux server has not turned out to be a problem and so no maintenance has been necessary for it since early October.

Figure 7: Gantt Chart

33


There are no major discrepancies for project deliverables, as demonstrated in Figure 8 below. Slight variations in the start times of the various deliverables did occur, as can be seen in the start times of the project poster, classroom presentation, and the status report. The variations were mostly minor and involved only a shift of a few days.

Figure 8: Deliverables Schedule

34


ConclusionThis section includes lessons learned, risks and risk management, project team information, a project summary, and the project references. Appendices A and B follow the project references.

Lessons LearnedThis senior design project has presented many challenges, obstacles, frustrations, and learning opportunities for the team members. At the end of the semester, team members were left with a lot of new skills and valuable lessons. A brief summary of some of the team’s most valuable lessons follows.

Things that went well: The team was able to break up tasks among team members to lighten the work load for

single individuals, ensure that all team members were involved in the project, and give members the chance to learn new skills.

The team used source control (CVS) to manage files, providing a much easier and more efficient way to share and store the most updated versions of the code.

The team created a new working release of the framework with libraries for grading, thereby learning coordination and teamwork.

The team worked hard to create useful documentation for subsequent semesters so future groups can make more progress early in the semesters.

The team worked diligently to provide quality support for the application developer teams through meeting and documentation.

The team organized all files and code releases into a common location and released a CD for future teams to increase productivity.

Things that did not go well: All team members were responsible for everything, leading to an increased work load for

all team members and the inability to focus on one task to improve the quality of it. The team requested the other teams get started on integration as early as possible but

many groups were only requesting help late in the semester, even after the deadline for requesting help had past.

Technical knowledge gained by the team:

The team learned about PHP coding standards. The team learned how to administrate a Linux web server. The team learned about MySQL coding standards and proper database design. The team learned about source control tools such as CVS, and how to organize source

code versions in a multiple developer environment. The team learned how to structure SQL tables according to the developer’s requests.

Non-technical knowledge gained by the team: The team learned about how important it is to spend the initial time of a project to

generate a complete project plan and schedule. The team learned the importance of documentation, especially in an ongoing project

where future students will need to reuse and enhance the current team’s work.

35


The team learned how to communicate effectively with other developers. The team learned how to negotiate and compromise between clients and other teams.

What the team would do differently if given the ability to start over: Responsibility would have been better distributed amongst the team members. The team would redesign the quizzing and authentication functionalities to take into

account several vulnerabilities and design issues found during development of the grading functionality.

Risks and Risk ManagementThis section details the potential risks that were anticipated at the beginning of the semester, the anticipated risks that were encountered during the semester, the unanticipated risks that were encountered during the semester, and finally the resultant changes that were made to risk management as a result of encountering unanticipated risks.

Anticipated Risks Risk: The computer with the project’s software is stolen, it crashes, or the software is

maliciously tampered with or otherwise modified.Mitigation: Since the project is entirely software, it is imperative that the source files are

kept secure. In addition to limiting access to the machine to Ongo08 group members via user permissions on the Linux server, the source code and databases will be backed up regularly offsite.

Risk: Due to unforeseen circumstances, a group member leaves the project.Mitigation: The team has four members, so in the event that a team member is lost, the remaining members will shoulder the increased workload. If the person leaving were a critical member, the team would work with him/her to ensure that his/her knowledge and responsibilities were adequately disseminated among the remaining group members.

If more than one group member must leave the team, the team will decide whether a member from another project group could volunteer for double duty or switch groups all together to maintain proper productivity levels.

Risk: Code modification results in damaged and irreparable framework functionality.Mitigation: CVS will be used to update and combine code for the SASF. Functions pertinent

to this risk are the following:Archive - Provides a rollback from the current project all the way to the first version since CVS

began.Version Numbers - Provides a tag to each version created for testing and rollback purposes.

36


Risk: The other groups request certain elements of the framework be implemented differently or want additional functionality not originally specified.

Mitigation: The group will make an effort to keep members of the other groups informed with the progress and abilities of the project. The other groups are currently satisfied with the direction and feature set of the proposed and partially implemented software. Additional requests will be considered and fulfilled if the project leader deems enough time exists to add the requested parts while still maintaining enough time for quality control, testing, and debugging.

Risk: The technical approach fails.Mitigation: The group will need to determine cause of failure and redefine the technical

approach to compensate. If the failure is due to server problems, other server platforms may be investigated.

Risk: The testing methods fail.Mitigation: The group will need to determine the cause of the failure and redesign the

testing structure accordingly. This might require rewriting scripts to be more structurally sound instead of being efficient.

Anticipated Risks EncounteredThe only anticipated risk that took place was that other sub-teams did indeed make requests for additional functionality. It was decided by the team leader that some requests that didn’t require much time to implement (such as additional fields in the quiz table) could be implemented during the same semester. Other features (such as the ability to search for users) would be coded this semester but not released until next semester. And still other features (such as logout functionality and increased quiz security) were determined to be too complex to be done this semester and placed on the list for future semester activities.

Unanticipated Risks EncounteredNo unanticipated risks were encountered this semester. Changes in Risk Management As no unanticipated risks were encountered this semester, no changes have been made to the way the group manages risks. The anticipated risks mentioned above will still be applicable to future semesters.

37


Project Team InformationClient InformationAmes Community SchoolsAdministrative Offices1921 Ames High DriveAmes, IA 50010Phone: 515-268-6600

Faculty Advisor InformationDr. John Lamont324 Town EngineeringAmes, IA 50011-3230Phone: 515-294-3600Fax: [email protected]

Professor Ralph Patterson, III326 Town EngineeringAmes, IA 50011-3230Phone: 515-294-2428Fax: [email protected]

CprE/EE 492 Member InformationTim AdkissonComputer Engineering4733 Toronto St. #101Ames, IA [email protected]

Kevin WendzelComputer Engineering2136 Frederiksen Ct.Ames, IA [email protected]

CprE/EE 491 Member InformationMark KleinComputer Engineering614 Billy Sunday Rd #107Ames, IA [email protected]

Jason WilkinsonComputer Engineering / Computer Science6214 Frederiksen Ct.Ames, IA [email protected]

38


Closing SummaryThis project will provide the framework for current and new applications to be built for the ACS client. This framework will aid in the development of new teaching software by increasing the software’s reliability and development speed. The team has provided a CD containing all necessary documentation, semester deliverables, code, and testing methods to aid next semester’s team in creating a highly functional next release of the framework.

ReferencesThe following references were or will be utilized by the Ongo08d team:

The PHP website <http://www.php.net> The MySQL website <http://www.MySQL.org> Eclipse <http://www.eclipse.org> WinSCP3 <http://winscp.sourceforge.net/eng/download.php>

39


Appendix AAppendix A includes information on how to use WinSCP3 to remotely access the framework files and is written in the form of step-by-step instructions.

Using WinSCP31) Go to http://winscp.sourceforge.net/eng/download.php and download the latest version of the WinSCP3 software application.

2) Upon installation, open the application, click on new, and type in the following information:Hostname: sd6.eng.iastate.eduUsername: frameworkPassword: ******** Protocol: SFTP (Allow SCP fallback)See figure 9 below for an application screen example.

Figure 9: WinSCP3 Session Screen Example

3) Click on Stored sessions after the above information has been entered. This action will save the session so the information does not need to be reentered login.

4) Once authenticated, open the repository folder, then Venus, or whatever the current release of the framework is.

40

http://winscp.sourceforge.net/eng/download.php


Appendix BAppendix B is the grading framework documentation delivered to the other Ongo08 sub teams. It contains an overview of the grading functionality, installation instructions, and descriptions of globals, functions, libraries, and references. It is assembled in such a way as to provide an easily updated and maintained format for future teams.

41

Software Application Support Framework

Grading Database Requirements DocumentOngo8d

Client:Ongo08 Sub Teams

Faculty Advisors:Dr. John Lamont

Professor Ralph Patterson

CprE/EE 492 Team Members:Tim Adkisson, CprE

Kevin Wendzel, CprE

CprE/EE 491 Team Members:Mark Klein, CprE

Jason Wilkinson, CprE/ComS

28 September 2004

Table of Contents

Problem Statement..........................................................................................................45General Problem Statement...........................................................................................45General Solution-Approach Statement..........................................................................45

FUNCTION DEFINITIONS...........................................................................................46School Functions..............................................................................................................46

getSchoolsByCriteria.....................................................................................................46getSchool........................................................................................................................46addSchool.......................................................................................................................46updateSchool..................................................................................................................46deleteSchool...................................................................................................................47

Administrator Functions.................................................................................................48getAdministratorsByCriteria..........................................................................................48getAdministrator............................................................................................................48addAdministrator...........................................................................................................48updateAdministrator......................................................................................................48deleteAdministrator........................................................................................................49

Coordinator Functions....................................................................................................50getCoordinatorsByCriteria.............................................................................................50getCoordinator...............................................................................................................50addCoordinator..............................................................................................................50updateCoordinator..........................................................................................................50deleteCoordinator...........................................................................................................50

Teacher Functions...........................................................................................................51getTeachersByCriteria...................................................................................................51getTeacher......................................................................................................................51addTeacher.....................................................................................................................51updateTeacher................................................................................................................51deleteTeacher.................................................................................................................51

Parent Functions..............................................................................................................52getParentsByCriteria......................................................................................................52getParent........................................................................................................................52addParent........................................................................................................................52updateParent...................................................................................................................52deleteParent....................................................................................................................52

ParentsToStudents Functions.........................................................................................53getStudentsOfParent......................................................................................................53getParentsOfStudent......................................................................................................53deleteParentToStudent...................................................................................................53addParentToStudent.......................................................................................................53

Student Functions............................................................................................................54getStudentsByCriteria....................................................................................................54getStudent......................................................................................................................54addStudent......................................................................................................................54updateStudent.................................................................................................................54

deleteStudent..................................................................................................................54SectionsToStudents Functions........................................................................................55

getStudentsInSection......................................................................................................55getSectionsOfStudent.....................................................................................................55deleteSectionsToStudents..............................................................................................55addSectionsToStudents..................................................................................................55

Section Functions.............................................................................................................56getSectionsByCriteria....................................................................................................56getSection.......................................................................................................................56addSection......................................................................................................................56updateSection.................................................................................................................56deleteSection..................................................................................................................56

Section Quizzes Functions...............................................................................................57getSectionQuiz...............................................................................................................57getSectionQuizzesByCriteria.........................................................................................57deleteSectionQuiz..........................................................................................................57addSectionQuiz..............................................................................................................57updateSectionQuiz.........................................................................................................57

Quiz Records Functions..................................................................................................58getQuizRecord...............................................................................................................58getQuizRecordsByCriteria.............................................................................................58deleteQuizRecord...........................................................................................................58addQuizRecord..............................................................................................................58updateQuizRecord..........................................................................................................58

Problems Answered Functions.......................................................................................59getProblemAnswered.....................................................................................................59getProblemsAnsweredByCriteria..................................................................................59deleteProblemAnswered................................................................................................59addProblemAnswered....................................................................................................59updateProblemAnswered...............................................................................................59

TABLE DEFINITIONS..................................................................................................60Schools Table....................................................................................................................61

SchoolID........................................................................................................................61Name..............................................................................................................................61Address..........................................................................................................................61City.................................................................................................................................61State................................................................................................................................61Zip..................................................................................................................................61Description.....................................................................................................................61

Teachers Table.................................................................................................................62TeacherID......................................................................................................................62SchoolID........................................................................................................................62Username.......................................................................................................................62

Parents Table...................................................................................................................63ParentID.........................................................................................................................63Username.......................................................................................................................63

PhoneNumber................................................................................................................63ParentsToStudents Table................................................................................................64

ParentsToStudentsID.....................................................................................................64ParentID.........................................................................................................................64StudentID.......................................................................................................................64

Sections Table...................................................................................................................65SectionID.......................................................................................................................65TeacherID......................................................................................................................65Subject............................................................................................................................65Name..............................................................................................................................65Classification..................................................................................................................65

Students Table..................................................................................................................66StudentID.......................................................................................................................66Username.......................................................................................................................66Classification..................................................................................................................66

Administrators Table......................................................................................................67AdministratorID.............................................................................................................67SchoolID........................................................................................................................67Username.......................................................................................................................67

Coordinators Table..........................................................................................................68CoordinatorID................................................................................................................68SchoolID........................................................................................................................68Subject............................................................................................................................68Username.......................................................................................................................68

SectionsToStudents Table...............................................................................................69SectionStudentID...........................................................................................................69StudentID.......................................................................................................................69SectionID.......................................................................................................................69

SectionQuizzes Table.......................................................................................................70SectionQuizID................................................................................................................70QuizID............................................................................................................................70SectionID.......................................................................................................................70DateTimeAvailable........................................................................................................70DateTimeDue.................................................................................................................70QuizNumber...................................................................................................................70RetryQuiz.......................................................................................................................70RetryProblems................................................................................................................71QuizFeedback................................................................................................................71ProblemFeedback...........................................................................................................71

QuizRecords Table..........................................................................................................72QuizRecordID................................................................................................................72StudentID.......................................................................................................................72QuizID............................................................................................................................72SectionID.......................................................................................................................72Timestamp......................................................................................................................72PointsAwarded...............................................................................................................72

ProblemsAnswered Table...............................................................................................73ProblemAnsweredID......................................................................................................73QuizRecordID................................................................................................................73ProblemChoiceID..........................................................................................................73ProblemID......................................................................................................................73AnswerGiven.................................................................................................................73Correct............................................................................................................................73PointsAwarded...............................................................................................................73

TABLE DIAGRAM.........................................................................................................74

CONCLUSION................................................................................................................76Project Team Information..............................................................................................76

Client Information..........................................................................................................76Faculty Advisor Information..........................................................................................76CprE/EE 492 Member Information...............................................................................76CprE/EE 491 Member Information...............................................................................76

Summary............................................................................................................................77

Introduction

The purpose of the document is to give a general understanding of the implementation and methods used by the framework team (Ongo 08d) in their PHP library code. All questions should be directed to the framework team, and all assumptions made by non-framework teams (Ongo 08a, Ongo 08b, and Ongo 08c) should be checked with by Ongo 08d team representatives before implementation of said assumptions.

This document will be updated each term when new functionality is added to the framework. After agreeing upon the contents of this document, the framework will then begin creating code to meet these objectives. Once the code is ready for implementation, the contents of this document will become part of the framework cookbook. The cookbook should be used by the other teams as a guide to implementing the framework.

Problem StatementThis section contains the general problem and the solution decided upon, by the framework team.

General Problem StatementThe Ongoing 08 team consists of a series of applications and a framework. The framework is to be a library of calls, functions, and tables the applications can call to do basic routines shared by all of the applications. Since most of the applications were built by different sub-teams and different developers, each application is a little different. It is the framework’s responsibility to make the applications uniform in how they access the database, call specified routines, and respond to errors.

General Solution-Approach StatementThe Ongoing 08 team needs a list of set functions and tables to construct their applications around. In order to facilitate their needs, the framework team (Ongo 08d) has met and gathered information from each team including, but not limited to: application design, external file usage, method handling, and question types. From the meetings, a list of functions and SQL tables has been compiled. Contained within this document are the tables and functions to be considered for review by the application sub-teams.

The Ongoing 08 sub-teams (MTSS, Uncle Sam’s America, and Globey’s World) can now utilize this document by looking at the functions, tables, and definitions under proposal. Each function and table entry definition should help a team member to understand both why and how to use it.

47

Function Definitions

The following are a list of tentative desired functions for the framework. Included within each function is a listing of the prototype, description, and what the call will return. No distinction over whether to use objects or arrays has been made yet.

School FunctionsThe functions below are associated with the School table and will allow the programs to retrieve school information based upon certain search criteria or by a known SchoolID. They will also allow the addition of new schools as well as modifying and deleting existing schools.

getSchoolsByCriteriaCall: array getSchoolsByCriteria(object SchoolInfo)Description: The getSchoolsByCriteria function can be called as the above notation describes. Additionally, the getSchoolsByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, if you are unaware of the subject of the school you may omit the subject field indicating it is a wildcard. The same can be done for all other parameters. Return: Array of School objects.

getSchoolCall: object getSchool(int SchoolID)Description: The getSchool function can be called as the above notation describes. Unlike, the getSchoolsByCriteria function. The SchoolID must be passed in order to find a matching table entry.Return: A row from School table as an object.

addSchoolCall: int addSchool(object SchoolInfo)Description: The addSchool function can be called as the above notation describes. The addSchool function will add a school to the SQL table when invoked. During the call the object of SchoolInfo is required. Return: The SchoolID of the school just created, or NULL if unsuccessful.

updateSchoolCall: boolean updateSchool(object SchoolInfo)Description: By passing the SchoolID and the SchoolInfo, you can call the updateSchool function. The updateSchool function will find the proper school by use of the SchoolID and add the new information contained in the object SchoolInfo that was passed.Return: Boolean value.

48

deleteSchoolCall: boolean deleteSchool(int SchoolID)Description: When passed the SchoolID, the deleteSchool will search through the table and erase the row corresponding to that SchoolID. Once the school has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted school information from the weekly sd6 backup file stored offsite.Return: Boolean value.

49

Administrator FunctionsThe functions below are associated with the Administrator table and will allow the programs to retrieve administrator information based upon certain search criteria or by a known AdministratorID. They will also allow the addition of new administrators as well as modifying and deleting existing administrators.

getAdministratorsByCriteriaCall: array getAdministratorsByCriteria(object AdministratorInfo)Description: The getAdministratorsByCriteria function can be called as the above notation describes. Additionally, the getAdministratorsByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, if you are unaware of the subject of the administrator you may omit the subject field indicating it is a wildcard. The same can be done for all other parameters.Return: Array of Administrator objects.

getAdministratorCall: object getAdministrator(int AdministratorID)Description: The getAdministrator function can be called as the above notation describes. Unlike, the getAdministratorsByCriteria function. The AdministratorID must be passed in order to find a matching table entry.Return: A row from Administrator table as an object.

addAdministratorCall: int addAdministrator(object AdministratorInfo)Description: The addAdministrator function can be called as the above notation describes. The addAdministrator function will add a administrator to the SQL table when invoked. During the call the object of AdministratorInfo is required. Return: The AdministratorID of the administrator just created, or NULL if unsuccessful.

updateAdministratorCall: boolean updateAdministrator(object AdministratorInfo)Description: By passing the AdministratorID and the AdministratorInfo, you can call the updateAdministrator function. The updateAdministrator function will find the proper administrator by use of the AdministratorID and add the new information contained in the object AdministratorInfo that was passed.Return: Boolean value.

50

deleteAdministratorCall: boolean deleteAdministrator(int AdministratorID)Description: When passed the AdministratorID, the deleteAdministrator will search through the table and erase the row corresponding to that AdministratorID. Once the administrator has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted administrator information from the weekly sd6 backup file stored offsite.Return: Boolean value.

51

Coordinator FunctionsThe functions below are associated with the Coordinator table and will allow the programs to retrieve course coordinator information based upon certain search criteria or by a known CoordinatorID. They will also allow the addition of new course coordinators as well as modifying and deleting existing course coordinators.

getCoordinatorsByCriteriaCall: array getCoordinatorsByCriteria(object CoordinatorInfo)Description: The getCoordinatorsByCriteria function can be called as the above notation describes. Additionally, the getCoordinatorsByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, if you are unaware of the subject of the coordinator you may omit the subject field indicating it is a wildcard. The same can be done for all other parameters.Return: Array of Coordinator objects.

getCoordinatorCall: object getCoordinator(int CoordinatorID)Description: The getCoordinator function can be called as the above notation describes. Unlike, the getCoordinatorsByCriteria function. The CoordinatorID must be passed in order to find a matching table entry.Return: A row from Coordinator table as an object.

addCoordinatorCall: int addCoordinator(object CoordinatorInfo)Description: The addCoordinator function can be called as the above notation describes. The addCoordinator function will add a coordinator to the SQL table when invoked. During the call the object of CoordinatorInfo is required. Return: The CoordinatorID of the coordinator just created, or NULL if unsuccessful.

updateCoordinatorCall: boolean updateCoordinator(object CoordinatorInfo)Description: By passing the CoordinatorID and the CoordinatorInfo, you can call the updateCoordinator function. The updateCoordinator function will find the proper coordinator by use of the CoordinatorID and add the new information contained in the object CoordinatorInfo that was passed.Return: Boolean value.

52

deleteCoordinatorCall: boolean deleteCoordinator(int CoordinatorID)Description: When passed the CoordinatorID, the deleteCoordinator will search through the table and erase the row corresponding to that CoordinatorID. Once the coordinator has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted coordinator information from the weekly sd6 backup file stored offsite.Return: Boolean value.

53

Teacher FunctionsThe functions below are associated with the Teacher table and will allow the programs to retrieve teacher information based upon certain search criteria or by a known TeacherID. They will also allow the addition of new teachers as well as modifying and deleting existing teachers.

getTeachersByCriteriaCall: array getTeachersByCriteria(object TeacherInfo)Description: The getTeachersByCriteria function can be called as the above notation describes. Additionally, the getTeachersByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, if you are unaware of the subject of the teacher you may omit the subject field indicating it is a wildcard. The same can be done for all other parameters. Return: Array of Teacher objects.

getTeacherCall: object getTeacher(int TeacherID)Description: The getTeacher function can be called as the above notation describes. Unlike, the getTeachersByCriteria function. The TeacherID must be passed in order to find a matching table entry.Return: A row from Teacher table as an object.

addTeacherCall: int addTeacher(object TeacherInfo)Description: The addTeacher function can be called as the above notation describes. The addTeacher function will add a teacher to the SQL table when invoked. During the call the object of TeacherInfo is required. Return: The TeacherID of the teacher just created, or NULL if unsuccessful.

updateTeacherCall: boolean updateTeacher(object TeacherInfo)Description: By passing the TeacherID and the TeacherInfo, you can call the updateTeacher function. The updateTeacher function will find the proper teacher by use of the TeacherID and add the new information contained in the object TeacherInfo that was passed.Return: Boolean value.

54

deleteTeacherCall: boolean deleteTeacher(int TeacherID)Description: When passed the TeacherID, the deleteTeacher will search through the table and erase the row corresponding to that TeacherID. Once the teacher has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted teacher information from the weekly sd6 backup file stored offsite.Return: Boolean value.

55

Parent FunctionsThe functions below are associated with the Parent table and will allow the programs to retrieve parent information based upon certain search criteria or by a known ParentID. They will also allow the addition of new parents as well as modifying and deleting existing parents.

getParentsByCriteriaCall: array getParentsByCriteria(object ParentInfo)Description: The getParentsByCriteria function can be called as the above notation describes. Additionally, the getParentsByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, if you are unaware of the subject of the parent you may omit the subject field indicating it is a wildcard. The same can be done for all other parameters. Return: Array of Parent objects.

getParentCall: object getParent(int ParentID)Description: The getParent function can be called as the above notation describes. Unlike, the getParentsByCriteria function. The ParentID must be passed in order to find a matching table entry.Return: A row from Parent table as an object.

addParentCall: int addParent(object ParentInfo)Description: The addParent function can be called as the above notation describes. The addParent function will add a parent to the SQL table when invoked. During the call the object of ParentInfo is required. Return: The ParentID of the parent just created, or NULL if unsuccessful.

updateParentCall: boolean updateParent(object ParentInfo)Description: By passing the ParentID and the ParentInfo, you can call the updateParent function. The updateParent function will find the proper parent by use of the ParentID and add the new information contained in the object ParentInfo that was passed.Return: Boolean value.

deleteParentCall: boolean deleteParent(int ParentID)Description: When passed the ParentID, deleteParent will search through the table and erase the row corresponding to that ParentID. Once the parent has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted parent information from the weekly sd6 backup file stored offsite.Return: Boolean value.

56

ParentsToStudents FunctionsThese functions will access the ParentsToStudents table and allow the ability to get the students associated with a particular parent. The students are chosen from exiting students in the Students table and the parents are chosen from existing parents in the Parents table. The addition and deletion of students to a particular parent is also supported.

getStudentsOfParentCall: array getStudentsOfParent(int ParentID)Description: When passed the ParentID, the getStudentsOfParents function will return the Student objects of all the students who are children of the parent. Return: An array of Student objects.

getParentsOfStudentCall: array getParentsOfStudent(int StudentID)Description: When passed the StudentID the getParentsOfStudents function will return an array of Parent objects corresponding to the parents that the student is a child of.Return: An array of Parent objects.

deleteParentToStudentCall: boolean deleteStudentFromSection(int ParentID, int StudentID)Description: Implemented if you are attempting to remove a ParentToStudent relationship. If either field is set to NULL, then all matches of the other field will be removed.Return: Boolean value.

addParentToStudentCall: boolean addStudentToSection(int ParentID, int StudentID)Description: Adds a ParentToStudent relationship.Return: Boolean value.

57

Student FunctionsThe functions below are associated with the Student table and will allow the programs to retrieve student information based upon certain search criteria or by a known StudentID. They will also allow the addition of new students as well as modifying and deleting existing students.

getStudentsByCriteriaCall: array getStudentsByCriteria(object StudentInfo)Description: The getStudentsByCriteria function can be called as the above notation describes. Additionally, the getStudentsByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, if you are unaware of the subject of the student you may omit the subject field indicating it is a wildcard. The same can be done for all other parameters.Return: Array of Student objects.

getStudentCall: object getStudent(int StudentID)Description: The getStudent function can be called as the above notation describes. Unlike, the getStudentsByCriteria function. The StudentID must be passed in order to find a matching table entry.Return: A row from Student table as an object.

addStudentCall: int addStudent(object StudentInfo)Description: The addStudent function can be called as the above notation describes. The addStudent function will add a student to the SQL table when invoked. During the call the object of StudentInfo is required. Return: The StudentID of the student just created, or NULL if unsuccessful.

updateStudentCall: boolean updateStudent(object StudentInfo)Description: By passing the StudentID and the StudentInfo, you can call the updateStudent function. The updateStudent function will find the proper student by use of the StudentID and add the new information contained in the object StudentInfo that was passed.Return: Boolean value.

deleteStudentCall: boolean deleteStudent(int StudentID)Description: When passed the StudentID, deleteStudent will search through the table and erase the row corresponding to that StudentID. Once the student has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted student information from the weekly sd6 backup file stored offsite.Return: Boolean value.

58

SectionsToStudents FunctionsThese functions will access the SectionToStudents table and allow the ability to get the students associated with a particular section. The students are chosen from exiting students in the Students table and the sections are chosen from existing sections in the Sections table. The addition and deletion of students to a particular section is also supported.

getStudentsInSectionCall: array getStudentsInSection(int SectionID)Description: When passed the SectionID, the getStudentsInSection function will return an array of Student objects consisting of all the students in the section. Return: An array of Student objects.

getSectionsOfStudentCall: array getSectionsOfStudent(int StudentID)Description: When passed the StudentID the getSectionsOfStudent function will return an array of Section objects corresponding to the sections that the student is a member of.Return: An array of Section objects.

deleteSectionsToStudentsCall: boolean deleteSectionsToStudents(int SectionID, int StudentID)Description: Implemented if you are attempting to remove a student from a section. If either field is set to NULL, then all matches of the other field will be removed.Return: Boolean value.

addSectionsToStudentsCall: boolean addSectionsToStudents(int SectionID, int StudentID)Description: Adds a student to a section.Return: Boolean value.

59

Section FunctionsThe functions below are associated with the Section table and will allow the programs to retrieve section information based upon certain search criteria or by a known SectionID. They will also allow the addition of new sections as well as modifying and deleting existing sections.

getSectionsByCriteriaCall: array getSectionsByCriteria(object SectionInfo)Description: The getSectionsByCriteria function can be called as the above notation describes. Additionally, the getSectionsByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, if you are unaware of the subject of the section you may omit the subject field indicating it is a wildcard. The same can be done for all other parameters.Return: Array of Section objects.

getSectionCall: object getSection(int SectionID)Description: The getSection function can be called as the above notation describes. Unlike, the getSectionsByCriteria function. The SectionID must be passed in order to find a matching table entry.Return: A row from Section table as an object.

addSectionCall: int addSection(object SectionInfo)Description: The addSection function can be called as the above notation describes. The addSection function will add a section to the SQL table when invoked. During the call the object of SectionInfo is required. Return: The SectionID of the section just created, or NULL if unsuccessful.

updateSectionCall: boolean updateSection(object SectionInfo)Description: By passing the SectionID and the SectionInfo, you can call the updateSection function. The updateSection function will find the proper section by use of the SectionID and add the new information contained in the object SectionInfo that was passed.Return: Boolean value.

60

deleteSectionCall: boolean deleteSection(int SectionID)Description: When passed the SectionID, the deleteSection will search through the table and erase the row corresponding to that SectionID. Once the section has been erased, there is no method of retrieving it. It may be possible, but not guaranteed, to retrieve deleted section information from the weekly sd6 backup file stored offsite.Return: Boolean value.

61

Section Quizzes FunctionsThese functions will access the SectionQuizzes table and allow the ability to get the quizzes associated with a particular section. The quizzes are chosen from exiting quizzes in the Quiz table. The addition and deletion of quizzes to a particular section is also supported. See the Quizzes Functions sections for information on modifying a quiz.

getSectionQuizCall: object getSectionQuiz (int SectionID)Description: When passed the SectionID, the getSectionQuiz function will search through the table and return the Section Quiz objects associated with a SectionID. Return: A row from the Section Quiz table as an object.

getSectionQuizzesByCriteriaCall: object getSectionQuizByCriteria(object SectionQuizInfo)Description: The getSectionQuizByCriteria function can be called as the above notation describes. Additionally, the getSectionQuizByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, if you are unaware of the date the quiz will be available you may omit that field indicating it is a wildcard. The same can be done for all other parameters.Return: Array of Section objects.

deleteSectionQuizCall: boolean deleteSectionQuiz(int SectionQuizID)Description: Implemented if you are attempting to remove a section quiz from a section.Return: Boolean value.

addSectionQuizCall: boolean addSectionQuiz(object SectionQuizInfo)Description: If an addition of a quiz to a section is necessary, call this function. Be sure to pass all values in the call. A new row will be created in the Section Quiz Table.Return: Boolean value.

updateSectionQuizCall: boolean addSectionQuiz(object SectionQuizInfo)Description: If an addition of a quiz to a section is necessary, call this function. Be sure to pass all values in the call. A new row will be created in the Section Quiz Table.Return: Boolean value.

62

Quiz Records FunctionsThese functions will access the QuizRecords table and allow the ability to get the results of a quiz that a student took. The quizzes are chosen from existing quizzes in the Quiz table and the students are chosen from the existing students in the Student table.

getQuizRecordCall: object getQuizRecord(int QuizRecordID)Description: When passed the QuizRecordID, the getQuizRecord function will search through the table and return the row associated with that QuizRecordID. Return: An object of QuizRecordInfo corresponding to a QuizRecordID.

getQuizRecordsByCriteriaCall: array getQuizRecordsByCriteria(object QuizRecordInfo)Description: The getQuizRecordsByCriteria function can be called as the above notation describes. Additionally, the getQuizRecordsByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, if you are unaware of the Timestamp of the section you may omit the Timestamp field indicating it is a wildcard. The same can be done for all other parameters.Return: Array of QuizRecordInfo objects.

deleteQuizRecordCall: boolean deleteQuizRecord(int QuizRecordID)Description: Implemented if you are attempting to remove a quiz record.Return: Boolean value.

addQuizRecordCall: boolean addQuizRecord(object QuizRecordInfo)Description: Adds the results of a taken quiz to the database. Be sure to pass all values in the call. A new row will be created in the QuizRecords Table.Return: Boolean value.

updateQuizRecordCall: boolean updateQuizRecord(object QuizRecordInfo)Description: If an update to a quiz record is necessary, call this function. Be sure to pass all values in the call.Return: Boolean value.

63

Problems Answered FunctionsThese functions will access the ProblemsAnswered table and allow the ability to get the results of a quiz that a student took. The problems are chosen from existing problems in the Problems table and the quiz records are chosen from existing quiz records in the Quiz Records table.

getProblemAnsweredCall: object getProblemAnswered(int ProblemAnsweredID)Description: When passed the ProblemAnsweredID, the getProblemAnswered function will search through the table and return the row associated with that ProblemAnsweredID. Return: An object of ProblemAnsweredInfo corresponding to a ProblemAnsweredID.

getProblemsAnsweredByCriteriaCall: array getProblemsAnsweredByCriteria(object ProblemAnsweredInfo)Description: The getProblemsAnsweredByCriteria function can be called as the above notation describes. Additionally, the getProblemsAnsweredByCriteria function will allow for fields to be omitted, if your call does not know the information specified. For example, if you are unaware of the correct answer you may omit the Corrent field indicating it is a wildcard. The same can be done for all other parameters.Return: Array of ProblemAnsweredInfo objects.

deleteProblemAnsweredCall: boolean deleteProblemAnswer(int ProblemAnswerID)Description: Implemented if you are attempting to remove a problem answer.Return: Boolean value.

addProblemAnsweredCall: boolean addProblemAnswered(object ProblemAnswerInfo)Description: Adds the results of an answered problem to the database. Be sure to pass all values in the call. A new row will be created in the ProblemsAnswered Table.Return: Boolean value.

updateProblemAnsweredCall: boolean updateProblemAnswered(object ProblemAnswerInfo)Description: If an update to a problem answer is necessary, call this function. Be sure to pass all values in the call.Return: Boolean value.

64

Table Definitions

This section specifically deals with defining the MySQL tables and the table variables within them. The tables include: Schools, Teachers, Parents, ParentsToStudents, Students, Sections, Administrators, CourseCoordinators, SectionStudents, SectionQuizzes, QuizRecords, and ProblemsAnswered. A description of the Users table can be found in the Authentication and Registration documentation, and a description of the Quizzes, QuizProblems, Problems, ProblemChoices, and Files tables can be found in the quizzing documentation. Each table is listed by name and then the fields are listed with short descriptions of each field and their accepted values.

Each table represents a different object, with the same name as the table. To create a new object, you would either call the constructor for that object, or call the setName method where Name is the name of the table field you want to set. In the same way, to retrieve values from an object, you would call the getName method where Name is the name of the table field you want to retrieve.

65

Schools TableThe schools table will hold information about individual schools. Sections, grades, students, etc. will be tied to schools through this table’s SchoolID number.

SchoolIDThe unique ID number of the school. This is used to identify which teachers, students, etc. belong to which school.Type: Unsigned Int

NameThe school’s name.Type: String

AddressThe school’s address.Type: String

CityThe school’s city.Type: String

StateThe school’s state.Type: String

ZipThe school’s zip code.Type: Unsigned Int

DescriptionA short description of the schoolType: Text

66

Teachers TableThe teachers table will hold information about individual teachers. Sections, students, etc. will be tied to teachers through this table’s TeacherID number.

TeacherIDThe unique ID number for this teacher. This allows sections to be tied back to individual teachers.Type: Unsigned Int

SchoolIDWhich school this teacher belongs to.Type: Unsigned Int

UsernameThe username used by this teacher to log in.Type: String

67

Parents TableThe parents table will hold information about the parents of students.

ParentIDThe unique numeric ID assigned to this parent.Type: Unsigned Int

UsernameThe username used by this parent to log in.Type: String

PhoneNumberThe phone number of this parent.Type: String

68

ParentsToStudents TableThe ParentsToStudents table will hold information which students have which parents. This table structure allows for a many-to-many relationship of students to parents (ie, one student can have multiple parents, and one parent can have multiple children).

ParentsToStudentsIDA unique numeric ID for this parent-child relationship.Type: Unsigned Int

ParentIDThe numeric ID of the parent.Type: Unsigned Int

StudentIDThe numeric ID of the student.Type: Unsigned Int

69

Sections TableThe sections table will hold information about individual sections. A ‘section’ is analogous to a class in a school setting; however, the word ‘section’ was used to avoid ambiguity.

SectionIDThe unique numeric ID of this section. Students, quizzes, and grades can be tied to individual sections by this ID.Type: Unsigned Int

TeacherIDThe numeric ID of the teacher teaching this section.Type: Unsigned Int

SubjectThe subject of this section.Type: Global: MTSS_sub, Globey_sub, USA_sub

NameThe name of this section.Type: String

ClassificationThe classification (grade) of the students in the section.Type: Unsigned Int

70

Students TableThe school table will hold information about individual students. A student’s grades will be tied to back to him or her through this table’s StudentID number.

StudentIDThe unique ID number assigned to this student. Grades can be tied back to individual students by this ID number.Type: Unsigned Int

UsernameThe username used by the student when logging in.Type: String

ClassificationThe classification of the student (the grade the student is in).Type: Unsigned Int

71

Administrators TableThe Administrators table will hold information about administrators.

AdministratorIDThe unique ID number assigned to this administrator.Type: Unsigned Int

SchoolIDThe ID number of the school to which this administrator belongs.Type: Unsigned Int

UsernameThe username used by this administrator to log in.Type: String

72

Coordinators TableThe Coordinators table will hold information about course coordinators.

CoordinatorIDThe unique ID number assigned to this coordinator.Type: Unsigned Int

SchoolIDThe ID number of the school to which this coordinator belongs.Type: Unsigned Int

SubjectThe subject this coordinator coordinates.Type: Global: MTSS_sub, Globey_sub, USA_sub

UsernameThe username used by this coordinator to log in.Type: String

73

SectionsToStudents TableThe SectionStudents table will hold information about which students are in which sections. This table structure allows for one student to be in multiple sections, and one section to contain multiple students.

SectionStudentIDA unique ID number for this section-student relationship.Type: Unsigned Int

StudentIDThe student’s numeric ID.Type: Unsigned Int

SectionIDThe numeric ID of the section to which the student belongs.Type: Unsigned Int

74

SectionQuizzes TableThe SectionQuizzes table will hold information about which students are able to take which quizzes. This table structure allows for one student to take multiple quizzes, and one quiz to be taken by multiple students.

SectionQuizIDA unique ID number for this section-student relationship.Type: Unsigned Int

QuizIDThe numeric ID of the quiz.Type: Unsigned Int

SectionIDThe numeric ID of the section to which the quiz belongs.Type: Unsigned Int

DateTimeAvailableThe date and time at which this section will be able to take the quiz.Type: String of form 'YYYY-MM-DD HH:MM:SS'

DateTimeDueThe date and time at which this quiz is due for this section.Type: String of form 'YYYY-MM-DD HH:MM:SS'

QuizNumberThe number that this quiz will be taken by this section in relation to other quizzes taken in this section.Type: Unsigned Int

RetryQuizWhether or not the quiz can be retaken by a student.Type: Boolean

75

RetryProblemsWhether or not a student can retry a problem.Type: Boolean

QuizFeedbackWhether or not a student will get feedback once they complete a quiz.Type: Boolean

ProblemFeedbackWhether or not a student will get feedback once they complete a problem.Type: Boolean

76

QuizRecords TableThe QuizRecords table will hold information about individual quizzes taken by students. This table structure will allow one quiz to be taken multiple times by the same student. Each time a quiz is taken, an entry is generated in this table.

QuizRecordIDThe unique numeric ID assigned to this instance of a quiz being taken.Type: Unsigned Int

StudentIDThe numeric ID of the student that took the quiz.Type: Unsigned Int

QuizIDThe numeric ID of the quiz that was taken.Type: Unsigned Int

SectionIDThe numeric ID of the section for which this quiz was taken.Type: Unsigned Int

TimestampThe time and date at which this quiz was taken.Type: String of form 'YYYY-MM-DD HH:MM:SS'

PointsAwardedThe number of points awarded for this attempt at the quiz.Type: Unsigned Float

77

ProblemsAnswered TableThe ProblemsAnswered table will hold information about the problems answered on a quiz.

ProblemAnsweredIDThe unique numeric ID assigned to this problem-answer relationship.Type: Unsigned Int

QuizRecordIDThe numeric ID of the quiz attempt on which this problem was answered.Type: Unsigned Int

ProblemChoiceIDThe choice number chosen for the answer.Type: Unsigned Int

ProblemIDThe numeric ID of the problem answered.Type: Unsigned Int

AnswerGivenThe text of the answer given, if not a multiple-choice question.Type: String

CorrectWhether or not this answer was counted as correct.Type: Bool

PointsAwardedThe number of points awarded for this answer.Type: Unsigned Float

78

Table Diagram

This section contains a useful diagram describing the table relationships in the database. This diagram attempts to represent as fully as possible the relationships and fields within each table.

79

80

Conclusion

Project Team InformationClient InformationAmes Community SchoolsAdministrative Offices1921 Ames High DriveAmes, IA 50010Phone: 515-268-6600

Faculty Advisor InformationDr. John Lamont324 Town EngineeringAmes, IA 50011-3230Phone: 515-294-3600Fax: [email protected]

Professor Ralph Patterson, III326 Town EngineeringAmes, IA 50011-3230Phone: 515-294-2428Fax: [email protected]

CprE/EE 492 Member InformationMichael EspelandElectrical Engineering3324 Opal Dr.Ames, IA [email protected]

Sean HowardComputer Engineering2862 Lincoln Way #3Ames, IA [email protected]

Anthony PersaudComputer Engineering4490 Friley ConverseAmes, IA [email protected]

CprE/EE 491 Member InformationTim AdkissonComputer Engineering4733 Toronto St. #101Ames, IA [email protected]

Kevin WendzelComputer Engineering2136 Frederiksen Ct.Ames, IA [email protected]

81

SummaryThis document highlights the necessary functions and tables the framework should create in order to provide the other ongoing teams with useful support. Since the sub teams have worked largely independent of each other it was necessary for the framework team to make the library of functions as dynamic as possible, allowing for a greater flexibility.

This document will serve as a general guide for the present Ongoing 08 and future Ongoing 08 teams when they are constructing and utilizing the functions explained here in. If functions are found to be unnecessary and not useful to any Ongoing 08 team, it should be removed from this document and from the framework itself.

As a reminder, this document is tentative and subject to change within the future. Presently, this is the course for which the framework team (Ongo 08d) will strive for.

82

Documents

Mathematical Teaching Software Systemseniord.ece.iastate.edu/projects/archive/ongo08/SASF... · Web view515-292-5249 [email protected] Jason Wilkinson Computer Engineering