2011年軟考系統架構設計師學習筆記第十四章
14.1 基于ODP的架構開發過程
系統架構反映了功能在系統系統構件中的分布、基礎設施相關技術、架構設計模式等，它包含了架構的原則和方法、構件關系與約束，并能支持迭加或增量開發。
以軟件架構為中心的開發過程是以質量和風險驅動的，最終提供一個穩定、低風險的系統架構，并滿足客戶的需求(包含潛在需求)。
開放分布進程的參考模型(RM-ODP)是一個ISO標準，定義了分布系統的重要性質：
開放性、整體性、靈活性、可塑性、聯合性、可操作管理性、優質服務、安全性、透明性。
RM-ODP定義的 5個觀點：
1、企業視點：商業需求和策略、系統的范圍和目的?？赡軙绊懴到y中的與企業相關的信息，如組織結構等。
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 架構師的工作
需求一般定義系統的外部行為和外觀以及用戶信息，而不用設計系統的內部結構。
對需求分析通?？疾煲韵?個方面的內容：
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 系統移植工具
系列化、標準化、文檔化，使任何人都能以相同的順序開展工作，提高效率。
【編輯推薦】
