The document summarizes an alert tracking system created by the Blue Team for a software engineering class. The system allows users to be organized into groups with permissions, post alerts that are viewable based on permissions and groups, and includes messaging capabilities. It is entirely web-based using PHP scripts to interact with an Oracle database. The database stores user, alert, message, and archive information across several tables, including dynamic tables for each group. A link is provided to demo the system.

1. Blue Team
Aaron Kunz (Facilitator)
Karim Tawil (GUI)
Joe Reist (Server)
Final Presentation of
Alert Tracking System
CEN 3031
Software Engineering, Summer 2005

2. Features
• Complete suite of administrative tools
• Users can be organized into an infinite
number of arbitrarily named groups
• Flexible permissions hierarchy
• Permanent archive of all past alerts
• User-to-user and user-to-group messaging
capability
• Fast response; users are notified of new
alerts within 3 seconds.

3. Requirements Analysis
http://www.cise.ufl.edu/~akunz/evan/reqsto.html

4. Design Solution (see next slide)
• The system is be entirely web based
• The system consists of a collection of PHP
scripts interacting with an Oracle database.
• The PHP scripts interact with each other by
passing POST variables and modifying
SESSION variables, as shown on the next slide.
• The diagram on the next slide is designed to
provide some insight into the structure of the
system, but does not include all of the system
functions (there are more than 20).

5. Login/Account
Request
Authenticate
Main Interface window
Refresh
(Alert/message
display)
Controls
Log Out Delete Alert Add Alert
Page visible to
user
Intermediate
PHP function
(not visible)
Intermediate
PHP function
(not visible)
Legend
Global Variables (SESSION variables available to all scripts):
‘user’ : username of current user
‘level’ : user’s permission level
‘opcode’ : variable used to track login status. A ‘0’ means that the user
has successfully logged in, and other numbers will be used
to represent error codes and other messages
‘ora_err’ : keeps track of the most recent database error message
1
1
POST Variables
‘uname’ : username entered into login field
‘pw’ : password entered into login field
2
2
Change SESSION variable ‘opcode’ to
reflect login error
3
3 Update SESSION variables:
‘user’
‘level’
‘opcode’
4
4 POST variable ‘deleteID’ (ID number of
alert to be deleted
5
5 POST variables
‘permissionlevel’ : Permission level for new alert
‘text’ : New alert text
‘special’ : special notifier to indicate
group alert, etc.
6
6 Update SESSION variables
‘addstate’ : variable used to track alert addition
status. Similar to ‘opcode’
‘ora_err’ : Oracle error message (if any)
Data passed
between scripts
All database interaction
occurs inside functional
blocks
7
Send
message to a
user/group
7
POST variables
‘toUser’ : user/group to receive message
‘message’ : message text
Delete
Message(s)
8
8 POST variables
Indentifying characteristics of message(s) to delete
Manage group
affiliations and
settings
Accept Alert
9
9
POST variables
‘acceptID’ : ID number of alert being
accepted by the current user

6. Details
• Users are allowed to post ‘alerts’ to the system which will then be
viewable to other users depending on their group affiliation and/or
permission level:
• A user’s ‘permission level’ is a number between 0-999. Each alert
has a similar permission level, which is chosen by the user who
posts the alert.
• A user who is a member of a group may also designate the alert as
‘group only’.
• The newly posted alert will then be immediately visible to any user
whose permission level is equal to or higher than the alert’s
permission level (and who is also a member of the specified group if
the ‘group only’ option is chosen).
• Users have the option of ‘accepting’ alerts, at which time the alert is
moved from the active alert list into the alert archive, where it will
remain until removed by the administrator .

7. Database Structure
Table name
Users
Alerts
Messages
Alert_archive
Function
Contains each user’s username, password, permission
level and group membership information.
Contains all current alerts. Stores alert text, date
posted, permission level, group designation, and a
unique identification number for each alert.
Contains all messages (this includes both user-to-user
messages and user-to-group messages).
Similar to the ‘Alerts’ table, this table stores all
accepted/de-activated alerts. In addition to the
information from the ‘Alerts’ table, this table also
includes the name of the user who accepted the alert
and the date that the alert was accepted.

8. Database Structure (continued)
Table name
Groups
Group_*
Function
A list of names of all existing groups.
A separate table exists for each group which lists the
members of that group. The name of the table is
“Group_”, followed by the group name. This allows for
an infinite number or arbitrarily named groups since
the system can find the group name in the ‘Groups’ list
and simply concatenate ‘Group_’ and this name and
perform whatever actions are necessary.

9. Try it!
http://www.cise.ufl.edu/~akunz/system4/login.php
Main group website
http://www.cise.ufl.edu/~akunz/evan/
Test accounts for your convenience
Username Password Permission level Group
test test 50 one
test2 test 50 one
reist reist 33 blue
karimos 123 999 blue
admin x 999
*a blank value in the ‘group’ column indicates that the user does not belong to a group
** you must log in as ‘admin’ to access the administrative tools