【正文】 3）問題：捕獲的“過程”和“數(shù)據(jù)” 恰恰是客觀事物的易變性質(zhì)， 解的結構也不保持原系統(tǒng)的結構， 從而：造成 維護，驗證上的困難。 過程 （ 功能 ） 設計針對體系結構中的每一模塊 ， 給出它的過程屬性描述 ， 即算法設計 。 體系結構設計以系統(tǒng)的功能模型為基礎 ， 逐層精化 ， 最終形成系統(tǒng)的模塊 （ 子系統(tǒng) ） 以及它們之間的控制關系 。 著名的有 （ SSA） 。 包括結構化分析和結構化設計 。 PAD圖 S1 S2 S3 S1 S2 X?5 X5 S 順序 : 選擇 : 循環(huán) : 注 :支持逐步求精設計 NS圖 支持逐步求精設計舉例 順序 : 選擇 : 循環(huán) : 條件 F T S1 S2 循環(huán)條件 循環(huán)體 N:=1..10 X5 T F F T S1 S2 S3 S4 S5 S6 S8 S7 S9 S10 X10amp。 2)詳細設計的任務：定義每一模塊 幾種表示工具 流程圖、 PAD、 N－ S圖、偽碼等 框圖 s1 s2 s1 s2 . . . s 偽碼 偽碼是一種混合語言。 選擇 if 條件表達式 then s1 else s2。s2。 啟發(fā)性規(guī)則 經(jīng)驗的總結 （ 1）改進軟件結構，提高模塊獨立性； （ 2）模塊規(guī)模適中 每頁 60行語句； （ 3）深度、寬度、扇入和扇出適中； （ 4）模塊的作用域力爭在控制域之內(nèi)； （ 5）降低模塊接口的復雜性； （ 6）模塊功能應該可以預測。 （ 6）順序內(nèi)聚：各成分與一個功能相關，且一個成分的輸出作為 另一成分的輸入。 （ 4）過程內(nèi)聚：處理成分必須以特定的次序執(zhí)行。 （ 2）邏輯內(nèi)聚：幾個邏輯上相關的功能放在同一模塊中。 2）內(nèi)聚：一個模塊之內(nèi)各成分之間相互依賴程度的度量。 （ 4）標記耦合：兩個模塊至少有一個通過界面?zhèn)鬟f的公共 有結構的參數(shù)。 耦合類型： （ 1）內(nèi)容耦合： 一個模塊直接修改或操作另一個模塊的數(shù)據(jù) （ 2）公共耦合：兩個以上的模塊共同引用一個全局數(shù)據(jù)項。 SRS中陳述的各個需求之間沒有發(fā)生沖突 （ 6）可理解性： 有關 SRS格式與風格方面 （ 7）可修改性： 指的是 SRS的結構和風格使任何對需求的 必要修改都易于完整、一致的進行 （ 8） 可被跟蹤性： 指的是 SRS中的每個需求的出處都是清 楚的，這意味著 SRS中包含對前期支持文檔的引用表 （ 9） 可跟蹤性： 指的是 SRS的書寫方式有助于對其中陳述 的每個需求進行引用 （ 10） 設計無關性： 指的是 SRS不暗示特定的軟件結構和 算法 結構化設計 要回答如何解決問題 －即給出軟件解決方案 1)總體設計的任務：如何將 DFD轉(zhuǎn)化為 MSD 分二步實現(xiàn)： 第一步：如何將 DFD轉(zhuǎn)化為初始的 MSD 第二步：如何將初始的 MSD轉(zhuǎn)化為最終可供詳細設計 第一步：如何將 DFD轉(zhuǎn)化為初始的 MSD ?數(shù)據(jù)流圖分類 變換型 : 事務型 1 2 3 4 5 6 7 8 a b c d e f h g y x z 1 2 3 5 4 6 a b c d e f g y ?變換設計 XX系統(tǒng) 變換模塊 get e put h put g get c get d c,de ef fg,h hy put y gx put x xz put z get a get b bd ac e e g,h h g z z x x g y y h d b c a c d e e f g,h f x a b 事務設計 事務中心 輸入模塊 路徑 1 路徑 2 輸出模塊 a y c g b f ce c e eg e g bd b d df d f 3 4 6 8 2 5 7 9 A2 c b d e f g i h m k n 1 10 A1 x 一個系統(tǒng)的 DFD， 通常是變換型數(shù)據(jù)流圖和事務型數(shù)據(jù)流 圖的組合 。 SRS中沒有被標識為“待定”的內(nèi)容 （ 4）可驗證性： SRS中陳述的每個需求都是可驗證的 即當且僅當存在一個有限代價的過程（人工或機器） 可以檢查構造的軟件產(chǎn)品是否符合用戶的需求 （ 5）一致性： 未來系統(tǒng)所做的任何事情都包含在 SRS的陳述中 （注：存在數(shù)據(jù)庫設計問題） 以同樣方式，對加工 1進行分解，形成： 入庫新書 借書 還 書 注銷圖書 圖書管理要求 處理圖書管理要求 目錄文件 罰款單 當前日期 借書文件 讀者文件 入庫單 借書單 注銷單 還書單 其中：注意平衡問題；平面化問題。 ） 于是，可以根據(jù)這一抽象，可以識別： 1）頂層數(shù)據(jù)流： 借還書等事務處理要求 咨詢事務要求 以及相關的數(shù)據(jù)流 2）數(shù)據(jù)源和數(shù)據(jù)潭為：圖書管理人員，讀者以及時鐘。 進行功能抽象 。 分析數(shù)據(jù)內(nèi)容，確定是否所有的輸入信息都用于 產(chǎn)生輸出信息； 分析加工，確定一個加工所產(chǎn)生的輸出，是否都 能由該加工的輸入信息導出 實例講解 ： 圖書管理系統(tǒng) —問題陳述見 P35。 一幅圖中的圖元個數(shù)應控制在 7+/2以內(nèi) 上層數(shù)據(jù)可以“打包” 上、下數(shù)據(jù)流對應關系在數(shù)據(jù)字典中給出，但包內(nèi) 數(shù)據(jù)流的性質(zhì)（輸入、輸出）必須一致。 “ 葉”加工（最低層）必須給出加工小說明 父圖和子圖必須平衡 查詢商品銷售情況 計算日銷售額 查詢要求 銷售情況 日銷售額 銷售文件 3 繼續(xù) A、 B、 C：自頂向下，逐層分解。 錄入、修改或 刪除商品信息 錄入、修改 現(xiàn)金額 , 并計算余額 查詢商品銷售情況 計算日銷售額 銷售的商品 現(xiàn)金額 現(xiàn)金余額 查詢要求 銷售情況 日銷售額 銷售文件 1 2 3 C、引入文件，使之形成一個有機整體 —系統(tǒng)： 注：到一個文件，既有輸入流，又有輸出流，則可簡化為 ，并可不給出標識。 2）建模過程 (1)建立系統(tǒng)的功能模型 使用的工具為數(shù)據(jù)流圖 DFD 首先：建立系統(tǒng)環(huán)境圖，確定系統(tǒng)邊界 繼之：自頂向下，逐層分解 (2)建立數(shù)據(jù)字典 定義數(shù)據(jù)流 定義數(shù)據(jù)存儲 定義數(shù)據(jù)項 (3)給出加工小說明 使用的工具可以為判定表 判定樹 (1)建立系統(tǒng)的功能模型 使用的工具為數(shù)據(jù)流圖 DFD 數(shù)據(jù)流圖：是一種描述數(shù)據(jù)變換的圖形工具。 Check status Place order Fill order Establish credit Telephone Catalog Salesperson Shipping Clerck Supervisor Customer 例： USE CASE圖 需求規(guī)約 需求規(guī)約的主要目標： 依據(jù)需求陳述（作為輸入），解決其中的歧義、不一致等問題，以系統(tǒng)化的形式表達用戶的需求，即給出問題的形式化或半形式化的描述（建立模型），形成需求規(guī)格說明書。 即圖中給出了一些操作者 、 一組關系 、 一些接口和這些元素之間的關系 。 ? 泛化： USE CASE A到 USE CASE B的泛化 ， 指出 A是 B的特殊情況 。 ? 擴展： USE CASE A到 USE CASE B的一個擴展關系 ，指出了 USE CASE B的一個實例可以由 A說明的行為予以擴展 （ 根據(jù)該擴展所說明的特定條件 ） ， 并依據(jù)該擴展點定義的位置 ， A說明的行為被插入到 B中 。 例如 ， 操作者的實例與 USE CASE實例相互通訊 。 對于每一 USE CASE，一個操作者有一種角色，即每 一 USE CASE與具有一種角色的操作者進行通訊。 為了表明 USE CASE所包含的具體內(nèi)容，還應給出它 的正文描述。 （ 2）表示與描述 USE CASE通常被表示為： USE CASE包含一組操作和屬性，這些操作和屬性規(guī)約了 該 USE CASE的實例所執(zhí)行的那個動作序列。 通過這一約定 ， 描述了該語義實體在不同條件下的行為對參與者一個要求的響應 ， 以實現(xiàn)某一目的 。 （ 1） USE CASE語義 一個 USE CASE是系統(tǒng)或其它語義實體 （ 例如子系統(tǒng)或一個類 ） 所提供的一塊 (unit)高內(nèi)聚的功能 ， 顯露該系統(tǒng)和一個或多個外部的交互者 （ 稱為操作者 ） 交替出現(xiàn)的消息序列 ，以及該系統(tǒng)所執(zhí)行的動作 。例如： “做一次拼寫檢查” “對一個文檔建立索引” 對一個用況而言，關鍵要素是：表示一種用戶可以理解并對該用戶有價值的功能。為此使用了一種用戶和開發(fā)人員都能理解方式描述系統(tǒng)功能和行為 ? Use Case可以劃分系統(tǒng)與外部實體的界限，是系統(tǒng)開發(fā)的起點，而最終應該落實到類和實現(xiàn)代碼上 ? Use Case既然是對系統(tǒng)行為的動態(tài)描述，因此它是類、對象、操作的來源，是系統(tǒng)分析和設計階段的輸入之一，是分析和設計，制定開發(fā)計劃，測試計劃，設計測試用例的依據(jù)之一 ? Use Case Model是系統(tǒng)需求分析階段的成果之一 ? Use Case不但有助于幫助分析員理清思路；驗證用戶需求。 2） 劃分：分離問題。需求的目標是要簡潔而精確地說明所要解決的問題 需求工程的原則 1） 抽象：抓住事物的本質(zhì)（要素）。 6. 確定進入下一階段的方法步驟。 4. 開發(fā)并測試當前階段。 2. 識別并化解風險。如此不斷輪回重復，直到得到您滿意的最終產(chǎn)品。 “螺旋模型”的核心就在于您不需要在剛開始的時候就把所有事情都定義的清清楚楚。建設周期長，而軟件技術發(fā)展比較快，所以經(jīng)常出現(xiàn)軟件開發(fā)完畢后，和當前的技術水平有了較大的差距，無法滿足當前用戶需求。 5）客戶認可這種公司內(nèi)部的開發(fā)方式帶來的良好的溝通和高質(zhì)量的產(chǎn)品。 3）客戶始終參與每個階段的開發(fā) ,保證了項目不偏離正確方向以及項目的可控性。 優(yōu)點 1）設計上的靈活性 ,可以在項目的各個階段進行變更。 ? 針對事先不能完整地定義需求 ? 針對用戶的核心需求 ,開發(fā)核心系統(tǒng) ? 根據(jù)用戶的反饋 ,實施活動的迭代 1 3 2 5 9 10 11 6 7 12 13 8 4 增量 1 ? 1,2,5,9 ? 增量 2 ? 3,6,7,4,10,11 ? 增量 3 ? 8,12,1