［レポート］
オブジェクトテクノロジ・ソリューション部
畑 伸樹
Hata_Nobuki@ogis-ri.co.jp
さる 8 月 20 日にオブジェクト指向シンポジウムに参加しました。
私は企画セッション「パターン」の 1 日目に参加しました。
1995 年に発表された GoF の「デザインパターン」により、パターンはソフトウェア業界でブームとなりました。
しかし、現場での活用は当初の期待ほどには進んでいません。
GoF のデザインパターンはよく知られるようになりましたが、ソフトウェア開発でパターンがよく活用されているというレベルには至っていません。
例えば、設計においてデザインパターンを適用することはよくあるでしょうが、要求分析や分析などの作業でパターンを使うということはあまり行われていないと思います。
パターンという概念は元々、建築家の C. アレクサンダーによって考え出されたものです。このセッションは、建築でのパターンの使い方をパターンの原点として学び、ソフトウェア業界でのパターンの活用法をもう一度考えてみようというものです。
建築でのパターンの使い方は建築家の中埜博さんが説明してくれました。中埜さんはアメリカに留学して C. アレクサンダーに学んだ建築家です。お仕事としては個人の家を設計することを主にやっておられるそうです。
セッションは、まず中埜さんが「要求獲得と合意形成のためのパターンランゲージ入門」というチュートリアルを行ない、その後中埜さんも交えて「ソフトウェア開発はパターンランゲージから何が学べるか」というパネル討論を行う形で進められました。
C. アレクサンダーは良い建築設計の型をパターンとして収集しました。
例えばアルコーブというパターンがあります。
アルコーブでは真中に人が集まる場所があり、そこから離れられる場所が設けられています。人とずっといっしょにいるのは疲れるけど、人の集まりを見ていて、関心があれば参加したいというような人間の要求（問題）に対して、このパターンは解を与えています。
また、パターンにはあるパターンを使えば、この別のパターンを使うことも検討するといい、というような関連するパターンがあります。
このように、アレクサンダーのパターンでは多くのパターンが関連しあって、パターン体系（パターンランゲージ）を形成しています。
中埜さんは建築設計をする際に、パターンを以下のように適用して作業を進めていくと説明していました。
１． 顧客の建築への要求をヒアリングする。
２． パターンを使って建築設計として再構築する。
３． 顧客に建築設計案を提示しフィードバックを得る。（ユーザはパターンの存在を意識しない）
つまり、アレクサンダーのパターンは顧客の（高次で曖昧な）要求を具体的な建築の仕様に落とし込む時に使われているということです。
この他、中埜さんからは建築業界ではソフトウェア業界のようにパターンが広く認識されていないので、ソフトウェア業界から影響を与えてもらって、建築業界での認識を広げていきたいというお話もありました。
建築では顧客の要求から、具体的な建築の外部仕様を作っていく際にパターンが活用されています。
建築ではこの作業も「設計」と呼ばれているようですが、ソフトウェアではこの作業は「要求分析」、「要件定義」などと呼ばれ、「設計（内部設計）」と明示的に分離されて捉えられています。
建築と同じように要求分析、要件定義でパターンを使うことを考えると、以下のようなことが思いつきます。
- ユースケース作成の際にパターンを使う。
例えば、組込みのユースケースでは以下のようなパターンが考えられます。
通常機能ユースケース、保守機能ユースケース、初期化機能ユースケース、終了処理ユースケース、システム検査機能ユースケース、デバッグ用機能ユースケースなど。
- オブジェクト指向分析の際にパターンを使う。
近年のソフトウェア工学の成果を紹介しているシャリ・ローレンス・プーリガーの「ソフトウェア工学」には、オブジェクト指向分析が要件定義技法の１つとして紹介されています。
オブジェクト指向分析は設計の前段という面の他に、顧客の世界観を正しく把握するという要求分析、要件定義の面があります。
オブジェクト指向分析で使うパターンとしてはマーチン・ファウラーの「アナリシスパターン」があります。
この他にも分析で、よく使われる構造に名前をつけてパターンにすることが考えられます。継承といったUMLに用意されている構造から、自己参照のようなものまで、パターンとして記述しておけば覚書として役に立ちそうです。
パネルセッションでも「パターンの新たな活用法として、まずは建築と同じように要求分析でパターンを使ってみてはどうだろうか」という意見が出ていました。
このセッションに参加して、
「ノウハウを残しておく形としてパターンという形は良い」ということと、「完成度は高くなくても良いので、ノウハウをパターンとして残すべき」ということを感じました。
以下のようなことが理由です。結局、パターンは問題と解を抽象化して記述している、というのが良い所だと思います。
パターンを実際に活用する具体的な取組みとしては、以下のようなことが考えられます。
- 類似の開発で再利用できる。
- パターンとしてカタログ化しておけば道具箱のように使える。
- ノウハウをパターンにすることで、問題と解のエッセンスを捉えなおすことができる。
- 問題と解のエッセンスのみが記述されるので、チームのメンバなどと検討しやすい。
- 基本的、普遍的な技法をパターンとして棚卸しする。
- プロジェクトの成果物をパターンとして残しておいて、類似プロジェクトで使う。また、考察を深める。
オブジェクト指向分析で使う基本的な技法や定石をパターンとして捉えなおすのは前者の例です。
後者の例は、プロジェクトで適用した設計をパターンとして記述してみることです。 GoF のパターンやアナリシスパターンのように洗練されたものを作るのは難しいと思いますが、それほど完成度が高くなくてもノウハウを残し再利用するということでは非常に効果的です。アーキテクチャドキュメントなどで残しておくのでも良いと思いますが、パターンにすることで、ノウハウの再利用がしやすくなると思います。
ただし、パターンを洗練したり、完成度を上るのには労力がかかりますので、ノウハウを残しておくことを主目的にして、まずは手早くまとめておくというのがパターンを活用していくポイントだと思います。
ソフトウェア工学―理論と実践
シャリ・ローレンス・プリーガー著、ピアソンエデュケーション刊、ISBN：4894713683
アナリシスパターン―再利用可能なオブジェクトモデル
マーチン・ファウラー著、ピアソンエデュケーション刊、ISBN：4894716933
| © 2003 OGIS-RI Co., Ltd. |
|
