既存ウインドウ情報の解析による
一貫性を持った GUI 自動生成に関する研究
2012 年 1 月 31 日 ( 火 ) 提出
指導：深澤 良彰 教授
早稲田大学大学院 基幹理工学研究科 情報理工学専攻 学籍番号： 5110B066-0
白井 盛太郎
第1章 はじめに 1
第2章 ユーザビリティ 2
2.1 ユーザビリティとは . . . 2
2.2 一貫性. . . 2
2.2.1 一貫性によるユーザのメリット . . . 3
2.2.2 一貫性によるベンダのメリット . . . 3
2.3 ガイドライン . . . 3
第3章 本手法の特徴 5 3.1 レイアウトルールの発見 . . . 5
3.1.1 レイアウトルール . . . 5
3.2 レイアウトルールを適用した新しいウインドウの生成 . . . 8
第4章 本研究で用いる技術 10 4.1 アスペクト指向技術 . . . 10
4.1.1 アスペクト指向とは . . . 10
4.1.2 AspectJ . . . 10
4.2 コンパイラ・コンパイラ . . . 13
4.2.1 構文解析 . . . 13
4.2.2 字句解析 . . . 13
4.2.3 JavaCC . . . 14
第5章 本手法の手順 15 5.1 ソースコードの構文解析とAspectJファイルの生成 . . . 15
5.1.1 JavaParserによるAspectJファイル作成 . . . 16
5.1.2 AspectJファイルの織り込みによるGUI情報抽出 . . . 17
5.2 レイアウトルールの解析 . . . 20
5.2.1 レイアウトに関する追加情報の分析 . . . 22
5.2.2 各種レイアウト情報を基準にしたウィジェットのグループ化 23 5.2.3 位置ルールの解析 . . . 26
5.2.4 組み合わせルールの解析 . . . 26
5.3 新規開発ウインドウの自動レイアウト . . . 29
6.2 システムの適用実験 . . . 32
6.2.1 実験内容 . . . 32
6.2.2 実験結果 . . . 34
6.3 考察 . . . 34
第7章 関連研究 37 7.1 対応するルールからGUIをレイアウトする研究 . . . 37
7.2 ユーザの選択に基づいたGUIを生成する研究 . . . 38
7.3 既存のGUIソースコードを再利用する研究 . . . 39
第8章 おわりに 40
謝辞 41
参考文献 42
研究業績 44
第 1 章 はじめに
現在，多くのソフトウェアがGUI（Graphical User Interface）を備えている．従 来のCLI（Command Line Interface）に比べ，コンピュータへ直感的な操作で命令 をすることができるようになり，専門家以外のユーザが増加する一因となってい る．それゆえ，多種多様な業務がコンピュータ化されており，ソフトウェアには 業務内容に対応した多くの機能が実装されている．その一方で，機能を増やすこ とで，多くの場合，対応するGUIを開発する手間も増える．
また，近年では，コンシューマ向けのアプリケーションソフトウェアにおいて も，ひとつのソフトウェアに様々な機能が存在することは少なくなく，それに伴 い多くのGUIを備えたものは珍しくない．
GUI開発において，ボタンなどのオブジェクトを意図無く並べるだけでは，ユー ザにとって使いやすいものが作れることはきわめて稀であり，通常は，ソフトウェ アの使いやすさを意味する“ユーザビリティ”を考慮してGUIの設計をする必要が ある．
高いユーザビリティを持ったソフトウェアを設計する上で考慮すべき要素の一 つに“一貫性”がある．ひとつのソフトウェアにおいて，GUIオブジェクトの大き さや位置などを統一することであるが，GUIが増えれば増えるほど，この一貫性 を保つことが難しくなり，開発者への負担も増加する．
本研究では，一貫性をもったソフトウェアを開発するうえでの問題点に着目し，
ソフトウェアの開発済みGUIからGUIレイアウトに関するルールを解析し，残り のGUIをルールに沿って自動生成する手法を提案する．この手法より，GUI開発 の負担軽減と，機械による一貫性の保証を目指す．
第 2 章 ユーザビリティ
本章では，ソフトウェアの使いやすさを意味する“ユーザビリティ”について説明 する．ユーザビリティの定義はひとつに確立しておらす，認知度の高いものとして，
ISOで国際規格として定義されているISO9241-11と，ユーザビリティの権威であ るヤコブ・ニールセンが定義したものが存在する．本章では，以降，ISO9241-11 で定義されたものをユーザビリティとして説明していく．
2.1 ユーザビリティとは
ISO 9241-11では，ユーザビリティを「ある製品が，指定された利用者によって，
指定された利用の状況下で，指定された目的を達成するために用いられる際の，有 効さ，効率及び利用者の満足度の度合い」として定義されている．各要素の具体 的な定義は以下の通りである．
有効さ（Effectiveness）
ユーザが，指定された目標を達成する上での正確さと完全さ 効率（Efficiency）
ユーザが，目標を達成する際に正確さと完全さに費やした資源 満足度（Satisfaction）
不快さのないこと，および製品使用に対しての肯定的な態度
2.2 一貫性
一貫性とは，ひとつのソフトウェア製品で様々なモジュールを通じて，概観，使用 感，振る舞いが似ているとうことである．また，一貫性を持たせる範囲は，Microsoft OfficeやAdobe Creative Suiteなどのソフトウェアスイートに含まれるソフトウェ アや，同一プラットフォーム上で動作するすべてのソフトウェアに拡張されるこ ともある．ソフトウェアに一貫性を持たせることにより，ユーザやベンダにとって 以下の利点があるとヤコブ・ニールセンは著書『ユーザビリティエンジニアリン グ原論』[1]で述べている．
2.2.1 一貫性によるユーザのメリット
ソフトウェアのある部分で学習した技能を，別な部分で同様の操作をする際に そのまま活用することができる．また，一貫性がとれていれば，初めて利用する 操作でも動作を予測することができる．これにより，学習効率が向上し，ソフト ウェア全体のトレーニングコストが軽減される．
2.2.2 一貫性によるベンダのメリット
一貫性を持たせるための標準を社内で決定することにより，ソフトウェアを開発 する際の基盤ができあがる．規格外れの新製品であれば，標準をもとに調整され，
企業の製品はある統制のとれたルールに従い進化していく．標準が存在すること で，デザイナやプログラマの活動に関しても作業コストやミーティング時間の軽 減につながる．また，一貫性を持ったソフトウェアは使いやすく，市場での競争力 が増加する．MicrosoftやAppleなどのOSを開発・販売している企業は，社内製 品だけではなく，OS上で動くサードパーティのソフトウェアにも一貫性を持った 開発を促したいために，OSのユーザインターフェース標準を文書化したユーザー インターフェースガイドラインを提供している．
2.3 ガイドライン
前述のとおり，MicrosoftはWindowsユーザー エクスペリエンス ガイドライン [2]，AppleはMac OS X Human Interface Guidelines[3]として開発者向けにガイド ラインを公開している．
ガイドラインは，OSにおけるGUI開発において，非常に参考になる文書である が，実際の開発においてはガイドラインに従うだけでは良いGUI設計ができない 場合が存在する．
例えば，ガイドラインでは見た目や配置を強調して指示する傾向にあるが，振る 舞いや高水準から見た論理的組織構造についてはほとんど言及されてない．ガイ ドラインはあくまでも一般的な標準を提示する手段であり，ガイドラインから逸 脱したGUIレイアウトの方が多くのユーザにとって使いやすいものであれば，そ れを採用する方が良い[4]．
また，OSのバージョンアップにより，レイアウト方法の変換や，新しいGUIオ ブジェクトの登場した場合，ガイドラインが更新される．Windowsにおいては，リ ボンとよばれるGUIオブジェクトの登場により，自社製品であるOfficeアプリケー ションのGUIが大幅に変更された．AppleはMac OS 9からMac OS Xにかけて，
ビジュアルを根本的に切り替えた．ガイドラインの変更にあわせて，開発者には GUIの再設計や再調整をする必要が生まれる．
他にも，ガイドラインは，Windowsユーザー エクスペリエンス ガイドラインが PDFファイルで956ページと，膨大な量があり，すべてを把握し，開発するGUI に的確に織り込むことは難しいことも問題点としてあげられる．
第 3 章 本手法の特徴
3.1 レイアウトルールの発見
本研究では，ソフトウェアの開発済み部分のGUIソースコードを解析し，複数 のウインドウ間で共通して用いられているレイアウトに関するルールを発見する．
あるソフトウェアのGUIから生成したレイアウトルールは，残りのGUIを開発 する適用させることで，ルールに従ってレイアウトできる．プラットフォームや 社内のレイアウトガイドラインに沿って統一されたGUIを持つソフトウェアから は，適用することでガイドラインに沿って自動レイアウトされるレイアウトルー ルが作成される．そのため，新しく開発するウインドウにもガイドラインに沿っ たレイアウトが容易に適用できる．
また，一度ルールを生成すれば，新しく開発するソフトウェアのGUIにも適用 させることが可能であり，ベンダー内でソフトウェアのウインドウレイアウトに 一貫性を持たせる際にも活用できる．
3.1.1 レイアウトルール
発見するレイアウトに関するルールを，本研究ではルールの性質により位置ルー ルと組み合わせルールの2種類に分けて定義している．
位置ルール
各ウインドウでの配置位置がある程度統一されているウィジェットに対するルー ルを位置ルールとして定義する．ウインドウ最下部のボタンを例に挙げると，こ れらのボタンはウインドウでの項目の入力・編集・削除などの処理を行った後，そ の処理を決定（あるいはキャンセル）する命令を下す役割を持つことが多く，レ イアウトされる位置や並び方もひとつのソフトウェアの中で統一されていること が多い．また，これらのウィジェットは，同じ内容のラベルを持ったものが多い．
実際に，Mac OS XとWindows上で動く様々な種類の代表的な28種類のアプリ
ケーションにおける209ウインドウにおいて，最下部に位置するボタンのラベル に調査した結果を表3.1に示す．
表3.1より，ラベル名を基準とした解析でルールを発見できる可能性が高く，発
表3.1: ウインドウ最下部ボタンのラベル出現回数と出現率 ラベル名 出現回数 出現率
キャンセル 178 85%
OK 124 59%
ヘルプ 37 18%
次へ 21 10%
閉じる 17 8%
戻る 10 5%
完了 9 4%
前へ 7 3%
組み合わせルール
複数のウィジェットが，何らかの意図を持って組み合わせられレイアウトされて いる部分を対象としたルールである．
位置ルールの場合と同様に，25種のアプリケーションを調査した結果，大きく 分けて以下の4つの代表的なウィジェットの組み合わせが確認できた．また，調査 結果を表3.2に示す．
•囲みつきウィジェット群
複数のウィジェットを囲んでグループ化させる方法．
図3.1において，“デフォルトのコマンド”というテキストの付いた枠でウィ ジェットを囲っている．
図3.1: 囲みつきウィジェット群の例
•個別説明ラベル付きウィジェット
テキストフィールドやプルダウンメニューなど，入力や選択をするウィジェッ トの説明にラベルを用いる方法．
図3.2において，左側のラベルが右側のウィジェットの説明をする役割を担っ ている．
図3.2: 個別説明ラベル付きウィジェットの例
•グループ説明ラベル付きウィジェット群
あるウィジェットのまとまり全体の説明に，ひとつだけラベルを用いる方法．
図3.3において，右側の複数のウィジェットを左側のラベルがまとめて説明 している．
図3.3: グループ説明ラベル付きウィジェット群の例
•子要素つきウィジェット
る子オブジェクトを用いる方法．
図3.4において，親チェックボックスにチェックが入っている場合のみ利用可 能なチェックボックスで，より詳しい設定を行うことができる．
図3.4: 子要素付きウィジェットの例
表3.2: ウィジェットの組み合わせの出現回数と出現率 組み合わせの種類 出現回数 出現率 囲みつきウィジェット群 10 40%
個別説明ラベル付きウィジェット 25 100%
グループ説明ラベル付きウィジェット群 15 60%
子要素つきウィジェット 13 52%
3.2 レイアウトルールを適用した新しいウインドウの生 成
開発者が未開発ウインドウに配置する項目のリストを入力することで，開発済 みGUIから取得したレイアウトルールと比較され，ルールが存在するウィジェッ トに関して自動的にレイアウトを行い，ソースコードが生成される．
GUIレイアウトの支援ツールとしては，開発者にGUIをコーディングではなく 視覚的にレイアウトさせ，GUIのソースコードを生成するソフトウェアも存在す るが，そういったソフトウェアでレイアウトを統一するためにサポートしている のは，ウィジェット同士の間隔の調整などであり，開発者はGUI全体でのレイア ウト統一に関して依然として注意を払う必要がある．
本研究では，新しく開発するウインドウすべてにレイアウトを統一するよう調 整したソースコードを生成することができ，開発者GUIのレイアウト統一に関し て注意を払うことなくGUIの開発を進めることが可能になる．
第 4 章 本研究で用いる技術
4.1 アスペクト指向技術
4.1.1 アスペクト指向とは
各プログラム（モジュール）から共通に使われる機能を独立させ，さまざまなモ ジュールから横断的に利用する技術である．独立させた機能はアスペクト（Aspect） と呼ばれる．また，アスペクトを各モジュールに埋め込むことをウィーブ（織り 込み）と言う．
アスペクト指向の利用例として，ログ管理が挙げられる．あるアプリケーショ ンにおいて，あるメソッドが呼び出されるたびにログを出力させたいとする．ア スペクト指向を用いない場合，一般的には対象となるメソッドないにログを出力 させる記述を追加するであろう．ログ出力はメソッド本来の機能とは関係ない非 機能要求であるため，メソッド内に機能要求と非機能要求が混在してしまう．ま た，ログの出力処理を変更するたび，対象となるメソッドで修正する必要がでて くる．さらに他のメソッドでもログ出力させていた場合，変更箇所が膨大になっ てしまう．
一方アスペクト指向を用いた場合，呼び出されるポイントを指定することがで き，このような場合ならば対象となるメソッドの呼び出し時にウィーブされるロ グを出力するアスペクトを1つ用意すれば実現可能になる．また，ログの出力処 理を変更する際もアスペクトを変更するだけでよい．
4.1.2 AspectJ
AspectJ[5][6]は数あるアスペクト指向プログラミングのなかでもJava言語を対
象にアスペクト指向プログラミングを実装する技術である．
ここでは本研究で用いているAspectJの基本的な機能を説明し，簡単なサンプル コードを示す．
アスペクト（Aspect）
ジョインポイントとアドバイスの組み合わせを指定するモジュール単位のこと．
1つのアスペクト内に複数のポイントカットとアドバイスが指定できる．
ジョインポイント（JoinPoint）
実行時にアドバイスの実行を割り込ませることが可能なコード上の位置を示す．
割り込み位置は任意の場所を指定できるわけではなく，メソッドやコンストラ クタの呼び出し位置・実行位置やインスタンスの初期化位置など，プログラマに とって意味のあるいくつかの位置に限定されている．
ポイントカット（Pointcut）
条件を指定することでプログラム中のすべてのジョインポイント集合から得ら れる部分集合を選択する．
ポイントカットには，AspectJがあらかじめ用意しているプリミティブポイント
カットとpointcut句を用いてプリミティブポイントカットを組み合わせたものに名
前を付けた名前付きポイントカットの2つに大きく分けられる．
アドバイス（Advice）
任意のJavaスレッドによるプログラムの実行が，指定するポイントカットによっ て選択させるジョインポイントにさしかかった時に実行されるコードのこと．実 行するタイミングは以下の5通りである．
• ジョインポイントの事前 – before句によって指定
• ジョインポイントの事後 – after句によって指定
• ジョインポイントの戻り値を伴う事後 – after returning句によって指定
• ジョインポイントの例外を伴う事後 – after throwing句によって指定
• ジョインポイントのその時点 – around句によって指定
public class HelloWorld { public void hello(){
System.out.println("Hello World");
}
public static void main(String[] args) { (new HelloWorld()).hello();
} }
図4.1: アスペクトを織り込ませる対象HelloWorld.java
public aspect Trace {
public pointcut atHello() : call(void HelloWorld.hello());
before() : atHello() {
System.out.println("Before");
}
after() : atHello() {
System.out.println("After");
} }
図4.2: 織り込ませるアスペクトTracer.aj
サンプルコード
まず，アスペクトを織り込ませる対象のソースコードを図4.1として示す．
また，このファイルにウィーブさせるAspectJファイルを図4.2として示す．
アスペクト側では，まずジョインポイントを指定している．図4.2におけるpoint- cut句では，atHelloという名前のジョインポイントをHelloWorldクラスのhelloメ ソッドが呼び出された時点として宣言している．
次に続くbefore句から始まる部分では，atHelloで指定したジョインポイントの
事前に，波括弧で囲まれた部分の処理をアドバイスとして実行させるものである．
一方，after句から始まる部分ではatHelloで指定したジョインポイントの事後にア
ドバイスを実行させている．
最後に，アスペクトをウィーブして実行した結果を図4.3として示す．
Before Hello World After
図4.3: アスペクトを織り込ませた後の実行結果
4.2 コンパイラ・コンパイラ
4.2.1 構文解析
構文解析（syntax analysis）とは，コンパイラ技術で使われる言葉であり，単語 の並びを解析することである．
“I met him”という文を例にとってみる．構文解析器では，最初に入力された単
語がIで，その次にmetが入力され，最後にhimが入力されたことで，正しい順番 の英文だと判断する．
構文解析を行うプログラムのことを構文解析器（syntax analyzer）あるいはパー ザ（parser）と呼ぶ．
4.2.2 字句解析
字句解析（lexical analysis）とは，コンパイラ技術で使用される言葉であり，文 法を構成する意味のある最小単位を識別する処理である．
先ほどの例において，I, met, himのそれぞれが英文においての意味のある最小 単位とされる．また，これらは，Iは主語，metは動詞，himは目的語といった具 合に分別することも可能である．
字句解析を行うプログラムのことを字句解析器（lexical analyzer）あるいはス キャナー（scanner）と呼ぶ．
また，後述するJavaCCにおいてはこの最小単位がトークン（token）と呼ばれ ており，字句解析器をトークンマネージャ（token manager）と呼んでいる．
4.2.3 JavaCC
JavaCC[7]は，構文解析と字句解析を実行するJavaプログラムを作成するプロ
グラムジェネレータである．
トークンおよび構文の定義の記述に加え，オプションの指定，生成されるパー ザの構成の指定をした計3つの部分からなる入力をもとに構文解析器を生成する．
また，コンパイラの構成要素であるパーザやトークンマネージャを作成するた めの言語を解析・提供するプログラムであるため，JavaCCはコンパイラ・コンパ イラ（コンパイラを作るためのコンパイラ）と呼ばれている．
本研究では，JavaCCに付属するJava言語用の入力ファイルをもとに作成された，
構文・字句解析のみを行う構文解析器（JavaParser）を改良し，独自のメソッドを 挿入してシステムに用いている．
第 5 章 本手法の手順
本手法のシステム構成を図5.1に示す．本手法は，現段階ではJava言語のGUI を構築するためのツールキットであるSwingを使って作成されたGUIを対象とし ている．
開発済み ソースプログ
ラム
構文解析器
抽出用プログラム
GUI情報 ルール解析部
レイアウト ルール
ウインドウ生成部
ウインドウ 新規 本システム
レイアウト情報 抽出機能付きプ
ログラム 開発者
ウィジェットの種類 を入力
図5.1: 本手法のシステム構成
5.1 ソースコードの構文解析と AspectJ ファイルの生成
本手法では，まずJavaCCを用いて作成したJavaの構文解析器（JavaParser）に 変更を加えたプログラムを用い，構文解析した各Javaソースコードに特化したレ イアウト情報を出力するためのAspectJプログラムを自動生成する．
JavaParserとAspectJの2つを用いることにより，以下のような利点がある．
• JavaParserでソースコードを解析することにより，ソースコード内の各ウィ
ジェットにウィジェットIDを割り当てることができる．
• 実行時では抽出できない情報はJavaParserによるソースコードの構文解析時 に，実行時でなれければ抽出できない情報はAspecetJによる情報抽出用プロ
グラムにより実行時に，といった具合に，情報の特性に合わせて抽出のタイ ミングを2段階に分けることができる．
• AspectJを用いることにより，ソースコードを改変することなく情報を抽出
することができる．
5.1.1 JavaParser による AspectJ ファイル作成
JavaCCを用いて作成したJavaParserは，Javaの文法に特化してソースコードを トークンに分ける機能を持っている．JavaParserは，そのままでは単語に分解する 処理をするだけの構文解析器であるが，ソースコードに変更を加えることにより，
トークンの種類に対応した機能を付け加えることが可能である．本手法で加えた 変更を以下に示す．
インスタンス変数“token”
JavaParserが構文解析する際に，最新1個のトークンを保持している変数．本
手法では，最新10個までのトークンを保持するよう変更．
PackageDeclarationメソッド
JavaParserが構文解析対象のJavaソースコード中のパッケージ記述をトーク
ン化した際に呼び出される．本手法では，PackageDeclarationメソッド呼び 出し直後のtokenの値を参照し，パッケージ情報を保持する．
VariableDeclaratorIdメソッド
ソースコード中で変数の定義をトークン化した際に呼び出される．本手法で は，変数名と変数の型を参照し，型が抽出対象のGUIウィジェットと一致す る場合，変数名と型の組み合わせを保持する．
構文解析後の処理
構文解析後，クラス名・保持されたパッケージや変数の情報を利用し，解析 対象のソースコードに特化したGUI情報抽出用AspectJプログラムファイル を出力する．
GUIウィジェットの情報の多くは，生成されたAspectJプログラムを利用して抽 出されるが，この段階で以下の情報を抽出する．
• ウィジェットの変数名
• ウィジェットの変数の型
変数名は，ソースコード上でしか意味を持たず，コンパイルして実行する際に は抽出できない情報になってしまうため，この段階で変数の型と合わせて抽出し ている．また，各ウィジェットに識別子（ウィジェットID）を割り当てている．
また，JavaParserによるAspectJプログラムを生成する対象となる変数の型（す
なわち，本手法におけるルールの解析対象となる変数の型）は以下の7項目であ り，図5.2に例を示す．
• JButton（ボタン）
• JLabel（ラベル）
• JTextField（テキストフィールド）
• JCheckBox（チェックボックス）
• JRadioButton（ラジオボタン）
• JComboBox（コンボボックス）
• JPanel（パネル）
図5.2: ルール解析対象のウィジェット
5.1.2 AspectJ ファイルの織り込みによる GUI 情報抽出
第5.1.1項で出力したAspectJプログラムファイルを，構文解析対象である元の
Javaソースコードに織り込ませて実行することで，GUI情報を抽出する．
また，この段階で抽出する情報が以下の通りである．抽出の例を図5.3に示す．
• ウインドウのサイズ（幅，高さ）
• ウィジェットの位置（x座標，y座標）
• ウィジェットのサイズ（幅，高さ）
• ウィジェットのテキスト情報
• ウィジェットの親ウィジェットID
ウインドウの幅
ウインドウの高さ
x座標
y座標
親ウィジェットID
テキスト 幅
高さ
図5.3: “OK”ボタンに対する情報抽出の例
AspectJプログラムは，ソースコード中の各ウィジェットの変数が定義された直
後に織り込ませる部分と，ウインドウが描写された直後に織り込ませる部分の2 部に分かれている．図5.4に抽出の全体的な流れを示し，以下で各部分のサンプル コードと，詳細を説明する．
ウィジェット変数定義直後の処理 図5.5にサンプルコードを示す．
JavaParserでの構文解析時に発見されたGUIウィジェットごとに，アドバイスを
生成している．アドバイスでは，各ウィジェットが変数として定義された際に，ウィ ジェットに対応した情報記録用のオブジェクトを作成し，情報を一旦保持するマッ プオブジェクトに格納しておく．
ウィジェット変数!
定義後の処理 ウインドウ!
描写後の処理
ソースプログラム
ウィジェットAの!
インスタンス生成 ウィジェットBの!
インスタンス生成 ウインドウ描写
ウィーブ ウィーブ
ウィジェットAの! 情報を格納した!
オブジェクト!
ウィジェットBの! 情報を格納した!
オブジェクト!
オブジェクトを保持する! マップ
作成 作成
情報追加 情報追加
登録 登録
出力命令
XML出力 ウィーブ
情報抽出用AspectJプログラム
図5.4: AspectJによる情報抽出の流れ
...
after(): set(JButton okButton) {
Object[] a = thisJoinPoint.getArgs();
JComponent c = (JComponent) a[0];
GuiObj o = new JButtonObj("okButton");
guiObjMap_.put(c, o);
}
after(): set(JLabel nameLabel) {
Object[] a = thisJoinPoint.getArgs();
JComponent c = (JComponent) a[0];
GuiObj o = new JLabelObj("nameLabel");
guiObjMap_.put(c, o);
} ...
図5.5: ウィジェット変数定義直後の処理
...
after(WindowA w): call(void *.setVisible(boolean)) && target(w) { windowX_ = w.getX();
windowY_ = w.getY();
windowWidth_ = w.getWidth();
windowHeight_ = w.getHeight();
windowTitle_ = w.getTitle();
GuiObj o = new JFrameObj();
o.setX(windowX_);
o.setY(windowY_);
o.setWidth(windowWidth_);
o.setHeight(windowHeight_);
o.setText(new String[]{windowTitle_});
Container cnt = w.getContentPane();
guiObjMap_ = putWidInfo(guiObjMap_, cnt);
Document xml = makeXML(guiObjMap_, o);
} ...
図5.6: ウインドウ描写直後の処理 ウインドウ描写直後の処理
図5.6にサンプルコードを示す．
Swingにおいて，ウインドウを描写させるsetVisibleメソッドが呼ばれた直後に
呼び出され，ウインドウの情報を抽出する．その後，情報を保持するマップオブ ジェクトに格納されているすべてのウィジェットに対し，本項の冒頭で述べたレイ アウトに関する情報を別途用意したメソッドで抽出する．すべての抽出が終わっ た後，抽出した情報をXMLファイルとして出力する．
実際にGUI情報として出力されるXMLファイルファイルを図5.7に示す．
5.2 レイアウトルールの解析
節5.1.2項で抽出した情報を利用し，レイアウトルールの解析を行う．本手法の
レイアウトルールの解析の流れを図5.8に示す．
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<WindowA height="370" width="625" x="328" y="224">
...
<JButton height="29" parentObj="buttonPanel" text="完了"
varName="doneButton" width="75" x="526" y="317"/>
<JPanel height="43" parentObj="jPanel1" text="null"
varName="buttonPanel" width="625" x="1" y="327"/>
<JLabel height="29" parentObj="jPanel2" text="名前:"
varName="nameLabel" width="83" x="24" y="24"/>
...
</WindowA>
図5.7: GUI情報抽出結果の例
グループ化処理
レイアウト GUI情報 ルール
テキスト グループ化 グループ化 変数名 グループ化 パネル
ルール 解析
図5.8: レイアウトルール解析の流れ
5.2.1 レイアウトに関する追加情報の分析
AspectJによる情報抽出の段階では，ウィジェットの配置に関係した要素は各ウィ
ジェットのX座標，Y座標，幅，高さ，およびウインドウの幅と高さの6種類で あったが，より柔軟にルールを発見させるため，さらに以下の16種類の配置に関 係した情報を求め，合計18種の位置に関する情報をルール解析に用いる．
center
ウィジェットの中心のX座標 right
ウィジェットの右端のX座標 middle
ウィジェットの中心のY座標 bottom
ウィジェットの下端のY座標 xfr (X-coordinate from Right Edge))
ウインドウ右端からウィジェットの左端までの距離（ピクセル）
dfr (Distance from Right Edge)
ウインドウの右端からウィジェットの右端までの距離（ピクセル）
dfc (Distance from Center)
ウインドウ中央からウィジェット中央までのX方向の距離（ピクセル）
yfb (Y-coordinate from Bottom Edge))
ウインドウ右端からウィジェットの左端までの距離（ピクセル）
dfb (Distance from Bottom Edge)
ウインドウ下端からウィジェット下端までの距離（ピクセル）
dfm (Distance from Middle)
ウインドウ中央からウィジェット中央までのY方向の距離（ピクセル）
xP (x Percentage)
ウインドウの幅に対するx座標の値をパーセンテージで表したもの dfrP (dfr Percentage)
ウインドウの幅に対するdfrの値をパーセンテージで表したもの dfcP (dfc Percentage)
ウインドウの幅に対するdfcの値をパーセンテージで表したもの
yP (y Percentage)
ウインドウの幅に対するy座標の値をパーセンテージで表したもの dfbP (dfb Percentage)
ウインドウの幅に対するdfbの値をパーセンテージで表したもの dfmP (dfm Percentage)
ウインドウの幅に対するdfmの値をパーセンテージで表したもの
これらの情報のうち，dfr，dfc，dfb，dfmの算出例を示したものが図5.9である．
dfc!
dfb
dfr x!
! dfm!
図5.9: “OK”ボタンに関する追加配置情報
5.2.2 各種レイアウト情報を基準にしたウィジェットのグループ化
第5.1.2項で抽出した情報および第5.2.1項で分析した追加情報を元に，ウィジェッ
トをグループ化する．
分類方法は以下の3種類である．
テキスト情報による分類
ウィジェットから抽出した情報のうち，主にボタンやラベルを対象としたテキス
表5.1: テキスト情報による分類の例
テキスト ウィジェットID
OK {WindowA:okButton, WindowC:okButton, WindowD:okButton} Cancel {WindowA:cancelButton, WindowB:cancelButton, WindowC:cancelButton}
Apply {WindowA:applyButton, WindowD:applyButton}
変数名中のキーワードによる分類
Javaの変数名は，一般的にCamelCase（lowerCamelCase1）で命名される．また，
ウィジェットは，“キーワード＋型”の形式で命名されている場合が多い．そこで本 手法では，抽出した変数を大文字を基準にて単語に分け，前方の単語をキーワー ドとして分類する．例えば，図5.10のようにGUIにおける各ウィジェットの変数 の命名がされている場合，名前の前半部分をキーワードとすることで，横に並ぶ ラベルとテキストフィールドが同じキーワードを持つウィジェットとして表5.2の ようにグループ化することができる．
titleLabel artistLabel albumLabel
titleField artistField albumField
図5.10: ウィジェットオブジェクトの変数命名の例
表5.2: 変数名中のキーワードによる分類の例 キーワード ウィジェットID
title {WindowA:titleLabel, WindowA:titleField} artist {WindowA:artistLabel, WindowA:artistField} album {WindowA:albumLabel, WindowA:albumField}
1複合語の表記方法の一種．最初の単語はすべて小文字で表記し，以後の単語は頭文字のみを大 文字で表記し，スペースやハイフン，アンダースコアなどの記号を間に挟まず単語をつなげて表記 する．
例：wasedaUniversity
親ウィジェットによる分類
SwingではGUIをレイアウトする際に，JPanelとよばれるパネルウィジェットを
用い，図5.11のように関連するウィジェットを同じパネルに配置し，そのパネル をウインドウ上に配置する方法が用いられる．ウィジェットがどのパネルに属して
いるかはAspectJを織り込んで実行する際にメソッドで求めることができ，情報抽
出の際に記録している．
Panel C
Panel B Panel A
図5.11: パネルを用いたウィジェット配置の例
ここでは各ウィジェットが属しているパネルウィジェットを，そのウィジェット の親ウィジェットと称し，同じ親ウィジェットをもつウィジェットを表グループ化 をしている．例えば，図5.11の場合，表5.3のようなグループ分けがなされる．
表5.3: 親ウィジェットによる分類の例 親ウィジェットID ウィジェットID
WindowA:panelA {WindowA:nameLabel, WindowA:emailLabel, WindowA:phoneLabel, WindowA:passwordLabel} WindowA:panelB {WindowA:nameField, WindowA:emailField,
WindowA:phoneField, WindowA:passwordField} WindowA:panelC {WindowA:okButton, WindowA:cancelButton}
5.2.3 位置ルールの解析
第5.2.2項でグループ化した中で，テキスト情報によるグループ化結果を用い，
ボタンに関する位置ルールを解析する．
まず，テキスト情報によるグループ化結果から，同じテキストを持つウィジェッ トのリストを取り出す．ここで取り出されたリストに含まれるウィジェットに関し てウィジェットの配置位置に関する18種の情報（x，center，right，xfr，dfr，dfc， xP，dfrP，dfcP，y，middle，bottom，yfb，dfb，dfm，yP，dfbP，dfmP）それぞれ について表5.4のように，同じ値を持つウィジェットをグループ化を行う．
表5.4: “OK”テキストをもつウィジェットのdfrの値における分類の例
dfrの値 ウィジェットID
6 {WindowA:okButton}
16 {WindowB:okButton, WindowC:okButton, WindowF:okButton}
ここでグループ化された全情報のうち，各要素の出現頻度を調べ，最も多く出 現する要素において，その要素を持つウィジェットの直行する座標の情報で再度グ ループ化を行う．
再度グループ化した中で，もう一度各要素の出現頻度を調べ，最も置く出現す る要素をそのテキストにおけるルールとして出力する．
例えば，“OK”というテキストを持つウィジェットの集合の位置情報において，
dfbの値が16であるウィジェットが最も多く出現するという場合，dfbはY座標に 関する要素であるため，直行するX座標における要素（x，center，right，xfr，dfr， dfc，xP，dfrP，dfcP）においてのグループ化を行う．新しくグループ化した中で，
最も多く出現する要素を調べ，dfrが24の場合が一番多いという結果の場合，“OK”
ボタンに関する位置ルールはdfbが16，dfrが24であるとする．
5.2.4 組み合わせルールの解析
変数名によるグループ化結果との親ウィジェットによるグループ化結果を用い，
組み合わせルールを解析する．ここでの解析対象は，ボタンを含む本手法の対象 ウィジェットすべてとする．
組み合わせルールでは，位置ルールのようにウィジェットのラベルをルールの 基準にせず，ウィジェットの型でルールを判断する．例えば，個別説明ラベル付き ウィジェットのルール解析では，ラベル＋テキストフィールドのルール，ラベル＋
ボタンのルールなど，ラベルによって説明されているウィジェットの型でルールを 分けている．
変数名によるルール解析
変数名によるグループ化結果から，キーワードと変数そのキーワードが含まれ るウィジェットのリストの組み合わせを順に取り出す．取り出されたリストに存在 するウィジェットの中で，以下の条件を満たすウィジェットの組み合わせを更に取 り出す．
1. 同じキーワードを持つウィジェットが2つ同じウインドウ上に存在する 2. 2つのウィジェットのうち，片一方がラベルウィジェットである
この条件を満たし取り出された組み合わせは，3.1.1で述べた“個別説明ラベル 付きウィジェット”に関するレイアウトルールを持つ可能性がある．
そこで，条件を満たす組み合わせを，選別されたレイアウトルールの解析対象 とし，新しくグループ化を行う．ここでは，ラベルウィジェトの相手となってい るウィジェットの型を基準に組み合わせをまとめる．例を表5.5に示す．
表5.5: 相手となるウィジェットの型を基準にグループ化した例 相手ウィジェットの型 ウィジェットIDの組み合わせ
JTextField {{WindowA:nameLabel, WindowA:nameField}, {WindowA:phoneLabel, WindowA:phoneField}}
JButton {WindowC:fontLabel, WindowC:fontButton}
グループ化ののち，ウィジェットの型ごとにラベルと相手ウィジェットとの距離 を比較し，最も多く出現する距離を，ラベルウィジェットと組み合わされるウィ ジェットの組み合わせルールとして出力する．なお，この際比較されるウィジェッ ト間の距離は以下の10種類である．
• ラベルの左端から相手の左端
• ラベルの右端から相手の左端
• ラベルの中央(横方向)から相手の中央(横方向)
• ラベルの右端から相手の右端
• ラベルの左端から相手の右端
• ラベルの上端から相手の上端
• ラベルの下端から相手の上端
• ラベルの中央(縦方向)から相手の中央(縦方向)
• ラベルの下端から相手の下端
• ラベルの上端から相手の縦端
親ウィジェットによるルール解析
親ウィジェットのグループ化結果から，変数名によるルール解析と同様に解析対 象を選別する．ここでは以下の条件を満たす親ウィジェットIDとウィジェットID の組み合わせを取り出す．
1. 同じ親ウィジェットを持つウィジェット（子ウィジェット）が2つ以上存在 する
2. 同じ親ウィジェットを持つウィジェット（子ウィジェット）がすべて同じ型で ある
この条件を満たし取り出された組み合わせは，3.1.1で述べた“囲み付きウィジェッ ト”や，単純に関連したGUI要素をまとめる際のレイアウトルールを持つ可能性 がある．
ここでも変数名によるルール解析と同様に，対象となる兄弟ウィジェットを，ウィ ジェットの型を基準に新しくグループ化をする．その例を表5.6に示す．
表5.6: 子ウィジェットの型を基準にグループ化した例
子ウィジェットの型 ウィジェットIDの組み合わせ
JCheckBox {{WindowB:checkbox1, WindowB:checkbox2, WindowB:checkbox3}, {WindowD:checkbox8, WindowD:checkbox9}}
JButton {WindowC:fontButton, WindowC:colorButton}
ここでグループ化された組み合わせについて，ウィジェットの型ごとに子ウィ ジェット間の距離を比較し，最も多く出現する距離を，子ウィジェットの組み合わ せルールとして出力する．なお，ここでは以下の2種の間隔について比較する．単 純にウィジェットが等間隔で並べている場合は，以下の2種のうちのどちらかの間 隔が0になっている．
• ラベルの右端から相手の左端
• ラベルの下端から相手の上端
5.3 新規開発ウインドウの自動レイアウト
出力されたレイアウトルールをもとに，開発者から新規開発するウインドウの 情報を受け取り，ルールと比較した後，自動でレイアウトを行う．
開発者が本システムに入力する情報は以下の2種類である．
• ウィジェット情報のリスト – ウィジェットの型
– 変数名
– ラベル名
• ウインドウのサイズ
ここで入力された情報と，発見されたレイアウトルールを比較し，ルールを適 用できるウィジェットが存在する場合，レイアウトを自動的に調整したウインドウ のソースコードを出力する．
自動レイアウトの例として，レイアウトルールに図5.12，開発者による入力に 図5.13を用い自動レイアウト調整させた図5.14に示す．この例では，“OK”ボタ ンに関する位置ルールと，ラベルウィジェットとテキストフィールドウィジェット の組み合わせルールが発見されたものとしている．
“OK”ボタンは位置ルールに従い，ウインドウ右端および下端からの距離を調 整しレイアウトされている．また，ラベルウィジェットとテキストフィールドウィ ジェットは，ウィジェット間の相対的な位置関係を組み合わせルール（個別説明ラ ベル付きウィジェット）に従い調整しレイアウトされている．
Position Rule { type:button;
text:OK;
alignX:DFR;
distanceX:6;
alignY:DFB;
distanceY:6;
}
Labeled Rule { type:textField;
xType:X2X;
distanceX:78;
yType:M2M;
distanceY:0;
}
図5.12: レイアウトルールの例
label("Name:"), textField(), label("Phone:"), textField(), button("OK"), window(240,120)
図5.13: 開発者による入力の例
ラベルとテキストフィールドを
組み合わせルール(個別説明ラベル付きウィジェット) で指定された距離に従ってレイアウト
ボタンを位置ルールに従ってレイアウト
図5.14: 自動レイアウト調整の例
第 6 章 評価
6.1 手法適用に関する調査
一般的なソフトウェアのうち，メニューから直接開くことのできるウインドウ を調査し，実際に本研究の手法を適用した場合を想定し，ルール発見および自動 レイアウトの可能性を考察した．
調査は以下の3種のアプリケーションソフトウェアに対して行い，レイアウト ルールが発見されるまでに必要な最小のウインドウ数を記録した．ウインドウは，
メニューの左側の項目から順に見ていき，現段階の本研究の手法の性質により，同 じレイアウト情報が2つ登場した段階でルールが発見されたものとする．
(A) 写真管理ツール（Mac OS X用/ファーストパーティ製）
(B) ワードプロセッサ（Mac OS X用/サードパーティ製）
(C) FTPクライアント（クロスプラットフォーム/オープンソース）
また，ルール発見後にそのルール適用対象登場する3つのウインドウに対し，
ルールを適用した場合のレイアウトと，実際にレイアウトされているものを比較 し，一致するかどうかを判定した．なお，判定は以下の3段階で行った．
○ ほぼ一致する
△ 並べ方の基準は正しいが明らかに間隔が異なる
× 別の基準でレイアウトされている
3種のアプリケーションソフトウェアに対する結果を図6.1から図6.3に示す．
6.2 システムの適用実験
6.2.1 実験内容
IBMが開発する総合開発環境である“Eclipse”の機能として用いられているウイ ンドウを模したウインドウを7種作成し，本研究のシステムを用いてルールの発 見とウインドウの自動レイアウトをする．
表6.1: 発見されるルールと必要なウインドウ数(A)
ルール 必要数 一致判定1 一致判定2 一致判定3
ラベル付きコンボボックス 1 × △ ○
ラベル付きテキストフィールド 2 ○ ○ ×
“キャンセル”ボタン 3 ○ ○ ○
“作成”ボタン 6 – – –
表6.2: 発見されるルールと必要なウインドウ数(B)
ルール 必要数 一致判定1 一致判定2 一致判定3
“キャンセル”ボタン 2 ○ ○ ○
ラベル付きコンボボックス 4 × ○ ×
“オプション”ボタン 7 × × ×
表6.3: 発見されるルールと必要なウインドウ数(C)
ルール 必要数 一致判定1 一致判定2 一致判定3
“取り消し”ボタン 4 × △ ×
“OK”ボタン 4 × △ ×
ラベル付きテキストフィールド 1 ○ △ ×
これらのウインドウからレイアウトルールを解析し，以下の入力で新しいウイ ンドウを生成させた．
入力1 button(”OK”), button(”キャンセル”), button(”ヘルプ”)
入力2 button(”キャンセル”), button(”閉じる”), button(”プレビュー”) 入力3 button(”OK”), button(”次へ”), button(”戻る”)
6.2.2 実験結果
7つのウインドウから得られたウィジェットのレイアウト情報を本システムで解 析し，導き出したレイアウトルールを図6.1に示す．
6.3 考察
第6.1項の調査結果に関して，各アプリケーションソフトウェアの結果に関する 考察を以下に述べる．
(A)については，OSのファーストパーティ製アプリケーションであり，ガイド ラインをできる限り忠実に守り，一貫性が確保されたGUIとなっている．レイア ウトルールは比較的早期に発見され，一方で，“作成”ボタンに関しては，ルール が発見できたものの，その後適用する機会が無かった．しかし，“OK”などといっ た肯定的な決定ボタンと同じようにレイアウトされており，位置ルールをラベル そのものではなくニュアンス的な基準を設けることで，一度も解析することなく ルールを適用したレイアウトができる可能性がある．
(b)については，(A)と比較した場合に，レイアウトに若干のばらつきがあり，
ルール発見までの必要ウインドウ数が全体的に多い．また，“オプション”ボタン に関しては，ウインドウ左下と右上の2種類の配置位置があり，解析順の関係で 左下に配置されるルールとなったが，その後登場するケースではどれも右上に配 置されており，解析したルールが有効に活用できない結果となった．
(C)については，クロスプラットフォームのオープンソースアプリケーションで あるため，(A)，(B)に比べ，レイアウトに大きなばらつきが見られる．例えば，“ 取り消し”ボタンや“OK”ボタンに関してウインドウ中央揃えでレイアウトされて いるものと右揃えでレイアウトされているものがどちらも一定数存在し，ルール が1つに定まらない．また，“取り消し”と同じ意味を持つ“キャンセル”ボタンも 存在しており，ラベルを基準にしている現段階の手法では解析対象にも適用対象 にもすることができない．
以上から，本研究の手法では，一貫性に気を配りレイアウトされているソフト ウェアについては，少なからずレイアウトルールの適用によって開発者の意図通
Position Rule {
type:button; text:OK;
alignX:DFR; distanceX:118; alignY:DFB; distanceY:6;
}
Position Rule {
type:button; text:キャンセル;
alignX:DFR; distanceX:6; alignY:DFB; distanceY:6;
}
Position Rule {
type:button; text:ヘルプ;
alignX:X; distanceX:6; alignY:DFB; distanceY:6;
}
Position Rule {
type:button; text:完了;
alignX:DFR; distanceX:6; alignY:DFB; distanceY:6;
}
Position Rule {
type:button; text:戻る;
alignX:DFR; distanceX:336; alignY:DFB; distanceY:6;
}
Position Rule {
type:button; text:次へ;
alignX:DFR; distanceX:230; alignY:DFB; distanceY:6;
}
Position Rule {
type:button; text:閉じる;
alignX:DFR; distanceX:118; alignY:DFB; distanceY:6;
}
図6.1: レイアウト情報を解析し得られたレイアウトルール
りに自動レイアウトすることができるといった結果となった．一方で，一貫性が あまり保たれていないソフトウェアに関して，ルール発見までに
また，全体的に見て，個別説明ラベル付きウィジェットのルールや，囲み付き ウィジェット群のルールについては，位置ルールに比べてレイアウト方法がばらば らであることが多い．ウインドウやパネル，ウィジェットのサイズによってレイア ウトの並びが異なっているケースがあり，ウィジェットがレイアウトされるコンテ キストについても解析対象とし，周りの状況により柔軟に対応できるルールの解 析・適用が望まれる結果となった．
次に，第6.2項の適用実験に関しての考察を以下に述べる．
入力1について，これらのボタンはどれもルールが生成されており，入力に対 してすべてのボタンがルール通りに出力された．
入力2では，“キャンセル”と“閉じる”の同じ位置にレイアウトされているボタ ンが入力されており，どちらに対してもルールが生成されている．これらを同時 に入力した場合，システムにより同じ位置にレイアウトされ，どちらかのボタン しか正常に扱えないという結果が得られた．
先に調査した209のウインドウでは今回のように“キャンセル”と“閉じる”が共 存するケースは存在しなかったもの，似たような意味を持つボタン同士ではなく，
全く違った意味を持つボタンが同じ場所にレイアウトされるルールが得られた時 の対処法を今後考える必要がある．
また，“プレビュー”というボタンは解析対象中の一度しか登場しておらず，ルー ルが生成されなかったため，新しいウインドウにレイアウトされなかった．
入力3では，“キャンセル”と“閉じる”のどちらも入力に含めていない．この場 合，その位置には不自然な空白が挿入されてしまった．現段階で，本手法は位置 情報をウインドウの各辺からの距離を指定しレイアウトしているためこういった 結果になってしまうが，将来的にはウインドウだけではなく他のウィジェットから の距離や，使っているレイアウトマネージャー情報もレイアウト要素として取り 入れる必要があると考えられる．
なお，今回は模造品に適用したため，実際のウインドウで適用した場合には精 度が落ちると考えられる．今後は，オープンソースソフトウェアなどへの適用に よる検証が必要である．また，JavaのSwingで作成されたアプリケーションソフ トウェアは，クロスプラットフォームという性質上，OSのガイドラインを適用し ておらず，一貫性に気を配っていないものが多く見られる．今後は，ルール解析・
適用対象を拡張し，各OSに特化した開発環境での手法適用・検証も行うことが望 ましい．
第 7 章 関連研究
GUIのレイアウトを調整する研究としては，進化アルゴリズムやマッピングを 用いたものが存在する．また，コーディングされたGUIを再利用する研究も存在 する．
本章では，それらの関連研究を紹介し，利点と欠点について考察する．
7.1 対応するルールから GUI をレイアウトする研究
Bendsenが提案する手法[8]では，Windows上で動作するビジネスアプリケー
ション向けのフレームワークであるMicrosoft Business FrameworkにおけるGUIの 自動レイアウトを可能にしている．
沢山のフォームを必要とするビジネスアプリケーションにおいてのユーザエク スペリエンス向上とデベロッパの生産効率はトレードオフの関係にあり，デベロッ パの負担軽減を図ったモデルとマッピングを用いたシステムである．ビジネスア プリケーションのフォームをビジネスモデルと呼ばれる，エンティティ・関係・特 性なるモデルとして定義し，マッピングを用いてGUIに変換している．
まず，ビジネスモデルをマッピングを用いてロジカルレイヤーと呼ばれるもの に変換している．この段階の変換は，ビジネスモデル中のエンティティに含まれ る様々なクラスの属性を“文字列”や“数字”といった抽象化された要素に変換させ る．例えば“IDType”という属性ならば“文字列（String）’に変換させている．
次にロジカルレイヤーから別のマップを用いてGUIに変換させる．マップでは 各要素ごとにウィジェットを対応させている．マップはGUIを表示させるターゲッ
ト（WindowsPC，Webブラウザ，スマートフォンなど）ごとに用意され，1つのロ
ジカルレイヤーから様々なプラットフォームのGUIが生成できる．
これらの変換例を図7.1に示す．
GUIの生成にロジカルレイヤーを経由することで，開発者はロジカルレイヤー で高度に抽象化された項目を用いてロジックとデータの構築に集中できる．また，
ドメインスペシャリストは表示する対象や細かいレンダリングを気にせずにUIの 内容の作成に集中することができる．この仕組みがこの研究でのGUI生成に関す る一番の利点だと考えられる．
しかし一方で，この手法ではモデルからGUIを生成するため，レイアウト上の 一貫性の確保について保証されていない．
IDType!
String!
Float!
Number!
String!
Number!
Ship Method!
ID:IDType!
Name:String!
BaseRate:Float!
ShipRate:Float!
Number!
String!
Label! TextBox!
Label! TextBox!
ID: Number!
Name: String!
BaseRate: Number!
ShipRate: Number!
Ship Method!
Label!
Label!
Label!
Label!
TextBox!
TextBox!
TextBox!
TextBox!
Ship Method!
ビジネスモデル ロジカルレイヤー 表示対象(GUI) マップ
図7.1: マップの適用例
7.2 ユーザの選択に基づいた GUI を生成する研究
Plessisらが提案する手法[9]では，GUIの自動レイアウトを行う．
GUIの自動レイアウト手段として，以前の研究ではグリッドを用いた方法をとっ ていたが，この研究では見た目の良さを向上させるために，レイアウトマネージャ を用いて自動レイアウトを可能にしている．
利用しているレイアウトマネージャは以下の通りである．
FlowLayout
水平にスペースなく並べてウィジェットを配置していく GridLayout
以前の研究でも使われていた．サイズの等しい矩形のグリッドにコンポーネ ントを配置する
BorderLayout
上・下・左・右・中央の5つに領域を区切り，そのうちのどこかに配置する これらのレイアウトマネージャを頂点とし，ウィジェットの末端として木構造を 作成する．それらの組み合わせをランダムに9つ形成し，その構造を用いてレン ダリングしたGUIからユーザに最適なものを選んでもらい，選ばれなかった8つ を再形成させ，ユーザに再び選択してもらう．
木構造の組み合わせを生成する際に，進化アルゴリズムを用いており，選ばれ なかった8つの再形成に，以下の突然変異を用いている．
レイアウトの突然変異
レイアウトマネージャの1つを別のものに変更する シャッフル変異
レイアウトマネージャ頂点をランダムに選び，コンポーネントの順序をシャッ フル
頂点交換
2つの頂点をランダムに選び，入れ替える 頂点移動
ランダムに選んだ頂点を別な頂点の下に移動させる
実験結果として，平均10.7代目で許容できるGUIが作成されており，ユーザの 選択に各世代平均27.04秒かかっている．また，想定しているGUIレイアウトに たどりつけなかったケースも報告されている．
この研究での利点はユーザにレイアウト候補を選ばせるプロセスを取り入れる ことにより，ユーザが思い描くものに限りなく近いレイアウトが実現可能な点で あると考えられる．
一方で，ウインドウに含まれるウィジェットが多くなると，変異によるレイアウ トの変化が部分的なものになってしまい，ユーザが望む結果に至るまでの候補を 選択するプロセスに時間がかかってしまう点に疑問が残る．
7.3 既存の GUI ソースコードを再利用する研究
Lutterothが提案する手法[10]では，WYSIWYGで作られるハードコーディング
されたGUIのソースコードに，数行のコードを加えることでGUI情報を抽出し，
自身の提案するレイアウトモデルであるALM[11]を用いて，より抽象化したGUI を作成する．それにより，よりウインドウや動作環境に柔軟に対応する動的なレ イアウトがされたGUIを生成している．
本手法ではレイアウト情報の抽出に加え，そこからレイアウトのルールの解析 を行い，新規作成するウインドウへの適用が可能である．また，本手法ではアス ペクト指向プログラミングを用い，既存のソースコードを改変することなくレイ アウト情報を抽出している．
第 8 章 おわりに
本研究では，既存のソフトウェアのソースコードを解析することで，レイアウ トルールを発見し，ルールを適用させた新しいウインドウを生成する手法を提案 した．しかし，現段階でウインドウ中のすべてのウィジェットを自動レイアウトす るには至っておらず，引き続き努力が必要である．
本研究の今後の課題は以下の通りである．
より柔軟なルール解析方法の提案
現段階での各レイアウトルールの解析方法は，型やラベルごとに出現回数を 記録し，最も多く出現する値をルールとして定めている．今後は単純な出現 回数だけではなく，ウィジェットがレイアウトされるコンテキストなども考 慮し，柔軟なレイアウトをさせたい．
様々なレイアウト方法への対応
Swingでは，ウィジェットのレイアウトにレイアウトマネージャを用い，ピ
クセルを指定せずにレイアウトする方法がある．今後はこのような方法でレ イアウトされたウィジェットに対してもルールの解析および自動レイアウト ができるようにしたい．
ルール解析対象の拡張
現在の解析対象としているウィジェットの型やレイアウトルールの種類を更 に拡張し，GUI中のより多くの部分を自動でレイアウトさせたい．
研究のより詳しい評価
本研究は，適用対象のソフトウェアの規模が大きいほど効果があると考えら れるため，適用実験だけではなく，実際の大規模なソフトウェアを用い，研 究の評価をとりたい．
謝辞
本研究を進めるにあたり，数々のご助言を下さった，深澤良彰 教授，3年間に わたり丁寧かつ熱心なご指導を賜りました，東京女子大学 白銀純子 准教授，神奈 川工科大学 岩田一 助教に深く感謝いたします．
また，ともに研究に励み，様々なご協力をいただいた深澤研究室，鷲崎研究室 の皆様に深く感謝いたします．
