(57)【要約】      （修正有）【課題】ソースプログラムの自動生成が可能になり、業務要件の稼動基盤からの独立性が確保され、変数関係の順序を考慮する必要がなくなり、さらに、品質の向上とテスト工程の削減がなされること。【解決手段】本発明は、要件定義をもとに各論理体に所属する単語単位で所定の属性をデータとして規定する第１のステップと、要件の過不足を調整する第２のステップと、前記第2のステップで調整されたデータをＬｙｅｅ所与のプログラム構造をもつ自動生成ツールに入力し、目的コードを得る第３のステップとを具備するソフトウェア生成方法において、入力処理と業務処理、出力処理を独立化し、入力処理は業務処理を「入れ子」とする２重Loop構造をとり、入力処理群の完了判定後は、未完了の場合は、再度入力処理群へ制御を移し、入力処理群が完了した場合は、出力処理へ制御を移し、出力処理では完了判定は行わずに上司/部下プログラムの構成とする。【選択図】図３３
2008171023.tif 000002
【特許請求の範囲】
【請求項１】
要件定義をもとに各論理体に所属する単語単位で所定の属性をデータとして規定する第１のステップと、
要件の過不足を調整する第２のステップと、
前記第2のステップで調整されたデータをソフトウェアの必須要素としてＬｙｅｅ所与のプログラム構造をもつ自動生成ツールに入力することにより所望のソフトウェアの目的コードを得る第３のステップと
を具備するソフトウェア生成方法において、
前記Ｌｙｅｅ所与のプログラム構造においては入力処理と業務処理、出力処理を独立化し、入力処理は業務処理を「入れ子」とする２重Loop構造をとり、入力処理群の完了判定後は、未完了の場合は、再度入力処理群へ制御を移し、入力処理群が完了した場合は、出力処理へ制御を移し、出力処理では完了判定は行わずに上司/部下プログラムの構成とすることを特徴とするソフトウェア生成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェア生成方法に係り、特に、Ｌｙｅｅ方法論におけるソフトウェア生成方法に関する。
【背景技術】
【０００２】
高い品質を持つソフトウェアを容易に迅速に製造することは、ソフトウェア開発研究分野での基本的な関心事である。ここ数年間にわたって、ソフトウェア開発のライフサイクルに関連する１つまたは多くの局面を改善するために、種々の方法論および技術が考案され、提案されてきた。
【０００３】
しかし、この研究分野における熱心な努力にもかかわらず、明確に理解でき、修正可能なシステムの製造は、困難な目標であり達成にはほど遠い。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
これまでのシステム開発は、次のような欠点があった。
【０００５】
まず、業務要件が稼動基盤に依存し、少々の変更でもプログラム・ロジックの変更を考慮する必要があり、品質面の不安定性・テスト工程の煩雑さがあった。これがシステム開発プロジェクト全体の遅延をもたらしていた。
【０００６】
またこれが、プログラム保守の変更・追加作業にも波及し、作業の複雑化、非効率化を招いていた。
【０００７】
さらにプログラムの業務アプリケーション定義書の記述量が膨大となっていた。
【０００８】
また、プログラムにおいては各個別のフレームワークで規定しているフレームに対してのみ対応し、汎用性が低かった。
【０００９】
本発明は上記の従来技術の問題を解決するためになされたもので、ソースプログラムの自動生成が可能になり、業務要件の稼動基盤からの独立性が確保され、変数関係の順序を考慮する必要がなくなり、さらに、品質の向上とテスト工程の削減がなされることで、スピーデイなシステム開発が可能となるソフトウェア生成方法を提供することを目的とする。
【００１０】
さらに本発明の別の目的は、プログラム保守の変更・追加作業でも効果が発揮され、作業の容易化、効率化が可能となるソフトウェア生成方法を提供することである。
【００１１】
本発明のまた別の目的は、プログラムの業務アプリケーション定義書の記述量が少なくて済み、定義書の量的な削減が図られることを可能とするソフトウェア生成方法を提供することである。
【００１２】
本発明のさらに別の目的は、種々のフレームワークで規定しているフレームにも容易に対応可能なソフトウェア生成方法を提供することである。
【課題を解決するための手段】
【００１３】
かかる課題を解決するため、本発明は、要件定義をもとに各論理体に所属する単語単位で所定の属性をデータとして規定する第１のステップと、要件の過不足を調整する第２のステップと、前記第2のステップで調整されたデータをソフトウェアの必須要素としてＬｙｅｅ所与のプログラム構造をもつ自動生成ツールに入力することにより所望のソフトウェアの目的コードを得る第３のステップとを具備するソフトウェア生成方法において、  前記Ｌｙｅｅ所与のプログラム構造においては入力処理と業務処理、出力処理を独立化し、入力処理は業務処理を「入れ子」とする２重Loop構造をとり、入力処理群の完了判定後は、未完了の場合は、再度入力処理群へ制御を移し、入力処理群が完了した場合は、出力処理へ制御を移し、出力処理では完了判定は行わずに上司/部下プログラムの構成とすることを特徴とする。
【発明の効果】
【００１４】
本発明によれば、ソースプログラムの自動生成が可能になり、業務要件の稼動基盤からの独立性が確保され、変数関係の順序を考慮する必要がなくなり、さらに、品質の向上とテスト工程の削減がなされることで、スピーデイなシステム開発が可能となる。なおここで、Ｌｙｅｅ（商標）とは、「ｇｏｖｅｒｎｍｅｎｔａＬ  ｍｅｔｈｏｄｏｌｏｇＹ  ｆｏｒ  ｓｏｆｔｗａｒＥ  ｐｒｏｖｉｄｅｎｃＥ」（ソフトウェア開発における統一的方法論）の逆頭文字語である。
【００１５】
さらに、プログラムのスピーデイな開発が可能なことは、プログラム保守の変更・追加作業でも効果が発揮され、作業の容易化、効率化が図られる。
【００１６】
またさらに、プログラムの業務アプリケーション定義書は、プログラム制御に係わる記述が不要となるため記述量が少なくて済み、定義書の量的な削減が図られる。
【００１７】
さらに、LyeeプログラムはMDAで規定するＳＩＭとＰＳＭそれぞれに対応可能である。またLyeeプログラムはプログラム構造のみを規定しているため、MDA以外のフレームワークで規定しているフレームにも容易に対応可能である。
【発明を実施するための最良の形態】
【００１８】
以下、図面を参照して本発明の最良の実施形態を説明する。
はじめに
１部  Lyeeプログラムとはどんなものか
１章    Lyeeプログラムの特徴
１．１  仕事が始められる条件は？
１．２  上司／部下プログラム
１．３  複数モジュール化した上司／部下プログラム
２章  Lyeeプログラムの基本形
２．１  上司／部下プログラムのプログラミング方法
２．２  具体例：購入金額計算プログラム
２．３  まとめ
２部  Lyeeプログラム生成機能を使ってのシステム開発方法
Lyeeプログラムの役割とシステム開発方法
１．１  システム構築方法：ＭＤＡ
１．２  Lyeeプログラムの役割
１．３  Lyeeの業務アプリケーション要件の記述方法
１．４  システム開発方法
１．５  Lyeeプログラム生成機能
２章  Lyeeプログラムの入出力処理
２．１  入出力処理のプログラミング方法
２．２  具体例：購入金額照会プログラム
２．３  まとめ
３章  Lyeeプログラムの複数モジュール構成
３．１  Lyeeプログラムの複数モジュール化
３．２  具体例：注文画面処理プログラム
３．３  モジュール制御を含んだ上司プログラム
３．４  モジュール制御の部下プログラム
４章  システム開発上の効果
４．１  スピーデイなシステム開発
４．２  保守作業の効率化
４．３  業務アプリケーション定義書類の削減
４．４  多種なフレームと共存
４．５  課題
参考資料１  無限ループ防止仕様の詳細説明
参考資料２  プログラムフローの補足
参考資料３  Lyeeプログラム実績
参考資料４  ソース生成ツール入力例
はじめに
1  業務アプリケーション機能の画期的な開発の仕方
独創的で画期的な業務アプリケーション機能の開発方法が考案された．それがどのように画期的かは当ホームページで紹介されている色々な資料で述べられているが、ここでは著者らの見方でそれを説明したいと思う．
（１）開発のスピードが速い
理由：ソフトウエア開発の主要要素である業務アプリケーション機能についてLyeeでは、変数間の関係が専ら問題の論理的な関係を考慮するだけで良く、複雑な変数間の関係を斟酌する必要が無い。このためソフトウエア開発のスピードが速い。
（２）業務アプリケーション機能のメンテナンスが容易である
理由：（１）でも述べたが、Lyeeでは変数間の関係は論理的な関係を記述するだけで他の条件等はそもそも記述していないから、他の条件に影響されない。結果として業務アプロケーション機能のメンテナンスは、実現しようとする目標（問題の論理関係）が変わらぬ限り生じない．
（３）そのようなウマイ話がどうして成立するのか
理由：変数間の関係はコンピュータに自動的に行わせるプログラミングが可能となった．これは、コンピュータの主記憶が十分大きくなったことと計算スピードが速くなったことによってはじめて実用的な方法として使えるようになったといえる．
そのため、実行時にある程度コンピュータに変数間の関係を探させる必要があり、その結果、処理時間を限界まで高める必要のあるソフトウェアの開発に適用するには限界がある。しかし、変数間の関係をコンピュータが自動的に捜してくれるので、開発のスピードやメンテナンスの容易さが、より重要となるアプリケーションでは威力を発揮する。事務処理型のソフトウェアでは処理時間もさることながら、ソフトウエア開発のスピード、メンテナビリティにより価値を認めるから、そこでは十分実務的に使える開発方法である。  データベースアクセスなどアプリケーションに依存しないミドルウエアを利用するときには、従来のソフトウエアと同じく使用ミドルウエアが規定したインターフェースを持つ必要がある。理屈ではなく本書に添付されたサンプルプログラムで実際の雰囲気を味わっていただきたい。
２  開発のスピード、メンテナビリティの向上のもう一つの説明
Lyeeの方法論を良く調べるとそこではプログラムの作成に従来の意味でのプログラミングが不要であることに気付くであろう。
【００１９】
誇張して言うと、業務アプリケーション機能の開発は変数という「意味を扱う対象」をデータとして記述することしか行っていない。つまり、データの定義が終われば、そこで業務アプリケーション機能のソースプログラムは自動的に生成されるのである。
【００２０】
「データとして記述する」ということは具体的には何かは、今は明らかなことではないが、本書を読み進まれるうちにそれがどのように有効かを示す。
【００２１】
プログラミングはいくら勉強しても、したりないもので、コンピュータの出現以来ずっとソフトウエアはこの問題を追いつづけている．それにも拘わらず未だにプログラミングの新しい方法の提唱がやまない。今後も同様の提案は絶えることなく現れるであろう。
【００２２】
これに対してデータを定義する業務アプリケーション機能の開発方法は基本的にはデータが出尽くすならばそれ以上は増えつづけない。データに付随してロジックを与えロジック間のつながりは自動生成ツールに任せて、人は新たにプログラムを組まないからである。
【００２３】
Lyeeはデータを定義するのと同じ感覚で業務アプリケーション機能が記述でき、かつソースプログラムも自動的に作成できるので、本書ではLyeeを「データ指向プログラムの自動生成」と唱えることにした．
１部  Lyeeプログラムとはどんなものか
１章  Lyeeプログラムの特徴
Lyeeプログラムはあっと驚く単純な構造をしている。構造は単純であるが業務アプ      リケーション機能が何であってもその構造以外の構造は考える必要が無い。従って      プログラムの構造を複数の候補の中から選択すると言う手間は要らない。
【００２４】
この章ではLyeeプログラムの構成を「上司・部下」の役割に喩え、精密さは多少犠      牲にしたアイデアレベルの説明でその特徴を理解されたい。ここでの理解があると、２章以降のプログラムフローを基にした説明も簡単に理解できるはずである。
１．１  仕事が始められる条件は？
Lyeeプログラムの構造は単純であるが業務アプリケーション機能が何であってもその構造以外の構造は考える必要が無い。このようなことが何故可能なのか？複雑なケースの分析は後回しにして、２種類の人が仕事を分担して処理を行うケースを考える。２種類の人とは図１の２種類である．ここでは前者を上司、後者を部下と仮に呼んでおく。直感的に明らかなようにビジネス処理はこの２種類の人の共同作業でなされる。処理が複雑な時には部下が上司となって更に他の部下に仕事を回すこともあるが、それは単に処理が複雑になっただけで処理の考え方は変わらない。
【００２５】
さて、共同作業を単純化すると上司は他人に仕事を依頼した後は単に部下に依頼した処理が終わったかどうか待っているだけでよい。その上で部下全員が処理を完了した時、上司は自分自身がしなくてはならない仕事をして、仕事は一件落着となる。
【００２６】
ここで重要なのは部下が仕事をする順番は、上司も部下も特に考える必要はないということである。実際上は部下Ａが作業をするのに必要な条件が整っていないときにはその条件が整えられるまで部下Ａは作業をせずに単に待つ。そのことにより自然に処理の順番が定まる。部下Ａは自分の必要とする条件だけに興味を持てば良く、他のことは気にしなくても良い。
【００２７】
仕事を渡された部下のいずれもが自分の必要とする条件が満たされない時にはそもそも上司が依頼した仕事が不可能であったケースで、上司には「不可能であった」ということが通知される。このことによって、いくら大きな仕事であろうと処理をするときに考える範囲はごく限られたものになる。これをコンピュータプログラム的に展開したものがLyeeプログラムである。
１．２  上司／部下プログラム
購入金額計算の具体的処理でLyeeの上司プログラムや部下プログラムの概要を説明する（図２）。
ここでは、実稼動可能なプログラムを構成する命令の一部の‘塊‘をプログラムと呼んでいる。ここでのプログラムは上司モジュール（またはセクション）、部下モジュール（またはセクション）と同等である。同図において、業務要件としては（１）購入金額＝購入数量×単価×（１−割引率／１００）、（２）割引率：購入数量２０個以上は２０％引き、購入数量１９個以下は０％引きとする。
部下プログラムの構造
部下は上司から命令された仕事をする人である。購入金額計算処理での“仕事”とは、「購入金額」の計算、「単価」の決定、「割引率」の決定であり、これらの仕事を引き受ける部下が３人居るとする。
【００２８】
１人目の部下（部下１とする）の「購入金額の計算」の“仕事”は、計算に必要なデータが揃っているかを確認し、揃っていれば計算を行い、上司に完了を報告する。揃っていなければ揃うまで待つ。これをフロー図で表すと図３となる。なお、同図中、「計算に必要なデータ」とは、購入数量、商品単価、割引率である。
【００２９】
２人目の部下（部下２とする）の「単価の決定」の“仕事”は、商品マスターより該当商品の単価を得ることとする。商品マスターの入力処理が完了していれば単価が得られ、入力処理が未完了ならば完了するまで待つこととなる。これをフロー図で表すと図４となる。なお、同図中、「単価セットに必要なデータが揃ったか」に関しては、単価は商品マスターより得られるとしている。このため「単価セットに必要なデータ」は、商品マスターファイルの該当商品についての単価である。
【００３０】
３人目の部下（部下３とする）の「割引率の決定」の“仕事”も同様で、画面より入力された購入数量が２０個以上の場合は２０％引き、購入数量が１９個以下の場合は０％引きの割引率となる。画面より入力された購入数量が得られなければ得られるまで待つこととなる。これをフロー図で表すと図５となる。なお同図中、「割引率決定に必要なデータ」は画面より入力された購入数量としている。このため「割引率決定に必要なデータ」は画面より入力された購入数量である。
【００３１】
これらがLyeeの部下プログラムの基本的なプログラムフローである。購入金額計算の例題は簡単なので部下プログラムは３個しかないが、１画面で項目数が１００個以上となる場合もある。この場合は部下プログラムが１００個以上となる。
【００３２】
部下プログラムのプログラムフローを一般形で表現すると図６となる。部下プログラムは３つの命令群で構成され、第１の命令が「判定」であること、及び第３の命令が「完了報告」であることがLyeeプログラムの特徴である。なお第２の命令は通常のプログラムと同様に「指示された仕事」に関する「計算」とか「値のセット」とかの命令となる。
１．２．２  上司プログラムの構造
ここで、上司プログラムはプログラム構造的に必須事項ではないが、説明を簡単にするため加えている。
（１）上司プログラムのフロー
上司は次の３点を実施する人とする。
【００３３】
i. 部下に「仕事の割当と作業指示」を行う。
【００３４】
ii. 自分自身の「仕事」を行う。
【００３５】
iii. 仕事の「完了判断」を行う。
【００３６】
購入金額計算での上司プログラムの具体的役割は
i.部下への仕事の割当と作業指示
部下１：購入金額の計算  
部下２：単価の決定
部下３：割引率の決定
ii. 自分自身の仕事：「入力処理」と「出力処理」
iii. 完了判断
を行うことである。この上司の役割をプログラムフローで図示すると図７となる。
【００３７】
なおここで、「入力処理」に関して、ここでは説明を簡単にするため、入力処理や出力処理についてのLyeeプログラムフローの説明は省略している。入出力処理のLyeeプログラムフローは２部２章の2.1.1や2.1.3を参照されたい。また、図７中、「Call  部下１Sec」は部下１セクションの処理へ制御を移すことを意味する。また図７は現在の逐次処理型コンピュータを前提としたフローである。Lyeeプログラムの本来的な考え方は図８の並列処理を想定している。
【００３８】
「完了判定」では「完了」と「未完了」の場合で分岐が発生するが、分岐先（遷移先）は次となる。
【００３９】
（Ａ）「完了」と判定した場合：出力処理へ移る。
【００４０】
（Ｂ）「未完了」と判定した場合：再度「作業の割当と作業指示」を行う。
なお「完了」の判定方法は無限ループを回避するため一定の考慮を必要とする。なおここで、無限ループとならないため、「完了判断」の内容は「全ての完了」を完了と判断するだけでなく、何回処理を繰返しても「完了が見込めない」ものも完了として扱う必要がある。詳しくは巻末の参考資料１無限ループ防止使用の詳細説明を参照されたい。なおこの無限ループ回避方式はデータを順番に並べるソート処理でのデータを「並び終えた」ことを判断する方式と類似する。
【００４１】
（２）作業完了までの経緯
購入金額計算の具体例で作業完了までの経緯は以下であり、図示すると図９となる。この経緯を要約すると、「上司は作業が完了と判断されるまで、部下への作業指示を繰返し、作業指示を何回か繰返した後には必ず作業は完了となる」である。
【００４２】
＊＊作業完了までの経緯の説明＊＊
(一)まず入力処理が行われ１回目の「完了判定」が為される。判定は「未完了」である。
【００４３】
＜初回ループ＞
(二)初回の各部下の処理が開始される。部下２と部下３の「購入単価の決定」と「割引率の決定」作業は完了する。しかし「購入金額の計算」作業は未完了である。
【００４４】
(三)２回目の「完了判定」が行われ、判定は「未完了」である。
【００４５】
＜２回目ループ＞
(四)２回目の各部下の処理が行われる。部下１の「購入金額計算」は作業前提のデータが揃っているので計算が完了する。部下２、部下３は既に作業完了している。
【００４６】
(五)３回目の「完了判定」が行われ、作業は「完了」と判断される。処理は出力処理へ移り、出力後、作業は終了する。なおここで、部下の数が増えても「作業完了」に到る繰返し（ループ処理）回数は異なるが、作業完了までの経緯は同様であることを理解されたい。
（３）部下プログラムの判定条件の追加
前述のように、部下プログラムは上司プログラムから何回も呼ばれる可能性がある。これに対処するため部下プログラムフローの第１番目の判定は、(一)「仕事遂行に必要なデータが揃ったか」に加え、(二)「当該処理が完了したら“再度”実施しない」条件を追加する。具体的には、図１０となる。このことで再度計算してしまう無駄や再計算による累積値の値が不正解となることを防止できる。なお同図で「割引率の決定に必要なデータが揃った」とは、具体的には以下である。すなわち、
(A) 「割引率の決定に必要なデータ」は画面より入力された「購入数量」である。
(B) 「割引率の決定は未実施か」は「割引率決定記録」を判定する。「割引率決定記録」の具体的内容は２章の２．１．３（２）「“既に実施済か”の判定方法」を参照されたい。
【００４７】
購入金額計算処理の上司プログラムのフローと部下プログラムのフローを一括してまとめると図１１となる。
１．３  複数モジュール化した上司／部下プログラム
上司／部下の役割をもとにLyeeプログラムの特徴を説明して来たが、一般的な仕事では複層的な上司／部下の構成で行われる場合も多い。これと同じく、ある１つのプログラムでも複数の単位（以降モジュールと言う）を組合わせて一連の処理を行う場合も数多くある。Lyeeプログラムは、この複数モジュール化にどう対処するかの考え方を図１２に説明する。
１．３．１  複数モジュール化対応の考え方
Lyeeプログラムの複数モジュール化の対応は次の考え方で行う。
(一)各モジュールを階層構造化する。  
(二)各モジュールの内部構成はいままで説明した上司・部下構成とする。
【００４８】
図１２の左側の３階層の例をLyeeモジュール化すると図１３となる。まず、「部長と課長Ａ、Ｘ」の構成が親モジュール、「課長Ａと社員A1〜An」が子モジュール１、「課長Ｘと社員X1〜Xm」が子モジュール２の３モジュール構成となる。
【００４９】
各モジュール内での上司や部下の役割今までと変わりが無い。ただし部下の「仕事」は「子モジュールに作業指示を出す（プログラム的には“子モジュールのCall”）」という内容も１つの「仕事」と考える。
複数モジュール化したLyeeプログラム例
いままで述べてきた「金額計算」処理に「発注」処理を加えた注文画面（図１４）を例にLyeeプログラムの複数モジュール化の概要を説明する。詳しくは２部３章を参照されたい。
注文画面プログラムのモジュール構造
なお、Lyeeプログラムのモジュール分割方法は第２部３章３．１．３を参照されたい。
【００５０】
注文画面処理は操作者が画面へ情報を入力し「金額計算」ボタンか「発注」ボタンを押下されたかに応じ必要な処理がなされるとする。注文画面処理のモジュール構成は表１に示すように、「画面入出力＆金額計算」処理の機能と「発注」処理の機能に２分割した２モジュール構成とする。
【００５１】
【表１】
2008171023.tif 000003
注文画面処理のモジュール構造は「画面入出力＆金額計算」モジュールが親モジュール、「発注処理」モジュールが子モジュールとなる。これを図示すると図１５のモジュール構造となる。なお同図で「入力：注文番号採番ファイル」とは、注文番号を採番するファイルとする。
（２）各モジュールの上司プログラムフロー
親モジュールと子モジュールの上司プログラムのフローは図１６、１７となる。
【００５２】
複数モジュール化の特徴は「仕事」として「子モジュール呼出」の仕事が加わることである。
【００５３】
図１７において、「注文番号採番ファイル入力」について、注文番号は採番ファイルより得ることとしているので、採番ファイルの入力と更新処理が必要となる。部下処理の内容は「Call  部下11(注文番号採番)Sec」が注文番号採番ファイルへの出力項目、「Call  部下12(顧客コードセット)Sec」〜「Call  部下16(注文番号セット)Sec」が注文マスターへの出力項目としている。
【００５４】
また図１７では子モジュールの上司プログラムフロー（発注処理モジュール）を示しているが、実際の子モジュール呼出し命令は親モジュールの「部下５（子モジュール）Sec」で発行される。図１８を参照されたい。
（３）「子モジュール呼出」の部下プログラムフロー
部下５の「子モジュール呼出」のプログラムフローは図１８となる。特徴はプログラムフローの第２番目の命令内容が「子モジュールをCall」するとなっていることである。なお、親モジュールと子モジュールの各部下プログラムは図１０と同形のプログラムフローである。
２章  Lyeeプログラムの基本形
１章では上司・部下の役割を例にLyeeプログラムの特徴を説明した。この章では      上司プログラムの「完了判断」や部下プログラムの「完了報告」等をプログラミン      グ可能なフローに展開し、Lyeeプログラミングの基本形を説明する。なお上司・部下プログラムのプログラミング方法（テクニック）はいろいろ考えられるが、ここでは単純明快な方法で説明する。
上司／部下プログラムのプログラミング方法
Lyeeプログラムの基本形は上司プログラムと部下プログラム群で構成される。この章では業務アプリケーション機能（業務要件）である計算や条件、値のセット等についてのプログラミング方法をフロー図などで説明する。
２．１．１  仕事の単位
上司は部下に「仕事」を細分化して割当てる。Lyeeプログラミング方法の第１の課題は、この「仕事」の‘単位’をどう決定すれば良いかである。
【００５５】
プログラムの処理は一般的に「入力された情報」をもとに「計算・判定・加工」等の業務アプリケーション処理を行い「情報を出力」することである。
【００５６】
このことから、Lyeeプログラムでの「仕事」の‘単位’は、計算・判定・加工の結果である「出力情報」に所属している項目を「仕事の単位」とする。
【００５７】
なお、仕事の単位は出力項目群とすることも考えられるが、この「群」をどのようにするかなどの問題があり、単純明快とはいえない。仕事の単位は出力項目と決めたことにより、上司プログラムの作業指示の単位と各部下プログラムの単位も一意的に決ったこととなる。また、稼動可能なプログラムは業務アプリケーション機能以外に入出力機能なども必要となる。この「仕事の単位」については２部２章や３章を参照されたい。
【００５８】
図１９の購入金額計算画面の例では出力項目が３個とすると表２の３個が「仕事の単位」となり、部下プログラムの単位ともなる。
【００５９】
【表２】
2008171023.tif 000004
２．１．２  上司プログラムの完了判定の方法
次に１章で述べた上司プログラム機能の中での「完了判定」を、プログラミングとしてどう具体化するかを説明する。
【００６０】
上司プログラムの「完了判定」は、「仕事」の「完了」状態を記録させ、この記録されている内容を判定することで完了判断を行う方法とする。なお、成果物（出力内容）を判定することでも完了の判断は可能である。しかしこの方法は成果物内容に依存した判断も必要となるため、単純化を目指したプログラミングの自動化には適さない。
【００６１】
記録させる領域名を「業務実施フラグ」とすると、上司プログラムのフローは図２０となる。また完了状態の記録（具体的には「業務実施フラグ」）内容の適切な設定で上司プログラムの無限ループの発生は起こらない。なお、同図中、無限ループの回避策は下記の「完了判断の方法」において、(二)で「完了」と判断するため、上司プログラムの無限ループが回避できる。詳しくは巻末の参考資料１「無限ループ防止仕様の詳細説明」を参照されたい。また、「初期処理」は、一般的なファイルのOpen、領域の初期設定（例  業務フラグをOn）等の処理である。
【００６２】
また、完了判断の方法としては、次のいずれかになる。
【００６３】
(一)未完了：「業務実施フラグがOn」
どれかの部下プログラムで処理が行われた（成果物ができた）ことを意味する。この成果物を利用し「まだ処理が為される可能性」がある。よって処理は「未完了（中途）」と判断する。
【００６４】
(二)完了：「業務実施フラグがOff」
どの部下プログラムでも処理が為されなかった。すなわち成果物は出来なかった。このことは何回全ての部下プログラム処理をCallしても「新たな成果物は出来ない」ことを意味する。よって処理は「完了」と判断する。
【００６５】
さらに、終了処理はファイルのclose、Commit/Rollback等の処理である。
２．１．３  部下プログラムの業務遂行の判定方法
次は、部下プログラムのプログラムフロー第１番目の命令である「業務遂行の判定」をプログラミングとしてどう具体化するか説明する（図２１）。
【００６６】
プログラムフローの第１番目の判定命令で行わなければならないことは「業務遂行ができるか否」か、或いは「業務遂行をすべきか否か」である。
【００６７】
これを具体化すると、判定内容は表３に示すように、以下の３項目が必要となる。
【００６８】
(一)適切なデータが揃ったか。ここで、いままでは「必要なデータ」と述べてきたが、厳密には「適切なデータ」である。計算等を行うにあたって「適切なデータ」でない場合は部下プログラムフローの第２番目の処理は実施できない。具体例は次のとおりである。
【００６９】
＜例＞1  割り算での分母が「０」の場合：Ｄ＝Ｅ÷Ｆで「Ｆが０」の場合は計算ができない。
【００７０】
2  数値の加算でデータ値がNullの場合：Ａ＝Ｂ＋Ｃで「Ｂがnull値」では計算ができない。    
(二)既に「仕事」は実施済みか。
【００７１】
(三)業務遂行をする必要があるか（業務要件）。
【００７２】
【表３】
2008171023.tif 000005
なお、同表中、「データは定義域内か」に関しては、ある関数ｙ＝Ｆ（ｘ）でｘがある範囲内でないと成立しないことを意味する。上記で述べた２つの例はこのことの具体例である。
【００７３】
部下プログラムの業務遂行判定の具体的方法は以降順次説明するが、例示すると図２２となる。「xxxxフラグ」は後に説明するが、完了状態を記録する項目（領域）名である。
「適切なデータが揃ったか」の判定方法
表３の判定項目１番目の「適切なデータが揃ったか」の対象となるデータ項目は、例えば“金額＝数量×単価”では「数量」と「単価」である。一般的には“y=f(ｘ)”の変数「Ｘ」が「適切なデータ」の対象項目（簡便的には計算式の左辺の項目）である。具体例は表４に示されたものである。なおここで、定数（Ａ＝１０の「１０」、IF  Ｂ＞０の「０」）は「適切なデータ」の対象外である。
【００７４】
【表４】
2008171023.tif 000006
では、この対象となった「データ項目」は何をもって「適切」と判断するか、が次の課題である。「適切なデータ」の判断は
(一)データの値が「ある」だけを判断する場合
(二)データの値が「あり」かつその値は定義域内でなければならない場合
の２ケースが考えられる。なおここで(二)において、定義域内とは表３のところで述べた注意事項を参照されたい。
ア  データ値の「あり」を判定する方法
データ値が「ある」とは、入力されてデータ値が得られたり、計算や値のセットがなされたことによりデータ値が得られた状態である。なお、ここではデータ値の内容については問わない。
【００７５】
この判定はいろいろな方法（当該項目の「初期値」を判定する方法もあるが処理内容に依存するケースが生じ、単純明快な方法とは言えない。）が考えられるが、Lyeeプログラムの自動化を図るため、各データ項目のデータ値の「あり／なし」状態を領域に記録させ、この記録されている内容によりデータ値の「あり／なし」を判定することが単純明快である。
【００７６】
具体的には表５上段のように各項目毎に「xxxx完了フラグ」を設定し、入力処理完了後や計算や値のセットがなされた後に「セット完了」情報を記録する。項目値のセットが未完了の場合は「完了フラグ」は「Off」、項目値のセットが完了した場合は「完了フラグ」は「On」と記録する。このことで「データ値あり」判定は表５の下段となる。
【００７７】
【表５】
2008171023.tif 000007
なお、同表中、「購入数量入力完了フラグ」とは、入力項目の「項目入力完了フラグ」をOnとする処理個所は２部２章Lyeeプログラムの入出力処理で説明する。
イ  データ値が「定義域内」であるかを判定する方法
データ値が「定義域内」であるかを判定する方法は、部下プログラムの２番目の命令である計算式や使用する関数等の内容により決るため、それに合わせ判定内容を記述する必要がある。なお(一)「Null」値では数値計算不可や(二)割り算での「分母が０」は不可、などが共通的な内容として「定義域内」か否かの判定の項目である。
【００７８】
【表６】
2008171023.tif 000008
（２）「既に実施済か」の判定方法
表３の判定項目の２番目は、当該仕事である「値のセット」や「計算」等が「既に実施済みか」否かを判定する。
【００７９】
この判定のプログラミング方法は前記（１）と同じく「xxxx完了フラグ」方式で実現可能である。すなわち、仕事の「実施済」状態を「完了フラグ」に記録させ、この記録されている内容により実施済を判定することが単純明快である。
【００８０】
具体的には「出力項目ｘｘ」についての「完了フラグ」を用意し、初期状態は当該フラグを「Off」とし、計算やセット等が実施されたら当該フラグを「On」と記録する。なお、このOn/Offのセットの仕組みにより、当該項目の処理は１度しか実行されない。この部下プログラムでの「既に実施済み」の判定と２．１．４の「完了報告」により上司プログラムの無限ループは防止される。無限ループ防止については詳細は参考資料１を参照されたい。
【００８１】
【表７】
2008171023.tif 000009
（３）「業務遂行をする必要があるか（業務要件）」の判定方法
表３の判定項目の３番目は「業務遂行の必要性」を判断する。これは一般的な業務要件に該当し、出力項目ｘについての「業務的な条件」がある場合に設定する。このため具体的内容は各業務要件により決まる。表８はその具体例である。
【００８２】
【表８】
2008171023.tif 000010
２．１．４  部下プログラムの「完了報告」方法
部下プログラムの説明の最後は部下プログラムフローの第３番目の命令である上司への「完了報告」である。この「完了報告」をどうプログラミングするかを説明する。
（１）「業務完了」の記録
仕事の「完了報告」は前述の「２．１．２  上司プログラムの完了判定の方法」に対応させる必要がある。部下プログラムの「完了報告」方法は部下プログラムの第３番目の命令で「業務実施フラグ」を「On」と記録する。これにより、上司プログラムもまたこの「業務実施フラグ」をチェックすることで部下に割り当てた仕事の完了判断ができることとなる。
（２）当該項目の「既に実施済み」の記録
また「２．１．３（２）‘既に実施済か’の判定方法」で述べた当該項目の処理完了記録も部下プログラムフローの第３番目の命令群で実行しておく。具体的には当該項目の「セット完了フラグ」を「On」とする。以上をまとめると部下プログラムのフローは図２３となる。なお、同図中、「出力項目ｎの業務的条件」は、業務的条件はOr、Andや＝、≠、＜、＞等、使用言語で記述可能な判定識別子を使用して記述する。
Lyeeプログラムの領域
Lyeeプログラムの領域は一般的なデータ領域の他、Lyeeプログラムに特有な領域として、前述の各種完了情報を記憶する「フラグ」を制御情報として設定する必要がある。図２４に示す。
２．２  具体例：購入金額計算プログラム
やや抽象的にLyeeプログラミングの方法を説明して来たが、具体例でその内容を        確認されたい。
２．２．１  購入金額計算のプログラムフロー
（１）画面と業務要件
画面と業務要件は以下（図２５及び表９に示されるとおり）とする。単価は商品マスターを読むことで得られるものとする。
【００８３】
【表９】
2008171023.tif 000011
（２）Lyeeプログラムの全体構成
Lyeeプログラムの領域と命令の構成は以下となる。
ア  領域の構成
【００８４】
【表１０】
2008171023.tif 000012
イ  命令の構成
【００８５】
【表１１】
2008171023.tif 000013
（３）上司プログラムのフロー
上司プログラムの処理内容は以下の(一)〜(八)となる。(三)〜(六)は業務処理が完了するまで繰返される。フロー図は図２６である。
(一)初期処理：制御情報の各フラグのOff、業務実施フラグのOn、ファイルOpen等を行う。
(二)入力処理：画面情報入力、商品マスターReadを行う
(三)業務処理：完了判定
業務実施フラグがOn：(四)以降を実施
業務実施フラグOff：画面出力処理へ遷移
(四)業務実施フラグをOffとする。
【００８６】
(五)各出力項目処理sec（購入金額の計算、単価の決定、割引率の決定）の実行
(六)「(三)」に移る
(七)出力処理：画面へ処理結果を出力する。
(八)終了処理：ファイルClose等を行う
なお、同図中、「初期処理」は、領域の初期化、Open等を行う。「入力処理（画面入力、商品マスターRead）」に関して、Lyeeプログラミング特有の入出力処理方式については第２部２章参照されたい。「割引率」については、割引率は０％のセットと２０％のセットの２処理があるので部下プログラムsecを２個用意する。
（３）部下プログラムのフロー
部下プログラムは図２７〜図３０の４個である。それぞれは図２３の基本形と同型である。
【００８７】
割引率セットの業務要件‘購入数量「１９以下」は０％、「２０以上」は２０％’は、第２命令が条件により異なるため、２個の部下プログラムを用意する。この場合、「If  xx  Then  yy  Else  zz」でも可能であるが、部下プログラムフローを同一形態とするためや、プログラムの自動生成の実現に寄与するため、部下プログラムを複数個作成することとする。
【００８８】
なお、図２７中の「実施条件判定」は以下をいう。すなわち、
If  購入数量入力完了フラグ＝On
And  商品単価セット完了フラグ＝On
And  割引率セット完了フラグ＝On  
And  購入金額セット完了フラグ＝Off
２．２．２  計算が完了する順
購入金額計算プログラムが実行され、上司プログラムや部下プログラムの完了されていく順や購入金額が計算される状況は１章の図９と同様となる。
２．３  まとめ
たいへん簡単な例ではあるが、これがLyeeプログラムの基本形となる。たかだか３項目の出力で、各種フラグを用意したり、かなり面倒なことしている印象を与えるかもしれないが、しかし、この位でないと順序性を考慮しないプログラムはできないという側面もある。
【００８９】
２部ではより実際的な、Lyeeプログラムの入力出力処理方法等を説明するが、入出力処理方法等は、この章で説明した「完了判定方式」を「多段階」の入れ子構造に拡張した構成としただけである。１部２章で説明した内容が基本であり、２部の内容はこれを「応用しているだけ」であることの認識で読み進めていただきたい。
２部  Lyeeプログラム生成機能を使ってのシステム開発方法
１部ではビジネスロジックの画期的な開発の仕方であるLyeeプログラムの特徴を説明した。２部ではLyeeプログラムがシステム開発の実務上どこに位置付けられかや、自動プログラミングが可能となるための入出力処理やプログラムの内部モジュール作成を説明する。
１章  Lyeeプログラムの役割とシステム開発方法
１．１  システム構築方法：ＭＤＡ
システムを構築する際には、いろいろな構築方法が提唱されている中で最適な方法を利用し構築することとなる。ここでは、ＯＭＧ（Object  Management  Group）で提唱しているＭＤＡ（Model  Driven  Architecture：モデリング駆動型アーキテクチャ）に添いLyeeプログラムの役割を特定し、Lyeeプログラミングを前提としたシステム開発方法の考え方を説明する。
【００９０】
ＭＤＡはいくつかの標準的な技術仕様を体系化した方法論である。ＭＤＡで規定している機能体系を簡潔に要約すると図３１となる。すなわち(一)通信関連インターフェースを担う「ウエブインターフェース機能」(二)業務と利用者とのインターフェースを担う「利用者インターフェース機能」(三)当該業務処理を行う「業務アプリケーション機能」(四)共通的な処理を担う「共通ルーチン機能」の４機能となる。
【００９１】
またこの機能構成を基本とし、企業内や企業間の全体的なシステムを関連つけた構成としては図３２となる。これは図３１を１つのローカルなシステムと位置付け、全体のシステムはこれらをネットワークで繋いだイメージとなる。各要素内容は次のとおりである。
【００９２】
(一)Ｗ：ＷＥＢ機能
(二)Ａ：業務アプリケーション機能や利用者インターフェース機能
(三)Lib：共通ルーチン等のライブラリー機能
(四)I/O：データベース等の入出力機能
１．２  Lyeeプログラムの役割
LyeeプログラムはMDAの機能体系では業務アプリケーション機能を実現する役割を担う。稼動可能なLyeeプログラムはウェブインターフェ−ズ機能や利用者インタフェ−ズ機能、共通ルーティン（データベース、数値アルゴリズム等）機能を利用し、使用するプログラム言語に従うコードで業務アプリケーション機能を作成することとなる。
１．３  Lyeeプログラムの業務アプロケーション要件の記述方法
業務アプロケーション要件の記述方法についてLyeeプログラムは、そのプログラム構造から、データを定義するのと同じ感覚で業務要件を記述できる。表１２は１部２章２．２の購入金額計算プログラムの業務要件である。
【００９３】
【表１２】
2008171023.tif 000014
ＭＤＡではシステムの稼動基盤に独立なモデル（PIM：Platform  Independent  Model）と、稼動基盤に依存したモデル（PSM：Platform  Specific  Model）の２区分を規定している。Lyeeプログラムの業務アプリケーション機能の要件記述方法は表１．３のように、データを定義するのと同様であり、データは稼動基盤により変化するものではない。このため、Lyeeプログラムの業務アプリケーションの要件記述方法は、稼動基盤に独立した記述モデルと位置付けることができるためＭＤＡのPIMに該当する。
１．４  システム開発方法
ウオータフォール型のシステム開発はシステム化計画や基本設計を行い、外部仕様や業務要件等を確定しプログラミングおよび稼動確認の順実施される。プロトタイピング型のシステム開発はプログラムを作成しながら、その内容の確認と修正を繰返し、システムを完成させる手順で行われる。
【００９４】
Lyeeプログラムの開発手順は、外部設計で決った入出力仕様（画面レイアウトやファイルレイアウト情報）と内部設計で決めるデータ項目毎の業務アプリケーション情報をリポジトリに蓄積する。これらの情報とモジュール構造情報や入出力命令（SQL文など）を入力しLyeeプログラム生成機能を使い（2005年４月現在、Lyeeプログラム生成機能はカテナ社の「LyeeALL」が販売されている。）稼動環境にあわせたプログラミング（ソースコードは１００％自動生成）を完了させる。そして単体テストを繰返しプログラムを完成させる。
【００９５】
Lyeeプログラミングを前提としたシステム開発手順は、入出力仕様とデータ項目毎の業務要件が決ることでプログラムが作成可能であるため、ウオータフォール型開発でもプロトタイピング型開発でも適用可能である（図３３及び３４）。
【００９６】
Lyeeプログラム生成機能
Lyeeプログラム生成機能（図３５及び表１３）は以下の要素の構成で、Lyeeプログラムのソースプログラムを自動作成する。業務要件の追加変更に対応したプログラム修正もこの生成機能を使い行うことができる。このためにソースプログラムを直接修正することはない。
【００９７】
【表１３】
2008171023.tif 000015
なお同表中、雛型は上司と部下のLyeeプログラム、および領域情報より構成される。
２章  Lyeeプログラムの入出力処理
Lyeeプログラムは業務アプリケーション機能を担うが、WEBや利用者インターフェース、データベースインターフェースなどとの入出力処理を行う必要がある。この章では業務アプリケーション機能と入力処理機能、出力処理機能の３機能を独立させた構成としたLyeeプログラムを説明する。
【００９８】
なおこの例でもかなり余計で回りくどいプログラムフローとなっているとの見方もあろう。しかし、これは例題である「購入金額照会」処理固有のプログラムを作るのでなく、入出力処理を含めたソースプログラムの自動生成をいかに実現するかが目的であることを念頭に読み進んでいただきたい。
２．１  入出力処理のプログラミング方法
Lyeeプログラムの入出力処理は「入力処理命令群」と「出力処理命令群」を独立した“塊“として扱うことが特色である。以降入力処理群、出力処理群の“塊“をどうのプログラミングすれば良いのかを説明する。
【００９９】
なお、入出力処理を含むLyeeプログラムの基本構成は図３６である。
【０１００】
「初期処理命令群」では、ファイルのOpen、DＢのConnect等を行い、「終了処理命令群」ではファイルのClose、ＤＢのCommit/RollBack等を行う。
【０１０１】
入力処理の上司プログラム
（１）入力処理のフロー
通常は入力命令の発行順序を考慮してプログラミングする。これに対して、Lyeeプログラムは「変数間の関係」を斟酌せず「考慮範囲の極小化」を目指している。このため、Lyeeプログラムは各入力処理の処理順を不問とし、計算や値をセットする「業務アプリケーション処理」と「入力処理」の独立化を図るプログラム構造を実現する必要がある。
ア  入力処理と業務アプリケーション処理の完全分離
各処理の独立化を図るため、「入力処理命令群」と「業務アプリケーション命令群」の‘塊’は完全に分離する。フローで表すと以下（図３７に示すように）となる。ここでの業務アプリケーション処理とは出力領域にある値をセットしたり、ある条件により計算をしたりすることを意味している。
イ  入力命令の発行順の不問
続いて、入力命令の発行順序を考慮しないことを実現するため、業務アプリケーションの各命令群の処理順を不問とした方式と同様に、入力処理の完了状態を記録する方式を採用する。完了状態を記録する項目名を「入力実施フラグ」とすると、上司プログラムのプログラムフローは以下（図３８に示すように）となる。
ウ  入力処理と業務アプリケーション処理の連携方法
入力処理の‘塊‘と業務処理の’塊‘は分離したが、この塊をどのように連携させれば良いかが次の課題となる。
【０１０２】
一般的には「ある入力命令」が実行され、入力されたデータにより業務アプリケーション処理が実施できる。業務アプリケーション処理が実施できたことにより、更に入力命令が実施できる可能性がある。これを繰返し、必要な全ての入力処理の完了まで続ける。入力処理と業務処理の塊の連携はこの考え方に基づく。これをプログラムフロー化すると図３９となる。
（２）入力処理群の完了判定方式
入力処理命令群の完了判定方法は業務アプリケーション処理と同様に、入力処理の「完了」を記録し、この記録内容により完了を判定する。
【０１０３】
具体的には入力完了記録の項目名を「入力実施フラグ」とし、このフラグが「On」の場合は未完了（まだ入力処理は実施可能）、フラグが「Off」の場合は完了（これ以上入力処理は無効である）と判断できる。なお入力処理群での無限ループの回避策は業務処理の回避策と同様の論理で可能となる。（参考資料１「無限ループ回避の詳細説明」参照）
（３）入力処理群の完了判定後の制御の遷移
ア  入力処理群が未完了
入力処理群の処理が「未完了」の場合はまだ入力処理を実施する必要があるため、制御は入力処理の命令群へ制御を移す。ここでの入力処理の前提として、１回実施された入力処理は再び入力処理は実行しないとしている。なおバッチ処理等で入力ファイルをEOFまで繰返し読む場合等のように入力処理を繰返す必要がある処理の実現方法は３章の３．４．２「自モジュール処理の繰返」を参照されたい。
イ  入力処理群が完了
入力処理群の処理が「完了」の場合は既に業務処理も完了しているため、制御は出力処理へ遷移する。
（４）具体例
購入金額計算画面（図４０）を例にLyeeプログラムの上司プログラムの入力処理と業務処理のプログラムフローをまとめると図４１となる。
【０１０４】
なお、図４１において、入力処理の部下プログラムで入力命令が実行されると「入力実施フラグ」をOnとしている。また、入力順を考慮不要を強調するために、意図的に「商品マスター入力」を先頭にしている。
【０１０５】
入力処理の部下プログラム
入力処理の部下プログラムは、業務アプリケーション処理の部下プログラムと基本は同型であるが、入力命令実行結果により内容が異なる。具体的にはReadやSelect等の入力命令が正常終了した場合は必要となる入力項目が得られたので、入力完了情報の記録のため「フラグ」類を「On」とする。入力処理の部下プログラムフローは図４２となる。
【０１０６】
なお、同図中、「入力命令を実施すべきか」とは、具体的には、
1  If    商品マスター入力処理実施フラグ＝Off  
2  Ａnd  検索キーの商品名セット完了フラグ＝On  である。
【０１０７】
また、「商品単価入力完了フラグをOn」について、この例では「入力完了フラグ」のセットは１項目となっているが、入力命令で複数項目を得る場合はおのおのの項目の「完了フラグ」をOnとする必要がある。
【０１０８】
留意点はプログラムフローの第一番目の命令の「入力命令実施」判定の内容である。判定内容は表１４の３点に該当する項目を考慮する必要がなる。
【０１０９】
【表１４】
2008171023.tif 000016
２．１．３  出力処理の上司プログラム
出力処理は、入力処理と業務アプリケーション処理が全て完了した後で実行する。出力処理の上司プログラムのプログラム構成（図４３）はLyeeプグラム全体の同型性を保持するため、「上司/部下」のプログラム構成とするが、出力「完了」判定や繰返し処理は行わない。
【０１１０】
以上をまとめると上司プログラムの入力処理、業務アプリケーション処理、出力処理のプログラムフローは図４４となる。
２．１．４  出力処理の部下プログラム
出力処理の部下プログラムはWriteやInsert、Update、Delete等の出力命令を記述するが、その前段として出力命令を実施すべきか否かの判定を行う。出力処理の部下プログラムフローは図４５となる。
【０１１１】
なお、出力処理の上司プログラムでは「完了」判定は必要でないため、「完了情報（フラグ）」のセットは基本形としては行わない。また、「出力命令を実施すべきか」に関して、具体的な出力遂行判定は、
(一)If  単価セット完了フラグ＝On
(二)And  商品コードキー値セット完了フラグ＝On  である。
【０１１２】
一般的には、
(一)If  各出力項目のセット完了フラグ＝On
(二)And  更新、削除キー項目セット完了フラグ＝ON
(三)And  出力業務条件に合致か    となる
２．２  具体例：購入金額照会プログラム
具体例で入出力処理を含んだLyeeプログラムのフローを確認する。
２．２．１  処理概要
商品名、購入数量を入力し、割引率、消費税を加味した購入金額を表示する。
２．２．２  画面
図４６の画面とする。
２．２．３  データベース
検索するデータベースは商品マスターとし、所属項目は簡単に表１５とする。
【０１１３】
【表１５】
2008171023.tif 000017
２．２．４  業務要件
業務要件は表１６とする。
【０１１４】
割引率は購入数量と購入価格により異なることとする。
【０１１５】
また商品マスターに商品名が無い場合はメッセージを出力することとする。
【０１１６】
【表１６】
2008171023.tif 000018
購入金額照会処理のプログラムフロー
上司プログラムのプログラムフローは図４７となる。いままで説明しているようにプログラム構造は入力処理と業務処理が独立の“塊”となり、「入れ子」構造となっている。
初期処理の内容
一般的プログラムの初期処理と同様にトランザクションの開始、ＤＢへのコネクト、ファイルOPENを行う。また、Lyeeプログラムの固有処理としては制御情報の初期化を行う。制御情報の項目名と初期化内容は表１７である。
【０１１７】
【表１７】
2008171023.tif 000019
上司プログラム
図４７に示す。なお、「初期処理」は領域初期化やトランザクション開始、Lyeeプログラム特有のフラグ類の初期化を行う。また、業務処理については、入力される「購入商品名」と「購入数量」の内容は出力しないものとした。出力する必要がある場合は該当の部下プログラムを作成し、上司プログラムよりCallする必要がある。
（３）入力処理の部下プログラム
商品マスター入力secや画面入力secのプログラムフローは以下（図４８〜４９）である。
業務アプリケーション処理の部下プログラム
各業務アプリケーション処理の部下プログラムのフローは第１部２章の部下プログラムフロー図２．１８〜図２．２１と同型である。
【０１１８】
なお割引率２０％セット条件は「購入数量」２０個以上または「購入価格が１万円」以上が与件なので、フローの第１番目の判定は図５０と「Or」判定が加わったものとなる。
（４）出力処理の部下プログラム                                      
画面出力セクションのプログラムフローは以下（図５１）である。  
（５）終了処理
一般的なプログラムの終了処理と同様、必要に応じトランザクションのコミット/ロールバック、ファイルClose等の処理を行う。
２．３  まとめ
入出力処理を含めたLyeeプログラムフローの説明は以上である。要点としては以下の３点に要約できる。
(一)Lyeeプログラムは入力処理と業務処理、出力処理を独立化した‘塊‘とする。入力処理は業務処理を「入れ子」とする２重Loop構造をとる。
(二)入力処理群の完了判定後は以下となる
未完了の場合は、再度入力処理群へ制御を移す。
入力処理群が完了した場合は、出力処理へ制御を移す。
(三)出力処理では完了判定は行わないが、Lyeeプログラムの同型性を保つため上司/部下プログラムの構成とする。
３章  Lyeeプログラムの複数モジュール構成
この章ではプログラムの内部モジュールが複数となる場合のLyeeプログラミングを      説明する。これで実際のシステムで使用可能なLyeeプログラムが作成できる。
【０１１９】
なお稼動可能なプログラムやプログラム生成機能を作成する場合はJava、Cobol      等の言語文法や特性、稼動環境インターフェース規約を考慮しソースプログラムを      作成する必要があることは言うまでも無い。
３．１  Lyeeプログラムの複数モジュール化
第１部１章の図１．１４〜図１．１７で「複数モジュール対応のLyeeプログラム構成」の考え方を説明した。これをプログラムとしてどう実現するかを順次説明する。
【０１２０】
モジュールとは、一般的にプログラムを開発する場合、画面や帳票毎とかイベント毎とかをプログラム作成の単位とする。通常この決められた単位を更に機能的に分割して「ある塊」を作成する。この「塊」の呼び方はモジュール、セクション、サブプログラム、関数、オブジェクト等いろいろある。以降この「塊」を単にモジュールと呼ぶ。プログラムを更に分割した塊なので「内部モジュール」と呼ばれることも多い。（サブルーチンやオブジェクト等もLyeeプログラムで作成できることは言うまでもない。）
モジュールは機能的な「塊」として作成されるが、ここでの説明はLyeeプログラムの構造的な考えに従い「塊」を作成することとする。この目的は自動的に「モジュール構成」を決めることにある。（Lyeeプログラムのモジュールも保守容易性や企業の伝統的なモジュール化の考え方等を考慮して作成可能である。このことは現実的で実務的でもある。）
３．１．２  Lyeeプログラムのモジュールの機能
Lyeeプログラムのモジュール機能は前章までの(一)初期処理、(二)入力処理、(三)業務アプリケーション処理、(四)出力処理、(五)終了処理の５機能に(六)「モジュール制御」機能を加えた６機能で構成する。
【０１２１】
また領域構成は複数モジュール構造化により、モジュール共通領域と各モジュールの固有領域に分ける（図５２及び表１８）。
【０１２２】
Lyeeプログラムのモジュールは図５３の階層構造で複数モジュール化を実現する。「親モジュール」から「子モジュール」、「子モジュール」から「孫モジュール」等の呼び出しと戻り（Call/Return）の制御はモジュール制御命令群が担う。
【０１２３】
【表１８】
2008171023.tif 000020
３．１．３  モジュール分割基準（プログラムをどのような単位で作成するかは、与えられた稼動環境等により異なる。ここではプログラムの単位は「画面」毎とか「イベント」毎とかに決った後のこととして説明する。）
Lyeeプログラム内のモジュール分割の基準は次とする。(一)は一般的であるが(二)の入出力件数区分はLyeeプログラムの構造上およびプログラムの自動生成を容易に実施するためのモジュール分割基準である。この基準に従いプログラムのモジュール分割を行う。
(一)処理（イベント）・機能区分
(二)入出力件数区分
入出力件数単位とは、入力または出力が「１件」か「複数件」の処理かで区分する。
３．２  具体例：注文画面処理プログラム
「注文画面」処理の具体例でLyeeプログラムのモジュール分割とプログラムフローを概観する。
３．２．１  処理概要
画面遷移や各ボタン押下時の処理は以下（表１９に示すとおり）である。
【０１２４】
【表１９】
2008171023.tif 000021
３．２．２  画面
図５４の画面とする。
３．２．３  ファイル
検索や更新するファイルは表２０とする。
【０１２５】
なおログイン時に顧客コードが得られ「引継ファイル」にその情報が格納されているとする。ファイル編成は「引継ファイル」は順編成（テキスト）ファイル、他はデータベースとする。
【０１２６】
【表２０】
2008171023.tif 000022
３．２．４  業務要件
業務アプリケーションの処理要件は表２１とする。
【０１２７】
【表２１】
2008171023.tif 000023
３．２．５  モジュール構成
（１）プログラムの単位
プログラムをどのような単位で作成するかをまず決めておく必要がある。ここでは画面単位にプログラムを作成するとする。（イベント単位でプログラムを作成する場合は各イベント内でのモジュール構成の検討となる。また複数画面をまとめて１つのプログラムとする場合は複数画面をまとめたモジュール構成の検討となる。）  
（２）注文処理のモジュール分割
ア  注文画面の処理の単位（以降イベントと呼ぶ）は以下となる。
(一)初期起動
(二)金額計算ボタン押下
(三)発注ボタン押下
(四)クリアボタン押下
(五)戻るボタン押下
イ  (一)〜(四)に共通している機能は画面の入出力処理であるため、まず画面の入出力処理を親モジュールとする。
【０１２８】
ウ  (四)と(五)の処理は親モジュールで処理可能なので、子モジュールは作成しない。
【０１２９】
エ  初期起動処理の顧客名を表示する処理は顧客マスターを１件読むので「１件処理」、購入商品コンボBoxの商品名表示処理は商品マスターの「複数件処理」である。        モジュール分割基準の入出力処理の「１件／複数件」区分に従い初期起動処理の        子モジュールは２モジュール構成となる。
【０１３０】
オ  金額計算処理は商品マスターを１件読めば良いので子モジュールは１モジュール
構成となる。
【０１３１】
カ  発注処理は各ファイルの１件「Select」処理や１件「Insert」処理のため子モジュールは１モジュール構成となる。
（３）モジュール構成
上記の検討より、モジュール構成は表２２となりこれを図示すると図５５となる。
【０１３２】
【表２２】
2008171023.tif 000024
３．２．６  各モジュールのプログラムフロー
上司プログラムのフロー
各モジュールの上司命令群は参考資料２プログラムフロー参照（表２３）。
【０１３３】
【表２３】
2008171023.tif 000025
（２）部下プログラムのフロー
「モジュール制御処理」のプログラムフローは参考資料２プログラムフロー参照（表２４）。
【０１３４】
なお、繰返：商品マスターを複数件読み、コンボBoxへ複数件出力することのためである。詳しくは３．３．２「自モジュール処理の繰返」参照。
【０１３５】
【表２４】
2008171023.tif 000026
３．３  モジュール制御を含んだ上司プログラム
一般的な内容でモジュール制御を含めたプログラムフローを説明する。
３．３．１  モジュール制御機能
モジュール制御機能は一般的なプログラムと同様まず以下が必要である。
【０１３６】
(一)「子モジュールへの遷移」
(二)「親モジュール（呼び元）へ戻る」
これに１プログラム１モジュール構成も考慮し、プログラムの制御機能として以下を加える。
【０１３７】
(三)「他プログラムへ遷移」
(四)「プログラムの終了」
これらの次にLyeeプログラム特有の５番目の機能を加える。その内容は例示の注文画面の購入商品コンボBoxの出力処理ファイルや全レコードを読むバッチ処理などのように、「入力処理と出力処理」を繰返す「複数件処理」が可能となるモジュール制御機能である。
「複数件処理」は当該モジュール内の入力処理、業務アプリケーション処理、出力処理の一連の処理を繰返し、処理終了条件（例えば全レコード読み込み完了）に合致するまで繰返すこととなる。
【０１３８】
(五)「自モジュール処理の繰返」
以上がLyeeプログラムのモジュール制御機能で、一覧表にまとめると表２５となる。
【０１３９】
【表２５】
2008171023.tif 000027
３．３．２  自モジュール処理の繰返
「自モジュール処理の繰返」はLyeeプログラム特有の機能であり、図５６のように画面に「複数行」表示する場合や入力ファイルを１件読み、処理結果を１件出力する、２件目も同様に処理し、これを入力ファイルの全レコードについて行うような場合に適用する。
３．３．３  「自モジュール繰返」機能を加えた上司プログラム
「自モジュ−ル処理の繰返」機能を追加したLyeeプログラムの上司プログラムは図５７のコーデング例となる。プログラムフロー図は参考資料２の図２．１１参照。
【０１４０】
なおモジュール内の「初期処理」は以下の２区分に分けることとする（表２６）。
(一)初期処理１：モジュール起動時の１回だけ行う処理
(二)初期処理２：「自モジュ−ル処理の繰返」の繰返処理ごとに実行する処理  
【０１４１】
【表２６】
2008171023.tif 000028
３．３．４  各モジュール制御機能の適用優先度
５種類のモジュール制御機能の適用順序はそれぞれの機能を考慮し、優先度に従ったプログラミングをする必要がある。ここはプログラムの順序性を考慮しソースプログラムを作成する。
（１）「他プログラムへ遷移」や「プログラム終了」
この条件が発生したら、すみやかに「他プログラムへ遷移」や「プログラム終了」処理を行い、当該プログラムは処理完了として良いので、他のモジュール制御機能に比べ適用順位は１位である。
【０１４２】
なお、実際のコーデングでは整形する必要があるが、処理を再開する点は業務処理からである。
（２）「親モジュールへの戻り」
この条件は自モジュールの処理が全て完了した段階（完了とは出力処理が終わったか、繰返し処理の終了条件に合致したかで判断する。）で処理する必要があるため、適用順位は最下位となる。
（３）「子モジュールへ遷移」と「自モジュール処理の繰返」
「自モジュール処理の繰返」の条件は、子モジュール処理が全て完了した後に「繰返処理」が行われる必要がある。このため、「子モジュールへ遷移」処理が「自モジュール処理の繰返」処理より適用順位は高い。
【０１４３】
これらをまとめるとモジュール制御機能内での適用順位と適用条件は表２７となる。
【０１４４】
【表２７】
2008171023.tif 000029
３．３．５  モジュール制御処理の内容
モジュール制御命令群の処理開始は、一連の「入力処理と業務アプリケーション処理」が完了し、これ以上入力処理が行われない時点である。モジュール制御処理機能は表２５の５種類である。
【０１４５】
処理内容は機能どおりであるが、処理完了後の処理をどうするかに留意する必要がある。
例えば、複数の子モジュールがあった場合は「子モジュール１を実行後、親モジュールの業務処理と入力処理を行い」次ぎに「子モジュール２を実行しその後、親モジュールの業務処理と入力処理を行う」処理内容とする必要があることである。この理由は子モジュール実行後に親モジュールとして何らかの処理が実施できる可能性があるため、それを実施しておくことにある（表２８）。プログラムフローは図５８のコーデング例を参照されたい。
【０１４６】
【表２８】
2008171023.tif 000030
モジュール制御機能を含めた上司プログラムのコーデング例は図５８となる。プログラムフロー図は参考資料２の図２．１２参照。
【０１４７】
但し、図５８で、「２．Call  初期処理１」は、当該モジュール処理を繰返す毎に領域を初期化する内容は「初期処理２」、当該モジュールが起動した時のみ領域を初期化する内容は「初期処理１」で行う。
【０１４８】
モジュール制御処理の部下プログラムのフローは今までのフローと同様であるが、内容は２種類ある（表２９）。
【０１４９】
【表２９】
2008171023.tif 000031
子モジュールへ遷移の部下プログラム
子モジュールへ遷移する部下プログラムは子モジュール遷移条件に合致したら、実際に「子モジュールへ遷移」する。また子モジュールから戻った場合「モジュール制御実施フラグをOn」とするなど各種制御情報の記録を行う（図５９）。
【０１５０】
但し、同図において、「子モジュールＸへ遷移すべきか」については、モジュール制御遂行判定は以下である。
【０１５１】
If    (1)モジュール制御実施フラグ＝Off
And  (2)当該モジュール制御Ｘ実施フラグ＝Off
And  (3)モジュール制御の業務条件（業務条件例：「戻るボタン」押下  等）  
３．４．２  子モジュール遷移以外の部下プログラム
子モジュール遷移以外のモジュール制御部下プログラムは情報をセットするだけを行い、上司プログラムで「自モジュールの繰返」等のモジュール制御機能の実現を図る（図６０）。
【０１５２】
但し、同図において、「モジュール制御情報をセットすべきか」については、モジュール制御遂行判定は以下である。
【０１５３】
If    (1)モジュール制御実施フラグがOffか
And  (2)当該モジュール制御Ｙ実施フラグがOffか
And  (3)モジュール制御の業務条件（業務条件例  「戻るボタン」押下  等）  
また、「遷移先他プログラム名セット」はモジュール制御が「他プログラムへ遷移」で条件に合致する場合、「自モジュール繰返しフラグ＝On」はモジュール制御が「自モジュール繰返」で繰返し条件合致する場合である。
３．４．３  制御情報（データ領域）
モジュール制御のための制御情報（データ領域）は、モジュール制御を完了したか否かの情報を管理するモジュール制御実施フラグや自モジュール繰返しフラグ、他プログラムへ遷移する場合の遷移先モジュール名等５種類を用意する（表３０）。
【０１５４】
【表３０】
2008171023.tif 000032
但し、同表中、「各モジュール制御実施フラグ」について「Ｎ」とは、Ｎはモジュール制御の部下プログラムの数となる。
４章  システム開発上の効果
Lyeeプログラムのプログラミング方法の特徴や説明を行って来たが、ここでは「は      じめに」で述べたLyeeプログラムのシステム開発上の効果をまとめる。なおLyeeプログラムでシステム開発事例を参考資料３としてまとめてあるので参照されたい。
スピーデイなシステム開発
４．１．１  ソースプログラムの自動生成
前章までで説明して来たように、Lyeeプログラムは定型的なプログラム構造をしている。このため、出力項目についての計算式や条件、値のセット等の業務アプリケーション処理情報が得られれば、特定言語のプログラムソースを作成する「ソースジェネレータ」を作ることは容易に可能となる。特に「フレーム」だけでなく業務アプリケーション部分のソースプログラムも１００％できることを強調したい。
【０１５５】
なおソースジェネレータは稼動環境の各製品（OLTP、DBMS等）とのインターフェースは事前に雛型ソースを用意し、ソースジェネレータに取り込める形態となる。このため稼動環境の隠蔽やバージョンアップ対応も容易となる。（２００５年４月現在、カテナ（株）で「LyeeALL」という製品を販売しており、複数の言語や稼動環境に対応している。）
４．１．２  業務要件の稼動基盤からの独立性
Lyeeプログラムの業務要件は「出力項目」の情報を決めることと、この「出力項目」単位に計算式や条件、値のセット方法を決めることである。これは画面や帳票、ファイル内容が決定されることにより、決めることができる事項であり、かつ稼動基盤と分離独立できる（表３１）。
【０１５６】
【表３１】
2008171023.tif 000033
表３１は２部２章で使用した要件定義表であるが、このような表を作成することで要件定義が完了する。
【０１５７】
副題とした「データ指向プログラムの自動生成」の「データ指向プログラム」とは、この「表データ」＝「データ指向」＝「プログラム」という関係より命名しており、業務アプリケーションの要件をデータと同等に扱えることを意味している。
４．１．３  変数関係の順序未考慮
「出力項目」の計算式や条件、値のセット等のソースプログラムは処理順を考慮する必要がある。図６１の例では、各処理は処理順に並んでいる必要からケース１としなければならない。
【０１５８】
Lyeeプログラムはプログラムの構造上“いつか”は「ＡやＢが満たされ」結果的に「Ｃ＝Ａ＋Ｂ」の計算が行われるめ、図６１のケース１でもケース２でも処理は可能である。図６１は簡単な例であるが、項目数が多い場合や複数個の「入れ子」構成の関数と変数の関係でもそれぞれの関数式さえ明確化できれば‘いつか’は「各変数が満たされ（値がセットされ）」最終的に関数の計算が完了する。（以下のような関数でも並び順に無関係で順次値が得られることにより最終的にＹの値が得られる：Ｙ＝Ｆ（ｇ、ｈ）  ｇ＝Ｇ（ｇ１、ｇ２）  ｈ＝Ｈ（ｈ１）  ｇ１＝ｘ１、ｇ２＝ｘ２、ｈ１＝ｘ３）「はじめに」で述べた「従来の意味でのプログランミニングが不要」とはこのことを指している。
【０１５９】
この変数間の関係の処理順序を考慮しないで良いことは、プログラム作成上、プログラムの生産性や品質に多大な効果をもたらす。
品質の向上とテスト工程の削減
システム開発のテスト工程はプログラム単体のテストやファイル、画面遷移等を含めた結合テスト、総合テスト等により順次システム内容を確認し、プログラムの誤りを修正していく。Lyeeプログラムはプログラム構造が確定しているため、プログラム処理誤りが比較的少なく、かつ誤り個所の発見が容易にできる。このため単体テストのテスト期間や工数は短くて済む。
【０１６０】
なお結合テスト、総合テストの場合は画面やファイル設計等に関係している部分が多いため、プログラム単体の品質が良いことが効率化に貢献する。
４．２  保守作業の効率化
４．１で述べたプログラムのスピーデイな開発が可能なことは、プログラム保守の変更・追加作業でも効果が発揮され、作業の容易化、効率化が図られる。
【０１６１】
一般的にプログラムは標準化して作成するが、保守作業では「変更箇所の確定」や「影響範囲の調査」、「レベルダウン防止のテスト確認」などに多大な時間がかかってしまう状況である。それに加え担当者が変わることや、プログラム修正が繰り返されることで、更に作業効率は悪化する。
【０１６２】
Lyeeプログラムはプログラムが「表データ的」であり、「変数関係の順序未考慮」となっているため、要件の「変数関係」が変わるか否かしか考慮する必要が無く修正できる（表３２）。
【０１６３】
【表３２】
2008171023.tif 000034
なお、同表において、「給与明細票出力」「賞与明細表出力」に関して、社員に月々の給与明細を知らせる帳票である。プログラムの修正方法は上記以外にも考えられる。例えば新規に部長以上の処理モジュールを作成し、現在の処理モジュールは課長以下とする方式も有力である。
４．３  業務アプリケーション定義書類の削減
プログラムの業務アプリケーション定義書は、プログラム制御に係わる記述が不要となるため記述量が少なくて済み、定義書の量的な削減が図られる。
【０１６４】
また、ソースプログラムと業務アプリケーション定義書内容の同期を取ることへの多大な努力を各社行っているが、Lyeeプログラムのアプリケーション定義書は「項目名と要件」が対となっている表データ形式であるため、プログラムと定義書の同期が容易に取ることができる。
４．４  多種なフレームとの共存
第２部１章でMDAのフレームワークの中でのLyeeプログラムの機能と位置付けを説明した。LyeeプログラムはMDAで規定するＳＩＭとＰＳＭそれぞれに対応可能である。またLyeeプログラムはプログラム構造のみを規定しているため、MDA以外のフレームワークで規定しているフレームにも容易に対応可能と考えられる。
４．５  課題
前述のような効果は期待できるが、以下の課題も存在している。Lyeeプログラミングがより広範に活用されることにより、これら課題に対してもよりよい対応案が出来てくることと思われる。
４．５．１  配列の処理
一般的に２次元、３次元等の配列としてデータ処理を行うことが多い。例えば、月別支店別の売上金額を求める場合、表３３のコーデングをする場合が多い。
【０１６５】
【表３３】
2008171023.tif 000035
Lyeeプログラミングでは現在は表３４の対応方法がある。しかし「完了報告」の単位を１配列（例えば表３３の月別支店別売上金額）１個とするか否か等プログラム構造上の課題も残っている。
【０１６６】
【表３４】
2008171023.tif 000036
４．５．２  領域の初期化
プログラムを作成する上で、使用しているデータ領域をいつ初期化するかは単純ではない。またこの領域初期化条件をあまり複雑化してしまうと、分かり難いプログラムとなってしまう。Lyeeプログラムでは現在は表３５のNo１の内容で領域の初期化を行っているが、必ずしも作業者に理解され易い内容とはなっていない。特に合計を求める場合や突合（マージ）処理での新／旧のキー値比較などを表３５のNo１で実施した場合「Lyeeプログラム特有」の処理となる感じは拭えない。これらを隠蔽した方法などが今後の課題である。
【０１６７】
【表３５】
2008171023.tif 000037
４．５．３  使用コンピュータ資源や処理完了時間
昨今はCPUの処理能力やメモリ容量、ＯＳのアドレス空間など急激に拡張増大されている。このため、Lyeeプログラムの冗長なソースコードでも特段の問題は無い場合が多いが、一定の考慮をしておく必要がある。
【０１６８】
レスポンス時間等の処理完了時間はLyeeプログラムと一般のプログラムとの差は一概には言えないが、Lyeeプログラムの繰返すことで値が成立する構造からすると、CPU時間は相対的に長いと考えられる。しかし、CPU時間は千分の１秒以下の単位が通常であるため、このCPU時間が長いことによる問題は、既にLyeeプログラムで作成され本番稼動しているシステムで発生していない。ただし、ファイル設計やSQLの作り方により処理完了時間は大きく変動するため、一般のプログラムで開発すると同様にこれらは十分検討してシステムを構築する必要がある。
参考資料１  無限ループ防止仕様の詳細説明
1部の１．２．２「上司プログラムの構造」や２．１．２「上司プログラムの完了判断の方法」および第２部の２．１．１「入力処理の上司プログラム」等でプログラムの仕様上無限ループが起こらない旨の説明をしているが、ここでまとめてその仕組みを説明する。
１  業務処理の上司プログラム
第１部２章の購入金額計算上司プログラムのフローは以下（図６２のとおり）である。（以降この具体例で説明する。項目数が増えても無限ループ回避の仕組みは変わらない。）
（１）無限ループの検討をするため図６３のループ部分のフローに注目し、各命令に(一)、(二)と番号を付番する。ループが終了するためには(一)の判定で「業務実施フラグ」が「Off」であれば良い。すなわち、３個の部下プログラムの中で「業務実施フラグ」      が「Off」のままとなれば良い。
（２）図６４が部下プログラムの一般形である。部下プログラムの(一)の判定で「No」と判断されると「業務実施フラグ」は「On」とはならない。このため部下プログラで(一)の判定が全て「No」と判断されることが必ず起こるか否かが問題である。必ず起こるとすれば、無限ループは回避できる。
（３）図６３に対応する３個の部下プログラムを図６５のようにＮ回ループを繰返すと以下の状態となる。
【０１６９】
ケース１：ある部下は図６４の「当該IDｎに必要な命令」が実施され「部下ｎセット完了フラグ」がOnとなっている。
【０１７０】
Ｎ＋１回目では条件４に合致しないため１番目の判定は「No」となる。
【０１７１】
ケース２：ある部下は図６４の「当該IDｎに必要な命令」は実施されず「部下ｎセット完了フラグ」はOffのままである。Ｎ＋１回目でも条件２、３、５のどれかにより１の判定は「Yes」とはならないため、６は実施されず、８のフラグはOffのままである。
【０１７２】
そこで、Ｎ＋１回目では全ての部下プログラムで新たに図６４の６が実施されないので７も実施されない。このことで、結局「業務実施フラグ」はOffのままであり、無限ループは回避される。
（４）別の観点では、図６４の６が１度実施されれば８で「部下ｎセット完了フラグ」      がOnとなり、以降、部下ｎプログラムに制御が移っても、１の判定は４により常      に「No」と判断され、「業務実施フラグ」はOffのままである。
【０１７３】
また部下プログラムの中では「あるデータ」では図６３のループ処理を何回繰返      しても、図６４の２、３、５に該当せず、常に１の判定はNoとなるものもある。こ      の場合は「業務実施フラグ」はOffのままとなる。
【０１７４】
よって図６３のループは、いつかは「業務実施フラグ」がOffとなり、無限ループ      は起こらない。なお最大ループ回数は部下プログラムの数と等しくなる。
２  入力処理を含めた上司プログラム
２部２章２．１．１では入力処理を含めた上司プログラムフローは以下（図６６に示すとおり）である。
「１  業務処理の上司プログラム」で述べたとおり、図６６の下半分の業務処理部分は無限ループしない。このため入力処理を含めた上司プログラムフローは図６７に単純化しても問題はない。
【０１７５】
図６７のループが終了するためには１の判定で「入力実施フラグ」がOffであ      れば良い。
【０１７６】
図１．７が入力処理の部下プログラムの一般形である。１の判定で「No」と判断されると「入力実施フラグ」は「On」とはならない。このため全ての部下入力プログラムの判定で「No」と判断されることが必ず起これば、無限ループが回避できる。
【０１７７】
図６７に対応した２個の入力処理の部下プログラムを想定し、図６９のＮ回ループを繰返すと以下の状態となる。  
ケース１：ある部下入力プログラムは図６８の４が実施され７または１０のフラグがOnとなっている。N＋１回目の処理では条件３により１判定はNoとなる。
ケース２：ある部下入力プログラムは図６８の４が実施されず７または１０も実施されない。このため、「入力処理ｎ実施フラグ」はOffのままである。Ｎ＋１回目の処理でも４は実施されない。これは条件２、４のどれかにより１の判定はYesとならない。
【０１７８】
そこで、Ｎ＋１回目の処理では、全ての部下入力プログラムは図６８の１の判定でNoとなる。すなわち、「入力実施フラグ」はOffのままであり、無限ループは回避される。
３  自モジュールの繰返について
自モジュールの繰返し処理を加えると図７０のプログラムフローとなり、ここでも無限ループが起こる可能性がある。
【０１７９】
自モジュールの繰返しを停止する条件は表３６のような業務要件に従う。この停止条件は自モジュールの繰返し処理には存在するので、条件設定誤り以外は必ず繰返しは停止される。
【０１８０】
【表３６】
2008171023.tif 000038
４  複数モジュール構成について
複数モジュール構成となった場合、無限ループは起こらないか？につき考察する。
【０１８１】
まず、最下位のモジュールは前述の説明で無限ループは起こさない。この結果その上位の階層のモジュールも無限ループは起きない。これを最終的な最上位のモジュールまでも同様な論理で考えることができる。結局複数モジュール構成となっても、無限ループは起きない。
参考資料２  プログラムフローの補足
２部の３．２「具体例：商品注文プログラム」の上司プログラムフローやモジュール制御処理の部下プログラムフローは以下（図７１に示すとおり）となる。
１  商品注文画面の親モジュールの上司プログラムフロー
図７１に示すとおりである。なお、同図において、部下１２から１４は２部３章の３．２．４の業務要件より３種類のメッセージが必要のため作成している。
２  商品注文画面の子モジュール１の上司プログラムフロー
引継ぎファイルと顧客マスターを読む処理である（図７２）。
３  商品注文画面の子モジュール２の上司プログラムフロー
商品マスターを読み商品名コンボBox内容を複数件出力処理である（図７３）。
４  商品注文画面の子モジュール３の上司プログラムフロー
選択された商品名で商品マスターを読む処理である（図７４）。
５  商品注文画面の子モジュール４の上司プログラムフロー
商品マスターと採番テーブルを読み、受注マスターの登録と採番テーブルの更新を行う  処理である（図７５）。
６  「親モジュールへ戻る」の部下プログラムフロー
商品注文画面の子モジュール１の「親モジュールへ戻る」モジュール制御の部下プログラムフローは以下（図７６に示すとおり）である。
７  「子モジュール１へ遷移」の部下プログラムフロー
商品注文画面の親モジュールの「子モジュール１へ遷移」のモジュール制御の部下プログラムフローは以下（図７７に示すとおり）である。
８  「子モジュール４へ遷移」の部下プログラムフロー
商品注文画面の親モジュールの「子モジュール４へ遷移」のモジュール制御の部下プログラムフローは以下（図７８に示すとおり）である。
９  「メニュープログラムへ遷移」の部下プログラムフロー
商品注文画面の親モジュールの「メニュープログラムへ遷移」のモジュール制御の部下プログラムフローは以下（図７９に示すとおり）である。
１０  「自モジュール繰返」の部下プログラムフロー
商品注文画面の子モジュール２の「自モジュール繰返」のモジュール制御の部下プログラムフローは以下（図８０に示すとおり）である。
１１  「自モジュール処理の繰返」を加えたの上司プログラムフロー（図８１）
１２  モジュール制御処理を含めた上司プログラムフロー（図８２）
参考資料３  Lyeeプログラム実績（図８３）          ２００５年４月現在
参考資料４  ソース生成ツール入力例
＜購入金額計算＞
画面（図８４）
（２）要件（図８５）
（３）ソース生成ツールへの入力内容
ア  上司プログラム関連
（ア）入出力情報（図８６）
入出力情報と項目・属性
購入金額計算画面：KEISAN_gm 
（図８７）
商品マスター：GoodsMF 
（図８８）
イ  部下プログラム関連（図８９）
＜購入金額照会＞
画面（図９０）
要件（図９１）
ソース生成ツールへの入力例
ア  上司プログラム関連
入出力情報（図９２）
入出力情報と項目・属性
購入金額照会画面：Syoukai_gm 
（図９３）
商品マスター：GoodsMF  （図９４）
イ  部下プログラム関連（図９５）
なお、本発明は、上述した実施形態および実施例には限定されず、本発明の技術思想の範囲内で様々な変形が可能である。
【０１８２】
たとえば、上記した適用例に本願は限定されることなく、種々の機能を実現するいかなるシステム開発に対しても本願は適用可能であり、かかる本願の適用された各対象は当該対象物固有の効果を奏する。
【０１８３】
さらに本願発明は、その技術思想の同一及び等価に及ぶ範囲において様々な変形、追加、置換、拡大、縮小等を許容するものである。また、本願発明を用いて生産される装置、方法、ソフトウェア、システムが、その２次的生産品に登載されて商品化された場合であっても、本願発明の価値は何ら減ずるものではない。
【産業上の利用可能性】
【０１８４】
本発明によれば、ソースプログラムの自動生成が可能になり、業務要件の稼動基盤からの独立性が確保され、変数関係の順序を考慮する必要がなくなり、さらに、品質の向上とテスト工程の削減がなされることで、スピーデイなシステム開発が可能となる。
【０１８５】
さらに、プログラムのスピーデイな開発が可能なことは、プログラム保守の変更・追加作業でも効果が発揮され、作業の容易化、効率化が図られる。
【０１８６】
またさらに、プログラムの業務アプリケーション定義書は、プログラム制御に係わる記述が不要となるため記述量が少なくて済み、定義書の量的な削減が図られる。
【０１８７】
さらに、LyeeプログラムはMDAで規定するＳＩＭとＰＳＭそれぞれに対応可能である。またLyeeプログラムはプログラム構造のみを規定しているため、MDA以外のフレームワークで規定しているフレームにも容易に対応可能である。
よって本発明は、いかなる用途、或いはネットワークを介して配信され若しくはスタンドアローンを問わずあらゆる存在形態におけるソフトウェア、及びソフトウェアの生産方法にも適用できる。
【図面の簡単な説明】
【０１８８】
【図１】本発明のＬｙｅｅプログラムの特長を概念的に説明するための図である。
【図２】本発明の一実施形態に係る購入金額計算の画面の例を示す図である。
【図３】本発明の一実施形態に係る購入金額計算のフローチャートである。
【図４】本発明の一実施形態に係る単価の決定のフローチャートである。
【図５】本発明の一実施形態に係る割引率の決定のフローチャートである。
【図６】本発明の一実施形態に係る部下プログラムのプログラムフローを示すフローチャートである。
【図７】本発明の一実施形態に係る上司の役割をプログラムフローで示すフローチャートである。
【図８】本発明のLyeeプログラムの本来的な考え方である並列処理を示すフローチャートである。
【図９】本発明の一実施形態に係る購入金額計算の作業完了までの経緯を示すフローチャートである。
【図１０】本発明の一実施形態に係る部下プログラムの判定条件の追加を示すフローチャートである。
【図１１】本発明の一実施形態に係る購入金額計算処理の上司プログラムのフローと部下プログラムのフローを一括してまとめて示すフローチャートである。
【図１２】本発明の一実施形態に係る複数モジュール化した上司／部下プログラムを概念的に示す図である。
【図１３】本発明の一実施形態に係る図１２の左側の３階層の例をLyeeモジュール化する構成を示す図である。
【図１４】本発明の一実施形態に係る「金額計算」処理に「発注」処理を加えた注文画面の例を示す図である。
【図１５】本発明の一実施形態に係る注文画面処理のモジュール構造を示す図である。
【図１６】本発明の一実施形態に係る親モジュールの上司プログラムのフローを示すフローチャートである。
【図１７】本発明の一実施形態に係る子モジュールの上司プログラムのフローを示すフローチャートである。
【図１８】本発明の一実施形態に係る「子モジュール呼出」のプログラムフローを示すフローチャートである。
【図１９】本発明の一実施形態に係る購入金額計算画面の例を示す図である。
【図２０】本発明の一実施形態に係る上司プログラムのフローを示すフローチャートである。
【図２１】本発明の一実施形態に係る部下プログラムのフローを示すフローチャートである。
【図２２】本発明の一実施形態に係る部下プログラムのフローを示すフローチャートである。
【図２３】本発明の一実施形態に係る出力項目ｎの部下プログラムのフローを示すフローチャートである。
【図２４】本発明の一実施形態に係るLyeeプログラムの領域を示した図である。
【図２５】本発明の一実施形態に係る購入金額計算の画面を示す図である。
【図２６】本発明の一実施形態に係る上司プログラムのフローを示すフローチャートである。
【図２７】本発明の一実施形態に係る部下プログラムのフローを示すフローチャートである。
【図２８】本発明の一実施形態に係る部下プログラムのフローを示すフローチャートである。
【図２９】本発明の一実施形態に係る部下プログラムのフローを示すフローチャートである。
【図３０】本発明の一実施形態に係る部下プログラムのフローを示すフローチャートである。
【図３１】ＭＤＡで規定している機能体系を簡潔に要約する図である。
【図３２】本発明のLyeeプログラミングを前提とした全体的なシステム構成を示す図である。
【図３３】本発明の一実施形態に係るLyeeシステム開発手順例（ウオータフォール型）を示す図である。
【図３４】本発明の一実施形態に係るシステム開発イメージを示す図である。
【図３５】本発明の一実施形態に係るLyeeプログラム生成機能を示す図である。
【図３６】本発明の一実施形態に係るLyeeプログラムの基本構成を示す図である。
【図３７】本発明の一実施形態に係る入力処理と業務アプリケーション処理の完全分離を概念的に示す図である。
【図３８】本発明の一実施形態に係る入力処理の上司プログラムのフローを示すフローチャートである。
【図３９】本発明の一実施形態に係る入力処理と業務処理を含めた上司プログラムのフローを示すフローチャートである。
【図４０】本発明の一実施形態に係る購入金額計算画面の例を示す図である。
【図４１】本発明の一実施形態に係る入力処理を含めた上司プログラムのフローを示すフローチャートである。
【図４２】本発明の一実施形態に係る部下入力１（商品マスター）のプログラムフローを示すフローチャートである。
【図４３】本発明の一実施形態に係る出力処理の上司プログラムを示すフローチャートである。
【図４４】本発明の一実施形態に係る入出力処理を含めた上司プログラムのフローを示すフローチャートである。
【図４５】本発明の一実施形態に係る商品マスター更新処理の部下プログラムフローを示すフローチャートである。
【図４６】本発明の一実施形態に係る購入金額照会プログラムの画面の例を示す図である。
【図４７】本発明の一実施形態に係る購入金額照会の上司プログラムのフローを示すフローチャートである。
【図４８】本発明の一実施形態に係る部下入力１（商品マスター）のプログラムフローを示すフローチャートである。
【図４９】本発明の一実施形態に係る部下入力２（購入金額画面入力）のプログラムフローを示すフローチャートである。
【図５０】本発明の一実施形態に係る割引率２０％セットsecのプログラムフローを示すフローチャートである。
【図５１】本発明の一実施形態に係る画面出力secのプログラムフローを示すフローチャートである。
【図５２】本発明の一実施形態に係るモジュールの構成を概念的に示す図である。
【図５３】本発明の一実施形態に係るLyeeプログラムの複数モジュール構成を示す図である。
【図５４】本発明の一実施形態に係る注文画面処理プログラムの画面の例を示す図である。
【図５５】本発明の一実施形態に係る商品注文処理プログラムのモジュール構成図である。
【図５６】本発明の一実施形態に係る「１件出力」と「複数件出力」例についての「自モジュール処理の繰返」を示す図である。
【図５７】本発明の一実施形態に係る「自モジュール処理の繰返」を加えた上司プログラムコーデング例を示す図である。
【図５８】本発明の一実施形態に係る全ての「モジュール制御機能」を加えた上司プログラムコーデング例を示す図である。
【図５９】本発明の一実施形態に係る子モジュール遷移の部下プログラムフローを示すフローチャートである。
【図６０】本発明の一実施形態に係る子モジュール制御以外のモジュール制御処理部下プログラムフローを示すフローチャートである。
【図６１】本発明の一実施形態に係るソースコード（命令）の順を概念的に示す図である。
【図６２】本発明の一実施形態に係る上司プログラムのフローを示すフローチャートである。
【図６３】本発明の一実施形態に係るループ部分のフローを示すフローチャートである。
【図６４】本発明の一実施形態に係る部下プログラムｎのフローを示すフローチャートである。
【図６５】本発明の一実施形態に係るｎ回ループを示す図である。
【図６６】本発明の一実施形態に係る入力処理を含めた上司プログラムのフローを示すフローチャートである。
【図６７】本発明の一実施形態に係る入力処理ループ部分フローを示すフローチャートである。
【図６８】本発明の一実施形態に係る入力処理の部下ｎプログラムのフローを示すフローチャートである。
【図６９】本発明の一実施形態に係る入力処理ループ部分のフローを示すフローチャートである。
【図７０】本発明の一実施形態に係る「自モジュール処理の繰返」を加えた        Lyeeプログラムフローを示すフローチャートである。
【図７１】本発明の一実施形態に係る商品注文画面の親モジュールの上司プログラムフローを示すフローチャートである。
【図７２】本発明の一実施形態に係る商品注文画面の子モジュール１の上司プログラムフローを示すフローチャートである。
【図７３】本発明の一実施形態に係る商品注文画面の子モジュール２の上司プログラムフローを示すフローチャートである。
【図７４】本発明の一実施形態に係る商品注文画面の子モジュール３の上司プログラムフローを示すフローチャートである。
【図７５】本発明の一実施形態に係る商品注文画面の子モジュール４の上司プログラムフローを示すフローチャートである。
【図７６】本発明の一実施形態に係る親へ戻るモジュール制御の部下プログラムフローを示すフローチャートである。
【図７７】本発明の一実施形態に係る子モジュール１へ遷移するモジュール制御の部下プログラムフローを示すフローチャートである。
【図７８】本発明の一実施形態に係る子モジュール５へ遷移するモジュール制御の部下プログラムフローを示すフローチャートである。
【図７９】本発明の一実施形態に係るメニュープログラムへ遷移のモジュール制御の部下プログラムフローを示すフローチャートである。
【図８０】本発明の一実施形態に係るメニュープログラムへ遷移のモジュール制御の部下プログラムフローを示すフローチャートである。
【図８１】本発明の一実施形態に係る「自モジュール処理の繰返」を加えた            上司プログラムフローを示すフローチャートである。
【図８２】本発明の一実施形態に係るモジュール制御処理を含めた上司プログラムのフローを示すフローチャートである。
【図８３】Lyeeプログラム実績を示す図である。
【図８４】本発明の一実施形態に係る購入金額計算の画面の例を示した図である。
【図８５】本発明の一実施形態に係る業務要件を示す図である。
【図８６】本発明の一実施形態に係るソース生成ツールへ入力する入出力情報の例を示す図である。
【図８７】本発明の一実施形態に係るソース生成ツールへ入力する入出力情報と項目・属性の例を示す図である。
【図８８】本発明の一実施形態に係るソース生成ツールへ入力する入出力情報と項目・属性の例を示す図である。
【図８９】本発明の一実施形態に係るソース生成ツールへ入力する部下プログラム関連の例を示す図である。
【図９０】本発明の一実施形態に係る購入金額照会の画面の例を示す図である。
【図９１】本発明の一実施形態に係る購入金額照会の要件の例を示す図である。
【図９２】本発明の一実施形態に係るソース生成ツールへ入力する入出力情報の例を示す図である。
【図９３】本発明の一実施形態に係るソース生成ツールへ入力する入出力情報と項目・属性の例を示す図である。
【図９４】本発明の一実施形態に係るソース生成ツールへ入力する入出力情報と項目・属性の例を示す図である。
【図９５】本発明の一実施形態に係るソース生成ツールへ入力する部下プログラム関連の例を示す図である。
【符号の説明】
【０１８９】
ｓｅｃ  セクション
ＭＤＡ  モデリング駆動型アーキテクチャ
【図１】
2008171023.tif 000039
【図２】
2008171023.tif 000040
【図３】
2008171023.tif 000041
【図４】
2008171023.tif 000042
【図５】
2008171023.tif 000043
【図６】
2008171023.tif 000044
【図７】
2008171023.tif 000045
【図８】
2008171023.tif 000046
【図９】
2008171023.tif 000047
【図１０】
2008171023.tif 000048
【図１１】
2008171023.tif 000049
【図１２】
2008171023.tif 000050
【図１３】
2008171023.tif 000051
【図１４】
2008171023.tif 000052
【図１５】
2008171023.tif 000053
【図１６】
2008171023.tif 000054
【図１７】
2008171023.tif 000055
【図１８】
2008171023.tif 000056
【図１９】
2008171023.tif 000057
【図２０】
2008171023.tif 000058
【図２１】
2008171023.tif 000059
【図２２】
2008171023.tif 000060
【図２３】
2008171023.tif 000061
【図２４】
2008171023.tif 000062
【図２５】
2008171023.tif 000063
【図２６】
2008171023.tif 000064
【図２７】
2008171023.tif 000065
【図２８】
2008171023.tif 000066
【図２９】
2008171023.tif 000067
【図３０】
2008171023.tif 000068
【図３１】
2008171023.tif 000069
【図３２】
2008171023.tif 000070
【図３３】
2008171023.tif 000071
【図３４】
2008171023.tif 000072
【図３５】
2008171023.tif 000073
【図３６】
2008171023.tif 000074
【図３７】
2008171023.tif 000075
【図３８】
2008171023.tif 000076
【図３９】
2008171023.tif 000077
【図４０】
2008171023.tif 000078
【図４１】
2008171023.tif 000079
【図４２】
2008171023.tif 000080
【図４３】
2008171023.tif 000081
【図４４】
2008171023.tif 000082
【図４５】
2008171023.tif 000083
【図４６】
2008171023.tif 000084
【図４７】
2008171023.tif 000085
【図４８】
2008171023.tif 000086
【図４９】
2008171023.tif 000087
【図５０】
2008171023.tif 000088
【図５１】
2008171023.tif 000089
【図５２】
2008171023.tif 000090
【図５３】
2008171023.tif 000091
【図５４】
2008171023.tif 000092
【図５５】
2008171023.tif 000093
【図５６】
2008171023.tif 000094
【図５７】
2008171023.tif 000095
【図５８】
2008171023.tif 000096
【図５９】
2008171023.tif 000097
【図６０】
2008171023.tif 000098
【図６１】
2008171023.tif 000099
【図６２】
2008171023.tif 000100
【図６３】
2008171023.tif 000101
【図６４】
2008171023.tif 000102
【図６５】
2008171023.tif 000103
【図６６】
2008171023.tif 000104
【図６７】
2008171023.tif 000105
【図６８】
2008171023.tif 000106
【図６９】
2008171023.tif 000107
【図７０】
2008171023.tif 000108
【図７１】
2008171023.tif 000109
【図７２】
2008171023.tif 000110
【図７３】
2008171023.tif 000111
【図７４】
2008171023.tif 000112
【図７５】
2008171023.tif 000113
【図７６】
2008171023.tif 000114
【図７７】
2008171023.tif 000115
【図７８】
2008171023.tif 000116
【図７９】
2008171023.tif 000117
【図８０】
2008171023.tif 000118
【図８１】
2008171023.tif 000119
【図８２】
2008171023.tif 000120
【図８３】
2008171023.tif 000121
【図８４】
2008171023.tif 000122
【図８５】
2008171023.tif 000123
【図８６】
2008171023.tif 000124
【図８７】
2008171023.tif 000125
【図８８】
2008171023.tif 000126
【図８９】
2008171023.tif 000127
【図９０】
2008171023.tif 000128
【図９１】
2008171023.tif 000129
【図９２】
2008171023.tif 000130
【図９３】
2008171023.tif 000131
【図９４】
2008171023.tif 000132
【図９５】
2008171023.tif 000133