Scribd
Upload
41 views

Assignment 1: Student:Puscas Vlad Group:30237

This document outlines an assignment to design a banking application with two user types - regular employees and administrators. Regular employees can view, add, and update client and account information, transfer funds between accounts, and process bills. Administrators can manage employee data and generate reports. The system will use a layered architecture pattern to separate the presentation, business, and data layers. Class and sequence diagrams along with testing will also be included.

Uploaded by

Sreedhar Reddy
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
41 views

Assignment 1: Student:Puscas Vlad Group:30237

This document outlines an assignment to design a banking application with two user types - regular employees and administrators. Regular employees can view, add, and update client and account information, transfer funds between accounts, and process bills. Administrators can manage employee data and generate reports. The system will use a layered architecture pattern to separate the presentation, business, and data layers. Class and sequence diagrams along with testing will also be included.

Uploaded by

Sreedhar Reddy
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

Assignment 1

Student:Puscas Vlad
Group:30237
Table of Contents

1. Requirements Analysis 3
1.1 Assignment Specification 3
1.2 Functional Requirements 3
1.3 Non-functional Requirements 3

2. Use-Case Model 3

3. System Architectural Design 3

4. UML Sequence Diagrams 3

5. Class Design 3

6. Data Model 3

7. System Testing 3

8. Bibliography 3

UTCN, 2021 Page 2 of 8


1. Requirements Analysis
1.1 Assignment Specification
Use JAVA/C# API to design and implement an application for the front desk employees of a
bank. The application should have two types of users (a regular user represented by the front desk
employee and an administrator user) which have to provide a username and a password in order to
use the application.
The regular user can perform the following operations:
 Add/update/view client information (name, identity card number, personal
numerical code, address, etc.).
 Create/update/delete/view client account (account information: identification
number, type, amount of money, date of creation).
 Transfer money between accounts.
 Process utilities bills.
The administrator user can perform the following operations:
 CRUD on employees’ information.
 Generate reports for a particular period containing the activities performed by an
employee.
1.2 Functional Requirements
The system should permit regular users to add new clients and update or view client
information for existing clients. Regular users also have permission to execute CRUD
statements over the client accounts. Transfer between accounts and processing of utilities bills
are also an operation permitted to the regular user. The administrator of the application is
allowed to execute CRUD statements over employees and generate reports about a specific
employee.
1.3 Non-functional Requirements
The non-functional requirements of the system include the usage of a layered architectural
pattern and ensuring all the data is being verified before being introduced in the database.
2. Use-Case Model
Use case: Transact money between two accounts.
Level: user-goal level
Primary actor: Regular employee (User)
Main success scenario:
Action System Response
1.Access the web application The login page is displayed
2. Log in The user is directed to the home page
3.Click on transaction Display the form to be completed
4.Enter the id for both accounts and the The system checks if the transaction is
amount to be transfered possible and if so it executes the transaction

Extensions: The id of either of the accounts is not a valid one or the transaction cannot be

UTCN, 2021 Page 3 of 8


perfomed.

3. System Architectural Design


3.1 Architectural Pattern Description

UTCN, 2021 Page 4 of 8


The system uses the layers architectural design pattern. It divides the application in three layers:
the presentation layer, which is used to handle the front end of the application, the business layer
which handles all the logic of the system (input handling, validations) and the data layer which
handles the connection and access to the database.

3.2 Diagrams

4. UML Sequence Diagrams

UTCN, 2021 Page 5 of 8


5. Class Design
5.1 Design Patterns Description
5.2 UML Class Diagram

UTCN, 2021 Page 6 of 8


6. Data Model
The data model used for the application was derived from the problem specification. The

UTCN, 2021 Page 7 of 8


classes created are the following: Account, Client, Employee, User, Role and Log. A client can
have multiple accounts, while an account can have only one owner (Client). An employee is
mapped using a one-to-one relationship to a user. A user can have one or two roles (User and/or
Admin).
7. System Testing
The application was tested by providing input from the web interface. Due to the fact that
mocking an Entity Manager used by Spring Data Repositories is very difficult, unit testing the
operations could not be done without interfering with the database. The connection to the
database was tested in the early phases of development.
8. Bibliography
1. Lectures M. Dansoreanu 2017 UTCN
2. Patterns of enterprise application architecture – Martin Fowler
3. Various web resources about Spring and Thymeleaf

UTCN, 2021 Page 8 of 8

You might also like