Mô hình thực thi hệ thống được chia thành các thành phần (component) sau:
Hình 32 - Khung nhìn thực thi
3.3. Thực hiện hệ thống 3.3.1. Lựa chọn công nghệ
3.3.1.1. Công cụ lập trình và cơ sở dữ liệu
Hệ thống thi trắc nghiệm là hệ thống web-based nên có thể sử dụng nhiều công nghệ khác nhau. Trong thời điểm hiện nay, có thể thấy có các công nghệđiển hình sau:
• Ngôn ngữ lập trình: Java, PHP, Microsoft.Net.
• Cơ sở dữ liệu: Oracle, MySQL, SQL Server.
Hệ thống sử dụng dịch vụ web theo kiểu REST nên Java và Micrsoft.Net là phù hợp. Hiện nay, Microsoft đã phát hành phiên bản Visual Studio 2005/2008 trên nên tảng DotNetFrame work 3.0/3.5 có hỗ trợ đầy đủ REST. Vì vậy, môi trường lập trình được chọn là Visual Studio 2005/2008 .
Về lĩnh vực cơ sở dữ liệu, có thể lựa chọn một số cơ sở dữ liệu, đáp ứng đủ yêu cầu. MySQL là bản cơ sở dữ liệu mã nguồn mở. Oracle và SQL Server đều có bản bán thương mại và bản miễn phí dùng cho doanh nghiệp nhỏ. Trong giai đoạn trước mắt, lựa chọn SQL Server làm cơ sở dữ liệu vì nó khá phổ biến, các công cụ quản trị mạnh, dễ sử dụng, sẽ tiết kiệm thời gian phát triển. Tuy nhiên, trong tương lai, hệ thống có thể mở rộng để làm việc được trên nhiều hệ quản trị cơ sở dữ liệu nếu khách hàng cần.
3.3.1.2. Công nghệ web - DotNetNuke
Trong số các frame work cho web hiện nay, DotNetNuke là một trong những framework mã nguồn mở, miễn phí (cả cho thương mại và phi thương mại), rất mạnh cho các ứng dụng web, sử dụng web 2.0, có tính tích hợp cao dựa trên kiến trúc mô đun. DotNetNuke được quản lý và hỗ trợ bởi Công ty DotNetNuke. Đồng thời vì là mã nguồn mở, khá nổi tiếng, nên nó cũng được hỗ trợ bởi lực lượng đông đảo các cộng đồng trên toàn thế giới. Các công ty và cá nhân đều có thể hỗ trợ, chia sẻ các tài nguyên sẵn sàng trên web site của DotNetNuke, blog và bất kỳđâu. Chuẩn mô đun của DotNetNuke là một tính năng đặc biệt. Nó cho phép nhà phát triển độc lập viết mô đun sau đó đưa vào chung một framework DotNetNuke để tích hợp và sử dụng.
Các công nghệđược sử dụng:
DotNetNuke được kế thừa từ dự án IBuySpy Portal Solution Kit. Các công nghệ chính được dùng để viết nên DotNetNuke là:
• Windows 2000 Server, Windows 2003 Server
• ASP.NET
• Visual Basic .NET
• Web Forms
• Microsoft Internet Information Services
• ADO.NET
• Microsoft SQL Server 2000
Đồng thời, trong DotNetNuke cũng thực thi một số Design Pattern cốt lõi như Provider Model, Custom Business Objects and Controller,...
Sơđồ kiến trúc ứng dụng DotNetNuke: theo kiến trúc 3 lớp truyền thống [23]
Hình 33 - Kiến trúc DotNetNuke
Cách thức truy xuất cơ sở dữ liệu thông qua cơ chế:
Hình 34 - Mô hình DataProvider
Mô hình gọi tới CBO Hydrator để open DataReader và kiểu đối tượng để fill.
Hình 35 - Mô hình CBO Hydrator để Fill Object/Collection
Khả năng xây dựng và tích hợp dựa trên các mô đun, dễ dàng tuỳ biến giao diện bằng skin:
Hình 36 - Mô hình hoạt động mô đun
Hình 37 - Màn hình DotNetNuke khi xem
Hình 38 - Màn hình DotNetNuke khi thiết kế
Vì vậy, việc sử dụng DotNetNuke làm môi trường xây dựng ứng dụng web là một lợi thế rất lớn, tiết kiệm nhiều thời gian và công sức. Nó cung cấp sẵn môi trường tích hợp các chức năng phổ biến của một ứng dụng web và portal cho người dùng mà không cần xây dựng lại.
3.3.1.3. Kết luận về lựa chọn công nghệ
Tóm lại, các công nghệđược lựa chọn để xây dựng hệ thống gồm:
• Ngôn ngữ lập trình: Micrsoft Visual Studio 2005/2008.
• Cơ sở dữ liệu: Trước mắt chọn SQL Server làm CSDL ngầm định. Định hướng cho phép sử dụng các CSDL khác về sau.
• Framework: sử dụng web portal DotNetNuke.
3.3.2. Thiết kế chương trình 3.3.2.1. Tổ chức các project
Toàn bộ chương trình được tổ chức thành các project sau:
STT Tên Kiểu Mô tả
1. QTestDNN Web Web project DotNetNuke, giao diện của toàn ứng dụng
2. QTestWS Service Webservice ngân hàng câu hỏi và quản lý thi. Dạng Windows NT Service, cung cấp Dịch vụ web self-host.
3. QTestBank_BL DLL BusinessLogic cho mô đun ngân hàng câu hỏi, được gọi tới từ QTestWS
4. QTestBank_DAL DLL DataAccessLayer cho mô đun ngân hàng câu hỏi, được gói tới từ QTestBank_BL 5. QTestBankWS_Caller DLL Công cụ để tạo lời gọi tới dịch vụ web
QTestBankWS để cung cấp cho QTestDNN
6. QTestBank_ObjectInfo DLL Thư viện các đối tượng cho mô đun Ngân hàng câu hỏi
7. QTestTest_BL DLL BusinessLogic cho mô đun quản lý thi, được gọi tới từ QTestWS
8. QTestTest_DAL DLL DataAccessLayer cho mô đun quản lý thi, được gói tới từ QTestTest_BL
9. QTestTestWS_Caller DLL Công cụ để tạo lời gọi tới dịch vụ web QTestTestWS để cung cấp cho QTestDNN
10. QTestTest_ObjectInfo DLL Thư viện các đối tượng cho mô đun Quản lý thi
11. QTestCommon DLL Thư viện một số lớp dùng chung trong toàn solution
Bảng 4 - Bảng cấu trúc các project Hệ thống thi trắc nghiệm
3.3.2.2. Thiết kế giao diện
Màn hình giao diện của một số chức năng chính:
3.3.3. Thiết kế cơ sở dữ liệu
3.3.4. Thiết kế lời gọi REST
Các lời gọi REST cho dịch vụ web ngân hàng câu hỏi:
STT Verb URI Ý nghĩa
1. GET /qg/lst/root Lấy danh sách các nhóm câu hỏi gốc đầu tiên (không có parent)
2. GET /qg/lst/{qgid_cha} Lấy danh sách các nhóm câu hỏi có mã nhóm câu hỏi cha là qgid_cha
STT Verb URI Ý nghĩa
3. GET /qg/i/{qgid} Lấy thông tin chi tiết của nhóm câu hỏi có mã nhóm câu hỏi là qgid.
4. GET /q/lst/{qgid} Lấy danh sách các câu hỏi có mã nhóm câu hỏi là qgid
5. GET /q/i/{qid} Lấy thông tin chi tiết của câu hỏi có mã câu hỏi là qid
6. GET /fq/i/{qid} Lấy thông tin chi tiết đầy đủ của câu hỏi (có cả trả lời kèm theo) có mã câu hỏi là qid
7. GET /q/rnd/lst/{qgid}/{rnd_n}/ {dkmin}/{dkmax}/{rcs}
Lấy ngẫu nhiên các câu hỏi có mã nhóm câu hỏi là qgid (qgid=”all” là không phân biệt nhóm nào), rnd_n là số câu lấy ngẫu nhiên, dkmin-dkmax là từ độ khó nào – độ khó nào (=0-0 nếu không xét độ khó), rcs là có đệ quy tới các nhóm con không (=1: là có, 0: là không).
8. PUT /q/test Gửi lên một list các câu trả lời kèm trong message để yêu cầu kiểm tra kết quả.
Kết quả trả về là string, gồm chuỗi các kết quả kiểu int phân tách bởi dấu phẩy (,). Trong đó, mỗi phần tử thứ i, nếu =0 là câu thứ i đúng, =1 là sai, =2 là không tìm thấy câu hỏi có mã tương ứng.
9. PUT /qg/ud/{qgid} Sửa thông tin của nhóm câu hỏi có mã nhóm là qgid.
Trả kết quả qua HTTP Status Code. 10. PUT /qg/sttud/{qgid}/
{stt_new}
Cập nhật STT của nhóm câu hỏi có mã nhóm là qgid thành số thứ tự mới là stt_new.
Trả kết quả qua HTTP Status Code. 11. PUT /fq/ud/{qid} Sửa thông tin của câu hỏi có mã câu
hỏi là qid.
Trả kết quả qua HTTP Status Code.
12. POST /qg/nw Thêm mới nhóm câu hỏi theo data kèm
theo.
STT Verb URI Ý nghĩa
Trả kết quả qua HTTP Status Code, kèm thêm mã câu hỏi dạng string. 13. POST /fq/nw Thêm mới câu hỏi. Tương tự trên. 14. DEL /qg/de/{qgid} Xóa nhóm câu hỏi có mã nhóm câu hỏi
là qgid.
Trả kết quả qua HTTP Status Code. 15. DEL /fq/de/{qid} Xóa câu hỏi có mã câu hỏi là qid.
Trả kết quả qua HTTP Status Code.
Bảng 5 - Bảng thiết kế lời gọi REST
Ký hiệu viết tắt:
• qg: question group – nhóm câu hỏi
• q: question – câu hỏi
• rnd: random – ngẫu nhiên
• rcs: recursion – đệ quy
• fq: full question – thông tin đầy đủ của câu hỏi
• i: info – thông tin
• ud: update – cập nhật
• up: chuyển lên
• dn: down – chuyển xuống
• nw: new – thêm mới
• de: delete – xóa
3.3.5. Một số hình ảnh chương trình
Hình 39 - Giao diện chính quản lý ngân hàng câu hỏi
Hình 40 - Giao diện thêm/sửa nhóm
Hình 41 - Giao diện thêm/sửa câu hỏi
Hình 42 - Giao diện tự kiểm tra trắc nghiệm
Hình 43 - Màn hình dịch vụ web nhận được yêu cầu kiểu REST
PHẦN 3: THẢO LUẬN VÀ KẾT LUẬN
THẢO LUẬN VÀ KẾT LUẬN
Qua quá trình nghiên cứu về kiến trúc phần mềm, SOA, các chuẩn web được trình bày trong Phần 1 và áp dụng thực tế vào hệ thống thi trắc nghiệm ở Phần 2 của luận văn, có thể rút ra một sốđiểm kết luận như sau:
• Kiến trúc phần mềm là gì? Kiến trúc phần mềm là một thiết kế mức cao của toàn bộ hệ thống phần mềm, biểu diễn toàn cảnh cấu trúc và các quan hệ giữa các thành phần trong hệ thống. Một cách để thể hiện rõ nét kiến trúc phần mềm là mô hình 4+1 khung nhìn.
• SOA là gì? SOA là một kiểu kiến trúc phát triển mức cao hơn so với kiểu kiến trúc khách - chủ (client - server). Lúc này, khái niệm chủ (server) được thay bằng khái niệm dịch vụ (service) và một loạt các nguyên tắc xoay quanh dịch vụ. Trong đó, có ba nguyên tắc cốt lõi là kết nối lỏng lẻo, trừu tượng hoá và thoả ước dịch
vụ.
• Tại sao sử dụng SOA? Một trong những lợi ích rất lớn của SOA đó là khả năng tích hợp hoặc cung cấp dịch vụ tốt. Một hệ thống được thiết kế và xây dựng theo đúng các nguyên tắc của SOA sẽ cho phép các hệ thống khác kết nối đến và sử dụng dịch vụ một cách dễ dàng, không phân biệt nền tảng thực thi hoặc ngôn ngữ lập trình sử dụng. Kiến trúc SOA cho phép phân chia về vật lý đầy đủ của kiến trúc 3 tầng. Tầng nghiệp vụ có thểđược tách hẳn ra đểđưa vào trong tầng dịch vụ, chạy trên máy chủ độc lập với tầng dữ liệu và tầng trình diễn. Sự chuẩn hóa của dịch vụ, cho phép phát triển một cách đa dạng tầng trình diễn (với các kiểu như ứng dụng desktop, ứng dụng web, ứng dụng trên mobile,...) cũng như kết hợp của nhiều dịch vụ lại với nhau.
• Khi nào sử dụng SOA? SOA có nhiều lợi ích nhưng không hẳn bài toán nào cũng cần áp dụng SOA. Lý do bởi SOA khá cồng kềnh và cần có sựđầu tư lớn. Thông thường SOA sẽ thích hợp với các hệ thống quản lý doanh nghiệp, trong đó có nhiều thành phần ứng dụng cần có sự tích hợp và trao đổi thông tin với nhau. SOA cũng đặc biệt phù hợp cho nhưng hệ thống cung cấp dịch vụ trên mạng (ví dụ như dịch vụ bán thông tin, dịch vụ chuyển tiền qua ngân hàng,...).
• Làm thế nào áp dụng SOA? Hiện nay, đã có rất nhiều công cụ hỗ trợ phát triển SOA, điển hình là sử dụng dịch vụ web SOAP hoặc REST. Xu hướng tương lai, thế giới đang nghiêng nhiều về REST với kiểu kiến trúc WOA. Có thể nói WOA là một tập con của SOA.
• Các chuẩn web là gì và ý nghĩa? Với sự phát triển của web, có rất nhiều hãng sản xuất các công cụ phát triển phần mềm, các ứng dụng và trình duyệt web (nổi tiếng như Microsoft, Sun, Oracle,...). Để đảm bảo thống nhất và tính tương thích giữa các phần mềm, có các tổ chức chuyên về chuẩn hoá trên thế giới (như W3C, IETF, ISO, ECMA) đứng ra kiểm duyệt và công bố các chuẩn hoặc khuyến nghị này (điển hình như các chuẩn về HTML, XHTML, CSS, ECMAScript, DOM). Việc
hiểu và áp dụng các chuẩn web trong quá trình phát triển web sẽ tạo ra nhiều lợi ích về khả năng sử dụng được rộng rãi, hiệu năng hệ thống và quá trình bảo trì sản phẩm được tốt hơn, giảm thiểu chi phí và thời gian.
• Kết quả thực tế của Hệ thống thi trắc nghiệm đạt được gì?:
- Việc xây dựng hệ thống thi trắc nghiệm theo cách truyền thống thì đơn thuần là tạo ra được ứng dụng để chạy trong một phạm vi khép kín (Công ty, Trường học,...). Khi triển khai theo SOA, ý nghĩa của nó trở nên lớn hơn nhiều. Một mặt nó vẫn đáp ứng nhu cầu sử dụng riêng rẽ, nội bộ trong một Đơn vị. Mặt khác nó có thể phát triển lên để tạo ra các dịch vụ cung cấp ngân hàng câu hỏi, dịch vụ tổ chức thi trên mạng (Internet/WAN/Intranet). Một Đơn vị có uy tín có thể đứng ra để quản lý ngân hàng câu hỏi và bán dịch vụ cho các khách hàng. Các khách hàng có thể lựa chọn mua dịch vụ mà không cần đầu tư nhiều (như về nhân sự, thiết bị) hoặc biết nhiều kiến thức về lĩnh vực đó nhưng vẫn có thể tổ chức thi được (với điều kiện tuân thủ đúng định dạng chuẩn thông điệp của nhà cung cấp dịch vụ trao đổi trong hệ thống). Đề thi được tạo ngẫu nhiên trong ngân hàng với rất nhiều câu hỏi và việc chấm thi cũng thực hiện tự động bởi dịch vụ cung cấp. Điều này đảm bảo không cần thiết phải lộ ngân hàng câu hỏi cho các khách hàng mà vẫn đáp ứng được yêu cầu thi. Đó có thể xem là một trong những lợi ích lớn mà SOA có thểđem lại.
- Hệ thống thi trắc nghiệm được viết theo kiểu kiến trúc REST. Trong đó, phần cung cấp dịch vụ được viết bằng dịch vụ web REST và phần khai thác dịch vụ được viết bằng web, sử dụng công nghệ DotNetNuke. Việc áp dụng kiểu kiến trúc này khá mới mẻ so với cách viết phần mềm hiện nay. Kết quả cho thấy hệ thống phần mềm hoạt động thông suốt, tốt.
---
TÀI LIỆU THAM KHẢO
1. Albin S.T. (2003), The Art of Software Architecture: Design Methods and
Techniques, Wiley Publishing, Inc.
2. Bass L., Clements P., Kazman R. (2003), Software Architecture in Practice,
Second Edition, Addison Wesley.
3. Erl T. (2005), Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall PTR.
4. ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description
of Software-Intensive Systems,
5. Fielding R.T. (2000), Architectural Styles and the Design of Network-based
Software Architectures, University of California, Irvine, degree of Doctor of
Philosophy in Information and Computer Science.
6. Garlan D., Shaw M. (1993), An Introduction to Software Architecture, Advances in
Software Engineering and Knowledge Engineering, Volume I, World Scientific.
7. Gorton I. (2006), Essential Software Architecture, Springer.
8. Gross C. (2006), Ajax and REST Recipes A Problem-Solution Approach, Apress. 9. Gross C. (2006), Ajax Patterns and Best Practices, Apress.
10.Hartman B., Flinn D. J. , Beznosov K., Kawamoto S. (2003), Mastering Web
Services Security, Wiley Publishing, Inc.
11.Hasan J., Duran M. (2006). Expert Service-Oriented Architecture in C# 2005 -