JP6440200B2

JP6440200B2 - Ｇｕｉの画面遷移を自動化するプログラム、装置及び方法

Info

Publication number: JP6440200B2
Application number: JP2015121491A
Authority: JP
Inventors: 大輔荒井; 智彦大岸
Original assignee: KDDI Corp
Current assignee: KDDI Corp
Priority date: 2015-06-16
Filing date: 2015-06-16
Publication date: 2018-12-19
Anticipated expiration: 2035-06-16
Also published as: JP2017010088A

Description

本発明は、ＧＵＩ(Graphic User Interface)の操作を自動化する技術に関する。

通信事業者（通信キャリア、サービスプロバイダ、クラウドサービス等の事業者）は、高速・大容量なネットワークを介して、ユーザ操作の端末に対して計算機リソースやクラウドサービスを提供する。このようなネットワークには、大量の通信事業設備（通信機器やサーバ装置）が設置されており、具体的には１つのデータセンタで１０万〜２０万台程度のノードが運用管理されている。通信事業者にとって、これら大規模な通信事業設備を、低コストで且つ自動的（効率的）に運用管理することが重要となる。

通信事業設備の群には、標準化された自動化プロトコルに対応した機能がインストールされている。オペレータから大規模なシステム全体を統一的に運用管理するために、例えばTelnet又はＳＳＨ(Secure Shell)のようなＣＬＩ(Command Line Interface)や、ＳＮＭＰ(Simple Network Management Protocol)を用いる場合が多い。

例えばGoogle（登録商標）やFacebook（登録商標）のデータセンタでは、大規模な通信事業設備に対して先進的な運用管理がなされている。Googleによれば、通信事業設備自体を自ら専用に開発し、画一的に運用管理できるように構成している（例えば非特許文献１参照）。
また、Facebookによれば、ＯＣＰ(Open Compute Project、例えば非特許文献２参照）を提唱し、スケーラブルなコンピューティングにとって、最も効率のよいサーバ／ストレージ／データセンタなどのハードウェアを設計している。
勿論、これら取組みは、単一の通信事業者が、大量の通信事業設備を購入できるケースでは有効である。一方で、その他の一般的な通信事業者の通信事業設備は、異なる機器ベンダや通信機器が混在した、マルチベンダ・マルチデバイス環境が一般的である。これは、機器導入の安定性のリスクや、コストの低減を勘案したものであって、画一的な通信事業設備を構成することは難しい。

また、運用対象機器となる大量のサーバ装置に、予めクライアント機能をインストールすることによって、管理サーバから集中的に運用管理する自動化技術がある（例えば非特許文献３参照）。この技術によれば、管理サーバが、運用管理用のrubyスクリプトを登録し、その運用管理情報が、クライアント機能によって各機器に反映される。特にサービスプロバイダによって積極的に採用されている。
また、ＯＳ(Operating System)で駆動するネットワーク機器に対しても、Linux（登録商標）等の汎用ＯＳを採用することによって、統一的な運用管理を実現しようとしている。但し、既設の（拡張性の少ない）ネットワーク機器に対してまで、運用管理用のクライアント機能の追加導入を適用することはできない。

更に、ネットワーク機器を対象とした設定管理プロトコルの標準化技術（例えば非特許文献４参照）や、それを活用したマルチベンダ・マルチデバイス環境の運用自動化技術がある（例えば非特許文献５参照）。これら技術も、NETCONFに代表される自動化プロトコルをサポートする機器や、前述したＣＬＩ又はＳＮＭＰによる運用管理を前提としている。

S. Jain et al., "B4: Experience with a Globally-Deployed Software Defined WAN, " proc. of the ACM SIGCOMM 2013, pp. 3-14 Open Compute Project (OCP)、[online]、［平成２７年６月３日検索］、インターネット＜URL:http://opencompute.org/＞ Chef、[online]、［平成２７年６月３日検索］、インターネット＜URL:https://www.chef.io/chef/＞ IETF RFC6241 NETCONF (Network Configuration Protocol)、[online]、［平成２７年６月３日検索］、インターネット＜URL:https://tools.ietf.org/html/rfc6241＞ Cisco、[online]、［平成２７年６月３日検索］、インターネット＜URL:http://www.tail-f.com/＞ Sikuli、[online]、［平成２７年６月３日検索］、インターネット＜URL:http://www.sikuli.org/＞ T.H. Chang et al., "GUI Testing Using Computer Vision," proc. of the SIGCHI Conference on Human Factors in Computing Systems 2010 (CHI’ 10), pp. 1535-1544 Pywinauto、[online]、［平成２７年６月３日検索］、インターネット＜URL:https://code.google.com/p/pywinauto/＞ A. Memon et al., "The first decade of GUI ripping: Extensions, applications, and broader impacts, " proc. of 20th Working Conference on Reverse Engineering (WCRE), 2013 pp. 11-20

通信機器には、ユーザからの設定や状態確認を容易にするために、専用ＧＵＩによって遠隔から運用管理できるようにしたものがあるが、その機種毎に個々に、専用ＧＵＩを用いて運用管理することは難しい。しかしながら、現実的には、オペレータに対するユーザインタフェースとして、専用ＧＵＩ経由でしか操作を許可しない通信機器も存在する。このような通信機器であっても、導入コストの観点から、通信事業設備として運用せざるを得ないケースも多い。ここで、このような専用ＧＵＩ経由でしか操作を許可しない通信機器に対する運用管理の自動化が重要となる。

図１は、コマンドラインインタフェースとグラフィックユーザインタフェースとを比較した運用管理の遷移を表す説明図である。

図１（ａ）によれば、オペレータの運用管理を自動化する基本的な３つの作業ステップを表す。
Ｓ１：状態確認（機器の現時点の設定状態を確認する）
Ｓ２：設定（機器の設定を変更する）
Ｓ３：状態確認（機器の現時点の設定状態を再度確認する）

図１（ｂ）によれば、図１（ａ）に対応して、TelnetやＳＳＨのようなＣＬＩに基づく操作内容を表す。ＣＬＩを用いる場合、作業ステップと対応付けてコマンドを入力することできる。ここで、設定や状態確認の作業ステップ毎に、１つ以上のコマンド列から構成したモジュール（スクリプト）を作成することによって、そのモジュールを再利用（同一処理を実行）することができる。

図１（ｃ）によれば、図１（ａ）に対応したＧＵＩの画面（ページ）を表す。ここでも同様に、作業ステップと対応付けた画面を表示させることができる。

しかしながら、ＧＵＩは、オペレータ所望の目標画面を自動的に開くためには、ページ毎に遷移可能な状態管理が必要となる(stateful)。ＧＵＩの場合、「目標画面」への遷移経路は、「現表示画面」によって異なる。そのために、「目標画面」までの遷移経路を自動化したスクリプトは、「現表示画面」毎に作成する必要があり、その再利用性は低くなる。全く同じ「現表示画面」「目標画面」の組み合わせでしか、そのスクリプトを再利用することができない。即ち、再利用可能なスクリプトを繰り返し利用することによって、自動化手順の品質が向上することを期待できない。
また、意図しない画面から目標画面へ遷移することができず、全ての画面から目標画面へ遷移するようにプログラムする必要もある。特に、機器の設定状態に応じて、例えば注意喚起やエラーを表示するためのポップアップ画面が表示された場合には、これらの画面からの遷移も考慮する必要がある。

図２は、グラフィックユーザインタフェースにおける画面遷移の切替を表す説明図である。

図２によれば、図１（ｃ）のような画面を開くために、最短で８回もの画面遷移を要する。
トップ画面Ａ->画面１->「状態確認画面Ｂ」->画面１->画面２->画面３
->「設定画面Ｃ」->画面２->「状態確認画面Ｂ」
ここで、「状態確認画面Ｂ」を表示する場合であっても、画面１から遷移する場合もあれば、画面２から遷移する場合もある。また、「設定画面Ｃ」を表示する場合には、必ず画面３から遷移する必要がある。このようにＧＵＩの場合、画面毎に遷移可能な状態を持つこととなる。状態管理が不要な図１（ｂ）のＣＬＩのように、画面遷移の処理モジュールを再利用することが難しい。

そこで、本発明は、ＧＵＩの画面遷移を再利用性の高いスクリプトで構成することによって、運用管理の自動化を実現するプログラム、装置及び方法を提供することを目的とする。

本発明によれば、複数の画面を遷移するグラフィックユーザインタフェースとしてコンピュータを機能させるユーザインタフェースプログラムにおいて、
ユーザ操作によって表示可能な全ての各画面を頂点とし、各画面から１回の操作で遷移可能な他の画面への遷移を有向辺とした有向グラフについて、有向辺毎に、遷移処理を実行するスクリプトを用いて、
ユーザによって遷移先画面が指定された際に、有向グラフに基づいて、現表示画面から遷移先画面までの経路を探索する経路探索手段と、
経路を通過する１つ以上の有向辺に基づくスクリプトを選択するスクリプト選択手段と、
選択されたスクリプトを経路順に実行するスクリプト実行手段と
してコンピュータを機能させることを特徴とする。

本発明のユーザインタフェースプログラムにおける他の実施形態によれば、
ユーザ操作によって表示可能な全ての各画面を頂点とし、各画面から１回の操作で遷移可能な他の画面への遷移を有向辺として、有向グラフを生成する有向グラフ生成手段と、
有向辺毎に、遷移処理を実行するスクリプトを生成するスクリプト生成手段と
してコンピュータを更に機能させることも好ましい。

本発明のユーザインタフェースプログラムにおける他の実施形態によれば、
遷移先画面毎に、コマンドを割り当て、
経路探索手段は、ユーザによってコマンドが命令された際に、現表示画面から、当該コマンドに対応する遷移先画面までの経路を探索する
ようにコンピュータを機能させることも好ましい。

本発明のユーザインタフェースプログラムにおける他の実施形態によれば、
コマンドラインインタフェースとして、グラフィックユーザインタフェースの画面間の遷移が制御される
ようにコンピュータを機能させることも好ましい。

本発明のユーザインタフェースプログラムにおける他の実施形態によれば、
経路探索手段は、幅優先探索(breadth first search)に基づいて最短経路を探索する
ようにコンピュータを機能させることも好ましい。

本発明のユーザインタフェースプログラムにおける他の実施形態によれば、
スクリプト生成手段は、画面内の操作及び画面遷移の操作を自動化するためにSikuli（登録商標）を用いる
ようにコンピュータを機能させることも好ましい。

本発明によれば、複数の画面を遷移するグラフィックユーザインタフェースをユーザに表示する装置において、
ユーザ操作によって表示可能な全ての各画面を頂点とし、各画面から１回の操作で遷移可能な他の画面への遷移を有向辺とした有向グラフについて、有向辺毎に、遷移処理を実行するスクリプトを用いて、
ユーザによって遷移先画面が指定された際に、有向グラフに基づいて、現表示画面から遷移先画面までの経路を探索する経路探索手段と、
経路を通過する１つ以上の有向辺に基づくスクリプトを選択するスクリプト選択手段と、
選択されたスクリプトを経路順に実行するスクリプト実行手段と
を有することを特徴とする。

本発明によれば、複数の画面を遷移するグラフィックユーザインタフェースを有する装置の画面遷移方法において、
ユーザ操作によって表示可能な全ての各画面を頂点とし、各画面から１回の操作で遷移可能な他の画面への遷移を有向辺とした有向グラフについて、有向辺毎に、遷移処理を実行するスクリプトを用いて、
ユーザによって遷移先画面が指定された際に、有向グラフに基づいて、現表示画面から遷移先画面までの経路を探索するステップと、
経路を通過する１つ以上の有向辺に基づくスクリプトを選択するステップと、
選択されたスクリプトを経路順に実行するステップと
を有することを特徴とする。

本発明のプログラム、装置及び方法によれば、ＧＵＩの画面遷移を再利用性の高いスクリプトで構成することによって、運用管理の自動化を実現することができる。

コマンドラインインタフェースとグラフィックユーザインタフェースとを比較した運用管理の遷移を表す説明図である。グラフィックユーザインタフェースにおける画面遷移の切替を表す説明図である。本発明のグラフィックユーザインタフェースプログラムにおける機能構成図である。画面遷移の有向グラフを表す説明図である。本発明における有向辺スクリプトの画面遷移を表す説明図である。本発明の画面遷移の処理を表すプログラムコードである。

以下、本発明の実施の形態について、図面を用いて詳細に説明する。

図３は、本発明のグラフィックユーザインタフェースプログラムにおける機能構成図である。

図３によれば、端末１は、専用ＧＵＩを持つ対象機器を運用管理するものであって、オペレータによって操作される。ＧＵＩの画面は、遠隔の対象機器を操作するためのものであって、例えばＨＴＭＬ(Hypertext Markup Language)のようなテキストマークアップ言語によって記述されたものであってもよい。

図３によれば、端末１にインストールされたグラフィックユーザインタフェースプログラムは、有向グラフ生成部１１と、有向グラフ蓄積部１１０と、スクリプト生成部１２と、スクリプト蓄積部１２０と、経路探索部１３と、スクリプト選択部１４と、スクリプト実行部１５とを有する。これら機能構成部は、端末（装置）に搭載されたコンピュータを機能させるプログラムを実行することによって実現される。尚、これら機能構成部の処理の流れは、画面遷移方法としても理解できる。

［有向グラフ生成部１１・有向グラフ蓄積部１１０］
有向グラフ生成部１１は、ＧＵＩの画面間を結ぶ有向グラフを生成する。
・ユーザ操作によって表示可能な全ての各画面（ページ）を「頂点」とする。
・各画面から１回の操作で遷移可能な他の画面への遷移を「有向辺」とする。
ここでの有向グラフは、単に頂点間を結ぶ辺であって、重み無しのものであってもよい。

有向グラフ自体は、既存のＧＵＩリッピング技術を用いて生成することができる（例えば非特許文献９参照）。この技術によれば、画面の中でページ遷移可能な全てのボタンを順次クリックしながら、リバースエンジニアリングによって画面遷移を辿っていき、最終的に画面の有向グラフ（テストシナリオ）を生成する。この技術は、主にＧＵＩアプリケーションを開発する開発者が、画面表示を網羅的に確認するためのテストツールである。
また、有向グラフ蓄積部１１０は、有向グラフ生成部１１によって生成された有向グラフを蓄積する。

図４は、画面遷移の有向グラフを表す説明図である。

図４によれば、７枚の画面（頂点）が、１１個の有向辺によって結ばれている。これは、有向グラフ生成部１１のＧＵＩリッピングによって自動的に生成されたものである。

［スクリプト生成部１２・スクリプト蓄積部１２０］
スクリプト生成部１２は、有向辺毎に、遷移処理を実行するスクリプトを生成する。「スクリプト」とは、機械語へのコンパイル（変換）を実行する必要がない簡易プログラムをいう。一般に、実行形式のプログラムは、ソースコードを機械語にコンパイルする必要があるのに対して、スクリプトはコンパイルを必要としない。

ここで、スクリプト生成部１２は、画面内の操作及び画面遷移の操作を自動化するために、例えばSikuli（登録商標）を用いる。この技術は、例えば「検索欄に単語を入力して検索ボタンを押下」のような操作を自動化することができる。操作対象のユーザインタフェース部品を自動的に発見するために、「画像認識」機能を搭載している。そのユーザインタフェース部品の画像（スクリーンショット）と、その部品に対する操作方法とを一緒にスクリプトとして記述することができる。スクリプト記述言語としては、例えばJythonやJRubyが用いられる。Sikuliによれば、アプリケーションに対する起動、停止、カーソル移動、マウスクリック、ドラッグ＆ドロップ、キーボード入力等、様々な操作を自動化することができる。

ＧＵＩによれば、例えばページ（画面）に表示されたページ遷移ボタンをクリックすることによって、次のページへ遷移することができる。ここで、スクリプト生成部１２は、有向辺毎に、その画面の「ページ遷移ボタン」をクリックするように、Sikuliでプログラムする。これによって、画面遷移自体をスクリプトによって自動化することができる。

尚、ページ内容を判断する他のＧＵＩ制御技術もある（例えば非特許文献７及び８参照）。これら技術は、ＧＵＩの表示内容をプログラムが解釈し、マウスクリックや文字入力をプログラムから実行可能としている。非特許文献７に記載の技術は、画像認識に基づいて画面の表示内容を判断することができる。また、非特許文献８に記載の技術は、Windows（登録商標）システムがページ毎に内部的に割り当てたウィンドウコントローラによって、表示内容を判断することができる。

［経路探索部１３］
経路探索部１３は、ユーザによって遷移先画面が指定された際に、有向グラフに基づいて、現表示画面から遷移先画面までの最短経路を探索する。有向グラフが、辺に対する重み無しのものである場合、最も簡易な、例えば幅優先探索(breadth first search)アルゴリズムを用いることができる。このアルゴリズムは、１つのノード（頂点・画面）から、隣接した全てのノードを、総当たり的に探索する。その隣接したノードもこれを繰り返すことによって、網羅的に展開して目標ノード（目標画面）を探索する。辺に対する重みが無いために、単に有向辺の数が最も少ない経路が選択される。

［スクリプト選択部１４］
スクリプト選択部１４は、最短経路を通過する１つ以上の有向辺に基づくスクリプトを選択する。

図５は、本発明における有向辺スクリプトの画面遷移を表す説明図である。

（Ｓ１）最初に、有向グラフを用いて、現表示画面Ａ（トップ画面）から、次の遷移先画面Ｂ（状態確認画面）までの最短経路を探索する。
画面Ａ-（有向辺１）->画面１-（有向辺２）->画面Ｂ
ここでは、有向辺１及び２のスクリプトが経路順に実行され、画面Ｂ（状態確認画面）へ遷移する。
（Ｓ２）次に、有向グラフを用いて、現表示画面Ｂ（状態確認画面）から、次の遷移先画面Ｃ（設定画面）までの最短経路を探索する。
画面Ｂ-（有向辺３）->画面１-（有向辺５）->画面２-（有向辺１０）->画面３
-（有向辺１１）->画面Ｃ
ここでは、有向辺３、５、１０及び１１のスクリプトが経路順に実行され、画面Ｃ（設定画面）へ遷移する。
（Ｓ３）次に、有向グラフを用いて、現表示画面Ｃ（設定画面）から、次の遷移先画面Ｂ（状態確認画面）までの最短経路を探索する。
画面Ｃ-（有向辺９）->画面２-（有向辺６）->画面Ｂ
ここでは、有向辺９及び６のスクリプトが経路順に実行され、画面Ｂ（状態確認画面）へ遷移する。

［スクリプト実行部１５］
スクリプト実行部１５は、選択されたスクリプトを経路順に実行することによって、遷移先画面をユーザに表示する。スクリプトは、大きく以下の２つの処理を実行する。
（１）有向辺に対する画面遷移処理
（２）頂点（画面自体）に対する操作処理
本発明によれば特に、有向辺に対する画面遷移処理を再利用可能なスクリプトとして構成することによって、専用ＧＵＩを持つ機器に対する操作を自動化することができる。

図６は、本発明の画面遷移の処理を表すプログラムコードである。

図６によれば、経路探索処理（Ｓ１３）、スクリプト選択処理（Ｓ１４）、スクリプト実行処理（Ｓ１５）が表されている。このプログラムコードを実行することによって、画面遷移及び画面操作のスクリプトを実行し、専用ＧＵＩであっても運用管理の自動化を実現することができる。

他の実施形態として、本発明によれば、図１（ｂ）のＣＬＩのように、遷移先画面毎にコマンドを割り当てて、ＧＵＩの運用管理を自動化することができる。即ち、コマンドラインインタフェースとして、グラフィックユーザインタフェースの画面間の遷移を制御することができる。ユーザによってコマンドが命令された際に、現表示画面から、当該コマンドに対応する遷移先画面までの最短経路を探索する（経路探索部１３）だけである。

以上、詳細に説明したように、本発明のプログラム、装置及び方法によれば、ＧＵＩの画面遷移を再利用性の高いスクリプトで構成することによって、運用管理の自動化を実現することができる。例えばSikuliを用いることによって、ＧＵＩに対する画面操作及び画面遷移をスクリプトとして生成することができる。このスクリプトは、ＧＵＩであってもＣＬＩのように再利用可能なモジュールとして構成される。

前述した本発明の種々の実施形態について、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。

１グラフィックユーザインタフェースプログラム
１０リッピング検出部
１１有向グラフ生成部
１１０有向グラフ蓄積部
１２スクリプト生成部
１２０スクリプト蓄積部
１３経路探索部
１４スクリプト選択部
１５スクリプト実行部

Claims

複数の画面を遷移するグラフィックユーザインタフェースとしてコンピュータを機能させるユーザインタフェースプログラムにおいて、
ユーザ操作によって表示可能な全ての各画面を頂点とし、各画面から１回の操作で遷移可能な他の画面への遷移を有向辺とした有向グラフについて、前記有向辺毎に、遷移処理を実行するスクリプトを用いて、
ユーザによって遷移先画面が指定された際に、前記有向グラフに基づいて、現表示画面から遷移先画面までの経路を探索する経路探索手段と、
前記経路を通過する１つ以上の有向辺に基づくスクリプトを選択するスクリプト選択手段と、
選択された前記スクリプトを経路順に実行するスクリプト実行手段と
してコンピュータを機能させることを特徴とするユーザインタフェースプログラム。
ユーザ操作によって表示可能な全ての各画面を頂点とし、各画面から１回の操作で遷移可能な他の画面への遷移を有向辺として、有向グラフを生成する有向グラフ生成手段と、
有向辺毎に、遷移処理を実行するスクリプトを生成するスクリプト生成手段と
してコンピュータを更に機能させることを特徴とする請求項１に記載のユーザインタフェースプログラム。
前記遷移先画面毎に、コマンドを割り当て、
前記経路探索手段は、ユーザによって前記コマンドが命令された際に、現表示画面から、当該コマンドに対応する前記遷移先画面までの経路を探索する
ようにコンピュータを機能させることを特徴とする請求項１又は２に記載のユーザインタフェースプログラム。
コマンドラインインタフェースとして、前記グラフィックユーザインタフェースの画面間の遷移が制御される
ようにコンピュータを機能させることを特徴とする請求項３に記載のユーザインタフェースプログラム。
前記経路探索手段は、幅優先探索(breadth first search)に基づいて最短経路を探索する
ようにコンピュータを機能させることを特徴とする請求項１から４のいずれか１項に記載のユーザインタフェースプログラム。
前記スクリプト生成手段は、画面内の操作及び画面遷移の操作を自動化するためにSikuli（登録商標）を用いる
ようにコンピュータを機能させることを特徴とする請求項２に記載のユーザインタフェースプログラム。
複数の画面を遷移するグラフィックユーザインタフェースをユーザに表示する装置において、
ユーザ操作によって表示可能な全ての各画面を頂点とし、各画面から１回の操作で遷移可能な他の画面への遷移を有向辺とした有向グラフについて、前記有向辺毎に、遷移処理を実行するスクリプトを用いて、
ユーザによって遷移先画面が指定された際に、前記有向グラフに基づいて、現表示画面から遷移先画面までの経路を探索する経路探索手段と、
前記経路を通過する１つ以上の有向辺に基づくスクリプトを選択するスクリプト選択手段と、
選択された前記スクリプトを経路順に実行するスクリプト実行手段と
を有することを特徴とする装置。
複数の画面を遷移するグラフィックユーザインタフェースを有する装置の画面遷移方法において、
ユーザ操作によって表示可能な全ての各画面を頂点とし、各画面から１回の操作で遷移可能な他の画面への遷移を有向辺とした有向グラフについて、前記有向辺毎に、遷移処理を実行するスクリプトを用いて、
ユーザによって遷移先画面が指定された際に、前記有向グラフに基づいて、現表示画面から遷移先画面までの経路を探索するステップと、
前記経路を通過する１つ以上の有向辺に基づくスクリプトを選択するステップと、
選択された前記スクリプトを経路順に実行するステップと
を有することを特徴とする装置の画面遷移方法。