Kiến trúc và thiết kế 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

Nguyễn Xuân Huy

Giáo trình

K I Ế N T R Ú C V À

T H I Ế T K Ế

P H Ầ 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

M Ụ C L Ụ C

Lời nói đầu 5

Chương 1 Khái niệm chung 8

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

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

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à hồ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ề tốn tử đầy nghi vấn – tố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à hồ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 tố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ệ

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

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à

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: nxhuy564@gmail.com

Hà Nội, Mùa Ve, năm Nhâm Thìn

N X Huy

Chương 1 Khái niệm chung

 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ữ

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 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ử;

là đi từ đại thể đến chi tiết, từ trừu tượng mức cao đến chi tiết

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

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ơ

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;

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ã

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

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:

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

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

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

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ơ

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á

Chuyển tiền

Gửi tiền

Rút tiền

Xem số dư Khách hàng

Nhân viên ngân hàng Thay đổi

PIN

Thanh toán Hệ thống tín

Hình 1.3 Kiến trúc của hệ thống ATM

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…

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

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

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;

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ơ

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

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

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:

N G U Y Ê N L Í L Ỗ I N Ặ N G

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:

Bước 1 Khách đăng nhập hệ thống: Điền trực tuyến (online) theo mẫu sau

Điều bất tiện ở kiến trúc này là gì?

Hãy tưởng tượng, một vị khách mới, chưa hề biết gì về công ti dịch vụ này

Vị khách muốn xem thông tin giới thiệu công ti Nhu cầu này chỉ được đáp ứng sau khi khách đã đăng nhập vào hệ thống Mà việc đang nhập này đòi hỏi phải trả phí

Dĩ nhiên, khi trao đổi với những người có thẩm quyền ta có thể phát hiện ra một số điểm bất hợp lí dựa trên các gợi ý về mặt nguyên tắc như sau:

 Danh có chính, ngôn mới thuận: Việc tiên quyết là giới thiệu về công ti

 Sử dụng dịch vụ nào thì trả phí riêng cho dịch vụ đó

Như vậy là phải tách cấu phần đầu tiên thành hai cấu phần riêng biệt, độc lập nhau là đăng nhập và thu phí Cấu phần thu phí sẽ được đặt sau cấu phần phục vụ

Nếu kiến trúc sư hệ thống chịu khó khảo sát các mẫu thông dụng trên thị trường thì có thể đề xuất được ngay một kiến trúc khá hợp lệ như sau:

Kiến trúc này có thêm pha dùng thử Tuỳ theo mục đích cung ứng, nhà cung ứng có thể giới hạn thời gian hoặc / và chức năng được dùng thử

2 Sau mỗi bước phân rã, làm mịn kiến trúc hệ thống rất nên thực hiện kiểm

định Nhận định này được trình bày chi tiết trong giáo trình "Kiểm định phần mềm"

3 Đánh giá kiến trúc là việc khó, đặc biệt là đối với các yêu cầu phi chức năng vì hệ thống chưa thực thi, mới nằm trên giấy Thí dụ minh hoạ nói trên chỉ liên quan đến các yêu cầu về chức năng Từ nhận định này ta thấy việc trao đổi thường xuyên các phương án kiến trúc với những người có thẩm quyền là rất quan trọng Ngoài ra, để giảm nhẹ gánh nặng và áp lực, kiến trúc sư hệ thống nên khảo sát và đánh giá các hệ thống và các mẫu hiện hành

Đăng kí Điền thông tin

Giới thiệu

chung

Lựa chọn dịch vụ

Lựa chọn dịch vụ

Phục

vụ

N G U Y Ê N L Í Ả N H H Ư Ở N G

Nhiều kiến trúc sư hệ thống mới vào nghề thường quan niệm rằng tham khảo nhiều mẫu và nhiều hệ thống dễ bị ảnh hưởng, dễ gây thói quen bắt chước, làm nhái

Muốn sáng tạo thì phải có vốn, phải học Xem nhiều, đọc nhiều với một đầu óc biết phân tích và phê phán sẽ giúp ta sáng tạo ra những sản phẩm độc đáo

1.4 Các quan điểm trong kiển trúc phần mềm

Nhắc lại rằng các mô hình kiến trúc của một hệ thống phần mềm rất cần và

có thể được sử dụng để thảo luận về các yêu cầu giữa nhóm thiết kế, phát triển phần mềm và những người có thẩm quyền Hơn nữa, các mô hình này còn có thể được sử dụng để lập hồ sơ kiến trúc trong các bước làm mịn sau này

Trong mục này chúng ta sẽ thảo luận hai vấn đề quan trọng sau đây:

1 Khi thiết kế và lập hồ sơ cho kiến trúc hệ thống ta vận dụng các quan điểm nào và dự đoán viễn cảnh của hệ thống ra sao?

2 Khái niệm nào cần thiết cho mô tả kiến trúc hệ thống?

Không thể biểu diễn mọi thông tin về kiến trúc hệ thống với một tập các mô hình đơn giản và tổng qúat lúc đầu, vì mỗi mô hình chỉ phản ánh một quan điểm

và một viễn cảnh của hệ thống Chẳng hạn, nó chỉ có thể cho biết rằng hệ thống

sẽ được làm mịn, phân rã thành các đơn thể nào, cũng như các tiến trình thời gian thực sẽ tương tác với nhau ra sao hoặc vận dụng các phương thức nào để phân bố các cấu phần của hệ thống đối với mô hình phân tán

Chúng ta luôn luôn cần cả một lớp các quan điểm cho các bước tiếp theo Krutchen (1995), đề xuất mô hình (4+1) quan điểm cho kiến trúc phần mềm Đó là:

1 Quan điểm logic Quan điểm này giúp chúng ta thể hiện các đối tượng và

lớp trừu tượng cơ bản trong hệ thống, thể hiện các yêu cầu về thực thể dưới dạng các quan niệm logic

2 Quan điểm tiến trình Vào thời điểm hệ thống hoạt động ta phải hình

dung rõ các qui trình tương tác của hệ thống Khi tuân thủ quan điểm tiến trình, điều quan trọng là phải hiểu được các yêu cầu phi chức năng như tính hiệu năng hoặc tính hữu dụng

3 Quan điểm phát triển Theo quan điểm phát triển, ta giải thích được hệ

thống sẽ được phân rã ra sao trong quá trình phát triển Quan điểm phát triển là hữu ích đối với các nhân viên quản trị và lập trình viên

phần mềm tương ứng trong hệ thống Quan điểm này rất quen thuộc đối với các

kĩ sư hệ thống

Hofmeister và các cộng sự [6] bổ sung thêm

Khung quan điểm hay khung nhìn chính là khung trừu tượng làm cơ sở cho quá trình phân rã các yêu cầu mức cao thành các đặc tả chi tiết giúp cho các nhân viên quyết định chọn các cấu phần dùng lại và thể hiện các dòng sản phẩm

Trong thực tiễn, khung nhìn được sử dụng với tần suất cao Nó cũng là cơ

sở để trao đổi giữa nhóm phát triển phần mềm và những người có thẩm quyền Thí dụ, Có nhiều quan điểm khác nhau về khả năng sử dụng UML và các môi trường đặc tả khác nhau trong thiết kế kiến trúc [9]

Nếu ta tiếp cận theo hướng đối tượng thì nên sử dụng UML Ngoài ra ta có thể sử dụng các công cụ khác như các ngôn ngữ mô tả chuyên dụng (Specialized Architectural Description Languages, ADLs, [8]) với các phần tử cơ sở là các thành phần và các đường nối

U M L

UML (Unified Modeling Language  Ngôn ngữ

mô hình hóa thống nhất) do Booch, Rumbaugh và Jacobson đề xuất dùng để đặc tả kiến trúc hệ thống

theo tiếp cận mô hình hoá và hướng đối tượng

Các công cụ trực quan chủ yếu là các biểu đồ:

biểu đồ lớp, biểu đồ trình tự, biểu đồ trạng thái, biểu đồ cộng tác, biểu đồ cấu trúc (thành phần), biểu đồ triển khai

Bài tập 1.4

1 Hiện nay các thiết bị điện tử được tích hợp rất nhiều tiện ích Bạn thử liệt

kê một số chức năng mà bạn muốn tích hợp vào chiếc điện thoại di động của bạn Với mỗi chức năng bạn hãy gán một trị số từ 1 đến 10 nhằm xác định ý kiến của bạn về mức độ cần thiết của chức năng đó: mức 10 là rất cần thiết

2 Bill Gate đã xây dựng cho mình một ngôi nhà thông minh, trong đó mọi dịch vụ trong sinh hoạt gia đình được tự động hóa tối đa thông qua hệ thống các

phần mềm Bạn hãy thử mô tả ước muốn của bạn về một ngôi nhà thông minh theo gợi ý sau:

Hai kĩ thuật quan trọng nhất thường được vận dụng trong thiết kế là:

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

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

Ba lợi ích của một bản thiết kế hệ thống chuẩn mực:

1 Trợ giúp cho việc liên hệ với những người có thẩm quyền

2 Trợ giúp phân tích hệ thống

3 Cho phép tái sử dụng ở mức rộng

Kiến trúc hệ thống cần được mô tả dưới dạng các sơ đồ khối

Các quan điểm chỉ đạo trong thiết kế kiến trúc:

1 Quan điểm logic

2 Quan điểm tiến trình

3 Quan điểm phát triển

4 Quan điểm vật lí

Chương 2 Các mẫu kiến trúc

2.1 Khái niệm chung

Các mẫu kiến trúc được sử dụng với mục đích chia sẻ và tái sử dụng các tri thức của cộng đồng công nghệ phần mềm

Ta hiểu mẫu là những sản phẩm làm sẵn dùng để dựa vào đó sản xuất ra

những sản phẩm cùng loại Giả sử bạn cần thiết kế một kiến trúc cho một ngôi nhà Bạn tìm trong thực tế hoặc trên mạng Internet một vài bản kiến trúc có sẵn

mà bạn cho là phù hợp nhất với kiến trúc dự kiến của ngôi nhà của bạn Các bản

kiến trúc này được gọi là các bản kiến trúc mẫu Sau đó bạn dựa trên những bản

kiến trúc mẫu này để thiết kế kiến trúc cho ngôi nhà của bạn Giả sử bản kiến

trúc bạn ưng ý nhất và bạn đã chọn là K

Nếu bạn đã giao tiếp với chủ nhà K và được chủ nhà cung cấp rõ ràng các

thông tin về ngôi nhà: những điểm mạnh, điểm yếu, điểm chưa hoàn thiện… thì chắc chắn là bạn rất biết ơn chủ nhà về điều đó Các thông tin quí giá này giúp

cho bạn hoàn thiện nhanh chóng việc sửa đổi kiến trúc K cho ngôi nhà của bạn

Tình hình cũng tương tự như vậy đối với việc lựa chọn và sửa đổi kiến trúc phần mềm

Hiểu được những khó khăn, vất vả (và cả những hiểm nguy !!!) trong thiết

kế phần mềm, cộng đồng công nghệ phần mềm đã tăng cường chia sẻ, trao đổi thông tin về các bản mẫu và xây dựng những cơ sở dữ liệu chứa các mẫu thiết kế dùng chung nhằm hỗ trợ nhau trong công việc Trong vòng mươi năm gần đây,

số mẫu kiến trúc được gia tăng đáng kể về số lượng, chất lượng và phong phú về loại hình Mức độ linh hoạt và mịn hóa của các nhóm mẫu cũng tăng lên đáng

kể Ta có thể tìm kiếm, đọc tài liệu hướng dẫn và vận dụng các mẫu thiết kế tổ chức, mẫu vận dụng, mẫu tương tác, mẫu cấu hình

Đại thể qui trình thiết kế kiến trúc theo mẫu bao gồm các bước lớn sau đây: Bước 1 Nhận biết yêu cầu đặt ra đối với hệ thống

phải tìm hiểu kĩ các yêu cầu và bạn phải trao đổi với nhóm làm kĩ nghệ yêu cầu

và những người có thẩm quyền để họ giải đáp, bổ sung hoặc thống nhất lại những yêu cầu của hệ thống Sau khi nắm vững các yêu cầu đặt ra đối với hệ thống, bạn có thể chuyển qua bước 2

Bước 2 Tìm kiếm mẫu Có thể, tại bước này bạn phải làm đi làm lại nhiều

lần Từ các kho mẫu, bạn chọn ra một nhóm mẫu đầu tiên Khảo sát nhóm mẫu này, bạn có thể lược bớt một số mẫu hoặc thay thế chúng bằng các mẫu khác

hoặc thêm các mẫu mới Có thể gọi nhóm mẫu này là nhóm mẫu ứng viên

Bước 3 Quyết định chấp nhận mẫu Bạn cần trao đổi, kiểm điểm với nhóm

phát triển và những người có thẩm quyền để lựa chọn một mẫu từ nhóm mẫu ứng viên Dĩ nhiên, trước đó bạn cần chỉnh sửa sơ bộ các mẫu ứng viên cho tương đối phù hợp với dự kiến thiết kế của bạn Kết quả cuối cùng của bước này là một bản thiết kế duy nhất - bản khởi thủy cho hệ thống

Các bước tiếp theo thuộc về qui trình phân rã và làm mịn kiến trúc

2.2.1 Kiến trúc Mô hình, Quan sát và Điều khiển

(Model View Controller, MVC)

Mô tả: MVC tách riêng hiển thị dữ liệu và tương tác dữ liệu hệ thống Hệ

thống được tổ chức thành ba cấu phần logic tương tác lẫn nhau: (1) Cấu phần Mô hình quản trị dữ liệu hệ thống (bao gồm cả các thao tác trên dữ liệu); (2) Cấu phần Khung nhìn (hiển thị) quản trị các mẫu hiển thị dữ liệu cho người sử dụng; (3) Cấu phần Điều khiển quản trị các tương tác (thí dụ, nhấn phím trên bàn phím, kích chuột ) và chuyển các tác động này tới cấu phần Khung nhìn và cấu phần

Mô hình

Tình huống vận dụng: MVC được vận dụng trong tình huống có nhiều

khung nhìn và nhiều phương thức tương tác với dữ liệu MVC còn có thể được

vận dụng trong trường hợp ta chưa xác định được các phương thức trình bày và tương tác với dữ liệu trong tương lai

Ưu điểm: Cho phép dữ liệu thay đổi độc lập với các khung trình diễn và

ngược lại Hỗ trợ khả năng trình diễn dữ liệu theo nhiều khuôn dạng khác nhau

Nhược điểm: Có thể chứa các mã trình bổ sung và mã trình phức tạp ngay

cả trong trường hợp mô hình và tương tác chỉ là đơn giản

A Viết lại một phiên bản tiếng Anh và một phiên bản tiếng Pháp

B Viết thêm hai giao diện tiếng Anh và tiếng Pháp và đặt chế độ tùy chọn ngôn ngữ giao tiếp Việt, Anh hoặc Pháp

Trong trường hợp bạn chọn phương án B, bạn thử phác thảo kiến trúc phần mềm của bạn

2.2.2 Kiến trúc Phân tầng

(Layered Architecture, LA)

Mô tả: LA tổ chức hệ thống theo các tầng, mỗi tầng đảm nhận các nhóm

chức năng tương ứng Tầng dưới phục vụ cho tầng trên Tầng dưới cùng chính là các dịch vụ cơ sở

Tình huống vận dụng: LA được vận dụng trong các tình huống sau: (1)

Khi xây dựng các tiện ích mới nằm ở tầng trên của hệ thống hiện có; (2) Khi một bước phát triển được phân chia cho nhiều nhóm, mỗi nhóm triển khai một chức năng; (3) Khi đòi hỏi bảo mật theo nhiều mức

Ưu điểm: Kiến trúc LA cho phép thay thế trọn một tầng khi cần cập nhật lại

các khuôn dạng hiển thị dữ liệu Có thể xây dựng các khả năng dự phòng dư thừa nhằm nâng cao tính phụ thuộc cho hệ thống, thí dụ, khi cần tổ chức bảo mật, cấp

và xác thực bản quyền, ngăn chặn người sử dụng xem các dữ liệu nhạy cảm, ta

có thể bổ sung thêm cơ chế bảo mật, phân quyền vào tầng hiển thị hoặc thêm

người sử dụng

Nhược điểm: Trong thực tế việc tổ chức phân định rạch ròi giữa các tầng

thường là khó và tầng cao thường đôi khi cần tương tác với các tầng thấp không nằm trực tiếp dưới nó Kiến trúc LA có thể gây ảnh hưởng đến năng suất vì mọi yêu cầu được chuyển đến tầng khác đều phải được kiểm soát và xử lí

Mức 1: Toàn quyền đọc, ghi và sửa mọi dòng, cột của mọi bảng.Mức này thường dành cho quản trị trưởng

Mức 2: Được phép đọc, ghi và sửa một số bảng

Mức 3: Được phép đọc, ghi và sửa mọi dòng, cột của một số bảng

Mức 4: Được phép chỉ đọc mọi dòng và cột của mọi bảng

Mức 5:

Hãy phác thảo một tầng kiến trúc mới cho hệ thống

2.2.3 Kiến trúc Kho chứa

(Repository Architecture, RA)

Mô tả: Quản lí dữ liệu trong kiến trúc RA được giao cho một kho trung tâm

của hệ thống Mọi cấu phần của hệ thống đều có thể truy cập đến kho này Các cấu phần không giao tiếp trực tiếp với nhau mà buộc phải thông qua kho này

Tình huống vận dụng: RA được vận dụng khi thiết kế các hệ thống phát

sinh những tập dữ liệu lớn đòi hỏi phải có kho chứa trong khoảng thời gian dài

RA còn được vận dụng trong các hệ thống hướng dữ liệu, trong đó mỗi khi sản sinh dữ liệu trong kho chứa một công cụ hoặc một thao tác nào đó của hệ thống

sẽ được kích hoạt

Ưu điểm: Các cấu phần được hoạt động độc lập với nhau Mỗi cấu phần

trong hệ thống không cần quan tâm đến sự tồn tại của cấu phần khác Do dữ liệu được tập trung tại một kho nên sự thay đổi (dữ liệu) do một cấu phần sinh ra sẽ

được truyền bá đến mọi cấu phần khác trong hệ thống Mọi dữ liệu trong hệ thống được đảm bảo toàn vẹn (thí dụ, hệ thống có thể thực hiện sao lưu tại bất kì thời điểm nào)

Nhược điểm: Mọi khó khăn nảy sinh đều rơi vào nguyên nhân tập trung dữ

liệu Truy nhập dữ liệu từ xa, hoặc phân tán trên nhiều máy tính có thể không hiệu quả Mọi lỗi dữ liệu đều ảnh hưởng đến mọi cấu phần hệ thống

2.2.4 Kiến trúc Khách - Chủ

(Client - Server, CS)

Mô tả: Trong kiến trúc Khách – Chủ chức năng của hệ thống được tổ chức

thành các dịch vụ, mỗi dịch vụ được giao cho một đơn vị riêng đảm nhiệm Khách chính là những người sử dụng các dịch vụ của hệ thống và truy cập đến các đơn vị đảm nhiệm dịch vụ đó

Tình huống vận dụng: Kiến trúc CS được vận dụng khi dữ liệu trong cơ sở

dữ liệu dùng chung được truy nhập từ nhiều địa điểm Vì các đơn vị phục vụ có thể đảm đương những dịch vụ giao nhau nên kiến trúc CS còn có thể được vận dụng trong các tình huống truy nhập hệ thống là biến thiên

Ưu điểm: Ưu điểm chính của kiến trúc này là các đơn vị dịch vụ có thể

được phân tán trên mạng Các chức năng chung (thí dụ, dịch vụ in) được cung cấp cho mọi khách hàng

Nhược điểm: Mỗi khi sinh lỗi tại một điểm dịch vụ thì tiến trình đa nhiệm

của khách hàng sẽ bị gián đoạn Việc hồi phục có thể là không khả thi Mỗi sự cố trên mạng cũng có thể ảnh hưởng đến hoạt động của hệ thống

2.2.5 Kiến trúc Ống và Lọc

(Pipe and Filter, PAF)

Mô tả: Trong kiến trúc PAF, mỗi cấu phần xử lí dữ liệu (được gọi là bộ lọc)

là rời nhau và cho ra một kiểu dữ liệu Dòng dữ liệu (như dòng chảy trong một đường ống) từ một cấu phần tới một cấu phần khác để được xử lí tuần tự

Tình huống vận dụng: Được vận dụng chung cho các ứng dụng xử lí dữ

liệu, (theo cả hai chế độ: xử lí theo lô và xử lí theo từng giao dịch), khi input được xử lí theo từng pha riêng, mỗi pha cho ra một output tương ứng

Ưu điểm: Kiến trúc rõ ràng, dễ hiểu, trợ giúp tốt cho các tình huống tái sử

dụng giao dịch và do đó được vận dụng nhiều trong các tiến trình thương mại

như xử lí tương tranh

Nhược điểm: Trong quá trình dữ liệu chuyển theo các đường ống từ bộ lọc

này đến bộ lọc khác, cấu trúc dữ liệu có thể thay đổi, thí dụ như thêm hoặc bớt một vài trường, hoặc phương thức, đổi dạng, thí dụ từ văn bản sang đồ họa Tình huống này buộc các bộ lọc phải thực hiện nhiều chuyển đổi vào / ra phức tạp và

do đó làm giảm hiệu năng chung của hệ thống, thậm chí còn hạn chế khả năng tái sử dụng

Xử lí theo từng giao dịch: Nhận một giao dịch và xử lí ngay

Thí dụ: Trao đổi trực tuyến với một khách hàng

Xử lí (giao dịch) theo lô: Nhận một tập giao dịch rồi xử lí tập

đó

Thí dụ: Nhận một tập đơn đặt hàng từ các khách hàng sau đó

phân nhóm theo mặt hàng rồi đáp ứng

Xử lí (giao dịch) phân tán: (1) Chia giao dịch thành các thành

phần rồi gửi mỗi thành phần đến một máy để xử lí sau đó tổng

hợp kết quả; (2) Xử lí giao dịch tại một máy nhưng cần dữ liệu từ

nhiều máy khác; Kết hợp (1) và (2)

Thí dụ: (1) Giải quyết một đơn thư liên quan đến nhiều đơn

vị (2) Tổng hợp báo cáo từ nhiều đơn vị (1&2) Hội thảo điện tử

nhằm quyết định một giải pháp nào đó

Xử lí tương tranh: Xử lí giao dịch A đòi hỏi phải xem xét

tương quan về trật tự thời gian, trật tự thao tác và truy nhập dữ

liệu với các giao dịch khác

Thí dụ: Xử lí các thao tác cập nhật (xen, xóa, sửa dữ liệu)

trong cơ sở dữ liệu phân tán Xử lí các thao tác truy nhập và cập

nhật các file dùng chung cho nhiều máy trong một mạng máy

cùng chung tác nghiệp Vì lí do đó nên có thể xây dựng các đặc trưng cho từng lớp ứng dụng như các siêu thị tạp hoá, điện máy, khách sạn Dĩ nhiên là các đặc trưng này giới hạn trong cùng một quốc gia hoặc lãnh thổ; với các quốc gia hoặc vùng lãnh thổ khác nhau còn có thể có một vài qui định khác nhau Thí dụ, một

số quốc gia qui định khách không được cho nhân viên tiền thưởng, trong khi một

số quốc gia lại qui định tiền thưởng là bắt buộc và coi như đó là khoản thu nhập tính trong thu nhập của nhân viên Từ đó thấy rằng các hóa đơn của mỗi quốc gia lại có thể có những khoản mục khác nhau Tuy nhiên, những khác biệt này là không lớn và do đó ta vẫn có thể tái sử dụng từng phần Mỗi kiến trúc ứng dụng

có thể cài đặt lại với một vài thay đổi Hầu hết, trong một quốc gia thì gần như không có sự thay đổi nhiều

Với mỗi phần mềm, kiến trúc sư có thể sử dụng các kiến trúc ứng dụng theo nhiều phương cách khác nhau:

1 Tại pha đầu tiên, khi chưa hiểu rõ lĩnh vực ứng dụng bạn cần xuất phát

từ một mẫu chung nhất Dĩ nhiên là sau đó ta vẫn cần xác định các đặc thù cụ

thể Dù sao thì bước khởi đầu như vậy là rất cần thiết

2 Lập một bảng kiểm mục So sánh với kiến trúc khởi thuỷ, mục nào là phù

hợp, mục nào chưa

3 Tổ chức công việc cho nhóm phát triển Thực thi song song triển khai

kiến trúc cho từng cấu phần

4 Lựa chọn các cấu phần tái sử dụng So sánh với kiến trúc đã chọn Cần

hiểu rõ cấu phần bạn chọn đáp ứng yêu cầu hệ thống ở mức độ nào

5 Lập bảng từ vựng: Trao đổi về các đặc thù hoặc đối sánh Cần vận dụng

các quan niệm dã mô tả trong thiết kế khởi thuỷ

Bạn đọc có thể tham khảo thêm các trang Web sau đây:

Các mẫu kiến trúc phổ biến:

 Kiến trúc Mô hình, Quan sát và Điều khiển MVC

 Kiến trúc Kho chứa RA

 Kiến trúc Khách - Chủ CS

 Kiến trúc Ống và Lọc PAF

 Các kiến trúc ứng dụng