Nghiên cứu đề xuất mẫu thiết kế cho việc phát triển phần mềm trong môi trường điện toán đám mây

ĐẠI HỌC QUỐC GIA TP. HCM
TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN

NGÔ HUY BIÊN

NGHIÊN CỨU ĐỀ XUẤT MẪU THIẾT KẾ CHO VIỆC PHÁT TRIỂN PHẦN
MỀM TRONG MƠI TRƯỜNG ĐIỆN TỐN ĐÁM MÂY

Chun ngành: Khoa học máy tính
Mã số: 62.48.01.01

TĨM TẮT LUẬN ÁN TIẾN SĨ KHOA HỌC MÁY TÍNH

Tp. Hồ Chí Minh năm 2017


Cơng trình được hồn thành tại: Trường Đại học Khoa học Tự Nhiên-HCM
Người hướng dẫn khoa học: PGS. TS. Trần Đan Thư
Phản biện 1: PGS.TS. Quản Thành Thơ
Phản biện 2: TS. Phạm Văn Hậu
Phản biện 3: TS. Nguyễn An Tế
Phản biện độc lập 1: PGS.TS. Quản Thành Thơ
Phản biện độc lập 2: PGS.TS. Nguyễn Tấn Khôi

Luận án sẽ được bảo vệ trước Hội đồng chấm luận án cấp cơ sở đào tạo họp tại trường Đại học
Khoa học Tự Nhiên-HCM
vào hồi
giờ
ngày
tháng
năm

Có thể tìm hiểu luận án tại thư viện:
1. Thư viện Tổng hợp Quốc gia Tp.HCM
2. Thư viện trường Đại học Khoa học Tự Nhiên-HCM


Dẫn nhập
Để thiết kế thành công các hệ thống phần mềm, đặc biệt là các phần mềm doanh nghiệp, các kiến trúc sư
cần được trang bị các kiến thức về lĩnh vực (domain knowledge), các phương pháp thiết kế, các kinh nghiệm thiết
kế và hiện thực hóa phần mềm.
Mẫu thiết kế là một trong các hướng tiếp cận hiệu quả cho việc nâng cao chất lượng và rút ngắn thời gian
thiết kế bằng cách tái sử dụng các tri trức và kinh nghiệm thiết kế. Về mặt kỹ thuật, mẫu thiết kế là một tài liệu mô
tả một vấn đề lặp lại thường xuyên khi thiết kế phần mềm trong một hồn cảnh đặc thù và một mơ hình tổng quát
đã được chứng minh là giải pháp hiệu quả cho vấn đề đề cập. Tính hiệu quả của việc áp dụng mẫu thiết kế cho các
phần mềm truyền thống đã được chứng thực qua thời gian.
Hiện nay, hầu hết các doanh nghiệp và tổ chức đều dựa trên các hệ thống phần mềm để vận hành các hoạt
động kinh doanh và quy trình nghiệp vụ phức tạp. Việc di chuyển các hệ thống này từ mạng nội bộ (on-premises
software) lên môi trường đám mây là điều tất yếu do lợi ích to lớn trong việc giảm chi phí mở rộng và vận hành hệ
thống. Ngoài ra, việc xây dựng các phần mềm mới trong đám mây nhằm đáp ứng các nhu cầu nghiệp vụ khác nhau
cũng là một lựa chọn của nhiều doanh nghiệp và nhà cung cấp phần mềm do sự dễ dàng trong việc phân phối sản
phẩm đến người dùng cuối và khả năng chia sẻ chi phí sở hữu và vận hành giữa các người dùng với nhau.
Tuy nhiên, việc thiết kế các hệ thống phần mềm, đặc biệt là các ứng dụng trong môi trường đám mây là
một thách thức lớn đối với các kiến trúc sư. Nguyên nhân là do sự khác biệt rất lớn giữa một hệ thống phần mềm
dành cho hàng ngàn công ty cùng hàng trăm triệu người cùng sử dụng với một hệ thống phần mềm được dùng bởi
vài trăm nhân viên trong mạng nội bộ của một công ty hay một phần mềm cài đặt trên máy một người dùng. Nhu
cầu nghiên cứu phát hiện các mẫu thiết kế hỗ trợ phát triển các hệ thống phần mềm trong môi trường đám mây, đặc
biệt là các hệ thống phần mềm quản trị ngân hàng, thương mại điện tử, quản trị nhân lực, kết nối, trao đổi thông tin
hay bản đồ trở nên ngày càng cấp thiết. Các mẫu thiết kế mới này sẽ giúp bảo đảm chất lượng và nâng cao hiệu
suất của quá trình phát triển các loại phần mềm này trong mơi trường đám mây.
Đã có những đề xuất khởi đầu về việc nghiên cứu tìm kiếm và áp dụng mẫu thiết kế cho việc phát triển

phần mềm trong môi trường đám. Tuy nhiên, các mẫu thiết kế cho từng loại phần mềm đặc thù trong môi trường
đám mây, ví dụ như phần mềm doanh nghiệp, phần mềm đa người thuê, chưa được phát hiện và tài liệu hóa đầy đủ.
Chi tiết kỹ thuật để xây dựng các phần mềm đám mây cũng chưa được làm rõ. Tiếp tục hướng nghiên cứu này luận
án nghiên cứu tìm hiểu và đề xuất các mẫu thiết kế hỗ trợ việc phát triển phần mềm trong môi trường đám mây.
Luận án tập trung vào các phần mềm đa người thuê, các chi tiết kỹ thuật và sự tương đối độc lập của giải pháp đối
với công nghệ của các nhà cung cấp dịch vụ đám mây đặc thù.
Đóng góp của luận án là bốn mẫu thiết kế nhằm giúp các nhà phát triển phần mềm rút ngắn thời gian và chi
phí khi hiện thực hóa các hệ thống phần mềm trong môi trường đám mây, đặc biệt là phần mềm đa người thuê.
Ngoài ra luận án cũng cung cấp một bản nghiên cứu tổng quan về hiện trạng mẫu thiết kế hỗ trợ phát triển phần
mềm trên các hệ thống điện toán đám mây.

1


Chương 1 Mở đầu
1.1.

Động cơ nghiên cứu
Mục đích của luận án là tìm hiểu các vấn đề phát sinh khi phát triển phần mềm trong môi trường đám mây,

đặc biệt là phần mềm doanh nghiệp cung cấp dạng dịch vụ, đặc thù hơn nữa là phần mềm doanh nghiệp đa người
thuê; đề xuất các giải pháp tổng quát cho các vấn đề dưới dạng các mẫu thiết kế nhằm mục đích tái sử dụng, đảm
bảo chất lượng và nâng cao hiệu suất trong quá trình xây dựng phần mềm trong môi trường đám mây. Các mẫu
thiết kế này là các tri thức được tổng quát hóa, có thể tùy biến cho phù hợp với từng hoàn cảnh cụ thể. Các mơ hình
của các mẫu thiết kế này đóng vai trị như các kiến trúc tham khảo giúp các kiến trúc sư đưa ra các quyết định thiết
kế phù hợp khi xây dựng phần mềm trên các hệ thống điện toán đám mây.
Các mẫu thiết kế này sẽ giúp việc xây dựng hay chuyển đổi các hệ thống truyền thống lên đám mây đạt
được chất lượng cao hơn với chi phí thấp hơn, giúp các nhà phát triển tăng chất lượng, tiết kiệm thời gian, chi phí
xây dựng, triển khai, tích hợp, bảo trì và mở rộng phần mềm. Đồng thời các mẫu thiết kế này cũng sẽ giúp các nhà
nghiên cứu liên lạc, trao đổi thảo luận về các vấn đề phát sinh và giải pháp khi xây dựng các ứng dụng đám mây dễ

dàng hơn.

1.2.

Mục tiêu nghiên cứu
Từ các kết quả nghiên cứu hiện trạng và nhu cầu thực tế của các tổ chức liên quan luận án đặt ra mục tiêu

là phát hiện, tài liệu hóa được bốn mẫu thiết kế hỗ trợ phát triển các hệ thống doanh nghiệp, đặc biệt là các phần
mềm đa người thuê trong môi trường đám mây; thử nghiệm và rút ra các bài học kinh nghiệm khi áp dụng các mẫu
thiết kế này. Về mặt nghiệp vụ, luận án tập trung vào các mẫu thiết kế cho các phần mềm doanh nghiệp. Về mặt kỹ
thuật, luận án tập trung vào các mẫu thiết kế hỗ trợ phát triển các hệ thống phần mềm ở tầng ứng dụng của điện
toán đám mây. Luận án tập trung giải quyết các vấn đề về kiến trúc tổng quan, sự tùy biến, tính mở rộng và bảo
mật của các hệ thống phần mềm đa người th.
Hỗ trợ mơ hình đa người th bằng một hệ thống phần mềm triển khai trong môi trường đám mây với một
bộ mã nguồn và cơ sở dữ liệu duy nhất, sử dụng chung bởi nhiều tổ chức, giải quyết các vấn đề trong hệ thống
phần mềm đa người thuê và tận dụng các dịch vụ của điện toán đám mây khi hiện thực hóa mẫu thiết kế là điểm
đặc trưng của các mẫu thiết kế luận án đề xuất so với các mẫu thiết kế truyền thống.

1.3.

Phương pháp nghiên cứu
Luận án được thực hiện dựa vào phương pháp nghiên cứu trường hợp (case study research method) được

tùy biến cho lĩnh vực kỹ nghệ phần mềm. Nguồn tri thức cơ sở hay lý thuyết nền tảng của luận án là các nghiên cứu
đã thực hiện về mẫu thiết kế cho việc phát triển phần mềm trong môi trường đám mây. Các vấn đề nghiên cứu, yêu
cầu cụ thể và câu hỏi nghiên cứu đến từ các hệ thống phần mềm đám mây mà chúng tôi đã và đang phát triển cho
các tổ chức và doanh nghiệp. Các hệ thống phần mềm mở và thương mại cùng với các dự án mà chúng tôi đã và
đang phát triển và các công trình nghiên cứu khoa học đã được thực hiện là đối tượng nghiên cứu của luận án. Kết
quả nghiên cứu của luận án là các mẫu thiết kế trả lời cho các câu hỏi nghiên cứu.
Việc đánh giá các mẫu thiết kế đề xuất được thực hiện dựa trên các tình huống thực tế (cases) mà mẫu thiết

kế giải quyết. Hai tiêu chí chính được lựa chọn để đánh giá là tính khả dụng (applicability) và tính đúng đắn
(correctness). Tính khả dụng của các mẫu thiết kế đề xuất được đánh giá thông qua việc áp dụng mẫu thiết kế vào
các hệ thống phần mềm thực tế và rút ra các bài học kinh nghiệm. Tính đúng đắn các mẫu thiết kế đề xuất được
đánh giá bằng cách kiểm thử các hệ thống phần mềm dựa trên các yêu cầu nghiệp vụ đề ra.
Ngồi ra việc đánh giá cịn được thực hiện bằng cách phân tích hệ quả của một số đặc tính chất lượng khác
(ví dụ như tính dễ sử dụng, tính tái sử dụng, khả năng bảo trì, khả năng chỉnh sửa) dựa trên các mẫu thiết kế truyền
2


thống được áp dụng hoặc hiệu chỉnh mở rộng trong mẫu thiết kế đề xuất cho môi trường đám mây. Việc áp dụng và
hiệu chỉnh mở rộng các mẫu thiết kế phổ biến và đã được kiểm chứng qua thời gian góp phần đảm bảo các mẫu
thiết kế đề xuất tuân theo các nguyên lý thiết kế tổng quát. Các mẫu thiết kế cũng được viết thành các bài báo khoa
học và gửi đến các hội nghị khoa học quốc tế để thu nhận ý kiến phản biện của các chuyên gia và nhà nghiên cứu
trong và ngoài nước. Các bài báo khoa học đã được xuất bản và tham chiếu bởi các cơng trình nghiên cứu khác. Sự
hợp lệ về khái niệm, sự hợp lệ bên ngoài và sự tin cậy của các kết quả nghiên cứu được hỗ trợ bằng cách áp dụng
các chiến lược đề xuất bởi phương pháp nghiên cứu trường hợp.

1.4.

Đóng góp của luận án
Thơng qua các kết quả đạt được, luận án đã có những đóng góp chính sau:
•

Mẫu thiết kế “Người th phân cấp”: hỗ trợ mơ hình hóa người th phân cấp, định danh, phân
quyền việc truy cập các tài nguyên của hệ thống đa người thuê phân cấp.

•

Mẫu thiết kế “Hệ thống giao dịch”: hỗ trợ mơ hình các kiến thức về lĩnh vực một cách nhất quán
và xử lý việc thực thi các giao dịch một cách bảo mật theo một cung cách nhất quán.

•

Mẫu thiết kế “Khung ứng dụng web”: giúp các kiến trúc sư và các nhà phát triển phần mềm
đánh giá, lựa chọn hoặc xây dựng một khung ứng dụng web với khả năng hỗ trợ đa người thuê, mở
rộng mà không bị trùng lắp mã nguồn, tách biệt các mối quan tâm, cho phép phát triển và tái sử
dụng các mô đun với khả năng “cắm-chạy” khi thực thi.

•

Mẫu thiết kế “Tùy biến giao diện”: hỗ trợ xây dựng sự tùy biến cho giao diện đồ họa người dùng
trong phần mềm đa người thuê.

Ngoài ra luận án cũng cung cấp một báo cáo hiện trạng nghiên cứu mẫu thiết kế trong mơi trường đám mây
góp phần hỗ trợ các nhà nghiên cứu và những người quan tâm có cái nhìn tổng quan khi thực hiện các nghiên cứu
về mẫu thiết kế trong mơi trường điện tốn đám mây.
Các kết quả đạt được ở trên đã được công bố và xuất bản ở các hội nghị trong nước và quốc tế. Ngoài ra
các mẫu thiết kế đề xuất cũng đã được triển khai vào sáu hệ thống đa người thuê thực tiễn với tổng số hơn 3,500
khách hàng (người thuê) và 350,000 người dùng.

1.5.

Nội dung luận án
•

Chương 1 trình bày động cơ, mục tiêu, phương pháp nghiên cứu và đóng góp của luận án.

•

Chương 2 trình bày tổng quan tri thức nền tảng liên quan đến thiết kế phần mềm và mẫu thiết kế.

•

Chương 3 trình bày chi tiết động cơ, câu hỏi nghiên cứu, cơng trình liên quan, giái pháp, đánh giá
và hướng phát triển của mẫu thiết kế người th phân cấp.

•

Chương 4 trình bày chi tiết động cơ, câu hỏi nghiên cứu, cơng trình liên quan, giái pháp, đánh giá
và hướng phát triển của mẫu thiết kế hệ thống giao dịch.

•

Chương 5 trình bày chi tiết động cơ, câu hỏi nghiên cứu, cơng trình liên quan, giái pháp, đánh giá
và hướng phát triển của mẫu thiết kế khung ứng dụng web.

•

Chương 6 trình bày chi tiết động cơ, câu hỏi nghiên cứu, cơng trình liên quan, giái pháp, đánh giá
và hướng phát triển của mẫu thiết kế tùy biến giao diện.

•

Chương 7 tổng kết các kết quả nghiên cứu và xác định các hướng nghiên cứu mở rộng cho luận
án.

3


Chương 2. Mẫu thiết kế phần mềm

2.1.

Thiết kế phần mềm
Thiết kế đóng vai trị thiết yếu trong kỹ nghệ phần mềm vì đây là hoạt động cầu nối giữa hai thế giới: thế

giới con người với các nhu cầu của thế giới thực và thế giới công nghệ với việc thỏa mãn các nhu cầu thực tế bằng
phần mềm. Thiết kế vừa là một hoạt động mang tính khoa học vửa là một hoạt động mang tính nghệ thuật sáng tạo.
Sản phẩm của quá trình thiết kế phần mềm gồm hai loại. Một là các thuật toán, các cấu trúc dữ liệu dành cho việc
tính tốn. Hai là kiến trúc phần mềm. Một trong các phương pháp kích thích và truyền cảm hứng cho sự sáng tạo
trong việc thiết kế các phần mềm là áp dụng các kinh nghiệm thu được trong quá khứ và hiệu chỉnh lại cho vấn đề
hiện tại. Mẫu thiết kế nghiên cứu phương pháp này.

2.2.

Mẫu thiết kế
Tài liệu hóa và tái sử dụng lại cách giải quyết của người khác cho một vấn đề trong một hồn cảnh tương

tự sao cho giải pháp có thể áp dụng cho vấn đề trong hoàn cảnh hiện tại chính là ý tưởng của mẫu thiết kế. Mẫu
thiết kế là chìa khóa để rút ngắn thời gian và tăng chất lượng thiết kế bằng cách tái sử dụng các giải pháp có sẵn
cho các vấn đề lặp lại thường xuyên. Kết hợp các quan niệm về mẫu ở các cơng trình nghiên cứu đã thực hiện
chúng tơi đưa ra một quan niệm về mẫu thiết kế được sử dụng trong luận án như sau:
Mẫu thiết kế là một tài liệu mô tả một vấn đề và một giải pháp trong lĩnh vực thiết kế phần mềm. Vấn đề
bao gồm 3 phần là (i) hoàn cảnh, (ii) các yêu cầu ràng buộc và (iii) các ví dụ cụ thể về sự lặp lại thường xuyên của
vấn đề. Giải pháp bao gồm 3 phần là (i) ý tưởng tổng quát của giải pháp, (ii) các mơ hình và sự mơ tả, giải thích
cho các mơ hình để làm rõ nghĩa ý tưởng của giải pháp và (iii) các ví dụ cụ thể về các trường hợp áp dụng thành
công ý tưởng của giải pháp để giải quyết vấn đề ở ít nhất 3 hệ thống khác nhau. Mỗi mơ hình bao gồm 3 phần là (i)
mơ tả hồn cảnh đưa đến mơ hình, ngun nhân đưa ra các quyết định trong mơ hình, (ii) các hiện thực hóa của mơ
hình, các biến thể và (iii) thảo luận về các thỏa hiệp khi áp dụng mơ hình.

2.3.

Mơ tả và biểu diễn mẫu thiết kế
Một số nhà nghiên sử dụng một khuôn mẫu (template) với các thành phần cố định để mô tả mẫu thiết kế.

Phát triển ngơn ngữ hình thức để biểu diễn mẫu thiết kế và cho phép phát triển các công cụ hỗ trợ mẫu cũng đã
được nghiên cứu. Tuy nhiên, nhiều nhà nghiên cứu cho rằng việc hình thức hóa một vấn đề sẽ làm cho việc gắn kết
mẫu thiết kế với một vấn đề đặc thù khó hơn vì các vấn đề đặc thù thường là phi hình thức. Hình thức hóa một giải
pháp sẽ làm cho việc nắm bắt ý tưởng tổng quát của mẫu khó hơn và khơng cho phép có các biến thể.

2.4.

Mục đích của mẫu thiết kế
Mục đích cốt lõi của mẫu là tái sử dụng tri thức và kinh nghiệm thiết kế. Ngoài tính tái sử dụng mẫu cịn là

một cơng cụ giúp chuyển giao tri thức và kinh nghiệm thiết kế một cách rất hiệu quả.

2.5.

Áp dụng mẫu thiết kế
Kỹ nghệ phần mềm nói chung và thiết kế phần mềm nói riêng là hoạt động phụ thuộc rất nhiều vào sự sáng

tạo và khéo léo con người. Mẫu thiết kế có thể được áp dụng như một hướng tiếp cận độc lập cho việc thiết kế
(pattern-based design) hoặc kết hợp với các phương pháp thiết kế khác. Phát triển các công cụ hỗ trợ việc tự động
hóa việc khai thác mẫu cũng được nhiều nhà nghiên cứu quan tâm.

4


2.6.

Phát hiện và tài liệu hóa mẫu thiết kế
Cơng nghệ và phương pháp phát triển phần mềm thay đổi liên tục theo từng ngày, các vấn đề mới luôn xuất

hiện ngày một nhiều trong khi các mẫu thiết kế có sẵn thì ln giới hạn. Do vậy, thường xun có nhu cầu về các
mẫu mới để giải quyết các vấn đề vừa nảy sinh. Để đưa ra các mẫu mới địi hỏi cần có sự đầu tư nghiên cứu về mẫu
đối với các vấn đề mới nảy sinh, sau đó tổng kết và tài liệu hóa lại các giải pháp. Ngồi việc tìm kiếm các mẫu mới,
các nhà nghiên cứu còn tập trung vào việc tái cấu trúc, hiệu chỉnh lại các mẫu cũ cho phù hợp với hiện tại. Một số
đóng góp chính cho việc phát hiện và tài liệu hóa mẫu thiết kế được trình bày trong Phụ Lục A của toàn văn luận
án.

2.7.

Mẫu thiết kế hỗ trợ phát triển phần mềm trong môi trường đám mây
Mẫu thiết kế đã được nghiên cứu nhiều trong việc phát triển các phần mềm truyền thống. Tương tự, trong

môi trường đám mây, mẫu thiết kế cũng được nhiều nhà nghiên cứu đề xuất như một hướng tiếp cận cho việc giải
quyết các vấn đề nảy sinh khi phát triển phần mềm. Tuy nhiên, trong lĩnh vực điện toán đám mây, mới chỉ tồn tại
một số đề xuất khởi đầu cho việc nghiên cứu mẫu thiết kế. Các nghiên cứu chỉ mới tập trung phần lớn vào các nhà
cung cấp dịch vụ đám mây đặc thù, các khía cạnh ứng dụng điện tốn đám mây, các mơ hình triển khai tổng qt.
Khía cạnh phần mềm, đặc biệt là phần mềm cung cấp dạng dịch vụ và mơ hình đa người th, chưa được quan tâm
đầy đủ. Chi tiết về một số đóng góp chính cho việc nghiên cứu mẫu thiết kế hỗ trợ phát triển phần mềm trong môi
trường đám mây được chúng tơi trình bày trong Phụ lục D của tồn văn luận án.

2.8.

Đánh giá mẫu thiết kế
Do đặc tính cố hữu trong việc thể hiện mẫu thiết kế như một tài liệu với các sơ đồ và sự mô tả (dữ liệu định

tính), việc đánh giá các mẫu thiết kế hiện nay đều dựa trên các nghiên cứu trường hợp và nhận xét định tính của các
chuyên gia. Bản thân tài liệu đặc tả mẫu thiết kế cần bao gồm mơ tả ít nhất 3 trường hợp thực tế đã sử dụng mẫu để

giải quyết vấn đề một cách thành cơng. Ba trường hợp này đóng vai trị như một trong các bằng chứng để chứng
minh cho tính khả dụng của mẫu. Sau khi được tài liệu hóa như một ứng viên mẫu, mẫu thiết kế thường được áp
dụng vào các trường hợp thực tế theo phương pháp nghiên cứu trường hợp để đánh giá một số đặc tính chất lượng
như tính đúng đắn, tính khả dụng. Mẫu thiết kế đã được tài liệu hóa sau đó được gửi đến các hội thảo nghiên cứu
khoa học để nhận phản hồi và đánh giá từ các chuyên gia và nhà nghiên cứu nhiều kinh nghiệm.

2.9.

Hạn chế của mẫu thiết kế
Việc tài liệu hóa các mẫu thiết kế tiêu tốn nhiều thời gian. Các mẫu thiết kế có thể chưa phải là các giải

pháp chuẩn hay tốt nhất khi xây dựng các hệ thống phần mềm. Sự trừu tượng và biểu diễn phi hình thức của các
mẫu thiết kế làm cho việc hiện thực hóa mẫu bằng một cơng nghệ đặc thù không hỗ trợ hoặc hỗ trợ chưa tốt một số
khái niệm của mẫu trở nên khó khăn.

2.10. Tóm tắt
Chúng tơi vừa giới thiệu tổng quan về mẫu thiết kế nhằm làm rõ hơn hoàn cảnh, động cơ và phương pháp
nghiên cứu của luận án. Trong 4 chương tiếp theo chúng tơi sẽ trình bày đóng góp chính của luận án.

5


Chương 3. Mẫu thiết kế người thuê phân cấp
3.1.

Động cơ và câu hỏi nghiên cứu
Các hệ thống phần mềm đa người thuê đều cần quản lý người thuê và dữ liệu. Thiết kế người thuê và dữ

liệu là một công việc gặp nhiều thử thách, đặc biệt khi ứng dụng được triển khai trong môi trường đám mây với
một bộ mã nguồn và cơ sở dữ liệu duy nhất sử dụng chung bởi nhiều khách hàng. Vấn đề càng trở nên phức tạp

hơn khi đòi hỏi sự phân cấp đối với người thuê và sự phân cấp đối với dữ liệu. Hai vấn đề cần giải quyết khi quản
lý người thuê và dữ liệu phân cấp là (i) vấn đề mơ hình hóa người th và dữ liệu phân cấp và (ii) vấn đề kiểm soát
việc truy cập của người thuê vào tài nguyên hệ thống.
Câu hỏi nghiên cứu 1: Làm sao để thiết kế hệ thống hỗ trợ người thuê và tài nguyên phân cấp, cho phép
định danh một cách nhất quán cho cả người dùng cá nhân lẫn người dùng của người thuê, hỗ trợ phân quyền truy
cập vào tài nguyên hệ thống theo vai trò, người dùng và người th?

3.2.

Cơng trình liên quan
Vấn đề được đề cập trong câu hỏi nghiên cứu 1 liên quan đến nhiều khía cạnh của phần mềm đa người th

như mơ hình khái niệm, việc chứng thực và phân quyền, tốc độ, khả năng cấu hình và hiệu chỉnh.

3.3.

Giải pháp

3.3.1. Tổng quan về giải pháp
Giải pháp là sự mở rộng của mẫu Composite nhằm hỗ trợ người thuê phân cấp và mở rộng của mẫu RoleBased Access Control nhằm hỗ trợ phân quyền theo người thuê. Hình 3.4 thể hiện tổng quan về giải pháp của mẫu
thiết kế người thuê phân cấp.
Một tổ chức Organization chứa một số người dùng User. Một tổ chức phức hợp Composite Organiazation
là một tổ chức chứa các tổ chức đơn lẻ khác hoặc các tổ chức phức hợp khác. Mỗi người dùng của hệ thống được
cung cấp các thông tin ủy nhiệm để đăng nhập vào hệ thống. Mỗi người dùng có thể đảm nhiệm một hay nhiều vai
trị Role. Một tài ngun Resourse có thể là bất cứ thực thể nào của hệ thống. Một tài nguyên phức hợp Composite
Resource là một tài nguyên chứa các tài nguyên đơn lẻ khác hoặc các tài nguyên phức hợp khác.

Hình 3.4 – Tổng quan về mẫu thiết kế người thuê phân cấp
Quyền hạn Privilege là quyền truy cập vào một tài nguyên hệ thống đối với một người dùng. Quyền hạn
thường là một mức độ truy cập hay một hành động truy cập (ví dụ như đọc Read, chỉnh sửa Edit, xóa Delete, vân

6


vân). Việc kiểm soát truy cập của người dùng được thực hiện bởi đối tượng phân quyền Authorization. Đối tượng
phân quyền là sự kết hợp của người dùng User, vai trò Role, tổ chức Organization, tài nguyên Resource và quyền
hạn Privilege. Sử dụng các danh sách phân quyền, hệ thống có thể quyết định xem một người dùng có thể truy cập
hay thực hiện một hành động nào đó đối với một tài nguyên hay không.
3.3.2. Cấu trúc tĩnh
Một mô hình tiêu biểu cho cấu trúc tĩnh của mẫu thiết kế người thuê phân cấp được mô tả bởi lược đồ
UML trong hình 3.5.
Role
+RoleId : Guid
+Name : String
+Users : List<User>

<<enumeration>>

<<enumeration>>

Privilege

AccessorType

+None
+Create
+Delete
+Read
+FullControl

0..1

0..*
0..*
+member

1..*

Organization

0..1
0..1 0..1

+decision

+Resource : Resource
+AccessorType : AccessorType
+AccessorId : Guid
+Previlege : Previlege
+entity

0..*

1

Authorization

0..1

+UserId : Guid
+Username : Guid

+Password : String
+PrimaryOrganization :
Organization
+Organizations :
List<Organization>
+Roles : List<Roles>

0..1

+OrganizationId : Guid
+ThemeName : Guid
+Name : String
+Parent : Organization

+privilege

User

0..*
+container

1

+User
+Role
+Organization

1 +decision

Resource

+child

0..*

+ResourceId : Guid
+Name : String
+Parent : Resource

+parent

1

+child

1
SingleOrganization

CompositeOrganization

+parent
SingleResource

+ChildOrganizations :
List<Organization>

CompositeResource
+ChildResources :
List<Resource>

1

Hình 3.5 – Cấu trúc tĩnh của mẫu thiết kế người thuê phân cấp
3.3.3. Cấu trúc động
Hình 3.6 mơ tả quy trình xử lý việc truy cập vào các tài nguyên của hệ thống đối với một người dùng.
:Client

:System

:User

:AuthorizationDAO

:ResourceDAO

GetResources(username, password)
Create()
user
GetResources()

GetOrganizationAuthorizationList(user)
userOrganizationAuthorizationList
GetRoleAuthorizationList(user)
userRoleAuthorizationList
GetUserAuthorizationList(user)
userAuthorizationList
GetResources(authorizationList)

resourceList
resourceList

resourceList

Hình 3.6 – Cấu trúc động của mẫu thiết kế người thuê phân cấp

3.4.

Đánh giá

3.4.1. Phân tích và thảo luận
Đối với câu hỏi nghiên cứu 1 mẫu thiết kế người thuê phân cấp đã hỗ trợ người thuê phân cấp bằng mẫu
thiết kế Composite thông qua các đối tượng Orgnization, SingleOrgnization và CompositeOrgnization; hỗ trợ tài
nguyên phân cấp bằng mẫu thiết kế Composite thông qua các đối tượng Resource, SingleResource và
7


CompositeResource; cho phép định danh một cách nhất quán cho cả người dùng cá nhân lẫn người dùng của người
thuê thông qua đối tượng User và mối liên hệ giữa đối tượng User và Orgnization; hỗ trợ phân quyền truy cập vào
tài nguyên hệ thống theo vai trò, người dùng và người thuê thông qua đối tượng Authorization.
3.4.2. Nghiên cứu trường hợp
Mẫu thiết kế người thuê phân cấp đã được áp dụng trong 4 hệ thống phần mềm đa người thuê bao gồm hệ
thống thư điện tử bảo mật, hệ thống quản lý dự án, hệ thống quản lý thông tin doanh nghiệp và hệ thống quản lý
trường học.
Hệ thống thư điện tử bảo mật là một hệ thống phần mềm cung cấp các dịch vụ gửi thư điện tử với nội dung
được bảo mật trên đường truyền và nơi lưu trữ cho các cá nhân, công ty và đại lý. Hệ thống hoạt động tương tự như
thư điện tử truyền thống. Điểm khác biệt với thư điện tử truyền thống là nội dung của thư điện tử được mã hóa trên
đường truyền và tại nơi lưu trữ.
Các người thuê của hệ thống này được phân thành nhiều cấp. Một đại lý có thể có nhiều cơng ty. Một cơng
ty có thể có nhiều cơng ty con. Một cơng ty con có thể có nhiều cơng ty trực thuộc cấp dưới. Các dữ liệu dịch vụ
của hệ thống này là thư điện tử, thư mục lưu trữ thư điện tử, tập tin đính kèm thư điện tử, vân vân. Các dữ liệu này

cũng có sự phân cấp. Một thư điện tử có thể có nhiều thư điện tử trả lời. Một thư mục có thể có nhiều thư mục con.
Một tập tin có thể có nhiều phiên bản.
Hệ thống cung cấp nhiều dịch vụ khác nhau như gửi thư điện tử bảo mật, gửi thư điện tử bảo mật bằng
Outlook Add-in, sử dụng API để gửi thư điện tử bảo mật, xem các báo cáo, quản lý các công ty con, quản lý người
dùng của công ty, quản lý thông tin cấu hình của cơng ty, vân vân. Mỗi dịch vụ được cung cấp dưới dạng một mô
đun (Module). Các tính năng hoặc cấu hình của một mơ đun được truy cập thơng qua một trang web (Page).
Mơ hình nghiệp vụ của hệ thống thư điện tử bảo mật được mơ tả ở hình 3.7. Các đối tượng đại lý, công ty
con của đại lý, người dùng của đại lý và dịch vụ của đại lý được lược bỏ để dễ quan sát.
thuộc về

Người quản trị hệ thống
quản lý

quản lý

Công ty

quản lý
các
thiết lập
cấu hình

quản lý
Người dùng
của cơng ty

Người quản trị
của công ty

truy cập

quản lý
quản lý
quản lý
Người quản trị
đại lý
truy cập

Dịch vụ
(Trang và Mơ đun)

Người dùng cá nhân

Hình 3.7 – Mơ hình nghiệp vụ hệ thống thư điện tử bảo mật
Cách tiếp cận hiện nay đối với việc phân cấp thường là áp dụng mẫu thiết kế Composite. Tuy nhiên, hạn
chế của cách tiếp cận này là không hỗ trợ xử lý thẩm định các đối tượng phân cấp trong hệ thống. Mẫu người thuê
phân cấp mở rộng mẫu Composite bằng cách thêm đối tượng User để khắc phục các hạn chế trên.
Cách tiếp cận hiện nay đối với việc phân quyền thường là áp dụng mẫu thiết kế Role-Based Access
Control. Tuy nhiên, khi áp dụng cách tiếp cận này vào trong một hệ thống phần mềm đa người thuê thì mơ hình này
khơng thể phân biệt người dùng cá nhân với các nhân viên của tổ chức, cũng như nhân viên của một tổ chức này
với nhân viên của một tổ chức khác. Mẫu người thuê phân cấp khắc phục các hạn chế trên bằng cách sử dụng cả 3
đối tượng User, Role và Organization cho sự phân quyền thay vì chỉ dùng đối tượng Role như mẫu Role-Based
Access Control.
8


Áp dụng giải pháp của mẫu đa người thuê phân cấp, các người thuê được phân cấp thành các tổ chức và
các tổ chức phức hợp, các tổ chức phức hợp ở cấp độ đầu tiên được xem như các đại lý. Mỗi trang web hoặc mô
đun được xem như một tài nguyên. Một trang web có thể bao gồm nhiều trang con. Một trang web có thể có nhiều
mơ đun. Việc áp dụng mẫu đa người thuê phân cấp được thể hiện ở hình 3.8.

Áp dụng mơ hình đăng nhập của mẫu đa người thuê phân cấp, mỗi người dùng hệ thống được cung cấp
một tên và mật khẩu. Việc đăng nhập vào hệ thống được thực hiện nhất quán bất kể người dùng là người thuê cá
nhân hay nhân viên cơng ty. Áp dụng mơ hình phân quyền của mẫu đa người thuê phân cấp, Việc phân quyền truy
cập vào từng trang web hay mô đun được thiết lập theo từng người dùng, theo công ty hoặc theo đại lý hoặc theo
vai trò của người dùng.
Role
+RoleId : Guid
+Name : String
+Users : List<User>

<<enumeration>>

<<enumeration>>

Privilege

AccessorType

+None
+Create
+Delete
+Read
+FullControl

0..1

0..*
0..*
+member
0..*

0..1
+container

1..*

Organization
+OrganizationId : Guid
+ThemeName : Guid
+Name : String
+Parent : Organization

1

+privilege

User
+UserId : Guid
+Username : Guid
+Password : String
+PrimaryOrganization :
Organization
+Organizations :
List<Organization>
+Roles : List<Roles>

+User
+Role
+Organization

1

Authorization

0..1

+Resource : Resource
+AccessorType : AccessorType
+AccessorId : Guid
+Previlege : Previlege

0..1
0..1 0..1

+entity

0..*

1 +decision

Resource

+child

+ResourceId : Guid
+Name : String
+Parent : Resource

+parent

+decision

1

0..*
+child

1
SingleOrganization

+parent

CompositeOrganization

Module

+ChildOrganizations :
List<Organization>

Page
+ChildPages :
List<Resource>
+Modules :
List<Resource>

1

Hình 3.8 – Một phần cấu trúc tĩnh hệ thống thư điện tử bảo mật
3.4.3. Bài học kinh nghiệm
Từ các kết quả nghiên cứu các trường hợp và tổng hợp ý kiến của các chuyên gia chúng tôi rút ra một số
biến thể và kinh nghiệm kỹ thuật khi áp dụng mẫu thiết kế người thuê phân cấp. Mẫu người thuê phân cấp có thể có

một số biến thể tùy thuộc vào hồn cảnh áp dụng. Hình 3.5 khơng thể hiện sự liên hệ giữa giữa vai trò Role và tổ
chức Organization. Tất cả các tổ chức đều có cùng một số lượng vai trò. Trong thực tế mỗi tổ chức có thể có các
vai trị riêng đặc thù cho tổ chức của mình. u cầu này có thể được thực hiện bằng cách thêm mối liên hệ “có
một” vào giữa tổ chức và vai trị.
Trong một hồn cảnh khác khi có quá nhiều số lượng người dùng tương tự, các người dùng này có thể
được nhóm lại thành các nhóm đơn lẻ Single Group và các nhóm phức hợp Composite Group để dễ quản lý và
quân quyền. Tương tự, các vai trị có thể được phân loại thành các vai trò đơn lẻ Single Role và các vai trò phức
hợp Composite Role.

9


Dưới đây là một số kinh nghiệm về mặt kỹ thuật được chúng tơi rút ra khi hiện thực hóa mẫu thiết kế người
thuê phân cấp trong các hệ thống thực tế:
•

Mỗi người dùng, tổ chức, vai trị, hay tài nguyên cần có một định danh duy nhất để tham gia vào
quy trình phân quyền của hệ thống.

•

Việc lưu trữ dữ liệu có thể được thực hiện bằng cách sử dụng cơ sở dữ liệu quan hệ. Khi sử dụng
cơ sở dữ liệu quan hệ sự phân cấp có thể được mơ hình hóa bằng cách sử dụng các danh sách liền
kề hoặc các tập lồng nhau. Áp dụng danh sách liền kề địi hỏi đệ quy và có thể ảnh hưởng đến tốc
độ của hệ thống khi truy vấn dữ liệu (danh sách các phân quyền). Sử dụng tập lồng nhau khơng địi
hỏi đệ quy khi truy vấn dữ liệu nhưng tốc độ them dữ liệu vào chậm hơn là sử dụng danh sách liền
kề. Ngoài ra cơ sở dữ liệu NoSQL hoặc XML cũng có thể sử dụng để lưu trữ dữ liệu. Việc phân
cấp được hỗ trợ ngay trong bản chất của NoSQL và XML.

•

Mỗi sự phân quyền cần có ít nhất một tài ngun với một người dùng hoặc một tài nguyên với một
vai trò hoặc một tài nguyên với một tổ chức. Để tiện cho việc sử dụng các danh sách phân quyền,
hệ thống có thể định nghĩa sẵn các mơ hình phân quyền mặc định và hỗ trợ sự kế thừa mơ hình
phân quyền truy cập từ một tài nguyên cha đối với một tài nguyên con. Khi đó nếu một người dùng
chưa được cấp quyền đối với một tài nguyên thì hệ thống sẽ sử dụng sơ đồ phân quyền mặc định
hoặc sử dụng sơ đồ phân quyền cấp của tài nguyên cha để xác định quyền truy cập của người dùng
đối với tài nguyên con.

•

Việc kiểm tra quyền truy cập vào một tài nguyên đối với một người dùng có thể được thực hiện
bằng mã nguồn tường minh hoặc sử dụng chú giải phương thức hoặc tính chất (C# attribute or Java
annotation) hoặc tiêm mã nguồn vào hệ thống (filter hay plug-in) bằng cách áp dụng các tính năng
của khung ứng dụng.

3.5.

Kết luận và hướng phát triển
Lợi ích lớn nhất mơ hình đa người thuê là tối đa hóa việc sử dụng tài ngun. Tuy nhiên, hiện thực hóa mơ

hình đa người thuê hỗ trợ phân cấp không dễ dàng, đặc biệt là việc quản lý khía cạnh bảo mật của hệ thống. Trong
chương này chúng tôi đã đề xuất giải pháp để xây dựng mơ hình phân cấp cho các phần mềm đa người thuê trong
môi trường đám mây. Trong tương lai chúng tôi sẽ bổ sung các mô tả về việc mở rộng, tăng khả năng tải cho hệ
thống khi số lượng người th tăng cao. Mơ hình hóa người thuê và xử lý bảo mật là các khía cạnh cơ bản trong
phần mềm đa người thuê. Một khía cạnh quan trọng khác là kiến trúc tổng thể và mô hình xử lý giao dịch trong
phần mềm cung cấp dạng dịch vụ nói chung và phần mềm đa người thuê nói riêng. Trong phần tiếp theo, chúng tơi
sẽ trình bày việc tách biệt các thành phần của phần mềm đa người thuê, phát triển phần mềm đa người thuê một
cách mơ đun hóa và xử lý các giao dịch nghiệp vụ nhằm cung cấp một giải pháp tổng thể cho việc phát triển các
phần mềm cung cấp dạng dịch vụ nói chung và phần mềm đa người thuê nói riêng.

10


Chương 4. Mẫu thiết kế hệ thống giao dịch
4.1.

Động cơ và câu hỏi nghiên cứu
Tất cả các phần mềm doanh nghiệp đều cần hiện thực hóa các giao dịch trong thế giới thực để tự động hóa

các quy trình nghiệp vụ. Một trong các vấn đề khó khăn gặp phải khi thiết kế các hệ thống này là các kiến thức về
lĩnh vực (domain knowledge) luôn rất phức tạp. Việc thực thi các giao dịch một cách bảo mật hiện nay hầu như đều
được thực hiện một cách rất đặc thù (ad hoc) đối với từng hệ thống. Điều này làm cho chi phí và thời gian q trình
xây dựng các hệ thống xử lý giao dịch trở nên tốn kém.
Câu hỏi nghiên cứu 2: Làm sao để thiết kế các kiến thức về lĩnh vực của hệ thống xử lý giao dịch một cách
nhất quán, tách biệt các kiến thức về lĩnh vực khỏi công nghệ, đồng thời cho phép các giao dịch thực thi một cách
bảo mật theo một cung cách nhất qn?

4.2.

Cơng trình liên quan
Bernstein và Newcomer đã trình bày các nguyên lý cơ bản của việc xử lý giao dịch. Mark Grand đề xuất 4

mẫu thiết kế liên quan với nhau (ACID Transaction, Composite Transaction, Audit Trail và Two Phase Commit)
dành cho việc xử lý các giao dịch. Eric Evans đề xuất một tập các mẫu (đặc biệt là mẫu Repository và mẫu
Factory) để xử lý vấn đề phức tạp của kiến thức về lĩnh vực. Các mẫu thiết kế cho bảo mật được nghiên cứu bởi
Yoder & Barcalow, Schumacher và các cộng sự, Kanneganti, Chodavarapu và Fernandez.

4.3.

Giải pháp

4.3.1. Tổng quan về giải pháp
Để trả lời câu hỏi nghiên cứu trước tiên chúng tôi đề xuất một kiến trúc dựa trên các thành phần
(component-based) cho các hệ thống xử lý giao dịch bảo mật trong đám mây bằng cách tổng hợp các kiến trúc
doanh nghiệp truyền thống và kinh nghiệm từ các dự án chúng tôi đã thực hiện. Kiến trúc này cung cấp góc nhìn
tổng quan về các thành phần cơ bản của một hệ thống xử lý giao dịch cũng như chi tiết quá trình xử lý một giao
dịch. Sau đó chúng tơi tập trung vào việc thiết kế từng thành phần trong kiến trúc đề xuất.
Đối với khía cạnh phức tạp của kiến thức về lĩnh vực, chúng tơi đề xuất một hình thức biểu diễn các kiến
thức về lĩnh vực một cách nhất quán bằng các đối tượng Factory, Repository, Persistence và ServiceAdapter. Giải
pháp này là sự kết hợp, chi tiết hóa và mở rộng các mẫu Factory, Repository và Data Access Object. Để hỗ trợ các
giao dịch thực thi một cách bảo mật, chúng tơi đề xuất một quy trình nhất quán bao gồm việc thẩm định, kiểm tra
quyền truy cập và thực thi các chính sách bảo mật nghiệp vụ. Sự nhất quán này sẽ giúp các nhà phát triển hiểu các
giao dịch của hệ thống một cách dễ dàng hơn và tiết kiệm cơng sức khi hiện thực hóa hoặc thay đổi sự thực thi của
các giao dịch trong hệ thống.
4.3.2. Kiến trúc hệ thống xử lý giao dịch
Kiến trúc hệ thống xử lý giao dịch dựa trên các thành phần được thể hiện ở Hình 4.1. Mục đích của kiến
trúc này là liệt kê các thành phần chính của hệ thống xử lý giao dịch doanh nghiệp và sự tương tác giữa các thành
phần. Dựa trên ngữ cảnh của kiến trúc này một mơ hình nhất qn để thiết kế các kiến thức về lĩnh vực và xử lý các
giao dịch bảo mật của hệ thống được đề xuất.

11


Hình 4.1 – Kiến trúc hệ thống xử lý giao dịch dựa trên thành phần
4.3.3. Cấu trúc tĩnh
Một cấu trúc tĩnh của mẫu thiết kế hệ thống giao dịch được chúng tơi thể hiện bằng UML ở hình 4.2.
<<implementation class>>

EntityFactory

<<Interface>>

IEntityFactory
+CreateNew(in name: string, in description: string, in counterpartName: string, in dependant1Name: string, in dependant2Name: string): Entity
+CreateForUpdate(in entity: Entity, in newName: string, in newDescription: string, in newCounterpartName: string): Entity
+PrepareForTransaction(in name: string, in description: string, in counterpartId: string, in dependant1Name: string, in dependant2Id: string): Entity

Partner

*

+Id: string
+Name: string
+Entities: List<Entity>

*
1

Dependant
+Id: string
+Name: string
+Parent: Entity

<<Interface>>

IDependantRepository
+Create(in dependant : Dependant) : Dependant
+Update(in dependant : Dependant) : Dependant
+Delete(in Id : string) : int

+Retrieve(in Id : string) : Dependant
+List(in page: long, in pageSize: long) : List<Dependant>
+DoTransaction(in dependant : Dependant) : Dependant

*

1

Entity
+Id: string
+Name: string
+Description: string
+Friend: Friend
+Dependants: List<Dependant>
+Partners: List<Partner>

<<Interface>>

IEntityRepository

ICounterpartRepository

+Create(in entity : Entity) : Entity
+Update(in entity : Entity) : Entity
+Delete(in Id : string) : int
+Retrieve(in Id : string) : Entity
+List(in page: long, in pageSize: long) : List<Entity>
+DoTransaction(in entity : Entity) : Entity

IDependantPersistence

+Create(in dependant : Dependant) : Dependant
+Update(in dependant : Dependant) : Dependant
+Delete(in Id : string) : int
+Retrieve(in Id : string) : Dependant
+List(in page: long, in pageSize: long) : List<Dependant>
<<implementation class>>

DependantPersistence
TransactionRequestHandler

<<implementation class>>

CounterpartRepository

<<Interface>>

IEntityPersistence
+Create(in entity : Entity) : Entity
+Update(in entity : Entity) : Entity
+Delete(in Id : string) : int
+Retrieve(in Id : string) : Entity
+List(in page: long, in pageSize: long) : List<Entity>
<<implementation class>>

EntityPersistence

<<Interface>>

ICounterpartPersistence
+Create(in counterpart : Counterpart) : Counterpart

+Update(in counterpart : Counterpart) : Counterpart
+Delete(in Id : string) : int
+Retrieve(in Id : string) : Counterpart
+List(in page: long, in pageSize: long) : List<Counterpart>

<<Interface>>

IServiceAdapter
+Invoke(in input : string) : string
<<implementation class>>

TransactionClient

+Create(in counterpart : Counterpart) : Counterpart
+Update(in counterpart : Counterpart) : Counterpart
+Delete(in Id : string) : int
+Retrieve(in Id : string) : Counterpart
+List(in page: long, in pageSize: long) : List<Counterpart>
+DoTransaction(in counterpart : Counterpart) : Counterpart

<<implementation class>>

EntityRepository

<<Interface>>

+Id: string
+Name: string
+Entity: Entity

<<Interface>>

<<implementation class>>

DependantRepository

Counterpart
1

ServiceAdapter

<<implementation class>>

CounterpartPersistence

SystemUtility

Hình 4.2 – Cấu trúc tĩnh của mẫu hệ thống giao dịch

12


4.3.4. Cấu trúc động
Hình 4.3 mơ tả q trình thực thi một giao dịch bảo mật để đặt một đơn hàng Order, ở đây đơn hàng là một
đối tượng nghiệp vụ cụ thể.

Hình 4.3 – Cấu trúc động của mẫu hệ thống giao dịch

4.4.

Đánh giá

4.4.1. Phân tích và thảo luận
Đối với câu hỏi nghiên cứu 2 mẫu thiết kế hệ thống giao dịch đã cung cấp một phương pháp nhất quán để
thiết kế các kiến thức về lĩnh vực. Sự nhất quán đạt được bằng cách biểu diễn tất cả các đối tượng nghiệp vụ ở cùng
một hình thức. Mẫu thiết kế hệ thống giao dịch hỗ trợ tách biệt các kiến thức về lĩnh vực khỏi công nghệ. Điều này
được thực hiện bằng cách bao bọc trách nhiệm truy xuất dữ liệu vào đối tượng Persistence và bao bọc các kiến thức
về lĩnh vực vào các đối tượng Repository và Factory. Mẫu thiết kế hệ thống giao dịch cho phép các giao dịch thực
thi một cách bảo mật theo một cung cách nhất quán. Sự nhất quán đạt được bằng cách bao bọc các công việc đăng
nhập trong các đối tượng UserRepository và ServiceAdapter, bao bọc các công việc phân quyền trong các đối
tượng AuthorizationRepository và ServiceAdapter, bao bọc việc thực thi các chính sách bảo mật trong một đối
tượng nghiệp vụ, ví dụ như đối tượng OrderRepository.
Việc từng đối tượng trong mẫu thiết kế hệ thống giao dịch có giao diện (interface) riêng (Hình 4.2) đảm
bảo ngun lý mở đóng (The Open Closed Principle). Việc tách biệt các trách nhiệm trong từng đối tượng nghiệp
vụ thành các đối tượng Entity, Factory, Repository, Persistence, Adapter đảm bảo nguyên lý trách nhiệm đơn lẻ
(The Single-Responsibility Principle) trong thiết kế hướng đối tượng. Do vậy, mẫu thiết kế hệ thống giao dịch giúp
việc chỉnh sửa, mở rộng hệ thống dễ dàng hơn.
4.4.2. Nghiên cứu trường hợp
Mẫu thiết kế hệ thống giao dịch đã được áp dụng vào 6 hệ thống phần mềm bao gồm hệ thống thư điện tử
bảo mật, hệ thống trao đổi tập tin bảo mật cho ngân hàng, hệ thống tương tác và quản trị dự án, hệ thống quản lý
thông tin và tài liệu doanh nghiệp, hệ thống quản lý trường học phổ thông và hệ thống quản lý hạ tầng đập nước.
Hệ thống tương tác và quản trị dự án là một phần mềm cung cấp dạng dịch vụ đa người thuê cho phép quản
lý và báo cáo các thông tin và tài nguyên của dự án, cũng như cho phép các thành viên của dự án có thể tương tác,
liên lạc với nhau qua một không gian làm việc chung. Đây là một hệ thống bao gồm nhiều đối tượng với các mối
13


quan hệ phức tạp ví như Customer, User, Role, Project, Project Template, To-Do List, To-Do, Milestone, File,
Message, Comment, Time Log, Risk, vân vân.
Ngoài ra hệ thống cũng cho phép thêm các đối tượng nghiệp vụ mới tùy theo nhu cầu của các khách hàng

đặc thù. Ví dụ đối với việc quản lý một dự án xây dựng có thể địi hỏi phải thêm các đối tượng nghiệp vụ đặc thù
như Supplier, Contractor, Order, Material, Expense, vân vân. Một phần các đối tượng nghiệp vụ và mối liên hệ
giữa các đối tượng được thể hiện trong hình 4.4.
«enumeration»
ProjectStatus
+Active = 1
+Paused = 2
+Completed = 3
+Cancel = 4

Company

FileCategory

+CompanyId : uniqueidentifier
+Name : string
+ThemeName : string
+UserAdded : User
+DateAdded : DateTime

+FileCategoryId : uniqueidentifier
+Project : Project
+Name : string
+UserAdded : User
+DateAdded : DateTime
*

1

*

1

Project
+ProjectId : uniqueidentifier
+Creator : User
+Name : string
+Description : string
+Status : ProjectStatus
+Clients : IList<User>
+Participants : IList<User>
+Tasks : IList<Task>
+Company : Company

*

*

FilePackage
+FilePackageId : uniqueidentifier
+Project : Project
+Name : string
+Description : string
+DateAdded : DateTime
+UserAdded : User
+Authorizations : IList<Authorization>

Milestone
1
*

+MilestoneId : uniqueidentifier
+Project : Project
+Name : string
+DueDate : DateTime
+ResponsiblePerson : User
+UserAdded : User
+DateAdded : DateTime

*

1

1

1

*
1*

1

+ToDoListId : uniqueidentifier
+Name : string
+Project : Project
+Description : string
+Status : ToDoListStatus
+Completion : double
+UserAdded : User
+DateAdded : DateTime

+ToDos : IList<ToDo>

1

*

«enumeration»
ToDoListStatus
+Active = 1
+Completed = 2

+ToDoId : uniqueidentifier
+Task : ToDoList
+Name : string
+Assignee : User
+DateAssigned : DateTime
+Status : ToDoStatus

+MessageId : uniqueidentifier
+Project : Project
+Category : MessageCategory
+DatePosted : DateTime
+Subject : string
+Body : string
+Sender : User

«enumeration»
ToDoStatus
+None
+OnHold

+Committed
+Started
+Completed

+FileId : uniqueidentifier
+ContainerId : uniqueidentifier
+Name : string
+Path : string
+Mime : string
+Size : long
+Version : uint
+DateAdded : DateTime
+UserAdded : User

*

1

1

MessageCategory
*

*
ToDo

File

Message

ToDoList

+MessageCategoryId : uniqueidentifier
+Name : string
*

Comment
+CommentId : uniqueidentifier
+Message : Message
+DatePosted : DateTime
+Subject : string
+Body : string
+Sender : User

Authorization
+AuthorizationId : uniqueidentifier
+ResourceId : uniqueidentifier
+AccessorId : uniqueidentifier
+AccessorType : AccessorType
+AuthorizationRights : AuthorizationRights

«enumeration»
AccessorType
+Role
+User

«enumeration»
AuthorizationRights
+None = 0
+Read = 1

Hình 4.4 – Một số đối tượng trong hệ thống tương tác và quản trị dự án
Một cách tiếp cận để thiết kế hệ thống quản trị dự án mô tả ở trên là sử dụng mẫu thiết kế Transaction
Script. Một cách tiếp cận khác là sử dụng mẫu thiết kế Table Module. Tuy nhiên, cả hai cách tiếp cận ở trên làm
cho hệ thống trở nên phức tạp khi số lượng các đối tượng nghiệp vụ và các mối liên hệ trong hệ thống tăng lên. Một
cách tiếp cận khác là sử dụng trực tiếp các đối tượng trong mơ hình 4.4 để thực hiện các tác vụ cần thiết thông qua
mẫu thiết kế Domain Model. Vấn đề đối với hướng tiếp cận này việc truy cập vào dữ liệu của các đối tượng nghiệp
vụ được tích hợp vào trong bản thân các đối tượng nghiệp vụ. Điều này làm phình to các đối tượng nghiệp vụ và sự
phức tạp của hệ thống tăng lên. Một hướng tiếp cận khác là áp dụng Domain-Driven Design thông qua các mẫu
thiết kế Repository và Factory. Tuy nhiên, hướng tiếp cận này không tách biệt các đối tượng nghiệp vụ khỏi các
công nghệ để lưu trữ và truy xuất dữ liệu. Hướng tiếp cận này cũng không hỗ trợ xử lý các giao dịch bảo mật một
cách nhất quán.

14


Mẫu thiết kế hệ thống giao dịch khắc phục các hạn chế trên. Việc áp dụng mẫu thiết kế hệ thống giao dịch
cho các thực thể trong hình 4.4 được thể hiện trong hình 4.5 trong tồn văn luận án.
4.4.3. Bài học kinh nghiệm
Qua nghiên cứu các trường hợp áp dụng mẫu thiết kế hệ thống giao dịch và tổng hợp ý kiến của các chuyên
gia chúng tôi nhận thấy rằng trong khi (i) một thực thể có độ phức tạp thấp có thể được hiện thực hóa bằng cách áp
dụng mẫu Transaction Script hoặc Table Module hoặc Active Record thì (ii) một thực thể có độ phức tạp trung
bình có thể được hiện thực hóa bằng cách mơ hình hệ thống dựa trên kiến thức về lĩnh vực và (iii) một thực thể có
có độ phức tạp trung bình hoặc cao có thể được hiện thực hóa bằng mẫu hệ thống giao dịch hoặc một sự kết hợp
của mẫu hệ thống giao dịch và 2 hướng tiếp cận trên. Các khái niệm độ phức tạp thấp, trung bình và cao phụ thuộc
vào số lượng các thực thể liên quan đến thực thể cần thiết kế và dữ liệu, quy trình nghiệp vụ liên quan đến thực thể
cần thiết kế.
Điều này ngụ ý rằng việc thiết kế tất cả các thực thể của một hệ thống bằng một hướng tiếp cận không phải
là điều bắt buộc. Tuy nhiên, mẫu hệ thống giao dịch ln có tác dụng tách biệt các kiến thức về lĩnh vực khỏi các
công nghệ ứng dụng. Các thực thể được thiết kế theo mẫu hệ thống giao dịch thường được nhóm lại thành tầng mơ

hình nghiệp vụ của hệ thống và phân biệt với tầng công nghệ đặc thù.
Dưới đây là một số kinh nghiệm về mặt kỹ thuật được chúng tôi rút ra khi hiện thực hóa mẫu thiết kế hệ
thống giao dịch trong các hệ thống thực tế:
•

Các điểm vào của các dịch vụ nghiệp vụ (hay các phương thức của đối tượng
TransactionRequestHandler) có th c hin thc húa bng mu Faỗade khi cn các dịch vụ thơ
(coarse-grain services).

•

Các đối tượng lưu trữ có thể được thiết kế bằng cách sử dụng mẫu Data Access Object hoặc Table
Data Gateway hoặc Row Data Gateway hoặc Data Mapper. Tầng hiện thực hóa việc lưu trữ nên
được tách biệt với tầng nghiệp vụ (hay tầng chứa các thực thể) bằng cách sử dụng các đối tượng
chuyển giao dữ liệu (data transfer objects).

•

Việc ủy quyền truy cập cho từng thực thể (trách nhiệm của đối tượng AuthorizationRepository) có
thể được hiện thực hóa bằng mẫu Check Point và/hoặc mẫu RBAC và/hoặc mẫu ABACvà/hoặc
mẫu đa người th phân cấp.

•

Các tính chất ACID của giao dịch có thể đạt được bằng cách sử dụng các tính năng của ngơn ngữ
hay nền tảng cơng nghệ (ví dụ thư viện System.Transactions của .NET Framework) và mẫu Unit of
Work hoặc sử dụng mẫu ACID Transaction.

•

Cơ chế kiểm sốt việc truy cập đồng thời trong hệ thống xử lý giao dịch có thể được hiện thực hóa
bằng cách sử dụng mẫu Optimistic Offline Lock, Pessimistic Offline Lock, Coarse-Grained Lock
hoặc Implicit Lock.

4.5.

Kết luận và hướng phát triển
Trong phần này chúng tôi đã đề xuất giải pháp để xây dựng các hệ thống giao dịch bảo mật một cách nhất

quán, đặc biệt là các phần mềm doanh nghiệp trong đám mây. Trong tương lai chúng tôi sẽ mở rộng mẫu thiết kế
này để xử lý các giao dịch tổng hợp và đảm bảo việc tuân theo các chuẩn dịch vụ mạng, phương pháp kiểm soát các
giao dịch đồng thời và khôi phục sự cố khi các giao dịch bị lỗi. Các giao dịch trong môi trường đám mây thường
được tiếp nhận và xử lý thông qua một ứng dụng web. Ứng dụng web thường được xây dựng dựa trên một khung
ứng dụng web. Trong phần tiếp theo, chúng tôi sẽ giới thiệu một giải pháp để xây dựng một khung ứng dụng web
đa người thuê trong môi trường đám mây.

15


Chương 5. Mẫu thiết kế khung ứng dụng web
5.1.

Động cơ và câu hỏi nghiên cứu
Nhiều khung ứng dụng web đã được phát triển nhằm giảm công sức, thời gian phát triển và tăng chất lượng

các ứng dụng web. Tuy nhiên, tồn tại rất ít tài liệu giải thích các bộ khung này hoạt động nội tại như thế nào nhằm
hỗ trợ việc lựa chọn khung ứng dụng web phù hợp và sử dụng khung ứng dụng web hiệu quả. Đặc biệt hầu như
chưa tồn tại các tài liệu hỗ trợ việc hiệu chỉnh một khung ứng dung web cho mục đích đặc thù hay xây dựng một
khung ứng dụng từ đầu vì lý do khơng tương thích khi tích hợp với các hệ thống cũ hoặc do yêu cầu bảo mật hoặc
do lĩnh vực đặc thù.

Các phần mềm cung cấp dạng dịch vụ và các nền tảng cung cấp dạng dịch vụ đang trở nên rất hấp dẫn do
tổng chi phí sở hữu các phần mềm được giảm xuống bằng cách áp dụng kiến trúc đa người thuê. Ứng dụng web là
thành phần cơ bản của các hệ thống đa người thuê này. Tuy nhiên, các khung ứng dụng web hiện tại hầu như chưa
hỗ trợ đa người thuê. Các nhà phát triển phải tùy biến các khung ứng dụng web có sẵn hoặc xây dựng các khung
ứng dụng web mới hỗ trợ đa người thuê bằng phương pháp đặc thù.
Câu hỏi nghiên cứu 3: Làm sao để thiết kế khung ứng dụng web đa người thuê cho phép mở rộng ứng dụng
mà không bị trùng lắp mã nguồn, hỗ trợ tách biệt các mối quan tâm của ứng dụng, cho phép phát triển và tái sử
dụng các mô đun với khả năng “cắm-chạy” khi thực thi?

5.2.

Cơng trình liên quan
Mẫu thiết kế chúng tôi đề cập ở chương này liên quan đến nhiều lĩnh vực nghiên cứu bao gồm phát triển

các hệ thống web, mẫu thiết kế và kiến trúc đa người thuê.

5.3.

Giải pháp

5.3.1. Tổng quan về giải pháp
Giải pháp là sự mở rộng của mẫu Model-View-Controller với các mô đun “cắm-chạy” và sự phân cấp, mở
rộng mẫu Pipe and Filter để hỗ trợ các mô đun “cắm-chạy”, và mở rộng quy trình xử lý yêu cầu với đối tượng ngữ
cảnh người thuê (TenantContext) chứa thông tin về người thuê cho từng u cầu để hỗ trợ mơ hình đa người thê.

Hình 5.1 – Tổng quan về mẫu thiết kế khung ứng dụng web
Mẫu thiết kế sử dụng một đối tượng ứng dụng (Application) để xử lý các yêu cầu từ trình khách. Bên trong
đối tượng ứng dụng Application này chúng tôi tạo các phương thức mẫu (Template method) để xử lý các yêu cầu
16

theo từng pha thư kiểm tra đầu vào, đăng nhập, kiểm tra quyền truy cập, xử lý nghiệp vụ, vân vân (Hình 5.1). Bên
trong mỗi phương thức mẫu chúng tơi sử dụng các bộ lọc (Filter) để hiện thực hóa và mở rộng các tác vụ đặc thù
của ứng dụng. Mỗi yêu cầu sẽ được xử lý bằng sự kết hợp của mẫu thiết kế Presentation-Abstraction-Control
(nhằm hỗ trợ phân cấp) với mẫu thiết kế Model-View-Controller (nhằm hỗ trợ tách biệt các mối quan tâm của ứng
dụng) với sự liên lạc theo mơ hình Request-Reply.
5.3.2. Cấu trúc tĩnh
Một sơ đồ lớp tiêu biểu bằng ngôn ngữ UML của mẫu thiết kế khung ứng dụng web được thể hiện ở hình
5.2.
URI
ModulePath
UserId

RequestParams
URI
Browser
IPAddress

HomePage
Theme

ThemeName
LicenseStartDate
LicenseEndDate

CanManageApplicationSettings
CanManageUsers
CanManageRoles

TenantContext

ShoppingCart

1

Username
Roles

1

ApplicationContext

RequestContext

SessionContext

PermissionContext

UserContext
1

1

1

1

ApplicationManager

*
1

CurrentController
PreviousController
PageContext
*

1

CustomActionView
1

ActionView

*

1

+Render()

1

Model

1

1

1

1

Application
+ApplicationContext : ApplicationContext
+RequestContext : RequestContext
+SessionContext : SessionContext
+UserContext : UserContext
+Filters : List<IFilter>
+Run()
#Start()
#BeginRequest()
#AuthenticateRequest()
#AuthorizeRequest()
#HandleRequest()
#EndRequest()
#End()

1

Client

1

1

1

CustomApplication
1

/Public/Home/Index

/Public/Product/Create
/Public/Product/Display/10
/Admin/Account/Edit/20
1

*

*

Controller
+ActionViews : List<ActionView>
+Model : Model
+Filters : List<IFilter>
+ModuleControllers : List<Controller>
+Run()
#BeginAction()
#Action()
#EndAction()
#RunModules()
CustomController
+Index
+Create
+Display

#HandleRequest()

1

HomeController
ProductController

AccountController

«interface»
IFilter

+Execute() : bool
*
1

*

«implementation class»
CustomFilter

AuthenticationFilter
AuthorizationFilter
VersionFilter
LicenseFilter
ErrorFilter

Hình 5.2 – Cấu trúc tĩnh của mẫu thiết kế khung ứng dụng web
Tất cả các tài nguyên của một ứng dụng web được sinh ra bởi các trang chủ. Mô đun là một thành phần
cắm-chạy được quản lý và vận hành bên trong một trang chủ. Cả trang chủ và mô đun đều được tạo thành từ nhiều
đối tượng phân cấp mơ hình (model), hiển thị (view) và người điều khiển (controller). Cấp độ gốc hay cao nhất bao
gồm các đối tượng mơ hình trang, hiển thị trang và người điều khiển trang. Các cấp độ thấp hơn bao gồm các đối
tượng mơ hình mơ đun, hiển thị mơ đun và người điều khiển mơ đun. Đây là chìa khóa để tách biệt các mối quan
tâm của ứng dụng.
5.3.3. Cấu trúc động
Chi tiết về sự tương tác giữa các thành phần để xử lý một yêu cầu từ trình khách được mơ tả trong tồn văn
của luận án.

17


5.4.

Đánh giá

5.4.1. Phân tích và thảo luận
Đối với câu hỏi nghiên cứu 3 mẫu thiết kế khung ứng dụng web hỗ trợ mơ hình đa người th đạt bằng
cách sử dụng một đối tượng ngữ cảnh người thuê (Tenant Context) chứa thông tin về người thuê cho từng yêu cầu;
cho phép mở rộng ứng dụng mà không bị trùng lắp mã nguồn bằng cách cho phép lập trình viên mở rộng hệ thống
bằng cách kế thừa từ các đối tượng Application, Controller và View và tạo các mô đun và “cắm” vào q trình thực
thi thơng qua giao diện IFilter; hỗ trợ tách biệt các mối quan tâm của ứng dụng bằng cách tách biệt hiển thị (View)
khỏi điều khiển (Controller) và mơ hình (Model) bằng mẫu MVC và PAC; cho phép phát triển và tái sử dụng các
mô đun với khả năng “cắm-chạy” khi thực thi bằng cách áp dụng mẫu Pipes and Filter.
Việc áp dụng mẫu thiết kế Template Method cho phép mở rộng ứng dụng web bằng cách kế thừa mà không
cần thay đổi mã nguồn cũ; việc áp dụng mẫu Strategy hỗ trợ các mô đun “cắm-chạy” và các bộ lọc “cắm-chạy”
đảm bảo nguyên lý mở đóng. Việc mở rộng mẫu thiết kế MVC hỗ trợ tách biệt hiển thị khỏi điều khiển và mơ hình
đảm bảo nguyên lý trách nhiệm đơn lẻ trong thiết kế hướng đối tượng. Nhờ đó, mẫu thiết kế khung ứng dụng web
cho phép chỉnh sửa, mở rộng hệ thống dễ dàng hơn.
5.4.2. Nghiên cứu trường hợp
Chúng tôi đã áp dụng mẫu thiết kế khung ứng dụng web vào 5 hệ thống phần mềm bao gồm hệ thống thư
điện tử bảo mật, hệ thống trao đổi tập tin bảo mật cho ngân hàng, hệ thống tương tác và quản trị dự án, hệ thống
quản lý thông tin và tài liệu doanh nghiệp và hệ thống quản lý trường học phổ thông.
Hệ thống thư điện tử bảo mật là một hệ thống phần mềm cung cấp các dịch vụ gửi thư điện tử với nội dung
được bảo mật trên đường truyền và nơi lưu trữ cho các cá nhân, công ty và đại lý. Một ứng dụng web đa người thuê
được cung cấp để người dùng tương tác với hệ thống.
Cách tiếp cận thông thường đối với một khung ứng dụng web là sử dụng tính kế thừa và mẫu thiết kế
Template Method. Hạn chế của cách tiếp cận này là không tách biệt các mối quan tâm của ứng dụng (tách biệt các

hiển thị khỏi các điều khiển và mơ hình). Điều này dẫn đến việc kiểm thử các thành phần của ứng dụng gặp khó
khăn. Cách tiếp cận đối với việc tách biệt các mối quan tâm trong khung ứng dụng web được thực hiện dựa vào
mẫu thiết kế MVC và các biến thể của mẫu thiết kế này. Hạn chế của cách tiếp cận này không phân rã các tính năng
của hệ thống thành các mơ đun phân cấp và không hỗ trợ các mô đun “cắm-chạy”.
Mẫu thiết kế khung ứng dụng web khắc phục các hạn chế này. Đồng thời mẫu thiết kế khung ứng dụng
web cũng giải quyết vấn đề hỗ trợ đa người thuê trong một khung ứng dụng web mà hai cách tiếp cận trên chưa xử
lý.
Áp dụng mẫu thiết kế khung ứng dụng web chúng tơi hiện thực hóa các tính năng cốt lõi như thẩm định,
phân quyền, lưu trữ dữ liệu, phục hồi giao dịch trong mơ hình kiến thức về lĩnh vực. Chúng tơi cũng hiện thực hóa
một số bộ lọc như bộ lọc phát hiện yêu cầu không hợp lệ, bộ lọc kiểm tra việc thông tin bảo mật người dùng cần
nâng cấp. Việc áp dụng mẫu khung ứng dụng web trên nền tảng ASP.NET cho hệ thống thư điện tử bảo mật được
thể hiện trong hình 5.9 trong tồn văn luận án.
Để xây dựng ứng dụng web cho hệ thống thư điện tử bảo mật dựa trên bộ khung này chúng tơi thực hiện
các cơng việc sau:
•

Phân rã các tính năng đặc thù của hệ thống thư điện tử bảo mật thành các trang và mơ đun phân
cấp.

•

Xác định mối liên hệ bao hàm giữa một trang và các mô đun con.

•

Xác định mối liên hệ bao hàm giữa một mơ đun cha và các mơ đun con.

•

Tạo và lắp ráp các trang và mô đun sử dụng các trang và mơ đun có sẵn đã được hiện thực hóa bởi

khung ứng dụng.
18


•

Hiện thực hóa các trang và mơ đun tùy biến cho các tác vụ ứng dụng đặc thù bằng cách tạo lớp con
kế thừa từ lớp ứng dụng Application, lớp điều khiển Controller và lớp hiển thị View

•

Hiện thực hóa các bộ lọc cho các tác vụ đặc thù và gắn gắn các bộ lọc này vào các trang và mô đun
ở thời điểm biên dịch hoặc vận hành.

5.4.3. Bài học kinh nghiệm
Từ các trường hợp nghiên cứu và tổng hợp ý kiến của các chuyên gia chúng tôi rút ra một số kinh nghiệm
khi áp dụng mẫu thiết kế khung ứng dụng web. Một phiên bản đơn giản hóa của mẫu thiết kế này có thể áp dụng để
phát triển các khung ứng dụng web đơn người thuê bằng cách loại bỏ đối tượng ngữ cảnh người thuê hoặc giới hạn
số lượng người thuê là một tổ chức.
Dưới đây là một số kinh nghiệm về mặt kỹ thuật được chúng tơi rút ra khi hiện thực hóa mẫu thiết kế
khung ứng dụng web trong các hệ thống thực tế:
•

Để giảm sự phức tạp của đối tượng ứng dụng và đối tượng ngữ cảnh yêu cầu một động cơ điều
phối có thể được đưa vào sử dụng. Động cơ này gồm nhiều đối tượng chịu trách nhiệm nhận các
yêu cầu, phân tích các tham số và thơng tin của các yêu cầu, lựa chọn các điều khiển tương ứng và
chuyển các yêu cầu đến các điều khiển lựa chọn.

•

Việc đăng ký các mơ đun (hay plug-ins) và bộ lọc có thể là tĩnh (đăng ký ở thời điểm biên dịch)
hoặc động (đăng ký ở thời điểm vận hành).

•

Việc kích hoạt động các phương thức hành động mẫu có thể được hiện thực hóa bằng cách sử dụng
phản chiếu hành vi.

•

Để giảm tải cho máy chủ và tăng các hành động đồng thời của ứng dụng các đối tượng giao diện có
thể chỉ đảm nhiệm chuyển các kết quả giao dịch thành các đối tượng mơ hình hiển thị (view
model) và trả về cho trình khách (hay trình duyệt). Trình khách chịu trách nhiệm hiển thị các mơ
hình giao diện này bằng cách sử dụng một mơ hình hiển thị (presentation model).

5.5.

Kết luận và hướng phát triển
Trong phần này chúng tôi đã đề xuất một mẫu thiết kế để xây dựng một khung ứng dụng web đa người

thuê. Mẫu thiết kế này có thể được hiệu chỉnh cho các hệ thống phần mềm khác nhau, đặc biệt là các hệ thống phần
mềm trong các môi trường hướng dịch vụ và đám mây. Trong tương lai chúng tôi sẽ bổ sung phương pháp xử lý
các giao dịch đồng thời và khôi phục giao dịch khi gặp lỗi. Chúng tôi cũng sẽ bổ sung các giải pháp cho các tính
năng gọi lại (callback) và xử lý sự kiện (event handling) giữa các đối tượng.
Giao diện đồ họa người dùng là một phần thiết yếu của các hệ thống phần mềm nói chung và các ứng dụng
web nói riêng. Việc tùy biến giao diện đồ họa người dùng cho từng người thuê là một yêu cầu cơ bản trong phần
mềm đa người thuê. Trong phần tiếp theo, chúng tơi sẽ trình bày việc mở rộng mẫu thiết kế khung ứng dụng web
đa người thuê để bổ sung khả năng hiệu chỉnh, tùy biến giao diện đồ họa người dùng.

19

Chương 6. Mẫu thiết kế tùy biến giao diện
6.1.

Động cơ và câu hỏi nghiên cứu
Giao diện đồ họa người dùng là thành phần thiết yếu của hầu hết các hệ thống phần mềm. Một trong các

vấn đề thường gặp khi phát triển phần mềm đa người thuê là việc hỗ trợ các giao diện đồ họa người dùng khác
nhau không chỉ cho tồn hệ thống mà cịn cho cả từng người dùng và từng người thuê. Yêu cầu này cũng áp dụng
cho các ứng dụng có khả năng nhận biết hoàn cảnh. Trong các ứng dụng này một giao diện phù hợp sẽ được lựa
chọn tùy thuộc vào hoàn cảnh của người dùng.
Các yêu cầu về tùy biến cho giao diện đồ họa người dùng của một hệ thống phần mềm có thể phát sinh từ
các nguồn sau: (i) hỗ trợ trải nghiệm khác nhau của một tính năng cho các thiết bị hay người thuê hay người dùng
hay hoàn cảnh khác nhau, (ii) hỗ trợ các nội dung khác nhau của một tính năng cho các thiết bị hay người thuê hay
người dùng hay hoàn cảnh khác nhau, (iii) hỗ trợ cả trải nghiệm và nội dung khác nhau của một tính năng cho các
cho các thiết bị hay người thuê hay người dùng hay hoàn cảnh khác nhau.
Việc tùy biến giao diện thường được thực hiện thông qua một khung giao diện đồ họa người dùng. Hiện tại
tồn tại rất ít nghiên cứu về mẫu thiết kế hỗ trợ đánh giá, sử dụng, hiệu chỉnh và xây dựng một khung giao diện đồ
họa người dùng hỗ trợ tùy biến dành cho phần mềm nói chung và các phần mềm đa người thuê nói riêng. Sự thiếu
hụt các mẫu thiết kế này khiến các nhà phát triển phải xây dựng một bộ khung giao diện đồ họa người dùng hỗ trợ
tùy biến bằng phương pháp thử sai. Do đó làm gia tăng công sức và thời gian xây dựng cũng như bảo trì hệ thống.
Câu hỏi nghiên cứu 4: Làm sao để thiết kế khung giao diện đồ họa người dùng đa người thuê với khả năng
tùy biến theo toàn hệ thống hoặc theo người dùng hoặc theo người thuê, cho phép phát triển các biến thể giao diện
một cách mơ đun hóa, hỗ trợ triển khai và kích hoạt các biến thể giao diện khi hệ thống đang thực thi?

6.2.

Cơng trình liên quan
Kết quả nghiên cứu được trình bày ở chương này liên quan đến nhiều lĩnh vực nghiên cứu bao gồm thiết kế

và hiện thực hóa giao diện đồ họa người dùng, sự tùy biến của phần mềm, mẫu thiết kế và mơ hình đa người th.

6.3.

Giải pháp

6.3.1. Tổng quan về giải pháp
Giải pháp là sự mở rộng mẫu MVC bằng cách (i) phân rã giao diện của hệ thống thành các hiển thị cửa sổ
và hiển thị mô đun phân cấp, (ii) thêm đối tượng chủ đề giao diện Theme nhằm lưu trữ một tập các đối tượng hiển
thị (View) cho một biến thể của giao diện. Việc thay đổi giao diện của hệ thống được thực hiện bằng cách truyền
các hiển thị khác nhau đến điều khiển (Controller) bằng mẫu Strategy. Đồng thời đối tượng TenanContext được
thêm vào để lưu trữ thông tin người thuê nhằm hỗ trợ lựa chọn giao diện phù hợp với từng người dùng của người
th (Hình 6.3).
Thơng tin cho việc lựa chọn chủ đề giao diện được lấy ra các tham số đầu vào, thơng tin cấu hình hoặc quy
ước. Đối với các phần mềm đa người thuê, thông tin về chủ đề giao diện đồ họa người dùng được lấy ra từ đối
tượng ngữ cảnh người thuê.
Các biến thể của một hiển thị khác nhau ở phong cách giao diện (màu sắc, phông chữ), số lượng các hiển
thị mô đun bên trong cửa sổ và vị trí của các mô đun bên trong. Về mặt kỹ thuật, các biến thể của một hiển thị được
phát triển bằng cách áp dụng mẫu thiết kế Decorator.

20


Hình 6.3 – Tổng quan về mẫu thiết kế tùy biến giao diện
6.3.2. Cấu trúc tĩnh
Chi tiết về các thành phần tham gia vào mẫu tùy biến giao diện được trình bày trong tồn văn của luận án.
6.3.3. Cấu trúc động
Chi tiết về sự tương tác giữa các thành phần để hiển thị giao diện một cửa sổ của hệ thống được trình bày
trong tồn văn của luận án.

6.4.

Đánh giá

6.4.1. Phân tích và thảo luận
Đối với câu hỏi nghiên cứu 4 mẫu thiết kế tùy biến giao diện đã hỗ trợ mơ hình đa người th trong mơi
trường đám mây, cho phép tùy biến giao diện theo toàn hệ thống hoặc theo người dùng hoặc theo người thuê bằng
cách thêm đối tượng TenantContext vào quá trình lựa chọn giao diện; cho phép phát triển các biến thể giao diện
một cách mơ đun hóa bằng cách tách một chủ đề thành các hiển thị khác nhau và tách một hiển thị thành các hiển
thị con phân cấp sử dụng mẫu Composite, sau đó sử dụng mẫu Decorator để trang trí cho từng hiển thị; hỗ trợ triển
khai và kích hoạt các biến thể giao diện khi hệ thống đang thực thi bằng cách tạo các tập tin hiển thị khác nhau và
tiêm vào hệ thống tại thời điểm vận hành bằng mẫu thiết kế Strategy.
Việc áp dụng mẫu Strategy hỗ trợ kích hoạt các biến thể của giao diện khi hệ thống đang thực thi đảm bảo
nguyên lý mở đóng. Việc mở rộng mẫu thiết kế MVC hỗ trợ tách biệt hiển thị khỏi điều khiển và mơ hình và phân
loại hiển thị thành hiển thị cửa sổ, hiển thị mô đun và hiển thị vùng đảm bảo nguyên lý trách nhiệm đơn lẻ trong
thiết kế hướng đối tượng. Nhờ đó, mẫu thiết kế tùy biến giao diện cho phép chỉnh sửa, mở rộng hệ thống dễ dàng
hơn.
6.4.2. Nghiên cứu trường hợp
Mẫu thiết kế tùy biến giao diện đã được áp dụng trong 4 hệ thống phần mềm bao gồm hệ thống thư điện tử
bảo mật, hệ thống quản lý dự án, hệ thống quản lý thông tin doanh nghiệp và hệ thống quản lý trường học. Hệ
thống thư điện tử bảo mật đa người thuê yêu cầu mỗi người dùng hoặc cơng ty có thể có một giao diện đồ họa
người dùng khác nhau khi truy cập vào hệ thống thơng qua ứng dụng web. Mỗi cơng ty có thể có chủ đề giao diện
riêng của mình hoặc kế thừa chủ đề giao diện từ cơng ty cha.
Hiện nay tính tùy biến của giao diện chưa được đề cập nhiều trong các tài liệu nghiên cứu. Cách tiếp cận
phổ biến trong ngành công nghiệp là sử dụng một tập tin khuôn mẫu (template) định nghĩa các thành phần sẽ được
21


hiển thị cho một nhóm các màn hình giao diện có cùng cách sắp đặt (ví dụ như gồm 3 phần Header, Content và

Foooter) và thay đổi tập tin này (ví dụ như thay đổi kích thước, vị trí, phong cách Header, Content và Foooter) khi
cần tùy biến. Cách tiếp cận này giới hạn tùy biến trong phạm vi một cửa sổ hiển thị (không hỗ trợ các mô đun),
không hỗ trợ phân cấp, không cho phép hiệu chỉnh cách trình bày các dữ liệu được hiển thị và khơng tách biệt các
mối quan tâm của ứng dụng.
Một cách tiếp cận khác là định nghĩa sẵn các thuộc tính mơ tả phong cách các giao diện (màu sắc, phông
chữ, vân vân) và gán các thuộc tính này vào các đối tượng giao diện cần tùy biến. Hạn chế của cách tiếp cận này là
chỉ hỗ trợ thay đổi phong cách giao diện mà không cho phép tùy biến các nội dung được hiển thị hay bản thân các
tập tin hiển thị khi cần thiết.
Một cách tiếp cận khác là sử dụng các tập tin khuôn mẫu làm các hiển thị trực tiếp kết hợp với các tập tin
định nghĩa các thuộc tính mơ tả phong cách các hiển thị. Hạn chế của cách tiếp cận này là không tách biệt các mối
quan tâm của ứng dụng dẫn đến việc mở rộng và bảo trì hệ thống tốn thời gian và công sức.
Mẫu thiết kế tùy biến giao diện khắc phục các hạn chế trên. Việc áp dụng mẫu thiết kế tùy biến giao diện
cho hệ thống thư điện tử bảo mật được thể hiện trong hình 6.8 trong tồn văn luận án. Quy trình xây dựng một chủ
đề giao diện cho hệ thống thư điện tử bảo mật cũng được trình bày trong tồn văn luận án.
6.4.3. Bài học kinh nghiệm
Từ các trường hợp nghiên cứu và tổng hợp ý kiến của các chuyên gia chúng tôi rút ra một số kinh nghiệm
về mặt kỹ thuật khi hiện thực hóa mẫu thiết kế tùy biến giao diện trong các hệ thống thực tế:
•

Một bộ khung giao diện đồ họa người dùng cần định nghĩa một cơ chế để lưu trữ các tập tin và
thông tin cho từng chủ đề giao diện. Cách tiếp cận thông thường là (i) sử dụng một cấu trúc thư
mục (hay quy ước tên các tập tin) hoặc (ii) sử dụng dữ liệu cấu hình (lưu trữ trong hệ quản trị dữ
liệu hoặc tập tin) hoặc (iii) một sự kết hợp của cả hai hướng trên.

•

Các hiển thị có thể được định nghĩa bằng cách sử dụng một ngôn ngữ đánh dấu (markup language)
hoặc sự kết hợp giữa ngôn ngữ đánh dấu và ngôn ngữ lập trình.

•

Đối với ứng dụng web, trong nội tại một hiển thị, vị trí và phong cách giao diện cũng có thể tùy
biến cho nhiều kích thước màn hình khác nhau bằng cách áp dụng các nguyên tắc thiết kế phản hồi
(responsive design) như sử dụng truy vấn phương tiện (media query), phân chia kích thước theo
phần trăm, vân vân.

6.5.

Kết luận và hướng phát triển
Trong phần này chúng tôi đã đề xuất một mẫu thiết kế hỗ trợ tùy biến giao diện đồ họa người dùng cho các

ứng dụng đám mây, đặc biệt là các phần mềm đa người thuê và nhận biết ngữ cảnh.
Các công việc trong tương lai bao gồm việc chi tiết hóa làm thế nào để kết hợp mẫu thiết kế hỗ trợ tùy biến
giao diện đồ họa người dùng với mẫu thiết kế hỗ trợ tùy biến xử lý quy trình nghiệp vụ và mẫu thiết kế hỗ trợ tùy
biến dữ liệu; thực hiện việc đánh giá chi phí, cơng sức hoặc tính dễ sử dụng của mẫu thiết kế này bằng cách so sánh
một hệ thống xây dựng bằng mẫu thiết kế đề xuất với một hệ thống xây dựng bằng một cách tiếp cận khác như phát
triển hướng mơ hình.

22


Chương 7. Kết luận
7.1.

Các kết quả đạt được
Phát triển phần mềm trong môi trường đám mây, đặc biệt là phần mềm đa người thuê là xu hướng chính

trong kỹ nghệ phần mềm hiện đại. Qua quá trình nghiên cứu và thực hiện cho luận án, các đóng góp chính của
chúng tơi trong luận án này bao gồm:
•

Mẫu thiết kế người thuê phân cấp (chương 3, [CT1]) giải quyết vấn đề mơ hình hóa người th
phân cấp trong một hệ thống đám mây; hỗ trợ định danh, phân quyền việc truy cập tài nguyên của
hệ thống. Các nhà phát triển có thể hiệu chỉnh lại giải pháp cho phù hợp với các nhu cầu phân cấp
khác nhau trong từng ứng dụng cụ thể, cũng như tinh chỉnh lại các cấu trúc tĩnh và động để bổ sung
thêm các cơ chế bảo mật đặc thù.

•

Mẫu thiết kế hệ thống giao dịch (chương 4, [CT2]) giải quyết vấn đề về sự phức tạp của kiến
thức về lĩnh vực trong một hệ thống xử lý giao dịch; hỗ trợ mơ hình hóa các kiến thức về lĩnh vực
một cách nhất quán; cho phép các giao dịch thực thi một cách bảo mật theo một cung cách nhất
quán. Các nhà phát triển có thể tái sử dụng toàn bộ giải pháp cho một hệ thống xử lý giao dịch
trong đám mây hoặc tinh chỉnh lại các thành phần cho phù hợp với từng loại ứng dụng đặc thù.

•

Mẫu thiết kế khung ứng dụng web (chương 5, [CT3]) giải quyết vấn đề xây dựng khung ứng
dụng web đa người thuê theo phương pháp đặc thù; cung cấp mơ hình giúp các kiến trúc sư và các
nhà phát triển xây dựng, đánh giá và lựa chọn một khung ứng dụng web đa người th. Mơ hình
này hỗ trợ mở rộng ứng dụng bằng cách kế thừa và tổng hợp, tách biệt các mối quan tâm của ứng
dụng, cho phép xây dựng các mơ đun “cắm-chạy” và tích hợp các mô đun này vào hệ thống khi
đang vận hành.

•

Mẫu thiết kế tùy biến giao diện (chương 6, [CT4]) giải quyết vấn đề xây dựng tính tùy biến cho
giao diện đồ họa người dùng trong các phần mềm đa người th theo phương pháp đặc thù; cung
cấp mơ hình để phát triển, đánh giá và lựa chọn một khung giao diện đồ họa người dùng đa người
th. Mơ hình này cho phép xây dựng các giao diện khác nhau một cách mơ đun hóa, hỗ trợ triển

khai và kích hoạt các giao diện khi hệ thống đang vận hành. Các nhà phát triển cũng có thể sử dụng
các tri thức của mẫu thiết kế này để lựa chọn một bộ khung giao diện đồ họa người dùng phù hợp
với nhu cầu của mình.

Ngồi ra chúng tơi cũng cung cấp một bản nghiên cứu tổng quan về hiện trạng mẫu thiết kế hỗ trợ phát
triển phần mềm trên các hệ thống điện tốn đám mây [CT5]. Tính đúng đắn và tính khả dụng của các mẫu thiết kế
đề xuất được kiểm tra bằng các nghiên cứu trường hợp. Các mẫu thiết kế đề xuất đã được áp dụng vào các hệ thống
đa người thuê thực tế và đạt được kết quả khả quan.
Chúng tơi hy vọng rằng cơng trình luận án sẽ đóng góp một phần kiến thức vào lĩnh vực mẫu thiết kế hỗ
trợ phát triển phần mềm trong môi trường đám mây, tạo cảm hứng và đặt thêm nền móng để các nhà nghiên cứu
khác tiếp tục nghiên cứu trong lĩnh vực này.

23