考察

第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に特化した開発環境での手法適用・検証も行うことが望 ましい．