ObectSquare

[Martin Fowler氏 講演レポート]


Martin Fowler氏 講演レポート

by への

Martin Fowlerという人物

講演内容 -UMLモデリングのエッセンス- 編

講演内容 -アナリシスパターン- 編

最後に


Martin Fowlerという人物

冒頭から「私は反抗的です」という発言で茶目っ気たっぷりのところを披露したFowler氏は、生っ粋の英国人ということで非常に聞き取りやすい英語を話していました。 容貌もヒジョーに広いおでこ、髪との境界が分からないほど立派な髯、髭、鬚。グレーのセーターを着て大変印象的でした。 肝心の講演はFowler氏の著書である「UMLモデリングのエッセンス」と「アナリシスパターン」の二つのテーマに分けて行われました。


top


講演内容 -UMLモデリングのエッセンス- 編

「UMLモデリングのエッセンス」のテーマでは、著書から更にエッセンスを抽出したような内容で、UMLの要点を押さえて簡潔にまとまっていて大変分かり易かったです。 具体的にはUML登場の経緯から始まり、ユースケース、クラス図、CRCカード、相互作用図をUMLの中核となるテクニックとして解説し、その他にパッケージ図、状態図、アクティビティ図、配置図とコンポーネント図にも簡単な説明を加えた後、最後にUMLを実際に導入するためのアドバイスを紹介するといった内容でした。

講演の全体を通してFowler氏が強調していたのは「UMLはコミュニケーションのための道具」であるということで、そのためには「モデリングの観点」に注意して、不要な情報を取り除いた「シンプルなモデル」を心掛けるのが重要と仰有ってました。

参加者からの質問も開発現場で実際に問題となるようなものが多く、とても充実した内容だったと思います。 ここで折角ですから、参加できなかった人のためにもUMLモデリングに対するFolwer氏の意見をまとめておきましょう。 (※ 私が理解した範囲でまとめてますので、誤った理解をしている部分もあるかもしれません。あしからず)

ユースケースについて

  1. 図よりもコンテンツ(記述内容)に力を入れなさい。
    (※ 図は二次的な価値を提供するに過ぎないと仰有っていました)
  2. ユースケースの単位は大きくても小さくてもうまくいくので余り神経質にならなくても良い。
    (※ 要は、統一された単位で扱えば余り問題にはならないということでしょう)

クラス図について

  1. モデリングの観点に注意する。
    (※ 著書にも紹介されていますが、概念(Conceptual)・仕様(Specification)・実装(Implementation)の3つの観点です)
  2. 観点が異なる図は、似ているが同じではない。
  3. 仕様の観点を重視することを推奨する。
  4. UMLの要素は限定して使用する。
    (※ 過度に複雑なモデルにならないためのアドバイスでした)

CRCカードについて

UMLとは直接関係のないテーマですが、モデリングのテクニックとしてあげたようです。

  1. ウォークスルーをロールプレイング形式でやるべきではない。
    (※ 代替ケースを不必要に発見してしまう危険性があるそうです。 ちなみにFowler氏はCRCの生みの親、K.BeckとW.Cunninghamが実際にロールプレイングをしているのを見たことがないと言ってました)

相互作用図について

  1. 条件によって変化する振る舞いは図を分けて記述する。
    (※ 条件付きでも記述できますが、図をシンプルなままに止めておくためのアドバイスでした)
  2. 必要に応じて記述する。
    (※ すべての振る舞いを相互作用図に記述するのは無意味だそうです。コミュニケーション上必要がある場合に書けば十分とのことでした)
  3. 書きすぎないように注意する。

UMLの導入について

  1. 最初は最低限の三種類の図(ユースケース図、クラス図、相互作用図)から始める。
  2. 必要のない部分は利用しない。

最後に会場の方からの質問で、UMLをユーザーとのコミュニケーションに利用するためのガイドラインを挙げていましたので紹介しましょう。

ユーザーとのコミュニケーションに利用するためのガイドライン

  1. 「ユースケース」、「概念の観点でのクラス図」、「アクティビティ図」を利用する。
  2. 「ユースケース」はユーザーに馴染みのある言葉を用いた自然言語で記述する。
  3. 「クラス図」は観点を概念に絞り、ユーザーにも容易に理解できるように利用する要素を限定して単純化する。
  4. 「アクティビティ図」はワークフローを理解するためのツールとして利用する。


top


講演の内容 -アナリシスパターン- 編

「アナリシスパターン」のテーマでは、著書に書かれている内容をベースに行われました。 モデルを提示する、問題点を挙げる、パターンを用いて解決する。この手順を繰り返してパターンの説明が行われ、それぞれのパターンのみならずパターン同士の関連や、パターンを適用していく過程まで疑似体験できる素晴らしい内容でした。本を読むよりはるかに分かり易く、難解といわれる文章に挫折しそうになった人でも十分に理解できるものだったと思います。 講演で扱われたパターンは以下の通りです。

こちらも「エッセンス」の例に倣って、Fowler氏の意見をまとめておきます。

アナリシスパターンとは

  1. 概念レベルで見つかるパターンのこと。
  2. コンポーネントとは違う。

パターンを人に説明するためのコツ

  1. 今までに経験したことがあるようなことを題材に選んで説明をする。
    (※ これでピンとくることが多いそうです)

パターンを適用する判断基準

パターンには欠点と利点があるので適用は慎重に行う必要がある。

  1. Forceのバランスに注目する。
  2. パターンの問題事項を良く読む。
  3. パターンの適用可能性が非常に重要。

パターンの特徴について

  1. 小規模で適用範囲の広いパターンが存在する。
    (※ 多種多様な領域で適用できるそうです)
  2. パターンは全面的な解答にはならない。
    (※ パターンを適用する場合必ず若干の変更が必要となり、適用したものは二つとして同じ物がないと仰有ってました)

パターンというテーマのためか「エッセンス」の時よりも参加者の反応はいまひとつという感じです。最後の質疑応答の時にようやくちらほらと質問が出ていました。 個人的にはどちらかというと今あるパターンについての即物的な傾向の質問が多かったように感じられました。 というわけで「パターンの認知度」は十分に高くなってきているのですが、「パターンの理解」についてはまだまだ十分ではないと感じる次第でした。


top


最後に

Fowler氏は自分の考えを相手に伝えること、つまりコミュニケーションを非常に大切にしている方でした。講演自体も質問に対する回答もたいへん丁寧に行っていました。 これはエンジニアが見落としがちな部分ですが、自己満足に陥らないようにするためにも自分自身気を付けていかねばと改めて思います。 またUMLに関しても、Fowler氏にとってUMLはコミュニケーションを円滑にする道具であってそれ以上の存在ではないようです。 ただUMLでモデルを書き散らしているだけでは、モデリングとはいえないという警句にも取れます。 「過ぎたるは及ばざるが如し」ですね。

以上、なんともとりとめのない内容ですが講演レポートとさせていただきます。


top

© 2000 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP