簡介
架構這個字現在已普遍使用,不再限於原有的建築涵意,而「架構」(在論及系統時)和「系統架構」也出現許多的定義,例如:
「系統架構:按照系統元素、介面、流程、限制及行為所定義的基本和統一的系統結構。」
[標準定義已由 INCOSE Systems Architecture Working Group 於 1996/7/8 在美國波士頓舉行的 INCOSE '96 上審核通過]
「系統架構包含一個系統的主要實體內容、樣式、結構、互動及用途。」
[Process for System Architecture and Requirements Engineering, Derek Hatley, Peter Hruschka, Imtiaz
Pirbhai, Dorset House Publishing 2000]
「架構:定義系統組件的結構、語意行為及相互關係的概念與規則。包括由事物組成的元素、這些元素的關係、影響這些關係的限制、事物的局部焦點,以及事物的整體焦點。」
[Architecting with RM-ODP, Janis Putman, Prentice Hall PTR 2001,其中以 ISO/IEC 10746-2: Information Technology
- Open Distributed Processing - Reference Model: Foundations 為文獻參考出處]
「架構:程式/系統的元件結構、元件的相互關係,以及在設計和演進過程的控管原則和準則。」
[DoD 5000.59-P, "Modeling and Simulation Master Plan," October 1995]
架構是「元件的結構、關係,以及在設計和演進過程的控管原則和準則。」
[IEEE STD 610.12,由 C4ISR Integration Task Force (ITF) 的 Integrated Architectures Panel (IAP) 在 DoD Architecture
Framework, Version 1.0 中稍微擴大解釋]
各採用不同的單字和句法結構,且不是所有定義都確切指向同一觀點,更何況還有明顯的重疊。這些定義指出系統架構就是關於:
-
以元素、元件及組件來表達系統的結構
-
這些元素之間的關係
-
影響元素及其關係的限制
-
系統表現的行為,以及產生該行為之前在元素之間發生的互動
-
形成系統(及控管演進過程)的原則、規則及原理
-
系統的實體和邏輯特性與內容
-
系統的用途
因此,完整表達全部的層面需要豐富且複雜的資訊,但必須注意,並非所有關係人都需要同時瞭解所有層面。見解可以只針對某一類關係人積極參與議題所需的條件,清楚區隔這些不同的關切重點和表達方式。站在特定的見解角度來看,您也可以採取不同的「解析度」來觀察系統,從對應於高
抽象層次的低解析度,乃至於對應於具體實作規格(組件等)的高解析度。
見解
見解(在系統上)是「利用一組選定的架構概念和結構規則來達到的一種抽象形式,以便於強調系統內的特定議題」[ISO/IEC 10746-2: Information Technology - Open Distributed
Processing - Reference Model: Foundations]。下表列出一些用來擷取各項議題的見解。這些見解與 ISO/IEC 10746-1: Information technology - Open
Distributed Processing - Reference Model: Overview 的見解一致。
見解
|
關切重點
|
影響
|
工作者
|
關於組織和系統工作者的角色和責任(以及有影響力的原則)。
|
工作者活動、人與系統的互動。人員效能規格和人為因素。
|
資訊
|
系統處理的資訊類型,以及在資訊運用和解譯上的限制。
|
資訊完整性、容量限制。
資訊存取性、時效性。
|
邏輯
|
將系統分解成一群在介面上互動的子系統,這群子系統彼此合作以提供系統服務。
|
系統達到預期的表現。
可延伸、調整、維護系統。
可重複使用資產。
|
分佈/實體
|
支援系統功能和分佈所需的基礎架構。
|
系統實體特性實現功能和符合非功能面需求的適當性。
|
流程
|
並行性、延展性、效能、傳輸量、可靠性。
|
系統反應力、傳輸量、容錯的適當性。
|
常見系統見解。
這些見解是軟體密集系統中最常見的一些見解。許多系統架構還需要其他特定領域的見解。
例如安全性、機密性及機械方面的見解。見解代表在系統架構和設計中必須解決的不同關注議題。如果系統關係人或專家的考量對於整體架構很重要,則很可能需要一套見解工作成果來擷取設計決策。
系統架構團隊必須由有能力廣納不同見解的成員組成。該團隊的成員可能包括主要負責尋求工作者見解的業務分析師和使用者、專注於邏輯見解的軟體架構設計師、關心實體見解的工程師組成,以及專業領域見解的專家。
抽象層次
除了見解以外,系統架構還需要多層規格。架構會隨著開發而逐漸從一般、抽象的規格進化到更特殊、詳細的規格。RUP 提出四種架構層次,如下表所示。
模型層次
|
陳述
|
環境
|
系統及其參與者。
|
分析
|
初期分割系統以建立概念方法。
|
設計
|
將「分析模型」實現為硬體、軟體及人。
|
實作
|
將「設計模型」實現為特定配置。
|
RUP 架構層次
經過這幾層的洗禮,設計會從抽象轉化為實體。「環境模型」可擷取所有與系統互動的外部實體(參與者)。這些參與者可能在負責部署系統的企業之外,或在企業內部。不論何種情況,參與者可能是工作人員,也可能是其他系統。在「分析」層次上,分割無法反映硬體、軟體及人的選擇。相反地,分割只反映設計方法,只劃分系統必須做什麼及如何分配工作量。「設計」層次上會根據所需的軟硬體元件種類及工作者角色來制訂決策。「實作」層次上會決定選擇什麼軟硬體技術來實作設計。例如,在「設計」層次上可能指定資料伺服器。在「實作」層次上會決定採用特定的平台來執行特定的資料庫應用程式。
模型和圖解
模型是系統的一種表示法,通常在描述某些特定的關注議題。系統通常以一組模型來表達,因為系統的開發或用途上會許多考量。每一個模型可透過不同的抽象層次來建構,範圍包括最普通、隱匿或封閉的細節,乃至於最特殊、最詳細及最具體的設計決策。
顧名思義,見解是一種抽象的「立場」,以此呈現系統的一些層面或考量,意指運用一套概念和規則來形成概念性過濾條件。只是檢查真實系統通常不夠(不足以理解)—應該(或必須)建構模型來呈現和描述重要議題。
觀點是模型的意念投射,顯示在特定見解上的重要實體。這些意念投射通常以某種圖解來表達。
見解與抽象或具體模型層次的交集,包含(或至少指出)在此見解或議題的一或多個相關模型上,以該抽象層次所得的觀點。
系統架構是在一組模型上(及實際呈現模型的圖解上)擷取,可從各種不同的見解和層次來表達架構。從下列模型架構表可知,並非每一組見解-層次都有一個相對的模型/圖解。在「實作」層次上,單一模型可擷取每一種系統配置的軟硬體元件的實現結果。
模型層次
|
見解
|
工作者
|
邏輯
|
資訊
|
分佈/實體
|
流程
|
環境
|
UML 組織觀點
|
系統環境圖
|
企業資料觀點
|
企業位置觀點
|
商業流程觀點
|
分析
|
一般性系統工作者觀點
|
子系統觀點
|
系統資料觀點
|
系統位置觀點
|
系統流程觀點
|
設計
|
系統工作者觀點
|
子系統類別觀點
軟體元件觀點
|
系統資料綱目
|
描述子節點觀點
|
詳細流程觀點
|
實作
|
工作者角色規格與指示
|
配置:呈現軟硬體系統元件的部署圖。
|
表格中有許多觀點皆衍生自標準的 UML 模型。 例如,在「邏輯」見解的「分析」層次上,系統拆解成分工合作來滿足使用者需求的子系統。子系統採用 UML
標準的相同語意來表達。這些子系統又再拆解成子系統或(最終的)類別。「邏輯」見解的「設計」層次是詳細的「類別模型」觀點。「流程模型」也是標準的 UML
類別模型,但比較著重在系統的主動類別。特定領域的見解在一或多個層次上也需要有一些工作成果的觀點。在此架構內,專案工作成果必須是專案開發案例的一部份。
|