UML Forum2001

[2001 年 5 月号]

［UML Forum2001］

UML Forum2001参加レポート

今回、私は上司にわがままを言って、2日間通常業務を休んで、UML Forum2001に参加しました。その償いの意味もこめて、このレポートを書きます。

さて、私の方からは参加したセミナの中からを２つほど紹介させていただきます。１つはMartin Fowler氏の｢Plannig Agile Projects｣、もう1つは児玉公信氏による｢UMLによるビジネスモデリング｣です。

Planning Agile Projects

このセッションはMartin Fowler氏の衝撃的な告白で始まりました。｢はじめに皆さんにお詫びをしなければなりません。私のマシンが日本に来る途中でクラッシュしてしまい、当セッションのスライドが無くなってしまいました｣ということで、このセッションはFowler氏の口頭での講義と手元の資料のみで進めることになりました。ちなみにFowler氏がマシンがクラッシュしたことを話したとき、会場では笑っていた方もいたのですが、私は見事に英語を聞き取れず、笑い損ねてしまいました。こんな時は英語を勉強しなければと、痛切に感じますね。

概要

Planningという単語から想像つく方もいるかもしれませんが、当セミナはXPなど一連のLight-weight Process(Agile Process)において、どのようにプロジェクトの計画を立てればよいのか講演したセミナでした。ちなみにAgileとは｢機敏な｣という意味で、Light-weightと同義のようです。以下に講演された順番に沿って、気になった点についてあげました。

なぜ計画するのか(Agile Processにおける計画の必要性)

計画を立てることにより、存在する選択肢を理解でき、それにより最も重要な事に時間を割くことが出来る。
計画を立てることで、開発者のアクティビティと他社のアクティビティを調整できる。
計画が存在すると予期していない出来事に容易に対処できる。
計画から外れることは誤りではない。

計画における変数(計画の変更時の変更要因)

コスト：人、設備、モラル改善。特に協調されていたことは、人の変更は効果があがるまで時間がかかり、予測不能であることです。
品質：外部品質、内部品質。内部品質を下げると生産性が低下する。
スコープ：容易に変更しやすい。調整可能。
時間：プロジェクトの最後になるまで結果が見えない。調整可能。

リリース計画(リリースの計画法)

リリースとはRUPのフェイズにあたります。
イテレーション、ストーリーの見積もりを行う場合、以前のリリースをもとに見積もりを行う。
ストーリーごとに重みをつけ、１イテレーションで実行可能な分量(Velocity)、イテレーションに割り振る。

感想

セミナの当初は、スライドが存在しないこともあり、果たして問題なくセミナが進められるのだろうか、と心配しましたが、Fowler氏が非常に気を配って、テキストと連動したゆっくりとした丁寧な説明をしてくださったおかげで、わかりやすいセミナとなっていました。

XPの世界では、今回のセミナのような計画は変化するというスタンスは当然のことなのかも知れませんが、XPを経験したことのない私にとっては、計画は守るものという先入観があり、抵抗を感じてしまいました。ただ、概要の｢なぜ計画するのか｣に書いた内容は私にとっても納得の行くものでした。

UMLによるビジネスモデリング

今回のUML Fourmで私が最も興味を持っていたのがこのセッションでした。児玉公信氏によるこのセミナの内容は大きく分けてモデリング自身ついてと、ビジネスモデリングへのUMLの適用の可能性を探るものに分かれていました。

概要

ビジネスをモデリングするためのプラクティスとUMLによるビジネスモデリングの事例を取り上げたセミナでした。以下に講演された順番に沿って、気になった点についてあげました。

ビジネスモデル

ドメインの概念的観点からモデリングを行う
表層的な、非正規的なモデルでもシステムは作れるが、そのようなモデルはビジネスの変化に弱いため、ビジネスの最適化を阻害するシステムができあがってしまう。

ビジネスユースケース

主アクタは受益者
目的は必須、アクタから見た目的
事前条件、事後条件はアクタが観察できる条件
include, extendはなし

型図(クラス図のタイプ版)においては、OCLやErikson-PenkerによるOCL拡張を用いてビジネスルール表現する。

アクティビティ図

アクティビティ図を用いて、ワークフロー記述を行う。
ビジネスプロセスを表現するためのアクティビティ図の拡張が、Eriksson-PenkerのBusiness Modeling with UMLで提案されている。

感想

モデリングを行う理由というのを考え直すいい機会になりました。お客様の業務をモデリングする際には、とりあえずのシステムが構築できるモデルを構築するのではなく、絶えず変化していくビジネスに追随できる、システムの基盤となるモデルを構築するという心構えが必要ではないでしょうか。

今回とりあげられませんでしたが、セミナの中でいくつかのビジネスモデリングの例があげられていました。それを見ていて感じたことは、ビジネスの静的、動的な構造を表現することにはUMLは使えるかもしれないが、できることはそれまででその表現されたモデルを評価する手段としてUMLが使えるわけではないということです。しかし、良く考えてみると当然のことかもしれません。UMLは表記法であり、良いものを表現する技術、表現されたものが良いと判断する技術ではないわけですから。もし、UMLがビジネスモデルを表現するに足りるとしても、ビジネスモデルを構築、検証するためのメソドロジーが必要かもしれません。

アンケートにご協力お願いいたします
記事の内容を５点満点で評価してください。
1点	2点	3点	4点	5点

HOME

TOP