Main System Database and Interface Specifications

Authors | Publisher

 


ER- Diagram

Data Dictionaries

Process Specifications


Entity Relationship Diagram

This Entity Relationship Diagram models the information that must be remembered and therefore stored by the Automated gas Station system over a nontrivial period of time. This information is received as input from various sources including the user, the credit card companies, and the system software itself and must be accessed, modified, or reported at a later time.

This ERD seems about right, but we find it hard to read.
For example, it is unclear what the relationship between Tax and Stats is, and the "deleting" box does not seem to belong because it is an action, not an entity.
Finally, it is not immediately obvious in which direction the "many:1" relationships apply.



Data Dictionaries

Following is a data dictionary of all the data elements that are pertinent to the Automated Gas Station system, with precise, rigorous definitions. These are to help ensure that both users (or "customers") and developers of systems have a common understanding of all the inputs, outputs, components of stores, and intermediate calculations used by a system.

Following are the entities included in the Data Dictionaries. The Data Dictionaries are divided up into four separate parts but each is interrelated via these entities:

Transaction - Stores transaction information.

Transaction Summary - Used as a summary when reporting all Transactions.
Delivery - Stores delivery information.
Rejected Credit Card - Stores rejected credit card information.
Tax - Stores the values of the GST and PST.
Fuel - Stores the types of fuel and their prices per litre.
Pump - Stores pump status.
Tank - Stores tank status.
Login - Stores login information for the Remote Operations System.
Statistics - Used as a summary of the station configuration.
Report - Stores report times for the Batch Processing System.

Good idea to give us a general overview of the data dictionary, but we would appreciate an additional paragraph or two describing how the system uses these entities.



Transaction Data Dictionary

Transaction ID = unsigned integer

Description: The number representing the particular pump at the gas
which delivered the gas for the current transaction.
Parameters: from 1 to #Number of gas pumps at station
Example: 3

Which entity do these attributes belong to? Which is a key attribute?


Transaction Date = date/time

Description: The date on which the transaction took place.
Parameters: dd/mm/yyyy
Example: 24/02/97

Does this mean that the first 2 digits of the year get truncated in the representation? (Just to clarify the given example.)
Also, is it necessary to enclose the parts of the date with slashes?

Customer's First Name = string

Description: The first name of the customer for the current transaction.
Type: Text
Parameters: Length=50
Example: John

Customer's Last Name = string

Description: The last name of the customer for the current transaction.
Parameters: Length=50
Example: Smith

Card Type = ["MasterCard" | "Visa" | "American Express" | "Bank Card"]

Description: The type of credit card or bank card used
Parameters: list
Example: Visa

Will you be specifying different bank cards or just Interac in general?
We don't have a requirement either way - just as long as it works for all cases.


Card Number = string

Description: The account number of the card used for the current transaction
Parameters: [string]
Example: [4520 02 95643657 33]

We have trouble understanding this bracket notation, but using a string is a great idea, rather than storing the actual number

Amount in Litres = real

Description: The number of litres of gas delivered for the current
transaction.
Parameters: OOR.RR
Example: 100.00

Please explain the meaning of OOR.RR. We are not familiar with this notation.


Tax Total = real

Description: The total amount in Canadian dollars charged as tax for the
current transaction.
Parameters: (Gas Amount in Litres Price per Litre) (Tax)
Example: $3.00

Transaction Total = real

Description: The total cost for the current transaction.
Parameters: (Gas Amount in Litres * Price per Litre) + Tax Total
Example: $58.74

This must be a typo, but just to be clear we would like to point out the missing multiplication sign above (in red).

Transaction = @Transaction ID + Transaction Date + Pump + Fuel + Customer's First Name + Customer's Last Name + Card Type + Card Number + Amount in Litres + Tax + Tax Total + Transaction Total

The transaction entity stores data pertaining to each transaction
processed by a pump at the station.

We are concerned that the Transaction ID alone may not be enough of a key to uniquely identify a transaction.


Summary ID = unsigned integer

Description: The ID for the particular report being generated.
Parameters: none
Example: 1

Summary Start = date/time

Description: The starting time for the period of time covered by the report.
Parameters: hh:tt
Example: 13:30

Summary Stop = date/time

Description: The end time of the period of time covered by the report.
Parameters: hh:tt
Example: 23:30

Do the above two items include both date and time or just the time?
As well, you _do_ mean hh:mm, not hh:tt, correct?

Transaction Summary = @Summary ID + Summary Start + Summary Stop

The report entity stores data pertaining to a batch report generated
for the transactions processed during a particular period of time.

Delivery Data Dictionary

Delivery ID = unsigned integer

Description: ID of the delivery of fuel to main tank.
Parameters: none
Example: 04

Delivery Date = date/time

Description: The time of delivery of fuel to main tank.
Parameters: hh:tt
Example: 13:30

Again we need the date of the delivery as well as the time.


Delivery Person First Name = string

Description: First Name of person delivering fuel to main tank.
Parameters: Length = 50
Example: John

Delivery Person Last Name = string

Description: Last Name of person delivering fuel to main tank.
Parameters: Length = 50
Example: Smith

Delivery Person ID = unsigned integer

Description: First Name of person delivering fuel to main tank.
Parameters: Length = 8
Example: 12345678

Few delivery people in our company have a number as their first name.


Delivery Tank Level Before = real

Description: The number of litres in the main tank before delivery of
additional fuel.
Parameters: OOOOO.OO
Example: 10523.50

Delivery Tank Level Added = real

Description: The number of litres added to main tank.
Parameters: OOOOO.OO
Example: 5000.00

Delivery Tank Level After = real

Description: The number of litres in the main tank after delivery.
Parameters: OOOOO.OO
Example: 15523.50

Delivery Total Value = real

Description: The value of the gas added to the tank at current value of gas.
Parameters: $DDDDD.CC
Example: $9158.57

Delivery = @Delivery ID + Delivery Date + Tank + Delivery Person Last Name + Delivery Person First Name + Delivery Person ID + Delivery Tank Level Before + Delivery Tank Level Added + Delivery Tank Level After + Delivery Total Value

Delivery Entity stores the definition for the data records for each
delivery.


Rejected Credit Card Data Dictionary

This section is quite well done, as far as we can see.

Rejected Credit Card ID = unsigned integer

Description: ID of the entry of the rejected credit card into the database.
Parameters: none
Example: 04

Credit Card Number = string

Key attribute of the entity Rejected Credit Card. This is a string field of
maximum 30 characters holding the rejected credit card number including all
relevant spaces.

Card Holder Name = string

Non-key attribute of the entity Rejected Credit Card. This is a string field of
maximum 30 characters and includes the credit card holder's full name, first
and last name, as presented on the rejected credit card.

Status = [ "Lost" | "Stolen" ]

Non-key attribute of the entity Rejected Credit Card. This is an enumerated
type field that specifies the status of the rejected credit card.

Action = [ "Card kept" | "Card returned" | "Credit card company system informed" ]

Non-key attribute of the entity Rejected Credit Card. This is an enumerated
type field that specifies the action taken on the rejected credit card as
specified by the credit card company.

Rejected Credit Card = @Rejected Credit Card ID + Credit Card Number + Card Holder Name + Status + Action

Rejected Credit Card Entity; this represents credit cards that have been
been rejected by credit card companies because they have been reported
lost or stolen.

What about expired cards? They should be rejected too.



System Configuration Data Dictionary

GST = real

This is a member of the entity Tax. It is used to stored the value of the GST.

PST = real

This is a member of the entity Tax. It is used to stored the value of the PST.

Tax = GST + PST

Tax entity; this is the system configuration stored values for the Tax applied
transactions.

Fuel Type = ["Regular" | "Mid Grade" | "Premium" | "Diesel"]

Key attribute of the entity Fuel. This is an enumerated type field indicating
the type of fuel.

Fuel Price per Litre = real

Non-key attribute of the entity Fuel. This is a real field indicating the
price/litre the fuel is to purchase.

Fuel = @Fuel Type + Fuel Price per Litre

Fuel Entity; this represents the fuel types and their respective prices.

Pump Number = integer

Key attribute of the entity Pump. This is an integer field starting at the
minimum value of 1 to the maximum value of the number of pumps installed
at the Automated Gas Station.

Pump Status = [ "On" | "Off" ]

Non-key attribute of the entity Pump. This is an enumerated type field
indicating whether the pump should be On or Off.

Pump = @Pump + Pump Active

Pump and Pump Active are not defined here.


Pump Entity; this represents the different pumps at the Automated gas Station
and allows pumps to be turned On and Off.

Tank Type = ["Regular" | "Mid Grade" | "Premium" | "Diesel"]

Description: The ID of the main tank the gas was delivered to.
Parameters: nn
Example: 02

Tank Status = ["Empty" | "Full"]

Is there any gas in the tanks?

We hope that the tanks never become empty. Shouldn't this be something representing the quantity of gas in the tank, rather than simply a yes/no indicator?


Tank = @Tank Type

Tank entity; this report represents the different tanks at the Automated Gas
Station and is used to identify tanks in delivery reports.

We want the report to contain more than just a list of tank types. It is unclear from this definition whether this is so.


User = string

Key attribute of the entity Login. This is a string field of maximum 8
characters and indicates a unique username for the Remote Operations
Interface.

Password = string

Non-key attribute of the entity Login. This is a string field of minimum 4
characters and maximum 8 characters and indicates a password for the
corresponding username.

Access Level = [ "Level 0" | " Level 1"]

Non-key attribute of the entity Login. This is an enumerated type field that
indicates the access level of the user.

Login = @User + Password + Access Level

Login Entity; this represents the users that may log into the Remote
Operations Interface and their corresponding access password and access
level.

Statistics = Fuel + Pump + Tank + Tax

.

The definition for this item is missing.


Report Date = date/time

Key attribute of the entity Report. This is a date/time field that indicates the
when a report is to be generated. The date field may be an actual date or
may just be "Daily".

Report Type = [ "Transaction" | "Deliveries" | "Rejected Credit Cards" | "Statistics" | "Monthly"]

Non-key attribute of the entity Report. This is an enumerated type field
that indicates the type of report to be generated.

Type Report = @Report Date + Report

Report Entity; this represents when each report is to be generated by the
Automated Gas Station.

In general, the data dictionary displays the Supplier's good analysis of the project. However, a few paragraphs describing the overall organization of the data would aid our understanding.
We are impressed with the supplier's adherence to standard ways of defining data types in this data dictionary.



Process Specifications

These Process Specifcations are the interface for each Data Sotore that holds information located in the Data Dictionaries. One Data Store exists for each Entity.


Which of these modules, if any, do error checking?


Transaction Module

Transaction.Add()
Description:
Add a Transaction to the Transaction Database.
Input: Transaction
Output: None (since addding a transaction will be implemented via a pre-packaged table locking mechanism, there
is no need for a status flag as output)

Transaction.Report()
Description:
Generate a report for all transactions conducted within the batch reporting interval.
Input: Transaction ID
Output: A list of transactions within the specified interval.

Transaction.BackupDatabase()
Description:
This is a private function accessible only by other functions in the Transaction module.
Input: Transaction ID
Output: status

What kind of status is output?


Transaction.ClearDatabase()
Description:
This is a private function accessible only by other functions in the Transaction module.
Input: Transaction ID
Output: status

Transaction Summary Module

TransactionSummary.Report()
Description:
Generate a header for a given report containing Report Summary information.
Input: Transaction Summary.
Output: none

Would it not output the report header?


Delivery Module

Delivery.Add()
Description:
Adds a delivery record to the Deliveries database.
Input: Delivery
Output: none

Wouldn't the output be a delivery record added to the database?


Delivery.Report()
Description:
Prepares a report of all deliveries of fuel to the main gas tanks.
Input: Deliveries
Output: none

Delivery.BackupDatabase()
Description:
This is a private function accessible only by other functions in the Transaction module.
Input: Delivery ID
Output: none

What does this function do? And the one below? If we are expected to evaluate this information, we would expect more detail in a form non-programmers can understand.


Delivery.ClearDatabase()
Description:
This is a private function accessible only by other functions in the Transaction module.
Input: Delivery ID
Output: none

What about provisions for cancelling(deleting) or even modifying a delivery?

Rejected Credit Card Module

RejectedCreditCard.Add()
Description:
Add a rejected credit card entry to the database.
Input: Rejected Credit Card
Output: none

Where is the decision made about what to do with the rejected credit card?


RejectedCreditCard.Report()
Description:
Generates report of all rejected credit cards.
Input: Rejected Credit Cards
Output: none

RejectedCreditCard.BackupDatabase()
Description:
This is a private function accessible only by other functions in the Transaction module.
Input: Rejected Credit Card ID
Output: none

RejectedCreditCard.ClearDatabase()
Description:
This is a private function accessible only by other functions in the Transaction module.
Input: Rejected Credit Card ID
Output: none

 

Tax Module

Tax.setGST()
Description:
This function allows the current GST tax rate to be set. This function is called by the Remote Operations Interface by a User with the appropriate Access Level.
Input: A real indicating the new GST tax rate.
Output: None.

Tax.getGST()
Description:
This function is an accessor function that returns the current GST tax rate. This function is called by the Gas Pump Interface when calculating the Tax Total and Transaction Total fields for a Transaction.
Input: None.
Output: A real indicating the current GST tax rate.

Tax.setPST()
Description:
This function allows the current PST tax rate to be set. This function is called by the Remote Operations Interface by a User with the appropriate Access Level.
Input: A real indicating the new PST tax rate.
Output: None.

Tax.getPST()
Description:
This function is an accessor function that returns the current PST tax rate. This function is called by the Gas Pump Interface when calculating the Tax Total and Transaction Total fields for a Transaction.
Input: None.
Output: A real indicating the current PST tax rate.

Would it be possible for a function to view what the rates currently are?


Fuel Module

This section is much more clear. As non-programmers, we appreciate a detailed description of what the modules do, rather than how they do it.


Fuel.addFuel()
Description:
This function is used when a new type of Fuel is added to the system. It creates a new type of Fuel in the Fuel Database and allows the Automated Gas Station to start tracking the Price per Litre of the new type of Fuel. This function is called by the Remote Operations Interface, by a User with the appropriate Access Level.
Input: An emunerated type integer indicating the Fuel Type, and a real indicating the Price per Litre.
Output: A boolean indicating success or failure to add a new type of Fuel.

Fuel.deleteFuel()
Description:
This function is used when a type of Fuel is removed from the system. It removes the type of Fuel from the Fuel Database. This function is called by the Remote Operations Interface, by a User with the appropriate Access Level.
Input: An enumerated type indicating the Fuel Type.
Output: A boolean indicating success or failure to remove the type of Fuel.

Fuel.setFuelPrice()
Description:
This function allows the Price per Litre to be set for a specific type of Fuel. It updates the Fuel Database with the new Price per Litre. This function is called by the Remote Operations Interface, by a User with the Appropriate Access Level.
Input: An enumerated type indicating the Fuel Type, and a real indicating the new Price per Litre.
Output: A boolean indicating success or failure of setting the Price per Litre of the type of Fuel.

Does this module check to see if the fuel is being pumped first? We can't have the fuel price changing partway through a transaction.


Fuel.getFuelPrice()
Description:
This function allows access to the Price per Litre for a specific type of Fuel. It returns the current Price per Litre from the Fuel Database. This function is called by the Pump Interface, when calculating the Tax Total and Transaction Total fields for a Transaction.
Input: An enumerated type indicating the Fuel Type.
Output: A real indicating the current Price per Litre of the Fuel Type.

Pump Module

Pump.addPump()
Description:
This function is used when a new Pump is added to the system after a new Pump has been installed or a Pump has been down for repairs. It creates a Pump in the Pump Database and allows the Automated Gas Station to start accepting Transactions from the Pump. This function is called by the Remote Operations Interface, by a User with the appropriate Access Level.
Input: None.
Output: A boolean indicating success or failure to add a new Pump

Under what conditions would Add and Delete functions like this fail?


Pump.deletePump()
Description:
This function is used when a Pump is removed from the system for removal or repairs. It removes the Pump from the Pump Database. This function is called by the Remote Operations Interface, by a User with the appropriate Access Level.
Input: An unsigned integer indicating the Pump Number.
Output: A boolean indicating success or failure to remove the Pump.

Pump.setPumpStatus()
Description:
This function allows the Pump Status to be set for a specific Pump to allow the Pump to be turned on or off. It updates the Pump Database with the new Pump Status. This function is called by the Remote Operations Interface, by a User with the Appropriate Access Level.
Input: An unsigned integer indicating the Pump Number, and an enumerated type indicating the new Pump Status.
Output: A boolean indicating success or failure of setting the Price per Litre of the type of Fuel

Pump.getPumpStatus()
Description:
This function allows access to the Pump Status for a specific Pump. It returns the current Pump Status from the Pump Database. This function is called by the Pump Interface, when checking whether the Pump should be on or off, and by the Remote Operations Interface, by a User with the appropriate Access Level.
Input: An unsigned integer indicating the Pump Number.
Output: An enumerated type indicating the current Pump Status of the Pump.

Tank Module

Tank.addTank()
Description:
This function is used when a new Tank is added to the system after a new Tank has been installed or a Tank has been down for repairs. It creates a Tank in the Tank Database and allows the Automated Gas Station to start tracking the status of the new Tank. This function is called by the Remote Operations Interface, by a User with the appropriate Access Level.
Input: None.
Output: A boolean indicating success or failure to add a new Tank.

This action wasn't in our original spec, but we certainly do need the ability to do this in the final system.
If you decide to implement this for the demonstration, we would like to point out that when adding a new tank we need to be able to specify its capacity and what type of fuel it will contain, etc. This is because the tank sizes may vary according to projected sales of the various gas types.


Tank.deleteTank()
Description:
This function is used when a Tank is removed from the system for removal or repairs. It removes the Tank from the Tank Database. This function is called by the Remote Operations Interface, by a User with the appropriate Access Level.
Input: An unsigned integer indicating the TankNumber.
Output: A boolean indicating success or failure to remove the Tank.

Tank.getTankStatus()
Description:
This function allows access to the Tank Status for a specific Tank. It returns the current Tank Status from the Tank Database which is updated via a sensor inside the Tank. This function is called by the Pump Interface, when checking whether their is Fuel in a specific Tank, and by the Remote Operations Interface, by a User with the appropriate Access Level.
Input: An unsigned integer indicating the TankNumber.
Output: An enumerated type indicating the current Tank Status of the Tank.

The fuel, pump, and tank modules are very nicely done

Login Module

Login.addLogin()
Description:
This function is used when a new Login account is added to the system. It creates a Login account in the Login Database and allows a user to log into the new account via the Remote Operations Interface. This function is called by the Remote Operations Interface, by a User with the appropriate Access Level.
Input: None.
Output: A boolean indicating success or failure to add a new Login.

Login.deleteLogin()
Description:
This function is used when a Login account is removed from the system. It removes the Login account from the Login Database. This function is called by the Remote Operations Interface, by a User with the appropriate Access Level.
Input: A string integer indicating the User of the Login account.
Output: A boolean indicating success or failure to remove the Login.

This will be done with a sort of "confirmation" message, we hope. Perhaps something like "Are you sure you want to do this?"
In fact, anything involving a delete function should confirm.

Login.setLoginPassword()
Description:
This function allows the Password for a specific Login account to be set. It updates the Login Database with the new Password. This function is called by the Remote Operations Interface, by a User with the Appropriate Access Level.
Input: A string indicating the User of the Login account.
Output: A boolean indicating success or failure of setting the Password of a User's Login account.

Login.getLoginPassword()
Description:
This function allows access to the Password for a specific Login account. It returns the current Password from the Login Database. This function is called by the Remote Operations Interface when a user attempts to log into the system.
Input: A string indicating the User of the Login account.
Output: A string indicating the Password that corresponds to the User's Login account.

Login.setLoginAccess()
Description:
This function allows the Access Level for a specific Login account to be set. It updates the Login Database with the new Access Level. This function is called by the Remote Operations Interface, by a User with the Appropriate Access Level.
Input: A string indicating the User of the Login account.
Output: A boolean indicating success or failure of setting the Price per Litre of the type of Fuel.

Login.getLoginAccess()
Description:
This function allows access to the Access Level for a specific Login account. It returns the current Access Level from the Login Database. This function is called by the Remote Operations Interface when a user attempts to log into the system.
Input: A string indicating the User of the Login account.
Output: A string indicating the Access Level that corresponds to the User's Login account.

Statistics Module

Statistics.Report()
Description:
This is the only function in the Statistics module. This function generates a report on all the Automated Gas Station Statistics. This includes:

Input: None.
Output: A formatted report of all the Fuels, Pumps, Tank, and Tax settings of the Automated Gas Station.

Report Module

Report.addReport()
Description:
This function is used when a new Report time is added to the system. It creates a Report time entry in the Report Database and allows reports to be generated at specific times. This function is called by the Remote Operations Interface, by a User with the appropriate Access Level.
Input: A date/time indicating the Report Date, and an enumerated type indicating the report Type.
Output: A Boolean indicating success or failure to add a new Login.

Report.deleteReport()
Description:
This function is used when a Report time is removed from the system. It removes the Report time from the Report Database. This function is called by the Remote Operations Interface, by a User with the appropriate Access Level.
Input: A date/time indicating the Report Date.
Output: A Boolean indicating success or failure to remove the Login.

The output is something about adding or removing a login?
We don't understand the meaning of the return values of the two above functions.



Authors : Paul Werbicki, and Vlad Levin


Send Comments to Customer Group 11 |

Back


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