アジャイルモデリング(AM)
公式サイト
モデリング成果物>データフロー図(DFD)

データフロー図 (DFD) の概要

by Scott W. Ambler, Copyright 2003

データフロー図は1970年代後半に提案され、構造化分析と設計(Gane and Sarson 1979)において普及しました。DFDでは、外部エンティティからシステムへのデータの流れ、プロセスからプロセスへのデータの流れ方、そしてその論理ストレージを表します。図1は、GaneとSarsonの記法によるDFDの例です。シンボルは4つしか出てきません。

  1. 四角形は外部エンティティを表します。これはデータの移動元または移動先になります。

  2. 角の丸い四角形はプロセスを表します。プロセスは、入力としてデータを受け取り、何かを行なって、それを出力します。

  3. 矢印は データの流れを表します。電子データでも物理的なものでもかまいません。

  4. 右端の開いた長方形はデータストアを表します。データベースやXMLファイルといった電子的なものも、ファイルキャビネットや書類の山といった物理的なものも含まれます。

 

図1. 大学に登録する

この図を作成するために、私は利用シナリオを使用しました。この場合の利用シナリオは、システムユースケース「大学に登録する」に記述されたユースケースの定義（アクションの流れ）です。実際のプロジェクトでは、プロジェクトの利害関係者と一緒にホワイトボードに向かって、問題について議論しながら直接書いていく方がずっと一般的です。

今回私は、左上の外部エンティティの申込者からスタートして、データがシステム内をどう流れるかをたどっていきました。「申込用紙をチェックする」というプロセスを作って、最初の確認のステップをそこにまとめました。このプロセスには1.0という識別番号をつけて、トップレベルの図の1つめのプロセスであることを示しました。DFDでは、プロセスごとに詳細図を作成して、より細かいレベルの処理をそこに記述するという方法が一般的に使われます。このプロセスでもその方法を使うとしたら、サブプロセスに1.1、1.2などという番号をつけることになるでしょう。1.1のサブプロセスは1.1.1、1.1.2のようになります。このプロセスに関しては、さらに詳細なDFDに展開することはしません。何が起きているかはきわめて明白で、新しい図を作成することに価値はないからです。また、プロセスの箱の一番下のセクションに、何/誰がその仕事をするのかも示しました。この場合は学籍係です。この情報は書かなくてもいいのですが、私の経験では非常に役に立ちます。申込用紙は、記入に不備がある場合、必要なであれば申込者に返されることが分かります。

続けてユースケースのロジックをたどりながら、各ステップでデータがどう処理されるかに着目していきます。2つめのプロセスには、学生レコードを作成するロジックがカプセル化されています。その学生に登録資格があるかどうかや、すでにデータベース上に存在するかどうかといった確認がここに含まれます。図のデータフローすべてにラベルが付けられていることに注意してください。また、どう処理されたかによってデータの名前も変わっています。

今ここで図をじっくり見ると、「学生情報を入力する」のプロセスと「学生DB」データストアとの間の矢印は双方向でなければならないことが分かります。このプロセスでは学生レコードが存在するかどうか、データベースを検索するからです。残念ながら私はこの図をホワイトボードから消してしまったので、さほど重要でないこの問題に簡単には対処できせん。もちろん、描画ツールを使っていたのであれば矢印を変更することもできたでしょう。しかし、更新することよりも、アジャイルなモデルでは完璧でなくても何とか役に立つということの方がもっと重要です。AMでは「困った時だけ更新しよう」というプラクティスを推奨しています。この場合、2、3分の時間をかけて図を更新しなければならないほど困っていないので、更新せずに置いといておけばよいでしょう。

「授業料を徴収する」のプロセスが興味深いのは、電子的なデータストアの「財務DB」だけでなく、物理的なデータストアである「金庫」とも相互作用している点です。DFDを使って、完全に物理的なプロセスも、完全に電子的なプロセスも、あるいはより一般的な両方が混ざったプロセスも、モデリングすることができます。電子的なデータストア、特にリレーショナルデータベースは、データモデルでモデリングすることができます。物理データストアについてはたいてい、改めて説明するまでもありません。

私がDFDを作成するときには、いくつかのモデリングルールに従っています。

  1. どのプロセスにも、少なくとも1つの入力データフローと1つの出力データフローがなければならない。

  2. どのプロセスも、入力データを変更して新しい形の出力データを作成しなければならない。

  3. 各データストアは少なくとも1つのデータフローに関係しなければならない。

  4. 各外部エンティティは少なくとも1つのデータフローに関係しなければならない。

  5. データフローは少なくとも1つのプロセスに結び付いていなければならない。

従来型の手法の多くは役立たないやり方でDFDを用いる傾向がありますが、アジャイルなやり方で用いても役立たない可能性はあります。ここでの例のように図は小さくしておいてください。ホワイトボードなどの簡単な道具を使って、利害関係者と共同で作成します。身軽な旅をし、使い終わった図は消します。プロセスで作るように指示されているから作るのではなく、価値がある場合にのみ図を作成しましょう。大事な点は、DFD を推奨するモデリング方法論の中には問題があるものもあるでしょうが、システム内のデータフローは表現する必要があるということです。

 

 

注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。本ではより詳しく説明しています。

推奨文献

 

その他の文献

アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。

 アジャイルモデリング

 

Let Us Help　(以下、北米での話ですのでご注意ください）

Ronin International, Inc. continues to help numerous organizations to learn about and hopefully adopt agile techniques and philosophies.  We offer both consulting and training offerings.  In addition we host several sites - Agile Modeling, Agile Database Techniques, UML Modeling Style Guidelines, Enterprise Unified Process (EUP) - that you may find of value.

You might find several of my books to be of interest, including The Object Primer, Agile Modeling, The Elements of UML Style, and Agile Database Techniques.

For more information please contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).

 

visits since November 17, 2003.