Vol. 31 No. 1 Feb [3] INTER-Mediator HTML HTML ( HTML ) Web 2 INTER-Mediator 3 Web INTER-Mediator INTER-Mediator Web Web 2010 MIT Lic

エンドユーザーによる保守作業を可能にする

Web

アプリケーションフレームワーク

新居 雅行 鄭 顕志 石川 冬樹

筆者が開発した INTER-Mediator は，データベースを使用し Web 経由でアクセスするシステムの開発に利用する ためのフレームワークである．予算規模の小さな組織でも業務システムの開発を円滑にできることを目指して開発さ れた．データの表示や書き込みは手続き的なプログラムを作成しなくても宣言的な記述で実現する．開発作業後での 表示項目の追加のような小規模な改変であれば，HTML での記述や設定ファイルの修正で行えるので，エンドユー ザーやデザイナーによるシステム変更作業が可能となる．本稿では，これらの仕組みを実現するフレームワークの アーキテクチャを解説し，フレームワークを利用して構築したシステムの改変が宣言的な手法によってできる点を議 論する．

INTER-Mediator is a framework for developing web applications. Mainly it can be applied to the business system for small and medium organizations, especially limited budget circumstances. As far as presenting and updating the data of database, we can build the page with the declarative way, not any imperative ways by programming languages. This means end users and designers can maintain the developed system, for example adding page elements. In this paper, we discuss how does the framework work and describe the some maintenance tasks can work out by using the declarative way.

1 はじめに

業務系のシステム構築ではデータを効率よく永続化 するためにデータベースを利用し，多種多様なデバイ スから機能を利用可能とするためにWebベースのイ ンターフェースを利用することが求められる．Web を利用するシステム開発においてはMVCアーキテ クチャ[16]を採用したフレームワークを利用し，プロ グラム開発が行われる．この手法は複雑なロジックの Web Application Framework to Realize the

Main-tanance by End-Users.

Masayuki Nii, 電気通信大学大学院博士後期課程, Gradu-ate School of Information Systems, The University of Electro-Communications.

Kenji Tei, 国 立 情 報 学 研 究 所, National Institute of Informatics.

Fuyuki Ishikawa, 国立情報学研究所 / 電気通信大学大 学院, National Institute of Informatics / Graduate School of Information Systems, The University of Electro-Communications. コンピュータソフトウェア, Vol.31, No.1 (2014), pp.60–74. [ソフトウェア論文] 2013 年 5 月 30 日受付. 組み込みが可能で開発者にとっての自由度が高く，開 発現場で積極的に利用されている[6]．システムをプ ログラミング主体で開発すると，例えばデータ表示 に関する軽微な修正であってもプログラム変更が必 要となり，一般のユーザー企業内では修正が行えず， 開発から保守まで一貫して業者へ依頼する．結果的に 保守にかかる費用が高くなり，中小企業では予算不足 のため必要な改変ができずに運用されることもある． 中小企業や企業の部門内のような予算規模が小さ な組織で，コストをかけずに保守可能とすることを目 的としたフレームワーク，INTER-Mediator[20]を提 案する．開発後の保守作業をエンドユーザーやデザイ ナーによっても可能にすることで，従来のシステム開 発とは異なる保守体制を取ることができ，コスト削減 につながる．エンドユーザーによる保守を実現するた めに，宣言的な記述部分の修正だけで，一定範囲のシ ステム改変を可能にした．例えば，データベース上に 用意されているテーブルのフィールドをページ上に 新たに表示したり，フィールドの表示順序を変更した

り，データベースから取り出すデータに対する並べ替 えや検索条件の付加などは，宣言的な記述の変更で可 能である．このような，データベースのスキーマ修正 を伴わず，ユーザーインターフェースの要素に対する 改変やデータベース要求の追加といった，すでに開発 されている情報を元に改良を加えるような作業に対 しての保守をエンドユーザーが行えるような仕組み を持つ． 手続き的なプログラミングよりも，宣言的な記述で 機能を指定できる方が，保守作業ができる人材は広が り，エンドユーザーによる保守作業はより実現しやす くなると考えられる．手続き的なプログラミングの習 熟に対する困難さを示す事例として，プログラミング の学習過程に関する6つの障壁がある[3]．その中で 最も大きな障害である「デザインの障壁」，すなわち アルゴリズムを正しく構築しなければならないという 障壁は手続き的なプログラミングでは必ず発生する． 例えば，「一覧」を作るということは，手続き的なプ ログラミングでは，繰り返されるレコードをループ で処理してそれぞれ表示するように記述する必要が ある．これに対し，同じことを宣言的に記述できると いうことは，フレームワークが繰り返し処理のアル ゴリズムを正しく再現する作業を肩代わりしている ことになる．宣言的な記述で機能を呼び出すことで， 開発者は繰り返しの記述をプログラミング言語で書 く必要がなく，「デザインの障壁」は低くなり，学習効 率は高くなる． エンドユーザー主体の保守作業ができるような仕 組みを実現するために，INTER-Mediatorではデータ ベースのフィールドと，HTMLページの要素を宣言 的な記述だけで連動させる仕組みを導入した．HTML 要素にフィールド名を記述すれば，テンプレート処理 (ページのひな形とデータを合成してユーザーに見せ るHTMLデータを合成する処理)によりデータベー スのフィールドのデータが要素に埋め込まれる．ペー ジ内のテキストフィールドと連動させれば，ユーザー による変更結果を自動的にデータベースに書き込む． 読み出しと更新だけで済むようなページ作成は，デー タベースが用意されていれば手続き的なプログラミ ングを必要としない． 本稿では宣言的な記述だけでデータベースとWeb ページが連動する仕組みに加え，特に保守の段階でエ ンドユーザーがどの程度参画ができるのかを明らか にする．以下，第2章にINTER-Mediatorの概要を解 説し，第3章でWebページ生成のテンプレート処理 について解説する．さらに，第4章ではシステム改 変に対する適合性を検討する．そして，第5章では 本フレームワークがどのような業務に向くのかを検 討し，他の製品やフレームワークとの比較を行う．

2 INTER-Mediator の概要

INTER-Mediatorはデータベースと連動したWeb ページを宣言的な記述を行うだけで作成できるWeb アプリケーションフレームワークである．2010年 初頭よりMIT Licenseとして配布している．データ ベースエンジンには，MySQLやPostgreSQLなどの

PDO(PHP Data Object[12])に対応したRDB，ある いはFileMaker Server[15]を利用できる．Webサー バーにはPHP Ver.5.2以上が稼働する環境が必要で

ある．クライアントとなるWebブラウザについて

は，HTML5対応ブラウザでの利用を原則としてい る．Internet Explorerについては，Ver.8以降で利 用できる． INTER-Mediatorは筆者の1人が受注したいくつか のシステムでの稼働実績がある．2013年4月の時点 で，看護師の勤務予定を作成するシステムはすでに稼 働しており，開発中の案件としては，オンデマンド印 刷を受け付けるサイトや，店舗営業向けのカタログシ ステムなどがある． 2. 1 フレームワークの利用者 INTER-Mediatorは実務担当者などのエンドユー ザーによる保守の実現を目指している．ここで想定し ているエンドユーザーは，プログラミングに関する知 識はないものの，HTMLやCSSについての知識はあ り，ページ上に表示する部品(ウィジェット)の変更や その書式の改変を自力でできるようなユーザーを示 す．Web制作現場でのデザイナーも，対象者と想定 している． システムを新規開発する場合，ドメイン分析に基づ

62 くデータベースのスキーマ設計など，専門的な知識が 必要な作業が必要になり，リリースするまでの開発は 主に専門家が行う必要がある．その後，運用中に見つ かった改訂などを含めた保守作業をエンドユーザーが 行うことを本論文では想定している． 2. 2 アーキテクチャ INTER-Mediatorを利用して開発されるWebアプリ ケーションのアーキテクチャを図1に示した． INTER-Mediatorはサーバーサイドで稼働するソフトウェア と，クライアントサイドで稼働するものに分類され る．図中，「拡張」コンポーネントの部分はプログラ ミングにより独自に機能を追加できる箇所である． 開発において必ず用意するものとして，「データベー ス」，「ページファイル」，「定義ファイル」がある．デー タベースは前述のRDB等を用意しスキーマを適用し ておく．「ページファイル」とは，HTMLで記述した Webページのテンプレートである．「定義ファイル」 には宣言的な記述でデータベースの利用方法などを 記述する．ページファイルと定義ファイルの構成につ いては，2. 5節で詳しく解説する． 2. 3 機能概要 INTER-Mediatorの機能概要を示すために，Webア プリケーションで組み込まれる機能について，表示， 図 1 INTER-Mediator のアーキテクチャ 編集，インタラクティブ，その他の4つに分類した結 果を表1に示す．「表示」は主にデータベースの内容 をページ上に展開する機能である．「編集」はページ 上で入力や変更したデータをデータベース側に反映 表 1 INTER-Mediator の機能概要 (Ver.3.3 現在) 機能分類 宣言的な記述で実現 プログラム記述が必要 表示 (デ ー タ ベースア クセス) • テーブルやビューの指定 • 検索条件の指定 • ソート条件の指定 • リレーションシップに基づく 検索 • サーバーサイドで データベースへの要 求や応答を変更 (バインデ ィング) • データベースのフィールドに 関して – データを要素内に表示 – データを変更して要素内 に表示 – データをフォーム要素に 設定 – データを要素の属性やス タイル属性に設定 – 標 準 で 用 意 さ れ た JavaScript コンポーネン トへの表示 • 複数のレコードを繰り返し て表示 • リレーションによって得られ たレコードの表示 • ノード生成時での割 り込み処理 • フィールドから求め た計算結果の表示 • 標準で用意されてい ない変換処理 • 標準で用意されてい な い JavaScript コ ンポーネントの利用 編集 • ユーザーによる編集結果を フィールドに書き戻す • 編集結果を変換して書き戻す • 楽観的ロックに基づくマルチ ユーザー対応 • 値のチェック • 変更したフィールドとリレー ションが設定された他のフ ィールドの更新 • サーバーサイドで データベースへの要 求や応答を変更 • 標準で用意されてい ない変換処理 • フォーム要素以外へ のアクションに対す る処理 インタラ クティブ • レコード作成ボタン • レコード削除ボタン • 一定数のレコードごとの表 示と表示範囲移動のコント ロール • 新規レコード作成専用ページ • ファイルのアップロード • サーバーサイドで データベースへの要 求や応答を変更 • 入力結果に応じてフ ィールドから求めら れた計算結果の更新 その他 • 認証・認可およびユーザーイ ンターフェース • パスワードの変更 • 画像などのメディアアクセス への認証の適用 • メール送信

させる機能である．「インタラクティブ」はフレーム ワークに自動的に追加されるユーザーインターフェー スをまとめた．「その他」には認証などを記載した．そ れぞれの分類に関してINTER-Mediatorで宣言的な 記述だけで利用できる機能と，プログラムを記述する ことで実現する機能を表1に示した． 2. 4 サンプルプログラムの概要 フレームワークを使ったWebアプリケーション作 成を解説するために，サンプルとして社内の共有物 などについて貸し出し管理や一覧作成を行う「資産 管理」アプリケーションの例を示す．本サンプルは INTER-Mediatorのソースに含めて配布している．ス キーマには，資産，貸出履歴，社員名簿といった3つ のエンティティだけがある．図2は「資産一覧」の表 示画面である．データベースのデータが表示されてい るとともに複数のレコードが繰り返され，一定数のレ コードごとに表示するインタラクティブ要素がページ 最上部に表示されている． 図3は個別の資産に関する貸出履歴を表示する「資 産詳細」画面で，テキストフィールドなどのフォーム 要素や，貸出履歴として関連レコードの繰り返し表示 が行われている．ここで貸出履歴の追加やメモの記述 図 2 資産管理アプリケーションの「資産一覧」 図 3 資産管理アプリケーションの「資産詳細」 が行える． INTER-Mediatorでは，表1の「プログラム記述が 必要」と記載された機能を実現するような場合には， 手続き的なプログラミングが必要となる．図3のペー ジでは，特定のレコードに絞り込む情報をURLから 取得して設定する個所と，「本日返却」ボタンを押した ときに今日の日付を貸出履歴の最後のレコードに設定 する機能に関して，いずれも数行ほどのJavaScript のプログラムを追加した．また，図2では，フレー ムワークの呼び出し部分と，「詳細」ボタンに関して， いずれも1ステートメントのみのJavaScriptプログ ラムを利用している．これら以外には手続き的なプロ グラムの記述は行っていない． 2. 5 データベース連動ページ作成 INTER-MediatorでのWebアプリケーション作成 に必要な「定義ファイル」と「ページファイル」に記 述すべき内容を，資産管理アプリケーションでの記述 例を用いて説明する． 「定義ファイル」はPHPで記述するが，配列を， 決められたキーとアプリケーションの動作に合わせた 値で記述するだけで，クラス定義や制御構造を交えた 手続き的なプログラミングを行う必要はない． 「ページファイル」はHTMLで既定された範囲の タグと属性のみで記述する．一般的なフレームワーク ではテンプレートのための拡張タグを用いることが あり，テンプレート単体で仕上がり具合をブラウザで 確認できない場合があるといった問題点がある． これら2種類のファイルでは手続き的なプログラ ミングは必要なく，宣言的な記述のみである． 2. 5. 1 定義ファイルの作成 リスト1は資産管理アプリケーションで利用する定 義ファイルの例である(ファイル名はcontext.php)． この定義ファイルでは，フレームワークが用意する IM Entry関数を呼び出す必要がある．関数の引数に フレームワークが必要とする情報を配列の形式で指 定する．呼び出す関数はIM Entry関数と常に決まっ ているので，実質的に開発案件ごとの違いがあるの は，配列で指定する部分だけである． 「資産一覧」ではこのうち2行目から始まる配列

64 によって定義された情報を利用しており，定義の概要 はリスト内にコメントで示した．この定義によって， データベース内のassetテーブルを利用することが記 述されている．加えて，データベースからデータを 取り出すときにpurchaseフィールドの値で昇順での 並べ替えを行うといったクエリーのための付加的な 情報も記述している．配列のキーはINTER-Mediator で独自に定義したものであり，さまざまな動作を定義 するために必要に応じて記述する．この1つの配列 を「コンテキスト」と呼ぶ． リスト 1 定義ファイルの例 (context.php) 1 I M _ E n t r y ( a r r a y ( 2 a r r a y ( 3 ’ name ’= > ’ asset ’ , // ペ ー ジ フ ァ イ ル か ら の 参 照 名 4 ’ view ’= > ’ asset ’ , // デ ー タ ベ ー ス 側 の テ ー ブ ル 名 5 ’ key ’= > ’ a s s e t _ i d ’ , // キ ー フ ィ ー ル ド 名

6 ’ repeat - control ’= > ’ i n s e r t delete ’ ,

7 // 挿 入 ， 削 除 ボ タ ン を 設 置 8 ’ records ’= >5 , //5 レ コ ー ド ず つ 表 示 す る 9 ’ paging ’= > true , // 一 定 数 の レ コ ー ド ご と に 表 示 10 ’ sort ’= > a r r a y ( // 並 べ 替 え の フ ィ ー ル ド と 方 向 11 a r r a y ( ’ field ’= > ’ p u r c h a s e ’ , //( フ ィ ー ル ド ) 12 ’ d i r e c t i o n ’= > ’ ASC ’) ,) , //( 方 向 ) 13 [ … 途 中 省 略 … ] 14 ) , 15 NULL , 16 a r r a y ( /* デ ー タ ベ ー ス 接 続 情 報 ， 詳 細 は 省 略 * / ) 17 ); 2. 5. 2 ページファイルの作成 「資産一覧」のページファイルをリスト2に示す． ページファイルでの記述内容について，図中の番号と 対比させて解説する． 1 ⃝ヘッダ部のSCRIPTタグの要素で，リスト1の 定義ファイルを読み込む部分があり，これによりペー ジにフレームワークが組み込まれる．定義ファイル にアクセスすることで得られるのはJavaScriptの プログラムであるが，固定的なプログラムだけでな く，一部はサーバー側でフレームワークによって動的 にプログラムを生成している．これらを取り込んだ JavaScriptのプログラムを利用して，テンプレート 処理や更新処理を行っている． 2 ⃝ページ内の要素では，リスト2の17行目以降 にあるように「IM[asset@category]」といった記述が 見られる．ここでは，定義ファイルの参照名(name キーの値)と，データベース側のフィールド名を，@ で区切って記述する．この指定のある要素を「リンク ノード」と呼び，IM[...] の部分を「ターゲット指定」 と呼ぶ． INTER-Mediatorがテンプレート処理をするとき， リスト2でのリンクノード(TDタグ要素)のテキス ト要素にテーブルのフィールドにあったデータが組み 込まれ，結果としてテーブルのセルにフィールドの データが表示される．ここではTRタグ要素が1つ だけの1行分の表であるが，レコードが複数あれば， レコードの数だけTRタグ要素を複製してレコード が一覧されて見える． 3 ⃝テンプレート処理を始めるには，「 INTERMedi-ator.construct()」というJavaScriptの呼び出しを行 う．このページでは，BODY要素のonload属性で記 述したので，ページファイルの内容をブラウザが読み 出した直後にテンプレート処理が行われることにな る．テンプレート処理は第3章で解説する． リスト 2 「資産一覧」のページファイルの例 1 < h t m l > 2 < h e a d >

3 ⃝<script src =" contexts . php "></ script >1 4 < / h e a d > 5 < b o d y o n l o a d = " I N T E R M e d i a t o r . c o n s t r u c t () " >⃝3 6 < div id = " I M _ N A V I G A T O R " > < / div >⃝4 7 < t a b l e > 8 < t h e a d > [ 省 略 ] < / t h e a d > 9 < t b o d y > 10 < tr > 11 < td >

12 ⃝<button onclick =" location . href5 13 = ’ a s s e t _ d e t a i l . h t m l ? id = $ ’; "

14 c l a s s = " IM [ a s s e t @ a s s e t _ i d @ $ o n c l i c k ] " >

15 詳 細 </ button >

16 < / td >

17 ⃝<td class ="IM[ asset@category ]"></td >2 18 < td c l a s s = " IM [ a s s e t @ n a m e ] " > < / td > 19 < td c l a s s = " IM [ a s s e t @ m a n i f a c t u r e ] " > < / td > 20 < td c l a s s = " IM [ a s s e t @ p r o d u c t i n f o ] " > < / td > 21 < td c l a s s = " IM [ a s s e t @ p u r c h a s e ] " > < / td > 22 < td c l a s s = " IM [ a s s e t @ d i s c a r d ] " > < / td > 23 < td > < / td > 24 < / tr > 25 < / t b o d y > 26 < / t a b l e > 27 < / b o d y > 28 < / h t m l >

4 ⃝にid属性が「IM NAVIGATOR」の要素がある． これにより，図2に見られるような，5レコードずつ 表示しつつ，前後のページへ移動するためのユーザー インターフェース(ページコントロール)が，フレー ムワークによって自動的に挿入される．ページコント ロールは，リスト1の定義ファイルでpagingキーの 値がtrueに設定されているコンテキストにのみ作用 する． さらに図2では，1行ごとに「削除」ボタンがあ り，画面上部には「レコード追加asset」というリン クがある．これらは，リスト1の定義ファイルにある repeat-controlキーによって指示でき，フレームワー クによって自動的に挿入される． 5 ⃝BUTTONタグ要素の中にJavaScriptのプログ ラムが見られるが，これは，図3の「資産詳細」のペー ジに移動するためのプログラムである．BUTTONタ

グ要素のclass属性には「asset@asset id@$onclick」

という記述がある．これは，要素のonclick属性に 記述されたテキストに含まれる「$」という文字を， asset idフィールドの値に置き換えるということを 意味する．結果としてURLのパラメータにどのレ コードを表示するのかを「?id=12」などと指定して 図3のページを呼び出すことができる．ファイル名 asset detail.htmlの「資産詳細」ページ側ではパラ メータの値を検索条件に加えて特定のレコードに絞 り込み表示する．データベースへのクエリーに対し て「asset id=12」といった検索条件を加えるための APIがINTER-Mediatorにあるので，データベース 検索処理の条件を動的に指定できる．

3 テンプレート処理と更新処理

INTER-MediatorによるWebアプリケーション作 成に必要な定義ファイルとページファイルの作成方法 について2章で説明した．本章では，これらの情報 を利用して，どのようにWebページのテンプレート 処理やデータベースへの更新が行われているのかを 説明する． INTER-Mediatorでのテンプレート処理は，図1に 示した「コア機能」のコンポーネントで行われる． ページファイルを元にデータベースから得られたデー 図 4 テンプレート処理と更新処理の概要 タを埋め込み，ページとして表示するHTMLが生成 される．Webアプリケーションでは，ロジックとユー ザーインターフェースを分離することが可能な点か ら[10]，フレームワークにテンプレート処理が組み込 まれるのが一般的である．通常はテキスト処理によ るテンプレート処理がサーバーサイドで行われるが， INTER-MediatorではDOMをベースにした処理を行 う．執筆時点ではクライアントサイドでの処理を行っ ているが，将来的にはサーバー側でのテンプレートも 対応する(一部開発済み)．DOMを一定のルールで解 析する手法により，独自のタグを定義しなくても純粋 なHTMLで記述されたテンプレート処理が可能とな る．図4にはページの合成とページ上での編集結果 からデータベース更新を行う流れの概要を示した． 3. 1 1レコード範囲の識別 テンプレート処理では，まずページファイルの解析 が行われ，1レコードに対応付けられる範囲を識別す る．その結果，1レコード分のデータを挿入するノー ド群の「リピーター」と，リピーターを束ねる「エン クロージャー」が求められる．典型的なリピーターは TRタグ要素群であり，その場合にエンクロージャー となる要素はTBODYタグである．他にOPTION

とSELECTタグや，汎用的なDIVあるいはSAPN

タグもリピーターとエンクロージャーのセットとして 利用もできる． リピーターとエンクロージャーの識別手順は次の 通りである．ページ内にあるBODYタグ要素の内部 を前順走査を行い「ターゲット指定」(class属性に IM[...]の記述がある要素)がある「リンクノード」を

66 見つける．そのノードを含めた上位のノードについ て，エンクロージャーとリピーターのセットを見つけ る．その後，すべてのリンクノードを収集するために 再度リピーター内を走査する．ただし，さらに内部に 異なるエンクロージャーとリピーターが存在すれば， その内部のリンクノードは収集しない．こうして収 集したターゲット指定の情報から，定義ファイルのど のコンテキストを利用するかを求める．もし，いくつ かのコンテキストを指定していれば，指定している ノードが最も多いコンテキストを使用する．リスト2 ではassetというコンテキストを使うことになり，定 義ファイルのviewキーの設定よりassetテーブルか らレコードを取得する． 3. 2 データベースアクセスとテンプレート処理 データベースからレコードを得て，1レコードの内 容を1つのリピーターに合成する．複数のレコードが 得られた場合は，結果として1つのエンクロージャー (TBODY要素)の中にリピーター(TRタグ要素群) がレコードの数だけ複製・挿入され，複数のレコード が一覧表示される． リンクノードに対してデータベーステーブルの フィールドの値が合成される．INPUTタグ要素によ るテキストフィールドでは，value属性など種類に応 じた属性にフィールドのデータが設定される．一方， DIVやTDなどの編集可能でないHTML要素の場 合，通常はテキストノードとしてフィールドのデータ を追加する．ターゲット指定で所定の記述を行うこと で，特定の属性，特定のスタイル属性，innerHTML への追加といった指定もできる． 3. 3 データベース更新 Webページに呼び出されたデータベースのデータ を，逆にデータベース側に更新をかける仕組みも用意 されている．INPUTタグによるテキストフィールド に合成されたデータは，変更することでデータベー スに書き戻せる．テキストフィールドにデータベース のフィールドの値を挿入する場合，INTER-Mediator はJavaScriptのオブジェクトに，そのレコードのコ ンテキスト名，キーフィールドの値，そして挿入した 値を記録する．ページ生成時に要素ごとに固有のid 属性を割り当てており，そのid属性に対応して記録 されている．すなわち，画面に見えているテキスト フィールド1つ1つに対して，コンテキストやキー 値を記録している． テキストフィールドの値をユーザーが書き直して別 のフィールドに移動するタイミング(changeイベン ト)でスクリプト起動するようにしておき，コンテキ スト名からテーブル名を取得し，キー値をもとに検索 条件を作成して，更新処理を行う． 3. 4 リレーションシップの実施 3章のこれより後の部分は，図4には明示していな い動作について解説する． あるレコードに対する関連レコード(例えば伝票と 明細のような関係)があるようなリレーションシップ が存在し，それをWebページ内に展開したい場合に も対応できる．ページファイル内で，リピーターとエ ンクロージャーのセットの中に，さらにリピーターと エンクロージャーのセットを記述する．上位のセット が基準となるレコードで，それに対する下位のセット は0∼複数個のレコードを展開する． 階層的なリピーターとエンクロージャーのセットを 見つけるために，1レコード分のテンプレート処理が 終わった後にリピーターの内部を探索する．内部にリ ピーターとエンクロージャーのセットがさらに見つか ると，そこで新たに合成処理を行う．見つかった内部 のリピーターを分離し，使用するコンテキストを確 定してデータベースアクセスを行う．定義ファイルに relationキーによる定義があれば，上位のリピーター のレコードにある値を検索条件に追加してデータベー スアクセスを行い，結果として関連レコードの取り出 しが可能となる． 3. 5 新規レコードとレコード削除 新規レコードや，レコード削除のボタンは，定義 ファイルで指定することで自動的にページ上に配置さ れる． コンテキストに新規レコード作成ボタンの生成を 指示すると，一連のレコードの最下部あるいは，一定

数ごとのレコードの表示範囲を切り替えるページコ ントロール上のいずれかに，新規レコード作成ボタ ンが追加される．新規レコード作成時の初期値は通 常はデータベースのスキーマで設定できるが，コン テキストでも指定できる．INTER-Mediatorでは，新 規レコードを作ったときには，そのレコードが編集状 態になるように動作する．これは，Microsoft Access やFileMakerでの動作に習ったものである． レコード削除については，リピーターの内部にボタ ンを用意するか，ページコントロール上にボタンを用 意できる．フィールドの更新と同様，コンテキストと レコードを特定するためのキーフィールドと値を保持 し，ボタンをクリックすることでそれらの値をもとに データベースにコマンドを送ってレコードの削除を行 う．レコード削除後には，フレームワークが対応する リピーターを削除する．ただし，ページコントロール に関連したコンテキストの場合は，レコード削除後に ページの合成をフレームワークがやり直す． 3. 6 フィールド単位のデータ変換 フィールド単位でのデータ変換の仕組みがあり，日 付のデータの変換などに利用できる．図1に示した 「フィルタクラス」において，レコードの中の1つの フィールドに対する変換処理を記述できる．例えば， データベースから「2013-02-24」という情報が得られ れば，「2013年2月24日」という情報に変更する．一 方で，テキストフィールドで編集して更新したときに は逆の変換を行う．日付以外に数値のフォーマットや テキストを前後に付加するもの，HTML文字列に関 するものが用意されている．

4 INTER-Mediator を用いたシステムの改変

通常，システムの構築は専門家による分析，設計， 実装，テストを経て完成される．そのシステムに対す る要求に変化がある場合，同様にして専門家に対して 変更の依頼をするのが一般的である．しかしながら， 少しの修正であっても手続き的なプログラムの修正が 必要な場合が多く，エンドユーザーがシステム改変に 主体的に関わることは難しい． INTER-Mediatorで構築する作業においては，分析 とその結果をデータベースとして蓄積可能にするた めのスキーマ構築，そしてクライアントサイドでの 応答などに対応するJavaScriptでのプログラミング， さらにはサーバーサイドでの処理の追加など，データ ベース設計やプログラミングの知識が必要な場面が ある．一方，ページファイルや定義ファイルの修正に ついては手続き的なプログラミングの知識が必要で はなく，システム構築の専門家でなくても行える範囲 である．INTER-Mediatorで構築したシステムがどの 範囲であればエンドユーザーによる改変が可能なの かを本章で示す． 4. 1 システム改変の分類 データベースを利用するWebアプリケーションに おける改変作業を分類したのが表2である．図5に は表2の番号で示した改変を適用する場所を示した． 本章で，INTER-Mediatorでは⃝1∼⃝3についてはプロ グラムの変更なしにできることを示す．なお，⃝4∼⃝6 は専門家によって実施される内容と位置付けている． 4. 2 ページ要素の改変 表2の⃝1の改変については，HTMLで記述された テンプレートの一部の修正のようなきわめて小規模 な改変であれば，フレームワークや開発手法の種類を 表 2 システム改変の発生する状況 概要 例 1 ⃝ ページ要素 • 表示する順序変更，非表示 フィールドを 新たに追加表示する • 文字の色の変更 2 ⃝ データベース要求 • レコード取得のための検索や並べ替え条 件の変更 3 ⃝ 単一フィールド応答 • 小数以下の桁数を 2 桁から 3 桁に増やす • 一定の文字列を前後に追加する 4 ⃝ クライアント • 特別な処理を行うボタンの設置 スクリプト • 表示要素の更新処理 5 ⃝ データベース応答 • 新規レコード作成後にメール送信を追加 する • データベースだけで実現できないような 集計処理を行う 6 ⃝ スキーマ変更 • 新たなビューを作成する • テーブルやフィールドを新たに作成する * 新規ページ追加 • スクラッチから作成する • 既存ページを複製後，⃝∼1 ⃝の改変をす6 る

68 図 5 ページ改変の分類 問わず手続き的なプログラムの知識は不要である． ここで，INTER-Mediatorを利用して作成したアプ リケーションに対して，表2の⃝1に相当する要素の 種類を変更する改変作業を示す．図3のWebページ にある「分類」を，テキストフィールドではなくポッ プアップメニューから一定の文字列を選択して入力 できるようにしたいとする．加えて，ポップアップ メニューの選択肢をマスターテーブルから取り出す といった，表2の⃝2の改変も交えて行うことにする． データベースには，「カテゴリ」として取り得る値を記 録したマスターテーブルの「category」が存在し，シ リアル番号が記録されたcategory idフィールドと， 選択肢となる文字列が記録されたnameフィールド を持つ． ポップアップメニューに変更するために，ページ ファイルの一部をリスト3のようにinputタグ要素か らselectタグ要素に変更し，加えて選択肢をoption タグで記述する．optionタグ要素は「category」と いう名前のコンテキストからデータを得る．selectタ グ要素内のoptionタグ要素は，それぞれエンクロー ジャーとリピーターとして認識されるので，category テーブルからデータを取り出し，存在するレコード数 分optionタグ要素が繰り返される．各レコードでは value属性はcategory idフィールドの値，そして要 素の内容にはカテゴリの名前を示すnameフィールド の文字列が設定され，結果としてnameフィールドに あるいくつかの値がポップアップメニューとして表示 される．更にこのコンテキストが利用できるように，

定義ファイルには「array(′name′=>′category′)」

という記述を追加する．なお，categoryフィールド には文字列で「個人用」などと記録していたが，こ の改変によりcategoryテーブルの主キーである cat-egory idフィールドにある数値を記録する．その結 果，図2に示す一覧表示の「分類」列では，category フィールドの値がそのまま見えるようになり，文字列 ではなく数字が見えるようになる．元のように文字列 が見えるようにする修正は，4.5節で解説する． リスト 3 ページファイルの改変 (1) 1 【 変 更 前 】 2 < i n p u t c l a s s = " IM [ a s s e t d e t a i l @ c a t e g o r y ] " / > 3 【 変 更 後 】 4 < s e l e c t c l a s s = " IM [ a s s e t d e t a i l @ c a t e g o r y ] " > 5 < o p t i o n c l a s s = " IM [ c a t e g o r y @ c a t e g o r y _ i d @ v a l u e | c a t e g o r y @ n a m e ] " v a l u e = " " > < / o p t i o n > 6 < / s e l e c t > ページ要素の修正が必要になれば，タグの修正は フレームワークの種類に限らず必要である．しかし ながら，INTER-Mediatorではこの記述だけで，ペー ジ表示したときにcategoryフィールドの値に応じて 対応する選択肢が選択される．また，ポップアップメ ニューを選択することで，選択した項目に対応する値 を自動的に元のレコードのcategoryフィールドに書 き込む． 一般的な手続き的なプログラミングを主体とした フレームワークでも，テンプレートをHTML主体で 記述し，テンプレート処理のために少数の拡張記述を 加えた程度で記述できる場合もある．表2の⃝1の改 変を行う場合，HTMLの変更だけで済まない場合に は，プログラムの中にある変更可能な要素を探し出す ためにはビューやコントローラーがどのファイルであ るのかなどの構成全体を把握する必要があり，小規模 な修正でも全体的な知識が必要である．また，タグの 種類に応じたプログラムの変更が必要になることも ある．一方，INTER-Mediatorでは，ページファイル の記述のみの変更で対処できる． 4. 3 データベース要求の改変 表2の⃝2の改変に相当するような例として，図2 ではすべてのレコードを一覧しているが，破棄してい ない資産(discardフィールドが未入力)だけの一覧を 出したくなったとする．

INTER-Mediatorで改変を行う場合，リスト4のよ うなコンテキストを定義ファイルに記述することにな る．作業手順は次の通りである．定義ファイルではす

でに記述されたリスト1のコンテキストをコピーして

nameキーの値を「asseteffect」に書き換え，query

キーの定義を追加する†1_{．ページファイルは既存のも} のを複製して，ターゲット指定のコンテキスト名を変 更すれば良い． リスト 4 定義ファイルの改変 (1) 1 a r r a y ( 2 ’ name ’ = > ’ a s s e t e f f e c t ’ , 3 ’ view ’ = > ’ asset ’ , 4 ’ sort ’ = > a r r a y ( 5 a r r a y ( ’ field ’ = > ’ p u r c h a s e ’ , ’ d i r e c t i o n ’ = > ’ ASC ’) , 6 ) , 7 ’ query ’ = > a r r a y ( 8 a r r a y ( ’ field ’ = > ’ discard ’ , ’ o p e r a t o r ’ = > ’ < ’ , ’ value ’= > ’1990 -1 -1 ’) , 9 ) , 10 ) , 一般的なフレームワークでは，SQLで記述した要 求の変更やあるいはモデル部分のプログラムの変更， あるいはコントローラーでの受け入れ場所の確保な ど，プログラミングの追加や編集が必要になるような 改変である．INTER-Mediatorではデータベース利用 を宣言的に記述できるので，それに関連する改変も宣 言的な記述の変更で対処できる． 4. 4 データベース応答の改変 表2では，データベースからの応答を変更する仕組 みとして，⃝3の1フィールド単位と，⃝5の単一ある いは複数のレコード単位の応答を変更する場合に分け た．⃝5に対応する改変については，INTER-Mediator を使った場合においても，手続き的なプログラムの作 成を必要とする． 3 ⃝のような改変の例として，データベースから得 られる日付の書式を整えたいとする．MySQLでは日 †1 MySQL では未入力の日付型フィールドの値は「0000-00-00」となるので適当な日付 (ここでは 1990 年 1 月 1 日) より前であれば，discard フィールドは未入力 とみなせる． 付型のフィールドのデータは「2012-12-19」のような ISO8601形式で得られるが，年月日をスラッシュで 区切った日付で表示したいといった要望が発生したと する． INTER-Mediatorで作ったWebアプリケーション では，定義ファイルでのIM Entry関数の2つ目の 引数にリスト5のような配列を定義することで対 処できる．この記述により，assetテーブルの pur-chaseフィールドについてはparameterキーに従った 「12/12/19」，discardフィールドについては既定の 書式である「2012/12/19」といった形式に変換する． ページ上に表示された日付を変更した場合，データ ベースに書き込むときに，これらの形式からISO8601 形式への逆変換も行う．1フィールドのデータの変換 については，カンマ付きや通貨記号付きなどいくつか の典型的な書式処理は定義ファイルへの記述を追加す るだけで行える． リスト 5 定義ファイルの改変 (2) 1 a r r a y ( 2 ’ f o r m a t t e r ’ = > a r r a y ( 3 a r r a y ( ’ field ’ = > ’ a s s e t @ p u r c h a s e ’ , 4 ’ c o n v e r t e r - class ’ = > ’ M y S Q L D a t e T i m e ’ , 5 ’ p a r a m e t e r ’= > ’% y /% m /% d ’) , 6 a r r a y ( ’ field ’ = > ’ a s s e t @ d i s c a r d ’ , 7 ’ c o n v e r t e r - class ’ = > ’ M y S Q L D a t e T i m e ’) , 8 ) , 同じようなことを一般的なフレームワークで行う 場合は，プログラム中にフォーマット変換を行う記述 を追加することになる．一方，INTER-Mediatorは日 付や数値などについては定義ファイル上の設定として 対処できる． 4. 5 リレーションシップを伴う改変 4.2節では，1つのフィールドの値をマスターテー ブルより取得し，そのフィールドにはマスターテーブ ルの主キー値(連番の数値の1つ)を記録するように した．このままでは，図2に示す「分類」列には数字 が見えてしまう．ここで，改変による副作用の修正が 必要になる．フィールドの記述を変更するという外見 的な要因では⃝3の改変である．また，データベース の応答についての記述を加えるため，⃝2に関する改

70 変でもある． 一覧表に提示するテーブルのcategoryフィールド にある値とリレーションシップが定義された新たなコ ンテキストとしてリスト6のような定義を定義ファイ ルに追加する．このコンテキスト「category-in-list」 を利用する場合は，viewに対応する値を参照して cat-egoryテーブルにアクセスし，そのときrelationキー に対応する設定を参照して，一覧表示側のcategory フィールドの値と，categoryテーブルのcategory id の値が一致するものを取得する． リスト 6 定義ファイルへの追加 1 a r r a y ( 2 ’ name ’ = > ’ c a t e g o r y - in - list ’ , 3 ’ view ’ = > ’ c a t e g o r y ’ , 4 ’ r e l a t i o n ’ = > a r r a y ( 5 a r r a y ( 6 ’ foreign - key ’ = > ’ c a t e g o r y _ i d ’ , 7 ’ join - field ’= > ’ c a t e g o r y ’ , 8 ’ o p e r a t o r ’ = > ’= ’ 9 ) ) ) 一方，ページファイルではリスト7のように，td タグ要素による1つのセルの中に，2重になるspan タグ要素を記述し，それぞれがエンクロージャーと リピーターとなるようにclass属性を設定する．ま た，内側のspanタグ要素にはIM[...]の記述により， category-in-listコンテキストで得られたnameフィー ルドの値が要素の内容として設定されるようにする． これで，表のセルの中には「個人用」などの文字列が 表示されるようになる． リスト 7 ページファイルの改変 (2) 1 【 変 更 前 】 2 < td c l a s s = " IM [ a s s e t e f f e c t @ c a t e g o r y ] " > < / td > 3 【 変 更 後 】 4 < td > 5 < s p a n c l a s s = " _ i m _ e n c l o s u r e " > 6 < s p a n c l a s s = " _ i m _ r e p e a t e r IM [ c a t e g o r y in -l i s t @ n a m e ] " > &-lt; / s p a n > 7 < / s p a n > 8 < / td > 一般的なフレームワークでは，このような変更が生 じた場合，スキーマレベルでのビューの作成や，ある いはモデルの応答を変更するといった作業が必要に なる．INTER-Mediatorでは宣言的な記述で，リレー ションシップの追加を伴う改変も可能である． 以上のように，⃝1∼⃝3の改変については，一般的 なフレームワークでは手続き的なプログラミングが 必要になるものの，INTER-Mediatorは宣言的な記述 の変更で改変が可能となる．

5 フレームワークの適用範囲と比較

INTER-Mediatorによって作られるWebアプリケー ションでは，手続き的なプログラムをすることなく データベースの内容の表示や更新が可能となる．ただ し，データベースの設計やスクラッチからの開発には どうしても専門的なスキルが必要になる．エンドユー ザーによる改変が可能な範囲が広がる点は前の章で 示した通りである．一方で，システム開発において本 フレームワークが実用上どのような用途に向くのか を検討し，加えて同じような目的の他のソフトウェア との比較も行う． 5. 1 本フレームワークが適用可能なシステム システム投資によって市場における競争力を高め るという考え方があり[7]，システム化の有効性は高 い．業務システムには，基幹システムのような大規模 なものから，数人規模で使うものまでさまざまな形態 がある．基幹システムでは予算が十分に取られること があるが，規模の小さいシステムは予算が限られてい たり確保できない場合もある†2_{．INTER-Mediatorは} 限られた予算でシステムを運用するような場面でも， システム開発を実現するために，専門家による作り込 みの作業を極力減らすことを意図したものである． 企業のシステムにおいて，短時間にあまり労力をか けないで開発する動きも見られる[21]．変化するビジ ネス現場での要求に対して迅速に対応するために，短 時間で労力をかけない開発と保守へのニーズが高まっ ている．すなわち，基幹システムとExcel等での作 業の中間的なシステム構築が必要とされてきており， †2 経済産業省の平成 23 年度の情報処理実態調査[18] に おける「情報処理関係投資の状況」を見ても，300 人 以下の従業員企業に比べて，300∼1000 人の企業では 約 5 倍，1000 人以上では約 15 倍の投資があった．

INTER-Mediatorやあるいは直後に示す「関連ソフト との比較」で紹介したようなソフトウェアが登場する 契機ともなっている．ビジネス現場においてはExcel で作ったワークシートを複数の担当者にメールで送 り，それらが別々に更新されるような場面が多々あり [23]，かえって作業効率が低下する場合もある．また， Excelで蓄積したデータの活用は容易でないこともあ る[8]．そうした問題を解消するためにデータベース を使うきっかけとして，INTER-Mediatorの利用によ る業務の効率化が可能であると考える． INTER-Mediatorは一定以上の機能を持つバージョ ンのJavaScriptを想定しているため，Internet Ex-plorer Ver.7以前や，従来型の携帯電話等での利用は できない．一般的にはこれらのデバイスの利用率はす でに10%は下回っている†3_{が，対象ユーザーによって} 比率は大きく変わる．DOMモデルによるテンプレー ト処理のために検索エンジンによる内容の取り込み が行われないこともあり，不特定多数のアクセスが要 求されるようなWebサイトには向いていない．一方 で，業務ユーザーの場合にはSEOとは関係ないこと も多く，PCでの利用が中心で数年サイクルでの買い 替えが一般的とすれば，クライアント環境に対する問 題は少ないと言える．この点からも，本フレームワー クは業務システムを中心に利用されると想定できる． なお，宣言的な記述のみでは，フレームワークに 用意された機能を選択的に利用することが基本とな り，要件に対する細かな対応は難しくなる． INTER-Mediatorでは，データベースの応答や送信データを PHPによるプログラムで改変したり，クライアント サイドでのJavaScriptのプログラムで，ユーザー応 答やテンプレート処理後のページ上での処理を記述す ることができるようになっている．現在稼働している INTER-Mediatorを利用したシステムの1つは極めて 複雑な集計処理が要求されたものである．ユーザーの 操作に応じて集計結果がダイナミックに更新される ような仕組みはJavaScriptのプログラムで実現した．

†3 StatCounter Global Stats[11] では，2013 年 3 月で Internet Explorer 7 以下とその他を含めて全世界で 約 6.5%．ただし，「その他」の中でも利用可能な場合 もある． また，複雑な集計結果のレポートを出力する場合には サーバーサイドで集計処理プログラムを記述した． 5. 2 INTER-Mediatorを利用した開発 本論文で対象とした保守作業の前に，システム稼働 までの開発作業がある．こうした作業はエンジニアに よって行われることを想定している．開発における一 般的な手順としては，業務分析を元にデータベースの スキーマやアプリケーションが備えるべき機能が決定 され，実装し，テストするといった作業が発生する． INTER-Mediatorでも同様ではあるが，実装計画や実 装については特有の事情がある． 第3章で説明したように，INTER-Mediatorは宣言 的な記述でページ要素とデータベース内のテーブルの フィールドとが連動する．開発するアプリケーション の中で，この仕組みが利用できる箇所とできない箇所 を見つける．宣言的な記述だけではできない実装は， 例えば，特別なユーザーインターフェースが必要な箇 所や，データベースの応答を元に新たなデータが必 要な場合である．その場合，クライアントサイドでの JavaScript，サーバーサイドでのPHPによるプログ ラミングが可能である． アプリケーション開発においては，「後からプログ ラムでなんとかする」といったプランが立てられ，ス キーマをシンプルなもので構成するようなこともあ る．しかしながら，INTER-Mediatorの特徴を生かす には，宣言的な記述で処理可能な範囲を広げること でもあり，そのためにはリレーションシップを含むス キーマの定義の段階で，さまざまな機能を実現できる ようにすることが望ましい．例えば，あるフィールド の値に依存した選択肢を持つポップアップメニューを 作りたい場合を考える．手続き的なプログラミング ができる状況では，単にポップアップの選択肢のため のマスターの定義だけをスキーマとして記述し，そ のマスターから取り出した一連のデータをIF文等で 絞り込むような手法が取られる可能性もある．一方， INTER-Mediatorでは，関連するリレーションシップ を定義したコンテキストから選択肢が得られるため， そうしたポップアップメニューも宣言的な記述で構築 できる．そのとき，マスターテーブルが単に存在す

72 ることだけではなく，依存元のフィールドとのリレー ションシップを考慮する．そして，リレーションシッ プ自体は定義ファイルに記述する必要がある． JavaScript向けには多数のライブラリがあり，そ れらが混在することで同一名関数がそれぞれのライ ブラリに存在するような不具合も発生する． INTER-Mediatorでは識別子に他のライブラリで使っていな いようなものを使用し，他のライブラリとの混在を想 定した設計とした．INTER-Mediatorでは各種ライブ ラリとのインターフェースを取る仕組みも備えてい る．ライブラリをラッピングするオブジェクトを定義 し，決められた名前のセッタやゲッタ，初期化メソッ ドを実装することで，データベースと連携しての利用 もできる．moodle等でも利用されているHTMLエ ディタのTinyMCE[9]を使用した例をサンプルとし て製品に含めている． 5. 3 セキュリティ面への対策 INTER-Mediatorでのセキュリティに対する配慮は， 一般的なフレームワークと基本的には変わりない． SQLインジェクションを防ぐために，PDOが提供す るクォート処理を実装している．また，XSSに対処 するために既定の状態では，ページ合成ではテキスト はすべてテキストノードとして処理をする． ユーザー認証や認可の機能も持っており，CRUD の各操作およびレコード単位での認可の管理までで きる．認証や認可に関する設定はサーバー側でのみ評 価されるようになっており，クライアントからのアク セス等で変更することは一切できないようになって いる． INTER-Mediatorでは，クライアントからのリクエ ストをフレームワークが生成するため，ブラウザの セキュリティ対策が完全ではない場合，それと同等な 処理がHTMLの改変等によって行われる可能性もあ る．しかしながら，仮にできたとしても，認証・認可 の設定はクライアント側からのリクエストでは一切 変更ができないため，認可の設定によって排除するこ とができる．例えば読み出ししかしないテーブルへの 利用は，更新などの残りの処理は存在しないグループ にだけ権限を与えるといった手法で意図していないア クセスを排除できる． 誤入力への対策としては，テキストフィールドに 入力した値の検査機能を宣言的な記述で利用できる． ただし，条件記述では変数の仕組みを知っている必要 があり，JavaScriptのプログラム素片のような書き 方をする．複合的なフィールド検査はJavaScriptで プログラムを作成するなどの対処が必要になる． 5. 4 関連ソフトとの比較 INTER-Mediatorは宣言的な記述を用意することで データベースとの連動を行うが，同様な仕組みのフ レームワークにColdFusion(Adobe Systems)[13]が ある．ColdFusionではタグを拡張することで，繰り 返しや条件分岐を始めとして一般的なプログラミン グ言語に匹敵する機能を実現している．そのため，手 続き的なプログラミングと同様にアルゴリズムの記 述を正確に行う必要がある．INTER-Mediatorでは独 自タグは定義しておらず，HTMLの規約を外れない でページファイルを宣言的に記述できる． 手続き的なプログラミング言語を用いたMVCを 基調とするフレームワークでは開発が大規模になりが ちであり，シンプルな手法でエンドユーザーによる開 発を可能にする必要性も主張されている[4]．XForms やXQueryといった標準的なXMLの規格をベース にしたフレームワークXFormsDB[5]も開発されてい るが，INTER-Mediatorは最終的なHTMLページを テンプレート処理の基本とするため，より直接的な手 法と言える． データベースとWebアプリケーションの連携を容易 に行う開発ツールとしては，Microsoft VisualStudio LightSwitch[22]などがある．また，ASPサービスに ついてもサイボウズ社のKintone[14]がある．これら は，例えばフィールドをページ上にドラッグするなど してデータベースと連動する要素の配置ができるな ど，ツールによる利用を主体とした使い勝手のよさ が特徴となっている．これらのツールを用いた場合も INTER-Mediatorと同様に，手続き的なプログラムの 修正を行うことなしに一定範囲の保守は可能である． これらは総じて開発環境や動作環境が限定されるの に対し，INTER-Mediatorはオープンソースであり利

用者による活用の幅は広い．KintoneではAPIも提 供されているが，特にサーバーサイドでのプログラム を組み込める点ではINTER-Mediatorの方が拡張性 が高い． INTER-Mediatorは他のWebアプリケーションフ レームワークとは競合の関係にあるとも言えるが，一 方で協調的な稼働についても利用者の中で進められ ている．PHP言語の代表的なフレームワークである CakePHP[1]やCodeIgniter[2]を利用しつつ，ビュー の構築にINTER-Mediatorを利用する方法[19] [17]が 公開されている．

6 まとめ

INTER-Mediatorは，独自拡張のないHTMLで記 述するページファイルと，データベースとのやりとり を宣言的な手法で記述する定義ファイルを記述するこ とで，データベースの内容を読み書き可能なWebア プリケーションが構築できる．特に，開発後の改変作 業において，一般的なフレームワークに比べてエンド ユーザーやデザイナーによる改変が可能な範囲が広 く，保守のための予算が限られた現場でも業務の変化 に応じたシステム構築の継続を可能にする． 現在の業務システム開発では，さまざまなフレーム ワークが用いられているが，いずれも開発専門業者に よって構築が必要になる．さまざまな機能を組み込め る一方で，コストは高くなる傾向にある．一定規模以 上の予算がない場合にはシステム構築は難しい．その 結果，中小企業や部門の中でシステム化されない業務 が発生する．INTER-Mediatorを利用することで，シ ステム構築のためのコストの下限値を下げることが でき，業務の効率化に貢献できるものと考えられる． 参 考 文 献

[ 1 ] Cake Software Foundation, Inc.: CakePHP, http://cakephp.org/, 閲覧日: 2013/8/15.

[ 2 ] EllisLab, Inc.: CodeIgniter, http://ellislab.com/ codeigniter, 閲覧日: 2013/8/15.

[ 3 ] Ko, A. J., Myers, B. A. and Aung, H. H.: Six Learning Barriers in End-User Programming Sys-tems, in Proceedings of the 2004 IEEE Symposium on Visual Languages - Human Centric Computing, VLHCC ’04, Washington, DC, USA, IEEE Com-puter Society, 2004, pp. 199–206.

[ 4 ] Laine, M., Shestakov, D., Litvinova, E. and Vuorimaa, P.: Toward Unified Web Application Development, IT Professional, Vol. 13, No. 5(2011), pp. 30–36.

[ 5 ] Laine, M., Shestakov, D. and Vuorimaa, P.: XFormsDB: an extensible web application frame-work built upon declarative W3C standards, SIGAPP Appl. Comput. Rev., Vol. 12, No. 3(2012), pp. 37–50.

[ 6 ] Leff, A. and Rayfield, J. T.: Web-Application Development Using the Model/View/Controller De-sign Pattern, in Proceedings of the 5th IEEE Inter-national Conference on Enterprise Distributed Ob-ject Computing, EDOC ’01, Washington, DC, USA, IEEE Computer Society, 2001, pp. 118–127. [ 7 ] アンドリュー・マカフィー，エリック・ブリニュルフ

ソン (有賀裕子訳) : 全米上場企業四〇年間の調査が明ら かにする 競争力と IT 投資の知られざる力学 (Feature Articles 組織 IQ の経営), Diamond ハーバード・ビジ ネス・レビュー, Vol. 33, No. 9(2008), pp. 60–72. [ 8 ] McCallum, Q. E.: Bad Data Handbook:

Clean-ing Up The Data So You Can Get Back To Work, O’Reilly Media, 1st edition, 2012/11.

[ 9 ] Moxiecode Systems AB: TinyMCE, http://www. tinymce.com/, 閲覧日: 2013/8/11.

[10] Parr, T. J.: Enforcing strict model-view sepa-ration in template engines, in Proceedings of the 13th international conference on World Wide Web, WWW ’04, New York, NY, USA, ACM, 2004, pp. 224–233.

[11] StatCounter: StatCounter Global Stats, http:// gs.statcounter.com/.

[12] The PHP Group: PHP Data Objects, http:// php.net/manual/ja/book.pdo.php, 閲覧日: 2013/5 /18. [13] ア ド ビ シ ス テ ム ズ 株 式 会 社: Adobe Cold-Fusion 10 ファミ リ ー, http://www.adobe.com/jp /products/coldfusion-family.html, 閲覧日:2013/5/18. [14] サイボウズ株式会社: Kintone, https://kintone. cybozu. com/jp/, 閲覧日: 2013/5/18. [15] ファイ ル メ ー カ ー 株 式 会 社: FileMaker Server 12 製品概要, http://www.filemaker.co.jp/products/ filemaker-server/, 閲覧日: 2013/5/18. [16] F. ブッシュマン, H. ローネルト, M. スタル, R. ム ニエ, P. ゾンメルラード: ソフトウェアアーキテクチャ - ソフトウェア開発のためのパターン体系, 近代科学社, 2000/12. [17] 伊藤清徳: INTER-Mediator を CodeIgniter から使 って み る, http://agilmente.com/blog/2013/07/22/ inter-mediator with codeigniter/, 閲覧日: 2013/8/15. [18] 経済産業省: 情報処理実態調査 平成 23 年調査関係資 料, http://www.meti.go.jp/statistics/zyo/zyouhou/ result-2/h23jyojitsu.html. [19] 松 尾 篤: IMCake, https://github.com/matsuo/ IMCake, 閲覧日: 2013/8/15. [20] 新 居 雅 行: INTER-Mediator, http://inter-mediator.info/, 閲覧日: 2013/5/18. [21] 浅川直輝: 特集 「軽い」内製 : システム開発の常識が 変わる, 日経コンピュータ, No. 825(2013), pp. 44–51.

74

[22] 日本マイクロソフト株式会社: Microsoft Visual Stu-dio LightSwitch 2011, http://www.microsoft.com/ japan/visualstudio/lightswitch, 閲覧日: 2013/5/18. [23] 梅 田 弘 之: (ITPro 情 報 シ ス テ ム) プ ロ ジェク ト・マ ネ ー ジャの「 やって は い け な い 」［ 変 更 管 理 編 ］変 更 管 理 を Excel で やって は い け な い, http://itpro.nikkeibp.co.jp/article/COLUMN/ 20110921/369014/. 新 居 雅 行 フリーランスのエンジニアとして，シ ステム開発やコンサルティングに携 わる．トレーナーやライターとして も活動する．1987年，京都工芸繊維 大学大学院修了．2012年，トップエスイー修了．現 在，電気通信大学大学院後期博士課程に在学中．慶応 義塾大学文学部非常勤講師．著書に「リレーションで 極めるFileMaker」「OS Xシステム管理」など． 鄭   顕 志 1980年生．2003年早稲田大学理工学 部情報学科卒．2008年同大学大学院 理工学研究科情報・ネットワーク専 攻博士課程修了．2006年早稲田大学 理工学部助手．2007年早稲田大学基幹理工学部助手． 2008年早稲田大学メディアネットワークセンター助 教．2010年国立情報学研究所アーキテクチャ科学研 究系助教，現在に至る．博士(工学)(早稲田大学)．自 己適応ソフトウェア，無線センサネットワーク，ソフ トウェア工学の研究に従事． 石 川 冬 樹 2007年東京大学大学院情報理工学研 究科コンピュータ科学専攻博士課程 修了．博士(情報理工学)．現在，国 立情報学研究所コンテンツ科学研究 系准教授．電気通信大学大学院情報システム学研究 科客員准教授併任．ソフトウェア工学，サービスコン ピューティングの研究に従事．