golftrack login

Design Sub-system #:2 Login Sub-System (Pipe and Filter Architectural Approach)

Similar to the Registration sub-system, the Pipe and Filter Architectural approach will be utilized to design the Login sub-system. In this implementation of the Pipe and Filter architecture there are three filters for input, login, and output. Each filter processes the data and sends it to the next filter. Control is distributed: each filter can run whenever it has data on which to compute. Data sharing between filters is strictly limited to that transmitted on pipes refer to figure 2.1 below (1). As shown in Figure 2.1, the Login process is initiated by the user (external stimulus). The Login process begins when the user receives the Sign-on web page (HTML document) and enters his or her Login user name (member identification) and password into the input medium. A detailed description of this approach is listed in the Login Sub-System (Pipe and Filter Architecture) Explanation section below.

Figure 2.1 "Pipe and Filter Architecture for Login Sub-System"

Registration Sub-System (Pipe and Filter Architecture) Explanation

Input Medium

The input medium for the Login sub-system is the user agent (client application) that sends the login request web page (HTML file) to the web server. Once the web server responds to the user agent's request a HTML document with the login fields for username and password appears (a sample login screen is shown in the Screen shots & sitemap section). After the user enters the user name and password, the input medium (user agent) accepts the information as input for the system.

Input

Once the input medium captures the username and password this data is sent to the input filter. The input filter performs client side verification of the data using a scripting language to verify that the data received is in the correct format (i.e. Password should be at least 8 characters or username is a seven digit number) If the format is correct the input data is sent to the Login filter. Otherwise, a flag of INVALID data format is sent to the Login filter.

Login

The Login filter processes the data sent by the input filter. If the data is in the proper format the Login process searches the Golf Track database registry database via the Database Management Systems query language. It compares the username (member identification number) and password combination with the stored user login information. Once a match is found, the Login process sends a valid user flag to the Output filter along with the user access information. This includes user roles/ access restrictions or database privileges. The roles sent to the Output process govern what the user sees/edits from the output medium (user agent). If an INVALID data format flag is sent to the Login filters, the Login filter in turns sends an INVALID_USER login flag to the output medium.

Output

The output filter formats the output of HTML documents to send to the Output Medium (User Agent). In other words, the HTML document is created that states that the user does not exist and this document is sent to the output medium. The user does not exist HTML document will also contain hyperlinks to re- direct the user to the Registration screen for NEW Members. On the other hand, if the output filter receives a valid user flag and the user information. A HTML document that links to the Online Golf Handicapping system components that the user has access to read/change is sent to the output medium.

Output Medium

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

DESIGN RATIONALE

The requirements that are satisfied through design #2, the Login Sub-system, are listed below:

Functional Requirements

First Requirement #2 was accomplished by utilizing the Pipe and Filter architecture approach described above to design the Login Sub-system. Requirement #7 was satisfied by using the user's login information coupled with the Database Management Systems security features (i.e. user roles) to give the user permission to view other member's public data after login.

Usability Requirements

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

Reliability Requirements

As stated in the Registration section , requirement #10 (the applications server is available 95% of the time) was not directly related to this section of the architecture. However, 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 login/sign on to the system during system maintenance the login sub-system will display a HTML document to the user agent stating, "The System is unavailable please Sign on at later time".

Performance Requirements

For both Requirements 12 and Requirement 13, the login process should adhere to the performance time constraints and should not hinder the user experience. The login design is not expected to satisfy these requirements only to address them as a performance standard.

Identical to the Registration Sub-system section, utilizing the Pipe and Filter architecture approach had several advantages. They are as follows: the intuitive flow of processing the user login information from the initial input via the client application to the systems output to the user agent yielded a good fit for this architectural approach. Additionally, the ease of adding functionality if new filters are needed in the future is an advantage as well as the pipe and filter's strong support of reuse. On the other, the disadvantage of this architecture approach for the login section is the fact that the filter must copy all the data to its out ports, which causes the space to be utilized inefficiently (1). Consequently, the speed of the network connection could negatively impact the communication between the client (user agent) and server.