Bronx Project Design Document

mexicanmorningData Management

Dec 16, 2012 (4 years and 7 months ago)

121 views







Bronx Project Design Document



















Cap Consulting

June, 23 2008










Contents

Bronx Project Design Document

................................
................................
................................
...............

1

1

Purpose

................................
................................
................................
................................
.............

3

2

Existing Application

................................
................................
................................
.........................

3

3

New Application

................................
................................
................................
...............................

3

4

Databa
se Design

................................
................................
................................
...............................

4

4.1

User Table:

................................
................................
................................
...............................

5

4.2

Role Table:

................................
................................
................................
...............................

5

4.3

UserRoles Ta
ble:

................................
................................
................................
......................

5

5

Screen Design

................................
................................
................................
................................
...

6

5.1

Basic Screen Layout

................................
................................
................................
....................

6

5.2

Login Pag
e

................................
................................
................................
................................
...

7

5.3

Main Page

................................
................................
................................
................................
....

8

5.4

Search Page

................................
................................
................................
................................
.

9

5.5

Results Page

................................
................................
................................
..............................

10

5.6

Maintenance Page
................................
................................
................................
......................

11

6

Screen Flow

................................
................................
................................
................................
....

12

7

Testing

................................
................................
................................
................................
............

12



1

Purpose

The purpose of the document is to outline the necessary steps to fully convert the existing Bronx
project from a MS Access database that is only available on the local network, to a full web based
application.

2

Existing Applicatio
n

The existing system is a MS Access database with VB Forms. In order for the user to make use of the
application, the user must perform the following operations:


1.

Be connected to the target Windows server where the database lives (this may or may not
req
uire user authentication)

2.

Navigate to the location of the database (or, more likely user a shortcut)

3.

Open the database and start working from the main form


In all cases, the existing application will be used to ensure the proper functionality (unless othe
rwise
stated).

3

New Application

The new application will be a web based application using the following layers and technologies:


1.

Database Tier

1.

This tier will consist of a PostgreSQL 8.x database (current Open Source full transactional
SQL92 compliant datab
ase). If the provider does not allow for Postgres, MySQL 5.x will
be used. (NOTE: Due to the nature of the technology mix, SQL Server would also be a
possibility, however licensing costs need to be taken into account).

2.

The database will allow for either
a Linux or Windows based platform.

2.

Web Tier

1.

Java 6

2.

Glassfish v2 (current Open Source standard for a full J2EE 3, Servlet 2.x application server)
or other equivalent (i.e. Tomcat 5.5, Tomcat 6.0)

3.

Spring 2.5 (current Open Source standard for web framework)

4.

J
PA 1.x (object relationship mapper to convert objects to records in a database table and
back again)

5.

XHTML transitional (IE 6, 7, 8, FireFox 1, 2, 3, Safari compliant)

6.

CSS3

7.

This tier will allow for either a Linux or Windows based platform.

3.

The Client's bro
wser

1.

The following browsers will be supported:

1.

IE 6, 7, 8

2.

Firefox 2.x


3.x

3.

Safari

2.

The client's browser must allow JavaScript to execute to ensure the proper functioning of
any client side code. This code can be used to provide menus, calendars, spinners,

and
additional controls.

3.

This tier will allow for either a Linux or Windows based platform.


For a list of compatible hosting solutions, please see the Web Hosting Solutions document. If the
application is to be hosted by the client, then direct access t
o the target machine will be necessary to
ensure proper configuration of the production environment. If additional environments are requested
(i.e. testing environment), then access to that platform (i.e. machine) will also be necessary for setup
purposes
.


Regardless of where the application is hosted, additional documentation will be provided to detail the
steps on how to maintain the application and server (i.e. how to shutdown the server, make changes,
and restart the server, basic trouble shooting inf
ormation). This documentation will be provided
towards the end of the project after the application has been deployed. This is to ensure that the exact
environment is represented in the documentation.

4

Database Design

The current database (C DB, and CT DB

which references C DB) will be directly ported from MS
Access to the target database. Since the current database does not use referential integrity, foreign
keys, cascading operations, the porting process will be rather simple. The existing MS Access da
tabase
includes several views (i.e. stored queries), these will also be directly ported to the new database as is.


As part of the database porting process, any empty tables will be assumed to no longer be necessary.
These tables will not be replicated in

the new database unless directly referenced by either a non
-
enforced foreign key or by a view.


Once the schema for the database has been ported, an additional task will be required to load the data
into the new database from the existing. In order to
ensure that all of the up to date information is
loaded into the new database, this load process will be performed last (i.e. before the system goes live).
A simple script based application will be used to pull the data from the source database into a tex
t
based file. This file will then be directly loaded into the new database. Even though the full data will
not be ported until the end of the project, a representative sample of data from the current database will
be used for development purposes.


For a

complete list of tables to be ported, please see the C DB and CT DB documents.


An addition to the existing database will be the necessary tables for user authentication, administration,
and security access restrictions. A basic login page will be necess
ary in order for the user to provide a
username and password. This provided information will be used to verify the USER database table. If
the user exists and the encrypted passwords match, then the user will be authenticated. An additional
step of retr
ieving the access roles that the user is assigned will then be performed. The access roles will
be used to determine if a user has the ability to view, or update information. Also, a higher role will be
used to allow a person to administer other users in

the system.


The user tables schema is as follows:


4.1

User Table:

Column

Data Type

Notes

UserId

Numeric

Unique per person, required

UserName

Varchar(40)

The shortened form of the user's first and last
names, required

FirstName

Varchar(40)

Not require
d

LastName

Varchar(40)

Not required

Email

Varchar(80)

Not required (possible future use)


4.2

Role Table:

Column

Data Type

Notes

RoleId

Numeric

Unique per role, required

RoleName

Varchar(40)

Unique, required

Description

Varchar(100)

Not required


4.
3

UserRoles Table:

Column

Data Type

Notes

UserId

Numeric

Required

RoleId

Numeric

Required


Additional code will be required at the screen level to ensure that values are only modifiable based on
user role information.





5

Screen Design

The following sec
tion outlines mockups for all of the various pages. These mockups include
navigation options and usage information.

5.1

Basic Screen Layout

The basic screen layout would be as follows:























Logo Pic


A standard picture that represents SEF
B



Page Title


A title for the page



User Name, Student Name


Basic information about the user, the student, etc. This
information would change based on the functional area that the user is in (i.e. Activity
maintenance would have different information th
an Student's Activities maintenance)



Pull down menu


The basic form of navigation through the system. This allows the user to
select the maintenance item that they need to work in. This also becomes the main means to
limit a users access to a maintenanc
e item.



Logo Pic

User Name: User

Student Name: Student


Page Title

pull down menu

Working Area

5.2

Login Page

The following mockup is for the Login page. This page is used to verify that a user has access to the
system (i.e. functions as you would expect a Login page to function).
































Logo Pic

Login

Login

User Nam
e:

Password:

Logo Pic

Login

Login

User Name:

Password:

5.3

Main Page

The main pa
ge is the the landing page of the application. That means, when the user logs into the
application, this page will be displayed. It is essentially a standard mockup page with a blank Working
Area (see basic screen mockup).
































Logo Pic

Student

Activities

Virtues

User Name: User

South Bronx Education Foundation

5.4

Search Page

A basic part of the application (both new and old) is to limit the available data to a manageable set. In
the old application, this was accomplished by the filter available on each screen. In the new
application, this is available by a s
earch page. The search page is specific for each maintenance item.
So, the search page for Students is slightly different than the search page for Virtues.































Logo Pic

Student

Activities

Virtues

User Name: User

Student Maintenance

Student Search

First Nam
e:

Last Name:

Search

5.5

Results Page

After a search has been performed, the results t
hat match are displayed on a standard results page. The
fields available on the search page are specific per maintenance item. From the results page, a specific
record can be selected.
































Logo Pic

Student

Activities

Virtues

User Name: User

Student Maintenance

Student Search Results

First Name

Last Name

School

Xxxxxx

Xxxxxx

Xxxxxx

Xxxxxx

Xxxxxx

Xxxxxx

Select

Add

Delete

5.6

Maintenance Page

After the user e
ither picks a a Student or decides to create a new one, a maintenance page would be
displayed. This page would allow a user to enter or modify data as necessary. The user has the option
to either save the changes, or to cancel the changes. If the user c
ancels the changes and they were
editing an already existing student, then the original student information would be displayed.












s



















Logo Pic

Student

Activities

Virtues


User Name: User

Student Name: Student


School Name: School

Student Maintenance

Student

Save

Cancel

First Name:

Last Name:


Phone
:

Email Address:

6

Screen Flow

The basic flow of the application is outlined in the figure below. As in the curren
t version of the
application, the main page is the starting point for all operations. One change from the current
application is the necessity to login to the application to ensure that only authorized users can have
access. The remainder of the screen f
low will be the same as the current application.


The normal flow for the screens would be as follows:

1.

Login

2.

Directly forwarded to the main page

1.

Using the menu, find the student (or other maintenance item)

1.

Directly forwarded to the search page for the main
tenance item

2.

Do a search, or create a new item, or edit an existing

3.

Save changes

2.

Use menu to change to some other maintenance item

7

Testing


Testing will be covered in three different phases.



Unit Testing



This phase is used to test small pieces of code. Th
is testing code can be used to detect
problems that are very localized. This kind of testing is code based and only performed by
the developer. The goal of this phase is to eliminate obvious coding problems.



Integration Testing



This phase of testing is u
sed to test an entire page to ensure that it functions properly. This
level of testing is commonly performed by the developer first, then verified by an actual
user of the application.



System Testing



This phase of testing is used to verify that flow of th
e application is correct, major features
of the application work as defined, and no referenced feature is missing. This phase of
testing is performed by the client and used to ensure that the client is getting what they
expected.


Based on the complexity
of the application, only a few test cases will be fully documented. This
documentation will be performed on an as needed basis.