【文章內(nèi)容簡介】 、 外部耦合 、 公共耦合 、 內(nèi)容耦合 ， 它們的耦合程度由低到高 。 75 （ 2） 概要設計的基本原理 4)模塊獨立性 __內(nèi)聚性 又稱塊內(nèi)聯(lián)系 。 指模塊的功能強度的度量 ， 即一個模塊內(nèi)部各個元素彼此結合的緊密程度的度量 。 若一個模塊內(nèi)各元素 （ 語句之間 、 程序段之間 ） 聯(lián)系的越緊密 ， 則它的內(nèi)聚性就很高 。 內(nèi)聚性有以下七類類型： 偶然內(nèi)聚 、 邏輯內(nèi)聚 、 時間內(nèi)聚 、 過程內(nèi)聚 、 通信內(nèi)聚 、 順序內(nèi)聚 、 功能內(nèi)聚 ， 它們的內(nèi)聚程度由低到高 。 76 2. 概要設計 軟件結構：表示程序的總體結構，指程序的控制層次體系（多少模塊，多少層次，調(diào)用關系） 77 一個問題可以有多種結構來表示 78 軟件結構的術語 深度：控制的層次數(shù) 寬度：控制的總跨度，即最多模塊一層的模塊數(shù) 扇出：一個模塊直接控制的模塊數(shù) 扇入：一個模塊被幾個模塊直接控制 79 軟件結構的術語 從屬： A模塊控制 B模塊，則 B從屬 A 統(tǒng)率： A模塊控制 B模塊，則 A統(tǒng)率 B 80 C1和 C2中， C1’和 C， C2’和 C，可能是偶然性塊內(nèi)聯(lián)系，把它們從各自的模塊分離出來， C1’， C2’和 C的塊內(nèi)聯(lián)系增大，模塊獨立性增強，塊間聯(lián)系看起來增大一些，又通過模塊的合并，得到圖（ c）（ d）塊內(nèi)聯(lián)系大，塊間聯(lián)系相應小些（模塊個數(shù)少）。 81 ?模塊調(diào)用個數(shù)最好不要超過五個 ?一個模塊具有過多的調(diào)用模塊或被調(diào)用模塊，那么它往往包含過多的功能，這就是這個模塊太復雜 ?除特殊情況外（ case，開關），應避免這種結構，用增加層次以減少調(diào)用個數(shù)。 ?五個是經(jīng)驗得來的 82 結構化設計技術（ＳＤ） ?ＳＤ是ＩＢＭ公司提出的，是長期程序設計的經(jīng)驗總結。 ?下面將介紹如何建立系統(tǒng)的模塊結構。 數(shù)據(jù)流圖的類型 ?ＳＤ是以數(shù)據(jù)流為基礎來設計軟件的模塊結構，那么我們首先要找出數(shù)據(jù)流圖的一些規(guī)律，從而導出軟件的初始結構。 83 變換類型數(shù)據(jù)流圖 定義：具體較明顯的輸入，變換（或稱主加工）和輸出界面的數(shù)據(jù)流圖。 84 事務型數(shù)據(jù)流圖 定義：圖中某個加工將它的輸入數(shù)據(jù)流分離成一串發(fā)散的數(shù)據(jù)流，形成許多活動的路徑（分支），并根據(jù)輸入的值選擇其中的一個路徑，具有這樣特征的數(shù)據(jù)流圖。 事務中心：把輸入數(shù)據(jù)流分離成一串發(fā)散數(shù)據(jù)流的加工。 85 設計步驟：總述 —— 模型 —— 實例 第一步：復查基本系統(tǒng)模型 這一步將看到軟件的 原型 ，傳統(tǒng)方法往往是從這一步開始的 。 在做這一步時， 要對以前建立的基本數(shù)據(jù)模型 ，再作最后的審查，是否有遺漏的輸入或輸出。 第二步：復查并精化數(shù)據(jù)流圖 對數(shù)據(jù)流圖的最后復審求精要慎重，一定要保證數(shù)據(jù)流圖的正確性 。不同的選擇 導出的軟件初始模塊圖的合理性有些差異。 86 設計步驟：總述 —— 模型 —— 實例 第三步：確定數(shù)據(jù)流圖的類型： 變換型與事務型。 變換設計： 從變換型數(shù)據(jù)流圖導出軟件模塊結構的過程。 如何劃分輸入、主加工、輸出三個部分 ？ ?從兩頭向中間，先找出邏輯輸入和邏輯輸出，找到它們即可劃分出三個部分。 87 88 第四步：設計上層模塊結構 ：自頂向下的設計方法。 ?頂層：主模塊，對應于主加工。 ?一層：標準的一層，對應于變換數(shù)據(jù)流圖的三個部分，三個模塊 89 第五步：設計軟件的中下層模塊結構 （基于數(shù)據(jù)流圖）。 90 第六步：對初始模塊求精，得到合理的軟件結構。 91 2. 軟件詳細設計 （ 1）詳細設計基本任務 （ 2）結構化程序設計方法 92 （ 1）詳細設計基本任務 1)為每個模塊進行 詳細的算法 設計 。 2)為模塊內(nèi)的 數(shù)據(jù)結構 進行設計 。 3)對數(shù)據(jù)庫進行物理設計 ， 即確定 數(shù)據(jù)庫的物理結構 。 4)其他設計 。 根據(jù)軟件系統(tǒng)的類型 ， 還可能要進行以下設計：代碼設計 、 輸入輸出格式設計 、 人機對話設計 。 5)編寫 詳細設計說明書 。 6)為每一個模塊設計一組 測試用例 。 7) 評審 。 對處理過程的算法和數(shù)據(jù)庫的物理結構都要評審 。 93 （ 2）結構化程序設計方法 結構化程序設計是 1965年提出的 。 它的主要觀點是采用自頂向下 、 逐步求精的程序設計方法；使用三種基本控制結構構造程序 ， 任何程序都可由順序 、選擇 、 重復三種基本控制結構構造 。 詳細描述處理過程常用三種工具： 圖形、表格和語言。 圖形： 程序流程圖、 NS圖 、 PAD圖 表格： 判定表 語言： 過程設計語言（ PDL） 94 四、 軟件編碼 軟件編碼是將詳細設計得到的處理過程的描述轉換為基于某種計算機語言的程序，即源程序代碼。 需注意根據(jù)項目的應用領域選擇適當?shù)木幊陶Z言、編程的軟硬件環(huán)境以及編碼的程序設計風格等事項 95 四、 軟件編碼 Fourth Generation Languages ? 1st generation languages ? machine languages (binary) ? 2nd generation languages ? assemblers ? 3rd generation languages ? highlevel languages ? FORTRAN, COBOL, C, C++… ? each statement indended to be ~ 510 assembler stmts ? 4th generation languages (4GLS) ? each statement indended to be ~ 3050 assembler stmts ? easier/faster to program ? reduces costs ? declarative – say what you want, not how to do it (., SQL Structured Query Language ) ? success has been mixed ? positives ? fast response from DP dept. ? work well for DB apps ? negatives ? slow inefficient 96 程序風格 ? 程序?qū)嶋H上也是一種供人閱讀的文章，有一個文章的風格問題。應該使程序具有良好的風格。 ? 源程序文檔化 ? 數(shù)據(jù)說明 ? 語句結構 ? 輸入／輸出方法 97 源程序文檔化 ? 標識符的命名 ? 安排注釋 ? 程序的視覺組織 98 標識符的命名 ? 符號名即標識符，包括模塊名、變量名、常量名、標號名、子程序名、 數(shù)據(jù)區(qū)名以及緩沖區(qū)名等。 ? 名字應能反映它所代表的對象，應有一定實際意義。 ? 名字不是越長越好，應當選擇精煉的意義明確的名字。必要時可使用縮寫名字，但這時要注意縮寫規(guī)則要一致，并且要給每一個名字加注釋。 ? 在一個程序中，一個變量只應用于一種用途。 99 程序的注釋 ? 夾在程序中的注釋是程序員與日后的程序讀者之間通信的重要手段。 ? 注釋決不是可有可無的。 ? 一些正規(guī)的程序文本中，注釋行的數(shù)量占到整個源程序的 1／ 3到 1／ 2，甚至更多。 ? 注釋分為 序言性注釋 和 功能性注釋 。 100 序言性注釋 ? 通常置于每個程序模塊的開頭部分，它應當給出程序的整體說明，對于理解程序本身具有引導作用。有些軟件開發(fā)部門對序言性注釋做了明確而嚴格的規(guī)定，要求程序編制者逐項列出。 ? 有關項目包括： ? 程序標題； ? 有關本模塊功能和目的的說明； ? 主要算法； ? 接口說明：包括調(diào)用形式，參數(shù)描述，子程序清單； 101 序言性注釋 ? 有關數(shù)據(jù)描述：重要的變量及其用途，約束或限制條件，以及其它有關信息； ? 模塊位置：在哪一個源文件中，或隸屬于哪一個軟件包； ? 開發(fā)簡歷：模塊設計者，復審者，復審日期，修改日期及有關說明等。 102 功能性注釋 ? 功能性注釋嵌在源程序體中，用以描述其后的語句或程序段是在做什么工作，或是執(zhí)行了下面的語句會怎么樣。而不要解釋下面怎么做。 ? 要點： ? 描述一段程序，而不是每一個語句； ? 用縮進和空行，使程序與注釋容易區(qū)別； ? 注釋要正確。 103 程序的視覺組織 ? 恰當?shù)乩?空格 ，可以突出運算的優(yōu)先性，避免發(fā)生運算的錯誤。 ? 自然的程序段之間可用空行隔開； ? 移行也叫做向右縮格。 ? 它是指程序中的各行不必都在左端對齊，都從第一格起排列。這樣做使程序完全分不清層次關系。 ? 對于選擇語句和循環(huán)語句，把其中的程序段語句向右做 階梯式移行 。使程序的邏輯結構更加清晰。 104 數(shù)據(jù)說明 ? 在設計階段已經(jīng)確定了數(shù)據(jù)結構的組織及其復雜性。在編寫程序時，則需要注意數(shù)據(jù)說明的風格。 ? 為了使程序中數(shù)據(jù)說明更易于理解和維護，必須注意以下幾點。 105 數(shù)據(jù)說明 ? 數(shù)據(jù)說明次序規(guī)范化，使數(shù)據(jù)屬性容易查找，也有利于測試，排錯和維護。 ? 原則上，數(shù)據(jù)說明的次序與語法無關，其次序是任意的。但出于閱讀、理解和維護的需要，最好使其規(guī)范化，使說明的先后次序固定。 ? 當多個變量名在一個說明語句中說明時，應當對這些變量按字母的順序排列。帶標號的全程數(shù)據(jù)也應當按字母的順序排列。 106 數(shù)據(jù)說明 ? 如果設計了一個復雜的數(shù)據(jù)結構，應當使用注釋來說明在程序?qū)崿F(xiàn)時這個數(shù)據(jù)結構的固有特點。 107 語句結構 ? 在設計階段確定了軟件的邏輯流結構，但構造單個語句則是編碼階段的任務。 語句構造力求簡單，直接， 不能為了片面追求效率而使語句復雜化 。 在一行內(nèi)只寫一條語句 程序編寫首先應當考慮清晰性 程序編寫首先應當考慮清晰性，不要刻意追求技巧性，使程序編寫得過于緊湊。 程序要能直截了當?shù)卣f明程序員的用意 。 108 語句結構 4. 除非對效率有特殊的要求 , 程序編寫要做到清晰第一，效率第二 。不要為了追求效率而喪失了 清晰性 。事實上，程序效率的提高主要應通過選擇高效的算法來實現(xiàn)。 , 然后才要求提高速度。反過來說，在使程序高速運行時，首先要保證它是正確的。 。 7. 讓編譯程序做簡單的優(yōu)化。 8. 盡可能使用庫函數(shù) 9. 避免不必要的轉移。 109 語句結構 。 11. 避免使用空的 ELSE語句和 IF… THEN IF… 的語句。 。 “否定”條件的條件語句 14. 盡可能用通俗易懂的偽碼來描述程序的流程，然后再翻譯成必須使用的語言。 15. 數(shù)據(jù)結構要有利于程序的簡化。 16. 要模塊化，使模塊功能盡可能單一化，模塊間的耦合能夠清晰可見。 110 語句結構 17. 利用信息隱蔽，確保每一個模塊的獨立性。 18. 從數(shù)據(jù)出發(fā)去構造程序。 19. 不要修補不好的程序，要重新編寫。也不要一味地追求代碼的復用，要重新組織。 20. 對太大的程序，要分塊編寫、測試，然后再集成。 21. 對遞歸定義的數(shù)據(jù)結構盡量使用遞歸過程。 111 輸入 /輸出 ? 在設計和編碼時都應考慮下列原則： 1. 對所有的輸入數(shù)據(jù)都要進行檢驗，識別錯誤的輸入，以保證每個數(shù)據(jù)的有效性； 2. 檢查輸入項的各種重要組合的合理性，必要時報告輸入狀態(tài)信息； 3. 使得輸入的步驟和操作盡可能簡單，并保持簡單的輸入格式； 112 輸入 /輸出 4. 輸入數(shù)據(jù)時，應允許使用自由格式輸入； 5. 應允許缺省值； 6. 輸入一批數(shù)據(jù)時，最好使用輸入結束標志，而不要由用戶指定輸入數(shù)據(jù)數(shù)目； 7. 在交互式輸入輸入時，要在屏幕上使用提示符明確提示交互輸入的請求，指明可使用選擇項的種類和取值范圍。同時，在數(shù)據(jù)輸入的過程中和輸入結束時，也要在屏幕上給出狀態(tài)信息； 8. 當程序設計語言對輸入／輸出格式有嚴格要求時，應保持輸入格式與輸入語句的要求的一致性； 9. 給所有的輸出加注解，并設計輸出報表格式。 113 五、軟件測試與調(diào)試 〈 一 〉 軟件測試 1. 軟件測試概念及目的 2. 軟件測試的原則 3. 軟件測試方法 4. 軟件測試對象 5. 測試與軟件開發(fā)各階段的關系 6. 軟件測試過程 7. 測試用例設計 114 一 軟件測試 測試階段的基本任務： 是根據(jù)軟件開發(fā)各