JP4939007B2 - システム設計支援プログラム - Google Patents

Description

本発明は、業務向けシステムのシステム設計に用いられるシステム設計支援プログラムに関し、いわゆるＣＡＳＥ(Computer Aided System Engineering）ツールに用いられるプログラムに関する。

従来から、業務向け等のシステムの開発において、該システムの設計を支援するＣＡＳＥツールが利用されている。ＣＡＳＥツールの１つに、ケン・システム開発（株）が開発した「ＸｕｐｐｅｒII（クロスアッパー・ツー）」（登録商標）がある。

変化が激しい昨今においてシステム開発を成功させるには、設計の上流工程でユーザニーズを正確に把握する必要がある。「ＸｕｐｐｅｒII」は、上流分析設計を支援するためのソフトウェアツールであり、エンドユーザにも分かりやすいビジネスフロー図とビジネスルールを基に、データ中心アプローチ（ＤＯＡ：Data Oriented Approach）を実現している。
特許第３５２７６５８号公報

一般に、ソフトウェアの開発工程には、クライアントの業務を分析する業務分析工程、クライアントの業務における要求仕様を定義する要求定義工程、要求定義を満たすソフトウェアの基本構成を設計する基本設計工程及びその詳細を設計する詳細設計工程を含む上流工程と、ソフトウェアを構成する各プログラムを作成するプログラム開発工程及び作成されたプログラムの動作を検証するテスト工程を含む下流工程とに分かれる。

しかしながら、前記従来のシステム設計支援ツールである「ＸｕｐｐｅｒII」は、上流設計用ツールであるため、下流工程であるプログラム開発工程を行なうにあたって、得られた設計データを他の下流設計用ツールにブリッジ又は手作業を介して渡す必要がある。

このような場合には、せっかく作成した設計データのすべてを利用できない場合があり、時間的且つ費用的に大きな無駄が生じるという問題がある。

本発明は、前記従来の問題を解決し、上流設計用ツールである「ＸｕｐｐｅｒII」を用いて、下流工程であるプログラム開発をブリッジ及び人手を介することなく自動的に行なえるようにすることを目的とする。

前記の目的を達成するため、本発明は、「ＸｕｐｐｅｒII」を、該「ＸｕｐｐｅｒII」が持つリポジトリ（システム専用のデータベース）に対してソースコードの生成に必要なデータを付加することにより、上流工程から下流工程までをブリッジ及び人手を介することなく自動的に行なう構成とする。

具体的に、本発明に係るシステム設計支援プログラムは、データ中心アプローチ手法を用いたシステム設計支援プログラムを対象とし、コンピュータに、入力された業務フローを複数のプロセスに階層化する機能Ａと、各プロセスに用いる複数のエンティティと、該エンティティ同士の互いの関連を表わすエンティティ関連図を作成する機能Ｂと、各プロセスに必要な入出力データ及び各エンティティのフィールドデータを保持するディクショナリを作成する機能Ｃと、エンティティ関連図及びディクショナリを参照して、グラフィカルユーザインタフェース設計を行なう機能Ｄと、各プロセスにおける階層化データ、各
エンティティの属性データ、ディクショナリ及びグラフィカルユーザインタフェース設計に関するデータをそれぞれ登録してリポジトリを作成する機能Ｅと、各プロセス、各エンティティ、ディクショナリに保持されたデータ及びグラフィカルユーザインタフェース設計に関するデータのうちの少なくとも１つを参照し、且つ、外部から各プロセスを実行可能とするロジック定義を入力することにより、ソースコードを自動生成して出力する機能Ｆとを実現させ、前記機能Ｆは、ロジック定義を入力する際にＳＱＬ構文を用いており、ロジック定義を入力する際に、入力されたロジック定義がＳＱＬ構文に定義されている場合はウィザードによる対話形式を用いる一方、入力されたロジック定義がＳＱＬ構文に定義されていない場合は、定義されていないロジック定義を直接に入力してリポジトリに登録する機能を含むことが好ましい。

本発明のシステム設計支援プログラムによると、「ＸｕｐｐｅｒII」の機能に相当する機能Ａ、Ｂ、Ｃ、Ｄ及びＥを有しているため、各プロセス、各エンティティ、ディクショナリに保持されたデータ及びグラフィカルユーザインタフェース設計に関するデータのうちの少なくとも１つを参照し、且つ外部から各プロセスを実行可能とするロジック定義を入力することにより、ソースコードを自動生成して出力することができる。

本発明のシステム設計支援プログラムにおいて、ソースコードには、Ｊａｖａ言語（登録商標）、高速機関Ｐｒｏｃｅｄｕｒｅ言語又はＢｉｚＣＲＳ言語を用いることができる。

本発明のシステム設計支援プログラムにおいて、機能Ｆにおけるソースコードは、各プロセスごとに該プロセスを実行するファンクションを有し、機能Ｆは、ファンクションにおいて、ロジック定義を展開するロジック文の構成要素を、それぞれがソースコードの骨組みである複数のスケルトンにより構成する機能と、複数のスケルトンを、スケルトンロジック部と、置換文字列別生成ロジック部と、ユーザポイント別生成ロジック部とに分解する機能と、分解された置換文字列別生成ロジック部を、リポジトリに登録されたデータのうち置換文字列別生成ロジック部と対応するデータと置換する機能と、分解されたユーザポイント別生成ロジック部を、入力されたロジック定義と置換する機能とを含むことが好ましい。

この場合に、機能Ｆは、外部からスケルトンロジック部を書き換え可能とする機能を含むことが好ましい。

本発明のシステム設計支援プログラムは、自動生成されないソースコードをあらかじめマクロファンクションとしてリポジトリに登録する機能Ｇをさらに備え、機能Ｆは、ソースコードを自動生成する際に、リポジトリに登録されたマクロファンクションをソースコードに展開する機能を含むことが好ましい。

本発明のシステム設計支援プログラムにおいて、機能Ｃは、各エンティティのフィールドデータにおけるデータ型を、ディクショナリにソースコードの言語種別に応じて第１のマスタファイルとして保持することが好ましい。

この場合に、機能Ｃは、各エンティティのフィールドデータ同士の間で実行されるデータの代入、演算、比較及び呼び出しパラメータの照合のうちの少なくとも１つの処理を行なう際に、行なう処理ごとの妥当性を判定するコードをディクショナリに第２のマスタファイルとして保持する機能を含むことが好ましい。

また、データ型を第１のマスタファイル化する場合に、機能Ｃは、各エンティティのフィールドデータ同士の間で実行されるデータの代入、比較及び呼び出しパラメータの照合のうちの少なくとも１つの処理を行なう際に、行なった処理の結果の出力条件ごとの妥当性を判定するコードをディクショナリに第３のマスタファイルとして保持する機能を含むことが好ましい。

また、データ型を第１のマスタファイル化する場合に、機能Ｃは、各エンティティのフィールドデータ同士の間で実行されるデータの代入文、条件文、演算文及びパラメータの照合のうちの少なくとも１つの処理を行なう際に、行なう処理と対応するソースコードごとの生成ルールをディクショナリに第４のマスタファイルとして保持する機能を含むことが好ましい。

本発明のシステム設計支援プログラムにおいて、機能Ｅは、グラフィカルユーザインタフェース設計に用いるコントロールコマンドにおけるプロパティ、メソッド及びイベントをソースコードに依存しない設計用コントロールコマンドとしてリポジトリに登録する機能を含み、機能Ｆは、プロパティ、メソッド及びイベントを、設計用コントロールコマンドと、各エンティティのフィールドデータのデータ型と、ソースコードの種別とに基づいて、ソースコードと対応したグラフィカルユーザインタフェースを生成する機能を含むことが好ましい。

本発明のシステム設計支援プログラムにおいて、機能Ｅは、グラフィカルユーザインタフェース設計に用いるコントロールコマンドの戻り値をパネル変数としてリポジトリに登録する機能を含み、機能Ｆは、パネル変数をソースコードに依存しない論理メソッドを発行して取得し、取得したパネル変数をソースコードに展開する機能を含むことが好ましい。

本発明のシステム設計支援プログラムにおいて、機能Ｅは、グラフィカルユーザインタフェース設計に用い、種別が同一で複数のコントロールコマンドに参照される各パネル変数をグループ化してリポジトリに登録する機能を含み、機能Ｆは、複数のコントロールコマンドを、グループ化されたパネル変数ごとに一のコマンドを発行する一括コマンドに変換する機能と、一括コマンドを発行することにより、対応するパネル変数を取得し、取得したパネル変数をその括られた個数だけソースコードに展開する機能を含むことが好ましい。

本発明のシステム設計支援プログラムにおいて、機能Ｅは、各プロセスに固有の定義情報を共通化した共通マクロ命令をリポジトリに登録する機能を含み、機能Ｆは、ソースコードを生成する際に、ロジック定義が共通マクロ命令を参照する機能を含むことが好ましい。

本発明に係るシステム設計支援プログラムによると、上流設計用ツールである「ＸｕｐｐｅｒII」を用いて、下流工程であるプログラム開発をブリッジ及び人手を介することなく自動的に行なえるようになる。

（第１の実施形態）
本発明の第１の実施形態について図面を参照しながら説明する。

図１は本発明の第１の実施形態に係るシステム設計支援プログラムのブロック構成を示している。ここでは、システム設計支援プログラムは、それが実行されるコンピュータ（ハードウェア）には依存しないため、ハードウェア構成は省略する。

図１に示すように、第１の実施形態に係るシステム設計支援プログラムは、上流設計用ツールであってデータ中心アプローチ（ＤＯＡ）手法を用いる「ＸｕｐｐｅｒII」１０と、該「ＸｕｐｐｅｒII」１０が生成、更新及び参照を行なう第１のリポジトリ１１と、該第１のリポジトリ１１及びその拡張部である第２のリポジトリ２１に対して生成、更新及び参照を行ない、開発対象であるプログラムのソースコードを自動生成する下流設計用ツールである「ＭＤＦｒａｍｅ／Ｘ（エムディーフレーム・エックス）」２０とから構成されている。以下、第１のリポジトリ１１及び第２のリポジトリ２１を統合リポジトリ３０と呼ぶ。

第２のリポジトリ２１にはソースコードの生成に必要なデータが格納されており、「ＭＤＦｒａｍｅ／Ｘ」２０は、統合リポジトリ３０を１つのモデルとして捕らえる。

すべての情報（データ）はこのモデルに対して設定され、稼働環境はこのモデルから生成されたソースコードによって実装（インプリメント）される。その結果、「ＭＤＦｒａｍｅ／Ｘ」２０を用いることにより、モデルと実装環境との乖離がなくなるため、いわゆるモデルドリブンの開発環境を得ることができる。

「ＭＤＦｒａｍｅ／Ｘ」２０は、第１のリポジトリ１１に格納されているデータのうち、以下の各情報をブリッジ等を介することなく直接に参照する。

１）プロセスの階層及び最下層プロセス等を含むプロセス情報
２）識別子、属性項目及びエンティティ同士の関連情報等を含むエンティティ情報
３）ドメインフィールド、コンディション及びフィールド等を含むディクショナリ情報
４）グラフィカルユーザインタフェース（ＧＵＩ：Graphical User Interface）の画面レイアウト等を含むＧＵＩデバイスの設計情報
さらに、「ＭＤＦｒａｍｅ／Ｘ」２０は、第１のリポジトリ１１に含まれるディクショナリに対して、追加編集を直接に行なうことができる。

第１の実施形態に係るシステム設計支援プログラムは、コンピュータに、入力された業務フローを複数のプロセスに階層化する機能と、記各プロセスに用いる複数のエンティティと、該エンティティ同士の関連を表わすエンティティ関連図を作成する機能と、各プロセスに必要な入出力データ及び各エンティティのフィールドデータを保持するディクショナリを作成する機能と、エンティティ関連図及びディクショナリを参照して、ＧＵＩ設計を行なう機能と、各プロセスにおける階層化データ、各エンティティの属性データ、ディクショナリ及びＧＵＩ設計に関するデータをそれぞれ登録して第１のリポジトリを作成する機能と、各プロセス、各エンティティ、ディクショナリに保持されたデータ及びＧＵＩ設計に関するデータを参照し、且つ、外部から各プロセスを実行可能とするロジック定義を入力することにより、ソースコードを自動生成して出力する機能とを実現させる。

図２は第１の実施形態に係るシステム設計支援プログラムにおける「ＭＤＦｒａｍｅ／Ｘ」２０が生成可能なソースコードの一例を示す。図２に示すように、少なくとも、ＢｉｚＣＲＳファイル３１、Ｊａｖａソース３２及び高速機関Ｐｒｏｃｅｄｕｒｅソース３３のいずれか１つのソースコードを生成可能である。なお、周知のように、ＢｉｚＣＲＳファイル３１は、スクリプト言語であるため、コンパイルは不要である。

以下、「ＭＤＦｒａｍｅ／Ｘ」におけるソースコードの自動生成の具体例について図面を参照しながら説明する。

「ＭＤＦｒａｍｅ／Ｘ」は、所定のファンクション（プログラム関数）を生成する場合に、ソースコードの骨組みである「スケルトン」、「ユーザーポイントロジック単位の生成ソース」及び「置き換え文字列単位の生成ソース」を合成することによって、完全なソースコードの自動生成を実現する。

図３にスケルトンの具体例を示す。スケルトンとは、ファンクションパターンごとに対応して設定されたスケルトン文字列をいう。また、スケルトンは、ファンクションに依存しない固定された生成内容と、生成内容が変動する部分を示す置き換え文字列とから構成される。

置き換え文字列は、後述する「ユーザーポイントロジック」を埋め込む場合と、「置き換え文字列単位の生成ロジック」を埋め込む場合との２種類がある。

ユーザーポイントロジック用の置き換え文字列には、例えば、図３の下から３行目に記述された＜％＃ ＵＳＥＲ＿ＰＯＩＮＴ ＣＤ:Ｕ６０＿Ｍａｉｎ ＃％＞が相当する。

置き換え文字列単位の生成ロジック用の置き換え文字列には、例えば、図３の１行目に記述された＜％＃ Ｊａｖａ＿ＰａｃｋａｇｅＮａｍｅ ＃％＞及び８行目の＜％＃ Ｊａｖａ＿ＩｍｐｏｒｔＰａｃｋａｇｅＬｉｓｔ ＃％＞等が相当する。このＩｍｐｏｒｔＰａｃｋａｇｅＬｉｓｔを含むスケルトンは、該当ファンクションが呼び出しているファンクション等のインポート文を生成することを指定する。

ユーザーポイントロジックは、実際のファンクションにおいては、ファンクションパターンに設定されているユーザーポイントに対するアクションダイアグラム記述による論理コーディングが行なわれ、コーディングされた内容をソースコードに変換した文字列を意味する。また、置き換え文字列単位の生成ロジックは、実際のファンクションにおいては、ロジックコーディングを行なうことなく、パラメータ等が設定された統合リポジトリの情報を参照することによって生成された文字列を意味する。

図４に図３に示したスケルトンのソースコードの生成結果を示す。図４において、例えば、図３の１行目に記述された＜％＃ Ｊａｖａ＿ＰａｃｋａｇｅＮａｍｅ ＃％＞はｄｅｍｏ.ｔｒａｎに置き換えられ、図３の下から３行目に記述された＜％＃ ＵＳＥＲ＿ＰＯＩＮＴ ＣＤ:Ｕ６０＿Ｍａｉｎ ＃％＞は、下から４行目に記述された、ｍｙ＿ｊｙｕｔｙｕｕＵｐｄａｔｅ＿ｉ＝ｎｅｗ ｊｙｕｔｙｕｕＵｐｄａｔｅ＿ｉ（）等に置き換えられていることが分かる。

図５は、図３から図４の処理を実行する際のデータ構造を表わしたエンティティ関連図（ＥＲＤ：Entity Relation Diagram）である。図５において、図３に示したスケルトンは、図１に示した第２のリポジトリ２１の「ＸＥ＿スケルトン.ＦＵＮスケルトン」に格納されている。ファンクションは「ＸＥ＿ファンクション」ごとに作成されるため、対応するスケルトンがソースコードの生成時に参照されることが分かる。

このように、第１の実施形態によると、スケルトンに直接に記述されている内容については、人手によるメンテナンス作業は不要であり、第１の実施形態に係るソース生成機能を修正する必要はない。

（第１の実施形態の一変形例）
以下、第１の実施形態の一変形例を説明する。

ファンクションのソースコードを自動生成する際には、ユーザの稼働環境又はプロジェクトに依存するコード（記述）が必要となる。例えば、図３の７行目に記述したデータベース接続情報の取得方法及びその１２行目に記述したログファイルの書き出し方法等がそれに相当する。

このようなユーザの稼動環境等に依存する記述は、ＣＡＳＥツール自体の機能に取り込むか又は該ＣＡＳＥツールをカスタマイズすることによって対応する必要があるが、これらの方法を用いても、すべての要求に対応することは困難である。

そこで、自動生成されるソースコードにユーザが指定した内容を容易に反映する機構が必要となる。

本変形例においては、図３に示したスケルトンにおける、例えば２、３、６及び７行目のようなファンクションに依存しない固定された部分について、稼動環境等に依存する要素に対するユーザカスタマイズを行なえるようにしている。このように、管理者によるメンテナンス作業を可能とすることにより、「ＭＤＦｒａｍｅ／Ｘ」によるソース生成機能を何ら変更するこことなく、ユーザに依存したコードを動的に反映させることが可能となる。

（第２の実施形態）
以下、本発明の第２の実施形態に係るシステム設計支援プログラムについて図面を参照しながら説明する。

リレーショナルデータベースを対象としたデータベース照会言語であるＳＱＬを用いる場合に、該ＳＱＬ定義は、直接に文字入力されたコードをプログラムのソースコード中に埋め込む方法が一般的である。

本発明に係る「ＭＤＦｒａｍｅ／Ｘ」は、ＳＱＬ定義自体を独立したオブジェクトとして管理している。また、構文エラーを回避したり、ＳＱＬ定義を変更した場合にプログラムの他の部分におよぶ影響の分析を容易にしたりするために、ウィザード形式で登録した結果を第２のリポジトリに格納している。

図６にＳＱＬ定義に関するテーブル（ＥＲＤ）の一例を示す。図６において、左上に位置する「ＸＥ＿ＤＬＣＰ」がＳＱＬ定義の一単位に相当する。

ところが、「ＭＤＦｒａｍｅ／Ｘ」は、ＳＱＬ９２／９９のすべての構文に対してウィザードとリポジトリとを対応させているわけではない。ＳＱＬ９２／９９が対象とする構文は多種多様であり、これらすべてにウィザードを対応させることは実質的に不可能であると共に非効率でもあるため、一般に使用頻度が高いＳＱＬ構文のみをウィザードの対象としている。

しかしながら、使用頻度は低いにもかかわらず、ＳＱＬの実行効率に大きく影響する構文も存在する。このため、使用頻度が低く且つ重要なＳＱＬ定義を一律に管理対象外とすることは、システム開発作業における生産性という観点からも好ましくない。

そこで、第２の実施形態においては、ウィザードの対象としていない構文については、直接に入力したＳＱＬ文をあらかじめ第２のリポジトリに登録しておき、ソースコードの生成時に参照することにより対応可能としている。

「ＭＤＦｒａｍｅ／Ｘ」は、ＳＱＬを基本的に「所定の値を受け取って、ＳＱＬを発行し、所定の値を返す」ための一部品としている。このため、受け取る情報と返す情報とに関して、通常のＳＱＬと同様にウィザードを用いて定義を行なう必要はあるものの、発行するＳＱＬについては、ウィザードの制限に縛られることなく任意の構文を使用することが可能となる。

また、ＳＱＬ定義を直接に入力する場合にも、ＳＱＬ定義文のすべてを直接に入力する場合と、その一部分を直接に入力する場合との２段階に分けることによって、直接入力する対象範囲を最小限に留めている。

図７に直接に入力したＳＱＬ定義に関する情報を格納したテーブル（ＥＲＤ）の一例を示す。図７に示すように、「ＸＥ＿生成部分ＳＱＬ」以外のエンティティについては、通常のウィザードによる場合と同様の設定が行なわれることが分かる。すなわち、ＳＱＬ定義を直接に入力した場合は、その結果が「ＸＥ＿生成部分ＳＱＬ」に保持され、一方、ウィザードによって入力した場合は、その結果をＳＱＬにより生成された内容が格納される。

ここで、「ＸＥ＿生成部分ＳＱＬ」の各項目を説明する。

「ＤＬＣＰＳＧＴ」は、ＳＱＬを一意に識別する管理番号を示す。

「論理／物理種別ST」は、格納される情報が論理ＳＱＬか物理ＳＱＬかを識別する符号（ST：ステータス）である。例えば、論理ＳＱＬを１とし、物理ＳＱＬを２とする。なお、論理ＳＱＬはＳＱＬ定義の確認を行なうためのＳＱＬであって、実際のソースを生成する対象ではない。

「ＳＱＬ部分種別ST」は、格納される情報がＳＱＬのどの部分に相当するのかを識別する符号である。例えば、ＳＱL全体を０とし、Ｓｅｌｅｃｔ句を１とし、Ｆｒｏｍ句を２とし、Ｗｈｅｒｅ句を３とし、ＯｒｄｅｒＢｙ句を４とし、ＧｒｏｕｐＢｙ句を５とし、Ｈｖｉｎｇ句を６とし、Ｓｅｔ句を７とし、ＩｎｓｅｒｔＩｎｔｏ句を８とし、Ｖａｌｕｅｓ句を９とする。

「生成部分ＳＱＬ」は、直接に入力されたＳＱＬ文又は第２のリポジトリに格納された情報から自動生成されたＳＱＬ文が格納される。

「ＳＱＬ直接入力識別ST」は、「生成部分ＳＱＬ」（図示せず）に格納された値が、直接に入力されたコードか、ウィザードを介してＳＱＬ定義から自動生成されたコードかを識別する符号である。

［表１］及び［表２］に、テーブルに格納される一例を示す。

ここでは、１つの「ＤＬＣＰＳＧＴ」により識別されるＳＱＬで且つ物理ＳＱＬがどのように格納されるかを検索型のＳＱＬ定義を用いて説明する。

検索型の場合、パートには「ＳＱＬ全体」、「Ｓｅｌｅｃｔ句」、「Ｆｒｏｍ句」、「Ｗｈｅｒｅ句」、「ＯｒｄｅｒＢｙ句」、「ＧｒｏｕｐＢｙ句」及び「Ｈａｖｉｎｇ句」の７種類がある。

（１）「ＳＱＬ全体」を直接に入力した場合

この場合、「ＳＱＬ全体」に対して入力された内容がそのままプログラムの生成時にソースコードに埋め込まれる。

（２）「Ｗｈｅｒｅ句」及び「ＯｒｄｅｒＢｙ句」を直接に入力した場合

この場合、プログラムの生成時には、各パートの値がソースコードに埋め込まれる。また、各パートの値は、生成されたソースプログラムのロジックによって合成された後で発行される。

（第３の実施形態）
以下、本発明の第３の実施形態に係るシステム設計支援プログラムについて図面を参照しながら説明する。

前述したように、「ＭＤＦｒａｍｅ／Ｘ」は、各ファンクションに対して設定するロジックを、論理的なアクションダイアグラムとしてウィザード形式で入力させることによって属人性を排し、理解が容易で且つ入力ミスを防止したロジックの構築が可能となる。

しかしながら、ソースコードを生成するプログラム言語のすべての命令セットを網羅することは困難である。

例えば、アプリケーションプログラムインタフェース(ＡＰＩ:Application Program Interface)を呼び出すロジック等の記述を行なう場合には、ソースコードの自動生成を行なった後で、生成されたソースコードを手作業で修正する必要が生じる場合がある。但し、この場合に再度ソースコードの生成を実行すると、手作業で行なった修正内容は上書きされて消失してしまう。これでは、統合リポジトリに登録されたデータと稼動しているプログラムとの間に乖離が生じてしまう。

そこで、第３の実施形態においては、生成対象であるプログラム言語による必要なソースコード（Ｎａｔｉｖｅコード）を記述してマクロファンクションとして第２のリポジトリに登録し、登録されたマクロファンクションを部品として扱えるようにする。

例えば、ソースコードを自動生成した後に、手作業で修正が必要な事項をあらかじめマクロファンクションとして部品化し、第２のリポジトリに登録しておく。ソースコードの生成時には、部品化されたマクロファンクションを参照してソースコードを生成することにより、アクションダイアグラムが対応していない命令（コマンド）を生成後のソースに展開する。

図８に第２のリポジトリに格納されたマクロファンクションのＥＲＤの一例を示す。図８はファンクション定義のうちのマクロファンクションに関係する部分の抜粋である。図８において、「ＸＥ＿ＤＬＣＰ」、「ＸＥ＿ＢＰＴＢＬ」及び「ＸＥ＿ファンクション」はそれぞれ１対１の関係にあり、ファンクションの一単位となる。

ファンクションに対して、「ＸＥ＿ファンクション内変数」は該ファンクションが持つ変数を示す。この変数は入力、出力及びローカルの３種類が存在し、第３の実施形態に係るマクロファンクションはこのうちの入力と出力とを対象とする。

「ＸＥ＿ロジック行」は、ファンクションに設定したアクションダイアグラムの１行ごとの情報に相当する。この「ＸＥ＿ロジック行」に対して各命令を登録することにより、ファンクションのロジックが完成する。

マクロファンクションはそれ自体で生成されることはなく、あくまでマクロファンクションを呼び出す他のファンクションの一部のソースコードとして取り込まれることによって所定のソースコードに展開される。

図９は、あるファンクションにロジックを入力した様子を示している。図９に示すように、ロジック定義はアクションダイアグラム表記として入力され、各行が「ＸＥ＿ロジック行」に対応する。例えば、図９の１２行目の「ＣＡＬＬ Ｂ＿ＭＡＣＲＯ：Ｃ００１＿配列要素数取得（文字列）」が本実施形態のマクロファンクションを呼び出す記述である。この場合、図８に示したＥＲＤ中の「ＸＥ＿ロジック行」に対して、「ＸＥ＿呼出」のデータが作成され、呼び出し先のマクロファンクションが特定される。その後、呼出先のマクロファンクションにおける「ＸＥ＿ファンクション内変数」と、自身のファンクションにおける「ＸＥ＿ファンクション内変数」との間で、マッピング（対照）定義を行なった結果が「ＸＥ＿パラメータマッピング」に格納される。

図１０に図９の１２行目に記述されたマクロファンクションを呼び出す行と対応したウィザードを示す。図１０においては、「ＸＥ＿呼出」を作成するために、呼出先ファンクションを特定している。

図１１に図１０のウィザードにおいて「次へ（Ｆ９）」のボタンが押下された後に表示されるウイザードを示す。図１１に示すように、呼出先のマクロファンクションの「ＸＥ＿ファンクション内変数」をパラメータとして表示し、これに対して自身のファンクションの変数をマッピングすることによって、「ＸＥ＿パラメータマッピング」を作成する。

次に、呼び出される側のマクロファンクションに関する定義について説明する。呼び出されるマクロファンクションもファンクションとしては「ＸＥＤＬＣＰ」、「ＸＥ＿ＢＰ」及び「ＸＥ＿ファンクション」を一単位として作成される。また、図１１に示した呼出のパラメータマッピングのイメージからも分かるように、この例では入力パラメータとして「ＭＤ＿配列項目」を持ち、出力パラメータとして「ＭＤ＿配列要素数」を持つ。

次に、図１２にマクロの実体を記述するためのＮａｔｉｖｅ文を受け付けるウイザードを示す。これは、図１２の左上のアクションダイアグラムにおける３行目の「Ｎａｔｉｖｅ ＭＤ＿配列要素数取得（Ｊａｖａ）」と対応する画面イメージである。このウイザードから入力されたデータは、図８のＥＲＤに示すように、「ＸＥ＿ロジック行」を介して「ＸＥ＿Ｎａｔｉｖｅ＆コメント」及び「ＸＥ＿Ｎａｔｉｖｅインポート文（ＪＡＶＡ）」にそれぞれ格納されます。但し、ここではインポート文を使用していないため、「ＸＥ＿Ｎａｔｉｖｅインポート文（ＪＡＶＡ）」にはデータは格納されることはない。

この定義により、以下に示すソースコードを得ることができ、このソースコードがマクロファンクションの呼出元に組み込まれる。

ｌ＿ＨａｉｒｅｔｕＹｏｕｓｏＳｕｕ＝Ｉ＿ＳｙｏｕｈｉｎＣＤ＿ａｒｒ．ｓｉｚｅ（）；
また、同様に、インポート文として入力した場合には、入力された内容は、呼出元のファンクションにおけるＩｍｐｏｒｔ文の記述箇所に組み込まれる。

このように、「ＭＤＦｒａｍｅ／Ｘ」が対応していないＪａｖａの命令コードをマクロファンクションとして取り込むことによって、生成後のソースコードを修正する必要がなくなる。その上、Ｊａｖａのソースコードが、該Ｊａｖａに対するスキルが低い開発者にも共有部品として使用することができる。

（第４の実施形態）
以下、本発明の第４の実施形態に係るシステム設計支援プログラムについて図面を参照しながら説明する。

図１３は本発明に係る「ＸｕｐｐｅｒII」がアクセスするディクショナリに格納されたデータのフィールドに関するＥＲＤを示している。図１３に示すように、左下の「フィールド」は、右上の「ドメイン」及び右下の「フィールドタイプ」に従属し、且つ、「ドメイン」は「フィールドタイプ」に従属する。

例えば、「フィールド：得意先CD」は「ドメイン：取引先CD」に従属するため、データタイプ、内部長及び小数点桁数等は「ドメイン：取引先CD」と同一の値が設定される。同時に、「ドメイン：取引先CD」は「フィールドタイプ：コード」に従属するため、データタイプ等は「フィールドタイプ：コード」と同一の値が設定される。ところが、例えば「フィールド：受注入力画面用備考」は「ドメイン」には従属しておらず、「フィールドタイプ：漢字項目」に従属している。

このように、「ＸｕｐｐｅｒII」においては、「フィールド」に対するデータ型（タイプ）の概念の最上位に「フィールドタイプ」が位置する構成を採る。さらに、「フィールドタイプ」は、ユーザが新たな定義を追加することができる。

ところで、各種ソースコードを生成するときに、生成対象のプログラム言語は種々のデータ型を持っている。従って、「ＸｕｐｐｅｒII」のディクショナリに格納された「フィールドタイプ」を各プログラム言語のデータ型に関連付ける必要がある。

そこで、第４の実施形態においては、生成対象となるプログラム言語のデータ型をマスタファイル（基本ファイル）化することによって、変数定義部分のソースコード生成機能から固定ロジックを排除して、変数定義部分におけるソースコード生成機能を柔軟に行なえるようにする。ここで、マスタファイル（基本ファイル）とは、登録されたデータに対する追加、変更及び削除を禁止されたデータファイルをいう。

具体的には、図１４のＥＲＤに示すように、「ＸｕｐｐｅｒII」における「フィールドタイプとは独立に、「ＭＤＦｒａｍｅ／Ｘ」に「ＸＥ＿言語別データタイプ」を定義し、さらに「ＭＤＦｒａｍｅ／Ｘ」に「ＸＥ＿フィールドタイプ拡張」を定義することにより「ＸｕｐｐｅｒII」における「フィールドタイプ」と「ＭＤＦｒａｍｅ／Ｘ」における「ＸＥ＿言語別データタイプ」とを互いに関連付けることによって、各項目が複数のプログラム言語のうちの生成対象である言語のデータ型を設定可能とする。

例えば、「ＸＥ＿言語別データタイプ」には、［表３］に示す内容が設定される。

また、「ＸＥ＿フィールドタイプ拡張」に［表４］に示す内容を設定することにより、各プログラム言語のデータ型間の関連が定義される。

［表４］に示す関係を設定することによって、例えば、「ＮＢＲ」タイプの項目がプログラム言語「ＢｉｚＣＲＳ」として生成される場合には「Ｎｕｍｂｅｒ」となり、プログラム言語「Ｊａｖａ」として生成される場合には「ｄｏｕｂｌｅ」となるようなロジックを、生成対象のロジック定義から抽出することが可能となる。

このように、ユーザが各プログラム言語のデータ型をマスタファイル化するだけで、生成ロジックに対する変更を行なうことなく、変数定義部分の生成結果を動的に変更することができるようになる。これにより、「ＸｕｐｐｅｒII」における「フィールドタイプ」に対しても任意に追加することが可能となる。

以下、ローカル変数として受注数量を定義した場合の変数定義における生成例を示す。

（１）「ＢｉｚＣＲＳ」の場合
Ｎｕｍｂｅｒ ｌ＿受注数量 ＝ ０；
（２）「Ｊａｖａ」の場合
ｐｒｉｖａｔｅ ｄｏｕｂｌｅ ｌ＿ＪｙｕｔｙｕｕＳｕｕｒｙｏｕ；
（３）「高速機関Ｐｒｏｃｅｄｕｒｅ」の場合
ｌ＿受注数量 ＩＮ ＤＥＣＩＭＡＬ（７，０）；
上記の「Ｎｕｍｂｅｒ」、「ｄｏｕｂｌｅ」及び「ＤＥＣＩＭＡＬ」は、図１４に示した「ＸＥ＿言語別データタイプ.言語別データタイプ生成名」をそれぞれ参照することによって、動的に変更可能となる。

（第５の実施形態）
以下、本発明の第５の実施形態に係るシステム設計支援プログラムについて図面を参照しながら説明する。

図１５はアクションダイアグラムに対して「代入」処理を入力する際のウィザードの一例を示している。

「ＭＤＦｒａｍｅ／Ｘ」は、種々のプログラム言語のソースコードの生成を可能とするため、変数同士の値を代入する場合に、「代入」処理が生成対象のプログラム言語にとって妥当か否かを判定する必要がある。

例えば、一般に、数値項目のフィールドに対して数値の代入は可能ではあるが、日付項目のフィールドに対する数値の代入は不可能である。このような判定機能を組み込むには、各ウィザードにおいて「フィールドタイプ」同士の判定処理を行なう必要がある。但し、生成対象の言語によっては、「フィールドタイプ」が異なってはいてもデータ型が同一であるという場合があり、このような場合は「代入」処理を許可する必要がある。従って、「フィールドタイプ」のみを判定するという判定ルールは採用できない。

そこで、第５の実施形態においては、生成対象となるプログラム言語のデータ型間の関連ルールをマスタファイル化する。これにより、画面入力機能における「代入」、「演算」、「比較」及び「呼出パラメータマッピング」の各処理に関して、判定ルールを固定的に記述する必要がなくなる。

具体的には、第４の実施形態で説明した言語別データタイプに各データタイプの関連性を定義する新たなマスタファイルを追加する。各種入力機能用のウィザードがこのマスタファイルを参照することにより、ウィザードの判定ロジックを動的に変更できるようにする。

図１６は「ＸＥ＿言語別データタイプ」と「ＸＥ＿言語別データタイプ関連」とのＥＲＤを示している。図１６において、「ＸＥ＿言語別データタイプ」は第４の実施形態と同一である。

「ＸＥ＿言語別データタイプ関連」は２つの「言語別データタイプCD」の間で「代入」処理、「演算」処理又は「比較」処理がそれぞれ実行可能か否かを設定する。これにより、「代入」、「演算」、「比較」及び「呼出パラメータマッピング」の各ウィザードでは、処理対象項目から「言語別データタイプCD」を取得した後に、上記のマスタファイル化された「ＸＥ＿言語別データタイプ#関連」を参照することにより、判定内容を動的に変更することが可能となる。

例えば、「代入」処理の場合には、左辺と右辺との言語別データタイプの間で、「代入可否ST」が「可」であれば代入可能であり、「代入可否ST」が「否」であれば代入不能であるとウィザード（プログラム）が判定する。

（第６の実施形態）
以下、本発明の第６の実施形態に係るシステム設計支援プログラムについて図面を参照しながら説明する。

図１７はアクションダイアグラムに対して「代入」処理を入力する際のウィザードの他の例を示している。図１７は、代入文における「出力.ＭＤ＿リターンコード」にコンディション値を設定する際の、代入すべきコンディション値を選択するウィザードを表示している。ここで、コンディション値とはある項目の値に対して意味を持たせるための値である。ここでは、「ＭＤ＿リターンコード」に対して有効なコンディション値として「＊ＢＬＡＮＫ」、「＊ＮＵＬＬ」、「ＥＲＲＯＲ」、「ＮＯＲＭＡＬ」、「ＳＱＬ＿ＥＲＲＯＲ」、「ＳＱＬ＿ＥＸＩＳＴ」及び「ＳＱＬ＿ＮＯＴ＿ＦＯＵＮＤ」の７つのコンディション値が代入可能であることを意味している。このうち「＊ＢＬＡＮＫ」及び「＊ＮＵＬＬ」以外のコンディション値は、「ＸｕｐｐｅｒII」に既に登録されている。

「ＸｕｐｐｅｒII」は、論理仕様に関する定義を行なうツールであるため、「＊ＢＬＡＮＫ」及び「＊ＮＵＬＬ」以外のコンディション値は登録する必要があるものの、「＊ＢＬＡＮＫ」及び「＊ＮＵＬＬ」等に関しては、一般に論理的な意味を持たないため、あえて登録する必要がない。

しかしながら、「ＭＤＦｒａｍｅ／Ｘ」は、開発の下流工程においてプログラミングを行なうため、これら「＊ＢＬＡＮＫ」及び「＊ＮＵＬＬ」等のコンディション値も必要となる。

このような下流工程に必要なコンディション値には、「＊ＢＬＡＮＫ」及び「＊ＮＵＬＬ」以外にも、「＊ＺＥＲＯ」と「＊ＯＮＥ」とがある。しかしながら、これら４種類の新たなコンディション値に関しては、「ＸｕｐｐｅｒII」においてはコンディション登録をしなくても済むようにする必要がある。

その上、これら４種類のコンディション値を使用できるか否かに関しては、プログラム言語の各データ型によっても異なる。例えば、文字列型には「＊ＺＥＲＯ」及び「＊ＯＮＥ」を用いることはない。従って、所望のソースコードを生成した後に、該ソースコードにコンパイルエラーが生じるようなロジック定義を入力時点でエラーとするためにも、判定機能を組み込む必要がある。

そこで、第６の実施形態においては、生成対象となるプログラム言語のデータ型に対して設定可能なコンディション値をマスタファイル化する。これにより、「代入」、「比較」及び「呼出パラメータマッピング」の各処理に関する画面入力機能のなかから、コンディション値の妥当性の判定ルールを固定的に記述する必要がなくなる。

具体的には、第４の実施形態で説明した言語別データタイプに、前述の４つのコンディション値、すなわち「＊ＢＬＡＮＫ」、「＊ＮＵＬＬ」、「＊ＺＥＲＯ」及び「＊ＯＮＥ」のうち、有効なコンディション値を定義する新たなマスタファイルを追加する。各種入力機能用のウィザードがこのマスタファイルを参照することにより、ウィザードの判定ロジックを動的に変更できるようにする。

図１８は「ＸＥ＿言語別データタイプ」と「ＸＥ＿言語別データタイプ許容CND」とのＥＲＤを示している。図１８において、「ＸＥ＿言語別データタイプ」は第４の実施形態と同一である。ここでは、「ＸＥ＿言語別データタイプ許容CND」にデータが設定されていれば、使用可能なコンディション値であること意味する。

例えば、「許容ＩＴＥＭ種別ST」には、「＊ＢＬＡＮＫ」、「＊ＮＵＬＬ」、「＊ＺＥＲＯ」及び「＊ＯＮＥ」のうちのいずれか１つのコンディション値が設定される。その結果、「代入」、「比較」及び「呼出パラメータマッピング」の各処理に関する画面入力機能のなかから、コンディション値の妥当性の判定ルールを固定的に記述することなく、動的に変更することが可能となる。

（第７の実施形態）
以下、本発明の第７の実施形態に係るシステム設計支援プログラムについて図面を参照しながら説明する。

アクションダイアグラム記述によってロジック定義を行なったデータから、例えばＪａｖａのソースコードを生成する際に、データ型によってソースコードの生成方式が異なる場合がある。一例を挙げると、ｄｏｕｂｌｅ型の代入文とＢｉｇＤｅｃｉｍａｌ型の代入文とでは、以下のように異なる。

ｄｏｕｂｌｅ型は、
ＬｅｆｔＦｉｅｌｄ＝ＲｉｇｈｔＦｉｅｌｄ；
ＢｉｇＤｅｃｉｍａｌ型は、
ＬｅｆｔＦｉｅｌｄ
＝ｎｅｗ ＢｉｇＤｅｃｉｍａｌ（ＲｉｇｈｔＦｉｅｌｄ.ｔｏＳｔｒｉｎｇ（））；
又は
ＬｅｆｔＦｉｅｌｄ
＝（ｎｕｌｌ＝＝ＲｉｇｈｔＦｉｅｌｄ）？ｎｕｌｌ：ｎｅｗ ＢｉｇＤｅｃｉｍａｌ（ＲｉｇｈｔＦｉｅｌｄ.ｔｏＳｔｒｉｎｇ（））；
このような生成ルールをソースコードの生成ロジックとして組み込んだ場合には、組み込まれた生成ロジックが想定していないデータ型のロジック生成を行なうことは不可能である。

そこで、第７の実施形態においては、生成対象となるプログラム言語における「代入文」、「条件文」、「演算文」及び「パラメータマッピング」に関する生成ルールをマスタファイル化する。これにより、ソースコード生成機能として、固定ロジックを記述する必要がなくなるため、動的なロジック生成が可能となる。

具体的には、第４の実施形態で説明した言語別データタイプに、「代入文」、「条件文」、及び「演算文」等のコード生成を行なう場合の生成ルールをマスタファイル化して、第２のリポジトリに登録する。生成ロジックは、ソースコードの生成時にこのマスタファイルを参照して、生成ロジックの動的な変更を可能とする。

第７の実施形態に係るコード生成処理は、対応する部分スケルトンと変数生成名の合成とによって行なう。

図１９に第７の実施形態に係る部分スケルトンに関するＥＲＤを示す。以下、部分スケルトンのうち、「代入文」、「配列表現」、「条件文」、「演算文」、「ＭａｐＳｅｔ」及び「ＭａｐＧｅｔ」の順に説明する。

（１）ＸＥ＿生成スケルトンの「代入文」処理
代入文として登録されるバリエーションごとにデータが存在し、代入文を生成するための部分スケルトンが代入文スケルトンとして第２のリポジトリにマスタファイル化されて登録される。「代入文」のバリエーションは、左辺と右辺と２つの言語別データタイプの間に、許容されない場合を含め１５個だけ存在する。［表５］及び［表６］は「代入文」のバリエーションとスケルトンの例をそれぞれ示している。
ａ）ｄｏｕｂｌｅ型同士の代入文の場合

ｂ）ＢｉｇＤｅｃｉｍａｌ型同士の代入文の場合

［表５］及び［表６］において、各代入スケルトンに埋め込まれる置き換え文字列には以下がある。

＜％＃ Ｌ＿Ｆｌｄ ＃％＞：左辺に対する変数の生成名で置き換えられる。

＜％＃ Ｒ＿Ｆｌｄ ＃％＞：右辺に対する変数の生成名で置き換えられる。

＜％＃ Ｌ＿ａＦｌｄ ＃％＞：左辺の配列に対する変数の生成名で置き換えられる。

＜％＃ Ｒ＿ａＦｌｄ ＃％＞：右辺の配列に対する変数の生成名で置き換えられる。

＜％＃ Ｌ＿ａＩｄｘ ＃％＞：左辺の配列指標に対する変数の生成名で置き換えられる。

＜％＃ Ｒ＿ａＩｄｘ ＃％＞：右辺の配列指標に対する変数の生成名で置き換えられる。

＜％＃ Ｃｎｄ ＃％＞：右辺のコンディションに対する内部値で置き換えられる。

（２）ＸＥ＿生成スケルトンの「配列表現」処理
例えば条件判定を行なう際に、ある項目を参照し、参照した項目が配列要素の場合には、該配列要素を参照するように記述（ロジック）を変更する必要がある。この場合には、スケルトンを用いて配列要素をあらかじめ参照するように変換した後に、条件等の変換を行なう。
［表７］は「配列要素表現」のデータ型（タイプ）とスケルトンの例をそれぞれ示している。

［表７］において、配列表現スケルトンに埋め込まれる置き換え文字列には以下がある。

＜％＃ ａＦｌｄ ＃％＞：配列に対する変数の生成名で置き換えられる。

＜％＃ ａＩｄｘ ＃％＞：配列指標に対する変数の生成名で置き換えられる。

（３）ＸＥ＿生成スケルトンの「条件文」処理
代入文として登録されるバリエーションごとにデータが存在し、条件文を生成するための部分スケルトンが条件文スケルトンとして第２のリポジトリにマスタファイル化される。「条件文」のバリエーションは、「条件オペレータ」と「右辺条件項目」の間に、許容されない場合を含め３６個だけ存在する。

［表８］は「条件文」のバリエーションとスケルトンの例をそれぞれ示している。
ａ）ｄｏｕｂｌｅ型同士の代入の場合

［表８］において、各条件スケルトンに埋め込まれる置き換え文字列は、前述の「代入文」と同一である。

（４）ＸＥ＿生成スケルトンの「演算文」処理
演算文として登録されるバリエーションごとにデータが存在し、演算文を生成するための部分スケルトンが演算文スケルトンとして第２のリポジトリにマスタファイル化される。「演算文」のバリエーションは、左辺と右辺と２つの言語別データタイプ及び演算オペレータの間に１８個だけ存在する。ここで、演算オペレータには、「＋（加算）」、「−（減算）」、「＊（乗算）」、「／（除算）」、「＋＋（インクリメント）」及び「−−（デクリメント）」の６つがある。
［表９］は「演算文」のバリエーションとスケルトンの例をそれぞれ示している。
ａ）ＢｉｇＤｅｃｉｍａｌ型の演算文の場合

［表９］において、各演算スケルトンに埋め込まれる置き換え文字列のうち、＜％＃ Ｏ＿Ｆｌｄ ＃％＞は、演算結果のフィールドに対する変数の生成名で置き換えられる。これ以外の置き換え文字列は、前述の「代入文」と同一である。

（５）ＸＥ＿生成スケルトンの「ＭａｐＳｅｔ」処理
一のファンクションが他のファンクションを呼び出す際に、呼び出し先に引き渡すパラメータは、呼び出し先のＳｅｔｔｅｒメソッドに対するパラメータ引き渡しによって実行される。「ＭａｐＳｅｔ」においては、Ｓｅｔｔｅｒメソッドを呼び出す部分を生成するための部分スケルトンが第２のリポジトリにマスタファイルとして登録される。パラメータマッピングを行なうバリエーションごとにデータが存在し、「ＭａｐＳｅｔ」のバリエーションは、受け側と渡し側との２つの言語別データタイプごとに渡す項目の種類によって、許容されない場合を含め８個だけ存在する。［表１０］は「ＭａｐＳｅｔ」のバリエーションとスケルトンの例をそれぞれ示している。
ａ）ＢｉｇＤｅｃｉｍａｌ型同士の引き渡しの場合

［表１０］において、各ＭａｐＳｅｔスケルトンに埋め込まれる置き換え文字列には以下がある。

＜％＃ ＣａｌｌＦｕｎ ＃％＞：呼出先ファンクションの生成名で置き換えられる。

＜％＃ Ｔ＿Ｆｌｄ ＃％＞：呼出先ファンクションのパラメータとして設定されている項目の物理名で置き換えられる。

＜％＃ Ｔ＿ａＦｌｄ ＃％＞：呼出先ファンクションのパラメータとして設定されている配列項目の生成名で置き換えられる。

＜％＃ Ｍ＿Ｆｌｄ ＃％＞：引き渡す項目の生成名で置き換えられる。

＜％＃ Ｍ＿ａＦｌｄ ＃％＞：引き渡す配列の生成名で置き換えられる。

＜％＃ Ｍ＿ａＩｄｘ ＃％＞：引き渡す配列要素を示す指標変数の生成名で置き換えられる。

＜％＃ Ｃｎｄ ＃％＞：引き渡す配列要素を示す指標変数の生成名で置き換えられる。

（６）ＸＥ＿生成スケルトンの「ＭａｐＧｅｔ」処理
一のファンクションが他のファンクションを呼び出す際に、呼び出し先から受け取るパラメータは、呼び出し先のＧｅｔｔｅｒメソッドに対するパラメータ引き渡しによって実行される。「ＭａｐＧｅｔ」においては、Ｇｅｔｔｅｒメソッドを呼び出す部分を生成するための部分スケルトンが第２のリポジトリにマスタファイルとして登録される。パラメータマッピングを行なうバリエーションごとにデータが存在し、「ＭａｐＧｅｔ」のバリエーションは、受け側と渡し側との２つの言語別データタイプごとに渡す項目の種類によって３個だけ存在する。［表１１］は「ＭａｐＧｅｔ」のバリエーションとスケルトンの例をそれぞれ示している。
ａ）ＢｉｇＤｅｃｉｍａｌ型同士の引き渡しの場合

［表１１］において、各ＭａｐＧｅｔスケルトンに埋め込まれる置き換え文字列は「ＭａｐＳｅｔ」（但し、＜％＃ Ｃｎｄ ＃％＞を除く。）と同一である。

（第８の実施形態）
以下、本発明の第８の実施形態に係るシステム設計支援プログラムについて図面を参照しながら説明する。

前述したように、「ＭＤＦｒａｍｅ／Ｘ」は、上流設計部分を「ＸｕｐｐｅｒII」に特化した下流工程用ＣＡＳＥツールである。従って、基本的なユーザインタフェース（ＵＩ）は「ＸｕｐｐｅｒII」におけるＧＵＩ設計を対象としている。

ところで、本発明に係る「ＭＤＦｒａｍｅ／Ｘ」は、複数種類のプログラム言語（ソースコード）の生成が可能である。例えば、ＢｉｚＢｒｏｗｓｅｒ用のスクリプト言語は開発を完了しており、Ｍｉｃｒｏｓｏｆｔ．ｎｅｔのＣ＃言語及びＶｉｓｕａｌＢａｓｉｃ等も生成対象とすることが可能である。これらのプログラム言語はそれぞれの言語がサポートするＧＵＩコントロール（コントロールコマンド）を有しており、該ＧＵＩコントロールが言語ごとに異なることを前提とする必要がある。また、各言語ごとのＧＵＩコントロールは、メソッド名等もそれぞれに異なる。

しかしながら、ＧＵＩコントロールは、言語によってイベントの名称が異なっていたり、プロパティの種類が異なっていたりすることはあるものの、プロパティ、メソッド及びイベントの３要素により構成されていることは、いずれの言語においても共通である。

そこで、第８の実施形態に係る「ＭＤＦｒａｍｅ／Ｘ」は、特定の言語に依存しない「設計用ＧＵＩコントロール」を導入する。具体的には、ＧＵＩ画面上の各種コントロールのプロパティ、メソッド及びイベントをマスタファイル化して第２のリポジトリに登録して管理することにより、ＧＵＩ画面ロジック入力機能からこれらの要素を独立させる。

図２０は「ＸｕｐｐｅｒII」が扱うＧＵＩコントロールと、第８の実施形態に係る「ＭＤＦｒａｍｅ／Ｘ」が扱う「設計用ＧＵＩコントロール」と、生成対象となるＧＵＩコントロールとの関係を表わしている。

「ＸｕｐｐｅｒII」が扱うＧＵＩコントロールと、「ＭＤＦｒａｍｅ／Ｘ」が扱う「設計用ＧＵＩコントロール」とは、図２１のＥＲＤに示す「ＸＥ＿言語別省略時ＧＵＩコントロール割当」によって対応が決定される。すなわち、「ＭＤＦｒａｍｅ／Ｘ」は、「ＸｕｐｐｅｒII」が扱うＧＵＩコントロールにおける、「フィールドタイプ」、生成対象となる「言語種別ST」及び「コントロールタイプ」によって、設計用ＧＵＩコントロール種別を決定する。

これによって、例えば以下のような判断がなされる。

「ＸｕｐｐｅｒII」のＣＤＥタイプのフィールドにおいて、「コントロールタイプ」が「ＥＤＩＴタイプ」で配置されているＧＵＩ画面をＢｉｚＢｒｏｗｓｅｒ用の画面として使用する場合に、対応するコントロールの設計用ＧＵＩコントロールは「ＥｄｉｔＢｏｘ」となる。

「ＭＤＦｒａｍｅ／Ｘ」は、設計用ＧＵＩコントロールに対してプロパティの設定及びイベントロジックの記述を行なう。図２２は設計用ＧＵＩコントロールに関するＥＲＤを表わしている。図２２から、設計用ＧＵＩコントロールは、それぞれプロパティ（上段２列目）、メソッド（中段２列目）及びイベント（中段１列目）の３要素を含むことが分かる。ソースコードの生成が行なわれる際には、設計用ＧＵＩコントロールにおける「プロパティ」、「メソッド」及び「イベント」はそれぞれの生成対象である言語用のＧＵＩコントロールに変換される。

図２３は図２２に示したプロパティ、メソッド及びイベントの３要素に対して、それぞれの生成名に関する情報を格納するエンティティが追加されたＥＲＤを示している。図２３から分かるように、「ＸＥ＿設計用ＧＵＩＣＴＬプロパティー生成名」、「ＸＥ＿設計用ＧＵＩＣＴＬメソッド生成名」、「ＸＥ＿設計用ＧＵＩＣＴＬイベント生成名」及び「ＸＥ＿設計用ＧＵＩＣＴＬ種別生成名」の４種類のエンティティが追加される。

このように、プロパティ、メソッド、イベント及びこれらに関する生成名に関する情報をマスタファイル化することにより、ＧＵＩ画面ロジック入力機能からこれらの各要素に対する個別のロジックを排除することができる。従って、処理機能を簡単化できると共に、マスタファイル化することによって、新たなＧＵＩコントロールコマンドにも対応することが可能となる。

ところで、「ＸｕｐｐｅｒII」のＧＵＩコントロール画面に表示されるボタンは、「ＭＤＦｒａｍｅ／Ｘ」においても、設計用ＧＵＩコントロールのボタンとして処理される。

「ＭＤＦｒａｍｅ／Ｘ」においては、図２３に示した「ＸＥ＿設計用ＧＵＩＣＴＬイベント」により、「ＯｎＣｌｉｃｋ」という論理イベントの存在が認識されるため、このイベントに対するロジック入力機能が使用可能となる。

例えば、「ＯｎＣｌｉｃｋ」に入力されたロジックが「ＢｉｚＢｒｏｗｓｅｒ」のスクリプト言語として生成される場合は、「ＸＥ＿設計用ＧＵＩＣＴＬイベント生成名」を参照することにより「ＢｉｚＢｒｏｗｓｅｒ」の「ＯｎＴｏｕｃｈ（）イベント」として生成される。これに対し、「Ｍｉｃｒｏｓｏｆｔ．Ｎｅｔ」のソースコードとして生成される場合は、「ＸＥ＿設計用ＧＵＩＣＴＬイベント生成名」を参照することにより、「Ｃｌｉｃｋイベント」として生成される。

（第９の実施形態）
以下、本発明の第９の実施形態に係るシステム設計支援プログラムについて図面を参照しながら説明する。

ＧＵＩコントロールは、その実装方法によって種々の値（戻り値）の格納方法が存在する。従って、プログラマは戻り値の格納方法の相違を意識しながら、各種のコーディングを行なう必要がある。

図２４に「ＢｉｚＢｒｏｗｓｅｒ」におけるＧＵＩコントロールの実装例を示す。図２４は、論理的に同一の項目が、テキストボックスとして存在する場合とコンボボックス（combo box)として存在する場合の各定義部分を抽出して示している。

図２５はテキストボックスの場合とコンボボックスの場合との各項目の戻り値がいずれも「ＳＱＬ＿ＥＸＩＳＴ」であるか否かを判定する際に用いるロジックを示す。例えば、コンボボックスの場合の比較対象としている数字の”２”という戻り値はデータ自体の意味はなく、単にコンボボックスが有する要素のうちの２番目に位置することを示しているに過ぎない。このように、「ＳＱＬ＿ＥＸＩＳＴ」のように同一の意味を持つ値であっても、コントロールコマンドの種類によっては戻り値の参照方法が異なるため、「代入」及び「演算」等のソースコードを自動生成する際の生成ロジックが複雑になってしまう。

そこで、第９の実施形態においては、ＧＵＩ画面上の要素に対してパネル変数を導入して第２のリポジトリに登録し、ＧＵＩコントロールのコマンドタイプに依存しない戻り値の参照方法を採用する。

図２６に第９の実施形態に係るパネル変数の定義を示す。図２６に示すように、ＧＵＩコントロールの定義部分に関しては、図２５に示したソースと同等である。すべての画面上の戻り値は、コントロールコマンドを直接に参照するのではなく、このパネル変数を介して参照及び更新を行なう。この場合、パネル変数に取り込むロジックを記述する必要はあるものの、「ＭＤＦｒａｍｅ／Ｘ」においては、生成後のプログラム言語には存在しない論理メソッドを定義する。

この仕組みを図２７に示す。図２７に示すように、「画面上のコントロール」は、第９の実施形態に係る論理メソッド「ＧｅｔＡｎｄＶａｌｉｄａｔｅ」を「パネル変数」に対して発行することによって、該コントロールコマンドの妥当性の検査を伴って「パネル変数」に読み込まれる。メソッドを読み込んだ「パネル変数」は、「Ｐｕｔ」メソッドを「画面上のコントロール」に発行することによって、「画面上のコントロール」は「パネル変数」からの戻り値に対応してその状態が変更される。

図２８及び図２９に第９の実施形態に係る「ＧｅｔＡｎｄＶａｌｉｄａｔｅ」メソッド及び「Ｐｕｔ」メソッドの各生成例を示す。図２９に示すように、代入及び演算等のロジックは、画面コントロールに影響されることなく、単なるワークフィールドに対するロジックであるかのように展開されるため、簡単な構成となり、可読性が向上する。これにより、パネル上の項目の戻り値に関する判定ロジックは図３０に示すようになり、コントロールコマンドの種類によらず、同一の判定条件が展開されていることが分かる。

（第１０の実施形態）
以下、本発明の第１０の実施形態に係るシステム設計支援プログラムについて図面を参照しながら説明する。

一般に、ＧＵＩの画面は用途が同一である複数の表示項目の集合体により構成される。図３１に伝票入力形式の画面イメージの一例を示す。図３１において、それぞれ破線でグループ化された「伝票ヘッダー部」「明細行編集エリア」及び「明細行一覧表示エリア」には、それぞれに複数の表示項目が存在しており、各グループ内で同一の処理を行なう必要がある。例えば、判定結果がエラーとなった場合に、表示画面の背景色が変更されている表示項目について、その背景色を元に戻すという初期化処理を行なう場合がある。この場合、各表示項目ごとに同一の命令を所定数分だけ繰り返して記述するのが一般的である。

図３２に「ＢｉｚＢｒｏｗｓｅｒ」を生成対象言語とする場合の「伝票ヘッダー部」における各表示項目の背景色の初期化処理を示す。図３２に示すように、表示項目ごとに同一ロジックを繰り返し記述する必要がある。ロジック自体は単純ではあるが、このような繰り返し作業を一括に記述することを自動生成処理の対象にすることにより、プログラム開発における生産性を大きく向上させることができる。

第１０の実施形態においては、前述したパネル変数をグループ化することにより、グループ化された複数の表示項目に対して一括命令を発行する構成を採用する。ここでは、パネル変数をグループ化したものを「変数グループ」と呼ぶ。

以下、変数グループの各項目に対して一括に発行する命令セットを示す。

（１）「ＧｅｔＡｎｄＶａｌｉｄａｔｅ」：画面の表示項目に対する妥当性の検査を行なった後、コントロールコマンドをパネル変数に取り込む。

（２）「ＣｈｅｃｋＲｅｑｕｉｒｅｄ」：入力されたコマンドに対して必須入力チェックを実行する。

（３）「ＳｅｔＯｒｉｇｉｎａｌＳｔａｔｅ」：表示項目の背景色を初期値に戻す。

（４）「Ｐｕｔ」：パネル変数の値を画面の表示項目に書き出す。

これら（１）〜（４）の各命令をアクションダイアグラム上で変数グループに対していずれも１行分記述するだけで、ソースコードの生成時には、変数グループに含まれる表示項目に対して所定数分が繰り返して生成される。

これにより、単純な繰り返しのコーディング作業をなくすことができるため、プログラム開発における生産性の向上が図れる。

図３３に第１０の実施形態に係るＧＵＩ画面の表示項目に関するＥＲＤを示す。図３３において、１つのＧＵＩ画面ごとに、「ＧＵＩフォーム」エンティティのデータが作成される。また、１つのＧＵＩ画面の表示項目ごとに「ＧＵＩコントロール」エンティティのデータが作成される。

「ＧＵＩフォーム」、「ＸＥ＿ＧＵＩフォーム拡張」、「ＸＥ＿ＤＬＣＰ」、「ＸＥ＿ＢＰＴＢＬ」及び「ＸＥ＿ファンクション」はそれぞれ１対１で作成されて第２のリポジトリに登録される。例えば、図３１に示した画面イメージにおける「伝票ヘッダー部」、「明細行編集エリア」及び「明細行一覧表示エリア」の単位で、「ＸＥ＿ファンクション内変数グループ」が作成される。この「ＸＥ＿ファンクション内変数グループ」に対して、前述した「ＧｅｔＡｎｄＶａｌｉｄａｔｅ」コマンド等の一括命令を発行することにより、ソースコードの生成ロジックは、「ＸＥ＿ファンクション内変数グループ」に従属する「ＸＥ＿ファンクション内変数」の各表示項目に対してそれぞれ所定の処理が実行されて、複数のコントロールコマンドがソースコードに展開される。

図３４、図３５、図３６及び図３７に、「ＧｅｔＡｎｄＶａｌｉｄａｔｅ」コマンド、「Ｐｕｔ」コマンド、「ＳｅｔＯｒｉｇｉｎａｌＳｔａｔｅ」コマンド及び「ＣｈｅｃｋＲｅｑｕｉｒｅｄ」コマンドの各生成例を示す。

なお、ロジックはサブルーチン化された状態で生成されるため、複数の箇所から発行された場合の冗長性が回避される。

（第１１の実施形態）
以下、本発明の第１１の実施形態に係るシステム設計支援プログラムについて図面を参照しながら説明する。

システムが使用する複数の項目のなかには、業務を区分する区分値を管理する項目が存在する。これらの項目には、一般に、意味を示す外部値と実際に格納される値である内部値とがある。例えば［表１２］に示すように、得意先に対して「現金売り」と「掛売り」とを識別するための「入金方式区分」を持つような場合である。

プログラム中の処理では内部値を使用するが、該当する項目を画面に表示する場合には、その内部値の意味を人が分かるように、内部値を外部値に変換して表示するのが一般的である。これを実現するために、通常は変換ロジックを個々に記述する必要がある。

この内部値の外部値への変換ロジックは単純ではあるものの、このような単純作業こそ自動生成処理の対象とすることにより、単純作業によるミスの防止とプログラム開発における生産性とを確実に向上することができる。

そこで、第１１の実施形態に係る「ＭＤＦｒａｍｅ／Ｘ」は、実際のデータではなく、例えば第１のリポジトリに格納されている定義情報を参照する場合に、参照した定義情報を共通マクロ命令として展開させる方法を採る。

図３８に第１１の実施形態に係る共通マクロに関するＥＲＤを示す。図３８の「ＸＥ＿ロジック行」に対して、アクションダイアグラムの１行分の情報が格納される。このとき、［表１２］の外部値の変換処理を行なう場合に、ロジック行には「命令種別ST：コンディション名取得」の値が設定される。また、命令種別に対応する「ＸＥ＿組込関数パラメータ」には、コンディション名を取得したい項目と、コンディション名を返したい項目とが登録されている。

また、ロジック行と対応する「ＸＥ＿組込関数パラメータマッピング」に対して、「ＸＥ＿組込関数パラメータ」と対応する項目をマッピング（対応付け）した情報が格納される。

図３９は実際のアクションダイアグラムにより、共通マクロ命令に対するパラメータマッピングを行なう画面イメージを表わしている。図３９において、「入力.ＭＤ＿プグラムモード」の値を外部値に変換したものが「ローカル.Ｕ＿モード#表示」に格納される。

図４０に図３９に示したアクションダイアグラムに入力された１行分のマクロ命令から４通りのソースコードとして生成される様子を示す。具体的には、第１のリポジトリの内容を参照して、「検索」、「削除」、「追加」及び「変更」のうちのいずれか１つの外部値を設定するか否かを判定するロジックが展開される。

このように、ソースコードの生成時に、第１のリポジトリを参照することにより、定型的なロジックを自動生成することができるため、プログラムの開発効率を高めることができる。

本発明に係るシステム設計支援プログラムは、上流設計用ツールである「ＸｕｐｐｅｒII」を用いて、下流工程であるプログラム開発をブリッジ及び人手を介することなく自動的に行なえるようになり、業務向けシステムのシステム設計に用いられるシステム設計支援プログラム（ＣＡＳＥツール）に用いるプログラム等として有用である。

本発明の第１の実施形態に係るシステム設計支援プログラムを示す概略ブロック図である。 本発明の第１の実施形態に係るシステム設計支援プログラムにおける「ＭＤＦｒａｍｅ／Ｘ」が複数のソースコードを生成する様子を示すブロック図である。 本発明の第１の実施形態に係るシステム設計支援プログラムにおけるスケルトンの一例を示すコード図である。 図３に示すスケルトンによるソースコードの生成結果の一例を示すコード図である。 図３から図４の処理を実施する際のデータ構造を表わすエンティティ関連図（ＥＲＤ）である。 本発明の第２の実施形態に係るシステム設計支援プログラムにおけるＳＱＬ定義に関するテーブル（ＥＲＤ）の一例を示す図である。 本発明の第２の実施形態に係るシステム設計支援プログラムにおける直接入力したＳＱＬ定義に関する情報を格納したテーブル（ＥＲＤ）の一例を示す図である。 本発明の第３の実施形態に係るシステム設計支援プログラムにおける第２のリポジトリに格納されたマクロファンクションのＥＲＤの一例を示す図である。 本発明の第３の実施形態に係るシステム設計支援プログラムにおいて、あるファンクションにロジック（マクロファンクション）を入力した図である。 図９に示したマクロファンクションを呼び出す行と対応したウィザードを示す図である。 図１０に示したウィザードにおいて「次へ（Ｆ９）」のボタンが押下された後に表示されるウイザードを示す図である。 本発明の第３の実施形態に係るシステム設計支援プログラムにおいて、マクロの実体を記述するためのＮａｔｉｖｅ文を受け付けるウイザードを示す図である。 本発明の第４の実施形態に係る「ＸｕｐｐｅｒII」がアクセスするディクショナリに格納されたデータのフィールドに関するエンティティを示すＥＲＤの一例を示す図である。 本発明の第４の実施形態に係るシステム設計支援プログラムにおいて、「ＸｕｐｐｅｒII」における「フィールドタイプ」と「ＭＤＦｒａｍｅ／Ｘ」における「ＸＥ＿言語別データタイプ」とを互いに関連付けるＥＲＤの一例を示す図である。 本発明の第５の実施形態に係るシステム設計支援プログラムにおいて、アクションダイアグラムに対して「代入」処理を入力する際のウィザードの一例を示す図である。 本発明の第５の実施形態に係るシステム設計支援プログラムにおいて、「ＸＥ＿言語別データタイプ」と「ＸＥ＿言語別データタイプ関連」とのＥＲＤの一例を示す図である。 本発明の第６の実施形態に係るシステム設計支援プログラムにおいて、アクションダイアグラムに対して「代入」処理を入力する際のウィザードの一例を示す図である。 本発明の第６の実施形態に係るシステム設計支援プログラムにおいて、「ＸＥ＿言語別データタイプ」と「ＸＥ＿言語別データタイプ許容CND」とのＥＲＤの一例を示ス図である。 本発明の第７の実施形態に係るシステム設計支援プログラムにおける部分スケルトンに関するＥＲＤの一例を示す図である。 本発明の第８の実施形態に係るシステム設計支援プログラムにおける「ＸｕｐｐｅｒII」が扱うＧＵＩコントロールと、「ＭＤＦｒａｍｅ／Ｘ」が扱う「設計用ＧＵＩコントロール」と、生成対象となるＧＵＩコントロールとの関係を表わすブロック図である。 本発明の第８の実施形態に係るシステム設計支援プログラムにおける「ＸＥ＿言語別省略時ＧＵＩコントロール割当」に関するＥＲＤの一例を示す図である。 本発明の第８の実施形態に係るシステム設計支援プログラムにおける設計用ＧＵＩコントロールに関するＥＲＤの一例を示す図である。 図２２に示したプロパティ、メソッド及びイベントの３要素に対して各生成名に関する情報を格納するエンティティが追加されたＥＲＤの一例を示す図である。 本発明の第９の実施形態に係るシステム設計支援プログラムにおける「ＢｉｚＢｒｏｗｓｅｒ」を生成対象言語とする場合のＧＵＩコントロールの実装例を示すコード図である。 本発明の第９の実施形態に係るシステム設計支援プログラムにおけるテキストボックスの場合とコンボボックスの場合との各項目の戻り値がいずれも「ＳＱＬ＿ＥＸＩＳＴ」であるか否かを判定する際に用いるロジックを示す図である。 本発明の第９の実施形態に係るシステム設計支援プログラムにおけるパネル変数の定義を示す図である。 本発明の第９の実施形態に係るシステム設計支援プログラムにおけるパネル変数のアクセスの方法を示すブロック図である。 本発明の第９の実施形態に係るシステム設計支援プログラムにおける「ＧｅｔＡｎｄＶａｌｉｄａｔｅ」メソッドの一生成例を示すコード図である。 本発明の第９の実施形態に係るシステム設計支援プログラムにおける「Ｐｕｔ」メソッドの一生成例を示すコード図である。 本発明の第９の実施形態に係るシステム設計支援プログラムにおけるパネル上の項目の戻り値に関する判定ロジックの一例を示すコード図である。 本発明の第１０の実施形態に係るシステム設計支援プログラムにおける伝票入力形式の画面イメージの一例を示す図である。 本発明の第１０の実施形態に係るシステム設計支援プログラムにおいて、「ＢｉｚＢｒｏｗｓｅｒ」を生成対象言語とする場合の「伝票ヘッダー部」における各表示項目の背景色の初期化処理を示コード図である。 本発明の第１０の実施形態に係るシステム設計支援プログラムにおけるＧＵＩ画面の表示項目に関するＥＲＤの一例を示す図である。 本発明の第１０の実施形態に係るシステム設計支援プログラムにおける「ＧｅｔＡｎｄＶａｌｉｄａｔｅ」メソッドの一生成例を示すコード図である。 本発明の第１０の実施形態に係るシステム設計支援プログラムにおける「Ｐｕｔ」メソッドの一生成例を示すコード図である。 本発明の第１０の実施形態に係るシステム設計支援プログラムにおける「ＳｅｔＯｒｉｇｉｎａｌＳｔａｔｅ」メソッドの一生成例を示すコード図である。 本発明の第１０の実施形態に係るシステム設計支援プログラムにおける「ＣｈｅｃｋＲｅｑｕｉｒｅｄ」メソッドの一生成例を示すコード図である。 本発明の第１１の実施形態に係るシステム設計支援プログラムにおける共通マクロに関するＥＲＤの一例を示す図である。 本発明の第１１の実施形態に係るシステム設計支援プログラムにおける実際のアクションダイアグラムにより、共通マクロ命令に対するパラメータマッピングを行なう画面イメージを表わす図である。 図３９に示したアクションダイアグラムに入力された１行分のマクロ命令から４通りのソースコードとして生成されたコード図である。

符号の説明

１０ ＸｕｐｐｅｒII
１１ 第１のリポジトリ
２０ ＭＤＦｒａｍｅ／Ｘ
２１ 第２のリポジトリ
３０ 統合リポジトリ
３１ ＢｉｚＣＲＳファイル
３２ Ｊａｖａソース
３３ Ｐｒｏｃｅｄｕｒｅソース

Claims (13)

1. データ中心アプローチ手法を用いたシステム設計支援プログラムであって、
   コンピュータに、
   入力された業務フローを複数のプロセスに階層化する機能Ａと、
   前記各プロセスに用いる複数のエンティティと、該エンティティ同士の互いの関連を表わすエンティティ関連図を作成する機能Ｂと、
   前記各プロセスに必要な入出力データ及び前記各エンティティのフィールドデータを保持するディクショナリを作成する機能Ｃと、
   前記エンティティ関連図及び前記ディクショナリを参照して、グラフィカルユーザインタフェース設計を行なう機能Ｄと、
   前記各プロセスにおける階層化データ、前記各エンティティの属性データ、前記ディクショナリ及び前記グラフィカルユーザインタフェース設計に関するデータをそれぞれ登録してリポジトリを作成する機能Ｅと、
   前記各プロセス、前記各エンティティ、前記ディクショナリに保持されたデータ及び前記グラフィカルユーザインタフェース設計に関するデータのうちの少なくとも１つを参照し、且つ、外部から前記各プロセスを実行可能とするロジック定義を入力することにより、ソースコードを自動生成して出力する機能Ｆとを実現させ、
   前記機能Ｆは、前記ロジック定義を入力する際にＳＱＬ構文を用いており、前記ロジック定義を入力する際に、入力されたロジック定義が前記ＳＱＬ構文に定義されている場合はウィザードによる対話形式を用いる一方、入力されたロジック定義が前記ＳＱＬ構文に定義されていない場合は、定義されていないロジック定義を直接に入力して前記リポジトリに登録する機能を含むことを特徴とするシステム設計支援プログラム。
2. 前記ソースコードは、Ｊａｖａ言語、高速機関Ｐｒｏｃｅｄｕｒｅ言語又はＢｉｚＣＲＳ言語であることを特徴とする請求項１に記載のシステム設計支援プログラム。
3. 前記機能Ｆにおける前記ソースコードは、前記各プロセスごとに該プロセスを実行するファンクションを有し、
   前記機能Ｆは、前記ファンクションにおいて、前記ロジック定義を展開するロジック文の構成要素を、それぞれがソースコードの骨組みである複数のスケルトンにより構成する機能と、前記複数のスケルトンを、スケルトンロジック部と、置換文字列別生成ロジック部と、ユーザポイント別生成ロジック部とに分解する機能と、分解された前記置換文字列別生成ロジック部を、前記リポジトリに登録されたデータのうち前記置換文字列別生成ロジック部と対応するデータと置換する機能と、分解された前記ユーザポイント別生成ロジック部を、入力された前記ロジック定義と置換する機能とを含むことを特徴とする請求項１又は２に記載のシステム設計支援プログラム。
4. 前記機能Ｆは、外部から前記スケルトンロジック部を書き換え可能とする機能を含むことを特徴とする請求項３に記載のシステム設計支援プログラム。
5. 自動生成されないソースコードをあらかじめマクロファンクションとして前記リポジトリに登録する機能Ｇをさらに備え、
   前記機能Ｆは、前記ソースコードを自動生成する際に、前記リポジトリに登録された前記マクロファンクションを前記ソースコードに展開する機能を含むことを特徴とする請求項１〜４のいずれか１項に記載のシステム設計支援プログラム。
6. 前記機能Ｃは、前記各エンティティのフィールドデータにおけるデータ型を、前記ディクショナリに前記ソースコードの言語種別に応じて第１のマスタファイルとして保持することを特徴とする請求項１〜５のいずれか１項に記載のシステム設計支援プログラム。
7. 前記機能Ｃは、前記各エンティティのフィールドデータ同士の間で実行されるデータの代入、演算、比較及び呼び出しパラメータの照合のうちの少なくとも１つの処理を行なう際に、行なう処理ごとの妥当性を判定するコードを前記ディクショナリに第２のマスタファイルとして保持する機能を含むことを特徴とする請求項６に記載のシステム設計支援プログラム。
8. 前記機能Ｃは、前記各エンティティのフィールドデータ同士の間で実行されるデータの代入、比較及び呼び出しパラメータの照合のうちの少なくとも１つの処理を行なう際に、行なった処理の結果の出力条件ごとの妥当性を判定するコードを前記ディクショナリに第３のマスタファイルとして保持する機能を含むことを特徴とする請求項６又は７に記載のシステム設計支援プログラム。
9. 前記機能Ｃは、前記各エンティティのフィールドデータ同士の間で実行されるデータの代入文、条件文、演算文及びパラメータの照合のうちの少なくとも１つの処理を行なう際に、行なう処理と対応するソースコードごとの生成ルールを前記ディクショナリに第４のマスタファイルとして保持する機能を含むことを特徴とする請求項６〜８のいずれか１項に記載のシステム設計支援プログラム。
10. 前記機能Ｅは、前記グラフィカルユーザインタフェース設計に用いるコントロールコマンドにおけるプロパティ、メソッド及びイベントを前記ソースコードに依存しない設計用コントロールコマンドとして前記リポジトリに登録する機能を含み、
    前記機能Ｆは、前記プロパティ、メソッド及びイベントを、前記設計用コントロールコマンドと、前記各エンティティのフィールドデータのデータ型と、前記ソースコードの種別とに基づいて、前記ソースコードと対応したグラフィカルユーザインタフェースを生成する機能を含むことを特徴とする請求項１〜９のいずれか１項に記載のシステム設計支援プログラム。
11. 前記機能Ｅは、前記グラフィカルユーザインタフェース設計に用いるコントロールコマンドの戻り値をパネル変数として前記リポジトリに登録する機能を含み、
    前記機能Ｆは、前記パネル変数を前記ソースコードに依存しない論理メソッドを発行して取得し、取得したパネル変数を前記ソースコードに展開する機能を含むことを特徴とする請求項１〜１０のいずれか１項に記載のシステム設計支援プログラム。
12. 前記機能Ｅは、前記グラフィカルユーザインタフェース設計に用い、種別が同一で複数のコントロールコマンドに参照される各パネル変数をグループ化して前記リポジトリに登録する機能を含み、
    前記機能Ｆは、前記複数のコントロールコマンドを、前記グループ化されたパネル変数ごとに一のコマンドを発行する一括コマンドに変換する機能と、
    前記一括コマンドを発行することにより、対応する前記パネル変数を取得し、取得したパネル変数をその括られた個数だけ前記ソースコードに展開する機能を含むことを特徴とする請求項１〜１１のいずれか１項に記載のシステム設計支援プログラム。
13. 前記機能Ｅは、前記各プロセスに固有の定義情報を共通化した共通マクロ命令を前記リポジトリに登録する機能を含み、
    前記機能Ｆは、前記ソースコードを生成する際に、前記ロジック定義が前記共通マクロ命令を参照する機能を含むことを特徴とする請求項１〜１２のいずれか１項に記載のシステム設計支援プログラム。