帶有 層次的元件型 架構
「元件架構」是一種以概念:元件中所說明的可替換元件為基礎的架構。因為「元件架構」是以獨立、可替換、模組化的元件為基礎,所以有助於管理複雜度並鼓勵重複使用。
使用案例在整個生命週期端對端驅動 Rational Unified Process (RUP),但設計活動是以系統架構及(採用大量軟體的系統)軟體架構的概念為中心。流程反覆初期(主要為詳述階段)的主要重心在於產生及驗證軟體結構,這在起始開發週期時為執行檔架構原型,並於反覆的後期階段逐漸形成最終系統。
這裡所指的執行檔架構是指專為展示選取的系統功能及內容所建置的系統的局部實作,特別是那些令人滿意的非功能性的需求。執行檔架構的目的在於降低與效能、傳輸量、容量、可靠性及其他「功能」相關的風險,以便系統的完整功能性功能可確實增加至結構階段,而不必擔心損毀。
如需架構的概念(特別是軟體架構)及其重要的原因的說明,請參閱概念:軟體架構。
RUP 以一種有條理、系統化的方法,設計、開發及驗證架構。我們提供範本以針對多重架構觀點的概念進行架構化的說明,以及擷取架構樣式、設計規則及限制。分析與設計規範內含特定活動,這些活動以識別架構化限制和對架構很重要的元素為目標,以及如何進行架構選擇的準則。管理流程顯示反覆初期的計劃,如何將架構的設定及主要技術風險的解決方法納入考量。如需詳細資訊,請參閱專案管理規範,及所有與角色:軟體架構相關的活動。
架構的重要性如下:
-
可讓您得到並保留對專案的理解性控制權,以管理其複雜性及維持系統完整性。
複雜的系統不只是其各部份的總和,也不只是一系列較小的獨立策略決策。而是必須有某種程度的一致、連貫結構,以有系統地組織其各部位,且必須提供系統成長精確的規則,以避免其複雜性超越人們可理解的範圍。
架構建立一組共同的參照(即用以討論設計問題的共同般詞彙),以便強化專案期間的溝通與彼此的瞭解。
架構清楚地說明主要元件及元件之間的重要介面,以讓您理解重複使用的原因,包括內部重複使用(識別共同部份)及外部重複使用(結合已就緒的現成元件)。然而,您也可以進行大規模的重複使用:在同一領域中解決不同功能問題的產品的環境下,重複使用架構。
規劃及人員配置是依據主要元件加以組織。基本的架構決策是由小型、一致(未被分散)的架構團隊所決定。開發程序經由一組小型團隊的分割,每一組都負責系統的一或多個部份。
元件式開發是從一般應用程式開發延伸的一個派別,其中:
-
應用程式是從各別的可執行元件建置,這些元件彼此獨立開發,可能由不同的團隊負責。這些元件在 RUP 中被稱為「組合元件」。如需詳細定義,請參閱概念:元件。
-
應用程式可以採取較小幅度的升級,僅升級構成應用程式的部份組合元件。
-
應用程式可以共用組合元件,建立重複使用的機會,但也會產生專案間的相依關係。
-
分散式不一定就是元件式,但元件式應用程式通常是分散式。
組合元件是由下列所產生的:
-
於定義模組化的架構時,您要識別、隔離、設計、開發及測試形式完整的元件。這些元件可經由個別測試並逐步整合以形成完整的系統。
-
此外,部份元件也可開發成可重複使用,特別是那些提供各種共同問題之共同解決方法的元件。這些可重複使用的元件(可能比公用程式或類別程式庫的集合還大),是組織內部重複使用的基礎,以提高整體軟體生產力及品質。
-
最近十分成功的元件基礎架構(例如 CORBA、Internet、ActiveX、JavaBeans、.NET 及 J2EE)引發適用於各種領域的現成可用元件產業的興起,您只需要購買並整合元件,不需要實際進行開發的工作。
前述清單中的第一個點利用模組化與封裝的原有概念,並進一步延伸物件導向技術(此概念的基礎)。最後兩個點則是將軟體開發(一次僅一條線)從程式設計軟體,轉為利用組合元件的方式組成軟體。
RUP 支援元件型開發的方式如下:
-
反覆方法 (iterative approach) 可讓您逐漸識別元件,並決定要開發、重複使用及購買哪些元件。
-
將重心放在軟體架構,您就可以詳細描述架構(元件以及元件整合的方式)包括主要的機制及互動的方式。這麼做可支援專案開發的規畫層面,因為元件的相依關係有助於判斷哪些元件可以同時開發,以及可以相繼開發哪些元件。
-
分析 & 設計階段將利用套件、子系統及層次等概念,以組織元件及指定介面。
-
測試一開始是根據元件組織,然後再逐漸根據較大的整合元件集合。
如需有關元件的詳細資訊,請參閱概念:元件。
|