プログラムによって表示される画面が仕様を満たすか判断するシステム
【課題】プログラムの処理によって順次表示される複数の画面が仕様を満たすかを、当該プログラムを実行することなく判断する。
【解決手段】本発明のシステムは、第１画面の仕様を定めた第１スキーマと、第２画面の仕様を定めた第２スキーマと、プログラムによる表示を第１から第２画面に切り替えさせるイベントとを記憶している。まず、第１スキーマに準拠した画面の表示中に発生したイベントに応じ実行される部分プログラムを、第１スキーマおよびイベントに基づきプログラムから抽出する。次に、第１スキーマに準拠する画面の集合から、当該集合に属する画面の表示中に発生したイベントに応じ表示される画面の集合を求める中間プログラムを、部分プログラムに基づき生成する。次に、第１画面が第１スキーマに準拠し、第１スキーマに中間プログラムを適用して得られる画面の集合が第２スキーマに準拠することを条件に、これらの画面が仕様を満たすと判断する。
【解決手段】本発明のシステムは、第１画面の仕様を定めた第１スキーマと、第２画面の仕様を定めた第２スキーマと、プログラムによる表示を第１から第２画面に切り替えさせるイベントとを記憶している。まず、第１スキーマに準拠した画面の表示中に発生したイベントに応じ実行される部分プログラムを、第１スキーマおよびイベントに基づきプログラムから抽出する。次に、第１スキーマに準拠する画面の集合から、当該集合に属する画面の表示中に発生したイベントに応じ表示される画面の集合を求める中間プログラムを、部分プログラムに基づき生成する。次に、第１画面が第１スキーマに準拠し、第１スキーマに中間プログラムを適用して得られる画面の集合が第２スキーマに準拠することを条件に、これらの画面が仕様を満たすと判断する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラムによって表示される画面が仕様を満たすか判断するシステムに関する。特に、本発明は、順次表示される複数の画面が予め定められた仕様を満たすかを静的に判断するシステムに関する。
【背景技術】
【０００２】
近年、インターネット上で閲覧可能なウェブページなどの文書のデザインが多様になってきている。デザインのよいウェブページは見栄えがよいが、視覚障害者などの特定の利用者にとっては理解しにくい場合がある。また、ページの構造が規約に反し、ある種のウェブブラウザでは正常に閲覧できない場合もある。このため、従来、ウェブページなどの文書が予め定められた仕様を満たすかを判断し、理解のし易さを評価したり、修正すべき箇所を指摘するシステムが提案されている（非特許文献８および９を参照。）。また、HTMLやXMLなどの構造化文書の仕様を定めるための研究や、仕様を定めるためのスキーマ（Schema）などの研究が進められている（非特許文献２および非特許文献４から５を参照。）。
【０００３】
非特許文献６および非特許文献７については実施の形態において参照する。
【非特許文献１】Yasuhiko Minamide: "Static approximation of dynamically generated Web pages", World Wide Web (WWW), 2005
【非特許文献２】FDR2 (Formal Systems)
【非特許文献３】Cristiano Calcagno, Philippa Gardner, Uri Zarfaty: "Context Logic and Tree Update", Principles of Programming Languages (POPL), 2005
【非特許文献４】Eugenio Di Sciascio, Francesco M. Donini, Marina Mongiello, Giacomo Piscitelli: "Web applications design and maintenance using Symbolic Model Checking", European Conference On Software Maintenance And Reengineering (CSMR), 2003
【非特許文献５】崔銀惠, 渡邊宏: "Web アプリケーションのクラス設計仕様に対するモデル化と検証", ソフトウェアテストシンポジウム, 2005
【非特許文献６】H. Comon, et al.: "Tree Automata Techniques and Applications", http://www.grappa.univ-lille3.fr/tata/, 1997
【非特許文献７】Haruo Hosoya and Benjamin Pierce: "Regular expression pattern matching for XML", Principles of programming languages (POPL), 2001
【非特許文献８】aDesigner (IBM)
【非特許文献９】Dreamweaver 8 (Macromedia)
【非特許文献１０】鷲尾和則, 松下 誠, 井上 克郎:"JavaScriptを含んだHTML文書に対するデータフロー解析を用いた構文検証手法の提案", 電子情報通信学会技術研究報告, SS2002-22, Vol.102, No.370, pp.13-18, 2002
【非特許文献１１】立石孝彰、斉藤新、宮下尚： "DHTMLのためのアクセシビリティ・チェックツール", http://spa.jssst.or.jp/2006/, SPA2006
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ウェブページによっては、静止画のみならず動画を含む場合がある。例えば、動画を生成するための規格として、Macromedia社のFlashや、DynamicHTMLなどが用いられている。動画は、ウェブページと共に提供されるプログラムによって静止画の表示を順次切り替えることにより実現される。静止画に関する技術を動画に応用しようとすると、そのプログラムを実際に実行したうえで、実行の結果として得られるそれぞれの静止画が仕様を満たすかを判断する必要がある。しかしながら、表示可能性のある全ての静止画が仕様を満たすか判断しようとすると、プログラムの実行状態の数が爆発的に増加し、現実的な時間で判断が完了しない場合があった。
【０００５】
なお、プログラムを実行することなくプログラムの実行後の状態を解析する技術が提案されている（非特許文献１、３、１０および１１を参照。）。非特許文献１および１０の技術によれば、プログラムを実行した結果として生成される文字列を、実際にそのプログラムを実行することなく解析することができる。しかしながら、これらの技術によっては、プログラムを実行した結果HTMLやXMLなどで記述された木構造のデータがどのように変更されるかを解析することはできない。また、非特許文献３には、プログラムを実行した結果として得られる木構造のデータが仕様を満たすかを判断する論理が示されている。しかしながら、この文献には、この論理に基づいて情報処理装置によってどのように仕様の充足性を判断するかについては記載されていない。また、非特許文献１１においては、プログラムを実行した結果生成される文字列を解析する技術を、木構造のＤＯＭ（ドキュメント・オブジェクト・モデル）に対し応用すべきことが示唆されている。しかしながら、非特許文献１には、応用するための具体的な方法は記述されていない。
【０００６】
そこで本発明は、上記の課題を解決することのできるシステム、方法およびプログラムを提供することを目的とする。この目的は特許請求の範囲における独立項に記載の特徴の組み合わせにより達成される。また従属項は本発明の更なる有利な具体例を規定する。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明の１形態においては、アプリケーションプログラムによって順次表示される複数の画面が予め定められた仕様を満たすかを判断するシステムであって、第１画面の構成が満たすべき仕様を定めた第１スキーマ情報、第２画面の構成が満たすべき仕様を定めた第２スキーマ情報、および、アプリケーションプログラムによる表示を第１画面から第２画面に切り替えさせるイベントを記憶した仕様記憶部と、アプリケーションプログラムのうち、第１スキーマ情報に準拠した何れかの画面の表示中にイベントが発生したことに応じ実行される部分プログラムを、第１スキーマ情報およびイベントに基づいて抽出する抽出部と、第１スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中にイベントが発生した場合に表示される画面の集合を求める中間プログラムを、部分プログラムに基づいて生成する生成部と、第１画面が第１スキーマ情報に準拠し、かつ、第１スキーマ情報に中間プログラムを適用して得られる画面の集合が第２スキーマ情報に準拠していることを条件として、複数の画面が予め定められた仕様を満たすと判断する判断部とを備えるシステムを提供する。また、当該システムとして情報処理装置を機能させるプログラムと、当該システムによって複数の画面が仕様を満たすかを判断する方法とを提供する。
なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となりうる。
【発明の効果】
【０００８】
本発明によれば、プログラムの処理によって順次表示される複数の画面のそれぞれが仕様を満たすことを、当該プログラムを実行することなく判断できる。
【発明を実施するための最良の形態】
【０００９】
以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
【００１０】
図１は、情報処理システム１０の全体構成を示す。情報処理システム１０は、文書データベース２０と、充足判断システム３０とを備える。文書データベース２０は、ウェブブラウザなどに対し複数の画面を順次表示させるための文書を記憶している。この文書は、例えば、HTML(Hyper Text Markup Language)などで記述された初期画面と、JavaScript(登録商標)などのプログラム言語で記述されたアプリケーションプログラムとを含む。この文書がウェブブラウザによって読み込まれると初期画面がウェブブラウザに表示される。表示された初期画面は、アプリケーションプログラムがウェブサーバまたはウェブブラウザにより実行されることにより順次変更される。この結果ウェブブラウザには複数の画面が順次表示される。
【００１１】
充足判断システム３０は、文書データベース２０から文書を読み出す。そして、充足判断システム３０は、読み出したこの文書に基づいて、アプリケーションプログラムによって順次表示される複数の画面が予め定められた仕様を満たすかを判断する。判断結果は利用者に出力される。
このように、本実施形態に係る情報処理システム１０は、アプリケーションプログラムによって順次変更される画面のそれぞれが予め定められた仕様を満たすか否かを、実際にそのプログラムを実行することなく、それらの画面を表示させるための文書を解析することによって判断することを目的とする。
【００１２】
図２は、文書データベース２０に記憶されたデータの一例を示す。文書データベース２０は、動画を含むウェブページなどを表示させるための文書を記憶している。この文書は、１行目から９行目に各種の設定情報を含み、１０行目から４９行目にヘッダ部分を含み、５１行目から５９行目に本体部分を含む。ヘッダ部分は、１３行目から３８行目までにJavaScriptで記述されたアプリケーションプログラムを含む。このアプリケーションプログラムは、ウェブページに表示を変更するための変更プログラムである。このアプリケーションプログラムは、ウェブページ上にチェックボックスを実現する。即ちこのアプリケーションプログラムは、表示したチェックボックスがマウスでクリックされるとそのチェックボックスをチェック状態に変更した画面を表示し、チェック状態のチェックボックスがマウスでクリックされるとそのチェックボックスをチェックされていない状態に変更した画面を表示する。
【００１３】
詳細には、このアプリケーションプログラムは、１６行目から３６行目にcheckBoxEventという関数を定義する。この関数は、５５行目に定義されたイベントの発生を条件に呼び出されるイベントハンドらとしての役割を果たす。この関数が呼び出されると、まず、１８行目および１９行目の条件判断が実行される。即ち、マウスにおいてＩＤが０のボタン（左ボタン）がクリックされたか、または、キーボードにおいてキーコードが３２のキー（スペースキー）が押下されたかが判断される。それ以外の場合には３５行目に処理を移してこの関数の処理を完了させる。
【００１４】
左ボタンがクリックされるか、スペースキーが押下されると、２０行目から３４行目までの処理が実行される。まず、２２行目において、チェックボックスがチェックされているか否かを示す属性"checked"が"true"か否かが判断される。チェックボックスがチェックされている場合には、アプリケーションプログラムは、この属性を"false"に変更することにより、チェックボックスからチェックを外す（２４行目）。この場合、チェックボックスの隣に表示されていた入力欄をさらに削除してもよい（２５行目）。
【００１５】
一方、チェックボックスがチェックされていなかった場合には、アプリケーションプログラムは、属性"checked"を"true"に変更することにより、チェックボックスにチェックをつける（２９行目）。この場合、アプリケーションプログラムは、チェックボックスの隣に入力欄を生成してもよい（３１行目）。なお、説明の便宜上、以降の図３から図９までの説明は入力欄についての処理を行わないことを前提とする。入力欄についての処理を行う場合については、図１０から図１４において後述する。
【００１６】
この文書は、アプリケーションプログラムに加えて、５１行目から５８行目に初期画面を含む。この初期画面はcheckという文字列と、その隣に並べたチェックボックスとを含む。５４行目において属性checkedはfalseに設定されているので、このチェックボックスは初期状態においてチェックが外れた状態にある。チェックボックスに対しマウスのクリックまたはキーボード操作がされると、checkBoxEventという関数が呼び出される（５５行目および５６行目）。
【００１７】
図３は、充足判断システム３０の機能構成を示す。充足判断システム３０は、仕様記憶部３００と、抽出部３１０と、生成部３２０と、判断部３３０とを有する。仕様記憶部３００は、アプリケーションプログラムによって順次表示される複数の画面のそれぞれが満たすべき仕様を定めた複数のスキーマ情報のそれぞれを記憶している。また、仕様記憶部３００は、これら複数の画面のそれぞれから他のそれぞれの画面に表示を切り替えさせるイベントを記憶している。例えば、仕様記憶部３００は、初期画面である第１画面の構成が満たすべき仕様を定めた第１スキーマ情報、および、第１画面の次に表示される第２画面が満たすべき仕様を定めた第２スキーマ情報を記憶している。そして、仕様記憶部３００は、アプリケーションプログラムによる表示を第１画面から第２画面に切り替えさせるイベントを記憶している。図２のアプリケーションプログラムにおいて、第１画面はチェックボックスがチェックされた画面であり、第２画面はチェックボックスのチェックが外れた画面である。そして第１画面から第２画面に表示を切り替えさえるイベントはマウスの左クリックまたはスペースキーの押下である。
【００１８】
図６は、仕様記憶部３００に記憶された仕様の第１例を示す。チェックボックスのチェックが外れている第１画面の仕様を定めた第１スキーマ情報を図の左下に示す。また、チェックボックスがチェックされている第２画面の仕様を定めた第２スキーマ情報を図の右下に示す。第１画面から第２画面に表示を切り替えさせるイベントは左クリック（Ｔ０）またはスペースキーの押下（Ｔ２）である。第２画面から第１画面に表示を切り替えさせるイベントは左クリック（Ｔ１）またはスペースキーの押下（Ｔ３）である。
【００１９】
図６に例示するスキーマ情報は、言語理論における木と正規木文法とによって表される。HTMLの文書は、開始タグと終了タグとの間に他の開始タグと終了タグとを含むツリー構造のデータである。スキーマ情報は、このようなツリー構造のデータの集合を正規木文法によって定義する。即ち、まず、<elem><child1/><child2/>…<childN/></elem>というタグを含むHTML文書を、スキーマ情報においてはelem(child1, child2, … ,childN)と表す。そして、スキーマ情報は、それぞれのタグを終端記号とし、記号Ｇｎを非終端記号とした複数の文法規則を含む。
【００２０】
具体的には、第１スキーマ情報（図中左下）は、bodyタグを含む。bodyタグの中に定義された非終端記号はG5およびG10などである。非終端記号はspanタグと、更に他の非終端記号G6~G8とを含む。G6~G8のそれぞれは属性値をcheckboxとするrole属性、属性値をfalseとするchecked属性、およびonclick属性を定義する。また、G10は他のspanタグを含む。即ち、第１スキーマ情報は、bodyタグの中に複数のspanタグを含むことを定義し、更に、最初のspanタグがrole属性、checked属性、および、onclick属性を含むことを定義している。
【００２１】
同様に、第１スキーマ情報（図中右下）は、bodyタグを含む。bodyタグの中に定義された非終端記号の規則によれば、bodyタグの中のspanタグは、属性値をcheckboxとするrole属性、属性値をfalseとするchecked属性、およびonclick属性を含む。即ち、第２スキーマ情報は、bodyタグの中に複数のspanタグを含むことを定義し、更に、最初のspanタグがrole属性、checked属性、および、onclick属性を含むことを定義している。このように、動画を含むコンテンツの仕様は、各画面の仕様と、各画面間の遷移を示すイベントとを含む状態遷移図によって表される。
【００２２】
図３に戻る。抽出部３１０は、文書データベース２０から文書を読み出す。そして、抽出部３１０は、この文書に含まれるアプリケーションプログラムのうち、第１スキーマ情報に準拠した何れかの画面の表示中にイベントが発生したことに応じ実行される部分プログラムを、第１スキーマ情報およびそのイベントに基づいて抽出する。このようにした抽出された部分プログラムを部分プログラム５０とする。図７にその一例を示す。
【００２３】
図７は、部分プログラム５０の第１例を示す。説明のために、文書データベース２０に記憶されたアプリケーションプログラムのうち関数checkBoxEventを抜粋して図上部に示す。抽出部３１０は、アプリケーションプログラムに含まれるそれぞれの条件分岐命令について、第１スキーマ情報に規定されたこれらの状態およびイベントに基づいて、何れの分岐先が実行されるかを判断する。図６において説明したように、第１画面から第２画面に表示を切り替えるイベントはマウスの左クリックまたはスペースキーの押下である。このため、４・５行目の条件分岐命令の条件は満たされる。即ち抽出部３１０は、６行目から１５行目までの命令列が実行されると判断する。
【００２４】
また、第１スキーマ情報は、属性値をfalseとするchecked属性を含む。このため、８・９行目の条件分岐命令の条件は満たされない。即ち、抽出部３１０は、１３行目から始まるelse節が実行されると判断する。抽出部３１０は、このようにして実行されると判断された分岐先の命令列を連続的に並べることにより、部分プログラム５０を生成する。この結果、部分プログラム５０は、checked属性の属性値をtrueに変更する命令を含む。
【００２５】
図３に戻る。生成部３２０は、部分プログラム５０に基づいて中間プログラム６０を生成する。この中間プログラム６０は、第１スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中にイベントが発生した場合に表示される画面の集合を求めるプログラムである。中間プログラム６０を図８に例示する。
図８は、中間プログラム６０の第１例を示す。説明のために、図８上段には部分プログラム５０を例示する。生成部３２０は、まず、部分プログラム５０をSSA(Static Single Assignment)変換することにより、それぞれの変数の定義が唯一に定まり、部分プログラム５０と同一の実行結果が得られる複数の命令を生成する。生成された命令列を図８中段に示す。
【００２６】
変換の過程について説明する。SSA表現において、それぞれの変数への代入は部分プログラム５０中で唯一に定まる。このため、部分プログラム５０をSSA変換するためには、２度以上の代入操作によって代入先となっている変数を、２以上の中間変数に変更する必要がある。図８に例示する部分プログラム５０において、変数checkboxには、オブジェクトevent.targetが代入されている。さらに、変数checkboxに含まれる属性の属性値は、関数setAttributeNSによって変更されている。このように、同一の変数checkboxの内容は複数回の操作によって複数回変更されている。このため、生成部３２０は、変数checkboxに関する処理を何らかの方法で変換する必要がある。
【００２７】
部分プログラム５０における直接的な木操作（例えば子要素の追加、属性の変更など）は、中間プログラム６０において抽象コンテンツ変換関数として表現される。抽象コンテンツ変換関数は任意のスキーマ情報Ｇと、そのスキーマ情報Ｇを満たす任意のコンテンツＴに対して、Ｆ（Ｔ）∈Ｔｒ（Ｇ）を満たすような、スキーマ情報からスキーマ情報への関数である。ここで、Ｔｒは抽象コンテンツ変形関数を表し、Ｆは木変形関数による木の変換を表す。
【００２８】
例えば、JavaScriptなどのプログラム言語を用いれば、コンテンツＴの中からある開始タグと終了タグとの間のデータを選択し、選択した当該データを変更する命令列を記述することができる。詳細には、JavaScriptには、HTML文書からドキュメントオブジェクトを抽出するgetElementByTagNameなどの関数が設けられている。これを用いれば、HTML文書においてある要素docを取り出し、その要素docに対応する属性attrの値をvalueに変更することができる。部分プログラム５０の例において、変数checkboxには、初期画面のうちイベントを発生させたタグが選択されて格納される。そして、checkbox.setAttributeNS();のメソッドによって、checkboxに格納されたタグの属性が変更されている。
【００２９】
アプリケーションプログラムにおけるこのようなツリー操作命令列を一般化すると、以下の式で表される。
v = doc.getElementByTagName("foo");
v.setAttribute.....
ここで、docはもとのHTML文書を格納するオブジェクトであり、fooは任意のタグの名称とする。getElementByTagNameは、指定された名称の開始タグから終了タグまでの間の文書をdocから取り出す関数とする。取り出された文書は変数vに代入される。変数vがその後の操作を受けると、docに格納されたもとのHTML文書も変更を受ける。即ち、ツリー操作命令列は、HTML文書からドキュメントオブジェクトを抽出する命令、および、抽出したドキュメントオブジェクトを変更する命令を含む。
【００３０】
抽出部３１０がツリー操作命令列を部分プログラム５０に含めて抽出した場合には、生成部３２０は、このツリー操作命令列を以下のように変換する。
$doc1 = getElementByTagName_r($doc0, $vN, "foo");
$v0 = getElementBytagName($doc0, "foo");
$v1 = setAttribute(…, $v0, …);
$vN = …;
ここで、変数$doc0は、ツリー操作命令例による操作前の画面構成を示す。一方、変数$doc1は、ツリー操作命令例による操作後の画面構成を示す。また、変数$v0は、getElementByTagName関数によって元の文書から複写されたドキュメントオブジェクトである複写データを格納する（２行目）。また、変数$vNは、変数$v0に格納された複写データが各種の操作、例えば属性の変更などを経て生成された文書を格納する（３〜４行目）。また、getElementByTagName_rは、画面中のタグfooの開始タグから終了タグまでの間の文書を、変数$vNの内容で置換える関数である。各種の操作を受けた複写データは、元の文書$doc0の一部と置換される（１行目）。
即ち生成部３２０は、ツリー操作命令列を、開始タグと終了タグとの間のデータを初期画面から複写した複写データを生成し、複写データを変更し、変更した当該複写データによって初期画面における複写元のデータを置換する命令列に変換する。
【００３１】
図８の例において具体的には、生成部３２０は、変数checkboxを、２つの中間変数$checkbox1および$checkbox2に変更する。変数$checkbox1は一般例における変数$v0に相当し、変数$checkbox2は一般例における変数$vNに相当し、変数$uncheckedは、一般例における$doc1に相当する。そして、生成部３２０は、変数$checkbox1にオブジェクトevent.targetを代入する命令を生成する。オブジェクトevent.targetの内容は、第１スキーマ情報の定義およびイベントによって具体的に定まる。したがって、生成部３２０は、変数$checkbox1に、event.targetの具体的な内容を代入する命令を生成してもよい。
【００３２】
次に、生成部３２０は、変数$checkbox2にツリー操作命令列の処理結果を代入する命令を生成する。即ち、変数$checkbox2には、変数$checkbox1に格納された画面において、checked属性の属性値をtrueに変更した画面が代入される。そして、生成部３２０は、変数$checkbox2の内容により元の画面を置換した画面を変数$uncheckedに代入する命令を代入する。この結果、操作後の画面を格納する変数$uncheckedには、checked属性の属性値がtrueに変更された画面が代入される。
【００３３】
以上の変換によれば、部分プログラム５０は、それぞれの変数に一度ずつの代入が行われるSSA形式に変換される。但し、関数setAttributeNSは、単一の画面に対する操作を行う関数であるので、このままでは第１スキーマ情報を満たす画面の集合から第２スキーマ情報を満たす画面の集合を求めることはできない。このため、生成部３２０は、関数setAttributeNSについて更に次の変換を行う。
【００３４】
ツリー操作命令列によって得ることができるコンテンツをＴ´とすると、抽象コンテンツ変形関数は、少なくともＴ´∈Ｔｒ（Ｇ）を満たす関数Ｔｒとして定義される。木変形関数が複数の引数を採る場合には、Ｔをコンテンツの組とし、Ｇをスキーマの組とし、Ｆ（Ｔ）∈Ｔｒ（Ｇ）を満たすようなＴｒが抽象コンテンツ変形関数である。このような抽象コンテンツ変形関数の定義としては、トップ・ダウン・ツリー・トランスデューサなどのツリー・トランスデューサや、非特許文献８に示すXML変換言語・クエリー言語の方理論の枠組みを利用することができる。以下にツリー・トランスデューサを例示する。
【００３５】
図９は、部分プログラム５０を中間プログラム６０に変換する処理に用いるツリー・トランスデューサの一例を示す。ツリー・トランスデューサにおいて、状態q1および状態q2の２状態を定義する。関数setAttributeNSによる操作は、状態q1から状態q2への遷移として表される。このツリー・トランスデューサにおいて、状態q1におけるそれぞれのタグは状態q2においてもそのまま維持され、checked属性の属性値のみがtrueに変更されている。
生成部３２０による以上の処理によって図８に例示する中間プログラム６０が生成される。
【００３６】
図３に戻る。続いて、判断部３３０は、中間プログラム６０に基づいて、それぞれの画面が仕様を満たすかを判断する。具体的には、まず、判断部３３０は、初期画面である第１画面が第１スキーマ情報を満たすかを判断する。そして、判断部３３０は、第１スキーマ情報に中間プログラム６０を適用して得られる画面の集合が第２スキーマ情報に準拠しているかを判断する。これらの判断には、非特許文献６などの従来公知の技術を用いることができる。そして、判断部３３０は、第１画面が第１スキーマ情報に準拠し、かつ、第１スキーマ情報に中間プログラム６０を適用して得られる画面の集合が第２スキーマ情報に準拠していることを条件に、それぞれの画面が仕様を満たすと判断する。仕様を満たすと判断された場合には、第２画面の次に表示される第３画面が第３スキーマ情報に準拠することを抽出部３１０に通知して判断させる。
【００３７】
図４は、それぞれの画面が仕様を満たすかを判断する処理の一例を示す。まず、判断部３３０は、第１画面が第１スキーマ情報に準拠するかを判断する（Ｓ４００）。第１画面が第１スキーマ情報に準拠しなければ（Ｓ４００：ＮＯ）、判断部３３０は、仕様を満たさないと判断し（Ｓ４１５）、判断結果を出力して処理を終了する。一方で、第１画面が第１スキーマ情報に準拠していれば（Ｓ４００：ＹＥＳ）、抽出部３１０は、アプリケーションプログラムのうち、第１スキーマ情報に準拠した何れかの画面の表示中にイベントが発生したことに応じ実行される部分プログラム５０を抽出する（Ｓ４２０）。
【００３８】
次に、生成部３２０は、部分プログラム５０に基づいて中間プログラム６０を生成する（Ｓ４３０）。次に、判断部３３０は、第１スキーマ情報に中間プログラム６０を適用することにより第１画面の次に表示し得る画面の集合を求める（Ｓ４４０）。そして、判断部３３０は、求められた画面の集合が第２スキーマ情報に準拠しているかを判断する（Ｓ４５０）。準拠していなければ（Ｓ４５０：ＮＯ）、判断部３３０は、アプリケーションプログラムによって表示され得る画面が仕様を満たさないと判断し（Ｓ４１５）、本図の処理を終了する。この場合、判断部３３０は、第１画面または第２画面がスキーマ情報とはどのように異なるのかを示す情報を生成して出力してもよい。
【００３９】
一方で、準拠していれば（Ｓ４５０：ＹＥＳ）、判断部３３０は、仕様記憶部３００に格納された全てのスキーマ情報について判断が完了したかを判断する（Ｓ４６０）。例えば、第２画面の次に表示される第３画面が満たすべき仕様を定めた第３スキーム情報が仕様記憶部３００に記憶されている場合には、全てのスキーマ情報についてはまだ判断が完了していない。このため、充足判断システム３０はＳ４２０に処理を戻す。即ち、抽出部３１０は、第２スキーマ情報、および、第２画面から第３画面へ表示を切り替えるイベントに基づいて部分プログラムを抽出し、その後の処理を行う。
全てのスキーマ情報について判断が完了したことに応じ（Ｓ４６０：ＹＥＳ）、判断部３３０は、アプリケーションプログラムによって表示される各画面が仕様を満たすと判断し（Ｓ４７０）、判断結果を出力して処理を終了する。
【００４０】
以上、図４を参照して説明した処理によれば、抽出部３１０は、表示され得る複数の画面のそれぞれについて、当該画面の表示中にイベントが発生したことに応じ実行される部分プログラムを、当該画面に対応するスキーマ情報、および、当該画面の表示中に発生しうるイベントに基づいて抽出することができる。そして、生成部３２０は、複数のスキーマ情報のそれぞれについて、当該スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中にイベントが発生した場合に表示される画面の集合を求める中間プログラムを、その画面の表示中に実行される部分プログラムに基づき生成することができる。そして、判断部３３０は、初期画面が第１スキーマ情報に準拠し、かつ、それぞれのスキーマ情報に中間プログラムを適用して得られる画面の集合が、当該スキーマ情報に準拠した画面の次に表示される画面の仕様を定めたスキーマ情報に準拠していることを条件として、それらの画面が仕様を満たすと判断できる。
【００４１】
図５は、充足判断システム３０による判断の概念図である。文書データベース２０は、複数の画面の初期画面を記述したHTML文書と、そのHTML文書を順次変更することにより複数の画面を表示するアプリケーションプログラムとを記憶する。即ち複数の画面のそれぞれもまたHTMLで記述されたウェブページである。また、アプリケーションプログラムとは、ウェブページ中に埋め込まれ、JavaScriptなどで記述されたプログラムであってもよい。
【００４２】
仕様記憶部３００は、複数の画面のそれぞれが満たすべき仕様を定めた複数のスキーマ情報のそれぞれを記憶する。また、仕様記憶部３００は、それぞれの画面から他のそれぞれの画面に表示を切り替えさせるイベントを記憶している。判断部３３０は、まず、初期画面が第１スキーマ情報に準拠するかを判断する。次に、判断部３３０は、第１スキーマ情報に基づき生成された中間プログラム６０によって、第１スキーマ情報に準拠する画面の表示中にイベントが発生した場合に表示され得る画面の集合を求める。判断部３３０は、この画面の集合が第２スキーマ情報に準拠するかを判断する。同様に、判断部３３０は、第２スキーマ情報に基づき生成された中間プログラムによって、第２スキーマ情報に準拠する画面の表示中にイベントが発生した場合に表示され得る画面の集合を求める。また、判断部３３０は、この画面の集合が第３スキーマ情報に準拠するかを判断する。画面が何れかのスキーマ情報に準拠しなくなるか、または、全てのスキーマ情報について判断が完了するまで以上の処理を繰り返す。
【００４３】
以上、本実施形態に係る充足判断システム３０によれば、アプリケーションプログラムによって順次表示される画面のそれぞれが仕様を満たすかを、そのアプリケーションプログラムを実行せずに判断することができる。この判断の際に、ツリー操作命令列を含む部分プログラムが中間プログラムへ変換される。部分プログラムを中間プログラムに変換することよって、単一の画面でなく所定の条件を満たす画面の集合に対し処理を適用可能とすることができる。この結果、プログラムを実際に実行しなくとも、プログラムの実行によって表示し得る画面の集合が仕様を満たすことを効率的に判断することができる。
【００４４】
以下、図１０から図１４を参照して、アプリケーションプログラムがチェックボックスに隣に入力欄を表示する場合について説明する。
図１０は、仕様記憶部３００に記憶された仕様の第２例を示す。チェックボックスのチェックが外れている第１画面の仕様を定めた第１スキーマ情報を図の左下に示す。また、チェックボックスがチェックされている第２画面の仕様を定めた第２スキーマ情報を図の右下に示す。第１画面から第２画面に表示を切り替えさせるイベントは左クリック（Ｔ０）またはスペースキーの押下（Ｔ２）である。第２画面から第１画面に表示を切り替えさせるイベントは左クリック（Ｔ１）またはスペースキーの押下（Ｔ３）である。
図１０に示す第１スキーマ情報は図６を参照して説明した第１スキーマ情報と略同一であるから説明を省略する。第２スキーマ情報は、第１スキーマ情報に加えて、bodyタグの中のspanタグの中に非終端記号G9を含む。G9は、inputタグを含む。即ち、第２スキーマ情報は、第２画面がinputタグを含むべきことを定めている。
【００４５】
図１１は、部分プログラム５０の第２例を示す。説明のために、文書データベース２０に記憶されたアプリケーションプログラムのうち関数checkBoxEventを抜粋して図上部に示す。抽出部３１０は、アプリケーションプログラムに含まれるそれぞれの条件分岐命令について、第１スキーマ情報に規定されたこれらの状態およびイベントに基づいて、何れの分岐先が実行されるかを判断する。図１０に示すように、第１画面から第２画面に表示を切り替えるイベントはマウスの左クリックまたはスペースキーの押下である。このため、３・４行目の条件分岐命令の条件は満たされる。即ち抽出部３１０は、５行目から１６行目までの命令列が実行されると判断する。
【００４６】
また、第１スキーマ情報は、属性値をfalseとするchecked属性を含む。このため、７行目の条件分岐命令の条件は満たされない。即ち、抽出部３１０は、１１行目から始まるelse節が実行されると判断する。抽出部３１０は、このようにして実行されると判断された分岐先の命令列を連続的に並べることにより、部分プログラム５０を生成する。この結果、部分プログラム５０は、checked属性の属性値をtrueに変更する命令と、inputタグを生成する命令とを含む。
【００４７】
図１２は、中間プログラム６０の第２例を示す。説明のために、図１２上段には部分プログラム５０を例示する。生成部３２０は、まず、部分プログラム５０をSSA(Static Single Assignment)変換することにより、それぞれの変数の定義がプログラム中で唯一に定まり、かつ、部分プログラム５０と同一の実行結果が得られる複数の命令を生成する。生成された命令列を図１２中段に示す。本例の部分プログラム５０は、ツリー操作命令列として、初期画面からイベントが発生した部分を取り出す命令と、属性値を変更する命令と、タグを追加する命令とを含む。したがって、変数checkboxは、３回の代入を受ける。
【００４８】
このため、生成部３２０は、変数checkboxを、３つの中間変数$checkbox1、$checkbox2および$checkbox3に変更する。変数$checkbox1は一般例における変数$v0に相当し、変数$checkbox2は一般例における変数$v1に相当し、変数$checkbox3は一般例における変数$vNに相当し、変数$uncheckedは、一般例における$doc1に相当する。そして、生成部３２０は、変数$checkbox1にオブジェクトevent.targetを代入する命令を生成する。次に、生成部３２０は、変数$checkbox2にツリー操作命令列の第１処理結果を代入する命令を生成する。即ち、変数$checkbox2には、変数$checkbox1に格納された画面において、checked属性の属性値をtrueに変更した画面が代入される。次に、生成部３２０は、変数$checkbox3にツリー操作命令列の第２処理結果を代入する命令を生成する。即ち、変数$checkbox3には、変数$checkbox2に格納された画面において、タグinputを追加した画面が代入される。そして、生成部３２０は、変数$checkbox3の内容により元の画面を置換した画面を変数$uncheckedに代入する命令を代入する。この結果、操作後の画面を格納する変数$uncheckedには、checked属性の属性値がtrueに変更され、かつ、タグinputが追加された画面が代入される。
【００４９】
以上の変換によれば、部分プログラム５０は、それぞれの変数に一度ずつの代入が行われるSSA形式に変換される。但し、関数setAttributeNS、関数appendChildおよび関数removeChildは、単一の画面に対する操作を行う関数であるので、このままでは第１スキーマ情報を満たす画面の集合から第２スキーマ情報を満たす画面の集合を求めることはできない。このため、生成部３２０は、関数setAttributeNS、関数appendChildおよび関数removeChildのそれぞれについて、ツリー・トランスデューサを用いた変換を行う。関数setAttributeNSの変換は図９と同一であるので説明を省略する。関数applendChildの変換を図１３に示し、関数removeChildの変換を図１４に示す。
【００５０】
図１３は、部分プログラム５０を中間プログラム６０に変換する処理に用いるツリー・トランスデューサの一例を示す。ツリー・トランスデューサにおいて、状態q1および状態q2の２状態が定義される。関数appendChildによる操作は、状態q1から状態q2への遷移として表される。このツリー・トランスデューサにおいて、状態q1におけるそれぞれのタグは状態q2においてもそのまま維持され、タグinputのみが追加されている。但し、変数$checkbox1についてはそのままではツリー・トランスデューサによって取り扱えないため、生成部３２０は、これを２分木にエンコードする。詳しくは非特許文献７などにおいて従来公知であるから説明を省略する。
【００５１】
図１４は、部分プログラム５０を中間プログラム６０に変換する処理に用いるツリー・トランスデューサの一例を示す。ツリー・トランスデューサにおいて、状態q1および状態q2の２状態が定義される。関数removeChildによる操作は、状態q1から状態q2への遷移として表される。このツリー・トランスデューサにおいて、状態q1におけるそれぞれのタグは状態q2においてもそのまま維持され、タグinputのみが削除されている。なお、図１４に例示したツリー・トランスデューサは、inputという名称のタグがHTML文書中にただ１つ存在することを前提とする。HTML文書中にinputという名称のタグが複数含まれる場合には、それぞれのタグを識別可能とするべく、それぞれのタグに識別可能な番号を付し、または、それぞれのタグを他の名称に変更する必要がある。また、以上に説明したようなツリー・トランスデューサでは取り扱いができないような処理については非特許文献６および非特許文献７に詳しいので説明を省略する。
【００５２】
以上、図１０から図１４を参照して説明したように、充足判断システム３０によれば、チェックボックスがチェックされたときにその隣に入力欄を表示させるアプリケーションプログラムについても、当該プログラムによって表示されるそれぞれの画面が仕様を満たすことを効率的に判断することができる。
【００５３】
図１５は、充足判断システム３０として機能する情報処理装置５００のハードウェア構成の一例を示す。情報処理装置５００は、ホストコントローラ１０８２により相互に接続されるＣＰＵ１０００、ＲＡＭ１０２０、及びグラフィックコントローラ１０７５を有するＣＰＵ周辺部と、入出力コントローラ１０８４によりホストコントローラ１０８２に接続される通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を有する入出力部と、入出力コントローラ１０８４に接続されるＲＯＭ１０１０、フレキシブルディスクドライブ１０５０、及び入出力チップ１０７０を有するレガシー入出力部とを備える。
【００５４】
ホストコントローラ１０８２は、ＲＡＭ１０２０と、高い転送レートでＲＡＭ１０２０をアクセスするＣＰＵ１０００及びグラフィックコントローラ１０７５とを接続する。ＣＰＵ１０００は、ＲＯＭ１０１０及びＲＡＭ１０２０に格納されたプログラムに基づいて動作し、各部の制御を行う。グラフィックコントローラ１０７５は、ＣＰＵ１０００等がＲＡＭ１０２０内に設けたフレームバッファ上に生成する画像データを取得し、表示装置１０８０上に表示させる。これに代えて、グラフィックコントローラ１０７５は、ＣＰＵ１０００等が生成する画像データを格納するフレームバッファを、内部に含んでもよい。
【００５５】
入出力コントローラ１０８４は、ホストコントローラ１０８２と、比較的高速な入出力装置である通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を接続する。通信インターフェイス１０３０は、ネットワークを介して外部の装置と通信する。ハードディスクドライブ１０４０は、情報処理装置５００が使用するプログラム及びデータを格納する。ＣＤ−ＲＯＭドライブ１０６０は、ＣＤ−ＲＯＭ１０９５からプログラム又はデータを読み取り、ＲＡＭ１０２０又はハードディスクドライブ１０４０に提供する。
【００５６】
また、入出力コントローラ１０８４には、ＲＯＭ１０１０と、フレキシブルディスクドライブ１０５０や入出力チップ１０７０等の比較的低速な入出力装置とが接続される。ＲＯＭ１０１０は、情報処理装置５００の起動時にＣＰＵ１０００が実行するブートプログラムや、情報処理装置５００のハードウェアに依存するプログラム等を格納する。フレキシブルディスクドライブ１０５０は、フレキシブルディスク１０９０からプログラム又はデータを読み取り、入出力チップ１０７０を介してＲＡＭ１０２０またはハードディスクドライブ１０４０に提供する。入出力チップ１０７０は、フレキシブルディスク１０９０や、例えばパラレルポート、シリアルポート、キーボードポート、マウスポート等を介して各種の入出力装置を接続する。
【００５７】
情報処理装置５００に提供されるプログラムは、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５、又はＩＣカード等の記録媒体に格納されて利用者によって提供される。プログラムは、入出力チップ１０７０及び/又は入出力コントローラ１０８４を介して、記録媒体から読み出され情報処理装置５００にインストールされて実行される。プログラムが情報処理装置５００等に働きかけて行わせる動作は、図１から図１４において説明した充足判断システム３０における動作と同一であるから、説明を省略する。
【００５８】
以上に示したプログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としては、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５の他に、ＤＶＤやＰＤ等の光学記録媒体、ＭＤ等の光磁気記録媒体、テープ媒体、ＩＣカード等の半導体メモリ等を用いることができる。また、専用通信ネットワークやインターネットに接続されたサーバシステムに設けたハードディスク又はＲＡＭ等の記憶装置を記録媒体として使用し、ネットワークを介してプログラムを情報処理装置５００に提供してもよい。
【００５９】
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【図面の簡単な説明】
【００６０】
【図１】図１は、情報処理システム１０の全体構成を示す。
【図２】図２は、文書データベース２０に記憶されたデータの一例を示す。
【図３】図３は、充足判断システム３０の機能構成を示す。
【図４】図４は、それぞれの画面が仕様を満たすかを判断する処理の一例を示す。
【図５】図５は、充足判断システム３０による判断の概念図である。
【図６】図６は、仕様記憶部３００に記憶された仕様の第１例を示す。
【図７】図７は、部分プログラム５０の第１例を示す。
【図８】図８は、中間プログラム６０の第１例を示す。
【図９】図９は、部分プログラム５０を中間プログラム６０に変換する処理に用いるツリー・トランスデューサの一例を示す。
【図１０】図１０は、仕様記憶部３００に記憶された仕様の第２例を示す。
【図１１】図１１は、部分プログラム５０の第２例を示す。
【図１２】図１２は、中間プログラム６０の第２例を示す。
【図１３】図１３は、部分プログラム５０を中間プログラム６０に変換する処理に用いるツリー・トランスデューサの一例を示す。
【図１４】図１４は、部分プログラム５０を中間プログラム６０に変換する処理に用いるツリー・トランスデューサの一例を示す。
【図１５】図１５は、充足判断システム３０として機能する情報処理装置５００のハードウェア構成の一例を示す。
【符号の説明】
【００６１】
１０ 情報処理システム
２０ 文書データベース
３０ 充足判断システム
５０ 部分プログラム
６０ 中間プログラム
３００ 仕様記憶部
３１０ 抽出部
３２０ 生成部
３３０ 判断部
５００ 情報処理装置
【技術分野】
【０００１】
本発明は、プログラムによって表示される画面が仕様を満たすか判断するシステムに関する。特に、本発明は、順次表示される複数の画面が予め定められた仕様を満たすかを静的に判断するシステムに関する。
【背景技術】
【０００２】
近年、インターネット上で閲覧可能なウェブページなどの文書のデザインが多様になってきている。デザインのよいウェブページは見栄えがよいが、視覚障害者などの特定の利用者にとっては理解しにくい場合がある。また、ページの構造が規約に反し、ある種のウェブブラウザでは正常に閲覧できない場合もある。このため、従来、ウェブページなどの文書が予め定められた仕様を満たすかを判断し、理解のし易さを評価したり、修正すべき箇所を指摘するシステムが提案されている（非特許文献８および９を参照。）。また、HTMLやXMLなどの構造化文書の仕様を定めるための研究や、仕様を定めるためのスキーマ（Schema）などの研究が進められている（非特許文献２および非特許文献４から５を参照。）。
【０００３】
非特許文献６および非特許文献７については実施の形態において参照する。
【非特許文献１】Yasuhiko Minamide: "Static approximation of dynamically generated Web pages", World Wide Web (WWW), 2005
【非特許文献２】FDR2 (Formal Systems)
【非特許文献３】Cristiano Calcagno, Philippa Gardner, Uri Zarfaty: "Context Logic and Tree Update", Principles of Programming Languages (POPL), 2005
【非特許文献４】Eugenio Di Sciascio, Francesco M. Donini, Marina Mongiello, Giacomo Piscitelli: "Web applications design and maintenance using Symbolic Model Checking", European Conference On Software Maintenance And Reengineering (CSMR), 2003
【非特許文献５】崔銀惠, 渡邊宏: "Web アプリケーションのクラス設計仕様に対するモデル化と検証", ソフトウェアテストシンポジウム, 2005
【非特許文献６】H. Comon, et al.: "Tree Automata Techniques and Applications", http://www.grappa.univ-lille3.fr/tata/, 1997
【非特許文献７】Haruo Hosoya and Benjamin Pierce: "Regular expression pattern matching for XML", Principles of programming languages (POPL), 2001
【非特許文献８】aDesigner (IBM)
【非特許文献９】Dreamweaver 8 (Macromedia)
【非特許文献１０】鷲尾和則, 松下 誠, 井上 克郎:"JavaScriptを含んだHTML文書に対するデータフロー解析を用いた構文検証手法の提案", 電子情報通信学会技術研究報告, SS2002-22, Vol.102, No.370, pp.13-18, 2002
【非特許文献１１】立石孝彰、斉藤新、宮下尚： "DHTMLのためのアクセシビリティ・チェックツール", http://spa.jssst.or.jp/2006/, SPA2006
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ウェブページによっては、静止画のみならず動画を含む場合がある。例えば、動画を生成するための規格として、Macromedia社のFlashや、DynamicHTMLなどが用いられている。動画は、ウェブページと共に提供されるプログラムによって静止画の表示を順次切り替えることにより実現される。静止画に関する技術を動画に応用しようとすると、そのプログラムを実際に実行したうえで、実行の結果として得られるそれぞれの静止画が仕様を満たすかを判断する必要がある。しかしながら、表示可能性のある全ての静止画が仕様を満たすか判断しようとすると、プログラムの実行状態の数が爆発的に増加し、現実的な時間で判断が完了しない場合があった。
【０００５】
なお、プログラムを実行することなくプログラムの実行後の状態を解析する技術が提案されている（非特許文献１、３、１０および１１を参照。）。非特許文献１および１０の技術によれば、プログラムを実行した結果として生成される文字列を、実際にそのプログラムを実行することなく解析することができる。しかしながら、これらの技術によっては、プログラムを実行した結果HTMLやXMLなどで記述された木構造のデータがどのように変更されるかを解析することはできない。また、非特許文献３には、プログラムを実行した結果として得られる木構造のデータが仕様を満たすかを判断する論理が示されている。しかしながら、この文献には、この論理に基づいて情報処理装置によってどのように仕様の充足性を判断するかについては記載されていない。また、非特許文献１１においては、プログラムを実行した結果生成される文字列を解析する技術を、木構造のＤＯＭ（ドキュメント・オブジェクト・モデル）に対し応用すべきことが示唆されている。しかしながら、非特許文献１には、応用するための具体的な方法は記述されていない。
【０００６】
そこで本発明は、上記の課題を解決することのできるシステム、方法およびプログラムを提供することを目的とする。この目的は特許請求の範囲における独立項に記載の特徴の組み合わせにより達成される。また従属項は本発明の更なる有利な具体例を規定する。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明の１形態においては、アプリケーションプログラムによって順次表示される複数の画面が予め定められた仕様を満たすかを判断するシステムであって、第１画面の構成が満たすべき仕様を定めた第１スキーマ情報、第２画面の構成が満たすべき仕様を定めた第２スキーマ情報、および、アプリケーションプログラムによる表示を第１画面から第２画面に切り替えさせるイベントを記憶した仕様記憶部と、アプリケーションプログラムのうち、第１スキーマ情報に準拠した何れかの画面の表示中にイベントが発生したことに応じ実行される部分プログラムを、第１スキーマ情報およびイベントに基づいて抽出する抽出部と、第１スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中にイベントが発生した場合に表示される画面の集合を求める中間プログラムを、部分プログラムに基づいて生成する生成部と、第１画面が第１スキーマ情報に準拠し、かつ、第１スキーマ情報に中間プログラムを適用して得られる画面の集合が第２スキーマ情報に準拠していることを条件として、複数の画面が予め定められた仕様を満たすと判断する判断部とを備えるシステムを提供する。また、当該システムとして情報処理装置を機能させるプログラムと、当該システムによって複数の画面が仕様を満たすかを判断する方法とを提供する。
なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となりうる。
【発明の効果】
【０００８】
本発明によれば、プログラムの処理によって順次表示される複数の画面のそれぞれが仕様を満たすことを、当該プログラムを実行することなく判断できる。
【発明を実施するための最良の形態】
【０００９】
以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
【００１０】
図１は、情報処理システム１０の全体構成を示す。情報処理システム１０は、文書データベース２０と、充足判断システム３０とを備える。文書データベース２０は、ウェブブラウザなどに対し複数の画面を順次表示させるための文書を記憶している。この文書は、例えば、HTML(Hyper Text Markup Language)などで記述された初期画面と、JavaScript(登録商標)などのプログラム言語で記述されたアプリケーションプログラムとを含む。この文書がウェブブラウザによって読み込まれると初期画面がウェブブラウザに表示される。表示された初期画面は、アプリケーションプログラムがウェブサーバまたはウェブブラウザにより実行されることにより順次変更される。この結果ウェブブラウザには複数の画面が順次表示される。
【００１１】
充足判断システム３０は、文書データベース２０から文書を読み出す。そして、充足判断システム３０は、読み出したこの文書に基づいて、アプリケーションプログラムによって順次表示される複数の画面が予め定められた仕様を満たすかを判断する。判断結果は利用者に出力される。
このように、本実施形態に係る情報処理システム１０は、アプリケーションプログラムによって順次変更される画面のそれぞれが予め定められた仕様を満たすか否かを、実際にそのプログラムを実行することなく、それらの画面を表示させるための文書を解析することによって判断することを目的とする。
【００１２】
図２は、文書データベース２０に記憶されたデータの一例を示す。文書データベース２０は、動画を含むウェブページなどを表示させるための文書を記憶している。この文書は、１行目から９行目に各種の設定情報を含み、１０行目から４９行目にヘッダ部分を含み、５１行目から５９行目に本体部分を含む。ヘッダ部分は、１３行目から３８行目までにJavaScriptで記述されたアプリケーションプログラムを含む。このアプリケーションプログラムは、ウェブページに表示を変更するための変更プログラムである。このアプリケーションプログラムは、ウェブページ上にチェックボックスを実現する。即ちこのアプリケーションプログラムは、表示したチェックボックスがマウスでクリックされるとそのチェックボックスをチェック状態に変更した画面を表示し、チェック状態のチェックボックスがマウスでクリックされるとそのチェックボックスをチェックされていない状態に変更した画面を表示する。
【００１３】
詳細には、このアプリケーションプログラムは、１６行目から３６行目にcheckBoxEventという関数を定義する。この関数は、５５行目に定義されたイベントの発生を条件に呼び出されるイベントハンドらとしての役割を果たす。この関数が呼び出されると、まず、１８行目および１９行目の条件判断が実行される。即ち、マウスにおいてＩＤが０のボタン（左ボタン）がクリックされたか、または、キーボードにおいてキーコードが３２のキー（スペースキー）が押下されたかが判断される。それ以外の場合には３５行目に処理を移してこの関数の処理を完了させる。
【００１４】
左ボタンがクリックされるか、スペースキーが押下されると、２０行目から３４行目までの処理が実行される。まず、２２行目において、チェックボックスがチェックされているか否かを示す属性"checked"が"true"か否かが判断される。チェックボックスがチェックされている場合には、アプリケーションプログラムは、この属性を"false"に変更することにより、チェックボックスからチェックを外す（２４行目）。この場合、チェックボックスの隣に表示されていた入力欄をさらに削除してもよい（２５行目）。
【００１５】
一方、チェックボックスがチェックされていなかった場合には、アプリケーションプログラムは、属性"checked"を"true"に変更することにより、チェックボックスにチェックをつける（２９行目）。この場合、アプリケーションプログラムは、チェックボックスの隣に入力欄を生成してもよい（３１行目）。なお、説明の便宜上、以降の図３から図９までの説明は入力欄についての処理を行わないことを前提とする。入力欄についての処理を行う場合については、図１０から図１４において後述する。
【００１６】
この文書は、アプリケーションプログラムに加えて、５１行目から５８行目に初期画面を含む。この初期画面はcheckという文字列と、その隣に並べたチェックボックスとを含む。５４行目において属性checkedはfalseに設定されているので、このチェックボックスは初期状態においてチェックが外れた状態にある。チェックボックスに対しマウスのクリックまたはキーボード操作がされると、checkBoxEventという関数が呼び出される（５５行目および５６行目）。
【００１７】
図３は、充足判断システム３０の機能構成を示す。充足判断システム３０は、仕様記憶部３００と、抽出部３１０と、生成部３２０と、判断部３３０とを有する。仕様記憶部３００は、アプリケーションプログラムによって順次表示される複数の画面のそれぞれが満たすべき仕様を定めた複数のスキーマ情報のそれぞれを記憶している。また、仕様記憶部３００は、これら複数の画面のそれぞれから他のそれぞれの画面に表示を切り替えさせるイベントを記憶している。例えば、仕様記憶部３００は、初期画面である第１画面の構成が満たすべき仕様を定めた第１スキーマ情報、および、第１画面の次に表示される第２画面が満たすべき仕様を定めた第２スキーマ情報を記憶している。そして、仕様記憶部３００は、アプリケーションプログラムによる表示を第１画面から第２画面に切り替えさせるイベントを記憶している。図２のアプリケーションプログラムにおいて、第１画面はチェックボックスがチェックされた画面であり、第２画面はチェックボックスのチェックが外れた画面である。そして第１画面から第２画面に表示を切り替えさえるイベントはマウスの左クリックまたはスペースキーの押下である。
【００１８】
図６は、仕様記憶部３００に記憶された仕様の第１例を示す。チェックボックスのチェックが外れている第１画面の仕様を定めた第１スキーマ情報を図の左下に示す。また、チェックボックスがチェックされている第２画面の仕様を定めた第２スキーマ情報を図の右下に示す。第１画面から第２画面に表示を切り替えさせるイベントは左クリック（Ｔ０）またはスペースキーの押下（Ｔ２）である。第２画面から第１画面に表示を切り替えさせるイベントは左クリック（Ｔ１）またはスペースキーの押下（Ｔ３）である。
【００１９】
図６に例示するスキーマ情報は、言語理論における木と正規木文法とによって表される。HTMLの文書は、開始タグと終了タグとの間に他の開始タグと終了タグとを含むツリー構造のデータである。スキーマ情報は、このようなツリー構造のデータの集合を正規木文法によって定義する。即ち、まず、<elem><child1/><child2/>…<childN/></elem>というタグを含むHTML文書を、スキーマ情報においてはelem(child1, child2, … ,childN)と表す。そして、スキーマ情報は、それぞれのタグを終端記号とし、記号Ｇｎを非終端記号とした複数の文法規則を含む。
【００２０】
具体的には、第１スキーマ情報（図中左下）は、bodyタグを含む。bodyタグの中に定義された非終端記号はG5およびG10などである。非終端記号はspanタグと、更に他の非終端記号G6~G8とを含む。G6~G8のそれぞれは属性値をcheckboxとするrole属性、属性値をfalseとするchecked属性、およびonclick属性を定義する。また、G10は他のspanタグを含む。即ち、第１スキーマ情報は、bodyタグの中に複数のspanタグを含むことを定義し、更に、最初のspanタグがrole属性、checked属性、および、onclick属性を含むことを定義している。
【００２１】
同様に、第１スキーマ情報（図中右下）は、bodyタグを含む。bodyタグの中に定義された非終端記号の規則によれば、bodyタグの中のspanタグは、属性値をcheckboxとするrole属性、属性値をfalseとするchecked属性、およびonclick属性を含む。即ち、第２スキーマ情報は、bodyタグの中に複数のspanタグを含むことを定義し、更に、最初のspanタグがrole属性、checked属性、および、onclick属性を含むことを定義している。このように、動画を含むコンテンツの仕様は、各画面の仕様と、各画面間の遷移を示すイベントとを含む状態遷移図によって表される。
【００２２】
図３に戻る。抽出部３１０は、文書データベース２０から文書を読み出す。そして、抽出部３１０は、この文書に含まれるアプリケーションプログラムのうち、第１スキーマ情報に準拠した何れかの画面の表示中にイベントが発生したことに応じ実行される部分プログラムを、第１スキーマ情報およびそのイベントに基づいて抽出する。このようにした抽出された部分プログラムを部分プログラム５０とする。図７にその一例を示す。
【００２３】
図７は、部分プログラム５０の第１例を示す。説明のために、文書データベース２０に記憶されたアプリケーションプログラムのうち関数checkBoxEventを抜粋して図上部に示す。抽出部３１０は、アプリケーションプログラムに含まれるそれぞれの条件分岐命令について、第１スキーマ情報に規定されたこれらの状態およびイベントに基づいて、何れの分岐先が実行されるかを判断する。図６において説明したように、第１画面から第２画面に表示を切り替えるイベントはマウスの左クリックまたはスペースキーの押下である。このため、４・５行目の条件分岐命令の条件は満たされる。即ち抽出部３１０は、６行目から１５行目までの命令列が実行されると判断する。
【００２４】
また、第１スキーマ情報は、属性値をfalseとするchecked属性を含む。このため、８・９行目の条件分岐命令の条件は満たされない。即ち、抽出部３１０は、１３行目から始まるelse節が実行されると判断する。抽出部３１０は、このようにして実行されると判断された分岐先の命令列を連続的に並べることにより、部分プログラム５０を生成する。この結果、部分プログラム５０は、checked属性の属性値をtrueに変更する命令を含む。
【００２５】
図３に戻る。生成部３２０は、部分プログラム５０に基づいて中間プログラム６０を生成する。この中間プログラム６０は、第１スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中にイベントが発生した場合に表示される画面の集合を求めるプログラムである。中間プログラム６０を図８に例示する。
図８は、中間プログラム６０の第１例を示す。説明のために、図８上段には部分プログラム５０を例示する。生成部３２０は、まず、部分プログラム５０をSSA(Static Single Assignment)変換することにより、それぞれの変数の定義が唯一に定まり、部分プログラム５０と同一の実行結果が得られる複数の命令を生成する。生成された命令列を図８中段に示す。
【００２６】
変換の過程について説明する。SSA表現において、それぞれの変数への代入は部分プログラム５０中で唯一に定まる。このため、部分プログラム５０をSSA変換するためには、２度以上の代入操作によって代入先となっている変数を、２以上の中間変数に変更する必要がある。図８に例示する部分プログラム５０において、変数checkboxには、オブジェクトevent.targetが代入されている。さらに、変数checkboxに含まれる属性の属性値は、関数setAttributeNSによって変更されている。このように、同一の変数checkboxの内容は複数回の操作によって複数回変更されている。このため、生成部３２０は、変数checkboxに関する処理を何らかの方法で変換する必要がある。
【００２７】
部分プログラム５０における直接的な木操作（例えば子要素の追加、属性の変更など）は、中間プログラム６０において抽象コンテンツ変換関数として表現される。抽象コンテンツ変換関数は任意のスキーマ情報Ｇと、そのスキーマ情報Ｇを満たす任意のコンテンツＴに対して、Ｆ（Ｔ）∈Ｔｒ（Ｇ）を満たすような、スキーマ情報からスキーマ情報への関数である。ここで、Ｔｒは抽象コンテンツ変形関数を表し、Ｆは木変形関数による木の変換を表す。
【００２８】
例えば、JavaScriptなどのプログラム言語を用いれば、コンテンツＴの中からある開始タグと終了タグとの間のデータを選択し、選択した当該データを変更する命令列を記述することができる。詳細には、JavaScriptには、HTML文書からドキュメントオブジェクトを抽出するgetElementByTagNameなどの関数が設けられている。これを用いれば、HTML文書においてある要素docを取り出し、その要素docに対応する属性attrの値をvalueに変更することができる。部分プログラム５０の例において、変数checkboxには、初期画面のうちイベントを発生させたタグが選択されて格納される。そして、checkbox.setAttributeNS();のメソッドによって、checkboxに格納されたタグの属性が変更されている。
【００２９】
アプリケーションプログラムにおけるこのようなツリー操作命令列を一般化すると、以下の式で表される。
v = doc.getElementByTagName("foo");
v.setAttribute.....
ここで、docはもとのHTML文書を格納するオブジェクトであり、fooは任意のタグの名称とする。getElementByTagNameは、指定された名称の開始タグから終了タグまでの間の文書をdocから取り出す関数とする。取り出された文書は変数vに代入される。変数vがその後の操作を受けると、docに格納されたもとのHTML文書も変更を受ける。即ち、ツリー操作命令列は、HTML文書からドキュメントオブジェクトを抽出する命令、および、抽出したドキュメントオブジェクトを変更する命令を含む。
【００３０】
抽出部３１０がツリー操作命令列を部分プログラム５０に含めて抽出した場合には、生成部３２０は、このツリー操作命令列を以下のように変換する。
$doc1 = getElementByTagName_r($doc0, $vN, "foo");
$v0 = getElementBytagName($doc0, "foo");
$v1 = setAttribute(…, $v0, …);
$vN = …;
ここで、変数$doc0は、ツリー操作命令例による操作前の画面構成を示す。一方、変数$doc1は、ツリー操作命令例による操作後の画面構成を示す。また、変数$v0は、getElementByTagName関数によって元の文書から複写されたドキュメントオブジェクトである複写データを格納する（２行目）。また、変数$vNは、変数$v0に格納された複写データが各種の操作、例えば属性の変更などを経て生成された文書を格納する（３〜４行目）。また、getElementByTagName_rは、画面中のタグfooの開始タグから終了タグまでの間の文書を、変数$vNの内容で置換える関数である。各種の操作を受けた複写データは、元の文書$doc0の一部と置換される（１行目）。
即ち生成部３２０は、ツリー操作命令列を、開始タグと終了タグとの間のデータを初期画面から複写した複写データを生成し、複写データを変更し、変更した当該複写データによって初期画面における複写元のデータを置換する命令列に変換する。
【００３１】
図８の例において具体的には、生成部３２０は、変数checkboxを、２つの中間変数$checkbox1および$checkbox2に変更する。変数$checkbox1は一般例における変数$v0に相当し、変数$checkbox2は一般例における変数$vNに相当し、変数$uncheckedは、一般例における$doc1に相当する。そして、生成部３２０は、変数$checkbox1にオブジェクトevent.targetを代入する命令を生成する。オブジェクトevent.targetの内容は、第１スキーマ情報の定義およびイベントによって具体的に定まる。したがって、生成部３２０は、変数$checkbox1に、event.targetの具体的な内容を代入する命令を生成してもよい。
【００３２】
次に、生成部３２０は、変数$checkbox2にツリー操作命令列の処理結果を代入する命令を生成する。即ち、変数$checkbox2には、変数$checkbox1に格納された画面において、checked属性の属性値をtrueに変更した画面が代入される。そして、生成部３２０は、変数$checkbox2の内容により元の画面を置換した画面を変数$uncheckedに代入する命令を代入する。この結果、操作後の画面を格納する変数$uncheckedには、checked属性の属性値がtrueに変更された画面が代入される。
【００３３】
以上の変換によれば、部分プログラム５０は、それぞれの変数に一度ずつの代入が行われるSSA形式に変換される。但し、関数setAttributeNSは、単一の画面に対する操作を行う関数であるので、このままでは第１スキーマ情報を満たす画面の集合から第２スキーマ情報を満たす画面の集合を求めることはできない。このため、生成部３２０は、関数setAttributeNSについて更に次の変換を行う。
【００３４】
ツリー操作命令列によって得ることができるコンテンツをＴ´とすると、抽象コンテンツ変形関数は、少なくともＴ´∈Ｔｒ（Ｇ）を満たす関数Ｔｒとして定義される。木変形関数が複数の引数を採る場合には、Ｔをコンテンツの組とし、Ｇをスキーマの組とし、Ｆ（Ｔ）∈Ｔｒ（Ｇ）を満たすようなＴｒが抽象コンテンツ変形関数である。このような抽象コンテンツ変形関数の定義としては、トップ・ダウン・ツリー・トランスデューサなどのツリー・トランスデューサや、非特許文献８に示すXML変換言語・クエリー言語の方理論の枠組みを利用することができる。以下にツリー・トランスデューサを例示する。
【００３５】
図９は、部分プログラム５０を中間プログラム６０に変換する処理に用いるツリー・トランスデューサの一例を示す。ツリー・トランスデューサにおいて、状態q1および状態q2の２状態を定義する。関数setAttributeNSによる操作は、状態q1から状態q2への遷移として表される。このツリー・トランスデューサにおいて、状態q1におけるそれぞれのタグは状態q2においてもそのまま維持され、checked属性の属性値のみがtrueに変更されている。
生成部３２０による以上の処理によって図８に例示する中間プログラム６０が生成される。
【００３６】
図３に戻る。続いて、判断部３３０は、中間プログラム６０に基づいて、それぞれの画面が仕様を満たすかを判断する。具体的には、まず、判断部３３０は、初期画面である第１画面が第１スキーマ情報を満たすかを判断する。そして、判断部３３０は、第１スキーマ情報に中間プログラム６０を適用して得られる画面の集合が第２スキーマ情報に準拠しているかを判断する。これらの判断には、非特許文献６などの従来公知の技術を用いることができる。そして、判断部３３０は、第１画面が第１スキーマ情報に準拠し、かつ、第１スキーマ情報に中間プログラム６０を適用して得られる画面の集合が第２スキーマ情報に準拠していることを条件に、それぞれの画面が仕様を満たすと判断する。仕様を満たすと判断された場合には、第２画面の次に表示される第３画面が第３スキーマ情報に準拠することを抽出部３１０に通知して判断させる。
【００３７】
図４は、それぞれの画面が仕様を満たすかを判断する処理の一例を示す。まず、判断部３３０は、第１画面が第１スキーマ情報に準拠するかを判断する（Ｓ４００）。第１画面が第１スキーマ情報に準拠しなければ（Ｓ４００：ＮＯ）、判断部３３０は、仕様を満たさないと判断し（Ｓ４１５）、判断結果を出力して処理を終了する。一方で、第１画面が第１スキーマ情報に準拠していれば（Ｓ４００：ＹＥＳ）、抽出部３１０は、アプリケーションプログラムのうち、第１スキーマ情報に準拠した何れかの画面の表示中にイベントが発生したことに応じ実行される部分プログラム５０を抽出する（Ｓ４２０）。
【００３８】
次に、生成部３２０は、部分プログラム５０に基づいて中間プログラム６０を生成する（Ｓ４３０）。次に、判断部３３０は、第１スキーマ情報に中間プログラム６０を適用することにより第１画面の次に表示し得る画面の集合を求める（Ｓ４４０）。そして、判断部３３０は、求められた画面の集合が第２スキーマ情報に準拠しているかを判断する（Ｓ４５０）。準拠していなければ（Ｓ４５０：ＮＯ）、判断部３３０は、アプリケーションプログラムによって表示され得る画面が仕様を満たさないと判断し（Ｓ４１５）、本図の処理を終了する。この場合、判断部３３０は、第１画面または第２画面がスキーマ情報とはどのように異なるのかを示す情報を生成して出力してもよい。
【００３９】
一方で、準拠していれば（Ｓ４５０：ＹＥＳ）、判断部３３０は、仕様記憶部３００に格納された全てのスキーマ情報について判断が完了したかを判断する（Ｓ４６０）。例えば、第２画面の次に表示される第３画面が満たすべき仕様を定めた第３スキーム情報が仕様記憶部３００に記憶されている場合には、全てのスキーマ情報についてはまだ判断が完了していない。このため、充足判断システム３０はＳ４２０に処理を戻す。即ち、抽出部３１０は、第２スキーマ情報、および、第２画面から第３画面へ表示を切り替えるイベントに基づいて部分プログラムを抽出し、その後の処理を行う。
全てのスキーマ情報について判断が完了したことに応じ（Ｓ４６０：ＹＥＳ）、判断部３３０は、アプリケーションプログラムによって表示される各画面が仕様を満たすと判断し（Ｓ４７０）、判断結果を出力して処理を終了する。
【００４０】
以上、図４を参照して説明した処理によれば、抽出部３１０は、表示され得る複数の画面のそれぞれについて、当該画面の表示中にイベントが発生したことに応じ実行される部分プログラムを、当該画面に対応するスキーマ情報、および、当該画面の表示中に発生しうるイベントに基づいて抽出することができる。そして、生成部３２０は、複数のスキーマ情報のそれぞれについて、当該スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中にイベントが発生した場合に表示される画面の集合を求める中間プログラムを、その画面の表示中に実行される部分プログラムに基づき生成することができる。そして、判断部３３０は、初期画面が第１スキーマ情報に準拠し、かつ、それぞれのスキーマ情報に中間プログラムを適用して得られる画面の集合が、当該スキーマ情報に準拠した画面の次に表示される画面の仕様を定めたスキーマ情報に準拠していることを条件として、それらの画面が仕様を満たすと判断できる。
【００４１】
図５は、充足判断システム３０による判断の概念図である。文書データベース２０は、複数の画面の初期画面を記述したHTML文書と、そのHTML文書を順次変更することにより複数の画面を表示するアプリケーションプログラムとを記憶する。即ち複数の画面のそれぞれもまたHTMLで記述されたウェブページである。また、アプリケーションプログラムとは、ウェブページ中に埋め込まれ、JavaScriptなどで記述されたプログラムであってもよい。
【００４２】
仕様記憶部３００は、複数の画面のそれぞれが満たすべき仕様を定めた複数のスキーマ情報のそれぞれを記憶する。また、仕様記憶部３００は、それぞれの画面から他のそれぞれの画面に表示を切り替えさせるイベントを記憶している。判断部３３０は、まず、初期画面が第１スキーマ情報に準拠するかを判断する。次に、判断部３３０は、第１スキーマ情報に基づき生成された中間プログラム６０によって、第１スキーマ情報に準拠する画面の表示中にイベントが発生した場合に表示され得る画面の集合を求める。判断部３３０は、この画面の集合が第２スキーマ情報に準拠するかを判断する。同様に、判断部３３０は、第２スキーマ情報に基づき生成された中間プログラムによって、第２スキーマ情報に準拠する画面の表示中にイベントが発生した場合に表示され得る画面の集合を求める。また、判断部３３０は、この画面の集合が第３スキーマ情報に準拠するかを判断する。画面が何れかのスキーマ情報に準拠しなくなるか、または、全てのスキーマ情報について判断が完了するまで以上の処理を繰り返す。
【００４３】
以上、本実施形態に係る充足判断システム３０によれば、アプリケーションプログラムによって順次表示される画面のそれぞれが仕様を満たすかを、そのアプリケーションプログラムを実行せずに判断することができる。この判断の際に、ツリー操作命令列を含む部分プログラムが中間プログラムへ変換される。部分プログラムを中間プログラムに変換することよって、単一の画面でなく所定の条件を満たす画面の集合に対し処理を適用可能とすることができる。この結果、プログラムを実際に実行しなくとも、プログラムの実行によって表示し得る画面の集合が仕様を満たすことを効率的に判断することができる。
【００４４】
以下、図１０から図１４を参照して、アプリケーションプログラムがチェックボックスに隣に入力欄を表示する場合について説明する。
図１０は、仕様記憶部３００に記憶された仕様の第２例を示す。チェックボックスのチェックが外れている第１画面の仕様を定めた第１スキーマ情報を図の左下に示す。また、チェックボックスがチェックされている第２画面の仕様を定めた第２スキーマ情報を図の右下に示す。第１画面から第２画面に表示を切り替えさせるイベントは左クリック（Ｔ０）またはスペースキーの押下（Ｔ２）である。第２画面から第１画面に表示を切り替えさせるイベントは左クリック（Ｔ１）またはスペースキーの押下（Ｔ３）である。
図１０に示す第１スキーマ情報は図６を参照して説明した第１スキーマ情報と略同一であるから説明を省略する。第２スキーマ情報は、第１スキーマ情報に加えて、bodyタグの中のspanタグの中に非終端記号G9を含む。G9は、inputタグを含む。即ち、第２スキーマ情報は、第２画面がinputタグを含むべきことを定めている。
【００４５】
図１１は、部分プログラム５０の第２例を示す。説明のために、文書データベース２０に記憶されたアプリケーションプログラムのうち関数checkBoxEventを抜粋して図上部に示す。抽出部３１０は、アプリケーションプログラムに含まれるそれぞれの条件分岐命令について、第１スキーマ情報に規定されたこれらの状態およびイベントに基づいて、何れの分岐先が実行されるかを判断する。図１０に示すように、第１画面から第２画面に表示を切り替えるイベントはマウスの左クリックまたはスペースキーの押下である。このため、３・４行目の条件分岐命令の条件は満たされる。即ち抽出部３１０は、５行目から１６行目までの命令列が実行されると判断する。
【００４６】
また、第１スキーマ情報は、属性値をfalseとするchecked属性を含む。このため、７行目の条件分岐命令の条件は満たされない。即ち、抽出部３１０は、１１行目から始まるelse節が実行されると判断する。抽出部３１０は、このようにして実行されると判断された分岐先の命令列を連続的に並べることにより、部分プログラム５０を生成する。この結果、部分プログラム５０は、checked属性の属性値をtrueに変更する命令と、inputタグを生成する命令とを含む。
【００４７】
図１２は、中間プログラム６０の第２例を示す。説明のために、図１２上段には部分プログラム５０を例示する。生成部３２０は、まず、部分プログラム５０をSSA(Static Single Assignment)変換することにより、それぞれの変数の定義がプログラム中で唯一に定まり、かつ、部分プログラム５０と同一の実行結果が得られる複数の命令を生成する。生成された命令列を図１２中段に示す。本例の部分プログラム５０は、ツリー操作命令列として、初期画面からイベントが発生した部分を取り出す命令と、属性値を変更する命令と、タグを追加する命令とを含む。したがって、変数checkboxは、３回の代入を受ける。
【００４８】
このため、生成部３２０は、変数checkboxを、３つの中間変数$checkbox1、$checkbox2および$checkbox3に変更する。変数$checkbox1は一般例における変数$v0に相当し、変数$checkbox2は一般例における変数$v1に相当し、変数$checkbox3は一般例における変数$vNに相当し、変数$uncheckedは、一般例における$doc1に相当する。そして、生成部３２０は、変数$checkbox1にオブジェクトevent.targetを代入する命令を生成する。次に、生成部３２０は、変数$checkbox2にツリー操作命令列の第１処理結果を代入する命令を生成する。即ち、変数$checkbox2には、変数$checkbox1に格納された画面において、checked属性の属性値をtrueに変更した画面が代入される。次に、生成部３２０は、変数$checkbox3にツリー操作命令列の第２処理結果を代入する命令を生成する。即ち、変数$checkbox3には、変数$checkbox2に格納された画面において、タグinputを追加した画面が代入される。そして、生成部３２０は、変数$checkbox3の内容により元の画面を置換した画面を変数$uncheckedに代入する命令を代入する。この結果、操作後の画面を格納する変数$uncheckedには、checked属性の属性値がtrueに変更され、かつ、タグinputが追加された画面が代入される。
【００４９】
以上の変換によれば、部分プログラム５０は、それぞれの変数に一度ずつの代入が行われるSSA形式に変換される。但し、関数setAttributeNS、関数appendChildおよび関数removeChildは、単一の画面に対する操作を行う関数であるので、このままでは第１スキーマ情報を満たす画面の集合から第２スキーマ情報を満たす画面の集合を求めることはできない。このため、生成部３２０は、関数setAttributeNS、関数appendChildおよび関数removeChildのそれぞれについて、ツリー・トランスデューサを用いた変換を行う。関数setAttributeNSの変換は図９と同一であるので説明を省略する。関数applendChildの変換を図１３に示し、関数removeChildの変換を図１４に示す。
【００５０】
図１３は、部分プログラム５０を中間プログラム６０に変換する処理に用いるツリー・トランスデューサの一例を示す。ツリー・トランスデューサにおいて、状態q1および状態q2の２状態が定義される。関数appendChildによる操作は、状態q1から状態q2への遷移として表される。このツリー・トランスデューサにおいて、状態q1におけるそれぞれのタグは状態q2においてもそのまま維持され、タグinputのみが追加されている。但し、変数$checkbox1についてはそのままではツリー・トランスデューサによって取り扱えないため、生成部３２０は、これを２分木にエンコードする。詳しくは非特許文献７などにおいて従来公知であるから説明を省略する。
【００５１】
図１４は、部分プログラム５０を中間プログラム６０に変換する処理に用いるツリー・トランスデューサの一例を示す。ツリー・トランスデューサにおいて、状態q1および状態q2の２状態が定義される。関数removeChildによる操作は、状態q1から状態q2への遷移として表される。このツリー・トランスデューサにおいて、状態q1におけるそれぞれのタグは状態q2においてもそのまま維持され、タグinputのみが削除されている。なお、図１４に例示したツリー・トランスデューサは、inputという名称のタグがHTML文書中にただ１つ存在することを前提とする。HTML文書中にinputという名称のタグが複数含まれる場合には、それぞれのタグを識別可能とするべく、それぞれのタグに識別可能な番号を付し、または、それぞれのタグを他の名称に変更する必要がある。また、以上に説明したようなツリー・トランスデューサでは取り扱いができないような処理については非特許文献６および非特許文献７に詳しいので説明を省略する。
【００５２】
以上、図１０から図１４を参照して説明したように、充足判断システム３０によれば、チェックボックスがチェックされたときにその隣に入力欄を表示させるアプリケーションプログラムについても、当該プログラムによって表示されるそれぞれの画面が仕様を満たすことを効率的に判断することができる。
【００５３】
図１５は、充足判断システム３０として機能する情報処理装置５００のハードウェア構成の一例を示す。情報処理装置５００は、ホストコントローラ１０８２により相互に接続されるＣＰＵ１０００、ＲＡＭ１０２０、及びグラフィックコントローラ１０７５を有するＣＰＵ周辺部と、入出力コントローラ１０８４によりホストコントローラ１０８２に接続される通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を有する入出力部と、入出力コントローラ１０８４に接続されるＲＯＭ１０１０、フレキシブルディスクドライブ１０５０、及び入出力チップ１０７０を有するレガシー入出力部とを備える。
【００５４】
ホストコントローラ１０８２は、ＲＡＭ１０２０と、高い転送レートでＲＡＭ１０２０をアクセスするＣＰＵ１０００及びグラフィックコントローラ１０７５とを接続する。ＣＰＵ１０００は、ＲＯＭ１０１０及びＲＡＭ１０２０に格納されたプログラムに基づいて動作し、各部の制御を行う。グラフィックコントローラ１０７５は、ＣＰＵ１０００等がＲＡＭ１０２０内に設けたフレームバッファ上に生成する画像データを取得し、表示装置１０８０上に表示させる。これに代えて、グラフィックコントローラ１０７５は、ＣＰＵ１０００等が生成する画像データを格納するフレームバッファを、内部に含んでもよい。
【００５５】
入出力コントローラ１０８４は、ホストコントローラ１０８２と、比較的高速な入出力装置である通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を接続する。通信インターフェイス１０３０は、ネットワークを介して外部の装置と通信する。ハードディスクドライブ１０４０は、情報処理装置５００が使用するプログラム及びデータを格納する。ＣＤ−ＲＯＭドライブ１０６０は、ＣＤ−ＲＯＭ１０９５からプログラム又はデータを読み取り、ＲＡＭ１０２０又はハードディスクドライブ１０４０に提供する。
【００５６】
また、入出力コントローラ１０８４には、ＲＯＭ１０１０と、フレキシブルディスクドライブ１０５０や入出力チップ１０７０等の比較的低速な入出力装置とが接続される。ＲＯＭ１０１０は、情報処理装置５００の起動時にＣＰＵ１０００が実行するブートプログラムや、情報処理装置５００のハードウェアに依存するプログラム等を格納する。フレキシブルディスクドライブ１０５０は、フレキシブルディスク１０９０からプログラム又はデータを読み取り、入出力チップ１０７０を介してＲＡＭ１０２０またはハードディスクドライブ１０４０に提供する。入出力チップ１０７０は、フレキシブルディスク１０９０や、例えばパラレルポート、シリアルポート、キーボードポート、マウスポート等を介して各種の入出力装置を接続する。
【００５７】
情報処理装置５００に提供されるプログラムは、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５、又はＩＣカード等の記録媒体に格納されて利用者によって提供される。プログラムは、入出力チップ１０７０及び/又は入出力コントローラ１０８４を介して、記録媒体から読み出され情報処理装置５００にインストールされて実行される。プログラムが情報処理装置５００等に働きかけて行わせる動作は、図１から図１４において説明した充足判断システム３０における動作と同一であるから、説明を省略する。
【００５８】
以上に示したプログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としては、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５の他に、ＤＶＤやＰＤ等の光学記録媒体、ＭＤ等の光磁気記録媒体、テープ媒体、ＩＣカード等の半導体メモリ等を用いることができる。また、専用通信ネットワークやインターネットに接続されたサーバシステムに設けたハードディスク又はＲＡＭ等の記憶装置を記録媒体として使用し、ネットワークを介してプログラムを情報処理装置５００に提供してもよい。
【００５９】
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【図面の簡単な説明】
【００６０】
【図１】図１は、情報処理システム１０の全体構成を示す。
【図２】図２は、文書データベース２０に記憶されたデータの一例を示す。
【図３】図３は、充足判断システム３０の機能構成を示す。
【図４】図４は、それぞれの画面が仕様を満たすかを判断する処理の一例を示す。
【図５】図５は、充足判断システム３０による判断の概念図である。
【図６】図６は、仕様記憶部３００に記憶された仕様の第１例を示す。
【図７】図７は、部分プログラム５０の第１例を示す。
【図８】図８は、中間プログラム６０の第１例を示す。
【図９】図９は、部分プログラム５０を中間プログラム６０に変換する処理に用いるツリー・トランスデューサの一例を示す。
【図１０】図１０は、仕様記憶部３００に記憶された仕様の第２例を示す。
【図１１】図１１は、部分プログラム５０の第２例を示す。
【図１２】図１２は、中間プログラム６０の第２例を示す。
【図１３】図１３は、部分プログラム５０を中間プログラム６０に変換する処理に用いるツリー・トランスデューサの一例を示す。
【図１４】図１４は、部分プログラム５０を中間プログラム６０に変換する処理に用いるツリー・トランスデューサの一例を示す。
【図１５】図１５は、充足判断システム３０として機能する情報処理装置５００のハードウェア構成の一例を示す。
【符号の説明】
【００６１】
１０ 情報処理システム
２０ 文書データベース
３０ 充足判断システム
５０ 部分プログラム
６０ 中間プログラム
３００ 仕様記憶部
３１０ 抽出部
３２０ 生成部
３３０ 判断部
５００ 情報処理装置
【特許請求の範囲】
【請求項１】
アプリケーションプログラムによって順次表示される複数の画面が予め定められた仕様を満たすかを判断するシステムであって、
第１画面の構成が満たすべき仕様を定めた第１スキーマ情報、第２画面の構成が満たすべき仕様を定めた第２スキーマ情報、および、前記アプリケーションプログラムによる表示を前記第１画面から前記第２画面に切り替えさせるイベントを記憶した仕様記憶部と、
前記アプリケーションプログラムのうち、前記第１スキーマ情報に準拠した何れかの画面の表示中に前記イベントが発生したことに応じ実行される部分プログラムを、前記第１スキーマ情報および前記イベントに基づいて抽出する抽出部と、
前記第１スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中に前記イベントが発生した場合に表示される画面の集合を求める中間プログラムを、前記部分プログラムに基づいて生成する生成部と、
前記第１画面が前記第１スキーマ情報に準拠し、かつ、前記第１スキーマ情報に前記中間プログラムを適用して得られる画面の集合が前記第２スキーマ情報に準拠していることを条件として、前記複数の画面が予め定められた仕様を満たすと判断する判断部と
を備えるシステム。
【請求項２】
前記抽出部は、前記アプリケーションプログラムに含まれるそれぞれの条件分岐命令について、前記第１スキーマ情報に規定された画面の状態および前記イベントに基づいて、何れの分岐先が実行されるかを判断し、実行されると判断した分岐先の命令列を前記部分プログラムに含めて抽出する
請求項１に記載のシステム。
【請求項３】
前記生成部は、前記部分プログラムをSSA（Static Single Assignment）変換することにより、それぞれの変数への代入が前記部分プログラム中で唯一に定まり、かつ、前記部分プログラムと同一の実行結果が得られる複数の命令を前記中間プログラムとして生成する
請求項１に記載のシステム。
【請求項４】
前記複数の画面のそれぞれは、開始タグと終了タグとの間に他の開始タグと終了タグとを含むツリー構造のデータであり、
前記抽出部は、ある開始タグと終了タグとの間のデータを前記第１画面から選択し、選択した当該データを変更する命令列であるツリー操作命令列を、前記部分プログラムに含めて抽出し、
前記生成部は、前記ツリー操作命令列を、当該開始タグと終了タグとの間のデータを前記第１画面から複写した複写データを生成し、前記複写データを変更し、変更した当該複写データによって前記第１画面における複写元のデータを置換する命令列に変換する
請求項３に記載のシステム。
【請求項５】
前記複数の画面のそれぞれは、HTML(Hyper Text Markup Language)で記述されたウェブページであり、
前記アプリケーションプログラムは、JavaScriptで記述され、当該ウェブページの表示を変更する変更プログラムであり、
前記抽出部は、前記変更プログラムの中から、HTML文書からドキュメントオブジェクトを抽出する命令、および、抽出した前記ドキュメントオブジェクトを変更する命令を、前記ツリー操作命令列として抽出し、
前記生成部は、前記ツリー操作命令列を、HTML文書から抽出したドキュメントオブジェクトを複写して前記複写データを生成し、前記複写データを変更し、変更した当該複写データによってHTML文書のドキュメントオブジェクトを置換する命令列に変換する
請求項４に記載のシステム。
【請求項６】
前記仕様記憶部は、前記複数の画面のそれぞれが満たすべき仕様を定めた複数のスキーマ情報のそれぞれと、前記複数の画面のそれぞれから他のそれぞれの画面に表示を切り替えさせるイベントとを記憶しており、
前記抽出部は、前記複数の画面のそれぞれについて、当該画面の表示中にイベントが発生したことに応じ実行される部分プログラムを、当該画面に対応するスキーマ情報、および、当該画面の表示中に発生しうるイベントに基づいて抽出し、
前記生成部は、前記複数のスキーマ情報のそれぞれについて、当該スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中に前記イベントが発生した場合に表示される画面の集合を求める中間プログラムを、当該画面の表示中に実行される前記部分プログラムに基づいて生成し、
前記判断部は、初期画面である前記第１画面が前記第１スキーマ情報に準拠し、かつ、それぞれの前記スキーマ情報に前記中間プログラムを適用して得られる画面の集合が、当該スキーマ情報に準拠した画面の次に表示される画面の仕様を定めたスキーマ情報に準拠していることを条件として、前記複数の画面が予め定められた仕様を満たすと判断する
請求項１に記載のシステム。
【請求項７】
アプリケーションプログラムによって順次表示される複数の画面が予め定められた仕様を満たすかを情報処理装置によって判断する方法であって、
前記情報処理装置は、第１画面の構成が満たすべき仕様を定めた第１スキーマ情報、第２画面の構成が満たすべき仕様を定めた第２スキーマ情報、および、前記アプリケーションプログラムによる表示を前記第１画面から前記第２画面に切り替えさせるイベントを記憶した仕様記憶部を有し、
前記アプリケーションプログラムのうち、前記第１スキーマ情報に準拠した何れかの画面の表示中に前記イベントが発生したことに応じ実行される部分プログラムを、前記第１スキーマ情報および前記イベントに基づいて抽出するステップと、
前記第１スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中に前記イベントが発生した場合に表示される画面の集合を求める中間プログラムを、前記部分プログラムに基づいて生成するステップと、
前記第１画面が前記第１スキーマ情報に準拠し、かつ、前記第１スキーマ情報に前記中間プログラムを適用して得られる画面の集合が前記第２スキーマ情報に準拠していることを条件として、前記複数の画面が予め定められた仕様を満たすと判断するステップと
を備える方法。
【請求項８】
アプリケーションプログラムによって順次表示される複数の画面が予め定められた仕様を満たすかを判断するシステムとして、情報処理装置を機能させるプログラムであって、
前記情報処理装置を、
第１画面の構成が満たすべき仕様を定めた第１スキーマ情報、第２画面の構成が満たすべき仕様を定めた第２スキーマ情報、および、前記アプリケーションプログラムによる表示を前記第１画面から前記第２画面に切り替えさせるイベントを記憶した仕様記憶部と、
前記アプリケーションプログラムのうち、前記第１スキーマ情報に準拠した何れかの画面の表示中に前記イベントが発生したことに応じ実行される部分プログラムを、前記第１スキーマ情報および前記イベントに基づいて抽出する抽出部と、
前記第１スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中に前記イベントが発生した場合に表示される画面の集合を求める中間プログラムを、前記部分プログラムに基づいて生成する生成部と、
前記第１画面が前記第１スキーマ情報に準拠し、かつ、前記第１スキーマ情報に前記中間プログラムを適用して得られる画面の集合が前記第２スキーマ情報に準拠していることを条件として、前記複数の画面が予め定められた仕様を満たすと判断する判断部と
して機能させるプログラム。
【請求項１】
アプリケーションプログラムによって順次表示される複数の画面が予め定められた仕様を満たすかを判断するシステムであって、
第１画面の構成が満たすべき仕様を定めた第１スキーマ情報、第２画面の構成が満たすべき仕様を定めた第２スキーマ情報、および、前記アプリケーションプログラムによる表示を前記第１画面から前記第２画面に切り替えさせるイベントを記憶した仕様記憶部と、
前記アプリケーションプログラムのうち、前記第１スキーマ情報に準拠した何れかの画面の表示中に前記イベントが発生したことに応じ実行される部分プログラムを、前記第１スキーマ情報および前記イベントに基づいて抽出する抽出部と、
前記第１スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中に前記イベントが発生した場合に表示される画面の集合を求める中間プログラムを、前記部分プログラムに基づいて生成する生成部と、
前記第１画面が前記第１スキーマ情報に準拠し、かつ、前記第１スキーマ情報に前記中間プログラムを適用して得られる画面の集合が前記第２スキーマ情報に準拠していることを条件として、前記複数の画面が予め定められた仕様を満たすと判断する判断部と
を備えるシステム。
【請求項２】
前記抽出部は、前記アプリケーションプログラムに含まれるそれぞれの条件分岐命令について、前記第１スキーマ情報に規定された画面の状態および前記イベントに基づいて、何れの分岐先が実行されるかを判断し、実行されると判断した分岐先の命令列を前記部分プログラムに含めて抽出する
請求項１に記載のシステム。
【請求項３】
前記生成部は、前記部分プログラムをSSA（Static Single Assignment）変換することにより、それぞれの変数への代入が前記部分プログラム中で唯一に定まり、かつ、前記部分プログラムと同一の実行結果が得られる複数の命令を前記中間プログラムとして生成する
請求項１に記載のシステム。
【請求項４】
前記複数の画面のそれぞれは、開始タグと終了タグとの間に他の開始タグと終了タグとを含むツリー構造のデータであり、
前記抽出部は、ある開始タグと終了タグとの間のデータを前記第１画面から選択し、選択した当該データを変更する命令列であるツリー操作命令列を、前記部分プログラムに含めて抽出し、
前記生成部は、前記ツリー操作命令列を、当該開始タグと終了タグとの間のデータを前記第１画面から複写した複写データを生成し、前記複写データを変更し、変更した当該複写データによって前記第１画面における複写元のデータを置換する命令列に変換する
請求項３に記載のシステム。
【請求項５】
前記複数の画面のそれぞれは、HTML(Hyper Text Markup Language)で記述されたウェブページであり、
前記アプリケーションプログラムは、JavaScriptで記述され、当該ウェブページの表示を変更する変更プログラムであり、
前記抽出部は、前記変更プログラムの中から、HTML文書からドキュメントオブジェクトを抽出する命令、および、抽出した前記ドキュメントオブジェクトを変更する命令を、前記ツリー操作命令列として抽出し、
前記生成部は、前記ツリー操作命令列を、HTML文書から抽出したドキュメントオブジェクトを複写して前記複写データを生成し、前記複写データを変更し、変更した当該複写データによってHTML文書のドキュメントオブジェクトを置換する命令列に変換する
請求項４に記載のシステム。
【請求項６】
前記仕様記憶部は、前記複数の画面のそれぞれが満たすべき仕様を定めた複数のスキーマ情報のそれぞれと、前記複数の画面のそれぞれから他のそれぞれの画面に表示を切り替えさせるイベントとを記憶しており、
前記抽出部は、前記複数の画面のそれぞれについて、当該画面の表示中にイベントが発生したことに応じ実行される部分プログラムを、当該画面に対応するスキーマ情報、および、当該画面の表示中に発生しうるイベントに基づいて抽出し、
前記生成部は、前記複数のスキーマ情報のそれぞれについて、当該スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中に前記イベントが発生した場合に表示される画面の集合を求める中間プログラムを、当該画面の表示中に実行される前記部分プログラムに基づいて生成し、
前記判断部は、初期画面である前記第１画面が前記第１スキーマ情報に準拠し、かつ、それぞれの前記スキーマ情報に前記中間プログラムを適用して得られる画面の集合が、当該スキーマ情報に準拠した画面の次に表示される画面の仕様を定めたスキーマ情報に準拠していることを条件として、前記複数の画面が予め定められた仕様を満たすと判断する
請求項１に記載のシステム。
【請求項７】
アプリケーションプログラムによって順次表示される複数の画面が予め定められた仕様を満たすかを情報処理装置によって判断する方法であって、
前記情報処理装置は、第１画面の構成が満たすべき仕様を定めた第１スキーマ情報、第２画面の構成が満たすべき仕様を定めた第２スキーマ情報、および、前記アプリケーションプログラムによる表示を前記第１画面から前記第２画面に切り替えさせるイベントを記憶した仕様記憶部を有し、
前記アプリケーションプログラムのうち、前記第１スキーマ情報に準拠した何れかの画面の表示中に前記イベントが発生したことに応じ実行される部分プログラムを、前記第１スキーマ情報および前記イベントに基づいて抽出するステップと、
前記第１スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中に前記イベントが発生した場合に表示される画面の集合を求める中間プログラムを、前記部分プログラムに基づいて生成するステップと、
前記第１画面が前記第１スキーマ情報に準拠し、かつ、前記第１スキーマ情報に前記中間プログラムを適用して得られる画面の集合が前記第２スキーマ情報に準拠していることを条件として、前記複数の画面が予め定められた仕様を満たすと判断するステップと
を備える方法。
【請求項８】
アプリケーションプログラムによって順次表示される複数の画面が予め定められた仕様を満たすかを判断するシステムとして、情報処理装置を機能させるプログラムであって、
前記情報処理装置を、
第１画面の構成が満たすべき仕様を定めた第１スキーマ情報、第２画面の構成が満たすべき仕様を定めた第２スキーマ情報、および、前記アプリケーションプログラムによる表示を前記第１画面から前記第２画面に切り替えさせるイベントを記憶した仕様記憶部と、
前記アプリケーションプログラムのうち、前記第１スキーマ情報に準拠した何れかの画面の表示中に前記イベントが発生したことに応じ実行される部分プログラムを、前記第１スキーマ情報および前記イベントに基づいて抽出する抽出部と、
前記第１スキーマ情報に準拠する画面の集合から、当該集合に属する画面の表示中に前記イベントが発生した場合に表示される画面の集合を求める中間プログラムを、前記部分プログラムに基づいて生成する生成部と、
前記第１画面が前記第１スキーマ情報に準拠し、かつ、前記第１スキーマ情報に前記中間プログラムを適用して得られる画面の集合が前記第２スキーマ情報に準拠していることを条件として、前記複数の画面が予め定められた仕様を満たすと判断する判断部と
して機能させるプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２００７−２７９７９５（Ｐ２００７−２７９７９５Ａ）
【公開日】平成１９年１０月２５日（２００７．１０．２５）
【国際特許分類】
【出願番号】特願２００６−１０１５８４（Ｐ２００６−１０１５８４）
【出願日】平成１８年４月３日（２００６．４．３）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成１７年度、独立行政法人情報通信機構「視覚障害者向けマルチメディアブラウジング技術の研究開発」委託研究
【出願人】（５９２０７３１０１）日本アイ・ビー・エム株式会社 (42)
【復代理人】
【識別番号】１００１０４１５６
【弁理士】
【氏名又は名称】龍華 明裕
【Ｆターム（参考）】
【公開日】平成１９年１０月２５日（２００７．１０．２５）
【国際特許分類】
【出願日】平成１８年４月３日（２００６．４．３）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成１７年度、独立行政法人情報通信機構「視覚障害者向けマルチメディアブラウジング技術の研究開発」委託研究
【出願人】（５９２０７３１０１）日本アイ・ビー・エム株式会社 (42)
【復代理人】
【識別番号】１００１０４１５６
【弁理士】
【氏名又は名称】龍華 明裕
【Ｆターム（参考）】
[ Back to top ]