Head Office Interface and Data Module Specifications

Authors


Head Office System Specifications:

The head office system will enable remote safety checks, control of the station, and report viewing. Each user of the system will have a password and an associated level of access, and will be required to log in before using the system, so that the information contained in the system is not abused. Each process, when initiated, will start a counter which will automatically log the user out after a long period of inactivity.

Excellent, but could you please be a bit more specific (ie. amount of time before the user will be logged out, and is the time adjustable?)


The following Data Flow Diagrams illustrate the hierarchy of menus and processes, as well as the travel of data between individual processes and the database:

It looks like you have a clear understanding of how you're going to implement this system, but some of us have trouble understanding these DFDs.
For example, in the first one, where do all the data items being sent into the Process Fill Tank entity come from?


1 Login Session

The login will ensure that only authorized users have access to the system. The user will be prompted for their user ID, and their password, on a screen similar to the one below. Based on this information, the system will grant or deny access to one of three subsystems:

  1. the Station Control and Reporting subsystem,
  2. the Fuel Delivery subsystem, or
  3. the Administrative subsystem.

[login screen]

Process Description:

The login session is used to verify if the user has the authorization to access the system. The screen will show the Petro 451 Logo, as well as fields for the input of the ID and the password. Once these are input, the ID and the password are sent to the database for verification. If found not to match and no database entry is found, an error message is displayed breifly and the login screen is redisplayed.

If the ID and the password match the information in the database, the level of access for the user will be retreived and, depending on this, the appropriate menu will be activated. Each type of user will be resticted only to the activities authorized by their access level.

What if we want one person to be able to access two of the functions?



STATION CONTROL AND REPORTING

3 Main Menu Selection

The main menu screen will be similar to the following:

[main menu screen]

Process: Display the Main Menu screen

3.3 Station Operation submenu

The system operations submenu screen will be similar to the following:

[station operations menu screen]

Process: Display the Station Operation Submenu screen

3.4 Reports Submenu

The reports submenu screen will be similar to the following:

[reports menu screen]

Process: Display the Reports Submenu screen

3.1 Change Fuel Price

    1. Syntactically incorrect input(s) from user
    2. Fuel Price is out of range.

    Are we going to be able to set the range, or is this just going to be programmed in?


Process:

  1. Read the Fuel Price per Litre and Fuel Type from the database Fuel
  2. Display the list of Fuel Price per Litre and Fuel Type
  3. Get the new Fuel Price per Litre (from user).
  4. Get the Fuel Type (from user).
  5. if the Fuel Price is out of range OR syntactically incorrect

Could you please switch #4 and #3 around?


3.2 Change Maximum Amount Allow for a Single Purchase

  • Input: Maximum Purchase (from configuration database), Maximum Purchase (from user)
  • Output: Maximum Purchase (to configuration database)
  • Error Condition: Syntactically incorrect input (from user)

Process:

  1. Read the Maximum Purchase from the configuration database
  2. Display the Maximum Purchase
  3. Get the Maximum Purchase (from user)
  4. If the value entered is syntactically incorrect
    • restore old value
    • display error message
    • else
      • display message asking for confirmation.
      • Write Maximum Purchase to configuration database.
    • endif

3.5 Main Menu Help

  • Input: None
  • Output: None
  • Error Condition: None

Process: Display short descrition for each choice of main menu

3.6 Logout

  • Input: None
  • Output: None
  • Error Condition: None

Process: Close all databases and logout.


Anywhere that we are prompted for a date we would like the option to select either a current reporting period (ie.select through buttons) or a specific reporting period (ie. type in a reporting period). The way we understand it now, we will always have to type in a specific reporting period, which could be quite inconvenient.

3.4 Process Reports

Inputs:

Menu selection by clicking the mouse pointer on the desired choice.

Outputs:

A menu is displayed to choose from the following choices:

1) Transaction Report and Backups

2) Statistics Report

3) Monthy Summaries

4) Delivery Report

5) Card Status Report

6) Change Reporting Periods

7) Help

8) Main Menu

Error Conditions:

a) none

3.4.1 Display Transaction Report

Inputs:

Start Date or Report ID. The user has the option to print out the report.

Outputs:

It will display the corresponding report with Report ID, Start Date, Start Time, Stop Date, Stop Time, GST, PST and the Transactions themselves.

Error Conditions:

a) Syntactically incorrect inputs in which the system will notify the user and repromt for input.

b) Start Date or Report ID is out of range or not found in database.

3.4.2 Display Statistics Report

Inputs:

To print it or not

Outputs:

It will display in a table format the current station's statistics. Which includes the Pump Number, Pump Status, Fuel Types, Fuel Price and amount sold for each pump

Could you please include the date as well?

Error Conditions: none

3.4.3 Display Monthly Summaries

Inputs:

Enter the month to be displayed. The user has the option to print out the report

Outputs:

The will display the transactions for the month, totals, GST and PSTs. Also the summary of the statistics for the month.

Error Conditions:

a) Syntactically incorrect input.

b) Month entered is out of range or not in database.

3.4.4 Display Delivery Report

Inputs:

Enter a range of date to display or a specific delivery id. Also the option to print report.

Outputs:

An instance or instances of Delivery is displayed. Which includes Delivery ID, Delivery Date, Delivery Time, Delivery User Last Name, Delivery User First Name, Delivery User ID, Gas Type Delivered, Delivery Tank ID, Delivery Tank Level Before, Delivery Tank Level Added, Delivery Tank Level After and Delivery Total Value

Error Conditions:

a) Syntactically incorrect input.

b) Delivery ID is not in database or date is out of range.

3.4.5 Display Card Status Report

Inputs:

The range of dates credit cards were rejected. Also the option to print the report.

Outputs:

The credit card number, card holder's name, status, and the action taken.

Error Conditions:

a) Syntactically incorrect input.

b) The specified range is not in the database.

3.4.6 Change Reporting Periods

Inputs:

The date/time of the new reporting period.

Outputs:

The date and time of the old reporting period is displayed. A prompt will ask the user if the change is what was intended and if yes then the period is changed.

Error Conditions:

a) Syntactically incorrect input.

b) The specified date or time is not in the database.

3.4.7 Display Reports Help

Inputs: None.

Outputs:

Displays the functionalties of each of the menu choices. Also how to make a selection.

Error Conditions: None.


Station Operations

Each of the following processes are activated by pressing a button for that process activity.

Process: 3.3.4 Activate/Shutdown Facilities

Allow user to activate or shutdown any of the station facilities.

  • Input: pump status, tank status
  • Output: Either one "on" or "off" button is shown pressed for each of the facilities (which results in actual real life response). Also, a "change" flag is set if anything was changed.
  • Errors: None

Description:

This process will diplay the status of all station facilities, and will allow the user to change any one of them from "on" to "off" or "off" to "on". Only one status for each of the station facilities will be selected (ie. button pressed). No single one can ever have both "on" and "off" pressed at the same time. All selections will be buffered as the changes will not take effect immediately but buttons will still be shown pressed according to any changes.

We are not too sure why these changes can not be done as soon as the button has been pressed. We would rather the changes be done right away.


Each of these controlled station facilities will be represented by a pictoral icon with two buttons beside it. The buttons will be tagged "on" and "off" and only one will be shown pressed at all times.

We will assume any manual shutdowns or activations at the station site will require advising Head Office prior to doing so. Therefore, a notification on the system will not be required. We feel that it is not possible to implement and simulate this type of real-time, immediate notification of a manual shutdown or activation, on the system due to the time constraints for the project.

This is acceptable.


Subprocess: Return to Main Menu From Activate/Shutdown Facilities

To confirm that user changes to station facilities will take effect immediately.

  • Input: Change flag -from main process, (followed by user button selection)
  • Output: Window prompt with buttons if Change flag set. Station Operations Menu displayed if:
    • -Change flag not set or
    • -Cancel button selected or
    • -Continue button selected.

Also write changes to database and initiate station changes if Continue button is selected. Activate/Shutdown Facilities status screen displayed if Redo button is selected. Text window displaying descriptions of each of the three buttons (Continue, Redo, Cancel) and what is the result when selected.

  • Errors: None.

Description:

When something has been changed in the Activate/Shutdown Facilities screen, a flag will be set (Change) to indicate this. So when the screen is exited, a window will appear with a prompt to make sure the user wants to accept the changes. At this time, the user is given four choices (buttons):

  • Continue: accept station changes and return to Station Operations Menu
  • Redo: return to Activate/Shutdown Facilities screen and fix changes
  • Cancel: do not accept changes, leave things as they were before changes and return to Station Operations Menu
  • Help: Another window to help with button clarification

All information about changes are kept in a buffer and it is only written back to the database when the changes are accepted (ie. selected Continue button). The Help button will activate a help window with text describing each of the other three buttons. Contained in this window will also be an OK button to return to the previous window prompt.

We do not understand the above section. We are hoping that your demo will make this section clear to us.

Process: 3.3.1 Display Pump Status

-Show user the status of all station pumps and related information.

  • Input: pump numbers, fuel types, pump status, price per litre, (total gas sold from pump)
  • Output: Display information on screen.
  • Errors: None

Description:

The activated process will display relevant information about all the pumps located at the station. The screen will be divided into the number of pumps available at the station and each pump will have a section assigned to it for displaying its information. Each pump section will have a numbered icon to represent the pump. Different fuel types will be represented by different icons along with the actual type of fuel in words. This will help distinguish different fuel type immediately. Price per litre and totat gas sold will just be simple numerical values. The pump status, whether it is on or off, will be indicated by a highly visible flag.

All information displayed is taken from the database when this process begins so any changes while the display is up will not be reflected immediately, but will be shown the next time the display in brought up.

A Return to Station Operations Menu button will be available for the user when finished viewing the information.

Process: 3.3.3 Display Tank Lock Info

-Show user the status of all station tanks and related information.

  • Input: tank numbers, tank status, fuel types
  • Output: Display information on screen.
  • Errors: None
Description:

Information about the status of all the tank locks at the station will be shown in this display. Also included are the fuel types each tank is holding. The display will be divided into parts equal to the number of tanks at the station. Each section of the display will have information on one of the tanks. All tanks will be represented by a numbered tank icon. The fuel types will be represented by different icons depending on the type. There will also be the type in words following the icon. The tank status will be the main focus of this display so it will have a large area devoted to it (in it's section) where it will show whether it is locked or unlocked using highlighted words.

All information displayed is taken from the database when this process begins so any changes while the display is up will not be reflected immediately, but will be shown the next time the display in brought up.

A Return to Station Operations Menu button will be available for the user when finished viewing the information.

Process: 3.3.2 Display Station Diagnostics

-Show user the status of all station equipment and related information.

    • Input: (Calibration Equipment Status)
    • Output: Display information on screen
    • Errors: None

Description:

Information on station equipment will be displayed on this screen. Each piece of equipment, either it be calibration equipment or tank equipment or pump equipment, will be mentioned in this screen and it will show whether it is OK or NOT OK. This will simply be highlighted text displayed beside the name of the equipment and its icon. Each piece of equipment will have its own icon so it can be identified/located faster.

All information displayed is taken from the database when this process begins so any changes while the display is up will not be reflected immediately, but will be shown the next time the display in brought up. So when a piece of equipment suddenly malfunctions while this display is being viewed, then it will not show up as NOT OK. ***Also note that due to time constraints it is not possible to implement and simulate an real-time, interactive malfunction.***

In the final system, we would like real-time changes as well as an audible alarm to warn us that there is a malfunction (we understand that it may be difficult or impossible to show real-time simulation during the demo).


A Return to Station Operations Menu button will be available for the user when finished viewing the information.

Process: Display Station Operations Menu Help

-Window with an explanation of each of the other 5 buttons on the menu.

    • Input: None
    • Output: display information on screen
    • Errors: None

Description:

The text window that is displayed will contain information about what the following buttons do:

    • -Activation/Shutdown Facilities
    • -Pump Status
    • -Tank Status
    • -Diagnostic check
    • -Return to Main Menu

An OK button will be available for the user when finished viewing the information.

Process: Return to Main Menu (utility)

    • Input: None
    • Output: None
    • Errors: None

Description:

This utility is called to return from submenus (offering this option) to the Main Menu.


FUEL DELIVERY

2 Fill Tank

For the purposes of fuel delivery, as well as for maintenance, a terminal with a link to the head office system will be available at the station sight.

When a fuel delivery to the station is made, the deliverer will be asked to login to the system. The system will recognize the access level, and allow the user to perform only a very restricted number of operations.

The user will be presented with a screen similar to the following:

[fill tank screen]

    • Input: Deliverer's name, choice of fuel type, amount of fuel dispensed.
    • Expected Output: Record keeping data are sent back to the database.
    • Possible Error: Non-numeric data entered into the "fuel dispensed" field

Process Description:

The user will first be asked to enter their name for record keeping purposes. Then the screen will show the number of tanks and the type of fuel stored in each, and allow the user to unlock these, one at a time, by clicking on a button corresponding to the appropriate tank. A message will also be displayed, asking the user to enter the amount of fuel dispensed into the tank once the filling is finished.

This is a bit ambiguous. We would like only the availability to open one tank per transaction (to avoid human error).

When the tank is filled, the user will be expected to enter the amount of fuel dispensed. The input will be checked to ensure that it is numeric. If it is not, a message will be displayed asking the user to reenter the value, stressing that units are not required. The input value as well as the new gauge level reading, deliverer's name, and date and time of delivery will will be stored in the central database. The tank is automatically locked and the system will return to the login screen.


SYSTEM ADMINISTRATION

4 Administration

This screen will allow the user to change the user accounts on the system. This will be necessary to update the user database when staff changes occurr. The administration screen will look similar to the following:

[administration screen]

    • Input: Choice of add user, delete user, or change password.
    • Output: Appropriate entry fields displayed on screen

When the help button is pressed, the purpose of each option will be displayed, as well as a description of the fields which need to be filled for each.

The exit botton will log the user out and redisplay the login screen.

By selecting the appropriate page, one of the following processes will be initiated.

4.1 Add User

    • Input: User ID, Password, Access level
    • Output: New record sent to the database for creation

For adding users, the system will send an entry to the user database to be added, according to the fields entered on the add user screen.

4.2 Delete User

    • Input: User ID
    • Output: User ID sent to database for entry deletion
    • Possible Errors: The user entered is not on the system

For deletion of users, the system will first verify if the user is in the database, and if there is no corresponding entry, will prompt the user to this effect. The administrative account on the system will be unable to delete itself from the system, so that the user database can never be sealed.

We would like a confirmation before the user is deleted from the database.


4.3 Change Password

    • Input: User ID, Old Password, New Password
    • We would like you to prompt us for our new password twice.
      We are also curious if the user is able to change their own password outside of the administration?

    • Output: New entry sent to update the database
    • Possible Errors: User entered is not on the system

When a password change is requested, the system will first verify the user's existance, then verify the current password before sending the new password field to the user database for updating.


Authors:

Phong Tu(Reports), | Les Loh(Station Operations), | Francis Nguyen (Main menus, Change Price), Dom Royko (Administration,Delivery).


Send Comments to Customer Group 11 |

Back


Last Updated on 2/09/97
By Carey Dean Bingham
Email
:
bingham@cpsc.ucalgary.ca