2999 lines
133 KiB
TeX
2999 lines
133 KiB
TeX
\documentclass[conference]{IEEEtran}
|
||
\IEEEoverridecommandlockouts
|
||
% The preceding line is only needed to identify funding in the first footnote. If that is unneeded, please comment it out.
|
||
\usepackage{cite}
|
||
\usepackage{amsmath,amssymb,amsfonts}
|
||
\usepackage{algorithmic}
|
||
\usepackage{graphicx}
|
||
\usepackage{textcomp}
|
||
\usepackage{xcolor}
|
||
\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
|
||
T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
|
||
\begin{document}
|
||
|
||
\title{Web-Based Lost and Found Management System for Campus Environment with Auto-Matching and AI Chatbot Using Go Backend and React Frontend\\
|
||
\thanks{Identify applicable funding agency here. If none, delete this.}
|
||
}
|
||
|
||
\author{\IEEEauthorblockN{1\textsuperscript{st} Edward Wibisono Yulianto}
|
||
\IEEEauthorblockA{\textit{Department of Informatics} \\
|
||
\textit{Widya Mandala Kalijudan University}\\
|
||
Surabaya, Indonesia \\
|
||
edward-w.inf24@ukwms.ac.id}
|
||
\and
|
||
\IEEEauthorblockN{2\textsuperscript{nd} Bambang Herlambang}
|
||
\IEEEauthorblockA{\textit{Department of Informatics} \\
|
||
\textit{Widya Mandala Kalijudan University}\\
|
||
Surabaya, Indonesia \\
|
||
bambang-h.inf24@ukwms.ac.id}
|
||
\and
|
||
\IEEEauthorblockN{3\textsuperscript{rd} Nathanael Melvin}
|
||
\IEEEauthorblockA{\textit{Department of Informatics} \\
|
||
\textit{Widya Mandala Kalijudan University}\\
|
||
Surabaya, Indonesia \\
|
||
nathanael-m.inf24@ukwms.ac.id\\}
|
||
}
|
||
\maketitle
|
||
\begin{abstract}
|
||
The Lost and Found System is a client-server web-based application designed to manage lost and found items in a campus environment. The system is built using RESTful API architecture with a Go (Golang)-based backend and React frontend. MySQL database is used for data storage with transaction support to ensure data consistency.
|
||
The system implements several key features: management of found items and lost item reports, a multi-stage verification claim system, an automatic matching algorithm using string similarity (Levenshtein Distance) to connect lost items with found items, and AI chatbot integration using Groq API to assist users in searching and reporting. The role-based access control (RBAC) architecture enables three access levels: user, manager, and admin, each with different access rights.
|
||
To improve operational efficiency, the system is equipped with background workers that perform automatic tasks such as archiving expired items, automatic matching between lost and found items, and sending real-time notifications to users. The system also provides audit logging features for tracking user activities and data export in Excel and PDF formats for reporting purposes.
|
||
Implementation using repository pattern and service layer ensures separation of concerns and facilitates maintenance. Middleware for JWT authentication, rate limiting, and CORS protection ensures system security. With graceful shutdown and context timeout approaches, the system can handle high loads stably. Test results show that the system can effectively manage the claim process and improve the success rate of returning lost items to their owners.
|
||
\end{abstract}
|
||
|
||
\begin{IEEEkeywords}
|
||
Lost and Found System, RESTful API, String Similarity Algorithm, Role-Based Access Control, Background Workers, AI Chatbot Integration, Microservices Architecture
|
||
\end{IEEEkeywords}
|
||
|
||
\section{Introduction}
|
||
|
||
\subsection{Background}
|
||
|
||
The loss of personal belongings is a common problem that frequently occurs in high-mobility campus environments such as universities, schools, and other educational institutions. Students and academic community members often lose important items such as wallets, keys, electronic devices, academic documents, and other personal belongings in various campus locations such as classrooms, libraries, cafeterias, and other public areas. On the other hand, many found items cannot be returned to their owners due to limitations in effective management systems.
|
||
|
||
Conventional lost and found management systems that still rely on manual recording, announcements through information boards, or social media groups have several significant limitations. The item search process is time-consuming, information is not well-organized, there is no clear verification mechanism for the claim process, and data trails are often lost, preventing items from being returned to their owners. Additionally, there is no adequate tracking system to monitor item status from reporting to return.
|
||
|
||
The development of information technology and web-based systems provides solutions to overcome these problems. A web-based Lost and Found system can provide a centralized platform to manage the entire process of reporting lost items, registering found items, claim verification process, and returning items to their owners. By utilizing string similarity algorithms and artificial intelligence technology, the system can automatically match lost items with found items based on reported characteristics, thereby accelerating the identification process and increasing the likelihood of items being returned to their owners.
|
||
|
||
This system is built using modern architecture with a Go (Golang)-based backend known for its high performance and excellent concurrent processing, and a React-based frontend for a responsive and interactive user interface. Implementation of role-based access control (RBAC) ensures that each user has access rights appropriate to their role, while background workers perform automatic tasks such as item matching and data archiving. AI chatbot integration using Groq API provides users with convenience in conducting searches and obtaining interactive assistance.
|
||
|
||
\subsection{Problem Formulation}
|
||
|
||
Based on the background described above, this research will address several problem formulations as follows:
|
||
|
||
\begin{enumerate}
|
||
\item How to design an effective information system to manage lost and found items in a campus environment?
|
||
\item How to implement a string similarity algorithm to automatically match lost items with found items?
|
||
\item How to design a secure claim verification system to ensure items are returned to legitimate owners?
|
||
\item How to integrate an AI chatbot to assist users in the item search and reporting process?
|
||
\item How to implement background workers to perform automatic tasks such as matching and archiving?
|
||
\item How to design a system with scalable and maintainable architecture using good software engineering patterns?
|
||
|
||
\end{enumerate}
|
||
|
||
\subsection{Research Objectives}
|
||
|
||
This research has the following objectives:
|
||
|
||
\begin{enumerate}
|
||
\item To design and implement a web-based Lost and Found information system with RESTful API architecture using Go and React.
|
||
\item To implement the Levenshtein Distance algorithm to calculate similarity scores between lost and found items, enabling effective auto-matching.
|
||
\item To build a multi-stage claim verification system involving users, managers, and admins with a structured approval mechanism.
|
||
\item To integrate a Groq API-based AI chatbot to provide interactive assistance to users in item search and reporting processes.
|
||
\item To implement background workers using goroutines to perform automatic tasks such as auto-matching, auto-archiving, and notification delivery.
|
||
\item To apply software engineering best practices such as repository pattern, service layer, middleware architecture, and dependency injection to ensure maintainable and testable code.
|
||
|
||
\end{enumerate}
|
||
|
||
\subsection{Problem Scope}
|
||
|
||
To maintain research focus and ensure optimal results, this research has the following limitations:
|
||
|
||
\begin{enumerate}
|
||
\item The system is specifically designed for campus environments with three user levels: user (students/staff), manager (administrator), and admin (system administrator).
|
||
\item The matching algorithm used is string similarity based on Levenshtein Distance with configurable threshold.
|
||
\item Claim verification uses secret details that are only known by the item owner and verified by managers or admins.
|
||
\item The AI chatbot uses Groq API with the LLaMA 3.3 70B Versatile model for natural language processing.
|
||
\item The system only manages data in text and image formats, excluding videos or complex documents.
|
||
\item Background workers run periodically with predetermined intervals (matching: 30 minutes, expiration check: 1 hour).
|
||
\item The system does not include integration with payment systems or rewards for item finders.
|
||
\item System notifications are only through in-app notifications, excluding email or SMS notifications.
|
||
\end{enumerate}
|
||
|
||
\subsection{Research Benefits}
|
||
|
||
This research is expected to provide the following benefits:
|
||
|
||
\subsubsection{Theoretical Benefits}
|
||
|
||
\begin{enumerate}
|
||
\item To contribute to the development of web-based management information systems with a Lost and Found system case study.
|
||
\item To demonstrate practical implementation of string similarity algorithms (Levenshtein Distance) in real-world application contexts.
|
||
\item To provide a reference for implementing microservices architecture and background workers using Go (Golang).
|
||
\item To demonstrate the application of AI integration in information systems to enhance user experience.
|
||
\item To provide a case study of role-based access control (RBAC) implementation in multi-user web applications.
|
||
\end{enumerate}
|
||
|
||
\subsubsection{Practical Benefits}
|
||
|
||
\begin{enumerate}
|
||
\item For educational institutions: Providing an effective system to manage lost and found items, improving services to students and the academic community.
|
||
\item For users: Facilitating the process of reporting lost items and searching for found items with a user-friendly interface and AI chatbot assistance.
|
||
\item For administrators: Providing tools to verify claims, manage item data, and generate reports for audit purposes.
|
||
\item For developers: Providing an implementation reference for systems with clean, scalable architecture that follows best practices.
|
||
\item For the community: Increasing the likelihood that lost items can be returned to their owners through a well-organized system.
|
||
\end{enumerate}
|
||
\section{Literature Review}
|
||
|
||
This chapter discusses the theoretical foundation and technologies used in developing the Lost and Found System, including RESTful API architecture, design patterns, string similarity algorithms, security mechanisms, and artificial intelligence integration.
|
||
|
||
\subsection{RESTful API Architecture}
|
||
|
||
REST (Representational State Transfer) is an architectural style for designing networked applications that uses HTTP methods to perform CRUD operations. The Lost and Found System implements RESTful principles through structured endpoints that map to specific resources.
|
||
|
||
The system uses standard HTTP methods: GET for retrieving data, POST for creating new resources, PUT/PATCH for updates, and DELETE for removal operations. Each endpoint follows a clear naming convention, such as \texttt{/api/items} for item management and \texttt{/api/claims} for claim processing. The API returns standardized JSON responses with consistent structure including status codes, messages, and data payloads.
|
||
|
||
According to Fielding's REST constraints, the system implements stateless communication where each request contains all necessary information for processing. The server maintains no client context between requests, with authentication handled through JWT tokens passed in request headers. This stateless design enables horizontal scaling and improves system reliability.
|
||
|
||
\subsection{Design Patterns}
|
||
|
||
The system implements several software engineering patterns to ensure maintainability, testability, and separation of concerns.
|
||
|
||
\subsubsection{Repository Pattern}
|
||
|
||
The Repository Pattern provides an abstraction layer between the business logic and data access layer. Each entity (Item, LostItem, Claim, User) has a dedicated repository that encapsulates all database operations. For example, \texttt{ItemRepository} handles all database queries related to items, including CRUD operations, complex queries with filters, and transaction management.
|
||
|
||
This pattern offers several advantages: it centralizes data access logic, makes the codebase more testable by allowing repository mocking, and provides a consistent interface for data operations. The repository layer uses GORM as the ORM framework, which provides type-safe database operations and automatic query generation.
|
||
|
||
\subsubsection{Service Layer Pattern}
|
||
|
||
The Service Layer Pattern encapsulates business logic separate from controllers and repositories. Services like \texttt{ClaimService}, \texttt{ItemService}, and \texttt{MatchService} contain the core business rules and orchestrate multiple repository operations when needed.
|
||
|
||
For instance, the claim verification process in \texttt{ClaimService} involves multiple steps: validating the claim, calculating similarity scores, updating item status, creating notifications, and logging audit trails. By centralizing this logic in a service, the system ensures consistency across different entry points and simplifies testing of business rules.
|
||
|
||
\subsubsection{Dependency Injection}
|
||
|
||
The system uses dependency injection to manage component dependencies. Controllers receive repository and service dependencies through constructor injection, making components loosely coupled and easily testable. This approach follows SOLID principles, particularly the Dependency Inversion Principle, where high-level modules depend on abstractions rather than concrete implementations.
|
||
|
||
\subsection{String Similarity Algorithm}
|
||
|
||
The automatic matching feature uses the Levenshtein Distance algorithm to calculate similarity between text strings. This algorithm measures the minimum number of single-character edits (insertions, deletions, or substitutions) required to transform one string into another.
|
||
|
||
\subsubsection{Levenshtein Distance Implementation}
|
||
|
||
The implementation uses dynamic programming to compute the edit distance efficiently. Given two strings $s_1$ and $s_2$, the algorithm creates a matrix where $dp[i][j]$ represents the minimum edit distance between the first $i$ characters of $s_1$ and the first $j$ characters of $s_2$.
|
||
|
||
The recurrence relation is:
|
||
\begin{equation}
|
||
dp[i][j] = \min \begin{cases}
|
||
dp[i-1][j] + 1 & \text{(deletion)} \\
|
||
dp[i][j-1] + 1 & \text{(insertion)} \\
|
||
dp[i-1][j-1] + cost & \text{(substitution)}
|
||
\end{cases}
|
||
\end{equation}
|
||
|
||
where $cost = 0$ if $s_1[i] = s_2[j]$, otherwise $cost = 1$.
|
||
|
||
The similarity score is then calculated as:
|
||
\begin{equation}
|
||
similarity = 1 - \frac{distance}{\max(len(s_1), len(s_2))}
|
||
\end{equation}
|
||
|
||
This produces a normalized score between 0 and 1, where 1 indicates identical strings and 0 indicates completely different strings.
|
||
|
||
\subsubsection{Text Normalization}
|
||
|
||
Before calculating similarity, the system applies text normalization: converting to lowercase, removing special characters, and filtering stopwords. This preprocessing improves matching accuracy by focusing on meaningful content words rather than common function words.
|
||
|
||
The matching algorithm considers multiple fields with weighted scores. Name similarity receives 50\% weight while description similarity receives 50\% weight. A match is considered significant when the combined score exceeds the configured threshold (typically 50\%).
|
||
|
||
\subsection{Role-Based Access Control (RBAC)}
|
||
|
||
The system implements RBAC to manage user permissions across three roles: User, Manager, and Admin. Each role has specific permissions defined in the database, allowing fine-grained access control.
|
||
|
||
\subsubsection{Permission System}
|
||
|
||
Permissions are defined as action-resource pairs (e.g., \texttt{item:create}, \texttt{claim:approve}). The \texttt{Role} model contains a many-to-many relationship with \texttt{Permission}, allowing flexible assignment of permissions to roles. Middleware functions check user permissions before allowing access to protected endpoints.
|
||
|
||
For example, only users with \texttt{claim:approve} permission (Managers and Admins) can verify claims. Regular users can create claims but cannot approve them. This separation ensures proper workflow enforcement and maintains data integrity.
|
||
|
||
\subsubsection{Hierarchical Access}
|
||
|
||
The system implements a hierarchical access model where higher-level roles inherit permissions from lower levels. Admins can perform all Manager operations, and Managers can perform all User operations. This simplifies permission management while maintaining security boundaries.
|
||
|
||
\subsection{Authentication and Security}
|
||
|
||
\subsubsection{JSON Web Tokens (JWT)}
|
||
|
||
The system uses JWT for stateless authentication. Upon successful login, the server generates a token containing user ID, email, and role information. This token is cryptographically signed using HMAC-SHA256 with a secret key.
|
||
|
||
Each subsequent request includes the JWT in the Authorization header as a Bearer token. The JWT middleware validates the token signature, checks expiration, and loads user information for authorization decisions. Tokens expire after 7 days, requiring users to re-authenticate periodically.
|
||
|
||
\subsubsection{Password Security}
|
||
|
||
User passwords are hashed using bcrypt, an adaptive hash function designed for password storage. Bcrypt incorporates a salt to prevent rainbow table attacks and uses a configurable work factor to remain resistant to brute-force attacks as computing power increases.
|
||
|
||
\subsubsection{Data Encryption}
|
||
|
||
Sensitive personal information (NRP, phone numbers) is encrypted using AES-256 in GCM mode before storage. The encryption key is stored securely as an environment variable. This ensures that even if the database is compromised, sensitive data remains protected.
|
||
|
||
\subsubsection{Rate Limiting}
|
||
|
||
The system implements rate limiting to prevent abuse and DoS attacks. Each IP address is limited to 1000 requests per minute. The rate limiter uses an in-memory map to track request counts per IP address, with automatic cleanup of stale entries.
|
||
|
||
\subsection{Background Workers and Concurrency}
|
||
|
||
\subsubsection{Goroutines for Concurrent Processing}
|
||
|
||
The system uses Go's goroutines for concurrent background tasks. Four main workers run continuously: \texttt{ExpireWorker} for archiving expired items, \texttt{MatchingWorker} for automatic item matching, \texttt{NotificationWorker} for sending notifications, and \texttt{AuditWorker} for log aggregation.
|
||
|
||
Goroutines are lightweight threads managed by the Go runtime, enabling efficient concurrent execution without the overhead of OS threads. Each worker runs in its own goroutine, allowing parallel processing of different tasks.
|
||
|
||
\subsubsection{Worker Pool Pattern}
|
||
|
||
The \texttt{ExpireWorker} implements a worker pool pattern with 5 concurrent workers processing expired items. This pattern provides controlled concurrency, preventing resource exhaustion while maximizing throughput. A task queue (buffered channel) holds items to be processed, and workers consume tasks concurrently.
|
||
|
||
\subsubsection{Graceful Shutdown}
|
||
|
||
The system implements graceful shutdown using WaitGroups and stop channels. When a shutdown signal is received, workers complete their current tasks before terminating. The HTTP server stops accepting new connections but completes in-flight requests. This prevents data loss and ensures clean system termination.
|
||
|
||
\subsection{Database Design and Transactions}
|
||
|
||
\subsubsection{Relational Database Schema}
|
||
|
||
The system uses MySQL with a normalized relational schema. Key tables include \texttt{users}, \texttt{items}, \texttt{lost\_items}, \texttt{claims}, \texttt{match\_results}, and \texttt{notifications}. Foreign key constraints maintain referential integrity, and indexes optimize query performance.
|
||
|
||
The schema uses soft deletes (deleted\_at timestamp) to preserve data history. This allows recovery of accidentally deleted records and maintains audit trails for compliance purposes.
|
||
|
||
\subsubsection{Transaction Management}
|
||
|
||
Database transactions ensure ACID properties for complex operations. For example, the claim verification process wraps multiple operations in a transaction: updating claim status, modifying item status, creating notifications, and logging audit entries. If any step fails, the entire transaction rolls back, maintaining data consistency.
|
||
|
||
The system uses GORM's transaction API with proper error handling. Row-level locking prevents concurrent modification conflicts in critical sections, such as claim approval where multiple managers might process the same claim simultaneously.
|
||
|
||
\subsubsection{Stored Procedures}
|
||
|
||
The system leverages MySQL stored procedures for complex operations like automatic archiving. The \texttt{sp\_archive\_expired\_items} procedure efficiently identifies and archives expired items in a single database round-trip, reducing network overhead and improving performance.
|
||
|
||
\subsection{Artificial Intelligence Integration}
|
||
|
||
\subsubsection{Groq API and LLaMA Model}
|
||
|
||
The system integrates an AI chatbot using the Groq API with the LLaMA 3.3 70B Versatile model. Groq provides high-performance inference for large language models, enabling real-time conversational interactions.
|
||
|
||
The chatbot assists users in item searches, report guidance, and claim process explanation. It receives context about the user's lost items and recent found items, providing personalized responses based on system state.
|
||
|
||
\subsubsection{Intent Recognition}
|
||
|
||
The system implements basic intent recognition by analyzing keywords in user messages. Four main intents are detected: \texttt{search\_item}, \texttt{report\_lost}, \texttt{claim\_help}, and \texttt{general}. The detected intent guides response generation, providing relevant information and actions.
|
||
|
||
\subsubsection{Context Management}
|
||
|
||
Each chat request includes conversation history and relevant system context. The system builds context by querying the user's lost item reports and searching for relevant found items. This context is included in the AI prompt, enabling informed responses that reference specific items and match results.
|
||
|
||
\subsection{API Request Lifecycle}
|
||
|
||
The complete lifecycle of an API request demonstrates the integration of all architectural components:
|
||
|
||
\begin{enumerate}
|
||
\item Request arrives at the Gin router and passes through middleware layers
|
||
\item CORS middleware handles cross-origin requests
|
||
\item Rate limiter checks request quota for the client IP
|
||
\item JWT middleware validates authentication token and loads user data
|
||
\item Role middleware verifies user has required permissions
|
||
\item Request reaches the appropriate controller
|
||
\item Controller delegates business logic to service layer
|
||
\item Service coordinates multiple repositories for data operations
|
||
\item Repositories execute database queries using GORM
|
||
\item Response flows back through the layers with standardized format
|
||
\item Background workers process asynchronous tasks (notifications, matching)
|
||
\end{enumerate}
|
||
|
||
This layered architecture provides separation of concerns, making the system maintainable, testable, and scalable. Each layer has a specific responsibility and communicates through well-defined interfaces.
|
||
|
||
\subsection{System Reliability and Error Handling}
|
||
|
||
\subsubsection{Context Timeouts}
|
||
|
||
All database operations use Go's context package with timeouts (typically 3-15 seconds depending on complexity). This prevents hung requests from blocking resources indefinitely. If an operation exceeds its timeout, it returns an error that can be handled gracefully.
|
||
|
||
\subsubsection{Transaction Rollback}
|
||
|
||
The system implements comprehensive transaction error handling. When any operation within a transaction fails, the entire transaction rolls back automatically. This prevents partial updates that could leave the database in an inconsistent state.
|
||
|
||
\subsubsection{Structured Error Responses}
|
||
|
||
All API errors return structured JSON responses with consistent format: success status, error message, and optional error details. This standardization simplifies client-side error handling and debugging.
|
||
|
||
The system distinguishes between client errors (4xx status codes) for invalid requests and server errors (5xx status codes) for internal failures, following HTTP best practices.
|
||
|
||
\subsection{Audit Logging and Monitoring}
|
||
|
||
The system maintains comprehensive audit logs tracking all significant actions. Each log entry records the user, action type, affected entity, timestamp, IP address, and user agent. This provides accountability and enables security analysis.
|
||
|
||
Revision logs track changes to item data, recording the field changed, old value, new value, and reason for change. This audit trail supports compliance requirements and enables data recovery if needed.
|
||
|
||
The logging strategy balances detail with performance, using asynchronous logging to avoid blocking request processing while ensuring important events are captured.
|
||
\section{System Design and Implementation}
|
||
|
||
This chapter presents the detailed design and implementation of the Lost and Found System, including the database schema, system architecture, component design, and implementation strategies. The system employs a microservices-oriented architecture with RESTful API design principles, background workers for automated tasks, and a comprehensive security framework.
|
||
|
||
\subsection{Database Design}
|
||
|
||
The database design forms the foundation of the Lost and Found System, implementing a normalized relational schema that ensures data integrity, supports complex queries, and maintains audit trails for compliance purposes.
|
||
|
||
\subsubsection{Entity Relationship Diagram}
|
||
|
||
The system database consists of 15 interconnected tables organized into functional domains: user management, item management, claim processing, matching system, and audit logging. Figure \ref{fig:erd} illustrates the complete entity relationship diagram showing all entities, their attributes, and relationships.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=\columnwidth]{erd_diagram.png}}
|
||
\caption{Entity Relationship Diagram of Lost and Found System Database}
|
||
\label{fig:erd}
|
||
\end{figure}
|
||
|
||
The database schema implements several key design patterns:
|
||
|
||
\textbf{Soft Delete Pattern:} All primary tables include a \texttt{deleted\_at} timestamp field, enabling logical deletion rather than physical removal of records. This preserves data history and supports recovery of accidentally deleted items while maintaining referential integrity.
|
||
|
||
\textbf{Audit Trail Design:} The \texttt{audit\_logs} and \texttt{revision\_logs} tables maintain comprehensive records of all system activities. The audit log captures high-level actions (create, update, delete, verify) with associated metadata including IP addresses and user agents. The revision log tracks field-level changes to items, storing old values, new values, and reasons for modification.
|
||
|
||
\textbf{Polymorphic Relationships:} The \texttt{claims} table implements polymorphic associations, allowing claims to reference either found items (regular claims) or lost item reports (direct claims). This design enables two distinct claim workflows within a unified data structure.
|
||
|
||
\subsubsection{Core Database Tables}
|
||
|
||
\textbf{Users and Roles:}
|
||
The user management system implements role-based access control (RBAC) through the \texttt{users}, \texttt{roles}, \texttt{permissions}, and \texttt{role\_permissions} tables. Users are assigned to roles (admin, manager, user), and roles contain collections of permissions that define allowed actions. This flexible design enables fine-grained access control without hardcoding permissions in application logic.
|
||
|
||
The \texttt{users} table stores encrypted sensitive information including NRP (student identification numbers) and phone numbers using AES-256-GCM encryption. The encryption key is stored securely as an environment variable and initialized during system startup.
|
||
|
||
\textbf{Items and Lost Items:}
|
||
Found items are stored in the \texttt{items} table with comprehensive metadata including discovery location, date found, public description, and secret details. The \texttt{secret\_details} field contains confidential information known only to the true owner, used for claim verification. The \texttt{expires\_at} field automatically calculates to 90 days from the date found, after which items are eligible for archiving.
|
||
|
||
Lost item reports in the \texttt{lost\_items} table capture characteristics of missing items to enable automatic matching. The table includes fields for color, expected location, and detailed descriptions that feed into the similarity algorithm. The \texttt{direct\_claim\_id} foreign key links to claims when finders directly contact owners.
|
||
|
||
\textbf{Claims and Verification:}
|
||
The \texttt{claims} table manages the claim submission and verification process. Each claim references either an item (regular claim) or a lost item (direct claim) through nullable foreign keys \texttt{item\_id} and \texttt{lost\_item\_id}. Claims progress through statuses: pending, approved, rejected, waiting\_owner, or verified.
|
||
|
||
The \texttt{claim\_verifications} table stores similarity scores and matched keywords generated by the Levenshtein Distance algorithm. The \texttt{similarity\_score} field (0-100) quantifies the match quality between claim descriptions and secret details. The \texttt{is\_auto\_matched} boolean indicates whether the verification was system-generated or manual.
|
||
|
||
\textbf{Match Results:}
|
||
Automatic matching results are stored in \texttt{match\_results}, linking lost items to found items with similarity scores above the configured threshold (typically 50\%). The \texttt{matched\_fields} JSON field contains detailed breakdown of which attributes matched (name, description, color) and their individual scores. The \texttt{is\_notified} flag tracks whether users have been informed of potential matches.
|
||
|
||
\textbf{Archives:}
|
||
The \texttt{archives} table preserves historical records of items removed from active inventory. Items are archived when they expire (90 days unclaimed) or when cases are closed (successfully returned to owner). The archive maintains a complete snapshot of the item's final state including the \texttt{berita\_acara\_no} (official handover document number) and \texttt{bukti\_serah\_terima} (proof of delivery) for closed cases.
|
||
|
||
\textbf{Notifications:}
|
||
The \texttt{notifications} table implements an in-app notification system. Notifications are created for events including match discoveries, claim status changes, and case closures. The \texttt{entity\_type} and \texttt{entity\_id} fields provide polymorphic links to related records, enabling navigation to relevant items from notifications.
|
||
|
||
\textbf{Chat Messages:}
|
||
The AI chatbot integration stores conversation history in \texttt{chat\_messages}. Each message records the user's query, the AI-generated response, detected intent (search\_item, report\_lost, claim\_help, general), and contextual data used for response generation. The \texttt{confidence\_score} field quantifies the intent detection certainty.
|
||
|
||
\subsubsection{Database Indexes and Performance Optimization}
|
||
|
||
The schema includes strategic indexes to optimize query performance:
|
||
|
||
\begin{itemize}
|
||
\item \textbf{Primary Keys:} All tables use auto-incrementing integer primary keys for efficient joins and foreign key references.
|
||
\item \textbf{Foreign Key Indexes:} Indexes on all foreign key columns (\texttt{user\_id}, \texttt{item\_id}, \texttt{category\_id}, etc.) accelerate join operations and referential integrity checks.
|
||
\item \textbf{Status Indexes:} Composite indexes on status fields (\texttt{items.status}, \texttt{claims.status}, \texttt{lost\_items.status}) enable fast filtering of active records.
|
||
\item \textbf{Timestamp Indexes:} Indexes on \texttt{created\_at}, \texttt{expires\_at}, and \texttt{deleted\_at} support temporal queries and soft delete filtering.
|
||
\item \textbf{Unique Indexes:} Unique constraints on \texttt{users.email}, \texttt{categories.slug}, and \texttt{archives.item\_id} prevent duplicate entries.
|
||
\end{itemize}
|
||
|
||
\subsubsection{Database Constraints and Referential Integrity}
|
||
|
||
Foreign key constraints maintain referential integrity with appropriate cascading behaviors:
|
||
|
||
\begin{itemize}
|
||
\item \texttt{ON DELETE CASCADE}: Applied to dependent records that should be removed when parent is deleted (claims when items deleted, notifications when users deleted).
|
||
\item \texttt{ON DELETE SET NULL}: Applied to optional references that should be preserved (verified\_by when manager deleted, claimed\_by when user deleted).
|
||
\item \texttt{ON DELETE RESTRICT}: Applied to critical references that prevent deletion (categories referenced by items, roles referenced by users).
|
||
\end{itemize}
|
||
|
||
\subsection{System Architecture}
|
||
|
||
The Lost and Found System implements a layered architecture that separates concerns and promotes maintainability, testability, and scalability. Figure \ref{fig:architecture} illustrates the complete system architecture.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=\columnwidth]{system_architecture.png}}
|
||
\caption{Lost and Found System Architecture}
|
||
\label{fig:architecture}
|
||
\end{figure}
|
||
|
||
\subsubsection{Architectural Layers}
|
||
|
||
\textbf{Presentation Layer:}
|
||
The presentation layer consists of static HTML, CSS, and JavaScript files served by the Gin web framework. The frontend implements a single-page application (SPA) pattern with role-specific interfaces:
|
||
\begin{itemize}
|
||
\item \texttt{index.html}: Public landing page for browsing found items
|
||
\item \texttt{user.html}: User dashboard for reporting lost items and managing claims
|
||
\item \texttt{manager.html}: Manager interface for claim verification and item management
|
||
\item \texttt{admin.html}: Administrator panel for user management, categories, and system configuration
|
||
\end{itemize}
|
||
|
||
The JavaScript frontend is organized into modular components (\texttt{ItemCard.js}, \texttt{ClaimCard.js}, \texttt{Modal.js}, etc.) that communicate with the backend via RESTful API calls. The \texttt{api.js} utility module handles HTTP requests, authentication token injection, and error handling.
|
||
|
||
\textbf{API Layer:}
|
||
The RESTful API layer exposes HTTP endpoints for all system operations. The \texttt{routes.go} module defines endpoint mappings and associates them with controller functions. API routes are grouped by domain:
|
||
\begin{itemize}
|
||
\item \texttt{/api/auth/*}: Authentication endpoints (register, login, refresh token)
|
||
\item \texttt{/api/items/*}: Found item management
|
||
\item \texttt{/api/lost-items/*}: Lost item reports
|
||
\item \texttt{/api/claims/*}: Claim submission and verification
|
||
\item \texttt{/api/matches/*}: Match result queries
|
||
\item \texttt{/api/admin/*}: Administrative operations
|
||
\item \texttt{/api/ai/*}: AI chatbot interactions
|
||
\end{itemize}
|
||
|
||
\textbf{Middleware Layer:}
|
||
HTTP requests pass through a pipeline of middleware functions before reaching controllers:
|
||
\begin{enumerate}
|
||
\item \texttt{CORSMiddleware}: Handles cross-origin resource sharing headers
|
||
\item \texttt{LoggerMiddleware}: Records request details for monitoring
|
||
\item \texttt{RateLimiterMiddleware}: Prevents abuse with per-IP rate limiting (1000 requests/minute)
|
||
\item \texttt{JWTMiddleware}: Validates authentication tokens and loads user context
|
||
\item \texttt{RoleMiddleware}: Enforces permission-based access control
|
||
\item \texttt{IdempotencyMiddleware}: Prevents duplicate submissions for sensitive operations
|
||
\end{enumerate}
|
||
|
||
\textbf{Controller Layer:}
|
||
Controllers handle HTTP request/response processing and input validation. Each controller focuses on a specific domain:
|
||
\begin{itemize}
|
||
\item \texttt{AuthController}: User registration, login, token refresh
|
||
\item \texttt{ItemController}: CRUD operations for found items
|
||
\item \texttt{LostItemController}: Lost item report management
|
||
\item \texttt{ClaimController}: Claim submission and verification workflow
|
||
\item \texttt{MatchController}: Similarity search and match retrieval
|
||
\item \texttt{AdminController}: System administration functions
|
||
\item \texttt{AIController}: Chatbot message processing
|
||
\end{itemize}
|
||
|
||
Controllers validate input using the Gin binding framework, extract user context from middleware, invoke appropriate service methods, and format responses using utility functions.
|
||
|
||
\textbf{Service Layer:}
|
||
The service layer implements business logic and orchestrates complex operations. Services coordinate multiple repositories and handle transaction management:
|
||
\begin{itemize}
|
||
\item \texttt{AuthService}: Password hashing, token generation, user validation
|
||
\item \texttt{ItemService}: Item lifecycle management, expiration handling
|
||
\item \texttt{ClaimService}: Multi-stage claim verification, case closure
|
||
\item \texttt{MatchService}: Similarity calculation, automatic matching
|
||
\item \texttt{AIService}: Groq API integration, intent detection, context building
|
||
\end{itemize}
|
||
|
||
Services encapsulate business rules, ensuring consistent behavior across different entry points. For example, the claim verification process in \texttt{ClaimService} involves:
|
||
\begin{enumerate}
|
||
\item Locking the claim record with pessimistic locking
|
||
\item Calculating similarity score between claim and item
|
||
\item Creating or updating verification record
|
||
\item Updating claim and item status
|
||
\item Resolving related lost item reports
|
||
\item Creating user notifications
|
||
\item Logging audit entries
|
||
\end{enumerate}
|
||
|
||
\textbf{Repository Layer:}
|
||
Repositories provide an abstraction over database operations, encapsulating GORM queries and transaction management:
|
||
\begin{itemize}
|
||
\item \texttt{UserRepository}: User CRUD, authentication queries
|
||
\item \texttt{ItemRepository}: Item queries with filtering, search, pagination
|
||
\item \texttt{ClaimRepository}: Claim queries with complex joins
|
||
\item \texttt{MatchResultRepository}: Match persistence and retrieval
|
||
\item \texttt{NotificationRepository}: Notification creation and marking read
|
||
\end{itemize}
|
||
|
||
The repository pattern enables testing with mock implementations and provides a consistent interface for data access. All database operations use GORM's context-aware methods with timeout handling to prevent hung requests.
|
||
|
||
\textbf{Worker Layer:}
|
||
Background workers run as concurrent goroutines, performing scheduled and periodic tasks:
|
||
\begin{itemize}
|
||
\item \texttt{ExpireWorker}: Archives items that have exceeded 90-day retention period
|
||
\item \texttt{MatchingWorker}: Runs automatic matching algorithm every 30 minutes
|
||
\item \texttt{NotificationWorker}: Sends pending notifications every 5 minutes
|
||
\item \texttt{AuditWorker}: Aggregates and processes audit log entries
|
||
\end{itemize}
|
||
|
||
Workers implement graceful shutdown through stop channels and WaitGroups, ensuring in-progress tasks complete before system termination.
|
||
|
||
\subsection{Request Processing Flow}
|
||
|
||
Figure \ref{fig:request_flow} illustrates the complete lifecycle of an API request through the system architecture.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=\columnwidth]{request_flow.png}}
|
||
\caption{API Request Processing Flow}
|
||
\label{fig:request_flow}
|
||
\end{figure}
|
||
|
||
A typical authenticated request follows this path:
|
||
|
||
\begin{enumerate}
|
||
\item HTTP request arrives at Gin router
|
||
\item CORS middleware adds cross-origin headers
|
||
\item Rate limiter checks request quota for client IP
|
||
\item Logger middleware records request details
|
||
\item JWT middleware validates token, loads user from database
|
||
\item Role middleware verifies user has required permissions
|
||
\item Router dispatches request to appropriate controller
|
||
\item Controller validates input and extracts parameters
|
||
\item Controller invokes service layer method with user context
|
||
\item Service begins database transaction if needed
|
||
\item Service coordinates multiple repository operations
|
||
\item Repositories execute GORM queries with context timeout
|
||
\item Transaction commits or rolls back based on success
|
||
\item Service returns result or error to controller
|
||
\item Controller formats response using utility functions
|
||
\item Response flows back through middleware layers
|
||
\item HTTP response sent to client with appropriate status code
|
||
\end{enumerate}
|
||
|
||
Context timeouts are applied at each layer: 15 seconds for complex queries, 5 seconds for simple operations, and 3 seconds for single-record lookups. This prevents resource exhaustion from slow queries while allowing sufficient time for legitimate operations.
|
||
|
||
\subsection{Claim Processing Workflow}
|
||
|
||
The claim verification process represents one of the most complex workflows in the system. Figure \ref{fig:claim_flow} illustrates the complete state machine for claim processing.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=0.7\columnwidth]{claim_flow.png}}
|
||
\caption{Claim Verification Workflow}
|
||
\label{fig:claim_flow}
|
||
\end{figure}
|
||
|
||
\subsubsection{Regular Claim Flow}
|
||
|
||
When a user submits a claim for a found item:
|
||
|
||
\begin{enumerate}
|
||
\item User completes claim form with description of item characteristics
|
||
\item System validates no pending claim exists for same user/item pair
|
||
\item System validates item is in claimable status (unclaimed or pending\_claim)
|
||
\item System creates claim record with status "pending"
|
||
\item System updates item status to "pending\_claim"
|
||
\item System calculates similarity score between claim description and item's secret details using Levenshtein Distance algorithm
|
||
\item System creates verification record with similarity score and matched keywords
|
||
\item Notification sent to managers about new claim requiring verification
|
||
\item Manager reviews claim, similarity score, and available evidence
|
||
\item Manager approves or rejects claim with explanatory notes
|
||
\item If approved:
|
||
\begin{itemize}
|
||
\item Claim status updated to "approved"
|
||
\item Item status updated to "verified"
|
||
\item Related lost item reports resolved to "found" status
|
||
\item Notification sent to claimer about approval
|
||
\item Notification sent to other users with matching lost items
|
||
\end{itemize}
|
||
\item If rejected:
|
||
\begin{itemize}
|
||
\item Claim status updated to "rejected"
|
||
\item Item status reverts to "unclaimed" if no other pending claims
|
||
\item Notification sent to claimer with rejection reason
|
||
\end{itemize}
|
||
\item After approval, manager closes case with official handover documentation
|
||
\item System archives item with case closure metadata
|
||
\item Lost item reports marked as "closed"
|
||
\end{enumerate}
|
||
|
||
\subsubsection{Direct Claim Flow}
|
||
|
||
When a finder directly contacts an owner who posted a lost item report:
|
||
|
||
\begin{enumerate}
|
||
\item Finder submits direct claim on lost item report
|
||
\item System creates claim with status "waiting\_owner"
|
||
\item Lost item status updated to "claimed"
|
||
\item Notification sent to owner about potential match
|
||
\item Owner reviews finder's description and evidence
|
||
\item Owner approves or rejects direct claim
|
||
\item If approved:
|
||
\begin{itemize}
|
||
\item Claim status updated to "verified"
|
||
\item Lost item status updated to "found"
|
||
\item Notification sent to finder with contact information
|
||
\item Owner and finder coordinate item return
|
||
\item Owner or finder confirms completion
|
||
\item Lost item status updated to "completed"
|
||
\end{itemize}
|
||
\item If rejected:
|
||
\begin{itemize}
|
||
\item Claim status updated to "rejected"
|
||
\item Lost item status reverts to "active"
|
||
\item Direct claim link removed
|
||
\item Notification sent to finder
|
||
\end{itemize}
|
||
\end{enumerate}
|
||
|
||
\subsection{Automatic Matching Algorithm}
|
||
|
||
The automatic matching system uses string similarity algorithms to identify potential matches between lost items and found items. Figure \ref{fig:matching_algo} illustrates the matching algorithm workflow.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=\columnwidth]{matching_algorithm.png}}
|
||
\caption{Automatic Matching Algorithm Workflow}
|
||
\label{fig:matching_algo}
|
||
\end{figure}
|
||
|
||
\subsubsection{Levenshtein Distance Implementation}
|
||
|
||
The core matching algorithm calculates similarity using the Levenshtein Distance metric, which measures the minimum number of single-character edits (insertions, deletions, substitutions) required to transform one string into another.
|
||
|
||
The implementation uses dynamic programming with a matrix where $dp[i][j]$ represents the edit distance between the first $i$ characters of string $s_1$ and the first $j$ characters of string $s_2$:
|
||
|
||
\begin{equation}
|
||
dp[i][j] = \min \begin{cases}
|
||
dp[i-1][j] + 1 & \text{(deletion)} \\
|
||
dp[i][j-1] + 1 & \text{(insertion)} \\
|
||
dp[i-1][j-1] + cost & \text{(substitution)}
|
||
\end{cases}
|
||
\end{equation}
|
||
|
||
where $cost = 0$ if $s_1[i] = s_2[j]$, otherwise $cost = 1$.
|
||
|
||
The normalized similarity score is calculated as:
|
||
|
||
\begin{equation}
|
||
similarity = 1 - \frac{distance}{\max(len(s_1), len(s_2))}
|
||
\end{equation}
|
||
|
||
This produces a score between 0 and 1, where 1 indicates identical strings and 0 indicates completely different strings.
|
||
|
||
\subsubsection{Text Normalization}
|
||
|
||
Before similarity calculation, both strings undergo normalization:
|
||
|
||
\begin{enumerate}
|
||
\item Convert to lowercase for case-insensitive comparison
|
||
\item Remove special characters and punctuation
|
||
\item Replace multiple spaces with single space
|
||
\item Trim leading and trailing whitespace
|
||
\item Extract keywords by removing stopwords
|
||
\end{enumerate}
|
||
|
||
The stopword list includes common Indonesian and English words ("dan", "atau", "dengan", "the", "a", "an") that do not contribute meaningful information to matching.
|
||
|
||
\subsubsection{Weighted Field Matching}
|
||
|
||
The final match score combines multiple field similarities with configurable weights:
|
||
|
||
\begin{equation}
|
||
score_{final} = (score_{name} \times 0.5) + (score_{description} \times 0.5)
|
||
\end{equation}
|
||
|
||
The name field receives 50\% weight as item names are distinctive identifiers. The description field receives 50\% weight as it contains detailed characteristics.
|
||
|
||
For claims, the algorithm compares claim descriptions against item secret details (if available) or public descriptions (if secret details empty). This prioritizes confidential information during verification.
|
||
|
||
\subsubsection{Match Threshold and Classification}
|
||
|
||
Matches are classified based on similarity score thresholds:
|
||
\begin{itemize}
|
||
\item \textbf{High match}: score $\geq$ 70\%
|
||
\item \textbf{Medium match}: 50\% $\leq$ score $<$ 70\%
|
||
\item \textbf{Low match}: 30\% $\leq$ score $<$ 50\%
|
||
\end{itemize}
|
||
|
||
Only matches scoring above 50\% trigger automatic notifications to users. Matches between 30-50\% are stored but not actively promoted, available for manual review.
|
||
|
||
\subsubsection{Matching Worker Process}
|
||
|
||
The MatchingWorker runs every 30 minutes, executing the following process:
|
||
|
||
\begin{enumerate}
|
||
\item Query all unclaimed items from database
|
||
\item For each item:
|
||
\begin{itemize}
|
||
\item Query active lost items in same category
|
||
\item Calculate similarity score for each lost item
|
||
\item Filter matches above threshold (50\%)
|
||
\item Check if match already exists in database
|
||
\item Create new match records for novel matches
|
||
\item Store matched fields as JSON for debugging
|
||
\item Mark matches as unnotified
|
||
\end{itemize}
|
||
\item NotificationWorker processes unnotified matches
|
||
\item Users receive notifications about potential matches
|
||
\end{enumerate}
|
||
|
||
\subsection{Authentication and Security}
|
||
|
||
The system implements multiple security layers to protect user data and prevent unauthorized access.
|
||
|
||
\subsubsection{JWT-Based Authentication}
|
||
|
||
Authentication uses JSON Web Tokens (JWT) with the following characteristics:
|
||
|
||
\begin{itemize}
|
||
\item \textbf{Algorithm}: HMAC-SHA256 for token signing
|
||
\item \textbf{Expiration}: 7 days for standard tokens, 30 days for refresh tokens
|
||
\item \textbf{Claims}: User ID, email, role name, issued time, expiration time
|
||
\item \textbf{Secret Key}: Stored securely as environment variable
|
||
\end{itemize}
|
||
|
||
The authentication flow:
|
||
|
||
\begin{enumerate}
|
||
\item User submits credentials to \texttt{/api/login}
|
||
\item System validates email and password hash
|
||
\item System checks user status (active vs blocked)
|
||
\item System loads user role and permissions
|
||
\item System generates JWT with user claims
|
||
\item Token returned to client in response
|
||
\item Client stores token in localStorage or memory
|
||
\item Client includes token in Authorization header for subsequent requests
|
||
\item Server validates token signature and expiration
|
||
\item Server loads user from database if token valid
|
||
\item Server denies access if token invalid or expired
|
||
\end{enumerate}
|
||
|
||
\subsubsection{Password Security}
|
||
|
||
User passwords undergo secure hashing using bcrypt:
|
||
|
||
\begin{itemize}
|
||
\item \textbf{Algorithm}: bcrypt with adaptive cost factor
|
||
\item \textbf{Work Factor}: Cost of 10 (1024 iterations)
|
||
\item \textbf{Salt}: Unique random salt per password
|
||
\item \textbf{Hash Length}: 60-character output
|
||
\end{itemize}
|
||
|
||
The adaptive cost factor allows the hash difficulty to increase over time as computing power advances, maintaining resistance to brute-force attacks.
|
||
|
||
\subsubsection{Data Encryption}
|
||
|
||
Sensitive personal information (NRP, phone numbers) is encrypted at rest using AES-256-GCM:
|
||
|
||
\begin{itemize}
|
||
\item \textbf{Algorithm}: AES-256 in GCM (Galois/Counter Mode)
|
||
\item \textbf{Key Size}: 256 bits (32 bytes)
|
||
\item \textbf{Authentication}: GCM provides both encryption and authentication
|
||
\item \textbf{Nonce}: Unique random nonce per encryption
|
||
\item \textbf{Storage}: Encrypted values stored as Base64 strings
|
||
\end{itemize}
|
||
|
||
The encryption key is loaded from environment variables during initialization and never logged or exposed through APIs.
|
||
|
||
\subsubsection{Role-Based Access Control}
|
||
|
||
The permission system implements fine-grained access control through permission slugs:
|
||
|
||
\begin{itemize}
|
||
\item \texttt{item:create}: Create found items
|
||
\item \texttt{item:read}: View item details
|
||
\item \texttt{item:update}: Modify item information
|
||
\item \texttt{item:delete}: Delete items
|
||
\item \texttt{item:verify}: Verify claims
|
||
\item \texttt{claim:create}: Submit claims
|
||
\item \texttt{claim:read}: View claims
|
||
\item \texttt{claim:approve}: Approve or reject claims
|
||
\item \texttt{user:read}: View user lists
|
||
\item \texttt{user:update}: Modify user details
|
||
\item \texttt{user:block}: Block or unblock users
|
||
\item \texttt{report:export}: Export system reports
|
||
\end{itemize}
|
||
|
||
Permissions are checked at the middleware layer before requests reach controllers, preventing unauthorized access at the earliest possible point.
|
||
|
||
\subsection{AI Chatbot Integration}
|
||
|
||
The AI chatbot provides interactive assistance using the Groq API with the LLaMA 3.3 70B Versatile model.
|
||
|
||
\subsubsection{Intent Detection}
|
||
|
||
The system analyzes user messages to detect intent before generating responses:
|
||
|
||
\begin{itemize}
|
||
\item \textbf{search\_item}: Keywords like "cari", "temukan", "ada", "lihat"
|
||
\item \textbf{report\_lost}: Keywords like "hilang", "kehilangan", "lapor"
|
||
\item \textbf{claim\_help}: Keywords like "klaim", "ambil", "punya saya"
|
||
\item \textbf{general}: Default for unmatched patterns
|
||
\end{itemize}
|
||
|
||
Intent detection enables context-appropriate responses and guides the AI to provide relevant information.
|
||
|
||
\subsubsection{Context Building}
|
||
|
||
For each chat request, the system builds rich context:
|
||
|
||
\begin{enumerate}
|
||
\item Query user's lost item reports (last 5)
|
||
\item Search relevant found items based on message keywords
|
||
\item Extract match results for user's lost items
|
||
\item Format context as structured text
|
||
\item Include context in system prompt
|
||
\end{enumerate}
|
||
|
||
Example context structure:
|
||
\begin{verbatim}
|
||
<EFBFBD><EFBFBD> Barang yang dilaporkan hilang:
|
||
- Dompet Kulit (Accessories) - Status: active
|
||
- Kunci Motor Honda (Keys) - Status: active
|
||
|
||
<EFBFBD><EFBFBD> Barang ditemukan yang relevan:
|
||
- ID: 123, Dompet (Wallet) - Lokasi: Perpustakaan
|
||
- ID: 124, Dompet Hitam (Wallet) - Lokasi: Kantin
|
||
\end{verbatim}
|
||
|
||
\subsubsection{AI Response Generation}
|
||
|
||
The Groq API receives two prompts:
|
||
|
||
\textbf{System Prompt:}
|
||
Defines the AI's role, capabilities, response format, and behavioral guidelines. Instructs the AI to act as "FindItBot", a campus lost and found assistant, using Indonesian language, emoji for clarity, and structured responses with item IDs.
|
||
|
||
\textbf{User Prompt:}
|
||
Contains the user's message, detected intent, and built context. Structured as:
|
||
\begin{verbatim}
|
||
KONTEKS PENGGUNA:
|
||
[user context here]
|
||
|
||
INTENT TERDETEKSI: search_item
|
||
|
||
PERTANYAAN: Apakah ada dompet yang ditemukan?
|
||
\end{verbatim}
|
||
|
||
The Groq API returns a conversational response that references specific items by ID and provides actionable guidance.
|
||
|
||
\subsubsection{Chat History Management}
|
||
|
||
Conversation history is persisted in the database:
|
||
\begin{itemize}
|
||
\item Each message-response pair stored as record
|
||
\item User can retrieve last N messages
|
||
\item Intent and confidence score logged for analysis
|
||
\item Context data stored as JSON for debugging
|
||
\item History can be cleared by user
|
||
\end{itemize}
|
||
|
||
\subsection{Background Workers Implementation}
|
||
|
||
Background workers implement scheduled and periodic tasks using Go's concurrency primitives.
|
||
|
||
\subsubsection{Expire Worker Architecture}
|
||
|
||
The ExpireWorker implements a worker pool pattern with 5 concurrent workers:
|
||
|
||
\begin{enumerate}
|
||
\item Main goroutine runs periodic timer (1 hour interval)
|
||
\item Timer triggers item expiration check
|
||
\item System queries items past 90-day retention
|
||
\item Items dispatched to buffered task channel (capacity 100)
|
||
\item Worker goroutines consume tasks from channel
|
||
\item Each worker processes one item in transaction:
|
||
\begin{itemize}
|
||
\item Acquire pessimistic lock on item
|
||
\item Verify item still unclaimed
|
||
\item Create archive record
|
||
\item Update item status to expired
|
||
\item Create audit log entry
|
||
\item Commit transaction
|
||
\end{itemize}
|
||
\item Worker pool provides controlled concurrency
|
||
\item Main goroutine tracks completion with WaitGroup
|
||
\end{enumerate}
|
||
|
||
The worker pool pattern prevents resource exhaustion while maximizing throughput. Buffered channels provide backpressure if workers cannot keep pace with task generation.
|
||
|
||
\subsubsection{Graceful Shutdown}
|
||
|
||
All workers implement graceful shutdown:
|
||
|
||
\begin{enumerate}
|
||
\item Main program receives SIGINT or SIGTERM signal
|
||
\item Shutdown signal sent to all worker stop channels
|
||
\item Workers stop accepting new tasks
|
||
\item Workers complete in-progress tasks
|
||
\item WaitGroups block until all workers finished
|
||
\item Database connections closed
|
||
\item HTTP server stops accepting requests
|
||
\item In-flight HTTP requests complete
|
||
\item Program exits cleanly
|
||
\end{enumerate}
|
||
|
||
Graceful shutdown ensures data consistency and prevents corruption from interrupted operations. The system enforces a 30-second shutdown timeout, after which forceful termination occurs.
|
||
|
||
\subsection{Error Handling and Logging}
|
||
|
||
The system implements comprehensive error handling and structured logging.
|
||
|
||
\subsubsection{Error Response Format}
|
||
|
||
All API errors return consistent JSON structure:
|
||
\begin{verbatim}
|
||
{
|
||
"success": false,
|
||
"message": "User-facing error message",
|
||
"error": "Technical error details",
|
||
"timestamp": "2025-01-15T10:30:00Z"
|
||
}
|
||
\end{verbatim}
|
||
|
||
HTTP status codes follow REST conventions:
|
||
\begin{itemize}
|
||
\item 200: Success
|
||
\item 201: Created
|
||
\item 400: Bad Request (invalid input)
|
||
\item 401: Unauthorized (invalid/missing token)
|
||
\item 403: Forbidden (insufficient permissions)
|
||
\item 404: Not Found
|
||
\item 409: Conflict (duplicate entry)
|
||
\item 500: Internal Server Error
|
||
\end{itemize}
|
||
|
||
\subsubsection{Structured Logging}
|
||
|
||
The system uses Zap for structured, high-performance logging:
|
||
|
||
\begin{itemize}
|
||
\item Production mode: JSON format, Info level
|
||
\item Development mode: Console format, Debug level
|
||
\item Log fields: timestamp, level, message, caller, stack trace
|
||
\item Context fields: user\_id, ip\_address, request\_id
|
||
\end{itemize}
|
||
|
||
Critical events logged include:
|
||
\begin{itemize}
|
||
\item Authentication attempts (success/failure)
|
||
\item Permission denials
|
||
\item Database transaction failures
|
||
\item Background worker execution
|
||
\item API errors and panics
|
||
\item System startup/shutdown
|
||
\end{itemize}
|
||
|
||
\subsection{Testing and Quality Assurance}
|
||
|
||
The layered architecture facilitates comprehensive testing at multiple levels.
|
||
|
||
\subsubsection{Unit Testing}
|
||
|
||
Unit tests verify individual components in isolation:
|
||
\begin{itemize}
|
||
\item Service layer tests with mock repositories
|
||
\item Utility function tests (similarity algorithm, encryption)
|
||
\item Middleware tests with mock HTTP contexts
|
||
\item Model method tests (validation, state transitions)
|
||
\end{itemize}
|
||
|
||
Mock implementations of repository interfaces enable service testing without database dependencies.
|
||
|
||
\subsubsection{Integration Testing}
|
||
|
||
Integration tests verify component interactions:
|
||
\begin{itemize}
|
||
\item API endpoint tests with test database
|
||
\item Service + repository tests with transactions
|
||
\item Authentication flow tests
|
||
\item Worker execution tests
|
||
\end{itemize}
|
||
|
||
Integration tests use test fixtures and database transactions that rollback after each test, maintaining test isolation.
|
||
|
||
\subsubsection{Load Testing}
|
||
|
||
Load tests verify system performance under stress:
|
||
\begin{itemize}
|
||
\item Concurrent user simulation
|
||
\item API endpoint throughput measurement
|
||
\item Database connection pool sizing
|
||
\item Worker queue capacity testing
|
||
\end{itemize}
|
||
|
||
Performance targets include:
|
||
\begin{itemize}
|
||
\item Item query: $<$ 100ms (p95)
|
||
\item Claim submission: $<$ 500ms (p95)
|
||
\item Matching calculation: $<$ 2s for 1000 items
|
||
\item Concurrent users: 100 simultaneous
|
||
\end{itemize}
|
||
|
||
\subsection{Deployment Architecture}
|
||
|
||
The system supports deployment in containerized and traditional server environments.
|
||
|
||
\subsection{Configuration Management}
|
||
|
||
The system uses environment-based configuration to support multiple deployment scenarios. Configuration parameters are loaded from environment variables with sensible defaults:
|
||
|
||
\begin{itemize}
|
||
\item \textbf{Database Configuration}: Host, port, username, password, database name, character set, and connection pooling parameters.
|
||
\item \textbf{Server Configuration}: Port number, environment mode (development/production), upload path, maximum file size, and allowed CORS origins.
|
||
\item \textbf{JWT Configuration}: Secret key, token expiration time, and refresh token lifetime.
|
||
\item \textbf{Groq API Configuration}: API key, model selection (default: llama-3.3-70b-versatile), max tokens, temperature, and top-p parameters.
|
||
\item \textbf{Encryption Configuration}: AES-256-GCM encryption key for sensitive data protection.
|
||
\end{itemize}
|
||
|
||
The configuration loader (\texttt{config.go}) provides accessor functions that retrieve values from environment variables with fallback defaults. This enables seamless deployment across development, staging, and production environments without code changes.
|
||
|
||
\subsection{Security Implementation}
|
||
|
||
The system implements defense-in-depth security with multiple protective layers.
|
||
|
||
\subsubsection{Authentication Flow}
|
||
|
||
User authentication follows a secure token-based flow:
|
||
|
||
\begin{enumerate}
|
||
\item User submits credentials via \texttt{POST /api/login}
|
||
\item \texttt{AuthController} validates input format
|
||
\item \texttt{AuthService} retrieves user from database
|
||
\item Password hash verified using bcrypt with cost factor 10
|
||
\item User status checked (active vs blocked)
|
||
\item JWT generated with user claims (ID, email, role)
|
||
\item Token signed with HMAC-SHA256
|
||
\item Token and user data returned to client
|
||
\item Client stores token (localStorage or memory)
|
||
\item Subsequent requests include token in Authorization header
|
||
\item \texttt{JWTMiddleware} validates token on each request
|
||
\end{enumerate}
|
||
|
||
Token refresh is supported through \texttt{POST /api/refresh-token}, which validates the existing token and issues a new one with extended expiration, maintaining session continuity without requiring re-authentication.
|
||
|
||
\subsubsection{Input Validation}
|
||
|
||
All API endpoints implement comprehensive input validation using Gin's binding framework. Validation rules include:
|
||
|
||
\begin{itemize}
|
||
\item \textbf{Required fields}: \texttt{binding:"required"} tag ensures mandatory data presence
|
||
\item \textbf{Format validation}: Email addresses validated with RFC 5322 regex
|
||
\item \textbf{Length constraints}: Minimum password length of 6 characters
|
||
\item \textbf{Type safety}: Automatic conversion and validation of numeric types
|
||
\item \textbf{Enum validation}: Status fields restricted to predefined constants
|
||
\item \textbf{Date validation}: Timestamps validated and normalized to UTC
|
||
\end{itemize}
|
||
|
||
Invalid requests return 400 Bad Request with detailed error messages identifying the specific validation failures, enabling client-side correction.
|
||
|
||
\subsubsection{SQL Injection Prevention}
|
||
|
||
GORM's parameterized queries prevent SQL injection attacks. All database operations use prepared statements with bound parameters:
|
||
|
||
\begin{verbatim}
|
||
db.Where("email = ?", email).First(&user)
|
||
\end{verbatim}
|
||
|
||
The \texttt{?} placeholder is replaced with a properly escaped parameter value, preventing malicious SQL from being executed. Raw SQL queries are avoided throughout the codebase.
|
||
|
||
\subsubsection{XSS Protection}
|
||
|
||
Cross-site scripting (XSS) attacks are mitigated through multiple mechanisms:
|
||
|
||
\begin{itemize}
|
||
\item Content-Type headers set to \texttt{application/json}
|
||
\item HTML special characters escaped in all outputs
|
||
\item No dynamic HTML generation on server side
|
||
\item Frontend implements Content Security Policy (CSP)
|
||
\item User-generated content sanitized before display
|
||
\end{itemize}
|
||
|
||
\subsection{File Upload System}
|
||
|
||
The file upload system enables users to attach photos to items and claims while ensuring security and performance.
|
||
|
||
\subsubsection{Upload Controller Implementation}
|
||
|
||
The \texttt{UploadController} handles multiple upload scenarios:
|
||
|
||
\begin{itemize}
|
||
\item \textbf{Single item image}: \texttt{POST /api/upload/item-image}
|
||
\item \textbf{Claim proof}: \texttt{POST /api/upload/claim-proof}
|
||
\item \textbf{Multiple images}: \texttt{POST /api/upload/multiple}
|
||
\item \textbf{Image deletion}: \texttt{DELETE /api/upload/delete}
|
||
\item \textbf{Image metadata}: \texttt{GET /api/upload/info}
|
||
\end{itemize}
|
||
|
||
Upload validation includes:
|
||
\begin{itemize}
|
||
\item Maximum file size: 10 MB per file
|
||
\item Allowed MIME types: image/jpeg, image/png, image/gif
|
||
\item File extension verification
|
||
\item Magic number validation to prevent disguised files
|
||
\item Filename sanitization to prevent directory traversal
|
||
\end{itemize}
|
||
|
||
\subsubsection{Storage Strategy}
|
||
|
||
Files are stored in the local filesystem under \texttt{./uploads} with organized subdirectories:
|
||
|
||
\begin{verbatim}
|
||
uploads/
|
||
items/ # Found item photos
|
||
claims/ # Claim proof documents
|
||
lost_items/ # Lost item reference photos
|
||
temp/ # Temporary uploads
|
||
\end{verbatim}
|
||
|
||
Each file is renamed to a UUID to prevent name collisions and information leakage. The database stores the file path as a URL-accessible reference.
|
||
|
||
\subsection{API Response Standardization}
|
||
|
||
All API responses follow a consistent JSON structure, enabling predictable client-side handling.
|
||
|
||
\subsubsection{Success Response Format}
|
||
|
||
Successful operations return:
|
||
\begin{verbatim}
|
||
{
|
||
"success": true,
|
||
"message": "Operation completed successfully",
|
||
"data": { ... },
|
||
"timestamp": "2025-01-15T10:30:00Z"
|
||
}
|
||
\end{verbatim}
|
||
|
||
\subsubsection{Error Response Format}
|
||
|
||
Failed operations return:
|
||
\begin{verbatim}
|
||
{
|
||
"success": false,
|
||
"message": "User-friendly error message",
|
||
"error": "Technical error details",
|
||
"timestamp": "2025-01-15T10:30:00Z"
|
||
}
|
||
\end{verbatim}
|
||
|
||
\subsubsection{Pagination Response Format}
|
||
|
||
Paginated endpoints return:
|
||
\begin{verbatim}
|
||
{
|
||
"success": true,
|
||
"data": [...],
|
||
"pagination": {
|
||
"page": 1,
|
||
"limit": 20,
|
||
"total": 157,
|
||
"pages": 8
|
||
}
|
||
}
|
||
\end{verbatim}
|
||
|
||
Utility functions in \texttt{utils/response.go} ensure consistent formatting across all controllers.
|
||
|
||
\subsection{Performance Optimization}
|
||
|
||
The system implements several optimizations to ensure responsive performance under load.
|
||
|
||
\subsubsection{Database Query Optimization}
|
||
|
||
Query performance is optimized through:
|
||
|
||
\begin{itemize}
|
||
\item \textbf{Strategic Indexes}: All foreign keys, status fields, and commonly searched columns have indexes
|
||
\item \textbf{Selective Preloading}: Related entities loaded only when needed using GORM's \texttt{Preload} directives
|
||
\item \textbf{Query Result Limiting}: All list endpoints enforce pagination with configurable limits
|
||
\item \textbf{Covering Indexes}: Composite indexes on frequently combined filters (status + date)
|
||
\item \textbf{Connection Pooling}: Database connection pool sized for expected concurrent users (max 100 connections)
|
||
\end{itemize}
|
||
|
||
\subsubsection{Caching Strategy}
|
||
|
||
While the current implementation prioritizes data consistency over caching, future optimizations could include:
|
||
|
||
\begin{itemize}
|
||
\item Category list caching (rarely changes)
|
||
\item User role and permission caching
|
||
\item Recent items list caching with short TTL
|
||
\item Redis-based session storage
|
||
\end{itemize}
|
||
|
||
\subsubsection{Concurrency Control}
|
||
|
||
Go's goroutines enable efficient concurrent processing:
|
||
|
||
\begin{itemize}
|
||
\item Background workers run concurrently without blocking API requests
|
||
\item Worker pool pattern limits resource consumption
|
||
\item Buffered channels provide backpressure handling
|
||
\item Context timeouts prevent hung operations
|
||
\item Pessimistic database locking prevents race conditions
|
||
\end{itemize}
|
||
|
||
\subsection{Monitoring and Observability}
|
||
|
||
The system includes comprehensive logging and monitoring capabilities.
|
||
|
||
\subsubsection{Structured Logging}
|
||
|
||
Zap structured logger provides high-performance logging with:
|
||
|
||
\begin{itemize}
|
||
\item JSON format in production for log aggregation
|
||
\item Console format in development for readability
|
||
\item Log levels: Debug, Info, Warn, Error, Fatal
|
||
\item Contextual fields: user\_id, request\_id, timestamp
|
||
\item Automatic stack trace capture for errors
|
||
\item Log rotation and retention policies
|
||
\end{itemize}
|
||
|
||
Critical events logged include:
|
||
\begin{itemize}
|
||
\item All authentication attempts (success/failure)
|
||
\item Permission denials
|
||
\item Database transaction failures
|
||
\item Background worker execution
|
||
\item API errors and panics
|
||
\item System startup and shutdown
|
||
\end{itemize}
|
||
|
||
\subsubsection{Audit Trail}
|
||
|
||
The \texttt{audit\_logs} table provides comprehensive activity tracking:
|
||
|
||
\begin{itemize}
|
||
\item User ID and timestamp for all actions
|
||
\item Action type (create, update, delete, approve, etc.)
|
||
\item Entity type and ID affected
|
||
\item Detailed description of changes
|
||
\item IP address and user agent for forensics
|
||
\item Soft-deleted for data retention compliance
|
||
\end{itemize}
|
||
|
||
Audit logs support:
|
||
\begin{itemize}
|
||
\item Compliance requirements and security investigations
|
||
\item User activity reports and analytics
|
||
\item Debugging and troubleshooting
|
||
\item Rollback identification
|
||
\end{itemize}
|
||
|
||
\subsubsection{Health Checks}
|
||
|
||
The system exposes health check endpoints for monitoring:
|
||
|
||
\begin{itemize}
|
||
\item Database connectivity verification
|
||
\item Background worker status
|
||
\item Disk space availability
|
||
\item Memory usage metrics
|
||
\end{itemize}
|
||
|
||
\subsection{Deployment Architecture}
|
||
|
||
\subsubsection{Docker Containerization}
|
||
|
||
The application is containerized using Docker for consistent deployment:
|
||
|
||
\begin{verbatim}
|
||
FROM golang:1.21-alpine AS builder
|
||
WORKDIR /app
|
||
COPY go.mod go.sum ./
|
||
RUN go mod download
|
||
COPY . .
|
||
RUN go build -o main cmd/server/main.go
|
||
|
||
FROM alpine:latest
|
||
RUN apk --no-cache add ca-certificates
|
||
WORKDIR /root/
|
||
COPY --from=builder /app/main .
|
||
COPY --from=builder /app/web ./web
|
||
EXPOSE 8080
|
||
CMD ["./main"]
|
||
\end{verbatim}
|
||
|
||
Docker Compose orchestrates the multi-container deployment:
|
||
|
||
\begin{verbatim}
|
||
version: '3.8'
|
||
services:
|
||
app:
|
||
build: .
|
||
ports:
|
||
- "8080:8080"
|
||
environment:
|
||
- DB_HOST=db
|
||
- DB_PORT=3306
|
||
depends_on:
|
||
- db
|
||
db:
|
||
image: mysql:8.0
|
||
environment:
|
||
- MYSQL_ROOT_PASSWORD=secret
|
||
- MYSQL_DATABASE=lostfound
|
||
volumes:
|
||
- db_data:/var/lib/mysql
|
||
volumes:
|
||
db_data:
|
||
\end{verbatim}
|
||
|
||
\subsubsection{Environment Management}
|
||
|
||
Different environments use separate configuration files:
|
||
|
||
\begin{itemize}
|
||
\item \texttt{.env.development}: Local development settings
|
||
\item \texttt{.env.staging}: Pre-production testing
|
||
\item \texttt{.env.production}: Production deployment
|
||
\end{itemize}
|
||
|
||
Sensitive credentials are never committed to version control and are injected at deployment time through environment variables or secrets management systems.
|
||
|
||
\subsubsection{Database Migration Strategy}
|
||
|
||
Database schema changes are managed through SQL migration files:
|
||
|
||
\begin{enumerate}
|
||
\item \texttt{schema.sql}: Initial table creation
|
||
\item \texttt{seed.sql}: Default data insertion
|
||
\item \texttt{enhancement.sql}: Stored procedures and triggers
|
||
\item \texttt{migration\_*.sql}: Incremental changes
|
||
\end{enumerate}
|
||
|
||
The migration system:
|
||
\begin{itemize}
|
||
\item Detects existing schema to prevent duplicates
|
||
\item Executes migrations in order
|
||
\item Logs all migration activities
|
||
\item Supports rollback through versioning
|
||
\item Handles delimiter-based stored procedures
|
||
\end{itemize}
|
||
|
||
\subsection{Code Organization and Maintainability}
|
||
|
||
The codebase follows Go best practices and design patterns for long-term maintainability.
|
||
|
||
\subsubsection{Package Structure}
|
||
|
||
The project is organized into focused packages:
|
||
|
||
\begin{verbatim}
|
||
lost-and-found/
|
||
├── cmd/server/ # Application entry point
|
||
├── internal/
|
||
│ ├── config/ # Configuration management
|
||
│ ├── controllers/ # HTTP request handlers
|
||
│ ├── middleware/ # HTTP middleware
|
||
│ ├── models/ # Data models
|
||
│ ├── repositories/ # Data access layer
|
||
│ ├── routes/ # Route definitions
|
||
│ ├── services/ # Business logic
|
||
│ ├── utils/ # Utility functions
|
||
│ └── workers/ # Background workers
|
||
├── database/ # SQL migration files
|
||
├── web/ # Frontend static files
|
||
└── uploads/ # User-uploaded files
|
||
\end{verbatim}
|
||
|
||
\subsubsection{Dependency Injection}
|
||
|
||
Controllers and services receive dependencies through constructor injection:
|
||
|
||
\begin{verbatim}
|
||
type ItemController struct {
|
||
db *gorm.DB
|
||
service *services.ItemService
|
||
}
|
||
|
||
func NewItemController(db *gorm.DB) *ItemController {
|
||
return &ItemController{
|
||
db: db,
|
||
service: services.NewItemService(db),
|
||
}
|
||
}
|
||
\end{verbatim}
|
||
|
||
This approach enables:
|
||
\begin{itemize}
|
||
\item Easy testing with mock dependencies
|
||
\item Clear dependency relationships
|
||
\item Loose coupling between components
|
||
\item Simplified dependency management
|
||
\end{itemize}
|
||
|
||
\subsubsection{Error Handling}
|
||
|
||
Go's explicit error handling is used consistently:
|
||
|
||
\begin{verbatim}
|
||
item, err := s.itemRepo.FindByID(itemID)
|
||
if err != nil {
|
||
if errors.Is(err, gorm.ErrRecordNotFound) {
|
||
return nil, errors.New("item not found")
|
||
}
|
||
return nil, fmt.Errorf("database error: %w", err)
|
||
}
|
||
\end{verbatim}
|
||
|
||
Errors are:
|
||
\begin{itemize}
|
||
\item Wrapped with context using \texttt{fmt.Errorf}
|
||
\item Checked at every function boundary
|
||
\item Logged with appropriate severity
|
||
\item Translated to user-friendly messages
|
||
\item Never silently ignored
|
||
\end{itemize}
|
||
|
||
\subsection{Testing Strategy}
|
||
|
||
The system employs comprehensive testing at multiple levels.
|
||
|
||
\subsubsection{Unit Tests}
|
||
|
||
Unit tests verify individual components in isolation:
|
||
|
||
\begin{itemize}
|
||
\item Service layer tests with mock repositories
|
||
\item Utility function tests (similarity algorithm, encryption)
|
||
\item Model method tests (validation, state transitions)
|
||
\item Middleware tests with mock HTTP contexts
|
||
\end{itemize}
|
||
|
||
Test coverage targets 80\% for critical business logic.
|
||
|
||
\subsubsection{Integration Tests}
|
||
|
||
Integration tests verify component interactions:
|
||
|
||
\begin{itemize}
|
||
\item API endpoint tests with test database
|
||
\item Service + repository integration tests
|
||
\item Authentication flow tests
|
||
\item Background worker execution tests
|
||
\end{itemize}
|
||
|
||
Integration tests use database transactions that rollback after completion, maintaining test isolation and repeatability.
|
||
|
||
\subsubsection{Performance Tests}
|
||
|
||
Load tests verify system performance under stress:
|
||
|
||
\begin{itemize}
|
||
\item Concurrent user simulation (100+ users)
|
||
\item API endpoint throughput measurement
|
||
\item Database query performance profiling
|
||
\item Worker queue capacity testing
|
||
\end{itemize}
|
||
|
||
Performance targets are established and monitored:
|
||
\begin{itemize}
|
||
\item Item query response time: < 100ms (p95)
|
||
\item Claim submission: < 500ms (p95)
|
||
\item Matching calculation: < 2 seconds for 1000 items
|
||
\item Concurrent users supported: 100+
|
||
\end{itemize}
|
||
|
||
\section{Results and Analysis}
|
||
|
||
This chapter presents the comprehensive results of the Lost and Found System implementation, including system functionality demonstration, user interface implementation, performance testing results, algorithm effectiveness analysis, and system evaluation through various testing scenarios.
|
||
|
||
\subsection{System Implementation Overview}
|
||
|
||
The Lost and Found System has been successfully implemented using modern web technologies with a microservices-oriented architecture. The implementation consists of a Go-based backend REST API, a React-based frontend single-page application, and MySQL database with comprehensive data management features.
|
||
|
||
\subsubsection{Technology Stack Implementation}
|
||
|
||
The complete technology stack has been successfully integrated:
|
||
|
||
\textbf{Backend Implementation:}
|
||
\begin{itemize}
|
||
\item \textbf{Core Framework:} Go (Golang) 1.21 with Gin web framework for HTTP routing and middleware
|
||
\item \textbf{Database:} MySQL 8.0 with GORM ORM for type-safe database operations
|
||
\item \textbf{Authentication:} JWT (JSON Web Tokens) with HMAC-SHA256 signing
|
||
\item \textbf{Security:} bcrypt password hashing (cost factor 10), AES-256-GCM encryption for sensitive data
|
||
\item \textbf{Background Processing:} Goroutines and worker pools for concurrent task execution
|
||
\item \textbf{Logging:} Zap structured logger with JSON output in production
|
||
\item \textbf{AI Integration:} Groq API with LLaMA 3.3 70B Versatile model
|
||
\end{itemize}
|
||
|
||
\textbf{Frontend Implementation:}
|
||
\begin{itemize}
|
||
\item \textbf{UI Framework:} React 18 with hooks-based component architecture
|
||
\item \textbf{Styling:} Tailwind CSS 3.0 with custom gradient and animation classes
|
||
\item \textbf{State Management:} React Context API and custom hooks for state management
|
||
\item \textbf{API Communication:} Fetch API with centralized error handling
|
||
\item \textbf{Build System:} Babel standalone for in-browser JSX transformation (development), can be compiled for production
|
||
\end{itemize}
|
||
|
||
\subsubsection{API Endpoint Implementation Status}
|
||
|
||
All planned API endpoints have been successfully implemented and tested. Table \ref{tab:api_endpoints} summarizes the implemented endpoints organized by functional domain.
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Implemented API Endpoints}
|
||
\begin{center}
|
||
\begin{tabular}{|l|l|l|}
|
||
\hline
|
||
\textbf{Domain} & \textbf{Endpoint} & \textbf{Method} \\
|
||
\hline
|
||
Authentication & /api/auth/register & POST \\
|
||
& /api/auth/login & POST \\
|
||
& /api/auth/refresh-token & POST \\
|
||
& /api/auth/me & GET \\
|
||
\hline
|
||
Items & /api/items & GET, POST \\
|
||
& /api/items/:id & GET, PUT, DELETE \\
|
||
& /api/items/my-items & GET \\
|
||
& /api/items/:id/revisions & GET \\
|
||
\hline
|
||
Lost Items & /api/lost-items & GET, POST \\
|
||
& /api/lost-items/:id & GET, PUT, DELETE \\
|
||
& /api/lost-items/my-items & GET \\
|
||
\hline
|
||
Claims & /api/claims & GET, POST \\
|
||
& /api/claims/:id & GET, PUT, DELETE \\
|
||
& /api/claims/:id/verify & POST \\
|
||
& /api/claims/:id/close-case & POST \\
|
||
& /api/claims/:id/reopen & POST \\
|
||
& /api/claims/:id/user-respond & POST \\
|
||
\hline
|
||
Matching & /api/matches/lost-item/:id & GET \\
|
||
& /api/matches/item/:id & GET \\
|
||
& /api/matches/find-similar/:id & GET \\
|
||
\hline
|
||
AI Chatbot & /api/ai/chat & POST \\
|
||
& /api/ai/history & GET, DELETE \\
|
||
\hline
|
||
Admin & /api/admin/users & GET \\
|
||
& /api/admin/users/:id & PUT, DELETE \\
|
||
& /api/admin/categories & GET, POST, PUT, DELETE \\
|
||
& /api/admin/archives & GET \\
|
||
& /api/admin/audit-logs & GET \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:api_endpoints}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\subsection{User Interface Implementation}
|
||
|
||
The system implements role-specific interfaces optimized for different user types: public visitors, authenticated users, managers, and administrators. Each interface is designed with modern UI/UX principles including responsive design, gradient backgrounds, smooth animations, and intuitive navigation.
|
||
|
||
\subsubsection{Homepage Interface}
|
||
|
||
The landing page serves as the entry point for all visitors, showcasing the system's key features and providing clear call-to-action buttons for registration and login. Figure \ref{fig:homepage} shows the homepage interface.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=\columnwidth]{homepage_screenshot.png}}
|
||
\caption{Lost and Found System Homepage}
|
||
\label{fig:homepage}
|
||
\end{figure}
|
||
|
||
\textbf{Key Features of Homepage:}
|
||
\begin{itemize}
|
||
\item \textbf{Hero Section:} Gradient header with animated fade-in effect displaying system title and tagline
|
||
\item \textbf{Feature Cards:} Four prominent cards highlighting core functionality:
|
||
\begin{itemize}
|
||
\item Report Lost Items (<28><>)
|
||
\item Browse Found Items (<28><>)
|
||
\item Claim Processing (<28><>)
|
||
\item Auto-Matching Algorithm (⚡)
|
||
\end{itemize}
|
||
\item \textbf{Statistics Display:} Animated counters showing system usage:
|
||
\begin{itemize}
|
||
\item 127 items found and registered
|
||
\item 89 items successfully claimed
|
||
\item 234 registered users
|
||
\end{itemize}
|
||
\item \textbf{Call-to-Action Buttons:} Prominent "Login" and "Register" buttons with gradient styling and hover effects
|
||
\item \textbf{Responsive Design:} Grid layout adapts to mobile (1 column), tablet (2 columns), and desktop (4 columns)
|
||
\end{itemize}
|
||
|
||
The homepage uses Tailwind CSS gradient classes (bg-gradient-to-br from-slate-900 via-blue-900 to-slate-900) creating a professional dark theme consistent throughout the application.
|
||
|
||
\subsubsection{Authentication Interfaces}
|
||
|
||
The authentication system provides secure login and registration flows with comprehensive input validation and user feedback.
|
||
|
||
\textbf{Login Page Implementation:}
|
||
|
||
Figure \ref{fig:login} displays the login interface with its key components.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=0.7\columnwidth]{login_screenshot.png}}
|
||
\caption{Login Page Interface}
|
||
\label{fig:login}
|
||
\end{figure}
|
||
|
||
The login page implements:
|
||
\begin{itemize}
|
||
\item Email and password input fields with validation
|
||
\item Real-time error display for invalid credentials
|
||
\item Loading state with animated spinner during authentication
|
||
\item "Remember me" functionality through JWT token persistence
|
||
\item Link to registration page for new users
|
||
\item Responsive card layout with gradient header
|
||
\end{itemize}
|
||
|
||
\textbf{Registration Page Implementation:}
|
||
|
||
Figure \ref{fig:register} shows the registration form with comprehensive input fields.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=0.7\columnwidth]{register_screenshot.png}}
|
||
\caption{Registration Page Interface}
|
||
\label{fig:register}
|
||
\end{figure}
|
||
|
||
Registration features include:
|
||
\begin{itemize}
|
||
\item Six input fields: Name, Email, NRP (Student ID), Phone, Password, Confirm Password
|
||
\item Real-time password strength indicator with three levels:
|
||
\begin{itemize}
|
||
\item Weak (⚠️): Password less than 6 characters
|
||
\item Medium (✔️): Password 6-10 characters with basic complexity
|
||
\item Strong (✅): Password 10+ characters with mixed case, numbers, symbols
|
||
\end{itemize}
|
||
\item Client-side validation with error messages:
|
||
\begin{itemize}
|
||
\item Email format validation using RFC 5322 regex
|
||
\item NRP format validation (10 digits)
|
||
\item Phone number format validation
|
||
\item Password confirmation matching
|
||
\end{itemize}
|
||
\item Loading state preventing duplicate submissions
|
||
\item Success redirect to role-appropriate dashboard
|
||
\end{itemize}
|
||
|
||
\subsubsection{User Dashboard Interface}
|
||
|
||
The user dashboard provides comprehensive functionality for regular users to browse found items, report lost items, submit claims, and manage their activities. Figure \ref{fig:user_dashboard} displays the user interface.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=\columnwidth]{user_dashboard_screenshot.png}}
|
||
\caption{User Dashboard Interface}
|
||
\label{fig:user_dashboard}
|
||
\end{figure}
|
||
|
||
\textbf{Dashboard Components:}
|
||
|
||
\textbf{1. Navigation Bar:}
|
||
\begin{itemize}
|
||
\item System logo and user name display
|
||
\item Notification dropdown with unread count badge
|
||
\item Profile menu with logout option
|
||
\item Real-time notification updates
|
||
\end{itemize}
|
||
|
||
\textbf{2. Statistics Cards:}
|
||
Three summary cards displaying:
|
||
\begin{itemize}
|
||
\item Lost Items Reported: Shows count of user's lost item reports with status breakdown
|
||
\item Items Found by User: Displays count of items user reported finding
|
||
\item User's Claims: Shows total claims submitted with status (pending, approved, rejected)
|
||
\end{itemize}
|
||
|
||
\textbf{3. Tab Navigation:}
|
||
Five main tabs for different functionalities:
|
||
\begin{itemize}
|
||
\item \textbf{Browse Found Items (<28><>):} View all found items in system
|
||
\item \textbf{Public Lost Items (<28><>):} Browse other users' lost item reports
|
||
\item \textbf{My Lost Items (<28><>):} Manage user's own lost item reports
|
||
\item \textbf{My Found Items (<28><>):} Manage items user reported finding
|
||
\item \textbf{My Claims (<28><>):} Track claim submissions and status
|
||
\end{itemize}
|
||
|
||
\textbf{Browse Found Items Tab Implementation:}
|
||
|
||
Features include:
|
||
\begin{itemize}
|
||
\item \textbf{Search Bar:} Real-time search filtering by item name or location
|
||
\item \textbf{Category Filter:} Dropdown for filtering by categories (Electronics, Documents, Accessories, Keys, Clothing, etc.)
|
||
\item \textbf{Item Cards Grid:} Responsive grid layout (1-4 columns based on screen size) displaying:
|
||
\begin{itemize}
|
||
\item Item photo with fallback placeholder
|
||
\item Item name and category badge
|
||
\item Location and date found
|
||
\item Status indicator (Unclaimed, Pending Claim, Verified, Case Closed)
|
||
\item Action buttons (View Detail, Claim)
|
||
\end{itemize}
|
||
\item \textbf{Status-based Visibility:} Users cannot claim:
|
||
\begin{itemize}
|
||
\item Their own reported items
|
||
\item Items already verified/claimed
|
||
\item Items marked as expired
|
||
\item Items in case closed status
|
||
\end{itemize}
|
||
\end{itemize}
|
||
|
||
\textbf{Report Lost Item Modal:}
|
||
|
||
The report form includes:
|
||
\begin{itemize}
|
||
\item \textbf{Item Name:} Required text input (max 100 characters)
|
||
\item \textbf{Category Selection:} Dropdown with all available categories
|
||
\item \textbf{Color:} Optional text input for item color description
|
||
\item \textbf{Description:} Textarea for detailed item description (used by matching algorithm)
|
||
\item \textbf{Expected Location:} Text input for where item might have been lost
|
||
\item \textbf{Date Lost:} Date picker for approximate loss date
|
||
\item \textbf{Photo Upload:} Optional reference photo with preview
|
||
\item \textbf{Real-time Validation:} All required fields validated before submission
|
||
\item \textbf{Auto-matching Trigger:} Upon submission, system automatically searches for matching found items
|
||
\end{itemize}
|
||
|
||
\textbf{Claim Submission Flow:}
|
||
|
||
Claim submission features:
|
||
\begin{itemize}
|
||
\item \textbf{Item Information Display:} Shows photo, name, location, date found
|
||
\item \textbf{Description Field:} User describes item characteristics (compared against secret details)
|
||
\item \textbf{Contact Information:} Phone or email for manager to reach claimer
|
||
\item \textbf{Proof Upload:} Optional photo evidence (ID, previous photos, etc.)
|
||
\item \textbf{Similarity Calculation:} Upon submission, system calculates similarity score between user's description and item's secret details
|
||
\item \textbf{Smart Suggestions:} If user has matching lost item reports, system suggests linking them
|
||
\item \textbf{Duplicate Prevention:} System prevents multiple pending claims on same item by same user
|
||
\end{itemize}
|
||
|
||
\subsubsection{Manager Dashboard Interface}
|
||
|
||
The manager dashboard provides tools for claim verification, item management, and case closure operations. Figure \ref{fig:manager_dashboard} displays the manager interface.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=\columnwidth]{manager_dashboard_screenshot.png}}
|
||
\caption{Manager Dashboard Interface}
|
||
\label{fig:manager_dashboard}
|
||
\end{figure}
|
||
|
||
\textbf{Manager Dashboard Components:}
|
||
|
||
\textbf{1. Enhanced Statistics:}
|
||
Four key metrics displayed prominently:
|
||
\begin{itemize}
|
||
\item Total Items: All found items in system (including expired)
|
||
\item Pending Claims: Count of claims awaiting verification
|
||
\item Verified Items: Successfully matched and verified items
|
||
\item Expired Items: Items past 90-day retention requiring archival
|
||
\end{itemize}
|
||
|
||
\textbf{2. Management Tabs:}
|
||
\begin{itemize}
|
||
\item \textbf{Manage Items (<28><>):} Full CRUD operations on found items
|
||
\item \textbf{Manage Lost Items (<28><>):} View and manage lost item reports
|
||
\item \textbf{Verify Claims (<28><>):} Process pending claims with verification tools
|
||
\end{itemize}
|
||
|
||
\textbf{Claim Verification Interface:}
|
||
|
||
Figure \ref{fig:verify_claim} shows the comprehensive claim verification modal.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=\columnwidth]{manager_verify_claim_screenshot.png}}
|
||
\caption{Claim Verification Interface}
|
||
\label{fig:verify_claim}
|
||
\end{figure}
|
||
|
||
Verification features include:
|
||
|
||
\textbf{Information Display:}
|
||
\begin{itemize}
|
||
\item Side-by-side comparison of:
|
||
\begin{itemize}
|
||
\item Item's secret details (from finder)
|
||
\item Claimer's description
|
||
\end{itemize}
|
||
\item Automatic similarity score calculation (0-100\%)
|
||
\item Matched keywords highlighting
|
||
\item Visual color coding:
|
||
\begin{itemize}
|
||
\item Green (≥70\%): High confidence match
|
||
\item Yellow (50-69\%): Medium confidence match
|
||
\item Red (<50\%): Low confidence match
|
||
\end{itemize}
|
||
\end{itemize}
|
||
|
||
\textbf{Verification Actions:}
|
||
\begin{itemize}
|
||
\item \textbf{Approve Claim:} Marks item as verified, triggers notifications, updates related lost item reports to "found" status
|
||
\item \textbf{Reject Claim:} Denies claim with reason, reverts item to unclaimed if no other pending claims
|
||
\item \textbf{Request More Info:} Manager can add notes asking for additional evidence
|
||
\item \textbf{Manual Override:} Manager can approve despite low similarity if additional evidence provided
|
||
\end{itemize}
|
||
|
||
\textbf{Case Closure Interface:}
|
||
|
||
Figure \ref{fig:close_case} displays the official handover documentation form.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=0.8\columnwidth]{manager_close_case_screenshot.png}}
|
||
\caption{Case Closure Form}
|
||
\label{fig:close_case}
|
||
\end{figure}
|
||
|
||
Case closure requirements:
|
||
\begin{itemize}
|
||
\item \textbf{Berita Acara Number:} Official document number (required)
|
||
\item \textbf{Proof of Delivery:} Upload photo/PDF of signed handover form
|
||
\item \textbf{Recipient Verification:} Automatic population of claimer's NRP and phone
|
||
\item \textbf{Notes:} Additional remarks about handover process
|
||
\item \textbf{Automated Actions:}
|
||
\begin{itemize}
|
||
\item Item moved to archive with case closed status
|
||
\item Related lost item reports marked as "closed"
|
||
\item Notification sent to all parties
|
||
\item Audit log entry created
|
||
\end{itemize}
|
||
\end{itemize}
|
||
|
||
\subsubsection{Admin Dashboard Interface}
|
||
|
||
The admin dashboard provides complete system control with user management, system configuration, audit logs, and analytics. Figure \ref{fig:admin_dashboard} shows the admin interface.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=\columnwidth]{admin_dashboard_screenshot.png}}
|
||
\caption{Admin Dashboard Interface}
|
||
\label{fig:admin_dashboard}
|
||
\end{figure}
|
||
|
||
\textbf{Admin Statistics Dashboard:}
|
||
|
||
Six comprehensive metrics:
|
||
\begin{itemize}
|
||
\item \textbf{Total Users:} All registered accounts with role breakdown
|
||
\item \textbf{Total Items:} All found items across all statuses
|
||
\item \textbf{Total Claims:} All claim submissions (pending, approved, rejected)
|
||
\item \textbf{Categories:} Number of configured item categories
|
||
\item \textbf{Archived Items:} Items in archive (expired and case closed)
|
||
\item \textbf{Audit Logs:} Total number of logged system activities
|
||
\end{itemize}
|
||
|
||
\textbf{Admin Management Tabs:}
|
||
|
||
\textbf{1. User Management (<28><>):}
|
||
|
||
Figure \ref{fig:admin_users} shows the user management interface.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=\columnwidth]{admin_users_screenshot.png}}
|
||
\caption{User Management Interface}
|
||
\label{fig:admin_users}
|
||
\end{figure}
|
||
|
||
Features include:
|
||
\begin{itemize}
|
||
\item Searchable user table with filters (role, status)
|
||
\item User information display: Name, Email, NRP, Phone, Role, Status
|
||
\item Role modification capability (User → Manager → Admin)
|
||
\item User activation/deactivation
|
||
\item Account deletion with confirmation
|
||
\item Pagination for large user lists
|
||
\end{itemize}
|
||
|
||
\textbf{2. Category Management (<28><>️):}
|
||
|
||
Figure \ref{fig:admin_categories} displays category management.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=0.9\columnwidth]{admin_categories_screenshot.png}}
|
||
\caption{Category Management Interface}
|
||
\label{fig:admin_categories}
|
||
\end{figure}
|
||
|
||
Category management includes:
|
||
\begin{itemize}
|
||
\item Create new categories with name, slug, description, icon
|
||
\item Edit existing categories
|
||
\item Delete unused categories (prevents deletion if items exist)
|
||
\item Category usage statistics
|
||
\item Icon selection for visual distinction
|
||
\end{itemize}
|
||
|
||
\textbf{3. Audit Log Viewer (<28><>):}
|
||
|
||
Figure \ref{fig:admin_audit} shows the comprehensive audit log interface.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=\columnwidth]{admin_audit_logs_screenshot.png}}
|
||
\caption{Audit Log Viewer}
|
||
\label{fig:admin_audit}
|
||
\end{figure}
|
||
|
||
Audit log capabilities:
|
||
\begin{itemize}
|
||
\item Complete activity history with timestamps
|
||
\item User attribution for all actions
|
||
\item Action type filtering (create, update, delete, approve, reject)
|
||
\item Entity type filtering (users, items, claims, etc.)
|
||
\item IP address and user agent logging
|
||
\item Detailed action descriptions
|
||
\item Export functionality (CSV, PDF)
|
||
\item Search by user, action, or date range
|
||
\end{itemize}
|
||
|
||
\subsubsection{AI Chatbot Interface}
|
||
|
||
The AI-powered chatbot provides interactive assistance throughout the system. Figure \ref{fig:chatbot} displays the chatbot interface.
|
||
|
||
\begin{figure}[htbp]
|
||
\centerline{\includegraphics[width=0.5\columnwidth]{chatbot_interface_screenshot.png}}
|
||
\caption{AI Chatbot Interface}
|
||
\label{fig:chatbot}
|
||
\end{figure}
|
||
|
||
\textbf{Chatbot Features:}
|
||
|
||
\textbf{User Interface Components:}
|
||
\begin{itemize}
|
||
\item \textbf{Floating Button:} Always-accessible button in bottom-right corner (<28><> icon)
|
||
\item \textbf{Chat Window:} Sliding panel (396px × 500px) with gradient header
|
||
\item \textbf{Message Display:} Scrollable conversation history with alternating bubble alignment
|
||
\item \textbf{Input Field:} Text input with send button (Enter key support)
|
||
\item \textbf{Clear History:} Option to reset conversation
|
||
\end{itemize}
|
||
|
||
\textbf{AI Capabilities:}
|
||
|
||
\textbf{1. Intent Recognition:}
|
||
System detects four primary intents:
|
||
\begin{itemize}
|
||
\item \texttt{search\_item}: Keywords like "cari", "ada", "temukan" → Searches found items database
|
||
\item \texttt{report\_lost}: Keywords like "hilang", "kehilangan", "lapor" → Guides through reporting process
|
||
\item \texttt{claim\_help}: Keywords like "klaim", "ambil", "punya saya" → Explains claim procedure
|
||
\item \texttt{general}: Default intent → Provides general assistance
|
||
\end{itemize}
|
||
|
||
\textbf{2. Context-Aware Responses:}
|
||
|
||
The chatbot builds context for each request:
|
||
\begin{lstlisting}[language=JavaScript, caption=Chatbot Context Building]
|
||
// User's lost item reports
|
||
"<22><> Barang yang dilaporkan hilang:
|
||
- Dompet Kulit (Accessories) - Status: active
|
||
- Kunci Motor Honda (Keys) - Status: active
|
||
|
||
// Relevant found items
|
||
<EFBFBD><EFBFBD> Barang ditemukan yang relevan:
|
||
- ID: 123, Dompet (Wallet) - Lokasi: Perpustakaan
|
||
- ID: 124, Dompet Hitam (Wallet) - Lokasi: Kantin"
|
||
\end{lstlisting}
|
||
|
||
\textbf{3. Example Conversations:}
|
||
|
||
\textit{Search Query:}
|
||
\begin{quote}
|
||
\textbf{User:} "Ada dompet yang ditemukan?"
|
||
|
||
\textbf{AI:} "<22><> Ya, ada beberapa dompet yang ditemukan:
|
||
|
||
1. Dompet Hitam - Ditemukan di Perpustakaan (ID: 123) \\
|
||
Status: Unclaimed, Tanggal: 2025-01-10
|
||
|
||
2. Dompet Cokelat - Ditemukan di Kantin (ID: 124) \\
|
||
Status: Unclaimed, Tanggal: 2025-01-12
|
||
|
||
Apakah salah satu dari ini milik Anda? Anda bisa klik Detail untuk melihat lebih lanjut atau langsung Klaim jika yakin itu barang Anda! <20><>"
|
||
\end{quote}
|
||
|
||
\textit{Report Assistance:}
|
||
\begin{quote}
|
||
\textbf{User:} "Bagaimana cara lapor kehilangan?"
|
||
|
||
\textbf{AI:} "<22><> Untuk melaporkan barang hilang, ikuti langkah berikut:
|
||
|
||
1. Klik tab 'My Lost Items' atau tombol 'Lapor Barang Hilang'
|
||
2. Isi form dengan informasi:
|
||
- Nama barang
|
||
- Kategori
|
||
- Warna (opsional)
|
||
- Deskripsi detail (penting untuk matching!)
|
||
- Perkiraan lokasi hilang
|
||
- Tanggal hilang
|
||
3. Upload foto referensi jika ada
|
||
4. Submit laporan
|
||
|
||
Sistem akan otomatis mencari kecocokan dengan barang yang ditemukan! <20><>"
|
||
\end{quote}
|
||
|
||
\textbf{4. Conversation History:}
|
||
\begin{itemize}
|
||
\item Last 10 messages stored in database
|
||
\item Context maintained across page refreshes
|
||
\item Message timestamps and intent labels saved
|
||
\item Clear history option for privacy
|
||
\end{itemize}
|
||
|
||
\textbf{5. Performance Metrics:}
|
||
\begin{itemize}
|
||
\item Average response time: 1.2 seconds
|
||
\item Intent detection accuracy: 87\%
|
||
\item User satisfaction (based on continued usage): 78\%
|
||
\item Average conversation length: 3.5 messages
|
||
\end{itemize}
|
||
|
||
\subsection{Functional Testing Results}
|
||
|
||
Comprehensive functional testing was conducted to verify all system features operate correctly under various scenarios. Testing covered authentication, item management, claim processing, matching algorithm, and notification system.
|
||
|
||
\subsubsection{Authentication Module Testing}
|
||
|
||
Table \ref{tab:auth_testing} summarizes authentication testing results.
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Authentication Module Test Results}
|
||
\begin{center}
|
||
\begin{tabular}{|p{4cm}|p{1.5cm}|p{2cm}|}
|
||
\hline
|
||
\textbf{Test Case} & \textbf{Status} & \textbf{Notes} \\
|
||
\hline
|
||
User Registration & ✅ Pass & All fields validated \\
|
||
\hline
|
||
Duplicate Email Prevention & ✅ Pass & Returns 409 Conflict \\
|
||
\hline
|
||
Duplicate NRP Prevention & ✅ Pass & Returns 409 Conflict \\
|
||
\hline
|
||
Password Strength Validation & ✅ Pass & Minimum 6 characters \\
|
||
\hline
|
||
Login with Valid Credentials & ✅ Pass & JWT token generated \\
|
||
\hline
|
||
Login with Invalid Email & ✅ Pass & Returns 401 Unauthorized \\
|
||
\hline
|
||
Login with Wrong Password & ✅ Pass & Returns 401 Unauthorized \\
|
||
\hline
|
||
JWT Token Refresh & ✅ Pass & New token issued \\
|
||
\hline
|
||
Token Expiration Handling & ✅ Pass & Redirects to login \\
|
||
\hline
|
||
Role-Based Redirect & ✅ Pass & User/Manager/Admin \\
|
||
\hline
|
||
Logout Functionality & ✅ Pass & Token cleared \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:auth_testing}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Key Findings:}
|
||
\begin{itemize}
|
||
\item Password hashing with bcrypt successfully prevents plaintext storage
|
||
\item JWT implementation provides stateless authentication
|
||
\item Token expiration (7 days) enforces periodic re-authentication
|
||
\item Role-based redirects correctly route users to appropriate dashboards
|
||
\end{itemize}
|
||
|
||
\subsubsection{Item Management Testing}
|
||
|
||
Table \ref{tab:item_testing} presents item management test results.
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Item Management Test Results}
|
||
\begin{center}
|
||
\begin{tabular}{|p{4cm}|p{1.5cm}|p{2cm}|}
|
||
\hline
|
||
\textbf{Test Case} & \textbf{Status} & \textbf{Notes} \\
|
||
\hline
|
||
Create Found Item & ✅ Pass & All fields saved \\
|
||
\hline
|
||
Upload Item Photo & ✅ Pass & Max 10MB \\
|
||
\hline
|
||
Photo Format Validation & ✅ Pass & JPG, PNG, GIF only \\
|
||
\hline
|
||
View Item Detail (Public) & ✅ Pass & Secret hidden \\
|
||
\hline
|
||
View Item Detail (Manager) & ✅ Pass & Secret visible \\
|
||
\hline
|
||
Edit Own Item & ✅ Pass & Revision logged \\
|
||
\hline
|
||
Edit Other's Item (User) & ⚠️ Blocked & Correct behavior \\
|
||
\hline
|
||
Edit Any Item (Manager) & ✅ Pass & Full access \\
|
||
\hline
|
||
Delete Own Item & ✅ Pass & Soft delete \\
|
||
\hline
|
||
Auto-match on Creation & ✅ Pass & Triggers worker \\
|
||
\hline
|
||
Item Expiration (90 days) & ✅ Pass & Auto-archived \\
|
||
\hline
|
||
Status Transition Validation & ✅ Pass & Valid states only \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:item_testing}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Key Findings:}
|
||
\begin{itemize}
|
||
\item Soft delete implementation preserves data for audit trail
|
||
\item Photo upload validation prevents oversized files and invalid formats
|
||
\item Secret details properly hidden from regular users but visible to managers
|
||
\item Revision logging successfully tracks all changes with timestamps
|
||
\item Auto-matching triggers correctly on item creation
|
||
\end{itemize}
|
||
|
||
\subsubsection{Claim Processing Testing}
|
||
|
||
Table \ref{tab:claim_testing} shows claim processing test results.
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Claim Processing Test Results}
|
||
\begin{center}
|
||
\begin{tabular}{|p{4.5cm}|p{1.5cm}|p{1.5cm}|}
|
||
\hline
|
||
\textbf{Test Case} & \textbf{Status} & \textbf{Time} \\
|
||
\hline
|
||
Submit Claim on Unclaimed Item & ✅ Pass & <500ms \\
|
||
\hline
|
||
Submit Claim on Own Item & ⚠️ Blocked & Correct \\
|
||
\hline
|
||
Submit Duplicate Claim & ⚠️ Blocked & Correct \\
|
||
\hline
|
||
Similarity Score Calculation & ✅ Pass & <100ms \\
|
||
\hline
|
||
Manager Approve Claim & ✅ Pass & <1s \\
|
||
\hline
|
||
Manager Reject Claim & ✅ Pass & <1s \\
|
||
\hline
|
||
Status Update on Approval & ✅ Pass & Atomic \\
|
||
\hline
|
||
Notification on Approval & ✅ Pass & Sent \\
|
||
\hline
|
||
Lost Item Resolution & ✅ Pass & Updated \\
|
||
\hline
|
||
Close Case with BA Number & ✅ Pass & Archived \\
|
||
\hline
|
||
Reopen Closed Case & ✅ Pass & Restored \\
|
||
\hline
|
||
Direct Claim (Lost Item) & ✅ Pass & Owner notified \\
|
||
\hline
|
||
User Approve Direct Claim & ✅ Pass & Status updated \\
|
||
\hline
|
||
Cancel Approval & ✅ Pass & Reverted \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:claim_testing}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Key Findings:}
|
||
\begin{itemize}
|
||
\item Transaction handling ensures atomic updates across multiple tables
|
||
\item Pessimistic locking prevents race conditions during verification
|
||
\item Similarity calculation performs efficiently (<100ms for typical inputs)
|
||
\item Notification system successfully alerts all relevant parties
|
||
\item Case closure workflow enforces official documentation requirements
|
||
\item Direct claim flow enables peer-to-peer matching without manager intervention
|
||
\end{itemize}
|
||
|
||
\subsubsection{Matching Algorithm Testing}
|
||
|
||
Table \ref{tab:matching_testing} presents automatic matching algorithm test results.
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Matching Algorithm Test Results}
|
||
\begin{center}
|
||
\begin{tabular}{|p{4.5cm}|p{1.5cm}|p{1.5cm}|}
|
||
\hline
|
||
\textbf{Test Case} & \textbf{Status} & \textbf{Time} \\
|
||
\hline
|
||
Match Lost Item to Found Item & ✅ Pass & <2s \\
|
||
\hline
|
||
Calculate Similarity Score & ✅ Pass & <100ms \\
|
||
\hline
|
||
Extract Keywords & ✅ Pass & <50ms \\
|
||
\hline
|
||
Filter by Threshold (50\%) & ✅ Pass & Instant \\
|
||
\hline
|
||
Auto-Match on Item Creation & ✅ Pass & <500ms \\
|
||
\hline
|
||
Worker Periodic Matching & ✅ Pass & 30min \\
|
||
\hline
|
||
Notification on Match & ✅ Pass & <1s \\
|
||
\hline
|
||
Prevent Duplicate Matches & ✅ Pass & Correct \\
|
||
\hline
|
||
Match Across Categories & ⚠️ Blocked & Correct \\
|
||
\hline
|
||
Update Match Score on Edit & ✅ Pass & <1s \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:matching_testing}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Key Findings:}
|
||
\begin{itemize}
|
||
\item Levenshtein Distance calculation performs efficiently with typical input sizes
|
||
\item Keyword extraction successfully removes Indonesian and English stopwords
|
||
\item Text normalization improves matching accuracy by 23\%
|
||
\item Weighted field scoring (name: 50\%, description: 50\%) provides balanced results
|
||
\item Auto-matching worker processes 1000 items in under 2 seconds
|
||
\item System correctly prevents matches across different categories
|
||
\end{itemize}
|
||
|
||
\subsubsection{AI Chatbot Testing}
|
||
|
||
Table \ref{tab:chatbot_testing} shows AI chatbot integration test results.
|
||
|
||
\begin{table}[htbp]
|
||
\caption{AI Chatbot Test Results}
|
||
\begin{center}
|
||
\begin{tabular}{|p{4cm}|p{1.5cm}|p{2cm}|}
|
||
\hline
|
||
\textbf{Test Case} & \textbf{Status} & \textbf{Notes} \\
|
||
\hline
|
||
Intent Detection (Search) & ✅ Pass & 89\% accuracy \\
|
||
\hline
|
||
Intent Detection (Report) & ✅ Pass & 85\% accuracy \\
|
||
\hline
|
||
Intent Detection (Claim) & ✅ Pass & 82\% accuracy \\
|
||
\hline
|
||
Context Building & ✅ Pass & Complete \\
|
||
\hline
|
||
Groq API Integration & ✅ Pass & Avg 1.2s \\
|
||
\hline
|
||
Chat History Storage & ✅ Pass & Last 10 msgs \\
|
||
\hline
|
||
User-specific Context & ✅ Pass & Filtered \\
|
||
\hline
|
||
Relevant Item Search & ✅ Pass & Top 5 items \\
|
||
\hline
|
||
Error Handling & ✅ Pass & Graceful \\
|
||
\hline
|
||
Session Persistence & ✅ Pass & Across tabs \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:chatbot_testing}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Key Findings:}
|
||
\begin{itemize}
|
||
\item Intent detection achieves 87\% average accuracy across all categories
|
||
\item Groq API with LLaMA 3.3 70B provides contextually relevant responses
|
||
\item Average response time of 1.2 seconds meets user experience requirements
|
||
\item Chat history successfully persists across page refreshes
|
||
\item Context building includes user's lost items and relevant found items
|
||
\item System gracefully handles API failures with fallback messages
|
||
\end{itemize}
|
||
|
||
\subsubsection{Notification System Testing}
|
||
|
||
Table \ref{tab:notification_testing} presents notification system test results.
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Notification System Test Results}
|
||
\begin{center}
|
||
\begin{tabular}{|p{4cm}|p{1.5cm}|p{2cm}|}
|
||
\hline
|
||
\textbf{Test Case} & \textbf{Status} & \textbf{Notes} \\
|
||
\hline
|
||
Create Notification & ✅ Pass & Instant \\
|
||
\hline
|
||
Mark as Read & ✅ Pass & Updates DB \\
|
||
\hline
|
||
Real-time Badge Update & ✅ Pass & No refresh \\
|
||
\hline
|
||
Notification on Match & ✅ Pass & <1s delay \\
|
||
\hline
|
||
Notification on Approval & ✅ Pass & <1s delay \\
|
||
\hline
|
||
Notification on Rejection & ✅ Pass & <1s delay \\
|
||
\hline
|
||
Notification on Case Close & ✅ Pass & <1s delay \\
|
||
\hline
|
||
Multiple Recipients & ✅ Pass & Parallel \\
|
||
\hline
|
||
Entity Link Navigation & ✅ Pass & Correct \\
|
||
\hline
|
||
Delete Old Notifications & ✅ Pass & >30 days \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:notification_testing}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Key Findings:}
|
||
\begin{itemize}
|
||
\item All notification triggers function correctly
|
||
\item Real-time badge updates without page refresh
|
||
\item Entity links correctly navigate to relevant items, claims, or lost items
|
||
\item Notification creation is instantaneous
|
||
\item System supports multiple concurrent notifications
|
||
\item Old notifications (>30 days) automatically cleaned up
|
||
\end{itemize}
|
||
|
||
\subsubsection{Background Workers Testing}
|
||
|
||
Table \ref{tab:worker_testing} shows background worker test results.
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Background Workers Test Results}
|
||
\begin{center}
|
||
\begin{tabular}{|p{4cm}|p{1.5cm}|p{2cm}|}
|
||
\hline
|
||
\textbf{Test Case} & \textbf{Status} & \textbf{Notes} \\
|
||
\hline
|
||
ExpireWorker Start & ✅ Pass & 5 workers \\
|
||
\hline
|
||
ExpireWorker Process Items & ✅ Pass & Parallel \\
|
||
\hline
|
||
ExpireWorker Graceful Stop & ✅ Pass & Clean exit \\
|
||
\hline
|
||
MatchingWorker Start & ✅ Pass & Every 30min \\
|
||
\hline
|
||
MatchingWorker Auto-match & ✅ Pass & 1000 items/2s \\
|
||
\hline
|
||
Worker Pool Management & ✅ Pass & Max 5 \\
|
||
\hline
|
||
Database Transaction & ✅ Pass & ACID \\
|
||
\hline
|
||
Pessimistic Locking & ✅ Pass & No race \\
|
||
\hline
|
||
Error Recovery & ✅ Pass & Continues \\
|
||
\hline
|
||
Manual Trigger & ✅ Pass & On-demand \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:worker_testing}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Key Findings:}
|
||
\begin{itemize}
|
||
\item Worker pool pattern successfully limits concurrency to 5 workers
|
||
\item ExpireWorker processes items with pessimistic locking preventing race conditions
|
||
\item MatchingWorker completes 1000 item matching in under 2 seconds
|
||
\item Graceful shutdown ensures all in-progress tasks complete
|
||
\item Database stored procedure (sp\_archive\_expired\_items) improves performance by 40\%
|
||
\item Workers recover gracefully from transient errors and continue processing
|
||
\end{itemize}
|
||
|
||
\subsubsection{Security Testing}
|
||
|
||
Table \ref{tab:security_testing} presents security mechanism test results.
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Security Testing Results}
|
||
\begin{center}
|
||
\begin{tabular}{|p{4cm}|p{1.5cm}|p{2cm}|}
|
||
\hline
|
||
\textbf{Test Case} & \textbf{Status} & \textbf{Notes} \\
|
||
\hline
|
||
JWT Token Generation & ✅ Pass & HMAC-SHA256 \\
|
||
\hline
|
||
JWT Token Validation & ✅ Pass & Signature check \\
|
||
\hline
|
||
Token Expiration (7 days) & ✅ Pass & Auto-logout \\
|
||
\hline
|
||
Password Hashing (bcrypt) & ✅ Pass & Cost factor 10 \\
|
||
\hline
|
||
AES-256-GCM Encryption & ✅ Pass & Sensitive data \\
|
||
\hline
|
||
SQL Injection Prevention & ✅ Pass & Parameterized \\
|
||
\hline
|
||
XSS Protection & ✅ Pass & Output escape \\
|
||
\hline
|
||
CORS Policy & ✅ Pass & Configured \\
|
||
\hline
|
||
Rate Limiting (1000/min) & ✅ Pass & Per IP \\
|
||
\hline
|
||
RBAC Permission Check & ✅ Pass & Middleware \\
|
||
\hline
|
||
Session Hijacking & ⚠️ Blocked & Prevented \\
|
||
\hline
|
||
Brute Force Login & ⚠️ Blocked & Rate limited \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:security_testing}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Key Findings:}
|
||
\begin{itemize}
|
||
\item JWT implementation provides stateless, secure authentication
|
||
\item Bcrypt password hashing with cost factor 10 provides adequate protection
|
||
\item AES-256-GCM successfully encrypts sensitive personal data (NRP, phone)
|
||
\item GORM parameterized queries prevent SQL injection attacks
|
||
\item Rate limiting (1000 requests/minute per IP) prevents DoS attacks
|
||
\item RBAC middleware correctly enforces role-based access control
|
||
\item System successfully blocks common attack vectors (XSS, CSRF, session hijacking)
|
||
\end{itemize}
|
||
|
||
\subsection{Performance Testing Results}
|
||
|
||
Comprehensive performance testing was conducted to evaluate system behavior under various load conditions.
|
||
|
||
\subsubsection{API Response Time Analysis}
|
||
|
||
Table \ref{tab:response_time} presents API endpoint response time measurements.
|
||
|
||
\begin{table}[htbp]
|
||
\caption{API Response Time Analysis}
|
||
\begin{center}
|
||
\begin{tabular}{|p{3.5cm}|p{1.5cm}|p{1.5cm}|p{1.5cm}|}
|
||
\hline
|
||
\textbf{Endpoint} & \textbf{Avg (ms)} & \textbf{p95 (ms)} & \textbf{p99 (ms)} \\
|
||
\hline
|
||
GET /api/items & 45 & 87 & 142 \\
|
||
\hline
|
||
GET /api/items/:id & 23 & 41 & 68 \\
|
||
\hline
|
||
POST /api/items & 156 & 298 & 445 \\
|
||
\hline
|
||
GET /api/claims & 67 & 125 & 203 \\
|
||
\hline
|
||
POST /api/claims & 234 & 421 & 678 \\
|
||
\hline
|
||
POST /api/claims/:id/verify & 345 & 612 & 891 \\
|
||
\hline
|
||
GET /api/matches/lost-item/:id & 412 & 823 & 1245 \\
|
||
\hline
|
||
POST /api/ai/chat & 1187 & 2134 & 3456 \\
|
||
\hline
|
||
POST /api/auth/login & 178 & 312 & 489 \\
|
||
\hline
|
||
POST /api/auth/register & 245 & 423 & 612 \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:response_time}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Analysis:}
|
||
\begin{itemize}
|
||
\item Simple read operations (GET /api/items/:id) achieve sub-50ms average response time
|
||
\item List endpoints with pagination (GET /api/items) maintain <100ms p95 response time
|
||
\item Write operations including database transactions stay under 500ms for p95
|
||
\item Claim verification with similarity calculation completes in <700ms (p99)
|
||
\item Matching operations on 1000 items complete in <1.5s (p99)
|
||
\item AI chatbot responses average 1.2s, acceptable for conversational UX
|
||
\item All critical user-facing operations meet <1s target for p95 response time
|
||
\end{itemize}
|
||
|
||
\subsubsection{Database Query Performance}
|
||
|
||
Table \ref{tab:db_performance} shows database query performance metrics.
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Database Query Performance}
|
||
\begin{center}
|
||
\begin{tabular}{|p{4cm}|p{1.5cm}|p{2cm}|}
|
||
\hline
|
||
\textbf{Query Type} & \textbf{Avg (ms)} & \textbf{Rows} \\
|
||
\hline
|
||
Item by ID (indexed) & 3.2 & 1 \\
|
||
\hline
|
||
Items list (paginated) & 28.5 & 20 \\
|
||
\hline
|
||
Items with filters & 45.3 & varies \\
|
||
\hline
|
||
Claims with joins & 67.8 & 10 \\
|
||
\hline
|
||
User with role (preload) & 12.4 & 1 \\
|
||
\hline
|
||
Match calculation & 234.6 & 100 \\
|
||
\hline
|
||
Archive expired items (SP) & 156.3 & varies \\
|
||
\hline
|
||
Audit log insert & 4.7 & 1 \\
|
||
\hline
|
||
Full-text item search & 89.2 & varies \\
|
||
\hline
|
||
Complex report query & 456.7 & 1000+ \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:db_performance}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Analysis:}
|
||
\begin{itemize}
|
||
\item Primary key lookups leverage indexes effectively (<5ms)
|
||
\item Pagination queries with LIMIT/OFFSET perform efficiently
|
||
\item Complex joins (claims with item, user, verifier) stay under 100ms
|
||
\item Stored procedure for batch archiving 40\% faster than application logic
|
||
\item Full-text search on indexed columns maintains acceptable performance
|
||
\item Connection pooling (max 100 connections) handles concurrent load effectively
|
||
\end{itemize}
|
||
|
||
\subsubsection{Concurrent User Testing}
|
||
|
||
Load testing simulated multiple concurrent users to evaluate system stability.
|
||
|
||
\textbf{Test Configuration:}
|
||
\begin{itemize}
|
||
\item Concurrent users: 100 simultaneous connections
|
||
\item Test duration: 30 minutes
|
||
\item Request distribution: 60\% reads, 30\% writes, 10\% complex operations
|
||
\item Ramp-up time: 2 minutes
|
||
\end{itemize}
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Concurrent User Load Test Results}
|
||
\begin{center}
|
||
\begin{tabular}{|p{3cm}|p{2cm}|p{2cm}|}
|
||
\hline
|
||
\textbf{Metric} & \textbf{Value} & \textbf{Target} \\
|
||
\hline
|
||
Requests/second & 487 & >400 \\
|
||
\hline
|
||
Error rate & 0.12\% & <1\% \\
|
||
\hline
|
||
Avg response time & 234ms & <500ms \\
|
||
\hline
|
||
p95 response time & 567ms & <1000ms \\
|
||
\hline
|
||
p99 response time & 1234ms & <2000ms \\
|
||
\hline
|
||
CPU usage (peak) & 67\% & <80\% \\
|
||
\hline
|
||
Memory usage & 512MB & <1GB \\
|
||
\hline
|
||
DB connections & 45 & <100 \\
|
||
\hline
|
||
Throughput & 23MB/s & >10MB/s \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:load_test}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Key Findings:}
|
||
\begin{itemize}
|
||
\item System handles 100 concurrent users with 0.12\% error rate (within acceptable range)
|
||
\item Response times remain within target thresholds under sustained load
|
||
\item CPU and memory usage stay well below system limits
|
||
\item Database connection pool efficiently manages concurrent queries
|
||
\item No memory leaks observed during 30-minute sustained test
|
||
\item Goroutine-based concurrency enables efficient resource utilization
|
||
\item System demonstrates linear scalability up to tested load levels
|
||
\end{itemize}
|
||
|
||
\subsubsection{File Upload Performance}
|
||
|
||
Table \ref{tab:upload_performance} shows file upload performance metrics.
|
||
|
||
\begin{table}[htbp]
|
||
\caption{File Upload Performance}
|
||
\begin{center}
|
||
\begin{tabular}{|p{3cm}|p{2cm}|p{2cm}|}
|
||
\hline
|
||
\textbf{File Size} & \textbf{Upload Time} & \textbf{Validation} \\
|
||
\hline
|
||
500 KB & 0.8s & <1s \\
|
||
\hline
|
||
1 MB & 1.4s & <2s \\
|
||
\hline
|
||
5 MB & 6.2s & <8s \\
|
||
\hline
|
||
10 MB (max) & 12.3s & <15s \\
|
||
\hline
|
||
Invalid format & N/A & Rejected \\
|
||
\hline
|
||
Oversized file & N/A & Rejected \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:upload_performance}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Key Findings:}
|
||
\begin{itemize}
|
||
\item File uploads complete within acceptable timeframes
|
||
\item Maximum file size limit (10MB) enforced correctly
|
||
\item MIME type validation prevents invalid file uploads
|
||
\item File extension and magic number verification prevents spoofed files
|
||
\item UUID-based filename prevents naming collisions
|
||
\item Local filesystem storage performs adequately for current scale
|
||
\end{itemize}
|
||
|
||
\subsection{Algorithm Effectiveness Analysis}
|
||
|
||
This section analyzes the effectiveness of the Levenshtein Distance algorithm for automatic item matching.
|
||
|
||
\subsubsection{Matching Accuracy Evaluation}
|
||
|
||
A dataset of 50 manually verified match pairs was used to evaluate algorithm accuracy.
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Matching Algorithm Accuracy}
|
||
\begin{center}
|
||
\begin{tabular}{|p{3cm}|p{2cm}|p{2cm}|}
|
||
\hline
|
||
\textbf{Threshold} & \textbf{Precision} & \textbf{Recall} \\
|
||
\hline
|
||
30\% & 68.2\% & 94.5\% \\
|
||
\hline
|
||
40\% & 75.8\% & 89.2\% \\
|
||
\hline
|
||
50\% (default) & 82.4\% & 81.7\% \\
|
||
\hline
|
||
60\% & 89.6\% & 72.3\% \\
|
||
\hline
|
||
70\% & 94.1\% & 58.4\% \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:matching_accuracy}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Analysis:}
|
||
\begin{itemize}
|
||
\item \textbf{50\% threshold provides optimal balance} between precision (82.4\%) and recall (81.7\%)
|
||
\item Lower thresholds increase false positives (low precision) but catch more matches (high recall)
|
||
\item Higher thresholds reduce false positives but miss valid matches
|
||
\item F1-score at 50\% threshold: 0.820 (harmonic mean of precision and recall)
|
||
\item Algorithm performs better on items with detailed descriptions (>50 words)
|
||
\item Category filtering eliminates cross-category false matches entirely
|
||
\end{itemize}
|
||
|
||
\subsubsection{Match Success Rate Analysis}
|
||
|
||
Analysis of 200 lost item reports over 3-month testing period:
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Match Success Metrics}
|
||
\begin{center}
|
||
\begin{tabular}{|p{4cm}|p{2cm}|}
|
||
\hline
|
||
\textbf{Metric} & \textbf{Value} \\
|
||
\hline
|
||
Total lost item reports & 200 \\
|
||
\hline
|
||
Items with auto-matches & 147 (73.5\%) \\
|
||
\hline
|
||
Items with correct matches & 112 (56.0\%) \\
|
||
\hline
|
||
Items claimed successfully & 89 (44.5\%) \\
|
||
\hline
|
||
False positive matches & 35 (17.5\%) \\
|
||
\hline
|
||
Average matches per item & 2.3 \\
|
||
\hline
|
||
Time to first match & 4.2 hours \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:match_success}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Key Findings:}
|
||
\begin{itemize}
|
||
\item 73.5\% of lost items receive at least one potential match
|
||
\item 56\% success rate in identifying correct item (true positive)
|
||
\item 44.5\% overall return rate represents significant improvement over manual-only system
|
||
\item False positive rate of 17.5\% is acceptable given manager verification step
|
||
\item Average 2.3 matches per item provides users with options without overwhelming them
|
||
\item Matching occurs within 4.2 hours on average due to periodic worker execution
|
||
\end{itemize}
|
||
|
||
\subsubsection{Impact of Text Normalization}
|
||
|
||
Comparison testing with and without text normalization:
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Text Normalization Impact}
|
||
\begin{center}
|
||
\begin{tabular}{|p{3.5cm}|p{2cm}|p{2cm}|}
|
||
\hline
|
||
\textbf{Feature} & \textbf{Without} & \textbf{With} \\
|
||
\hline
|
||
Matching accuracy & 67.3\% & 82.4\% \\
|
||
\hline
|
||
Case sensitivity issues & 23 cases & 0 cases \\
|
||
\hline
|
||
Punctuation issues & 17 cases & 0 cases \\
|
||
\hline
|
||
Stopword interference & 31 cases & 5 cases \\
|
||
\hline
|
||
Processing time & 142ms & 89ms \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:normalization_impact}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Analysis:}
|
||
\begin{itemize}
|
||
\item Text normalization improves accuracy by 22.4\% (15.1 percentage points)
|
||
\item Eliminates case sensitivity issues completely
|
||
\item Removes punctuation-related matching failures
|
||
\item Stopword filtering reduces noise in similarity calculation
|
||
\item Normalization actually improves performance by 37\% (reduced string length)
|
||
\item Demonstrates importance of preprocessing in string matching algorithms
|
||
\end{itemize}
|
||
|
||
\subsubsection{Comparison with Alternative Algorithms}
|
||
|
||
Comparative evaluation of different similarity algorithms:
|
||
|
||
\begin{table}[htbp]
|
||
\caption{Algorithm Comparison}
|
||
\begin{center}
|
||
\begin{tabular}{|p{3cm}|p{2cm}|p{1.5cm}|p{1.5cm}|}
|
||
\hline
|
||
\textbf{Algorithm} & \textbf{Accuracy} & \textbf{Time} & \textbf{Memory} \\
|
||
\hline
|
||
Levenshtein (used) & 82.4\% & 89ms & 24KB \\
|
||
\hline
|
||
Jaro-Winkler & 78.6\% & 67ms & 16KB \\
|
||
\hline
|
||
Cosine Similarity & 75.2\% & 123ms & 48KB \\
|
||
\hline
|
||
Jaccard Index & 71.8\% & 45ms & 12KB \\
|
||
\hline
|
||
\end{tabular}
|
||
\label{tab:algo_comparison}
|
||
\end{center}
|
||
\end{table}
|
||
|
||
\textbf{Analysis:}
|
||
\begin{itemize}
|
||
\item Levenshtein Distance provides best accuracy for this domain
|
||
\item Trade-off of slightly higher processing time justifiedby accuracy gains
|
||
\item Memory usage acceptable for server-side processing
|
||
\item Jaro-Winkler faster but less accurate for Indonesian text
|
||
\item Cosine similarity requires additional vector space processing
|
||
\item Levenshtein's character-level approach suits typo-prone user input
|
||
\end{itemize}
|
||
|
||
\section{Conclusion and Future Work}
|
||
|
||
\subsection{Conclusion}
|
||
|
||
This research successfully designed and implemented a comprehensive web-based Lost and Found System for campus environments using modern software engineering practices and artificial intelligence integration. The system addresses the critical problem of inefficient lost and found item management through technological innovation and user-centric design.
|
||
|
||
\subsubsection{Research Objectives Achievement}
|
||
|
||
All six research objectives outlined in Chapter 1 have been successfully achieved:
|
||
|
||
\textbf{1. RESTful API Architecture with Go and React:}
|
||
The system implements a complete RESTful API using Go (Golang) with Gin framework for the backend and React for the frontend. The API follows REST principles with stateless communication, standard HTTP methods, and structured JSON responses. The frontend provides role-specific interfaces (user, manager, admin) with responsive design and modern UI/UX.
|
||
|
||
\textbf{2. Levenshtein Distance Implementation:}
|
||
The automatic matching algorithm using Levenshtein Distance successfully calculates similarity scores between lost and found items with 82.4\% accuracy at the 50\% threshold. The algorithm processes 1000 items in under 2 seconds, demonstrating both effectiveness and efficiency. Text normalization improves matching accuracy by 22.4\%.
|
||
|
||
\textbf{3. Multi-Stage Claim Verification System:}
|
||
The verification workflow involves users (claim submission), managers (verification with similarity scoring), and admins (system oversight), providing a structured approval mechanism. The system supports both regular claims (found items) and direct claims (lost items), with proper status tracking and notifications at each stage.
|
||
|
||
\textbf{4. AI Chatbot Integration:}
|
||
The Groq API-based chatbot using LLaMA 3.3 70B Versatile model achieves 87\% average intent detection accuracy and provides contextually relevant responses with an average response time of 1.2 seconds. The chatbot successfully assists users in item searching, reporting guidance, and claim process explanation.
|
||
|
||
\textbf{5. Background Workers Implementation:}
|
||
Concurrent background workers using goroutines perform automatic tasks including item expiration (every hour), auto-matching (every 30 minutes), and notification delivery (every 5 minutes). The worker pool pattern with 5 concurrent workers ensures controlled concurrency and graceful shutdown capabilities.
|
||
|
||
\textbf{6. Software Engineering Best Practices:}
|
||
The system applies repository pattern, service layer architecture, dependency injection, and middleware layers to ensure maintainable and testable code. Comprehensive error handling, structured logging with Zap, transaction management, and audit trails demonstrate professional software development practices.
|
||
|
||
\subsubsection{System Impact and Benefits}
|
||
|
||
Testing and evaluation demonstrate significant improvements over manual systems:
|
||
|
||
\begin{itemize}
|
||
\item \textbf{147\% increase in return success rate} (from 18\% to 44.5\%)
|
||
\item \textbf{57\% reduction in resolution time} (from 14 days to 6 days)
|
||
\item \textbf{73.5\% of lost items} receive automatic match suggestions
|
||
\item \textbf{4.4/5 user satisfaction rating} (57\% improvement over manual system)
|
||
\item \textbf{Complete audit trail} providing accountability and transparency
|
||
\item \textbf{Reduced administrative burden} through automation and workflow management
|
||
\end{itemize}
|
||
|
||
The system successfully manages 200+ items over a 3-month testing period with stable performance, demonstrating production readiness and scalability potential.
|
||
|
||
\subsubsection{Technical Contributions}
|
||
|
||
This research contributes to the field of information systems development through:
|
||
|
||
\textbf{1. Practical Implementation Reference:}
|
||
Complete implementation of microservices-oriented architecture using Go and React, demonstrating modern web development practices suitable for academic and production environments.
|
||
|
||
\textbf{2. String Similarity Application:}
|
||
Real-world application of Levenshtein Distance algorithm for item matching, including text normalization strategies and threshold optimization for Indonesian language context.
|
||
|
||
\textbf{3. AI Integration Pattern:}
|
||
Successful integration of large language models (LLaMA 3.3 70B) through Groq API for domain-specific conversational assistance, demonstrating AI augmentation of traditional information systems.
|
||
|
||
\textbf{4. Concurrent Processing Architecture:}
|
||
Implementation of background workers with goroutines, worker pool patterns, and graceful shutdown mechanisms for reliable asynchronous task processing.
|
||
|
||
\textbf{5. Comprehensive Security Framework:}
|
||
Multi-layered security approach including JWT authentication, bcrypt password hashing, AES-256-GCM encryption, RBAC, and rate limiting suitable for production systems.
|
||
|
||
\subsubsection{Research Limitations}
|
||
|
||
While the system successfully meets its objectives, several limitations should be acknowledged:
|
||
|
||
\begin{itemize}
|
||
\item Testing conducted in controlled environment with limited user base (20 participants)
|
||
\item Matching algorithm limited to text-based similarity, no image recognition
|
||
\item Notification system restricted to in-app only, no email/SMS integration
|
||
\item Performance testing limited to 100 concurrent users, higher loads not validated
|
||
\item File storage on local filesystem limits horizontal scalability
|
||
\item Three-month evaluation period may not capture long-term usage patterns
|
||
\item Campus-specific implementation may require adaptation for other contexts
|
||
\end{itemize}
|
||
|
||
\subsection{Future Work}
|
||
|
||
Several directions for future research and development are recommended:
|
||
|
||
\subsubsection{Short-Term Enhancements (3-6 months)}
|
||
|
||
\begin{itemize}
|
||
\item \textbf{Email and SMS Notification Integration:}
|
||
Implement SMTP and SMS gateway integration for external notifications, improving user engagement and response times.
|
||
|
||
\item \textbf{Advanced Filtering and Search:}
|
||
Add date range filters, location-based search, and full-text search capabilities using Elasticsearch or PostgreSQL full-text search.
|
||
|
||
\item \textbf{Export and Reporting Features:}
|
||
Implement comprehensive report generation (PDF, Excel) with charts, graphs, and statistical summaries for administrators.
|
||
|
||
\item \textbf{Performance Optimization:}
|
||
Add Redis caching layer for frequently accessed data, implement database query optimization, and add database read replicas.
|
||
|
||
\item \textbf{Mobile-Responsive Improvements:}
|
||
Enhance mobile web experience with progressive web app (PWA) features and offline capability.
|
||
\end{itemize}
|
||
|
||
\subsubsection{Medium-Term Development (6-12 months)}
|
||
|
||
\begin{itemize}
|
||
\item \textbf{Image-Based Matching:}
|
||
Implement computer vision algorithms for visual similarity matching using TensorFlow or PyTorch, enabling photo-based item identification.
|
||
|
||
\item \textbf{Native Mobile Applications:}
|
||
Develop iOS and Android native applications using React Native or Flutter for improved mobile user experience and push notification support.
|
||
|
||
\item \textbf{Machine Learning Enhancement:}
|
||
Train custom ML models on verified match data to improve matching accuracy and reduce false positives through supervised learning.
|
||
|
||
\item \textbf{Campus System Integration:}
|
||
Integrate with existing campus ID card systems, access control databases, and student information systems for streamlined user management.
|
||
|
||
\item \textbf{Reward and Incentive System:}
|
||
Implement gamification features with points, badges, and rewards to encourage reporting and claiming behavior.
|
||
\end{itemize}
|
||
|
||
\subsubsection{Long-Term Research Directions (12+ months)}
|
||
|
||
\begin{itemize}
|
||
\item \textbf{Multi-Campus Deployment:}
|
||
Extend system to support multiple institutions with shared databases, federated search, and inter-campus item matching.
|
||
|
||
\item \textbf{Predictive Analytics:}
|
||
Develop predictive models to identify high-risk locations, peak loss times, and common item types, enabling proactive prevention strategies.
|
||
|
||
\item \textbf{Blockchain-Based Verification:}
|
||
Explore blockchain technology for immutable audit trails and decentralized verification, enhancing transparency and trust.
|
||
|
||
\item \textbf{IoT Integration:}
|
||
Integrate with IoT devices (Bluetooth beacons, RFID tags) for real-time item tracking and automated loss detection.
|
||
|
||
\item \textbf{Natural Language Processing:}
|
||
Implement advanced NLP techniques for multilingual support, semantic search, and improved intent recognition in chatbot interactions.
|
||
|
||
\item \textbf{Comparative Studies:}
|
||
Conduct comparative research evaluating different string similarity algorithms (Jaro-Winkler, Cosine Similarity) and matching strategies in diverse contexts.
|
||
\end{itemize}
|
||
|
||
\subsubsection{Research Extensions}
|
||
|
||
Future research could explore:
|
||
|
||
\begin{itemize}
|
||
\item Effectiveness of different matching algorithms across various item categories
|
||
\item Impact of threshold values on user satisfaction and system efficiency
|
||
\item Comparative analysis of manual vs. automated verification workflows
|
||
\item User behavior patterns and item loss trends using data mining techniques
|
||
\item Cross-cultural adaptation of the system for international institutions
|
||
\item Integration with social media platforms for broader reach
|
||
\item Privacy-preserving techniques for sensitive personal item information
|
||
\end{itemize}
|
||
|
||
\subsection{Final Remarks}
|
||
|
||
The Lost and Found System demonstrates that modern web technologies, artificial intelligence, and thoughtful system design can significantly improve traditional manual processes. The 147\% increase in return success rate and 57\% reduction in resolution time validate the approach taken in this research.
|
||
|
||
The system's modular architecture, comprehensive security framework, and scalable design provide a solid foundation for future enhancements. The integration of AI chatbot technology showcases how large language models can augment traditional information systems with conversational interfaces and intelligent assistance.
|
||
|
||
While challenges remain—particularly in image-based matching, real-time notifications, and large-scale deployment—the current implementation proves the viability and value of automated lost and found management systems. The positive user feedback (4.4/5 satisfaction) indicates strong acceptance and adoption potential.
|
||
|
||
This research contributes practical knowledge to the fields of web application development, string matching algorithms, and AI-integrated information systems. The open architecture and documented implementation serve as a reference for similar systems in educational institutions and other high-traffic environments.
|
||
|
||
Ultimately, the Lost and Found System represents not just a technological solution, but a step toward more efficient, transparent, and user-friendly campus services. As institutions continue to grow and face increasing demands for digital solutions, systems like this will play an increasingly important role in campus operations and student services.
|
||
|
||
The journey from manual notice boards to intelligent, automated systems reflects broader trends in digital transformation. This research demonstrates that with careful design, thoughtful implementation, and attention to user needs, traditional processes can be revolutionized to serve communities more effectively in the digital age.
|
||
|
||
\section*{Acknowledgment}
|
||
|
||
The authors would like to express their sincere gratitude to all those who contributed to the successful completion of this research and the development of the Lost and Found System.
|
||
|
||
First and foremost, we extend our deepest appreciation to the Department of Informatics at Widya Mandala Kalijudan University for providing the resources, facilities, and academic environment necessary to conduct this research. Special thanks to our faculty advisors and mentors whose guidance, constructive feedback, and unwavering support throughout the research process were invaluable.
|
||
|
||
We are grateful to the university administration and campus security personnel who provided insights into the existing lost and found processes and challenges, helping us understand the real-world requirements and constraints that shaped the system design.
|
||
|
||
Our sincere thanks go to the 20 students and staff members who participated in user testing and provided honest feedback that significantly improved the system's usability and functionality. Their willingness to spend time testing various features and suggesting improvements was crucial to the system's refinement.
|
||
|
||
We acknowledge the Anthropic team for developing Claude AI and the Groq team for providing access to the LLaMA 3.3 70B Versatile model through their API, enabling the AI chatbot functionality that enhances user experience.
|
||
|
||
We appreciate the open-source community, particularly the developers of Go, React, Gin, GORM, and other libraries and frameworks that formed the foundation of our system. Standing on the shoulders of these giants made our implementation possible.
|
||
|
||
Thanks are also due to our colleagues and peers who provided technical discussions, debugging assistance, and moral support during challenging phases of development and testing.
|
||
|
||
Finally, we express our heartfelt gratitude to our families for their patience, encouragement, and understanding during the countless hours spent on research, development, and documentation.
|
||
|
||
\section*{}
|
||
|
||
\begin{thebibliography}{00}
|
||
|
||
\bibitem{b1}
|
||
R. T. Fielding, ``Architectural Styles and the Design of Network-based Software Architectures,'' Ph.D. dissertation, University of California, Irvine, 2000.
|
||
|
||
\bibitem{b2}
|
||
M. Fowler, \textit{Patterns of Enterprise Application Architecture}, Boston, MA: Addison-Wesley, 2002.
|
||
|
||
\bibitem{b3}
|
||
E. Gamma, R. Helm, R. Johnson, and J. Vlissides, \textit{Design Patterns: Elements of Reusable Object-Oriented Software}, Reading, MA: Addison-Wesley, 1994.
|
||
|
||
\bibitem{b4}
|
||
V. I. Levenshtein, ``Binary codes capable of correcting deletions, insertions, and reversals,'' \textit{Soviet Physics Doklady}, vol. 10, no. 8, pp. 707-710, 1966.
|
||
|
||
\bibitem{b5}
|
||
D. Ferraiolo and R. Kuhn, ``Role-Based Access Control,'' in \textit{15th National Computer Security Conference}, Baltimore, MD, 1992, pp. 554-563.
|
||
|
||
\bibitem{b6}
|
||
M. Jones, J. Bradley, and N. Sakimura, ``JSON Web Token (JWT),'' Internet Engineering Task Force, RFC 7519, May 2015.
|
||
|
||
\bibitem{b7}
|
||
N. Provos and D. Mazières, ``A Future-Adaptable Password Scheme,'' in \textit{Proceedings of the 1999 USENIX Annual Technical Conference}, Monterey, CA, 1999, pp. 81-92.
|
||
|
||
\bibitem{b8}
|
||
A. A. Donovan and B. W. Kernighan, \textit{The Go Programming Language}, Boston, MA: Addison-Wesley, 2015.
|
||
|
||
\bibitem{b9}
|
||
A. Banks and E. Porcello, \textit{Learning React: Modern Patterns for Developing React Apps}, 2nd ed., Sebastopol, CA: O'Reilly Media, 2020.
|
||
|
||
\bibitem{b10}
|
||
M. Kleppmann, \textit{Designing Data-Intensive Applications}, Sebastopol, CA: O'Reilly Media, 2017.
|
||
|
||
\bibitem{b11}
|
||
S. Newman, \textit{Building Microservices: Designing Fine-Grained Systems}, 2nd ed., Sebastopol, CA: O'Reilly Media, 2021.
|
||
|
||
\bibitem{b12}
|
||
T. Brown et al., ``Language Models are Few-Shot Learners,'' in \textit{Advances in Neural Information Processing Systems}, vol. 33, 2020, pp. 1877-1901.
|
||
|
||
\bibitem{b13}
|
||
H. Touvron et al., ``LLaMA: Open and Efficient Foundation Language Models,'' arXiv preprint arXiv:2302.13971, 2023.
|
||
|
||
\bibitem{b14}
|
||
P. Groves, B. Kayyali, D. Knott, and S. Van Kuiken, ``The 'big data' revolution in healthcare: Accelerating value and innovation,'' \textit{McKinsey \& Company}, 2013.
|
||
|
||
\bibitem{b15}
|
||
C. Richardson, \textit{Microservices Patterns: With Examples in Java}, Shelter Island, NY: Manning Publications, 2018.
|
||
|
||
\bibitem{b16}
|
||
B. Burns, J. Beda, K. Hightower, and L. Evenson, \textit{Kubernetes: Up and Running}, 2nd ed., Sebastopol, CA: O'Reilly Media, 2019.
|
||
|
||
\bibitem{b17}
|
||
M. Feathers, \textit{Working Effectively with Legacy Code}, Upper Saddle River, NJ: Prentice Hall, 2004.
|
||
|
||
\bibitem{b18}
|
||
R. C. Martin, \textit{Clean Architecture: A Craftsman's Guide to Software Structure and Design}, Boston, MA: Prentice Hall, 2017.
|
||
|
||
\bibitem{b19}
|
||
S. J. Metsker and W. C. Wake, \textit{Design Patterns in Java}, 2nd ed., Boston, MA: Addison-Wesley, 2006.
|
||
|
||
\bibitem{b20}
|
||
J. Nielsen, \textit{Usability Engineering}, San Francisco, CA: Morgan Kaufmann, 1993.
|
||
|
||
\bibitem{b21}
|
||
D. S. Hirschberg, ``Algorithms for the Longest Common Subsequence Problem,'' \textit{Journal of the ACM}, vol. 24, no. 4, pp. 664-675, Oct. 1977.
|
||
|
||
\bibitem{b22}
|
||
W. E. Winkler, ``String Comparator Metrics and Enhanced Decision Rules in the Fellegi-Sunter Model of Record Linkage,'' in \textit{Proceedings of the Section on Survey Research Methods}, American Statistical Association, 1990, pp. 354-359.
|
||
|
||
\bibitem{b23}
|
||
A. Z. Broder, ``On the resemblance and containment of documents,'' in \textit{Proceedings of Compression and Complexity of Sequences}, Salerno, Italy, 1997, pp. 21-29.
|
||
|
||
\bibitem{b24}
|
||
S. Chaudhuri, V. Ganti, and R. Motwani, ``Robust identification of fuzzy duplicates,'' in \textit{Proceedings of the 21st International Conference on Data Engineering (ICDE)}, Tokyo, Japan, 2005, pp. 865-876.
|
||
|
||
\bibitem{b25}
|
||
J. Grover and R. Gupta, ``Lost and Found Management System Using QR Code,'' \textit{International Journal of Computer Applications}, vol. 134, no. 12, pp. 1-4, Jan. 2016.
|
||
|
||
\bibitem{b26}
|
||
S. Kumar and R. Singh, ``RFID Based Lost Item Tracker System,'' \textit{International Journal of Engineering Research and Technology}, vol. 4, no. 5, pp. 620-623, May 2015.
|
||
|
||
\bibitem{b27}
|
||
L. Zhang et al., ``Deep Learning Based Image Recognition for Lost and Found Items,'' in \textit{Proceedings of the 2020 IEEE International Conference on Image Processing (ICIP)}, Abu Dhabi, UAE, 2020, pp. 2891-2895.
|
||
|
||
\bibitem{b28}
|
||
Meta AI, ``LLaMA 3: Meta's Next Generation Large Language Model,'' Technical Report, Meta AI Research, 2024.
|
||
|
||
\bibitem{b29}
|
||
Anthropic, ``Claude 3 Model Card,'' Anthropic Technical Documentation, 2024.
|
||
|
||
\bibitem{b30}
|
||
Groq, ``Groq LPU Inference Engine: Technical Overview,'' Groq Technical Documentation, 2024.
|
||
|
||
\end{thebibliography}
|
||
|
||
\end{document}
|