(57)【要約】【課題】  従来のＡＰＩ学習曲線および／または少なくとも退行的連続性ギャップを改善することができ、および／またはより良好な全ＡＰＩユーザビリティを達成することができるスキームおよび／または技法を提供すること。【解決手段】  アプリケーションプログラミングインターフェース（ＡＰＩ）を設計する第１の例示的方法は、コアシナリオに関する複数のコードサンプルを準備するステップであって、その複数のコードサンプルの各コードサンプルは複数のプログラミング言語の各プログラミング言語にそれぞれ対応するステップと、その複数のコードサンプルに応答して、コアシナリオからＡＰＩを導出するステップとを含む。【選択図】  図４
2005129027.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションプログラミングインターフェース（ＡＰＩ）を設計する方法であって、
コアシナリオに関する複数のコードサンプルを準備するステップであって、前記複数のコードサンプルの各コードサンプルは複数のプログラミング言語の各プログラミング言語にそれぞれ対応するステップと、
前記複数のコードサンプルに応答して、前記コアシナリオから前記ＡＰＩを導出するステップと
を含むことを特徴とする方法。
【請求項２】
ＡＰＩ設計者により、導出した前記ＡＰＩが複雑すぎるか否かを判定するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
導出した前記ＡＰＩが複雑すぎると判定した場合、
前記ＡＰＩ設計者により、導出した前記ＡＰＩを改良し、改良後ＡＰＩを生成するステップをさらに含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記ＡＰＩ設計者により、前記改良後ＡＰＩが複雑すぎるか否かを判定するステップをさらに含むことを特徴とする請求項３に記載の方法。
【請求項５】
複数の開発者を使用して、前記ＡＰＩに関する１つまたは複数のユーザビリティスタディを実行するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記実行するステップは、
前記複数の開発者を使用して、前記ＡＰＩについての前記１つまたは複数のユーザビリティスタディを実行するステップであって、前記複数の開発者は、前記複数のプログラミング言語に関して典型的であるステップを含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記複数の開発者が大きな問題なく前記ＡＰＩを使用することができるか否かを確認するステップをさらに含むことを特徴とする請求項５に記載の方法。
【請求項８】
前記複数の開発者が大きな問題なく前記ＡＰＩを使用することができると確認されなかった場合、前記ＡＰＩを修正するステップをさらに含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記修正するステップは、
前記１つまたは複数のユーザビリティスタディからの少なくとも１つの教訓に基づいて前記ＡＰＩを修正するステップを含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記導出するステップは、
前記複数のプログラミング言語にそれぞれ対応する前記複数のコードサンプルをサポートするように前記ＡＰＩを導出するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
前記導出するステップは、
前記複数のコードサンプルから言語特有の命令を集めるステップと、
前記言語特有の命令を前記ＡＰＩに組み込むステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項１２】
前記導出するステップは、
前記複数のコードサンプルから、言語に触発された開発者の予想を集めるステップと、
前記言語に触発された開発者の予想を前記ＡＰＩに組み込むステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項１３】
前記導出するステップは、
前記複数のコードサンプルから共通点を集めるステップと、
前記共通点を前記ＡＰＩに組み込むステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項１４】
前記導出するステップは、
前記コアシナリオをサポートするために複数の低レベルファクタードタイプを互いに結合する集合コンポーネントを有するように前記ＡＰＩを導出するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１５】
アプリケーションプログラミングインターフェース（ＡＰＩ）を設計する方法であって、
機能エリアに関するコアシナリオを選択するステップと、
前記コアシナリオに関する少なくとも１つのコードサンプルを書き込むステップと、
前記少なくとも１つのコードサンプルに応答して、前記コアシナリオに関するＡＰＩを導出するステップと
を含むことを特徴とする方法。
【請求項１６】
前記選択するステップは、
前記機能エリアに関する複数のコアシナリオを選択するステップを含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記機能エリアに関して選択した前記複数のコアシナリオの各コアシナリオについて、前記書き込むステップおよび前記導出するステップを反復するステップをさらに含むことを特徴とする請求項１６に記載の方法。
【請求項１８】
前記書き込むステップは、
前記コアシナリオに関する複数のコードサンプルを書き込むステップであって、前記複数のコードサンプルの各コードサンプルは、複数のプログラミング言語の各プログラミング言語にそれぞれ対応するステップを含むことを特徴とする請求項１５に記載の方法。
【請求項１９】
前記導出するステップは、
前記複数のコードサンプルに応答して前記コアシナリオに関する前記ＡＰＩを導出するステップを含むことを特徴とする請求項１８に記載の方法。
【請求項２０】
複数の開発者を使用して、前記ＡＰＩに関する１つまたは複数のユーザビリティスタディを実行するステップと、
前記複数の開発者が大きな問題なく前記ＡＰＩを使用することができるか否かを確認するステップと、
前記複数の開発者が大きな問題なく前記ＡＰＩを使用することができると確認されなかった場合、前記ＡＰＩを修正するステップと
をさらに含むことを特徴とする請求項１５に記載の方法。
【請求項２１】
前記修正するステップは、
前記１つまたは複数のユーザビリティスタディからの少なくとも１つの教訓に基づいて前記ＡＰＩを修正し、修正後ＡＰＩを生成するステップを含むことを特徴とする請求項２０に記載の方法。
【請求項２２】
前記修正後ＡＰＩに関して前記実行するステップおよび前記確認するステップを反復するステップをさらに含むことを特徴とする請求項２１に記載の方法。
【請求項２３】
前記導出するステップは、
集合コンポーネントおよび下にある複数のファクタードタイプを含む２層ＡＰＩを生成することにより、前記コアシナリオのために書かれた前記少なくとも１つのコードサンプルをサポートするように前記ＡＰＩを導出するステップを含むことを特徴とする請求項１５に記載の方法。
【請求項２４】
前記導出するステップは、
前記少なくとも１つのコードサンプルから１つまたは複数の言語特有の命令を集めるステップと、
前記１つまたは複数の言語特有の命令を前記ＡＰＩに組み込むステップと
を含むことを特徴とする請求項１５に記載の方法。
【請求項２５】
前記導出するステップは、
前記特定のファクタードタイプのすべてのメンバが前記集合コンポーネントによって公開される場合、前記コアシナリオに関連する集合コンポーネント内に特定のファクタードタイプをカプセル化するステップを含むことを特徴とする請求項１５に記載の方法。
【請求項２６】
前記導出するステップは、
前記特定のファクタードタイプが他のコンポーネントタイプにとって無関係である場合、前記コアシナリオに関連する集合コンポーネント内に特定のファクタードタイプをカプセル化するステップを含むことを特徴とする請求項１５に記載の方法。
【請求項２７】
前記導出するステップは、
前記特定のファクタードタイプの少なくとも１つのメンバが前記集合コンポーネントによって公開されない場合、前記コアシナリオに関連する集合コンポーネントから特定のファクタードタイプを公開するステップを含むことを特徴とする請求項１５に記載の方法。
【請求項２８】
前記導出するステップは、
前記集合コンポーネントとは無関係に前記特定のファクタードタイプを別のコンポーネントタイプによって有益に使用することができる場合、前記コアシナリオに関連する集合コンポーネントから特定のファクタードタイプを公開するステップを含むことを特徴とする請求項１５に記載の方法。
【請求項２９】
前記導出するステップは、
相対的に高レベルのアブストラクションを対象とするコンポーネントタイプと、相対的に低レベルのアブストラクションを対象とするコンポーネントタイプとを含む２層フレームワークを生成するステップを含むことを特徴とする請求項１５に記載の方法。
【請求項３０】
前記相対的に高レベルのアブストラクションを対象とする前記コンポーネントタイプが、コアシナリオに向けられることを特徴とする請求項２９に記載の方法。
【請求項３１】
前記相対的に低レベルのアブストラクションを対象とする前記コンポーネントタイプが、前記相対的に高レベルのアブストラクションを対象とする前記コンポーネントタイプと比較して、高い制御量を開発者に対して提供することを特徴とする請求項２９に記載の方法。
【請求項３２】
前記導出するステップは、
開発者が前記コアシナリオに対してｃｒｅａｔｅ−ｓｅｔ−ｃａｌｌ使用パターンを実装することが可能となるように前記ＡＰＩを導出するステップを含むことを特徴とする請求項１５に記載の方法。
【請求項３３】
前記導出するステップは、
前記コアシナリオに対して適切な事前選択パラメータと共に前記ＡＰＩを生成するステップを含むことを特徴とする請求項３２に記載の方法。
【請求項３４】
アプリケーションプログラミングインターフェース（ＡＰＩ）を設計する方法であって、
前記シナリオに関して書かれた少なくとも１つのコードサンプルに応答して、シナリオに関するＡＰＩを導出するステップと、
複数の開発者を使用して、前記ＡＰＩに関する１つまたは複数のユーザビリティスタディを実行するステップと、
前記１つまたは複数のユーザビリティスタディに基づいて前記ＡＰＩを修正するステップと
を含むことを特徴とする方法。
【請求項３５】
前記シナリオに関する複数のコードサンプルを書き込むステップであって、前記複数のコードサンプルの各コードサンプルが複数のプログラミング言語の各プログラミング言語にそれぞれ対応するステップをさらに含み、
前記導出するステップは、
前記複数のコードサンプルに応答して、前記シナリオに関するＡＰＩを導出するステップを含むことを特徴とする請求項３４に記載の方法。
【請求項３６】
前記ＡＰＩに関する１つまたは複数のユーザビリティスタディを実行するステップに先立って、
前記導出したＡＰＩが複雑すぎるか否かをＡＰＩ設計者によって判定するステップと、
前記導出したＡＰＩが複雑すぎる場合、前記導出したＡＰＩを前記ＡＰＩ設計者によって修正し、修正後ＡＰＩを生成するステップと、
前記修正後ＡＰＩが複雑すぎるか否かを前記ＡＰＩ設計者によって判定するステップと
をさらに含むことを特徴とする請求項３４に記載の方法。
【請求項３７】
前記複数の開発者が大きな問題なく前記ＡＰＩを使用することができるか否かを確認するステップと、
前記複数の開発者が大きな問題なく前記ＡＰＩを使用することができると確認されなかった場合、前記修正するステップを実行するステップとをさらに含み、
前記修正するステップは、
前記１つまたは複数のユーザビリティスタディからの少なくとも１つの教訓に基づいて前記ＡＰＩを修正し、修正後を生成するステップを含むことを特徴とする請求項３４に記載の方法。
【請求項３８】
前記修正後ＡＰＩに関して、少なくとも前記実行するステップおよび前記確認するステップを反復するステップをさらに含むことを特徴とする請求項３７に記載の方法。
【請求項３９】
前記確認するステップは、
前記複数の開発者が、少なくとも１つの対象とする開発者グループについての所望のレベルのユーザビリティに関して、大きな問題なく前記ＡＰＩを使用することができるか否かを確認するステップを含み、前記所望のレベルのユーザビリティは、（ｉ）前記複数の開発者による詳細なＡＰＩドキュメントへの頻繁および／または広範にわたる参照、（ｉｉ）前記複数の開発者の大多数が前記シナリオを実装することに失敗すること、および（ｉｉｉ）前記複数の開発者が、ＡＰＩ設計者の予想する手法とはかなり異なる手法を取るか否かに関する考慮すべき点を含むことを特徴とする請求項３７に記載の方法。
【請求項４０】
機能エリアに関する複数のコアシナリオを選択するステップと、
前記複数のコアシナリオの各コアシナリオについて、前記導出するステップ、前記実行するステップ、および前記修正するステップを反復するステップをさらに含むことを特徴とする請求項３４に記載の方法。
【請求項４１】
前記導出するステップは、
前記複数のコアシナリオの各コアシナリオについて、集合コンポーネントを生成するステップを含むことを特徴とする請求項４０に記載の方法。
【請求項４２】
前記導出するステップは、
複数のファクタードタイプの各ファクタードタイプとの関係をそれぞれ有する集合コンポーネントを生成するステップを含むことを特徴とする請求項３４に記載の方法。
【請求項４３】
前記生成するステップは、
前記少なくとも１つのコードサンプルがそれに関して書かれる前記シナリオをサポートするように前記集合コンポーネントを生成するステップを含むことを特徴とする請求項４２に記載の方法。
【請求項４４】
前記生成するステップは、
前記複数のファクタードタイプの少なくとも１つのファクタードタイプとの間で公開された関係を有し、前記複数のファクタードタイプの少なくとも１つの他のファクタードタイプとの間でカプセル化された関係を有するように前記集合コンポーネントを生成するステップを含むことを特徴とする請求項４２に記載の方法。
【請求項４５】
前記集合コンポーネントとの間で前記カプセル化された関係を有する前記複数のファクタードタイプの前記少なくとも１つの他のファクタードタイプを、別のコンポーネントタイプとの直接対話のために前記集合コンポーネントによって渡すことができることを特徴とする請求項４４に記載の方法。
【請求項４６】
前記複数のファクタードタイプが、オブジェクト指向方法を使用して設計されることを特徴とする請求項４２に記載の方法。
【請求項４７】
アプリケーションプログラミングインターフェース（ＡＰＩ）を設計する方法であって、
コアシナリオに関する複数のコードサンプルを準備するステップであって、前記複数のコードサンプルの各コードサンプルは複数のプログラミング言語の各プログラミング言語にそれぞれ対応するステップと、
前記複数のコードサンプルに応答して、前記コアシナリオに関する前記ＡＰＩを導出するステップと、
複数の開発者を使用して、前記ＡＰＩに関する１つまたは複数のユーザビリティスタディを実行するステップと、
前記１つまたは複数のユーザビリティスタディに基づいて前記ＡＰＩを修正するステップと
を含むことを特徴とする方法。
【請求項４８】
アプリケーションプログラミングインターフェース（ＡＰＩ）を設計する方法であって、
コアシナリオに関する少なくとも１つのコードサンプルを書き込むステップと、
前記少なくとも１つのコードサンプルに応答して前記シナリオに関するＡＰＩを導出するステップであって、前記ＡＰＩは、（ｉ）前記シナリオの実装を実行するように適合された集合コンポーネントと、（ｉｉ）下にある前記集合コンポーネントに関する機能を提供する複数のファクタードタイプとを含み、前記ＡＰＩは、より単純な状況で前記集合コンポーネントを使用することから、だんだん複雑な状況で前記複数のファクタードタイプの増加部分を使用することまでの段階的進歩を可能にするステップと
を含むことを特徴とする方法。
【請求項４９】
アプリケーションプログラミングインターフェース（ＡＰＩ）を設計する方法であって、
少なくとも１つのシナリオに関する少なくとも１つのコードサンプルをサポートするように少なくとも１つの集合コンポーネントを導出するステップと、
前記少なくとも１つのシナリオに関する追加要件を求めるステップと、
過度の複雑さを加えることなく前記追加要件を前記少なくとも１つの集合コンポーネントに加えることができるか否かを判定するステップと、
過度の複雑さを加えることなく前記追加要件を前記少なくとも１つの集合コンポーネントに加えることができない場合、前記判定に応答して複数のファクタードタイプを定義するステップと
を含むことを特徴とする方法。
【請求項５０】
過度の複雑さを加えることなく前記追加要件を前記少なくとも１つの集合コンポーネントに加えることができる場合、前記少なくとも１つの集合コンポーネントを改良して、前記追加の要件を組み込むステップをさらに含むことを特徴とする請求項４９に記載の方法。
【請求項５１】
機能エリアに関する複数のコアシナリオを選択するステップであって、前記複数のコアシナリオは、前記少なくとも１つのシナリオを含むステップと、
前記複数のコアシナリオに関する好ましいコード行を示す複数のコードサンプルを書き込むステップであって、前記複数のコードサンプルは、前記少なくとも１つのコードサンプルを含むステップと
をさらに含み、前記導出するステップは、
前記複数のコアシナリオに関する前記複数のコードサンプルをサポートするように、前記少なくとも１つの集合コンポーネントを含む複数の集合コンポーネントを導出するステップを含むことを特徴とする請求項４９に記載の方法。
【請求項５２】
前記導出するステップは、
前記少なくとも１つのシナリオに関する前記少なくとも１つのコードサンプルをサポートするように、適切なメソッド、デフォルト、およびアブストラクションを用いて前記少なくとも１つの集合コンポーネントを導出するステップを含むことを特徴とする請求項４９に記載の方法。
【請求項５３】
導出した前記少なくとも１つの集合コンポーネントに従って前記少なくとも１つのコードサンプルを改良するステップと、
単純さに関して、改良した前記少なくとも１つのコードサンプルを評価するステップと、
前記評価するステップにおいて、改良した前記少なくとも１つのコードサンプルが十分に単純ではない場合、前記導出するステップを反復するステップと
をさらに含むことを特徴とする請求項４９に記載の方法。
【請求項５４】
前記求めるステップは、
前記少なくとも１つのシナリオに関する追加要件を求めるステップであって、前記追加要件は、追加のシナリオ、追加の使用法、および他のコンポーネントタイプとの追加の対話を含むステップを含むことを特徴とする請求項４９に記載の方法。
【請求項５５】
前記判定するステップは、
前記少なくとも１つの集合コンポーネントへの前記追加要件の追加がｃｒｅａｔｅ−ｓｅｔ−ｃａｌｌ使用パターンの妨げとなるか否かを考慮するステップを含むことを特徴とする請求項４９に記載の方法。
【請求項５６】
前記定義するステップは、
前記判定するステップに応答して、機能のフルセットの理想的なファクタリングを用いて前記複数のファクタードタイプを定義するステップを含むことを特徴とする請求項４９に記載の方法。
【請求項５７】
前記定義するステップは、
前記判定するステップに応答して、１つまたは複数のオブジェクト指向方法を使用して前記複数のファクタードタイプを定義するステップを含むことを特徴とする請求項４９に記載の方法。
【請求項５８】
前記少なくとも１つの集合コンポーネントが、前記複数のファクタードタイプの各ファクタードタイプの前記機能をカプセル化すべきか、それとも公開すべきかを判定するステップをさらに含むことを特徴とする請求項４９に記載の方法。
【請求項５９】
前記少なくとも１つの集合コンポーネントおよび前記追加要件をサポートするように前記複数のファクタードタイプを改良するステップをさらに含むことを特徴とする請求項４９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般にはアプリケーションプログラミングインターフェース（ＡＰＩ）に関し、詳細には、限定はしないが、例えば、使用するのが容易であると共に、制御と柔軟性を同時に実現するＡＰＩを設計することに関する。
【背景技術】
【０００２】
アプリケーションプログラミングインターフェース（ＡＰＩ）は、開発者が多種多様なアプリケーションおよびプログラムを作成するのに使用される。開発者は、マクロを記録するオフィスワーカーから、低レベルデバイスドライバの作者まで多岐にわたる。こうした開発者は、様々な複雑さの様々な言語および／または様々なフレームワークを利用すると共に、様々なスキルセットおよび／または様々な目的でプログラミングする。従来より、様々な個人のスキルレベルおよび（例えば、様々な関連するシナリオに基づく）制御に対する様々な要求を対象とするように、様々なＡＰＩが設計されてきた。
【０００３】
この手法は特定の開発者向けに最適化されたＡＰＩを提供する際にはうまく行くが、この手法には重大な欠点がある。例えば、複数フレームワークの手法は、あるスキルレベルおよびシナリオタイプから別のスキルレベルおよびシナリオタイプに開発者が知識を移送することが困難な状況を生み出す。様々なフレームワークを使用してシナリオを実装する必要がある場合、開発者は非常に急な学習曲線に直面する。また、学習曲線が非常に急であるだけでなく、一般には第１の低スキルレベルフレームワーク向けに書かれたコードを第２の高スキルレベルフレームワーク向けに最初から書き直さなければならない。さらに、様々な開発者スキルレベル向けに別々のフレームワークを作成する結果として、あるレベルの開発者を対象とし、またはそのレベルの開発者によって実装されたＡＰＩが、別のレベルの開発者には使用不能となる状況が生じる。
【０００４】
図１に、２つの異なるフレームワークに関する従来のＡＰＩ学習曲線のグラフ１０１を示す。第１フレームワークは、必要なスキルおよび／または難易度のレベルが比較的低く、それに付随して開発者による制御に関する能力が比較的低いフレームワークに対応する。一方、第２フレームワークは、必要なスキルおよび／または難易度のレベルが比較的高く、それに付随して開発者による制御に関する能力が比較的高いフレームワークに対応する。このような第１フレームワークは、経験の浅い開発者または頻繁には開発しない開発者によって使用され、このような第２フレームワークは、経験のある開発者または専門職の開発者によって使用される。例えば、第１フレームワークは、Ｖｉｓｕａｌ  Ｂａｓｉｃ向けに設計されたフレームワークに対応し、第２フレームワークはＣ＋＋向けに設計されたフレームワークに対応する。
【０００５】
この従来の手法では、比較的別々の、本質的に異なるＡＰＩが設計され、各フレームワークの一部として利用される。比較的低いスキルレベルおよび制御能力で第１フレームワークに関するＡＰＩを使用することを可能にするために、急であるが比較的短い学習曲線を越える。２つのＡＰＩフレームワークが、別々の、本質的に異なる性質であるため、第１フレームワークでの経験は、第２フレームワークの第２ＡＰＩの学習に向けての何らかの知識が存在する場合であってもほとんど寄与しない。したがって、第２フレームワークに関するＡＰＩを使用することを可能にするために、同様に急であるがさらに高い学習曲線を越える。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
言い換えれば、第１フレームワークのＡＰＩを学習することは、第２フレームワークのＡＰＩを学習するための足掛かりとはならない。このばらばらなＡＰＩフレームワークの組の退行的性質を連続性ギャップ（ｃｏｎｔｉｎｕｉｔｙ  ｇａｐ）で示す。第１フレームワークのＡＰＩを学習した開発者は、第２フレームワークのＡＰＩの学習が容易であるわけではなく、したがって第２フレームワークの基礎から開始しなければならない。
【０００７】
従来のフレームワークに伴う別の問題は、どんな場合にも全体のユーザビリティが貧弱となる傾向があることである。一般には、オブジェクト指向設計／開発（ＯＯＤ）方法（例えば統一モデリング言語（ＵＭＬ））は、得られるフレームワークのユーザビリティに関してではなく、得られる設計の保守性に関して「最適化」される。ＯＯＤ方法は、内部アーキテクチャの設計により適しており、大規模な再利用可能ライブラリのＡＰＩ層の設計にはそれほど適していない。例えば、ユーザビリティの貧弱さは、最低の基本ブロックとして抽出した物に焦点を当て、および／またはＡＰＩ設計全体を通して厳格な継承階層を確固として守るＯＯＤ方法の結果として生じる可能性がある。
【０００８】
したがって、従来のＡＰＩ学習曲線および／または少なくとも退行的連続性ギャップを改善することができ、および／またはより良好な全ＡＰＩユーザビリティを達成することができるスキームおよび／または技法が求められている。
【課題を解決するための手段】
【０００９】
第１の例示的方法の実装では、アプリケーションプログラミングインターフェース（ＡＰＩ）を設計する方法が、コアシナリオに対して複数のコードサンプルを準備するステップであって、その複数のコードサンプルの各コードサンプルが複数のプログラミング言語の各プログラミング言語に対応するステップと、その複数のコードサンプルに応答して、コアシナリオからＡＰＩを導出するステップとを含む。第２の例示的方法の実装では、ＡＰＩを設計する方法が、機能エリア（ｆｅａｔｕｒｅ  ａｒｅａ）に関するコアシナリオを選択するステップと、コアシナリオに関する少なくとも１つのコードサンプルを書き込むステップと、その少なくとも１つのコードサンプルに応答して、コアシナリオに関するＡＰＩを導出するステップとを含む。第３の例示的方法の実装では、ＡＰＩを設計する方法が、シナリオに関する少なくとも１つのコードサンプルに応答して、そのシナリオに関するＡＰＩを導出するステップと、複数の開発者を使用して、ＡＰＩに関する１つまたは複数のユーザビリティスタディを実行するステップと、その１つまたは複数のユーザビリティスタディに基づいてＡＰＩを修正するステップとを含む。
【００１０】
他の方法、システム、手法、装置、デバイス、媒体、ＡＰＩ、手順、構成などの実装を本明細書で説明する。
【００１１】
同様の、および／または対応する態様、機能、およびコンポーネントを参照するのに、図面全体を通して同一の数字を使用する。
【発明を実施するための最良の形態】
【００１２】
図２に、２つの異なるレベルのアブストラクションに関する例示的な漸進的ＡＰＩ学習曲線のグラフ２００を示す。図示するこの２つの異なるレベルのアブストラクションは、比較的高レベルのアブストラクションと比較的低レベルのアブストラクションである。高レベルのアブストラクションは、必要なスキルおよび／または難易度のレベルが比較的低く、それに付随して開発者による制御に関する能力が比較的低い開発環境に対応する。一方、低レベルのアブストラクションは、必要なスキルおよび／または難易度のレベルが比較的高く、それに付随して開発者による制御に関する能力が比較的高い開発環境に対応する。
【００１３】
必要なスキルおよび付随する制御能力が比較的低い地点から、高／低レベルのアブストラクションに関するエリアを通り、必要なスキルおよび付随する制御能力が比較的高い地点まで、比較的スムースに上昇する漸進的ＡＰＩ学習曲線が示されている。漸進的ＡＰＩ学習曲線は、高レベルのアブストラクションのエリアと低レベルのアブストラクションのエリアの間で連続性ゾーンを示す。統合ＡＰＩフレームワークにより、段階的な学習曲線が可能となる。ＡＰＩフレームワークの統合的な性質により、高レベルのアブストラクションでの経験が、低レベルのアブストラクションならびにより高い制御を要求するシナリオについてのＡＰＩ使用法を学習する助けとなる知識に寄与する。
【００１４】
言い換えれば、高レベルのアブストラクションについてのＡＰＩを学習することにより、低レベルのアブストラクションについてのＡＰＩを学習すること、および／またはＡＰＩを低レベルのアブストラクションに拡張することの足掛かりが得られる。このことを、高レベルと低レベルのアブストラクションエリアを共に包含する２層（ＡＰＩ）フレームワーク形状で示す。本明細書の以下で説明する、あるＡＰＩの漸進的性質により、開発者が当初は単純なＡＰＩを使用し、より複雑なＡＰＩコンポーネントの使用を段階的（および部分的）に開始することが可能となる。したがって、高レベルのアブストラクションを目標とするＡＰＩを学習した開発者は、開発者の経験が保証される場合、および／または開発者が直面するシナリオの複雑さが要求する場合、低レベルのアブストラクションを目標とするＡＰＩの使用に移行することができる。
【００１５】
漸進的ＡＰＩは（特に初期の学習段階中は）容易に使用することができ、（ＡＰＩが経時的に調査されるときは特に）非常に強力である。使用可能なＡＰＩは、以下の例示的属性のうち１つまたは複数を含むことができる。開始するのに少数の概念および／またはクラスが必要であり、数行のコードが単純なシナリオを実施することができ、クラス／メソッドは直感的な名前を有し、自然および／または明白な開始点は容易に理解でき、追加の、必要および／または関係する概念／クラスへの明白な（例えば発見可能な）進歩がある。
【００１６】
漸進的ＡＰＩにより、難易度および付随する制御能力が低い地点での開発から、難易度および付随する制御能力が高い地点での開発に、増分式に進歩することも可能となる。漸進的ＡＰＩならびに一般に非常にユーザビリティが高いＡＰＩを設計するための例示的パラダイムを、本明細書の以下で説明する。
【００１７】
図３に、ＡＰＩについての例示的設計原理／慣習を表３００で示す。表３００は、４つの例示的カテゴリ３０２〜３０８についての一般的設計原理／慣習を示す。具体的には、シナリオ駆動設計３０２、コンポーネント指向設計３０４、カスタマイズ可能デフォルト３０６、および自己ドキュメントオブジェクトモデル３０８の４つのカテゴリを対象とする。
【００１８】
所与のＡＰＩを設計する場合、ここで示したカテゴリ３０２〜３０８のうち任意の１つまたは複数についての設計原理／慣習を利用することができる。さらに、与えられたカテゴリ３０２〜３０８のどの中でも、図示する設計原理／慣習のうちの１つまたは複数を利用することができる。言い換えれば、所与のＡＰＩ設計に対して、すべてのカテゴリや、カテゴリのすべての設計原理／慣習を利用する必要はなく、または実装する必要はない。
【００１９】
シナリオ駆動設計カテゴリ３０２は、４つの例示的設計原理／慣習を示す。第１に、選択する機能または技術領域についてのコアシナリオを定義する。第２に、コアシナリオに対応するコードサンプルをまず書き込み、それに応答して２番目にＡＰＩを設計する。第３に、上記で紹介し、本明細書の以下でさらに説明する漸進的ＡＰＩを設計する。第４に、定義したコアシナリオの使用を容易にすると共に、他のシナリオの使用を可能にする。シナリオ駆動設計３０２は、以下の「シナリオ駆動設計」と題するセクションでさらに説明する。
【００２０】
コンポーネント指向設計カテゴリ３０４は、３つの例示的設計原理／慣習を示す。第１に、集合コンポーネント（ＡＣ）を作成する。一般に、集合コンポーネントがコアシナリオに向けられ、比較的単純で使用するのが容易であり、ファクタードタイプ（ＦＴ）の上に構築される。ファクタードタイプはより基本的なものであり、より低い論理レベルに分解される。この結果、２層ＡＰＩ設計となる。第２に、こうした集合コンポーネントがファクタードタイプと相関付けられる。第３に、特に集合コンポーネントについて、ｃｒｅａｔｅ−ｓｅｔ−ｃａｌｌ使用パターンがサポートされる。以下の「コンポーネント指向設計」と題するセクションで、コンポーネント指向設計３０４をさらに説明する。
【００２１】
カスタマイズ可能デフォルトカテゴリ３０６は、２つの例示的設計原理／慣習を示す。第１に、少なくとも集合コンポーネントを使用するのに必要な初期化を低減する。必要な初期化を低減するのにデフォルトを使用する。第２に、定義されたコアシナリオに対して適切なデフォルトを選択する。以下の「カスタマイズ可能デフォルト」と題するセクションで、カスタマイズ可能デフォルト３０６をさらに説明する。
【００２２】
自己ドキュメントオブジェクトモデルカテゴリ３０８は、４つの例示的設計原理／慣習を示す。第１に、コアシナリオに対して単純で直感的な名前を確保する。第２に、継承階層にかたくなに執着するのではなく、コンポーネントタイプの意図する使用法または目的に基づいて名前を選択する。第３に、行動可能な例外が投入され、その結果、開発者は、エラーをどのように修復するかを指示する命令を例外メッセージから受け取る。第４に、主名前空間が乱雑となるのを回避するために、稀にしか使用されないタイプをサブネームスペースに配置することにより、クリーンな名前空間を生成する。以下の「自己ドキュメントオブジェクトモデル」と題するセクションで、自己ドキュメントオブジェクトモデル３０８をさらに説明する。
【００２３】
シナリオ駆動設計
ここで説明する実装では、ＡＰＩ仕様がシナリオによって駆動される。したがって、ＡＰＩ設計者はまず、ＡＰＩのユーザが書かなければならないコードをコア（例えばメイン）シナリオに書く。次いでＡＰＩ設計者は、オブジェクトモデルを設計して、こうしたコードサンプルをサポートする。この手法は、（様々な設計方法を用いて）オブジェクトモデルの設計を開始し、次いで、得られるＡＰＩに基づいてコードサンプルを書くことと対照的である。
【００２４】
言い換えれば、共通ＡＰＩ設計では特に、ＡＰＩ設計者は、各機能／技術エリアについてのシナリオとそれに関するコードサンプルのリストから開始し、それに基づいて、ヘッダスタイルオブジェクトモデル記述を生成する。機能エリアの例には、ファイルＩ／Ｏ、ネットワーキング、メッセージ交換、コンソール、診断、データベースアクセス、ウェブページ、グラフィカルユーザインターフェース（ＧＵＩ）プログラミングなどが含まれる。
【００２５】
図４は、機能エリアごとにＡＰＩを設計する例示的技法を示す流れ図４００である。ブロック４０２では、与えられた機能エリアに対してコアシナリオを選択する。例えば、所与の技術エリアについて、５〜１０個のシナリオを選択することができる。シナリオは、与えられた技術エリアに関して最も一般的に使用される機能（例えば最も一般的なタスク）または最も頻繁に追求される目標に基づいて選択することができる。例えば、ファイルＩ／Ｏ技術機能エリアに対する例示的シナリオは、ファイルから読み取ること、およびファイルに書き込むことである。
【００２６】
ブロック４０４では、コアシナリオに関するコードサンプルを複数（例えば２つ以上）の言語で書く。例えば、選択したコアシナリオに関連するコードサンプルを３つの異なる言語で書くことができる。コードサンプルは、選択した現コアシナリオを３つの言語で実行することができる。このような言語には、例えばＶＢ、Ｃ＃、ＭＣ＋＋、マークアップ言語などが含まれる。しかし、その他の言語も使用することができる。アスタリスクで示すように、単一言語用の使用可能および強力なＡＰＩを設計する場合に、コアシナリオに関してコードサンプル（さらには複数のコードサンプル）を単一言語で書けることを理解されたい。
【００２７】
異なる言語で書かれたコードは著しく異なることがあるので、複数の言語でのコードサンプルの書込みを実施することができる。ここで説明する実装では、選択した現コアシナリオに関するコードサンプルは、特定のコードサンプルが書かれる特定の言語のユーザ間で共通の異なるコーディングスタイルを使用して（例えば、言語特有の機能または特性、開発者の習癖／慣習などを使用して）書かれる。例えば、言語特有のケーシングを使用してサンプルを書くことができる。例えば、ＶＢは大／小文字を区別せず、したがってＶＢで書かれたコードサンプルはその変異性を反映する。一方、Ｃ＃で書かれたコードサンプルは、それに関する標準ケーシングに追従する。
【００２８】
別の例は、Ｃ＃がサポートする「ｕｓｉｎｇ」と呼ばれるステートメントに関するものである。例えば、「ｕｓｉｎｇ」コールは、ｔｒｙ／ｆｉｎａｌｌｙブロックをカプセル化する。しかし、ＶＢはこの機能をサポートせず、コードサンプルを書くことにより、この機能をｔｒｙ／ｆｉｎａｌｌｙステートメントで使用することはＶＢユーザにとって難しいということが示される可能性がある。さらに別の例は、Ｃ＃がサポートする条件節での割当てに関するものである。ファイルＩ／Ｏの例において、「ｉｆ（（ｔｅｘｔ＝ｒｅａｄｅｒ．ＲａｄＬｉｎｅ（）！＝ｎｕｌｌ）」はＣ＃で機能する。しかしＶＢでは、「ｉｆ」節内で割当てステートメントを使用することができない。その代わりに、コードが複数のステートメントに分割される。さらに別の例は、Ｃ＃開発者はパラメータ化コンストラクタを使用するが、ＶＢ開発者は通常は使用しないという傾向に関するものである。例えば、Ｃ＃でのコーディングは「ＭｙＣｌａｓｓ  ｘ＝ｎｅｗ  ＭｙＣｌａｓｓ（“ｖａｌｕｅ”）」でよいが、対応するＶＢでのコーディングは「Ｄｉｍ  ｘ  Ａｓ  ＭｙＣｌａｓｓ」および「ｘ．Ｐｒｏｐｅｒｔｙ＝“ｖａｌｕｅ”」である。
【００２９】
ブロック４０６では、複数の言語で書かれたコードサンプルに応答して、現コアシナリオからＡＰＩを導出する。例えば、複数の各言語で書かれたコードサンプルから集めた因子をＡＰＩに組み込むことができる。このような因子は、異なるコードサンプル間の類似性、２つ以上のコードサンプル間の差などを含むことができる。このような因子、ならびにブロック４０４および４０６のその他の態様を、図５を参照しながら以下でさらに説明する。
【００３０】
同様に、単一言語用のＡＰＩを設計する場合、単一言語で書かれたコードサンプルに応答して、現コアシナリオからＡＰＩを導出する。したがって、単一言語で書かれたコードサンプルから集めた因子をＡＰＩに組み込むことができる。単一または複数の言語の状況についての追加のＡＰＩ設計因子例として、ＡＰＩ設計因子は、コードサンプルを書くための言語向けのツールとの互換性を含むことができる。
【００３１】
ブロック４０８では、ＡＰＩが複雑すぎるか否かを判定する。例えば、ＡＰＩ設計者がＡＰＩを検討し、ＡＰＩが複雑すぎるか、それともそれほど複雑でないかを判定する。言い換えれば、初期チェックを実施して、複数の他の特定のＡＰＩをかなり理解しなくてもＡＰＩを使用することができるか否か、過度の実験をしなくてもＡＰＩを使用することができるか否かなどを考慮することができる。このような初期チェックはまた、導出したＡＰＩが関連するあらゆる言語での現コアシナリオで実際に動作可能であることも検証することができる。ＡＰＩが複雑すぎる場合、設計者は、ブロック４０６で、現コアシナリオを参照しながら、複数の言語で書かれたコードサンプルに応答して、ＡＰＩを改良する。
【００３２】
一方、（ブロック４０８で）ＡＰＩはそれほど複雑でないと判定した場合、ブロック４１０で、典型的な開発者を使用してユーザビリティスタディを実施する。例えば、典型的な開発者が通常使用するのと類似の開発環境を使用して、１つまたは複数のユーザビリティスタディを実施することができる。このような通常の開発環境は、インテリセンス、エディタ、言語、および対象とする開発者グループによって最も広く使用される文書セットを含む可能性が高い。
【００３３】
ユーザビリティスタディ
広範な開発者を対象とするユーザビリティスタディにより、特に一般の共通ＡＰＩを設計する場合、シナリオ駆動設計が実施される。コアシナリオに関するＡＰＩ設計者によって書かれたコードサンプルは、恐らくはそのＡＰＩ設計者にとっては単純に見えるが、実際に対象とする開発者のうちのあるグループ（例えば、特に経験の浅い開発者および／または頻繁には開発しない開発者）にとってはそのコードサンプルは同程度に単純ではない可能性がある。加えて、ユーザビリティスタディによって得られる、開発者が各コアシナリオに取り組む仕方に関する理解により、ＡＰＩの設計と、対象とする開発者のすべての必要をどの程度満たしているかについて強力な洞察を得ることができる。
【００３４】
一般に、ユーザビリティスタディは、製品サイクルの初期に実行することができ、オブジェクトモデルの大規模な再設計の後に再び実行することができる。これはコストのかかる設計慣習であるが、実際には長期間では資源を節約することができる。使用不能または単に欠陥のあるＡＰＩを、急激な変化を導入することなく修正するコストは莫大である。
【００３５】
ブロック４１２では、典型的な開発者が重大な問題なしにＡＰＩを使用できるか否かを確認する。例えば、ほとんどのサブジェクトは、選択した現シナリオに関するコードを、大きな問題なしに書くことができるべきである。大きな問題なしに書くことができない場合、（ブロック４１４を参照しながら以下で説明するように）ＡＰＩを修正する。
【００３６】
重大な／大きな問題の解釈は、所与の対象とする開発者グループに対する所望のユーザビリティレベルにかかっている。例えば、テストサブジェクトによる、現コアシナリオに関する詳細なＡＰＩ文書への頻繁および／または広範にわたる参照は、重大な問題となる可能性がある。一般に、テスト開発者の大多数が現コアシナリオを実装しない場合、またはテスト開発者の取る手法が、予想される手法と著しく異なる場合、可能な修正（最大で完全な再設計までを含む）に関してＡＰＩを評価すべきである。
【００３７】
（ブロック４１２で）典型的な開発者が重大な問題なしにＡＰＩを使用できないと確認した場合、ブロック４１４で、ユーザビリティスタディの教訓に基づいてＡＰＩを修正する。例えば、デフォルトを変更することができ、別のプロパティを追加することができ、１つまたは複数の属性をカプセル化せずに公開することなどができる。
【００３８】
一方、（ブロック４１２で）典型的な開発者が重大な問題なしにＡＰＩを使用できると確認した場合、ブロック４１６で、各コアシナリオについてプロセスを反復する。例えば、与えられた機能に関する選択したコアシナリオの別のコアシナリオが、（ブロック４０４で）コードサンプルが書かれる現コアシナリオとなる。２層ＡＰＩ設計により焦点を当てたＡＰＩを設計する別の例示的技法を、図８と共に以下でさらに説明する。
【００３９】
図５は、コアシナリオごとにＡＰＩを設計する例示的スキームを示すブロック図４０４／４０６である。図示する例示的スキームは、複数言語実装の場合、図４のブロック４０４および４０６に対応する。第１言語に関するコードサンプル５０２（１）、第２言語に関するコードサンプル５０２（２）、および第３言語に関するコードサンプル５０２（３）が示されている。３つのコードサンプル５０２（１、２、３）はそれぞれ、所与の現コアシナリオに向けられる。３つの言語に対応する３つのコードサンプル５０２（１、２、３）を示すが、この例示的複数言語実装では、代替として任意の数の対象とする言語のうち２つ以上のコードサンプル５０２を使用することもできる。
【００４０】
ここで説明する実装では、３つの言語のそれぞれで書かれたコードサンプル５０２（１、２、３）から因子５０６を集める。これらの因子５０６はＡＰＩ５０４に組み込まれる。具体的には、３つの対応する各言語で書かれた３つのコードサンプル５０２（１、２、３）をサポートするようにＡＰＩ５０４を設計する。しかし、因子５０６は単一言語実装にも適用可能であることを理解されたい。
【００４１】
一部の例示的因子５０６は、図４のブロック４０４および４０６を参照しながら上記で説明したものであり、他の例示的因子５０６を、図５のブロック図４０４／４０６で示す。このような因子５０６は、コードサンプル５０２（１、２、３）の検討によって明らかとなる言語特有の命令を含む。言語特有の制約の一例を、サンプルコード行「Ｆｏｏ  ｆ＝ｎｅｗ  Ｆｏｏ（）；」に関して説明する。このサンプル行をサポートするように設計された漸進的ＡＰＩは、デフォルトコンストラクタを含まなければならない。そうでない場合、コードサンプルは正しくコンパイルされない。
【００４２】
因子５０６はまた、言語特性と、様々な言語に自然に引かれる典型的な開発者の様々なスキル／経験レベルの両方に触発される開発者の予想も含む。因子５０６は、コードサンプル５０２（１、２、３）の検討によって発見可能な、様々な言語間のコードおよびコーディング慣習の共通点もさらに含む。
【００４３】
様々な言語に直接関係する因子５０６を考慮すると共に、本明細書で説明するその他の因子５０６を引き続き考慮する。例えば、以下の因子５０６も、単一言語環境ならびに複数言語環境を対象とする漸進的ＡＰＩに関係する。第１に、シナリオを完了するのに必要な異なるコンポーネントタイプの数が一因子である。一般に、必要なコンポーネントタイプが多いほど、学習が難しくなる。第２の因子は、後続のコード行間の接続である。あるコンポーネントタイプの使用により、次の必要なコンポーネントタイプの使用に開発者が導かれる範囲では、ＡＰＩの使用が容易になる。
【００４４】
第３に、識別子の命名の整合性が別の因子である。第４の因子は、プロパティ、メソッド、およびイベントの適切な使用に関係する。第５の因子は、１つまたは複数の既存のＡＰＩに対する可能な類似性に関係する。第６の別の因子は、ＡＰＩに関する全設計ガイドラインの準拠に関係する。第７の因子は、ＡＰＩがフレームワークの他のコンポーネントタイプと重なるか否かに関係する。第８に、特定の言語に向けられるツールとの互換性が、さらに別の因子である。例えば、ＶＢ開発者は一般に、パラメータのないコンストラクタおよびプロパティセッタを望む。代替として、他の因子５０６も考慮することができる。
【００４５】
集合コンポーネントとファクタードタイプの相関関係に関するさらに別の因子５０６を、特に図８を参照しながら以下で説明する。図４および５の方法およびスキームは、ＡＰＩの設計に全般的に適用することができるが、２層ＡＰＩの設計に特に適用可能である。（例えば集合コンポーネントおよびファクタードタイプを伴う）２層ＡＰＩパラダイムを、図６〜８を参照しながら以下の「コンポーネント指向設計」と題するセクションで説明する。
【００４６】
コンポーネント指向設計
図６に、２つの異なる目的を対象とする例示的コンポーネントタイプ６０２間の潜在的不一致を連続体６００と共に示す。連続体６００は、左側の高ユーザビリティレンジから、右側の高制御性レンジまで延びる。複数のコンポーネントタイプ６０２が、連続体６００間に分布する。
【００４７】
一般に、相対的に大きく示されているコンポーネントタイプ６０２は、より単純であり、したがって使用するのがより容易なタイプを表す。逆に、相対的に小さく示されているコンポーネントタイプ６０２は、より複雑であり、したがって使用するのがより難しいタイプを表す。この状況での単純、複雑とは、指定のシナリオを実装する場合に特定のコンポーネントタイプ６０２を使用するのがどれほど容易であるか、またはどれほど難しいかを指す。
【００４８】
相対的に小さく示されているコンポーネントタイプ６０２は、以下のようないくつかの例示的理由のために、一般に使用するのがより難しい。第１に、開発者は、どのコンポーネントタイプ６０２を使用すべきかに関してより多くの選択肢を有する。図示する例では、大きいコンポーネントタイプ６０２について３つの「選択肢」があるのに対して、小さいコンポーネントタイプ６０２について１５個の「選択肢」がある。より具体的には、開発者は、様々なコンポーネントタイプ６０２（ＨＣ）の中から、どのコンポーネントタイプを使用するかを知っているか、または識別しなければならない。これには、複数（例えば１４個）のコンポーネントタイプ６０２（ＨＣ）のそれぞれについて、ならびにそれらがどのように相関するかを理解することが必要であり、このことは、より少数の（例えば３つ）のコンポーネントタイプ６０２（ＨＵ）のうちの単一のコンポーネントタイプ６０２（ＨＵ）から開始することと対照的である。コンポーネントタイプ６０２（ＨＵ）とコンポーネントタイプ６０２（ＨＣ）の違いを以下でさらに説明する。
【００４９】
例示的類推により、より小さいコンポーネントタイプ６０２は、ステレオシステムの個々のコンポーネントと似ている。したがって、ユーザは、どのコンポーネントが必要であり、それをどのように互いに接続されるかを知っていなければならない。各コンポーネントを互いに接続しないと、各コンポーネントは一般に有用ではない。より大きいコンポーネントタイプ６０２は、容易に使用することができるが、あまり強力ではなく、柔軟性が低くなる可能性の高いオールインワンステレオと似ている。より小さいコンポーネントタイプ６０２を使用するのが難しい第２の理由は、潜在的により多くの「開始点」が存在することである。第３に、一般には理解すべき概念がより多く存在する。第４に、開発者は、個々のコンポーネントタイプ６０２が他のコンポーネントタイプ６０２とどのように関係するかを理解しなければならない。
【００５０】
ここで説明する実装では、コンポーネントタイプ６０２が、高ユーザビリティ目的のコンポーネントタイプ６０２（ＨＵ）と、高制御性目的のコンポーネントタイプ６０２（ＨＣ）とに分割される。高ユーザビリティコンポーネントタイプ６０２（ＨＵ）は、より単純で使用するのが容易であるが、柔軟性が低く、限定的であり、および／または制限の多い傾向がある。高ユーザビリティコンポーネントタイプ６０２（ＨＵ）は、一般にＡＰＩ全体の広範な知識なしに使用することができる。高ユーザビリティコンポーネントタイプ６０２（ＨＵ）は通常、限定された数のシナリオ、または当該の各シナリオに対するせいぜい限定された数の手法を実行できるにすぎない。
【００５１】
一方、高制御性コンポーネントタイプ６０２（ＨＣ）は、使用するのが複雑であるが、より高程度の制御を開発者に提供する。高制御性コンポーネントタイプ６０２（ＨＣ）は相対的に強力であり、開発者が低レベルの微調整およびチューニングを実行することを可能にする。しかし、高制御性コンポーネントタイプ６０２（ＨＣ）を用いる開発は、比較的直接的なシナリオを実装するのでさえ、正しくインターリンクされた複数の高制御性コンポーネントタイプ６０２（ＨＣ）のインスタンス化を可能とするために、多くのコンポーネントタイプ６０２をより完全に理解することが必要とする。
【００５２】
通常、高ユーザビリティコンポーネントタイプ６０２（ＨＵ）は、ＶＢなどの入門的言語で提示され、高制御性コンポーネントタイプ６０２（ＨＣ）は、Ｃ＋＋などの上級のプロフェッショナルプログラマタイプ言語で提示される。図６に示す高ユーザビリティコンポーネントタイプ６０２（ＨＵ）と高制御性コンポーネントタイプ６０２（ＨＣ）の間の潜在的不一致は、図７のコンポーネントタイプ７０２によって少なくとも部分的に改善される。具体的には、高ユーザビリティコンポーネントタイプ６０２（ＨＵ）と高制御性コンポーネントタイプ６０２（ＨＣ）との間の相関関係が、漸進的ＡＰＩによって確立される。
【００５３】
図７に、連続体７００に沿った少なくとも２つの異なる目的をカバーするように拡張可能および／または相互動作可能に設計されたコンポーネントタイプ７０２間の例示的関係を示す。ここで説明する実装では、高ユーザビリティ目的のコンポーネントタイプが集合コンポーネント７０２（ＡＣ）として実現され、高制御性目的のコンポーネントタイプがファクタードタイプ７０２（ＦＴ）として実現される。コンポーネントタイプ７０２が２つの目的だけに分割されているが、代替として、３つ以上の目的（またはその他のカテゴリ）に分離することもできる。
【００５４】
キー７０４は、実線が、公開されたファクタードタイプについての関係を表し、破線が、カプセル化されたファクタードタイプについての関係を表すことを示す。図示するように、集合コンポーネント７０２（ＡＣ）（１）は、３つのファクタードタイプ７０２（ＦＴ）との関係を有する。具体的には、ファクタードタイプ７０２（ＦＴ）（１）は、集合コンポーネント７０２（ＡＣ）（１）と公開されたファクタードタイプ関係を有し、ファクタードタイプ７０２（ＦＴ）（２）および７０２（ＦＴ）（３）は、集合コンポーネント７０２（ＡＣ）（１）とカプセル化されたファクタードタイプ関係を有する。
【００５５】
図示していないが、２つ以上の集合コンポーネント７０２（ＡＣ）が、同一のファクタードタイプ７０２（ＦＴ）と、カプセル化された関係および／または公開された関係を有することができる。公開されカプセル化されたファクタードタイプ７０２（ＦＴ）および集合コンポーネント７０２（ＡＣ）、ならびにそれらの関係を、図８への参照を含めて以下でさらに説明する。
【００５６】
コンポーネント指向設計は、論理的概念ごとに複数のオブジェクトを必要とするのとは対照的に、ユーザ概念ごとに単一オブジェクトを提供することに関係する。したがって、集合コンポーネントは通常はユーザ概念に対応し、ユーザビリティの観点からはより単純となる。集合コンポーネントは、ファクタードタイプの上に重ねられる。例示的比較では、集合コンポーネントは、ファイルなどの事柄をモデル化することができ、ファクタードタイプは、ファイルに対するビューなどの事柄の状態をモデル化することができる。集合コンポーネントとファクタードタイプとがあいまって、新しい開発者に対して、特に特定の所与のＡＰＩに関して、漸進的および段階的な学習曲線を提供する。
【００５７】
集合コンポーネントに関するコンポーネント指向設計
多くの機能エリアは、より複雑であるがウェルファクタード（ｗｅｌｌ−ｆａｃｔｏｒｅｄ）の機能エリアＡＰＩの残りにわたって単純化されたビューとして振る舞うファサードタイプから恩恵を受けることができる。ここで説明する実装では、ファサードは、所与の機能エリアで上位５〜１０個のシナリオをカバーし、任意選択で他の高レベルオペレーションをカバーする。集合コンポーネント７０２（ＡＣ）は、このようなファサードタイプとして働くことができ、ファクタードタイプ７０２（ＦＴ）は残りのウェルファクタードの複雑なＡＰＩランドスケープを提供することができる。
【００５８】
各集合コンポーネントは、複数の低レベルファクタードクラスを高レベルコンポーネントに結合して、トップコアシナリオをサポートする。例えば、メール集合コンポーネントは、ＳＭＴＰプロトコル、ソケット、符号化などを互いに結合することができる。一般に、各集合コンポーネントは、物事を行う異なる方法を単に提供するのではなく、より高いアブストラクションレベルを提供する。単純化した高レベルオペレーションは、機能エリアで提供される機能の全範囲を学習することを望まず、開発者のしばしば非常に単純なタスクを、学習またはＡＰＩ調査をあまりせずに単に実行することを望む開発者にとって役立つ。
【００５９】
一般に、コンポーネント指向設計は、コンストラクタ、プロパティ、メソッド、およびイベントに基づく設計である。集合コンポーネントを使用することは、コンポーネント指向設計の比較的極端なアプリケーションである。集合コンポーネントのコンポーネント指向設計のための例示的な１組のパラメータを以下に与える。
コンストラクタ：集合コンポーネントはデフォルト（パラメータなしの）コンストラクタを有する
コンストラクタ：任意選択のコンストラクタパラメータは、プロパティに対応する。
プロパティ：大部分のプロパティはゲッタおよびセッタを有する。
プロパティ：プロパティは理解できるデフォルトを有する。
メソッド：（選択したコアシナリオで）各メソッドコールにわたって一定のままとどまるオプションをパラメータが指定する場合、メソッドはパラメータを取らない。このようなオプションは、プロパティを使用して指定することができる。
イベント：メソッドはパラメータとしてデリゲートを取らない。イベントに関してコールバックが実行される。
【００６０】
コンポーネント指向設計は、オブジェクトモデルにメソッド、プロパティ、およびイベントを単に含めることに焦点を合わせる代わりに、どのようにＡＰＩを使用するかを考慮することを伴う。コンポーネント指向設計に関する例示的使用モデルは、デフォルトのコンストラクタまたは比較的単純なコンストラクタでタイプをインスタンス化し、インスタンスに対していくつかのプロパティを設定し、次いで単純なメソッドをコールするパターンを含む。このパターンをＣｒｅａｔｅ−Ｓｅｔ−Ｃａｌｌ使用パターンと呼ぶ。一般的例は以下の通りである。
【００６１】
【表１】
2005129027.tif 000003
【００６２】
集合コンポーネントがこのＣｒｅａｔｅ−Ｓｅｔ−Ｃａｌｌ使用パターンをサポートする場合、集合コンポーネントは、集合コンポーネントのメインユーザの予想と一致する。さらに、インテリセンスや設計者などのツールが、この使用パターン向けに最適化される。Ｃｒｅａｔｅ−Ｓｅｔ−Ｃａｌｌ使用パターンを示す具体的なコード例は、以下の通りである。
【００６３】
【表２】
2005129027.tif 000004
【００６４】
漸進的ＡＰＩの一部である例示的集合コンポーネントでは、「Ｆｉｌｅ．Ｅｎｃｏｄｉｎｇ」プロパティのセットは任意選択である。ＡＰＩは、指定されない場合、事前選択したファイル符号化についてのデフォルトを有する。同様に、「Ｆｉｌｅ．Ｏｐｅｎ（）」に関して、「ＯｐｅｎＭｏｄｅ．Ｗｒｉｔｅ」の指定は任意選択である。指定されない場合、ＡＰＩによって事前選択されたデフォルト「ＯｐｅｎＭｏｄｅ」が使用される。
【００６５】
コンポーネント指向設計に伴う問題は、コンポーネント指向設計の結果として、モードおよび無効状態を有する可能性のあるタイプが得られることである。例えば、デフォルトコンストラクタにより、ユーザは、「ＦｉｌｅＮａｍｅ」を指定することなく「ＦｉｌｅＯｂｊｅｃｔ」をインスタンス化することが可能となる。「ＦｉｌｅＯｂｊｅｃｔ」は、オープンされることに関して無効な状態にある（例えば、まだファイル名を指定していない）ので、「ＦｉｌｅＮａｍｅ」をまずセットすることなくＯｐｅｎ（）をコールするよう試みることにより、例外が発生する。別の問題は、任意選択で独立にセットすることができるプロパティが、オブジェクトの状態に対して一貫した微細な変更を実行しないことである。さらに、このような「モーダル」プロパティは、消費者間でのオブジェクトインスタンスの共有を禁止する。第１ユーザは、第２ユーザが合間に値を変更した場合、以前にセットした値を再利用する前にその値をチェックしなければならないからである。しかし、非常に多くの開発者にとって、集合コンポーネントのユーザビリティは、こうした問題より重要である。
【００６６】
ユーザがオブジェクトの現状態で有効ではないメソッドをコールしたとき、「ＩｎｖａｌｉｄＯｐｅｒａｔｉｏｎＥｘｃｅｐｔｉｏｎ」が投じられる。この例外のメッセージは、オブジェクトを有効な状態にするためにどのプロパティを変更する必要があるかを明確に説明することができる。こうした明確な例外メッセージにより、無効状態の問題が部分的に克服され、より自己ドキュメント型のオブジェクトモデルが得られる。
【００６７】
ＡＰＩ設計者はしばしば、オブジェクトが無効状態で存在することができないようにタイプを設計しようとする。このことは例えば、すべての必要な設定をコンストラクタに対するパラメータとして有し、インスタンス化の後に変更することのできない設定に関するｇｅｔ−ｏｎｌｙプロパティを有し、プロパティおよびメソッドが重ならないように機能を別々のタイプに分割することによって実行される。ここで説明する実装では、この手法は、集合コンポーネントではなく、ファクタードタイプで使用される。集合コンポーネントでは、開発者は、無効状態を開発者に通信するクリア例外の提供を受ける。こうしたクリア例外は、コンポーネントがインスタンス化されるとき（例えば、コンストラクタがコールされるとき、またはプロパティがセットされるとき）ではなく、オペレーションの実行中に投入することができ、それによって無効状態が一時的である状態が回避され、後続のコード行で「修正」される。
【００６８】
ファクタードタイプ
上述のように、集合コンポーネントは、最も一般的な高レベルオペレーションに対するショートカットを提供し、通常は、１組のより複雑であるがよりリッチでもあるタイプにわたってファサードとして実装される。これは、ファクタードタイプと呼ばれる。ここで説明する実装では、ファクタードタイプはモードを持たず、非常に明白な存続時間を有する。
【００６９】
集合コンポーネントは、あるプロパティおよび／またはメソッドを介して、その内部ファクタードタイプへのアクセスを提供することができる。ユーザは、比較的高度なシナリオ、またはシステムの様々な部分との統合が必要なシナリオで、内部ファクタードタイプにアクセスする。集合コンポーネントによって使用されるファクタードタイプにアクセスする能力により、集合コンポーネントを使用して書かれたコードが、高度なシナリオに対して複雑さを増分式に追加することが可能となり、またはファクタードタイプを使用することに焦点を合わせることから始めてコードを書き直さなくても、他のコンポーネントタイプと統合することが可能となる。
【００７０】
以下の例に、その例示的内部ファクタードタイプ（「ＳｔｒｅａｍＷｒｉｔｅｒ」）を公開する例示的集合コンポーネント（「ＦｉｌｅＯｂｊｅｃｔ」）を示す。
【００７１】
【表３】
2005129027.tif 000005
【００７２】
高レベルオペレーション
ここで説明する実装では、（例えば、アブストラクションのレベルの観点から見て）より上位レベルまたは高レベルのＡＰＩとしての集合コンポーネントが、ユーザが下で生じている時として複雑な物事を意識しなくても「魔術的に」機能するように見えるように実装される。例えば、「ＥｖｅｎｔＬｏｇ」集合コンポーネントは、ログが、読取りハンドルと書込みハンドルをどちらも有することを隠す。読取りハンドルと書込みハンドルはどちらも、ログを使用するために開かれる。開発者が関わることができる限りにおいて、集合コンポーネントをインスタンス化することができ、プロパティをセットすることができ、ｕｎｄｅｒ−ｔｈｅ−ｈｏｏｄ機能に関わることなくログイベントを書き込むことができる。
【００７３】
ある状況では、わずかに高い透過性により、開発者を伴う一部のタスクを実行することができる。一例は、オペレーションの結果としてユーザが明示的なアクションを取るオペレーションである。例えば、暗黙的にファイルを開き、次いでそれを暗黙的に閉じるようユーザに要求することは恐らく、「魔術的に」機能する原理を極端に取ることである。それでも、勤勉なＡＰＩ設計者はしばしば、そうした複雑さえも隠す巧みな解決策を設計することができる。例えば、ファイルの読取りは、ファイルを開き、その内容を読み取り、ファイルを閉じる単一のオペレーションとして実行することができる。したがってユーザは、ファイルハンドルのオープンおよびクローズに関する複雑さから隠される。
【００７４】
さらに、集合コンポーネントの使用は、どんなインターフェースの実装も含まず、どんな構成ファイルの修正も含まず、以下同様である。その代わりに、ライブラリ設計者は、宣言されたインターフェースに関するデフォルトの実装を出荷することができる。さらに、構成の設定は任意選択であり、理解できるデフォルトによって後援される。
【００７５】
図８に、２つの異なる目的を２層ＡＰＩ８００で処理する例示的集合コンポーネント７０２（ＡＣ）および関連するファクタードタイプ７０２（ＦＴ）を示す。集合コンポーネント７０２（ＡＣ）は、第１層以上の層を表し、ファクタードタイプ７０２（ＦＴ）は、第２層以下の層を表す。第１層は実質上、カスタムインターフェースを用いて第２層上に構築される。
【００７６】
図示するように、集合コンポーネント７０２（ＡＣ）は、複数の集合コンポーネント（ＡＣ）メンバ８０２を含む。具体的には、集合コンポーネントメンバ８０２（１）、８０２（２）、８０２（Ｐ）（１）、８０２（Ｐ）（２）、８０２（Ｍ）（１）、８０２（Ｍ）（２）、および８０２（Ｍ）（３）が示されている。集合コンポーネント７０２（ＡＣ）はまた、公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）およびカプセル化されたファクタードタイプ７０２（ＦＴ−Ｅｎ）も含む。具体的には、公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）（１）および７０２（ＦＴ−Ｅｘ）（２）、ならびにカプセル化されたファクタードタイプ７０２（ＦＴ−Ｅｎ）（１）および７０２（ＦＴ−Ｅｎ）（２）が示されている。ファクタードタイプ７０２（ＦＴ）はまた、ファクタードタイプ（ＦＴ）メンバ８０４も含む。
【００７７】
ここで説明する実装では、集合コンポーネント７０２（ＡＣ）は、少なくとも１つの集合コンポーネントメンバ８０２を含む。集合コンポーネントメンバ８０２は、例えばメソッドまたはプロパティでよい。したがって、集合コンポーネントメンバ８０２は、集合コンポーネントメソッド８０２（Ｍ）および集合コンポーネントプロパティ８０２（Ｐ）を含むことができる。集合コンポーネントメンバ８０２（１）および８０２（２）などのこうした集合コンポーネントメンバ８０２は、集合コンポーネント７０２（ＡＣ）に特有のものでよい。言い換えれば、集合コンポーネント７０２（ＡＣ）上にある集合コンポーネントメンバ８０２（１）および８０２（２）などの一部の集合コンポーネントメンバ８０２は、どんなファクタードタイプ７０２（ＦＴ）にも依拠しないことがある。代替として、一部の集合コンポーネントメンバ８０２を、下にあるファクタードタイプ７０２（ＦＴ）にリンクすることもできる。
【００７８】
ファクタードタイプ７０２（ＦＴ）は、公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）またはカプセル化されたファクタードタイプ７０２（ＦＴ−Ｅｎ）でよい。公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）は、所与の集合コンポーネント７０２（ＡＣ）の個々の集合コンポーネントメンバ８０２を使用せずに、または所与の集合コンポーネント７０２（ＡＣ）の個々の集合コンポーネントメンバ８０２を通ることなく、他の一般コンポーネントタイプ７０２（ＦＴまたはＡＣ）によってアクセス可能な、または他の一般コンポーネントタイプ７０２（ＦＴまたはＡＣ）にとってアクセス可能な所与の集合コンポーネント７０２（ＡＣ）のファクタードタイプ７０２（ＦＴ）である。ファクタードタイプ７０２（ＦＴ−Ｅｘ／Ｅｎ）が集合コンポーネントメンバ８０２（メソッドまたはプロパティ）によって返される場合、そのファクタードタイプ７０２（ＦＴ−Ｅｘ）が公開される。そうでない場合、そのファクタードタイプ７０２（ＦＴ−Ｅｎ）がカプセル化される。
【００７９】
言い換えれば、集合コンポーネントメンバ８０２はファクタードタイプメンバ８０４を公開することができ、または集合コンポーネントメンバ８０２はファクタードタイプインスタンスを返すことができる。後者は、公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）で行うことができ、前者は、カプセル化されたファクタードタイプ７０２（ＦＴ−Ｅｎ）で行うことができる。カプセル化されたファクタードタイプ７０２（ＦＴ−Ｅｎ）は、所与の集合コンポーネント７０２（ＡＣ）内に含まれる、または所与の集合コンポーネント７０２（ＡＣ）の内部のその所与の集合コンポーネント７０２（ＡＣ）のファクタードタイプ７０２（ＦＴ）である。各ファクタードタイプ７０２（ＦＴ）は、メソッドおよび／またはプロパティである１つまたは複数のメンバ８０４（その一部を図８に具体的に示す）を含むことができる。
【００８０】
図示するように、カプセル化されたファクタードタイプ７０２（ＦＴ−Ｅｎ）（１）の２つのメソッドメンバ８０４が、メソッドメンバ８０２（Ｍ）（１）およびメソッドメンバ８０２（Ｍ）（２）として集合コンポーネント７０２（ＡＣ）によって公開される。カプセル化されたファクタードタイプ７０２（ＦＴ−Ｅｎ）（２）の１つのメソッドメンバ８０４が、メソッドメンバ８０２（Ｍ）（３）として集合コンポーネント７０２（ＡＣ）によって公開される。
【００８１】
公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）（１）はそれ自体、集合コンポーネント７０２（ＡＣ）のプロパティメンバ８０２（Ｐ）（１）として公開される。同様に、公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）（２）も集合コンポーネント７０２（ＡＣ）のプロパティメンバ８０２（Ｐ）（２）として公開される。ここに示すように、公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）（１）のファクタードタイプ（ＦＴ）メンバ８０４は、別々にアクセス可能（すなわち、集合コンポーネント７０２（ＡＣ）の個々のメンバ８０２を直接使用せずにアクセス可能）となるように公開される。したがって、公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）のファクタードタイプメンバ８０４は、集合コンポーネント７０２（ＡＣ）の集合コンポーネントメンバ８０２によって個々に公開されない場合であってもなおアクセスすることができる。
【００８２】
したがって、公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）（１）の示されるメンバ８０４は、集合コンポーネント７０２（ＡＣ）のメンバ８０２を使用することなく、集合コンポーネント７０２（ＡＣ）の外部にあるコンポーネントタイプ７０２によってアクセス可能となるように公開される。公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）（１）から出る破線で示すように、公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）は、集合コンポーネント７０２（ＡＣ）と対話することができないか、または渡される公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）（１）だけを使用してその所期の目的をより良く達成することができる他のコンポーネントタイプ７０２（特に他のファクタードタイプ７０２（ＦＴ））で使用するために「渡す」ことができる。「渡される」オブジェクト（公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）（１））は、公開する集合コンポーネント７０２（ＡＣ）のコピーではなく、実際の一部であることに留意されたい。その結果、渡されたオブジェクトに対するオペレーションが、集合コンポーネント７０２（ＡＣ）に影響を及ぼす。
【００８３】
一般に、ファクタードタイプ７０２（ＦＴ）がカプセル化される場合、消費者には公開されない。その代わりに、集合コンポーネント７０２（ＡＣ）上のプロパティ８０２（Ｐ）を設定し、またはメソッド８０２（Ｍ）をコールすることにより、ファクタードタイプ７０２（ＦＴ）を作成することができ、プロパティ８０４をセットすることができ、または下にあるファクタードタイプ７０２（ＦＴ）上のメソッド８０４をコールすることができる。こうしたメンバ８０２および８０４は、１対１対応を持たないことがある。例えば、集合コンポーネント７０２（ＡＣ）上のいくつかのプロパティ８０２（Ｐ）を集合コンポーネント７０２（ＡＣ）内にキャッシュすることができる。その後で、集合コンポーネント７０２（ＡＣ）上のメソッド８０２（Ｍ）をコールすることにより、いくつかのプロパティ８０２（Ｐ）の以前に指定した値をファクタードタイプ７０２（ＦＴ）に対するコンストラクタ引数として使用して、ファクタードタイプ７０２（ＦＴ）を作成することができる。
【００８４】
ここで説明する実装では、集合コンポーネント７０２（ＡＣ）は、公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）の公開に加えて、少なくとも２つの点でより伝統的なオブジェクト指向コンポーネントとは異なる。第１に、集合コンポーネント７０２（ＡＣ）は、必ずしもそのファクタードタイプ７０２（ＦＴ）のすべてのあらゆるメンバ８０４を公開するわけではない。言い換えれば、集合コンポーネント７０２（ＡＣ）は、厳格に継承階層に向けられるわけではない。第２に、集合コンポーネント７０２（ＡＣ）はモードを有することができ、したがって無効なオペレーションとなる状態を周期的に有する可能性がある。
【００８５】
（図５の）因子５０６に関するコンポーネント指向設計に対するガイドラインとして、ファクタードタイプ７０２（ＦＴ）が公開されるのか、それとも集合コンポーネント７０２（ＡＣ）内にカプセル化されるのかは、いくつかの因子のうち１つまたは複数に基づくことができる。第１に、特定のファクタードタイプ７０２（ＦＴ）が所与の集合コンポーネント７０２（ＡＣ）によって公開されない機能を含む場合、特定のファクタードタイプ７０２（ＦＴ）が、その所与の集合コンポーネント７０２（ＡＣ）のプロパティメンバ８０２（Ｐ）として公開される。第２に、フレームワークの他の一般のコンポーネントタイプ７０２が、特定のファクタードタイプ７０２（ＦＴ）の直接消費についてハンドオフから恩恵を受けることができる場合、その特定のファクタードタイプ７０２（ＦＴ）が、所与の集合コンポーネント７０２（ＡＣ）のプロパティメンバ８０２（Ｐ）として公開される。一方、特定のファクタードタイプ７０２（ＦＴ）の機能が所与の集合コンポーネント７０２（ＡＣ）によって完全に公開される場合、および特定のファクタードタイプ７０２（ＦＴ）が他のコンポーネントタイプ７０２に渡すのに有用ではない場合、特定のファクタードタイプ７０２（ＦＴ）は公開されない（したがってカプセル化される）。
【００８６】
開発者は、特により単純なシナリオおよび／またはコアシナリオを実装するために、集合コンポーネント７０２（ＡＣ）から開始することができる。開発者がより複雑なシナリオを実装することを望む場合、またはそれが必要な場合、開発者は、経時的に、直接的なアクセスと、その低レベル属性を含む公開されたファクタードタイプ７０２（ＦＴ−Ｅｘ）の使用を、増分式および段階的に開始することができる。より単純な集合コンポーネント７０２（ＡＣ）に依拠した元のコードを廃棄する必要はなく、ファクタードタイプ７０２（ＦＴ）だけに依拠するより複雑なコーディングに取って代わられる。ＡＰＩフレームワークの２つの層を様々な割合で使用することができ、２つの層は、同時に共存することができる。
【００８７】
２層ＡＰＩフレームワークの設計は、１０段階で説明する以下の例示的技法を使用して実行することができる。第１に、特定の機能エリアに関する１組のコアシナリオを選択する。第２に、選択したコアシナリオに対して好ましいコード行を書く。第３に、コードサンプルをサポートするのに適切なメソッド、デフォルト、アブストラクション、命名などを用いてコード行から集合コンポーネントを導出する。
【００８８】
第４に、導出した集合コンポーネントに従って第２段階のコードサンプルを適宜改良する。第５に、改良したコードサンプルが十分に単純であるか否かについて評価する。十分に単純でない場合、この技法は再び第３段階に進む。十分に単純である場合、第６段階で、追加のシナリオ、使用法、他のコンポーネントとの対話、および／または他の要件が存在するか否かを判定する。第７に、選択したコアシナリオに過度の複雑さを加えることなく、第６段階で発見した追加要件のいずれかを集合コンポーネントに追加することができるかどうかをＡＰＩ設計者が判断する。
【００８９】
第８に、追加の要件を集合コンポーネントに追加することができない場合、第７段階に基づいて、ファクタードタイプ関する機能の全集合の（例えばオブジェクト指向またはその他の分析方法に基づく）理想的なファクタリングを定義する。第９に、第８段階で定義したファクタードタイプからの機能を集合コンポーネントがどのようにカプセル化または公開するか、およびカプセル化するか、それとも公開するかを決定する。第１０に、集合コンポーネントならびに追加の要件をサポートするようにファクタードタイプを適宜改良する。この例示的技法を使用して、集合コンポーネント７０２（ＡＣ）およびファクタードタイプ７０２（ＦＴ）を有する２層ＡＰＩフレームワークを設計することができる。
【００９０】
図９に、ｃｒｅａｔｅ−ｓｅｔ−ｃａｌｌ使用パターンをサポートすることができる例示的集合コンポーネント７０２（ＡＣ）、ならびに関連するＡＰＩ９０２、８０２（Ｐ）、８０２（Ｍ）、および９０４を示す。コンストラクタ９０２、プロパティ８０２（Ｐ）、メソッド８０２（Ｍ）、およびイベント９０４という例示的ＡＰＩグループを示す。ｃｒｅａｔｅ、ｓｅｔ、ｃａｌｌ使用パターンでは、初めに集合コンポーネント７０２（ＡＣ）のインスタンスが、開発者により、デフォルト（例えばパラメータなしの）コンストラクタ９０２に依拠して作成される。
【００９１】
第２に、開発者は、オブジェクトの所期の使用法にとってデフォルト値が不適切であり、および／または好ましくない任意のプロパティ８０２（Ｐ）をセットする。第３に、開発者が所望の方法８０２（Ｍ）をコールする。次いでコールバックをイベント９０４によって実行する。
【００９２】
カスタマイズ可能デフォルト
カスタマイズ可能デフォルトは、少なくとも集合コンポーネントに対して実行可能であるときはいつでも、デフォルトを有することに関係する。例えば複数の言語に対応する複数のコードサンプルを用いてＡＰＩを設計する場合、各コードサンプルで渡される同一の値を、代わりに集合コンポーネントに関するデフォルトとしてセットすることができる。カスタマイズ可能デフォルトは、集合コンポーネント上の１つまたは複数のプロパティをセットすることによって変更することができる。
【００９３】
多くの開発者は、プロジェクトを開始するに先立って、ドキュメントを読み、機能エリアを完全に理解するのではなく、試行錯誤でコーディングすることを好む。このことは、ＶＢを用いてコーディングする開発者など、経験の浅い開発者または頻繁には開発しない開発者について特に当てはまる。こうした開発者はしばしば、ＡＰＩが何を行い、どのように働くかを発見するために実験を試み、次いで、ＡＰＩ実装が開発者の目標を達成するまで、開発者のコードをゆっくりと、増分式に調整する。編集することの人気と、開発に対する継続的な手法は、この選好の表れである。
【００９４】
一部のＡＰＩ設計は「実験によるコーディング」に向いているが、別のＡＰＩ設計はそうではない。実験によるコーディング手法を使用する場合に開発者が有する可能性の高い成功のレベルに影響を及ぼす複数の側面が存在する。こうした側面には、（１）手元のタスクに対して正しいＡＰＩを配置することがどれほど容易か、（ｉｉ）ＡＰＩが（当初）開発者が望むことを行うか否かに関わらず、ＡＰＩの使用を開始することがどれほど容易か、（ｉｉｉ）ＡＰＩについてカスタマイズのポイントを発見することがどれほど容易か、（ｉｖ）所与のシナリオに対して正しいカスタマイズを発見することがどれほど容易か、および（ｖ）その他が含まれる。
【００９５】
ここで説明する実装では、ＡＰＩは、何らかの初期化（例えば最小量の初期化）が存在する場合であってもほとんどそれを必要としないように設計される。例えば、デフォルトコンストラクタまたは１つの単純なパラメータを有するコンストラクタが、タイプで作業を開始するのには十分であるようにＡＰＩを設計することができる。初期化が必要である場合、初期化を実行しなかった結果として生じる例外は、例外を除去または防止するために何を行う必要があるか、および／または何を変更する必要があるかを明確に説明する。例えば、例外は、何のプロパティまたはどのプロパティをセットする必要があるかを規定することができる。
【００９６】
例えば、限定はしないが、経験則として、最も単純なコンストラクタは、３つ以下（上限５）のパラメータを有する。加えて、最も単純なコンストラクタは、パラメータのうちのいずれかとして複雑なタイプを回避すべきである。複雑なタイプとは、他のファクタードタイプまたは集合コンポーネントである。別の経験則として、最も単純なコンストラクタが、列挙、文字列、整数などのプリミティブタイプに依拠する。タイプはまた、より複雑なシナリオをサポートするためにより複雑なコンストラクタオーバーロードを実装することもできる。
【００９７】
手短に言えば、ＡＰＩのカスタマイザビリティは、すべてのカスタマイズポイントに対して良好なデフォルトを有するプロパティを提供することによって単純化することができる（しかし、開発者は一般に、開発者のシナリオをカスタマイズする場合に既存のコードに新しいコードを追加することができるべきである。異なるＡＰＩを使用してコード全体を初めから書き直すことは任意選択であるべきである。）。例えば、システムメッセージ交換キュー集合コンポーネントにより、パスストリングをコンストラクタに渡し、送信メソッドをコールした後に、メッセージの送信が可能となる。メッセージ優先順位や暗号化アルゴリズムなどのメッセージプロパティは、コアシナリオにコードを追加することによってカスタマイズすることができる。
【００９８】
自己ドキュメントオブジェクトモデル
自己ドキュメントオブジェクトモデルは、オブジェクトおよびそのメンバを学習し、それを使用できるように、開発者がそれを観察することができるＡＰＩフレームワークを設計することに関係する。例えば、名前は、多くの開発者が学習することを望まない継承階層に専念するのではなく、タイプがどのように使用されると予想されるかに基づくことができる。手短に言えば、自己ドキュメントオブジェクトモデルにより、自称開発者による発見可能性が促進される。
【００９９】
上記で触れたように、一部の開発者は、試行錯誤でコーディングすることを好み、開発者の直観が開発者の所期のシナリオを実行することに失敗したときにだけドキュメントを読むことに頼る。したがって、自己ドキュメントオブジェクトモデルは、単純なタスクでさえも開発者が実行することを望むたびに開発者がドキュメントを読むことを要求することを避けるべきである。ここで説明する実装に関する比較的自己ドキュメント型の直感的ＡＰＩを生成する際の助けとなる例示的な１組の原理および慣例を以下に提示する。それらのうち１つまたは複数を、所与のＡＰＩおよび／またはＡＰＩ設計実装で利用することができる。
【０１００】
命名
第１の指導原理は、最も一般的なシナリオでユーザが使用する（例えばインスタンス化する）必要があるタイプに関して、単純で直感的な名前を確保することである。設計者はしばしば、大部分のユーザが気にする必要のないアブストラクションに関して最良の名前を「浪費」する。例えば、アブストラクトベースクラス「Ｆｉｌｅ」を命名し、次いで具象タイプ「ＸＹＺＦｉｌｅ」を与えることは、すべてのユーザがＡＰＩの使用を開始する前に継承階層を理解しなければならないと予想される場合にはうまく働く。しかし、ユーザが階層を理解していない場合、ユーザが最初に使用しようと試み、たいていは失敗する可能性の高い物は、「Ｆｉｌｅ」タイプである。より具体的には、トップコアシナリオを対象とする集合コンポーネントのために最も一般的または予想される名前が確保され、あまり一般的でない名前または聴き慣れない名前が、概念およびアブストラクションに対して使用される。
【０１０１】
第２の指導原理は、各メソッドが何を行うのか、および各タイプおよびパラメータが何を表すのかを明確に示す記述的識別子名を使用することである。例えば、ＡＰＩ設計者は、識別子名を選ぶ場合に、幾分冗長となることをためらうべきではない。例えば、「EventLog.DeleteEventSource (string source, string machineName)」は幾分冗長に見えるが、まず間違いなく正味で正のユーザビリティ値を有する。さらに、タイプおよびパラメータ名は、それが何を行うかを表すのではなく、タイプまたはパラメータが何を表すかを示す。メソッド名はメソッドが何を行うかを示す。もちろん、単純で明確なセマンティクスを有するメソッドにとって正確で冗長なメソッド名は容易である。このことは、複雑なセマンティクスを避けることが、追従すべき良い一般的設計原理であることの別の理由である。
【０１０２】
指導設計慣習は、ＡＰＩ仕様の検討および／またはテストの重要な一部として命名選択肢についての議論を含むべきである。例示的な考慮すべき点および質問には、以下が含まれる。大部分のシナリオが開始するタイプは何か、所与のシナリオを実装しようと試みる場合に大部分の人々がまず考えるのはどんな名前か、ユーザがまず考える共通タイプの名前は何か、例えば、「Ｆｉｌｅ」は、ファイルＩ／Ｏシナリオを扱う際に大部分の人々が考える名前であるので、ファイルにアクセスするための集合コンポーネントは「Ｆｉｌｅ」と命名することができる。加えて、最も一般的に使用するタイプの最も一般的に使用するメソッドおよびそのパラメータが、検討されテストされる。例えば、考慮中の特定のＡＰＩ設計ではなく、技術に通じている誰もが、こうしたメソッドを直ちに、正しく、容易に認識しコールすることができるか、である。
【０１０３】
例外
上記で示したように、例外は、自己ドキュメント型ＡＰＩを実行することができる。言い換えれば、ＡＰＩは、ユーザを、次に必要な事柄を行うよう導くべきであり、例外は、次に何が必要かを通信することができ、そうするのに優れている。例えば、以下のサンプルコードは、「「ＦｉｌｅＯｂｊｅｃｔ」を開こうと試みる前に「ＦｉｌｅＮａｍｅ」プロパティをセットする必要がある」というメッセージを有する例外を投じる。
【０１０４】
【表４】
2005129027.tif 000006
【０１０５】
強い型定義
直感的ＡＰＩを実行する別の指導原理は強い型定義である。例えば、「Ｃｕｓｔｏｍｅｒ．Ｎａｍｅ」をコールすることは、「Ｃｕｓｔｏｍｅｒ．Ｐｒｏｐｅｒｔｉｅｓ［‘Ｎａｍｅ’］」をコールすることよりも容易である。さらに、このような「Ｎａｍｅ」プロパティに名前を文字列として返されることは、プロパティがオブジェクトを返す場合よりも便利である。
【０１０６】
文字列ベースのアクセス機構を有するプロパティバッグ、レートバインドコール、および他の強い型ではないＡＰＩが望ましい場合があるが、それらは珍しいものとして退けられ、通例ではない。さらに、ＡＰＩ設計者は、ユーザが強く型付けされていないＡＰＩ層に対して実行するより一般的なオペレーションのために、強く型付けされたヘルパを提供することができる。例えば、顧客タイプは、プロパティバッグを有することができるが、「ｎａｍｅ」、「ａｄｄｒｅｓｓ」などのより一般的なプロパティに対して強く型付けされたＡＰＩを追加で提供することができる。
【０１０７】
簡潔さに向けたベクタリング
さらに別の指導原理は、特にコアシナリオに対して簡潔さを求めるよう試みることである。標準的設計方法は、アブストラクションを使用することなどによって保守性に関して最適化される設計を生成することを目標とする。したがって、現在の設計方法は、多数のアブストラクションを生成する。問題は、このような設計方法が、単純なシナリオであっても実装を開始する前には、得られる設計のユーザがエキスパートとなるという想定のもとに運用されることである。しかし、このことはしばしば現実世界では当てはまらない。
【０１０８】
ここで説明する実装では、少なくとも単純なシナリオについて、ＡＰＩ設計者により、機能エリア全体がどのように互いに調和され、または相互運用されるかを理解しなくても、オブジェクトモデル階層を使用することができるようにオブジェクトモデル階層が十分に単純であることが保証される。結果として得られる良く設計されたＡＰＩは、開発者が、実装されるコアシナリオを理解していることを必要とすることがあるが、実装するのに使用されるライブラリの設計を完全に理解している必要はない。
【０１０９】
一般に、コアシナリオＡＰＩは、アブストラクションではなく、システムの物理的部分または周知の論理的部分に向けられ、またはそれに対応する。アブストラクションに対応するタイプは通常、機能エリアのすべての部分がどのように互いに調和され、相互運用されるかを理解せずに使用することは困難である。したがってそれは、機能間統合が必要な場合により重要である。
【０１１０】
別の指導慣習は、コアシナリオまたは共通シナリオ（例えば、集合コンポーネントを有するシナリオ）についてのＡＰＩを設計する場合にではなく、内部アーキテクチャとファクタードタイプの一部とを設計する場合に、標準設計方法（例えばＵＭＬ）を使用することである。コアシナリオに対して集合コンポーネントを設計する場合、その代わりに、シナリオ駆動設計と共に、プロトタイピング、ユーザビリティスタディ、および反復（本明細書の上記で説明した）を使用する。
【０１１１】
クリーンな名前空間
さらに別の指導原理は、（非常に）稀にしか使用されないタイプが、主名前空間が乱雑となるのを避けるためにサブネームスペースに配置されることである。例えば、許可タイプと設計タイプの２つのグループをその主名前空間から分離することができる。例えば、許可タイプは、「．Ｐｅｒｍｉｓｓｉｏｎｓ」サブネームスペースに常駐することができ、ｄｅｓｉｇｎ−ｔｉｍｅ−ｏｎｌｙタイプは、「．Ｄｅｓｉｇｎ」サブネームスペースに常駐することができる。
【０１１２】
図１〜９のアクション、態様、機能、コンポーネントなどは、複数のブロックに分割された図に示される。しかし、図１〜９を説明および／または図示する順序、相互接続、相関関係、レイアウトなどを限定とみなすことは意図されず、ＡＰＩを設計するために１つまたは複数のシステム、方法、デバイス、手順、媒体、ＡＰＩ、装置、構成などを実装する目的で、任意の方式で、任意の数のブロックを修正、結合、再構成、増大、省略などを行うことができる。さらに、本明細書の説明は特定の実装（および図１０の例示的動作環境）への参照を含むが、図示および／または説明する実装は、どんな適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せで実装することができ、どんな適切なソフトウェアアーキテクチャ、コーディング言語、シナリオ定義、ユーザビリティスタディフォーマットなどを使用しても実装することができる。
【０１１３】
コンピュータまたはその他のデバイスに関する例示的動作環境
図１０に、本明細書で説明するＡＰＩを設計するために、少なくとも１つのシステム、デバイス、装置、コンポーネント、構成、プロトコル、手法、方法、手順、媒体、ＡＰＩ、それらの何らかの組合せを（完全に、または部分的に）実装することができる例示的コンピューティング（一般的デバイス）動作環境１０００を示す。動作環境１０００は、以下で説明するコンピュータおよびネットワークアーキテクチャで使用することができる。
【０１１４】
例示的動作環境１０００は、環境の一例に過ぎず、適用可能デバイス（コンピュータ、ネットワークノード、エンターテイメントデバイス、モバイルアプライアンス、一般的電子デバイスなどを含む）アーキテクチャの使用法または機能の範囲に関して何らかの制限を示唆するものではない。図１０に図示する構成要素のうちのいずれか１つ、あるいはそれらの任意の組合せに関する何らかの依存関係または要件を動作環境１０００（またはそのデバイス）が有すると解釈すべきでもない。
【０１１５】
加えて、ＡＰＩの設計および／またはそれから得られるＡＰＩは、多数の他の汎用／特殊目的デバイス（コンピューティングシステムを含む）環境／構成と共に実行可能である。使用するのに適した周知のデバイス、システム、環境、および／または構成の例には、限定はしないが、パーソナルコンピュータ、サーバコンピュータ、シンクライアント、シッククライアント、パーソナルデジタルアシスタント（ＰＤＡ）または携帯電話、腕時計、ハンドヘルド／ラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル消費者向け電子機器、ビデオゲームマシン、ゲームコンソール、ポータブル／ハンドヘルドゲームユニット、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、ネットワークノード、ならびに上記のシステムまたはデバイスのいずれか、その何らかの組合せなどを含む分散／マルチプロセッシングコンピューティング環境などが含まれる。
【０１１６】
ＡＰＩの設計および／またはそれから得られるＡＰＩに関する実装は、プロセッサ実行可能命令の一般的状況で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行および／または可能にし、および／または特定の抽象データタイプを実装するルーチン、プログラム、モジュール、プロトコル、オブジェクト、インターフェース、コンポーネント、データ構造などを含む。本明細書のある実装で説明したＡＰＩの設計および／またはそれから得られるＡＰＩは、通信リンクリンクおよび／またはネットワークを介して接続されるリモートリンク処理装置によってタスクが実行される分散処理環境でも実行および／または存在することができる。排他的ではないが特に分散コンピューティング環境では、プロセッサ実行可能命令は、別々の記憶媒体に配置することができ、異なるプロセッサで実行することができ、および／または伝送媒体を介して伝搬することができる。
【０１１７】
例示的動作環境１０００は、コンピュータ１００２の形態の汎用コンピューティング装置を含む。コンピュータ１００２は、コンピューティング／処理能力を有する任意の（例えば電子）デバイスを備えることができる。コンピュータ１００２の構成要素には、限定はしないが、１つまたは複数のプロセッサまたは処理装置１００４と、システムメモリ１００６と、プロセッサ１００４を含む様々なシステム構成要素をシステムメモリ１００６に結合するシステムバス１００８とを含めることができる。
【０１１８】
プロセッサ１００４は、形成される材料またはその中で使用される処理機構によって限定されない。例えば、プロセッサ１００４は、半導体および／またはトランジスタ（例えば電子集積回路（ＩＣ））から構成することができる。このような状況では、プロセッサ実行可能命令は、電子的実行可能命令でよい。代替として、プロセッサ１００４の機構またはプロセッサ１００４用の機構、すなわちコンピュータ１００２の機構またはコンピュータ１００２用の機構は、限定はしないが、量子コンピューティング、光コンピューティング、（例えば、ナノテクノロジーを用いた）機械コンピューティングなどを含むことができる。
【０１１９】
システムバス１００８は、メモリバスまたはメモリコントローラ、ポイントツーポイント接続、スイッチングファブリック、周辺バス、アクセラレーテッドグラフィックスポート、プロセッサ、または様々なバスアーキテクチャのうちのいずれかを使用するローカルバスを含む、多くのタイプの有線または無線バス構造のうちの任意の１つまたは複数を表す。例えば、そのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バス、それらの何らかの組合せなどを含めることができる。
【０１２０】
コンピュータ１００２は通常、様々なプロセッサアクセス可能媒体を含むことができる。このような媒体は、コンピュータ１００２または他の（例えば電子）デバイスによってアクセス可能である入手可能などんな媒体でもよく、それには揮発性媒体と不揮発性媒体の両方、取外し可能媒体と取外し不能媒体の両方、記憶媒体と伝送媒体の両方が含まれる。
【０１２１】
システムメモリ１００６は、ランダムアクセスメモリ（ＲＡＭ）１０４０などの揮発性メモリおよび／または読取り専用メモリ（ＲＯＭ）１０１２などの不揮発性メモリの形態のプロセッサアクセス可能記憶媒体を含む。起動中などにコンピュータ１００２内の要素間で情報を転送する助けになる基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１０１４が、一般にＲＯＭ１０１２内に格納される。ＲＡＭ１０１０は一般に、処理装置１００４にとって即座にアクセス可能であり、および／または処理装置１００４によって現在操作されているデータおよび／またはプログラムモジュール／命令を含む。
【０１２２】
コンピュータ１００２はまた、他の取外し可能／取外し不能および／または揮発性／不揮発性コンピュータ記憶媒体も含むことができる。例えば、図１０に、（通常は）取外し不能不揮発性磁気媒体（別々には図示せず）を読み書きするハードディスクドライブまたはディスクドライブアレイ１０１６と、（通常は）取外し可能不揮発性磁気ディスク１０２０（例えば「フロッピー（登録商標）ディスク」）を読み書きする磁気ディスクドライブ１０１８と、ＣＤ、ＤＶＤ、その他の光媒体などの（通常は）取外し可能不揮発性光ディスク１０２４を読み書きする光ディスクドライブ１０２２とを示す。ハードディスクドライブ１０１６、磁気ディスクドライブ１０１８、および光ディスクドライブ１０２２はそれぞれ、１つまたは複数の記憶媒体インターフェース１０２６によってシステムバス１００８に接続される。代替として、ハードディスクドライブ１０１６、磁気ディスクドライブ１０１８、および光ディスクドライブ１０２２は、１つまたは複数の他の別々のインターフェースまたは組み合わせたインターフェース（図示せず）によってシステムバス１００８に接続することもできる。
【０１２３】
ディスクドライブおよびその関連するプロセッサアクセス可能媒体は、コンピュータ１００２に関するデータ構造、プログラムモジュール、およびその他のデータなどのプロセッサ実行命令の不揮発性記憶を実現する。例示的コンピュータ１００２は、ハードディスク１０１６、取外し可能磁気ディスク１０２０、および取外し可能光ディスク１０２４を示すが、磁気カセットまたはその他の磁気記憶装置、フラッシュメモリ、コンパクトディスク（ＣＤ）、デジタルバーサタイルディスク（ＤＶＤ）、またはその他の光ストレージ、ＲＡＭ、ＲＯＭ、電気消去可能プログラマブル読取り専用メモリ（ＥＥＰＲＯＭ）などのその他のタイプのプロセッサアクセス可能媒体が、デバイスによってアクセス可能な命令を格納できることを理解されたい。このような媒体には、いわゆる特殊目的／ハードワイヤドＩＣチップも含めることができる。言い換えれば、任意のプロセッサアクセス可能媒体を使用して、例示的動作環境１０００の記憶媒体を実現することができる。
【０１２４】
一般的な例としてオペレーティングシステム１０２８、１つまたは複数のアプリケーションプログラム１０３０、他のプログラムモジュール１０３２、およびプログラムデータ１０３４を含む任意の数のプログラムモジュール（あるいはＡＰＩフレームワークおよび／またはそれに基づくオブジェクトを含むその他のユニットまたは命令／コードの組）を、ハードディスク１０１６、磁気ディスク１０２０、光ディスク１０２４、ＲＯＭ１０１２、および／またはＲＡＭ１０４０上に格納することができる。
【０１２５】
ユーザは、キーボード１０３６やポインティングデバイス１０３８（例えば「マウス」）などの入力装置を介して、コマンドおよび／または情報をコンピュータ１００２に入力することができる。他の入力装置１０４０（具体的には図示せず）には、マイクロフォン、ジョイスティック、サテライトディッシュ、シリアルポート、および／またはスキャナなどを含めることができる。上記およびその他の入力装置は、システムバス１００８に結合されるユーザ入出力インターフェース１０４２を介して処理装置１００４に接続される。しかし、その代わりに、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）ポート、赤外線ポート、ＩＥＥＥ１３９４（「Ｆｉｒｅｗｉｒｅ」）インターフェース、ＩＥＥＥ８０２．１１無線インターフェース、Ｂｌｕｅｔｏｏｔｈ（登録商標）無線インターフェースなどのその他のインターフェースおよびバス構造によって入力装置および／または出力装置を接続することもできる。
【０１２６】
モニタ／ビュー画面１０４４またはその他のタイプのディスプレイ装置もまた、ビデオアダプタ１０４６などのインターフェースを介してシステムバス１００８に接続することができる。ビデオアダプタ１０４６（または別の構成要素）は、グラフィックスに集中する計算を処理し、要求の厳しい表示要件を処理するグラフィックスカードでよく、またはそれを含むことができる。通常は、グラフィックスカードは、迅速なグラフィックスの表示およびグラフィックスオペレーションの性能を促進するためにグラフィックス処理装置（ＧＰＵ）、ビデオＲＡＭ（ＶＲＡＭ）などを含む。モニタ１０４４に加えて、他の出力周辺装置には、スピーカ（図示せず）やプリンタ１０４８などの構成要素も含めることができ、その周辺出力装置は、入出力インターフェース１０４２を介してコンピュータ１００２に接続することができる。
【０１２７】
コンピュータ１００２は、リモートコンピューティング装置１０５０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク環境で動作することができる。例えば、リモートコンピューティング装置１０５０は、パーソナルコンピュータ、ポータブルコンピュータ（例えばラップトップコンピュータ、タブレットコンピュータ、ＰＤＡ、移動局など）、パームコンピュータまたはポケットサイズのコンピュータ、腕時計、ゲームデバイス、サーバ、ルータ、ネットワークコンピュータ、ピアデバイス、別のネットワークノード、または上記で列挙したその他のデバイスタイプなどでよい。しかし、リモートコンピューティングデバイス１０５０を、コンピュータ１００２に関して本明細書で説明した要素および機能のうち多くまたはすべてを含むことができるポータブルコンピュータとして示す。
【０１２８】
コンピュータ１００２とリモートコンピュータ１０５０との間の論理接続を、ローカルエリアネットワーク（ＬＡＮ）１０５２および一般的広域ネットワーク（ＷＡＮ）１０５４として示す。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネット、固定／携帯電話ネットワーク、アドホック／インフラストラクチャ無線ネットワーク、その他の無線ネットワーク、ゲームネットワーク、それらの何らかの組合せなどで一般的なものである。このようなネットワークおよび通信接続は、伝送媒体の例である。
【０１２９】
ＬＡＮネットワーキング環境で実装する場合、コンピュータ１００２は通常、ネットワークインターフェース／アダプタ１０５６を介してＬＡＮ１０５２に接続される。ＷＡＮネットワーキング環境で実装する場合、コンピュータ１００２は一般に、ＷＡＮ１０５４を介して通信を確立するためのモデム１０５８またはその他の構成要素を含む。モデム１０５８は内蔵でも外付けでもよく、入出力インターフェース１０４２またはその他の適切な機構を介してシステムバス１００８に接続することができる。図示するネットワーク接続は例示的なものであって、コンピュータ１００２と１０５０の間の通信リンクを確立するその他の手段も使用できることを理解されたい。
【０１３０】
動作環境１０００で示すようなネットワーク環境では、コンピュータ１００２に関して示すプログラムモジュールまたはその他の命令、あるいはその一部は、リモート媒体記憶装置内に完全にまたは部分的に格納することができる。例えば、リモートアプリケーションプログラム１０６０は、リモートコンピュータ１０５０のメモリコンポーネント上に常駐するが、コンピュータ１００２を介して使用可能であり、またはコンピュータ１００２を介してアクセス可能である。さらに、例示のために、オペレーティングシステム１０２８などのアプリケーションプログラム１０３０およびその他のプロセッサ実行可能命令を本明細書では離散的ブロックとして示したが、このようなプログラム、コンポーネント、その他の命令が様々な時にコンピューティング装置１００２（および／またはリモートコンピューティング装置１０５０）の様々な記憶構成要素に常駐し、コンピュータ１００２のプロセッサ１００４（および／またはリモートコンピューティング装置１０５０のプロセッサ）によって実行されることを理解されたい。
【０１３１】
システム、媒体、デバイス、方法、手順、装置、技法、ＡＰＩ、スキーム、手法、手順、構成、およびその他の実装を、構造的、論理的、アルゴリズム的、機能的、およびアクションベースの機能および／または図に特有の言葉で説明したが、添付の特許請求の範囲で定義される発明は、ここで説明した特定の機能または図に必ずしも限定されないことを理解されたい。むしろ、特定の機能および図は、特許請求の範囲に記載の発明を実装する例示的形態として開示される。
【図面の簡単な説明】
【０１３２】
【図１】２つの異なるフレームワークに関する従来のＡＰＩ学習曲線のグラフを示す図である。
【図２】２つの異なるレベルアブストラクションに関する例示的な漸進的ＡＰＩ学習曲線のグラフを示す図である。
【図３】ＡＰＩに関する例示的設計原理／慣習を示す図である。
【図４】機能エリアごとにＡＰＩを設計する例示的技法を示す流れ図である。
【図５】コアシナリオごとにＡＰＩを設計する例示的スキームを示すブロック図である。
【図６】２つの異なる目的を対象とする例示的コンポーネントタイプ間の潜在的不一致を示す図である。
【図７】２つの異なる目的をカバーするように拡張可能および／または相互動作可能に設計されたコンポーネントタイプ間の例示的関係を示す図である。
【図８】２つの異なる目的を２層ＡＰＩで処理する例示的集合コンポーネント（ＡＣ）および関連するファクタードタイプ（ＦＴ）を示す図である。
【図９】ｃｒｅａｔｅ−ｓｅｔ−ｃａｌｌ使用パターンをサポートすることができる例示的集合コンポーネントおよび関連するＡＰＩを示す図である。
【図１０】本明細書で説明するＡＰＩを設計および／または使用する少なくとも１つの態様を（完全に、または部分的に）実装することができる例示的コンピューティング（一般的デバイス）動作環境を示す図である。
【符号の説明】
【０１３３】
１０１  ＡＰＩ学習曲線のグラフ
２００  漸進的ＡＰＩ学習曲線のグラフ
３００  表
３０２  シナリオ駆動設計
３０４  コンポーネント指向設計
３０６  カスタマイズ可能デフォルト
３０８  自己ドキュメントオブジェクトモデル
【図１】
2005129027.tif 000007
【図２】
2005129027.tif 000008
【図３】
2005129027.tif 000009
【図４】
2005129027.tif 000010
【図５】
2005129027.tif 000011
【図６】
2005129027.tif 000012
【図７】
2005129027.tif 000013
【図８】
2005129027.tif 000014
【図９】
2005129027.tif 000015
【図１０】
2005129027.tif 000016