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

フローチャートの概要

by Scott W. Ambler, Copyright 2003

フローチャートは、1940〜50年代に紹介され、1970年代の構造化開発(Gane and Sarson 1979)やビジネスモデリングで普及したモデリング技法です。図1は、「大学に登録する」のユースケースのフローチャートです。このフローチャートには3つの基本的なシンボルが使われています。アクティビティやタスクを表す長方形、分岐点を表すひし形、制御フローを表す矢印の3つです。フローチャートでは他のシンボルも使うことができます。ページ外へのコネクタ(図が大きくなりすぎたときのため)や、印刷されたレポートやデータストレージのオプションを表す入出力のシンボルなどです。フローチャートは小さい方が好きなので、私はページ外へのコネクタはほとんど使いませんが、レポート(長方形の下辺が波打ったもの)やデータベース(円筒形)をモデリングすることは時々あります。

 

図1. 大学に登録する

== Distribute Forms to Student: 学生に申込用紙を配布する Fill Out Forms: 申込用紙に記入する Validate Forms: 申込用紙を確認する Valid?: 有効か? Security Risk?: セキュリティリスクがあるか? Deal With It: 対処する Student Exists: 学生が存在する Eligible Applicant?: 登録資格のある申込者か? Inform Applicant: 申込者に知らせる Create Student Record: 学生レコードを作成する Enroll in Seminars: ゼミに登録する Calculate Fees: 授業料を計算する Request Payment: 支払いを要求する Sufficient Funds?: 手持ちの現金が足りるか Collect Fees: 授業料を徴収する Produce Receipt: 領収証を作成する Yes: Yes No: No ==

このフローチャートと、同じユースケースをモデリングしたデータフロー図(DFD)とを比べてみてください。システム内のデータフローを記述するためのDFDと違って、フローチャートは通常、ビジネスプロセスやビジネスルールの詳細ロジックを記述するのに使います。過去には、フローチャートを使って大規模なソフトウェアモジュール(3万行のCOBOLプログラムなど)をモデリングすることが一般的に行われていました。しかし、オブジェクトのメソッドはずっと小さいため(30行のメソッドでもかなり大きいとみなされるでしょう)、近年プログラマがフローチャートを好んで使うことはなくなっています。フローチャートはプロセスモデリングにはまだまだ役に立つのですから、それは問題ありません。注意して欲しいのは、このフローチャートはDFDよりずっと詳細になっていますが、どちらの図も同じレベルまで詳細にすることは容易だという点です。

この図を作成する場合、私はビジネスロジックを1ステップずつ追っていきます。最初はホワイトボードの左上からです。何もないところから矢印が始まり、「学生に申込用紙を配布する」のステップに入っています。興味深いのは、ユースケースでは特にこのステップを最初のステップとして呼び出していないところです。ただし、これは暗黙的に含まれていて、申込書に不備があると学籍係が判断した場合にはこのステップは必須になっています。

判断が行われるところにはひし形の分岐点を使っています。この例では、分岐点はすべてYES/NO形式の質問になっていますが、必ずしもそうでなくても構いません。「何曜日か?」という質問を書いて、一日に1本、合計7本の矢印をひし形から出すこともできます。分岐点から出る矢印には適切な条件のラベルを付けるべきですが、図を見ると分かるように、「有効か?」のひし形から出る矢印には「Yes」のラベルを付け忘れています。思い出してください。アジャイルなモデルはそこそこ役に立てばよいのです。

このフローチャートを書くことで、ユースケースのロジックの間違いがいくつか見つかったのは興味深いところです。まず、クエスチョンマークだけが入っている長方形は、ユースケースの代替コースをさらに考えなければならないことを表しています。しかしこれはたいした問題ではありません。ロジックで本当に問題になるのは、その人が登録資格のある申込者のリストに載っているかどうかを確認する前に、データベース上に存在するかどうかを確認していることです。これは私には何かおかしいように思えるので、利害関係者と話をして確認する必要があります。ここでAMの「利害関係者の積極的な参加」のプラクティスが真価を発揮します。利害関係者が私と一緒にこのモデルを作成している場合には、その場で問題を解決することができます。そうでなければ、利害関係者とこの問題について話をできる機会を待つか、その場で何かをでっち上げて後で修正するというリスクを冒すことになります。

フローチャート作成時にアジャイルであり続けるための最善の方法は、ものごとをシンプルにしておくことです。利害関係者と一緒にフローチャートをホワイトボードに書き、重要なビジネスロジックについて話し合います。図を残しておきたければデジタルカメラで写すか、必要でなければ終わった後で消してしまいます。たいてい価値があるのは作成したモデルではなく、モデリング作業自体です。ものごとをじっくりと考えることになるからです。たとえば、図1のフローチャートを作成することで、私のチームはユースケースの潜在的な問題点を見つけることができました。しかし、その問題を解決してしまえば、このフローチャートにはそれ以上の価値はあまりありません。

最近では私はあまりフローチャートを使いませんが、それはUMLアクティビティ図の方を使うためです。実際、アクティビティ図はおそらくフローチャートを改良したものだと言えるでしょう(それだけではありませんが)。それでも、経験を積んだITの専門家が使うのを時々見かけるでしょうから、フローチャートについて知っておくことは重要です。

 

注: この成果物の説明は『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 June 8, 2004.