第 7 章 INTER-Mediator の適用範囲と評価 95
4.8 マスターテーブルから取り出した関連レコードを表示する
1 【変更前】
2 < td data−im="asseteffect@category"></ td >
3 【変更後】
4 <td >
5 <span data−im−c o n t r o l ="enclosure">
6 <span data−im−c o n t r o l ="repeater" data−im="category-in-list@name"></span>
7 </span>
8 </ td >
一般的なフレームワークでは，このような変更が生じた場合，スキーマレベルでのビューの作成や，あ るいはモデルの応答を変更するといった作業が必要になる．INTER-Mediatorでは宣言的な記述で，リレー ションシップの追加を伴う改変も可能である．
4.7 関連研究
ISO/IEC 25010に規定された「システム／ソフトウェア製品の標準品質モデル」の中に「保守性」という
カテゴリがあり，さらにその中で「モジュール性」「再利用性」「解析性」「変更性」「試験性」といった項 目が挙げられている[122]．INTER-Mediatorの機能と本章での検証をこれらの項目に照らした結果を表4.2 にまとめた，モジュール性や再利用性はHTMLの記述の特性に概ね一致するため，テキストそのものの活 用という意味ではあると言える．また，定義ファイルの1つのコンテキスト定義は，1つのモジュールとし
て扱うことも可能であり，複数のページでの再利用もできる．解析性については，手続き的なプログラム のような長いコードが出てこないこと，HTMLが実際にページ上に見える内容と対比しやすいこと，定義 ファイルの記述は単純なキーと値の組み合わせの羅列であることを考えれば，解析はしやすい状況にある．
変更性については，本章で示した通り，さまざまな動作を宣言的な記述の変更で対処でき，その結果は他 の部分に大きく影響を与えないものも多い．ただし，INTER-Mediatorはデータベースエンジンを別のソフ トウェアに委ねているため，INTER-Mediatorで作ったWebアプリケーションについては変更しやすい箇所 と，例えばコマンドでのデータベース管理といった変更を行うための知識が必要な箇所が発生する．試験 性についてはINTER-Mediator自身は特に機能を持たない．Webアプリケーションの自動テストに使われる
Selenium[91]などの別のツールを使う必要がある．結果として品質モデルの基準で言えば，HTML/CSSを
ベースにしたレベルでのモジュール性や再利用性があり，宣言的な手法での変更性を持つフレームワークと なる．
表4.2:システム／ソフトウェア製品の標準品質モデルの「保守性」
品質特性 INTER-Mediatorに対する評価
モジュール性 HTMLテキストや項目の羅列である定義ファイルではこの特性はあると言えるが，オブジェク ト指向のクラスのような意味でのモジュール性はない
再利用性 「モジュール性」と同様
解析性 記述がシンプル，HTMLは表示結果と対比しやすい，定義ファイルは項目の羅列だけであり把 握はしやすい
変更性 宣言的な記述により変更ができ，他の部分への影響は比較的少ない．一方，データベースの管 理に及ぶと変更は困難になる
試験性 作成したアプリケーションの試験を行う仕組みは持っていないので，他のツールを使う
エンドユーザーによるTailorablity2を持つシステムを設計する手法が研究されており，Tailorablityがある ことを示すために開発したシステムの変更をケーススタディ形式で進めたときの知見をまとめている[94]．
本章で保守作業の可能性を例で示している点では共通の手法である．Tailorablityとは，既存のアプリケー ションをベースにした開発や，システムやフレームワークの開発時にユーザーの要求に応じて改変ができる 性質を示している[66]．保守や再開発はTailorablityによってその範囲が広がることが指摘されており，そ の結果エンドユーザーとソフトウェアエンジニアが共同作業する機会が増える[26]．エンドユーザーによる 保守を促進するためには，保守の段階でもなんらかのエンジニアのサポートが受けられることが望ましく，
それぞれの開発プロセスでエンジニアとエンドユーザーが協調して開発に取り組む必要性[61]と合致する．
開発プロセスとエンドユーザーによる保守に関して，エンドユーザーソフトウェアエンジニアリング[12]
の中では保守作業はプロセスの1つとして捉えられている．エンドユーザーソフトウェアエンジニアリング は，要求定義（Requirements），Design and Specification（設計と仕様），Reuse（再利用），Implementation
（実装），Testing and Verification（テストと確認），Debugging（デバッグ）といった6つの作業に分類され
ている[61]．保守はReuseの中の作業の1つと位置付けている．Reuseを行う上でのエンドユーザーにとっ
ての問題として，ある目的で作られたものを別の用途に転用できるかどうかの判断ができないことがある としている．その解決策にはTailorablityを持たせることが示されている[65]．すなわち，Reuseの観点か らは知識や開発物を別の用途に転用できることによって，より効率的に保守が進められると言い換えるこ
2コンピュータの分野では適切な訳語が定義されていないので，英語で記述をする．
4.8. INTER-Mediatorを用いたシステムの改変に関するまとめ 41 とができる．INTER-Mediatorの定義ファイルやページファイル内の宣言的な記述に関しては，それほど多 くのポターンが存在するということではない．筆者のさまざまなフレームワークを使ってきた経験から言 えば，さほど多くないルールを理解すれば，Webアプリケーションは開発できる．また，HTMLの便利な 点はタグ単位でコピー&ペーストをし，ペースト先で修正するといった記述が一般的に行われている．これ らの点からINTER-Mediatorは知識の転用は十分に可能な仕様となっていて，Tailorablityがあると言える．
4.8 INTER-Mediator を用いたシステムの改変に関するまとめ
以上のように，表4.1で示した!〜1 !の改変については，一般的なフレームワークでは手続き的なプログ3 ラミングが必要になる場面でも，INTER-Mediatorは宣言的な記述の変更で改変が可能となる．!〜4 !につ6 いては，もともと手続き的な記述を行っていたり，スキーマ変更のようにエンジアリングの知識が必要な箇 所であり，INTER-Mediatorを用いても手続き的なプログラムの修正が必要である．分類上は半分ではあり，
比較的マイナーな修正に相当するのが!〜1 !ではあるが，宣言的な記述の範囲内でエンドユーザーによって3 主体的に作業を進められるとすれば，システムの継続的な利用を促進する要因になる．
43
第 5 章 フレームワークの動作上の特徴
INTER-MediatorによるWebアプリケーション作成に必要な定義ファイルとページファイルの作成方法につ
いて第3章で説明した．本章では，これらの情報を利用して，どのようにWebページのテンプレート処理 やデータベースへの更新が行われているのかを説明する．最初に全体的なアーキテクチャについて議論し，
テンプレート処理を始めとするさまざまな機能を解説する．
5.1 INTER-Mediator のアーキテクチャ
INTER-Mediatorを利用したWebアプリケーションの構成は図3.1に示した通りで，開発者が用意するの はデータベース，定義ファイル，ページファイルである．こうした手法がWebアプリケーションに関して 持つ意味付けを最初に議論する．
5.1.1 モックアップ駆動開発
一般的な手続き的プログラミングを行って利用するフレームワークはMVCアーキテクチャを採用してい るのが一般的であり，開発者自身が，アプリケーションの動作を行うためのモデル，ビュー，コントロー ラーのそれぞれのコンポーネントを，フレームワークに用意されたクラスを継承するなどのさまざまなサ ポートを得て定義して利用する．しかしながら，INTER-Mediatorでは，明確なMVCのコンポーネントの定 義は開発時には行わない．内部的動作の上では，ある部分はコントローラーの一部などと言える機能を持っ ているものの，エンドユーザー開発者に対してはその部分を意識しなくてもいいような実装をした．アー キテクチャを意識した構成をしなくてもWebアプリケーションをユーザーインタフェースであるHTMLの テンプレートを中心に開発できる点が，エンドユーザーにとって開発物自体が解りやすいと感じられるこ とに注目した．
成果物に近いものを最初に作る「プロトタイピング」は従来からある手法であるが，Mockup Driven
Development[8]（MockupDD）といった手法が提唱されており，アジャイル開発プロセスの1つとして位
置づけられている[84]．Webアプリケーション開発で言えば，HTMLをベースにしてユーザーインタフェー ス部分をまず作り，そこから開発を始めるといった手法である．一般にはモデル駆動の開発が推奨されてい る．抽象的な意味ではモデルはシステム動作の前提となる基本的な構造を定義することもある．実装の上で は，MVCの階層をいずれも手続き的なプログラミング言語で記述する場合，モデル部分がすべての処理の 基礎になることもあって，インタフェースや機能等を早めに確定した上で，残りの階層を構築することで，
後々の大幅な変更を避けるといった意図がある．
予算規模の大きなプロジェクトでは設計のプロフェッショナルが参画して，モデル駆動の開発が行われて