第十四章? 基于ODP的架構師實踐

14.1? 基于ODP的架構開發過程

系統架構 反映了功能在系統系統構件中的 分布、基礎設施相關技術、架構設計模式 等，它包含了架構的 原則 和 方法、構件關系 與 約束，并能支持 迭加或增量開發。

以軟件架構為中心的開發過程是以 質量 和 風險 驅動的，最終提供一個穩定、低風險的 系統架構，并滿足客戶的需求（包含潛在需求）。

開放分布進程的參考模型（RM-ODP）是一個ISO標準，定義了分布系統的重要性質：

開放性、整體性、靈活性、可塑性、聯合性、可操作管理性、優質服務、安全性、透明性。

RM-ODP定義的 5個觀點：

1、企業視點：商業需求 和 策略、系統的范圍 和 目的。可能會影響系統中的與企業相關的信息，如組織結構等。

2、信息視點。

3、計算視點。

4、工程視點。

5、技術視點。

每一個觀點有具體的 建模目標 和 系統相關者。

分層子系統視圖 提供了一個所有子系統高度抽象的 視圖。

14.2? 系統構想

14.2.1? 系統構想的定義

系統構想 是 開發人員 與 用戶 之間 共同的協議。

按照該協議，開發人員需要在特定的時間內完成系統用戶的需求，系統構想必須 簡短而切中要點。

高度概括了 業務架構的核心內容。

14.2.2? 架構師的作用

系統構想 有助于 各方 明了系統的目標和范圍。

確保系統開發的 計劃、設計 等階段 能依次有序地展開。

系統構想階段，架構師合理的介入，有以下好處：

1、有利于使系統架構師本身對系統的看法更加全面、準確。

2、統一系統開發人員對系統的看法。

3、正確確定需求的優先次序。

4、最大程度上提高客戶對設計等過程的參與程度，更好地與客戶溝通。

14.2.3? 系統構想面臨的挑戰

架構師對其控制能力之外的因素通常無能為力，可以通過有效地評估，以及高級經理和架構師之間保持緊密的聯系 克服這些困難。

還必須面對以下幾種情況：

1、很多架構師把架構看成是他們獨自的創造，只要他們認為合適的就進行修改。

2、有些人不是擁有產品線構想的高級經理，卻總是由這些人決定雇傭誰來做架構師。

14.3? 需求分析

14.3.1? 架構師的工作

需求 一般定義系統的 外部行為 和 外觀 以及 用戶信息，而 不用設計系統的 內部結構。

對需求分析 通常考察以下 6個方面的內容：

1、系統范圍對象關系圖。

2、用戶接口原型，用戶操作的一個雛形。

3、需求的適用性，該用什么技術解決，性能怎么樣，是否與其他需求 相重合 或 矛盾，需求分析應注意 需求本身的實用或適用，而不必考慮其實現。

4、確定需求的優先級。

5、為需求建立功能結構模型，組件圖，實體數據對象圖。

6、使用質量功能分配（Quality Function Deploymen，QFD）發現隱藏質量需求，建立相關質量場景，先期預測需求風險。

有效地捕捉行為需求的方法是分析用例（Use Case）

用例包含 圖 和 文字描述，符號 簡單、抽象，保證 表述 需求時 簡單性 和 清晰度。

14.3.2? 需求分析的任務

1、需求分析的目的

完整、準確 地 描述用戶對系統的需求，跟蹤用戶需求的變化，準確地 反映到系統架構和設計中，設計和用戶的需求保持一致。

具有決策性、方向性、策略性 的作用。

2、需求分析的特點

追求系統需求的 完整性、一致性、驗證性。

保持和用戶要求同步，

保持需求分析各側面之間的一致，

保持需求和系統設計間的同步。

14.3.3? 需求文檔與架構

每個用例都有一個相關需求的文字描述，定義用例應該和領域專家一起進行，如果沒有領域專家的長期參與，只能是一種“偽分析”。

用例 為定義架構 提供了一個 系統的領域行為模型。

界面的外觀、功能、導航 同用例緊密相連，有效定義屏幕的方法叫 低保真度原型（Low-fidelity Prototyping），領域專家也始終參與到屏幕定義中去。

需求分析的 項目詞匯表，也將在架構規劃中被擴展。

14.4? 系統架構設計

系統架構溝通了 需求和軟件 之間巨大的 語義上 的 鴻溝。

系統架構的第一個任務就是 定義這兩個極端之間的映射。

開放分布式處理（Open Distributed Processing，ODP）包括 企業、邏輯信息、計算接口、分布式工程、技術選擇。

對每個觀點，確認架構需求的一致性是非常重要的。

14.4.1? 企業業務架構

企業業務架構 從IT角度，對企業的 業務結構、企業機構、業務的關系、內部的關系、與外部機構的關系 進行整理定義。

包含如下內容：

1、企業的業務和戰略目標，近期、中期、長遠 目標。

2、企業的組織結構。

3、業務的分類。

4、各類業務之間的關系。

5、組織機構與業務的關系。

6、企業與外部機構的關系。

這些業務對象模型標識出系統的關鍵性約束，包括系統目標和重要的系統策略。

策略包含如下三類明確的表達方式：

責任：業務對象必須做什么。

許可：業務對象可以做什么。

禁止：業務對象不可以做什么。

對業務問題進行分析時，要考慮企業業務的發展，如新的服務或產品推出、考慮組織機構的改變 等。

所有這些可能的變化（易變場景）都應該提現在企業業務架構中。

通過對企業業務架構的定義，很清楚地知道由于企業業務特點、業務的流程特點、企業的組織機構 等 原因 對IT系統所帶來的 自然分塊 和 各個分塊之間的邊界關系。

企業業務架構的維護 是一個長期而反復的工作。

測試結果報告系統（Test Results Reporting System，TRRS）。

對象約束語言（Object Constraint Language，OCL）來定義企業活動者的這些策略（如 許可、禁止、義務 等）。

14.4.2? 邏輯信息架構

邏輯信息架構（信息視點）標識出 系統必須知道什么。

強調定義系統狀態的屬性。

開放分布式處理是一種面向對象的方法，模型包含了關鍵信息的處理，如 傳統的對象概念。

軟件架構對象 并不是編程的 對象，它表示對系統的約束和依賴，這些約束能夠消除把需求翻譯成軟件過程中的許多猜測性工作。

架構師應該 把他們的建模 集中于 有高風險、高復雜性、模糊性 的關鍵方面。

14.4.3? 計算接口架構

計算接口對系統架構非常有幫助，但是它常常被架構師所忽略。

消除多個開發者和小組的主要設計爭端，這些接口的架構控制對于一個支持變化和控制復雜性的穩定的系統結構來說，是非常重要的。

接口定義語言（IDL），完全獨立于編程語言和操作系統。

14.4.4? 分布式工程架構

分布式工程架構 定義了 底層結構的需求，獨立于所選擇的技術，解決了 最復雜的系統策略，包括 物理位置、系統規模可變性、通信服務質量。

ODP的一個最大好處是 關注點分離。

14.4.5? 技術選擇架構

大多數架構是獨立的。

基于對候選者的初始選擇，根據 產品價格、培訓要求、維護風險 之類的項目因素 而反復進行。

14.5? 實現模型

最終用戶和架構師應在一起審查并貫穿于用例，始終 來證實需求的有效。

對產品設計的可行性做出準確地 評估、論證。

14.6? 架構原型

架構原型是很好的需求驗證工具，作為改進設計的手段，確保與工程約束相一致。

下面是一些架構師可以在架構原型中尋求解答的具體問題：

1、主要組件 是否得到了良好的定義？是否恰當？

2、主要組件間的協作 是否得到了良好的定義？

3、耦合是否得意最小化？

4、我們能否確定重用的潛在來源？

5、接口定義和各項約束是否可以接受？

6、每個模塊 是否能訪問到其所需要的數據？

經過2次或3次迭代之后，架構變得穩定。主要的抽象對象都已找到，子系統和過程都已經完成，所有的接口都已明確定義。

利用架構原型，幾個好處：

1、落實之前，讓團隊成員能自由發表他們自己的看法。

2、統一團隊之間的思想看法，提高系統開發的成功率。

3、對系統內部的結構分析與設計也有幫助。

14.7? 項目規劃

項目規劃是通過批準的正式文檔，以它為基準跟蹤和控制項目，行動方案 和 資源分配，引導項目實施。

主要作用是 將指定規劃的 假設 和 決定 批準的范圍、成本、進度 的基線等 用正式的文檔記錄保存。

估算是項目規劃的核心。

隨著項目的進展，估算會不斷校正并逐漸地接近實際。

項目管理者通過計劃與規劃的差異，不斷優化和更新計劃策略，使項目按規劃的要求得以實現，計劃的變更是可管理和可受控的。

規劃包括：

1、項目的 目的、范圍、目標、對象。

2、軟件生存周期 的選擇。

3、精選的 規程、方法、標準。

4、待開發的軟件工作產品。

5、規模估計、軟件項目的工作量和成本估計。

6、關鍵計算機資源的估計；項目的里程碑。

7、風險的識別和評估。

8、工程實施和支持工具計劃。

軟件項目計劃的目標有：軟件估計被文檔化，活動和約定形成文檔，受影響的組和個人 認同與軟件項目規劃的約定。

14.8? 并行開發

14.8.1? 軟件并行開發的內容及意義

提高軟件生產率，改善軟件質量，有效地組織可以重復的資源。

并行開發研究的內容主要如下：

1、軟件過程及其模型。

2、并行分成劃分。

3、并行控制。

4、支持環境。

5、交互機制與集成技術。

14.8.2? 并行開發的過程

把軟件系統的開發過程劃分為若干個 可以并行的成分，這個成分稱之為 子開發過程。

子開發過程 = 開發小組 + 軟件對象 + 對軟件對象的開發活動。

并行開發活動，稱為并行開發系統，實體是個開發小組，實體屬性是被開發的軟件對象，行為是開發軟件對象的活動。

行為模塊的 劃分 是并行開發中的核心問題，模塊獨立性是 衡量軟件設計質量的關鍵。

系統劃分方法：

1、基于 Petri網系統模型的動態劃分方法。

2、基于腳本的系統劃分方法。

軟件過程并行控制是一個非常重要的問題。

就是要用正確的方式 調度并行操作，避免造成不一致性，使一個操作的執行不受其他系統的干擾。

保證 一致性、相容性、正確性、可靠性，手段有 加鎖、時間戳、管程、Petri 網、PV 操作 等。

繼承 和 測試 被分為兩個階段，如果不考慮硬件或軟件的集成，兩個階段并沒有明顯的界限，所以，軟件集成的主要問題是 集成測試技術。

14.9 系統轉換

系統轉換是指 運用某一種方式 由新的系統代替舊的系統的過程，也就是系統 設備、數據、人員 等方面的 轉換。

14.9.1? 系統轉換的準備

轉換前，必須認真做好準備。

還需測試 試運行 這項工作。

注意如下兩個問題：

1、系統試運行工作的代表性。

2、系統試運行中錯誤的修正。

14.9.2? 系統轉換的方式

直接轉換、平行轉換、分段轉換、分批轉換。

14.9.3? 系統轉換的注意事項

1、大量的基礎數據，錄入工作量很大，應及早準備，盡快完成。

2、應提前做好人員的培訓工作。

3、出現一些局部性的問題，應有 足夠的準備，并做好記錄。如果出現致命問題，要重新設計。

14.10? 操作與維護

14.10.1? 操作與維護的內容

數據管理與維護。

設備管理與維護。

軟件的管理與維護工作。

14.10.2? 系統維護與架構

系統架構的好壞，可維護性是一個重要方面，維護人員應參與架構的審評。

可維護性可以定性地定義為：維護人員 理解、改正、改動、改進 的難易程度。

可維護性有如下幾個評價指標：

可理解性。

可測試性。

可修改性。

系統維護工作可以分為以下 4種類型：

更正性維護。

適應性維護。

完善性維護。

預防性維護。

維護人員必須先理解要維護的系統，然后建立一個維護方案。

由于某處修改很可能會影響其他模塊程序，所以考慮的重要問題 是 修改的影響范圍 和 波及面 的大小。

必須強調的是，維護是對整個系統而言的，必須同時修改涉及的所有文檔。

14.11? 系統移植

14.11.1? 系統移植的方式

不修改已有的軟件。

修改軟件。

重新編軟件。

14.11.2? 系統移植的工作階段劃分

計劃階段。

準備階段，準備轉換所需的材料。

轉換階段。

測試階段。

驗證階段。

使系統移植工作標準化，工具實現自動化。

14.11.3? 系統移植工具

系列化、標準化、文檔化，使任何人都能以相同的順序開展工作，提高效率。

轉載于:https://www.cnblogs.com/hack/archive/2010/08/25/1808561.html

總結

以上是生活随笔為你收集整理的系统架构师学习笔记_第十四章_连载的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。