運用軟件工程的方法論

1、運用軟件工程的方法論軟件工程專業(yè)以計算機科學(xué)與技術(shù)學(xué)科為基礎(chǔ)，強調(diào)軟件開發(fā)的工程性，使學(xué)生在掌握計算機科學(xué)與技術(shù)方面知識和技能的基礎(chǔ)上熟練掌握從事軟件需求分析、軟件設(shè)計軟件測試、軟件維護(hù)和軟件項目管理等工作所必需的基礎(chǔ)知識、基本方法和基本技能，突出對學(xué)生專業(yè)知識和專業(yè)技能的培養(yǎng)，培養(yǎng)能夠從事軟件開發(fā)、測試、維護(hù)和軟件項目管理的高級專門人才。軟件工程是一個方法論，就是我們在開始一個項目時，大體框架一定要有這么一個概念，而具體實施時，必須根據(jù)公司一些特點，優(yōu)化項目開發(fā)的流程，這樣才是有實效的而方法論只是軟件工程的結(jié)果而已，軟件工程可以指導(dǎo)我們?nèi)绾胃鶕?jù)特定的環(huán)境制定自己的方法論。試想，如果軟件工程剛

2、剛開始就是一個方法論的話，所有的工程只需要按照這個方法去做就可以成功了，可是實際情況不是這樣。每個公司都有自己的方法論，每個行業(yè)都有自己的方法論，而軟件工程是凌駕在方法論之上的。她是眾多方法（成功的、失敗的）的抽象。1、瀑布式方法論瀑布模型將軟件生命周期的各項活動規(guī)定為依固定順序聯(lián)接的若干階段工作，形如優(yōu)點：強調(diào)開發(fā)的階段性；強調(diào)早期計劃及需求調(diào)查；強調(diào)產(chǎn)品測試。缺點：依賴于早期進(jìn)行的唯一的一次需求調(diào)查，不能適應(yīng)需求的變化；由于是單一流程，開發(fā)中的經(jīng)驗教訓(xùn)不能反饋應(yīng)用于本產(chǎn)品的過程風(fēng)險往往遲至后期的開發(fā)階段才顯露，因而失去及早糾正的機會。+十*J*tKTK*tTLJT*tI+牛ST*tFTWi

3、fi昶描|昶就BDFDDDMK1PT-STCT-UT鯉1爲(wèi)赭酣f翹城其中，BD是BasicDesign的縮寫，這一部分完成“本系統(tǒng)要做什么”的文檔記錄工作，即系統(tǒng)的分析階段工作；FD是FunctionDesign的縮寫，這一部分完成本系統(tǒng)功能塊的劃分，是“怎么去做”的第一階段工作，即系統(tǒng)的設(shè)計初期階段工作；DD是DetailDesign的縮寫，這一部分完成本系統(tǒng)各個功能模塊的詳細(xì)設(shè)計工作，是編程階段的準(zhǔn)備設(shè)計階段；MK是Making的縮寫，即具體編程實施階段；UT是UnitTest的縮寫，即單元測試階段；CT是CombineTest的縮寫，即結(jié)合測試階段；ST是SystemTest的縮寫，即系

4、統(tǒng)測試階段；PT是ProductTest的縮寫，即商品測試階段。從上圖中可以看出，BD和PT、FD和ST、DD和CT、MK和UT都是成對出現(xiàn)的。每一對的前一部分完成之后，應(yīng)該馬上著手后一部分的文檔制作工作。對較大的系統(tǒng)開發(fā)，實際測試和文檔的擔(dān)當(dāng)者應(yīng)該不同。2、生魚片式方法論前一階段完成70%到80%時，即可并行進(jìn)入到下一個階段。3、螺旋式方法論瀑布模型與演化模型相結(jié)合，并加入兩者所忽略的風(fēng)險分析所建立的一種軟件開發(fā)模型。該模型于1998年由美國TRW公司(B.W.Boehm)提出。軟件項目風(fēng)險的大小作為指引軟件過程的一個重要因素，引入這一概念有可能使得軟件開發(fā)被看作一種元模型，因為它能包容任何

5、一個開發(fā)過程模型。Ailutsn/救打/弁閱世汁產(chǎn)屈/j呀-敘匯俺工程螺旋模型基本的做法是在“瀑布模型”的每一個開發(fā)階段之前，引入非常嚴(yán)格的風(fēng)險識別、風(fēng)險分析和風(fēng)險控制。直到采取了消除風(fēng)險的措施之后，才開始計劃下一階段的開發(fā)工作。否則，項目就很可能被取消。另外，如果有充足的把握判斷遺留的風(fēng)險已降低到一定的程度，項目管理人員可作出決定讓余下的開發(fā)工作采用另外的生命周期模型，如“演化模型”，“瀑布模型”，或自定的混合模型。優(yōu)點：強調(diào)嚴(yán)格的全過程風(fēng)險管理。強調(diào)各開發(fā)階段的質(zhì)量。提供機會檢討項目是否有價值繼續(xù)下去。缺點：a引入非常嚴(yán)格的風(fēng)險識別，風(fēng)險分析，和風(fēng)險控制，這對風(fēng)險管理的技能水平提出了很高的

6、要求。這需要人員，資金，和時間的投入。4、階段性發(fā)布式方法論該模型主要針對事先不能完整定義需求的軟件開發(fā)。用戶可以給出待開發(fā)系統(tǒng)的核心需求，并且當(dāng)看到核心需求實現(xiàn)后，能夠有效地提出反饋，以支持系統(tǒng)的最終設(shè)計和實現(xiàn)。軟件開發(fā)人員根據(jù)用戶的需求，首先開發(fā)核心系統(tǒng)。當(dāng)該核心系統(tǒng)投入運行后，用戶試用之，完成他們的工作，并提出精化系統(tǒng)、增強系統(tǒng)能力的需求。軟件開發(fā)人員根據(jù)用戶的反饋，實施開發(fā)的迭代過程。第一迭代過程均由需求、設(shè)計、編碼、測試、集成等階段組成，為整個系統(tǒng)增加一個可定義的、可管理的子集。下面為生魚片型階段性發(fā)布式方法論圖示。在開發(fā)模式上采取分批循環(huán)開發(fā)的辦法，每循環(huán)開發(fā)一部分的功能，它們成為

7、這個產(chǎn)品的原型的新增功能。于是，設(shè)計就不斷地演化出新的系統(tǒng)。實際上，這個模型可看作是重復(fù)執(zhí)行的多個“生魚片方式”。5、Booch方法論Booch方法的過程包括以下步驟：在給定的抽象層次上識別類和對象識別這些對象和類的語義識別這些類和對象之間的關(guān)系實現(xiàn)類和對象這四種活動不僅僅是一個簡單的步驟序列，而是對系統(tǒng)的邏輯和物理視圖不斷細(xì)化的迭代和漸增的開發(fā)過程。類和對象的識別包括找出問題空間中關(guān)鍵的抽象和產(chǎn)生動態(tài)行為的重要機制。開發(fā)人員可以通過研究問題域的術(shù)語發(fā)現(xiàn)關(guān)鍵的抽象。語義的識別主要是建立前一階段識別出的類和對象的含義。開發(fā)人員確定類的行為（即方法）和類及對象之間的互相作用（即行為的規(guī)范描述）。該

8、階段利用狀態(tài)轉(zhuǎn)移圖描述對象的狀態(tài)的模型，利用時態(tài)圖（系統(tǒng)中的時態(tài)約束）和對象圖（對象之間的互相作用）描述行為模型。在關(guān)系識別階段描述靜態(tài)和動態(tài)關(guān)系模型。這些關(guān)系包括使用、實例化、繼承、關(guān)聯(lián)和聚集等。類和對象之間的可見性也在此時確定。在類和對象的實現(xiàn)階段要考慮如何用選定的編程語言實現(xiàn)，如何將類和對象組織成模塊。在面向?qū)ο蟮脑O(shè)計方法中，Booch強調(diào)基于類和對象的系統(tǒng)邏輯視圖與基于模塊和進(jìn)程的系統(tǒng)物理視圖之間的區(qū)別。他還區(qū)別了系統(tǒng)的靜態(tài)和動態(tài)模型。然而，他的方法偏向于系統(tǒng)的靜態(tài)描述，對動態(tài)描述支持較少。Booch方法的力量在于其豐富的符號體系，包括：類圖（類結(jié)構(gòu)靜態(tài)視圖）對象圖（對象結(jié)構(gòu)靜態(tài)視圖）

9、狀態(tài)轉(zhuǎn)移圖（類結(jié)構(gòu)動態(tài)視圖）時態(tài)圖（對象結(jié)構(gòu)動態(tài)視圖）模塊圖（模塊體系結(jié)構(gòu)）進(jìn)程圖（進(jìn)程體系結(jié)構(gòu)）用于類和對象建模的符號體系使用注釋和不同的圖符（如不同的箭頭）表達(dá)詳細(xì)的信息。Booch建議在設(shè)計的初期可以用符號體系的一個子集，隨后不斷添加細(xì)節(jié)。對每一個符號體系還有一個文本的形式，由每一個主要結(jié)構(gòu)的描述模板組成。符號體系由大量的圖符定義，但是，其語法和語義并沒有嚴(yán)格地定義。6、OMT方法論Rumbaugh的OMT方法從三個視角描述系統(tǒng)，相應(yīng)地提供了三種模型，對象模型，動態(tài)模型和功能模型。對象模型描述對象的靜態(tài)結(jié)構(gòu)和它們之間的關(guān)系。主要的概念包括：類屬性操作繼承關(guān)聯(lián)（即關(guān)系）聚集動態(tài)模型描述系統(tǒng)

10、那些隨時間變化的方面，其主要概念有：狀態(tài)子狀態(tài)和超狀態(tài)事件行為活動功能模型描述系統(tǒng)內(nèi)部數(shù)據(jù)值的轉(zhuǎn)換，其主要概念有：加工數(shù)據(jù)存儲數(shù)據(jù)流控制流角色(源/潭)該方法將開發(fā)過程分為四個階段：分析基于問題和用戶需求的描述，建立現(xiàn)實世界的模型。分析階段的產(chǎn)物有：問題描述-對象模型=對象圖+數(shù)據(jù)詞典動態(tài)模型=狀態(tài)圖+全局事件流圖功能模型=數(shù)據(jù)流圖+約束系統(tǒng)設(shè)計結(jié)合問題域的知識和目標(biāo)系統(tǒng)的體系結(jié)構(gòu)(求解域)，將目標(biāo)系統(tǒng)分解為子系統(tǒng)。該階段的主要產(chǎn)物是系統(tǒng)設(shè)計文檔：基本的系統(tǒng)體系結(jié)構(gòu)和高層次的決策。對象設(shè)計基于分析模型和求解域中的體系結(jié)構(gòu)等添加的實現(xiàn)細(xì)節(jié)，完成系統(tǒng)設(shè)計。主要產(chǎn)物包括：細(xì)化的對象模型細(xì)化的動態(tài)模型

11、細(xì)化的功能模型實現(xiàn)將設(shè)計轉(zhuǎn)換為特定的編程語言或硬件，同時保持可追蹤性、靈活性和可擴展性。7、OOSE方法論Jacobson方法（OOSE）與上述三種方法有所不同，它涉及到整個軟件生命周期，包括需求分析、設(shè)計、實現(xiàn)和測試等四個階段。需求分析和設(shè)計密切相關(guān)。需求分析階段的活動包括定義潛在的角色（角色指使用系統(tǒng)的人和與系統(tǒng)互相作用的軟、硬件環(huán)境），識別問題域中的對象和關(guān)系，基于需求規(guī)范說明和角色的需要發(fā)現(xiàn)usecase，詳細(xì)描述usecase。設(shè)計階段包括兩個主要活動，從需求分析模型中發(fā)現(xiàn)設(shè)計對象，以及針對實現(xiàn)環(huán)境調(diào)整設(shè)計模型。第一個活動包括從usecase的描述發(fā)現(xiàn)設(shè)計對象，并描述對象的屬性、行為

12、和關(guān)聯(lián)。在這里還要把usecase的行為分派給對象。在需求分析階段的識別領(lǐng)域?qū)ο蠛完P(guān)系的活動中，開發(fā)人員識別類、屬性和關(guān)系。關(guān)系包括繼承、熟悉（關(guān)聯(lián)）、組成（聚集）和通信關(guān)聯(lián)。定義usecase的活動和識別設(shè)計對象的活動，兩個活動共同完成行為的描述。Jacobson方法還將對象區(qū)分為語義對象（領(lǐng)域?qū)ο螅⒔缑鎸ο螅ㄈ缬脩艚缑鎸ο螅┖涂刂茖ο螅ㄌ幚斫缑鎸ο蠛皖I(lǐng)域?qū)ο笾g的控制）。在該方法中的一個關(guān)鍵概念就是usecase。usecase是指行為相關(guān)的事務(wù)（transaction）序列，該序列將由用戶在與系統(tǒng)對話中執(zhí)行。因此，每一個usecase就是一個使用系統(tǒng)的方式，當(dāng)用戶給定一個輸入，就執(zhí)行一

13、個usecase的實例并引發(fā)執(zhí)行屬于該usecase的一個事務(wù)?；谶@種系統(tǒng)視圖，Jacobson將usecase模型與其它五種系統(tǒng)模型關(guān)聯(lián)：領(lǐng)域?qū)ο竽Ｐ汀secase模型根據(jù)領(lǐng)域來表示。分析模型。usecase模型通過分析來構(gòu)造。設(shè)計模型。usecase模型通過設(shè)計來具體化。實現(xiàn)模型。該模型依據(jù)具體化的設(shè)計來實現(xiàn)usecase模型。測試模型。用來測試具體化的usecase模型。8、UML方法論面向?qū)ο蟮姆治雠c設(shè)計（OOA&D）方法的發(fā)展在80年代末至90年代中出現(xiàn)了一個高潮,UML是這個高潮的產(chǎn)物。軟件工程領(lǐng)域在1995年至1997年取得了前所未有的進(jìn)展,其成果超過軟件工程領(lǐng)域過去15年來

14、的成就總和。其中最重要的、具有劃時代重大意義的成果之一就是統(tǒng)一建模語言(UML:UnifiedModelingLanguage)的出現(xiàn)。在世界范圍內(nèi)，至少在近10年內(nèi),UML將是面向?qū)ο蠹夹g(shù)領(lǐng)域內(nèi)占主導(dǎo)地位的標(biāo)準(zhǔn)建模語言。UML的中心體現(xiàn)了統(tǒng)一、建模和可視化語言三個方面。統(tǒng)一是指它不僅統(tǒng)一了Booch、Rmbaugh和Jacobson的表示方法,而且對其作了進(jìn)一步(綜合了其他方法的優(yōu)勢)的發(fā)展,并最終統(tǒng)一為大眾所接受的標(biāo)準(zhǔn)建模語言。建模是指從應(yīng)用的角度看,當(dāng)采用面向?qū)ο蠹夹g(shù)設(shè)計系統(tǒng)時,首先是描述需求;其次根據(jù)需求建立系統(tǒng)的靜態(tài)模型,以構(gòu)造系統(tǒng)的結(jié)構(gòu);第三步是描述系統(tǒng)的行為。其中在第一步與第二步

15、中所建立的模型都是靜態(tài)的,包括用例圖、類圖(包含包)、對象圖、組件圖和配置圖等五個圖形，是標(biāo)準(zhǔn)建模語言UML的靜態(tài)建模機制。其中第三步中所建立的模型或者可以執(zhí)行,或者表示執(zhí)行時的時序狀態(tài)或交互關(guān)系。它包括狀態(tài)圖、活動圖、順序圖和合作圖等四個圖形,是標(biāo)準(zhǔn)建模語言UML的動態(tài)建模機制。因此，標(biāo)準(zhǔn)建模語言UML的主要內(nèi)容也可以歸納為靜態(tài)建模機制和動態(tài)建模機制兩大類?？梢暬恼Z言是指建模的要素及其關(guān)系均可用圖形要素(共9種圖形)及明確的可視性關(guān)系來表示，其種類大約有近400種，且可擴展。UML的5種建模圖歸納如下：第一類是用例圖,從用戶角度描述系統(tǒng)功能,并指出各功能的操作者。第二類是靜態(tài)圖(Stati

16、cdiagram),包括類圖、對象圖和包圖。其中類圖描述系統(tǒng)中類的靜態(tài)結(jié)構(gòu)。不僅定義系統(tǒng)中的類,表示類之間的聯(lián)系如關(guān)聯(lián)、依賴、聚合等,也包括類的內(nèi)部結(jié)構(gòu)(類的屬性和操作)。類圖描述的是一種靜態(tài)關(guān)系,在系統(tǒng)的整個生命周期都是有效的。對象圖是類圖的實例,幾乎使用與類圖完全相同的標(biāo)識。他們的不同點在于對象圖顯示類的多個對象實例,而不是實際的類。一個對象圖是類圖的一個實例。由于對象存在生命周期,因此對象圖只能在系統(tǒng)某一時間段存在。包由包或類組成,表示包與包之間的關(guān)系。包圖用于描述系統(tǒng)的分層結(jié)構(gòu)。第三類是行為圖(Behaviordiagram),描述系統(tǒng)的動態(tài)模型和組成對象間的交互關(guān)系。其中狀態(tài)圖描述類

17、的對象所有可能的狀態(tài)以及事件發(fā)生時狀態(tài)的轉(zhuǎn)移條件。通常,狀態(tài)圖是對類圖的補充。在實用上并不需要為所有的類畫狀態(tài)圖,僅為那些有多個狀態(tài)其行為受外界環(huán)境的影響并且發(fā)生改變的類畫狀態(tài)圖。而活動圖描述滿足用例要求所要進(jìn)行的活動以及活動間的約束關(guān)系,有利于識別并行活動。第四類是交互圖(Interactivediagram),描述對象間的交互關(guān)系。其中順序圖顯示對象之間的動態(tài)合作關(guān)系,它強調(diào)對象之間消息發(fā)送的順序,同時顯示對象之間的交互;合作圖描述對象間的協(xié)作關(guān)系,合作圖跟順序圖相似,顯示對象間的動態(tài)合作關(guān)系。除顯示信息交換外,合作圖還顯示對象以及它們之間的關(guān)系。如果強調(diào)時間和順序,則使用順序圖;如果強調(diào)上下級關(guān)系,則選擇合作圖。這兩種圖合稱為交互圖。第五類是實現(xiàn)圖(Implementationdiagram)。其中構(gòu)件圖描述代碼部件的物理結(jié)構(gòu)及各部件之間的依賴關(guān)系。一個部件可能是一個資源代碼部件、一個二進(jìn)制部件或一個可執(zhí)行部件。它包含邏輯類或?qū)崿F(xiàn)類的有關(guān)信息。部件圖有助于分析和理解部件之間的相互影響程度。配置圖定義系統(tǒng)中軟硬件的物理體系結(jié)構(gòu)。它可以顯示實際的計算機和設(shè)備(用節(jié)點表示)以及它們之間的連接關(guān)系,也可顯示連接的類型及部件之間的依賴性。在節(jié)點內(nèi)部,