Software Design and Implementation

Document
Project Name: Knowledge Management System​
Version: 1.0​
Date: December 31st, 2024​
Prepared by:

-​ Nguyen Hoai Duy - 2202087

-​ Huynh Van Dong - 2202086
-​ Vo Huu Nhan - 2202083

1. Introduction
a.​ Introduction to the Project:

The Knowledge Management System (KMS) is a centralized platform designed to

streamline the management and organization of educational resources. It provides a
user-friendly interface for lecturers, teachers, and departments to upload, store, and manage
various types of files, such as PDFs, images, Word documents, text files, and more. By
centralizing these resources, the system aims to foster efficient knowledge sharing,
collaboration, and accessibility across educational institutions.

b.​ Purpose and Significance of the Project:

The purpose of the KMS is to address common challenges faced by educators and
institutions, such as scattered resources, lack of version control, and inefficient sharing
methods. The system empowers users to:

●​ Organize their materials systematically.

●​ Collaborate effectively within and across departments.
●​ Maintain an up-to-date repository of resources.
●​ Manage Users efficiently, ensuring appropriate access and permissions for
different roles.

Significance:

●​ Enhances Productivity: Reduces the time spent searching for resources and
managing users.
 ●​ Encourages Collaboration: Provides shared access to materials and tools,
fostering teamwork.
●​ Ensures Secure Storage: Offers controlled access to sensitive information
through role-based permissions.
●​ Supports Seamless Workflows: Facilitates efficient management of both
content and user roles, streamlining operations across the institution.
●​ User Management: Simplifies account creation, role assignment, and
permission handling to ensure a smooth user experience while maintaining
security and compliance.
c.​ Scope and Target Users:

Scope:​
​ ​ The system is scalable and can be implemented across various educational
institutions, including schools, colleges, and universities. It supports multiple file types and
allows users to manage their files through features like uploading, modifying, and deleting
resources.

Target Users:

1.​ Lecturers and Teachers: To store lesson plans, presentations, and educational
materials.
2.​ Departments: To manage administrative files and shared resources.
d.​ Summary of Key Features:

Documents Management:

●​ Upload various file types (PDF, images, Word documents, etc.).

●​ Modify and update existing files.
●​ Delete files securely.

Version Control:

●​ Track changes to files and maintain older versions for reference.

Search and Filter:

●​ Easily locate files using keywords, tags, or filters.

Access Control:

●​ Assign roles and permissions to ensure secure file sharing and management.

Collaboration Tools:

●​ Enable sharing and co-editing of files among users.

Activity Logs:
 ●​ Monitor file access and modifications for accountability.

Cloud Integration:

●​ Ensure secure and scalable storage through cloud services.

e.​ Technologies Used (Summary):

Frontend:

●​ Next.js: A React-based framework for building dynamic and responsive web

interfaces, offering server-side rendering and static site generation for optimal
performance.

Backend:

●​ Python with FastAPI: A modern and high-performance web framework ideal for
building APIs, known for its speed and intuitive design.

Database:

●​ MongoDB: A NoSQL database that stores file metadata and user information in a
flexible, document-oriented format, allowing for efficient handling of unstructured
data.

2. Software Architecture
The software is based on a Client-Server architecture, where the mobile app (client)
communicates with a remote server to fetch and store data. The server hosts the business logic
and interacts with a relational database.

2.1 Client-Side (Mobile Application)

●​ Platform: iOS and Android

●​ Programming Languages: Swift (for iOS), Kotlin (for Android)
●​ UI Framework: SwiftUI (for iOS), Jetpack Compose (for Android)
●​ State Management: Redux (for managing application state)

2.2 Server-Side (Backend)

●​ Framework: Node.js with Express

●​ Database: PostgreSQL
●​ API Communication: RESTful API with JSON response
●​ Authentication: OAuth 2.0 (JWT-based)
2.3 Communication Protocols

●​ API Endpoints: RESTful services exposed over HTTPS

●​ Authentication: Secure token-based authentication using OAuth 2.0 and JWT

3. Functional Requirements
a.​ Knowledge Management:
●​ File Upload:​
Users (lecturers, teachers, departments) can upload files of various
formats, including:
○​ PDFs
○​ Images
○​ Word documents
○​ Text files
○​ Other common formats
●​ File Editing:​
Users can modify uploaded files by replacing them or updating file
metadata (e.g., title, description, tags).
●​ File Deletion:​
Users can delete files they no longer need while ensuring accidental
deletion is prevented with a confirmation step.
●​ Version control: Maintain a history of file updates to allow users to:
○​ View previous versions.
○​ Restore older versions if needed.
●​ Activity Logs: Track user actions, such as file uploads, modifications,
deletions, and logins, for accountability and auditing.
●​ Collaboration Tools: Allow users to share files with specific individuals
or groups. Enable co-editing or commenting on shared files to encourage
collaboration.
b.​ File Viewing and Searching:
●​ File List Display:​
Display a list of uploaded files with essential details, such as name, type,
upload date, and owner.
●​ Search and Filter:​
Users can search and filter files by:
○​ File type
○​ Upload date
○​ Tags
○​ Owner
c.​ User Authentication and Authorization:
 ●​ Secure Login and Registration:​
Implement OAuth for secure user authentication, ensuring only authorized
users can access the system.
●​ Role-Based Access Control:​
Assign permissions based on user roles, such as:
○​ Admin: Full access to all files and system settings.
○​ Department: Access to department-specific files.
○​ Lecturer/Teacher: Access to their own and shared resources.

4. Database Design
4.1 Identify Entities And Relationships

Eddx file’s link: KMS_ER

❖​ Entities
➢​ User
■​ Lecturers, teachers, and department staff who interact with the system.
➢​ Document
■​ The educational resources (PDFs, images, Word...) stored in the system.
➢​ Department
■​ The organizational units (SIT Department etc.) within the institution.
➢​ Role
■​ The access levels or permissions assigned to users.
➢​ Version
■​ Different versions of a document for version control.
➢​ Activity Log
■​ Logs of user actions (document upload, modification, deletion etc.).
➢​ Tag
■​ Keywords or labels used to categorize and search for documents.
❖​ Relationship
 ➢​ User - Role:
■​ A User has multiple Roles → 1:N
➢​ User - Department:
■​ A User belongs to one Department → 1:N
➢​ User - Document:
■​ A User manages many documents → M:N
➢​ Document - Version:
■​ A File can have multiple Versions → 1:N
➢​ Document - Tag:
■​ A document can have multiple tag, and a tag can link to multiple
documents → M:N
➢​ User - Activity Log:
■​ A User performs actions logged in the Activity Log → 1:N
➢​ Document - Activity Log:
■​ Actions in the Activity Log are associated with specific documents → 1:N

4.2 Tables
❖​ User
➢​ Fields:
■​ The User entity has attributes like UserID, Name, Email, Password,
RoleID, and DepartmentID. These become the fields in the User table.
➢​ Data Types:
■​ UserID is an integer (INT).
■​ Name, Email, and Password are strings with fixed lengths (VARCHAR).
■​ RoleID and DepartmentID are integers (INT) because they reference
other tables.
➢​ Constraints:
■​ UserID, Name, Email, and Password cannot be null (NOT NULL).
■​ RoleID and DepartmentID cannot be null because every user must belong
to a role and department.
➢​ Keys:
■​ UserID is the primary key (Y(P)).
■​ RoleID and DepartmentID are foreign keys

Field Data Type Constraints Key

 UserID INT NOT NULL Y(P)

Name VARCHAR(100) NOT NULL N

Email VARCHAR(100) NOT NULL N

Pass VARCHAR(255) NOT NULL N

RoleID INT NOT NULL Y(F)

DeID INT NOT NULL Y(F)

❖​ FileManager
➢​ Fields:
■​ FileManagerID: Primary key for FileManager table.
■​ UserID: Foreign key referencing the User table.
■​ DocID: Foreign key referencing the Document table
➢​ Keys:
■​ Both DocID and TagID are foreign keys.

Field Data Type Constraints Key

FileManagerID INT NOT NULL Y(P)

UserID INT NOT NULL Y(F)

DocID INT NOT NULL Y(F)

❖​ Document
➢​ Fields:
■​ The Document entity has attributes like DocID, Name, Type,
DepartmentID, and CurrentVersion. These become the fields in the
Document table.
➢​ Data Types:
■​ DocID is an integer (INT).
■​ Name is a string with a fixed length (VARCHAR).
■​ Type is a string with a fixed length (VARCHAR).
■​ DepartmentID is an integer (INT) because it references the Department
table.
■​ CurrentVersion is an integer (INT)
 ➢​ Constraints:
■​ DocID, Name and DepartmentID cannot be null (NOT NULL).
■​ Type and CurrentVersion can be null (optional).
➢​ Keys:
■​ DocID is the primary key (Y(P)).
■​ DepartmentID, and CurrentVersion is foreign keys

Field Data Type Constraints Key

DocID INT NOT NULL Y(P)

Name VARCHAR(255) NOT NULL N

Type VARCHAR(50) NULL N

DeID INT NOT NULL Y(F)

CurrentNumber INT NULL N

❖​ DocumentTag
➢​ Fields:
■​ DocID: Foreign key referencing the File table.
■​ TagID: Foreign key referencing the Tag table.
➢​ Keys:
■​ Composite Primary Key: (DocID, TagID).
■​ Both DocID and TagID are foreign keys.
​

Field Data Type Constraints Key

DocID INT NOT NULL Y(P)

TagID INT NOT NULL Y(P)

❖​ Tag
➢​ Fields:
■​ The Tag entity has attributes like TagID, Name, and DocID. These
become the fields in the Tag table.
➢​ Data Types:
■​ TagID is an integer (INT).
 ■​ Name is a string with a fixed length (VARCHAR).
■​ DocID is an integer (INT) because it references the Document table.
➢​ Constraints:
■​ TagID, Name, and DocID cannot be null (NOT NULL).
➢​ Keys:
■​ TagID is the primary key (Y(P)).
■​ DocID is a foreign key

Field Data Type Constraints Key

TagID INT NOT NULL Y(P)

Name VARCHAR(100) NOT NULL N

DocID INT NOT NULL Y(F)

❖​ Department
➢​ Fields:
■​ The Department entity has attributes like DepartmentID, Name, and
Description. These become the fields in the Department table.
➢​ Data Types:
■​ DepartmentID is an integer (INT).
■​ Name is a string with a fixed length (VARCHAR).
■​ Description is a long text (TEXT).
➢​ Constraints:
■​ DepartmentID and Name cannot be null (NOT NULL).
■​ Description can be null (optional).
➢​ Keys:
■​ DepartmentID is the primary key (Y(P)).

Field Data Type Constraints Key

DeID INT NOT NULL Y(P)

Name VARCHAR(100) NOT NULL N

Descript TEXT NULL N

❖​ Role
➢​ Fields:
■​ The Role entity has attributes like RoleID, Name, and Permissions. These
become the fields in the Role table.
➢​ Data Types:
■​ RoleID is an integer (INT).
■​ Name is a string with a fixed length (VARCHAR).
■​ Permissions is a string with a fixed length (VARCHAR).
➢​ Constraints:
■​ RoleID and Name cannot be null (NOT NULL).
■​ Permissions can be null (optional).
➢​ Keys:
■​ RoleID is the primary key (Y(P)).

Field Data Type Constraints Key

RoleID INT NOT NULL Y(P)

Name VARCHAR(50) NOT NULL N

Permissions VARCHAR(255) NULL N

❖​ Activity Log
➢​ Fields:
■​ The ActivityLog entity has attributes like LogID, UserID, DocID, Action,
Description, and Date. These become the fields in the ActivityLog table.
➢​ Data Types:
■​ LogID is an integer (INT).
■​ UserID is an integer (INT) because it references the User table.
■​ DocID is an integer (INT) because it references the Document table.
■​ Action is a string with a fixed length (VARCHAR).
■​ Date is a date and time (DATETIME).
➢​ Constraints:
■​ LogID, UserID, DocID, Action, and Date cannot be null (NOT NULL).
■​ Description can be null (optional).
 ➢​ Keys:
■​ LogID is the primary key (Y(P)).
■​ UserID and DocID are foreign keys

Field Data Type Constraints Key

LogID INT NOT NULL Y(P)

UserID INT NOT NULL Y(F)

DocID INT NULL Y(F)

Act VARCHAR(50) NOT NULL N

Date DATETIME NOT NULL N

❖​ Version
➢​ Fields:
■​ The Version entity has attributes like VersionID, DocID, VersionNumber,
ModifiedBy, ModificationDate, and FilePath. These become the fields in
the Version table.
➢​ Data Types:
■​ VersionID is an integer (INT).
■​ DocID is an integer (INT) because it references the Document table.
■​ VersionNumber is an integer (INT).
■​ ModifiedBy is an integer (INT) because it references the User table.
■​ ModificationDate is a date and time (DATETIME).
■​ FilePath is a string with a fixed length (VARCHAR).
➢​ Constraints:
■​ VersionID, DocID, VersionNumber, ModifiedBy, ModificationDate, and
FilePath cannot be null (NOT NULL).
➢​ Keys:
■​ VersionID is the primary key (Y(P)).
■​ DocID and ModifiedBy are foreign keys

Field Data Type Constraints Key

VerID INT NOT NULL Y(P)

 DocID INT NOT NULL Y(F)

VersionNumber INT NOT NULL N

By INT NOT NULL Y(F)

Date DATETIME NOT NULL N

FilePath VARCHAR(255) NOT NULL N

6. System Design
6.1 Frontend Design

The frontend design follows the Model-View-ViewModel (MVVM) pattern.

●​ Model: Represents the data and business logic (task data, user credentials, etc.).
●​ View: The UI components responsible for displaying data and receiving user input.
●​ ViewModel: A layer that communicates between the View and the Model, managing UI
state and updating the View based on changes in the data model.

6.2 Backend Design

The backend is built using Node.js with the Express framework. The server exposes a RESTful
API, and communication is done via HTTP requests with JSON responses.

●​ Controllers: Handle requests and return responses.

●​ Services: Contain the business logic and interact with the database.
●​ Models: Represent the data structures (User, Task, etc.) and define validation logic.

7. API Design
7.1 Endpoints

●​ POST /auth/register​
Registers a new user.​
Request Body: { "email": "[email protected]", "password":
"password123" }​
Response: { "token": "jwt_token" }​
 ●​ POST /auth/login​
Authenticates a user and returns a JWT token.​
Request Body: { "email": "[email protected]", "password":
"password123" }​
Response: { "token": "jwt_token" }​

●​ GET /tasks​
Fetches a list of tasks for the authenticated user.​
Headers: { "Authorization": "Bearer jwt_token" }​
Response: { "tasks": [{ "task_id": 1, "title": "Task 1",
"due_date": "2024-12-31" }] }​

●​ POST /tasks​
Creates a new task.​
Request Body: { "title": "New Task", "description": "Description",
"due_date": "2024-12-31", "priority": "High" }​
Response: { "task_id": 1 }​

●​ PUT /tasks/{task_id}​
Updates an existing task.​
Request Body: { "title": "Updated Task", "description": "Updated
description", "due_date": "2024-12-31", "priority": "Medium" }​
Response: { "task_id": 1 }​

8. Implementation Plan
8.1 Milestones

●​ Milestone 1: UI/UX Design (Week 1 - Week 2)​

○​ Finalize app wireframes and user journey.

○​ Review and approve designs with stakeholders.
●​ Milestone 2: Backend Development (Week 3 - Week 5)​

○​ Set up Node.js server and database.

○​ Implement authentication API and task CRUD operations.
●​ Milestone 3: Mobile App Development (Week 4 - Week 6)​

○​ Implement task list, task creation, and task update functionality.

 ○​ Integrate authentication with the backend.
●​ Milestone 4: Testing & Deployment (Week 7 - Week 8)​

○​ Conduct unit and integration testing.

○​ Prepare deployment pipeline (CI/CD).
○​ Deploy the app to production.

9. Testing Strategy
9.1 Unit Testing

●​ Backend: Use Jest for testing API endpoints and services.

●​ Frontend: Use XCTest for iOS and JUnit for Android to test individual components.

9.2 Integration Testing

●​ Test the integration of frontend and backend components.

●​ Ensure that API responses are correctly handled by the client-side application.

9.3 User Acceptance Testing

●​ Perform UAT with stakeholders to ensure that the system meets business requirements.

10. Conclusion
This document outlines the complete design and implementation plan for the MyApp application.
By following this plan, we aim to build a robust, scalable, and secure task management system
that provides an excellent user experience.