第十四章? 基于ODP的架構(gòu)師實踐

14.1? 基于ODP的架構(gòu)開發(fā)過程

系統(tǒng)架構(gòu) 反映了功能在系統(tǒng)系統(tǒng)構(gòu)件中的 分布、基礎(chǔ)設施相關(guān)技術(shù)、架構(gòu)設計模式 等，它包含了架構(gòu)的 原則 和 方法、構(gòu)件關(guān)系 與 約束，并能支持 迭加或增量開發(fā)。

以軟件架構(gòu)為中心的開發(fā)過程是以 質(zhì)量 和 風險 驅(qū)動的，最終提供一個穩(wěn)定、低風險的 系統(tǒng)架構(gòu)，并滿足客戶的需求（包含潛在需求）。

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

開放性、整體性、靈活性、可塑性、聯(lián)合性、可操作管理性、優(yōu)質(zhì)服務、安全性、透明性。

RM-ODP定義的 5個觀點：

1、企業(yè)視點：商業(yè)需求 和 策略、系統(tǒng)的范圍 和 目的。可能會影響系統(tǒng)中的與企業(yè)相關(guān)的信息，如組織結(jié)構(gòu)等。

2、信息視點。

3、計算視點。

4、工程視點。

5、技術(shù)視點。

每一個觀點有具體的 建模目標 和 系統(tǒng)相關(guān)者。

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

14.2? 系統(tǒng)構(gòu)想

14.2.1? 系統(tǒng)構(gòu)想的定義

系統(tǒng)構(gòu)想 是 開發(fā)人員 與 用戶 之間 共同的協(xié)議。

按照該協(xié)議，開發(fā)人員需要在特定的時間內(nèi)完成系統(tǒng)用戶的需求，系統(tǒng)構(gòu)想必須 簡短而切中要點。

高度概括了 業(yè)務架構(gòu)的核心內(nèi)容。

14.2.2? 架構(gòu)師的作用

系統(tǒng)構(gòu)想 有助于 各方 明了系統(tǒng)的目標和范圍。

確保系統(tǒng)開發(fā)的 計劃、設計 等階段 能依次有序地展開。

系統(tǒng)構(gòu)想階段，架構(gòu)師合理的介入，有以下好處：

1、有利于使系統(tǒng)架構(gòu)師本身對系統(tǒng)的看法更加全面、準確。

2、統(tǒng)一系統(tǒng)開發(fā)人員對系統(tǒng)的看法。

3、正確確定需求的優(yōu)先次序。

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

14.2.3? 系統(tǒng)構(gòu)想面臨的挑戰(zhàn)

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

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

1、很多架構(gòu)師把架構(gòu)看成是他們獨自的創(chuàng)造，只要他們認為合適的就進行修改。

2、有些人不是擁有產(chǎn)品線構(gòu)想的高級經(jīng)理，卻總是由這些人決定雇傭誰來做架構(gòu)師。

14.3? 需求分析

14.3.1? 架構(gòu)師的工作

需求 一般定義系統(tǒng)的 外部行為 和 外觀 以及 用戶信息，而 不用設計系統(tǒng)的 內(nèi)部結(jié)構(gòu)。

對需求分析 通常考察以下 6個方面的內(nèi)容：

1、系統(tǒng)范圍對象關(guān)系圖。

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

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

4、確定需求的優(yōu)先級。

5、為需求建立功能結(jié)構(gòu)模型，組件圖，實體數(shù)據(jù)對象圖。

6、使用質(zhì)量功能分配（Quality Function Deploymen，QFD）發(fā)現(xiàn)隱藏質(zhì)量需求，建立相關(guān)質(zhì)量場景，先期預測需求風險。

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

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

14.3.2? 需求分析的任務

1、需求分析的目的

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

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

2、需求分析的特點

追求系統(tǒng)需求的 完整性、一致性、驗證性。

保持和用戶要求同步，

保持需求分析各側(cè)面之間的一致，

保持需求和系統(tǒng)設計間的同步。

14.3.3? 需求文檔與架構(gòu)

每個用例都有一個相關(guān)需求的文字描述，定義用例應該和領(lǐng)域?qū)＜乙黄疬M行，如果沒有領(lǐng)域?qū)＜业拈L期參與，只能是一種“偽分析”。

用例 為定義架構(gòu) 提供了一個 系統(tǒng)的領(lǐng)域行為模型。

界面的外觀、功能、導航 同用例緊密相連，有效定義屏幕的方法叫 低保真度原型（Low-fidelity Prototyping），領(lǐng)域?qū)＜乙彩冀K參與到屏幕定義中去。

需求分析的 項目詞匯表，也將在架構(gòu)規(guī)劃中被擴展。

14.4? 系統(tǒng)架構(gòu)設計

系統(tǒng)架構(gòu)溝通了 需求和軟件 之間巨大的 語義上 的 鴻溝。

系統(tǒng)架構(gòu)的第一個任務就是 定義這兩個極端之間的映射。

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

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

14.4.1? 企業(yè)業(yè)務架構(gòu)

企業(yè)業(yè)務架構(gòu) 從IT角度，對企業(yè)的 業(yè)務結(jié)構(gòu)、企業(yè)機構(gòu)、業(yè)務的關(guān)系、內(nèi)部的關(guān)系、與外部機構(gòu)的關(guān)系 進行整理定義。

包含如下內(nèi)容：

1、企業(yè)的業(yè)務和戰(zhàn)略目標，近期、中期、長遠 目標。

2、企業(yè)的組織結(jié)構(gòu)。

3、業(yè)務的分類。

4、各類業(yè)務之間的關(guān)系。

5、組織機構(gòu)與業(yè)務的關(guān)系。

6、企業(yè)與外部機構(gòu)的關(guān)系。

這些業(yè)務對象模型標識出系統(tǒng)的關(guān)鍵性約束，包括系統(tǒng)目標和重要的系統(tǒng)策略。

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

責任：業(yè)務對象必須做什么。

許可：業(yè)務對象可以做什么。

禁止：業(yè)務對象不可以做什么。

對業(yè)務問題進行分析時，要考慮企業(yè)業(yè)務的發(fā)展，如新的服務或產(chǎn)品推出、考慮組織機構(gòu)的改變 等。

所有這些可能的變化（易變場景）都應該提現(xiàn)在企業(yè)業(yè)務架構(gòu)中。

通過對企業(yè)業(yè)務架構(gòu)的定義，很清楚地知道由于企業(yè)業(yè)務特點、業(yè)務的流程特點、企業(yè)的組織機構(gòu) 等 原因 對IT系統(tǒng)所帶來的 自然分塊 和 各個分塊之間的邊界關(guān)系。

企業(yè)業(yè)務架構(gòu)的維護 是一個長期而反復的工作。

測試結(jié)果報告系統(tǒng)（Test Results Reporting System，TRRS）。

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

14.4.2? 邏輯信息架構(gòu)

邏輯信息架構(gòu)（信息視點）標識出 系統(tǒng)必須知道什么。

強調(diào)定義系統(tǒng)狀態(tài)的屬性。

開放分布式處理是一種面向?qū)ο蟮姆椒?#xff0c;模型包含了關(guān)鍵信息的處理，如 傳統(tǒng)的對象概念。

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

架構(gòu)師應該 把他們的建模 集中于 有高風險、高復雜性、模糊性 的關(guān)鍵方面。

14.4.3? 計算接口架構(gòu)

計算接口對系統(tǒng)架構(gòu)非常有幫助，但是它常常被架構(gòu)師所忽略。

消除多個開發(fā)者和小組的主要設計爭端，這些接口的架構(gòu)控制對于一個支持變化和控制復雜性的穩(wěn)定的系統(tǒng)結(jié)構(gòu)來說，是非常重要的。

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

14.4.4? 分布式工程架構(gòu)

分布式工程架構(gòu) 定義了 底層結(jié)構(gòu)的需求，獨立于所選擇的技術(shù)，解決了 最復雜的系統(tǒng)策略，包括 物理位置、系統(tǒng)規(guī)模可變性、通信服務質(zhì)量。

ODP的一個最大好處是 關(guān)注點分離。

14.4.5? 技術(shù)選擇架構(gòu)

大多數(shù)架構(gòu)是獨立的。

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

14.5? 實現(xiàn)模型

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

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

14.6? 架構(gòu)原型

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

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

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

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

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

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

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

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

經(jīng)過2次或3次迭代之后，架構(gòu)變得穩(wěn)定。主要的抽象對象都已找到，子系統(tǒng)和過程都已經(jīng)完成，所有的接口都已明確定義。

利用架構(gòu)原型，幾個好處：

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

2、統(tǒng)一團隊之間的思想看法，提高系統(tǒng)開發(fā)的成功率。

3、對系統(tǒng)內(nèi)部的結(jié)構(gòu)分析與設計也有幫助。

14.7? 項目規(guī)劃

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

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

估算是項目規(guī)劃的核心。

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

項目管理者通過計劃與規(guī)劃的差異，不斷優(yōu)化和更新計劃策略，使項目按規(guī)劃的要求得以實現(xiàn)，計劃的變更是可管理和可受控的。

規(guī)劃包括：

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

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

3、精選的 規(guī)程、方法、標準。

4、待開發(fā)的軟件工作產(chǎn)品。

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

6、關(guān)鍵計算機資源的估計；項目的里程碑。

7、風險的識別和評估。

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

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

14.8? 并行開發(fā)

14.8.1? 軟件并行開發(fā)的內(nèi)容及意義

提高軟件生產(chǎn)率，改善軟件質(zhì)量，有效地組織可以重復的資源。

并行開發(fā)研究的內(nèi)容主要如下：

1、軟件過程及其模型。

2、并行分成劃分。

3、并行控制。

4、支持環(huán)境。

5、交互機制與集成技術(shù)。

14.8.2? 并行開發(fā)的過程

把軟件系統(tǒng)的開發(fā)過程劃分為若干個 可以并行的成分，這個成分稱之為 子開發(fā)過程。

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

并行開發(fā)活動，稱為并行開發(fā)系統(tǒng)，實體是個開發(fā)小組，實體屬性是被開發(fā)的軟件對象，行為是開發(fā)軟件對象的活動。

行為模塊的 劃分 是并行開發(fā)中的核心問題，模塊獨立性是 衡量軟件設計質(zhì)量的關(guān)鍵。

系統(tǒng)劃分方法：

1、基于 Petri網(wǎng)系統(tǒng)模型的動態(tài)劃分方法。

2、基于腳本的系統(tǒng)劃分方法。

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

就是要用正確的方式 調(diào)度并行操作，避免造成不一致性，使一個操作的執(zhí)行不受其他系統(tǒng)的干擾。

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

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

14.9 系統(tǒng)轉(zhuǎn)換

系統(tǒng)轉(zhuǎn)換是指 運用某一種方式 由新的系統(tǒng)代替舊的系統(tǒng)的過程，也就是系統(tǒng) 設備、數(shù)據(jù)、人員 等方面的 轉(zhuǎn)換。

14.9.1? 系統(tǒng)轉(zhuǎn)換的準備

轉(zhuǎn)換前，必須認真做好準備。

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

注意如下兩個問題：

1、系統(tǒng)試運行工作的代表性。

2、系統(tǒng)試運行中錯誤的修正。

14.9.2? 系統(tǒng)轉(zhuǎn)換的方式

直接轉(zhuǎn)換、平行轉(zhuǎn)換、分段轉(zhuǎn)換、分批轉(zhuǎn)換。

14.9.3? 系統(tǒng)轉(zhuǎn)換的注意事項

1、大量的基礎(chǔ)數(shù)據(jù)，錄入工作量很大，應及早準備，盡快完成。

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

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

14.10? 操作與維護

14.10.1? 操作與維護的內(nèi)容

數(shù)據(jù)管理與維護。

設備管理與維護。

軟件的管理與維護工作。

14.10.2? 系統(tǒng)維護與架構(gòu)

系統(tǒng)架構(gòu)的好壞，可維護性是一個重要方面，維護人員應參與架構(gòu)的審評。

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

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

可理解性。

可測試性。

可修改性。

系統(tǒng)維護工作可以分為以下 4種類型：

更正性維護。

適應性維護。

完善性維護。

預防性維護。

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

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

必須強調(diào)的是，維護是對整個系統(tǒng)而言的，必須同時修改涉及的所有文檔。

14.11? 系統(tǒng)移植

14.11.1? 系統(tǒng)移植的方式

不修改已有的軟件。

修改軟件。

重新編軟件。

14.11.2? 系統(tǒng)移植的工作階段劃分

計劃階段。

準備階段，準備轉(zhuǎn)換所需的材料。

轉(zhuǎn)換階段。

測試階段。

驗證階段。

使系統(tǒng)移植工作標準化，工具實現(xiàn)自動化。

14.11.3? 系統(tǒng)移植工具

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

轉(zhuǎn)載于:https://www.cnblogs.com/hack/archive/2010/08/25/1808561.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。