软件工程课件

什麼是軟體软件的分类软件的发展软件生存期

軟體工程软件工程的目的和要求第一章軟體工程概論軟體是電腦系統中與硬體相互依存的另一部分，它是包括程式，數據及其相關文檔的完整集合。程式是按事先設計的功能和性能要求執行的指令序列數據是使程式能正常操縱資訊的數據結構文檔是與程式開發，維護和使用有關的圖文材料什麼是軟體？軟體的特點軟體是一種邏輯實體，而不是具體的物理實體。因而它具有抽象性軟體的生產與硬體不同，在它的開發過程中沒有明顯的製造過程在軟體的運行和使用期間，沒有硬體那樣的機械磨損，老化問題軟體的開發和運行常受到電腦系統的限制，對電腦系統有著不同程度的依賴性軟體的開發至今尚未完全擺脫手工藝的開發方式軟體本身是複雜的實際問題的複雜性程式邏輯結構的複雜性軟體成本相當昂貴相當多的軟體工作涉及到社會因素軟體的分類按軟體的功能進行劃分：系統軟體操作系統資料庫管理系統設備驅動程式通信處理程式等

支撐軟體文本編輯程式檔格式化程式磁片向磁帶向數據傳輸的程式程式庫系統支持需求分析、設計、實現、測試和支持管理的軟體

應用軟體商業數據處理軟體工程與科學計算軟體電腦輔助設計／製造軟體系統仿真軟體智能產品嵌入軟體醫療、制藥軟體事務管理、辦公自動化軟體電腦輔助教學軟體按軟體規模進行劃分：類別參加人員數研製期限根源程式行數

微型 1 1～4周0.5k小型1 1～6月1k～2k中型2～5 1～2年5k～50k大型5～20 2～3年50k～100k甚大型100～10004～5年1M(=1000k)極大型2000～50005～10年1M～10M

按軟體工作方式劃分：即時處理軟體分時軟體互動式軟體批處理軟體按軟體服務對象的範圍劃分：專案軟體產品軟體按使用的頻度進行劃分：一次使用頻繁使用按軟體失效的影響進行劃分：高可靠性軟體一般可靠性軟體軟體發展階段程式設計階段—50至60年代程式系統階段—60至70年代 軟體工程階段—70年代以後軟體工程過程軟體規格說明：規定軟體的功能及其運行的限制軟體開發：產生滿足規格說明的軟體軟體確認：確認軟體能夠完成客戶提出的要求軟體演進：為滿足客戶的變更要求，軟體必須在使用的過程中演進軟體工程過程的特性易理解性可見性可支持性可接受性可靠性健壯性可維護性速度軟體生存期lifecycle軟體有一個孕育、誕生、成長、成熟、衰亡的生存過程。這個過程即為電腦軟體的生存期軟體生存期的六個步驟，即制定計畫、需求分析、設計、程式編碼、測試及運行維護瀑布模型

RETURN制定計畫確定要開發軟體系統的總目標給出功能、性能、可靠性以及介面等方面的要求完成該軟體任務的可行性研究估計可利用的資源

(硬體，軟體，人力等)、成本、效益、開發進度制定出完成開發任務的實施計畫，連同可行性研究報告，提交管理部門審查需求分析和定義對用戶提出的要求進行分析並給出詳細的定義編寫軟體需求說明書或系統功能說明書及初步的系統用戶手冊提交管理機構評審軟體設計概要設計

—把各項需求轉換成軟體的體系結構。結構中每一組成部分都是意義明確的模組，每個模組都和某些需求相對應詳細設計

—對每個模組要完成的工作進行具體的描述，為根源程式編寫打下基礎編寫設計說明書，提交評審。程式編寫把軟體設計轉換成電腦可以接受的程式代碼，即寫成以某一種特定程式設計語言表示的“根源程式清單”寫出的程式應當是結構良好、清晰易讀的，且與設計相一致的軟體測試單元測試，查找各模組在功能和結構上存在的問題並加以糾正組裝測試，將已測試過的模組按一定順序組裝起來按規定的各項需求，逐項進行有效性測試，決定已開發的軟體是否合格，能否交付用戶使用運行／維護改正性維護運行中發現了軟體中的錯誤需要修正適應性維護為了適應變化了的軟體工作環境，需做適當變更完善性維護為了增強軟體的功能需做變更軟體生存期模型軟體生存期模型是跨越整個生存期的系統開發、運作和維護所實施的全部過程、活動和任務的結構框架瀑布模型演化模型螺旋模型噴泉模型智能模型演化模型由於在專案開發的初始階段人們對軟體的需求認識常常不夠清晰，因而使得開發專案難於做到一次開發成功，出現返工再開發在所難免。做兩次第一次只是試驗開發，其目標只是在於探索可行性，弄清軟體需求第二次則在此基礎上獲得較為滿意的軟體產品螺旋模型螺旋模型沿著螺線旋轉，在四個象限上分別表達四個方面的活動，即：制定計畫──確定軟體目標，選定實施方案，弄清專案開發的限制風險分析──分析所選方案，考慮如何識別和消除風險實施工程──實施軟體開發客戶評估──評價開發工作，提出修正建議

噴泉模型迭代重複演進無間隙各階段間無明顯界限軟體工程的定義Boehm：運用現代科學技術知識來設計並構造電腦程式及為開發、運行和維護這些程式所必需的相關檔資料IEEE：軟體工程是開發、運行、維護和修復軟體的系統方法FritzBauer：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法軟體工程三要素：

方法、工具和過程軟體工程方法為軟體開發提供了“如何做”的技術軟體工具為軟體工程方法提供了自動的或半自動的軟體支撐環境軟體工程過程定義了:

方法使用的順序要求交付的文檔資料為保證品質和適應變化所需要的管理軟體開發各個階段完成的里程碑

某些元素的一個集合或排列這些元素被組織起來以實現某種方法，過程或借助處理資訊進行控制。基於電腦的系統基於電腦系統的系統元素系統元素軟體—

電腦程式、數據結構、相關文檔硬體—

電子計算設備（如CPU，記憶體）和外部機電設備（如感測器、馬達等）人—

硬體和軟體的用戶資料庫—

一個大型的有組織的資訊集合文檔—

手冊、表格和其他用以描述系統使用和操作的資訊過程—

定義每一種系統元素的特定使用步驟，或系統駐留的過程性環境系統的層次結構基於電腦的系統本身可以成為一個更大的基於電腦系統中的一個元素，並稱為那個更大系統的宏元素。工廠自動化

系統電腦系統工程電腦系統工程是一個問題求解活動，目的是揭示、分析所期望的功能，並把它們分配到各個單獨的系統元素中去。系統工程師的任務與用戶合作確認用戶的目標和約束導出功能、性能、介面、設計約束和資訊結構的表示將它們分配到每一個系統元素中

電腦系統工程師選擇硬體元件的某種組合以構成基於電腦系統的硬體元素硬體工程過程可以分為三個階段計畫和定義階段設計和樣機實現階段生產、銷售和售後服務階段硬體和硬體工程

軟體與軟體工程為實現要求的功能和性能，必須製作或獲取一系列軟體部件軟體元素分為兩類

應用軟體用來實現資訊處理的功能

系統軟體完成使應用軟體能與其它系統元素交互的控制功能

人類工程是應用從心理學和方法論導出的知識來確定和設計高質量HCI的多學科活動人類工程過程包括以下步驟（1）活動分析──環境交互及劃分任務,進行任務分析

（2）語義分析和設計──動作精確定義，“對話”設計(3)語法和詞法設計──各個動作和命令的形式，硬體與軟體實現

(4)用戶環境設計──將硬體、軟體和其他系統生成元素組合起來形成用戶環境(5)原型──從人的角度出發來評價HCI資料庫和數據庫工程資料庫工程（包括資料庫分析、設計和實現）對於使用資料庫的系統，資訊倉庫往往是所有功能的核心資料庫工程的應用是在資料庫的資訊域定義完成之後

系統工程師的作用是

定義資料庫中包含的資訊處理查詢的類型數據存取的方式資料庫的容量等數據分析和設計是基本的軟體工程活動系統分析的目標識別用戶要求評價系統的可行性進行經濟分析和技術分析把功能分配給硬體、軟體、人、資料庫和其他系統元素建立成本和進度限制生成系統規格說明，形成所有後續工程的基礎需求識別系統分析過程的第一步就是識別用戶要求分析員必須考慮以下問題：功能和性能

可靠性和品質

總的系統目標

成本與進度限制製造需求

市場與競爭情況

有效的技術

將來可能的擴充系統分析的任務識別希望的功能和性能範圍確定系統的功能、性能、約束和介面將功能賦予一個或多個系統元素（即軟體、硬體、人等）提出一些候選方案並做評價

專案考慮商業考慮技術分析生產評估

對同一功能，可以分配不同的系統元素為選取最有效的分配方案，使用一組權衡準則進行評價人員問題環境介面法律考慮1、專案考慮在預估的成本與進度範圍內所選的系統配置能否實現？與成本與進度估算相關的風險有哪些？

2、商業考慮所選的系統配置是最可能有效益的解決方案嗎？能否成功地佔領市場？最終的報償是否能表明所冒的開發風險是值得的？

3、技術分析是否具備開發所有系統元素的技術實力？能否確保功能和性能得到滿足？能否對這種系統配置進行充分的維護？是否具備技術資源？與技術相關的風險有哪些？

4、生產評估生產工具與設備是否有效？必需的過程是否短缺？是否充分地實施了品質保證？

5、人員問題開發人員是否得到培訓？是否存在政治問題？用戶是否瞭解這個系統將要做什麼？

6、環境介面所提交的系統配置與系統的外部環境的介面是否合適？機器與機器、人與機器之間的通信是否以智能方式處理？

7、法律考慮這種配置是否會引入違法的責任風險？對責任問題是否給予了足夠的保護？是否存在潛在的破壞問題？

可行性研究問題識別市場調查分析準備環境分析物理分析功能分析資訊分析動態分析確立系統方案，作出各種估算模型評審

問題的初步認識瞭解系統應解決的問題，這些問題使如何提出的設想這些問題如何解決才能滿足要求瞭解問題的結構

市場調查瞭解市場對待開發軟體的需求情況調查市場上已有的類似軟體系統的功能、性能、價格情況

分析準備確立分析計畫規定由誰參加分析作業，任務分配對參加分析的人員進行必要的培訓

環境分析明確系統的目的和限制條件使用單位的狀況、經營方針和組織機構使用單位的電腦利用情況相關的硬體、軟體及其它介面部分用戶的操作環境及操作要求習慣、法律、制度上對軟體的制約開發能具備的技術條件和設備條件

物理分析瞭解實際業務活動狀況，特別對一些活動要點進行分析明確在這些要點之間什麼東西在流動，如何進行流動對物理流量進行分析對其模型化，得到實際業務系統（當前系統）的物理模型

功能分析決定系統應具備的功能(工作域)分析功能的結構：功能展開和功能分配分析各功能之間的關係，整理它們之間傳遞的資訊利用數據流圖，描述資訊在系統流動與處理的情況

資訊分析調查系統的輸入、輸出、保存資訊明確資訊的結構及各資訊之間的關係調查各資訊的資訊量調查各種報表和文件的格式建立粗略的數據詞典，定義系統中使用的數據

動態分析系統內每一部分有幾種狀態各種狀態轉換的條件同步產生的條件與同步後狀態的變化

確立系統方案，進行各種估算粗略地估算成本估算可能取得的效益提出可能需要的資源，包括人員、硬體、軟體等提出大概的進度安排

軟體需求分析的任務深入描述軟體的功能和性能確定軟體設計的約束和軟體同其他系統元素的介面細節定義軟體的其他有效性需求需求分析研究的對象是軟體專案的用戶要求準確地表達被接受的用戶要求確定被開發軟體系統的系統元素將功能和資訊結構分配到這些系統元素中需求分析的任務就是借助於當前系統的邏輯模型導出目標系統的邏輯模型，解決目標系統的“做什麼”的問題。通常軟體開發專案是要實現目標系統的物理模型目標系統的具體物理模型是由它的邏輯模型經實例化，即具體到某個業務領域而得到的需求分析的過程(1)問題識別從系統的角度來理解軟體並評審軟體範圍是否恰當確定對目標系統的綜合要求，即軟體的需求提出這些需求實現條件，以及需求應達到的標準軟體的需求包括：功能需求性能需求環境需求可靠性需求安全保密要求用戶介面需求資源使用需求成本消耗需求開發進度需求預先估計以後系統可能達到的目標問題識別的另一項工作是建立分析所需要的通信途徑，以保證能順利地對問題進行分析。(2)分析與綜合從資訊流和資訊結構出發，逐步細化所有的軟體功能，找出系統各元素之間的聯繫、介面特性和設計上的約束，分析它們是否滿足功能要求，是否合理。剔除其不合理的部分，增加其需要部分。最終綜合成系統的解決方案，給出目標系統的詳細邏輯模型。常用的分析方法面向數據流的結構化分析方法(SA)面向數據結構的Jackson方法(JSD)面向數據結構的結構化數據系統開發方法(DSSD)面向對象的分析方法(OOA)等(3)編制需求分析階段的文檔軟體需求說明書數據要求說明書初步的用戶手冊修改、完善與確定軟體開發實施計畫(4)需求分析評審系統定義的目標是否與用戶的要求一致;系統需求分析階段提供的文檔資料是否齊全;文檔中的所有描述是否完整、清晰、準確反映用戶要求;與所有其他系統成分的重要介面是否都已經描述;被開發專案的數據流與數據結構是否足夠，確定;所有圖表是否清楚，在不補充說明時能否理解;主要功能是否已包括在規定的軟體範圍之內，是否都已充分說明;設計的約束條件或限制條件是否符合實際;開發的技術風險是什麼;是否考慮過軟體需求的其他方案;是否考慮過將來可能會提出的軟體需求;是否詳細制定了檢驗標準，它們能否對系統定義是否成功進行確認;需求分析流程軟體需求分析的原則需要能夠表達和理解問題的資訊域和功能域要能以層次化的方式對問題進行分解和不斷細化要給出系統的邏輯視圖和物理視圖軟體需求規格說明的原則從現實中分離功能，即描述要“做什麼”而不是“怎樣實現”要求使用面向處理的規格說明語言（或稱系統定義語言）如果被開發軟體只是一個大系統中的一個元素，那麼整個大系統也包括在規格說明的描述之中規格說明必須包括系統運行環境規格說明必須是一個認識模型規格說明必須是可操作的規格說明必須容許不完備性並允許擴充規格說明必須局部化和鬆散耦合軟體需求方法需求分析方法由對軟體問題的資訊域和功能域的系統分析過程及其表示方法組成大多數的需求分析方法是由資訊驅動的資訊域具有三種屬性:資訊流、資訊內容和資訊結構。結構化分析方法

面向數據流進行需求分析的方法結構化分析方法適合於數據處理類型軟體的需求分析具體來說，結構化分析方法就是用抽象模型的概念，按照軟體內部數據傳遞、變換的關係，自頂向下逐層分解，直到找到滿足功能要求的所有可實現的軟體為止結構化分析方法使用工具：

數據流圖數據詞典結構化英語判定表與判定樹數據流圖數據流圖中的主要圖形元素數據加工(數據變換)數據源點或終點(外部實體)數據流數據存儲檔描述銀行取款過程的數據流圖數據流與數據加工之間的關係數據流圖的層次結構為了表達數據處理過程的數據加工情況，需要採用層次結構的數據流圖。按照系統的層次結構進行逐步分解，並以分層的數據流圖反映這種結構關係，能清楚地表達和容易理解整個系統分層的數據流圖在多層數據流圖中，頂層流圖僅包含一個加工，它代表被開發系統。它的輸入流是該系統的輸入數據，輸出流是系統所輸出數據底層流圖是指其加工不需再做分解的數據流圖，它處在最底層中間層流圖則表示對其上層父圖的細化。它的每一加工可能繼續細化，形成子圖。結構化分析方法步驟示例

商店业务处理系统這個數據流圖只是一個高層的系統邏輯模型，它反映了目標系統要實現的功能數據流圖繪製步驟首先確定系統的輸入和輸出根據商店業務，畫出頂層數據流圖，以反映最主要業務處理流程

經過分析，商店業務處理的主要功能應當有銷售、採購、會計三大項。主要數據流輸入的源點和輸出終點是顧客和供應商。然後從輸入端開始，根據商店業務工作流程，畫出數據流流經的各加工框，逐步畫到輸出端，得到第一層數據流圖第一層數據流圖加細每一個加工框 銷售細化採購細化檢查和修改數據流圖的原則數據流圖上所有圖形符號只限於前述四種基本圖形元素數據流圖的主圖必須包括前述四種基本元素，缺一不可數據流圖的主圖上的數據流必須封閉在外部實體之間每個加工至少有一個輸入數據流和一個輸出數據流在數據流圖中，需按層給加工框編號。編號表明該加工所處層次及上下層的親子關係規定任何一個數據流子圖必須與它上一層的一個加工對應，兩者的輸入數據流和輸出數據流必須一致。此即父圖與子圖的平衡可以在數據流圖中加入物質流，幫助用戶理解數據流圖圖上每個元素都必須有名字數據流圖中不可夾帶控制流初畫時可以忽略瑣碎的細節，以集中精力於主要數據流數據詞典數據詞典與數據流圖配合，能清楚地表達數據處理的要求詞條描述——對於在數據流圖中每一個被命名的圖形元素，均加以定義，其內容有:名字，別名或編號，分類，描述，定義，位置，其他，等（1）數據流詞條描述數據流名：說明：簡要介紹作用即它產生的原因和結果數據流來源：來自何方數據流去向：去向何處數據流組成：數據結構數據量流通量：數據量，流通量（2）數據元素詞條描述數據元素名：類型：數字（離散值，連續值），文字（編碼類型）長度：取值範圍：相關的數據元素及數據結構：（3）數據檔詞條描述數據檔案名：簡述：存放的是什麼數據輸入數據：輸出數據：數據檔組成：數據結構存儲方式：順序，直接，關鍵碼存取頻率：（4）加工邏輯詞條描述加工名：加工編號：反映該加工的層次簡要描述：加工邏輯及功能簡述輸入數據流：輸出數據流：加工邏輯：簡述加工程式，加工順序（5）源點及匯(終)點詞條描述名稱：外部實體名簡要描述：什麼外部實體有關數據流：數目：數據結構的描述

符號

含義

舉例＝被定義為＋與

x=a＋b[...,...]或[...|...]或

x=[a,b]，x=[a|b]{...}或m{...}n重複

x={a}，x=3{a}8(...)可選

x=(a)“...”基本數據元素

x=“a”.. 連結符

x=1..9存摺格式存摺＝戶名＋所號＋帳號＋開戶日＋性質＋(印密)＋1{存取行}50戶名＝2{字母}24所號＝“001”..“999”帳號＝“00000001”..“99999999”開戶日＝年＋月＋日性質＝“1”..“6”注：“1”表示普通戶，“5”表示工資戶等印密＝“0”注：印密在存摺上不顯示存取行＝日期＋（摘要）＋支出＋存入＋餘額＋操作＋復核

對數據流圖的每一個基本加工，必須有一個基本加工邏輯說明基本加工邏輯說明必須描述基本加工如何把輸入數據流變換為輸出數據流的加工規則加工邏輯說明必須描述實現加工的策略而不是實現加工的細節加工邏輯說明中包含的資訊應是充足的，完備的，有用的，無冗餘的基本加工邏輯說明用於寫加工邏輯說明的工具

結構化英語判定表判定樹（1）結構化英語結構化英語的辭彙表由英語命令動詞數據詞典中定義的名字有限的自定義詞邏輯關係詞IF_THEN_ELSE、

CASE_OF、

WHILE_DO、

REPEAT_UNTIL等組成。是一種介於自然語言和形式化語言之間的語言語言的正文用基本控制結構進行分割，加工中的操作用自然語言短語來表示其基本控制結構有三種：簡單陳述句結構：避免複合語句；重複結構：while_do

或

repeat_until結構。判定結構：if_then_else

或

case_of結構；商店業務處理系統中“檢查發貨單”if發貨單金額超過$500then

if

欠款超過了60天then

在償還欠款前不予批准

else

（欠款未超期）發批准書，發貨單

else

（發貨單金額未超過$500）

if

欠款超過60天then

發批准書，發貨單及賒欠報告

else

（欠款未超期）發批准書，發貨單

（2）判定表如果數據流圖的加工需要依賴於多個邏輯條件的取值，使用判定表來描述比較合適以“檢查發貨單”為例（3）判定樹判定樹也是用來表達加工邏輯的一種工具。有時侯它比判定表更直觀。檢查發貨單金額>$500金額

$500

欠款>60天不發出批准書

欠款

60天發貨單發出批准書、

欠款>60天發出批准書、發貨單及賒欠報告

欠款

60天發出批准書、發貨單原型化方法在開發初期，要想得到一個完整準確的規格說明不是一件容易的事。特別是對一些大型的軟體專案。用戶往往對系統只有一個模糊的想法，很難完全準確地表達對系統的全面要求。軟體開發者對於所要解決的應用問題認識更是模糊不清隨著開發工作向前推進，用戶可能會產生新的要求，或因環境變化，要求系統也能隨之變化；開發者又可能在設計與實現的過程中遇到些沒有預料到的實際困難，需要以改變需求來解脫困境。因此規格說明難以完善、需求的變更、以及通信中的模糊和誤解，都會成為軟體開發順利推進的障礙。為解決這些問題，逐漸形成了軟體系統的快速原型的概念。軟體原型的分類在軟體開發中，原型是軟體的一個早期可運行的版本，它反映最終系統的部分重要特性。

探索型：目的是要弄清對目標系統的要求，確定所希望的特性，並探討多種方案的可行性。

實驗型：這種原型用於大規模開發和實現之前，考核方案是否合適，規格說明是否可靠。

進化型：這種原型的目的不在於改進規格說明，而是將系統建造得易於變化，在改進原型的過程中，逐步將原型進化成最終系統。原型使用策略

廢棄策略追加策略

建立快速原型，進行系統的分析和構造的好處：

增進軟體者和用戶對系統服務需求的理解，使比較含糊的具有不確定性的軟體需求（主要是功能）明確化。軟體原型化方法提供了一種有力的學習手段。

使用原型化方法，可以容易地確定系統的性能，確認各項主要系統服務的可應用性，確認系統設計的可行性，確認系統作為產品的結果。軟體原型的最終版本，有的可以原封不動地成為產品，有的略加修改就可以成為最終系統的一個組成部分，這樣有利於建成最終系統。

原型開發技術可執行規格說明基於腳本(scenario)的設計自動程式設計專用語言可複用(reusable)的軟體簡化假設可執行規格說明可執行規格說明是用於需求規格說明的一種自動化技術。使用這種方法，人們可以直接觀察他們用語言規定的任何系統性行為。包括

代數規格說明

有限狀態模型

可執行的數據流圖

（1）代數規格說明代數規格說明使用集合、定義於這些集合上的函數和定義於這些函數上的方程來描述對象。規格說明的操作語義用這些方程表示。

NEW_STACK：→StackPUSH：Stack，Element→StackPOP：Stack→(Element|Undefined)POP(NEW_STACK())＝UndefinedPOP(PUSH(stk，elem))＝elem其中，前三行定義了操作的語法，後兩行把它們的語義定義為一些方程。舉例：定義一個無界的棧及其操作

（2）有限狀態模型parnas提出的使用最廣泛的一種可執行規格說明形式。從一個初始狀態開始接收輸入，到產生輸出，狀態在推移變化。施加在狀態元素上的約束確定了有效狀態的推移。舉例：建立用戶／程式對話

（3）可執行的數據流圖數據流圖是基於結構化開發方法的結構化規格說明用一種可執行的語言程式代替定義處理邏輯的結構化英語，數據流圖就成為由可執行語言程式模組組成的網路，在一定環境或工具的支持下就可成為一個可以執行的原型系統。

基於腳本的設計腳本是指用戶介面的原型。一個腳本用以模擬在系統運行期間用戶經歷的事件。它提供了輸入─處理─輸出的螢幕格式和有關對話的模型。因此，軟體開發者能夠給用戶顯示系統的逼真的視圖，使用戶得以判斷是否符合他的意圖。可在任一腳本中使用一套可複用的軟體模組，以表達某一方面的要求。可使用一種原型語言來描述原型系統。原型開發過程中用這種語言來定義螢幕、資料項目、及其相關的操作。從系統的外部描述開始，開發與資料庫的介面、錯誤處理和恢復過程等系統的與外部視圖一致的細節。

自動程式設計自動程式設計是指在程式自動生成環境的支持下，利用電腦實現軟體的開發。它可以自動地或半自動地把用戶的非過程式問題規格說明轉換為某種高級語言程式：

演繹綜合手段：基於數學推理的構造式證明。程式變換手段：將一程式轉換成另一功能等價的程式，並保持其正確性不變。實例推廣手段：從實例特徵出發，將它推廣為待編程序的特徵，最後得到程式。

過程化手段：研究甚高級語言的編譯和知識的過程化。

專用語言專用語言是應用領域的模型化語言。在原型開發中使用專用語言，可方便用戶和軟體開發者在計畫中的系統特性方面的交流。

軟體複用技術利用可複用的模組，做出適當的組合，就可得到快速構造的原型系統。為了快速地構造原型，這些模組首先必須有簡單而清晰的介面；其次它們應當儘量不依賴其他的模組或數據結構；第三，它們應具有一些通用的功能。

簡化假設簡化假設是在開發過程中使設計者迅速得到一個簡化的系統所做的假設。儘管這些假設可能實際上並不能成立，但它們在原型開發過程中可以使開發者的注意力集中在一些主要的方面。

在修改一個檔時，可以假設這個檔確實存在在存取檔時，待存取的記錄總是存在一旦計畫中的系統滿足用戶所有的要求，就可以撤銷這些假設，並追加一些細節。系統動態分析系統的需求規格說明通常是用自然語言來敘述的，但是用自然語言描述往往會出現歧義性。為了直觀地分析系統的動作，從特定的視點出發描述系統的行為，需要採用動態分析的方法。最常用的動態分析方法狀態遷移圖時序圖Petri網狀態遷移圖狀態遷移圖是描述系統的狀態如何相應外部的信號進行推移的一種圖形表示。

圓圈“○”表示可得到的系統狀態

箭頭“→”表示從一種狀態向另一種狀態的遷移。例如,當有多個申請佔用CPU運行的進程時,有關CPU分配的進程的狀態遷移。可得到的狀態＝就緒，運行，等待生成的事件＝t1，t2，

t3，

t4

t1─

中斷事件

t2─

中斷已處理

t3─

分配CPU

t4─

用完CPU時間狀態遷移圖的優點狀態之間的關係能夠直觀地捕捉到由於狀態遷移圖的單純性，能夠機械地分析許多情況，可很容易地建立分析工具在系統分析中，用時序圖於對比在系統中處理事件的時序和相應的處理時間。在右圖中,對於事件e,功能1～功能3

的處理時間總計為(T1

＋T2＋T3）其中功能間切換時間0。時序圖採用擴充時序圖可表示進程間的通信流,用於分析幾個事件的交錯現象。，C1與C2，R1與R2是交錯的。因此，可以做如下分析：“必須設計成HOST1在等待C1的回答R1期間要能接收從HOST2發出的命令C2。”Petri網

Petri網已廣泛地應用於硬體與軟體系統的開發中，它適用於描述與分析相互獨立、協同操作的處理系統，也就是併發執行的處理系統。Petri網簡稱PNG(PetriNetGraph)，它有兩種結點：位置(place)：符號為“○”，它用來表示系統的狀態。轉移(transition)：符號為“

”,它用來表示系統中的事件。

圖中的有向邊表示對轉移的輸入，或由轉移的輸出標記，或稱令牌(token)，是表明系統當前處於什麼狀態的標誌

處理兩個進程的同步問題

數據及資料庫需求在數據詞典中，強調對數據存儲結構的邏輯設計，並用數據結構表達資料項目之間的邏輯關係。但任何一個軟體系統都可能有成千上萬個數據項，僅僅描述這些資料項目是不夠的，更重要的是如何把它們以最優的方式組織起來，以滿足系統對數據的要求。有關資料庫的基本概念在軟體系統中需要處理的數據是現實世界中存在的事物及其聯繫的反映。人們通常將與數據處理有關的的領域分為三個世界：

現實世界資訊世界數據世界現實世界是存在於人們頭腦之外的客觀世界，現實世界中的事物可分成對象和性質兩大類。對象可以是人、是物，還可以是實際的東西或概念的東西，例如，大學、城市等。對象還可以指事物與事物間的聯繫。性質則是指事物的性質或特徵。資訊世界也叫做觀念世界，是現實世界在人們頭腦中的反映。客觀世界中的事物在資訊世界中叫做實體，反映事物之間聯繫的叫做實體模型。實體是由若干屬性的屬性值組成。屬性是實體某一方面的特徵，相應於事物的性質。例如，一個學生實體是如下的一個5元組：(951149,袁秋慧,女,19,軟體)5元組中每一元素是學生的某一屬性的屬性值。他們對應的屬性集合是：這些屬性集合表徵了“學生”實體的類型，叫做實體型。同一類型的實體的集合叫做實體集。數據世界則是資訊世界中資訊的數據化，現實世界中的事物及其聯繫在數據世界中用數據模型描述。(學號,姓名,性別,年齡,專業)描述每一實體的數據稱為記錄，描述屬性的數據叫做資料項目或字段。與實體集相對應的稱為檔。例如，學生檔就由多個記錄組成，這些記錄放在一起構成一個二維表。表中每一橫排叫做一個記錄或元組，每一縱列叫做一個屬性。

記錄由資料項目組成，正如實體由若干屬性的屬性值組成一樣。一般資料項目沿用屬性名。用做屬性名時表示觀念資訊，用做資料項目名時表示數據資訊。每個資料項目包括兩個特徵：即數據類型和數據長度。若干同類型的記錄構成檔。為了對檔中的記錄有效組織和存取，通常指定一個資料項目進行區別，這個資料項目叫做關鍵字。E-R方法(Entity-RelationshipApproach)和實體模型在需求分析階段進行資料庫邏輯設計過程中，使用E-R圖，可定義一個實體模型。實體模型是現實世界的純表示，它不涉及數據世界的數據結構、存取路徑、存取效率等問題。因此，它可以轉換成數據庫中的數據模型。數據可以按相應數據模型進行組織。E-R圖中表示實體聯繫的符號如下：在E-R圖中，每個方框表示實體型或屬性，方框之間的連線表示實體之間，或實體與屬性之間的聯繫。出現在連線上的短豎線可以看成是“1”，而圓圈隱含表示“0”。例如，在教學管理中，一個教師可以教授零門、一門或多門課程，每位學生也需要學習幾門課程。因此，教學管理中涉及的對象（實體型）有學生、教師和課程。用E-R圖描述它們之間的聯繫，得下圖。其中，學生與課程是多對多的聯繫，而教師與課程的聯繫是零、一對多。進一步，要確定屬性。例如，學生具有學號、姓名、性別、年齡、專業（其他略）等屬性；課程具有課程號、課程名、學分、學時數等屬性；教師具有職工號、姓名、年齡、職稱等屬性。此外，學生通過學號、分數與課程發生聯繫。如此可得教學實體模型。教學實體模型數據結構的規範化資訊域分析需要確定數據的內容，每個資料項目要用表格列出，最後組織成文件的邏輯結構，即面向應用而不是面向存儲的結構。為了便於資料庫的設計，常常要對這種結構做一些簡化，其中最常見的一種方法就是規範化技術。“規範化”將數據的邏輯結構歸結為滿足一定條件的二維表（關係）。

表格中每個資訊項必須是一個不可分割的資料項目，不可是組項。

表格中每一列(列表示屬性)中所有資訊項必須是同一類型，各列的名字(屬性名)互異，列的次序任意。

表格中各行(行表示元組)互不相同，行的次序任意。不滿足上述要求的二維表或關係，叫做非規範化關係。對於非規範化的關係，必須將它規範化，即利用更單純、更規則的關係來代替原來的關係。規範化的目的是：

消除數據冗餘，即消除表格中數據的重複；消除多義性，使關係中的屬性含義清楚、單一；使關係的“概念”單一化，讓每個資料項目只是一個簡單的數或字串，而不是一個組項或重複組；方便操作。使數據的插入、刪除與修改操作可行並方便；使關係模式更靈活，易於實現接近自然語言的查詢方式。用教學管理例說明如何規範化有三個實體型，即課程、學生和教師，用三個關係保存它們的資訊：

學生(學號，姓名，性別，年齡，專業，籍貫)

教師(職工號，姓名，年齡，職稱，工資級別，工資)

課程(課程號，課程名，學分，學時，課程類型)為表示實體型之間的聯繫，又建立兩個關係：

選課

(學號，課程號，聽課出勤率，作業完成率，分數)

教課

(職工號，課程號)這五個關係，組成了資料庫的模型。在每個關係中，屬性名下加下劃線）指明關鍵字。並規定關鍵字能唯一地標識一個元組。關係規範化的程度，通常按屬性間的依賴程度來區分，並以範式NF(NormalForm)來表達。常用的範式分為第一範式（1NF）、第二範式（2NF）和第三範式（3NF）。設Ｒ是一個關係，Ｘ和Ｙ是Ｒ中的兩個屬性。若對於Ｘ的任一個值，Ｙ僅有一個值與之對應，則稱Ｒ的屬性Ｙ函數依賴於屬性Ｘ。例如，教師(職工號,姓名,年齡,)其中，屬性“姓名”，“年齡”等都函數依賴於屬性“職工號”。屬性Ｘ可以是複合屬性，如：選課(學號,課程號,聽課出勤率,)如果屬性Ｙ函數依賴於複合屬性Ｘ，而不與Ｘ的任何真子集函數依賴，則稱屬性Ｙ完全函數依賴於複合屬性Ｘ。例如在“選課”關係中，屬性“聽課出勤率”、“作業完成率”和“分數”等表示某個學生學習某門課程時的學習情況。只有同時指定“學號”和“課程號”，才能準確地說明是哪位學生學習哪門課程時的學習情況。因此，“分數”等屬性完全函數依賴於“學號，課程號”。判斷規範化程度的條件是：

關係中所有屬性都是“單純域”，即不出現“表中有表”

非主屬性完全函數依賴於關鍵字

非主屬性相互獨立，即任何非主屬性間不存在函數依賴。如果一個關係連條件

都不滿足，則這個關係是非規範化的。如果一個關係僅滿足條件

，則這個關係滿足第一範式(1NF)。如果一個關係滿足條件

、

，但不滿足

，則這個關係滿足第二範式(2NF)。如果一個關係同時滿足條件

、

和

，則這個關係表滿足第三範式(3NF)。當數據模型達到3NF，一般情況下就能滿足資料庫應用的需要。資料庫分析的過程在需求分析階段進行資料庫分析的流程為開發一個系統所使用的資料庫，在開始分析資料庫的需求前，分析員必須瞭解該系統的總目標和範圍。然後建立一個完整並高度細化的資訊模型。此信息模型應包括一個綜合的數據詞典，定義所有在開發資料庫時用到的資料項目。接著資料庫分析定義資料庫的邏輯特性和物理特性。以資訊模型和系統規格說明為指導，定義資料庫的邏輯數據結構。這種邏輯結構必須適應數據存取、修改、關聯性及其它相關需求。一旦邏輯數據結構建立起來，就可以研製資料庫的物理結構。物理資料庫結構定義檔結構、記錄格式、與硬體相關的處理方式以及資料庫管理系統的特性。最後，要對模式和物理特性進行完全的評審。在資料庫分析過程中所考慮的因素間存在著複雜的相互聯繫。改變其中的任何一個因素都會（潛在地）影響其他的因素。所以必須在各個因素之間進行折衷。這種折衷包括專用性和通用性的折衷，資訊關聯程度、擴充潛力及操作特性等方面的折衷。考慮資訊關聯程度和擴充潛力（包括資訊規模和資訊內容兩方面）主要基於需求分析和設計階段分派給資料庫的專用性程度。專用的資料庫要為系統特定的資訊需求服務，因此資訊結構要設計得能適應要求的關聯性和預計的擴充。通用的資料庫可以適應更為廣泛的各種資訊需求，但是為了獲得通用性要付出代價。軟體設計的目標和任務根據用資訊域表示的軟體需求，以及功能和性能需求，進行數據設計系統結構設計過程設計。數據設計側重於數據結構的定義。系統結構設計定義軟體系統各主要成份之間的關係。過程設計則是把結構成份轉換成軟體的過程性描述。在編碼步驟，根據這種過程性描述，生成根源程式代碼，然後通過測試最終得到完整有效的軟體。開發階段的資訊流程式模組測試編碼設計資訊域需求功能與性能需求數據設計過程設計系統結構設計組裝好的有效的軟體軟體設計是後續開發步驟及軟體維護工作的基礎。如果沒有設計，只能建立一個不穩定的系統結構軟體設計任務從工程管理的角度來看，軟體設計分兩步完成。

概要設計，將軟體需求轉化為數據結構和軟體的系統結構。

詳細設計，即過程設計。通過對結構表示進行細化，得到軟體的詳細的數據結構和演算法。軟體設計過程1.制定規範在進入軟體開發階段之初，首先應為軟體開發組制定在設計時應該共同遵守的標準，以便協調組內各成員的工作。包括:

閱讀和理解軟體需求說明書，確認用戶要求能否實現，明確實現的條件，從而確定設計的目標，以及它們的優先順序根據目標確定最合適的設計方法規定設計文檔的編制標準規定編碼的資訊形式，與硬體，操作系統的介面規約，命名規則2.軟體系統結構的總體設計基於功能層次結構建立系統。採用某種設計方法，將系統按功能劃分成模組的層次結構確定每個模組的功能建立與已確定的軟體需求的對應關係確定模組間的調用關係確定模組間的介面評估模組劃分的品質3.處理方式設計確定為實現系統的功能需求所必需的演算法，評估演算法的性能確定為滿足系統的性能需求所必需的演算法和模組間的控制方式

周轉時間回應時間吞吐量精度確定外部信號的接收發送形式4.數據結構設計確定軟體涉及的檔系統的結構以及資料庫的模式、子模式，進行數據完整性和安全性的設計確定輸入，輸出檔的詳細的數據結構結合演算法設計，確定演算法所必需的邏輯數據結構及其操作確定對邏輯數據結構所必需的那些操作的程式模組(軟體包)限制和確定各個數據設計決策的影響範圍若需要與操作系統或調度程式介面所必須的控制表等數據時，確定其詳細的數據結構和使用規則數據的保護性設計

防衛性設計：在軟體設計中就插入自動檢錯，報錯和糾錯的功能

一致性設計：保證軟體運行過程中所使用的數據的類型和取值範圍不變在併發處理過程中使用封鎖和解除封鎖機制保持數據不被破壞冗餘性設計：針對同一問題，由兩個開發者採用不同的程式設計風格不同的演算法設計軟體，當兩者運行結果之差不在允許範圍內時，利用檢錯系統予以糾正，或使用表決技術決定一個正確結果。

5.可靠性設計可靠性設計也叫做品質設計在運行過程中，為了適應環境的變化和用戶新的要求，需經常對軟體進行改造和修正。在軟體開發的一開始就要確定軟體可靠性和其他品質指標，考慮相應措施，以使得軟體易於修改和易於維護。6.編寫概要設計階段的文檔概要設計階段完成時應編寫以下文檔：

概要設計說明書資料庫設計說明書用戶手冊制定初步的測試計畫7.概要設計評審可追溯性：確認該設計是否複蓋了所有已確定的軟體需求，軟體每一成份是否可追溯到某一項需求介面：確認該軟體的內部介面與外部介面是否已經明確定義。模組是否滿足高內聚和低耦合的要求。模組作用範圍是否在其控制範圍之內風險：確認該設計在現有技術條件下和預算範圍內是否能按時實現

實用性：確認該設計對於需求的解決方案是否實用技術清晰度：確認該設計是否以一種易於翻譯成代碼的形式表達可維護性：確認該設計是否考慮了方便未來的維護品質：確認該設計是否表現出良好的品質特徵各種選擇方案：看是否考慮過其他方案，比較各種選擇方案的標準是什麼限制：評估對該軟體的限制是否現實，是否與需求一致其他具體問題：對於文檔、可測試性、設計過程..等進行評估在詳細設計過程中，需要完成的工作是：確定軟體各個組成部分內的演算法以及各部分的內部數據組織選定某種過程的表達形式來描述各種演算法。進行詳細設計的評審詳細設計軟體設計基礎

自頂向下，逐步細化

軟體結構

程式結構

結構圖

模組化

抽象化

資訊隱蔽自頂向下，逐步細化將軟體的體系結構按自頂向下方式，對各個層次的過程細節和數據細節逐層細化，直到用程式設計語言的語句能夠實現為止，從而最後確立整個的體系結構。軟體結構軟體結構包括兩部分。程式的模組結構和數據的結構軟體的體系結構通過一個劃分過程來完成。該劃分過程從需求分析確立的目標系統的模型出發，對整個問題進行分割，使其每個部分用一個或幾個軟體成份加以解決，整個問題就解決了程式結構程式結構表明了程式各個部件(模組)的組織情況，是軟體的過程表示。

結構圖結構圖反映程式中模組之間的層次調用關係和聯繫：它以特定的符號表示模組、模組間的調用關係和模組間資訊的傳遞①

模組：模組用矩形框表示，並用模組的名字標記它。②

模組的調用關係和介面：模組之間用單向箭頭聯結，箭頭從調用模組指向被調用模組。③

模組間的資訊傳遞：當一個模組調用另一個模組時，調用模組把數據或控制資訊傳送給被調用模組，以使被調用模組能夠運行。而被調用模組在執行過程中又把它產生的數據或控制資訊回送給調用模組④

在模組A的箭頭尾部標以一個菱形符號，表示模組A有條件地調用另一個模組B。當一個在調用箭頭尾部標以一個弧形符號，表示模組A反復調用模組C和模組D。程式的系統結構圖模組化軟體系統的模組化是指整個軟體被劃分成若干單獨命名和可編址的部分，稱之為模組。這些模組可以被組裝起來以滿足整個問題的需求。把問題／子問題的分解與軟體開發中的系統／子系統或系統／模組對應起來，就能夠把一個大而複雜的軟體系統劃分成易於理解的比較單純的模組結構。抽象化軟體系統進行模組設計時，可有不同的抽象層次。在最高的抽象層次上，可以使用問題所處環境的語言概括地描述問題的解法。在較低的抽象層次上，則採用過程化的方法。(1)過程的抽象

在軟體工程中，從系統定義到實現，每進展一步都可以看做是對軟體解決方法的抽象化過程的一次細化。

在軟體需求分析階段，用“問題所處環境的為大家所熟悉的術語”來描述軟體的解決方法。

在從概要設計到詳細設計的過程中，抽象化的層次逐次降低。當產生根源程式時到達最低抽象層次。例:開發一個CAD軟體的三層抽象抽象層次Ⅰ.

用問題所處環境的術語來描述這個軟體:

该软件包括一个计算机绘图界面，向绘图员显示图形，以及一个数字化仪界面，用以代替绘图板和丁字尺。所有直线、折线、矩形、圆及曲线的描画、所有的几何计算、所有的剖面图和辅助视图都可以用这个CAD軟體實現……。抽象層次Ⅱ.

任務需求的描述。

CADSOFTWARETASKS

userinteractiontask;

2-Ddrawingcreationtask;graphicsdisplaytask;

drawingfilemanagementtask;

end.

在这个抽象层次上，未给出“怎样做”的信息，不能直接实现。抽象層次Ⅲ.

程式過程表示。以2-D(二維)繪圖生成任務為例:

PROCEDURE：2-Ddrawingcreation

REPEATUNTIL(drawingcreationtaskterminates)

DOWHILE(digitizerinteractionoccurs)digitizerinterfacetask;

DETERMINEdrawingrequestCASE;

line：linedrawingtask;

rectangle：rectangledrawingtask;

circle：circledrawingtask;

……(2)數據抽象

在不同層次上描述數據對象的細節，定義與該數據對象相關的操作。

例如，在CAD軟體中，定義一個叫做drawing的數據對象。可將drawing規定為一個抽象數據類型，定義它的內部細節為:

TYPEdrawingISSTRUCTUREDEFIND

numberISSTRINGLENGTH(12);

geometryDEFIND……

notesISSTRINGLENGTH(256);

BOMDEFIND

ENDdrawingTYPE;數據抽象drawing本身由另外一些數據抽象，如geometry、BOM(billofmaterials)構成定義drawing的抽象數據類型之後，可引用它來定義其他數據對象，而不必涉及drawing的內部細節例如，定義:

blue-printISINSTANCEOFdrawing;

或

schematicISINSTANCEOFdrawing;

資訊隱蔽由parnas方法提倡的資訊隱蔽是指，每個模組的實現細節對於其他模組來說是隱蔽的。也就是說，模組中所包含的資訊（包括數據和過程）不允許其他不需要這些資訊的模組使用。模組的獨立性模組（Module） “模組”，又稱“組件”。它一般具有如下三個基本屬性:功能：描述該模組實現什麼功能邏輯：描述模組內部怎麼做狀態：該模組使用時的環境和條件在描述一個模組時，還必須按模組的外部特性與內部特性分別描述模組的外部特性模組的模組名、參數表、其中的輸入參數和輸出參數，以及給程式以至整個系統造成的影響模組的內部特性完成其功能的程式代碼和僅供該模組內部使用的數據模組獨立性模組獨立性,是指軟體系統中每個模組只涉及軟體要求的具體的子功能,而和軟體系統中其他的模組的介面是簡單的例如,若一個模組只具有單一的功能且與其它模組沒有太多的聯繫,則稱此模組具有模組獨立性一般採用兩個準則度量模組獨立性。即模組間耦合和模組內聚

耦合是模組之間的互相連接的緊密程度的度量。

內聚是模組功能強度(一個模組內部各個元素彼此結合的緊密程度)的度量。模組獨立性比較強的模組應是高內聚低耦合的模組。模組間的耦合

非直接耦合(NondirectCoupling)

兩個模組之間沒有直接關係，它們之間的聯繫完全是通過主模組的控制和調用來實現的。非直接耦合的模組獨立性最強。數據耦合(DataCoupling)

一個模組訪問另一個模組時，彼此之間是通過簡單數據參數

(不是控制參數、公共數據結構或外部變數)來交換輸入、輸出資訊的。標記耦合(StampCoupling)

一組模組通過參數表傳遞記錄資訊，就是標記耦合。這個記錄是某一數據結構的子結構，而不是簡單變數。控制耦合(ControlCoupling)

如果一個模塊通過傳送開關、標誌、名字等控制資訊，明顯地控制選擇另一模組的功能，就是控制耦合。外部耦合（ExternalCoupling）

一組模組都訪問同一全局簡單變數而不是同一全局數據結構，而且不是通過參數表傳遞該全局變數的資訊，則稱之為外部耦合。公共耦合（CommonCoupling）

若一組模組都訪問同一个公共数据环境，則它們之間的耦合就稱為公共耦合。公共的數據環境可以是全局數據結構、共用的通信區、記憶體的公共覆蓋區等。公共耦合的複雜程度隨耦合模組的個數增加而顯著增加。若只是兩模組間有公共數據環境，則公共耦合有兩種情況。鬆散公共耦合和緊密公共耦合。內容耦合(ContentCoupling)

如果發生下列情形，兩個模組之間就發生了內容耦合

(1)一個模組直接訪問另一個模組的內部數據;

(2)一个模块不通过正常入口转到另一模块内部;

(3)两个模块有一部分程序代码重迭(只可能出現在組合語言中);

(4)一个模块有多个入口。

c

模組內聚功能內聚

(FunctionalCohesion)

一個模組中各個部分都是完成某一具體功能必不可少的組成部分，或者說該模組中所有部分都是為了完成一項具體功能而協同工作，緊密聯繫，不可分割的。則稱該模組為功能內聚模組。資訊內聚

(InformationalCohesion)

這種模組完成多個功能，各個功能都在同一數據結構上操作，每一項功能有一個唯一的入口點。這個模組將根據不同的要求，確定該執行哪一個功能。由於這個模組的所有功能都是基於同一個數據結構（符號表），因此，它是一個資訊內聚的模組。資訊內聚模組可以看成是多個功能內聚模組的組合，並且達到資訊的隱蔽。即把某個數據結構、資源或設備隱蔽在一個模組內，不為別的模組所知曉。通信內聚

(CommunicationCohesion)

如果一個模組內各功能部分都使用了相同的輸入數據，或產生了相同的輸出數據，則稱之為通信內聚模組。通常，通信內聚模組是通過數據流圖來定義的。過程內聚（ProceduralCohesion）

使用流程圖做為工具設計程式時，把流程圖中的某一部分劃出組成模組，就得到過程內聚模組。例如，把流程圖中的迴圈部分、判定部分、計算部分分成三個模組，這三個模組都是過程內聚模組。時間內聚（ClassicalCohesion）

時間內聚又稱為經典內聚。這種模組大多為多功能模組，但模組的各個功能的執行與時間有關，通常要求所有功能必須在同一時間段內執行。例如初始化模組和終止模組。邏輯內聚（LogicalCohesion）

這種模組把幾種相关的功能组合在一起，每次被調用時，由傳送給模組的判定參數來確定該模組應執行哪一種功能。巧合內聚（CoincidentalCohesion）

巧合內聚(偶然內聚)。當模組內各部分之間沒有聯繫，或者即使有聯繫，這種聯系也很鬆散，則稱這種模塊為巧合內聚模組，它是內聚程度最低的模組。結構化設計方法首先研究、分析和審查數據流圖。從軟體的需求規格說明中弄清數據流加工的過程，對於發現的問題及時解決。然後根據數據流圖決定問題的類型。數據處理問題典型的類型有兩種：變換型和事務型。針對兩種不同的類型分別進行分析處理。

由數據流圖推導出系統的初始結構圖。利用一些啟發式原則來改進系統的初始結構圖，直到得到符合要求的結構圖為止。修改和補充數據詞典。制定測試計畫。

在系統結構圖中的模組傳入模組─從下屬模組取得數據，經過某些處理，再將其傳送給上級模組。它傳送的數據流叫做邏輯輸入數據流。傳出模組─從上級模組獲得數據，進行某些處理，再將其傳送給下屬模組。它傳送的數據流叫做邏輯輸出數據流。變換模組─它從上級模組取得數據，進行特定的處理，轉換成其他形式，再傳送回上級模組。它加工的數據流叫做變換數據流。協調模組─對所有下屬模組進行協調和管理的模組。變換型系統結構圖變換型數據處理問題的工作過程大致分為三步，即取得數據，變換數據和給出數據。相應於取得數據、變換數據、給出數據，變換型系統結構圖由輸入、中心變換和輸出等三部分組成。事務型系統結構圖它接受一項事務，根據事務處理的特點和性質，選擇分派一個適當的處理單元，然後給出結果。在事務型系統結構圖中，事務中心模組按所接受的事務的類型，選擇某一事務處理模組執行。各事務處理模組並列。每個事務處理模組可能要調用若干個操作模組，而操作模組又可能調用若干個細節模組。變換分析變換分析方法由以下四步組成：重畫數據流圖；區分有效(邏輯)輸入、有效(邏輯)輸出和中心變換部分；進行一級分解，設計上層模組；進行二級分解，設計輸入、輸出和中心變換部分的中、下層模組。①

在選擇模組設計的次序時，必須對一個模組的全部直接下屬模組都設計完成之後，才能轉向另一個模組的下層模塊的設計。②

在設計下層模組時，應考慮模組的耦合和內聚問題，以提高初始結構圖的品質。③使用“黑箱”技術:在設計當前模組時，先把這個模組的所有下層模組定義成“黑箱”，在設計中利用它們時，暫時不考慮其內部結構和實現。在這一步定義好的“黑箱”，在下一步就可以對它們進行設計和加工。這樣，又會導致更多的“黑箱”。最後，全部“黑箱”的內容和結構應完全被確定。④

在模組劃分時，一個模組的直接下屬模組一般在5個左右。如果直接下屬模組超過10個，可設立中間層次。⑤如果出現了以下情況，就停止模組的功能分解：

當模組不能再細分為明顯的子任務時；

當分解成用戶提供的模組或程式庫的副程式時；

當模組的介面是輸入／輸出設備傳送的資訊時；

當模組不宜再分解得過小時。

事務分析在很多軟體應用中，存在某種作業數據流，它可以引發一個或多個處理，這些處理能夠完成該作業要求的功能。這種數據流就叫做事務。與變換分析一樣，事務分析也是從分析數據流圖開始，自頂向下，逐步分解，建立系統到結構圖。

事務分析過程①

識別事務源

利用數據流圖和數據詞典，從問題定義和需求分析的結果中，找出各種需要處理的事務。通常，事務來自物理輸入裝置。有時，設計人員還必須區別系統的輸入、中心加工和輸出中產生的事務。②

規定適當的事務型結構

在確定了該數據流圖具有事務型特徵之後，根據模組劃分理論，建立適當的事務型結構。③

識別各種事務和它們定義的操作。

從問題定義和需求分析中找出的事務及其操作所必需的全部資訊，對於系統內部產生的事務，必須仔細地定義它們的操作。④

注意利用公用模組

在事務分析的過程中，如果不同事務的一些中間模組可由具有類似的語法和語義的若干個低層模組組成，則可以把這些低層模組構造成公用模組。⑤

對每一事務，或對聯系密切的一組事務，建立一個事務處理模組；

如果發現在系統中有類似的事務，可以把它們組成一個事務處理模組。⑥

對事務處理模組規定它們全部的下層操作模組⑦對操作模組規定它們的全部細節模組

變換分析是軟體系統結構設計的主要方法。一般，一個大型的軟體系統是變換型結構和事務型結構的混合結構。所以，我們通常利用以變換分析為主，事務分析為輔的方式進行軟體結構設計。

軟體模組結構的改進模組功能的完善化

一個完整的模組應當有以下幾部分：

①執行規定的功能的部分；

②出錯處理的部分。當模組不能完成規定的功能時，必須回送出錯標誌，出現例外情況的原因。

③如果需要返回數據給它的調用者，在完成數據加工或結束時，應當給它的調用者返回一個狀態碼。

消除重複功能，改善軟體結構

①

完全相似：在結構上完全相似，可能只是在數據類型上不一致。此時可以採取完全合併的方法。

②局部相似：找出其相同部分，分離出去，重新定義成一個獨立的下一層模組。還可以與它的上級模組合併。模組的作用範圍應在控制範圍之內

模組的控制範圍包括它本身及其所有的從屬模組。模組的作用範圍是指模組內一個判定的作用範圍，凡是受這個判定影響的所有模組都屬於這個判定的作用範圍。如果一個判定的作用範圍包含在這個判定所在模組的控制範圍之內，則這種結構是簡單的，否則，它的結構是不簡單的。

盡可能減少高扇出結構，隨著深度增大扇入。

如果一个模块的扇出数过大，就意味着该模块过分复杂，需要协调和控制过多的下属模块。应当适当增加中间层次的控制模块。

避免或減少使用病態聯接

應限制使用如下三種病態聯接：

①

直接病態聯接即模組A直接從模組B內部取出某些數據，或者把某些數據直接送到模組B內部。

②

公共數據域病態聯接模組A和模組B通過公共數據域，直接傳送或接受數據，而不是通過它們的上級模組。這種方式將使得模組間的耦合程度劇增。它不僅影響模組Ａ和模組Ｂ，而且影響與公共數據域有關聯的所有模組。③

通信模組聯接即模組A和模組B通過通信模組TABLEIT傳送數據。從表面看，這不是病態聯接，因為模組Ａ和模組B都未涉及通信模組TABLEIT的內部。然而，它們之間的通信（即數據傳送）沒有通過它們的上級模組。從這個意義上講，這種聯接是病態的。模組的大小要適中

模組的大小，可以用模組中所含語句的數量的多少來衡量。把模組的大小限制在一定的範圍之內。通常規定其語句行數在50～100左右，保持在一頁紙之內，最多不超過500行。設計功能可預測的模組，但要避免過分受限制的模組一個功能可預測的模組，不論內部處理細節如何，但對相同的輸入數據，總能產生同樣的結果。但是，如果模組內部蘊藏有一些特殊的鮮為人知的功能時，這個模組就可能是不可預測的。對於這種模組，如果調用者不小心使用，其結果將不可預測。

如果一個模組的局部數據結構的大小、控制流的選擇或者與外界(人、硬軟體)的介面模式被限制死了，則很難適應用戶新的要求或環境的變更。為了能夠適應將來的變更，軟體模組中局部數據結構的大小應當是可控制的，控制流的選擇對於調用者來說，應當是可預測的。而與外界的介面應當是靈活的。

軟體包應滿足設計約束和可移植性

為了使得軟體包可以在某些特定的環境下能夠安裝和運行，對軟體包提出了一些設計約束和可移植的要求。例如，設計約束有時要求一個程式段在記憶體中覆蓋自身。當這種情況出現時，設計出來的軟體程式結構不得不根據重複程度、訪問頻率、調用間隔等等特性，重新加以組織。設計的後處理為每一個模組寫一份處理說明為每一個模組提供一份介面說明確定全局數據結構和局部數據結構指出所有的設計約束和限制進行概要設計的評審進行設計的優化(如果需要和可能的話)數據設計及檔設計數據設計的原則檔設計數據設計的原則R.S.Pressman數據設計的過程

為在需求分析階段所確定的數據對象選擇邏輯表示，需要對不同結構進行演算法分析，以便選擇一個最有效的結構；設計對於這種邏輯數據結構的一組操作，以實現各種所期望的運算。

確定對邏輯數據結構所必需的那些操作的程式模組(軟體包)，以便限制或確定各個數據設計決策的影響範圍。Pressman提出了一組原則，用來定義和設計數據。實際上，在進行需求分析時往往就開始了數據設計。1.用於軟體的系統化方法也適用於數據。在導出、評審和定義軟體的需求和軟體系統結構時，必須定義和評審其中所用到的數據流、數據對象及數據結構的表示。應當考慮幾種不同的數據組織方案，還應當分析數據設計給軟體設計帶來的影響。2.確定所有的數據結構和在每種數據結構上施加的操作。設計有效的數據結構，必須考慮到要對該數據結構進行的各種操作。3.應當建立一個數據詞典並用它來定義數據和軟體的設計。數據詞典清楚地說明了各個數據之間的關係和對數據結構內各個數據元素的約束。

4.低層數據設計的決策應推遲到設計過程的後期進行。在進行需求分析時確定的總體數據組織，應在概要設計階段加以細化，在詳細設計階段才規定具體的細節。5.數據結構的表示只限於那些必須直接使用該數據結構內數據的模組才能知道。此原則就是資訊隱蔽和與此相關的耦合性原則。6.應當建立一個存放有效數據結構及相關操作的庫。數據結構應當設計成為可複