第1章軟件工程學概述1.1軟件危機1.2軟件工程1.3軟件生命周期1.4軟件過程

1.5小結習題*

學習重點1、軟件危機、軟件工程產生的原因2、軟件工程過程和軟件生命周期3、軟件生命周期模型掌握幾個基本概念軟件危機軟件工程軟件過程軟件生命周期軟件生命周期模型*

軟件危機與軟件工程學軟件工程學的產生要從“軟件危機”說起1968年，第一屆NAT0（北大西洋公約組織的計算機科學家的國際會議）會議，“軟件工程”的慨念作為一種有效解決“軟件危機”的途徑被正式提出。什么是軟件危機？軟件危機有什么典型表現？為什么會產生軟件危機？怎么解決軟件危機？*

§1軟件危機§1.1.1軟件危機介紹什么是軟件危機？軟件危機指在計算機軟件的開發和維護過程中，所遇到的一系列嚴重問題。軟件危機主要包括的問題（兩方面）:

①如何開發軟件②如何維護軟件*

軟件危機有什么典型表現？（1）開發費用和進度難以估算和控制，大大超過預期的資金和規定日期；軟件需求分析不夠充分，用戶不滿意“已經完成”的軟件系統。軟件質量難于保證；軟件維護困難；難以改正程序中的錯誤；難以根據用戶的需要在原有程序中增加一些新的功能。*

軟件危機有什么典型表現？通常沒有保留適當的文檔資料。文檔的作用：軟件開發管理人員：用于管理和評價軟件開發工程的進展狀況軟件開發人員：用于開發人員對各個階段的工作都進行周密思考、全盤權衡、從而減少返工。并且可在開發早期發現錯誤和不一致性，便于及時加以糾正軟件維護人員:軟件維護的依據開發成本逐年上升，軟件開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢。*

*

幾個軟件危機的著名案例①1966年，IBM360機的操作系統。花費5000人一年的工作量，寫了近1萬行代碼。錯誤百出，每次的新版本就是從前一版本中找1000個程序錯誤而修正的結果。②1963年，美國用于控制火星探測器的計算機軟件中的一個“,”號被誤寫為“.”，而致使飛往火星的探測器發生爆炸，造成高達數億美元的損失。③美國丹佛新國際機場自動化行李系統軟件。投資1.93億美元，計劃1993年萬圣節啟用。但開發人員一直為系統錯誤困擾，屢次推后啟用時間，直到1994年6月，機場計劃者承認無法預測何時能啟用。

④1996年，歐洲阿里亞納5型運載火箭墜毀，造成5億美元損失。原因是控制軟件中的一個錯誤。*

§1.1.2產生軟件危機的原因主要兩個原因：

1、與軟件本身的特點有關2、與軟件開發與維護的方法不正確有關。*

一、軟件本身的特點（1）軟件與硬件、一般程序存在很多不同之處。

1、軟件與硬件不同抽象性。軟件生產沒有明顯的制造過程，難以衡量開發進展，也難以控制軟件質量。問題的隱蔽性。沒有硬件的磨損、老化問題，但存在開發早期在分析、設計階段的錯誤，修改難度較大。*

失效率蜘線*

改正一個問題需付出的代價*

2、軟件與一般程序不同（1）①軟件遠比一般程序規模龐大，復雜性高軟件所反映的實際問題的復雜性程序邏輯結構的復雜性。例1:Windows95,1000萬行代碼；

Windows2000，5000萬行代碼例2:Exchange2000和windows2000開發人員*

軟件的規模軟件產品的特殊性和人類智力的局限性，導致人們無力處理“復雜問題”。*

2、軟件與一般程序不同（2)②大型軟件開發既有技術問題，還有社會問題。社會因素：組織機構、體制、管理方式、觀念、人的心理素等。開發團隊成員分工合作技術與管理的矛盾軟件開發人員對軟件應用的領域知識的了解*

二、軟件開發維護方法中存在的問題（1)①對用戶需求的獲取不正確用戶的原因分析人員的原因對分析人員的要求：溝通能力、歸納總結能力、經驗越是早期產生的錯誤，付出的代價越大。圖：不同時期引入同一變動的代價*

二、軟件開發維護方法中存在的問題(2)②軟件開發就是編寫程序。一個完整的軟件產品由一整套完整的配置組成，程序只是其中的一個組成部分。軟件開發過程包括多個階段，每個階段的產品都是最終的完整的軟件產品的一部分。③軟件開發只要依靠個別編程高手就能完成。

④輕視軟件維護軟件維護約占軟件費用55一75%，包括修改軟件運行的錯誤；對軟件進行改進和功能擴充。*

軟件維護在軟件費用的比例*

三、其他產生軟件危機的原因①軟件開發尚未完全擺脫手工藝的開發方式。②軟件成本相當昂貴，主要依靠大量復雜的、高強度的腦力勞動③軟件的開發和運行常常受到計算機系統的限制，對計算機系統有著不同程度的依賴性。軟件的“可移植性”就是指的軟件對硬件的依賴程度。好的可移植性依賴少。*

§1.1.3消除軟件危機的途徑1、徹底消除“軟件就是程序”的錯誤觀念。2、充分認識到軟件開發是一種組織良好、管理嚴密、各類人員協同配合、共同完成的工程項目，不是個人獨立的勞動。

3、推廣和使用在實踐中總結出來的軟件開發的成功技術和方法。

4、開發和使用更好的軟件工具*

總結：“軟件工程”的方法理論是擺脫軟件危機的一個主要出路。計算機和軟件科學家為解決軟件危機問題，嘗試將在其它領域中行之有效的工程學知識運用到軟件開發工作中來，經過不斷實踐和總結，最后得出一個結論；按工程化的原則和方法組織軟件開發工作是有效的，是擺脫軟件危機的一個主要出路。*

思考題（1)1）只要是編程高手，即使是不懂軟件工程，也能編出很好的軟件。軟件是服務于大眾，卻是由個性化的開發人員完成的。如果個性化太強，程序就無法閱讀，其他人員也就無法維護。例：國內80年代涌現出來的眾多漢字操作系統均是由編程高手完成的。*

思考題（2)2）只要擁有一套講述如何開發軟件的書籍，并了解了書中的標準與示例，就可以解決軟件開發中遇到的任何問題。軟件是用來解決現實問題的，現實問題的特殊性對規范提出了挑戰（要進行適應）。軟件技術是發展的，沒有祖傳秘方。就像擁有食譜并不能成為名廚一樣，軟件開發需要實踐。*

思考題（3)3）只要擁有最好的開發工具、最好的計算機，一定能做出優秀的軟件。硬件環境只是必要條件，人才是充分條件，軟件是人在一定的約束條件下創造出來的。因人因事而異。*

思考題(4)4）軟件開發時，如果進度慢，落后于計劃，可以增加更多的程序員來解決。增加人力可以減少開發時間嗎？新手！任務的重新劃分！溝通更加復雜！必須依靠科學地計劃來解決這樣的問題。*

思考題（5）5）爭議：如果軟件運行較慢，是換一臺更快的計算機，還是設計一種更快的算法？軟件的性能問題；應用級別→算法的合理性；系統級別→操作系統、數據庫系統、系統軟件等；硬件級別→機器性能*

§1.2軟件工程§1.2.1軟件工程介紹一、“軟件工程”的典型定義1）1968年，第一屆NATO會議為了經濟地獲得可靠的且能在實際機器上有效地運行的軟件，而建立和使用完善的工程原理。2)IEEE/CS（電氣電子工程師協會／計算機科學分會）

①1993年，將系統化的、規范的、可度量的方法應用于軟件的開發、運行和維護的過程，即將工程化應用于軟件中。

②對①中提到的各種方法的研究*

3）其他學者的定義Boehm：運用現代科學技術知識來設計并構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。FritzBauer:建立并使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟件的一系列方法所有定義都強調在軟件開發過程中，應用工程化原則的重要性*

幾個關于軟件工程本質特性和基本原理的問題問題一：軟件工程適用范圍？問題二：軟件工程如何控制系統開發的復雜性的？問題三：以你的經驗，舉例說明一個成熟的軟件通常采用什么方法來適應現實世界的變化的？*

幾個關于軟件工程本質特性和基本原理的問題問題四：假設某軟件公司，能為同一個用戶開發兩個不同層次的軟件：一個層次的軟件功能非常強大，在滿足用戶所有需求的基礎上，還能提供大大超過用戶需求的其他更多更強的功能；另一個層次的軟件僅僅能滿足用戶需求，但沒有提供其他額外的功能。請問如果你是項目負責人，你會選擇為客戶開發那個層次的軟件？問題五：協同工作有什么重要性？*

幾個關于軟件工程本質特性和基本原理的問題問題五：怎樣理解“在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人創造產品”這句話？問題六：某軟件開發，由于時間和資金都非常緊迫，在需求分析人員非常認真、仔細地做完需求分析之后，說：我們可以保證我們的需求分析正確性，不用花時間檢查了，設計人員可以直接拿著這份分析報告，馬上開始設計。如果你是項目負責人，你會如何決定？為什么？問題七：在需求分析完成并獲得了用戶的肯定，也通過了評審，進入軟件設計階段之后，用戶的想法有了改變，提出了一個新的要求，此時如果你是項目負責人，應該怎樣做？*

二、軟件工程本質特性（2）1）軟件工程關注于大型程序的構造。

2）軟件工程的中心課題是控制復雜性主要考慮：如何分解和集成為什么要分解：G.Miller,“7士2”

原則3）軟件經常變化4）開發軟件的效率非常重要5）和諧地合作是開發軟件的關鍵6）軟件必須有效地支持它的用戶7）在軟件工程領域中是由具有一種文化背景的人替具有另一種文化背景的人創造產品擴展定義：軟件=知識＋程序+數據+文檔*

§1.2.2軟件工程的基本原理B.W.Boehm,1983年提出：

1）用分階段的生命周期計劃嚴格管理

2）堅持進行階段評審

3）實行嚴格的產品控制基線基線（baseline）控制

4）采用現代程序設計技術

5）結果應能清楚地審查

6）開發小組的人員應該少而精7）承認不斷改進軟件工程實踐的必要性*

§1.2.3軟件工程方法學軟件工程包括“管理”和“技術”兩方面內容：管理——對人、財、物的合理使用和配置；技術——指軟件開發中采用的方法、工具和過程。什么是軟件工程方法學？通常把在軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學（methodology)，也稱為范型（paradigm）。*

一、軟件工程方法學三要素：工具、方法和過程要素一：軟件工程過程規定了完成各項任務的工作步驟。要素二：軟件工程方法完成軟件開發的各項任務的技術方法，為軟件開發提供了“如何做”的技術。如項目計劃與估算、軟件系統需求分析、數據結構、系統總體結構的設計、算法過程的設計、編碼、測試以及維護等。要素三：軟件工程工具計算機輔助軟件工程CASE(computerAidedsottwareEngineering)，為軟件工程方法提供自動或半自動的軟件支撐環境。*

二、軟件工程方法學思想兩種：1、傳統方法學（生命周期方法學或結構化范型）

2、面向對象方法*

1.傳統方法學(生命周期方法學或結構化范型）采用結構化技術（結構化分析、結構化設計和結構化實現）來完成軟件開發的各項任務；把軟件生命周期劃分為若干個階段，按順序完成每個階段的任務；每個階段開始和結束都有嚴格的標準，對任何兩個相鄰的階段而言，前一個階段的結束標準就是后一階段的開始標準；每一個階段結束之前都必須進行正式嚴格的技術審查和管理復審*

傳統方法學的優點：分解任務，分工合作，降低整個軟件開發工程的困難；采用科學的管理技術和良好的技術方法對每個階段成果都進行嚴格的審查。保證了軟件的質量。傳統方法學的缺點：把數據和操作人為地分離成兩個獨立的部分，增加了軟件開發與維護的難度。*

2、面向對象方法學（OO,Object-oriented)

模擬人類習慣的思維方式，使開發軟件的方法與過程盡可能接近人類認識世界解決問題的方法與過程，從而使描述問題的問題空間（也稱為問題域）與實現解法的解空間（也稱為求解域）在結構上盡可能一致。*

面向對象方法學4要點把對象（object）作為融合了數據及在數據上的操作行為的統一的軟件構件。把所有對象都劃分成類（class）。按照父類（或稱為基類）與子類（或稱為派生類）的關系，把若干個相關類組成一個層次結構的系統（也稱為類等級）。對象彼此間僅能通過發送消息互相聯系。*

二者區別傳統方法學：強調自頂向下順序地完成軟件開發的各階段任務。面向對象方法：是主動地多次反復迭代的演化過程*

3軟件生命周期一、什么是軟件生命周期（lifecycle）指軟件孕育、誕生、成長、成熟、衰亡的生存過程

GB一8567中將軟件生命周期分為7個階段：可行性研究和項目開發計劃；需求分析；慨要設計；詳細設計；編碼；測試；維護其他分法，5個階段：需求定義、設計、編碼、測試及維護；需求定義階段包括可行性研究和項目開發計劃、需求分析；設計階段包括慨要設計和詳細設計。*

本教材對軟件生命周期的劃分*

1、軟件定義時期任務：確定軟件開發工程必須完成的總目標；確定工程的可行性；導出實現工程目標應該采用的策略及系統必須完成的功能；估計完成該項工程需要的資源和成本，并且制定工程進度表。通常分為問題定義、可行性研究和需求分析三個階段。*

軟件定義時期的三個階段①問題定義階段回答：

回答：“要解決的問題是什么？”

②可行性研究階段回答：“對于上一個階段所確定的問題有行得通的解決辦法嗎？

③需求分析（RequirementAnalysis）回答“為了解決這個問題，目標系統必須做什么?

用正式文檔準確地記錄對目標系統的需求，這份文檔通常稱為規格說明書（specification）。*

2、軟件開發時期具體設計和實現前一個時期定義的軟件，通常分為四個階段：

①總體設計（概要設計）回答：“概括地說，應該怎樣實現目標系統？”根據需求分析，設計軟件的體系結構；定義結構中的組成模塊。

②詳細設計（模塊設計）回答：“應該怎樣具體地實現這個系統呢？”對每個模塊要完成的工作進行具體的描述，為源程序編寫打下基礎。編寫設計說明書，提交評審。二者統稱系統設計

*

軟件開發時期四個階段③程序編寫（Coding,Programming)：把軟件設計轉換成計算機可以接受的程序代碼。

④軟件測試（Testing):按規定的各項需求，逐項進行有效性測試，決定已開發的軟件是否合格，能否交付用戶使用，包括單元測試和組裝測試。二者統稱系統實現*

3、運行維護（軟件維護）時期（Running/Maintenance)使軟件持久的滿足用戶的需要。包括：改正性維護：運行中發現了軟件中的錯誤需要修正。適應性維護：為了適應變化了的軟件工作環境，需做適當變更。完善性維護：當用戶有新的要求時，應該及時改進軟件以滿足用戶的要求。預防性維護:即修改軟件為將來的維護活動預先做準備。*

幾個關干軟件生命周期階段的問題問題一：開發一個軟件大概需要多少資金、時間，將獲得什么效益一般是在哪個階段確定？相對而言，在哪個階段與用戶交流最多？問題二：系統分析員主要工作在哪個時期？程序員主要工作在哪個時期？問題三：軟件定義時期的三個階段，各自回答什么關鍵問題？問題四：軟件開發時期有幾個階段？各自回答什么關鍵問題？*

問題五：軟件體系結構最早是在哪個階段決定的？問題六：詳細設計與程序編寫階段有什么樣的密切聯系？問題七：“軟件測試是為了驗證系統的正確性”這句話對嗎？問題八：軟件維護有那幾種？各有什么功能？*

§1.4軟件過程（SoftwareProcess)1、什么是軟件過程為了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。

ISO9000的定義：使用資源將輸入轉化為輸出的活動所構成的系統。“系統”是相互關聯或相互作用的一組要素。過程是軟件工程三要素之一。通常用軟件生命周期模型來描述。*

2、什么是軟件生命周期模型又稱：軟件開發模型／軟件過程模型／軟件工程范型。指軟件項目從需求定義直至軟件經使用后廢棄為止，跨越整個生存周期的系統開發、運作和維護所實施的全部過程、活動和任務的結構框架。常見的有：瀑布模型、演化模型、螺旋模型、噴泉模型、智能模型*

§1.4.1瀑布模型(waterfallmodel)1970年,由W.Royce提出

一、瀑布模型的過程

1、傳統的瀑布模型從上一階段接受本階段

的工作對象，作為輸入；利用輸入，完成本階段活

動的內容．本階段的工作成果作為輸出

傳入下一階段。*

瀑布模型—實際的瀑布模型

需求分析驗證規格說明驗證設計驗證編碼測試綜合測試維護變化的需求驗證

增加了一個評審活動，評審每個階段完成的活動，若得到確認，則進行下一階段的活動；否則返回前一階段，甚至更前階段返工；*

二、瀑布模型特點階段間具有順序性和依賴性推遲實現的觀點質量保證的觀點*

三、瀑布模型優缺點優點：可強迫開發人員采用規范的方法；嚴格地規定了每個階段必須提交的文檔；要求每個階段的所有產品都必須經過質量保證小組的仔細驗證；缺點：無法解決軟件需求不明確或不準確的問題；可能導致最終開發的產品不能真正滿足用戶需要。瀑布模型比較適合開發需求明確的軟件。*

§1.4.2快速原型模型1、什么是“原型”?

原型是快速實現和運行的早期版本，反映最終系統部分重要特性。常見的原型實例：人機界面；系統主要功能。

優點：

1、通常能反映用戶真實需求；

2、軟件產品的開發基本上是線性順序進行的。*

2、快速原型的過程如右圖。獲得用戶的基本需求說明，據此快速建立一個小型軟件系統．用戶試用，對其評價；開發人員按照用戶的意見快速地修改原型系統，獲得新的原型版本，再請用戶試用，如此反復，直到滿足用戶的要求；用戶確認原型系統之后，開發人員據此書寫規格說明文檔，進行下一步開發。*

1.4.3增量（漸增）模型

把軟件產品作為一系列的增量構件來設計、編碼、集成和測試。每個構件由多個相互作用的模塊構成，并且能夠完成特定的功能。使用增量模型時，第一個階段的增量構件往往實現軟件的基本需求，提供最核心的功能；后面的增量構架逐漸添加系統的功能。*

圖：增量（漸增）模型需求分析驗證規格說明驗證設計驗證維護針對每個構件完成詳細設計、編碼和集成，經測試后交付給用戶*

增量模型注意事項增量構件規模適中；分解的約束條件是當把新構件集成到現有軟件中時，所形成的產品必須是可測試的；軟件體系必須是開放的，即在對現有系統添加新增量構件時，不能破壞系統原有功能。*

增量模型優缺點優點：能在較短的時間內，提供可完成部分工作的初步產品給用戶；用戶有較為充裕的時間學習和適應新產品。缺點：對開發人員技術能力要求較高，要求能從系統整體出發正確劃分增量構件，并進行分別開發，最后能很好地集成這些構件。*

一種風險更大的增量模型

有可能提高開發速度，但需要密切地監控整個開發過程，否則將冒構件無法集成到一起的風險，。分析分析分析分析設計設計設計設計編碼編碼編碼編碼測試測試測試測試構件1構件2構件3構件4*

§1.4.4螺旋模型（spiralmodel)大型軟件開發面臨的重要問題：軟件風險如：產品交付給用戶之后，用戶不滿意；開發進度落后，開發成本超出預算;

產品完成前關鍵的開發人員跳槽;

在產品投人市場前，競爭對手發布了一個功能相近，價格更低的軟件………構建原型能使某些類型的風險降到最低.*

一、簡單的螺旋模型

螺旋模型改進了原型模型，在每個階段都加入風險分析。圖1.7簡化的螺旋模型圖1.7簡化的螺旋模型圖1.7簡化的螺旋模型

*

二、完整的螺旋模型*

螺旋模型的優缺點優點：強調可選方案和約束條件，有利于已有軟件的重用，也有助于把軟件質量作為軟件開發的一個重要目標；減少了過多測試（浪費資金）或測試不足（產品故障多）所帶來的風險；維護是一個周期，與開發并沒有本質區別缺點：需要開發人員具有相當豐富的風險評估經驗和專門知識；進行風險分析的費用可能較大。適合大型軟件開發*

各種模型的比較模型優點缺點瀑布模型規范，文檔驅動系統可能不滿足客戶真正的需求快速原型克服了瀑布型的缺點增量模型開發早期回報明確，易于維護要求開放的軟件體系結構螺旋模型風險驅動，適用于大型項目開發風險分析人員需要有經驗且經過充分訓練*

第一章小結*

軟件工程02章可行性研究02章可行性研究2.1可行性研究的任務2.2可行性研究過程2.3系統流程圖2.4數據流圖2.5數據字典2.6成本／效益分析2.7小結習題*

重點、難點重點：可行性研究任務；數據流圖基本符號、繪制過程及應用；數據字典的用途和建立：難點：數據流圖的應用*

§2.1可行性研究任務一、可行性研究的目的說明該軟件開發項目的實現在技術上、經濟上和社會條件上的可行性；評述為合理地達到開發目標可能選擇的各種方案。

GB8567-88《計算機軟件產品開發文件編制指南》

用最小的代價在盡可能短的時間內確定問題是否能夠并且值得解決。可行性研究最根本任務是對以后的行動方針提出建議.

可行性研究一般占預期工程總成本的5％~10％。*

二、可行性研究的基本內容1、技術可行性：使用現有的技術能實現這個系統嗎？主要考慮：開發風險；資源；相關技術的發展2、經濟可行性：這個系統的經濟效益能超過它的開發成本嗎？系統經濟效益=新系統增加的收入＋新系統節省的費用考慮：成本——效益分析、長期的公司經營策略、對其他單位或產品的影響、開發所需的成本和資源、潛在的市場前景3、操作可行性：系統的操作方式在用戶組織內行得通嗎？4、其他：法律可行性、社會效應、管理問題等*

國家標準定義的可行性研究

了解客戶的要求及現實環境，從技術、經濟和社會因素等三方面研究并論證本軟件項目的可行性，編寫可行性研究報告，制定初步項目開發計劃。一GB8566-88《計算機軟件開發規范》GB8567一88《計算機軟件產品開發文件編制指南》GB5666一88（計算機軟件開發規范》

國家標準局1988年發布標準基于軟件生存周期，將軟件產品從形成、開發、運用、維護，到最后被淘汰的整個過程中，應提交的文檔歸于13種，作為軟件開發人員工作的準則和規程。*

§2.2可行性研究的過程*

可行性研究報告的編寫

可行性研究報告功能：說明軟件項目的實現在技術上、經濟上和社會因素上的可行性，評述為合理地達到開發目標可供選擇的各種可能的實現方案，說明并論證所選定實施方案的理由。

GB8567一88《計算機軟件產品開發文件編制指南》*

§2.3系統流程圖

可行性分析的描述手段：系統流程圖、數據流圖

1、什么是系統流程圖?

概括地描繪物理系統的傳統工具。基本思想：用圖形符號以黑盒子形式描繪組成系統的每個部件（程序，文檔，數據庫，人工過程等）,表達數據在系統各部件之間流動的情況。*

§2.3.1符號*

§2.3.1例子一個簡單的例子圖2.3庫存清單系統的系統流程圖*

§2.3.3分層描繪復雜系統時，一采取分層次地描繪的方法第一步:建立高層次的系統流程圖，描繪系統總體概貌，表明系統的關鍵功能。第二步:分別對每個關鍵功能進行擴展，到合適的詳細程度，畫在單獨的一頁紙上。第三步：可以多次擴展，直到描述完整。優點：便于閱讀者按從抽象到具體的過程逐步深入地了解一個復雜的系統。*

§2.6成本／效益分析

從經濟角度分析開發一個特定的新系統是否劃算，幫助客戶負責人作出是否投資的決定。主要包括成本估計和成本效益分祈。*

§2.6.1成本估計

包括開發成本和運行成本

一、開發成本估計技術（1)1、代碼行技術

根據經驗和歷史數據，估算實現一個功能需要多少源程序行數，用每行代碼的平均成本乘以行數。*

一、開發成本估計技術（2)2、任務分解技術

將軟件開發工程分解成若干個相對獨立的任務，分別估算，然后累加得出總成本。按階段分解按功能分解5(%)*

例：按功能分解計算機輔助設計（CAD）的軟件項目估算將CAD項目分為如下7個子項目：用戶界面和控制；二維幾何分析；三維幾何分析；數據庫管理；計算機圖形顯示；外設控制；設計分析*

代碼行和成本、工作量估算*

系統開發和每年運行費用估算舉例A．系統開發費用（一次）。2名系統分析員（450小時/名，45美元/小時）$40,5005名系統開發人員（275小時/名，36美元/小時）$49,5001名數據庫管理員（30小時/名，42美元/小時）$1,2602名技術寫作者（120小時/名，25美元/小時）$6,0001名秘書（160小時/名，15美元/小時）$2,4001名數據通訊專家（60小時/名，42美元/小時）$2,4002名數據輸入人員（40小時/名，12美元/小時）$49,500*

系統其他費用培訓：三天的開發人員內部培訓課程$7,00030個用戶，三天的內部培訓課$10,000物資：復印$500磁盤、紙張等消耗品$650購買軟、硬件：

20臺工作站windows軟件$1,00020臺工作站內存升級$8,000

網絡軟件$17,50020臺工作站辦公軟件產品$20,000系統開發總費用$161,670*

B.年運行費用（每年）人員：維護程序員/分析員（250小時/年，42美元/小時）$10,500網絡管理員（3000小時/年，50美元/小時）$15,000購買硬件、軟件升級：硬件―$5,000軟件―$6,000物資和雜項：$3,500每年總運行費用$40，000*

一、開發成本估計技術（3)3、自動估計成本技術采用自動估計成本的軟件工具，需要有長期搜集的大量歷史數據為基礎，并需要良好的數據庫系統支持。二、運行費用估計取決于系統的操作費用（操作人員數、工作時間、消耗的物資等）和維護費用。*

6.2成本／效益分折方法成本／效益分折的第一步是估計開發成本、運行費用和新系統將帶來的經濟效益。系統的經濟效益等于因使用新系統而增加的收入加上使用新系統可以節省的運行費用。比較新系統的開發成本和經濟效益，以便從經濟角度判斷這個系統是否值得投資。*

6.2成本／效益分折方法

幾種度量效益的方法

1.貨幣的時間價值：以銀行利率表示貨幣的時間價值。假設年利率為i，如果現在存入P元，則n年后可以得到的錢數為：F=P(1+i)n如果n年后能收入F元錢，那么這些錢的現在價值是：P=F/(1+i)n提問：若某系統，投資為200萬元，銀行利率3%，即100元可獲3元現金，一年后此系統運行賺了200萬元，是否可以認為所有投資都收回了？*

設年利率是5%，引入CAD后，每年預計節省的錢的現在價值。年份將來值（1+I)n現在價值累計現在價值19.61.059.14299.142929.61.10258.707517.851339.61.15768.292826.143249.61.21557.897934.041159.61.27637.521941.5630例：在工程設計中用CAD系統取代大部分人工設計工作，每年可節省9.6萬元。若軟件生存期為5年，則5年節省48萬元。開發CAD系統共投資了20萬元。*

§6.2成本／效益分折方法投資回收期：累計的經濟效益等于最初的投資所需要的時間。CAD投資回收期是：2+2.15/8.29=2.259年純收入：整個軟件生命期內，累計經濟效益（折合成現在值）與投資之差。如：引入CAD系統之后，5年內工程的純收入預計是41.563-20=21.563投資回收率:

指系統的投資在生命周期內達到的累計效益的利率。*

附：可行性研究報告（參考格式）*

可行性研究報告（參考格式）*

可行性研究報告（參考格式）*

軟件工程03章需求分析第三章軟件需求分析3.1需求分析的任務3.2與用戶溝通獲取需求的方法3.3分析建模與規格說明3.4實體一聯系圖3.5數據規范化

3.6狀態轉換圖3.7其他圖形工具3.8驗證軟件需求3.9小結習題*

教學要求教學目的：了解需求分析的任務和步驟、評審標準和過程；掌握基本技術，理解需求規格說明書的作用與組成。教學重點：基本技術、需求規格說明書的作用與組成。教學難點：基本技術。*

需求分折簡介

軟件需求指用戶對所開發的軟件在功能、性能、環境、可靠性等各方面的要求。需求分析主要回答待開發的系統必須“做什么”，并用《需求規格說明書》的形式準確、詳細、規范地表達出來。*

注意①需求分析階段，系統分析員的主要關注點是“做什么（what)”，不是“怎樣做（how）”；②需求分析階段，系統分析員應該給出軟件求規格書。*

§3.1需求分析的任務四項主要任務：1、確定對系統的綜合要求2、分析系統的數據要求3、導出系統的邏輯模型4、修正系統開發計劃*

提問并思考：

如果你是一個用戶，你會對將要開發的軟件有哪些要求？*

§3.1.1確定對系統的綜合要求①功能需求。指定系統必須提供的服務。

②性能需求。指定系統必須滿足的定時約束或容量約束等。

③可靠性和可用性需求。應定量指定。

④出錯處理需求。指環境錯誤，非系統本身的錯誤。

⑤接口需求。常見的接口需求：用戶接口需求；硬件接口需求；軟件接口需求；通信接口需求。

*

⑥約束。常見的約束：精度；工具和語言約束；設計約束；應該使用的標準；應該使用的硬件平臺。⑦逆向需求。指定系統不應該做什么，⑧將來可能提出的要求。*

§3.1.2分析系統的數據要求提問并思考：如果你是設計者，除了上述需求以外，你覺得還需要得到哪些要求？答：軟件系統本質上是信息處理系統，要考慮數據和數據處理的問題。*

對系統數據的分析建立數據(3.4節）;描繪數據結構(3.7節）;規范化（3.5節）*

§3.1.3導出系統的邏輯模型

用數據流圖、實體一聯系圖、狀態轉換圖、數據字典和主要的處理算法描述這個邏輯模型。

§3.1.4修正系統開發計劃根據在分析過程中獲得的對系統的更深入更具體的了解，可以比較準確地估計系統的成本和進度，修正以前制定的開發計劃。*

圖:軟件需求分析的通信途徑分析小組成員主要包括領域專家、系統分析員；客戶訪談問題分析與確認*

與用戶溝通的方法1、訪談2、面向數據流自頂向下求精3、簡易的應用規格說明技術4、快速建立軟件原型*

§3.2.1訪談分正式和非正式訪談。可采用調查表形式可使用情景分析技術*

例：某出版社系統調查表編號提出問題1您在哪個部門工作？每日都處理哪些文件、數據、報表？2出版業務流程是什么？3工作中手工處理特別麻煩的事情是什么？4手工處理有什么問題解決不了？影響效率的問題有哪些？5您認為提高工作效率，節省工作時間，減輕工作強度可采取哪些辦法？6您的部門需要成本核算和統計的內容有哪些？7您的部門采用計算機管理工作情況如何？8如何改進業務流程使之更合理？9哪些問題是目前傳統手工方法根本無法解決的？10出版社計算機管理信息系統需要解決什么問題？*

§3.2面向數據流自頂向下求精

結構化分析方法的實質。進一步細化可行性研究階段獲得到高層數據流圖。包括建立：詳細的數據流圖，描繪數據在軟件系統內從輸入移動到輸出的過程中所經受到變換；數據字典：定義數據流圖中包含的元素；實體關系（ER）圖：從用戶角度描述數據；IPO圖：描述數據流圖中處理框的功能和算法。*

面向數據流自頂向下求精過程*

§3.2.3簡易的應用規格說明技術

一種面向團隊的需求收集法，提倡用戶與開發者密切合作，共同標識問題，提出解決方案要素，商討不同方案并指定基本需求。具體過程見教材P60面提問：此方法將產生什么樣的產品？*

§3.2.4快速建立軟件原型快速原形就是快速建立起來的旨在演示目標系統主要功能的可運行的程序。要點：實現用戶看得見的功能，省略目標系統“隱含”功能。*

§3.2.4快速建立軟件原型

建立和修改原型的方法和工具：(1)第四代技術。包括眾多數據庫查詢和報表語言、程序和應用系統生成器以及其他非常高級的非過程語言。能快速生成可執行的代碼。(2)可重用的軟件構件。使用一組已有的軟件構件（也稱為組件）來裝配（而不是從頭構造）原型。(3)形式化規格說明和原型環境。在交互式環境下，用自動工具把基于形式語言的規格說明翻譯成可執行的程序代碼。*

§3.3分析建模與規格說明§3.3.1分析建模什么是模型？為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的書面描述。模型通常由一組圖形符號和組織這些符號的規則組成。*

模型的作用在建模過程中了解系統。通過抽象降低復雜性。有助于回憶所有的細節。有助于開發小組間的交流。有助于與用戶的交流。為系統的維護提供文檔*

例：結構化分析方法建立的需求模型

結構化分析（StructuredAnalysis,SA）是面向數據流進行分析的方法，主要建立以下幾種模型：實體關系圖(Entity-RelationshipDiagram,E-R圖)來創建數據模型，描述系統中所有重要的數據對象；

數據流圖（DataFlowDiagram,DFD）：用來創建功能模型，描述了信息流和數據轉換。

狀態轉換圖（State-TransitionDiagram,STD）用來創建行為模型，描述系統狀態如何響應外部事件，而進行轉換。*

例：面向對象分祈方法（OOA）所建立的摸型對象模型(Objectmodel)：定義實體，描述系統的靜態結構，定義“對誰做”動態模型(Dynamicmodel):描述對象之間的交互過程，規定“何時做”功能模型作(Functionalmodel)：描述內部數據的處理，指明系統應“做什么”*

軟件需求規格說明《軟件需求規格說明書》是需求分析階段最主要的文檔。對目標進行完善和補充，并寫出完整的需求說明。為消除自然語言中可能存在的不一致、歧義、含糊、不完整及抽象層次混亂等問題，有主張用形式化方法描述用戶對軟件系統的需求。

例:GB8567-88計算機軟件產品開發文件編制指南*

結構化分析方法（StructuredAnalysis,SA)面向數據流進行需求分析的方法適合于數據處理類型軟件的需求分析*

結構化分折模型的組成結構*

§3.4實體一聯系圖

實體一聯系圖（E一R圖）描繪系統的數據關系。分析實體一聯系有助于對業務或系統數據組成的理解和交互。

一、基本概念（1)

實體：客觀世界中存在的，可區分的事物。數據對象：實體在數據模型中的體現，能由一組屬性來定義的實體都可以被認為是數據對象。

屬性：實體或數據對象所具有的性質。*

一、基本概念(2)聯系：客觀事物之間的聯系。聯系分為三種：一對一（1:1)．一對多聯系（1:N)．多對多聯系（M:N)二、E一R圖的結構三種基本元素：*

例:教學E-R圖*

三、如何建立實體一聯系圖？1、在需求收集的過程中，列出應用軟件或業務過程涉及到的所有“事物”，將其演化成數據對象；2、一次考慮一個對象，定義這個對象和其他對象之間是否存在連接；3、如果存在連接，應創建一個或多個關系；4、對每一個關系，確定其關聯類型；5、重復步驟（2）到步驟（4)，直到定義了所有關系。6、定義每個實體的屬性；7、形式化并復審實體關系圖；8、重復步驟（1）到（7)，直到數據建模完成。*

2.4數據流圖(DFD,DataFlowDiagram)描述數據處理過程的工具。通過圖形的方法，從數據傳遞和數據處理的角度，刻畫數據流從輸入到輸出的移動變換過程。數據流三個重要屬性：．數據流名字．數據組成．流向*

2.4.1符號（1）說明：用圖形符號以黑盒子形式描繪組成系統的每個部件（程序，文檔，數據庫，人工過程等），表達數據在系統各部件之間流動的情況。*

符號（2）

*

例1：描述銀行取款過程的數據流圖*

應該注意的幾個問題適當地命名。（詳見教材p45)“數據存儲”代表數據靜止狀態，“數據流”代表數據的運動狀態；注意數據流與控制流的區別；通常數據流圖中忽略出錯處理、打開或關閉文件之類的內務處理。若數據的源點和終點相同，則應該有兩個箭頭和這個數據源（終）點相連；或重復畫一個源（終）點。*

數據流圖的層次結構

對于大型系統，往往采用自頂向下逐層分解的方法，用分層數據流圖表示所有數據流和加工。對任何一個數據流圖來說，它的上層圖為父圖，在它的下一層的圖為子圖。*

分層數據流圖*

說明：在多層數據流圖中，頂層流圖僅包含一個數據處理，它代表被開發系統。它的輸入流是該系統的輸入數據，輸出流是系統所輸出數據底層流圖是指其數據處理不需再做分解的數據流圖，它處在最底層中間層流圖則表示對其上層父圖的細化。它的每一數據處理可能繼續細化，形成子圖。*

注意的原則(1)

數據流圖上所有圖形符號只限于前述四種基本圖形元素；數據流圖的主圖必須包括前述四種基本元素，缺一不可；數據流圖的主圖上的數據流必須封閉在外部實體之間；每個數據處理至少有一個輸入數據流和一個輸出數據流；在數據流圖中，需按層給數據處理框編號。編號表明該處理所處層次及上下層的親子關系；*

注意的原則(2)規定任何一個數據流子圖必須與它上一層的一個數據加工對應，兩者的輸入數據流和輸出數據流必須一致。此即父圖與子圖的平衡；可以在數據流圖中加入物質流，幫助用戶理解數據流圖；圖上每個元素都必須有名字；數據流圖中不可夾帶控制流；初畫時可以忽略瑣碎的細節，以集中精力于主要數據流*

例2：結構化分析方法步驟示例商場業務處理系統假設某商場的經營業務。商場進貨時，先發訂貨單給供應商，供應商收到訂貨單，將商品發給商場，商場貨到付款，供應商收款后，將收據發給商場；當顧客到商場采購商品時，先下購物訂單，商場查詢庫存中是否有此種商品，若有則發貨給顧客；若沒有，則向供應商訂貨，貨到之后再銷售給顧客；顧客收到貨物之后付款，商場開收據給顧客；商場對貨物的管理方面要求知道每種貨物詳細的銷售情況。*

分析業務流程:訂貨過程*

分析業務流程:采購過程*

第一步：繪制頂層數據流圖（1)基本思想，任何計算機系統都是有若干個數據源(終)點加上一個事務處理組成。首先從問題的描述中提取數據流圖中的源（終）點、數據處理、數據流和數據存儲四種成份。．分析源（終）點．.分析數據處理．分析數據流和數據存儲*

分析數據源點和終點：如果將商場的購、銷業務系統看成一個整體，則外部的與這個系統有交往的對象（機構、人員、或外部系統）是“供應商，和“顧客”，二者是商場購銷系統源點和終點。*

分析源點、終點與商場之間的數據流數據流方向分別是：供應商方給商場：發貨單、貨款收據顧客給商場：訂單、貨款商場給供貨商：訂貨單、貨款商場給顧客：貨物、收據*

分析數據存儲:需要存儲的數據分別是庫存信息暫存訂單(缺貨訂單)采購訂單商品銷售歷史資金帳目*

第一步：繪制頂層數據流圖(2)*

第一步：繪制頂層數據流圖（3)第一步：繪制頂層數據流圖（3)*

第二步：將頂層數據流圖細化經過分析，商店業務處理的主要數據處理是銷售、采購、會計三大數據處理，三者之間的數據流：*

需要存儲的數據有：*

*

DFD/L2.2(采購細化)*

DFD/L2.1(銷售細化)*

2.5數據詞典（DD,datadictionary)DD是對數據流圖中包含的所有元素的定義的集合，使得每個圖形元素的名字都有一個精確的、嚴格的定義。數據流圖和詞典結合在一起，能清楚地表達數據處理的要求，構成了“需求說明書”*

2.5.1數據字典的內容主要描述數據流數據元素數據存儲數據處理*

2.5.2定義數據的方法*

1、定義數據流數據流名：說明：簡要介紹作用即它產生的原因和結果。數據流來源：來自何方。數據流去向：去向何處。數據流組成：數據結構。數據量流通量：數據量，流通量*

舉例：*

數據流定義：*

2、定義數據元素數據元素（數據項）指數據處理中最小的，不可再分的單位。描述包括：數據元素名：類型：數字（離散值，連續值），文字（編碼類型）長度：取值范圍：相關的數據元素及數據結構：*

數據元素定義舉例（1)*

數據元素定義舉例（2)*

數據元素定義舉例（3)*

數據元素定義舉例（4)*

3、定義數據存儲數據文件名：簡述：存放的是什么數據輸入數據：輸出數據:數據文件組成：數據結構存儲方式：順序，直接，關鍵碼存取頻率：*

數據存儲定義舉例（1)*

*

*

4、定義數據處理數據處理定義舉例（1)*

數據處理定義舉例（2)*

*

加工邏輯詞條說明舉例（3)*

⑤源點及匯（終）點詞條描述名稱：外部實體名簡要描述：什么外部實體有關數據流：數目：*

3.5數據規范化1、第一范式每個屬性值都必須是原子值。2、第二范式滿足第一范式條件，而且每個非關鍵字屬性都由整個關鍵字決定。3、第三范式符合第二范式的條件，每個非關鍵字屬性都僅由關鍵字決定，而且一個非關鍵字屬性不能僅僅是對另一個非關鍵字屬性的進一步描述。范式低，冗余大，范式高，分解得細，冗余小，但處理過程復雜。*

3.6狀態轉換圖（STD)為了直觀地分析系統的動作，從特定的視點出發描述系統的行為，需要采用動態分析的方法。狀態轉換圖是一種常用的動態分析方法。是描述系統的狀態如何響應外部信號，而進行轉換的一種圖形表示。*

3.6.1狀態指任何可以被觀察到的系統行為模式，一個狀態代表系統的一種行為模式。主要有：初態、終態和中間狀態。一個狀態圖中，只能有一個初態，但可以有0~多個終態。*

3.6.2事件某個特定時刻發生的事情，它是對引起系統做動作或（和）從一個狀態轉換到另一個狀態的外界事情的抽象.*

3.6.3狀態轉換圖符號活動表語法：事件名（參數表）／動作表達式常用事件名：Entry、Exit、Do動作表達式：應做的具體動作事件表達式：觸發狀態轉換的事件。語法：事件說明[守衛條件]／動作表達式。其中，事件說明的語法：事件名（參數表）。*

電話系統的狀態圖電話系統的狀態圖電話系統的狀態圖*

3.7其他圖形工具3.7.1層次方框圖*

3.7.2Warnier圖*

3.7.3IPO圖*

3.8驗證軟件需求問：從哪些方面驗證軟件需求的正確性？如何驗證？1、一致性自然語言書寫的需求說明，只能用人工方法驗證；形式化方法定義的可以借助驗證工具（3.8.3節）2、完整性需要用戶參與、合作；建立快速原型。3、現實性參照以往類似系統；進行真或性能模擬4、有效性*

用于需求分析的軟件工具對采用形式化方法定義的需求進行驗證的工具。應該滿足下列要求：

(1）必須有形式化的語法（或表），因此可以用計算機自動處理使用這種語法說明的內容；(2）使用這個軟件工具能夠導出詳細的文檔；(3）必須提供分析（測試）規格說明書的不一致性和冗余性的手段，并且應該能夠產生一組報告指明對完整性分析的結果。(4）使用這個軟件工具之后，應該能夠改進通信狀況。如：在1977年設計完成的RSL（需求陳述語言）。1977年美國密執安大學開發了PSL/PSA（問題陳述語言／問題陳述分析程序）系統。*

*

比較完整的數據流圖例子例：教務管理系統某校準備開發一個學生成績管理系統。在該系統中，教務人員錄入學生信息、課程信息和成績信息，學生可以隨時查詢自己所選課程的成績。由于學生成績屬于敏感信息，系統必須提供必要的安全措施以防非法存取*

0層DFD分析：源點終點：教務人員（源點）；學生（終點）數據處理：將系統當成一個整體“學生成績管理”數據流：學生信息、課程信息和成績；（教務人員錄入時）查詢請求、查詢結果（學生查詢時）數據文件：成績文件、學生文件、課程文件。*

＊第0層DFD圖教務人員維護學生信息和課程信息，并登錄學生的選課成績；學生查詢自己的成績單。*

第1層DFD說明“學生信息”是教務人員需要錄入的一個信息，因此加入一個加入“錄入學生信息”;同樣得到“錄入課程信息”、“登記成績”兩個數據處理。另外，數據流“查詢請求”和“查詢結果”應該由數據處理“查詢成績”來完成。*

第1層DFD說明對第0層DFD的加工“學生成績管理“進行展開。數據處理：錄入學生信息錄入課程信息登記學生成績查詢學生成績數據存儲：增加這些數據流對應的數據存儲，即“學生”、“課程”和“成績”，最后得到如圖所示的第1層DFD。*

第1層DFD圖：對第0層DFD的一個“學生成績管理“進行展開。*

第2層DFD說明繼續分解第1層DFD中的加工“查詢學生成績”數據處理：分解為“合法性檢查”和“查詢成績”數據文件：合法的查詢條件*

*

＊部分數據字典*

*

軟件工程第五章總體設計第五章總體設計5.1設計過程5.2設計原理5.3啟發規則5.4描繪軟件結構的圖形工具

5.5面向數據流的設計方法5.6小結習題*

學習要求掌握：1、軟件設計過程中應遵循的基本原理和相關概念；2、描繪軟件結構的圖形工具的運用；3、面向數據流設計方法概念；變換分析、事務分析法過程和應用。理解：1、典型的總體設計過程包括的步驟；2、設計中的啟發式規則；*

重點和難點重點:軟件設計過程中應遵循的基本原理；面向數據流的設計方法難點:變換分析、事務分析法的過程和應用*

軟件設計的目標和任務軟件需求：解決“做什么”軟件設計：解決“怎么做”．軟件設計的任務：以軟件需求規格說明書為依據，著手實現軟件的需求，并將設計的結果反映在“設計規格說明書”文檔中。軟件設計的重要性：是軟件開發階段的第一步，最終影響軟件實現的成敗和軟件維護的難易程度。*

軟件設計的兩個階段第一階段：概要設計（總體設計）根據軟件需求，設計軟件系統結構和數據結構，確定程序的組成模塊及模塊之間的相互關系。回答“概括地說，系統應該如何實現？”。其重要性是：站在全局高度，從較抽象的層次上分析對比多種可能的系統實現方案和軟件結構，從中選出最佳方案和最合理的軟件結構，從而用較低成本開發出較高質量的軟件系統。*

軟件設計的兩個階段第二階段：詳細設計（過程設計）確定模塊內部的算法和數據結構；選定某種過程的表達形式來描述各種算法；產生精確描述各模塊程序過程的詳細文檔，并進行評審。*

將需求分析摸型轉換為軟件設計軟件結構設計以需求分析中得到的數據流圖為基礎而進行。*

SA與SD的關系*

第一個階段總體設計的任務①制定規范②設計軟件系統結構（簡稱軟件結構）③處理方式設計④數據結構及數據庫設計⑤可靠性設計⑥編寫概要設計文檔

⑦概要設計評審*

①制定規范為軟件開發小組制定在進行軟件設計，應該共同遵守的標準，以便協調組內各員的工作。*

②軟件結構設計包括：將系統按功能劃分成模塊確定每個模塊的功能確定模塊之間的調用關系確定模塊之間的接口，即模塊之間傳遞的信息評價模塊結構的質量*

③處理方式設計包括：功能設計：確定實現功能法，評估算法的性能．性能設計：確定實現性能需求必須的算法和模塊間的控制方式*

5.1設計的過程*

5.2設計原理5.2.1模塊化5.2.2抽象5.2.3逐步求精5.2.4信息隱蔽和局部化5.2.4模塊獨立*

5.2.1模塊化(Modularity)①什么是模塊和模塊化思想？采取自頂向下的方式，逐層把軟件系統劃分成若干可單獨命名和可編址的部分－“模塊”，每個模塊完成一個特定的子功能；所有模塊按某種方法組成一個整體，完成整個系統所要求的功能。軟件系統就是通過這些模塊的組合來實現。*

②模塊化的優點模塊化是軟件解決復雜問題所具備的手段，可降低軟件復雜性，減少開發工作量，從而降低開發成本，提高軟件生產率，是模塊化的依據。*

③模塊化與軟件成本的關系接口*

④模塊的基本屬性接口：指模塊的輸入與輸出。功能：指模塊實現什么功能。模塊化好處:模塊化使軟件容易測試和調試，因而有助提高軟件的可靠性。模塊化能提高軟件的可修改性。模塊化有助于軟件開發工程的組織管理。*

5.2.2抽象（Abstraction)①什么是抽象？認識復雜事物和現象時，抽出事物本質的共同特性而暫不考慮它們的細節。②軟件開發中的抽象過程的抽象數據的抽象宜賓學院計算機學院08級學生宜賓學院計算機學院學生宜賓學院*

抽象什么是抽象思想?在認識事物、分析和解決問題的過程中，忽略那些與當前研究目標不相關的部分,以便將注意力集中于與當前目標相關的方面軟件開發實際上就是一個從高層次抽象到低層次抽象逐步過渡的過程。一個復雜的系統先用一些高級的抽象概念構造和理解，這些高級概念又用較低級的概念構造和理解，如此進行下去，直到具體元素。*

形體衣著性格抽象抽象例子外表*

5.2.3逐步求精逐步求精：為了能集中精力解決主要問題而盡量推遲對問題細節的考慮。可把逐步求精看作是一項把一個時期內必須解決的種種問題按優先級排序的技術。逐步求精是一種自頂向下的設計策略，按這種設計策略，程序的體系結構是通過逐步精化處理過程的層次而設計出來的。*

逐步求精外表形體衣著性格頭發臉形領帶抽象逐步求精的例子*

自頂向下，逐步求精的基本思想將功能、信息的說明分為多個層次，最高層也最抽象―僅僅只是概念性地描述功能或信息，不提供功能的內部工作情況或信息的內部結構；設計者從最高層開始，仔細推敲，進行功能和信息的細化，給出下層實現的細節；隨著每個后續細化逐步的完成，提供越來越多的細節，最終得出用程序設計語言表達的程序。*

結合了模塊化和逐步細化思想建立的軟件結構圖*

5.2.4信息隱蔽和局部化信息隱蔽：在設計和確定模塊時，使得一個模塊內包含的信息（過程或數據），不允許其它不需要這些信息的模塊訪問，獨立的模塊間僅僅交換為完成系統功能而必須交換的信息。局部化：將一些關系密切的軟件元素物理地放得彼此靠近。*

5.2.5模塊獨立1、什么是模塊獨立性（moduleindependence)模塊只完成系統要求的相對獨立的功能符合信息隱蔽原則模塊間關聯和依賴程度盡量小2、模塊獨立的優點容易開發、測試和維護*

3、衡量模塊獨立性的兩個準則①耦合性（coupling)②內聚性（cohesion)*

①耦合性（coupling)也稱塊間的聯系。是對軟件系統結構中，各模塊間相互聯系緊密程度的一種度量。設計目標：低耦合*

無直接藕合兩個模塊沒有直接關系，模塊獨立性最強。*

數據耦合屬松散耦合。一模塊訪問另一模塊時，通過數據參數交換輸入、輸出信息。*

控制藕合模塊之間傳遞的是控制信息（如開關、標志、名字等），控制被調用模塊的內部邏輯。*

控制耦合舉例*

去除模塊間控制耦合的方法控制藕合增加了理解和編程的復雜性，調用模塊必須知道被調模塊的內部邏輯，增加了相互依賴。解決方法：

(1）將被調用模塊內的判定上移到調用模塊中進行(2）被調用模塊分解成若干單一功能模塊*

改控制藕合為數據藕合舉例*

特征耦合兩個模塊通過傳遞數據結構加以聯系，或都與一個數據結構有關系，則稱這兩個模塊間存在特征耦合。可能出現的情況：當把整個數據結構作為參數傳遞時，被調用的模塊雖然只需要使用其中的一部分數據元素，但實際可以使用的數據多于它真正需要的數據，這將導致對數據訪問失去控制，*

特征耦合舉例*

將特征耦合修改為數據耦合舉例*

公共環境耦合一組模塊引用同一個公用數據區（也稱全局數據區、公共數據環境）。公共數據區指：全局數據結構。共享通訊區。內存公共覆蓋區等*

公共環境耦合舉例模塊A、B、C間存在錯綜復雜的聯系*

公共耦合存在的問題(1）軟件可理解性降低(2）診斷錯誤困難(3）軟件可維護性差

(4）軟件可靠性差*

內容耦合有下列情況之一的。是最不好的耦合形式！*

模塊間耦合強度*

耦合強度依賴的因素：一模塊對另一模塊的引用一模塊向另一模塊傳遞的數據量一模塊施加到另一模塊的控制的數量模塊間接口的復雜程度*

降低耦合度的設計原則1、根據問題特點，選擇合適的耦合類型。盡量使用數據耦合，少用控制耦合和外部耦合，限制公共耦合的范圍，完全不用內容耦合2、降低模塊接口的復雜性。減少每個模塊的參數個數；盡量使用標準過程調用方式，少用直接引用的方式；傳送的信息以標準、直接的方式提供。3、把模塊的通信信息放在緩沖區中。*

②內聚性（cohesion)又稱塊內聯系。指一個模塊內部各個元素彼此結合的緊密程度的度量。若一個模塊內各元素（語句之間、程序段之間）聯系的越緊密，則它的內聚性就越．設計目標：高內聚*

巧合內聚（偶然內聚)塊內各組成成份在功能上是互不相關的。模塊M

中的三個語句沒有任何聯系。缺點：可理解性差，可修改性差*

邏輯內聚把幾種相關功能（邏輯上相似的功能）組合在一模塊內，每次調用由傳給模塊的參數確定執行哪種功能。*

邏輯內聚模塊*

時間內聚（經典內聚）模塊完成的功能必須在同一時間內執行，這些功能只因時間因素關聯在一起。例：初始化系統模塊系統結束模塊、緊急故障處理模塊等*

過程內聚（順序性組合）模塊內各處理成分相關，且必須以特定次序執行。*

通信內聚模塊內各部分使用相同的輸入數據，或產生相同的輸出結果*

順序內聚模塊完成多個功能，各功能都在同一數據結構上操作，每一功能有唯一入口。*

功能內聚模塊僅包括為完成某個功能所必須的所有成分。模塊所有成分共同完成一個功能，缺一不可內聚性最強*

模塊間內聚的類型*

總結：耦合、內聚與模塊獨立性關系耦合與內聚都是模塊獨立性的定性標準，都反映模塊獨立性的良好程度。但耦合是直接的主導因素，內聚則輔助耦合共同對模塊獨立性進行衡量。設計要求：低耦合，高內聚*

5.3啟發規則改進原則：高內聚、低耦合①改進軟件結構，提高模塊獨立性②模塊規模適中③深度、寬度、扇出和扇入適中④將模塊的影響限制在控制范圍內⑤降低模塊接口的復雜性⑥設計單入口單出口的模塊⑦模塊功能可預測*

①改進軟件結構，提高模塊獨立性通過模塊分解或合并，降低耦合提高內聚*

②模塊規模適中模塊過大：可理解程度下降模塊過小：開銷大于有效操作系統接口復雜在考慮模塊的獨立性同時，為了增加可理解性，模塊的大小最好在50一150條語句左右，可以用1一2頁打印紙打印，便于人們閱讀與研究。*

③深度、寬度、扇出和扇入適中軟件結構度量術語*

例：避免平鋪結構*

增加中間層降低扇出*

作用域是指受模塊內一個判定影響的所有模塊的集合控制域是指這個模塊本身及其所有的下屬模塊的集合④將模塊的影響限制在控制范圍內*

模塊C的控制范圍：C、D、E、F、G、H。如果模塊C作