不適切なデータフロー図の例
図1●不適切なデータフロー図の例
要求定義と実装は分けて考えなければならないのに,それが交じっている。この段階で,データストアがファイルなのかテーブルなのかなどを定義すべきではない

 便利な図解だが,使い方を間違えると役に立たない。まずは専門家に,「やってはいけない」ことを3点指摘してもらおう。

 最初は「要求と実装を一緒に考えてはいけない」(オージス総研 取締役 ソリューション開発本部 副本部長 兼 アドバンストモデリングソリューション部 部長 山崎朝照氏)ということである。(図1)は要求定義でよく使われるデータフロー図(DFD)だが,書く内容が間違っている。「こうした不適切な図を前提に設計するとデータ構造がメチャメチャになる。メンテナンスに苦労する可能性が高い」(メタジトリー 取締役 松本聰氏)。

 DFDでは,上下の二重線に囲まれた枠を「データストア」と呼び,処理されたデータの格納場所を表す。ただし,これは概念的なものであって,実際にデータをファイルに格納するのか,RDBMSのテーブルに格納するのかなどは,この段階では決めてはいけない。それなのに図1ではプロセスAで処理したデータを「ファイルAに格納する」と明示してしまっている。

 テクニックに走るべきではない――。これが二つ目のやってはいけないことだ。要求定義に詳しいITコンサルタントの鈴村幸太郎氏は,「正しい記法で書かれていても,何のためにこういうモデルを作ったのか分からない図がある」と指摘する。

意味のない概念モデルの例   図2●意味のない概念モデルの例
学習塾の組織を表したクラス図。「人」→「講師」「生徒」の継承は間違いではないが,業務を把握するという観点からは何の意味もない

 (図2)はその一例で,無意味に汎化(複数のクラスから共通の要素を取り出して上位のスーパークラスを作ること)している。確かに「講師」と「生徒」を汎化すれば,「人」というスーパークラスができる。だがこの汎化は,業務を理解するという目的に照らせばあまり意味がない。

使いづらいユースケース図の例
図3●使いづらいユースケース図の例
ユースケース図は,業務を定義するのに向いているが,複数業務をふかんするのには使いづらいことがある

 三つ目は,UMLなどのモデルの使いどころを間違えてはいけないという点だ。カタログの作成から商品の配送までをカバーする通信販売システムの案件で説明しよう。このシステムの全体をユースケース図で書くと,在庫管理や商品管理など細切れの図になり,図と図の関係を理解するのが難しくなる(図3)。

 「複数の業務をまたがって処理が流れるような大きなシステムの全体を,ユースケース図でふかんするのは難しい。こういう場合は,業務フロー図を書くと分かりやすい」(オージス総研 アドバンストモデリングソリューション部 モデリング技術チーム シニアコンサルタント 正木威寛氏)。ユースケース図は,開発のスコープを考える段階で,個々の業務の大枠を理解するのに有効な図である。

 *  *  *

 次回からは,図解のうまい利用法を探る。「漏れ」「過剰」「誤り」という仕様バグに着目し,それらをなくす現場の知恵を集めた。