iT邦幫忙

2021 iThome 鐵人賽

DAY 3
2
Software Development

淺談中台架構、DDD與Python實踐系列 第 4

【Day 04】阿公級的系統分析方法 -- DFD

前言

上一篇談到領域驅動設計並不是橫空出世,而是經由過去幾十年的逐步演化而成的,因此,我們就來看看阿公級的系統分析方法 -- 『結構化分析與設計』(俗稱DFD),現在很少人在討論了,但是它其實是一個最直覺的系統分析方法,系統開發人員可以藉由這個方法輕易的掌握使用者的需求。

初步接觸

記得讀研究所時,直屬學長就極力推薦一本書『Structured Analysis and System Specification』,當時很訝異,我讀的是工業工程研究所,不是資工啊,不過為了尊重學長,還是買了這本書,就讓它躺在書架上,直到初入社會,沒想到Mentor也指定一個月要看完這本書,且要週週報告,這才努力地看完,也才領略到系統分析之美,為了寫這篇文章,特地查看市面上是否還銷售這本書,沒想到竟暴漲到4234元,跟收集古董一樣,當初只花了200元,賺翻了。
https://ithelp.ithome.com.tw/upload/images/20210919/200019765tqejxO3mC.png
圖一. 博客來-Structured Analysis and System Specification,圖片來源:https://www.books.com.tw/products/F012874494

之後,Edward Yourdon 又出了一系列的相關書籍,其中『Modern Structured Analysis』的附錄有一完整的個案研究,非常珍貴,它以自身出版社系統為例,撰寫出完整的規格書。這本書便宜一點,現在只賣US$22.5,記得很多年以前,天瓏書局清庫存時,只賣NT$50,當時有一股衝動,想要全部買下來,只可惜沒有付諸行動。
https://ithelp.ithome.com.tw/upload/images/20210921/20001976eyDoHUDsDB.png
圖二. Modern Structured Analysis,圖片來源:https://www.marlowesbooks.com/Modern-Structured-Analysis-Yourdon-Edward-Book-122490

核心流程

講了這麼多廢話,結構化分析(Structured Analysis)究竟有甚麼特點呢?

  1. 它以資料流程圖(Data Flow Diagram, DFD)為核心,先繪製系統的功能(Function),再描述功能之間的資料流,如果需要落地,就繪製『資料儲存』(Data Store),就這麼簡單。
    範例一. 訂單處理
    https://ithelp.ithome.com.tw/upload/images/20210921/200019769VrMWAbplD.png
    圖三. Modern Structured Analysis,圖片來源:https://www.conceptdraw.com/examples/data-flow-diagram-of-library-system

範例二. 生鮮蔬菜購物系統
https://ithelp.ithome.com.tw/upload/images/20210921/20001976698uGbdtrX.png
圖四. 生鮮蔬菜購物系統 Level 0 DFD,圖片來源:https://sites.google.com/site/gdghujy/gtgrgtr/di1jiedfd

其中包含的符號很簡單:
https://ithelp.ithome.com.tw/upload/images/20210921/200019768pEg4Gd4xr.png
圖五. DFD 元素

『資料儲存』(Data Store)有另一派畫法,Gane Sarson 以下列符號表示:
https://ithelp.ithome.com.tw/upload/images/20210922/20001976wyADtS8iUp.png

繪製的思維很直覺,先跟使用者訪談,將使用者的角色、屬性、職掌記錄下來,再從訪談記錄中將流程萃取出來,並思考現行流程如何改善,就可畫出上述的流程圖,並將每一個處理的輸入及輸出標示出來,即為資料流。期間如果要存檔或寫入資料庫,即繪製『資料儲存』(Data Store)。注意,DFD不考慮例外狀況及控制,只描述資料在處理之間的流動,細部規劃留待系統設計階段處理,避免過於鑽牛角尖。

  1. 資料字典(Data Dictionary):將資料流的欄位內容列表,並註明資料型態、長度、預設值、發生頻率等。
    https://ithelp.ithome.com.tw/upload/images/20210921/20001976tCRaTVbaRP.png
    圖六. 資料字典

  2. 資料儲存(Data Store):與資料流相同,列出包含的欄位內容。注意,在系統分析階段,並不需要對資料儲存作資料表的規劃,例如正規化,現階段主要著重『What』,而非『How』。

  3. 為每個處理撰寫處理規格書(Mini Spec.):以結構化敘述(Structured English)說明輸入資料流如何轉換為輸出資料流,如果,處理邏輯過於複雜,可繪製下一層的資料流程圖,直到處理規格書可以使用一頁就撰寫完成為止。
    https://ithelp.ithome.com.tw/upload/images/20210921/20001976vblXgPBrvz.png
    圖六. 結構化敘述(Structured English)

分層(Layer)的概念是DFD非常棒的特點,它可以把很複雜的系統描繪清楚,例如,ERP系統分為採購、庫存、銷售、會計、...等子系統,而每個子系統的處理又非常複雜,若使用DFD分層繪製,每個人可以聚焦在不同的層次或是不同的子系統,例如圖四『生鮮蔬菜購物系統』 Level 0 DFD 中的『2.0 訂單管理』可以再展開,另畫一張DFD說明細節,如下圖:
https://ithelp.ithome.com.tw/upload/images/20210922/20001976FQcFOumMX3.png
圖七. 『生鮮蔬菜購物系統』 Level 1 DFD,圖片來源:https://sites.google.com/site/gdghujy/gtgrgtr/di1jiedfd

完稿後DFD結構如下:
https://ithelp.ithome.com.tw/upload/images/20210922/20001976Nln98v7N1l.png
圖八. DFD 分層(Layer)

上述工作完成後,就是一本很完整的系統分析報告書,系統設計人員再把控制/例外細節、資料料庫設計、程式規格補上,就可以交給程式設計師開發了。

當年市面上有許多輔助的CASE Tools,可以把圖形超連結,只要點選上層DFD的處理,就可跳到下一層的DFD或處理規格書,點選資料流或資料儲存,就可以彈出資料字典,看到詳細的內容。只可惜價格過高,並沒有被普遍採用,否則,今天搞不好還是『結構化分析』獨霸的局面。

結語

從以上的介紹,結構化分析有幾項特點:

  1. 它是一個完整的方法論,不是單純的圖形工具,只要照著作,就可以完成系統分析的工作,它還有很多檢查清單(Check List),可以自我審查報告書是否有疏漏,另外針對複雜的邏輯,還有其他的圖形工具輔助,如Decision tree、Decision table、State Transition Diagram。
  2. 分層的DFD是一個由上往下(Top Down)的分析方式,先看全貌,再展開為細節,見樹又見林。編碼系統,可以串聯上下層的關係,例如DFD 1 可以展開為 1.1、1.2、1.3...。
  3. 將處理轉為函數非常直覺,因為輸入/輸出(資料流)都描繪清楚了。
  4. 只有處理、資料流、資料儲存、外部系統四種符號,非常容易說明。

相對的,它也有一些缺點,導致此方法論被取代:

  1. 現在物件導向程式設計(OOP)當道,DFD以處理為核心,並沒有與OOP有直接的連結,雖然,Yourdon 出版了幾本書,試圖與物件導向連結,不過,似乎未能挽回頹勢。
  2. 瀑布型的開發期程過長,不符合瞬息萬變的企業環境,導致RUP、SCRUM等並行開發方式崛起。
    https://ithelp.ithome.com.tw/upload/images/20210922/20001976gT3RC3zIFm.png

我還記得當年主管的提醒,不斷的練習才能熟能生巧,從早上醒來到出發上班,都可以練習畫DFD,應用無所不在,例如,這一篇訪談記錄『引進日本經驗打好物流基本功,新竹物流下一步要邁向智慧物流』談到貨運業的貨品追蹤系統,如何以DFD描繪系統功能就是一個很好的個案研究。

這系列的文章雖然以領域驅動設計(DDD)為主,但筆者認為結構化分析的思維,仍有許多值得參考的地方,值得大家品嘗,其中的細節可以講個一天,避免文章過長,只能淺嚐即止了。


上一篇
【Day 03】初探領域驅動設計
下一篇
【Day 05】領域驅動設計的啟動
系列文
淺談中台架構、DDD與Python實踐10

尚未有邦友留言

立即登入留言