本発明の実施の形態について、図面を用いて以下に説明する。
<実施の形態1>
<構成>
図1は、本発明の実施の形態1によるユーザインタフェース設計装置1、ユーザインタフェース実行装置2、およびデータ提供部3の構成の一例を示すブロック図である。なお、図1において、実線矢印は、各構成要素間におけるデータの流れを示しており、破線矢印は、状態遷移生成部10と、先読み生成部11と、データ取得生成部12と、および先読み管理生成部13の各々で生成されたコードの流れを示している。
まず、ユーザインタフェース設計装置1の構成について説明する。
ユーザインタフェース設計装置1は、ユーザインタフェース設計者が使用する装置であり、遷移設計部6と、インタフェース定義部7と、状態遷移生成部10と、先読み生成部11と、データ取得生成部12と、先読み管理生成部13とを備えている。
遷移設計部6(状態遷移定義部)は、ユーザインタフェースの状態を設計する。具体的には、遷移設計部6では、ユーザインタフェース設計者の入力に基づいて、状態遷移定義8を作成する。すなわち、遷移設計部6は、ユーザインタフェースの状態遷移を定義した状態遷移定義8を定義する。
インタフェース定義部7は、ユーザインタフェース実行装置2のユーザインタフェース実行部14と、当該ユーザインタフェース実行部14にデータを提供するデータ提供部3との間のインタフェース定義9を定義する。状態遷移定義8では、インタフェース定義部7で定義されたインタフェース定義9のうち、特定の状態で使用する可能性があるインタフェース群を定義することができる。
状態遷移生成部10は、状態遷移定義8に基づいて、ユーザインタフェース実行装置2のユーザインタフェース実行部14の状態遷移を処理するソフトウェアのソースコードである状態遷移コード30(図3参照)を生成する。生成された状態遷移コード30は、ユーザインタフェース実行装置2の状態遷移部18に伝えられる。
先読み生成部11は、状態遷移定義8およびインタフェース定義9に基づいて、予め定められたインタフェースの状態において、ユーザインタフェース実行装置2のユーザインタフェース実行部14による先読み要求および先読み破棄要求のうちの少なくとも一方を実行するソフトウェアのソースコードである先読み実行コード31(図3参照)を生成する。ここで、先読み要求とは、予め定められたインタフェースの状態で必要となり得るデータの提供をデータ提供部に要求することをいう。また、先読み破棄要求とは、データ提供部に対する先読み要求を止める(破棄する)ことをいう。なお、予め定められたインタフェースの状態は、予め定められた回数を遷移した後のインタフェースの状態を含むものとする。生成された先読み実行コード31は、ユーザインタフェース実行装置2のデータ要求部20に伝えられる。なお、先読み要求および先読み破棄要求については後述する。
データ取得生成部12は、インタフェース定義9に基づいて、データ提供部3から提供されるデータを蓄積するユーザインタフェース実行装置2のデータ記憶部16へのインタフェースとなるソフトウェアのソースコードである蓄積データアクセスコード32(図3参照)を生成する。生成された蓄積データアクセスコード32は、ユーザインタフェース実行装置2のデータ取得部15に伝えられる。
先読み管理生成部13は、インタフェース定義9に基づいて、ユーザインタフェース実行装置2におけるデータの先読み状態を管理するソフトウェアのソースコードである先読み管理コード33(図3参照)を生成する。生成された先読み管理コード33は、データ提供部3の先読み管理部23に伝えられる。
次に、ユーザインタフェース実行装置2の構成について説明する。
ユーザインタフェース実行装置2は、ユーザインタフェース実行部14と、データ取得部15と、データ記憶部16とを備えており、ユーザの入力操作を直接受け付ける入力装置4からの入力、またはデータ提供部3からのデータの受領などをきっかけとして、ユーザインタフェースの処理の結果を提示する提示装置4を制御する。
ユーザインタフェース実行部14は、イベント取得部17と、状態遷移部18と、データ処理部19と、データ要求部20と、提示制御部21とを備えている。
イベント取得部17は、入力装置4からの入力、またはデータ提供部3からのデータの受領等をイベントとして取得する。イベント取得部17で処理されるイベントは、ユーザインタフェースの状態を遷移させる状態遷移イベントと、データ提供部3に対する操作イベントと、入力装置4からの入力信号をそのまま提示制御に利用するための入力データイベントとに分類される。状態遷移イベントは、状態遷移部18に伝えられる。操作イベントは、データ要求部20に伝えられた後、データ取得部15を経由してデータ提供部3に伝えらえる。入力データイベントは、データ処理部19に伝えられた後、入力データの変更として提示制御部21に伝えられる。ここで、入力データイベントとしては、例えば、ユーザがタッチパネルに対するタッチダウン中の操作量(スライドの移動量)に応じて、画面の移動量を変更する処理等が挙げられる。
状態遷移部18は、ユーザインタフェース設計装置1の状態遷移生成部10で生成された状態遷移コード30を受領し、受領した状態遷移コード30に基づくインタフェースの状態遷移を実行する。また、状態遷移部18は、状態遷移時に、ユーザインタフェース設計装置1の先読み生成部11から先読み実行コード31を受領したデータ要求部20に対して、先読み要求を実行する。
データ要求部20は、イベント取得部17および状態遷移部18の指示に基づいて、データ提供部3が提供するデータや機能に対してアクセスする。データ要求部20は、イベント取得部17から、状態遷移を伴わない操作イベントに従ったデータ提供部3への要求を受領する。例えば、データ要求部20は、イベント取得部17から「音楽の再生開始」等の要求を受領する。また、データ要求部20は、状態遷移部18から、先読み要求の指示を受領する。
データ処理部19は、イベント取得部17で処理されたデータ付きイベントと、データ取得部15を経由してデータ提供部3から取得したデータを、ユーザインタフェースの提示に利用可能なように加工する。ここで、データ付きイベントとしては、入力装置4から入力された入力データイベントと、データ取得部15を経由してデータ提供部3から取得したデータを受け取る取得データイベントとが挙げられる。
提示制御部21は、ユーザインタフェース実行部14の状態と、データ処理部19で加工されたデータとに基づいて、提示装置5において実際にユーザに提示する情報を生成し、提示装置5において提示可能なように加工した制御信号を生成する。具体的には、提示制御部21は、ユーザインタフェース実行部14の状態を状態遷移部18から取得し、ユーザに提示するデータをデータ処理部19から取得する。提示制御部21で生成された制御信号は、提示装置5に伝えられ、提示装置5においてユーザへの提示が実行される。なお、本実施の形態において、提示とは、画面における表示に限らず、音声再生による音の提示、および触覚デバイスを用いた力覚としての提示も含むものとする。
データ取得部15は、データ要求部20から先読み要求を受領すると、データ記憶部16にデータ要求部20から要求されたデータと同一のデータが存在するか否かの確認を行う。データ記憶部16に同一のデータが存在しない場合において、データ取得部15は、先読み要求の対象となるデータを送付するようにデータ提供部3に要求する。一方、データ記憶部16に同一のデータが存在する場合において、データ取得部15は、データ提供部3に要求することなく、データ要求部20に対して成功(同一のデータが存在する)旨を応答する。
また、データ取得部15は、データ処理部19から実際のデータを取得したい旨の要求(データ取得要求)を受領すると、データ記憶部16にデータ処理部19から要求されたデータと同一のデータが存在するか否かの確認を行う。データ記憶部16に同一のデータが存在する場合において、データ取得部15は、データ提供部3にデータを要求することなく、データ記憶部16に記憶されている同一のデータを応答として返す。一方、データ記憶部16に同一のデータが存在しない場合において、データ取得部15は、データ記憶部16に同一のデータが存在しない旨のエラーを応答として返す。
また、データ取得部15は、データ取得インタフェースではない他のインタフェースに基づく要求をデータ要求部20から受領した場合において、データ記憶部16を参照することなく、データ提供部にデータの要求を送付する。
入力装置4は、ユーザの入力操作を解釈し、ユーザインタフェース実行装置2にイベントとして送付する。ここで、入力装置4としては、例えば、タッチパネル、マウス、キーボード、H/W(hardware)キー、ロータリースイッチ、リモートコントローラ、音声認識エンジン等が挙げられる。
提示装置5は、提示制御部21から受領した制御信号に基づいて、ユーザに情報の提示を行う。ここで、提示装置5としては、液晶ディスプレイまたはプロジェクタ等の視覚情報を提示するデバイス、スピーカまたはイヤフォン等の音声情報を提示するデバイス、振動子等の力覚を提示するデバイス等が挙げられる。
次に、データ提供部3の構成について説明する。
データ提供部3は、提示装置5において提示するデータをユーザインタフェース実行装置2に提供する装置であり、要求処理部22と、先読み管理部23と、応答返却部24と、データ生成処理部25とを備えている。
要求処理部22は、データ取得部15から先読み要求、先読み破棄要求、およびデータ提供部3に対して予め定められた処理を要求する指示要求のうちの少なくとも1つの要求を受領する。
先読み管理部23は、先読み管理生成部13で生成された先読み管理コード33に基づいて、ユーザインタフェース実行装置2におけるデータの先読み状態を管理する。具体的には、先読み管理部23における管理は、要求処理部22が受領した先読み要求または先読み破棄要求に基づいて行われる。
応答返却部24は、要求処理部22が受領した先読み要求またはデータ取得要求に対して、データ取得部15にデータを返す。また、応答返却部24は、データ生成処理部25の処理によってデータ提供部3において保持するデータが更新されたことをデータ生成処理部25から通知されると、先読み管理部23を参照して当該更新されたデータが先読み状態であるか否かの判断を行う。そして、更新されたデータが先読み状態である場合において、応答返却部24は、データ取得部15に対してデータ(より具体的には、データの値)が更新された旨を通知する。
データ生成処理部25は、データ提供部3が保持するデータの更新処理またはデータの生成処理を行う。これらの処理は、データ提供部3の開発者がプログラムを記述することによって行われる。なお、データ提供部3が保持するデータは、データ提供部3が備える記憶部(図示せず)で保持されているものとする。
図2は、図1に示すユーザインタフェース設計装置1、ユーザインタフェース実行装置2、およびデータ提供部3におけるソフトウェア機能に対応するハードウェア構成の一例を示す図である。
ユーザインタフェース設計装置1において、遷移設計部6、インタフェース定義部7、状態遷移生成部10、先読み生成部11、データ取得生成部12、および先読み管理生成部13は、例えば図2のプロセッサ26がメモリ27等に記憶されたプログラムを実行することにより、当該プロセッサ26の機能として実現される。ただし、これらは、例えば複数のプロセッサ26が連携して実現されてもよい。
また、ユーザインタフェース実行装置2において、ユーザインタフェース実行部14、データ取得部15、イベント取得部17、状態遷移部18、データ処理部19、データ要求部20、および提示制御部21は、例えば図2のプロセッサ26がメモリ27等に記憶されたプログラムを実行することにより、当該プロセッサ26の機能として実現される。ただし、これらは、例えば複数のプロセッサ26が連携して実現されてもよい。
また、データ提供部3において、要求処理部22、先読み管理部23、応答返却部24、およびデータ生成処理部25は、例えば図2のプロセッサ26がメモリ27等に記憶されたプログラムを実行することにより、当該プロセッサ26の機能として実現される。ただし、これらは、例えば複数のプロセッサ26が連携して実現されてもよい。
なお、プロセッサ26およびメモリ27は、ユーザインタフェース設計装置1、ユーザインタフェース実行装置2、およびデータ提供部3の各々に備えられているものとする。
図3は、ユーザインタフェース設計装置1に対する入力とその生成コードの一例を示す図である。
ユーザは、遷移設計部6およびインタフェース定義部7に対して、ユーザインタフェース実行装置2において実行されるユーザインタフェースの設計を入力する。
ユーザは、遷移設計部6に対して、状態遷移図28と、各状態で利用するインタフェースの対応を定義した対応定義29とを入力する。なお、遷移設計部6は、自らがGUI(Graphical User Interface)を有してユーザに入力させるようにしてもよく、UML(Unified Modeling Language)を編集するツールを用いて設計された状態遷移モデルをインポートするようにしてもよい。また、状態遷移定義8は、状態遷移図28と対応定義29とを含んでいる。
図3の例では、状態遷移図28は、状態S1のときにイベントE1を受理すると状態S2に遷移することを示している。また、状態遷移図28は、状態S2のときにイベントE2を受理すると状態S1に遷移し、状態S2のときにイベントE3を受理すると状態S3に遷移することを示している。また、状態遷移図28は、状態S3のときにイベントE4を受理すると状態S1に遷移することを示している。
対応定義29は、状態遷移図28で定義された各状態において利用する可能性があるインタフェースの対応を定義したものである。なお、対応定義29は、状態遷移図28における各状態のプロパティとして定義されてもよく、別のファイルで定義されてもよい。図3の例では、対応定義29は、状態S1においてgetDataA、getStateD、doSomethingの3つのインタフェースを利用し、状態S2においてgetDataA、getCurrentState、OnNotifyE2の3つのインタフェースを利用し、状態S3においてgetListC、getCurrentState、doSomethingの3つのインタフェースを利用することを示している。
インタフェース定義9は、ユーザインタフェース実行装置2のユーザインタフェース実行部14とデータ提供部3との間におけるインタフェースの定義と、当該インタフェースに基づいてデータ提供部3から得られるデータの最大サイズの定義とを含んでいる。インタフェース定義9には、そのインタフェースがどのようなインタフェースであるのかを示している。図3の例では、"get"から始まるインタフェースは、データ提供部3からデータを取得するインタフェース(データ取得インタフェース)であることを示している。"do"から始まるインタフェースは、データ提供部3に指示を行うインタフェース(指示インタフェース)であることを示している。"OnNotify"から始まるインタフェースは、データ提供部3からユーザインタフェース実行部14へのイベント通知のインタフェース(イベント通知インタフェース)であることを示している。
なお、本実施の形態1では、インタフェース定義9は、記載のルールによる暗黙的な定義を示しているが、例えば、インタフェース定義9の型指定の前に、データ取得インタフェースは"getter"、指示インタフェースは"method"、イベント通知インタフェースは"event"等と明示的に宣言してもよい。
図3の例では、インタフェース定義9は、serviceAというデータ提供部3に対するインタフェースについて、4種類のデータ取得インタフェースと、1種類の指示インタフェースと、1種類のイベント通知インタフェースを定義している。
また、インタフェース定義9では、データ取得インタフェースに基づいてデータ提供部3から取得するデータの最大サイズを定義することができる。図3の例では、インタフェース定義9のデータサイズについて、DataAを4バイト、StringBを4×256バイト、ListCの最大保持サイズを16×256+8バイト、StateDを16バイトと各々定義している。
状態遷移生成部10は、状態遷移定義8に基づいて状態遷移コード30を生成する。図3の例では、状態遷移コード30は、状態S1のときにイベントE1を受理すると状態S2に状態が遷移することを示している。また、状態遷移生成部10は、対応定義29の状態S1で定義されたデータ取得インタフェースであるgetDataAおよびgetStateDを読み込み、状態S1に遷移したときにはsubscribe_DataA()およびsubscribe_StateD()を実行し、状態S1から他の状態に遷移するときにはunsubscribe_DataA()およびunsubscribe_StateD()を実行する状態遷移コード30を生成する。
先読み生成部11は、状態遷移定義8とインタフェース定義9とに基づいて先読み実行コード31を生成する。図3の例では、先読み生成部11は、状態遷移コード30から呼び出されるsubscribe_DataA()およびsubscribe_StateD()と、データ取得部15からデータを取得するデータ取得インタフェースであるgetDataA()およびgetStateD()を含む先読み実行コード31を生成する。subscribe_DataAは、インタフェース定義9によりDataAがint型であることを判断し、intのサイズを引数に追加することによって先読み処理を行うsubscribeを呼び出す。また、データ取得インタフェースであるgetメソッドは、データ記憶部16からintの形に変換して取り出すコードを生成する。なお、StateDについても同様である。
また、先読み生成部11は、当該先読み生成部11にて生成された先読み実行コード31と、インタフェース定義9に含まれるデータの最大サイズの定義とに基づいて、状態遷移定義8で定義された各状態における、データ提供部3から提供されたデータを記憶するユーザインタフェース実行装置2のデータ記憶部16の最大サイズを算出する。
データ取得生成部12は、インタフェース定義9に基づいて蓄積データアクセスコード32を生成する。図3の例では、データ取得生成部12は、インタフェース定義9で定義されたインタフェースに基づいて、データ記憶部16にエントリを生成するコードを生成するとともに、データ提供部3に先読み要求を送付して返ってきたデータをデータ記憶部16に記憶する処理を行うコードを生成する。エントリは、例えば図9に示すような、key(キー)−value(値)の組み合わせで構成される(詳細は後述する)。
また、データ取得生成部12は、データ提供部3から値の変更(更新)通知を受け取るコールバック関数も生成する。また、データ取得生成部12は、インタフェース定義9で定義されたデータ取得インタフェースではない他のインタフェースであるdoSomething()、呼出コードであるOnNotifyE2()、およびコールバックインタフェースを定義する。
図3の例では、蓄積データアクセスコード32の5行目の処理を実行することによって"key"で表されるデータの先読み要求をデータ提供部3に伝えており、その応答として現時点での最新の値(データの値)が返され、4,5行目の処理を実行することによってデータ記憶部16に値を記録している。なお、図3の例では、データ提供部3から同期処理によって値が返されているが、当該値を返す処理をコールバックで受けて、非同期応答に対応してもよい。蓄積データアクセスコード32の20行目以降の処理は、データ提供部3からデータの更新通知を受け取るコールバック関数の一例を示しており、getDataAというインタフェースに対してOnNotifyDataAというコールバック関数を生成し、当該コールバック関数においてデータ記憶部16の更新と、ユーザインタフェース実行部14への通知を行う。
なお、蓄積データアクセスコード32には、データ記憶部16に予め定められたサイズのエントリを生成して先読み開始処理を呼び出すコードと、先読み破棄要求によってデータを削除して先読み破棄要求をデータ提供部3に送付するコードと、データ記憶部16から予め定められてデータを取得するコードと、データ提供部3から受領したデータの更新通知に基づいてデータ記憶部16のデータを更新するコードとのうちの少なくとも1つのコードが含まれている。
先読み管理生成部13は、インタフェース定義9に基づいて先読み管理部23で使用される先読み管理コード33を生成する。図3の例では、先読み管理生成部13は、インタフェース定義9に基づいて、データ提供部3が提供するserviceAの先読み要求(subscribe)と、先読み破棄要求(unsubscribe)との各々に対応するコードを生成する。すなわち、先読み管理生成部13は、インタフェース定義9に基づいて、データ提供部3からユーザインタフェース実行装置2に提供されるデータが先読みの対象となっているか否かをデータ提供部3で管理するための先読み管理コード33を生成する。
先読み要求に対応する先読み要求コードは、先読み要求を行うクライアント(client)と、先読み対象となるデータとを先読み管理部23に登録するコードを実行し、データ提供部3の開発者が実際にプログラムを記述する対象であるonCall_getDataA()等の処理を呼び出す。先読み破棄要求に対応する先読み破棄要求コードは、先読み管理部23に対して、先読み要求を行うクライアントと、先読み対象となるデータとの登録を破棄するコードを生成する。
また、先読み管理生成部13は、先読み対象となるデータの値を変更する処理(setDataA)を生成する。データ提供部3の開発者が当該処理を呼び出すと、該当するデータ(開発者が変更等行ったデータ)が先読み状態であるか否かを判断し、先読み状態である場合はクライアントであるユーザインタフェース実行装置2のユーザインタフェース実行部14に対してデータの変更通知を発行する。
<動作>
図4は、ユーザインタフェース実行装置2の動作の一例を示すフローチャートである。図4では、入力装置4またはデータ取得部15からイベント取得部17に入力されるイベントに従って状態遷移部18で状態が遷移した場合における処理の流れを示している。なお、ステップS101〜ステップS105において、遷移先の状態が状態S1である場合を一例として説明している。また、ステップS106〜ステップS110において、遷移元の状態が状態S1である場合を一例として説明している。
ステップS101において、状態遷移部18は、状態の遷移を実行すると、遷移先の状態で定義された全てのデータ取得インタフェースに対して処理が行われたか否かの判断を行う。なお、ステップS101の処理は、図4に示すようにループ構造で実行してもよく、設計時に対応定義29からループを展開した状態で実行してもよい。図3の例では、状態S1で使用するデータ取得インタフェースがgetDataAおよびgetStateDであるため、状態遷移コード30の4〜7行目のS1.onenterで実行される処理を生成する際において、ループを展開してDataAおよびStateDの取得の形に展開されている。全てのデータ取得インタフェースに対して処理が行われた場合は、ステップS106に移行する。一方、全てのデータ取得インタフェースに対して処理が行われていない場合は、ステップS102に移行する。
ステップS102において、データ取得部15は、データ記憶部16に同一キーのエントリが存在するか否かの判断を行う。図3の例では、蓄積データアクセスコード32の2行目のisSubscribedで実行される処理に対応する。同一キーのエントリが存在する場合は、ステップS103に移行する。一方、同一キーのエントリが存在しない場合は、ステップS104に移行する。
ステップS103において、データ取得部15は、蓄積データアクセスコード32の7行目のaddで実行される処理によって、エントリの呼出元(先読み処理を呼び出したclient、ここではユーザインタフェース実行部14)を、データ記憶部16のclient管理テーブルに記憶(追加)する。なお、client管理テーブル(図13参照)については、後の実施の形態3で詳述する。
ステップS104において、データ取得部15は、データ名およびサービス名をキーとした新たなエントリをデータ記憶部16に作成する。
ステップS105において、データ取得部15は、サーバであるデータ提供部3に先読み要求を送付する。
ステップS106において、状態遷移部18は、遷移元の状態で使用される全てのデータ取得インタフェースに対して処理が行われたか否かの判断を行う。図3の例では、状態遷移コード30の8〜11行目のonleaveで実行される処理である。状態遷移コード30の8〜11行目では、イベントE1によって状態S1から状態S2に状態が遷移するときの処理を示している。なお、ステップS106の処理は、ステップS101と同様、設計時に対応定義29からループを展開した状態で実行してもよい。全てのデータ取得インタフェースに対して処理が行われた場合は、処理を終了する。一方、全てのデータ取得インタフェースに対して処理が行われていない場合は、ステップS107に移行する。
ステップS107において、データ取得部15は、データ記憶部16のclient管理テーブルにアクセスし、該当するキーのエントリが呼出元以外からも参照されているかの判断を行う。呼出元以外からも参照されている場合は、ステップS108に移行する。一方、呼出元のみから参照されている場合は、ステップS109に移行する。なお、本実施の形態1のように、ユーザインタフェース実行部14が1つの場合は、ステップS109に移行する。
ステップS108において、データ取得部15は、データ記憶部16のclient管理テーブルから呼出元を削除する。
ステップS109において、データ取得部15は、データ記憶部16の該当キーのエントリを無効化または破棄(削除)する。なお、エントリを無効化にする場合は、予め各エントリ(図9参照)に無効化フラグを設定する必要がある。そして、エントリを無効化にするときは無効化フラグを「false」とし、エントリを有効化にするときは「true」とする。
ステップS110において、データ取得部15は、データ要求部20からの先読み破棄要求の指示に基づいて、データ提供部3に先読み破棄要求を送付する。図3の例では、蓄積データアクセスコード32の9〜12行目に示されるコードが先読み破棄要求の処理に対応する。
図5は、データ提供部3における先読み要求を受領したときの動作の一例を示すフローチャートである。図5では、図4のステップS105における処理によって、データ取得部15から送付された先読み要求をデータ提供部3が受領したときの処理の流れを示している。
ステップS201において、要求処理部22は、データ取得部15から先読み要求を受領すると、先読み要求を送付したユーザインタフェース実行部14(クライアント)を特定するIDであるデバイスIDと、先読みの対象となるデータを特定する先読み対象データキーとの組み合わせを、先読み管理部23に登録する。図3の例では、先読み管理コード33の2行目に示される処理に対応する。
ステップS202において、要求処理部22は、データ提供部3の値を取得するためのグル―コードを呼び出す。当該グル―コードは、データ提供部3の開発者によって内部の処理(プログラム)を自由に記述することができる処理であり、クライアントであるユーザインタフェース実行部14から値を取得するためのインタフェースが呼び出される際に処理するコードと同じである。図3の例では、先読み管理コード33の5行目および7行目に示される処理に対応する。
ステップS203において、応答返却部24は、ステップS202にて取得した値を、RPC(Remote Procedure Call)の仕組みによってユーザインタフェース実行装置2に返す。
図6は、データ提供部3における先読み破棄要求を受領したときの動作の一例を示すフローチャートである。図6では、図4のステップ110における処理によって、データ取得部15から送付された先読み破棄要求をデータ提供部3受領したときの処理の流れを示している。
ステップS301において、要求処理部22は、データ取得部15から先読み破棄要求を受領すると、先読み管理部23に登録されているデバイスIDと先読み対象データキーとの組み合わせを削除する。当該処理を行うことによって、データ提供部3では、ユーザインタフェース実行部14(クライアント)と、先読み対象となるデータとの対応が取れなくなり、先読み状態が解除される。
図7は、データ提供部3における値更新時の動作の一例を示すフローチャートである。
データ提供部3は、データ生成処理部25においてユーザインタフェース実行装置2とは独立してデータを生成しており、当該データを生成する処理を行う際に、先読み状態であるデータの値が変更することがある。図7では、データの値が変更(更新)されたときの処理の流れを示している。なお、以下では、値が変更されたデータのことを、変更後のデータという。
ステップS401において、データ生成処理部25は、変更後のデータを応答返却部24に通知する。
ステップS402において、応答返却部24は、先読み管理部23に登録されているデバイスIDおよび先読み対象データキーとの組み合わせを参照し、変更後のデータを先読みしているユーザインタフェース実行部14が存在するか否かの判断を行う。変更後のデータを先読みしているユーザインタフェース実行部14が存在する場合は、ステップS403に移行する。一方、変更後のデータを先読みしているユーザインタフェース実行部14が存在しない場合は、処理を終了する。
ステップS403において、応答返却部24は、先読みしているユーザインタフェース実行部14に対して、変更後のデータと、当該データに対応する先読み対象データキーとを送付する。
図8は、ユーザインタフェース実行装置2における変更後のデータを受領したときの動作の一例を示すフローチャートである。
ステップS501において、データ取得部15は、データ提供部3の応答返却部24から変更後のデータを受領する。
ステップS502において、データ取得部15は、変更後のデータと、当該データに対応する先読み対象データキーとに基づいて、データ記憶部16から該当するデータを検索し、該当するデータの値に対して変更後のデータの値を上書きする。
ステップS503において、データ取得部15は、上記の該当するデータを使用しているユーザインタフェース実行部14に対して、データの値が更新された旨を通知する。当該通知を受領したイベント取得部17は、イベントに応じて、提示装置5に提示する値を更新する等の処理を行う。
図9は、データ記憶部15で管理されるデータの形式の一例を示す図である。
データ記憶部15では、データ提供部3から提供されたデータをkey(キー)−value(値)の組み合わせで記憶している。keyは、インタフェース定義9で定義されたデータ取得インタフェース("get"から始まるインタフェース)のget以降の文字列である。例えば、インタフェース定義9でgetDataAのインタフェースが定義されている場合において、当該インタフェースに基づいて取得するデータのkeyは"DataA"となる。また、データ取得インタフェースに基づいて取得する型がList型等のCollection型である場合は、keyの後にlength、name、item等の定形語を追加して、List型の扱いに必要なパラメータも同時に格納する。
また、"get"のインタフェースに引数を指定することができる場合は、引数によって取得するデータを変更する意図があるため、keyの末尾にその引数を追加することによってデータの同一性を保証する。具体的には、"getListC(int id)"のインタフェースが存在する場合において、id=1で取得するListCの長さを格納するkeyは、"ListC_length_1"という形式とする。このようなkeyの決定方法によって、getListC(1)で取得するListCのデータと、getListC(2)で取得するListCのデータとを区別してデータ記憶部16に記憶することができる。
valueは、データ提供部3から提供されたデータの値をそのままの形で記憶する。本実施の形態1では、全てのデータの値はJSON(JavaScript(登録商標) Object Notation)形式の文字列として記憶されている。データ取得部15は、データ記憶部16から取得したデータをインタフェースで定義した型に変換した後、ユーザインタフェース実行部14にデータを送付する。
図10は、先読み管理部23で管理される先読み管理データの一例を示す図である。
先読み管理部23では、先読み管理コード33に含まれるインタフェース定義9から解釈されたデータの先読み状態を、key−subscribeの組み合わせで管理している。データが先読み状態であればtrue、先読み状態でなければfalseとする。
図10の例では、インタフェース定義9から解釈されたデータのうち、keyがStringBのデータは先読み状態でなく、他のキーのデータは先読み状態であることを示している。例えば、データ生成処理部25がStringBのデータを更新するメソッドを呼び出して更新した場合において、応答返却部24は、先読み管理部23の先読み管理データを参照してStringBのデータは先読み状態でないことが分かるため、ユーザインタフェース実行部14に対して更新後のデータを通知しない。一方、データ生成処理部25がDataAのデータを更新するメソッドを呼び出して更新した場合において、応答返却部24は、先読み管理部23の先読み管理データを参照し、先読み状態であるユーザインタフェース実行部14に対して更新後のデータを通知する。
このような管理を行うことによって、先読み状態でないユーザインタフェース実行部14には不必要なデータの通知を行わないため、ユーザインタフェース実行装置2とデータ提供部3との間における通信トラフィックを削減するとともに、ユーザインタフェース実行装置2における無駄なソフトウェア処理を削減することができる。
<実施例>
上記で説明したユーザインタフェース実行装置2およびデータ提供部3をカーナビゲーションシステムに適用する場合について説明する。
以下において、ユーザインタフェース実行装置2は、自動車のダッシュボードの中に組み込まれるカーナビゲーションシステムに対応している。入力装置4は、運転手のステアリングに装着されたステアリングリモコン、カーナビゲーションシステムに搭載されたH/Wキー、または赤外線リモコンである。提示装置5は、カーナビゲーションシステムの液晶パネルである。データ提供部3は、ネットワークを介したインタネット上のサーバで実行されるラジオ番組の番組情報配信サービスに対応する。また、インタフェース定義9として、データ取得インタフェースであるSongInfo getSongInfo(station_id)が定義されているものとする。
ユーザインタフェース実行装置2において、状態遷移部18は、ユーザインタフェース設計装置1の状態遷移生成部10から状態遷移コード30を受領しているものとする。また、データ要求部20は、ユーザインタフェース設計装置1の先読み生成部11から先読み実行コード31を受領しているものとする。また、データ取得部15は、ユーザインタフェース設計装置1のデータ取得生成部12から蓄積データアクセスコード32を受領しているものとする。
データ提供部3において、先読み管理部23は、ユーザインタフェース設計装置1の先読み管理生成部13から先読み管理コード22を受領しているものとする。
ユーザが入力装置4を操作することによって、ユーザインタフェース実行部14の状態が、当該状態から予め定められた回数の操作を行えばラジオ番組の情報表示画面に遷移する状態となった場合において、データ要求部20は、先読み実行コード31であるsubscribe_SongInfo(station1)を実行する。そして、データ取得部15は、データ記憶部16にSongInfo_station1の項目(エントリ)を追加し、データ提供部3に対して先読み要求を送付する。このとき、先読み要求として、当該先読み要求を行ったクライアントであるカーナビゲーションシステム(ユーザインタフェース実行装置2)のdeviceIDである"device1"と、keyである"SongInfo_station1"が送付される。
データ提供部3において、要求処理部22は、ユーザインタフェース実行装置2から先読み要求を受領すると、SongInfo_station1がdevice1で先読み状態であることを先読み管理部23に登録する。そして、応答返却部24は、現在のstation1のSongInfoをユーザインタフェース実行装置2に返す。
データ提供部3からstation1のSongInfoを受領したデータ取得部15は、データ記憶部16のkeyである"SongInfo_station1"に対応するvalueに対してtation1のSongInfoを記録し、イベント取得部17に先読みが完了した旨を伝える。
その後、ユーザの操作によって、ラジオ番組表示画面に遷移した場合において、データ要求部20がデータ取得部15に対してgetSongInfo(station1)を実行すると、データ取得部15からデータ記憶部16に記録されているtation1のSongInfoがデータ処理部19に送付される。
このような動作を行うことによって、ユーザインタフェース実行部14が、データを必要とするタイミングでデータ提供部3に対してデータ取得の要求を行う処理を削減することができる。
また、時間が経過して、ラジオ番組で配信中の楽曲が変更になった場合において、データ提供部3の応答返却部24は、先読み管理部23の先読み管理データを参照し、SongInfoが先読み状態であることを把握する。そして、応答返却部24は、ユーザインタフェース実行装置2のデータ取得部15に対して、変更後の情報を通知する。データ取得部15は、変更後の情報を受領すると、データ記憶部16のvalueに対して変更後の情報を上書きして更新し、イベント取得部17に変更後の情報を通知する。
上記より、ユーザインタフェース実行部14は、先読み状態であれば常にデータ提供部3から最新の情報を取得することができる。従って、ユーザインタフェース実行部14は、遅延の大きなデータ提供部3に対してデータの要求を逐次行う必要がなくなるため、画面の遷移または画面の描画等を高速に行うことができ、ユーザに快適な操作感を提供することができる。
また、ユーザの操作によって、例えばCDの再生を開始する等、ラジオ番組の情報提供画面までの操作回数が予め定められた回数以上になる場合において、データ要求部20は、先読み実行コード31における先読み破棄要求であるunsubscribe_SongInfo(station1)が実行され、データ取得部15によってデータ記憶部16のtation1のSongInfoが無効化または破棄される。このとき、データ取得部15は、先読み破棄要求をデータ提供部3に送付する。データ提供部3の要求処理部22は、受領した先読み破棄要求に従って、先読み管理部23で管理している先読み管理データから、SongInfo_station1がdevice1で先読み状態である旨の情報が削除される。
データ要求部20が先読み破棄要求を実行することによって、ユーザインタフェース実行部14のある状態において先読み状態となるデータを特定することが可能になるため、この処理(先読み破棄要求に係る処理)を決定するコード(蓄積データアクセスコード)の生成時に、ユーザインタフェース実行装置2が動作する上で必要なデータ記憶部16に記憶されているデータを特定することができる。従って、データ記憶部16における各データ項目(ユーザインタフェースの各状態で必要となるデータ)の最大サイズを予め規定しておくことによって、ユーザインタフェース実行装置2の動作時に必要なデータ記憶部16の容量を設計時に見積もることができる。
以上のことから、本実施の形態1によれば、先読みするデータを記憶する記憶領域の最大サイズをユーザインタフェースの設計時に予測可能であり、かつ先読みしたデータが先読み後に更新された場合であっても更新後のデータをユーザに提示することが可能となる。
<実施の形態2>
実施の形態1では、ユーザインタフェース実行装置2とデータ提供部3とが別個に設けられる場合について説明したが、これに限るものではない。例えば、ユーザインタフェース実行装置2とデータ提供部3とを一体に設けるようにしてもよい。
例えば、実施の形態1の実施例で説明したカーナビゲーションシステムにおいて、自車両が走行中の現在地を提供する機能を実行する場合がある。このとき、カーナビゲーションシステムはユーザインタフェース実行装置2に対応し、自車両の現在地を提供する機能はデータ提供部3に対応する。
図11は、本実施の形態2によるユーザインタフェース実行装置34の構成の一例を示すブロック図である。
図11に示すように、ユーザインタフェース実行装置34は、実施の形態1(図1参照)によるユーザインタフェース実行装置2とデータ提供部3とを一体にしたものである。また、ユーザインタフェース実行部35は、実施の形態1によるユーザインタフェース実行部14にデータ取得部15およびデータ記憶部16を組み込んだものである。その他の構成および動作は、実施の形態1と同様であるため、ここでは説明を省略する。
ユーザインタフェース実行装置34は、ユーザインタフェース実行部35とデータ提供部3とを備えている。従って、ユーザインタフェース実行部35がデータ提供部3からデータを取得するときの遅延が、実施の形態1よりも小さくなる。また、実施の形態1において、ユーザインタフェース実行装置2は、一般的にオペレーティング・システム(OS)を搭載しており、ユーザインタフェース実行部14とデータ提供部3とではメモリ空間が異なる。従って、ユーザインタフェース実行部14とデータ提供部3との間におけるデータの受け渡し時には遅延が発生し、受け渡しのデータサイズおよび回数が増えるほど遅延が大きくなるという問題がある。本実施の形態2では、ユーザインタフェース実行部35内にデータ記憶部16を設けているため、データ取得時において、異なるメモリ空間でのデータの受け渡しの回数を無くすことが可能となる。
<実施の形態3>
実施の形態1,2では、ユーザインタフェース実行部14,35が単数である場合について説明したが、これに限るものではない。例えば、ユーザインタフェース実行部は複数存在してもよい。
例えば、実施の形態1の実施例で説明したカーナビゲーションシステムにおいて、運転者に向けて表示するディスプレイ、助手席の同乗者に向けて表示するディスプレイ、および後部座席の同乗者に向けて表示するディスプレイの各々に対応するユーザインタフェース実行部が備えられる場合が考えられる。
図12は、本発明の実施の形態3によるユーザインタフェース実行装置36の構成の一例を示すブロック図である。
図12に示すように、ユーザインタフェース実行装置36は、ユーザインタフェース実行部41,42,43を備えることを特徴としている。また、ユーザインタフェース実行部41は提示装置38に接続され、ユーザインタフェース実行部42は提示装置39に接続され、ユーザインタフェース実行部43は提示装置40に接続されている。なお、ユーザインタフェース実行部41,42,43は、実施の形態1によるユーザインタフェース実行部14と同一の機能を有している。その他の構成および動作は、実施の形態1と同様であるため、ここでは説明を省略する。
例えば、上記のカーナビゲーションシステムにおいて、運転者に向けて表示するディスプレイを提示装置38とし、助手席の同乗者に向けて表示するディスプレイを提示装置39とし、後部座席の同乗者に向けて表示するディスプレイを提示装置40とし、提示装置38,39,40の各々に対して異なる情報を表示することができる。
データ取得部44およびデータ記憶部45は、ユーザインタフェース実行部41,42,43の各々で共通している。このような構成とすることによって、例えばユーザインタフェース実行部41で必要となったデータを、ユーザインタフェース実行部42が先読みしている場合において、ユーザインタフェース実行部41は、データ提供部3に対して先読み要求することなく、データ記憶部45から必要なデータを取得することができる。従って、ユーザインタフェース実行装置36全体として高速な応答を実現することができる。
上記の動作を実現するために、例えば、ユーザインタフェース実行部41のデータ要求部49は、先読み実行コード31を実行する際において、図3に示す先読み実行コード31の4行目に示されているように、自身のインスタンス(図3の例では"this")をデータ取得部44に伝える。データ取得部44では、蓄積データアクセスコード32に基づいて、データ記憶部40に項目を追加する。このとき、データ取得部44は、蓄積データアクセスコード32の2行目に示されているように、既に先読み状態である場合は、データ提供部3に対して先読み要求を新たに伝えることなく処理を終了する。
また、データ提供部3において、例えば先読み状態である"DataA"の値が変更された場合、変更後のデータを受領したデータ取得部44は、蓄積データアクセスコード32のOnNotifyDataAを実行する。このとき、変更後のデータの値をデータ記憶部45に記録した後、DataAを先読みしている全てのインタフェース実行部に対してOnChangeDataAを実行する。
図13は、データ記憶部45で管理されるclient管理テーブルの一例を示す図である。
データ記憶部45では、key−valueの組み合わせの管理に加えて、特定のkeyを読み出しているclientを管理するclient管理テーブルが記憶されている。
図13において、DataAは、clientA(例えば、ユーザインタフェース実行部41)とclientB(例えば、ユーザインタフェース実行部42)から先読み状態であり、StringBはclientAから先読み状態であることを示している。
以上のことから、本実施の形態3によれば、ユーザインタフェース実行装置36が複数のユーザインタフェース実行部41,42,43を備えている場合であっても、ユーザインタフェース実行装置36全体として高速な応答を実現することができる。
<実施の形態4>
実施の形態3では、1つのユーザインタフェース実行装置36内に複数のユーザインタフェース実行部41,42,43が存在する場合について説明したが、これに限るものではない。例えば、ユーザインフェース実行装置は複数存在してもよい。
例えば、実施の形態1の実施例で説明したカーナビゲーションシステムにおいて、自動車のダッシュボードに組み込まれたカーナビゲーションユニットと、ユーザが自動車内に持ち込んだタブレット端末とのように、ユーザインタフェース実行装置が複数存在する場合が考えられる。
図14は、本発明の実施の形態4によるユーザインタフェース実行装置2,61の構成の一例を示すブロック図である。
図14に示すように、本実施の形態4では、複数のユーザインタフェース実行装置2,61が備えられている。なお、ユーザインタフェース実行装置2,61は、実施の形態1によるユーザインタフェース実行装置2と同一の機能を有している。その他の構成および動作は、実施の形態1と同様であるため、ここでは説明を省略する。
例えば、上記のカーナビゲーションシステムにおいて、自動車のダッシュボードに組み込まれたカーナビゲーションユニットをユーザインタフェース実行装置2とし、ユーザが自動車内に持ち込んだタブレット端末をユーザインタフェース実行装置61とすることができる。
ユーザインタフェース実行装置2,61は、別個の装置であり、各々データ取得部15,65およびデータ記憶部16,66を備えている。データ提供部3では、各ユーザインタフェース実行装置2,61を識別するIDを管理している。具体的には、データ取得部15,65が実行する蓄積データアクセスコード32に基づくデータ提供部3に対する先読みを実行する処理(図3の例では、蓄積データアクセスコード32の5行目に示す処理であるclient.serviceIF.subscribe(key))の中で、ユーザインタフェース実行装置2,61を特定するdeviceIDを付与し、データ提供部3に対するsubscribeコードを呼び出す。データ提供部3の要求処理部22は、先読み管理コード33に基づいてdeviceIDと、先読み対象となるデータのkeyとを受領して先読み管理部23に記録する。そして、データ生成処理部25の処理によってデータの値が変更した場合において、応答返却部24は、先読み管理部23の先読み管理データを参照し、先読み状態である全てのユーザインタフェース実行装置に対して変更後のデータを通知する。
図15は、先読み管理部23で管理される管理データの一例を示す図である。
実施の形態1による先読み管理部23の管理データ(図10参照)とは異なり、本実施の形態4による先読み管理部23の管理データは、図15に示すように、keyと、当該keyのデータを先読み中であるdeviceIDとの組み合わせを記録している。図15の例では、DataAがdevice1(例えば、ユーザインタフェース実行装置2)およびdevice2(例えば、ユーザインタフェース実行装置61)から先読みされていることが分かる。応答返却部24は、先読み管理部23の先読み管理データを参照し、例えばDataAが更新された場合は、deviceAおよびdeviceBに更新後のデータを通知する必要があると判断する。
以上のことから、本実施の形態4によれば、実施の形態1と同様の効果を得ることができる。
<実施の形態5>
実施の形態1〜4では、ユーザインタフェース実行装置がデータ提供部からデータを取得するときの通信遅延を低減することと、ユーザインタフェースの設計時にデータ記憶部に必要な容量を見積もることを目的としている。本発明の実施の形態5では、データ記憶部をバックアップする仕組みを備えることによって、ユーザインタフェース実行装置の起動を高速化させることを目的とする。
図16は、本実施の形態5によるユーザインタフェース実行装置72の構成の一例を示すブロック図である。
図16に示すように、ユーザインタフェース実行装置72は、バックアップ部74および不揮発記憶部75を備えている。また、バックアップ部74は、起動停止入力装置73に接続されている。その他の構成および動作は、実施の形態1(図1)と同様であるため、ここでは説明を省略する。
起動停止入力装置73は、ユーザインタフェース実行装置2の起動または停止を実行する信号(起動信号、停止信号)をバックアップ部74に入力する。
バックアップ部74は、起動停止入力装置73から起動信号が入力されると、不揮発記憶部75に記憶されているデータを用いて、データ記憶部15の内容およびユーザインタフェース実行部14の状態を復元する。また、バックアップ部74は、起動停止入力装置73から停止信号が入力されると、データ記憶部15の内容およびユーザインタフェース実行部14の状態を不揮発記憶部75に記憶(バックアップ)させ、ユーザインタフェース実行装置2を停止する。
不揮発記憶部75は、SDカード(登録商標)またはHDD等、電源供給がなくてもデータを保持することができる記憶デバイスである。
また、ユーザインタフェース設計装置1のインタフェース定義部7は、インタフェース定義9のデータ取得インタフェースに対して、データの種類を示すフラグを設定する。これにより、データ取得インタフェースに基づいて取得するデータが、電源断時(ユーザインタフェース実行装置2の停止時)に変化するデータであるか否かを定義することが可能となる。
図17は、インタフェース定義9のデータ取得インタフェースに対するデータの種類を示すフラグの設定の一例を示す図である。
図17において、fixedを指定したデータは電源断後でも不変であることを示し、periodicを指定したデータは電源断後でも変化することを示している。このような定義をデータ記憶部16に記憶させておくことによって、電源断後でも変化するデータはバックアップの対象としないといった処理を行うことができる。
図18は、データ記憶部16で管理されるデータの形式の一例を示す図である。
図18に示すように、データ記憶部16は、key−value−typeの組み合わせを管理している。バックアップ部74は、データ記憶部16で管理される図18に示すデータを参照することによって、電源断時にどのデータを不揮発記憶部75に記憶させるのか判断することができる。
例えば、実施の形態1の実施例で説明したカーナビゲーションシステムにおいて、カーナビゲーションシステムの終了時における状態を保存し、終了時に動作していたアプリケーションまたは画面に表示していた情報を次回の起動時に復帰させる必要がある場合において、本実施の形態5によるユーザインタフェース実行装置72を用いることによって、終了時のデータのうち次回の起動時に使用可能なデータのみを保存する。これにより、次回の起動時にデータ提供部にアクセスすることなく、前回終了時のデータを復元して起動することができるため、ユーザインタフェース実行装置72の起動を高速化することができる。
以上のことから、本実施の形態5によれば、ユーザインタフェース実行装置72の起動を高速化させることが可能となる。
なお、図1,11,12,14,16において、遷移設計部6、インタフェース定義部7、状態遷移生成部10、先読み生成部11、データ取得生成部12、先読み管理生成部13、ユーザインタフェース実行部14,35,41,42,43,64、データ取得部15,44,65、イベント取得部17,46,51,56,67、状態遷移部18,47,52,57,68、データ処理部19,48,53,58,69、データ要求部20,49,54,59,70、提示制御部21,41,55,60,71、要求処理部22、先読み管理部23、応答返却部24、データ生成処理部25、バックアップ部74の各々は、図2のプロセッサ26がメモリ27に記憶されたソフトウェアプログラムに従って動作することにより実現された。しかし、これに代えて、遷移設計部6、インタフェース定義部7、状態遷移生成部10、先読み生成部11、データ取得生成部12、先読み管理生成部13、ユーザインタフェース実行部14,35,41,42,43,64、データ取得部15,44,65、イベント取得部17,46,51,56,67、状態遷移部18,47,52,57,68、データ処理部19,48,53,58,69、データ要求部20,49,54,59,70、提示制御部21,41,55,60,71、要求処理部22、先読み管理部23、応答返却部24、データ生成処理部25、バックアップ部74の各々は、ハードウェア(例えば、電気信号に対して特定の演算あるいは処理を行うように構成された演算/処理回路等)として構成するようにしてもよい。また、上記の両者を混在させてもよい。
また、ソフトウェアの遷移設計部6、インタフェース定義部7、状態遷移生成部10、先読み生成部11、データ取得生成部12、先読み管理生成部13、ユーザインタフェース実行部14,35,41,42,43,64、データ取得部15,44,65、イベント取得部17,46,51,56,67、状態遷移部18,47,52,57,68、データ処理部19,48,53,58,69、データ要求部20,49,54,59,70、提示制御部21,41,55,60,71、要求処理部22、先読み管理部23、応答返却部24、データ生成処理部25、バックアップ部74の各々と、ハードウェアの遷移設計部6、インタフェース定義部7、状態遷移生成部10、先読み生成部11、データ取得生成部12、先読み管理生成部13、ユーザインタフェース実行部14,35,41,42,43,64、データ取得部15,44,65、イベント取得部17,46,51,56,67、状態遷移部18,47,52,57,68、データ処理部19,48,53,58,69、データ要求部20,49,54,59,70、提示制御部21,41,55,60,71、要求処理部22、先読み管理部23、応答返却部24、データ生成処理部25、バックアップ部74の各々とを組み合わせた概念として、「部」という語に代えて「処理回路」という語を用いることもできる。
なお、本発明は、その発明の範囲内において、各実施の形態を自由に組み合わせたり、各実施の形態を適宜、変形、省略することが可能である。
本発明は詳細に説明されたが、上記した説明は、すべての態様において、例示であって、この発明がそれに限定されるものではない。例示されていない無数の変形例が、この発明の範囲から外れることなく想定され得るものと解される。