評価・考察

68 / 116 ビューでのフォームのタイプがpasswordになる。

(viii)見出しは，'title'または'name'のカラム名はリスト表示などでの見出しに使用される

（modelのdisplayFieldの設定が無い場合）。

(ix)名前の変換は，Inflector クラスを使用して命名規則に従った名前に変換できる。

$newName = Inflector::camelize($name);

⑥ JavaScriptライブラリの実装 JavaScriptライブラリには，jQueryを採用した。Query による非同期なデータ転送には，JSON形式を採用し，jQueryライブラリである「FlexiGrid」

を使用してレコードの一覧表を表示するIndex処理を実現した。PCとスマートフォン用の Controller部のメソッドとして，それぞれ「json_index()」「smart_json_index()」を追加した。

JSON形式のデータを生成するためにPCとスマートフォン用のView部の画面として，そ れぞれ「json_index.ctp」と「smart_json_index.ctp」を追加した。また，「View」「Add」「Edit」

「Delete」処理においては，非同期なデータ転送を使用するために，jQueryライブラリであ る「Dialog」を使用して実現した。

3.3.1.5 評価・考察

69 / 116

発する必要があったが，フレームワークに機能を追加することによるScaffold機能を利用 することで，View部のアプリケーションのコード削減が実現できた。

(ii) Controller クラスの作成 Controller クラスの作成は，データベースの表単位に

CRUD処理（index, view, add, edit, delete）のメソッドの記述をする必要があった。

これらのControllerクラスは，データベースの表のスキーマの定義に依存するために，「デ

ータベースの表の種類×端末の種類」の数だけ開発する必要があったが，フレームワーク に機能を追加することで，Controller部のアプリケーションのコード削減が実現できた。

③ 多様なスマートデバイスへの対応

多様なスマートデバイスの画面に対応するソフトウェアの自動生成として，アプリケーシ

(a) 障害受付 (b)ドキュメント

図3.23 サンプル画面

表3.3 アプリケーションコードの行数比較 単位：行

保守支援システム 自動生成の場合 手組みの場合 機能（a ～ f ） Model View Controlle

r

Model View Controlle (a) 顧客システム情報 110 0 240 110 1300 r 1050 (b) システム詳細情報 260 0 350 260 1780 1460 (c) 障害・修理履歴 120 0 200 120 1590 1100 (d) 作業手順 (交換など) 260 0 310 260 2120 2420 (e) パラメータ設定手順 300 0 400 300 2280 2560 (f) 報告書作成 100 0 110 100 1380 1200 Web アプリ合計（*） 1150 0 1610 1150 10450 9790

拡張クラス開発 0 800 1500 0 0 0

拡張ライブラリ開発 0 1500 400 0 0 0 拡張部開発合計（**） 0 2300 1900 0 0 0 合計（*＋**） 1150 2300 3510 1150 10450 9790

70 / 116

ョンに応じてユーザが定義した画面と，サーバサイドから送信されるJSONデータにより，

JSONデータに含まれる画面IDと画面表示やボタンなどの項目により，スマートデバイス の画面サイズに適した画面を表示することができた。図 3.23 に画面サンプルを示す。図

3.23(a) は顧客からの障害受付画面であり，図3.23(b)は，技術情報検索画面である。PCに

表示するような画面をそのままスマートフォンなどに表示すると，縦も横もスクロールす る必要が生じてしまい，操作性が悪くなる。横方向を画面サイズに合わせることにより，

縦のスクロールのみで操作が可能となった。また，標準に装備されているブラウザでは画 面切替が3タッチかかるのに対して，以前のシステムでは，スマートデバイス上にアプリ ケーションを開発してワンタッチできるようになっていた。本方式では，さらにこれをカ スタムブラウザを開発することで，画面切替をワンタッチでできるよう操作性を向上させ た。スマートデバイスによって操作ボタンなどが異なる場合にも，それを吸収することが 可能となった。このように，スマートデバイスの機種に依存して，サーバのWebアプリケ ーションをカスタマイズする必要がなくなった。この方法は，カスタムブラウザの開発を 伴うが，いったん開発しておけばユーザが画面を定義することで再利用可能なことと，表 示に係わる属性情報をサーバ側で作成しないので，サーバ側の View の自動生成が容易に なるという効果があった。

(2) 考察

①対象システムと生産性評価について

今回評価の対象とした保守業務支援アプリケーションは，オフィス内で伝票を大量に入 力するような業務アプリケーションとは異なり，保守技術者が移動先でスマートデバイス を使って簡単な操作で使えることが狙いである。但し，保守センターの管理者は同様の画 面をPCを使ったり，指示を与えたりするので，PCとスマートデバイスを両方使用するシ ステムで，操作性や多様な端末に対応可能にする必要があるシステムであった。このよう な点から，本提案方式の評価対象として妥当であったと考える。本手法で開発したことに より，複数のメーカのスマートフォンやタブレットの対応を個別に開発することなく，そ れぞれのスマートデバイスから利用できるWebアプリケーションシステムを実現できた。

評価に示したように，開発プログラムコードの行数比較において，提案方式は生産性向上 に有効な方式であると言える。実現しようとするアプリケーションによって，クラスやラ イブラリの拡張を必要とするが，同様のアプリケーションであれば，拡張部分を再利用で きる点も，生産性向上の点から有効であった。自動生成後のプログラムコードの追加･変更 を極力少なくするということについては，自動生成を使用せずにコーディングするのに対 して，１／５程度のコーディング量になった。

②端末の多様性に対する解決策について

スマートデバイスにおいてもHTMLとjQuery Mobile などのJavaScriptを活用すること で，スマートデバイスの多様性を解決する手法があるが，提案のカスタムブラウザによる 方式は，スマートデバイス固有の機能を作りこめるという点，JSON データ送受信により

71 / 116

伝送データ量の削減と，画面生成の自由度が向上し，サーバ側でのHTMLデータ生成も不 要となるなどのメリットがあった。さらに，他のスマートデバイス・アプリケーションと のタブ操作による切替が可能となるというメリットもあった。

③多対多の表の定義と自動生成について

多対多の関係性を持つデータは，たとえば，よく題材で出てくる「レシピは複数の材料 を使い，材料は複数のレシピで使われる」のほか，販売管理の例では「顧客は複数の商品 を注文する。商品は複数の顧客から注文される」，生産管理の例では「製品は複数の部品か ら構成される。部品は複数の製品で使われる」など，一般的な概念としてよくある関係で ある。この多対多という概念モデルを，論理モデルにするときに中間に新しいエンティテ ィを追加し，多対1，1対多の関係にした。データベースの実装はMySQLを使ってRDB で行ったが，RDBを使って直接SQL文でプログラムを書くのではなく，MVC方式のオブ ジェクト指向プログラミングでプログラムを実現しており，プログラマからは直接SQLは 見えず，データベースへのアクセスはフレームワークに内蔵するO/Rマッパが，RDBへの マッピング処理を行う。使用したActive RecordsのようなO/Rマッパーには，テーブルと オブジェクトの1対1対応にとどまらず，オブジェクトの多対多関係など，リレーショナ ル・モデルでは直接表現できないモデルについてもサポートするものがあるが，多対多の ままだとViewを自動生成できないほか，joinテーブルが隠蔽されるため，障害発生時の原 因追及が困難などの問題もある。提案の方式は，model の定義方法により，多対１と１対 多の関係にすることで，ViewやControllerの自動生成と，障害時の原因追及を容易にした。

④保守性について

自動生成することでプログラムの処理内容が見えにくくなるため，不具合が発生したと きにどこをどう修正すればよいのかがわかりにくくなるという問題は想定されたが，クラ スの拡張機能を明確にして，ソースにもその仕様をコメントとして入れることにより可読 性がよくなり保守性の点で改善された。拡張フレームワークを理解していることは必要で あり，可読性を高めるコメントは有効ではあったが，保守性向上の仕組みという点は，今 後の課題である。ただし，いったん理解できれば，アプリケーション独自のコード量が少 ないため，原因の絞込みは早くできるようになった。

⑤今後の課題

本方式による自動生成方式は，アプリケーションが必要とする機能をフレームワークの 提供機能を拡張することで，自動生成後のプログラム追加を減らすことに成功している。

したがって，この拡張をアプリケーションごとに増やしていくことで蓄積ができ，さらに 生産性を高めることができると考える。したがって，今後開発するシステムでも検証して いきたい。