golftrack registration

Registration

Design Sub-system #1: Registration Sub-System (Pipe and Filter Architectural Approach)

The Pipe and Filter Architectural approach will be utilized to design the Registration sub-system. In this implementation of the Pipe and Filter architecture there will be four filters for input, data validation, registration, and output. Each filter processes the data and sends it to the next filter. Control is distributed, in other words, each filter can run whenever it has data on which to compute. Data sharing between filters is strictly limited to that transmitted on pipes (see figure 1.1 below) (1). As depicted in Figure 1.1 below, the registration process is initiated by the user (external stimulus) and the process actually begins when the user receives the Registration web page (HTML document) and enters his or her user registration information. A detailed description of this approach is listed in the Registration Sub-System (Pipe and Filter Architecture) Explanation section.

Figure 1.1 "Pipe and Filter Architecture for Registration Sub- System"

Registration Sub-System (Pipe and Filter Architecture) Explanation

Input Medium

The input medium for the Registration sub-system is the user agent (client application) that sends the request for the registration web page (HTML file) to the web server. Once the web server transfers the HTML document to the user agent (web client) the registration screen appears to the user with text boxes to collect user registration information such as the username, password, first name, last name, street address zip code, and club membership. After the user enters the requested information, the input medium (user agent) accepts the information as input for the system.

Data Input

After the input medium captures the user information such as username, address, and membership selection. The captured user information is then sent to the data input filter. The data input filter performs client side checks on the information to verify that the user name and address are in the correct formats. If the format is correct the input data is sent to the validate data filter. Otherwise, a flag of INVALID data is sent to the validate data filter.

Validate Data

The validate data process performs server-side validation of the user registration information to ensure the same user does not register multiple times. This is accomplished by checking the validity of the of the user name, address, and private membership type with the Golf Track users database registry (data storage details are described in the data storage section) to ensure that it is not a duplicate entry. If duplicate entries of the user name, address, and membership type, are detected an UNSUCCESSFUL flag is sent to the Register filter. However, if no duplicate entries exist in the Golf Track database registry the data for user name, address, and membership type is sent to the Register filter for further processing.

Register

The register process stores the user information in the database registry (via processes that interact with the Database Management System described in the Data Storage section) if the user name, address, and membership type data is received from the validate data filter successfully. After storing the user information, it then sends the confirmed user name (member identification) and password for the new user to the Output filter for further processing. On the other hand, if the Register filter receive the unsuccessful flag from the validate data filter it sends an EXISTING member flag to the output filter.

Output

The output filter formats the output at HTML documents to send to the Output Medium (User Agent). In other words, the HTML document is created based on the data received from the Register filter. If an EXISTING member flag is received, a HTML page that redirects the user to the Login screen for Current Members is created. If it is data for a new user the output filter creates a HTML document that contains the new user's member information (i.e. username and password) and hyperlinks to help information on how to use the Online Golf Handicapping System.

Output Medium

The output medium, which is the user agent, displays the formatted HTML output that it received from the output filter.

DESIGN RATIONALE

The requirements that are satisfied through design #1: Registration Sub-system are listed below:

Functional Requirements

Requirement #2 was accomplished by utilizing the Pipe and Filter architecture approach described above to implement the Registration sub-system.

Usability Requirements

Requirement #8 was satisfied by displaying help information as an HTML file with hyperlinks to the user agent so that new members can familiarize themselves with the system. Using a windows based registration screen, as shown in the Screen Shots and Site Map section, satisfied requirement #9.

Reliability Requirements

Although requirement #10 (the applications server is available 95% of the time) was not directly related to this section of the architecture. The requirement can be addressed by producing a message that displays a HTML document to the user agent during the 5% of down time. For instance, in the event the user is attempting to access the system during system maintenance the registration sub-system will display a HTML document to the user agent stating, "The System is unavailable please try your registration at later time".

There were several advantages for utilizing the Pipe and Filter architecture approach and they are as follows: the intuitive flow of processing the user registration from the initial input via the client application to the systems output to the user agent yielded a good fit for this architecture. Additionally, the ease of adding functionality if new filters are needed in the future is an advantage. The last advantage is the Pipe and Filter's strong support for reuse. The disadvantage of this architecture approach is the fact that the filter must copy all the data to its out ports, thus space is utilized inefficiently (1). As a result, this negatively impacts the speed of the network connection, which in turn may cause delays between processes.