"Documenting Frameworks using Patterns" 紹介

Ralph E. Johnson, Documenting Frameworks using Patterns OOPSLA ’92 2006 年 1 月 26 日発表者 : 佐藤匡剛 [email_address]

要旨フレームワークの文書は、以下の 3 つを記述する必要があるフレームワークの目的フレームワークの使い方フレームワークの設計の詳細一組のパターン（ a set of patterns ）として記述することで、文書は上記要件をすべて満たせる HotDraw を例に、文書化の方法を示す

－　論文の構成　－はじめにパターンの書式フレームワークの文書化とは具体例の役割についてパターンによる HotDraw の文書化文書化作業を振り返る結論付録 HotDraw の文書化

はじめにパターン言語とは建築家C. Alexanderが考案　（ 70 年代）人々が家やコミュニティを設計するためのものパターン言語 = 一組のパターンパターン = ある特定の問題への解法を記述したもの Alexanderのパターン言語は、一般人（非建築家）のための文書日常的な設計問題に焦点をおくコンサートホールや教会ではなく、寝室や住宅の建て方

本論文では、パターン言語を単に「パターン（ patterns ）」と言い換えるなぜなら ... パターンは、いわゆる形式的言語ではないたんに構造化されたエッセイのようなもの

フレームワーク＝「一組のクラスで表された、再利用可能なプログラムの設計」抽象度が高いので、文書化が難しい専門家が設計して、一般プログラマが使うものフレームワークの文書化には、パターンが有効主な読者は、専門家でなく一般プログラマ想定読者がAlexanderのパターン言語と同じ本論文では、パターンを使ってフレームワークを文書化する一手法を示す

1. パターンの書式パターンの重要な特徴統一された書式パターンが別のパターンを導出する構成パターンの書式問題の記述様々な解法についての詳細な議論（+ 具体例）解法のサマリ解法を補完する別のパターンへの参照

パターンの具体例～描画ツールフレームワーク HotDraw のパターン～パターン 4 ：　 Complex Figures 　図形には、視覚表現とともに内部構造をもつものがある。例えば、別の図形として表示されるような属性をもつものなどだ。こうした図形を、単純な図形の組み合わせで作成できるようにしたい。　 PERT イベントのような複雑な図形は、より単純な図形から構成されていると考えられる。例えば、 PERT イベントは長方形に、タイトル、期間、終了日の文字図形が組み合わせられたものだ。 PERT イベントのような複雑な図形（ complex figures ）は、 CompositeFigure のサブクラスとする。（つづく）

CompositeFigure は、他の図形を構成要素としてもつような図形で、それらを描画することで、自身を描画する。この図形は、構成要素の境界領域とは独立に自らの境界領域をもち、その中に含まれる構成要素だけを描画する。選択ツールとテキストツールによって構成要素を操作するには、左の Shift キーを押す。必要ならば、構成要素を直接操作する独自ツールを作ってもよい。 ... （以降省略）　複雑な図形は CompositeFigure のサブクラスとし、その一側面を表示する図形をその構成要素とする。　構成要素間に制約条件を課したいときは、 Constraints (5) を参照せよ。

パターンは「問題指向（ problem-oriented ）」である解法指向（ solution-oriented ）ではない各パターンは、大きな設計問題の一部分を解いていく解法はさまざま: サブクラスを作る　（パターン 2 ）既存のオブジェクトをパラメータ化する　（パターン 10 ）いくつかのオブジェクトを連携させる　（パターン 3 ）

2. フレームワークの文書化とはフレームワーク文書化の 3 つの目的 : フレームワークの目的を記述フレームワークの使い方を記述フレームワークの内部設計を記述パターンで文書化すれば、この要件を満たせる（⇒ 付録「 HotDraw の文書化」を先に見てください）

2.1 目的の記述フレームワークの目的＝どの問題領域を設計したものか文書で一番最初に説明されるべきこと読者が探しているものかどうか、がすぐ分かるなるべく短くなければならない誰もが簡単に読めるパターン文書では、第一パターンがフレームワーク全体の動機を扱う目的が最初に簡潔に示される加えて、後続パターンへのロードマップも示す

2.2 使い方の記述実際に使ってみるまで、フレームワークなんか理解できない多くの文書は、内部設計のことを先に書きたがる読者が本当に求めているのは、料理本（ cookbook ）中には、料理本から始めている文書もある MacApp 、 Smalltalk-80 の MVC パターン文書は基本的に上記 2 つと似ているが次の 2 点が優れている : 構造化されている本当の料理本のように、料理が完成するまでを説明する

2.3 内部設計の記述良いフレームワークとは、設計者が予想もしない使い方をされるもの料理本だけでは、典型的な使い方しか示せないすべての使い方を示すには、内部設計の説明が必要パターンには、内部設計を説明する余地がある解法の詳細について議論するセクションパターン全体のどこで説明をすべきか？パターン構造を有向グラフと捉える第一パターンからできるだけ遠くで説明する説明の重複を排除

3. 具体例の役割について具体例は、文書の中で重要な役割を果たすフレームワークを具体化し、理解を助けるパターンでも、ふんだんに具体例が使われる使い方や内部設計の例ではなく、フレームワークが何に使えるかを示す例 ex)　UIフレームワーク　⇒　UIの例　コンパイラフレームワーク　⇒　コンパイラの例後続のパターンへの動機付けにもなるパターンの練習にも使える実例（実際のアプリケーション）も示す

具体例を重視する他のアプローチ Jacobson のユースケース Wirfs-Brock らの徒歩検査（ walk-through ） ★ つまり、具体例は抽象的な議論より理解しやすいということ

4. パターンによる HotDraw の文書化 HotDraw 意味論的描画エディタのフレームワーク作者は、 Tektronix 社の K. Beck & W. Cunningham HotDraw を選んだ理由描画エディタのフレームワークは他にもある Unidraw 、 DRAW_Master 、 GUI_Master 他に比べて作りがシンプルだから実際の文書は、付録を参照

5. 文書化作業を振り返るパターン文書完成までの経緯 OOPSLA’91 で K. Beck に会ったのがきっかけその後、大学院生に最初の文書を見せたが役に立たなかったパターンは、まだ具体例も内部設計も含まれない単なる文章 Alexander のパターン言語を読み直して、具体例と内部設計の必要性を認識し、文書に盛り込んだパターンの構造が出来上がったが、不完全（説明不足／重複） Smalltalk プログラマに見せて、フィードバックを得た HotDraw の文書としては十分と言われたので、ここで完成！これ以上の改善には、管理された実験下でのフィードバックが必要　　（非形式的な実験方法では、ここまでで限界）

パターン文書執筆の際のポイント書式が決まれば、パターンの記述は難しくない難しいのは、フレームワークがどういった使われ方をするか、について精通しなくてはならないこと有向グラフの構造は、具体例や内部設計を適切な場所に配分するのに役立つパターン文書を書くと、ユーザの視点を分析する必要があるので、それ自体が設計のよい訓練となるその他のトピックパターン文書は、ハイパーテキストと親和性が高い

結論パターンはフレームワーク文書化に有効である初めての読者には、フレームワークの目的を端的に示せる一般の読者には、フレームワークの基本的な使い方を示せる意欲のある読者には、内部設計まで説明できる今後の課題パターン以外の文書化の方法との比較大規模なフレームワークへも適用可能かどうか

付録 : HotDraw の文書化（論文図3より）

パターン 1: Semantic Graphic Editors 　 HotDraw は構造化された描画エディタのためのフレークワークである。回路図や見取り図、楽譜、プログラム設計図といった、専門的な二次元の図を描くためのエディタを構築するのに使うことができる。図の要素間には制約をつけることができ、ユーザのコマンドに応答することができる。また、アニメーションを走らせることもできる。エディタは一個のアプリケーションでもよいし、大きなシステムに組み込むこともできる。　 [... 詳細な説明 ...] 　 HotDraw を使って描画エディタを設計するには、まず図を構成する最小要素を列挙せよ。各要素は、 Figure のサブクラスとなる。図がアニメーションをする必要があるかを決めよ。パレットに載せるツールを列挙し、 DrawingEditor のサブクラスに tools メソッドを定義せよ。 tools メソッドは、パレットを構成するツールの配列を返すようにする。　 Figure のサブクラスを作るには、 Defining drawing elements (2) を見よ。図をアニメーションさせるには、 Animating drawings (9) を見よ。描画エディタを大きなツールに組み込むには、 Embedding a drawing in another tool (7) を見よ。ツールをパレットに載せるには、 Tools (8) を見よ。

パターン 2: Defining Drawing Elements 　図に含められる基本図形には、無限の種類が考えられる。そのため、アプリケーションごとに新しい図形を作成できる仕組みが必要である。　 [... 詳細な説明 ...] 　 HotDraw アプリケーションの描画要素はすべて Figure のサブクラスであり、 displayOn: 、 origin 、 extent 、 translateBy: を実装しなければならない。そのほか、 Figure のサブクラスはアプリケーションの必要に応じて好きなメソッドを実装できる。　 displayOn: を記述するには、 [ParcPlace 90] を見よ。ユーザが図形のサイズや色を変更できるようにするには、 Changing drawing element attributes (3) を見よ。 PERT イベントのような複雑な図形の実装方法を知るには、 Complex Figures (4) を見よ。異なる図形間に制約条件を課すには、 Constraints (5) を見よ。

パターン 3: Changing drawing element attributes 　図形の属性を編集するには、少なくとも 3 つの方法がある。ハンドルによる方法、ポップアップメニューによる方法、特定のツールによる方法である。どの方法が適切かは、ケースに応じて変わる。　 [... 詳細な説明 ...] 　編集したい描画要素の属性を列挙せよ。各属性について、ハンドル、メニュー、ツールのどれを使って編集するかを決めよ。そして、 handles メソッド、 menu メソッド、または描画エディタのツール一覧を更新せよ。　新しい種類のハンドルを作るには、 Handles (6) を見よ。新しい種類のツールを作るには、 Tools (8) を見よ。

パターン4: Complex Figures 　図形には、視覚表現とともに内部構造をもつものがある。例えば、別の図形として表示されるような属性をもつものなどだ。こうした図形を、単純な図形の組み合わせで作成できるようにしたい。　 [... 詳細な説明 ...] 　複雑な図形は CompositeFigure のサブクラスとし、その一側面を表示する図形をその構成要素とする。　構成要素間に制約条件を課したいときは、 Constraints (5) を参照せよ。

パターン5: Constraints 　ある図形の属性が、別の図形の属性に作用することがある。たとえば、図 1 （論文）の PERT チャートエディタの中で、イベントの開始日は、それに先行する（つまり接続している）全イベントの終了日の最大値として与えられる。別の例では、イベント間を繋ぐ線の終端点は、そのイベントの位置に依存する。ハンドルも、それが取り付けられている図形に依存している。　 [... 詳細な説明 ...] 　描画の中にある制約は、すべて制約オブジェクトとして表現する。　図形間に線を繋いだときに自動的に制約が付与されるようにするには、 Adding Lines (10) を見よ。

パターン 6: Making new kinds of handles 　ハンドルによって振舞は変わる。図形のサイズを変更するハンドルもあれば、色を変更するハンドルもあるし、新しい線を生成するハンドルもある。一般的に、あらゆる操作をハンドルを使って実行することができるだろう。さらに、ハンドルは図形の好きな部分に取り付けることができ、図形が動くと一緒に動く。こうしたことから、ハンドルはなんらかの形でパラメータ化されなくてはならない。　 [... 詳細な説明 ...] 　ドラッグによってひとつの図形の一面だけを変更するハンドラは、 TrackHandle インスタンスとする。ドラッグによって複数選択された図形の一面を変更するハンドラは、 SelectionTrackHandle インスタンスとする。ある図形から別の図形へ伸びる線を生成するハンドラは、 ConnectionHandle インスタンスとする。それ以外の機能を実現するハンドルを作るには、 Handle のサブクラスを作成する。　 ConnectionHandle を生成するには、 Adding lines (10) を見よ。

パターン 7: Embedding a drawing in another program 　テキスト窓やボタン、リストなどを含んだ複雑なユーザインタフェースの中に、描画が組み込まれることがある。 HotDraw は Smalltalk-80 の MVC フレームワークの上に構築されており、複雑なアプリケーションの中に組み込めるようになっていなくてはならない。　 [... 詳細な説明 ...] 　複雑なアプリケーションの描画部分を構築するには、 DrawingView をアプリケーションビューの部分ビューとし、 DrawingView に対しては、 DrawingEditor のプロトコルに応答するモデルを渡せ。 DrawingEditor のプロトコルとは、 currentTool 、 menu 、 drawing 、 drawing: メソッドを実装することをさす。

パターン8: Tools 　ツールとは、描画に対するユーザインタフェースのモードのことを表す。パレットからツールを選ぶことで、ユーザは図形を操作したり、新しい図形を作ったり、一図形や全体に対してなんらかの操作を実行したりできる。パレットにどういったツールのセットを載せるかを設計するのが、 HotDraw ベースのエディタを設計する際の重要な仕事のひとつである。　 [... 詳細な説明 ...] 　 DrawingEditor の tools メソッドがパレットに載せるツールを定義する。このメソッドは、順序付けられたツールのコレクションを返す。ツールは、 Tool のサブクラスのインスタンスである。

パターン9: Animating drawings 　制約、ハンドル、ツールでは、描画をユーザに対して反応させることができるが、描画そのものに生命を与えることはできない。アニメーションを行なうには、描画内のすべての図形を指揮する制御オブジェクトが必要になる。　 [... 詳細な説明 ...] 　描画にアニメーションを行なわせるには、描画を表すサブクラスに step メソッドを定義せよ。このメソッドは、アニメーションの次のステップを実行するものである。

パターン10: Adding lines 　図形を接続するときに、よく線が使われる。こうした接続には、たとえば他のアクションの副産物として生成された線など、なんのセマンティクスももたないものもある。この場合は、線を削除したり移動させたりしても、他の図形に影響を与えることはない。その一方で、線を加える結果として新たな制約が発生したり、新たな図形が生成されることもある。　 [... 詳細な説明 ...] 　線を生成して図形を接続するには、ユーザは一方の図形の ConnectionHandle を押さえるようにする。 ConnectionHandle をパラメータ化することで、 2 つの図形を繋いだときに他のアクションも実行させられるようにする。こうすることで、制約を付加したり、接続が許されるかをテストしたりできるようになる。

感想現在の「 GoF デザインパターン」とは異なるボキャブラリ化が目的ではないパターンに普遍性がない Alexander のパターン言語に近い論文は、パターンの書式を使ってフレームワークを文書化する試みに読める目的は、フレームワークを文書化することパターンカタログ／言語の記述が目的ではない

関連研究との違いを考察して欲しかったたとえば ... Clements らの「 module guide 」 P. Clements, D. Parnas & D. Weiss, “The Modular Structure of Complex Systems.” IEEE Trans. in Software Engineering , SE-11(3): 259-266, 1985. 情報隠蔽の原理によって、ソフトウェアを文書化する試み [ 私見 ] 　 module guide はモジュール（＝計算単位）の視点からソフトウェアを分割（ decompose ）するが、本論文は問題に基づいてソフトウェアを分割する。

ソフトウェアアーキテクチャ文書化の研究では、以下の3つの視点が取られることが多いモジュール（ module ）実行時の振舞（ component and connector ）配置（ allocation ）本論文は、「問題」の視点からソフトウェアを文書化している点に独自性がある M. Jacksonの「問題フレーム」は関連研究か？

参考論文 K. Beck & R. Johnson, Patterns Generate Architectures , ECOOP’94 デザインパターンからアーキテクチャを創出する試みトップダウン式の本論文に対する、ボトムアップのアプローチ同じ HotDraw を題材にしている

"Documenting Frameworks using Patterns" 紹介

More Related Content

Similar to "Documenting Frameworks using Patterns" 紹介 (20)

More from Tadayoshi Sato (7)

"Documenting Frameworks using Patterns" 紹介