(57)【要約】【課題】対象のソフトウェアを外部ディスプレイに出力した場合における、当該外部ディスプレイ上における表示状態をチェックする。【解決手段】内蔵ディスプレイである第一のディスプレイと、外部ディスプレイである第二のディスプレイに画面出力が可能な第一のコンピュータで動作するソフトウェアが、規定に沿った画面インタフェースを有するかチェックするユーザインタフェース評価装置であって、第二のディスプレイの実サイズおよび解像度を取得する解像度取得手段と、ソフトウェアのユーザインタフェース画面上に配置されたコンポーネントに関する情報を取得する設計情報取得手段と、ソフトウェアが第一のコンピュータ上で実行され、ユーザインタフェース画面が第二のディスプレイに出力された場合において、当該第二のディスプレイ上における外観に関する条件が、所定の条件を満たさないコンポーネントがあることを検出する検出手段と、を有する。【選択図】図１
2016024668.tif 000002
【特許請求の範囲】
【請求項１】
内蔵されたディスプレイである第一のディスプレイと、外部に接続されたディスプレイである第二のディスプレイに画面出力が可能な第一のコンピュータで動作するソフトウェアが、規定に沿った画面インタフェースを有するかチェックするユーザインタフェース評価装置であって、
前記第二のディスプレイの実サイズおよび解像度を取得する解像度取得手段と、
前記ソフトウェアのユーザインタフェース画面上に配置されたコンポーネントに関する情報を取得する設計情報取得手段と、
前記ソフトウェアが前記第一のコンピュータ上で実行され、前記ユーザインタフェース画面が前記第二のディスプレイに出力された場合において、当該第二のディスプレイ上における外観に関する条件が、所定の条件を満たさないコンポーネントがあることを検出する検出手段と、
を有する、ユーザインタフェース評価装置。
【請求項２】
前記外観に関する条件は、対象のコンポーネントが前記第二のディスプレイに表示された際の実サイズに関する条件である、
請求項１に記載のユーザインタフェース評価装置。
【請求項３】
前記所定の条件は、前記コンポーネントに含まれる文字のサイズ、前記コンポーネントの高さ、前記コンポーネントの幅、隣接するコンポーネントとの間隔のうちのいずれかの最小値である、
請求項２に記載のユーザインタフェース評価装置。
【請求項４】
第三のディスプレイと、
前記ユーザインタフェース画面を、前記第二のディスプレイに出力した場合の結果をエミュレートした画面であるエミュレート画面を生成し、前記第三のディスプレイに出力するエミュレート手段と、をさらに有する、
請求項１から３のいずれかに記載のユーザインタフェース評価装置。
【請求項５】
前記解像度取得手段は、前記第三のディスプレイの実サイズおよび解像度をさらに取得し、
前記エミュレート手段は、前記第二のディスプレイと同一の実サイズで前記エミュレート画面を生成する、
請求項４に記載のユーザインタフェース評価装置。
【請求項６】
前記検出手段が、前記所定の条件を満たさないコンポーネントが前記ユーザインタフェース画面に含まれていることを検出した場合に、利用者に警告を行う警告手段をさらに有する、
請求項１から５のいずれかに記載のユーザインタフェース評価装置。
【請求項７】
前記第一のコンピュータは、携帯端末であり、
前記第二のディスプレイは、車載装置が有するディスプレイである、
請求項１から６のいずれかに記載のユーザインタフェース評価装置。
【請求項８】
内蔵されたディスプレイである第一のディスプレイと、外部に接続されたディスプレイである第二のディスプレイに画面出力が可能な第一のコンピュータで動作するソフトウェアが、規定に沿った画面インタフェースを有するかチェックするユーザインタフェース評価装置が行うユーザインタフェース評価方法であって、
前記第二のディスプレイの実サイズおよび解像度を取得する解像度取得ステップと、
前記ソフトウェアのユーザインタフェース画面上に配置されたコンポーネントに関する情報を取得する設計情報取得ステップと、
前記ソフトウェアが前記第一のコンピュータ上で実行され、前記ユーザインタフェース画面が前記第二のディスプレイに出力された場合において、当該第二のディスプレイ上における外観に関する条件が、所定の条件を満たさないコンポーネントがあることを検出する検出ステップと、
を含む、ユーザインタフェース評価方法。
【請求項９】
請求項８に記載のユーザインタフェース評価方法の各ステップをコンピュータに実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアのユーザインタフェースを評価する装置に関する。
【背景技術】
【０００２】
近年、スマートフォン等の携帯端末の普及に伴い、クロスプラットフォーム、すなわち、ターゲットとなるデバイスとは異なるプラットフォーム上で動作する開発環境が普及している（非特許文献１参照）。
【０００３】
携帯端末の画面は限られたサイズであるため、開発者が自由に画面デザインを行うと、ユーザビリティの低下を引き起こすおそれがある。そこで、画面デザインに関する規約を設け、規約に沿ったコーディングを行うという手法が一部で採用されている。
例えば、特許文献１に記載のシステムでは、開発対象のソフトウェアのコードを開発環境上で自動的にチェックし、規約に違反したコードを発見した場合に、警告を行うことができる。規約は、例えば、ソフトウェアのパブリッシャや、業界団体によって作成される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平０８−１０１７７１号公報
【非特許文献】
【０００５】
【非特許文献１】”Android SDK”、［online］、［平成２６年７月１日検索］、インターネット＜URL：http://developer.android.com/sdk/＞
【非特許文献２】”MirrorLink”、［online］、［平成２６年７月１日検索］、インターネット＜URL：http://www.mirrorlink.com/＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで最近、携帯端末と車載機器の融合を目指し、スマートフォンをはじめとするモバイルコンピュータを車載機器に接続するための規格が提唱されている（非特許文献２）。このような規格によってスマートフォンを接続することで、車載機器（例えばナビゲーション装置）のディスプレイ上に、スマートフォンの画面を出力することが可能になる。
【０００７】
一方、車載機器のディスプレイは、運転しながら視認する可能性があるため、当該ディスプレイに出力されるＧＵＩは、運転の妨げにならないような（すなわち集中力を低下させないような）デザインであることが好ましい。このようなデザインについては、例えば、日本自動車工業会の「画像表示装置ガイドライン」において定義されている。
【０００８】
携帯端末上で動作するソフトウェアであって、車載端末のディスプレイに画面を出力することが想定されるソフトウェアを作成する場合、このようなガイドラインを踏襲したコーディング規約を設け、当該規約に沿って画面のデザインを行うことが好ましい。
例えば、「文字フォントの高さは○ミリ以上」、「ボタン同士の間隔は○ミリ以上」といったようなコーディング規約を用いることができる。
【０００９】
ここで問題となるのが、車載機器のディスプレイサイズは、メーカーによってまちまちであるため、ユーザの元で実際に表示される際の画面サイズが、開発時にわからないという点である。
非特許文献１に記載の開発環境では、ターゲットとなるデバイスの解像度を指定し、どのような表示のされ方がされるのかを、実際に画面上でエミュレートすることができる。しかし、車載機器のディスプレイのように、ターゲットデバイスの外部にディスプレイを接続するような場合、出力される画面のサイズは、当該ディスプレイの解像度やサイズに依存したものとなる。すなわち、画面に含まれるコンポーネントが、どのような大きさで表示されるかは、実機を接続するまでわからない。
また、特許文献１に記載のシステムでは、画面に含まれるコンポーネントが、規約を満たすものであるかをチェックすることはできるが、外部ディスプレイに画面を出力した際に、当該コンポーネントが実際にどのような大きさで表示されるかまではチェックすることができない。
【００１０】
このように、従前の開発環境では、ターゲットデバイスの外部にディスプレイを接続して表示を行うような環境をエミュレートすることができないため、ディスプレイ上での最終的な表示サイズに関する規約があったとしても、当該規約に沿ったコーディングがされているか否かをチェックすることができないという問題があった。
【００１１】
本発明は上記の課題を考慮してなされたものであり、対象のソフトウェアを外部ディスプレイに出力した場合における、当該外部ディスプレイ上における表示状態をチェック可能なユーザインタフェース評価装置を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記課題を解決するために、本発明に係るユーザインタフェース評価装置は、
内蔵されたディスプレイである第一のディスプレイと、外部に接続されたディスプレイである第二のディスプレイに画面出力が可能な第一のコンピュータで動作するソフトウェアが、規定に沿った画面インタフェースを有するかチェックするユーザインタフェース評価装置であって、前記第二のディスプレイの実サイズおよび解像度を取得する解像度取得手段と、前記ソフトウェアのユーザインタフェース画面上に配置されたコンポーネントに関する情報を取得する設計情報取得手段と、前記ソフトウェアが前記第一のコンピュータ上で実行され、前記ユーザインタフェース画面が前記第二のディスプレイに出力された場合において、当該第二のディスプレイ上における外観に関する条件が、所定の条件を満たさないコンポーネントがあることを検出する検出手段と、を有することを特徴とする。
【００１３】
第一のディスプレイとは、ターゲットデバイスが有するディスプレイであり、第二のディスプレイとは、ターゲットデバイスの外部に接続される外部ディスプレイである。
また、解像度取得手段は、第二のディスプレイの実サイズおよび解像度を取得する手段である。第二のディスプレイの実サイズおよび解像度は、例えば、ユーザの入力によって取得してもよい。また、複数の第二のディスプレイに関する情報を記憶しておき、合致するものをその都度取得するようにしてもよい。
【００１４】
また、設計情報取得手段は、対象ソフトウェアのユーザインタフェース画面上に配置されたコンポーネントの配置状態に関する情報を取得する手段である。コンポーネントとは、画面を構成する部品であり、例えば、ラベル、リストボックス、ボタン等である。画面上に配置されるものであれば、対象はどのようなものであってもよい。また、配置状態とは、例えば、各コンポーネントの画面上における配置位置（座標）、縦サイズ、横サイズなどである。各コンポーネントの配置位置やサイズは、ピクセルやポイントなど、実表示サイズ（物理サイズ）に依存しない単位で表される。
【００１５】
また、検出手段は、解像度取得手段が取得した情報と、設計情報取得手段が取得した情報に基づいて、第二のディスプレイに出力された際における外観に関する条件が、所定の条件を満たさないコンポーネントがあることを検出する。
【００１６】
かかる構成によると、ユーザインタフェース画面が第二のディスプレイに出力された際の、当該第二のディスプレイ上におけるコンポーネントの表示状態をチェックすることができる。すなわち、ソフトウェアを実機で動作させずとも、開発環境上において、外観に関する規約に反したコンポーネントがあることを検出することができる。
【００１７】
また、前記外観に関する条件は、対象のコンポーネントが前記第二のディスプレイに表示された際の実サイズに関する条件であることを特徴としてもよい。
【００１８】
実サイズとは、実際に第二のディスプレイに表示された際の物理サイズである。これにより、例えば、ユーザが実際に目にするコンポーネントのサイズ（縦サイズ、横サイズ）や、コンポーネント同士の間隔などが、所定の条件を満たしていることを確認することができる。
【００１９】
また、前記所定の条件は、前記コンポーネントに含まれる文字のサイズ、前記コンポーネントの高さ、前記コンポーネントの幅、隣接するコンポーネントとの間隔のうちのいずれかの最小値であることを特徴としてもよい。
【００２０】
これらの条件が規定を満たしていることを確認することで、第二のディスプレイにユーザインタフェース画面を出力した際のユーザビリティを確保することができる。
【００２１】
また、本発明に係るユーザインタフェース評価装置は、第三のディスプレイと、前記ユーザインタフェース画面を、前記第二のディスプレイに出力した場合の結果をエミュレートした画面であるエミュレート画面を生成し、前記第三のディスプレイに出力するエミュレート手段と、をさらに有することを特徴としてもよい。
【００２２】
第三のディスプレイは、ユーザインタフェース評価装置が有するディスプレイである。
エミュレート手段は、解像度取得手段が取得した情報と、配置取得手段が取得した情報に基づいて、第二のディスプレイ上でどのような表示が行われるかをエミュレートすることができる。
【００２３】
また、前記解像度取得手段は、前記第三のディスプレイの実サイズおよび解像度をさらに取得し、前記エミュレート手段は、前記第二のディスプレイと同一の実サイズで前記エミュレート画面を生成することを特徴としてもよい。
【００２４】
さらに、第三のディスプレイの実サイズおよび解像度を取得することで、エミュレートを行う際の画面サイズを、第二のディスプレイに表示される実際の画面サイズと一致させることができる。
【００２５】
また、本発明に係るユーザインタフェース評価装置は、前記検出手段が、前記所定の条件を満たさないコンポーネントが前記ユーザインタフェース画面に含まれていることを検出した場合に、利用者に警告を行う警告手段をさらに有することを特徴としてもよい。
【００２６】
警告は、例えば、画面上にアラートを表示させることで行ってもよいし、ログを出力することで行ってもよい。また、当該警告には、作成されたコードが、所定の条件をどのように逸脱しているのかといった情報を含ませることが好ましい。
【００２７】
また、前記第一のコンピュータは、携帯端末であり、前記第二のディスプレイは、車載装置が有するディスプレイであることを特徴としてもよい。
【００２８】
携帯端末を車載装置に接続し、当該車載装置が有するディスプレイを用いて画面表示を行う場合、特に、画面インタフェースに関する制約が大きくなる。本発明に係るユーザインタフェース評価装置は、このような環境に好適に適用することができる。
【００２９】
本発明は、上記処理の少なくとも一部を含む、ユーザインタフェース評価装置として特定することもできる。また、ユーザインタフェース評価装置が実行するソフトウェアチェック方法として特定することもできる。上記処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。
【発明の効果】
【００３０】
本発明によれば、対象のソフトウェアを外部ディスプレイに出力した場合における、当該外部ディスプレイ上における表示状態をチェック可能なユーザインタフェース評価装置を提供することができる。
【図面の簡単な説明】
【００３１】
【図１】第一の実施形態に係るソフトウェア作成装置の構成図である。
【図２】第一の実施形態におけるコンポーネントの配置例である。
【図３】第一の実施形態におけるソフトウェアの画面表示例である。
【図４】ターゲットディスプレイについての情報を説明する図である。
【図５】ＧＵＩ設計データおよびディスプレイデータの例である。
【図６】第一の実施形態におけるチェック処理のフローチャート図である。
【図７】第二の実施形態におけるディスプレイデータの例である。
【図８】第二の実施形態におけるエミュレータ画面の例である。
【図９】変形例に係る画面の表示例である。
【発明を実施するための形態】
【００３２】
（第一の実施形態）
<システム構成>
第一の実施形態に係るソフトウェア作成装置について、システム構成図である図１を参照しながら説明する。第一の実施形態に係るソフトウェア作成装置１００は、携帯端末２００上で動作するソフトウェアを作成するための装置である。
ソフトウェア作成装置１００は、プロセッサ、主記憶装置、補助記憶装置を有するコンピュータであり、補助記憶装置に記憶されたプログラムが主記憶装置にロードされ、プロセッサによって実行されることによって、後述する各手段が機能する（プロセッサ、主記憶装置、補助記憶装置はいずれも不図示）。
【００３３】
ターゲットデバイスである携帯端末２００は、携帯型のコンピュータ（携帯電話、スマートフォン、ＰＤＡ、ハンドヘルドコンピュータ等）であり、ソフトウェア作成装置１００にて作成したソフトウェアを実行する端末である。また、携帯端末２００は、車載端末３００と接続する機能を有しており、実行中のソフトウェアのユーザインタフェース画面を出力することができる。
【００３４】
車載端末３００は、車両に搭載される車載型のコンピュータである。車載端末３００は、ディスプレイ３１０を有しており、当該ディスプレイに、携帯端末２００で実行中のソフトウェアのユーザインタフェース画面を出力することができる。
これにより、車両に乗車しているユーザが、携帯端末２００にて利用しているアプリケーションソフトウェア（例えば、ナビゲーションアプリ、音楽アプリ、ブラウザ、ＳＮＳクライアントなど）を、大画面を通して利用することができる。
【００３５】
次に、ソフトウェア作成装置１００について詳細に説明する。ソフトウェア作成装置１
００は、入出力部１０１、設計部１０２、記憶部１０３、解像度取得部１０４、規約チェック部１０５、コード生成部１０６からなる。
【００３６】
入出力部１０１は、ユーザが行った入力操作を受け付け、ユーザに対して情報を提示する手段である。具体的には、液晶ディスプレイ、キーボード、マウス等とその制御手段から構成される。
【００３７】
設計部１０２は、ソフトウェアの設計を行う手段である。具体的には、ソフトウェアの設計を行うための画面（例えばコードエディタや画面エディタ）を、入出力部１０１を通してソフトウェア開発者に提示し、当該開発者によって入力されたソフトウェアの設計データを取得する。ソフトウェアの設計データとは、ユーザインタフェース画面の設計データ（以下、ＧＵＩ設計データ）と、ロジックに関する設計データである。
【００３８】
ここで、ＧＵＩ設計データについて説明する。ＧＵＩ設計データとは、開発対象のソフトウェアが有するユーザインタフェース画面（以下、フォーム）上に配置された部品（以下、コンポーネント）の配置を表すデータである。図２に、コンポーネントの配置例を示す。本例は、複数のラベル（文字領域）、ボタン、イメージ等をそれぞれフォーム２０１上に配置した例である。コンポーネントの配置は、例えば、左上の点の座標、幅、高さ、フォントサイズ（文字コンポーネントの場合）などによって表される。なお、本例では、コンポーネントとしてラベル、ボタン、イメージを例示したが、画面上に配置されるものであれば、コンポーネントはどのようなものであってもよい。例えば、リストボックス、セレクトボックス、チェックボックス等であってもよい。
ソフトウェアの開発者は、設計部１０２が生成したエディタ画面を通して、フォーム上にコンポーネントの配置を行う。また同様に、設計部１０２が生成したエディタ画面を通して、ロジックのコーディングを行う。
【００３９】
ソフトウェアが実行される際は、このように配置されたコンポーネントが、設計されたロジックに従って動作する。例えば、図３のように、実際のデータが埋め込まれてユーザに提供される（図３は、音楽プレーヤの例）。
設計部１０２が取得した設計データは、例えば、コードが記述されたテキストファイルや、画面デザインを表すＸＭＬファイルによって、記憶部１０３に一時的に記憶される。
【００４０】
記憶部１０３は、ソフトウェアの設計に関するデータを一時的に記憶する手段である。記憶部１０３には、高速に読み書きでき、かつ、大容量な記憶媒体を用いることが好ましい。例えば、フラッシュメモリなどを好適に用いることができる。
【００４１】
解像度取得部１０４は、ソフトウェアのユーザインタフェース画面が表示されるディスプレイについての情報を取得する手段である。対象のディスプレイとは、携帯端末２００が有するディスプレイと、車載端末３００が有するディスプレイ３１０の二種類である。具体的には、図４に示したように、対象ディスプレイの有効表示領域の、縦方向および横方向の物理サイズ、および、縦方向および横方向のピクセル数を取得する。以下、当該二つの情報をディスプレイデータと称する。ディスプレイデータの詳細例については後述する。
なお、ディスプレイデータは、入出力部１０１を通してその都度取得してもよいし、プリセットされた複数の値からその都度取得してもよい。また、対象のディスプレイは複数であってもよい。解像度取得部１０４が取得したディスプレイデータは、記憶部１０３によって一時的に記憶される。
【００４２】
規約チェック部１０５は、設計部１０２が取得したＧＵＩ設計データと、解像度取得部１０４が取得したディスプレイデータに基づいて、コーディング規約を逸脱したコンポー
ネントが無いかチェックする手段である。コーディング規約の内容、および、具体的なチェック方法については後述する。
【００４３】
コード生成部１０６は、設計部１０２が取得したコードに基づいて、実行形式のプログラムを生成（ビルド）する手段である。ビルドされたプログラムは、配布形式のソフトウェアパッケージとして最終的に出力される。なお、コード生成部１０６は、有線接続または無線接続によって、当該ソフトウェアパッケージを携帯端末２００に転送する機能を有していてもよい。
【００４４】
<チェック方法>
次に、コーディング規約について説明する。本実施形態におけるコーディング規約とは、フォームをディスプレイ３１０に表示した際の、当該フォームに含まれるコンポーネントの大きさないし位置に関する制約の集合である。本実施形態におけるコーディング規約は、例えば、以下のうちの少なくとも一つを含む。なお、以下に示す「サイズ」「高さ」「間隔」とは全て、ディスプレイ３１０上における実サイズ（ｍｍ）である。
（１）ラベルに関連付いた文字列の高さが所定値以上であること
（２）ラベルに関連付いた文字列の文字数が所定値以下であること
（３）コンポーネント同士の間隔が所定値以上空いていること
（４）ボタンの縦サイズおよび横サイズが所定値以上であること
なお、使用するコーディング規約は、フォームを外部ディスプレイに表示した場合の、当該フォームに含まれるコンポーネントの外観に関するものであれば、例示したもの以外であってもよい。
【００４５】
設計部１０２が取得するＧＵＩ設計データは、コンポーネントの配置を、ピクセルで指定したものである。図５（Ａ）は、設計部１０２によって取得され、記憶部１０３に記憶されるＧＵＩ設計データの例である。ここでは、フォーム上における座標（コンポーネントの左上座標）、幅、高さが、コンポーネントごとに定義される。
【００４６】
一方、ＧＵＩ設計データだけでは、各コンポーネントが、ディスプレイ３１０上で実際にどのようなサイズで表示されるかを推定することはできない。そこで、本実施形態に係るソフトウェア作成装置では、ディスプレイデータを用いて、フォームをディスプレイ３１０に表示した際のエミュレーションを行う。具体的には、ピクセル数で表されたＧＵＩ設計データを、ディスプレイ上における実サイズ（物理サイズ）に変換する。
例えば、ディスプレイ３１０の横幅の実サイズが２５０[ｍｍ]であって、横方向の解像度が１２８０[ｐｘ]であり、表示対象のコンポーネントＡの横幅が２３０[ｐｘ]であった場合を考える。この場合、当該コンポーネントＡの横幅の実サイズは、２５０×（２３０／１２８０）＝４４．９[ｍｍ]となる。
このような処理を行うと、図５（Ａ）に示したＧＵＩ設計データを、実サイズに置き換えることができる。
【００４７】
本実施形態に係るソフトウェア作成装置では、このように、ＧＵＩ設計データを実サイズに変換した結果と、コーディング規約とを比較することで、当該コーディング規約に反しているコンポーネントがあることを検出する。例えば、前述したコンポーネントＡの種別が「ボタン」であり、「外部ディスプレイ上におけるボタンの横幅は４５ｍｍ以上」というコーディング規約があった場合、当該コンポーネントは規約を満たさないものであると判定される。
【００４８】
フォーム上に配置されたコンポーネントが、規約を満たさないものである場合、その旨の警告が入出力部１０１を通してソフトウェア開発者に提示される。警告は、例えばコンソール画面に出力してもよいし、ダイアログ等によって出力してもよい。また、ログに出
力してもよい。
【００４９】
<処理フローチャート>
次に、以上に説明した機能を実現するための処理フローチャートについて説明する。
図６は、本実施形態に係るソフトウェア作成装置が行う、コーディングチェック処理のフローチャートである。当該処理は、ユーザの指示に基づいて（例えば、開発環境においてチェック機能を起動したタイミングで）、規約チェック部１０５によって実行される。
【００５０】
まず、ステップＳ１１で、解像度取得部１０４によって取得されたディスプレイデータ、すなわち表示に用いるディスプレイの解像度および画面サイズを取得する。本実施形態では、携帯端末２００に内蔵されたディスプレイと、車載端末３００が有するディスプレイ３１０についての情報を取得する。なお、ディスプレイデータについては、前述したように、手入力されたものを取得してもよいし、予めプリセットされた複数の値から、用いるものを取得するようにしてもよい。
【００５１】
次に、ステップＳ１２で、設計部１０２によって取得されたＧＵＩ設計データを取得する。
次に、ステップＳ１３で、ユーザインタフェース画面を外部ディスプレイに表示した際の実表示サイズを演算する。具体的には、ディスプレイデータのうち、種別が「外部」であるディスプレイについて、実サイズおよび解像度を取得し、前述した方法によってコンポーネントのサイズを演算する。
次に、ステップＳ１４で、演算結果とコーディング規約を比較することで、当該コーディング規約に反しているコンポーネントの有無を判定する。この結果、適合しないコンポーネントがあった場合（ステップＳ１５−Ｎｏ）、処理をステップＳ１６へ遷移させ、結果を提示する。全てのコンポーネントがコーディング規約に適合する場合、警告は行わず、処理は終了する。
【００５２】
以上に説明したように、第一の実施形態に係るソフトウェア作成装置は、ターゲットデバイスが有するディスプレイではなく、ターゲットデバイスに外部接続されるディスプレイに関する情報を用いて、実際に表示されるコンポーネントのサイズが規約を満たしているかを判定する。これにより、実際にソフトウェアのユーザが画面を目にする際の見え方に基づいて、コンポーネントの適合・非適合を判断することができ、ユーザビリティを確保することができる。
【００５３】
（第二の実施形態）
第二の実施形態は、設計対象のフォームをディスプレイ３１０に出力した際の画面をエミュレートし、当該ディスプレイ３１０上に表示される画面を、実サイズにてソフトウェア開発者に提示する実施形態である。
第二の実施形態に係るソフトウェア作成装置の構成は、第一の実施形態と同様であるため説明は省略し、処理が異なる部分についてのみ説明を行う。
【００５４】
第二の実施形態では、開発環境におけるディスプレイ（すなわち、入出力部１０１が利用するディスプレイ）のサイズおよび解像度を保持し、エミュレートに利用する。図７は、第二の実施形態におけるディスプレイデータの例である。当該データには、開発環境におけるディスプレイの情報が付加される。
【００５５】
また、第二の実施形態では、ステップＳ１３で算出した、対象コンポーネントのディスプレイ３１０上における実サイズを用いて、エミュレート画面のサイズを演算する。
例えば、入出力部１０１が利用するディスプレイの横幅の実サイズが４８０[ｍｍ]であって、横方向の解像度が１２８０[ｐｘ]であり、表示対象のコンポーネントＡの、ディス
プレイ３１０上における実サイズが４４．９[ｍｍ]であった場合を考える。この場合、ディスプレイ３１０上における実サイズを再現するための、当該コンポーネントのサイズは、１２８０×（４４．９／４８０）＝１２０[ｐｘ]となる。また、エミュレート画面中におけるコンポーネントの配置位置（座標）も同様にして算出することができる。
【００５６】
このようにして生成したエミュレート画面は、入出力部１０１を通してソフトウェア開発者に提示される。図８は、開発環境のディスプレイに出力されるエミュレート画面の例である。なお、エミュレート画面の生成は、ディスプレイデータおよびＧＵＩ設計データが入力されていれば、任意のタイミングで実行することができる。
【００５７】
第二の実施形態によると、ソフトウェア開発者が、ディスプレイ３１０に表示されるものと同一サイズの画面を、開発環境上で確認しながら開発を行うことができる。
なお、本実施形態では、ディスプレイ３１０を対象としてエミュレート画面を生成したが、同様の方法で、携帯端末２００の画面を対象としてエミュレートを行ってもよい。
【００５８】
（変形例）
なお、各実施形態の説明は本発明を説明する上での例示であり、本発明は、発明の趣旨を逸脱しない範囲で適宜変更または組み合わせて実施することができる。
【００５９】
例えば、携帯端末２００と車載端末３００との間で画面をやり取りする際に、画面デザインに影響するような変換が行われる場合がある。図９は、携帯端末２００が有するディスプレイと、ディスプレイ３１０とでアスペクト比が異なる場合の画面変換例である。本例では、縦方向の高さが画面にフィットするようにフォームが配置され、点線の外側領域については領域が補完される。このように、領域の補完や引き伸ばしが発生する場合、当該変換を考慮して、ディスプレイ３１０上における実サイズを演算するようにしてもよい。
【００６０】
また、ディスプレイデータは、例示したように、必ずしも縦横サイズ、縦横解像度の全てを含んでいる必要はない。例えば、解像度のみを定義し、実行時に、コーディング規約を満たすために必要な残りの条件（最低限必要な縦横サイズ）を提示するようにしてもよい。逆も同様である。
【００６１】
また、各実施形態では、ユーザの指示に基づいてチェック処理を実行する例を挙げたが、図６の処理はリアルタイムで行ってもよい。例えば、コンポーネントのレイアウトが変更されたことを検出し、チェックを自動的に実行するようにしてもよい。
【００６２】
また、各実施形態では、解像度としてピクセルを例示したが、他の単位を用いてもよい。例えば、端末の画面密度に依存しないピクセル単位であるDensity-independent Pixels（ＤＩＰ）や、Scale-independent Pixels（ＳＰ）を用いてもよいし、他の単位を用いてもよい。
【符号の説明】
【００６３】
１００  ソフトウェア作成装置
１０１  入出力部
１０２  設計部
１０３  記憶部
１０４  解像度取得部
１０５  規約チェック部
１０６  コード生成部
２００  携帯端末
３００  車載端末
３１０  ディスプレイ
【図１】
2016024668.tif 000003
【図２】
2016024668.tif 000004
【図３】
2016024668.tif 000005
【図４】
2016024668.tif 000006
【図５】
2016024668.tif 000007
【図６】
2016024668.tif 000008
【図７】
2016024668.tif 000009
【図８】
2016024668.tif 000010
【図９】
2016024668.tif 000011