考試題型：選擇15道，判斷15道，大題20分，簡答50分，答題請(qǐng)簡明扼要。一、軟件工程及面向?qū)ο蠹夹g(shù)、RUP概述軟件生命周期的主要階段?需求分析（RequirementAnalysis）?軟件設(shè)計(jì)（SoftwareDesign）?編碼（Coding/Programming）?測(cè)試/調(diào)試（Testing/Debug）?運(yùn)行/維護(hù)（Running/Maintenance）幾種經(jīng)典的軟件過程模型及其相應(yīng)的特點(diǎn)從項(xiàng)目的需求定義情況、項(xiàng)目規(guī)模和復(fù)雜程度以及管理、控制的模式來看，大致可分為：–線性模型?瀑布模型Waterfallmodel，也稱為線性順序模型或典型的生命周期模型特點(diǎn)：a軟件開發(fā)各階段嚴(yán)格按照順序進(jìn)行，前一階段的任務(wù)沒有完成，不能進(jìn)入下一階段b每一階段的工作成果必須經(jīng)過評(píng)審，確認(rèn)無誤，才能作為下一階段的輸入和依據(jù)c每一階段結(jié)束時(shí)要求交出規(guī)定的軟件文檔資料缺點(diǎn)：a缺乏靈活性b對(duì)軟件開發(fā)過于理想化，如對(duì)系統(tǒng)的需求分析適用范圍：a適用于小型項(xiàng)目b要求在項(xiàng)目開始時(shí)就明確需求。?快速應(yīng)用開發(fā)（RAD）模型瀑布模型的高速變種，強(qiáng)調(diào)在短期內(nèi)開發(fā)軟件強(qiáng)調(diào)重用在以前項(xiàng)目中開發(fā)過和測(cè)試過的構(gòu)件特點(diǎn)：a開發(fā)速度快b適用于在開發(fā)過程之前就充分理解需求的情況c需要有足夠的人力資源以建立相應(yīng)的RAD小組dRAD不適合技術(shù)風(fēng)險(xiǎn)很高或系統(tǒng)難以模塊化的情況–原型模型特點(diǎn)：a循環(huán)模式（Circulation）b引入用戶評(píng)價(jià)c逐步求精–演化模型a優(yōu)點(diǎn)–便于開發(fā)人員和用戶之間的交流溝通–開發(fā)過程變得簡單、靈活–可以吸引客戶，搶占市場(chǎng)（慎用）b缺點(diǎn)–要求開發(fā)團(tuán)隊(duì)有較高的原型開發(fā)能力，如果團(tuán)隊(duì)經(jīng)驗(yàn)不足，可能會(huì)影響原型的質(zhì)量–沒有考慮軟件的整體質(zhì)量和可維護(hù)性?增量模型a優(yōu)點(diǎn)：–能夠明確需求，可以實(shí)施較好的風(fēng)險(xiǎn)管理–人員分配靈活，項(xiàng)目開始時(shí)不用投入大量人力資源，當(dāng)核心產(chǎn)品很受歡迎時(shí)，可增加人力實(shí)現(xiàn)下一個(gè)增量b缺點(diǎn)–至始至終都必須和客戶溝通，直至完成最終版本–只適用于大型系統(tǒng)，對(duì)小系統(tǒng)劃分小的功能增量很困難?螺旋模型a優(yōu)點(diǎn)–對(duì)于大型系統(tǒng)來說，這個(gè)模型是一個(gè)很好的方法，開發(fā)者和客戶能夠較好地對(duì)待和理解每一個(gè)演化層次上的風(fēng)險(xiǎn)b缺點(diǎn)–需要相當(dāng)?shù)娘L(fēng)險(xiǎn)評(píng)估技術(shù)–潛在的風(fēng)險(xiǎn)將導(dǎo)致問題的發(fā)生?基于構(gòu)件的開發(fā)模型a優(yōu)點(diǎn)–構(gòu)件可復(fù)用，提高了開發(fā)效率–采用了面向?qū)ο蟮募夹g(shù)b缺點(diǎn)–過分依賴于構(gòu)件，構(gòu)件庫的質(zhì)量影響著產(chǎn)品質(zhì)量面向?qū)ο蟮幕窘Ｔ瓌t–抽象–封裝–繼承–分類–關(guān)聯(lián)面向?qū)ο蠓治龇执笾逻^程?描述需求?識(shí)別潛在對(duì)象?篩選對(duì)象?對(duì)象的命名?識(shí)別對(duì)象的屬性?識(shí)別對(duì)象的行為?識(shí)別對(duì)象所屬的類?定義類的結(jié)構(gòu)面向?qū)ο蟪绦蛟O(shè)計(jì)語言?Simula,1967?Smalltalk,20世紀(jì)60年代?C++優(yōu)點(diǎn)–可在操作系統(tǒng)的任何層次上作任何事情–可能是現(xiàn)有的速度最快的面向?qū)ο笳Z言–C++編譯器十分流行，程序員很多缺點(diǎn)–指針的大量使用難以保證軟件在運(yùn)行時(shí)的安全性?Java特點(diǎn)：–平臺(tái)無關(guān)性，可移植性高–垃圾回收機(jī)制–沒有指針?C#?AdaRUP的基本概念、基本特征以及裁剪——基本概念：AProcessdefineswhoisdoingwhatwhenandhowtoreachacertaingoal.–(軟件過程描述了什么時(shí)候，什么人，做什么事，以及怎樣實(shí)現(xiàn)某一特定的目標(biāo))RationalUnifiedProcess是一種軟件的開發(fā)過程，是將用戶需求轉(zhuǎn)化為軟件系統(tǒng)所需的活動(dòng)的集合。是一個(gè)通用的過程框架?！咎卣鳎?用例驅(qū)動(dòng)采用用例來捕獲對(duì)目標(biāo)系統(tǒng)的功能需求采用用例來驅(qū)動(dòng)軟件的整個(gè)開發(fā)過程，保證需求的可跟蹤性，確保系統(tǒng)所有功能均被實(shí)現(xiàn)。?以軟件體系結(jié)構(gòu)為中心軟件體系結(jié)構(gòu)刻畫了系統(tǒng)的整體設(shè)計(jì)，它去掉了細(xì)節(jié)部分，突出了系統(tǒng)的重要特征在開發(fā)過程的早期形成良好的軟件體系結(jié)構(gòu)，有利于對(duì)系統(tǒng)的理解、支持重用和有效的組織軟件開發(fā)在后續(xù)階段中對(duì)已形成的體系結(jié)構(gòu)框架進(jìn)行不斷細(xì)化，最終實(shí)現(xiàn)整個(gè)系統(tǒng)。?受控的迭代式增量開發(fā)將軟件開發(fā)過程分為一系列小的迭代過程，在每個(gè)迭代過程中逐步增加信息、進(jìn)行細(xì)化根據(jù)具體情況決定迭代的次數(shù)、每次迭代延續(xù)的時(shí)間以及迭代工作流每次迭代都選擇目前對(duì)風(fēng)險(xiǎn)影響最大的用例進(jìn)行，以分解和降低風(fēng)險(xiǎn)。RUP與UML的關(guān)系要實(shí)施RUP，應(yīng)該用UML統(tǒng)一建模語言。二者是一起發(fā)展起來的，是不可分的關(guān)系。二、UML概述UML基本概念以及其與編程語言的區(qū)別UnifiedModelingLanguage–是對(duì)軟件密集型系統(tǒng)中的制品進(jìn)行可視化、詳述、構(gòu)造和文檔化的語言UML中圖的分類——結(jié)構(gòu)圖：類圖、構(gòu)件圖、對(duì)象圖、部署圖、組合結(jié)構(gòu)圖、包圖、用例圖——行為圖：?活動(dòng)圖–顯示系統(tǒng)內(nèi)的活動(dòng)流?狀態(tài)圖–顯示一個(gè)對(duì)象的狀態(tài)和狀態(tài)之間的轉(zhuǎn)換?合作圖–突出對(duì)象之間的合作與交互?順序圖–強(qiáng)調(diào)一個(gè)系統(tǒng)中不同元素間傳遞消息的時(shí)間順序?時(shí)間圖–描繪與交互元素的狀態(tài)轉(zhuǎn)換或條件變化有關(guān)的詳細(xì)時(shí)間信息?交互概觀圖–用于從總體上顯示交互序列之間的控制流UML的組成由基本構(gòu)造塊、規(guī)則、通用機(jī)制組成。UML可見性原則可見性:Public,Protected,Private,Package常用的UML工具?RationalRose（功能強(qiáng)大，市場(chǎng)占有率高）?StarUML?EnterpriseArchitect?ArgoUML?Visio三、用例圖用例圖建模步驟①找出系統(tǒng)外部的參與者和外部系統(tǒng),確定系統(tǒng)邊界和范圍②確定每一個(gè)參與者所期望的系統(tǒng)行為③把這些系統(tǒng)行為命名為用例④使用泛化、包含、擴(kuò)展等關(guān)系處理系統(tǒng)行為的公共或變更部分⑤編制每一個(gè)用例的腳本⑥繪制用例圖⑦區(qū)分主要事件流和異常事件流,如果需要,可以把異常事件流處理為單獨(dú)的用例細(xì)化用例圖,解決用例間重復(fù)與沖突的問題用例是為了獲得系統(tǒng)需求。需求技術(shù)、需求的類型——兩種類型的需求–功能性需求：系統(tǒng)應(yīng)該提供什么行為–非功能性需求：系統(tǒng)上的特定屬性或約束——三種需求技術(shù)–XP中的用戶故事由用戶參與編寫，說明需要系統(tǒng)為他們做什么簡短的文字描述–FDD中的特性描述特性驅(qū)動(dòng)的軟件開發(fā)方法特性（feature）描述：<action>the<result><by|for|of|to>a(n)<object>–RUP中的用例描繪一個(gè)系統(tǒng)外在可見的需求情況，是代表系統(tǒng)中各個(gè)項(xiàng)目相關(guān)人員之間就系統(tǒng)的行為所達(dá)成的契約?！枨箢愋凸δ苄孕枨螅合到y(tǒng)應(yīng)該提供什么行為非功能性需求：系統(tǒng)上的特定屬性或約束用例圖的三要素參與者：?參與者是虛擬的概念，可以指人，也可以指外部系統(tǒng)、設(shè)備等?一個(gè)參與者可以執(zhí)行多個(gè)用例?一個(gè)用例也可以由多個(gè)參與者所使用?盡管在用例建模時(shí)使用參與者，但參與者實(shí)際上并不是系統(tǒng)的一部分用例：用例是對(duì)一個(gè)活動(dòng)者(actor)使用系統(tǒng)的一項(xiàng)功能時(shí)所進(jìn)行的交互過程的一個(gè)文字描述序列用例是系統(tǒng)、子系統(tǒng)或類和外部參與者交互的動(dòng)作序列的說明,包括可選的動(dòng)作序列和會(huì)出現(xiàn)異常的動(dòng)作序列參與者與用例之間的關(guān)系：參與者和用例之間是關(guān)聯(lián)關(guān)系，表示了參與者與用例間的通信可以用一條實(shí)線箭頭表示，由參與者指向用例用例之間的關(guān)系–泛化(generalization)–包含(include)–擴(kuò)展(extend)–自定義四、類圖類的基本概念類是具有相似結(jié)構(gòu)、行為和關(guān)系的一組對(duì)象的描述符接口是一種特殊的類。接口是一種類似于抽象類的機(jī)制，是一個(gè)沒有具體實(shí)現(xiàn)的類。關(guān)聯(lián)類既是關(guān)聯(lián)又是類。嵌套類：在諸如JAVA的語言中，允許將一個(gè)類的定義放在另一個(gè)類定義的內(nèi)部，這就是嵌套類，嵌套類是聲明在它的外層類中的，因此只能夠通過外層類或外層類的對(duì)象對(duì)它進(jìn)行訪問。類之間的關(guān)系及相應(yīng)表示方法聚合，組合，依賴，關(guān)聯(lián)四種關(guān)系的強(qiáng)弱：組合>聚合>關(guān)聯(lián)>依賴。三種主要的類版型及其表示方法邊界類：實(shí)體類：控制類：邊界類位于系統(tǒng)與外界的交界處每個(gè)參與者-用例對(duì)至少要有一個(gè)邊界類，但并非每個(gè)參與者-用例對(duì)要生成唯一邊界類，多個(gè)參與者可以用同一個(gè)邊界類。實(shí)體類描述要保存到持久存儲(chǔ)體中的信息。實(shí)體類可以通過事件流和交互圖發(fā)現(xiàn)。控制類是主要負(fù)責(zé)其它類工作的類。類圖的抽象層次概念層（分析階段）、說明層（設(shè)計(jì)階段）、實(shí)現(xiàn)層（實(shí)現(xiàn)階段）——概念層：描述應(yīng)用領(lǐng)域中的概念–一般這些概念與類有很自然的聯(lián)系，但未必有直接的映射關(guān)系?獨(dú)立于程序設(shè)計(jì)語言，類的描述可能沒有或有少量屬性和操作名稱——說明層：?描述軟件的接口部分,不是實(shí)現(xiàn)部分–接口可能因?yàn)閷?shí)現(xiàn)環(huán)境等不同而有不同的實(shí)現(xiàn)?主要列出屬性和操作名稱——實(shí)現(xiàn)層?考慮類的實(shí)現(xiàn)問題?提供類的實(shí)現(xiàn)細(xì)節(jié)——比較?類圖的三個(gè)層次之間沒有一個(gè)清晰的界限?三個(gè)層次的觀點(diǎn)并不是UML的組成部分，但它們對(duì)于畫類圖或者閱讀類圖非常有用?指明類圖層次的方法–版型：《implementationclass》《type》多重性的概念表示有多少個(gè)對(duì)象參與該關(guān)聯(lián)*(即0..n)0個(gè)或多個(gè)四、對(duì)象圖與包圖對(duì)象的特征以及命名方法——狀態(tài)、行為、標(biāo)識(shí)?對(duì)象的狀態(tài)包括這個(gè)對(duì)象的所有屬性（通常是靜態(tài)的）以及每個(gè)屬性當(dāng)前的值（通常是動(dòng)態(tài)的）?為了將一個(gè)對(duì)象與其它所有對(duì)象區(qū)分開來，我們通常會(huì)給它起一個(gè)“標(biāo)識(shí)”?行為是對(duì)象根據(jù)它的狀態(tài)改變和消息傳遞所采取的行動(dòng)和所作出的反應(yīng)；對(duì)象的行為代表了其外部可見的活動(dòng)；操作代表了一個(gè)類提供給它的對(duì)象的一種服務(wù)。?對(duì)象名–“對(duì)象名:類名”–“:類名”–“對(duì)象名”?屬性–“屬性名=屬性值”對(duì)象和類的關(guān)系?對(duì)象是一個(gè)存在于時(shí)間和空間中的實(shí)體，類僅代表一種抽象，抽象出對(duì)象的本質(zhì)?類是靜態(tài)的，對(duì)象是動(dòng)態(tài)的?類是一般化，對(duì)象是個(gè)性化?類是定義，對(duì)象是實(shí)例?類是抽象，對(duì)象是具體包在UML體系中的位置基本構(gòu)造塊：事物：分組事物?包是一種常規(guī)用途的組合機(jī)制?在UML中，包是–一種分組事物–一個(gè)UML建模元素的容器–通過包可將以下元素聚集在一起?類?用例?構(gòu)件?……包中可包含的元素類、接口、構(gòu)件、節(jié)點(diǎn)、協(xié)作、用例、其他子包或圖包的版型?《system》版型–表示正在建模的整個(gè)系統(tǒng)?《subsystem》版型–表示正在建模的系統(tǒng)中某個(gè)獨(dú)立的部分?《facade》版型–是其它包的視圖，主要為復(fù)雜的包提供簡略視圖?《stub》版型–是一個(gè)代理包，通常用于分布式系統(tǒng)的建模?《framework》版型–表示一個(gè)框架，框架是一個(gè)領(lǐng)域中的應(yīng)用系統(tǒng)提供可擴(kuò)充模板的體系結(jié)構(gòu)模式包之間的關(guān)系依賴關(guān)系：《use》《import》《access》《trace》泛化關(guān)系包圖建模原則重用等價(jià)原則：?把類放入包中時(shí),應(yīng)考慮把包作為可重用的單元?重用的粒度就是發(fā)布的粒度?該原則傾向于把包做的越小越好共同重用原則：?不會(huì)一起使用的類不要放在同一個(gè)包中?一個(gè)包中的所有類應(yīng)該是共同重用的，如果重用了包中的一個(gè)類，就應(yīng)該重用包中的所有類?該原則傾向于把包做的盡可能小共同閉包原則：?把需要同時(shí)改變的類放在同一個(gè)包中?以下情況兩個(gè)類放在一個(gè)包中：–一個(gè)類的改變要求另一個(gè)類做相應(yīng)改變–刪除一個(gè)類后，另一個(gè)類變成多余–兩個(gè)類間有大量的消息發(fā)送?該原則傾向于將包做的盡可能的大非循環(huán)依賴原則：?包之間的依賴關(guān)系不要形成循環(huán)?包A依賴包B，包B依賴包C，包C依賴包A，形成了循環(huán)，怎么辦？?將這些包中的元素放入一個(gè)更大的包中包內(nèi)元素的可見性?包內(nèi)元素的可見性控制了包外部元素訪問包內(nèi)部元素的權(quán)限?包的可見性有–“+”表示“public”–“#”表示“protected”–“-”來表示“private活動(dòng)圖概念以及構(gòu)成元素?活動(dòng)圖描述系統(tǒng)或業(yè)務(wù)的一系列活動(dòng)構(gòu)成的控制流?活動(dòng)圖描述系統(tǒng)從一種活動(dòng)轉(zhuǎn)換到另一種活動(dòng)的整個(gè)過程?活動(dòng)圖通常對(duì)業(yè)務(wù)過程、工作流和用例實(shí)現(xiàn)進(jìn)行建模初始節(jié)點(diǎn)、活動(dòng)終點(diǎn)、活動(dòng)節(jié)點(diǎn)、轉(zhuǎn)換、分支和監(jiān)護(hù)條件、分岔與匯合活動(dòng)圖建模的原則?盡量使用分支、分岔和匯合等基本建模元素繪制活動(dòng)圖?根據(jù)活動(dòng)圖中是否要體現(xiàn)出不同的實(shí)施者，來決定是否采用泳道?根據(jù)需要，加入對(duì)象流以及對(duì)象的狀態(tài)變化?根據(jù)需要，加入高級(jí)的建模元素（比如輔助活動(dòng)圖、匯合描述、信號(hào)節(jié)點(diǎn)、引腳及擴(kuò)展區(qū)）分岔與分支的區(qū)別分岔：活動(dòng)是并發(fā)執(zhí)行；有一個(gè)進(jìn)入轉(zhuǎn)換，有兩個(gè)或多個(gè)離開轉(zhuǎn)換分支：活動(dòng)的轉(zhuǎn)換是有條件的；有一個(gè)進(jìn)入轉(zhuǎn)換，一個(gè)或多個(gè)離開轉(zhuǎn)換狀態(tài)機(jī)圖基本概念以及構(gòu)成元素?一個(gè)狀態(tài)是指在對(duì)象的生命期中的一個(gè)條件或狀況，在此期間對(duì)象將滿足某些條件、執(zhí)行某些活動(dòng)或等待某些事件?狀態(tài)機(jī)圖是一種用來表達(dá)狀態(tài)機(jī)的圖?在狀態(tài)機(jī)圖中，狀態(tài)節(jié)點(diǎn)由狀態(tài)符號(hào)表示，狀態(tài)之間的轉(zhuǎn)換由連接狀態(tài)節(jié)點(diǎn)的有向弧表示?狀態(tài)機(jī)圖描述狀態(tài)到狀態(tài)的控制流程，常用來對(duì)系統(tǒng)的動(dòng)態(tài)特征建模?狀態(tài)機(jī)圖可以用于對(duì)不同建模元素的實(shí)體建模?初態(tài)和終態(tài)?源狀態(tài)和目標(biāo)狀態(tài)?觸發(fā)事件?監(jiān)護(hù)條件?動(dòng)作?分支復(fù)合狀態(tài)?指狀態(tài)本身包含一個(gè)或多個(gè)狀態(tài)機(jī)的狀態(tài)?順序復(fù)合狀態(tài)–只包含一個(gè)狀態(tài)機(jī)的復(fù)合狀態(tài)?并發(fā)復(fù)合狀態(tài)–包含兩個(gè)或兩個(gè)以上并發(fā)執(zhí)行的狀態(tài)機(jī)歷史狀態(tài)?用于記住上次離開復(fù)合狀態(tài)時(shí)所處的子狀態(tài)?表示方法–淺歷史–深歷史交互圖分類?順序圖（時(shí)序圖，序列圖）?通信圖（協(xié)作圖）?定時(shí)圖?交互概述圖順序圖基本概念、建模元素以及編號(hào)?順序圖是顯示對(duì)象之間交互的