Ở các hệ thống hội thoại khi người dùng đưa ra câu hỏi hoặc sự kiện bất kỳ đến hệ thống, hệ thống sẽ xử lý truy vấn để tìm ra ý định phù hợp thông qua luồng nghiệp vụ được xây dựng để tiến hành trích xuất các tham số. Luồng nghiệp vụ đó dựa trên các tham số, truy vấn dữ liệu từ cơ sở dữ liệu hoặc hệ thống bên thứ ba để đưa ra hành động hoặc câu trả lời phù hợp với ý định. Cuối cùng hệ thống gửi câu trả lời hoặc hành động tương ứng về cho người dùng. Với mỗi bộ dữ liệu hoặc API bên thứ ba khác nhau thì cần xây dựng luồng nghiệp vụ phù hợp để có được kết quả chính xác
Giới thiệu đề tài
Đặt vấn đề
Hình 1 Dialogflow 1 Ở các hệ thống hội thoại khi người dùng đưa ra câu hỏi hoặc sự kiện bất kỳ đến hệ thống, hệ thống sẽ xử lý truy vấn để tìm ra ý định phù hợp thông qua luồng nghiệp vụ được xây dựng để tiến hành trích xuất các tham số Luồng nghiệp vụ đó dựa trên các tham số, truy vấn dữ liệu từ cơ sở dữ liệu hoặc hệ thống bên thứ ba để đưa ra hành động hoặc câu trả lời phù hợp với ý định Cuối cùng hệ thống gửi câu trả lời hoặc hành động tương ứng về cho người dùng Với mỗi bộ dữ liệu hoặc API bên thứ ba khác nhau thì cần xây dựng luồng nghiệp vụ phù hợp để có được kết quả chính xác
Dữ liệu từ cơ sở dữ liệu dùng để trả kết quả cho ý định chia làm hai dạng Dạng thứ nhất là các tri thức gắn với dữ liệu để huấn luyện Khi các dữ liệu này thay đổi thì cần huấn luyện lại làm mất nhiều thời gian, tài nguyên và công sức Dạng thứ hai là các tri thức độc lập, không nằm trong dữ liệu huấn luyện Để hệ thống hội thoại có thể sử dụng các tri thức dạng này cần viết các API truy vấn dữ liệu Việc người phát triển viết từng API cho mỗi tri thức
1 https://ignitevisibility.com/why-dialogflow-is-the-future-of-marketing/, Truy cập lần cuối 31/12/2021
Chương 1 Giới thiệu đề tài sẽ rất mất công, khó khăn và tốn tài nguyên khi có sự thay đổi dữ liệu, cập nhật sửa đổi API hay phát triển cho hệ thống khác
Ví dụ các hệ thống QA hay bot sẽ có phần dữ liệu dùng để training, sau khi training thành công phần dữ liệu này sẽ trở thành tri thức để bot truy vấn Với các tri thức phức tạp cần hệ thống riêng để quản lý, viết riêng API cho nó Nếu tri thức không quá phức tạp thì có thể tổng quát cho nhiều ứng dụng chatbot, callbot, khác nhau để có thể sử dụng cho nhiều domain, cơ quan, tổ chức
Ngoài các dữ liệu được lưu trong cơ sở dữ liệu, các hệ thống hội thoại còn sử dụng dữ liệu từ bên thứ ba thông quan API được cung cấp Ví dụ các ứng dụng bot về dự báo thời tiết để có dữ liệu trả lời thì cần được cơ quan khí tượng thủy văn quốc gia cấp API để truy vấn dữ liệu về thời tiết Các API được cung cấp như thế thường dữ liệu trả về các ứng dụng chưa sử dụng được ngay mà cần xây dựng nghiệp vụ để cấu hình lại dữ liệu Điều đó gây khó khăn trong việc quản lý vì bên thứ ba thay đổi cấu trúc của dữ liệu hay cấu hình API thì các ứng dụng cũng cần sửa lại nghiệp vụ, khởi động lại hệ thống hay các thay đổi khác để bot có dữ liệu chính xác
Chính vì vậy em tạo ra “Hệ thống quản lý tri thức và xây dựng API cho bot” để quản lý tri thức và API tập trung, dễ dàng sử dụng xây dựng bot, không cần xây dựng lại tri thức hay API khi có thay đổi, nâng cấp hay thêm mới Đồng thời trong quá trình phát triển tiếp theo của hệ thống, em có thể xây dựng thêm các tính năng mới phù hợp với yêu cầu của người dùng.
Mục tiêu và phạm vi đề tài
Từ những vấn đề đặt ra ở phần 1.1, mục tiêu đặt ra là phát triển hệ thống (i) quản lý tri thức và (ii) xây dựng api cho bot có thể được sử dụng để truy vấn dữ liệu Trong đó, hệ thống quản lý tri thức cho phép tạo các bộ tri thức, mỗi bộ tri thức là tập hợp của các bộ dữ liệu có cùng mục đích sử dụng Với mỗi bộ tri thức, hệ thống cần hiển thị đầy đủ dữ liệu của bộ tri thức đó, có cách thức nhập liệu phù hợp với mọi người dùng, có thể theo dõi, kiểm soát được sự thay đổi dữ liệu Đồng thời cũng cần có hướng dẫn để người dùng có thể dễ dàng tạo bộ tri thức cho mình Bên cạnh đó với mỗi bộ tri thức cũng cần cung cấp các API để dễ dàng truy vấn dữ liệu Các API được tạo ra sẽ tiếp tục được phát triển, quản lý ở hệ thống xây dựng API Hệ thống này cần hiển thị đầy đủ thông tin liên quan đến API, cho phép người dùng thử nghiệm các API, qua đó người quản lý có thể nắm bắt được tình hình sử dụng dữ liệu Để xây dựng được hệ thống như trên em cần tìm hiểu và thiết kế một kiến trúc có thể truy
Các bộ tri thức và API được xây dựng cần tuân theo một quy trình để đảm bảo tính toàn vẹn và bảo mật dữ liệu Bên cạnh đó hệ thống cần có giao diện thân thiện, phù hợp với đa dạng người dùng và dễ dàng phát triển thêm tính năng mới.
Định hướng giải pháp
Do hệ thống lấy dữ liệu làm tiền đề, cho phép truy vấn dữ liệu từ nhiều hệ thống khác nhau nên cần thiết kế để xây dựng được tri thức từ bộ dữ liệu, lưu trữ được nhiều dữ liệu, dễ dàng tạo và chỉnh sửa Hệ thống cho phép tạo cấu trúc dữ liệu động để có thể xác định được cấu trúc của mỗi bộ dữ liệu và xây dựng lên cấu trúc cho từng tri thức từ đó dễ dàng thêm dữ liệu thành cùng một chủ đề Để hệ thống có thể lưu trữ dữ liệu linh hoạt theo cấu trúc dữ liệu động thì hệ thống sử dụng MongoDB làm cơ sở dữ liệu MongoDB cho phép lưu trữ được nhiều dữ liệu giải quyết vấn đề lưu dữ liệu lớn, cho phép lưu dữ liệu phi chuẩn, cấu trúc linh hoạt giúp giải quyết sự đa dạng về các bộ dữ liệu khi xây dựng cấu trúc dữ liệu cho từng bộ Bên cạnh đó tốc độ xử lý dữ liệu với Mongo cũng rất nhanh giúp cho việc truy vấn không mất nhiều thời gian
Hệ thống cho phép xây dựng các API để truy vấn dữ liệu từ các bộ tri thức, sẽ sinh các API tự động cho tri thức khi tri thức được tạo đồng thời nó cũng cho phép người dùng tạo các API cho tri thức theo mục đích sử dụng Ngoài ra một ứng dụng bot muốn sử dụng dữ liệu của bên thứ 3 nhưng chỉ được cung cấp API truy vấn dữ liệu, dữ liệu trả về chưa thể sử dụng được ngay thì người dùng có thể xây dựng API trung gian để chuẩn hóa dữ liệu đưa về dạng phù hợp với nhu cầu Hệ thống sẽ quản lý các API được tạo ra một cách tập trung, thống nhất về mặt truy vấn và cho phép theo dõi lịch sử truy vấn Để xây dựng hệ thống như vậy em chia hệ thống thành 2 phần là frontend và backend tương tác với nhau qua RESTful API phát triển trên nền tảng web Frontend em sử dụng ReactJS vì đây là một thư viện tập trung vào xây dựng giao diện có thể tách giao diện thành các thành phần nhỏ hơn dễ dàng cho việc tái sử dụng và phát triển trang web Để đồng nhất về ngôn ngữ và định dạng dữ liệu với frontend thì backend em lựa chọn NodeJS với hiệu năng tốt, có thể xử lý sự kiện bất đồng bộ Việc cùng ngôn ngữ Javascript giúp tiết kiệm thời gian xây dựng và giảm bớt lỗi hơn MongoDB sẽ được sử dụng làm cơ sở dữ liệu và Redis hỗ trợ truy vấn API một cách nhanh chóng.
Bố cục đồ án
Phần còn lại của báo cáo đồ án tốt nghiệp này được tổ chức như sau
Chương 2 trình bày đóng góp và giải pháp đặt ra để giải quyết các vấn đề và xây dựng hệ thống quản lý tri thức và xây dựng API cho bot
Trong Chương 3 là các phân tích thiết kế hệ thống, đưa ra tổng quan chức năng và mô tả các chức năng chính
Tiếp đến Chương 4 mô tả các công nghệ sử dụng và chi tiết về quá trình xây dựng và triển khai hệ thống
Cuối cùng Chương 5 tổng kết nội dung đồ án, nêu ra những thành công đạt được, những thiếu sót cần cải thiện và các định hướng phát triển cho tương lai
Dựa trên những vấn đề và mục tiêu em đưa ra ở Chương 1, Chương 2 sẽ đưa ra các giải pháp để giải quyết các vấn đề và đạt được mục tiêu xây dựng được hệ thống quản lý tri thức và tích hợp API áp dụng cho bất kỳ hệ thống hội thoại nào
Với những hệ thống liên quan đến xử lý, lưu trữ và truy vấn dữ liệu thì cần đảm bảo lưu trữ được nhiều dữ liệu, dữ liệu có dụng lượng lớn như ảnh, audio, Việc xử lý và truy vấn cũng cần diễn ra nhanh chóng đặc biệt với các bộ dữ liệu lớn Dữ liệu được trả về từ API thì phải nhanh và chính xác Bên cạnh đó vì cần tạo ra được API từ kho tri thức có sẵn nên cần có sự gắn kết giữa API và tri thức được tạo ra, dữ liệu trả về khi truy vấn API cần chính xác theo tri thức Ngoài ra để hệ thống đáp ứng được số lượng người dùng và yêu cầu lớn, dễ dàng bảo trì sửa lỗi thì có thể chia nhỏ hệ thống dựa trên các tính năng theo kiến trúc microservices
Dựa trên những vấn đề trên, em đã thiết kế kiến trúc hệ thống quản lý tri thức và xây dựng API để đảm bảo tối ưu hiệu năng xử lý dữ liệu và dễ dàng quản lý
Hình 2 mô tả kiến trúc tổng quan hệ thống quản lý tri thức và tích hợp API bao gồm hai dịch vụ chính xây dựng theo kiến trúc microservice là:(i) Dịch vụ tri thức và (ii) Dịch vụ API Để sử dụng được các dịch vụ của hệ thống quản lý tri thức và tích hợp API người dùng cần thực hiện đăng nhập thông qua hệ thống IAM Các hệ thống hội thoại sẽ thông qua Gateway API để tương tác với hệ thống để truy vấn dữ liệu từ tri thức được lưu trong cơ sở dữ liệu của hệ thống hoặc thông qua API tích hợp để truy vấn dữ liệu từ bên thứ ba Các API cung cấp để các hệ thống hội thoại truy vấn sẽ dùng được ngay mà không cần phải cấu hình, lập trình hay xây dựng các luồng hội thoại riêng.
Giải pháp quản lý tri thức và tích hợp API
Kiến trúc tổng quan
Với những hệ thống liên quan đến xử lý, lưu trữ và truy vấn dữ liệu thì cần đảm bảo lưu trữ được nhiều dữ liệu, dữ liệu có dụng lượng lớn như ảnh, audio, Việc xử lý và truy vấn cũng cần diễn ra nhanh chóng đặc biệt với các bộ dữ liệu lớn Dữ liệu được trả về từ API thì phải nhanh và chính xác Bên cạnh đó vì cần tạo ra được API từ kho tri thức có sẵn nên cần có sự gắn kết giữa API và tri thức được tạo ra, dữ liệu trả về khi truy vấn API cần chính xác theo tri thức Ngoài ra để hệ thống đáp ứng được số lượng người dùng và yêu cầu lớn, dễ dàng bảo trì sửa lỗi thì có thể chia nhỏ hệ thống dựa trên các tính năng theo kiến trúc microservices
Dựa trên những vấn đề trên, em đã thiết kế kiến trúc hệ thống quản lý tri thức và xây dựng API để đảm bảo tối ưu hiệu năng xử lý dữ liệu và dễ dàng quản lý
Hình 2 mô tả kiến trúc tổng quan hệ thống quản lý tri thức và tích hợp API bao gồm hai dịch vụ chính xây dựng theo kiến trúc microservice là:(i) Dịch vụ tri thức và (ii) Dịch vụ API Để sử dụng được các dịch vụ của hệ thống quản lý tri thức và tích hợp API người dùng cần thực hiện đăng nhập thông qua hệ thống IAM Các hệ thống hội thoại sẽ thông qua Gateway API để tương tác với hệ thống để truy vấn dữ liệu từ tri thức được lưu trong cơ sở dữ liệu của hệ thống hoặc thông qua API tích hợp để truy vấn dữ liệu từ bên thứ ba Các API cung cấp để các hệ thống hội thoại truy vấn sẽ dùng được ngay mà không cần phải cấu hình, lập trình hay xây dựng các luồng hội thoại riêng
Chương 2 Giải pháp quản lý tri thức và tích hợp API
Cấu trúc cơ sở dữ liệu được xây dựng theo mô hình “Master-slave pattern” chia làm 1 master và 2 slaver Trong đó master đóng vai trò thêm, sửa, xóa dữ liệu Dữ liệu từ master dược phân phối và đồng bộ với slave Dữ liệu truy vấn từ các API sẽ được trả về từ slave
Hình 2 Kiến trúc tổng quan hệ thống quản lý tri thức và tích hợp API
Dịch vụ tri thức chịu trách nhiệm quản lý tri thức bao gồm tạo tri thức, xử lý truy vấn dữ liệu, theo dõi lịch sử dữ liệu, quản lý nhập liệu và tạo API cho tri thức Mỗi bộ tri thức sẽ thuộc về một chủ đề theo nhu cầu trả lời của bot, được đảm bảo là duy nhất để chính xác khi truy vấn
Dịch vụ API chịu trách nhiệm quản lý, xây dựng các API, xử lý các truy vấn từ bot Khi nhận được truy vấn, dịch vụ sẽ kiểm tra xem API đã từng được truy vấn trong một khoảng thời gian được quy định sẵn trong hệ thống chưa bằng cách kiểm tra dữ liệu trong cache
Nếu có sẽ truy vấn dữ liệu từ cache, nếu không có sẽ truy vấn dữ liệu từ 1 trong 2 slaver của cấu trúc cơ sở dữ liệu và lưu dữ liệu vừa được truy vấn vào cache Việc truy vấn như vậy sẽ giúp truy vấn nhanh hơn vì dữ liệu ở cache của máy chủ, nếu dữ liệu đã có thì sẽ không phải gọi lên server của cơ sở dữ liệu.
Dịch vụ tri thức
Dịch vụ tri thức cung cấp các tính năng để quản lý tri thức cho bot như tạo tri thức, quản lý cấu trúc dữ liệu động, xây dựng dữ liệu, theo dõi lịch sử dữ liệu, sinh API tự động cho tri tính năng sinh API tự động trình bày ở phần 2.2.2 là nổi bật nhất, làm tiền đề để tạo nên tri thức và làm cơ sở để tạo API động cho tri thức
2.2.1 Quản lý cấu trúc dữ liệu động
Hình 3 Mô tả cơ sở dữ liệu của cấu trúc dữ liệu động theo NoSQL
Dữ liệu dành cho bot rất đa dạng, với mỗi nội dung, mục đích trả lời cần bộ dữ liệu khác nhau Mỗi câu trả lời sẽ được dựa vào từ khóa trong câu hỏi để tìm dữ liệu và trả lời thích hợp Khi đó mỗi bộ dữ liệu sẽ cần thu thập các câu trả lời và lưu trữ theo từ khóa Các từ khóa liên quan đến cùng một chủ đề sẽ được tập hợp thành cùng một bộ tri thức Để mỗi bộ tri thức có thể dễ dàng lưu trữ dữ liệu như thế cần xác định trước cấu trúc dữ liệu cho nó Mỗi bộ tri thức sẽ được xây dựng cấu trúc dữ liệu trước khi thêm dữ liệu Cấu trúc dữ liệu sẽ cho phép xây dựng cơ sở nhập liệu của mỗi tri thức, giúp mỗi tri thức sẽ là tập hợp dữ liệu của một chủ đề nhất định, dễ dàng xây dựng dữ liệu cho bot theo các chủ đề khác nhau, đồng thời dễ dàng quản lý và xây dựng các API truy vấn Việc mỗi bộ tri thức có một cấu trúc dữ liệu riêng xây dựng theo mỗi trường dữ liệu sẽ tạo thành cấu trúc dữ liệu động Và để đảm bảo lưu trữ dữ liệu theo cấu trúc linh hoạt thì cơ sở dữ liệu sẽ thiết kế theo NoSQL
Cấu trúc dữ liệu động được xây dựng từ nhiều nguồn dựa theo nguồn dữ liệu (biểu mẫu, file dữ liệu) và dựa trên kiểu dữ liệu của mỗi trường dữ liệu Mỗi trường dữ liệu sẽ có cách để lưu trữ cấu hình khác nhau và khi thêm dữ liệu sẽ có cách lưu dữ liệu theo từng trường khác nhau để tạo thành bộ dữ liệu của tri thức dựa trên tính chất kiểu dữ liệu của nó như Hình 3 Cấu hình mỗi trường dữ liệu sẽ được lưu thành bộ cấu trúc dữ liệu và các bộ dữ liệu sẽ được tạo thành từ các trường đó Với các kiểu dữ liệu dạng lựa chọn như trắc nghiệm hay danh sách cần có danh sách các lựa chọn để người dùng có thể chọn hoặc có thể cho người dùng thêm câu trả lời khác Với các kiểu dữ liệu file đa phương tiện như hình ảnh hay âm thanh thì dư xlieeuj khi lưu cần có tên file, loại file và dữ liệu cần nén lại để lưu
Bảng 1 Thiết kế cơ sở dữ liệu cho cấu trúc dữ liệu của tri thức
Thông tin Kiểu dữ liệu Mô tả field String Tên trường dữ liệu dataType String Kiểu câu trả lời description String Mô tả obligate Boolean Bắt buộc trả lời hay không key Boolean Có phải trường định danh không options Array Danh sách các lựa chọn cho câu trả lời dạng lựa chọn other Boolean Xác định có cho phép thêm câu trả lời cho dạng lựa chọn
2.2.2 Sinh API cho tri thức
Các bộ tri thức sau khi được tạo sẽ tự động sinh ra các API để truy vấn dữ liệu từ tri thức 6 loại API được sinh tự động, tổng quát cho mọi tri thức là: “API lấy danh sách bản ghi” (Lấy ra toàn bộ dữ liệu của tri thức), “API lấy dữ liệu một bản ghi” (Lấy ra các bộ dữ liệu đáp ứng được điều kiện), “API lấy dữ liệu có điều kiện” (Lấy dữ liệu sao cho chỉ lấy các trường được chỉ định, các bộ dữ liệu lấy ra cần đáp ứng được điều kiện nếu có), “API thêm bộ dữ liệu” (Thêm bộ dữ liệu mới cho tri thức), “API chỉnh sửa dữ liệu” (Chỉnh sửa bộ dữ liệu đáp ứng điều kiện), “API xóa dữ liệu” (Xóa bộ dữ liệu đáp ứng điều kiện)
Bảng 2 Danh sách API tri thức tổng quát
API Phương thức Địa chỉ
Lấy danh sách bản ghi GET /api/v1/datas/:uniqueId
Lấy dữ liệu một bản ghi GET /api/v1/datas/:uniqueId/{conditionList}
Dữ liệu có đều kiện GET /api/v1/datas/:uniqueId/{fieldList}?
Thêm bộ dữ liệu POST /api/v1/datas/:uniqueId
Chỉnh sửa bộ dữ liệu PUT /api/v1/datas/:uniqueId
Xóa bộ dữ liệu DELETE /api/v1/datas/:uniqueId
Dịch vụ API
Dịch vụ API cung cấp các tính năng quản lý các API được tạo ra và xử lý truy vấn dữ liệu từ API Trong đó 2 tính năng chính là quản lý API tri thức phần 2.3.1 và quản lý API tích hợp phần 2.3.2
2.3.1 Quản lý API tri thức Để các ứng dụng bot có thể truy vấn dữ liệu từ tri thức thì cần có API để truy vấn API truy vấn dữ liệu có 2 dạng Dạng thứ nhất là các API mặc định, tổng quan cho mọi trường hợp được sinh ra khi tri nhức được tạo thành công ở phần 2.2.2 Dạng thứ 2 là các API tùy biến được người quản lý tri thức tạo ra theo nhu cầu sử dụng với tri thức dựa trên 6 loại API mặc định
Sau khi các API được sinh ra, hệ thống sẽ cho phép những người đủ quyền hạn xem được cách thức sử dụng, thông tin cơ bản, các luật giúp bảo mật dữ liệu của API đồng thời cũng cho phép dùng thử các API trước Người có quyền sử dụng cần nhập chính xác URL, phương thức truy cập API và cung cấp chính xác các điều luật để có thể sử dụng
Hình 4 Minh họa truy vấn dữ liệu từ API tri thức
Các ứng dụng sử dụng API để truy vấn dữ liệu từ các bộ tri thức sẽ qua cùng một bộ quản lý API tri thức Bộ quản lý sẽ tiếp nhận các yêu cầu và xử lý lấy dữ liệu từ tri thức tương ứng để trả về kết quả truy vấn cho ứng dụng Để tránh quá tải khi có nhiều truy vấn cùng một lúc thì hệ thống được triển khai trên nhiều máy chủ khác nhau Các máy chủ sẽ dùng chung một bộ quản lý API tri thức để xử lý
2.3.2 Quản lý API tích hợp
Tính năng quản lý API tích hợp sẽ cho phép chuyển đổi API tích hợp của bên thứ 3 thành API trung gian API trung gian sẽ được sử dụng để tích hợp thay cho API bên thứ 3
Hình 5 Tính năng quản lý API tích hợp
Hình 6 Luồng tạo API tích hợp
Khi người dùng sử dụng tính năng để tạo API trung gian thì API bên thứ 3 sẽ được chuyển đổi định dạng dữ liệu trả về, chuẩn hóa tên trường dữ liệu, lựa chọn các trường dữ liệu cần lấy dữ liệu sao cho phù hợp với nhu cầu Bên cạnh đó người dùng có thể chuyển đổi điều kiện bảo mật sao cho API được tích hợp linh hoạt và phân được cho nhiều người sử dụng nhưng vẫn đảm bảo về vấn đề bảo mật API trung gian sẽ sử dụng REST để xử lý truy vấn thay vì các phương thức khác nhau mà API bên thứ 3 sử dụng
Khi API trung gian được tích hợp và truy vấn, hệ thống sẽ kiểm tra điều kiện bảo mật Sau khi điều kiện bảo mật của API trung gian được đáp ứng, hệ thống sẽ tiến hành truy vấn API bên thứ 3 kèm điều kiện bảo mật của API bên thứ 3 Kết quả truy vấn sẽ được kiểm tra điều kiện đầu vào để lấy dữ liệu cần thiết và chuyển đổi phù hợp với định dạng dữ liệu được thiết lập cho API trung gian và trả về cho người dùng
Hình 7 Luồng truy vấn API tích hợp Để hiện thực hóa những giải pháp trên thành hệ thống quản lý tri thức và truy cập API cho bot thì cần qua quá trình phân tích thiết kế, xây dựng và triển khai Quá trình này sẽ được trình bày ở Chương 3 và Chương 4 Để xây dựng được hệ thống quản lý tri thức và xây dựng API cho bot thì em đã tiến hành phân tích thiết kế để đưa ra được các chức năng, yêu cầu cũng như là các thiết kế chính cho hệ thống Các nội dung của quá trình phân tích thiết kế hệ thống sẽ được em trình bày trong chương này
3.1.1 Biểu đồ use case tổng quan
Hệ thống quản lý tri thức và xây dựng API cho bot gồm nhiều thành phần và chức năng Hình 8 thể hiện các chức năng tổng quan và các tác nhân chính của hệ thống
Hình 8 Biểu đồ use case tổng quan
Hệ thống gồm 3 tác nhân chính, đó là: Người sở hữu, Người nhập liệu, Người phát triển Các tác nhân trên là người dùng sau khi đăng nhập vào hệ thống Mỗi người dùng sẽ trở thành tác nhân tương ứng với quyền được phân cho tri thức hoặc API:
• Người sở hữu:Là người tạo ra tri thức hoặc API Có các chức năng liên quan đến quản lý tri thức hoặc API do mình tạo ra như: Phân quyền người dùng, xem chi tiết, chỉnh sửa dữ liệu, theo dõi lịch sử, khôi phục dữ liệu, cập nhật API
• Người nhập liệu: Là người được phân vai trò nhập dữ liệu cho tri thức
• Người phát triển: Là sử dụng API cho hệ thống hội thoại.
Phân tích thiết kế hệ thống
Tổng quan chức năng
3.1.1 Biểu đồ use case tổng quan
Hệ thống quản lý tri thức và xây dựng API cho bot gồm nhiều thành phần và chức năng Hình 8 thể hiện các chức năng tổng quan và các tác nhân chính của hệ thống
Hình 8 Biểu đồ use case tổng quan
Hệ thống gồm 3 tác nhân chính, đó là: Người sở hữu, Người nhập liệu, Người phát triển Các tác nhân trên là người dùng sau khi đăng nhập vào hệ thống Mỗi người dùng sẽ trở thành tác nhân tương ứng với quyền được phân cho tri thức hoặc API:
• Người sở hữu:Là người tạo ra tri thức hoặc API Có các chức năng liên quan đến quản lý tri thức hoặc API do mình tạo ra như: Phân quyền người dùng, xem chi tiết, chỉnh sửa dữ liệu, theo dõi lịch sử, khôi phục dữ liệu, cập nhật API
• Người nhập liệu: Là người được phân vai trò nhập dữ liệu cho tri thức
• Người phát triển: Là sử dụng API cho hệ thống hội thoại
Chương 3 Phân tích thiết kế hệ thống
3.1.2 Biểu đồ use case phân rã quản lý tri thức
Hình 9 Biểu đồ use case phân rã quản lý tri thức
Với chức năng quản lý tri thức người dùng có thể Tạo tri thức, Tạo cấu trúc dữ liệu, Tạo dữ liệu, Chỉnh sửa tri thức, Xóa tri thức, Theo dõi lịch sử tri thức như Hình 9
3.1.3 Biểu đồ use case phân rã quản lý API
Với chức năng quản lý API người dùng có thể Tạo API, Chỉnh sửa API, Thử nghiệm API, Kiểm soát API như Hình 10
Hình 11 Biểu đồ hoạt động quy trình tạo tri thức
Dịch vụ quản lý tri thức có quy trình nghiệp vụ quan trọng là tạo tri thức với mô tả như sau: Người sở hữu tạo các thông tin cơ bản cho tri thức bao gồm tên, ID và danh sách người nhập liệu, sau đó người sở hữu tạo cấu trúc dữ liệu cho tri thức, cuối cùng dựa trên cấu trúc dữ liệu để tạo dữ liệu Hình 11 mô tả quy trình tạo tri thức.
Đặc tả chức năng
Phần này sẽ đặc tả các chức năng chính của hệ thống Do dung lượng đồ án có hạn em sẽ trình bày 7 use case: (i) Tạo thông tin tri thức, (ii) Tạo cấu trúc dữ liệu, (iii) Tạo dữ liệu, (iv) Nhập dữ liệu cho tri thức, (v) Tạo API tùy biến, (vi) Tạo API tích hợp, (vii) Truy cập API
3.2.1 Đặc tả use case Tạo thông tin tri thức
Bảng 3 Đặc tả use case Tạo thông tin tri thức
Mã use case UC001 Tên use case Tạo thông tin tri thức
Tác nhân Người sở hữu
Tiền điều kiện Người tạo tri thức đăng nhập thành công vào hệ thống
Luồng sự kiện chính (thành công)
STT Thực hiện bởi Hành động
1 Hệ thống Lấy danh sách người dùng có trong hệ thống
2 Người sở hữu Nhập tên tri thức
3 Người sở hữu Thêm ID cho tri thức
4 Hệ thống Kiểm tra xem ID đã tồn tại chưa
5 Người sở hữu Thêm người nhập liệu cho tri thức
6 Người sở hữu Xác nhận thông tin tri thức được tạo
7 Hệ thống Lưu thông tin tri thức
Luồng sự kiện thay thế
STT Thực hiện bởi Hành động 1a Hệ thống Thông báo nếu lấy danh sách người dùng lỗi 4a Hệ thống Thông báo nếu ID đã tồn tại
3.2.2 Đặc tả use case Tạo cấu trúc dữ liệu
Bảng 4 Đặc tả use case Tạo cấu trúc dữ liệu
Mã use case UC002 Tên use case Tạo cấu trúc dữ liệu
Tác nhân Người sở hữu
STT Thực hiện bởi Hành động
1 Người sở hữu Lựa chọn cách tạo cấu trúc dữ liệu
2 Hệ thống Xử lý hiển thị giao diện tạo tương ứng với cách tạo
3 Người sở hữu Thiết lập thông tin các trường dữ liệu
4 Người sở hữu Xác nhận cấu trúc dữ liệu được tạo
5 Hệ thống Lưu cấu trúc dữ liệu
Luồng sự kiện thay thế STT Thực hiện bởi Hành động
2a Hệ thống Thông báo và yêu cầu lựa chọn lại cách tạo cấu trúc dữ liệu nếu xử lý lỗi
3.2.3 Đặc tả use case Tạo dữ liệu
Bảng 5 Đặc tả use case Tạo dữ liệu
Mã use case UC003 Tên use case Tạo dữ liệu
Tác nhân Người sở hữu
Người tạo tri thức hoàn thành xong bước tạo cấu trúc dữ liệu
STT Thực hiện bởi Hành động
1 Người sở hữu Lựa chọn cách tạo dữ liệu
2 Hệ thống Xử lý hiển thị giao diện tạo tương ứng với cách tạo
3 Người sở hữu Thêm dữ liệu mới
4 Hệ thống Xử lý và kiểm tra dữ liệu có đúng cấu trúc không
5 Hệ thống Lưu dữ liệu
Luồng sự kiện thay thế STT Thực hiện bởi Hành động
2a Hệ thống Thông báo và yêu cầu lựa chọn lại cách tạo dữ liệu nếu xử lý lỗi 4a Hệ thống Thông báo nếu dữ liệu không đúng cấu trúc
3.2.4 Đặc tả use case Nhập dữ liệu cho tri thức
Bảng 6 Đặc tả use case Nhập dữ liệu cho tri thức
Mã use case UC005 Tên use case Nhập dữ liệu cho tri thức
Tác nhân Người nhập liệu
Người nhập liệu đăng nhập thành công
STT Thực hiện bởi Hành động
Truy cập vào đường dẫn nhập liệu được chia sẻ
2 Hệ thống Tìm kiếm tri thức được nhập dữ liệu
3 Hệ thống Kiểm tra quyền nhập liệu của người nhập liệu
4 Hệ thống Tạo biểu mẫu nhập liệu theo cấu trúc dữ liệu
5 Hệ thống Hiển thị biểu mẫu nhập liệu
Nhập các câu trả lời cho biểu mẫu
Xác nhận gửi biểu mẫu
8 Hệ thống Kiểm tra dữ liệu của người nhập liệu
9 Hệ thống Cập nhật danh sách dữ liệu của tri thức
10 Hệ thống Lưu tri thức sau khi cập nhật
11 Hệ thống Tạo lịch sử dữ liệu tri thức với dữ liệu mới
12 Hệ thống Hiển thị kết quả nhập liệu
Luồng sự kiện thay thế
STT Thực hiện bởi Hành động 2a Hệ thống Thông báo nếu tri thức không tồn tại
3a Hệ thống Thông báo nếu người nhập liệu không có quyền thêm dữ liệu cho tri thức
8a Hệ thống Thông báo nếu dữ liệu mới không đúng cấu trúc
3.2.5 Đặc tả use case Tạo API tùy biến
Bảng 7 Đặc tả use case Tạo API tùy biến
Mã use case UC010 Tên use case Tạo API tùy biến
Tác nhân Người sở hữu
Người tạo API đăng nhập thành công vào hệ thống
STT Thực hiện bởi Hành động
1 Người sở hữu Chọn tạo API tri thức
2 Hệ thống Lấy danh sách ID của các tri thức mà người sở hữu có quyền tạo API tùy biến và hiển thị các thông tin cần thêm để tạo API
3 Người sở hữu Lựa chọn tri thức cần tạo
4 Hệ thống Lấy ra các trường cấu trúc dữ liệu của tri thức được chọn
5 Người sở hữu Chọn loại API
6 Hệ thống Hiển thị các thông tin cần thêm tương ứng với loại API đã chọn
7 Người sở hữu Thêm các thông tin dựa trên loại API đã chọn
8 Người sở hữu Thêm người phát triển và điều kiện bảo mật cho API nếu cần
9 Người sở hữu Xác nhận tạo API
10 Hệ thống Xử lý và lưu API vào cơ sở dữ liệu
Luồng sự kiện thay thế STT Thực hiện bởi Hành động
10a Hệ thống Thông báo nếu API đã tồn tại hoặc lỗi khi lưu API
3.2.6 Đặc tả use case Tạo API tích hợp
Bảng 8 Đặc tả use case Tạo API tích hợp
Mã use case UC006 Tên use case Tạo API tích hợp
Tác nhân Người sở hữu
Người tạo API đăng nhập thành công vào hệ thống
API bên thứ 3 đã tồn tại
STT Thực hiện bởi Hành động
1 Người sở hữu Chọn tạo API tích hợp
2 Hệ thống Hiển thị giao diện có các thông tin để tạo
3 Người sở hữu Thêm đầy đủ các thông tin để truy cập API bên thứ 3
4 Người sở hữu Xác nhận truy cập
5 Hệ thống Xử lý truy cập API bên thứ 3
6 Hệ thống Trả về kết quả do bên thứ 3 trả về cho hệ thống
7 Người sở hữu Chuẩn hóa các trường dữ liệu trả về nếu cần
8 Người sở hữu Tạo ID cho API trung gian
9 Hệ thống Kiểm tra Xem ID đã tồn tại chưa
10 Người sở hữu Chọn loại API tích hợp
11 Hệ thống Hiển thị các thông tin cần thêm tương ứng với loại API đã chọn
12 Người sở hữu Thêm các thông tin dựa trên loại API đã chọn
13 Người sở hữu Thêm người phát triển và điều kiện bảo mật cho API tích hợp nếu cần
14 Người sở hữu Xác nhận tạo API tích hợp
15 Hệ thống Xử lý và lưu API vào cơ sở dữ liệu
Luồng sự kiện thay thế STT Thực hiện bởi Hành động
5a Hệ thống Thông báo nếu việc truy cập API bên thứ 3 bị lỗi 9a Hệ thống Thông báo nếu ID đã tồn tại 15a Hệ thống Thông báo lỗi khi lưu API
3.2.7 Đặc tả use case Truy cập API
Bảng 9 Đặc tả use Truy cập API
Mã use case UC008 Tên use case Truy cập API
Tác nhân Người phát triển
Người phát triển cần có đầy đủ thông tin để có thể truy cập API
STT Thực hiện bởi Hành động
1 Người phát triển Thêm các thông tin cơ bản để tuy cập API bao gồm URL và phương thức
Cung cấp chính xác điều kiện bảo mật của API
Xác nhận truy cập API
4 Hệ thống Tìm kiếm API được truy cập
5 Hệ thống Xác định loại API được truy cập
6 Hệ thống Lấy thông tin API từ cơ sở dữ liệu
7 Hệ thống Kiểm tra điều kiện bảo mật được cung cấp
8 Hệ thống Truy vấn dữ liệu với loại API tương ứng
9 Hệ thống Trả về kết quả truy vấn cho người phát triển
Luồng sự kiện thay thế STT Thực hiện bởi Hành động
4a Hệ thống Trả về kết quả API không tồn tại nếu không tìm thấy
Yêu cầu phi chức năng
Hệ thống quản lý tri thức và xây dựng API cho bot là hệ thống thiên nhiều về hướng kỹ thuật, mới mẻ với người dùng không có chuyên môn Vì vậy, hệ thống cần cung cấp giao diện đơn giản, quen thuộc, phù hợp với đa dạng người dùng Ngoài ra do cần đảm bảo chính xác về dữ liệu, tính bảo mật dữ liệu khi truy cấp API nên cũng cần có hướng dẫn, mô tả, cảnh báo nếu người dùng thao tác sai
Trong tương lai hệ thống có thể phát triển thêm một số tính năng xây dựng API và các bộ tri thức Điều đó có thể làm thay đổi nghiệp vụ, giao diện Do đó cần phải xây dựng để khi mở rộng không làm ảnh hưởng tới chức năng đã có.
Thiết kế kiến trúc
Hệ thống quản lý tri thức và xây dựng API cho bot được tách biệt làm hai phần: Frontend và Backend với kiến trúc tổng quan mô tả như Hình 12
Frontend sử dụng ReactJS để xây dựng các thành phần giao diện và sử dụng REST API để gửi yêu cầu và nhận phản hồi từ Backend Kiến trúc frontend sẽ được trình bày chi tiết trong 3.4.2
Backend sử dụng NodeJS xây dựng theo kiến trúc microservices gồm 2 service là API và Knowledge Kiến trúc chi tiết trình bày trong 3.4.3 Dữ liệu được lưu trữ và truy vấn từ MongoDB thông qua ODM Bên cạnh đó Redis sẽ hỗ trợ lưu dữ liệu tạm thời khi các bộ API do hệ thống xây dựng được sử dụng để những lần truy vấn sau nhanh hơn
Hình 12 Kiến trúc tổng quan
Khi frontend muốn giao tiếp với backend sẽ gửi một yêu cầu về backend quan API Route bên backend sẽ nhận yêu cầu gửi đến controller tương ứng Controller sẽ gọi service để xử lý truy vấn cơ sở dữ liệu qua model Sau khi backend xử lý xong sẽ phản hồi kết quả về cho frontend
Ngoài ra, để sử dụng hệ thống thì người dùng cần đăng nhập thông qua dịch vụ IAM
Hình 13 mô tả kiến trúc frontend của hệ thống với 2 phần chính là Components và Containers
Components là các thành phần dùng chung được sử dụng nhiều lần ở các container khác nhau khi cần thiết Có 8 thành phần là: ButtonCopy, KnowledgeOptions, DateRangePicker, FileOrFormOptions, Header, Rule, TableSort, Participants
Containers chứa các thành phần kết xuất giao diện theo từng chức năng để hiển thị cho người dùng Hệ thống có 5 containers gồm: (i) Login - giao diện cho người dùng đăng nhập, (ii) Answer - giao diện cho người nhập liệu nhập câu trả lời, (iii) Layout - Bố cục chung cho tất cả màn hình, (iv) KnowleadgeManage - nhóm giao diện liên quan đến quản lý tri thức, (v) ApiManage - nhóm giao diện liên quan đến quản lý API Nhóm giao diện (iv) bao gồm: CreateKnowledge - giao diện tạo hoặc hiển thị thông tin tri thức, KnowledgeHistory - giao diện hiển thị lịch sử chỉnh sửa tri thức, KnowledgeList – giao diện hiển thị danh sách tri thức Nhóm giao diện (v) bao gồm: CreateApi – giao diện tạo API, ApiInfo – giao diện hiển thị thông tin API, ApiList – giao diện hiển thị danh sách API
Routes bao gồm PrivateRoute và PublicRoutes Routes chịu trách nhiệm gọi đến các page tương ứng với đường dẫn người dùng truy cập Với đường dẫn thuộc PrivateRoute thì người dùng cần đăng nhập trước khi truy cập
Do hệ thống sử dụng framework ExpressJS để xây dựng backend nên kiến trúc backend bao gồm 4 thành phần là Routes, Controllers, Services, Models như Hình 14 Routes có nhiệm vụ nhận yêu cầu từ API để gửi các yêu cầu đến Controller phù hợp, Controllers nhận yêu cầu xử lý các dữ liệu cần thiết và gọi Services tương ứng, Services xử lý luồng nghiệp vụ và truy vấn dữ liệu thông qua Models Bên cạnh đó có 1 thành phần là 3 rd party API, đây là thành phần để các API tích hợp truy vấn dữ liệu thông qua API bên thứ 3.
Thiết kế chi tiết frontend
Giao diện được thiết kế trên màn hình có độ phân giải 1920x1080 và được điều chỉnh phù hợp với nhiều loại màn hình Để thống nhất tính nhất quán cho toàn bộ trang web và tạo giao diện thân thiện cho người dùng thì cần thống nhất về màu sắc, font chữ, nút, cách hiển thị thông báo Các thông tin của bộ cấu hình được trình bày trong Bảng 10
Bảng 10 Cấu hình chung giao diện Thuộc tính Cấu hình
Màu sắc Màu chính: #FFFFFF, #4991e2, #000034
Bo góc 10px Đổ bóng 0px 2px 1px -1px rgba(0,0,0,0.2), 0px 1px 1px 0px rgba(0,0,0,0.14), 0px 1px 3px 0px rgba(0,0,0,0.12)
Vị trí hiển thị popup Chính giữa màn hình
Vị trí hiển thị thông báo
3.5.1 Biểu đồ dịch chuyển màn hình
Hình 15 Biểu đồ dịch chuyển màn hình
Hệ thống bao gồm các màn hình chính là: Màn hình danh sách tri thức (màn hình trang chủ, từ đây có thể chuyển hướng đến màn hình khác), Màn hình nhập dữ liệu, Màn hình danh sách API, Màn hình tạo tri thức, Màn hình Tạo API, Màn hình thông tin API và các giao diện phụ theo từng tính năng Mối liên hệ và sự chuyển đổi giữa các màn hình được mô tả trong Hình 15
Hình 16 là bố cục giao diện chùng chung cho tất cả các trang khác của hệ thống bao gồm Header, Sidebar, Content Trong đó Header và Sidebar giống nhau trên các trang trừ trang nhập liệu không có Sidebar Content sẽ thay đổi tùy thuộc vào đường dẫn truy cập Header là thanh tiêu đề trang web Tại đây, người dùng có thể thay đổi ngôn ngữ, đăng xuất hoặc chọn logo để về trang chủ của hệ thống Sidebar chứa các thành phần dẫn đến trang mới của hệ thống
Hình 16 Thiết kế layout hệ thống 3.5.3 Thiết kế màn hình hiển thị danh sách
Màn hình hiển thị danh sách chia làm 3 thành phần như Hình 17 Tương ứng với từng loại danh sách (danh sách tri thức, danh sách API tri thức, danh sách API tích hợp) mà các thành phần sẽ hiển thị thông tin và thực hiện chức năng khác nhau
Chọn nút tạo sẽ đến trang tạo mới
Khu vực chức năng lọc, tìm kiếm sẽ cho phép lọc danh sách theo từ khóa, theo ngày tạo hoặc
Khu vực hiển thị thông tin từng phần tử của danh sách sẽ hiển thị thông tin cơ bản từng phần tử lấy ra từ danh sách dựa trên loại danh sách Khi chọn vào phần tử sẽ đến xem thông tin chi tiết của phần tử đó
Hình 17 Thiết kế màn hình danh sách 3.5.4 Thiết kế màn hình hiển thị tạo mới (tri thức/API)
Hình 18 Thiết kế màn hình tạo mới
Màn hình tạo mới chia làm 4 phần như Hình 18 Nếu có tri thức được xem thông tin chi tiết thì màn hình này sẽ trở thành màn hình thông tin tri thức Khi đó khu vực các nút chức năng sẽ được hiển thị chứa các nút thao tác với tri thức, khu vực nội dung cần tạo trong từng bước sẽ hiển thị thông tin tương ứng của tri thức trong từng bước
Khu vực danh sách các bước sẽ hiển thị các bước để tạo mới Có thể chọn các bước để chuyển bước hoặc chọn 2 nút bước trước, bước sau để chuyển Ở bước đầu tiên, nút bước trước sẽ không thể chọn, bước cuối cùng nút bước sau sẽ chuyển thành nút lưu
3.5.5 Thiết kế màn hình hiển thị lịch sử chỉnh sửa tri thức
Hình 19 Thiết kế màn hình lịch sử chỉnh sửa tri thức
Màn hình lịch sử chỉnh sửa tri thức chia làm 3 vùng như Hình 19
Khu vực chức năng lọc tìm kiếm cho phép tìm kiếm theo người chỉnh sửa, hành động chỉnh sửa (thêm mới, sửa, xóa dữ liệu), thời gian sửa
Khu vực danh sách lịch sử hiển thị danh sách các bộ dữ liệu được chỉnh sửa
Khu vực chi tiết thay đổi sẽ hiển thị dữ liệu của bộ dữ liệu được chỉnh sửa chọn từ danh sách Với bộ dữ liệu được thêm mới sẽ hiển thị dữ liệu mới Với bộ dữ liệu bị xóa sẽ hiển
3.5.6 Thiết kế màn hình hiển thị thông tin API
Hình 20 Thiết kế màn hình thông tin API
Hình 20 là thiết kế màn hình hiển thị thông thông tin API bao gồm 6 phần:
Các nút chức năng chứa các nút: Lưu dùng để lưu API sau khi chỉnh sửa Xóa dùng để xóa API tùy biến hoặc API tích hợp
Khu vực thông tin cơ bản hiển thị các thông tin cơ bản của API bảo gồm: URL, phương thức, trạng thái, loại, định dạng trả về
Khu vực người tham gia hiển thị danh sách những người phát triển được người sở hữu qui định để sử dụng API
Khu vực điều kiện bảo mật hiển thị những luật cần đáp ứng để có thể sử dụng API và danh địa chỉ IP được phép truy cập
Khu vực thống kê tần suất sử dụng API hiển thị bảng và biểu đồ cho thấy mức độ truy cập API, địa chỉ IP, kết quả, thời gian mỗi lần truy cập
3.5.7 Thiết kế màn hình hiển thị nhập liệu cho người nhập liệu
Hình 21 Thiết kế màn hình nhập liệu Đối với người được giao cho nhập liệu tri thức khi truy cập vào đường dẫn được chia sẻ để nhập liệu sẽ đến màn hình nhập liệu được thiết kế như Hình 21
Màn hình hiển thị bộ câu hỏi theo dạng google form để người nhập liệu trả lời
Popup hiển thị các tính năng yêu cầu người dùng thực hiện Nó gồm phần tiêu đề là tên popup, khu vực nội dung hiển thị các tính năng cần thực hiện, khu vực nút chức năng chứa các nút chức năng tương ứng với từng tính năng.
Thiết kế chi tiết backend
Do đồ án có hạn nên phần này em sẽ trình bày luông hoạt động cho hai chức năng là Truy cập API và Tạo tri thức
Hình 23 Biểu đồ trình tự truy cập API
Hình 23 mô tả luồng Truy cập API bắt đầu từ lúc người phát triển nhập URL, phương thức, điều kiện bảo mật và xác nhận truy cập Hệ thống sẽ dựa trên uniqueId chứa trong URL để tìm API đó Sẽ ưu tiên tìm trong apiModel của redis nếu chưa có sẽ tìm trong apiModel của cơ sở dữ liệu Nếu không tìm thấy API, hệ thống sẽ trả về lỗi “Api not exist” Nếu tìm thấy hệ thống sẽ dựa trên loại API để đưa ra những hành động tiếp theo
Nếu là API tích hợp hệ thống sẽ thực hiện Biểu đồ trình tự truy cập API tích hợp Hình 24
Hình 24 Biểu đồ trình tự truy cập API tích hợp
Nếu là API tri thức hệ thống sẽ tìm tri thức thông qua uniqueId Nếu không tìm thấy sẽ trả về lỗi “Knowledge not exist” Nếu tìm thấy dựa trên phương thức để thực hiện bước tiếp theo: (i) phương thức GET thực hiện Biểu đồ trình tự lấy dữ liệu tri thức Hình 25, (ii) phương thức POST thực hiện biểu đồ trình tự thêm dữ liệu tri thức Hình 26, (iii) phương thức PUT thực hiện biểu đồ trình tự sửa dữ liệu tri thức Hình 27, (iv) phương thức DELETE thực hiện biểu đồ trình tự xóa dữ liệu tri thức Hình 28
Hình 25 Biểu đồ trình tự lấy dữ liệu từ tri thức
Hình 26 Biểu đồ trình tự thêm dữ liệu vào tri thức
Hình 27 Biểu đồ trình tự sửa dữ liệu tri thức
Khi service nhận được yêu cầu từ controller sẽ tiến hành kiểm tra bảo mật theo điều kiện của từng API qua phương thức checkAuthentications Sau khi xử lý nghiệp vụ với từng API sẽ lưu lại kết quả truy vấn vào model statistic
Khi truy cập API tích hợp hệ thống sẽ gọi đến API bên thứ 3 dựa trên thông tin API được lưu Dữ liệu trả về từ API bên thứ 3 sẽ được lọc qua điều kiện lấy dữ liệu sau đó sẽ được chuyển đổi dữ liệu cho đúng với các trường được thiết lập khi tạo API tích hợp
Khi truy cập API lấy dữ liệu từ tri thức hệ thống sẽ lấy dữ liệu từ tri thức được tìm thấy, lọc qua điều kiện truy vấn dữ liệu và chỉ lấy ra các trường dữ liệu được chọn
Khi truy cập API thêm dữ liệu cho tri thức hệ thống sẽ kiểm tra dữ liệu mới xem có đúng với cấu trúc dữ liệu của tri thức không Nếu đúng sẽ thêm bộ dữ liệu mới vào danh sách dữ liệu của tri thức, cập nhật lại tri thức và tạo lịch sử chỉnh sửa dữ liệu với action ‘new’
Khi truy cập API chỉnh sửa dữ liệu tri thức hệ thống sẽ kiểm tra dữ liệu cần sửa có trong bộ dữ liệu của tri thức không Sau đó kiểm tra dữ liệu mới xem có đúng với cấu trúc dữ liệu của tri thức không Nếu đúng sẽ sửa bộ dữ liệu cần sửa bằng bộ dữ liệu mới, cập nhật lại tri thức và tạo lịch sử chỉnh sửa dữ liệu với action ‘edit’
Khi truy cập API chỉnh sửa dữ liệu tri thức hệ thống sẽ kiểm tra dữ liệu cần xóa có trong bộ dữ liệu của tri thức không Nếu đúng sẽ xóa bộ dữ liệu khỏi danh sách dữ liệu của tri thức, cập nhật lại tri thức và tạo lịch sử chỉnh sửa dữ liệu với action ‘delete’
3.6.1.1 Luồng hoạt động Tạo tri thức
Luồng tạo tri thức sẽ bắt đầu sau khi người dùng cung cấp đầy đủ thông tin và chọn lưu tri thức Hệ thống sẽ tiến hành kiểm tra xem tri thức đã tồn tại chưa thông qua ID Nếu đã tồn tại sẽ hiển thị thông báo cho người dùng Nếu chưa sẽ tiến hành gọi API tạo tri thức Route sau khi nhận thông điệp sẽ gọi phương thức createKnowledge ở controller, controller gọi phương thức createKnowledge ở service kèm theo dữ liệu tri thức được tạo gửi cùng yêu cầu tạo tại body thông qua createFields Service sẽ xử lý createFields để tạo tri thức và các bộ API mặc định của tri thức sau đó Cuối cùng gửi dữ liệu được xử lý về model để lưu tri thức và API vào cơ sở dữ liệu rồi trả kết quả cho người dùng Biểu đồ trình tự của quá trình trên được mô tả trong Hình 29
Hình 29 Biểu đồ trình tự tạo tri thức
Như đã trình bày trong phần 3.4.1, để Frontend và Backend có thể gửi nhận dữ liệu với nhau thì cần sử dụng API Ngoài ra khi bot sử dụng các bộ API do hệ thống cung cấp cũng cần qua API để có thể truy vấn Hệ thống gồm 22 API được mô tả trong Bảng 11
STT Nhóm Mục đích Phương thức Địa chỉ
1 Knowledge Tạo tri thức POST /api/v1/knowledges
2 Lấy danh sách tri thức GET /api/v1/knowledges
3 Lấy thông tin tri thức theo ID
4 Cập nhật thông tin tri thức theo ID
5 Xóa tri thức theo ID DELETE /api/v1/knowledges/
6 API Tạo API POST /api/v1/apis
7 Lấy danh sách API GET /api/v1/apis
8 Lấy thông tin API theo ID
10 Xóa API theo ID DELETE /api/v1/apis/:apiId
STT Nhóm Mục đích Phương thức Địa chỉ
11 Authentication Lưu tài khoản mới POST /api/v1/auths/register
12 Đăng nhập vào hệ thống
13 Kiểm tra access token GET /api/v1/auths/verify
14 User Lấy danh sách user GET /api/v1/users
15 Data Lấy dữ liệu khi truy vấn từ API dựa theo
16 Lấy dữ liệu khi truy vấn từ API dựa theo
ID nhưng sẽ chỉ lấy các trường được chỉ định theo fieldList trong mỗi bộ dữ liệu
17 Thêm bộ dữ liệu vào tri thức hoặc dữ liệu của hệ thống bên thứ
18 Chỉnh sửa bộ dữ liệu của tri thức hoặc dữ liệu của hệ thống bên thứ 3 theo ID
STT Nhóm Mục đích Phương thức Địa chỉ
19 Xóa bộ dữ liệu của tri thức hoặc dữ liệu của hệ thống bên thứ 3 theo ID
20 Statistic Lấy ra dữ liệu thống kê API
21 History Lấy danh sách lịch sử chỉnh sửa dữ liệu
22 Xóa lịch sử dữ liệu DELETE /api/v1/histories/
Thiết kế cơ sở dữ liệu
Hình 30 Biểu đồ thực thể liên kết
Hình 30 là biểu đồ thực thể liên kết của hệ thống thể hiện mối quan hệ giữa Người dùng, Tri thức, API, Lịch sử tri thức và thống kê API Một người dùng có thể tạo nhiều API hoặc tri thức, có thể tham gia xây dựng, phát triển nhiều tri thức hoặc API Một tri thức hoặc API chỉ được tạo bởi một người nhưng có thể cho nhiều người tham gia xây dựng, phát triển Một tri thức có nhiều bộ API, có thể có nhiều lịch sử chỉnh sửa dữ liệu Một bộ API có thể có nhiều thống kê phụ thuộc vào số lần API được truy vấn Biểu đồ còn cho biết các thông tin chi tiết cần cung cấp cho mỗi đối tượng
Hình 31 Thiết kế tổng quan cơ sở dữ liệu
Từ biểu đồ thực thể liên kết em đã thiết kế cơ sở dữ liệu như Hình 31 theo hướng NoSQL với 5 Collections: Knowledge, User, API, History, Statistic Trong đó API và History sẽ lưu
ID của tri thức liên quan tại trường knowledge để biết nó thuộc về tri thức nào Statistic sẽ lưu ID của API tại trường API để biết nó thuộc về API nào User tạo hoặc tham gia vào Knowledge hoặc API sẽ lưu vào participants gồm email và quyền tương ứng với Knowledge hoặc API đó
Chi tiết các trường dữ liệu của mỗi collection được mô tả trong Bảng 12
Bảng 12 Thiết kế chi tiết cơ sở dữ liệu
Collection Tên trường Kiểu dữ liệu Ý nghĩa Bắt buộc
User _id ObjectId ID người dùng trong hệ thống
Có email String Email đăng nhập của người dùng
Knowledge _id ObjectId ID tri thức trong hệ thống Có uniqueId String ID do người tạo đặt để phục vụ quản lý và xây dựng API
Có name String Tên tri thức Có participants Array Danh sách người tham gia xây dựng tri thức
Có dataStructure Array Cấu trúc dữ liệu tri thức Có schemas Array Danh sách các bộ dữ liệu của tri thức
Collection Tên trường Kiểu dữ liệu Ý nghĩa Bắt buộc
API _id ObjectId ID API trong hệ thống Có uniqueId String ID của API tích hợp do người dùng đặt phục vụ quản lý và truy vấn
Bắt buộc với API tích hợp knowledge ObjectId ID tri thức làm cơ sở tạo
Bắt buộc với API tùy biến method String Phương thức truy vấn của
Có type String Loại API Có url String Đường dẫn để truy vấn
Có link String Đường dẫn của API bên thứ 3
Bắt buộc với API tích hợp participants Array Danh sách người tham gia phát triển API
Có status String Trạng thái API là running hay stop
Có rules Array Danh sách điều kiện bảo mật của API
Không ips Array Danh sách địa chỉ ip được phép truy vấn API
Collection Tên trường Kiểu dữ liệu Ý nghĩa Bắt buộc headers Object Điều kiện để truy cập API bên thứ 3
Bắt buộc nếu API bên thứ 3 có điều kiện truy cập queryInfomations Array Danh sách các trường để lấy ra từ các bộ dữ liệu của API tích hợp sau khi chuẩn hóa trường dữ liệu của API bên thứ 3 trả về
Không queryConditions Array Danh sách các trường để lọc dữ liệu từ các bộ dữ liệu của API tích hợp sau khi chuẩn hóa trường dữ liệu của API bên thứ 3 trả về
Không default Boolean Xác định API có phải được tạo mặc định sau khi tri thức được tạo không
Có description Array Danh sách các mô tả cho
History _id ObjectId ID của lịch sử trong hệ thống
Có knowledge ObjectId ID của tri thức được chỉnh sửa
Collection Tên trường Kiểu dữ liệu Ý nghĩa Bắt buộc user String Email người chỉnh sửa hoặc ip của thiết bị chỉnh sửa nếu dữ liệu được chỉnh sửa qua API được cung cấp
Có keyData String Định danh bộ dữ liệu được chỉnh sửa
Có oldData Object Dữ liệu trước khi chỉnh sửa
Bắt buộc nếu hành động chỉnh sửa là edit hoặc delete newData Object Dữ liệu sau khi chỉnh sửa Bắt buộc nếu hành động chỉnh sửa là edit hoặc new action String Hành động chỉnh sửa là gì: new, edit, delete
Có updatedAt Date Thời gian chỉnh sửa Có
Statistic _id ObjectId ID của thống kê trong hệ thống
Có api ObjectId ID của API được thống kê Có ip String Địa chỉ IP truy vấn API Có
Collection Tên trường Kiểu dữ liệu Ý nghĩa Bắt buộc code String Mã kết quả truy vấn Có message String Thông điệp kết quả truy vấn
Có createdAt Date Thời gian truy vấn Có
Tổng kết Chương 3, em đã đưa ra nội dung về phân tích thiết kế cho hệ thống quản lý tri thức và xây dựng API cho bot Đây là cơ sở để xây dựng và triển khai ứng dụng được trình bày trong Chương 4 Để biến những phân tích thiết kế ở Chương 3 thành hệ thống thì cần sử dụng các cộng nghệ, ứng dụng công nghệ vào quá trình xây dựng và phát triển Công nghệ em sử dụng và quá trình xây dựng, phát triển hệ thống sẽ được em trình bày trong chương này
4.1 Công nghệ sử dụng Để triển khai, xây dựng các chức năng ở Chương 2 thì em cần sử dụng các công nghệ như sau: Hệ thống được chia làm 2 phần là frontend và backend Phần frontend sử dụng ReactJS và thư viện Material UI để xây dựng giao diện, Styled-Components hỗ trợ tổ chức CSS Phần backend sử dụng NodeJS để xử lý nghiệp vụ, MongoDB Atlas làm cơ sở dữ liệu và Redis hỗ trợ truy vấn API REST API để làm cầu nối giao tiếp cho frontend và backend Docker để triển khai hệ thống
ReactJS [1] là thư viện JavaScript do Facebook (nay là Meta) phát triển giúp tạo giao diện người dùng, thiết kế khung nhìn đơn giản cho từng trạng thái và có sự hiển thị phù hợp khi dữ liệu thay đổi Nó cho tốc độ phản hồi nhanh và hiệu quả cao Cho phép sử dụng lại các components để tái sử dụng phát triển các ứng dụng khác nhau có cùng chức năng
ReactJS lấy cơ sở xây dựng là Component Mỗi component là những thành phần được đóng gói quản lý trạng thái riêng, sau đó biên soạn chúng để tạo nên những giao diện phức tạp Điều này giúp dễ dàng trong việc phát triển và gỡ lỗi vì chúng ta chỉ cần tập trung vào từng phần nhỏ chứ không phải cả hệ thống Component có 2 thành phần quan trọng là props và state Props là đối tượng giúp component nhận giá trị truyền vào từ bên ngoài, giúp các component giao tiếp với nhau State lưu trữ dữ liệu động trong component, state thay đổi thì component sẽ render lại Ngoài ra do component là những thành phần nhỏ có chức năng khác nhau nhưng có thể sử dụng ở nhiều nơi nên giúp ích rất nhiều trong việc tái sử dụng code.
Xây dựng và triển khai hệ thống
Công nghệ sử dụng
Để triển khai, xây dựng các chức năng ở Chương 2 thì em cần sử dụng các công nghệ như sau: Hệ thống được chia làm 2 phần là frontend và backend Phần frontend sử dụng ReactJS và thư viện Material UI để xây dựng giao diện, Styled-Components hỗ trợ tổ chức CSS Phần backend sử dụng NodeJS để xử lý nghiệp vụ, MongoDB Atlas làm cơ sở dữ liệu và Redis hỗ trợ truy vấn API REST API để làm cầu nối giao tiếp cho frontend và backend Docker để triển khai hệ thống
ReactJS [1] là thư viện JavaScript do Facebook (nay là Meta) phát triển giúp tạo giao diện người dùng, thiết kế khung nhìn đơn giản cho từng trạng thái và có sự hiển thị phù hợp khi dữ liệu thay đổi Nó cho tốc độ phản hồi nhanh và hiệu quả cao Cho phép sử dụng lại các components để tái sử dụng phát triển các ứng dụng khác nhau có cùng chức năng
ReactJS lấy cơ sở xây dựng là Component Mỗi component là những thành phần được đóng gói quản lý trạng thái riêng, sau đó biên soạn chúng để tạo nên những giao diện phức tạp Điều này giúp dễ dàng trong việc phát triển và gỡ lỗi vì chúng ta chỉ cần tập trung vào từng phần nhỏ chứ không phải cả hệ thống Component có 2 thành phần quan trọng là props và state Props là đối tượng giúp component nhận giá trị truyền vào từ bên ngoài, giúp các component giao tiếp với nhau State lưu trữ dữ liệu động trong component, state thay đổi thì component sẽ render lại Ngoài ra do component là những thành phần nhỏ có chức năng khác nhau nhưng có thể sử dụng ở nhiều nơi nên giúp ích rất nhiều trong việc tái sử dụng code
Chương 4 Xây dựng và triển khai hệ thống
ReactJS component dễ viết hơn vì sử dụng JSX, là phần mở rộng cú pháp JavaScript cho phép kết hợp HTML với JavaScript để xác định thành phần giao diện và chức năng của chúng Nó làm rõ toàn bộ quá trình viết cấu trúc trang web vì những gì viết ra đều được hiển thị trên màn hình và lỗi sẽ được phát hiện ngay trong quá trình biên dịch Do đó JSX có thể không phổ biến nhất, nhưng là hiệu quả trong việc phát triển components
ReactJS sử dụng luồng dữ liệu một chiều để thiết kế luồng dữ liệu Luồng dữ liệu một chiều giúp đảm bảo sự xuyên suốt từ cha đến con, hạn chế thay đổi trong DOM, quản lý sự kiện trong các component và có thể tái sử dụng Để xây dựng ứng dụng nhanh, có thể mở rộng, đạt hiệu suất cao và đem lại trải nghiệm tốt cho người dùng thì ReactJS cung cấp một tính năng là Virtual DOM RectJS duy trì 2 DOM song song là DOM thực và DOM ảo (Virtual DOM) Khi giao diện có sự thay đổi, toàn bộ thành phần thay đổi lưu trong DOM ảo Sau đó sử dụng một thuật toán đối chiếu để kiểm tra sự khác biệt của DOM mới với lịch sử DOM Kết quả của thuật toán là DOM thật sẽ cập nhật những thứ thay đổi trong giao diện Điều này giúp tiết kiệm thời gian và bộ nhớ hơn
Tuy nhiên để có một giao diện hoàn chỉnh cần sử dụng thêm các hệ thống, thư viện, framework khác để hỗ trợ ReactJS
Material UI [3] do Google xây dựng để tạo ra các component thông dụng như Layout, Button, TextField, Dựa trên cơ sở xây dựng giao diện bằng component của ReactJS nó cung cấp thư viện có thể tùy chỉnh và truy cập các thành phần từ cơ bản đến nâng cao, cho phép xây dựng giao diện riêng và phát triển ứng dụng sử dụng ReactJS nhanh hơn
Styled-Components [4] là một thư viện được phát triển với mục đích tổ chức và quản lý CSS Nó cho phép viết CSS bằng Javascript, các thuộc tính css có thể viết trực tiếp vào một file js giúp dễ dàng kiểm tra code mà không cần chuyển qua lại giữa các file nhiều lần Việc sử dụng Styled-Components sẽ định nghĩa components với style chỉ dành riêng cho nó Điều này sẽ giúp hệ thống tải ít mã nhất khi load trang vì style sẽ tự động chèn vào khi component render
NodeJS [2] là một mã nguồn mở, môi trường cho các máy chủ và ứng dụng mạng NodeJS sử dụng Google V8 JavaScript engine để thực thi mã giúp xây dựng các ứng dụng web đơn giản và dễ mở rộng Nodejs cung cấp một thư viện built-in cho phép các hệ thống hoạt động như một webserver Nó cung cấp kiến trúc hướng sự kiện (event-driven) và cơ chế non- blocking I/O API giúp tối ưu hóa thông lượng, đảm bảo tính hiệu quả cao Mọi hàm trong NodeJS là bất đồng bộ nên các tác vụ đều xử lý ở chế độ nền
ExpressJS [7] là một framework của NodeJS cung cấp một bộ tính năng để xây dựng các ứng dụng web, di động và các API Với vô số phương thức tiện ích HTTP và middleware, việc tạo một API rất nhanh chóng và dễ dàng Nó cho phép thiết lập các lớp trung gian để trả về HTTP request Định nghĩa router cho phép sử dụng với các hành động khác nhau dựa trên phương thức HTTP và URL Cho phép trả về các trang HTML dựa vào các tham số
MongoDB [5] là một cơ sở dữ liệu mã nguồn mở và là cơ sở dữ liệu phi quan hệ NoSQL được viết bằng C++ Các dữ liệu trong MongoDB được lưu trữ theo định dạng JSON Ngoài ra, MongoDB là một cơ sở dữ liệu đa nền tảng, hoạt động trên các khái niệm Collection và Document, nó cung cấp hiệu suất cao, tính khả dụng cao và khả năng mở rộng dễ dàng
Dữ liệu trong Mongo lưu trữ theo dạng key-value nên sẽ cho phép các document linh hoạt trong việc xây dựng cấu trúc dữ liệu
MongoDB không cần mất thời gian kiểm tra vấn đề thỏa mãn ràng buộc dữ liệu do nó không có quan tâm đến vấn đề ràng buộc như SQL Tuy nhiên do dữ liệu được lưu dưới dạng key- value, nên sẽ dẫn đến việc dư thừa dữ liệu khi key-value bị lặp lại
MongoDB Atlas [6] là dịch vụ MongoDB được lưu trữ đám mây trên AWS, Azure và Google Cloud giúp triển khai và mở rộng cơ sở dữ liệu MongoDB Dữ liệu mỗi Cluster ở Atlas được lưu trữ theo cơ chế nhân rộng với 3 node trong đó có 1 master (primary) và 2 slaves (secondary) được đồng bộ dữ liệu với nhau Mỗi node có thể sử dụng để thực hiện một nghiệp vụ truy vấn dữ liệu khác nhau giúp tránh quá tải khi truy vấn cơ sở dữ liệu
API là một tập các quy tắc và cơ chế để các ứng dụng hay thành phần giao tiếp với nhau Định dạng dữ liệu trả về của API cũng rất đa dạng nhưng phổ biến là JSON và XML
REST là một kiểu kiến trúc phần mềm được tạo ra để thiết kế và phát triển kiến trúc cho các API Trong REST, dữ liệu và chức năng được coi là tài nguyên và truy cập bằng URL Khi xử lý dữ liệu REST sử dụng phương thức HTTP gửi một yêu cầu đến URL, URL sẽ gửi yêu cầu về máy chủ xử lý và trả về kết quả
REST hoạt động chủ yếu dựa vào giao thức HTTP thông qua những phương thức riêng, một số phương thức được sử dụng nhiều:
• PUT: Cập nhật dữ liệu
Redis [8] là một cơ sở dữ liệu giá trị quan trọng thường được xếp vào nhóm cơ sở dữ liệu NoSQL Được phát hành bởi nhà phát triển Salvatore Sanfilippo vào ngày 10 tháng 4 năm
Xây dựng ứng dụng
4.2.1 Thư viện và công cụ sử dụng
Bảng 13 Danh sách thư viện và công cụ sử dụng để xây dựng hệ thống
Mục đích Hệ thống Địa chỉ URL
IDE lập trình Visual Studio
Code https://code.visualstudio.com/
MongoDB Compass https://www.mongodb.com/products/compass
Ngôn ngữ lập trình Javascript https://developer.mozilla.org/en-
Nền tảng backend NodeJS https://nodejs.org/en/
Mục đích Hệ thống Địa chỉ URL
Nền tảng frontend ReacJS https://reactjs.org/
Material-ui https://mui.com/
Thư viện viết CSS Styled- components https://styled-components.com/
Axios https://www.npmjs.com/package/axios
Hệ thống hỗ trợ kiểm tra API
Postman https://www.postman.com/downloads/
Triển khai hệ thống Docker https://www.docker.com/
Hiện tại hệ thống đã hoàn thành, đóng gói và triển khai với tên miền https://knowledge.iristech.club/ Các thông số chính của hệ thống được trình bày ở Bảng 14
Bảng 14 Thông số hệ thống
Số file mã nguồn backend 58
Số file mã nguồn frontend 124
4.2.3 Minh hoạ các chức năng chính
Trong phần này em sẽ minh họa 3 chức năng là (i) Tạo tri thức, (ii) Xem thông tin API, (iii) Tạo API tích hợp
Chức năng tạo tri thức được chia làm 3 bước: (i) Tạo thông tin cơ bàn, (ii) Tạo cấu trúc dữ liệu, (iii) Tạo dữ liệu
Hình 32 Tạo tri thức - bước 1
Hình 32 hiển thị các thông tin trong bước 1 của tạo tri thức Người dùng tiến nhập tên cho tri thức, nhập ID hoặc chọn Auto-ID để tự sinh ID dựa theo tên Sau khi thêm thông tin cơ bản người tạo tri thức có thể thêm người tham gia để nhập liệu cho tri thức
Bước 2 tạo cấu trúc dữ liệu cho tri thức Với mỗi tri thức sẽ có cấu trúc dữ liệu khác nhau tạo thành cấu trúc dữ liệu động được trình bày trong phần 2.2.1 Để tạo cấu trúc dữ liệu cho mỗi tri thức cần xác định cách tạo dựa trên dữ liệu cần xây dựng Nếu đã có các trường nhưng chưa có dữ liệu gốc mà cần thu thập thêm thì có thể lựa chọn cách tạo cấu trúc dữ liệu bằng biểu mẫu như Hình 33
Hình 33 Tạo cấu trúc dữ liệu dạng biểu mẫu
Hình 34 Xem trước biểu mẫu
Người dùng nhập từ khóa vào ô câu hỏi, chọn kiểu trả lời với các kiểu dữ liệu khác nhau, có thể thêm mô tả cho câu hỏi, có thể đặt câu hỏi làm trường định danh cho mỗi bộ dữ liệu của tri thức bằng cách nhấn vào khóa, xác định câu hỏi bắt buộc phải trả lời hoặc xóa câu hỏi Để thêm câu hỏi mới ấn nút dấu cộng và có thể xem trước biểu mẫu trả lời như Hình 34 bằng các chọn xem trước trên nút thêm
Hình 35 Nhập dữ liệu dạng JSON
Hình 36 Chọn file dữ liệu
Nếu đã có dữ liệu được lưu trên các file thì có thể nhập dữ liệu theo dạng chuỗi JSON với từ khóa và dữ liệu tương ứng như Hình 35, hoặc tải lên file dữ liệu đó (chấp nhận các file JSON, CSV, Excel) như Hình 36, hay tải lên qua đường dẫn đến file google sheet nếu dữ liệu lưu trên đó như Hình 37
Hình 37 Nhập đường dẫn Google Sheet
Theo cách này dữ liệu sau khi được thêm, hệ thống sẽ xử lý lấy ra các từ khóa và cho phép người dùng chọn tất cả hoặc chọn từng từ khóa thêm vào cấu trúc, chọn kiểu dữ liệu cho từng trường, chọn trường làm định danh để cấu hình cho cấu trúc dữ liệu như Hình 38 Sau khi cấu hình xong có thể chuyển qua dạng biểu mẫu để cung cấp thêm thông tin cho các trường và thêm các trường mới
Hình 38 Định nghĩa cấu trúc dữ liệu từ file
Khi người dùng chuyển sang bước 3 để xây dựng dữ liệu, hệ thống sẽ kiểm tra sau khi cấu trúc dữ liệu được định nghĩa thì có sẵn dữ liệu chưa, nếu có sẽ hỏi người dùng có lấy dữ liệu không Hình 39
Hình 39 Xác nhận lấy dữ liệu hay không
Trong bước xây dựng dữ liệu người dùng có thể xem dữ liệu theo 2 dạng là dạng danh sách Hình 40 và dạng bảng Hình 42 Dạng danh sách sẽ hỗ trợ thêm, sửa, xóa dữ liệu Dạng bảng chỉ có thể xem cơ bản, có thể sắp xếp, phân trang bảng Cả 2 dạng đều hỗ trợ tìm kiếm bằng khóa dữ liệu qua ô tìm kiếm
Hình 40 Xem dữ liệu dạng danh sách Ở dạng danh sách chọn Thêm để thêm dữ liệu mới Chọn một khóa trong danh sách các khóa để xem chi tiết bộ dữ liệu Chọn trường dữ liệu không phải dạng danh sách sẽ hiển thi popup
73 cho phép chỉnh sửa Hình 41 Chọn trường dữ liệu dạng danh sách sẽ hiển thị chi tiết danh sách đó, chọn Sửa để sửa danh sách
Hình 41 Chỉnh sửa dữ liệu
Hình 42 Xem dữ liệu dạng bảng 4.5.3.2 Xem thông tin API
Hình 43 Thông tin cơ bản của API
Trang xem thông tin API cho phép người phát triển biết được cách truy cập, dùng thử và theo dõi tần suất sử dụng API Người sở hữu API có thể chỉnh sửa các thông tin liên quan đến API như thay đổi trạng thái chạy, thay đổi định dạng trả về dữ liệu, cập nhật điều kiện bảo mật và phân người dùng API
Hình 43 hiển thị các thông tin cơ bản của API Chọn nút Copy để sao chép đường đẫn, chọn
Switch để đổi trạng thái API, chọn định dạng trả về để thay đổi định dạng dữ liệu trả về sau khi truy vấn
Hình 44 Thiết lập người phát triển và điều kiện bảo mật
Hình 44 cho phép người sở hữu thêm người phát triển để sử dụng API, thiết lập các luật để bảo mật cho API Chọn email để lấy danh sách email người dùng chưa được thêm để chọn một người Chọn nút Thêm để thêm người đó vào danh sách người phát triển, chọn xóa để xóa khỏi danh sách Tương tự khi thiết lập các luật và địa chỉ ip API key và giá trị mỗi luật không được để trống
Hình 45 mô tả việc thử nghiệm API Người dùng chọn phương thức, thêm đường dẫn và các điều kiện bảo mật ở khu vực request sau đó chọn Gửi Kết quả truy vấn sẽ trả về ở khu vực Response
Hình 46 và Hình 47 lần lượt là thống kê tần suất sử dụng API dạng biểu đồ và bảng
Hình 46 Thống kê API dạng biểu đồ
Hình 47 Thống kê API dạng bảng 4.5.3.1 Tạo API tích hợp
Hình 48 Bước 1 tạo API tích hợp - truy cập API bên thứ ba
Hình 49 Bước 2 tạo API tích hợp - xử lý tham số
Hình 50 Bước 3 tạo API tích hợp - cấu hình API trung gian
Người có thể tạo API tích hợp để chuyển đổi API bên thứ ba bằng ba bước:
Bước 1 người dùng cần truy cập API bên thứ ba để lấy dữ liệu trả về như Hình 48 Người dùng cung cấp các thông tin để có thể truy cập bao gồm phương thức, URL, tham số và thông tin bảo mật nếu có Sau đó người dùng ấn gửi và chờ kết quả trả về
Sau khi có kết quả trả về, người dùng chuyển sang bước 2 như Hình 49 để chuẩn hóa các trường dữ liệu nếu cần
Cuối cùng, bước 3, người dùng cấu hình API trung gian, thêm người phát triển và các điều luật cho API theo các thông tin trong Hình 50.
Kiểm thử và triển khai
Để hệ thống được triển khai và hoạt động tốt nhất em đã tiến hành thực hiện kiểm thử hộp đen với 35 test case Do dung lượng đồ án có hạn nên danh sách test case em sẽ trình bày trong phần phụ lục B
Sau khi hoàn tất kiểm thử hệ thống đã được triển khai với cầu hình như Bảng 15
Tên cấu hình Thông số
CPU Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
Như vậy Chương 4 đã xác định xong công nghệ và quá trình xây dựng và triển khai để đưa những thiết kế thành một hệ thống Trong chương tiếp, em sẽ đưa ra những kết luận và định hướng cho tương lai của hệ thống
Chương cuối cùng em xin trình bày những kết luận cuối cùng của đồ án và đinh hướng phát triển về sau
Sau một quá trình khảo sát, phân tích, thiết kế em đã nêu ra được các mô hình, kiến trúc và công nghệ sử dụng để phát triển hệ thống quản lý tri thức và xây dựng API Đồng thời hệ thống cũng được thiết kế để dễ dàng sửa đổi và phát triển Hiện tại hệ thống đã được đưa vào thử nghiệm với tên miền https://knowledge.iristech.club/
Hệ thống xoay quanh việc phát triển triển tri thức, xây dựng API truy vấn dữ liệu từ tri thức và tích hợp API bên thứ ba để các hệ thống hội thoại sử dụng Vì tri thức rất đa dạng và phụ thuộc vào dữ liệu được sử dụng nên để tạo tri thức thì cần xây dựng cấu trúc dữ liệu cho tri thức Cấu trúc dữ liệu của tri thức là cấu trúc dữ liệu động phụ thuộc vào kiểu của từng dữ liệu trong bộ dữ liệu Sau khi cấu trúc dữ liệu được tạo thì sẽ tiến hành thêm dữ liệu Hệ thống sẽ lưu trữ cấu hình của cấu trúc dữ liệu và lưu dữ liệu theo từng định dạng phù hợp Sau khi tri thức được tạo ra, để hệ thống hội thoại có thể truy vấn dữ liệu từ tri thức thì hệ thống và người dùng sẽ tạo ra các API tương ứng Các API sẽ được cấu hình theo cùng một cấu trúc và được xử lý truy vấn bằng một bộ quản lý API duy nhất để không cần phải lập trình hay xây dựng nghiệp vụ riêng
Bên cạnh đó với các hệ thống hội thoại sử dụng dữ liệu từ bên thứ ba và được các bên thứ ba cấp API để truy vấn thì hệ thống quản lý tri thức và tích hợp API sẽ hỗ trợ cấu hình lại API tích hợp cho phù hợp với dữ liệu sử dụng, chuyển đổi các giao thức về chung một dạng duy nhất Điều này sẽ giúp các hệ thống hội thoại không cần phải lập trình xây dựng luồng nghiệp vụ riêng với từng API tích hợp
Trong quá trình phát triển hệ thống, để vượt qua khó khăn, đạt được thành công và kết quả tốt nhất thì em đã học thêm nhiều kỹ năng mới như kỹ năng làm việc nhóm, nâng cao kỹ năng thiết kế xây dựng phần mềm và quản lý mã nguồn hiệu quả Trong thời gian tới sẽ tiếp tục nâng cao kỹ năng để phát triển tiếp hệ thống.
