系統(tǒng)集成,項(xiàng)目管理工程師,系統(tǒng)集成技術(shù)知識(shí)

1系統(tǒng)集成項(xiàng)目管理工程師

串講2上午題：選擇題基礎(chǔ)知識(shí)150分鐘下午題：?jiǎn)柎痤}案例分析150分鐘考試科目分析3歷年考試情況分析-基礎(chǔ)知識(shí)歷年考試情況所屬學(xué)科2009.052009.11平均比例信息化知識(shí)454.56.00%信息系統(tǒng)服務(wù)管理423.04.00%信息系統(tǒng)集成技術(shù)專業(yè)知識(shí)141514.519.33%項(xiàng)目管理一般知識(shí)433.54.67%立項(xiàng)管理433.54.67%項(xiàng)目整體管理523.54.67%項(xiàng)目范圍管理433.54.67%項(xiàng)目時(shí)間管理666.08.00%項(xiàng)目成本管理031.52.00%項(xiàng)目質(zhì)量管理042.02.67%項(xiàng)目人力資源管理444.05.33%項(xiàng)目溝通管理010.50.67%項(xiàng)目采購(gòu)管理777.09.33%項(xiàng)目風(fēng)險(xiǎn)管理333.04.00%文檔與配置管理735.06.67%信息系統(tǒng)安全管理142.53.33%法律法規(guī)和標(biāo)準(zhǔn)規(guī)范322.53.33%專業(yè)英語(yǔ)555.06.67%4軟件的定義軟件（

Software）是計(jì)算機(jī)系統(tǒng)中與硬件相互依存的另一部分，它是包括程序（Program）

，數(shù)據(jù)（Data）及其相關(guān)文檔（Document）的完整集合。Software=Program+Data+Document程序是按事先設(shè)計(jì)的功能和性能要求執(zhí)行的指令序列數(shù)據(jù)是使程序能正常操縱信息的數(shù)據(jù)結(jié)構(gòu)文檔是與程序開(kāi)發(fā)，維護(hù)和使用有關(guān)的圖文材料5軟件危機(jī)的表現(xiàn)軟件成本高逐漸增高計(jì)算機(jī)軟件和硬件費(fèi)用比逐漸增大軟件質(zhì)量得不到保證由于軟件質(zhì)量問(wèn)題導(dǎo)致失敗的軟件項(xiàng)目非常多進(jìn)度難以控制維護(hù)非常困難6軟件工程定義總之：軟件工程是應(yīng)用計(jì)算機(jī)科學(xué)、數(shù)學(xué)及管理科學(xué)等原理開(kāi)發(fā)軟件的工程。它借鑒傳統(tǒng)工程的原則、方法，以提高質(zhì)量，降低成本為目的。7軟件生命周期模型問(wèn)題定義軟件定義可行性研究

需求分析

總體設(shè)計(jì)詳細(xì)設(shè)計(jì)軟件生命周期軟件開(kāi)發(fā)編碼單元測(cè)試綜合測(cè)試運(yùn)行維護(hù)

持久滿足用戶需求8軟件過(guò)程模型

軟件生命周期的每一階段都有明確的任務(wù)，把規(guī)模大、結(jié)構(gòu)復(fù)雜、管理復(fù)雜的軟件開(kāi)發(fā)變得容易控制和管理。各個(gè)階段的活動(dòng)如何銜接，開(kāi)發(fā)過(guò)程中采用什么樣的策略，應(yīng)遵守什么樣的規(guī)定和制約，將這些活動(dòng)框架（忽略不必要的細(xì)節(jié)）用一種模型表示出來(lái)，稱為軟件過(guò)程模型（或軟件開(kāi)發(fā)模型或軟件生命周期模型）。

也就是說(shuō)，

軟件過(guò)程模型是軟件開(kāi)發(fā)全部過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架。9瀑布模型(WaterfallModel）10實(shí)際的瀑布模型11面向?qū)ο竽Ｐ汀?/p>

噴泉模型分析設(shè)計(jì)實(shí)現(xiàn)測(cè)試集成演化特點(diǎn)：主要用于支持面向?qū)ο箝_(kāi)發(fā)過(guò)程體現(xiàn)了軟件創(chuàng)建所固有的迭代和無(wú)間隙的特征12螺旋模型13統(tǒng)一軟件開(kāi)發(fā)過(guò)程RUP每個(gè)周期劃分為初始、細(xì)化、構(gòu)造和移交四個(gè)階段，每個(gè)階段圍繞著五個(gè)核心工作流（需求、分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試）分別迭代。14RUP的特點(diǎn)

初始階段：進(jìn)行問(wèn)題定義，確定目標(biāo)，評(píng)估其可行性，降低關(guān)鍵風(fēng)險(xiǎn)。

細(xì)化階段：制定項(xiàng)目計(jì)劃、配置各類資源、建立系統(tǒng)架構(gòu)（包括各類視圖）。

構(gòu)造階段：開(kāi)發(fā)整個(gè)產(chǎn)品，并確保產(chǎn)品可移交給用戶

移交階段：產(chǎn)品發(fā)布、安裝、用戶培訓(xùn)。不同階段工作流的側(cè)重點(diǎn)不同，前兩階段大部分工作集中在需求、分析和架構(gòu)設(shè)計(jì)上；在構(gòu)造階段，重點(diǎn)轉(zhuǎn)移到詳細(xì)設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試上。15現(xiàn)有的軟件開(kāi)發(fā)方法大致可分為兩類：重型軟件開(kāi)發(fā)方法和輕型軟件開(kāi)發(fā)方法。重型軟件開(kāi)發(fā)方法一般具有嚴(yán)格和詳盡的軟件開(kāi)發(fā)過(guò)程，軟件開(kāi)發(fā)需產(chǎn)生大量的文檔。輕型軟件開(kāi)發(fā)方法則強(qiáng)調(diào)軟件開(kāi)發(fā)過(guò)程的簡(jiǎn)潔性和靈活性，軟件開(kāi)發(fā)只需編寫(xiě)少量的文檔。極限編程簡(jiǎn)介16敏捷思想敏捷軟件開(kāi)發(fā)是一類輕型的軟件開(kāi)發(fā)方法，它提供了一組思想和策略來(lái)指導(dǎo)軟件系統(tǒng)的快速開(kāi)發(fā)并響應(yīng)用戶需求的變化。不同于已有的其它軟件開(kāi)發(fā)方法，該方法對(duì)軟件開(kāi)發(fā)具有以下四個(gè)方面的基本認(rèn)識(shí)：1）較之于過(guò)程和工具，應(yīng)更加重視人和交互的價(jià)值；2）較之于面面俱到的文檔，應(yīng)更加重視可運(yùn)行軟件的價(jià)值；3）較之于合同談判，應(yīng)更加重視客戶合作的價(jià)值；4）較之于遵循計(jì)劃，應(yīng)更加重視響應(yīng)用戶需求變化的價(jià)值。極限編程簡(jiǎn)介17四大價(jià)值觀極限編程將其核心思想歸結(jié)為四條：交流反饋簡(jiǎn)單勇氣極限編程簡(jiǎn)介18五個(gè)原則快速反饋簡(jiǎn)單性假設(shè)逐步更改支持變化高質(zhì)量的工作極限編程簡(jiǎn)介19十二個(gè)最佳實(shí)踐計(jì)劃游戲（PlanningGame）隱喻（Metaphor）小型發(fā)布簡(jiǎn)單設(shè)計(jì)測(cè)試重構(gòu)結(jié)對(duì)編程代碼集體擁有持續(xù)集成每周工作40小時(shí)現(xiàn)場(chǎng)用戶編碼標(biāo)準(zhǔn)極限編程簡(jiǎn)介20需求分析的任務(wù)

需求分析是軟件定義時(shí)期的最后一個(gè)階段，它的基本任務(wù)不是確定系統(tǒng)怎樣完成它的工作，而是確定系統(tǒng)必須完成哪些工作，也就是對(duì)目標(biāo)系統(tǒng)提出完整、準(zhǔn)確、清晰、具體的要求。并在在需求分析階段結(jié)束之前，由系統(tǒng)分析員寫(xiě)出軟件需求規(guī)格說(shuō)明書(shū)，以書(shū)面形式準(zhǔn)確地描述軟件需求。即：

----準(zhǔn)確地回答“系統(tǒng)必須做什么?”。21系統(tǒng)流程圖系統(tǒng)流程圖是概括地描繪物理系統(tǒng)的傳統(tǒng)工具。它的基本思想是用圖形符號(hào)以黑盒子形式描繪組成系統(tǒng)的每個(gè)部件(程序，文檔，數(shù)據(jù)庫(kù)，人工過(guò)程等)。系統(tǒng)流程圖表達(dá)的是數(shù)據(jù)在系統(tǒng)各部件之間流動(dòng)的情況，而不是對(duì)數(shù)據(jù)進(jìn)行加工處理的控制過(guò)程，因此盡管系統(tǒng)流程圖的某些符號(hào)和程序流程圖的符號(hào)形式相同，但是它卻是物理數(shù)據(jù)流圖而不是程序流程圖。22基本符號(hào)----以概括的方式抽象地描繪一個(gè)實(shí)際系統(tǒng)所用符號(hào)23數(shù)據(jù)流圖一種圖形化技術(shù)，它描繪信息流和數(shù)據(jù)從輸入移動(dòng)到輸出的過(guò)程中所經(jīng)受的變換。在數(shù)據(jù)流圖中沒(méi)有任何具體的物理部件，它只是描繪數(shù)據(jù)在軟件中流動(dòng)和被處理的邏輯過(guò)程，是系統(tǒng)邏輯功能的圖形表示。設(shè)計(jì)數(shù)據(jù)流圖時(shí)只需考慮系統(tǒng)必須完成的基本邏輯功能，完全不需要考慮怎樣具體地實(shí)現(xiàn)這些功能，所以它也是今后進(jìn)行軟件設(shè)計(jì)的很好的出發(fā)點(diǎn)。DFD----DataFlowDiagram24數(shù)據(jù)流圖四種基本符號(hào)數(shù)據(jù)加工/處理/變換數(shù)據(jù)源點(diǎn)或終點(diǎn)(外部實(shí)體)數(shù)據(jù)流(dataflow)數(shù)據(jù)存儲(chǔ)文件或或或25數(shù)據(jù)字典&用途

數(shù)據(jù)流圖和數(shù)據(jù)字典共同構(gòu)成系統(tǒng)的邏輯模型

沒(méi)有數(shù)據(jù)字典數(shù)據(jù)流圖就不嚴(yán)格，沒(méi)有數(shù)據(jù)流圖數(shù)據(jù)字典也難于發(fā)揮作用。數(shù)據(jù)字典的任務(wù)是:對(duì)于數(shù)據(jù)流圖中出現(xiàn)的所有被命名的圖形元素在字典中作為一個(gè)詞條加以定義，使得每一個(gè)圖形元素的名字都有一個(gè)確切的解釋。----DD（DataDictionary）26判定表如果數(shù)據(jù)流圖的加工需要依賴于多個(gè)邏輯條件的取值，使用判定表來(lái)描述比較合適27判定表如果數(shù)據(jù)流圖的加工需要依賴于多個(gè)邏輯條件的取值，使用判定表來(lái)描述比較合適28判定樹(shù)判定樹(shù)也是用來(lái)表達(dá)加工邏輯的一種工具。有時(shí)侯它比判定表更直觀。檢查發(fā)貨單金額>$500金額$500欠款>60天不發(fā)出批準(zhǔn)書(shū)欠款60天發(fā)出批準(zhǔn)書(shū)、發(fā)貨單欠款>60天發(fā)出批準(zhǔn)書(shū)、發(fā)貨單及賒欠報(bào)告欠款60天發(fā)出批準(zhǔn)書(shū)、發(fā)貨單29軟件設(shè)計(jì)基礎(chǔ)自頂向下，逐步細(xì)化軟件結(jié)構(gòu)程序結(jié)構(gòu)結(jié)構(gòu)圖模塊化抽象化信息隱蔽30結(jié)構(gòu)化設(shè)計(jì)方法首先研究、分析和審查數(shù)據(jù)流圖。從軟件的需求規(guī)格說(shuō)明中弄清數(shù)據(jù)流加工的過(guò)程，對(duì)于發(fā)現(xiàn)的問(wèn)題及時(shí)解決。然后根據(jù)數(shù)據(jù)流圖決定問(wèn)題的類型。數(shù)據(jù)處理問(wèn)題典型的類型有兩種：變換型和事務(wù)型。針對(duì)兩種不同的類型分別進(jìn)行分析處理。由數(shù)據(jù)流圖推導(dǎo)出系統(tǒng)的初始結(jié)構(gòu)圖。利用一些啟發(fā)式原則來(lái)改進(jìn)系統(tǒng)的初始結(jié)構(gòu)圖，直到得到符合要求的結(jié)構(gòu)圖為止。修改和補(bǔ)充數(shù)據(jù)詞典。制定測(cè)試計(jì)劃。3131結(jié)構(gòu)程序設(shè)計(jì):goto語(yǔ)句慎用,3三種基本程序結(jié)構(gòu)人機(jī)界面設(shè)計(jì):可用性,合法性,界面友好過(guò)程設(shè)計(jì)的工具:程序流程圖,N-S,PAD,PDL,IPO面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)方法:Jackson方法程序復(fù)雜程度的定量度:McCabe詳細(xì)設(shè)計(jì)重點(diǎn)32abX1X2X7X6X4X3X5higfedcjFTFFFTTT多分支選擇結(jié)構(gòu)先判定型循環(huán)結(jié)構(gòu)選擇結(jié)構(gòu)后判定型循環(huán)結(jié)構(gòu)程序流程圖33N-S圖由而且僅由順序、選擇、循環(huán)三種基本結(jié)構(gòu)組成。基本圖例如下：順序結(jié)構(gòu)塊1塊2塊3塊4條件TF塊1塊2選擇結(jié)構(gòu)CaseI=1,2,3T塊1塊2多分支選擇結(jié)構(gòu)F塊3塊當(dāng)條件成立時(shí)當(dāng)型循環(huán)塊直到條件成立時(shí)直到型循環(huán)N—S圖34PAD圖—問(wèn)題分析圖（problemAnalysisDiagram）其基本控制結(jié)構(gòu)如下：任務(wù)1任務(wù)2任務(wù)3順序結(jié)構(gòu)WHILE型條件循環(huán)體先判定型循環(huán)結(jié)構(gòu)條件then部分else部分選擇結(jié)構(gòu)TFUNTIL型條件循環(huán)體后判定型循環(huán)結(jié)構(gòu)控制變量

任務(wù)1任務(wù)2任務(wù)n多分支選擇結(jié)構(gòu)值1值2值nPAD圖PAD圖基本結(jié)構(gòu)35這是一種結(jié)構(gòu)化的語(yǔ)言。是非形式化比較靈活的語(yǔ)言，用于描述模塊內(nèi)部過(guò)程的具體算法，以便在開(kāi)發(fā)人員之間比較精確的進(jìn)行交流。PDL的語(yǔ)法是開(kāi)放式的，其外層語(yǔ)法是確定的，而內(nèi)層語(yǔ)法則不確定。外層語(yǔ)法描述控制結(jié)構(gòu)它用類似于一般程序設(shè)計(jì)語(yǔ)言控制結(jié)構(gòu)的關(guān)鍵字：如：IF-THEN-ELSEWHILE-DOREPEAT-UNTILDOCASEDOWHILE等表示。有時(shí)還用關(guān)鍵字反排，表示控制結(jié)構(gòu)結(jié)束：

DO-ODIF-FIPDL（ProgramDesignLanguage）

程序設(shè)計(jì)語(yǔ)言361、建立數(shù)據(jù)結(jié)構(gòu)JACKSON方法中數(shù)據(jù)結(jié)構(gòu)表示為樹(shù)型結(jié)構(gòu)，有順序、選擇和循環(huán)三種基本結(jié)構(gòu)。2、以數(shù)據(jù)結(jié)構(gòu)為基礎(chǔ)，建立相應(yīng)的程序結(jié)構(gòu)圖，也稱為JACKSON圖。當(dāng)沒(méi)有結(jié)構(gòu)沖突時(shí)，轉(zhuǎn)換過(guò)程是簡(jiǎn)單的。JACKSON方法的設(shè)計(jì)過(guò)程

371、實(shí)現(xiàn)包括編碼和測(cè)試兩個(gè)階段2、

編碼=設(shè)計(jì)結(jié)果翻譯成程序(某種程序語(yǔ)言編寫(xiě))3、測(cè)試包含靜態(tài)測(cè)試和動(dòng)態(tài)測(cè)試,測(cè)試步驟至少分為:1.模塊測(cè)試---單元

2.子系統(tǒng)測(cè)試---局部3.系統(tǒng)測(cè)試---集成4.驗(yàn)收測(cè)試---用戶參與4、白盒測(cè)試和黑盒測(cè)試是軟件測(cè)試的兩類基本方法實(shí)現(xiàn)重點(diǎn)38軟件測(cè)試的目標(biāo)暴露問(wèn)題并不是軟件測(cè)試的最終目的，發(fā)現(xiàn)問(wèn)題是為了解決問(wèn)題，測(cè)試階段的根本目標(biāo)是盡可能多地發(fā)現(xiàn)并排除軟件中潛藏的錯(cuò)誤，最終把一個(gè)高質(zhì)量的軟件系統(tǒng)交給用戶使用。39軟件測(cè)試的策略和方法靜態(tài)測(cè)試方法動(dòng)態(tài)測(cè)試方法

人工測(cè)試方法計(jì)算機(jī)輔助靜態(tài)分析方法白盒測(cè)試方法黑盒測(cè)試方法測(cè)試方法4040測(cè)試步驟大型軟件系統(tǒng)的測(cè)試過(guò)程基本上由下述幾個(gè)步驟組成：1.模塊測(cè)試---單元

2.子系統(tǒng)測(cè)試---局部3.系統(tǒng)測(cè)試---集成4.驗(yàn)收測(cè)試---用戶參與5.平行運(yùn)行---新舊共存

4141白盒測(cè)試技術(shù)邏輯覆蓋

邏輯覆蓋----是以程序內(nèi)部的邏輯結(jié)構(gòu)為基礎(chǔ)的設(shè)計(jì)測(cè)試用例的技術(shù)。(1)語(yǔ)句覆蓋(2)判定覆蓋(3)條件覆蓋(4)判定/條件覆蓋(5)條件組合覆蓋(6)點(diǎn)覆蓋(7)邊覆蓋(8)路徑覆蓋4242發(fā)現(xiàn)錯(cuò)誤的能力標(biāo)準(zhǔn)含義1(弱)語(yǔ)句覆蓋每條語(yǔ)句至少執(zhí)行一次2判定覆蓋每一判定的每個(gè)分支至少執(zhí)行一次3條件覆蓋每一判定中的每個(gè)條件，分別按“真”、“假”至少各執(zhí)行一次4判定/條件覆蓋同時(shí)滿足判定覆蓋和條件覆蓋的要求5(強(qiáng))條件組合覆蓋求出判定中所有條件的各種可能組合值，每一可能的條件組合至少執(zhí)行一次

邏輯覆蓋測(cè)試的5種標(biāo)準(zhǔn)4343黑盒測(cè)試著重測(cè)試軟件功能。黑盒測(cè)試并不能取代白盒測(cè)試，它是與白盒測(cè)試互補(bǔ)的測(cè)試方法，它很可能發(fā)現(xiàn)白盒測(cè)試不易發(fā)現(xiàn)的其他類型的錯(cuò)誤。黑盒測(cè)試力圖發(fā)現(xiàn)下述類型的錯(cuò)誤：①功能不正確或遺漏了功能；②界面錯(cuò)誤；③數(shù)據(jù)結(jié)構(gòu)錯(cuò)誤或外部數(shù)據(jù)庫(kù)訪問(wèn)錯(cuò)誤；④性能錯(cuò)誤；⑤初始化和終止錯(cuò)誤。黑盒測(cè)試技術(shù)：等價(jià)劃分法、邊界值分析法、錯(cuò)誤推測(cè)法、因果圖法等。黑盒測(cè)試技術(shù)4444軟件維護(hù)

----就是在軟件已經(jīng)交付使用之后，為保證軟件在相當(dāng)長(zhǎng)的時(shí)期能夠正常運(yùn)作所進(jìn)行的軟件活動(dòng)。

維護(hù)的類型有四種：

改正性維護(hù)適應(yīng)性維護(hù)擴(kuò)充與完善性維護(hù)預(yù)防性維護(hù)軟件維護(hù)的定義4545軟件維護(hù)過(guò)程維護(hù)過(guò)程本質(zhì)上是修改和壓縮了的軟件定義和開(kāi)發(fā)過(guò)程，而且事實(shí)上遠(yuǎn)在提出一項(xiàng)維護(hù)要求之前，與軟件維護(hù)有關(guān)的工作已經(jīng)開(kāi)始了。維護(hù)組織維護(hù)報(bào)告維護(hù)的事件流維護(hù)檔案記錄維護(hù)評(píng)價(jià)46軟件的可維護(hù)性許多軟件的維護(hù)十分困難，原因在于這些軟件的文檔不全、質(zhì)量差、開(kāi)發(fā)過(guò)程不注意采用好的方法，忽視程序設(shè)計(jì)風(fēng)格等。許多維護(hù)要求并不是因?yàn)槌绦蛑谐鲥e(cuò)而提出的，而是為適應(yīng)環(huán)境變化或需求變化而提出的。為了使得軟件能夠易于維護(hù)，必須考慮使軟件具有可維護(hù)性。軟件可維護(hù)性是指糾正軟件系統(tǒng)出現(xiàn)的錯(cuò)誤和缺陷，以及為滿足新的要求進(jìn)行修改、擴(kuò)充或壓縮的容易程度。47決定軟件可維護(hù)性的因素

1.可理解性表現(xiàn)為外來(lái)讀者理解軟件的結(jié)構(gòu)、功能、接口和內(nèi)部處理過(guò)程的難易程度。2.可測(cè)試性診斷和測(cè)試的容易程度取決于軟件容易理解的程度。軟件結(jié)構(gòu)、可用的測(cè)試工具和調(diào)試工具，以及以前設(shè)計(jì)的測(cè)試過(guò)程也都是非常重要的

3.可修改性(和第五章設(shè)計(jì)原理和啟發(fā)規(guī)則直接有關(guān))4.可移植性

把程序從一種計(jì)算機(jī)環(huán)境(硬件配置和操作系統(tǒng))轉(zhuǎn)移到另一種計(jì)算環(huán)境的難易程度.5.可重用性指同一事物不做修改或稍加改動(dòng)就在不同的環(huán)境中多次重復(fù)使用.48文檔文檔是影響軟件可維護(hù)性的決定因素。往往文檔比程序代碼更重要。軟件系統(tǒng)的文檔可以分為用戶文檔和系統(tǒng)文檔兩類。

----用戶文檔主要描述系統(tǒng)功能和使用方法，并不關(guān)心這些功能是怎樣實(shí)現(xiàn)的；

----系統(tǒng)文檔描述系統(tǒng)設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試等各方面的內(nèi)容。49軟件復(fù)用的基本概念

軟件復(fù)用的定義

50軟件復(fù)用的重要性

軟件復(fù)用的目的是能更快、更好、成本更低地生產(chǎn)軟件制品。一般地說(shuō)，在軟件開(kāi)發(fā)中采用復(fù)用構(gòu)件可以比從頭開(kāi)發(fā)這個(gè)軟件更加容易。51軟件復(fù)用的粒度

按照可復(fù)用的粒度，軟件制品從小到大分為以下幾類：源代碼復(fù)用軟件體系結(jié)構(gòu)復(fù)用應(yīng)用程序生成器領(lǐng)域特定的軟件體系結(jié)構(gòu)的復(fù)用52橫向復(fù)用和縱向復(fù)用

橫向復(fù)用是指復(fù)用不同應(yīng)用領(lǐng)域中的軟件元素?？v向復(fù)用是指在一類具有較多公共性的應(yīng)用領(lǐng)域之間進(jìn)行軟部品復(fù)用。領(lǐng)域分析用戶需求軟件開(kāi)發(fā)與構(gòu)件開(kāi)發(fā)目標(biāo)軟件確認(rèn)可復(fù)用構(gòu)件庫(kù)檢索理解53

能力成熟度模型（CMM）CMMCapabilityMaturityModel，軟件過(guò)程成熟度模型定義、實(shí)施、度量、控制和改進(jìn)軟件過(guò)程的指南（MarkPaulk,WattsHumphrey等），主要流行于美國(guó)及印度SEISoftwareEngineeringInstitute，軟件工程研究所位于美國(guó)Pennsylvania州PittsburghCarnegieMellon大學(xué)，成立于1984年任務(wù)是在軟件工程領(lǐng)域中努力提高依賴軟件的系統(tǒng)質(zhì)量，促進(jìn)軟件開(kāi)發(fā)和維護(hù)的工程化管理，為軍方服務(wù)開(kāi)始主要用于大型軟件項(xiàng)目的招投標(biāo)活動(dòng)的評(píng)審依據(jù)；后應(yīng)用于軟件機(jī)構(gòu)的內(nèi)部過(guò)程改進(jìn)54CMM發(fā)展過(guò)程1986年11月應(yīng)美國(guó)政府要求，SEI和Mitre公司合作，共同開(kāi)發(fā)一種模型，用以評(píng)估軟件承包商能力，給出軟件組織改進(jìn)軟件過(guò)程的過(guò)程能力成熟度框架。1987年6月SEI提出初始模型框架，9月給出包含有101個(gè)問(wèn)題的初步成熟度提問(wèn)單（Questionnaire）。1991年推出CMMVersion1.0，這是SEI對(duì)軟件過(guò)程成熟度框架和初始成熟度提問(wèn)單經(jīng)過(guò)四年實(shí)踐的基礎(chǔ)上提出的。1992年4月召開(kāi)了有400位軟件專業(yè)人員參加的CMM研討會(huì)，針對(duì)CMMV1.0開(kāi)展了深入的討論，提出了改進(jìn)意見(jiàn)。55CMM發(fā)展過(guò)程1993年SEI提出了CMMVersion1.1技術(shù)報(bào)告文本，有70頁(yè)之多，對(duì)關(guān)鍵實(shí)踐的描述文本有450頁(yè)。1997年經(jīng)過(guò)對(duì)V1.1大量使用，吸收多方面的實(shí)踐經(jīng)驗(yàn)，再次修改，形成CMMVersion2.0。SEI與Mitre公司承擔(dān)項(xiàng)目1986過(guò)程成熟度框架成熟度提問(wèn)單1987CMMV1.01991CMMV1.11993CMMV2.0199756基本概念成熟：項(xiàng)目開(kāi)發(fā)是依據(jù)企業(yè)早已明確的過(guò)程準(zhǔn)則來(lái)實(shí)施；開(kāi)發(fā)結(jié)果較少以來(lái)個(gè)人能力和自然因素；項(xiàng)目有過(guò)程控制并可對(duì)整個(gè)生產(chǎn)作出預(yù)測(cè)；產(chǎn)品質(zhì)量得到有效監(jiān)控（借助與客觀定量化的數(shù)據(jù)）；歷史經(jīng)驗(yàn)得以積累并可系統(tǒng)地用于現(xiàn)行和未來(lái)的項(xiàng)目之中。不成熟沒(méi)有明確的軟件過(guò)程體系可以依據(jù)；無(wú)法對(duì)生產(chǎn)進(jìn)行預(yù)測(cè)；不嚴(yán)格執(zhí)行生產(chǎn)過(guò)程；質(zhì)量無(wú)法保證；無(wú)健全的過(guò)程控制及質(zhì)量控制體系；項(xiàng)目開(kāi)發(fā)沒(méi)有準(zhǔn)則可遵循；開(kāi)發(fā)結(jié)果主要依據(jù)項(xiàng)目小組及個(gè)人的帶有主觀因素的能力發(fā)揮。57CMM族Konrad.M于1996描述了SEI開(kāi)發(fā)的5種CMM-based模型,初始的CMM是針對(duì)軟件過(guò)程的，后發(fā)展到其它相關(guān)領(lǐng)域。SW-CMM軟件（Software）SA-CMM軟件獲取（SoftwareAcquisition）SE-CMM系統(tǒng)工程（SystemEngineering）IPM-CMM集成產(chǎn)品管理（IntegratedProductManagement）P-CMM人員（People）TSP小組軟件過(guò)程(TeamSoftwareProcess)PSP人員軟件過(guò)程（PersonnelSoftwareProcess)CMMI把分散的各個(gè)CMM集成在一起……58CMM5個(gè)成熟度等級(jí)經(jīng)反饋得以改進(jìn)的過(guò)程結(jié)果生產(chǎn)率和質(zhì)量風(fēng)險(xiǎn)已管理級(jí)保持優(yōu)化的組織，但仍為人員密集的過(guò)程技術(shù)變更、問(wèn)題分析、問(wèn)題預(yù)防過(guò)程度量、過(guò)程分析、量化質(zhì)量計(jì)劃培訓(xùn)、測(cè)試、技術(shù)常規(guī)和評(píng)審、過(guò)程關(guān)注、標(biāo)準(zhǔn)和過(guò)程項(xiàng)目管理、項(xiàng)目策劃、配置管理、軟件質(zhì)量保證（量化的）已度量的過(guò)程（量化的）已定義且制度化的過(guò)程（直覺(jué)的）過(guò)程依賴于個(gè)人個(gè)別的、混亂的過(guò)程優(yōu)化級(jí)已定義級(jí)可重復(fù)級(jí)初始級(jí)四五三二一主要需解決的問(wèn)題特征等級(jí)59初始級(jí)有制度的過(guò)程標(biāo)準(zhǔn)、一致的過(guò)程可預(yù)測(cè)的過(guò)程不斷改進(jìn)的過(guò)程可重復(fù)級(jí)已確定級(jí)已管理級(jí)優(yōu)化級(jí)60關(guān)鍵過(guò)程域KeyProcessArea軟件機(jī)構(gòu)為改進(jìn)其軟件過(guò)程所應(yīng)集中關(guān)注的區(qū)域，即對(duì)改進(jìn)過(guò)程能力最為有效的實(shí)踐為達(dá)到成熟度所必須著手解決的問(wèn)題和必須滿足的要求共18個(gè)KPA，分布在2~5級(jí)中區(qū)域目標(biāo)概括表明了KPA的范圍、界限、和目的。61過(guò)程變更管理PCM技術(shù)變更管理TCM缺陷預(yù)防 DP軟件產(chǎn)品工程SPE集成軟件管理ISM培訓(xùn)大綱 TP組織過(guò)程定義 OPD組織過(guò)程焦點(diǎn) OPF軟件配置管理

SCM軟件質(zhì)量保證

SQA軟件子合同管理 SSM軟件項(xiàng)目追蹤與監(jiān)督 SPTO軟件項(xiàng)目策劃

SPP需求管理

RM同行評(píng)審

PR組間協(xié)調(diào) IC軟件質(zhì)量管理SQM定量過(guò)程管理 QPM優(yōu)化已管理5級(jí)級(jí)4級(jí)3級(jí)2已定義可重復(fù)初始規(guī)范化過(guò)程標(biāo)準(zhǔn)化過(guò)程可預(yù)測(cè)過(guò)程持續(xù)改進(jìn)過(guò)程個(gè)別過(guò)程62

面向?qū)ο蟮幕靖拍蠲嫦驅(qū)ο蟮幕舅枷?/p>

面向?qū)ο笫且环N新興的程序設(shè)計(jì)方法,或者是一種新的程序設(shè)計(jì)規(guī)范(paradigm),其基本思想是使用對(duì)象、類、繼承、封裝、消息等基本概念來(lái)進(jìn)行程序設(shè)計(jì)。從現(xiàn)實(shí)世界中客觀存在的事物（即對(duì)象）出發(fā)來(lái)構(gòu)造軟件系統(tǒng)，并且在系統(tǒng)構(gòu)造中盡可能運(yùn)用人類的自然思維方式。開(kāi)發(fā)一個(gè)軟件是為了解決某些問(wèn)題，這些問(wèn)題所涉及的業(yè)務(wù)范圍稱作該軟件的問(wèn)題域。其應(yīng)用領(lǐng)域不僅僅是軟件，還有計(jì)算機(jī)體系結(jié)構(gòu)和人工智能等。63面向?qū)ο蟮幕靖拍?．對(duì)象的基本概念

對(duì)象是系統(tǒng)中用來(lái)描述客觀事物的一個(gè)實(shí)體，它是構(gòu)成系統(tǒng)的一個(gè)基本單位。一個(gè)對(duì)象由一組屬性和對(duì)這組屬性進(jìn)行操作的一組服務(wù)組成。主動(dòng)對(duì)象是一組屬性和一組服務(wù)的封裝體，其中至少有一個(gè)服務(wù)不需要接收消息就能主動(dòng)執(zhí)行（稱作主動(dòng)服務(wù)）。2．類的基本概念

類是具有相同屬性和服務(wù)的一組對(duì)象的集合，它為屬于該類的所有對(duì)象提供了統(tǒng)一的抽象描述，其內(nèi)部包括屬性和服務(wù)兩個(gè)主要部分。在面向?qū)ο蟮木幊陶Z(yǔ)言中，類是一個(gè)獨(dú)立的程序單位，它應(yīng)該有一個(gè)類名并包括屬性說(shuō)明和服務(wù)說(shuō)明兩個(gè)主要部分。3．消息 消息就是向?qū)ο蟀l(fā)出的服務(wù)請(qǐng)求，它應(yīng)該包含下述信息：提供服務(wù)的對(duì)象標(biāo)識(shí)、服務(wù)標(biāo)識(shí)、輸入信息和回答信息。服務(wù)通常被稱為方法或函數(shù)。64面向?qū)ο蟮幕咎卣?．封裝性

封裝性就是把對(duì)象的屬性和服務(wù)結(jié)合成一個(gè)獨(dú)立的相同單位，并盡可能隱蔽對(duì)象的內(nèi)部細(xì)節(jié)，包含兩個(gè)含義：

把對(duì)象的全部屬性和全部服務(wù)結(jié)合在一起，形成一個(gè)不可分割的獨(dú)立單位（即對(duì)象）。

信息隱蔽，即盡可能隱蔽對(duì)象的內(nèi)部細(xì)節(jié)，對(duì)外形成一個(gè)邊界〔或者說(shuō)形成一道屏障〕，只保留有限的對(duì)外接口使之與外部發(fā)生聯(lián)系。

封裝的原則在軟件上的反映是：要求使對(duì)象以外的部分不能隨意存取對(duì)象的內(nèi)部數(shù)據(jù)（屬性），從而有效的避免了外部錯(cuò)誤對(duì)它的"交叉感染"，使軟件錯(cuò)誤能夠局部化，大大減少查錯(cuò)和排錯(cuò)的難度。65面向?qū)ο蟮幕咎卣?．繼承性

特殊類的對(duì)象擁有其一般類的全部屬性與服務(wù)，稱作特殊類對(duì)一般類的繼承。 一個(gè)類可以是多個(gè)一般類的特殊類，它從多個(gè)一般類中繼承了屬性與服務(wù)，這稱為多繼承。 在java語(yǔ)言中，通常我們稱一般類為父類（superclass,超類），特殊類為子類(subclass)。3．多態(tài)性

對(duì)象的多態(tài)性是指在一般類中定義的屬性或服務(wù)被特殊類繼承之后，可以具有不同的數(shù)據(jù)類型或表現(xiàn)出不同的行為。這使得同一個(gè)屬性或服務(wù)在一般類及其各個(gè)特殊類中具有不同的語(yǔ)義。例如："幾何圖形"的"繪圖"方法，"橢圓"和"多邊形"都是"幾何圖"的子類，其"繪圖"方法功能不同。66面向?qū)ο蟪绦蛟O(shè)計(jì)方法

OOA－ObjectOrientedAnalysis面向?qū)ο蟮姆治鯫OD－ObjectOrientedDesign面向?qū)ο蟮脑O(shè)計(jì)OOI－ObjectOrientedImplementation面向?qū)ο蟮膶?shí)現(xiàn)67UML面向?qū)ο蟮姆治雠c設(shè)計(jì)統(tǒng)一建模面向?qū)ο蠓治龇椒ǜ攀鯱ML靜態(tài)建模UML動(dòng)態(tài)建模68§1UML概述1、UML概述統(tǒng)一的建模語(yǔ)言(UML)已經(jīng)在企業(yè)中廣泛使用它把Booch、Rumbaugh和Jacobson等各自獨(dú)立的OOA和OOD方法中最優(yōu)秀的特色組合成一個(gè)統(tǒng)一的方法。在UML中用5種不同的視圖來(lái)表示一個(gè)系統(tǒng)，這些視圖從不同的側(cè)面描述系統(tǒng)。每一個(gè)視圖由一組圖形來(lái)定義。用戶模型視圖：從用戶角度來(lái)表示系統(tǒng)。它用使用實(shí)例(usecase)

來(lái)建立模型，用它來(lái)描述由用戶方面的可用的場(chǎng)景。結(jié)構(gòu)模型視圖：從系統(tǒng)內(nèi)部來(lái)看數(shù)據(jù)和功能性。即對(duì)靜態(tài)結(jié)構(gòu)(類、對(duì)象和關(guān)系)模型化。69行為模型視圖：這種視圖表示了系統(tǒng)動(dòng)態(tài)和行為。它還描述了在用戶模型視圖和結(jié)構(gòu)模型視圖中所描述的各種結(jié)構(gòu)元素之間的交互和協(xié)作。實(shí)現(xiàn)模型視圖：將系統(tǒng)的結(jié)構(gòu)和行為表達(dá)成為易于轉(zhuǎn)換為實(shí)現(xiàn)的方式。環(huán)境模型視圖：表示系統(tǒng)實(shí)現(xiàn)環(huán)境的結(jié)構(gòu)和行為。通常，UML分析建模的著眼點(diǎn)放在系統(tǒng)的用戶模型和結(jié)構(gòu)模型上，而UML設(shè)計(jì)建模的著眼點(diǎn)則定位在行為模型、實(shí)現(xiàn)模型和環(huán)境模型上?！?UML概述70UML基本模型71UML靜態(tài)模型有：用戶、結(jié)構(gòu)、實(shí)現(xiàn)、環(huán)境模型（用例圖、類圖、對(duì)象圖、包、構(gòu)件圖和配置圖）1.用例圖(1)用例模型(Usecasemodel)用例模型描述的是外部執(zhí)行者(Actor)所理解的系統(tǒng)功能。它將系統(tǒng)看作黑盒，從外部執(zhí)行者的角度來(lái)理解系統(tǒng)，一個(gè)用例模型由若干個(gè)用例圖描述，用例圖主要元素是用例和執(zhí)行者。用例圖是包括執(zhí)行者、由系統(tǒng)邊界（一個(gè)矩形）封閉的一組用例，執(zhí)行者和用例之間的關(guān)聯(lián)、用例間關(guān)系以及執(zhí)行者的泛化的圖?！?UML靜態(tài)建模72用例圖73使用和擴(kuò)展(UseandExtend)：表示用例之間的使用和擴(kuò)展關(guān)系擴(kuò)展關(guān)系：當(dāng)一個(gè)用例與另一個(gè)用例相似，但所做的動(dòng)作多一些，將多余部分?jǐn)U展為一個(gè)用例，兩用例間關(guān)系稱為擴(kuò)展關(guān)系使用關(guān)系：當(dāng)有一大塊相似的動(dòng)作存在于幾個(gè)用例，又不想重復(fù)描述該動(dòng)作，將重復(fù)的部分分離為一個(gè)用例，兩用例間關(guān)系稱為使用關(guān)系擴(kuò)展與使用都是從幾個(gè)用例中抽取那些公共的行為并放入一個(gè)單獨(dú)用例中，而這個(gè)用例被其他幾個(gè)用例使用或擴(kuò)展。但使用和擴(kuò)展的目的是不同的?！?UML靜態(tài)建模742.類圖、對(duì)象圖和包（結(jié)構(gòu)模型）(1)類圖(ClassDiagram)類圖描述類和類之間的靜態(tài)關(guān)系。它顯示了信息的結(jié)構(gòu)和行為。類圖是定義其它圖的基礎(chǔ)。在類圖的基礎(chǔ)上，狀態(tài)圖、合作圖等進(jìn)一步描述了系統(tǒng)其他方面的特性。(2)類和對(duì)象(Object)對(duì)象、類、類屬性、操作類的名稱屬性屬性:數(shù)據(jù)類型屬性:數(shù)據(jù)類型=初值操作操作(參數(shù)表):結(jié)果類型類的屬性語(yǔ)法：可見(jiàn)性屬性名：類型=

缺省值{約束特性}75§3UML動(dòng)態(tài)建模UML動(dòng)態(tài)模型有：狀態(tài)圖、順序圖、合作圖、活動(dòng)圖1.消息對(duì)象間的交互是通過(guò)對(duì)象間消息的傳遞來(lái)完成的。當(dāng)一個(gè)對(duì)象調(diào)用另一個(gè)對(duì)象中的操作時(shí)，即完成了一次消息傳遞。當(dāng)操作執(zhí)行后，控制便返回到調(diào)用者。對(duì)象通過(guò)相互間的通信(消息傳遞)進(jìn)行合作，并在其生命周期中根據(jù)通信的結(jié)果不斷改變自身的狀態(tài)。簡(jiǎn)單消息(SimpleMessage)表示簡(jiǎn)單的控制流。用于描述控制如何在對(duì)象間進(jìn)行傳遞，而不考慮通信的細(xì)節(jié)。76同步消息(SynchronousMessage)表示嵌套的控制流。操作的調(diào)用是一種典型的同步消息。調(diào)用者發(fā)出消息后必須等待消息返回，只有當(dāng)處理消息的操作執(zhí)行完畢后，調(diào)用者才可繼續(xù)執(zhí)行自己的操作。異步消息(AsynchronousMessage)表示異步控制流。當(dāng)調(diào)用者發(fā)出消息后不用等待消息的返回即可繼續(xù)執(zhí)行自己的操作。異步消息主要用于描述實(shí)時(shí)系統(tǒng)中的并發(fā)行為。772.狀態(tài)圖(StateDiagram)狀態(tài)圖用來(lái)描述一個(gè)特定對(duì)象的所有可能狀態(tài)及其引起狀態(tài)轉(zhuǎn)移的事件。狀態(tài)圖表示單個(gè)對(duì)象在其生命周期中的行為。一個(gè)狀態(tài)圖包括一系列的狀態(tài)以及狀態(tài)之間的轉(zhuǎn)移。(1)狀態(tài)：狀態(tài)是對(duì)象執(zhí)行了一系列活動(dòng)的結(jié)果。當(dāng)某事件發(fā)生后，對(duì)象的狀態(tài)將發(fā)生變化。狀態(tài)圖中定義的狀態(tài)有：初態(tài)、終態(tài)、中間狀態(tài)、復(fù)合狀態(tài)。其中，初態(tài)是狀態(tài)圖的起始點(diǎn)，而終態(tài)則是狀態(tài)圖的終點(diǎn)。一個(gè)狀態(tài)圖只能有一個(gè)初態(tài)，而終態(tài)則可以有多個(gè)。一個(gè)狀態(tài)可以進(jìn)一步地細(xì)化為多個(gè)子狀態(tài)，我們將可以進(jìn)一步細(xì)化的狀態(tài)稱作復(fù)合狀態(tài)。子狀態(tài)之間有“或關(guān)系”和“與關(guān)系”兩種關(guān)系。78793.順序圖(SequenceDiagram)時(shí)序圖順序圖用來(lái)描述對(duì)象之間動(dòng)態(tài)的交互關(guān)系，著重體現(xiàn)對(duì)象間消息傳遞的時(shí)間順序。順序圖存在兩個(gè)軸：水平軸表示不同的對(duì)象，垂直軸表示時(shí)間。順序圖中的對(duì)象用一個(gè)帶有垂直虛線的矩形框表示，并標(biāo)有對(duì)象名和類名。垂直虛線是對(duì)象的生命線，用于表示在某段時(shí)間內(nèi)對(duì)象是存在的。對(duì)象間的通信通過(guò)在對(duì)象的生命線間畫(huà)消息來(lái)表示。消息的箭頭指明消息的類型。順序圖中的消息可以是信號(hào)(Signal)、操作調(diào)用或類似于C++中的RPC(RemoteProcedureCalls)和Java中的RMI(RemoteMethodInvocation)。當(dāng)收到消息時(shí)，接收對(duì)象立即開(kāi)始執(zhí)行活動(dòng)，即對(duì)象被激活了。通過(guò)在對(duì)象生命線上顯示一個(gè)細(xì)長(zhǎng)矩形框來(lái)表示激活。80814.合作圖(CollaborationDiagram)合作圖用于描述相互合作的對(duì)象間的交互關(guān)系和鏈接關(guān)系。雖然順序圖和合作圖都用來(lái)描述對(duì)象間的交互關(guān)系，但側(cè)重點(diǎn)不一樣。順序圖著重體現(xiàn)交互的時(shí)間順序，合作圖則著重體現(xiàn)交互對(duì)象間的靜態(tài)鏈接關(guān)系。鏈接關(guān)系：類似于類圖中的聯(lián)系(但無(wú)多重性標(biāo)志)。通過(guò)在對(duì)象間的鏈接上標(biāo)志帶有消息串的消息(簡(jiǎn)單、異步或同步消息)來(lái)表達(dá)對(duì)象間的消息傳遞消息流：在合作圖的鏈接線上，可以用帶有消息串的消息來(lái)描述對(duì)象間的交互。消息的箭頭指明消息的流動(dòng)方向。消息串說(shuō)明要發(fā)送的消息、消息的參數(shù)、消息的返回值以及消息的序列號(hào)等信息。82合作圖：打印835.活動(dòng)圖(ActivityDiagram)活動(dòng)圖描述操作(類的方法)的行為，或描述用例和對(duì)象內(nèi)部的工作過(guò)程。活動(dòng)圖是由狀態(tài)圖變化而來(lái)的，它們各自用于不同的目的?；顒?dòng)圖依據(jù)對(duì)象狀態(tài)的變化來(lái)捕獲動(dòng)作(將要執(zhí)行的工作或活動(dòng))與動(dòng)作的結(jié)果?；顒?dòng)圖中一個(gè)活動(dòng)結(jié)束后將立即進(jìn)入下一個(gè)活動(dòng)(在狀態(tài)圖中狀態(tài)的變遷可能需要事件的觸發(fā))。授權(quán)收費(fèi)84活動(dòng)圖：磁盤(pán)856.四種圖的運(yùn)用為幫助理解類而畫(huà)它的狀態(tài)圖。狀態(tài)圖描述跨越多個(gè)用例的單個(gè)對(duì)象的行為，而不適合描述多個(gè)對(duì)象間的行為合作。為此，常將狀態(tài)圖與其它技術(shù)(如順序圖、合作圖和活動(dòng)圖)組合使用。順序圖和合作圖適合描述單個(gè)用例中幾個(gè)對(duì)象的行為順序圖突出對(duì)象間交互的順序，而合作圖的布局方法能更清楚地表示出對(duì)象之間靜態(tài)的連接關(guān)系。當(dāng)行為較為簡(jiǎn)單時(shí)，順序圖和合作圖是最好的選擇。但當(dāng)行為比變復(fù)雜時(shí)，這兩個(gè)圖將失去其清晰度。因此，如果想顯示跨越多用例或多線程的復(fù)雜行為，可考慮使用活動(dòng)圖。順序圖和合作圖僅適合描述對(duì)象之間的合作關(guān)系，而不適合對(duì)行為進(jìn)行精確定義，如果想描述跨越多個(gè)用例的單個(gè)對(duì)象的行為，應(yīng)當(dāng)使用狀態(tài)圖。86應(yīng)用集成技術(shù)主要內(nèi)容：微軟的應(yīng)用集成技術(shù)對(duì)象管理協(xié)會(huì)（OMG）的應(yīng)用集成技術(shù)Java平臺(tái)上的應(yīng)用集成技術(shù)Web服務(wù)871微軟的應(yīng)用集成技術(shù)COM是微軟制訂并頒布的一種不依賴于任何編程語(yǔ)言的構(gòu)建對(duì)象模型。COM+是最近微軟宣布的以COM為基礎(chǔ)的新一代技術(shù)。在COM+的基礎(chǔ)上，微軟將多年積累下來(lái)的技術(shù)精華集合起來(lái)而形成一個(gè)完整的、多層結(jié)構(gòu)的企業(yè)應(yīng)用總體方案----WindowsDNA，它使Windows真正成為企業(yè)應(yīng)用平臺(tái)。88.NET應(yīng)用架構(gòu)微軟的.NET是基于一組開(kāi)放的互聯(lián)網(wǎng)協(xié)議，推出的一系列的產(chǎn)品、技術(shù)和服務(wù)。.NET開(kāi)發(fā)框架在通用語(yǔ)言運(yùn)行環(huán)境基礎(chǔ)上，給開(kāi)發(fā)人員提供了完善的基礎(chǔ)類庫(kù)、數(shù)據(jù)庫(kù)訪問(wèn)技術(shù)及網(wǎng)絡(luò)開(kāi)發(fā)技術(shù)，開(kāi)發(fā)者可以使用多種語(yǔ)言快速構(gòu)建網(wǎng)絡(luò)應(yīng)用。.NET開(kāi)發(fā)框架如圖：

通用語(yǔ)言運(yùn)行環(huán)境（CommonLanguageRuntime）處于.NET開(kāi)發(fā)框架的最底層，是該框架的基礎(chǔ)，它為多種語(yǔ)言提供了統(tǒng)一的運(yùn)行環(huán)境、統(tǒng)一的編程模型，大大簡(jiǎn)化了應(yīng)用程序的發(fā)布和升級(jí)、多種語(yǔ)言之間的交互、內(nèi)存和資源的自動(dòng)管理等?；A(chǔ)類庫(kù)（BaseClassLibrary）給開(kāi)發(fā)人員提供了一個(gè)統(tǒng)一的、面向?qū)ο蟮摹哟位?、可擴(kuò)展的編程接口，使開(kāi)發(fā)人員能夠高效、快速地構(gòu)建基于下一代互聯(lián)網(wǎng)的網(wǎng)絡(luò)應(yīng)用。89

對(duì)象管理協(xié)會(huì)（OMG）的應(yīng)用集成技術(shù)OMG（ObjectManagementGroup，對(duì)象管理組織）是CORBA規(guī)范的制訂者，是由800多個(gè)信息系統(tǒng)供應(yīng)商、軟件開(kāi)發(fā)者和用戶共同構(gòu)成的國(guó)際組織，建立于1989年。OMG在理論上和實(shí)踐上促進(jìn)了面向?qū)ο筌浖陌l(fā)展。OMG的目的是為了將對(duì)象和分布式系統(tǒng)技術(shù)集成為一個(gè)可相互操作的統(tǒng)一結(jié)構(gòu)，此結(jié)構(gòu)既支持現(xiàn)有的平臺(tái)也將支持未來(lái)的平臺(tái)集成。90公共對(duì)象請(qǐng)求代理結(jié)構(gòu)CORBAOMG的主要工作是通過(guò)建立行業(yè)指導(dǎo)和對(duì)象管理規(guī)范為應(yīng)用開(kāi)發(fā)提供公共的框架。OMG是一個(gè)僅僅制訂規(guī)范的組織，而不提供具體的實(shí)現(xiàn)。通過(guò)CORBA規(guī)范的制訂，OMG將對(duì)象引入了分布式的環(huán)境中。CORBA（CommonObjectRequestBrokerArchitecture,公共對(duì)象請(qǐng)求代理體系結(jié)構(gòu)）是由OMG提出的應(yīng)用軟件體系結(jié)構(gòu)和對(duì)象技術(shù)規(guī)范，其核心是一套標(biāo)準(zhǔn)的語(yǔ)言、接口和協(xié)議，以支持異構(gòu)分布應(yīng)用程序間的互操作性及獨(dú)立于平臺(tái)和編程語(yǔ)言的對(duì)象重用。

91CORBA體系結(jié)構(gòu)概述CORBA規(guī)范充分利用了軟件技術(shù)發(fā)展的成果，在基于網(wǎng)絡(luò)的分布式應(yīng)用環(huán)境下實(shí)現(xiàn)應(yīng)用軟件的集成，使得面向?qū)ο蟮能浖诜植?、異?gòu)環(huán)境下實(shí)現(xiàn)可重用、可移植和互操作。CORBA規(guī)范的特點(diǎn)：引入中間件（MiddleWare）作為事務(wù)代理，完成客戶機(jī)（Client）向服務(wù)對(duì)象方（Server）提出的業(yè)務(wù)請(qǐng)求(引入中間件概念后分布計(jì)算模式如圖所示)；實(shí)現(xiàn)客戶與服務(wù)對(duì)象的完全分開(kāi)，客戶不需要了解服務(wù)對(duì)象的實(shí)現(xiàn)過(guò)程以及具體位置(參見(jiàn)如圖所示的CORBA系統(tǒng)體系結(jié)構(gòu)圖)；

92CORBA的主要應(yīng)用方向及中間件產(chǎn)品介紹軟件市場(chǎng)中能夠見(jiàn)到的CORBA中間件產(chǎn)品很多，但基于不同公司的產(chǎn)品戰(zhàn)略以及研發(fā)方向，各個(gè)產(chǎn)品在服務(wù)性能、對(duì)高級(jí)語(yǔ)言的支持和所依賴的系統(tǒng)平臺(tái)方面有很大區(qū)別。根據(jù)整理的資料，對(duì)主要產(chǎn)品在上述幾方面進(jìn)行分析:

933Java平臺(tái)上的應(yīng)用集成技術(shù)RMI（RemoteMethodInvocation，遠(yuǎn)程方法調(diào)用）是Java在JDK1.1中實(shí)現(xiàn)的，它大大增強(qiáng)了Java開(kāi)發(fā)分布式應(yīng)用的能力。RMI是開(kāi)發(fā)百分之百純Java的網(wǎng)絡(luò)分布式應(yīng)用系統(tǒng)的核心解決方案之一?？梢员豢醋魇荝PC的Java版本。傳統(tǒng)RPC并不能很好地應(yīng)用于分布式對(duì)象系統(tǒng)。而JavaRMI則支持存儲(chǔ)于不同地址空間的程序級(jí)對(duì)象之間彼此進(jìn)行通信，實(shí)現(xiàn)遠(yuǎn)程對(duì)象之間的無(wú)縫遠(yuǎn)程調(diào)用。RMI目前使用Java遠(yuǎn)程消息交換協(xié)議JRMP（JavaRemoteMessagingProtocol）進(jìn)行通信。JavaRMI具有Java的"WriteOnce,RunAnywhere"的優(yōu)點(diǎn)，是分布式應(yīng)用系統(tǒng)的純Java解決方案。用JavaRMI開(kāi)發(fā)的應(yīng)用系統(tǒng)可以部署在任何支持JRE（JavaRunEnvironmentJava，運(yùn)行環(huán)境）的平臺(tái)上。94RMI與CORBA的關(guān)系RMI和CORBA常被視為相互競(jìng)爭(zhēng)的技術(shù)，因?yàn)閮烧叨继峁?duì)遠(yuǎn)程分布式對(duì)象的透明訪問(wèn)。但這兩種技術(shù)實(shí)際上是相互補(bǔ)充的，一者的長(zhǎng)處正好可以彌補(bǔ)另一者的短處。RMI和CORBA的結(jié)合產(chǎn)生了RMI-IIOP，RMI-IIOP是企業(yè)服務(wù)器端Java開(kāi)發(fā)的基礎(chǔ)。1997年，I