特許 6792281 シリアライズ・データ処理装置、シリアライズ・データ処理方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6792281

(24)【登録日】2020年11月10日

(45)【発行日】2020年11月25日

(54)【発明の名称】シリアライズ・データ処理装置、シリアライズ・データ処理方法及びプログラム

(51)【国際特許分類】

   G06F 9/448 20180101AFI20201116BHJP

   G06F 8/71 20180101ALI20201116BHJP

【ＦＩ】

   G06F9/448 120

   G06F8/71

【請求項の数】6

【全頁数】16

(21)【出願番号】特願2016-162973(P2016-162973)

(22)【出願日】2016年8月23日

(65)【公開番号】特開2018-32154(P2018-32154A)

(43)【公開日】2018年3月1日

【審査請求日】2019年5月10日

(73)【特許権者】

【識別番号】716003489

【氏名又は名称】田原 良則

(74)【代理人】

【識別番号】100136180

【弁理士】

【氏名又は名称】羽立 章二

(72)【発明者】

【氏名】田原 良則

【審査官】 多胡 滋

(56)【参考文献】

【文献】 特開２００１−１２５７８７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４４８

Ｇ０６Ｆ ８／７１

(57)【特許請求の範囲】

【請求項1】

シリアライズ・データに対して処理を行うシリアライズ・データ処理装置であって、
ターゲット・インスタンスからバージョンｋ（ｋは、最新バージョンＮ以下のいずれかの自然数）シリアライズ・データを保存する保存手段、及び／又は、バージョンｋシリアライズ・データからターゲット・インスタンスを回復する回復手段を備え、
前記保存手段は、
ｋ＝Ｎならば、ターゲット・インスタンスからバージョンＮシリアライズ・データを生成して保存し、
ｋ＝Ｎ−１ならば、ターゲット・インスタンスからバージョンＮ−１インスタンスを生成して、バージョンＮ−１シリアライズ・データを生成して保存し、
ｋ＜Ｎ−１ならば、ターゲット・インスタンスからｉ＝Ｎ−１，…，ｋに対してバージョンｉインスタンスを順に生成して、バージョンｋシリアライズ・データを生成して保存し、及び／又は、
前記回復手段は、
ｋ＝Ｎならば、バージョンＮシリアライズ・データからターゲット・インスタンスを回復し、
ｋ＝Ｎ−１ならば、バージョンＮ−１シリアライズ・データからバージョンＮ−１インスタンスを生成してターゲット・インスタンスを回復し、
ｋ＜Ｎ−１ならば、バージョンｋシリアライズ・データからバージョンｋインスタンスを生成し、ｉ＝ｋ＋１，…，Ｎ−１に対してバージョンｉインスタンスを順に生成して、ターゲット・インスタンスを回復する、シリアライズ・データ処理装置。

【請求項2】

ユーザ作成プログラムのグローバル・バージョンと前記ユーザ作成プログラムに含まれるクラスのクラス・バージョンを管理するバージョン管理手段を備え、
前記バージョン管理手段は、前記ユーザ作成プログラムにおいて、少なくとも一つのクラスのバージョンが変更されたならば、グローバル・バージョンを変更し、グローバル・バージョンと前記各クラスのクラス・バージョンとの対応関係を保存し、
前記保存手段は、前記回復手段がシリアライズ・データの保存時の前記グローバル・バージョンを知ることができる状態とし、及び／又は、前記回復手段は、前記グローバル・バージョンと前記クラス・バージョンとの対応関係を利用して回復する、請求項１記載のシリアライズ・データ処理装置。

【請求項3】

前記保存手段は、
ユーザが定義したバージョン・ダウン変換関数が存在するならば、当該バージョン・ダウン変換関数を使用してバージョンｉ＋１インスタンスからバージョンｉインスタンスを生成し、
前記バージョン・ダウン変換関数がないならば、バージョンｉインスタンスの各メンバに対して、
バージョンｉ＋１インスタンスに対応するメンバがあるならば、そのメンバへのポインタを設定し、
バージョンｉ＋１インスタンスに対応するメンバがないならば、バージョンｉクラス内に設けられた記憶領域にポインタを設定することにより、バージョンｉ＋１インスタンスからバージョンｉインスタンスを生成する、請求項１又は２に記載のシリアライズ・データ処理装置。

【請求項4】

クラスの少なくとも一つのメンバは、ユーザによって各メンバの保存記録媒体が指定されており、
前記保存手段は、クラスの各メンバをバージョン・ダウン変換処理して指定された保存記録媒体に記録し、及び／又は、
前記回復手段は、バージョンＮのクラスにおけるメンバの一部が保存されていない保存記録媒体のバージョンｋシリアライズ・データから回復処理を行うときに、当該保存記録媒体に記録されていないメンバの一部又は全部のバージョン・ダウン変換処理を行って、当該保存記録媒体に記録されているメンバの回復処理を行う、請求項１から３のいずれかに記載のシリアライズ・データ処理装置。

【請求項5】

シリアライズ・データに対して処理を行うシリアライズ・データ処理方法であって、
情報処理装置は、ターゲット・インスタンスからバージョンｋ（ｋは、最新バージョンＮ以下のいずれかの自然数）シリアライズ・データを保存する保存手段、及び／又は、バージョンｋシリアライズ・データからターゲット・インスタンスを回復する回復手段を備え、
前記保存手段が、
ｋ＝Ｎならば、ターゲット・インスタンスからバージョンＮシリアライズ・データを生成して保存し、
ｋ＝Ｎ−１ならば、ターゲット・インスタンスからバージョンＮ−１インスタンスを生成して、バージョンＮ−１シリアライズ・データを生成して保存し、
ｋ＜Ｎ−１ならば、ターゲット・インスタンスからｉ＝Ｎ−１，…，ｋに対してバージョンｉインスタンスを順に生成し、バージョンｋシリアライズ・データを生成して保存する保存ステップ、及び／又は、
前記回復手段が、
ｋ＝Ｎならば、バージョンＮシリアライズ・データからターゲット・インスタンスを回復し、
ｋ＝Ｎ−１ならば、バージョンＮ−１シリアライズ・データから、バージョンＮ−１インスタンスを生成して、ターゲット・インスタンスを回復し、
ｋ＜Ｎ−１ならば、バージョンｋシリアライズ・データからバージョンｋインスタンスを生成し、ｉ＝ｋ＋１，…，Ｎ−１に対してバージョンｉインスタンスを順に生成して、ターゲット・インスタンスを回復する回復ステップを含むシリアライズ・データ処理方法。

【請求項6】

コンピュータを、請求項１から４のいずれかに記載のシリアライズ・データ処理装置として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本願発明は、シリアライズ・データ処理装置、シリアライズ・データ処理方法及びプログラムに関し、特に、シリアライズ・データを保存及び／又は回復する処理を行うシリアライズ・データ処理装置等に関する。

【背景技術】

【0002】

一般に、オブジェクト指向言語を使ってクラスを保存／回復するときには、そのクラス・メンバについて１つ１つ保存／回復するプログラムを開発する必要があった。ここで、クラスを保存／回復するとは、ファイルへ保存及び／又は回復したり、通信回線を通じて送信及び／又は受信したりすることである。シリアライザを使用することにより、簡単なプログラムでクラス・インスタンスを保存／回復することができる（特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開平１０−０６３５２２号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、プログラム開発では、通常、複数のバージョンが発生する。従来のシリアライザでは、旧バージョンのクラス定義を残さず、最新版のクラスのみを保存／回復できるものであった。そのため、最新版のクラスを複数の旧バージョンのシリアライズ・データに保存したい場合、最新版から旧バージョンへ変換するプログラムを開発する必要があった。同様に、複数の旧バージョンのシリアライズ・データから最新版のクラスを回復したい場合、それらの旧バージョンから最新版へ変換するプログラムを開発する必要があった。

【0005】

図１０は、従来のシリアライザを使用した複数のバージョン間での処理の概要を示す図である。図１０を参照して、バージョン１からバージョン２にすると、相互に変換するために２つの変換プログラムが必要にある。バージョン３になると、バージョン１と３との間、及び、バージョン２と３との間で、相互に変換するために、さらに４つの変換プログラム（合わせて６つの変換プログラム）が必要になる。

【0006】

従来のシリアライザでは、将来、どのバージョンでも対応できるようにするには、全てのバージョン間で変換するプログラムを開発することが必要になった。例えばｎ個のバージョンがあれば、ｎ（ｎ−１）個の変換プログラムが必要になる。その結果、プログラム開発の当初はシリアライザの保存／回復の容易性というメリットを享受できても、開発が進んでバージョンが増加すると、プログラムのメンテナンスの手間が大幅に増える。ユーザにとっては、突然、デメリットが顕在化することとなった。

【0007】

さらに、従来のシリアライザでは、旧バージョンのクラス定義を残さない。新しいバージョンであるメンバを他のメンバへ統合するなどして、あるメンバを削除してしまうと、旧バージョンのシリアライズ・データを回復したいとき、最新のクラスでは回復できない。従来のシリアライザでは、ユーザがデシリアライズ処理プログラムを開発したり、メンバの削除を断念したりするしかなく、シリアライザの効果が半減したり、不要なメンバが残ってメンテナンス性が低下したりしていた。

【0008】

そこで、本願発明は、複数のバージョンのクラス・インスタンスの保存／回復を容易に実現することが可能なシリアライズ・データ処理装置等を提案することを目的とする。

【課題を解決するための手段】

【0009】

本願発明の第１の観点は、シリアライズ・データに対して処理を行うシリアライズ・データ処理装置であって、ターゲット・インスタンスからバージョンｋ（ｋは、最新バージョンＮ以下の自然数）シリアライズ・データを保存する保存手段、及び／又は、バージョンｋシリアライズ・データからターゲット・インスタンスを回復する回復手段を備え、前記保存手段は、ｋ＝Ｎならば、バージョンＮインスタンスを生成し若しくは生成せずに、バージョンＮシリアライズ・データを生成して保存し、ｋ＝Ｎ−１ならば、バージョンＮインスタンスを生成し若しくは生成せずに、バージョンＮ−１インスタンスを生成して、バージョンＮ−１シリアライズ・データを生成して保存し、ｋ＜Ｎ−１ならば、バージョンＮインスタンスを生成し若しくは生成せずに、ｉ＝Ｎ−１，…，ｋに対してバージョンｉインスタンスを順に生成し、バージョンｋシリアライズ・データを生成して保存し、及び／又は、前記回復手段は、ｋ＝Ｎならば、バージョンＮインスタンスを生成し若しくは生成せずに、バージョンＮシリアライズ・データからターゲット・インスタンスを回復し、ｋ＝Ｎ−１ならば、バージョンＮ−１シリアライズ・データからバージョンＮ−１インスタンスを生成して、バージョンＮインスタンスを生成し若しくは生成せずに、ターゲット・インスタンスを回復し、ｋ＜Ｎ−１ならば、バージョンｋシリアライズ・データからバージョンｋインスタンスを生成し、ｉ＝ｋ＋１，…，Ｎ−１に対してバージョンｉインスタンスを順に生成し、バージョンＮインスタンスを生成し若しくは生成せずに、ターゲット・インスタンスを回復する。

【0010】

本願発明の第２の観点は、第１の観点のシリアライズ・データ処理装置であって、ユーザ作成プログラムのグローバル・バージョンと前記ユーザ作成プログラムに含まれるクラスのクラス・バージョンを管理するバージョン管理手段を備え、前記バージョン管理手段は、前記ユーザ作成プログラムにおいて少なくとも一つのクラスのバージョンが変更されたならば、グローバル・バージョンを変更し、グローバル・バージョンと前記各クラスのクラス・バージョンとの対応関係を管理し、前記保存手段は、前記回復手段がシリアライズ・データの保存時の前記グローバル・バージョンを知ることができる状態とし、及び／又は、前記回復手段は、前記グローバル・バージョンと前記クラス・バージョンとの対応関係を利用して回復する。

【0011】

本願発明の第３の観点は、第１又は第２の観点のシリアライズ・データ処理装置であって、前記保存手段は、ユーザが定義したバージョン・ダウン変換関数が存在するならば、当該バージョン・ダウン変換関数を使用してバージョンｉ＋１インスタンスからバージョンｉインスタンスを生成し、前記バージョン・ダウン変換関数がないならば、バージョンｉインスタンスの各メンバに対して、バージョンｉ＋１インスタンスに対応するメンバがあるならば、そのメンバへのポインタを設定し、バージョンｉ＋１インスタンスに対応するメンバがないならば、バージョンｉクラス内に設けられた記憶領域にポインタを設定することにより、バージョンｉ＋１インスタンスからバージョンｉインスタンスを生成する。

【0012】

本願発明の第４の観点は、第１から第３のいずれかの観点のシリアライズ・データ処理装置であって、クラスの少なくとも一つのメンバは、ユーザによって各メンバの保存記録媒体が指定されており、前記保存手段は、クラスの各メンバをバージョン・ダウン変換処理して指定された保存記録媒体に記録し、及び／又は、前記回復手段は、バージョンＮのクラスにおけるメンバの一部が保存されていない保存記録媒体のバージョンｋシリアライズ・データから回復処理を行うときに、当該保存記録媒体に記録されていないメンバの一部又は全部のバージョン・ダウン変換処理を行って、当該保存記録媒体に記録されているメンバの回復処理を行う。

【0013】

本願発明の第５の観点は、シリアライズ・データに対して処理を行うシリアライズ・データ処理方法であって、情報処理装置は、ターゲット・インスタンスからバージョンｋ（ｋは、最新バージョンＮ以下の自然数）シリアライズ・データを保存する保存手段、及び／又は、バージョンｋシリアライズ・データからターゲット・インスタンスを回復する回復手段を備え、前記保存手段が、ｋ＝Ｎならば、バージョンＮインスタンスを生成し若しくは生成せずに、バージョンＮシリアライズ・データを生成して保存し、ｋ＝Ｎ−１ならば、バージョンＮインスタンスを生成し若しくは生成せずに、バージョンＮ−１インスタンスを生成して、バージョンＮ−１シリアライズ・データを生成して保存し、ｋ＜Ｎ−１ならば、バージョンＮインスタンスを生成し若しくは生成せずに、ｉ＝Ｎ−１，…，ｋに対してバージョンｉインスタンスを順に生成し、バージョンｋシリアライズ・データを生成して保存する保存ステップ、及び／又は、前記回復手段が、ｋ＝Ｎならば、バージョンＮインスタンスを生成し若しくは生成せずに、バージョンＮシリアライズ・データからターゲット・インスタンスを回復し、ｋ＝Ｎ−１ならば、バージョンＮ−１シリアライズ・データから、バージョンＮ−１インスタンスを生成して、バージョンＮインスタンスを生成し若しくは生成せずに、ターゲット・インスタンスを回復し、ｋ＜Ｎ−１ならば、バージョンｋシリアライズ・データからバージョンｋインスタンスを生成し、ｉ＝ｋ＋１，…，Ｎ−１に対してバージョンｉインスタンスを順に生成し、バージョンＮインスタンスを生成し若しくは生成せずに、ターゲット・インスタンスを回復する回復ステップを含む。

【0014】

本願発明の第６の観点は、コンピュータを、第１から第４のいずれかの観点のシリアライズ・データ処理装置として機能させるためのプログラムである。

【0015】

なお、バージョンｉインスタンス（ｉ＝１，…，Ｎ）は、バージョンｉのクラスのインスタンスである。バージョンｉシリアライズ・データは、バージョンｉのクラスのシリアライズ・データである。

【0016】

また、本願発明を、コンピュータをバージョン管理手段として機能させるためのプログラムとして捉えてもよい。本願発明を、ユーザが作成したソース・プログラムを利用して、シリアライズ／デシリアライズに必要な情報のみを抽出したクラス定義を（自動的に）生成するプログラムとして捉えてもよい。さらに、本願発明を、第７の観点などのプログラムを定常的に記録するコンピュータ読み取り可能な記録媒体として捉えてもよい。

【発明の効果】

【0017】

本願発明の各観点によれば、任意のバージョンから前のバージョンへの変換プログラムを用意するだけで、全ての複数のバージョンでのクラス・インスタンスの保存を容易に実現することができる。特に、ユーザは、任意のバージョンと次のバージョンとの間での変換プログラムを用意するだけで、複数のバージョンのクラス・インスタンスの保存／回復を容易に実現することができる。

【0018】

従来、旧バージョンのクラス定義を残していないため、クラス全体を纏めてデシリアライズすることができず、ユーザが回復するコードを手入力する必要があった。本願発明によれば、旧バージョンのクラス定義を残しているため、以前のバージョンのクラスに対しても従来のシリアライザ技術を用いることができる。

【0019】

さらに、従来、最新版と保存／回復に必要な古い版との間の変換プログラムを書く必要があった。例えばｎ個のバージョンがあれば、全体としてｎ（ｎ−１）個の変換プログラムが必要になった。本願発明の各観点によれば、最新バージョンとするとき、直前のバージョンとの間での２つの変換プログラムを新たに用意すればよく、例えばｎ個のバージョンがあっても、全体として２（ｎ−１）個の変換プログラムを用意すればよい。

【0020】

さらに、本願発明の各観点によれば、クラス・メンバを削除した場合でも、デシリアライズ処理プログラムを開発する必要がない。また、従来、シリアライズ・データとクラス・インスタンスとの間でメンバの対応を順序で行う場合、クラス・メンバの順序を変更することができなかったが、本願発明の各観点によれば、バージョンを変更することで、順序変更をすることができる。

【図面の簡単な説明】

【0021】

【図1】本願発明による複数のバージョン間での変換処理の一例の概要を示す図である。

【図2】本願発明によるバージョンＮとｋ（ｋ＜Ｎ）の間での保存／回復の処理の概要を示す図である。

【図3】本願発明の実施の形態に係るシリアライズ・データ処理装置の構成の一例のブロック図である。

【図4】図３の（ａ）クラス・バージョン変換部２１及び（ｂ）処理定義部２３の一例であるソース・プログラムである。

【図5】図３のソース生成部１５が自動生成したソース・コードの一例を示す。

【図6】図４及び図５の例における処理結果を示す図である。

【図7】図３のシリアライズ・データ処理装置１における保存処理の一例を示すフロー図である。

【図8】図３のシリアライズ・データ処理装置１における回復処理の一例を示すフロー図である。

【図9】図３のシリアライズ・データ処理装置１における回復処理の他の一例を示すフロー図である。

【図10】従来のシリアライザを使用した複数のバージョン間での処理の概要を示す図である。

【発明を実施するための形態】

【0022】

以下では、図面を参照して、本願発明の実施例について説明する。なお、本願発明は、この実施例に限定されるものではない。

【実施例】

【0023】

図１は、本願発明による複数のバージョン間での変換処理の一例の概要を示す図である。図１では、バージョン１と２の間、及び、２と３の間の変換処理を用意すればよく、バージョン１と３との間の変換処理はバージョン２を利用して行う。そのため、変換処理は、保存のために２つと回復のために２つを用意すればよい。

【0024】

具体的には、クラスには、バージョン１では、３つのメンバが含まれている。Code（string型）、Name（string型）及びPrice（int型）である。それぞれ、例えば、C123、ダッフルコートM、及び、50000である。

【0025】

バージョン２では、メンバColorを追加し、Codeに色コードとサイズを追加する。バージョン１から２への変換処理は、メンバColorを追加して「ネイビー」とすること、及び、メンバCodeへ、対応する色コード「2」及びNameから抽出したサイズ「M」を、ハイフンで追加することである。バージョン２から１への変換処理は、メンバColorの削除とコードからハイフン以降の削除である。

【0026】

バージョン３では、NameとColorをコロンで統合し、Colorを削除する。バージョン２から３への変換処理は、NameとColorをコロンで統合すること、及び、Colorを削除することである。バージョン３から２への変換処理は、Colorを追加し、Nameをコロンの前後で分離し、Colorをコロンの後のものにし、Nameからコロン以降を削除することである。

【0027】

以下では、ターゲット・クラスは、シリアライズ／デシリアライズ対象のユーザ定義クラスであり、最新のバージョン番号はN（Nは1以上の整数）とする。ターゲット・インスタンスは、ターゲット・クラスのインスタンスである。処理クラスは、ターゲット・クラスのシリアライズ／デシリアライズ処理用のクラスであり、過去の全てのバージョンに対して定義される。バージョン番号i（i=1, 2, ..., N)を持つ。これはシリアライズ／デシリアライズするメンバを含む。

【0028】

図２は、本願発明によるバージョンＮとｋ（ｋ＜Ｎ）の間での保存／回復の処理の概要を示す図である。まず、前処理として、シリアライズのために、シリアライズ対象メンバを持つ旧バージョンのクラスなどを定義する。そして、ターゲット・インスタンスをシリアライズ用クラスへ変換し、最新版インスタンスからＮ−ｋ回のバージョン・ダウン変換を行ってバージョンｋのインスタンスを生成し、バージョンｋのインスタンスへ保存／回復処理を行う。そして、Ｎ−ｋ回のバージョン・アップ変換を行ってバージョンＮのインスタンスを生成し、ターゲット・クラスへ変換してターゲット・インスタンスとする。これらの処理は、案件毎に人手で開発することは可能であるが、ソース・コードを自動的に生成することが望ましい。このとき、バージョン・アップ／ダウン時に各メンバ値の変換を行う部分はユーザ定義とし、その関数が存在すれば呼び出す。

【0029】

ターゲットのインスタンスと最新版(Verison.N)のインスタンスの変換処理について説明する。バージョン・ダウンのときは、Version.Nのインスタンスを生成し、Version.Nインスタンスの各メンバへターゲット・インスタンスの対応するメンバへのポインタを設定する。バージョン・アップのときは、Version.Nのインスタンスを破棄する。ターゲット・クラスのシリアライズ／デシリアライズする全てのメンバは最新版(Vesrion.N)のメンバと対応している。各メンバのアドレスをVersion.Nへ渡す場合、旧バージョンの対応するメンバが回復された時点で、ターゲットのメンバに直接値が設定されており、アドレス渡しの場合、特にするべき処理がなく、Version.Nのインスタンス（各メンバのアドレスを保持している。）を破棄するのみである。なお、コピーの場合は、対応するメンバのコピーを行った上でVersion.Nを破棄する。例えば、バージョン・ダウン処理はVersion.iのコンストラクタから呼び出し、バージョン・アップ処理はVersion.iのデストラクタから呼び出すことにより実現することができる。

【0030】

各バージョン間（Version.i+1とVersion.i）のインスタンスの変換処理（隣接バージョン間のインスタンスの変換処理）について説明する。バージョン・ダウンのときは、ユーザが定義したバージョン・ダウン変換関数があるときは、それを呼び出す。ないときは、Version.iのインスタンスを生成し、Version.iインスタンスの各メンバへポインタを設定する。具体的には、Version.i+1インスタンスに対応するメンバがある場合は、そこへのポインタを設定する。ない場合は、Version.iクラス内に該当変数の型の記憶領域を設けておき、バージョン・ダウン処理時に初期化する。Version.iの該当メンバへ、そこへのポインタを設定する。バージョン・アップのときは、ユーザが定義したバージョン・アップ変換関数がある時はそれを呼び出す。ないときは、Version.iのインスタンスを破棄する。

【0031】

各メンバの対応について、Version.iとVersion.i-1間で同じメンバの名前を変更し型を変更していない場合は、ユーザ（プログラマ）による指定によって名前変更前と後のメンバを対応づけ、そうでない場合は、同じ名前、かつ、同じ型のメンバ同士が対応するものとする。

【0032】

Version.iの保存／回復処理について、Version.iインスタンスの各メンバが指す記憶領域を保存／回復する。保存／回復先は、Version.iシリアライズ・データである。この処理には、従来のシリアライザを用いることもできる。他方、シリアライズ用クラスへの変換やバージョン・ダウン変換、バージョン・アップ変換、ターゲット・クラスへの変換などは、従来のシリアライザのみでは実現することができない。

【0033】

なお、最新版のインスタンスを生成することは、省略することができる。また、保存時にはバージョン・アップの連鎖を、回復時にはバージョン・ダウンの連鎖を省略することができる。

【0034】

また、ターゲットと最新版のインスタンスの変換処理及び隣接バージョン間のインスタンスの変換処理では、ポインタを用いて伝達することに代えて、コピーで実現してもよい。このときは、バージョン・ダウン処理の最初に新バージョンから旧バージョンへコピーし、バージョン・アップ処理の最初で逆方向へコピーする。このとき、同様に、保存時のバージョン・アップ処理のコピー、回復時のバージョン・ダウン処理のコピーは省略することができる。

【0035】

なお、本願発明では、ユーザが作成したプログラムにおいて、一部又は全部のクラスの旧バージョンのデータ保存をしないものでもよい。旧バージョンのデータ保存がされないクラスについては、例えば、Version.iのインスタンスを生成してシリアライズ・データから回復する。その後、Version.i+1のインスタンスを生成し、Version.iの各メンバを対応するVersion.i+1のメンバへコピーする。これを繰り返し、ターゲット・クラスのインスタンスへ各メンバをコピーする。なお、Version.i, i+1等のインスタンスは各コピー完了後破棄する。

【0036】

バージョン管理について説明する。各クラスのバージョン（「クラス・バージョン」という。）とは別に、プログラム全体にグローバルなバージョン番号（「グローバル・バージョン」という。）を定める。クラス・バージョンが上がったものが一つでもあると、グローバル・バージョンが上がる。そして、バージョン管理テーブルは、グローバル・バージョンと各クラス・バージョンとの対応関係を管理するための表である。表１は、バージョン管理テーブルの一例を示す。バージョン管理テーブルを用いることで、グローバル・バージョンを指定するだけで、全てのクラスについて当時のクラス・バージョンを決定でき、旧バージョンの形式での保存／回復を実現できる。また、グローバル・バージョンをシリアライズ・データへ記録することで、各クラスのクラス・バージョンの記録が不要となる。

【0037】

更に、型チェックするためにクラス名をシリアライズ・データへ記録する場合がある。従来のシリアライザでは、このクラス名を変更することができなかった。本願発明によれば、シリアライズ・データ内のクラス名を、バージョン管理テーブルの指定グローバル・バージョンについて検索し、そのバージョンにおけるクラス名が、シリアライズ・データ内のクラス名と一致する全てのものの中に、現在回復しようとしているクラスが存在すれば型チェックOK、存在しなければ型チェックNGとできる。これにより、保存時のクラス名で比較できるため、バージョン管理テーブルと、当該クラスのクラス名を取り出す手法を用意することで、バージョン番号が異なればクラス名の変更を実現できる。

【0038】

【表1】

【0039】

また、クラスの各メンバ変数に対して、保存記録媒体を指定できるようにしてもよい。一部のメンバはある保存記録媒体に保存され、他のメンバは別の保存記録媒体に保存することができる。このとき、回復処理のときも、バージョン・ダウン処理を行うことが望ましい。保存先指定により一部のメンバが保存されていない保存記録媒体からの回復時、そのままではバージョン・アップ変換処理が当該メンバをアクセスできない。しかし、回復時もバージョン・ダウン処理を行うことで保存されていないメンバの値を最新版から生成できる。また、最新のターゲット・クラスのインスタンスが持つ情報を、旧バージョンが使用することができる。

【0040】

ただし、保存先指定により保存対象の一部のメンバのみを回復し、かつ、バージョン・ダウン変換後、値の回復なしに、バージョン・アップ変換したときに値が元に戻らない場合に備えて、回復されなかったメンバについて元の値へ戻す手段を用意する。例えば、バックアップしておき、値が回復されなかった、又は、バージョン・アップ変換で変更されなかったメンバはバックアップをリストアする。バージョンＮ以外のインスタンスではバージョン・ダウン変換後にバックアップする。バージョンＮインスタンスは生成時にバックアップする。また、バージョン・ダウン変換前にバックアップしておき、戻ってきたときに値が（回復や修正がなく）変化していなければバックアップをリストアする。バージョン・ダウン変換を省略し、バージョン・アップ変換のみ実装する場合なども同様である。

【0041】

また、enum定義もバージョン変更されることは多い。従来、単にシンボルが増えるだけなら実現できるが、本願発明によって、同じシンボル名を異なる意味に使うこともできる。また、シリアライズ・データとクラス・メンバの対応付けはメンバIDと順序の２種類が用いられている。従来、順序対応の場合には順序変更できなかったが、本願発明によれば、バージョン番号変更により順序変更できる。

【0042】

また、あるクラスが他のクラスを含むとき、それらのクラスの間で、足並みを揃えてバージョン・アップ／ダウンできる仕組みを設けてもよい。これにより、含んでいるクラスの値を使ってバーション・アップ／ダウン処理を記述することができる。このような仕組みを設けない場合、含んでいるクラスのデータは最新版のデータとなり、バージョン・アップした当時の定義と異なっていた場合、そのバージョン・アップ／ダウン変換関数の修正が必要になる。

【0043】

また、プログラムを自動生成するときに、プログラム・ファイルに対する排他制御を行ってもよい。並列コンパイル時にプロクラム・ファイルを修正すると、同じファイルを用いて並列に実行されていたコンパイル動作がおかしくなる可能性があるためである。

【0044】

また、クラス・メンバの保存方式について、メンバ名対応と順序対応の切り替えができるようにしてもよい。これにより、プログラム変更に対応しやすくしたり、効率的なものとしたりすることができる。また、enum型の保存方法について、シンボル名（プログラム変更に対応しやすい）とシンボル値（効率的）を切り替えができるようにしてもよい。さらに、同じバージョン番号内でのenum型のシンボル名／シンボル値を変更できるようにしてもよい。これにより、バージョン番号を変えなくてもシンボル名や値を変更できる。また、キー付きコレクションとして、保存先指定でクラスを分割保存したとき、同じキーに属するクラス・データを同じクラス・インスタンスへ回復できるようにしてもよい。

【0045】

図３は、本願発明の実施の形態に係るシリアライズ・データ処理装置の構成の一例を示すブロック図である。シリアライズ・データ処理装置１は、ソース・プログラム記憶部３とバージョン管理テーブル記憶部５と、旧バージョン定義記憶部７と、インスタンス記憶部９と、シリアライズ・データ記憶部１１と、ソース生成部１５と、コンパイル部１７と、シリアライズ処理部１９を備える。なお、シリアライズ・データ処理装置は、従来のシリアライザによって実現されている処理も実行することができる。

【0046】

ソース・プログラム記憶部３は、ユーザが入力したソース・プログラムを記憶する。ソース・プログラムは、少なくとも、クラス・バージョン変換処理及びクラス定義を含む。図３では、簡単のために、１つのクラスで、ユーザがバージョン・アップ／ダウン処理を定義している場合を例に説明する。最新バージョンはＮであるとする。図３を参照して、ソース・プログラム記憶部３が記憶するソース・プログラムは、クラス・バージョン変換部２１と、処理定義部２３を含む。

【0047】

クラス・バージョン変換部２１は、クラス定義と保存・通信メンバの指定を含み、さらに、最大Ｎ−１個のバージョン・アップ関数部２５_iと、最大Ｎ−１個のバージョン・ダウン関数部２７_iを含む。バージョン・アップ関数部２５_iは、バージョンｉからバージョンｉ＋１へ変換するための処理を定義する。バージョン・ダウン関数部２７_iは、バージョンｉ＋１からバージョンｉへ変換するための処理を定義する。図４（ａ）は、クラス・バージョン変換部２１の一例であるソース・プログラムであり、ファイル名は「class.h」である。

【0048】

処理定義部２３は、シリアライズ／デシリアライズ処理を定義するものであり、保存処理部２９と、回復処理部３１を含む。図４（ｂ）は、処理定義部２３の一例であるソース・プログラムであり、ファイル名は「main.cpp」である。

【0049】

バージョン管理テーブル記憶部５は、表１を例に説明したバージョン管理テーブルを記憶する。

【0050】

ソース生成部１５は、クラス・バージョンの更新に伴い、バージョン管理テーブルを更新する。また、ソース生成部１５は、クラス・バージョン変換部２１及び処理定義部２３を用いて、保存／回復の処理を実現するためのソース・コードを自動生成する。旧バージョン定義記憶部７は、ソース生成部１５が生成したソース・コードを記憶する。図５（ａ）及び（ｂ）は、図４（ａ）及び（ｂ）を用いて自動生成されたソース・コードの一例を示し、ファイル名は「main.cpp.theoride.hpp」である。図５（ｂ）のMyGVNT部分が、バージョン管理テーブルに当たる。

【0051】

コンパイル部１７は、ソース・プログラム記憶部３、バージョン管理テーブル記憶部５及び旧バージョン定義記憶部７を参照して、ソース・コードをコンパイルする。ここで、シリアライズ制御ライブラリをリンクする。シリアライズ処理部１９は、シリアライズ／デシリアライズ処理を行うものであり、コンパイル済みのプログラムを実行することにより実現される。図６は、図４及び図５の例における（ａ）バージョン３、（ｂ）バージョン２、及び、（ｃ）バージョン１の出力を示す図である。main.cppには、THEORIDE_S_PROCESS()がある。図６において、最初が（ａ）バージョン３、次が（ｂ）バージョン２、３番目が（ｃ）バージョン１のシリアライズである。最後がデシリアライズであり、（ｄ）は、バージョン３のデシリアライズ結果を出力したものである。

【0052】

シリアライズ処理部１９は、保存部４１と、回復部４３と、制御部４５と、リピート制御部４７と、バージョン・ダウン変換部４９と、バージョン・アップ変換部５１を備える。図７〜９のフロー図を参照して、シリアライズ処理部１９の動作の例を説明する。

【0053】

図７（ａ）を参照して、保存処理の一例を説明する。保存処理の開始時に、保存先を指定する。この保存先とメンバに指定された保存先が一致しているものについて保存される。なお、保存先を指定しなかった場合、保存対象のメンバは全て保存される。制御部４５は、ｋを、保存対象のインスタンスバージョン番号とし（ステップＳＴＳ１）、型を判断する（ステップＳＴＳ２）。プリミティブ型（例えば、int型やdouble型等、基本的なデータ型）であれば、保存部４１は、プリミティブ保存をし、処理を終了する。

【0054】

クラス型であれば、保存部４１は、処理クラス・バージョンＮのインスタンスを生成する（ステップＳＴＳ４）。具体的には、インスタンス生成後、ターゲット・クラスの各メンバを、処理用クラス・バージョンNの対応するメンバへ設定する。これは、値をコピーする方法とアドレスを設定する方法がある。このとき、同じメンバ名のメンバ同士を対応付ける。

【0055】

制御部４５は、ｋがＮと一致するか否かを判断する（ステップＳＴＳ５）。一致するのであれば、保存部４１は処理用クラス・バージョンＮのインスタンス保存をし（ステップＳＴＳ６）、ステップＳＴＳ１３へ進む。

【0056】

ここで、インスタンス保存は、保存記録媒体へ保存する処理である。ステップＳＴＳ６及びＳＴＳ１１では、保存対象のメンバを１つ１つ枚挙し、保存先が一致しているものについて、値を保存するためにシリアライズ処理を再帰的に呼ぶ。その際、シリアライズ・データ上のメンバがプログラム側のどのメンバへ回復するのか対応付けに必要な情報も保存する。対応方法は２種類ある。メンバID対応では、クラス内でユニークに定められたメンバ名、もしくは、番号にて対応する。そのため、メンバIDとメンバの値をペアでシリアライズ・データへ記録する。なお、メンバIDとメンバの値がシリアライズ・データ上で隣接する必要はなく、例えば、ヘッダにメンバIDを記録し、シリアライズ・データ側へはメンバIDを記録しないなどでもよい。順序対応では、クラス内で決められた順序に従って対応する。順序は、ソース・コード上でメンバを記述した順序やメンバ名の辞書順等である。

【0057】

一致しないのであれば、リピート制御部４７は、ｉにＮ−１を代入する（ステップＳＴＳ７）。保存部４１は、処理クラス・バージョンｉのインスタンスを生成する（ステップＳＴＳ８）。バージョン・ダウン変換部４９は、処理用クラス・バージョンｉ＋１のインスタンス（Read Only）及び処理用クラス・バージョンｉのインスタンス（Read/Write）を受け取り、保存対象のメンバに対してバージョン・ダウン変換処理を行う（ステップＳＴＳ９）。具体的には、バージョン・ダウン変換部４９は、インスタンス生成後、処理用クラス・バージョンi+1の各メンバを、処理用クラス・バージョンiの対応するメンバへ設定する。これも、値をコピーする方法とアドレスを設定する方法がある。原則として、同じメンバ名のメンバ同士を対応付ける。もしメンバ名が変更されていたならば、ソース・コードの指定に従って対応付ける（後に具体例を使って説明する）。旧バージョン側に対応するメンバがない場合、対応しない。新バージョン側に対応するメンバがない場合、旧バージョン内にそのメンバ用のメモリ領域を確保し、予め決められた方法で初期化する（図１のクラス・バージョン２でのColorに関する処理を参照）。予め決められた方法には、使用しているプログラミング言語が定める方法（デフォルト・コンストラクタ）、当該シリアライザが定める方法（固定値等）、ユーザ指定（ユーザ関数呼び出しやソース・コードへの指定）による方法がある。

【0058】

メンバ名が変更されており、ソース・コードの指定に従って対応付ける場合について、バージョン3のmUShortメンバの名前をバージョン4のmDataへ変更したときには、例えば、下記のような例となる。ここで、THEORIDE_S_ANNOTATEは、属性定義用マクロである。theorideSD::Configは、保存先指定である。なお、保存先指定は、省略することもでき、この場合、常に保存対象とする。

【0059】

struct IntrusiveDerived : public IntrusiveBase
{
unsigned int mUInt;
unsigned short mData THEORIDE_S_ANNOTATE(FS:mUShort<theorideSD::Config>);
IntrusiveBase mIntrusiveBase;

THEORIDE_S_INTRUSIVE(CS, (IntrusiveDerived), 4);
};

【0060】

制御部４５は、ｋがＮと一致するか否かを判断する（ステップＳＴＳ１０）。一致するのであれば、保存部４１は処理用クラス・バージョンｉのインスタンスを保存し（ステップＳＴＳ１１）、ステップＳＴＳ１３へ進む。一致しないのであれば、リピート制御部４７は、ｉを１減少し、ステップＳＴＳ８に戻る。

【0061】

ステップＳＴＳ１３で、処理用クラス・バージョンｋ〜Ｎのインスタンスを全て破棄し、処理を終了する。

【0062】

図７（ｂ）は、処理用クラス・バージョンＮのインスタンスを生成しない場合の例を示す。図７（ａ）と（ｂ）は、基本的に同じであるが、図７（ａ）のステップＳＴＳ４が省略され、図７（ｂ）のステップＳＴＴ５では、図７（ａ）のステップＳＴＳ６と異なり、インスタンス破棄の処理は不要となる。

【0063】

図８を参照して、デシリアライズ処理の一例を説明する。まず、回復処理の開始時に、保存先を指定する。制御部４５は、ｋを、保存対象のインスタンスバージョン番号とし（ステップＳＴＤ１）、型を判断する（ステップＳＴＤ２）。プリミティブ型であれば、回復部４３はプリミティブ回復をし（ステップＳＴＤ３）、処理を終了する。

【0064】

ここで、インスタンス回復は、保存記録媒体から回復(デシリアライズ)することである。クラス型、かつ、メンバID対応の場合、回復対象のメンバを１つ１つ枚挙しつつ回復する。例えば、メンバＩＤが一致するものを回復する。また、保存先指定を無視せずに、メンバＩＤが一致し、かつ、保存先も一致するものを回復するようにしてもよい。例えば、クラス型、かつ、順序対応の場合、回復対象のメンバを１つ１つ枚挙しつつ、保存先が一致しているメンバの値を回復してもよい。枚挙は、例えば、保存時と同じ順序で行うことができる。

【0065】

クラス型であれば、処理クラス・バージョンＮのインスタンスを生成する（ステップＳＴＤ４）。制御部４５は、ｋとＮが一致するか否かを判断する（ステップＳＴＤ５）。一致するならば、処理用クラス・バージョンＮのインスタンスを回復し（ステップＳＴＤ６）、ステップＳＴＤ１７に進む。一致しないならば、リピート制御部４７は、ｉをＮ−１とする（ステップＳＴＤ７）。バージョン・ダウン変換部４９は、処理クラス・バージョンｉのインスタンスを生成する（ステップＳＴＤ８）。制御部４５は、ｉとｋが一致するか否かを判断する（ステップＳＴＤ９）。一致しないならば、リピート制御部４７は、ｉを１減少し、ステップＳＴＤ８に戻る。一致するならば、回復部４３は、処理クラス・バージョンｉのインスタンスを回復する（ステップＳＴＤ１１）。そして、処理用クラス・バージョンｉからｉ＋１へのインスタンス引き継ぎ処理を行う（ステップＳＴＤ１２）。

【0066】

処理用クラス・バージョンiからi+1へのインスタンス引き継ぎ処理は、処理用クラス・バージョンiのインスタンス生成にてアドレスを設定している場合は、特に処理はない。値をコピーしている場合は、処理用クラス・バージョンiの各メンバを、処理用クラス・バージョンi+1の対応するメンバへコピーする。

【0067】

そして、バージョン・アップ変換部５１は、処理用クラス・バージョンｉのインスタンス（Read Only）及び処理用クラス・バージョンｉ＋１のインスタンス（Read/Write）を受け取り、バージョン・アップ変換処理を行う（ステップＳＴＤ１３）。処理用クラス・バージョンiのインスタンス破棄を行う（ステップＳＴＤ１４）。リピート制御部４７は、ｉを１増加する（ステップＳＴＤ１５）。制御部４５は、ｉとＮが一致するか否かを判断する（ステップＳＴＤ１６）。一致しないならば、ステップＳＴＤ１２に戻る。一致するならば、ステップＳＴＤ１７に進む。

【0068】

ステップＳＴＤ１７で、回復部５１は、処理用クラス・バージョンNのインスタンスを破棄する。処理用クラス・バージョンNのインスタンス生成にてアドレスを設定している場合は、特に処理はなし。値をコピーする方法を用いている時は、処理用クラス・バージョンNの各メンバを、ターゲット・クラスの対応するメンバへコピーする。その後、インスタンスを破棄する。

【0069】

処理用クラスのバージョンNを生成しない場合についても、同様に実現することができる。

【0070】

図９は、バージョン・ダウン処理を行わないでデシリアライズ処理を実現する場合の一例である。制御部４５は、ｋを、保存対象のインスタンスバージョン番号とし（ステップＳＴＥ１）、型を判断する（ステップＳＴＥ２）。プリミティブ型であれば、回復部４３は、インスタンス回復をし（ステップＳＴＥ３）、処理を終了する。

【0071】

クラス型であれば、リピート制御部４７は、ｉをｋとする（ステップＳＴＥ４）。回復部４３は、処理用クラス・バージョンｉのインスタンスを生成する（インスタンス生成のみ）（ステップＳＴＥ５）。回復部４３は、処理用クラス・バージョンｉのインスタンスを回復する（ステップＳＴＥ６）。制御部４５は、ｉとＮが一致するか否かを判断する（ステップＳＴＥ７）。

【0072】

一致しないならば、回復部４３は、処理用クラス・バージョンｉ＋１のインスタンスを生成し、処理用クラス・バージョンｉの各メンバを処理用クラス・バージョンｉ＋１の対応するメンバへコピーし（ステップＳＴＥ８）、バージョン・アップ変換処理を行い（ステップＳＴＥ９）、処理用クラス・バージョンｉのインスタンスを破棄する（ステップＳＴＥ１０）。制御部４５は、ｉを１増加して、ステップＳＴＥ７に戻る。

【0073】

一致するならば、回復部４３は、処理用クラス・バージョンＮのインスタンスの各メンバを対応するターゲット・クラスのインスタンスの各メンバへコピーし（ステップＳＴＥ１２）、処理用クラス・バージョンＮのインスタンスを破棄して（ステップＳＴＥ１３）、処理を終了する。

【0074】

現在のシリアライザは、１つのオブジェクト指向言語において、クラスの保存／回復（送信／受信）を容易にしてプログラム開発を支援するにすぎない。今後、複数のオブジェクト指向言語の間で、クラス定義の交換を可能にするシリアライザが登場するであろう。これは、いわば「メタ・シリアライザ」とも表現し得るものである。発明者は、本願発明が、メタ・シリアライザの実現にも貢献できるものと考える。例えば、プリミティブをプログラミング言語ではなくライブラリ等を用いて決めることで、プログラミング言語から独立してシリアライズ・データのフォーマットを決めることができる。例えば図７〜９においてクラス型とプリミティブ型に関する処理が含まれることを利用してデータ交換を実現することができる。例えば文字列型をクラスとして提供するプログラミング言語であれば、図７〜９においてクラス型とプリミティブ型に関する処理が含まれることを利用して文字列型をクラス型ではなくプリミティブ型として実装することにより、文字列型を直接提供するプログラミング言語とのデータ交換を可能とすることができる。

【符号の説明】

【0075】

１ シリアライズ・データ処理装置、３ ソース・プログラム記憶部、５ バージョン管理テーブル記憶部、７ 旧バージョン定義記憶部、９ インスタンス記憶部、１１ シリアライズ・データ記憶部、１５ ソース生成部、１７ コンパイル部、１９ シリアライズ処理部、２１ バージョン・ダウン関数部、２５ バージョン・アップ関数部、２９ 保存処理部、３１ 回復処理部、４１ 保存部、４３ 回復部、４５ 制御部、４７ リピート制御部、４９ バージョン・ダウン変換部、５１ バージョン・アップ変換部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】