1 / 39

G 、結構化分析與設計： 流程塑模 ( 上 )

G 、結構化分析與設計： 流程塑模 ( 上 ). 結構化分析與設計之流程塑模工具 事件與事件列、資料流程圖、資料字典、結構圖與HIPO圖、處理規格描述 資料流程圖之建構 建構策略、修正之由中間往外策略步驟、 評估 資料流程圖轉結構圖與模組設計. 結構化分析與設計 的 流程塑模 工具. 包括： 事件 (Event) 及事件列 (Event List) 資料流程圖 (Data Flow Diagram, DFD) 環境圖 (Context Diagram) 資料字典 (Data Dictionary, DD)

vivi
Download Presentation

G 、結構化分析與設計： 流程塑模 ( 上 )

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. G、結構化分析與設計： 流程塑模(上) • 結構化分析與設計之流程塑模工具 • 事件與事件列、資料流程圖、資料字典、結構圖與HIPO圖、處理規格描述 • 資料流程圖之建構 • 建構策略、修正之由中間往外策略步驟、 • 評估 • 資料流程圖轉結構圖與模組設計

  2. 結構化分析與設計的流程塑模工具 • 包括： • 事件(Event)及事件列(Event List) • 資料流程圖(Data Flow Diagram, DFD) • 環境圖(Context Diagram) • 資料字典(Data Dictionary, DD) • 結構圖(Structure Chart)與HIPO圖(Hierarchical Input Process Output) • 處理規格描述(Process Specification, PS)

  3. 1.1 事件及事件列 • 事件 • 由外部實體啟動且系統需回應之「刺激」 (stimuli) ，例如客戶下訂單的事件是由外部實體(客戶)引發，而系統需處理之。 • 資料流導向事件：系統藉由接收到資料之輸入而知道事件之發生。 • 時間導向事件：預設之時間到時，該事件被啟動，例如發票需在每日下午三點產生。 • 控制導向事件：可視為時間導向事件之特例，是由非預設時間之某些刺激或狀態而引發，例如系統之開或關。

  4. 事件及事件列 (Cont.) • 事件列 • 一些事件之集合，用來表示系統與外部實體之關係 • 應描述所涉及之實體、活動之程序與步驟、所需之資訊，並以條列式文句描述之，例如客戶下訂單(業務部)之描述： • 客戶以電話、傳真、郵寄或親自向業務部下訂單 • 業務部處理訂貨資料。 • 訂單主要內容為：客戶名稱、訂購日期、訂購產品之品名、規格、數量、交貨地點與日期。

  5. 1.2 資料流程圖 • 提供一種簡易、圖形化的方式以表達系統之作業處理與資料流間的關係。 • 資料流程圖有四個基本元素： • 外部實體(Entity)：輸入資料的來源與輸出資料的去處 • 資料流(Data Flows)：資料或表報的流動方向 • 處理(Process)or轉換(Transform)：輸入資料轉變為輸出資訊的作業單元 • 資料貯存(Data Stores)：貯存資料檔或表單處

  6. 資料流程圖之表示符號 表達方式 DeMarco & Yourdon Gane & Sarson 元素 外部實體 資料流 處理 資料貯存

  7. 資料流程圖之圖例 系統 開發 1.0 資訊系統需求表 新系統 分解 資訊系統 需求表 分析 報告表 設計 規範書 系統 分析 1.1 系統 設計 1.2 系統 建置 1.3 新系統

  8. 1.2.1 資料流程圖之區分 • 資料流程圖可分為： • 高層次圖(High-level diagram)：初步分析時繪製 • 環境背景圖(Context diagram) • 主要功能圖或零階層圖(Level-0 diagram) • 低層次圖(Low-level diagram)：細步分析時繪製 • 分解(Decomposing)的資料流程圖：當某一功能單元的處理程序甚為複雜時，進行分解

  9. <A> 環境背景圖 • 表達系統之巨觀範圍 • 系統所在環境及其與環境間之關係 • 完成外部實體與事件之整理工作後，接著便可將外部實體與系統之互動製成環境圖，例如資訊之輸出、輸入與處理等，其重要內容為： • 與系統互動之外部實體 • 系統從環境中所接受的資訊或刺激 • 系統所產生及輸出給環境之資訊 • 系統與環境之界限等，以幫助我們了解 系統所存在之環境及兩者互動之關係

  10. 環境圖之表示符號 元素 表示符號 系統 外部實體 處理與資料流

  11. 環境圖舉例 期中考成績清單 教師 期末考成績清單 學生成績 系統 平時成績清單 成績單 成績總表 導師 學生

  12. <B> 主要功能圖 • 由環境背景圖進行延伸、擴展 • 處理圖形(即圓圈)由一個變為數個， 每個圓圈代表一個功能 • 繪製方法： (1)劃分系統的主要功能單元 (2)確定每一功能單元與外界實體間的輸出入關係 (3)確定每一功能單元所需使用的資料貯存所 (4)按作業順序，由左而右，由上而下依序 繪製各種圖號

  13. 學生成績檔 各科成績檔 主要功能圖舉例 期中考成績清單 期末考成績清單 教師 1.0 成績彙總 各科成績資料 平時成績清單 舊的成績記錄 2.0 成績計算 各科成績資料 新的成績 記錄 成績記錄 3.0 成績列印 學生 導師 成績單 成績總表

  14. <C>資料流程圖之分解 • 當某一功能單元的處理程序甚為複雜時，進行分解 • 繪製方法： (1) 將原功能分解成一個以上的次功能，並分別編訂細目代號 (2) 分解後之低層次圖可增加資料貯存、內部資料流，但是不得改變原功能單元之資料流

  15. 1.2.2 資料流程圖繪製原則 (1) DFD一般原則 • 命名：處理以動詞片語命名，外部實體、資料流與資料貯存以名詞片語命名。每一物件的命名均為唯一。 • 處理之輸入與輸出並不同：典型的處理是把輸入轉換成輸出，而非僅傳送資料。 • 完整性(Completeness)：系統所需之元素應全部包含在資料流程圖中。

  16. 資料流程圖繪製原則 (1) DFD一般原則(Cont.) • 一致性(Consistency)：DFD中，某一層之資訊範圍亦需包括在其他層中。 • 時間(Timing)：DFD無法表達時間。 • 反覆繪製(Iterative Development)：才能較為完美的表達。 • 各個處理需分解到最底層DFD：稱為基本的(Primitive) 資料流程圖，判斷方式見下頁。

  17. 資料流程圖繪製原則 • 下列情況可輔助判斷資料流程圖是否已被分解到最底層： a. 當每個處理已被分解到單一決策、單一計算或對單一資料庫操作時，例如檢索(Retrieve)、修改、新增、刪除或讀寫等。 b. 當每個資料貯存表達單一實體(Entity)之資料，例如客戶、員工、產品或訂單。 c. 當系統使用者不必看到更細部或當分析者已記載到足夠詳細可做後續的系統發展工作。 d. 當每一商業表單(Business Form)或交易，電腦之即時展示與報告被視為單一資料流。

  18. 資料流程圖繪製原則 (2) DFD在處理之原則 • 任何處理不可僅有輸出而無輸入 • 任何處理不可僅有輸入而無輸出 不正確 正確 不正確 正確

  19. 資料流程圖繪製原則 (3) DFD在資料貯存與外部實體之原則 • 資料不可直接由一資料貯存移到另一資料貯存，必需由處理移動。 • 資料不可直接由外部實體移至一資料貯存，必需透過處理再至資料貯存。

  20. 資料流程圖繪製原則 (4) DFD在資料流之原則 • 資料流僅以單方向之箭頭符號表示。 • 資料可能在處理與資料貯存間流動，例如先讀取再更新資料，此兩者應以分開之兩箭頭表示，因為兩個事件發生之時間不同且資料亦不同。

  21. A A B A A A B A 資料流程圖繪製原則 • DFD在資料流之原則 (Cont.) • 資料流之分叉表示完全相同之資料從同一地點流出，並流入不同的地方。 • 資料流之匯合表示完全相同之資料從不同的地方流出，並流入相同的地方。

  22. 資料流程圖繪製原則 • DFD在資料流之原則 (Cont.) • 資料流不可由一處理流出再直接流入該處理。 • 一資料流至一資料貯存意謂著資料之更新，例如資料之刪除或修改；資料 從資料貯存流出意謂著讀取或使用。 A B A A C

  23. 資料流程圖繪製原則 • DFD在資料流之原則 (Cont.) • 兩個或兩個以上之資料流可出現在單一箭頭上，只要這些資料流結合成一包裝(Package)並一起移動。 • 一合成資料流在某一層級可被拆成其下一層之一或多個子資料流，但不可加新資料，且上層資料流須相等於其下層之子資料流中之所有資料之集合。 • 處理之輸入必需足以經由處理產生必要的輸出。 • 在資料流程圖最底層，可能加入一些新的資料流，以表示某些特殊情況之資料傳遞。 • 這些資料流表示典型的錯誤訊息或確認告示(Notices) • 為避免資料流交叉，資料流程圖中之資料貯存或外部實體可重複。

  24. 1.3 資料字典 • 提供文字式資訊以輔助DFD之資訊顯示 • 是系統所有資料元素定義之集合 • 常用的表達符號如下：

  25. 資料字典 (Cont.) • 資料字典可以由上而下的方式表示一種複雜的資料元素 • 例如資料元素的組合、架構及意義 • 實例： • 客戶訂單=客戶名稱+帳單號碼+[送貨地址|自行取貨]+(售貨員)+{訂單項目} • 訂單項目=產品編號+(產品名稱)+數量+單價+ (折扣)

  26. 1.4 結構圖與HIPO圖 • 目的：表達系統的模組結構(Structure)以及系統架構(Architecture)，而非針對程序邏輯(Procedural Logic)。 • 結構圖：以圖形顯示一資訊系統之模組如何以層級方式組成，及如何以資料傳遞來表示模組間之互動關係 • HIPO圖：類似結構圖，但不需表示模組間的互動關係(無資料流)

  27. 結構圖之元素及其意義 • 模組 • 每個模組以矩形表示，矩形內有描述其功能之名稱，該名稱應能精確反映該模組能做什麼。 • 模組是執行某特定工作的一連串敘述，類似DFD的「處理」。例如任何程式語言完成的程式。 模組名稱

  28. 結構圖之元素及其意義(Cont.) • 聯繫 • 連接兩個模組的符號，由監督模組(呼叫模組)到附屬模組(被呼叫模組) • 模組之間以箭頭連結，而模組之呼叫順序是由左至右、由上而下。 • 附屬模組停止時，則無條件回到監督模組。 聯繫名稱

  29. 結構圖之元素及其意義(Cont.) • 資料耦合與旗標 • 模組間靠參數傳遞進行溝通，參數型式： • 資料耦合(Data Couples)：顯示資料在兩個模組間傳遞，其符號用空心之小圓圈連接向外之箭頭表示。 • 旗標(Flags 或 Control Flags)︰顯示在兩模組間傳遞之控制資料或訊息，其符號用實心之小圓圈連接向外之箭頭表示。 資料耦合名稱 旗標名稱

  30. 結構圖之元素舉例 • 例如有兩個模組，一為讀取資料A與B，另一模組將兩者製作成資料C。前者為協調模組，而後者為被呼叫的模組。 註︰控制旗標是傳遞訊息給上層呼叫模組，通知其執行某特定的程序，例如送出End of File通知關閉檔案，或value out of range訊息，通知上層模組呼叫例外處理程序。 取C C計算 錯誤 A B C 製C

  31. 系統模組 C C VB VA VA VB 取有效A 取有效B 產生C資料 列印C資料 A B A VB B VA 讀取 讀取 驗證資料 A資料 B資料 結構圖範例 註: VA表示validate A 結構圖的根部(Root)為一協調模組，其下一層是協調模組所呼叫的模組。 以系統為例，根部可想成是主選單，而每個附屬模組是主選單之選項。

  32. 系統模組 取得有效的 取得有效的 C C 產生 資料 列印 資料 A B 資料 資料 讀取 讀取 驗證資料 A B 資料 資料 HIPO圖範例

  33. 1.5 處理規格描述 • 在DFD最底層之每個基本處理單元精確的描述其規則 • 許多不同的方法可被用於描述處理規格，如： • 流程圖、法則 • 結構化英文(Structured English) • 程式設計語言(Program Design Language, PDL)等。 • 其中以結構化英文與PDL較常被用於處理規格描述。

  34. 1.5.1 結構化英文 • 使用有限字彙與語法的規格語言 • 有限的、必要的動詞與名詞的集合︰如 Read, Write, Add, Compute 與 Validate 等動詞與名詞的集合，名詞常在資料字典中定義。 • 控制方法︰藉由結構化程式語言(例如 IF-THEN-ELSE 與 DO-WHILE)來描述其他可能行動(Alternative Actions)與重複的行動。

  35. 結構化英文實例︰催繳款項處理 1. IF the dollar amount of the invoice times the number of weeks overdue is greater than $20,000 THEN: (1) Tell the salesperson to call the customer. (2) Examine the invoice again in 3 weeks. 2. OTHERWISE IF more than three overdue notices have been sent THEN: (1) Tell the salesperson to call the customer. (2) Examine the invoice again in 4 days. 3. OTHERWISE: (1) Send the customer a photocopy of the invoice. (2) Examine the invoice again in 1 week.

  36. 1.5.2 程式設計語言(PDL) • 以日常生活的語言來描述程式設計的概念，撰寫準則︰ • 使用口語化描述 • 避免使用特定程式語言的寫法來表達 • 描述程式要做些什麼 • 反覆設計與描述

  37. PDL範例 {*** 計算送貨明細加總金額 ***} Begin 移動送貨單的送貨明細資料到第一筆記錄 將送貨單的送貨明細加總金額初值設為0 當送貨單的送貨明細資料還沒超過最後一筆時，重複以下 動作 Begin 送貨單的送貨明細加總金額＝送貨明細(數量*售價)＋原 送貨單的送貨明細加總金額 移動送貨單的送貨明細資料到下一筆記錄 End; End;

  38. {*** *** PDL } 計算送貨明細加總金額 ＋程式碼 Procedure ComputeSummary; { } 計算送貨明細加總金額 Begin 移動送貨單的送貨明細資料到第一筆記錄 DataMdlDeli.TblDel iProdSearch.First; 將送貨單的送貨明細加總金額初值設為0 DataMdlDeli.TblDeliver.FieldByName('Summary').AsFloat =0; ： 當送貨單的送貨明細資料還沒超過最後一筆時重複以下動作 While Not DataMdlDeli.TblDeliProdSearch.Eof Do Begin 送貨單的送貨明細加總金額＝送貨明細 （ 數量 ×售價 ） ＋原送貨單的送貨明細 加總金額 DataMdlDeli.TblDeliver.FieldByName('Summa ry').AsFloat = ： DataMdlDeli.TblDeliver.FieldByName('Summary').AsFloat ＋ Round_(DataMdlDeli.TblDeliProdSearch.FieldByName('Price').AsFloat × DataMdlDeli.TblDeliProdSearchNum.Value); 移動送貨單的送貨明細資料到下一筆記錄 DataMdlDeli.TblDeliProdSearch.Next; End; End; PDL描述與程式範例 • 好的PDL應在程式完成後，成為註解

  39. 參考資料 • 吳仁和、林信惠， 「系統分析與設計：理論與實務應用」三版，智勝文化事業 有限公司，台北市，2004年1月。 • 第五章：結構化分析與設計： 流程塑模

More Related