Công nghệ phần mềm - Thiết kế kiến trúc

Công nghệ phần mềmThiết kế kiến trúcMục tiêuGiới thiệu thiết kế kiến trúc và tầm quan trọng của nóGiải thích các quyết định thiết kế kiến trúc cần đưa raGiới thiệu ba kiểu kiến trúc dành cho tổ chức, phân rã, và điều khiển (organisation, decomposition and control)Các kiến trúc tham khảo dùng để giao tiếp và so sánh kiến trúc.*Các chủ đềCác quyết định về thiết kế kiến trúcTổ chức hệ thốngCác kiểu phân rãCác kiểu điều khiểnReference architectures*Kiến trúc phần mềmThiết kế kiến trúc là quy trình thiết kế nhằm nhận diệnCác hệ thống con cấu thành nên một hệ thống, vàFramework cho việc điều khiển và liên lạc giữa các hệ thống. Kết quả là một mô tả về kiến trúc phần mềm*Thiết kế kiến trúcLà giai đoạn sớm của quy trình thiết kế hệ thốngĐại diện cho mối liên kết giữa đặc tả và các quy trình thiết kếThường được thực hiện song song với một số hoạt động đặc tảBao gồm việc nhận diện các thành phần hệ thống chính và giao tiếp giữa chúng*Ưu điểm của kiến trúcGiao tiếp với stakeholderStakeholder của hệ thống có thể dùng kiến trúc làm trọng tâm thảo luậnPhân tích hệ thốngPhân tích xem có thể làm cho hệ thống thỏa mãn các yêu cầu phi chức năng hay không.Tái sử dụng quy mô lớnCó thể tái sử dụng kiến trúc giữa nhiều hệ thống.*Cấu trúc hóa hệ thốngLà việc phân rã hệ thống thành những hệ thống con tương tác với nhauThiết kế kiến trúc thường được diễn đạt bằng một block diagram trình bày tổng quan về cấu trúc hệ thốngCác mô hình cụ thể hơn cho biết các hệ thống con chia sẻ dữ liệu và phân tán như thế nào, interface giữa các hệ thống con cũng có thể được phát triển*Packing robot control system*Object identification system Arm controllerGripper controllerVision systemPacking systemConveyer controllerPackaging selection systemBox and line diagramsRất trừu tượng – chúng không mô tả bản chất của quan hệ giữa các thành phần cũng như các tính chất nhìn được từ bên ngoài của các hệ thống conTuy nhiên, hữu ích khi giao tiếp với stakeholder và cho việc lập kế hoạch dự án*Architectural design decisionsArchitectural design is a creative process so the process differs depending on the type of system being developedHowever, a number of common decisions span all design processes*Các quyết định thiết kế kiến trúcCó kiến trúc ứng dụng tổng quát nào có thể dùng được?Hệ thống sẽ được phân tán như thế nào?Các kiểu kiến trúc nào thích hợp?Dùng cách tiếp cận nào để cấu trúc hóa hệ thống?Hệ thống sẽ được phân rã thành module như thế nào?Đánh giá thiết kế kiến trúc như thế nào?Kiến trúc nên được viết tài liệu như thế nào?*Các mô hình kiến trúcDùng để ghi tài liệu một thiết kế kiến trúcMô hình cấu trúc tĩnh mô tả các thành phần chính của hệ thốngMô hình tiến trình động mô tả cấu trúc xử lý của hệ thốngMô hình interface định nghĩa các giao diện giữa các hệ thống con.Mô hình quan hệ chẳng hạn mô hình data-flow mô tả quan hệ giữa các hệ thống conMô hình phân tán mô tả các hệ thống con được phân tán tại các máy tính như thế nào*System organisationPhản ánh chiến lược cơ bản để cấu trúc một hệ thốngBa kiểu tổ chức được dùng rộng rãi:A shared data repository style;A shared services and servers style;An abstract machine or layered style.*The repository modelCác hệ thống con phải trao đổi dữ liệu. Có thể thực hiện theo hai các:Dữ liệu dùng chung được đặt tại CSDL hoặc repository trung tâm và tất cả các hệ thống con đều có thể truy cập;Mỗi hệ thống con giữ CSDL riêng và truyền dữ liệu một cách tường minh cho các hệ thống con khác.Khi cần chia sẻ lượng dữ liệu lớn, mô hình chia sẻ kiểu repository được dùng rộng rãi nhất.*CASE toolset architecture*Project repositoryDesign editorCode generatorProgram editorDesign editorCode generatorDesign translatorĐặc điểm của mô hình repositoryƯu điểmCác hiệu quả để dùng chung lượng dữ liệu lớn;Các hệ thống con không cần quan tâm dữ liệu được tạo như thế nàoCông việc quản lý như backup, bảo mật, .. được tập trung.Mô hình dùng chung được công bố dưới dạng repository schema.Nhược điểmCác hệ thống con phải thống nhất về một mô hình dữ liệu repository. Thỏa hiệp là tất yếu;Tiến hóa dữ liệu là khó khăn và chi phí cao;Không có phạm vi cho các chính sách quản lý cụ thể;Khó phân tán một cách có hiệu quả.*Client-server modelMô hình hệ thống phân tán trong đó dữ liệu và xử lý dữ liệu được phân bố cho nhiều componentMột tập các server độc lập cung cấp các dịch vụ cụ thể, chẳng hạn in, quản lý dữ liệu, v.v..Một tập các client gọi các dịch vụ đóMạng máy tính cho phép client tương tác với các serverServer là "trình phục vụ", không phải "máy chủ"!*Film and picture library*InternetClient 1Client 2Web serverFilm and photo info.Video server Film clip filesPicture server Digitalized photosCatalog server Library catalogClient 3Đặc điểm mô hình client-serverƯu điểmDữ liệu được phân tán một cách rõ ràng dễ hiểu;Sử dụng hiệu quả các hệ thống nối mạng. Có thể đòi hỏi phần cứng rẻ hơn;Dễ bổ sung server mới hoặc nâng cấp các server cũ.Nhược điểmKhông có mô hình dữ liệu dùng chung nên các hệ thống con phải dùng các tổ chức dữ liệu riêng. Việc trao đổi dữ liệu có thể không hiệu quả;Quản lý dư thừa đặt tại mỗi server;Không có đăng kí trung tâm cho tên và dịch vụ - có thể khó tìm xem hiện có những server và dịch vụ nào.*Abstract machine (layered) modelMô hình phân tầngDùng để mô hình giao diện giữa các hệ thống con.Tổ chức hệ thống thành tập các layer (hoặc abstract machines) mỗi layer cung cấp một tập các dịch vụ.Hỗ trợ phát triển tăng dần đối với các hệ thống con tại các layer khác nhau. Khi một layer thay đổi, chỉ có layer sát nó bị ảnh hưởng.Tuy nhiên việc cấu trúc các hệ thống theo kiểu này thường không tự nhiên.*Version management system*Version Management layerObject management system layerDatabase system layerOperating System layerCác phong các phân rã mô-đunCác phong cách phân rã các hệ thống con thành các mô-đun.Không có phân biệt cứng nhắc giữa tổ chức hệ thống con và phân rã mô-đun.*Sub-systems and modulesSub-system – hệ thống conChính nó đã là một hệ thốngHoạt động của nó phụ thuộc vào các dịch vụ của các hệ thống con khácModuleMột thành phần hệ thống (component)Cung cấp dịch vụ cho các thành phần khácThường không được coi là một hệ thống riêng biệt.*Phân rã mô-đunMột mức cấu trúc khác mà trong đó các hệ thống con được phân rã thành các mô-đunHai mô hình phân rã mô-đun:Mô hình đối tượng Hệ thống được phân rã thành các đối tượng tương tác với nhauMô hình pipeline hoặc data-flowHệ thống được phân rã thành các mô-đun chức năng – các mô-đun biến đổi input thành outputNếu có thể, các quyết định về việc các mô-đun có chạy song song hay không nên được để cho đến khi cài đặt các mô-đun*Mô hình đối tượngCấu trúc hệ thống thành một tập các đối tượng ghép nối lỏng lẻo với nhau (loosely coupled) thông qua các giao diện được định nghĩa rõ ràngViệc phân rã xác định các lớp đối tượng, các thuộc tính và thao tác của chúngKhi cài đặt, các đối tượng được tạo từ các lớp này và một số hình thức điều khiển được sử dụng để đồng bộ hóa hoạt động của các đối tượng*Invoice processing system*issue ()sendReminder ()acceptPayment()sendReceipt ()invoice#dateamountcustomerinvoice#dateamountcustomer#invoice#dateamountcustomer#customer#nameaddresscredit periodCustomerPaymentInvoiceReceiptMũi tên gạch đứt có nghĩa: một đối tượng dùng thuộc tính/thao tác của đối tượng kiaObject model (dis)advantagesƯu điểmCó tính kết nối lỏng (loosely coupled) nên cài đặt các đối tượng có thể được sửa đổi mà không ảnh hưởng các đối tượng khácGần gũi với các đối tượng ngoài đời thựcCác ngôn ngữ hướng đối tượng được sử dụng rộng rãiNhược điểmViệc thay đổi giao diện đối tượng có thể gây ra vấn đềCó thể khó dùng đối tượng để biểu diễn các thực thể phức tạp, trừu tượng*Function-oriented pipeliningCác tiến trình biến đổi input để tạo outputCó thể gọi là pipe model và filter modelKhông thực sự thích hợp cho các hệ thống tương tác*Invoice processing system*Read issued invoicesIdentify paymentsIssue receiptsFind payments dueReceiptsIssue payment reminderRemindersInvoicesPaymentsPipeline model (dis)advantagesƯu điểmHỗ trợ tái sử dụng các tiến trình biến đổiLà tổ chức trực quan cho việc giao tiếp với stakeholderDễ bổ sung các tiến trình mớiTương đối đơn giản để cài đặt thành hệ thống tuần tự hoặc song songNhược điểm Đòi hỏi định dạng chung cho việc chuyển dữ liệuKhó hỗ trợ tương tác event-based*Các kiểu điều khiểnDùng cho luồng điều khiển giữa các hệ thống conPhân biệt với mô hình phân rã hệ thốngĐiều khiển tập trungMột hệ thống con có trách nhiệm chung cho điều khiển việc khởi động và dừng các hệ thống con khácEvent-based control – điều khiển dựa sự kiệnMỗi hệ thống con cần đáp ứng một số sự kiện bên ngoài do các hệ thống khác tạo ra hoặc từ môi trường hệ thống*Điều khiển tập trungMột hệ thống con chỉ huy ( control sub-system) giữ trách nhiệm quản lý việc chạy các hệ thống con khácCall-return modelMô hình chương trình con top-down, trong đó điều khiển bắt đầu từ đỉnh cây phân cấp và di chuyển theo hướng đi xuống. Áp dụng cho các hệ thống tuần tự (sequential systems).Manager modelÁp dụng cho các hệ thống song song. Một thành phần hệ thống điều khiển việc tắt, bật và đồng bộ hóa các tiến trình hệ thống khác. Có thể cài đặt trong các hệ thống tuần tự như dạng câu lệnh case*Call-return model*MainprogramRoutine 3Routine 2Routine 1Routine 1.1Routine 2.1Routine 3.1Real-time system control*SystemcontrolleruserinterfaceSensorprocessesActuatorprocessesComputation processesFault handlerEvent-driven systemsHệ thống bị dẫn dắt bởi các sự kiện tạo ra từ bên ngoài, trong đó thời gian và thời điểm của các sự kiện nằm ngoài tầm kiểm soát của các hệ thống xử lý sự kiệnHai mô hình event-driven chínhBroadcast modelsMột sự kiện được gửi cho tất cả các hệ thống con. Hệ thống con nào có thể xử lý thì xử lý;Interrupt-driven modelsDùng trong các hệ thống thời gian thực, trong đó một interrupt handler phát hiện các ngắt (interrupt) và gửi nó cho một thành phần khác để xử lý.Các mô hình event driven khác: spreadsheet và production system*Broadcast modelHiệu quả trong việc tích hợp các hệ thống con nằm tại các máy khác nhau trong một mạng.Các hệ thống con đăng kí quan tâm tới các sự kiện cụ thể. Khi một sự kiện xảy ra, điều khiển được chuyển cho hệ thống con nào có thể xử lý sự kiện đó.Chính sách điều khiển không được nhúng trong sự kiện và thành phần xử lý thông điệp (message handler). Các hệ thống con tự quyết định chúng quan tâm đến những sự kiện nào.Tuy nhiên, các hệ thống con không biết một sự kiện cụ thể nào đó có được xử lý hay không hoặc khi nào sẽ được xử lý.*Selective broadcasting*Event and message handlerSub-system 1Sub-system 2Sub-system 3Interrupt-driven systemsDùng trong các hệ thống thời gian thực mà trong đó việc đáp ứng nhanh chóng một sự kiện có ý nghĩa cốt tử.Có các loại interrupt được biết trước, mỗi loại có một handler được định nghĩa trước.Mỗi loại được gắn với một khu vực trong bộ nhớ và một hardware switch chuyển nó tới handler.Cho phép phản ứng nhanh nhưng phức tạp khi lập trình và khó thẩm định.*Interrupt-driven control*Handler1Process1Handler 2Process2Handler3Process3Interruptvector