Kiến trúc và thiết kế phần mềm
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.47 MB, 221 trang )
Nguyễn Xuân Huy
Giáo trình
KIẾN TRÚC VÀ
THIẾT KẾ
PHẦN MỀM
Giáo trình giới thiệu khái niệm về kiến trúc của một hệ thống phần mềm, các qui
trình và phương pháp thiết kế kiến trúc hệ thống phần mềm. Sau khi tìm hiểu
giáo trình, học viên sẽ
Hiểu được vai trò quan trọng của thiết kế kiến trúc phần mềm;
Nắm được các bước tư duy và định hướng cần thiết khi quyết định đưa
một thành phần vào kiến trúc hệ thống trong quá trình thiết kế kiến trúc;
Nắm được tư tưởng về các mẫu kiến trúc và các phương thức tổ chức
kiến trúc hệ thống để có thể tái sử dụng trong thiết kế hệ thống;
Nắm được các mẫu kiến trúc quan trọng thường được vận dụng trong
các qui trình thiết kế khác nhau.
2
M Ụ C
L Ụ C
Lời nói đầu 5
Chương 1 Khái niệm chung 8
1.1 Tiếp cận hệ thống 8
1.2 Thiết kế kiến trúc 10
1.3 Quyết định kiến trúc 18
1.4 Các quan điểm trong kiển trúc phần mềm 28
1.5 Tóm tắt 31
Chương 2 Các mẫu kiến trúc 33
2.1 Khái niệm chung 33
2.2 Mẫu 34
2.2.1 Kiến trúc Mô hình, Quan sát và Điều khiển (Model View
Controller, MVC) 34
2.2.2 Kiến trúc Phân tầng (Layered Architecture, LA) 35
2.2.3 Kiến trúc Kho chứa (Repository Architecture, RA) 36
2.2.4 Kiến trúc Khách - Chủ (Client - Server, CS) 37
2.2.5 Kiến trúc Ống và Lọc (Pipe and Filter, PAF) 37
2.3 Các kiến trúc ứng dụng 38
2.4 Tóm tắt 39
Chương 3 Ngôn ngữ mô hình hóa 41
thống nhất UML 41
3.1 Lược sử UML 41
3.2 Khái quát về UML 42
3.3 Mô hình khái niệm của UML 45
3.3.1 Phần tử mô hình trong UML 46
3.3.2 Các quan hệ trong UML 50
3.3.3 Biểu đồ UML 53
3.4 Kiến trúc hệ thống trong UML 62
3.5 Rational Rose 66
3
3.6 Khả năng vận dụng UML 67
3.7 Tóm tắt 69
Chương 4 Phân tích yêu cầu 71
4.1 Phân tích yêu cầu 72
4.2 Phân tích viên 76
4.3 Lĩnh vực vấn đề 77
4.4 Kĩ thuật trao đổi 78
4.5 Nguyên lí phân tích 80
4.5.1 Miền thông tin 80
4.4.3 Mô hình hoá 82
4.6 Làm bản mẫu phần mềm 83
4.6.1 Kịch bản làm bản mẫu 84
4.6.2 Các phương pháp và công cụ làm bản mẫu 86
4.7 Đặc tả 88
4.7.1 Nguyên lí đặc tả 88
4.7.2 Biểu diễn 92
4.7.3 Đặc tả các yêu cầu phần mềm 93
4.8 Kiểm điểm đặc tả 95
4.9 Tóm tắt 98
Các chủ đề Hoạt động nhóm 99
TÀI LIỆU THAM KHẢO 183
Phụ lục 1 Các mô hình phát triển phần mềm 184
Phụ lục 2 Các khái niệm cơ bản của kĩ nghệ phần mềm 192
Phụ lục 3 Thuật ngữ 216
4
Lời nói đầu
Cùng với sự ra đời và phát triển của công nghệ thông tin, công nghệ phần
mềm đã được hình thành như một nguyên lí khoa học và phát triển ngày càng
mạnh mẽ. Có thể hiểu công nghệ phần mềm là lĩnh vực của công nghệ thông tin
nhằm nghiên cứu và đề xuất các nguyên lí, qui trình công nghệ, phương pháp, và
công cụ trợ giúp các quá trình thiết kế, cài đặt và bảo trì sản phẩm phần mềm đáp
ứng được các chỉ tiêu về chất lượng: tính đúng, tính khoa học, tính tin cậy, tính
vững vàng, tính dễ chuyển mang, tính dễ sử dụng, dễ phát triển và hoàn thiện.
Kiến trúc phần mềm chính là một nhánh của công nghệ phần mềm có nhiệm
vụ quyết định cấu hình hệ thống thông qua việc mô tả các cấu phần và các mối
liên quan giữa các cấu phần trong hệ thống phần mềm.
Khoảng những năm sáu mươi của thế kỉ 20 đã bùng nổ một cuộc tranh luận
về toán tử đầy nghi vấn – toán tử GOTO trong ngôn ngữ lập trình. Chính cuộc
tranh luận này đã làm nảy sinh các ý tưởng và nguyên lí đầu tiên về công nghệ
phần mềm. Điều thú vị là, ngay từ những ngày đầu sơ khởi và chập chững của
công nghệ phần mềm, các phương pháp hình thức đã ra đời và phát triển nhanh
chóng. Hàng loạt công trình nghiên cứu có ý nghĩa của các nhà tin học đầu đàn
như Dijkstra, Dahl, Hoare, Boëhm đã nâng kĩ thuật lập trình lên một tầm cao,
mang tính chặt chẽ và hoàn thiện, rất gần với các ngành khoa học chính xác [5].
Dahl và Dijkstra đã đề xuất nguyên lý lập trình theo đặc tả hình thức, Hoare xây
dựng hệ tiên đề chứng minh tính đúng của chương trình thông qua các phương
pháp toán học và suy luận logic, Boëhm và Dijkstra chứng minh tính đủ của hai
cấu trúc điều khiển tuần tự và lặp while, trên cơ sở đó đề xuất khái niệm D-cấu
trúc với lời khuyên lập trình viên chỉ nên sử dụng ba cấu trúc điều khiển một
cách trong sáng và tao nhã là cấu trúc tuần tự, cấu trúc rẽ nhánh và cấu trúc lặp
điều kiện trước [4].
Do nhu cầu thị trường, các hệ thống phần mềm phức tạp ngày càng tăng
trưởng. Cùng với nó, các nguyên lí và công cụ trợ giúp thiết kế và phát triển hệ
thống ngày càng gánh thêm trách nhiệm nặng nề và chuyên nghiệp. Nếu như
trước đây, lập trình viên thường đảm đương luôn nhiệm vụ của kiến trúc sư hệ
5
Lời nói đầu
____________________________________
thống thì ngày nay, việc đó là không thể, chưa nói đến khả năng không được
khuyến khích. Các khái niệm và công nghệ mới được hình thành và phát triển rất
đa dạng. Có thể nói, ngày nay, mỗi mô hình phát triển phần mềm quyết định một
vài qui trình sản xuất phần mềm. Đến lượt mình, mỗi qui trình sản xuất phần
mềm lại quyết định một vài loại hình kiến trúc hiệu quả tương ứng.
Giáo trình đặt ra hai mục tiêu cơ bản sau đây:
1. Giới thiệu khái quát các qui trình và phương pháp thiết kế kiến trúc hệ
thống phần mềm, đi sâu vào các phương pháp tiên tiến và có hiệu quả theo nghĩa
các phương pháp này đã được kiểm chứng trong thực tế;
2. Định hướng cho học viên một số kĩ năng trợ giúp tổ chức và chỉ đạo các
nhóm thiết kế kiến trúc phần mềm tại các cơ sở làm phần mềm.
Nội dung của giáo trình tương đương với một học phần khoảng 50 tiết.
Giáo trình được kiến trúc như sau:
Chương đầu tiên giới thiệu một số khái niệm cơ sở về lí thuyết hệ thống và
kiến trúc hệ thống phần mềm với giả định là bạn đọc đã biết ít nhiều về sản
phẩm phần mềm và các tiêu chí đánh giá một sản phẩm phần mềm, về mô hình
và các qui trình phát triển phần mềm.
Nội dung của chương 2 dành cho các thảo luận về các mẫu kiến trúc thông
dụng trong cộng đồng công nghệ phần mềm.
Chương 3 trình bày tóm lược về ngôn ngữ mô hình hóa thống nhất UML
hiện đang được dùng rộng rãi trong thiết kế phần mềm theo tiếp cận hướng đối
tượng.
Chương 4 giới thiệu các kĩ năng phân tích yêu cầu. Đây chính là pha đầu
tiên nhằm xác định mục đích, chức năng của một sản phẩm phần mềm.
Mới xem, bạn đọc dễ có cảm giác rằng lẽ ra chương này phải đặt trước các
chương khác trong giáo trình. Nếu xét về trình tự vận dụng thì đúng như vậy.
Không một kĩ sư phần mềm nào có thể viết ngay, dù chỉ là một dòng mã lệnh,
nếu như không biết rõ mục đích và các yêu cầu đặt ra cho phần mềm. Tuy nhiên,
như đã nói trong phần trên, khi bạn đọc đã biết rõ về các mô hình và các qui
trình xây dựng một hệ thống phần mềm thì việc trình bày có thể thực hiện theo
một logic mà người viết cho rằng phù hợp với kì vọng của bạn đọc.
Trước khi biên soạn giáo trình này, người viết đã tiếp thu được nhiều kiến
thức bổ ích cả về nội dung công nghệ phần mềm và phương pháp luận truyền thụ
từ giáo sư John Vũ, kĩ sư trưởng Công nghệ thông tin hãng Boeing, giáo sư kiêm
nhiệm tại Viện nghiên cứu phần mềm của Đại học Carnegie Mellon (CMU) và
6
Lời nói đầu
____________________________________
giáo sư Anthony Lattanze, CMU. Tiến sĩ John Kang, chủ nhiệm Khoa Quốc tế
CMU và thày Lê Công Cơ, Q. hiệu trưởng trường Đại học Duy Tân Đà Nẵng đã
cấp kinh phí và tạo nhiều điều kiện thuận lợi cho người viết được thăm và tham
gia các khoá đào tạo công nghệ phần mềm tại CMU. PGS TS Đoàn Văn Ban,
PGS TS Đặng Văn Đức, Nghiên cứu viên chính Ngô Trung Việt, Viện Công
nghệ thông tin, Viện Khoa học và Công nghệ Việt Nam, TS Hồ Cẩm Hà, trưởng
khoa Công nghệ thông tin Đại học Sư phạm Hà Nội thường xuyên trao đổi và
cung cấp thông tin cho người viết về các vấn đề đương đại của công nghệ phần
mềm.
Đặc biệt, PGS TS Đặng Văn Đức, tác giả của tài liệu Phân tích, thiết kế
hướng đối tượng bằng UML, nghiên cứu viên chính Ngô Trung Việt và TS
Nguyễn Kim Ánh, tác giả của tài liệu Nhập môn kĩ nghệ phần mềm đã cho phép
người viết được sử dụng các bản thảo nói trên để soạn giáo trình này.
Trong thời gian biên soạn giáo trình này, thạc sĩ Lê Thị Mỹ Hạnh, Khoa
Công nghệ thông tin trường Đại học Bách khoa, Đại học Đà Nẵng đã cung cấp
một số hình vẽ và những trợ giúp trong soạn thảo và trình bày văn bản.
Người viết chân thành cảm ơn những hỗ trợ quí báu và chân tình của các
thày và đồng nghiệp.
Người viết rất mong nhận được các ý kiến bình luận và đánh giá của bạn
đọc gửi về theo địa chỉ sau đây:
Nguyễn Xuân Huy,
Chủ tịch Hội đồng tư vấn Giáo dục Microsoft,
MB: 0903203800, E-mail:
Hà Nội, Mùa Ve,
năm Nhâm Thìn
N. X. Huy
7
Chương 1
Khái niệm chung
1.1 Tiếp cận hệ thống
Chúng ta quan niệm phần mềm là một hệ thống tức là bao gồm các thành
phần được gọi là các cấu phần và các mối liên hệ giữa các cấu phần đó. Từ quan
niệm này ta thấy để xác định được kiến trúc của một phần mềm ta cần chỉ rõ hai
nhóm đối tượng trong hệ thống đó là
Các cấu phần, hay các thành phần tạo nên hệ thống, và
Các mối liên hệ giữa các cấu phần.
Trong tài liệu này các thuật ngữ
Phần mềm,
hệ thống phần mềm,
hệ thống
được xem là tương đương.
Hình 1.1 Hệ thống
8
Chương 1 Khái niệm chung
_________________________________________
Thí dụ
Hệ thống phần mềm quản lí thư viện có thể bao gồm các cấu phần sau đây:
Cấu phần quản lí ấn phẩm;
Cấu phần quản lí tài liệu điện tử;
Cấu phần quản lí tài liệu vi phim;
Cấu phần quản lí tài liệu điện ảnh;
Cấu phần phục vụ bạn đọc;
Cấu phần quan hệ giao dịch với các thư viện bạn;
....
Các mối liên hệ giữa các cấu phần có thể là:
Cấu phần phục vụ bạn đọc - các cấu phần khác;
Cấu phần quan hệ giao dịch với các thư viện bạn - các cấu phần khác;
Cấu phần quản lí tài liệu vi phim - cấu phần quản lí tài liệu điện tử;
...
Cấu phần là thành phần cấu trúc nên hệ
thống.
Một cấu phần có chức năng tương đối
độc lập được gọi là hệ thống con của hệ
thống.
Thí dụ
Trong hệ thống quản lí thư viện nói trên ta có thể gọi các cấu phần đã liệt kê
là các hệ thống con.
Trong quá trình thiết kế kiến trúc, mỗi cấu phần có thể được phân rã thành
các cấu phần nhỏ hơn. Đến lượt mình, các cấu phần nhỏ này còn có thể được
phân rã tiếp thành các chi tiết, các đơn vị. Qui trình này được gọi là phân rã
9
Chương 1 Khái niệm chung
_________________________________________
hoặc làm mịn thiết kế hệ thống. Tiếp cận này được gọi là tiếp cận trên xuống, tức
là đi từ đại thể đến chi tiết, từ trừu tượng mức cao đến chi tiết.
Thí dụ
Cấu phần phục vụ bạn đọc có thể được chi tiết hoá thành các cấu phần con
như sau:
Hướng dẫn đăng nhập;
Hướng dẫn tìm kiếm;
Trợ giúp (bạn đọc);
Thống kê sở thích (bạn đọc);
Đòi tài liệu quá hạn;
...
Bài tập 1.1
1. Hãy liệt kê các công việc phải làm trong mục Đòi tài liệu quá hạn của thư
viện.
2. Từ kinh nghiệm tổ chức thư viện cá nhân của bạn, bạn hãy liệt kê các
công việc phải làm khi nhập sách mới vào thư viện.
3. Nếu trong thư viện do bạn phụ trách không có tài liệu bạn đọc yêu cầu.
Bạn sẽ làm gì? Hãy đặt mình vào vai người đọc để liệt kê kì vọng của người đọc
đối với hệ thống phục vụ của bạn. Sau đó, hãy cân nhắc xem khả năng tổ chức
của bạn có thể đáp ứng được nguyện vọng của bạn đọc đến mức nào.
1.2 Thiết kế kiến trúc
Thiết kế kiến trúc phần mềm là qui trình
xác định các cấu phần và các mối liên
hệ giữa các cấu phần trong hệ thống
phần mềm.
Thiết kế kiến trúc đòi hỏi sự thấu hiểu về hệ thống. Mục tiêu cuối cùng là
xây dựng một cấu trúc tổng thể cho hệ thống. Trong mô hình qui trình phát triển
phần mềm, thiết kế kiến trúc là pha đầu tiên của quá trình thiết kế phần mềm.
10
Chương 1 Khái niệm chung
_________________________________________
Có một mối liên hệ chặt chẽ giữa thiết kế và kĩ nghệ yêu cầu vì chúng cùng
chỉ rõ các cấu phần chính của hệ thống và các mối liên hệ giữa các cấu phần đó.
Đầu vào của thiết kế kiến trúc là các yêu cầu đối với hệ thống. Đầu ra của thiết
kế kiến trúc là mô hình kiến trúc phản ánh tổ chức của hệ thống như một tập các
cấu phần có liên hệ với nhau. Toàn bộ sản phẩm đầu ra tạo thành một bộ hồ sơ
thiết kế kiến trúc.
Theo tiếp cận linh lợi, thiết kế kiến trúc nhìn chung được thừa nhận là pha
sớm nhất của qui trình phát triển phần mềm. Nhiệm vụ chính của pha này theo
tiếp cận linh lợi chính là khởi tạo được một kiến trúc tổng thể của hệ thống phần
mềm.
Việc phát triển kiến trúc theo kiểu tăng trưởng nói chung là không hiệu quả.
Điều dễ hiểu là sửa đổi một cấu phần, một module hay một thủ tục trong hệ
thống là khá dễ, nhưng sửa đổi kiến trúc hệ thống trong quá trình phát triển sẽ
kéo theo nhiều phiền toái, nếu như có thể nói rằng là không thể.
Trong thực tế, có một phần giao nhau giữa hai quá trình: kĩ nghệ yêu cầu và
thiết kế kiến trúc. Về mặt lí tưởng, đặc tả hệ thống không nên chứa bất kì thông
tin kiến trúc nào của hệ thống, ngoại trừ các hệ thống nhỏ.
Kĩ nghệ yêu cầu bao gồm hai bước
chính:
Lấy yêu cầu;
Đặc tả yêu cầu.
Đầu ra: Bản đặc tả các yêu cầu đặt ra
cho hệ thống.
Phân rã kiến trúc hệ thống thường đòi hỏi sự phối hợp tinh tế giữa hai tiến
trình: viết đặc tả và thiết kế cấu trúc.
11
Chương 1 Khái niệm chung
_________________________________________
Viết đặc tả: chuyển các yêu cầu thường
là dưới dạng ngôn ngữ tự nhiên sang
dạng chặt chẽ, không nhập nhằng.
Thiết kế cấu trúc: xác định các cấu phần
và quan hệ giữa các cấu phần.
Do đó, như là một phần trong qui trình kĩ nghệ yêu cầu, ta cần tổ chức trước
hết, một kiến trúc trừu tượng (hiểu theo nghĩa bao quát), trong đó ta liên kết các
chức năng hoặc công cụ thành từng cấu phần hoặc hệ thống con. Sau đó ta có thể
dựa trên kiến trúc khởi thuỷ này để thảo luận với những người có thẩm quyền về
các yêu cầu và công cụ cho hệ thống.
Người có thẩm quyền (stakeholder):
Những người quyết định đến sự sống
còn của phần mềm: người làm phần
mềm, người sử dụng, người chi tài
chính, lãnh đạo bên A (bên đặt hàng),
lãnh đạo của chính xí nghiệp sản xuất
phần mềm đó.
Hai kĩ thuật quan trọng nhất thường được vận dụng trong thiết kế cấu trúc
là trừu tượng hoá và phân rã.
12
Chương 1 Khái niệm chung
_________________________________________
Trừu tượng hoá: Bỏ qua các chi tiết để
tập trung vào những yếu tố chung nhất,
quan trọng nhất.
Thí dụ, để thiết kế kiến trúc cho phần mềm quản lí học tập cho học sinh tiểu
học ta trừu tượng hoá theo phương pháp đi lên từ mức cụ thể như sau:
Mức 0 (mức cụ thể). Phần mềm quản lí học tập cho học sinh tiểu học;
Mức trừu tượng 1. Phần mềm quản lí học tập cho học sinh trung học cơ
sở (cấp 2);
Mức trừu tượng 2. Phần mềm quản lí học tập cho học sinh trung học
phổ thông (cấp 3);
Mức trừu tượng 3. Phần mềm quản lí học tập cho học sinh phổ thông;
Mức trừu tượng 4. Phần mềm quản lí học tập cho học viên nói chung;
Khi phân rã (làm mịn) kiến trúc ta không nên nhầm lẫn với thêm – bớt cấu
phần, cấu trúc hoặc sửa lại các mối liên kết... Tiêu chí cơ bản của phân rã là:
bước sau làm chi tiết hơn bước trước, trong khi vẫn bảo lưu khung của các bước
trước.
Phân rã: Chia một cấu phần thành các
cấu phần nhỏ hơn dựa theo chức năng,
thao tác hoặc tổ chức dữ liệu.
Ta có thể thiết kế kiến trúc phần mềm theo 2 cấp độ: nhỏ và lớn.
1. Kiến trúc nhỏ liên quan đến các kiến trúc của chương trình máy tính riêng
biệt. Tại mức này ta quan tâm phân rã một chương trình cụ thể thành các
thành phần.
13
Chương 1 Khái niệm chung
_________________________________________
2. Kiến trúc lớn liên quan đến các hệ thống phức hợp chứa các hệ thống
khác, các chương trình và các cấu phần của chương trình. Các hệ thống
này phân tán trên nhiều máy tính được nhiều đơn vị khác nhau quản lí.
Bài tập 1.2
1. Hãy liệt kê các chức năng chủ yếu của hệ thống phần mềm quản lí học
tập trong nhà trường phổ thông. Bạn cố gắng xếp các chức năng này thành các
nhóm.
2. Bạn hãy thử liệt kê những sự khác biệt giữa phần mềm quản lí học tập
trong trường tiểu học và trường cấp ba.
3. Bạn hãy thử liệt kê những sự khác biệt giữa phần mềm quản lí học tập
trong trường phổ thông và trường đại học.
Kiến trúc phần mềm là quan trọng vì nó phản ánh tính hiệu quả, tính tin cậy,
tính khả chuyển của hệ thống [8]. Mỗi cấu phần thể hiện một yêu cầu chức năng
của hệ thống. Các yêu cầu phi chức năng phụ thuộc vào kiến trúc hệ thống – tức
là phương thức tổ chức và phương thức vận dụng, khai thác cấu phần đó. Trong
nhiều hệ thống, các yêu cầu phi chức năng cũng được chi phối bởi các cấu phần
riêng, nhưng điều đó không có nghĩa là kiến trúc của hệ thống gây ảnh hưởng
quyết định.
Tiếp cận hướng chức năng trong thiết kế kiến trúc phần mềm:
Gộp hoặc / và phân rã hệ thống theo chức năng.
Yêu cầu chức năng là yêu cầu mà hệ thống có thể thực hiện tự
động theo một thủ tục định trước.
Thí dụ: nhập liệu, nhập xuất kho, kết toán.
Yêu cầu phi chức năng là yêu cầu đòi hỏi người điều hành hệ
thống khai thác thông tin trong hệ thống trước khi ra quyết
định.
Thí dụ: ra quyết định về thu, chi, tăng/giảm một mặt hàng.
Bass và các đồng sự [8, 9] liệt kê ba lợi ích của một bản thiết kế hệ thống
chuẩn mực:
14
Chương 1 Khái niệm chung
_________________________________________
1. Trợ giúp cho việc liên hệ với những người có thẩm quyền. Kiến trúc là
biểu diễn mức cao của hệ thống nhờ đó chúng ta có thể trao đổi, bàn luận với
những người có thẩm quyền thuộc các cấp khác nhau.
2. Trợ giúp phân tích hệ thống. Ta có thể chính xác hóa kiến trúc hệ thống ở
các pha sớm trong qui trình phát triển hệ thống. Các quyết định về kiến trúc hệ
thống có thể tiên lượng được một số sự cố bất lợi ảnh hưởng đến hiệu năng, tính
tin cậy và tính bảo trì.
3. Cho phép tái sử dụng ở mức rộng. Một mô hình kiến trúc hệ thống là một
bản mô tả các cấu trúc với các cấu phần và các tương tác giữa các cấu phần đó.
Trong thực tế ta thường gặp các hệ thống có kiến trúc tương tự do đó ta có thể
tận dụng khả năng tái sử dụng phần mềm. Trong nhiều trường hợp ta có thể vận
dụng lại các kiến trúc hệ thống để phát triển cả một dòng sản phẩm.
Thí dụ
Các hệ thống phần mềm sau đây đều có chung một kiến trúc:
Các hệ điều hành trên máy tính cá nhân.
Các máy điện thọai di động.
Các hệ thống quản lí bán hàng.
Các hệ thống quản lí học tập
...
Bài tập 1.3
1. Hãy phác thảo vài nhóm chức năng trong sơ đồ của hệ thống phần mềm
trong máy điện thoại di động của bạn.
2. Theo ý bạn, chức năng nào của máy điện thoại di động của bạn là tốt
nhất, chức năng nào chưa hoàn thiện. Bạn kì vọng ở nó ra sao?
Nhờ phân loại các hệ thống phần mềm có chung kiến trúc ta có thể tái sử
dụng phần mềm hoặc chí ít là tổ chức được kiến trúc hệ thống cho các ứng dụng
trong cùng một dòng sản phẩm và do đó, tiết kiệm được chi phí, giảm được giá
thành sản phẩm.
Thí dụ
Sau khi hoàn thành dự án phần mềm quản lí học tập tại một trường trung
học cơ sở cụ thể, trường Lương Thế Vinh chẳng hạn, ta có thể tái sử dụng phần
mềm này cho cho các trường trung học cơ sở khác, thậm chí, với một vài thay
15
Chương 1 Khái niệm chung
_________________________________________
đổi nhỏ, ta có thể tái sử dụng phần mềm này cho các trường trung học phổ thông
hoặc/và trung học chuyên nghiệp.
Hofmeister và các cộng sự [3, 6, 8] cho rằng kiến trúc phần mềm có thể
phục vụ trước hết như là một bản hoạch định yêu cầu hệ thống, thứ đến có thể
làm nền cho các buổi thảo luận giữa khách hàng, nhà phát triển hệ thống và các
nhà quản trị dự án. Nó che giấu các chi tiết thường làm rối thêm vấn đề trong các
cuộc bàn thảo và do đó và cho phép nhà kiến trúc tập trung vào các mức trừu
tượng căn bản của hệ thống.
Thí dụ
Khi bàn về kiến trúc cho một hệ thống phần mềm quản lí học tập trong nhà
trường thì những chi tiết sau đây cần được che khuất đi tại pha đầu tiên - pha xây
dựng kiến trúc ở mức trừu tượng:
Giáo viên nạp điểm ra sao? Theo công thức nào, có trọng số hay không
có trọng số?
Danh sách học sinh được hiển thị theo chiều ngang hay dọc, có được sắp
không? Sắp tăng hay giảm, sắp theo tiêu chí nào: theo tên hay theo
điểm?
...
Kiến trúc hệ thống thường được mô tả dưới dạng các sơ đồ khối đơn giản.
Mỗi khối trong sơ đồ biểu diễn một cấu phần hoặc một hệ thống con. Một khối
con A1 trong khối A khác thể hiện một cấu phần con, tức là thể hiện một thành
phần A1 nhận được do A được phân rã (làm mịn) tiếp.
16
Chương 1 Khái niệm chung
_________________________________________
M1
A
M2
M5
M3
M6
M4
M7
B
Tính
C
M8
Hình 1.2 Các sơ đồ kiến trúc
Các cung có hướng mang ý nghĩa là dữ liệu hoặc các tín hiệu điều khiển
xuất phát từ một cấu phần đi tới một cấu phần khác.
Các sơ đồ khối biểu diễn một bức tranh mức cao của cấu trúc hệ thống, do
đó các thành viên trong nhóm phát triển và những người quan tâm có thể quan
sát và hiểu một cách trực quan.
Chúng ta cần quan tâm cả hai phương thức tiếp cận hệ thống như sau:
1.
Ở mức cao, như ta thấy, sơ đồ kiến trúc tổng thể tạo ra một khung nhìn
đơn giản và thuận lợi để những người có thẩm quyền có thể bàn bạc. Họ
sẽ không bị vướng vào các chi tiết quá vụn vặt ….
2.
Sản phẩm cuối của kiến trúc hệ thống là bộ hồ sơ mô tả một mô hình
đầy đủ của hệ thống, trong đó thể hiện rõ các cấu phần, các giao diện và
các mối liên hệ giữa các cấu phần. Các thông tin chi tiết này phải được
đưa vào hồ sơ.
17
Chương 1 Khái niệm chung
_________________________________________
Chuyển tiền
Thay đổi
PIN
Gửi tiền
Nhân viên
ngân hàng
Khách hàng
Rút tiền
Thanh toán
Hệ thống tín
Xem số dư
Hình 1.3 Kiến trúc của hệ thống ATM
Sơ đồ khối là phương tiện hữu ích để mô tả kiến trúc hệ
thống trong quá trình thiết kế cũng như hỗ trợ trao đổi với
những người có thẩm quyền.
Kiến trúc sư hệ thống cần có kĩ năng sử dụng các thành
thạo các công cụ và phương thức tốt để có thể mô tả chuẩn
mực, có ngữ nghĩa kiến trúc hệ thống.
1.3 Quyết định kiến trúc
Thiết kế kiến trúc là một qúa trình sáng tạo trong đó bạn thiết kế cơ cấu cho
một hệ thống đáp ứng được các yêu cầu chức năng và phi chức năng của hệ
thống.
Các hoạt động diễn ra trong hệ thống phụ thuộc vào đặc thù của hệ thống
mà ta phát triển, phụ thuộc vào kiến thức nền và kinh nghiệm của kiến trúc sư.
Do đó sẽ là tốt nếu ta tư duy về kiến trúc hệ thống như là một chuỗi các quyết
định cần thực hiện hơn là như một dãy hoạt động cần hoàn thành. Trong quá
18
Chương 1 Khái niệm chung
_________________________________________
trình thiết kế kiến trúc, các kiến trúc sư thường đối mặt với hàng loạt quyết định
cấu trúc ảnh hưởng đến hệ thống và quá trình phát triển hệ thống. Dựa trên kiến
thức và kinh nghiệm của mình các kiến trúc sư hệ thống cần xem xét các vấn đề
sống còn sau đây:
1.
Ta có thể xuất phát từ một hình mẫu có sẵn?
2.
Có thể phân rã hệ thống thành một số qui trình hoặc hạt nhân quen
thuộc?
3.
Có thể tái sử dụng các mẫu hoặc kiểu loại?
4.
Tiếp cận nào là cơ bản?
5.
Cấu phần nào cần làm mịn tiếp theo?
6.
Chiến lược nào sẽ được sử dụng để điều khiển các thao tác trên các cấu
phần hệ thống?
7.
Tổ chức kiến trúc nào là tốt nhất cho các yêu cầu phi chức năng?
8.
Đánh giá bản thiết kế kiến trúc ra sao?
9.
Lập hồ sơ kiến trúc ra sao?
Bạn đọc hãy dành ít phút quan sát bảng liệt kê này trước khi chuyển qua
mục khác. Trước hết ta thấy rằng đây là các quyết định chứ không phải là hoạt
động. Quyết định thường được kết thúc bằng các nhóm từ: có thể; ra sao; lựa
chọn cái gì là tốt nhất…
Có thể xây dựng quyết định bằng một câu hỏi chung
như sau:
Ta phải quyết định chọn/làm/tổ chức/tạo ra/xây dựng
cái gì?
Những dẫn dắt sau đây thuộc về hoạt động:
- Ta đặt thực đơn A tại chỗ này, trên thực đơn B.
- Ta nên đặt màu nền cho tươi hơn.
- Ta sẽ sửa lại chức năng này…
19
Chương 1 Khái niệm chung
_________________________________________
Mỗi hệ thống phần mềm thường là duy nhất đối với một ứng dụng cụ thể
nên các hệ thống thuộc cùng một lĩnh vực ứng dụng thường có cùng một kiến
trúc thể hiện các quan niệm cơ bản của lĩnh vực ứng dụng đó.
Thí dụ các ứng dụng của một dòng sản phẩm nào đó được thiết kế trên cơ
sở ứng dụng hạt nhân ban đầu với một số biến thể nhỏ nhằm đáp ứng các yêu
cầu nâng cao của người sử dụng. Sau khi khảo sát và phân tích các hạt nhân ban
đầu, ta chọn ra một vài hạt nhân có kiến trúc và chức năng gần nhất với hệ thống
cần thiết kế. Ta tiếp tục liệt kê các cấu phần và chức năng của các hạt nhân này
trong một bảng kiểm mục, trong đó ghi chú rõ chức năng nào là phù hợp, chức
năng nào cần loại bỏ, chức năng nào có thể được chỉnh sửa lại để tái sử dụng...
Việc này có thể được lặp lại nhiều lần cho đến khi nhận được một phiên bản mới
về nguyên tắc và phù hợp với các yêu cầu cơ bản của hệ thống ta đang cần thiết
kế.
Thí dụ
1. Bạn cần thiết kế một hệ thống phần mềm (nhúng) cho một dòng điện
thoại di động mới M có màn hình cảm ứng thuộc hãng X.
Sau khi xác định được các yêu cầu cho hệ thống M, bạn có thể tìm hiểu các
phiên bản điện thoại di động có màn hình cảm ứng mới nhất trước đó, chẳng hạn
bạn chọn được hai sản phẩm là L và T của chính hãng X.
Bạn cần xác định cái gì là chung, là kế thừa, cái gì là mới, … các ưu và
nhược điểm của từng chức năng đó;
Tiếp đến bạn quyết định xem có thể tái sử dụng các cấu phần nào từ L và T;
...
2. So với các phần mềm cho máy tính cá nhân thì phần mềm nhúng chỉ sử
dụng một bộ xử lí do đó không cần đến khái niệm phân tán. Tuy nhiên nhiều hệ
thống lớn hiện nay lại là phân tán trên nhiều máy nên việc quyết định lựa chọn
một kiến trúc phân tán cho các thiết bị di động là khôn ngoan vì nó đáp ứng được
hiệu năng và độ tin cậy trong giao dịch, trong tương tác.
3. Khi cần thiết kế kiến trúc cho một hệ thống phân tán ta có thể khảo sát và
lựa chọn các mẫu kiến trúc và topo mạng máy tính: kiến trúc hình sao, kiến trúc
vòng, client-server, …
Để lựa chọn một cấu phần đưa vào hệ thống hoặc phân rã một thành phần
hoặc một cấu phần của hệ thống, kiến trúc sư hệ thống cần được trang bị các
kiến thức và chiến lược trong lý thuyết hệ thống.
20
Chương 1 Khái niệm chung
_________________________________________
Phần mềm nhúng: phần mềm cài trong các thiết bị, chủ yếu là các thiết bị
điều khiển, thiết bị di động chuyên dụng.
Đặc điểm chung:
Không cài đặt cho các máy tính lớn và máy tính cá nhân (nhưng
thường được thiết kế và sản xuất trên các máy tính có môi trường mô
phỏng thiết bị);
Thường dùng một bộ xử lí;
Nhỏ gọn;
Được nhúng (ghi dưới dạng mã máy, mã đích) trong các vi mạch điện
tử;
Hiện đang có nhu cầu thị trường rất lớn.
Dưới đây là một minh hoạ gồm các phân tích ngắn gọn một số tiêu chí
mang tính chỉ đạo cho việc xây dựng kiến trúc cho một hệ phân tán:
1. Hiệu năng là đòi hỏi quan trọng nhất. Kiến trúc được xây dựng để phục
vụ cho các thao tác địa phương trong một nhóm nhỏ các cấu phần sẽ thực thi
trên một máy tính (địa phương) chứ không thực thi trên mạng. Do đó bạn cần lưu
ý đến nguyên tắc: hạn chế liên kết vì liên kết đòi hỏi thêm chi phí xử lí đồng bộ
hoá và tổ chức thời gian thực…
Hiệu năng của hệ thống: thể hiện mức độ hiệu quả
và khả năng phục vụ của hệ thống, thí dụ tốc độ xử
lí hay số đơn vị dữ liệu được xử lí trong một đơn vị
thời gian.
2. Tính bảo mật. Gần như mọi hệ thống phân tán đều đòi hỏi cơ chế bảo
mật. Vậy là bạn phải chọn một kiến trúc theo lớp, phân tầng để có thể tổ chức
được các thủ tục và qui trình bảo mật cho hệ thống;
21
Chương 1 Khái niệm chung
_________________________________________
3. An toàn và toàn vẹn. Các thao tác liên quan đến tính an toàn (và toàn
ven) được gói vào một cấu phần hoặc một nhóm nhỏ các cấu phần. Tổ chức kiểu
này sẽ làm giảm chi phí săn sóc , theo dõi và bảo vệ cho hệ thống và dữ liệu
được an toàn và toàn vẹn. Thí dụ, trong các hệ thống thường có chế độ thực hiện
sao lưu tự động và các cơ chế cảnh báo trước khi người sử dụng định thực hiện
các thao tác có thể vi phạm tính toàn vẹn như xoá (delete) dữ liệu, chuyển dịch
(move) dữ liệu, huỷ bỏ (cancel, stop), tái khởi động (reset, uninstall) hệ thống
hoặc tiến trình, chuyển đổi hoặc tạo lại (format) khuôn dạng thiết bị...
Tính an toàn và toàn vẹn: dữ liệu và chương trình không bị
biến dạng, sai lệch sau các thao tác của người sử dụng. Có cơ
chế ngăn chặn, cảnh báo và khôi phục lại hệ thống và dữ liệu
sau các sự cố như mất điện, treo máy hoặc các thao tác vô tình
hoặc cố ý làm sai lệch dữ liệu và hệ thống.
4. Sẵn sàng: Để đảm bảo tính sẵn sàng, hệ thống của bạn nên có thêm các
cấu phần dư thừa để thay thế khi cần. Ngoài ra, hệ thống của bạn nên có cơ chế
sao lưu hoặc tổ chức bộ nhớ cache để khi cần có thể làm việc trong chế độ gián
tuyến (offline)
Tính sẵn sàng của hệ thống: hệ thống có khả năng
phục vụ trong nhiều trạng thái và ngữ cảnh. Thí dụ, khi
một phần của mạng bị hỏng hệ thống vẫn làm việc với
phần còn lại của mạng và sau đó, khi sự cố đã được khắc
phục, hệ thống có thể cập nhật lại các cấu hình, trạng thái
và dữ liệu cho các điểm mạng thuộc phạm vi quản lí của
mình.
5. Khả năng duy tu: Nếu có yêu cầu bắt buộc về khả năng duy tu hệ thống,
bạn nên quan tâm đến những thành phần hạt nhân đủ nhỏ và độc lập có khả năng
tổ hợp cao nhằm đáp ứng được những yêu cầu mới. Bạn cũng nên tách hai cơ
22
Chương 1 Khái niệm chung
_________________________________________
chế phát sinh / lưu trữ dữ liệu (thuộc về người quản trị hệ thống) và khai thác dữ
liệu (dành cho người sử dụng hệ thống).
Online: hoạt động trực tuyến. Khách và chủ giao lưu trực
tiếp theo thời gian thực. Thí dụ, từ máy tính của mình bạn đang
nhập vào một hệ thống dịch vụ nào đó, bán hàng trên mạng chẳng
hạn, và làm việc, trao đổi với hệ thống đó.
Off-line: hoạt động gián tuyến. Khách làm việc trong chế độ
không kết nối với chủ.Thí dụ, sau khi lấy được thông tin về một
số mặt hàng cần mua, bạn tạm ngắt kết nối với hệ thống bán hàng
trên mạng để suy nghĩ, trao đổi với mọi người và điền các thông
tin vào các file mẫu.
Hệ thống có khả năng duy tu là hệ thống được thiết kế để
khi cần thiết có thể nâng cấp hoặc có đủ cơ chế linh hoạt để đáp
ứng được các yêu cầu mới, khó dự đoán trước.
Thí dụ, khi xây dựng hệ thống làm việc trên mạng thế hệ 2
ta nên nghĩ ngay đến khả năng sau này hệ thống sẽ được nâng
cấp để có thể làm việc trên mạng thế hệ 3.
Thành phần hạt nhân: thành phần cơ sở của hệ thống,
làm nền, làm hạ tầng để từ đó xây dựng toàn bộ hệ thống.
Thí dụ, hạt nhân của hệ điều hành thực thi các chức năng cơ
bản của hệ điều hành ở mức thấp, giao diện đơn giản.
Dĩ nhiên là có một số tiêu chí có thể đối kháng nhau trong các kiến trúc
trên. Thí dụ, các cấu phần lớn được trang bị cơ chế tối ưu hoá thường trợ giúp
23
Chương 1 Khái niệm chung
_________________________________________
tính hiệu quả, ngược lại, các cấu phần cơ sở và nhỏ thường dễ duy tu. Nếu hai
yêu cầu về tính hiệu quả và tính duy tu đều phải được coi trọng thì kiến trúc sư
hệ thống cần phải theo đuổi một chính sách dung hoà. Điều này cắt nghĩa lí do vì
sao kiến trúc sư hệ thống thường sử dụng vài loại hình mẫu khác nhau cho các hệ
thống khác nhau.
Thành phần độc lập (thành phần dễ chuyển mang):
một module (đơn thể) chương trình có thể chuyển từ hệ
thống này sang hệ thống khác. Module đó có thể hoạt động
trong nhiều chủng loại máy tính và môi trường khác nhau.
Thí dụ, lớp các thủ tục vào/ra, lớp các hàm toán học,
lớp đồ hoạ được thiết kế để dùng chung cho nhiều ngôn ngữ
và môi trường lập trình.
Hình mẫu: Một kiến trúc có thể dùng chung cho
một lớp các hệ thống.
Thí dụ: Kiến trúc hệ điều hành, kiến trúc giao diện
đồ hoạ, kiến trúc xử lí giao dịch.
Để kết luận cho mục này chúng ta trao đổi thêm ba kinh nghiệm quan trọng
sau đây:
1. Có thể thực hiện kiểm định logic cho phác thảo kiến trúc ban đầu.
24
Chương 1 Khái niệm chung
_________________________________________
Kiểm định hệ thống là hoạt động xác định:
hệ thống có đáp ứng đầy đủ và chính xác các
yêu cầu đã đề ra?
hệ thống có hoạt động đúng như ta mong
muốn không?
Kiểm định logic quan tâm chủ yếu đến tính
hợp lí, phi mâu thuẫn trong cấu trúc và hoạt động
của hệ thống.
Kiến trúc ban đầu thường rất đơn giản, nhưng không vì thế mà bạn có thể
bỏ qua việc kiểm tra. Lý do là như sau:
NGUYÊN LÍ LỖI NẶNG
Lỗi nặng nhất thường sinh ra tại các pha ban
đầu.
Thí dụ
Ta phân tích một thí dụ đơn giản.
Giả sử ta cần xây dựng một hệ thống dịch vụ đa năng trên mạng.
Thiết kế ban đầu của ta được biểu diễn dưới dạng một sơ đồ khối đơn giản
gồm có bốn khối thể hiện trình tự đón khách và phục vụ theo 4 bước như sau:
Đăng nhập
Điền
Thu
thông phí
tin
Giới thiệu
chung
Lựa chọn
dịch vụ
Phục
vụ
Hình 1.4 Một kiến trúc hệ thống yếu kém
25
