 |
続はじめるUML 第10回（最終回） |
2006.12.1 掲載
続はじめるUML総括（最終回）
一年近くをかけてお送りしてきた本連載も、今回が最終回です。UMLを使用する例としてのケーススタディと、いくつかの立場でのOCUP受験体験記を紹介しました。実際の開発と同様にモデリングツールを利用して、具体的なイメージをつかんでいただけるように心がけました。今回は、前回までの内容を簡単に振り返り、これからどのようにUMLと付き合っていくと良いかを考えてみましょう。
◇UMLはあくまでも道具
本連載のケーススタディは簡単な例ではありましたが、OMGで標準が進められているMDA(Model Driven Architecture)を意識した開発手順で行いました。
略 称 |
正式名称 |
概 要 |
| CIM |
Computation Independent Model |
コンピューターの内部処理に依存しないモデル |
|
| PIM |
Platform Independent
Model |
実装言語などのプラットフォームに依存しないモデル |
|
| PSM |
Platform Specific
Model |
プラットフォームに依存するモデル。開発ツールによっては、PSMからソースコードを自動生成するものもある。 |
|
UMLで規定されているのは、表記と意味といった言語（表記法）の部分のみです。どの段階で、どのような手順で、どんな観点で、どのダイアグラムを記述するかといった、手法やプロセスなどの方法論は規定されていません。本連載のケーススタディはあくまでもひとつの例であり、プロジェクトの性質によってモデリングの仕方を自由に選択することができます。よくある質問のひとつに「どちらのダイアグラムを先に記述すべきですか？」というものがあります。これは、どの方法論を採用するかによっても異なりますが、基本的にUMLはいくつかの視点からモデリングを行うために13種類のダイアグラムが用意されているため、どのダイアグラムを先に書くということではなく、いくつかのダイアグラムを同時並行的に、ダイアグラムの間を行き来しながら記述することで、効率的にモデリングすることができます。
◇モデリングのチェックポイント
ここで、実際にUMLを利用して開発を行う上で、特に注意したほうがよいことを確認しましょう。
1. 目的
そのモデルを書く目的は何でしょうか？目的に合わせたモデリングを行わなければ、無駄な作業を多く行うことになってしまいます。ユーザーの要求を明確にするためのモデルであったり、次工程以降のオブジェクト指向技術での実装につなげるためのモデル、見積もりを行うためのモデル、設計書として納品するためのモデル、ソースコードを生成するためのモデルなどなど、UMLは様々な目的に利用することができ、目的に応じて観点や記述の仕方も異なってきます。
2. 誰のためか
そのモデルは誰が読むモデルでしょうか？実際の開発では、工程毎にモデルを読む人物の役割が異なります。例えば、運用の中でどのようにシステムを利用するかを把握したいエンドユーザーや、より具体的で詳細な実現方法を設計する設計者、モデル変換とソースコードを生成するMDAツールなどが考えられます。読み取り手が何を求めているかを意識しながらモデリングすることで、より効果的なモデルを作成することができます。
3. わかりやすさ
モデリング言語であるUMLが、自然言語やプログラミング言語と大きく異なる点は、図示することによって内容を理解しやすいというところです。この特徴を活かせていない複雑で膨大なダイアグラムは、価値が薄れてしまいます。実際に行われているエンドユーザーの業務や、オブジェクト指向による実現方法をモデリングする場合は、特に複雑になってしまいやすいといえます。複雑なものをわかりやすく表現するのはとても難しいことですが、開発作業をスムーズに行うために、常にシンプルであることを心がけることが重要です。
こうしてみると、モデリングを行う際に特に注意すべきポイントは、日本語の文章を書く場合や、プレゼンテーション資料を作成する場合と同じであり、UMLがやはりコミュニケーション手段のひとつであることを再認識できますね。次の例は、小売店の業務分析において、コミュニケーションを目的として記述したモデルです。顧客が店舗とスタンプカードによって関連し、顧客が複数の会員№を所有することはありますが、顧客がひとつの店舗で複数のスタンプカードを作成することがないということを、ドメインスペシャリスト（業務知識に精通した人）と意識あわせを行うためのモデルです。このモデルを別の目的、例えば設計書としてエンドユーザに納品することはありません。方法論によっては、このダイアグラムを発展させ、メッセージのやりとりを追加してコミュニケーション図としたり、その先のクラス抽出につなげていく場合もあるかもしれません。
図1 - コミュニケーションモデル>>画像を大きく表示
◇おわりに
近年では、特に大規模なシステムにおいても、オープン化による低コスト化などが行われています。UML(1.4.2)はISO(ISO/IEC 19501)にも取り入れられている世界規模でオープンな標準です。また、OMGではUMLの他にも、前述したMDA(Model Driven Architecture)に関連した技術である、モデル変換のためのQVT(Queries/Views/Transformations)などの標準化も行われており、こうした標準技術がオープン化のメリットをさらに引き出していくことが期待できます。
以前にも少し紹介したのですが、本連載で使用したモデリングツールであるパターンウィーバーの次期マイナーバージョンアップであるバージョン 2.2 では、モデルの要素名に日本語以外の別名をつける機能が備わっています。オフショア開発での利用なども想定していますが、今後MDAツールと連携する際には、日本語で書かれた設計書としてのモデルの情報をできるだけ利用し、英名でソースコード生成を行うといった利用方法が予想できます。
図2 - パターンウィーバー バージョン 2.2>>画像を大きく表示
それでは、長い間、この連載におつきあいいただきまして、誠にありがとうございました。またお会いできる日を楽しみにしております。
■筆者紹介
株式会社テクノロジックアート テクニカルデプト モデリンググループ リーダー
照井 康真／Koma Terui
パターンウィーバー(PatternWeaver) ver2.1 |
 |
さらに使いやすく!
- 名前空間（ネームスペース）の管理機能を搭載
- 各種環境設定（デフォルト設定）が可能に
- モデルのビュー（視点）管理機能を搭載
- 最新Eclipseにも対応
- Eclipse3.1.1へ対応
- 組込み系ユーザにも対応
- 状態遷移表の機能を搭載
- C++ソースコード生成プラグイン
|
●商品に関するお問い合わせ
株式会社テクノロジックアート
e-mail : pw@tech-arts.co.jp
http://pw.tech-arts.co.jp/
|
|
|
