thống.
Mỗi người dùng trong hệ thống được phân quyền và đăng ký một username, username này có thể xác định đó là người dùng thông thường, người quản trị tin, hoặc duyệt tin,…tương tự như vậy mỗi vai trò duyệt, quản trị tin có thể do một người hay nhiều người cùng đảm nhận. Mỗi vai trò nằm trong một nhóm vai trò người dùng. Mối quan hệ N-N giữa bảng Roles và Users sẽ được phân tích thành các mối quan hệ 1-N với bảng trung gian là UserRoles.
Dưới đây là các bảng liên quan người dùng, phân quyền người dùng trong hệ thống.
- Thông tin các quyền người dùng (_Roles)
Bảng 1: Bảng lưu thông tin về các quyền. - Thông tin về nhóm người dùng(_RoleGroups).
Bảng 2: Bảng lưu thông tin nhóm quyền.
- Thông tin về chi tiết người dùng(_UserProfiles).
Bảng 3: Bảng lưu thông tin chi tiết người dùng. - Thông tin các quyền (_UserRoles).
Bảng 4: Bảng lưu thông tin các quyền. - Bảng thông tin người sử dụng(_Users).
Bảng 5: Bảng lưu thông tin người sử dụng.
Các thực thể trong quản lý hệ thống người dùng (Xem hình 15)
User: Thông tin về tất cả người dùng trong hệ thống. Thực thể này bao gồm các
thuộc tính UserID, UserName, FirstName, LastName, DisplayName, Email,
Address đây là những thuộc tính chung của từng user khi đăng ký với hệ thống.
UserProfile: Thông tin chi tiết về từng user. Thực thể này gồm các thuộc tính
UserProfileID,UserID, PropertyText. Mỗi user gồm nhiều các UserProfile để mô
tả thông tin chi tiết cho user đó.
Role: Thông tin về các role trong hệ thống, tùy theo từng hệ thống để thiết lập
các role khác nhau. Thực thể này bao gồm các thuộc tính RoleID, PortalID,
RoleName,RoleGroupID, Description. Mỗi RoleID xác định một vai trò cho hệ
thống. Trong một hệ thống một user có thể có một hay nhiều vai trò, cũng như một vai trò có thể do nhiều user cùng đảm nhận. Vì vậy mối quan hệ giữa Role và User là quan hệ nhiều – nhiều (N -N). Chuẩn hóa quan hệ N –N này em xin đưa vào bảng UserRole như sau.
UserRole: Gồm các thuộc tính UserRoleID, UserID, RoleID, ExpiryDate,
EffectiveDate. Như vậy mỗi User có thể gồm nhiều các UserRole (1 - N) và mỗi
Role gồm nhiều UserRole (1 - N).
RoleGroup: Gồm những thông tin về các nhóm vai trò. Thực thể này gồm các
gồm nhiều các Role khác nhau vì vậy mối quan hệ giữa Role và RoleGroup là quan hệ một – nhiều (1 –N).
Sơ đồ EA quan hệ phân quyền trong hệ thống.
5.2. Phân hệ hỗ trợ khách hàng.
Các bảng trong phân hệ hỗ trợ khách hàng.
- Users: Bảng này lưu thông tin người dùng bao gồm tất cả các thành viên có đăng ký với hệ thống.
Bảng 6: Bảng thông tin người dùng trong hệ thống.
- Dnn_Companies: Bảng này lưu thông tin về các doanh nghiệp, mỗi doanh nghiệp đăng ký một CompanyID với hệ thống. Và các thông tin liên quan đến doanh nghiệp như: CompanyName, Address, Email,… Đây là bảng lưu thông tin chung nhất của một doanh nghiệp đã được hệ thống cho phép đăng ký.
Bảng 7: Bảng lưu thông tin về doanh nghiệp.
- DetailCompanies: Bảng này lưu thông tin chi tiết về từng doanh nghiệp, trong bảng này lưu thông tin về tuyển dụng, thông tin giới thiệu về doanh nghiệp.
Từ bảng này có thể giúp cho khách hàng có thể tìm được nhiều thông tin hơn, biết doanh nghiệp này cung cấp phần mềm gì và những ứng dụng gì họ có thể đáp ứng được.
Bảng 8: Bảng lưu thông tin các thành viên.
- Dnn_QuestionDetails: Bảng này lưu thông tin về các câu hỏi như ID của câu hỏi, ngày tạo, mã số của người tạo câu hỏi, mỗi người có thể hỏi nhiều câu trong một ngày với username họ đăng nhập hệ thống. Mỗi câu hỏi thuộc một Category nhất định, người hỏi chọn category cho câu hỏi và đưa nội dung câu hỏi. Mỗi khi người dùng đăng nhập hệ thống nếu người dùng này được hệ thống cấp quyền cho phép đăng câu hỏi thì câu hỏi sẽ được đăng và được lưu vào cơ sở dữ liệu nếu không có quyền đăng câu hỏi thì sẽ có thông báo của hệ thống. Khi câu hỏi vừa được đăng lên trạng thái của câu hỏi sẽ là chưa trả lời.
- Dnn_AnswerDetails: Bảng này lưu thông tin của câu trả lời ngày tạo câu trả lời, cũng như người tạo câu trả lời. Một người cũng có thể có nhiều câu trả lời. Người trả lời cũng phải được hệ thống cấp quyền cho phép người đó đăng câu trả lời, nếu không hệ thống sẽ thông báo lỗi. Với mỗi câu trả lời xong trạng thái của câu hỏi sẽ được chuyển thành đã trả lời hoặc có những câu hỏi người trả lời không phải chỉ trả lời xong ngay tại một thời điểm thì trạng thái của câu cũng được xác định là đang trả lời.
Bảng 10: Bảng lưu thông tin câu trả lời.
- Dnn_Projects: Bảng này lưu thông tin về các dự án của một doanh nghiệp, mỗi doanh nghiệp có rất nhiều dự án, mỗi dự án được đăng lên có kèm theo CompanyID của doanh nghiệp thực hiện dự án đó.
Bảng 11: Bảng lưu thông tin các dự án.
- Dnn_Opinions: Bảng này lưu thông tin về ý kiến của khách hàng, khách hàng có thể nhận xét xem dự án mà họ đã được doanh nghiệp cung cấp có những ưu nhược điểm gì, dựa vào những ý kiến này doanh nghiệp có thể lấy đó làm bài học rút kinh nghiệm.
Bảng 12: Bảng lưu thông tin ý kiến khách hàng về phần mềm họ đang sử dụng. - Dnn_Categories: Bảng này lưu thông tin của từng lĩnh vực ví dụ câu hỏi này thuộc phần mềm kế toán hay phần mềm ứng dụng, ….Mỗi lĩnh vực được đặc trưng bởi một CategoryID.
- Dnn_Status: Bảng này lưu thông tin của từng câu hỏi hay từng bài viết tin tức, để có thể biết được trạng thái câu hỏi này chưa trả lời, đang trả lời hay đã được trả lời.
Bảng 13: Bảng lưu thông tin trạng thái.
- Dnn_Field: Bảng này lưu thông tin về các lĩnh vực mà các doanh nghiệp, công ty phần mềm có thể đáp ứng, mỗi lĩnh vực được đặc trưng bởi một FieldID riêng. Trong thực tế mỗi công ty phần mềm có thể hoạt động ở nhiều lĩnh vực khác nhau, và mỗi lĩnh vực có thể có rất nhiều công ty cùng tham gia hoạt động vì vậy bảng dnn_Fields và bảng dnn_Companies là mối quan hệ N- N. Để thực hiện việc lấy thông tin một cách chính xác em xin thêm vào một bảng dnn_CompanyFields với mục đích tách mối quan hệ N-N giữa hai bảng dnn_Companies và dnn_Fields thành các mối quan hệ 1-N.
Bảng 14: Bảng lưu thông tin về các lĩnh vực công ty có thể đáp ứng. - Dnn_CompanyFields: Bảng này lưu thông tin về các ID của CompanyID, FieldID, và CompanyFieldID.
Bảng 15: Bảng tách liên kết N-N.
Các thực thể trong phân hệ hỗ trợ khách hàng (Xem hình vẽ 16)
Company: Thông tin chung về các doanh nghiệp gồm CompanyID,
CompanyName, Address, Email, PhoneNumber,City. Mỗi doanh nghiệp được hệ
thống cho phép đăng ký một CompanyID xác định và được phép đăng những thông tin liên quan đến doanh nghiệp đó. Những thông tin này sẽ được lưu trong DetailCompany.
DetalCompany: Thông tin chi tiết về doanh nghiệp gồm NewID, CompanyID,
Title, Subject, Content, Photo, CreatDate, StatusID. Mỗi doanh nghiệp có nhiều
thông tin được đăng lên và được xác định bằng một NewID của thông tin đó. Mối quan hệ giữa Company và DetailCompany là quan hệ một – nhiều (1 -N).
Project: Thông tin về các dự án mà mỗi doanh nghiệp đã và đang thực hiện.
Thực thể Project gồm các thuộc tính sau ProjectID, CompanyID, ProjectName,
Subject, Content, DateFinish. Một doanh nghiệp có thể có nhiều dự án khác nhau
nên quan hệ giữa Company và Project là quan hệ một – nhiều (1 - N).
Field: Thông tin về các lĩnh vực mà doanh nghiệp có thể đáp ứng cho khách
hàng. Thực thể này gồm các thuộc tính sau FielID, FielName, Description. Mỗi doanh nghiệp có thể hoạt động ở nhiều lĩnh vực khác nhau, và một lĩnh vực có thể có rất nhiều doanh nghiệp cùng hoạt động vì vậy mối quan hệ giữa Field và Company là quan hệ nhiều – nhiều (N - N). Chuẩn hóa quan hệ này thành một – nhiều em xin đưa vào thực thể CompanyField như sau.
CompanyField: Thực thể này gồm các thuộc tính CompanyFieldID,
CompanyID, FieldID. Mỗi doanh nghiệp gồm nhiều CompanyField và mỗi Field
cũng gồm nhiều CompanyField khác nhau. Vì vậy quan hệ giữa thực thể Field và Company được tách thành các quan hệ một – nhiều (1 - N) thông qua một thực thể trung gian CompanyField.
User: Thực thể này gồm các thuộc tính như UserID, UserName, CompanyID,
…Mỗi doanh nghiệp có nhiều User cùng đăng ký trên hệ thống tùy thuộc vào vai
trò của từng user đối với hệ thống. Quan hệ giữa Company và User là quan hệ một – nhiều (1 - N).
Opinion: Thực thể này gồm các thuộc tính OpinionID, UserID, Title, Subject,
đã đăng ký với hệ thống và được hệ thống cấp cho quyền đăng ý kiến sẽ được hệ thống chấp nhận cho phép đưa ý kiến nếu user chưa được cấp quyền đăng ý kiến hệ thống sẽ báo lỗi và không cho phép đăng ý kiến. Quan hệ giữa User và Opinion là quan hệ một – nhiều (1 -N).
QuestionDetail: Thực thể này gồm các thuộc tính QuestionDetailID, Title,
Content, StatusID, UserID, CreateDate, Email, ProjectName, FieldID. Mỗi user
có thể đăng một hay nhiều câu hỏi nếu user được hệ thống cấp quyền cho phép đăng câu hỏi mỗi câu hỏi được xác định bằng một QuestionDetailID, và mỗi câu hỏi được đánh dấu trạng thái chưa trả lời, đang trả lời, hay đã trả lời. Trạng thái này sẽ được cập nhật lại khi câu hỏi được trả lời. Quan hệ giữa User và QuestionDetail là quan hệ một – nhiều (1 - N).
AnswerDetail: Thực thể này gồm các thuộc tính AnswerDetailID,
QuestionDetailID, Title, Content, CreatDate, UserAnswer. Mỗi câu hỏi có thể có
nhiều câu trả lời bổ xung và đều được cập nhật ngày tháng trả lời cũng như trạng thái trả lời, người trả lời là ai. Quan hệ giữa QuestionDetail và AnserDetail là quan hệ một – nhiều (1 - N).
Status: Gồm các thuộc tính StatusID, StatusName. Thực thể này lưu thông tin
về các trạng thái các câu hỏi hay câu trả lời. Quan hệ giữa Status và QuestionDetail là quan hệ một – nhiều (1 - N).
Sơ đồ EA trong phân hệ hỗ trợ khách hàng.
Hình 16: Mô hình EA phân hệ hỗ trợ khách hàng.
Tóm tắt chương V: Chương cài đặt hệ thống.
Hệ quản trị sử dụng trong bài đồ án: SQL Server 2005
Phân tích chi tiết từng bảng trong phân quyền người dùng trong hệ thống và giải thích mối quan hệ các bảng tại sao phải sử dụng các liên kết 1 – N việc tách các liên kết N – N thành 1 – N như thế nào.
Phân tích chi tiết từng bảng trong phân hệ hỗ trợ khách hàng và giải thích mối quan hệ các bảng tại sao phải sử dụng các liên kết 1 – N việc tách các liên kết N – N thành 1 – N như thế nào.
CHƯƠNG VI: ĐÁNH GIÁ HỆ THỐNG VÀ GIỚI THIỆU SẢN PHẨM
6.1. Đánh giá hệ thống.
Đánh giá hệ thống là một hoạt động đánh giá toàn bộ hệ thống đã xây dựng nhằm đảm bảo hệ thống hoạt động ổn định và không bị lỗi. Đảm bảo hiệu quả là hệ thống tối ưu.
6.2. Kiểm thử hệ thống.
Kiểm thử hệ thổng là một khâu rất quan trọng đối với bất kỳ phần mềm hay hệ thống nào nhằm đưa lại một sản phẩm hoàn chỉnh đảm bảo ít lỗi xảy ra trong quá trình thực thi hệ thống trong thực tế.
6.2.1. Đặc tả yêu cầu kiểm thử.
STT Chức năng Yêu cầu
1 Đăng nhập
hệ thống.
Khi người dùng đăng nhập hệ thống nếu đúng username và password thì hệ thống báo đăng nhập thành công, nếu sai hệ thống sẽ thông báo phải đăng nhập lại. Số lần đăng nhập quá 5 lần bị sai username hay password hệ thống sẽ khóa tài khoản của người dùng trong vòng 10 phút.
2 Thêm mới
tin tức.
Người thêm tin tức mới nếu được hệ thống cấp cho quyền thêm tin mới.
3 Xem tin tức. Người dùng có thể xem những tin tức nếu được hệ thống cho phép. Người dùng có thể xem tin theo từng chuyên mục khác nhau.
4 Tìm kiếm tin
tức.
Hệ thống cho phép tìm kiếm theo từng chuyên mục khác nhau và theo tưng lĩnh vực.
5 Nhập câu
hỏi. phép đăng câu hỏi mới được quyền đăng, nhữngNhững người được hệ thống cấp quyền cho người không có quyền này sẽ bị hệ thống báo lỗi.
6 Trả lời câu
hỏi.
Chỉ những người được hệ thống cấp quyền trả lời mới có thể đăng câu trả lời. Nếu không sẽ bị hệ thống báo lỗi.
7 Quản lý
portal thống. Portal mới được tạo ra khi đã nhập đầyĐây là người có quyền cao nhất trong hệ đủ thông tin được yêu cầu.
8 Quản lý
người dùng. portal (host hoặc admin). Người này có quyềnĐược cấp cho người có quyền cao nhất trong thêm mới, sửa, xóa người dùng trong portal mà họ quản lý.
9 Quản lý
nhóm quyền
Được cấp cho người có quyền cao nhất trong portal (host hoặc admin). Người được thêm mới quyền cho người dùng chưa được cấp quyền, và có quyền sửa, xóa với những username đã được cấp quyền từ thời điểm trước.
Bảng 16: Bảng đặc tả yêu cầu kiểm thử.
6.2.2. Đặc tả một số trường hợp kiểm thử.
Sau đây là một số trường hợp em thực hiện kiểm thử trên hệ thống.
a. Trường hợp thêm ý kiến khách hàng, hoặc đăng một tin mới.
Trường hợp kiểm thử
Các bước thực hiện
Kết quả mong đợi
Không nhập thông
tin cho trường tiêu đề. tin cho ô tiêu đề màKhông nhập thông nhấn nút save.
Hệ thống báo lỗi yêu cầu bạn phải nhập tất cả các trường thông tin bắt buộc.
Tin tức chưa được lưu vào cơ sở dữ liệu. Nhập đầy đủ thông
tin cần thiết nhưng chưa được hệ thống cấp quyền.
Sau khi nhập đủ thông tin cần thiết và nhấn nút save. Hệ thống kiểm tra quyền đăng nhập của username và thông báo lỗi người này chưa được phép đăng tin.
Hệ thống báo lỗi yêu cầu bạn phải đăng ký role được phép đưa tin tức, ý kiến.
Tin tức chưa được lưu vào cơ sở dữ liệu.
Nhập đầy đủ thông
cấp quyền đăng tin. nút save. Hệ thống kiểm tra quyền đăng nhập đã được hợp lệ.
bạn đã được đăng. Thông tin bạn vừa đăng được lưu vào cơ sở dữ liệu.
Bảng 17: Bảng các trường hợp kiểm thử khi thêm tin mới.
b. Trường hợp đăng câu hỏi.
Trường hợp kiểm
thử Các bước thựchiện Kết quả mong đợi
Không nhập đầy đủ các trường thông tin yêu cầu. Hoặc không chọn trạng thái cho câu hỏi.
Sau khi nhập câu hỏi nhấn nút save.
Hệ thống yêu cầu bạn phải nhập đầy đủ thông tin cần thiết. Câu hỏi không được lưu vào cơ sở dữ liệu. Nhập đầy đủ thông
tin cần thiết và không chọn trạng thái cho câu hỏi. Người dùng đăng nhập quyền hợp lệ.
Sau khi nhập đủ thông tin cần thiết và nhấn nút save. Hệ thống kiểm tra quyền đăng nhập của người đưa câu hỏi là hợp lệ.
Hệ thống thông báo câu hỏi đã được đưa vào cơ sở dữ liệu. Và trạng thái mặc định khi câu hỏi được đưa vào là chưa trả lời.
Nhập đầy đủ thông tin cần thiết và người dùng đăng nhập quyền không hợp lệ.
Sau khi nhấn nhập đủ thông tin và nhấn nút save. Hệ thống kiểm tra quyền đăng nhập và phát hiện lỗi.
Hệ thống đưa ra thông báo bạn không có quyền đưa câu hỏi. Và câu hỏi không được lưu vào cơ sở dữ liệu. Bảng 18: Trường hợp kiểm thử khi người dùng đăng câu hỏi.
c. Trường hợp đăng câu trả lời.
Trường hợp kiểm thử
Các bước thực hiện.
Kết quả mong đợi.
Nhập đầy đủ thông tin nhưng người dùng không có quyền đăng câu trả lời.
Nhập đủ thông tin vào form trả lời. Và