ObectSquare

[アナリシスパターンを読もう]


アナリシスパターンを読もう

written by

Japan PLoP代表 友野晶夫

INDEX
1. なにするものぞ
2. 読み下しのポイント
2.1. 動的分類、多重分類、完全区画、不完全区画
2.2. 知識レベル−操作レベルと制約
2.3. 問題領域横断的なパターン
2.4. アナリシスパターンの表現形式
3. まとめ

アナリシスパターン。さまざまなところで「難解」、「難読」、「現場と無関係」とさまざまな憶測を呼んでいるようですね。でも、ツボにはまればわりと簡単に読めるし、非常に有用であることもわかってもらえると思っています。なにせ、私は、これなしで生きていけない体になってしまいました。まあ、肩の力を抜いてお話に付き合ってください。「なーんだ、簡単」と思っていただければ幸いです。


 

1.なにするものぞ

まず、この先の話を読んでもらえるように、何の役に立つかから説明しましょう。アナリシスパターンの最大の御利益。まず、これを最大限に感じてもらうために、少し遠回りですが、要求獲得から設計初期に行われることについて少し触れます。

最初のかぎは、要求獲得にあります。要求獲得といえばユースケースですね。さて、ユースケースは、システムが達成すべき目標を「変化」の視点で表します。そこでは、「目的」として、現状のシステムを「どのような」システムにするかという「変換」が記述され、そして、「対話」としてその「変換」を実現するための「逐次的」な小目的が記述されます。こうして、「変化」により「プロジェクト」が満たすべきことが明確に記述されます。「変化」をもたらすための「プロジェクト」を「変化」によって表現するというのは、なんと直截的でわかりやすく、適切な方法だろうと感心します(JacobsonおよびChecklandに感謝)。

一方で、要求の背景には「プロジェクト」により「変化しない」ことがらがあります。そうしたことを記述するのに、ユースケースは、自然言語として以上の力を持ちません。そもそも、ユースケースにおいて「変化」を記述するのには、そうした「変化しない」語彙が不可欠です。こうしたことがらを記述するのに向いているのは、そう、クラス図です。一般にクラス図というと、オブジェクト指向プログラミングをする上での仕様書として書かれる、クラスの操作や属性が定義されているものを想起してしまいますね。そこで、アナリシスパターンでは、概念構造の表現であることを強調するために、「型モデル」であるとしています。

「型モデル」は、実装されるクラスの仕様書ではなく、「型」というインスタンスの集合がなす構造を表現するためのものです。そのため、属性や操作を完備にすることは考えません。これを書く上では、ともかく「概念構造の理解」に専念します。純粋に「概念構造の理解」のために書かれるモデルを概念モデルと呼びます。
こうして要求は、「変化」と「概念構造」によって押さえられます。これらは、どちらが先というものではなく、対象とするシステムにより重心が変わるだけの、2つの補完しあうモデルでしょう。

さて、これら2つ、ユースケースと概念モデルは、いずれ交わります。その交点は「責任」です。ユースケースを満たすために必要とされる「責任」が概念モデルの要素に割り振られます。この過程で重要な概念が抜け落ちていることに気づくこともあります。また、どの「型」に担わせるべきかが微妙な「責任」もあります。Fowlerは、これらの検討を加えた結果として得られるものを暗示的仕様モデルと呼んでいます。これは、クラス図のように操作や属性をすべて明示するまでに至っていないが、「責任」や関連および属性により操作が暗示されるモデルを指します。暗示的仕様モデルは、やはり「理解」のモデルでもあるため、概念モデルとしてみることもできます。

さて、前置きが長くなりました。アナリシスパターンは、上記のモデリングで有用なパターンです。

直接的には、「ある(複数の)ユースケースの元で繰り返し現れる概念モデル」を提示してくれます。Fowlerが提示している概念モデルは、ほぼそのままで暗示的仕様モデルにも使えるものになっています。この点が彼の強調するところの「有用性」でしょう。
逆の使い方もあります。アナリシスパターンにはユースケースが隠然と提示されていますので、ある概念モデルが獲得されたときに、ありうるユースケースを考察するのにも役立ちます。
しかも、Fowlerは、ユースケースが変化する過程から、概念モデルを柔軟なものにまで昇華してくれています。
このパターンを知っておくことで、要求から設計への移行という、システムエンジニアの行う作業でもとりわけ「華」の部分が補強されます。
おや、「ミドルウェアには不要」とか「パッケージをベースにした開発では関係ないのでは」といった声が聞こえてきました。そうでしょうか。
「要求」のないシステム開発はありえません。ソフトウェア構築ツールであれば、システム開発者がユーザであるはずです。パッケージソフトの機能に完全に満足する顧客ばかりであれば、パッケージソフトを販売している多くのソフトウェア企業が行っているような「開発」は不要なはずです。特に、パッケージソフトを抱える場合には、その限界を知るためにもアナリシスパターンは有効に機能すると思いますよ。


 

2.読み下しのポイント

アナリシスパターンを読み解く上でつまずきやすい概念、技法について解説しておきましょう。


 

2.1. 動的分類、多重分類、完全区画、不完全区画

動的分類(dynamic classification)、多重分類(multiple classification)、完全区画(complete partition)、不完全区画(incomplete partition)は、いずれも継承の弁別子にかかる制約およびステレオタイプです。

UMLで表記する場合は次のようにします。これには顧客の分類を例として使いました。

図2-11.顧客の分類

このモデルは、顧客は個人顧客または法人顧客のいずれかであり(完全区画)、かつ重要顧客である顧客とそうでない顧客がある(不完全区画)ことを示しています。また、個人顧客か法人顧客かの弁別子と重要顧客かどうかの弁別子を分けることで、個人顧客でかつ重要顧客、法人顧客でかつ重要顧客、単なる個人顧客、単なる法人顧客という顧客の多様性があることを表現しています(多重分類)。さらに、顧客は重要顧客となったり単なる顧客となったりする(動的分類)ことも示しています。

このように、これらの分類方法は、単なる継承では表現し切れなかった構造を簡潔に表現するのに役立ちます。
もちろん、こんなことを表現できる言語系は、今のところありません。しかし、「どういったものを作らなければならないか」ということを示してくれますので、いかなる言語系を使うにしても、設計のインプットとしては十分です。


 

2.2.知識レベル−操作レベルと制約

「一般化」といえば、汎化が想起されるかと思います。汎化以外の抽象化の方法として、型を知識レベル操作レベルに分離する方法があります。知識レベルは操作レベルのメタモデルに対応します。したがって、知識レベルのインスタンスは、操作レベルの型に対応します。たとえば、組織や人を抽象化したパーティ(party)という型がアナリシスパターンに出てきます。パーティのインスタンスである事業部、地域、部門、営業所などの型間の関係は、責任関係(accountability)パターンにより分類して、定義されます。

型モデルに知識レベルを持ち込む必要が生じる場合を述べておきましょう。第一に、分類の多様性が増減する可能性がある場合です。たとえば、企業において事業部、地域、部門、営業所といった組織の種類が増減する場合も、パーティ型という知識レベルの型があれば、組織の種類の増減はそのインスタンスを生成消滅させるだけで対応できます。第二に、型間の制約が変化する可能性がある場合です。知識レベルのインスタンスで操作レベルのインスタンスへの制約を定義できます。これについては後に詳しく示します。
知識レベルをモデルに持ちこむ意義はソフトウェアの進化と関係があります。ユーザは必然的にソフトウェアのカスタマイズを要求するようになるからです。変化をパターン化し、共通点を知識レベルとしておくことは、将来のこうした変化に対応できるモデルを作成することにもつながります。

知識レベルと操作レベルについて、責任関係パターンを基に例を示します。 ある企業の組織構造が、事業部−地域−部門−営業所という階層構造からなっているとしましょう。知識レベルを使わずにこの組織構造を表現したものが図2-12です。

図2-12.知識レベルを用いない組織構造

このモデルは、組織構造を表現する際に、最も一般的に使われるものです。事業部、地域、部門、営業所の重複部分の記述を省略でき、また、組織階層が増減した場合も、組織のサブタイプを増減させるだけで済むためです。
しかし、このモデルは「事業部−地域−部門−営業所という階層構造」という制約を表していません。図2-12の型にこの制約を付加したモデルを図2-13に示します。図2-13に示したモデルは組織構造が変化するたびに各型の制約が影響を受けます。そのため、制約まで考慮に入れると図2-12はあまり柔軟でないことがわかるでしょう。

図2-13.制約表現を施した知識レベルを用いない組織構造

責任関係パターンの記述において、Fowlerは制約も含めてこうした組織構造を表すモデルを安定化するように試みています。Fowlerはこの試行の過程でさらに適用範囲を広げるようにも努力し、組織を一般化してパーティとし、組織構造を一般化して責任関係としています。 知識レベルを導入することで安定化を図った型モデルを図2-14に示します。

図2-14.知識レベルを用いた責任関係

操作レベルのパーティの委任者(commissioner)と責任者(responsible)は、知識レベルにある責任関係型の委任者(commissioners)および責任者(responsibles)が許容する委任者および責任者でなければなりません。責任関係型に記された制約は、パーティ型が増減しても不変であり、組織構造の変更はパーティ型や責任関係型のインスタンスの増減およびそれらの間のリンクを変更することで対応できます。このモデルを用いた際の「事業部−地域−部門−営業所という階層構造」のインスタンスモデルを、図2-15に示します。

図2-15.事業部−地域−部門−営業所という階層構造

ところで、このように、ある状況にあわせたインスタンスモデルを記述することは、アナリシスパターンのように高度に抽象化されたモデルを理解する上での近道であると同時に、概念構造に関する顧客とのやり取りを行う上でも重要です。抽象的な型モデルでは、顧客の目には単なるPostItとしてしか映らないかもしれませんが、インスタンスモデルで提示することで顧客から意見をひきだすことができます。

図2-15に示すインスタンスモデルによって表現される制約に適合した「電気通信事業部の関東地域のオーディオ部門とビジュアル部門」という組織構造を表すインスタンスモデルを図2-16に示します。

図2-16.適合するシナリオのインスタンスモデル


 

2.3.問題領域横断的なパターン

パターンを複数の問題領域で利用することで抽象度は上がり、さらに広範囲な適用が期待できるようになります。Fowlerは、医療を対象としたモデリングで獲得した観測パターンを企業の財務分析に適用したり、会計で獲得された勘定パターンを在庫や電話会社の通話記録に適用することで、パターンがより広範囲に適用可能となることを示しています。ただし、実際のシステム構築で意識しなければパターンを真に使いやすいものに抽象化することはできないとも警告しています。これは一般にモデルを抽象化する上での重要な指針です。有用なモデルを作るという動機づけがなくては、抽象化されたモデルが有用かどうかの判断を下せないためです。抽象化しすぎた場合、そのモデルを使う意義が失われてしまうことすらあります。この辺の議論は、やはりFowlerの「Refactoring」に詳しく出てきます(もうすぐ邦訳ができますので乞ご期待)。

またFowlerは、「問題領域をまたいでパターンを用いることでプロセスモデルが共有される」とも述べています。これは、同一のパターンが適用される問題領域におけるユースケースの類似性を示しています。したがって、新たな問題領域に既存のパターンを流用した際には、既存のパターンが対応していたユースケースが、新たな問題領域でユースケースを洗い出すヒントとなります。たとえば、勘定パターンは物流に対しても適用できることから、物流には会計領域の各ユースケースに対応するユースケースがあると推測されます。たとえば、会計における転記や勘定の要約といったユースケースから、物流においても同様のユースケースがあるということです。これは、出荷の際に用いられる梱包材の管理は、出荷から転記すればよいし、全倉庫の在庫集計は各倉庫の在庫を要約すればよいといった具合です。


 

2.4.アナリシスパターンの表現形式

パターンの表現に広く適用されている文脈−問題−制約−解決からなるパターンテンプレートで整理してあれば、カタログとして利用しやすくパターン同士の比較も容易です。しかし、Fowlerのパターンは、そうしたパターンテンプレートに則っていません。これは、次の3つの理由からと考えられます。

  1. パターンが対象とするユースケースの範囲を広げると、それに応じてパターンの構造が複雑となるが、これはパターンの使いやすさとのトレードオフである。
  2. 文脈の選択が複雑になることから、単純な形式的表現よりもモデリングの過程をそのまま記述する形式の方が好ましい。
  3. Fowlerのパターンはパターンが導き出される過程であり、モデリングやパターンライティングに援用できる。

 

3. まとめ

いかがですか。アナリシスパターンについて、思い切ってかいつまんでお話してみました。その有効性に関していろいろと疑問を持たれる部分もあるかと思います。特に今のところ、概念モデルみたいなものはあまりプロジェクトで書かれることはないようです。しかし、私がモデラーとして参加したいくつかのプロジェクトでは、ユースケースと概念モデル(かなり厳しい制約を課してはいますが)だけで外注先への仕様とし、それで満足のいく結果を得ています。私は、この2つによって、「何を実現すればよいか」が明確に示せると確信しました。もちろん、構築するシステムの性格によっては、さらに仕様を精緻なものとする必要があります(特に、機能性以外の特性についての要求が厳しい場合)。その場合にしても、一旦はこれらを確立する必要があるでしょう。
是非、アナリシスパターンおよび概念モデルに興味をもっていただけることを期待します。これは、ソフトウェアエンジニアたる私たちの間のコミュニケーションギャップを埋めてくれることでしょう。そしていつの日か、他の領域のエンジニアたちのように、私たちがすらすらと要求や問題、そして設計について語り合えることを祈っています。


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

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