House Rental System

Software Architecture

Project Code: HRS

Document Code: HRS_AD_1.0

Ha Noi City, May 25, 2024

Internal use
 HRS - Software Architecture v.1.0

RECORD OF CHANGE

*A - Added M - Modified D - Deleted

Effective Changed Items A* Change Description New Version

Date M, D

25/5/2024 Software architecture A Create New 1.0

design document

//
HRS - Software Architecture v.1.0

SIGNATURE PAGE

ORIGINATOR: Group 1 SE1739NJ May, 25, 2024

<Position>

REVIEWERS: Nguyen Van Sang <Date>

Instructor

APPROVAL: Nguyen Van Sang <Date>

Instructor

//
HRS - Software Architecture v.1.0

TABLE OF CONTENTS

1 INTRODUCTION.......................................................................................................3

1.1 Purpose.................................................................................................................3
1.2 Scope....................................................................................................................3
1.3 Definitions, Acronyms and Abbreviations..................................................................3
1.4 References............................................................................................................3
1.5 Overview...............................................................................................................3

2 ARCHITECTURAL REPRESENTATION.......................................................................3

3 ARCHITECTURAL GOALS AND CONSTRAINTS..........................................................3

4 USE-CASE VIEW.......................................................................................................3

4.1 Use-Case Realizations.............................................................................................3

5 LOGICAL VIEW.........................................................................................................3

5.1 Overview...............................................................................................................3
5.2 Architecturally Significant Design Packages...............................................................3

6 PROCESS VIEW........................................................................................................3

7 DEPLOYMENT VIEW.................................................................................................3

8 IMPLEMENTATION VIEW.........................................................................................3

8.1 Overview...............................................................................................................3
8.2 Layers...................................................................................................................3

9 DATA VIEW (OPTIONAL)..........................................................................................3

10 SIZE AND PERFORMANCE........................................................................................3

11 QUALITY..................................................................................................................3

12 OTHER CONSIDERATIONS.......................................................................................3

//
<Project code> - Software Architecture v.xx

1 INTRODUCTION

1.1 Purpose

The main purpose of this Software Architecture Document (SAD) is to act as the House
Rental System's (HRS) official technical specification. It gives a thorough overview of the
architecture of the system, illustrating distinct features and components with a variety of
architectural views. In order to ensure that all parties involved have a common understanding,
this document attempts to document and communicate the important architectural decisions
made during the design process.

Target Audience:

Software Architects: To assess the design's viability, uphold architectural coherence,

and conform to accepted norms.

Developers: To enable effective feature implementation, they should obtain a thorough

understanding of the system's components, structure, and interconnections.

QA: Create test cases and scenarios to make sure the system works as planned and
satisfies quality requirements.

PM: keeping an eye on the status of the work, evaluating risks, and making choices
based on the architectural plan.

1.2 Scope

It encompasses the data design, user interface design, deployment architecture,

architectural patterns, and components of the system. It is devoid of project management
elements, low-level infrastructural information, and comprehensive business logic. The
technical orientation of the HRS project will be immediately impacted by this SAD, which is the
definitive source of information for all architectural decisions.

//
<Project code> - Software Architecture v.xx

1.3 Definitions, Acronyms and Abbreviations

HRS: House Rental System

UI: User Interface

UX: User Experience

API: Application Programming Interface

REST: Representational State Transfer

DB: Database

SQL: Structured Query Language

1.4 References

1. House Rental System Requirements Specification (HRS-RS-001)

1.5 Overview

1. Introduction
2. Architectural Representation
3. Architectural Goals and Constraints
4. Use-Case View
5. Logical View
6. Process View
7. Deployment View
8. Implementation View
9. Data View (optional)
10. Size and Performance
11. Quality
12. Other Considerations

//
<Project code> - Software Architecture v.xx

2 ARCHITECTURAL REPRESENTATION

The house rental system is designed using a 3-tier architecture, a widely adopted software
development model that promotes a clear separation of concerns, enhancing modularity,
maintainability, and scalability.

The 3-tier architecture consists of the following layers:

Presentation Layer (ReactJS): This layer is responsible for rendering the user interface (UI)
and interacting with the user through a web browser. ReactJS, a powerful JavaScript library, is
employed to create a dynamic, reusable, and performant UI.

Business Logic Layer (Node.js): This layer houses the core business rules and application
logic, such as input validation, search query processing, rent calculation, booking management,
and payment handling. Node.js, a JavaScript runtime environment, is utilized to build this layer,
leveraging its asynchronous processing capabilities and high performance.

Data Access Layer (MongoDB): This layer is responsible for storing, retrieving, and
managing data related to the system, including information about users, rental properties,
bookings, and transactions. MongoDB, a flexible NoSQL database, is used to store data as
JSON documents, allowing for easy scalability and adaptability to evolving business
requirements.

3 ARCHITECTURAL GOALS AND CONSTRAINTS

2.1 Architectural Goals

Usability: The user interface should be intuitive, easy to use, and user-friendly for both new
and experienced users. The system should provide features that assist users, such as tutorials,
search, filtering, and sorting of data.

Performance: The system should ensure fast page load times, quick response to user
requests, and efficient handling of tasks such as searching, filtering, and sorting data.

Security: The system should be protected against cyber attacks and ensure the security of
user data, including personal information, payment details, and other sensitive data. Security
measures such as data encryption, user authentication, access control, and mitigation of
common vulnerabilities should be implemented.

Scalability: The system should be able to scale to accommodate future growth in the number
of users, listings, and transactions. This can be achieved by using technologies and

//
<Project code> - Software Architecture v.xx

architectures that allow for horizontal scaling, such as microservices, or by leveraging cloud
services with autoscaling capabilities.

Maintainability: The system should be designed in a way that makes it easy to maintain and
upgrade in the future. This can be achieved by using clear naming conventions,
understandable code structure, comprehensive documentation, and tools that support the
software development and maintenance process.

Reusability: The components and modules of the system should be designed to be reusable
in other projects in the future.

2.2 Architectural Constraints

Technology Stack: The system will be built using ReactJS (Presentation Layer), Node.js
(Business Logic Layer), and MongoDB (Data Access Layer).

Budget: 5 person / month.

Timeline: 4 weeks.

Team Size: The development team consists of 5 people.

Regulatory Compliance: The system must comply with legal regulations regarding personal
data protection and other relevant regulations.

4 USE-CASE VIEW

//
<Project code> - Software Architecture v.xx

Primary actor Use cases

Tenant 1. Register account

2. Login to the system
3. Forget password
4. Change password of account
5. View information house
6. Search house
7. Booking house
8. View booking house
9. Cancel booking
10. Payment
11. View contract
12. Feedback
13. Update information

Landlord 1. Register account

2. Login to the system
3. Forget password
4. Change password of account
5. Create request post house
6. Edit information house
7. Delete house
8. View house
9. Create a contract
10. View contract
11. Update contract
12. View transaction history
13. Accept/Reject request booking house
14. Update information

Admin 1.Create account

2.set role

//
<Project code> - Software Architecture v.xx

3.Login to the system

4.Change pass for user

5.Accept/Reject post request

6.Post house

7.Edit house

8. Delete house

9.View house

10.Search house

11. Enable , disable account

4.1 Use-Case Realizations

1. Tenant search house

//
<Project code> - Software Architecture v.xx

2. Tenant booking house

3. Landlord accept | reject booking

//
<Project code> - Software Architecture v.xx

4. Admin accept | reject booking

//
<Project code> - Software Architecture v.xx

5 LOGICAL VIEW

5.1 Overview

//
<Project code> - Software Architecture v.xx

5.2 Architecturally Significant Design Packages

6 PROCESS VIEW

1. Process tenant booking house

//
<Project code> - Software Architecture v.xx

7 DEPLOYMENT VIEW

//
<Project code> - Software Architecture v.xx

8 IMPLEMENTATION VIEW

8.1 Overview

//
<Project code> - Software Architecture v.xx

8.2 Layers

//
<Project code> - Software Architecture v.xx

9 DATA VIEW (OPTIONAL)

10 SIZE AND PERFORMANCE

1. Size:

Expected Number of Users: The system is designed to accommodate thousands of daily

active users, comprising both tenants and landlords.

Data Volume:

Initial: Anticipated to store information for approximately 1,000 houses, 5,000 bookings, and
associated transactions. This is estimated to occupy around 1-2 GB of storage.

Within 1 Year: With projected growth, the database could expand to 10,000 houses, 20,000
bookings, and related transactions, requiring approximately 5-10 GB of storage.

Functional Complexity:

//
<Project code> - Software Architecture v.xx

Core Features: Registration/login, property search and viewing, listing creation, booking,
payment processing, contract management, reviews, and feedback.

Additional Features: Map integration, property comparison tool, advanced search filters,
messaging system between tenants and landlords.

Complexity Assessment: Core features are of moderate complexity, while additional

features may be more complex.

Frequency of Use: Users are expected to engage with the system daily for property searches,
listing management, and transactions.

2. Performance:

Response Times:

Read Requests (viewing information, search): Under 5 seconds.

Write Requests (creating listings, booking): Under 10 seconds.

Complex Requests (advanced search, comparison): Under 15 seconds.

Load Capacity: The system should be able to handle at least 500 concurrent requests without
significant performance degradation.

Scalability: The system is designed with a microservices architecture to allow for easy scaling
of individual components as needed. Technologies such as load balancing and caching will be
employed to enhance scalability.

Specific Requirements:

Page Load Speed: Homepage and search results pages should load within 5
seconds.

Transaction Processing Speed: Payment transactions should be processed within

15 seconds.

//
<Project code> - Software Architecture v.xx

11 QUALITY

The House Rental System employs a 3-tier architecture (presentation, business logic, and data access
layers) to achieve the following quality attributes:

1. Modifiability/Extensibility: The separation of concerns inherent in the 3-tier architecture

promotes modularity and maintainability. Changes or enhancements to one layer can be
made with minimal impact on other layers. For example, updating the user interface
(presentation layer) does not require modifications to the business logic or data access
layers.
2. Reliability/Availability: The data access layer provides a robust interface to the database,
ensuring data integrity and consistency. Error handling and exception management
mechanisms are implemented in each layer to gracefully handle failures and prevent system
crashes. Additionally, load balancing and redundancy can be implemented at the presentation
and business logic layers to enhance availability.
3. Performance: The 3-tier architecture allows for optimization at each layer. Caching can be
implemented at the presentation layer to reduce the need for repeated database queries.
The business logic layer can be optimized for efficient processing of requests. The data
access layer can utilize database indexing and query optimization techniques to improve
performance.
4. Security: Security measures are implemented at all layers. The presentation layer validates
user input and prevents common attacks like cross-site scripting (XSS). The business logic
layer enforces authorization rules and access controls. The data access layer protects
sensitive data using encryption and other security best practices.
5. Usability: The presentation layer is designed with a focus on user-friendliness. Intuitive
navigation, clear instructions, and responsive feedback enhance the user experience. The
separation of the presentation layer from the business logic and data access layers allows for
greater flexibility in UI design and customization.
6. Special Considerations (Privacy): The 3-tier architecture provides a clear separation
between user data and the underlying business logic. This separation helps protect user
privacy by limiting access to sensitive data to the data access layer. Strict access controls and
data encryption are implemented to safeguard user information.

12 OTHER CONSIDERATIONS

Reason for Choosing 3-Tier Architecture

During the design phase of this system, we considered various approaches and solutions.
Ultimately, the 3-tier architecture was selected due to its superior advantages over other
methods. Below is a comparison of the pros and cons of the 3-tier architecture with alternative
options:

Advantages of 3-Tier Architecture:

 Flexibility and Scalability: The 3-tier architecture allows for independent scaling of each
tier. For example, if the number of users increases significantly, you can easily scale the

//
<Project code> - Software Architecture v.xx

application tier by adding application servers without affecting the data tier or presentation
tier.

 Faster Development: Different development teams can work in parallel on separate tiers,
accelerating the application development process.

 Easier Maintenance: By separating code into distinct layers, updating or modifying each
layer becomes simpler, saving time and effort.

 Improved Security: The 3-tier architecture enhances security by isolating sensitive data
within the data tier. The presentation and application tiers only access the necessary data,
reducing the risk of direct attacks on the database.

Comparison with Other Options:

 2-Tier Architecture: While simpler, the 2-tier architecture is often less flexible and harder
to scale. Any changes to the application logic require updates to both the client and server
logic, slowing down development and maintenance.

 N-Tier Architecture: While the N-tier architecture can offer greater flexibility, it is also
more complex to design and implement. The 3-tier architecture provides a good balance
between flexibility, scalability, and simplicity.

//