1.軟件生命周期模型

軟件生命周期由軟件定義、軟件開發(fā)與運(yùn)維（也稱軟件維護(hù)）3個(gè)時(shí)期組成，每個(gè)時(shí)期又進(jìn)一步劃分成若干個(gè)階段。
問題定義：“要解決的問題是什么？”通過對(duì)客戶的訪問調(diào)查，系統(tǒng)分析員扼要地寫出關(guān)于問題性質(zhì)、工程目標(biāo)和工程規(guī)模的書面報(bào)告，經(jīng)過討論和必要的修改之后這份報(bào)告應(yīng)該得到客戶的確認(rèn)。
可行性研究：“對(duì)于上一個(gè)階段所確定的問題有行得通的解決辦法嗎？”可行性研究的結(jié)果是客戶做是否繼續(xù)進(jìn)行這項(xiàng)工程的決定的重要依據(jù)。
需求分析：“為了解決這個(gè)問題，目標(biāo)系統(tǒng)必須做什么”，主要是確定目標(biāo)系統(tǒng)必須具備哪些功能。在需求分析階段確定的系統(tǒng)邏輯模型是以后設(shè)計(jì)和實(shí)現(xiàn)目標(biāo)系統(tǒng)的基礎(chǔ)，因此必須準(zhǔn)確完整地體現(xiàn)用戶的要求。
總體設(shè)計(jì)：“概括地說，應(yīng)該怎樣實(shí)現(xiàn)目標(biāo)系統(tǒng)？”總體設(shè)計(jì)又稱為概要設(shè)計(jì)。
詳細(xì)設(shè)計(jì)：“應(yīng)該怎樣具體地實(shí)現(xiàn)這個(gè)系統(tǒng)呢？”就是把解法具體化?？傮w設(shè)計(jì)階段以比較抽象概括的方式提出了解決問題的辦法。
編碼和單元測(cè)試：這個(gè)階段的關(guān)鍵任務(wù)是寫出正確的容易理解、容易維護(hù)的程序模塊。
綜合測(cè)試：這個(gè)階段的關(guān)鍵任務(wù)是通過各種類型的測(cè)試（及相應(yīng)的調(diào)試）使軟件達(dá)到預(yù)定的要求。
軟件維護(hù)：維護(hù)階段的關(guān)鍵任務(wù)是，通過各種必要的維護(hù)活動(dòng)使系統(tǒng)持久地滿足用戶的需要。有四種維護(hù)：改正性維護(hù)；適應(yīng)性維護(hù)；完善性維護(hù)；預(yù)防性維護(hù)。

2.瀑布模型

特點(diǎn)：①階段間具有順序性和依賴性
②推遲實(shí)現(xiàn)的觀點(diǎn)
③質(zhì)量保證的觀點(diǎn)
優(yōu)點(diǎn)：①為項(xiàng)目提供了按階段劃分的檢查點(diǎn)。
②當(dāng)前一階段完成后，您只需要去關(guān)注后續(xù)階段。
③可在迭代模型中應(yīng)用瀑布模型。
④它提供了一個(gè)模板，這個(gè)模板使得分析、設(shè)計(jì)、編碼、測(cè)試和支持的方法可以在該模板下有一個(gè)共同的指導(dǎo)。
缺點(diǎn)：①各個(gè)階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量。
②由于開發(fā)模型是線性的，用戶只有等到整個(gè)過程的末期才能見到開發(fā)成果，從而增加了開發(fā)風(fēng)險(xiǎn)。
③通過過多的強(qiáng)制完成日期和里程碑來跟蹤各個(gè)項(xiàng)目階段。
④瀑布模型的突出缺點(diǎn)是不適應(yīng)用戶需求的變化。

3.軟件需求分析模型

結(jié)構(gòu)化分析模型的體系結(jié)構(gòu)
分析模型
實(shí)體關(guān)系圖：作為數(shù)據(jù)建模的基礎(chǔ)，描述數(shù)據(jù)對(duì)象及其關(guān)系。
數(shù)據(jù)流圖：作為功能建模的基礎(chǔ)，描述數(shù)據(jù)怎樣轉(zhuǎn)換以及轉(zhuǎn)換的功能。
狀態(tài)轉(zhuǎn)化圖：作為行為建模的基礎(chǔ)，表示系統(tǒng)的各種行為狀態(tài)以及狀態(tài)間的轉(zhuǎn)換方式。
數(shù)據(jù)字典
數(shù)據(jù)字典描述數(shù)據(jù)流圖的數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)加工（最底層加工）和數(shù)據(jù)流，他記錄的主要內(nèi)容有：基本信息；定義；使用特點(diǎn)；控制信息；其他說明。在數(shù)據(jù)字典中，數(shù)據(jù)元素的定義可以是基本元素及其組合，數(shù)據(jù)進(jìn)行自低向下的分解，知到不需要進(jìn)一步解釋且參與人員都清楚其含義為止。數(shù)據(jù)組合有三種方式：順序，選擇，重復(fù)。
結(jié)構(gòu)化分析過程

1. 創(chuàng)建實(shí)體關(guān)系圖
2. 創(chuàng)建數(shù)據(jù)流模型
3. 創(chuàng)建行為模型
4. 編寫加工規(guī)格說明
   建模步驟：
   1.通過調(diào)查研究，獲取用戶需求。
   2.去除非本質(zhì)因素，確定系統(tǒng)的真正需求。
   3.描述需求，建立系統(tǒng)的邏輯模型。
   4.書寫需求說明書，進(jìn)行需求復(fù)審。
   基本原則：
   1.能夠表達(dá)和理解問題的數(shù)據(jù)域和功能域。
   2.能夠?qū)?fù)雜的問題化簡(jiǎn)。
   3.能給出系統(tǒng)的邏輯表示和物理表示。（邏輯表示指明系統(tǒng)所要達(dá)到的功能要求和需要處理的數(shù)據(jù)，不涉及實(shí)現(xiàn)的細(xì)節(jié)）

4.軟件設(shè)計(jì)模型

軟件設(shè)計(jì)是開發(fā)階段最重要的步驟，它是軟件開發(fā)過程中質(zhì)量得以保證的關(guān)鍵步驟。根據(jù)用數(shù)據(jù)、功能和行為模型表示軟件的需求，采用某種設(shè)計(jì)方法進(jìn)行數(shù)據(jù)設(shè)計(jì)、體系結(jié)構(gòu)設(shè)計(jì)、接口設(shè)計(jì)和過程設(shè)計(jì)。
數(shù)據(jù)設(shè)計(jì)：主要來源于數(shù)據(jù)詞典和實(shí)體關(guān)系圖，數(shù)據(jù)設(shè)計(jì)將實(shí)體關(guān)系圖中描述的對(duì)象和關(guān)系，以及數(shù)據(jù)字典中描述的詳細(xì)數(shù)據(jù)內(nèi)容轉(zhuǎn)化為數(shù)據(jù)結(jié)構(gòu)的定義。
體系結(jié)構(gòu)設(shè)計(jì)：主要來源于數(shù)據(jù)流圖，體系結(jié)構(gòu)設(shè)計(jì)定義軟件系統(tǒng)各主要成分之間的關(guān)系。
接口設(shè)計(jì)：主要來源于數(shù)據(jù)流圖，接口設(shè)計(jì)根據(jù)數(shù)據(jù)流圖定義軟件內(nèi)部各成分之間、軟件與其他協(xié)調(diào)系統(tǒng)之間及軟件與用戶之間的交互機(jī)制。
過程設(shè)計(jì)：主要來源于狀態(tài)轉(zhuǎn)化圖、控制規(guī)格說明及加工規(guī)格說明，過程設(shè)計(jì)是把結(jié)構(gòu)成分轉(zhuǎn)化成軟件的過程性描述。

5.軟件測(cè)試模型

測(cè)試步驟：1.模塊測(cè)試2.子系統(tǒng)測(cè)試3.系統(tǒng)測(cè)試4.驗(yàn)收測(cè)試5.平行運(yùn)行
輸入信息：軟件配置和測(cè)試配置
單元測(cè)試
單元測(cè)試集中檢測(cè)最小單元—模塊；單元測(cè)試和編碼屬于軟件過程的同一個(gè)階段；可以應(yīng)用人工測(cè)試和計(jì)算機(jī)測(cè)試這樣兩種不同類型的測(cè)試方法；單元測(cè)試主要使用白盒測(cè)試技術(shù)，對(duì)多個(gè)模塊的測(cè)試可以并行地進(jìn)行。
測(cè)試重點(diǎn)：模塊接口；局部數(shù)據(jù)結(jié)構(gòu)；重要的執(zhí)行通路；出錯(cuò)處理通路；邊界條件。

6.噴泉模型

噴泉模型是的面向?qū)ο蟮能浖^程模型之一。
迭代是軟件開發(fā)過程中普遍存在的一種內(nèi)在屬性。經(jīng)驗(yàn)表明，軟件過程各個(gè)階段之間的迭代或一個(gè)階段內(nèi)各個(gè)工作步驟之間的迭代，在面向?qū)ο蠓缎椭斜仍诮Y(jié)構(gòu)化范型中更常見。
“噴泉”這個(gè)詞體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性。
噴泉模型的優(yōu)點(diǎn)：噴泉模型不像瀑布模型那樣，需要分析活動(dòng)結(jié)束后才開始設(shè)計(jì)活動(dòng)，設(shè)計(jì)活動(dòng)結(jié)束后才開始編碼活動(dòng)。該模型的各個(gè)階段沒有明顯的界限，開發(fā)人員可以同步進(jìn)行開發(fā)。其優(yōu)點(diǎn)是可以提高軟件項(xiàng)目開發(fā)效率，節(jié)省開發(fā)時(shí)間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過程。
噴泉模型的缺點(diǎn)：由于噴泉模型在各個(gè)開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項(xiàng)目的管理。此外這種模型要求嚴(yán)格管理文檔，使得審核的難度加大，尤其是面對(duì)可能隨時(shí)加入各種信息、需求與資料的情況。

7.OOA模型

OO = objects + classes + inheritance + communication with messages
面向?qū)ο?= 對(duì)象+類+繼承+通信
面向?qū)ο蟮姆治?0OA) 是軟件生命周期的一個(gè)階段，具有一般分析方法所共有的內(nèi)容、目標(biāo)及策略。也是使用面向?qū)ο蟮母拍?、原理、分析問題域、求解問題域的重要階段。
00A基本任務(wù)是:
運(yùn)用面向?qū)ο蟮姆椒?對(duì)問題域和系統(tǒng)責(zé)任進(jìn)行分析和理解,找出描述問題域及系統(tǒng)責(zé)任所需的對(duì)象,定義對(duì)象的屬性、服務(wù)以及它們之間的關(guān)系。目標(biāo)是建立一個(gè)符合問題域、滿足用戶功能需求的00A模型
問題域:被開發(fā)系統(tǒng)的應(yīng)用領(lǐng)域，記載現(xiàn)實(shí)世界中要由這個(gè)系統(tǒng)進(jìn)行處理的業(yè)務(wù)范圍。
系統(tǒng)責(zé)任:所開發(fā)的系統(tǒng)應(yīng)該具備的職能。
00A特點(diǎn)1
00A采用的概念與問題域的事務(wù)保持了最大程度的一致，對(duì)象、對(duì)象的屬性和操作的命名都強(qiáng)調(diào)與客觀事務(wù)保持一致。
00A特點(diǎn)2
00A模型不考慮與系統(tǒng)的具體實(shí)現(xiàn)有關(guān)的因素例如采用什么編程語言、用戶界面、數(shù)據(jù)庫(kù)等，因此00A模型獨(dú)立于具體的現(xiàn)實(shí)環(huán)境。00D則是針對(duì)系統(tǒng)的其體實(shí)現(xiàn)。
00A的目標(biāo)是:
建立一個(gè)符合問題域、滿足用戶需求的00A模型。
用面向?qū)ο蠓椒ㄩ_發(fā)軟件，通常建立3種形式的模型，分別是:
描述系統(tǒng)靜態(tài)的對(duì)象模型(類圖)
描述系統(tǒng)控制結(jié)構(gòu)的動(dòng)態(tài)模型
描述系統(tǒng)功能的功能模型
OOA過程
建立靜態(tài)模型
描述系統(tǒng)的結(jié)構(gòu)特征，類圖。
建立動(dòng)態(tài)模型
描述系統(tǒng)的動(dòng)態(tài)行為特征，交互圖、活動(dòng)圖和狀態(tài)圖。
建立功能模型
描述系統(tǒng)的功能的用力圖。
寫詳細(xì)說明
三個(gè)模型的建立不需要按順序，不分前后。

8.OOD模型

大多數(shù)系統(tǒng)的面向?qū)ο笤O(shè)計(jì)模型，在邏輯上由四大部分組成，這四大部分對(duì)應(yīng)于組成目標(biāo)系統(tǒng)的四個(gè)子系統(tǒng)，它們分別是問題子系統(tǒng)、人機(jī)交互子系統(tǒng)、任務(wù)管理子系統(tǒng)和數(shù)據(jù)管理子系統(tǒng)。

9.通用模型的建模過程

                         建模過程框圖

建模過程

1. 建模過程的信息源
   （1） 建模目的
   （2） 先驗(yàn)知識(shí)
   （3） 實(shí)驗(yàn)數(shù)據(jù)
2. 建模途徑
   （1） 演繹法
   （2） 歸納法
3. 建模的可信性
   （1） 在演繹中的可信性
   （2） 在歸納中的可信性
   （3） 在目的方面的可信性

10. 建模的整個(gè)過程

文章來源地址http://www.zghlxwxcb.cn/news/detail-450405.html

1. 先是從現(xiàn)實(shí)世界到業(yè)務(wù)模型
   由四個(gè)關(guān)鍵因素（人、事、物、規(guī)則）構(gòu)建現(xiàn)實(shí)世界的模型，UML采用被稱之為參與者的元模型作為信息來源的提供者，參與者代表了現(xiàn)實(shí)世界的“人”；UML采用被稱之為用例的一種元模型表示驅(qū)動(dòng)者的業(yè)務(wù)目標(biāo)，這個(gè)業(yè)務(wù)目標(biāo)就是現(xiàn)實(shí)世界的“事”；這件事是怎么做的，依據(jù)什么規(guī)則，通過場(chǎng)景來描述的，這些場(chǎng)景就是現(xiàn)實(shí)世界的“規(guī)則”；最后UML通過被稱之為業(yè)務(wù)的模型來代表現(xiàn)實(shí)世界的“物”。人、事、物、規(guī)則就是這樣被模型化的，于是現(xiàn)實(shí)信息轉(zhuǎn)化成業(yè)務(wù)模型，業(yè)務(wù)模型真實(shí)映射了參與者在現(xiàn)實(shí)世界的行為。
2. 從業(yè)務(wù)模型到概念模型
   UML通過被稱之為概念化的過程來建立適合計(jì)算機(jī)理解和實(shí)現(xiàn)的模型稱為分析模型，繪制分析模型最主要的元模型有○1邊界類（界面）、②實(shí)體類、③控制類（動(dòng)態(tài)、功能模型），同時(shí)軟件架構(gòu)和框架也通常在這個(gè)階段產(chǎn)生。
3. 從概念模型到設(shè)計(jì)模型
   要得到真正可執(zhí)行的代碼，需要將概念模型實(shí)例化，相當(dāng)于已經(jīng)得到細(xì)節(jié)和藍(lán)圖去建造部件和組裝的過程。概念模型中的邊界類可以轉(zhuǎn)化為操作界面或者系統(tǒng)接口；控制類可以轉(zhuǎn)化為計(jì)算機(jī)程序或控制程序；實(shí)體類可以轉(zhuǎn)化為數(shù)據(jù)庫(kù)表、XML文檔或者其他帶有持久化特征的類。可遵循的規(guī)則有：○1軟件架構(gòu)和框架、○2編程語言、○3規(guī)范或中間件。
   經(jīng)過三個(gè)步驟的轉(zhuǎn)換，就把現(xiàn)實(shí)世界轉(zhuǎn)化到計(jì)算機(jī)可執(zhí)行的語言上，如果我們把這三個(gè)模型的建立過程綜合起來就形成上圖，顯示了建模的整個(gè)過程，這一過程是有規(guī)律、可推導(dǎo)、可追溯的過程。

到了這里，關(guān)于軟件工程的十大模型的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！