Chapter 4 結構化技術 - Ian-Liu-1990/Systems-Analysis-Design GitHub Wiki

1. 結構化技術範疇

1. 結構化分析(Structured Analysis，SA)

• 定義 : 資訊系統將資料及流程控制獨立分開表示，強調由上而下發展反覆將問題分割成更小更容易管理的基本單位(模組)。 詳-維基百科

• 結構化分析工具-國營資訊100:

1. 資料流程圖(Data Flow Diagram)
2. 資料字典(Data Dictionary)
3. 決策表(Decision Table)
4. 資料結構圖(Data Structured Diagram)或HIPO
5. 決策樹(Decision Tree)
6. 系統關係圖（System Context Diagram）

---

2. 結構化設計(Structured Design，SD)

• 定義 : 有關軟體模組的開發，及分析模組之間的「模組層次」和「模組互動」

• 在結構化設計中，２個主要的設計準則：

  1. 內聚力
  2. 耦合力

• 結構化設計-設計經驗

  • 模組 : 一連串指令的集合，包含5個部分(模組名稱，輸出/入，內部資料，資料處理邏輯)組成，在結構化設計中的最小單位
  • 設計經驗:
    1. 模組大小: 不希望模組功能過於龐雜，不易維護，不易複用，不易閱讀
    2. 控制間距: 不希望模組同時被太多即時模組控制，不易掌控和維護
    3. 影響範圍與控制範圍: 縮小這兩種範圍，減少非預期的程式問題發生

---

3. 結構化程式設計

• 定義 : 強調任何邏輯均可由循序(Sequence)，條件(Condition)和重複(Repetition)結構三種邏輯結構組成，取代和消除以往程式中GOTO指令，多點輸出和輸入的混亂狀況

---

4. 由上而下的發展

• 定義 : 強調把大問題依序分解成具層級結構小模組，並由上層模組開始進行(1)設計，(2)編碼與(3)實施和測試

• 包含 : 由上而下設計，由上而下編碼與由上而下實施

1-1. 由上而下設計

• 定義 : 大而複雜的問題分解成小且較簡化的問題，直到原來的問題可用容易理解的小問題組合來表示，系統很大時有助於縮短時間

• 特色 :

  1. 層級化的設計 : 先考慮程式的主要功能，再依次考慮內部細節。
  2. 延緩考慮細節問題 : 先考慮高層次之功能。
  3. 與程式語言無關 : 可選用任何一種語言來撰寫，而不需更改設計內容。
  4. 便於驗證 : 根據各主要功能來檢查各次功能。

1-2. 由下而上設計

• 定義 : 先考慮程式中低底層的項目，最後將低層部分組合高層次部分，適用在已有現存系統或子系統的關鍵技術必須先克服，以降低風險的設計

• 缺點 :

  1. 難以規劃一完整程式
  2. 不易將程式化分部分區塊
  3. 不易明確訂出區塊部分間的相互影響和資料關係

---

2. 由上而下或由下而上編碼

---

3-1. 軟體測試[何為軟體測試? ]

• 測試條件 : 必須在"規定的"條件下操作程序

• 測試目的 : 衡量軟體品質，正確性和完整性，找出錯誤，並符合使用者需求

• 軟體測試種類和階段 :

測試類型	測試階段	測試模式	測試內容	測試人員	測試例子
單元	開發初期	白箱	模組為單元，測試邏輯程序(迴圈次數，判斷式條件是否正確，輸入參數是否符合規範和輸出結果是否正確)．且獨立進行，不受前後工作致使結果受影響而不一致	程式設計師	測試腳本
整合	模組結合為子系統	白箱	單元測試邏輯延伸，為測試多個模組元件間的介面在相互溝通和傳遞資料是否正確	程式設計師	測試腳本
驗收	軟體部署於硬體前	黑箱	確保軟體準備就緒，展示軟體可依使用者需求執行	專門測試人員	Alpha測試
系統	系統完成時	黑箱	軟硬結合，人員，數據和環境等與系統有關之元素結合一起測試	特定人士	Beta測試

• 白箱測試 :

  • 測試人員 : 程式設計師
  • 測試目的 : 以深度為主，測試人員必須瞭解測試對象內部細節(結構，演算法等訊息)，檢查特定條件，迴圈，邏輯路徑和發現漏洞
  • 測試實現 : 單元與整合可由上往下或由下往上，確認程式邏輯路徑

• 黑箱測試 :

  • 測試人員 : 專門測試人員
  • 測試目的 : 以廣度為主，測試人員不必理解測試對象運作細節，只需在正確的輸出入下檢視，系統的互動與狀態反映是否有符合需求或缺少功能
  • 測試實現 : 驗收針對使用者使用的功能完善度，系統則是找出正常，極端和例外狀況下，問題發生條件和底線

---

• 參考 - Alpha和Beta測試 :
  • Alpha測試:
    • 何時: 階段性的開發完成後所開始進行，是一種驗證測試，
    • 誰測: 通常是開發與測試單位的開發人員與測試人員，
    • 怎麼測: 以類比或實際操作性的方式進行驗證測試。
    • 結果: 驗證資訊系統符合使用者以及設計需求所期望的功能。
  • Beta測試:
    • 何時: Alpha測試完之後
    • 誰測: 由公眾參與的測試的階段
    • 怎麼測: 在一個真實的環境中以實際的資料來執行測試，以確認效能，系統執行有效率，系統復原與備份作業正常
    • 結果: 透過測試讓資訊系統日後可以更趨完善。

---

3-2. 由上而下實施(Top-Down Implementation)或由上而下整合測試(Top-Down Integration Test)

• 由上而下測試 : 低階模組尚未完成前，先測試系統的高階模組，而以殘根模組(Stub Module)或虛擬模組(Dummy Module)暫時替代其下一層為完成的模組

換句話說，在由上而下測試中，殘根模組(Stub Module)或虛擬模組(Dummy Module)作為暫時替代的模組當作低階模組幫助高階模組測試．

• 由下而上測試 : 由程式結構圖的最低端模組開始，逐次往上測試，必須製造啟動模組

	由上而下-優點	缺點	由下而上-優點	缺點
發先錯誤	錯誤在上方及早發現	-	錯誤在下方及早發現	-
測試準備	-	需要製造殘根和虛擬模組(設計複雜，輸出入設計困難)	-	必須製造啟動模組
結果觀察	-	測試個案不易產生或不準確，結果難觀察，準確度不高	測試個案設計容易，易準確觀察測試結果	-
設計與測試重疊	-	設計與測試產生重疊的誤解，潛意識對模組測試產生可延期的想法	不會產生設計與測試重疊的誤解	-
測試範疇	-	低階模組平行測試受限上層模組的完成度	-	整體系統要到最後模組完成才可以看見全貌
測試次數	最高階模組介面被測試次數最多	-	最低階模組受測試較徹底	-

---

結構化分析與設計結論-分治(Divide and Conquer)

• 分析對象: 針對資訊系統有使用者介面，問題處理，知識子系統三個主要元件作結構化的分析與設計
• 實現辦法: 因為結構化強調資料與流程分開處理，所以分成

1. 資料塑模: 針對知識子系統，若後端系統使用關聯資料庫，使用系統需求分析階段完成的[藍圖+描述詞彙]內容，以實體關聯圖[ERD]進行資料塑模，表示資料與資料間的關係，再依規則轉換成關聯表，並進行正規化檢查與精簡，進一步創建資料庫系統．

2. 流程塑模: 針對系統問題處理，使用系統需求分析階段完成的[環境圖+流程圖+事件描述]內容，以資料流程圖[DFD]進行流程塑模，表示所有外部實體與系統的互動，包括系統內部之處理程序及所需資料的輸出入，再將DFD圖轉成結構圖或HIPO圖，以層級結構再進行模組設計，最後再進行結構化程式設計

3. 使用者介面塑模: 針對使用者介面，使用[介面(結構圖+藍圖+元件規格)，狀態圖與轉換表]進行介面表達，完成後進行進階之使用者介面設計