-
Notifications
You must be signed in to change notification settings - Fork 0
mateusfonseca/DorsetCollege.ID24088.CA1.BankApp
Folders and files
| Name | Name | Last commit message | Last commit date | |
|---|---|---|---|---|
Repository files navigation
¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬
$ DORSET COLLEGE BANK APPLICATION $
¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬
$ $
$ Welcome to Dorset College Bank Application's README file! $
$ $
¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬
$ BSc of Science in Computing & Multimedia $
$ OOP - BSC20921 $
$ Stage 2, Semester 1 $
$ November 2021 $
$ Continuous Assessment number 1 (Individual) $
$ $
$ Module Title: Object-Oriented Programming $
$ Module Code: BSC20921 $
$ Weighting: 40% $
$ Maximal Possible Mark: 100 marks $
$ Submission Date: 25/11/21 (via private repository on GitHub) $
$ $
$ Student Name: Mateus Fonseca Campos $
$ Student Number: 24088 $
$ Student Email: 24088@student.dorset-college.ie $
¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬
INTRO
This .NET console application, written in C#, was developed as part of the Object-Oriented Programming module's Continuous
Assessment number 1 of the BSc of Science in Computing & Multimedia course at Dorset College and aims to implement some basic
banking functionalities.
¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬
SUMMARY
1) Assignment Brief
2) Hierarchy
2.1) Classes
2.1.1) Program
2.1.2) User
2.1.3) Employee
2.1.4) Customer
2.1.5) Account
2.1.6) Transaction
2.1.7) TestDriver
2.2) Interfaces
2.2.1) IMenu
3) Directory Tree and Files
3.1) Root
3.2) classes
3.3) database
3.4) interfaces
3.5) test
3.5.1) deploy/1/input-and-output
3.5.2) deploy/2/input-and-output
3.5.3) create/1/input
3.5.4) create/1/output
3.5.5) create/2/input
3.5.6) create/2/output
3.5.7) delete/1/input
3.5.8) delete/1/output
3.5.9) delete/2/input
3.5.10) delete/2/output
3.5.11) delete/3/input
3.5.12) delete/3/output
3.5.13) deposit/1/input
3.5.14) deposit/1/output
3.5.15) deposit/2/input
3.5.16) deposit/2/output
3.5.17) deposit/3/input
3.5.18) deposit/3/output
3.5.19) deposit/4/input
3.5.20) deposit/4/output
3.5.21) history/1/input
3.5.22) history/1/output
3.5.23) history/2/input
3.5.24) history/2/output
3.5.25) list/1/input
3.5.26) list/1/output
3.5.27) list/2/input
3.5.28) list/2/output
3.5.29) withdraw/1/input
3.5.30) withdraw/1/output
3.5.31) withdraw/2/input
3.5.32) withdraw/2/output
3.5.33) withdraw/3/input
3.5.34) withdraw/3/output
3.5.35) withdraw/4/input
3.5.36) withdraw/4/output
3.5.37) withdraw/5/input
3.5.38) withdraw/5/output
3.5.39) withdraw/6/input
3.5.40) withdraw/6/output
3.5.41) custom/1/input
3.5.42) custom/1/output
3.5.43) custom/2/input
3.5.44) custom/2/output
3.5.45) custom/3/input
3.5.46) custom/3/output
3.5.47) custom/4/input
3.5.48) custom/4/output
4) Test Mode
¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬
1) ASSIGNMENT BRIEF
This assignment's task was to develop a .NET console application in C# with basic banking functionalities, such as:
- A login menu, where an user can login either as an employee or a customer.
Employee should be authenticated through a special PIN of value "A1234".
Customer should be authenticated through their first name, last name, account number and personal PIN.
- A customer should have both a savings account and a current account.
- Employees should be able to create and delete accounts, make deposits and withdrawals on behalf of a customer and list all
customers in the database.
- Customers should be able to make deposits and withdrawals, and to list all the transactions for either of their accounts.
- The algorithm for account number generation is the pattern "xx-nn-yy-zz", where xx are the initials of the customer's first
and last name, nn is the length of their full name, yy is the alphabetical position of the first initial and zz is the
alphabetical position of the second initial.
- A customer's PIN should be the last 4 digits of their account number.
- Customers' data should be saved in a file named "customers.txt".
- Transaction data should be saved in files named "AN-savings.txt" and "AN-current.txt", where AN is the customer's account
number, for both savings and current accounts, respectively.
¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬
2) HIERARCHY
The relationship between the components in this project can be outlined as follows:
- Program implements IMenu.
- Employee extends User and implements IMenu.
- Customer extends User and implements IMenu.
- Account is a property of Customer.
- Transaction is a property of Account.
Note: the idea of having IMenu as an interface comes from predicting that, although all users in this project need menus, later
introduced types of user may not need one. That is, if in a later version of this application, a different specialized type of
user is implemented, e.g. an ITAdmin, it would not necessarily need a menu, therefore it is better to have menu-related methods
in an interface instead of having them as abstract methods of the base class User, which would enforce unecessary behavior to
all of its derived classes.
2.1) Classes
2.1.1) Program
This class defines the "driver" of the application. It houses the Main method, which is the entry point of the program. It also
boots up basic variables and objects that are passed on as arguments to other classes during runtime.
Constructors:
- public Program(int,string,string,string[],
string[],char,char,char) initializes the properties enforced by IMenu.
Methods:
- public void Banner(string,string,string[]) prints an enclosed banner used both for greeting and farewell. It has three
sections: head sentence, description and footer. Head sentence and footer
are static in size and the code only centralizes them. The middle section,
description, may be have multiple lines of text. Therefore, the code
provides dynamic linebreakers to prevent overflow.
- public static void Main(string[]) is the entry point of the whole application.
Note: inherited/enforced members are omitted.
2.1.2) User
This class defines the application actor of type User which represents any user of the application. It is an abstract class,
which means that it cannot be directly instantiated. The purpose of this class is to define general properties and methods that
are common to any derived class that may inherit from it (e.g., Employee, Customer).
Properties:
- public string Pin stores the PIN code of a user.
Methods:
- abstract public bool logIn(TestDriver) returns true or false depending on whether the user was able to log in.
- abstract public bool start(List<Customer>,
TestDriver) returns true or false depending on whether the application should go back to
the start.
- public bool pinAuthentication(User,TestDriver) verifies that a given PIN code is authentic by checking it against what is
stored for the user in the database.
- public Customer customerIdentification(
List<Customer>,TestDriver) scans the database in search for a user whose credentials (i.e., first name,
last name and account number) match those given. It returns an object the
represents the found customer if it exists in the database and a blank
customer object if not. It also returns null if the user aborts the process.
- public string whichAccount(TestDriver) returns a string that identifies whether the user is trying to access an
account of type savings or current.
- public List<Customer> deposit(List<Customer>,
Customer,TestDriver) increases the value of the Balance property for either the savings or
current account of a given customer. It returns an updated version of the
customers list if the operation was successful or an unaltered version of it
in case of failure.
- public List<Customer> withdraw(List<Customer>,
Customer,TestDriver) decreases the value of the Balance property for either the savings or
current account of a given customer. It returns an updated version of the
customers list if the operation was successful or an unaltered version of
it in case of failure.
- public List<Customer> importCustomers(
TestDriver) loads all customers' data from the database and stores them in a list which
is returned. If the database file cannot be found, the method creates one
and returns an empty list.
- public List<Customer> saveCustomers(
List<Customer>,TestDriver) writes the current state of the customers list to the database file. If the
file cannot be found, the method creates one. It returns the list of
customers.
- public void saveTransactions(List<Transaction>,
string,string,TestDriver) writes the last transaction performed in the system to the database
according to the account type.
2.1.3) Employee
This class defines the application actor of type Employee which represents a bank clerk. As a specialized type of User, it has
access to all of the base class' members, it is enforced the implementation of the latter's abstract members and offers methods
of its own. It also implements the IMenu interface, which allows an Employee instance to handle an employee-oriented menu.
Constructors:
- public Employee(string,int,string,string,
string[],string[],char,char,char) initializes the Pin property (inherited from User) and all the properties
enforced by IMenu.
Methods:
- public List<Customer> createCustomer(
List<Customer>,TestDriver) triggers the instantiation of a new object of type Customer. It calls the
User's customerIdentification method to validate naming format and verify
that those credentials do not belong to a customer already present in the
system. It also validates email format by testing the Address property of
the MailAddress class, which is set to true if the address is valid and
false if not.
- public List<Customer> deleteCustomer(
List<Customer>,TestDriver) removes an identified instance of the Customer class from the database. It
calls the User's customerIdentification method to verify that the informed
credentials in fact belong to a customer currently present in the system. It
also checks that both balances of the customer's account are zeroed,
otherwise the account cannot be deleted.
- public void listCustomers(List<Customer>,
TestDriver) prints a formatted list with all the customers currently present in the
system.
Note: inherited/enforced members are omitted.
2.1.4) Customer
This class defines the application actor of type Customer which represents a bank customer. As a specialized type of User, it
has access to all of the base class' members, it is enforced the implementation of the latter's abstract members and offers
methods of its own. It also implements the IMenu interface, which allows an Customer instance to handle an customer-oriented menu.
Properties:
- public string AccountNumber stores the auto-generated account number of a customer account.
- public string FirstName stores the first name of a customer.
- public string LastName stores the last name of a customer.
- public string Email stores the email address of a customer.
- public Account Savings stores savings account details of a customer account.
- public Account Current stores current account details of a cusomter account.
Constructors:
- public Customer() invoked when creating a generic instance of Customer that works as a
placeholder that will eventually be assigned the content of a real
identified customer.
- public Customer(int,string,string,string[],
string[],char,char,char) initializes the properties enforced by IMenu.
- public Customer(string,string,string) invoked when a brand new customer account is created and there is no data to
be retrieved from the database.
- public Customer(string,string,string,string,
string,decimal,decimal,TestDriver) invoked when an existing customer account is loaded from the database.
Methods:
- public void transactionHistory(TestDriver) prints a formatted list with all the transactions for a specified account
type.
Note: inherited/enforced members are omitted.
2.1.5) Account
This class defines individual accounts for the customers in the application. It keeps record of the account's dynamic details
(i.e., Balance and Transactions).
Properties:
- public decimal Balance stores the current balance of the account.
- public List<Transaction> Transactions defines a list that keeps record of all transactions for the account.
Constructors:
- public Account(string) invoked when a brand new customer account is created and there is no data
to be retrieved from the database.
- public Account(decimal,string) invoked when an existing customer account is loaded from the database.
2.1.6) Transaction
This class defines individual transactions for the accounts in the application. Every time a new transaction is created (e.g.,
a deposit, a withdrawal), an object of this class is instantiated to represent that transaction and keep record of its details.
Properties:
- public DateTime Date stores both date and time when the transaction happens.
- public string Type stores the type of the transaction (either deposit or withdrawal).
- public decimal Amount stores the amount of money of the transaction.
- public decimal Balance stores the final balance of the account after the transaction happens.
Constructors:
- public Transaction(DateTime,string,decimal,
decimal) initializes all four properties of the class.
2.1.7) TestDriver
This class defines an "pseudo-actor" that drives the application when it is set to run in test mode. It signals all classes and
methods in the program that they should read input data from a file instead of the standard input stream (usually the keyboard)
and write output data to another file instead of the standard output stream (usually the monitor). It also provides safety by
validating the input file used when in test mode, preventing the program from being stuck in a endless execution cycle in the
occasion of a badly designed input script, that is, when the file does not indicate a way out.
Properties:
- public bool IsTest a "flag" that signals other classes whether the application is running in
test mode.
- public string FilePathIn stores the file path to the directory where input files are kept.
- public string FilePathOut stores the file path to the directory where output files are kept.
- public string EndOfFile a "code" that marks the end of the input file used while in test mode. It
prevents the program from being trapped inside of infinite loops.
- public StreamReader Input defines the reading source when in test mode.
- public StreamWriter Output defines the writing destination when in test mode.
Constructors:
- public TestDriver(string) invoked when the program is set not to run in test mode.
- public TestDriver(string,string,string) invoked when the program is set to run in test mode.
Methods:
- private string validateInput(string,string) validates the input file when running in test mode by making sure that the
file contains the EndOfFile code. If the file does not exist, the method
creates one.
2.2) Interfaces
2.2.1) IMenu
This interface defines properties and methods to be implemented by classes that wish to print a customizable and responsive
menu, that is, a menu block that adjusts itself to the length of the content it displays. Please, notice that, as an interface,
IMenu only declares and enforces the implementation of its members, but does not really define their use and behavior. It is up to
the implementing classes to do so. The comments below should be seen as general guidelines aiming to explain the intent behind
this interface as of its creation and not as a limitation to its use. Do get funky with it if you will!
Properties:
- string Title defines the title to displayed on the menu header.
- string SubTitle defines the subtitle to be displayed on the menu header.
- string[] Message defines an array of different messages to be displayed on the menu body as
needed.
- string[] Options defines an array of different menu options to be displayed on the menu body
as needed.
- int Width defines the internal width of the menu box.
- char Corner defines the character to be used as corner delimeter of the menu box.
- char Col defines the character to be used as column delimeter of the menu box.
- char Row defines the character to be used as row delimeter of the menu box.
Methods:
- void menuHeader() prints the header of the menu and houses the title and the subtitle.
- void menuBody(int,int) prints the body of the menu and houses the message and the options.
- string getLeftPadding(string,string,int) returns a padding string based on a predefined width and the length of a
piece of text.
- string getRightPadding(string,string,int,string) returns a padding string based on a predefined width, the length of a piece
of text and the padding string on the opposite side.
¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬
3) DIRECTORY TREE AND FILES
This section describes the structure and organization of files and folders within the project's repository. It does not cover
files and folders created by .NET core by default, in which case, please refer to https://docs.microsoft.com/en-us/dotnet/.
3.1) Root
The repository starts here, the root houses every file and directory of this project.
- Program.cs: file with the C# code for the Program class (refer to 2.1.1).
3.2) classes
This directory houses all class files of the project with the exception of Program.cs, which is at the root (refer to 3.1).
- User.cs: file with the C# code for the User class (refer to 2.1.2).
- Employee.cs: file with the C# code for the Employee class (refer to 2.1.3).
- Customer.cs: file with the C# code for the Customer class (refer to 2.1.4).
- Account.cs: file with the C# code for the Account class (refer to 2.1.5).
- Transaction.cs: file with the C# code for the Transaction class (refer to 2.1.6).
- TestDriver.cs: file with the C# code for the TestDriver class (refer to 2.1.7).
3.3) database
This directory houses the files necessary to keep track of the current state of the application. It may be empty at first, but
it gets populated as accounts and transactions are created.
- customers.txt: file with all customers' information. Each line in the file refers to an individual customer and it follows the
pattern "ACCOUNT-NUMBER|FIRST-NAME|LAST-NAME|E-MAIL-ADDRESS|PIN-CODE|SAVINGS-BALANCE|CURRENT-BALANCE", where the pipe symbol
('|') acts as a delimeter.
- AN-savings.txt: file with all transactions of a specific customer for their savings account. The "AN" in the name of the file
is a placeholder for the actual account number. Each line in the file refers to an individual transaction and it follows the
pattern "DAY/MONTH/YEAR|HOUR:MINUTE|TRANSACTION|AMOUNT|BALANCE", where the pipe symbol ('|') acts as a delimeter.
- AN-current.txt: file with all transactions of a specific customer for their current account. The "AN" in the name of the file
is a placeholder for the actual account number. Each line in the file refers to an individual transaction and it follows the
pattern "DAY/MONTH/YEAR|HOUR:MINUTE|TRANSACTION|AMOUNT|BALANCE", where the pipe symbol ('|') acts as a delimeter.
3.4) interfaces
This directory houses the one interface file of the project.
- IMenu.cs: file with the C# code for the IMenu interface (refer to 2.2.1).
3.5) test
This directory houses all files and folders necessary to the test mode of the project.
3.5.1) deploy/1/input-and-output
This directory houses the input/output files necessary/generated to/by the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
- customers.txt: this file represents the state of the database after the test (refer to 3.3).
- AE-14-01-05-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- AE-14-01-05-current.txt: this file represents the state of the database after the test (refer to 3.3).
- AS-15-01-19-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- AS-15-01-19-current.txt: this file represents the state of the database after the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database after the test (refer to 3.3).
- AU-13-01-21-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- AU-13-01-21-current.txt: this file represents the state of the database after the test (refer to 3.3).
- DM-09-04-13-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- DM-09-04-13-current.txt: this file represents the state of the database after the test (refer to 3.3).
- FB-12-06-02-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- FB-12-06-02-current.txt: this file represents the state of the database after the test (refer to 3.3).
- GG-11-07-07-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- GG-11-07-07-current.txt: this file represents the state of the database after the test (refer to 3.3).
- LS-13-12-19-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- LS-13-12-19-current.txt: this file represents the state of the database after the test (refer to 3.3).
- PA-12-16-01-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- PA-12-16-01-current.txt: this file represents the state of the database after the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database after the test (refer to 3.3).
3.5.2) deploy/2/input-and-output
This directory houses the input/output files necessary/generated to/by the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
- customers.txt: this file represents the state of the database after the test (refer to 3.3).
- AE-14-01-05-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- AE-14-01-05-current.txt: this file represents the state of the database after the test (refer to 3.3).
- AS-15-01-19-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- AS-15-01-19-current.txt: this file represents the state of the database after the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database after the test (refer to 3.3).
- AU-13-01-21-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- AU-13-01-21-current.txt: this file represents the state of the database after the test (refer to 3.3).
- DM-09-04-13-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- DM-09-04-13-current.txt: this file represents the state of the database after the test (refer to 3.3).
- FB-12-06-02-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- FB-12-06-02-current.txt: this file represents the state of the database after the test (refer to 3.3).
- GG-11-07-07-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- GG-11-07-07-current.txt: this file represents the state of the database after the test (refer to 3.3).
- LS-13-12-19-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- LS-13-12-19-current.txt: this file represents the state of the database after the test (refer to 3.3).
- PA-12-16-01-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- PA-12-16-01-current.txt: this file represents the state of the database after the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database after the test (refer to 3.3).
3.5.3) create/1/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.4) create/1/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
- customers.txt: this file represents the state of the database after the test (refer to 3.3).
- MC-12-13-03-savings.txt: this file represents the state of the database after the test (refer to 3.3).
- MC-12-13-03-current.txt: this file represents the state of the database after the test (refer to 3.3).
3.5.5) create/2/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.6) create/2/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
3.5.7) delete/1/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.8) delete/1/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
- customers.txt: this file represents the state of the database after the test (refer to 3.3).
3.5.9) delete/2/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.10) delete/2/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
3.5.11) delete/3/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.12) delete/3/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
3.5.13) deposit/1/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.14) deposit/1/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
- customers.txt: this file represents the state of the database after the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database after the test (refer to 3.3).
3.5.15) deposit/2/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.16) deposit/2/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
3.5.17) deposit/3/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.18) deposit/3/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
- customers.txt: this file represents the state of the database after the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database after the test (refer to 3.3).
3.5.19) deposit/4/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.20) deposit/4/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
3.5.21) history/1/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
- MC-12-13-03-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- MC-12-13-03-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.22) history/1/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
3.5.23) history/2/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
- MC-12-13-03-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- MC-12-13-03-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.24) history/2/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
3.5.25) list/1/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
- MC-12-13-03-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- MC-12-13-03-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.26) list/1/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
3.5.27) list/2/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
3.5.28) list/2/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
3.5.29) withdraw/1/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.30) withdraw/1/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
- customers.txt: this file represents the state of the database after the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database after the test (refer to 3.3).
3.5.31) withdraw/2/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.32) withdraw/2/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
3.5.33) withdraw/3/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.34) withdraw/3/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
3.5.35) withdraw/4/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.36) withdraw/4/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
- customers.txt: this file represents the state of the database after the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database after the test (refer to 3.3).
3.5.37) withdraw/5/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.38) withdraw/5/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
3.5.39) withdraw/6/input
This directory houses the input files necessary to the test mode and scenario in question.
- input.txt: input script file. Each line in the file is sequencially fed into the program as it runs in test mode.
- customers.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- AT-10-01-20-current.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-savings.txt: this file represents the state of the database before the test (refer to 3.3).
- SG-13-19-07-current.txt: this file represents the state of the database before the test (refer to 3.3).
3.5.40) withdraw/6/output
This directory houses the output files generated by the test mode and scenario in question.
- output.txt: output log file. Each line in the file is sequencially fed by the program as it runs in test mode.
3.5.41) custom/1/input
This directory may house the input files necessary to the test mode and scenario in question.
3.5.42) custom/1/output
This directory may house the output files generated by the test mode and scenario in question.
3.5.43) custom/2/input
This directory may house the input files necessary to the test mode and scenario in question.
3.5.44) custom/2/output
This directory may house the output files generated by the test mode and scenario in question.
3.5.45) custom/3/input
This directory may house the input files necessary to the test mode and scenario in question.
3.5.46) custom/3/output
This directory may house the output files generated by the test mode and scenario in question.
3.5.47) custom/4/input
This directory may house the input files necessary to the test mode and scenario in question.
3.5.48) custom/4/output
This directory may house the output files generated by the test mode and scenario in question.
¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬
4) TEST MODE
This application offers a test mode. To access it, specific arguments need to passed to the main method when executing the
application. The CLI syntax for running the program in test mode is:
- dotnet run test {FEATURE} {SCENARIO}
Alternatively, you can pass FEATURE and SCENARIO as the first and second arguments of the main method, respectively, through the
GUI of your favorite IDE.
Where:
FEATURE SCENARIO
deploy Automatically populates the database.
1 - Output files are kept in the test directory only and the current database files are NOT overwritten.
2 - Output files are copied to the database directory. Any equally-named file in the database is overwritten.
create Tests the system's functionality of opening customer accounts.
1 - The customer does not yet exist in the database and account creation is successful.
2 - The customer already exists in the database and account creation fails.
delete Tests the system's functionality of closing customer accounts.
1 - The customer exists in the database and their accounts' balances are zeroed. Deletion is successful.
2 - The customer exists in the database but their accounts' balances are NOT zeroed. Deletion fails.
3 - The customer is not in the database and account deletion fails.
list Tests the system's functionality of listing all customer accounts' details.
1 - There is, at least, one customer in the database. Listing is successful.
2 - There are no customers in the database. Listing fails.
history Tests the system's functionality of displaying transaction history.
1 - There is, at least, one transaction in the database. History view is successful.
2 - There are no transactions in the database. History view fails.
deposit Tests the system's functionality of making deposits.
1 - The customer exists in the database. Deposit is successful (Employee's perspective).
2 - The customer does not exist in the database. Deposit fails (Employee's perspective).
3 - The customer exists in the database. Deposit is successful (Customer's perspective).
4 - The customer does not exist in the database. Deposit fails (Customer's perspective).
withdraw Tests the system's functionality of making withdrawals.
1 - The customer exists in the database and has funds. Withdrawal is successful (Employee's perspective).
2 - The customer exists in the database but does not have funds. Withdrawal fails (Employee's perspective).
3 - The customer does not exist in the database. Withdrawal fails (Employee's perspective).
4 - The customer exists in the database and has funds. Withdrawal is successful (Customer's perspective).
5 - The customer exists in the database but does not have funds. Withdrawal fails (Customer's perspective).
6 - The customer does not exist in the database. Withdrawal fails (Customer's perspective).
custom Runs customized test scripts.
1 - Runs customized test script #1
2 - Runs customized test script #2
3 - Runs customized test script #3
4 - Runs customized test script #4
When test mode is on, the standard input stream (usually the keyboard) is set to a file named input.txt instead that drives the
program through the test by feeding all of its requests for input during execution. Each line in input.txt corresponds to an
answer to an input request. Also, when running in test mode, the standard output stream (usually the monitor) is set to a file
named output.txt instead, which will log all the output produced by the application during execution and can be later used for
troubleshooting and debugging.
As a safety measure, the input files have to end with the special string "!EOF!", which is a end-of-file flag that tells the
program that there is nothing else to read from the file and, if any input requests remain, something went wrong and execution
should stop. This prevents the application from being trapped in infinite loops. If an input script lacks the EOF code, it will
be added to it automatically by the program before running the test.
Besides all the standard test modes outlined above, the application offers four slots for customized tests. All that is needed
is an customized input file script to be placed in the correct directory.
To understand where all files are kept for each test mode and scenario, please refer back to section 3.5.
¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬
$ DORSET COLLEGE BANK APPLICATION $
¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬
$ $
$ Thanks for reading Dorset College Bank Application's README file! $
$ $
¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬¬
About
Simple .NET console bank application, written in C#.
Resources
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published