final paper - Course Website Directory

cuttlefishblueΔιαχείριση Δεδομένων

16 Δεκ 2012 (πριν από 4 χρόνια και 8 μήνες)

437 εμφανίσεις


1

1
. Introduction

There are many applications emerging in the computing world that are provided through websites. For
instance, Yahoo! offers web
-
based e
-
mail, web
-
based calendar, and web
-
based calendar applications. One of the
advantages of these applica
tions on websites is that they accessible on any computer with an Internet browser.
No longer is one limited to local application software that is machine and operating system dependent. In
addition, software upgrades are not necessary since the provider
of the website is responsible for development
and upgrades. The majority of applications on websites are currently tailored to the individual. Websites allow
users to setup customized homepages for the use of these website applications such as My Yahoo!
The broad
objective of this project is to take this to another level and provide group
-
based customized homepages for the
use of some website applications. The specific objective of this project is to create an intelligent group
management website named e
-
Group.

This website provides website applications to improve group communication, management, and
information sharing. These website applications are dynamic and adaptable to the unique characteristics of
different types of groups. The website applicati
ons that this project implements are a discussion board, search
capability, shared web links, and calendar. All of the website is protected by a cookie
-
based user authorization
scheme.

An example of a group that can utilize e
-
Group website to improve

its group communication and
management is an ECE 345 project team. The first person to setup the new group enters the group information in
addition to their own user information. The other members of the group then each enter user information and
select

to join the existing ECE 345 project group already created. This is all that is necessary to setup a group on
the e
-
Group website. The group members then have their own discussion board, shared web links, group
calendar, and individual calendars. The d
iscussion board has the capability to attach files to messages and links.
The calendar has the capability for the group administrator to automatically schedule a meeting based on the
individual calendars of the individuals included.

The three main compon
ents of this system are the web server, relational database, and website
applications (see Figure 1.1). For this project the web server is a Linux machine running Apache web server
software. The relational database is the PostgreSQL database software for

Linux. The website applications are
written in Perl with embedded Common Gateway Interface (CGI), Hypertext Markup Language (HTML), and
Structured Query Language (SQL). The website applications were divided into main subprojects which were
each develope
d by a project member. First, the web server and software modules were installed and testes.
Second, the database was installed and database built. Third the website applications developed. These were
divided into three parts. The user login authoriza
tion, group profile, and user profile was developed a one
subproject. Second, the discussion board, links, search, and website layout was developed as another subproject.
Third, the calendar, including group and individual events, and meeting scheduler,
were developed as the other
subproject. All of these subprojects were developed with integration specifications so that integration of the
components was possible.


















Figure 1.1

System Overview


Database
Main Navigation
Page
Main Navigation
Page
Search
Search
Calendar
Calendar
Web Server
Security
Website
Discussion
Board
Discussion
Board
Profile
Profile
Links
Links
Database
Main Navigation
Page
Main Navigation
Page
Search
Search
Calendar
Calendar
Web Server
Security
Website
Discussion
Board
Discussion
Board
Profile
Profile
Links
Links


2

2
. Design Procedure


2.1 Web Server

The serv
er is a main component of this project. It was important to decide upon a reliable and robust
server early on in the project, because it would be difficult to switch to a different operating platform and
machine once the project was underway.

There were se
veral choices of server available. When considering operating systems, one naturally first
thinks of Microsoft Window NT system or for the more technical savvy, a Solaris Sparc server. However both
these choices involve a high start up and maintenance cost
, which was not practical for a project of this size.
Linux, an UNIX
-
like operating system (OS), however, waived all the previously disadvantages. Linux is a very
popular modular operating system that can download freely from the Internet. By choosing a Re
d Hat Linux
distribution, installation was much simpler and maintenance was provided with package management, graphical
system control, and system administration tools. The integrated open source development effort and wide
distribution of Linux OS shared
by a large computing community, are features that commercial OS developers
cannot offer.


The web server software chosen to run on this Linux platform is Apache Web Server. This software is an
open source freely distributed on the Internet. In addition,
Apache has extensive support and documentation
available on the Internet. These advantages made it an ideal choice to fit with the Linux server. In addition, this
combination of Linux and Apache is widely used on the Internet and proven an effective web

server combination
according to
Pitt
and Ball [5].


2.2 Database

A relational database was chosen to store the information necessary for the website applications. A
relational database is a proven, efficient, and easily adaptable and upgradeable type o
f database. In addition, a
relational database allows the use of SQL, a standard language that allows simple or complex queries of the
database. The constraints for the database were cost, complexity, and technical support. After evaluating these
constr
aints, a PostgreSQL database software package for Linux was chosen. PostgreSQL is a free open source
database software package distributed form the University of California at Berkley. The software package has
moderate complexity, that is, enough funct
ionality to handle the design of this project’s, while the complexity is
not too high for the resources of this project group. There also exists a large amount of technical support
available on the Internet. This is an important factor, since the install
ation of a large software package on Linux
can be challenging.


3


3. Design
Details


3.1 Web Server

In order to write dynamic and secure web pages, one turns to CGI


Common Gateway Interface. CGI is
the common glue that binds different network protocols a
nd other information technology together.
Unfortunately, CGI is not the most efficient run
-
time environment. Every time the web server needs a CGI script,
the server must set up the CGI environment, read the script into main memory, and then run the scrip
t. As load
increases, this process creates bottlenecks that worsen exponentially, and eventually halt the web server.

To work around the problem of CGI, Server Application Programming Interfaces (API) was employed.
Mod_perl is one such module use to write

server API. Mod_perl stands for modular Perl [1]. Developers extend
the functionality of the server by linking new modules directly into the server executable. Since the developer
uses the Perl interpreter within the Apache web server, Apache handlers wri
tten entirely in Perl step into each
phases of Apache. This process greatly increases the speed of pages dynamically created by CGI scripts or by
other means. A summary of the software and modules installed on the web server is listed in Table 3.1 below.



Table 3.1.

Summary of Web Server Software and Modules

Software

Description

Red Hat Linux 5.2

Linux operating system

Mod_Perl 5.45

Apache Perl Interpreter

ApacheDBI 0.87

This module is a Perl interface to a relational database. Apache::DBI cache the
database connection on a child thread upon start up. Any successive call to DBI
connect() will be identify by unique data source name.


DBD
-
Pg

=
M.9P
=
周q猠mod畬攠comp汥浥n瑳=A灡捨攺:䑂䤠瑯=wo牫r睩瑨=~=偯獴杲g猠s~瑡扡獥s獹s瑥t
=
ro䤠1.MQ
=
jod畬攠瑨~琠獴数猠s
nto=ro䤠瑲tn獬~瑩tn=灨p獥猠瑯=m~步k~=癩牴畡氠l楲i捴潲礠浡灳pon瑯=
瑨攠牥~氠灨祳楣i氠l楲i捴潲礮
=
=
䍇䤠C.RS
=
=
周q猠mod畬攠em灬o祳=th攠敭扥dd敤=健m氠楮瑥t灲整e爠to=汯~d=䍇䤠獣C楰琠楮瑯=th攠s敲癥爠
m敭o特r灥牳楳瑥湴汹.
=
j䐵
J
1.T
=
健m氠楮瑥tf~捥=瑯=瑨攠opA=a~瑡=p散u
物瑹⁉湣⸠j䐵=j敳獡来
J
䑩来獴⁁汧o物rhm
=
=
A灡捨攠業灬pm敮瑳=楴i=mod畬敳⁴uro畧h=楴i=A偉⸠A灡捨攠A偉⁨m猠s=獥s楥猠潦i灨ps敳e敶敲礠y汩敮琠eeq略獴猠
杯敳eth牯r杨.=周攠扥h~癩vr=of=瑨攠睥戠獥癥爠d数敮摳eon=th攠h~nd汥l=瑨~琠th攠d敶敬潰敲猠sm灬敭pn瑳.==A=汩s琠潦t

汥癡n琠th~獥猠sh~琠瑨t猠灲oj散琠to=楮瑥t牵r瑳=楳=l楳瑥t=in=呡扬攠P.O=扥汯眮
=
=
=
=
=
Table 3.2
. Summary of Apache Phases

Phase

Description

URI
-
File name translation

Matches IP the URL requested with a filename on the system

Authentication checking

Verifies us
er’s identity
=
A畴uo物r~瑩on=ch散歩ng
=
噥物r楥猠畳敲=楳=~畴ho物r敤=to=灲o捥獳=牥q略獴u
=
j䥍b
J
瑹灥td整e牭楮~瑩on
=
䍨散歳⁴h~琠瑨攠牥q略獴敤=o扪散琠楳⁡=瑥t琯htm氬l~畤楯L睡瘬=業~来gj灥朠
o爠o瑨敲=t祰攠f楬敳
=
䙩硥s
=
j~步k~dj畳um敮瑳=n散敳獡特r獯=th攠獥s癥爠捡n=灲
o捥獳=瑨攠牥q略u瑳
=
io杧ing
=
乯瑥猠th攠楲i敧畬e牳rof=牥qu敳e
=

4



3.2 Database

The relational database software package installed is PostgreSQL version 6.5.2 for i486 Linux. This
package was installed using the pre
-
compiled binaries available on the PostgreS
QL homepage [6] and the Red
Hat package manager. After the database was successfully installed and tested, the next step was setting up the
database created for e
-
Group. This database was designed to store the information needed for the website
applicati
ons. Each website application has a table associated with it and contained in that table are fields that
store the information. In order to link the information in each of the tables, there is a key field that is repeated in
any of the tables that need t
o share information. An overview of the database for e
-
Group is in Figure 3.1. The
exact table information including table names, field names, and field characteristics is contained in Appendix 1.
After the database for e
-
Group was setup, the users and p
ermissions for the database required configuration. The
members of the project team were given full permissions to the database including table creation, table dropping,
and table updating. In addition, a user named “nobody” was given permission to read
and update the tables of
the database. This user is used for the web access to the database. Here permissions are restricted to the access
required by the website applications.























Figure 3.1
. Database Overview


The next set in the dat
abase setup was the creating a set of test data that was necessary for the
development and testing of the website applications. An ECE 345 project team served as the model for the test
data. This test group has all of the information necessary for the de
veloping and testing. It contained group
information, three users, discussion board messages, links, and calendar events.

After the database, users and permissions, and test data were all setup, the next step was to begin to
develop the web and database

interface. PostgreSQL has numerous ways to interface to it and retrieve data in a
number of different programming languages. A Perl interface was chosen for the web and database interface.
This was chosen because there exist modules that allow for both

embedded web programming and embedded
database programming. Specifically, the Perl module Pg.pm was used at first for this database interface. This
module contains all of the commands to embed submit SQL code and parse the resulting data from the
Postgr
eSQL database. Combining this with the CGI.pm module used for web programming in Perl, a web and
database interface was successfully setup and tested.

Upon further research into database interaction and Apache web server software, it was determined that
a different Perl module named DBI.pm provides much higher performance [8]. This module is based on the Perl
Database Interaction standard and has different syntax than Pg.pm. Consequentially, the web and database
interaction was re
-
written to utilize the
advantages of DBI.pm. This web and database interaction was tested and
Groups
Users
Users
Demographics
Users Contact
Groups
Calendar
Users
Calendar
Groups
Keywords
Users
Keywords
Bboard
Bboard
upload
files
Links
Groups
Users
Users
Demographics
Users Contact
Groups
Calendar
Users
Calendar
Groups
Keywords
Users
Keywords
Groups
Groups
Users
Users
Users
Demographics
Users
Demographics
Users Contact
Users Contact
Groups
Calendar
Groups
Calendar
Users
Calendar
Users
Calendar
Groups
Keywords
Groups
Keywords
Users
Keywords
Users
Keywords
Bboard
Bboard
Bboard
upload
files
Bboard
upload
files
Links
Links


5

documentation sent to the project members for a reference during their development of website application
subprojects.


During the course of development of the project, there were so
me minor additions made to the database
for e
-
Group. All of these changes were documented and tracked in the form of table versions. Through the
course of the project there were a total of six versions, the latest being the version implemented for the fi
nal demo.
Please note the not all of the tables in the database are in use due to these design changes. The database was
backed
-
up on a weekly basis in case of data corruption or server failure. The database was also optimized weekly
through the use of

the optimization scripts provided in the PostgreSQL software package.


3.3 Website Layout

The web interface was designed for maximum efficiency and ease of use. A frame
-
based web interface
was chosen to achieve these goals. Along the left side of the br
owser screen there is a navigation frame that
contains links to all of the website applications. The frame on the remaining portion of the browser screen is for
the website applications. This type of frame
-
based web interface is setup in the main HTML fi
le. It defines the
two frames and the target of links clicked in the navigation frame is the other frame. In addition to the frame
-
based layout, a common set of styles is defined. This is accomplished through the use of an HTML 3.0 standard
called Casca
ding Style Sheets (CSS). A style sheet contains style definitions for all of the HTML tags. The two
main advantages of CSS are that styles are common throughout the website and that changes in style to the entire
website need only be made in the style d
efinitions file [2]. In order for a HTML file to utilize these common CSS
definitions, any HTML file need only import the definition at the top in the header section. For this project the
style sheet contains definitions of color, font, alignment, backgr
ound images, and other elements on the e
-
Group
website.


3.4 Login

For the login phases, several handlers were written to implement the Apache server authorization and
authentication phases. A cookie base access control was chosen for this scheme for two i
mportant reasons. First,
user authentication via a database lookup over a network is slow. If this system was expanded to multiple servers
and one common database, the overhead required process the network requests and database interaction is not
feasible

every time the user accesses a page on the website. In addition, if the database request were complex, the
time it takes to process the request on the server would slow this process down even more. Second, there are
security issues to consider when usin
g a common authentication database. If the database holds confidential
information, it is a security hole if all the web servers have free access to the database. A break
-
in on any of the
web server would comprise the confidentiality of the information.

Th
e module Apache::TicketAccess was written to provide a cookie base access control where user
authentication is expensive. Instead of performing full authentication every time a page is requested, a user only
authenticates against a relational database only

once at the very first time the user connects. Upon each
subsequence access, the module issues the user a “ticket”. The ticket is a HTTP cookie that carries the user’s
name, IP address, expiration date and a cryptographic signature. The user can use the
ticket to gain access to the
allowed area on the server.

The modules Apache::TicketAccess, Apache::TicketTool and Apche::TicketMaster interrupt the
authentication handler of Apache. They then logs onto the database and perform an authentication lookup usi
ng
functions from Perl DBI. Once the request is validated, TicketMaster transmits the input and statistical
information back to the server which responds back to the client. The entire process is transmitted through
encrypted packages. Although the channe
l is not secure, the chance of interception and decryption is not likely.
Finally, TicketMaster calls the URI phase and directs the request to the correct PageEngine function and
dynamically creates the requested page with CGI. The result of the about Apac
he phase interruptions and
modules is a secure and efficient login scheme for the e
-
Group website.


3.5 Profile

In order for the authentication and authorization to work, a user must have an account on the e
-
Group
database. A new user to the e
-
Group webs
ite is prompted to enter user information such as a username,
password, and e
-
mail address. The user is also prompted whether to join an existing group or to create a new
group. If a user joins an existing group, then the user proceeds to that group’s ma
in page. If the user instead
creates a new group, the user will be prompted to enter group information. When a user creates a new group, this
user is automatically identified as the administrator of the group.


6

There are three different access levels cur
rently implemented into this project. The administrator has the
highest access level and can perform the most functions. The next access level is a user of the group, who can
perform all of the functions necessary, but not administer the group. The last

access level of the project is a
visitor, which has read
-
only access to a group. These access levels are implemented in the functions described
below by utilizing the ticket login scheme.

Creating a new user or a new group goes through the same encryptio
n phase and then the client signals
the server to request an update on user’s data in the database. This
create group

and
create user

function is written
in Apache::CreateGroup module and Apache::Join module.



3.6 Discussion Board

The discussion board has

many components that presented a programming challenge. This was
overcome by breaking down the development of the discussion board into five subparts. These subparts are the
main discussion board, read a message, reply to a message, post a new message,
and delete a message. The
discussion board main page displays the current messages with title, author, date information, and attachment
information. The
read a message

function allows the user to read the contents of the message body and also view
the at
tached links and files. The
reply to a message

function allows the user to reply to a message listed on the
discussion board main page. The
post a new message

function allows a user to compose a message and attach a
link and file. The
delete a message

f
unction allows a user to prevent a message from being displayed on the
discussion board main page. For an overview of the discussion board function see Figure 3.2 below. All of these
functions are based on the access level of the user see the Table 3.3

below.










Figure 3.2
. Discussion Board Overview





Table 3.3
. Discussion Board Functions by Access Level

Administrator

User

Visitor

Display Messages

Display Messages

Display Messages

Message Read

Message Read

Message Read

Message Reply

Mes
sage Reply


Post Message

Post Message


Delete Message




These functions were implemented as separate Perl scripts with embedded CGI and HTML for web
display and embedded SQL for database interaction. The bboard and bboard_upload_files tables are used

to
store information for the discussion board. In addition, the groups and users tables are used to gather the group
and author information respectively. All of these functions have tests to ensure that users enter valid data. For
instance if a user d
oes not enter a title or a body in a message, the users is informed with an error message and
prompted to enter the missing field.

The user’s identity is verified before showing any information from the database. This is verified by
looking at the “ticke
t” generated by the Apache server when the user logs onto the system. By determining the
user’s ID and group ID, the privilege of the user in obtained for access to the proper functions. For instance, only
if the is a user is the administrator of a group

can the user delete a message from the discussion board. Between
each PERL program, URL parameters are used to pass variables. For example to pass the message ID of a
message the URL is represented by:

http://adp
-
91.csh.uiuc.edu/perl/bb_read.pl?msg_id=2
1

This link tells the message reading program, bb_read.pl, to read the message with message ID equal to 21.

This same format is used to pass parameters between the other parts of the discussion board as well.

Reply to Message
Read Message
Post Message
Delete Message
Display Messages


7


3.7 Search

The search capability of the e
-
Grou
p website allows a user to search the entire e
-
Group database for
information. The two main options of the search function are search type and search areas. The search type
offered is a Boolean AND search or a Boolean OR search based on the words entered

by the user. The search
areas offered is in the user and group keywords, discussion board, and links. The search type default is a Boolean
AND, while no search areas are selected as default. For an overview of the search capability see Figure 3.3 below
.















Figure 3.3.

Search
Overview


This function was implemented with embedded CGI and HTML for web display and embedded SQL for
database interaction. The entire search function is implemented by creating SQL query statements based on the
use
r’s search options. The SQL query statements search these tables: users_keywords, groups_keywords, bboard,
and links. In addition, the groups and users tables are used to gather the group and author information
respectively. There is limited user error
checking on this function because the interface dictates the choices to the
user in the form of check boxes.


3.8 Links

The links capability of the e
-
Group website allows a users to share links to the Internet. The links
function is divided into three sub
parts. The subparts are the links main page, add a link, and delete a link. The
links main page displays the group’s links with link title, link submitter’s name, date, and link description. For
an overview of the links function see Figure 3.4 below. T
hese subparts are limited by the user’s access level as
seen in Table 3.4.





Figure Links Overview








Figure 3.4
. Search Overview






Table 3.4
. Links Functions by Access Level

Administrator

User

Visitor

Display Links

Display Links

Di
splay Links

Add Link

Add Link


Delete Link






These functions were implemented as separate Perl scripts with embedded CGI and HTML for web
display and embedded SQL for database interaction. The links table is used to store information for the links
f
unction. In addition, the groups and users tables are used to gather the group and submitter’s information
respectively. All of these functions have tests to ensure that users enter valid data. For instance a user must
AND
OR
Search Type
Keywords
Discussion Board
Links
Search Area
Search

Add Link
Delete Link
Display Links


8

enter “http://’ or “https://” at

the beginning of a link. If this is left out, the user is informed with an error
message and prompted to enter link correctly.

The user’s identity is verified before showing any information from the database. This is verified by
looking at the “ticket”
generated by the Apache server when the user logs onto the system. By determining the
user’s ID and group ID, the privilege of the user in obtained for access to the proper functions. For instance, only
if the is a user is the administrator of a group ca
n the user delete a links from the links page. Between each PERL
program, URL parameters are used to pass variables. For example to pass a link URL to the delete link script the
URL is represented by:

http://adp
-
91.csh.uiuc.edu/perl/delete_link?link_URL=”
http://www.uiuc.edu”

This link tells the link
-
deleting program, delete_link.pl, to delete the link with URL equal to
“http://www.uiuc.edu.” This same format is used to pass parameters between the other parts of the links
function as well.


3.9 Calendar

Th
e calendar function of this project consists of a monthly calendar for user events and a meeting
scheduler for groups. The monthly calendar has functions to retrieve an event, add an event, delete an event, and
display the monthly calendar. An overview o
f the monthly calendar is shown in Figure 3.5. The meeting
scheduler is a function for the group administrator to automatically setup group meetings at a time when all
group members have free time.






















Figure 3.5
. Calendar
Overview


Whe
n a user first enters the calendar page, a monthly calendar of current month is displayed as well as a
list of the events for the current day. The monthly calendar is presented in an HTML table format with each day
containing a link to the events for that
date. In addition, the user can click on “next >>” or “<< prev” links to
display the next month or the previous month. This provides a simple and effective interface for a user to
display events for any date.


Another function available to a user ca
n also add events to his calendar. The event
-
adding function first
checks the validity of the input data: event title and description must not be blank, duration time must not be
zero, and the input date must be correct (e.g. Feb 30
th

is not allowed). If

any of the above errors are found, the
function prompts the user for a revise the entry. Once the entry is valid, it then contacts the database to check if
the entered event time and duration time collides with any other events in the database that belon
g to the user. If
any conflicting events are found, the function prompts the user to revise the entry. An event that passes through
all the validity tests is finally written to the user’s schedule.


The user also has the ability to delete events from t
he calendar. The user simply clicks on the “delete
event link” and the system prompts the users to make sure. If the deletion is confirmed, then the event is deleted
form the calendar and the database immediately updated.


Another feature of the calendar

enables a group’s administrator to add an event, such as a group meeting,
to all of the group members’ individual calendars at a time that is suitable for all group members. The interface
for the meeting scheduler is similar to the individual event
-
addin
g function, with the added feature of more
flexible time allocation. Instead of prompting an administrator to input the exact date and time of an event as in
the event
-
adding function, the meeting scheduler lets the administrator input a range of days an
d times for a
Retrieve events of the day
Delete event
Add event
Show monthly calendar
Calendar
Retrieve events of the day
Delete event
Add event
Show monthly calendar
Calendar


9

meeting. A series of data validity tests are then performed to ensure the following: the user has the
administrative privilege of the group, event title and description are not blank, the input date is valid, the earliest
possible time is ea
rlier than the latest possible time, enough time is available for the expected duration of the
event, and finally that the estimated duration of time is not zero.

After successful completion of those tests, the meeting scheduler then proceeds to contact th
e database to
determine the earliest free time available on all group members’ schedule. If this database query finds that the
meeting collides with any events of a group member, then the query will be performed again with the start time
delayed. It con
tinues this process until a suitable time is found for the group event. If a time slot cannot be found
on the proposed day, then the same procedure will be applied on the next day, until the last allowed day is
reached. If such a time slot is still not f
ound, the administrator is prompted to revise the meeting entry. When a
suitable time is found, the event is automatically added to all group members’ schedule


These functions were implemented as separate Perl scripts with embedded CGI and HTML for web
d
isplay and embedded SQL for database interaction. The users_calendar and groups_calendar tables are used to
store information for the calendar function. In addition, the groups and users tables are used to gather the group
and user information respective
ly.

Between each PERL program, URL and Hidden parameters are used to pass variables. For example to pass the
date of the calendar or event_id of an event the URL is represented by:

http://adp
-
91.csh.uiuc.edu/perl/list.pl?Showd=1
-
11
-
1999

This link tells th
e event listing program, list.pl, to list all events dated 1 Dec, 1999 (Note that in PERL, months are
represented by a list (0,1,2,…,11) for (Jan, Feb,… ,Dec)).

The user’s identity is verified before showing any information from the database. This is veri
fied by looking
at the “ticket” generated by the Apache server when the user logs onto the system. By determining the user’s ID
and group ID, the privilege of the user in obtained for access to the proper functions. For instance, only if the is a
user is

the administrator of a group can the user run the group meeting scheduler.

The calendar is calculated on each page according to the Doomsday Rule [3]. A summary of the Doomsday
rule is listed below. The implementation of the calendar, the Doomsday Rule i
s applied once to the first day of the
month. The day of week of other days are calculated as the offset from the first day with a “mod 7” calculation.



Number 0 to 6 are used to represent Sunday, Monday, till Saturday.



Set the Doomsday of each year as the

Doomsday of the last day of that year’s February.



Doomsday 1900 is 3; Doomsday 2000 is 4.



The Doomsday of each 19xx year can be calculated as

o

Doomsday 1900 + xx + [xx/4]



The Doomsday of each 20xx year can be calculated as

o

Doomsday 2000 + xx + [xx/4]



Each

month has a Doomsday too, the list of 12 months are:

o

(31, 28, 7, 4, 9, 6, 11, 8, 5, 10, 7, 12) for common years; or

o

(32, 29, 7, 4, 9, 6, 11, 8, 5, 10, 7, 12) for leap years



Therefore, for a given dd/mm/yy, the Doomsday of the date is:

o

{ (Doomsday yy)
-

[
(Doomsday of mm)


(dd) ] } mod 7


3.10 Integration of
functions

The project was divided into three subparts, namely, namely “Login, Profile”, “Search, Discussion Board,
Links”, and “Calendar.” An overview of how these three parts integrate is shown belo
w in Figure 3.6.











Figure 3.6
. Integration
Overview


Discussion Board
Search
Links
Calendar
Login
Profile


10

On top of the diagram is the “Login Profile”, where all users must pass through before accessing any
functionality of the group managing website. After the user has logged on, a ticket generat
ed by the Apache
server is passed to each function page with the user’s username stored in it. At each function page, this ticket is
read to retrieve other information about the user and provide the proper services to the user. This information
provided
in the “Login Profile” is the main specification necessary to integrate all of the components.



11

4. Design
Verification


4.1 Testing

The testing required for this software project differs from that of a hardware project. The main areas of
testing of th
e project involve functionality tests and user error checking. The testing of functionality was carried
out in two stages. First, each function was tested independently during its development for the desired results.
For example, the discussion board wa
s developed and tested until it functioned correctly. The next stage of the
testing was of the integrated system. Once all of the subprojects were working and the integration was
completed, the functions needed to perform the same as prior to integration
, along with the added component of
user recognition. A test group modeled after this project team was entered in the database to test the
functionality of the individual components and the entire system.

The other main testing that occurred was in the f
orm of user error checking. Because the audience that
might use this website has varying degrees of computer experience, a thorough checking of user inputted data is
necessary. This is accomplished in the actual coding of the website applications. There

are many references to
this in the Design Details chapter of this report. One example user error checking is in the calendar function.
When a user enters an event for instance, one test is that the ending time is later than the starting time. This is j
ust
one example of the many user error tests that are performed inside the website applications.



4.2 Web Server Performance

The web server performance is based on three main factors. These factors are the s
cript interpreter,
coding techniques, and serve
r hardware [7]. These factors were optimized based on the resources of the project.
The first two factors were within the group’s control and were optimized through the use of mod__perl and DBI
as discussed in the Design Procedure chapter. The third fac
tor is based on the memory and processor running the
web server applications. Since this project was borrowing a server for free, any changes to this factor were not
possible.

The web server was tested using a benchmark utility provided with Apache name
d ApacheBench [7].
This utility simulates access to a web site and measures the resulting performance. For this test, the utility is run
for an increasing number of users all accessing the same page on the website. The results of this test provide
perfo
rmance information of which number of requests processed per second is the most relevant source of
performance data. The results of the tests are graphed below in Figure 4.
1
.





















Figure 4.1

Web Server Performance
0.00
2.00
4.00
6.00
8.00
10.00
12.00
1
2
3
4
5
6
7
8
9
10
Number of Users
Requests Processed
Per Second


12



5.
Costs

The main

cost of this project is in the labor costs. All of the software used f or the creation of this website
is open
-
source and distributed freely on the Internet. The web server is on loan from a colleague, but if it needed
to be purchased an estimated cost
for a low
-
end web server is approximately $2,500. The other parts costs are
associated with the Special Circuit, but these components are very common and inexpensive. The labor charges
were calculated per labor
-
hour. On average each project member spent

15 hours per week on the project for the
duration of 10 weeks. This is a total of 450 labor
-
hours at a hourly rate of $100 for a labor cost of $45,000.

A summary of the project costs is in Table 5.1.








Table 5.1.

Costs Summary

Description

A
mount

Parts


Web Server

Free

Redhat 5.2 Linux Operating System

Free

PostgreSQL Database Software

Free

Perl software and modules

Free



Special Circuit

$5



Labor


450 person
-
hours

$45,000



Parts Subtotal

$5

Labor Subtotal

$45,000

Project T
otal

$45,005






13

6. Special
Circuit


6.1 Introduction


Because this senior design project is entirely software based, a special circuit was built in order to satisfy
the course requirements. The special circuit assigned is a small signal low frequency
amplifier with a high pass
frequency response. This circuit was built, tested, and tolerances analyzed successfully.


6.2 Specifications


The assigned specifications for this special circuit are summarized in Table 6.1below.


Table 6.1.

Specifications for

Special Circuit

Specification

Value and Tolerance

Frequency response

Highpass

Rolloff

Single pole response

Gain in passband

3.4 ± 5%

Corner frequency

8.2 kHz ± 3%

Input impedance

500Ω at 1 kHz ± 5%
=

6.3 Design and Calculations

In order to build a low frequency amplifier, a common emitter circuit with emitter resistor was chosen to
output a high pass filter from Neamen [4]. The circuit layout is shown in Figure 6.1below.






















Figure 6.1
. Circuit Diagram


In order to output the desired gain and corner frequency, some reasonable resistors values were chosen,
and then the appropriate capacitance was calculated. Please see the calculations below for the details.


R1
= 12.8
kΩ; R2 = 2.4 kΩ; Rc = 1.5 kΩ; Re = 0.4 kΩ;



= 100; Icq


1.86mA; Vceq = 6.27V; Vt = 0.026V


Using time constant relation => Ts = (Rs+Ri)Cc, one can easily find the require Cc

Gm= Icq/Vt = 1.86mA/0.026V = 71.5mA/V

r


= Vt*

/Icq = (100)(0.026v)/1.86mA = 13
97.8 Ω

Ri = R1 || R2[r


(1+

)Re] = 979.0

Ts = (979.0 Ω + 100 Ω)Cc

Corner frequency = f = 8200Hz = W/2


= 1/Ts/2


= 1/2

/1079 Ω /Cc

Cc = 18nF

Ris is the resistance as seen by the input source.

Rib = Vs/Ib = r


+ (1+

)Re = 1122 Ω

Input Impedence = Ris = Rib

|| (R1 || R2)


600 Ω



14


6.4 Implementation


Not all of the parts from the design are available for the exact values required. Therefore the closest
values available were ordered. The parts were then assembled and the circuit built. The exact values for
the final
circuit are listed below in Table 6.2.






Table 6.2.

Circuit Components Used

Component

Value

R1

12.8 kΩ
=

=
2.4 kΩ
=

=
1.548 kΩ
=

=
0.4 kΩ
=

=
0.01 μF
=
呲~n獩獴or
=
乐丠䝥n敲~氠偵牰l獥sAm灬楦楥r
=

6.5 Testing

The special circuit was tested and
data collected on its characteristics. The input voltage was connected
to a function generator with a varying frequency sine wave with a peak
-
to
-
peak voltage of 1 volt. The output
voltage was measured by connecting the circuit to an oscilloscope and meas
uring the peak
-
to
-
peak voltage of the
output waveform. The frequency of the input wave was varied from 0 Hz to 50 kHz at 500Hz intervals, and the
resulting output voltage recorded. A graph of this data is shown in Figure 6.2. From this data the gain of

the
circuit was determined to be 3.375, which is within the tolerance of 5 percent of the 3.4 specification. The corner
frequency was also calculated to be 8.17 kHz based on the 3
-
decibel rule and is within the tolerance of 5 percent of
the 8.2kHz speci
fication.




































Figure 6.2.

Graph of Special Circuit Data




15

6.6 Tolerance Analysis

Two of the specifications on the circuit were varied to measure the effects on the output characteristics. First the
Rc resistor was decreased
from 1.548 kΩ to 1.500 kΩ. Data for output voltage and frequency was then collected in
the same manner as in the regular testing of the circuit. This resulted in a reduction in the gain of the circuit from
3.375 to 3.313. A graph of the results obtained

is in Figure 6.3 below. Second, the Cc capacitor was increased
from 0.01μF to 0.02 μF. Data for output voltage and frequency was then collected in the same manner as in the
regular testing of the circuit. This resulted in a reduction in the corner freq
uency from 8.17kHz to 4.1kHz. A
graph of the results obtained is in Figure 6.4 on the following page.


































Figure 6.3

Tolerance Analysis 1


16









































Figure 6.4
. Tolerance Analysis 2


17


7.
Conclusi
on


7.1 Problems and Challenges

Throughout the development and integration of the project some problems and challenges were
encountered. First, the server performance limited the number of users who could develop and test at the same
time. For instance,

if three users were logged on and all running text editors or compiling it would bring the
server to a near standstill. The group overcame this problem by using a modular design that allowed for local
machine development. Therefore the majority of the s
erver’s resources were devoted to testing, instead of text
editors and compiling.

Another problem encountered was in the installation of software. Software was not always smoothly
installed, and sometimes did not work well properly after the installation.

This problem is solved by a
collaborative effort and the use of web support (e.g. on
-
line documents, FAQ’s, and newsgroups).

In addition to these problems a more general challenge was faced by the group, that is, all members of the
group were novices at
web development and programming. This challenge was well faced by the group, which
overcame this by seeking knowledge and quickly learning new skills.


7.2 Future Improvements

While the functionality and reliability of the website is solid, there is an op
portunity for numerous future
improvements. Currently, routine server and database maintenance jobs and backup jobs are done manually.
One of the possible future improvements of this project could be to make those jobs automated by the server.
There are
a number factors about the system, like the performance rate, user access, etc., that are a concern to the
system administrators. Reporting those factors is useful in system maintenance and is also a good reference for
further development. Adding a repor
ting function is also a good future improvement of this project. The website
currently implements some basic functions for group management. One future improvement is to add more
features to the existing functions, such as a location constraint to the me
eting scheduler. There are also many
more new functions can be added, like a web auction feature, web base e
-
mail, and to
-
do lists. Integrating the
current system with an existing project planning software package could also be a good improvement which
e
nhance the functionality of the website.


7.3 Outcome of Project


Finally, after integrating all parts of the project, a web
-
based group managing we
bsite is successfully set
up and working with the desired functionalities. This project covered many areas from server selection to web
programming. The members of the group successfully learned new technical skills and applied them toward the
project ob
jective. In addition, the project management skills and team interactions required by this project
provided a valuable learning experience directly applicable in the professional world.








18


Appendix 1. Database Design
Details


Table Name

Variable

Typ
e

Null?

Description


groups

group_id

INT4

No

Primary Key




group_name

VARCHAR(100)

No

Group name




group_desc

VARCHAR(500)

No

Group description




num_users

INT4

Yes

Number of group users




group_admin_user1

INT4

Yes

User ID number of first adminis
trator




group_admin_user2

INT4

Yes

User ID number of second administrator




group_admin_user3

INT4

Yes

User ID number of third administrator




registration_date

DATE

Yes

Date of group registration




isactive

BOOL

No

Active flag, if group is active
=true




new_members

BOOL

No

Accept new members flag, if accepting
then=true








users

user_id

INT4

No

Primary key




group_id

INT4

No

Identifies users group, defaults to new user
group




first_name

VARCHAR(100)

No

Users first name




last_name

V
ARCHAR(100)

No

Users last name




email

VARCHAR(100)

No

email address of user (UNIQUE)




password

VARCHAR(30)

No

password of user




url

VARCHAR(200)

Yes

URL of users homepage




last_visit

DATE

Yes

Date of users last visit




second_to_last_visit

D
ATE

Yes

Date of users second to last visit




num_sessions

INT4

Yes

Number of times users has visited site




registration_date

DATE

Yes

Date of user registration




username

VARCHAR(100)

No

Username used for login




admlevel

INT4

No

Access level of u
ser




registration_ip

VARCHAR(50)

Yes

IP address where user registered from








user_demographics

user_id

INT4

No

Primary Key




birthday

DATE

Yes

Users birthday




priv_birthday

INT4

Yes

Level of privilege to see users birthday




sex

CHAR(1)

Y
es

Users sex (M or F)




priv_sex

INT4

Yes

Level of privilege to see users sex








users_contact

user_id

INT4

No

Primary key




home_phone

VARCHAR(100)

Yes

Users home phone number




priv_home_phone

INT4

Yes

Level of privilege to see users home pho
ne
number




work_phone

VARCHAR(100)

Yes

Users work phone number




priv_work_phone

INT4

Yes

Level of privilege to see users work phone
number




mobile_phone

VARCHAR(100)

Yes

Users mobile phone number




priv_mobile_phone

INT4

Yes

Level of privilege t
o see users mobile phone
number




pager_num

VARCHAR(100)

Yes

Users work pager number



19



priv_pager_num

INT4

Yes

Level of privilege to see users pager phone
number




m_address

CHAR(1)

Yes

Mailing address of user (W=Work,
H=Home)




ha_line1

VARCHAR(80
)

Yes

Line 1 of users home address




ha_line2

VARCHAR(80)

Yes

Line 2 of users home address




ha_city

VARCHAR(80)

Yes

City of users home address




ha_state

VARCHAR(80)

Yes

State of users home address




ha_postal_code

VARCHAR(80)

Yes

Postal code of u
sers home address




ha_country_code

VARCHAR(80)

Yes

Country code of users home address




priv_ha

INT4

Yes

Level of privilege to see users home address




wa_line1

VARCHAR(80)

Yes

Line 1 of users work address




wa_line2

VARCHAR(80)

Yes

Line 2 of user
s work address




wa_city

VARCHAR(80)

Yes

City of users work address




wa_state

VARCHAR(80)

Yes

State of users work address




wa_postal_code

VARCHAR(80)

Yes

Postal code of users work address




wa_country_code

VARCHAR(80)

Yes

Country code of users wo
rk address




priv_wa

INT4

Yes

Level of privilege to see users work address








categories

category_id

INT4

No

Primary key




caregory

VARCHAR(50)

No

Category name




isactive

BOOL

No

Active flag, equals true if category active








groups_inte
rests

group_id

INT4

No

Primary Key




category_id

INT4

No

Primary Key




interest_date

DATE

Yes

Date group registers interest in category













groups_keywords

group_id

INT4

No

group_id number




keyword

VARCHAR(50)

No

keywords used for search a
gent








users_interests

user_id

INT4

No

Primary Key




category_id

INT4

No

Primary Key




interest_date

DATE

Yes

Date group registers interest in category













users_keywords

user_id

INT4

No

user_id number




keyword

VARCHAR(50)

No

keywor
ds used for search agent








links

group_id

INT4

No

Group ID number




user_id

INT4

No

User ID number




url

VARCHAR(300)

No

Link URL




link_title

VARCHAR(100)

No

Tiltle of link URL




link_desc

VARCHAR(4000)

Yes

Link URL description




display_
link

BOOL

No

Flag to display link, equals true to display
link




isactive

BOOL

No

Active flag for link, equals true if link active




posting_date

DATE

Yes

Date link posted








search_agent_query

query_date

DATE

No

Date of query



20



query_string

VA
RCHAR(300)

No

Query string




scope

CHAR(1)

Yes

Scope of search flag, I=internal, E=external,
B=both (currently only internal)




group_id

INT4

Yes

Group ID




user_id

INT4

Yes

User ID




num_results

INT4

Yes

Number of results from query








grou
ps_calendar

calendar_id

INT4

No

Primary Key




group_id

INT4

No

Group ID




user_id

INT4

No

User ID




user_ip_addr

VARCHAR(50)

No

Users IP address when posting calendar data




event_title

VARCHAR(100)

No

Group event title




event_desc

VARCHAR(4000)

Yes

Group event description




event_start

TIMESTAMP

No

Group event start time, date




event_end

TIMESTAMP

No

Group event end time, date




event_url

VARCHAR(200)

Yes

Group event URL




event_email

VARCHAR(100)

Yes

Group event email address




event
_creation

DATE

Yes

Date of group event creation




event_expiration

DATE

Yes

Date of group event expiration








users_calendar

calendar_id

INT4

No

Primary Key




user_id

INT4

No

User ID




user_ip_addr

VARCHAR(50)

No

Users IP address when posting c
alendar data




event_title

VARCHAR(100)

No

User event title




event_desc

VARCHAR(4000)

Yes

User event description




event_start

TIMESTAMP

No

User event start time, date




event_end

TIMESTAMP

No

User event end time, date




event_url

VARCHAR(200)

Y
es

User event URL




event_email

VARCHAR(100)

Yes

User event email address




event_creation

DATE

Yes

Date of user event creation




event_expiration

DATE

Yes

Date of user event expiration








bboard

msg_id

INT4

No

Primary Key




group_id

INT4

No

Primary Key




user_id

INT4

No

User ID




user_ip_addr

VARCHAR(50)

Yes

Users IP address when posting message




user_last_login

TIMESTAMP

Yes

Users last login time, date to bboard page




msg_title

VARCHAR(200)

No

Message title




msg_body

VARCHAR(400
0)

No

Message body




msg_url

VARCHAR(200)

Yes

Message URL link




msg_url_tiltle

VARCHAR(200)

Yes

Message URL link title




msg_date

TIMSTAMP

No

Message posting time, date




msg_thread_id

INT4

Yes

Message ID number of original message
thread (only
if reply)




display_msg

BOOL

No

Flag to display message, equals true to
display message




msg_upload

BOOL

No

File upload flag, equals true if file is exists to
upload



21







bboard_upload_files

msg_id

INT4

No

Message ID upload is associated with




mime_type

VARCHAR(100)

Yes

MIME type (assigned to file by browser)




client_filename

VARCHAR(200)

No

Name of file from client




server_filename

VARCHAR(200)

No

Name of file on server




timestamp

VARCHAR(50)

No

Timestamp (YYMMDDHHMMSS)




descripti
on

VARCHAR(2000)

Yes

Description of file










22


Appendix 2. Program Files and
Descriptions

Filename

Description

bb_main.pm

Display main discussion board

bb_read.pl

Read a message from discussion board

bb_reply.pl

Reply to a message on discussion
board

bb_post.pl

Post a message on discussion board

bb_delete.pl

Delete a message on discussion board

links.pm

Display main links

add_link.pl

Add a link

delete_link.pl

Delete a link

search.pl

Search e
-
Group database

list.pl

Lists events for calendar

post.pl

Post event for calendar

meet.pl

Meeting Scheduler for calendar

PageEngine.pm

Module to dynamically create the front page

TicketAccess.pm

Handler to interrupt authentication phases

TicketMaster.pm

Module that contains functions use by TicketAc
cess

TicketTool.pm

Module that contains functions use by TicketMaster

Join.pm

Create new user to join a pre
-
existing group

CreateGroup.pm

Create a group




23

References


1.

The
Apache/Perl Integration Project, “Mod_perl Developer Guide”, December 1999,
http://perl.apache.org/guide/


2.

Marty Hall,
CORE Web Programming
. New Jersey: Prentice Hall, 1998, pp. 146
-
212


3.

Rudy Limeback, “Doomsday Algorithm,” 8/21/1999, http://www.interlog.com/~r937/doomsday.html


4.

D. A. Neamen,
Electric Circuit Analysis and Design
.

New York: McGraw
-
Hill, 1996, pp. 153
-
244


5.

D. Pitts and B. Ball,
Red Hat Linux Unleashed, Third Edition
. New York: Sams Publishing, 1998, pp. 125
-
561


6.

PostgreSQL Organization, “PostgreSQL Homepage,” December 1999, http://www.postgresql.org


7.

Stek Bekman, “m
od_perl: Performance. Benchmarks,” 11/13/1999,
http://perl.apache.org/guide/performance.html


8.

Symbolstone Homepage, “DBI
-
A Database Interface for Perl5,” 4/3/1999,
http://www.symbolstone.org/technology/perl/DBI/doc/tpj5/index.html