JP2016224623A - 画面ｕｉ検証装置、画面ｕｉ検証方法、及びプログラム - Google Patents

Abstract

【課題】画面ＵＩのモデル検査において、画面ＵＩの操作順序に関する一部の制約条件について明示的に記述することなく、自動的に制約条件を推測して検証することにより、人手で入力する制約条件を削減する。
【解決手段】画面ＵＩの設計の検証を行うための画面ＵＩ検証装置において、前記画面ＵＩの設計情報を記憶する記憶手段と、前記設計情報を用いて、前記画面ＵＩにおいて依存性を有するウィジェット間の遷移関係を計算し、当該遷移関係の遷移先状態であるイベント処理実行後の状態において、当該イベントの発生源であるウィジェットについての所定の条件が満たされているという制約条件を作成する作成手段と、前記制約条件を含むモデル検査用モデルを入力することによりモデル検査を実行する検査実行手段とを備える。
【選択図】図４

Description

本発明は、ＧＵＩアプリケーションの設計手法の分野で、画面ＵＩの設計を検証するにあたり、設計情報から画面ＵＩの操作順序に関する制約を推測し、制約を含めたモデル検査用のモデルを作成してモデル検査を行う技術に関連するものである。

以下、画面ＵＩの設計、モデル検査、先行技術について説明する。

（画面ＵＩの設計）
画面ＵＩとはアプリケーションにおいて、ユーザが情報を入力し、アプリケーションに実行させる処理を選択するために、画面上に表示されるインタフェースを指す。画面ＵＩでは、情報の入力や処理の選択のために、開発に利用するライブラリ等によって予め定義された、テキストフィールドやボタン等の有限種類のウィジェットが組み合わされて利用される。

ウィジェットはそれぞれの性質を表すためのプロパティを持ち、プロパティ値を変更することによって状態が変化する。例えば、チェックボックスはチェック状態というプロパティを持ち、チェック有りとチェック無しの二つのプロパティ値の間で変化する。プロパティ値は、ユーザによるウィジェットの操作によって発生するイベントを契機として変化する。一般的には、画面上に表示するか否か、操作可能か否かといった状態もプロパティとして扱われるが、これらの状態はイベントの発生条件に関わるため、ここではそれぞれ表示状態、操作可能状態として他のプロパティとは分けて扱う。

画面ＵＩの例を図１に示す。図１（ａ）に示す画面ＵＩ状態１ではチェックボックスとボタンが表示されており、チェックボックスは操作可能でボタンは操作不能である。ここでチェックボックスをクリックすると図１（ｂ）の画面ＵＩ状態２に遷移するものとする。画面ＵＩ状態２ではチェックボックスのチェック状態がチェック有りになっており、それに伴いボタンが操作可能になっている。ここでボタンをクリックすると図１（ｃ）の画面ＵＩ状態３に遷移するものとする。画面ＵＩ状態３では新たにテキストフィールドが表示されている。このように、画面ＵＩの設計者は、処理内容に応じて必要なウィジェットのみを表示・操作可能な状態とし、他のウィジェットを非表示・操作不能な状態にすることでユーザによる画面ＵＩの操作順序に制限を課す。ユーザは、設計者の意図した操作順序に従うことにより、情報の入力及び処理の選択を直感的に行うことができる。

設計者は各ウィジェットの表示状態や操作可能状態の組み合わせと状態の遷移について、画面状態表及び状態遷移表と呼ばれる表を作成する。図１に対応する画面状態表、状態遷移表の一部の例を図２と図３にそれぞれ示す。

設計者は、画面ＵＩ設計の際には、設計者の意図していない画面ＵＩの操作手順によって不正な画面ＵＩの状態に到達しないことを検査するために、画面状態表と状態遷移表を目視で確認する。画面上に多数のウィジェットが配置される場合、画面状態表、状態遷移表の項目数が爆発的に増大するため、目視による検査には大きな手間を要する。また目視による検査では、ユーザが設計者の意図しない順序で操作を行うことにより不正な状態へと遷移する可能性を見落としてしまうといった問題点がある。

（モデル検査）
モデル検査は、有限状態遷移系として記述されたモデルが、時相論理式として記述された仕様を満たすか否かを、網羅的に検査することにより判定する技術である。有限状態遷移系とは、状態の有限集合、初期状態、遷移関係の集合の３つ組から成る系であり、初期状態から開始し、遷移関係によって現在の状態が遷移する。また、時相論理式とは、「すべての時点でＸが成り立つ」「ある時点でＹが成り立つ」等の時間によって真偽が変化する命題を記述するための論理式である。モデル検査では線形時相論理（ＬＴＬ）や計算木論理（ＣＴＬ）といった時相論理が用いられる。なお、本明細書で使用する主な用語の定義についてはまとめて実施の形態の冒頭で説明する。

モデル検査技術の実装であるモデル検査器を利用することにより、検査は自動的に実行できる。ハードウェア及びソフトウェアの設計情報を有限状態遷移系としてモデル化し、モデル検査器による検査を行うことで、人間によるレビューでは見落としやすい不具合を早期に発見することができるというメリットがある。

ただし、ハードウェアやソフトウェアの設計情報が有限状態遷移系として与えられることは稀であるため、モデル検査を行う際には、通常の設計作業とは別に設計情報のモデル化を行う場合が多い。また、検査すべき仕様を時相論理式で記述した制約条件として与える必要がある。モデル及び制約条件は使用するモデル検査器によって定められた特別な記述言語で記述しなければならず、モデル検査器に精通していない設計者にとっては扱いづらいという問題がある。

（先行技術）
アプリケーションの操作順序に関して検証を行う方法としては、Ｗｅｂアプリケーションにおいて、画面間の遷移が予め定義した遷移順序等の遷移規則に従って遷移を行うか否かをモデル検査により検証する方法が提案されている（例えば、非特許文献１）。

上記のような装置や方法を用いて、モデル検査で設計者の意図しない状態への到達を検査することにより、目視では見落としやすい遷移も手間をかけずに漏れなく発見することができる。

Minmin Han and Christine Hofmeister. Modeling and verification of adaptive navigation in web applications. In Proceedings of the 6th International Conference on Web Engineering, ICWE '06, pp. 329-336, New York, NY, USA, 2006. ACM.

非特許文献１に開示されているような従来技術では、モデル検査を行うためには制約条件として遷移順序を設計者が与える必要があった。また、画面間の遷移における順序関係を検証することはできるが、同一画面内での動的な画面ＵＩの変化による操作順序の検証を行うことはできない。具体的には、例えば図１において、テキストフィールドの入力文字列の変化はボタンをクリックした後で行われるといった検証に対応していない。

画面ＵＩの設計において、設計者は画面ＵＩの操作順序を想定して設計を行うが、これを制約条件として網羅的に明記するには大きな手間を要し、また、設計者の意図しない手順による遷移はそもそも設計者の考えから漏れている場合が多く、記述漏れが生じるという課題がある。

本発明は上記の点に鑑みてなされたものであり、画面ＵＩのモデル検査において、画面ＵＩの操作順序に関する一部の制約条件について明示的に記述することなく、自動的に制約条件を推測して検証することにより、人手で入力する制約条件を削減することを可能とする技術を提供することを目的とする。

本発明の実施の形態によれば、画面ＵＩの設計の検証を行うための画面ＵＩ検証装置であって、
前記画面ＵＩの設計情報を記憶する記憶手段と、
前記設計情報を用いて、前記画面ＵＩにおいて依存性を有するウィジェット間の遷移関係を計算し、当該遷移関係の遷移先状態であるイベント処理実行後の状態において、当該イベントの発生源であるウィジェットについての所定の条件が満たされているという制約条件を作成する作成手段と、
前記制約条件を含むモデル検査用モデルを入力することによりモデル検査を実行する検査実行手段と
を備えることを特徴とする画面ＵＩ検証装置が提供される。

また、本発明の実施の形態によれば、画面ＵＩの設計の検証を行うための画面ＵＩ検証装置が実行する画面ＵＩ検証方法であって、
画面ＵＩ検証装置が備える記憶手段に格納された設計情報を用いて、前記画面ＵＩにおいて依存性を有するウィジェット間の遷移関係を計算し、当該遷移関係の遷移先状態であるイベント処理実行後の状態において、当該イベントの発生源であるウィジェットについての所定の条件が満たされているという制約条件を作成する作成ステップと、
前記制約条件を含むモデル検査用モデルを用いてモデル検査を実行する検査実行ステップと
を備えることを特徴とする画面ＵＩ検証方法が提供される。

本発明の実施の形態によれば、画面ＵＩのモデル検査において、画面ＵＩの操作順序に関する一部の制約条件について明示的に記述することなく、自動的に制約条件を推測して検証することにより、人手で入力する制約条件を削減することを可能とする技術が提供される。

画面ＵＩの例を示す図である。 画面状態表の例を示す図である。 状態遷移表の例を示す図である。 本実施の形態における画面ＵＩ検証装置１００の構成図である。 設計情報の構成例を示す図である。 本実施の形態における画面ＵＩ検証装置１００の動作を説明するためのフローチャートである。 本実施の形態における画面ＵＩ検証装置１００の動作を説明するためのフローチャートである。 ウィジェット配置設計情報を示す図である。 初期値表を示す図である。 定義値表を示す図である。 表示条件・操作可能条件表を示す図である。 イベント表を示す図である。 イベント順序情報を示す図である。 画面ＵＩ状態遷移モデルを示す図である。 イベント実行状態有限状態遷移系に相当するモデル記述を示す図である。 ウィジェットのプロパティに対応する有限状態遷移系に相当するモデル記述を示す図である。 状態遷移を制御する有限状態遷移系に相当するモデル記述を示す図である。 画面ＵＩの操作順序制約を示す図である。 モデル検査実行部による出力を示す図である。 モデル検査実行部による出力（設計情報の記法）を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

（実施の形態における用語の説明）
本発明の実施の形態の内容を説明する前に、まず、主な用語についての定義を説明する。

ウィジェット：ユーザによる情報の入力や処理の実行を行うために、画面ＵＩに用いられる部品。開発に利用するライブラリ等によって複数種類のウィジェットが予め用意されている。

プロパティ：ウィジェットごとに定義されている、ウィジェットの状態を表す属性。

表示状態：ウィジェットが画面に表示されているか、非表示であるかの別。表示、非表示という二つの表示状態値のいずれかを指す。

操作可能状態：ウィジェットが操作可能であるか、操作不能であるかの別。操作可能、操作不能という二つの操作可能状態値のいずれかを指す。

イベント：ウィジェットの操作等により発生する処理の契機となる事象。

画面ＵＩの状態：画面上に配置されたウィジェットのある時点におけるプロパティ値及び表示状態値・操作可能状態値の集合。

画面状態表：設計するアプリケーションにおいて到達し得る画面ＵＩの状態を網羅した表。列タイトルに状態名、行タイトルにウィジェットのプロパティ種別又は表示状態、操作可能状態を持つ。画面ＵＩの状態におけるウィジェットのプロパティ値、表示状態値、操作可能状態値が記述される。

状態遷移表：画面ＵＩの状態間の遷移関係を網羅した表。列タイトルに状態名、行タイトルにイベント名を持つ。画面ＵＩの状態におけるイベント発生時の遷移先の状態が記述される。

画面遷移：サーバに新しい画面を表示するための資源へのアクセスを要求し、その結果として現在の画面に代わり新しい画面をディスプレイに表示すること。

ウィジェット間の依存性：ウィジェットＡを操作するために、ウィジェットＢのプロパティが特定のプロパティ値であることが要求される場合、ウィジェットＡとウィジェットＢの間に依存性があると定義する。

画面ＵＩの操作順序：入力する情報や実行する処理の間に依存関係が存在する場合に、アプリケーションのユーザが操作すべきウィジェットの順序。設計者は、使用性を高めるために、依存関係のないウィジェットについては操作順序を制限せず、依存関係のあるウィジェットでは依存元のウィジェットを操作するまで依存先のウィジェットを非表示又は操作不能状態にすることで操作順序を暗黙的に規定する。

操作の実行状態：画面ＵＩに操作順序がある場合において、どの操作が実行され、どの操作が実行されていないかを区別した状態。

一階の述語論理式：「ＸはＹである。」といった命題と、命題の論理和、論理積、論理否定、及び「すべての〜について」「ある〜について」といった限量子から構成される式。述語を引数にとる述語は一階の述語論理式には含まれない。

時相論理式：「すべての時点でＸが成り立つ」「ある時点でＹが成り立つ」等の時間によって真偽が変化する命題を記述するための論理式。モデル検査では線形時相論理（ＬＴＬ）や計算木論理（ＣＴＬ）といった時相論理が用いられる。

走査：集合、列など複数の要素から成る構造に対して、各要素一つひとつを取り出して順に処理を行うこと。

有限状態遷移系：状態の有限集合、初期状態、遷移関係の集合の３つ組から成る系。初期状態から開始し、遷移関係によって現在の状態が遷移する。

有限状態遷移系における状態：ある時点における系の性質を他の時点の性質と区別するための単位。

遷移関係：遷移元状態、遷移ラベル、遷移先状態の３つ組。

遷移の実行：有限状態遷移系において現在の状態が遷移関係の遷移元状態と一致している場合に、当該有限状態遷移系の現在の状態を遷移先状態に変化させること。実行する遷移に遷移ラベルがついている場合、ラベルによる遷移の実行と呼ぶ。

遷移ラベル：有限状態遷移系の遷移につけられたラベル。複数の有限状態遷移系において、現在の状態を遷移元状態とする同一の遷移ラベルを持つ遷移関係がそれぞれ定義されている場合、当該遷移ラベルによる遷移は同時に実行される。

マッピング：キーと値の２つ組。

マッピングのキー：マッピングの集合があるとき、個々のマッピングを一意に識別するための要素。そのため、マッピングの集合中でキーが重複することは許されない。

ＮｕＳＭＶ：モデル検査器の一つ。

（実施の形態の概要）
本実施の形態では、ＧＵＩアプリケーションの設計時に、画面上に配置されるウィジェットに着目し、各ウィジェットの表示条件・操作可能条件やイベント設計情報を入力として、操作順序に関する設計上の制約条件を推測する。推測した制約条件をモデル検査器によって自動的に検証することができる。すなわち、ウィジェットの表示状態や操作可能状態の変化と操作順序の関連を用いることにより、操作順序に関する制約条件について、設計者が明示的に与えることなく、設計情報を基に自動的に推測することができる。以下、本実施の形態の内容を説明する。

まず、概要を説明する。本実施の形態では画面ＵＩ検証装置１００が提供される。当該画面ＵＩ検証装置１００は、画面ＵＩの設計において用いられるウィジェットの配置設計情報、画面上に配置されたウィジェットについて表示条件及び操作可能条件の規則を記した表示条件・操作可能条件設計情報、イベント発生時のウィジェットの状態の変化を記したイベント設計情報を記憶する機構と、画面上に配置されたウィジェットのプロパティの遷移を有限状態遷移系としてモデル化した画面ＵＩ遷移モデルを記憶する機構と、画面ＵＩの操作順序に関する暗黙的な制約条件を導出する機構と、画面ＵＩの操作順序に従って状態遷移をする有限状態遷移系を作成する機構と、有限状態遷移系と制約条件をモデル検査器に入力する形式に変換する機構と、モデル検査を実行する機構とを含む。

本実施の形態では、既に説明したとおり、有限状態遷移系を状態の集合、初期状態、遷移関係の集合の３つ組として定義する。遷移関係は遷移元状態、遷移ラベル、遷移先状態の３つ組と定義する。有限状態遷移系の現在の状態は初期状態から開始し、遷移関係によって遷移する。有限状態遷移系が複数ある場合、一つの有限状態遷移系がある遷移ラベルを持つ遷移関係によって遷移するとき、他の有限状態遷移系が同じ遷移ラベルを持つ遷移関係を持ち、かつ現在の状態からその遷移関係による遷移が可能な場合、それらの有限状態遷移系は同じ遷移ラベルを持つ遷移関係によって同時に遷移を起こすものとする。

本実施の形態に係る画面ＵＩ検証装置１００では、画面上のウィジェットのプロパティ値の集合と対応した状態を持ち、イベントと対応したラベルの付いた遷移関係を持つ有限状態遷移系を画面ＵＩ状態遷移モデルとして検証に利用する。この有限状態遷移系は入力としてユーザから受け取っても良いし、ウィジェット配置設計情報や表示条件・操作可能条件といった他の設計情報から機械的に作成しても良い。

画面ＵＩにおいて、ウィジェットは他のウィジェットのプロパティ値に依存して表示状態及び操作可能状態等の、イベントの発生条件に関わる状態を変化させることが多い。そのため、設計者はウィジェットの表示条件・操作可能条件等はウィジェットのプロパティ値を利用して記述する。また、ウィジェットの表示状態や操作可能状態等は、プロパティ値に依存せず、ボタンクリック等のイベントの発生のみを契機として変化する場合もある。この場合、イベント設計情報に表示条件・操作可能条件等の変化を記述する。ユーザはウィジェット配置設計情報、表示条件・操作可能条件等及びイベント設計情報を画面ＵＩ検証装置１００に入力する。

画面ＵＩの設計時には、操作順序に関する制約を明示する代わりに、表示条件・操作可能条件とイベント設計情報によって表示状態、操作可能状態等のイベントの発生条件に関わる状態を変化させ、ウィジェット間に依存関係を持たせる。つまり、画面ＵＩの操作順序に関する制約は表示条件・操作可能条件やイベント設計情報という形式で設計情報に暗黙的に含まれていると言える。本実施の形態では、表示条件・操作可能条件とイベント設計情報からウィジェットの依存関係を計算し、設計情報に含まれている操作順序の制約を推測する。

具体的には、画面ＵＩの操作によってある前提条件を満たした後に、あるイベントを実行させることを意図した設計を行う場合、前提条件をイベントの発生源となるウィジェットの表示条件・操作可能条件に設定することで操作順序を制限する。

この設計に対して、本実施の形態に係る画面ＵＩ検証装置１００は表示条件・操作可能条件からウィジェットの依存関係を計算し、イベント処理実行後の状態においては、イベントの発生源であるウィジェットの表示条件・操作可能条件が満たされていることが期待されていると推測する。

例えば図１の例では、設計情報より、テキストフィールドが表示された状態においては、ボタンの操作可能条件であるチェックボックスのチェック状態がチェック有りとなっていることが期待されていると推測される。従って、ボタンのクリック後の状態においてチェックボックスのチェック状態がチェック有りであることを操作順序に関する制約とする。

推測した制約条件についてモデル検査を行うために、ウィジェットの表示状態・操作可能状態を変化させるイベントについて、実行前の状態と実行後の状態のそれぞれの状態を持つ有限状態遷移系を作成する。また、あるイベントの実行が他のイベントの必要条件となっている場合、前者の実行後の状態と後者の実行前の状態をマージして一つの有限状態遷移系とする。この有限状態遷移系は画面ＵＩにおける操作の実行状態を表す。

入力された画面ＵＩ状態遷移モデルである有限状態遷移系と、作成した実行状態の有限状態遷移系及び導出した制約条件をモデル検査器の入力となる記述に変換して、モデル検査を実行し、結果を出力する。

なお、本実施の形態において、イベントの発生条件に関わる状態として表示条件、操作可能条件を用いているが、これら二種の状態に限定するものではなく、他にイベントの発生条件に関わる状態が存在する場合は、これら二種の状態と同様に扱う。

以下、本実施の形態における画面ＵＩ検証装置１００の構成と動作をより詳細に説明する。

（装置構成）
図４に、本実施の形態における画面ＵＩ検証装置１００の構成例を示す。図４に示す通り、本実施の形態の画面ＵＩ検証装置１００は、設計情報記憶部１０１、画面ＵＩ状態遷移モデル記憶部１０２、操作順序制約作成部１０３、実行状態モデル作成部１０４、モデル検査用モデル作成部１０５、及びモデル検査実行部１０６を備える。

設計情報記憶部１０１は、入力された画面上のウィジェット配置設計情報、ウィジェットの表示条件・操作可能条件設計情報、及びイベント設計情報を記憶する。画面ＵＩ状態遷移モデル記憶部１０２は画面ＵＩ状態遷移モデルを記憶する。操作順序制約作成部１０３は、入力された設計情報から操作順序に関する制約を作成する。実行状態モデル作成部１０４は、画面ＵＩ操作の実行状態を表現する実行状態モデルを作成する。モデル検査用モデル作成部１０５は、記憶された画面ＵＩ状態遷移モデルと作成された実行状態モデル及び順序制約からモデル検査用のモデルを作成する。モデル検査実行部１０６は当該モデルに基づきモデル検査を行う。

なお、図４に示す機能区分は一例に過ぎない。本実施の形態で説明する処理を実行できるのであれば、図４に示す機能区分に限られず、任意の機能区分としてよい。

本実施の形態に係る画面ＵＩ検証装置１００は、例えば、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。すなわち、画面ＵＩ検証装置１００が有する機能は、当該コンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

（設計情報）
本実施の形態の画面ＵＩ検証装置１００において用いる設計情報の構成例を図５に示す。図５においてＳｅｔ［Ｔ］はＴの有限個の集合を表し、Ｔｕｐｌｅ［Ｔ_１，...，Ｔ_ｎ］はＴ_１，...，Ｔ_ｎから成るｎ組を表し、Ｓｅｑ［Ｔ］はＴの０以上の列を表す。Ｔは変数であり、例えば、Ｓｅｔ［ウィジェット設計情報］はウィジェット設計情報の有限個の集合を意味する。

設計情報はウィジェット設計情報の集合である。ＵＩ Ｄｅｓｉｇｎは設計情報であり、その実体はウィジェットの集合である。ウィジェット設計情報は、ウィジェットＩＤ、ウィジェット種別、イベント設計情報の集合、プロパティ設計情報の集合、表示条件、操作可能条件の組で構成される。ウィジェットＩＤはウィジェットを一意に識別するための識別子である。ウィジェット種別は、テキストフィールドやチェックボックス、セレクトボックス等、画面ＵＩとして利用可能な種別が予め定義されている。イベント設計情報はイベント種別と、処理命令の列の２つ組で構成される。

イベント種別は、ｏｎＣｌｉｃｋやｏｎＣｈａｎｇｅ等、ウィジェットごとに有効な種別が予め定義されている。処理命令は、ウィジェットＩＤ、プロパティ種別、プロパティ値の組、又はウィジェットＩＤ、条件種別、真理値の組で表される。条件種別は表示状態か操作可能状態のいずれかであり、真理値は真か偽のいずれかである。これはウィジェットＩＤのウィジェットのプロパティ種別の与えられたプロパティ値を変更するか又は表示条件・操作可能状態を与えられた真理値に変更することを表現している。

プロパティ設計情報はプロパティ種別、プロパティ値、プロパティ値の集合の組として表現される。３つ組の２つ目はプロパティ初期値を表している。プロパティ種別は、チェックボックスのチェック状態やセレクトボックスの選択値等、ウィジェットごとに有効な種別が予め定義されている。プロパティ値にはチェック状態のチェック有・チェック無等の予め定義された値と、テキストフィールドの入力値である文字列等のユーザによって定義されるユーザ定義値がある。

表示条件・操作可能条件は、論理式として表される。ここでの論理式はウィジェットＩＤとプロパティ種別とプロパティ値を用いて記述された述語である。イベント順序情報は、ウィジェットＩＤとイベント種別の２つ組からウィジェットＩＤの集合へのマッピングとして表される。ウィジェットＩＤとイベント種別の２つ組によりイベントを一意に識別し、イベントによって表示状態又は操作可能状態が変化するウィジェットの集合をウィジェットＩＤの集合で表している。

（画面ＵＩ検証装置１００の動作概要）
次に、図６及び図７を参照して、本実施の形態に係る画面ＵＩ検証装置１００の動作の概要を説明する。

図６に示すように、画面ＵＩ検証装置１００は、ユーザの入力を待機し（ステップＳ１０１）、ユーザがウィジェット配置設計情報、表示条件・操作可能条件設計情報、イベント設計情報の入力を行うたびにそれぞれ設計情報記憶部１０１の設計情報を更新する（ステップＳ１０２、Ｓ１０３）。更に画面ＵＩ検証装置１００は、更新された設計情報を基に、イベント順序情報を更新する（ステップＳ１０４）。また、画面ＵＩ検証装置１００は、画面ＵＩ状態遷移モデルの入力を受けて画面ＵＩ状態遷移モデル記憶部１０２に記憶されたモデルを更新する（ステップＳ１０２、Ｓ１０５）。

必要な情報が入力されると（ステップＳ１０６のＹｅｓ）、画面ＵＩ検証装置１００は、イベント順序情報を用いてイベントの実行状態を区別するための有限状態遷移系を作成し（図７のステップＳ２０１）、イベント順序情報と表示条件・操作可能条件から操作順序に関する制約条件を作成し（ステップＳ２０２）、各種有限状態遷移系と制約条件、表示条件・操作可能条件を用いてモデル検査実行部１０６（モデル検査器）への入力となるモデル記述を作成する（ステップＳ２０３）。画面ＵＩ検証装置１００は、モデル検査を実行した後、モデル記述と設計情報の対応関係を利用して検証結果の可読性を高め、出力する（ステップＳ２０４）。

（動作の詳細）
以下に各ステップの処理を詳細に説明する。

＜ウィジェット配置設計情報の入力：Ｓ１０１、Ｓ１０２、Ｓ１０３＞
画面ＵＩ検証装置１００がステップＳ１０１においてユーザの操作を待機している状態にあるとき、ステップＳ１０２において、ユーザは例えば図８に示すように、画面上のウィジェット配置設計情報を入力することができる。

図８中の１はラジオボタングループ、１'及び１"はラジオボタン、２、５及び７はボタン、３はチェックボックス、４はテキストフィールド、６はセレクトボックスである。

ウィジェットにはそれぞれ一意に識別可能な識別子が定められる。本例では、１の識別子をラジオボタングループ１とし、１'及び１"の識別子をそれぞれラジオボタン１'、ラジオボタン１"とし、２、５、７の識別子をそれぞれボタン２、ボタン５、ボタン７とし、３の識別子をチェックボックス３とし、４の識別子をテキストフィールド４とし、６の識別子をセレクトボックス６とする。

また、画面上に配置されたウィジェットについて、ウィジェット種別、プロパティ種別に応じて、必要な場合には図１０に示すようにユーザ定義値を入力する。更に、ウィジェット種別、プロパティ種別に応じて、必要な場合には図９に示すようにプロパティ初期値を入力する。

画面ＵＩ検証装置１００は、入力されたウィジェット配置設計情報、ユーザ定義値、プロパティ初期値を用い、ステップＳ１０３において、設計情報記憶部１０１に記憶された設計情報を更新する。設計情報記憶部１０１では、画面上のウィジェットに対してウィジェット種別に応じて、ウィジェット設計情報に有効なイベント種別、プロパティ種別、有効なプロパティ値の集合を設定する。

＜表示条件・操作可能条件設計情報の入力：Ｓ１０１、Ｓ１０２、Ｓ１０３＞
画面ＵＩ検証装置１００がステップＳ１０１においてユーザの操作を待機している状態にあるとき、ステップＳ１０２において、ユーザは図１１に示すように、ウィジェットの表示条件・操作可能条件を入力する。表示条件・操作可能条件は一意に意味の定まる一階の述語論理式に対応付けられる形式で記述されているものとする。

入力された表示条件・操作可能条件を用い、ステップＳ１０３では設計情報記憶部１０１に記憶された設計情報を更新する。具体的には入力された表示条件・操作可能条件を論理式に変換し、設計情報中のウィジェット設計情報の表示条件・操作可能条件にそれぞれ設定する。

表示条件・操作可能条件中に出現するウィジェットのウィジェット種別、プロパティ種別に対して、ユーザ定義値として任意の文字列が許されている場合、プロパティ値として任意の文字列を使用することができる。その場合、プロパティ値として使用した文字列を当該ウィジェット設計情報のユーザ定義値に追加する。

＜イベント設計情報の入力：Ｓ１０１、Ｓ１０２、Ｓ１０３＞
設計者はまずイベント発生時のウィジェットのプロパティ値の変化を設計する。本実施の形態では、ウィジェットの一般的な動作については、ウィジェット種別ごとに暗黙的に定義されているため、ユーザはウィジェットの一般的な動作から外れたプロパティ値の変化のみを入力する。

画面ＵＩ検証装置１００がステップＳ１０１においてユーザの操作を待機している状態にあるとき、ステップＳ１０２において、ユーザは例えば図１２に示すように、イベント設計情報を入力する。

画面ＵＩ検証装置１００は、入力されたイベント設計情報を用い、ステップＳ１０３において、設計情報記憶部１０１に記憶された設計情報を更新する。具体的には、入力されたイベント設計情報を内部モデル中のウィジェット設計情報のイベント設計情報として設定する。

イベント設計情報中に出現するウィジェットのウィジェット種別、プロパティ種別に対して、ユーザ定義値として任意の文字列が許されている場合、プロパティ値として任意の文字列を使用することができる。その場合、プロパティ値として使用した文字列を当該ウィジェット設計情報のユーザ定義値に追加する。

イベント設計情報の処理命令中に、表示状態・操作可能状態を変化させる処理が記述されている場合、変化対象のウィジェットの表示条件・操作可能条件にイベント実行前後の条件を追加する。

＜ベント順序情報の更新：Ｓ１０４＞
画面ＵＩ検証装置１００は、ステップＳ１０４において、イベント設計情報からイベント順序情報を作成する。

イベントの処理命令によってウィジェットが表示又は操作可能になる場合、当該ウィジェットの操作はイベント実行後に行われることが期待されていると推測できる。そのため、各ウィジェットのイベント設計情報に含まれる処理命令を走査し、表示状態又は操作可能状態を真に設定する処理命令があれば、イベントの発生源であるウィジェットのウィジェットＩＤとイベント種別の組から表示状態・操作可能状態が変化させられるウィジェットのウィジェットＩＤの集合へのマッピングをイベント順序情報に加える。

例として、図１３に、図１２のイベント設計情報から作成されるイベント順序情報を示す。ボタン２のｏｎＣｌｉｃｋではチェックボックス３、テキストフィールド４、ボタン５が表示され、ボタン５のｏｎＣｌｉｃｋではセレクトボックス６とボタン７が表示されるため、イベント順序情報にイベントとウィジェットＩＤのマッピングが追加されている。この情報から、例えば、ボタン２のｏｎＣｌｉｃｋ実行後にボタン５を発生源とするイベントが実行可能になることが分かるため、イベント実行順序としては、ボタン２のｏｎＣｌｉｃｋ、ボタン５のｏｎＣｌｉｃｋという制約があるものと推測される。

＜画面ＵＩ状態遷移モデルの入力：Ｓ１０１、Ｓ１０２、Ｓ１０５＞
画面ＵＩ検証装置１００がステップＳ１０１においてユーザの操作を待機している状態にあるとき、ステップＳ１０２において、ユーザは図１４に示すように、画面ＵＩ状態遷移モデルを入力する。

図１４（ａ）におけるラベル付き有限状態遷移系の各状態は、画面上に配置されたウィジェットのプロパティ値及び表示状態値・操作可能状態値の集合に対応している。例えば、１とラベル付けられた状態では、図１４（ｂ）の表に示す通り、ラジオボタングループ１の選択値が未選択、表示状態は表示、操作可能状態は操作可能、ボタン２の表示状態は表示、操作可能状態が操作不能である。

また、図１４（ａ）に示す遷移に付けられたラベルはイベントと対応しており、例えば、ａとラベル付けられた遷移は図１４（ｃ）の表に示す通り、ラジオボタン１'のＯｎＣｌｉｃｋイベントと対応する。

＜入力情報のチェック：Ｓ１０６＞
画面ＵＩ検証装置１００は、ステップＳ１０６において、設計情報記憶部１０１及び画面ＵＩ状態遷移モデル記憶部１０２にウィジェット配置設計情報、表示条件・操作可能条件設計情報、イベント設計情報、画面ＵＩ状態遷移モデルが記憶されている場合、ステップＳ２０１〜ステップＳ２０４のモデル検査フローを実施し、そうでない場合はステップＳ１０１の待機状態に戻る。

＜イベント実行状態有限状態遷移系の作成：Ｓ２０１＞
ステップＳ２０１では、実行状態モデル作成部１０４が、ステップＳ１０４で作成されたイベント順序情報を用いて有限状態遷移系を作成する。

具体的には、実行状態モデル作成部１０４は、イベント順序情報に含まれるマッピングを走査し、マッピングのキー中のウィジェットＩＤが、マッピングの値であるウィジェットＩＤの集合に一度も現れないキーの集合を作成し、この集合に含まれるそれぞれのキーを唯一の要素とする列を作成する。図１３の例では、キーの中のボタン５はイベント順序情報の値の中に現れるため、ボタン２のみを要素とした集合が作成されたのち、（ボタン２，ＯｎＣｌｉｃｋ）のみを要素とする列が一つ作成される。

そして、作成した列に含まれるキーをイベント順序情報のキーから取り除いたマッピングを作成する。図１３の例では、キー（ボタン５，ＯｎＣｌｉｃｋ）とその値からなるマッピングが作成される。先に作成した列に含まれるキーそれぞれについて、イベント順序情報のマップ先の値のウィジェットＩＤの集合に含まれるウィジェットＩＤが、新しく作成したマッピングのキー中に現れる場合、そのキーを列に追加する。図１３の例では、先に作成した列のキー（ボタン２，ＯｎＣｌｉｃｋ）について、イベント順序情報のマップ先の値のウィジェットＩＤの集合に含まれるウィジェットＩＤ｛チェックボックス３、テキストフィールド４、ボタン５｝のうち、ボタン５が、新しく作成したマッピングのキー中に現れるので、（ボタン２，ＯｎＣｌｉｃｋ）の次に（ボタン５，ＯｎＣｌｉｃｋ）が続く列が作成される。これは、ボタン2とボタン５の依存関係が計算されたことに相当する。

作成した列それぞれに対して、列に含まれる組数に１を加算した数の状態を持つ有限状態遷移系を作成する。列に含まれる組に対してラベルを対応付け、初期状態から列に含まれる順にラベル遷移を行うように遷移関係を追加する。図１３に示す本実施例では初期状態から、ボタン２のＯｎＣｌｉｃｋ実行後かつボタン５のＯｎＣｌｉｃｋ実行前の状態に遷移し、さらにボタン５のＯｎＣｌｉｃｋ実行後の状態に遷移する有限状態遷移系が作られる。これは、依存性を有するウィジェット間の遷移関係が計算されたことに相当する。

＜制約条件の作成：Ｓ２０２＞
ステップＳ２０２では、操作順序制約作成部１０３が、ステップＳ２０１で作成された有限状態遷移系と表示条件・操作可能条件を用いて画面ＵＩ操作順序に関する制約条件を作成する。具体的には、ステップＳ２０１で作成された有限状態遷移系の遷移関係それぞれに対し、現在の状態が遷移先状態ならばラベルに対応するイベントの発生源と成るウィジェットの表示条件・操作可能条件が満たされているという制約を作成する。

本実施例では、ボタン２のＯｎＣｌｉｃｋイベントの発生源のウィジェットであるボタン２の操作可能条件が図１１で「ラジオボタングループ１の選択値が"ｂ"である」と定義されているため、「ボタン２のＯｎＣｌｉｃｋ実行後かつボタン５のＯｎＣｌｉｃｋ実行前の状態においてラジオボタングループ１の選択値が"ｂ"である」という制約が作成される。さらに、この制約条件に、ボタン５のＯｎＣｌｉｃｋイベントの発生源のウィジェットであるボタン５の操作可能条件を加えて、「ボタン５のＯｎＣｌｉｃｋ実行後の状態において、ＯｎＣｌｉｃｋ実行前の状態においてラジオボタングループ１の選択値が"ｂ"かつ、（チェックボックス３のチェック状態がチェック無しであるか、又はチェック有りでかつテキストフィールド４の入力文字列が空文字列でない）」という条件が作成される。尚、条件文中の括弧は結合順序を表している。

＜モデル検査用モデルの作成：Ｓ２０３＞
ステップＳ２０３では、モデル検査用モデル作成部１０５が、ステップＳ１０５で記憶された画面ＵＩ状態遷移モデルとステップＳ２０１で作成した有限状態遷移系及びステップＳ２０２で作成した制約条件を、モデル検査実行部１０６（例：モデル検査器ＮｕＳＭＶ）に入力するための特別な記法で出力する。

図１５はステップＳ２０１で作成した有限状態遷移系をモデル検査器ＮｕＳＭＶへの入力形式で出力したものの一部である。図１６、図１７は、ステップＳ１０５で入力された状態遷移モデルをモデル検査器ＮｕＳＭＶへの入力形式で出力したものの一部である。また、図１８はステップＳ２０２で作成した制約条件を同様にＮｕＳＭＶの入力形式で出力したものの一部ある。

画面ＵＩ状態遷移モデルは、各状態がウィジェットのプロパティ値の集合と対応付けられ、各遷移がイベントと対応付けられている。そのため、各ウィジェットのプロパティに対応する有限状態遷移系の集合と、それらの現在の状態から実行可能なイベントに対応するラベルを一つ選択して状態遷移を制御する有限状態遷移系に分離して記述する。

上述したとおり、図１５はステップＳ２０１で作成した有限状態遷移系に対応する記述である。図１５において、２行目〜３行目でｓ１、ｓ２、ｓ３の３状態を定義している。５行目は初期状態がｓ１であることを示す。７行目〜１９行目では遷移関係を記述しており、現在の状態がｓ１のとき３というラベルによってｓ２に遷移し、現在の状態がｓ２のとき６というラベルによってｓ３に遷移することが記されている。ここでは、ボタン２のＯｎＣｌｉｃｋがラベルの３と対応付けられており、ボタン５のＯｎＣｌｉｃｋがラベルの６と対応付けられている。

図１６はチェックボックス３のチェック状態に対応する有限状態遷移系の記述である。１行目のｓｔ＿ｃｈｅｃｋｂｏｘ＿１は有限状態遷移系の識別子である。直後のかっこ中のｅはこの有限状態遷移系に外部から渡されるパラメータを表す。外部からのパラメータとしては、イベントに対応するラベルが渡される。

２行目〜３行目で状態の集合を定義している。ｃｈｅｃｋｅｄ、ｕｎｃｈｅｃｋｅｄの二つの状態を持つことが３行目に記されており、これはそれぞれ「チェック有り」、「チェック無し」のプロパティ値に対応している。５行目は初期状態の指定であり、ここではｕｎｃｈｅｃｋｅｄを指定している。

６行目から１４行目は状態の遷移の記述である。７行目から１２行目が、ｅ＝４のときの遷移の記述である。ここで、４はチェックボックス３のＯｎＣｌｉｃｋに対応するラベルである。９行目の記述は、この有限状態遷移系の現在の状態がｃｈｅｃｋｅｄのとき、遷移先の状態として集合｛ｕｎｃｈｅｃｋｅｄ｝が与えられていることを意味する。遷移先の集合から非決定的に一つを選択して遷移する。この場合は集合の要素がｕｎｃｈｅｃｋｅｄのみであるため、必ずｕｎｃｈｅｃｋｅｄに遷移する。１０行目も同様に現在の状態がｕｎｃｈｅｃｋｅｄのときの遷移を記述している。１１行目は、現在の状態がｃｈｅｃｋｅｄ、ｕｎｃｈｅｃｋｅｄのいずれでもない場合の遷移の記述であるが、この有限状態遷移系ではこれらの状態以外に遷移しないため、この遷移が起きることはない。

１４行目はｅが４でない場合の遷移の記述であり、その場合この有限状態遷移系は現在の状態と同じ状態に遷移することが記されている。

図１７は状態遷移を制御する有限状態遷移系の記述である。３行目の記述は、イベントに対応するラベルの集合である。

４行目から８行目までは、実行可能なイベントを判別するために必要な、他の有限状態遷移系の状態を参照するための記述である。

１０行目は次に実行するイベントに対応するラベルの初期値の設定であり、初期値としていずれのイベントにも対応しないラベルである−１を指定している。１１行目は次に実行するイベントに対応するラベルの遷移の記述であり、１２行目から４７行目の記述で定義されている集合ｎｅｘｔ＿ｅｖｅｎｔから非決定的に一つを選択する。

１３行目、１４行目の記述では、ラジオボタン１'のＯｎＣｌｉｃｋとラジオボタン１"のＯｎＣｌｉｃｋがそれぞれラベル１、２と対応付けられている。１５行目から１９行目の記述はボタン１のＯｎＣｌｉｃｋのラベルとの対応づけに関する記述である。ボタン２は図１１より、ラジオボタングループ１の選択値が"ｂ"の場合のみ操作可能となる。また、ステップＳ１０６で追加された表示条件・操作可能条件により、ボタン２をクリックした後には操作不能になる。そのため、１７行目の記述により、ラジオボタングループ１の選択値に対応する有限状態遷移系とイベント実行状態に対応する有限状態遷移系に関する条件が満たされた場合にのみイベントがラベル３と対応付けられる。そうでない場合はイベントが実行できないことを表すために−１と対応付ける。２４行目から３９行目では同様に他のイベントとラベルを対応付けている。４０行目から４７行目で、ｎｅｘｔ＿ｅｖｅｎｔが実行可能なイベントに対して対応づけられたラベルの集合として定義される。この中から一つのラベルを選択し、すべての有限状態遷移系が同期的に状態遷移を行う。

図１８は制約条件の記述例を示す。例えば図１８の１行目は、ボタン２のＯｎＣｌｉｃｋ実行後かつボタン５のＯｎＣｌｉｃｋ実行前の状態において、ラジオボタングループ１の選択値が"ｂ"であるという制約条件を表す。

＜モデル検査の実行：Ｓ２０７＞
ステップＳ２０７ではステップＳ２０６で作成したモデルをモデル検査実行部１０６（モデル検査器）に入力し、結果を出力する。モデル検査実行部１０６は入力した制約条件に対する反例となるトレースを結果として出力する。

モデル検査の結果はモデル検査用モデルの記法に合わせて出力されるため、これを設計情報の記法に変換することで可読性を高める。具体的には、モデル検査実行部１０６の出力に含まれるラベルや状態を対応するイベントやプロパティ値に置換し、イベントによる画面ＵＩの変化を表現した出力に変換する。

モデル検査実行部１０６による検証結果の出力と、設計情報の記法への変換後の出力をそれぞれ図１９と図２０に示す。図１９と図２０はいずれもイベント実行状態がボタン２のＯｎＣｌｉｃｋ実行後でボタン５のＯｎＣｌｉｃｋ実行前の状態のとき、ボタン２の実行前提となるラジオボタングループ１の選択値がｂであるという条件が成り立たない場合のトレースを表している。これは、図１４において１、３、５、４の順に遷移したトレースにあたる。

３つ以上の遷移の順序に関する制約条件を人手により作成することは一般には容易ではなく、これを自動で推測し、検査できるという点において本実施の形態の画面ＵＩの検証装置１００は画面ＵＩの設計の検証に有用である。

（実施の形態の効果）
本実施の形態によれば、画面ＵＩの設計情報に暗黙的に定義された画面ＵＩの操作順序に関する制約の一部を推測し、制約条件を明示することなくモデル検査用モデルを自動的に作成することにより、検証を行うことができる。これによって、例えば、制約を一切記述することなく設計者の意図しない操作順序による不正な画面状態への到達を発見することが可能となる。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１００ 画面ＵＩ検証装置
１０１ 設計情報記憶部
１０２ 画面ＵＩ状態遷移モデル記憶部
１０３ 操作順序制約作成部
１０４ 実行状態モデル作成部
１０５ モデル検査用モデル作成部
１０６ モデル検査実行部

Claims (7)

1. 画面ＵＩの設計の検証を行うための画面ＵＩ検証装置であって、
   前記画面ＵＩの設計情報を記憶する記憶手段と、
   前記設計情報を用いて、前記画面ＵＩにおいて依存性を有するウィジェット間の遷移関係を計算し、当該遷移関係の遷移先状態であるイベント処理実行後の状態において、当該イベントの発生源であるウィジェットについての所定の条件が満たされているという制約条件を作成する作成手段と、
   前記制約条件を含むモデル検査用モデルを入力することによりモデル検査を実行する検査実行手段と
   を備えることを特徴とする画面ＵＩ検証装置。
2. 前記所定の条件は、前記イベントの発生源であるウィジェットについての表示条件又は操作可能条件である
   ことを特徴とする請求項１に記載の画面ＵＩ検証装置。
3. 前記設計情報は、ウィジェットの配置設計情報と、画面上に配置されたウィジェットについての表示条件及び操作可能条件と、イベント発生時のウィジェットの状態の変化を表すイベント設計情報とを含み、
   前記作成手段は、前記表示条件及び操作可能条件と前記イベント設計情報とに基づいて前記遷移関係を計算する
   ことを特徴とする請求項１又は２に記載の画面ＵＩ検証装置。
4. 画面ＵＩの設計の検証を行うための画面ＵＩ検証装置が実行する画面ＵＩ検証方法であって、
   画面ＵＩ検証装置が備える記憶手段に格納された設計情報を用いて、前記画面ＵＩにおいて依存性を有するウィジェット間の遷移関係を計算し、当該遷移関係の遷移先状態であるイベント処理実行後の状態において、当該イベントの発生源であるウィジェットについての所定の条件が満たされているという制約条件を作成する作成ステップと、
   前記制約条件を含むモデル検査用モデルを用いてモデル検査を実行する検査実行ステップと
   を備えることを特徴とする画面ＵＩ検証方法。
5. 前記所定の条件は、前記イベントの発生源であるウィジェットについての表示条件又は操作可能条件である
   ことを特徴とする請求項４に記載の画面ＵＩ検証方法。
6. 前記設計情報は、ウィジェットの配置設計情報と、画面上に配置されたウィジェットについての表示条件及び操作可能条件と、イベント発生時のウィジェットの状態の変化を表すイベント設計情報とを含み、
   前記作成ステップにおいて、前記画面ＵＩ検証装置は、前記表示条件及び操作可能条件と前記イベント設計情報とに基づいて前記遷移関係を計算する
   ことを特徴とする請求項４又は５に記載の画面ＵＩ検証方法。
7. コンピュータを、請求項１ないし３のうちいずれか1項に記載の画面ＵＩ検証装置の各手段として機能させるためのプログラム。

Images