JP6994071B2 - Ｐｒｏｔｏｂｕｆベースのプロジェクトのための包括的な検証手法 - Google Patents

Description

本開示の実施形態は一般にソフトウェア開発に関する。より具体的には、本開示の実施形態は、Ｐｒｏｔｏｂｕｆを使用するアプリケーションの検証において検証の代用ヘッダファイルを使用することに関する。

Ｇｏｏｇｌｅ（登録商標）によって開発されたプロトコル・バッファ（Ｐｒｏｔｏｂｕｆ）は、構造化データを直列化する、言語的にもプラットフォーム的にも中立の方法である。Ｐｒｏｔｏｂｕｆは、互いに有線で通信するため、またはデータを記憶するためのプログラムの開発において有用である。

Ｐｒｏｔｏｂｕｆを利用する人工知能（ＡＩ）アプリケーション（たとえば自律性乗物を運転するためのＡＩプログラム）が、ますます増えている。自動化された検証および評価のツールを使用する（たとえばメモリ安全性のための）そのようなＡＩアプリケーションの検証および評価は、Ｇｏｏｇｌｅによって提供されるＰｒｏｔｏｂｕｆコード・ジェネレータなどの標準的なＰｒｏｔｏｂｕｆコード・ジェネレータによって生成されたＰｒｏｔｏｂｕｆヘッダファイルの複雑さのために、遅く、多くの時間が必要となる。

本開示の実施形態が、限定ではなく例として示され、添付図面では類似の参照は類似の要素を指示する。

Ｐｒｏｔｏｂｕｆヘッダファイルを生成するための処理を示すブロック図である。 Ｐｒｏｔｏｂｕｆ定義ファイルの一例を示す図である。 一実施形態に係る検証の代用ヘッダファイルを生成する処理を示すブロック図である。 一実施形態に係るｅｘａｍｐｌｅ．ｐｒｏｔｏ Ｐｒｏｔｏｂｕｆ定義ファイルに対応する例示のＡＳＴを示す図である。 一実施形態に係る図３Ａに対応する特定のフィールドを定義するデータ構造の図表である。 一実施形態に係る図３Ａに対応する特定のフィールドを定義するデータ構造の図表である。 一実施形態に係る図３Ａの例示のＡＳＴに対応する等価のコードを示す図である。 一実施形態に係るデータ通信のためにＰｒｏｔｏｂｕｆを使用するアプリケーションの検証において検証の代用ヘッダファイルを使用するための方法を示す流れ図である。 一実施形態に係るデータ処理システムを示すブロック図である。

本開示の様々な実施形態および態様が、以下で論じられる詳細を参照しながら説明され、添付図面は様々な実施形態を示す。以下の説明および図面は本開示の実例であり、本開示を限定するものと解釈されるべきではない。本開示の様々な実施形態の完全な理解を提供するために、多くの具体的な詳細が説明される。しかしながら、特定の事例では、本開示の実施形態の簡潔な議論を提供するために、周知の詳細または旧来の詳細は説明されない。

本明細書における「一実施形態」または「実施形態」に対する参照は、実施形態に関連して説明された特定の特徴、構造、または特性が、本開示の少なくとも１つの実施形態に含まれ得ることを意味する。様々な位置において「一実施形態では」という慣用句が出現することは、必ずしもすべてが本明細書における同一の実施形態を指すわけではない。

いくつかの実施形態によれば、データ通信のためにプロトコル・バッファ（Ｐｒｏｔｏｂｕｆ）を使用するアプリケーションの検証において、検証の代用ヘッダファイルが使用される。Ｐｒｏｔｏｂｕｆ定義ファイルから１または複数のＰｒｏｔｏｂｕｆメッセージタイプが得られる。Ｐｒｏｔｏｂｕｆ定義ファイルは、対応するソースコードの実行中に呼び出される１または複数の関数を定義するＰｒｏｔｏｂｕｆ仕様に適合する。検証の代用ヘッダファイルは、Ｐｒｏｔｏｂｕｆメッセージタイプに基づいて生成され、検証の代用ヘッダファイルは、Ｐｒｏｔｏｂｕｆの専用ライブラリの代わりに標準Ｃ／Ｃ＋＋ライブラリを使用して呼び出される１または複数の関数を定義する。Ｐｒｏｔｏｂｕｆの専用ライブラリは検証するのが困難である。検証の代用ヘッダファイルに１または複数の検証スタブが付加される。検証の代用ヘッダファイルはアプリケーションのソースコードに含まれる。その後、検証の代用ヘッダファイルを含むアプリケーションの検証は、検証の代用ヘッダファイルに基づいて、呼び出された標準Ｃ／Ｃ＋＋ライブラリの関数のソースコードの検証を含めて遂行される。

一実施形態では、Ｐｒｏｔｏｂｕｆ定義ファイルから１または複数のＰｒｏｔｏｂｕｆメッセージタイプを得るステップは、Ｐｒｏｔｏｂｕｆ定義ファイルに基づいて抽象構文ツリー（ＡＳＴ）を生成するステップと、ＡＳＴを解析するステップとを含む。一実施形態では、各Ｐｒｏｔｏｂｕｆメッセージタイプについて、検証の代用ヘッダファイルの中にＣ＋＋クラスが生成され、Ｃ＋＋クラスの中に、対応するＰｒｏｔｏｂｕｆメッセージタイプの各フィールドについて、１つのメンバ・フィールドおよび対応するメンバ関数が生成される。

一実施形態では、Ｃ＋＋クラスの１または複数のオブジェクトの生成、アクセスまたは削除のための、検証の代用ヘッダファイルを含むアプリケーションの検証は、標準Ｃ／Ｃ＋＋ライブラリに依存する。一実施形態では、検証スタブは、メンバ関数に関連した１または複数の事前条件、メンバ関数に関連した１または複数の事後条件、またはこれらの組合せを含む。一実施形態では、１または複数の事前条件ならびに／あるいは１または複数の事後条件はカスタマイズ可能である。一実施形態では、ＰｒｏｔｏｂｕｆメッセージタイプはＰｒｏｔｏｂｕｆ定義ファイルの中で定義される。

図１Ａを参照して、Ｐｒｏｔｏｂｕｆヘッダファイルを生成するための処理を示すブロック図１００が示されている。開発者は、Ｐｒｏｔｏｂｕｆインターフェース記述言語を用いるＰｒｏｔｏｂｕｆ定義ファイル１１０（通常は．ｐｒｏｔｏのファイル名拡張子を有する）において構造化データ（またはメッセージ）を定義する。以下で、Ｐｒｏｔｏｂｕｆ定義ファイル１１０は、簡単にｐｒｏｔｏファイルとも称され得る。Ｐｒｏｔｏｂｕｆ定義ファイル１１０は、グーグルによって定義されたＰｒｏｔｏｂｕｆライブラリのセットに関連づけられたＰｒｏｔｏｂｕｆ仕様に適合する。Ｐｒｏｔｏｂｕｆコード・ジェネレータ１２０は、Ｐｒｏｔｏｂｕｆ定義ファイル１１０に基づいて、１または複数のＰｒｏｔｏｂｕｆヘッダファイル１３０を生成する。標準的なＰｒｏｔｏｂｕｆコード・ジェネレータ１２０はグーグルから入手可能である。たとえば、Ｐｒｏｔｏｂｕｆコード・ジェネレータ１２０は、Ｃ／Ｃ＋＋言語を用いて、Ｐｒｏｔｏｂｕｆ定義ファイル１１０からヘッダファイル（拡張子．ｐｂ．ｈを有する）およびインプリメンテーション・ファイル（拡張子．ｐｂ．ｃｃを有する）を生成する。その後、開発者はアプリケーションの中にヘッダファイル１３０を含めることができ、それによって、アプリケーションは、Ｐｒｏｔｏｂｕｆ定義ファイル１１０に含まれるメッセージタイプ定義に従ってＰｒｏｔｏｂｕｆメッセージを読んだり書いたりすることができる。

解説のために、図１Ｂには、ｅｘａｍｐｌｅ．ｐｒｏｔｏという名称の簡単な例示のＰｒｏｔｏｂｕｆ定義ファイル１１０が与えられている。この例では、ｅｘａｍｐｌｅ．ｐｒｏｔｏファイルは２つのメッセージタイプＭｓｇＴｙｐｅ１およびＭｓｇＴｙｐｅ２を定義しており、ＭｓｇＴｙｐｅ１は必要な３２ビットの整数値を含み、ＭｓｇＴｙｐｅ２は必要なブール値を含む。

この文献の最後の表１及び表２に列記されたｅｘａｍｐｌｅ．ｐｂ．ｈヘッダファイルは、図１Ｂに示されたようなグーグルのｅｘａｍｐｌｅ．ｐｒｏｔｏ定義ファイルに基づく標準的なＰｒｏｔｏｂｕｆコード・ジェネレータによって生成された例示のヘッダファイルである。ヘッダファイルｅｘａｍｐｌｅ．ｐｂ．ｈが、ＧｏｏｇｌｅのＰｒｏｔｏｂｕｆのインプリメンテーションからの専用ライブラリ（たとえばヘッダファイルがライン１～７に列記されたライブラリ）に大きく依存することが理解され得、このため、検証処理は、ＧｏｏｇｌｅのＰｒｏｔｏｂｕｆライブラリを詳細に調べて、対応する関数を検証する必要があるので、検証処理に付随する作業負荷が大幅に増加してしまう。

Ｐｒｏｔｏｂｕｆを利用する人工知能（ＡＩ）アプリケーション（たとえば自律性乗物を運転するためのＡＩプログラム）が、ますます増えている。自動化された検証および評価のツールを使用する（たとえばメモリ安全性のための）そのようなＡＩアプリケーションの検証および評価は、標準的なＰｒｏｔｏｂｕｆコード・ジェネレータによって生成されたＰｒｏｔｏｂｕｆヘッダファイルの複雑さのために、遅く、多くの時間を必要とする。具体的には、標準的なＰｒｏｔｏｂｕｆコード・ジェネレータによって生成されたＰｒｏｔｏｂｕｆヘッダファイルは、標準的なＰｒｏｔｏｂｕｆライブラリからのデータ構造を用いて生成されているため、複雑である。したがって、検証されかつ検査されるアプリケーションの中に標準的なＰｒｏｔｏｂｕｆコード・ジェネレータによって生成されたＰｒｏｔｏｂｕｆヘッダファイルを含めると、検証および確認の処理を不必要に低速化する恐れがある。

図２を参照して、一実施形態に係る検証の代用ヘッダファイルを生成する処理を示すブロック図２００が示されている。抽象構文ツリー（ＡＳＴ）ジェネレータ２１０は、Ｐｒｏｔｏｂｕｆ定義ファイル１１０を分析して、Ｐｒｏｔｏｂｕｆ定義ファイル１１０の中で定義されたメッセージタイプを記述するＡＳＴを生成する。次いで、ＡＳＴパーサ２２０は、ＡＳＴを解析して、各Ｐｒｏｔｏｂｕｆメッセージタイプにおけるすべてのフィールドを含むすべてのＰｒｏｔｏｂｕｆメッセージタイプを得る。そのようにして得られたＰｒｏｔｏｂｕｆメッセージタイプは、ＡＳＴ生成の基になったＰｒｏｔｏｂｕｆ定義ファイル１１０の中で定義されたものと一致するはずであることを理解されたい。

Ｐｒｏｔｏｂｕｆメッセージタイプが一旦得られると、検証コード・ジェネレータ２３０はＰｒｏｔｏｂｕｆメッセージタイプに基づいて１または複数のＣ＋＋クラスを生成する。詳細には、各Ｐｒｏｔｏｂｕｆメッセージタイプについて少なくとも１つのＣ＋＋クラスが生成される。検証コード・ジェネレータ２３０は、Ｐｒｏｔｏｂｕｆメッセージタイプにおける各フィールドについて、メンバ・フィールドならびにＰｒｏｔｏｂｕｆメッセージタイプに対応するＣ＋＋クラスにおけるメンバ・フィールドにアクセスするためのメンバ関数を生成する。データ・メンバおよび関数メンバを含むＣ＋＋クラスは、検証の代用ヘッダファイル２５０に保存される。

その上、検証の代用ヘッダファイル２５０が証明可能なように、検証スタブ・ジェネレータ２４０は、検証の代用ヘッダファイル２５０に検証スタブを付加する。検証スタブは、少なくとも１つのメンバ関数のメモリ安全性などを保証するための事前条件および／または事後条件を含む。たとえば、事前条件は、１）関数の入力パラメータがポインタである場合にはＮＵＬＬポインタであってはならない、２）関数の入力パラメータは、それぞれの基本タイプの範囲を超えてはならない（たとえば整数、実数、倍精度実数などの基本タイプは定義された範囲を有する）、といった条件を含み得る。別の実施形態では、事前条件の一例は「入力値が特定の範囲内にあること」でよい。事後条件の一例は「出力値が特定の範囲内にあること」でよい。本明細書で説明された例示の事前条件および事後条件は例であり、本開示を限定するものではない。異なる実施形態では、事前条件および事後条件は異なるやり方でカスタマイズされ得る。加えて、事前条件および事後条件は任意の適切なフォーマットで定義され得る。一実施形態では、事前条件および事後条件を定義するためにＡＮＳＩ／ＩＳＯ Ｃ仕様言語（ＡＣＳＬ）が使用される。

したがって、標準Ｃ＋＋クラスが使用されるため、検証および評価のとき、検証の代用ヘッダファイル２５０がアプリケーションに含まれている場合には、オブジェクトの生成、アクセス、または削除のために依存されるのは標準Ｃ／Ｃ＋＋ライブラリのみ（たとえばｓｔｄｌｉｂｃ＋＋）となり、より複雑な、Ｐｒｏｔｏｂｕｆに特有のコード、関数、およびライブラリは使用されない。

上記のｅｘａｍｐｌｅ．ｐｒｏｔｏ定義ファイルに対応するｖｅｒｉｆｉｃａｔｉｏｎ＿ｅｘａｍｐｌｅ．ｈという名称の例示の検証の代用ヘッダファイル２５０が、解説のために、この文献の最後の表３から表５に与えられている。表１及び表２のｅｘａｍｐｌｅ．ｐｂ．ｈヘッダファイルと比較して、各メッセージタイプに関して必要なすべての方法が大幅に簡素化されたことが認められる。事前条件および事後条件に関する検証検査は、パラメータを有する関数に付加される。詳細には、引数としてポインタを有する関数にはポインタ検査が付加される。たとえば、ｖｅｒｉｆｉｃａｔｉｏｎ＿ｅｘａｍｐｌｅ．ｈのライン４６～４７（表３及び表４参照）に示されるように、検証サブ“／＊＠ ｒｅｑｕｉｒｅｓ ＼ｖａｌｉｄ（ｘ）＊／”が挿入されている。同様に、ライン８１は変数“ｆｒｏｍ”の検証を必要とし、ライン８６は変数“ｏｔｈｅｒ”の検証を必要とする。そのような検証スタブは、変数“ｘ”が有効なポインタであることを確認するための検証処理を命令する。検証が失敗すると（たとえばポインタｘが無効なポインタであると）、ユーザに通知するために警報が生成されてよい。条件はＡＣＳＬフォーマットに従う。それゆえに、検証処理は、条件が満たされるかどうかを自動的に検査して確認することになる。Ｐｒｏｔｏｂｕｆ定義ファイルに基づいてＡＳＴを生成することは、当業者の技量の範囲内にある。

図３Ａを参照して、ｅｘａｍｐｌｅ．ｐｒｏｔｏ定義ファイルに対応するＡＳＴ ３００の一例が示されている。ＡＳＴ ３００は、Ｐｒｏｔｏｂｕｆ定義ファイル名（“１：ｅｘａｍｐｌｅ．ｐｒｏｔｏ”）、パッケージ名（“２：ｔｅｓｔ”）、および２つの定義されたメッセージタイプ（すなわちＭｓｇＴｙｐｅ１およびＭｓｇＴｙｐｅ２）に関する情報を含む（ノード“３：１”：両方のメッセージタイプが１つのフィールドを有する、ノード“４：２”：両方のメッセージタイプが「必要な」ラベルを有する、ノード“５：５”および“５：８”：フィールド・タイプはそれぞれｉｎｔ３２およびｂｏｏｌである）。一実施形態によれば、キー値ペアと同様に、キー（たとえば図３Ｂに示されるようなフィールドＩＤ）およびキーに関連する値（たとえば図３Ｃに示されるようなフィールド・タイプ）を列挙するために数が利用される。ＡＳＴパーサは、各Ｐｒｏｔｏｂｕｆメッセージタイプにおけるすべてのフィールドを含むすべてのＰｒｏｔｏｂｕｆメッセージタイプを得るために、ＡＳＴを解析してよい。解説のために、ＡＳＴの等価なコード表現が図３Ｄに与えられている。

図４を参照して、データ通信のためにＰｒｏｔｏｂｕｆを使用するアプリケーションの検証において検証の代用ヘッダファイルを使用するための方法４００の流れ図が示されている。方法４００はハードウェア、ソフトウェア、またはこれらの組合せで実施され得る。ブロック４１０において、Ｐｒｏｔｏｂｕｆ定義ファイル（たとえばＰｒｏｔｏｂｕｆと互換性がある定義ファイル）に基づいて、１または複数のＰｒｏｔｏｂｕｆメッセージタイプが得られる。ブロック４２０において、標準Ｃ／Ｃ＋＋ヘッダファイルと互換性があるＰｒｏｔｏｂｕｆメッセージタイプに基づいて、検証の代用ヘッダファイルが生成される。ブロック４３０において、検証の代用ヘッダファイルに１または複数の検証スタブが付加される。ブロック４４０において、検証の代用ヘッダファイルがアプリケーションのソースコードに含まれる。ブロック４５０において、Ｐｒｏｔｏｂｕｆの専用ライブラリの検証を必要とすることなく、標準Ｃ／Ｃ＋＋ライブラリのみを検証することにより、検証の代用ヘッダファイルを含むアプリケーションが検証される。

上記で示されて説明されたコンポーネントのうちいくつかまたはすべてが、ソフトウェア、ハードウェア、またはこれらの組合せで実施され得ることに留意されたい。たとえば、そのようなコンポーネントは持続的記憶デバイスにインストールして記憶されたソフトウェアとして実施され得、本出願の全体にわたって説明された処理または演算を実行するために、プロセッサ（図示せず）によってメモリにロードされ、かつ実行され得る。あるいは、そのようなコンポーネントは、集積回路（たとえば特定用途向けＩＣすなわちＡＳＩＣ）、デジタル信号プロセッサ（ＤＳＰ）、またはフィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）などの専用ハードウェアの中にプログラムされた、または組み込まれた、アプリケーションから、対応するドライバおよび／またはオペレーティングシステムを介してアクセス可能な実行可能コードとして実施され得る。その上、そのようなコンポーネントは、ソフトウェア・コンポーネントによって１または複数の特定の命令を介してアクセス可能な命令セットの一部分として、プロセッサまたはプロセッサコアにおける特定のハードウェア・ロジックとして実施され得る。

Ｃ＋＋プログラム言語を参照しながらいくつかの実施形態が説明されてきたが、本開示はプログラム言語によって制限されず、本開示の実施形態は、本開示の範囲から逸脱することなく他のプログラム言語に適合し得ることを理解されたい。

図５は、本開示の一実施形態とともに使用され得るデータ処理システムの一例を示すブロック図である。たとえば、システム１５００は、上記で説明された処理または方法のうち任意のものを遂行する、上記で説明されたデータ処理システムのうち任意のものを表し得、たとえば、図２のＡＳＴジェネレータ２１０、ＡＳＴパーサ２２０、検証コード・ジェネレータ２３０、および検証スタブ・ジェネレータ２４０などでよい。システム１５００は多くの様々な構成要素を含むことができる。これらの構成要素は、集積回路（ＩＣ）、ＩＣの一部分、個別の電子デバイス、またはコンピュータシステムのマザーボードもしくはアドイン・カードなどの回路基板に適合された他のモジュール、またはコンピュータシステムのシャーシの内部に別様に組み込まれた構成要素として実施され得る。

システム１５００は、コンピュータシステムの多くの構成要素の高レベルの概観を示すように意図されていることにも留意されたい。しかしながら、特定の実装形態には追加の構成要素が存在し得、その上、他の実装形態では、示された構成要素の種々の配置が生じ得ることを理解されたい。システム１５００は、デスクトップ・コンピュータ、ノートパソコン、タブレット型コンピュータ、サーバ、携帯電話、メディアプレーヤ、携帯情報端末（ＰＤＡ）、スマートウォッチ、パーソナル・コミュニケータ、ゲーム機、ネットワークのルータまたはハブ、無線アクセスポイント（ＡＰ）またはリピータ、セットトップ・ボックス、またはこれらの組合せを表し得る。さらに、単一のマシンまたはシステムしか示されていないが、「マシン」または「システム」という用語は、本明細書で論じられた技法のうち任意の１または複数を遂行する１組（または複数の組）の命令を個々にまたは連帯的に実行するマシンまたはシステムの任意の収集を含むと解釈されるものとする。

一実施形態では、システム１５００は、バスまたは相互接続１５１０を介して接続される、プロセッサ１５０１、メモリ１５０３、およびデバイス１５０５～１５０８を備える。プロセッサ１５０１は、単一のプロセッサコアまたは複数のプロセッサコアを含む、単一のプロセッサまたは複数のプロセッサを表し得る。プロセッサ１５０１は、マイクロプロセッサ、中央処理装置（ＣＰＵ）等の１または複数の汎用プロセッサを表し得る。より具体的には、プロセッサ１５０１は、複数命令セット・コンピューティング（ＣＩＳＣ）マイクロプロセッサ、縮小命令セット・コンピューティング（ＲＩＳＣ）マイクロプロセッサ、超長命令語（ＶＬＩＭ）マイクロプロセッサ、他の命令セットを実施するプロセッサ、または命令セットの組合せを実施するプロセッサでよい。プロセッサ１５０１は、特定用途向け集積回路（ＡＳＩＣ）、セルラー式プロセッサまたはベースバンド・プロセッサ、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、ネットワーク・プロセッサ、グラフィックス・プロセッサ、通信用プロセッサ、暗号プロセッサ、コプロセッサ、組み込み型プロセッサ、または命令を処理することができる何らかの他のタイプの論理などの１または複数の専用プロセッサでもよい。

超低電圧プロセッサなど低電力のマルチコア・プロセッサ・ソケットであり得るプロセッサ１５０１は、システムの様々な構成要素と通信するための主処理ユニットおよび中央ハブとして働き得る。そのようなプロセッサはシステム・オン・チップ（ＳｏＣ）として実施され得る。プロセッサ１５０１は、本明細書で論じた動作およびステップを遂行するための命令を実行するように構成されている。システム１５００がさらに含み得るグラフィックス・インターフェースは、表示コントローラ、グラフィックス・プロセッサ、および／または表示デバイスを含み得る任意選択のグラフィックス・サブシステム１５０４と通信する。

プロセッサ１５０１はメモリ１５０３と通信してよく、メモリ１５０３は、一実施形態では、所与の量のシステムメモリを与えるために複数のメモリ・デバイスによって実施され得る。メモリ１５０３は、ランダムアクセスメモリ（ＲＡＭ）、動的ＲＡＭ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、静的ＲＡＭ（ＳＲＡＭ）または他のタイプの記憶デバイスなど、１または複数の揮発性記憶（すなわちメモリ）デバイスを含み得る。メモリ１５０３は、プロセッサ１５０１または何らかの他のデバイスによって実行される命令のシーケンスを含む情報を記憶し得る。たとえば、種々のオペレーティングシステム、デバイス・ドライバ、ファームウェア（たとえば入出力基本システムすなわちＢＩＯＳ）の実行可能コードおよび／またはデータ、および／またはアプリケーションがメモリ１５０３にロードされ、プロセッサ１５０１によって実行され得る。オペレーティングシステムは、たとえば、ロボットオペレーティングシステム（ＲＯＳ）、マイクロソフト（登録商標）のウィンドウズ（登録商標）オペレーティングシステム、アップルのマックＯＳ（登録商標）／ｉＯＳ（登録商標）、グーグル（登録商標）のアンドロイド（登録商標）、ＬＩＮＵＸ、ＵＮＩＸ（登録商標）など任意の種類のオペレーティングシステム、または他のリアルタイム・オペレーティングシステムもしくは組み込み型オペレーティングシステムであり得る。

システム１５００がさらに含み得るデバイス１５０５～１５０８などのＩＯデバイスは、ネットワーク・インターフェース・デバイス１５０５、任意選択の入力デバイス１５０６、および他の任意選択のＩＯデバイス１５０７を含む。ネットワーク・インターフェース・デバイス１５０５は、無線トランシーバおよび／またはネットワーク・インターフェース・カード（ＮＩＣ）を含み得る。無線トランシーバは、Ｗｉ－Ｆｉトランシーバ、赤外線トランシーバ、ブルートゥース（登録商標）・トランシーバ、ＷｉＭａｘトランシーバ、無線セルラー電話トランシーバ、衛星トランシーバ（たとえば全地球測位システム（ＧＰＳ）トランシーバ）、もしくは他の無線周波数（ＲＦ）トランシーバ、またはこれらの組合せでよい。ＮＩＣはイーサネット（登録商標）カードでよい。

入力デバイス１５０６は、マウス、タッチパッド、タッチセンシティブ・スクリーン（表示デバイス１５０４に組み込まれ得る）、スタイラスなどのポインタデバイス、および／またはキーボード（たとえば物理的キーボードまたはタッチセンシティブ・スクリーンの一部分として表示されたバーチャル・キーボード）を含み得る。たとえば、入力デバイス１５０６はタッチスクリーンに結合されたタッチスクリーン・コントローラを含み得る。タッチスクリーンおよびタッチスクリーン・コントローラは、たとえば、それだけではないが、容量技術、抵抗技術、赤外線技術、表面弾性波技術、ならびに他の近接センサ配列またはタッチスクリーンに対する１または複数の接触点を判定するための他の要素を含む複数のタッチ感知技術のうち任意のものを使用して、接触と、動きまたは動きの中断とを検知する。

ＩＯデバイス１５０７はオーディオ・デバイスを含み得る。オーディオ・デバイスは、音声認識、音声応答、デジタル記録、および／または電話の機能など、音声対応の機能を促進するためのスピーカおよび／またはマイクロフォンを含み得る。他のＩＯデバイス１５０７は、ユニバーサル・シリアル・バス（ＵＳＢ）ポート、パラレルポート、シリアルポート、プリンタ、ネットワーク・インターフェース、バスブリッジ（たとえばＰＣＩ－ＰＣＩブリッジ）、センサ（たとえば加速度計、ジャイロスコープ、磁力計、光センサ、コンパス、近接センサなどの運動センサ）またはこれらの組合せをさらに含み得る。デバイス１５０７がさらに含み得る画像処理サブシステム（たとえばカメラ）は、写真およびビデオクリップの記録などのカメラ機能を促進するために利用される電荷結合デバイス（ＣＣＤ）または相補型金属酸化膜半導体（ＣＭＯＳ）光センサなどの光センサを含み得る。特定のセンサがセンサ・ハブ（図示せず）を介して相互接続１５１０に結合されてよく、一方、キーボードまたは熱センサなど他のデバイスは、システム１５００の特定の構成または設計に依拠して、組み込みコントローラ（図示せず）によって制御され得る。

データ、アプリケーション、１または複数のオペレーティングシステムなどの情報の持続的記憶を提供するために、プロセッサ１５０１には大容量記憶装置（図示せず）も結合され得る。様々な実施形態において、より薄くより軽いシステム設計を可能にするばかりでなくシステム応答性も改善するために、この大容量記憶装置はソリッドステート・デバイス（ＳＳＤ）によって実施されてよい。しかしながら、他の実施形態では、大容量記憶装置は、停電中にコンテキスト状態および他のそのような情報の不揮発性記憶装置を有効にするために、主として、ＳＳＤキャッシュとして働く少量のＳＳＤ記憶装置を伴うハードディスク・ドライブ（ＨＤＤ）を使用して実施されてよく、その結果、システム・アクティビティの再起動において高速のパワーアップが可能になる。また、フラッシュメモリが、たとえばシリアル周辺インターフェース（ＳＰＩ）を介してプロセッサ１５０１に結合されてよい。このフラッシュメモリは、ＢＩＯＳならびにシステムの他のファームウェアを含むシステム・ソフトウェアの不揮発性記憶装置をもたらし得る。

記憶デバイス１５０８が含み得るコンピュータ・アクセス可能な記憶媒体１５０９（マシン可読記憶媒体またはコンピュータ可読媒体としても知られている）には、本明細書で説明された技法または機能のうち任意の１または複数を具現する１または複数の命令のセットまたはソフトウェア（たとえばモジュール、ユニット、および／またはロジック１５２８）が記憶されている。処理モジュール／ユニット／ロジック１５２８は、たとえばＡＳＴジェネレータ２１０、ＡＳＴパーサ２２０、検証コード・ジェネレータ２３０、および検証スタブ・ジェネレータ２４０など、上記で説明されたコンポーネントのうち任意のものを表し得る。処理モジュール／ユニット／ロジック１５２８は、データ処理システム１５００による実行中には、メモリ１５０３の内部および／またはプロセッサ１５０１の内部に、余すところなく、または少なくとも部分的に存在してもよく、メモリ１５０３およびプロセッサ１５０１はマシンアクセス可能な記憶媒体も構成する。処理モジュール／ユニット／ロジック１５２８は、ネットワーク・インターフェース・デバイス１５０５によってネットワークを通じてさらに送信／受信されてよい。

コンピュータ可読記憶媒体１５０９は、上記で説明されたいくつかのソフトウェア機能を持続的に記憶するためにも使用され得る。例示的実施形態では、コンピュータ可読記憶媒体１５０９は単一の媒体であるように示されているが、「コンピュータ可読記憶媒体」という用語は、命令の１または複数のセットを記憶する単一の媒体または複数の媒体（たとえば集中型もしくは分散型のデータベース、および／または関連するキャッシュおよびサーバ）を含むように解釈されるべきである。「コンピュータ可読記憶媒体」という用語は、マシンによる実行のための命令のセットを記憶することまたは符号化することが可能であって本開示の技法のうち任意の１または複数をマシンに遂行させる任意の媒体を含むようにも解釈されるべきである。したがって、「コンピュータ可読記憶媒体」という用語は、それだけではないが、ソリッドステート・メモリならびに光媒体および磁気媒体、または何らかの他の非一時的マシン可読媒体を含むように解釈されるべきである。

処理モジュール／ユニット／ロジック１５２８、構成要素および本明細書で説明された他の機能は、個別のハードウェア構成要素として実施され得、またはＡＳＩＣ、ＦＰＧＡ、ＤＳＰまたは類似のデバイスなどハードウェア構成要素の機能の中に組み込まれ得る。加えて、処理モジュール／ユニット／ロジック１５２８は、ハードウェアデバイスの内部のファームウェアまたは機能回路として実施され得る。さらに、処理モジュール／ユニット／ロジック１５２８は、ハードウェアデバイスとソフトウェア・コンポーネントの任意の組合せで実施され得る。

システム１５００は、データ処理システムの様々な構成要素を用いて示されているが、何らかの特定のアーキテクチャまたは構成要素を相互に連結するやり方を表すことは意図されておらず、そのため、詳細は、本開示の実施形態に密接な関係はないことに留意されたい。ネットワークコンピュータ、ハンドヘルドコンピュータ、携帯電話、サーバ、および／または構成要素がより少ないかもしくは恐らくより多い他のデータ処理システムも、本開示の実施形態とともに使用され得ることも理解されたい。

先の詳細な説明のいくつかの部分は、コンピュータ記憶装置の内部のデータ・ビットにおける動作のアルゴリズムおよび記号表現の観点から提示されている。これらのアルゴリズム的な説明および表現は、データ処理技術の当業者が、著作物の要旨を他の当業者に最も効果的に伝えるために使用するやり方である。ここで、アルゴリズムは、一般に、所望の結果に達する動作の自己矛盾がないシーケンスと考えられる。動作は、物理量の物理的操作を必要とするものである。

しかしながら、これらおよび類似の用語のすべてが、適切な物理量に関連づけられるべきであり、これらの量に与えられた好都合なラベルでしかないことを念頭に置かれたい。特に別記しない限り、上記の議論から明らかなように、説明の全体にわたって、以下の特許請求の範囲において説明されるものなどの用語を利用する議論は、コンピュータシステムのレジスタおよびメモリの内部の物理的（電子的）量として表されたデータを操作して、コンピュータシステムのメモリもしくはレジスタ、または他のそのような情報の記憶デバイス、伝送デバイスもしくは表示デバイスの内部の物理量として同様に表される他のデータへと変換するコンピュータシステム（または類似の電子計算デバイス）の作用および処理を指すことが理解される。

本開示の実施形態は、本明細書における動作を遂行するための装置にも関する。そのようなコンピュータプログラムは非一時的コンピュータ可読媒体に記憶されている。マシン可読媒体は、マシン（たとえばコンピュータ）に可読の形態で情報を記憶するための任意の機構を含む。たとえば、マシン可読（たとえばコンピュータ可読）媒体は、マシン（たとえばコンピュータ）可読記憶媒体（たとえば読み取り専用メモリ（「ＲＯＭ」）、ランダムアクセスメモリ（「ＲＡＭ」）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ素子）を含む。

先の図に表された処理または方法は、ハードウェア（たとえば回路、専用ロジックなど）、（たとえば非一時的コンピュータ可読媒体上に具現された）ソフトウェア、またはこれらの組合せを含む処理ロジックによって遂行され得る。上記では、処理または方法がいくつかの順次動作の観点から説明されているが、説明された動作のうちいくつかは異なる順序で遂行され得ることを理解されたい。その上に、いくつかの動作は、順次ではなく並行して遂行され得る。

本開示の実施形態は、何らかの特定のプログラム言語を基準として説明されているわけではない。本明細書で説明されたような本開示の実施形態の教示を実施するために、種々のプログラム言語が使用され得ることが理解されよう。

前述の明細書では、本開示の実施形態が特定の例示的実施形態を参照しながら説明されている。以下の特許請求の範囲で説明されるような本開示のより広範な精神および範囲から逸脱することなく、様々な修正形態が作製され得ることが明白であろう。したがって、本明細書および図面は、限定的意味ではなく例示的意味に見なされるべきである。

Claims (20)

1. データ通信のためにプロトコル・バッファ（Ｐｒｏｔｏｂｕｆ）を使用するアプリケーションの検証において、検証の代用ヘッダファイルを使用するためのコンピュータで実装される方法であって、
   Ｐｒｏｔｏｂｕｆ仕様による１または複数の関数の第１のセットを定義するＰｒｏｔｏｂｕｆ定義ファイルから１または複数のＰｒｏｔｏｂｕｆメッセージタイプを得るステップであって、前記第１のセットの前記関数がＰｒｏｔｏｂｕｆライブラリのセットを呼び出すステップと、
   前記Ｐｒｏｔｏｂｕｆメッセージタイプに基づいて前記検証の代用ヘッダファイルを生成するステップであって、該検証の代用ヘッダファイルが、標準Ｃ／Ｃ＋＋プログラム言語による１または複数の関数の第２のセットを定義し、前記第２のセットの前記関数が標準Ｃ／Ｃ＋＋ライブラリのセットを呼び出すステップと、
   前記検証の代用ヘッダファイルに１または複数の検証スタブを挿入するステップと、
   前記標準Ｃ／Ｃ＋＋ライブラリのセットに基づいて、前記Ｐｒｏｔｏｂｕｆライブラリのセットの検証を必要とすることなく、前記検証の代用ヘッダファイルを含むアプリケーションの検証を遂行するステップと、
   を含む方法。
2. 前記Ｐｒｏｔｏｂｕｆ定義ファイルから前記１または複数のＰｒｏｔｏｂｕｆメッセージタイプを得るステップが、前記Ｐｒｏｔｏｂｕｆ定義ファイルに基づいて抽象構文ツリー（ＡＳＴ）を生成するステップと、前記ＡＳＴを解析するステップと、を含む請求項１に記載の方法。
3. 各Ｐｒｏｔｏｂｕｆメッセージタイプについて、前記検証の代用ヘッダファイルの中にＣ＋＋クラスが生成され、対応するＰｒｏｔｏｂｕｆメッセージタイプの各フィールドについて、前記Ｃ＋＋クラスの中に１つのメンバ・フィールドおよび対応するメンバ関数が生成される請求項１に記載の方法。
4. Ｃ／Ｃ＋＋クラスの１または複数のオブジェクトの生成、アクセス、または削除のための、前記検証の代用ヘッダファイルを含む前記アプリケーションの前記検証が、前記標準Ｃ／Ｃ＋＋ライブラリに依存する請求項３に記載の方法。
5. 前記検証スタブが、前記メンバ関数に関連した１または複数の事前条件、前記メンバ関数に関連した１または複数の事後条件、またはこれらの組合せを含む請求項３に記載の方法。
6. 前記１または複数の事前条件ならびに／あるいは前記１または複数の事後条件がカスタマイズ可能である請求項５に記載の方法。
7. 前記Ｐｒｏｔｏｂｕｆメッセージタイプが前記Ｐｒｏｔｏｂｕｆ定義ファイルの中で定義される請求項１に記載の方法。
8. 命令を記憶した非一時的マシン可読媒体であって、前記命令がプロセッサによって実行されたとき、該プロセッサが、データ通信のためにプロトコル・バッファ（Ｐｒｏｔｏｂｕｆ）を使用するアプリケーションの検証において、検証の代用ヘッダファイルを使用する動作を遂行し、該動作が、
   Ｐｒｏｔｏｂｕｆ仕様による１または複数の関数の第１のセットを定義するＰｒｏｔｏｂｕｆ定義ファイルから１または複数のＰｒｏｔｏｂｕｆメッセージタイプを得るステップであって、前記第１のセットの前記関数がＰｒｏｔｏｂｕｆライブラリのセットを呼び出す、１または複数のＰｒｏｔｏｂｕｆメッセージタイプを得るステップと、
   前記Ｐｒｏｔｏｂｕｆメッセージタイプに基づいて前記検証の代用ヘッダファイルを生成するステップであって、該検証の代用ヘッダファイルが、標準Ｃ／Ｃ＋＋プログラム言語による１または複数の関数の第２のセットを定義し、前記第２のセットの前記関数が標準Ｃ／Ｃ＋＋ライブラリのセットを呼び出す、前記検証の代用ヘッダファイルを生成するステップと、
   前記検証の代用ヘッダファイルに１または複数の検証スタブを挿入するステップと、
   前記標準Ｃ／Ｃ＋＋ライブラリのセットに基づいて、前記Ｐｒｏｔｏｂｕｆライブラリのセットの検証を必要とすることなく、前記検証の代用ヘッダファイルを含むアプリケーションの検証を遂行するステップとを含む非一時的マシン可読媒体。
9. 前記Ｐｒｏｔｏｂｕｆ定義ファイルから前記１または複数のＰｒｏｔｏｂｕｆメッセージタイプを得るステップが、前記Ｐｒｏｔｏｂｕｆ定義ファイルに基づいて抽象構文ツリー（ＡＳＴ）を生成するステップと、前記ＡＳＴを解析するステップと、を含む請求項８に記載の非一時的マシン可読媒体。
10. 各Ｐｒｏｔｏｂｕｆメッセージタイプについて、前記検証の代用ヘッダファイルの中にＣ＋＋クラスが生成され、対応するＰｒｏｔｏｂｕｆメッセージタイプの各フィールドについて、前記Ｃ＋＋クラスの中に１つのメンバ・フィールドおよび対応するメンバ関数が生成される、請求項８に記載の非一時的マシン可読媒体。
11. Ｃ／Ｃ＋＋クラスの１または複数のオブジェクトの生成、アクセス、または削除のための、前記検証の代用ヘッダファイルを含む前記アプリケーションの前記検証が、前記標準Ｃ／Ｃ＋＋ライブラリに依存する請求項１０に記載の非一時的マシン可読媒体。
12. 前記検証スタブが、前記メンバ関数に関連した１または複数の事前条件、前記メンバ関数に関連した１または複数の事後条件、またはこれらの組合せを含む請求項１０に記載の非一時的マシン可読媒体。
13. 前記１または複数の事前条件ならびに／あるいは前記１または複数の事後条件がカスタマイズ可能である請求項１２に記載の非一時的マシン可読媒体。
14. 前記Ｐｒｏｔｏｂｕｆメッセージタイプが前記Ｐｒｏｔｏｂｕｆ定義ファイルの中で定義される請求項８に記載の非一時的マシン可読媒体。
15. プロセッサと、命令を記憶するように該プロセッサに結合されたメモリとを備えるデータ処理システムであって、前記命令が前記プロセッサによって実行されたとき、前記プロセッサが、データ通信のためにプロトコル・バッファ（Ｐｒｏｔｏｂｕｆ）を使用するアプリケーションの検証において検証の代用ヘッダファイルを使用するための動作を遂行し、該動作が、
    Ｐｒｏｔｏｂｕｆ仕様による１または複数の関数の第１のセットを定義するＰｒｏｔｏｂｕｆ定義ファイルから１または複数のＰｒｏｔｏｂｕｆメッセージタイプを得るステップであって、前記第１のセットの前記関数がＰｒｏｔｏｂｕｆライブラリのセットを呼び出す、１または複数のＰｒｏｔｏｂｕｆメッセージタイプを得るステップと、
    前記Ｐｒｏｔｏｂｕｆメッセージタイプに基づいて前記検証の代用ヘッダファイルを生成するステップであって、該検証の代用ヘッダファイルが、標準Ｃ／Ｃ＋＋プログラム言語による１または複数の関数の第２のセットを定義し、前記第２のセットの前記関数が、標準Ｃ／Ｃ＋＋ライブラリのセットを呼び出すステップと、
    前記検証の代用ヘッダファイルに１または複数の検証スタブを挿入するステップと、
    前記標準Ｃ／Ｃ＋＋ライブラリのセットに基づいて、前記Ｐｒｏｔｏｂｕｆライブラリのセットの検証を必要とすることなく、前記検証の代用ヘッダファイルを含むアプリケーションの検証を遂行するステップと、
    を含むデータ処理システム。
16. 前記Ｐｒｏｔｏｂｕｆ定義ファイルから前記１または複数のＰｒｏｔｏｂｕｆメッセージタイプを得るステップが、前記Ｐｒｏｔｏｂｕｆ定義ファイルに基づいて抽象構文ツリー（ＡＳＴ）を生成するステップと、前記ＡＳＴを解析するステップと、を含む請求項１５に記載のシステム。
17. 各Ｐｒｏｔｏｂｕｆメッセージタイプについて、前記検証の代用ヘッダファイルの中にＣ＋＋クラスが生成され、対応するＰｒｏｔｏｂｕｆメッセージタイプの各フィールドについて、前記Ｃ＋＋クラスの中に１つのメンバ・フィールドおよび対応するメンバ関数が生成される請求項１５に記載のシステム。
18. Ｃ／Ｃ＋＋クラスの１または複数のオブジェクトの生成、アクセス、または削除のための、前記検証の代用ヘッダファイルを含む前記アプリケーションの前記検証が、前記標準Ｃ／Ｃ＋＋ライブラリに依存する、請求項１７に記載のシステム。
19. 前記検証スタブが、前記メンバ関数に関連した１または複数の事前条件、前記メンバ関数に関連した１または複数の事後条件、またはこれらの組合せを含む請求項１７に記載のシステム。
20. 前記１または複数の事前条件ならびに／あるいは前記１または複数の事後条件がカスタマイズ可能である請求項１９に記載のシステム。

Images