2011年軟考系統(tǒng)架構(gòu)設(shè)計(jì)師學(xué)習(xí)筆記第十四章
14.1 基于ODP的架構(gòu)開發(fā)過程
系統(tǒng)架構(gòu)反映了功能在系統(tǒng)系統(tǒng)構(gòu)件中的分布、基礎(chǔ)設(shè)施相關(guān)技術(shù)、架構(gòu)設(shè)計(jì)模式等，它包含了架構(gòu)的原則和方法、構(gòu)件關(guān)系與約束，并能支持迭加或增量開發(fā)。
以軟件架構(gòu)為中心的開發(fā)過程是以質(zhì)量和風(fēng)險(xiǎn)驅(qū)動(dòng)的，最終提供一個(gè)穩(wěn)定、低風(fēng)險(xiǎn)的系統(tǒng)架構(gòu)，并滿足客戶的需求(包含潛在需求)。
開放分布進(jìn)程的參考模型(RM-ODP)是一個(gè)ISO標(biāo)準(zhǔn)，定義了分布系統(tǒng)的重要性質(zhì)：
開放性、整體性、靈活性、可塑性、聯(lián)合性、可操作管理性、優(yōu)質(zhì)服務(wù)、安全性、透明性。
RM-ODP定義的 5個(gè)觀點(diǎn)：
1、企業(yè)視點(diǎn)：商業(yè)需求和策略、系統(tǒng)的范圍和目的?？赡軙?huì)影響系統(tǒng)中的與企業(yè)相關(guān)的信息，如組織結(jié)構(gòu)等。
2、信息視點(diǎn)。
3、計(jì)算視點(diǎn)。
4、工程視點(diǎn)。
5、技術(shù)視點(diǎn)。
每一個(gè)觀點(diǎn)有具體的建模目標(biāo)和系統(tǒng)相關(guān)者。
分層子系統(tǒng)視圖提供了一個(gè)所有子系統(tǒng)高度抽象的視圖。
14.2 系統(tǒng)構(gòu)想
14.2.1 系統(tǒng)構(gòu)想的定義
系統(tǒng)構(gòu)想是開發(fā)人員與用戶之間共同的協(xié)議。
按照該協(xié)議，開發(fā)人員需要在特定的時(shí)間內(nèi)完成系統(tǒng)用戶的需求，系統(tǒng)構(gòu)想必須簡(jiǎn)短而切中要點(diǎn)。
高度概括了業(yè)務(wù)架構(gòu)的核心內(nèi)容。
14.2.2 架構(gòu)師的作用
系統(tǒng)構(gòu)想有助于各方明了系統(tǒng)的目標(biāo)和范圍。
確保系統(tǒng)開發(fā)的計(jì)劃、設(shè)計(jì)等階段能依次有序地展開。
系統(tǒng)構(gòu)想階段，架構(gòu)師合理的介入，有以下好處：
1、有利于使系統(tǒng)架構(gòu)師本身對(duì)系統(tǒng)的看法更加全面、準(zhǔn)確。
2、統(tǒng)一系統(tǒng)開發(fā)人員對(duì)系統(tǒng)的看法。
3、正確確定需求的優(yōu)先次序。
4、***程度上提高客戶對(duì)設(shè)計(jì)等過程的參與程度，更好地與客戶溝通。
14.2.3 系統(tǒng)構(gòu)想面臨的挑戰(zhàn)
架構(gòu)師對(duì)其控制能力之外的因素通常無(wú)能為力，可以通過有效地評(píng)估，以及高級(jí)經(jīng)理和架構(gòu)師之間保持緊密的聯(lián)系克服這些困難。
還必須面對(duì)以下幾種情況：
1、很多架構(gòu)師把架構(gòu)看成是他們獨(dú)自的創(chuàng)造，只要他們認(rèn)為合適的就進(jìn)行修改。
2、有些人不是擁有產(chǎn)品線構(gòu)想的高級(jí)經(jīng)理，卻總是由這些人決定雇傭誰(shuí)來(lái)做架構(gòu)師。
14.3 需求分析
14.3.1 架構(gòu)師的工作
需求一般定義系統(tǒng)的外部行為和外觀以及用戶信息，而不用設(shè)計(jì)系統(tǒng)的內(nèi)部結(jié)構(gòu)。
對(duì)需求分析通?？疾煲韵?個(gè)方面的內(nèi)容：
1、系統(tǒng)范圍對(duì)象關(guān)系圖。
2、用戶接口原型，用戶操作的一個(gè)雛形。
3、需求的適用性，該用什么技術(shù)解決，性能怎么樣，是否與其他需求相重合或矛盾，需求分析應(yīng)注意需求本身的實(shí)用或適用，而不必考慮其實(shí)現(xiàn)。
4、確定需求的優(yōu)先級(jí)。
5、為需求建立功能結(jié)構(gòu)模型，組件圖，實(shí)體數(shù)據(jù)對(duì)象圖。
6、使用質(zhì)量功能分配(Quality Function Deploymen，QFD)發(fā)現(xiàn)隱藏質(zhì)量需求，建立相關(guān)質(zhì)量場(chǎng)景，先期預(yù)測(cè)需求風(fēng)險(xiǎn)。
有效地捕捉行為需求的方法是分析用例(Use Case)
用例包含圖和文字描述，符號(hào) 簡(jiǎn)單、抽象，保證表述需求時(shí)簡(jiǎn)單性和清晰度。
14.3.2 需求分析的任務(wù)
1、需求分析的目的
完整、準(zhǔn)確地描述用戶對(duì)系統(tǒng)的需求，跟蹤用戶需求的變化，準(zhǔn)確地反映到系統(tǒng)架構(gòu)和設(shè)計(jì)中，設(shè)計(jì)和用戶的需求保持一致。
具有決策性、方向性、策略性的作用。
2、需求分析的特點(diǎn)
追求系統(tǒng)需求的完整性、一致性、驗(yàn)證性。
保持和用戶要求同步，
保持需求分析各側(cè)面之間的一致，
保持需求和系統(tǒng)設(shè)計(jì)間的同步。
14.3.3 需求文檔與架構(gòu)
每個(gè)用例都有一個(gè)相關(guān)需求的文字描述，定義用例應(yīng)該和領(lǐng)域?qū)＜乙黄疬M(jìn)行，如果沒有領(lǐng)域?qū)＜业拈L(zhǎng)期參與，只能是一種“偽分析”。
用例為定義架構(gòu)提供了一個(gè)系統(tǒng)的領(lǐng)域行為模型。
界面的外觀、功能、導(dǎo)航同用例緊密相連，有效定義屏幕的方法叫低保真度原型(Low-fidelity Prototyping)，領(lǐng)域?qū)＜乙彩冀K參與到屏幕定義中去。
需求分析的項(xiàng)目詞匯表，也將在架構(gòu)規(guī)劃中被擴(kuò)展。
14.4 系統(tǒng)架構(gòu)設(shè)計(jì)
系統(tǒng)架構(gòu)溝通了需求和軟件之間巨大的語(yǔ)義上的鴻溝。
系統(tǒng)架構(gòu)的***個(gè)任務(wù)就是定義這兩個(gè)極端之間的映射。
開放分布式處理(Open Distributed Processing，ODP)包括企業(yè)、邏輯信息、計(jì)算接口、分布式工程、技術(shù)選擇。
對(duì)每個(gè)觀點(diǎn)，確認(rèn)架構(gòu)需求的一致性是非常重要的。
14.4.1 企業(yè)業(yè)務(wù)架構(gòu)
企業(yè)業(yè)務(wù)架構(gòu)從IT角度，對(duì)企業(yè)的業(yè)務(wù)結(jié)構(gòu)、企業(yè)機(jī)構(gòu)、業(yè)務(wù)的關(guān)系、內(nèi)部的關(guān)系、與外部機(jī)構(gòu)的關(guān)系進(jìn)行整理定義。
包含如下內(nèi)容：
1、企業(yè)的業(yè)務(wù)和戰(zhàn)略目標(biāo)，近期、中期、長(zhǎng)遠(yuǎn) 目標(biāo)。
2、企業(yè)的組織結(jié)構(gòu)。
3、業(yè)務(wù)的分類。
4、各類業(yè)務(wù)之間的關(guān)系。
5、組織機(jī)構(gòu)與業(yè)務(wù)的關(guān)系。
6、企業(yè)與外部機(jī)構(gòu)的關(guān)系。
這些業(yè)務(wù)對(duì)象模型標(biāo)識(shí)出系統(tǒng)的關(guān)鍵性約束，包括系統(tǒng)目標(biāo)和重要的系統(tǒng)策略。
策略包含如下三類明確的表達(dá)方式：
責(zé)任：業(yè)務(wù)對(duì)象必須做什么。
許可：業(yè)務(wù)對(duì)象可以做什么。
禁止：業(yè)務(wù)對(duì)象不可以做什么。
對(duì)業(yè)務(wù)問題進(jìn)行分析時(shí)，要考慮企業(yè)業(yè)務(wù)的發(fā)展，如新的服務(wù)或產(chǎn)品推出、考慮組織機(jī)構(gòu)的改變等。
所有這些可能的變化(易變場(chǎng)景)都應(yīng)該提現(xiàn)在企業(yè)業(yè)務(wù)架構(gòu)中。
通過對(duì)企業(yè)業(yè)務(wù)架構(gòu)的定義，很清楚地知道由于企業(yè)業(yè)務(wù)特點(diǎn)、業(yè)務(wù)的流程特點(diǎn)、企業(yè)的組織機(jī)構(gòu)等原因?qū)T系統(tǒng)所帶來(lái)的自然分塊和各個(gè)分塊之間的邊界關(guān)系。
企業(yè)業(yè)務(wù)架構(gòu)的維護(hù)是一個(gè)長(zhǎng)期而反復(fù)的工作。
測(cè)試結(jié)果報(bào)告系統(tǒng)(Test Results Reporting System，TRRS)。
對(duì)象約束語(yǔ)言(Object Constraint Language，OCL)來(lái)定義企業(yè)活動(dòng)者的這些策略(如 許可、禁止、義務(wù)等)。
14.4.2 邏輯信息架構(gòu)
邏輯信息架構(gòu)(信息視點(diǎn))標(biāo)識(shí)出系統(tǒng)必須知道什么。
強(qiáng)調(diào)定義系統(tǒng)狀態(tài)的屬性。
開放分布式處理是一種面向?qū)ο蟮姆椒?，模型包含了關(guān)鍵信息的處理，如傳統(tǒng)的對(duì)象概念。
軟件架構(gòu)對(duì)象并不是編程的對(duì)象，它表示對(duì)系統(tǒng)的約束和依賴，這些約束能夠消除把需求翻譯成軟件過程中的許多猜測(cè)性工作。
架構(gòu)師應(yīng)該把他們的建模集中于有高風(fēng)險(xiǎn)、高復(fù)雜性、模糊性的關(guān)鍵方面。
14.4.3 計(jì)算接口架構(gòu)
計(jì)算接口對(duì)系統(tǒng)架構(gòu)非常有幫助，但是它常常被架構(gòu)師所忽略。
消除多個(gè)開發(fā)者和小組的主要設(shè)計(jì)爭(zhēng)端，這些接口的架構(gòu)控制對(duì)于一個(gè)支持變化和控制復(fù)雜性的穩(wěn)定的系統(tǒng)結(jié)構(gòu)來(lái)說(shuō)，是非常重要的。
接口定義語(yǔ)言(IDL)，完全獨(dú)立于編程語(yǔ)言和操作系統(tǒng)。
14.4.4 分布式工程架構(gòu)
分布式工程架構(gòu)定義了底層結(jié)構(gòu)的需求，獨(dú)立于所選擇的技術(shù)，解決了最復(fù)雜的系統(tǒng)策略，包括物理位置、系統(tǒng)規(guī)?？勺冃浴⑼ㄐ欧?wù)質(zhì)量。
ODP的一個(gè)***好處是關(guān)注點(diǎn)分離。
14.4.5 技術(shù)選擇架構(gòu)
大多數(shù)架構(gòu)是獨(dú)立的。
基于對(duì)候選者的初始選擇，根據(jù)產(chǎn)品價(jià)格、培訓(xùn)要求、維護(hù)風(fēng)險(xiǎn)之類的項(xiàng)目因素而反復(fù)進(jìn)行。
14.5 實(shí)現(xiàn)模型
最終用戶和架構(gòu)師應(yīng)在一起審查并貫穿于用例，始終來(lái)證實(shí)需求的有效。
對(duì)產(chǎn)品設(shè)計(jì)的可行性做出準(zhǔn)確地評(píng)估、論證。
14.6 架構(gòu)原型
架構(gòu)原型是很好的需求驗(yàn)證工具，作為改進(jìn)設(shè)計(jì)的手段，確保與工程約束相一致。
下面是一些架構(gòu)師可以在架構(gòu)原型中尋求解答的具體問題：
1、主要組件是否得到了良好的定義?是否恰當(dāng)?
2、主要組件間的協(xié)作是否得到了良好的定義?
3、耦合是否得意最小化?
4、我們能否確定重用的潛在來(lái)源?
5、接口定義和各項(xiàng)約束是否可以接受?
6、每個(gè)模塊是否能訪問到其所需要的數(shù)據(jù)?
經(jīng)過2次或3次迭代之后，架構(gòu)變得穩(wěn)定。主要的抽象對(duì)象都已找到，子系統(tǒng)和過程都已經(jīng)完成，所有的接口都已明確定義。
利用架構(gòu)原型，幾個(gè)好處：
1、落實(shí)之前，讓團(tuán)隊(duì)成員能自由發(fā)表他們自己的看法。
2、統(tǒng)一團(tuán)隊(duì)之間的思想看法，提高系統(tǒng)開發(fā)的成功率。
3、對(duì)系統(tǒng)內(nèi)部的結(jié)構(gòu)分析與設(shè)計(jì)也有幫助。
14.7 項(xiàng)目規(guī)劃
項(xiàng)目規(guī)劃是通過批準(zhǔn)的正式文檔，以它為基準(zhǔn)跟蹤和控制項(xiàng)目，行動(dòng)方案和資源分配，引導(dǎo)項(xiàng)目實(shí)施。
主要作用是將指定規(guī)劃的假設(shè)和決定批準(zhǔn)的范圍、成本、進(jìn)度 的基線等用正式的文檔記錄保存。
估算是項(xiàng)目規(guī)劃的核心。
隨著項(xiàng)目的進(jìn)展，估算會(huì)不斷校正并逐漸地接近實(shí)際。
項(xiàng)目管理者通過計(jì)劃與規(guī)劃的差異，不斷優(yōu)化和更新計(jì)劃策略，使項(xiàng)目按規(guī)劃的要求得以實(shí)現(xiàn)，計(jì)劃的變更是可管理和可受控的。
規(guī)劃包括：
1、項(xiàng)目的目的、范圍、目標(biāo)、對(duì)象。
2、軟件生存周期 的選擇。
3、精選的規(guī)程、方法、標(biāo)準(zhǔn)。
4、待開發(fā)的軟件工作產(chǎn)品。
5、規(guī)模估計(jì)、軟件項(xiàng)目的工作量和成本估計(jì)。
6、關(guān)鍵計(jì)算機(jī)資源的估計(jì);項(xiàng)目的里程碑。
7、風(fēng)險(xiǎn)的識(shí)別和評(píng)估。
8、工程實(shí)施和支持工具計(jì)劃。
軟件項(xiàng)目計(jì)劃的目標(biāo)有：軟件估計(jì)被文檔化，活動(dòng)和約定形成文檔，受影響的組和個(gè)人認(rèn)同與軟件項(xiàng)目規(guī)劃的約定。
14.8 并行開發(fā)
14.8.1 軟件并行開發(fā)的內(nèi)容及意義
提高軟件生產(chǎn)率，改善軟件質(zhì)量，有效地組織可以重復(fù)的資源。
并行開發(fā)研究的內(nèi)容主要如下：
1、軟件過程及其模型。
2、并行分成劃分。
3、并行控制。
4、支持環(huán)境。
5、交互機(jī)制與集成技術(shù)。
14.8.2 并行開發(fā)的過程
把軟件系統(tǒng)的開發(fā)過程劃分為若干個(gè)可以并行的成分，這個(gè)成分稱之為子開發(fā)過程。
子開發(fā)過程 = 開發(fā)小組 + 軟件對(duì)象 + 對(duì)軟件對(duì)象的開發(fā)活動(dòng)。
并行開發(fā)活動(dòng)，稱為并行開發(fā)系統(tǒng)，實(shí)體是個(gè)開發(fā)小組，實(shí)體屬性是被開發(fā)的軟件對(duì)象，行為是開發(fā)軟件對(duì)象的活動(dòng)。
行為模塊的劃分是并行開發(fā)中的核心問題，模塊獨(dú)立性是衡量軟件設(shè)計(jì)質(zhì)量的關(guān)鍵。
系統(tǒng)劃分方法：
1、基于 Petri網(wǎng)系統(tǒng)模型的動(dòng)態(tài)劃分方法。
2、基于腳本的系統(tǒng)劃分方法。
軟件過程并行控制是一個(gè)非常重要的問題。
就是要用正確的方式調(diào)度并行操作，避免造成不一致性，使一個(gè)操作的執(zhí)行不受其他系統(tǒng)的干擾。
保證一致性、相容性、正確性、可靠性，手段有 加鎖、時(shí)間戳、管程、Petri 網(wǎng)、PV 操作等。
繼承和測(cè)試被分為兩個(gè)階段，如果不考慮硬件或軟件的集成，兩個(gè)階段并沒有明顯的界限，所以，軟件集成的主要問題是集成測(cè)試技術(shù)。
14.9 系統(tǒng)轉(zhuǎn)換
系統(tǒng)轉(zhuǎn)換是指運(yùn)用某一種方式由新的系統(tǒng)代替舊的系統(tǒng)的過程，也就是系統(tǒng)設(shè)備、數(shù)據(jù)、人員等方面的轉(zhuǎn)換。
14.9.1 系統(tǒng)轉(zhuǎn)換的準(zhǔn)備
轉(zhuǎn)換前，必須認(rèn)真做好準(zhǔn)備。
還需測(cè)試試運(yùn)行這項(xiàng)工作。
注意如下兩個(gè)問題：
1、系統(tǒng)試運(yùn)行工作的代表性。
2、系統(tǒng)試運(yùn)行中錯(cuò)誤的修正。
14.9.2 系統(tǒng)轉(zhuǎn)換的方式
直接轉(zhuǎn)換、平行轉(zhuǎn)換、分段轉(zhuǎn)換、分批轉(zhuǎn)換。
14.9.3 系統(tǒng)轉(zhuǎn)換的注意事項(xiàng)
1、大量的基礎(chǔ)數(shù)據(jù)，錄入工作量很大，應(yīng)及早準(zhǔn)備，盡快完成。
2、應(yīng)提前做好人員的培訓(xùn)工作。
3、出現(xiàn)一些局部性的問題，應(yīng)有足夠的準(zhǔn)備，并做好記錄。如果出現(xiàn)致命問題，要重新設(shè)計(jì)。
14.10 操作與維護(hù)
14.10.1 操作與維護(hù)的內(nèi)容
數(shù)據(jù)管理與維護(hù)。
設(shè)備管理與維護(hù)。
軟件的管理與維護(hù)工作。
14.10.2 系統(tǒng)維護(hù)與架構(gòu)
系統(tǒng)架構(gòu)的好壞，可維護(hù)性是一個(gè)重要方面，維護(hù)人員應(yīng)參與架構(gòu)的審評(píng)。
可維護(hù)性可以定性地定義為：維護(hù)人員 理解、改正、改動(dòng)、改進(jìn)的難易程度。
可維護(hù)性有如下幾個(gè)評(píng)價(jià)指標(biāo)：
可理解性。
可測(cè)試性。
可修改性。
系統(tǒng)維護(hù)工作可以分為以下4種類型：
更正性維護(hù)。
適應(yīng)性維護(hù)。
完善性維護(hù)。
預(yù)防性維護(hù)。
維護(hù)人員必須先理解要維護(hù)的系統(tǒng)，然后建立一個(gè)維護(hù)方案。
由于某處修改很可能會(huì)影響其他模塊程序，所以考慮的重要問題是修改的影響范圍和波及面的大小。
必須強(qiáng)調(diào)的是，維護(hù)是對(duì)整個(gè)系統(tǒng)而言的，必須同時(shí)修改涉及的所有文檔。
14.11 系統(tǒng)移植
14.11.1 系統(tǒng)移植的方式
不修改已有的軟件。
修改軟件。
重新編軟件。
14.11.2 系統(tǒng)移植的工作階段劃分
計(jì)劃階段。
準(zhǔn)備階段，準(zhǔn)備轉(zhuǎn)換所需的材料。
轉(zhuǎn)換階段。
測(cè)試階段。
驗(yàn)證階段。
使系統(tǒng)移植工作標(biāo)準(zhǔn)化，工具實(shí)現(xiàn)自動(dòng)化。
14.11.3 系統(tǒng)移植工具
系列化、標(biāo)準(zhǔn)化、文檔化，使任何人都能以相同的順序開展工作，提高效率。
【編輯推薦】
