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