Nghiên cứu ứng dụng mẫu thiết kế trong tương tác người - máy

ĐẠI HỌC QUỐC GIA HÀ
NỘI

TRƯỜNG ĐẠI HỌC CÔNG
NGHỆ












LƯƠNG THỊ NGỌC HÀ

NGHIÊN CỨU ỨNG DỤNG MẪU THIẾT KẾ
TRONG TƯƠNG TÁC NGƯỜI - MÁY
















LUẬN VĂN THẠC
SĨ

Hà Nội -
2011

ĐẠI HỌC QUỐC GIA HÀ
NỘI

TRƯỜNG ĐẠI HỌC CÔNG
NGHỆ












LƯƠNG THỊ NGỌC HÀ

NGHIÊN CỨU ỨNG DỤNG MẪU THIẾT KẾ
TRONG TƯƠNG TÁC NGƯỜI - MÁY




Ngành: Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
M
ã số: 60 48 10





LUẬN VĂN THẠC
SĨ

NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS Đặng Văn Đức











Hà Nội -
2011

III

MỤC LỤC

Lời cam đoan I
Lời cảm ơn II
MỤC LỤC III
Danh mục các ký hiệu, các chữ viết tắt V
Danh mục các hình vẽ VI
MỞ ĐẦU 1
Chương 1- TỔNG QUAN VỀ THIẾT KẾ GUI VÀ MẪU THIẾT KẾ. 3
1.1 Giới thiệu về UI 3

1.1.1 Định nghĩa UI 3
1.1.2 Tại sao cần thiết kế UI 3
1.2 Tính sử dụng được của hệ thống phần mềm 4
1.2.1 Định nghĩa tính sử dụng được 4
1.2.2 Thuộc tính của tính sử dụng 5
1.3 Nguyên lý thiết kế GUI 6
1.4 Qui trình thiết kế GUI 8
1.4.1 Đề xuất bài toán 8
1.4.2 Phân tích người sử dụng 8
1.4.3 Phân tích nhiệm vụ 9
1.4.4 Phác hoạ thiết kế 9
1.4.5 Prototype giấy 9
1.4.6 Prototype máy tính 10
1.4.7 Cài đặt 10
1.4.8 Kiểm thử bởi người sử dụng 10
1.5 Mẫu trong phát triển phần mềm 11
1.5.1 Giới thiệu về mẫu 11
1.5.2 Mẫu thiết kế 12
Chương 2 – MỘT SỐ MẪU ỨNG DỤNG TRONG THIẾT KẾ GUI 14
2.1 Các mẫu kiến trúc 14
2.2.1 Abstract Factory 14
2.2.2 Builder 15
2.2.3 Adapter 16
2.2.4 Façade 17
2.2.5 Observer 17
2.2.6 Mẫu MVC 18
2.2 Các mẫu đồ họa 19
2.2.1 Các mẫu về định vị 19
2.2.2. Các mẫu tổ chức trang 31
2.2.3 Các mẫu hành động 38

2.2.4 Đồ hoạ thông tin 46
Chương 3 – PHÁT TRIỂN GUI PHẦN MỀM THỬ NGHIỆM ĐỊNH HƯỚNG MẪU 51
3.1 Giới thiệu bài toán 51
3.2 Giải quyết bài toán 51
3.3 Phân tích người sử dụng và phân tích nhiệm vụ 52
3.3.1 Tiêu đề 52
3.3.2 Phân tích người sử dụng 52
3.3.3 Phân tích nhiệm vụ 54
3.4 Phác hoạ thiết kế 59
3.4.1 Thiết kế tổng quan 59
3.4.2 Kịch bản 59
IV

3.5 Xây dựng Prototype giấy 61
3.5.1 Login: 61
3.5.2 Sametime Instant Message. 65
3.5.3 Sametime Call 65
3.5.4 Sametime Video Call 65
3.6 Xây dựng Prototype máy tính 66
3.6.1 Log in 66
3.6.2 Sametime Instant Message. 70
3.6.3 Sametime Call 70
3.6.4 Sametime Video Call 71
3.7 Một số mẫu ứng dụng trong thiết kế Sametime 71
3.8 Cài đặt 74
3.9 Kiểm thử bởi người sử dụng 74
3.9.1 Thiết kế 74
3.9.2 Cài đặt 76
3.9.3 Đánh giá 78
KẾT LUẬN 79

TÀI LIỆU THAM KHẢO 80

V


Danh mục các ký hiệu, các chữ viết tắt

Thuật ngữ, chữ
viết tắt
Giải thích
HCI
Human - Computer Interaction
Tương tác người – máy tính
UI
User Interface
Giao diện người sử dụng
GUI
Graphical User Interface
Giao diện đồ hoạ

VI


Danh mục các hình vẽ
Hình 1-1. Framework của ISO 9241-11 5
Hình 2-1. Mô hình mẫu Façade. 17
Hình 2-2. Mô hình hoạt động của mẫu MVC 19
Hình 2-3. Giao diện sử dụng mẫu Clear Entry Point 19
Hình 2-4. Giao diện sử dụng mẫu Hub and Spoke 21
Hình 2-5. Giao diện sử dụng mẫu Pyramid 23

Hình 2-6. Mô hình Pyramid 24
Hình 2-7. Giao diện sử dụng mẫu Modal Panel 24
Hình 2-8. Giao diện sử dụng mẫu Sequence Map 25
Hình 2-9. Giao diện sử dụng mẫu Breadcrumbs 26
Hình 2-10. Giao diện sử dụng mẫu Annotated Scrollbar 27
Hình 2-11. Giao diện sử dụng mẫu Color-Coded Sections 29
Hình 2-12. Giao diện sử dụng mẫu Escape Hatch 30
Hình 2-13. Giao diện sử dụng mẫu Visual Framework 31
Hình 2-14. Giao diện sử dụng mẫu Center Stage 32
Hình 2-15. Giao diện sử dụng mẫu Titled Sections 34
Hình 2-16. Giao diện sử dụng mẫu Card Stack 35
Hình 2-17. Giao diện sử dụng mẫu Closable Panels 36
Hình 2-18. Giao diện sử dụng mẫu Movable Panels 37
Hình 2-19. Giao diện sử dụng mẫu Button Groups 39
Hình 2-20. Giao diện sử dụng mẫu Action Panel 40
Hình 2-21. Giao diện sử dụng mẫu Prominent “Done” Button 42
Hình 2-22. Giao diện sử dụng mẫu Preview 43
Hình 2-23. Giao diện sử dụng mẫu Progress Indicator 44
Hình 2-24. Giao diện sử dụng mẫu Cancelability 45
Hình 2-25. Giao diện sử dụng mẫu Overview Plus Detail 46
Hình 2-26. Giao diện sử dụng mẫu Datatips 48
Hình 2-27. Giao diện sử dụng mẫu Local Zooming 49
Hình 3-1. Giao diện Log in. 60
Hình 3-2. Giao diện Sametime. 60
Hình 3-3. Giao diện chat 61
Hình 3-4. Giao diện Video Call 61
Hình 3-5. Giao diện Log in với tài khoản haluong. 62
Hình 3-6. Giao diện Sametime với tài khoản haluong. 62
Hình 3-7. Giao diện File Menu. 63
Hình 3-8. Giao diện Edit Menu. 63

Hình 3-9. Giao diện View Menu. 64
Hình 3-10. Giao diện Tool Menu. 64
Hình 3-11. Giao diện chát với Nguyen Minh Tuyen. 65
Hình 3-12. Giao diện Call với Luong Thanh Tung. 65
Hình 3-13. Giao diện Video Call với Luong Thanh Tung. 66
Hình 3-14. Giao diện tạo tài khoản mới. 66
Hình 3-15. Giao diện Log in bằng prototype máy tính. 67
Hình 3-16. Giao diện Sametime bằng prototype máy tính. 67
Hình 3-17. Giao diện File Menu bằng prototype máy tính. 68
Hình 3-18. Giao diện Edit Menu bằng prototype máy tính. 68
Hình 3-19. Giao diện View Menu bằng prototype máy tính. 69
Hình 3-20. Giao diện Tool Menu bằng prototype máy tính. 69
Hình 3-21. Giao diện Help Menu bằng prototype máy tính. 70
VII

Hình 3-22. Giao diện chat bằng prototype máy tính. 70
Hình 3-23. Giao diện Call bằng prototype máy tính. 70
Hình 3-24. Giao diện Video Call bằng prototype máy tính. 71
Hình 3-25. Giao diện Notice sử dụng mẫu Model Panel. 71
Hình 3-26. Giao diện New Contact sử dụng mẫu Button Groups. 72
Hình 3-27. Giao diện Sametime sử dụng mẫu Closable Panels. 72
Hình 3-28. Giao diện Forgotten your password. 73
Hình 3-29. Giao diện Font sử dụng mẫu Card Stack. 74
Hình 3-26. Giao diện New Contact. 75
Hình 3-28. Giao diện Chat History. 75
Hình 3-29. Giao diện Send File. 75
Hình 3-30. Giao diện cài đặt Log In. 76
Hình 3-31. Giao diện cài đặt Menu Sametime. 77

1

MỞ ĐẦU
Tương tác người – máy (HCI – Human Computer Interaction) là lĩnh vực
nghiên cứu, lập kế hoạch và thiết kế về việc con người và máy tính cùng làm
việc với nhau như thế nào để nhu cầu của con người được thoả mãn cao nhất.
Nói cách khác HCI là lĩnh vực nghiên cứu về tương tác giữa con người, máy
tính và nhiệm vụ. HCI liên quan đến việc hiểu sự tương tác của con người và hệ
thống trên cơ sở máy tính để thực hiện nhiệm vụ và hiểu biết về việc thiết kế các
hệ thống tương tác. HCI là đa lĩnh vực, nó sử dụng tri thức của nhiều ngành
khác nhau như: khoa học máy tính, trí tuệ nhân tạo, nhân loại học, công thái học,
ngôn ngữ học, triết học, nghệ thuật, xã hội học, thiết kế, tâm lý học, kỹ nghệ và
sinh lý học. HCI là lĩnh vực rộng, nó liên quan đến nhiều ngành khoa học.
Nhưng trong phạm vi người sử dụng tin học thì ta chỉ quan tâm đến lĩnh vực
thiết kế giao diện người sử dụng cho hệ thống tương tác.
Giao diện người sử dụng (UI – User Interface) là một phần của máy tính
và của hệ thống phần mềm mà con người có thể nhìn, sờ, nói với nó. Nếu hệ
thống có giao diện tốt thì chúng ta sẽ dễ sử dụng, sản phẩm dễ bán, thời gian lập
trình được giảm bớt và tăng năng suất lao động. Do đó việc thiết kế giao diện
người sử dụng trở nên rất quan trọng. Nhưng thiết kế giao diện tốt cho một hệ
thống thông tin không phải là việc làm dễ dàng. Để có thể thiết kế một giao diện
tốt, tăng tính sử dụng và thiết kế được nhanh chóng thì chúng ta phải sử dụng
những kinh nghiệm, những tri thức và những kết quả đã có từ trước. Đó chính là
mẫu thiết kế. Do đó luận văn nghiên cứu “Nghiên cứu ứng dụng mẫu thiết kế
trong tương tác người – máy”.
Mục tiêu của quá trình thiết kế là đạt được giao diện người sử dụng có
tính sử dụng cao. Quá trình thiết kế không phải chỉ một lần mà phải thực hiện
lặp các giai đoạn như thiết kế, cài đặt và đánh giá. Dựa vào kết quả đánh giá để
tái thiết kế giao diện. Nếu thiết kế giao diện bằng mã trình sẽ mất rất nhiều thời
gian, khi được đánh giá, góp ý để chỉnh sửa sẽ rất khó khăn. Một số thiết kế có

nhiều thiếu sót nghiêm trọng nhưng ta không nỡ vứt bỏ đi vì đã làm việc cật lực
để có nó. Để khắc phục điều đó thì có rất nhiều công cụ phần mềm với khả năng
hỗ trợ việc thiết kế giao diện người dùng. Và có rất nhiều các trung tâm mở các
lớp dạy sử dụng phần mềm để thiết kế giao diện người dùng.
Luận văn sử dụng công cụ phần mềm để thiết kế giao diện đồ hoạ (GUI –
Graphical User Interface) là GUI Design Studio. Khi dùng GUI Design Studio,
bản mẫu được xây dựng nhanh hơn nhiều so với cài đặt cuối cùng, ta có thể
đánh giá sớm và nhận được phản hồi sớm về những điểm tốt và điểm xấu của
thiết kế. Nếu phát hiện vấn đề trong thiết kế thì bản mẫu dễ dàng được chỉnh sửa
2

vì nó được xây dựng nhanh. Quan trọng nhất là nếu thiết kế có nhiều thiếu sót
nghiêm trọng thì bản mẫu có thể bị loại bỏ.
Luận văn được bố cục thành 3 chương. Chương 1 tìm hiểu về thiết kế
GUI và mẫu thiết kế. Chương 2 trình bầy về một số mẫu ứng dụng trong thiết kế
GUI. Chương 3 phát triển GUI phần mềm thử nghiệm định hướng mẫu.
3


Chương 1- TỔNG QUAN VỀ THIẾT KẾ GUI VÀ MẪU THIẾT KẾ.
Chương 1 tập chung tìm hiểu thiết kế GUI và mẫu thiết kế. Nội dung của
chương được bố cục thành 5 mục. Mục 1 giới thiệu về UI. Mục 2 trình bày tính
sử dụng được của hệ thống phần mềm. Mục 3 đưa ra những nguyên lý thiết kế
GUI. Mục 4 trình bày quy trình thiết kế GUI. Mục 5 tìm hiểu mẫu trong phát
triển phần mềm.
1.1 Giới thiệu về UI
1.1.1 Định nghĩa UI
Trong nhiều tài liệu, khái niệm UI có ý nghĩa tương tự với HCI. Nhưng sự
thật UI là tập con của lĩnh vực nghiên cứu HCI. UI được hiểu như sau:
UI bao gồm các khái niệm về hệ thống máy tính và cách thức sử dụng

chúng để hoàn thành các công việc khác nhau của người sử dụng. Do vậy UI
không chỉ là những cái gì mà con người có thể nhìn, sờ và nghe thấy mà còn hơn
thế.
UI là tập hợp các phương tiện để con người tương tác với máy móc, thiết
bị, chương trình máy tính hay hệ thống phức tạp [3].
UI được hiểu là tiến trình thiết kế phần mềm ghép nối sao cho hệ thống
máy tính trở nên hiệu quả, dễ sử dụng và làm được những gì con người muốn
chúng làm.
UI là bộ mặt, là thành phần trung gian để thực hiện giao tiếp giữa con
người với máy tính. Do đó ta cần nghiên cứu về thiết kế UI.
1.1.2 Tại sao cần thiết kế UI
Có rất nhiều lý do để tập trung nghiên cứu thiết kế UI. Sau đây là một vài
lý do chính:
UI là điểm chính nơi giao tiếp giữa người sử dụng và hệ thống máy tính.
Nó là một phần của hệ thống, nơi mà người sử dụng nhìn, sờ, nghe và giao tiếp.
Người sử dụng không thể xâm nhập vào hệ thống máy tính nếu không có UI.
Phụ thuộc vào giao diện mà hệ thống có thể thắng lợi hay thất bại trong
việc giúp người sử dụng thực hiện nhiệm vụ. Nhiều người sử dụng đánh giá hệ
thống thông qua UI, họ cho rằng hệ thống là tồi nếu UI của nó tồi. UI tồi làm hệ
thống khó sử dụng đôi khi rất nguy hiểm khi sử dụng hệ thống với UI tồi.
 Hệ thống liệu pháp bức xạ chữa bệnh ung thư Therac-25 đã gây
chết người do có UI tồi [2].
 Hệ thống rada Aegis trên tàu chiến USS Vincennes đã bắn nhầm
máy bay dân sự của Iran cũng do có UI thiết kế tồi [2].
4

Với thiết kế giao diện tồi, các vấn đề sau đây sẽ nảy sinh: năng suất lao
động thấp, thời gian học sử dụng và mức độ lỗi xảy ra không chấp nhận được.
Do vậy, dẫn tới việc người sử dụng từ chối sử dụng hệ thống.
Thông thường mã trình xử lý giao diện với người sử dụng trong phần

mềm ứng dụng chiếm khoảng 50-70%, do vậy nguồn lực (thời gian, kinh phí)
dành cho phát triển UI là khá lớn. Theo thống kê với 74 dự án phần mềm thực
hiện vào năm 1992 thì UI chiếm khoảng 50% thời gian thiết kế, thời gian cài
đặt, thời gian bảo trì và kích thước mã trình.
Phần mềm giao diện ngày càng phức tạp, đặc biệt với GUI. Công việc
phát triển GUI là khó khăn vì tương tác giữa người sử dụng và hệ thống là khá
phức tạp.
GUI tốt làm giảm chi phí cho công việc bảo trì hệ thống.
Việc thiết kế UI tốt là rất quan trọng trong nhiều lĩnh vực. Nhưng giao
diện đó phải đảm bảo có tính sử dụng được.
1.2 Tính sử dụng được của hệ thống phần mềm
1.2.1 Định nghĩa tính sử dụng được
Tính sử dụng được (Usability) là chỉ số quan trọng đối với hệ thống phần
mềm tương tác. Tính sử dụng được Bennett đề xuất lần đầu vào năm 1979, sau
đó có nhiều nghiên cứu khác. Vào năm 1991, Shacked định nghĩa tính sử dụng
như “khả năng hệ thống được sử dụng bởi con người một cách dễ dàng và hiệu
quả”.
Tính sử dụng được xác định bởi “người sử dụng có thể sử dụng tốt các
chức năng hệ thống như thế nào”
Hiện tại có nhiều chuẩn: ISO 9241-11 (1998), ISO/IEC 9126 (2001),
IEEE Std.610.12 (1990) và mô hình khái niệm Metrics for Usability Standards
in Computing –MUSiC (1997) về tính sử dụng
Theo ISO 9241-11, tính sử dụng được xem như phạm vi trong đó sản
phẩm được sử dụng bởi nhóm người xác định để đạt được những mục tiêu xác
định với tính hiệu quả, năng suất và sự thoả mãn trong ngữ cảnh sử dụng xác
định [3].
 Mục tiêu: Kết quả dự kiến.
 Hiệu quả: Đem lại kết quả đúng như dự kiến. Đạt được mục tiêu một cách
chính xác và đầy đủ (ví dụ tốc độ thực hiện cao, không lỗi).
 Năng suất: Tiêu hao năng lượng và tài nguyên phù hợp để đạt được mục

tiêu một cách chính xác và đầy đủ. Là thước đo mức độ cố gắng của
người sử dụng để đạt được mục tiêu đề ra.
5

 Sự thỏa mãn: Không bực dọc, lo lắng và có quan điểm tích cực với việc
sử dụng sản phẩm.
 Ngữ cảnh ứng dụng: Người sử dụng, nhiệm vụ, thiết bị (phần cứng, phần
mềm, …), môi trường vật lý, xã hội.
 Nhiệm vụ: Các hoạt động cần thiết để đạt được mục tiêu.
Framework của ISO 9241-11: Nhằm đặc tả các thành phần tính sử dụng
và quan hệ giữa chúng. Khung làm việc hỗ trợ đánh giá sản phẩm:

Hình 1-1. Framework của ISO 9241-11
Với khung làm việc của tính sử dụng thì: Hiệu năng (performance): hiệu
quả và năng suất. Do đó hiệu năng và sự thỏa mãn của người sử dụng được sử
dụng vào việc đo tính sử dụng. Độ đo về hiệu năng và sự thỏa mãn của người sử
dụng là nền tảng của sự so sánh tính sử dụng của các hệ thống khác nhau. Tính
sử dụng có thể được cải thiện bằng cách tích hợp các đặc trưng, thuộc tính đã
biết trong ngữ cảnh sử dụng cụ thể.
Tính sử dụng được định nghĩa theo nhiều cách khác nhau trong các tài
liệu khác nhau. Các chuẩn hoặc các tác giả khác nhau đã đề xuất tập khác nhau
về các thuộc tính của tính sử dụng được.
1.2.2 Thuộc tính của tính sử dụng
Các thuộc tính của tính sử dụng được do Nielsen đề xuất năm 1993 gồm
sáu thuộc tính sau:
 Hiệu quả: Tính chính xác và tính đầy đủ mà với nó người sử dụng đạt
được mục tiêu xác định trước.
 Tính học được: Hệ thống có dễ học không?
 Năng suất: Một khi đã dễ học, có được sử dụng nhanh không?
 Tính nhớ được: Có dễ nhớ những gì đã học?

 Các lỗi: Ít lỗi xảy ra và dễ vượt qua lỗi?
 Thoả mãn mục đích: Có thích thú sử dụng hệ thống?
6

Năm 1994, Mandel đã liệt kê 10 vi phạm ảnh hưởng đến tính sử dụng
theo báo cáo của các chuyên gia tại hãng IBM. Bao gồm:
1. Menu và biểu tượng nhập nhằng.
2. Ngôn ngữ chỉ cho phép đi theo một hướng trong hệ thống.
3. Hạn chế đầu vào và thao tác trực tiếp.
4. Hạn chế lựa chọn và điểm nổi bật.
5. Trình tự các bước không rõ ràng.
6. Nhiều bước quản lý giao diện hơn thực hiện nhiệm vụ.
7. Liên kết phức tạp với các ứng dụng khác và giữa các ứng dụng.
8. Phản hồi và khẳng định không phù hợp.
9. Hệ thống kém đề phòng và kém thông minh.
10. Các thông điệp lỗi, trợ giúp, tài liệu không phù hợp.
Có rất nhiều các tiêu chí để đạt được tính sử dụng của hệ thống. Dựa vào
các tiêu chí này người ta xây dựng nguyên lý thiết kế hệ thống có tính sử dụng
được. Nguyên lý thiết kế GUI thoả mãn các nguyên lý thiết kế hệ thống có tính
sử dụng được.
1.3 Nguyên lý thiết kế GUI
Don Norman đề xuất sáu nguyên lý thiết kế để hệ thống có tính sử dụng,
bao gồm: Sự rõ ràng, phản hồi, ràng buộc, ánh xạ, nhất quán, gợi ý [2].
 Sự rõ ràng: được xem như những phần của hệ thống liên quan đến tương
tác phải được nhìn thấy. Sự rõ ràng có thể là nguyên tắc cơ bản nhất trong
mô hình giao tiếp với người sử dụng. Giao diện người sử dụng cần có khả
năng giúp người sử dụng nhận biết trạng thái hiện hành của hệ thống và
cần biết phải thực hiện thao tác nào.
Ví dụ: Khi di chuột đến một vị trí bất kỳ trên màn hình, người sử
dụng cần được biết cái gì xảy ra khi nhấn chuột.

 Sự phản hồi: là cái hệ thống thể hiện khi người sử dụng thực hiện hành
động. Khi bất kỳ cái gì thay đổi, nó cần phải được nhìn thấy.
Ví dụ: Khi xoá tệp hệ thống không chỉ đơn giản hiển thị “sẵn sàng”.
Khi thực hiện hành động thì phím có thể bị nhấn hay nhả, thanh trượt dịch
chuyển hay các đối tượng dịch chuyển theo con chạy chuột.
Các loại phản hồi bao gồm: thị giác, âm thanh và xúc giác.
 Sự ràng buộc: Mức độ khó sử dụng của một hệ thống liên quan trực tiếp
đến tổng số khả năng. Sự ràng buộc là các giới hạn vật lý, ngữ nghĩa, văn
hóa và logíc trên tổng số khả năng.
7

Ví dụ với đồ chơi xe gắn máy (12 chi tiết), thiết kế của nó tận dụng
lợi thế ràng buộc để cho ta khả năng lắp ráp đơn giản. Ta có các ràng buộc
sau:
 Vật lý: Bánh trước chỉ lắp vừa vào một vị trí.
 Ngữ nghĩa: Tài xế ngồi trên ghế và mặt quay về phía trước.
 Văn hóa: Đèn đỏ lắp phía sau, đèn vàng lắp phía trước.
 Logic: Hai đèn màu xanh và 2 đèn màu trắng đi với nhau.
 Qui ước: là ràng buộc về văn hoá. Các ràng buộc này ban đầu là tuỳ ý,
nhưng được chấp nhận dần theo thời gian. Tuy nhiên các quy ước vẫn còn
rất khác nhau nó phụ thuộc vào nền văn hóa khác nhau: Ví dụ:
 Tắt công tắc đèn: Mỹ: Bật xuống; Anh: Bật lên.
 Mở van vòi nước: Mỹ: Vặn ngược chiều kim đồng hồ; Anh: Vặn
theo chiều kim đồng hồ.
 Màu đỏ: Mỹ: Nguy hiểm; Ai cập: Chết chóc; Ấn độ: Sống; Trung
quốc: Hạnh phúc.
 Bàn phím máy tính: Tiếng Anh: QWERTY; Pháp: AZERTY.
 Ánh xạ: là quan hệ giữa các điều khiển và ảnh hưởng của nó trên hệ
thống. Điều khiển là khái niệm liên quan đến các đối tượng đồ họa trong
giao diện phần mềm. Ánh xạ tự nhiên đem lại lợi thế của sự tương ứng vật

lý và các chuẩn văn hóa. Ánh xạ tự nhiên phải tương quan với tri thức về
thế giới thực. Ví dụ:
 Xoay tai lái ôtô về phía phải để rẽ phải.
 Sử dụng âm thanh lớn hơn để nhập số lớn hơn và ngược lại trong
giao diện người sử dụng sử dụng âm thanh.
 Nhất quán: trong việc nhìn và cảm giác là yếu tố mấu chốt trong tương
tác người máy tốt. Ví dụ:
 Bố trí thực đơn nhất quán với chuẩn Windows.
 Bố trí nhất quán các phím OK và Cancel trong các ứng dụng
Windows.
 Sự gợi ý: là tập các thao tác hay thủ tục có thể thực hiện trên đối tượng.
“Gợi ý quan sát” là cái người sử dụng nghĩ rằng nó có thể thực hiện trên
đối tượng. Khả năng tưởng tượng liên quan đến khả năng người sử dụng
xác định cách sử dụng đối tượng chỉ bằng quan sát chúng.
Đối với các đối tượng vật lý, hình dáng bề ngoài chỉ ra cách sử dụng
nó như thế nào. Ví dụ:
 Cái ghế gợi ý ngồi.
 Tay cửa gợi ý xoay.
8

Sự gợi ý GUI:
 Con chạy chuột gợi ý trỏ.
 Phím chuột gợi ý nhấn.
 Màn hình gợi ý sờ.
 Bàn phím gợi ý gõ.
Từ nguyên lý thiết kế GUI ta xây dựng được quy trình thiết kế GUI.
1.4 Qui trình thiết kế GUI
Tính sử dụng là mục tiêu đầu tiên của việc thiết kế hệ thống tương tác.
Quy trình thiết kế GUI giúp chúng ta nâng cao khả năng phân tích, thiết kế, cài
đặt và kiểm thử giao diện người sử dụng. Thiết kế UI là tiến trình lặp, nên UI

không chỉ được xây dựng một lần mà được thực hiện lặp nhiều lần để có được
prototype ngày càng đầy đủ, độ tin cậy ngày càng cao hơn.
1.4.1 Đề xuất bài toán
Vấn đề: Mô tả vấn đề mà bài toán sẽ giải quyết dưới góc nhìn của người
sử dụng. Mục tiêu của người sử dụng là gì?
Người sử dụng: Tính cách hóa nhóm người sử dụng đối mặt với vấn đề
sẽ giải quyết. Tìm ra các đặc điểm của người sử dụng.
Giải pháp: Mô tả giải pháp chính có thể áp dụng để giải quyết vấn đề.
Không cần mô tả chi tiết ở đây vì giải pháp có thể tìm ra trong khi xây dựng và
đánh giá một vài prototype ở giai đoạn sau.
1.4.2 Phân tích người sử dụng
Phân tích người sử dụng là quá trình thu thập thông tin về người sử dụng
cho bản thiết kế đầu tiên. Mục tiêu của phân tích người sử dụng:
 Nhận biết ai là người sử dụng phần mềm do ta thiết kế?
 Kỹ năng và mức độ của người sử dụng?
 Cách thức sử dụng hệ thống của người sử dụng?
 Hiểu biết môi trường sử dụng hệ thống tương tác
 Quan hệ giữa người sử dụng với người sử dụng khác trong tổ chức
(làm việc độc lập hay giúp đỡ nhau)
Phân nhóm người sử dụng:
 Người bắt đầu, người có kinh nghiệm hay là chuyên gia
 Tần suất sử dụng: Thường xuyên sử dụng hay thỉnh thoảng
Các kỹ thuật phân tích người sử dụng:
 Tìm ra người đại diện để thu thập từ họ những thông tin về người
sử dụng
 Trả lời bảng câu hỏi thăm dò để có được các tính chất nổi trội
9

 Kỹ thuật khác là phỏng vấn trực tiếp người sử dụng
 Quan sát người sử dụng thực hiện nhiệm vụ hàng ngày để biết các

chi tiết về ngữ cảnh và môi trường sử dụng.
1.4.3 Phân tích nhiệm vụ
Phân tích nhiệm vụ là tiến trình phân tích cách mà người sử dụng thực
hiện nhiệm vụ của họ với hệ thống. Phân tích chi tiết các nhiệm vụ dẫn tới mô tả
nhiệm vụ rõ ràng, đảm bảo rằng giao diện người sử dụng phù hợp với nhiệm vụ
của người sử dụng. Các câu hỏi cần trả lời khi phân tích nhiệm vụ:
 Người sử dụng làm cái gì?
 Họ làm việc bằng công cụ gì?
 Họ cần có hiểu biết gì khi làm việc?
Kỹ thuật phân tích nhiệm vụ:
 Phỏng vấn, quan sát người sử dụng thực hiện công việc hàng ngày.
 Phân rã chức năng
1.4.4 Phác hoạ thiết kế
Sau khi phân tích nhiệm vụ, hãy hình thành kịch bản (ví dụ thực, cụ thể về
nhiệm vụ). Mô tả nhiệm vụ là khá trừu tượng thì các kịch bản cần được mô tả
đầy đủ và chi tiết.
Thiết kế ban đầu: biểu diễn phác họa các cửa sổ, hộp thoại, cây thực đơn,
các điều khiển dành cho người sử dụng và diễn giải ngắn gọn về các chức năng
của chúng.
Kịch bản: Với mỗi kịch bản, mô tả việc sử dụng giao diện ban đầu như
thế nào để thực hiện nhiệm vụ. Phác họa mô tả hình dáng giao diện tại một số
điểm quan trọng của nhiệm vụ. Khi phác họa giao diện, không cần quá chi tiết
như chọn nhãn, biểu tượng hay bố trí màn hình. Hãy để cho UI thật đơn giản mà
tập trung vào mô hình dự định giao tiếp với người sử dụng.
1.4.5 Prototype giấy
Prototype là lựa chọn tuyệt vời cho những vòng lặp thiết kế đầu tiên.
Prototype giấy là mô hình vật lý của giao diện làm từ giấy.
 Giao diện được phác họa bằng tay trên các mẩu giấy.
 Mẩu giấy biểu diễn các phần tử khác nhau như thực đơn, hộp thoại
hay cửa sổ.

 Tương tác: trỏ bằng tay tương ứng với trỏ bằng chuột, viết trên các
mẩu giấy tương ứng với gõ bàn phím.
Ta cần xây dựng Prototype giấy vì:
10

 Phác họa bằng tay trên giấy sẽ nhanh hơn việc viết mã trình hay
phác họa bằng máy tính.
 Giấy là dễ thay đổi.
 Xây dựng nhanh.
 Phác họa bằng tay làm tăng phản hồi nhận được từ người sử dụng.
 Không đòi hỏi kỹ năng đặc biệt nào.
Công cụ xây dựng prototype giấy:
 Bảng áp phích trắng (11” x14”): Làm nền, khung cửa sổ.
 Số lượng lớn các thẻ chỉ mục (4” x 6” , 5” x8”): Làm menus,
window contents, và dialog boxes.
 Hồ dán: Để dán các mẩu giấy.
 Băng giấy trắng: Để làm text fields, checkboxes, short messages.
 Giấy bóng kính: Để người sử dụng “typing” (viết lên chúng).
 Máy sao chụp: Để tạo ra nhiều phần tử trong bản mẫu.
 Bút, kéo và băng giấy.
1.4.6 Prototype máy tính
Prototype máy tính là mô phỏng phần mềm tương tác. Sử dụng prototype
máy tính để khám phá thiết kế đồ họa của giao diện cuối cùng.
 Bố trí màn hình: Rõ ràng, phức tạp hay làm rối bời hay không?
Người sử dụng có thể tìm thấy các phần tử quan trọng không?
 Màu, font, icon và các phần tử khác: Lựa chọn phù hợp chưa?
 Phản hồi tương tác: Có khả năng thông báo với người sử dụng bằng
thông điệp, thanh trạng thái, thay đổi hình dáng con chạy và cách
phản hồi khác.
Kỹ thuật để xây dựng prototype máy tính là Storyboard. Storyboard là

trình tự của các màn hình cố định. Mỗi màn hình có một hoặc nhiều điểm nóng
(hotspots) hoặc hyperlink mà ta có thể nhấn chuột để nhảy đến màn hình khác.
StoryBoard được sử dụng cho các kịch bản, chuyển dần đến chi tiết hơn. Nó là
dãy các phác thảo/khung hình cơ bản.
1.4.7 Cài đặt
Thực hiện cài đặt UI demo theo prototype đã xây dựng. Hoàn thiện cài đặt
các nhiệm vụ quan trọng đã nhận ra khi phân tích nhiệm vụ để người sử dụng có
thể kiểm thử. Cài đặt cần có cả thành phần chính và hệ thống.
1.4.8 Kiểm thử bởi người sử dụng
Kiểm thử bởi người sử dụng là kỹ thuật được sử dụng để đánh giá sản
phẩm bằng cách người sử dụng thử nghiệm nó. Phương pháp này cho phép quan
11

sát trực tiếp người sử dụng khi họ đang sử dụng ứng dụng. Ta có các bước kiểm
thử bởi người sử dụng:
 Phát triển kế hoạch kiểm thử: Mô tả mục đích kiểm thử, lý lịch
người sử dụng, phương pháp, danh sách nhiệm vụ.
 Chọn lựa người tham gia: Chọn người sử dụng, phân nhóm, quản lý
cơ sở dữ liệu người sử dụng
 Chuẩn bị vật liệu kiểm thử: Kịch bản nhiệm vụ, mẫu thu thập dữ
liệu, hướng dẫn thảo luận, các câu hỏi sau kiểm thử, lập danh sách
các kiểm thử sẽ thực hiện.
 Thực hiện kiểm thử thí điểm (Pilot Test)
 Thực hiện kiểm thử thật (Real Test)
 Phân tích và báo cáo cuối cùng
Để thiết kế UI một cách nhanh chóng thì ngoài thiết kế theo quy trình
thiết kế GUI ta cũng cần phải sử dụng những kinh nghiệm, tri thức và kết quả đã
có từ trước. Các kết quả này được trừu tượng hoá thành một mẫu.
1.5 Mẫu trong phát triển phần mềm
1.5.1 Giới thiệu về mẫu

Mục đích của việc phát triển phần mềm là tạo ra phần mềm đáp ứng được
yêu cầu của người sử dụng. Do đó phát triển phần mềm cần hạn chế việc thoái
hóa thiết kế, phần mềm cần có tính sử dụng lại cao.
Việc sử dụng lại phần mềm là một cách tiếp cận để xúc tiến quá trình phát
triển phần mềm. Một câu hỏi đặt ra là: “ta có thể sử dụng lại gì và sử dụng như
thế nào?”. Mã nguồn thường được sử dụng lại nhiều nhất, ta duyệt Internet tìm
mã nguồn mở mà ta có thể mượn, sửa đổi, và sử dụng lại. Còn việc sử dụng lại
những thiết kế được làm ít hơn việc sử dụng lại mã. Vì sự phức tạp và khó khăn
của việc xây dựng thiết kế và khởi tạo chúng. Hơn nữa, mã thì hữu hình hơn
thiết kế, ta có thể triển khai và thực thi mã với ít hoặc không có sự cải biến nào.
Tuy nhiên, rất mạo hiểm để sửa đổi mã nguồn. Ta có thể làm hỏng sự toàn vẹn
thành phần và tính hoạt động của nó được xây dựng trước đấy. Bởi vậy, nhiều
nhà phát triển phần mềm thích sử dụng lại ý tưởng của giải pháp và thực hiện nó
theo cách của họ. Những ý tưởng của giải pháp được sử dụng lại này, nó được
giới thiệu ở mức cao hơn, đó chính là mẫu (pattern).
Một mẫu mô tả một vấn đề thường xuyên xảy ra trong thiết kế và thực thi
phần mềm, mô tả giải pháp của vấn đề theo cách mà nó được sử dụng lại. Một
cặp vấn đề/giải pháp có thể được áp dụng trong những ngữ cảnh mới. Mẫu được
giới thiệu là tài liệu tốt để thực hành thiết kế; là phương tiện phổ biến kiến thức
12

và kinh nghiệm từ những chuyên gia đến người tập sự. Mẫu là lời khuyên từ
những người thiết kế giàu kinh nghiệm, giúp đỡ những người thiết kế trong tình
huống mới. Vì vậy, ta có thể sử dụng mẫu để cải thiện thiết kế hệ thống của
mình, có thể áp dụng mẫu tại bất kỳ thời điểm nào trong một chu trình của dự
án.
Có rất nhiều loại mẫu, nhưng trong giới hạn của luận văn ta chỉ nghiên
cứu về các mẫu thiết kế.
1.5.2 Mẫu thiết kế
Mẫu thiết kế là khái niệm rộng và bao quát trong công đoạn thiết kế phần

mềm. Giống như các yêu cầu của thiết kế và phân tích hướng đối tượng, việc sử
dụng các mẫu cũng cần đạt được khả năng tái sử dụng các giải pháp chuẩn đối
với các vấn đề thường xuyên xảy ra. Mẫu thiết kế nhằm thúc đẩy sử dụng lại
trong pha thiết kế vì chúng cung cấp từ vựng chung cho thiết kế, chúng cung cấp
những phương tiện để hiểu thiết kế, và chúng được tạo thành khối hợp nhất từ đó
xây dựng những ứng dụng phức tạp hơn.
Mẫu thiết kế không đơn thuần là một bước nào đó trong giai đoạn phát
triển phần mềm mà nó đóng vai trò là sáng kiến để giải quyết một bài toán thông
dụng nào đó. Các giai đoạn phần mềm vẫn hoàn chỉnh mà không có mẫu thiết
kế, nhưng sự góp mặt của mẫu thiết kế sẽ giúp cho việc xác định bài toán cần
giải quyết nhanh gọn hơn, từ đó đưa ra cách giải quyết hợp lý.
Mẫu thiết kế không chỉ được sử dụng để xác định bài toán và cách giải
quyết mà mẫu thiết kế còn được sử dụng nhằm cô lập các thay đổi trong mã
nguồn, từ đó làm cho hệ thống có khả năng tái sử dụng cao.
Cũng giống như mẫu trong phần mềm nói chung, mẫu thiết kế là sự hình
thức hóa của các cách tiếp cận một vấn đề thường gặp trong một ngữ cảnh cụ
thể. Mỗi mẫu thiết kế là một giải pháp cho một vấn đề thiết kế cụ thể trong một
ngữ cảnh xác định. Giải pháp được đưa ra đã được kiểm nghiệm, được sử dụng
nhiều lần đem lại kết quả tốt và do đó được trìu tượng hóa thành một mẫu. Mẫu
thiết kế chính là kinh nghiệm thiết kế được đúc kết lại thành mẫu chuẩn mực. Sử
dụng mẫu thiết kế người thiết kế không phải thiết kế hệ thống từ đầu, không
phải giải quyết lại những bài toán đã được giải quyết mà sử dụng các kinh
nghiệm, tri thức và kết quả đã có từ trước. Điều này làm cho chất lượng thiết kế
tốt hơn, tăng tính sử dụng của bản thiết kế và tạo điều kiện cho người thiết kế
tập trung vào sáng tạo những cái mới.


13

Kết luận

Mỗi sản phẩm phần mềm đều có một yếu tố quyết định đến sự lựa chọn
của khách hàng, nó góp phần không nhỏ vào sự thành công của sản phẩm, đó là
UI - bộ mặt của sản phẩm. UI như một bảng chỉ dẫn không lời, thực hiện sứ
mạng mang lại sự tiện lợi, đơn giản và hiệu quả cho người dùng. Một giao diện
hấp dẫn sẽ có lợi thế rất lớn trong nhiều lĩnh vực.
Nhưng có một giao diện đẹp không có nghĩa là đã có hệ thống với tính sử
dụng cao. Do đó ta cần thiết kế hệ thống phần mềm có tính sử dụng được. Hệ
thống đó phải thoả mãn nguyên lý thiết kế GUI và được thực hiện theo đúng quy
trình thiết kế GUI. Khi thiết kế theo quy trình thiết kế GUI ta sẽ xây dựng được
bản mẫu một cách nhanh chóng, khi được góp ý bản mẫu được chỉnh sửa dễ
dàng và quan trọng là nó nhận được đánh giá sớm và phản hồi sớm về những
điểm tốt và điểm xấu của thiết kế.
Để thiết kế được UI một cách nhanh chóng và hiệu quả thì ngoài thiết kế
theo quy trình GUI thì người ta cũng cần sử dụng các kinh nghiệm, tri thức và
kết quả đã có từ trước. Các kinh nghiệm, tri thức và kết quả này được đúc kết lại
thành mẫu thiết kế. Khi sử dụng mẫu thiết kế người thiết kế không phải thiết kế
hệ thống từ đầu, không phải giải quyết lại những bài toán đã được giải quyết.
Điều này làm cho chất lượng thiết kế tốt hơn và tạo điều kiện cho người thiết kế
tập trung vào sáng tạo những cái mới.


14

Chương 2 – MỘT SỐ MẪU ỨNG DỤNG TRONG THIẾT KẾ GUI
Chương 2 trình bày một số mẫu ứng dụng trong thiết kế GUI. Bố cục của
chương gồm 2 mục. Mục 1 tìm hiểu các mẫu kiến trúc. Mục 2 tìm hiểu các mẫu
đồ hoạ.
2.1 Các mẫu kiến trúc
Mẫu kiến trúc biểu thị một mô hình tổ chức cấu trúc cơ bản cho những hệ
thống phần mềm. Nó cung cấp một tập hợp các hệ thống con hoặc những thành

phần, và bao gồm quy tắc chỉ đạo để tổ chức những mối quan hệ giữa chúng.
Những mẫu kiến trúc là phương tiện của kiến trúc cung cấp tài liệu cho hệ thống
phức tạp, nó giúp đỡ việc quản lý sự phức tạp của ứng dụng. Ta tìm hiểu một số
mẫu kiến trúc sau:
2.2.1 Abstract Factory
a. Vấn đề đặt ra
Trong các hệ điều hành giao diện đồ hoạ, một bộ công cụ muốn cung cấp
một giao diện người dùng dựa trên chuẩn look-and-feel, như chương trình trình
diễn tài liệu Microsoft Office PowerPoint. Có rất nhiều kiểu giao diện look-and-
feel và cả những hành vi giao diện người dùng khác nhau như thanh cuộn tài
liệu (scroll bar), cửa sổ (window), nút bấm (button), hộp soạn thảo (editbox)
Nếu coi chúng là các đối tượng thì ta thấy chúng có một số đặc điểm và hành vi
khá giống nhau về mặt hình thức nhưng lại khác nhau về cách thực hiện. Ví dụ,
đối tượng button và window, editbox có cùng các thuộc tính là chiều rộng, chiều
cao, toạ độ… Có các phương thức là Resize(), SetPosition() Nhưng các đối
tượng này không thể gộp chung vào một lớp được vì theo nguyên lý xây dựng
lớp thì các đối tượng thuộc lớp phải có các phương thức hoạt động giống nhau.
Mà các đối tượng này có cùng giao diện nhưng cách thực hiện các hành vi tương
ứng lại hoàn toàn khác nhau.
Do đó ta phải xây dựng một lớp tổng quát, có thể chứa hết những điểm
chung của các đối tượng này để từ đó có thể dễ dàng sử dụng lại.
b. Định nghĩa:
Abstract Factory là mẫu thiết kế mà cung cấp cho trình khách một giao
diện cho một họ hoặc một tập các đối tượng thuộc các lớp khác nhau nhưng có
cùng chung giao diện với nhau mà không phải trực tiếp làm việc với từng lớp
con cụ thể [4].
c. Các tình huống áp dụng
- Khi hệ thống muốn xác định quá trình khởi tạo và sử dụng đối tượng tại
thời điểm chạy chương trình.
15

- Hệ thống muốn tương tác với một họ trong một tập hợp họ đối tượng và
việc chọn họ đối tượng được xác định tại thời điểm chạy.
- Hệ thống muốn ràng buộc tính sử dụng đồng thời của các phần tử trong
một họ đối tượng.
d. Thuận lợi và hạn chế:
- Tạo sự độc lập giữa các thành phần: Client thao tác dựa trên giao diện lập
trình mà không quan tâm sản phẩm gì được trả về, quá trình tạo lập sản
phẩm được che dấu hoàn toàn.
- Dễ dàng chuyển đổi giữa các họ sản phẩm nhờ tính độc lập, khi cần thay
đổi họ sản phẩm, client chỉ việc thay đổi điều kiện tạo lập đối tượng, các
phần mã chương trình cũ vẫn giữ nguyên.
- Khó bổ sung loại sản phẩm mới do khi đó phải bổ sung vào lớp Abstract
Factory và sẽ ảnh hưởng đến hầu hết các lớp khác.
2.2.2 Builder
a. Vấn đề đặt ra
Trong những ứng dụng lớn có nhiều chức năng phức tạp và mô hình giao
diện đồ sộ. Việc khởi tạo ứng dụng thường gặp nhiều khó khăn. Ta không thể
dồn tất cả công việc khởi tạo này cho một hàm khởi tạo. Vì rất khó kiểm soát
hết, và không phải lúc nào các thành phần của ứng dụng cũng được khởi tạo một
cách đồng bộ. Có thành phần được tạo ra vào lúc dịch chương trình nhưng cũng
có thành phần tuỳ theo từng yêu cầu của người dùng, tuỳ vào hoàn cảnh của ứng
dụng, mà nó sẽ được tạo ra. Do vậy người ta giao công việc này cho một đối
tượng chịu trách nhiệm khởi tạo, và chia việc khởi tạo ra riêng rẽ, để có thể tiến
hành khởi tạo riêng biệt ở các hoàn cảnh khác nhau.
Ví dụ, ta coi việc tạo ra đối tượng giống như việc ta tạo ra chiếc xe đạp.
Đầu tiên ta tạo ra khung xe, sau đó tạo ra bánh xe, tạo ra buđông xe, xích, líp
Việc tạo ra các bộ phận này không nhất thiết phải được thực hiện một cách đồng
thời hay theo một trật tự nào cả, và nó có thể được tạo ra một cách độc lập bởi
nhiều người. Nhưng trong một mô hình sản xuất, việc tạo ra chiếc xe luôn được

khép kín để tạo ra chiếc xe hoàn chỉnh, đó là nhà máy sản xuất xe đạp. Ta gọi
đối tượng nhà máy sản xuất xe đạp này là Builder.
b. Định nghĩa
Builder là mẫu thiết kế hướng đối tượng được tạo ra để chia một công
việc khởi tạo phức tạp của một đối tượng ra riêng rẽ từ đó có thể tiến hành khởi
tạo đối tượng ở các hoàn cảnh khác nhau [8].

16

c. Các tình huống áp dụng
- Khi tạo đối tượng phức hợp độc lập với thành phần.
- Tiến trình khởi tạo cho phép nhiều đại diện khác nhau của đối tượng cũng
được khởi tạo.
d. Thuận lợi và hạn chế:
- Về phía người dùng: nó chỉ là những thành phần con, do dó làm giảm số
lượng các đối tượng mà người dùng phải sử lý và làm cho hệ thống dễ sử
dụng hơn.
- Làm giảm sự móc nối giữa các đối tượng.
- Nó cho phép sử dụng các lớp con của hệ thống.
2.2.3 Adapter
a. Vấn đề đặt ra
Đôi khi một lớp công cụ được thiết kế cho việc sử dụng lại, lại không thể
sử dụng lại chỉ bởi giao diện không thích hợp với miền giao diện đặc biệt mà
một ứng dụng yêu cầu. Adapter đưa ra một giải pháp cho vấn đề này.
Ta muốn sử dụng một lớp đã tồn tại nhưng giao diện của nó không phù
hợp với giao diện của một lớp mà ta yêu cầu. Ta muốn tạo ra một lớp có khả
năng được dùng lại, lớp đó cho phép kết hợp với các lớp không liên quan hoặc
không được dự đoán trước, các lớp đó không nhất thiết phải có giao diện tương
thích với nhau. Nhưng thực tế là không thể làm được vì giao diện của các lớp
không tương thích. Mà để làm được điều này ta dùng một đối tượng Adapter để

biến đổi giao diện lớp cha của nó.
b. Định nghĩa
Adapter là mẫu thiết kế dùng để biến đổi giao diện của một lớp thành một
giao diện khác mà clients yêu cầu. Adapter cho phép các lớp làm việc cùng nhau
mà bình thường là không thể do sự không tương thích về giao diện [8].
c. Các tình huống áp dụng
- Khi muốn sử dụng một lớp đã có sẵn nhưng giao diện của lớp đó không
tương thích với yêu cầu của bạn.
- Muốn tạo một lớp có thể sử dụng lại. Lớp này có thể làm việc được với
lớp khác không liên hệ gì vì nó là những lớp không cần thiết có những
tương thích trong giao diện.
d. Thuận lợi và hạn chế.
- Adapter làm tăng khả năng tái sử dụng các thành phần của hệ thống, cho
phép 2 hay nhiều đối tượng có thể tương tác được với nhau dù chúng
không tương thích với nhau về kiểu, loại đối tượng.
17

- Việc lạm dụng Adapter có thể dẫn tới sự không tương tác các chức năng
trong hệ thống. Do đó cần có chiến lược quản lý và đảm bảo chức năng
của mỗi lời gọi hàm bên Adapter.
- Việc truyền tham số qua lại giữa Adapter và hệ thống: các tham số giữa
Adapter và Framework không phải lúc nào cũng tương thích.
2.2.4 Façade
a. Vấn đề đặt ra
Khi cấu trúc hóa một hệ thống thành các hệ thống con sẽ giúp làm giảm
độ phức tạp của hệ thống. Một mục tiêu thiết kế thông thường là tối thiểu hóa sự
giao tiếp và phụ thuộc giữa các hệ thống con. Một cách để đạt được mục tiêu
này là đưa ra đối tượng Façade, đối tượng này cung cấp một giao diện đơn giản
để dễ dàng tổng quát hóa cho một hệ thống con.

Hình 2-1. Mô hình mẫu Façade.
b. Định nghĩa
Mẫu Façade cung cấp một giao diện thống nhất cho một tập các giao diện
trong một hệ thống con. Façade định nghĩa một giao diện ở mức cao hơn, giao
diện này làm cho hệ thống con được sử dụng dễ dàng hơn [4].
c. Các tình huống áp dụng
- Muốn cung cấp một giao diện lập trình cô đọng, đơn giản thay vì nhiều
giao diện phức tạp.
- Giảm sự phụ thuộc của client với giao diện của các lớp trong phân hệ.
- Tạo nên kiến trúc tầng (layer)
2.2.5 Observer
a. Định nghĩa
Observer định nghĩa một phụ thuộc một - nhiều giữa các đối tượng để khi
một đối tượng thay đổi trạng thái thì tất cả các phụ thuộc của nó được nhận biết
và cập nhật tự động [4].

18

b. Các tình huống áp dụng
- Khi ứng dụng mối quan hệ phụ thuộc, đối tượng này phụ thuộc vào đối
tượng kia.
- Khi sự thay đổi ở đối tượng này dẫn đến sự thay đổi đối tượng khác và ta
không biết đích xác có bao nhiêu đối tượng phải thay đổi theo.
c. Thuận lợi và hạn chế
- Observer giúp ta sử dụng những subject và observer một cách độc lập.
Chúng ta có thể sử dụng lại những subject mà không phải sử dụng lại các
Observer của nó và ngược lại. Chúng ta có thể thêm vào một hoặc nhiều
Observer mà không phải sửa lại Subject hoăc các observer khác
2.2.6 Mẫu MVC
a. Định nghĩa

Mẫu thiết kế MVC (Model-View-Controller) được đề xuất và áp dụng
trong thiết kế vào những năm 80 của thế kỷ trước, áp dụng lần đầu trong UI của
SmallTalk-80.
MVC là mẫu thiết kế sử dụng để tách logic nghiệp vụ khỏi giao diện, tách
phần dữ liệu khỏi phần trình diễn, tách đầu vào khỏi đầu ra. MVC bao gồm ba
loại đối tượng: Model, View và Controller.
 Model: Có trách nhiệm với dữ liệu. Quản lý trường dữ liệu (trạng thái ứng
dụng). Cài đặt hành vi thay đổi trạng thái. Thông báo cho
Views/Controllers liên quan biết có sự thay đổi.
 View: Có trách nhiệm với đầu ra. Chiếm vùng màn hình. Lấy dữ liệu từ
Model để vẽ trên màn hình. “Nghe” sự thay đổi ở model để vẽ lại màn
hình. Mỗi View chỉ có một Model. Một Model có thể có nhiều View.
 Controller: Có trách nhiệm với đầu vào. “Nghe” sự kiện phím và chuột.
Ra lệnh cho Model hoặc View thay đổi cho phù hợp. Mỗi Controller chỉ
có một Model và một View.
b. Biểu diễn hoạt động của MVC
- Event yêu cầu Controller thay đổi Model, View
- Khi Controller thay đổi dữ liệu của Model, View tự cập nhật
- Khi Controller tác động trên (chọn) View, View lấy dữ liệu từ Model và
tự hiển thị.