軟件工程導論課件

軟件工程導論

1.1.1軟件的定義

軟件的經(jīng)典定義： 軟件=“完成特定功能的程序+數(shù)據(jù)結構+文檔”軟件的特征：

1、軟件是開發(fā)的，而不是制造的；

2、軟件不磨損，但退化；

3、自定義。1.1.1軟件的定義

軟件發(fā)展中的相關問題：

硬件的發(fā)展超過軟件；

現(xiàn)有軟件與用戶的要求矛盾；

軟件失敗導致“災難性后果”；

需要高質(zhì)量、高可靠性的軟件；

設計的問題使升級和維護十分困難。1.1.1軟件危機的定義

定義

“在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重的問題。”1.1.2軟件危機的表現(xiàn)（1）對軟件開發(fā)成本和進度的估計常常很不準確。

實際成本往往大大超過估計成本，或開發(fā)進度比計劃推遲幾個月或一年以上。這種現(xiàn)象極大地影響了軟件開發(fā)組織的信譽，也會引起用戶的強烈不滿。（2）軟件產(chǎn)品質(zhì)量較差，可靠性低。

軟件開發(fā)過程中不能堅持嚴格的審查、復審和測試，使得軟件可靠性差、質(zhì)量問題多。

1.1.2軟件危機的表現(xiàn)（3）用戶對開發(fā)出來的軟件產(chǎn)品不滿意。開發(fā)人員與用戶之間的交流不充分，僅對用戶需求有了一個模糊的認識就匆忙開始寫程序。這樣的結果就是用戶對于所謂已經(jīng)完成的軟件很不滿意。（4）軟件常常是不可維護的。在實際項目中，很多程序的錯誤往往難以修改，而且不能適應軟硬件環(huán)境的變化，也無法添加用戶需要的一些新功能。1.1.2軟件危機的表現(xiàn)（5）軟件產(chǎn)品缺少應有的文檔資料。軟件=程序+數(shù)據(jù)+文檔。開發(fā)人員對文檔認識不足，不能保證在開發(fā)過程中文檔的完整性和準確性。缺少文檔資料會造成軟件開發(fā)、管理、審查、用戶交流、軟件維護等方面的諸多問題。（6）軟件產(chǎn)品的供不應求。軟件開發(fā)的生產(chǎn)率遠遠低于計算機硬件發(fā)展速度和用戶的需求，造成了軟件產(chǎn)品的供不應求。1.1.3產(chǎn)生軟件危機的原因客觀原因：軟件與硬件產(chǎn)品不同，軟件是“開發(fā)的”而非“制造的”。其開發(fā)過程難以管理和控制，產(chǎn)品質(zhì)量也不好把握。軟件沒有“磨損”，但是它會不斷“退化”。軟件系統(tǒng)無法適應不斷變化的環(huán)境和功能需求。軟件都規(guī)模龐大，而程序的復雜性是隨其規(guī)模的擴大呈指數(shù)增加。主觀原因：對用戶要求沒有完整和準確的認識就匆忙編寫程序。對軟件的開發(fā)過程的認識不準確。生命周期的每個階段都有特定的工作和特點，都是不可逾越的。只有上一階段工作完成，才能開始下一階段的工作。對軟件質(zhì)量的重視不夠是造成軟件開發(fā)成本激增的主要原因。注意軟件開發(fā)過程中錯誤的“放大效應”。輕視軟件維護將是一個重大的錯誤。軟件開發(fā)時期各階段的關鍵目標都是提高軟件的可維護性。1.1.3產(chǎn)生軟件危機的原因第1章軟件工程學概述

1.1軟件危機

1.2軟件工程

1.3軟件生命周期

1.4軟件過程1.2軟件工程為了更有效地開發(fā)與維護軟件，軟件工作者在20世紀60年代后期開始認真研究消除軟件危機的途徑，從而逐漸形成了一門新興的工程學科——計算機軟件工程學(簡稱為軟件工程)。

1.2.1軟件工程的概念

定義指導軟件開發(fā)與維護的工程科學采用工程的概念、原理、技術和方法來開發(fā)和維護軟件，綜合運用正確的管理技術和最好的技術方法，以經(jīng)濟地開發(fā)出高質(zhì)量的軟件并有效維護它。

1.2.1軟件工程的概念

IEEE的定義

①軟件工程是把系統(tǒng)的、規(guī)范的、可度量的途徑應用于軟件開發(fā)、運行和維護過程，也就是把工程應用于軟件；②對這些途徑加以研究。

1.2.1軟件工程的概念諸多軟件工程的定義所揭示的軟件工程的本質(zhì)認識是一致的：軟件工程一般更關注于大型軟件系統(tǒng)的開發(fā)；其中心任務是控制整個軟件系統(tǒng)的復雜性，提高軟件開發(fā)的效率，加強人員和技術的管理，更好地滿足用戶的需要。1.2.2軟件工程的基本原理（1）用分階段的生命周期計劃嚴格管理應該將軟件開發(fā)和維護的漫長生命周期劃分成若干個階段，并針對每個階段制定切實可行的計劃，然后嚴格按照計劃對軟件的開發(fā)和維護工作進行管理。（2）堅持進行階段評審錯誤發(fā)現(xiàn)的越早，改正錯誤所付出的代價就越小。因此，開發(fā)人員應該堅持在每個階段都進行嚴格的評審，以便更早地發(fā)現(xiàn)和改正錯誤。1.2.2軟件工程的基本原理（3）實行嚴格的產(chǎn)品控制在軟件開發(fā)的過程中不應隨意修改需求，當改變需求時，必須實行嚴格的產(chǎn)品控制以保持軟件各個配置成分的一致性。（4）采用現(xiàn)代程序設計技術

采用先進的技術不僅可以提高軟件開發(fā)和維護的效率，而且還能有效地提高軟件產(chǎn)品的質(zhì)量。

1.2.2軟件工程的基本原理（5）結果可以清楚地審查

應規(guī)定每個開發(fā)階段的產(chǎn)品標準和文檔要求，使得到的結果可以清楚地審查。

（6）開發(fā)小組成員少而精軟件開發(fā)小組人員要求素質(zhì)高，而人數(shù)不宜過多。隨著人數(shù)n的增加，通信路徑也急劇增加。1.2.2軟件工程的基本原理（7）承認不斷改進軟件工程實踐的必要性軟件開發(fā)和維護的過程也需要隨之改進。要主動采用最新的軟件技術，而且還要不斷總結經(jīng)驗和教訓、收集歷史數(shù)據(jù)幫助開發(fā)人員改進軟件工程實踐。1.2.3軟件工程方法學軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學。

軟件工程方法學主要包含3個要素：方法、工具和過程。

目前使用最為廣泛的軟件工程方法學是傳統(tǒng)方法學和面向?qū)ο蠓椒▽W。1.2.3軟件工程方法學1.傳統(tǒng)方法學-也稱為生命周期方法學或結構化范型。

-它采用結構化技術（包括結構化分析、結構化設計和結構化實現(xiàn)）來完成軟件開發(fā)的各項任務。

-這種方法學將軟件生命周期劃分為若干個階段，然后順序完成各個階段的任務。每個階段依賴上一個階段產(chǎn)生的結果，并將上一階段工作進一步具體化。1.2.3軟件工程方法學2.面向?qū)ο蠓椒▽W-以數(shù)據(jù)為主線，將數(shù)據(jù)和其上的操作緊密結合起來。面向?qū)ο蠓椒▽W的四要素：類+對象+繼承+消息傳遞。

-面向?qū)ο蟮姆椒▽W是盡量模擬人類習慣的思維方式，使軟件開發(fā)過程更接近人類認知模式，做到問題空間與解空間在結構上一致。-運用面向?qū)ο蠓椒▽W開發(fā)出來的軟件產(chǎn)品一般是由很多較小的獨立對象組成，從而降低了軟件產(chǎn)品的復雜性，增強了可理解性，使得開發(fā)和維護更為簡單有效。第1章軟件工程學概述

1.1軟件危機

1.2軟件工程

1.3軟件生命周期1.3.1軟件生命周期的概念

定義

一個軟件從定義、開發(fā)、使用和維護，直至最終被廢棄，要經(jīng)歷的漫長的時期稱為軟件生命周期。1.3.1軟件生命周期的概念

構成3個時期：軟件定義、軟件開發(fā)和運行維護各時期任務：

軟件定義時期：確定軟件開發(fā)的總目標和工程的可行性；導出實現(xiàn)策略和系統(tǒng)必須完成的功能；進行成本效益的估算；制定開發(fā)計劃等。

軟件開發(fā)時期：具體設計和實現(xiàn)前一個時期定義的軟件。

維護時期：使軟件持久地滿足用戶的需要。1.3.1軟件生命周期的概念

構成3個時期：軟件定義、軟件開發(fā)和運行維護8個階段：

問題定義

可行性研究

需求分析

總體設計詳細設計

編碼和單元測試

綜合測試軟件維護階段1:問題定義“需要解決的問題是什么？”

確定問題的性質(zhì)

軟件目標和規(guī)模

形成書面報告。

1.3.2各階段的基本任務階段2:可行性研究“確定軟件系統(tǒng)是否值得去解”

高層次的系統(tǒng)分析和設計

估算系統(tǒng)的成本和效益

《可行性研究報告》1.3.2各階段的基本任務階段3:需求分析“解決這些問題需要系統(tǒng)做什么？”

與用戶的交流

生成系統(tǒng)的邏輯模型

《軟件需求規(guī)格說明書》1.3.2各階段的基本任務階段4:總體設計（概要設計）“應該怎樣實現(xiàn)目標系統(tǒng)？”

設計出實現(xiàn)目標系統(tǒng)的方案

設計軟件結構，確定模塊及之間關系

概要設計說明書1.3.2各階段的基本任務階段5:詳細設計（模塊設計）

“如何具體地實現(xiàn)這個系統(tǒng)？”

詳細的設計每個模塊的算法和數(shù)據(jù)結構

1.3.2各階段的基本任務階段6:編碼和單元測試“寫代碼，測試每個模塊！”

選取程序設計語言

寫出容易理解和維護的程序模塊

對每一個模塊進行嚴格的測試1.3.2各階段的基本任務階段7:綜合測試“通過各類測試和調(diào)試來完善軟件”

集成測試+驗收測試(用戶參加)

保存測試計劃、測試方案和測試結果1.3.2各階段的基本任務階段8:軟件維護“通過各種必須的維護活動使系統(tǒng)持久地滿足用戶的需要！”

改正性維護

適應性維護

完善性維護

預防性維護1.3.2各階段的基本任務1.3.3軟件生命周期的模型

定義在軟件開發(fā)過程中，人們通常使用生命周期模型來簡要地描述軟件過程。生命周期模型規(guī)定了生命周期各個階段和它們執(zhí)行的順序，因此也被稱為過程模型。1.瀑布模型—線性模型之一

在20世紀80年代之前，瀑布模型一直是惟一被廣泛采用的生命周期模型。傳統(tǒng)軟件工程方法學的軟件過程，基本上可以用瀑布模型來描述。

瀑布模型1.瀑布模型—線性模型之一瀑布模型的特點：

（1）各階段之間有依賴性和嚴格的順序性。

（2）推遲實現(xiàn)。

——典型特點（3）嚴格的階段質(zhì)保。（4）文檔驅(qū)動。

瀑布模型的問題：（1）實際的項目很少順序嚴格（2）用戶往往難以給出具體、正確、完整的要求（3）開發(fā)人員“阻塞狀態(tài)”嚴重1.瀑布模型—線性模型之一

2.原型模型原型模型是一個快速開發(fā)的過程，首先和用戶溝通進行主要功能的需求分析和快速設計，然后建立一個原型，再請用戶進行評價和反饋。開發(fā)人員根據(jù)用戶的反饋進一步細化需求，改進原型系統(tǒng)的設計，如此反復直至用戶滿意?？焖傩枨蠓治觯ㄓ脩魷贤ǎ嫿?修改模型（快速設計）用戶使用評價（運行測試）原型模型2.原型模型快速原型模型的特點：

(1)出品速度快。

(2)逐步求精。

(3)開發(fā)階段迭代?？焖僭湍Ｐ偷膯栴}： (1)實現(xiàn)過程中不應有的折衷方案。

(2)開發(fā)者急于完成原型而忽略了整體設計和可維護性；

(3)用戶的參與過多也造成了軟件開發(fā)管理的混亂。

2.原型模型增量模型也稱為漸增模型。使用增量模型開發(fā)軟件時，把軟件產(chǎn)品作為一系列的增量構件來設計、編碼、集成和測試。分析設計編碼測試交付增量1分析設計編碼測試交付增量2……項目時間分析設計編碼測試交付增量n增量模型3.增量模型軟件系統(tǒng)3.增量模型增量模型增量模型的特點：

(1)結合了線性模型和原型模型的特點；

(2)每個增量可以結合原型法；

(3)系統(tǒng)的問世提前→“增量1”增量模型的問題：開放的軟件體系結構

中心思想：“漸進開發(fā)，逐步完善”3.增量模型-使用增量模型開發(fā)時，第一個增量往往是系統(tǒng)中的核心構件，同時，要求產(chǎn)品分解成增量構件的規(guī)模應當適中。

-如何不破壞已經(jīng)開發(fā)的構件將新的構件集成到一個產(chǎn)品中是增量模型的一個難點。-增量模型的提出很好地解決了線性模型中的人員阻塞問題，尤其是在項目開始初期開發(fā)人員不足的時候，能有效地規(guī)避技術風險。3.增量模型噴泉模型是典型的面向?qū)ο蟮能浖^程模型之一，“噴泉”較好地體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性。4.噴泉模型4.噴泉模型（1）假設要求你開發(fā)一個軟件，該軟件的功能是把讀入的浮點數(shù)開平方，所得到的結果應該精確到小數(shù)點后4位。一旦實現(xiàn)并測試完之后，該產(chǎn)品將被拋棄。你打算選用哪種軟件生命周期模型？請說明你做出選擇的理由。問題討論——情景分析解：對這個軟件的需求很明確，實現(xiàn)開平方功能的算法也很成熟，因此，既無須通過原型來分析需求也無須用原型來驗證設計方案。此外，一旦實現(xiàn)并測試完之后，該產(chǎn)品將被拋棄，因此也無須使用有助于提高軟件可維護性的增量模型或螺旋模型來開發(fā)該軟件。問題討論——情景分析（2）假設你被任命為一家軟件公司的項目負責人，你的工作是管理該公司已被廣泛應用的字處理軟件的新版本開發(fā)。由于市場競爭激烈，公司規(guī)定了嚴格的完成期限并且已對外公布。你打算采用哪種軟件生命周期模型？為什么？問題討論——情景分析2.1可行性研究的任務目標：“用最小的代價和盡可能短的時間判斷問題是否值得去解？”實質(zhì)：高層次的系統(tǒng)分析和設計主要任務：（1）分析和澄清問題定義；（2）導出系統(tǒng)的邏輯模型；（3）探索各種解法并研究每種解法的可行性；（4）制定粗略的進度、建議和計劃。2.1可行性研究的任務（1）技術可行性對要開發(fā)項目的功能、性能和限制條件進行分析，確定在現(xiàn)有的資源條件下，技術風險有多大，項目能否實現(xiàn)。–技術：相關技術的發(fā)展可否支持這個軟件系統(tǒng)。–資源的有效性：開發(fā)人員及用于建立系統(tǒng)的其它資源是否具備。–開發(fā)的風險：在給出的限制范圍內(nèi)，能否設計出軟件系統(tǒng)并實現(xiàn)必須的功能和性能。2.1可行性研究的任務（2）經(jīng)濟可行性經(jīng)濟可行性研究的內(nèi)容是進行開發(fā)成本的估算以及進行效益的評估確定要開發(fā)的項目是否值得投資開發(fā)。–成本/效益分析–長期的公司經(jīng)營策略–對其他的單位或產(chǎn)品的影響–潛在的市場前景等2.1可行性研究的任務（3）操作可行性在這個應用范圍內(nèi)，系統(tǒng)的操作方式（批處理/聯(lián)機處理）是否行得通。

2.1可行性研究的任務（4）社會可行性社會可行性主要研究開發(fā)的項目是否存在任何侵犯、妨礙等責任問題，要開發(fā)項目的運行方式在用戶組織內(nèi)是否行得通，現(xiàn)有管理制度、人員素質(zhì)和操作方式是否可行。–合同、責任、侵權–用戶組織的管理模式及規(guī)范和其他一些技術人員常常不了解的陷阱等

第2章可行性研究

2.1可行性研究的目標與任務

2.2可行性研究過程

2.3可行性研究工具

2.4成本/效益分析2.2可行性研究過程（1）復查系統(tǒng)規(guī)模與目標

(1)訪問關鍵人員，復查確認系統(tǒng)規(guī)模和目標

(2)清晰描述對目標系統(tǒng)的一切限制和約束（2）研究目前正在使用的系統(tǒng)

(1)了解現(xiàn)有系統(tǒng)，實地考察

(2)注意現(xiàn)有系統(tǒng)與目標系統(tǒng)之間的接口(功能)

(3)運行費用

Note：重在分析現(xiàn)有系統(tǒng)可以做什么，不要陷入細節(jié)！2.2可行性研究過程（3）導出新系統(tǒng)的高層邏輯模型

從現(xiàn)有的物理系統(tǒng)出發(fā)導出目標系統(tǒng)的邏輯模型（4）導出與評價各種方案

邏輯模型

——〉物理解法(1)評估解決方案的可行性(2)給出實現(xiàn)進度表（5）推薦行動方針

作為結果之一

是否繼續(xù)開發(fā)？

對于推薦的系統(tǒng)

詳細的成本/效益分析2.2可行性研究過程（6）草擬開發(fā)計劃

工程進度表

開發(fā)人員需求

設備與軟件的需求（使用情況說明）

估計軟件生命周期每個階段的成本

給出下一個階段的進度表/成本估計（7）書寫文檔提交審查——《可行性研究報告》2.2可行性研究過程第2章可行性研究

2.1可行性研究的目標與任務

2.2可行性研究過程

2.3可行性研究工具

2.4成本/效益分析

系統(tǒng)流程圖

——用來描述物理系統(tǒng)概貌

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

——用來描述系統(tǒng)邏輯功能

2.3可行性研究工具

系統(tǒng)流程圖

基本思想:用圖形符號以黑盒子形式描繪組成系統(tǒng)的每個部件（程序、文檔、數(shù)據(jù)庫、人工過程）。

注：系統(tǒng)流程圖表達的是數(shù)據(jù)在系統(tǒng)各部件之間流動的情況，而不是對數(shù)據(jù)進行加工處理的控制過程(程序流程圖)。2.3可行性研究工具基本符號表（概括描述系統(tǒng)）2.3可行性研究工具系統(tǒng)符號表（具體描述系統(tǒng)）某裝配廠有一座存放零件的倉庫，倉庫中現(xiàn)有的各種零件的數(shù)量以及每種零件的庫存量臨界值等數(shù)據(jù)記錄在庫存清單主文件中。當倉庫中零件數(shù)量有變化時，應該及時修改庫存清單主文件，如果哪種零件的庫存量少于它的庫存量臨界值，則應該報告給采購部門以便定貨，規(guī)定每天向采購部門送一次定貨報告。該裝配廠使用一臺小型計算機處理更新庫存清單主文件和產(chǎn)生定貨報告的任務。零件庫存量的每一次變化稱為一個事務，由放在倉庫中的CRT終端輸入到計算機中；系統(tǒng)中的庫存清單程序?qū)κ聞者M行處理，更新存儲在磁盤上的庫存清單主文件，并且把必要的訂貨信息寫在磁帶上，并且打印出定貨報告。2.3可行性研究工具注：自頂向下從左到右?guī)齑媲鍐蜗到y(tǒng)的高層系統(tǒng)流程圖2.3可行性研究工具數(shù)據(jù)流程圖

數(shù)據(jù)流圖(DFD)是一種圖形化技術，它描繪信息流和數(shù)據(jù)從輸入移動到輸出的過程中所經(jīng)受的變換，即數(shù)據(jù)流圖描繪數(shù)據(jù)在軟件中流動和被處理的邏輯過程。2.3可行性研究工具2.3可行性研究工具任何系統(tǒng)的基本模型都由若干個數(shù)據(jù)源點/終點以及一個處理組成，這個處理就代表了系統(tǒng)對數(shù)據(jù)加工變換的基本功能。1.數(shù)據(jù)流圖的基本圖形符號2.3可行性研究工具源點/終點：表示圖中要處理數(shù)據(jù)的輸入來源或處理結果要送往何處。它是數(shù)據(jù)流圖的外圍環(huán)境中的實體。加工/變換：使用橢圓或圓角矩形表示。它是以數(shù)據(jù)結構或數(shù)據(jù)內(nèi)容作為加工對象的，是對數(shù)據(jù)進行處理的單元，是對數(shù)據(jù)流進行某些操作或變換。數(shù)據(jù)流：沿箭頭方向傳送數(shù)據(jù)，指明被加工的數(shù)據(jù)與流向。數(shù)據(jù)存儲：和數(shù)據(jù)流一樣都是數(shù)據(jù)，僅僅所處的狀態(tài)不同。數(shù)據(jù)存儲是處于靜止狀態(tài)的數(shù)據(jù)，數(shù)據(jù)流是處于運動中的數(shù)據(jù)。附加符號及含義2.3可行性研究工具2.3可行性研究工具2.數(shù)據(jù)流圖元素命名原則（1）數(shù)據(jù)流（數(shù)據(jù)存儲）的命名-應代表整個數(shù)據(jù)流（數(shù)據(jù)存儲）的內(nèi)容。-不使用空洞、缺乏具體含義的名字（如數(shù)據(jù)、信息等）。-數(shù)據(jù)流圖分解得當可以有效地為數(shù)據(jù)流命名。（2）數(shù)據(jù)加工的命名-與數(shù)據(jù)流命名相關聯(lián)。-應反映整個處理的功能。-及物動詞+賓語。-處理分解要得當。（3）為數(shù)據(jù)源點/終點命名

數(shù)據(jù)源點/終點屬于目標系統(tǒng)的外圍環(huán)境部分。通常在命名時采用它們在問題域中習慣使用的名字。2.3可行性研究工具3.數(shù)據(jù)流圖的層次結構

為了表達數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，對于復雜的實際問題，需要采用層次結構的數(shù)據(jù)流圖。按照系統(tǒng)的層次結構進行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結構關系，能清楚地表達整個系統(tǒng)。任何一層數(shù)據(jù)流圖的上層圖為父圖，下一層的圖為子圖。2.3可行性研究工具分層的數(shù)據(jù)流圖2.3可行性研究工具

在多層數(shù)據(jù)流圖中，頂層流圖僅包含一個加工，它代表被開發(fā)系統(tǒng)。它的輸入流是該系統(tǒng)的輸入數(shù)據(jù)，輸出流是系統(tǒng)所輸出的數(shù)據(jù)；

底層流圖是指其加工不需再做分解的數(shù)據(jù)流圖，它處在最底層；

中間層流圖則表示對其上層父圖的細化。它的每一個加工可能繼續(xù)細化，形成子圖。2.3可行性研究工具4.畫數(shù)據(jù)流圖的基本步驟自頂向下，逐層細化

（1）先找外部實體（可以是人、物或其他軟件系統(tǒng)），找到了外部實體，則系統(tǒng)與外部世界的界面就得以確定，系統(tǒng)的源點和終點也就確定了；

（2）找出外部實體的輸入和輸出數(shù)據(jù)流；

（3）在圖的邊上畫出系統(tǒng)的外部實體；2.3可行性研究工具4.畫數(shù)據(jù)流圖的基本步驟

（4）從外部實體的輸出流（源點）出發(fā)，按照系統(tǒng)的邏輯需要，逐步畫出一系列變換數(shù)據(jù)的加工，直到找到外部實體處所需的輸入流（終點），形成數(shù)據(jù)流的封閉；

（5）對初步畫出的數(shù)據(jù)流圖進行檢查和修改。

（6）最后按照上述步驟畫出所有子圖。2.3可行性研究工具（1）數(shù)據(jù)流圖所有圖形符號只限于前述四種基本圖形元素；（2）頂層數(shù)據(jù)流圖中的數(shù)據(jù)流必須封閉在外部實體之間；（3）每個加工至少有一個輸入數(shù)據(jù)流和一個輸出數(shù)據(jù)流；（4）在數(shù)據(jù)流圖中，需按層給加工框編號。編號表明該加工所處層次及上下層的親子關系；5.檢查和修改數(shù)據(jù)流圖的原則2.3可行性研究工具（5）規(guī)定任何一個數(shù)據(jù)流子圖必須與它上一層的一個加工對應，兩者的輸入數(shù)據(jù)流和輸出數(shù)據(jù)流必須一致。這被稱為是父圖與子圖的平衡；（6）圖上每個元素都必須有名字；（7）數(shù)據(jù)流圖中不可夾帶控制流；（8）初畫時可以忽略瑣碎的細節(jié)，以集中精力于主要數(shù)據(jù)流。5.檢查和修改數(shù)據(jù)流圖的原則2.3可行性研究工具假設一家工廠的采購部每天需要一張定貨報表，報表按零件編號排序，表中列出所有需要再次定貨的零件。對于每個需要再次定貨的零件應該列出下述數(shù)據(jù)：零件編號、零件名稱、訂貨數(shù)量、價格、主要供應者、次要供應者。零件入庫或出庫稱為事務，通過放在倉庫中的CRT終端把事務報告給定貨系統(tǒng)。當某種零件的庫存數(shù)量少于庫存量臨界值時就應該再次定貨。源點/終點：數(shù)據(jù)流：處理：數(shù)據(jù)存儲：倉庫管理員、采購員處理事務、產(chǎn)生報表事務、定貨報表庫存清單、定貨信息6.數(shù)據(jù)流圖實例定貨系統(tǒng)的頂級數(shù)據(jù)流圖

源點終點（1）從問題描述中提取數(shù)據(jù)流圖的4種成分，設計頂級數(shù)據(jù)流圖。6.數(shù)據(jù)流圖實例定貨系統(tǒng)的一級數(shù)據(jù)流圖（2）產(chǎn)生一級數(shù)據(jù)流圖6.數(shù)據(jù)流圖實例定貨系統(tǒng)的二級數(shù)據(jù)流圖（3）設計二級數(shù)據(jù)流圖。

考慮通過系統(tǒng)的邏輯數(shù)據(jù)流：當發(fā)生一個事務時必須首先接收它；隨后按照事務的內(nèi)容修改庫存清單；最后如果更新后的庫存量少于庫存量臨界值時，則應該再次定貨，也就是需要處理定貨信息。6.數(shù)據(jù)流圖實例2.3可行性研究工具

作為信息交流的工具；

作為分析和設計的工具。8.數(shù)據(jù)流圖的用途課堂練習-1銀行計算機儲蓄系統(tǒng)的工作過程大致如下：儲戶填寫的存款單或取款單由業(yè)務員鍵入系統(tǒng)，如果是存款則系統(tǒng)記錄存款人姓名、住址、身份證號碼等存款信息，并打印出存款存單給儲戶；如果是取款且存款時留有密碼，則系統(tǒng)首先核對儲戶密碼，若密碼正確或存款時未留密碼，則系統(tǒng)計算利息并打印出利息清單給儲戶。要求：用數(shù)據(jù)流圖描繪本系統(tǒng)的功能。計算機儲蓄系統(tǒng)數(shù)據(jù)流圖練習-1解析課堂練習-2某醫(yī)院打算開發(fā)一套以計算機為中心的患者監(jiān)護系統(tǒng)。該系統(tǒng)的基本要求是：系統(tǒng)隨時接收每個病人的生理信號（脈搏、體溫、血壓、心電圖等），當某個病人的生理信號超出醫(yī)生規(guī)定的安全范圍時向值班護士發(fā)出警告信息，定時記錄病人情況以形成患者日志，此外，護士在需要時還可以要求系統(tǒng)印出某個指定病人的病情報告。要求：用數(shù)據(jù)流圖描繪本系統(tǒng)的功能。(基本系統(tǒng)模型+功能級數(shù)據(jù)流圖)練習-2解析患者監(jiān)護系統(tǒng)的基本系統(tǒng)模型練習-2解析患者監(jiān)護系統(tǒng)的功能級數(shù)據(jù)流圖考慮一個修改磁帶上主文件的系統(tǒng)。文件管理員把修改信息穿孔在卡片上，系統(tǒng)讀入穿孔卡片上的信息并按照記錄號把修改信息順序排列好。然后系統(tǒng)逐個讀入主文件上的記錄，根據(jù)記錄上的校驗碼核對每個讀入的記錄，丟掉出錯的記錄，按照修改信息修改余下的記錄，產(chǎn)生的新文件存儲在磁盤上。最后系統(tǒng)輸出一份修改報告供文件管理員參閱。要求：分層次畫出上述主文件修改系統(tǒng)的數(shù)據(jù)流圖。

(基本系統(tǒng)模型+功能級數(shù)據(jù)流圖)課堂練習-3主文件修改系統(tǒng)的基本系統(tǒng)模型練習-3解析主文件修改系統(tǒng)的功能級數(shù)據(jù)流圖練習-3解析第2章可行性研究

2.1可行性研究的目標與任務

2.2可行性研究過程

2.3可行性研究工具

2.4成本/效益分析2.4成本/效益分析

成本/效益分析的目的是從經(jīng)濟角度評價開發(fā)一個新的軟件工程項目是否可行。成本/效益分析首先是估算待開發(fā)軟件系統(tǒng)的成本，然后與可能取得的效益進行比較。2.4成本/效益分析成本估計1．代碼行技術代碼行技術是比較簡單的定量估算方法，它把開發(fā)每個軟件功能的成本和實現(xiàn)這個功能需要用的源代碼行數(shù)聯(lián)系起來。軟件成本=每行代碼的平均成本×源代碼行數(shù)

每行代碼的平均成本主要取決于軟件的復雜程度和工資水平；實現(xiàn)一個功能需要的源代碼行數(shù)通?？梢愿鶕?jù)經(jīng)驗和歷史數(shù)據(jù)估計得到。此方法對于開發(fā)有類似工程的歷史數(shù)據(jù)的項目時比較有效。2.4成本/效益分析成本估計2．任務分解技術將軟件開發(fā)工程分解為若干相對獨立的任務。最常用的辦法是按開發(fā)階段劃分任務。如果需要可以把每個子系統(tǒng)在按開發(fā)階段進一步劃分成更小的任務。估計每個任務成本時，通常是將估計完成該項任務需要的人力（以人月為單位）乘以每人每月的平均工資得到。軟件開發(fā)成本=任務1的成本+任務2的成本+……2.4成本/效益分析成本估計3．自動估計成本技術

在有長期收集的歷史數(shù)據(jù)和良好的數(shù)據(jù)庫系統(tǒng)的支持下，可以采用自動估計成本軟件工具以減輕勞動強度，得到相對客觀的估計結果。2.4成本/效益分析效益分析效益包括有形效益和無形效益。有形效益可以用貨幣的時間價值、投資回收期、純收入等指標進行度量。無形的效益主要是從性質(zhì)上、心理上進行衡量，很難直接進行量化。常用的效益度量方法1．貨幣的時間價值

用利率表示貨幣的時間價值，設年利率為i，現(xiàn)已存入p元，則n年后可得到錢數(shù)為：F=P×(1+i)n

若n年后能收入F元，那么這些錢現(xiàn)在的價值是：P=F/(1+i)n2.4成本/效益分析例：在企業(yè)管理中使用制圖系統(tǒng)來取代大部分人工工作，每年可節(jié)省8.6萬元。若軟件生存期5年，則5年可節(jié)省43萬元。開發(fā)這個系統(tǒng)共投資18萬元。設年利率是5%，利用上面計算貨幣現(xiàn)在價值的共識，可以算出引入制圖系統(tǒng)后，每年預計節(jié)省的錢的現(xiàn)在價值。如下表所示。2.4成本/效益分析年將來值（萬元）（1+i）n現(xiàn)在值（萬元）累積的現(xiàn)在值（萬元）18.61.058.19058.190528.61.10257.800415.990938.61.15767.429223.420148.61.21557.075230.495358.61.27636.738237.2335（1）確定對系統(tǒng)的綜合要求

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

非功能性需求：可用性：如果用戶可以學會對系統(tǒng)的操作，能解釋一個系統(tǒng)或構建的輸入狀況，則稱系統(tǒng)是可用的?？煽啃裕嚎煽啃灾赶到y(tǒng)或構件在給定時間內(nèi)、指定條件下，可以完成軟件要求功能的能力。例如，可靠性需求包括系統(tǒng)出現(xiàn)故障前的使用時間等。3.1需求分析的任務（1）確定對系統(tǒng)的綜合要求

性能：性能需要考慮系統(tǒng)的定量屬性。例如,響應時間、吞吐量、有效性和準確性。

可支持性：關注系統(tǒng)部署后系統(tǒng)的變化情況。包括可移植性、可維護性等。

外部接口需求：常用的接口需求有用戶接口需求，硬件接口需求，軟件接口需求和通信接口需求。

約束信息：是指一些合理限制設計者和程序員選擇的條件。例如，某種數(shù)據(jù)必須達到的數(shù)據(jù)精度；要求軟件產(chǎn)品可以在某種系統(tǒng)上運行。3.1需求分析的任務（2）分析系統(tǒng)的數(shù)據(jù)要求——軟件需求分析的一個重要任務

復雜數(shù)據(jù)由許多基本數(shù)據(jù)元素組成，數(shù)據(jù)結構表示數(shù)據(jù)元素之間的邏輯關系。

數(shù)據(jù)字典——定義數(shù)據(jù)；

層次方框圖——

定義數(shù)據(jù)結構3.1需求分析的任務（3）建立軟件的邏輯模型

對系統(tǒng)的綜合要求對數(shù)據(jù)的要求描述方法：數(shù)據(jù)流圖、數(shù)據(jù)字典、實體-聯(lián)系圖、和主要的處理算法。（4）編寫軟件需求規(guī)格說明書（5）需求分析評審：驗證一致性、完整性、現(xiàn)實性、有效性

系統(tǒng)邏輯模型3.1需求分析的任務第3章需求分析

3.1需求分析的任務和步驟

3.2需求獲取的常用方法

3.3需求分析的方法

3.4結構化分析技術

3.5需求分析圖形工具

3.6習題1、訪談：最原始的獲取用戶需求的技術2、問卷調(diào)查：通常與用戶訪談組合使用3、觀察用戶工作流程：需要對復雜流程加深了解或?qū)﹃P鍵人物理解不清楚時使用4、建立聯(lián)合分析小組：由軟件開發(fā)方和客戶方共同組成5、快速原型法：需要多次修改3.2需求分析獲取的常用方法3.2需求分析獲取的常用方法1、訪談：（2）訪談對象被訪談者

話題中心

目標

高層管理人員

問題、機會

探討系統(tǒng)的目標與范圍

中層管理人員

業(yè)務事件

理清需求的脈絡信息

操作層

業(yè)務活動

填充需求的細節(jié)

技術團隊

解決方案

論證解決方案的可行性

表3.1訪談類型表3.2需求分析獲取的常用方法1、訪談：（3）訪談中的溝通技巧(a)制作訪談問卷并事先發(fā)給被訪談者。(b)把握語言節(jié)奏。(c)有效結合不同的問題類型。包括有封閉式問題（判斷題）、半封閉式問題（選擇題）、開放式問題（簡答題）。(d)注意安排問題的順序。(e)訪談時要注意溝通的細節(jié)。注意消除“隔行如隔山”的術語影響；善于觀察在訪談過程中對方的異?，F(xiàn)象；在溝通中注意使用模型幫助理解；不要遺漏問題。3.2需求分析獲取的常用方法2、問卷調(diào)查（1）問卷的特點：當片面性矛盾比較突出時就應該組織進行問卷調(diào)查。例如：企業(yè)中的從業(yè)人員數(shù)量是很大的，或存在跨地域用戶。（2）使用方法：用戶訪談與問卷調(diào)查應該采用組合方式使用。先調(diào)查，后訪談；先訪談，后調(diào)查。

問卷調(diào)查在設計問題時還要注意一些設計要點，如問題的篇幅與布局；問題類型的選擇等。問卷調(diào)查之后還要進行問卷分析。3.2需求分析獲取的常用方法3．觀察用戶工作流程但是這個過程耗時較長。而且由于“被觀察”者微妙的心理變化，會使觀察失真。所以此方法在需要對復雜流程加深了解時，對關鍵人物理解不清楚時使用。4．建立聯(lián)合分析小組聯(lián)合小組要制定小組工作計劃和進度安排，確定專門的記錄員和負責人。同時還要選定一種簡潔、準確、易于理解的符號，作為共同交流的語言。3.2需求分析獲取的常用方法5．快速原型法過程：快速建立起一個系統(tǒng)原型，用來演示系統(tǒng)功能。用戶對原型進行評估，根據(jù)用戶的需求來修改原型，把修改后的系統(tǒng)原型再次交給用戶評估，如此循環(huán)多次，直到獲得用戶最終準確的需求?？焖僭头ㄔ谑褂脮r應注意以下幾點：（1）系統(tǒng)原型應該是實現(xiàn)用戶看得見的功能。（2）盡量在較短的時間內(nèi)構建原型。（3）原型必須容易修改。第3章需求分析

3.1需求分析的任務和步驟

3.2需求獲取的常用方法

3.3需求分析的方法

3.4結構化分析技術

3.5需求分析圖形工具

3.6習題3.3需求分析的方法功能分解法結構化開發(fā)方法信息建模方法面向?qū)ο蟮姆治?.3需求分析的方法1．功能分解方法

這種方法是將一個系統(tǒng)看成是由若干功能構成的一個集合，每個功能又可劃分為若干個子功能，每個子功能又進一步分解。

這種方法是把軟件需求當做一棵倒置的功能樹。體現(xiàn)了“自頂向下，逐步求精”的思想，用過程抽象的觀點來看需求，符合傳統(tǒng)程序設計人員的思維特征。

最后分解的結果一般已經(jīng)是系統(tǒng)程序結構的一個雛形，實際它已經(jīng)很難與軟件設計明確分離。由此可見，這種方法往往難以適應用戶的需求變化。3.3需求分析的方法2．結構化開發(fā)方法

結構化開發(fā)方法提出了一組提高軟件結構合理性的準則，如分解與抽象、模塊獨立化等。它包含有結構化分析、結構化設計和結構化程序設計等方法。

結構化分析技術，是由E.Yourdon等人在20世紀70年代提出的一種適用于大型數(shù)據(jù)處理系統(tǒng)的、面向數(shù)據(jù)流的需求分析技術。3.3需求分析的方法3．信息建模方法

信息建模方法是從數(shù)據(jù)的角度來對現(xiàn)實世界建立模型的。

信息建模方法的基本工具是實體-聯(lián)系圖。在信息模型中，實體和關系形成一個網(wǎng)絡，描述系統(tǒng)的信息狀況。3.3需求分析的方法4．面向?qū)ο蟮姆治?/p>

面向?qū)ο蟮姆治鍪前褜嶓w-聯(lián)系圖中的概念與面向?qū)ο蟪绦蛟O計語言中的概念結合在一起。

面向?qū)ο蠓治龅年P鍵是識別、定義問題域內(nèi)的類與對象，并分析它們之間的關系，根據(jù)問題域中的操作規(guī)則建立模型。第3章需求分析

3.1需求分析的任務和步驟

3.2需求獲取的常用方法

3.3需求分析的方法

3.4結構化分析技術

3.5需求分析圖形工具

3.6習題3.4結構化分析技術

結構化分析技術是面向數(shù)據(jù)流自頂向下逐步求精進行需求獲取的方法，適合于數(shù)據(jù)處理類型系統(tǒng)的需求分析。思路：基于數(shù)據(jù)流圖自頂向下逐層分解分析工具：數(shù)據(jù)流圖、數(shù)據(jù)字典等分析過程：

沿數(shù)據(jù)流圖回朔 注意細節(jié)的分析、補充

用戶復查 補充、糾正、新問題的提出

細化數(shù)據(jù)流圖

修正開發(fā)計劃3.4結構化分析技術3.5需求分析圖形工具分為：非形式化，半形式化和形式化三類。半形式化的描述工具：實體-聯(lián)系圖、數(shù)據(jù)流圖、數(shù)據(jù)字典、描述加工邏輯的結構化語言、判定表和判定樹等。實體-聯(lián)系圖也稱為ER圖，是一種面向問題的數(shù)據(jù)模型，是按照用戶觀點對數(shù)據(jù)建立的模型。數(shù)據(jù)模型中包含3種互相關聯(lián)的信息：實體、屬性

和

聯(lián)系。3.5.1實體-聯(lián)系圖實體對軟件必須理解的復合信息的抽象

復合信息是具有一系列不同性質(zhì)或?qū)傩缘氖挛?僅有單個值的事物不是數(shù)據(jù)對象。

數(shù)據(jù)對象可以是外部實體、事物、行為、時間、角色、單位、地點或結構等。3.5.1實體-聯(lián)系圖

屬性數(shù)據(jù)對象的性質(zhì)

把屬性定義為“標識符”。在查找數(shù)據(jù)對象實例時，用標識符屬性作為“關鍵字”。實體的屬性有很多，應盡量找與開發(fā)系統(tǒng)相關的一些性質(zhì)。實體和聯(lián)系都有屬性，兩者可以轉(zhuǎn)換為相應的數(shù)據(jù)庫表，而屬性則是表里的字段。3.5.1實體-聯(lián)系圖

聯(lián)系數(shù)據(jù)對象彼此之間相互連接的方式

一對一聯(lián)系（1：1）一對多聯(lián)系（1：N）多對多聯(lián)系（M：N）3.5.1實體-聯(lián)系圖如何區(qū)分實體和屬性實體與屬性是相對而言的。同一事物，在一種應用環(huán)境中作為“屬性”，在另一種應用環(huán)境中也可以作為“實體”。例：學校中的系，在某種應用環(huán)境中，它只是作為“學生”實體的一個屬性，表明一個學生屬于哪個系；而在另一種環(huán)境中，由于需要考慮一個系的系主任、教師人數(shù)、學生人數(shù)、辦公地點等，這時它就需要作為實體了。3.5.1實體-聯(lián)系圖如何區(qū)分實體和屬性

一般原則：屬性不能再具有需要描述的性質(zhì)。即屬性必須是不可分的數(shù)據(jù)項，不能再由另一些屬性組成。屬性不能與其他實體具有聯(lián)系。聯(lián)系只發(fā)生在實體之間。符合上述兩條特性的事物一般作為屬性對待。為了簡化E-R圖的處置，現(xiàn)實世界中的事物凡能夠作為屬性對待的，應盡量作為屬性。3.5.1實體-聯(lián)系圖例1：“學生”由學號、姓名等屬性進一步描述，根據(jù)準則１，“學生”只能作為實體，不能作為屬性。例2：職稱通常作為教師實體的屬性，但在涉及住房分配時，由于分房與職稱有關，也就是說職稱與住房實體之間有聯(lián)系，根據(jù)準則２，這時把職稱作為實體來處理會更合適些。3.5.1實體-聯(lián)系圖

符號E-R圖(Entity-RelationshipDiagram)

實體：矩形框

關系：菱形框

屬性：橢圓形或圓角矩形3.5.1實體-聯(lián)系圖實體-聯(lián)系圖的元素符號實體聯(lián)系屬性3.5.1實體-聯(lián)系圖例如：某品牌的計算機是由多種部件組成的，而部件通過各地供貨商供應，假定每種部件的供貨商是唯一的，但一個供貨商可以供應多種零件。3.5.1實體-聯(lián)系圖課堂練習-1：請為某倉庫的管理設計一個ER模型。該倉庫主要管理零件的訂購和供應商等事項。倉庫向工程項目供應零件，并且根據(jù)需要向供應商訂購零件。3.5.1實體-聯(lián)系圖工程項目供應商零件供應訂購MMNN零件名稱零件編號顏色重量供應量訂購量項目編號開工日期項目名稱供應商編號地址供應商名稱課堂練習-2：

銀行計算機儲蓄系統(tǒng)的工作過程大致如下：儲戶填寫的存款單或取款單由業(yè)務員鍵入系統(tǒng)，如果是存款則系統(tǒng)記錄存款人姓名、住址、身份證號碼等存款信息，并打印出存款存單給儲戶；如果是取款且存款時留有密碼，則系統(tǒng)首先核對儲戶密碼，若密碼正確或存款時未留密碼，則系統(tǒng)計算利息并打印出利息清單給儲戶。要求：用ER圖描繪系統(tǒng)中的數(shù)據(jù)對象。3.5.1實體-聯(lián)系圖儲戶儲蓄所存取款MN類型數(shù)額利率密碼姓名身份證號碼住址名稱地址電話號碼電話號碼到期日期計算機儲蓄系統(tǒng)的實體-聯(lián)系圖學生每學期按照事先安排的課程計劃開始學習。每門課程由多名教師講授,一個教師可以講授多門課程；每名學生可以選修多門課程；學期結束后通過考試，教師登記每門課程、每名學生的成績，并得到確認后存檔；要求可以按照教師、學生、課程查詢和統(tǒng)計成績，了解課程授課的質(zhì)量；能給出統(tǒng)計分析報表，供院主管部門參考。舉例：3.5.1實體-聯(lián)系圖教師課程編號姓名性別職稱系別自然情況編號名稱學時學期性質(zhì)講授nm3.5.1實體-聯(lián)系圖學生課程編號姓名性別班級學生證號自然情況編號名稱學時學期性質(zhì)選修nm成績3.5.1實體-聯(lián)系圖教師課程編號姓名性別職稱系別自然情況編號名稱學時學期性質(zhì)講授nm學生編號姓名性別班級學生證號自然情況選修nm成績3.5.1實體-聯(lián)系圖

數(shù)據(jù)字典是關于數(shù)據(jù)的信息的集合，也就是對數(shù)據(jù)流圖中包含的所有元素的定義的集合。任何字典最主要的用途都是供人查閱對不了解的條目的解釋，數(shù)據(jù)字典的作用也正是在軟件分析和設計的過程中給人提供關于數(shù)據(jù)的描述信息。3.5.2數(shù)據(jù)字典

數(shù)據(jù)流圖和數(shù)據(jù)字典共同構成系統(tǒng)的邏輯模型，沒有數(shù)據(jù)字典數(shù)據(jù)流圖就不嚴格，然而沒有數(shù)據(jù)流圖數(shù)據(jù)字典也難于發(fā)揮作用。只有數(shù)據(jù)流圖和對數(shù)據(jù)流圖中每個元素的精確定義放在一起，才能共同構成系統(tǒng)的規(guī)格說明。3.5.2數(shù)據(jù)字典基本功能：定義數(shù)據(jù)。數(shù)據(jù)字典由對以下四類元素的定義組成：數(shù)據(jù)流；數(shù)據(jù)流分量（即數(shù)據(jù)元素）；數(shù)據(jù)存儲；處理。

注：通常用IPO圖或PDL圖描述3.5.2數(shù)據(jù)字典數(shù)據(jù)流圖中每一個被命名的圖形元素包含：名

字：數(shù)據(jù)流圖中表示數(shù)據(jù)流、數(shù)據(jù)源或外部實體的名字與別名。（保持命名唯一性）別

名:數(shù)據(jù)描述：關于該數(shù)據(jù)條目的簡要功能描述。數(shù)據(jù)定義：該數(shù)據(jù)條目的解釋性說明，可以使用自頂向下的方法進行定義。數(shù)據(jù)位置：使用該數(shù)據(jù)條目作為輸入流或輸出流的轉(zhuǎn)換的列表。（修改時保持數(shù)據(jù)元素的一致性）3.5.2數(shù)據(jù)字典數(shù)據(jù)定義的方法：對于復雜的數(shù)據(jù)，一般可以采用自頂向下的方法進行分解。復雜數(shù)據(jù)中的數(shù)據(jù)元素的組成方式：順序：表示個分量連續(xù)地按次序排列。通常用加號表示連續(xù)關系。選擇：表示從列表中的多個元素中選取一個。重復：表示某個元素重復零次或多次?？蛇x：表示一個分量是可有可無的（即重復零次或一次）。3.5.2數(shù)據(jù)字典可以使用的符號：（1）=表示“被定義為”或“等價于”或“由……組成”。

（2）＋表示“與”（和），用來連接兩個數(shù)據(jù)元素。例如，職工號=科室號+序列號。（3）[…|…]表示“或”，對[]中列舉的數(shù)據(jù)元素可任選其中某一項。例如：性別=[男|女]表示性別由男或女組成。3.5.2數(shù)據(jù)字典（4）{…}表示“重復”，對{…}中內(nèi)容可以重復使用。通常使用m{…|…}n或者

表示{…}mn中內(nèi)容至少出現(xiàn)m次，最多出現(xiàn)n次。其中m和n為重復次數(shù)的上、下限。例如，字符串=2{字母或數(shù)字字符}6表示“字符串”由2—6位字母或數(shù)字字符符號組成。（5）（…）表示“可選”，對（…）中的內(nèi)容可選、可不選；例如，學生基本信息=學號+性別+（家庭住址）。（6）“...”表示基本數(shù)據(jù)元素。例如，x=“a”。（7）..表示連結符。例如，x=1..9。3.5.2數(shù)據(jù)字典數(shù)據(jù)字典的實現(xiàn)：小型軟件系統(tǒng)中一般采用卡片的形式描述。一張卡片上記錄某數(shù)據(jù)元素中包含名字、別名、描述、定義和位置。3.5.2數(shù)據(jù)字典假設一家工廠的采購部每天需要一張定貨報表，報表按零件編號排序，表中列出所有需要再次定貨的零件，對于每個需要再次定貨的零件應該列出下述數(shù)據(jù)：零件編號，零件名稱，定貨數(shù)量,目前價格，主要供應者，次要供應者。零件的入庫或出庫稱為事務，通過放在倉庫中的CRT終端把事務報告給定貨系統(tǒng)。當某種零件的庫存數(shù)量少于庫存量臨界值時就應該再次定貨。請用數(shù)據(jù)流圖描繪該功能的需求并建立相應的數(shù)據(jù)字典。3.5.2數(shù)據(jù)字典名字：定貨報表別名：定貨信息描述：每天一次送給采購員的需要定貨的零件表定義：定貨報表=零件編號+零件名稱+定貨數(shù)量+目前價格+主要供應者+次要供應者位置：定貨信息名字：零件編號別名：描述：唯一地標識庫存清單中一個特定零件的關鍵域定義：零件編號=8{字符}8位置：定貨報表定貨信息庫存清單事務名字：定貨數(shù)量別名：描述：某個零件一次定貨的數(shù)量定義：定貨數(shù)量=1{數(shù)字}5位置：定貨報表定貨信息

3.5.2數(shù)據(jù)字典定貨報表在DD中的定義：名字：定貨報表別名：定貨信息描述：每天一次送給采購員的需要定貨的零件表定義：定貨報表=零件編號+零件名稱+定貨數(shù)量+目前價格+主要供應者+次要供應者位置：定貨信息定貨報表在數(shù)據(jù)字典中的表示：3.5.2數(shù)據(jù)字典名字：零件編號別名：描述：唯一地標識庫存清單中一個特定零件的關鍵域定義：零件編號=8{字符}8位置：定貨報表

定貨信息

庫存清單

事務3.5.2數(shù)據(jù)字典名字：定貨數(shù)量別名：描述：某個零件一次定貨的數(shù)量定義：定貨數(shù)量=1{數(shù)字}5位置：定貨報表

定貨信息3.5.2數(shù)據(jù)字典練習-1：某程序設計語言規(guī)定，用戶說明的標識符是長度不超過8個字符的字符串，其中第一個字符必須是字母字符，隨后的字符既可以是字母字符也可以是數(shù)字字符。則對標識符的定義可表示為：標識符=字母字符+字母數(shù)字串字母數(shù)字串=0{字母或數(shù)字}7字母或數(shù)字=[字母字符|數(shù)字字符]3.5.2數(shù)據(jù)字典習題11電話號碼=[分機號碼|外線號碼]分機號碼=8201..8299外線號碼=數(shù)字零+[市話號碼|長話號碼]數(shù)字零=0市話號碼=局號+分局號局號=[455|325|999]分局號=4位數(shù)字串4位數(shù)字串=4{數(shù)字}4數(shù)字=0..9長話號碼=區(qū)號+市話號碼區(qū)號=000..300練習-2：北京某高?？捎玫碾娫捥柎a有以下幾類：校內(nèi)電話號碼由4位數(shù)字組成，第1位數(shù)字不是0；校外電話又分為本市電話和外地電話兩類，撥校外電話需先撥0，若是本市電話則再接著撥8位數(shù)字(第1位不是0)，若是外地電話則撥3位區(qū)碼再撥8位電話號碼(第1位不是0)。3.5.2數(shù)據(jù)字典電話號碼=[校內(nèi)電話號碼|校外電話號碼]校內(nèi)電話號碼=非零數(shù)字+3位數(shù)字校外電話號碼=[本地號碼|外地號碼]本地號碼=數(shù)字零+8位數(shù)字外地號碼=數(shù)字零+3位數(shù)字+8位數(shù)字非零數(shù)字=[1|2|3|4|5|6|7|8|9]數(shù)字零=03位數(shù)字=3{數(shù)字}38位數(shù)字=非零數(shù)字+7位數(shù)字7位數(shù)字=7{數(shù)字}7數(shù)字=[0|1|2|3|4|5|6|7|8|9]電話號碼在數(shù)據(jù)字典中的定義：層次方框圖：用樹型結構的一系列多層次的矩形框描繪數(shù)據(jù)的層次結構。頂層是一個單獨的矩形框，代表完整的數(shù)據(jù)結構，下面的各層矩形框代表這個數(shù)據(jù)的子集，最底層的各個框代表組成這個數(shù)據(jù)的實際數(shù)據(jù)元素（不能再分割的元素）。3.5.3層次方框圖例如，描繪一所大學各個機關部門和學院的組成可以用如圖3.3中的層次方框圖表示。這所大學由黨委辦公室、校長辦公室及各個學院組成，計算機學院又分為軟件工程系、計算機科學系等。3.5.3層次方框圖例如，描繪一家計算機公司全部產(chǎn)品由硬件、軟件和服務三類產(chǎn)品組成。硬件包括處理機、存儲器和外部設備等。軟件產(chǎn)品又分為系統(tǒng)軟件和應用軟件，系統(tǒng)軟件又進一步分為操作系統(tǒng)、編譯程序和軟件工具等。而服務類產(chǎn)品包括軟件服務、硬件維修和培訓等。試用層次方框圖表示該公司全部產(chǎn)品的數(shù)據(jù)結構。3.5.3層次方框圖IPO圖：簡稱是IPO（InputProcessOutput）圖。它能夠方便地描繪輸入數(shù)據(jù)、對數(shù)據(jù)的處理和輸出數(shù)據(jù)之間的關系。

左邊的框中列出有關的輸入數(shù)據(jù)，中間的框內(nèi)列出主要的處理，右邊的框內(nèi)列出產(chǎn)生的輸出數(shù)據(jù)。處理框中列出處理的次序暗示了執(zhí)行的順序。3.5.4IPO圖

總體設計：應用各種技術和原理，對設備、過程或系統(tǒng)做出足夠詳細的定義，使之能夠在物理上得以實現(xiàn)。

過程：將“做什么”的邏輯模型轉(zhuǎn)變?yōu)椤霸趺醋觥钡奈锢砟Ｐ停磳⑶捌诠こ讨械能浖枨筠D(zhuǎn)換為軟件表示的過程。4.1總體設計的目標及任務

總體設計的基本目的：

解決“系統(tǒng)應該如何實現(xiàn)”的問題總體設計的兩個階段：

系統(tǒng)設計階段：確定系統(tǒng)的具體實現(xiàn)方案

結構設計階段：確定系統(tǒng)的軟件結構4.1總體設計的目標及任務1、設計軟件結構（1）通過需求分析階段得到的數(shù)據(jù)流圖設想各種可能方案。將一個復雜的系統(tǒng)按功能劃分為若干模塊；（2）確定每個模塊的功能；（3）確定模塊之間的調(diào)用關系；（4）確定模塊之間的接口，即模塊之間傳遞的消息；（5）評價模塊結構的質(zhì)量。4.1總體設計的目標及任務2．數(shù)據(jù)結構及數(shù)據(jù)庫設計

數(shù)據(jù)結構的設計采用逐步細化的方法。在需求分析階段可通過數(shù)據(jù)字典對數(shù)據(jù)的組成、操作約束和數(shù)據(jù)之間的關系等方面進行描述，確定數(shù)據(jù)的結構特性。在總體設計階段要加以細化，詳細設計階段則規(guī)定具體的實現(xiàn)細節(jié)。4.1總體設計的目標及任務3．確定測試要求并制定測試計劃

軟件開發(fā)早期階段考慮測試問題，能促使軟件設計人員在設計時注意提高軟件的可測試性。4、編寫總體設計文檔《概要設計說明書》4.1總體設計的目標及任務5、評審

對設計部分是否完整地實現(xiàn)需求中規(guī)定的功能、性能等要求，設計方案的可行性、關鍵的處理及內(nèi)外部接口定義正確性、有效性，及各部分之間的一致性等進行評審。4.1總體設計的目標及任務第4章總體設計

4.1總體設計的目標及任務

4.2軟件結構設計原理

4.3軟件結構設計工具

4.4軟件結構設計啟發(fā)式規(guī)則

4.5結構化設計方法4.2軟件結構設計原理軟件結構設計（結構化方法）：①在系統(tǒng)設計中分析信息流程，繪制數(shù)據(jù)流程圖；②根據(jù)數(shù)據(jù)的規(guī)范，編制數(shù)據(jù)字典；③根據(jù)概念結構的設計，確定數(shù)據(jù)文件的邏輯結構；④選擇系統(tǒng)執(zhí)行的結構化語言，以及采用控制結構作為軟件的設計工具。4.2軟件結構設計原理4.2.1模塊化“由大化小，各個擊破”優(yōu)點：

提高可靠性、可修改性

錯誤一般出現(xiàn)在模塊或接口中4.2軟件結構設計原理4.2.1模塊化模塊:

數(shù)據(jù)說明、可執(zhí)行語句等程序?qū)ο蟮募?，或者是單獨命名和編址的元素（如函?shù)、子程序）等。模塊化:

解決一個復雜問題時自頂向下逐層把軟件系統(tǒng)劃分成若干模塊的過程。每個模塊完成一個特定的子功能，所有的模塊按某種方法組裝起來，成為一個整體，完成整個系統(tǒng)所要求的功能。4.2軟件結構設計原理4.2.1模塊化模塊的基本屬性：接口：模塊的輸入與輸出。

功能：模塊實現(xiàn)什么功能。

邏輯：描述內(nèi)部如何實現(xiàn)要求的功能及所需的數(shù)據(jù)。

狀態(tài)：指該模塊的運行環(huán)境，是模塊的調(diào)用與被調(diào)用的關系。功能、狀態(tài)、接口反映模塊的外部特性，邏輯反映它的內(nèi)部特性。4.2軟件結構設計原理4.2.2抽象抽出事物本質(zhì)特性而不考慮細節(jié)軟件設計：從抽象概括到具體實現(xiàn)的過程具體

抽象

具體（系統(tǒng)功能）（建模）（程序代碼）問題定義階段：（具體）用戶給出對目標系統(tǒng)的實際需求。

系統(tǒng)定義階段：（抽象）軟件可作為整個計算機系統(tǒng)的一個元素來看待。軟件需求分析階段：（抽象）軟件的解決方案是使用問題環(huán)境中的術語來描述?？傮w設計—詳細設計階段：（抽象—具體）將面向問題的術語與面向?qū)崿F(xiàn)的術語結合起來來描述解決方法，直到產(chǎn)生源程序時到達最低抽象層次。4.2軟件結構設計原理4.2軟件結構設計原理4.2.2逐步求精為了能集中精力解決主要問題而盡量推遲對問題細節(jié)的考慮。Miller法則：一個人在任何時候都只能把注意力集中在(7±2)個知識塊上。4.2軟件結構設計原理4.2.3信息隱藏和局部化信息隱藏原理：設計和確定模塊時，使得一個模塊內(nèi)包含的信息對于不需要這些信息的模塊來說，是不能訪問的。局部化：把一些關系密切的軟件元素物理地放得彼此靠近。優(yōu)點：防止錯誤的擴大與傳播。4.2軟件結構設計原理4.2.4模塊獨立性模塊獨立是模塊化、抽象、信息隱藏和局部化概念的直接結果。

模塊獨立：每個模塊完成一個相對獨立的特定子功能，并且和其他模塊之間的關系很簡單。4.2軟件結構設計原理4.2.4模塊獨立性良好的模塊獨立性的重要性：能使開發(fā)的軟件具有較高的質(zhì)量。

設計的模塊可理解性、可維護性及可測試性好，必然導致軟件的可靠性高。

接口簡單、功能獨立的模塊易開發(fā)，且可并行工作，有效地提高了軟件的生產(chǎn)率。4.2軟件結構設計原理4.2.4模塊獨立性

耦合：軟件系統(tǒng)結構中各模塊間相互聯(lián)系緊密程度的一種度量。模塊之間聯(lián)系越緊密，其耦合性就越強，模塊的獨立性則越差。模塊間總是相互關聯(lián)的，很少是相互獨立的，完全獨立的模塊是無法構成系統(tǒng)的。

模塊間耦合高低取決于模塊間接口的復雜性、調(diào)用的方式及傳遞的信息。4.2軟件結構設計原理4.2.4模塊獨立性

耦合類型無直接耦合—數(shù)據(jù)耦合—控制耦合—特征耦合—公共耦合—內(nèi)容耦合

低——————————————————————高4.2軟件結構設計原理4.2.4模塊獨立性

無直接耦合：指兩個模塊之間沒有直接的關系，它們分別從屬于不同模塊的控制與調(diào)用，它們之間不傳遞任何信息。

數(shù)據(jù)耦合：指兩個模塊之間有調(diào)用關系，傳遞的是簡單的數(shù)據(jù)值，相當于高級語言中的值傳遞。這種耦合程度較低，模塊的獨立性較高。

控制耦合：指一個模塊調(diào)用另一個模塊時，傳遞的是控制變量(如開關、標志等)，被調(diào)模塊通過該控制變量的值有選擇地執(zhí)行塊內(nèi)某一功能。4.2軟件結構設計原理4.2.4模塊獨立性

特征耦合：當模塊之間傳遞的是某些數(shù)據(jù)結構，但是目標模塊只是使用了數(shù)據(jù)結構中的部分內(nèi)容時，這種耦合方式稱為特征耦合。

公共耦合：指通過一個公共數(shù)據(jù)環(huán)境相互作用的那些模塊間的耦合。公共數(shù)據(jù)環(huán)境可以是全程變量或數(shù)據(jù)結構、共享的通信區(qū)、內(nèi)存的公共覆蓋區(qū)及存儲介質(zhì)上的文件和物理設備等。

內(nèi)容耦合：當一個模塊直接使用另一個模塊的內(nèi)部數(shù)據(jù)，或通過非正常入口而轉(zhuǎn)入另一個模塊內(nèi)部時，這種模塊之間的耦合便為內(nèi)容耦合。4.2軟件結構設計原理4.2.4模塊獨立性設計原則：

盡量使用數(shù)據(jù)耦合，少用控制耦合和特征耦合，限制公共環(huán)境耦合的范圍，完全不用內(nèi)容耦合。4.2軟件結構設計原理4.2.4模塊獨立性

內(nèi)聚：一個模塊內(nèi)部各個元素彼此結合的緊密程度的度量。

偶然內(nèi)聚—邏輯內(nèi)聚—時間內(nèi)聚—過程內(nèi)聚—通信內(nèi)聚—順序內(nèi)聚—功能內(nèi)聚

低內(nèi)聚————————中內(nèi)聚

——————高內(nèi)聚4.2軟件結構設計原理4.2.4模塊獨立性偶然內(nèi)聚：指一個模塊內(nèi)的各處理元素之間沒有任何聯(lián)系。

邏輯內(nèi)聚：指模塊內(nèi)執(zhí)行幾個邏輯上相似的功能，通過參數(shù)確定該模塊完成哪一個功能。

時間內(nèi)聚：把需要同時執(zhí)行的動作組合在一起形成的模塊為時間內(nèi)聚模塊。時間內(nèi)聚模塊中的各部分都要在同一時間內(nèi)完成。過程內(nèi)聚：如果一個模塊內(nèi)部的處理是相關的，而且這些處理必須以特定的次序執(zhí)行，則稱過程內(nèi)聚。

4.2軟件結構設計原理4.2.4模塊獨立性通信內(nèi)聚：指模塊內(nèi)所有處理元素都在同一個數(shù)據(jù)結構上操作，或指各處理使用相同的輸入數(shù)據(jù)或者產(chǎn)生相同的輸出數(shù)據(jù)。

順序內(nèi)聚：指一個模塊中各個處理元素都密切相關于同一功能且必須順序執(zhí)行，前一功能元素的輸出就是下一功能元素的輸入。

功能內(nèi)聚：最強的內(nèi)聚形式，指模塊內(nèi)所有元素共同完成一個功能，缺一不可。模塊不能再分割。4.2軟件結構設計原理4.2.4模塊獨立性設計原則：

力爭做到高內(nèi)聚，并且能辨認出低內(nèi)聚的模塊，通過修改設計提高模塊的內(nèi)聚程度并降低模塊間的耦合程度?！咀ⅰ狂詈闲耘c內(nèi)聚性是模塊獨立性的兩個定性標準，將軟件系統(tǒng)劃分成模塊時，盡量做到高內(nèi)聚低耦合，提高模塊的獨立性，為設計高質(zhì)量的軟件結構奠定基礎。但也有內(nèi)聚性與耦合性發(fā)生矛盾的時候，為了提高內(nèi)聚性而可能使耦合性變差。在這種情況下，建議給予內(nèi)聚性以更高的重視。第4章總體設計

4.1總體設計的目標及任務

4.2軟件結構設計原理

4.3軟件結構設計工具

4.4軟件結構設計啟發(fā)式規(guī)則

4.5結構化設計方法4.4軟件結構設計啟發(fā)式規(guī)則1．模塊獨立性準則：通過模塊分解或合并，力求做到降低耦合提高內(nèi)聚，保持模塊相對獨立性。（1）如圖4.13(a)所示，若多個模塊公有的一個子功能（使用陰影部分表示），則可以將這個子功能獨立成一個模塊，由這些模塊調(diào)用。4.4軟件結構設計啟發(fā)式規(guī)則（2）若有多個功能相關的模塊，如圖4.13(b)所示B、C、D三個模塊耦合度較高，E、F兩個模塊耦合度較高，應考慮對它們進行合并以減少控制信息的傳遞，降低接口的復雜程度。4.4軟件結構設計啟發(fā)式規(guī)則2．模塊的作用域應該在控制域內(nèi)

作用域：指受該模塊內(nèi)一個判斷影響的所有模塊的集合?？刂朴颍褐改K本身以及其所有直接或者間接從屬于它的模塊集合。4.4軟件結構設計啟發(fā)式規(guī)則(a)(b)(c)圖4.14模塊的作用域和控制域(a)差的結構圖(b)不理想的結構圖(c)理想的結構圖4.4軟件結構設計啟發(fā)式規(guī)則改進方法：（1）上移判斷點。如圖4.14(a)所示，將模塊D中的判斷點上移到它的上層模塊B中，或者將整個模塊D合并到模塊B中，使該判斷的層次升高，以擴大它的控制域。

（2）下移受判斷影響的模塊。將受判斷影響的模塊下移到判斷所在模塊的控制域內(nèi)，如圖4.14(a)所示，將模塊C下移到模塊D的下層。（1）深度指軟件結構中模塊的層次數(shù)，它表示控制的層數(shù)，一定意義上能粗略地反映系統(tǒng)的規(guī)模和復雜程度。

（2）寬度指同一層次中最大的模塊個數(shù)，它表示控制的總分布。

（3）扇出指一個模塊直接調(diào)用的模塊數(shù)目。經(jīng)驗證明，良好的系統(tǒng)結構平均扇出數(shù)一般是3-4，不能超過5-9。

（4）扇入指有多少個上級模塊直接調(diào)用它。

4.4軟件結構設計啟發(fā)式規(guī)則3．軟件結構的形態(tài)特征準則（1）深度能粗略地反映系統(tǒng)的規(guī)模和復雜程度，寬度也能反映系統(tǒng)的復雜情況。寬度與模塊扇出有關，若一個模塊的扇出太多，說明本模塊過分復雜，缺少中間層。（2）單一功能模塊的扇入數(shù)大比較好，說明本模塊為上層幾個模塊共享的公用模塊，重用率高。（3）不能把彼此無關的功能湊在一起形成一個通用的超級模塊，雖然它扇入高，但內(nèi)聚低。因此非單一功能的模塊扇入高時應考慮重新分解，以消除控制耦合的情況。4.4軟件結構設計啟發(fā)式規(guī)則4.3軟件結構設計工具如圖所示，結構圖的深度為5；寬度為8；模塊M的扇出為3；模塊T的扇入為4。4.4軟件結構設計啟發(fā)式規(guī)則4．模塊大小準則

在考慮模塊的獨立性時，為了增加可理解性，模塊的大小最好在50-150條語句左右，可以用1-2頁紙打印，便于人們閱讀與研究。5．模塊的接口準則（1）模塊接口設計要簡單，以降低復雜程度和冗余度。（2）設計功能可預測并能得到驗證的模塊。（3）適當劃分模塊規(guī)模，以保持其獨立性。第4章總體設計

4.1總體設計的目標及任務

4.2軟件結構設計原理

4.3軟件結構設計工具

4.4軟件結構設計啟發(fā)式規(guī)則

4.5結構化設計方法4.3.1層次圖4.3軟件結構設計工具左圖中，矩形框：模塊連線：調(diào)用關系層次圖：適于在自頂向下設計軟件的過程中使用。4.3.2HIPO圖=H圖+每個模塊的IPO圖（H圖：帶編號的層次圖）4.3軟件結構設計工具Note:

和H圖中每個方框相對應，應都有一張IPO圖來描繪其代表的模塊處理過程。4.3軟件結構設計工具4.3.3軟件結構圖主要內(nèi)容：模塊——方框表示

模塊的調(diào)用關系——單向箭頭或直線模塊間的信息傳遞——帶注釋的短箭頭選擇調(diào)用——菱形循環(huán)調(diào)用——弧形箭頭4.3軟件結構設計工具4.3軟件結構設