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

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

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

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

1.1軟件發展簡史

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

多態性

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

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

1.2.1什么是軟件危機軟件危機是指在計算機軟件開發和維護過程中所遇到的一系列嚴重問題。其具體表現如下:

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

1.2.2軟件危機的形成原因

軟件危機的出現一方面固然與軟件本身的特點有關，另一方面也與軟件的開發和維護方法有關，具體原因如下:軟件本身是邏輯部件，是無形的產品，看不見摸不著，質量往往難以評價，潛在的錯誤在所難免，并且質量檢測非常復雜，往往不能在交付使用之前檢查出所有錯誤。軟件在運行中不會因為使用時間長而損壞，如果運行中出現問題，一般是由于在開發階段引入而在測試階段沒有發現的問題。因此，軟件的修改和維護實際是對原有設計的修改和改進。1.2軟件危機

軟件規模越來越大，軟件結構越來越復雜。1968年美國航空公司訂票軟件系統規模達到30萬條指令；IBM360操作系統的16版達到100萬條指令；1973年美國阿波羅項目達到1000萬條指令。這些龐大的軟件功能非常復雜，其調用關系、接口信息、數據結構都十分復雜，其復雜程度遠遠超過了人所能接受的程度。

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

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

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

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

1.2軟件危機

其次，應該開發和使用更好的軟件工具。在軟件開發的每個階段都由許多繁瑣重復的工作要做，在適當的軟件工具的輔助下，開發人員可以做得又快又好。把各個階段使用的軟件工具有機地集合起來構成一個整體，支持軟件開發的全過程，這稱為軟件工程支撐環境。

最后，應該采取必要的管理措施。軟件產品是一種無形的產品，它不同于一般工程項目的管理。必須采取適合軟件產品特點的管理措施，通過人員組織管理、項目計劃管理、配置管理等環節來保證軟件開發按時按質量完成。1.2軟件危機1.3軟件工程1.3.1什么是軟件工程

本書采用如下定義：軟件工程是指導計算機軟件開發和維護的一門學科，它采用工程的概念、原理、技術和方法，把經過時間考驗而證明是正確的管理技術與技術方法結合起來用于開發軟件。軟件工程是一門指導性的學科，它在宏觀上或總體上指導人們如何開發軟件系統。可以說，軟件工程就是“軟件的哲學”。軟件工程的目標是指導成功地開發大型軟件系統，達到降低開發成本、實現要求的功能、取得較好的性能和可靠性、軟件系統易于移植、降低維護費用、按時完成開發任務、及時交付使用等具體的目標。

圖1.1軟件工程目標之間的關系1.3軟件工程1.3.2軟件工程的基本原理

自從軟件工程的概念提出以來，專家學者們陸續提出了100多條關于軟件工程的準則。1983年B.Woehm提出了軟件工程的七條基本原理。

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

1.3軟件工程1.3軟件工程

堅持進行階段評審。統計結果顯示，大約63%的軟件錯誤是在編碼之前造成的，錯誤發現得越晚，改正錯誤花費的代價就越高，相差達到2~3個數量級。因此，軟件的質量保證工作不能等到編碼結束后再進行，應當堅持嚴格的階段評審，以便及早發現錯誤。

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

采用現代程序設計技術。從提出軟件工程的概念開始，人們的主要精力都用于研究各種新的程序設計技術，20世紀60年代的結構化程序設計技術隨后發展為結構化分析技術和結構化設計技術，已成為被大多數人認可的先進技術，后來又出現了面向對象技術。計算機程序設計語言也從一代、二代、三代發展到第四代語言。人們已經充分認識到，采用先進的技術可以極大地提高軟件開發效率，降低軟件維護成本。

工作成果應當能夠清楚地審查。軟件產品不同于一般的物理產品，軟件是邏輯產品，看不見、摸不著。軟件開發小組的工作進展情況可見性差，難于評價和管理。為了更好地管理，應根據軟件開發的總目標及完成期限，盡量明確地規定開發小組的責任和產品標準，從而使所得到工作成果能按標準清楚地審查。1.3軟件工程

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

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

軟件工程研究的主要內容是軟件開發技術和軟件開發管理兩個方面。軟件開發技術主要包括軟件開發方法、軟件開發過程、軟件開發工具和環境。軟件開發管理主要包括軟件管理學、軟件經濟學和軟件心理學等，包括人員分配、制定計劃、確定標準與配置、成本估算、質量評價等。傳統的軟件工程學的基本內容如下:

軟件生存周期模型。描述軟件開發總過程的理論模型，指導整個軟件開發過程。

軟件分析。確定待開發軟件的總體要求和使用范圍以及與之相關的硬件和支撐軟件的要求，包括系統分析、可行性分析、軟件開發計劃、需求分析，主要介紹結構化分析方法。1.3軟件工程

軟件設計。包括總體設計和詳細設計兩個階段，產生軟件的總體結構、軟件包含的所有功能模塊及其接口規范、全局數據結構和局部數據結構以及各模塊的詳細算法，涉及軟件設計基本原理和軟件設計基本方法等問題，主要介紹結構化設計方法。

軟件實現。將設計階段的數據結構和各功能模塊采用某種程序語言“翻譯”為可執行的程序，涉及程序設計語言的選擇、程序設計方法、程序設計風格等問題的研究，主要介紹結構化程序設計方法。

軟件測試。對已經用程序語言實現的程序模塊進行單元測試，和對已經過測試的模塊進行組裝測試，以保證最終程序能正確可靠地運行。

軟件維護。軟件開發結束交付使用后，在整個使用期間可能需要不斷地維護，以修改新發現的錯誤，或是為了適應變化了的環境，或是擴充原有的功能。

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

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

圖2.1軟件工程層次

軟件過程定義了一組關鍵過程域，它們構成軟件項目管理的基礎，并規定了技術方法的采用、工程產品（模型、文檔、數據、報告以及表格等）的產生、里程碑的建立、質量的管理以及適當的變更控制。2.1軟件工程過程軟件過程是軟件生存期中的一系列相關軟件工程活動的集合。每一個軟件過程又是由一組工作任務、項目里程碑、軟件工程產品和交付物以及質量保證（SQA）點等組成。一個軟件過程可以用圖2.2的形式來表示。

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

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

2.1軟件工程過程圖2.4問題循環解決過程中階段嵌套階段2.1軟件工程過程2.1.3過程建造技術

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

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

軟件定義可分為軟件系統的可行性研究和需求分析兩個階段:軟件系統的可行性研究可行性研究的任務是了解用戶要求和現實環境，從技術、經濟、市場等方面研究并論證開發該軟件系統的可行性。即這個軟件系統是否值得開發，是否有可行的技術去開發。系統分析員一般需通過以下途徑完成此階段的任務:調查和了解用戶要求和現實環境。撰寫調查報告。可行性論證和分析（技術可行性、操作可行性和經濟可行性）如可行，制定初步項目開發計劃（成本估算、人員組織、進度安排等）。

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

2.2軟件生存周期軟件需求分析不僅是軟件開發依據，而且也是軟件驗收的標準。

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

在軟件生存周期模型中，軟件開發由概要設計、詳細設計、實現、集成測試和確認測試五個階段組成。概要設計概要設計的任務是根據軟件需求規格說明（SRS）建立軟件系統的總體結構和模塊間的關系，定義各功能模塊的接口，設計全局數據庫或數據結構，規定設計約束，制定組裝測試計劃。對于大型軟件系統，應對軟件需求進行分解，將其劃分為若干個子系統，對每個子系統定義功能模塊和各功能模塊之間的關系，并給出各子系統接口界面的定義；對于一般的軟件系統可以直接定義各功能模塊以及它們之間的關系

概要設計應提供概要設計說明書、數據庫或數據結構設計說明書、組裝測試計劃等文件。

2.2軟件生存周期詳細設計

詳細設計的任務是對概要設計產生的功能模塊逐步細化，形成若干個可編程的程序模塊，用某種過程設計語言（ProcedureDesignLanguage）設計程序模塊的內部細節，包括算法、數據結構和各程序模塊之間的詳細接口信息，為編寫源代碼提供必要的說明，建立“模塊開發卷宗”，擬定模塊測試方案。詳細設計需根據軟件需求規格說明（SRS）和概要設計的結果進行，可以選用的方法和工具是比較多的，如結構化的設計方法、面向對象的設計等方法和RationaRose、VisualModel及MicrosoftVisio等工具。軟件開發人員可以根據實際情況選用適當的方法和工具。詳細設計應該遵循的原則是：設計應與軟件需求保持一致，設計的軟件結構應支持模塊化、信息隱藏等。詳細設計應該提供詳細設計規格說明書和單元測試計劃。

2.2軟件生存周期

實現實現的主要任務是，根據詳細設計文檔將詳細設計轉化為所要求的編程語言或數據庫語言的程序，并對這些程序進行調試和程序單元測試，驗證程序模塊接口與詳細設計文檔的一致性。集成測試

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

通過集成測試的軟件應生成滿足概要設計要求、可運行的系統源程序清單和集成測試報告。2.2軟件生存周期確認測試確認測試的任務是根據軟件需求規格說明定義的全部功能和性能要求及軟件確認測試計劃對軟件系統進行測試，測試系統是否達到了系統需求或是否滿足用戶的需求。

確認測試應有客戶參加，以軟件需求規格說明書為依據，使用專用的測試工具進行確認測試。為驗證軟件產品是否滿足軟件需求規格說明的要求，必須按照測試計劃的要求編制大量的測試用例、采用多種方法和工具、組織專門的測試隊伍并嚴格組織實施。

確認測試階段應向用戶提交最終的用戶手冊、操作手冊、源程序清單及其他軟件文檔。確認測試結束時應生成確認測試報告、項目開發總結報告。2.2軟件生存周期2.2.3軟件使用、維護和退役軟件的使用

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

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

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

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

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

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

噴泉模型對軟件復用和生存周期中多項開發活動的集成提供了支持，主要支持面向對象的開發方法，如圖2.9所示

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

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

開發一個基于計算機的系統會受到時間和資源上的限制。所以，在一個新項目開發之前，應該根據用戶提供的條件進行可行性研究，這樣可以避免人力、財力和物力上的浪費。

3.2.1可行性研究的任務可行性研究的目的是用最少的代價在盡可能短的時間內確定問題能夠解決。可行性研究的任務：首先需要進行概要的分析研究，初步確定項目的規模、目標、約束和限制。分析員再進行簡要的需求分析，抽象出項目的邏輯結構，建立邏輯模型。從邏輯模型出發，經過壓縮的設計，探索出若干種可供選擇的解決方法，對每種解決方法都要研究它的可行性。

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

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

分析員應該從他建議的系統邏輯模型出發，導出若干個較高層次的（較抽象的）物理解決方法供比較和選擇。根據技術可行性﹑經濟可行性﹑社會可行性進行評估，得到可行的解決方法。推薦可行方案

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

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

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

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

通常表示打印輸出，也可表示用打印終端輸入數據聯機存儲

表示任何種類的聯機存儲

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

人工輸入數據的脫機處理，如：填寫表格人工操作

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

通過通信鏈路傳送數據

3.2可行性分析圖3.1為銀行取款系統流程圖。儲戶通過銀行終端的操作，建立與服務器端的數據通信，進行密碼驗證、查詢余額、取款等功能的實現.圖3.1銀行取款系統流程圖

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

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

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

3.2可行性分析任務人力（%）可行性研究5需求分析10軟件設計

25編碼和單元測試

20綜合測試40總計

100表3.2典型環境下各個開發階段所需人力的百分比

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

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

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

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

現在值(萬元)

累計(萬元)

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

軟件需求分析的任務是深入描述軟件的功能和性能，確定軟件實際的限制和軟件同它系統之間的接口細節，定義軟件的其它有效性需求，借助當前系統的邏輯模型導出目標系統的邏輯模型，解決目標系統“做什么”的問題。實現步驟如圖3.3所示。圖3.3參考當前系統建立目標系統模型

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

圖3.4需求分析過程

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

分析與綜合。系統分析員需從數據流和數據結構出發，逐步細化軟件的所有功能，找處系統各元素之間的聯系、接口特性和對設計的限制，分析它們能否滿足功能需求，是否合理。最終將其綜合成系統的解決方案，給出目標系統的詳細邏輯模型。

編寫文檔。已經確定的需求應當得到清晰準確的描述，即將其編制成文檔。通常把描述需求的文檔稱為“需求規格說明書”。同時，為了確切表達用戶對軟件的輸入輸出要求，還要制定“數據要求說明書”、“初步用戶使用手冊”，以及“確認測試計劃”、“修改完善軟件開發計劃”。

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

它有以下幾難點：問題的復雜性交流障礙不完備性和不一致性需求易變性。用戶的要求經常有所變化

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

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

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

圖3.5某計算機公司產品的層次方框圖

3.3需求分析Warnier圖

圖3.6軟件產品的Warnier圖3.3需求分析

IPO圖

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

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

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

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

數據詞典分析模型中包含了對數據對象、功能和控制的表示。在每一種表示中，數據對象和控制項都扮演一定的角色。為表示每個數據對象和控制項的特性，建立了數據詞典。數據詞典精確地、嚴格地定義了每一個與系統相關的數據元素，并以字典式順序將它們組織起來，使得用戶和分析員對所有的輸入、輸出、存儲成分和中間計算有共同的理解。3.3需求分析3.3.7面向對象分析面向對象方法（Objected-OrientedMethod）是90年代流行的一種新的軟件開發方法。面向對象方法學的出發點和基本原則，是盡可能模擬人類習慣的思維方式，使開發軟件的方法與過程盡可能接近人類認識世界解決問題的方法與過程，也就是使描述問題的問題空間（也稱為問題域）與實現解法的解空間（也稱為求解域）在結構上盡可能一致。1.面向對象分析建模(OOA)面向對象分析（OOA，Objected-OrientedAnalysis）的目的是對客觀世界的系統進行建模。在面向對象方法中，軟件分析的基本任務是從現實問題空間抽象出對象空間。為了更好地理解問題，人們常常采用建立問題模型的方法。3.3需求分析面向對象的模型包括三個，它們分別是：描述系統數據結構的對象模型、描述系統控制結構的動態模型和和描述系統功能的功能模型。

（1）對象模型

對象模型表示了靜態的、結構化的系統數據性質，描述了系統的靜態結構，它是從客觀世界實體的對象關系角度來描述，表現了對象的相互關系。該模型主要關心的是系統中對象的結構、屬性和操作，使用了對象圖的工具來刻畫，它是分析階段三個模型的核心，也是其他兩個模型的框架。3.3需求分析

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

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

圖3.20數據流圖

3.3需求分析2．面向對象分析方法3.3需求分析主題（Subject）層。將相關對象用不同的主題層來表示和實現，是面向對象分析中將復雜問題分解的一種方式。對象（Object）層。對象是數據及專用處理的抽象，表示待開發相同的基本構造塊，反映系統保存有關信息和與現實世界的交互能力。結構（Structure）層。結構表示問題空間的復雜度。結構分為一般/特殊和整體/部分兩種方式。屬性（Attribute）層。屬性是用來描述一個對象或者一個分類結構實例的數據單元。表示對象所存儲的數據以及類（對象）之間的相互約束關系。方法（Method）層。方法也稱為服務，是收到消息之后所執行的處理，表示對象的服務以及對象之間的消息通信。3.3需求分析3．UML

UML是一種基于面向對象的可視化建模語言，實現了基于面向對象的建模工具的統一，已成為國際、國內可視化建模語言實際上的工業標準。

UML的組成UML用圖形符號隱含表示了模型元素的語法，用這些圖形符號組成元模型表達語義，組成模型描述系統結構（或稱為靜態特征）以及行為（或稱為動態特征）。（2）UML的模型UML提供了兩大類，支持系統建模：標識對象，對象的數據屬性，對象相聯系的行為性狀以及與支持業務系統需求的聯系，使之文檔化。3.3需求分析（3）UML的特點和應用

UML是面向對象的用例模型、類/對象模型、動態模型等不同系統模型的圖形符號描述。它所提供的表示模型元素的圖形和方法，能簡潔明確地表達面向對象技術的主要概念和建立各類系統模型。它的標準化定義、可視化描述、可擴展性機制等，顯示了UML強大的生命力。（4）利用UML進行系統建模的主要步驟建立系統功能描述的模型，也稱用例建模。以各業務事件為基點，建立系統功能的模型，誰引起事件，系統如何響應事件。找出和標識好各個業務對象。組織好各個對象并標識好他們之間的關系。建立起對象行為性狀的模型。

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

圖3.24軟件設計示意圖3.4概要設計分析模型中的每一個成份都提供了建立設計模型所需的信息。軟件設計的信息流如圖3.25所示。根據用數據、功能和行為模型表示的軟件需求，采用某種設計方法進行數據設計、體系結構設計、接口設計和過程設計。圖3.25將分析模型轉換為軟件設計3.4概要設計3.4.2概要設計的任務軟件總體設計階段要做的事情是什么呢?確定系統設計方案、軟件的體系結構、軟件由哪些模塊組成以及這些模塊之間的相互關系。總的來看有四個方面，它們是：設計軟件系統結構(軟件結構)。數據結構及數據庫設計。編寫概要設計文檔。評審。3.4概要設計3.4.3概要設計的過程總體設計通常由系統設計和結構設計兩個階段組成。系統設計階段確定系統的具體實現方案，結構設計階段確定軟件的結