詳細設計
㈠ 詳細設計的簡介
詳細設計的工具 詳細設計的基本任務 詳細設計說明書
㈡ 軟體詳細設計包含哪些內容
傳統軟體開發方法的詳細設計主要是用結構化程序設計法。
詳細設計的表示工具有圖形工具和語言工具。圖形工具有業務流圖、程序流程圖、PAD圖（Problem Analysis Diagram）、NS流程圖（由 Nassi和 Shneidermen開發，簡稱 NS）。
語言工具有偽碼和PDL（Program Design Language）等。
㈢ 軟體詳細設計的工具什麼簡述幾種常見的詳細設計工具
（1）程序流程圖。程序流程圖又稱為程序框圖，是使用最廣泛然而也是用得最混亂的一種描述程序邏輯結構的工具。它用方框表示一個處理步驟，菱形表示一個邏輯條件，箭頭表示控制流向。其優點是：結構清晰，易於理解，易於修改。缺點是：只能描述執行過程而不能描述有關的數據。
（2）盒圖。盒圖是一種強制使用結構化構造的圖示工具，也稱為方框圖。其具有以下特點：功能域明確、不可能任意轉移控制、很容易確定局部和全局數據的作用域、很容易表示嵌套關系及模板的層次關系。
（3）PAD圖。PAD是一種改進的圖形描述方式，可以用來取代程序流程圖，比程序流程圖更直觀，結構更清晰。最大的優點是能夠反映和描述自頂向下的歷史和過程。PAD提供了5種基本控制結構的圖示，並允許遞歸使用。
PAD的特點有：使用PAD符號設計出的程序代碼是結構化程序代碼；PAD所描繪的程序結構十分清晰；用PAD圖表現程序的邏輯易讀、易懂和易記；容易將PAD圖轉換成高級語言源程序自動完成；即可以表示邏輯，也可用來描繪數據結構；支持自頂向下方法的使用。
（4）PDL。PDL也可稱為偽碼或結構化語言，它用於描述模塊內部的具體演算法，以便開發人員之間比較精確地進行交流。語法是開放式的，其外層語法是確定的，而內層語法則不確定。外層語法描述控制結構，它用類似於一般編程語言控制結構的關鍵字表示，所以是確定的。內層語法描述具體操作，考慮到不同軟體系統的實際操作種類繁多，內層語法因而不確定，它可以按系統的具體情況和不同的設計層次靈活選用，實際上任意英語語句都可用來描述所需的具體操作。用它來描述詳細設計，工作量比畫圖小，又比較容易轉換為真正的代碼。
PDL的優點：可以作為注釋直接插在源程序中；可以使用普通的文本編輯工具或文字處理工具產生和管理；已經有自動處理程序存在，而且可以自動由PDL生成程序代碼。
PDL的不足：不如圖形工具形象直觀，描述復雜的條件組合與動作間對應關系時，不如判定樹清晰簡單。
㈣ 詳細設計的主要任務是什麼
詳細設計的主要任務是設計每個模塊的實現演算法、所需的局部數據結構。
基本任務：
(1)為每個模塊進行詳細的演算法設計。用某種圖形、表格、語言等工具將每個模塊處理過程的詳細演算法描述出來。
(2)為模塊內的數據結構進行設計。對於需求分析、概要設計確定的概念性的數據類型進行確切的定義。
(3)為數據結構進行物理設計，即確定資料庫的物理結構。物理結構主要指資料庫的存儲記錄格式、存儲記錄安排和存儲方法，這些都依賴於具體所使用的資料庫系統。
(4)其他設計：根據軟體系統的類型，還可能要進行以下設計：
①代碼設計。為了提高數據的輸入、分類、存儲、檢索等操作，節約內存空間，對資料庫中的某些數據項的值要進行代碼設計。
②輸入/輸出格式設計。
③人機對話設計。對於一個實時系統，用戶與計算機頻繁對話，因此要進行對話方式、內容、格式的具體設計。
(5)編寫詳細設計說明書。
(6)評審。對處理過程的演算法和資料庫的物理結構都要評審。
(4)詳細設計擴展閱讀：
相關延伸：詳細設計的主要任務的設計工具：
1、圖形工具
利用圖形工具可以把過程的細節用圖形描述出來。
2、表格工具
可以用一張表來描述過程的細節，在這張表中列出了各種可能的操作和相應的條件。
3、語言工具
用某種高級語言（稱之為偽碼）來描述過程的細節。概要設計和詳細設計的區別與聯系。
㈤ 概要設計與詳細設計的區別
概要設計與詳細設計的區別如下：
1、概要設計的主要任務是把需求分析得到的系統擴展用例圖轉換為軟體結構和數據結構。設計軟體結構的具體任務是：將一個復雜系統按功能進行模塊劃分、建立模塊的層次結構及調用關系、確定模塊間的介面及人機界面等。數據結構設計包括數據特徵的描述、確定數據的結構特性、以及資料庫的設計。顯然，概要設計建立的是目標系統的邏輯模型.
2、詳細設計是軟體工程中軟體開發的一個步驟，就是對概要設計的一個細化，就是詳細設計每個模塊實現演算法，所需的局部結構。在詳細設計階段，主要是通過需求分析的結果，設計出滿足用戶需求的嵌入式系統產品。
3、概要設計階段通常得到軟體結構圖 ，詳細設計階段常用的描述方式有：流程圖、N-S圖、PAD圖、偽代碼等 。
4、詳細設計階段就是為每個模塊完成的功能進行具體的描述，要把功能描述轉變為精確的、結構化的過程描述。
(5)詳細設計擴展閱讀
設計是把一種設想通過合理的規劃、周密的計劃、通過各種感覺形式傳達出來的過程。人類通過勞動改造世界，創造文明，創造物質財富和精神財富，而最基礎、最主要的創造活動是造物。設計便是造物活動進行預先的計劃，可以把任何造物活動的計劃技術和計劃過程理解為設計。
設計（Design）是為構建有意義的秩序而付出的有意識的直覺上的努力。更詳細的定義如下：
第一步：理解用戶的期望、需要、動機，並理解業務、技術和行業上的需求和限制。
第二步：將這些所知道的東西轉化為對產品的規劃（或者產品本身），使得產品的形式、內容和行為變得有用、能用，令人嚮往，並且在經濟和技術上可行。（這是設計的意義和基本要求所在）
㈥ 工藝包，基礎設計和詳細設計的不同
「基礎設計」不知是什麼基礎。我這里權當是「基本設計」。
1、工藝包。工程項專目中確定的產品在屬其加工的整個過程需要的工藝流程確定、加工設備選擇、原料的選擇與成品存放環境、通用設備配置等等工程參數，以及生產過程的質量控制參數、生產過程工藝執行計劃、生產流程中全部工藝技術的確定是工藝包涉及的內容。
2、基本設計。是按照提供的工藝流程及設備參數初步做出的總圖性設計，包括，總平面圖，總流程圖。
3、詳細設計。是按照總圖和工藝包的參數做出的供工程實施使用的施工設計。包括：建築物、構築物、機械、電氣、給排水、消防、水處理、綠化等施工設計。
上述三點不同的地方一眼便可看出，這里不在累述。
㈦ 如何寫模塊的詳細設計。求解答
詳細設計的主要任務是設計
每個模塊的實現演算法、所需的局部數據結構
。詳細設計的目專標有兩個：實屬現模塊功能的演算法要邏輯上正確和演算法描述要簡明易懂。
主要任務：1．為每個模塊確定採用的演算法，選擇某種適當的工具表達演算法的過程，寫出模塊的詳細過程性描述；2．確定每一模塊使用的數據結構；3．確定模塊介面的細節，包括對系統外部的介面和用戶界面，對系統內部其它模塊的介面，以及模塊輸入數據、輸出數據及局部數據的全部細節。
在詳細設計結束時，應該把上述結果寫入詳細設計說明書，並且通過復審形成正式文檔。交付給下一階段（編碼階段）的工作依據。4．要為每一個模塊設計出一組測試用例，以便在編碼階段對模塊代碼（即程序）進行預定的測試，模塊的測試用例是軟體測試計劃的重要組成部分，通常應包括輸入數據，期望輸出等內容。
詳細設計的工具：1．圖形工具利用圖形工具可以把過程的細節用圖形描述出來。2．表格工具可以用一張表來描述過程的細節，在這張表中列出了各種可能的操作和相應的條件。3．語言工具用某種高級語言（稱之為偽碼）來描述過程的細節。
㈧ 軟體的結構化設計SD方法中，詳細設計主要是要建立什麼
軟體設計一般分為兩個階段：
第一階段：概要設計階段。
第二階段：過程設計（也稱詳細設計）階段。
SD方法是面向數據流的方法，以SA結果為依據。
SD方法主要完成概要設計階段的任務：從DFD圖導出SC圖，確定軟體的體系結構、給出了各模塊的功能和模塊間的介面；
在SD方法結果的基礎上，用SP方法完成詳細設計階段的主要任務，即過程設計（對各個模塊給出詳細的過程性描述）。
㈨ 系統設計的概要設計和詳細設計的區別
概要設計的主要任務是把需求分析得到的系統擴展用例圖轉換為軟體結構和數據結構。設計軟體結構的具體任務是：將一個復雜系統按功能進行模塊劃分、建立模塊的層次結構及調用關系、確定模塊間的介面及人機界面等。數據結構設計包括數據特徵的描述、確定數據的結構特性、以及資料庫的設計。顯然，概要設計建立的是目標系統的邏輯模型.
詳細設計是軟體工程中軟體開發的一個步驟，就是對概要設計的一個細化，就是詳細設計每個模塊實現演算法，所需的局部結構。在詳細設計階段，主要是通過需求分析的結果，設計出滿足用戶需求的嵌入式系統產品。
㈩ 如何寫詳細設計文檔
在大多數軟體項目中，要末不作詳細設計，要麼開發完成後再補詳細設計文檔，質量也不容樂觀，文檔與系統往往不能同步，使詳細設計文檔完全流於形式，對工作沒有起到實際的幫助。
·
詳細設計是相對概要設計而言的，是瀑布開發流程的一個重要環節，在概要設計的高層設計的基礎上，從邏輯上實現了每一模塊的功能，是編碼階段的主要參考資料，是從高層到低層、逐步精化思想的具體實現。
詳細設計文檔的內容包括各個模塊的演算法設計，
介面設計，
數據結構設計，交互設計等。必須寫清楚各個模塊/介面/公共對象的定義，列明各個模塊程序的
各種執行條件與期望的運行效果，還要正確處理各種可能的異常。
·
在開發過程中，由需求及設計不正確、不完整所導致的問題是項目進度拖延、失敗的一個主要因素，而軟體系統的一個重要特性就是需求和設計的不斷構建和改進，在寫詳細設計文檔過程中，
詳細設計實際上是對系統的一次邏輯構建，可以有效驗證需求的完整性及正確性。
如果不寫詳細設計文檔，一般就從概設直接進入編碼階段，這時開發人員所能參考的資料就是需求規格說明書及頁面原型、資料庫設計等，不能直接進行開發，需要進行信息的溝通，把頁面原型不能體現的設計講清楚，這樣既容易遺忘，也容易發生問題，詳細設計文檔可以作為需求人員、總體設計人員與開發人員的溝通工具，把靜態頁面無法體現的設計體現出來，包含整體設計對模塊設計的規范，體現對設計上的一些決策，例如選用的演算法，對一些關鍵問題的設計考慮等等，使開發人員能快速進入開發，提高溝通效率，減少溝通問題。
對於系統功能的調整，後期的維護，詳設文檔提供了模塊設計上的考慮、決策，包括模塊與整體設計的關系、模塊所引用的資料庫設計、重要操作的處理流程、重要的業務規則實現設計等等信息，提供了對模塊設計的概述性信息，闡明了模塊設計上的決策，配合代碼注釋，可以相對輕松讀懂原有設計。
·存在的問題要由專門的人寫，是比較麻煩的，也是很需要時間的，會對進度造成壓力，也容易形成工作瓶頸，使設計人員負擔過重，而開發人員無事可作。對於現在一般的以資料庫為中心的管理系統而言，這個工作始終是要作的，區別只不過是不是形成專門文檔，形成文檔可能會多花一兩周時間，但相對於規避的風險和問題來說，也是值得的，另外由於現在高級語言的流行，所以更詳細的設計應該直接體現在代碼的設計上，而文檔則只體現設計上的一些決策，協調整體設計與模塊設計的關系，把頁面原型所不能體現的設計情況文檔化，所以所花費的時間是有限的。
設計內容容易過細，但設計階段是不能考慮特別清楚地，時間也不允許。
對於這個問題，一個對策是上邊所提到的，文檔只體現設計上的決策，頁面原型所不能反映的信息，詳細設計只體現總體設計對模塊設計的一些考慮，例如對功能的資料庫設計等等，而具體的實現實現，則到代碼中再去實現，相關的設計也僅體現在代碼中。
需求、設計需要不斷的被更新、構建，則設計文檔需要不斷的重新調整，文檔的維護需要跟上，否則文檔和系統的同步就很難得到保障了，且造成多餘的工作量。文檔的內容易流於形勢，質量糟糕，不能成為開發人員的參考手冊，一是要建立起相關制度，如有修改，先改文檔，後作開發，從工作流程上切實保障文檔與系統的同步，二是要規範文檔質量，對文檔該寫什麼，不該寫什麼，標準是什麼，粒度是什麼，語法應該如何組織，有明確的標准和考慮，同時，建立審計文檔評審、審核制度，充分保障系統的使用。·
首先是文檔的內容，根據項目和團隊的不同，詳細設計文檔的內容也有所不同，一般說來，粒度不宜過細，不能代替開發人員的設計和思考，但要把有關設計的決策考慮進去，包括與其他模塊、整體設計的關系、操作的處理流程，對業務規則的設計考慮等，有一個標准為，凡是頁面原型、需求規格說明書所不能反映的設計決策，而開發人員又需要了解的，都要寫入文檔。
其次是文檔所面向的讀者，主要為模塊開發人員、後期維護人員，模塊開發人員通過詳細設計文檔和頁面原型來了解所開發的功能，後期維護人員通過實際系統、模塊代碼、詳細設計文檔來了解一個功能。
再有就是誰來寫文檔，因為文檔主要考慮的是設計上的決策，所以寫文檔的人應該為負責、參加設計的技術經理、資深程序員，根據團隊情況和項目規模、復雜度的不同，也有所不同。
還需要保證文檔的可讀性、准確性、一致性，要建立嚴格的文檔模板及標准，保證文檔的可讀性及准確性，同時建立審核及設計評審制度，來保障設計及文檔的質量，另外在工作流程中要強調，要先設計、先寫文檔，再進行開發。