Web Development Technologies
Summer Semester - 2024 Page 1 of 16
COSC2276 / COSC2277 Assignment 2 Specification
Deadline Monday, 29/01/2024 11:59pm AEST
Mandatory face to face demo 30/01/2024 and 31/01/2024 (Bookings TBA)
No face to face demo = No marks
Total marks 40 marks
% Allocated to this assignment 40%
Assignment mode In a group of 2 OR individually
To be submitted via Canvas
2.1 IMPORTANT
a. You MUST submit your code via Canvas. See section 2.9 Submission Procedure for
more information.
b. You will be marked on the use of GitHub and development process.
• You must join the rmit-wdt-summer-2024 GitHub organisation using a
GitHub account that has been registered with your RMIT student email
address.
• Using a personal GitHub repository and not being a part of the
rmit-wdt-summer-2024 GitHub organisation will lead to ZERO for the
whole assignment.
• The GitHub repository for this assignment must be private and named as:
<student-id>-a2 for example -a2
If working in a group include all student IDs in the repository name as:
<student-id>-<student-id>-a2 for example - -a2
• Include the URL of your GitHub repository in the readme file. The URLs for
the repositories shown in the examples above would be:
https://github.com/rmit-wdt-summer-2024/  -a2
https://github.com/rmit-wdt-summer-2024/  - -a2
c. You MUST make a commit at the beginning of the assignment period. You must also
commit on a regular basis and make use of branches. Branches must represent the
implementation of specific features.
d. All data must be saved to an Azure Microsoft SQL Server database. Using any other
database or files to save data will lead to ZERO for the whole assignment.
e. In an advanced elective like this we place importance on code quality and the
development process.
f. Do NOT MAKE ASSUMPTIONS regarding the specifications. When in doubt post
a question on Canvas or email us.
g. The marks will be weighted according to your contribution within the group.
Please submit the contribution form.
Web Development Technologies
Summer Semester - 2024 Page 2 of 16
2.2 PLAGIARISM
All assignments will be checked with plagiarism-detection software; any student found to
have plagiarised would be subject to disciplinary action. Plagiarism includes:
• CONTRACT CHEATING: Paying someone to do your work.
• Copying code from assessments completed by students from previous
semesters.
• Posting assignment questions (in full or partial) on external forums, reddit, etc…
• Submitting work that is not your own or submitting text that is not your own.
• Copying work from / of previous / current semester students.
• Allowing others to copy your work via email, printouts, social media, etc…
• Sending or passing your work to your friends.
• Posting assignment questions on technical forums to get them solved.
A disciplinary action can lead to:
• A meeting with the disciplinary committee.
• A score of zero for the assignment.
• A permanent record of copying in your personal university records and / or
• Expulsion from the university, in some severe cases.
All plagiarism will be penalised. There are no exceptions and no excuses. You have been
warned. For more details, please read RMIT’s page on Academic Integrity at:
https://www.rmit.edu.au/students/my-course/assessment-results/academic-integrity
Web Development Technologies
Summer Semester - 2024 Page 3 of 16
2.3 Scope
The aim of this assignment is to develop an ASP.NET Core MVC Website for Internet
Banking with .NET 8.0 written in C# using Visual Studio 2022 with an Azure Microsoft
SQL Server database. Database access is to be implemented with EF Core as the ORM with
no SQL statements present.
2.4 Overview
MCBA (Most Common Bank of Australia) was impressed by the console application and
wants you to design their Internet Banking website. It is a simulated banking application.
When complete, the system will be able to:
• Check account balance and transaction history.
• Simulate transactions such as deposits and withdrawals.
• Transfer money between accounts.
• Schedule payments.
• Modify a personal profile.
• Perform administrative tasks.
The following diagram depicts the logical architecture:

MCBA
Web
Pages
I
MCBA
Database
II III
Bank
BillPay
Security
Other
Admin
Data
Access
Web Development Technologies
Summer Semester - 2024 Page 4 of 16
The architecture is a three-tiered distributed design.
Layer I: User Interface (Presentation Layer): Will contain the VIEWS (web pages).
Lorem Ipsum content is not allowed.
Please add meaningful content and images to the pages.
Layer II: Business Logic / Object Layer: All the functionality will be present in this layer.
You can use CONTROLLERS or Business Objects for this purpose.
Business Objects are separate files where pieces of usable functionality are written. Instead of
writing all application logic in controllers, you can call methods defined in business objects.
Layer III: Database / Data: This comprises of your Azure Microsoft SQL Server database.
For database operations you MUST only use Entity Framework Core (EF Core). If your
query cannot be expressed with EF Core syntax you may use embedded SQL queries within
the ORM - however you must justify the use of any SQL in the readme file. Do not resort to
using SQL unless necessary.
Web Development Technologies
Summer Semester - 2024 Page 5 of 16
2.5 Database
Below is a more detailed version of the database provided to you for Assignment 1. This design
is only a suggestion, you can modify the database structure, for example changing or adding
constraints, default values, tables, fields, etc… however an unnormalized database with
duplicated data / not well-defined entities / too few tables will attract HEAVY penalty.
 1
 1 *
 1

*
*
*
1
IMPORTANT NOTE: All format constraints must be enforced with server-side validation.
Brief description of these tables follows →
Customer
PK CustomerID
 Name
 TFN
 Address
 City
 State
 Postcode
 Mobile
Login
PK LoginID
 CustomerID
 PasswordHash


Account
PK AccountNumber
 AccountType
 CustomerID


BillPay
PK BillPayID
 AccountNumber
 PayeeID
 Amount
 ScheduleTimeUtc
 Period


Transaction
PK TransactionID
 TransactionType
 AccountNumber
 DestinationAccountNumber
 Amount
 Comment
 TransactionTimeUtc

Payee
PK PayeeID
 Name
 Address
 City
 State
 Postcode
 Phone
Web Development Technologies
Summer Semester - 2024 Page 6 of 16
Customer Table
Field Name Data Type Length Description Format Allow Null
CustomerID int A unique ID for
each customer
Must be 4
digits
NOT NULL
Name nvarchar 50 NOT NULL
TFN nvarchar 11 Tax File Number,
this is just for
identification
purposes, no tax
implications
Must be of
the format:
XXX XXX XXX
Address nvarchar 50
City nvarchar 40
State nvarchar 3 Must be a 2
or 3
lettered
Australian
state
Postcode nvarchar 4 Must be 4
digits
Mobile nvarchar 12 Must be of
the format:
04XX XXX XXX
Login Table
Field Name Data Type Length Description Format Allow Null
LoginID char 8 Must be 8
digits
NOT NULL
CustomerID int FK to Customer NOT NULL
PasswordHash char 94 Must be
stored in
salted and
hashed
format
NOT NULL
Web Development Technologies
Summer Semester - 2024 Page 7 of 16
Account Table
Field Name Data Type Length Description Format Allow Null
AccountNumber int A unique ID for
each account,
also the
customer’s
account number
Must be 4
digits
NOT NULL
AccountType char The type of
account such as
checking or
savings account
‘C’ or ‘S’ NOT NULL
CustomerID int FK to Customer NOT NULL
Transaction Table
Field Name Data Type Length Description Format Allow
Null
TransactionID int Autogenerated
unique ID
for each
transaction
NOT
NULL
TransactionType char Type of
transaction
Refer to
Transaction
Types below
NOT
NULL
AccountNumber int Source
account,
FK to
Account
NOT
NULL
DestinationAccountNumber int Target
account,
used for
transfers,
FK to
Account
Amount money Amount to
credit or
debit for
the
transaction
Must be a
positive
value
NOT
NULL
Comment nvarchar 30 Comment for
the
transaction
TransactionTimeUtc datetime2 Date and
time when
the
transaction
occurred
NOT
NULL
Web Development Technologies
Summer Semester - 2024 Page 8 of 16
BillPay Table
Field Name Data Type Length Description Format Allow
Null
BillPayID int Auto-generated
unique ID
NOT
NULL
AccountNumber int Account number
to withdraw
funds from,
FK to Account
NOT
NULL
PayeeID int FK to Payee NOT
NULL
Amount money Amount of funds
to be withdrawn
from the
account
Must be a
positive
value
NOT
NULL
ScheduleTimeUtc datetime2 Next scheduled
date and time
for transaction
to occur
NOT
NULL
Period char How often
scheduled
payment will
occur
One-off ‘O’
OR
Monthly ‘M’
NOT
NULL
Payee Table
Field Name Data Type Length Description Format Allow Null
PayeeID int Auto-generated
unique ID
NOT NULL
Name nvarchar 50 NOT NULL
Address nvarchar 50 Payee’s address NOT NULL
City nvarchar 40 NOT NULL
State nvarchar 3 Must be a 2
or 3
lettered
Australian
state
NOT NULL
Postcode nvarchar 4 Must be 4
digits
NOT NULL
Phone nvarchar 14 Must be of
the format:
(0X) XXXX XXXX
NOT NULL
Web Development Technologies
Summer Semester - 2024 Page 9 of 16
Transaction Types
D = Credit Deposit
W = Debit Withdraw
T = Debit Transfer from source account (outgoing transfer transaction)
T = Credit Transfer to target account (incoming transfer transaction)
S = Debit Service Charge
B = Debit BillPay
Customer table is used to store all the customer information. Distinguishes between bank
customers and payees by creating a separate Payee table. Only the bank’s own customers will
be held in the Customer table.
Login table is used to store customer’s username and salted + hashed password allowing
customers to login to the website.
Account table is used to store all the information about the different accounts that a customer
may have.
Transactions table is used to track all credit and debit items. Each credit adds the amount to
the account’s balance and each debit subtracts the amount from the account’s balance.
BillPay table is used to schedule automatic payments to a third party such as a telephone bill,
electricity bill, or a home mortgage company. You can schedule these payments to be made at
a specific date and time as a one-off or monthly payment.
2.6 Business Rules
Refer to section 1.5 Business Rules within the Assignment 1 specification for the business
rules.
NOTE: BillPay transactions do not incur a service charge.
Web Development Technologies
Summer Semester - 2024 Page 10 of 16
2.7 Tasks and Marking Allocation
Part 1: Internet Banking - Customer Website [23 marks]
a) [3 marks] Using EF Core Code First approach create suitable Models and DbContext to
represent the database schema. The migrations needed to generate the database schema must
also be included within the project.
b) [2 marks] Implement the pre-loading of data by making a REST call using HTTP GET to
the provided customers web-service using the JSON returned to insert data into the database
as appropriate. Generics should be used for the JSON deserialisation. The REST call should
be implemented using the System.Net.Http.HttpClient class provided by .NET.
NOTE: Contacting the customers web-service should only occur if the system has no
customer data. If there are any customers present in the database, then the web-service should
not be contacted.
Customers Web-Service
https://coreteaching01.csit.rmit.edu.au/~e103884/wdt/services/customers/
The TransactionTimeUtc format is:
<day>/<month>/<year> <hour>:<minute>:<second> <AM or PM>
When inserting customers and creating their accounts all the transactions from the web-service
should be transaction type D (Deposit). Additionally, the account’s balance should be set to
the sum of all the account’s associated transactions.
Web Development Technologies
Summer Semester - 2024 Page 11 of 16
Refer to the Dealing_with_Passwords.pdf file for information on how to handle passwords
and using the PasswordHash field.
c) [6 marks] Create a login page (start page), which should have some introductory
information about the bank and a form to login. Once logged in provide a logout link. You
may use the customised logic for login and logout discussed during Day 6.
Once logged in the user should be shown the balance for all their accounts. Each page must
include a navigation bar which should provide links to the following features:
Deposit || Withdraw || Transfer || My Statements || My Profile
The UI layout and design is up to you. For example, you could have a separate page for
Deposit, Withdraw and Transfer or reuse the same page for all these actions, etc…
Implement the ATM (Deposit & Withdraw) and Transfer features. The user should be able to
transfer money between their own accounts and to accounts of other users. The user should be
able to enter a comment when performing a Deposit, Withdraw and Transfer transaction.
When performing a Deposit, Withdraw or Transfer transaction the user should be presented
with a confirmation page displaying the details of the transaction with an option to confirm
or cancel the transaction.
d) [3 marks] My Statements page allows the user to see the current balance for a specified
account and list its transaction history. The transactions should be ordered by transaction time
with the most recent transaction coming first and must be displayed in a paged manner,
showing only 4 transactions at a time and allows the user to move to the next and previous
pages as appropriate. The transactions should be displayed in a tabulated format with the first
row displaying the headings for each column and all columns should be in alignment.
The transaction ID, transaction type, account number, destination account number, amount,
transaction time and comment fields should all be displayed. The transaction time should
display both the date and time information with the date portion in the DD/MM/YYYY
format and the time portion in the <hour>:<minute> <AM or PM> format, for example
03/01/2024 07:00 AM.
e) [2 marks] My Profile page displays the user’s customer information Name, TFN, Address,
City, State, Postcode and Mobile in a read-only (non-editing) view. The user should be able to
proceed to modify this information. The user should also be able to change their password
independently from the customer information. Any updates made must be written back to the
database.
f) [3 marks] All format constraints (outlined in the table descriptions) must be enforced with
server-side validation. The format constraints can also be enforced with client-side validation
if desired, however server-side validation is mandatory.
These format constraints should be implemented using appropriate data-annotations within
the Models when possible.
Web Development Technologies
Summer Semester - 2024 Page 12 of 16
g) [4 marks] Effective use of version control and Trello.
Version control has the following guidelines:
• Effective use of a GitHub repository that demonstrates your development practises.
• Regular commits have been made throughout the development period.
• Commit messages should be meaningful, the messages can be short provided they are
concise.
• Branches are used to represent each feature you are implementing; you may break a
feature into additional sub-components if desired.
• Branches should be given meaningful names.
• A minimum of 6 branches should be used in addition to the main branch.
• All branches should be merged into the main branch when completed.
• All branch commits must be checked and verified by your group members prior to
merging back into the main branch. If working in a group create and use GitHub Pull
Requests to perform the merging of a branch into the main branch.
Trello has the following guidelines:
• Document your development and thought process over time as you build features of
the software.
• The board should show the journey from the start of the project through to the end.
• Include milestones and features on the board. You may also include design, proof-ofconcept, testing and bug-fixing tasks on the board if desired.
• You are allowed to use online templates.
• The board should show sufficient details to the marker.
• Embed a minimum of 8 screenshots in your GitHub repository in a directory called
Trello. The screenshots should be taken over time, for example adding a new
screenshot every few days reflecting the project’s progress. The file name should
include the date in year-month-day format, for example 2024-0**20.png. If multiple
screenshots are taken on the same day, then include a timestamp using 24-hour format,
for example 2024-0**20-1**30.png and 2024-0**20-16-30.png.
Web Development Technologies
Summer Semester - 2024 Page 13 of 16
Part 2: BillPay, Payee and Scheduled Payments [5 marks]
h) [5 marks] Add another link to the navigation bar called BillPay. This page shows the user
their currently scheduled bills to be paid and includes a link to create a new entry. Additionally,
there should be an option to cancel a scheduled bill.
Once a bill is scheduled the payment should be automatically executed at the date and time
scheduled by the user. The processing of scheduled payments must be persistent, meaning if
the web server is stopped or restarted then the pending payments are not forgotten and are still
processed. Any payments due to be paid should be processed immediately upon the web server
starting. The bill paymentshould fail if the account has an insufficient balance. If failure occurs
the error should be conveyed to the user on the BillPay page with options to deal with the
error, for example cancel, retry, etc… how error handling is implemented, including storage
and presentation is up to your own discretion.
Postgraduate Students: Additional Task
The following is an additional task for postgraduate students only.
The scheduled payments must be implemented using a background scheduling library
such as Hangfire (https://www.hangfire.io/).
The scheduled payments implementation must be persistent. The background scheduling
library used is up to your own discretion provided it is open-source and well supported.
Web Development Technologies
Summer Semester - 2024 Page 14 of 16
Part 3: Internet Banking - Admin Web API and Admin Portal Website [6 marks]
i) [3 marks] Create an ASP.NET Core Web API exposing endpoints to perform all backend
and database operations required for the Admin Portal Website outlined below. All endpoints
of this API should be well-documented by describing them with either method comments or
readme file documentation. The API should be implemented using the Repository design
pattern.
For undergraduate students there is no requirement to include authentication or authorisation
for the Web API.
NOTE: The Admin Web API and Admin Portal Website can be contained within the same
project if desired, although the recommendation is to use separate projects for each site.
Postgraduate Students: Additional Task
The following is an additional task for postgraduate students only.
The Admin Web API must not be public and thus require an authentication token for a
client to be authorised to consume the API. The type of authentication token used and
how it is implemented is up to your own discretion.
j) [3 marks] Create an Admin Portal Website implementing the features outlined below. This
site must be independent from the Customer Website and thus must not be included within
the Customer Website project.
Admin username and password do not need to be stored within the database. After a successful
login (username = admin, password = admin) the admin should be able to:
1. Modify a customer’s profile details Name, TFN, Address, City, State, Postcode
and Mobile.
2. Lock and unlock a customer’s login. Once locked the customer should not be able
to login to the Customer Website until unlocked by an admin.
All the above features MUST use the Admin Web API to access the database. The pages
should contain minimal logic / code beyond calling the API and processing the response.
Web Development Technologies
Summer Semester - 2024 Page 15 of 16
NOTE: The following section of the assignment requires self-effort. You will need to take
initiative and research to implement the following requirements.
Part 4: Unit Testing [6 marks]
k) [6 marks] Unit test all backend endpoints / classes, structs, records / methods, controllers,
and actions. Methods and types should have various use-cases / edge-cases / error-cases
covered if they take in parameters or have context / state involved. The BillPay background
processing code for both one-off and monthly scheduled payments should also be unit tested.
The unit tests must support being executed with the dotnet test command and should adhere
to the AAA (Arrange, Act, Assert) pattern testing convention:
• The Arrange section of a unit test method initialises objects and sets the value of the
data that is passed to the method being tested.
• The Act section invokes the method being tested with the arranged state and
parameters.
• The Assert section verifies that the action of the method being tested behaves as
expected.
NOTE: Please read this online resource:
https://learn.microsoft.com/en-au/visualstudio/test/unit-test-basics?view=vs-2022
NOTE: Multiple cycles of arrange-act-assert can be present within a single unit test if desired.
The unit test naming convention is up to your own discretion.
Code should not be duplicated between tests when possible. For example, if multiple tests are
implemented as Facts that have the same code duplicated with only different test data, then
these Facts should be refactored into a Theory with input data supplied using InlineData.
All projects must be covered by unit testing. Significant coverage is required to achieve full
marks in this section.
Web Development Technologies
Summer Semester - 2024 Page 16 of 16
2.8 Coding Standards
• Read the C# coding standard from the following website:
https://learn.microsoft.com/en-au/dotnet/csharp/fundamentals/coding-style/codingconventions
• Remember that there are too many to be followed, implementing 6 to 10 of the
standards will be a job well done.
• Do not force yourself to implement every object-oriented feature that you have learnt,
use the features wisely and if needed.
2.9 Submission Procedure
Each submission must include a readme file containing your full name, student ID, URL to
your GitHub repository, document your application, and any other relevant information. If you
are working in a group, then please mention the details of all the group members. The readme
file should ideally be named Readme.md and be contained within the root of your repository.
Upload the solution / project, readme, and contribution form (if working in a group) as a single
zip file to Canvas.
NOTE: You can include the contribution form within the repository if desired.
2.10 Late Submissions and Extension-Related Information
A penalty of 10% per day of the total marks for the assignment will apply for each day a
submission is late, including both weekdays and the weekend. After 5 days, you will receive
zero marks for the assignment. Email the course lecturer matthew.bolger2@rmit.edu.au for
extension related queries.
2.11 Use of ChatGPT
Generative AI tools such as ChatGPT should be approached with caution. The AI is basically
re-packaging text that somebody else has written. (We will discuss the issue in class, both in
terms of academic standards and because the technology will be important in your careers.)
Keep it simple and only submit work which you did yourself. Please ask if you have any
questions or are not sure about anything.
For more details concerning referencing anything found via ChatGPT, kindly read:
https://rmit.libguides.com/referencing_AI_tools

如有需要，請加QQ：99515681 或WX：codehelp