1、整理者：南京農業大學 戚愛靜第一章 概論一 計算機軟件定義：計算機系統中的程序及其文檔。程序：計算任務的處理對象和處理規則的描述。處理對象：數據或信息。 處理規則：一般指處理的動作和步驟。文檔：為了便于了解程序所需的闡述性資料。發展：1946-1956年：從計算機問世到實用的高級程序語言出現前；1956-1968年：從實用的高級程序語言出現到軟件工程出現前（出現軟件危機）；1968年-至今：從軟件工程出現到現在。軟件危機：許多軟件項目不能滿足客戶的要求；許多軟件項目超出預算和時間安排。表現：1）對軟件開發成本和進度的估計常常很不正確；2）用戶對“已完成的”軟件系統不滿意的現象經常發生；3）軟件

2、產品的質量往往靠不住；4）軟件常常是不可維護的；5）軟件通常沒有適當的文檔資料；6）軟件成本在計算機系統總成本中所占的比例逐年上升；7）軟件開發生產率提高的速度遠遠跟不上計算機應用迅速普及深入的趨勢。原因：1）軟件是邏輯產品，開發進度、成本難以估計；2）缺乏或不完整、不一致的文檔給維護帶來困難；3）用戶對軟件需求的描述往往不夠精確，有遺漏，有二義；4）軟件開發人員對需求的理解與用戶的本來愿望有差異；5）大型軟件項目需多人協同完成，缺乏管理經驗；6）開發人員不能有效地、獨立自主地處理大型軟件的全部關系；7）缺乏有力的方法學和工具的支持；8）軟件項目的特殊性和人類智力的局限性。克服：1）消除錯誤的

3、概念和做法；2）推廣使用成功的開發技術和方法；3）使用軟件工具和軟件工程支持環境；4）加強軟件管理。軟件的特點（與硬件相比）：1） 軟件是一種邏輯實體，而不是有形的系統元件，其開發成本和進度難以準確地估算。2） 軟件是被開發的或被設計的，沒有明顯的制造過程，一旦開發成功，只需復制即可，但其維護的工作量大。3） 軟件的使用沒有硬件那樣的機械磨損和老化問題。故障曲線：軟件的分類：1） 系統軟件：位于計算機系統中最靠近硬件的一層，其它軟件一般都通過系統軟件發揮作 用，它與具體的應用領域無關（如操作系統、編譯程序等）。2） 支撐軟件：支持軟件開發和維護的軟件（如數據庫管理系統、網絡軟件、軟件開發環境）

4、。3） 應用軟件：特定應用領域專用的軟件（如實時軟件、嵌入式軟件、科學和工程計算軟件、 事務處理軟件、人工智能軟件等）。軟件語言：書寫計算機軟件的語言。1） 需求定義語言：書寫軟件需求定義（功能需求和非功能需求），做什么（如PSL、PSA）。2） 功能性語言：書寫軟件功能規約語言。外部功能做什么（如廣譜語言、Z語言）。 （軟件功能規約是軟件所要完成功能的精確而完整的陳述。）3） 設計性語言：書寫軟件設計規約。如何做（如PDL）。 （設計規約是軟件設計的嚴格而完整的陳述，是功能規約的算法性細化。）4） 實現性語言：用于書寫計算機程序的語言，也稱編程語言或程序設計語言。分類：按語言級別可分為低級語

5、言和高級語言； 按用戶要求可分為過程式語言和非過程式語言； 按應用范圍可分為通用語言和專用語言； 按使用方式可分為交互式語言和非交互式語言； 按成分性質可分為順序語言、并發語言、分布語言。5） 文檔語言：用于書寫軟件文檔的語言。二、軟件工程定義：軟件工程是應用計算機科學、數學及管理科學等原理，開發軟件的工程。軟件工程借鑒傳統工程的原則、方法，以提高質量、降低成本為目的。軟件工程框架：1） 目標：生產具有正確性、可用性以及開銷合宜的產品。2） 過程：指生產一個最終滿足需求且達到工程目標的軟件產品所需要的步驟。3） 原則：選取適宜的開發模型；采用合適的設計方法；提供高質量的工程支持；重視軟件工程的

6、管理。軟件生存周期（6個階段）：1） 計算機系統工程：確定待開發軟件的總體要求和范圍，以及它與其它計算機系統元素之間的關系；進行成本估算，做出進度安排；進行可行性分析。2） 軟件需求分析：做什么。確定軟件的功能、數據、界面等要求，生成軟件需求規約。3） 軟件設計：怎么做。系統設計：設計軟件系統的體系結構；詳細設計：設計各個組成成分的實現細節。4） 編碼：用某種程序設計語言，將設計的結果轉換為可執行的程序代碼。5） 測試：發現并糾正軟件中的錯誤和缺陷（包括單元測試、集成測試、確認測試和系統測試）。6） 運行和維護：當發現了軟件中潛藏的錯誤或需要增加新的功能或使軟件適應外界環境的變化等情況出現時對

7、軟件進行修改。三、軟件過程模型定義：軟件開發全部過程、活動和任務的結構框架。瀑布模型：給出了軟件生存周期活動的固定順序，上一階段的活動完成后向下一階段的活動過渡，最終得到所開發的軟件產品。特征：1）接受上一階段的結果作為本階段的輸入；2）利用這一輸入實施本階段應完成的活動；3）對本階段的工作進行評審；4）將本階段的結果作為輸出，傳遞給下一階段。缺點：1）缺乏靈活性，難以適應需求不明確或需求多變的軟件開發；2）問題往往要到交付使用時才發現，維護代價大。演化模型：在獲取了一組基本的需求后，通過快速分析構造出該軟件的一個初始可運行版本，稱之謂原型，然后該用戶在試用原型的過程中提出的意見和建議、或者增

8、加新的需求，對原型進行改造，獲得原型的新版本，重復這一過程，最終得到令客戶滿意的軟件產品。（適用于對軟件需求缺乏準確認識的情況。）1、 增量模型：將軟件的開發過程分成若干個日程時間交錯的線性序列，每個線性序列產生軟件的一個可發布的“增量”版本，后一個版本是對前一版本的修改和補充，重復增量發布的過程，直至產生最終的完善產品，（強調每一個增量都發布一個可運行的產品）。適用于：1）需求經常變化的軟件開發；2）市場急需而開發人員和資金不能在設定的市場期限之前實現一個完善的產品的軟件開發。（能有計劃的管理技術風險。）2、 原型模型：從軟件工程師與客戶的交流開始，其目的是定義軟件的總體目標，標識需求。然后

9、快速制訂原型開發的計劃，確定原型的目標和范圍，采用快速設計的方式對其建模，并構建原型交付給客戶試用，并收集客戶的反饋意見，這些反饋意見可在下一輪迭代中對原型進行改進。在前一個原型需要改進，或者需要擴展其范圍的時候，進入下一輪原型的迭代開發。根據使用原型的目的不同，原型可分為：1） 探索型：目的是要弄清目標系統的要求，確定所希望的特性，并探討多種方案的可行性。2） 實驗型：目的是驗證方案或算法的合理性，在大規模開發和實現前，用于考核方案是否合適，規格說明是否可靠。3） 演化型：目的是將原型作為目標系統的一部分，通過對原型的多次改進，逐步將原型演化成最終的目標系統。原型使用策略：1） 廢棄策略：主

10、要用于探索型和實驗型原型的開發。2） 追加策略：主要用于演化型原型的開發。3、 螺旋模型：是瀑布模型和演化模型的結合，并增加了風險分析。四個象限活動：制定計劃；風險分析；工程實施；客戶評估。噴泉模型：一種支持面向對象開發的模型（體現迭代和無間隙特征）。（迭代：開發活動需要多次重復。 無間隙：開發活動之間不存在明顯的邊界。）四、CASE工具與環境計算機輔助軟件工程（CASE）：在軟件工程活動中，軟件工程師和管理人員按照軟件工程的方法和原則，借助于計算機及其軟件工具的幫助，開發、維護、管理軟件產品的過程。軟件工具：用來輔助計算機軟件的開發、運行、維護、管理、支持過程中的活動或任務的軟件。集成型開發

11、環境：一種把支持多種軟件開發方法和過程模型的軟件工具集成到一起的軟件開發環境（由工具集和環境集成機制組成）。環境集成機制：1） 數據集成：為各種相互協作的工具提供統一的數據接口規范。2） 界面集成：持工具界面的集成和應用系統的界面開發，統一界面風格。3） 控制集成：支持各個工具或開發活動之間的通信、切換、調度和協同工作，并支持軟件開發過程的描述、執行與轉接。4） 方法與過程集成5） 平臺集成第二章 系統工程一、 基于計算機的系統定義：通過處理信息來完成某些預定義目標而組織在一起的元素的集合。組成元素：軟件、硬件、人員、數據庫、文檔和規程二、 系統工程的任務1、 識別用戶的需求：標識系統的功能和

12、性能范圍，確定系統的功能、性能、約束和接口。2、 系統建模和模擬：硬件系統模型、軟件系統模型、人機接口模型、數據模型。3、 成本估算及進度安排4、 可行性分析：從經濟、技術、法律等方面分析所給出的解決方案是否可行。5、 生成系統規格說明三、 可行性分析定義：主要從經濟、技術、法律等方面分析所給出的解決方案是否可行，能否在規定的資源和時間的約束下完成。1、 經濟可行性：1） 成本：購置硬件、軟件和設備費用；系統的開發費用；系統安裝、運行和維護費用；人員培訓費用。2） 效益：經濟效益包括使用基于計算機的系統后可增加的收入和可節省的運行費用（經濟效益通常可用貨幣的時間價值、投資回收期和純收入來度量）

13、；社會效益指使用基于計算機的系統后對社會產生的影響。2、 技術可行性：主要根據系統的功能、性能、約束條件等，分析在現有資源和技術條件下系統能否實現1） 風險分析：分析在給定的約束條件下設計和實現系統的風險（不成熟的技術、人員流動、成本和人員估算不合理）。2） 資源分析：論證是否具備系統開發所需的各類人員、軟件、硬件等資源和相應的工作環境3） 技術分析：分析當前的科學技術是否支持系統開發的各項活動。3、 法律可行性：研究系統開發過程中可能涉及到的合同、侵權、責任以及各種與法律相抵觸 的問題4、 方案的選擇和折中第三章 需求工程一、 需求工程概述軟件需求：用戶對目標軟件系統在功能、行為、性能、設計

14、約束等方面的期望。任務：準確地定義未來系統的目標，確定為了滿足用戶的需求系統必須做什么。細分階段：需求獲取；需求分析與協商；系統建模；需求規約；需求驗證；需求管理。二、 需求獲取軟件需求種類：功能需求 ；性能需求；用戶或人的因素； 環境需求； 界面需求； 文檔需求；數據需求； 資源使用需求； 安全保密要求； 可靠性需求； 軟件成本消耗與開發進度需求； 其他非功能性要求。需求獲取的方法與策略：1、 建立順暢的通信途徑2、 訪談與調查3、 觀察用戶操作流程4、 組成聯合小組：打破用戶（需方）和開發者（供方）的界限，共同組成一個聯合小組，發揮各自的長處，共同負責項目的推進，這樣有助于發揮各自優勢并增

15、進解和協調。5、 用況、用例（Use Case）：分析員創建一組標識一串待建造系統的使用場景。用況提供了系統如何被使用的描述。創建用況模型的主要步驟如下：1）確定誰會直接使用該系統，即執行者（Actor）； 2）選取其中一個執行者；3）定義該執行者希望系統做什么，執行者希望系統做的每件事將成為一個用況；4）對每件事來說，何時參與者會使用系統，通常會發生什么，這就是用況的基本過程； 5）描述該用況的基本過程。三、 需求分析、協商與建模需求分析原則：1） 必須能夠表示和理解問題的信息域；2） 必須能夠定義軟件將完成的功能；3） 必須能夠表示軟件的行為(作為外部事件的結果；4） 必須劃分描述數據、功

16、能和行為的模型，從而可以分層次地揭示細節；5） 分析過程應該從要素信息移向細節信息。模型：對對象系統的形式化的特征抽象，概括性或近似地表示。需求分析過程：1） 通過對現實環境的調查，獲得當前系統的物理模型；2） 去掉具體模型中的非本質因素，抽象出當前系統的邏輯模型；3） 分析當前系統與目標系統的差別，建立目標系統的邏輯模型。常用的分析方法：面向數據流的結構化分析方法 (SA)；面向對象的分析方法 (OOA)。四、 需求規約與驗證需求驗證目的：是要檢驗需求是否能夠反映用戶的意愿。第四章 設計工程一、 軟件設計工程概述軟件設計：軟件設計是把軟件需求變換成軟件表示的過程。任務：把軟件分析模型中通過數

17、據、功能和行為模型所展示的軟件需求的信息被傳送給設計階段，產生數據/類設計、體系結構設計、接口設計、部件級設計。1. 數據/類設計：將分析-類模型變換成類的實現和軟件實現所需要的數據結構（數據對象和關系以及數據字典中描述的詳細數據內容提供數據設計活動的基礎）。過程：1) 為在需求分析階段所確定的數據對象選擇邏輯表示，需要對不同結構進行算法分析，以便選擇一個最有效的設計方案； 2) 確定對邏輯數據結構所必需的那些操作的程序模塊，以便限制或確定各個數據設計決策的影響范圍。2. 體系結構設計：體系結構設計定義了軟件的整體結構，由軟件部件、外部可見的屬性和它們之間的關系組成。3. 接口設計：接口設計描

18、述了軟件內部、軟件和協作系統之間以及軟件同人之間如何通信。三方面：1） 軟件模塊間的接口；2） 模塊和其它非人的信息生產者和消費者(比如外部實體)之間的接口；3） 人(用戶)和計算機間的接口4. 部件級設計：部件級設計將軟件體系結構的結構性元素變換為對軟件部件的過程性描述（以類為基礎的對象模型、流模型、行為模型中得到的信息是部件設計的基礎）。軟件設計過程的目標（McGlanghlin）：1) 須實現分析模型中描述的所有顯式需求，必須滿足用戶希望的所有隱式需求。2) 必須是可讀、可理解的，使得將來易于編程、易于測試、易于維護。3) 從實現角度出發，給出與數據、功能、行為相關的軟件全貌。衡量設計的

19、技術標準：1) 設計出來的結構應是分層結構，從而建立軟件成份之間的控制。2) 設計應當模塊化，從邏輯上將軟件劃分為完成特定功能或子功能的部件。3) 設計應當既包含數據抽象，也包含過程抽象。4) 設計應當建立具有獨立功能特征的模塊。5) 設計應當建立能夠降低模塊與外部環境之間復雜連接的接口。6) 設計應能根據軟件需求分析獲取的信息，建立可驅動、可重復的方法。軟件設計的過程：1) 制定規范2) 體系結構和接口設計3) 數據/類設計4) 部件級（過程）設計5) 編寫設計文檔6) 設計評審二、 軟件設計原則1、 抽象與逐步求精：1) 抽象：是在軟件設計的規模逐漸增大的情況下，控制復雜性的基本策略。抽象

20、手段：a) 過程抽象：任何一個完成明確定義功能的操作都可被使用者當作單個實體看待，盡管這個操作實際上是由一系列更低級的操作來完成的。b) 數據抽象：指定義數據類型和施加于該類型對象的操作，并限定了對象的取值范圍，只能通過這些操作修改和觀察數據。2) 逐步求精：把問題的求解過程分解成若干步驟或階段，每步都比上步更精化，更接近問題的解法2、 模塊化：把軟件按照規定原則，劃分為較小且相互獨立的但又相互關聯的部件，實際上是系統分解和抽象的過程（模塊化是好的軟件設計的一個基本準則）。（模塊：數據說明、可執行語句等程序對象的集合，它是單獨命名的，并且可以通過名字來訪問）3、 信息隱藏：可定義和實施對模塊的

21、過程細節和局部數據結構的訪問限制4、 功能獨立：功能獨立是模塊化、抽象、信息隱藏和局部化等概念的直接結果。開發功能專一的且避免與其他模塊過多交互的的模塊可以實現功能獨立。功能獨立的重要性：1) 功能被分隔且接口被簡化使得軟件更容易開發。2) 由于因修改設計或修改編碼引起的副作用被限制，減少了錯誤擴散，且模塊復用成為可能，因而使得軟件更易于維護和測試。功能獨立性的兩項衡量指標：1) 內聚度：度量模塊內部各個元素彼此結合的緊密程度。a) 巧合內聚（偶然內聚）：幾個模塊中沒有明確表現出獨立功能的相同程序代碼段獨立出來建立的模塊。b) 邏輯內聚 ：指完成一組邏輯相關任務的模塊，調用該模塊時，由傳送給模

22、塊的控制型參數來確定該模塊應執行哪一種功能。c) 時間內聚：指一個模塊中的所有任務必須在同一時間段內執行。例如初始化模塊和終止模塊。d) 過程內聚 ：指一個模塊完成多個任務，這些任務必須按指定的過程（procedural）執行。e) 通信內聚 ：指一個模塊內所有處理元素都集中在某個數據結構的一塊區域中。f) 順序內聚：指一個模塊完成多個功能，這些功能又必須順序執行。g) 功能內聚 ：指一個模塊中各個部分都是為完成一項具體功能而協同工作，緊密聯系，不可分割的。2) 耦合度: 度量模塊之間的相對獨立性（互相連接的緊密程度）。a) 內容耦合 ：如果一個模塊直接訪問另一個模塊的內部數據；或者一個模塊不

23、通過正常入口轉到另一模塊內部；或者兩個模塊有一部分程序代碼重迭；或者一個模塊有多個入口，則兩個模塊之間就發生了內容耦合。b) 公共耦合 ：若一組模塊都訪問同一個公共數據環境，則它們之間的耦合就稱為公共耦合。公共的數據環境可以是全局數據結構、共享的通信區、內存的公共覆蓋區等。c) 外部耦合 ：指模塊間通過軟件之外的環境聯結（如I/O將模塊耦合到特定的設備、格式、通信協議上）時，稱為外部耦合。d) 控制耦合：如果一個模塊傳送給另一個模塊的參數中包含了控制信息，該控制信息用于控制接收模塊中的執行邏輯，則稱為控制耦合。e) 標記耦合：兩個模塊之間通過參數表傳遞一個數據結構的一部分（如某一數據結構的子結

24、構），就是標記耦合。 f) 數據耦合：兩個模塊之間僅通過參數表傳遞簡單數據，則稱為數據耦合。g) 非直接耦合 ：如果兩個模塊之間沒有直接關系，即它們中的任何一個都不依賴于另一個而能獨立工作，這種耦合稱為非直接耦合。模塊之間的連接越緊密，聯系越多，耦合性就越高，而其功能獨立性就越弱； 一個模塊內部各個元素之間的聯系越緊密，則它的內聚性就越高；功能獨立性比較強的模塊應是高內聚低耦合的模塊。三、 軟件體系結構設計軟件體系結構關注系統的一個或多個結構，包含軟件構件、這些構件的對外可見的性質以及它們之間的關系。常見的軟件體系結構：單主機結構、C/S（Client/Server）結構、B/S（Browse

25、r/Server）結構軟件體系結構的風格：1. 數據為中心體系結構：數據保存在整個結構的中心，并且被其他部件頻繁地使用、添加、刪除、或者修改。2. 數據流風格的體系結構：這種結構適用于輸入數據被一系列的計算或者處理部件變換成輸出數據。3. 調用和返回風格的體系結構：便于設計出非常容易修改和擴充的體系結構。4. 面向對象風格的體系結構:：系統部件封裝數據和操作數據的方法。部件之間的交互和協調通過消息來傳遞。5. 層次式風格的體系結構: 在這種結構中，定義不同的層次，每層都完成了相對外層更靠近機器指令的操作。四、 部件級設計技術在結構化分析和設計方法時部件往往被稱為模塊；在面向對象分析和設計時部件

26、被稱為類；在基于構件的開發方法中，部件被稱為構件。部件級設計階段工作：1. 為每個部件確定采用的算法，選擇某種適當的工具表達算法的過程，編寫部件的詳細過程性描述； (算法過程)2. 確定每一部件內部使用的數據結構；（數據結構） 3. 在部件級設計結束時，把上述結果寫入部件級設計說明書，并且通過復審形成正式文檔，作為下一階段（編碼階段）的工作依據。（文檔）方法：1. 結構化程序設計方法：代碼塊僅通過順序、選擇和循環這三種基本控制結構進行連結，并且每個代碼塊只有一個入口和一個出口。2. 圖形表示法：程序流程圖、N-S圖、PAD3. 判定表：當算法中包含多重嵌套的條件選擇時，用程序流程圖、N-S圖或

27、PAD都不易清楚地描述。然而，判定表卻能清晰地表達復雜的條件組合與應做動作之間的對應關系。優點：能夠簡潔，無二義性地描述所有的處理規則。缺點：靜態邏輯，是在某種條件取值組合情況下可能的結果，它不能表達加工的順序，也不能表達循環結構。4. 設計性語言PDL：是一種用于描述功能部件的算法設計和處理細節的語言，稱為設計性語言。五、 設計規約與設計評審設計評審內容：可追溯性；接口；風險；實用性；技術清晰度；可維護性；質量；各種選擇方案；限制；其他具體問題。（分正式評審、非正式評審）第五章 結構化分析與設計結構化方法：一種面向數據流的傳統軟件開發方法，以數據流為中心構建軟件的分析模型和設計模型（結構化分

28、析、結構化設計、結構化程序設計）。一、 結構化方法概述主要思想：抽象與自頂向下的逐層分解（控制復雜性的兩個基本手段）。1、 抽象：忽略一個問題中與當前目標無關的那些方面，以便更充分地關注與當前目標有關的方面。2、 分解：將問題不斷分解為較小的問題，直到每個最底層的問題都足夠簡單為止。過程：1. 理解當前的現實環境，獲得當前系統的具體模型（物理模型）；2. 從當前系統的具體模型抽象出當前系統的邏輯模型；3. 分析目標系統與當前系統邏輯上的差別，建立目標系統邏輯模型；4. 為目標系統的邏輯模型作補充。結構化分析模型的組成與概述：數據字典：核心，包含了軟件使用和產生的所有數據的描述。數據流圖：用于功

29、能建模，描述系統的輸入數據流的加工變換到輸出數據流過程。實體關系圖：用于數據建模，描述數據字典中數據之間的關系，數據對象的屬性用“數據對象描述”描述。狀態轉換圖：用于行為建模，描述系統接收外部事件，以及在外部事件的作用下系統的狀態遷移。控制規約：用來描述軟件控制方面的附加信息。二、 數據流圖DFD定義：描述輸入數據流到輸出數據流的變換（即加工）過程，用于對系統的功能建模。基本元素：源或宿：存在于軟件系統之外的人員或組織，表示軟件系統輸入數據的來源和輸出數據的去向，因此也稱為源點和終點。加工：描述輸入數據流到輸出數據流的變換。文件：保存數據信息的外部單元。數據流：有一組固定成分的數據組成。擴充符

30、號：星號（*）：表示數據流之間存在“與”關系。加號（+）：表示數據流之間存在“或”關系。異或（）：表示數據流之間存在“異或”（互斥）關系。畫分層數據流圖的步驟：1、 畫出系統的輸入和輸出：確定源和宿；確定加工；確定數據流。2、 畫出系統內部：確定加工；確定數據流；確定文件；確定源和宿。3、 畫出加工內部4、 重復第3步，直至加工都足夠簡單。畫分層數據流圖原則：先全局后局部，先整體后細節，先抽象后具體（由頂向下，逐步細化）。三、 分層數據流圖的審查一致性：分層DFD中不存在矛盾和沖突。完整性：分層DFD本身的完整性，即是否有遺漏的數據流、加工等元素。構造分層DFD時需要注意的問題：適當命名；畫數

31、據流而不是畫控制流；避免一個加工有過多的數據流；分解盡可能均勻；先考慮穩定狀態，忽略瑣碎的枝節；隨時準備重畫。四、 數據字典定義：對所有與系統相關的數據元素的一個有組織的列表，以及精確的、嚴格的定義，使得用戶和系統分析員對于輸入、輸出、存儲成分和中間計算有共同的理解。種類：數據流、文件、數據項、加工、源或宿。字典條目描述內容主要包括：DFD元素的基本信息（名稱、別名、簡述、注解）；定義（數據類型、數據組成）；使用特點（取值范圍、使用頻率、激發條件）；控制信息（來源、去向、訪問權限）。五、 描述基本加工的小說明定義：是基本加工的規約說明，應精確地描述用戶要求一個加工“做什么”，包括加工的激發條件

32、、加工邏輯、優先級、執行頻率、出錯處理等。加工邏輯的描述方法：結構化語言；判定表；判定樹。六、 結構化設計（SD）概述定義：將結構化分析得到的數據流圖映射成軟件體系結構的一種設計方法，強調模塊化、自頂向下逐步求精、信息隱蔽、高內聚低耦合等設計準則。結構圖：描述軟件系統的體系結構，由哪些模塊組成，以及模塊之間的調用關系。基本成分：1） 模塊(module)：指具有一定功能的可以用模塊名調用的一組程序語句，如函數、子程序等，是組成程序的基本單元。外部特征：模塊的接口（模塊名、輸入/輸出參數、返回值等）和模塊的功能。內部特征：模塊的內部數據和完成其功能的程序代碼。2） 調用(call)：用從一個模塊

33、指向另一個模塊的箭頭來表示，其含義是前者調用了后者。3） 數據(data)：模塊調用時需傳遞的參數可通過在調用箭頭旁附加一個小箭頭和數據名來表示。輔助符號：條件調用、循環調用、遞歸調用。深度：程序結構圖中控制的層數。寬度：程序結構圖中同一層次上模塊總數的最大值。扇出(fan out)：該模塊直接調用的模塊數目。扇入(fan in)：能直接調用該模塊的模塊數目。相關指標的含義：1. 深度和寬度在一定程序上反映了程序的規模和復雜程度。相對而言，如果程序結構圖的深度和寬度較大，則說明程序的規模和復雜程度都較大；模塊的扇入扇出會影響結構圖的深度和寬度，例如減少模塊的扇出，可能導致寬度變小而深度增加。2

34、. 一個模塊的扇出過大通常意味著該模塊比較復雜，然而扇出太少，可能導致深度的增加。3. 一個模塊的扇入表示有多少模塊可直接調用它，它反映了該模塊的復用(reuse)程度，因此模塊的扇入越大越好。啟發式設計策略：1. 改造程序結構圖，降低耦合度，提高內聚度。2. 避免高扇出，并隨著深度的增加，力求高扇入。3. 模塊的影響范圍應限制在該模塊的控制范圍內。4. 降低模塊接口的復雜程度和冗余程度，提高一致性。5. 模塊的功能應是可預測的，避免對模塊施加過多的限制。6. 盡可能設計單入口和單出口的模塊。結構化設計的步驟：1. 建立初始結構圖2. 對結構圖的改進3. 書寫設計文檔4. 設計評審七、 數據流

35、圖到軟件體系結構的映射變換流：信息沿著輸入通路進入系統，并將外部形式轉換成內部形式，進入系統的信息通過變換中心的處理，再沿著輸出通路轉換成外部形式后離開系統，具有這種特征的信息流稱為變換流。事物流：數據流沿著輸入通路到達一個事務中心，事務中心根據輸入數據的類型在若干條動作通路中選出一條來執行，具有這種特征的信息流稱為事務流。 事務中心的任務：1） 接收事務（輸入數據）；2） 分析每個事務以確定它的類型；3） 根據事務類型選取一條動作通路。數據流圖映射到結構圖的步驟：1. 復審和精化數據流圖；2. 確定數據流圖的類型；3. 將DFD映射成初始結構圖；4. 改進初始結構圖。變換分析步驟：1. 劃定輸入流和輸出流的邊界，確定變換中心；2. 進行第一級分解；3. 進行第二