(57)【要約】【課題】  従来のｗｅｂやバッチシステムの業務層の設計・開発・保守作業では膨大な仕様書ドキュメントを書き、読み、理解し、プログラムを作成する必要があり、開発生産性が低くまた保守を重ねるほど仕様書品質が悪化する構造的な問題を抱えていた。【解決手段】  ビジネスフローやプログラムを限られた数の柔軟性の高い型で組み合せて構成し、それをシステム構造情報に登録し、システム構造情報と型ごとのひな型ソースプログラムと入出力データ属性オブジェクト情報からプログラムをビジネスフロー単位に一括自動生成できるようにした。【選択図】図２ａ
2015022433.tif 000002
【特許請求の範囲】
【請求項１】
ｗｅｂまたはバッチシステムの次の（ａ）〜（ｅ）の方法を組合せたフトウエア開発方法であって、
（ａ）はビジネスフローやそれを構成するプログラムの構造情報をシステム構造情報として持ちかつプログラムを限られた種類の単純な機能の型に分け、型ごとにひな型プログラムを持ち、ひな型とシステム構造情報と入出力データ属性オブジェクト情報とからプログラムを自動生成することを特徴とするソフトウエア開発方法であり、
（ｂ）はビジネスフローを幾つかの単位ビジネスフロー（ビジネスロジックとそれから起動されるプログラムのセット）で構成し、ビジネスロジックもプログラムもぞれぞれ型で構成し、それらの型のひな型プログラムとシステム構造情報とプログラムごとの入出力データ属性オブジェクト情報とから（ａ）の方法を適用して単位ビジネスフローを一括生成することを特徴とするソフトウエア開発方法であり、
（ｃ）は（ａ）の方法で自動生成するプログラムに、その元情報であるシステム構造情報をも書き加えることで、プログラムを更新した後でも更新プログラムのシステム構造情報から元情報であるシステム構造情報を逆生成できる特徴を持つソフトウエア開発方法であり、
（ｄ）は予めひな型プログラムを構造化しておきそれを（ａ）の方法で自動生成するプログラムにそのまま反映させるようにし、またその自動生成プログラムの構造化情報から組込部品情報を自動生成し、その組込部品情報にプログラムの更新履歴を自動的に書き込む特徴を持つソフトウエア開発方法であり、
（ｅ）はシステム構造情報のノード情報に固有のバージョン情報を、また関係性情報内にセットバージョン情報を持ち、それを用いてノード情報の共有とシステム全体のバージョン管理を同時に実現する特徴を持つソフトウエア開発方法である。
【請求項２】
プログラムを限られた数の型に分け、型ごとにひな型プログラムを予め用意し、システム構造情報はひな型プログラムと入出力データ属性オブジェクト情報へのリンク情報を持ち、ひな型プログラム中にはソースコード情報部と変換指示情報部を持ち、ソースコード情報部のプログラム行は複数の変換式タイプに分れ、また最終的には他の名前で置換される仮名で記述され、変換指示情報部にはプログラム行の変換式タイプの区別や入出力データ属性オブジェクト情報を参照できる情報を持ち、それらを使って入出力データ属性オブジェクト情報から必要情報を取り出して、ひな型のプログラム行の変換式を繰り返し生成したり仮名を置き換えたりして、プログラムを自動生成することを特徴とする請求項１（ａ）記載のソフトウエア開発方法。
【請求項３】
ビジネスロジックを限られた数の型に分け、型ごとにひな型プログラムを予め用意し、システム構造情報にはビジネスロジックとそれから起動されるプログラムの構造情報を持ち、ひな型プログラム中にはソースコード情報部と変換指示情報部を持ち、ソースコード情報部のプログラム行は複数の変換式タイプに分れ、また最終的にはシステム構造情報からの抽出情報で置き換えられる仮名で記述され、変換指示情報部にはプログラム行ごとに変換式タイプやその他の変換指示情報を持ち、その変換式タイプや変換指示情報でシステム構造情報を参照してひな型のプログラム行を削除したり、繰り返し生成したり、書き換えたりしてビジネスロジックを自動生成し、またビジネスロジックから起動されるプログラムはシステム構造情報と入出力データ属性オブジェクト情報から請求項２の方法を適用して一括自動生成し、その際使う中間のデータ属性オブジェクト情報はビジネスフローの先頭に与えるデータ属性オブジェクト情報とプログラムの型ごとのデータ変換特性から次のデータ属性オブジェクト情報を順次自動生成することを特徴とする請求項１（ｂ）記載のソフトウエア開発方法。
【請求項４】
ひな形プログラムのコメント行にＸＭＬタグでシステム構造情報を書き込む位置を予め定めておき、請求項２または請求項３の方法でプログラムやビジネスロジックを自動生成するとき、自動生成プログラムでシステム構造情報をも書き込むようにし、その後自動生成したプログラムを更新したとき、そのＸＭＬタグ情報からシステム構造情報を自動的に逆生成することを特徴とする請求項１（ｃ）記載のソフトウエア開発方法。
【請求項５】
ひな形プログラムのコメント行にプログラムの構造化区分をＸＭＬタグで表現し、そこから請求項２または請求項３の方法で自動生成されるプログラムやビジネスロジックも必然的にＸＭＬタグで構造化されるようにし、また生成されるＸＭＬタグ情報からそのプログラムを更新したあともＸＭＬタグからプログラムの組込部品情報を自動生成し、プログラムの更新前後の内容の差分を自動的に取得しそれを組込部品情報に更新履歴として書き込むことを特徴とする請求項１（ｄ）記載のソフトウエア開発方法。
【請求項６】
システム構造情報のノード情報にノード固有のバージョン情報を持ち、関係性情報にはセットバージョン情報を持ち、セットバージョン情報は全階層でひとつではなく階層内関係性情報に階層内セットバージョン情報、階層間関係性情報に階層間セットバージョン情報を別々に持ち、それによってノード更新時の関係性情報のセットバージョン情報の更新数を抑制し、ノード個別のバージョン管理、階層内のセットバージョン情報管理、システム全体のセットバージョン情報管理を同時に可能とする特徴を持つ請求項１（ｅ）記載のソフトウエア開発方法。
【発明の詳細な説明】
【技術分野】
【０００１】
ｗｅｂシステムまたはバッチシステムの開発で、業務層のビジネスフローやプログラムを限られた数の型に分け、型ごとにビジネスロジックやプログラムのひな型プログラムを持ち、ひな型の中の情報からシステム構造情報や入出力データ属性オブジェクト情報を参照してプログラムやビジネスロジックを柔軟に自動生成または一括自動生成するソフトウエア開発方法に関する。今回の特許請求の基本設計思想は図１に示すように「システムを型で掴み、表現し、理解する」ことであり、それを実現するための技術の全体構成図を図２に、情報の構成図を図２ａ示す。
（注１）ビジネスロジックは主としてプログラムを呼び出すだけの、流れを制御するプログラムを指す。一般的なビジネスロジックの意味とは異なる。
【背景技術】
【０００２】
従来技術とその問題点
（問題点１）ドキュメント量が膨大。文章を読まないと分からない仕様書。
ホストコンピュータやC／S上のシステムではプログラム一本に沢山の処理を含むためプログラムが大規模で複雑になる。オンライン系のプログラムを例にとると、ホストコンピュータの時代には一画面の全ての処理を一本のプログラムで記述したのでステップ数は長大であったが、C／Sの時代では画面を複数に分割し、イベントごとに分けて記述するようになりプログラムが小型化した。しかしまだビジネスフロー中に複数の機能を含んでいるので、仕様書による詳細な説明が不可欠で、依然として記述量が多い。
その結果どのシステムでもほぼ次のような似通った問題を抱えることになった。
（ａ）システムを理解するには膨大なドキュメントを読まなければならない
（ｂ）システムを習得するまで長い期間がかかる。保守業務が属人化しやすい
（ｃ）保守を重ねるにつれてドキュメント品質が悪化する
これらは本質的には１プログラムに大規模な処理を含んでいるプログラムの構造的な問題に起因する。もしプログラムが単一機能を記述するだけなら非常に単純で分り易くなり、それによって自動生成が可能なプログラムも多数出てくる。
【０００３】
（問題点２）似たような処理の繰り返しが分かり易さや開発生産性効率に繋がらない
プログラムの制御構造や処理の組合せを観察すると、少しずつ違って似通った処理がたくさんある。しかるにそのことが、仕様書の分かり易さや開発生産性の効率化に繋がっていない。
似通った処理群をひとつの型とみなし、もし型が単純で限られた数しかない場合には、型を通してビジネスロジックやプログラムの内容を把握したり、また型からプログラムを自動生成し後から違う部分だけを修正すれば、生産効率もずっと高められる（図４）。ここで言う型とは従来のサブルーチンやクラスのような処理が固定的なプログラムではなく、プログラムの前の段階の多少違いを含んだずっと柔軟な括りを指す。従って型とは設計段階から使う考え方である。また型は参考文献：Ｅ．Ｇａｍｍａ他著、「オブジェクト指向における再利用のためのデザインパターン」で扱っているデザインパターンとも明確に異なっている。デザインパターンはミドルウエアやフレームワークなどの複雑なシステム構造の設計で活かせる、抽象的に記述された一般的な解法であるのに対し、型は業務ロジックレベルを具体的に記述する。
【０００４】
（問題点３）ソースプログラムが数ページにも及び非常に読み難い
一本のプログラムのステップ数が多くなるとソースプログラムは著しく見難くなる。例えばｉｆ文やｌｏｏｐ文が多数混在する中で、あるｉｆ文と対になるｅｌｓｅｉｆ文やｅｎｄｉｆ文が数ページも先に現れたり、またｌｏｏｐ文と対になるｅｎｄｌｏｏｐ文にも同じ問題が現れる。従ってソースの内容はシンプルであってもそれを解読するために長時間費やしている。もしプログラムを単一機能単位に分割すればプログラムは小さく簡単になり大幅に見易さは改善される。しかしそれでも数ページに渡ればソースプログラムは決して見易くはないので、特にソースと仕様書を兼用させる場合には、ソースとは別に１ページ内で一目で分る内部構造図があると便利である（図５）。
ソースの読み難さに加えて、多くの場合プログラムの更新履歴をソースプログラムの中に書き込んでいる。このやり方では更新を重ねるごとにソースは非常に見苦しくなる。プログラムと更新履歴を密着させながらもプログラムに直接書き込まない更新履歴が欲しい。
【０００５】
（問題点４）  オブジェクト指向に於けるこれらの問題
オブジェクト指向は複雑なシステムの開発に対して高い品質、生産性を発揮できる優れた開発言語である。しかし現在最も進化した技術と雖もこれらの問題の解決策になりえていない。複雑なシステムでこそ極めて効果的に活きる利点が、むしろ簡単なｗｅｂやバッチの業務処理の領域では逆に足枷になる側面がある。
まず問題点１のプログラム単位を小さくする点では問題ない。しかし問題点２の処理の繰り返しを分かり易さや生産効率に繋げる点では、そもそも業務層の領域ではクラスはほとんど従来型のサブルーチンに近いので、周囲の期待ほど成功しているように見えない。ただ単にシステムが多くの個別サブルーチンの集合で構成されるというだけでは従来のＣ言語と同じである。型はサブルーチンとは違って、処理やデータの違いがあっても似ている業務処理を類型化する考え方である。業務層の繰り返しが多い性質を利用して、小さな違いはあっても構わないので限られた型で業務を外枠から把握したいのである。本来オブジェクト指向は高い抽象性の実現を目指したものだし、オブジェクトという構造体こそはそのシンボルであると思われるが、しかしオブジェクト指向では処理が似ていても扱うデータが異なれば相互に何の関係もない別のクラスになるので、システムを類型で括って理解し易くするとか、異なるクラスを同じ型から生成する等の考え方はしないのである。
【０００６】
（問題点５）  オブジェクト指向の問題・・プログラムの組合せの複雑さ
プログラム単位を小さくすると普通組合せが複雑化する反作用が生ずる。オブジェクト指向は全て部品だけで組合せ、部品が累々と繋がる構造をとる。プログラムの大きさと組合せの難易度の関係を図６に示す。
オブジェクト指向ではデータと処理をカプセリングすることで複雑なクラスの集まりの品質を保証する。複雑な処理を扱う場合はオブジェクト指向のように処理とデータは一体化する方が遥かに扱いやすい。逆に処理とデータが別々では保守が困難で到底使用に絶えない。普通オブジェクト指向のシステムを表現するためにＵＭＬという仕様書表記法を使う。しかしＵＭＬはオブジェクト指向と密接に関連し専門家以外にはなかなか理解できない。
ｗｅｂやバッチの業務処理フローはもともと単純なので処理とデータを切り離すことができ、また大部分が図６２、図６３のビジネスフローのような単純な流れをとる。処理とデータがあたかも一体であるかのように１フロー上に並び、処理の順番やデータの入出力の関係が一目で分る。ｗｅｂやバッチ処理の単純なブジネスフロー全体が型として扱える。単純なｗｅｂやバッチ処理に対しUMLを一律に適用したのではわざわざシンプルな問題を複雑に見せるようなものである。
組み込み系のシステムではＵＭＬからクラスを自動生成する機能が普及してきている。それはまだ１００％記述したものを１００％生成するに近いもので、型から生成する考え方とは明らかな違いがある。
【０００７】
（問題点６）  オブジェクト指向の問題・・技術習得の難しさ
業務層のシンプルな処理を記述するには本来どの言語にもほぼ共通な極めて少数の単語（コマンド）で済むにも拘わらず、オブジェクト指向では相当に部品体系に習熟しないと使いこなせない。またオブジェクト指向の設計では問題点２の参考文献で述べたデザインパターンを理解することが望ましいが、それとてもスキルや経験が必要でデザインパターンの適用をアシストする仕組みを特許申請している文献（特開平９−２３７１８０、特開２０００−３０５７６６）も見られる位である。
またホストやC／S上のシステムではミドルウエアとして扱っていた画面層やＩＯ層がオブジェクト指向ではユーザに任せられている。これらＩＴ技術への依存度が極めて高い層についてはフレームワーク化することでその困難さが軽減されてきてはいる。しかしフレームワークの理解にまた時間が費やされるうえに、フレームワーク自体が多様化し変化する。パワーのあるエンジニアでなければ全体を理解して使うことができない。フレームワークやオブジェクト指向固有の技術や言語などは、ひな型の中に隠蔽して直接ユーザが記述する必要がないようにすることが望ましい。
【０００８】
（課題対象領域の設定）
ｗｅｂシステムを図３のように３階層に分けた場合、画面層、IO層は大部分フレームワークでカバーされているので課題対象から外し業務層にのみに課題対象を絞った。業務層は固有の業務部分を扱うために、問題点４，５で述べたような理由で折角のオブジェクト指向の再利用技術が生きているとは言い難い。従って業務層はフレームワークの谷間になり、また部品化再利用もせいぜい共通業務のサブルーチン化止まりになってしまう。要は業務層に関しては昔ながらのＣＯＢＯＬで開発した方がよっぽど簡単だということになりかねない。また部品化再利用の意義がすっきりしないまま一辺にＥＲＰパッケージへ飛躍してしまうのではしかるべき手順を踏んでいないようにも見える。ここを乗り越えるためにビジネスフローやプログラムの柔軟な型を取り入れた。言うまでもなく型はシンプルな業務処理領域に適用されてこそ有用である。型の考え方をオブジェクト指向のような開発技術をベースにしそれを十分活用し、その上に被せるように適用する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開平９−２３７１８０号公報
【特許文献２】特開２０００−３０５７６６号公報
【非特許文献】
【００１０】
【非特許文献１】「オブジェクト指向における再利用のためのデザインパターン」、Ｅ．Ｇａｍｍａ他著、ソフトバンク、1995
【発明の概要】
【発明が解決しようとする課題】
【００１１】
１．新開発方法の開発生産性と品質の実現目標
ｗｅｂやバッチシステムでの開発生産性と３つの品質の観点、すなわちシステムの分かり易さや仕様書ボリュームや仕様書の老化の早さについて、従来のC／Sシステムとオブジェクト指向を開発者の感覚で位置づけ、それと新開発方法の到達目標を比較する。図７の横軸に開発・保守の生産性、縦軸に３つの品質の観点をとると、従来のC／S方式に対してオブジェクト指向は周囲の期待ほどには高くない。まさに従来の言語でも十分対応ができるほど処理が単純でありかつ再利用のレベルもサブルーチン化のレベルにとどまるからである。ＳＥの技術習得の負担まで考慮に入れるなら立ち位置が逆転しかねない。これに対して新開発方式では次に述べる考え方で生産性、品質を同時に改善する。
【００１２】
２．柔軟な型とそのひな型プログラムを使ったシステム開発方法
新しい開発方法では次の様々な違いに対する対応力の柔軟性を持たせている。
（ａ）オブジェクト指向のような従来の技術をベース技術としてそれを活用
（ｂ）ｊａｖａ等開発言語の固有な部分や特殊技術をひな型に隠蔽
（ｃ）ｗｅｂでもバッチでも同じ方法を適用
（ｄ）プログラム開発段階にも、設計段階にも型は使える。異なる業務でも型は共通である。
（ｅ）単一機能のプログラムの型を組合せビジネスフローを柔軟に構成する
（ｆ）プログラムの型はファイル数やデータ項目数、項目名の違いに柔軟に対応
（ｇ）保守時には、システム構造情報から自動生成するソース・仕様書一体情報を直接更新し、その更新結果をシステム構造情報へ反映させる。
【００１３】
この中でもビジネスフローの設計段階から柔軟な型に当て嵌めながら段々とプログラムの型にまで落とし、システム構造情報に登録し、最後に一括自動生成するところに大きな特徴がある。ビジネスフローの枠組みを自動生成するわけで、自動生成されるプログラムには完成プログラムも、未完成でプログラムの枠と制御部分だけのプログラムも混在する。未完成のプログラムは保守と同様にビジネスルールを追加更新して完成させる。
【００１４】
３．プログラム機能の単一機能化とプログラムおよびその組合せの型の問題
２．（ｆ）について補足をする。新しい部品化再利用の基本になる考え方が（ａ）プログラムを単一機能単位に分割し、（ｂ）プログラムやその組合せを柔軟な型で捉えて類型化し、（ｃ）型のひな型から仕様書プログラム一体構造を自動生成または一括生成する方法である。固有の業務処理をこれ以上分割できない塊りと見てしまわずに、これもまた単一の機能単位の組合せであると考える。また単一の機能単位とは処理の型にピュアな業務処理が作用した形とみなす。例えばＳＱＬコマンドは全てのデータに共通な集合処理の型に、ｗｈｅｒｅ句以下のオペランドを作用させた処理である。わずか数種類のＳＱＬコマンド（型）で集合処理が識別され、オペランド（ピュア業務）で処理内容を規定する。一般の業務処理も単一機能まで分解すればこのような簡単な型から組み立てられると考える。この型はサブルーチンとは異なり柔軟な括りで小さな違いを吸収するようにする。一方ビジネスフローは制御の流れの組み合せ方に着目し、プログラムの処理内容には関知せずに括る。ビジネスロジックの型は制御プログラムの型である。
【００１５】
４．システム構造情報のリバースエンジニアリング
２．（ｇ）について補足する。新しい開発方法では型ごとのひな型プログラムとシステム構造情報とデータ属性オブジェクト情報からプログラムを自動生成する。生成されるのはソース・仕様書一体情報と呼ぶXMLタグで構造化されたソース・仕様書の一体情報である。保守ではソース・仕様書一体情報を更新するが、このとき従来の保守作業で仕様書とソースの乖離が起きてしまったようにソース・仕様書一体情報とシステム構造情報で乖離が生ずる恐れがある。そのため更新結果をシステム構造情報へ自動的に反映させる（リバースエンジニアリング）。それを実現するためにソース・仕様書一体情報を自動生成するときシステム構造情報をXMLタグを使って一体情報の中に書き込む。更新後、書き込んだタグ情報のシステム構造情報から、元情報のシステム構造情報を逆生成する。
【００１６】
５．発明が解決しようとする課題
１〜４を実現するため次の１０個の課題を設定する。このうち特許の請求項に直接関係するのは課題４〜８および課題１０である。
課題１．プログラムの単純化
課題２．プログラム・ビジネスフローの型化
課題３．システム構造情報の構成
課題４．システム構造情報とデータ属性オブジェクト情報とひな型プログラムからプログラム自動生成
課題５．ビジネスフロー単位の設計とプログラム一括生成
課題６．ソース・仕様書一体情報とリバースエンジニアリング    
課題７．組込み部品層による保守履歴管理
課題８．ノード情報、関係性情報によるバージョン管理
課題９．三階層構造情報による分り易いシステム体系、構造情報の表現
課題１０．課題４〜課題８を適用した新しいシステム開発方法
【課題を解決するための手段】
【００１７】
本特許請求は特定の言語や技術を前提にするものではないが、これから先具体的に分り易く説明するために、オブジェクト指向をベース技術と仮定して進める。
１．課題１「プログラムの単純化」の解決手段
（請求項対象外）
１．１．単一機能単位のプログラムへの分割（図８）
ホストコンピュータやC／Sシステムではプログラム中に多数の機能処理とワークデータ領域を持つ構造をとり、ステップ数が多くプログラムも複雑になる。それを例えばプログラムを機能の区切りで分割し、中間ワークデータ領域をｌｉｓｔデータオブジェクト（メモリ上のファイルオブジェクト）に切り出し、ｌｉｓｔデータオブジェクトは引数を介して引き渡せば、プログラムは単純になるうえｌｉｓｔデータオブジェクトへのアクセスは共有メソッドをそのまま使える。この構造は従来のプログラムとは処理が単一機能単位であり、ワーク領域の代わりにメモリ上のｌｉｓｔデータオブジェクトを使い、ｌｉｓｔデータオブジェクトを引数で受け渡す点で異なっている。またオブジェクト指向との比較で見れば、処理とデータを分離し、分離したデータにｌｉｓｔデータオブジェクトを使う点で異なる。
プログラムは小さく分割すればするほど再利用し易くなるが、新しい開発方法でのプログラムの分割は業務記述の範囲どまりで十分ある。それより細部の部品化はベース言語（たとえばオブジェクト指向言語等）に任せ、ユーザはただそれを利用する。肝腎なのはビジネスフローの全体構成とそれがプログラムの型でどう組み立てられるかだけだからである。
【００１８】
１．２．IO呼出の標準化
プログラムを自動生成し易くするためＤＡＯの生成の仕方を標準化する。例えばビジネスロジックとそこから起動される子プログラムのどちら側でＤＡＯを生成するかの問題がある。複数の子プログラム間で同じＤＡＯを使い廻す場合はビジネスロジック側で生成する方が効率良い。それ以外はどちらで生成しても構わないがビジネスロジック側でも子
プログラム側でも引数の数や引数の型を親子間で矛盾が起きないように合わせる必要がある。そのための情報はシステム構造情報の中に持つ。子プログラムの中ではＤＡＯのオブジェクト名を引数で渡される場合も含めｉｎ１、ｏｕ１のようにバッチのｄｄ名のように定めればメソッドの呼出しはin1.get,ou1．putのようにメソッド名を入れ替えるだけで使える。DAOの定義で予めメソッド名も引数も共通化できればそれらを入れ替える必要もないが、しかし引数まで含めて全て共通化はできないのでひな型は標準メソッドで記述し必要に応じて書き換える。またスコープに登録されたＤＡＯクラスは子プログラムでスコープから取り出すことにする。もし徹底的に標準化すればビジネスロジック側または子プログラム側のＤＡＯをソケットのように入れ替えるだけで済むが理想通りにはゆかない。
（注１）標準メソッド：標準メソッドは類似機能のメソッドや引数を統一化するために標準的に決めておくインターフェースの規則のひとつ。ＤＡＯクラスノード情報で標準メソッドに対応する個別メソッドを指定しておき、必要ならこれと書き換える。
【００１９】
２．課題２「プログラム・ビジネスフローの型化」の解決手段
（請求項対象外）
２．１．柔軟な型の効用
あるデータの平均値や分散等を複数のキー階層で集計する場合、ＳＱＬで処理するとなるとキー階層ごとに複数回実行するのでＩＯの処理効率が悪くなる。本来は１回で処理するのが望ましい。またもしデータを累積しつつ累積時点までの平均値や分散を使って演算するような場合も１回の集計処理で済ませたくなる。これらはまたいずれも一部だけ処理が異なるほとんど類似したプログラム構造をとる。こうした処理をゆるやかに一纏めにして同じ型に属する処理とみなして型化する。また単なる参照ファイルの数はいくらあっても同じ型とみなす。型のひな型には想定していない参照ファイルがシステム構造情報で指定されるとそのＤＡＯがプレ処理部に自動生成されるだけであり、自動生成後ソース・仕様書一体情報にその呼出し処理を書き込んで初めてＤＡＯが機能する。このような柔軟な型化は単一機能単位に分割してこそ可能になる。
ところでプログラムの内部構造はデータを同一の処理の平面まで取り出す制御部と同一の処理の平面上の業務処理部に分けられるが、実際には制御部と業務処理部は微妙に絡み合ってくる。それを厳密に分けるよりも制御部と業務部を最初から組合せた一体を型として扱う方が簡単である。必要ならひな型プログラムに出口を設けることも可能である。出口を設ける方法を徹底すれば、そこへ組込む部品だけを操作し、ソース・仕様書一体情報を直接修正する必要がなくなる。しかし一方ではひな型の柔軟性を削いでしまう恐れが多分にある。それゆえに柔らかさを優先させ、ソース・仕様書一体情報を自由に更新できる形をとる。
（注１）処理の平面：関連ファイルからデータをワーク領域に読み出して演算したり結果を書き出す場合、直接メモリ領域を使って演算する部分を処理の平面とし、処理の平面へデータを読み出したり、そこから書き出す部分を制御処理とする。
【００２０】
２．２．プログラムの型の例（図９，図１０）
バッチプログラムの処理はｌｏｏｐの繰返しかｌｏｏｐが無い条件判定付き実行文が大部分である。ｗｅｂプログラムの処理は正味の業務処理自体は一部に限られ、多くは正規形ＤＢ情報と非正規形画面情報とのデータ形式変換のような変換処理が多い。そこでｗｅｂ、バッチとも型の最初の分類基準を処理の平面までのデータを取り出すｌｏｏｐ制御の形で分ける。すなわちデータを取り出すループ制御処理の回数で、０層制御ループと１層制御ループと２層制御ループに分ける。ｌｏｏｐを使わずキーを使ったダイレクトアクセスを追加する場合は２．１で述べたように単に基本型からの派生に過ぎない。３層制御ループ以上については殆ど例がなく、仮にあっても２層＋1層のように分けて処理できる。この三種類の制御ｌｏｏｐの分類は更に次のような複数の機能別のパターンに分類できる。
【００２１】
２．２．１．１層制御ループ下の業務プログラムパターン例（図１１）
ｗｅｂで良く使われるパターンやバッチで頻繁に使われるパターンがある。例えばｗｅｂで多いデータ型変換パターンは、計画系の画面で、日付を軸に並べた非正規形データとＤＢ上の正規形データとを変換するために頻繁に使われる。これをＳＱＬだけで押し通そうとすればＵＮIOＮコマンドで見苦しくなり更新時には使えないなどの不便があるが、変換処理をパターン化すれば便利に使える。
１）ｗｅｂで多い業務プログラムパターン
・データ型変換パターン（正規系、非正規系変換）
・データ属性変換パターン
・データ部分分割パターン（部分データ抽出）
・データ複数分割パターン（複数ページ分割）
２）バッチで多い業務プログラムパターン
・データ項目選択パターン（データ項目の選択）
・集計・集約パターン（選択的、または全件のデータ集計、集約）
・データキー集約パターン（内部の複数のキー単位でデータ集計、集約）
【００２２】
２．２．２．２層制御ループ下の業務プログラムパターン例（図１２）
主としてバッチで頻繁に使われるパターンである。単なる参照キーを使ったダイレクトアクセス参照処理ではない。そのタイプの参照はいくつあっても型とは無関係である。
１）バッチで多い業務プログラムパターン
・キーマッチングパターン
・双方マッチング
・データ組合せ
【００２３】
２．２．３．０層制御ループ下の業務プログラムパターン例（図１３）
１）ｗｅｂで使われる業務プログラムパターン
ｗｅｂで極めて頻度が高く現れ、業務処理とは直接関係ないプログラムパターン（図１４）。しかしこのパターンは単なるオブジェクト指向のクラス部品としても使える。
・ＭｏｄｅｌＢｅａｎデータ整合性チェックパターン
・ファイル内キー存在チェックパターン
・セキュリテイチェックパターン
・ＪＰＡＥｎｔｉｔｙデータ設定パターン
（注１）ＭｏｄｅｌＢｅａｎとは画面層のフレームワークと業務層とのインターフェースとなるオブジェクト
（注２）ＪＰＡＥｎｔｉｔｙとはIO層のフレームワークと業務層とのインターフェースとなるオブジェクト
２）バッチで使われる業務プログラムパターン
・文字次列処理パターン
・構文分析・自然言語分析パターン
・特殊なレコード処理順序の係わるパターン（キー、タグ、ポインタの関係）
【００２４】
２．２．４．組込部品の例（図１５）
組込部品とは、プログラムの一部分であり、かつ課題４の解決手段で述べるような変換指示情報部とソースコード情報部を持ち部品のひな型として変換処理を受けるものである。扱い方は上記のパターンと実質同じ。これに対し、ｅｄｉｔｏｒを使ってソースの一部に直接組込み編集するソース部品は従来のｅｄｉｔｏｒの技術の範囲である。
１）生成呼出組込部品
他のクラスオブジェクト呼出やDAO呼出部品であり、特にオブジェクト指向技術やフレームワーク技術を部品中に隠蔽する役割も果たす。
・ＤＡＯ生成呼出組込部品
・クラスオブジェクト生成呼出組込部品
・スコープ呼出組込部品（ｗｅｂの場合）
２）ビジネスロジック組込部品
次の２．３で述べるビジネスロジックと同じ機能であるが、プログラムの中で制御の流れ部分を作る組込部品。
・  ビジネスロジック１型
・  ビジネスロジック２型
・  ビジネスロジック３型
【００２５】
２．３．ビジネスフローの型の例（図９、図１０）
ｗｅｂではデータチェックや属性変換、型変換などの定型的な機能のプログラムが同じ順番に並んでビジネスフローを形成する。バッチではｗｅｂのように決まった機能のプログラムが同じ順に並ぶことは少ないが、単位ビジネスフローがいくつか階層的に重なった構成をとることが多い。ｗｅｂでもバッチの単位ビジネスフローでもビジネスロジックとそれから起動される子プログラムのセットで構成する。
１）ビジネスロジックのパターン
子プログラムを連続的に起動するだけのビジネスロジック図１０は、多種多様なパターンが考えうるが、実際の例では呼出し処理が対称的に並ぶ単純なパターンが多い。大抵は次の３つのパターンと１層、２層の制御ｌｏｏｐパターンがビジネスロジックとして使われ組合せさることが多い。
（ａ）ビジネスロジック１型
単純にシリアルに子プログラムを呼出すパターン。呼び出すプログラムを無条件に縦列に繋げるタイプ
（ｂ）ビジネスロジック２型
シリアルに実行されるが処理の前に判定条件が入るパターン。１型と似ているが、判定条件に合致した場合のみ実行するタイプ
（ｃ）ビジネスロジック３型
複数の処理のそれぞれがｅｌｓｅｉｆで複数繋がった判定条件に合致したとき実行されるパターン
この他にも図９のパターンもビジネスロジックパターンとして使うことができる。
【００２６】
３．課題３「システム構造情報の構成」の解決手段
（請求項対象外）
システム構造をシステムやビジネスフローやクラスレベルで一括再利用するため、概念層、ビジネスフロー層、組込部品層の３階層のノード情報、関係性情報で構成する。
１）概念層のシステム構造情報例（図１６）
概念層はシステム最上位の括りで一括して取り扱うために使用され、システムやサブシステム、画面・ジョブのノード情報とそれを結びつける関係性情報を持ち、さらにビジネスフロー層との階層間関係性情報を持ち、下位層へ繋がるシステム体系を構成する。概念層にはプログラム処理やビジネスフローなどの実体がない。概念層のノード自体が再利用できる情報である。
（ａ）システムノード情報
システム、ノード種別、目的、コメント、付加情報
（ｂ）サブシステムノード情報
サブシステム、ノード種別、目的、コメント、付加情報
（ｃ）画面・ジョブノード情報
画面・ジョブ、ノード種別、目的、コメント、付加情報
（ｄ）ノード部品とノード部品の関係性情報
システムverNO、関係性種別、上位システムノード、下位システムノード
尚、図１６の６の画面・ジョブとビジネスフローの関係性情報が、８．１）２）で述べる階層間関係性情報である。
【００２７】
２）ビジネスフロー層のシステム構造情報例（図１７、図１８）
ビジネスフロー層は単位ビジネスフローを構成するビジネスロジックとクラスのノード情報、ＤＡＯクラスのノード情報とそれらの関係性情報、即ちビジネスロジックとクラスとの関係性情報、クラスとＤＡＯクラスとの関係性情報を持つ。なおノード情報、関係性情報に含まれる各ノード名には８で述べるノード個別バージョンも含まれるものとみなして省略する。
イ）ビジネスフローノード情報
ビジネスフロー、ノード種別、目的、コメント、ビジネスフローパターン
ロ）クラスノード情報（ビジネスロジックを含む）
クラス、ノード種別、メソッド、目的、コメント、プログラムパターン、パラメタ指示オブジェクト
（注１）業務層のメソッドはクラスでひとつ。従ってメソッド名＝クラス名で良い。
（注２）クラス名はソース・仕様書一体化情報とリンクする。
【００２８】
ハ）ＤＡＯクラスノード情報
ＤＡＯクラス、ノード種別、データ属性オブジェクト０、種類（ｌｉｓｔ，ＤＢ、クラス）、永久化ＤＢテーブル（最終接続ＤＢテーブル）、メソッド、標準メソッド、引数型、引数順序
（注３）データ属性オブジェクト０はデータ属性オブジェクト０情報とリンクする
（注４）メソッド、標準メソッドはメソッド単位にセットで持ち、さらに、引数型、引数順序はメソッドと標準メソッドごとの引数単位に持つ。標準メソッドはひな型プログラム中に記述される呼び出しメソッドで、メソッドと標準メソッドが異なっている場合はメソッドに置き換えられる。
（注５）ＤＡＯクラスの種類はＬｉｓｔデータオブジェクト、ＤＢテーブル、クラスオブジェクトの３種類としているが、勿論もっと多数の種類を扱う場合もある。
ニ）ビジネスフローとクラスの関係性情報
システムverNO、関係性種別、ビジネスフロー、クラス
ホ）クラスとＤＡＯクラスの関係性情報
システムverNO、関係性種別、クラス（親）、メソッド（親）、ｄｄ名、引数・スコープ、ＤＡＯクラス、データ属性オブジェクト
ヘ）プログラムパターンノード情報
プログラムパターン、ノード種別、目的、コメント、ｄｄ名、標準メソッド
ト）ビジネスロジックパターンノード情報
単なるプログラムのひとつとしてのビジネスロジックのパターンでプログラムパターンと実質同じもの。
プログラムパターン、ノード種別、目的、コメント
チ）ビジネスフローパターンノード情報
プログラムが繋がったビジネスフローのパターンでビジネスロジックパターンとは区別される。
ビジネスフローパターン、ノード種別、目的、コメント、ビジネスロジックパターン
（注６）ｄｄ名以下はクラス（親）から呼び出されるＤＡＯクラス毎に持つ。
（注７）ｄｄ名は仮オブジェクト名であり、バッチ処理のdd名ｉｎ１、ｉｎ２、・・、ｏｕ１、ｏｕ２、ｉｏ１、ｉｏ２のように識別する。
（注８）データ属性オブジェクト情報はＤＡＯクラスノード情報のデータ属性オブジェクト０情報に仮名２、変換式タイプ２、インデックス２が加わったもの。
（注９）データ属性オブジェクト情報はクラスとオブジェクトの関係性情報内のデータ属性オブジェクトとリンクする
ヘ）クラスとクラスの関係性情報
システムverNO、関係性種別、クラス（親）、メソッド（親）、クラス（子）、メソッド（子）、呼出順序
（注１０）呼出順序はクラス（親）がビジネスロジックでありそれが生成される場合のみ使われる。
【００２９】
３）ビジネスフロー層のデータの参照関係（図１９）
イ）ノード情報同士が関係性情報によってつながれている。
ロ）ノード情報はシステム間で共有される。また関係性情報は必ずシステムverNOを持ち、同じシステムverNOを持つ関係性情報で結びつけられたノード情報でシステムの体系を構成する。
４）組込部品層のシステム構造情報例（図２１）
組込部品層はクラスの内部構造情報でセクション（プレ処理、主処理、ポスト処理）やクローズなどの構造化要素の構成と、それらの要素から呼出す下位のクラス、ＤＡＯとの関係を表現したもの。ビジネスフロー層はプログラムを自動生成するための元情報であるのに対し、組込部品層は逆に自動生成されたプログラムから生成される。
イ）組込部品ノード情報
組込部品、ノード種別、種類（セクション、クローズ、ＤＡＯ呼出、子クラス呼出）、更新履歴
ロ）クラスと組込部品、組込部品と組込部品の関係性情報
関係性種別、クラス、メソッド、組込部品
関係性種別、クラス、組込部品、組込部品
（注１）組込部品層では更新履歴が書き込まれるので組込部品は他のクラスから共有されることはなくクラスと一体で構成される。従ってシステムverNOは使わない。
【００３０】
５）ＤＡＯ生成時に渡されるシステム構造情報例（図１７の３）
システム構造情報の中にはIO層開発段階のDAO生成時点に作成される情報がある。それはＤＡＯクラスノード情報でDAOが最終的にアクセスする永久化DBテーブルやDAOを呼び出すときのメソッドと標準メソッド、その引数情報を持つ。
イ）ＤＡＯクラスノード情報
ＤＡＯクラス、ノード種別、データ属性オブジェクト０、種類（ｌｉｓｔ，ＤＢ、クラス）、永久化ＤＢテーブル（最終接続ＤＢテーブル）、メソッド、標準メソッド、引数型、引数順序
【００３１】
６）システム構造情報からリンクされる情報
システム構造情報には含まれないが、システム構造情報の名前からリンクされる情報として次のものがある。
イ）ひな型プログラム          クラスノード情報、またはプログラムパターンノード情報のプログラムパターンからリンク
ロ）データ属性オブジェクト０情報    ＤＡＯクラスノード情報のデータ属性オブジェクト０（語尾に情報がない）からリンク
ハ）データ属性オブジェクト情報  クラスとＤＡＯクラスの関係性情報のデータ属性オブジェクト（語尾に情報がない）からリンク
ニ）パラメタ指定オブジェクト  クラスノード情報からリンク
ホ）ソース・仕様書一体情報      クラスノード情報のクラスからリンク
【００３２】
４．課題４「システム構造情報とデータ属性オブジェクト情報とひな型プログラムからプログラム自動生成」の解決手段
（請求項２に対応）
システム構造情報と入出力データ属性オブジェクト情報からひな型プログラムをデータ属性オブジェクト情報のデータ項目に対して弾力的に変換してソース・仕様書一体情報を自動生成する。
最初に従来のプログラム再利用の方法と新しい方法とを比較する。従来の方法を図２２の左側の１〜３で示す。１はプログラムのｅｄｉｔｏｒの機能のひとつで、ソースプログラム形式の再利用可能な組込部品を用意し、ソース編集の過程で再利用するタイプである。２は通常はプログラムのひな型を用意し、ひな型にｅｄｉｔｏｒ型の組込部品を組込んで仕様書をソースと一体で使用するタイプである。３はオブジェクト指向で代表される方法で、部品が組込部品ではなく独立部品（プログラム）であり、独立部品を継承機能を使って再利用するタイプである。これに対し４が新しい方法であり、システム構造情報やデータ属性オブジェクト情報を使うことでひな型から柔軟にソース・仕様書一体情報を自動生成し、また組込部品についても同様に部品のひな型と組込む先のクラスのシステム構造情報やデータ属性オブジェクト情報を使って生成する方法である。入出力データの違いを吸収する柔軟性に一番の特徴がある。
【００３３】
次に具体的な手段であるが、ビジネスロジックの生成方法はビジネスフロー単位の一括生成と密接に係わるので課題５で扱い、ここではビジネスロジックから呼出される子プログラムの生成法について述べる。図２３で示すように、ひな型プログラムの書き換えは（ａ）プログラム呼出のインターフェース引数部分、（ｂ）ＤＡＯ生成と呼出部分、（ｃ）データ転送変換部分である。（ｃ）のデータ転送変換部分では、ひな型に折り畳まれた変換式を入出力データ属性オブジェクト情報を作用させて再び展げてやる。（ａ）（ｂ）の部分はシステム構造情報を使う変換であり４．６で説明する。
【００３４】
４．１．データ転送変換部のソース変換方法の概要（図２４）
データ転送変換はひな型ソースプログラムの左辺データ項目＝変換式ｆ（右辺データ項目）のような変換式を、データ属性オブジェクト情報の中の同じ変換式タイプのデータ項目の数だけ繰返し展開する。このとき右辺、左辺とは入力データ項目やワーク領域や出力データ項目である。ひな型の変換式はひとつまたは複数の式のセットで表現し、変換式に記述するデータ項目名は、変換式タイプとインデクスを合成した仮名（ひな型ソース中では記号[[ ]]で括る）で記述する。これをソースへ変換するときは次の二つの手順を踏む。
１）最初にひな型の変換指示情報部の参照dd名で指定されたデータ属性オブジェクト情報からひな型の変換対象行と同じ変換式タイプのデータ項目の数を探しそれを変換式の繰返し生成数とする。変換式を繰返し生成数だけメモリ上に展開するとき、式中のインデクスを１，２、・・のように変えてインデックスおよびインデックス付きの仮名にバリエーションをつけることができる。
変換式タイプはデータ属性オブジェクト情報での設定を簡単にするために標準と個別の２種類に分ける。標準タイプとはデータ項目から変換式タイプを決めてしまえるもので（ａ）日付従量項目変換式タイプと（ｂ）独立項目変換式タイプとがある。このタイプはデータ属性オブジェクト情報を生成する時に決めることができる。一方個別変換式タイプは処理パターンによって変化し（ｅ）ｋｅｙ項目変換式タイプがその代表例である。これはたとえばｋｅｙマッチングで別ファイルから指定のデータ項目を参照する場合などに使われるが、マッチングするｋｅｙと参照されるデータ項目をプログラムパターンごとに指定しなければならない。従って５．４のようにビジネスフローの中間データ属性オブジェクト情報を一括生成する場合でも、（ａ）（ｂ）のタイプは自動設定が可能であるが、（ｅ）のタイプはそれが必要な場合個別に設定する。尚変換式タイプは必要に応じて増やせる。
【００３５】
（標準変換式タイプ）
（ａ）日付従量項目変換式タイプ（ｉｄｘ）
日付をインデックスと対応づけた仮名やインデクスを変換式に含み、通常日付に従って変換式が繰り返し生成される変換式タイプ
（ｂ）独立項目変換式タイプ（ｘ）
日付従量項目変換式タイプ以外のもっとも単純な変換式タイプ
（ｃ）ＤＡＯ生成部変換式タイプ（ｗ）
データ転送部ではなくＤＡＯ生成部で使われる。これとほとんど類似した変換ロジックを適用するビジネスロジック変換式タイプと区別するための変換式タイプ
（ｄ）ビジネスロジック変換式タイプ（ｙ）
データ転送部ではないビジネスロジックのクラス生成部で使われる。ほとんど類似した変換ロジックを適用するＤＡＯ生成部変換式タイプと区別するための変換式タイプ
（個別変換式タイプ）
（ｅ）ｋｅｙ項目変換式タイプ（ｋｅｙ）
ｋｅｙマッチングのための複合ｋｅｙを作るタイプの変換式タイプ
２）同じ変換式タイプのひな型セット行をメモリ上に繰り返し生成数だけ展開した後で、記号[[ ]]で括られたインデクス付の仮名を再びデータ属性テーブルから探し、置換データ項目で置き換える。
（注１）（ｃ）（ｄ）の変換式タイプはデータ属性オブジェクト情報の中では使わない。
【００３６】
４．２．ひな型プログラムの構造
ひな型プログラム例を図２６に示す。ひな型プログラムはプログラムパターンノード情報またはクラスノード情報のプログラムパターンからリンクされる。
ひな型プログラムはソースコード情報部と変換指示情報部で構成する。ソースコード情報部はソースプログラムに近い形であるが、次のような仕方で作成する。
（ａ）同種の変換式タイプの変換式はインデックスを使ってひとつ、または１セット行に折り畳む
（ｂ）変換するデータ項目は変換式タイプとインデックスを合成した仮名で記述したうえで記号[[ ]]で括る
（ｃ）逆に変換式を繰り返し数だけ展開するとき式中のインデックスを使って変換式にバリエーションをつけることができる
（ｄ）ひな型の変換個所をプログラムで容易に特定できるようにひな型中の変換式の仮名やインデックスは記号[[ ]]で囲む
（ｅ）ひな型プログラムを適切に改行して変換指示情報部の参照ｄｄ名が重複しないようにする。
また各行の変換指示情報部では（ｉ１）変換時に参照するデータ属性オブジェクト情報を参照ｄｄ名で指定、（ｉ２）標準と個別の変換式タイプ（単一の変換式かセットの変換式か、セットならばその行範囲）を分けて指定（ｉ３）変換式以外の各種変換指示コードを指定する。各種変換指示コードは任意に追加できるが例えば次のような種類がある。
・文字列置換  ＊：記号[[ ]]で囲まれた仮名をデータ属性オブジェクト情報から変換
・パラメタ指定項目置換  ｐ：パラメタ指定オブジェクトの設定値を置換
・ＤＡＯ生成部、ビジネスロジック生成時の各種変換指示コード（ｓ１，ａｒ，ｄｂ，ｄ１，ｒ１等）
【００３７】
４．３．データ属性オブジェクト情報の構造（図２５）
データ属性オブジェクト情報は、データ項目名とデータ属性と標準変換式タイプの仮名１、変換式タイプ１、インデクス１と、個別変換式タイプの仮名２、変換式タイプ２、インデックス２を持つ。仮名は変換式タイプとインデックスの単純組合せである。標準変換式タイプは独立項目変換タイプ、日付従量項目変換タイプ、日付項目のいずれかであり、データ属性オブジェクト情報作成と同時に設定する。個別変換式タイプは個別のプログラムパターンごとに必要な場合のみ後から追加設定する項目で、ｋｅｙ項目変換タイプ等がある。またデータ属性オブジェクトにはビジネスフロー層のＤＡＯクラスノード情報のデータ属性オブジェクト０からリンクされるデータ属性オブジェクト０情報とクラスとＤＡＯクラスの関係情報からリンクされるデータ属性オブジェクト情報がある。わざわざ２種類のデータ属性オブジェクト情報を持つ理由は、もし同じデータ属性オブジェクト情報を異なるプログラムパターンに適用した場合、個別変換式タイプをプログラムパターンに対して別に設定する必要がある場合が起きるからである。
（ａ）変換式タイプ  独立項目変換式タイプ      ｘ
日付従量項目変換式タイプ  ｉｄｘ
（日付項目）              ｄate
ｋｅｙ項目変換式タイプ    ｋｅｙ
（参照項目）              ｒｆ１，ｒｆ２，
（ｂ）インデックス  連続繰返し項目    １,２,・・・
（注１）日付従量項目変換式タイプ日付項目  正規形データで日付そのものを入れる項目
（注２）ｋｅｙ項目変換式タイプ参照項目  ｋｅｙマッチングした時、データ属性オブジェクト情報から参照する項目あるいは参照される項目
【００３８】
４．４．その他必要な補助情報    パラメタ指定オブジェクト
もしひな型プログラムの変換で補助情報が必要であれば、それをパラメタ指定オブジェクトとして与える。例えばデレクトリパスをパラメタで与えたり、ｗｅｂの計画系の画面で何件分のデータをページング画面として表示させるか等の指示情報をパラメタとして与える。パラメタ指定オブジェクト中でparam1=xx,param2=yyのように指定したパラメタ値が、ひな型プログラムの中の該当パラメタと置き換えられる。パラメタデータ指定オブジェクトはクラスノード情報からリンクされる。
【００３９】
４．５．データ転送変換部のプログラム自動生成ロジック
４．５．１．プログラム自動生成で使う情報
（ａ）プログラムパターンのひな型プログラム（（ｂ）からリンクされる）
（ｂ）ビジネスフロー層システム構造情報のクラスノード情報
（ｃ）ビジネスフロー層システム構造情報のクラスとＤＡＯクラスの関係性情報
（ｄ）（ｃ）からリンクされるデータ属性オブジェクト情報
（ｅ）必要ならばパラメタ指定オブジェクト（（ｂ）からリンクされる）
（ｆ）その他システム構造情報
【００４０】
４．５．２．データ転送変換部の変換方法の詳細  処理フローは図３０、図３１
（図３０の左のフロー）
１）生成対象クラスのビジネスフロー層システム構造情報を読む
２）システム構造情報のクラスとＤＡＯクラスの関係性情報の参照ｄｄ名で指定されたデータ属性オブジェクト情報を読む（複数ありうる）
３）システム構造情報のクラスノード情報からパラメタ指定オブジェクトを読む
４）システム構造情報のクラスノード情報のプログラムパターンからひな型プログラムを読み、一時的ひな型プログラムへ保存
５）ＰＧ生成処理を呼出す
【００４１】
（図３０の右のフロー：ＰＧ生成処理）
（１）一時的ひな型プログラムの行を順次読出し、変換指示情報部の変換式パターンをキーとして同じキーのものをキーが切れるまで繰り返し読み出し抽出ひな型オブジェクトへ保存
（２）キーが切れたら抽出ひな型オブジェクトを渡してデータ項目群処理を実行
（３）これを一時的ひな型プログラムを読み終えるまで繰り返す
（図３１の縦方向の流れ：データ項目群処理）
（１）ひな型のＰパラメタ行をパラメタ指定オブジェクトの指定値と置換え
（２）変換式タイプごとの変換処理を実行
（３）その他の文字列置換処理の実行
（４）生成されたプログラムをクラスＰＧへ出力．変換指示情報部は削除しソースコード情報部のみ出力する
（５）抽出ひな型プログラムを削除
【００４２】
（図３１の横方向の流れ：変換式タイプごとの変換処理）
抽出ひな型プログラムを１行づつ順次読み、変換指示情報部の参照ｄｄ名で指定されたデータ属性オブジェクト情報を参照し同じ変換式パターンの繰り返し数を決め、変換式の行セットを繰り返し数だけ生成する時に記号[[ ]]で囲まれたインデクスの変換を行い、次に記号[[ ]]で囲まれた仮名を再び参照先のデータ属性オブジェクト情報から読み出し置換する。
この処理を更に詳しく説明する。
（１）ひな型の変換指示情報部にひな形の１行または行セットを繰り返し生成する変換式タイプ（仮にｉｄｘとする）と文字列変換記号（＊）があるとする。この時は繰り返し生成指示を優先し参照ｄｄ名で指定されたデータ属性オブジェクト情報から変換式タイプが同じデータ項目数ｎを読出し、そのデータ項目数ｎ個分だけ変換式（行またはセット）を繰り返し生成する。そのとき変換式中に記号［［  ］］で括られたインデックス（例えば［［ｉｄｘ［［ｉ］］］］があればそれを重複がないように、［［ｉｄｘ１］］，［［ｉｄｘ２］］、・・、［［ｉｄｘｎ］］のようにシリアルにインクリメントし展開する。変数としてのインデクスも同様である（例えば［［ｉ］］があればそれを１，２、・・、ｎのように展開）。
（２）次にデータ属性オブジェクト情報から変換式パターンとインデクスがｉｄｘｎ（ｎ＝１〜ｎ）と等しいｎ個の仮名を読出し、そのｎ個の置換データ項目名と仮名とを置き換える。
【００４３】
４．６．ひな型のインターフェース引数部分、ＤＡＯ生成、呼出部分の書き換え
４．６．１．プログラム自動生成で使う情報
４．５．１の情報に加えて次の情報が必要
（ａ）ＤＡＯ生成時に渡される構造情報（ＤＡＯクラスノード情報）（図１７の３参照）
４．６．２．ひな型のインターフェース引数部分の書き換え
ビジネスロジックから呼び出される子クラス側の引数部分を作る。そのとき子クラス側で呼び出すＤＡＯクラスオブジェクトの一部は子クラス側へ引数を通して渡すことがある。子クラスで使う全てのＤＡＯはビジネスフロー層のクラスとＤＡＯクラスの関係性情報ｄに設定されるが、その中で引数・スコープ項目に引数と指定されているＤＡＯクラスのみが引数で渡される。引数の形はクラスノード情報の引数構成情報ｃのようになる。引数渡しのＤＡＯクラスが複数ある場合はクラスノード情報の引数構成情報を複数作成する。ｄからｃへの変換は次のように行う。
１）ｃのクラスとメソッドはｄそのままである
２）ｃの引数型はクラスとＤＡＯクラスの関係性情報ｄのデータ属性オブジェクトからリンクされるデータ属性オブジェクト情報を内容にもつデータクラスとする。そのデータクラスは生成対象クラスにｉｍｐｏｒｔされるか、クラス定義される。
３）ｃの引数順序は引数の並び順であり、複数のｄｄ名のアルファベット昇順とかの規約を作っておき、それに従う。
４）ＤＡＯ以外の引数を渡すため所定の形式のＤＡＯクラスをひとつ決めておく
【００４４】
４．６．３．ひな型のＤＡＯ生成部分の書き換え
ビジネスフロー層のクラスとＤＡＯクラスの関係性情報ｄの中で設定されかつ引数を介さないオブジェクトはそのクラスの内部で生成するかもしくはスコープから取り出す。ひな型のプレ処理部分にはオブジェクトひとつ当りにそれを子プログラムで生成する場合、スコープから取り出す場合等すべてのケースの行セットを用意しておき、変換時にクラスとＤＡＯクラスの関係性情報ｄがそれに該当するケースの行セットみを残して他の行セットは削除する。クラスとＤＡＯクラスの関係性情報ｄの全てのオブジェクトについてそれを繰り返す。この部分の生成ロジックは５．５．２〜５．５．３のビジネスロジックの生成と同じ考え方であるので詳細説明は省略する（処理フローは図３９〜図４２：ｗタイプの変換式の場合になる）。但しＤＡＯの生成とビジネスロジックの生成では同じクラスとＤＡＯクラスの関係性情報ｄを参照するがオブジェクトの生成条件が反対になる。
【００４５】
４．６．４．ひな型のＤＡＯ呼出部分の書き換え
ひな型プログラムではＤＡＯクラスオブジェクト名をｉｎ１、ｏｕ１のようにバッチのｄｄ名のように決めるとメソッドの呼出しはin1.get,ou1．putのようにメソッド名を入れ替えるだけで済む。更にＤＡＯ生成時、ＤＡＯのメソッド名もその引数も予めできるだけ共通化しておけばメソッド名を入れ替える必要もない。この場合はＤＡＯの生成部をソケットのように入れ替えるだけで済む。しかし全て統一することはできないので、実際にはひな型にはプログラムパターンノード情報の標準メソッド名で記述しておいて置き換えが必要な場合のみ標準メソッド名と引数をＤＡＯクラスノード情報ｅのメソッド名と引数に置き換える（ＤＡＯクラスノード情報ｅのメソッド名と標準メソッド名が異なる場合は入れ替えが必要）。ＤＡＯクラスノード情報ｅはＤＡＯの生成時に既に作成されているシステム構造情報である。またこの書き換えは４．５．データ転送変換部の置き換え行と重なりあうことがあっても変換内容が異なるので問題はない。
【００４６】
４．７．このプログラム自動生成方法の柔軟性
ひな型プログラムと入出力データ属性オブジェクト情報とシステム構造情報を利用したこの自動生成方法は、基本的にはひな型の行単位に変換を掛ける方法なので組込部品のようにプログラムの一部分であっても全く同様に適用できる。またここで生成するクラスはデータと処理を切り離した形を前提にしているが、データと処理が一体構造の普通のオブジェクト構造に対しても同じ考え方が適用できる。ｌｉｓｔデータオブジェクトとして外に切り出したデータ属性オブジェクト情報のひとつをオブジェクトの内部で保有する形に変え、かつ複数メソッドを持てるようにするだけであり、オブジェクトの構成要素は変わらずにその配置だけが変わるだけだからである。そのためにはシステム構造情報もひな型も少し変える必要があるが、考え方の基本は同じである。
【００４７】
５．課題５「ビジネスフロー単位の設計とプログラム一括生成」の解決手段
（請求項３に対応）
システム概念層のサブシステムの設計ではユースケース図が描かれ、そこで画面から永久化データを生成したりまたは永久化データから帳票を生成するブジネスフローが決められる（図３３）。ビジネスフローの設計では、ひとつのビジネスフローをいくつかの単位ビジネスフローで切り出してゆく。単位ビジネスフローとはひとつのビジネスロジックとそれから起動される複数のプログラムのセットである。ビジネスロジックは処理内容ではなく処理の形に制御の型を当て嵌めて括り出す。またビジネスロジックは単純にプログラム呼出を制御する流れとし、処理と制御をできるだけプログラムとビジネスロジックで分担させるようにする。基本ビジネスフローをいくつか組合わす場合でも、制御部分はなるべくビジネスロジックだけの組合せにする。
【００４８】
５．１．ｗｅｂとバッチのビジネスフローの違い
ｗｅｂのビジネスフローは図３４の最下段で示すように単位ビジネスフローで構成されかつある特定のパターンのプログラムが決まった順番に並ぶ傾向がある。ビジネスフローの構成自体がどれも類似し大抵はビジネスフローの機能を代表する１つのプログラムだけが入れ換わるパターンである。一方バッチでは図３に示すように単位ビジネスフローが階層をなす、あるいはビジネスロジックが複数組み合わさることが多い。単位ビジネスフローの構成はｗｅｂの場合と変わらないが、決まったパターンのプログラムが決まった順に並ぶことはない。ｗｅｂの場合は限られたビジネスフローの型を用意して、それを再利用することで効率が上げられるが、バッチの場合はビジネスロジックの型を組み合せてビジネスフローの多様性を出す。
【００４９】
５．２．ビジネスフロー単位の設計の具体例
５．２．１．ｗｅｂのビジネスフローの具体例
図６１はある物流在庫システムの概念層とビジネスフローの構成例で、その中の二つのビジネスフローを図６２に、また図６３には生産計画システムのあるビジネスフローを示している。この三つのビジネスロジックの型は全て同じビジネスロジック１だけであり、その中の構成プログラムの型（パターン）も同じものが並ぶことが分る。
５．２．２．バッチビジネスフローの具体例
図３２は４．５．２で説明したデータ転送変換部の変換方法のプログラムフロー（図３０、図３１）の型構成を示したものである。図３０のビジネスロジックの型はビジネスロジック１と１層制御ループ下の業務プログラムパターン（P108）との組合せであり、図３１のビジネスロジックの型はビジネスロジック１とビジネスロジック３の組合せである。また図３９〜図４１のプログラムフローも図３０、図３１の構成と同じである。一見難しそうに見えるバッチ処理も柔軟な型を当て嵌めると非常に単純に捉えられることが分る。
【００５０】
５．３．ビジネスフロー層システム構造情報の設計
ビジネスフローを設計するとき上位の単位ビジネスフローから下位の単位ビジネスフローへと順次詳細化する。更に単位ビジネスフローをビジネスロジックと子プログラムの型の組合せへと落とし、システム構造情報ができた時点で単位ビジネスフロー単位で一括してプログラムを自動生成する。その手順は図３４に示すように次のようになる。
１）ビジネスフローを設計しビジネスフロー層システム構造情報作成（５．３で説明）
２）中間データ属性オブジェクト情報の一括生成（５．４で説明）
３）ビジネスロジックの自動生成（５．５で説明）
４）ビジネスロジックから呼び出される子プログラムを一括自動生成（５．６で説明）
【００５１】
５．３．１．ビジネスフロー層システム構造情報の設計で決まるデータ項目
単位ビジネスフロー中の次のシステム構造情報を決める。
（ａ）ビジネスフローノード    ビジネスフロー、ビジネスフローパターン
（ｂ）クラスノード    クラス、メソッド、プログラムパターン、引数型、引数順序
（ｃ）ＤＡＯクラスノード    ＤＡＯクラス、データ属性オブジェクト０、種類（ｌｉｓｔ，ＤＢ、クラス）、永久化ＤＢテーブル（最終接続ＤＢテーブル）、メソッド、標準メソッド、引数型、引数順序
（ｄ）ビジネスフローとクラスの関係性    ビジネスフロー、ビジネスロジック
（ｅ）クラスとデータ属性オブジェクトの関係性    クラス、メソッド、ｄｄ名、引数・スコープ、ＤＡＯクラス、データ属性オブジェクト
（ｆ）クラスとクラスの関係性    クラス、メソッド、接続手段、クラス、呼出順序
【００５２】
５．３．２．ビジネスフローパターンを再利用せず新たにシステム構造情報を設定する場合
１）単純な処理フローとプログラムパターンの標準構成を生かした設定
既存のシステム構造情報を再利用せずに図１９のようなシステム構造情報を新たに生成するについて、２）のような命名規約を適用しかつプログラムパターンの標準構成を利用してプログラムを使って効率的に作成できるようにする。次の手順で図１９のノード情報や関係性情報を作業領域のフレームに生成しながら、画面から必要データを入力しフレームを作り込んでゆく。
（１）最初にビジネスフロー名と生成クラス数を与えるとビジネスフローノード情報ａのフレームをひとつ、ビジネスフローとクラスの関係性情報ｂのフレームをひとつ、ビジネスロジックのクラスノード情報ｃのフレームをひとつ、子クラスノード情報ｃのフレームを生成クラス数だけ作業領域に自動生成し、たとえば２）の命名規約を適用する。
（２）それと同時にクラス（ビジネスロジック）とクラスの関係性情報ｆのフレームを生成クラス数自動生成し、ビジネスロジックとクラスの呼出し関係を画面から設定。
（３）画面から子クラスノード情報ｃにプログラムパターンを指定すると、クラスとＤＡＯクラスの関係性情報ｄのフレームを図１８のプログラムパターン情報のｄｄ名の数だけ自動生成し、同時にＤＡＯクラスノード情報ｅのフレームもｄｄ名の数だけ自動生成し、（１）と同様に２）の命名規約を適用する。ｄｄ名はプログラムパターン情報のｄｄ名（ｉｎ１，ｏｕ１等）に設定。
（４）画面からＤＡＯクラスのクラス間の引数渡しによる使い廻しがある場合、対象となるクラスとＤＡＯクラスの関係性情報ｄのＤＡＯクラスとデータ属性オブジェクトの名前を同じ名前に揃え、不要なＤＡＯクラスノード情報ｅは削除する。
（５）おなじく画面からクラスとＤＡＯクラスの関係性情報ｄの引数・スコープを設定する。そのスコープ・引数項目で該当クラスがＤＡＯクラスを引数渡しするか判断し、引数渡しの場合、クラスノード情報ｃのフレームに引数型、引数順序を次のルールで自動設定する。
引数渡しのＤＡＯクラスが複数ある場合はクラスノード情報ｃのフレームを複数作成する。
（ｉ）引数型はクラスとＤＡＯクラスの関係性情報ｄのデータ属性オブジェクトからリンクされるデータ属性オブジェクト情報を内容にもつデータクラスとする。そのデータクラスは生成対象クラスにｉｍｐｏｒｔされるか、クラス定義される。
（ｉｉ）引数順序は引数の並び順であり、複数のｄｄ名のアルファベット昇順とかの規約を作っておき、それに従う。
（６）まだ埋められていない次の項目を設定する。
・ビジネスロジックノード情報ｃのビジネスロジックパターン
・クラス（ビジネスロジック）ノード情報ｃのパラメタ指示オブジェクト
・クラス（ビジネスロジック）とクラスの関係性情報ｆの呼出順序   
（７）もしプログラムパターンで標準に持つｄｄ名の数以上のクラスとＤＡＯクラスの関係性情報ｄとＤＡＯクラスノード情報ｅのフレームを追加したい場合はここで行う。勿論自動生成後に追加しても良い。
（８）全ての入力が済んだら、システムverNOを新規につけ、作業領域をシステム構造情報に移す。
注１）フレームとは図１７、図１８のようなノード情報、関係性情報のセットを容れる作業領域のデータの箱
【００５３】
２）名前付けのルール化
プログラムでビジネスフロー、ビジネスロジック、クラス、メソッド、ＤＡＯクラス、データ属性オブジェクトなどの名前を自動的に付けるためには、例えばビジネスロジックはビジネスフロー＋１、２、３等のように追番を付加して良いし、業務層のクラスは１クラス１メソッドなのでクラス名＝メソッド名でよい（大文字、小文字で区別するが）。ビジネスフローの中間のクラス、メソッド、中間データ属性オブジェクト等は本来的にワーク的なものとしてひとつの流れを形成するので、追番を変えて繋げて良い。例えばビジネスフローをａとするとビジネスロジックはａ０，そこから起動されるクラスとメソッドは起動順にａ１，ａ２，ａ３，・・のように名付ける。ＤＡＯクラスとデータ属性オブジェクトの名前も、ａ１ｉｎ１，ａ１ｏｕ１，ａ２ｉｎ１，ａ２ｏｕ１，・・のように決めることができる。このような名前付けルールをプログラム化しておく。但しＤＢテーブルのデータ属性オブジェクトに関してはＩＯ層設計時に決めておく。
【００５４】
５．３．３．ビジネスフローパターンを再利用したシステム構造情報の作成（新規作成、新バージョン作成）
ビジネスロジックとそれから起動される一連の子プログラムをシステム構造情報に予め単位ビジネスフローのパターンとして登録しておき、それを利用して新たなビジネスフロー、または新バージョンのビジネスフローを作成できる。
１）すでに登録してあるビジネスフローパターンのシステム構造情報を作業領域のフレームへ一括コピー。５．３．１の場合と異なり全てのフレームはビジネスフローパターンの情報で既に埋められている。その名前（ビジネスフロー名、ビジネスロジック名、変更するクラス名とクラスのノード情報など）を必要な個所だけ変えてゆく。
２）プログラムの追加、削除等のクラスノード情報の追加・削除またはクラス（ビジネスロジック）とクラスの関係性情報の追加・削除がある場合はまずフレーム自体を先に追加・削除する。
３）全てのフレームの更新が終わったら作業領域をシステム構造情報へ戻す。そのときシステム構造情報の現バージョンの情報が直接削除されたり更新されることはない。またノード情報は共有されるので同じノード情報であればシステム構造情報へ追加する必要がない。関係性情報は更新の度にシステムverNOが変わるので必ず新規に追加される。
【００５５】
５．４．中間データ属性オブジェクト情報の生成
ビジネスフローの中間データ属性オブジェクト情報を作成する手間を省くために、ビジネスフローの先頭にひとつデータ属性オブジェクト情報を与えると、後に続く中間のデータ属性オブジェクト情報はその直前のデータ属性オブジェクト情報とプログラムのプログラムパターンから順次自動生成するようにする（図４３）。
【００５６】
ホストやC／Sシステムの時代ではビジネスフロー数本分を一本のプログラムに記述した。ここではビジネスフローを単一機能の複数のプログラムに分割し、中間のワーク領域はｌｉｓｔデータオブジェクトとして切り出す形にした。中間のワーク領域が見える形になった分、一見扱うデータが増えたように見えるが、実際には見えなかったワーク領域が見えるようになっただけで増えたわけではない。それはオブジェクト指向でも同じで永久化データへアクセスするSQLやDAOメソッドだけで業務処理が完結する訳ではなく、オブジェクトとしてどこかでこの中間的な性格の領域は保持される。この中間のデータ属性オブジェクト情報を設定する負荷を軽減する。
【００５７】
１）プログラムで自動設定できる標準変換式タイプの設定
クラスの入出力データには変換式タイプに応じた対応関係があり、プログラムパターンと変換式タイプごとにINとOUTのデータ属性オブジェクト情報の対応関係をルールづけることができる。対応関係とはデータ項目名、属性、仮名、変換式タイプ、インデックスのことである。対応関係をオブジェクト属性テーブルの生成時に決定できてしまう標準タイプ（仮名１、変換式タイプ１、インデックス１）とそうでない個別タイプ（仮名２、変換式タイプ２、インデックス２）に分ける。標準には独立項目変換式タイプと日付従量項目変換式タイプが含まれ、個別にはｋｅｙ項目変換式タイプが含まれる。この標準の設定だけで済む場合も多い。
【００５８】
例えば図４４のプログラムパターンではINとOUTのデータ属性オブジェクト情報で次のような対応関係がある。
（ａ）独立項目はデータ項目名も属性も仮名も変換式タイプもインデックスも変わらない。
（ｂ）日付従量項目はデータ項目名も属性も仮名も変換式タイプも変わらないが、インデックスの個数のみパラメタ指定オブジェクトで与える数値（７）に変わる（３１−＞７）。
（ｃ）key項目はデータ項目名も仮名も属性も仮名も変換式タイプもインデックスも変わらない。
この変換式タイプでは個別のkey項目変換式タイプでも自動生成が可能である。これを図４５の表のようにプログラムパターン、変換式タイプごとにルール化すればそれをプログラム化できる。
ところで図４５のデータ属性オブジェクト情報の生成フローの中で、同一プログラムのＩＮからＯＵＴへ生成する場合と、異なるプログラムのＯＵＴからＩＮへ同じデータ属性オブジェクト情報を引き渡す場合とがある。後者の場合でも標準タイプは無条件にコピーできるので、結果的には前者の場合の個別タイプのＩＮ、ＯＵＴの設定だけで充分である。
【００５９】
２）人の介在が必要な個別変換式タイプの設定
標準タイプ以外に更に個別タイプを設定する必要がある場合は個別に追加指定する。ｗｅｂのビジネスフローはほとんどが定型的なプログラムパターンで構成され、中間データ属性オブジェクト情報もビジネスフロー単位に一括自動生成できることが多い。しかしバッチの場合は、固有処理で必ずしもINとOUTの対応関係を図４５の表のように関連づけて生成できないプログラムパターンが中には出てくる。そのようなプログラムパターンの対応関係は人が判断して繋げるほかない。人の判断を助けるため図４５の表には各プログラムパターンで指定が必要になる変換式タイプを中間データ属性オブジェクト情報ごとに対応させて明示する。
【００６０】
５．５．ビジネスロジックの自動生成
ビジネスロジックから起動する子クラスのクラスノード情報とビジネスロジックとクラスの関係性情報はビジネスロジックを自動生成する前にシステム構造情に登録されている必要がある。
次にビジネスロジックの生成方法について述べる。
【００６１】
５．５．１．ビジネスロジック１，２，３の内部の処理の流れ（図３８）
ビジネスロジックとクラスの関係性情報を参照して起動する子クラスが複数ある場合、２）〜４）が複数回繰り返される。
１）DBを使用する場合、DBコネクト
２）子クラス呼出しの条件判定（ビジネスロジック１，２，３で異なる）
３）最初の子クラスの生成と呼出し
次の（ｂ）〜（ｄ）のＤＡＯクラスの生成はビジネスロジック側で生成して引数で子クラスへ渡すか、または子プログラム側で生成するかいずれかで行われるが、どちらになるかはクラスとＤＡＯクラスの関係性情報の引数・スコープ項目で判断する。スコープから渡されたり子クラス側で生成するＤＡＯクラスは、ビジネスロジック側で新たに生成する必要がない。（ただしビジネスロジックのひな型ではどのケースの場合も用意しておき、ソース自動生成時に不要な行セットを削除する）
（ａ）子クラス１生成  
クラスとＤＡＯクラスの関係性情報とＤＡＯのクラスノード情報の条件を使って生成するＤＡＯの種別と引数・スコープ項目が（ｂ）〜（ｄ）の条件に合う処理ケースだけが選択される。クラス内に複数個生成すべきＤＡＯクラスがある場合は（ｂ）〜（ｄ）の条件選択を複数回繰り返す。（ｆ）は生成したＤＡＯクラスをスコープに登録するか否かの処理の選択である。
（ｂ）ｌｉｓｔデータオブジェクトでスコープを使用する場合  スコープの検索
（ｃ）ｌｉｓｔデータオブジェクトの生成
（ｄ）DBdaoオブジェクトの生成
（ｅ）ｌｉｓｔデータオブジェクト、DBdaoを引数にして子クラス呼出し
（ｆ）生成ｌｉｓｔデータオブジェクをスコープに登録する場合、スコープ登録
４）子クラス呼出しの条件判定の終了
５）子クラス２生成
・・・・
６）DBクローズ
【００６２】
５．５．２．ビジネスロジックのひな型プログラム構造例
ビジネスロジック１のひな型プログラムの子クラス生成、呼出し部の例を図３７に示す。
ここは４．６．３のＤＡＯ生成部に対応する子プログラム側のひな型プログラムとほぼ似た構造になるが、通常ビジネスロジックのひな型ではメイン処理部に持ちかつ変換指示情報部の変換式タイプはｙであり、４．６．３のＤＡＯ生成部のひな型ではプレ処理部に持ち、かつ変換指示情報部の変換式タイプはｗである。
ビジネスロジックのひな型プログラムはソースコード情報部と自動変換の指示情報を与える変換指示情報部で構成する。ソースコード情報部はソースプログラムに近い形であるが、５．５．１の３）４）を起動する１生成クラス当りのセット行を変換式タイプｙで区別する。行セットの中に記号［［  ］］で括られた次の（１）〜（５）の変数はシステム構造情報から読み出される情報で置換される。
（１子タスク当りの生成・呼出し）
（１）［［ＢＬ１］］        生成クラスの型
（２）［［ｂｌ１］］        生成クラスオブジェクト
（３）［［ｂｌ１ｉｎ１］］  生成クラス中の呼出入力オブジェクト（複数ありうる）
ｌｉｓｔかＤＢか、スコープか引数継承か、新規生成か
（４）［［ｂｌ１ｏｕ１］］  生成クラス中の呼出出力オブジェクト（複数ありうる）
ｌｉｓｔかＤＢか、スコープか引数継承か、新規生成か
（５）［［ＤＢｄａｏ０１］］  生成クラス中の呼出ＤＢＤＡＯクラス（複数ありうる）
【００６３】
また変換指示情報部ではｙタイプ変換式の行セットを更に部分に分けて、次の（ａ）〜（ｆ）の変換指示コード（ｂ１，ｓ１，ａｒ，ｄｂ，ｄ１，ｒ１）を使って５．５．１に対応する処理内容を区別する。ひな型には生成クラスあたり（ａ）〜（ｆ）の変換指示コードを持つ部分行セットが並んでｙタイプ変換式の行セットを形成する。この場合ｙタイプ変換式の行セットの繰り返し展開数はデータ属性オブジェクト情報ではなく、システム構造情報のビジネスロジックとクラスの関係性情報から読み出す。また（ｂ）〜（ｄ）のどのＤＡＯクラスを生成するかは５．５．１で述べた。
（ａ）ｂｌ  子クラス生成  
（ｂ）ｓ１  ｓｔｒｕｔｓ等のフレームワークでｌｉｓｔデータオブジェクトをスコープから取得する  ｓｅｓｓｉｏｎ、ｒｅｑｕｅｓｔスコープ等を区別
（ｃ）ａｒ  ｌｉｓｔデータオブジェクトの生成
ｌｉｓｔデータオブジェクトを使用する場合の呼出オブジェクト生成
（ｄ）ｄｂ  DBdaoオブジェクトの生成
ＤＢアクセスをやる場合の呼出オブジェクト生成
（ｅ）ｄ１  ｌｉｓｔデータオブジェクト、DBdaoを引数にして子クラス呼出し
（ｆ）ｒ１  生成ｌｉｓｔをスコープに登録する場合、スコープ登録
【００６４】
５．５．３．ビジネスロジックの生成手順
４．５．２のプログラムのひな型から自動生成する場合と基本的な考え方は同じであるがその中のｙタイプ変換式の処理部分が変換指示コード別の処理へ細分化される。
１）プログラム自動生成で使う情報
（ａ）システム構造情報
（ｂ）ビジネスロジックのひな型プログラム
（ｃ）必要ならばパラメタ指定オブジェクト
２）処理フローは図３９、図４０（但し４．５．２の図３０、図３１とはほぼ同じだが一部のみ異なる）、および図４１、図４２
【００６５】
（図３９の左のフロー）
（１）生成対象ビジネスロジックのビジネスフロー層システム構造情報を読む
（２）システム構造情報のクラスノード情報からパラメタ指定オブジェクトを読む
（３）システム構造情報のクラスノード情報からビジネスロジックひな型プログラムを読み、一時的ひな型プログラムへ保存
（４）ＰＧ生成処理を呼出す
（図３９の右のフロー：ＰＧ生成処理）
（１）一時的ひな型プログラムを読出し、変換指示情報部の標準変換式パターンをキーとしてキーが切れるまで繰り返し読み出し、抽出ひな型プログラムへ保存
（２）キーが切れたら抽出ひな型オブジェクトを渡してデータ項目群処理を実行
（３）これを一時的ひな型プログラムを読み終えるまで繰り返す
【００６６】
（図４０の縦方向の流れ：データ項目群処理）
（１）ひな型のＰパラメタ行をパラメタ指定オブジェクトの指定値と置換え
（２）変換式タイプごとの変換処理を実行（この場合はｙタイプ変換式のみ）
（３）その他の変換指示コードの実行
（４）生成されたプログラムをクラスＰＧへ出力．変換指示情報部は削除しソースコード情報部のみ出力する
（５）抽出ひな型プログラムを削除
【００６７】
（図４０の横方向の流れ：データ項目群処理の変換式タイプ別の変換処理）
（１）変換式タイプ毎に変換式処理を呼出し実行。このとき変換式タイプｙ、ｗの変換式処理では主としてシステム構造情報を参照し、それ以外（ｉｄｘ，ｘ，ｋｅｙ等）の変換式タイプの変換式処理では主としてデータ属性オブジェクト情報を参照する。
【００６８】
（図４１のフロー：ｙタイプ変換式処理）
（１）生成する子タスクの数だけ（２）〜（４）を繰り返す。
（２）一時的ひな型プログラムを読出し、変換指示情報部の変換指示コードをキーとして同じキーのものをキーが切れるまで繰り返し読み出し、抽出変換指示ひな型プログラムへ保存
（３）キーが切れたら抽出変換指示ひな型プログラムを引数で渡して変換指示コード処理を実行
（４）これを抽出ひな型プログラムを読み終えるまで繰り返す
【００６９】
（図４２の縦方向の流れ：変換指示コード処理）
（１）変換指示コードごとの変換指示コード処理を実行
（２）その他の変換指示コード別の文字列変換処理の実行
（３）抽出変換指示ひな型プログラムを削除
【００７０】
（図４２の横方向の流れ：変換指示コード処理）
変換指示コード（ｓ１，ａｒ，ｄｂ，ｄ１，ｒ１）別に次の（１）〜（２）を繰り返し実行する
（１）該当変換指示コードの部分セット行を削除すべきか、残すべきかをシステム構造情報とクラスとオブジェクトの関係性情報の引数・スコープ項目から判断し、不要な場合は当該部分セット行を削除する。
（２）残った変換式パラメタの部分セット行について、システム構造情報とビジネスロジックとクラスの関係性情報から５．５．２の記号［［  ］］で括られた変数と置換する名前を読み出し文字列変換を施す。文字列変換後、文字列変換指示コード＊をクリアする。
【００７１】
５．６．ビジネスフロー単位の子プログラムの一括生成
ビジネスフロー層のシステム構造情報の登録が終了したら、ビジネスフローを構成する全ての子プログラムについて課題４の自動生成方法で順次適用して一括自動生成する。
【００７２】
６．課題６「ソース・仕様書一体情報とリバースエンジニアリング」の解決手段
（請求項４に対応）    
自動生成されるソースを仕様書として一体で利用するには、プログラム分割だけではまだ不十分なのでひとつはソースの構造化をシステムで標準化し、それと同時にクラスの内部構造をソースとは別に組込部品層構造情報として生成しそれを内部構造図として１画面で見せ、一目で内部構造が分るようにする。
更にはソース・仕様書一体情報を保守するとき、ソース・仕様書一体情報とシステム構造情報との乖離が起きないように、更新した一体情報に基づいてシステム構造情報を書き換えできるようにする。
【００７３】
６．１．ひな型を使ったソース・仕様書一体情報の構造化
ソースプログラムコードは生のままでは可読性は低い。しかしプログラムを単一機能化しセクションやクローズなどの構造化単位の前後をＸＭＬタグで挟み込み更に人でも分り易いようにコメントを付加すれば可読性を高められる（図４６）それをあらかじめひな型に作り込んでおけば、自動生成したソース・仕様書一体情報も結果的にＸＭＬタグで構造化表記される。
（注）セクション・クローズ：構造化の単位（図４７）
セクション：主処理、プリ処理、ポスト処理等の大きな単位
クローズ：セクションの内部の、通常ｉｆ〜ｅｎｄｉｆ等で括られる中程度の括り単位
周知のごとくＸＭＬには次のような特徴がある。
（ａ）視覚的に文書が構造化され、人にとっても分かり易い表現になる
・日本語を使えばドキュメント性が高まる
・タグの意味を標準化すれば、統一的な表現が可能になる
（ｂ）表記を統一すればコンピュータ処理も可能なのでコンバージョンが楽
ソース・仕様書一体情報の構造化のルールを次のように決める。
プログラムパターンのひな型はセクション（ループ制御プレ処理、主処理、ポスト処理）とクローズ（分岐判別条件処理、終了中断処理）と,組込部品の区切りで構造化される（図４７）。
【００７４】
６．２．ソース・仕様書一体情報が複数ページに跨ると読み難くなるので、ひと目で見渡せる内部構造図を作る。ソース・仕様書一体情報から組込部品層の構造情報と内部構造図を自動生成できる。システムの保守段階でソース・仕様書一体情報を直接更新しても一体情報から組込部品層（内部構造図）を自動生成できる（図４８）。例えば図４６のソース・仕様書一体情報の編集が行われたとき、その中のＸＭＬタグによって構造化区分の開始位置と終了位置がすべて把握でき、呼出プログラムとの関係も更新後も把握できる。従って組込部品層の構造情報はソース・仕様書一体情報の更新と連動させることができる。
【００７５】
６．３．システム構造情報のリバースエンジニアリング
保守ではソース・仕様書一体情報を直接更新するが、このとき従来のシステムの保守で仕様書とプログラムの乖離が起きたと同様に今度はシステム構造情報とソース・仕様書一体情報との乖離が起きる恐れがある。ソース・仕様書一体情報に更新をかけた場合に、それをシステム構造情報へ自動的に反映させるのがリバースエンジニアリングである。それを可能にするため、ソース・仕様書一体情報の自動生成の仕組みの中でシステム構造情報をXMLタグを使って一体情報のコメント行の中に書き込んでやる（図４９）。ソース・仕様書一体情報に書き込む情報は次の（ａ）〜（ｄ）の項目で、重複情報は除いている。
（ａ）クラス（ビジネスロジックも含む）ノード情報
クラス、メソッド、プログラムパターン、（引数型、引数順序）
（ｂ）ＤＡＯクラスノード情報
ＤＡＯクラス、データ属性オブジェクト０、種類、永久化ＤＢテーブル、メソッド、（引数型、引数順序）
（ｃ）クラス（ビジネスロジックも含む）とＤＡＯクラスの関係性情報
ｄｄ名、引数・スコープ、ＤＡＯクラス、データ属性オブジェクト
（ｄ）クラス（ビジネスロジックも含む）とクラスの関係性情報
クラス（子）メソッド（子）、呼出順序（ビジネスロジックの場合）
これらが書き込まれたソース・仕様書一体情報のXMLタグ情報を必要ならば保守時に書き換え、システム構造情報を逆生成すれば、システム構造情報へ反映させることができる。
但し、ＤＡＯクラスノード情報はソース・仕様書一体情報情報から書き換える性質のものではないので、あくまで参考情報どまりである。
尚、ソース・仕様書一体情報に書き込まないシステム構造情報、たとえばビジネスフローノード情報、ビジネスフローとクラスの関係性情報は直接システム構造情報を更新する。
【００７６】
７．課題７「組込部品層による保守時の更新履歴管理」の解決手段
（請求項５）に対応
保守時にソース・仕様書一体情報から新しい一体情報をコピー生成しそれを更新したとき、６．２の方法でその情報を元に組込部品層を自動生成する。このとき元のバージョンのソース・仕様書一体構造も保持されており、新旧の一体情報の内容を比較しその差分を、生成した組込部品層の例えばメソッドノードにプログラムで自動的に書き込む（図５０）。二つの文書中の差分をとる方法は編集距離、最長部分列ＬＣＳ，最小エデット距離ＳＥＤを求めるアルゴリズムとしてすでに確立されている。古いバージョンの一体情報を削除するタイミングは次のバージョン管理の方法で述べる。
【００７７】
８．課題８「ノード情報、関係性情報によるバージョン管理」の解決手段
（請求項６）に対応
１）システム構造情報のバージョン管理（図５１）
システム構造情報のバージョン管理はノード情報と関係性情報に異なるバージョン情報を持って管理する。ノード情報にはそれ自体のノード個別バージョンを持ち、ノード情報はシステム構造情報全体で共有される。それらを繋ぐ関係性情報のセットには同一のシステムｖｅｒＮＯを持ち、一連のシステムｖｅｒＮＯで括られたノードの体系、階層の繋がりが表現される。つまり同じセットバージョン情報の関係性情報でノードを繋ぎ合わせてゆけば、システム全体を次々に参照することができる。但し、この方法では一本のプログラムの更新に対して全ての関係性情報のセットバージョン情報の更新が発生する問題がある。その更新回数を抑制するためには例えば図５２のように、セットバージョン情報を概念層とビジネスフロー層で分ける（左図）とか更にビジネスフロー単位にセットバージョン情報を分割する（右図）方法がある。このとき階層間関係性情報の中に概念層とビジネスフロー層のセットバージョン情報を持つ。ビジネスフロー単位にまで分割すれば一本のプログラムの更新によって書き換える関係性情報はそのビジネスフローの範囲内に収めることができる。但しこの場合は概念層とビジネスフロー層のセットバージョン情報の組を別管理する（簡単でよい）ことになるが、更新回数は遥かに抑えることができる。
【００７８】
２）組込部品層のバージョン管理
組込部品層にはクラスの更新履歴が書き込まれるのでクラス間で共有しない。従って概念層やビジネスフロー層のようにセットバージョン情報を使って管理する必要がない。クラスと一体のノード個別バージョンだけで十分である。
３）システム構造情報から名前でリンクされる情報のバージョン管理
ソース・仕様書一体構造やデータ属性オブジェクト情報はシステム構造情報から名前でリンクされる情報である。それのバージョン管理はノードの中にノード個別バージョンを含めるだけのことで実現できる。
【００７９】
４）新旧のバージョンの情報管理
旧バージョンに更新をかける場合は、旧バージョンはシステム構造情報またはリンク先ファイルにそのまま保存しておき、新バージョンを付け加える形をとる。そのとき一番安全な更新方法は、まず現行バージョンをそっくり作業領域にコピーし、作業領域上で新バージョンを作成し内容を確認したうえで、システム構造情報に追加するようにする。内容的には５．３．２でやっていることと同じである。
【００８０】
９．課題９「三階層構造情報による分り易いシステム体系、構造情報の表現」の解決手段
（請求項対象外）
階層内、階層間の関係性情報を辿りながらシステム体系全体の部品情報や関係性情報を参照、更新、再利用する（図５１）。ここは基本的にシステム構造情報とそのリンク情報を画面で参照・編集するだけの処理であり、従来技術の範囲内であり、特許の申請対象にはならないが、新しい開発方法のイメージを示すために記述する。
【００８１】
１）概念層、ビジネスフロー層、組込部品層の全体構成表示
全体をビジュアルに表示し、さらに３つの階層ごとに繋げて表示することで、仕様書を読まなくとも眼で見て理解できるようにする。まず指定されたシステムｖｅｒＮＯの概念層だけ図５３のように参照画面を表示し、そこで概念層の最下位層ノードが選択されたならそれと階層間関係性情報で繋がれたビジネスフロー層を表示し図５４、更にそこから組立部品層図５５を表示する。
２）システム構造情報のノード情報、関係性情報の更新
８．４）で述べたようにビジネスフロー層に更新をかける場合は、旧バージョンは保存しておき、新バージョンを付け加える形をとる。
【００８２】
３）ソース・仕様書一体情報の編集
（ａ）ソース・仕様書一体情報の編集時には図５６のように組込部品層の構造情報（内部構造図）とソース・仕様書一体情報が同時に表示され、またビジネスフローのシステム構造情報を俯瞰しながら編集できる特徴がある。
（ｂ）ソース・仕様書一体情報への組込部品の組み込み
ソース・仕様書一体情報へ２．２．１．４）で述べたような組込部品を単に組み込んで自由に編集することは従来のソースｅｄｉｔｏｒの技術の範囲内である。組込部品の中にＸＭＬタグによる構造化情報を含んだとしても同じである。ただし、もし組込部品が変換指示情報部とソースコード情報部を持ち、組込先のプログラムのデータ属性オブジェクト情報を使ってひな型と同じ変換過程を踏んだ後にソース・仕様書一体情報の一部として組み込むならば、この機能は課題４で述べたプログラムの自動変換と同じである。
【００８３】
１０．課題１０「課題４〜課題８を適用した新しいシステム開発方法」の解決手段
（請求項１に対応）
１０．１．新しい開発方法の基本的な考え方を一口であらわせば、柔軟な型を通してシステムを捉え、理解し、柔軟な型を使って再利用性を高めることである。特に設計段階では概念層からシステム構造情報の再利用が可能であり、ビジネスフロー層では型を使って単位ビジネスフローの塊りを切り出してシステム構造情報を作り、そこからプログラムを一括生成する。それを実現する手段として述べてきた課題４〜課題８の解決手段は相互にトレードオフの要件を持たず、ｗｅｂやバッチのシステムの開発に単独かもしくは組合せて適用できる。それにより（ａ）システム構造情報を中心に持ちそれを一括利用することができ、（ｂ）システム開発とはシステム構造情報を構築してゆくことと同じであり、（ｃ）プログラムを作成する工程がなく、（ｄ）ビジネスフロー単位で一括してソース・仕様書一体情報を生成し、（ｆ）保守でソース・仕様書一体情報を直接更新してもシステム構造情報へ更新結果を反映させる開発方法が可能になる。
具体的に新旧の開発方法を比較する（図５７）。
【００８４】
１）従来のシステム開発方法
イ）基本設計、詳細設計、プログラム開発工程ごとに膨大なシステム成果物を作成、その上に必要ならＵＭＬも作成。各工程の成果物で重複が発生。特に詳細設計仕様書とプログラムは内容的にはほぼ重複する。
ロ）日本語で書く設計工程での資産の再利用はほとんど困難
ハ）設計工程でのプログラムの切出し単位が不明確
ニ）設計工程とプログラム開発工程の分離と仕様書とプログラムの内容乖離、および負担になるプログラム開発工数
２）新しいシステム開発方法（開発工程が変わる）
イ）システム構造情報だけでこれ以外の仕様書もＵＭＬも不要。概念層、ビジネスフロー層、組込部品層の構造情報のみ。
ロ）開発の上流から下流まで構造情報の再利用徹底。
ハ）概念層の設計では概念層システム構造情報を再利用
ニ）ビジネスフロー層の設計では柔軟な型でビジネスフローやプログラムを切り出す。
ホ）ニ）でシステム構造情報ができたらソース・仕様書一体情報と内部構造情報を一括生成。プログラムの開発工程はない。
ヘ）自動生成プログラムの更新は保守と同じ。直接ソース・仕様書一体情報を更新。
【００８５】
１０．２．背景技術で述べたように特許の検討対象として、画面層とＩＯ層を切り離しているので、その関係について図５８で示しておく。この開発方法も基本的にはデータ中心設計であり、業務層の設計に先立ち、ＩＯ層と画面層が設計されている。ＤＡＯが生成された段階では図１７の３に示したシステム構造情報ができていなければならない。画面層もＩＯ層もフレームワークがあればそれを活用して開発され、業務層とのインターフェースはそれぞれオブジェクトＭｏｄｅｌｂｅａｎ，ＪＰＡｅｎｔｉｔｙを介して行われる。
【発明の効果】
【００８６】
１．システムを細かな説明を要しない型で組み立てることでシステムの理解が早まる
２．開発・保守工数が画期的に削減    
本発明を適用することで開発生産性のどこが改善されるのか図５９によって説明する。
まず開発工程全体を見た場合は、左図で示すように本発明はＩＯ層や画面層を切り離しておりまたテスト工程も直接対象にはしていないので、改善される工程は業務プログラム開発に限られる。さらに業務プログラム開発工程の中でも、右図で示すように手続き部分を取り除いた純然たるピュア業務部分については改善されない。その割合はシステムの種類によってもまたｗｅｂかバッチかによってもかなり変わってくる。ｗｅｂの一例は実施例を参照されたい。
３．システム品質の向上。特に保守品質の向上
（ａ）シンプルでビジュアル化されたシステム構造情報とソース・仕様書一体情報による表現
（ｂ）データ間（オブジェクト）の連携が分かり易い
（ｃ）クラス構造の標準化
４．従来型の読む仕様書は不要、ソース・仕様書の一体化
５．ドキュメントレス。開発生成物はシステム構造情報とソース・仕様書一体情報
６．プログラムが単一機能化し単体テストがし易い
７．ピュア業務への集中（ビジネスフロー、プログラムの型による一括設計）
８．特殊技術の隠蔽。技術の変化に強いシステム構造。資産の再利用性向上
９．変化が早い複雑な開発技術の修得から開放
１０．ＰＧ数、画面数、データ数、データ項目数などのプログラムやシステムの構成要素が全て明確になり、開発工数見積り方法、開発生産性の追及、品質障害原因の追究などがやりやすくなる。
１１．クラス構造の標準化が進み、構造面の設計品質チェックやプログラムの処理パターンの分布、標準システムと個別システムとの乖離度など構造面の統計分析がしやすくなる。
【図面の簡単な説明】
【００８７】
【図１】基本設計思想：システムを型で掴み、表現し、理解する
【図２】新しい開発方法の全体機能構成図
【図２ａ】新しい開発方法の全体情報構成図
【図３】課題対象領域
【図４】型：類似処理のゆるやかな括り
【図５】ソース・仕様書一体情報の構造化
【図６】プログラムの大きさと組合せの難易度比較
【図７】開発効率とドキュメント品質の比較
【図８】プログラムの分割・単一機能化
【図９】業務処理の型化・・・制御ループプログラムパターン
【図１０】業務処理の型化・・・ビジネスロジックパターン
【図１１】１層制御ループの業務プログラムパターン（Ｐ１０ｘ）
【図１２】２層制御ループの業務プログラムパターン（Ｐ２０ｘ）
【図１３】０層制御ループの業務プログラムパターン（Ｐ００ｘ）
【図１４】単機能組込部品（Ｐ７ｘ）
【図１５】呼出組込部品（Ｐ８ｘ）
【図１６】概念層のシステム構造情報
【図１７】ビジネスフロー層のシステム構造情報（１）
【図１８】ビジネスフロー層のシステム構造情報（２）
【図１９】ビジネスフロー層のデータの参照関係
【図２０】ＤＡＯクラスの引数渡しの判定
【図２１】組込部品層のシステム構造情報
【図２２】新旧のプログラム自動生成方法の比較
【図２３】プログラム自動生成の仕組み
【図２４】データ項目群処理の自動生成の仕組み
【図２５】データ属性オブジェクト情報の例
【図２６】プログラムパターンのひな型例
【図２７】自動生成されたプログラム例
【図２８】インターフェース部（引数）・DAO生成部の自動生成
【図２９】子クラスメソッド呼出部のひな型例
【図３０】データ項目群処理自動生成ビジネスフロー（１）
【図３１】データ項目群処理自動生成フローチャート（２）
【図３２】データ項目群処理自動生成処理の型
【図３３】ビジネスフロー単位の一括生成
【図３４】ｗｅｂビジネスフローの場合
【図３５】バッチビジネスフローの場合
【図３６】ビジネスロジックと生成子クラス
【図３７】ビジネスロジックのひな型例
【図３８】ビジネスロジック自動生成時の参照情報
【図３９】ビジネスロジックの自動生成フローチャート（１）
【図４０】ビジネスロジックの自動生成フローチャート（２）
【図４１】ビジネスロジックの自動生成フローチャート（３）
【図４２】ビジネスロジックの自動生成フローチャート（４）
【図４３】中間データ属性オブジェクト情報の連続生成
【図４４】ＩＮとＯＵＴのデータ属性オブジェクト情報の対応関係
【図４５】中間データ属性オブジェクト情報の個別生成ルール
【図４６】プログラムの内部構造の表現
【図４７】単一機能プログラムの構造化
【図４８】単一機能プログラム内部構造図
【図４９】システム構造情報のリバースエンジニアリング
【図５０】組込部品層での更新履歴管理
【図５１】ノード情報と関係性情報によるバージョン管理（１）
【図５２】ノード情報と関係性情報によるバージョン管理（２）
【図５３】ビジネスフロー中心の分りやすい３階層ビュー
【図５４】概念層内の構造ビュー
【図５５】ビジネスフロー層内の構造ビュー
【図５６】組込部品層内の構造ビュー
【図５７】新旧システム開発方法の比較
【図５８】画面層・IO層の設計との関係
【図５９】開発生産性を切り出して見る
【図６０】適用例
【図６１】ビジネスフロー設計試行例（物流在庫引当）
【図６２】ビジネスフロー設計試行例（物流在庫引当）
【図６３】ビジネスフロー設計試行例（生産計画）
【実施例】
【００８８】
このソフトウエア部品化再利用方法、開発方法を物流システム、生産計画システムのｗｅｂシステムの一部に適用し自動生成率を調査した結果を図６０に示す。ｗｅｂ画面からリクエストが入力されてから画面に処理結果が返されるまでのビジネスフローを単一機能単位のクラスに分解したとき完全自動生成されるクラスと手続き部分を自動生成した後固有業務処理を付加するクラスの比率がどうなるか調べている。
ｗｅｂ処理では定型的な処理が定まった順に並びビジネスフローパターンが有効に生かせるので自動化率はバッチより高くなる。
（物流システム）（図６１、図６２）
在庫引当システムの５画面とそこから起動されるビジネスフロー１３本の構成の中から、一例としてひとつのビジネスフローを構成するプログラムパターンを図６２で示す。この例では全体で７０個のクラスのうち非定型業務処理クラスは７つであり、ほかは全て完全自動生成可能な定型業務クラスである。図６２中のクラスの番号Ｐｎｎｎはプログラムパターンを示している。ほとんどのビジネスフローで似通った定型処理が繰り返され、非定型業務処理はそのなかの極く一部でしかないことが分る。
（生産計画システム）（図６３）
生産計画対話更新システムの４画面とそこから起動されるビジネスフロー６本の構成の中から、一例としてひとつのビジネスフローのプログラムパターンを図６３で示す。この例では全体で４０個のクラスのうち非定型業務処理クラスはわずかひとつであり、ほかは全て完全自動生成可能な定型業務クラスである。
【産業上の利用可能性】
【００８９】
ｗｅｂやバッチシステムの開発・保守に適用可能であり、あらゆる法人や官公庁などの情報システム部門、ソフトウエア開発産業で幅広く利用可能。
【符号の説明】
【００９０】
１    画面層                                              図３
２    ＩＯ層                                              図３
３    業務層                                              図３
４    フレームワーク                                      図３
５    ＵＭＬ                                              図５７
６    ＤＡＯ                                              図２１、図２３
７    システム構造情報                                    図２
８    概念層                                              図３３、図５３
９    ビジネスフロー層                                    図３３、図５３
１０  ビジネスフロー                                      図５３
１１  ビジネスロジック                                    図３６
１２  組込部品層                                          図２１、図４８、図５３
１３  組込部品                                            図２１
１４  ノード情報                                          図５３
１５  関係性情報                                          図５３
１６  階層内関係性情報                                    図５３
１７  階層間関係性情報                                    図５２、図５３
１８  ｌｉｓｔデータオブジェクト                          図８
１９  型（パターン）                                      図４
２０  プログラムパターン                                  図９
２１  １層制御ループプログラムパターン                    図１１
２２  ２層制御ループプログラムパターン                    図１２
２３  ０層制御ループプログラムパターン                    図１３
２４  ビジネスロジックパターン                            図１０
２５  データ属性オブジェクト情報                          図２５
２６  仮名                                                図２５
２７  変換式タイプ                                        図２４
２８  標準変換式タイプ                                    図２４
２９  個別変換式タイプ                                    図２４
３０  インデックス                                        図２５
３１  ひな型プログラム                                    図２６
３２  ソースコード情報部                                  図２６
３３  変換指示情報部                                      図２６
３４  参照ｄｄ名                                          図２６
３５  文字列変換指定                                      図２６
３６  パラメタ指定オブジェクト                            図２
３７  プログラム間インターフェース（引数）                図２８
３８  ソース・仕様書一体情報                              図２
３９  ユースケース図                                      図３３
４０  ＸＭＬタグ                                          図４６
４１  セクション                                          図４６
４２  クローズ                                            図４６
４３  プレ処理                                            図４７
４４  主処理                                              図４７
４５  ポスト処理                                          図４７
４６  リバースエンジニアリング                            図５７
４７  差分情報                                            図５０
４８  ノード個別バージョン                                図５１
４９  セットバージョン情報                                図５１、図５２
５０  ３階層ビュー                                        図５３
【図１】
2015022433.tif 000003
【図２】
2015022433.tif 000004
【図２ａ】
2015022433.tif 000005
【図３】
2015022433.tif 000006
【図４】
2015022433.tif 000007
【図５】
2015022433.tif 000008
【図６】
2015022433.tif 000009
【図７】
2015022433.tif 000010
【図８】
2015022433.tif 000011
【図９】
2015022433.tif 000012
【図１０】
2015022433.tif 000013
【図１１】
2015022433.tif 000014
【図１２】
2015022433.tif 000015
【図１３】
2015022433.tif 000016
【図１４】
2015022433.tif 000017
【図１５】
2015022433.tif 000018
【図１６】
2015022433.tif 000019
【図１７】
2015022433.tif 000020
【図１８】
2015022433.tif 000021
【図１９】
2015022433.tif 000022
【図２０】
2015022433.tif 000023
【図２１】
2015022433.tif 000024
【図２２】
2015022433.tif 000025
【図２３】
2015022433.tif 000026
【図２４】
2015022433.tif 000027
【図２５】
2015022433.tif 000028
【図２６】
2015022433.tif 000029
【図２７】
2015022433.tif 000030
【図２８】
2015022433.tif 000031
【図２９】
2015022433.tif 000032
【図３０】
2015022433.tif 000033
【図３１】
2015022433.tif 000034
【図３２】
2015022433.tif 000035
【図３３】
2015022433.tif 000036
【図３４】
2015022433.tif 000037
【図３５】
2015022433.tif 000038
【図３６】
2015022433.tif 000039
【図３７】
2015022433.tif 000040
【図３８】
2015022433.tif 000041
【図３９】
2015022433.tif 000042
【図４０】
2015022433.tif 000043
【図４１】
2015022433.tif 000044
【図４２】
2015022433.tif 000045
【図４３】
2015022433.tif 000046
【図４４】
2015022433.tif 000047
【図４５】
2015022433.tif 000048
【図４６】
2015022433.tif 000049
【図４７】
2015022433.tif 000050
【図４８】
2015022433.tif 000051
【図４９】
2015022433.tif 000052
【図５０】
2015022433.tif 000053
【図５１】
2015022433.tif 000054
【図５２】
2015022433.tif 000055
【図５３】
2015022433.tif 000056
【図５４】
2015022433.tif 000057
【図５５】
2015022433.tif 000058
【図５６】
2015022433.tif 000059
【図５７】
2015022433.tif 000060
【図５８】
2015022433.tif 000061
【図５９】
2015022433.tif 000062
【図６０】
2015022433.tif 000063
【図６１】
2015022433.tif 000064
【図６２】
2015022433.tif 000065
【図６３】
2015022433.tif 000066
【手続補正書】
【提出日】平成25年8月26日(2013.8.26)
【手続補正１】
【補正対象書類名】図面
【補正対象項目名】図３２
【補正方法】変更
【補正の内容】
【図３２】
2015022433.tif 000067