Table of Contents
Introduction ............................................................................................................................................................................ 2
Current Situation:................................................................................................................................................................ 2
Purpose: .............................................................................................................................................................................. 2
Goals: .................................................................................................................................................................................. 2
Roles and terminology: ....................................................................................................................................................... 3
User roles (user classes): ................................................................................................................................................. 3
Terms: ............................................................................................................................................................................. 4
Requirements .......................................................................................................................................................................... 6
Common User Requirements .............................................................................................................................................. 6
Participants: ........................................................................................................................................................................ 7
Other System Requirements: .............................................................................................................................................. 7
Software Architecture ............................................................................................................................................................. 8
Overview of Software Architecture .................................................................................................................................... 9
The Server Side ................................................................................................................................................................. 11
The Client .......................................................................................................................................................................... 12
Database ............................................................................................................................................................................... 14
Database Management System: ....................................................................................................................................... 14
Entity Relationship Diagram: ............................................................................................................................................ 14
Data Dictionary: ................................................................................................................................................................ 15
Modules ................................................................................................................................................................................ 21
User Management: ........................................................................................................................................................... 25
Session Management Module .......................................................................................................................................... 31
Database Abstraction Module .......................................................................................................................................... 38
Admin Module .................................................................................................................................................................. 39
Semester Module .............................................................................................................................................................. 41
Login Module .................................................................................................................................................................... 47
Experiment Management Module:................................................................................................................................... 48
Confirmations: .................................................................................................................................................................. 58
Conclusion ............................................................................................................................................................................. 62
How do we meet the requirements? ................................................................................................................................ 62
How do we exceed the requirements? ............................................................................................................................. 63
Introduction
Current Situation:
The SIUE Psychology department has an experiment program whereby new students
have to participate in experiments conducted by graduate students and faculty. It is a
requirement that they must participate in 6 hours worth of experiments and there grade is
impacted by how many hours of experiments they participate in.
Currently, the Psychology department manages this with a number of ‘done by hand’
paper systems. Scheduling is done by posting experiment availability times in the lower level
of Alumni Hall , the students have to trek down to the posted times, search through many
different experiments finding ones that do not conflict with their schedule and which have
compatible requirements, sign up for the experiment and remember to show up at the proper
time. Participation is tracked by an error prone card and stamp method, where a student is
given a card at the start of the semester and has to have it stamped for each experiment they
participate in. if the card is lost they have to start over, and forgery of stamps is an issue.
Finally at the end of the semester the cards are collected to determine who participated in
how many hours of which experiments and their grade is assigned. In addition to being a very
slow and cumbersome system it is also very error prone at almost every step of the process. It
was for these reasons that our client Dr Mike Dudley contacted the CS department with his
senior project proposal.
Purpose:
The purpose of our system is keep track of who did what when. It will make the
process of posting experiments easier. It will make the process of finding and signing up for
experiments much less of a chore. It will make the tracking of participation far more secure
and much less error prone. And it will allow a much simplified means of summarizing
participation status.
Goals:
Our goals are to provide a system that will be:
a) Usable:
Our foremost goal is to ensure that the system will be easy to use by all users of
the system, no matter what sort of capabilities our system might have they will be
worthless if they cannot be easily accessed by the people who need to use them.
b) Functional:
Our system must meet the all requirements that our client needs to perform the
task at hand, if the system is only able to handle 90% of the critical functionality
then the remaining 10% will need to be done out of system and will remain a
source of great inefficiency and error.
c) Reliability:
In order to be useful to our client the system must be highly fault tolerant and
capable of running for extremely long periods of time without failing. In the event
of a failure it must be able to handle it gracefully and recover with minimal loss of
data. Even if we have the most function rich, highly useable system in the world it
will be useless if it is constantly down.
d) Expandable:
It is expected that at some point in the future the requirements of the psychology
department might change. For this reason we must ensure that future
modification of the system is as easy and straight forward as possible.
e) Secure:
Ensuring that every user is able to reach all functionality that they are supposed
to and ABSOLUTELY NONE that they are not supposed to have access to is of
extreme importance, if a flaw is found that allows a participant to modify their
participation record then the whole purpose of the system will have been
undermined.
Roles and terminology:
The system will involve the interaction of several different user classes with a number of
different entities. For clarity, we will define these terms here:
User roles (user classes):
 Participant:
A Participant is a psychology 111 student who is required to complete 6 hours of
experiments. Participants search for Experiments posted by experimenters, and sign up
for them.
 Experimenter:
An Experimenter is a user who posts and/or conducts experiments in the system, and
confirms the participation of participants for experiment sessions they conduct.
 Coordinator:
A coordinator is an administrative user, who has complete control over all aspects of the
system, they control when registration is allowed and can add or remove any class of
user at any time. Coordinators are responsible for maintaining the operation of the
system, and for producing the system’s documentation used by the psychology
department for assigning grades to participants.
Terms:
 Experiment
An Experiment is a test or study conducted under controlled conditions. In terms of our
system, an experiment has a duration, a description, a number of requirements, and
one or more experimenter owners who can make adjustments to most of its values and
schedule sessions for conducting the experiment.
 Session
A Session is one instance of an experiment being conducted. A session has a starting
time, and a participation capacity as well as an experimenter who will be conducting the
experiment session.
 Participation
Participation is the act of a participant participating in an experimental session, when a
participant signs up for an experiment session they are making a participation link
between them and a Session. A session can have one or many participants participating
in it.
 Owner
An Experiment’s owner is an experimenter, who has control over an experiment. The
owner can make changes to the experiment’s description and restrictions, and an owner
can schedule sessions for the experiment. The primary purpose of the owner is to
facilitate experimenters who work in groups or situations where one experimenter
would make an experiment for other experimenters to conduct.
 Primary Owner
The primary owner of an experiment is the owner who has the highest level of control
over the experiment, only the primary owner is allowed to grant other experimenters
ownership of the experiment.
 Availability
Availability is a timeslot when a participant will be available to participate in an
experiment session.
 Confirmation/Approval
Confirmations and approvals are items which the system is prepared to process in some
fashion but needs feedback from a particular user to provide feedback as to whether it
should or not. The three typical types of approvals are:
 Participation confirmation: confirming that a participant did indeed
participate in an experiment session like they said they would.
 Experimenter registration approval: coordinators will be required to review
all users who register as experimenters to make sure they are in fact
authorized.
 Experiment approval: a coordinator is required to explicitly authorize every
experiment before sessions can be scheduled for it.
Requirements
The requirements for the system are divided into five categories, requirements that are
common to all user types, requirements specific to each of the three user types, and
requirements for the system to perform on its own.
Common User Requirements
All users need the ability to register with the system and submit and update user details
(including contact details). Participants and experimenters will be able to select their role at
registration time but only participants will be active without coordinator approval.
Registration can be opened and closed by the coordinator, when the registration is closed no
new users may be registered unless done manually by the coordinator.
Experimenters:
Experimenters need the ability to post and conduct experiments. Some experimenters
will conduct experiments posted by other experimenters (for instance several experimenters
conducting the same experiment, it would be submitted only one time (for instance by a team
leader) but conducted by more than one experimenter). Some experimenters will only post
experiments for others to conduct (like a faculty member who will have several grad students
run a particular experiment). By default the person submitting an experiment would own it (be
able to schedule sessions, be able to update details, etc...) but they would have the ability to
give other experimenters co-ownership. Experimenters will have the ability to limit availability
to a select list of students. Experimenters will only be able to schedule sessions for an
experiment after the coordinator approves it. The number of credits it is worth is 1 credit per
hour. The amount of time the experiment should take (and thus credits it will be worth) will be
determined and assigned by the coordinator.
To conduct an experiment an experimenter will have to schedule one or more sessions
with it. As far as our system is concerned the actual conducting of the experiment will simply
be the experimenter confirming that the participant showed up and did what was expected of
them (or not) for the given session after the session has expired (after it has started). An
experimenter will also have the option of denying retaking an experiment on the occasion that
a participant fails to show up, but by default they will be able to retake.
Experimenters should be able to cancel experiment sessions and update experiment
details (with restrictions and notifications). On the event that an experimenter cancel’s an
experiment all actively registered participants will receive full credit from the experiment.
Participants:
Participants need to be able to set up and update a weekly availability schedule and
search for experiments that are compatible. From the resulting experiments a participant
should be able to sign up for experiment sessions to participate in. Participants should be able
to cancel their participation, no later than 24 hours before hand, or requiring experimenter
approval after that. As part of the registration process a participant will need to fill out a
demographic survey, experiments will be filtered based on this. Some experiments may have
additional requirements that the system cannot filter automatically, in these situations the
user should be alerted to them and required to read and confirm that they have read and
conform to these restrictions. Each participant may only participate in a given experiment
once (they can take experiments they fail to show up for at experimenter discretion). Some
experiments will require completion of one or more other experiments as a prerequisite, and
participation in one will sometimes require signing up for one or more others. Participants will
be able to track their progress through the semester.
Coordinators:
Coordinators would basically have administration power over the whole system. They
would be primarily responsible for confirming the registration of experimenters, approving
experiments and the number of credits (and therefore duration), setting a cap on the number
of participants who can participate in any experiment, setting a cap on the number of credits a
student can sign up for, and producing a participation report at the end of an experimentation
cycle (semester).
Other System Requirements:
The system should send notifications and reminders of any upcoming, changed or
canceled events. The system should only work with one experiment cycle at a time; that is, all
the participants and experiments of a given semester would be removed from active
registration at the end of a semester, and archived. This along with the production of the
participation report would all be considered part of an end cycle process, the end result of
which would be the report. The system would then be primed for the next upcoming semester
with all of last semester's experiments and participants archived.
Software Architecture
Definition
The software architecture of an application represents its technical structure—the
software components (and the APIs that they expose) and their relationships.
Our application will represent a client-server software architecture model. A clientserver model is a distributed system in which one or more clients and one or more servers
(often, there is only one server) communicate over a computer network to service the needs
of the application. In general, what distinguishes clients from servers is that clients initiate
requests to servers, and servers respond to requests.
In our application’s software architecture, the client will typically be a web browser, like
Mozilla Firefox, and the server consists of an array of applications that will be publicly exposed
as an HTTP interface using the Apache HTTP server. Therefore, the client will provide the enduser interface functionality—how the application looks and feels—and the server will be the
backend support.
Overview of Software Architecture
Here is a diagram depicting the basic components and their relationships:
On the server side, there is a web server, server-side scripting, and a database. On the
client side, there is a web browser, HTML/CSS for presentation, and client-side scripting. The
basic communications channel between the client-side and server side is between the web
browser and the web server, where the web server waits to respond to HTTP requests from
the web browser. The web server interfaces with the DBMS with server-side scripts, and this
combination of technologies will allow our application to dynamically generate web pages;
essentially, our application will customize the server response based on various parameters,
like the type of user that is logged in, e.g., a client logged in as a participant will get a different
version of the Current Experiments page than a client logged in as an experimenter.
This set of technologies by itself will permit our application to meet our customer’s
design requirements; however, on clients with Javascript functionality, our application will
have enhanced usability. For instance, Javascript will be able to programmatically alter the
presentation of the user interface while resident in the browser through the Document Object
Model (DOM). This will permit usability enhancements like popping up a small calendar when
the user clicks on a calendar icon next to a date entry field. More ambitiously, if our
application can exploit the AJAX path, it will enable even more enhanced usability because it
will be able to make requests from the server for data that runs asynchronously in the
background while the user interacts with the user interface. For instance, on the Experiment
Search page, while the user enters in search criteria the client-side script can issue a request
from the server for experiments that match the user’s search criteria and then update the user
interface without any reloads so that the user sees real-time updates for experiment’s that
match his or her search criteria.
What follows is a detailed overview of our software architecture.
The Server Side
The server side is a LAMP stack. LAMP is an acronym that stands for Linux, Apache,
MySQL, and PHP.
Linux is an open-source operating system. It has a proven reliability record. Equally
important, there is an open community of users and developers that offer free support to endusers. Since are project has limited funds, this is an especially important criteria. This will also
be true for all of the other open-source programs that our project depends on.
Apache is an open source web server. It will accept HTTP requests from clients, e.g.,
web browsers, and it will serve HTTP responses to them.
MySQL is an open source relational database management system (RDBMS). It will be
used as the primary data store and retrieval. MySQL supports SQL; SQL is both a query
language and a manipulation language. We will use it to implement and query the database.
PHP is an open-source server-side scripting language. It will be used to dynamically
generate content, e.g., HTML pages. Its primary input will be results from SQL queries; it will
process that input to generate its primary output, HTML documents.
The Client
The client will consist of a web browser—like Mozilla Firefox—that supports various
World Wide Web open-standards—like HTML and CSS. Our software will exploit the latest
World Wide Web standards, but it will not do so at the expense of compatibility; it is intended
to gracefully degrade to support the widest audience possible.
HTML/CSS will serve as its core user interface and presentation layer. HTML stands for
Hypertext Markup Language. It is a markup language used to construct interlinking web pages.
It will specify the content. CSS stands for Cascading Style Sheets. It will specify the
presentation.
Since our HTML documents will refer to the same set of style sheets, we benefit from
the following:
1.
2.
3.
Separation of Concerns. Separating content from presentation helps to separate
our concerns. For example, once we produce the content and structure of our
document, we could then focus on how we want it to be presented to the user
depending upon the client’s needs, e.g., presentation on a computer monitor
may be very different than presentation on a printer. This separation of
concerns also makes it much easier to support accessibility standards for
disabled end-users.
Our web application will have a consistent presentation.
It will be easier to change the overall presentation of our web application by
modifying one or more style sheets.
HTML-DOM/Javascript will add optional capabilities or features to the user interface.
DOM stands for Document Object Model. HTML-DOM is a language-independent API
that exposes the structure of an HTML document as a hierarchical tree of objects—like an
HTML table—thus facilitating programmatic manipulation of HTML documents. Specifically, an
HTML-DOM tree can be manipulated by adding new objects under specified “parent” objects,
modifying existing objects, and deleting objects.
Javascript, our chosen client-side scripting language, will be used to programmatically
read and write to the HTML-DOM. This will facilitate rapidly changing HTML documents
resident in the client so that the client does not need to request from the server an HTML
document that has those changes, which would be considerably slower.
AJAX stands for Asynchronous JavaScript + XML. It too will expand upon HTMLDOM/Javascript with respect to adding optional features. With AJAX, a client will be able to
retrieve data from the server asynchronously. This will permit our application to, for instance,
update search results simultaneously as the user interactively specifies search criteria. Another
example outside of our application is Google Maps, which asynchronously updates the viewing
pane with new data as the user interactively pans around the map.
Database
The database is an intricate part of the Pool Party application. It stores all information
related to the application, every user, every experiment, and every session are all stored in the
database. The database also links users, both participants and experimenters to experiments.
Without the use of a database the Pool Party application would not be feasible.
Database Management System:
The database management system that we will be using to implement the Pool Party
application will be MySQL.
Entity Relationship Diagram:
The following diagram is the ERD which represents that database to be implemented for
use with the Pool Party application.
User
AvailabilityTimeslot
ID {PK} : Integer
User ID {FK} : Integer
Start Time : Time
End Time : Time
Participation
ID {PK} : Integer
User ID {FK} : Integer
Session ID {FK} : Integer
Status : ParticipationStatus
 has Participant
*
1
*
1
 is
Participating
Participant
1
*
 in
Experimenter
 Conducts
ID {PK} : Integer
Student ID {UNIQUE} : String
User Name {UNIQUE} : String
User Type : UserType
First Name : String
Last Name : String
Email : String
Phone Number : String
Password : String
Class : String
Section : String
Gender : Character
DOB : Date
Ethnicity : EthnicityType
Student Status : StudentType
1
Smoker : Boolean
Drinker : DrinkingLevel
Relationship Status : RelationshipType
Owner
Experimenter
*
1
1..*
PrerequisiteExperiments
ID {PK} : Integer
Experiment ID {FK} : Integer
Prerequisite{FK} : Integer
-PrimaryOwner
*
Owns
*
User Restriction
ID {PK} : Integer
Experiment ID {FK} : Integer
Experimenter ID {FK} : Integer
Start Time : Time
Location : String
MaxParticipents : Integer
1
*
*
*
 has
*
1
Enumerations
«enumeration»EthnicityType
+Freshmen
+Softmore
+Junior
+Senior
1is restricted to
0..1
Restrictions
«enumeration»RelationshipType
+Single
+Dateing
+Married
+Divorced-Single
+Divorced-Dateing
*
Ethnicity Restriction
ID {PK} : Integer
Experiment ID {FK} : Integer
Ethnicity : EthnicityType
«enumeration»UserType
«enumeration»StudentType
experiment
ID {PK} : Integer
PrimaryOwner{FK} : Integer
Name : String
Credits : Rational
Abstract : String
Description : String
EthnicityRestrictionMode : RestrictionMode
UserRestrictionMode : RestrictionMode
1
+Caucasian
+Black, African American
+Hispanics
+Asian
+Pacific Islander
+Native American
1
Experiment
1
ID {PK} : Integer
User ID {FK} : Integer
Experiment ID {FK} : Integer
Session
other experiment
Requires
Participant
1
1
ID {PK} : Integer
User ID {FK} : Integer
Experiment ID {FK} : Integer
+Participant
+Experimenter
+Coordinator
ID {PK} : Integer
Experiment ID {FK} : Integer
Gender : Character
Smoker Status : Boolean
Drinker Status : DrinkingLevel
Relationship Status : RelationshipType
Minimum Age : Integer
Maximum Age : Integer
StudentStatus : StudentType
Other : String
«enumeration»ParticipationStatus
«enumeration»DrinkingLevel
+None
+Moderate
+Heavy
+SignedUp
+Completed
+Missed
«enumeration»RestrictionMode
+Allow
+Deny
+None
Data Dictionary:
The following table is the data dictionary for the database to be implemented for use
with the Pool Party application.
Name
abstract
Description
From Experiment; stored as a string; the abstract
description of the experiment.
AvailabilityTimeslot
class
credits
description
DOB
drinker
drinkerStatus
DrinkingLevel
email
endTime
ethnicity
Entity type that contains information about a user’s
availability during a specific time period.
From User; stored as a string; the class that the user is
using the system for.
From Experiment; stored as a rational; the number of
credits that a participant will receive for participating in
this experiment.
From Experiment; stored as a string; the full description
of the experiment.
From User; stored as a datetime; the user's date of
birth.
From User; stored as a DrinkingLevel; the amount a user
drinks.
From Restrictions; stored as a boolean; a restriction
based on how much a participant drinks.
enumerator; a level of drinking to be used in the
system; values: none, moderate, heavy.
From User; stored as a string; the user's email address.
From AvailabilityTimeslot; stored as datetime; the time
that the AvailabilityTimeslot ends.
From EthnicityRestriction; stored as an EthnicityType;
the ethnicity that an experiment is restricted to or from.
ethnicity
From User; stored as an EthnicityType; the user's
ethnicity.
ethnicityRestrictionMode From Experiment; stored as a RestrictionMode; the
mode of restriction based on ethnicity.
EthnicityRestrictions
Entity type that contains information about restrictions
based on ethnicity for a particular experiment.
EthnicityType
enumerator; a type of ethnicity to be used in the
system; values: Caucasian, Black, African American,
Hispanic, Asian, Pacific Islander, Native American.
Experiment
Entity type that contains information about an
experiment in the system.
From Session; Foreign key; stored as an integer; the ID
number for the experimenter conducting the session.
experimenterID
experimentID
From Session; Foreign key; stored as an integer; the ID
number for the experiment for which the session
belongs
experimentID
experimentID
experimentId
experimentID
experimentID
firstName
gender
gender
ID
From Owner; Foreign key; stored as an integer; the ID
number for the experiment owned.
From PrerequisiteExperiments; Foreign key; stored as
an integer; the ID number of the experiment that has
the prerequisite.
From Restrictions; Foreign key; stored as an integer; the
ID number of the experiment being restricted.
From EthnicityRestriction; Foreign key; stored as an
integer; the ID number for the experiment with the
ethnicity restriction.
From UserRestriction; Foreign key; stored as an integer;
the ID number of the experiment that the user is
restricted from.
From User; stored as a string; the user's first name.
From Restrictions; stored as a character; the gender
that the experiment is restricted to.
From User; stored as a character; the gender of the
user.
From AvailabilityTimeslot; Primary key; stored as an
integer; the ID number for an AvailabilityTimeslot.
ID
From Participation; Primary key; stored as an integer;
the ID for a users participation in a session.
ID
From Session; Primary key; stored as an integer; the ID
number for a Session
From Owner; Primary key; stored as an integer; the ID
number of an Owner.
From PrerequisiteExperiments; Primary key; stored as
an integer; the ID number for a PrerequisiteExperiment.
ID
ID
ID
ID
ID
From Experiment; Primary key; stored as an integer; the
ID number of an Experiment.
From Restrictions; Primary key; stored as an integer; the
ID number for a restriction.
From EthnicityRestriction; Primary key; stored as an
integer; the ID number for an ethnicity restriction on an
experiment.
ID
ID
lastName
location
maximumAge
maxParticipants
minimumAge
name
other
Owner
Participation
ParticipationStatus
password
phoneNumber
From User; Primary key; stored as an integer; the ID
number for a User.
From UserRestriction; Primary key; stored as an integer;
the ID number for a UserRestriction.
From User; stored as a string; the user's last name.
From Session; stored as a string the building and room
number in which the session is taking place.
From Restrictions; stored as an integer; restrict the
maximum age of a participant in an experiment.
From Session; stored as an integer; the maximum
number of participants allowed to participate in the
session.
From Restrictions; stored as an integer; restrict the
minimum age of a participant in an experiment.
From Experiment; stored as a string; the name of the
experiment.
From Restrictions; stored as a string; additional
restrictions for an experiment.
Entity type that contains information about a user
having ownership of an experiment.
Entity type that contains information about
participation in an experiment.
enumerator; the status of a participation used in the
system; values: SignedUp, Completed; Missed.
From User; stored as a string; a hash made from the
user's password, used when logging in.
From User; stored as a string; the user's phone number.
prerequisite
From PrerequisiteExperiments; Foreign key; stored as
an integer; the ID number of the experiment that is the
prerequisite for another experiment.
PrerequisiteExperiments
Entity type that contains information about
experiments which are prerequisites of another
experiment.
From Experiment; Foreign key; stored as an integer; the
Id number of the Owner of an experiment.
primaryOwner
relationshipStatus
From Restrictions; stored as a RelationshipType; a
restriction based on a participants relationship status.
relationshipStatus
RelationshipType
RestrictionMode
Restrictions
section
Session
sessionID
smoker
smokerStatus
startTime
startTime
status
studentID
studentStatus
studentStatus
StudentType
User
userID
From User; stored as a RelationshipType; the users
relationship status.
enumerator; a type of relationship status to be used in
the system; valued: Single, Dating, Married, DivorcedSingle, Divorced-Dating.
enumerator; the mode of a restriction used in the
system; values: Allow, Deny, None.
Entity type that contains information about restriction
on a given experiment.
From User; stored as a string; the section of the class
that the user is enrolled in.
Entity type that contains information about a session of
an experiment.
From Participation; Foreign key; the ID of the session
associated with that participation.
From User; stored as a boolean; whether or not the
user smokes.
From Restrictions; stored as a boolean; a restriction
based on whether a participant smokes, or doesn’t
smoke.
From AvailabilityTimeslot; stored as datetime; the time
that the AvailabilityTimeslot starts.
From Session; stored as datetime; the time that the
session begins.
From Participation; stored as a participationStatus; the
status of the given participation.
From User; Unique; stored as a string; a users university
ID number;
From Restrictions; stored as a StudentType; the school
year of the participant.
From User; stored as a StudentType; the school year of
the user.
enumerator; a type of student to be used in the system;
values: Freshman, Sophomore, Junior, Senior.
Entity type that contains information about a user of
the system.
From AvailabilityTimeslot; Foreign key; stored as an
integer; the ID number of the user with the current
AvailabilityTimeslot.
userID
userID
From Participation; Foreign key; the ID of the user that
belongs to the participation.
From Owner; Foreign key; stored as an integer; the ID
number for the user who owns an experiment.
userId
From UserRestriction; Foreign key; stored as an integer;
the ID number of the user being restricted.
userName
From User; Unique; stored as a string; the username
that is used to log in to the system.
Entity type that contains information about a restriction
of an experiment based on a specific user.
UserRestriction
userRestrictionMode
userType
UserType
From Experiment; stored as a RestrictionMode; the
mode of restriction based on users.
From User; stored as a UserType; the user's type,
participant, experimenter, or coordinator.
enumerator; a type of user to be used in the system;
values: Participant, Experimenter, Coordinator.
Modules
Because our project is implemented largely in PHP, an imperative language, all
data is held in a database, and the code connecting the database and the interface will be very
thin, we do not have a typical object model. What we have done is divided our functionality
into a number of modules. In this section we will list and describe all modules and describe the
associated interface page(s).
Interface Overview:
P
E
C
Restrictions
Login
P/E
E/C
C/P
Add/Modify
Experiment
Registration
Main
C/E/P
C/P
P/E
P
Profile
Search
Experiments
Current
Experiments
Availability
Edit
E
Schedule
C/E
Confirmation/
Approval
C
Users
C
Semester
C
Admin
C
Stats
Profile
List Experiments
Search
E/C
Monthly
Sessions
Add
Experiment
Delete
E/C
Experiment
Modify
E/C
Experiment
Weekly
Schedule
Confirmation
Approve
Experimenter
Approve
C
Experiment
Approve Late
E
Cancelation
Confirm
E
Participation
C
Admin
Daily sessions
Detail view
Add
Session
Delete
E/C
Experiment
Modify
E/C
Experiment
Give
E/C
Ownership
E/C
Add session
E/C Add Session
Delete
Session
Adjust
E/C
Status
Cancel
P/E/C
Participatoin
E/C
P
Users
C
Add User
C
Delete User
E/C
Search
P/E/C
Modify
Profile
Sign up
Ownership
Semester
Close
C
Registraition
End
C
Semester
C
Make Report
This diagram shows all the interfaces without module constraints. The lines in the diagram
represent a major link, and the arrows represent the typical workflow.
Module Overview:
P
E
P/E
C
E/C
Restrictions
C/P
Add/Modify
Experiment
Main
C/E/P
C/P
P/E
P
E
Schedule
C/E
Confirmation/
Approval
C
Users
C
Semester
C
Admin
C
Stats
Search
Confirmation
Approve
Experimenter
Approve
C
Experiment
Approve Late
E
Cancelation
Confirm
E
Participation
Add
E/C
Experiment
Delete
E/C
Experiment
Modify
E/C
Experiment
C
Daily sessions
Detail view
Add
Session
Delete
E/C
Experiment
Modify
E/C
Experiment
Give
E/C
Ownership
E/C
Confirmation
Management Module
Admin
Add session
Delete
Session
Adjust
E/C
Status
Cancel
P/E/C
Participatoin
P
Users
Weekly
Schedule
Registration
E/C Add Session
E/C
Profile
Admin Module
Login
Monthly
Sessions
List Experiments
Profile
Search
Experiments
Current
Experiments
Availability
Edit
C
Add User
C
Delete User
E/C
Search
P/E/C
Modify
Profile
Sign up
Ownership
Experiment Management Module
Session Management Module
User Management Module
Login
Management
Module
Semester
Close
Registraition
End
C
Semester
C
C
Make Report
Semester
Management
Module
Database
Abstraction
This diagram outlines the different modules and the interfaces for them. The interfaces
have been moved so that they can be grouped with the module that they belong to.
Datatypes will be described in terms of PHP associative arrays in the form:
Name_of_data_type(
‘name_of_atribute’ => data_type_of_atribute, description of atribute
)
Functions will be described in the form:
Name_of_function($parameter)
Description of function
Interfaces will have prototype samples, an explanation of the different variations of the
interface between different user classes which users will have access to the interface and
different situations where the interface might be used, a description, and a listing of the most
typical use cases that would use the interface, including the intended steps they would take,
with the ones specific to the interface in bold.
User Management:
The user management module is responsible for adding, removing, and modifying users,
and their associated attributes. In addition to the standard attributes, users also have a list of
demographic information and an availability schedule. The availability schedule is a collection
of time blocks that define when a participant is available to participate in an experiment
session.
Data Structures:
user(
‘id’=> int; a unique identifier for this user,
‘student_id’ => string; the user’s university id number,
‘user_name’ => string; unique name chosen by the user,
‘user_type’ => enum; the classification for a user can be participant, experimenter or coordinator,
‘first_name’ =>string; the user’s first name,
‘last _name’ => string; the user’s last name,
‘email’ => string; the user’s email address,
‘phone_number’ => string; the user’s phone number,
‘password’ => string; a hash string generated from the user’s password,
‘class’ => string; the psychology class that the use ris currently enrolled in, if any,
‘section’ => string; the section number of the class,
‘gender’ => character; m or f,
‘date_of_birth’ => datetime; the user’s birthday,
‘ethnicity’ => enum; Caucasian, Black/African American, Hispanic, Asian, Pacific Islander, Native
American,
‘student_status’ => enum; Freshman, Sophomore, Junior, Senior,
‘smoker’ => boolean; whether or not the user smokes,
‘drinker’ => enum; None, Moderate, Heavy,
‘relationship_status’ => enum; Single, Dating, Married, Divorced-Single, Divorced-Dating
)
time_block(
‘id’=> int; a unique identifier for this time block,
‘start_time’ => datetime; start of the time block,
‘end_time’ => datetime; end of the time block
)
Functions:
user_add($user_info)
This function adds a user using the data in $user_info. $user_info is of type user.
Returns the ID of the new user added to the table.
user_remove($user_id)
This function removes the user identified by $user_id. Returns nothing.
user_modify($user_id, $user_info)
This function modifies a user identified by $user_id using the data in $user_info. Returns
false if the user does not exist, true otherwise.
availability_add ($start_time, $end_time, $user_id)
This function adds a time block for the user defined by $user_id (defaults to the
currently logged in user), that starts at a relative timestamp defined by $start_time (datetime,
representing time since 12:00am Sunday), that runs until another relative timestamp defined
by $end_time. Returns id of the new slot or false on failure.
availability_ get($user_id)
Returns an array containing all time blocks for the given $user_id (defaults to the
currently logged in user)
availability_ remove ($timeslot_id)
Removes the timeslot identified by $timeslot_id.
Interface:
User Listing
Add User Delete Selected Users
Name
Email
User Type
Filter
filter
filter
John Smith
(details)
jsmith@siue.edu
Experimenter
Jane Smith
(details)
janesmith@siue.edu
Coordinator
Chris B.
(details)
chrisb@siue.edu
Participant
Mike A.
(details)
mikea@siue.edu
Participant
Alex T.
(details)
alext@siue.edu
Participant
The user listing is used anytime an experimenter or coordinator would need to view a list of
users, this can be found in the context of owner listing and similar situations. When used for
experiment owner listing this interface will merely show the names of the experimenters and
options specific to that situation, such as remove ownership. When a coordinator goes to
view the list of users they will be given user management options such as add user, remove
user, etc.
User Listing Use Cases:
Experimenter gives ownership to another experimenter





Experimenter logs in
Clicks on ‘Current Experiments’
Clicks on ‘View Details’
Clicks on ‘Owners’
Clicks on ‘Add Owner’


Places a check next to the name of every experimenter that they want to add ad owners of the given
experiment
Clicks on ‘Make Selected Users Owners’

Is returned to the ‘Owners’ page
Experimenter limits participation to a specific list of students





Experimenter logs in
Clicks on ‘Current Experiments’
Clicks on ‘View Details’ (or clicks on 'Edit' on the experiment list)
Clicks on 'Modify Details' (bypasses this if clicked on 'Edit' previously)
Clicks on 'Edit Restrictions'



Checks 'Restrict participants to selected' check box
Clicks on 'Permitted participants'
Clicks on 'Add participants'


Places a check next to the name of every participant that they want to add as permitted participants of the
related experiment
Clicks on ‘Make Selected Users Permitted Participants’

Is returned to the ‘Owners’ page
Coordinator adding users (late)


Coordinator logs in
Click ‘User’

Click ‘Add User’

Fill in necessary profile fields for user
Coordinator removing a user


Coordinator logs in
Click ‘User’

Click ‘Remove’ on desired users
User Details
Demographic Information
User Type:
Gender:
Student ID:
Date of Birth:
Username:
Ethnicity:
First Name:
Student Status:
Last Name:
Smoker:
E-mail:
Drinker:
Phone Number:
Relationship Status:
Password:
Note: This information is only used for filtering
search results
Verify:
Cancel
Submit
This page provides an interface for allowing a user to input information about a user or
to view information about a user. It is used in the context of user registration and
modifying the information of an existing user. The fields for user type, student id, and
user name are only available in the registration interface. In order to view another
user’s profile, a read only version of this page is used, except for the coordinator who
has authority to make changes to other user’s profiles.
User Details Use Cases:
New user registers for the system



Start at login page
In the new users portion, click the “Register” button
Registration page opens



Fill in the fields listed under new user registration
Fill in the fields listed under demographic survey
Click the submit button

The main form appears
User changes profile


User logs in
Click ‘Profile’



Modify Profile page appears
Make appropriate changes
Click ‘Submit’
Weekly Availability Schedule
Click on a cell to change your availability for that time on that day.
-
+
means you are unavailable at the time
means you are available
Weekly Availability
Time
Sun
Mon
Tue
Wed
Thur
Fri
Sat
8:00am
-
+
-
+
-
-
-
8:15am
-
+
-
+
-
-
-
8:30am
-
+
+
+
+
-
-
8:45am
-
+
+
+
+
-
-
9:00am
-
-
+
-
+
-
+
-
+
9:15am
-
-
+
-
+
9:30am
-
-
-
-
-
-
+
9:45am
-
-
-
-
-
-
+
Start Time:
8:00am
End Time:
10:00am
Update Schedule
Submit
The availability module’s interface is only available to the participant user class and the
coordinator user class in the context of modifying a participant’s profile.
A user would click on a 15 minute time block to change it toggle it between available
and unavailable, the system would optimize there choices to use a minimum of actual
database timeblocks.
A user would have the ability to specify a time range to use.
Changes would not take effect until the submit button was pressed.
Availability Use Cases
New participant registers for the system and logs in for the first time






Start at login page
In the new users portion, click the “Register” button
Registration page opens
Fill in the fields listed under new user registration
Fill in the fields listed under demographic survey
Click the submit button




Is taken to the availability interface
[maybe change the default timeframe]
Clicks on the timeslots that they are typically free
Clicks on the submit button

The main form appears
Participant changes their weekly availability schedule

Participant logs in

Clicks on the availability link

[maybe change the default timeframe]

Clicks on the timeslots that they are typically free

Clicks on the submit button
Session Management Module
The session manager module is responsible for displaying and updating experiment
sessions and participations in those sessions, and displaying summary information about
sessions, participations for sessions, or experiments that a set of sessions is involved with.
A ‘session’ is a time and location when an experiment will be conducted by a single
experimenter.
A ‘participation’ is the action of a participant participating in a session.
Data Structures:
session(
‘id’=> int; a unique identifier for this session,
‘experiment_id’ => int; a unique identifier for the experiment that will be conducted,
‘experimenter_id’ => int; unique identifier for the experimenter running the session,
‘start_time’ => datetime; start of the session,
‘location’ => string; description of the location where the session will be conducted,
‘max_participants’ => int; the number of participants who are allowed to participate
)
participation(
‘id’=> int; a unique identifier for this participation,
‘session_id’=> int; a unique identifier for the associated session,
‘status’=> enum, the status of this participation, can have the following values:
signed_up, the user has signed up for the session, but has not yet been confirmed to have
participated,
participated, the user has been confirmed to have participated,
no_show, the user has been confirmed to have not participated when they should have,
request_cancel, the user wanted to cancel their participation, but they are not permitted to do
so at the time they attempted to do so.
)
Functions:
session_add($experiment_id, $experimenter_id, $start, $location, $participants)
This function adds a session for the experiment identified by $ experiment_id, to be conducted
by the experimenter identified by $experimenter_id, that can have a number of participants
not exceeding the number provided by $participants, should start at the time specified by
$start, and will be conducted at a location described in $location.
session_cancel($session_id)
Cancels a session identified by $session_id. This will also implicitly cancel all associated
participations.
participation_add($session_id, $participant_id)
Adds a participation for a session identified by $session_id, for the user identified by
$participant_id. This will implicitly set status to ‘signed_up’. Will return the id of the new
participation or false if it failed.
participation_cancel($participation_id, $notify)
Removes a participation identified by $participation_id, will send a notification email to the
involved participant if $notify is true (defaults to true).
participation_request_cancel($participation_id)
Sets the status of the participation identified by $participation_id to ‘request_cancel’,
the experimenter who is running the session will be prompted to approve the cancelation
upon their next login.
participation_confirm($participation_id , $confirm)
Sets the status of the participation identified by $participation_id to ‘participated’ if
$confirm is true, or ‘no_show’ if false.
Interface:
Monthly session and participation view
Experiment Search Results: Monthly Calendar View
Please select a day to view individual sessions for that day
< Last Month
Week
Sun
April
Mon
1
Next Month >
Tue
Wed
Thur
Fri
Sat
(1)
NONE
(2)
NONE
(3) today
NONE
(4)
24 open
(5)
NONE
2
(6)
NONE
(7)
17 open
(8)
NONE
(9)
2 open
(10)
NONE
(11)
NONE
(12)
NONE
3
(13)
NONE
(14)
NONE
(15)
19 open
(16)
NONE
(17)
NONE
(18)
NONE
(19)
NONE
4
(20)
8 open
(21)
NONE
(22)
NONE
(23)
NONE
(24)
19 open
(25)
NONE
(26)
12 open
5
(27)
NONE
(28)
19 open
(29)
3 open
(30)
NONE
Used for displaying information about a large number of sessions and/or participations
spanning a number of days and summarizing it allowing the user to find a smaller subset
pertaining to a single day. Is available to all users seeking to view a list of sessions or
participations, but is usually only shown when there are a lot of items spanning a lot of days.
The days would show different information depending on the specific purpose it was called
for. Clicking on information within a day cell would direct the user to a daily view showing the
relevant information for the day clicked on.
Could be used to display available sessions for one or more experiments found in a
search for participants, days would show number of sessions available. Could also be used by
an experimenter to display all sessions for one or more experiments the will be conducting,
days would show number of sessions and/or number of participations on that day.
Monthly View Use Cases:
Participant signs up for experiment

Participant logs in

Clicks ‘Search Experiments’

[maybe Enters in a date range or other search criteria]

Hit’s search [results are auto generated if javascript is available]

Clicks on the ‘sign up’ link

From the monthly session view they click on a the number next to the word open (will only show monthly view
if number of days is greater than 1)

They find a time slot they like and click ‘sign up’

{acknowledge confirmation dialog}

Are taken to ‘current experiments’ page
Experimenter views or performs action on session

Experimenter logs in

Clicks on ‘Current Experiments’

Clicks on sessions (is taken to monthly sessions)

Clicks on the day of the session they want to view/perform action in the monthly view

Performs actions on sessions listed for that day.
Daily session view
Daily Sessions Available
Daily sessions on
Previous Day
Time
Between
April 11, 2009
Experiment Title (#)
and
Next Day
Sign Up
Filter
Credits
Filter
8:00am - 8:30am
Conformity Under Social Pressure (33715)
Sign Up (5 left)
0.5
8:30am - 9:00am
Conformity Under Social Pressure (33715)
Sign Up (3 left)
0.5
9:00am - 9:30am
Conformity Under Social Pressure (33715)
Sign Up (1 left)
0.5
9:00am - 9:30am
Group / Selective Perception (91522)
Sign Up (2 left)
0.5
9:30am - 10:00am
Conformity Under Social Pressure (33715)
Sign Up (4 left)
0.5
9:30am - 10:00am
Group / Selective Perception (91522)
Sign Up (4 left)
0.5
Search Experiments | Monthly Session View| Current Participation Schedule
Used for displaying information about a list of sessions. Typically the list of sessions will
be short and/or for one day, but could be any number of sessions spanning any number of
days.
This view is used by many different user classes and under many different situations.
For participants it is used to display the search results, sowing non-conflicting sessions
for one or more experiments
For experimenters it is used to display a list of sessions for experiments they are
conducting. It can also be used to display a list of participations in a list of sessions they are
participating in. in this case each session in the list would be followed by all the participations.
Coordinators would also have access to these views, but it would not be restricted to only one
experimenter as it is in the experimenter view.
Daily View Use Cases:
Participant signs up for experiment

Participant logs in

Clicks ‘Search Experiments’

[maybe Enters in a date range or other search criteria]

Hit’s search [results are auto generated if javascript is available]

Clicks on the ‘sign up’ link

From the monthly session view they click on a the number next to the word open

They find a time slot they like and click ‘sign up’

{acknowledge confirmation dialog}

Are taken to ‘current experiments’ page
Experimenter views or performs action on session

Experimenter logs in

Clicks on ‘Current Experiments’

Clicks on sessions (is taken to monthly sessions)

Clicks on the day of the session they want to view/perform action in the monthly view

Performs actions on sessions listed for that day.
o
o
Add session

Clicks on the add session link

Fills out the information in the add sessions page

Clicks submit
Cancel session

Clicks on the cancel link for the session they want to cancel
Add Session
Add Sessions for Experiment
Experiment
Date
Start Time
Conformity Under Social Pressure (33715)
April 11, 2009
8:00am
End Time
3:00pm
Experiment duration is 30 minutes
Number of Sessions
14
Participant Limit
25
Location
Peck Hall, Room # 2330
Submit New Sessions
Used by experimenters and coordinators to add one or more experiment sessions. It is
required that the experiment is added and approved by a coordinator (unless the coordinator
adds it them self) before sessions can be scheduled. User provides the necessary information
and the system will add the proper number of sessions to fill in the time window specified. An
alternate interface we have considered involved specifying a start time and a number of
sessions.
Add Sessions Use Cases:
Experimenter adds sessions

Experimenter logs in

Clicks ‘Current Experiments’

[maybe clicks on details]

Clicks on ‘Sessions’

Clicks on ‘add session’ or ‘add’ in one of the dates of the monthly view

Fills out the information in the add sessions page

Clicks ‘submit new session’
Database Abstraction Module
The database abstraction is a collection of functionality intended to make database
operations easier, perform basic validation, and be less DBMS dependent. Common operations
are broken down into functions reducing the need to make SQL query strings on the fly. Often
a ‘search key’ will be used; this is an associative array with a name-of-column => value-ofcolumn relationship, this is generally used in situations where a SELECT statement or similar
would be used. This module has no user interface as it is only a utility module.
Functions:
database_get_single_result($query_string)
database_get_single_result($table, $search_keys)
This function returns an associative array, representing the first result of $query_string, or of
rows identified by $search_keys on a table by the name passed in $table.
database_get_ results($query_string)
database_get_ results($table, $search_keys)
This function returns an array of associative arrays, representing all results of $query_string, or
of rows identified by $search_keys on a table by the name passed in $table.
database_row_set($table_name, $search_keys, $value)
This function takes on the roll of setting data in a table. $table_name is the name of the table
to perform an action on. $search denotes which rows in the table should be updated. If a
string “new” is passed for the $search parameter, an insert operation will be performed. The
function will return an array containing the primary keys of all rows affected.
database_row_delete($table_name, $search_keys)
This function deletes the rows identified by the $search_keys.
Admin Module
The admin module is for performing administrative tasks mainly creating and restoring
from backups for coordinators. It is available only to coordinators.
Functions:
admin_make_backup ($backup_name)
This function creates a backup of the system of the given backup name. It returns true or false
depending on if the backup is created or not.
admin_restore_backup ($backup_name)
This function restores a backup of the system from the given backup name. It returns true or
false depending on if the system is returned to the backup’s state.
admin_list_backups()
This function returns an array of strings representing the list of files available to be restored
from.
admin_export ($format)
This function exports the system to a given file format given by the variable $format. It returns
a file handle, or false if it fails.
Interface:
General Administration
Archived Semesters
Backup Database
Restore From Backup Database
Export Data Microsoft Excel
This is the general administration page. It offers options for administrative tasks.
Administrative tasks are only available to coordinators.
Admin Use Cases:
Coordinator backing up database


Coordinator logs in
Click ‘Admin’



Click ‘Backup Database’
Choose the backup destination (default: C: Drive)
Choose the backup folder (default: /backup)
Coordinator Export Data


Coordinator logs in
Click ‘Admin’




Click ‘Export Data’
Click the desired info to export
Download dialog screen
Click ‘Save’
Semester Module
Data Structures:
statistics (
‘approved_user_count’=> int; number of users who are available during a semester,
‘unappoved_user_count’=> int;number of users who have been denied access,
‘approved_experiments_count=> int; number of experiments that have been approved for the
semester,
‘unapproved_experiments_count=> int; number of experiments that have not been approved for the
semester,
‘approved_students_complete_count=> int; number of users that have been approved for the
semester and completed the required number of hours,
‘approved_students_incomplete_count=> int; number of users that have been approved for the
semester and have not completed the required number of hours
)
report_info(
‘student_id’ => string; the user’s university id number,
‘user_name’ => string; unique name chosen by the user,
‘first_name’ =>string; the user’s first name,
‘last _name’ => string; the user’s last name,
‘email’ => string; the user’s email address,
‘phone_number’ => string; the user’s phone number,
‘class’ => string; the psychology class that the use ris currently enrolled in, if any,
‘section’ => string; the section number of the class,
‘gender’ => character; m or f,
‘date_of_birth’ => datetime; the user’s birthday,
‘ethnicity’ => enum; Caucasian, Black/African American, Hispanic, Asian, Pacific Islander, Native
American,
‘student_status’ => enum; Freshman, Sophomore, Junior, Senior,
‘smoker’ => boolean; whether or not the user smokes,
‘drinker’ => enum; None, Moderate, Heavy,
‘relationship_status’ => enum; Single, Dating, Married, Divorced-Single, Divorced-Dating,
‘hours_completed’ => int; the number of hours the user has completed
)
Functions:
semester_get_statistics($semester)
This function takes in the name of a semester; if no semester is given it defaults to the current
semester. This function returns statistical information of the form of a statistics structure.
semester_enable_registration($enabled)
This function enables or disables registration for the current semester. It returns nothing.
semester_get_report_data($column_description)
This function takes in an array that contains the names of the columns requested. It defaults
to all columns, and returns an array of report_info with only the passed values included.
semester_archive($new_semester_name, $credit_hour_max)
This function takes in the name of the semester to be created after the current semester is
archived and the maximum number of credits that can be participated in for the new
semester. It returns true or false depending on whether or not the archive was complete and
new semester is created.
Interface:
Statistics
Semester: Fall ‘09
Number of Approved Users: 30
Number of Unapproved Users: 10
Number of Approved Experiments: 20
Number of Unapproved Experiments: 10
Approved students with completed hours: 12
Approved students with uncompleted hours: 18
View / Edit Semester Report
This is the statistics interface. It shows statistics for the current semester of previous
semesters. It is used as the default interface for the coordinator assuming there are no
approvals pending.
Semester: Fall 2009
Registration: Open
View / Edit Semester Report
End Current Semester
This is the semester interface. It provides an interface for the coordinator to access semester
functionality.
Semester Interface Use Cases:
Coordinator closing the current semester


Coordinator logs in
Click ‘Semester’

Click ‘End Current Semester’



Click ‘Print Report’, if necessary
Click ‘Cancel’, if you do not want to create a new semester at that moment
Click ‘Create New Semester’, if desired
Coordinator close / open registration


Coordinator logs in
Click ‘Semester’

Click dropdown menu and choose closed or open registration
Create Semester
In order to close the current semester, a new one must be created
Name of Semester:
Spring 2009
Max Number of Credit Hours: 6
Create
Cancel
This is the create semester interface. It allows the coordinator to set up a new semester.
Create Semester Use Cases:
Coordinator c0losing the current semester



Coordinator logs in
Click ‘Semester’
Click ‘End Current Semester’

Click ‘Print Report’, if necessary

Click ‘Cancel’, if you do not want to create a new semester at that moment

Click ‘Create New Semester’, if desired
Semester Report: Fall 2009
Edit Report
Print Report
Fall 2009
Psychology 101 Section 001
SID
First Name
Last Name
Complete Hours?
800395481
Donald
Duck
No
800025482
Bruce
Wayne
No
800847321
Bill
Goldberg
Yes
Psychology 101 Section 002
SID
First Name
Last Name
Complete Hours?
800395483
John
Doe
Yes
800025484
Jane
Doe
Yes
800847325
Bruce
Banner
Yes
Psychology 101 Section 003
SID
First Name
Last Name
Complete Hours?
800395486
Daffy
Duck
No
800025487
Mark
Elliot
Yes
800847328
Bill
Wayne
No
This is the semester report interface. It allows the coordinator to configure and print a report
for the semester.
Semester Report Use Cases:
Coordinator printing report


Coordinator logs in
Click ‘Semester’

Click ‘View/Edit Semester Report’

Click ‘Edit’, if the fields desired are missing to add them
o
Highlight desired fields
o
Click the arrow to move the fields to be ‘displayed fields’

Click ‘Print Report’
Semester: Fall 2009
Not Displayed Fields
Displayed Fields
Number of Hours Completed
Necessary Hours
Username
Age
Gender
Smoke?
Drink?
Date of Birth
Student Status
Ethnicity
Student ID (SID)
First Name
Last Name
Completed Hours?
Save
Cancel
This is the report configuration interface. It is used by the semester report interface for
configuring the report.
Report Configuration Use Cases:
Coordinator printing report



Coordinator logs in
Click ‘Semester’
Click ‘View/Edit Semester Report’


Click ‘Edit’, if the fields desired are missing to add them
o Highlight desired fields
o Click the arrow to move the fields to be ‘displayed fields’
Click ‘Save’

Click ‘Print Report’
Login Module
The login module is responsible for logging users in and keeping track of which users are
currently logged in i.e. the current user. It will also be responsible for password recovery.
Functions:
login ($user_name, $password)
This function will log the user in to the system assuming their user name and password are
valid. It returns true if the username and password match a username and password pair in
the system, false otherwise.
login_get_current_user_id()
This function will return the users id if that user is currently logged in, and false if the user is
not currently logged in.
Interface:
Log In
Returning Users
Username:
Password:
Forgot Password?
OK
New Users
Register
This is the login interface. It provides functionality to log a user into the system and keep track
of who is currently logged in. It will also provide a link to the new user registration interface.
Password recovery will also be handled by the login interface.
Report Configuration Use Cases:
Returning user logs into the system



Start at login page
In the returning users portion, fill in the username and password
Click ok

The main form appears
New user registers for the system and logs in for the first time


Start at login page
In the new users portion, click the “Register” button





Registration page opens
Fill in the fields listed under new user registration
Fill in the fields listed under demographic survey
Click the submit button
The main form appears
User recovering password


Start at login page
Click “Forgot Password?” link




Password recovery page opens
Fill in username and email
Click ok
Feedback page appears letting the user know that an email has been sent to them
Experiment Management Module:
The experiment management functionality of this module is responsible for adding,
editing, and viewing experiments.
The searching functionality for this module is responsible for providing a search
interface for posted experiments; experiments can be searched based on various criteria, e.g.,
only show experiments that have sessions that fall between a specified date range.
The experiment listing functionality of this module is responsible for displaying the
experiments that match specified search criteria.
Data Structures:
experiment(
‘id’=> int; a unique identifier for this experiment,
‘primary_owner’=> int; a user_id identifier specifying primary owner,
‘name’=>string; the name of the experiment,
‘credits’=>rational number; the amount of credits that this experiment is worth, e.g, 0.5
credits,
‘abstract’=>string; a brief description of the experiment,
‘description’=>string; a long description of the experiment,
‘ethnicity_restriction_mode’=>enum, specifies how the associated ethnicity
requirement list will relate to this experiment. It can have any one of following values:
allow, only permit the ethnicities specified in ethnicity restriction list to sign up,
deny, do not allow the ethnicities specified in ethnicity restriction list to sign up,
none, this experiment does not have any ethnicity restrictions
‘user_restriction_mode’=>enum, specifies how the associated user requirement list will
relate to this experiment. It can have any one of the following values:
allow, only permit the specific users specified in user restriction list to sign up,
deny, do not allow the specific users specified in user restriction list to sign up,
none, this experiment does not restrict on the basis of specific users
‘owner_ids[]’=>array of ‘user_id’ elements specifying which experiment user types own
this experiment
‘user_restriction_ids[]’=>array of ‘user_id’ elements specifying specific user restrictions
for this experiment; refer to ‘user_restriction_mode’ to see how this array applies the
restrictions to this experiment
‘ethnicity_restriction_ids[]’=>array of ‘user_id’ elements specifying ethnicity restrictions
for this experiment; refer to ‘ethnicity_restriction_mode’ to see how this array applies
the restrictions to this experiment
‘prerequisite_experiment_ids[]’=>array of ‘experiment_id’ elements specifying which
experiments are a perquisite to signing up for this experiment.
‘session_ids[]’=>array of ‘session_id’ elements specifying the sessions belonging to this
experiment.
‘demographic_restrictions’=>demographic_restrictions; specifies the demographic
restrictions requirements this experiment
)
demographic_restrictions(
‘gender’=>character, m for male, m for female, null for no gender restriction
‘smoker_status’=>boolean, true if requires participant to be smoker, false otherwise
‘drinker_status’=>enum; none, moderate, heavy
‘relationship_status’=>enum; single, dating, married, divorced-single, divorced-married
‘minimum_age’=>int, minimum age participant can be
‘maximum_age’=>int, maximum age participant can be
‘student_status’=>enum; freshman, sophomore, junior, senior
‘other_requirements’=>string, used for specifying custom restrictions
)
NOTE: the arrays in the experiment data type will be associative many-to-many relations in our
relational database implementation. For design purposes, it helps to think of these relations as
arrays. Additionally, the ‘demographic_restrictions’ compound attribute will be a separate
table with a one-to-one relationship with this experiment. The reason why we will not
implement ‘demographic_restrictions’ as an attribute for ‘experiment’ type is because some
experiments will not have any demographic restrictions and we wanted to reduce redundancy.
Moreover, we wanted to make it easier to extend the demographic requirements at a later
point if the need should arise.
Functions:
get_experiments_matching($user_id, $after_date, $before_date, $keywords, $credits,
$availability_schedule)
This function returns a list of experiments matching the specified search criteria.
NOTE: If the end-user client is Ajax-capable, PHP will convert results from a database query for
experiments matching the specified search criteria into an XML document (for the purpose of
programmatic manipulation by a client running Javascript). For clients without Ajax capability,
PHP will return an HTML document containing the experiments matching the specified search
criteria.
$after_date: the date that sessions scheduled for experiments must be after. ‘NULL’ for
no limit, which is the default.
$before_date: the date that sessions scheduled for experiments must be before. ‘NULL’
for no limit, which is the default.
$keywords: this will be for a partial string match on title, description, or abstract. ‘NULL’
for no limit, which is the default.
$credits: the number of credits to search for. ‘NULL’ for no limit, which is the default.
$availability_schedule: boolean; if true, only show experiments that have sessions
compatible with the availability schedule associated with $user_id. Default is ‘false’.
$user_id: the unique identifier for the user to provide search results for. This is used for
properly filtering experiments based on the user’s availability schedule and
demographic data.
get_demographic_restrictions($experiment_id)
This function returns the $demographic_restrictions structure for this experiment.
change_demographic_restrictions($experiment_id, $demographic_restrictions)
This function changes demographic restrictions. The parameter $demographic_restrictions is a
demographic_restrictions structure.
get_ethnicity_restrictions($experiment_id)
This function returns a list of enum elements; Caucasian, Black/African American, Hispanic,
Asian, Pacific Islander, Native American
NOTE: refer to $ethnicity_restriction_mode to see how the list restricts the participants
set_ethnicity_restrictions($experiment_id, $ethnicities[])
This function sets the ethnicity restrictions for this experiment to the ethnicities in the
$ethnicities[] array.
get_user_restrictions($experiment_id)
This function returns a list of user_id elements that have a restriction on this experiment.
NOTE: refer to $user_restriction_mode to see how the list restricts the participants
add_user_restriction($experiment_id, $user_id)
This function adds the ethnicity restrictions in the $ethnicities[] array to this experiment.
get_prerequisite_experiments($experiment_id)
This function returns a list of experiment_id elements which are prerequisites for this
experiment. If a participant has not previously participated in one or more of these
prerequisites, he or she is restricted from participating in this experiment.
add_prerequisite($experiment_id, $prerequisite_id)
This function adds experiment specified by $prerequisite_id to this experiment.
get_owners($experiment_id)
This function returns a list of user_id elements corresponding to which users are registered as
owners for this experiment.
add_owner($experiment_id, $user_id)
This function adds an owner to this experiment.
remove_owner($experiment_id, $user_id)
This function removes an owner from this experiment.
change_primary_owner($experiment_id, $user_id)
This function changes the primary owner of this experiment.
change_experiment($experiment_id, $primary_owner, $name, $credits, $abstract,
$description, $ethnicity_restriction_mode, $user_restriction_mode)
This function changes this to have the values indicated by its parameters for each
corresponding attribute. A null parameter indicates no change for the corresponding attribute.
Interfaces:
Search Experiments
Between
Any date
Search
and
Credits
Any date
Keywords
Only show results compatible with my availability schedule
X
This is the primary interface for providing the end-user with the functionality to only
show experiments that match user-specified search criteria. The functionality has already been
described in the definition of the get_experiments_matching() function.
If the client is Ajax-capable, the pane below the search criteria interface will dynamically
update in real-time by including only those experiments that match the user-specified search
criteria. If the client is not Ajax-capable, the user will be required to click the “Search” button
to update the results.
Search Results: Experiments (Participant)
Experiment #1 (0.5 credits / hours)
Date: Today @ 10:00 am Location: AH 1234
This is an abstract. An abstract is a brief description. To view more details, click on Details. To
sign up for this experiment, click on Sign Up.
Restrictions: None
Details Sign Up
Date: 4/26/09 @ 2:00 pm Location: AH 1234
Study of Male Aggression (0.5 credits / hours)
This is an abstract. An abstract is a brief description. To view more details, click on Details. To
sign up for this experiment, click on Sign Up.
Restrictions: Males only
Details Sign Up
Date: 5/3/09 @ 12:00 pm Location: AH 1034
Study of Female Aggression (1.0 credits / hours)
This is an abstract. An abstract is a brief description. To view more details, click on Details. To
sign up for this experiment, click on Sign Up.
Restrictions: Females only
Details Sign Up
Here is the interface component showing the results of the experiments matching the
user-specified search criteria. The results will be shown below the primary search interface
described previously.
Clicking on the ‘Details’ link brings up the ‘Experiment Details’ view of the associated
experiment. Clicking ‘Sign Up’ will bring up either the Monthly View or Daily View interfaces
for sessions, depending upon the number of sessions for the experiment and the number of
days that the sessions span over.
Experiment Details (Coordinator / Experimenter)
Study of Male Aggression (0.5 credits/hours)
This a study that is designed to reveal if there is a correlation between participating in
extended meetings and male aggression.
Contact: John Smith (jsmith@siue.edu )
Restrictions
Must be male.
Owners (Add More)
John Smith (details) (remove)
Phone: (618) 254-8888
Email: jsmith@siue.edu
Jane Smith (details) (remove) (set primary)
Phone: (618) 254-1111
Email: janes@siue.edu
Description
This is a long description. This is a long description. This is a long description. This is a long
description.
This is a long description.
This is a long description.
This is a long description.
Edit Add Session Sessions
This is the experiment details user interface for coordinator/experimenter (if an owner). This
interface is for showing extended details for experiments, and modifying experiment details.
The participant view is similar but lacks the editing options.
Restrictions
Allow only the following
Deny the following
Do not limit
Gender
Smoking status
User Name
Drinking status
BillyK (Remove)
MarkE (Remove)
Relationship status
Minimum age
Add the following participants:
(username, separate by comma)
Maximum age
Prerequisite Experiments
Ethnicity
Conformity Under Social Pressure (33715) (Remove)
Do not limit
Add the following experiments:
(experiment #, separate by comma)
Additional Restrictions
Allow only the following
Deny the following
Asian
Native American
Black/African
Pacific Islander
East Indian
White
Latino/Hispanic
Other
Middle Eastern
Cancel
Submit
This is the experiment restrictions user interface. One can only arrive at this page by clicking
on the ‘Edit Restrictions’ link in the experiment details view. This is where an experimenter or
coordinator specifies the requirements for an experiment.
Add Experiment Owners
Select an experiment to add owners to:
Conformity Under Social Pressure (33715)
Check the experimenters who should have co-ownership of the selected experiment
Select Owners
Username
Filter Both
Filter
Select This User
JaneD
X Select This User
BillyK
X Select This User
MarkE
OK
Cancel
This is the experiment owner’s user interface. Here, one can add or remove owners for an
experiment. This page is also reused for specifying specific individual user restrictions for an
experiment.
Add/Edit Experiment (Coordinator)
Experiment Name:
Credits:
Abstract:
Restrictions:
Edit Restrictions
Description:
Cancel
Save
This is the add/edit experiment coordinator user interface. Here, one can edit the details of a
particular experiment. Only coordinators and experiment owners can access this interface. The
experimenter’s interface for this is similar except that it lacks the ability to change the credit
value; that’s an exclusively coordinator privilege.
Experiment Management Use Cases
Participant signs up for experiment

Participant logs in

Clicks ‘Search Experiments’

[maybe Enters in a date range or other search criteria]

Hit’s search [results are auto generated if Javascript is available]

Clicks on the details link [or the title] of an experiment

From the details page they click sign up

From the monthly session view they click on a the number next to the word open

They find a time slot they like and click ‘sign up’

{acknowledge confirmation dialog}

Are taken to ‘current experiments’ page
Experimenter posts experiment

Experimenter logs in

Clicks ‘Current Experiments’

Clicks ‘Add Experiment’

Fills out new experiment information

Submits and is returned to the ‘Current Experiments’ page

[maybe adds sessions from ‘Current Experiments’ experiment list]
Experimenter changing experiment description

Experimenter logs in

Clicks on ‘Current Experiments’

Clicks on details

Makes changes to the description

Clicks the ‘save’ button
Experimenter gives ownership to another experimenter

Experimenter logs in

Clicks on ‘Current Experiments’

Clicks on ‘View Details’

Clicks on ‘Owners’

Clicks on ‘Add Owner’

Places a check next to the name of every experimenter that they want to add ad owners of the given
experiment

Clicks on ‘Make Selected Users Owners’

Is returned to the ‘Owners’ page
Experimenter limits participation to a specific list of students

Experimenter logs in

Clicks on ‘Current Experiments’

Clicks on ‘View Details’ (or clicks on 'Edit' on the experiment list)

Clicks on 'Modify Details' (bypasses this if clicked on 'Edit' previously)

Clicks on 'Edit Restrictions'

Checks 'Restrict participants to selected' check box

Clicks on 'Permitted participants'

Clicks on 'Add participants'

Places a check next to the name of every participant that they want to add as permitted participants of the
related experiment

Clicks on ‘Make Selected Users Permitted Participants’

Is returned to the ‘Owners’ page
Experimenter limits participation to only students who are over the age of 23 and smoke

Experimenter logs in

Clicks on ‘Current Experiments’

Clicks on ‘View Details’ (or clicks on 'Edit' on the experiment list)

Clicks on 'Modify Details' (bypasses this if clicked on 'Edit' previously)

Clicks on 'Edit Restrictions'

Checks ‘Has minimum’ check box

Previous action enables lower limit input box

Enters '23' (initially 0)

Selects 'Must be a smoker' in the smoking status drop-down menu

Clicks on the 'Save' button
Confirmations:
The confirmations module is responsible for managing the confirmations for the
coordinator and experimenter user types. There are three types of confirmations:
1. Coordinator confirms request by a user to be elevated to experimenter user type
2. Coordinator confirms request by an experimenter to post an experiment
3. Experimenter or coordinator confirms that a participant took part in a session that he
or she signed up for
Data Structures:
user_type_confirmation(
‘id’=> int; a unique identifier for this change user type confirmation,
‘user_id’=>int; a unique user identifier,
‘user_type’=>enum; the status of the user type can be ‘experimenter’, ‘coordinator’, or ‘participant’
‘request_date’=>date; the date this request to change user type was made
‘confirmation_status’=>enum; the status of the
)
NOTE: we may generalize “user_type” so that it specifies more fine grained control over privileges.
‘experimenter’, ‘coordinator’, and ‘participant’ would just by default specify certain privileges for each of
those user types.
experiment_confirmation(
‘id’=>int; a unique identifier for this allow experiment post confirmation,
‘experiment_id’=>int; a unique identifier for the experiment awaiting confirmation
‘request_date’=>date; the date this request to post experiment was made
)
Functions:
approve_user_as_experimenter($user_id)
This function approves user identified by $user_id as an ‘experimenter’ user type. Returns true
if successfully changed, false if not, e.g., $user_id does not exist.
deny_user_as_experimenter($user_id)
This function denies user identified by $user as an ‘experimenter’ user type. Returns true if
successfully denied, false if not, e.g., $user_id does not exist.
approve_experiment($experiment_id)
This function approves experiment identified by $experiment_id for posting. When this
happens, the experiment becomes available on the server for adding sessions to, signing up
for, etc. This function returns true if successfully approved, false if not, e.g., $experiment_id
does not exist.
deny_experiment($experiment_id)
This function denies the posting of the experiment identified by $experiment_id. Returns true
if successfully denied, false if not, e.g., $experiment_id does not exist.
approve_late_cancelation($user_id, $session_id)
This function approves a late request to cancel participation in a session uniquely specified by
$session_id by the user uniquely specified by $user_id
NOTE: We may expand this module so that change_experiment_approval_status(…) becomes
a useful function, e.g., coordinator is not whether to approve a particular experiment, so he or
she clicks on the option to dismiss it until a specified date (defaults to tomorrow) so that it
doesn’t clutter up confirmations list until then.
Interfaces:
Confirmations (Coordinator)
Items Awaiting Confirmation
Approve Posting of Experiment: Date Requested – 5/5/2009
Study of Female Aggression
This is an abstract. An abstract is a brief description. To view more details, click on Details.
Restrictions: Females only
Credit Worth:
Details Deny Confirm
Approve User As Experimenter: Date Requested – 5/7/2009
Chris Ballenger
Phone: (618) 254-8888
Email: chrisb@siue.edu
Details Deny Confirm
This interface is used to show coordinator items awaiting his or her approval. This is the
view that the coordinator’s user interface defaults to, since this is probably the most
important function for the coordinator and, without almost daily attention, the number of
items awaiting approval may get quickly out of hand. Items that have been waiting the longest
for approval will be shown first. When the coordinator denies or confirms an item, it
disappears from view and the confirmations below it slide up to fill the empty space. There will
also be a filtering mechanism in place to show only certain items, e.g., only show
experimenters awaiting approval, or more specifically, show only experimenters awaiting
approval whose names partially match a specified search term.
NOTE: We may also include the following:
1. A “Dismiss” option to help the coordinator manage approvals.
2. Name/email/phone number of the owner of the experiment awaiting approval.
3. A “Details” link to the experiment awaiting approval so that the coordinator can get a
detailed view of the experiment under consideration.
Participant Confirmation
Confirm
Username
Date
Session Time
Experiment
Filter
Filter
Filter
Filter
confirm
deny
John Doe
4/1/2009
9:00am-9:30am
Study of Male Aggression
confirm
deny
BillyK
4/1/2009
9:00am-9:30am
Study of Female Aggression
confirm
deny
MarkE
4/2/2009
12:30pm-1:00pm
Experiment #1
This interface is used to show experimenters the participants awaiting confirmation over
whether they participated in their scheduled experiment. This is the view that the
experimenter’s user interface defaults to, since this is one of the most important functions for
the experimenter. It is similar to the coordinator’s view, except that it provides a more
condensed presentation of the confirmation entries based on the grounded assumption that
the experimenter will generally have more confirmations to attend to than the coordinator.
Confirmation Use Cases
Experimenter confirms participant participated

Experimenter logs in

<Default main page is the confirmation page>

Is presented with a list of participants who should have participated by now but who’s status is still ‘signed
up’

Item disappears from the list
Conclusion
Currently, the Psychology Department manages their experiment participation pool with
a non-automated paper filing system:
1. Scheduling is done by posting paper forms
2. Signing up for experiments can only be accomplished by having students trek to
the required location
3. Searching for experiments must be done manually
4. Participation is tracked by an unreliable and insecure card and stamp system
5. Creating the participation record at the end of the semester is done by hand
This is a repetitive, error-prone, and needlessly labor-intensive process. A primary role
for computer systems is to automate such processes, thus reducing the need for human
intervention. This has two primary benefits: it liberates humans from repetitive tasks which
they are not well suited for, and it eliminates most human error caused by repetition from the
process.
It is for this reason that our client, Dr. Mike Dudley, contacted the CS department with
his senior project proposal. He wants a software solution that will automate, or at least
simplify, most of the work that humans must presently do. It must keep track of what students
have done, it must automate most of the searching tasks, it must eliminate most of the traveltime required to manage the system, and it must automate the work of producing
participation reports. As a side-effect of this automation, we can also expect there to be much
less [human] error.
In this document, we have presented a design that will not only meet these
requirements, but exceed them.
How do we meet the requirements?
 Student participation tracking will be accomplished with a simple point-and-click
interface
 Experiment searching will be accomplished with an easy-to-use Google-like search
interface for posted experiments
 Nearly every facet of the system can be managed by any Internet-connected computer
 Participation reports can be generated with the click of a button
How do we exceed the requirements?
 Our basic version of the web-application will be usable by any computer—even on older
systems that do not have a GUI. However, if the client is capable, our system will
gracefully improve the user-interface, e.g., using Ajax to provide real-time search results
as the user types in search criteria.
 We automate at least some aspects of the demographic survey given to students at the
beginning of semesters. The system will use this information to prevent students from
signing up for experiments they are not eligible for.
 The participation report generator is customizable by the coordinator