【正文】 叫轉移功能。 ?CC08交換機應該提供鬧鐘服務功能。 這個“等”包含哪些內容？怎么測試？ 測試人員 需求范例 69 課程內容 ?為什么要文檔化 ?文檔寫作基本要求 ?需求設計文檔模板 ?需求文檔寫作 ?設計文檔寫作 設計文檔大綱 (開發(fā)項目 ) 零層設計 一層設計 二層設計 配置和 控制 簡介 模塊 1 詳設 數(shù)據庫 模塊 n 詳設 …… HLD LLD 上下文定義 設計思路 分解描述 依賴性描述 接口描述 …… 分解描述 依賴性描述 接口描述 …… 數(shù)據描述 函數(shù)描述 開發(fā)項目： 系統(tǒng)總體設計 子系統(tǒng)設計 系統(tǒng)對外關系 ?HLD分解層次一般不超過 3層（ 0層、 1層、 2層），每層的模塊數(shù)以 2到 4個為宜，最多不要超過 7個。 單元模塊函數(shù)總數(shù)也不超過 7個； ?HLD階段將所有函數(shù)全部分解出來， LLD階段不再關注模塊分解； ?HLD使用 結構圖 描述函數(shù)的調用關系； ?函數(shù)分解規(guī)模以 30~50行 (非空非注釋 )為宜，最大不超過200行。每個函數(shù)的復雜度控制在 10以內，即：一個函數(shù)中不能有太多的 if， else， for, switch…case 等邏輯； ?LLD階段寫 偽碼 ，推薦在 source insight中寫，完成后嵌入 LLD中。偽碼的粗細程度以適宜作注釋為標準； 設計文檔寫作要點 結構圖 (structure chart)描述了一個系統(tǒng)的模塊劃分，體現(xiàn)了模塊之間的層次、組織和通信關系 示例： 結構圖 偽碼 又叫 PDL(Program Design Language)，是一種混合語言，用自然語言（如英語、漢語等）描述程序的處理邏輯，用一定的關鍵字語法（如 if、 else等）定義控制結構和數(shù)據結構。 優(yōu)點： ?維護方便 ?容易評審 ?作為代碼注釋 缺點： ?不容易掌握粗細 ?容易寫成代碼 偽碼 偽碼 = 關鍵字語法 + 自然語言描述 偽碼 ?使用 C語言的語法書寫偽代碼，使用標準符號，如： if, else, { }, while等； ?用描述性語言來描述； if（接口是以太網接口） if（ InterfaceType == ETHERNET) ?詳略得當。用概括性的語句來描述具體的處理，要求在每個邏輯處理分支用簡練、概括性的語言描述處理，而不要局限于處理的細節(jié)。 封裝 IP報文頭的內容 。 用收到報文的源地址來設置發(fā)送報文的目的地址 。 用發(fā)送報文接口的地址來設置發(fā)送報文的源地址 。 偽碼寫作說明： 75 設計樣例 設計文檔大綱 (增強、移植項目 ) 移植或增強項目： 修改分類 1 修改原因 影響分析 修改描述 修改點 1 修改點 n …… …… 修改分類 N 增強、移植設計 修改分類： ? 對所有需要的修改點進行分類，一個修改分類包含一個或多個修改點，實現(xiàn)一相對獨立的功能； ? 每個修改分類都應使用有明確含義的標題，如：“關于 XXX的修改”。 修改分類一 關于將 MQC策略應用到 ATM PVC接口下的修改 修改點： ? 一個修改點描述一處修改，如一個數(shù)據結構的修改，一個宏定義的修改，一個函數(shù)的修改等； ? 修改點也應使用有意義的標題，不要使用“修改點 1”等。 增強、移植設計 修改原因： ? 針對每個修改點，具體闡述為什么需要修改，如因為某某處理流程的變化，功能的擴展，界面的變化，性能的優(yōu)化等； ? 不應該描述修改什么，這是修改描述部分應詳細介紹的內容； ? 修改原因中的描述應有助于對修改描述的理解。 修改 原因 影響分析 修改描述 增強、移植設計 影響分析： ? 應評估修改對原模塊有無沖擊，從功能、性能、接口等多方面進行評估； ? 應評估修改對系統(tǒng)資源的消耗情況； ? 應描述為了配合此修改點還需要作哪些修改，即將各修改點關聯(lián)起來。 ? 還應考慮對測試的影響，即如何充分地驗證這些修改。 影響 分析 修改原因 修改描述 80 增強、移植設計 修改描述： ? 使用合適的 標注方式 描述修改，修改前后對比要明顯； 修改 描述 影響分析 修改原因 新增的代碼：用紅色表示 修改的代碼：用藍色表示 刪除的代碼：用刪除線表示 continue 增強、移植設計 修改描述 :(續(xù) ) ? 對原代碼的修改一定要將修改的具體位置體現(xiàn)出來 —— 將合適的代碼 加在 合適的位置 ； ? 新增函數(shù)應采用偽碼描述，與原有函數(shù)的調用關系應該用函數(shù)調用關系圖的方式表示出來，便于理解； ? 對于修改函數(shù)，若改動量很小或很分散，可以直接用代碼描述；對于大段集中的修改，建議還是采用偽碼描述。 修改 描述 影響分析 修改原因 練習 struct crypto_xf transforms[] 1）修改原因 crypto_xf transforms[]結構增加 AES； 2）影響分析 無 3）修改描述 struct crypto_xf transforms[] = { …… { AES_CBC, AES(CBCMode), 16, 32, 2 * BLOCKSIZE, NULL, IKE_AesInit, IKE_AesEncrypt, IKE_AesDecrypt } …… } 修改原因還是在描述如何修改，為什么修改卻沒有闡述。 影響分析“無”，是無影響，還是沒有分析？ 修改描述中沒有體現(xiàn)出修改在原代碼中的具體位置。 練習 2 數(shù)據結構修改： ETHARP_ARPRTENTRY_S 1）修改原因 需要在 ARP表項節(jié)點紀錄授權表項標志位。 2）影響分析 修改原有數(shù)據結構，對其他模塊無影響。 3）修改描述 typedef struct tagARPRTENTRY { 。 if ( VRP_MODULE_LINK_ARP_AUTHORIZED == VRP_YES ) ULONG ulArpAuthTag。 /* 授權表項標志位 * 0x1 授權 ARP。 * 0x0 其他 。 */ endif }ETHARP_ARPRTENTRY_S。 修改原因還是在描述如何修改，沒有介紹增加該標志是為了什么。 影響分析“對其他模塊無影響”，結構體變大，有沒有評估對系統(tǒng)內存資源的消耗？ 增強、移植設計范例 85 思考 對于開發(fā)項目，在詳細設計階段，我們提倡在 C文件中寫偽碼，這樣較之在 word文檔中寫偽碼的好處有： 。偽碼在形式上很接近于代碼，而大家更習慣在 source insight中閱讀代碼； ，原因同上； 。 對于增強、移植項目，目前大家都是在 word文檔中寫設計，是因為 word文檔中可以使用特殊的標注，這樣能將修改前后的對比體現(xiàn)出來。 移植設計能否也在 C文件中寫呢？ 請大家思考這個問題，如果有好的想法，可以提出來討論。 內容回顧 ?為什么要文檔化 ?文檔寫作基本要求 ?需求設計文檔模板 ?需求文檔寫作 ?設計文檔寫作 答疑 Any question ? 謝 謝 ! 謝謝觀看 /歡迎下載 BY FAITH I MEAN A VISION OF GOOD ONE CHERISHES AND THE ENTHUSIASM THAT PUSHES ONE TO SEEK ITS FULFILLMENT REGARDLESS OF OBSTACLES. BY FAITH I BY FAITH