(57)【要約】  ソフトウェア本体に対するインクリメンタルなリリースは、コンピュータ装置上で自動化ツールを使用することにより実行される。ツールは、リリースされるソフトウェア本体全体を含むファイル及びソフトウェア本体全体の前回のリリースを含むファイルに対するアクセス権、並びにリリースに含まれる各コンポーネントの内容を含むファイルの名前、コンポーネント及びタイムスタンプ／日付スタンプを含む（これらに限定されない）詳細を格納するコンポーネント・データベースに対するアクセス権が提供される。更新されないコンポーネントに含まれるファイルの集合中の各ファイルが前回のリリース以降変更されていないファイルの集合中の同一ファイルと一致すること、新しいファイル又は前回のリリース以降に変更されたファイルの集合が更新されるコンポーネントに含まれるファイルの集合と一致すること、及びリリースされるソフトウェア本体全体を含むファイルの各々が１つのコンポーネントに含まれることをチェックした後、リリースする必要のある更新されたコンポーネントの集合をツールに認識させ、ツールは単にソフトウェアをリリースする。ツールは、各コンポーネント及び各変更ファイルに対するコンポーネント・データベースをソフトウェアのリリースのパーツとして更新する。
2007538328.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンポーネントを備えるデータの本体へ更新をリリースするための、自動化ツールを用いたコンピュータ装置の制御方法であって、
リリースすべき前記データの本体を備えるファイルへのアクセスを可能にする工程と、
前記データの本体の前回のリリースを備えるファイルへのアクセスを可能にする工程と、
リリースすべき更新されたコンポーネントの集合を通知する工程と、
前記更新に係るコンポーネントのそれぞれについて、名前、コンポーネント、及び、ファイルのタイムスタンプ／日付スタンプを備える、コンポーネント・データベースへのアクセスを可能にする工程と、
更新されていないこれらのコンポーネントに含まれる前記ファイルが、前記データの本体の前回のリリースにおける対応する前記ファイルと同一であることをチェックする工程と、
新しい、又は、前回のリリース以降変更されたファイルが、リリースされているコンポーネントの対応するファイルと同一であることをチェックする工程と、
リリースされるファイルのそれぞれが、１つのコンポーネントにのみ含まれることをチェックする工程と、
前記コンポーネント・データベースを更新する工程と、
を備える方法。
【請求項２】
前記ツールは、これまでにリリースされている前記データの本体全体を備える前記ファイルへのアクセスを有するように構成され、
前記ツールは、前記コンポーネント・データベースへ問い合わせ、前記データの前回のリリース以降変更されたリリースに係るこれらのコンポーネントのみを取得するように構成される
請求項１に記載の方法。
【請求項３】
前記データの本体におけるそれぞれのファイルについての前記コンポーネント・データベースは、該ファイルの機能的に重要な部分のみのメッセージダイジェストを有し、
前記コンポーネント・データベースを更新する工程には、変更されたファイルのそれぞれの機能的に重要な部分のみの新しいメッセージダイジェストを計算し、格納する工程が含まれ、
更新されていない前記コンポーネントに含まれる前記ファイルのそれぞれが、過去のリリースにおいて同じファイルと同一であることをチェックする前記工程は、該ファイルの機能的に重要な部分のみのメッセージ・ダイジェストを計算し、それが、前記コンポーネント・データベースに格納されたそのファイルの過去のリリースのダイジェストと同一であることをチェックすることにより実行される
請求項１又は２に記載の方法。
【請求項４】
前記ファイルのそれぞれの機能的に重要な部分のみのメッセージ・ダイジェストを計算し、これらのメッセージ・ダイジェストが、前記コンポーネント・データベースにおけるファイルのそれぞれに係る前記メッセージ・ダイジェストと同一であることをチェックすることによって、前記データの本体の前記リリースの完全性を検証する工程
を備える請求項３に記載の方法。
【請求項５】
ネットワーク・コンピュータのディスク等の、共有アクセス媒体へ、前記データの本体に関する情報を、コピー、格納、又は、更新する工程を備え、
リリース、又は、リリースへの更新を取得する前記方法は、前記共有アクセス媒体から取得される情報を、コピー、格納、又は、更新することにより行われる
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
コンピュータ・テープ、コンパクトディスク、又は、デジタル・ビデオ・ディスク等の、分散媒体へ、前記データの本体に関する情報を、コピー、格納、又は、更新する工程を備え、
リリース、又は、リリースへの更新を取得する前記方法は、前記分散媒体から取得される情報を、コピー、格納、又は、更新することにより行われる
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項７】
前記工程の全て又は一部は、あらゆるデータをリリースも取得もしないで動作するものをシミュレートするための、デバッグモードでコンピュータ装置を動作させることによって実行される
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記データの本体は、コンピュータ装置と電気通信装置との少なくともいずれかのためのオペレーティングシステムを備える
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記データの本体は、デジタル情報又は数値情報の本体を備える
ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
請求項１乃至９のいずれか１項に記載の方法に適合して動作するように構成されたコンピュータ装置。
【請求項１１】
請求項１０に記載のコンピュータ装置を、請求項１乃至９のいずれか１項に記載の方法に適合して動作させるように構成されたコンピュータソフトウエア。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ装置を動作させる方法に関し、特に、一貫性のある完全なカスタマイズ可能なソフトウェア製品全体がパーツ又はコンポーネントからアセンブルされることを相対的に保証しつつ、複数の開発者がそのソフトウェア製品のパーツ又はコンポーネントを作成及び配布することを可能にするように、そのような装置を動作させる方法に関する。
【背景技術】
【０００２】
カスタマイズ可能なソフトウェア製品は、受信者が対応するバイナリ又は実行ファイルと共にソフトウェア製品をビルド（build:構築）するのに使用されたソースコードの全て又は一部を受信することにより、自身の要求に応じてソフトウェアを修正できるソフトウェア製品と定義することができる。
【０００３】
カスタマイズ可能なソフトウェア製品のこの定義には、オープンソースソフトウェア及びフリーソフトウェアの双方が含まれる。また、この定義には、ソースコード及びソフトウェアの受信者が制限されたグループである製品が含まれる。例えば、LondonのSymbian Ltdにより開発されたSymbian OSオペレーティングシステムの認証された受信者はバイナリ又は実行ファイルと共にソフトウェアをビルドするのに使用されたソースコードの全て又は一部を受信することにより、自身の要求に応じてソフトウェアを修正できる。このため、Symbian OSオペレーティングシステムは、カスタマイズ可能なソフトウェア製品である。
【０００４】
継続的に開発される任意のソフトウェア本体（body）が定期的にリリースされる場合、一般に各リリースにおいては、全体的に見てソフトウェア本体の特定のパーツに対して比較的小さな変更があるだけである。すなわち、ソフトウェア本体の大部分は、あるリリースから次のリリースに対して変更されないことが多い。
【０００５】
しかし、リリースの全ての受信者間で一貫性及び整合性を保証するために、本体全体がリリース毎に完全に再構成及び再配布されるのが一般的である。これは、通常、ＣＤ−ＲＯＭ又は他の不揮発性記憶媒体等の物理媒体にインストールファイルをコピーすることにより達成されるか、あるいはインターネット又は他のデータ転送媒体を介してインストールファイルをダウンロードできるようにすることにより実現される。全ての元のソフトウェアファイルは、ソフトウェアの先のリリース以降変更されていないファイルでも更新データに含まれる。しかし、コンピュータ装置のオペレーティングシステム等の大規模なソフトウェア本体の場合、これは、リリース毎に不必要に大量のＣＤ−ＲＯＭを配布することを意味し、あるいはダウンロードによる配布に対してインターネットが使用される時にはファイルをダウンロードするための接続時間が数時間又は数日になることを意味する。
【０００６】
ソフトウェア本体に対する変更を配布するこの方法は、一般に、モノリシック配布と呼ばれる。その主な利点は、モノリシック配布が毎回ソフトウェア全体を効果的にビルドするため、受信者が先のリリースに対して行なった修正に関わらず、本質的に全ての受信者に対して動作することが保証された基準となる共通プラットフォームを提供することである。通常、この配布方法は、任意の種類のソフトウェアに対する更新データをリリースする最も一般的な方法と考えられる。
【０００７】
更新されたソフトウェアのリリースを配布する別の方法は、ソフトウェア本体全体が必要に応じて受信者により再構成可能な状態で、ソフトウェア全体とは無関係に配布される先のバージョンと機能的に異なるソフトウェアのパーツのみを配布するものである。変更を配布するこの方法は、インクリメンタル配布と呼ばれてもよい。最も明らかな利点は、モノリシック配布と比較して、リリース毎に配布される必要のあるデータ量が少ないため、より迅速で効率的なことである。インクリメンタル配布は、ソフトウェア本体全体を一般にコンポーネントと呼ばれる個別のパーツに分割することに基づいている。このコンポーネントが存在することから、受信者は、先のリリースを修正する際に行なった投資を可能な限り保存することができる。インクリメンタル配布は以下の２つの点でこれを可能にする。第１に、インクリメンタル配布がソフトウェア製品を更新するのに厳密に必要なものを配布するためである。第２に、受信者がソフトウェア製品の各カスタマイズに対して必要のない任意のコンポーネント更新データを廃棄することを選択的に決定してもよいためである。
【０００８】
ソフトウェア更新データの再リリース及び配布の概要は、Oxford UniversityにおいてComputing LaboratoryのColin Percivalにより編集されている。この概要は、http://www.daemonology.net/freebsd-update/binup.htmlで得られ、当該分野の多くの課題及び問題を概説する。しかし、Percivalは、上述のようなカスタマイズ可能なソフトウェア製品と共に使用するのに適切な方法を発見していない。その概要において説明される表面上は類似する２つのソフトウェア更新方法は、本明細書において更に詳細に説明する価値のある周知の方法である。
【０００９】
・カスタマイズ可能なソースコードを含まない部分的なリリースに対するモノリシック配布の方法が存在する。特に、Microsoftは、ソフトウェア本体全体を再発行するのではなくサービスパックを発行することによりオペレーティングシステム及びソフトウェアスイートを更新する。サービスパックは、完全な再インストールとは異なり、当該ソフトウェアに対するユーザのカスタマイズを保存する。
【００１０】
しかし、サービスパックが適用されるMicrosoft製品はカスタマイズ可能なソフトウェア製品とは考えられないため、そのようなサービスパックのリリースは、本発明が対処しようとする問題領域には入らない。最も重要なことは、ソースコードがサービスパックに含まれないこと又はユーザに配布されないことである。従って、ユーザは、自身の要求に応じて製品をカスタマイズするためにソフトウェアソースコードを修正できない。ユーザは、製品の設計者及び作成者により許可された制限内で製品の挙動をカスタマイズすることしかできない。特に、サービスパックをインストールする時に更新処理を制御する方法は存在せず、ユーザはサービスパックの任意の部分を実際に選択的に採用することに関して決定を行うことができない。
【００１１】
・受信者が別個のコンポーネント更新データをオペレーティングシステムに統合することを可能にするLinuxの配布により使用される方法が存在する。最もよく知られている方法は、Debianパッケージ管理（Debian Linuxにおけるコンポーネント化に関する更なる情報については、http://www.debian.org/doc/debian-policy/ch-binary.htmlを参照）及びRed Hatにより開発され、Linux Standard Baseプロジェクトにより採用されたＲＰＭシステム（ＲＰＭパッケージ管理に関する更なる情報については、http://www.rpm.org/を参照）に基づく方法である。
【００１２】
しかし、そのようなパッケージ管理システムは、本発明が対処しようとする問題領域に入らない。これは、Red Hat等の企業及びDebian等の団体がカスタマイズ可能なソフトウェア製品を作成しないからである。企業及び団体が行なうことは、独立した別個のカスタマイズ可能なソフトウェア製品を複数の供給元及び作成者から集約して統合して、受信者が正常に統合できるように個別に作成されたコンポーネントをパッケージ化することである。Linuxの配布の場合、出荷される時のソフトウェア本体全体とコンポーネント・リリースの受信者が使用する可能性のあるソフトウェア本体全体との関係に関して保証する必要はない。
【００１３】
従って、統合されたソフトウェア全体の設計、記述及びビルドを行なうオペレーティングシステムの作成者及び配布者によりコンポーネントが示され、管理される点と、Linuxの製造者によりコンポーネントが受け入れられ、再配布される点との間には明らかな違いがある。ここで、Linuxの製造者は、例えば他の人に作成されたカスタマイズ可能なソフトウェア製品からオペレーティングシステムをアセンブルするが、安定して一貫した方法で出荷するソフトウェア本体全体を追加的に更新する必要がない。
【００１４】
モノリシック配布の主な利点は、受信者が先のリリースに対して行なった修正に関わらず全ての受信者に対して動作することが保証されることであることが、上述から理解される。
【００１５】
モノリシック配布を図１に概略的に示す。しかし、以下を含むいくつかの理由のために、モノリシック配布は完全なものではない。
【００１６】
・ソフトウェアの変更部分及び未変更部分の双方を配布することは、非効率的でコストが高く、不便である。これは、特定のリリースに対する変更が非常に小さなものであり、関連するデータが大量であり、配布チャネルが制限された容量のチャネルである場合に特に当てはまる。通常、カスタマイズ可能なソフトウェア製品は、ソースコードがバイナリと共に配布されるため大量のデータを含む。Symbian OSオペレーティングシステム等のオペレーティングシステムの場合、媒体帯域幅データ接続を介してオンラインで全てのデータを転送するのに数日かかる可能性がある。
【００１７】
・モノリシック配布ポリシーによる一貫性及び整合性の要求は、ソフトウェア本体が、標準のポリシーに従って、理想的には１つの場所で１つの集団の人々により１度に作成されることを必要とする。実際には、通常、これは開発上の大きな障害を表す。
【００１８】
・配布がコンポーネントに分割され、ソフトウェアの変更部分及び未変更部分が区別なく含まれるため、受信者が取得したい配布のコンポーネントを選択するための容易な方法は存在しない。配布は、受信者が選択できる別個のコンポーネントに分割されない。例えば、特定のデバイスドライバに対する１つの更新データが、特定の受信者が要求する全てであると仮定すると、受信者は、要求されるデバイスドライバをビルドするのに必要な部分のみを抽出するために、配布全体を細分化し、その内容を解析するように試みる必要があるだろう。配布がソースコードを完全に含み、情報をビルドするため、当然これは理論的に可能である。しかし、配布における変更は非常に複雑となり、適当な時間枠において成功する可能性は非常に小さいだろう。従って、そのような受信者は、全てを必要とするかしないかに関わらず、リリースに含まれる全ての更新データを受け入れる必要がある。
【００１９】
インクリメンタル配布は、モノリシック配布による多くの問題を克服し、速度及び効率の面において潜在的な利点を提供するが、その配布自体の問題も発生する。
【００２０】
インクリメンタル配布は、いくつかの点において、モノリシック配布より潜在的により大きな危険性を有する。部分的なソースコードのみが配布されるため、ソフトウェア製作者が誤る可能性がより大きい。これは、オペレーティングシステム等の大規模なソフトウェア本体の場合に特に当てはまる。例えば、追加のソースファイル（これは、未変更のファイルではなく新しいファイルである）がリリースから誤って除外される可能性がある。あるいは、コンポーネント間の相互の依存性が非常に複雑である場合、任意の１つのコンポーネントのリリースの失敗により、受信者は、ソースコードファイル又はヘッダファイルのファイルがリリースにおいて複数バージョン存在することを発見する可能性がある。
【００２１】
インクリメンタル配布がソフトウェアの受信者の興味を引く１つの理由、すなわち受信者が実際に必要であり使用するものに基づいて取得するコンポーネントを選択して決定できるということに起因して、危険を招く別の原因が発生する。このため、作成者又は配布者は、製品が種々の受信者により複数の種々の構成で使用されることをほぼ断定する必要がある。作成者又は配布者は、任意の特定のモジュールが更新又はカスタマイズされたか否かを示す方法を有さず、カスタマイズされたコンポーネント、更新されたコンポーネント及び元のコンポーネントの固有の組合せを含む範囲で各受信者がソフトウェアをビルドする可能性に直面する。これにより、製品の品質の制御は低下し、サポート費用は増加する。
【００２２】
インクリメンタル配布は、製作者がリリース処理において間違いをしない場合でも、また受信者がリリースの全てのコンポーネントを取得する場合でも、さらなる危険性を必然的に伴う。インクリメンタル配布が「クリーン（clean）」を使用するリリースから開始しないため、リリースは、全ての受信者が同一バージョンのソフトウェアを厳密にビルドするモノリシック配布方法を提供された時と同等のレベルの保証を作成者又は配布者に提供することができない。これは、新しい配布と古い配布とを結合し、実際に使用するためにソフトウェア本体を再ビルドする役割を果たすのは受信者であり、作成者又は配布者ではないからである。
【００２３】
更に、ビルド処理の偶発的な複雑性、並びに再ビルドするのに使用されるローカルシステムの構成の制御不可能な特定の面に対するその依存性により、任意の受信者に対して再ビルド・ソフトウェア本体全体の統合を常に保証できるとは限らない。
【００２４】
また、ソフトウェア本体をコンポーネントに分割することは、インクリメンタル配布にとって不可欠なことである。ソフトウェアがモノリシックにビルドされる場合には、この方法は採用できない。しかし、当業者には明らかとなるように、適切なモジュラアーキテクチャを使用しても、大規模なソフトウェア本体を個別の配布可能なコンポーネントに分割することは単純な動作ではない。種々の領域とコンポーネントとの間の多くの関係及び相互依存を判定することは、困難で時間のかかる処理である。
【００２５】
更に、インクリメンタル配布に含まれる必要のあるソフトウェアのパーツのみを識別する実際のタスクは重要である。手動でこのタスクを試み、最適化することは、危険性の高い手順であると考えられる。Oxford UniversityにおけるComputing LaboratoryのColin Percivalは、手作業に関して以下のように指摘する。「手作業は、更新されるファイル数を最小限にするように試み、その作業に人の関与を伴う。これには、誤りを起こす大きな危険性がある。最適な状況下でも人は間違いを犯す。また、特定のソースコードパッチにより影響を受けたファイルを特定のリストから判定するタスクは、ファイルがビルドされる方法に関する詳細な知識を必要とする。」
最後の点に関して、手動最適化は危険を伴うが、リリースを自動的に最適化することも実現するのは容易ではない。これは、機能的な変更と非機能的な変更とを自動的に区別するのが非常に困難なためである。ファイル中の非機能的な変更の例としては、ソースコードに付けられたコメントにおける綴りの誤りが修正された場合である。そのような修正は、ソースコードの内容を明らかに変更するが、非機能的な点の変更である。ソースコードが再コンパイルされる場合、関連するオブジェクトファイルに含まれるタイムスタンプ（timestamp、時間スタンプ）が変更されるが、これも非機能的な点の変更である。変更されたコンポーネントを見つけるために、ファイルに相違点（「Diff」等）があるかを自動的にチェックする自動化ソフトウェアツール及びファイルのダイジェストを提供する等の方法を使用することで、変更されたものとしてソースコード及びオブジェクトファイルの双方にフラグを立てる。インクリメンタル配布の最適化に失敗したときは、更新される必要のないアイテムを配布する。
【００２６】
しかし、この影響を最小限にする方法についての従来技術が存在する。例えば、Percivalは、それぞれ異なるシステム日付で同一ソースから２度ファイルをビルドすることにより内部のタイムスタンプが変更されたため、バイナリファイルの再リリースを単純に回避し、日付スタンプが格納される場所を見つけるためにバイト単位の比較を行なう１つの方法を説明する。これにより、過去のリリースと現在のリリースとを比較する場合にそのような領域のファイルを除外し、変更されたコンポーネントを識別する場合に誤る可能性を回避することが可能になる。Symbian Ltdは、バイト単位にファイルの比較を行ない、重要でない相違点を無視する「evalid」と呼ばれるツールをSymbian OSオペレーティングシステムのパーツとして以前に発表した。しかし、更新データに含まれる必要のあるパーツを識別する問題に対する全ての解決策は、機能に対するファイルの比較に依存していることに留意すべきである。
【００２７】
インクリメンタル配布の固有の問題から発生するいくつかの結果を図２に示す。このインクリメンタル配布モデルを図１に示すより単純化されたモノリシックモデルと比較することにより、３つの危険が明確に示される。図２の左側部分１００はソフトウェア製作者によりビルドされたバイナリファイルを示し、図２の中央部分２００はリリースされたコンポーネントを示し、図２の右側部分３００は受信者の終了の際のファイルを示す。変更されたバイナリファイルは、それらバイナリファイルが属するコンポーネントとバイナリファイルとを連結する点線により示される。コンポーネントＡの再リリースの失敗により、バイナリファイルＢ１／Ａ５は２つの互換性のないバージョンで存在し、バイナリファイルＥ１はリリースに全く含まれず、コンポーネント構造において使用されたバイナリＤ１は受信されたバージョンと一致しないことが示されている。
【００２８】
モノリシック配布方法の利点とインクリメンタル配布方法の利点とを一致させる有効な方法が存在しないことは、上述から明らかである。
【発明の開示】
【発明が解決しようとする課題】
【００２９】
従って、本発明の目的は、コンポーネント・リリースの集合（セット）がソフトウェア本体全体を完全に正確に表せることを保証するように、モノリシック配布方法と同等のレベルの保証を提供できるインクリメンタル配布方法を提供することである。
【課題を解決するための手段】
【００３０】
本発明は、作成者、配布者及び受信者が機能的な変更と非機能的な変更とを区別できるようにするインクリメンタル配布方法の最適化を更に含む。これにより、不必要な内容をリリースにおいて配布しないことを保証し、効率及び利便性を最大限にする。
【００３１】
本発明の第１の側面によると、１つの方法が提供される。
【００３２】
本発明の第２の側面によると、第１の面による方法に従って動作するように構成されるコンピュータ装置が提供される。
【００３３】
本発明の第３の面によると、第２の面によるコンピュータ装置が第１の面の方法に従って動作するようにするためのコンピュータソフトウェアが提供される。
【発明を実施するための最良の形態】
【００３４】
添付の図面を参照し、更なる例として本発明の一実施形態について以下に説明する。
【００３５】
以下に説明する本発明の実施形態において、自動化ツールの集合により、コンポーネント・リリースが作成され、相対的な保証が実現される。本発明の本実施形態のために、以下のことが仮定される。
【００３６】
・コンポーネント・リリースは、本明細書においてリリーサ（releaser）と呼ばれる人又は人々のチームにより作成され、リリーサは、自身の開発ドライブ上にソフトウェア本体のコピーを有すると仮定される。
【００３７】
・コンポーネント・リリースは、本明細書において受信者と呼ばれる人又は人々のチームに配布され、受信者は、自身の開発ドライブ上にソフトウェア本体のコピーを有すると仮定される。
【００３８】
・ソフトウェアは、コンピュータネットワーク、ＦＴＰ（ファイル転送プロトコル）サイト又はＣＤ ＲＯＭ等の共有媒体を介してリリーサにより受信者に対して入手可能にされると仮定される。
【００３９】
・ソフトウェアがコンポーネントに分割され、ある種類のコンポーネント・データベース又は同等のデータ記憶装置が存在し、それらコンポーネント、コンポーネント間の依存性、コンポーネントをビルドするのに要求されるソースファイル及び生成するバイナリファイルをリストにすると仮定される。受信者が更新された各コンポーネントに対してデータベースの関連する部分をローカル開発ドライブにコピーすることを可能にするため、このデータベースのコピーは、利便性のためにオプションとして共有媒体に維持されてもよい。
【００４０】
・リリース処理の開始時、ソフトウェア本体と関連する受信者開発ドライブの内容は共有リリースドライブの内容と同一であり（受信者はソフトウェアの最新リリースを有する）、リリーサ開発者ドライブの内容は共有リリースドライブの内容と同一ではない（ソフトウェアの最新リリースは現在のバージョンではなく、新しいリリースが作成される必要がある）ことが仮定される。
【００４１】
これらの関係を図３に示す。使用される処理は、以下のように要約される。
【００４２】
ａ）リリーサは、ある適切な手段により、変更されたソフトウェア本体のコンポーネント及び変更されていないコンポーネントをリリースツールに知らせる。変更された全てのコンポーネントに含まれるファイルは、図３のＲ１で示されるような変更ファイルの集合を含む。当業者は、情報が見つけられる１以上のファイルの名前をコマンドで渡す等、情報を渡す可能な方法が多く存在することを認識すると考えられ、この情報転送を実現するのに使用される方法が本発明の動作に関連するとは考えられない。従って、本発明は、任意の方法と共に機能するように適応される。
【００４３】
ｂ）リリーサは、ツールに対してコマンドを発行し、変更されたことをツールが知っているコンポーネントの新しいリリースを作成するようにツールに命令する。処理のこの部分で、リリースの一貫性及び完全性が以下のようにツールによりチェックされてもよい。
【００４４】
ｉ）図４に示すように、リリース開発ドライブ上の各ファイルに対して、共有媒体上の同一コンポーネントのファイルと同一であるか、あるいは共有媒体と同一でないか又は共有媒体に存在しないか、あるいは変更されたコンポーネントの集合に属するファイルとしてリストされているか（図３のＲ１）を確認するためのチェックが行なわれる。これらチェックのいずれかが失敗する場合、リリースは失敗する。
【００４５】
ｉｉ）図３に示すように、各ファイルが厳密に１つのコンポーネントのみに含まれること、いずれのコンポーネントにおいてもファイルが除外されないこと及びファイルが２つ以上のコンポーネントに含まれないことを保証するために、リリース開発ドライブ上のソフトウェアはチェックされる。このチェックが失敗する場合、リリースは失敗する。
【００４６】
ｃ）最後にツールは、変更ファイルの集合（図３のＲ１）をリリーサ開発ドライブから共有媒体にコピーすることにより、ソフトウェアの最新バージョンをリリースする。
【００４７】
ｄ）ツールは、リリースに含まれる実際のファイルと共に、変更されたソフトウェア本体のコンポーネントの詳細で構成されるメタデータを生成してリリースする。これは、処理の開始時にリリーサにより作成された変更コンポーネントの有効な宣言に基づく情報でコンポーネント・データベースを更新することにより行なわれる。以下に説明するように、このメタデータは、共有媒体からインクリメンタル更新データを抽出するために、受信者により使用される。
【００４８】
尚、Symbian Ltdにより使用される本発明の好適な実装において、リリースメタデータは、リリースが作成された時に開発環境に存在した他のコンポーネントのリストを更に含む。強制される制約と組み合わされたこの「環境」情報により、任意のリリースの厳密な環境は、先に作成されたリリースに加え新しく作成されたリリースのみに基づいて、別のコンピュータ上で再現される。
【００４９】
以下の擬似コードは、リリース処理をより厳密に説明する。
【００５０】
リリーサ擬似コード
１  リリーサは、コンポーネントを含む全ての情報のマニフェスト（manifest）、又は、コンポーネントをビルドするのに使用されたツールを介してそのようなマニフェストを取得するのに必要とされる情報を含む、各コンポーネントに対する宣言と共に、インストールされたコンポーネントのいくつかが「リリース待ち」であることを宣言する
２  リリーサは、それらコンポーネントのリリースを作成するようにツールに要求する
３  リリーサ開発ドライブ上のファイルのリストを作成する−そのリストを「配布元不明」リストと呼ぶ
４  「所有ファイル」のリストを空で開始する
５  インストールされているものを確認するために「コンポーネント・データベース」を検査する
６  Ｆｏｒｅａｃｈ（インストールされた各コンポーネントに対して）
７    コンポーネントの状態をクリーンに設定する
８    コンポーネントは「リリース待ち」か？
９      ｎｏの場合：
１０  コンポーネントの状態を「クリーン」に設定する
１１  リリースのために使用された共有媒体に依然として存在する最初にインストールされたバージョンのコンポーネントを検査し、含まれるファイルのリストを取得する
１２    ｙｅｓの場合：
１３  リリーサの宣言からコンポーネントに属するファイルのリストを取得する
１４  Ｆｏｒｅａｃｈ（コンポーネントに属する各ファイルに対して）
１５  「配布元不明」リストからファイルを除去する
１６  ファイルは「所有ファイル」リストに存在するか？
１７    ｙｅｓの場合：
１８  リリースを中止する（所有権を複写する）
１９    ｎｏの場合：
２０  「所有ファイル」リストにファイルを追加する
２１  ファイルはリリーサ開発ドライブに存在するか？
２２    ｎｏの場合：
２３  リリースを中止する（欠落したファイル）
２４  コンポーネントは「リリース待ち」か？
２５    ｎｏの場合：
２６  ファイルは最初にインストールされたバージョンと一致するか？
２７    ｎｏの場合：
２８  リリースを中止する（不正なコンポーネント）
２９  次へ（コンポーネントに属する次のファイル）
３０  次へ（インストールされた次のコンポーネント）
３１  「配布元不明」ファイルが残っているか？
３２  ｙｅｓの場合：
３３  リリースを中止する（配布元不明ファイル）
３４  Ｆｏｒｅａｃｈ（リリース待ちの各コンポーネントに対して）
３５  他者により使用されるためにリリースのアーカイブを作成する
３６  最新のファイル名及びタイムスタンプをコンポーネント・データベースに記録する
３７  次へ（リリース待ちの次のコンポーネント）
３８  リリースと共に全てのコンポーネントのリストを「コンポーネント・データベース」に記録する。
【００５１】
上記アルゴリズムにおいてリリースが中止された時、リリーサは、新たな試みを行なう前にその中止の原因となった問題を解決する必要がある。コードコンパイラが誤りを見つけた時に最初に見つけた誤りで停止するのではなくコンパイルを継続するのと同様に、処理を中止せずに更なる誤りのチェックを継続するがリリースを行なわないことで、処理が最適化される。これにより、リリーサは各リリースに対する繰り返し数を減少できる。
【００５２】
リリースが作成されると、受信者は、ツールの相補的な集合を使用して共有媒体から新しいリリースを取得し、インストールする。本実施形態の主な点は、リリースが上記アルゴリズムを使用して作成される必要があることである。それにより、ギャップの可能性及びオーバラップがないことを保証し、またコンポーネントが共有媒体上のリリースから再生不可能なことがないことを保証する。以下の擬似コードのアルゴリズムにおいて、受信者は、既に旧リリースを有しており、そのリリース以降に更新されたコンポーネントを単純に要求すると仮定される。
【００５３】
受信者擬似コード（１）
１  受信者は、前回行なわれたリリース以降にコンポーネント・データベースにおいて変更されたエントリを要求する
２  Ｆｏｒｅａｃｈ（データベース中の変更されたコンポーネント・リリース）
３  受信者開発ドライブにリリースの最新ファイルを抽出する
４  コンポーネント・データベースの受信者コピーを更新し、インストールされたコンポーネントバージョンを記録する
５  次へ（データベース中の次の変更されたコンポーネント・リリース）。
【００５４】
このアルゴリズムは、受信者がリリースをスキップした場合でも機能する。また、アルゴリズムは、全てのコンポーネントが変更されたとしてマークされる場合、先のリリースを取得していない受信者及び「クリーン」リリースの取得を要求する受信者に対して機能する。
【００５５】
本発明の好適な実装において、リリーサ擬似コードアルゴリズムの２６行目に最適化が存在する。このステップは、変更されていない各ファイルに対して、リリーサ開発ドライバ上のバージョンが共有媒体上のバージョンと同一であることを本発明がチェックすることを表す。
【００５６】
この最適化の基本原理は、ファイル中のデータが数学的に操作され、メッセージダイジェスト、ハッシュ又はチェックサムと呼ばれるファイルの内容を表す単一番号を生成することである。この番号を算出するのに使用されるアルゴリズムに依存して、２つのファイルが同一のメッセージダイジェストを有することが起こる可能性は非常に低い。従って、一致を検証するために、ファイル自体を比較するのではなく２つのファイルのダイジェストを比較することが可能である。周知のＭＤ５アルゴリズム等の公開されている適切なアルゴリズムが多く存在する。一般に、ファイルと共にそのようなダイジェストを配布することにより、受信者が一致を検証できる。
【００５７】
従って、本発明の好適な最適化において、コンポーネントに含まれる各ファイルの有効部分のダイジェストを共有媒体上のコンポーネント・データベースに含まれる情報に含むこと、変更されていない各ファイルに対して同様のダイジェストを計算すること、及び２つのダイジェストを突き合わせて一致を検証することが提案される。ファイル全体のダイジェストではなく、ファイルの有効部分のみのダイジェストを配布することは、本発明の別の利点である。ダイジェスト単位の比較は、ファイル単位の比較と比べて迅速で効率的な方法であり、適切に機能するために、チェックされるファイルとは別の任意のファイルにアクセスすることを必要としないことが理解されるだろう。好適な実装において、方法は以下の通りである。
【００５８】
・まず、ファイルが検査され、その形式が判定される。これは、単に最初の数バイトを読み出すことにより達成されることが多い。このファイル形式は、ファイルの残りの部分の構造を特定し、その構造は、「重要である」と考えられるパーツ及び「重要ではない」と考えられるパーツを判定するために検査される。
【００５９】
・「重要である」パーツを決定するルールは、動作の厳密な目的に依存する。バイナリファイルに対する最も単純な例において、ファイルの機能を表すパーツ（コンピュータ・マシンコード等）のみが対象であり重要であると考えられるため、ファイルを再作成するのに変更されたパーツ（タイムスタンプ等）を無視する。ソースファイルに対する最も単純な例において、ファイル中の全てのコメント及び余白を無視する。重要な部分を決定する方法は、本発明の要素ではない。しかし、その方法は、例えばバイナリファイル中のタイムスタンプの場所を発見するためにPercivalにより提案されたアルゴリズムを使用して動作する。
【００６０】
形式の記述をツールに取り入れたり、ツールが読み出し可能な形式で共有媒体に形式の記述を格納する等、各ファイル形式を識別するデータを伝播する多くの種々の機構、並びに全ての受信者に対して重要な領域を決定するルールが実現可能である。
【００６１】
・重要な領域が識別されると、最も単純な方法は、元のファイルを別の「仮想」ファイルにコピーすることである。重要ではない領域は、その仮想ファイルから除外される。メッセージダイジェスト処理はその仮想ファイルに適用され、ファイルの重要な機能領域のみを表すダイジェストを生成する。従って、ダイジェストは、同一の機能（すなわち、重要なデータ）を有し、異なる「重要ではない」データを有する２つのファイル間で一致するだろう。
【００６２】
・種々のショートカットが可能である。例えば、コピーを行なわずに、元のファイルの選択されたパーツに対してダイジェストルーチンを実行することができる。同様に、ファイルの重要なパーツのみの表現を生成するための容易に入手可能な既存の変換が存在してもよい（例えば、実行可能ファイルを翻訳する）。それらの変換は、実現の複雑性をなくし、実行時間を節約するために使用されてもよい。
【００６３】
この最適化により、リリーサが変更ファイルを効率的に識別するのが可能になると共に、受信者はソフトウェア本体のバージョンの完全性をチェックできる。受信者は、単純にファイルの有効部分のメッセージダイジェストを算出し、各ダイジェストがコンポーネント・データベースの同一リリースの同一ファイルに対して格納されたダイジェストと一致するかをチェックできる。これを達成する１つの可能なアルゴリズムは以下の通りである。
【００６４】
ソフトウェア本体の受信者チェック
１  受信者は、リリースに対するコンポーネント・データベースの全てのエントリをチェックすることを要求する
２  Ｆｏｒｅａｃｈ（各コンポーネントに対して）
３  Ｆｏｒｅａｃｈ（コンポーネントの各ファイルに対して）
４    受信者開発ドライブに格納される時に、ファイルの有効セクションのメッセージダイジェストを算出する
５    ダイジェストが同一ファイルの同一バージョンに対してコンポーネント・データベースに格納されたダイジェストと一致するかをチェックする
６    ｎｏの場合：
７    ソフトウェアが損なわれた可能性があることを報告する
８  次へ（コンポーネントの次のファイル）
９  次へ（次のコンポーネント）。
【００６５】
本発明は、ソフトウェア本体を配布する周知の方法に対して、以下の重要な利点を提供すると考えられる。
【００６６】
・本発明は、保証された一貫性のあるソフトウェア本体全体を個別のコンポーネントの集合からアセンブルする方法を提供する−上記機構の欠如は、コンポーネント化された配布に対して相当な危険をもたらす。そのため、現在、多くの受信者は、コンポーネント化されたファイルを採用したがらず、毎回ソフトウェア本体全体を採用したがる。
【００６７】
・本発明は、分散したリリースに適している。集中化されたビルド及び統合チームにより１つの場所で生成された大量のデータを配布する時間及び資金を費やす必要がない。事実上保証されたコンポーネント集合を使用して、ソフトウェア本体全体の複数のパーツは、異なる場所で異なる時間に生成でき、結果が完全であり一貫していることを受信者に明確に保証できる。
【００６８】
・埋め込まれたソフトウェアを複数の受信者に出荷する際の追加の融通性により、ソフトウェアに依存する製品を開発するのに必要とされる時間を大幅に減少する−共通のカスタマイズされたオペレーティングシステムを使用する移動電話の種々のモデルの開発がよい例である。
【００６９】
・容易に格納され且つ機能性の一致を検証するのに容易に使用されるファイルの有効部分の比較的小さなメッセージダイジェストを使用することにより、ファイル及びコンポーネントが実際に変更された時期をリリーサ及び受信者が検出することを迅速且つ容易にする。特に、オペレーティングシステム等の大規模なソフトウェア製品の場合、新しいリリースを配布、取得及び検証する費用及び時間において１桁の違いを生じる。
【００７０】
・方法は、コンピュータソフトウェアファイルだけでなく、デジタルデータ又は数値データの本体に適用できる。
【００７１】
特定の実施形態を参照して本発明について説明したが、添付の請求の範囲により規定されるような本発明の範囲内で変更が行なわれてもよいことが理解されるだろう。
【図面の簡単な説明】
【００７２】
【図１】ソフトウェア本体の配布に対するモノリシック方法を概略的に示す図である。
【図２】ソフトウェア本体の配布に対するインクリメンタル方法を概略的に示す図である。
【図３】ソフトウェア本体に対するコンポーネント・リリースがそのソフトウェア本体のリリーサと受信者との間に配置される方法を概略的に示す図である。
【図４】リリース開発ドライブ上の各ファイルに対して、ソフトウェア本体の受信者と共有される媒体上の同一コンポーネントのファイルと同一ファイルであるかを確認するためのチェックを行なう方法を概略的に示す図である。
【図１】
2007538328.tif 000003
【図２】
2007538328.tif 000004
【図３】
2007538328.tif 000005
【図４】
2007538328.tif 000006
【国際調査報告】
2007538328.tif 000007
2007538328.tif 000008
2007538328.tif 000009