辅导AST11103程序设计、Python，c++，Java编程语言辅导 讲解R语言编程|解析Java程序
- 首页 >> Matlab编程 AST11103 – Individual Project
Faculty of Science and Technology
AST11103 – Individual Project
You are asked to write a simple accounting programme that accurately records daily transactions of all
account holders. The programme provides basic operations including: 1) opening an account, 2) closing
an account, 3) deposit, 4) withdrawal, 5) reading accounts’ details from a file, 6) writing account’s
details to the file, and 7) displaying account details, etc. Assuming the total number of clients will not
exceed 100 (i.e. 100 accounts max.).
The mentioned operations are executed by two types of users: manager and client. The programme
itself should also automatically execute some operations.
The deadline of the project is 23 Apr, 23:59.
Operation definition
This section will define how the above operations should be performed. These operations can be
completed in program-driven (text-based) or event-driven (GUI based) manner.
Remarks: Programme written in event-driven manner will earn higher grade which will be discussed in
later section.
• Programme
o Reading accounts’ details from a file
§ As the system start, the programme should prompt user (either in text or in GUI) to
select a plain text file.
§ The plain text file contains lines of account record. Each line represents one record.
To make it simple, each piece of data is separated by a comma containing name,
account number, initial balance, and status (normal, closed, suspended). Following
is an example:
Li Yin Hong,123-4596-512,45955.05,normal
Yim Yik Wang,594-2844-213,12452.50,normal
Leung Judy,149-5915-294,56866.41,normal
Pang Will,598-9244-234,0,closed
Chu Sing Yim,950-4814-234,324.24,suspended
§ The programme should be able to read those data and break the record down into
multiple pieces of data for further usage.
§ This operation can also be performed if the manager has manually requested.
o Writing accounts’ details to the file
§ Before closing the system, the programme should automatically write those modified
account details back to the file so that all results of operations can be recorded.
§ This operation can also be performed if the manager has manually requested.
§ The file format should be maintained as mentioned in “Reading accounts’ details
from a file”.
AST11103 – Individual Project
Faculty of Science and Technology
• Manager
o Manual request to read/write accounts’ details to the file
§ Refer the processes mentioned in the previous page “Programme” in Operation
definition.
o Opening an account
§ Input the name of client, assign an account number, and set initial balance.
§ Set status as “normal” by default.
§ Account number should be automatically given. The account number could not be
duplicated to the existing ones.
§ Initial balance must be at least $100.00.
§ Make sure this new piece of account details will also be recorded to the file.
o Closing an account
§ Input account number to retrieve existing record. If such a/c number does not exist,
prompt a message to the manager.
§ If an account is found, prompt manager to reconfirm closure of account.
§ If reconfirmation is received, set account balance to 0.
§ DON’T erase the account details. Simply change its status to “closed”.
§ Be reminded such operation should be recorded to the file.
o View account details
§ The programme should provide view(s) for the manager to understand the current
records’ details.
§ It would be helpful it the manger are permitted to have different views by applying
some filters, for instance by account status.
o Apply interests/charges
§ The manager can apply interests or charges to all or an individual account.
§ Interests and charges can be inputted as % or actual amount. For example, the
manager could give 5% interest to all accounts or apply $20 charges to an individual
account.
o End programme
§ Only the manager has the right to end the programme. Once this function has been
triggered, results of account details should be recorded to the file.
AST11103 – Individual Project
Faculty of Science and Technology
• Client
o Deposit
§ Input (or select) a valid a/c number. If invalid, prompt user to re-enter.
§ Increase current balance by an inputted amount.
§ This operation is only possible if the account status is normal.
o Withdrawal
§ Input (or select) a valid a/c number. If invalid, prompt user to re-enter.
§ Decrease current balance by an inputted amount.
§ The current balance must be bigger than the withdrawal amount.
§ This operation is only possible if the account status is normal.
o View of an individual account
§ View of his/her own account details: name, balance, and status
Criteria
• Program-driven (text-based) VS Event-driven (GUI based)
o The programme can be written in program-driven (text) or event-driven (GUI) based but
event-driven based will earn higher marks.
• Error checking
o You should be trying your best to make sure your programme not to be interfered by invalid
input from users. If invalid inputs are found, prompt user for re-attempt.
• Documentation
o You programme should be given enough comments so that the marker could understand your
work.
• Programme flow
o Programme flow should be user-friendly. Menus/pages should be carefully designed and
“going back to previous manual” should be provided, if necessary.
o The programme should continue until the programme is stopped by the manager.
AST11103 – Individual Project
Faculty of Science and Technology
Marking Scheme (Total 40)
• Completeness of programme (20 points)
o Validity of functions
o Proper handlings of invalid inputs
• User-interface (12 points)
o Programme-driven (max. 6 points)
o Event-driven (max. 12 points)
• Documentation (8 points)
o Comments (3 points)
o User-manual (no more than 10 pages) (5 points)
• Live demo (10 points)
o You are required to present your work in live via Zoom. Time for presentation is around 5
minutes.
Be reminded that simply completion of functions DOES NOT make you score full mark in the project.
Project has to been done in a professional manner and has reasonably defend invalid inputs.
Your programme will be put into a plagiarism checking system. ALL parties involved in plagiarism (both
the lender(s) and the borrower(s) will score ZERO if plagiarism is found.
Submission Details
Compress your programme in a .zip file and submit it to Moodle dropbox by 23 April 23:59. Late
submission will be penalized (-15% /per calendar day). Any submission late for more than 3 days will not
be entertained.
Faculty of Science and Technology
AST11103 – Individual Project
You are asked to write a simple accounting programme that accurately records daily transactions of all
account holders. The programme provides basic operations including: 1) opening an account, 2) closing
an account, 3) deposit, 4) withdrawal, 5) reading accounts’ details from a file, 6) writing account’s
details to the file, and 7) displaying account details, etc. Assuming the total number of clients will not
exceed 100 (i.e. 100 accounts max.).
The mentioned operations are executed by two types of users: manager and client. The programme
itself should also automatically execute some operations.
The deadline of the project is 23 Apr, 23:59.
Operation definition
This section will define how the above operations should be performed. These operations can be
completed in program-driven (text-based) or event-driven (GUI based) manner.
Remarks: Programme written in event-driven manner will earn higher grade which will be discussed in
later section.
• Programme
o Reading accounts’ details from a file
§ As the system start, the programme should prompt user (either in text or in GUI) to
select a plain text file.
§ The plain text file contains lines of account record. Each line represents one record.
To make it simple, each piece of data is separated by a comma containing name,
account number, initial balance, and status (normal, closed, suspended). Following
is an example:
Li Yin Hong,123-4596-512,45955.05,normal
Yim Yik Wang,594-2844-213,12452.50,normal
Leung Judy,149-5915-294,56866.41,normal
Pang Will,598-9244-234,0,closed
Chu Sing Yim,950-4814-234,324.24,suspended
§ The programme should be able to read those data and break the record down into
multiple pieces of data for further usage.
§ This operation can also be performed if the manager has manually requested.
o Writing accounts’ details to the file
§ Before closing the system, the programme should automatically write those modified
account details back to the file so that all results of operations can be recorded.
§ This operation can also be performed if the manager has manually requested.
§ The file format should be maintained as mentioned in “Reading accounts’ details
from a file”.
AST11103 – Individual Project
Faculty of Science and Technology
• Manager
o Manual request to read/write accounts’ details to the file
§ Refer the processes mentioned in the previous page “Programme” in Operation
definition.
o Opening an account
§ Input the name of client, assign an account number, and set initial balance.
§ Set status as “normal” by default.
§ Account number should be automatically given. The account number could not be
duplicated to the existing ones.
§ Initial balance must be at least $100.00.
§ Make sure this new piece of account details will also be recorded to the file.
o Closing an account
§ Input account number to retrieve existing record. If such a/c number does not exist,
prompt a message to the manager.
§ If an account is found, prompt manager to reconfirm closure of account.
§ If reconfirmation is received, set account balance to 0.
§ DON’T erase the account details. Simply change its status to “closed”.
§ Be reminded such operation should be recorded to the file.
o View account details
§ The programme should provide view(s) for the manager to understand the current
records’ details.
§ It would be helpful it the manger are permitted to have different views by applying
some filters, for instance by account status.
o Apply interests/charges
§ The manager can apply interests or charges to all or an individual account.
§ Interests and charges can be inputted as % or actual amount. For example, the
manager could give 5% interest to all accounts or apply $20 charges to an individual
account.
o End programme
§ Only the manager has the right to end the programme. Once this function has been
triggered, results of account details should be recorded to the file.
AST11103 – Individual Project
Faculty of Science and Technology
• Client
o Deposit
§ Input (or select) a valid a/c number. If invalid, prompt user to re-enter.
§ Increase current balance by an inputted amount.
§ This operation is only possible if the account status is normal.
o Withdrawal
§ Input (or select) a valid a/c number. If invalid, prompt user to re-enter.
§ Decrease current balance by an inputted amount.
§ The current balance must be bigger than the withdrawal amount.
§ This operation is only possible if the account status is normal.
o View of an individual account
§ View of his/her own account details: name, balance, and status
Criteria
• Program-driven (text-based) VS Event-driven (GUI based)
o The programme can be written in program-driven (text) or event-driven (GUI) based but
event-driven based will earn higher marks.
• Error checking
o You should be trying your best to make sure your programme not to be interfered by invalid
input from users. If invalid inputs are found, prompt user for re-attempt.
• Documentation
o You programme should be given enough comments so that the marker could understand your
work.
• Programme flow
o Programme flow should be user-friendly. Menus/pages should be carefully designed and
“going back to previous manual” should be provided, if necessary.
o The programme should continue until the programme is stopped by the manager.
AST11103 – Individual Project
Faculty of Science and Technology
Marking Scheme (Total 40)
• Completeness of programme (20 points)
o Validity of functions
o Proper handlings of invalid inputs
• User-interface (12 points)
o Programme-driven (max. 6 points)
o Event-driven (max. 12 points)
• Documentation (8 points)
o Comments (3 points)
o User-manual (no more than 10 pages) (5 points)
• Live demo (10 points)
o You are required to present your work in live via Zoom. Time for presentation is around 5
minutes.
Be reminded that simply completion of functions DOES NOT make you score full mark in the project.
Project has to been done in a professional manner and has reasonably defend invalid inputs.
Your programme will be put into a plagiarism checking system. ALL parties involved in plagiarism (both
the lender(s) and the borrower(s) will score ZERO if plagiarism is found.
Submission Details
Compress your programme in a .zip file and submit it to Moodle dropbox by 23 April 23:59. Late
submission will be penalized (-15% /per calendar day). Any submission late for more than 3 days will not
be entertained.