Học phần

Software Engineering
http://hubt.edu.vn
 Nội dung

Chương 1: Giới thiệu chung về kỹ nghệ

phần mềm.
Chương 2: Phân tích và đặc tả yêu cầu
phần mềm.
Chương 3: Thiết kế phần mềm.
Chương 4: Lập trình phần mềm.
Chương 5: Kiểm thử phần mềm.
Chương 6: Bảo trì phần mềm.

http://hubt.edu.vn
 Chương 3: Thiết kế phần mềm.
 3.1 Các khái niệm thiết kế phần mềm.
 3.2 Các hoạt động thiết kế.
 3.3 Thiết kế hướng đối tượng.
 3.4 Thiết kế giao diện.
 3.5 Tài liệu thiết kế phần mềm.

http://hubt.edu.vn
 3.1 Các khái niệm thiết kế phần mềm

Khái niệm
 Thiết kế là chuyển đặc tả yêu cầu thành mô tả
thiết kế mà người lập trình có thể chuyển
thành chương trình với một ngôn ngữ, vận
hành được đáp ứng được yêu cầu đặt ra.
 Là một quá trình sáng tạo:
• Tìm giải pháp công nghệ (cách thức, phương án)
• Biểu diễn cách thức, phương án
• Xem xét lại, chi tiết hóa
Tóm lại: đủ chi tiết để người lập trình biết phải làm
như thế nào để chuyển thành chương trình.

http://hubt.edu.vn
 Vai trò của thiết kế
 Tạo ra mô hình cài đặt của phần mềm.
 Là công cụ giao tiếp giữa những người tham
gia phát triển, các cơ sở đảm bảo chất lượng
hệ thống
• Dễ đọc, dễ hiểu, dễ sửa đổi hơn mã chương trình.
• Có nhiều mức chi tiết, cung cấp cái nhìn tổng thể.
• Làm cơ sở để trao đổi, cải tiến.
 Cung cấp đầy đủ thông tin cho việc bảo trì
sau này:
• Giảm công sức mã hóa khi sửa đổi.
• Tiện bảo trì, phát triển, mở rộng.
http://hubt.edu.vn
 Cấu trúc thiết kế
 Phần mềm là tập các mô đun tương tác lẫn
nhau.
 Mô đun hóa là chìa khóa cho phần mềm tốt.
 Mục tiêu thiết kế là xác đinh:
• Các mô đun chức năng.
• Cách thức cài đặt mô đun.
• Tương tác giữa các mô đun.

http://hubt.edu.vn
  Nguyên lý thiết kế
 1. Không bị bó buộc vào một cách nhìn hạn chế nào
• Nó cần được lựa chọn từ các giải pháp có thể.
 2. Cho phép lần ngược lại mô hình phân tích
• Các mô đun & yêu cầu không nhất thiết phải tương ứng 1-1.
• Nhưng phải kiểm tra được sự thỏa mãn các yêu cầu.
 3. Không nên tạo lại các thiết kế (giải pháp) đã có, mà
cần tái sử dụng tối đa chúng.
 4. Mô hình thiết kế (giải pháp) nên tiến gần đến mô
hình thế giới thực (bài toán).
 5. Biểu diễn thiết kế nhất quán và có tính tích hợp:
• Thiết kế do nhiều người tiến hành song song.
• Phải thống nhất cách biểu diễn, thống nhất giao diện.

http://hubt.edu.vn
  6. Thiết kế cần có cấu trúc dể dễ hiểu, dễ thay đổi.
• Phải được mô đun hóa, phân cấp.
 7. Thiết kế không phải là mã hóa
• Thiết kế luôn có mức trừu tượng hơn mã hóa, đảm bảo dễ
hiểu, dễ thay đổi.
 8. Thiết kế cần được đánh giá chất lượng ngay trong
khi được tạo ra
• Tính kết dính, tính ghép nối, hiệu quả thuật toán
 9. Thiết kế cần được thẩm định để tránh các lỗi mang
tính hệ thống.
• Thiếu chức năng, chức năng không rõ, mâu thuẫn,…

http://hubt.edu.vn
 Nội dung thiết kế
 1.Thiết kế kiến trúc
• Phân rã hệ thống thành hệ thống các mô đun con,
• Xác định giao diện tương tác giữa các mô đun.
 2.Thiết kế cấu trúc dữ liệu
• Xây dựng mô hình biểu diễn thông tin.
 3.Thiết kế thủ tục (thuật toán)
• Xác định các bước thực hiện xử lý.
 4.Thiết kế giao diện người dùng
• Nên nhìn nhận giao diện là một bài toán độc lập

http://hubt.edu.vn
  Các bước tổng quát tiến trình thiết kế
 Tiến trình thiết kế là quá trình tăng cường hình thức hóa và luôn
quay lại các thiết kế đúng đắn và ít hình thức hóa hơn trước đó
để kiểm tra và hoàn thiện.
 Bước 1- Thiết kế sơ bộ: Quan tâm tới việc chuyển hoá các yêu
cầu thành kiến trúc dữ liệu và các thành phần phần mềm.
 Bước 2- Thiết kế chi tiết: Tập trung vào việc làm mịn biểu diễn
kiến trúc để dẫn tới cấu trúc dữ liệu chi tiết và biểu diễn các quy
trình tính toán và xử lý của phần mềm.

http://hubt.edu.vn
http://hubt.edu.vn
 1.Thiết kế kiến trúc (lựa chọn mẫu thiết kế
kiến trúc)
 Sử dụng biểu đồ cấu trúc (structure chart),
mô tả:
• Cái nhìn tổng thể về hệ thống
• Mối quan hệ giữa các mô đun
• Giao diện giữa các mô đun
 Không cần chỉ ra
• Thứ tự thực hiện
• Số lần thực hiện
• Chi tiết thiết kế

http://hubt.edu.vn
 2.Thiết kế cấu trúc dữ liệu
 Chọn cách biểu diễn các đối tượng thiết kế có
ảnh hưởng mạnh mẽ đến chất lượng phần
mềm.
 Các mức thiết kế
• Thiết kế cấu trúc lô gic
– Các quan hệ chuẩn, các khóa, các tham chiếu, các cấu
trúc thao tác dữ liệu.
• Thiết kế cấu trúc vật lý
– Các file, các kiểu, kích cỡ.

http://hubt.edu.vn
 3.Thiết kế thủ tục
 Mô tả các bước hoạt động của mô đun
 Phương pháp mô tả:
• Giả mã (pseudo code)
• Sơ đồ luồng (flow chart)
• Biểu đồ (diagram) Nassi-Shneiderman
• Biểu đồ hoạt động (activity diagram)
• JSP

http://hubt.edu.vn
 Nguyên tắc thiết kế phần mềm cơ bản.

 Nguyên tắc là “một giả định, giáo lý hoặc luật căn bản và
toàn diện”. Nguyên tắc thiết kế phần mềm là quan niệm
chính cung cấp kiến thức cơ bản cho khái niệm và
hướng tiếp cận thiết kế phần mềm khác nhau.
 Nguyên tắc thiết kế phần mềm bao gồm:
 Trừu tượng hóa (abstraction);
 Ghép nối và liên kết (coupling and conhesion);
 Phân rã và modul hóa (decomposition and modularization);
 Đóng gói/ẩn thông tin (encapsulation/information hiding);
 Tách giao diện và thực hiện (separation of interface and
implementation);
 Đầy đủ, toàn vẹn và nguyên thủy (sufficiency, completeness,
and primitiveness);
 và tách mối quan tâm (separation of cencerns)

http://hubt.edu.vn
 Trừu tượng hóa
 Khái niệm cơ sở trong tư duy của con người
 Là quá trình ánh xạ một sự vật/hiện tượng
của thế giới thực thành một khái niệm lô gic.
 Có nhiều mức trừu tượng khác nhau
• Cho phép con người tập trung (tư duy) vào giải
quyết vấn đề mà không cần bận tâm đến chi tiết.
• Biểu diễn vấn đề bằng một cấu trúc tự nhiên.

http://hubt.edu.vn
  Trừu tượng dữ liệu
• Dữ liệu
• Thao tác tác động lên dữ liệu
 Trừu tượng thủ tục

 Trừu tượng điều khiển:

• Sử dụng chương trình con
• Luồng điều khiển
http://hubt.edu.vn
 Coupling and Conhesion: Ghép nối là một
độ đo của độ phụ thuộc lẫn nhau giữa các
module trong chương trình máy tính, trong
khi đó liên kết là độ đo độ mạnh của mối
liên kết giữa các phần tử trong một
module.

http://hubt.edu.vn
  Phân rã hóa và module hóa: Phân rã hóa và
modul hóa nghĩa là phần mềm lớn được chia
thành một số thành phần định danh (dễ định
nghĩa interface) mà mô tả tương tác giữa các
thành phần. Thông thường mục tiêu là thay thế
những chức năng và trách nhiệm trong những
thành phần khác nhau.
 Dựa trên quan điểm “chia để trị”
 C(p1 + p2) > C(p1) + C(p2), C: độ phức tạp
 E(p1 + p2) > E(p1) + E(p2), E: công sức thực hiện

http://hubt.edu.vn
  Lợi ích thiết kế mô đun
• Giảm độ phức tạp.
• Cục bộ, dễ sửa đổi.
• Có khả năng phát triển song song.
• Dễ sửa đổi, dễ hiểu nên dễ tái sử dụng.
 Số lượng mô đun: xác định số mô đun tối ưu

http://hubt.edu.vn
  Kích cỡ mô đun: được quyết định dựa trên
khái niệm độc lập chức năng. Mỗi mô đun
nên thực hiện một công việc: dễ hiểu, dễ sửa
đổi, dễ tái sử dụng.

http://hubt.edu.vn
  Đóng gói và ẩn thông tin: nghĩa là nhóm và đóng
gói chi tiết bên trong của một trừu tượng và làm
cho những chi tiết không thể được truy cập từ
bên ngoài.
 Giảm hiệu ứng phụ khi sửa đổi mô đun.
 Giảm tác động của thiết kế tổng thể lên thiết kế cục
bộ.
 Nhấn mạnh trao đổi thông tin thông qua giao diện.
 Loại bỏ việc sử dụng dữ liệu dùng chung.
 Hướng tới sự đóng gói chức năng, một thuộc tính của
thiết kế tốt.

http://hubt.edu.vn
  Tách giao diện và thực hiện: liên quan đến việc
xác định một thành phần bằng cách xác định
một giao diện public (được biết đến như là
client) mà là tách từ chi tiết của thành phần
được hiện thực hóa như thế nào.
 Tính đầy đủ, toàn vẹn và nguyên thủy: mục tiêu
của tính đầy đủ, toàn vẹn và nguyên thủy nghĩa
là chắc rằng một thành phần chỉ tương ứng với
những đặc điểm quan trọng của một trừu tượng.
Nguyên thủy nghĩa là thiết kế nên được dựa trên
mô hình dễ thực hiện

http://hubt.edu.vn
  Tách mối quan tâm. Một mối quan tâm là một
“khu vực quan tâm với sự liên quan đến thiết kế
phần mềm”. Một mối quan tâm thiết kế là một
lĩnh vực của thiết kế mà liên quan đến một hay
nhiều các bên liên quan (stakeholders). Mỗi kiến
trúc nhìn một hay nhiều khung nhìn quan tâm.
Tách mối quan tâm bởi những khung nhìn cho
phép quan tâm các bên liên quan (stakeholders)
tập trung vào một việc tại một thời điểm và yêu
cầu và cung cấp một phương tiện quản lý phức
tạp.

http://hubt.edu.vn
 Chất lượng thiết kế

 Ba đặc trưng được xem như là hướng dẫn cho

một thiết kế tốt (Robert McLaughlin):
 Thiết kế phải triển khai được tất cả yêu cầu trong mô
hình & yêu cầu tiềm ẩn mà khách hàng đòi hỏi.
 Thiết kế cần là bản hướng dẫn dễ đọc, dễ hiểu cho
người viết chương trình, người kiểm thử và người
bảo trì.
 Thiết kế cần cung cấp một bức tranh đầy đủ về phần
mềm trên quan điểm triển khai hướng đến các mặt
dữ liệu, chức năng và hành vi của hệ thống.
(MCG91: Robert McLaughlin, Some notes on program design,
Software Engineering Notes vol 16 no 4, Oct 1991 Page 53, 54.)

http://hubt.edu.vn
  Tiêu chí chất lượng: cần thiết lập các tiêu chí kỹ
thuật để đánh giá một thiết kế tốt hay không
 Thiết kế cần có kiến trúc tốt: cấu thành từ các mẫu
(pattern), các thành phần có đặc trưng tốt, dễ tiến
hóa.
 Thiết kế được mô đun hóa cho mỗi thành phần chức
năng.
 Chứa các biểu diễn tách biệt nhau về: dữ liệu, kiến
trúc, giao diện, thành phần, môi trường.
 Liên kết qua giao diện làm giảm độ phức tạp liên kết
giữa các mô đun với nhau và giữa hệ thống và môi
trường.

http://hubt.edu.vn
 Độ đo chất lượng thiết kế

Phụ thuộc bài toán, không có phương

pháp chung.
Một số độ đo:
 Coupling: mức độ ghép nối giữa các mô đun.
 Cohension: mức độ liên kết giữa các thành
phần trong một mô đun.
 Understandability: tính hiểu được.
 Adaptability: tính thích nghi.

http://hubt.edu.vn
  Coupling (ghép nối)
• Độ đo sự liên kết (trao đổi dữ liệu) giữa các mô
đun.
• Ghép nối chặt chẽ thì khó hiểu, khó sửa đổi do
phải tính đến các liên kết có thể, dễ gây lỗi lan
truyền.
 Cohension (kết dính)
• Độ đo sự phụ thuộc lẫn nhau của các thành phần
trong một mô đun.
• Kết dính cao thì tính cục bộ cao (độc lập chức
năng); dễ hiểu, dễ sửa đổi.
 Tiêu chuẩn của thiết kế tốt: kết dính chặt,
ghép nối lỏng.
http://hubt.edu.vn
  Ghép nối –
coupling: Mức độ
quan hệ của các
mô đun
• Mô đun nên ghép
nối lỏng lẻo.
• Mức lỏng lẻo thể
hiện qua loại hình
ghép nối.

http://hubt.edu.vn
 • Ghép nối nội dung
– Các mô đun dùng dữ lieu hay thông tin điều khiển được
duy trì trong một mô đun khác
– Là trường hợp xấu nhất. VD:
» Các ngôn ngữ bậc thấp chỉ dùng biến chung
» Lạm dụng lệnh Goto trong một chi trình

http://hubt.edu.vn
 • Ghép nối chung
– Các mô đun trao đổi dữ liệu thông qua biến tổng thể
– Lỗi của mô đun này có thể ảnh hưởng đến hoạt động
của mô đun khác.
– Khó sử dụng lại các mô đun

http://hubt.edu.vn
 • Ghép nối điều khiển
– Các mô đun trao đổi thông tin điều khiển
– Làm cho thiết kế khó hiểu, khó sửa đổi, dễ nhầm

http://hubt.edu.vn
 • Ghép nối nhãn
– Các mô đun trao
đổi thừa thông tin.
– Mô đun có thể thực
hiện chức năng
ngoài ý muốn.
– Làm giảm tính thích
nghi.
• Ghép nối dữ liệu
– Truyền dữ liệu qua
tham số.
– Nhận kết quả tham
số và giá trị trả lại.

http://hubt.edu.vn
  Kết dính –
Cohesion
• Mỗi mô đun chỉ nên
thực hiện một chức
năng.
• Mọi thành phần của
mô đun phải tham
gia thực hiện chức
năng đó.

http://hubt.edu.vn
 • Các loại kết dính
– Kết dính gom góp (coincidental cohension)
» Gom các thành phần không liên quan đến nhau.
– Kết dích lô gic (logical cohension)
» Gồm các thành phần làm chức năng lô gic tương tự
(vd: hàm xử lý lỗi chung).
– Kết dính thời điểm (temporal cohension)
» Các thành phần hoạt động cùng thời điểm (vd: hàm
khởi tạo, đọc dữ liệu, cấp phát bộ nhớ,…).
– Kết dính thủ tục (procedural cohesion)
» Các thành phần thực hiện theo một thứ tự xác định
(vd: tính lương cơ bản, tính phụ cấp, tính bảo hiểm)

http://hubt.edu.vn
 – Kết dính truyền thông (communicational cohesion)
» Các thành phần truy cập đến cùng tập dữ liệu: tính
toán thống kê (tính max, min, mean, variation,…)
– Kết dính tuần tự (sequential cohesion)
» Output của một thành phần là input của thành phần
tiếp theo: ảnh mầu  đen trắng  ảnh nén.
– Kết dính chức năng (functional cohesion)
» Các thành phần cùng góp phần thực hiện một chức
năng (vd: các thao tác sắp xếp).

http://hubt.edu.vn
  Tính hiểu được – Understandability
• Là kết quả tổng hợp từ nhiều thuộc tính
– Cấu trúc rõ rang, tốt.
– Ghép nối lỏng lẻo.
– Kết dính cao.
– Được lập tài liệu.
– Thuật toán, cấu trúc dễ hiểu.
 Tính thích nghi được – Adaptability
• Hiểu được
– Sửa đổi được, tái sử dụng được.
• Tự chứa
– Không sử dụng thư viện ngoài.
– Mâu thuẫn với xu hướng tái sử dụng.

http://hubt.edu.vn
 Thiết kế hướng đối tượng hướng tới chất
lượng thiết kế tốt.
 Đóng gói, che dấu thông tin (độc lập dữ liệu).
 Các thực thể hoạt động độc lập (cục bộ, dùng
lại).
 Trao dổi dữ liệu qua truyền thông (liên kết
yếu).
 Có khả năng kế thừa (dùng lại).
 Cục bộ, dễ hiểu, dễ tái sử dụng.

http://hubt.edu.vn
 3.2 Thiết kế kiến trúc phần mềm

3.2.1 Giới thiệu Software architecture

design.
 Khái niệm kiến trúc
• Kiến trúc phần mềm chỉ cấu trúc tổng thể của một
phần mềm và cách thức tổ chức qua đó cho ta một
sự tích hợp về mặt khái niệm của một hệ thống
[SHA95a]
• Thông thường: thể hiện bằng một biểu đồ phân
cấp của các thành phần và quan hệ giữa chúng.
• Đầy đủ: thể hiện cấu trúc hệ thống theo nhiều góc
nhìn khác nhau (tĩnh, động, dữ liệu, triển khai).
[SHA95a] Shaw,M and D.Garlan, Formulation and formalisms
in software achitecture, Lecture Notes in Computer Science,
Springer-Verlag,Volume 1000, 1995.
http://hubt.edu.vn
  Vai trò kiến trúc phần mềm
• Không phải là mô hình hoạt động.
• Là mô hình phân hoạch theo những cách nhìn
khác nhau (chức năng, dữ liệu, tiến trình, tĩnh hay
động,…)
• Giúp kỹ sư hệ thống:
– Phân tích hiệu quả của thiết kế đáp ứng được yêu cầu
của phần mềm.
– Tìm các giải pháp thay thế cấu trúc ở giai đoạn sớm.
– Giảm các rủi ro liên quan tới cấu trúc.

http://hubt.edu.vn
  Khái niệm thiết kế kiến trúc
• Quá trình xác định các hệ con lập thành hệ thống
và khung làm việc để điều khiển & giao tiếp giữa
các hệ con với nhau.
• Bắt đầu sớm ngay từ giai đoạn đầu của thiết kế hệ
thống, tiến hành cùng với một số hoạt động đặc tả.
• Nó bao gồm việc xác định các thành phần chính
của hệ thống, sự truyền thông giữa chúng.

http://hubt.edu.vn
  Các bước thiết kế kiến trúc
• 1. Cấu trúc hóa hệ thống: phân chia hệ thống
thành các hệ con (sub-system) độc lập và xác định
trao đổi thông tin giữa các hệ con, xác định các
giao diện của chúng.
• 2. Mô hình hóa điều khiển: xác lập mô hình điều
khiển giữa các phần khác nhau của hệ thống đã
được xác định.
• 3. Phân rã thành các module: phân rã các hệ con
thành các mô đun
– Hệ con: phần hệ thống hoạt động độc lập với các dịch vụ
mà các hệ con khác cung cấp.
– Mô đun: phần hệ thống cung cấp dịch vụ và tương tác
cùng phần khác để tạo ra dịch vụ hay sản phẩm.

http://hubt.edu.vn
 3.2.2 Các mô hình kiến trúc
 Trong quá trình thiết kế tạo ra nhiều mô hình
kiến trúc khác nhau.
 Mỗi mô hình biểu diễn một cách nhìn của kiến
trúc
• Mô hình kiến trúc tĩnh: chỉ ra các thành phần chính
của hệ thống (biểu đồ phân rã).
• Mô hình động: chỉ ra cấu trúc tiến trình của hệ
thống (biểu đồ luồng dữ liệu).
• Mô hình giao diện: xác định hệ thống giao diện của
hệ thống (hệ thống giao diện tương tác).
• Mô hình mối quan hệ: như mô hình khái niệm thực
thể miền dữ liệu của hệ thống.
http://hubt.edu.vn
  Một số mô hình kiến trúc (theo Software
Architecture Patterns, Mark Richards,
O’Reilly, 2017)
• 1. Kiến trúc phân tầng (Layered Architecture).
• 2. Kiến trúc hướng sự kiện (Event-Driven
Architecture).
• 3. Kiến trúc Microkernel, còn gọi là kiến trúc Plugin
(Microkernel Architecture).
• 4. Kiến trúc Microservices (Microservices
Architecture).
• 5. Kiến trúc dựa trên không gian (Space-Based
Architecture).

http://hubt.edu.vn
  1. Layered Architecture: Đây là kiến trúc phổ biến nhất cho các
ứng dụng nguyên khối. Ý tưởng cơ bản đằng sau mô hình là
chia logic ứng dụng thành nhiều lớp, mỗi lớp đóng gói vai trò cụ
thể. Ví dụ: lớp Persistence sẽ chịu trách nhiệm giao tiếp ứng
dụng với công cụ cơ sở dữ liệu.

http://hubt.edu.vn
  Closed layers and request access
• Môt lớp “closed” nghĩa là một yêu cầu di chuyển từ lớp này
sang lớp khác, nó phải đi qua lớp ngay bên dưới nó để đến
lớp tiếp theo bên dưới lớp đó.

http://hubt.edu.vn
  Open layers and request flow
• Lớp Services được đánh dấu là “open”, nghĩa là các yêu cầu được phép bỏ
qua lớp mở này và đi trực tiếp đến lớp bên dưới nó.

http://hubt.edu.vn
  Layered architecture example
Request Response

http://hubt.edu.vn
  Đánh giá kiến trúc phân tầng:
 Tính linh động chung (overall agility): là khả năng
phản ứng nhanh chóng với một môi trường thay đổi
liên tục. Thay đổi có thể bị cô lập thông qua các lớp,
tuy nhiên mô hình vẫn rườm rà và tốn thời gian để
thực hiện các thay đổi trong mô hình.  THẤP.
 Dễ dàng triển khai: tùy thuộc cách triển khai mô hình,
việc triển khai có thể trở thành một vấn đề đối với các
ứng dụng lớn. Một thay đổi nhỏ với một thành phần
có thể yêu cầu triển khai lại toàn bộ ứng dụng, cần
lập kế hoạch triển khai.  THẤP.
 Khả năng kiểm tra (testability): các thành phần thuộc
về các lớp cụ thể nên dễ kiểm tra, có thể cô lập để
thử nghiệm.  CAO.
http://hubt.edu.vn
  Hiệu quả (performance): ứng dụng không cho hiệu
suất cao do sự kém hiệu quả của việc phải trải qua
nhiều lớp của kiến trúc để đáp ứng các yêu cầu.
 THẤP.
 Khả năng mở rộng (scability): vì xu hướng kết hợp
chặt chẽ và triển khai nguyên khối, các ứng dụng xây
dựng bằng mô hình này nói chung là khó mở rộng.
Chúng ta có thể chia thành các lớp riêng biệt triển
khai vật lý hoặc sao chép toàn bộ ứng dụng thành
nhiều nút, nhưng mức độ chi tiết quá rộng, chi phí đắt
để mở rộng.  THẤP.
 Dễ phát triển: là mô hình nổi tiếng, không quá phức
tạp được dùng bởi nhiều công ty phát triển ứng dụng
bằng cách tách các bộ kỹ năng theo lớp (trình diễn,
nghiệp vụ, CSDL,…).  CAO.
http://hubt.edu.vn
  2. Kiến trúc hướng sự kiện (Even-driven
architecture): Ý tưởng đằng sau mẫu này là tách logic
ứng dụng thành các thành phần xử lý sự kiện có mục
đích duy nhất nhận và xử lý các sự kiện một cách
không đồng bộ. Mẫu này là một trong những mẫu
kiến trúc không đồng bộ phân tán phổ biến được biết
đến với khả năng mở rộng và khả năng thích ứng
cao.
• Bao gồm 2 cấu trúc liên kết (topology) chính: dàn xếp (mediator) và
môi giới (broker).
• Mediator topology: dùng khi cần sắp xếp nhiều bước trong một sự
kiện thông qua central mediator.
• Broker topology: dùng khi muốn liên kết các sự kiện với nhau mà
không cần sử dụng central mediator.

http://hubt.edu.vn
 • Event-driven architecture mediator topology

http://hubt.edu.vn
 • Mediator topology example

http://hubt.edu.vn
 • Event-driven architecture broker topology

http://hubt.edu.vn
 • Broker topology
example

http://hubt.edu.vn
  Đánh giá kiến trúc hướng sự kiện:
 Tính linh động: các thay đổi được một hoặc một vài
bộ xử lý sự kiện thực hiện nhanh chóng mà không
ảnh hưởng đến các thành phần khác.  CAO.
 Dễ triển khai: mô hình tương đối dễ triển khai do bản
chất tách rời của các thành phần bộ xử lý sự kiện.
Các cấu trúc liên kết môi giới (broker topology) có xu
hướng dễ triển khai hơn cấu trúc liên kết dàn xếp
(mediate topology).  CAO.
 Khả năng kiểm tra: mặc dù thử nghiệm đơn vị riêng
không quá khó nhưng yêu cầu một số loại client hoặc
thử nghiệm chuyên biệt, công cụ để tạo sự kiện. Việc
kiểm tra phức tạp do tính chất không đồng bộ.
 THẤP
http://hubt.edu.vn
  Hiệu quả: mặc dù chắc chắn có thể triển khai, một
cấu trúc hướng sự kiện không hoạt động tốt cho
nhiều ứng dụng do cơ sở hạ tầng liên quan, đạt hiệu
suất cao nhờ khả năng không đồng bộ (phân tách,
hoạt động song song).  CAO.
 Khả năng mở rộng: với mỗi sự kiện bộ xử lý có thể
được chia tỷ lệ riêng biệt, cho phép mở rộng  CAO.
 Dễ dàng phát triển: việc phát triển hơi phức tạp do
bản chất không đồng bộ cũng như nhu cầu về các
điều kiện xử lý lỗi trong bộ xử lý sự kiện không phản
hồi và môi giới thất bại.  THẤP.

http://hubt.edu.vn
  3. Kiến trúc Mikrokernel, còn được gọi là kiến trúc Plugin, là
mô hình thiết kế với hai thành phần chính: một hệ thống lõi và
các mô-đun plug-in (hoặc phần mở rộng). Một ví dụ tuyệt vời sẽ
là trình duyệt Web (hệ thống lõi) nơi bạn có thể cài đặt các tiện
ích mở rộng (hoặc plugin) vô tận.

http://hubt.edu.vn
 • Microkernel architecture example
– Ngăn xếp các thư mục đại diện cho hệ thống lõi để xử lý
xác nhận quyền sở hữu. Nó chứa các lô gic nghiệp vụ
cơ bản cần thiết bởi công ty bảo hiểm để xử lý yêu cầu
bồi thường, không có bất kỳ xử lý tùy chỉnh. Mỗi mô đun
plugin chứa các quy tắc cụ thể cho trạng thái đó. Ở trạng
thái cụ thể các quy tắc và quy trình xử lý tách biệt với hệ
thống xác nhận quyền sở hữu cốt lõi có thể thêm, bớt.

http://hubt.edu.vn
  Đánh giá kiến trúc Microkernel:
 Tính linh động: các thay đổi phần lớn có thể được
tách biệt và thực hiện nhanh chóng thông qua plugin.
Hệ thống cốt lõi của kiến trúc microkernel có xu
hướng ổn định nhanh chóng, nghĩa là mạnh mẽ và
yêu cầu ít thay đổi theo thời gian.  CAO.
 Dễ triển khai: các mô đun plugin có thể được thêm
động vào hệ thống lõi trong thời gian chạy, giảm thời
gian chết trong triển khai.  CAO.
 Khả năng kiểm tra: các mô đun plugin có thể được
kiểm tra riêng biệt.  CAO.

http://hubt.edu.vn
  Hiệu quả: hầu hết các ứng dụng có hiệu suất tốt vì có
thê tùy chỉnh và hợp lý hóa các ứng dụng để chỉ bao
gồm những tính năng cần thiết (vd điển hình máy chủ
JBoss).  CAO.
 Khả năng mở rộng: hầu hết các triển khai đều dựa
trên sản phẩm và thường có kích thước nhỏ, chúng
được triển khai dưới dạng các đơn vị đơn lẻ và do đó
không có khả năng mở rộng cao.  THẤP.
 Dễ dàng phát triển: đòi hỏi chặt chẽ trong thiết kế và
quản lý hợp đồng, làm cho nó khá phức tạp để thực
hiện. Phiên bản hợp đồng, sổ đăng ký plugin nội bộ,
mức độ chi tiết plugin và nhiều lựa chọn plugin sẵn
có.  THẤP.

http://hubt.edu.vn
  4. Kiến trúc microservices bao gồm các dịch vụ được triển
khai riêng biệt, trong đó mỗi dịch vụ sẽ có một trách nhiệm lý
tưởng. Các dịch vụ đó độc lập với nhau và nếu một dịch vụ bị lỗi
thì các dịch vụ khác sẽ không ngừng chạy.
• Microservices là một kiến trúc phân tán, nghĩa là tất cả các
thành phần trong kiến trúc được tách biệt hoàn toàn khỏi
nhau và được truy cập thông qua một số loại giao thức truy
cập từ xa (VD: JMS, AMQP, REST, SOAP, RMI,…).
• Kiến trúc microservices phát triển từ hai nguồn chính: các
ứng dụng nguyên khối được phát triển bằng cách sử dụng
mô hình kiến trúc phân lớp và các ứng dụng phân tán được
phát triển thông qua mô hình kiến trúc hướng dịch vụ (SOA).
– Khi triển khai ứng dụng với mô hình kiến trúc hướng dịch vụ: nó
phức tạp, tốn kém, khó hiểu và khó thực hiện và thường là quá
mức cần thiết cho hầu hết các ứng dụng. Microservices giải
quyết sự phức tạp này bằng cách đơn giản hóa khái niệm về
dịch vụ, loại bỏ nhu cầu cần điều phối và đơn giản hóa kết nối và
truy cập vào các thành phần dịch vụ.
http://hubt.edu.vn
 • Basic Microservices architecture

http://hubt.edu.vn
 • API REST-based topology
– Hữu ích cho các trang web hiển thị các dịch vụ riêng lẻ, nhỏ,
khép kín thông qua một số loại API.

http://hubt.edu.vn
 • Application REST-based topology
– Các yêu cầu máy khách được nhận thông qua các màn hình
ứng dụng kinh doanh dựa trên web truyền thống hoặc dựa trên
ứng dụng khách thay vì qua một lớp API đơn giản. Phổ biến
cho ứng dụng kinh doanh quy mô vừa và nhỏ có mức độ phức
tạp tương đối thấp.

http://hubt.edu.vn
 • Centralized messaging topology
– Tương tự Application REST-based topology, thay REST bằng
Lightweight Message Broker (VD: ActiveMQ, HornetQ,…). Lưu ý tránh
nhầm lẫn với “SOA-lite”. Kiến trúc này tìm thấy trong các ứng dụng kinh
doanh lớn hoặc các ứng dụng yêu cầu kiểm soát phức tạp hơn đối với
lớp truyền tải giữa giao diện người dùng và các thành phần dịch vụ

http://hubt.edu.vn
  Đánh giá kiến trúc Microservices:
 Tính linh động: thay đổi thường được tách biệt với
các thành phần dịch vụ riêng lẻ. Ngoài ra ứng dụng
được xây dựng bằng kiến trúc nà có xu hướng được
kết hợp lỏng lẻo, tạo điều kiện thay đổi.  CAO.
 Dễ triển khai: các dịch vụ thường được triển khai
dưới dạng các đơn vị phần mềm riêng biệt, khả năng
“triển khai nóng” bất kỳ lúc nào. Rủi ro triển khai tổng
thể giảm, các hoạt động triển khai không thành công
có thể được khôi phục nhanh hơn và chỉ tác động
đến các hoạt động trên dịch vụ đang triển khai.
 CAO.

http://hubt.edu.vn
  Khả năng kiểm tra: các thử nghiệm được xác định phạm vi,
có mục tiêu. Kiểm tra hồi quy cho một thành phần dịch vụ cụ
thể dễ dàng hơn và khả thi hơn là kiểm tra toàn bộ ứng dụng
nguyên khối.  CAO.
 Hiệu quả: có thể tạo các ứng dụng hoạt động rất tốt nhưng
về tổng thể không phù hợp với các ứng dụng hiệu suất cao
do bản chất phân tán của kiến trúc này.  THẤP.
 Khả năng mở rộng: ứng dụng chia thành các đơn vị triển khai
riêngbiệt, mỗi thành phần dịch vụ có thể chia tỷ lệ, cho phép
tinh chỉnh quy mô của ứng dụng.  CAO.
 Dễ phát triển: vì chức năng tách biệt thành các thành phần
dịch vụ nên dễ dàng phát triển (do phạm vi nhỏ và bị cô lập).
Có ít khả năng thực hiện thay đổi trong một thành phần dịch
vụ có thể ảnh hưởng đến các thành phần khác, do đó giảm
sự phối hợp cần thiết giữa các nhà phát triển hoặc nhóm
phát triển.  CAO.
http://hubt.edu.vn
  5. Kiến trúc dựa trên không gian (Space-based
Architecture)
• Ý tưởng chính đằng sau mô hình dựa trên không gian là bộ
nhớ được chia sẻ phân tán để giảm thiểu các vấn đề thường
xuyên xảy ra ở cấp cơ sở dữ liệu. Giả định là bằng cách xử
lý hầu hết các hoạt động sử dụng dữ liệu trong bộ nhớ,
chúng ta có thể tránh các hoạt động bổ sung trong cơ sở dữ
liệu, do đó bất kỳ vấn đề nào trong tương lai có thể phát triển
từ đó (ví dụ: nếu thực thể dữ liệu hoạt động người dùng của
bạn đã thay đổi, bạn không cần để thay đổi một loạt mã liên
tục và truy xuất dữ liệu đó từ DB).
• Cách tiếp cận cơ bản là tách ứng dụng thành các đơn vị xử
lý (có thể tự động tăng và giảm quy mô dựa trên nhu cầu),
nơi dữ liệu sẽ được sao chép và xử lý giữa các đơn vị đó mà
không cần bất kỳ sự ổn định nào đối với cơ sở dữ liệu trung
tâm (mặc dù sẽ có các kho lưu trữ cục bộ cho nhân sự cố hệ
thống).
http://hubt.edu.vn
  Hai thành phần chính:
• Processing Unit: chứa các thành phần ứng dụng, thường chứa các
mô đun ứng dụng, cùng với lưới dữ liệu trong bộ nhớ và một kho
lưu trữ liên tục không đồng bộ tùy chọn để chuyển đổi dự phòng.
Nó cũng chứa một công cụ sao chép các thay đổi dữ liệu giữa các
đơn vị xử lý.
• Virtualized Middware: xử lý việc quản lý và liên lạc. Nó chứa các
thành phần kiểm soát các khía cạnh khác nhau của đồng bộ hóa dữ
liệu và xử lý yêu cầu.

http://hubt.edu.vn
 • Messaging-grid component
– Quản lý thông tin yêu cầu đầu vào và phiên: xác định các thành
phần xử lý đang hoạt động, chuyển tiếp yêu cầu đến một trong
các đơn vị xử lý nào đó.

http://hubt.edu.vn
 • Data-grid component
– Quan trọng nhất, tương tác với công cụ nhân dữ liệu trong mỗi đơn vị
xử lý để quản lý việc sao chép dữ liệu giữa các đơn vị xử lý khi xảy ra
cập nhật dữ liệu.
– Trong hình sự sao chép dữ liệu đồng bộ giữa các đơn vị xử lý, trên
thực tế điều này được thực hiện song song không đồng bộ và rất
nhanh chóng, đôi khi hoàn thành việc đồng bộ hóa dữ liệu chỉ vài micro
giây (một phần triệu giây).

http://hubt.edu.vn
 • Processing-grid component
– Một thành phần tùy chọn, quảnlý quá trình xử lý yêu cầu phân
tán khi có nhiều đơn vị xử lý, mỗi đơn vị xử lý một phần của
ứng dụng. VD: một yêu cầu cần phối hợp đơn vị xử lý đơn đặt
hàng và đơn vị xử lý khách hàng.

http://hubt.edu.vn
  Đánh giá kiến trúc dựa trên không gian:
 Tính linh động: bởi vì các đơn vị xử lý (các phiên bản
được triển khai của ứng dụng) có thể đưa lên và
xuống nhanh chóng, các ứng dụng phản ứng tốt với
các thay đổi liênquan đến tăng hoặc giảm tải. 
CAO.
 Dễ triển khai: các kiến trúc này thường không được
tách rời và phân tán, nhưng chúng là các công cụ
động và tinh vi dựa trên đám mây cho phép các ứng
dụng dễ dàng được “đẩy” ra máy chủ, đơn giản hóa
việc triển khai.  CAO.
 Khả năng kiểm tra: việc đạt được tải cao trong môi
trường thử nghiệm vừa tốn kém, tốn thời gian, gây
khó khăn cho việc kiểm tra.  THẤP.
http://hubt.edu.vn
  Hiệu quả: hiệu suất cao đạt được thông qua cơ chế
truy cập dữ liệu trong bộ nhớ và bộ đệm được tích
hợp.  CAO.
 Khả năng mở rộng: xuất phát từ thực tế là có rất ít
hoặc không có sự phụ thuộc vào CSDL tập trung, do
đó cung cấp khả năng mở rộng.  CAO.
 Dễ dàng phát triển: các sản phẩm lưới dữ liệu trong
bộ nhớ đệm và bộ nhớ đệm phức tạp làm cho mô
hình này phức tạp để phát triển, chủ yếu là do thiếu
sự quen thuộc với các công cụ và sản phẩm được sử
dụng để tạo ra kiểu kiến trúc này. Hơn nữa, đặcbiệt
chú ý trong khi phát triển các loại kiến trúc này để
đảm bảo rằng không có gì trong mã nguồn ảnh
hưởng đến hiệu suất và khả năng mở rộng.  THẤP.
http://hubt.edu.vn
 Tóm tắt
Space-
Layered Event-driven Microkernel Microservices
based

Tính
linh động

Dễ
triển khai

Khả năng
kiểm tra

Hiệu suất

Khả năng
mở rộng

Dễ
phát triển
http://hubt.edu.vn
  Các mô hình kiến trúc phổ dụng khác
 6. Kiến trúc đơn thể (Monolithic): hệ thống chỉ gồm duy nhất 1
mô đun. Module này chứa mọi thứ của chương trình:
• Giao tiếp giữa các thành phần là cục bộ và rất hiệu quả.
• Thích hợp cho những phần mềm nhỏ, đơn giản.
• Không thích hợp cho những phần mềm lớn và phực tạp.
 7. Kiến trúc lô tuần tự (Batch Sequential). Chương trình gồm n
phần mềm độc lập và được chạy theo cơ chế tuần tự: phần
mềm i chạy trước, khi xong rồi thì truyền kết quả cho phần mềm
thứ i+1... Mỗi phần mềm i trong lô được gọi là filter, nó xử lý dữ
liệu đầu vào theo định dạng xác định rồi tạo kết quả đầu ra theo
định dạng xác định.

http://hubt.edu.vn
  7. Kiến trúc lô tuần tự (Batch Sequential)
• Tình huống nên dùng: trong các ứng dụng xử lý dữ liệu mà
dữ liệu nhập cần được xử lý bởi nhiều công đoạn khác nhau
và có tính độc lập cao trước khi tạo ra kết quả cuối cùng.
• Ưu điểm: dễ dàng thay đổi/bảo trì/dùng lại từng filter của hệ
thống, phù hợp với nhiều hoạt ₫ộng nghiệp vụ, dễ dàng
nâng cấp bằng cách thêm filter mới.
• Khuyết điểm: 2 filter kề nhau cần tuân thủ ₫ịnh dạng dữ liệu
chung.
• VD: thiết kế trực quan của cửa sổ giao diện và dùng nó trong
phần mềm Android.

http://hubt.edu.vn
  8. Kiến trúc đường ống và lọc (Pipe and filter Architecture):
mở rộng kiến trúc lô tuần tự lên tầm cao mới
• Các filter không nhất thiết là phần mềm độc lập lẫn nhau, chúng có
thể là các thread chạy trong 1 chương trình.
• Có thể có nhiều ống con trong từng đoạn xử lý.
• Tình huống nên dùng: trong các ứng dụng xử lý dữ liệu mà dữ liệu
nhập cần được xử lý bởi nhiều công đoạn khác nhau và có tính độc
lập cao trước khi tạo ra kết quả cuối cùng.
• Ưu điểm: dễ dàng thay đổi/bảo trì/dùng lại từng filter của hệ thống,
phù hợp với nhiều hoạt động nghiệp vụ, dễ dàng nâng cấp bằng
cách thêm filter mới, hiệu quả cao hơn kiến trúc lô tuần tự.
• Khuyết điểm: 2 filter kề nhau cần tuân thủ định dạng dữ liệu chung.

http://hubt.edu.vn
 • VD: Một tổ chức đã xuất hóa đơn cho khách hàng.
Mỗi tuần một lần, các khoản thanh toán được đối
chiếu với các hóa đơn. Đối với các hóa đơn đã
được thanh toán, xuất hóa đơn đỏ. Đối với những
hóa đơn chưa thanh toán, đưa là lời nhắc nợ.

http://hubt.edu.vn
  9. Kiến trúc client-server (client-server Architecture).
Hệ thống gồm 2 loại phần tử chức năng: server cung
cấp 1 số dịch vụ, client là phần tử sử dụng dịch vụ
bằng cách truy xuất đến server tương ứng.
• Tình huống nên dùng: khi database dùng chung từ nhiều vị
trí khác nhau hay khi tải hệ thống thay đổi động (nhân bản
server thành nhiều phần tử).
• Ưu điểm: server có thể phân tán tự do trên mạng.
• Khuyết điểm: độ hiệu quả phụ thuộc vào mạng và hệ thống
nên khó lường trước. Nếu các server được quản lý bởi các
tổ chức khác nhau thì có vấn đề về quản lý chúng.

http://hubt.edu.vn
 • VD: hệ thống quản lý phim ảnh dùng mô hình
client-server

http://hubt.edu.vn
  10. Kiến trúc 3 đối tác (3-tiers Architecture): Sự cải
tiến của kiến trúc client-server. Hệ thống gồm 3 loại
phần tử chức năng: client, server, và server của
server.
• Tình huống nên dùng: khi database dùng chung từ nhiều vị
trí khác nhau hay khi tải hệ thống thay đổi động (nhân bản
server thành nhiều phần tử).
• Ưu điểm: server có thể phân tán tự do trên mạng.
• Khuyết điểm: độ hiệu quả phụ thuộc vào mạng và hệ thống
nên khó lường trước. Nếu các server được quản lý bởi các
tổ chức khác nhau thì có vấn ₫ề về quản lý chúng.

http://hubt.edu.vn
 • VD: hệ thống quản lý phim ảnh dùng mô hình 3-
tiers

http://hubt.edu.vn
  11. Kiến trúc n đối tác (n-tiers Architecture). Sự tổng
quát của kiến trúc 3-tiers. Hệ thống gồm n loại phần
tử chức năng : client, server, và server của server,...
• Tình huống nên dùng: khi database dùng chung từ nhiều vị
trí khác nhau hay khi tải hệ thống thay ₫ổi ₫ộng (nhân bản
server thành nhiều phần tử).
• Ưu điểm: server có thể phân tán tự do trên mạng.
• Khuyết điểm: độ hiệu quả phụ thuộc vào mạng và hệ thống
nên khó lường trước. Nếu các server được quản lý bởi các
tổ chức khác nhau thì có vấn đề về quản lý chúng.

http://hubt.edu.vn
 • VD: hệ thống quản lý phim ảnh dùng mô hình n-
tiers

http://hubt.edu.vn
  12. Kiến trúc MVC (Model-View-Controller): Hệ thống gồm 3
thành phần luận lý tương tác lẫn nhau :
• Model quản lý dữ liệu và các tác vụ liên quan đến dữ liệu này.
• View định nghĩa và quản lý cách thức dữ liệu được trình bày cho
user.
• Controller quản lý các tương tác với user như ấn phím, click
chuột… và gởi thông tin tương tác này tới View và/hoặc Model.
• Tình huống nên dùng: Hệ thống có nhiều cách để view và tương tác
với dữ liệu, hoặc ta chưa biết trước các yêu cầu tương lai về sự
tương tác và biểu diễn dữ liệu của chương trình.
• Ưu điểm: cho phép dữ liệu thay đổi độc lập với cách thức thể hiện
nó và ngược lại.
• Khuyết điểm: có thể cần nhiều code hơn và code có thể phức tạp
hơn khi mô hình dữ liệu và sự tương tác chỉ ở mức độ đơn giản.

http://hubt.edu.vn
 • VD: kiến trúc ứng dụng web sử dụng mô hình
MVC

http://hubt.edu.vn
  13. Kiến trúc MVP (Model-View-Presenter): Hệ thống gồm 3
thành phần luận lý tương tác lẫn nhau:
• Model quản lý dữ liệu và các tác vụ liên quan đến dữ liệu này.
• View định nghĩa và quản lý cách thức dữ liệu được trình bày cho
user, quản lý các tương tác với user như ấn phím, click chuột… và
gởi thông tin tương tác này tới Presenter để nhờ xử lý chi li hơn.
• Presenter xử lý chi li về luận lý nghiệp vu, nhờ Model truy xuất dữ
liệu khi cần.
• Tình huống nên dùng: Hệ thống có nhiều cách ₫ể view và tương tác
với dữ liệu, hoặc ta chưa biết trước các yêu cầu tương lai về sự
tương tác và biểu diễn dữ liệu của chương trình.
• Ưu điểm: cho phép dữ liệu thay đổi độc lập với cách thức thể hiện
nó và ngược lại.
• Khuyết điểm: có thể cần nhiều code hơn và code có thể phức tạp
hơn khi mô hình dữ liệu và sự tương tác chỉ ở mức độ đơn giản.

http://hubt.edu.vn
  14. Kiến trúc kho (Repository Architecture): Tất cả dữ liệu của
hệ thống được quản lý trong 1 kho chứa tập trung, mọi thành
phần chức năng của hệ thống đều có thể truy xuất kho chứa
này. Các thành phần không tương tác trực tiếp với nhau, chỉ
thông qua kho chứa tập trung.
• Tình huống nên dùng : khi hệ thống tạo và chứa 1 lượng rất lớn
thông tin trong thời gian dài, hay trong các hệ thống dựa vào dữ
liệu, ở đó việc chứa thông tin vào kho sẽ kích hoạt 1 tool hay 1
chức năng hoạt động.
• Ưu điểm: các thành phần độc lập nhau, không ai biết gì về ai khác.
• Khuyết điểm: kho là điểm yếu nhất, nếu có lỗi sẽ ảnh hưởng toàn
bộ các thành phần chức năng. Có vấn đề về truy xuất đồng thời
kho, phân tán kho trên nhiều máy cũng khó khăn.

http://hubt.edu.vn
 • VD: môi trường IDE gồm nhiều thành phần dùng
chung kho thông tin, mỗi tool tạo thông tin và để
trong kho để các tool khác dùng.

http://hubt.edu.vn
  15. Kiến trúc hướng đối tượng (Objects
based Architecture): Hệ thống phần mềm gồm
1 tập các đối tượng độc lập được ghép nối
lỏng lẻo.
• Tình huống nên dùng: bất kỳ hệ thống phần mềm
phức tạp nào.
• Khuyết điểm: là mẫu kiến trúc có độ tổng quát cao
nên khi hiện thực ta phải tốn nhiều chi phí để vận
dụng nó.

http://hubt.edu.vn
  16. Kiến trúc các thành phần (Components based
Architecture): Hệ thống phần mềm gồm 1 tập các
thành phần độc lập được ghép nối lỏng lẻo.
• Tình huống nên dùng : bất kỳ hệ thống phần mềm phức tạp
nào.
• Khuyết điểm : là mẫu kiến trúc có độ tổng quát cao nên khi
hiện thực ta phải tốn nhiều chi phí để vận dụng nó.

http://hubt.edu.vn
  17. Kiến trúc hướng dịch vụ (Service-
Oriented Architecture): Cho phép tạo phần
mềm bằng cách sử dụng các dịch vụ sẵn có.
• Service: phần tử cung cấp 1 số chức năng đa
dụng nào đó và thường đã có sẵn.
• Tình huống nên dùng: bất kỳ hệ thống phần mềm
phức tạp nào mà muốn chạy trên nền Internet.
• Khuyết điểm: độ hiệu quả phụ thuộc vào cơ sở hạ
tầng mạng và máy chạy service.

http://hubt.edu.vn
  18. Kiến trúc Chương trình chính và thủ tục (Main
Program/Subroutine Architecture): Hệ thống phần mềm gồm 1
chương trình chính và 1 tập các thủ tục chức năng cần thiết.
• Dùng cách phân rã theo dạng cây phân cấp: dựa trên mối quan hệ
định nghĩa-sử dụng.
• Chỉ có 1 thread kiểm soát duy nhất: được hỗ trợ trực tiếp bởi các
ngôn ngữ lập trình.
• Ẩn chứa cấu trúc hệ thống con: các thủ tục có mối quan hệ mật
thiết thường được gộp thành module.
• Lý do của sự phân cấp: độ đúng đắn của 1 thủ tục phụ thuộc vào
sự đúng đắn của các thủ tục mà nó gọi.

http://hubt.edu.vn
  19. Kiến trúc các process liên lạc nhau
(Communication process Architecture): Hệ thống
phần mềm gồm 1 tập các process độc lập liên lạc lẫn
nhau khi cần.
• Process: là nguyên tử cấu thành phần mềm, nó chạy độc
lập, mỗi process thực hiện 1 chức năng xác định.
• Connector là phương tiện tương tác (truyền thông báo) giữa
các process:
– Điểm tới điểm, Đồng bộ hay bất đồng bộ, RPC và các giao thức khác
có thể được đặt trên cấp các process này.

http://hubt.edu.vn
  20. Kiến trúc bảng đen (Blackboard Architecture): Hệ thống
phần mềm gồm 3 loại thành phần tương tác nhau như sau:
• Blackboard: là vùng nhớ toàn cục có cấu trúc của phần mềm, nó
chứa các đối tượng của bài toán cần giải quyết, còn được gọi là các
nút, chúng được tổ chức dạng phân cấp.
• Knowledge sources: là những module chức năng chuyên dụng có
cách biểu diễn riêng biệt. Mỗi KS được đặc trưng bởi 1 tập các điều
kiện kích hoạt xác định và đoạn code xử lý dữ liệu từ blackboard rồi
đóng góp kết quả vào quá trình giải quyết bài toán.
• Control: là phần tử điều khiển chung, nó cấu hình, chọn lựa và thi
hành các KS. Việc xác định KS nào là dựa vào trạng thái của quá
trình giải quyết bài toán (được miêu tả trong blackboard).

http://hubt.edu.vn
 3.2.3 Rà soát kiến trúc

 Là nhiệm vụ quan trọng nhất để giảm chi phí sai sót, tìm
ra và khắc phục sớm các vấn đề kiến trúc. Đó là một
cách hiệu quả, được thiết lập tốt để giảm chi phí dự án
và khả năng thất bại của dự án.
 Thường xuyên xem xét kiến trúc tại các mốc quan trọng
của dự án và để ứng phó với những thay đổi kiến trúc
quan trọng khác.
 Mục tiêu chính của đánh giá kiến ​trúc là xác định tính
khả thi của các kiến ​trúc cơ sở và ứng viên để xác minh
kiến ​trúc đó một cách chính xác.
 Liên kết các yêu cầu chức năng và các thuộc tính chất
lượng với giải pháp kỹ thuật được đề xuất. Nó cũng giúp
xác định các vấn đề và nhận ra các lĩnh vực cần cải
thiện
http://hubt.edu.vn
  Đánh giá dựa trên tình huống là một phương pháp chủ đạo để xem
xét một thiết kế kiến ​trúc, trong đó tập trung vào các tình huống
quan trọng nhất từ ​góc độ kinh doanh và có tác động lớn nhất đến
kiến ​trúc.
 Phương pháp phân tích kiến ​trúc phần mềm (Software Architecture
Analysis Method - SAAM). Ban đầu nó được thiết kế để đánh giá khả
năng sửa đổi, nhưng sau đó đã được mở rộng để xem xét kiến ​trúc liên
quan đến các thuộc tính chất lượng.
 Phương pháp phân tích đánh đổi kiến ​trúc (Architecture Tradeoff
Analysis Method - ATAM). Đây là phiên bản được đánh bóng và cải tiến
của SAAM, xem xét các quyết định về kiến ​trúc đối với các yêu cầu về
thuộc tính chất lượng và mức độ đáp ứng các mục tiêu chất lượng cụ
thể của chúng.
 Đánh giá thiết kế tích cực (Active Design Review - ADR) Nó phù hợp
nhất cho các kiến ​trúc chưa hoàn thiện hoặc đang trong quá trình thực
hiện, tập trung nhiều hơn vào một tập hợp các vấn đề hoặc các phần
riêng lẻ của kiến ​trúc tại một thời điểm, thay vì thực hiện đánh giá
chung.

http://hubt.edu.vn
  Đánh giá tích cực về các thiết kế trung gian (Active Reviews
of Intermediate Designs - ARID). Nó kết hợp khía cạnh ADR của
việc xem xét kiến ​trúc đang tiến hành với việc tập trung vào một
số vấn đề và cách tiếp cận ATAM và SAAM của việc xem xét
dựa trên kịch bản tập trung vào các thuộc tính chất lượng.
 Phương pháp phân tích lợi ích chi phí (Cost Benefit Analysis
Method - CBAM)Nó tập trung vào việc phân tích chi phí, lợi ích
và ý nghĩa lịch trình của các quyết định về kiến ​trúc.
 Phân tích khả năng sửa đổi cấp độ kiến ​trúc (Architecture
Level Modifiability Analysis - ALMA). Nó ước tính khả năng sửa
đổi của kiến ​trúc cho hệ thống thông tin kinh doanh (BIS).
 Phương pháp đánh giá kiến ​trúc gia đình (Family Architecture
Assessment Method - FAAM) Nó ước tính các kiến ​trúc họ hệ
thống thông tin cho khả năng tương tác và khả năng mở rộng.

http://hubt.edu.vn
 3.2.4 Mô tả kiến trúc

 Có một số phương pháp nổi tiếng sau đây để mô tả kiến

​trúc cho những người khác (nhóm phát triển, quản trị
viên hệ thống, nhà điều hành, chủ sở hữu doanh nghiệp
và các bên quan tâm khác):
 4 + 1 Model. Cách tiếp cận này sử dụng năm góc nhìn của kiến ​
trúc hoàn chỉnh. Trong số đó, bốn khung nhìn (logic view,
process view, physical view và development view) mô tả kiến ​
trúc từ các cách tiếp cận khác nhau. Chế độ xem thứ năm hiển
thị các tình huống và ca sử dụng cho phần mềm. Nó cho phép
các bên liên quan xem các đặc điểm của kiến ​trúc mà họ quan
tâm cụ thể.
 Ngôn ngữ mô tả kiến ​trúc (Architecture Description Language
- ADL). Cách tiếp cận này được sử dụng để mô tả kiến ​trúc
phần mềm trước khi triển khai hệ thống. Nó giải quyết các mối
quan tâm sau - hành vi, giao thức và kết nối (connector).

http://hubt.edu.vn
  Agile Modeling. Cách tiếp cận này tuân theo khái niệm rằng
“nội dung quan trọng hơn sự trình bày”. Nó đảm bảo rằng các
mô hình được tạo đơn giản và dễ hiểu, đủ chính xác, chi tiết và
nhất quán.
 IEEE 1471 là tên viết tắt của tiêu chuẩn chính thức được gọi là
ANSI/IEEE 1471-2000, “Recommended Practice for Architecture
Description of Software-Intensive Systems”. IEEE 1471 nâng
cao nội dung của mô tả kiến ​trúc, đặc biệt, mang lại ý nghĩa cụ
thể cho ngữ cảnh (context), quan điểm (viewpoint) và góc nhìn.
 Ngôn ngữ mô hình thống nhất (UML). Cách tiếp cận này thể
hiện ba quan điểm của một mô hình hệ thống. Chế độ xem các
yêu cầu chức năng (các yêu cầu chức năng của hệ thống theo
quan điểm của người dùng, bao gồm cả các ca sử dụng); chế
độ xem cấu trúc tĩnh (đối tượng, thuộc tính, mối quan hệ và hoạt
động bao gồm cả biểu đồ lớp); và chế độ xem hành vi động (sự
cộng tác giữa các đối tượng và thay đổi trạng thái bên trong của
các đối tượng, bao gồm biểu đồ trình tự, hoạt động và trạng
thái).
http://hubt.edu.vn
 3.3 Thiết kế hướng đối tượng

Kiến trúc phần mềm truyền thống

http://hubt.edu.vn
 Vấn đề của thiết kế hướng thủ tục
 Dữ liệu là chung cho cả hệ thống
• Mọi thủ tục thao tác trên CSDL chung, đặc trưng
cho trạng thái toàn hệ thống.
• Thao tác sai của một thủ tục lên dữ liệu gây sai lan
truyền sang phần khác sử dụng dữ liệu này.
• Sửa đổi một thủ tục có nguy cơ ảnh hưởng tới
phần khác liên quan.
 Thay đổi cấu trúc dữ liệu dẫn đến thay đổi
tổng thể hệ thống  dữ liệu cần tổ chức tốt.
 Hệ thống lớn, phức tạp: bảo trì khó khăn.

http://hubt.edu.vn
 Thiết kế hướng đối tượng – OOD
 Hiện đang trở nên phổ biến.
 Là một cách tiếp cận khác, nhìn nhận hệ
thống theo các quan điểm:
• Tập các đối tượng có tương tác với nhau.
• Mỗi đối tượng bao gói cả dữ liệu và các xử lý trên
chúng.
• Tương tác giữa các đối tượng bằng truyền thông
báo.
• Các đối tượng có thể kế thừa nhau.

http://hubt.edu.vn
 VD: kiến trúc hướng đối tượng

http://hubt.edu.vn
  Ưu điểm của OOD
• Dễ bảo trì: các đối tượng được hiểu như các thực
thể hoạt động độc lập.
– Bao gói thông tin.
– Liên kết lỏng lẻo (trao đổi bằng truyền thông điệp).
• Dễ tái sử dụng:
– Độ độc lập cao.
– Có khả năng kế thừa.
• Dễ hiểu: một vài hệ thống, có sự ánh xạ tường
minh giữu thực thể trong thế giới thật và đối tượng
hệ thống.

http://hubt.edu.vn
  Nội dung của OOD
• Xác định các tập đối tượng (gọi là lớp) và các đặc
trưng của chúng.
• Phân định vai trò và trách nhiệm của chúng trong
hệ thống.
• Thiết lập được sự tương tác của chúng để thực
hiện chức năng của hệ thống phần mềm đặt ra.

http://hubt.edu.vn
  Các khái niệm của OOD
• Đối tượng.
• Lớp đối tượng.
• Trừu tượng hóa.
• Bao gói và che dấu thông tin.
• Cấu trúc dữ liệu.
• Tổng quát hóa và kế thừa.
• Tương tác giữa các đối tượng.

http://hubt.edu.vn
  Ngôn ngữ mô hình hóa thống nhất (Unified
Modeling Language – UML).
• Là một ngôn ngữ mô hình để phát triển phần mềm
hướng đối tượng
• UML là ngôn ngữ:
– Đồ họa.
– Làm trực quan hóa.
– Đặc tả.
– Xây dựng mô hình.
– Làm tài liệu.

http://hubt.edu.vn
  UML gồm ba khối cơ bản:
• A. Các sự vật (things)
– Các sự vật cấu trúc (structural)
– Các sự vật hành vi (behavioral)
– Các sự vật nhóm gộp (grouping)
– Các sự vật giải thích (annotational)
• B. Các quan hệ (relationships)
• C. Các biểu đồ (diagrams)

http://hubt.edu.vn
 A. Các sự vật

http://hubt.edu.vn
 B. Các quan hệ

http://hubt.edu.vn
 C. Các biểu đồ

http://hubt.edu.vn
  Mô hình phân tích
 Mô hình nghiệp vụ
• Mô hình miền.
• Biểu đồ hoạt động.
 Mô hình ca sử dụng
 Mô hình lớp phân tích
 Mô hình gói lớp.
 Mô hình thiết kế
 Mô hình cấu trúc gói.
 Mô hình cộng tác.
 Mô hình lớp.
 Đặc tả lớp, giao diên.

http://hubt.edu.vn
 Tiến trình phân tích – thiết kế đối tượng

http://hubt.edu.vn
  Phân tích hướng đối tượng
• 1. Phân tích một ca sử dụng
– Tìm các lớp phân tích.
– Xác định liên kết giữa các lớp.
• 2. Phân gói lại các lớp phân tích (tăng cường kiến
trúc)
– Tách các lớp dịch vụ & ứng dụng.
– Phân gói các lớp phân tích theo tầng.
• 3. Xác định và mô tả các giao diện
– Xác định giao diện giữa các gói.
– Xác định liên kết giữa các gói.

http://hubt.edu.vn
  Thiết kế hướng đối tượng
• 1. Thiết kế biểu đồ tương tác mỗi gói
– Xác định lại các lớp.
– Xây dựng biểu đồ tương tác.
• 2. Phát triển biều đồ lớp thiết kế
– Chuyển biểu đồ cộng tác sang biểu đồ lớp.
– Hoàn thiện các quan hệ cộng tác
• 3. Thiết kế các lớp
– Thiết kế các thuộc tính.
– Thiết kế các phương thức.
– Thiết kế CSDL.
• 4. Thiết kế giao diện người dùng

http://hubt.edu.vn
 Mẫu thiết kế HĐT- Pattern

 Một biện pháp được đề xuất để có những bản thiết kế

tốt, hạn chế được việc tái thiết kế lại và khi cần thiết kế
lại, nó phải hỗ trợ tốt nhất việc tái thiết kế là sử dụng lại
những mẫu thiết kế hướng đối tượng (Object Oriented
Design Patterns), hay gọi tắt là mẫu thiết kế (Design
Patterns).
 Vậy mẫu thiết kế là gì? Mẫu thiết kế có các đặc điểm:
 Là bản thiết kế của những người chuyên nghiệp và nổi tiếng, đã
được sử dụng trong các phần mềm đang được dùng phổ biến
và được người dùng đánh giá tốt.
 Giúp giải quyết 1 trong những vấn đề thiết kế thường gặp trong
các phần mềm.
 Giúp cho bản thiết kế phần mềm có tính uyển chuyển cao, dễ
hiệu chỉnh và dễ nâng cấp.

http://hubt.edu.vn
  Vai trò của mẫu thiết kế: mẫu thiết kế đóng 1 số vai trò
chính yếu như sau :
 Cung cấp phương pháp giải quyết những vấn đề thực tế thường
gặp trong phần mềm mà mọi người đã đánh giá, kiểm nghiệm là
rất tốt.
 Là biện pháp tái sử dụng tri thức các chuyên gia phần mềm.
 Hình thành kho tri thức, ngữ vựng trong giao tiếp giữa những
người làm phần mềm.
 Giúp ta tìm hiểu để nắm vững hơn đặc điểm ngôn ngữ lập trình
hướng đối tượng.
 Như vậy, nếu sử dụng triệt để các mẫu thiết kế trong
việc thiết kế phần mềm mới, ta sẽ tiết kiệm được chi phí,
thời gian và nguồn lực. Hơn nữa PM tạo được sẽ có ₫ộ
tin cậy, uyển chuyển cao, dễ dàng hiệu chỉnh và nâng
cấp sau này khi cần thiết.
http://hubt.edu.vn
  Phân loại các mẫu thiết kế: Dựa vào công dụng, ta có
thể phân các mẫu thiết kế thành 3 nhóm chính:
 Structural (nhóm mẫu cấu trúc): các mẫu này cung cấp cơ chế
để quản lý cấu trúc và mối quan hệ giữa các class, thí dụ ₫ể
dùng lại các class có sẵn (class thư viện, class của bên thứ ba -
third party,…), để tạo mối ràng buộc thấp nhất giữa các class
(lower coupling) hay cung cấp các cơ chế thừa kế khác.
 Creational (nhóm mẫu phục vụ khởi tạo đối tượng): giúp khắc
phục các vấn đề về khởi tạo đối tượng, nhất là đối tượng lớn và
phức tạp, hạn chế sự phụ thuộc của phần mềm vào platform
cấp thấp.
 Behavioral (nhóm mẫu giải quyết hành vi của đối tượng): giúp
che dấu sự hiện thực của đối tượng, che dấu giải thuật, hỗ trợ
việc thay đổi cấu hình đối tượng một cách linh hoạt.

http://hubt.edu.vn
  Phân loại các mẫu thiết kế: Còn nếu dựa vào loại phần
tử được dùng trong mẫu, ta có thể phân các mẫu thiết
kế thành 2 nhóm chính :
 Class patterns: nhóm mẫu thiết kế chỉ sử dụng các class và
mối quan hệ tĩnh giữa các class như thừa kế, hiện thực. Các
mối quan hệ này được xác định tại thời ₫iểm dịch, do đó class
patterns thích hợp cho thành phần chức năng không cần thay
đổi động trong thời gian chạy.
 Object patterns: nhóm mẫu thiết kế có dùng mối quan hệ giữa
các đối tượng, mối quan hệ này rất động vì dễ dàng thay đổi bất
kỳ lúc nào trong lúc phần mềm chạy.

http://hubt.edu.vn
  Ví dụ một số mẫu thiết kế
 Structural Pattern  Behavioral Pattern
• 1. Mẫu Adapter. • 1. Mẫu Chain of Responsibility.
• 2. Mẫu Composite. • 2. Mẫu Template Method.
• 3. Mẫu Strategy.
• 3. Mẫu Proxy.
• 4. Mẫu State.
• 4. Mẫu Decorator. • 5. Mẫu Command.
• 5. Mẫu Facade. • 6. Mẫu Observer.
• 6. Mẫu Flyweight.
 Creational Pattern
• 1. Mẫu Abstract Factory.
• 2. Mẫu Factory Method.
• 3. Mẫu Prototype.
• 4. Mẫu Buider.
• 5. Mẫu Singleton.
http://hubt.edu.vn
 3.4 Thiết kế giao diện
 Vai trò, tầm quan trọng
 Một khâu không thể thiếu trong thiết kế phần mềm –
người dùng đánh giá phần mềm qua giao diện.
 Thiết kế giao diện:
• Hướng người dùng.
• Che dấu chi tiết kỹ thuật bên trong.
• Kết hợp 3 mặt: người dùng, chức năng, công nghệ.
 Là phương tiện để người dùng sử dụng hệ thống
• Giao diện thiết kế nghèo nàn người dùng dễ mắc lỗi.
• Giao diện thiết kế tồi là lý do nhiều phần mềm không được
sử dụng
 Giao diện trợ giúp người dùng làm việc
• Giao diện trợ giúp tốt, người dùng thành công.
• Giao diện trợ giúp tồi, người dùng khó khăn, thất bại.

http://hubt.edu.vn
 Tiến trình thiết kế giao diện chung

http://hubt.edu.vn
 Tiến trình thiết kế giao diện làm mẫu

http://hubt.edu.vn
 Nguyên tắc thiết kế giao diện
 Cần phản ánh vào thiết kế:
• Kinh nghiệm, năng lực, nhu cầu của người dùng.
– Khả năng dùng bàn phím, chuột,
– Tốc độ phản ứng, khả năng nhớ thao tác.
• Sở thích, văn hóa, lứa tuổi, mầu sắc, ngôn ngữ,…
• Những hạn chế về mặt vật chất và tinh thần của
người dùng (trí nhớ, vụng về,…có thể mắc lỗi).
 Luôn bao gồm việc làm bản mẫu để người
dùng đánh giá.

http://hubt.edu.vn
  Giao diện cần có các tính chất sau đây:
• Tính thân thiện: thuật ngữ, khái niệm, thói quen, trình tự
nghiệp vụ của người dùng.
• Tính nhất quán: vị trí hiển thị, câu lệnh, thực đơn, biểu
tượng, màu sắc – cùng dạng.
• Ít gây ngạc nhiên.
• Có cơ chế phục hồi tình trạng trước lỗi.
• Cung cấp kịp thời phản hồi và trợ giúp mọi lúc, mọi nơi.
• Tiện ích tương tác đa dạng.
 Thiết bị tương tác thường gặp:
• Màn hình, màn hình cảm biến,
• Bàn phím, chuột, bút từ, bóng xoay,
• Mic/Speaker, smart cards,…

http://hubt.edu.vn
  Các kiểu tương tác thông dụng
• Thao tác trực tiếp.
• Chọn thực đơn.
• Chọn biểu tượng.
• Điền vào mẫu biểu.
• Ngôn ngữ lệnh.
• Ngôn ngữ tự nhiên.

http://hubt.edu.vn
  Các loại giao diện truyền thống
 Giao diện dòng lệnh (giao diện hỏi đáp)
• Là phương thức tương tác có sớm nhất.
• Nhập lệnh/dữ liệu từ bàn phím.
• Dễ cài đặt so với GUI.
– Thực hiện thông qua hàm chuẩn của ngôn ngữ.
– Không tốn tài nguyên hệ thống.
• Có khả năng tổ hợp lệnh để tạo các lệnh phức tạp
– Phối hợp các filter, tạo các lô xử lý (batch)
– Có thể lập trình bằng shell.
– Có thể tự động hóa.
• Thao tác thực hiện tuần tự
– Khó sửa lỗi thao tác trước đó.
• Không phù hợp với người dùng ít kinh nghiệm.

http://hubt.edu.vn
  Giao diện đồ họa (Graphic User Interface – GUI)
• Thông dụng, dễ học, dễ sử dụng, thuận tiện với người ít kinh
nghiệm.
• Có nhiều cửa sổ, có thể tương tác song song.
• Hiển thị, tương tác dữ liệu trên nhiều vị trí trong cửa sổ.
• Tương tác trực tiếp với thông tin: soạn thảo; nhập dữ liệu
vào các form
– Dễ học, dễ sử dụng.
– Nhận được tức thời kết quả thao tác.
– Cài đặt phức tạp, tốn tài nguyên phần cứng.

http://hubt.edu.vn
 Tương tác trực Tương tác gián
tiếp tiếp

http://hubt.edu.vn
  Các quy tắc thiết kế cho từng nền tảng
 Hướng dẫn về giao diện con người iOS - Apple
• Trang web: https://developer.apple.com/design/
• Hướng dẫn thiết kế giao diện người dùng chính thức của
Apple. Bạn có thể tải xuống các mẫu giao diện người dùng
như iOS, macOS, macOS, tvOS và thậm chí là các tệp
nguồn cho Sketch, Photoshop, Adobe XD và Keynote tại đây.
 Material Design - Google
• Trang web: https://material.io/guidelines/
• Nếu bạn đang thiết kế một sản phẩm cho chợ ứng dụng
Google, thì bạn cần biết các thông số kỹ thuật của Material
Design do Google cung cấp. Màu sắc, bố cục, cỡ chữ, điều
hướng, v.v. đều được trình bày chi tiết.

http://hubt.edu.vn
  Hệ thống thiết kế thông thạo - Microsoft
• Trang web: https://fluent.microsoft.com/
• Thông thạo kết hợp các nguyên tắc của thiết kế nguyên tắc,
đổi mới công nghệ và nhu cầu của khách hàng. Đây là một
cách tiếp cận tập thể để tạo ra sự đơn giản và nhất quán
thông qua một hệ thống thiết kế mở, đa nền tảng.
 Ant Design
• Trang web: https://ant.design/index-cn
• Ant Design cung cấp các nguyên tắc thiết kế toàn diện, các
phương pháp hay nhất và các tệp tài nguyên thiết kế (Sketch
và Axure) để giúp các nhà thiết kế nhanh chóng thiết kế các
nguyên mẫu sản phẩm chất lượng cao.

http://hubt.edu.vn
  Các công cụ thiết kế giao diện người dùng
 Sketch: Sketch là một công cụ thiết kế dựa trên vector giúp bạn
thiết kế giao diện một cách nhanh chóng và trực quan.
 Figma: Figma là một công cụ tương đối mới với giao diện gần
giống như Sketch. Đó là một công cụ sáng tạo vì nó cho phép
một nhóm các nhà thiết kế cộng tác và đưa ra nhận xét về một
thiết kế trong thời gian thực.
 InVision Studio: Nó tuyên bố độc quyền là công cụ duy nhất có
thể “chinh phục” tất cả các quy trình thiết kế sản phẩm.
 Mockplus Cloud: Mockplus Cloud là một công cụ cộng tác thiết
kế sản phẩm mạnh mẽ dành cho các nhà thiết kế và nhà phát
triển. Nó tạo điều kiện thuận lợi cho việc xử lý bằng cách lấy các
thiết kế từ PS, Sketch và Adobe XD và xuất thành một định dạng
có thể tạo các đoạn mã, thông số kỹ thuật và nội dung.

http://hubt.edu.vn
  Framer: một công cụ thiết kế tương tác để tạo bố cục đáp ứng
và thiết kế các nguyên mẫu thực tế.
 Flinto: Flinto cho phép các nhà thiết kế tạo các nguyên mẫu
tương tác cho thiết bị di động, máy tính để bàn hoặc bất kỳ ứng
dụng web nào khác. Nó cũng cho phép người dùng tạo các
tương tác vi mô phức tạp trên đầu các lớp được xuất từ ​Sketch.
 Adobe XD: Adobe XD có hai tab: Design và Prototype. Tab Thiết
kế có các công cụ vectơ và văn bản đơn giản và được sử dụng
để tạo thiết kế của bạn. Tab Nguyên mẫu dùng để xem trước và
chia sẻ thiết kế của bạn.

http://hubt.edu.vn
 Sách thiết kế giao diện
 Don’t make me think – Steve Krug.
 UI is communication – Everett N.
 Designing with the Mind in Mind – Jeff
Johnson.
 Evil by Design – Chris Nodder.
 Simple and Usable Web, Mobile, and
Interaction Design – Giles Colborne.

http://hubt.edu.vn
 3.5 Tài liệu thiết kế

 1. Introduction: thông tin chung về tài liệu kiến ​

trúc, các tài liệu liên quan khác.
 2. System Purpose: mục đích, chức năng và đặc
điểm chất lượng của hệ thống từ quan điểm hộp
đen.
 2.1 Context: mô tả bối cảnh của hệ thống và vấn đề mà nó giải
quyết.
 2.2 System Interface: các dịch vụ do hệ thống cung cấp.
 2.3 Non-functional Requirements: nguyên tắc của kiến ​trúc, chất
lượng của dịch vụ, hạn chế bên ngoài

http://hubt.edu.vn
  3. Structure: cái nhìn logic về cấu trúc tĩnh của
kiến ​trúc xét về các thành phần của nó, kết nối
và các giao diện và hoạt động được cung cấp
bởi các thành phần.
 3.1 Overview: (các) sơ đồ kiến ​trúc cho cấu trúc tổng thể, bình
luận chứa cơ sở lý luận, phong cách kiến ​trúc, các ràng buộc
kiến ​trúc và các kiến ​trúc thay thế.
 3.2 Components. Cho từng thành phần: mô tả về thành phần về
trách nhiệm của nó, các giao diện mà nó cung cấp, các thành
phần cộng tác, khả năng tham số hóa và hạn chế.
 3.3 Interfaces. Cho mỗi giao diện thành phần: mô tả giao diện,
hoạt động của nó và ràng buộc về thứ tự hoạt động, đặc điểm
kỹ thuật tùy chọn của hoạt động.

http://hubt.edu.vn
  4. Dynamic Behavior: đặc tả hành vi hệ thống, sự hợp
tác của các thành phần để đạt đượchành vi hệ thống.
 4.1 Scenarios: (các) Sơ đồ kiến ​trúc. Cho mỗi tình huống: đặc
điểm kỹ thuật của kịch bản như hoạt động hệ thống hoặc đặc
điểm kỹ thuật ca sử dụng cho một số hoặc tất cả các dịch vụ
được cung cấp bởi hệ thống. Mô hình tương tác thành phần của
kịch bản.
 4.2 Mechanisms (optional): giải thích và mô hình tương tác cho
các cơ chế quan trọng.
 5. Other Views:
 5.1 Process View (optional): sơ đồ kiến ​trúc của các quá trình
hiển thị ánh xạ của các thành phần của quy trình.
 5.2 Development View (optional): ánh xạ các thành phần logic
thành các thành phần mã, cấu trúc của các thành phần mã.

http://hubt.edu.vn
  5.3 Physical View (optional): sơ đồ kiến ​trúc của cơ sở hạ tầng phần
cứng hiển thị ánh xạ các thành phần, quy trình và tệp mã tới các nút
phần cứng.
 5.x Additional Sections (optional): các phần dành cho các mô hình và
góc nhìn bổ sung không được chỉ địnhtrong mẫu này
 6. Conceptual Framework: định nghĩa về các khái niệm
và thuật ngữ cụ thể trong lĩnh vực vấn đề và chúngcác
mối quan hệ
 7. Conclusion: ưu điểm và hạn chế của kiến ​trúc đối với
các yêu cầu phi chức năng, vấn đề mở.

- The IEEE Draft Recommended Practice for Architectural Description.

- A Template for Documenting Software and Firmware Architectures,
Hewlett-Packard Product Gerneration Solution.

http://hubt.edu.vn
http://hubt.edu.vn