Tài liệu Phân tích các tiêu chí và quy trình kiến trúc phần mềm

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƢỜNG ĐẠI HỌC SƢ PHẠM HÀ NỘI 2 LƢU THÀNH SƠN PHÂN TÍCH CÁC TIÊU CHÍ VÀ QUY TRÌNH KIẾN TRÚC PHẦN MỀM LUẬN VĂN THẠC SĨ MÁY TÍNH ................................................................................................................. 1 HÀ NỘI, 2014 BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƢỜNG ĐẠI HỌC SƢ PHẠM HÀ NỘI 2 LƢU THÀNH SƠN PHÂN TÍCH CÁC TIÊU CHÍ VÀ QUY TRÌNH KIẾN TRÚC PHẦN MỀM Chuyên ngành: KHOA HỌC MÁY TÍNH Mã số: 60 48 01 01 LUẬN VĂN THẠC SĨ MÁY TÍNH ............... Người hướng dẫn khoa học: PGS,TSKH: Nguyễn Xuân Huy 2 HÀ NỘI, 2014 LỜI CẢM ƠN Xin chân thành cảm ơn Thầy giáo, GS.TSKH. Nguyễn Xuân Huy đã tận tình chỉ dạy, hướng dẫn tôi trong suốt thời gian nghiên cứu và thực hiện luận văn. Tôi cũng xin chân thành cảm ơn các Thầy giáo Viện Công nghệ Thông tin và các Thầy giáo Trường Đại học sư phạm Hà Nội 2 đã giảng dạy, giúp đỡ trong suốt thời gian học tập. Xin cảm ơn tất cả các anh chị em học viên Cao học khóa 16 – Khoa học máy tình, cảm ơn các cán bộ công chức, giảng viên Trường Đại học sư phạm Hà Nội 2 đã tạo điều kiện tốt cho tôi trong suốt hai năm học qua. Xin cảm ơn các bạn bè, đồng nghiệp, gia đính đã tạo mọi điều kiện thuận lợi cũng như đã chỉ bảo tôi rất nhiều trong thời gian thực hiện luận văn này để tôi có được kết quả như ngày hôm nay. Hà Nội, tháng /2014 Người viết luận văn Lƣu Thành Sơn 3 LỜI CAM ĐOAN Tôi xin cam đoan rằng số liệu và kết quả nghiên cứu trong luận văn này là hoàn toàn trung thực và không trùng lặp với các đề tài khác. Tôi cũng xin cam đoan rằng mọi sự giúp đỡ cho việc thực hiện luận văn này đã được cảm ơn và các thông tin trìch dẫn trong luận văn đã được chỉ rõ nguồn gốc. Vĩnh Phúc, ngày tháng Tác giả Lƣu Thành Sơn 4 năm 2014 MỤC LỤC LỜI CẢM ƠN LỜI CAM ĐOAN MỞ ĐẦU ......................................................................................................... 1 1. Lý do chọn đề tài ............................................................................... 1 2. Mục đìch nghiên cứu ........................................................................ 2 3. Nhiệm vụ nghiên cứu ........................................................................ 2 4. Đối tượng và phạm vi nghiên cứu ................................................... 2 5. Phương pháp nghiên cứu .................................................................. 2 6. Những đóng góp mới của đề tài ........................................................ 3 7. Cấu trúc luận văn .............................................................................. 3 Chƣơng 1: Tổng quan về kiến trúc phần mềm ........................... 4 1.1 Khái niệm kiến trúc phần mềm ....................................................... 4 1.2 Các quyết định trong thiết kế kiến trúc ........................................... 7 1.3 Các quan điểm trong kiến trúc phần mềm .............................. …..14 1.4 Kết luận chương 1 ................................................................... …..16 Chƣơng 2: Quy trình phát triển phần mềm và các tiêu chí chất lƣợng của sản phẩm phần mềm ............................................. ….17 2.1 Mô hính phát triển phần mềm ................................................. ….17 2.1.1 Xác định từ một mô hính mẫu có sẵn ........................ ….17 2.1.2 Xác định từ mô hính phát triển phần mềm ................ ….20 2.1.3 Phương pháp phát triển phần mềm Agile .................. ….22 2.2 Hoạt động trong các quá trính ................................................ ….24 2.2.1 Đặc tả phần mềm ....................................................... ….25 2.2.2 Thiết kế và triển khai phần mềm ............................... ….27 5 2.2.3 Xác nhận phần mềm .................................................. ….33 2.2.4 Nâng cấp phần mềm .................................................. ….37 2.3 Các tiêu chì chất lượng của sản phẩm phần mềm .................. ….38 2.4 Kết luận chương 2 ................................................................... ….42 Chƣơng 3: Kỹ thuật xử lý yêu cầu và đối phó với sự thay đổi.43 3.1 Yêu cầu chức năng và phi chức năng ..................................... ….43 3.1.1 Yêu cầu chức năng .................................................... ….44 3.1.3 Yêu cầu phi chức năng .............................................. ….45 3.2 Đặc tả yêu cầu ......................................................................... ….51 3.2.1 Đặc tả bằng ngôn ngữ tự nhiên.................................. ….54 3.2.2 Đặc tả theo cấu trúc ................................................... ….56 3.3 Thu thập và phân tìch yêu cầu ................................................ ….59 3.4 Xác nhận yêu cầu .................................................................... ….62 3.5 Đối phó với sự thay đổi .......................................................... ….64 3.5.1 Xây dựng nguyên mẫu .............................................. ….65 3.5.2 Chuyển giao từng phần .............................................. ….69 3.6 Phân tìch và thiết kế chương trính quản lý danh bạ điện thoại…72 3.6.1 Đặt vấn đề .................................................................. ….72 3.6.2 Đặc tả chức năng........................................................ ….73 3.6.3 Phương án giải quyết cụ thể ...................................... ….73 3.6.4 Xây dựng sơ đồ phân rã chức năng, phân tìch đầu vào và đầu ra ............................................................................. ….75 3.6.5 Demo ứng dụng ......................................................... ….78 3.7 Kết luận chương 3 ................................................................... ….82 KẾT LUẬN ............................................................................................. ….83 DANH MỤC TÀI LIỆU THAM KHẢO ................................................ ….84 6 DANH MỤC CÁC HÌNH Hình 1.1: Một kiến trúc hệ thống yếu kém Hình 1.2: Một phương án cải tiến Hình 2.1: Kỹ thuật phần mềm theo hướng sử dụng lại Hình 2.2: Mô hình phát triển tăng tiến Hình 2.3: Quá trình kỹ thuật lấy yêu cầu Hình 2.4: Mô hình chung của quá trình thiết kế Hình 2.5: Các giai đoạn kiểm thử Hình 2.6: Các giai đoạn kiểm thử trong một quy trình phần mềm hướng kế hoạch Hình 2.7: Nâng cấp phần mềm Hình 3.1: Các dạng yêu cầu phi chức năng. Hình 3.2: Số liệu cụ thể cho các yêu cầu phi chức năng Hình 3.3: Một số cách viết đặc tả yêu cầu hệ thống Hình 3.4: Ví dụ về yêu cầu cho hệ thống phần mềm bơm insulin Hình 3.5: Một đặc tả yêu cầu có cấu trúc cho hoạt động bơm Insulin Hình 3.6: Đặc tả dạng bảng tính toán việc bơm Insulin Hình 3.7: Quy trình thu thập và phân tích yêu cầu Hình 3.8: Quá trình xây dựng một nguyên mẫu Hình 3.9: Chuyển giao từng phần Hình 3.10: Sơ đồ phân rã chức năng Hình 3.11: Sơ đồ luồng dữ liệu Hình 3.12: Sơ đồ quản lý danh bạ Hình 3.13: Sơ đồ quản lý tìm kiếm Hình 3.14 – 3.15 – 3.16: Giao diện tìm kiếm và Kết quả tìm kiếm Hình 3.17: Khi thêm số liên lạc vào danh bạ Hình 3.18: Khi sửa thông tin số liên lạc Hình 3.19: Khi xóa số liên lạc 7 MỞ ĐẦU 1. Lý do chọn đề tài 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. 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. 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, mỗi quy 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. Khi xây dựng và phát triển phần mềm nếu thực hiện đúng và đầy đủ theo các giai đoạn của mô hính phần mềm đã lựa chọn, đặc biệt là giai đoạn thiết kế, phần mềm sẽ tránh được sự rủi ro và có chất lượng tốt. Trên thực tế chúng ta thường làm việc không có kế hoạch cụ thể, làm tới đâu nghĩ tới đó, xem nhẹ bước thiết kế, coi trọng cài đặt mã nguồn. Kết quả mà chúng ta thu được thường là một khối mã nguồn rối rắm hoặc nếu có thí cũng chỉ là một chương trính nhỏ với vài chức năng cần thiết, rất khó cho bảo trí và tái sử dụng. Đôi khi, chúng ta làm việc có phần chủ quan và mang tình tự phát, nhưng nếu bính tĩnh 1 nghiên cứu, làm việc có kế hoạch và áp dụng các tiến trính thiết kế phần mềm vào trong bài toán của mính, chúng ta có thể thấy được nhiều hướng đi, nhiều cách giải quyết, mà có thể đó là những lời giải tối ưu mà trước đó chúng ta không thấy hoặc đã bỏ qua. Điều quan trọng hơn cả là chúng ta có thể theo dõi và kiểm soát được những gí đang xảy ra. Thiết kế là đồng nghĩa với việc tiết kiệm thời gian và tiền bạc. Nếu không có bản thiết kế hoặc thiết kế không tốt, khi có thay đổi yêu cầu một vài chức năng trong phần mềm hoặc nâng cấp, cải tiến các chức năng đó, chúng ta phải làm lại một chương tính hoàn toàn mới hoặc phải nghiên cứu lại toàn bộ mã nguồn, điều đó đồng nghĩa với việc tiêu tốn của chúng ta khá nhiều thời gian và tiền bạc. Ví thế tôi chọn đề tài “ Phân tích các tiêu chí và quy trình kiến trúc phần mềm” nhằm bổ sung thêm vào lì thuyết kiến trúc phần mềm được đầy đủ hơn. Mặt khác dưới một góc nhín rộng và bao quát hơn, thông qua việc phản ánh các kết quả của quá trính phân tìch, thiết kế thường xác định cho chúng ta nhiều hướng đi, nhiều cách thức giải quyết trên cùng một bài toán, từ đó cho phép chúng ta chọn được cách thức tốt nhất và con đường ngắn nhất để đi tới đìch 2. Mục đích nghiên cứu Phân tìch các tiêu chì và quy trính kiến trúc phần mềm nhằm giúp chúng ta nắm được các nguyên lì, cách thức tổ chức thiết kế kiến trúc phần mềm hay có thể tái sử dụng phần mềm. Hiểu được vai trò quan trọng của thiết kế kiến trúc phần mềm. 3. Nhiệm vụ nghiên cứu Tím hiểu về kiến trúc phần mềm. Mô hính phát triển phần mềm, các hoạt động trong quá trính phát triển phần mềm. Đưa ra cách thức giải quyết bài toán của việc thiết kế kiển trúc phần mềm. 4. Đối tƣợng và phạm vi nghiên cứu Đối tượng nghiên cứu của luận văn là tập trung tím hiểu một số tiêu chì và quy trính xây dựng kiến trúc phần mềm. 2 Cách thức tổ chức, xác định xây dựng kiến trúc cho một phần mềm. 5. Phƣơng pháp nghiên cứu Nghiên cứu tài liệu trong nước và quốc tế để tím hiểu, phân tìch, suy luận, tổng hợp, đánh giá. Từ đó đề xuất nghiên cứu phân tìch các tiêu chì và quy trính kiến trúc phần mềm. 6. Những đóng góp mới của đề tài Đưa ra được cách thức tổ chức, xác định xây dựng kiến trúc cho một phần mềm và xây dựng chương trính ứng dụng. 7. Cấu trúc luận văn Luận văn gồm: Lời mở đầu, ba chương nội dung, phần kết luận và sau cùng là tài liệu tham khảo. Chương 1: Tổng quan về kiến trúc phần mềm Chương 2: Quy trình phát triển phần mềm và các tiêu chì chất lượng của sản phẩm phần mềm Chương 3: Kỹ thuật xử lì yêu cầu và đối phó với sự thay đổi. 3 CHƢƠNG 1 TỔNG QUAN VỀ KIẾN TRÚC PHẦN MỀM 1.1 Khái niệm kiến trúc phần mềm 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 [9]. 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 4 while, trên cơ sở đó đề xuất khái niệm D-cấu trúcvớ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 [6]. 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. 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. [2] 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ác yêu cầu đối với hệ thống. + Đầu ra : 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. 5 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 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. 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ả: 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. 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. 6 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. - 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. 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. Thiết kế kiến trúc phần mềm theo 2 cấp độ: nhỏ và lớn. + 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. + 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í. 1.2 Các quyết định trong thiết kế kiến trúc Thiết kế kiến trúc là một quá 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. 7 Trong quá 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 đề 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? 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 đó. Ví 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ế. [2] 8 Thí dụ: 1. Chúng ta 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. 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; 9 + Đượ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; 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 vẹn) đượ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. 10 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. 11 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 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. 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: 12 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: Hình 1.1: Một kiến trúc hệ thống yếu kém Bước 1. Khách đăng nhập hệ thống: Điền trực tuyến (online) theo mẫu sau đó trả phí dịch vụ. Bước 2. Hệ thống tự trình diễn: giới thiệu về công ti và các dịch vụ hệ thống đảm nhiệm. Bước 3. Hướng dẫn khách lựa chọn dịch vụ cần thiết. Bước 4. Phục vụ khách theo dịch vụ đã chọn. Đ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 ty. 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: 13