整套電子課件：軟件工程原理與應(yīng)用

第1章緒論1.1軟件發(fā)展簡史1.2軟件危機(jī)1.3軟件工程1.4關(guān)于本書1.1軟件發(fā)展簡史1.1.1什么是軟件什么是軟件？有人說軟件就是計算機(jī)程序，開發(fā)軟件就是編寫程序。還有人會說軟件就是計算機(jī)程序和說明書。這種看法對不對呢？計算機(jī)系統(tǒng)是通過運(yùn)行程序來實(shí)現(xiàn)各種不同應(yīng)用功能的。各種不同功能的程序，包括用于特定目的的程序、支持這些程序運(yùn)行的系統(tǒng)程序（如操作系統(tǒng)）、管理和控制計算機(jī)系統(tǒng)的資源的程序、檢查和診斷計算機(jī)系統(tǒng)的程序等，統(tǒng)稱為軟件。軟件是計算機(jī)系統(tǒng)中與硬件相對應(yīng)、又相互依存的另一部分，與硬件合二為一共同完成系統(tǒng)的功能。軟件是一種產(chǎn)品，作為一種產(chǎn)品，它表達(dá)了由計算機(jī)硬件體現(xiàn)的計算潛能。不管是駐留在設(shè)備中，還是在主機(jī)中，軟件是一個信息轉(zhuǎn)換器，能產(chǎn)生、管理、獲取、修改、顯示和轉(zhuǎn)換信息。軟件可以有如下定義：計算機(jī)程序及其說明程序的各種文檔的集合。1.1軟件發(fā)展簡史1.1.2軟件的分類根據(jù)軟件的功能可以將軟件劃分為：系統(tǒng)軟件、支撐軟件、應(yīng)用軟件。根據(jù)軟件的工作方式可以將軟件劃分為：實(shí)時軟件、分時軟件、交互式軟件、批處理軟件。根據(jù)軟件的規(guī)模可以將軟件劃分為：微型軟件、小型軟件、中型軟件、大型軟件、超大型軟件、極大型軟件。1.1軟件發(fā)展簡史根據(jù)軟件服務(wù)對象的范圍可以將軟件劃分為：定制軟件、產(chǎn)品軟件。根據(jù)應(yīng)用領(lǐng)域可以將軟件劃分為：操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)、軟件開發(fā)系統(tǒng)、辦公軟件（包括字處理軟件、電子表格軟件等）、財務(wù)軟件、網(wǎng)絡(luò)工具軟件、圖形圖像處理軟件、多媒體軟件、游戲軟件、家庭教育軟件等。根據(jù)軟件的規(guī)?？梢詫④浖澐譃椋何⑿蛙浖?、小型軟件、中型軟件、大型軟件、超大型軟件、極大型軟件。1.1軟件發(fā)展簡史1.1.3軟件技術(shù)的發(fā)展從第一臺計算機(jī)問世以來，為滿足日益增長的需求，每次硬件技術(shù)的突破都為軟件技術(shù)新發(fā)展提供了更為廣闊的空間，開拓了廣闊的應(yīng)用領(lǐng)域。計算機(jī)的應(yīng)用領(lǐng)域從單純的科學(xué)計算發(fā)展到軍事、經(jīng)濟(jì)、科學(xué)、文化以及社會生活的各個方面，進(jìn)而要求計算機(jī)的運(yùn)算速度不斷提高，存儲容量不斷擴(kuò)大、體積不斷縮小。而計算機(jī)數(shù)量的聚增使得軟件系統(tǒng)從簡單到復(fù)雜，從小型到大型，從封閉式自動化孤島到網(wǎng)絡(luò)化的開放式系統(tǒng)。1.1軟件發(fā)展簡史1.1.4軟件開發(fā)技術(shù)的發(fā)展計算機(jī)誕生以來，軟件開發(fā)技術(shù)在觀念、目標(biāo)等方面發(fā)生了很大的變化?？傮w上看大致經(jīng)歷了如下三個階段。個體手工勞動階段（20世紀(jì)50年代初期~60年代中期）。計算機(jī)發(fā)展早期，軟件的生產(chǎn)方式主要是個體手工勞動的方式，這一階段稱作程序設(shè)計階段。這一時期硬件系統(tǒng)價格昂貴、運(yùn)行速度慢、存儲容量小、可靠性差。程序員使用機(jī)器語言或匯編語言，懷著極大的熱情，將編寫程序視作藝術(shù)創(chuàng)作，將開發(fā)出來的軟件視為藝術(shù)品。開發(fā)程序的目標(biāo)之一是追求編程技巧和程序的運(yùn)行效率；同時由于缺少文檔，往往導(dǎo)致所開發(fā)出來的程序難讀、難懂、難修改。當(dāng)然，由于此時程序規(guī)模很小，程序開發(fā)似乎還不需要采用系統(tǒng)化的方法進(jìn)行管理。一旦出了問題，諸如計劃推遲、超過成本預(yù)算，或軟件出現(xiàn)錯誤，程序員才開始彌補(bǔ)。1.1軟件發(fā)展簡史

“軟件作坊”階段（20世紀(jì)60年代中期~70年代末期）。由于計算機(jī)應(yīng)用領(lǐng)域的不斷擴(kuò)大，軟件需求不斷增長，軟件變得越來越復(fù)雜，設(shè)計者不得不組織為合作組織采用分工合作的方式開發(fā)程序，即作坊式的軟件開發(fā)模式，這一階段稱為程序系統(tǒng)階段。這一時期硬件速度、存儲容量以及可靠性有了明顯提高，價格明顯降低，計算機(jī)應(yīng)用迅速普及，軟件需求迅猛增加。程序員采用高級程序設(shè)計語言編寫程序，雖然有所分工，但仍然依靠個人技巧，開發(fā)人員無規(guī)范約束，又缺乏軟件理論方法，開發(fā)技術(shù)也沒有新的突破。開發(fā)人員的素質(zhì)和落后的開發(fā)技術(shù)不適應(yīng)規(guī)模日益增長的、越來越復(fù)雜的軟件系統(tǒng)的開發(fā)。軟件錯誤嚴(yán)重，維護(hù)費(fèi)用巨大，更為嚴(yán)重的是，如此開發(fā)出來的軟件根本就不能維護(hù)。最終，“軟件危機(jī)”出現(xiàn)了。

1.1軟件發(fā)展簡史軟件工程階段（20世紀(jì)70年中期~現(xiàn)在）。面對軟件開發(fā)所遇到的嚴(yán)重問題，1968年由北大西洋公約組織（NATO）在前聯(lián)邦德國格密斯（Garmish）舉行的國際學(xué)術(shù)會議上正式提出并使用了“軟件工程”的概念，軟件工程階段開始了。這一時期硬件向超高速、大容量、微型化、網(wǎng)絡(luò)化、智能化方向發(fā)展。軟件應(yīng)用滲透到人類生活的每個角落，軟件的種類空前繁榮，軟件的結(jié)構(gòu)空前復(fù)雜、規(guī)?？涨褒嫶?，軟件以產(chǎn)品化、系列化、工程化、標(biāo)準(zhǔn)化和產(chǎn)業(yè)化向前發(fā)展。軟件開發(fā)必須打破個體化特征，采用工程化的原理和方法，綜合運(yùn)用數(shù)據(jù)庫技術(shù)、網(wǎng)絡(luò)技術(shù)、分布式、面向?qū)ο蠹夹g(shù)及相應(yīng)的開發(fā)工具和開發(fā)環(huán)境來開發(fā)軟件。但是，軟件工程至今并未取得突破性進(jìn)展，軟件價格仍然高居不下，軟件產(chǎn)業(yè)仍然是勞動密集型產(chǎn)業(yè)，軟件生產(chǎn)的自動化水平仍然很低，這與人類已經(jīng)進(jìn)入的信息社會應(yīng)有的生產(chǎn)方式顯得格格不入.1.1軟件發(fā)展簡史1.1.5面向?qū)ο筌浖_發(fā)技術(shù)不同的計算機(jī)語言適合不同的需求，低級語言往往能夠帶來更高的運(yùn)行效率并且占用更少的計算機(jī)資源。但是，在客觀條件許可的情況下，我們應(yīng)該盡量使用高級語言，以便于軟件工程管理。計算機(jī)語言是一種對計算機(jī)本身的抽象，計算機(jī)以機(jī)器碼運(yùn)行程序。因?yàn)槿祟愲y以理解掌握這種機(jī)器碼，所以出現(xiàn)了方便人類使用的編程語言。所有的編程語言都是對機(jī)器碼的一種抽象，匯編語言幾乎就是機(jī)器碼本身。隨后的C是對匯編語言作了抽象，它較匯編語言有了很大的進(jìn)步，但是依然是一種初級的抽象。Java等面向?qū)ο蟮恼Z言是一種更高程度的抽象。1.1軟件發(fā)展簡史面向?qū)ο缶幊陶Z言減少了這兩個模型之間的鴻溝。Booch給對象作了個簡單的定義：對象有狀態(tài)、行為和標(biāo)識。這里說的標(biāo)識，是指每個對象的名字，這使得它能同其它對象區(qū)分開來。狀態(tài)是指對象的具體特征，行為是指它能夠做的事情。比如說，現(xiàn)實(shí)世界中的出納員，映射到面向?qū)ο竽Ｐ椭?，可以是這樣的：類：出納員{狀態(tài)：姓名行為：收錢（）；發(fā)錢（）；}1.1軟件發(fā)展簡史

面向?qū)ο缶幊陶Z言提供了一些特性，善于利用這些特性，可以使得我們的軟件在邏輯上更簡單、優(yōu)雅、方便以后的升級和修改。簡單地說，面向?qū)ο笳Z言提供了以下幾個特性：封裝、繼承、多態(tài)性。封裝簡單地說，封裝是指隱藏具體的代碼。一個程序員寫好了一段代碼，另外一個程序員打算使用它。對于那個使用者來說，這段代碼只是提供了一種服務(wù)，比如說驅(qū)動打印機(jī)，或者說把報表存入數(shù)據(jù)庫。至于打印機(jī)具體是怎么被驅(qū)動的，使用者并不想知道。封裝的第一個好處就是合作開發(fā)軟件更方便。一個程序員寫了一個對象，他把無關(guān)的代碼封裝起來，只開放幾個接口。使用這個對象的程序員只要知道怎么使用這個接口，就可以在自己的代碼中使用這個對象，享受到這個對象的服務(wù)

1.1軟件發(fā)展簡史

繼承封裝很容易理解和使用。繼承容易理解卻不容易使用。所謂繼承，就是一個類是別的類的子類。他繼承了父類的特性，他還可以有自己的特性。在我們寫程序的時候，經(jīng)常會發(fā)現(xiàn)，我們正打算寫的一段代碼跟程序中已經(jīng)存在的某段代碼功能非常類似，但是卻不完全一樣。如果那段代碼是一個對象的話，我們就可以繼承那個對象。當(dāng)然我們也可以創(chuàng)建一個新對象，然后把那個舊對象中的代碼都貼過來，修改一下。但是這在軟件工程上是一種錯誤的做法，它違背了軟件工程中的OAOO原則（Onceandonlyonce，一段實(shí)現(xiàn)特定功能的代碼只出現(xiàn)一次，決不粘貼拷貝到其它地方）。繼承的另外一個優(yōu)點(diǎn)就是，它支持漸進(jìn)式的開發(fā)。1.1軟件發(fā)展簡史

多態(tài)性

最常見的多態(tài)性，就是java或者C++語言中的“+”號，它是一個操作符，整型數(shù)可以用，浮點(diǎn)型也可以用，字符串也可以用。這個擁有多態(tài)性的加號可以自動識別類型。在這個用法中，它的好處就是方便，增加了代碼的可讀性。

其實(shí)多態(tài)性還有其它的軟件工程方面的好處。在多人合作開發(fā)一個軟件的時候，一個人的代碼會被另外一個人使用。雖然一個類被正式完成之后，其它人可以方便地使用。但是在沒有寫完之前，同事也可能需要使用它。1.2軟件危機(jī)

1.2.1什么是軟件危機(jī)軟件危機(jī)是指在計算機(jī)軟件開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題。其具體表現(xiàn)如下:

軟件不符合用戶的實(shí)際需要。一般情況下，由于開發(fā)人員在軟件開發(fā)初期對用戶的要求上不夠明確，就閉門造車，急于開始編程。開發(fā)工作開始后，軟件開發(fā)人員又未能與用戶及時與用戶交換意見，使得一些問題不能得到及時解決，導(dǎo)致所開發(fā)出來的軟件不能完全滿足用戶的要求，用戶對已完成的軟件不滿意的現(xiàn)象常常發(fā)生。有的軟件甚至因?yàn)楹献髋c技術(shù)問題出現(xiàn)開發(fā)失敗的情況。1.2軟件危機(jī)軟件價格昂貴。20世紀(jì)50年代，軟件成本在整個計算機(jī)系統(tǒng)中所占的比例并不大，約為10%～20%。但隨著軟件產(chǎn)業(yè)的發(fā)展，軟件成本隨著人力成本日益提高。與此相反，計算機(jī)硬件成本隨著技術(shù)的進(jìn)步和生產(chǎn)規(guī)模的擴(kuò)大卻不斷下降，軟件代價在計算機(jī)系統(tǒng)中所占的比例越來越大。到60年代中期，軟件成本占整個計算機(jī)系統(tǒng)的比例增長為50%左右，1985年就已增長到大約90%。軟件開發(fā)項(xiàng)目超支和延期。難以按進(jìn)度完成軟件開發(fā)，難以估計軟件開發(fā)的工作量。實(shí)際成本比估計成本有可能高出一個數(shù)量級，實(shí)際進(jìn)度比預(yù)期進(jìn)度又可能拖延幾個月甚至幾年。這種現(xiàn)象降低了軟件開發(fā)者的信譽(yù)。而為了趕進(jìn)度和節(jié)約成本所采取的一些權(quán)宜之策又往往降低了軟件產(chǎn)品的質(zhì)量，從而不可避免地會引起用戶不滿。經(jīng)驗(yàn)表明，當(dāng)軟件項(xiàng)目組織者發(fā)現(xiàn)無法按進(jìn)度完成項(xiàng)目開發(fā)時，往往采取增加開發(fā)人員的措施，而這不僅不會解決問題，反而造成進(jìn)一步的延期，原因是新增人員一般并不熟悉正在開發(fā)的項(xiàng)目，老的開發(fā)人員花在培訓(xùn)新來人員上的時間往往會更多。1.2軟件危機(jī)軟件質(zhì)量低，可靠性差。由于在開發(fā)過程中，沒有確保軟件質(zhì)量的體系和措施，在軟件測試時，又沒有嚴(yán)格的、充分的、完全的測試，提交給用戶的軟件質(zhì)量差，在運(yùn)行中暴露出大量問題。這種不可靠的軟件輕者會影響系統(tǒng)正常工作，重者會發(fā)生事故，造成生命財產(chǎn)的重大損失。例如，1965~1970年間，美國范登堡基地發(fā)射火箭多次失敗，絕大部分出于控制系統(tǒng)故障，故障主要是由于程序錯誤所造成。軟件缺少適當(dāng)?shù)奈臋n資料。開發(fā)過程無完整、規(guī)范的文檔，發(fā)現(xiàn)問題后進(jìn)行雜亂無章的修改，結(jié)果越改越是錯誤百出。從軟件的使用角度，由于缺少完備的、詳細(xì)的、明確的說明書，用戶往往不能正確使用系統(tǒng)，不僅增加了不必要的誤操作，也大大增加了軟件的售后服務(wù)成本。難于修改和維護(hù)軟件。由于軟件開發(fā)過程沒有統(tǒng)一的、公認(rèn)的規(guī)范，軟件開發(fā)人員按各自的風(fēng)格工作，各行其是，很多程序中的錯誤非常難以修改，并且難以使這些程序適應(yīng)新的軟硬件環(huán)境，難以根據(jù)用戶的要求在程序中增加新的功能。1.2軟件危機(jī)

1.2.2軟件危機(jī)的形成原因

軟件危機(jī)的出現(xiàn)一方面固然與軟件本身的特點(diǎn)有關(guān)，另一方面也與軟件的開發(fā)和維護(hù)方法有關(guān)，具體原因如下:軟件本身是邏輯部件，是無形的產(chǎn)品，看不見摸不著，質(zhì)量往往難以評價，潛在的錯誤在所難免，并且質(zhì)量檢測非常復(fù)雜，往往不能在交付使用之前檢查出所有錯誤。軟件在運(yùn)行中不會因?yàn)槭褂脮r間長而損壞，如果運(yùn)行中出現(xiàn)問題，一般是由于在開發(fā)階段引入而在測試階段沒有發(fā)現(xiàn)的問題。因此，軟件的修改和維護(hù)實(shí)際是對原有設(shè)計的修改和改進(jìn)。1.2軟件危機(jī)

軟件規(guī)模越來越大，軟件結(jié)構(gòu)越來越復(fù)雜。1968年美國航空公司訂票軟件系統(tǒng)規(guī)模達(dá)到30萬條指令；IBM360操作系統(tǒng)的16版達(dá)到100萬條指令；1973年美國阿波羅項(xiàng)目達(dá)到1000萬條指令。這些龐大的軟件功能非常復(fù)雜，其調(diào)用關(guān)系、接口信息、數(shù)據(jù)結(jié)構(gòu)都十分復(fù)雜，其復(fù)雜程度遠(yuǎn)遠(yuǎn)超過了人所能接受的程度。

忽視需求分析的重要性，急于開始編程，往往造成開發(fā)出來的軟件不能滿足用戶的要求而導(dǎo)致返工甚至作廢。這是由于早期軟件開發(fā)的個體化特征造成的，主要表現(xiàn)為對軟件需求分析重視不夠，錯誤地認(rèn)為軟件開發(fā)就是編寫程序并使之運(yùn)行，不重視軟件需求和軟件維護(hù)。許多程序員不愿意編寫文檔，而熱衷于編寫程序。往往直到軟件開發(fā)臨近結(jié)束時，才為了應(yīng)付任務(wù)，而匆匆編寫文檔，草草了事，責(zé)任心不強(qiáng)，可以想象其文檔的質(zhì)量。

輕視軟件測試和軟件維護(hù)。如前所述，許多人認(rèn)為軟件開發(fā)就是寫程序，殊不知軟件開發(fā)過程中絕大部分工作是花在需求分析、測試和維護(hù)階段。B.Boehm認(rèn)為軟件是程序以及開發(fā)、使用和維護(hù)程序所需要的所有文檔的集合，即軟件=程序+文檔。

軟件開發(fā)技術(shù)落后，生產(chǎn)方式落后，開發(fā)工具落后。20世紀(jì)60年代人們注重于一些計算機(jī)理論問題的研究，如編譯原理、操作系統(tǒng)原理、數(shù)據(jù)庫原理、人工智能原理、形式語言理論等，不注重軟件開發(fā)技術(shù)的研究，用戶要求的軟件復(fù)雜性與軟件技術(shù)解決復(fù)雜性的能力不相適應(yīng)。同時，與計算機(jī)硬件生產(chǎn)形成鮮明反差的是，軟件開發(fā)仍然采用個體手工方式，根據(jù)個人愛好工作，無章可循，無規(guī)范可依，靠言傳身教、師傅帶徒弟的方式進(jìn)行。1.2軟件危機(jī)

1.2.3軟件危機(jī)的解決方法20世紀(jì)60年代后期人們驚呼發(fā)生了軟件危機(jī)，于是人們坐到一起開始討論解決軟件危機(jī)的方法.1968年由北大西洋公約組織在前聯(lián)邦德國格密斯舉行的國際學(xué)術(shù)會議上正式提出并使用了“軟件工程”的概念，運(yùn)用工程學(xué)的基本原理和方法來組織和管理軟件生產(chǎn).后來還發(fā)展了相關(guān)的心理學(xué)、生理學(xué)和經(jīng)濟(jì)學(xué)等方面的學(xué)科。軟件工程誕生了,它是解決軟件危機(jī)惟一有效的方法。首先，必須消除存在的錯誤認(rèn)識，借鑒人類長期以來的工程原理、概念、技術(shù)、方法，用工程化方法和途徑來開發(fā)和維護(hù)軟件。

1.2軟件危機(jī)

其次，應(yīng)該開發(fā)和使用更好的軟件工具。在軟件開發(fā)的每個階段都由許多繁瑣重復(fù)的工作要做，在適當(dāng)?shù)能浖ぞ叩妮o助下，開發(fā)人員可以做得又快又好。把各個階段使用的軟件工具有機(jī)地集合起來構(gòu)成一個整體，支持軟件開發(fā)的全過程，這稱為軟件工程支撐環(huán)境。

最后，應(yīng)該采取必要的管理措施。軟件產(chǎn)品是一種無形的產(chǎn)品，它不同于一般工程項(xiàng)目的管理。必須采取適合軟件產(chǎn)品特點(diǎn)的管理措施，通過人員組織管理、項(xiàng)目計劃管理、配置管理等環(huán)節(jié)來保證軟件開發(fā)按時按質(zhì)量完成。1.2軟件危機(jī)1.3軟件工程1.3.1什么是軟件工程

本書采用如下定義：軟件工程是指導(dǎo)計算機(jī)軟件開發(fā)和維護(hù)的一門學(xué)科，它采用工程的概念、原理、技術(shù)和方法，把經(jīng)過時間考驗(yàn)而證明是正確的管理技術(shù)與技術(shù)方法結(jié)合起來用于開發(fā)軟件。軟件工程是一門指導(dǎo)性的學(xué)科，它在宏觀上或總體上指導(dǎo)人們?nèi)绾伍_發(fā)軟件系統(tǒng)?？梢哉f，軟件工程就是“軟件的哲學(xué)”。軟件工程的目標(biāo)是指導(dǎo)成功地開發(fā)大型軟件系統(tǒng)，達(dá)到降低開發(fā)成本、實(shí)現(xiàn)要求的功能、取得較好的性能和可靠性、軟件系統(tǒng)易于移植、降低維護(hù)費(fèi)用、按時完成開發(fā)任務(wù)、及時交付使用等具體的目標(biāo)。

圖1.1軟件工程目標(biāo)之間的關(guān)系1.3軟件工程1.3.2軟件工程的基本原理

自從軟件工程的概念提出以來，專家學(xué)者們陸續(xù)提出了100多條關(guān)于軟件工程的準(zhǔn)則。1983年B.Woehm提出了軟件工程的七條基本原理。

用分階段的生命周期計劃嚴(yán)格管理。這條原則是吸取前人的經(jīng)驗(yàn)教訓(xùn)而得到的。統(tǒng)計表明，失敗的項(xiàng)目有50%以上是由于計劃不周而造成的。在軟件開發(fā)和維護(hù)的漫長生命周期中，需要完成許多性質(zhì)各異的工作。我們應(yīng)該把整個軟件生命周期劃分為若干階段，為每個階段制定不同的任務(wù)，并制定出切實(shí)可行的計劃，然后嚴(yán)格按照計劃對軟件的開發(fā)和維護(hù)進(jìn)行管理。這些計劃包括：項(xiàng)目總體計劃、里程碑計劃、項(xiàng)目控制計劃、產(chǎn)品控制計劃、驗(yàn)證計劃、運(yùn)行維護(hù)計劃。不同層次的管理人員都必須嚴(yán)格按照計劃各盡其職，絕不能受客戶或上級人員的影響而擅自背離預(yù)定的計劃。

1.3軟件工程1.3軟件工程

堅(jiān)持進(jìn)行階段評審。統(tǒng)計結(jié)果顯示，大約63%的軟件錯誤是在編碼之前造成的，錯誤發(fā)現(xiàn)得越晚，改正錯誤花費(fèi)的代價就越高，相差達(dá)到2~3個數(shù)量級。因此，軟件的質(zhì)量保證工作不能等到編碼結(jié)束后再進(jìn)行，應(yīng)當(dāng)堅(jiān)持嚴(yán)格的階段評審，以便及早發(fā)現(xiàn)錯誤。

實(shí)行嚴(yán)格的產(chǎn)品控制。在軟件的開發(fā)過程中不能隨意改變需求，否則將會付出較高的代價。軟件開發(fā)過程中最糟糕的是莫過于改動需求，而實(shí)踐告訴我們，改動需求往往是不可避免的。作為軟件開發(fā)人員，我們往往不能禁止用戶提出修改需求的要求，而只能依靠科學(xué)的產(chǎn)品控制技術(shù)來適應(yīng)用戶的這種要求。也就是要采用變動控制（又叫基準(zhǔn)配置管理）。當(dāng)需求變動時，使其他各個階段的文檔和代碼隨之相應(yīng)變動，以保證軟件的一致性。1.3軟件工程

采用現(xiàn)代程序設(shè)計技術(shù)。從提出軟件工程的概念開始，人們的主要精力都用于研究各種新的程序設(shè)計技術(shù)，20世紀(jì)60年代的結(jié)構(gòu)化程序設(shè)計技術(shù)隨后發(fā)展為結(jié)構(gòu)化分析技術(shù)和結(jié)構(gòu)化設(shè)計技術(shù)，已成為被大多數(shù)人認(rèn)可的先進(jìn)技術(shù)，后來又出現(xiàn)了面向?qū)ο蠹夹g(shù)。計算機(jī)程序設(shè)計語言也從一代、二代、三代發(fā)展到第四代語言。人們已經(jīng)充分認(rèn)識到，采用先進(jìn)的技術(shù)可以極大地提高軟件開發(fā)效率，降低軟件維護(hù)成本。

工作成果應(yīng)當(dāng)能夠清楚地審查。軟件產(chǎn)品不同于一般的物理產(chǎn)品，軟件是邏輯產(chǎn)品，看不見、摸不著。軟件開發(fā)小組的工作進(jìn)展情況可見性差，難于評價和管理。為了更好地管理，應(yīng)根據(jù)軟件開發(fā)的總目標(biāo)及完成期限，盡量明確地規(guī)定開發(fā)小組的責(zé)任和產(chǎn)品標(biāo)準(zhǔn)，從而使所得到工作成果能按標(biāo)準(zhǔn)清楚地審查。1.3軟件工程

開發(fā)小組的成員應(yīng)少而精。開發(fā)人員的素質(zhì)和數(shù)量是影響軟件開發(fā)效率的重要因素，開發(fā)小組的人員應(yīng)少而精。高素質(zhì)的開發(fā)人員比低素質(zhì)開發(fā)人員的效率要高幾倍到幾十倍，開發(fā)工作中所犯的錯誤也少得多。此外，開發(fā)小組成員之間的通信代價也隨人員的增加而增加。當(dāng)開發(fā)小組為N人時，可能的通信信道為N（N－1）/2，可見隨著人數(shù)增加，通信開銷急劇增加。

承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性。在軟件工程基本原理中，一般認(rèn)為只要遵循上述六條原理，就能較好地進(jìn)行軟件的工程化開發(fā)。但是，Beohm還提出了第七條原理，要求承認(rèn)不斷總結(jié)經(jīng)驗(yàn)、改進(jìn)軟件工程過程的必要性。根據(jù)這條原理，不僅要吸納新的軟件開發(fā)技術(shù)，還要注意不斷總結(jié)經(jīng)驗(yàn)，收集數(shù)據(jù)，進(jìn)行出錯類型和問題的報告統(tǒng)計。用這些數(shù)據(jù)評估新的軟件技術(shù)的效果，指明必須要著重注意的問題和應(yīng)該優(yōu)先進(jìn)行研究的工具和技術(shù)。1.3軟件工程1.3.3軟件工程的基本內(nèi)容

軟件工程研究的主要內(nèi)容是軟件開發(fā)技術(shù)和軟件開發(fā)管理兩個方面。軟件開發(fā)技術(shù)主要包括軟件開發(fā)方法、軟件開發(fā)過程、軟件開發(fā)工具和環(huán)境。軟件開發(fā)管理主要包括軟件管理學(xué)、軟件經(jīng)濟(jì)學(xué)和軟件心理學(xué)等，包括人員分配、制定計劃、確定標(biāo)準(zhǔn)與配置、成本估算、質(zhì)量評價等。傳統(tǒng)的軟件工程學(xué)的基本內(nèi)容如下:

軟件生存周期模型。描述軟件開發(fā)總過程的理論模型，指導(dǎo)整個軟件開發(fā)過程。

軟件分析。確定待開發(fā)軟件的總體要求和使用范圍以及與之相關(guān)的硬件和支撐軟件的要求，包括系統(tǒng)分析、可行性分析、軟件開發(fā)計劃、需求分析，主要介紹結(jié)構(gòu)化分析方法。1.3軟件工程

軟件設(shè)計。包括總體設(shè)計和詳細(xì)設(shè)計兩個階段，產(chǎn)生軟件的總體結(jié)構(gòu)、軟件包含的所有功能模塊及其接口規(guī)范、全局?jǐn)?shù)據(jù)結(jié)構(gòu)和局部數(shù)據(jù)結(jié)構(gòu)以及各模塊的詳細(xì)算法，涉及軟件設(shè)計基本原理和軟件設(shè)計基本方法等問題，主要介紹結(jié)構(gòu)化設(shè)計方法。

軟件實(shí)現(xiàn)。將設(shè)計階段的數(shù)據(jù)結(jié)構(gòu)和各功能模塊采用某種程序語言“翻譯”為可執(zhí)行的程序，涉及程序設(shè)計語言的選擇、程序設(shè)計方法、程序設(shè)計風(fēng)格等問題的研究，主要介紹結(jié)構(gòu)化程序設(shè)計方法。

軟件測試。對已經(jīng)用程序語言實(shí)現(xiàn)的程序模塊進(jìn)行單元測試，和對已經(jīng)過測試的模塊進(jìn)行組裝測試，以保證最終程序能正確可靠地運(yùn)行。

軟件維護(hù)。軟件開發(fā)結(jié)束交付使用后，在整個使用期間可能需要不斷地維護(hù)，以修改新發(fā)現(xiàn)的錯誤，或是為了適應(yīng)變化了的環(huán)境，或是擴(kuò)充原有的功能。

軟件管理。包括成本估算、風(fēng)險分析、進(jìn)度安排、人員組織、軟件質(zhì)量保證等基本內(nèi)容。1.4關(guān)于本課程 本書分三大篇來介紹軟件工程的知識，包括原理篇、應(yīng)用篇和管理篇。原理篇主要介紹了軟件工程的由來及其基本概念、軟件生存周期模型、軟件分析、軟件設(shè)計、軟件實(shí)現(xiàn)、軟件測試和軟件維護(hù)等內(nèi)容。應(yīng)用篇以一個圖書館管理系統(tǒng)為案例，根據(jù)軟件工程原理，完整地描述了案例的整個實(shí)施過程。管理篇主要介紹了軟件管理方面的知識，包括項(xiàng)目管理、成本估算、質(zhì)量保證以及極限變成等內(nèi)容 建議在學(xué)習(xí)本課程的過程中，將重點(diǎn)放在對基本概念的理解以及對軟件工程基本內(nèi)容和基本過程的掌握上。而有關(guān)軟件工程研究的最新成果，其本身一直處于不斷變化的過程之中，相信讀者在今后的學(xué)習(xí)和工作中通過自己的努力可以不斷地充實(shí)自己的知識結(jié)構(gòu)和視野。第2章軟件生存周期2.1軟件工程過程2.2軟件生存周期2.3軟件生存周期瀑布模型2.4軟件生存周期原型模型2.5軟件生存周期其他模型2.1軟件工程過程2.1.1什么是軟件工程過程

軟件工程是一種層次化的技術(shù)。如圖2.1所示

圖2.1軟件工程層次

軟件過程定義了一組關(guān)鍵過程域，它們構(gòu)成軟件項(xiàng)目管理的基礎(chǔ)，并規(guī)定了技術(shù)方法的采用、工程產(chǎn)品（模型、文檔、數(shù)據(jù)、報告以及表格等）的產(chǎn)生、里程碑的建立、質(zhì)量的管理以及適當(dāng)?shù)淖兏刂啤?.1軟件工程過程軟件過程是軟件生存期中的一系列相關(guān)軟件工程活動的集合。每一個軟件過程又是由一組工作任務(wù)、項(xiàng)目里程碑、軟件工程產(chǎn)品和交付物以及質(zhì)量保證（SQA）點(diǎn)等組成。一個軟件過程可以用圖2.2的形式來表示。

圖2.2軟件過程2.1軟件工程過程2.1.2軟件過程模型軟件工程過程模型的選擇基于項(xiàng)目和應(yīng)用的特點(diǎn)、采用的方法和工具、要求的控制和需交付的產(chǎn)品.所有的軟件開發(fā)都可以看成是一個問題循環(huán)解決過程，如圖2.3所示。

其中包括四個截然不同的階段：狀態(tài)捕獲、問題定義、技術(shù)開發(fā)和方案綜合。狀態(tài)捕獲表示了事物的當(dāng)前狀態(tài)；問題定義標(biāo)識了需要解決的特定問題；技術(shù)開發(fā)利用某些技術(shù)來解決問題；方案綜合導(dǎo)出最終的結(jié)果（如文檔、程序、數(shù)據(jù)、新的事務(wù)功能、新的產(chǎn)品）。2.1軟件工程過程以上的問題循環(huán)解決過程可以用于軟件工程的不同開發(fā)級別上。它可用于考慮整個應(yīng)用系統(tǒng)的宏觀級，也可用于建造程序構(gòu)件的中間級，甚至還可用于源代碼行級。因此，可以用分級幾何表示來給出過程的理想化的視圖。首先定義一個分級幾何表示的模式，然后相繼地在更小的規(guī)模上遞歸地應(yīng)用分級幾何表示：模式中嵌套模式。在圖2.4中，問題循環(huán)解決過程的每一個階段又包含一個同樣的問題循環(huán)解決過程，該循環(huán)中每一個步驟中還可以再包含另一個問題循環(huán)解決過程。這樣一直繼續(xù)下去，直到某個合理的邊界為止。對于軟件來說，就是源代碼行。

2.1軟件工程過程圖2.4問題循環(huán)解決過程中階段嵌套階段2.1軟件工程過程2.1.3過程建造技術(shù)

為了使得軟件過程模型適合于軟件項(xiàng)目組的使用，需要開發(fā)一些過程技術(shù)工具，以幫助軟件開發(fā)組織分析它們當(dāng)前的過程，組織工作任務(wù)，控制和監(jiān)控進(jìn)度，管理技術(shù)質(zhì)量。使用過程技術(shù)工具，可以建造一個自動模型，模型包含前面提到的公共過程框架、任務(wù)集合及保護(hù)傘活動。該模型一般表示成一個網(wǎng)絡(luò)，對其加以分析，就能夠確定典型的工作流程，考察可能導(dǎo)致減少開發(fā)時間、降低開發(fā)成本的可選的過程結(jié)構(gòu)。一旦創(chuàng)建了一個可接受的過程，就可以使用其他過程技術(shù)工具來分配、監(jiān)視、甚至控制在軟件過程模型中定義的所有軟件工程任務(wù)。軟件項(xiàng)目組的每一個成員都可以使用這樣的工具來開發(fā)檢查表，列出所有將要執(zhí)行的工作任務(wù)、將要產(chǎn)生的工作產(chǎn)品和將要實(shí)施的軟件質(zhì)量保證活動。2.2軟件生存周期如同任何事物一樣，軟件也有一個孕育、誕生、成長、成熟、衰亡的生存過程。軟件產(chǎn)品從形成概念開始，經(jīng)過開發(fā)、使用和維護(hù)，直到最后退役的全過程稱為軟件生存周期。根據(jù)這一思想我們可以得到軟件生存周期的三個時期：軟件定義、軟件開發(fā)、軟件使用與維護(hù),如圖2.5所示。圖2.5軟件生存周期

2.2軟件生存周期2.2.1軟件定義

軟件定義可分為軟件系統(tǒng)的可行性研究和需求分析兩個階段:軟件系統(tǒng)的可行性研究可行性研究的任務(wù)是了解用戶要求和現(xiàn)實(shí)環(huán)境，從技術(shù)、經(jīng)濟(jì)、市場等方面研究并論證開發(fā)該軟件系統(tǒng)的可行性。即這個軟件系統(tǒng)是否值得開發(fā)，是否有可行的技術(shù)去開發(fā)。系統(tǒng)分析員一般需通過以下途徑完成此階段的任務(wù):調(diào)查和了解用戶要求和現(xiàn)實(shí)環(huán)境。撰寫調(diào)查報告?？尚行哉撟C和分析（技術(shù)可行性、操作可行性和經(jīng)濟(jì)可行性）如可行，制定初步項(xiàng)目開發(fā)計劃（成本估算、人員組織、進(jìn)度安排等）。

2.2軟件生存周期需求分析這個階段的任務(wù)主要是確定待開發(fā)軟件的功能需求、性能需求和運(yùn)行環(huán)境約束、編制軟件需求規(guī)格說明、軟件系統(tǒng)的確認(rèn)測試準(zhǔn)則和用戶手冊概要。軟件的功能需求應(yīng)該指明軟件必須完成的功能。軟件的性能需求包括：軟件的安全性、可靠性、可維護(hù)性、精度、錯誤處理、適應(yīng)性及用戶培訓(xùn)等。軟件系統(tǒng)的運(yùn)行環(huán)境約束指軟件系統(tǒng)必須滿足的運(yùn)行環(huán)境方面（硬件環(huán)境、系統(tǒng)平臺）的要求。

2.2軟件生存周期軟件需求分析不僅是軟件開發(fā)依據(jù)，而且也是軟件驗(yàn)收的標(biāo)準(zhǔn)。

系統(tǒng)需求一般由用戶提出。由于用戶往往缺乏軟件開發(fā)的知識和經(jīng)驗(yàn)，系統(tǒng)分析員和軟件開發(fā)人員不得不與用戶反復(fù)討論、協(xié)商、使用戶需求逐步精確化、一致化、完全化。需求分析的一項(xiàng)重要任務(wù)是建立面向開發(fā)者的軟件需求規(guī)格說明（SoftwareRequirementsSpecification，簡稱SRS）。多數(shù)場合面向開發(fā)者的軟件需求用需求規(guī)格說明語言描述。SRS應(yīng)該指明軟件系統(tǒng)的功能需求、性能需求、接口需求、設(shè)計需求、基本結(jié)構(gòu)，以及開發(fā)標(biāo)準(zhǔn)和驗(yàn)收原則，等等。SRS是軟件開發(fā)的基礎(chǔ)，建立SRS是軟件開發(fā)成敗的關(guān)鍵。2.2軟件生存周期2.2.2軟件開發(fā)

在軟件生存周期模型中，軟件開發(fā)由概要設(shè)計、詳細(xì)設(shè)計、實(shí)現(xiàn)、集成測試和確認(rèn)測試五個階段組成。概要設(shè)計概要設(shè)計的任務(wù)是根據(jù)軟件需求規(guī)格說明（SRS）建立軟件系統(tǒng)的總體結(jié)構(gòu)和模塊間的關(guān)系，定義各功能模塊的接口，設(shè)計全局?jǐn)?shù)據(jù)庫或數(shù)據(jù)結(jié)構(gòu)，規(guī)定設(shè)計約束，制定組裝測試計劃。對于大型軟件系統(tǒng)，應(yīng)對軟件需求進(jìn)行分解，將其劃分為若干個子系統(tǒng)，對每個子系統(tǒng)定義功能模塊和各功能模塊之間的關(guān)系，并給出各子系統(tǒng)接口界面的定義；對于一般的軟件系統(tǒng)可以直接定義各功能模塊以及它們之間的關(guān)系

概要設(shè)計應(yīng)提供概要設(shè)計說明書、數(shù)據(jù)庫或數(shù)據(jù)結(jié)構(gòu)設(shè)計說明書、組裝測試計劃等文件。

2.2軟件生存周期詳細(xì)設(shè)計

詳細(xì)設(shè)計的任務(wù)是對概要設(shè)計產(chǎn)生的功能模塊逐步細(xì)化，形成若干個可編程的程序模塊，用某種過程設(shè)計語言（ProcedureDesignLanguage）設(shè)計程序模塊的內(nèi)部細(xì)節(jié)，包括算法、數(shù)據(jù)結(jié)構(gòu)和各程序模塊之間的詳細(xì)接口信息，為編寫源代碼提供必要的說明，建立“模塊開發(fā)卷宗”，擬定模塊測試方案。詳細(xì)設(shè)計需根據(jù)軟件需求規(guī)格說明（SRS）和概要設(shè)計的結(jié)果進(jìn)行，可以選用的方法和工具是比較多的，如結(jié)構(gòu)化的設(shè)計方法、面向?qū)ο蟮脑O(shè)計等方法和RationaRose、VisualModel及MicrosoftVisio等工具。軟件開發(fā)人員可以根據(jù)實(shí)際情況選用適當(dāng)?shù)姆椒ê凸ぞ摺Ｔ敿?xì)設(shè)計應(yīng)該遵循的原則是：設(shè)計應(yīng)與軟件需求保持一致，設(shè)計的軟件結(jié)構(gòu)應(yīng)支持模塊化、信息隱藏等。詳細(xì)設(shè)計應(yīng)該提供詳細(xì)設(shè)計規(guī)格說明書和單元測試計劃。

2.2軟件生存周期

實(shí)現(xiàn)實(shí)現(xiàn)的主要任務(wù)是，根據(jù)詳細(xì)設(shè)計文檔將詳細(xì)設(shè)計轉(zhuǎn)化為所要求的編程語言或數(shù)據(jù)庫語言的程序，并對這些程序進(jìn)行調(diào)試和程序單元測試，驗(yàn)證程序模塊接口與詳細(xì)設(shè)計文檔的一致性。集成測試

集成測試的任務(wù)是根據(jù)概要設(shè)計各功能模塊的說明及制定的集成測試計劃，將經(jīng)過單元測試的模塊逐步進(jìn)行集成和測試。集成測試應(yīng)對系統(tǒng)各模塊間的連接正確性進(jìn)行測試；測試軟件系統(tǒng)或子系統(tǒng)的輸入／輸出處理是否達(dá)到設(shè)計要求；測試軟件系統(tǒng)或子系統(tǒng)正確處理能力和承受錯誤的能力等。

通過集成測試的軟件應(yīng)生成滿足概要設(shè)計要求、可運(yùn)行的系統(tǒng)源程序清單和集成測試報告。2.2軟件生存周期確認(rèn)測試確認(rèn)測試的任務(wù)是根據(jù)軟件需求規(guī)格說明定義的全部功能和性能要求及軟件確認(rèn)測試計劃對軟件系統(tǒng)進(jìn)行測試，測試系統(tǒng)是否達(dá)到了系統(tǒng)需求或是否滿足用戶的需求。

確認(rèn)測試應(yīng)有客戶參加，以軟件需求規(guī)格說明書為依據(jù)，使用專用的測試工具進(jìn)行確認(rèn)測試。為驗(yàn)證軟件產(chǎn)品是否滿足軟件需求規(guī)格說明的要求，必須按照測試計劃的要求編制大量的測試用例、采用多種方法和工具、組織專門的測試隊(duì)伍并嚴(yán)格組織實(shí)施。

確認(rèn)測試階段應(yīng)向用戶提交最終的用戶手冊、操作手冊、源程序清單及其他軟件文檔。確認(rèn)測試結(jié)束時應(yīng)生成確認(rèn)測試報告、項(xiàng)目開發(fā)總結(jié)報告。2.2軟件生存周期2.2.3軟件使用、維護(hù)和退役軟件的使用

將軟件安裝在用戶確定的運(yùn)行環(huán)境中，測試通過后移交用戶使用。軟件的使用是軟件發(fā)揮社會和經(jīng)濟(jì)效益的重要階段。由于軟件是邏輯產(chǎn)品，軟件發(fā)行的份數(shù)越多，軟件的社會和經(jīng)濟(jì)效益越顯著。因此應(yīng)大力推廣軟件的使用。軟件在使用過程中客戶或維護(hù)人員必須認(rèn)真收集被發(fā)現(xiàn)的軟件錯誤，定期或階段性地撰寫“軟件問題報告”和“軟件修改報告”。軟件的維護(hù)

當(dāng)發(fā)現(xiàn)軟件產(chǎn)品中的潛伏錯誤，或用戶提出要對軟件需求進(jìn)行修改，或軟件運(yùn)行環(huán)境發(fā)生變化時，都需要對軟件進(jìn)行維護(hù)。軟件維護(hù)不僅針對程序代碼，而且還針對軟件定義、開發(fā)的各個階段生成的文檔．軟件在設(shè)計階段很難預(yù)料到這個軟件交給誰，在什么時候進(jìn)行什么樣的維護(hù)工作。2.2軟件生存周期

軟件維護(hù)的依據(jù)只能靠軟件文檔和有關(guān)的設(shè)計信息。這樣，軟件維護(hù)人員不得不花費(fèi)大量的勞動，用于軟件系統(tǒng)的再分析和對軟件信息的理解。軟件的維護(hù)直接影響軟件的應(yīng)用和軟件的生存期，而軟件的可維護(hù)性又與軟件的設(shè)計密切相關(guān)，因此軟件在開發(fā)過程中應(yīng)該重視對軟件可維護(hù)性的支持。軟件的退役軟件的退役是軟件生存周期中的最后一個階段，即終止對軟件產(chǎn)品的支持，停止使用該軟件。2.3軟件生存周期瀑布模型瀑布（waterfallmodel）模型也稱軟件生存周期模型（如圖2.6所示），由W．Royce于1970年首先提出。根據(jù)軟件生存周期各個階段的任務(wù)，瀑布模型從可行性研究（或稱系統(tǒng)分析）開始，逐步進(jìn)行階段性變換，直至通過確認(rèn)測試并得到用戶確認(rèn)的軟件產(chǎn)品為止。瀑布模型上一階段的變換結(jié)果是下一階段變換的輸入，相鄰兩個階段具有因果關(guān)系，緊密相聯(lián)。一個階段工作的失誤將蔓延到以后的各個階段。為了保障軟件開發(fā)的正確性，每一階段任務(wù)完成后，都必須對它的階段性產(chǎn)品進(jìn)行評審，確認(rèn)之后再轉(zhuǎn)入下一階段的工作。評審過程發(fā)現(xiàn)錯誤和疏漏后，應(yīng)該反饋到前面的有關(guān)階段修正錯誤、彌補(bǔ)疏漏，然后再重復(fù)前面的工作，直至某一階段通過評審后再進(jìn)入下一階段。瀑布模型在軟件工程中占有重要的地位，它提供了軟件開發(fā)的基本框架，它有利于大型軟件開發(fā)過程中人員的組織、管理，有利于軟件開發(fā)方法和工具的研究與使用，從而提高了大型軟件項(xiàng)目開發(fā)的質(zhì)量和效率。2.3軟件生存周期瀑布模型

圖2.6軟件生存周期的瀑布模型2.3軟件生存周期瀑布模型瀑布模型的主要缺點(diǎn)如下:

在軟件開發(fā)的初始階段指明軟件系統(tǒng)的全部需求是困難的，有時甚至是不現(xiàn)實(shí)的。而瀑布模型在需求分析階段要求客戶和系統(tǒng)分析員必須做到這一點(diǎn)才能開展后續(xù)階段的工作。需求確定后，用戶和軟件項(xiàng)目負(fù)責(zé)人要等相當(dāng)長的時間（經(jīng)過設(shè)計、實(shí)現(xiàn)、測試、運(yùn)行）才能得到一份軟件的最初版本。如果用戶對這個軟件提出比較大的修改意見，那么整個軟件項(xiàng)目將會蒙受巨大的人力、財力和時間方面的損失。瀑布模型的應(yīng)用有一定的局限性。2.4軟件生存周期原型模型由于在軟件開發(fā)的初始階段人們對軟件的需求認(rèn)識常常不夠清晰，因而使得所開發(fā)的軟件項(xiàng)目難于做到一次性開發(fā)成功，出現(xiàn)返工再開發(fā)在所難免，這樣會造成軟件開發(fā)進(jìn)度的延長、開發(fā)成本的上升。因此，我們可以先做試驗(yàn)開發(fā)，其目標(biāo)只是在于探索可行性，弄清軟件需求，然后在此基礎(chǔ)上獲得較為滿意的軟件產(chǎn)品。通常我們把第一次得到的試驗(yàn)性產(chǎn)品稱為“原型”。軟件開發(fā)人員根據(jù)客戶提出的軟件定義，快速地開發(fā)一個原型，它向客戶展示了待開發(fā)軟件系統(tǒng)的全部或部分功能和性能，在征求客戶對原型意見的過程中，進(jìn)一步修改、完善、確認(rèn)軟件系統(tǒng)的需求并達(dá)到一致的理解。2.4軟件生存周期原型模型快速開發(fā)原型的途徑有三種：利用個人計算機(jī)模擬軟件系統(tǒng)的人機(jī)界面和人機(jī)交互方式。開發(fā)一個工作原型，實(shí)現(xiàn)軟件系統(tǒng)的部分功能，而這部分功能是重要的，也可能是容易產(chǎn)生誤解的。找來一個或幾個正在運(yùn)行的類似軟件，利用這些軟件向客戶展示軟件需求中的部分或全部功能。為了快速開發(fā)原型，要盡量采用軟件重用技術(shù)，在算法的時／空開銷方面也可以讓步，以便爭取時間，盡快向客戶提供原型。原型應(yīng)充分展示軟件的可見部分，如數(shù)據(jù)的輸入方式、人機(jī)界面、數(shù)據(jù)的輸出格式等。由于原型是客戶和軟件開發(fā)人員共同設(shè)計和評審的，因此利用原型能統(tǒng)一客戶和軟件開發(fā)人員對軟件項(xiàng)目需求的理解，有助于需求的定義和確認(rèn)。原型開發(fā)模型如圖2.7所示。利用原型定義和確認(rèn)軟件需求之后，就可以對軟件系統(tǒng)進(jìn)行設(shè)計、編碼、測試和維護(hù)。2.4軟件生存周期原型模型

圖2.7原型模型示意圖2.5軟件生存周期其他模型2.5.1螺旋模型對于復(fù)雜的大型軟件，開發(fā)一個原型往往達(dá)不到要求。螺旋模型將瀑布模型與演化模型結(jié)合起來，并且加入兩種模型均忽略了風(fēng)險分析。螺旋模型沿著螺線旋轉(zhuǎn)，如圖2.8所示，在笛卡爾坐標(biāo)的四個象限上分別表達(dá)了四個方面的活動，即：制定計劃。確定軟件目標(biāo)，選定實(shí)施方案，弄清項(xiàng)目開發(fā)的限制條件。風(fēng)險分析。分析所選方案，考慮如何識別和消除風(fēng)險。實(shí)施工程。實(shí)施軟件開發(fā)?？蛻粼u估。評價開發(fā)工作，提出修正建議。沿螺線自內(nèi)向外每旋轉(zhuǎn)一圈便開發(fā)出更為完善的一個新的軟件版本。2.5軟件生存周期其他模型圖2.8螺旋模型2.5軟件生存周期其他模型2.5.2噴泉模型

噴泉模型對軟件復(fù)用和生存周期中多項(xiàng)開發(fā)活動的集成提供了支持，主要支持面向?qū)ο蟮拈_發(fā)方法，如圖2.9所示

圖2.9噴泉模型2.5軟件生存周期其他模型2.5.3智能模型智能模型是基于知識的軟件開發(fā)模型，它綜合了上述若干模型，并把專家系統(tǒng)結(jié)合在一起。該模型應(yīng)用基于規(guī)則的系統(tǒng)，采用歸約和推理機(jī)制，幫助軟件人員完成開發(fā)工作，并使維護(hù)在系統(tǒng)規(guī)格說明一級進(jìn)行。第3章系統(tǒng)分析和設(shè)計3.1系統(tǒng)定義3.2可行性分析3.3需求分析3.4概要設(shè)計3.5詳細(xì)設(shè)計3.6界面設(shè)計3.1系統(tǒng)定義系統(tǒng)分析是一組統(tǒng)稱為計算機(jī)系統(tǒng)工程的活動。這里系統(tǒng)分析著眼于所有的系統(tǒng)生成元素，而不僅僅是軟件。系統(tǒng)分析是應(yīng)用系統(tǒng)的思想和方法，把復(fù)雜的對象分解成簡單的組成部分，找出這些部分的基本屬性和彼此間的關(guān)系。在軟件工程項(xiàng)目開始時，往往要先進(jìn)行系統(tǒng)定義，確定系統(tǒng)硬件、軟件的功能和接口。系統(tǒng)定義涉及的問題不完全屬于軟件工程范疇，它為系統(tǒng)提供總體概貌，根據(jù)對需求的初步理解，把系統(tǒng)功能分配給硬件、軟件及系統(tǒng)的其他部分

3.1系統(tǒng)定義系統(tǒng)定義是整個工程的基礎(chǔ)，它的任務(wù)是：充分理解所涉及的問題，對問題的解決辦法進(jìn)行論證。評價問題解決辦法的不同實(shí)現(xiàn)方案。表達(dá)解決方案，以便進(jìn)行復(fù)審。系統(tǒng)定義后，軟件的功能也初步確定，接下來要進(jìn)行軟件問題定義、可行性研究、指定軟件開發(fā)計劃和復(fù)審。問題定義（problemdefinition）階段必須回答的關(guān)鍵問題是：“要解決的問題是什么?”通過對客戶的訪問調(diào)查研究，明確系統(tǒng)目標(biāo)、規(guī)模、基本要求，并對現(xiàn)有系統(tǒng)進(jìn)行分析，設(shè)計新系統(tǒng)可能的解決方案。扼要地寫出關(guān)于問題性質(zhì)、工程目標(biāo)和工程規(guī)模的書面報告，經(jīng)過討論和必要的修改之后這份報告應(yīng)該得到客戶的確認(rèn)。3.2可行性分析

開發(fā)一個基于計算機(jī)的系統(tǒng)會受到時間和資源上的限制。所以，在一個新項(xiàng)目開發(fā)之前，應(yīng)該根據(jù)用戶提供的條件進(jìn)行可行性研究，這樣可以避免人力、財力和物力上的浪費(fèi)。

3.2.1可行性研究的任務(wù)可行性研究的目的是用最少的代價在盡可能短的時間內(nèi)確定問題能夠解決?？尚行匝芯康娜蝿?wù)：首先需要進(jìn)行概要的分析研究，初步確定項(xiàng)目的規(guī)模、目標(biāo)、約束和限制。分析員再進(jìn)行簡要的需求分析，抽象出項(xiàng)目的邏輯結(jié)構(gòu)，建立邏輯模型。從邏輯模型出發(fā)，經(jīng)過壓縮的設(shè)計，探索出若干種可供選擇的解決方法，對每種解決方法都要研究它的可行性。

3.2可行性分析主要從四個方面考慮：技術(shù)可行性：是指設(shè)備條件、技術(shù)解決方案的實(shí)用性和技術(shù)資源的可用性。一般要考慮的情況包括：開發(fā)的風(fēng)險即設(shè)計出的系統(tǒng)能否達(dá)到要求的功能和性能；資源的有效性；相關(guān)技術(shù)的發(fā)展是否支持。經(jīng)濟(jì)可行性：進(jìn)行開發(fā)成本的估算以及了解取得效益的評估，確定要開發(fā)的項(xiàng)目是否值得投資。社會可行性：要開發(fā)的項(xiàng)目是否存在任何侵權(quán)問題，運(yùn)行方式在用戶組織內(nèi)是否可行，現(xiàn)有管理制度﹑人員素質(zhì)﹑操作方式是否可行。方案的選擇：提出并評價實(shí)現(xiàn)系統(tǒng)的各種開發(fā)方案，選出最適合該項(xiàng)目的切實(shí)可行的方案。3.2可行性分析3.2.2可行性研究的過程可行性研究的具體步驟如下:復(fù)查系統(tǒng)規(guī)模和目標(biāo)

系統(tǒng)分析員訪問關(guān)鍵人員，仔細(xì)閱讀和分析有關(guān)的材料，以便對問題定義階段書寫的關(guān)于規(guī)模和目標(biāo)的報告書進(jìn)一步復(fù)查確認(rèn)，改正含糊或不確切的敘述，清晰地描述對目標(biāo)系統(tǒng)的一切限制和約束。這個步驟的工作，實(shí)質(zhì)上是為了確保分析員正在解決的問題確實(shí)是要求他解決的問題。研究正在使用的系統(tǒng)現(xiàn)有的系統(tǒng)是信息的重要來源。新系統(tǒng)必須能解決舊系統(tǒng)中存在的問題。此外，運(yùn)行使用舊系統(tǒng)所需要的費(fèi)用是一個重要的經(jīng)濟(jì)指標(biāo)，如果新系統(tǒng)不能增加收入或減少使用費(fèi)用，那么從經(jīng)濟(jì)角度看新系統(tǒng)就不如舊系統(tǒng)。3.2可行性分析收集﹑研究﹑分析現(xiàn)有系統(tǒng)的文檔資料，實(shí)地考察系統(tǒng)訪問有關(guān)人員，然后描繪現(xiàn)有系統(tǒng)的高層系統(tǒng)流程圖。并請有關(guān)人員檢驗(yàn)他對現(xiàn)有系統(tǒng)的認(rèn)識是否正確。千萬不要花費(fèi)太多時間去了解和描繪現(xiàn)有系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)。還要注意了解并記錄現(xiàn)有系統(tǒng)和其他系統(tǒng)之間的接口情況，這是設(shè)計新系統(tǒng)時的重要約束條件。建立新系統(tǒng)的高層邏輯模型優(yōu)秀的設(shè)計過程通?？偸菑默F(xiàn)有的物理系統(tǒng)出發(fā)，導(dǎo)出現(xiàn)有系統(tǒng)的邏輯模型，再參考現(xiàn)有系統(tǒng)的邏輯模型，設(shè)想目標(biāo)系統(tǒng)的邏輯模型，最后根據(jù)目標(biāo)系統(tǒng)的邏輯模型建造新的物理系統(tǒng)?？梢允褂脭?shù)據(jù)流圖和數(shù)據(jù)字典描述數(shù)據(jù)在系統(tǒng)中的流動和處理情況。3.2可行性分析導(dǎo)出和評價各種方案

分析員應(yīng)該從他建議的系統(tǒng)邏輯模型出發(fā)，導(dǎo)出若干個較高層次的（較抽象的）物理解決方法供比較和選擇。根據(jù)技術(shù)可行性﹑經(jīng)濟(jì)可行性﹑社會可行性進(jìn)行評估，得到可行的解決方法。推薦可行方案

進(jìn)行成本～效益分析，決定該項(xiàng)目是否值得開發(fā)。如果分析員認(rèn)為值得繼續(xù)進(jìn)行這項(xiàng)開發(fā)工程，那么他應(yīng)該選擇一種最好的解法，并且說明選擇這個解決方案的理由。草擬開發(fā)計劃分析員應(yīng)該為所推薦的方案草擬一份開發(fā)計劃，除了制定工程進(jìn)度表之外還應(yīng)該估計對各類開發(fā)人員和各種資源的需要情況，應(yīng)該指明什么時候使用以及使用多長時間。此外還應(yīng)該估計系統(tǒng)生命周期每個階段的成本。最后應(yīng)該給出下一個階段（需求分析）的詳細(xì)進(jìn)度表和成本估計

3.2可行性分析編寫文檔并提交審查應(yīng)該把上述可行性研究各個步驟的工作結(jié)果寫成清晰的文檔，即可行性研究報告，請用戶、客戶組織的負(fù)責(zé)人及評審組審查，以決定是否繼續(xù)這項(xiàng)工程及是否接受分析員推薦的方案。3.2可行性分析3.2.3系統(tǒng)流程圖在軟件項(xiàng)目的開發(fā)過程中，軟件開發(fā)人員需要進(jìn)行業(yè)務(wù)和技術(shù)交流。為了準(zhǔn)確地表達(dá)出交流的信息，需要有專門的描述工具，這些工具可以用圖或表的形式表現(xiàn)，其中系統(tǒng)流程圖是描述系統(tǒng)工程物理模型的工具。它用圖形符號來表示系統(tǒng)中各個元素，表達(dá)各元素之間的信息流動情況。系統(tǒng)流程圖的基本符號見表3.1。3.2可行性分析符號名稱說明處理能改變數(shù)據(jù)值或數(shù)據(jù)位置的加工或部件。例如：程序、處理機(jī)、人工加工等都是處理。

輸入/輸出表示輸入或輸出，是一廣義的不指明具體設(shè)備的符號連接指出轉(zhuǎn)到圖的另一部分或從另一部分轉(zhuǎn)來，通常在同一布頁上

換頁連接指出轉(zhuǎn)到另一頁上或從另一頁上轉(zhuǎn)來數(shù)據(jù)流用來連接其他符號，指明數(shù)據(jù)流動方向3.2可行性分析文檔

通常表示打印輸出，也可表示用打印終端輸入數(shù)據(jù)聯(lián)機(jī)存儲

表示任何種類的聯(lián)機(jī)存儲

磁盤磁盤輸入/輸出，也可表示存儲在磁盤上的文件或數(shù)據(jù)庫人工輸入

人工輸入數(shù)據(jù)的脫機(jī)處理，如：填寫表格人工操作

人工完成的處理，如：會計在工資支票上簽名通信鏈路

通過通信鏈路傳送數(shù)據(jù)

3.2可行性分析圖3.1為銀行取款系統(tǒng)流程圖。儲戶通過銀行終端的操作，建立與服務(wù)器端的數(shù)據(jù)通信，進(jìn)行密碼驗(yàn)證、查詢余額、取款等功能的實(shí)現(xiàn).圖3.1銀行取款系統(tǒng)流程圖

3.2可行性分析3.2.4成本／效益分析

軟件開發(fā)需要進(jìn)行投資，軟件運(yùn)行后需要得到收益，在進(jìn)行可行性分析時要從經(jīng)濟(jì)的角度評價軟件項(xiàng)目是否可行。成本/效益分析是對軟件的開發(fā)成本和可能取得的效益進(jìn)行權(quán)衡比較。目的是從經(jīng)濟(jì)角度評價一個新項(xiàng)目是否可行、是否劃算，從而幫助使用部門負(fù)責(zé)人正確地作出是否投資于這項(xiàng)開發(fā)項(xiàng)目的決定。成本估計代碼行技術(shù)。代碼行技術(shù)是比較簡單的定量估算方法，它把開發(fā)每個軟件功能的成本和實(shí)現(xiàn)這個功能需要用的源代碼行數(shù)聯(lián)系起來。通常根據(jù)經(jīng)驗(yàn)和歷史數(shù)據(jù)估計實(shí)現(xiàn)這一功能需要的源代碼行數(shù)。一旦估計出源代碼行數(shù)以后，用每行代碼的平均成本乘以行數(shù)就可以確定軟件的成本。每行代碼的平均成本取決于軟件的復(fù)雜程度和開發(fā)人員的工資水平。3.2可行性分析

任務(wù)分解技術(shù)。這種方法首先把軟件開發(fā)工程分解若干個相對獨(dú)立的任務(wù)，再分別估計每個單獨(dú)的開發(fā)任務(wù)的成本，最后累加起來得出軟件開發(fā)工程的總成本。最常用的辦法是按開發(fā)階段劃分任務(wù)。表3.2給出了典型環(huán)境下各個開發(fā)階段在生存周期中需要使用的人力百分比。

3.2可行性分析任務(wù)人力（%）可行性研究5需求分析10軟件設(shè)計

25編碼和單元測試

20綜合測試40總計

100表3.2典型環(huán)境下各個開發(fā)階段所需人力的百分比

3.2可行性分析度量效益的方法

貨幣的時間價值。通常用貨幣的時間價值進(jìn)行估算。可用利率來表示貨幣的時間價值。設(shè)年利率為i，現(xiàn)存入P元，n年后可得錢數(shù)為F，若不計復(fù)利則F=P×（1+i）n反之，若n年能收入F元，那么這些錢現(xiàn)在的價值是：P=F/（1+i）n。

例如，在工程設(shè)計中用CAD系統(tǒng)取代大部分人工設(shè)計工作，每年可節(jié)省9.6萬元。假設(shè)軟件生存期為5年，則5年可節(jié)省48萬元。開發(fā)這個CAD系統(tǒng)共投資了20萬元。這里就需要把5年內(nèi)每年節(jié)省的錢折合成現(xiàn)在的價值才能進(jìn)行比較。

設(shè)年利率為5%，利用上面計算貨幣現(xiàn)在價值的公式，可以算出引入CAD系統(tǒng)后，每年節(jié)省的錢的現(xiàn)在價值，如表3.3所示3.2可行性分析表3.3貨幣的時間價值年份將來值(萬元)（1+i）n

現(xiàn)在值(萬元)

累計(萬元)

19.61.059.14299.142929.61.10258.707517.851339.61.15768.292826.143249.61.21557.897934.041159.61.27637.521941.56303.3需求分析軟件需求分析（Requirementanalysis）確定軟件系統(tǒng)應(yīng)具備的具體功能。只有通過軟件需求分析，才能把軟件功能和性能的總體概念描述為具體的軟件需求規(guī)格說明，從而奠定軟件開發(fā)的基礎(chǔ)。軟件需求分析也是一個不斷認(rèn)識和逐步細(xì)化的過程。該過程將軟件計劃階段所確定的軟件范圍逐步細(xì)化到可詳細(xì)定義的程度，并分析出各種不同的軟件元素，然后為這些元素找到可行的解決方法。需求分析階段對問題進(jìn)行分析建模。需求分析的結(jié)果應(yīng)該反映的是必須干什么，而不是怎么干。它的主要用途是明確需求、為用戶和開發(fā)人員提供一起協(xié)商討論的基礎(chǔ)、作為設(shè)計和實(shí)現(xiàn)的依據(jù)。在需求分析階段結(jié)束之前，系統(tǒng)分析員應(yīng)該寫出軟件需求規(guī)格說明書，以書面形式準(zhǔn)確地描述軟件需求。3.3需求分析圖3.2需求分析示意圖3.3需求分析3.3.1需求分析的任務(wù)

軟件需求分析的任務(wù)是深入描述軟件的功能和性能，確定軟件實(shí)際的限制和軟件同它系統(tǒng)之間的接口細(xì)節(jié)，定義軟件的其它有效性需求，借助當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型，解決目標(biāo)系統(tǒng)“做什么”的問題。實(shí)現(xiàn)步驟如圖3.3所示。圖3.3參考當(dāng)前系統(tǒng)建立目標(biāo)系統(tǒng)模型

3.3需求分析3.3.2需求分析的過程需求分析是發(fā)現(xiàn)、求精、建模、規(guī)格說明和復(fù)審的過程。需求分析的過程如圖3.4所示。需求分析階段的工作可分為四個方面：問題識別、分析與綜合、編寫文檔、需求分析評審。

圖3.4需求分析過程

3.3需求分析問題識別。雙方確定對問題的綜合需求，這些需求包括功能需求，性能需求，環(huán)境需求，用戶界面需求。

分析與綜合。系統(tǒng)分析員需從數(shù)據(jù)流和數(shù)據(jù)結(jié)構(gòu)出發(fā)，逐步細(xì)化軟件的所有功能，找處系統(tǒng)各元素之間的聯(lián)系、接口特性和對設(shè)計的限制，分析它們能否滿足功能需求，是否合理。最終將其綜合成系統(tǒng)的解決方案，給出目標(biāo)系統(tǒng)的詳細(xì)邏輯模型。

編寫文檔。已經(jīng)確定的需求應(yīng)當(dāng)?shù)玫角逦鷾?zhǔn)確的描述，即將其編制成文檔。通常把描述需求的文檔稱為“需求規(guī)格說明書”。同時，為了確切表達(dá)用戶對軟件的輸入輸出要求，還要制定“數(shù)據(jù)要求說明書”、“初步用戶使用手冊”，以及“確認(rèn)測試計劃”、“修改完善軟件開發(fā)計劃”。

將用戶準(zhǔn)確、全面地轉(zhuǎn)化為需求規(guī)格說明書并以此作為作為產(chǎn)品的設(shè)計依據(jù)；確保用戶和軟件開發(fā)者雙方對軟件的初始規(guī)定有一個共同的理解，使之成為整個開發(fā)工作的基礎(chǔ)，需求分析評審。對功能的正確性、完整性和清晰性，以及其他需求給予評價。3.3需求分析3.3.3需求分析的原則需求分析：開發(fā)人員準(zhǔn)確地理解用戶的要求，進(jìn)行細(xì)致的調(diào)查分析，將用戶非形式的需求陳述轉(zhuǎn)化為完整的需求定義，再由需求定義轉(zhuǎn)換到相應(yīng)的需求規(guī)格說明的過程。

它有以下幾難點(diǎn)：問題的復(fù)雜性交流障礙不完備性和不一致性需求易變性。用戶的要求經(jīng)常有所變化

3.3需求分析3.3.4需求分析的方法

需求分析方法由對軟件的數(shù)據(jù)域和功能域的系統(tǒng)分析過程及其表示方法組成。它定義了表示系統(tǒng)邏輯視圖和物理視圖的方式。大多數(shù)的需求分析方法是由數(shù)據(jù)驅(qū)動的，也就是說，這些方法提供了一種表示數(shù)據(jù)域的機(jī)制，分析員根據(jù)這種表示，確定軟件功能及其他特性，最終建立一個待開發(fā)軟件的抽象模型，即目標(biāo)系統(tǒng)的邏輯模型。當(dāng)前主要采用的需求分析方法分為結(jié)構(gòu)化分析方法（StructuredAnalysis，SA）、面向?qū)ο蠓治龇椒?Objected-OrientedAnalysis，OOA).

3.3需求分析3.3.5需求分析的工具層次方框圖

圖3.5某計算機(jī)公司產(chǎn)品的層次方框圖

3.3需求分析Warnier圖

圖3.6軟件產(chǎn)品的Warnier圖3.3需求分析

IPO圖

圖3.7IPO圖的一個例子3.3需求分析3.3.6結(jié)構(gòu)化分析結(jié)構(gòu)化分析（StructuredAnalysis,簡稱SA），是面向數(shù)據(jù)流進(jìn)行數(shù)據(jù)分析的方法。于20世紀(jì)70年代末由E.Yourdon等人提出和發(fā)展。采用自頂向下逐層分解的分析策略。頂層抽象地描述整個系統(tǒng)，底層具體地畫出系統(tǒng)工程的每個細(xì)節(jié)，中間層則是從抽象到具體的過渡數(shù)據(jù)詞典實(shí)體—關(guān)系圖數(shù)據(jù)流圖狀態(tài)轉(zhuǎn)換圖加工規(guī)格說明數(shù)據(jù)對象描述控制規(guī)格說明3.3需求分析分析模型結(jié)構(gòu)的核心是數(shù)據(jù)字典（DD，DataDictionary），它描述了所有的在目標(biāo)系統(tǒng)中使用的和生成的數(shù)據(jù)對象，包含了軟件使用或生產(chǎn)的所有數(shù)據(jù)對象描述的中心數(shù)據(jù)庫。分析模型結(jié)構(gòu)的中間層有三種視圖。實(shí)體-關(guān)系圖（E-RD，Entity-RelationshipDiagram）描述數(shù)據(jù)對象之間的關(guān)系。數(shù)據(jù)流圖（DFD，DataFlowDiagram）服務(wù)于兩個目的：一是描述數(shù)據(jù)在系統(tǒng)中如何被傳送或變換，二是描述如何對數(shù)據(jù)流進(jìn)行變換的功能和子功能。數(shù)據(jù)流圖可以用于信息域的分析，并作為功能建模的基礎(chǔ)。狀態(tài)轉(zhuǎn)換圖（STD，StateTransitionDiagram）描述系統(tǒng)對外部事件如何響應(yīng)，如何動作。狀態(tài)轉(zhuǎn)換圖表示系統(tǒng)的各種行為模式，以及在狀態(tài)間轉(zhuǎn)換的方式，是行為建模的基礎(chǔ)。分析模型結(jié)構(gòu)的外層是描述。在實(shí)體-關(guān)系圖中出現(xiàn)的每個數(shù)據(jù)對象的屬性可以使用數(shù)據(jù)對象描述來描述。在數(shù)據(jù)流圖中出現(xiàn)的每個加工/處理的功能描述包含在加工規(guī)格說明中。軟件控制方面的附加信息包含在控制規(guī)格說明中。3.3需求分析數(shù)據(jù)建模

為了把用戶的數(shù)據(jù)要求清晰地表達(dá)出來。通常要建立一個概念性的數(shù)據(jù)模型，最常用的表示方法是建立實(shí)體聯(lián)系即E-R（Entity-Relationship）模型。E-R模型是一個面向問題概念性的數(shù)據(jù)模型，它采用E-R圖描述現(xiàn)實(shí)世界中的實(shí)體，而不涉及這些實(shí)體在系統(tǒng)中的實(shí)現(xiàn)方法，主要用來描述靜態(tài)的數(shù)據(jù)結(jié)構(gòu)。在E-R模型中包含“實(shí)體”、“屬性”和“聯(lián)系”等三個基本成分:3.3需求分析圖3.9某校教學(xué)管理的E-R圖3.3需求分析數(shù)據(jù)流圖數(shù)據(jù)流圖（DFD,Dataflowdiagram）也稱為BubbleChart或DataFlowGraph。它是描述數(shù)據(jù)處理過程的有力工具。數(shù)據(jù)流圖從數(shù)據(jù)傳遞和加工的角度，以圖形的方式刻畫數(shù)據(jù)流從輸入到輸出的移動變換過程。作為一種描述手段，它可以模擬手工的、自動的或是兩者混合的數(shù)據(jù)處理過程。以圖形的方式描述數(shù)據(jù)在系統(tǒng)中流動和處理的過程。只反映系統(tǒng)必須完成的邏輯功能，是一種功能模型。3.3需求分析數(shù)據(jù)流圖的基本符號

圖3.10數(shù)據(jù)流圖的基本符號處理。輸入數(shù)據(jù)在此進(jìn)行變換產(chǎn)生輸出數(shù)據(jù)數(shù)據(jù)輸入的源點(diǎn)或數(shù)據(jù)輸出的匯點(diǎn)數(shù)據(jù)流。被加工的數(shù)據(jù)與流向數(shù)據(jù)存儲文件，須加以命名3.3需求分析圖3.11銀行存取款手續(xù)的數(shù)據(jù)流圖3.3需求分析分層數(shù)據(jù)流圖圖3.12分層數(shù)據(jù)流圖3.3需求分析

行為建模狀態(tài)是任何可以被觀察到的行為模式，一個狀態(tài)代表系統(tǒng)的一種行為模式。狀態(tài)模型是一種描述系統(tǒng)對內(nèi)部或者外部事件響應(yīng)的行為模型。它描述系統(tǒng)狀態(tài)和事件，以及事件引發(fā)系統(tǒng)在狀態(tài)間的轉(zhuǎn)換。狀態(tài)模型一般采用狀態(tài)轉(zhuǎn)換圖（狀態(tài)圖）標(biāo)記方法。（1）畫狀態(tài)轉(zhuǎn)換圖的步驟。找出實(shí)體的所有狀態(tài)。分析在不同狀態(tài)下，對象的行為規(guī)則有無差別，若無差別則應(yīng)將它們合并為一種狀態(tài)。3.3需求分析分析從一種狀態(tài)可以轉(zhuǎn)換到哪幾種其它狀態(tài)，對象的什么行為能引起這種轉(zhuǎn)換，有無狀態(tài)轉(zhuǎn)換的限制條件。（2）狀態(tài)轉(zhuǎn)換圖的符號。狀態(tài)轉(zhuǎn)換圖中常見的符號如下：橢圓：表示對象的一種狀態(tài)，橢圓內(nèi)部填寫狀態(tài)名。箭頭：表示從箭頭開始的狀態(tài)可以轉(zhuǎn)換為箭頭指向的狀態(tài)。事件：箭頭線上方可標(biāo)引起狀態(tài)轉(zhuǎn)換的事件名。事件后可加方括號，括號內(nèi)寫狀態(tài)轉(zhuǎn)換的條件。實(shí)心圓：指出該對象被創(chuàng)建后所處的初始狀態(tài)。內(nèi)部實(shí)心的同心圓：表示最終狀態(tài)3.3需求分析圖3.17棧的狀態(tài)轉(zhuǎn)換圖3.3需求分析

數(shù)據(jù)詞典分析模型中包含了對數(shù)據(jù)對象、功能和控制的表示。在每一種表示中，數(shù)據(jù)對象和控制項(xiàng)都扮演一定的角色。為表示每個數(shù)據(jù)對象和控制項(xiàng)的特性，建立了數(shù)據(jù)詞典。數(shù)據(jù)詞典精確地、嚴(yán)格地定義了每一個與系統(tǒng)相關(guān)的數(shù)據(jù)元素，并以字典式順序?qū)⑺鼈兘M織起來，使得用戶和分析員對所有的輸入、輸出、存儲成分和中間計算有共同的理解。3.3需求分析3.3.7面向?qū)ο蠓治雒嫦驅(qū)ο蠓椒ǎ∣bjected-OrientedMethod）是90年代流行的一種新的軟件開發(fā)方法。面向?qū)ο蠓椒▽W(xué)的出發(fā)點(diǎn)和基本原則，是盡可能模擬人類習(xí)慣的思維方式，使開發(fā)軟件的方法與過程盡可能接近人類認(rèn)識世界解決問題的方法與過程，也就是使描述問題的問題空間（也稱為問題域）與實(shí)現(xiàn)解法的解空間（也稱為求解域）在結(jié)構(gòu)上盡可能一致。1.面向?qū)ο蠓治鼋?OOA)面向?qū)ο蠓治觯∣OA，Objected-OrientedAnalysis）的目的是對客觀世界的系統(tǒng)進(jìn)行建模。在面向?qū)ο蠓椒ㄖ校浖治龅幕救蝿?wù)是從現(xiàn)實(shí)問題空間抽象出對象空間。為了更好地理解問題，人們常常采用建立問題模型的方法。3.3需求分析面向?qū)ο蟮哪Ｐ桶ㄈ齻€，它們分別是：描述系統(tǒng)數(shù)據(jù)結(jié)構(gòu)的對象模型、描述系統(tǒng)控制結(jié)構(gòu)的動態(tài)模型和和描述系統(tǒng)功能的功能模型。

（1）對象模型

對象模型表示了靜態(tài)的、結(jié)構(gòu)化的系統(tǒng)數(shù)據(jù)性質(zhì)，描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)，它是從客觀世界實(shí)體的對象關(guān)系角度來描述，表現(xiàn)了對象的相互關(guān)系。該模型主要關(guān)心的是系統(tǒng)中對象的結(jié)構(gòu)、屬性和操作，使用了對象圖的工具來刻畫，它是分析階段三個模型的核心，也是其他兩個模型的框架。3.3需求分析

圖3.18類與對象圖形符號3.3需求分析（2）動態(tài)模型動態(tài)模型是與時間和變化有關(guān)的系統(tǒng)性質(zhì)。該模型描述了系統(tǒng)的控制結(jié)構(gòu)，它表示了瞬時的、行為化的系統(tǒng)控制性質(zhì)，它關(guān)系的是系統(tǒng)的控制，操作的執(zhí)行順序，它從對象的事件和狀態(tài)的角度出發(fā)，表現(xiàn)了對象的相互行為。該模型描述的系統(tǒng)屬性是觸發(fā)事件，事件序列、狀態(tài)、事件與狀態(tài)的組織。使用狀態(tài)圖作為描述工具。通常，用狀態(tài)圖來描繪對象的狀態(tài)、觸發(fā)狀態(tài)轉(zhuǎn)換的事件、以及對象的行為(對事件的響應(yīng))。狀態(tài)圖的表示方法如圖3.19所示。3.3需求分析

圖3.19狀態(tài)圖表示符號3.3需求分析（3）功能模型功能模型描述了系統(tǒng)的所有計算。功能模型指出發(fā)生了什么，動態(tài)模型確定什么時候發(fā)生，而對象模型確定發(fā)生的客體。功能模型表明一個計算如何從輸入值得到輸出值，它不考慮所計算的次序。功能模型由多張數(shù)據(jù)流圖組成。數(shù)據(jù)流圖說明數(shù)據(jù)流是如何從外部輸入、經(jīng)過操作和內(nèi)部存儲輸出到外部的。功能模型也包括對象模型中值的約束條件。功能模型說明對象模型中操作的含義、動態(tài)模型中動作的意義以及對象模型中約束的意義。圖3.20給出了數(shù)據(jù)流圖的表示方法。3.3需求分析

圖3.20數(shù)據(jù)流圖

3.3需求分析2．面向?qū)ο蠓治龇椒?.3需求分析主題（Subject）層。將相關(guān)對象用不同的主題層來表示和實(shí)現(xiàn)，是面向?qū)ο蠓治鲋袑?fù)雜問題分解的一種方式。對象（Object）層。對象是數(shù)據(jù)及專用處理的抽象，表示待開發(fā)相同的基本構(gòu)造塊，反映系統(tǒng)保存有關(guān)信息和與現(xiàn)實(shí)世界的交互能力。結(jié)構(gòu)（Structure）層。結(jié)構(gòu)表示問題空間的復(fù)雜度。結(jié)構(gòu)分為一般/特殊和整體/部分兩種方式。屬性（Attribute）層。屬性是用來描述一個對象或者一個分類結(jié)構(gòu)實(shí)例的數(shù)據(jù)單元。表示對象所存儲的數(shù)據(jù)以及類（對象）之間的相互約束關(guān)系。方法（Method）層。方法也稱為服務(wù)，是收到消息之后所執(zhí)行的處理，表示對象的服務(wù)以及對象之間的消息通信。3.3需求分析3．UML

UML是一種基于面向?qū)ο蟮目梢暬ＵZ言，實(shí)現(xiàn)了基于面向?qū)ο蟮慕９ぞ叩慕y(tǒng)一，已成為國際、國內(nèi)可視化建模語言實(shí)際上的工業(yè)標(biāo)準(zhǔn)。

UML的組成UML用圖形符號隱含表示了模型元素的語法，用這些圖形符號組成元模型表達(dá)語義，組成模型描述系統(tǒng)結(jié)構(gòu)（或稱為靜態(tài)特征）以及行為（或稱為動態(tài)特征）。（2）UML的模型UML提供了兩大類，支持系統(tǒng)建模：標(biāo)識對象，對象的數(shù)據(jù)屬性，對象相聯(lián)系的行為性狀以及與支持業(yè)務(wù)系統(tǒng)需求的聯(lián)系，使之文檔化。3.3需求分析（3）UML的特點(diǎn)和應(yīng)用

UML是面向?qū)ο蟮挠美Ｐ?、?對象模型、動態(tài)模型等不同系統(tǒng)模型的圖形符號描述。它所提供的表示模型元素的圖形和方法，能簡潔明確地表達(dá)面向?qū)ο蠹夹g(shù)的主要概念和建立各類系統(tǒng)模型。它的標(biāo)準(zhǔn)化定義、可視化描述、可擴(kuò)展性機(jī)制等，顯示了UML強(qiáng)大的生命力。（4）利用UML進(jìn)行系統(tǒng)建模的主要步驟建立系統(tǒng)功能描述的模型，也稱用例建模。以各業(yè)務(wù)事件為基點(diǎn)，建立系統(tǒng)功能的模型，誰引起事件，系統(tǒng)如何響應(yīng)事件。找出和標(biāo)識好各個業(yè)務(wù)對象。組織好各個對象并標(biāo)識好他們之間的關(guān)系。建立起對象行為性狀的模型。

3.4概要設(shè)計3.4.1軟件設(shè)計的任務(wù)在軟件需求分析階段已經(jīng)完全弄清楚了軟件的各種需求，較好地解決了要讓所開發(fā)的軟件“做什么”的問題，并已在軟件需求規(guī)格說明和數(shù)據(jù)要求規(guī)格說明中詳盡和充分地闡明了這些需求。下一步就要著手實(shí)現(xiàn)軟件的需求，即要著手解決“怎么做”的問題。軟件設(shè)計的輸入輸出，如圖3.24所示。3.4概要設(shè)計

圖3.24軟件設(shè)計示意圖3.4概要設(shè)計分析模型中的每一個成份都提供了建立設(shè)計模型所需的信息。軟件設(shè)計的信息流如圖3.25所示。根據(jù)用數(shù)據(jù)、功能和行為模型表示的軟件需求，采用某種設(shè)計方法進(jìn)行數(shù)據(jù)設(shè)計、體系結(jié)構(gòu)設(shè)計、接口設(shè)計和過程設(shè)計。圖3.25將分析模型轉(zhuǎn)換為軟件設(shè)計3.4概要設(shè)計3.4.2概要設(shè)計的任務(wù)軟件總體設(shè)計階段要做的事情是什么呢?確定系統(tǒng)設(shè)計方案、軟件的體系結(jié)構(gòu)、軟件由哪些模塊組成以及這些模塊之間的相互關(guān)系?？偟膩砜从兴膫€方面，它們是：設(shè)計軟件系統(tǒng)結(jié)構(gòu)(軟件結(jié)構(gòu))。數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)庫設(shè)計。編寫概要設(shè)計文檔。評審。3.4概要設(shè)計3.4.3概要設(shè)計的過程總體設(shè)計通常由系統(tǒng)設(shè)計和結(jié)構(gòu)設(shè)計兩個階段組成。系統(tǒng)設(shè)計階段確定系統(tǒng)的具體實(shí)現(xiàn)方案，結(jié)構(gòu)設(shè)計階段確定軟件的結(jié)