May09-17-Design-Doc - Senior Design

nutritionistcornInternet και Εφαρμογές Web

14 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

79 εμφανίσεις

NCAA Student Athlete Compliance System

Group May 09
-

17










Client

Dustin Gray

Associate Director of Compliance

ISU Department of Athletics


Faculty Advisor

Dr. Doug Jacobson


Development Team

Andy Dorman

Jared Eakins

Ryan Kent

Ben Youngblut










2



Table of Contents

1.

Project Description

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

3

2.

Subsystem Description

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

4

2.1

Abstract Design

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

4



2.1.1

MDA

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

4


2.1.2

Model
-
View Controller
................................
................................
................................
..............

5

2.2

MVC Implementation

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

6

2.3

Controllers

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

6

2.4

Model

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

7

2.4.1

Data Structure

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

8

2.5

View

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

9

2.6

User Interface

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

9

3.

Use
Cases

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

9

3.1

Login/Create User

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

9

3.2

Create Form

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

11

3.3

Complete
Form

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

12

4.

Tools

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

13

4.1

EZPDO
................................
................................
................................
................................
..........

13

4.2

EXTJS

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

14







3



1.

P
roject Description

The client needs to keep detailed compliance data on all student
-
athletes in the athletic
department. The current solution involves packets of forms delivered to each student
-
athlete. This
method is very labor inten
sive, and wasteful of paper, as these forms stay at ISU and are not needed to
be in hard copy. Both the Big XII and NCAA require the member Universities to maintain the forms, and
only require their own copies in event of inquiry or audit.

The new product

will provide a green software solution for both student
-
athletes and athletic
officials. Students will be able to submit their information online, while officials can monitor and
approve the student’s progress. Officials will also be able to create

new
form for the

students

to

complete.

Users:



Administrators creating forms



Students completing forms


Currently, hard copies of each form are delivered to individual students by hand. The students fill
out the forms and return them to the Compliance departme
nt. Officials from compliance then have to
review each form from each student individually to ensure completeness.

If a form is incomplete, the
student is given a new form to complete. The completed forms are stored in hard copy for 7 years, and
are ava
ilable for Big XII or NCAA requests.


With the new product, Athletics officials will be able to create forms as necessary using an
institutive drag
-
and
-
drop interface. The forms can be then filled out and completed, which will save the
results to a databa
se. This product will then be integrated into our Senior Design project, which includes

user accounts, and a capacity to review forms for errors.


4



2.

Subsystem Description


2.1

Abstract Design

2.1.1

MDA

We will be following a model
-
driven architecture (MDA) appro
ach in this project. In MDA, the
system is designed and implemented from the model upwards. The model of a system can be described
by its class diagram. Typically in an MDA
-
based system, a universal modeling tool is used to manually
create the class dia
gram. Then, based on a standard definition of that model, a code generator is used
to create the set of classes to be used in the application, the scripts are generated to create the
database based on that model, and a common library acts as the link betw
een the two. Therefore, a
developer can simply program to the

data structures and not
worry

about the interface to the database.
Another approach to MDA is to manually create the database and run a schema extraction tool to
g
enerate the same class model.


We will be using the MDA approach because this system is, by nature, a data
-
based project; its
cornerstone relies on heavy user
-
database interaction. As such, designing the model of our system is
the first step of the design process. We use UML as our

standard modeling language, which we can use
to graphically depict the model of our system. From this diagram, we get an exported XMI file


a
Figure
1

System Architecture

A

B

C

5



standard XML definition for a UML model. Using this XMI file, we use XMI2PHP to generate the PHP
classes that
can be consumed by EZPDO
.


2.1.2

Model
-
View Controller

MVC is a common design pattern in software engineering, especially in web development. It
achieves the all
-
important task of breaking a software system into components; the presentation of a
system is compl
etely abstracted from the business logic and data access. The model typically describes
the state of the system. Any business logic takes place in the model also, so if any kind of manipulations
need to happen on the state of the system, this is where is

occurs. It has no concept of how the system
is presented, displayed, or interacted with. The view is where the presentation occurs. Based on a
known set of model data, it knows how to configure itself to be displayed to the user. Absolutely no
busines
s logic or data access occurs in the view. The controller acts as a link between the model and the
view. Typically in a user
-
interactive system, it is the controller that handles requests from the user. It
looks into
the view for the current state, pe
rforms any necessary business logic, and passes it on to the
view for processing. The following diagram explains the typical flow in an MVC system:

Since one of the main necessities of our system is scalability and maintainability, we will implement the
M
VC design pattern. Using this design pattern, a future developer will be easily be able to swap out the
current user interface for another without having to change any of the data access or business logic.
Likewise they could change the business logic wi
thout messing up any of the presentation. There are
many different rapid development frameworks in PHP that implement an MVC container, but for our
system, we will use a very simple approach (described in system component breakdown).



Figure 2 Model
-
View
-
Controller Flow

6



2.2

MVC

Implementation

A good MVC system has a single point of entry into the backend of the system. There are
frameworks that help facilitate this such that individual controller methods are mapped to a unique URL;
this way, they are accessible from the client without having t
o kno
w the workings of the system.

We take a very simple approach to this, not by having a complex framework to handle this routing,
but instead hand
-
construct a control
-
routing mechanism, through which all requests to the server are
routed. This is acc
omplished by pulling the controller name and the desired method name out of the
URL's query string.

In this specific implement
ation, ‘control.php’ is our main routing script.

For instance
a request to 'control.php?route=FormController/saveNewForm' would
call the saveNewForm method in
the FormController class.

The control router passes an associative hash array by reference into the controller. This “model
map” acts as a means of communication between the controller and the view. The controller populates

this model map with arti
facts retrieved from the model after

performing any business logic necessary
through its res
pective business manager class. This population is

keyed by strings that the view expects
to see in this model map. The controller then c
reates and returns the correct view to execute over the
model map.

Every view extends an abstract class View_Base that defines an abstract method execute that. Since
the controller returns the view to be executed back to the control router, execute is inv
oked with the
model map populated by the controller as the parameter. The view then performs any logic needed to
present the response back to the client. It is important to note that no business logic takes place in the
view, as this would cause unnecess
ary coupling between components and the system would lose its
modularity. The view finishes by printing a JSON
-
encoded string representing the objects to be used by
the invoking Javascript function.

2.3

Controllers

Typically in an MVC system, controllers are
grouped per their respective model element.

This is
visible in Figure 1 at letter B.

For instance, a request to create a new Form in the database would be
routed into the FormController. The methods contained within each controller are the only places i
n
the system that accesses the system database. This achieves a significant separation of components in
the design. Data access queries through EZPDO return model elements, and the controller manipulates
them accordingly through their business managers.

Naming conventions for controllers are important in
order for the control router to work properly.

Otherwise, the router would not be able to construct the
proper URL for the controller.

The controller for the Form actions would be in a file named
formC
ontroller.php and the class name would be Controller_FormController.



7



2.4

Model

The model of the system is presented as a class diagram below
, and is shown in the system in Figure 1 at
letter C.


Figure 3 Model Design

8



2.4.1

Data Structure




Admin
-

Compliance office employees with adm
inistrative access to system.



User
-

A student
-
athlete. Stores some basic information and eligibility status. Belongs to one or
more teams. Contains form responses for the forms that are required.



Team
-

An athletic team. Contains users who belong to t
he team.



FormGroup
-

Contains forms, organizing them into a single "packet", usually one for each
academic year.



Form
-

A form to be filled out. Belongs to a single form group. Contains form elements. Stores
information about who is required to fill out

the form (freshman, transfers, etc.).



FormElement
-

A question, text block, or other form element of a specific type. Belongs to a
single form. May contain form element options.



FormElementOption
-

A possible response to a question (i.e.: yes/no, pick o
ne, etc.). Belongs to
a single form element. The element type determines whether or not there are options (i.e.: a
textarea does not have options).



FormElementDependency
-

Allows dependency between form elements. Has a parent element,
child element, an
d a value. If the user's response to the parent element matches the value, the
child element becomes required.



FormResponse
-

An individual user's instance of a single form. Ties users to forms they must
complete. Contains form element responses. Belon
gs to a single user and a single form. Stores
the time a user responded to the form. Has a status (approved, rejected, etc.) set by an admin
based on the review of the user's responses to the form. A user can have many form responses
(one for each form
they fill out) and a form can have many form responses (one for each user
that fills it out).



FormElementResponse
-

An individual user's response to a single form element in a form.
Belongs to the form response of the form that the element belongs to. St
ores the value of the
user's response. A form response can have many form element responses (one for each element
in the form) and a form element can have many form element responses (one for each user that
fills it out).



FormResponseStatus
-

The status o
f a user's form response.


This data structure models everything the system needs to create, modify, and fill out/save forms,
as well as tracking necessary information such as completion dates and approval statuses. This
collective data structure is also
a representation of our persistence layer; there is a one
-
to
-
one mapping
between each class and a table in the database. EZPDO will act as the interface between the two. With
this library, a developer can program directly to the object
-
oriented data stru
ctures and do a single
commit to the database; all the hassles of interfacing and dealing with relations are handled internally
by EZPDO.

The model represents a state of the system, but it has no knowledge of business logic rules. This is
the purpose of t
he business managers. There is one business manager for each class in the data model,
so the business manager for the Form class would be named FormManager, and so on. It is in these
classes that any manipulation of a class model based on business requir
ements.

9



2.5

View

In general there is a single view class for every controller method. In our system, the only
communication from the server back to the client is purely JSON (Javascript Object Notation) encoded
strings. With our design choice of using ExtJS,

JSON data is easily consumed by the Javascript code. The
entire communication with the server will be handled asynchronously without having to refresh the
browser.

This view class is shown in Figure 1 at letter A.

2.6

User Interface

The user interface for
our application is aimed at being extremely simple to use. Our main goal is to
create a user environment that enables the user to efficiently achieve their tasks. To do this we first plan
to make as many
functions institutive to the user; in

doing this the
re is less of a learning curve and the
user is able to be productive quickly since they have used other applications with similar features. The
next step is to not create unnecessary windows and screens. This enables the user to quickly and
efficiently

nav
igate and move around the site.

Form creation is one of the main components of our application and intern has its own specific user
interface. This interface enables the user to drag a form element from one panel and drop it in another
panel. Once the form

element has been placed into the panel it can be dragged up and down within the
panel overtop of other elements to change the ordering.

3.

Use Cases

3.1

Login/Create User

To login, the user is redirected from the Program to the ISU Single Sign On. If their log
in is
successful, their client is returned a cookie with their personal information. That cookie is then checked
against the Program’s user accounts in the database to see if the account is valid.

To add a student user account, the Administrative user ent
ers the student’s ISU ID number into a
form. That number is then checked against the ISU student information database. If the number is
valid, the student’s personal information is acquired and a user account is created in the Program’s
database.





10


























Figure
2

Login/Create User Use Case

11



3.2

Create Form

To create a form, the Administrator requests the Form Creation webpage. This page is entirely
generated client
-
side, and does not interact with any server
-
side scripts. As the user modifies the form,
all interaction is a
lso client
-
side.


Once the user clicks on ‘Save’, the form is encoded in a JSON string, and sent to the PHP Router.
The Form object is then sent to the Controller, where the individual Form Elements are created and
saved to the database. Once the form
is committed, a confirm message is percolated back to the PHP
Router, and then sent to the View to be JSON encoded and returned to the client.

Figur
e 4 Create Form Use Case

12



3.3

Complete Form

To complete a form, the student user selects the form to view. That request is forwarded to the
PH
P Router, where the specific Form Object is requested, and then to the Controller and Model,
where the individual Form Elements are requested. The Form Elements are retrieved from the
database, and packaged in a Form object, and later encoded in JSON for
display.

Once the user clicks the ‘Save’ button, the responses to the form are JSON encoded, and passed
through the PHP Control to the Controller, and to the Model, where the responses are turned into
Form Response objects where they are associated with th
e appropriate form, and saved to the
database. Once the database is updated, a confirm message is sent forward to the client.




Figure 5 Complete Form Use Case

13



4.

Tools

4.1

EZPDO

EZPDO (Easy PHP Data Objects) is an object
-
relation mapping (ORM) library that allows the user to
program direc
tly to their object
-
oriented data structure and let the data persistence problem be taken
care of by the library. A developer could write an entire application with no knowledge of SQL. Given a
simple XML configuration file to define such things as locat
ion of the model classes, location of the
database, etc., EZPDO will create the database necessary to represent the PHP class model. A developer
can then use the library and the system's object
-
oriented data structure to create a meaningful, data
-
dependen
t application.

We looked at several tools to accomplish a similar task. The necessities of such tools included the
ability write object
-
oriented code that can be
(a)
saved to a database transactionally,
(b)
be easy to use
and get started with, and

(c)

sup
port future changes. The following is a list of the other tools we tried
out and the reasons we didn't choose them.



DaoGen
--

a dao based approach. We liked the architecture it generated, but its major pitfall is
that it requires manually entering the sche
ma of your database. This is not good for future
changes in your schema.



ObjectGenerator
--

A good approach to generating a dao architecture straight from your
database. However, the code generated was not quality code and would require a lot of
maintaining
.



NeuralBuild
--

a good product for the most part. It requires you to write templates that it will fill
in based on your database schema (auto
-
generated).
Its

pitfalls
include lack of

support for
foreign keys, or multiple column primary keys.



PHP Class Gene
rator
--

an eclipse plug
-
in that generates your data access objects based your
database schema. It had support for foreign keys, and, being a template
-
driven generator, we
could set up exactly what we want with this layer.
Its main drawback is that code gen
eration
happened one table at a time.



PHPObjectGenerator (POG)
--

a similar approach as DaoGen: input your table's attributes and it
outputs your code. However, this was open source, so it could be adapted (with quite a bit of
effort) to look directly into
your database.




Acceleo


an Eclipse plugin that took a UML model and generated an entire application
framework. It had object
-
oriented data models and dao architecture, along with an entire MVC
container. This was a little overkill for our purposes, but

it seemed to create a very nice
14



framework. Its main pitfall was the fact that it was not considered a production
-
level
application, but instead in an “incubated” state: not good enough for a professional application.


EZPDO was the last one that we tested out. The reason that we chose to use it as our data access
layer is because of its ease of use. Our system must be maintainable for future developers, and with this
library, codin
g is very easy. It has full support for an object
-
oriented data structure with transactional
commits. What this means is that a single object can be created, a collection of other objects added to
it, and all committed in a single action. All relations
are handled by the EZPDO library and maintains
them in the database; it even creates the database for the developer. This design fits perfectly into our
MDA approach, as well as our MVC container.

4.2

EXTJS

For the user's interaction with our web application
a JavaScript user interface was chosen to allow
for rich user experience. JavaScript allows for simple interactive user navigation as well as dynamic page
content loaded from the server, without refreshing the page. A JavaScript framework was chosen to bui
ld
upon that would simplify the JavaScript coding. The JavaScript framework chosen for this application was
Ext JS.

Ext JS was chosen for the following reasons.



Cross browser compatible.



Open Source License.



Intuitive API.

Ext JS will provide framework for

the
following components that will b
e used for designing our user
interface.



HTML Editor, for user input.



Data Grids, for displaying data.



In browser windows, with modal support



Layout Managers, for organizing the page layout.



Drag and Drop, for form crea
tion.

Other JavaScript frameworks like Yahoo User Interface (YUI), DOJO, and Moo Tools were considered. But
Ext JS was chosen as the best solution over these other existing

JavaScript libraries due to it
s
completeness.

YUI was too heavy
-
weight for our nee
ds, and DOJO and Moo Tools did not include the
simplified drag
-
and
-
drop windows that we felt were important for our interface.