軟件工程課件

軟件工程第2章需求分析

本章要點：需求分析的任務和原則可行性研究的任務和步驟結構化分析分析方法和面向對象分析方法需求建模與規(guī)格說明軟件需求驗證軟件工程本章學習目標：了解需求分析的任務和原則掌握可行性研究的步驟掌握結構化分析分析方法和面向對象分析方法了解需求建模與規(guī)格說明了解軟件需求驗證方法和有關工具軟件工程2.1需求分析的任務

需求分析的基本任務是準確地回答“系統(tǒng)必須做什么?”這個問題。目標系統(tǒng)提出完整、準確、清晰、具體的要求。需求分析階段的具體任務一、確定對系統(tǒng)的綜合要求。

對系統(tǒng)的綜合要求有下述四個方面：

1．系統(tǒng)功能要求

應該劃分出系統(tǒng)必須完成的所有功能。

軟件工程2．系統(tǒng)性能要求

例如，聯(lián)機系統(tǒng)的響應時間(即對于從終端輸入的一個“事務”，系統(tǒng)在多長時間之內可以做出響應)，系統(tǒng)需要的存儲容量以及后援存儲，重新啟動和安全性等方面的考慮都屬于性能要求。

3．運行要求這類要求集中表現(xiàn)為對系統(tǒng)運行時所處環(huán)境的要求。例如，支持系統(tǒng)運行的系統(tǒng)軟件是什么，采用哪種數據庫管理系統(tǒng)，需要什么樣的外存儲器和數據通信接口等。

軟件工程4．將來可能提出的要求應該明確地列出那些雖然不屬于當前系統(tǒng)開發(fā)范疇，但是據分析將來很可能會提出來的要求。這樣做的目的是在設計過程中對系統(tǒng)將來可能的擴充和修改預做準備，以便一旦需要時能比較容易地進行這種擴充和修改。二、分析系統(tǒng)的數據要求任何一個軟件系統(tǒng)本質上都是信息處理系統(tǒng)，系統(tǒng)必須處理的信息和系統(tǒng)應該產生的信息在很大程度上決定了系統(tǒng)的面貌，對軟件設計有深遠影響，因此，必須分析系統(tǒng)的數據要求，這是軟件需求分析的一個重要任務。分析系統(tǒng)的數據要求通常采用建立概念模型的方法。軟件工程復雜的數據由許多基本的數據元素組成，數據結構表示數據元素之間的邏輯關系。利用數據字典可以全面準確地定義數據，但是數據字典的缺點是不夠形象直觀。為了提高可理解性，常常利用圖形工具輔助描繪數據結構。常用的圖形工具有層次方框圖和Warnier圖。

三、導出系統(tǒng)的邏輯模型綜合上述兩項分析的結果可以導出系統(tǒng)的詳細的邏輯模型，通常用數據流圖、數據字典和主要的處理算法描述這個邏輯模型。

四、修正系統(tǒng)開發(fā)計劃根據在分析過程中獲得的對系統(tǒng)的更深入更具體的了解，軟件工程可以比較準確地估計系統(tǒng)的成本和進度，修正以前制定的開發(fā)計劃。五、開發(fā)原型系統(tǒng)在計算機硬件和許多甚他工程產品的設計過程中經常使用樣機。建造樣機通常有兩個主要目的：檢驗關鍵設計方案的正確性及系統(tǒng)是否真正滿足用戶的需要。對于軟件系統(tǒng)的開發(fā)，使用“樣機”(更正確的名稱應該是原型系統(tǒng))的主要目的是，使用戶通過實踐獲得關于未來的系統(tǒng)將怎樣為他們工作的更直接更具體的概念，從而可以更準確地提出和確定他們的要求。軟件工程2.2需求分析的原則

需求分析的前提是準確、完整地獲取用戶需求。向問題領域的專家學習，進行用戶需求查是需求分析的第一步。用戶需求通?？梢苑譃楣δ苄枨蠛托阅苄枨髢深?。功能需求定義了系統(tǒng)應該做什么，系統(tǒng)要求輸入什么信息，輸出什么信息，以及如何將輸入變換為輸出。性能需求則定義了軟件運行的狀態(tài)特征，如系統(tǒng)運行效率，可靠性，安全性，可維護性等等。綜合起來，應該獲取用戶需求的內容包括：(1)物理環(huán)境。系統(tǒng)運行的設備地點、位置是集中式的還是分布式的，對環(huán)境的要求如何(如溫度、濕度，電磁場干擾等)。

軟件工程(2)系統(tǒng)界面。要求與其他系統(tǒng)進行數據交換的內容與格式，終端用戶的類型與熟練程度，用戶對界面的特定要求，用戶操作的易接受性等。(3)系統(tǒng)功能。系統(tǒng)應該完成的功能以及何時完成，對于系統(tǒng)運行速度、響應時間或者數據吞吐量的要求，系統(tǒng)運行的權限規(guī)定，系統(tǒng)可靠性要求，是否要求可移植，未來擴充或者升級的要求。(4)數據要求。輸入偷出數據的種類與格式，計算必須達到的精度，數據接收與發(fā)送的頻率，數據存儲的容量和可靠性，數據或者文件訪問的控制權限，數據備份的要求。軟件工程(5)系統(tǒng)文檔規(guī)格。系統(tǒng)要求交付什么文檔，各類文檔的編制規(guī)范和預期使用對象。(6)系統(tǒng)維護要求。系統(tǒng)出錯后可以允許的最大恢復時間，對錯誤修改的回歸測試要求，系統(tǒng)運行日志規(guī)格，是否允許對系統(tǒng)修改，系統(tǒng)變化如何反映到設計中。在獲取需求過程中遇到的典型問題及其解決方法是：(1)如何理解問題。大多數情況下，軟件開發(fā)人員不是問題領域的行家。但是要準確、完整的獲取需求必須對問題具有深入的理解與把握。許多問題即使是用戶業(yè)務人員也可能沒有自覺的認識。(2)分析員與用戶的通信問題。分析員對問題的理解軟件工程必須從信息處理要求出發(fā)，而用戶更多的考慮是本身的業(yè)務領域。與用戶建立相互信任、有效的溝通是分析員的首要任務。(3)用戶需求的可變性。用戶需求通常是不斷變化的，而軟件開發(fā)人員則希望將需求凍結在某一時刻。影響用戶需求變化的因素可以是用戶領域的業(yè)務擴充或者轉移，市場競爭的要求，用戶主管人員的變更等。現(xiàn)實情況是分析員只能接受需求不斷變化的事實，應該千方百計地使其工作適應需求的變化?，F(xiàn)實世界是復雜多變的。為了將現(xiàn)實世界中問題的求解映射為信息處理模型，對問題進行分解與抽象是普遍有效的基本法則。

軟件工程2.3可行性研究

2.3.1可行性研究的任務可行性研究的目的就是用最小的代價在盡可能短的時間內確定問題是否能夠解決。確定問題是否值得去解。首先需要進一步分析和澄清問題定義。在問題定義階段初步確定的規(guī)模和目標，如果

是正確的就進一步加以肯定，如果有錯誤就應該及時改正，如果對目標系統(tǒng)有任何約束和

限制，也必須把它們清楚地列舉出來。

在澄清了問題定義之后，分析員應該導出系統(tǒng)的邏輯模型。然后從系統(tǒng)邏輯模型出

發(fā)，探索若干種可供選擇的主要解法(即系統(tǒng)實現(xiàn)方案)。對每種解法都應該仔細研究它的

可行性，一般說來，至少應該從下述三方面研究每種解法的可行性：

軟件工程(1)技術可行性使用現(xiàn)有的技術能實現(xiàn)這個系統(tǒng)嗎?(2)經濟可行性這個系統(tǒng)的經濟效益能超過它的開發(fā)成本嗎?(3)操作可行性系統(tǒng)的操作方式在這個用戶組織內行得通嗎?

分析員應該為每個可行的解法制定一個粗略的實現(xiàn)進度。軟件工程2.3.2可行性研究的步驟

一、復查系統(tǒng)規(guī)模和目標

分析員訪問關鍵人員，仔細閱讀和分析有關的材料，以便對問題定義階段書寫的關于規(guī)模和目標的報告書進一步復查確認，改正含糊或不確切的敘述，清晰地描述對目標系統(tǒng)的一切限制和約束。二、研究目前正在使用的系統(tǒng)

現(xiàn)有的系統(tǒng)是信息的重要來源。顯然，如果目前有一個系統(tǒng)正被人使用，那么這個系統(tǒng)必定能完成某些有用的工作，因此，新的目標系統(tǒng)必須也能完成它的基本功能；另一方面，如果現(xiàn)有的系統(tǒng)是完美無缺的，用戶自然不會提出開發(fā)新系統(tǒng)的要求，因此，現(xiàn)有的系統(tǒng)必然有某些缺點，新系統(tǒng)必須能解決舊系統(tǒng)中存在的問題。

軟件工程

應該仔細閱讀分析現(xiàn)有系統(tǒng)的文檔資料和使用手冊，也要實地考察現(xiàn)有的系統(tǒng)。三、導出新系統(tǒng)的高層邏輯模型

優(yōu)秀的設計過程通常總是從現(xiàn)有的物理系統(tǒng)出發(fā)，導出現(xiàn)有系統(tǒng)的邏輯模型，再參考現(xiàn)有系統(tǒng)的邏輯模型，設想目標系統(tǒng)的邏輯模型，最后根據目標系統(tǒng)的邏輯模型建造新的物理系統(tǒng)。四、重新定義問題

新系統(tǒng)的邏輯模型實質上表達了分析員對新系統(tǒng)必須做什么的看法。用戶是否也有

同樣的看法呢?分析員應該和用戶一起再次復查問題定義、工程規(guī)模和目標，這次復查軟件工程應該把數據流圖和數據字典作為討論的基礎。五、導出和評價供選擇的解法分析員應該從他建議的系統(tǒng)邏輯模型出發(fā)，導出若干個較高層次的(較抽象的)物理解法供比較和選擇。導出供選擇的解法的最簡單的途徑，是從技術角度出發(fā)考慮解決問題的不同方案。在數據流圖上劃分不同的自動化邊界，從而導出不同物理方案的方法。當從技術角度提出了一些可能的物理系統(tǒng)之后，應該根據技術可行性的考慮初步排除一些不現(xiàn)實的系統(tǒng)。軟件工程其次可以考慮操作方面的可行性。接下來應該考慮經濟方面的可行性。分析員應該估計余下的每個可能的系統(tǒng)的開發(fā)

成本和運行費用，并且估計相對于現(xiàn)有的系統(tǒng)而言這個系統(tǒng)可以節(jié)省的開支或可以增加的收入。最后為每個在技術、操作和經濟等方面都可行的系統(tǒng)制定實現(xiàn)進度表，這個進度表不

需要(也不可能)制定得很詳細，通常只需要估計生命周期每個階段的工作量。六、推薦行動方針根據可行性研究結果應該做出的一個關鍵性決定是，是否繼續(xù)進行這項開發(fā)工程。分

析員必須清楚地表明他對這個關鍵性決定的建議。

軟件工程七、草擬開發(fā)計劃分析員應該進一步為推薦的系統(tǒng)草擬一份開發(fā)計劃，除了工程進度表之外還應該估計對各種開發(fā)人員(系統(tǒng)分析員，程序員，資料員等等)和各種資源(計算機硬件，軟件工具等等)的需要情況，應該指明什么時候使用以及使用多長時間。此外還應該估計系統(tǒng)生命周期每個階段的成本。最后應該給出下一個階段(需求分析)的詳細進度表和成本估計。八、書寫文檔提交審查應該把上述可行性研究各個步驟的結果寫成清晰的文檔，請用戶和使用部門的負責人仔細審查，以決定是否繼續(xù)這項工程以及是否接受分析員推薦的方案。

軟件工程2.3.3系統(tǒng)流程圖

系統(tǒng)流程圖是描繪物理系統(tǒng)的傳統(tǒng)工具。它的基本思想是用圖形符號以黑盒子形式描繪系統(tǒng)里面的每個部件(程序、文件、數據庫、表格、人工過程等等)。一、符號

當以概括的方式抽象地描繪一個物理系統(tǒng)時，僅僅使用圖2．1中列出的基本符號就夠了，其中每個符號表示系統(tǒng)中的一個部件。當需要更具體地描繪一個物理系統(tǒng)的時候還需要使用圖2．2中列出的系統(tǒng)符號，利用這些符號可以把一個廣義的輸入／輸出操作具體化為讀／寫存儲在特殊設備上的文件(或數據庫)，把一般的處理具體化為特定的程序或手工操作等等。

軟件工程圖2．1基本符號符號名

稱說

明處理能改變數據值或數據位置的加工或部件，例如，程序、處理機、人工加工等都是處理

輸入／輸出表示輸入或輸出(或既輸入又輸出)，是一個廣義的不指明具體設備的符號。

連接指出轉到圖的另一部分或從圖的另一部分轉來，通常在同一頁上

換頁連接指出轉到另一頁圖上或由另一頁圖轉來。

數據流用來連接其他符號，指明數據流動方向。

軟件工程圖2.2系統(tǒng)符號符號名

稱

穿孔卡片表示用穿孔卡片輸入或輸出，也可表示一個穿孔卡片文件。

文檔通常表示打印輸出，也可表示用打印終端輸入數據。

磁帶磁帶輸入／輸出，或表示一個磁帶文件。

聯(lián)機存儲表示任何種類的聯(lián)機存儲，包括磁盤、磁鼓、軟盤和海量存儲器件等。

磁盤磁盤輸入／輸出。也可表示存儲在磁盤上的文件或數據庫。

磁鼓磁鼓輸入／輸出，也可表示存儲在磁鼓上的文件或數據庫。

顯示CRT終端或類似的顯示部件，可用于輸入或輸出，也可既輸入又輸出。

人工輸入人工輸入數據的脫機處理，例如，填寫表格。

人工操作人工完成的處理，例如，會計在工資支票上簽名。

輔助操作使用設備進行的脫機操作。

通信鏈路通過遠程通信線路或鏈路傳送數據。

軟件工程二、例子

介紹系統(tǒng)流程圖的最好方法可能是通過一個具體例子說明它的用法。下面是一個簡單的例子。某裝配廠有一座存放零件的倉庫，倉庫中現(xiàn)有的各種零件的數量以及每種零件的庫存量臨界值等數據記錄在庫存清單主文件中。當倉庫中零件數量有變化時，應該及時修改庫存清單主文件，如果那種零件的庫存量少于它的庫存量臨界值，則應該報告給采購部門以便定貨，規(guī)定每天向采購部門送一次定貨報告。該裝配廠使用一臺小型計算機處理更新庫存清單主文件和產生定貨報告的任務。零件庫存量的每一次變化稱為一個事務，通過放在倉庫中的CRT終端輸入到計算機中；系統(tǒng)中的庫存清單程序對事務進行處理，更新存儲在軟件工程磁盤上的庫存清單主文件，并且把必要的定貨信息寫在磁帶上。最后，每天由報告生成程序讀一次磁帶，并且打印出定貨報告。圖2．3的系統(tǒng)流程圖描繪了上述系統(tǒng)的概貌。事務庫存清單程序訂貨信息報告生成程序訂貨報告庫存清單主文件圖2.3庫存清單系統(tǒng)的系統(tǒng)流程圖軟件工程三、分層面對復雜的系統(tǒng)時，一個比較好的方法是分層次地描繪這個系統(tǒng)。首先用一張高層次的系統(tǒng)流程圖描繪系統(tǒng)總體概貌，表明系統(tǒng)的關鍵功能。然后分別把每個關鍵功能擴展到適當的詳細程度，畫在單獨的一頁紙上。這種分層次的描繪方法便于閱讀者按照從抽象到具體的過程逐步深入地了解一個復雜的系統(tǒng)。

軟件工程2.4需求分析方法

2.4.1結構化分析方法結構化分析技術是70年代中期由E．Yourdon等人倡導的一種面向數據流的分析方法。按照T．Demarco的定義，“結構化分析就是使用數據流圖、數據詞典、結構化英語、判定表和判定樹等工具，來建立一種新的、稱為結構化說明書的目標文檔?！边@里的結構化說明書，就是需求規(guī)格說明書。結構化分析技術將軟件系統(tǒng)抽象為一系列的邏輯加工單元，各單元之間以數據流發(fā)生關聯(lián)。按照數據流分析的觀點，系統(tǒng)模型的功能是數據變換，邏輯加工單元接受輸入數據流，使之變換成輸出數據流。數據流模型常用數據流圖表示。

軟件工程

建立功能模型

數據流程圖，又稱數據流圖，它是以圖形的方式來表達數據處理系統(tǒng)中信息的變換和傳遞過程。作為一種描述手段，它可以模擬手工的、自動的以及兩兼而有之混合的數據處理過程。數據流程圖有三個重要屬性：

．可以表示任何一個系統(tǒng)(人工的、自動的或混合的)中的信息流程。

．每個圓圈可能需要進一步分解以求得對問題的全面理解。

．著重強調的是數據流程而不是控制流程。軟件工程以工資處理為例，我們畫出這一過程中數據加工過程各項活動的數據流程圖(見2.4)。圖2.4可知，數據流程圖中的基本符號有：1、數據流數據流是有名字有流向的數據，在數據流程圖中，數據流用標有名字的箭頭來表示，如圖2.1中的工資調整表、工資發(fā)放表等。2、加工加工又稱處理邏輯，表示數據所進行的加工或變換，圖2.4中以標有名字的圓圈代表加軟件工程工資匯總表工資發(fā)放表工資條工資計算工資冊取款總務人事工資匯總工資分配開戶銀行職工統(tǒng)籌醫(yī)療費房租費水電費托兒費工資調整表調入人員工資單調出人員調出單病事假扣款單工資費用分配表工資發(fā)放圖2.4工資處理數據流程圖軟件工程工。指向加工的數據流是該加工的輸入數據，離開加工的數據流是該加工的輸出數據，如圖2.4中的工資計算、取款等。3、文件文件是數據暫存的處所，可對文件進行必要的存取，在圖中以標有名字的雙直線段表示，如圖2.1中的工資冊、工資匯總表等。對文件的存取分別以指向或離開文件的箭頭表示。由于文件的內容能顧名思義，因而對其進行存取的箭頭即使沒有名字也不會造成混亂。4、數據源及數據終點表明數據處理過程的數據來源或數據去向的標志稱為軟件工程數據源及數據終點，在數據流程圖中均以命名的方框來表示，如圖2.4中的人事（科）。一般情況下，為了表達數據處理的數據加工過程，只用一個數據流程圖是不夠的。對稍為復雜一些的實際問題，常以層次結構的數據流程圖來表示。任何系統(tǒng)都是有層次的結構，如果按照層次結構對系統(tǒng)進行逐步分解，就能很清楚地表達和理解整個系統(tǒng)。在每一個層次上，最核心的部分就是數據加工乃其相關的數據流。除了上述4種基本成分外，數據流程圖還有幾種附加成分，例如，星號“﹡”表示幾股數據流之問是“與”的關系，加號“+”表示“或”的關系，⊙號表示從幾股數據流中選取一股，軟件工程即表示“互斥”的關系。我們來研究一個財務管理信息系統(tǒng)中的材料核算部分。圖2.2中的基本系統(tǒng)模型把整個材料核算工作抽象成一個加工，并標上所有的輸入數據流和輸出數據流，即為材料核算子系統(tǒng)的項層數據流程圖。有關材料統(tǒng)計報表材料分類明細帳材料采購付款憑證材料核算采購合同收料憑證發(fā)料憑證材料匯總表圖2.5頂層數據流程圖軟件工程把材料核算處理功能進行分解。一般材料核算包括采購核算、儲存核算、發(fā)出核算等，據此，我們畫出如圖2.5所示的第一層數據流程圖。分解后的子圖中生出了一些新的數據流和文件，它們是頂層數據流程圖中加工“材料核算”內部的數據流和文件，與其外部元素沒有聯(lián)系。在“材料核算”被分解后，這些數據流和文件成了一些子加工的界面。分別把第一層數據流程圖中的幾個核算處理（加工）再進行分解，可畫出第二層數據流程圖。圖2.5為其中的加工“材料發(fā)出核算”進行功能分解得到第二層數據流程圖，其他如材料采購核算、材料儲存核算等，都可以用同樣的方法講行分解擴展，畫出相應的數據流程圖。

軟件工程圖2.5、圖2.6和圖2.7畫出了3種不同層次的信息流程，表示出需求分析一層比一層更為具體細致。軟件工程收購憑證采購核算儲存核算發(fā)出核算材料匯總核算材料采購付款憑證采購合同發(fā)料憑證材料明細帳材料匯總表材料明晰分類帳有關材料統(tǒng)計報表材料采購合同執(zhí)行情況材料采購成本材料采購明細帳材料發(fā)出憑證生成用料應攤材料成本差異表其他用料存儲材料明細帳生產材料分配表圖2.6第一層數據流程圖軟件工程圖2.7第二層數據流圖生產用料分配表材料發(fā)出憑證材料發(fā)出憑證按用途歸類按產品分配車間管理用料企業(yè)管理用料輔助生產用料材料明細表生產用料應攤材料成本差異軟件工程

數據流程圖是一種圖解方法，它在軟件需求分析中是非常有用的。然而，如果它的作用與程序流程圖(框圖)混淆的話，也會引起混亂。數據流程圖描繪的是信息流，沒有明顯的控制說明(例如條件或循環(huán))，它不是一個用圓圈表示的程序流程圖。在推導面向軟件的數據流時有幾個非常有用而簡單的準則：1、

1、

一層數據流程圖應當是基本系統(tǒng)模型。2、應當仔細說明原始的輸入／輸出文件。3、所有箭頭和圓圈均應加上標注(使用有意義的名字)。

4、必須維持信息的連續(xù)性。

軟件工程5、每一次只應當細化一個圓圈。

6、可以在數據流程圖中加上物質流。有助于幫助用戶理解該數據流程圖。在畫分層數據流程圖時，要特別注意下面幾個問題：

1、加工的編號方法

加工的編號遵循兩條原則：第一，從加工的編號能知道該加工處在哪一層分解；第二，從加工編號知道該加工是從父圖中哪個加工分解得來的。2、分解程度

分解程度問題包括兩個方面，其一是每個加工每次軟件工程分解成幾個子加工比較恰當；其二是分解深度，即分解的層數問題。這兩個問題之間有一定的聯(lián)系。經驗表明，一個加工的分解以不超過7個子加工比較合適。3、父圖和子圖之間的平衡多層數據流程圖中的父圖和子圖之間的數據流必須保持一致(或稱保持“平衡“)，亦即，父圖中出現(xiàn)的輸入數據流和輸出數據流都應在子圖中出現(xiàn)，以保證加工過程的連續(xù)性和一致性。有時，當在子圖中對父圖的數據流做了分解后，檢驗父圖和子圖的平衡還需借助于數據字典。因為“自頂向下”逐層對數據流程圖的分解，實際上不僅是對加工進行分解，同時也對數據流進行分解。軟件工程

建立數據模型

在需求分析階段則既要分析用戶的數據要求（即需要哪些數據、數據之間有什么聯(lián)系、數據本身有什么性質、數據的結構等等），又要分析用戶的處理要求(即對數據進行哪些處理、每個處理的邏輯功能等等)。為了把用戶的數據要求清晰明確地表達出來，系統(tǒng)分析員通常建立一個概念性的數據模型(也稱為信息模型)。概念性數據模型是一種面向問題的數據模型，是按照用戶的觀點來對數據和信息建模。它描述了從用戶角度看到的數據，它反映了用戶的現(xiàn)實環(huán)境，且與在軟件系統(tǒng)中的實現(xiàn)方法無關。最常用的表示概念性數據模型的方法，是實體一聯(lián)系方法(Entity—RelationshipApproach)。這種方法用ER圖。軟件工程描述現(xiàn)實世界中的實體，而不涉及這些實體在系統(tǒng)中的實現(xiàn)方法。用這種方法表示的概念性數據模型又稱為ER模型。通常，軟件系統(tǒng)中有許多數據是需要長期保存的，為減少數據冗余，簡化修改數據的過程，應該對數據進行規(guī)范化。ER模型中包含“實體”、“聯(lián)系”和“屬性”等三個基本成分，下面分別介紹這三個基本成分：1．實體

實體是客觀世界中存在的且可相互區(qū)分的事物。實體可以是人也可以是物；可以是具體事物也可以是抽象概念。例如，職工、學生、課程、教師等都是實體。在ER圖中用矩形框代表實體。軟件工程2．聯(lián)系客觀世界中的事物彼此間往往是有聯(lián)系的。例如，教師與課程間存在“教”這種聯(lián)系，而學生與課程間則存在“學”這種聯(lián)系。聯(lián)系可分為三類：(1)一對一聯(lián)系(1︰1)例如，一個部門有一個經理，而每個經理只在一個部門任職，則部門與經理的聯(lián)系是一對一的。

(2)一對多聯(lián)系(1︰N)例如，某校教師與課程之間存在一對多的聯(lián)系“教”，即每位教師可以教多門課程，但是每門課程只能由一位教師來教。軟件工程(3)多對多聯(lián)系(M︰N)例如，學生與課程間的聯(lián)系(“學”)是多對多的，即一個學生可以學多門程，而每門課程可以有多個學生來學。在ER圖中，用連接相關實體的菱形框表示聯(lián)系。3．屬性屬性是實體或聯(lián)系所具有的性質。通常一個實體由若干個屬性來刻畫。例如，“學生”實體有學號、姓名、性別、系、年級等屬性；“教師”實體有教工號、姓名、性別、職稱、職務等屬性；“課程”實體有課程號、課名、學時、學分等屬性。軟件工程聯(lián)系也可能有屬性。例如，學生“學”某門課程所取得的成績，既不是學生的屬性也不是課程的屬性。由于“成績”既依賴于某名特定的學生又依賴于某門特定的課程，所以它是學生與課程之間的聯(lián)系“學”的屬性。N1NM教師教工號性別姓名職稱職務教師教師教學姓名性別系年級學號成績課程號課名學時學分圖2.8某校教學管理ER圖軟件工程

在ER圖中用橢圓形或圓角矩形表示實體(或聯(lián)系)的屬性，并用無向邊把實體(或聯(lián)系)與其屬性連接起來。人們通常就是用實體、聯(lián)系和屬性這三個概念來理解現(xiàn)實問題的，因此，ER模型比較接近人的習慣思維方式。此外，ER模型使用簡單的圖形符號表達系統(tǒng)分析員對問題域的理解，不熟悉計算機技術的用戶也能理解它，因此，ER模型可以作為用戶與分析員之間有效的交流工具。

4．范式通常用“范式(NormalForms)”定義消除數據冗余的程度。第一范式(1NF)數據冗余程度最大，第五范式(5NF)數據冗余程度最小。但是，范式級別越高，存儲同樣數據就軟件工程需要分解成更多張表，因此，“存儲自身”的過程也就越復雜。第二，隨著范式級別的提高，數據的存儲結構與基于問題域的結構間的匹配程度也隨之下降，因此，在需求變化時數據的穩(wěn)定性較差。第三，范式級別提高則需要訪問的表增多，因此性能（速度）將下降。從實用角度看來，在大多數場合選用第三范式都比較恰當。

1．第一范式每個屬性值都必須是原子值，即僅僅是一個簡單值而不含內部結構。2．第二范式滿足第一范式條件，而且每個非主屬性完全依賴于某個軟件工程候選鍵(而不是部分依賴于某個候選鍵)3．第三范式。符合第二范式的條件，所有非主屬性即不部分依賴于某個候選鍵，也不傳遞依賴于某個候選鍵。

軟件工程

建立行為模型

狀態(tài)轉換圖通過描述狀態(tài)以及導致系統(tǒng)改變狀態(tài)的事件來表示系統(tǒng)的行為，它沒有表示出系統(tǒng)所執(zhí)行的處理，只表示了處理結果可能的狀態(tài)轉換。STD用帶標記的圓圈或矩形表示狀態(tài)，用箭頭表示從一種狀態(tài)到另一種狀態(tài)的變換，箭頭上的文本標記表示引起變換的條件。轉換條件狀態(tài)圖2.9狀態(tài)轉換圖基本圖形元素軟件工程分析建模是實現(xiàn)真實世界模型向計算機模型轉換的核心環(huán)節(jié)，也是一種處理軟件復雜性的有效手段。在需求開發(fā)階段，分析建模的關鍵是針對用戶需求建立抽象的分析模型，從而有助于開發(fā)人員理解用戶需求，同時增強自然語言的需求規(guī)格說明。分析模型往往采用一些圖形化的表示方式，從數據、功能和行為等不同角度表達用戶需求。結構化分析是面向數據流進行需求分析的方法，經過20多年的發(fā)展，已經成為廣泛應用的技術之一。結構化分析方法以數據字典為核心，采用實體關系圖、數據流圖和狀態(tài)轉換圖等圖形來表達需求，直觀明了且易于理解和掌握。

軟件工程

數據詞典

數據字典是結構化分析方法的一個有力工具，它對數據流程圖中出現(xiàn)的所有數據元素給出邏輯定義。有了數據字典，使數據流程圖上的數據流、加工和文件能得到確切的解釋。

數據字典的條目可以分成四大類，即：

·數據流條目。

·文件條目。

·數據項條目。

·加工條目。軟件工程數據字典中的數據構成如圖2.10所示的層次關系。這些數據元素的定義通常用定義式的形式給出。圖2.10數據字典中數據的層次關系數據流文件數據結構數據元素軟件工程通常，在數據字典的定義式中可能出現(xiàn)的符號及其含意是(設x和a、b都是數據元素)：

x=a+bx由a和b構成

x=[a︱b]x由a或b構成

x=(a)數據元素a在x中可出現(xiàn)，也可不出現(xiàn)

x={a}x由0個或多個重復的a構成軟件工程1、數據流條目數據流條目主要說明數據流條目是由哪些數據項組成的，以及數據在單位時間內的流量，它的來源、去向等。條目格式如下：數據流名：組成：流量：來源：去向：軟件工程例如：數據流“銀行對賬單”條目：條目格式如下：數據流名：銀行對帳單組成：月份＋日期＋銀行支票＋金額流量：2張∕3天，每張約40筆數據來源：開戶銀行去向：資金管理組軟件工程2、文件條目文件條目主要說明文件由哪些數據項組成，存儲方式和存取頻率等。條目格式如下：文件名：

組成：

存儲方式：

存儲頻率：軟件工程例如：文件“現(xiàn)金日記賬”條目如下：文件名：現(xiàn)金日記賬

組成：月份＋日期＋摘要＋收入＋支出＋結存

存儲方式：順序

存儲頻率：20筆∕天軟件工程3、數據項條目

數據項名：

類型：

長度：

取值范圍：數據項條目主要說明數據項類型、長度、取值范圍等。軟件工程例如：數據項“憑證號”條目和數據項“經辦人”條目如下：

數據項名：憑證號

類型：數值

長度：6位（含小數一位）

取值范圍：1000.0～4999.9軟件工程4、加工條目加工條目主要說明加工的輸入數據、輸出數據及其加工邏輯等。條目格式如下：

加工名：

輸入數據：

輸出數據：

加工邏輯：

軟件工程例如加工“工資分配”條目：加工名：工資分配輸入數據：工資結算單(匯總表)輸出數據：工資費用分配表加工邏輯：各車間根據工資結算單，按產品種類或批別，分別分配管理人員工資和生產工人工資，并按比例提取福利基金。

軟件工程

和數據流程圖的層次概念相類似，一個數據字典的定義式不宜包含過多的項，這可以采取逐級定義的定義式，使得一些復雜的數據元素自頂向下多層定義，直到最后給出無需定義的基本數據元素。例如：日期=年+月+日數據字典就是這樣構造起來的一組定義式。必要時，定義式之間還可能有一些特定的注釋行出現(xiàn)，以利于理解。常用的詞典相似，數據字典所收集的數據定義，都按詞典的編輯方法順序排列，以方便使用。當然，不允許出現(xiàn)一個數據元素有多個定義的現(xiàn)象。

軟件工程2.4.2面向對象分析方法與UML

面向對象分析方法面向對象方法是一種把面向對象的思想應用于軟件開發(fā)過程中，指導開發(fā)活動的系統(tǒng)方法，簡稱OO方法，它是建立在對象概念(對象、類和繼承)基礎上的方法。面向對象方法成為90年代的主流開發(fā)方法，其原因主要在于：

1．從認知學的角度來看，面向對象方法符合人們對客觀世界的認識規(guī)律

2．面向對象方法開發(fā)的軟件系統(tǒng)易于維護，其體系結構易于理解、擴充和修改

3．面向對象方法中的繼承機制有力支持軟件的復用

軟件工程一、面向對象的基本概念PeterCoad和EdwardYourdon提出用下列等式來認識面向對象方法：面向對象=對象(Obiect)+分類(Classification)+繼承(Inheritance)+通過消息的通信(CommunicationWithMessages)可以說，采用這4個概念開發(fā)的軟件系統(tǒng)是面向對象的。1．對象

對象是指一組屬性以及這組屬性上的專用操作的封裝體。屬性通常是一些數據，有時它也可以是另一個對象。

軟件工程

對象中的屬性只能通過該對象所提供的操作來存取或修改。操作也稱為方法或服務，它規(guī)定了對象的行為，表示對象所能提供的服務。封裝是一種信息隱蔽技術，用戶只能看見對象封裝界面上的信息，對象的內部實現(xiàn)對用戶是隱蔽的，封裝的目的是使對象的使用者和生產者分離，使對象的定義和實現(xiàn)分開。一個對象通?？捎蓪ο竺?、屬性和操作三部分組成。

2．類

類是一組具有相同屬性和相同操作的對象的集合。一個類中的每個對象都是這個類的一個實例。

不必為每個對象逐個定義，只需對類作出定義，而對類的屬性的不同賦值即可得到該類的對象實例，類和軟件工程

對象之間的關系類似于程序設計語言中的類型和變量之間的關系。通常把一個類和這個類的所有對象稱為類及對象，或稱為對象類。一個類可以定義為另一個更一般的類的特殊情況，如“轎車”類是“汽車”類的特殊情況，我們稱一般類是特殊類的父類，特殊類是一般類的子類。這樣可以形成類的一種一般一特殊的層次關系。在這種一般一特殊的關系中，子類可以繼承其父類(或祖先類)的所有屬性和操作，同時子類中還可以定義自己特有的屬性和操作。所以子類的屬性和操作是子類中的定義部分和其祖先類中的定義部分的總和。繼承是類間的基本關系，它是基于層次關系的不同類共享數據和操作的一種機制。父類中定義了其所有子類的公共屬性和操作，在子類中除了定義自己特有的屬性和軟件工程操作外，還可以對父類(或祖先類)中的操作重新定義其實現(xiàn)方法。如果一個子類只有惟一一個父類，這個繼承稱為單一繼承。如果一個子類有一個以上的父類，這種繼承稱為多重繼承。

3．消息傳遞消息傳遞是對象間通信的手段，一個對象通過向另一個對象發(fā)送消息來請求其服務。一個消息通常包括接收對象名、調用的操作名和適當的參數(如果有必要的話)。消息只告訴接收對象需要完成什么操作，但并不指示接收者怎樣完成操作。消息完全由接收者解釋，接收者獨立決定采用什么方法完成所需的操作。軟件工程4．多態(tài)性

多態(tài)性是指同一個操作作用于不同的對象上可以有不同的解釋，并產生不同的執(zhí)行結果。例如“畫”操作，作用在“矩形”對象上，則在屏幕上畫一個矩形，作用在“圓”對象上，則在屏幕上畫一個圓。也就是說，相同操作的消息發(fā)送給不同的對象時，每個對象將根據自己所屬類中定義的這個操作去執(zhí)行，從而產生不同的結果。

與多態(tài)性密切相關的一個概念就是動態(tài)綁定(亦稱動態(tài)定連)。傳統(tǒng)的程序設計語言的過程調用與目標代碼的連接(即調用哪個過程)放在程序運行前進行(稱為靜態(tài)綁定)，而動態(tài)綁定則是把這種連接推遲到運行時才進行。

軟件工程二、面向對象分析

面向對象分析(Object—Oriented．Analysis，OOA)的目標是完成對所解問題的分析，確定待建的系統(tǒng)要做什么，并建立系統(tǒng)的模型。為達到這一目標，必須完成以下任務：

(1)在客戶和軟件工程師之間溝通基本的用戶需求。

(2)標識類(包括定義其屬性和操作)。

(3)刻畫類的層次結構。

(4)表示類(對象)之間的關系。

(5)為對象行為建模。

軟件工程(6)遞進地重復任務(1)至任務(5)，直至完成建模。

其中任務(2)至任務(4)刻畫了待建系統(tǒng)的靜態(tài)結構，任務(5)刻畫了系統(tǒng)的動態(tài)行為。

面向對象分析的一般步驟如下：

(1)獲取客戶對系統(tǒng)的需求：包括標識場景(Scenario)和用例(IJseCase)，以及建造需求模型。

(2)用基本的需求為指南來選擇類和對象(包括屬性和操作)。

(3)定義類的結構和層次。

(4)建造對象．關系模型。

軟件工程(5)建造對象一行為模型。(6)利用用例／場景來復審分析模型。三、面向對象設計

面向對象設計(Object-Oriented．Design，OOD)是將OOA所創(chuàng)建的分析模型轉化為設計模型。與傳統(tǒng)的開發(fā)方法不同，OOD和OOA采用相同的符號表示，OOD和OOA沒有明顯的分界線，它們往往反復迭代地進行。在OOA時，主要考慮系統(tǒng)做什么，而不關心系統(tǒng)如何實現(xiàn)。在OOD時，主要解決系統(tǒng)如何做，因此需要在OOA的模型中為系統(tǒng)的實現(xiàn)補充一些新的類，或在原有類中補充一些屬性和操作。OOD時應能從類中導出對象，以及這些對象如何互相關聯(lián)，還要描述對象間的關系、行為以及對象間的通信如何實現(xiàn)。

軟件工程OOD同樣應遵循抽象、信息隱蔽、功能獨立、模塊化等設計準則。

面向對象設計的一般步驟如下：

(1)系統(tǒng)設計?！⒆酉到y(tǒng)分配到處理器。

·選擇實現(xiàn)數據管理、界面支持和任務管理的設計策略。

·為系統(tǒng)設計合適的控制機制。

·復審并考慮權衡。

軟件工程(2)對象設計。

·在過程級別設計每個操作。

·定義內部類。

·為類屬性設計內部數據結構。

(3)消息設計。

使用對象間的協(xié)作和對象．關系模型，設計消息模型。

(4)復審。

復審設計模型，并在需要時迭代。

目前有許多種面向對象方法，例如Coad&Yourdon方法、OMT方法、Booch方法等。

軟件工程統(tǒng)一的建模語言

一、UML概述

1994年Booch和Rumbaugh在R~ionalsoftwareCorporation開始了UML的工作，其目標是創(chuàng)建一個“統(tǒng)一的方法”，他們把Booch一93和OMIT一2統(tǒng)一起來，于1995年發(fā)布了UM0.8(UnifiedMethod)。

OOSE的創(chuàng)始人jacobson加盟到這項工作中，他們以Booch方法、OMT方法、OOSE方法為基礎，吸收了其他流派的長處，于1996年6月、10月、1997年1月、11月分別推出了UML0.9，UML0.91，UML1.0，UMLl.1。

1997年11月，國際對象管理組織OMG(ObjectManagementGroup)批準把UML1.1作為基于面向對象技術的標準建模語言。

軟件工程一個系統(tǒng)往往可以從不同的角度進行觀察，從一個角度觀察到的系統(tǒng)，構成系統(tǒng)的一個視圖(View)，每個視圖是整個系統(tǒng)描述的一個投影，說明了系統(tǒng)的一個特殊側面。若干個不同的視圖可以完整地描述所建造的系統(tǒng)。視圖并不是一種圖表(Graph)，它是由若干幅圖(Diagram)組成的一種抽象。每種視圖用若干幅圖來描述，一幅圖包含了系統(tǒng)某一特殊方面的信息，它闡明了系統(tǒng)的一個特定部分或方面。由于不同視圖之間存在一些交叉，因此一幅圖可以作為多個視圖的一部分。一幅圖由若干個模型元素組成，模型元素表示圖中的概念。UML語言建立在面向對象的基礎上，它采用面向對象的概念和范型。UML語言的體系結構建立在四層元模型結構之上，這4層元模型分別為：元一元模型、元模型、軟件工程模型、用戶對象。1．元一元模型層元一元模型(Meta—metamodel)是建立元模型體系結構的基礎結構(Infrastructure)。元一元模型定義描述元模型的語言，是任何模型的基礎，用于對概念的形式化。2．元模型層元模型層(Metamodel)定義描述模型的語言。在UML語言的元模型中，定義了面向對象的范型的概念，如“對象類”、“屬性”、“操作”、“組件”等，它們是元模型層的元對象。元模型是元一元模型的一個實例。例如，“對象類”、“軟件工程屬性”、“操作”分別是“元對象類”、“元屬性”、“元操作”的實例。“對象類”是對一組具有共同的結構特征、行為特征、聯(lián)系和語義的對象的描述?！皩ο蟆笔恰皩ο箢悺钡囊粋€實例?！瓣P聯(lián)”是對一組具有共同的結構特征、行為特征、聯(lián)系和語義的鏈接的描述，“鏈接”用于為兩個或多個實體(對象類)之間具有共同特征的聯(lián)系建立模型?！版溄印笔恰瓣P聯(lián)”的一個實例，“鏈接”用于為兩個或多個對象之間的聯(lián)系實例建立模型。3．模型層模型(Model)是元模型的一個實例，在模型層定義用于描述信息領域的語言。模型是對現(xiàn)實世界的抽象。無論是問題領域還是解決軟件工程方案，都可以抽象成模型。模型是系統(tǒng)構建和更新的基礎，用于對問題和解決方案的理解與交流，便于管理和控制系統(tǒng)的復雜性。4．用戶對象層用戶對象(Userobjects)是模型的實例，用戶對象層定義一個特定的信息領域。用戶對象層用于表達一個模型的特定情況。為了模型的可視化，UML為每一個模型元素規(guī)定了獨特的圖形表示符號，稱為圖標(Icon)。這些圖標簡潔明了能夠容納足夠的語義，并且容易繪制方便區(qū)別。在UML的核心包中定義的分類符，如對象類、接口、軟件工程數據類型、節(jié)點、組件、信號、UseCase、子系統(tǒng)等，它們的圖標如圖2．11所示。其中，對象類的圖標是一個矩形框，并且可以劃分成3個分割框，分別含有類的名字、屬性和操作。接口的圖標是一個圓，旁邊標有接口的名字。數據類型的圖標是一個矩形框，框內含有構造型<type>>、數據類型的名稱、以及關于取值范圍的說明(可選)。信號的圖標是一個矩形框，框內含有構造型<<signal>>和信號的名字。UseCase的圖標是一個橢圓，內含UseCase的名字。組件的圖標是一個大矩形框的左邊帶兩個小矩形，大框內含有組件的名字。節(jié)點的圖標是一個三維立方體，其內含有節(jié)點的名字。包的圖標是一個大矩形框的左上角帶一個小矩形。子系統(tǒng)用包的圖標表達，即在包的圖標中含有構造型<<subsystem>>和軟件工程子系統(tǒng)的名字。實際上，以上這些分類符的圖標中可以包含比名字更多的信息。學生姓名入學注冊查詢成績對象類分析風險UseCase<<type>>Int{from–2**31to=2**31-1}數據類型<<signal>>offHook信號<<subsystem>>教學管理子系統(tǒng)子系統(tǒng)接口IUnknown

image.java組件節(jié)點數據庫服務器圖2．11分類符圖標示例軟件工程UML定義的聯(lián)系，如依賴、關聯(lián)、泛化、實現(xiàn)(Realization)等，它們的圖標如圖2．12所示。其中，依賴的圖標是一條虛箭線，從源模型元素指向目標模型元素，表示源模型元素依賴于目標模型元素。關聯(lián)的圖標是一條實線，連接兩個模型元素，在關聯(lián)端可標有多重性標記和關聯(lián)角色。泛化的圖標是一條帶空心三角箭頭的實箭線，從表示特殊性事物的模型元素指向表示一般性事物的模型元素。實現(xiàn)的圖標是一條帶空心三角箭頭的虛箭線，從源模型元素指向目標模型元素，表示源模型元素實現(xiàn)目標模型元素。UML定義的聯(lián)系還有聚合與組合。聚合與組合是兩種特殊的關聯(lián)，表示事物之問的部分與整體的關系。聚合與組合的圖標是在關聯(lián)線的一端分別加上一個空心或實心軟件工程（a）依賴（b）泛化（c）關聯(lián)（d）實現(xiàn)（e）聚合（f）組合圖2．12聯(lián)系的圖標示例的小菱形，小菱形端連接表示整體事物的模型元素，另一端連接表示部分事物的模型元素。

軟件工程UML定義的行為事物基本上分為兩大類：交互和狀態(tài)機。交互是這樣一種行為：在一個特定的上下文環(huán)境里，一組對象之間交換消息，完成某個指定的任務。交互所涉及的模型元素有對象、消息、動作序列、鏈接等。消息的圖標是一條帶實心三角箭頭的實箭線，從消息的發(fā)送對象指向消息的接受對象。消息的圖標如圖（a）所示。添加訂貨(a)消息

休閑(b)狀態(tài)制定計劃(c)活動圖2．13消息、狀態(tài)和活動的圖標示例狀態(tài)機是這樣一種行為：一個對象的狀態(tài)序列，或一個在整個對象的生存期中響應事件的交互。一個對象類軟件工程和多個對象類的協(xié)同可以用狀態(tài)機描述。狀態(tài)機所涉及的模型元素有狀態(tài)、轉移、事件、活動等。狀態(tài)的圖標是一個帶4個小圓角的矩形，含有狀態(tài)的名字。活動(動作狀態(tài))的圖標是一個由上下兩條平行線段、兩側圓弧構成的圖形，含有活動的名字。狀態(tài)與活動的圖標分別如圖

(b)和圖(c)所示。

UML定義的注解性的模型元素——注解(Comment)，是附加在其他模型元素上的一個文字串，用來對該模型元素做解釋。注解沒有強制性的語義，只是對模型元素作說明。注解常用注釋(Note)圖標表示。注釋圖標是一個右上角折角的矩形，內含注釋文字或約束表達式。注釋圖標也可以標有特定的構造型，如<<requirement>>、軟件工程<<constraint>>等，說明注釋的作用或類型。表達一個模型元素的注釋是把它的一個注釋圖標用一條虛線連接到該模型元素，如圖2．14所示。

安全當前值（）歷史值（）<<requirement>>遵照系統(tǒng)登錄事務的規(guī)定，滿足信息系統(tǒng)安全性要求圖2．14注釋示例用于表示模型元素之問相互連接的關系也是模型元素，如關聯(lián)(Association)、泛化(Generalization)、依賴(Dependency)、聚集(Aggregation)等。這些關系的含義如下：

(1)關聯(lián)：連接(Connect)模型元素及鏈接(Link)實例。

軟件工程(2)泛化：表示一般與特殊關系，即“一般”元素是“特殊”元素的泛化，“特殊”元素是“一般”元素的特化(Specialization)。

(3)依賴：表示一個元素以某種方式依賴于另一個元素。

(4)聚集：表示整體與部分的關系，即“部分”元素是“整體”元素的一部分。

UML中有9種圖(Diagram)和五種視圖。九種圖是：用例圖(Use—caseram)、類圖(Class)、對象圖(Object)、狀態(tài)圖(State)、時序圖(Sequence)、協(xié)作圖(Collaboration)、活動圖(Activity)、構件圖(Component)和部署圖(Deployment)。軟件工程UML可以從下列五種視圖來觀察系統(tǒng)，即用例視圖、邏輯視圖、構件視圖、并發(fā)視圖和部署視圖。二、使用UML的過程UML給出了面向對象建模的符號表示和規(guī)則，但并沒有描述如何工作，即沒有描述使用語言的過程或方法。實際上，UMI是為不同規(guī)模和目標的過程而設計的，盡管如此，要成功地使用UML仍需要一些過程。UML的設計者在設計UML時頭腦中是有一些過程的，使用UML。過程的基本特征是：用例驅動(Use-case-driven)、以體系結構為中心(Architecture-centric)、反復(Iterative)、漸增式(Incremental)。

軟件工程面向對象(OO)方法的主要步驟是需求分析、設計、實現(xiàn)和測試。UML的設計者將他們原先各自的面向對象開發(fā)過程進行合并，命名為RationalObjectoryProcess，其開發(fā)過程如圖所示。初始階段細化階段構造階段……細化階段圖2．15RationalObjectory開發(fā)過程1、初始階段

初始階段主要確定項目的范圍和目標，并進行可行性分析。

軟件工程2、細化階段

細化階段對開發(fā)項目的問題領域和功能做詳細分析，畫出用例圖，建立系統(tǒng)的基礎結構。

3、構造階段

通常具有高優(yōu)先級、高體系結構風險和高進度風險的用例應盡早實現(xiàn)，不要風險留到最后。4、移交階段

移交階段一般不再開發(fā)新的功能，該階段的工作主要有B測試、產品包裝、培訓等。

軟件工程2.5軟件需求分析建模與規(guī)格說明

2.5.1需求分析建模

目標軟件系統(tǒng)的模型用來刻劃系統(tǒng)所涉及的信息、處理功能及實際運行時的外部行為，但是，分析階段所建造的模型不應涉及軟件實現(xiàn)細節(jié)，因為這樣會分散分析人員的注意力，限制軟件設計人員為提高軟件的質量和效率而選擇實現(xiàn)方法的自由度。通常，分析人員選定一些圖形記號分別表示信息流、處理功能及系統(tǒng)行為．井利用受限的自然語言給出用戶需求的描述。此外，為了處理大型問題，模型的表示機制還應具備良好的結構化能力。建立軟件模型是分析活動的焦點。因為模型以一種簡潔、準確、結構清晰的方式系統(tǒng)地描述了軟件需求，從而使軟件工程于分析人員剔除用戶描述中的模糊性和不一致性，并使軟件需求臻于完全。分析過程實質上是軟件模型的建造和不斷完善的過程。在分析的初期，開發(fā)方和用戶方的聯(lián)合小組通過訪談、會議及實際觀察為構筑模型收集素材．同時也利用不太完整的初步模型作為小組內都相互溝通的需求表示機制、此后，分析人員不斷地對模型進行精確化、一致化、完全化方面的工作。最終確立的軟件模型既是生產需求規(guī)格說明的基礎，又是軟件設計和實現(xiàn)的基礎。軟件工程2.5.2規(guī)格說明及形式化說明技術

軟件需求規(guī)格說明書(SoltwareRequirementSpecificatiOns，SIRS)是需求分析階段的主要文檔，它以一致的，無二義性的方式完整、準確地表達目標系統(tǒng)應該實現(xiàn)的用戶需求。SRS既是軟件開發(fā)設計的依據，也是將來用戶測試驗收的依據。提交并且通過復審的SRS是需求分析結束的里程碑。SRS圍繞以下四個方面組織：(1)系統(tǒng)規(guī)格說明：目標系統(tǒng)的總體概貌；系統(tǒng)功能、性能要求；系統(tǒng)運行要求；將來可能的修改擴充要求。如果采用SA方法進行需求分析，則數據流圖是描述系統(tǒng)邏輯模型主要工具。(2)數據要求：建立數據詞典描繪系統(tǒng)數據要求，給出系統(tǒng)邏輯模型的準確、完整定義。軟件工程(3)用戶描述：從用戶使用角度對系統(tǒng)的描述，相當于初始的用戶手冊。內容包括系統(tǒng)功能、性能概述，預期的系統(tǒng)使用步驟與方法，用戶運行維護要求等。(4)修正的開發(fā)計劃：經過需求分析，對系統(tǒng)開發(fā)的成本估計，資源使用要求，項目進度計劃的可能修改。一份好的軟件需求規(guī)格說明應該具有唯一性、完整性、可驗證性、一致性、可跟蹤性、可修改性等特征。1．唯一性用戶的每一個要求／系統(tǒng)功能僅有一種解釋。自然語言的二義性可能導致對于系統(tǒng)功能、性能的不同理解。

2．完整性軟件工程需求分析的完整性包括：·系統(tǒng)包含全部重要的用戶需求(功能、性能、設計約束、外部接口)；·規(guī)定每種輸入數據的軟件響應(正確輸入的響應和不正確輸入的響應)；·全部術語、圖表完整，符合需求規(guī)范標準。3．可驗證性

SRS中每個功能、性能需求是可以驗證的。

4．一致性SRS陳述的各項功能、性能要求是相容的，沒有互相發(fā)生軟件工程矛盾或者沖突。5．可修改性SRS的組織結構使得當需求發(fā)生必須的變化時，對SRS的修改能夠保證完整、一致、容易地完成。在SRS中，如果存在一個有關SRS內容的列表、索引和交叉引用表，則當某個需求發(fā)生變化時，就可以方便對SRS中必須修改的部分進行定位和修改。6．可跟蹤性對于軟件開發(fā)中的每個需求在SRS中可以追溯出其來源。實現(xiàn)可跟蹤性的常用方法是對SRS中每個段落按層編號，每個需求給以唯一編碼，使用特殊指示字對同一需求在SRS中的不同出現(xiàn)進行標識。軟件工程2.6軟件需求正確性驗證

2.6.1軟件需求正確性要求和驗證方法

為了提高軟件質量，確保軟件開發(fā)成功，降低軟件開發(fā)成本，一旦對目標系統(tǒng)提出一組要求之后，必須嚴格驗證這些需求的正確性。一般說來，應該從下述四個方面進行驗證：一致性所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。完整性需求必須是完整的，規(guī)格說明書應該包括用戶需要的每一個功能或性能?，F(xiàn)實性指定的需求應該是用現(xiàn)有的硬件技術和軟件技術基本上可以實現(xiàn)的。對硬件技術的進步可以做些預測，軟件工程對軟件技術的進步則很難做出預測，只能從現(xiàn)有技術水平出發(fā)判斷需求的現(xiàn)實性。有效性必須證明需求是正確有效的，確實能解決用戶面對的問題。那么，怎樣驗證軟件需求的正確性呢?驗證的角度不同，驗證的方法也不同：1．驗證需求的一致性當需求分析的結果是用自然語言書寫的時候，除了靠人工技術審查驗證軟件系統(tǒng)規(guī)格說明書的正確性之外，目前還沒有其他更好的“測試”方法。但是，這種非形式化的規(guī)格說明書是難于驗證的，特別在目標系統(tǒng)規(guī)模龐大、規(guī)格軟件工程說明書篇幅很長的時候，人工審查的效果是沒有保證的，冗余、遺漏和不一致等問題可能沒被發(fā)現(xiàn)而繼續(xù)保留下來，以致軟件開發(fā)工作不能在正確的基礎上順利進行。為了克服上述困難，人們提出了形式化的描述軟件需求的方法。當軟件需求規(guī)格說明書是用形式化的需求陳述語言書寫的時候，可以用軟件工具驗證需求的一致性，從而能有效地保證軟件需求的一致性。2．驗證需求的現(xiàn)實性為了驗證需求的現(xiàn)實性，分析員應該參照以往開發(fā)類似系統(tǒng)的經驗，分析用現(xiàn)有的軟、硬件技術實現(xiàn)目標系統(tǒng)的可能性。必要的時候應該采用仿真或性能模擬技術，輔助分析軟件需求規(guī)格說明書的現(xiàn)實性。軟件工程3．驗證需求的完整性和有效性只有目標系統(tǒng)的用戶才真正知道軟件需求規(guī)格說明書是否完整、準確地描述了他們的需求。因此，檢驗需求的完整性，特別是證明系統(tǒng)確實滿足用戶的實際需要(即，需求的有效性)，只有在用戶的密切合作下才能完成。然而許多用戶并不能清楚地認識到他們的需要(特別在要開發(fā)的系統(tǒng)是全新的，以前沒有使用類似系統(tǒng)的經驗時，情況更是如此)，不能有效地比較陳述需求的語句和實際需要的功能。只有當他們有某種工作著的軟件系統(tǒng)可以實際使用和評價時，才能完整確切地提出他們的需要。

軟件工程2.6.2用于需求分析的軟件工具

為了更有效地保證軟件需求的正確性，特別是為了保證需求的一致性，需要有適當的軟件工具支持需求分析工作。這類軟件工具應該滿足下列要求：(1)必須有形式化的語法(或表)，因此可以用計算機自動處理使用這種語法說明的內容；(2)使用這個軟件工具能夠導出詳細的文檔；(3)必須提供分析(測試)規(guī)格說明書的不一致性和冗余性的手段，并且應該能夠產生一組報告指明對完整性分析的結果；(4)使用這個軟件工具之后，應該能夠改進通信狀況。作為需求工程方法學的一部分，在1977年設計完成了軟件工程RSL(需求陳述語言)。RSL中的語句是計算機可以處理的，處理以后把從這些語句中得到的信息集中存放在一個稱為抽象系統(tǒng)語義模型(ASSM)的數據庫中。有一組軟件工具處理ASSM數據庫中的信息以產生出用PASCAL語言書寫的模擬程序，從而可以檢驗需求的一致性、完整性和現(xiàn)實性。美國密執(zhí)安大學開發(fā)了PSL／PSA(問題陳述語言／問題陳述分析程序)系統(tǒng)。這個系統(tǒng)是“計算機輔助設計和規(guī)格說明分析工具(CADSAT)”的一部分，它的基本結構類似于RSL。其中PSL是用來描述系統(tǒng)的形式語言，PSA是處理PSL描述的分析程序。用PSL描述的系統(tǒng)屬性放在一個數據庫中。一旦建立起數據庫之后即可增加信息、刪除信息或修改信息，并且保持信息的一致性。PSA對數據庫軟件工程進行處理以產生各種報告，測試不一致性或遺漏，并且生成文檔資料。PSL／PSA系統(tǒng)的功能主要有下述四種：(1)描述任何應用領域的信息系統(tǒng)；(2)創(chuàng)建一個數據庫保存對該信息系統(tǒng)的描述符；(3)對描述符施加增加、刪除和更改等操作；(4)產生格式化的文檔和關于規(guī)格說明書的各種分析報告。PSL／PSA系統(tǒng)用描述符從系統(tǒng)信息流、系統(tǒng)結構、數據結構、數據導出、系統(tǒng)規(guī)模、系統(tǒng)動態(tài)、系統(tǒng)性質和軟件工程項目管理等八個方面描述信息系統(tǒng)。一旦用PSI一對系統(tǒng)做了完整描述，就可以調用PSA產生一組分析報告，其中包括所有修改規(guī)格說明數據庫的記錄，用各種形式描述數據庫信息的參照報告(包括圖形形式的描述)，關于項目管理信息的總結報告，以及評價數據庫特性的分析報告。借助PSL／PSA系統(tǒng)可以邊對目標系統(tǒng)進行自頂向下的逐層分解，邊將需求分析過程中遇到的數據流、文件、處理等對象用PSI。描述出來并輸入到PSL／PSA系統(tǒng)中。PSA將對輸入信息作一致性和完整性檢查，并且保存這些描述信息。軟件工程2.7需求分析指南

按照軟件工程對軟件開發(fā)過程的描述，需求階段我們可以細分為需求調研和需求分析兩個小階段，需求調研需要充分細致的了解客戶目標，用戶業(yè)務內容、流程等，這是一個對需求的采集過程，是進行需求分析的基礎準備。當我們已經了解、理解了用戶的業(yè)務，于是可以開始分析需求了。軟件系統(tǒng)的需求分析可以由產品工程師或系統(tǒng)分析員或兩者分階段合作完成全部的需求分析工作。一、

提取出核心、主要、急迫的業(yè)務，明晰業(yè)務流程二、

運用管理思想，優(yōu)化業(yè)務流程

軟件工程本章小結

需求分析是在可行性研究的基礎上進行的，可行性研究實質上是一次完整的分析和設計過程，只不過是在抽象的層次上進行的大大壓縮和簡化了的分析和設計過程。因此在可行性研究階段已經進行了某些初步的分析，特別是已經得出了高層次的數據流圖。但是，需求分析的主要任務是得出詳細的系統(tǒng)邏輯模型。通常需求分析工作從可行性研究得出的數據流圖出發(fā)，首先確定構成輸出數據的各個數據元素，沿數據流圖回溯尋求每個數據元素的源，在此過程中確定必要的處理算法并補充必要的數據元素，同時也會產生一些新的問題。在尋求這些問題的答案時，將澄清一些算法并劃分出更多的數據元素，可能也會再遇到一些問題。對這些問題的解答又將導致對系統(tǒng)的更深入更具體的認識。在對系統(tǒng)的主要軟件工程處理算法有充分了解之后，應該把數據流圖進一步分層細化。通過需求分析應該得出用數據流圖、ER圖、數據字典和IPO圖(或PDL等其他描述算法的工具)描繪的精確的系統(tǒng)邏輯模型。為了提高文檔的可理解性，還可以用層次方框圖或Warnier圖等圖形工具輔助描繪系統(tǒng)中的數據結構。為了減少冗余、簡化修改步驟，往往需要規(guī)范數據的存儲結構。需求分析的結果是軟件開發(fā)的基礎，必須仔細驗證它的正確性，開發(fā)人員必須和用戶取得完全一致的意見，需求分析的文檔應該被用戶所確認。軟件工程第6章項目管理

本章要點：軟件項目管理概念項目管理組織及過程

軟件質量及保證CMM模型軟件工程本章學習目標：了解項目管理過程

理解項目的估算方法了解CMM模型的層次結構

軟件工程6.1項目管理概述

項目管理就是為了滿足甚至超越項目涉及人員對項目的需求和期望而將理論知識、技能、工具和技巧應用到項目的活動中去。

需要在下面這些相互間有沖突的要求中尋求平衡：

范圍、時間、成本和質量

有不同需求和期望的項目涉及人員

明確表示出來的要求（需求）和未明確表達的要求在軟件行業(yè)，對項目實施有效的管理是軟件成敗的關鍵。軟件工程項目管理的過程

軟件項目啟動度量

估算

風險分析

進程安排

追蹤和控制

軟件工程6.2項目計劃

計劃是管理工作的重要職能，在軟件項目管理中，軟件項目從制定項目計劃開始。項目計劃中需要確定以下幾項內容：

目標：定義了待完成的目標，迫切需要的資源，約束和優(yōu)先級。范圍：定義待開發(fā)系統(tǒng)的邊界，什么包括在系統(tǒng)里，什么不包括在系統(tǒng)里。產品技術說明：說明軟硬件信息以及有關功能、性能、安全性等方面的約束。時間：進度表。資金：預算。地點：工作空間分配。人員：參與人員以及項目組織。軟件工程6.3進度安排

軟件開發(fā)項目的進展安排有兩種考慮方式：

系統(tǒng)最終交付日期已經確定，軟件開發(fā)部門必須在規(guī)定期限內完成任務。系統(tǒng)最終交付日期只確定了大致的年限，最后交付日期由軟件開發(fā)部門確定

進度安排是基于對項目的需求分析和評審軟件工程項目的并行性提出一系列進度要求。因為并行任務是同時發(fā)生的，以進度計劃決定任務之間的從屬關系，確定各個任務的先后次序和銜接，以及各個任務完成的持續(xù)時間。

軟件工程6.4項目估算對軟件項目進行有效的估算，取決于掌握多少有關項目范圍的原始資料。估算的兩個主要方法是：第一種方法是根據項目特征和算法進行估算。第二種方法是采用類比的方法，根據歷史數據來進行估算。

軟件工程項目規(guī)模估算量軟件項目規(guī)模最常用的概念--LOC

L指所有的可執(zhí)行的源代碼行數，包括可交付的工作控制語言（JCL：JobControlLanguage）語句、數據定義、數據類型聲明、等價聲明、輸入/輸出格式聲明等。

規(guī)模估算的三種方法方法一、Delphi法

方法二、類比法方法三、功能點估計法

軟件工程軟件開發(fā)成本估算軟件開發(fā)成本主要是指軟件開發(fā)過程中所花費的工作量及相應的代價。軟件開發(fā)成本的估算，應是從軟件計劃、需求分析、設計、編碼、單元測試、組裝測試到確認測試，整個軟件開發(fā)過程所花費的代價作為依據的。

對于一個大型的軟件項目，要進行一系列的估算處理，主要靠分解和類推的方法進行。基本估算方法分為3類：

自頂向下的估算方法自底向上的估算法差別估計法軟件工程6.5項目組織組織原則

（1）

早落實原則

（2）

減少接口

（3）

責權均衡

2人員配備

軟件工程6.6軟件質量按照ANSI/IEEE1983年的標準，軟件質量定義為“與軟件產品滿足需求所規(guī)定的和隱含的能力有關的特征和特性的全體?！避浖a品中所能滿足用戶給定的全部特性的集合軟件具有所期望的各種屬性組合的程度用戶主觀得出的軟件是否滿足其綜合期望的程度決定所用軟件在使用中將滿足其綜合期望程度的軟件合成特性軟件工程質量保證的主要內容軟件工程質量保證應用于整個軟件過程的保護活動，包括：（1）

質量管理方法（2）

有效的軟件工程技術（方法和工具）。（3）

應用于整個軟件過程的形式化技術評論。（4）

多等級測試策略。（5）

軟件文檔以及對軟件進行改變和維護的控制和約束（6）

確保遵照軟件開發(fā)標準的過程。（7）

測量和報告機制。軟件工程軟件工程標準化軟件工作的范圍從只是使用程序設計語言編寫程序，擴展到

整個軟件生存期。所有這些方面都應逐步

建立起標準或規(guī)范來。

軟件工程標準的類型也是多方面的。它可能包括過程標準(如方法、技術、度量等)、產品標準(如需求、設計、部件、描述、計劃、報告等)、專業(yè)標準(如職別、道德準則、認證、特許、課程等)以及記法標準(如術語、表示法、語言等)。

軟件工程軟件工程標準的制定與推行通常要經歷一個環(huán)狀的生命期(參看圖6．2)。最初，制定一項標準僅僅是初步設想，經發(fā)起后沿著環(huán)狀生命期，順時針進行要經歷以下的步驟：軟件工程CMM模型

CMM(CapabilityMaturityModel)即能力成熟度模型，定義了當一個組織達到不同的過程時應該具有的軟件工程能力。它描述了軟件過程從無序到有序、從特殊到一般、從定性管理到定量管理、最終到達可動態(tài)優(yōu)化的成熟過程。給出了該過程中5個成熟階段的基本特性和應遵循的原則、采取的行動，以幫助軟件組織改進其軟件過程。

CMM的基前提是：軟件質量在很大程度上取決于開發(fā)軟件的軟件過程的質量和能力；軟件過程是一個可管理、可度并不斷改進的過程；軟件過程的質量受到用以支撐它的技術和設施的影響；軟件開發(fā)組織在軟件過程中所采用的技術層次應適應于軟件過程的成熟度。軟件工程CMM模型

將CMM組織成下圖所示的5個等級，其意在于增加軟件過程成熟的改進行動按優(yōu)先級排序。圖中帶有標記的箭頭，指示在成熟度框架的每一步驟上，組織應予以規(guī)范化的過程能力的類型。

[5]優(yōu)化級[4]已管理級[2]可重復級[3]已定義級[1]初始級軟件工程6.7軟件配置管理系統(tǒng)配置指的是交付給特定客戶的一個系統(tǒng)構件的集合

軟件配置管理是監(jiān)督和控制工作產品中變化的過程。變化遍及整個軟件開發(fā)過程。

軟件配置管理是軟件系統(tǒng)發(fā)展過程中管理和控制變化的規(guī)范[IEEEStD.1042-1987]。配置管理系統(tǒng)使得版本的識別、存儲和檢索以及支持狀態(tài)記錄自動完成。配置管理包括下列活動：配置項的確定變化控制狀態(tài)記錄審核軟件工程配置管理的過程軟件配置管理的方法大致分三類：單獨文件、增量和條件編譯。以上三種