第一篇：軟件工程之用例模型總結(jié)

軟件工程之用例模型總結(jié)

一、用例模型1.用例概念用例：使用系統(tǒng)時(shí)發(fā)現(xiàn)的功能性需求，不應(yīng)過于復(fù)雜，簡單的來說就是你希望系統(tǒng)能夠有什么功能，能夠增加系統(tǒng)的價(jià)值。

用例模型包括用例描述和用例圖，我們主要把中心放在用例描述上。

用例模型包含參與者和場(chǎng)景，場(chǎng)景包括成功場(chǎng)景和失敗場(chǎng)景。因此用例模型中有多個(gè)場(chǎng)景；每個(gè)場(chǎng)景是一個(gè)用例。用例必須注重為用戶提供可觀察的返回值，就是系統(tǒng)觸發(fā)了一個(gè)用例之后能夠給用戶帶來什么。

一般用例都是黑盒用例，即不考慮如何實(shí)現(xiàn)。2.Use Case Description每個(gè)用例都有一個(gè)描述。怎樣確定用例？(1)確定一個(gè)功能；

(2)寫一個(gè)用例；(1)主要參與者：調(diào)用系統(tǒng)服務(wù)完成目標(biāo)的人。(2)次要參與者：為系統(tǒng)提供服務(wù)的人。

(3)寫出每個(gè)項(xiàng)目相關(guān)人員的理想需求，從中分析功能。(4)PreCondition:執(zhí)行到這個(gè)用例之前必須為真的情況，比如必須已成功登錄或通過驗(yàn)證。

(5)PostCondition:成功執(zhí)行完此用例后的情況，比如登錄用例的后置條件是成功登錄（不考慮其他失敗情況）。(6)main flow：將最理想的步驟列出。一般main flow步驟如下：

(1)參與者發(fā)生動(dòng)作。

(2)系統(tǒng)驗(yàn)證。

(3)返回結(jié)果。

(7)extension flow：擴(kuò)展步驟,通常格式為：(1)系統(tǒng)檢測(cè)到**有問題;在main flow中的第一步擴(kuò)展，則用1a,1b,1c;3.如何確保正確的用例

EBP原則:一般用例都需要遵守這個(gè)規(guī)則，即確定主要用例。用例中的主要用例是一些重復(fù)做但是有意義的事，比如收銀員收錢，重復(fù)多次是有意義的，因?yàn)殄X收得多了；但是像登錄系統(tǒng)，這種做100次卻沒有意義的用例，不能被稱為主要用例；

(1)EBP（基本業(yè)務(wù)過程）原則的用例寫入；

(2)如果要寫編輯A，刪除A，添加A，可以合并成“管理A”； 4.用例圖

每個(gè)用例描述都是一個(gè)用例，左邊是主要參與者（希望系統(tǒng)為他提供服務(wù)）和次要參與者（提供給系統(tǒng)服務(wù)的人）；

在次要參與者中不能有數(shù)據(jù)庫，因?yàn)樵谟脩艚嵌瓤词遣恢老到y(tǒng)有數(shù)據(jù)庫的；

關(guān)系：

(1)泛化關(guān)系，在參與者和用例中都能泛化。(2)包含關(guān)系：

表示A包含B；比如A是管理數(shù)據(jù)，B可以是添加數(shù)據(jù)、刪除數(shù)據(jù)等；

(3)擴(kuò)展關(guān)系：表示D被C擴(kuò)展，D包含新的功能，比如D是查詢數(shù)據(jù)，C可以是打印數(shù)據(jù)，即用戶可以查詢但不打印數(shù)據(jù)，打印數(shù)據(jù)只是一個(gè)擴(kuò)展功能。用例描述模板 [html] view plain copy

用例模型根據(jù)系統(tǒng)邊界的確定，描述了系統(tǒng)的輸入和輸出，確定了系統(tǒng)外部的參與者，通過用例描述了系統(tǒng)的主要功能，描述了外部參與者與系統(tǒng)的交互，將系統(tǒng)作為一個(gè)黑盒，從用戶角度描繪出系統(tǒng)需要提供的功能;

Use Case：用例名稱

Actor：參與者

Precondition：前置條件，即執(zhí)行這個(gè)用例一定要滿足的條件

Postcondition：后置條件，如果成功執(zhí)行，則一定會(huì)變成的狀態(tài)

Main flow：

1.用戶開始一次會(huì)話

2.用戶輸入信息

3.系統(tǒng)驗(yàn)證并反饋

4.用戶重復(fù)2，3步

Extensions：

3a：數(shù)據(jù)無效

1.系統(tǒng)提示出錯(cuò)

第二篇：軟件工程生命周期模型的學(xué)習(xí)總結(jié)

綜述

軟件過程定義了軟件開發(fā)中采用的方法。軟件工程是集成計(jì)算機(jī)軟件開發(fā)的過程、方法和工具的學(xué)科。

軟件工程的一般視圖：定義階段（做什么）、開發(fā)階段（如何做）、支持階段（變化）。線性順序模型

有時(shí)被稱為“傳統(tǒng)生存周期或瀑布模型”。

活動(dòng)包括：系統(tǒng)/信息工程和建模、軟件需求分析、設(shè)計(jì)、代碼生成、測(cè)試、支持 為什么線性模型有時(shí)候不能奏效？

建議：雖然線性模型經(jīng)常被嘲笑為“舊式的”，但是，在需求被很好理解的情況下，它仍然是一種合理的方法。缺點(diǎn)：

1、實(shí)際的項(xiàng)目大部分情況難以按照該模型給出的順序進(jìn)行，而且這種模型的迭代是間接的，這很容易由微小的變化而造成大的混亂。

2、經(jīng)常情況下客戶難以表達(dá)真正的需求，而這種模型卻要求如此，這種模型是不歡迎具有二義性問題存在的。

3、客戶要等到開發(fā)周期的晚期才能看到程序運(yùn)行的測(cè)試版本，而在這時(shí)發(fā)現(xiàn)大的錯(cuò)誤時(shí)，可能引起客戶的驚慌，而后果也可能是災(zāi)難性的。

4、采用這種線性模型，會(huì)經(jīng)常在過程的開始和結(jié)束時(shí)碰到等待其他成員完成其所依賴的任務(wù)才能進(jìn)行下去，有可能花在等待的時(shí)間比開發(fā)的時(shí)間要長。我們稱之為“堵賽狀態(tài)”。

優(yōu)點(diǎn)：

1、它提供了一個(gè)摸板，這個(gè)摸板使得分析、設(shè)計(jì)、編碼、測(cè)試和支持的方法可以在該摸板下有一個(gè)共同的指導(dǎo)。

2、雖然有不少缺陷但比在軟件開發(fā)中隨意的狀態(tài)要好得多。

瀑布模型將軟件開發(fā)活動(dòng)分為需求分析、設(shè)計(jì)、編碼、測(cè)試等幾個(gè)階段，這幾個(gè)階段是對(duì)工程活動(dòng)的劃分，瀑布模型沒有再涉及其它方面的活動(dòng)，因此瀑布模型關(guān)注于工程活動(dòng)。

關(guān)于選取開發(fā)模型

有時(shí)開發(fā)模型的選取不是很容易判斷的，這里面有時(shí)不單是需求及開發(fā)的問題，對(duì)于開發(fā)商有開發(fā)周期、開發(fā)費(fèi)用的問題，對(duì)于用戶同樣有內(nèi)部計(jì)劃、公司發(fā)展計(jì)劃等因素進(jìn)行影響。

一般來說對(duì)于應(yīng)用開發(fā)―――為客戶開發(fā)軟件，客戶在開發(fā)及測(cè)試完畢軟件后就要實(shí)際開始使用，那么就使用瀑布模型。

當(dāng)然在需求明確的情況下自然也要使用瀑布模型

對(duì)于自主開發(fā)及客戶需求不明并有較長的設(shè)計(jì)時(shí)間―――可以用演化模型。

而螺旋模型適于適合于大型軟件開發(fā)，吸收了“演化”概念，不過有時(shí)也用于用戶需求不明的情況下。當(dāng)然還有其他開發(fā)模型，沒有在本文討論。名詞定義：

瀑布模型：規(guī)定了各項(xiàng)軟件工程活動(dòng)。包括：制定開發(fā)計(jì)劃、進(jìn)行需求分析和說明、軟件設(shè)計(jì)、程序編碼、測(cè)試及維護(hù)。

特點(diǎn)：自上而下，相互銜接的固定次序，如瀑布流水、逐級(jí)下落。

演化模型：第一次只是試驗(yàn)開發(fā)，其目標(biāo)只在于探索可行性，弄清軟件需求;第二次則在此基礎(chǔ)上獲得較為滿意的軟件產(chǎn)品，通常把一次得到的試驗(yàn)性產(chǎn)品稱“原型”。特點(diǎn)：減少由于軟件需求不明確而給開發(fā)帶來的風(fēng)險(xiǎn)。

螺旋模型：將瀑布模型及演化螺旋模型結(jié)合起來，并且加入被兩種模型都忽略了的風(fēng)險(xiǎn)分析，彌補(bǔ)了兩者的不足。

瀑布模型的特點(diǎn)：

① 瀑布模型為軟件的開發(fā)和維護(hù)提供了一種有效有管理模式，對(duì)保證軟件產(chǎn)品的質(zhì)量有重要的作用；

② 可根據(jù)這一模式制定出開發(fā)計(jì)劃，進(jìn)行成本預(yù)算，組織開發(fā)力量，以項(xiàng)目的階段評(píng)審和文檔控制為手段，有效地對(duì)整個(gè)開發(fā)過程進(jìn)行指導(dǎo)； ③ 在一定程度上消除非結(jié)構(gòu)化軟件、降低軟件的復(fù)雜度、促進(jìn)軟件開發(fā)工程化方面起到顯著作用；

④ 瀑布模型缺乏靈活性、無法通過開發(fā)活動(dòng)來澄清本來不夠確切的需求，這將導(dǎo)致直到軟件開發(fā)完成時(shí)發(fā)現(xiàn)所開發(fā)的軟件并非是用戶所需求的。原型實(shí)現(xiàn)模型

原型實(shí)現(xiàn)范型定義： 需求收集 快速設(shè)計(jì)

原型實(shí)現(xiàn)模型是迭代的，是幫助客戶或開發(fā)者理解需求的，總體上講，并不是交付一個(gè)最終產(chǎn)品系統(tǒng)。其流程從聽取客戶意見開始、隨后是建造/修改原型、客戶測(cè)試運(yùn)行原型、然后回頭往復(fù)循環(huán)直到客戶對(duì)原型滿意為止。由于這種模型可以讓客戶快速的感受到實(shí)際的系統(tǒng)（雖然這個(gè)系統(tǒng)不帶有任何質(zhì)量的保證），所以客戶和開發(fā)者都比較喜歡這種過程模型（對(duì)于那些僅僅用來演示軟件功能的公司而言或從來不考慮軟件質(zhì)量和不害怕長期維護(hù)的公司而言）。缺點(diǎn)：

1、沒有考慮軟件的整體質(zhì)量和長期的可維護(hù)性。

2、大部分情況是不合適的操作算法被采用目的為了演示功能，不合適的開發(fā)工具被采用僅僅為了它的方便，還有不合適的操作系統(tǒng)被選擇等等。

3、由于達(dá)不到質(zhì)量要求產(chǎn)品可能被拋棄，而采用新的模型重新設(shè)計(jì)。

優(yōu)點(diǎn)：

1、如果客戶和開發(fā)者達(dá)成一致協(xié)議：原型被建造僅為了定義需求，之后就被拋棄或者部分拋棄，那么這種模型很合適了。

2、迷惑客戶搶占市場(chǎng)，這是一個(gè)首選的模型。

原型實(shí)現(xiàn)仍然是軟件工程的一個(gè)有效范型。關(guān)鍵是定義開始時(shí)的游戲規(guī)則，即客戶和開發(fā)者達(dá)成一致：原型被建造僅是為了定義需求，之后就被拋棄了（或至少部分被拋棄），實(shí)際的軟件在充分考慮了質(zhì)量和可維護(hù)性之后才被開發(fā)。

建議：當(dāng)你的客戶有一個(gè)合理的續(xù)簽，但對(duì)細(xì)節(jié)沒有任務(wù)線索時(shí)，先開發(fā)一個(gè)原型。

原型模型則主要是為了解決需求獲取的難題而創(chuàng)建原型用于需求的獲取和確認(rèn)，再將需求轉(zhuǎn)化為軟件系統(tǒng)，其主要內(nèi)容集中在軟件開發(fā)本身，因此原型模型也關(guān)注于工程活動(dòng)。RAD模型

快速應(yīng)用開發(fā)（Rapid Application Development、RAD）是一個(gè)增量型的軟件開發(fā)過程模型，強(qiáng)調(diào)極短的開發(fā)周期。是線性順序模型的一個(gè)“高速”變種，通過使用基于構(gòu)件的建造發(fā)放贏得了快速開發(fā)。如果需求理解的好而且約束了項(xiàng)目的范圍，利用這種模型可以很快的創(chuàng)建出功能完善的“信息系統(tǒng)”。其流程從業(yè)務(wù)建模開始，隨后是數(shù)據(jù)建模、過程建模、應(yīng)用生成、測(cè)試及反復(fù)。RAD過程強(qiáng)調(diào)的是復(fù)用，復(fù)用已有的或開發(fā)可復(fù)用的構(gòu)件。實(shí)際上RAD采用第四代技術(shù)?；跇?gòu)件的軟件工程（不理解）適用范圍：

如果需求理解得很并且約束了項(xiàng)目范圍。主要適用于信息系統(tǒng)應(yīng)用，包括以下階段：業(yè)務(wù)建模、數(shù)據(jù)建模、過程建模、應(yīng)用生成、測(cè)試及反復(fù)。

業(yè)務(wù)建模工作流程與其他工作流程的關(guān)系如下：

業(yè)務(wù)模型是需求工作流程的一種重要輸入，用來了解對(duì)系統(tǒng)的需求。

業(yè)務(wù)實(shí)體是分析設(shè)計(jì)工作流程的一種輸入，用來確定設(shè)計(jì)模型中的實(shí)體類。

缺點(diǎn)：

1、只能用于信息系統(tǒng)。

2、對(duì)于較大的項(xiàng)目需要足夠的人力資源去建造足夠的RAD組。

3、開發(fā)者和客戶必須在很短的時(shí)間完成一系列的需求分析，任何一方配合不當(dāng)都會(huì)導(dǎo)致RAD項(xiàng)目失敗。

4、這種模型對(duì)模塊化要求比較高，如果有哪一功能不能被模塊化，那么建造RAD所需要的構(gòu)件就會(huì)有問題。

5、技術(shù)風(fēng)險(xiǎn)很高的情況下不適合這種模型。

優(yōu)點(diǎn)：

1、開發(fā)速度快，質(zhì)量有保證。

2、對(duì)信息系統(tǒng)特別有效。演化軟件過程模型

演化模型是迭代的。它的特征是：使軟件工程師漸進(jìn)地開發(fā)逐步完善的軟件版本。

5.1 增量模型

增量模型融合了線性順序模型的基本成分（重復(fù)的應(yīng)用）和原型實(shí)現(xiàn)的迭代特征。增量模型采用隨著日程時(shí)間的進(jìn)展而交錯(cuò)的線性序列。每一個(gè)線性序列產(chǎn)生軟件的一個(gè)可發(fā)布的“增量”。當(dāng)使用增量模型時(shí)，第一個(gè)增量往往是核心的產(chǎn)品，也就是說第一個(gè)增量實(shí)現(xiàn)了基本的需求，但很多補(bǔ)充的特征還沒有發(fā)布?？蛻魧?duì)每一個(gè)增量的使用和評(píng)估，都做為下一個(gè)增量發(fā)布的新特征和功能。這個(gè)過程在每一個(gè)增量發(fā)布后不斷從復(fù)，直到產(chǎn)生了最終的完善產(chǎn)品。增量模型強(qiáng)調(diào)每一個(gè)增量均發(fā)布一個(gè)可操作的產(chǎn)品。

缺點(diǎn)：

1、至始至終開發(fā)者和客戶糾纏在一起，直到完全版本出來。

優(yōu)點(diǎn)：

1、人員分配靈活，剛開始不用投入大量人力資源，當(dāng)核心產(chǎn)品很受歡迎時(shí)，可增加人力實(shí)現(xiàn)下一個(gè)增量。

2、當(dāng)配備的人員不能在設(shè)定的期限內(nèi)完成產(chǎn)品時(shí)，它提供了一種先推出核心產(chǎn)品的途徑，這樣就可以先發(fā)布部分功能給客戶，對(duì)客戶起到鎮(zhèn)靜劑的作用。

3、具有一定的市場(chǎng)。

增量模型將瀑布模型的順序化和多次迭代相結(jié)合，每個(gè)增量開發(fā)都是一次瀑布模型的過程，強(qiáng)調(diào)每一個(gè)增量均發(fā)布一個(gè)可運(yùn)行版本，以滿足客戶和市場(chǎng)的需要。增量模型主要考慮當(dāng)需要快速推出可運(yùn)行的版本，而該版本不需要完整的功能時(shí)，在工程活動(dòng)上的解決方案，因此增量模型也關(guān)注于工程活動(dòng)。

5.2 螺旋模型

這是一個(gè)演化軟件過程模型，它將原型實(shí)現(xiàn)的迭代特征和線性順序模型中控制的和系統(tǒng)化的方面結(jié)合起來。使得軟件的增量版本的快速開發(fā)成為可能。在螺旋模型中，軟件開發(fā)是一系列的增量發(fā)布。在每一個(gè)迭代中，被開發(fā)系統(tǒng)的更加完善的版本逐步產(chǎn)生。螺旋模型被劃分為若干框架活動(dòng)，也稱為任務(wù)區(qū)域。典型地，有3到6個(gè)任務(wù)區(qū)域：

1、客戶交流：建立開發(fā)者和客戶之間有效通信所需要的任務(wù)。

2、計(jì)劃：定義資源、進(jìn)度、及其它相關(guān)項(xiàng)目信息所需要的任務(wù)。

3、風(fēng)險(xiǎn)分析：評(píng)估技術(shù)的及管理的風(fēng)險(xiǎn)所需要的任務(wù)。

4、工程：建立應(yīng)用的一個(gè)或多個(gè)表示說需要的任務(wù)。

5、構(gòu)造及發(fā)布：構(gòu)造、測(cè)試、安裝和提供用戶支持所需要的任務(wù)。

6、客戶評(píng)估：基于對(duì)在工程階段產(chǎn)生的或在安裝階段實(shí)現(xiàn)的軟件表示的評(píng)估，獲得客戶反饋所需要的任務(wù)。

這是一個(gè)相對(duì)較新的模型，它的功效還需要經(jīng)歷若干年的使用方能確定下來。

缺點(diǎn)：

1、需要相當(dāng)?shù)娘L(fēng)險(xiǎn)分析評(píng)估的專門技術(shù)，且成功依賴于這種技術(shù)。

2、很明顯一個(gè)大的沒有被發(fā)現(xiàn)的風(fēng)險(xiǎn)問題，將會(huì)導(dǎo)致問題的發(fā)生，可能導(dǎo)致演化的方法失去控制。

3、這種模型相對(duì)比較新，應(yīng)用不廣泛，其功效需要進(jìn)一步的驗(yàn)證。

優(yōu)點(diǎn)：

1、對(duì)于大型系統(tǒng)及軟件的開發(fā)，這種模型是一個(gè)很好的方法。開發(fā)者和客戶能夠較好地對(duì)待和理解每一個(gè)演化級(jí)別上的風(fēng)險(xiǎn)。

螺旋模型的主要貢獻(xiàn)在于明確提出迭代概念和風(fēng)險(xiǎn)的問題，并指出在項(xiàng)目定義、需求、設(shè)計(jì)等階段均存在風(fēng)險(xiǎn)，需要重點(diǎn)考慮，并通過多次迭代的原型主動(dòng)誘發(fā)風(fēng)險(xiǎn)。風(fēng)險(xiǎn)管理不屬于工程活動(dòng)的范圍，但我們?nèi)匀徽J(rèn)為螺旋模型的主要內(nèi)容是工程方面的：因?yàn)閷?duì)于非工程活動(dòng)，螺旋模型僅考慮了風(fēng)險(xiǎn)問題，而風(fēng)險(xiǎn)管理僅是非工程活動(dòng)的一個(gè)小部分，不足以依此推斷螺旋模型主要關(guān)注于非工程活動(dòng)。

5.3 WINWIN螺旋模型

螺旋模型提出了強(qiáng)調(diào)客戶交流的一個(gè)框架活動(dòng)。該活動(dòng)的目標(biāo)是從客戶處誘導(dǎo)項(xiàng)目需求。在理想情況下，開發(fā)者簡單地詢問客戶需要什么,而客戶提供足夠的細(xì)節(jié)進(jìn)行下去。不幸的是這種情形很少發(fā)生。在現(xiàn)實(shí)中，客戶和開發(fā)者進(jìn)入一個(gè)談判過程，客戶被要求在成本和應(yīng)市之間的約束下平衡功能、性能、和其它產(chǎn)品或系統(tǒng)特征。最好的談判追求“雙贏”結(jié)果，也就是說通過談判客戶獲得大部份系統(tǒng)的功能，而開發(fā)者則獲得現(xiàn)實(shí)的和可達(dá)到的預(yù)算和時(shí)限。對(duì)客戶的交流定義了下面的活動(dòng)：

1、系統(tǒng)或子系統(tǒng)的關(guān)鍵“風(fēng)險(xiǎn)承擔(dān)者”的標(biāo)識(shí)。

2、風(fēng)險(xiǎn)承擔(dān)者的“贏條件”的確定。

3、風(fēng)險(xiǎn)承擔(dān)者的贏條件談判，以將它們協(xié)調(diào)為一組滿足各方考慮的雙贏條件。

缺點(diǎn)：

1、需要額外的談判技巧。

優(yōu)點(diǎn)：

1、客戶和開發(fā)者達(dá)到一種平衡。

5.4 并發(fā)開發(fā)模型

這種模型關(guān)注于多個(gè)任務(wù)的并發(fā)執(zhí)行，表示為一系列的主要技術(shù)活動(dòng)、任務(wù)及它們的相關(guān)狀態(tài)。并發(fā)過程模型是由客戶要求、管理決策、評(píng)審結(jié)果驅(qū)動(dòng)的。該模型不是將軟件工程活動(dòng)限定為一個(gè)順序的事件序列，而是定義了一個(gè)活動(dòng)網(wǎng)絡(luò)。網(wǎng)絡(luò)上的每一個(gè)活動(dòng)均可于其它活動(dòng)同時(shí)發(fā)生。這種模型可以提供一個(gè)項(xiàng)目的當(dāng)前狀態(tài)的準(zhǔn)確視圖。

缺點(diǎn)：暫時(shí)無

優(yōu)點(diǎn)：

1、可用于所有類型的軟件開發(fā)，而對(duì)于客戶/服務(wù)器結(jié)構(gòu)更加有效。

2、可以隨時(shí)查閱到開發(fā)的狀態(tài)。基于構(gòu)件的開發(fā)模型

面向?qū)ο蟮募夹g(shù)為軟件工程的基于構(gòu)件的過程模型提供了技術(shù)框架。面向?qū)ο竽Ｐ蛷?qiáng)調(diào)了類的創(chuàng)建、類的封裝了的數(shù)據(jù)、操縱該數(shù)據(jù)的算法。一般來講經(jīng)過合適的設(shè)計(jì)和實(shí)現(xiàn)，面向?qū)ο蟮念惪梢栽诓煌膽?yīng)用及基于計(jì)算機(jī)的系統(tǒng)的體系結(jié)構(gòu)中復(fù)用?；跇?gòu)件的開發(fā)模型融合了螺旋模型的許多特征，它本質(zhì)上是演化形的，要求軟件創(chuàng)建的迭代方法。然而基于構(gòu)件的開發(fā)模型是利用預(yù)先包裝好的軟件構(gòu)件（有時(shí)成為類）來構(gòu)造應(yīng)用。

開發(fā)活動(dòng)從候選類的標(biāo)識(shí)開始，這一步是通過檢查將被應(yīng)用系統(tǒng)操縱的數(shù)據(jù)及用于實(shí)現(xiàn)該操縱的算法來完成的。相關(guān)的數(shù)據(jù)和算法被封裝成一個(gè)類。

缺點(diǎn)：

1、過分依賴于構(gòu)件，構(gòu)件庫的質(zhì)量影響著產(chǎn)品質(zhì)量。

優(yōu)點(diǎn)：

1、構(gòu)件可復(fù)用。提高了開發(fā)效率。

2、采用了面向?qū)ο蟮募夹g(shù)。形式化方法模型

形式化方法模型包含了一組活動(dòng)，他們導(dǎo)致了計(jì)算機(jī)軟件的數(shù)學(xué)規(guī)約。形式化方法使得軟件工程師們能夠通過應(yīng)用一個(gè)嚴(yán)格的數(shù)學(xué)符號(hào)體系來規(guī)約、開發(fā)、和驗(yàn)證基于計(jì)算機(jī)的系統(tǒng)。這種方法的一個(gè)變種，稱為凈室軟件工程，已經(jīng)被一些組織所采用。在開發(fā)中使用形式化方法時(shí)，它們提供了一種機(jī)制，能夠消除使用其它軟件過程模型難以克服的很多問題。二義性、不完整性、不一致性能被更容易地發(fā)現(xiàn)和糾正，而不是通過專門的評(píng)審，是通過對(duì)應(yīng)用的數(shù)學(xué)分析。形式化方法提供了可以產(chǎn)生無缺陷軟件的承諾。

缺點(diǎn)：

1、開發(fā)費(fèi)用昂貴（對(duì)開發(fā)人員需要多方面的培訓(xùn)），而且需要的時(shí)間較長。

2、不能將這種模型作為對(duì)客戶通信的機(jī)制，因?yàn)榭蛻魧?duì)這些數(shù)學(xué)語言一無所知。

3、目前還不流行。

優(yōu)點(diǎn)：

1、形式化規(guī)約可直接作為程序驗(yàn)證的基礎(chǔ)，可以盡早的發(fā)現(xiàn)和糾正錯(cuò)誤（包括那些其它情況下不能發(fā)現(xiàn)的錯(cuò)誤）。

2、開發(fā)出來的軟件具有很高的安全性和健壯性，特別適合安全部門或者軟件錯(cuò)誤會(huì)造成經(jīng)濟(jì)損失的開發(fā)者。

3、具有開發(fā)無缺陷軟件的承諾。第四代技術(shù)

一系列的軟件工具的使用，是第四代技術(shù)的特點(diǎn)。這些工具有一個(gè)共同的特點(diǎn)：能夠使軟件工程師們?cè)谳^高級(jí)別上規(guī)約軟件的某些特征，然后根據(jù)開發(fā)者的規(guī)約自動(dòng)生成源代碼。我們知道，軟件在越高的級(jí)別上被規(guī)約，就越能被快速的建造出程序。軟件工程的4GT模型集中于規(guī)約軟件的能力：使用特殊的語言形式或一種采用客戶可以理解的術(shù)語描述待解決問題的圖形符號(hào)體系。和其它模型一樣，4GT也是從需求收集這一步開始的，要將一個(gè)4GT實(shí)現(xiàn)變成最終產(chǎn)品，開發(fā)者還必須進(jìn)行徹底的測(cè)試、開發(fā)有意義的文檔，并且同樣要完成其它模型中同樣要求的所有集成活動(dòng)?？偠灾?，4GT已經(jīng)成為軟件工程的一個(gè)重要方法。特別是和基于構(gòu)件的開發(fā)模型結(jié)合起來時(shí)，4GT模型可能成為當(dāng)前軟件開發(fā)的主流模型！

缺點(diǎn)：

1、用工具生成的源代碼可能是“低效”的。

2、生成的大型軟件的可維護(hù)性目前還令人懷疑。

3、在某些情況下可能需要更多的時(shí)間。

優(yōu)點(diǎn)：

1、縮短了軟件開發(fā)時(shí)間，提高了建造軟件的效率。

2、對(duì)很多不同的應(yīng)用領(lǐng)域提供了一種可行性途徑和解決方案 9 過程技術(shù) 產(chǎn)品和過程 11 附錄

第三篇：軟件工程題例

【例1】某裝配廠有一個(gè)存放零件的倉庫，倉庫中現(xiàn)有的各種零件的數(shù)量及每種零件的庫存量臨界值等數(shù)據(jù)記錄在庫存清單主文件中。當(dāng)倉庫中零件數(shù)量有變化時(shí)，應(yīng)該及時(shí)修改庫存清單主文件；如果哪種零件的庫存量少于它的庫存量臨界值，則應(yīng)該報(bào)告給采購部門以便訂貨，規(guī)定每天向采購部門送一次訂貨報(bào)告。

該裝配廠使用一臺(tái)小型計(jì)算機(jī)處理更新庫存清單主文件和產(chǎn)生訂貨報(bào)告的任務(wù)。零件庫存量的每一次變化稱為一個(gè)事務(wù)，由放在倉庫中的CRT終端輸入到計(jì)算機(jī)中；系統(tǒng)中的庫存清單程序?qū)κ聞?wù)進(jìn)行處理，更新存儲(chǔ)在磁盤上的庫存清單主文件，并且把必要的訂貨信息寫在磁帶上。最后，每天由報(bào)告生成程序讀一次磁帶，并且打印出訂貨報(bào)告。下圖所示的系統(tǒng)流程圖描繪了上述系統(tǒng)的概貌。

事務(wù)庫存清單主文件庫存清單程序訂貨信息報(bào)告生成程序訂貨報(bào)告

例1 【例2】利用Visio繪制如下圖所示的數(shù)據(jù)流圖。

D1庫存信息庫存清單1.11.21.32倉庫管理員事務(wù)接收事務(wù)事務(wù)更新庫存庫存信息處理訂貨清單訂貨報(bào)表產(chǎn)生報(bào)表采購員訂貨信息D2訂貨信息訂貨信息

例2 【例3】車輛購置業(yè)務(wù)流程

總工程師1.2總經(jīng)理批復(fù)基礎(chǔ)設(shè)施購置申請(qǐng)單（公司所有）二級(jí)公司1.31.1二級(jí)公司基礎(chǔ)設(shè)施購置申請(qǐng)單基礎(chǔ)設(shè)施購置申請(qǐng)單（公司所有）基礎(chǔ)設(shè)施購置申請(qǐng)單（融資掛靠）審批購車技術(shù)機(jī)務(wù)部1.4生產(chǎn)經(jīng)營處車輛調(diào)撥通知單二級(jí)公司各類單據(jù)發(fā)票下調(diào)撥單并插入設(shè)備臺(tái)帳客貨經(jīng)營處財(cái)務(wù)處車輛購置登記表汽車履歷及規(guī)格記錄二級(jí)公司 例3 試完成飛機(jī)訂票系統(tǒng)的業(yè)務(wù)流程圖，系統(tǒng)描述如下： 為了方便旅客，某航空公司擬開發(fā)一個(gè)機(jī)票預(yù)定系統(tǒng)。旅行社把預(yù)定機(jī)票的旅客信息（姓名、性別、工作單位、身份證號(hào)碼、旅行時(shí)間、旅行目的地等）輸入該系統(tǒng)，系統(tǒng)為旅客安排航班，旅客在飛機(jī)起飛前一天憑取票通知和賬單交款取票，系統(tǒng)核對(duì)無誤即印出機(jī)票給顧客。

P1.3 P1.1 訂票信息P1.2 訂票信息打印取票輸入旅客查詢機(jī)票通知及賬基本信息信息單訂單通知及賬單旅客訂票信息旅客機(jī)票機(jī)票預(yù)訂系統(tǒng)取票通知及賬單旅客已付款證明D1 機(jī)票信息系統(tǒng)機(jī)票D1 航班信息表航班信息要求的機(jī)票信息P1.5 取票取票證明P1.4 得到已付款證明付款旅客旅客符合要求的機(jī)票P2 符合旅客要求的余票訂票信息D2 訂票信息表例4

第四篇：軟件工程總結(jié)

1.Software is a product and can be manufactured using the same technologies used for other engineering artifacts Answer: b 2.WebApps are a mixture of print publishing and software development, making their development outside the realm of software engineering practice.Answer: b 3.Software engineering umbrella activities are only applied during the initial phases of software development projects.Answer: b 4.Planning ahead for software reuse reduces the cost and increases the value of the systems into which they are incorporated.Answer: a 5.The essence of software engineering practice might be described as understand the problem, plan a solution, carry out the plan, and examine the result for accuracy.Answer: a 6.In agile process models the only deliverable work product is the working program.Answer: b 7.A most software development projects are initiated to try to meet some business need.Answer: a 8.In general software only succeeds if its behavior is consistent with the objectives of its designers.Answer: b 9.Software processes can be constructed out of pre-existing software patterns to best meet the needs of a software project.Answer: a 10.Process technology tools allow software organizations to compress schedules by skipping unimportant activities.Answer: b 11.It is generally accepted that one cannot have weak software processes and create high quality end products.Answer: a 1.Requirements engineering is a generic process that does not vary from one software project to another.Answer: a 2.A stakeholder is anyone who will purchase the completed software system under development.Answer: b 3.It is relatively common for different customers to propose conflicting requirements, each arguing that his or her version is the right one.Answer: a 4.Developers and customers create use-cases to help the software team understand how different classes of end-users will use functions.Answer: a 5.Use-case actors are always people, never system devices.Answer: b 6.Analysis patterns facilitate the transformation of the analysis model into a design model by suggesting reliable solutions to common problems.Answer: a 7.In win-win negotiation, the customer’s needs are met even though the developer’s need may not be.Answer: b 8.In requirements validation the requirements model is reviewed to ensure its technical feasibility.Answer: b

1.Object-oriented domain analysis is concerned with the identification and specification of reusable capabilities within an application domain.Answer: a 2.In structured analysis models focus on the structure of the classes defined for a system along with their interactions.Answer: b 3.Creation and refinement of use cases if an important part of scenario-based modeling.Answer: a 4.It is important to consider alternative actor interactions when creating a preliminary use case.Answer: b 5.Brainstorming is one technique that may be used to derive a complete set of use case exceptions.Answer: a 6.In many cases there is no need to create a graphical representation of a usage scenario.Answer: a 7.One or more attributes of a data object must be defined as a key to allow the location of an instance of the data object.Answer: a 8.Attributes are chosen for an object by examining the problem statement and identifying the entities that appear to be related.Answer: b 9.An analysis package involves the categorization of analysis model elements into useful groupings.Answer: a 10.The data flow diagram must be augmented by min-spec that can serve as a guide the design of the software component that will implement the process.Answer: a 11.The UML sequence diagram show the order in which system events are processed.Answer: b 12.Analysis patterns are discovered, they are not explicitly created.Answer: a 13.It is not possible to justify the time required for WebApp requirements analysis.Answer: b 14.UML activity diagrams can be used to represent the user observable functionality delivered by the WebApp as well as the operations contained in each analysis class.Answer: a 15.Configuration analysis focuses on the architecture of the user’s web browsing environment.Answer: b 16.Content objects are extracted from use cases by examining the scenario description for direct or indirect content references.Answer: a 1.With thorough testing it is possible to remove all defects from a program prior to delivery to the customer.Answer: b 2.Program flow graphs are identical to program flowcharts.Answer: b 3.The cyclomatic complexity of a program can be computed directly from a PDL representation of an algorithm without drawing a program flow graph.Answer: a 4.Graph-based testing methods can only be used for object-oriented systems Answer: b 5.Equivalence testing divides the input domain into classes of data from which test cases can be derived to reduce the total number of test cases that must be developed.Answer: a 6.Boundary value analysis can only be used to do white-box testing.Answer: b 7.Orthogonal array testing enables the test designer to maximize the coverage of the test cases devised for relatively small input domains.Answer: a 8.Client/server architectures cannot be properly tested because network load is highly variable.Answer: b 1.The best representation of system architecture is an operational software prototype.Answer: b 2.The architectural representations can be an enabler for communication among project stakeholders.Answer: a 3.An architectural description is often documented using an architecture template.Answer: b 4.An architectural genre will often dictate the architectural approach that may used for the structure to be built.Answer: a 5.Before an architectural pattern can be chosen for use in a specific system it must have a code implementation to facilitate its reuse.Answer: b 6.Once selected, archetypes always need to be refined further as architectural design proceeds.Answer: a 7.Quantitative methods for assessing the quality of proposed architectural designs are readily available.Answer: b

Chapter 10 Self-Check Quiz

1.In the most general sense a component is a modular building block for computer software.a.True b.False

Answer: a(Section 10.1)

2.In the context of object-oriented software engineering a component contains

a.attributes and operations b.instances of each class c.roles for each actor(device or user)d.set of collaborating classes

Answer: d(Section 10.1.1)

3.In traditional software engineering modules must serve in which of the following roles?

a.Control component b.Infrastructure component c.Problem domain component d.All of the above

Answer: d(Section 10.1.2)

4.Software engineers always need to cerate components from scratch in order to meet customer expectations fully.a.True b.False

Answer: b(Section 10.1.3)

5.Which of the following is not one of the four principles used to guide component-level design?

a.Dependency Inversion Principle b.Interface Segregation Principle c.Open-Closed Principle d.Parsimonious Complexity Principle

Answer: d(Section 10.2.1)

6.The use of stereotypes can help identify the nature of components at the detailed design level.a.True b.False

Answer: a(Section 10.2.2)

7.Classes and components that exhibit functional, layer, or communicational cohesion are relatively easy to implement, test, and maintain.a.True b.False

Answer: a(Section 10.2.3)

8.Software coupling is a sign of poor architectural design and can always be avoided in every system.a.True b.False

Answer: b(Section 10.2.4)

9.WebApp content design at the component level focuses on content objects and the manner in which they interact.a.True b.False

Answer: b(Section 10.4.1)

10.A WebApp functional architecture describes the key functional components and how they interact with each other.a.True b.False

Answer: a(Section 10.4.2)

11.Which of these is a graphical notation for depicting procedural detail?

a.box diagram b.decision table c.ER diagram d.flowchart

Answer: d(Section 10.5.1)

12.A decision table should be used

a.to document all conditional statements b.to guide the development of the project management plan c.only when building an expert system d.when a complex set of conditions and actions appears in a component

Answer: d(Section 10.5.2)

13.A program design language(PDL)is often a

a.combination of programming constructs and narrative text b.legitimate programming language in its own right c.machine readable software development language d.useful way to represent software architecture

Answer: a(Section 10.5.3)

14.In component-based software engineering, the development team examines the requirements to see which are amenable to composition, rather than construction, before beginning detailed design tasks.a.True b.False

Answer: a(Section 10.6)

15.Which of the following is not one of the major activities of domain engineering?

a.analysis b.construction c.dissemination d.validation

Answer: d(Section 10.6.1)

16.Which of the following factors would not be considered during component qualification?

a.application programming interface(API)b.development and integration tools required c.exception handling d.testing equipment required

Answer: d(Section 10.6.2)

17.Which is the following is a technique used for component wrapping?

a.black-box wrapping b.clear-box wrapping c.gray-box wrapping d.white-box wrapping

Answer: b(Section 10.6.2)

18.Which of the following is not one of the issues that form a basis for design for reuse?

a.object-oriented programming b.program templates c.standard data d.standard interface protocols

Answer: a(Section 10.6.3)

19.In a reuse environment, library queries are often characterized using the ________ element of the 3C Model.a.concept b.content c.context d.all of the above

Answer: c(Section 10.6.4)

1.The importance of software design can be summarized in a single word a.b.c.d.Answer: d(Section 8.1)

2.Which of the following is not a characteristic common to all design methods?

a.configuration management b.functional component representation c.quality assessment guidelines d.refinement heuristics

Answer: a(Section 8.2.2)

3.Which of the following can be used to represent the architectural design of a piece of software?

a.Dynamic models b.Functional models c.Structural models d.All of the above

Answer: d(Section 8.3.2)

4.Design patterns are not applicable to the design of object-oriented software?

a.True b.False

Answer: b(Section 8.3.3)

5.Since modularity is an important design goal it is not possible to have too many modules in a proposed design.a.True b.False

Answer: b(Section 8.3.5)

6.Information hiding makes program maintenance easier by hiding data and procedure from unaffected parts of the program.accuracy complexity efficiency quality

a.True b.False

Answer: a(Section 8.3.6)

7.Cohesion is a qualitative indication of the degree to which a module

a.can be written more compactly.b.focuses on just one thing.c.is able to complete its function in a timely manner.d.is connected to other modules and the outside world.Answer: b(Section 8.3.7)

8.Coupling is a qualitative indication of the degree to which a module

a.can be written more compactly.b.focuses on just one thing.c.is able to complete its function in a timely manner.d.is connected to other modules and the outside world.Answer: d(Section 8.3.7)

9.When using structured design methodologies the process of stepwise refinement is unnecessary.a.True b.False

Answer: b(Section 8.3.8)

10.Software designs are refactored to allow the creation of software that is easier to integrate, easier to test, and easier to maintain.a.True b.False

Answer: a(Section 8.3.10)

11.Which of the following is not one of the five design class types

a.Business domain classes b.Entity classes c.Process classes d.User interface classes

Answer: b(Section 8.3.13)

12.Which design model elements are used to depict a model of information represented from the user’s view?

a.Architectural design elements b.Component-level design elements c.Data design elements d.Interface design elements

Answer: c(Section 8.4.1)

13.Which design is equivalent to the floor plan of a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: a(Section 8.4.2)

14.Which design model is equivalent to the detailed drawings of the access points and external utilities for a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: d(Section 8.4.3)

15.Which design model is equivalent to a set of detailed drawings for each room in a house?

a.Architectural design b.Component-level design c.Data design d.Interface design

Answer: b(Section 8.4.4)

16.The deployment design elements specify the build order for the software components.a.True b.False

Answer: b(Section 8.4.5)

第五篇：軟件工程總結(jié)

第一章軟件與軟件工程的概念

軟件的概念：軟件是計(jì)算機(jī)系統(tǒng)中與硬件相互依存的另一部分，軟件包括程序，數(shù)據(jù)，及其相關(guān)文檔的完整集合。程序是按事先設(shè)計(jì)的功能和性能要求執(zhí)行的指令序列。數(shù)據(jù)是使程序能夠正確地處理信息的數(shù)據(jù)結(jié)構(gòu)。文檔是與程序開發(fā)，維護(hù)和使用有關(guān)的圖文資料。

程序的最小單位是函數(shù)及子程序，程序與數(shù)據(jù)是分離的，在面向?qū)ο蟪绦蛟O(shè)計(jì)時(shí)代，程序的最小單位是類，在類中封裝了相關(guān)的數(shù)據(jù)及指令代碼。

軟件的特性，判斷正誤：1.軟件是無形的、不可見的邏輯實(shí)體，因此，軟件是無法描述的。（錯(cuò)）

2、軟件的開發(fā)特性是指軟件需要大量手工勞動(dòng)，難以自動(dòng)化生產(chǎn)。（對(duì)）

3、有缺陷的軟件就是廢品。（錯(cuò)）

4、軟件的生產(chǎn)指的是軟件的復(fù)制。（錯(cuò)）

5、由于軟件的開發(fā)充滿人的個(gè)性特點(diǎn)，因此管理并不決定軟件開發(fā)的成敗（錯(cuò)）。

6、軟件的開發(fā)環(huán)境往往就是軟件的運(yùn)行環(huán)境，或者與其兼容。（對(duì)）

7、合格的軟件產(chǎn)品不需要維護(hù)，軟件需要維護(hù)說明其質(zhì)量不合格。（錯(cuò)）

8、軟件可以不斷改進(jìn)，因此軟件不需要廢棄。（錯(cuò)）

軟件的分類：1，系統(tǒng)軟件：能與計(jì)算機(jī)硬件緊密配合在一起，使計(jì)算機(jī)系統(tǒng)各個(gè)部件，相關(guān)的軟件和數(shù)據(jù)協(xié)調(diào)，高效的工作的軟件。2，應(yīng)用軟件，是在系統(tǒng)軟件的支持下，在特定區(qū)域內(nèi)開發(fā)，為特定目的服務(wù)的一類軟件。3，支撐軟件，也叫工具軟件，是協(xié)助用戶開發(fā)軟件的工具性軟件。4，可復(fù)用軟件，最初實(shí)現(xiàn)的典型的可復(fù)用軟件是各種標(biāo)準(zhǔn)函數(shù)庫，通常是由計(jì)算機(jī)廠商提供的系統(tǒng)軟件的一部分。

IEEE給出的定義：軟件工程是開發(fā)，運(yùn)行，維護(hù)和修復(fù)軟件的系統(tǒng)方法。軟件的定義：計(jì)算機(jī)程序，方法，規(guī)則，相關(guān)的文檔資料一集在計(jì)算機(jī)上運(yùn)行時(shí)所必需的數(shù)據(jù)。

軟件危機(jī)的典型表現(xiàn)

1、成本太高，預(yù)算不準(zhǔn)

2、超過預(yù)計(jì)時(shí)間

3、軟件質(zhì)量標(biāo)準(zhǔn)不明確

4、生產(chǎn)率低

5、缺乏文檔資料，難以維護(hù)。原因：1，缺乏軟件開發(fā)的經(jīng)驗(yàn)和有關(guān)軟件開發(fā)數(shù)據(jù)的積累，使得開發(fā)工作的計(jì)劃很難制定。2.軟件人員與用戶的交流存在障礙，除了知識(shí)背景的差異，缺少合適的交流方法及需求描述工具。3，軟件開發(fā)過程不規(guī)范，缺少方法和規(guī)范的指導(dǎo)。4，隨著軟件規(guī)模的增大，其復(fù)雜性往往會(huì)呈指數(shù)級(jí)升高。5，缺少有效的軟件評(píng)測(cè)手段，提交用戶的軟件質(zhì)量差。

軟件危機(jī)發(fā)生的主要原因有：

1、遇到了無法解決的高難度技術(shù)問題（不是）

2、無法招聘到足夠的編程高手（不是）

3、軟件人員與用戶互相不理解（是）

4、計(jì)劃和管理不科學(xué)、落實(shí)不力（是）

5、軟件質(zhì)量標(biāo)準(zhǔn)不明確（是）

軟件的質(zhì)量特性包括（選擇）問題1：

1、功能性

2、可靠性

3、使用性

4、經(jīng)濟(jì)性（不包括）

軟件的質(zhì)量特性包括（選擇）問題2：

1、效率

2、可維護(hù)性

3、可移植性

4、經(jīng)濟(jì)性（不包括）

軟件工程的目標(biāo)是運(yùn)用先進(jìn)的軟件開發(fā)技術(shù)和管理方法來提高軟件的質(zhì)量和生產(chǎn)率，也就是要以較短的周期，較低的成本生產(chǎn)出高質(zhì)量的軟件產(chǎn)品，并最終實(shí)現(xiàn)軟件的工業(yè)化生產(chǎn)。軟件生存期：軟件的孕育，誕生，成長，成熟，衰亡的生存過程。軟件生存期由軟件定義，軟件開發(fā)和運(yùn)行維護(hù)三個(gè)時(shí)期組成，每個(gè)時(shí)期又可劃分為若干個(gè)階段。

2、軟件定義時(shí)期的任務(wù)主要任務(wù)是解決“做什么”的問題，確定工程的總目標(biāo)和可行性；實(shí)現(xiàn)工程目標(biāo)的策略及系統(tǒng)功能；估計(jì)需要的資源和成本；制訂工程進(jìn)度表。通常又分為3個(gè)階段：問題定義，可行性研究，需求分析。

3、軟件開發(fā)時(shí)期的任務(wù)和包含階段主要任務(wù)是解決“如何做”的問題，設(shè)計(jì)和實(shí)現(xiàn)定義的軟件。由概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼和測(cè)試4個(gè)階段組成。

4、軟件運(yùn)行維護(hù)時(shí)期的主要任務(wù)是使軟件持久地滿足用戶的需要，通常有4類維護(hù)活動(dòng)：改正性維護(hù)；適應(yīng)性維護(hù)；完善性維護(hù)；預(yù)防性維護(hù)。開發(fā)過程中的典型文檔：軟件需求規(guī)格說明書。項(xiàng)目計(jì)劃。軟件測(cè)試計(jì)劃。軟件設(shè)計(jì)說明書。用戶手冊(cè)。軟件工程各個(gè)階段的基本任務(wù)

1、問題定義與可行性研究：解決什么問題？能否解決問題？是否值得做？”

2、需求分析：做什么

3、軟件設(shè)計(jì)：如何實(shí)現(xiàn)

4、程序編碼和單元測(cè)試：實(shí)現(xiàn)設(shè)計(jì)

5、集成和系統(tǒng)測(cè)試：組裝連接測(cè)試、功能驗(yàn)證測(cè)試

6、軟件運(yùn)行和維護(hù)：修改 第二章軟件工程方法與工具

軟件工具：是指能支持軟件生存周期中某一階段（如系統(tǒng)定義，需求分析，設(shè)計(jì)，編碼，測(cè)試，維護(hù)等）的需要而使用的軟件工具。

需求分析工具

1、結(jié)構(gòu)化圖形工具箱。通過數(shù)據(jù)流程圖DFD進(jìn)行功能分析。包括DFD圖形工具，實(shí)體-關(guān)系圖(E-R)圖形工具，Jackson圖形工具，Warnier圖形工具，Visio綜合工具，2、面向?qū)ο蠊ぞ?，Rational Rose，PowerDesigner，Visio 設(shè)計(jì)工具（1)概要設(shè)計(jì)工具：設(shè)計(jì)目標(biāo)軟件的體系結(jié)構(gòu)、控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)。軟件的體系結(jié)構(gòu)通常用模塊結(jié)構(gòu)圖來描述。模塊的數(shù)據(jù)結(jié)構(gòu)通常用實(shí)體-關(guān)系圖來描述。Visio。Rational Rose 詳細(xì)設(shè)計(jì)工具。設(shè)計(jì)模塊的算法和內(nèi)部實(shí)現(xiàn)細(xì)節(jié)。詳細(xì)設(shè)計(jì)描述方法有輸入-處理-輸出(IPO)圖。問題分析圖(PAD)。盒圖(NS圖)。流程圖(FC)。程序設(shè)計(jì)語言(PDL)。結(jié)構(gòu)化語言。判定表。判定樹

第三章軟件需求獲取與結(jié)構(gòu)化分析方法 需求獲取的主要任務(wù)是與用戶溝通，了解系統(tǒng)或產(chǎn)品的目標(biāo)是什么，客戶或用戶想要實(shí)現(xiàn)什么，系統(tǒng)和產(chǎn)品如何滿足業(yè)務(wù)的要求，最終系統(tǒng)或產(chǎn)品如何用于日常工作。獲取并理解用戶的需求是軟件工程師所面對(duì)的最困難的任務(wù)之一。

需求分析的困難體現(xiàn)：系統(tǒng)的目標(biāo)或范圍問題；需求不準(zhǔn)確性問題；需求的易變問題

需求獲取的任務(wù)：發(fā)現(xiàn)和分析問題，并分析問題的原因，結(jié)果關(guān)系。與用戶進(jìn)行各種方式的交流，并使用調(diào)查研究方法收集信息。按照三個(gè)成分即數(shù)據(jù)，過程和接口觀察問題的不同側(cè)面。將獲取的需求文檔化，形式有用例，決策表，決策樹等。需求獲取的原則：深入淺出，以流程為主線。

獲取具體的需求的途徑1，與用戶交流。2，現(xiàn)有產(chǎn)品或競(jìng)爭產(chǎn)品的描述文檔。3，系統(tǒng)需求規(guī)格說明。4，當(dāng)前系統(tǒng)的問題報(bào)告和改進(jìn)要求。5，市場(chǎng)調(diào)查和用戶問卷調(diào)查。6，觀察用戶如何工作。

關(guān)于需求獲取問題的認(rèn)識(shí)辨析：

1、沒有與用戶交流就不可能獲取系統(tǒng)需求。（不能獲取準(zhǔn)確、全面的系統(tǒng)需求）

2、沒有經(jīng)過與用戶交流而獲取的需求都是不真實(shí)的需求。（一些需求從用戶以外的途徑獲取）

3、系統(tǒng)開發(fā)必須獨(dú)立完成，參考類似系統(tǒng)及技術(shù)文檔屬于抄襲行為，應(yīng)予避免。（系統(tǒng)開發(fā)包含研究行為，應(yīng)了解對(duì)手產(chǎn)品，取長補(bǔ)短）

4、系統(tǒng)開發(fā)包含改進(jìn)當(dāng)前系統(tǒng)的缺陷和不足。（對(duì)）

5、需求調(diào)查時(shí)，用戶所說的需求未必是真實(shí)、準(zhǔn)確的需求，因此需求分析需要依賴用戶，但是不能過分迷信用戶。（對(duì)，需求描述是困難的）

6、觀察用戶如何工作也是一種需求調(diào)查行為。（對(duì)）

軟件需求分析階段的任務(wù)：需求獲取，需求分析，需求定義，需求驗(yàn)證。完整性，正確性，合理性，可行性，充分性。

結(jié)構(gòu)化分析方法：是一種建模技術(shù)。核心是數(shù)據(jù)字典。

功能模型用數(shù)據(jù)流圖（DFD)來描述使用實(shí)體—關(guān)系圖（ER圖）建立數(shù)據(jù)模型。使用狀態(tài)轉(zhuǎn)換圖（簡稱狀態(tài)圖）建立系統(tǒng)行為模型。數(shù)據(jù)字典。加工規(guī)格說明。需求建模的依據(jù)是需求描述

數(shù)據(jù)建模，ER圖，需要認(rèn)真看。

第四章結(jié)構(gòu)化設(shè)計(jì)方法

結(jié)構(gòu)化設(shè)計(jì)方法是在模塊化，自頂向下逐步細(xì)化及結(jié)構(gòu)化程序設(shè)計(jì)技術(shù)基礎(chǔ)上發(fā)展起來的，結(jié)構(gòu)化設(shè)計(jì)方法可分為兩類：一類是根據(jù)系統(tǒng)的數(shù)據(jù)流進(jìn)行設(shè)計(jì)，稱為面向數(shù)據(jù)流的設(shè)計(jì)，或稱過程驅(qū)動(dòng)設(shè)計(jì)，另一類是根據(jù)系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)進(jìn)行設(shè)計(jì)，稱為面向數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)，或稱數(shù)據(jù)驅(qū)動(dòng)的設(shè)計(jì)。

軟件的體系結(jié)構(gòu)設(shè)計(jì)，模塊化設(shè)計(jì)都是分而治之策略的具體表現(xiàn)。模塊化是將整體軟件劃分為獨(dú)立命名且可獨(dú)立訪問的模塊，不同的模塊通常具有不用的功能或指責(zé)，每個(gè)模塊可獨(dú)立開發(fā)，測(cè)試，最后組裝成完整的軟件。模塊是構(gòu)成軟件的基本構(gòu)件。模塊并不是越小越好，當(dāng)模塊數(shù)目增加時(shí)，每個(gè)模塊的規(guī)模將減小，開發(fā)單個(gè)模塊的成本確實(shí)減少了，但是隨著模塊數(shù)目增加，模塊之間關(guān)系的復(fù)雜程度也會(huì)增加，設(shè)計(jì)模塊間接口所需要的工作量也將增加。

模塊的獨(dú)立性是指軟件系統(tǒng)中每個(gè)模塊只涉及軟件要求的具體的子功能，而與軟件系統(tǒng)中其他模塊的接口是簡單的，若一個(gè)模塊只具有單一的功能且與其他模塊沒有太多的聯(lián)系，那么稱此模塊有獨(dú)立性。

自頂向下，逐步細(xì)化：抽象是指忽視一個(gè)主題中與當(dāng)前目標(biāo)無關(guān)的方面，以便更充分地注意與當(dāng)前目標(biāo)有關(guān)的方面，當(dāng)我們進(jìn)行軟件設(shè)計(jì)時(shí)，設(shè)計(jì)開始時(shí)應(yīng)盡量提高軟件的抽象層次，按抽象級(jí)別從高到低進(jìn)行軟件設(shè)計(jì)，將軟件的體系結(jié)構(gòu)按自頂向下方式，對(duì)各個(gè)層次的過程細(xì)節(jié)和數(shù)據(jù)細(xì)節(jié)逐層細(xì)化，直到用程序設(shè)計(jì)語言的語句能夠?qū)崿F(xiàn)為止，從而最后確定整個(gè)系統(tǒng)的體系結(jié)構(gòu)，這就是自頂向下逐步細(xì)化過程。

復(fù)用是指同一事物不做修改或稍加修改就可以多次重復(fù)使用，將服用的思想用于軟件開發(fā)，稱為軟件復(fù)用。1是盡量使用已有的構(gòu)件。2是如果確實(shí)需要?jiǎng)?chuàng)建新的構(gòu)件，則在設(shè)計(jì)時(shí)應(yīng)該考慮將來的可重復(fù)使用性。軟件設(shè)計(jì)的階段與任務(wù)：從工程管理的角度，可以將軟件設(shè)計(jì)分為概要設(shè)計(jì)階段和詳細(xì)設(shè)計(jì)階段。從技術(shù)的角度，傳統(tǒng)的結(jié)構(gòu)化方法將軟件設(shè)計(jì)劃分為體系結(jié)構(gòu)設(shè)計(jì)、數(shù)據(jù)設(shè)計(jì)、接口設(shè)計(jì)和過程設(shè)計(jì)4部分；概要設(shè)計(jì)包括體系結(jié)構(gòu)設(shè)計(jì)、數(shù)據(jù)設(shè)計(jì)、接口設(shè)計(jì)。詳細(xì)設(shè)計(jì)即過程設(shè)計(jì)，對(duì)結(jié)構(gòu)表示進(jìn)行細(xì)化，得到軟件詳細(xì)的數(shù)據(jù)結(jié)構(gòu)和算法。

軟件設(shè)計(jì)各項(xiàng)設(shè)計(jì)工作的依據(jù)：體系結(jié)構(gòu)設(shè)計(jì)，定義軟件模塊及其之間的關(guān)系，依賴于數(shù)據(jù)流圖。數(shù)據(jù)設(shè)計(jì)，依賴于ER圖。接口設(shè)計(jì)，依賴于頂層數(shù)據(jù)流圖。過程設(shè)計(jì)：依賴于加工規(guī)格說明、狀態(tài)圖

基于數(shù)據(jù)流方法的設(shè)計(jì)過程：1.復(fù)查并精化數(shù)據(jù)流圖。2.確定數(shù)據(jù)流圖中數(shù)據(jù)流的類型，典型的數(shù)據(jù)流類型有變換型數(shù)據(jù)流和事務(wù)型數(shù)據(jù)流。3.導(dǎo)出初始的軟件結(jié)構(gòu)圖。4.逐級(jí)分解。5.精化軟件結(jié)構(gòu)。6.導(dǎo)出接口描述和全局?jǐn)?shù)據(jù)結(jié)構(gòu)。

軟件模塊結(jié)構(gòu)的改進(jìn)方法：1，模塊功能的完善化。2，消除重復(fù)功能，改善軟件結(jié)構(gòu)。3，模塊的作用范圍應(yīng)在控制范圍之內(nèi)。4，盡可能減少高扇出結(jié)構(gòu)，隨著深度增大扇入。5，避免或減少使用病態(tài)連接。6，模塊的大小要適中。接口設(shè)計(jì)的依據(jù)是數(shù)據(jù)流圖中的自動(dòng)化系統(tǒng)邊界。

自頂向下，逐步細(xì)化的設(shè)計(jì)過程主要包括兩個(gè)方面：一是將復(fù)雜問題的解法分析和細(xì)化成由若干個(gè)模塊組成的層次結(jié)構(gòu)，二是將每個(gè)模塊的功能逐步分解細(xì)化為一系列的處理。第五章編碼

編碼容易出現(xiàn)的風(fēng)格不足

1、變量或函數(shù)名字缺乏具體含義

2、變量或函數(shù)名字與其用途不符

3、變量或函數(shù)未加上必要的注釋

4、函數(shù)未說明其功能、參數(shù)的意義

5、引用的符號(hào)未加以解釋和說明

6、對(duì)循環(huán)等重要的程序語句未注釋

7、對(duì)用到的重要庫函數(shù)沒有解釋說明

8、對(duì)結(jié)構(gòu)體等復(fù)雜數(shù)據(jù)結(jié)構(gòu)的組成成分沒有解釋說明

9、缺乏必要的提示語句 第六章軟件測(cè)試方法

軟件測(cè)試是在軟件投入生產(chǎn)性運(yùn)行之前，對(duì)軟件需求分析，設(shè)計(jì)規(guī)格說明和編碼的最終復(fù)審，是軟件質(zhì)量控制的關(guān)鍵步驟。軟件測(cè)試是為了發(fā)現(xiàn)錯(cuò)誤而執(zhí)行程序的過程。