Requirement & Design Specification

Learning Japanese Support System (LJSS)

Subject: SWD392

Version: 1.0

– Danang, February 2026 –

LJSS -RDS_v1.0 Page 1

Record of Changes
Version Date A* In charge Change Description
M,
D
V1.0 1/8 A Huectm3

*A - Added M - Modified D - Deleted

LJSS -RDS_v1.0 Page 2

Contents

I. Requirement Specification...........................................................................................4
I.1 Problem description.............................................................................................4
I.2 Major Features.....................................................................................................5
I.2.1 Features for customers are as follows..............................................................5
I.2.2 Features for staff are as follows.......................................................................6
I.3 System context.....................................................................................................6
I.4 Nonfunction Requirements..................................................................................8
I.5 Functional requirements.......................................................................................9
I.5.1 Use case diagrams............................................................................................9
I.5.2 Use case descriptions.....................................................................................15
I.5.3 Activity diagrams...........................................................................................22
I.6 Data Requirements.............................................................................................24
II. Analysis models.........................................................................................................30
II.1 Interaction diagrams...........................................................................................30
II.2 State diagram......................................................................................................37
III. Design specification...............................................................................................37
III.1 Integrated Communication Diagrams................................................................37
III.2 System High-Level Design................................................................................38
III.3 Component and Package Diagram.....................................................................40
III.4 Detail Design......................................................................................................41
III.5 Database Design.................................................................................................42
IV. Implementation.......................................................................................................44
IV.1 Map architecture to the structure of the project.................................................44
IV.2 Map Class Diagram and Interaction Diagram to Code......................................45
V. Applying Alternative Architecture Patterns...............................................................51
V.1 Applying the service-oriented architecture........................................................51
V.2 Applying Service Discovery Pattern in the service-oriented architecture.........53

LJSS -RDS_v1.0 Page 3

I. Requirement Specification
I.1 Problem description

Purpose: Build a web-based Japanese learning support system named Sentry, providing learners with
an online environment to study Japanese language knowledge, practice exercises, and take mock exams
following JLPT standards. The system allows students to access learning materials and track their
progress, while teachers and administrators manage learning content, quizzes, users, and system
operations. The system requirements are described as follows:

1. The system provides multiple account roles including Student, Teacher, and Admin. Users must
register and log in before accessing protected features. Authentication can be performed using
email/password or third-party login methods such as Google authentication. The system supports
account verification using OTP email confirmation.

2. Users can browse available Japanese learning courses organized by JLPT levels (N5–N1). Each
course contains multiple lessons. Users can view basic course information before enrollment and
access detailed content after enrollment.

3. Teachers are responsible for creating and managing courses. They can create new courses by
entering course information such as title, description, image, and visibility status. Teachers may
update or delete courses if information changes or is incorrect.

4. Each course includes multiple lessons. Teachers can create, edit, or remove lessons. Lessons may
contain multiple learning materials such as grammar explanations, vocabulary, kanji, videos,
downloadable files, or quizzes.

5. The system supports vocabulary, grammar, and kanji learning components. Teachers can manage
these learning elements within each lesson, including adding examples, meanings,
pronunciations, and usage instructions.

6. Students can study lessons and track learning progress. The system records completion status and
progress percentages for each lesson and course, allowing learners to monitor their learning
performance over time.

7. The system provides quiz functionality to help learners practice knowledge. Each lesson may
include quizzes with multiple questions and answers. Students can take quizzes, submit answers,
and receive automatic grading results immediately.

8. The system stores users’ quiz results and learning history. Students can review past results and
identify strengths or weaknesses based on performance analysis.

9. Users can create and manage personal flashcards for vocabulary review. Flashcards may be
linked to lessons or created independently. Users can save, organize, and review flashcards to
improve memorization.

LJSS -RDS_v1.0 Page 4

 10. The platform integrates additional learning tools such as Japanese dictionary lookup and kanji
practice features, allowing users to search meanings and view detailed kanji information.

11. Registered users can update personal profile information including avatar, Japanese proficiency
level, and personal settings. Profile images and media files may be stored using external storage
services.

12. The system supports premium subscription plans. Users can upgrade their accounts by
purchasing premium plans, allowing access to advanced features. The system records payment
history and manages premium expiration automatically.

13. Teachers can submit applications to request teacher privileges. Administrators review submitted
applications and may approve or reject requests according to system rules.

14. The system includes messaging and communication features allowing users to chat or interact
with others. Users may also block unwanted contacts to maintain privacy.

15. All administrative and teacher functions require authentication. Administrators manage user
accounts, roles, permissions, and system configurations. When necessary, administrators can ban
users or revoke access rights.

I.2 Major Features

I.2.1 Features for Students are as follows
- F01: Course Viewing: View course list by JLPT level, view suggested courses, search
courses by name, view course details.
- F02: Lesson Learning: View lesson content including grammar, vocabulary, kanji, video
materials, and downloadable resources; track learning progress.
- F03: Quiz and Exam Practice: Start quiz or mock exam, navigate questions, submit answers,
receive automatic grading, review correct and incorrect answers.
- F04: User Authentication & Profile Management: Register/Login (Email/Google), OTP
verification, view personal information, update profile, change avatar, manage account
settings.
- F05: Learning Progress Tracking: View personal learning statistics, completed lessons,
exam history, and performance results.
- F06: Flashcard Management: Create flashcards, edit flashcards, delete flashcards, review
flashcards, save public flashcards.
- F07: Dictionary & Kanji Lookup: Search vocabulary and kanji information, view readings,
meanings, and examples.
- F08: Feedback & Rating: Submit course feedback, rate courses, view feedback history.
- F09: Messaging & Communication: Participate in chat conversations, send messages, view
conversation history, block users.

LJSS -RDS_v1.0 Page 5

 - F10: Premium Membership: View premium plans, purchase premium package, view payment
history, access premium features.

I.2.2 Features for Teachers are as follows

- F11: Teacher Dashboard: View personal statistics including created courses, lessons, and
quizzes.
- F12: Course Management: Add course, edit course, delete course, upload course image,
hide/unhide course, manage suggested courses.
- F13: Lesson Management: Add lesson, edit lesson, delete lesson, upload lesson materials
(video/file/audio).
- F14: Learning Content Management: Manage vocabulary, grammar, and kanji content
associated with lessons.
- F15: Quiz Management: Create quiz, edit quiz, delete quiz, add questions and answers,
import quiz from Excel file.
- F16: Student Performance Monitoring: View students’ quiz results and learning statistics.

I.2.3 Features for Administrators are as follows

- F17: User Management: View user list, assign roles, ban/unban users, manage user permissions.
- F18: Teacher Application Management: View teacher applications, approve/reject
applications, manage certification review.
- F19: System Content Management: Manage courses and lessons globally, override teacher
actions when necessary.
- F20: Payment & Premium Management: Manage premium plans, monitor payments,
track subscription expiration.
- F21: Feedback Management: View feedback list, review reports, moderate inappropriate
content.
- F22: System Monitoring & Statistics: View overall system statistics including user
activity, course enrollments, and learning progress.

LJSS -RDS_v1.0 Page 6

 I.3 System context

Figure I-1 System context is modeled by a class diagram

Figure I-1 illustrates the system context of the Sentry Japanese Learning Support System,
showing the interactions between the system and its surrounding entities including external users
and external systems.
External Users
1. Student: The primary end-user of the system who can browse courses, study lessons,
take quizzes, view learning progress, manage personal flashcards, and submit feedback.
2. Teacher: Responsible for creating and managing courses, lessons, quizzes, and learning
materials such as vocabulary, grammar, and kanji. Teachers can also monitor student
learning performance.
3. Administrator: Manages the entire system including user management, role assignment,
teacher application approval, content moderation, and system configuration.

LJSS -RDS_v1.0 Page 7

 External Systems

1. Google Authentication Service: Provides authentication and login functionality using

users’ Google accounts.
2. Mailing System: Sends OTP verification emails, account notifications, password reset
emails, and system announcements.
3. File Storage Service (AWS S3 / Local Storage): Stores uploaded files such as course
images, lesson materials, avatars, audio files, and other learning resources.
4. Payment System: Handles premium subscription payments and manages payment
transaction information.
I.4 Nonfunction Requirements

NF-01 Maintainability: The system should be designed to support efficient maintenance, scalability,
and future feature expansion.
All modules must follow a clear layered architecture with proper separation of concerns. Components
and modules should have clear traceability through documentation describing dependencies,
relationships, and interactions.

 Modular and well-structured codebase.

 Clear mapping between requirements, UML models, and implementation.
 Well-documented APIs and system components.
 Easy modification and extension for future learning features.

NF-02 Usability: The website must provide an intuitive and user-friendly learning experience for
students, teachers, and administrators.

 Learning task completion time (access a lesson and start a quiz within 3 minutes).
 Error rate (less than 5% for main learning activities).
 User satisfaction rate (at least 85% based on feedback evaluation).
 Clear navigation structure suitable for both beginner and advanced learners.

NF-03 Portability: The system must be accessible across multiple platforms, browsers, and device
sizes.

 Browser compatibility (latest versions of Chrome, Firefox, Safari, and Edge).

 Device compatibility (desktop, tablet, and mobile devices).
 Responsive interface supporting screen widths from 320px to 1920px.
 Cross-platform access regardless of operating system.

LJSS -RDS_v1.0 Page 8

NF-04 Performance: The system should ensure smooth learning and testing experiences, especially
during quizzes and exams.

 Page load time less than 2 seconds for most users.

 API response time ideally below 300ms for quiz navigation.
 Support simultaneous users during peak exam periods.
 Stable performance under concurrent access without significant degradation.

NF-05 Security: The system must ensure secure authentication, data protection, and safe learning
interactions.

 Password encryption using secure hashing algorithms (e.g., BCrypt).

 Token-based authentication (JWT).
 Role-based access control (Student, Teacher, Admin).
 Protection against unauthorized access and data modification.

NF-06 Scalability: The backend architecture should be designed as stateless services to allow horizontal
scaling when user traffic increases.

 Session handling via token-based authentication.

 Ability to add server instances without affecting system functionality.
 Support increased user load during JLPT examination seasons.

I.5 Functional requirements

I.5.1 Use case diagrams
Based on described user requirements in Section 1.1 and detailed analysis, the system has
been deployed on a web platform, consisting of two primary sites: the Customer Site and the
Administration Site. Figure 1-2 presents the Overview Use Case Diagram for the Customer Site,
highlighting key functionalities such as viewing product information, reading news, managing
cart, managing profile, and Checkout. Figures 1-3 showcase the Overview Use Case Diagram for
the Administration Site, covering essential tasks like managing product categories, managing
products, processing orders, managing import bills, managing news, managing users, reporting
statistics, managing discounts, and managing suppliers. Figures 1-4 to 1-11 show some Detailed
Use Case Diagrams, which further break down the specific use cases for both the Customer Site
and the Administration Site.
Tables 1-1 to 1-6 show descriptions of use cases Manage Products, Add product, Edit
product, Delete product, Disable news, Enable news. These descriptions will be inputs to
LJSS -RDS_v1.0 Page 9
building analysis models in Section 2.

LJSS -RDS_v1.0 Page 10

THÊM HÌNH USECASE CỦA WEB VÔ THEO FIG I-2

Figure I-2 — Overview Use Case Diagram of Learning Site

Figure I-3 — Overview Use Case Diagram of Admin Site

LJSS -RDS_v1.0 Page 11

 Figure I-4 — Detailed Use Case Diagram for Managing Flashcards

Figure I-5 — Detailed Use Case Diagram for Managing Profile

LJSS -RDS_v1.0 Page 12

 Figure I-6 — Detailed Use Case Diagram for Learning History

Figure I-7 — Detailed Use Case Diagram for View Courses & Lessons

LJSS -RDS_v1.0 Page 13

 Figure I-8 — Detailed Use Case Diagram for Manage Courses & Lessons

LJSS -RDS_v1.0 Page 14

 Figure I-9 — Detailed Use Case Diagram for Manage Quizzes

LJSS -RDS_v1.0 Page 15

 Figure I-10 — Detailed Use Case Diagram for Teacher Application

LJSS -RDS_v1.0 Page 16

 Figure I-11 — Detailed Use Case Diagram for Premium Payment
I.5.2 Use case descriptions

Tables 1-1 to 1-6 describe the use cases: Manage Courses, Add Course, Edit Course, Delete Course,
Manage Lessons, and Manage Quizzes. The event flows of these use cases can be modeled using
activity diagrams. For example, Figures 1-12 and 1-13 are activity diagrams modeling the event flows of
the Manage Courses and Add Course use cases. These use case descriptions will be used as inputs for
building analysis models in Section II.

LJSS -RDS_v1.0 Page 17

 Table 1-1 — Use case description for Manage Courses

ID and Name: UC-01 Manage Courses

Created By: Tran Thao Nguyen Date Created: 26/02/2026
Primary Actor: Teacher Secondary
Actors:
Description: This use case allows teachers to manage courses in the system,
including adding, editing, deleting, and searching courses.
Trigger: Teacher selects the Manage Course option from the dashboard.

Preconditions:
PRE-1. Teacher is logged in.
PRE-2. Teacher has course management permission.
Postconditions: POST-1. Course list is updated correctly in the system.

Normal Flow: 1. Teacher selects Manage Course.

2. System retrieves course list from database.
3. System displays course management interface.
4. Teacher views course list.
5. Teacher can select actions: Add Course / Edit Course / Delete Course
/ Search Course.

Alternative AF-1 (Add Course): Teacher fills in course form (title, description,
Flows: image, visibility, suggested). System validates and saves course, then
redirects to lesson builder.
AF-2 (Edit Course): Teacher modifies course information (title,
description, image). System updates course record.
AF-3 (Delete Course): Teacher deletes course. System removes all
related data (progress, enrollments, user answers, quizzes, lessons) and
course image from storage.
AF-4 (Search Course): Teacher enters keyword. System searches by
title (case-insensitive) and returns matching courses via AJAX.
Exceptions: E1. System fails to load course list.
E2. Course not found when editing/deleting.
E3. Validation fails (blank title, description > 2000 chars).
E4. Image upload to storage fails.
Priority: High

LJSS -RDS_v1.0 Page 18

Business Rules: Only the course creator (Teacher) can edit/delete their own courses. Title
is required (max 255 chars). Default image is set if none provided.
Courses can be marked as Hidden or Suggested.

Table 1-2 — Use case description for Add Course

ID and Name: UC-02 Add Course

Created By: Tran Thao Nguyen Date Created: 26/02/2026
Primary Actor: Teacher Secondary
Actors:
Description: This use case allows teachers to create a new course.

Trigger: Teacher selects Add Course from Manage Course screen.

Preconditions:
PRE-1. Teacher logged in.

Postconditions:
POST-1. New course is saved in the database.
POST-2. System redirects to lesson builder for the new course.

Normal Flow:

1. Teacher selects "Add Course".

2. System displays course creation form (title, description, image,
isHidden, isSuggested).
3. Teacher fills in course information and uploads thumbnail image.

4. Teacher submits the form.

5. System validates input (title required, max 255 chars; description
max 2000 chars).
6. System uploads image to storage and saves course.
7. System redirects Teacher to lesson builder page.

LJSS -RDS_v1.0 Page 19

 Alternative 1. AF-1: Teacher does not upload image → system sets default image.
Flows:

Exceptions: E1. Validation fails (blank title,

description too long).
E2. Image upload to storage fails.

Priority: High
Business Rules: Title is required (max 255 chars). Default image is set if none provided.
Course is assigned to the creating Teacher.

Table 1-3 — Use case description for Edit Course

ID and Name: UC-03 Edit Course

Created By: Tran Thao Nguyen Date Created: 26/02/2026
Primary Actor: Teacher Secondary
Actors:
Description: This use case allows teachers to edit an existing course's information
including title, description, image, and visibility settings.
Trigger: Teacher selects "Edit" on an existing course.

Preconditions:
PRE-1. Teacher is logged in.

PRE-2. Teacher is the owner of the course.

Postconditions: POST-1. Course information is updated in the database.

LJSS -RDS_v1.0 Page 20

 Normal Flow:
1. Teacher selects "Edit" on a course.
2. System loads course data and displays edit form.
3. Teacher modifies course information (title, description,
image, visibility, suggested).
4. Teacher submits the form.
5. System validates input and updates course record.
6. If new image is uploaded, system deletes old image and
uploads new one.

Alternative 1. AF-1: Teacher does not change image → system keeps

Flows: existing image.

Exceptions: 1. E1. Course not found.

2. E2. Validation fails.
3. E3. Image upload fails.

Priority: High
Business Rules: Only the course creator can edit the course. Old image is deleted from
storage when replaced.

Table 1-4 — Use case description for Delete Course

ID and Name: UC-04 Delete Course

Created By: Tran Thao Nguyen Date Created: 26/02/2026
Primary Actor: Teacher Secondary
Actors:
Description: This use case allows teachers to delete a course and all its related data
from the system.
Trigger: Teacher selects "Delete" on an existing course.

LJSS -RDS_v1.0 Page 21

 Preconditions:
PRE-1. Teacher is logged in.

PRE-2. Teacher is the owner of the course.

Postconditions:
POST-1. Course is removed from system.

Normal Flow: 1. Teacher selects course to delete.

2. System asks for confirmation.
3. Teacher confirms deletion.
4. System deletes course.
5. System shows success message.

Alternative
Flows: 1. A1. Teacher cancels deletion.

Exceptions: 1. E1. Course contains lessons → cannot delete.

Priority: High
Business Rules: Course with active lessons cannot be deleted directly.

Table 1-5 — Use case description for Manage Courses

ID and Name: UC-05 — Search Course

Created By: Tran Thao Nguyen Date Created: 26/02/2026
Primary Actor: Teacher Secondary
Actors:
Description: Teacher searches courses by keyword.

Trigger: Enter search keyword.

Preconditions:
PRE-1. Manage Course screen opened.

LJSS -RDS_v1.0 Page 22

Postconditions: POST-1. Filtered course list displayed.

Normal Flow: 1. Enter keyword.

2. System searches DB.
3. Display results.

Alternative Empty keyword → show all courses.

Flows:
Exceptions: No result found.
Priority: Medium
Business Rules:

Table 1-6 — Use case description for Manage Lessons

ID and Name: UC-06 Manage Lessons

Created By: Tran Thao Nguyen Date Created: 26/02/2026
Primary Actor: Teacher Secondary
Actors:
Description: This use case allows teachers to manage lessons inside a course.

Trigger: Teacher selects Manage Lessons of a course.

Preconditions: PRE-1. Course exists.

LJSS -RDS_v1.0 Page 23

Postconditions: POST-1. The selected news article is deactivated and no longer visible
on the customer site.
POST-2. The system logs the action, recording which user disabled the
news and when it was done.
Normal Flow:
1. Teacher opens lesson management.
2. System loads lesson list.
3. Teacher performs Add/Edit/Delete lesson actions.

Alternative 1. A1. Teacher exits lesson management.

Flows:

Exceptions: E1. Lesson data invalid.

Priority: High
Business Rules: Lesson must belong to a course.

Table 1-6 — Use case description for Manage Quizzes

ID and Name: UC-06 Manage Quizzes

Created By: Tran Thao Nguyen Date Created: 26/02/2026
Primary Actor: Teacher Secondary
Actors:
Description: This use case allows teachers to manage quizzes in the system,
including creating, editing, importing from Excel, deleting, and
viewing quizzes.
Trigger: Teacher selects the Manage Quiz option from the lesson management
interface.

Preconditions: PRE-1. Teacher is logged in.

PRE-2. Teacher has course management permission.

LJSS -RDS_v1.0 Page 24

Postconditions: POST-1. Quiz data is updated correctly in the system.

Normal Flow: 1. Teacher selects Manage Quiz from a lesson.

2. System retrieves quiz list from database.
3. System displays quiz management interface.
4. Teacher views quiz details (questions, answers).
5. Teacher can select actions: Create Quiz / Edit Quiz / Import from
Excel / Delete Quiz.

Alternative 1. AF-1 (Create): Teacher fills in quiz form (title, questions, answers
Flows: with correct marks) and submits. System validates and saves.

2. AF-2 (Edit): Teacher modifies existing quiz content. System

performs smart update (sync questions).
3. AF-3 (Import Excel): Teacher uploads Excel file (.xlsx). System
parses and creates/updates quiz.
4. AF-4 (Delete): Admin deletes quiz. System removes all related data
(answers, questions, user answers).
5. AF-5 (Submit Quiz): Student takes quiz and submits answers.
System calculates score (pass ≥ 70%).
6. AF-6 (View Result): User views quiz result. Students can only
view their own results.
Exceptions: E1. System fails to load quiz data.
E2. Lesson already has a quiz (each lesson allows only 1 quiz).
E3. Question has no correct answer.
E4. Quiz not found.
E5. Excel file parsing fails.
E6. Teacher attempts to delete quiz (only Admin allowed).
Priority: High
Business Rules: Only Teachers/Admins can create/edit quizzes. Only Admin can delete
quizzes. Each lesson can have only 1 quiz. Each question must have at
least 1 correct answer.

Table 1-7 — Use case description for Manage Courses

ID and Name: UC-01 Manage Courses

Created By: Tran Thao Nguyen Date Created: 26/02/2026

LJSS -RDS_v1.0 Page 25

 Primary Actor: Teacher Secondary
Actors:
Description: This use case allows teachers to manage courses in the system,
including adding, editing, deleting, and searching courses.
Trigger: Teacher selects the Manage Course option from the dashboard.

Preconditions:
PRE-1. Teacher is logged in.
PRE-2. Teacher has course management permission.
Postconditions: POST-1. Course list is updated correctly in the system.

Normal Flow: 1. Teacher selects Manage Course.

2. System retrieves course list from database.
3. System displays course management interface.
4. Teacher views course list.
5. Teacher can select actions: Add Course / Edit Course / Delete Course
/ Search Course.

Alternative
Flows:
Exceptions: E1. System fails to load course list.
Priority: High
Business Rules: Only teachers can modify courses.

I.5.3 Activity diagrams

Figures 1-12 and 1-13 are activity diagrams modeling event flows of the use case Manage
products and Add product.

LJSS -RDS_v1.0 Page 26

 Figure I-12 Activity diagram modeling event flows of use case Manage product

LJSS -RDS_v1.0 Page 27

 Figure I-13 Activity diagram modeling event flows of use case Add product

I.6 Data Requirements

Figure I-14 Entity class diagram modeling data requirements

LJSS -RDS_v1.0 Page 28

 The class diagram in Figure 1.14 specifies the entity classes and the relationships
between them, clearly representing the system's data requirements. Each entity class in the
diagram represents a domain concept, relationships between entities are associations,
aggregations, composition, or inheritances. To provide detailed information about these entity
classes, they are all thoroughly described in Table 1-7, which is known as the data dictionary.
This data dictionary serves as an explanatory tool, offering detailed descriptions of each class’s
attributes, data types, and relationships, helping the reader better understand the data structure
and system requirements.

Table I-7 Data Description (Data dictionary)

Name Data Length Description

Type
Category Product category
CatId String 20 Product Category Identifier
CatName String 50 Product Category Name
Description String 500 Description of product category
Product
ProId String 20 Product Identify
ProName String 50 Product Name
Measure String 50 The unit of measurement used to quantify the product.
Description String Max Description of product
Image String 50 The visual representation of the product. It stores
information about an image file that shows what the
product looks like.
Supplier
SupId String 20 Supplier identifier
Name String 50 Supplier Name
Address String 500 Supplier Address
Phone String 15 The contact telephone number for the supplier
Customer
CusId String 20 Customer Identifier

LJSS -RDS_v1.0 Page 29

CusName String 50 Customer Name

LJSS -RDS_v1.0 Page 30

Phone String 15 The contact telephone number for the customer
Email String 50 The email address of the customer
Address String 500 The physical address of the customer
Discount
DisId string 20 Discount Identifier
DisName String 250 The name or description of a discount applied to orders or
products.
DisAmount Float The monetary value or percentage of the discount applied
to an order or product
IsPercentage Boolean It indicates whether the discount amount is represented
as a percentage or a fixed monetary value
StartDate DateTime The date and time when a particular record or action
becomes effective
EndDate DateTime The date and time when a particular record or action
expires or is no longer effective
IsActive Boolean It indicates whether a particular discount is currently
active and can be applied or not.
ShippingAddress
AddId String 20 Shipping address Identifier
CuId String 20 Customer Identifier
Province String 50 It is a part of the address and represents a specific
administrative division within a country, such as a city,
province, or region
District String 50 It is a part of the address and represents a specific
administrative division within provinces and cities
Commune String 50 It is an address represents a smaller administrative
division within a district
AddressLine String 100 It typically includes street names, building numbers,
apartment or suite numbers, and other address details.
Order

OrdId String 20 Order Identifier

LJSS -RDS_v1.0 Page 31

CusId String 50 Customer Identifier
ShippingAddress String 255 Shipping address
OrDate String 20 The date and time when the order was placed or created
Status String 50 The current state or progress of the order through its
lifecycle.
Note String 50 The note provided by the customer when placing an order
TotalAmount Int The total cost of the order, including all items, taxes,
discounts, and any other charges that may apply
PaymentMethod String 30 The method or mode used by the customer to pay for the
order
ShippingCost Int The total cost associated with shipping and delivering the
order to the customer.
PaymentStatus String 20 The current state of the payment for the order
OrderProduct The OrderProduct entity is created from the many-to-
many relationship between Order and Product.
ProId String 20 Product identifier
Quantity Int Quantity of products that customers order
Price int Price of a product within each order
Discount Float discount of a product within each order
ImportBill Import Bill
ImpId String 20 Import bill Identifier
ImpDate String 20 The date when the import of products into the store
occurs
SupId String 20 Supplier Identifier
StaffId String 20 Identifier of the staff who processed or handled the
import bill.
TotalAmount int The total monetary value of the import transaction
ImportBillProduct The OrderProduct entity is created from the many-to-
many relationship between ImportBill and Product.
ProId String 20 Product Identifier

LJSS -RDS_v1.0 Page 32

ImBId String 20 Import Bill Identifier

LJSS -RDS_v1.0 Page 33

ImportPrice int The price of each product when the store imports it
SellingPrice int The price at which the store intends to sell each product
after it has been imported.
Quantity Int The quantity of each product when the store imports it
RemainingQuanti int The number of units of a specific product that are still
ty available in the store's inventory from a particular import
batch
ExpirationDate String 50 The date after which a specific product is no longer
considered safe or suitable for sale or consumption
Staff It represents employees within the store, who can play
different roles such as sales staff, warehouse staff, and
store owner.
StaId String 20 Staff identifier
StaName String 50 Staff Name
Role String 20 Role of staff in the system
Phone String 15 Phone number of staff
HireDate DateTime The date when an employee is officially hired or begins
working at the organization.
User Users of the system
Uid String 20 User identifier
ExternalUserID String 50 Unique identifier for users from an external system or
service that is integrated with your system. This could be
used to track users who log in through third-party
authentication services like Google, Facebook, or other
external identity providers.
ExternalProvider String The name of the external authentication service or
provider that is used to authenticate or identify the user.
Password String 50 The password of the user if they have
UserType String 50 It categorizes users based on their roles or access levels
within the system.

LJSS -RDS_v1.0 Page 34

 News It typically represents articles that are communicated to
customers.
NewId String 20 New identifier
Title String 255 Title of news
Content String max Content of news
CreateDate String 20 Time creates the news
StaffId String 20 Staff identifier of who writes news
Log Log is an entity used to record events, actions, or changes
within a system
TimeStamp DateTime The date and time when the log entry was created.
StaId String 20 The identifier of the user who performed the action
EntityID String 20 The identifier of the entity related to the action (e.g.,
order ID, product ID). This attribute specifies which
particular instance of an entity was involved.
EntityType String 50 The type of entity associated with the action (e.g., order,
product). It indicates what kind of data was affected.
Action String 20 The type of action or event recorded (e.g., create, update,
delete). It describes the nature of the activity.
Description String 255 A detailed description of the event or action
Cart
CarId String 20 A unique identifier for each cart
CreateDate DateTime The date and time when the cart was created
Status String The status of the cart (e.g., "active," "abandoned,"
"completed")
CartIterm It represents an individual item within a customer's
shopping cart. It captures details about each product the
customer intends to purchase
ProId String A unique identifier for each product in the cart.
Quantity Int The number of units of the product added to the cart.

DateAdded Date The date and time when the item was added to the cart

LJSS -RDS_v1.0 Page 35

 Price int The price per unit of the product at the time it was added
to the cart

II. Analysis models

II.1 Interaction diagrams
In this section, we will analyze objects and their interactions to realize use cases based
on the MVC model's analysis pattern. Specifically, we will examine the following use cases:
Manage Products, Add Product, Edit Product, Delete Product, Disable News, and Enable News.
The interaction diagrams, illustrated in Figures 2-1 through 2-12 include sequence diagrams and
communication diagrams that model the interactions (messages) of objects to realize these use
cases.

Figure II-1 Sequence Diagram for Manage Products Use Case

LJSS -RDS_v1.0 Page 36

 Figure II-2 Sequence Diagram for Add Product Use Case

Figure II-3 Sequence Diagram for Edit Product Use Case

LJSS -RDS_v1.0 Page 37

 Figure II-4 Sequence Diagram for Delete Product Use Case

LJSS -RDS_v1.0 Page 38

 Figure II-5 Sequence Diagram for Disable News Use Case

Figure II-6 Sequence Diagram for Enable News Use Case

LJSS -RDS_v1.0 Page 39

 Figure II-7 Communication Diagram for Manage Products Use Case

Figure II-8 Communication Diagram for Add Product Use Case

LJSS -RDS_v1.0 Page 40

 Figure II-9 Communication Diagram for Edit Product Use Case

Figure II-10 Communication Diagram for Delete Product Use Case

LJSS -RDS_v1.0 Page 41

 Figure II-11 Communication Diagram for Disable News Use Case

Figure II-12 Communication Diagram for EnableNews Use Case

LJSS -RDS_v1.0 Page 42

II.2 State diagram
In object-oriented analysis and design, a finite state machine can model the states and
state transitions of a system or an object. Figure 2-13 illustrates a state diagram depicting the
states and state transitions of a News object. The events DisableNews and EnableNews cause
state transitions to share the same names as two messages arriving at the state-dependence object
in the sequence diagrams (Figures 2-5, 2-6) or the communication diagrams (Figures 2-11, 2-12).

Figure II-13 State diagram model states of a News object

III. Design specification

III.1 Integrated Communication Diagrams
To transition from analysis to design and to identify the subsystems, it is necessary to
synthesize an initial software design based on the analysis conducted so far. This involves
integrating the use case based interaction diagrams developed as part of the dynamic model [1].
The integrated collaboration diagrams will then incorporate all interactions within the
system. For large and complex systems, this integration may be performed for each subsystem
individually. In this example, we will integrate the collaboration diagrams for the four use cases
we have developed: Manage Products, Add Product, Edit Product, and Delete Product.
As an alternative to integrating interactive diagrams, design often involves incorporating
class diagrams. This integration helps identify all the necessary classes and methods required to
implement use cases. For example, Figure 3-7 shows a design-level class diagram that integrates
the use cases: Manage Products, Add Product, Edit Product, and Delete Product.

LJSS -RDS_v1.0 Page 43

 Figure III-1 Integrated communication diagram of Manage products, Add product, Edit
product, Delete product.

III.2 System High-Level Design

The software architecture separates the overall structure of the system. The design of the
software architecture can be depicted from different perspectives, referred to as different views.
The static view of the software architecture is depicted on class diagrams. The dynamic view of
the software architecture is depicted on communication diagrams. The deployment view of the
software architecture is depicted deployment diagram. Another view of software architecture is
the Component-Based view [1].
Based on the functional and non-functional requirements, the FSO system is designed
using a Multiple Client/Single Service architecture. In this design, the FSO system is divided into
two subsystems: one subsystem for customers and another subsystem for store staff. The
software high- level architecture of FSO is depicted by different views as in Figures 3-2, 3-3, and
3-4.
Note: To meet the non-functional requirements NF-02 and NF-03, we need to design the
interface to ensure ease of use, enable the website to run on multiple browsers, and support
Responsive capabilities. Additionally, to meet the non-functional requirements NF-01 regarding

LJSS -RDS_v1.0 Page 44

maintainability and NF-04 regarding performance, we need to design the architecture to fulfill
these characteristics.

Figure III-2 Deployment diagram for the FSO system architecture

Figure III-3 Class diagram for the FSO system architecture

LJSS -RDS_v1.0 Page 45

 Figure III-4 Component diagram for the FSO system architecture

III.3 Component and Package Diagram

After designing the system into subsystems, the organization of classes within the
subsystems into packages and components can also be determined. This organization is modeled
in the corresponding package and component diagrams in UML. Figure 3-5 is the package
diagram of the FSO system. This diagram shows packages and the relationships between
packages. Figure 3-6 is a component diagram of the FSO system. This diagram shows
components and the relationships between components.

Figure III-5 Package diagram for the FSO system

LJSS -RDS_v1.0 Page 46

 Figure III-6 Component diagram for the FSO system

III.4 Detail Design

After high-level architectural design, the classes in the analysis model are mapped to
design classes. The operations of a class can be determined from either the static model and the
dynamic model. Information hiding classes are categorized by stereotype: entity classes,
boundary classes, control classes, and application logic classes. In design modeling, each entity
class is usually split into two separate classes. The first is a database wrapper class, which hides
how data is accessed, especially when using a relational database. The second is a data
abstraction class, which encapsulates the data structures [1].
Figure 3-7 shows the detailed design classes for the use cases: Manage Products, Add
Product, Edit Product, and Delete Product. These classes are identified based on the architecture
of the FSO system, as designed in Section 3.2. The operations of these classes are defined based
on the messages in the sequence diagrams for these use cases, as shown in Figures 2-1 through 2-
4.

LJSS -RDS_v1.0 Page 47

 Figure III-7 Detailed Design Classes for Use Cases: Manage Products, Add Product,
Edit Product, Delete Product

III.5 Database Design

The data contained in the entity classes of the static model are mapped to a database (in
this system, we will design a relational database). The entity class diagram of the FSO system,
shown in Figure 1-4, which models the data requirements, will be mapped to a relational
database design for the system.
Supplier(SupId: nvarchar(20), Name: nvarchar(50), Address: nvarrchar(500), Phone: nvarchar
(15))
Customer(CusId: nvarchar(20), CusName:nvarchar(50), PhoneNumber: nvarchar(15),
Email:nvarchar(50), Address: nvarchar(500))
Staff(StaId: nvarchar(20), StaName: nvarchar(50), Role: nvarchar(20), Phone: nvarchar(15),
HireDate: DateTime)
Discount(DisId: nvarchar(20), DisName: nvarchar(250), DisAmount: float, IsPercentage,
StartDate: DateTime, EndDate: DateTime, IsActive: bit)
Staff(StaId: nvarchar(20), StaName: nvarchar(50), Role: nvarchar(20), Phone: nvarchar(15),
HireDate: DateTime)

LJSS -RDS_v1.0 Page 48

User(Uid: nvarchar(20), StaId:nvarchar(20), CusId: nvarchar(20),
ExternalUserID:nvarchar(50), ExternalProvider:nvarchar(50), Password:nvarchar(50),
UserType: nvarchar(50))
News(NewId: nvarchar(20), StaffId: nvarchar(20), Title: nvarchar(255), Content: LongTex,
CreateDate: DateTime)
Log(LogId: nvarchar(20), TimeStamp: DateTime, StaId: nvarchar(20), EntityID: nvarchar(20),
EntityType: nvarchar(50), Action: nvarchar(20), Description: nvarchar(255))
Category(CatId: nvarchar(20), CatName: nvarchar(50),Description: nvarchar(500))
Product(ProId: nvarchar(20), CatId: nvarchar(20), ProName: nvarchar(50), Measure:
nvarchar(50), Description: nvarchar(500), Image: nvarchar(255))
Cart(CusId: nvarchar(20), CreateDate: DateTime, Status: nvarchar(20))
ShippingAdress(AddId: nvarchar(20), CuId: nvarchar(20), Province: nvarchar(50), District:
nvarchar(50), Commune: nvarchar(50), AddressLine: nvarchar(100))
Order(OrdId: nvarchar(20), CusId: nvarchar(20), StaId: nvarchar(20), ShippingAddress:
nvarchar(255), OrDate, Status, Note, TotalAmount, PaymentMethod, ShippingCost,
PaymentStatus)
ImportBill(ImpId: nvarchar(20), SupId: nvarchar(20), StaffId: nvarchar(20), ImpDate:
DateTime, TotalAmount: int)
CartIterm(CaIId: nvarchar(20), CusId: nvarchar(20), ProId: nvarchar(20), Quantity: int,
DateAdded: DateTime, Price: int)
ImportBillProduct(ProId: nvarchar(20), ImBId: nvarchar(20), ImportPrice: int, SellingPrice:int,
Quantity: int, RemainingQuantity: int, ManufactureDate: DateTime, ExpirationDate: DateTime)
OrderProduct(OrdId: nvarchar(20), ProId: nvarchar(20), Quantity: int, Price: int, Discount:Float)

LJSS -RDS_v1.0 Page 49

IV. Implementation
IV.1 Map architecture to the structure of the project
In the system architecture outlined in Section 3.2, the FSO (FreshFood Online) system is
designed using a Multi-client/one-server model. It is divided into two subsystems: FSOAdmin
and FSOCustomer, deployed in a web environment. To manage data operations effectively, these
tasks are separated into a distinct component. As illustrated in Figure 3-6 (Component Diagram),
the system consists of three main components: FSOAdmin (Executable - Web app),
FSOCustomer (Executable - Web app), and FSOData (Library). These components are further
organized into packages, as shown in Figure 3-5. Each package groups classes with similar roles
and functionalities.

Figure IV-1 the structure of the project

LJSS -RDS_v1.0 Page 50

IV.2 Map Class Diagram and Interaction Diagram to Code
For example, two classes (ProductService, ProductController) in the detailed design classes in
Figure 3-7 are mapped into code c# as follows:

using [Link];
namespace [Link]
{
public interface IProductService
{
Task<IEnumerable<Product>> GetProducts ();
Task AddProduct (Product product);
Task EditProduct(Product product);
Task DeleteProduct(string proId);
}
}

using [Link];
namespace [Link]
{
public class ProductService : IProductService
{
private readonly DataContext _context;

public ProductService(DataContext context)

{
_context = context;
}

// Method to get all products

LJSS -RDS_v1.0 Page 51

 public async Task<IEnumerable<Product>> GetProducts ()
{
return await _context.[Link]();
}

// Method to add a new product

public async Task AddProduct (Product product)
{
_context.[Link](product);
await _context.SaveChangesAsync();
}

// Method to update an existing product

public async Task EditProductAsync(Product product)
{
_context.[Link](product);
await _context.SaveChangesAsync();
}
// Method to delete a product by ID
public async Task<bool> DeleteProduct (string proId)
{
// Check if the product exists in any related tables (e.g., OrderProduct, ImportBillProduct)
bool isReferenced = await _context.[Link](op => [Link] == proId) ||
await _context.[Link](ibp => [Link] == proId);
if (isReferenced) return false;
var product = await _context.[Link](proId);
if (product != null)
{
_context.[Link](product);

LJSS -RDS_v1.0 Page 52

 await _context.SaveChangesAsync();
return true; // Deletion successful
}
return false; // Product not found
}
}
}

using [Link];
using [Link];
namespace [Link]
{
public class ProductController: Controller
{
private readonly IProductService _productService;
private readonly ICategoryService _categoryService;

// Constructor
public ProductController(IProductService productService)
{
_productService = productService;
}

// GET: Product/Manage
public async Task<IActionResult> Manage()
{
var products = await _productService.GetProducts();
return View(products);
}

LJSS -RDS_v1.0 Page 53

// GET: Product/GetProduct/{id}
public async Task<IActionResult> GetProduct(string id)
{
var product = await _productService.GetProduct(id);
if (product == null)
{
return NotFound();
}
return PartialView("_ProductDetails", product);
}

// GET: Product/GetCategories
public async Task<IActionResult> GetCategories()
{
var categories = await _ [Link]();
return Json(categories);
}

// GET: Product/Add
public IActionResult
Add()
{
return PartialView("_AddProductModal");
}

// POST: Product/Add
[HttpPost]
[ValidateAntiForgeryToken]

LJSS -RDS_v1.0 Page 54

public async Task<IActionResult> Add(Product product)

LJSS -RDS_v1.0 Page 55

{
if ([Link])
{
bool isVerified = _productService.VerifyProductInfor(product);
if (!isVerified)
{
[Link]("", "Product information is not valid.");
return PartialView("_AddProductModal", product);
}

await _productService.AddProduct(product);
return RedirectToAction("Manage");
}

return PartialView("_AddProductModal", product);

}

// GET: Product/Edit/{id}
public async Task<IActionResult> Edit(string id)
{
var product = await _productService.GetProduct(id);
if (product == null)
{
return NotFound();
}

return PartialView("_EditProductModal", product);

}

LJSS -RDS_v1.0 Page 56

// POST: Product/Edit
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Edit(Product product)
{
if ([Link])
{
bool isVerified = _productService.VerifyProductInfor(product);
if (!isVerified)
{
[Link]("", "Product information is not valid.");
return PartialView("_EditProductModal", product);
}

await _productService.EditProduct(product);
return RedirectToAction("Manage");
}

return PartialView("_EditProductModal", product);

}

// POST: Product/Delete/{id}
[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Delete(string id)
{
var product = await _productService.GetProduct(id);
if (product == null)
{

LJSS -RDS_v1.0 Page 57

 return NotFound();
}

bool isDeleted = await _productService.DeleteProduct(id);

if (isDeleted)
{
return Json(new { success = true, message = "Product deleted successfully." });
}
return Json(new { success = false, message = "Failed to delete the product. It may be
referenced in other records." });
}
}
}

V. Applying Alternative Architecture Patterns

Assuming that the functional requirements remain unchanged, the system is now being
expanded to incorporate additional characteristics related to scalability and reusability. This
enhancement allows the system to support the integration of new user-facing applications,
including the potential development of a mobile app.
V.1 Applying the service-oriented architecture
NF-05 Reusability: The system should be built in a way that allows us to easily use the same
code and features across different platforms. This means that the same functionality can be
adapted for both the web and mobile apps, saving time and effort when adding new platforms or
updating existing ones.
The current system architecture described in Section 3.2 does not fully meet the
requirements of NF-05. To address this, the FSOData component must be restructured as a
distributed component and designed using a service-oriented architecture (SOA). This
adjustment will allow FSOData to function as a distributed service, thereby enhancing the
system’s ability to achieve Reusability, traceability, modularity, and effective maintenance. The
software architecture is redesigned as shown below.

LJSS -RDS_v1.0 Page 58

 Figure V-1 Deployment Diagram for the FSO System Architecture Based on Service-
Oriented Architecture

Figure V-2 Class Diagram for the FSO System Architecture Based on Service-Oriented
Architecture

LJSS -RDS_v1.0 Page 59

 Figure V-3 Component Diagram for the FSO System Architecture Based on Service-
Oriented Architecture

V.2 Applying Service Discovery Pattern in the service-oriented architecture

Assuming that user requirements change and the store's scale may later expand into a
chain of stores with an increasing number of users, the system will need to address an additional
non- functional requirement, NF-06, as follows:
NF-06: The system must be designed to accommodate an increasing number of stores and users
while maintaining performance and reliability. This includes the ability to scale both horizontally
and vertically. The architecture should support the addition of new stores and handle a growing
volume of transactions and concurrent users without significant performance degradation. The
system should implement load balancing to evenly distribute traffic and employ scalable
database solutions to manage increasing amounts of data effectively.

LJSS -RDS_v1.0 Page 60

Figure V-4 Deployment Diagram for the FSO System Architecture Based on Microservice
Architecture

LJSS -RDS_v1.0 Page 61

Figure V-5 Class Diagram for the FSO System Architecture Based on Microservice Architecture

Figure V-6 Component Diagram for the FSO System Architecture Based on Microservice
Architecture

LJSS -RDS_v1.0 Page 62