ĐẠI HỌC THÁI NGUYÊN
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
VÀ TRUYỀN THÔNG


NGÔ THỊ MAI PHƯƠNG



PHÂN TÍCH VÀ THIẾT KẾ GUI
ĐỊNH HƯỚNG MẪU


LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH



Thái Nguyên, 2012
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

ĐẠI HỌC THÁI NGUYÊN
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN
VÀ TRUYỀN THÔNG


NGÔ THỊ MAI PHƯƠNG

PHÂN TÍCH VÀ THIẾT KẾ GUI
ĐỊNH HƯỚNG MẪU
Chuyên ngành: Khoa học máy tính
Mã số: 60 48 01

LUẬN VĂN THẠC SĨ KHOA HỌC MÁY TÍNH

NGƯỜI HƯỚNG DẪN KHOA HỌC
PGS. TS. ĐẶNG VĂN ĐỨC


Thái Nguyên, 2012
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

1
Mở đầ u
Hiện nay đồ họa máy tính (Computer Graphics) là một trong những
chương trình thông dụng nhất, nó đã góp phần quan trọng làm cho giao tiếp
giữa con người và máy tính trở nên thân thiện hơn. Thật vậy, giao diện kiểu
văn bản (text) đã được thay thế hoàn toàn bằng giao diện đồ họa, cùng với
công nghệ đa phương tiện (multimedia) đã đưa ngành Công nghệ thông tin
sang một phiên bản mới.
Giao diện người sử dụng (UI – User Interface) 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,
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 UI 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ụ của mình. Nhiều người sử dụng đánh giá
hệ thống thông qua UI, họ cho rằng hệ thống tồi nếu UI 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.
Thông thường mã trình cho chiếm khoảng 50-70% của hệ thống, do vậy
nguồn lực dành cho phát triển UI là khá lớn. Theo thống kê 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 (Graphic
User Interface). Công việc phát triển GUI là khó khăn. GUI tốt làm giảm chi
phí cho công việc bảo trì hệ thống. Thiết kế giao diện tốt cho một hệ thống
không phải là việc làm dễ dàng. Người sử dụng đòi hỏi hệ thống phải làm
được những gì mà họ mong đợi. Người ta đã nghiên cứu nhiều qui trình,
phương pháp làm tăng hiệu quả quá trình phân tích thiết kế GUI, trong đó có
định hướng ứng dụng mẫu thiết kế. Một mẫu mô tả một vấn đề thường xuyên
xuất hiện trong thiết kế và thực thi phần mềm và mô tả giải pháp 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.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

2
Nhận thấy tính thiết thực của vấn đề này và được sự gợi ý của giảng viên
hướng dẫn, tôi đã chọn đề tài: “ Phân tích thiết kế GUI định hướng mẫu” làm
đề tài cho luận văn tốt nghiệp của mình. Mục tiêu luận văn là nghiên cứu về
mẫu thiết kế và khả năng ứng dụng chúng trong thiết kế GUI cho hệ thống
phần mềm.
Luận văn sử dụng công cụ phần mềm để thiết kế giao diện đồ họ a (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 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ổ ng quan về thiế t kế
GUI và mẫ u thiế t kê . Chương 2 thiế t kế GUI trên cơ sở mẫ u . Chương 3 Xây
dự ng giao diệ n thử nghiệ m.
Đối tƣợng và phạm vi nghiên cứu

Luậ n văn nghiên cứu trong phạm vi mộ t số mẫu áp dụng thiết kế giao
diện lập trình đồ họa (GUI)
Hƣớng nghiên cứu của đề tài
Nghiên cứu tổng quan về mẫu trong công nghệ phần mềm. Tập trung
khảo sát các mẫu thiết kế ứng dụng chúng trong việc xây dựng giao diện
người sử dụng.






Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

3
CHƢƠNG I: TỔNG QUAN VỀ THIẾT KẾ GUI VÀ MẪU THIẾT KẾ
1.1 Giới thiệu về UI
1.1.1 Định nghĩa UI( User interface)
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.
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.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

4
 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.
 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.
- 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”
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

5
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.
 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.
 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

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

6
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?
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.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

7
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, qui ướ c, ánh xạ, nhất quán,
gợi ý.
 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.
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í.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

8
 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.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

9
Đố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.
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õ.


1.4. Tổng quan về mẫu trong công nghệ phần mềm.
1.4.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.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

10
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 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.

1.4.3. Phân loại mẫu.
Người ta phân loại mẫu theo pha sử dụng của nó như sau:
- Mẫu Phân tích: Mẫu phân tích là các mô hình quan niệm đã được xây
dựng để mô hình hóa các tri thức cốt lõi của một vấn đề. Vì thế, các mẫu đã
sử dụng để mô hình hóa cho một vấn đề cụ thể có thể được sử dụng lại để mô
hình hóa cho vấn đề tương tự và đạt được thành công ngay cả khi có sự khác biệt
về ngữ cảnh của bài toán.
- Mẫu kiến trúc: Một 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 đặt sẵn hoặc những thành phần, chỉ rõ những trách nhiệm của họ,
và bao gồm quy tắc và nguyên 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 hỗn tạp và phức tạp, như vậy nó sẽ giúp đỡ việc quản lý sự phức
tạp của ứng dụng.
- Mẫu thiết kế: Một mẫu thiết kế cung cấp một mô hình để tinh lọc
những hệ thống con hoặc những thành phần của một hệ thống phần mềm hoặc
mối quan hệ giữa chúng. Nó mô tả một cấu trúc có định kỳ thông thường của
việc truyền thông thành phần giải quyết một vấn đề thiết kế chung bên trong
một ngữ cảnh đặc biệt. Chiến lược, trạng thái, và những mẫu uỷ nhiệm là
những ví dụ từ phạm trù này.
- Những thành ngữ: Một thành ngữ là một mẫu đặc biệt mức thấp tới
một ngôn ngữ lập trình. Một thành ngữ mô tả làm sao để thực hiện những
khía cạnh đặc biệt của thành phần hoặc mối quan hệ giữa chúng sử dụng
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

11
những đặc tính của một ngôn ngữ lập trình đã cho như C ++, Java, hoặc
Smalltalk.
Mẫu được áp dụng trong nhiều giai đoạn khác nhau trong quy trình
phát triển hệ thống. Các mẫu tổ chức (organnizational pattern ) được dùng

trong việc lập kế hoạch cho dự án. Các mẫu phân tích được dùng trong việc
lập cấu trúc của mô hình thuộc phạm vi bài toán. Các mẫu kiến trúc được
dùng để xác định toàn bộ kiến trúc của hệ thống. Các mẫu thiết kế được dùng
để thiết kế các quan hệ tương tác giữa các lớp thiết kế.
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 Mẫu thiết kế.
1.5.3 Các định nghĩa về 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
(nhằm đạt được khả năng tái sử dụ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ế giúp đỡ 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. Điều này là tất
yếu vì mẫu tuân thủ rất nghiêm ngặt các nguyên lý thiết kế hướng đối tượng.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

12
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.
1.5. 4 Các yếu tố xác định một mẫu thiết kế.
- Tên mẫu: Giúp ta hình dung nhanh chóng hiệu quả về mẫu mầ không
cần phải xem lại cấu trúc mẫu. Nắm được các tên mẫu thông dụng sẽ giúp ta
nhìn được các bản thiết kế ở mức trìu tượng hơn thay vì phải đi vào chi tiết.
- Vấn đề (bài toán cần giải quyết – problem): Mô tả tình huống sử dụng
mẫu. Ngoài ra, nó cũng giúp ta nhìn nhận vấn đề một cách thận trọng , biết
khi nào nên khi nào không nên áp dụng mẫu này.
- Cách giải quyết (solution): mô tả các nhân tố ( class – object) tham
gia giải quyết bài toán và mối quan hệ giữa chúng (composition, inhertance,
instantiation)
- Hệ quả (consequences): Cho ta thấy việc áp dụng các vấn đề có hiệu
quả hay không. Nói cách khác nó đăt ra cho chúng ta cách lựa chọn, từ đó ta
có thể xem xét cách lựa chọn nào là phù hợp nhất, tốt nhất.
1.5.7 Phân loại mẫu thiết kế.
Các mẫu thiết kế được phân loại dựa vào nhiều tiêu chí, chung nhất là
dựa vào vấn đề cơ bản mà chúng giải quyết. Theo tiêu chuẩn này, các mẫu
thiết kế có thể được phân loại thành nhiều lớp, một số trong chúng là:
 Các mẫu Cơ Sở (Fundamental pattern)
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

13

 Các mẫu Tạo Lập (Creational pattern): là những mẫu tạo ra đối t-
ượng. Nó làm cho chương trình của ta linh hoạt hõn trong việc quyết ðịnh
rằng những ðối týợng nào cần tạo ra trong một trýờng hợp cụ thể ðã cho.
 Các mẫu Cấu Trúc (Structural pattern): giúp đỡ ta biên soạn những
nhóm đối tượng vào trong những cấu trúc lớn hơn, như giao diện người dùng
phức tạp hoặc dữ liệu kế toán.
 Các mẫu Ứng Xử (Behavioral pattern): giúp ta định nghĩa giao tiếp
giữa các đối tượng trong hệ thống và chỉ ra cách làm thế để quản lý được
luồng điều khiển trong chương trình phức tạp.
 Các mẫu Đồng Thời (Concurrency pattern)
 Các mẫu xử lí Sự Kiện (Event handling pattern)
 Các mẫu Kiến Trúc (Architectural pattern)
1.6 Áp dụng mẫu
1.6.1. Mẫu thiết kế với từng bài toán.
- Khi các đối tượng được tạo ra từ concrete class thay vì các lớp thuần
ảo (interface) làm cho việc thay đổi và cập nhập hệ thống sau này sẽ trở nên
khó khăn. Hướng giải quyết là ta sử dụng các mẫu: Abstract Factory, factory
method, Prototype.
- Chương trình phụ thuộc vào phần cứng và hệ điều hành. Một chương
trình được thiết kế trên windown sẽ chạy không hiệu quả trên Linux vì các
hàm API và plasform hoàn toàn khác biệt nhau. Do đó cần thiết kees sao cho
chương trình linh động không phụ thuộc và bất kỳ hệ điều hành nào, phần
cứng nào. Hướng dgiải quyết: Dùng mẫu Absstrct Factory, Bridge.
- Chương trình phụ thuộc vào các chi tiết của đối tượng như cách thức
hoạt động, lưu trữ tại stack nào, thực thi ra sao, có ràng buộc quan hệ nào
không… client biêt quá nhiều về đối tượng mà nó gọi tới thường luôn có xu
hướng thay đổi nếu đối tượng thay đổi. Vì vậy, ta cần giấu đi những thông tin
không cần thiết đối với client. Vậy ta có thể dùng các mẫu: Abstract Factory,
Bridge, Memento, Proxy.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên


14
- Cách giải quyết bài toán nào đó tại thời điểm này có thể chưa tốt và nó
cần được mở rộng thay thế hoặc tối ưu hóa. Việc phụ thuộc vào cách giải
quyết một vấn đề cụ thể thường làm thay đổi các đối tượng có liên quan, thậm
chí gây ra sự thay đổi dây chuyền. Do đó các thuật toán càng độc lập bao
nhiêu thì càng hạn chế sự ràng buộc bấy nhiêu. Ta có thể sử dụng mẫu:
Buider, iterator, strategy, template method, visitor.
- Chương trình phụ thuộc quá chặt chẽ giữa các đối tượng. Lớp đối
tượng A và B liên kết với nhau quá chặt chẽ nên rất khó có thể thay đổi lớp A
nếu không hiểu rõ về lớp B. Cách giải quyết dùng mẫu: Abstract Factory,
Bridge, chain of Responssibility, command, façade, mediator, observer.
- Chương trình kế thừa những chức năng từ đối tượng cha (super class).
Theo nguyên lý thay thế của Liskov, lớp đối tượng B là con của đối tượng A,
nếu ta thay thế A bằng B thì hệ thống vẫn không thay đổi. Khi đó xảy ra 2 tình
huống:
+ B phủ lên (override)chức năng của A nhưng không đáp ứng ngữ nghĩa
và ngữ cảnh mà A dặt trong đó (sai nguyên lí của Liskov).
+ B phủ lên một hàm trong A, dẫn theo thay đổi khác trong A.
Hướng giải quyết: Sử dụng Bridge, Chain of responssibility, composite,
Decorator, Strategy.
- Trong một vài trường hợp ta cần thay đổi chức năng của một lớp đối
tượng sao cho phù hợp với hoàn cảnh thực tế của hệ thống hoặc tích hợp các
lớp đối tượng khác vào trong hệ thống của ta, nhưng chúng ta không có mã
nguồn của mhững đối tượng đó. Những điều này bắt ta phải thiết kế lại hệ
thống. Hướng giải quyết: Sử dụng adapter, decorator, visitor.
Mẫu thiết kế đưa ra ý tưởng để để khắc phục các vấn đề trên, cho phép
ta xây dựng các kiến trúc độc lập nhau, sao cho bất kỳ thay đổi của phần nào
trong hệ thống cũng không làm ảnh hưởng hoặc ảnh hưởng rất ít đến các phần
còn lại của hệ thống, từ đó làm cho phần mềm trở nên kiên định và linh động

hơn.

Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

15
1.6.2. Cách lựa chọn và sử dụng mẫu thiết kế.
Mẫu không phải luôn là câu trả lời cho mọi vấn đề trong thiết kế hệ
thống. Tuy nhiên, chúng có thể cung cấp các lợi ích có ý nghĩa bằng cách rút
gọn quy trình tìm ra các giải pháp cho các vấn đề thiết kế trong các hệ thống
phức tạp. Khi gặp vấn đề trong thiết kế hệ thống, hãy xem xét các điểm sau
đây:
- Mẫu thiết kế đang xét có áp dụng cho vấn đề này hay vấn đề tương tự không?
- Tài liệu của mẫu này có gợi ý bất kỳ một giải pháp nào khác có được
chấp nhận hơn không?
- Có giải pháp nào hơn không (không dùng mẫu cho mục đích này)?
- Ngữ cảnh của mẫu và vấn đề có nhất quán với nhau không?
- Các kết quả của việc dùng mẫu có thể chấp nhận được không?
- Các ràng buộc của phần mềm đang dùng có tranh chấp khi dùng mẫu không?
Gama và các đồng sự của ông đã gợi ý các bước để ứng dụng một mẫu
thành công như sau:
- Đọc mẫu để có cái nhìn toàn cảnh, học chi tiết cấu trúc, các đối tượng
tham gia và các cộng tác của mẫu.
- Kiểm tra về mã nguồn mẫu để xem ví dụ về cách dùng mẫu.
- Chọn tên cho các đối tượng tham gia của mẫu (ví dụ như lớp) sao cho
có ý nghĩa đối với các ứng dụng.
- Định nghĩa các lớp, giao diện, cấu trúc kiểu dữ liệu và quan hệ giữa chúng.
- Chọn tên cho các thao tác.
- Cài đặt các thao tác thực hiện các trách nhiêm và cộng tác trong mẫu.
Các mẫu rất có ích nhưng phải áp dụng nó một cách cẩn thận. Ưu điểm của
mẫu là cho phép tái sử dụng các kinh nghiệm của nhà phát triển đi trước và

học tập dạng thực hành từ các ví dụ. Tuy nhiên việc dùng mẫu có thể làm cho
hệ thống phức tạp hơn mức cần thiết. Để chọn được một cách chính xác và
thực sự hiệu quả các mẫu thiết kế cho một ứng dụng thì đó còn là kinh
nghiệm, là thời gian mà người thiết kế bỏ ra để làm việc trên các mẫu thiết kế.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

16
Ta không thể dễ dàng tìm được mẫu thích hợp từ một tập các mẫu phức tạp.
Thiết kế những ứng dụng có hệ thống triển khai thiết kế mẫu không phải là một
quá trình bình thường.
Kết luận chƣơng I
Ta thấy rằng, trong thực tế 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 đó người sử dụng sẽ sử dụng tốt các chức
năng của hệ thống. Khi thiết kế bằng GUI ta sẽ thiết kế giao diện một cách
nhanh chóng, bản mẫu được góp ý để chỉnh sửa sẽ dễ dàng và quan trọng là
nó nhận được đánh giá sớm và phản hồi sớm.
Khi thiết kế UI ngoài thiết kế theo quy trình thiết kế GUI thì người ta
cũng sử dụng các kinh nghiệm, tri thức và kết quả đã có từ trước để thiết kế
được nhanh hơn, cách giải quyết vấn đề hợp lý hơn. Các tri thức này được đúc
kết lại thành mẫu thiết kế. 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.





Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

17
CHƢƠNG II. THIẾ T KẾ GUI TRÊN CƠ SỞ MẪ U
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.1.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ể.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

18
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.
- 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.1.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,
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

19
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.
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.1.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
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

20
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.
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.
- 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.1.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.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

21

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.
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.1.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.
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
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

22
nhiều Observer mà không phải sửa lại Subject hoăc các observer khác
2.1.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ị.

Hình 2-2. Mô hình hoạt động của mẫu MVC
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên

23
2.2 Các mẫu đồ họa
2.2.1 Các mẫu về định vị
Mục đích của các mẫu định vị là làm sao người sử dụng biết được họ
đang ở đâu, họ phải đi tới đâu và làm sao họ tới được đích cần tới. Khi bạn
tạo một website hay một chương trình lớn và bạn cần chia thành các mục lớn,
nhỏ, các trang, các cửa sổ, các hướng dẫn. Bằng cách nào đó bạn có thể giúp
người sử dụng tìm đường.
Để làm được điều này người ta sử dụng các mẫu định vị sau:
2.2.1.1 Clear Entry Points

Hình 2-3. Giao diện sử dụng mẫu Clear Entry Point
a. Định nghĩa
Clear Entry Points chỉ trình bầy một số điểm vào trên các giao diện,
điều này làm chúng ta tập trung vào các điểm chính.
b. Các tình huống áp dụng

Khi bạn đang thiết kế một chương trình kết nối với công việc hoặc một
chương trình bất kì được sử dụng bởi những người mới sử dụng. Mục đích
của chương trình khá rõ ràng đối với người lập ra nó, nếu có nhiều định vị
khiến bạn khó chịu thì tốt nhất nên dùng mẫu Clear Entry Points.
c. Tại sao
Một số chương trình và website khi bạn mở ra thì giống như một rừng
thông tin và cấu trúc: có nhiều biểu bảng, các quảng cáo, các toolbar không
hoạt động… Tất cả những cái đó không giúp cho người sử dụng bất kì hướng
dẫn rõ ràng nào.
Vì người sử dụng bạn nên lập ra một số lựa chọn để bắt đầu. Do đó
người sử dụng sẽ lựa chọn một khả năng thích hợp và bắt đầu làm việc với nó.
Số hóa bởi Trung tâm Học liệu – Đại học Thái Nguyên