NCAA Student Athlete Compliance System

Transcription

1 NCAA Student Athlete Compliance System Group May 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 Subsystem Description Abstract Design MDA Model-View Controller MVC Implementation Controllers Model Data Structure View User Interface Use Cases Login/Create User Create Form Complete Form Tools EZPDO EXTJS

3 1. Project 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 intensive, 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 department. 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 available 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 database. This product will then be integrated into our Senior Design project, which includes user accounts, and a capacity to review forms for errors. 3

4 2. Subsystem Description B A C Figure 1 System Architecture 2.1 Abstract Design MDA We will be following a model-driven architecture (MDA) approach 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 diagram. 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 between 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 generate 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 4

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 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 completely 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 Figure 2 Model-View-Controller Flow business 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, performs 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 MVC 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 without 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). 5

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 to know 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 accomplished by pulling the controller name and the desired method name out of the URL's query string. In this specific implementation, 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 artifacts retrieved from the model after performing any business logic necessary through its respective business manager class. This population is keyed by strings that the view expects to see in this model map. The controller then creates 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 invoked 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 unnecessary 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 in 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 formcontroller.php and the class name would be Controller_FormController. 6

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 7

8 2.4.1 Data Structure Admin - Compliance office employees with administrative 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 the 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 one, 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, and 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. Belongs 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. Stores 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 of 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 structures 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 the 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 requirements. 8

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 there 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 navigate 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 login 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 enters 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. 9

10 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 also 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. Figure 4 Create Form Use Case 11

12 3.3 Complete Form To complete a form, the student user selects the form to view. That request is forwarded to the PHP 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 the 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 12

13 4. Tools 4.1 EZPDO EZPDO (Easy PHP Data Objects) is an object-relation mapping (ORM) library that allows the user to program directly 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 location 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, datadependent 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) support 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 schema 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 Generator-- 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 generation 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 13

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, coding 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 build 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 be 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 creation. 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 its completeness. YUI was too heavy-weight for our needs, and DOJO and Moo Tools did not include the simplified drag-and-drop windows that we felt were important for our interface. 14