Tài liệu Kiến trúc và thiết kế phần mềm

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: [email protected]. 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