JP2008537831A - アプリケーションのユーザインターフェースの仕様作成方法および仕様作成システム - Google Patents

Abstract

アプリケーションの仕様書を作成および／または変更するシステムおよび方法である。仕様書に取り込むべきデータはデータベースに記憶される。このデータは、概念モデルに従ってデータベースに記憶され、この概念モデルにより、仕様書作成アプリケーションは、一連のデータベースクエリを作成することで、仕様書を作成することができる。データがデータベースに記憶されるので、特定のデータ要素に対する変更は一回のみ行うだけでよく、それにより仕様書の維持が簡略化され、仕様書の正確性が増す。

Description

様々な実施形態は、コンピュータにより実装される方法およびシステムに関し、より詳細には、ソフトウェアアプリケーションのユーザインターフェースに関する仕様を作成するためのコンピュータにより実装される方法およびシステムに関する。

ソフトウェアアプリケーションの開発者は一般に、アプリケーションの機能、設定、インターフェース等の仕様を規定する仕様書を書く。次いで、プログラマはこの仕様書を使用して、アプリケーションを実装するコードを記述することができ、そのアプリケーションと相互運用可能なアプリケーションを記述している他の開発者は、この仕様書を使用することができる。

アプリケーションは、多数の（何百もの、ときには何千もの）様々な特徴、機能、設定、および他の関連データを有する場合があるので、アプリケーションの仕様書を書くことは、複雑な作業である場合がある。仕様書を書く者は、この情報全てを追跡し続けなければならない。さらに、仕様書は一般に何回か改訂され、情報の要素（例えば、ラベル、範囲、プロパティ等）が仕様書全体に渡って改訂される必要がある。従って、仕様書を維持することは困難な作業でもあり得る。

説明する様々な実施形態の側面に従うと、アプリケーションの仕様書を作成し維持するためのシステムおよび方法が提供される。一側面において、仕様書に取り込むべきデータはデータベースに記憶される。データは概念モデル（conceptual model）に従ってデータベースに記憶され、その概念モデルにより、仕様書作成アプリケーションは、データベースに対する一連のクエリを作成することで、仕様書を作成することができる。データはデータベースに記憶されるので、特定のデータ要素に対する変更は一回のみ行うだけでよく、それにより仕様書の維持が簡略化され、仕様書の正確性が増す。

別の側面において、アプリケーションの仕様書を作成し維持するためのシステムおよび方法は、仕様書作成におけるワークフローを管理するメカニズムを含む。例えば、どのユーザが仕様書に関する所定の作業の実行権限を有するか、どのユーザが承認を必要とするか、どのユーザがレビューを受けるか等を制御するメカニズムをシステムに含めることができる。

さらに別の側面において、アプリケーションの仕様書を作成し維持するためのシステムおよび方法は、ウェブサービスモデルに組み込むことができ、それにより、複数のユーザが仕様書の作成に取り掛かること、および複数のユーザが外部ネットワークから仕様書にアクセスすることが可能となる。

制限的なものでも排他的なものでもない実施形態について、図面を参照しながら説明する。図面において、明記しない限りは、様々な図で類似した参照番号は類似した部分を指す。

以下において、本明細書の一部を形成する添付図面を参照しながら、諸実施形態についてより詳細に説明する。しかしながら、実施形態は、多数の異なる形態で実装することができ、本明細書で説明する実施形態に限定されるものと解釈すべきではない。むしろ、これらの実施形態は、本開示が綿密かつ完全であって、当業者に本発明の範囲を完全に伝えるために提供されるものである。実施形態は、方法、システムまたは装置として実行することができる。従って、実施形態は、完全なハードウェアによる実装、完全なソフトウェアによる実装、またはソフトウェアおよびハードウェアの態様を組み合わせた実装の形態を取ることができる。従って、以下の詳細な説明を、限定的な意味として理解すべきではない。

様々な実施形態の論理演算処理は、（１）コンピューティングシステム上で実行されるコンピュータにより実装される一連のステップとして、および／または（２）コンピューティングシステム内で相互接続したマシンモジュールとして実装される。実装は、実施形態を実行するコンピューティングシステムのパフォーマンス要件に依存する選択の問題である。従って、本明細書で説明する実施形態を構成する論理演算処理は代替的に、演算、ステップまたはモジュールと呼ばれる。

実施形態は、コンピュータプロセス、（モバイルハンドヘルドデバイスを含む）コンピューティングシステム、またはコンピュータプログラム製品のような製造品として実施することができる。コンピュータプログラム製品は、コンピュータ記憶媒体とすることができ、コンピュータ記憶媒体は、コンピュータシステムにより読み取り可能であって、コンピュータプロセスを実行するための命令から成るコンピュータプログラムを符号化する。コンピュータプログラム製品はまた、コンピューティングシステムにより読み取り可能であって、コンピュータプロセスを実行するための命令から成るコンピュータプログラムを符号化する、キャリア上で伝送される信号であってもよい。

図１は、例示的な実施形態に従う、仕様書の概念モデル１００を示している。この実施形態において、モデル１００は、１つまたは複数のページ１０２を有するユーザインターフェース（ＵＩ：User Interface）仕様書を表し、各ページは、１つまたは複数の設定１０４を有する。ページ１０２は、ＵＩ仕様書のページではなく、ＵＩ自体におけるページであり、別途状況に応じて、または具体的に明記しない限り、“ページ”という用語は、仕様書のページではなく、ＵＩのページを指すものと意図している。各設定は、ユーザインターフェースコントロール（例えば、テキストボックス）に対応し、ユーザインターフェースコントロールは、機能構成におけるプロパティ、またはモニタリングシステムからの値のいずれかに対応する。この状況で使用される機能は、ＵＩを介してユーザが利用できるアプリケーションの機能または能力である。この状況で使用されるモニタリングシステムの値は、アプリケーションの一側面のランタイム値である。例えば、“モニタリング”値は、アプリケーションにより生成されたイベントに対応する値、またはそのイベントにより定義された値とすることができる。モニタリング値の別の例は、アプリケーションが使用しているＣＰＵ帯域の割合とすることができる。

設定１０４に加えて、ページ１０２は、ページ間の関連付けを定義する１つまたは複数のタスク１０６を有する。タスクにより、ユーザは、あるページから別のページに移動することができるという点で、タスクは誘導的なものと言うことができる。さらに、タスクは、より複雑である場合があり、ページ間の移動に加えて、ユーザ入力を要求することもできる。例えば、タスクのセットは、ウィザード（例えば、相対的に複雑な操作を実行したり、ある機能を使用したり、あるいはモジュールまたはドライバを構成したりする際にユーザを誘導するアプリケーション内の対話ユーティリティ等）を実装することができる。タスクはまた、ユーザがＵＩを介してアプリケーションに実行を求めることができるアクション（例えば、保存、変更のキャンセル、印刷、データ表示の変更等）に対応することができる。

図２は、例示的な実施形態に従う、アプリケーションの仕様書を作成し維持するシステム２００を示している。この実施形態において、システム２００は、入力インターフェース２０２、仕様書データベース２０４、および仕様書ジェネレータ（specification generator）２０６を備えている。

一実施形態において、入力インターフェース２０２は、仕様書内に含められるべきデータをユーザが入力できるようにするアプリケーションである。このデータには、アプリケーション内で実装されるべき機能、当該機能に関連付けられた設定、当該機能に関連付けられたページ、ページに関連付けられたタスク、アプリケーションのモニタリング値等が含まれる。１人または複数人のユーザは、入力インターフェース２０２を使用して、アプリケーションの仕様書にデータを入力／編集することができる。一実施形態において、入力インターフェース２０２は、例えば、ワシントン州レドモンドを本拠とするＭｉｃｒｏｓｏｆｔ社から入手可能なＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）等のウェブブラウザを使用して実装される。

仕様書データベース２０４は、アプリケーションの仕様書のデータを記憶するために使用され、そのデータは、入力インターフェース２０２を介して１人または複数人のユーザにより提供される。この実施形態において、仕様書データベース２０４は、概念モデル１００（図１）に従ってデータを記憶する。例えば、仕様書データベース２０４は、概念モデル１００を実装するリレーショナルデータベースとすることができる。概念モデル１００の上記実装の１つについて、図３を参照して、以下で説明する。一実施形態において、仕様書データベース２０４は、Ｍｉｃｒｏｓｏｆｔ社から入手可能なＭｉｃｒｏｓｏｆｔ（登録商標） ＳＱＬ Ｓｅｒｖｅｒ（登録商標）を使用して実装される。他の実施形態では、仕様書データベース２０４は、概念モデル１００を実装するように構成されたオブジェクト指向データベースまたは任意の適切なタイプのデータベースとすることができる。

仕様書ジェネレータ２０６は、ユーザが仕様書データベース２０４から仕様書のデータを抽出し、その抽出されたデータを含む仕様書を出力できるようにするアプリケーションである。一実施形態において、仕様書ジェネレータ２０６は、概念モデルを使用して、特定のデータを抽出するための仕様書データベース２０４のクエリを作成し、所望の仕様書フォーマットに従う仕様書の作成を容易にする。従って、１人または複数人のユーザ（必ずしも仕様書データを入力したユーザである必要はない）は、仕様書ジェネレータ２０６を使用して、アプリケーションの仕様書を作成することができる。一実施形態において、仕様書ジェネレータ２０６は、Ｍｉｃｒｏｓｏｆｔ社が開発したＡＳＰ．ＮＥＴフレームワークを使用して実装された一連のページとして実装される。

システム２００は、ワークフロー機能（不図示）も含んでおり、仕様書データベース２０４へのデータ入力方法および仕様書データベース２０４からのデータ表示方法を制御することができる。ワークフローデータは、機能に関連付けられた設定や仕様書に正式に機能を取り込むのに必要な承認等を変更するために、どのような権限が必要であるかを定義することができる。いくつかの実施形態では、仕様書データベース２０４は、ワークフローを定義するメタデータを含み、仕様書データベース２０４は、そのメタデータを強制する（例えば、データ入力／編集拒否権限、データ表示拒否権限等）。いくつかの実施形態では、権限は、個々のＵＩ設計者／作成者に与えられる。例えば、特定の作成者は、選択された外国語におけるフィールドラベル名を入力／編集する（即ち、英語名を対応する外国語のフィールドラベル名に翻訳する）権限しか有することができない。いくつかの実施形態では、ワークフロー機能は、それが不要もしくは望まれないシステムでは省略される。

図３は、例示的な実施形態に従う、概念モデル１００（図１）を実装するために使用されるリレーショナルデータベースのテーブル３００を示している。この実施形態において、データベースは、機能テーブル３０１、ページテーブル３０２、ページ設定テーブル３０３、および設定テーブル３０５を含む。

機能テーブル３０１は、仕様書のデータが記憶されるべきアプリケーションの機能のリストを含む。この実施形態において、機能テーブル３０１は、機能の識別子（機能識別子）に関する列、および機能の名前（機能名）に関する列を含む。機能名は、ユーザが容易に読んで理解できる点で、“ユーザフレンドリ”であるのに対し、機能識別子は、機能に対する一意な識別子であって、その一意な識別子は、単語または名前を詳しく示す必要はない。

ページテーブル３０２は、機能によって構成されるページのリストを含む。この実施形態において、ページテーブル３０２は、ページの識別子（ページ識別子）に関する列、ページが関係する機能への参照（機能参照）に関する列、ページの名前（ページ名）に関する列、およびページのスクリーンショットへの参照（スクリーンショット参照）に関する列を含む。ページ識別子は、ページに対する一意な識別子である。機能参照列は、機能テーブル３０１における機能とのリレーションを含む。ページ名は、ページに対する“ユーザフレンドリ”な名前である。スクリーンショット参照は、仕様書に含まれるべきページのスクリーンショットの位置に対するポインタを含む。

ページ設定テーブル３０３は、各ページに含まれる設定のリストを含む。この実施形態において、ページ設定テーブル３０３は、設定の識別子（設定識別子）に関する列、設定が関係するページへの参照（ページ参照）に関する列、シーケンス番号に関する列、および設定への参照（設定参照）に関する列を含む。設定識別子は、設定に対する一意な識別子である。ページ参照は、ページテーブル３０２におけるページとのリレーションを含む。シーケンス番号は、設定がページ上で表示されるべき順番または順序を決定するために使用される。設定参照は、設定テーブル３０５における設定とのリレーションを含む。

設定テーブル３０５は、アプリケーションにおける全設定のリストを含む。この実施形態において、設定テーブル３０５は、設定の識別子（設定識別子）に関する列、設定の名前（設定名）に関する列、フィールドラベルに関する１つまたは複数の列（即ち、仕様書を作成することができる各言語に対応する）、ツールチップに関する１つまたは複数の列（即ち、仕様書を作成することができる各言語に対応する）、設定のコントロールタイプに関する列、設定のデフォルト値に関する列、設定の有効値に関する列、および設定のプロパティに関する列を含む。設定識別子および設定名は、ページ設定テーブル３０３に関して上述した通りである。フィールドラベルは、ＵＩ内の設定の近傍に現れる（特定の言語の）テキストを含む。ツールチップは、マウスが設定上を通るときに現れる（特定の言語の）テキストである。コントロールタイプは、設定値を表すために使用されるＵＩコントロール（例えば、テキストボックス、ボタン、スライド等）のタイプを含む。デフォルト値は、ユーザが値を入力しない場合の設定値を含む。有効値は、その設定に対して有効な値の範囲またはリスト（例えば、数値範囲や、“ｙｅｓ”または“ｎｏ”等）を含む。現在値は、機能構成システムにおいて参照される設定値を含む。

概念モデル１００を実装するリレーショナルデータベースのテーブルの一部について上述したが、他の実施形態では、より多数のテーブルを使用して、概念モデルを実装することができる。

図３Ａは、一実施形態に従う、概念モデル１００を実装するのに使用できるリレーショナルデータベースのスキーマ３１０を示すＥＲ図である。このリレーショナルデータベースは、テーブル３００（図３）と比べて更なるテーブルを有するが、このデータベースも概念モデルを実装する。この実施形態において、スキーマ３１０は、仕様書エンティティ３１２、機能エンティティ３１４、タスクエンティティ３１６、ページエンティティ３２０、および設定エンティティ３２４を含む。図３ＡのＥＲ図は、完全性のために、各エンティティの属性と、他のエンティティとの間のリレーションとを定義しているが、一実施形態に従うこれらのエンティティについて以下で説明する。これらのエンティティの各々は、“識別子”と示された一意な識別子を有し、この識別子は、必要に応じて他のエンティティにより参照される。

この実施形態において、仕様書エンティティ３１２は、作成者、日付等のようなＵＩ仕様書に関する一般情報、および機能の一意な識別子に対する参照のリストを記憶するために使用される。この参照のリストは、仕様書が作成されるときに表示されることになる順番で仕様書に含まれる。これを“機能の順序リスト”と表す。

この実施形態において、機能エンティティ３１４は、アプリケーションの機能に関する情報を記憶するために使用される。機能エンティティの目的は、ユーザインターフェースにおいて、顧客が理解できるように、関連するタスクをグループ化することである。この実施形態において、機能エンティティ３１４は、“名前”と示された、機能に対するユーザフレンドリな名前を記憶するための属性と、機能を構成するユーザインターフェースタスクの一意な識別子に対する参照のリストとを含む。（ユーザインターフェース内で表示される順番の）この参照のリストを“タスクの順序リスト”と表す。

タスクエンティティ３１６は、タスクに関する情報を記憶するために使用される。この実施形態において、タスクエンティティ３１６は、特定のタスクに対して記憶する以下の属性を含む。
（ａ）“内部名”と示された、（コードにより内部的に使用される）タスクのユーザフレンドリな名前；
（ｂ）“英語ラベル”と示された、タスクをラベル付けしてＵＩ内で表示される英語のテキスト（他の実施形態では、他言語でのラベルに対する属性とすることもできる）；および
（ｃ）機能毎に表示されるユーザインターフェースページの一意な識別子に対する参照のリスト。このリストは、ユーザインターフェース内でページが表示される順序を示すように順序付けられる。タスクは少なくとも１つのユーザインターフェースページを有する。タスクが、ユーザインターフェースウィザードを使用することにより実行される場合、ページが順番に顧客に提示されることになり、ページ数、およびページの順序は、このリストにおいて定義される。このリストを“ページの順序リスト”と表す。

ページエンティティ３２０は、ＵＩ仕様書において使用されるページに関する情報を記憶するために使用される。この実施形態において、ページエンティティ３２０は以下の属性を含む。
（ａ）“英語名”と示された、ＵＩ内で表示されるページをラベル付けする英語のテキスト（他の実施形態では、他言語での名前に対する属性とすることもできる）；および
（ｂ）“設定の順序リスト”と示された、ページ上に表示される設定の一意な識別子に対する参照のリスト。このリストは、設定がユーザインターフェースページ上に（一般的には上から下に）表示される順序を定義するように順序付けられる。設定は一般に、ラベルおよびユーザインターフェースコントロールのリストとして表示される。この順序は、タブシーケンスを定義するために使用される順序でもある。タブシーケンスとは、顧客がコンピュータのキーボード上で“Ｔａｂ”キーを押下する度に、カーソルフォーカスがユーザインターフェースページ上で変化する順序のことである。

設定エンティティ３２４は、ページ上における個々のユーザインターフェースコントロールを表し、この実施形態においては、記憶される以下の属性を含む。
（ａ）“内部名”と示された、（コードにより内部的に使用される）設定のユーザフレンドリな名前；
（ｂ）“英語ラベル”と示された、設定をラベル付けしてＵＩ内で表示する英語のテキスト（他の実施形態では、他言語でのラベルとすることもできる）；
（ｃ）“型”と示された、設定毎に使用されるデータに対して定義されたデータ型（例えば、ブーリアン、ストリング等）；
（ｄ）“デフォルト値”と示された、ＵＩのユーザにより変更可能な設定に対して自動的に入力される値；
（ｅ）“有効値”と示された、設定が有効に有することが可能な値の範囲；
（ｆ）“英語ツールチップ”と示された、ユーザがカーソルを動かして、設定上を通過させたときに現れる英語のテキスト（他の実施形態では、他言語でのツールチップとすることもできる）；
（ｇ）“ＵＩコントロールタイプ”と示された、ＵＩコントロール（例えば、ボタン、スライド等）のタイプを示す値；および
（ｈ）“現在値のソース”と示された、設定（例えば、データベース内のテーブルの列名、または構成システム内の変数名）に関連付けられているデータベースシステムに記憶された情報への参照。

一実施形態に従う、上記のエンティティ間のリレーションについて以下で説明する。仕様書エンティティ３１２では、仕様書における“機能の順序リスト”属性の各インスタンスは、機能エンティティ３１４において定義された少なくとも１つの機能“識別子”のインスタンスとリレーションを有さなければならない。即ち、各仕様書は１つまたは複数の機能（即ち、必須の１対多リレーション）を有さなければならない。

機能エンティティ３１４では、機能における“タスクの順序リスト”属性の各インスタンスを、タスクエンティティ３１６におけるタスク“識別子”属性の１つまたは複数のインスタンスと関連付けることができる。即ち、各機能は、少なくとも１つのタスクを有さなければならない（即ち、機能が存在しなければならず、機能は、タスクと１対多リレーションを有する）。

タスクエンティティ３１６では、タスクにおける“ページの順序リスト”属性の各インスタンスは、ページエンティティ３２０におけるページ“識別子”属性の１つまたは複数のインスタンスと関連付けられなければならない。即ち、タスクは、少なくとも１つのページ（即ち、ページとの必須の１対多リレーション）を有さなければならない。

ページエンティティ３２０では、ページにおける“設定の順序リスト”属性を、設定エンティティ３２４における設定“識別子”属性の１つまたは複数のインスタンスと関連付けることができる。即ち、各ページエンティティは、少なくとも１つの設定（即ち、設定との必須の１対多リレーション）を有さなければならない。

当業者であれば、スキーマ３１０を使用して、テーブル３００（図３）のようなテーブルを含むＵＩ仕様書データベースを実装することができよう。例えば、スキーマ３１０の各エンティティ（エンティティの各インスタンスはテーブルの行の役割を果たし、エンティティの属性はテーブルの列の役割を果たす）に対してテーブルを形成することにより、リレーショナルデータベースを実装することができる。さらに、スキーマ３１０に対して正規化プロセスを実行して、異なる数のエンティティおよびリレーションを有するが実質的には同一の機能性を有する他の実施形態を生成することができる。

図４は、例示的な実施形態に従う、アプリケーションの仕様書を作成する際の動作フロー４００を示している。動作フロー４００は、任意の適切なコンピューティング環境において実行することができる。例えば、動作フロー４００は、図２のシステム２００により実行することができ、従って、動作フロー４００の記述は、図２における少なくとも１つのコンポーネントに対して使用することができる。しかしながら、図２のコンポーネントに対する任意の上記使用は、単に説明の目的上示したにすぎず、動作フロー４００に関する環境は、図２の実装に限定されるものではないことを理解されたい。

ブロック４０２において、ユーザは、アプリケーションの仕様書の作成に使用されるデータを入力する。一実施形態において、ユーザは、入力インターフェース２０２（図２）のようなアプリケーションを使用して、仕様書のデータを入力することができる。この動作の実施例については、図５を参照して、以下でより詳細に説明する。

ブロック４０４において、入力されたデータはデータベースに記憶される。一実施形態において、入力されたデータは仕様書データベースに記憶される。一実施形態において、仕様書データベースは、概念モデル１００（図１）を実装するように構成されたリレーショナルデータベースである。他の実施形態においては、仕様書データベースは、概念モデル１００を実装するように構成されたオブジェクト指向データベースである。例えば、一実施形態において、仕様書データベースは、図２に関連して上述したように、仕様書データベース２０４を使用して実装される。

ブロック４０６において、データベースに記憶されたデータを使用して、仕様書が作成される。一実施形態において、ユーザは、仕様書ジェネレータ２０６（図２）のようなアプリケーションを使用して、仕様書の作成を要求することができる。この動作の実施例については、図６を参照して、以下でより詳細に説明する。

図５は、一実施例に従う、アプリケーションの仕様書の新規機能に関するデータを入力する際の動作フロー５００を示している。例えば、動作フロー５００を使用して、ブロック４０２（図４）の一実施例を実装することができる。動作フロー５００は、任意の適切なコンピューティング環境において実行することができる。例えば、動作フロー５００は、図２のシステム２００により実行することができ、従って、動作フロー５００の記述は、図２における少なくとも１つのコンポーネントに対して使用することができる。しかしながら、図２のコンポーネントに対する任意の上記使用は、単に説明の目的上示したにすぎず、動作フロー５００に関する環境は、図２の実装に限定されるものではないことを理解されたい。

ブロック５０２において、仕様書により作成されるべきアプリケーションの新規機能に関するデータが受信される。一実施例において、例えば、ユーザは、入力インターフェース２０２（図２）のようなアプリケーションを使用して、新規機能を入力することにより、仕様書において新規機能を作成することができる。アプリケーションは、機能の名前、およびその機能に関連付けられた１つまたは複数のページを入力するよう、ユーザに促すことができる。図３に関連して前述したように、各ページは、仕様書の一部となるスクリーンショットを有することができる。一実施例において、ユーザは、機能に関連付けられた１つまたは複数のページの各々に対して、スクリーンショットを入力することができる。

ブロック５０４において、機能に関連付けられた１つまたは複数のページに対して入力されるべき１つまたは複数の設定に関するデータが受信される。一実施例において、ユーザは、例えば、前述の入力インターフェース２０２のようなアプリケーションを使用して、設定データを入力することができる。図３に関連して前述したように、設定は、識別子、名前、１つまたは複数のフィールドラベル、コントロールタイプ、デフォルト値、有効値の範囲、およびプロパティを有することができる。各設定に対して、その設定を作成するユーザは、上記の属性に関するデータを入力する。

ブロック５０６において、機能に関連付けられた１つまたは複数のページに入力されるべき１つまたは複数のタスクに関するデータが受信される。一実施例において、ユーザは、例えば、前述の入力インターフェース２０２のようなアプリケーションを使用して、タスクデータを入力することができる。図１に関連して前述したように、タスクは、ページ間の関連付け（例えば、ナビゲーション関係、ウィザード等）およびアクション（例えば、保存、変更のキャンセル、印刷、データ表示の変更等）を定義するために使用される。

動作フロー５００は、仕様書内に新規機能を作成するための動作を記述しているが、そのフローは、仕様書内に既に含まれている機能のデータを変更することに実質的には類似している。基本的に、ブロック５０２、５０４、５０６、および５０８における単語“作成”および“入力”を“編集”で置き換えることにより、機能に関連付けられたデータを変更する動作フローを記述することができる。

図６は、一実施例に従う、アプリケーションの仕様書を作成する際の動作フロー６００を示している。例えば、動作フロー６００を使用して、ブロック４０６（図４）の一実施例を実装することができる。動作フロー６００は、任意の適切なコンピューティング環境において実行することができる。例えば、動作フロー６００は、図２のシステム２００により実行することができ、従って、動作フロー６００の記述は、図２における少なくとも１つのコンポーネントに対して使用することができる。しかしながら、図２のコンポーネントに対する任意の上記使用は、単に説明の目的上示したにすぎず、動作フロー６００に関する環境は、図２の実装に限定されるものではないことを理解されたい。

ブロック６０２において、仕様書の一部を作成するために、データベースクエリが作成される。一実施例において、ユーザは、仕様書ジェネレータ２０６（図２）のようなアプリケーションを使用して、仕様書を作成または出力することができる。仕様書ジェネレータ２０６は、クエリを作成し、そのクエリを仕様書データベース２０４（図２）のような仕様書データベースに送信する。一実施例において、ユーザが出力権限を有する一部分または複数の部分のみを出力することができるように、アプリケーションを構成することができる。

ブロック６０４において、クエリから生ずるデータが仕様書データベースから受信される。一実施例において、前述の仕様書ジェネレータ２０６は、クエリから生ずるデータを受信する。

ブロック６０６において、仕様書に取り込むために受信されたデータがフォーマットされる。一実施例において、前述の仕様書ジェネレータ２０６が、受信されたデータをフォーマットする。例えば、一実施例において、フォーマットは、機能の名前を、その機能に関連付けられたページのヘッダとして表示すること、ヘッダの後にページのスクリーンショットを表示すること、および、次いで設定および他の関連データ（例えば、タスク、権限、承認等）のリストを続いて表示することを含む。他の実施例では、異なるフォーマットを使用することができることは言うまでもない。

ブロック６０８において、出力または作成すべき仕様書の部分がまだあるか否かが判定される。一実施例において、前述の仕様書ジェネレータ２０６が、出力すべき部分がまだあるか否かを判定する。例えば、仕様書全体が作成されることになる場合、仕様書ジェネレータ２０６は、仕様書の全ての部分がフォーマットされたか否かを判定する。

ブロック６０８において、フォーマットされるべき部分がまだあると判定された場合、動作フローはブロック６０２に戻る。しかしながら、ブロック６０８において、フォーマットされるべき部分がもうないと判定された場合、動作フローはブロック６１０に進み、ブロック６１０において、フォーマットされた部分が結合されて文書内に出力される。その後、文書をユーザへ表示したり、印刷したりすること等ができる。一部分の例を図７に示す。この例において、この部分は、アプリケーションにおけるＵＩのページ７００の仕様を規定する。この例示的なページ７００は、図３に関連して上述したような、スクリーンショット７０２、設定のリスト７０４、および関連データを含む。仕様書の他の部分は、アプリケーションにおけるＵＩの他のページの仕様を規定する。

図８は、例示的な実施形態に従う、アプリケーションの仕様書を作成し維持するウェブサービスベースのシステム８００を示している。この実施形態において、システム８００は、クライアント８０２と、サーバ８０４と、概念モデル１００を実装する仕様書データベース２０４とを含む。これらは、図２に関連して前述した通りである。

一実施形態において、クライアント８０２は、サービスを呼び出すことができるブラウザである。このサービスは、サーバ８０４により提供され、仕様書データベース２０４内に仕様書のデータを入力したり、仕様書データベース２０４内の仕様書のデータを変更したりして、仕様書データベース２０４に記憶されたデータを使用することにより、仕様書または仕様書の一部を出力または作成する。これらのサービスは、サーバ８０４内で入力インターフェース２０２および仕様書ジェネレータ２０６として表されている。一実施形態において、これらのサービスは、Ｍｉｃｒｏｓｏｆｔ社が開発したＡＳＰ．ＮＥＴフレームワークに従うページとして実装される。この実施形態により、ユーザらは、異なる場所にいても、仕様書に同時にアクセスすること、および仕様書の作成に同時に取り掛かることができる。

例示的な動作環境
図９は、実施形態を実装することができる適切なコンピューティングシステム環境９００の例を示している。コンピューティングシステム環境９００は、適切なコンピューティング環境の一例にすぎず、実施形態の使用範囲または機能性に関する何らかの限定を意味するよう意図するものではない。コンピューティング環境９００は、例示的な動作環境９００において示されたコンポーネントの任意の１つまたは組合せに関して何らかの依存関係または要件を有するものと解釈すべきではない。

実施形態は、多数の他の汎用もしくは専用コンピューティングシステム環境またはコンピューティングシステム構成を用いて動作可能である。実施形態とともに使用するのに適した周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な民生家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記の任意のシステムまたはデバイスを含む分散コンピューティング環境等が含まれるが、これらに限定されるものではない。

実施形態は、プログラムモジュールのようなコンピュータが実行しているコンピュータ実行可能命令の一般的なコンテキストにおいて説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等が含まれる。通信ネットワークを介して接続されたリモート処理ユニットがタスクを実行する分散コンピューティング環境において、実施形態を実行することもできる。分散コンピューティング環境において、プログラムモジュールは、メモリ記憶デバイスを含むローカルコンピュータ記憶媒体およびリモートコンピュータ記憶媒体の両方に配置させることができる。

図９を参照すると、様々な実施形態を実装するための例示的なシステムは、コンピュータ９１０の形態をとる汎用コンピューティングデバイスを含む。コンピュータ９１０のコンポーネントには、処理ユニット９２０と、システムメモリ９３０と、システムメモリ等の様々なシステムコンポーネントを処理ユニット９２０に接続するシステムバス９２１とを含めることができるが、これらに限定されるものではない。システムバス９２１は、様々なバスアーキテクチャのいずれかを用いた、メモリバスまたはメモリコントローラ、周辺バス、ローカルバス等、いくつかのタイプのバス構造のいずれかとすることができる。例えば、このようなアーキテクチャには、ＩＳＡ（Industry Standard Architecture）バス、ＭＣＡ（Micro Channel Architecture）バス、ＥＩＳＡ（Enhanced ISA）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカルバス、および、メザニンバスとしても知られているＰＣＩ（Peripheral Component Interconnect）バスが含まれるが、これらに限定されるものではない。

コンピュータ９１０は通常、様々なコンピュータ読み取り可能な媒体を備える。コンピュータ読み取り可能な媒体は、コンピュータ９１０がアクセスできる任意の利用可能な媒体とすることができ、コンピュータ読み取り可能な媒体には、揮発性媒体および不揮発性媒体、取り外し可能な媒体および取り外し不可能な媒体の両方が含まれる。例えば、コンピュータ読み取り可能な媒体には、コンピュータ記憶媒体および通信媒体を含めることができるが、これらに限定されるものではない。コンピュータ記憶媒体には、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、またはその他のデータ等の情報を記憶するための任意の方法または技術を用いて実装された、揮発性媒体および不揮発性媒体、取り外し可能な媒体および取り外し不可能な媒体が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、もしくはその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、もしくはその他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、もしくはその他の磁気記憶デバイスが含まれ、または、所望の情報を記憶するのに使用できコンピュータ９１０がアクセスできるその他の任意の媒体が含まれるが、これらに限定されるものではない。通信媒体は通常、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、またはその他のデータを、搬送波やその他の搬送機構等の被変調データ信号に組み入れるものであり、通信媒体には、任意の情報伝達媒体が含まれる。「被変調データ信号」という用語は、信号内の情報が符号化される形で１つまたは複数の特性が設定または変更される信号を意味する。例えば、通信媒体には、有線ネットワークや直接配線接続等の有線媒体と、音響、ＲＦ、赤外線、およびその他の無線媒体等の無線媒体とが含まれる。これらの任意の組合せも、コンピュータ読み取り可能な媒体の範囲に含まれるべきである。

システムメモリ９３０には、読み取り専用メモリ（ＲＯＭ）９３１やランダムアクセスメモリ（ＲＡＭ）９３２等、揮発性メモリおよび／または不揮発性メモリの形態をとるコンピュータ記憶媒体が含まれる。ＲＯＭ９３１には通常、起動中等にコンピュータ９１０内の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（Basic Input/Output System）９３３が記憶されている。ＲＡＭ９３２には通常、処理ユニット９２０がすぐにアクセスすることができ、かつ／または、処理ユニット９２０が現在処理している、データおよび／またはプログラムモジュールが含まれる。例えば、図９には、オペレーティングシステム９３４、アプリケーションプログラム９３５、その他のプログラムモジュール９３６、およびプログラムデータ９３７が示されているが、これらに限定されるものではない。

コンピュータ９１０は、その他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。一例として、図９には、取り外し不可能な不揮発性磁気媒体に対して読み書きするハードディスクドライブ９４１と、取り外し可能な不揮発性磁気ディスク９５２に対して読み書きする磁気ディスクドライブ９５１と、ＣＤ ＲＯＭやその他の光媒体等の取り外し可能な不揮発性光ディスク９５６に対して読み書きする光ディスクドライブ９５５が示されている。この例示的な動作環境において使用できるその他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ等が含まれるが、これらに限定されるものではない。ハードディスクドライブ９４１は通常、インターフェース９４０等の取り外し不可能なメモリインターフェースを介してシステムバス９２１に接続され、磁気ディスクドライブ９５１および光ディスクドライブ９５５は通常、インターフェース９５０等の取り外し可能なメモリインターフェースを介してシステムバス９２１に接続される。

図９に示して上述したドライブ群、およびそれらに関連するコンピュータ記憶媒体は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、およびその他のデータの記憶領域をコンピュータ９１０に提供する。例えば図９には、ハードディスクドライブ９４１が、オペレーティングシステム９４４、アプリケーションプログラム９４５、その他のプログラムモジュール９４６、およびプログラムデータ９４７を記憶しているものとして示されている。これらのコンポーネントは、オペレーティングシステム９３４、アプリケーションプログラム９３５、その他のプログラムモジュール９３６、およびプログラムデータ９３７と同一とすることもできるし、または、異なるものとすることもできることに留意されたい。図９では、オペレーティングシステム９４４、アプリケーションプログラム９４５、その他のプログラムモジュール９４６、およびプログラムデータ９４７が少なくとも異なるコピーであることを示すために、それらには異なる番号を付している。ユーザは、キーボード９６２、および、通常マウス、トラックボール、タッチパッド等を指すポインティングデバイス９６１等の入力デバイスを介して、コンピュータ９１０にコマンドおよび情報を入力することができる。その他の入力デバイス（不図示）には、マイクロホン、ジョイスティック、ゲームパッド、衛星受信アンテナ、スキャナ等を含めることができる。これらおよびその他の入力デバイスは、システムバスに接続されたユーザ入力インターフェース９６０を介して、処理ユニット９２０に接続されることが多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）等、その他のインターフェースおよびバス構造を介して接続されてもよい。モニタ９９１または他のタイプのディスプレイデバイスも、ビデオインターフェース９９０等のインターフェースを介して、システムバス９２１に接続される。コンピュータは、モニタに加えて、スピーカ９９７やプリンタ９９６等、その他の出力周辺デバイスも備えることができ、これらは、出力周辺インターフェース９９５を介して接続することができる。

コンピュータ９１０は、リモートコンピュータ９８０等の１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク環境において動作することができる。リモートコンピュータ９８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の一般的なネットワークノードとすることができ、図９には、メモリ記憶デバイス９８１しか示されていないが、通常は、コンピュータ９１０に関して上述した要素の多くまたは全てを備える。図９に示す論理接続には、ローカルエリアネットワーク（ＬＡＮ）９７１およびワイドエリアネットワーク（ＷＡＮ）９７３が含まれるが、その他のネットワークも含めることができる。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットにおいては一般的である。

ＬＡＮネットワーキング環境において使用される場合、コンピュータ９１０は、ネットワークインターフェースまたはネットワークアダプタ９７０を介してＬＡＮ９７１に接続される。ＷＡＮネットワーキング環境において使用される場合、コンピュータ９１０は通常、インターネット等のＷＡＮ９７３を介した通信を確立するためのモデム９７２またはその他の手段を備える。モデム９７２は、内蔵型でも外付け型でもよく、ユーザ入力インターフェース９６０、またはその他の適切な機構を介して、システムバス９２１に接続することができる。ネットワーク環境では、コンピュータ９１０と関連させて示したプログラムモジュールまたはその一部を、リモートメモリ記憶デバイスに記憶することができる。例えば、図９には、リモートアプリケーションプログラム９８５がメモリデバイス９８１に存在するものとして示されているが、これに限定されるものではない。図示したネットワーク接続は、例示的なものであり、コンピュータ間で通信リンクを確立するための他の手段も使用できることを理解されたい。

諸実施形態について構造的特徴および／または方法論的ステップに対して特定の言語により説明したが、特許請求の範囲で定義する本発明は、必ずしも説明した特定の特徴またはステップに限定されないことを理解されたい。むしろ、特定の特徴およびステップは、特許請求の範囲に記載の発明を実装する具体的な形態として開示されている。本発明の趣旨および範囲から逸脱することなく多数の実施形態が可能であるので、本発明は、特許請求の範囲に記載の発明に属するものである。

例示的な実施形態に従う、仕様書の概念モデルを示す図である。 例示的な実施形態に従う、アプリケーションの仕様書を作成し維持するシステムを示すブロック図である。 例示的な実施形態に従う、図１の概念モデルを実装するために使用されるリレーショナルデータベースのテーブルを示す図である。 一実施形態に従う、図３のリレーショナルデータベースのスキーマを示すＥＲ図である。 例示的な実施形態に従う、アプリケーションの仕様書を作成する際の動作フローを示すフロー図である。 一実施例に従う、アプリケーションの仕様書の新規機能に関するデータを入力する際の動作フローを示すフロー図である。 一実施例に従う、アプリケーションの仕様書を作成する際の動作フローを示すフロー図である。 例示的な実施形態に従う、ＵＩのページに対して作成されるＵＩ仕様書の一部の例を示す図である。 例示的な実施形態に従う、アプリケーションの仕様書を作成し維持するためのウェブサービスベースのシステムを示す図である。 例示的な実施形態に従う、使用可能なコンピューティング環境を示すブロック図である。

Claims (20)

1. アプリケーションの仕様書を提供するコンピュータにより実装される方法であって、
   前記仕様書内で使用するための、ユーザにより入力されたデータを受信するステップと、
   データベースに前記データを記憶するステップと、
   前記データベースにアクセスして、前記データベースからのアクセスされたデータを使用することにより、前記仕様書の少なくとも一部を作成するステップと
   を備えることを特徴とするコンピュータにより実装される方法。
2. 前記データベースからのアクセスされた前記データをフォーマットするステップ
   をさらに備えることを特徴とする請求項１に記載のコンピュータにより実装される方法。
3. 前記入力されたデータは、ユーザインターフェース（ＵＩ）のページに関連付けられたデータを含むことを特徴とする請求項１に記載のコンピュータにより実装される方法。
4. 前記入力されたデータは、前記ページに対する設定を含むことを特徴とする請求項３に記載のコンピュータにより実装される方法。
5. 前記入力されたデータは、前記ページに関連付けられたタスクを含むことを特徴とする請求項３に記載のコンピュータにより実装される方法。
6. 前記入力されたデータは、前記ページに関連付けられたワークフローデータを含むことを特徴とする請求項３に記載のコンピュータにより実装される方法。
7. 前記ワークフローデータは、前記仕様書の変更に対して付与される権限に関するデータを含むことを特徴とする請求項６に記載のコンピュータにより実装される方法。
8. 前記ワークフローデータは、前記仕様書の一部の承認に関するデータを含むことを特徴とする請求項６に記載のコンピュータにより実装される方法。
9. 前記データベースは、前記仕様書内の全ページに対して定義された設定テーブルと、該設定テーブルとのリレーションを有するページ設定テーブルとを含むリレーショナルデータベースを備えたことを特徴とする請求項１に記載のコンピュータにより実装される方法。
10. 前記方法は、ウェブサービスモデルを使用して実装されることを特徴とする請求項１に記載のコンピュータにより実装される方法。
11. 請求項１に記載の方法を実装する動作を実行する命令を記憶したコンピュータ読み取り可能な媒体。
12. アプリケーションの仕様書を作成するシステムであって、
    前記仕様書内で使用するための、ユーザにより入力されたデータを受信する入力インターフェースと、
    前記入力されたデータを記憶する仕様書データベースと、
    前記仕様書データベースからのアクセスされたデータを使用することにより、前記仕様書の少なくとも一部を作成する仕様書ジェネレータと
    を備えたことを特徴とするシステム。
13. 前記仕様書ジェネレータは、前記データベースからのアクセスされた前記データをさらにフォーマットすることを特徴とする請求項１２に記載のシステム。
14. 前記入力されたデータは、ユーザインターフェース（ＵＩ）のページに関連付けられたデータを含むことを特徴とする請求項１２に記載のシステム。
15. 前記入力されたデータは、前記ページに関連付けられた１つまたは複数の設定、タスク、またはワークフローデータを含むことを特徴とする請求項１４に記載のシステム。
16. 前記仕様書データベースは、前記仕様書内の全ページに対して定義された設定テーブルと、該設定テーブルとのリレーションを有するページ設定テーブルとを含むリレーショナルデータベースを備えたことを特徴とする請求項１２に記載のシステム。
17. 請求項１２に記載のシステムを実装する動作を実行する命令を記憶したコンピュータ読み取り可能な媒体。
18. アプリケーションの仕様書を作成するシステムであって、
    前記仕様書内で使用するための、ユーザにより入力されたデータを受信する手段と、
    前記データを記憶する手段であって、該記憶する手段はデータベースを備える、記憶する手段と、
    前記データベースにアクセスして、前記データベースからのアクセスされたデータを使用することにより、前記仕様書の少なくとも一部を作成する手段と
    を備えたことを特徴とするシステム。
19. 前記入力されたデータは、ページに関連付けられた１つまたは複数の設定、タスク、またはワークフローデータを含むことを特徴とする請求項１８に記載のシステム。
20. 前記データベースは、前記仕様書内の全ページに対して定義された設定テーブルと、該設定テーブルとのリレーションを有するページ設定テーブルとを含むリレーショナルデータベースを備えたことを特徴とする請求項１８に記載のシステム。

Images