Xml xay dung_he_thong_ho_tro_khach_hang

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN KHOA CÔNG NGHỆ THÔNG TIN BỘ MÔN HỆ THỐNG THÔNG TIN

NGUYỄN THỊ KIM PHƯỢNG – TRƯƠNG KIỀU GIANG

KHÓA LUẬN CỬ NHÂN TIN HỌC

TP.HCM, 2005

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN KHOA CÔNG NGHỆ THÔNG TIN BỘ MÔN HỆ THỐNG THÔNG TIN

NGUYỄN THỊ KIM PHƯỢNG 0112237 TRƯƠNG KIỀU GIANG 0112344

GIÁO VIÊN HƯỚNG DẪN

THẠC SĨ: NGUYỄN TRẦN MINH THƯ

NIÊN KHÓA 2001-2005

Lôøi caûm ôn Chuùng em xin chaân thaønh caûm ôn Ban giaùm hieäu, quyù Thaày Coâ cuûa

tröôøng Ñaïi hoïc Khoa Hoïc Töï Nhieân Tp.Hoà Chí Minh, ñaëc bieät laø

caùc Thaày Coâ trong khoa Coâng Ngheä Thoâng Tin ñaõ taän tình giaûng

daïy, trang bò cho chuùng em nhöõng kieán thöùc caàn thieát trong suoát nhöõng

naêm hoïc taäp taïi tröôøng.

Chuùng em xin chaân thaønh caûm ôn Thaïc só Nguyeãn Traàn Minh Thö

ñaõ taän tình quan taâm, höôùng daãn vaø giuùp ñôõ chuùng em trong quaù trình

thöïc hieän luaän vaên ñeå chuùng em coù theå hoaøn thaønh toát luaän vaên naøy.

Chuùng toâi xin chaân thaønh caûm ôn caùc anh chò cuøng caùc baïn ñaõ coù

nhöõng nhaän xeùt, ñoùng goùp yù kieán, ñoäng vieân, quan taâm vaø giuùp ñôõ

chuùng toâi vöôït qua khoù khaên trong suoát quaù trình thöïc hieän ñeà taøi.

Cuoái cuøng, chuùng con xin göûi loøng bieát ôn saâu saéc ñeán cha meï, gia

ñình ñaõ taïo moïi ñieàu kieän veà vaät chaát, tinh thaàn, ñoäng vieân, khích leä

vaø hoã trôï chuùng con trong suoát thôøi gian qua.

Tp.Hoà Chí Minh, ngaøy 12 thaùng 7 naêm 2005

Nhoùm sinh vieân thöïc hieän

Nguyeãn Thò Kim Phöôïng – Tröông Kieàu Giang

LỜI NÓI ĐẦU Thế kỷ 21 - thế kỷ của sự bùng nổ công nghệ thông tin, các công nghệ

tiên tiến phát triển như vũ bão, mang một luồng gió mới thổi vào nhận thức

của mỗi người. Song song đó, thế giới đang trong xu thế toàn cầu hóa, tất

cả đều mang ý nghĩa hội nhập. Lúc này, các doanh nghiệp và chính phủ

không chỉ cạnh tranh với các doanh nghiệp trong một quốc gia mà còn cạnh

tranh với các doanh nghiệp, chính phủ ở khắp thế giới. Vì thế, để tồn tại và

phát triển, mục tiêu mà các doanh nghiệp hướng đến đầu tiên là nâng cao

chất lượng phục vụ khách hàng. Khách hàng là yếu tố sống còn của bất kỳ

doanh nghiệp nào trong thế kỷ 21. Một chính phủ muốn quốc gia mình phát

triển phải xem nhân dân và doanh nghiệp là khách hàng. Để có khách hàng

đã khó, để giữ khách hàng càng khó hơn nhiều. Doanh nghiệp nào làm cho

khách hàng thỏa mãn, doanh nghiệp đó sẽ phát triển tốt, chính phủ nào làm

nhân dân hài lòng chính phủ đó sẽ vững mạnh.

Trong bối cảnh phát triển mạnh mẽ của Internet nói chung, thương mại

điện tử và chính phủ điện tử nói riêng, việc ứng dụng công nghệ thông tin

vào lĩnh vực dịch vụ khách hàng không là mới trên thế giới nhưng là mới ở

Việt Nam. Nhiều vấn đề đặt ra là làm thế nào đem đến cho khách hàng sự

phục vụ tốt nhất, tiện lợi và hiệu quả nhất. Chính vì vậy đề tài “Tìm hiểu

công nghệ XML và xây dựng hệ thống quản lý dịch vụ khách hàng”

được đưa ra nhằm giúp cho các doanh nghiệp hay các tổ chức nhà nước

hỗ trợ khách hàng hiệu quả hơn. Với luận văn này, nhóm chúng em mong

muốn sẽ xây dựng được một hệ thống hỗ trợ khách hàng giảm chi phí về

nhân sự và viễn thông, thời gian hỗ trợ ngắn hơn, thông tin hỗ trợ chính xác

theo yêu cầu và không bỏ sót yêu cầu của khách hàng.

Nội dung của đề tài gồm các phần chính sau:

Chương 1: Tổng quan - Giới thiệu đôi nét về hệ thống hỗ trợ dịch vụ khách

hàng như mục tiêu, phạm vi, đối tượng mà hệ thống hướng tới. Song song

đó là các cách tiếp cận bài toán và đưa ra hướng giải quyết bài toán.

Chương 2: Giới thiệu công nghệ XML – Đề tài sử dụng một công nghệ mới

để hỗ trợ trong vấn đề lưu trữ và trao đổi thông tin trong môi trường Internet

đó là XML. Chương này sẽ giới thiệu được cho mọi người biết XML là gì và

các công nghệ đang được hỗ trợ trên XML.

Chương 3: Mô tả hệ thống quản lý dịch vụ khách hàng - Mô tả chi tiết hệ

thống hỗ trợ dịch vụ khách hàng và đưa ra các yêu cầu mà hệ thống sẽ

được xây dựng.

Chương 4: Phân tích ứng dụng - Phân tích chi tiết các yêu cầu theo mô

hình UML (Unified Model Language).

Chương 5: Thiết kế và cài đặt ứng dụng.

Chương 6: Kết luận và hướng phát triển – Tổng kết những kết quả đạt được

và mặt hạn chế của đề tài, đồng thời cũng đưa ra hướng phát triển cho hệ

thống sau này.

Phần cuối cùng là Tài liệu tham khảo và phụ lục.

Do thời gian có hạn, kinh nghiệm phân tích, thiết kế, cài đặt còn hạn chế

nên chắc chắn không tránh khỏi một số sai sót nhất định. Rất mong nhận

được sự đóng góp ý kiến của quý Thầy Cô và bạn bè để chúng em hoàn

thiện đề tài này.

Tìm hiểu công nghệ XML và xây dựng hệ thống quản lý dịch vụ khách hàng

MỤC LỤC

Chương 1: MỞ ĐẦU....................................................................................... 9

1.1. Giới thiệu ứng dụng ............................................................................ 9

1.2. Đối tượng và phạm vi của ứng dụng................................................. 10

1.2.1. Đối tượng .................................................................................... 10

1.2.2. Phạm vi ....................................................................................... 10

1.3. Mục tiêu cần đạt được và các cách tiếp cận bài toán ........................ 11

1.3.1. Mục tiêu cần đạt được................................................................. 11

1.3.2. Các cách tiếp cận bài toán .......................................................... 11

1.3.3. Vấn đề đặt ra cho hệ thống hỗ trợ dịch vụ khách hàng .............. 16

1.4. Hướng giải quyết bài toán ................................................................. 18

1.4.1. Về tốc độ thực hiện câu truy vấn ................................................ 18

1.4.2. Vấn đề tìm kiếm thông tin .......................................................... 21

Chương 2: NGHIÊN CỨU CÔNG NGHỆ XML....................................... 25

2.1. Tổng quan về XML........................................................................... 25

2.1.1. Giới thiệu .................................................................................... 25

2.1.2. Mục tiêu ra đời và lợi ích khi sử dụng XML.............................. 25

2.1.3. Một tài liệu XML trông như thế nào?......................................... 27

2.1.4. Tạo lập một tài liệu XML ........................................................... 27

2.1.5. Những thành phần của một tài liệu XML................................... 28

2.1.6. Một tài liệu XML hợp lệ ............................................................. 29

2.1.7. XPath........................................................................................... 33

2.1.8. Nhận xét về XML ....................................................................... 34

2.2. Cách sử dụng một tài liệu XML....................................................... 34

2.2.1. Đọc và phân tích tài liệu XML ................................................... 35

2.2.2. Định hướng qua tài liệu XML để rút trích dữ liệu: .................... 37

SVTH: Nguyễn Thị Kim Phượng GVHD: Th.S Nguyễn Trần Minh Thư T rương K iều G iang 9


2.2.3. Truy vấn dữ liệu XML sử dụng XPathDocument và XPathNavigator..................................................................................... 39

2.2.4. Nhận xét ...................................................................................... 45

2.3. XML và Cơ sở dữ liệu....................................................................... 45

2.3.1. XML có phải là Cơ sở dữ liệu? .................................................. 45

2.3.2. Vai trò XML trong hệ thống hỗ trợ dịch vụ khách hàng............ 46

2.3.3. Mô hình lưu trữ trong hệ thống quản lý dịch vụ khách hàng (eSupport) ............................................................................................. 47

Chương 3: MÔ TẢ HỆ THỐNG QUẢN LÝ DỊCH VỤ KHÁCH HÀNG

......................................................................................................................... 48

3.1. Đối tượng sử dụng............................................................................. 48

3.2. Mô tả hệ thống quản lý dịch vụ khách hàng ..................................... 48

3.2.1. Phân hệ hỗ trợ khách hàng.......................................................... 48

3.2.2. Phân hệ hỗ trợ hệ thống .............................................................. 49

3.3. Xác định yêu cầu chức năng hệ thống .............................................. 51

3.3.1. Yêu cầu chức năng nghiệp vụ..................................................... 51

3.3.2. Yêu cầu chức năng hệ thống....................................................... 61

3.3.3. Yêu cầu phi chức năng................................................................ 63

Chương 4: PHÂN TÍCH............................................................................... 64

4.1. Lược đồ USE-CASE ......................................................................... 64

4.2. Đặc tả Use-Case ................................................................................ 66

4.2.1. Đặc tả Use-Case Tìm kiếm FAQ................................................ 66

4.2.2. Đặc tả Use-Case Đăng ký tài khoản ........................................... 67

4.2.3. Đặc tả Use-Case Tạo yêu cầu ..................................................... 69

4.2.4. Đặc tả Use-Case Xem và hiệu chỉnh yêu cầu............................. 70

4.2.5. Đặc tả Use-Case Giải đáp yêu cầu.............................................. 72

4.2.6. Đặc tả Use-Case Tìm kiếm yêu cầu............................................ 73

4.2.7. Đặc tả Use-Case Quản lý yêu cầu............................................... 74



4.2.8. Đặc tả Use-Case Quản lý FAQ................................................... 76

Chương 5: THIẾT KẾ .................................................................................. 79

5.1. Hiện thực hóa Use-Case.................................................................... 79

5.1.1. Use-Case Tìm kiếm FAQ ........................................................... 79

5.1.2. Use-Case Đăng ký tài khoản....................................................... 81

5.1.3. Use-Case Tạo yêu cầu mới ......................................................... 83

5.1.4. Use-Case Giải quyết yêu cầu...................................................... 85

5.1.5. Use-Case Xem và hiệu chỉnh yêu cầu ........................................ 87

5.1.6. Use-Case Tìm kiếm yêu cầu ....................................................... 89

5.1.7. Use-Case Quản lý yêu cầu.......................................................... 91

5.1.8. Use-Case Quản lý FAQ .............................................................. 93

5.2. Thiết kế cơ sở dữ liệu........................................................................ 96

5.2.1. Sơ đồ lớp..................................................................................... 96

5.2.2. Mô hình quan hệ ......................................................................... 97

5.2.3. Mô tả chi tiết các lớp đối tượng.................................................. 98

5.2.4. Mô tả các ràng buộc toàn vẹn ................................................... 102

5.3. Thiết kế cài đặt và triển khai ........................................................... 105

5.3.1. Mô hình cài đặt ......................................................................... 105

5.3.2. Mô hình triển khai hệ thống...................................................... 106

5.4. Thiết kế giao diện............................................................................ 107

5.4.1. Sơ đồ liên kết các màn hình...................................................... 108

5.4.2. Thiết kế chi tiết một số màn hình ............................................. 109

Chương 6: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN ............................. 121

6.1. Kết luận ........................................................................................... 121

6.2. Hướng phát triển ............................................................................. 123

TÀI LIỆU THAM KHẢO ..........................................................................124

PHỤ LỤC.....................................................................................................125



Danh mục hình vẽ:

Hình 1-1: Phạm vi hệ thống ........................................................................... 10

Hình 1-2: Giải pháp 1..................................................................................... 12

Hình 1-3: Giải pháp 2..................................................................................... 13

Hình 1-4: Giải pháp 3..................................................................................... 14

Hình 1-5: Giải pháp 4..................................................................................... 14

Hình 1-6: Giải pháp 5..................................................................................... 15

Hình 1-7: Giải pháp 6..................................................................................... 16

Hình 1-8: Mô hình truy vấn dữ liệu ............................................................... 17

Hình 1-9: Mô hình truy vấn dữ liệu có hỗ trợ XML...................................... 20

Hình 1-10: Mô hình xử lý tìm kiếm............................................................... 21

Hình 1-11: Mô hình mô tả vai trò của XML.................................................. 24

Hình 2-1: Mô hình DOM ............................................................................... 38

Hình 5-1: Sơ đồ lớp........................................................................................ 96

Hình 5-2: Mô hình quan hệ cơ sở dữ liệu ...................................................... 97

Hình 5-3: Mô hình cài đặt ............................................................................ 105

Hình 5-4: Mô hình triển khai hệ thống ........................................................ 107

Hình 5-5: Sơ đồ liên kết các màn hình......................................................... 108

Danh mục các bảng:

Bảng 2-1: Danh sách các kiểu dữ liệu của lược đồ XML.............................. 33

Bảng 4-1: Danh sách các Actor...................................................................... 65

Bảng 4-2: Danh sách các Use-Case ............................................................... 66

Bảng 5-1: Danh sách các đối tượng lưu trữ dữ liệu ....................................... 98



Chương 1: MỞ ĐẦU

1.1. Giới thiệu ứng dụng Hệ thống quản lý dịch vụ khách hàng được xây dựng với mục tiêu chủ yếu

là hỗ trợ cho khách hàng khi có nhu cầu tìm hiểu thông tin về sản phẩm và

dịch vụ của doanh nghiệp. Hệ thống hoạt động như sau:

Khi khách hàng có nhu cầu tìm kiếm các thông tin liên quan đến sản phẩm

và dịch vụ của công ty hay doanh nghiệp, khách hàng vào khu vực dịch vụ

khách hàng (gọi là helpdesk) để tìm kiếm thông tin trong các câu hỏi và câu

trả lời có sẵn (còn gọi là hệ thống FAQ).

Trường hợp không tìm thấy thông tin cần thiết trong FAQ, khách hàng có

thể gửi yêu cầu và yêu cầu được giải đáp từ phía doanh nghiệp, công ty.

Khách hàng có thể gửi trực tiếp qua hệ thống website hỗ trợ khách hàng hoặc

gửi email trực tiếp về địa chỉ email hỗ trợ của doanh nghiệp, khách hàng sẽ

được giải đáp trong thời gian nhanh nhất có thể.

Nhân viên phụ trách giải đáp yêu cầu của khách hàng sẽ xem xét yêu cầu

và giải đáp cho khách hàng, nếu yêu cầu gửi không đúng phòng ban sẽ được

nhân viên chuyển qua phòng ban phù hợp.

Nội dung câu hỏi và trả lời của mỗi yêu cầu được nhân viên tuyển chọn,

sàng lọc để cập nhật vào FAQ. Như thế khi khách hàng cần thông tin tương tự

thì có thể tìm kiếm ngay trong hệ thống FAQ một cách nhanh chóng và tiện

lợi.

Quản trị hệ thống theo dõi quá trình giải quyết yêu cầu của các nhân viên,

đảm bảo cho các yêu cầu của khách hàng được hỗ trợ kịp thời.



1.2. Đối tượng và phạm vi của ứng dụng

1.2.1. Đối tượng

Hệ thống quản lý dịch vụ khách hàng (eSupport) được xây dựng hướng

đến các đối tượng là các doanh nghiệp, công ty vừa và lớn trong cả nước song

song đó là các khách hàng giao dịch với doanh nghiệp. Do nhu cầu cạnh tranh

các doanh nghiệp cần phải phục vụ tốt khách hàng về các mặt hỗ trợ thông

tin, giải đáp, vì thế các doanh nghiệp này cần có hệ thống hỗ trợ dịch vụ

khách hàng để kịp thời đáp ứng yêu cầu của khách hàng trong quá trình giao

dịch với doanh nghiệp.

1.2.2. Phạm vi

Đầu vào: yêu cầu, tìm kiếm, download,…

Phân hệ hỗ trợ khách hàng

Phân hệ hỗ trợ hệ thống

Đầu ra: yêu cầu được giải quyết, vấn đề tìm kiếm được, …

Môi trường: khách hàng, doanh nghiệp, …

Hình 1-1: Phạm vi hệ thống

Hệ thống được xây dựng để hỗ trợ, phục vụ khách hàng trong phạm vi

giữa doanh nghiệp và khách hàng xoay quanh các vấn đề về thông tin các sản

phẩm và dịch vụ của doanh nghiệp.



1.3. Mục tiêu cần đạt được và các cách tiếp cận bài

toán

1.3.1. Mục tiêu cần đạt được

1.3.1.1. Yêu cầu chức năng

Yêu cầu chức năng nghiệp vụ

Thực hiện đầy đủ các chức năng nghiệp vụ như tìm kiếm yêu cầu, tạo yêu

cầu, giải quyết yêu cầu, tải tài liệu, tìm kiếm thông tin, v.v.…

Yêu cầu chức năng hệ thống:

Thực hiện các chức năng tự động như: gởi câu trả lời cho khách hàng qua

email, gởi thông báo qua email, thống kê, nhận yêu cầu của khách hàng qua

email, v.v…Việc lưu trữ dữ liệu phải đạt chi phí tối thiểu và có sự ổn định

cao.

1.3.1.2. Yêu cầu phi chức năng

Hệ thống hỗ trợ dịch vụ khách hàng làm việc hiệu quả, có thể giúp doanh

nghiệp giảm chi phí về thời gian và nhân lực, giúp doanh nghiệp giải đáp

nhanh và chính xác khi khách hàng có yêu cầu, có thể hỗ trợ trực tuyến

(online), v.v…

1.3.2. Các cách tiếp cận bài toán

Hệ thống hỗ trợ dịch vụ khách hàng không còn xa lạ với các doanh nghiệp

trong cả nước vì tầm quan trọng và ích lợi của nó trong vấn đề giao dịch với

khách hàng. Vì thế nhu cầu xây dựng một hệ thống phục vụ khách hàng cho

doanh nghiệp là cần thiết và tất yếu. Nhưng khi bắt đầu xây dựng hệ thống,



điều quan tâm đầu tiên của chúng ta là gì? Bất cứ hệ thống nào vấn đề quan

trọng đầu tiên cần được quan tâm là tổ chức tốt việc lưu trữ dữ liệu. Nếu dữ

liệu được tổ chức tốt thì hệ thống của chúng ta sẽ cải thiện về mọi mặt như tốc

độ truy xuất, chi phí lưu trữ, thời gian cập nhật, v.v…Như vậy, làm cách nào

tổ chức tốt việc lưu trữ dữ liệu, nhất là ứng dụng của hệ thống dịch vụ khách

hàng chạy trong môi trường Internet, môi trường đa người dùng. Ví dụ như

khách hàng cần tìm kiếm những vấn đề về sản phẩm mà doanh nghiệp nào đó

cung cấp, chúng ta lưu trữ dữ liệu như thế nào để cho việc tìm kiếm của khách

hàng đạt hiệu quả là nhanh nhất. Để giải quyết vấn đề này, một số giải pháp

cho vấn đề lưu trữ dữ liệu của hệ thống được đề nghị như sau:

1.3.2.1. Giải pháp 1

Theo giải pháp này, việc lưu trữ dữ liệu được tổ chức theo mô hình sau:

Hình 1-2: Giải pháp 1

Ký hiệu: A_Table hay A_Database chỉ một đối tượng trong ngôn ngữ lập

trình có thể giao tiếp với CSDL1 quan hệ. 1 Cơ sở dữ liệu



Ưu điểm: Đây là mô hình đang được sử dụng rất phổ biến vì tận dụng được

những ưu điểm của hệ quản trị cơ sở dữ liệu.

Khuyết điểm: Không linh động trong vấn đề trao đổi dữ liệu giữa các hệ

thống khác nhau đặc biệt là khi ứng dụng chạy trên web.




Ký hiệu: A_XMLDom chỉ đến một đối tượng XML có thể đọc và ghi trên

tập tin XML.

Ưu điểm: Không phụ thuộc vào bất cứ hệ quản trị nào, dễ thực hiện.

Khuyết điểm: Việc thao tác truy vấn trên tập tin XML2 còn nhiều hạn chế

và vấn đề bảo mật không bằng hệ quản trị.


Theo giải pháp này, việc lưu trữ dữ liệu được tổ chức theo mô hình sau: 2 Extensible Markup Language




Ưu điểm: Tận dụng được cả hai cách lưu trữ đó là trên tập tin và trên hệ

quản trị.

Khuyết điểm: Không phải tập tin XML nào cũng có thể đọc/ghi bằng đối

tượng Datatable vì có nhiều tập tin XML lưu trữ phức tạp.






Ưu điểm: Mô hình này nghiên về việc lưu trữ trên tập tin XML. Và việc

trao đổi giữa một đối tượng XMLDom và cơ sở dữ liệu quan hệ cũng dễ dàng

vì từ SQL Server 2000 trở lên đã hỗ trợ truy xuất trên tập tin XML.

Khuyết điểm: Mặc dù từ SQL 2000 trở lên có hỗ trợ XML nhưng việc tạo

ra tập tin XML vẫn còn bị lỗi do không thể tạo ra đúng cấu trúc mà người

dùng mong đợi nếu như cấu trúc XML đó phức tạp.




Ưu điểm: Việc đọc/ghi trên từng đối tượng đã được tách riêng biệt ra để

mỗi đối tượng chỉ làm đúng nhiệm vụ của đối tượng đó nên thuận tiện trong

vấn đề xử lý.

Khuyết điểm: Vấn đề là làm cách nào để thực hiện việc chuyển đổi từ đối

tượng XMLDom thành đối tượng Datatable và ngược lại.






Ưu điểm: Việc trao đổi thông tin giữa các đối tượng rất linh động, vì một

đối tượng XMLDom có thể đọc/ghi trực tiếp đến CSDL quan hệ hoặc có thể

thông qua một Datatable.

Khuyết điểm: Do có nhiều cách đọc/ghi nên phức tạp, khó quản lý.

Kết luận: Mỗi giải pháp có ưu điểm và khuyết điểm khác nhau. Việc

chọn lựa mô hình nào sẽ tùy thuộc vào nhu cầu của ứng dụng của chúng ta.

Nghĩa là ứng dụng của chúng ta sẽ quan tâm vấn đề nào? Vấn đề nào là vấn

đề được quan tâm hàng đầu thì lúc đó chúng ta sẽ lựa chọn giải pháp lưu trữ

dữ liệu cho phù hợp.

1.3.3. Vấn đề đặt ra cho hệ thống hỗ trợ dịch vụ khách hàng

Vấn đề quan tâm hàng đầu của hệ thống là làm sao tăng tốc độ thực hiện

các thao tác truy vấn trên cơ sở dữ liệu quan hệ. Ví dụ như khách hàng cần

tìm kiếm thông tin trong hệ thống FAQ, khách hàng sẽ nhập vào câu hỏi cần

tìm kiếm, sau đó chương trình sẽ thực hiện kết nối với SQL để thực hiện câu



truy vấn trả về thông tin tìm kiếm được cho khách hàng. Mô hình thực hiện

được mô tả như sau:

Hình 1-8: Mô hình truy vấn dữ liệu

Như vậy, nếu có nhiều khách hàng có nhu cầu tìm kiếm thì mỗi khách

hàng đều phải kết nối đến SQL Server để lấy dữ liệu. Và sẽ có trường hợp

nhiều khách hàng đều cùng truy vấn đến cùng một dữ liệu, khi đó thời gian

thực hiện câu truy vấn để trả về kết quả sẽ rất chậm do phải thực hiện việc

điều khiển đồng thời, phân bổ tài nguyên để thực hiện câu truy vấn tại CSDL.

Một vấn đề khác đặt ra cho hệ thống là không chỉ tìm kiếm được vấn đề

dựa trên câu hỏi mà phải tìm kiếm được tất cả những vấn đề có liên quan đến

nội dung câu hỏi. Nghĩa là nếu khách hàng nhập vào câu hỏi: “các vấn đề liên

quan đến mạng và email” thì hệ thống sẽ phải trả về tất cả những vấn đề có

liên quan đến từ khóa “mạng” và “email”. Như vậy nếu chỉ đơn thuần tổ chức

trên CSDL quan hệ thì không thể giải quyết được vấn đề này vì với cách thực

hiện trên CSDL quan hệ, mà cụ thể là SQL Server 2000, nó sẽ tìm đúng cụm



từ “các vấn đề liên quan đến mạng và email” và nếu trong CSDL không có

đúng cụm từ này thì kết quả trả về là không có, trong khi mong đợi của người

dùng là trả ra những vấn đề có liên quan đến “mạng” và “email”.

Tóm lại: Chúng ta có hai vấn đề cần giải quyết khi lưu trữ dữ liệu trên

SQL Server

− Tốc độ thực hiện câu truy vấn.

− Việc tìm kiếm thông tin hiệu quả

Làm sao giải quyết được bài toán đặt ra cho hệ thống khi chỉ lưu trữ trên

CSDL quan hệ.

1.4. Hướng giải quyết bài toán

Chúng ta thấy được việc sử dụng giải pháp 1 để lưu trữ dữ liệu sẽ không

giải quyết được những vấn đề đặt ra cho bài toán. Và như vậy cần thiết phải

sử dụng mô hình khác để hệ thống thực hiện khả thi hơn.

Sau đây, chúng ta sẽ xem qua cách hệ thống thực hiện để giải quyết lần

lượt các vấn đề trên, và từ đó chọn ra giải pháp lưu trữ thích hợp nhất.

1.4.1. Về tốc độ thực hiện câu truy vấn

Nhu cầu khách hàng tìm kiếm các vấn đề cần giải đáp là thường xuyên xảy

ra và với tần suất rất cao nên việc lưu trữ trong SQL Server sẽ không khả thi.

Nên chúng ta sẽ sử dụng thêm một cách lưu trữ nữa đó là trên tập tin mà cụ

thể là trên tập tin XML. Giải pháp thực hiện cụ thể như sau:

Giả sử trong SQL Server ta lưu trữ dữ liệu của bảng Câu hỏi-Trả Lời

(FAQ) như sau:



FAQ_ID FAQ_QUESTION FAQ_ANSWER … FAQ_TOP_ID

FAQ00001 Cách nhận biết người nhận thư đã đọc thư của mình hay chưa?

Bạn làm theo các bước sau…. … TOP001

FAQ00002 Hỏi về phần mềm gõ tiếng Việt?

Unikey là một phần mềm….. … TOP002

FAQ00003 … … … …

FAQ00004 … … … …

… … … … …

FAQ000020 … … … …

… … … … …

Bằng việc sử dụng các công cụ hỗ trợ trong môi trường lập trình Visual

Studio.NET, ta sẽ tạo được tập tin FAQ.xml từ dữ liệu được lưu trữ trong

bảng FAQ có nội dung và cấu trúc như sau:

<? xml version="1.0"?>

<Danh_sach_FAQ>

<FAQ FAQ_ID= “FAQ00001”

<FAQ_Cau_Hoi>

Cách nhận biết người nhận thư đã đọc thư của mình hay chưa?

</FAQ_Cau_Hoi>

<FAQ_Cau_Tra_Loi>

Bạn làm theo các bước sau, để khi gửi thư cho mọi người trên giao diện Outlook Express sẽ có phản hồi lại là họ đã đọc thư…..

</FAQ_Cau_Tra_Loi>

<FAQ_Ngay_Cap_Nhat> 10-7-2005 </FAQ_Ngay_Cap_Nhat>

<FAQ_Ma_Chu_De> TOP001 </FAQ_Ma_Chu_De>

<FAQ_So_Lan_Xem> 10 </FAQ_So_Lan_Xem>

<FAQ_Ma_Tai_Lieu_Tai_Ve> DOC001 </FAQ_Ma_Tai_Lieu_Tai_Ve>

</FAQ>

<FAQ FAQ_ID= “FAQ00002”

<FAQ_Cau_Hoi>…….</FAQ_Cau_Hoi>



<FAQ_Cau_Tra_Loi>…..</FAQ_Cau_Tra_Loi>

<FAQ_Ngay_Cap_Nhat>…..</FAQ_Ngay_Cap_Nhat>

….

</FAQ>

…………….

…………….

</Danh_sach_FAQ>

Như vậy, mỗi khi khách hàng có nhu cầu tìm kiếm trong hệ thống FAQ,

thì không cần phải thực hiện kết nối đến SQL Server, mà chỉ cần mở tập tin

FAQ.xml và thực hiện việc truy vấn trên tập tin XML, cuối cùng trả về kết

quả cho khách hàng. Như vậy, việc thực hiện trên tập tin sẽ nhanh hơn rất

nhiều so với cơ sở dữ liệu (mở kết nối, tìm kiếm dữ liệu và thực hiện truy vấn

trên dữ liệu tìm được để cuối cùng cho ra kết quả như mong muốn =>truy vấn

chậm).

Mô hình minh họa như sau:

Hình 1-9: Mô hình truy vấn dữ liệu có hỗ trợ XML



1.4.2. Vấn đề tìm kiếm thông tin Muốn kết quả tìm kiếm đúng như mong muốn người dùng thì phải dựa vào

ngữ nghĩa của nội dung câu hỏi mà người dùng nhập vào. Để làm được điều

này thì phải dựa vào từ điển mới biết được chính xác ngữ nghĩa của câu.

Theo đó, dựa trên tập tin FAQ.xml ở trên, chương trình sẽ trích từ dựa trên

từ điển bằng phương pháp LRMM (Left Right Maximum Matching)[4].

Sau đây là mô hình minh họa cho quá trình xử lý

Yêu cầu tìm kiếm Danh sáchcác từ khóa XMLTrích từ và

loại bỏ từ thừa

XML

Bảng dữ liệu

Trích từ vàloại bỏ từ thừa

Danh sáchcác từ khóa

Tạo chỉ mục XML

Kết quảhiển thị

Hình 1-10: Mô hình xử lý tìm kiếm

Theo phương pháp LRMM, để phân đoạn từ tiếng Việt trong một ngữ/câu,

ta đi từ trái sang phải và chọn từ có nhiều âm tiết nhất mà có mặt trong từ

điển, rồi cứ tiếp tục cho từ kế tiếp cho đến hết câu. Với cách này, ta dễ dàng

tách được chính xác các ngữ câu như: “hợp tác xã | mua bán”; “thành lập |

nước | Việt Nam | dân chủ | cộng hòa”…Tuy nhiên, phương pháp này sẽ tách

từ sai trong các trường hợp như: “học sinh | học sinh | học”; “một | ông | quan

tài | giỏi”. Mặc dù vậy, phương pháp này cũng tách từ chính xác đến 95%



(theo giáo trình Xử lý ngôn ngữ tự nhiên). Vì vậy nhóm chúng em quyết định

chọn phương pháp này để sử dụng trong việc trích từ này mặc dù nó chưa

phải là phương pháp tối ưu nhất.

Trở lại vấn đề trích từ cho tập tin FAQ.xml, bằng phương pháp LRMM,

chúng ta sẽ trích được các từ trong tập tin FAQ.xml và lưu thành một tập tin

FAQ_Word.xml với cấu trúc như sau:


<WORDs>

<WORD Name="internet">

<FAQ FAQ_ID="FAQ00003" />






</WORD>

<WORD Name="yêu cầu">



</WORD>

…………….

…………….

</WORDs>

Chú thích: Danh sách các thẻ <FAQ>…</FAQ> trong mỗi thẻ

<WORD>…</WORDS> cho biết ứng với từ này thì có những tài liệu nào

liên quan đến nó.

Tập tin FAQ_Word.xml này sau đó sẽ qua một khâu nữa đó là loại bỏ

những từ thừa gọi là kỹ thuật “stoplist”. Chúng ta sẽ duyệt qua các từ trong

tập tin FAQ_Word.xml và so sánh với tập tin Stoplist.xml (đây là tập tin lưu



những từ thừa), sau đó tiến hành loại bỏ những từ không có nghĩa để cuối

cùng được một tập tin FaqDaLoaiStopList.xml với kích thước tập tin giảm

đáng kể so với tập tin FAQ_Word.xml do đã bỏ đi những từ không có nghĩa.

Đây sẽ là tập tin chúng ta mong muốn để thực hiện việc so khớp khi khách

hàng nhập vào một câu truy vấn.

Như vậy, mỗi khi khách hàng nhập vào nội dung câu hỏi cần tìm kiếm, nội

dung câu hỏi này sẽ được phân đoạn thành những cụm từ và sẽ loại bỏ những

từ thừa, chỉ giữ lại những từ có nghĩa. Và những cụm từ này sẽ được so khớp

với tập tin FaqDaLoaiStopList.xml để trả về kết quả truy vấn cho người dùng

(xem hình 1.10). Với cách thực hiện này, tất cả những vấn đề có liên quan đến

nội dung câu hỏi sẽ được trả về cho người dùng và tất cả những điều này đều

thực hiện trên tập tin XML nên sẽ truy vấn rất nhanh. Như vậy vấn đề đặt ra

đã được giải quyết.

Và bây giờ thì chúng ta đã biết được hệ thống quản lý dịch vụ khách hàng

sẽ chọn giải pháp nào để lưu trữ dữ liệu. Đó là giải pháp 5 vì theo như giải

pháp này, việc lưu trữ dữ liệu sẽ sử dụng cả trên tập tin XML và trên cơ sở dữ

liệu quan hệ.

Mặt khác, việc chọn giải pháp 5 này là do nhu cầu cần thiết phải sử dụng

thêm XML để hỗ trợ trong vấn đề lưu trữ và truy xuất trên hệ thống. Đó là khi

dữ liệu được lưu thông trên môi trường web thì vấn đề trao đổi thông tin giữa

các hệ thống khác nhau là yếu tố cần được xem xét. Do XML giải quyết rất

tốt trong vấn đề này nên cần thiết sử dụng thêm XML. Sau đây là mô hình để

thấy được vai trò của XML:



Hình 1-11: Mô hình mô tả vai trò của XML

Kết luận: Trên đây là một cách nhìn tổng quan về cách thực hiện cũng

như là vấn đề lưu trữ của hệ thống hỗ trợ dịch vụ khách hàng. Như vậy, chúng

ta muốn tạo lập được những tài liệu XML như mong muốn và thực hiện truy

vấn trên tập tin này thì điều tối thiểu là phải biết được XML là gì cũng như

các thao tác thực hiện truy vấn trên tập tin XML như thế nào? Vấn đề như thế

nào, chúng ta sẽ xem tiếp qua chương sau.



Chương 2: NGHIÊN CỨU CÔNG NGHỆ XML

2.1. Tổng quan về XML

2.1.1. Giới thiệu

XML (Extensible Markup Language) ra đời vào tháng 2/1998, là ngôn ngữ

có kiến trúc gần giống với HTML nhưng XML nhanh chóng trở thành một

chuẩn phổ biến trong việc chuyển đổi thông tin qua các trang web sử dụng

giao thức HTTP. Trong khi HTML là ngôn ngữ chủ yếu về hiển thị dữ liệu thì

XML lại đang phát triển mạnh về việc chuyển tải, trao đổi và thao tác dữ liệu

bằng XML. XML đưa ra một định dạng chuẩn cho cấu trúc của dữ liệu hoặc

thông tin bằng việc tự định nghĩa định dạng của tài liệu. Bằng cách này, dữ

liệu được lưu trữ bằng XML sẽ độc lập với việc xử lý. Vì vậy XML ra đời sẽ

đáp ứng được yêu cầu ngày càng cao của các nhà lập trình trong vấn đề trao

đổi và xử lý thông tin.

2.1.2. Mục tiêu ra đời và lợi ích khi sử dụng XML

2.1.2.1. Mục tiêu ra đời của XML

Ngày nay, XML đang trở thành một chuẩn chung cho việc trao đổi dữ liệu

cho những ứng dụng chạy trên môi trường Internet. Vì XML cho phép người

dùng có thể tự định nghĩa các thẻ (tag) - những thẻ này làm cho tài liệu XML

đa dạng hơn những ngôn ngữ thông thường như HTML. Như vậy mục tiêu

đặt ra cho sự ra đời XML là gì? Đó là, đầu tiên nó sẽ tương thích với SGML,

và dễ dàng viết những chương trình để xử lý cho những tài liệu XML. Kế



tiếp, những tài liệu XML rõ ràng, dễ đọc, dễ dàng tạo lập. Và điều quan trọng

là nó được hỗ trợ trong nhiều ứng dụng. Nói tóm lại, XML dễ dàng chia sẻ

thông tin qua những định dạng khác nhau thông qua môi trường web. XML

được thiết kế dành cho mọi người, được mọi người sử dụng.

2.1.2.2. Lợi ích khi sử dụng XML

Trong quá trình trưởng thành và phát triển, XML đã đối mặt và đương đầu

với nhiều thử thách trong việc thuyết phục các nhà lập trình rằng XML là sự

lựa chọn hàng đầu vì nó dễ dàng để hiểu, dễ dàng để đọc, và dễ dàng thực

hiện. Sau đây là một số lợi ích khi sử dụng XML

XML có thể tách rời dữ liệu. Sử dụng XML, dữ liệu được chứa trong

các tập tin XML riêng biệt.

XML có thể mô tả thông tin của những đối tượng phức tạp mà cơ sở dữ

liệu quan hệ không thể giải quyết được.

XML có thể dùng để chuyển đổi dữ liệu giữa các hệ thống không tương

thích.

XML dùng để chia sẻ dữ liệu với những tập tin văn bản đơn giản dễ

hiểu.

XML cũng được dùng để lưu trữ dữ liệu, có thể làm cho dữ liệu của

chúng ta hữu ích hơn.

Như vậy, chúng ta đã biết được lợi ích và vai trò của XML trong vấn đề

lưu trữ và trao đổi thông tin. Vấn đề bây giờ là nếu chúng ta muốn có một tài

liệu XML thì phải làm như thế nào?



2.1.3. Một tài liệu XML trông như thế nào?

Mục đích của việc tổ chức thông tin là để con người có thể đọc và hiểu

được những gì mà nó muốn truyền tải. Chúng ta xem một tập tin văn bản sau

đây:

F10 Shimano Calcutta 47.76

F20 Bantam Lexica 49.99

Theo cách tổ chức thông tin của tập tin trên, chúng ta thật khó để hiểu tập

tin này muốn nói lên điều gì. Bây giờ, chúng ta tổ chức tập tin trên theo định

dạng một tài liệu XML một cách đơn giản nhất.

<?xml version="1.0"?>

<Catalog>

<Product>

<ProductID>F10</ProductID>

<ProductName>Shimano Calcutta </ProductName>

<ListPrice>47.76</ListPrice>

</Product>

<Product>


<ProductName>Bantam Lexica</ProductName>


</Product>

</Catalog>

Như vậy, bằng cách sử dụng định dạng XML, người dùng có thể hiểu và

biết được tập tin trên đang muốn truyền tải nội dung gì.

2.1.4. Tạo lập một tài liệu XML

Chúng ta có thể sử dụng trình soạn thảo đơn giản nhất là Notepad để soạn

thảo tài liệu XML, nhưng phải tuân thủ theo qui tắc sau:



<root>

<child>

<subchild>…..</subchild>

....

</child>

....

</root>

Theo định dạng trên, chúng ta thấy tuy tài liệu XML rất đơn giản nhưng

qui định cũng rất nghiêm ngặt, có nghĩa là các tài liệu XML đều xuất phát từ

nút gốc (root), và mỗi phần tử phải có thẻ đóng và thẻ mở “< …/>”.

2.1.5. Những thành phần của một tài liệu XML Khai báo: Mỗi một tài liệu XML có một chỉ thị khai báo


Định nghĩa tài liệu XML tuân theo chuẩn của W3C và đây là phiên bản

“1.0”

Chú thích: được khai báo như sau:

<!-- chú thích -- >

Phần tử (Elements): Một tài liệu XML được cấu thành từ những phần tử.

Một phần tử có thẻ mở và thẻ đóng. Giữa thẻ mở và thẻ đóng là nội dung

của phần tử đó. Phần tử có thể chứa dữ liệu hoặc có thể lồng vào một phần

tử khác.

Phần tử gốc (root): Trong tài liệu XML, chỉ có một phần tử gốc, và phần

tử này sẽ chứa tất cả những phần tử của tài liệu XML do chúng ta tạo ra.

Theo ví dụ trên, ta thấy chỉ có một phần tử “Catalog” .

Thuộc tính (Attributes): Như đã trình bày ở trên, một phần tử có thể chứa

dữ liệu hoặc chứa phần tử khác hoặc cả hai. Bên cạnh đó, phần tử có thể

rỗng, khi đó nó có thể chứa thuộc tính. Một thuộc tính chỉ là một sự lựa



chọn để gắn dữ liệu đến phần tử. Một thuộc tính đặt trong thẻ mở của phần

tử và chỉ ra giá trị của nó bằng cách sử dụng cặp “name=value”.

<?xml version="1.0"?>

<Catalog>

<Product Type="Spinning Reel" SupplierId="5">


<ProductName>Shimano Calcutta </ProductName>


</Product>

<Product Type ="Baitcasting Reel" SupplierId="3">


<ProductName>Bantam Lexica</ProductName>


</Product>

</Catalog>

2.1.6. Một tài liệu XML hợp lệ

Như chúng ta đã đề cập ở trên, một tài liệu XML hợp khuôn dạng là yếu tố

đầu tiên khi tạo lập tài liệu. Hợp khuôn dạng có nghĩa là mỗi tài liệu chỉ có

một nút gốc, mỗi phần tử phải có thẻ mở và thẻ đóng, và phải lồng nhau chính

xác, và cuối cùng là tên thuộc tính chỉ xuất hiện một lần trong thẻ mở. Nhưng

một tài liệu XML hợp khuôn dạng không có nghĩa là nó hợp lệ. Muốn kiểm

tra sự hợp lệ của một tài liệu XML ta phải dựa vào DTD (Document Type

Definition) hoặc Schema XML.

2.1.6.1. DTD (Document Type Definition)

DTD và Schema là hai cách khác nhau để qui định những luật về nội dung

của một tài liệu XML. Tuy nhiên DTD có một vài hạn chế. Đầu tiên, tài liệu

DTD không sử dụng định dạng XML, nghĩa là bản thân DTD không phải là



một tài liệu XML. Điều thứ hai là kiểu dữ liệu có sẵn dùng để định nghĩa nội

dung của một thuộc tính hoặc một phần tử thì rất giới hạn trong DTD. Điều

thứ ba là DTD không có khả năng mở rộng và không hỗ trợ namespace. Cuối

cùng là do không viết theo định dạng XML nên DTD khó viết và khó hiểu. Vì

vậy, việc sử dụng DTD để kiểm tra sự hợp lệ của một tài liệu XML là không

khả thi. Chúng ta cần có một sự lựa chọn khác khả thi hơn để kiếm tra sự hợp

lệ của tài liệu XML. Đó là chúng ta sử dụng lược đồ XML - Schema XML

Definition (XSD).

2.1.6.2. Lược đồ XML (Schema XML)

2.1.6.2.1. Định nghĩa lược đồ XML

Một lược đồ đơn giản chỉ là một tập những luật được định nghĩa lại để mô

tả nội dung dữ liệu của một tài liệu XML. Nó tương tự như một định nghĩa

cấu trúc bảng trong cơ sở dữ liệu quan hệ. Trong lược đồ XML, chúng ta định

nghĩa một tài liệu XML, những phần tử của nó, những kiểu dữ liệu của phần

tử và những thuộc tính liên quan, và điều quan trọng nhất là mối quan hệ

“cha-con” giữa những phần tử. Chúng ta có thể tạo lược đồ trong nhiều cách

khác nhau. Cách đơn giản nhất là sử dụng Notepad. Sau đây là một ví dụ một

lược đồ XML

<xsd:schema id="Catalog"

targetNamespace="http://tempuri.org/Catalog1.xsd"

xmlns="http://tempuri.org/Catalog1.xsd"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"

attributeFormDefault="qualified"

elementFormDefault="qualified">

<xsd:element name="Catalog"

msdata:IsDataSet="true"



msdata:EnforceConstraints="False">

<xsd:complexType>

<xsd:choice maxOccurs="unbounded">

<xsd:element name="Product">

<xsd:complexType>

<xsd:sequence>

<xsd:element

name="ProductID"

type="xsd:string"

minOccurs="0" />

<xsd:element

name="ProductName"

type="xsd:string"

minOccurs="0" />

<xsd:element

name="ListPrice" type="xsd:string" minOccurs="0" />

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:choice>

</xsd:complexType>

</xsd:element>

</xsd:schema>

2.1.6.2.2. Các kiểu dữ liệu trong lược đồ XML

Khi tập tin XML hoạt động như một cơ sở dữ liệu, và XSL, XPath được sử

dụng để truy vấn trên tập tin XML giống như một số ngôn ngữ truy vấn trong

SQL, thì lúc này chúng ta cần biết được vị trí của từng phần tử trong tập tin

XML được khai báo ở đâu và với kiểu dữ liệu như thế nào. Vì trong bất kỳ cơ

sở dữ liệu quan hệ nào, ví dụ như SQL Server hoặc Oracle, tất cả những cột

đều được định nghĩa kiểu dữ liệu, và vì vậy thật sự cần thiết phải có kiểu dữ

liệu trong lược đồ XML.



Có hai loại kiểu dữ liệu trong lược đồ XML đó là kiểu dữ liệu cơ bản và

kiểu dữ liệu mở rộng. Kiểu dữ liệu cơ bản là kiểu dữ liệu không bắt nguồn từ

kiểu dữ liệu nào ví dụ như kiểu dữ liệu float. Kiểu dữ liệu mở rộng dựa trên

những kiểu dữ liệu khác ví dụ như kiểu integer dựa trên kiểu decimal.

Kiểu dữ liệu cơ bản được định nghĩa cho mục đích của lược đồ XML thì

không nhất thiết phải giống với một số cơ sở dữ liệu khác. Sau đây là danh

sách các kiểu dữ liệu của lược đồ XML.

Kiểu dữ liệu cơ bản Kiểu dữ liệu mở rộng Kiểu ràng buộc

String normalizedString length

Boolean Token minLength

Decimal Language maxLength

Float NMTOKEN pattern

Double NMTOKENS enumeration

dateTime NCName maxInclusive

Time ID maxExclusive

Date IDREF minExclusive

base64Binary negativeInteger

gYearMonth IDREFS minInclusive

gMonthDay ENTITY totalDigits

GMonth Integer

GDay ENTITIES fractionDigits

long

int

short

byte



nonNegativeInteger

unsignedLong

unsignedInt

unsignedShort

unsignedByte

positiveInteger

Bảng 2-1: Danh sách các kiểu dữ liệu của lược đồ XML

2.1.7. XPath

Qua phần trình bày trên, chúng ta biết được cấu trúc và cú pháp của XML

tương đối đơn giản. Bước tiếp theo là tìm hiểu cách nào để xử lý một tài liệu

XML.

Như vậy để xử lý một tài liệu XML, chương trình ứng dụng phải có cách

di chuyển bên trong tài liệu để lấy ra giá trị của các phần tử (Elements) hay

thuộc tính (Attributes). Do đó ngôn ngữ XML Path được ra đời, mà chúng ta

gọi tắt là XPath. XPath đóng một vai trò quan trọng trong việc truy vấn dữ

liệu cho các chương trình ứng dụng vì nó cho phép ta lựa chọn hay sàng lọc ra

những phần tử nào mình muốn để trao đổi hay hiển thị.

Nếu khi làm việc với cơ sở dữ liệu ta dùng các phát biểu SQL như

SELECT .. FROM table_name WHERE ... để trích ra một số mẩu tin từ một

bảng, thì khi làm việc với tập tin XML, XPath cho ta những biểu thức

(expressions) về điều kiện (criteria) giống như mệnh đề WHERE trong SQL.

XPath là một ngôn ngữ dùng để xử lý truy vấn trên tài liệu XML, cũng

giống như SQL là một chuẩn để làm việc với cơ sở dữ liệu. Một biểu thức



XPath có thể chỉ ra vị trí và mẫu nào để kết hợp. Chúng ta có thể áp dụng toán

tử boolean, hàm string, và toán tử số học trong biếu thức XPath để xây dựng

câu truy vấn phức tạp trên tài liệu XML. XPath cũng cung cấp một số hàm về

số như tính tổng, hàm làm tròn (round), v.v….

2.1.8. Nhận xét về XML

XML được xây dựng như là một chuẩn cho việc trình bày và trao đổi dữ

liệu trên web. Tập đoàn W3C3 đã xây dựng chuẩn XML và những công nghệ

liên quan bao gồm XML DOM, XPath, XSL, và XML Schema. Trong đó

XML DOM được sử dụng để tạo, thay đổi, và duyệt qua tài liệu XML. XPath

là ngôn ngữ dùng để truy vấn trên tài liệu XML. XSL dùng để chuyển đổi tài

liệu XML từ dạng này sang dạng khác. XML Schema định nghĩa cấu trúc và

kiểu dữ liệu cho những nút trong một tài liệu XML. Tất cả những công nghệ

này đã tạo nên sức mạnh cho XML. Vì thế, XML ngày nay đang được sử

dụng rất phổ biến và tương lai sẽ là một chuẩn duy nhất được dùng trên web.

2.2. Cách sử dụng một tài liệu XML

Khi chúng ta đã có một tài liệu XML, chúng ta sẽ tự hỏi: sử dụng nó như

thế nào và làm thế nào để truy cập đến một tập tin XML. Sau đây, là một số

kỹ thuật được sử dụng trong mội trường Visual Studio.NET để làm việc với

tập tin XML.

3 World Wide Web Consortium



2.2.1. Đọc và phân tích tài liệu XML

2.2.1.1. Sử dụng lớp XMLTextReader

Lớp XMLTextReader cung cấp một cursor được sử dụng để lấy dữ liệu từ

một tài liệu XML. Chúng ta khai báo như sau:

XmlTextReader myRdr =

new XmlTextReader(Server.MapPath("catalog2.xml"));

Khi một thể hiện được tạo ra, con trỏ cursor sẽ được đặt ở đầu tài liệu.

Chúng ta có thể sử dụng phương thức Read() để lấy những phần dữ liệu một

cách tuần tự. Mỗi phần dữ liệu tương tự như một nút trong cây XML. Thuộc

tính NodeType sẽ lấy kiểu của phần dữ liệu, thuộc tính Name sẽ lấy tên của

nút, và Value sẽ lấy giá trị của nút. Vì thế, khi một phần dữ liệu được đọc,

chúng ta có thể sử dụng câu lệnh sau để hiện thị tên, giá trị và kiểu của nút.

Response.Write(myRdr.NodeType.ToString()

+" " + myRdr.Name + ":" + myRdr.Value);

Nếu muốn kiểm tra nút đó có thuộc tính hay không, chúng ta có thể sử

dụng phương thức HasAttributes. Nếu giá trị trả về của phương thức

HasAttributes là true, chúng ta áp dụng phương thức MoveToAttribute(i) để

lặp qua các thuộc tính của nút.

if (myRdr.HasAttributes)

{

for( int i = 0; i< myRdr.AttributeCount-1;i++)

{

myRdr.MoveToAttribute(i);

Response.Write(myRdr.NodeType.ToString()+":"+



myRdr.Name + ": " + myRdr.Value + "</br>");

}

myRdr.MoveToElement();

}

2.2.1.2. Sử dụng mô hình DOM

Bên cạnh XMLTextReader thì mô trường Visual Studio.NET cũng hỗ trợ

mô hình DOM (Document Object Module) để đọc và trình bày nội dung của

một tập tin XML. Việc sử dụng mô hình DOM sẽ thông qua một số đối tượng

như XMLDocument, XMLDataDocument. Khi một XMLDocument được

tạo ra, nó tổ chức nội dung của một tập tin XML thành một cây. Trong khi đối

tượng XMLTextReader cung cấp một cursor định vị theo một hướng, thì

XMLDocument cung cấp việc truy xuất nhanh và trực tiếp đến một nút. Tuy

nhiên, việc sử dụng mô hình DOM rất tốn bộ nhớ để lưu trữ thành một cây, và

thật sự sẽ khó khăn khi tài liệu XML có kích thước lớn.

Có nhiều cách khác nhau để tạo một đối tượng XMLDocument. Sau đây

chúng ta sử dụng đối tượng XMLTextReader để tạo một XMLDocument.

private void Page_Load(object sender, System.EventArgs e)

{

if(!Page.IsPostBack)

{

XmlDocument myDoc = new XmlDocument();

XmlTextReader myRdr = new

XmlTextReader(Server.MapPath("Catalog2.xml"));

myDoc.Load(myRdr);

Session("sessionDoc") = myDoc;

//khi cây được tạo ra, chúng ta có thể hiển thị lênlistbox

//với thuộc tính InnerText của những node ProductName

int i=0;

for(i=0;i<myDoc.DocumentElement.ChildNodes.Count-1;i++)



{

lstProducts.Items.Add

(myDoc.DocumentElement.

ChildNodes[i].ChildNodes[i].InnerText);

}

myRdr.Close();

}

}

2.2.2. Định hướng qua tài liệu XML để rút trích dữ liệu:

2.2.2.1. Sử dụng lớp XMLTextReader

Trong phần trên, chúng ta đã biết cách để đọc vào một tài liệu XML, phần

này chúng ta sẽ định hướng qua tài liệu XML và chỉ lấy những dữ liệu nào

cần thiết cho ứng dụng của mình. Ví dụ như nếu nút đó là ProductName

chúng ta sẽ đọc và hiển thị thông tin trên một listbox, cụ thể như sau:

while (myRdr.Read())

{

if(XmlNoteType.Element)

{

if (myRdr.Name="ProductName")

{

myRdr.Read();

lstProducts.Items.Add(myRdr.ReadString);

}

}

}

myRdr.Close();



2.2.2.2. Sử dụng mô hình DOM

Một cây được tạo thành từ nhiều nút. Và một nút cũng là một cây chứa

những nút khác. Nút lá thì không có nút con, vì thế nút này dùng để hiển thị

dữ liệu văn bản.

Lớp XmlDataDocument kế thừa từ lớp XmlDocument, vì thế nó cũng có

một số phương thức như lớp XmlDocument. Điều thú vị nhất của

XmlDataDocument là nó cung cấp hai cách nhìn trên cùng một dữ liệu đó là

XML view và relational view.

XmlDataDocument có một thuộc tính tên là DataSet, thông qua DataSet,

XmlDataDocument trình bày dữ liệu như một hoặc nhiều bảng (DataTable)

có quan hệ hoặc không có quan hệ. Khi chúng ta sử dụng phương thức Load()

để tải một đối tượng XmlDataDocument, chúng ta có thể xem nó như một

cây hoặc như một bảng (hoặc nhiều bảng). Sau đây là hình minh hoạ cho hai

cách nhìn về một tài liệu XML khi sử dụng XmlDataDocument.

Hình 2-1: Mô hình DOM



2.2.3. Truy vấn dữ liệu XML sử dụng XPathDocument và XPathNavigator

Việc sử dụng lớp XmlDocument và XmlDataDocument để xử lý tài liệu

XML cũng có một vài hạn chế. Đầu tiên, toàn bộ tài liệu phải được lưu trong

cache. Thêm vào đó, việc định hướng thông qua một cây sẽ gặp nhiều khó

khăn, và định hướng thông qua những view quan hệ cũng không thuận tiện.

Để khắc phục vấn đề này, VS.NET cung cấp lớp XPathDocument và

XPathNavigator.

Lớp XPathDocument cho phép chúng ta xử lý dữ liệu XML mà không

phải tải lên toàn bộ cây. Và XPathNavigator sử dụng để thao tác trên dữ liệu

của XPathDocument. Nó cũng được sử dụng để thao tác trên XmlDocument,

và XmlDataDocument. Nó hỗ trợ kỹ thuật định hướng cho việc chọn nút, lặp

qua các nút đã chọn, và làm việc trên những nút đã chọn này. Để thực hiện

được việc này, nó sử dụng biểu thức XPath.

XPath chỉ ra cú pháp truy vấn cho việc rút trích dữ liệu từ một tài liệu

XML. Ý tưởng sử dụng tương tự như trong SQL, tuy nhiên cú pháp của nó thì

khác biệt. Nói chung, cú pháp truy vấn XPath có vẻ phức tạp. Tuy nhiên qua

các ví dụ sau, Chúng ta có thể thấy được sự ngắn gọn và hiệu quả trong việc

rút trích dữ liệu XML. Chi tiết về cú pháp của XPath sẽ không đi sâu trong

bài viết này vì nó nghiên về lĩnh vực khác. Tuy nhiên, chúng ta cũng minh

họa vài cách sử dụng biểu thức XPath. Sau đây chúng ta xem qua ví dụ một

tài liệu XML mà sẽ được sử dụng để thực hiện truy vấn trên đó. Tài liệu này

đặt tên là bank1.xml.

<?xml version="1.0" encoding="utf-8" ?>

<Bank>

<Account>



<AccountNo>A1112</AccountNo>

<Name>Pepsi Beagle</Name>

<Balance>1200.89</Balance>

<State>OH</State>

</Account>

…………

…………

<Account>

<AccountNo>A7833</AccountNo>

<Name>Frank Horton</Name>


<State>MI</State>

</Account>

</Bank>

Ví dụ 1: Giả sử chúng ta muốn truy vấn tất cả tên của tài khoản. Biểu

thức XPath như sau:

Dạng 1: descendant::Name

Dạng 2: Bank/Account/Name

Ý nghĩa của biếu thức dạng 1 là “ Hãy lấy những nút con của tất cả những

nút có tên là Name”, còn dạng 2 được diễn đạt như sau “Lấy những nút Name

của nút Account của nút Bank”. Cả hai biểu thức này đều trả về cùng một tập

hợp nút như nhau.

Ví dụ 2: Chúng ta muốn lấy tất cả khách hàng từ Ohio (OH). Biểu thức

được viết như sau:

Dạng 1: descendant::Account[child::State=‘OH’]

Dạng 2: Bank/Account[child::State=‘OH’]

Ví dụ 3: Lấy tất cả Account có Balance>5000.00

Dạng 1: descendant::Account[child::Balance> 5000]

Dạng 2: Bank/Account[child::Balance > 5000.00]



Ví dụ 4: Giả sử Chúng ta muốn lấy thông tin của những Account mà có

tên bắt đầu bằng ký tự ‘D’

Dạng 1: descendant::account[starts-with(child::Name,‘D’)]

Dạng 2: Bank/Account[starts-with(child::Name,‘D’)]

Như vậy, sử dụng dạng nào là thích hợp. Điều đó phụ thuộc vào cảm giác

của từng người và trên cấu trúc của tài liệu XML. Dạng 2 trông dễ sử dụng

hơn dạng 1. Tuy nhiên, trong những tài liệu XML lồng quá sâu, thì dạng 1 sẽ

đưa ra một biểu thức hiệu quả hơn.

Trên đây, chúng ta đã biết khái niệm về cách sử dụng biểu thức XPath như

thế nào, kế tiếp chúng ta sẽ đi vào sử dụng XPathDocument. Trong ngữ cảnh

này, chúng ta sẽ đưa ra 2 ví dụ. Ví dụ đầu tiên sẽ lấy tất cả tên của khách hàng

từ Ohio và hiển thị lên listbox. Ví dụ thứ hai sẽ minh hoạ cách tìm kiếm dữ

liệu thông qua XPathDocument.

2.2.3.2. Cách sử dụng XPathDocument và XPathNavigator

Đầu tiên, chúng ta load tài liệu XML sử dụng XPathDocument như sau:

XPathDocument doc = new

XPathDocument(Server.MapPath("Bank2.xml"));

Chúng ta cần hai đối tượng: XPathNavigator để rút trích ra tập hợp nút mà

chúng ta muốn lấy, và XPathNodeIterator để lặp thông qua tập hợp nút vừa

lấy được. Khai báo như sau:

XPathNavigator myNav = new XPathNavigator();

myNav = myDoc.CreateNavigator();

XPathNodeIterator myIter = new XPathNodeIterator();

myIter=myNav.Select("Bank/Account[child::State='OH']/Name");

Biểu thức “Bank/Account[child::State=‘OH’]/Name” trả về những node

tên Name từ tập nút Account có State=”OH”. Để lấy giá trị bên trong nút



Name, chúng ta sử dụng Current.Value của đối tượng Iterator. Cụ thể như

sau:

while (myIter.MoveNext())

{

lstName.Items.Add(myIter.Current.Value);

}

2.2.3.3. Cách sử dụng XPathDocument và XPathNavigator cho

việc định hướng tài liệu

Phần này minh họa cách tìm kiếm một XPathDocument sử dụng giá trị

của một thuộc tính và giá trị của một phần tử (element). Sử dụng tài liệu XML

bank2.xml sau:

<Bank>

<Account AccountNo="A1112">

<Name>Pepsi Beagle</Name>


<State>OH</State>

</Account>

…………….

…………….

</Bank>

Để tìm kiếm giá trị cụ thể của một thuộc tính, chúng ta sử dụng biểu thức

như sau

Bank/Account[@AccountNo='"+accNo+"']/Balance

Để tìm kiếm giá trị cụ thể của một phần tử, chúng ta sử dụng biểu thức

như sau:

descendant::Account[child::Name='"+accName+"']/Balance



Chúng ta cần gọi phương thức MoveNext() của đối tượng Iterator để lấy

nút Balance. Biểu thức như sau:

Bank/Account[@AccountNo='"+accNo+"']/Balance

Sau đây là một đoạn chương trình hoàn chỉnh viết bằng ngôn ngữ

ASP.NET sử dụng C#

<%@ Import Namespace="System.Xml.Xsl"%>

<%@ Import Namespace="System.Xml.XPath"%>

<%@ Import Namespace="System.Xml"%>

<%@ Page Language="C#" Debug="True"%>

<HTML>

<HEAD>

</HEAD>

<body>

<form runat="server" ID="Form1">

<h4>Balance Inquiry Screen</h4>

Select an Account Number:

<asp:DropdownList id="cboAcno"

runat="server" width="100"/>

Balance from Account Number Search:

<asp:Textbox id="txtBalance1"


<hr>

Select an Customer Name:www.syngress.com

<asp:DropdownList id="cboName"


Balance from Customer Name Search :

<asp:Textbox id="txtBalance2"


<asp:Button id="cmdDetails" Text="Show

Balances" runat="server" onClick="showNames"/>

</form>

<Script Language="c#" runat="server">



private void Page_Load(object sender, System.EventArgs e)

{

if(!Page.IsPostBack)

{

XPathDocument myDoc = new





myIter=myNav.Select("Bank/Account[child::State='OH']/Name");

//Điền giá trị Account Number vào DropDownList

myIter=myNav.Select("//@*"); //Lấy tất cả các thuộc tính


{

cboAcno.Items.Add(myIter.Current.Value);

}

//Điền giá trị Name vào DropDownList myIter=myNav.Select("/Bank/Account/Name");


{

cboName.Items.Add(myIter.Current.Value);

}

}

}

private showsNames(object sender, System.EventArgs e)

{

//Lấy giá trị của item được chọn

string accNo = cboAcno.SelectedItem.Text.Trim();

XPathDocument myDoc = new





//Truy vấn để lấy nút Balance từ AccounNo

myIter = myNav.Select("Bank/Account[@AccountNo='"+



accNo+"']/Balance");

myIter.MoveNext();

//Hiển thị giá trị của nút Balance

txtBalance1.Text=FormatCurrency(myIter.Current.Value);

myIter = myNav.Select("descendant::Account[child::Name='"+

accName+"']/Balance");

myIter.MoveNext();

//Hiển thị giá trị của nút Balance

txtBalance2.Text=FormatCurrency(myIter.Current.Value)

}

</Script>

</body>

</HTML>

2.2.4. Nhận xét

Như vây chúng ta đã biết được XML là như thế nào và cách sử dụng nó ra

sao. Và bây giờ câu hỏi đặt ra là tại sao không tổ chức dữ liệu chỉ trên tập tin

XML thôi mà lại dùng tập tin XML như là một cách lưu trữ hỗ trợ thêm cho

việc lưu trữ trên SQL Server. Để trả lời câu hỏi này, chúng ta xem qua sự so

sánh sau đây.

2.3. XML và Cơ sở dữ liệu

2.3.1. XML có phải là Cơ sở dữ liệu?

Việc XML có phải là cơ sở dữ liệu hay không thật khó giải đáp. Vì XML

cũng giống như mọi ngôn ngữ khác đó là nó cũng có ưu điểm và khuyết điểm.

Ưu điểm của XML như chúng ta đã biết ở trên nhưng khuyết điểm của XML

ở đây là XML dài dòng và truy xuất chậm. Việc truy xuất chậm là do việc lưu



trữ tài liệu XML trong bộ nhớ để phục vụ cho vấn đề truy vấn như chúng ta

đã đề cập trong mô hình DOM. Vì vậy, sau đây chúng ta sẽ quan tâm đến một

khía cạnh khác của XML. Đó là XML có gần gũi như một Cơ sở dữ liệu

(CSDL) hay không? Câu trả lời là “chỉ một phần nào”. Vì XML cũng có một

số điểm giống như CSDL. Đó là nó cũng có khả năng lưu trữ, có hỗ trợ một

số lược đồ như DTD, hay Schema (tương tự như bảng trong CSDL quan hệ).

Và trên XML ta cũng có thể thực hiện thao tác truy vấn bằng cách sử dụng

XPath, XQuery, XQL,…, và XML cũng có hỗ trợ lập trình trên giao diện.

Nhưng một số vấn đề mà XML chưa hỗ trợ như một CSDL. Đó là không có

chỉ mục, vấn đề bảo mật không cao, tính toàn vẹn dữ liệu chưa đáp ứng,

không hỗ trợ các trigger, việc truy cập đa người dùng cũng hạn chế, và cuối

cùng là không cho truy vấn thông qua nhiều tài liệu,v.v... Như vậy, việc lưu

trữ dữ liệu XML như một cơ sở dữ liệu cũng không khả thi.

2.3.2. Vai trò XML trong hệ thống hỗ trợ dịch vụ khách hàng

Trước khi đi vào phần này, chúng ta sẽ khảo sát một sự so sánh sau đây

2.3.2.1. Đánh giá các kiểu cơ sở dữ liệu lưu trữ dữ liệu XML

2.3.2.1.1. Sử dụng hệ thống tập tin (file)

Khi lưu trữ XML bằng tập tin (file) thì việc liên kết các thành phần của

cấu trúc cây sẽ không được hỗ trợ nên việc lưu trữ những liên kết về cấu trúc

và ngữ nghĩa của nó rất phức tạp. Và trên tập tin không thể thực thi được

những yêu cầu rút trích dữ liệu phức tạp nên sử dụng hệ thống tập tin sẽ

không hiệu quả.



2.3.2.1.2. Sử dụng CSDL quan hệ

Như chúng ta đã biết, CSDL quan hệ xây dựng dựa trên cấu trúc bảng nên

không phù hợp cho cấu trúc phân cấp và kết nối tự nhiên trong nội dung của

XML. Nếu chúng ta cố gắng lưu trữ trong CSDL quan hệ cho phù hợp bằng

các bảng dữ liệu và các mối quan hệ thì sẽ phá vỡ cấu trúc đối tượng và ngữ

nghĩa của XML, phải chịu sự trùng lắp trong thiết kế dữ liệu,…Và vấn đề tiếp

theo là sẽ nặng nề trong việc xử lý nhúng và đáp ứng các yêu cầu phức tạp mà

cấu trúc XML đưa ra. Như vậy, CSDL quan hệ là lựa chọn thông minh trong

nhiều ứng dụng khác, nhưng nó không phù hợp và không hiệu quả cho việc

lưu trữ dữ liệu phân cấp của XML.

2.3.3. Mô hình lưu trữ trong hệ thống quản lý dịch vụ khách hàng (eSupport)

Do đã giới thiệu về những ưu điểm và khuyết điểm khi lưu trữ trên tập tin

XML hay trên CSDL quan hệ, nên nhóm chúng em quyết định tích hợp cả hai

mô hình trên trong hệ thống eSupport, nghĩa là kết hợp việc lưu trữ dưới dạng

tập tin XML và CSDL quan hệ. Việc sử dụng cách này với mục đích:

Tận dụng được ưu điểm và khắc phục những yếu điểm của hai cách lưu

trữ trên.

Thích hợp cho việc tìm kiếm trong hệ thống eSupport.

Có thể tận dụng được sự hỗ trợ tối đa trên ngôn ngữ lập trình ASP.NET.



Chương 3: MÔ TẢ HỆ THỐNG QUẢN LÝ DỊCH VỤ KHÁCH HÀNG

3.1. Đối tượng sử dụng Việc trao đổi thông tin diễn ra giữa khách hàng và doanh nghiệp liên quan

đến sản phẩm và dịch vụ của doanh nghiệp. Khi khách hàng có yêu cầu hay

thắc mắc về sản phẩm và dịch vụ của doanh nghiệp, khách hàng có thể gửi

yêu cầu về doanh nghiệp để được giải đáp. Trong doanh nghiệp, sẽ có một bộ

phận nhân viên chuyên trách việc giải đáp các yêu cầu cho khách hàng. Do có

nhiều sản phẩm và dịch vụ khác nhau nên bộ phận nhân viên của công ty cũng

được chia ra theo từng lĩnh vực cần giải đáp.

Trên cơ sở đó, một hệ thống hỗ trợ dịch vụ khách hàng được xây dựng

nhằm phục vụ cho việc trao đổi giữa các nhân viên (doanh nghiệp) và khách

hàng được dễ dàng và nhanh chóng. Đối tượng sử dụng chính của hệ thống là

khách hàng, nhân viên của doanh nghiệp, và quản trị hệ thống.

3.2. Mô tả hệ thống quản lý dịch vụ khách hàng Hệ thống bao gồm hai phân hệ chính là phân hệ hỗ trợ khách hàng và phân

hệ hỗ trợ hệ thống.

3.2.1. Phân hệ hỗ trợ khách hàng

Khi khách hàng có nhu cầu tìm kiếm thông tin, giải đáp thắc mắc về doanh

nghiệp, khách hàng có thể vào khu vực dịch vụ khách hàng để tìm kiếm và

xem nội dung các câu hỏi - trả lời có sẵn trong hệ thống FAQ. Hệ thống FAQ

là phần quản trị các câu hỏi và câu trả lời có sẵn, các câu hỏi này tập hợp các



câu hỏi thường gặp được tập trung lại để phục vụ khách hàng. Hệ thống FAQ

được chia theo chủ đề bất kỳ và có thể cho khách hàng tìm kiếm theo từ khoá.

Trường hợp khách hàng cần biết các thông tin nhưng không có sẵn trong

hệ thống, khách hàng sẽ đăng ký một tài khoản khách hàng (chỉ một lần) và

mở một hay nhiều yêu cầu cho một hay nhiều vấn đề tại một hay nhiều thời

điểm khác nhau. Hay khách hàng không cần vào website, khách hàng chỉ cần

gửi email tới [email protected], hệ thống sẽ tự động tạo một tài khoản

(account) và tạo một yêu cầu hỗ trợ trên hệ thống, đồng thời hệ thống sẽ gửi

thông tin tài khoản mới cho khách hàng bằng email. Hệ thống cũng sẽ gửi

một email để thông báo có yêu cầu hỗ trợ này cho nhân viên doanh nghiệp.

Khách hàng có thể theo dõi tiến trình xử lý yêu cầu của nhân viên doanh

nghiệp qua email (khi yêu cầu đang được nhân viên xem xét thì khách hàng

nhận được email, thông báo về quá trình giải quyết yêu cầu của doanh

nghiệp).

Khách hàng cũng nhận được các thông báo về sản phẩm mới, dịch vụ,

khuyến mãi do doanh nghiệp đưa ra.

3.2.2. Phân hệ hỗ trợ hệ thống

Trong phân hệ này được chia làm hai đối tượng sử dụng chính là: quản trị

và nhân viên.

3.2.2.1. Đối tượng nhân viên (staff)

Mỗi nhân viên sẽ được phân công phụ trách giải đáp yêu cầu của một hay

nhiều phòng ban. Khi nhân viên đăng nhập vào tài khoản của mình thì tất cả

các yêu cầu của phòng ban mà nhân viên đó trực thuộc sẽ được hiển thị cho



nhân viên đó xem xét. Nhân viên sẽ xem xét và trả lời các yêu cầu của khách

hàng trong thời gian nhanh nhất có thể. Khi yêu cầu được giải quyết xong thì

trạng thái của nó sẽ được thay đổi, nếu như khách hàng có đăng ký nhận trả

lời qua email thì nội dung câu trả lời sẽ được gởi đến cho người sử dụng qua

email của họ.

Trong trường hợp phòng ban nhận yêu cầu không trả lời được thì nhân

viên quản trị sẽ chuyển qua phòng ban phù hợp để xử lý.

Nhân viên có thể lựa chọn trong các yêu cầu khách hàng gửi lên, yêu

cầu nào mới (chưa có trong hệ thống câu hỏi-trả lời), thường xuyên cần được

giải đáp thì nhân viên sẽ cập nhật vào hệ thống FAQ.

3.2.2.2. Đối tượng quản trị viên (admin)

Quản trị viên có chức năng quản trị chung hệ thống, quản lý cấu hình hệ

thống, đảm bảo cho hệ thống hoạt động tốt.

Quản trị viên quản lý người dùng trong hệ thống bao gồm các thao tác

thêm, xóa, sửa tài khoản người dùng và nhân viên. Thực hiện phân quyền cho

các nhân viên.

Quản trị viên cũng theo dõi các yêu cầu và trả lời, chọn lựa yêu cầu nào

mới, thường được khách hàng quan tâm để cập nhật FAQ.

Quản trị viên quản lý, theo dõi chặt chẽ quá trình xử lý yêu cầu của các

nhân viên, đảm bảo khách hàng không phải chờ đợi lâu. Nếu có yêu cầu nào

bị giải quyết chậm trễ ngưng trệ thì quản trị phải nhắc nhở bằng email tới các

nhân viên và các phòng ban.



3.3. Xác định yêu cầu chức năng hệ thống

3.3.1. Yêu cầu chức năng nghiệp vụ

3.3.1.1. Nhóm chức năng dành cho người dùng chung

Tìm kiếm FAQ

Khi truy cập vào hệ thống, bất kì người dùng nào cũng có thể tìm kiếm các

câu hỏi-trả lời có sẵn trong FAQ. Người dùng có thể tìm kiếm câu hỏi-trả lời

theo chủ đề của câu hỏi hoặc theo từ khóa. Mô hình quy trình nghiệp vụ như

sau:

Nhap tu khoa

[co]

Co yeu cau tim kiem FAQ

Tim kiem theo tu khoa

Tim kiem trong CSDL

Tiep tuc?Hien thi ket qua tim kiem

[Khong tim thay][Tim thay]

[Ket thuc]

[khong]

Tim kiem trong he thong chu de

[Bat dau]

Chon FAQ de xem xet

[khong tim thay][tim thay]



Xem thông báo

Người dùng có thể xem một số thông báo của hệ thống hoặc của doanh

nghiệp liên quan đến hệ thống, khách hàng, công ty…trực tiếp trên trang web

của doanh nghiệp. Hoặc khách hàng có thể đăng ký để nhận thông báo qua

email, nếu không muốn nhận nữa, khách hàng có thể hủy đăng ký qua link

trong email, hoặc trên trang web.

3.3.1.2. Nhóm chức năng dành cho khách hàng (Customer)

Đăng ký tài khoản người dùng

Khi khách hàng muốn tạo yêu cầu hoặc tải các tài liệu, hồ sơ liên quan đến

doanh nghiệp, khách hàng phải đăng ký một tài khoản trên hệ thống, tài khoản

này có thể được kích hoạt ngay lúc đó hoặc phải được quản trị viên (admin)

cho phép mới được sử dụng tùy theo yêu cầu của doanh nghiệp. Quy trình

nghiệp vụ này được mô tả như sau:



Nhu cau tao tai khoan moi

Yeu cau thong tin tao tai khoan

Nhap thong tin tao tai khoan

Dang ki tai khoan moi

Huy bo giao tac

[Dang ky] [Huy bo]

Kiem tra ten dang nhap

Kiem tra dia chi email

[khong trung ten dang nhap]

[trung ten dang nhap]

Thong bao dang ky thanh cong

[khong trung dia chi email]

[trung dia chi email]

Gui email xac nhan thong tin dang ky

[Bat dau]

[ket thuc]



Tạo yêu cầu mới qua website của doanh nghiệp

Khách hàng có thể mở yêu cầu mới trên hệ thống về vấn đề mình muốn

được giải đáp, sau khi tạo xong yêu cầu, khách hàng có thể chờ đợi để được

trả lời liền hoặc theo dõi tiến trình xử lý yêu cầu của doanh nghiệp qua email.

Khi một nhân viên nào đó mở yêu cầu để xem xét, lập tức có một email tự

động gửi cho khách hàng thông báo về việc yêu cầu của họ đang được xem

xét. Sau khi yêu cầu được trả lời xong, toàn bộ nội dung trả lời sẽ được gửi

qua email cho khách hàng, kèm thêm đường dẫn đến câu trả lời đó đặt trên

website của doanh nghiệp. Mô tả quy trình nghiệp vụ này như sau:

Co yeu cau can giai dap

Tiep nhan "yeu cau"

Nhap thong tin "yeu cau" moi

Huy bo giao tacGui yeu cau

[OK] [Cancel]

Tiep nhan yeu cau moi

Gui email thong bao yeu cau moi cho nhan vien

[Bat dau]

[Ket thuc]



Tạo yêu cầu mới qua email

Khách hàng không cần vào website của doanh nghiệp mà chỉ cần gửi

email đến địa chỉ [email protected] về yêu cầu mới cần được giải đáp, hệ

thống nhận được email sẽ kiểm tra xem, ứng với địa chỉ email đó là tài khoản

người dùng nào trên hệ thống, nếu không có, hệ thống tự tạo một tài khoản

người dùng mới với tên tài khoản là tên của email, mật khẩu được hệ thống

cấp tự động và gửi cho khách hàng. Sau khi nhận được mail chứa nội dung

yêu cầu, hệ thống sẽ phân tích lá mail đó và gửi về phòng ban thích hợp.

Xem và hiệu chỉnh các yêu cầu

Khách hàng có thể vào trang web của doanh nghiệp để xem các yêu cầu đã

mở trước đó, có thể sửa đổi yêu cầu hoặc thay đổi trạng thái của yêu cầu trên

hệ thống (đóng yêu cầu lại nếu đã được giải đáp thỏa đáng, mở lại yêu cầu đã

bị đóng nếu chưa thỏa mãn). Nếu chưa hài lòng với câu trả lời, khách hàng

cũng có thể tiếp tục gửi thắc mắc lên hệ thống trong yêu cầu đã mở. Mô hình

quy trình nghiệp vụ:



Hien thi noi dung "yeu cau"

Nhu cau xem "yeu cau"

Nhu cau chinh sua "yeu cau"

Nhap thong tin hieu chinh

Cap nhat thong tin moi

Tra loi yeu cau

Nhap noi dung tra loi yeu cau

Cap nhat thong tin tra loi yeu cau moi

Hien thi thong tin "yeu cau"

[Bat dau]

[Ket thuc]

Tải tài liệu về

Khi muốn download tài liệu, văn bản hướng dẫn, khách hàng vào khu vực

download để tìm kiếm tài liệu và tải về. Lưu ý là chỉ khi nào đã đăng nhập

khách hàng mới có thể tải tài liệu về (khách hàng vẫn có thể xem tài liệu lúc

chưa đăng nhập). Quy trình nghiệp vụ mô tả như sau:



[Bat dau]

Nhu cau tim kiem tai lieu download

Tim trong he thong cac chu de

Tim theo tu khoa

Nhap tu khoa

Tim kiem trong CSDL

Hien thi ket qua tim kiem

Tiep tuc?

[tim thay] [khong tim thay]

[co]

[khong]

Download tai lieu can tim

[tim thay] [khong tim thay]

[ket thuc]

Hiệu chỉnh thông tin cá nhân

Sau khi đăng nhập thành công, nhân viên có thể sửa đổi thông tin cá nhân

của mình như mật khẩu, email, địa chỉ, số điện thoại, …

Nhắc mật khẩu

Nếu khách hàng quên mật khẩu đăng nhập thì khách hàng sử dụng chức

năng nhắc mật khẩu của hệ thống để lấy lại mật khẩu của mình.



3.3.1.3. Nhóm chức năng dành cho nhân viên (staff)

Mọi tài khoản của nhân viên đều được quản trị viên tạo ra (nhân viên

không có quyền tạo tài khoản của mình) và được cấp quyền thích hợp trong

hệ thống theo chức năng của các phòng ban, một nhân viên có thể thuộc về

một phòng ban hoặc nhiều phòng ban khác nhau.

Giải quyết các vấn đề

Nhân viên sau khi đăng nhập vào tài khoản của mình thì có thể xem xét và

trả lời các yêu cầu mới thuộc về lĩnh vực mà phòng ban của nhân viên đó

quản lý. Sau khi trả lời xong trạng thái của yêu cầu đó sẽ là đánh dấu là đang

giải quyết (chưa đóng), nếu nhân viên thấy yêu cầu đã được giải quyết xong,

nhân viên đó có thể đóng yêu cầu đó lại. Nhân viên cũng có thể chuyển các

yêu cầu đến các phòng ban phù hợp để xử lý.



Chon yeu cau can giai quyet

Hien thi thong tin yeu cau

Xem xet noi dung yeu cau

Tra loi yeu cau

[Giai quyet duoc]

Xem xet chuyen phong ban

[Khong giai quyet duoc]

Lua chon phong ban chuyen toi

[Chuyen phong ban]

Yeu cau van chua duoc giai quyet

Gui mail thong bao yeu cau dang duoc xem xet

Chuyen phong ban

Cap nhat noi dung tra loi len he thong

Gui mail tra loi cho khach hang

Dong yeu cau

Thay doi trang thai cua yeu cau

[OK]

[khong chuyen phong ban]

[Bat dau]

[Ket thuc]

[khong dong]

Tìm kiếm yêu cầu

Nhân viên có thể tìm kíếm các yêu cầu trong hệ thống theo chủ đề, theo

người gửi, theo ngày tháng,...

Quản trị khu vực download

Nhân viên sử dụng chức năng này để quản trị các tài liệu cho tải về trên hệ

thống. Nhân viên có thể thêm, xoá, chỉnh sửa các tài liệu.



Cập nhật FAQ

Chỉ một số nhân viên có quyền (được admin gán quyền) có thể sử dụng

được chức năng cập nhật FAQ, nhân viên này sẽ xem xét lại các yêu cầu của

khách hàng xem yêu cầu nào thường xuyên được hỏi, các câu hỏi quan trọng

thiết yếu thì nhân viên đó sẽ hiệu chỉnh rồi cập nhật vào FAQ.

3.3.1.4. Nhóm chức năng dành cho quản trị (admin)

Quản trị hệ thống

Quản trị viên có chức năng thay đổi các thông số cấu hình của hệ thống,

thay đổi cấu hình của email gửi cho khách hàng.

Quản trị người dùng

Quản trị viên có thể thêm, xóa, sửa tài khoản của khách hàng, của nhân

viên và của các quản trị viên khác.

Quản trị các phòng ban

Quản trị viên có thể thêm, xóa, sửa các thông tin về phòng ban trong

doanh nghiệp. Các phòng ban được phân chia tùy theo từng doanh nghiệp.

Quản trị FAQ

Quản trị viên có chức năng phân chia chủ đề cho FAQ, hiệu chỉnh thêm,

xóa, sửa các chủ đề. Quản trị viên chọn lọc từ các câu hỏi-trả lời của khách

hàng trong phân hệ hỗ trợ khách hàng đề thêm vào FAQ. Quản trị viên cũng

có chức năng xóa, hiệu chỉnh FAQ nếu cần thiết.



Quản trị thông báo

Quản trị viên có chức năng thêm, xoá, sửa các thông báo trên hệ thống

(các thông báo này có phân quyền người xem).

Quản trị khu vực tải tài liệu về

Quản trị viên có chức năng thêm, xoá, sửa các tài liệu tải về trên hệ thống.

Tìm kiếm người dùng hệ thống

Quản trị viên cũng có thể tìm kiếm người dùng hệ thống bằng chức năng

tìm kiếm này, quản trị viên có thể tìm kiếm theo tên đăng nhập hoặc các

thông tin liên quan khách hàng. Sau khi tìm kiếm, quản trị viên được phép

xem các thông tin và gửi email cho người dùng đó.


Quản trị viên có thể tìm kíếm các yêu cầu trong hệ thống theo chủ đề, theo

người gửi, theo ngày tháng,...

3.3.2. Yêu cầu chức năng hệ thống

3.3.2.1. Chức năng lưu trữ

Người dùng: Lưu trữ các thông tin tài khoản hệ thống của cả khách

hàng, nhân viên và quản trị. Các thông tin cần lưu trữ bao gồm: Tên

đăng nhập, mật khẩu đăng nhập, địa chỉ email, họ tên, ngày đăng ký,

loại tài khoản, ngày đăng nhập cuối, tổng số bài gửi, …

Yêu cầu (ticket): Lưu trữ thông tin của một yêu cầu của khách hàng gửi

lên hệ thống. Các thông tin cần lưu trữ bao gồm: tiêu đề yêu cầu, nội

dung yêu cầu, ngày mở, ngày đóng, trạng thái, mức độ, tên file đính

kèm, người gửi, phòng ban xử lý, …



Phòng ban: Các thông tin cần lưu trữ như tên phòng ban, chức năng

giải quyết yêu cầu của phòng ban, …

Chủ đề: Các thông tin cần lưu trữ gồm có tên chủ đề, mô tả thông tin

của chủ đề, mã chủ đề cha.

FAQ: Các thông tin cần lưu trữ gồm nội dung câu hỏi, nội dung câu trả

lời, ngày cập nhật, số lần xem.

Tài liệu: Các thông tin cần lưu trữ gồm có mã tài liệu, tên tài liệu,

nộidung tóm tắt, tập tin đính kèm, kích thước, ngày upload, số lần tải.

Thông báo: Các thông tin cần lưu trữ gồm có tiêu đề, nội dung, ngày

thông báo, ngày hết hạn, người thông báo, số lần xem, quyền truy

cập,…

3.3.2.2. Chức năng tự động

Khi nhận được email yêu cầu của khách hàng, hệ thống phải có chức

năng phân loại yêu cầu này vào các phòng ban thích hợp.

Khi có yêu cầu mới trên hệ thống, hệ thống sẽ tự động gửi email thông

báo về việc có yêu cầu mới cho các nhân viên phụ trách phòng ban đó.

Khi một yêu cầu đã quá hạn bao lâu chưa trả lời (quy định trong quản

trị hệ thống), email sẽ tự động gửi lại cho tất cả các người trong phòng

ban đó với bao nhiêu lần, mỗi lần cách bao nhiều phút.

Khi có thông báo mới, hệ thống sẽ tự động gửi email cho những khách

hàng đã đăng kí nhận thông báo qua email.

3.3.2.3. Chức năng tìm kiếm

Tìm kiếm tài khoản khách hàng, nhân viên.


Tìm kiếm FAQ.

Tìm kiếm tài liệu tải về.



3.3.2.4. Chức năng thống kê

Số lượng yêu cầu mỗi ngày

Số lượng yêu cầu của mỗi phòng ban

Số lượng yêu cầu của mỗi nhân viên

Thống kê helpdesk : tổng số yêu cầu mở, đóng, FAQ, mở yêu cầu qua

email, qua trang web, tổng số khách hàng online.

Thống kê các file download

Tốc độ trả lời trung bình của nhân viên

Tốc độ trả lời trung bình của phòng ban

Nhân viên trả lời nhanh nhất.

3.3.3. Yêu cầu phi chức năng

3.3.3.1. Tính tiến hóa

Cho phép dễ dàng chuyển sang xây dựng các hệ thống khác có chức năng

tương tự

3.3.3.2. Tính tiện dụng

Giao diện người dùng phải được thiết kế sao cho vừa quen thuộc đối với

những ngườI đã từng sử dụng tin học, vừa dễ học cách sử dụng đối với những

người mới sử dụng tin học lần đầu. Đồng thời giao diện phải được thiết kế sao

cho người dùng có thể thao tác một cách nhanh nhất, thông tin hiển thị phải

dễ dàng nắm bắt và đầy đủ.

Khi chương trình thực hiện các yêu cầu chức năng phải đáp ứng những

yêu cầu như: tốc độ tìm kiếm, tốc độ hiển thị, thời gian lưu trữ, thời gian truy

xuất nhanh.



Chương 4: PHÂN TÍCH

4.1. Lược đồ USE-CASE

Từ mô tả hiện trạng và các yêu cầu chức năng hệ thống, ta xây dựng được

lược đồ Use-Case như sau:

Dang ky tai khoan

(from Khach hang)Tao yeu cau

(from Khach hang)

Tai tai lieu ve

(from Khach hang)

Xem va hieu chinh yeu cau

(from Khach hang) Khach hang

(from Actor)

Dang nhap

(from Nguoi su dung)Nguoi su dung

(from Actor)

Quan ly phong ban

(from Quan tri)

Quan ly thong bao

(from Quan tri)

Tim kiem tai khoan

(from Quan tri)

Quan ly tai khoan

(from Quan tri)

<<include>>

Quan tri he thong

(from Quan tri)

Tim kiem FAQ

(from Nguoi su dung)

Quan tri

(from Actor)

Quan ly yeu cau

(from Quan tri)

Giai quyet yeu cau

(from Nhan vien)

Quan ly tai lieu tai ve

(from Quan tri)

Quan ly FAQ

(from Quan tri)

<<include>>

Tim kiem Yeu cau

(from Quan tri)

<<include>>

Nhan vien

(from Actor)

Hình 4-1: Lược đồ Use-Case



Danh sách các Actor

STT Actor Diễn giải

1 Người dùng Người dùng hệ thống (bao gồm khách hàng, nhân viên, quản trị)

2 Khách hàng Khách hàng của doanh nghiệp

3 Nhân viên Nhân viên của doanh nghiệp

4 Quản trị Quản trị viên

Bảng 4-1: Danh sách các Actor

Danh sách các UseCase

STT Use-Case Diễn giải

Người sử dụng

1 Đăng nhập Đăng nhập

2 Tìm kiếm FAQ Tìm kiếm câu hỏi-trả lời có sẳn trong FAQ

Khách hàng

3 Đăng ký tài khoản Tạo tài khoản mới

4 Tạo yêu cầu Tạo yêu cầu mới, gửi lên hệ thống web hoặc qua email

5 Xem và hiệu chỉnh yêu cầu Xem và hiệu chỉnh các yêu cầu đã gửi.

6 Tải tài liệu về Tải về các tài liệu, văn bản

Nhân viên

7 Giải đáp yêu cầu Giải đáp yêu cầu của khách hàng

Quản trị

8 Tìm kiếm tài khoản Tìm kiếm tài khoản người dùng



9 Tìm kiếm yêu cầu Tìm kiếm các yêu cầu đã gửi

10 Quản trị FAQ Thêm xóa sửa FAQ

11 Quản trị tài khoản Thêm xóa sửa tài khoản người dùng

12 Quản trị thông báo Thêm xóa sửa thông báo

13 Quản trị phòng ban Thêm xóa sửa phòng ban

14 Quản trị yêu cầu Xóa sửa yêu cầu

15 Quản trị hệ thống Cấu hình hệ thống

16 Quản trị Download Thêm xóa sửa tài liệu tải về

Bảng 4-2: Danh sách các Use-Case

4.2. Đặc tả Use-Case

Một số chức năng chính của hệ thống được đặc tả ở đây, các chức năng

phụ được đặt ở phần phụ lục A.

4.2.1. Đặc tả Use-Case Tìm kiếm FAQ

4.2.1.1. Tóm tắt

Use-case tìm kiếm FAQ mô tả quá trình tìm kiếm các câu hỏi-trả lời có sẵn

trong cơ sở dữ liệu FAQ dựa trên từ khóa, nếu tìm thấy các câu hỏi-trả lời phù

hợp thì thông tin tìm kiếm sẽ được trả về. Nếu không tìm thấy, hệ thống thông

báo kết quả tìm kiếm và quay lại quá trình tìm kiếm.

4.2.1.2. Dòng sự kiện

Dòng sự kiện chính

Use-case bắt đầu khi có yêu cầu tìm kiếm câu hỏi-trả lời trong FAQ.



1. Người dùng nhập từ khóa để tìm kiếm câu hỏi-trả lời có sẳn trong

FAQ.

2. Hệ thống bắt đầu tìm kiếm trong FAQ các câu hỏi-trả lời theo từ

khóa cung cấp.

3. Nếu tìm thấy, danh sách các câu hỏi-trả lời sẽ được trả về.

Các dòng sự kiện khác

Không tìm thấy câu hỏi-trả lời thỏa điều kiện tìm kiếm

Nếu không tìm thấy, thông báo kết quả tìm kiếm và quay lại dòng sự kiện

chính. Nếu người dùng kết thúc tìm kiếm, Use-case sẽ kết thúc.

4.2.1.3. Đặc tả khác

Các yêu cầu đặc biệt Không có.

Điều kiện tiên quyết Không có.

Post Conditions Hệ thống không thay đổi sau khi Use-case thực hiện xong.

Điểm mở rộng Không có.

4.2.2. Đặc tả Use-Case Đăng ký tài khoản

4.2.2.1. Tóm tắt

Use-case đăng kí tài khoản thực hiện việc tạo một tài khoản mới trên hệ

thống cho khách hàng.





Use-case này bắt đầu khi khách hàng có nhu cầu tạo tài khoản.

1. Hệ thống yêu cầu khách hàng nhập các thông tin liên quan đến tài

khoản: tên tài khoản, mật khẩu, địa chỉ email, ngoài ra có thể cung

cấp thêm một số thông tin khác như tên, tuổi, năm sinh, địa chỉ…

2. Hệ thống kiểm tra xem đã tồn tại tài khoản có tên như thế trong hệ

thống chưa. Nếu không bị trùng tên đăng nhập, hệ thống tiếp tục

kiểm tra xem, địa chỉ email đã đăng kí có trùng với địa chỉ email

nào như thế trong hệ thống chưa. Nếu chưa có , tài khoản được thêm

vào hệ thống.

3. Khách hàng có thể sử dụng tài khoản được ngay để gửi yêu cầu hoặc

phải được sự cho phép của nhân viên quản trị. Hệ thống tự động gửi

email xác nhận tài khoản đã đăng kí cho khách hàng. Use-case kết

thúc


Trùng tên tài khoản

Khi tên tài khoản mà khách hàng cung cấp bị trùng trong hệ thống, khách

hàng sẽ được yêu cầu nhập lại tên tài khoản, các thông tin khác giữ nguyên.

Trùng địa chỉ email

Khi địa chỉ email mà khách hàng cung cấp để đăng kí bị trùng với email đã

có trong hệ thống, khách hàng sẽ được yêu cầu nhập lại địa chỉ email, các

thông tin khác giữ nguyên.





Điều kiện tiên quyết Không có.

Post Conditions Tài khoản mới được tạo ra trên hệ thống nếu Use-case thành công, ngược lại trạng thái hệ thống không thay đổi.


4.2.3. Đặc tả Use-Case Tạo yêu cầu

4.2.3.1. Tóm tắt

Use-case tạo yêu cầu mô tả quá trình khách hàng tạo một yêu cầu hỗ trợ

mới trên hệ thống.


Use-case này bắt đầu khi khách hàng có một yêu cầu hỗ trợ mới cần giải

đáp.

1. Hệ thống yêu cầu khách hàng nhập các thông tin liên quan và nội

dung yêu cầu mới: nội dung yêu cầu, phòng ban liên quan có trách

nhiệm, mức độ khẩn cấp, tài liệu đính kèm nếu có. Nếu khách hàng

chưa đăng nhập thì phải cung cấp thêm thông tin của tên và địa chỉ

email.

2. Sau khi các thông tin của yêu cầu mới được cung cấp, hệ thống tạo

một mã cho yêu cầu mới và lưu yêu cầu mới vào cơ sở dữ liệu. Hệ

thống tự động gửi email thông báo tới các nhân viên việc có một

yêu cầu mới trên hệ thống, nếu mức độ khẩn cấp ở mức cao nhất thì



thông báo được gửi cho tất cả các phòng ban trong hệ thống, còn lại

thông báo chỉ đượcgửi cho các phòng ban có liên quan tới yêu cầu.

3. Hệ thống hiển thị yêu cầu mới cho khách hàng và các nhân viên liên

quan. Use-case kết thúc.



Điều kiện tiên quyết Khách hàng có thể đăng nhập, hoặc thêm thông tin địa chỉ email trước khi tạo yêu cầu mới.

Post Conditions Nếu Use-case thực hiện thành công, một yêu cầu mới được lưu vào cơ sở dữ liệu, và được hiển thị cho khách hàng và các nhân viên có liên quan. Ngược lại nếu Use-case không thành công, trạng thái hệ thống không thay đổi.


4.2.4. Đặc tả Use-Case Xem và hiệu chỉnh yêu cầu

4.2.4.1. Tóm tắt

Use-case Xem và hiệu chỉnh yêu cầu mô tả quá trình khách hàng xem xét

yêu cầu hỗ trợ mới trên hệ thống xem đã được giải quyết hay chưa, đồng thời

khách hàng có thể hiệu chỉnh lại nội dung yêu cầu.


Use-Case này bắt đầu sau khi khách hàng đăng nhập và xem xét các yêu

cầu mà mình đã gửi.




1. Khách hàng lựa chọn yêu cầu để xem.

2. Nội dung câu hỏi-trả lời của yêu cầu được chọn hiển thị lên cho

khách hàng xem xét, khách hàng có thể hiệu chỉnh lại nội dung yêu

cầu hoặc yêu cầu giải thích thêm.

3. Sau khi thao tác xong, khách hàng đóng yêu cầu, hệ thống sẽ yêu

cầu khách hàng cập nhật lại trạng thái của yêu cầu (open, reopen,

close). Nếu khách hàng đã nhận được giải đáp hài lòng, khách hàng

có thể chuyển trạng thái yêu cầu về trạng thái đóng (close), nếu yêu

cầu đã bị đóng (do nhân viên đóng) mà khách hàng chưa hài lòng,

khách hàng có thể mở lại yêu cầu này (reopen).

Dòng sự kiện phụ

Hiệu chỉnh yêu cầu

Nếu khách hàng xem xét thấy nội dung yêu cầu chưa phù hợp, còn thiếu

sót, khách hàng có thể hiệu chỉnh thêm và cập nhật lại nội dung yêu cầu.



Điều kiện tiên quyết Khách hàng phải đăng nhập vào tài khoản của mình mới thấy được các yêu cầu mà mình đã gửi.

Post Conditions Nếu Use-Case thành công trạng thái của hệ thống được thay đổi. Ngược lại, trạng thái của hệ thống không thay đổi.




4.2.5. Đặc tả Use-Case Giải đáp yêu cầu

4.2.5.1. Tóm tắt

Use-case Giải đáp yêu cầu mô tả quá trình giải quyết các yêu cầu của nhân

viên, nhân viên sẽ được hiển thị tất cả các yêu cầu thuộc phòng ban mà nhân

viên đó trực thuộc. Nhân viên xem xét các yêu cầu và trả lời, nếu nhân viên

nhận thấy yêu cầu không được gửi đúng phòng ban, nhân viên xem xét

chuyển yêu cầu qua phòng ban phù hợp.



Use-case bắt đầu khi có yêu cầu mới được gửi lên hệ thống

1. Các yêu cầu của phòng ban nào thì nhân viên thuộc phòng ban đó sẽ

được hiển thị chờ giải quyết. Nếu độ ưu tiên của yêu cầu là rất khẩn

cấp thì bất kì một nhân viên nào cũng được thấy yêu cầu đó. Khi có

một nhân viên xem xét yêu cầu thì hệ thống gửi email thông báo cho

khách hàng biết trạng thái đang được giải đáp của yêu cầu.

2. Nếu giải đáp được yêu cầu thì nhân viên đó nhập nội dung trả lời rồi

đóng yêu cầu đó lại. Toàn bộ nội dung câu trả lời sẽ được gửi qua

email cho khách hàng(nếu khách hàng có đăng ký nhận yêu cầu qua

mail). Use-case kết thúc.


Yêu cầu chưa được giải quyết/Không đúng phòng ban

Nếu đã có nhiều nhân viên xem xét nhưng yêu cầu vẫn chưa được giải

quyết, hoặc yêu cầu gửi không đúng phòng ban, nhân viên có quyền trên hệ



thống sẽ chuyển yêu cầu qua phòng ban khác để xử lý.



Điều kiện tiên quyết Nhân viên phải đăng nhập thì mới được giải quyết các yêu cầu.

Post Conditions Nếu Use-Case thành công, trạng thái của hệ thống thay đổi. Ngược lại, nếu không thành công trạng thái của hệ thống được giữ nguyên.


4.2.6. Đặc tả Use-Case Tìm kiếm yêu cầu

4.2.6.1. Tóm tắt

Use-case Tìm kiếm yêu cầu cho phép các nhân viên và quản trị tìm kiếm

yêu cầu trước đó trên hệ thống dựa trên các thông tin của yêu cầu. Nếu tìm

thấy, các yêu cầu thõa mãn sẽ được trả về. Nếu không tìm thấy, hệ thống

thông báo kết quả tìm kiếm và quay lại quá trình tìm kiếm.



Use-case bắt đầu khi có yêu cầu tìm kiếm yêu cầu.

1. Người dùng nhập các thông tin cần thiết để tìm kiếm yêu cầu: từ

khóa tìm kiếm theo nội dung câu hỏi và trả lời, người nêu yêu cầu,

phòng ban của yêu cầu, ngày gởi yêu cầu, trạng thái hiện tại,... .



2. Hệ thống bắt đầu tìm kiếm trong hệ thống Helpdesk các yêu cầu

thõa mãn thông tin được cung cấp.

3. Nếu tìm thấy, danh sách yêu cầu sẽ được trả về. Nếu không tìm thấy

hệ thống quay lại quá trình tìm kiếm hoặc thoát ra. Use-Case kết

thúc.


Không tìm thấy yêu cầu thõa điều kiện tìm kiếm

Nếu không tìm thấy, thông báo kết quả tìm kiếm và quay lại dòng sự kiện

chính. Nếu người dùng kết thúc tìm kiếm, Use-case sẽ kết thúc.



Điều kiện tiên quyết Nhân viên, quản trị phải đăng nhập mới được tìm kiếm yêu cầu.

Post Conditions Hệ thống không thay đổi sau khi Use-case thực hiện xong.


4.2.7. Đặc tả Use-Case Quản lý yêu cầu

4.2.7.1. Tóm tắt

Use-case quản lý yêu cầu mô tả quá trình quản trị viên/nhân viên quản trị

các yêu cầu của người dùng. Quản trị yêu cầu bao gồm xóa, sửa các yêu cầu.





1. Use-case bắt đầu khi có yêu cầu quản trị yêu cầu trên hệ thống. Hệ

thống yêu cầu quản trị/nhân viên chọn chức năng để thực hiện Hiệu

chỉnh yêu cầu, xóa yêu cầu.

2. Sau khi quản trị viên cung cấp yêu cầu, một trong các luồng phụ sau

được thực hiện:

Nếu quản trị viên chọn “Hiệu chỉnh yêu cầu”, luồng phụ Hiệu chỉnh

yêu cầu được thực hiện.

Nếu quản trị viên chọn “Xóa yêu cầu”, luồng phụ Xóa yêu cầu được

thực hiện.



1. Hệ thống yêu cầu quản trị viên chọn yêu cầu để sửa đổi. Quản trị có

thể dùng Use-Case Tìm kiếm yêu cầu để tìm yêu cầu cần chỉnh sửa.

2. Quản trị viên chỉnh sửa các thông tin liên quan đến phòng ban, rồi

cập nhật lưu lại. Use-case kết thúc.

Xóa yêu cầu

1. Hệ thống yêu cầu quản trị viên chọn yêu cầu cần xóa. Quản trị có

thể dùng Use-Case Tìm kiếm yêu cầu để tìm yêu cầu cần xóa.

2. Hệ thống yêu cầu quản trị xác nhận yêu cầu xóa.

3. Quản trị viên xác nhận xóa, yêu cầu được xóa khỏi hệ thống. Use-

case kết thúc.





Điều kiện tiên quyết Phải đăng nhập quyền quản trị hoặc nhân viên mới được thực hiện Use-Case này.

Post Conditions Nếu Use-Case thành công, yêu cầu được thêm, xóa, chỉnh sửa. Ngược lại hệ thống không thay đổi.


4.2.8. Đặc tả Use-Case Quản lý FAQ

4.2.8.1. Tóm tắt

Use-case quản lý FAQ gồm mô tả chức năng quản trị câu hỏi-trả lời

(FAQ) của hệ thống. Quản trị câu hỏi-trả lời cho phép người quản trị/nhân

viên thêm, xóa, sửa các câu hỏi-trả lời.



Use-case bắt đầu khi quản trị viên muốn thêm, xóa, sửa hệ thống câu hỏi-

trả lời. Hệ thống yêu cầu quản trị chọn chức năng muốn thực hiện:

1. Nếu quản trị viên chọn “Thêm FAQ”, luồng phụ Thêm FAQ được

thực hiện.

2. Nếu quản trị viên chọn “Hiệu chỉnh FAQ”, luồng phụ Hiệu chỉnh

FAQ được thực hiện.

3. Nếu quản trị viên chọn “Xóa FAQ”, luồng phụ Xóa FAQ được thực

hiện.




Thêm FAQ mới

1. Hệ thống yêu cầu quản trị chọn cách thêm câu hỏi-trả lời mới: thêm

mới hoàn toàn hoặc thêm mới dựa trên Ticket đã có sẳn trên hệ

thống.

2. Hệ thống yêu cầu quản trị nhập nội dung câu hỏi và trả lời cho

Question mới.

3. Thêm câu hỏi-trả lời mới vào cơ sở dữ liệu.

Thêm FAQ từ Yêu cầu sẵn có

1. Hệ thống hiển thị các “Yêu cầu” trên hệ thống chưa được cập nhật

vào FAQ, quản trị viên chọn các ticket chưa được cập nhật vào FAQ

để thêm vào FAQ.

2. Quản trị hiệu chỉnh lại nội dung câu hỏi và trả lời.

3. Thêm câu hỏi-trả lời mới vào cơ sở dữ liệu.

Hiệu chỉnh FAQ

1. Quản trị viên sử dụng Use-case “Tìm kiếm FAQ” để tìm lại các câu

hỏi-trả lời cần sửa đổi.

2. Quản trị thay đổi lại các thông tin liên quan hoặc nội dung câu hỏi,

câu trả lời.

3. Sau khi cập nhật xong các thông tin cần thiết, hệ thống lưu lại câu

hỏi-trả lời vào cơ sở dữ liệu.

Xóa FAQ



1. Quản trị viên sử dụng Use-case “Tìm kiếm FAQ” để tìm lại câu hỏi-

trả lời cần xóa. Hệ thống nhắc quản trị xác nhận yêu cầu xóa.

2. Quản trị viên xác nhận xóa.

3. Hệ thống xóa câu hỏi-trả lời khỏi hệ thống FAQ. Use-case kết thúc.


Thao tác xóa bị hủy

Nếu trong luồng phụ Delete Catelogies hệ thống kiểm tra được chủ đề đó

còn các câu hỏi-trả lời, hoặc chủ đề đó còn chứa chủ đề con thì thao tác xóa bị

huỷ và Dòng sự kiện chính được bắt đầu lại từ đầu.



Điều kiện tiên quyết Quản trị viên, nhân viên phải đăng nhập vào hệ thống mới được phép quản trị FAQ..

Post Conditions Nếu Use-Case thành công FAQ sẽ được thêm vào, sửa, hoặc xóa khỏi hệ thống. Ngược lại, trạng thái của hệ thống không thay đổi.




Chương 5: THIẾT KẾ

5.1. Hiện thực hóa Use-Case

5.1.1. Use-Case Tìm kiếm FAQ

5.1.1.1. Lược đồ VOPC

Lược đồ mô tả các lớp đối tượng trong Use-Case Tìm kiếm FAQ và mối

quan hệ giữa các lớp.

Trangchu Khachhang(from User Interface)

Trang ChiTietFAQ(from User Interface)

FAQ(from Business Object)

Trang TimKiemFAQ(from User Interface)

0..11 0..11 0..n1 0..n1

Trang ThongBaoKetQua(from User Interface)

TimKiemFAQCtrl(from Business Service)

0..1

0..1

0..1

0..1

FAQCtrl(from Business Service)

n0..1 n0..1

0..1

0..1

0..1

0..1



5.1.1.2. Lược đồ Sequence Diagram – Luồng cơ bản

Lược đồ tuần tự các thao tác thực hiện chức năng tìm kiếm FAQ của Use-

Case Tìm kiếm FAQ

: Nguoi su dung : Trangchu Khachhang : Trang TimKiemFAQ : TimKiemFAQCtrl : FAQCtrl : FAQ : Trang ChiTietFAQ

[tim thay cau hoi-tra loi thoa dieu kien tim kiem]

Nguoi dung co the xem nhieu FAQ tim duoc

1: //Chon Tim kiem FAQ( )2: //Hien thi( )

3: //Nhap tu khoa tim kiem( )

4: //Tim kiem( )

11: //Hien thi ket qua( )

12: //Xem chi tiet FAQ( )

13: //Lay thong tin FAQ( )

5: //Thuc hien Tim kiem FAQ( )6: //Tim kiem FAQ( )

8: //Tao Truy van( )

10: //Xu ly ket qua( )

7: //Mo CSDL( )

9: //Truy Van( )

14: //Hien thi chi tiet FAQ( )

15: //Lay thong tin chi tiet FAQ( )

16: //Lay thong tin chi tiet( )


18: //Dong( )



5.1.1.3. Lược đồ Collaboration Diagram

: Nguoi su dung

: Trang TimKiemFAQ

: TimKiemFAQCtrl : FAQCtrl : FAQ

: Trang ChiTietFAQ

8: //Tao Truy van( )10: //Xu ly ket qua( )

11: //Hien thi ket qua( )13: //Lay thong tin FAQ( )17: //Hien thi chi tiet FAQ( )

: Trangchu Khachhang

1: //Chon Tim kiem FAQ( )

3: //Nhap tu khoa tim kiem(String)4: //Tim kiem( )

12: //Xem chi tiet FAQ( )18: //Dong( ) 2: //Hien thi( )

5: //Thuc hien Tim kiem FAQ( )


6: //Tim kiem FAQ( )7: //Mo CSDL( )9: //Truy Van( )


15: //Lay thong tin chi tiet FAQ( )

5.1.2. Use-Case Đăng ký tài khoản


Lược đồ mô tả các lớp đối tượng trong Use-Case Đăng kí tài khoản và mối



TaiKhoan(from Business Object)


EmailCtrl(from Business Service)

Trang DangkyTaikhoan(from User Interface)

0..11 0..11

DangkyTaikhoanCtrl(from Business Service)

0..1

0..1

0..1

0..1

TaiKhoanCtrl(from Business Service)

n0..1 n0..10..1

0..1

0..1

0..1




Lược đồ tuần tự các thao tác thực hiện chức năng đăng ký tài khoản mới

của Use-Case Đăng ký tài khoản

: Khach hang : Trangchu Khachhang : Trang DangkyTaikhoan : DangkyTaikhoanCtrl : TaiKhoanCtrl : TaiKhoan : Trang ThongBaoKetQua : EmailCtrl

1: //Chon Dang ky tai khoan m oi( )2: //Hien thi( )

3: //Nhap ten dang nhap( )

4: //Nhap mat khau( )

5: //Nhap lai mat khau( )

11: //Nhap dia chi email( )

6: //Nhap Ho lot( )

7: //Nhap Ten( )

8: //Nhap Ngay s inh( )

9: //Nhap dia chi( )

10: //Nhap dien thoai( )

12: //Dang ky( )

14: //Thuc hien Dang ky Tai khoan moi( )

13: //Kiem tra mat khau va mat khau nhap lai()

15: //Kiem tra trung ten dang nhap( )

16: //Mo CSDL( )

17: //Tim ten dang nhap( )

[khong tim thay tai khoan cua username -> username chua dang ky]

20: //Them moi Tai khoan( )


22: //Thong bao Dang ky thanh cong( )

18: //Kiem tra trung dia chi em ail( )

19: //Tim dia chi email( )

[Khong tim thay dia chi email do trong CSDL]

23: //Gui email _Dang ky thanh cong( )




: Khach hang : Trangchu Khachhang

: Trang DangkyTaikhoan : DangkyTaikhoanCtrl

: TaiKhoanCtrl

: TaiKhoan

: Trang ThongBaoKetQua

: EmailCtrl

13: //Kiem tra mat khau va mat khau nhap lai()

1: //Chon Dang ky tai khoan moi( )

3: //Nhap ten dang nhap( )4: //Nhap mat khau( )

5: //Nhap lai mat khau( )6: //Nhap Ho lot( )7: //Nhap Ten( )

8: //Nhap Ngay sinh( )9: //Nhap dia chi( )

10: //Nhap dien thoai( )11: //Nhap dia chi email( )

12: //Dang ky( )2: //Hien thi( )

14: //Thuc hien Dang ky Tai khoan moi( )

15: //Kiem tra trung ten dang nhap( )18: //Kiem tra trung dia chi email( )


22: //Thong bao Dang ky thanh cong( )

23: //Gui email _Dang ky thanh cong( )

16: //Mo CSDL( )17: //Tim ten dang nhap( )19: //Tim dia chi email( )


5.1.3. Use-Case Tạo yêu cầu mới


Lược đồ mô tả các lớp đối tượng trong Use-Case Tạo yêu cầu mới và mối



Trang TaoYeuCau(from User Interface)

0..1

1

0..1

1


QuanLyYeuCauCtrl(from Business Service)

0..1

0..1

0..1

0..1

YeuCau(from Business Object)

n0..1 n0..1




Lược đồ tuần tự các thao tác thực hiện chức năng tạo yêu cầu mới(gửi qua

web) của Use-Case Tạo yêu cầu mới.

: QuanLyYeuCauCtrl : Nguoi su dung : Trangchu Khachhang : Trang TaoYeuCau : EmailCtrl : YeuCau

gui thong bao ve viec co yeu cau moi toi cac phong ban, cac staff va quan tri he thong.

1: //Chon Tai Yeu cau moi( )2: //Hien thi( )

3: //Nhap tieu de( )

4: //Nhap noi dung yeu cau( )

5: //Chon phong ban( )

6: //Chon do uu tien( )

8: //Gui yeu cau( )

7: //Them file dinh kem( )

9: //Thuc hien Them moi Yeu cau( )

12: //Gui email_Thong bao co Yeu cau moi( )

10: //Mo CSDL( )

11: //Them moi Yeu cau( )




: Nguoi su dung

: Trang TaoYeuCau : QuanLyYeuCauCtrl

: EmailCtrl

: YeuCau

: Trangchu Khachhang

1: //Chon Tai Yeu cau moi( )

3: //Nhap tieu de( )4: //Nhap noi dung yeu cau( )

5: //Chon phong ban( )6: //Chon do uu tien( )

7: //Them file dinh kem( )8: //Gui yeu cau( ) 2: //Hien thi( )

9: //Thuc hien Them moi Yeu cau( )

12: //Gui email_Thong bao co Yeu cau moi( )

10: //Mo CSDL( )11: //Them moi Yeu cau( )

5.1.4. Use-Case Giải quyết yêu cầu


Lược đồ mô tả các lớp đối tượng trong Use-Case Giải quyết yêu cầu và

mối quan hệ giữa các lớp.

Trangchu QuanTri(from User Interface)

Trang QuanLyYeucau(from User Interface)

0..11 0..11

GiaiQuyetYeuCau(from Business Object)


Trang GiaiQuyetYeuCau(from User Interface)

GiaiQuyetYeuCauCtrl(from Business Service)

n 0..1n 0..1

0..1

0..1

0..1

0..1


n0..1 n0..1




Lược đồ tuần tự các thao tác thực hiện chức năng trả lời yêu cầu của Use-

Case Giải quyết yêu cầu

: Nhan vien : Trangchu QuanTri : Trang QuanLyYeucau : Trang GiaiQuyetYeuCau : GiaiQuyetYeuCauCtrl : YeuCau : EmailCtrl : GiaiQuyetYeuCau

1: //Chon Giai quyet Yeu cau( )2: //Hien thi( )

3: //Chon Yeu cau de giai quyet( )

4: //Lay thong tin Yeu cau( )

6: //Hien thi chi tiet Yeu cau( )

9: //Nhap noi dung tra loi moi( )

10: //Gui tra loi( )11: //Thuc hien gui tra loi( )

13: //Gui email_Noi dung tra loi Yeu cau( )

gui email cho khach hang ve noi dung tra loi cua nhan vien14: //Dong( )

12: //Them moi tra loi( )

5: //Gui email_Thong bao Yeu cau dang duoc xem xet( )

7: //Lay thong tin chi tiet Yeu cau( )





: Nhan vien : Trangchu QuanTri

: Trang QuanLyYeucau

: GiaiQuyetYeuCauCtrl : EmailCtrl

: Trang GiaiQuyetYeuCau

: YeuCau : GiaiQuyetYeuCau

1: //Chon Giai quyet Yeu cau( )

2: //Hien thi( )3: //Chon Yeu cau de giai quyet( )


5: //Gui email_Thong bao Yeu cau dang duoc xem xet( )


7: //Lay thong tin chi tiet Yeu cau( )


9: //Nhap noi dung tra loi moi( )10: //Gui tra loi( )

11: //Thuc hien gui tra loi( )

12: //Them moi tra loi( )

13: //Gui email_Noi dung tra loi Yeu cau( )

14: //Dong( )

5.1.5. Use-Case Xem và hiệu chỉnh yêu cầu


Lược đồ mô tả các lớp đối tượng trong Use-Case Xem và hiệu chỉnh yêu

cầu và mối quan hệ giữa các lớp.






Trang ChiTietYeuCau(from User Interface)

0..11


n0..1 n0..1

0..1

0..1

0..1

0..1

0..11


Lược đồ tuần tự các thao tác thực hiện chức năng hiệu chỉnh yêu cầu của

Use-Case Xem và hiệu chỉnh yêu cầu.

: Nguoi su dung : Trangchu Khachhang : Trang ChiTietYeuCau : QuanLyYeuCauCtrl : YeuCau : Trang ThongBaoKetQua

1: //Chon Yeu cau can xem( )

2: //Hien thi chi tiet Yeu cau( )3: //Lay thong tin Yeu cau( )

5: //Chon hieu chinh Yeu cau( )

6: //Hien thi thong tin Yeu cau can hieu chinh( )

7: //Thay doi noi dung( )

8: //Thay doi phong ban( )

9: //Thay doi do uu tien( )

11: //Cap nhat( )

12: //Thuc hien Cap nhat Yeu cau( )

14: //Thong bao cap nhat Yeu cau thanh cong( )

10: //Thay doi trang thai( )


13: //Cap nhat Yeu cau( )




: Nguoi su dung : Trangchu Khachhang

: QuanLyYeuCauCtrl : YeuCau : Trang ChiTietYeuCau


6: //Hien thi thong tin Yeu cau can hieu chinh( )

1: //Chon Yeu cau can xem( )

5: //Chon hieu chinh Yeu cau( )7: //Thay doi noi dung( )

8: //Thay doi phong ban( )9: //Thay doi do uu tien( )10: //Thay doi trang thai( )

11: //Cap nhat( )2: //Hien thi chi tiet Yeu cau( )

14: //Thong bao cap nhat Yeu cau thanh cong( )

4: //Lay thong tin chi tiet( )13: //Cap nhat Yeu cau( )

3: //Lay thong tin Yeu cau( )12: //Thuc hien Cap nhat Yeu cau( )

5.1.6. Use-Case Tìm kiếm yêu cầu


Lược đồ mô tả các lớp đối tượng trong Use-Case Tìm kiếm yêu cầu và mối




Trang TimKiemYeucau(from User Interface)

0..11 0..11

TimKiemYeucauCtrl(from Business Service)

n0..1 n0..1

0..1

0..1

0..1

0..1

Trang ChiTietYeuCau(from User Interface)

0..n 10..n 1




Lược đồ tuần tự các thao tác thực hiện chức năng tìm kiếm yêu cầu của

Use-Case Tìm kiếm yêu cầu.

Nguoi dung co the xem nhieu ticket

: Nguoi su dung : Trangchu QuanTri : Trang TimKiemYeucau : TimKiemYeucauCtrl : YeuCau : Trang ChiTietYeuCau

1: //Chon Tim kiem Yeu cau( )2: //Hien thi( )

3: //Nhap tu khoa tim kiem( )

4: //Nhap ten nguoi gui( )

8: //Tim kiem( )

9: //Thuc hien tim kiem Yeu cau( )

tu khoa de tim kiem ticket theo noi dung cau hoi va noi dung tra loi

Ket qua tra ve la mang cac ticket thoa dieu kien tim kiem

14: //Hien thi ket qua( )

15: //Xem chi tiet Yeu cau( )

16: //Lay thong tin Yeu cau( )17: //Hien thi chi tiet Yeu cau( )

20: //Dong( )

[tim thay ticket thoa dieu kien tim kiem]

5: //Nhap chu de( )

6: //Nhap ngay gui( )

7: //Nhap trang thai Yeu cau( )

10: //Mo CSDL( )

11: //Tao truy van( )

12: //Truy Van( )







: Nguoi su dung : Trangchu QuanTri

: Trang TimKiemYeucau : TimKiemYeucauCtrl

: YeuCau

11: //Tao truy van( )13: //Xu ly ket qua( )

14: //Hien thi ket qua( )16: //Lay thong tin Yeu cau( )

: Trang ChiTietYeuCau


1: //Chon Tim kiem Yeu cau( )

3: //Nhap tu khoa tim kiem( )4: //Nhap ten nguoi gui( )

5: //Nhap chu de( )6: //Nhap ngay gui( )

7: //Nhap trang thai Yeu cau( )8: //Tim kiem( )

15: //Xem chi tiet Yeu cau( )

20: //Dong( )

2: //Hien thi( )

9: //Thuc hien tim kiem Yeu cau( )

17: //Hien thi chi tiet Yeu cau( )10: //Mo CSDL( )12: //Truy Van( )


5.1.7. Use-Case Quản lý yêu cầu


Lược đồ mô tả các lớp đối tượng trong Use-Case Quản lý yêu cầu và mối



Trang QuanLyYeucau(from User Interface)

0..11 0..11 Trang ThongBaoKetQua(from User Interface)



0..1

0..1

0..1

0..1

n0..1 n0..1GiaiQuyetYeuCau(from Business Object)

n 0..1n 0..1




Lược đồ tuần tự các thao tác thực hiện chức năng xóa yêu cầu của Use-

Case Quản lý yêu cầu.

: Quan tri : Trangchu QuanTri : Trang QuanLyYeucau : QuanLyYeuCauCtrl : YeuCau : GiaiQuyetYeuCau : Trang ThongBaoKetQua

1: //Chon Quan ly Yeu cau( )2: //Hien thi( )

3: //Chon Yeu cau can xoa( )

4: //Xac nhan xoa( )

5: //Dong y xoa( )

6: //Thuc hien xoa Yeu cau( )

9: //Xoa Yeu cau( )

7: //Kiem tra Yeu cau da co tra loi( )

[Yeu cau da co tra loi]

8: //Xoa tra loi( )

10: //Thong bao Yeu cau da xoa thanh cong( )

Neu yeu cau da co tra loi thi phai xoa het tra loi truoc khi xoa Yeu cau




: Quan tri

: Trangchu QuanTri

: Trang QuanLyYeucau

: QuanLyYeuCauCtrl

: YeuCau

: GiaiQuyetYeuCau

4: //Xac nhan xoa( )

1: //Chon Quan ly Yeu cau( )

3: //Chon Yeu cau can xoa( )5: //Dong y xoa( )

2: //Hien thi( )

6: //Thuc hien xoa Yeu cau( )

7: //Kiem tra Yeu cau da co tra loi( )9: //Xoa Yeu cau( )

8: //Xoa tra loi( )


10: //Thong bao Yeu cau da xoa thanh cong( )

5.1.8. Use-Case Quản lý FAQ


Lược đồ mô tả các lớp đối tượng trong Use-Case Quản lý FAQ và mối



Trang QuanlyFAQ(from User Interface)

0..11 0..11

FAQ(from Business Object)


QuanLyFAQCtrl(from Business Service)

0..1

0..1

0..1

0..1

n0..1 n0..1n 0..1n 0..1




5.1.8.2. Lược đồ Sequence Diagram – Luồng thêm FAQ từ Yêu

cầu

Lược đồ tuần tự các thao tác thực hiện chức năng thêm FAQ mới từ yêu

cầu có sẳn của Use-Case Quản lý FAQ.

: Quan tri : Trangchu QuanTri : Trang QuanlyFAQ : QuanLyFAQCtrl : YeuCau : FAQ : Trang ThongBaoKetQua

1: //Chon Quan ly FAQ( )2: //Hien thi( )

3: //Chon them moi FAQ tu Yeu cau( )

4: //Lay du lieu Yeu cau( )

truy xuat co so du lieu lay ra cac ticket chua duoc cap nhat vao FAQ theo thu tu ngay thang

7: //Hien thi danh sach Yeu cau( )


8: //Chon Yeu cau them vao FAQ( )


10: //Hien thi form them FAQ tu Yeu cau( )

form them moi FAQ co chua san noi dung cau hoi la noi dung yeu cau cua Ticket, noi dung cau tra loi la ket hop cac cau tra loi cua ticket

11: //Hieu chinh Cau hoi( )

12: //Hieu chinh cau tra loi( )

13: //Chon chu de( )

14: //Them moi FAQ( )

15: /Thuc hien them moi FAQ( )

cap nhat bang ticket danh dau ticket da duoc cap nhat FAQ, va luu lai ma FAQ cua ticket do

5: //Lay Yeu cau( )

17: //Cap nhat YeuCau_FAQ( )


18: //Thong bao them moi FAQ thanh cong( )




: Quan tri : Trangchu QuanTri

: Trang QuanlyFAQ : QuanLyFAQCtrl

: FAQ

: YeuCau


1: //Chon Quan ly FAQ( )

2: //Hien thi( )

3: //Chon them moi FAQ tu Yeu cau( )

4: //Lay du lieu Yeu cau( )

5: //Lay Yeu cau( )


7: //Hien thi danh sach Yeu cau( )

8: //Chon Yeu cau them vao FAQ( )

9: //Lay thong tin Yeu cau( )10: //Hien thi form them FAQ tu Yeu cau( )

11: //Hieu chinh Cau hoi( )12: //Hieu chinh cau tra loi( )

13: //Chon chu de( )14: //Them moi FAQ( )

15: /Thuc hien them moi FAQ( )


17: //Cap nhat YeuCau_FAQ( )

18: //Thong bao them moi FAQ thanh cong( )



5.2. Thiết kế cơ sở dữ liệu

5.2.1. Sơ đồ lớp Từ mô hình lớp của hiện thực hóa Use-Case ta có sơ đồ lớp như sau:

Tra Loi NhanhMa Tra loi nhanh : IntegerTieu de : StringNoi dung : String

Taikhoan_QuyenNgay gan quyen : DateNgay hen han : DateMo ta : String

GiaiQuyetYeuCauMa van de : StringThu tu giai quyet : StringNoi dung tra loi : StringNgay tra loi : Date

Taikhoan_PhongbanNgay gia nhap : string

ThongBaoMa thong bao : StringTieu de thong bao : StringNoi dung thong bao : StringNgay thong bao : DateNgay het han : DateSo lan xem : IntegerQuyen xem : IntegerNguoi thong bao : String

QuyenHethongMa quyen : IntegerTen quyen : stringMo ta : string

TaiKhoanTen tai khoan : StringHo lot : StringTen : StringMat khau : StringDia chi : StringNgay sinh : DateEmail : StringDienthoai : StringNgay dang ki : DateKich hoat : IntegerLoai tai khoan : IntegerNgon ngu su dung : IntegerNgay dang nhap cuoi : DateNhan thong bao qua Email : IntegerNhan Reply qua Email : IntegerTong bai viet : Integer

0..n

1

0..n

10..n

1..n

0..n

1..n

TaiLieuMa tai lieu : StringTen tai lieu : StringNoi dung tom tat : StringNgay upload : DateTen file dinh kem : StringSo lan dowload : IntegerKich thuoc : IntegerNguoi them TL : String

0..n1 0..n1

FAQMa FAQ : StringND cau hoi : StringND cau tra loi : StringSo lan xem : IntegerNgay cap nhat : Date

0..n

1

0..n

1

ChudeMa chu de : StringTen chu de : StringMa chu de truoc : StringMo ta chu de : String

1

0..n

1

0..n

0..n

1

0..n

1 0..1

0..n

0..1

0..n

PhongbanMa phong ban : StringTen phong ban : StringMo ta : string

0..n

0..n

0..n

0..n

YeuCauMa yeu cau : StringTieu de : StringNoi dung : StringMuc do khan cap : IntegerNgay mo : DateTen file dinh kem : StringTrang thai : IntegerNgay dong : DateMa FAQ : String

0..n

0..n

0..n

0..n

11

11

1

0..n

1

0..n

Hình 5-1: Sơ đồ lớp



5.2.2. Mô hình quan hệ Mô hình lưu trữ dữ liệu trong CSDL SQL như sau:

Hình 5-2: Mô hình quan hệ cơ sở dữ liệu



Danh sách các đối tượng

STT Tên đối tượng Mô tả

1 ACCOUNT Tài khoản người dùng trong hệ thống

2 TICKET Yêu cầu khách hàng gửi lên hệ thống

3 SOLVETICKET Giải quyết yêu cầu do khách hàng đặt ra

4 DOCUMENT Các tài liệu, văn bản cho phép tải về

5 FAQ Hệ thống các câu hỏi-trả lời có sẵn

6 TOPIC Các chủ đề để phân chia các tài liệu và FAQ

7 QUICKREPLY Các mẫu tin giúp trả lời nhanh

8 ANNOUNCEMENT Các thông báo do công ty đưa ra

9 SYSTEMRIGHT Các quyền của hệ thống

10 DEPARTMENT Các phòng ban trong doanh nghiệp

11 DEPARTMENT_ACCOUNT Phân chia nhân viên theo phòng ban

12 RIGHT_ACCOUNT Phân chia quyền cho nhân viên

Bảng 5-1: Danh sách các đối tượng lưu trữ dữ liệu

5.2.3. Mô tả chi tiết các lớp đối tượng

Tài Khoản (ACCOUNT)

STT Tên thuộc tính Kiểu DL Loại Ràng buộc Ý nghĩa

1 USR_NAME Chuỗi (30) Khóa chính Khác null Tên tài khoản

2 USR_FIRSTNAME Chuỗi (20) Họ lót

3 USR_LASTNAME Chuỗi (10) Tên

4 USR_PASSWORD Chuỗi (20) Mật khẩu



5 USR_EMAIL Chuỗi (30) Địa chỉ email

6 USR_ADDRESS Chuỗi (60) Địa chỉ liên lạc

7 USR_BIRTHDAY Ngày Ngày sinh

8 USR_DATEREG Ngày Ngày đăng ký tài

9 USR_PHONE Chuỗi (10) Số điện thoại

10 USR_CATEGORY Chuỗi (5) Loại tài khoản

11 USR_LANGUAGE Chuỗi (2) Ngôn ngữ

12 USR_LASTLOGIN Ngày Ngày đăng nhập cuối

13 USR_TOTALPOST Số nguyên Tổng số lần gởi bài

14 USR_EMAILANN Số nguyên [0,1] Nhận thông báo qua email

15 USR_EMAILNOTIFY Số nguyên [0,1] Nhận trả lời qua email

16 USR_ACTIVATED Số nguyên [0,1] Trạng thái kích hoạt

Yêu Cầu (TICKET)


1 TIC_ID Chuỗi (10) Khóa chính Khác null Mã yêu cầu

2 TIC_SUBJECT Chuỗi (100) Tiêu đề

3 TIC_MESSAGE Chuỗi (1000) Nội dung yêu cầu

4 TIC_POSTDATE Ngày Ngày gởi

5 TIC_CLOSEDATE Ngày Ngày đóng

6 TIC_PRIORITY Số nguyên Độ ưu tiên

7 TIC_USRNAME Chuỗi (30) Khóa ngoại

Quan hệ với lớp ACCOUNT

Tên tài khoản người gởi yêu cầu



8 TIC_STATUS Số nguyên Trạng thái

9 TIC_FILENAME Chuỗi (100) Tài liệu đính kèm

10 TIC_DEP_ID Số nguyên Khóa ngoại

Quan hệ với lớp DEPARTMENT

Mã phòng ban giải quyết yêu cầu

12 TIC_FAQ_ID Chuỗi (10) Khóa ngoại

Quan hệ với lớp FAQ

Mã FAQ của yêu cầu

Giải quyết yêu cầu (SOLVETICKET)


1 SOL_TIC_ID Chuỗi (10) Quan hệ với lớp TICKET Mã Yêu cầu

2 SOL_USRNAME Chuỗi (30) Quan hệ với lớp ACCOUNT Tên tài khoản

3 SOL_ORDER Số nguyên

Khóa chính

Khác null Thứ tự giải quyết

4 SOL_REPLYDATE Ngày Ngày trả lời

5 SOL_MSGREPLY Chuỗi (1000) Nội dung trả lời

Chủ Đề (TOPIC)


1 TOP_ID Chuỗi (10) Khóa chính Khác null Mã chủ đề

2 TOP_TITLE Chuỗi (5) Tên chủ đề

3 TOP_NOTE Chuỗi (200) Các ghi chú nếu có

4 TOP_PRE Chuỗi (10) Khóa ngoại Mã chủ đề cha



Câu Hỏi-Trả Lời (FAQ)


1 FAQ_ID Chuỗi (10) Khóa chính Khác null Mã FAQ

2 FAQ_QUESTION Chuỗi (500) Nội dung câu hỏi

3 FAQ_ANSWER Chuỗi (1000) Nội dung câu trả

lời

4 FAQ_VIEW Số nguyên Số lần xem

6 FAQ_DATEUPDATE Ngày Ngày cập nhật

7 FAQ_TOP_ID Chuỗi (10) Khóa ngoại

Quan hệ với lớp TOPIC

Mã chủ đề mà FAQ này thuộc về

8 FAQ_DOC_ID Chuỗi (10) Khóa ngoại

Quan hệ với lớp DOCUMENT

Mã tài liệu liên quan

Thông báo (ANNOUNCEMENT)


1 ANN_ID Chuỗi (10) Khóa chính Khác null Mã thông báo

2 ANN_TITLE Chuỗi (100) Tiêu đề

3 ANN_CONTENT Chuỗi (1000) Nội dung thông

báo

4 ANN_POSTDATE Ngày Ngày thông báo

5 ANN_EXPDATE Ngày Ngày hết hạn

6 ANN_VIEW Số nguyên Số lần xem

7 ANN_RIGHTVIEW Số nguyên Quyền xem

8 ANN_USRNAME Chuỗi (10) Khóa ngoại

Quan hệ với lớp ACCOUNT

Người gửi thông báo



5.2.4. Mô tả các ràng buộc toàn vẹn

5.2.4.1. Các ràng buộc miền giá trị

• R1: Ngày đóng yêu cầu phải lớn hơn hoặc bằng ngày gởi yêu cầu.

− Thuật toán:

∀ yc ∈ TICKET yc.TIC_CLOSEDATE >= yc.TIC_POSTDATE

Cuối ∀

− Bảng tầm ảnh hưởng

R1 Thêm Xóa Sửa

TICKET – – +(TIC_CLOSEDATE, TIC_POSTDATE)

• R2: Ngày đăng ký tài khoản của người dùng phải lớn hơn ngày sinh của

người đó.

− Thuật toán:

∀ tk ∈ ACCOUNT tk.USR_DATEREG > tk.USR_BIRTHDAY

Cuối ∀


R2 Thêm Xóa Sửa

ACCOUNT – – +(USR_BIRTHDAY, USR_DATEREG)



5.2.4.2. Các ràng buộc liên thuộc tính, liên quan hệ liên thuộc

tính

• R3: Ngày giải quyết yêu cầu phải lớn hơn hoặc bằng ngày gởi yêu cầu.

− Thuật toán:

∀ gq ∈ SOLVETICKET Chọn yc ∈ TICKET sao cho Nếu yc.TIC_ID= gq.SOL_TIC_ID thì

gq.SOL_TIC_ID >= yc.TIC_POSTDATE

Cuối ∀


R3 Thêm Xóa Sửa

TICKET – – +(TIC_POSTDATE)

SOLVETICKET +(SOL_REPLYDATE) – +(SOL_REPLYDATE)

• R4: Tổng số lần gởi bài của một người dùng phải bằng tổng số các yêu

cầu và số lần giải quyết yêu cầu của người dùng đó.

− Thuật toán:

∀ tk ∈ ACCOUNT thì tk.USR_TOTALPOST=Count1+Count2

Trong đó:

Count1= Đếm tất cả các bộ của

bảng TICKET (yc∈TICKET) sao cho yc.TIC_USRNAME=tk.USR_NAME

Count2= Đếm tất cả các bộ của

bảng SOLVETICKET (gq∈SOLVETICKET) sao cho gq.SOL_USRNAME=tk.USR_NAME

Cuối ∀




R4 Thêm Xóa Sửa

TICKET – – –

SOLVETICKET – – –

ACCOUNT +(USR_TOTALPOST) +(USR_TOTALPOST) –

5.2.4.3. Các ràng buộc phụ thuộc tồn tại

• R5: Tất cả các SOL_TIC_ID và SOL_USRNAME trong bảng

SOLVETICKET phải có trước trong bảng TICKET và bảng ACCOUNT.

− Thuật toán:

SOLVETICKET.SOL_TIC_ID TICKET.TIC_ID ⊂SOLVETICKET.SOL_USRNAME ⊂ ACCOUNT.USR_NAME


R5 Thêm Xóa Sửa

ACCOUNT – – +(USR_NAME)

TICKET – – +(TIC_ID)

SOLVETICKET +(SOL_TIC_ID, SOL_USRNAME) – +(SOL_TIC_ID,

SOL_USRNAME)

• R6: Tất cả các DEA_USRNAME và DEA_DEP_ID trong bảng

DEPARTMENT_ACCOUNT phải có trước trong bảng DEPARTMENT và

bảng ACCOUNT.

− Thuật toán:

DEPARTMENT_ACCOUNT.DEA_USRNAME ACCOUNT.USR_NAME ⊂DEPARTMENT_ACCOUNT.DEA_DEP_ID DEPARTMENT.DEP_ID ⊂




R6 Thêm Xóa Sửa

ACCOUNT – – +(USR_NAME)

DEPARTMENT – – +(DEP_ID)

DEPARTMENT_ACCOUNT +(DEA_DEP_ID, DEA_USRNAME) – +(DEA_DEP_ID,

DEA_USRNAME)

5.3. Thiết kế cài đặt và triển khai

5.3.1. Mô hình cài đặt Trong chương trình ứng dụng này, ta dùng C# là ngôn ngữ lập trình cho

phần cài đặt hệ thống quản lý dịch vụ khách hàng. Ứng dụng được thiết kế

theo mô hình ba lớp: lớp giao diện, lớp xử lý nghiệp vụ chức năng, lớp xử lý

dữ liệu. Hình dưới minh họa các lớp cài đặt của hệ thống. Mỗi lớp chứa các

lớp con của hệ thống.

Hình 5-3: Mô hình cài đặt



Thành phần lớp Giao diện

Thành phần lớp giao diện chứa các thành phần giao tiếp với người dùng,

bao gồm các trang giao diện và các lớp xử lý màn hình. Các trang chịu trách

nhiệm thể hiện các giao tiếp, các lớp chịu trách nhiệm xử lý các sự kiện trên

trang.

Thành phần lớp Xử lý nghiệp vụ chức năng

Thành phần lớp xử lý nghiệp vụ chức năng chứa các lớp chịu trách nhiệm

kết nối giữa phần xử lý giao diện và dữ liệu của hệ thống. Gồm: XLTicket,

XLFAQ, XLDocument, XLAccount, …

Thành phần lớp Xử lý dữ liệu

Thành phần lớp xử lý dữ liệu gồm các lớp thao tác truy xuất dữ liệu trên

CSDL SQL Server và trên tập tin XML: DBAccess, XLDocumentXML, ..

5.3.2. Mô hình triển khai hệ thống Bước cuối cùng là cài đặt và triển khai hệ thống, tức mô tả kiến trúc phần

cứng và định vị các tập tin chương trình vào các thiết bị vật lý.


Tìm hi

S

ểu công nghệ XML và xây dựng hệ thống quản lý dịch vụ khách hàng

VTH: Nguyễn Thị Kim Phượng GVHD: Th.S Nguyễn Trần Minh Thư T rương K iều G iang 107

Hình trên là mô hình triển khai hệ thống mô tả kiến trúc vật lý của hệ

thống. Hệ thống sẽ cài đặt trên máy chủ(Server), yêu cầu máy này phải có hỗ

trợ Microsoft.NET Framework 1.1 trở lên. Cơ sở dữ liệu của hệ thống được

cài đặt trên hệ quản trị SQL Server có thể ở cùng máy hoặc khác máy với

Server của ứng dụng. Trong hệ thống Server ta có MailServer và WebServer,

cả hai có thể nằm cùng máy hoặc khác máy. Mail Server sử dụng giao thức

IMAP để gửi nhận mail, địa chỉ mail hỗ trợ của doanh nghiệp sẽ thuộc mail

server này. Toàn bộ hệ thống giao tiếp với mạng internet thông qua các dịch

vụ mạng để khách hàng có thể truy cập từ bất kỳ đâu.

5.4. Thiết kế giao diện

Hình 5-4: Mô hình triển khai hệ thống



Hình 5-5: Sơ đồ liên kết các màn hình

5.4.1. Sơ đồ liên kết các màn hình


5.4.2. Thiết kế chi tiết một số màn hình

5.4.2.1. Màn hình chính

1

2

3

Trang chủ của hệ thống hỗ trợ khách hàng

Thành phần giao diện:

[1] Các link tới các trang chức năng của khách hàng

[2] Tìm kiếm FAQ

[3] Danh sách các câu hỏi - trả lời (FAQ) được xem nhiều nhất



5.4.2.2. Màn hình chính của khách hàng

1

2

3

Màn hình chính của khách hàng sau khi khách hàng đăng nhập hệ thống


[1] Danh sách các yêu cầu khách hàng đã mở

[2] Các thông báo của doanh nghiệp thông báo cho khách hàng

[3] Chức năng nhận/hủy nhận thông báo qua email



5.4.2.3. Màn hình gửi yêu cầu

Gửi trực tiếp hệ thống

1

2

Màn hình gửi yêu cầu,


[1] Điều khiển hỗ trợ định dạng văn bản (WYSIWYG)

[2] Thông tin về yêu cầu gửi đi.



Gửi qua email

1

2

Màn hình gửi yêu cầu lên địa chỉ email hỗ trợ khách hàng,


[1] Thông tin về yêu cầu gửi đi, trong đó có cả email của khách hàng

và email hỗ trợ của doanh nghiệp

[2] Điều khiển hỗ trợ định dạng văn bản (WYSIWYG)



5.4.2.4. Màn hình theo dõi yêu cầu của khách hàng

2

1

3

Màn hình theo dõi yêu cầu của khách hàng


[1] Các thông tin về yêu cầu

[2] Nội dung yêu cầu của khách hàng

[3] Nội dung trả lời của yêu cầu




2

1

Màn hình theo dõi yêu cầu của khách hàng


[1] HIệu chỉnh thông tin yêu cầu

[2] Hiệu chỉnh nội dung yêu cầu



5.4.2.5. Màn hình tìm kiếm FAQ

3

2

1

Màn hình tìm kiếm FAQ


[1] Textbox nhập từ khóa tìm kiếm

[2] Kết quả tìm kiếm

[3] Hệ thống FAQ phân theo chủ đề



5.4.2.6. Màn hình chính của nhân viên

2

1

Màn hình chính của nhân viên khi nhân viên đăng nhập hệ thống thành

công


[1] Các yêu cầu mới của phòng ban mà nhân viên thuộc về

[2] Các thông báo của doanh nghiệp, quản trị thông báo cho nhân viên



5.4.2.7. Màn hình quản lý Yêu cầu

2

1

Màn hình chính quản lý yêu cầu của quản trị


[1] Thông tin về yêu cầu của từng phòng ban, gồm số lượng yêu cầu

mở đóng, v.v…

[2] Toàn bộ chức năng của quản trị viên.



5.4.2.8. Màn hình tìm kiếm yêu cầu

2

1

Màn hình tìm kiếm Yêu cầu


[1] Các tiêu chí tìm kiếm




5.4.2.9. Màn hình tìm kiếm tài khoản

2

1

Màn hình tìm kiếm Tài khoản


[1] Các tiêu chí tìm kiếm




5.4.2.10. Màn hình quản lý email hỗ trợ khách hàng

2

1

Màn hình quản lý email của khách hàng gửi về


[1] Danh sách các email do khách hàng gửi về địa chỉ email hỗ trợ.

[2] Nội dung của email chính là nội dung của yêu cầu của khách hàng.



Chương 6: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN

6.1. Kết luận Trong quá trình phục vụ khách hàng, các doanh nghiệp đều mong muốn

đem lại sự phục vụ hiệu quả, tiện lợi và nhanh chóng cho đối tác của mình.

Mặt khác, yếu tố chi phí luôn được các doanh nghiệp quan tâm hàng đầu.

Làm sao xây dựng được một hệ thống quản lý dịch vụ khách hàng với chi phí

đạt đến mức tối thiểu là điều mà các doanh nghiệp luôn mong đợi. Song song

đó, hệ thống xây dựng được chạy trong môi trường Internet nên độ ổn định,

an toàn, bảo mật cũng là yếu tố được xem là hàng đầu.

Cũng dựa trên quan điểm trên, mục tiêu của đề tài luận văn đặt ra là xây

dựng được một hệ thống quản lý dịch vụ khách hàng đáp ứng được các yêu

cầu mà doanh nghiệp đưa ra. Nội dung của đề tài đưa ra khá rộng và chỉ được

thực hiện trong thời gian khoảng 6 tháng do vậy để hoàn tất đề tài này chúng

em phải gặp rất nhiều khó khăn về mặt tìm kiếm tài liệu, đọc hiểu tài liệu, và

kỹ thuật xây dựng chương trình trong môi trường hoàn toàn khá mới đó là

ASP.NET. Nhưng bù đắp lại những khó khăn vất vả đó là chúng em đã tiếp

thu được rất nhiều kiến thức mới lạ và nâng cao kỹ năng lập trình đặc biệt là

nắm bắt được một ngôn ngữ khá mới đó là XML. Và cuối cùng, chúng em

cũng đã hoàn thành được những mục tiêu, yêu cầu đưa ra của đề tài. Sau đây

là một số kết quả chúng em đã đạt được cho đề tài:



6.1.1.1. Về mặt nghiên cứu lý thuyết

Nghiên cứu XML

Hiểu, nắm được tư tưởng và biết cách sử dụng XML trong vấn đề lưu

trữ dữ liệu cũng như các công nghệ liên quan đến nó như XPath,

Schema XML, XSLT, DOM, v.v...

Đưa công nghệ XML vào việc xây dựng ứng dụng và hỗ trợ trong vấn

đề lưu trữ dữ liệu.

Xử lý truy vấn

Ứng dụng các giải thuật trích từ dựa trên từ điển tiếng Việt giúp cho

việc tìm kiếm được chính xác và hiệu quả.

Sử dụng truy vấn trên tập tin XML để cải thiện tốc độ truy vấn.

Xử lý Mail Client/Server

Hiểu cách hoạt động của hệ thống Mail Client/Server để ứng dụng vào

việc kiểm tra và phân loại email tự động.

Hỗ trợ tối đa việc thông báo qua email cho từng khách hàng.

6.1.1.2. Về mặt ứng dụng

Xây dựng một chương trình hỗ trợ dịch vụ khách hàng chạy trên môi

trường web giúp cho các doanh nghiệp tiết kiệm thời gian và nhân lực, giải

đáp yêu cầu nhanh chóng và chính xác. Chương trình bao gồm:

Hỗ trợ khách hàng trong quá trình tìm kiếm các vấn đề liên quan cần

giải đáp.



Đưa yêu cầu của khách hàng nhanh chóng đến doanh nghiệp bằng biện

pháp gởi qua email.

Tự động phân loại những yêu cầu gởi qua email của khách hàng về các

phòng ban của doanh nghiệp để được giải đáp.

Hỗ trợ các chức năng thông báo qua email để tiện lợi cho khách hàng.

Chương trình có giao diện thân thiện, trang nhã, và dễ sử dụng.

Giao diện hỗ trợ đa ngôn ngữ (tiếng Việt và tiếng Anh).

6.2. Hướng phát triển Với những gì đạt được cũng như những hạn chế còn mắc phải, hướng phát

triển của luận văn như sau:

Ứng dụng XML trong vấn đề trao đổi dữ liệu giữa các hệ thống khác nhau

mà không phải phụ thuộc vào bất cứ định dạng nào.

Xây dựng chương trình tự động học ngữ nghĩa của câu theo từ điển tiếng

Việt để việc phân loại email bằng tiếng Việt chính xác theo ngữ nghĩa của

tiếng Việt.

Xây dựng hệ thống sao cho có thể tự động cập nhật FAQ từ nhiều FAQ

của nhiều hệ thống khác nhau thông qua môi trường Internet.



TÀI LIỆU THAM KHẢO

Tiếng Việt [1] Phạm Hữu Khang, Xây dựng và triển khai ứng dụng thương mại điện tử,

NXB Thống Kê, Thành phố Hồ Chí Minh, 2003.

[2] Dương Anh Đức, Giáo trình Phân tích & Thiết kế hướng đối tượng bằng

UML, nxb Thống Kê, Thành phố Hồ Chí Minh, 2002.

[3] Phạm Nguyễn Cương, Giáo trình phân tích thiết kế hệ thống thông tin,

2004.

[4] Đinh Điền, Giáo trình Xử lý ngôn ngữ tự nhiên.

Tiếng Anh [5] Adam Sills, Mesbah Ahmed, et al, XML .NET Developer’s Guidie,

Syngress Publishing, 2002.

[6] Adrian Turtschi, Jason Werry, Greg Hack, Joseph Albahari, et al, C# .NET

Web Developer’s Guide, Syngress Publishing, 2002.

[7] Mesbah Ahmed, Chris Garrett, Jeremy Faircloth, Chris Payne, ASP.NET

Web Developer's Guide, Syngress Publishing, 2002.

[8] www.kayako.com

[9] www.kerio.com

[10] www.w3c.com

[11] http://www.techguide.com Building a Customer-Centric Contact Center



PHỤ LỤC

Documents

Xml xay dung_he_thong_ho_tro_khach_hang