簡単なソフトウェアを作るときには設計書はメモ程度に済ませ、いきなりコーティングやテストを行うこともあります。仕様が簡単なため認識のズレやバグの作り込みの可能性が低いのでメモ程度の設計書でこと足りるからです。
ですが、大規模なソフトウェアを作るときにメモ程度の設計書でソフトウェアの作成を進めることは難しいでしょう。それは、ソフトウェアの作成を依頼する側と、ソフトウェアを作る側に認識のズレが起こる可能性が高いからです。
DFD（データフロー図）はソフトウェア制作を依頼する側と作る側の認識を合わせるツールとして使うことができます。ソフトウェア開発を行うメンバーと、システムのイメージを共有するのにも使え、機能の漏れや重複を防ぐこともできます。
ここではDFDとは何か、そしてDFDの書き方についても紹介します。
目次
DFD（データフロー図）とは
「DFD（データフロー図）」とは、システムにおけるデータの流れを表した図のことです。データの流れを書くことでシステムの機能を洗い出します。
コンピュータ上のシステムの設計に使えるのはもちろん、業務フロー分析にも使うことができます。視覚的にシステムをとらえることができることからシステム構築を行うSEと構築を依頼した顧客が、お互いの認識合わせにこの図を使うことにも有効です。
DFDの別の呼び名として、「データフローダイアグラム」、「データフローグラフ」、処理を丸（バブル）で書くことから「バブルチャート」といったものもあります。
構造化分析とDFD
DFDは、トム・デマルコにより提案された構造化分析のツールのひとつです。構造化分析は1970年代後半から普及しました。大きく複雑なシステムを概要から詳細へと階層化することで、人の頭で考えやすくする設計手法です。
『構造化分析とは「DFD」「データディクショナリー」「ミニ仕様書」といったツールを用いて構造化仕様書を作成すること』とデマルコは定義しています。この中でも、DFDはシステム上のデータの流れを直感的とらえることができる図であることから、構造化分析の柱となります。
DFD（データフロー図）で使う記号
DFDで使う記号は、「データフロー」「プロセス」「データストア」「源泉と吸収」の4つです。DFDには提唱者ごとに記号の表現方法が異なります。
DFDの描き方で有名なのは、デマルコ式と、ゲイン・サーソン式です。デマルコ式はプロセスを円（バブル）で表現しますが、ゲイン・サーソン式では角の丸い長方形で記載します。提唱者によって記号が異なる部分もありますが、基本的な考え方は同じです。
データフロー
データフローは、データの流れを表す矢印です。プロセス、データストア、源泉と吸収の要素間のデータの流れを表します。矢印には必ず名前をつける必要があります。
プロセス
プロセスはデータの加工を行うものです。デマルコ式では円で、ゲイン・サーソン式では角の丸い長方形で描きます。
プロセスは記号の内側に名前を記載します。見る人が概要をすぐに理解できるような名前がいいです。
また、DFDではプロセス個別の番号をつけます。DFDを階層で記載したときに、プロセスの番号から階層ごとの図の関係性がわかるようになります。
データストア
データストアは一時的なデータの保管場所です。データストアの例として、ファイルやデータベースなどがあります。デマルコ式では二重線で表現します。
データストアに名前をつける際は、見た人がすぐに理解できるものにするといいです。ほかのシステムのデータベース名と名前が被ると将来問題が起きるのではないかという不安から、一意性のある通し番号を名前にしようという考えもあるかと思います。
しかし、DFDの「直感的でわかりやすい」というメリットを失う恐れがあるので理解しやすい名前にすることがいいとされています。
源泉と吸収
源泉と吸収は、対象システムの外側の人や組織のことです。データをシステムに渡してくるもの（源泉）、データをシステムから受け取るもの（吸収）を表します。デマルコ式では名前をつけた長方形で表現します。
源泉と吸収は、対象システムとデータをやり取りする外部要因なので内容について書く必要はありません。注目する必要があるのは対象システムに入ってくるデータです。源泉と吸収についてはシステムへの理解を深めるために記載しているものと考えるといいです。
DFD（データフロー図）の書き方
ここでは、DFDを書くときのルールやポイントについて紹介します。
DFDのルール
DFDの書き方にはいくつかのルールがあります。以下がそのルールです。
プロセスには入力と出力のデータフローがどちらも必要
プロセスは入力したデータを加工して出力するものです。ですので、必ずデータの入力と出力が少なくともひとつずつ必要になります。入力はひとつで出力は複数あるという場合もありますし、逆に入力が複数で出力はひとつという場合もあります。
データストアには入力と出力のデータフローがどちらも必要
データは使わなければ保存する意味がないため、データストアには入力と出力のデータフローがどちらも必要になります。
データフローにはすべてに名前をつける
DFDは「どんなデータ」をやり取りするのか表す図なので、すべてのデータフローに「どんなデータ」かという名前をつける必要があります。名前がつけにくいデータフローはデータのまとまりとしてはいまいちであることが多いです。その場合はデータフローを分割するか、分割できない場合はデータフロー自体を削除することも検討します。
データフローに処理を書き込まない
データフローに「〇〇する」といった処理を書いてしまうことがあります。これは処理の流れを表す図である「フローチャート」の書き方が混ざっている可能性があります。
DFDは処理の流れについては書かず、データの流れのみを書く図です。「〇〇する」という動詞が名前になっているデータフローは誤りですので検討し直しましょう。
プロセスには、入力データと出力データの処理の内容がイメージできる名前をつける
プロセスには入力データと出力データが必ずひとつ以上あるので、プロセスに名前をつける場合は、入力データと出力データのどちらもイメージできるような名前にすると、見た人が直感的にシステムをイメージしやすくなってわかりやすい図になります。
処理の実行順序について書かない
DFDは「どこ」と「どこ」がデータをやり取りするのか明確にするための図なので、「いつ」データをやり取りするのかについては言及しません。処理の実行順序について描きたい場合は、フローチャートやシーケンス図など処理の流れを表現する図を別に作ることをおすすめします。
DFDのレイヤーとコンテキストダイアグラム
DFDを書くときは、構築するシステムをひとつの大きなプロセスとして、外部システムや操作者とどんなデータをやり取りをするかを記載するところから始めます。このシステムの全体を捉えた最上層のDFDを「コンテキストダイアグラム」といいます。
このコンテキストダイアグラムをより詳細にするため、段階的に下層のDFDを作成していきます。下層のDFDは上位のDFDのプロセスごとにひとつ作成されます。
このとき、ひとつのレイヤー（層）ごとにプロセスは7個以下に抑えて記載すると良いです。数を絞ることでDFDが見づらくならず、見るとすぐ直感的に理解できる図になります。
また、レイヤー分けをする場合、0、1、2といった番号をプロセスに割り振ります。下層のDFDは上層の番号を継承し、0.1、0.2といった番号を記載しておくと、上位と下位といったレイヤーの関係性がわかりやすくなります。
DFD（データフロー図）の記載例
ここではDFDの例をもとに、DFDの書き方を紹介します。
- まずは源泉と吸収から書き始めます。用紙の中央には分析対象のシステムを書くため、源泉と吸収は用紙の端に書いておくと、以降の作図が進めやすくなります。
- 図の真ん中にある点線の円は、対象となるシステムを表しています。始めはこの点線の円をひとつのプロセスとみなして、源泉と吸収とやり取りするデータフローを記載します。
DFDを書くときに大切なことは、概要から考え始め、徐々に詳細にしていくことです。システムをひとつのプロセスと見ることで、源泉と吸収とどのようなデータをやり取りするのか考えやすくなります。 - プロセスがひとつだけでは大雑把すぎるためプロセスを分割します。分割するときは源泉と吸収とのデータフローに着目して分けると書きやすいです。
- プロセスを分けることができたら、プロセスに名前をつけます。名前がつけにくい場合はさらに分割する必要があります。
- データストアを追加して、さらにプロセスやデータフローを分割していきます。プロセスの数が7個以上に増えそうならレイヤーを分けます。下層のDFDを書くときは、どのプロセスを書いているのかがわかるように、通し番号を振っておきます。
- プロセスの分割を進めていった場合に気になるのはどこまで分割するかです。そこで、分割の基準をプロセスの大きさで判断します。プロセスひとつにつきその機能を説明する仕様書（ミニ仕様書）を作成する際に、1ページくらいの規模になればそこが分割の最後と判断します。
データディクショナリー
データフローはやり取りする情報を表した記号ですが、DFD中に書かれるのは情報の概要または名前のみです。そこで、データフローをより詳細に定義するためにデータディクショナリーを使います。
たとえば「申請情報」というデータフローには次の情報が含まれています。
- 氏名
- 生年月日
- 住所
- 性別
DFDの中に書き込むと細かすぎて図を複雑にしてしまうので、データディクショナリーとして別紙に書きます。
データフローではデータをやり取りする関係が俯瞰でき、具体的にどんなデータになるのかはデータディクショナリーで確認できれば、見る人にわかりやすいドキュメントになります。
また、データディクショナリーは次の記号を用いて記載することもできます。
＝ 〜に等しい
＋ 〜と（AND）〜
[ ] 〜または（OR）〜
{ } 〜の繰り返し
( ) 〜のうちのどれか
たとえば「申請情報」を記号を使って書くと、次のようになります。
申請情報＝氏名＋生年月日＋住所＋性別
性別＝[１：男性｜２：女性]
ミニ仕様書とデシジョンテーブル
データフローの詳細としてデータディクショナリーがあるように、プロセスの詳細としてミニ仕様書というものがあります。ミニ仕様書ではDFDには書ききれないプロセスの詳細を記載します。
複雑な条件や処理の内容など記載しますが、その表現方法は文章だけでなく、構造化言語、デシジョンツリー（決定木）、デシジョンテーブルなどもあります。ここではデシジョンテーブルについて紹介します。
デシジョンテーブルは、複雑な条件を整理するのに適した表現方法です。書き方は表形式で、縦に「条件」、横に「場合」を記載し、その条件ごとに適応される（Yes）、適応されない（No）を書いていきます。
そして、その条件に対してどう対応するかも表にします。縦に「行動」、横に「場合」を記載します。条件の表と行動の表の「場合」はそろえます。
審査を行う場合を例にしてみましょう。審査用の書類が揃っていて、なおかつ書類の内容が正しい場合には証明書を発行する。書類が足りない場合は、書類不足の通知を出し、内容が誤っている場合には、書類不備の通知を出すという処理を行うとします。
この場合のデシジョンテーブルは次のとおりです。
| ＜場合＞ | ||||
| ＜条件＞ | １ | ２ | ３ | ４ |
| 書類が揃っている | Y | Y | N | N |
| 内容が正しい | Y | N | Y | N |
| ＜場合＞ | ||||
| ＜行動＞ | １ | ２ | ３ | ４ |
| 証明書発行 | Y | N | N | N |
| 書類不足通知 | N | N | Y | Y |
| 書類不備通知 | N | Y | Y | Y |
こうしてデシジョンテーブルを作ると、条件が重なったときにどういった行動をとるかを明確にすることができます。この例では書類が揃っていない場合も、書類のチェックを行うようになっていますが、書類不足の場合は書類のチェックを行わないといった条件にすることもできます。
このように、文章の説明だけでは見えていなかった条件を見つけることができたり、その場合の行動を明確にすることもできたりするのが、デシジョンテーブルのメリットです。
DFDでシステムの分析と認識合わせをしよう大規模なシステムの開発は、上流工程でしっかりとした分析や認識合わせを行うことにより、手戻りを防ぐことができます。DFDはデータの流れに着目した分析手法です。
視覚的に理解しやすいというメリットがあるため、システム開発を依頼した人と、システム開発を行う人の認識を合わせるためのツールとして有効です。ぜひシステム開発で使ってみてください。
👩🎨 Cacooでデータフロー図を作ってみませんか？ 🎨
Cacooを利用中の方はこちらをクリック ・ Cacooを試してみたい方はこちらをクリック
