 |
[2005 年 1 月号] |
|
[2005 年 1 月号] |
［技術講座］
株式会社 オージス総研
技術部
永田 博靖
Nagata_Hiroyasu@ogis-ri.co.jp
突然ですが、皆さんは、もしこれからオブジェクト指向分析・設計のテクニックを習得したいという方がいたら、どのような書籍をお薦めしますか？
実践的なモデリング手法が解説されている児玉公信さんの『UMLモデリングの本質』 [1] をお薦めしますか、それとも分析・設計を理解するには、まずオブジェクト指向の根底にある基本的な原理を理解すべきだということで、『Booch 法：オブジェクト指向分析と設計 第 2 版』 [2] をお薦めしますか。「いやいや、もっと良い書籍がありますよ」という読者もいるかもしれません。良い書籍がありましたら、是非、お教えください m(_ _)m 。
もし、私が同じ質問を受けたら、私は真っ先に Craig Larman 氏の『実践UML』 [3] の書籍をお薦めします。理由は、良いモデルを作成するためのノウハウやテクニックを段階的に提示しつつ、要求・分析・設計・実装までの一連の流れを具体的な題材をもとに解説しているからです。さらに、繰り返し型開発を成功に導くエッセンスもいっぱい詰まっており、非常に贅沢な書籍となっています。とりあえず、アメリカの Amazon の書評を参照してみてください。100 人近いレビュアーが GOOD!! な評価をしています。そのことからも、この書籍がいかに優れているか納得していただけると思います。
さて、現在翻訳されている『実践 UML 第 2 版』を読むだけでも、その名の通り UML を使った実践的なオブジェクト指向の分析・設計手法を十分に習得できる内容なのですが、去る 2004 年 10 月にこの 『実践UML 第 2 版』 をさらにパワーアップした第 3 版 『Applying UML and Patterns Third Edition』 [4] が出版されました。原書の第 2 版と分量だけを比較すると、約 80 ページの内容が追加されています。私は、英語が苦手ながらも、『実践UML 第 2 版』 以上に有益な情報が書かれていると思ったので、早速 『Applying UML and Patterns Third Edition』 を購入しました。
なお、本記事では、以降 『実践 UML 第 2 版』 を 「第 2 版」とし、『 Applying UML and Patterns Third Edition 』 を 「第 3 版」と略します。
購入してから、3 ヶ月 ・・・なんとかざっと 第 3 版を読み終えることができました。第 3 版と第 2 版を少しずつ比較しながら並行して読み進めることが、短時間で読み終えられた理由だと思います。
本記事では、 第 3 版と第 2 版を比較しながら読み進めた際に、私自身が新しく理解した分析・設計のテクニックやノウハウなどを思いつくままに紹介しています。現在、第 2 版を読んでいる方、もしくは、これから読もうとしている方、また、原書第 3 版を読もうとしている方の理解の参考になれば嬉しいです。
『Applying UML and Patterns Third Edition』 で第 2 版からどのような変更が行われたかを、以下に第 3 版の序文より引用しました。( ) で原文を記載しています。
この変更内容を確認すると、真っ先に UML 2 への対応が記載されているので、オブジェクト指向を用いた開発に役立つテクニックやノウハウなどがあまり追加されていないのでは？という印象を持たれる方が多いかもしれません。しかし、その心配は無用です。第 3 版では、本書全体を通して内容の刷新が行われており、実用的なテクニックやノウハウが随所に散りばめられています。
以降では、第 3 版で新たに追加された内容の中から、特に参考になったトピックを厳選して紹介します。
第 3 版の書籍から参考になったトピックの一部を書籍の構成とは関係なく紹介していきます。
ただ、書籍から私が理解したことを書いているので、 Craig Larman 氏が意図していない内容が読者に間違って伝わるところがあるかもしれません。内容に疑問を持たれた方は原書をご確認ください。
UML はグラフィカルな表記法として一般的に知られていますが、その使い方は、以下の 3 つのカテゴリに分けることができます。
この 3 つのカテゴリは、Martin Fowler 氏が考えたもので、『Uml Distilled Third Edition』 [6] の書籍の中で詳しく紹介されています。また、Martin Fowler's Bliki ( 翻訳 Wiki ) でもそのことについて解説されているので、この 3 つのカテゴリについてはご存知の方が多いのではないでしょうか？なお、blueprint を「青写真」として翻訳している書籍をときどき見かけますが、 翻訳 Wiki のように設計図として訳す方が適切かなと思います。
3 つのカテゴリを簡単に説明すると、以下のようになります。
ちなみに、私は「設計図としての UML」という使い方を利用することが多いです。
第 2 版でも記述されていた内容ですが、第 3 版では、ユースケースモデリングは「図を書くことではなく、テキストを書く行為である」ことがより強調されていました。もちろん、私はそのことを理解していましたが、ユースケースモデリングでは、「機能要件を一覧する役割として、ユースケース図も大事だよなぁ」と思っていたところがあり、私にとってはインパクトが強かったところです。ユースケース図は、ユースケースモデリングにおいてオプション的な位置付けのものでしかなく、コンテキストダイアグラムとしての価値しか提供しないようです。
ちなみに、コンテキストダイアグラムは、DFD の用語であり、システムに対する最終的な入力と出力をグラフィカルに表したものです。コンテキストダイアグラムについては、『構造化分析とシステム仕様』 [7] の書籍を参照してください。
有効なユースケースを判定するための方法として以下の 3 つのテスト方法が紹介されていました。
上司テストは、ユースケースの適切さを上司の判断に任せるというテストです。例えば、上司から「今日は一日中、何をしていたんだ？」と質問されたときに、部下が「ログインをしていました！」と回答したとします。 このとき、「ログインする」する行為に対して、上司が「おっ、よくやっとるな。」と満足したらユースケースとみなし(成功)、「何をやっとるんだ！」と怒ったら、ユースケースではない(失敗)とみなすテスト方法です。(この場合は、どちらかわかりますね？) ただ、上司テストに失敗したユースケースは、必ずしも不要なものとして無視してよいとは言えないようです。ユースケースとしては考えられないが、システムの機能として重要である場合があるので、慎重に扱う必要があります。
基本ビジネスプロセステストは、第 2 版にも記載されているので理解している方が多いでしょう。以下の基本ビジネスプロセスに定義に適合するものをユースケースとして考えるテスト方法です。
基本ビジネスプロセステストとは・・・ビジネスイベントに反応して、一度に１つの場所で一人の人間によって実行 されるタスクであり、観察可能なビジネスの価値を付加し、データの一貫性を 維持する。 (実践UML 第2版から引用) |
サイズテストは、ユースケースの(テキスト文書の)ステップ数に着目するテスト方法です。ユースケースは多数のステップを含んでおり、完全形式で記述した場合には、3 ページから 10 ページのテキスト文書になるそうです。ユースケースを記述する際に、一つのステップしか含まないような場合は、それはユースケースとしてみなしません。つまり、そのテスト名が示す通り、量の観点から適切なユースケースを判定するテスト方法です。
第 2 版にも記載されていることですが、アプリケーションサーバや、データベース製品、その他のミドルウェア製品といったバックエンドのシステムを作成する場合は、システム機能という観点で要求を捕らえる必要があります。そのため、ユースケースでそのシステムに対する要求を捉えることは、必ずしも適切ではあるとは限りません。
第 3 版では、この内容を一歩進めて具体的な題材をもとに解説しています。その具体例が、第 2 のケーススタディである「モノポリー」です。
では、その要求をどのような成果物で捉えるのかというと、要求の作業分野の成果物として挙げられている補足仕様書がメインになるようです。
今まで私は RUP や UP の繰り返し型開発は、ユースケースドリブンと言われていることから、必ずユースケースで機能要件をとらえて、ユースケース単位で反復計画を立てるということが前提であると考えていました。しかし、補足仕様書でとらえるシステム機能についても反復計画の材料として使われるようですね。
ビジネスルール(ドメインルール)は、長い期間、世の中に存在している規則です。例えば、「価格は、消費税を含んだ総額表示方式とする」といったものが挙げられます。
RUP では、ビジネスルールは、補足仕様書の一部として記述することになっていますが (第 2 版もそうでした)、第 3 版では、ビジネスルールは補足仕様書とは別のドキュメントとして記述することを提案しています。というのは、ビジネスルールは、あるプロジェクトに閉じた規則ではなく、複数のプロジェクト間をまたがって存在し得る規則だからです。ビジネスルールのドキュメントをより再利用しやすくするための一つのテクニックですね。なお、アプリケーション特有のドメインルールについては、補足仕様書に記載するようです。
ユースケースの成果物は、テストケースの作成時やマニュアルの作成時の入力として利用されることはよく書籍に記載されているので理解していましたが、ショートカットの機能を作成するための指針になるという考え方はこの書籍を通じて知りました。ユースケースの基本フローは、頻繁に利用する使い方を表しています。基本フローをもとにショートカット機能を考えることは、ユーザビリティを向上させることに繋がるので、良い指針だと思いました。
Amazon には「1-Click で今すぐ買う」という機能がありますが、その機能は、本観点から生み出されたショートカット機能ではないかなと思いました。
「汎化」と「継承」は、 UML では同じ表記をします。しかし、それらの用語には違いがあります。第 3 版ではその違いが、明確に記述されています。
「汎化」という用語は、使用する視点によって、その意味が、継承と異なったり、継承と同一になったりします。
概念的な視点で考えるドメインモデルのクラス図では、汎化は継承とは異なる意味を持ちます。具体的には、汎化関係で表されたスーパークラスは、超集合 (サブクラスの部分集合を含む集合) を意味し、サブクラスは部分集合を意味することになります。
一方、ソフトウェアの観点で考える設計のクラス図では、汎化関係は、スーパークラスの機能をサブクラスが引き継ぐという「継承」と同じ意味を持ちます。
なお、「汎化」と「継承」の違いに関する説明は、UML の仕様が定められる前に出版された 『オブジェクト指向方法序説 基盤編』 [8] にも記載されています。しかし、この書籍は絶版になっているため、入手が困難です。どうしても読みたい方は、Yahoo! オークションや楽天にときどき出品されているので、定期的にみて Get してはいかがでしょう。また、復刊ドットコムに投票して復刊されるのを待つのもいいですね。今でも一読の価値がある書籍です。
1990 年に出版された Bertrand Meyer 氏の 『オブジェクト指向入門』 [9] の書籍に記載されている「コマンドと問い合わせ」のテクニックが第 3 版になって初めて追加されています。古いものでも、今でも役に立つ考えがあることを示唆する一例ですね。
「コマンド・問い合わせの分離原則」というのは、以下の観点でメソッドを設計するというものです。
重要な点は、コマンドメソッド、問い合わせメソッドの両特性を共に持つメソッドを設計しないということです。必ず、どちらかのカテゴリに入るメソッドとして設計します。それによってそのメソッドを利用する利用者が混乱しなくなるという効果があるそうです。
なお、手続き型言語の場合、コマンドメソッドのことを「プロシージャ」、問い合わせメソッドのことを「ファンクション」と呼ぶそうです。Bertrand Meyer 氏の書籍を読むまでは、恥ずかしながら私自身両用語を区別していませんでした。
UML 2 からステートチャート図がステートマシン図という名前に変わっています。
ステートマシン図は、大きく以下の 2 つケースで利用することができると述べられています。
それぞれのケースに対する具体例が多数挙げられているので、ステートマシン図の使い方に困っている方は内容を確認するだけの価値はありますね。
掲載されている具体例の中で、私にとって価値が最も高かったものは、「画面のナビゲーションをモデル化する」ためにステートマシン図を利用するというものです。今まで、画面遷移は、UML ではなく独自の表記法で書こうとしていたところがあったので、このテクニックを知れたことは非常に有益でした。
RUP のアーキテクチャビューは、以下の 4 つのビューに 1 つの「ユースケースビュー」を合わせた、 「4+1 ビューモデル」として知られています。
第 2 版では、上記ビューに対して「データビュー」を追加したものが紹介されていました。Philippe Kruchten 氏の書籍 『ラショナル統一プロセス入門 第 3 版』 [10] では、今でも 「4+1 ビューモデル」を紹介していますが、RUP 2003 の製品版では、 「データビュー」も合わせた 5+1 ビューモデルが記載されています。従って、第 2 版までの項目は RUP に準じた内容になっていると言えます。
第 3 版では、上記 5 つのアーキテクチャビューにさらに 2 つのビューを追加しています。「セキュリティビュー」と「開発ビュー」です。
Craig Larman 氏が独自に考えたビューなのかどうかは分かりませんが、両ビューとも役立つビューであると思います。Craig Larman 氏は、アーキテクチャドキュメントは、プロジェクトに新しい開発要員が追加された際に参照すべきドキュメントとして位置付けているところがあるので、開発ビューのような観点のドキュメントも重要だと思ったのではないかと推測しています。
アクティビティ図をどのような場合に、また、どのような方法で表記すべきかのガイドラインが記載されています。アクティビティ図は以下の指針のもとに使うのがよいらしいですね。
ユースケースをイベントフローの形式で記述したり、アクティビティ図を用いて記述したりできるのは理解していたのですが、それを使い分ける指針が自分の中で曖昧だったので、1 の指針は特に参考になりました。
『Applying UML and Patterns』の第 1 版から第 3 版までを通して変わることなく最も重要であると言われていることは、オブジェクトに適切な責務を割り当てるスキルを持つことです。オブジェクトに適切な責務が割り当てられいるかどうかを見極めるには、オブジェクト同士がどのように振舞うかを検討することが必要であり、相互作用図を使ってオブジェクト間の振る舞いを十分に検討しなければなりません。
第 3 版では、UML を利用するモデラーは、静的なクラス図によるモデリングのみが重要であると考えがちであり、動的な相互作用図によるモデリングを軽視していることが多いと指摘しています。相互作用図を軽視しかけていた自分に喝を入れてくれる内容です。
また、第 3 版では、責務を重視して設計する RDD (Responsibility-Driven Design:責務駆動設計) と GRASP パターンの関係が簡単に紹介されています。RDD は、Rebecca Wirfs-Brock 氏が考案したもので CRC カードを道具として利用するアジャイル系の設計技法です。CRC カードは、Class, Responsibility and Collaboration の略で、Ward Cunningham 氏と Kent Beck 氏によって考案された 10cm × 15cm 程度のインデックスカード[11]です。
CRC カードを利用した設計手法には、David Bellin 氏と Susan Simone 氏が考案したブレーンストーミングとロールプレイを組み合わせた手法 [12] や Rebecca Wirfs-Brock 氏と Alan McKean 氏が提案している RDD [13] などがありますが、CRC カードの使い方は設計技法毎に異なることに注意してください。ちなみに CRC カードを利用した RDD の設計手法は、また別の機会に紹介したいと思います。
以上、私が参考になったトピックの一部を紹介しました。第 2 版を読んでいる方、これから第 2 版を読もうとしている方の参考になりましたでしょうか。
第 3 版には、その他の有益な情報がたくさん詰まっています。私が気付いたものを簡単に挙げると、以下のトピックがあります。
現在、500 以上を越えるデザインパターンが提案されているそうです。GoF のパターンが登場したときは、23 個でなんとか覚えることが出来ましたが、500 個となると目を通して理解するだけの時間がありません。第 3 版には多数のデザインパターンを理解するためのノウハウが記述されています。
Scott Amber 氏の書籍 『アジャイルモデリング』 [14] を凝縮した内容が掲載されています。
一般的に「繰り返し型開発をしている」と言われているプロジェクトでも、実際に中身を見てみるとウォータフォールの考え方で開発を進めているプロジェクトが多いのでしょう。
第 3 版では、外面 「繰り返し型」、内面 「ウォータフォール型」という考え方をしていることに気付いていない方に、どの点で誤解しているのかを指摘してくれるようなエッセンスが詰まっています。
クラス抽出に利用できる概念のカテゴリリストや、関連を引くときの目安になる関連のカテゴリリストが洗練されています。より適切なクラスを抽出しやすくなったのではないかと思います。
「オブジェクトの広場編集員が贈る勘違い集」で取り上げている「クラス名の上部につける ≪interface≫ はステレオタイプだと思っていた。」の勘違いと同じ誤りをしていたみたいです。
Craig Larman 氏、「 shocking surprise! 」と言ってます。
いかがだったでしょうか？
原書第 3 版は、その他のトピックで取り上げた内容以外にも、UML の各ダイアグラムがそれぞれ 1 つの章として書き直されていたり、UML とソースコードのマッピングが盛り込まれていたり、Struts を利用したソフトウェアアーキテクチャドキュメントの具体的なサンプルが掲載されていたりと、全体の内容、構成を読者が理解しやすいように Craig Larman 氏が丁寧に見直したということがうかがえるような書籍になっています。また、この書籍は、エンジニアなら一度は目を通しておくべきという有名な参考文献を多数掲載しているので、本書籍をベースに他の文献に目を通していくという読み方をしても、とても勉強になると思います。今まで読んだ要所の中でも、本書籍はわかりやすい英語で記載されている方だと思うので、皆さんも是非、これを機に原書を読んでみてはいかがでしょうか？
| © 2005 OGIS-RI Co., Ltd. |
|
