JP4524750B2 - モデル駆動開発装置、モデル駆動開発方法及びモデル駆動開発プログラム - Google Patents

Description

本発明は、モデル駆動開発によるソースファイルの自動生成方法において、モデル、変換ルール、ソースファイルのバージョン管理による効率的な自動生成方法に関するものである。

近年、ＵＭＬ（Unified Modeling Language：統一モデリング言語）等の標準化されたモデリング手法を用いて開発すべきプログラムのソースコードの自動生成を行うモデル駆動開発（「モデル駆動型アーキテクチュア（ＭＤＡ：Model Driven Architecture」とも言う）と呼ばれるソフトウェア開発手法が注目されている。

このモデル駆動開発によれば、アプリケーションの機能をモデル化し、これを基にジェネレータなどの専用ツールを使ってプログラムのソースコードを自動生成する。ジェネレータには、自動生成で用いる変換ルールが、予め設定されている。

図１４は、従来技術のモデル駆動開発の方法を概念的に説明するものである。この方法では、対象とするアプリケーションをモデリングしたモデル３３０全体及び変更ルール全体は、１つのバージョンで管理されている。このモデル３３０からジェネレータ３４０を使ってプログラムのソースファイルを作り出す。ソースファイル１（３５１）は、モデル３３０の要素３と要素２２の情報を元に変換ルール１を用いてジェネレータ３４０で生成される。他のソースファイル２（３５２）、ソースファイル３（３５３）も同様である。

よって、どのモデル要素または変換ルールが変更された場合でも全てのプログラム要素を再生成する必要がある。例えば、要素２２だけ変更された場合でもモデル３３０全体がバージョン変更になり、モデル３３０全体を使用して、全ソースファイルを再生成する。ジェネレータ３４０の変換ルールが一部変更された場合も、ジェネレータ３４０全体のバージョンが変更されるので、全ソースファイルを再生成する。

また、モデル駆動開発と別分野であるが、従来のプログラム及び文書情報に関するバージョン管理システムの一例が、特許文献１に記載されている。特許文献１は、一つのソースコード変更が他の複数の文書ファイルに影響を及ぼしていくものである。また、特許文献２及び３は、１つのソースプログラムの１つの差分情報の変更により、更新されバージョンアップした場合、アプリケーションプログラムは全体としてバージョンがアップしてしまうものである。
特開２００２−１８２９０８号公報（［００１０］〜［００２９］［００４５］、図１ 図６ 図７ 図９ 図１３ 図１５） 特開２０００−２００１８５号公報（［００１３］〜［００１９］［００２３］［００２４］、図１ 図３ 図６ 図７） 特開平１１−３２７８７８号公報（［００１４］［００２６］［００３３］、図１ 図２ 図５ 図８）

従来技術のモデル駆動開発において、単純な自動生成では、モデルや変換ルールの一部が変更された場合でも、モデル全体からソースファイル全部を再生成する。これでは、モデルが大きい場合、再生成に時間がかかり非効率である。また、モデルや変換ルールの一部が変更された場合でも、全生成物である全ソースファイルのバージョンが変更されてしまうものである。

そこで、本発明は、モデル駆動開発におけるモデルや変換ルールの一部の要素のみが更新された場合でも、プログラムのソースファイル全部が再生成されることなく、効率的にプログラムの再生成が行えるようにすることを課題とする。

また、モデル要素や生成物の要素に実質上変化がない場合はバージョンが変更されないようにし、生成物の本質的差分だけがすばやく分かることである。

本発明に係るモデル駆動開発装置は、モデル駆動開発手法を用いて開発すべきプログラムのモデルから所定の変換ルールにより前記プログラムのソースファイルを生成するモデル駆動開発装置において、前記モデルを前記生成の変換の基本となる単位である複数のモデル要素に分割し個々の前記モデル要素にバージョンを付与し、前記変換ルールを構成する複数の変換ルールを前記モデル要素と対応付けられた複数の変換ルール要素として、個々の前記変換ルール要素にバージョンを付与し、前記モデル及び／又は前記変換ルールが変更されるとき、変更する前記モデル要素のみ及び／又は前記変換ルール要素のみ、バージョンを更新する制御手段と、複数の前記モデル要素とそのバージョンを記憶し、複数の前記変換ルール要素とそのバージョンを記憶し、複数の生成されたソースファイルであるプログラム要素と、前記プログラム要素を生成したときの前記モデル要素のバージョンと前記変換ルール要素のバージョンを対応付けて記憶する記憶媒体と、前記複数の変換ルール要素のバージョンを取得する変換ルール要素バージョン取得手段と、前記複数のモデル要素のバージョンを取得するモデル要素バージョン取得手段と、前記モデル要素バージョン取得手段により取得された前記モデル要素のバージョンと対応する前記プログラム要素の生成したときのモデル要素のバージョンとを比較するとともに、前記変換ルール要素バージョン取得手段により取得された前記変換ルール要素のバージョンと対応する前記プログラム要素の生成したときの変換ルール要素のバージョンとを比較して結果を出力するバージョン比較手段と、前記バージョン比較手段から、前記モデル要素のバージョンと対応する前記プログラム要素の生成したときのモデル要素のバージョンが一致しないか、前記変換ルール要素のバージョンと対応する前記プログラム要素の生成したときの変換ルール要素のバージョンが一致しない前記結果を受けたとき、該モデル要素と該変換ルール要素を用いてプログラム要素を生成し、該モデル要素のバージョンと該変換ルール要素のバージョンを付加して前記記憶媒体に書き込むプログラム生成手段と、を有することを特徴とする。

モデル駆動開発装置は、モデル要素はエンティティ又はコントロール又はバウンダリからなることを特徴とする上記のモデル駆動開発装置である。

本発明のモデル駆動開発装置によれば、モデルをモデル要素に分割し、各要素にバージョンを付与するように構成され、変換ルールを変換ルール要素に分割し、各要素にバージョンを付与するように構成されているので、モデルの一部のモデル要素が変更された場合又は変換ルールの一部の変換ルール要素が変更された場合に、バージョン比較によりその要素の新しいバージョンによる自動生成しか行われないのでプログラム要素の無駄な再生成を防止できる。

以下、本発明の実施の形態について図面を用いて詳細に説明する。

モデル駆動開発装置は、モデル駆動開発におけるモデルを自動生成時の変換の基本となる単位である要素に分割し、個々の要素にバージョンを付与する。このバージョンは、各々の要素が変更された場合にのみ変更する。他の要素が変更されても、当該要素が変更されない場合はバージョンは以前と同一とする。自動生成に使用する変換ルールにもバージョンを付与する。変換ルールも、分割し、個々の変換ルール要素にバージョンを付与する。

自動生成されるプログラム要素には、対応する全てのモデル要素と変換ルール要素のバージョンを格納する。変換ルール要素やモデル要素のバージョンが前回生成時と同じ場合はそのプログラム要素を自動生成しない。これにより、モデルの一部のモデル要素のみが更新された場合、その変更に対応するプログラム要素のみが自動生成され、効率的に再生成が行える。

［実施形態１］
図１に、本発明の実施形態１のモデル駆動開発の方法を示す。モデル３０は複数のモデル要素を備える。各モデル要素ごとに１つずつのバージョンを設ける。

モデル３０は、モデル要素１、モデル要素２、モデル要素３、モデル要素２１、モデル要素２２から構成されている。モデル３０は、バージョン１．１である。モデル要素１、モデル要素２、モデル要素３は、直接モデルに属しており、バージョンはそれぞれバージョン１．２、バージョン１．１、バージョン１．１である。モデル要素２１とモデル要素２２は、モデル要素２に属しており、バージョンはそれぞれバージョン１．１、バージョン２．１である。

モデル駆動開発装置４０は、制御手段４１とジェネレータ４２からなる。

制御手段４１は、モデル３０がモデル駆動開発装置４０内に記憶されている場合は、モデル３０の制御を行う。制御手段４１は、モデル３０を各モデル要素に分割し、バージョンを付与する。モデル要素の変更時には、該当するモデル要素のバージョンを更新する。

モデル３０とその各要素は他のＰＣから与えられる場合や他のＰＣで更新を受ける場合もある。よって、このモデル３０の分割やバージョン付与、更新の機能を持たない制御手段を用いたモデル駆動開発装置４０も構成できる。

ジェネレータ４２は複数の変換ルール要素を備え、それぞれのソースファイルを生成する。モデル要素と使用される変換ルール要素は線と矢印で繋げられている。ジェネレータ４２の変換ルール要素ごとにも１つのバージョンを設ける。ジェネレータ４２には、変換ルール要素１（４３）、変換ルール要素２（４４）、変換ルール要素３（４５）があり、バージョンはそれぞれバージョン１．１、バージョン２．１、バージョン１．１であり、それぞれソースファイル１（５１）、ソースファイル２（５２）、ソースファイル３（５３）を生成する。

これにより、例えば、モデル要素２２だけのバージョンが変更された場合、変換ルール要素１（４１）を用いてソースファイル１（５１）だけが再生成となる。また、ジェネレータ４２の変換ルール要素２（４２）だけが変更された場合は、モデル要素２、モデル要素２１を用いてソースファイル２（５２）のみを再生成する。

次に、図２に、本発明の実施形態１の機能構成図を示す。コンピュータ１００は、モデル駆動開発装置４０となる。コンピュータ１００は、上述の図１の制御手段４１とジェネレータ４２を構成する。

プログラム制御により動作するコンピュータ１００は、モデル記憶手段１１０と、 変換ルール記憶手段１２０と、プログラム記憶手段１３０と 、変換ルール要素バージョン取得手段１４０と、モデル要素バージョン取得手段１５０と、プログラム要素バージョン取得手段１６０と、バージョン比較手段１７０と、モデル要素取得手段１８０と、変換ルール要素取得手段１９０と、プログラム生成手段２００と、上位制御手段２３０とを含む構成である。

図３は、このコンピュータ１００のハードウェア構成図である。ＣＰＵ（Central Processing Unit）２５０は、変換ルール要素バージョン取得手段１４０と、モデル要素バージョン取得手段１５０と、プログラム要素バージョン取得手段１６０と、バージョン比較手段１７０の制御と、モデル要素取得手段１８０と、変換ルール要素取得手段１９０と、プログラム生成手段２００と、上位制御手段２３０の制御の機能を行う。揮発性メモリ２６０は、バージョン比較手段１７０の一時記憶とプログラム生成手段２００の一時記憶の機能を行う。ハードディスク２７０は、モデル記憶手段１１０と、変換ルール記憶手段１２０と、プログラム記憶手段１３０の機能を行う。２８０は、ＣＰＵ２５０、揮発性メモリ２６０、不揮発性メモリ２７０を結ぶバスである。

機能構成図の各部を説明する。モデル記憶手段１１０は、モデル３０を、構成するモデル要素ごとにバージョン番号を付与可能な形式で記憶する。モデル３０は３種類のモデル要素、すなわち、後述するエンティティ３１、コントロール３２、バウンダリ３３からなる。

変換ルール記憶手段１２０は、変換ルールを、変換ルール要素ごとにバージョン番号を付与可能な形式で記憶する。

プログラム記憶手段１３０は、プログラム生成手段２００が生成したプログラムを、プログラム要素のファイルごとにバージョン番号を付与可能な形式で記憶する。プログラム要素には、後述するＤＢ（Database）ソースファイル３５、ＥＪＢ（Enterprise Java(登録商標）Beans）ソースファイル３６、ＪＳＰ（Java(登録商標）Server Pages）ソースファイル３７がある。

なお、プログラム要素は、図１でのソースファイルに相当する。

変換ルール要素バージョン取得手段１４０は、変換ルール要素のバージョン番号を変換ルール記憶手段１２０から取得し、バージョン比較手段１７０に送る。モデル要素バージョン取得手段１５０は、モデル要素のバージョン番号をモデル記憶手段１１０から取得し、バージョン比較手段１７０に送る。

プログラム要素バージョン取得手段１６０は、変換ルール要素とモデル要素に対応するプログラム要素のバージョンをプログラム記憶手段１３０から検索して取得し、バージョン比較手段１７０に送る。つまり、該当するプログラム要素に対応したプログラム要素生成時の変換ルール要素バージョンとモデル要素バージョンをプログラム記憶手段１３０から取得し、バージョン比較手段１７０に送る。ここで、プログラム要素のバージョンとは、プログラム要素に対応したプログラム要素生成時の変換ルール要素バージョンとモデル要素バージョンを指す。

バージョン比較手段１７０は、変換ルール要素とモデル要素に対応するプログラム要素のバージョンが、変換ルール要素のバージョンとモデル要素のバージョンに一致するかどうかを比較する。つまり、対応するプログラム要素のプログラム要素生成時の変換ルール要素バージョンとモデル要素バージョンが、指定された変換ルール要素のバージョンとモデル要素のバージョンに一致するかどうかを比較する。そして、すべて一致する場合のみ比較結果trueを返す。他の場合は比較結果falseを返す。

モデル要素取得手段１８０は、モデル記憶手段１１０からモデル要素の情報を取得する。
変換ルール要素取得手段１９０は、変換ルール記憶手段１２０から変換ルール要素の情報を取得する。

プログラム生成手段２００は、変換ルール要素取得手段１９０から取得した変換ルール要素と、変換ルール要素に入力するモデル要素をバージョン比較手段に渡し、該当するプログラム要素とバージョンが一致するかどうかを計算させ、一致しない場合はモデル要素取得手段１８０から取得したモデル要素と、すでに取得済みの変換ルール要素を用いて対応するプログラム要素を生成し、モデル要素と変換ルール要素のバージョン情報を追加した後、プログラム記憶手段１３０に格納する。一致した場合はプログラム要素を生成しない。

上位制御手段２３０は、バージョン比較手段１７０とプログラム生成手段２００の上位の制御手段として制御を行う。上位制御手段２３０は、モデルがモデル記憶手段に記憶されている場合は、モデル要素に分割し、各モデル要素にバージョンを付与する。モデル要素の変更、バージョンの更新も行う。また、変換ルール記憶手段１２０に変換ルールが記憶されている場合は、変換ルール要素に分割し、各変換ルール要素にバージョンを付与する。変換ルール要素の変更、バージョンの更新も行う。

なお、モデル及び変換ルールは、モデル要素に分割し、各モデル要素にバージョンを付与されたもの及び変換ルール要素に分割し、各変換ルール要素にバージョンを付与されたものを外部のＰＣ等から得る場合もある。また、他のＰＣで更新を受けたものが書き込まれる場合もある。

図４に、プログラム記憶手段１３０上のプログラム要素を示す。プログラム要素に対応したプログラム要素生成時の変換ルール要素バージョンとモデル要素バージョンを記憶する。これにより、プログラム要素から、生成に使用した変換ルール要素とモデル要素のバージョンをトレースすることができ、障害調査に有効活用できる。

図５に、モデル要素から構成されたモデル３０の例を示す。この例では、上述したように、モデル３０は、モデル駆動のモデリングによるオブジェクトである３種類のモデル要素からなる。すなわち、ひとまとまりの情報を持つ実体でありデータベースの表定義に相当するエンティティ３１、演算操作や処理を行いプログラムの制御を司るものであるコントロール３２、画面や帳票印刷など、外部世界とコンピュータの世界をつなぐ入出力情報であるバウンダリ３３からなる。なお、エンティティの属性は、エンティティの要素となる情報であり、コントロールの操作は、他のクラスつまりエンティティやバウンダリに対する処理を実行する部分であり、バウンダリの属性は、バウンダリの要素となる情報である。

エンティティ３１、コントロール３２、バウンダリ３３はそれぞれ任意個存在する。コントロール３２はエンティティ３１を、バウンダリ３３はコントロール３２をそれぞれ任意個参照する。

図６（ａ）は、モデル３０の３種類のモデル要素を、矢印で示される３つの変換ルール要素でＤＢソースファイル３５、ＥＪＢソースファイル３６、ＪＳＰソースファイル３７という３種類のプログラム要素に変換つまり自動生成する様子を、図６（ｂ）は、モデル要素とプログラム要素と変換ルール要素の対応表を示す。これらを合わせて説明する。

図６（ａ）において、エンティティ３１は、変換ルール要素１によってＤＢソースファイル３５に変換される。コントロール３２は、エンティティ３１を参照し変換ルール要素２によってＥＪＢソースファイル３６に変換される。バウンダリ３３は、コントロール３２を参照し変換ルール要素３によってＪＳＰソースファイル３７に変換される。

ここで、変換されたプログラム要素であるソースファイルを説明する。

ＤＢソースファイル３５は、エンティティ３１に対応するデータベースとしてのソースファイルである。ＥＪＢソースファイル３６は、コントロール３２とエンティティ３１に対応するＪａｖａ(登録商標）のコンポーネント仕様Ｊａｖａ(登録商標）Ｂｅａｎｓをサーバ側で使えるように拡張したソースファイルである。ＥＪＢ対応のソフトウエア部品は、いろいろなｊａｖａ(登録商標）プログラムから共有できる。ＪＳＰソースファイル３７は、バウンダリ３３とコントロール３２に対応するＪａｖａ(登録商標）を使ったＷｅｂアプリケーション実行環境のソースファイルであり、Ｊａｖａ(登録商標）コードをＨＴＭＬ文中に埋め込んだファイルをＷｅｂサーバ側で実行してその結果をＷｅｂブラウザに戻す。

次に図６（ｂ）の対応表を説明する。モデル要素とプログラム要素の変換と、その変換を行う変換ルール要素が番号ごとに示される。

次に、変換ルール要素を説明する。なお、実施例を図７から図１０で後述する。

変換ルール要素１は、エンティティ３１ひとつにつきデータベースつまりＤＢ３５の表を１つ生成する。エンティティ３１の属性をＤＢソースファイル３５の列に変換する。例えば、入力項目が、データベースの項目に変換される。

変換ルール要素２は、コントロール３２の１つにつき、ＥＪＢソースファイル３６を１つ作成する。コントロール３２の操作を、ＥＪＢのメソッドに変換する。ＥＪＢのメソッドとは、ＥＪＢの属性つまりＥＪＢの要素となる情報を操作するための処理を実行する部分である。また、コントロール３２が参照するエンティティ３１に対応するＤＢソースファイル３５を取得するためのＳＱＬ（Structured query language）文を生成する。例えば、入力の操作や使用するＤＢを聞くＳＱＬ文をＥＪＢに設ける。

変換ルール要素３は、バウンダリ３３の１つにつき、ＪＳＰソースファイル３７を１つ生成する。バウンダリ３３の属性をＪＳＰソースファイル３７のＩＮＰＵＴに変換する。ＪＳＰのＩＮＰＵＴとは、ＪＳＰに配置される入力領域である。バウンダリ３３が参照しているコントロール３２をＪＳＰソースファイル３７上にＪａｖａ(登録商標）のコンポーネント仕様であるＪａｖａ(登録商標）Ｂｅａｎｓを生成する。例えば、入力画面の項目をＪＳＰの入力項目とする。また、入力という操作をＪＳＰ内にＪａｖａ(登録商標）Ｂｅａｎｓとして生成する。

ここで、図６（ａ）に示すように、プログラム要素のＤＢソースファイル３５はモデル要素のエンティティ３１と変換ルール要素１に依存し、プログラム要素のＥＪＢソースファイル３６はモデル要素のエンティティ３１とコントロール３２ならびに変換ルール要素２に依存し、プログラム要素のＪＳＰソースファイル３７はモデル要素のコントロール３２とバウンダリ３３ならびに変換ルール要素３に依存する。

本発明の技術を使用することにより、プログラム要素の再生成範囲が限定される。すなわち、図６（ａ）からわかるように、エンティティ３１のみが変更された場合はＪＳＰソースファイル３７の生成は不要であり、コントロール３２のみが変更された場合はＥＪＢソースファイル３６の生成は不要であり、バウンダリ３３のみが変更された場合はＤＢソースファイル３５とＥＪＢソースファイル３６の生成は不要となる。また、変換ルール要素１のみが変更された場合はＥＪＢソースファイル３６とＪＳＰソースファイル３７の生成は不要であり、変換ルール要素２のみが変更された場合はＤＢソースファイル３５とＪＳＰソースファイル３７の生成は不要であり、変換ルール要素３のみが変更された場合はＤＢソースファイル３５とＥＪＢソースファイル３６の生成は不要である。いずれの場合も、常に生成されたプログラム要素ごとに、生成時に使用された変換ルール要素やモデル要素のバージョンを取得できる。

図７に、図６に対応する実施例である売上管理モデルを示し説明する。図７（ａ）が変換の例であり、図７（ｂ）が対応表である。対応表の変換ルール要素は、上述のものと同じである。

図７（ａ）では、モデル３０が売上管理モデル６０であり、エンティティ３１である売上入力画面６３で入力されたデータをバウンダリ３３である売上ＤＢ６１に、コントロール３２である入力制御６２の制御により格納し保存するというアプリケーションである。これを変換ルールにより変換する。

この結果、売上ＤＢ６１は、変換ルール要素１によってＤＢソースファイル３５であるＵＲＩＡＧＥ＿ＴＡＢＬＥ６５に変換される。入力制御６２は、売上ＤＢ６１を参照し変換ルール要素２によってＥＪＢソースファイル３６であるＵｒｉａｇｅＢｅａｎ６６に変換される。売上入力画面６３は、入力制御６２を参照し変換ルール要素３によってＪＳＰソースファイル３７であるＵｒｉａｇｅ．ＪＳＰ６７に変換される。

図７（ｂ）の対応表では、モデル要素とプログラム要素の具体例を示している。モデル要素のエンティティが「売上ＤＢ」であり、コントロールが「入力制御」、バウンダリが「売上入力画面」である。プログラム要素のＤＢつまりデータベース表が「ＵＲＩＡＧＥ＿ＴＡＢＬＥ」であり、ＥＪＢが「ＵｒｉａｇｅＢｅａｎ」、ＪＳＰが「Ｕｒｉａｇｅ．ＪＳＰ」である。

図８は、変換ルール要素１による変換の詳細例である。図８（ａ）では、売上ＤＢ６１につき、データベース表「ＵＲＩＡＧＥ＿ＴＡＢＬＥ」が作成され、売上ＤＢ６１の属性である日付、顧客、品名、単価、個数、合価がそれぞれ、ＵＲＩＡＧＥ＿ＴＡＢＬＥ６５の列である「Ｄａｔｅ ＤＡＴＥＴＩＭＥ」、「Ｃｕｓｔ ＮＵＭＢＥＲ（５）」、「Ｉｔｅｍ ＶＡＲＣＨＡＲ（２０）」、「Ｐｒｉｃｅ ＮＵＭＢＥＲ（１０）」、「Ｎｕｍ ＮＵＭＢＥＲ（５）」、「Ｓｕｍ ＮＵＭＢＥＲ（２０）」に変換されることを示す。図８（ｂ）は、図７（ｂ）の対応表内の変換ルール要素１のみの対応表を示す。

図９は、変換ルール要素２による変換の詳細例である。図９（ａ）では、入力制御６２につき、ＥＪＢである「ＵｒｉａｇｅＢｅａｎ」が作成され、入力制御６２の操作である「入力する」をＵｒｉａｇｅＢｅａｎのメソッドに変換するとともに、入力制御６２が参照する売上ＤＢ６１に対応するＤＢを取得するためのＳＱＬ文をメソッド内に作成することを示す。図９（ｂ）は、図７（ｂ）の対応表内の変換ルール要素２のみの対応表を示す。

図１０は、変換ルール要素３による変換の詳細例である。図１０（ａ）では、売上入力画面６３につき「Ｕｒｉａｇｅ．ＪＳＰ」が作成され、売上入力画面６３の属性である日付、顧客、品名、単価、個数、合価がそれぞれ、変換ルール要素３によって、Ｕｒｉａｇｅ．ＪＳＰ６７のＩＮＰＵＴである日付、顧客、品名、単価、個数、合価に変換されるとともに、売上入力画面６３が参照している入力制御６２をＵｒｉａｇｅ．ＪＳＰ上にＪａｖａ(登録商標）Ｂｅａｎｓとして生成する。これにより、入力制御６２により売上入力画面６３の入力がＵｒｉａｇｅ．ＪＳＰに入る。図１０（ｂ）は、図７（ｂ）の対応表内の変換ルール要素３のみの対応表を示す。

次に、図１１及び図１２のフローチャートを参照して本発明の実施形態１の動作について詳細に説明する。

初めに図１１のフローチャートを説明する。図中ステップＡ３及びＡ４のバージョンが一致しているかの比較の動作は、図１２のフローチャートで詳細に示す。

まず、変換ルール要素取得手段１９０が、変換ルール記憶手段１２０から変換ルール要素を取得する（ステップＡ１）。次に、モデル要素取得手段１８０が、変換ルール要素に対応するモデル要素をモデル記憶手段１１０から取得する（ステップＡ２）。

プログラム生成手段２００は、変換ルールとモデル要素を取得し、バージョン比較手段１７０に送る。バージョン比較手段１７０は、変換ルールとモデル要素のバージョンを対応するプログラム要素のバージョンと比較する（ステップＡ３、詳細は図８）。 バージョンが一致する場合は、モデル要素も変換ルール要素も更新されていないため、ステップＡ９へ進む（ステップＡ４）。

バージョンが一致しない場合は、モデル要素または変換ルール要素が更新されているため、引き続き対応するプログラム要素をプログラム生成手段２００にて生成する。モデル要素の情報を、取得した変換ルール要素の変換ルールに基づき変換し、プログラム要素を生成する（ステップＡ５）。次に、プログラム要素に、変換に使用したモデル要素のバージョンを書き込む（ステップＡ６）。さらに、プログラム要素に、変換に使用した変換ルールのバージョンも書き込む（ステップＡ７）。最後に、プログラム要素をプログラム記憶手段１３０に記憶する（ステップＡ８）。そして、処理したモデル要素が最後のモデル要素かどうかチェックする（ステップＡ９）。最後でなければステップＡ２に戻る。最後であれば、処理に使用した変換ルール要素が最後かどうかをチェックする（ステップＡ１０）。 最後でなければステップＡ１に戻る。最後であれば終了する。

次に図１２のフローチャートを用いてＡ３及びＡ４のバージョン比較を説明する。

バージョンの一致の確認は、まず、バージョン比較手段１７０が、変換ルール要素とモデル要素に対応するプログラム要素をプログラム要素バージョン取得手段１６０を介してプログラム記憶手段１３０から検索して取得する（ステップＢ１）。対応するプログラム要素が存在するかどうかチェックする（ステップＢ２）。存在しない場合は、変換ルール要素又はモデル要素が追加された場合であるから「バージョンは不一致」という結果で上位の制御手段に返す。対応するプログラム要素は不存在、新規にプログラム要素が作られることになる（ステップＢ７）。存在する場合は、バージョン比較手段１７０が、プログラム要素生成時の対応づけられた変換ルール要素のバージョンをプログラム要素バージョン取得手段１６０を介してプログラム記憶手段１３０から取得する（ステップＢ３）。このバージョンと、現在の変換ルール要素のバージョンを比較する（ステップＢ４）。バージョンが一致しない場合は、「バージョンは不一致」という結果を上位の制御手段に返す（ステップＢ７）。一致する場合は、バージョン比較手段１７０が、プログラム要素生成時の対応づけられたモデル要素のバージョンをプログラム要素バージョン取得手段１６０を介してプログラム要素記憶手段１３０から取得する（ステップＢ５）。モデル要素は複数存在する可能性があるが、その場合は全て取得しておく。バージョン比較手段１７０は、これらのバージョンと、現在のモデル要素のバージョンを比較する（ステップＢ６）。バージョンが一致しない場合は、「バージョンは不一致」という結果を上位の制御手段に返す（ステップＢ７）。一致する場合は、「バージョンは一致」という結果を上位の制御手段に返す（ステップＢ８）。

［実施形態２］
次に、本発明の実施形態２の構成について図面を参照して詳細に説明する。

図１３に実施形態２の構成を示す。本発明の実施形態２の構成は、実施形態１の構成に、モデル編集手段２１０と、変換ルール編集手段２２０とを追加した構成である。
実施形態１では、上位制御手段２３０で行う機能の内、モデル編集、変更ルール編集をモデル編集手段２１０と、変換ルール編集手段２２０で行う。
実施形態１で示した構成及び動作の説明は省略する。

コンピュータ１００は、モデル編集手段２１０と、変換ルール編集手段２２０とを含む。

モデル編集手段２１０は、モデルをモデル記憶手段１１０から読み込み、要素の追加、要素の削除、要素の内容変更を行い、モデル記憶手段１１０に書き戻す。その際、変更が行われたモデル要素のバージョン情報を更新し、以前のモデル要素とバージョンの区別がつくようにする。

変換ルール編集手段２２０は、変換ルールを変換ルール記憶手段１２０から読み込み、変換ルールの追加、変換ルールの削除、変換ルールの内容変更を行い、変換ルール記憶手段１２０に書き戻す。その際、変更が行われた変換ルール要素のバージョン情報を更新し、以前の変換ルール要素とバージョンの区別がつくようにする。

上位制御手段２３０は、モデル編集手段２１０と変換ルール編集手段２２０の制御を行う。

次に、本発明の実施形態２の効果について説明する。

本発明の実施形態２では、モデルをモデル編集手段２１０で編集することにより、各要素のバージョンを自動的に更新するように構成されているため、モデルが変更された場合 のバージョン更新作業の手間を省き、正確なバージョンを付与できる。
また、実施形態２では、変換ルールを変換ルール編集手段２２０で編集することにより、各要素のバージョンを自動的に更新するように構成されているため、変換ルールが変更された場合のバージョン更新作業の手間を省き、正確なバージョンを付与できる。

なお、本発明は上述の説明した実施の形態に限定されるものではなく、本発明の精神を逸脱することなく種々の変形が可能とされるものである。

本発明によれば、モデル駆動開発における自動生成といった分野に適用できる。また、 ハードウェアやミドルウェアのモデルから、保守ドキュメントを自動生成するといった用途にも適用可能である。

本発明の実施形態１のモデル駆動開発の方法である。 本発明の実施形態１の構成図である。 本発明の実施形態１のハードウェア構成図である。 本発明のプログラム記憶手段上のプログラム要素である。 本発明のモデル要素から構成されたモデルの例である。 （ａ）本発明のモデルを変換ルール要素でプログラム要素に変換する例である。（ｂ）本発明のモデル要素とプログラム要素と変換ルール要素の対応表である。 （ａ）本発明のモデルを変換ルール要素でプログラム要素に変換する実施例である。（ｂ）本発明のモデル要素とプログラム要素と変換ルール要素の対応表の実施例である。 （ａ）本発明のエンティティを変換ルール要素１で変換する実施例である。（ｂ）本発明のエンティティとプログラム要素の対応表の実施例である。 （ａ）本発明のコントロールを変換ルール要素２で変換する実施例である。（ｂ）本発明のコントロールとプログラム要素の対応表の実施例である。 （ａ）本発明のバウンダリを変換ルール要素３で変換する実施例である。（ｂ）本発明のバウンダリとプログラム要素の対応表の実施例である 本発明の実施形態１の動作のフローチャートである。 本発明の実施形態１のバージョン比較の動作のフローチャートである。 本発明の実施形態２の構成図である。 従来のモデル駆動開発の方法である。

符号の説明

１ モデル要素
２ モデル要素
３ モデル要素
２１ モデル要素
２２ モデル要素
３０ モデル
３１ エンティティ
３２ コントロール
３３ バウンダリ
３５ ＤＢソースファイル
３６ ＥＪＢソースファイル
３７ ＪＳＰソースファイル
４０ モデル駆動開発装置
４１ 制御手段
４２ ジェネレータ
４３ 変換ルール要素１
４４ 変換ルール要素２
４５ 変換ルール要素３
５１ ソースファイル１
５２ ソースファイル２
５３ ソースファイル３
６０ 売上管理モデル
６１ 売上ＤＢ
６２ 入力制御
６３ 売上入力画面
６５ ＵＲＩＡＧＥ＿ＴＡＢＬＥ
６６ ＵｒｉａｇｅＢｅａｎ
６７ Ｕｒｉａｇｅ．ＪＳＰ
１００ コンピュータ
１１０ モデル記憶手段
１２０ 変換ルール記憶手段
１３０ プログラム記憶手段
１４０ 変換ルール要素バージョン
１５０ モデル要素バージョン取得手段
１６０ プログラム要素バージョン取得手段
１７０ バージョン比較手段
１８０ モデル要素取得手段
１９０ 変換ルール要素取得手段
２００ プログラム生成手段
２１０ モデル編集手段
２２０ 変換ルール編集手段
２３０ 上位制御手段
２５０ ＣＰＵ
２６０ 揮発性メモリ
２７０ ハードディスク
２８０ バス
３３０ モデル
３４０ ジェネレータ
３５１ ソースファイル１
３５２ ソースファイル２
３５３ ソースファイル３

Claims (8)

1. モデル駆動開発手法を用いて開発すべきプログラムのモデルから所定の変換ルールにより前記プログラムのソースファイルを生成するモデル駆動開発装置において、
   前記モデルを前記生成の変換の基本となる単位である複数のモデル要素に分割し個々の前記モデル要素にバージョンを付与し、前記変換ルールを構成する複数の変換ルールを前記モデル要素と対応付けられた複数の変換ルール要素として、個々の前記変換ルール要素にバージョンを付与し、前記モデル及び／又は前記変換ルールが変更されるとき、変更する前記モデル要素のみ及び／又は前記変換ルール要素のみ、バージョンを更新する制御手段と、
   複数の前記モデル要素とそのバージョンを記憶し、複数の前記変換ルール要素とそのバージョンを記憶し、複数の生成されたソースファイルであるプログラム要素と、前記プログラム要素を生成したときの前記モデル要素のバージョンと前記変換ルール要素のバージョンを対応付けて記憶する記憶媒体と、
   前記複数の変換ルール要素のバージョンを取得する変換ルール要素バージョン取得手段と、
   前記複数のモデル要素のバージョンを取得するモデル要素バージョン取得手段と、
   前記モデル要素バージョン取得手段により取得された前記モデル要素のバージョンと対応する前記プログラム要素の生成したときのモデル要素のバージョンとを比較するとともに、前記変換ルール要素バージョン取得手段により取得された前記変換ルール要素のバージョンと対応する前記プログラム要素の生成したときの変換ルール要素のバージョンとを比較して結果を出力するバージョン比較手段と、
   前記バージョン比較手段から、前記モデル要素のバージョンと対応する前記プログラム要素の生成したときのモデル要素のバージョンが一致しないか、前記変換ルール要素のバージョンと対応する前記プログラム要素の生成したときの変換ルール要素のバージョンが
   一致しない前記結果を受けたとき、該モデル要素と該変換ルール要素を用いてプログラム要素を生成し、該モデル要素のバージョンと該変換ルール要素のバージョンを付加して前記記憶媒体に書き込むプログラム生成手段と、
   を有することを特徴とするモデル駆動開発装置。
2. モデル駆動開発手法を用いて開発すべきプログラムのモデルから所定の変換ルールにより前記プログラムのソースファイルを生成するモデル駆動開発装置において、
   複数のモデル要素とそのバージョンを記憶し、複数の変換ルール要素とそのバージョンを記憶し、複数の生成されたソースファイルであるプログラム要素と、前記プログラム要素を生成したときの前記モデル要素のバージョンと前記変換ルール要素のバージョンを対応付けて記憶する記憶媒体と、
   前記複数の変換ルール要素のバージョンを取得する変換ルール要素バージョン取得手段と、
   前記複数のモデル要素のバージョンを取得するモデル要素バージョン取得手段と、
   前記モデル要素バージョン取得手段により取得された前記モデル要素のバージョンと対応する前記プログラム要素の生成したときのモデル要素のバージョンとを比較するとともに、前記変換ルール要素バージョン取得手段により取得された前記変換ルール要素のバージョンと対応する前記プログラム要素の生成したときの変換ルール要素のバージョンとを比較して結果を出力するバージョン比較手段と、
   前記バージョン比較手段から、前記モデル要素のバージョンと対応する前記プログラム要素の生成したときのモデル要素のバージョンが一致しないか、前記変換ルール要素のバージョンと対応する前記プログラム要素の生成したときの変換ルール要素のバージョンが一致しない前記結果を受けたとき、該モデル要素と該変換ルール要素を用いてプログラム要素を生成し、該モデル要素のバージョンと該変換ルール要素のバージョンを付加して前記記憶媒体に書き込むプログラム生成手段と、
   を有することを特徴とするモデル駆動開発装置。
3. 前記複数のモデル要素は、エンティティ、コントロール及びバウンダリを含むものであることを特徴とする請求項１又は２に記載のモデル駆動開発装置。
4. 前記モデルの前記モデル要素を編集し、変更するモデル要素のバージョンを更新するモデル編集手段と、前記変換ルールの前記変換ルール要素を編集し、変更する変換ルール要素のバージョンの更新を行う変換ルール編集手段とを更に有する請求項２に記載のモデル駆動開発装置。
5. モデル駆動開発手法を用いて開発すべきプログラムのモデルを変換ルールにより前記プログラムのソースファイルを生成するモデル駆動開発装置が、制御手段、変換ルール要素バージョン取得手段、モデル要素バージョン取得手段、バージョン比較手段、プログラム生成手段、及び記憶媒体で構成され、前記記憶媒体が、複数のモデル要素とそのバージョンを記憶し、複数の変換ルール要素とそのバージョンを記憶し、複数の生成されたソースファイルであるプログラム要素と、前記プログラム要素を生成したときの前記モデル要素のバージョンと前記変換ルール要素のバージョンを対応付けて記憶するためのものである、モデル駆動開発方法において、
   前記制御手段が、前記モデルを前記生成の変換の基本となる単位である複数のモデル要素に分割し個々の前記モデル要素にバージョンを付与し、前記変換ルールを構成する複数の変換ルールを前記モデル要素と対応付けられた複数の変換ルール要素として、個々の前記変換ルール要素にバージョンを付与し、前記モデル及び／又は前記変換ルールが変更されるとき、変更する前記モデル要素のみ及び／又は前記変換ルール要素のみ、バージョンを更新し、
   前記変換ルール要素バージョン取得手段が、前記複数の変換ルール要素のバージョンを取得し、
   前記モデル要素バージョン取得手段が、前記複数のモデル要素のバージョンを取得し、
   前記バージョン比較手段が、前記モデル要素バージョン取得手段により取得された前記モデル要素のバージョンと対応する前記プログラム要素の生成したときのモデル要素のバージョンとを比較するとともに、前記変換ルール要素バージョン取得手段により取得された前記変換ルール要素のバージョンと対応する前記プログラム要素の生成したときの変換ルール要素のバージョンとを比較し、
   前記プログラム生成手段が、前記モデル要素のバージョンと対応する前記プログラム要素の生成したときのモデル要素のバージョンが一致しないか、前記変換ルール要素のバージョンと対応する前記プログラム要素の生成したときの変換ルール要素のバージョンが一致しないとき、該モデル要素と該変換ルール要素を用いてプログラム要素を生成し、該モデル要素のバージョンと該変換ルール要素のバージョンを付加して前記記憶媒体に記憶することを特徴とするモデル駆動開発方法。
6. 前記複数のモデル要素は、エンティティ、コントロール及びバウンダリを含むものであることを特徴とする請求項５に記載のモデル駆動開発方法。
7. モデル駆動開発手法を用いたモデル駆動開発装置に、複数のモデル要素とそのバージョンを記憶し、複数の変換ルール要素とそのバージョンを記憶し、複数の生成されたソースファイルであるプログラム要素と、前記プログラム要素を生成したときの前記モデル要素のバージョンと前記変換ルール要素のバージョンを対応付けて記憶するための記憶媒体が予め備えられ、
   前記モデル駆動開発装置を、
   前記モデルを前記生成の変換の基本となる単位である複数のモデル要素に分割し個々の前記モデル要素にバージョンを付与し、前記変換ルールを構成する複数の変換ルールを前記モデル要素と対応付けられた複数の変換ルール要素として、個々の前記変換ルール要素にバージョンを付与し、前記モデル及び／又は前記変換ルールが変更されるとき、変更する前記モデル要素のみ及び／又は前記変換ルール要素のみ、バージョンを更新する制御手段、
   前記複数の変換ルール要素のバージョンを取得する変換ルール要素バージョン取得手段、
   前記複数のモデル要素のバージョンを取得するモデル要素バージョン取得手段、
   前記モデル要素バージョン取得手段により取得された前記モデル要素のバージョンと対応する前記プログラム要素の生成したときのモデル要素のバージョンとを比較するとともに、前記変換ルール要素バージョン取得手段により取得された前記変換ルール要素のバージョンと対応する前記プログラム要素の生成したときの変換ルール要素のバージョンとを比較して結果を出力するバージョン比較手段、
   前記バージョン比較手段から、前記モデル要素のバージョンと対応する前記プログラム要素の生成したときのモデル要素のバージョンが一致しないか、前記変換ルール要素のバージョンと対応する前記プログラム要素の生成したときの変換ルール要素のバージョンが一致しない結果を受けたとき、該モデル要素と該変換ルール要素を用いてプログラム要素を生成し、該モデル要素のバージョンと該変換ルール要素のバージョンを付加して前記記憶媒体に書き込むプログラム生成手段、
   として機能させるためのモデル駆動開発プログラム。
8. 前記複数のモデル要素は、エンティティ、コントロール及びバウンダリを含むものであることを特徴とする請求項７に記載のモデル駆動開発プログラム。

Images