The Dragon Scroll

Be just and fear not.

TFP分割図に触れてみる。

要求開発アライアンスの定例会に初参加しました。
あいにくの天気で、気持ちが萎えかかりましたが、
意を決して新宿まで行きました。
行って良かったです。あの時判断した自分に
感謝。


事前に要求開発の本を再読して、備えておきました。
テーマは、TFP分割図の解説。
TFP分割図の説明は、『要求開発』でも、数ページしか
記載されていないので、今回の講義は、
とても参考になりました。
講師のお一人は、親しみのある関西弁でしたし。


以下は私なりの理解。
TFPは三つの図から成る。
Tは、Thing図。
モノをあらわすモデル図。ERDに繋がるものと言われると、
理解しやすい。
Fは、Function図。
機能をあらわすモデル図。DFDに似たものと言われると、
やはり理解しやすい。
最後のPは、場を表すPlace図。パッケージと言われると、
しっくりきます。
これまで使用してきたERDやDFDといったモデル図は
馴染み深いものですから。


講師の牛尾氏の次の言葉が、TFP分割図の本質を
表しているようです。
「クラスやアクティビティ図にDFDやERDのええところを
 ルールとしてぶちこんだもの。」
DFD+アクティビティ図→Function図
ERD+クラス図→Thing図
と言えると。
DFDでは扱えなかったようなスーパークラスの概念も
Function図では扱うことができる。


ところで、そもそもTFP分割図を作る目的とはなんでしょうか。
それを理解するためには、まず『要求開発』を
読むべきなのでしょうけども。
ひとまず、以下のように言うことができるようです。
「システムや業務の鳥瞰図」
AsIsをあらわすならば、現在の鳥瞰図。
ToBeをあらわすならば、これから作るシステムや業務の鳥瞰図。
この鳥瞰図を元に、洗い出したモノや機能を、
ERDや機能一覧へ繋げることができる。


講師の又吉氏の説明を聞いていると、実際の業務で
すぐにでも使ってみたいと思いました。
これは、モデル図の良い所取りです。
DFDはデータのフローを表現するため、そもそも
Functionだけを切り出す。Thingだけを切り出しにくい
面があります。
しかし、機能だけを見たい。あるいは、ERDに落とし込むために
データに着目したいというニーズは実際あるわけです。
それに対して、TFP分割図は、Function図+Thing図あるいは、
Thing図だけを取り出しても、モデルとして成り立つわけですから。


また、モデルとしてアクティビティ図の機能も備えている
ようですね。
私は、このアクティビティ図というのがあまり好きでは
ありません。
アクティビティ図の強みは、UMLに数えられていること
ぐらいではないかと思っているクチです。
なぜならば、業務フローを描くのであれば、既に
産能大方式を始めとした業務フローを書くための
方式があるからです。
こちらを使ったほうが、はるかに情報量が多く
分かりやすい(と私は感じています)。


一方、産能大方式にしても、あくまで業務フローを
あらわすもので、データを表現することは、苦手な
モデル図であると感じてきました。
ですから、結局DFDも書いている。
常々、業務フローとデータフローは、システム開発
命綱だと思っています。
その両者を補完あるいは代替するものとして
このTFP分割図は使えます。


私は、TFP分割図に対して、最初はとっつきにくい
イメージがあったのですが、今回のセッションで、
それがなくなりました。
講師のお二人方に感謝致します。