架構設計 Architectural Design

1. 架構設計Architectural Design

2. 大綱 • 軟體架構 • 資料設計 • 架構的型態與模式 • 架構的設計 • 評估可供選擇的架構設計 • 將資料流向映對成軟體架構

3. 軟體架構 • 什麼是架構(architecture) • 架構設計表示建立一個以電腦為基礎系統所必須要的資料結構與程式元件。它考慮系統所採取的架構型態、建構系統元件的結構與性質，和發生於系統的所有架構元件之間的交互關係。 • 組合軟體元件、元件外部可見的性質、它們之間的關係 • 軟體的整體架構，和其內結構所提供系統概念整合的方式。

4. 軟體架構(con’t) • The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: • analyze the effectiveness of the design in meeting its stated requirements, • consider architectural alternatives at a stage when making design changes is still relatively easy, and • reduce the risks associated with the construction of the software.

5. customer requirements "four bedrooms, three baths, lots of glass ..." architectural design 軟體架構(con’t) • 為何重要，有三大理由 • 溝通 • 早期決策 • 構成易於掌握的模型 • 提供你大的圖，並確保你得到對的東西

6. 資料設計 • 設計金字塔(圖9.1) • 資料設計(data design)： • 讓我們在物件導向的系統中，表示傳統系統與類別定義(包括屬性與操作)中架構的資料元件。 • 架構設計(architectural design)： • 聚焦於軟體元件的結構、及它們的性質和互動的表示。

7. 資料設計(Con’t) • 資料設計的原則： • 應用到功能與行為的系統化分析原則也應該能應用於資料上。 • 所有的資料結構和其所要實行的操作都應該確認。 • 應該建立定義每個資料物件內容的機制，並用來定義應用於它的資料與操作。 • 低層級的資料設計決策應該延遲到設計流程的後期。 • 資料結構的表示只有對那些必須準備直接使用包含於結構裡的資料模組，才應該要知道。 • 有用的資料結構程式庫和可能應用它們的操作應該被發展。 • 軟體設計與程式語言應該支援抽象資料型態的規格與實現(realization)。

8. 架構的型態與模式 • 架構的型態(Styles) • 以資料為中心的架構(Data-centered architecture) • 資料流向的架構(Data-flow architecture) • 呼叫與返回架構(Call and return architecture) • 主程式/副程式架構(Main program/subprogram architecture) • 遠端程序呼叫架構(Remote procedure architecture) • 主程式/副程式架構的元件分散跨越於網路上的多部電腦中。 • 物件導向的架構(Object-oriented architecture) • 系統的元件將資料和應用於操縱資料的操作封裝起來。 • 通訊與協調經由訊息傳遞(message passing)而完成。 • 層級架構(Layered architecture)

9. 架構的型態與模式(Con’t) • 架構型態的選擇 • 這些架構型態只是對軟體設計者可以利用的小型子集合。 • 一旦需求工程揭開所要建造系統的特性與侷限時，最適合此特性與侷限的架構型態或型態的組合可被選擇。 • 許多情形中，超過一種以上的型態可能是較為恰當的，且可供選舉的方案可被設計與評估。 • 例如，在許多資料庫的應用程式中，階層的型態(適用於大多數的系統)能結合以資料為中心的架構。 • 簡單的說可以選擇一個或結合多種架構

10. 架構的型態與模式(Con’t) • 架構的模式 • 房屋建造者決定建構一棟殖民地式的中央大廳。形態 • 架構的模式則有一些不同。 • 例如，廚房模式。定義基本的廚房家電、水槽、廚櫃的安置。廚房的設計是超過一種以上，但每一種設計能藉由廚房模式所建議的「解決方案」環境中構想出。模式

11. 架構的型態與模式(Con’t) • 軟體的架構模式定義特別的方式以處理某些系統的行為特性。 • 架構的模式 • 併行(Concurrency) • 模擬平行的方式處理多重的任務 • 例如：作業系統行程管理(operating system process management)、任務排程器(task scheduler) • 持續(Persistence) • 執行後資料要持續 • 例如：資料庫管理系統(Database management system) • 分散(Distribution) • 在分散式環境中元件彼此通訊 • 實體間彼此相連接的方法 • 通訊的性質 • 例如：經紀人(broker)模式，如CORBA • 前面所提及的任何一種架構模式都是可以選擇的，它必須對應用程式與整體架構型態的合適性，和它的可維護性(maintainability)、可靠性(reliability)、安全與效能進行評估。

12. 架構的型態與模式(Con’t) • 組織與改進 • 資料(Data) • 資料如何在元件之間通訊？資料的流向是連續的，或資料物件偶爾零星地傳給系統？資料轉移的模式是什麼(即資料由一個元件傳到另一個元件，或在系統的元件之間資料是全體所共享的)？資料元件(即一個黑板或倉庫)存在嗎？如果是，它們的角色是什麼？功能元件如何與資料元件互動？資料元件是被動或主動的(即資料元件主動地與其他系統中的元件互動)？資料與控制如何在系統中互動？ • 這些問題提供設計者早期評估設計品質，並立下更為詳細的架構分析基礎。

13. 架構的設計 • 當架構的設計開始，所要發展的軟體必須被置入環境中，即設計應該定義軟體所互動的外部實體(其他的系統、裝置、人)和互動的性質。 • 此資訊通常可由分析模型和需求工程期間所蒐集的所有其他資訊中獲得。 • 一旦環境被塑模完成且所有外部軟體的介面也被描述，設計者藉由定義與改進實作架構的軟體元件詳細說明系統的結構。此流程將反覆地繼續，直到導出完整架構的結構。

14. 架構的設計(Con’t) • 一位系統工程師必須要塑模環境，環境中系統的表示 • 使用架構環境圖(architectural context diagram, ACD)塑模軟體與外部實體互動的情形 • 與目標系統(target system)相互操作的系統 • 上級系統(Superordinate systems) • 使用目標系統做為某些較高層級處理方案一部分的那些系統。 • 下級系統(Subordinate systems) • 那些由目標系統所使用並提供完成目標系統功能性所必需的資料或處理的系統。 • 同儕層級系統(Peer-level systems) • 那些在以點對點基礎上互動的系統(即資訊要不是被同儕和目標系統產生，要不就是消耗)。 • 參與者(Actors) • 藉由產生或消耗對必要處理所需要的資訊與目標系統互動的那些實體(人、裝置)。 • 每個外部實體經由一個介面(小的陰影長方形)與目標系統通訊。 • 實例：『安全家』安全功能的架構環境圖

15. 架構的設計(Con’t) • 定義原型(archetype) • 原型(archetype)是一種類別或模式，它表示核心的抽象化，這對目標系統架構的設計必定是不可少的。 • 通常，對於設計或甚至相對複雜的系統，相對小的原型是必需的。目標系統架構是由這些原型所組成，此呈現出架構的穩定元素，但可以基於系統的行為，以許多不同的方法舉列。 • 以『安全家』居家安全功能為例(使用UML)

16. 架構的設計(Con’t) • 改進架構成為元件 • 系統的結構會開始浮現 • 元件如何選擇？ • 由分析類別開始 • 元件有三個來源： • 應用程式領域 • 基礎建設領域 • 介面領域 • 以『安全家』為例

17. 架構的設計(Con’t) • 進一步的細化 • 顯示更多的細節 • 以『安全家』為例

18. 評估可供選擇的架構設計 • 架構權衡分析方法(Architecture Trade-Off Analysis Method,ATAM) • 軟體架構分析方法(Software Architecture Analysis Method, SAAM) • 架構的複雜性

19. 評估可供選擇的架構設計(Con’t) • 架構權衡分析方法(Architecture Trade-Off Analysis Method,ATAM) • 一旦架構的敏感點已經決定，尋找權衡點就只是簡單地對多個敏感的屬性架構元件的辨識。 • 例如，主從式架構的效能可能對伺服器的數量是高度敏感的(在某個範圍內，藉由增加伺服器的數量來增加效能)……。 • 伺服器的數量是有關於此架構的一個權衡點

20. 評估可供選擇的架構設計(Con’t) • 架構的複雜性 • 評估複雜性的方法是考慮元件之間的相依性(dependencies)，有三種型態 • 共享相依性(sharing dependencies) • 兩元件都參考到同一全域資料 • 流向相依(flow dependencies) • 若在控制流進入v之前，u必須先完成 • 侷限的相依性(constrained dependencies) • 兩元件不能同時執行(互斥)

21. 評估可供選擇的架構設計(Con’t) • 架構的描述語言(Architectural Description Language, ADL) • 提供語意與語法以描述軟體架構 • 雖然軟體架構師可以利用UML標記、其他的圖表型態和一些相關的工具，但對於架構設計的規格還是需要更為正規的方式。 • 一旦架構設計的描述、以語言為基礎的技術已建立後，當設計演進時，對架構的有效評估方法將更為可能地被建立。

22. Transform flow Transaction flow 將資料流向映對成軟體架構 • 以資料流向為導向的設計方法 • 從資料流向圖  轉換成架構設計 • Flow Characteristics • Transform flow(轉換流向) • Transaction flow(交易流向)

23. 將資料流向映對成軟體架構(Con’t) • 轉換流向(Transform flow) • 資訊必須要以「外部世界」的形態進入與離開軟體。例如： • 在鍵盤上所鍵入的資料、電話線路的音調，和在多媒體應用程式中的視訊影像都是外部世界資訊的形式。 • 此種外部化(externalized)的資料必須要轉換成內部的形式以進行處理。 • 進入流向(incoming flow)--資訊由外部進入 • 轉換中心(transform center)--發生轉換 • 輸出流向(outgoing flow) • 整體的資料流向跟隨著一個或少許的「直線(straight line)」徑路，以連續的方式發生。

24. 將資料流向映對成軟體架構(Con’t) • 交易流向(Transaction flow) • 資訊流向經常藉由交易(transaction) 觸發沿著許多路徑之一的其他資料流向。 • 如圖10.10 • 大系統的DFD中，轉換與交易流向兩者都可能存在。 • 例如，在以交易為導向的流動，沿著動作路徑的資訊流向可能會有轉換流向的特性。

25. 將資料流向映對成軟體架構(Con’t) • 轉換應對(transform mapping) • 一組設計步驟，使具備轉換流向特性的DFD被mapping到特定的架構型態內。 • 相關名詞 • 分解(factoring) • 第一層級分解 • 第二層級分解 • 以『安全家』的安全功能為例，步驟如下：

26. 將資料流向映對成軟體架構(Con’t) • 轉換應對(transform mapping) • 步驟一：檢討基本的系統模型 • 圖10.11層級0，圖10.12改進後的 • 步驟二：檢視與改進軟體的資料流向圖 • 圖10.13監控感測器層級2圖10.14層級3 • 步驟三：決定DFD是否有轉換和交易流向的特性 • 圖10.14層級3 • 步驟四：藉由明確指定進入或流出的流向界限隔離出轉換中心 • 圖10.14層級3 • 步驟五：執行『第一層級分解(factoring)』 • 圖10.15 第一層級分解 • 步驟六：實行『第二層級的分解』 • 圖10.16 第二層級分解，圖10.17第一次的反覆架構 • 步驟七：使用改善軟體品質的設計經驗法則(heuristics)以改進第一次的反覆架構

27. 將資料流向映對成軟體架構(Con’t) • 交易應對(Transaction Mapping) • 整體資料流向的特性以交易為導向 • 步驟類似轉換應對，最大差異在於DFD到軟體結構的映對。 • 以『安全家』的安全功能為例，步驟如下

28. 將資料流向映對成軟體架構(Con’t) • 交易應對(Transaction Mapping) • 步驟一：檢視基本的系統模型 • 步驟二：檢視與改進軟體的資料流向圖 • 步驟三：決定DFD是否有轉換或交易流向的特性 • 圖10.19 • 步驟四：沿著每個活動路徑確認交易中心與流向特性 • 圖10.19 • 步驟五：映對DFD於程式結構中以服膺交易處理 • 圖10.20，圖10.21 • 步驟六：分解和改進交易結構與每條動作路徑的結構 • 圖10.22 • 步驟七：使用設計經驗法則改進第一次反覆式架構以改善軟體的品質

29. Q&A • 報告結束 • Q&A • Q1有什麼軟體可以協助我們作架構設計嗎？ • Q2架構、模式和框架這些術語有什麼不一樣？ • Q3可否介紹幾種『架構的描述語言』？ • Q4有沒有其他的架構型態與模式?

30. 圖9.1 轉換分析模型成為設計模型

31. 圖10.1 以資料為中心的架構 以資料為中心的架構促進可整合性(integrability)

32. 圖10.2 資料流向的架構 當輸入的資料經過一連串的計算或操縱的元件而轉換成為輸出資料時，會應用這個架構。

33. 呼叫與返回架構(Call and return architecture)

34. 圖10.3 主程式/副程式架構

35. 圖10.4 層級的架構 • 許多不同的層級被定義，每個所完成的操作逐漸地趨近於機器指令集。 • 在外部的層級，元件提供使用者介面操作的服務。 • 在內部的層級，元件實行作業系統的介面呼叫。 • 中間的層級提供公共程式服務與應用軟體功能。

36. 圖10.5 架構環境圖

37. 圖10.6 「安全家」安全功能的架構環境圖

38. 圖10.7 「安全家」安全功能原型的UML關係

39. 圖10.8 「安全家」頂層元件的整體架構的結構

40. 圖10.9 元件細化的安全功能實例

41. 圖10.10 交易流向 • 交易被評估，流向動作路徑(action paths)之一。 • 交易中心(transaction center)。

42. 圖10.11「安全家」的環境層級DFD 層級0的模型：基本的系統模型或環境圖

43. 圖10.12「安全家」安全功能層級1的DFD 描述安全功能改進後的資料流向

44. 圖10.13層級2的DFD改進監控感測器轉換 檢查，獲得如圖10.14所示層級3的資料流向圖

45. 圖10.14 具有流向界線的監控感測器層級3的DFD 圖中的DFD對監控感測器子系統在架構設計的「初步版本」中已含括充分的細節。

46. 圖10.14 具有流向界線的監控感測器層級3的DFD • 一條進入路徑，三條流出的路 • 沒有明顯的交易中心轉換流向

47. 圖10.14 具有流向界線的監控感測器層級3的DFD

48. 圖10.15 監控感測器的第一層級分解 • 最高層級(top-level)元件實行決策，而低層級(low-level)元件實行大多數的輸入、計算和輸出工作。中間層級元件則實行某些控制，並執行適度的工作。

49. 圖10.16 監控感測器的第二層級分解 • 轉換個別的圓圈成架構中適當的模組。 • 由轉換中心界限開始，並沿著進入路徑，然後流出路徑以向外移動，轉換被映對到軟體結構中的從屬(subordinate)層級內。

50. 圖10.17 監控感測器的第ㄧ次反覆結構