JP2008171023A - Software creation method - Google Patents
Software creation method Download PDFInfo
- Publication number
- JP2008171023A JP2008171023A JP2005124245A JP2005124245A JP2008171023A JP 2008171023 A JP2008171023 A JP 2008171023A JP 2005124245 A JP2005124245 A JP 2005124245A JP 2005124245 A JP2005124245 A JP 2005124245A JP 2008171023 A JP2008171023 A JP 2008171023A
- Authority
- JP
- Japan
- Prior art keywords
- program
- processing
- subordinate
- input
- module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4482—Procedural
- G06F9/4484—Executing subprograms
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
Description
本発明は、ソフトウェア生成方法に係り、特に、Lyee方法論におけるソフトウェア生成方法に関する。 The present invention relates to a software generation method, and more particularly, to a software generation method in the Lyee methodology.
高い品質を持つソフトウェアを容易に迅速に製造することは、ソフトウェア開発研究分野での基本的な関心事である。ここ数年間にわたって、ソフトウェア開発のライフサイクルに関連する1つまたは多くの局面を改善するために、種々の方法論および技術が考案され、提案されてきた。 The easy and rapid production of high quality software is a fundamental concern in the field of software development research. Over the past few years, various methodologies and techniques have been devised and proposed to improve one or many aspects related to the software development life cycle.
しかし、この研究分野における熱心な努力にもかかわらず、明確に理解でき、修正可能なシステムの製造は、困難な目標であり達成にはほど遠い。 However, despite intense efforts in this area of research, the production of a clearly understandable and modifiable system is a difficult goal and far from being achieved.
これまでのシステム開発は、次のような欠点があった。 Conventional system development has the following disadvantages.
まず、業務要件が稼動基盤に依存し、少々の変更でもプログラム・ロジックの変更を考慮する必要があり、品質面の不安定性・テスト工程の煩雑さがあった。これがシステム開発プロジェクト全体の遅延をもたらしていた。 First, the business requirements depend on the operating base, and even a small change needs to take into account changes in the program and logic, resulting in instability in quality and complexity in the test process. This led to a delay in the entire system development project.
またこれが、プログラム保守の変更・追加作業にも波及し、作業の複雑化、非効率化を招いていた。 This has also spread to program maintenance changes and additions, leading to complexity and inefficiencies.
さらにプログラムの業務アプリケーション定義書の記述量が膨大となっていた。 In addition, the amount of business application definition documents written in the program was enormous.
また、プログラムにおいては各個別のフレームワークで規定しているフレームに対してのみ対応し、汎用性が低かった。 In addition, the program only supports frames defined by each individual framework, and its versatility is low.
本発明は上記の従来技術の問題を解決するためになされたもので、ソースプログラムの自動生成が可能になり、業務要件の稼動基盤からの独立性が確保され、変数関係の順序を考慮する必要がなくなり、さらに、品質の向上とテスト工程の削減がなされることで、スピーデイなシステム開発が可能となるソフトウェア生成方法を提供することを目的とする。 The present invention has been made to solve the above-mentioned problems of the prior art, and it is possible to automatically generate a source program, to ensure the independence of business requirements from the operating base, and to consider the order of variable relationships. In addition, it is an object of the present invention to provide a software generation method that enables speedy system development by improving quality and reducing test processes.
さらに本発明の別の目的は、プログラム保守の変更・追加作業でも効果が発揮され、作業の容易化、効率化が可能となるソフトウェア生成方法を提供することである。 Still another object of the present invention is to provide a software generation method that is effective even in program maintenance change / addition work, and that facilitates and improves the work efficiency.
本発明のまた別の目的は、プログラムの業務アプリケーション定義書の記述量が少なくて済み、定義書の量的な削減が図られることを可能とするソフトウェア生成方法を提供することである。 Another object of the present invention is to provide a software generation method that can reduce the amount of description of a business application definition document of a program and can reduce the number of definition documents.
本発明のさらに別の目的は、種々のフレームワークで規定しているフレームにも容易に対応可能なソフトウェア生成方法を提供することである。 Still another object of the present invention is to provide a software generation method that can easily cope with frames defined by various frameworks.
かかる課題を解決するため、本発明は、要件定義をもとに各論理体に所属する単語単位で所定の属性をデータとして規定する第1のステップと、要件の過不足を調整する第2のステップと、前記第2のステップで調整されたデータをソフトウェアの必須要素としてLyee所与のプログラム構造をもつ自動生成ツールに入力することにより所望のソフトウェアの目的コードを得る第3のステップとを具備するソフトウェア生成方法において、 前記Lyee所与のプログラム構造においては入力処理と業務処理、出力処理を独立化し、入力処理は業務処理を「入れ子」とする2重Loop構造をとり、入力処理群の完了判定後は、未完了の場合は、再度入力処理群へ制御を移し、入力処理群が完了した場合は、出力処理へ制御を移し、出力処理では完了判定は行わずに上司/部下プログラムの構成とすることを特徴とする。 In order to solve such a problem, the present invention provides a first step of defining a predetermined attribute as data in units of words belonging to each logical body based on a requirement definition, and a second step of adjusting excess or deficiency of requirements And a third step of obtaining the target code of the desired software by inputting the data adjusted in the second step as an essential element of the software into an automatic generation tool having a given program structure. In the software generation method, the input process, the business process, and the output process are made independent in the given program structure, and the input process has a double loop structure in which the business process is “nested” to complete the input process group. After the determination, if it is not completed, control is transferred to the input processing group again. If the input processing group is completed, control is transferred to the output processing. It is characterized in that the manager / subordinate program is configured without performing the end determination.
本発明によれば、ソースプログラムの自動生成が可能になり、業務要件の稼動基盤からの独立性が確保され、変数関係の順序を考慮する必要がなくなり、さらに、品質の向上とテスト工程の削減がなされることで、スピーデイなシステム開発が可能となる。なおここで、Lyee(商標)とは、「governmentaL methodologY for softwarE providencE」(ソフトウェア開発における統一的方法論)の逆頭文字語である。 According to the present invention, it is possible to automatically generate a source program, the independence of business requirements from the operating base is ensured, there is no need to consider the order of variable relations, and quality is improved and test processes are reduced. As a result, speedy system development becomes possible. Here, Lyee (trademark) is an acronym for “governmental method Y for software E product E” (a unified methodology in software development).
さらに、プログラムのスピーデイな開発が可能なことは、プログラム保守の変更・追加作業でも効果が発揮され、作業の容易化、効率化が図られる。 Furthermore, the fact that programs can be developed quickly is effective even in program maintenance change / addition work, and facilitates and improves work efficiency.
またさらに、プログラムの業務アプリケーション定義書は、プログラム制御に係わる記述が不要となるため記述量が少なくて済み、定義書の量的な削減が図られる。 Furthermore, since the business application definition document of the program does not require a description related to program control, the amount of description is small, and the amount of definition document can be reduced.
さらに、LyeeプログラムはMDAで規定するSIMとPSMそれぞれに対応可能である。またLyeeプログラムはプログラム構造のみを規定しているため、MDA以外のフレームワークで規定しているフレームにも容易に対応可能である。 Furthermore, the Lyee program is compatible with both SIM and PSM defined by MDA. Also, because the Lyee program only defines the program structure, it can easily handle frames defined by frameworks other than MDA.
以下、図面を参照して本発明の最良の実施形態を説明する。
はじめに
1部 Lyeeプログラムとはどんなものか
1章 Lyeeプログラムの特徴
1.1 仕事が始められる条件は?
1.2 上司/部下プログラム
1.3 複数モジュール化した上司/部下プログラム
2章 Lyeeプログラムの基本形
2.1 上司/部下プログラムのプログラミング方法
2.2 具体例:購入金額計算プログラム
2.3 まとめ
2部 Lyeeプログラム生成機能を使ってのシステム開発方法
Lyeeプログラムの役割とシステム開発方法
1.1 システム構築方法:MDA
1.2 Lyeeプログラムの役割
1.3 Lyeeの業務アプリケーション要件の記述方法
1.4 システム開発方法
1.5 Lyeeプログラム生成機能
2章 Lyeeプログラムの入出力処理
2.1 入出力処理のプログラミング方法
2.2 具体例:購入金額照会プログラム
2.3 まとめ
3章 Lyeeプログラムの複数モジュール構成
3.1 Lyeeプログラムの複数モジュール化
3.2 具体例:注文画面処理プログラム
3.3 モジュール制御を含んだ上司プログラム
3.4 モジュール制御の部下プログラム
4章 システム開発上の効果
4.1 スピーデイなシステム開発
4.2 保守作業の効率化
4.3 業務アプリケーション定義書類の削減
4.4 多種なフレームと共存
4.5 課題
参考資料1 無限ループ防止仕様の詳細説明
参考資料2 プログラムフローの補足
参考資料3 Lyeeプログラム実績
参考資料4 ソース生成ツール入力例
はじめに
1 業務アプリケーション機能の画期的な開発の仕方
独創的で画期的な業務アプリケーション機能の開発方法が考案された.それがどのように画期的かは当ホームページで紹介されている色々な資料で述べられているが、ここでは著者らの見方でそれを説明したいと思う.
(1)開発のスピードが速い
理由:ソフトウエア開発の主要要素である業務アプリケーション機能についてLyeeでは、変数間の関係が専ら問題の論理的な関係を考慮するだけで良く、複雑な変数間の関係を斟酌する必要が無い。このためソフトウエア開発のスピードが速い。
(2)業務アプリケーション機能のメンテナンスが容易である
理由:(1)でも述べたが、Lyeeでは変数間の関係は論理的な関係を記述するだけで他の条件等はそもそも記述していないから、他の条件に影響されない。結果として業務アプロケーション機能のメンテナンスは、実現しようとする目標(問題の論理関係)が変わらぬ限り生じない.
(3)そのようなウマイ話がどうして成立するのか
理由:変数間の関係はコンピュータに自動的に行わせるプログラミングが可能となった.これは、コンピュータの主記憶が十分大きくなったことと計算スピードが速くなったことによってはじめて実用的な方法として使えるようになったといえる.
そのため、実行時にある程度コンピュータに変数間の関係を探させる必要があり、その結果、処理時間を限界まで高める必要のあるソフトウェアの開発に適用するには限界がある。しかし、変数間の関係をコンピュータが自動的に捜してくれるので、開発のスピードやメンテナンスの容易さが、より重要となるアプリケーションでは威力を発揮する。事務処理型のソフトウェアでは処理時間もさることながら、ソフトウエア開発のスピード、メンテナビリティにより価値を認めるから、そこでは十分実務的に使える開発方法である。 データベースアクセスなどアプリケーションに依存しないミドルウエアを利用するときには、従来のソフトウエアと同じく使用ミドルウエアが規定したインターフェースを持つ必要がある。理屈ではなく本書に添付されたサンプルプログラムで実際の雰囲気を味わっていただきたい。
2 開発のスピード、メンテナビリティの向上のもう一つの説明
Lyeeの方法論を良く調べるとそこではプログラムの作成に従来の意味でのプログラミングが不要であることに気付くであろう。
Hereinafter, the best embodiment of the present invention will be described with reference to the drawings.
1.2 Boss / subordinate program 1.3 Boss / subordinate program made up of
Role of Lyee Program and System Development Method 1.1 System Construction Method: MDA
1.2 Role of Lyee Program 1.3 Description Method of Lyee Business Application Requirements 1.4 System Development Method 1.5 Lyee Program Generation Function Chapter 2 I / O Processing of Lyee Program 2.1 I / O
1 Innovative way of developing business application functions An original and innovative way of developing business application functions has been devised. How it is epoch-making is described in various materials introduced on this homepage, but here I would like to explain it from the viewpoint of the authors.
(1) Reasons for fast development: Regarding business application functions, which are the main elements of software development, in Lyee, the relationship between variables only needs to consider the logical relationship of the problem, and the relationship between complex variables There is no need to hesitate. This speeds up software development.
(2) Reasons for easy maintenance of business application functions: As described in (1) above, because Lyee only describes logical relationships, it does not describe other conditions in the first place. Unaffected by other conditions. As a result, the maintenance of the business allocation function does not occur as long as the goal to be realized (the logical relationship of the problem) does not change.
(3) Reason why such a Umai story is established: The relationship between variables can be programmed automatically. It can be said that this became a practical method only after the main memory of the computer became sufficiently large and the calculation speed increased.
Therefore, it is necessary to let the computer search for the relationship between the variables to some extent at the time of execution, and as a result, there is a limit to the application to software development that needs to increase the processing time to the limit. However, the computer automatically searches for the relationship between variables, so it can be useful in applications where speed of development and ease of maintenance are more important. In business processing software, not only processing time but also the value is recognized by the speed and maintainability of software development, so it is a development method that can be used practically enough. When using middleware that does not depend on applications, such as database access, it is necessary to have an interface defined by the middleware used, as with conventional software. Please enjoy the actual atmosphere with the sample program attached to this book.
2 Another explanation for improving development speed and maintainability
If you look closely at Lyee's methodology, you will find that programming in the traditional sense is not necessary to create a program.
誇張して言うと、業務アプリケーション機能の開発は変数という「意味を扱う対象」をデータとして記述することしか行っていない。つまり、データの定義が終われば、そこで業務アプリケーション機能のソースプログラムは自動的に生成されるのである。 Exaggeratedly speaking, the development of business application functions only describes the “objects that handle meaning” as variables as data. That is, when the data definition is finished, the source program for the business application function is automatically generated there.
「データとして記述する」ということは具体的には何かは、今は明らかなことではないが、本書を読み進まれるうちにそれがどのように有効かを示す。 What is specifically "describe as data" is not clear at the moment, but it shows how effective it is as you read this book.
プログラミングはいくら勉強しても、したりないもので、コンピュータの出現以来ずっとソフトウエアはこの問題を追いつづけている.それにも拘わらず未だにプログラミングの新しい方法の提唱がやまない。今後も同様の提案は絶えることなく現れるであろう。 Programming is something you can't do, no matter how much you study, and software has been tracking this problem since the advent of computers. Nevertheless, there is still no advocacy for new methods of programming. Similar proposals will continue to appear in the future.
これに対してデータを定義する業務アプリケーション機能の開発方法は基本的にはデータが出尽くすならばそれ以上は増えつづけない。データに付随してロジックを与えロジック間のつながりは自動生成ツールに任せて、人は新たにプログラムを組まないからである。 On the other hand, the business application function development method for defining data basically does not continue to increase if the data runs out. This is because logic is attached to the data and the connection between the logics is left to an automatic generation tool, and a person does not create a new program.
Lyeeはデータを定義するのと同じ感覚で業務アプリケーション機能が記述でき、かつソースプログラムも自動的に作成できるので、本書ではLyeeを「データ指向プログラムの自動生成」と唱えることにした.
1部 Lyeeプログラムとはどんなものか
1章 Lyeeプログラムの特徴
Lyeeプログラムはあっと驚く単純な構造をしている。構造は単純であるが業務アプ リケーション機能が何であってもその構造以外の構造は考える必要が無い。従って プログラムの構造を複数の候補の中から選択すると言う手間は要らない。
Lyee can describe business application functions in the same way as defining data and can automatically create source programs, so in this book, we decided to call Lyee "automatic generation of data-oriented programs".
The Lyee program has a surprisingly simple structure. Although the structure is simple, there is no need to consider any structure other than that structure regardless of the business application function. Therefore, there is no need to select the program structure from multiple candidates.
この章ではLyeeプログラムの構成を「上司・部下」の役割に喩え、精密さは多少犠 牲にしたアイデアレベルの説明でその特徴を理解されたい。ここでの理解があると、2章以降のプログラムフローを基にした説明も簡単に理解できるはずである。
1.1 仕事が始められる条件は?
Lyeeプログラムの構造は単純であるが業務アプリケーション機能が何であってもその構造以外の構造は考える必要が無い。このようなことが何故可能なのか?複雑なケースの分析は後回しにして、2種類の人が仕事を分担して処理を行うケースを考える。2種類の人とは図1の2種類である.ここでは前者を上司、後者を部下と仮に呼んでおく。直感的に明らかなようにビジネス処理はこの2種類の人の共同作業でなされる。処理が複雑な時には部下が上司となって更に他の部下に仕事を回すこともあるが、それは単に処理が複雑になっただけで処理の考え方は変わらない。
In this chapter, the structure of the Lyee program is likened to the role of a “superior / subordinate”, and its characteristics should be understood with an explanation at the idea level, with some precision sacrificed. If you understand here, you should be able to easily understand the explanation based on the program flow from
1.1 What are the conditions for starting work?
The structure of the Lyee program is simple, but no matter what the business application function is, there is no need to consider other structures. Why is this possible? We will postpone the analysis of complicated cases, and consider the case where two types of people share work and process. The two types of people are the two types shown in Fig. 1. Here, the former is called the superior and the latter is called the subordinate. As it is intuitively obvious, business processing is performed by the collaboration of these two types of people. When processing is complicated, the subordinate may become a supervisor and work to other subordinates, but this is simply because the processing becomes complicated and the concept of processing does not change.
さて、共同作業を単純化すると上司は他人に仕事を依頼した後は単に部下に依頼した処理が終わったかどうか待っているだけでよい。その上で部下全員が処理を完了した時、上司は自分自身がしなくてはならない仕事をして、仕事は一件落着となる。 Now, when simplifying collaborative work, after the boss asks someone else to do the job, he or she simply has to wait to see if the processing requested by the subordinate has been completed. On top of that, when all the subordinates have completed the process, the boss does the work he has to do and the work is settled down.
ここで重要なのは部下が仕事をする順番は、上司も部下も特に考える必要はないということである。実際上は部下Aが作業をするのに必要な条件が整っていないときにはその条件が整えられるまで部下Aは作業をせずに単に待つ。そのことにより自然に処理の順番が定まる。部下Aは自分の必要とする条件だけに興味を持てば良く、他のことは気にしなくても良い。 The important thing here is that the order in which the subordinates work does not need to be considered by either the supervisor or the subordinates. In practice, when the conditions necessary for the subordinate A to work are not met, the subordinate A simply waits without performing work until the conditions are met. This naturally determines the order of processing. The subordinate A need only be interested in the conditions he needs, and does not have to worry about other things.
仕事を渡された部下のいずれもが自分の必要とする条件が満たされない時にはそもそも上司が依頼した仕事が不可能であったケースで、上司には「不可能であった」ということが通知される。このことによって、いくら大きな仕事であろうと処理をするときに考える範囲はごく限られたものになる。これをコンピュータプログラム的に展開したものがLyeeプログラムである。
1.2 上司/部下プログラム
購入金額計算の具体的処理でLyeeの上司プログラムや部下プログラムの概要を説明する(図2)。
ここでは、実稼動可能なプログラムを構成する命令の一部の‘塊‘をプログラムと呼んでいる。ここでのプログラムは上司モジュール(またはセクション)、部下モジュール(またはセクション)と同等である。同図において、業務要件としては(1)購入金額=購入数量×単価×(1−割引率/100)、(2)割引率:購入数量20個以上は20%引き、購入数量19個以下は0%引きとする。
部下プログラムの構造
部下は上司から命令された仕事をする人である。購入金額計算処理での“仕事”とは、「購入金額」の計算、「単価」の決定、「割引率」の決定であり、これらの仕事を引き受ける部下が3人居るとする。
In the case where none of the subordinates who have been given work meets the requirements of their own, the work requested by the boss was impossible in the first place, the boss was notified that it was `` impossible '' The This limits the scope to consider when processing, no matter how big the job. The Lyee program is a computer program that is expanded.
1.2 Overview of Lyee's supervisor program and subordinate program in the specific process of calculating the purchase amount of the supervisor / subordinate program (FIG. 2).
Here, a part of the “lumps” of instructions that constitute a program that can be actually operated is called a program. The program here is equivalent to the supervisor module (or section) and the subordinate module (or section). In the figure, the business requirements are (1) purchase price = purchase quantity × unit price × (1−discount rate / 100), (2) discount rate: 20% or more of purchase quantity is discounted by 20%, and purchase quantity of 19 or less is 0% discount.
The structure of the subordinate program The subordinate is the person who does the work ordered by the supervisor. The “job” in the purchase price calculation processing is calculation of “purchase price”, determination of “unit price”, determination of “discount rate”, and it is assumed that there are three subordinates who take on these jobs.
1人目の部下(部下1とする)の「購入金額の計算」の“仕事”は、計算に必要なデータが揃っているかを確認し、揃っていれば計算を行い、上司に完了を報告する。揃っていなければ揃うまで待つ。これをフロー図で表すと図3となる。なお、同図中、「計算に必要なデータ」とは、購入数量、商品単価、割引率である。 For the first person's subordinate (subordinate 1), the “work” of “calculation of purchase price” confirms whether the data necessary for the calculation is available, and if it is available, calculates and reports the completion to the supervisor . If not, wait until it is complete. This is represented by a flow chart in FIG. In the figure, “data necessary for calculation” is the purchase quantity, the product unit price, and the discount rate.
2人目の部下(部下2とする)の「単価の決定」の“仕事”は、商品マスターより該当商品の単価を得ることとする。商品マスターの入力処理が完了していれば単価が得られ、入力処理が未完了ならば完了するまで待つこととなる。これをフロー図で表すと図4となる。なお、同図中、「単価セットに必要なデータが揃ったか」に関しては、単価は商品マスターより得られるとしている。このため「単価セットに必要なデータ」は、商品マスターファイルの該当商品についての単価である。 The “work” of “determination of unit price” of the second subordinate (subordinate 2) is to obtain the unit price of the corresponding product from the product master. If the product master input process is completed, the unit price is obtained, and if the input process is not completed, the process waits until it is completed. This is represented by a flow chart in FIG. In the figure, the unit price is obtained from the product master with respect to “whether the data necessary for the unit price set is available”. Therefore, “data necessary for the unit price set” is a unit price for the corresponding product in the product master file.
3人目の部下(部下3とする)の「割引率の決定」の“仕事”も同様で、画面より入力された購入数量が20個以上の場合は20%引き、購入数量が19個以下の場合は0%引きの割引率となる。画面より入力された購入数量が得られなければ得られるまで待つこととなる。これをフロー図で表すと図5となる。なお同図中、「割引率決定に必要なデータ」は画面より入力された購入数量としている。このため「割引率決定に必要なデータ」は画面より入力された購入数量である。 The same applies to the “work” of “determining the discount rate” of the third subordinate (subordinate 3). If the purchase quantity entered on the screen is 20 or more, 20% is discounted and the purchase quantity is 19 or less. In this case, the discount rate is 0% discount. If the purchase quantity entered from the screen cannot be obtained, it will wait until it is obtained. This is represented by a flow chart in FIG. In the figure, “data necessary for determining the discount rate” is the purchase quantity entered from the screen. Therefore, “data necessary for determining the discount rate” is the purchase quantity entered from the screen.
これらがLyeeの部下プログラムの基本的なプログラムフローである。購入金額計算の例題は簡単なので部下プログラムは3個しかないが、1画面で項目数が100個以上となる場合もある。この場合は部下プログラムが100個以上となる。 These are the basic program flow of the subordinate program of Lyee. Since the example of calculating the purchase price is simple, there are only three subordinate programs, but the number of items may be 100 or more on one screen. In this case, there are 100 or more subordinate programs.
部下プログラムのプログラムフローを一般形で表現すると図6となる。部下プログラムは3つの命令群で構成され、第1の命令が「判定」であること、及び第3の命令が「完了報告」であることがLyeeプログラムの特徴である。なお第2の命令は通常のプログラムと同様に「指示された仕事」に関する「計算」とか「値のセット」とかの命令となる。
1.2.2 上司プログラムの構造
ここで、上司プログラムはプログラム構造的に必須事項ではないが、説明を簡単にするため加えている。
(1)上司プログラムのフロー
上司は次の3点を実施する人とする。
FIG. 6 shows the program flow of the subordinate program in a general form. The subordinate program is composed of three instruction groups. The feature of the Lyee program is that the first instruction is “determination” and the third instruction is “completion report”. Note that the second command is a command such as “calculation” or “value set” related to “instructed work” in the same way as a normal program.
1.2.2 Structure of the supervisor program Here, the supervisor program is not an essential item in the program structure, but is added to simplify the explanation.
(1) Boss program flow The boss is the person who performs the following three points.
i. 部下に「仕事の割当と作業指示」を行う。 i. “Assign work and work instructions” to subordinates.
ii. 自分自身の「仕事」を行う。 ii. Do your own “work”.
iii. 仕事の「完了判断」を行う。 iii. Make a “completion decision” for the job.
購入金額計算での上司プログラムの具体的役割は
i.部下への仕事の割当と作業指示
部下1:購入金額の計算
部下2:単価の決定
部下3:割引率の決定
ii. 自分自身の仕事:「入力処理」と「出力処理」
iii. 完了判断
を行うことである。この上司の役割をプログラムフローで図示すると図7となる。
The specific role of the boss program in the purchase price calculation
i. Assignment of work to subordinates and work instructions Subordinate 1: Calculation of purchase price
Subordinate 2: Determination of unit price Subordinate 3: Determination of discount rate
ii. My job: “input processing” and “output processing”
iii. Make a completion decision. The role of this boss is illustrated in the program flow as shown in FIG.
なおここで、「入力処理」に関して、ここでは説明を簡単にするため、入力処理や出力処理についてのLyeeプログラムフローの説明は省略している。入出力処理のLyeeプログラムフローは2部2章の2.1.1や2.1.3を参照されたい。また、図7中、「Call 部下1Sec」は部下1セクションの処理へ制御を移すことを意味する。また図7は現在の逐次処理型コンピュータを前提としたフローである。Lyeeプログラムの本来的な考え方は図8の並列処理を想定している。
It should be noted that here, the explanation of the Lyee program flow regarding input processing and output processing is omitted for the sake of simplicity of explanation regarding “input processing”. Refer to 2.1.1 and 2.1.3 of
「完了判定」では「完了」と「未完了」の場合で分岐が発生するが、分岐先(遷移先)は次となる。 In “completion judgment”, a branch occurs between “completed” and “incomplete”, but the branch destination (transition destination) is the next.
(A)「完了」と判定した場合:出力処理へ移る。 (A) When judged as “completed”: The process proceeds to output processing.
(B)「未完了」と判定した場合:再度「作業の割当と作業指示」を行う。
なお「完了」の判定方法は無限ループを回避するため一定の考慮を必要とする。なおここで、無限ループとならないため、「完了判断」の内容は「全ての完了」を完了と判断するだけでなく、何回処理を繰返しても「完了が見込めない」ものも完了として扱う必要がある。詳しくは巻末の参考資料1無限ループ防止使用の詳細説明を参照されたい。なおこの無限ループ回避方式はデータを順番に並べるソート処理でのデータを「並び終えた」ことを判断する方式と類似する。
(B) When it is determined as “incomplete”: “work assignment and work instruction” is performed again.
Note that the determination method of “complete” requires a certain consideration in order to avoid an infinite loop. Here, since there is no endless loop, it is necessary not only to determine that “all completed” is complete, but also to “complete” is considered as complete even if the process is repeated many times. There is. For details, refer to
(2)作業完了までの経緯
購入金額計算の具体例で作業完了までの経緯は以下であり、図示すると図9となる。この経緯を要約すると、「上司は作業が完了と判断されるまで、部下への作業指示を繰返し、作業指示を何回か繰返した後には必ず作業は完了となる」である。
(2) Process until completion of work The process until completion of work in the specific example of the calculation of the purchase price is as follows. To summarize this process, “the supervisor repeats the work instruction to his subordinates until the work is judged to be completed, and the work is always completed after repeating the work instruction several times”.
**作業完了までの経緯の説明**
(一)まず入力処理が行われ1回目の「完了判定」が為される。判定は「未完了」である。
** Description of the process up to completion of work **
(1) First, input processing is performed, and the first “completion determination” is performed. The determination is “incomplete”.
<初回ループ>
(二)初回の各部下の処理が開始される。部下2と部下3の「購入単価の決定」と「割引率の決定」作業は完了する。しかし「購入金額の計算」作業は未完了である。
<First loop>
(2) The first subordinate process is started. The “determination of purchase unit price” and “determination of discount rate” operations of
(三)2回目の「完了判定」が行われ、判定は「未完了」である。 (3) The second “completion determination” is performed, and the determination is “incomplete”.
<2回目ループ>
(四)2回目の各部下の処理が行われる。部下1の「購入金額計算」は作業前提のデータが揃っているので計算が完了する。部下2、部下3は既に作業完了している。
<Second loop>
(4) The processing of each subordinate for the second time is performed. The calculation of the purchase amount calculation of
(五)3回目の「完了判定」が行われ、作業は「完了」と判断される。処理は出力処理へ移り、出力後、作業は終了する。なおここで、部下の数が増えても「作業完了」に到る繰返し(ループ処理)回数は異なるが、作業完了までの経緯は同様であることを理解されたい。
(3)部下プログラムの判定条件の追加
前述のように、部下プログラムは上司プログラムから何回も呼ばれる可能性がある。これに対処するため部下プログラムフローの第1番目の判定は、(一)「仕事遂行に必要なデータが揃ったか」に加え、(二)「当該処理が完了したら“再度”実施しない」条件を追加する。具体的には、図10となる。このことで再度計算してしまう無駄や再計算による累積値の値が不正解となることを防止できる。なお同図で「割引率の決定に必要なデータが揃った」とは、具体的には以下である。すなわち、
(A) 「割引率の決定に必要なデータ」は画面より入力された「購入数量」である。
(B) 「割引率の決定は未実施か」は「割引率決定記録」を判定する。「割引率決定記録」の具体的内容は2章の2.1.3(2)「“既に実施済か”の判定方法」を参照されたい。
(5) The third “completion judgment” is performed, and the work is judged to be “completion”. The process moves to an output process, and after the output, the work ends. Here, although the number of subordinates increases, the number of repetitions (loop processing) leading to “work completion” is different, but it should be understood that the process until the work is completed is the same.
(3) Addition of criteria for subordinate program As described above, the subordinate program may be called many times by the supervisor program. In order to deal with this, the first determination in the subordinate program flow is that (1) “Is the data necessary for job execution complete?” And (2) “Do not execute again after the process is completed” to add. Specifically, FIG. 10 is obtained. As a result, it is possible to prevent wasteful recalculation and incorrect values of the accumulated value due to recalculation. In the same figure, “the data necessary for determining the discount rate is available” is specifically as follows. That is,
(A) “Data required for determination of discount rate” is “Purchase quantity” entered from the screen.
(B) “Whether or not discount rate has been determined” is determined by “discount rate determination record”. Refer to 2.1.3 (2) “Determination method of“ already implemented ”” in
購入金額計算処理の上司プログラムのフローと部下プログラムのフローを一括してまとめると図11となる。
1.3 複数モジュール化した上司/部下プログラム
上司/部下の役割をもとにLyeeプログラムの特徴を説明して来たが、一般的な仕事では複層的な上司/部下の構成で行われる場合も多い。これと同じく、ある1つのプログラムでも複数の単位(以降モジュールと言う)を組合わせて一連の処理を行う場合も数多くある。Lyeeプログラムは、この複数モジュール化にどう対処するかの考え方を図12に説明する。
1.3.1 複数モジュール化対応の考え方
Lyeeプログラムの複数モジュール化の対応は次の考え方で行う。
(一)各モジュールを階層構造化する。
(二)各モジュールの内部構成はいままで説明した上司・部下構成とする。
FIG. 11 shows a summary of the flow of the supervisor program and the subordinate program in the purchase price calculation process.
1.3 Multi-module supervisor / subordinate program The features of the Lyee program have been explained based on the roles of supervisor / subordinate. There are many. Similarly, there are many cases where a single program performs a series of processing by combining a plurality of units (hereinafter referred to as modules). The concept of how the Lyee program deals with this multi-modularization is illustrated in FIG.
1.3.1 Concept of handling multiple modules
The Lyee program is handled with the following concept.
(1) Each module is hierarchically structured.
(2) The internal configuration of each module shall be the supervisor / subordinate configuration described above.
図12の左側の3階層の例をLyeeモジュール化すると図13となる。まず、「部長と課長A、X」の構成が親モジュール、「課長Aと社員A1〜An」が子モジュール1、「課長Xと社員X1〜Xm」が子モジュール2の3モジュール構成となる。
FIG. 13 shows an example of the three layers on the left side of FIG. First, the structure of “department manager and section managers A and X” is a parent module, “section manager A and employees A1 to An” is a
各モジュール内での上司や部下の役割今までと変わりが無い。ただし部下の「仕事」は「子モジュールに作業指示を出す(プログラム的には“子モジュールのCall”)」という内容も1つの「仕事」と考える。
複数モジュール化したLyeeプログラム例
いままで述べてきた「金額計算」処理に「発注」処理を加えた注文画面(図14)を例にLyeeプログラムの複数モジュール化の概要を説明する。詳しくは2部3章を参照されたい。
注文画面プログラムのモジュール構造
なお、Lyeeプログラムのモジュール分割方法は第2部3章3.1.3を参照されたい。
The roles of supervisors and subordinates within each module are the same as before. However, the subordinate “work” is also considered to be “work” (“call out child module” from a program).
Example of Lyee Program with Multiple Modules An outline of the Lyee program with multiple modules will be described with an example of an order screen (FIG. 14) obtained by adding an “order” process to the “money calculation” process described so far. Please refer to
Module structure of order screen program Please refer to
注文画面処理は操作者が画面へ情報を入力し「金額計算」ボタンか「発注」ボタンを押下されたかに応じ必要な処理がなされるとする。注文画面処理のモジュール構成は表1に示すように、「画面入出力&金額計算」処理の機能と「発注」処理の機能に2分割した2モジュール構成とする。 It is assumed that the order screen processing is performed depending on whether the operator inputs information on the screen and presses the “calculate amount” button or the “order” button. As shown in Table 1, the module configuration of the order screen processing is a two-module configuration that is divided into two functions: a “screen input / output & amount calculation” processing function and an “ordering” processing function.
(2)各モジュールの上司プログラムフロー
親モジュールと子モジュールの上司プログラムのフローは図16、17となる。
(2) Supervisor program flow of each module The supervisor program flow of the parent module and the child module is shown in FIGS.
複数モジュール化の特徴は「仕事」として「子モジュール呼出」の仕事が加わることである。 The feature of multiple modules is that “child module call” work is added as “work”.
図17において、「注文番号採番ファイル入力」について、注文番号は採番ファイルより得ることとしているので、採番ファイルの入力と更新処理が必要となる。部下処理の内容は「Call 部下11(注文番号採番)Sec」が注文番号採番ファイルへの出力項目、「Call 部下12(顧客コードセット)Sec」〜「Call 部下16(注文番号セット)Sec」が注文マスターへの出力項目としている。 In FIG. 17, for “order number numbering file input”, since the order number is obtained from the numbering file, it is necessary to input and update the numbering file. The content of subordinate processing is “Call subordinate 11 (order number numbering) Sec” is the output item to the order number numbering file, “Call subordinate 12 (customer code set) Sec” to “Call subordinate 16 (order number set) Sec” "Is an output item to the order master.
また図17では子モジュールの上司プログラムフロー(発注処理モジュール)を示しているが、実際の子モジュール呼出し命令は親モジュールの「部下5(子モジュール)Sec」で発行される。図18を参照されたい。
(3)「子モジュール呼出」の部下プログラムフロー
部下5の「子モジュール呼出」のプログラムフローは図18となる。特徴はプログラムフローの第2番目の命令内容が「子モジュールをCall」するとなっていることである。なお、親モジュールと子モジュールの各部下プログラムは図10と同形のプログラムフローである。
2章 Lyeeプログラムの基本形
1章では上司・部下の役割を例にLyeeプログラムの特徴を説明した。この章では 上司プログラムの「完了判断」や部下プログラムの「完了報告」等をプログラミン グ可能なフローに展開し、Lyeeプログラミングの基本形を説明する。なお上司・部下プログラムのプログラミング方法(テクニック)はいろいろ考えられるが、ここでは単純明快な方法で説明する。
上司/部下プログラムのプログラミング方法
Lyeeプログラムの基本形は上司プログラムと部下プログラム群で構成される。この章では業務アプリケーション機能(業務要件)である計算や条件、値のセット等についてのプログラミング方法をフロー図などで説明する。
2.1.1 仕事の単位
上司は部下に「仕事」を細分化して割当てる。Lyeeプログラミング方法の第1の課題は、この「仕事」の‘単位’をどう決定すれば良いかである。
FIG. 17 shows the superior program flow (order processing module) of the child module, but the actual child module call instruction is issued by “subordinate 5 (child module) Sec” of the parent module. See FIG.
(3) Subordinate program flow of “child module call” The program flow of “child module call” of
How to program a supervisor / subordinate program
The basic form of the Lyee program consists of a supervisor program and subordinate programs. In this chapter, programming methods for business application functions (business requirements) such as calculations, conditions, value sets, etc. will be explained with flowcharts.
2.1.1 Unit of work The boss subdivides and assigns “work” to subordinates. The first challenge of the Lyee programming method is how to determine the 'unit' of this “work”.
プログラムの処理は一般的に「入力された情報」をもとに「計算・判定・加工」等の業務アプリケーション処理を行い「情報を出力」することである。 The processing of the program is generally to perform business application processing such as “calculation / determination / processing” based on “input information” and “output information”.
このことから、Lyeeプログラムでの「仕事」の‘単位’は、計算・判定・加工の結果である「出力情報」に所属している項目を「仕事の単位」とする。 For this reason, the “unit” of “work” in the Lyee program is the item belonging to “output information” that is the result of calculation / judgment / processing as “unit of work”.
なお、仕事の単位は出力項目群とすることも考えられるが、この「群」をどのようにするかなどの問題があり、単純明快とはいえない。仕事の単位は出力項目と決めたことにより、上司プログラムの作業指示の単位と各部下プログラムの単位も一意的に決ったこととなる。また、稼動可能なプログラムは業務アプリケーション機能以外に入出力機能なども必要となる。この「仕事の単位」については2部2章や3章を参照されたい。
Although the unit of work may be an output item group, there are problems such as how to make this "group", and it cannot be said that it is simple and clear. By determining the unit of work as an output item, the unit of work instruction of the supervisor program and the unit of each subordinate program are also uniquely determined. An operable program requires an input / output function in addition to the business application function. Please refer to
図19の購入金額計算画面の例では出力項目が3個とすると表2の3個が「仕事の単位」となり、部下プログラムの単位ともなる。 In the example of the purchase price calculation screen of FIG. 19, if there are three output items, the three items in Table 2 become “units of work” and are also units of subordinate programs.
次に1章で述べた上司プログラム機能の中での「完了判定」を、プログラミングとしてどう具体化するかを説明する。
上司プログラムの「完了判定」は、「仕事」の「完了」状態を記録させ、この記録されている内容を判定することで完了判断を行う方法とする。なお、成果物(出力内容)を判定することでも完了の判断は可能である。しかしこの方法は成果物内容に依存した判断も必要となるため、単純化を目指したプログラミングの自動化には適さない。 The “completion determination” of the superior program is a method of recording the “completion” state of “work” and determining the completion by determining the recorded contents. The completion can also be determined by determining the deliverable (output content). However, this method also requires judgment depending on the contents of the deliverables, so it is not suitable for automation of programming aimed at simplification.
記録させる領域名を「業務実施フラグ」とすると、上司プログラムのフローは図20となる。また完了状態の記録(具体的には「業務実施フラグ」)内容の適切な設定で上司プログラムの無限ループの発生は起こらない。なお、同図中、無限ループの回避策は下記の「完了判断の方法」において、(二)で「完了」と判断するため、上司プログラムの無限ループが回避できる。詳しくは巻末の参考資料1「無限ループ防止仕様の詳細説明」を参照されたい。また、「初期処理」は、一般的なファイルのOpen、領域の初期設定(例 業務フラグをOn)等の処理である。
If the area name to be recorded is “business execution flag”, the flow of the supervisor program is as shown in FIG. In addition, an infinite loop of the supervisor program does not occur with the proper setting of the completion status record (specifically, “business execution flag”). In the figure, the infinite loop avoidance measure is determined as “completed” in (2) in the following “completion judging method”, so that the infinite loop of the supervisor program can be avoided. For details, refer to
また、完了判断の方法としては、次のいずれかになる。 Further, the completion determination method is one of the following.
(一)未完了:「業務実施フラグがOn」
どれかの部下プログラムで処理が行われた(成果物ができた)ことを意味する。この成果物を利用し「まだ処理が為される可能性」がある。よって処理は「未完了(中途)」と判断する。
(1) Incomplete: “Business implementation flag is On”
It means that processing has been performed by one of the subordinate programs (a product has been created). Using this deliverable, there is a “possibility to be processed”. Therefore, it is determined that the process is “incomplete (intermediate)”.
(二)完了:「業務実施フラグがOff」
どの部下プログラムでも処理が為されなかった。すなわち成果物は出来なかった。このことは何回全ての部下プログラム処理をCallしても「新たな成果物は出来ない」ことを意味する。よって処理は「完了」と判断する。
(2) Completion: “Business implementation flag is off”
No subordinate program was processed. In other words, the product was not made. This means that no matter what number of subordinate program processes are called, no new product can be created. Therefore, it is determined that the process is “complete”.
さらに、終了処理はファイルのclose、Commit/Rollback等の処理である。
2.1.3 部下プログラムの業務遂行の判定方法
次は、部下プログラムのプログラムフロー第1番目の命令である「業務遂行の判定」をプログラミングとしてどう具体化するか説明する(図21)。
Furthermore, the termination process is a process such as file close, commit / rollback.
2.1.3 Method for Determining Business Execution of Subordinate Program Next, a description will be given of how the “determination of business execution”, which is the first instruction in the program flow of the subordinate program, is embodied as programming (FIG. 21).
プログラムフローの第1番目の判定命令で行わなければならないことは「業務遂行ができるか否」か、或いは「業務遂行をすべきか否か」である。 What must be performed in the first determination instruction of the program flow is “whether or not business can be performed” or “whether or not business should be performed”.
これを具体化すると、判定内容は表3に示すように、以下の3項目が必要となる。 Specifically, as shown in Table 3, the determination items require the following three items.
(一)適切なデータが揃ったか。ここで、いままでは「必要なデータ」と述べてきたが、厳密には「適切なデータ」である。計算等を行うにあたって「適切なデータ」でない場合は部下プログラムフローの第2番目の処理は実施できない。具体例は次のとおりである。 (I) Did you have the appropriate data? Here, it has been described so far as “necessary data”, but strictly speaking, it is “appropriate data”. If it is not “appropriate data” for performing the calculation, the second process of the subordinate program flow cannot be performed. A specific example is as follows.
<例>1 割り算での分母が「0」の場合:D=E÷Fで「Fが0」の場合は計算ができない。 <Example> 1 When the denominator in division is “0”: If D = E ÷ F and “F is 0”, calculation is not possible.
2 数値の加算でデータ値がNullの場合:A=B+Cで「Bがnull値」では計算ができない。
(二)既に「仕事」は実施済みか。
2 When the data value is Null by adding numerical values: A = B + C and “B is a null value” cannot be calculated.
(2) Has “work” already been carried out?
(三)業務遂行をする必要があるか(業務要件)。 (3) Is it necessary to carry out business (business requirements)?
部下プログラムの業務遂行判定の具体的方法は以降順次説明するが、例示すると図22となる。「xxxxフラグ」は後に説明するが、完了状態を記録する項目(領域)名である。
「適切なデータが揃ったか」の判定方法
表3の判定項目1番目の「適切なデータが揃ったか」の対象となるデータ項目は、例えば“金額=数量×単価”では「数量」と「単価」である。一般的には“y=f(x)”の変数「X」が「適切なデータ」の対象項目(簡便的には計算式の左辺の項目)である。具体例は表4に示されたものである。なおここで、定数(A=10の「10」、IF B>0の「0」)は「適切なデータ」の対象外である。
A specific method for determining the business execution of the subordinate program will be described in order, but FIG. As described later, “xxxx flag” is an item (area) name for recording the completion state.
How to determine whether “appropriate data is prepared” The data item that is the target of the first determination item “appropriate data is prepared” in Table 3 is “quantity” and “unit price” in “amount = quantity × unit price”, for example. It is. In general, the variable “X” of “y = f (x)” is the target item of “appropriate data” (simple item on the left side of the calculation formula). Specific examples are shown in Table 4. Here, the constants (“10” in A = 10, “0” in IF B> 0) are not subject to “appropriate data”.
(一)データの値が「ある」だけを判断する場合
(二)データの値が「あり」かつその値は定義域内でなければならない場合
の2ケースが考えられる。なおここで(二)において、定義域内とは表3のところで述べた注意事項を参照されたい。
ア データ値の「あり」を判定する方法
データ値が「ある」とは、入力されてデータ値が得られたり、計算や値のセットがなされたことによりデータ値が得られた状態である。なお、ここではデータ値の内容については問わない。
(1) When judging whether there is only a data value
(2) There are two cases where the data value is “Yes” and the value must be within the domain. Here, in (2), please refer to the notes mentioned in Table 3 for the definition area.
(A) Method for determining whether or not a data value exists A data value that is “present” means that a data value is obtained by being input, or a data value is obtained by calculation or set of values. Here, the content of the data value is not questioned.
この判定はいろいろな方法(当該項目の「初期値」を判定する方法もあるが処理内容に依存するケースが生じ、単純明快な方法とは言えない。)が考えられるが、Lyeeプログラムの自動化を図るため、各データ項目のデータ値の「あり/なし」状態を領域に記録させ、この記録されている内容によりデータ値の「あり/なし」を判定することが単純明快である。 There are various methods for this determination (there is a method to determine the “initial value” of the item, but there are cases where it depends on the processing content, and it cannot be said that it is a simple and clear method). However, the Lyee program can be automated. For the sake of illustration, it is simple and clear that the “present / not present” state of the data value of each data item is recorded in the area, and the “present / not present” data value is determined based on the recorded contents.
具体的には表5上段のように各項目毎に「xxxx完了フラグ」を設定し、入力処理完了後や計算や値のセットがなされた後に「セット完了」情報を記録する。項目値のセットが未完了の場合は「完了フラグ」は「Off」、項目値のセットが完了した場合は「完了フラグ」は「On」と記録する。このことで「データ値あり」判定は表5の下段となる。 Specifically, as shown in the upper part of Table 5, “xxxx completion flag” is set for each item, and “set completion” information is recorded after input processing is completed or after calculation or value setting is performed. When the setting of the item value is not completed, the “completion flag” is recorded as “Off”, and when the setting of the item value is completed, the “completion flag” is recorded as “On”. Thus, the “data value present” determination is in the lower part of Table 5.
イ データ値が「定義域内」であるかを判定する方法
データ値が「定義域内」であるかを判定する方法は、部下プログラムの2番目の命令である計算式や使用する関数等の内容により決るため、それに合わせ判定内容を記述する必要がある。なお(一)「Null」値では数値計算不可や(二)割り算での「分母が0」は不可、などが共通的な内容として「定義域内」か否かの判定の項目である。
Method of judging whether data value is "within definition domain" The method of judging whether data value is "within definition domain" depends on the contents of the calculation formula that is the second instruction of the subordinate program, the function to be used, etc. Therefore, it is necessary to describe the contents of the judgment accordingly. Note that (1) “Null” value cannot be numerically calculated and (2) “Denominator is 0” is not possible in division.
表3の判定項目の2番目は、当該仕事である「値のセット」や「計算」等が「既に実施済みか」否かを判定する。
この判定のプログラミング方法は前記(1)と同じく「xxxx完了フラグ」方式で実現可能である。すなわち、仕事の「実施済」状態を「完了フラグ」に記録させ、この記録されている内容により実施済を判定することが単純明快である。 The programming method of this determination can be realized by the “xxxx completion flag” method as in the above (1). That is, it is simple and clear that the “executed” state of the work is recorded in the “completion flag” and the execution is determined based on the recorded contents.
具体的には「出力項目xx」についての「完了フラグ」を用意し、初期状態は当該フラグを「Off」とし、計算やセット等が実施されたら当該フラグを「On」と記録する。なお、このOn/Offのセットの仕組みにより、当該項目の処理は1度しか実行されない。この部下プログラムでの「既に実施済み」の判定と2.1.4の「完了報告」により上司プログラムの無限ループは防止される。無限ループ防止については詳細は参考資料1を参照されたい。
Specifically, a “completion flag” for “output item xx” is prepared, the flag is set to “Off” in the initial state, and when calculation or setting is performed, the flag is recorded as “On”. Note that the processing of the item is executed only once by the on / off setting mechanism. The infinite loop of the supervisor program is prevented by the determination of “already implemented” in this subordinate program and the “completion report” in 2.1.4. Refer to
表3の判定項目の3番目は「業務遂行の必要性」を判断する。これは一般的な業務要件に該当し、出力項目xについての「業務的な条件」がある場合に設定する。このため具体的内容は各業務要件により決まる。表8はその具体例である。
部下プログラムの説明の最後は部下プログラムフローの第3番目の命令である上司への「完了報告」である。この「完了報告」をどうプログラミングするかを説明する。
(1)「業務完了」の記録
仕事の「完了報告」は前述の「2.1.2 上司プログラムの完了判定の方法」に対応させる必要がある。部下プログラムの「完了報告」方法は部下プログラムの第3番目の命令で「業務実施フラグ」を「On」と記録する。これにより、上司プログラムもまたこの「業務実施フラグ」をチェックすることで部下に割り当てた仕事の完了判断ができることとなる。
(2)当該項目の「既に実施済み」の記録
また「2.1.3(2)‘既に実施済か’の判定方法」で述べた当該項目の処理完了記録も部下プログラムフローの第3番目の命令群で実行しておく。具体的には当該項目の「セット完了フラグ」を「On」とする。以上をまとめると部下プログラムのフローは図23となる。なお、同図中、「出力項目nの業務的条件」は、業務的条件はOr、Andや=、≠、<、>等、使用言語で記述可能な判定識別子を使用して記述する。
Lyeeプログラムの領域
Lyeeプログラムの領域は一般的なデータ領域の他、Lyeeプログラムに特有な領域として、前述の各種完了情報を記憶する「フラグ」を制御情報として設定する必要がある。図24に示す。
2.2 具体例:購入金額計算プログラム
やや抽象的にLyeeプログラミングの方法を説明して来たが、具体例でその内容を 確認されたい。
2.2.1 購入金額計算のプログラムフロー
(1)画面と業務要件
画面と業務要件は以下(図25及び表9に示されるとおり)とする。単価は商品マスターを読むことで得られるものとする。
(1) Record of “business completion” “Completion report” of work needs to correspond to “2.1.2 Method of judging completion of supervisor program” described above. The “completion report” method of the subordinate program records “operation execution flag” as “On” in the third instruction of the subordinate program. As a result, the supervisor program can also determine the completion of the work assigned to the subordinate by checking the “business execution flag”.
(2) “Already implemented” record for the item The process completion record for the item described in “2.1.3 (2)“ Determination method ”” is also the third subordinate program flow. It is executed with the instruction group. Specifically, the “set completion flag” of the item is set to “On”. In summary, the flow of the subordinate program is shown in FIG. In the figure, “business condition of output item n” is described using determination identifiers that can be written in the language used, such as Or, And, =, ≠, <,>, etc.
Lyee program area
In addition to the general data area, the Lyee program area is an area unique to the Lyee program, and it is necessary to set the “flag” for storing the various types of completion information as control information. It shows in FIG.
2.2 Specific example: Purchase price calculation program The Lyee programming method has been explained somewhat abstractly, but please confirm the content with a specific example.
2.2.1 Purchase Flow Calculation Program Flow (1) Screen and Business Requirements The screen and business requirements are as follows (as shown in FIG. 25 and Table 9). The unit price is obtained by reading the product master.
Lyeeプログラムの領域と命令の構成は以下となる。
ア 領域の構成
The Lyee program area and command structure are as follows.
A Area configuration
上司プログラムの処理内容は以下の(一)〜(八)となる。(三)〜(六)は業務処理が完了するまで繰返される。フロー図は図26である。
(一)初期処理:制御情報の各フラグのOff、業務実施フラグのOn、ファイルOpen等を行う。
(二)入力処理:画面情報入力、商品マスターReadを行う
(三)業務処理:完了判定
業務実施フラグがOn:(四)以降を実施
業務実施フラグOff:画面出力処理へ遷移
(四)業務実施フラグをOffとする。
(1) Initial processing: Each flag of control information is turned off, task execution flag is turned on, file is opened, etc.
(2) Input processing: Screen information input, product master read
(3) Business processing: Judgment completion Business execution flag is On: (4) and after are executed Business execution flag Off: Transition to screen output processing
(4) Set the task execution flag to Off.
(五)各出力項目処理sec(購入金額の計算、単価の決定、割引率の決定)の実行
(六)「(三)」に移る
(七)出力処理:画面へ処理結果を出力する。
(八)終了処理:ファイルClose等を行う
なお、同図中、「初期処理」は、領域の初期化、Open等を行う。「入力処理(画面入力、商品マスターRead)」に関して、Lyeeプログラミング特有の入出力処理方式については第2部2章参照されたい。「割引率」については、割引率は0%のセットと20%のセットの2処理があるので部下プログラムsecを2個用意する。
(3)部下プログラムのフロー
部下プログラムは図27〜図30の4個である。それぞれは図23の基本形と同型である。
(5) Execution of each output item processing sec (calculation of purchase price, determination of unit price, determination of discount rate)
(6) Move to `` (3) ''
(7) Output processing: Output the processing result to the screen.
(8) End processing: file close etc. In the same figure, "initial processing" performs area initialization, open etc. Regarding "input processing (screen input, product master read)", refer to
(3) Flow of Subordinate Program There are four subordinate programs shown in FIGS. Each is the same type as the basic form of FIG.
割引率セットの業務要件‘購入数量「19以下」は0%、「20以上」は20%’は、第2命令が条件により異なるため、2個の部下プログラムを用意する。この場合、「If xx Then yy Else zz」でも可能であるが、部下プログラムフローを同一形態とするためや、プログラムの自動生成の実現に寄与するため、部下プログラムを複数個作成することとする。 The business requirement of the discount rate set ‘purchase quantity“ 19 or less ”is 0%, and“ 20 or more ”is 20%”. The second command differs depending on the conditions, so two subordinate programs are prepared. In this case, “If xx Then yy Else zz” is possible, but in order to make the subordinate program flow the same form and to contribute to the realization of automatic program generation, a plurality of subordinate programs are created.
なお、図27中の「実施条件判定」は以下をいう。すなわち、
If 購入数量入力完了フラグ=On
And 商品単価セット完了フラグ=On
And 割引率セット完了フラグ=On
And 購入金額セット完了フラグ=Off
2.2.2 計算が完了する順
購入金額計算プログラムが実行され、上司プログラムや部下プログラムの完了されていく順や購入金額が計算される状況は1章の図9と同様となる。
2.3 まとめ
たいへん簡単な例ではあるが、これがLyeeプログラムの基本形となる。たかだか3項目の出力で、各種フラグを用意したり、かなり面倒なことしている印象を与えるかもしれないが、しかし、この位でないと順序性を考慮しないプログラムはできないという側面もある。
In addition, “implementation condition determination” in FIG. That is,
If purchase quantity input completion flag = On
And Product unit price set completion flag = On
And Discount rate set completion flag = On
And purchase amount set completion flag = Off
2.2.2 Calculation Completion Order The purchase price calculation program is executed and the order in which the supervisor program and subordinate program are completed and the purchase price are calculated are the same as those in FIG.
2.3 Summary Although this is a very simple example, this is the basic form of the Lyee program. The output of at most 3 items may provide various flags or give the impression that it is quite troublesome, but there is also an aspect that a program that does not consider the ordering can not be done unless it is this place.
2部ではより実際的な、Lyeeプログラムの入力出力処理方法等を説明するが、入出力処理方法等は、この章で説明した「完了判定方式」を「多段階」の入れ子構造に拡張した構成としただけである。1部2章で説明した内容が基本であり、2部の内容はこれを「応用しているだけ」であることの認識で読み進めていただきたい。
2部 Lyeeプログラム生成機能を使ってのシステム開発方法
1部ではビジネスロジックの画期的な開発の仕方であるLyeeプログラムの特徴を説明した。2部ではLyeeプログラムがシステム開発の実務上どこに位置付けられかや、自動プログラミングが可能となるための入出力処理やプログラムの内部モジュール作成を説明する。
1章 Lyeeプログラムの役割とシステム開発方法
1.1 システム構築方法:MDA
システムを構築する際には、いろいろな構築方法が提唱されている中で最適な方法を利用し構築することとなる。ここでは、OMG(Object Management Group)で提唱しているMDA(Model Driven Architecture:モデリング駆動型アーキテクチャ)に添いLyeeプログラムの役割を特定し、Lyeeプログラミングを前提としたシステム開発方法の考え方を説明する。
The second part will explain the more practical input / output processing method of the Lyee program, etc., but the input / output processing method etc. is an extension of the “completion judgment method” described in this chapter to a “multi-stage” nested structure. It was just. The contents explained in
When constructing a system, it will be constructed using the optimum method among various construction methods proposed. Here, the role of the Lyee program is specified according to MDA (Model Driven Architecture) proposed by the Object Management Group (OMG), and the concept of the system development method on the premise of Lyee programming will be described.
MDAはいくつかの標準的な技術仕様を体系化した方法論である。MDAで規定している機能体系を簡潔に要約すると図31となる。すなわち(一)通信関連インターフェースを担う「ウエブインターフェース機能」(二)業務と利用者とのインターフェースを担う「利用者インターフェース機能」(三)当該業務処理を行う「業務アプリケーション機能」(四)共通的な処理を担う「共通ルーチン機能」の4機能となる。 MDA is a methodology that organizes several standard technical specifications. FIG. 31 shows a brief summary of the functional system defined by the MDA. (1) "Web interface function" responsible for communication-related interfaces (2) "User interface function" responsible for the interface between business and users (3) "Business application function" that performs the business process (4) Common The four functions are “common routine functions” that are responsible for various processes.
またこの機能構成を基本とし、企業内や企業間の全体的なシステムを関連つけた構成としては図32となる。これは図31を1つのローカルなシステムと位置付け、全体のシステムはこれらをネットワークで繋いだイメージとなる。各要素内容は次のとおりである。 Further, FIG. 32 shows a configuration in which the overall system is associated with the entire system within a company or between companies based on this functional configuration. This positions FIG. 31 as one local system, and the entire system is an image in which these are connected by a network. The contents of each element are as follows.
(一)W:WEB機能
(二)A:業務アプリケーション機能や利用者インターフェース機能
(三)Lib:共通ルーチン等のライブラリー機能
(四)I/O:データベース等の入出力機能
1.2 Lyeeプログラムの役割
LyeeプログラムはMDAの機能体系では業務アプリケーション機能を実現する役割を担う。稼動可能なLyeeプログラムはウェブインターフェ−ズ機能や利用者インタフェ−ズ機能、共通ルーティン(データベース、数値アルゴリズム等)機能を利用し、使用するプログラム言語に従うコードで業務アプリケーション機能を作成することとなる。
1.3 Lyeeプログラムの業務アプロケーション要件の記述方法
業務アプロケーション要件の記述方法についてLyeeプログラムは、そのプログラム構造から、データを定義するのと同じ感覚で業務要件を記述できる。表12は1部2章2.2の購入金額計算プログラムの業務要件である。
(1) W: WEB function
(2) A: Business application functions and user interface functions
(3) Lib: Library functions such as common routines
(4) I / O: I / O function such as database 1.2 Role of Lyee program
The Lyee program is responsible for realizing business application functions in the MDA functional system. Operable Lyee programs use web interface functions, user interface functions, and common routine (database, numerical algorithm, etc.) functions, and create business application functions with code that complies with the programming language used. .
1.3 Method of describing business allocation requirements of Lyee program About the method of describing business allocation requirements The Lyee program can describe business requirements from the program structure in the same way as defining data. Table 12 shows the business requirements of the purchase price calculation program in
1.4 システム開発方法
ウオータフォール型のシステム開発はシステム化計画や基本設計を行い、外部仕様や業務要件等を確定しプログラミングおよび稼動確認の順実施される。プロトタイピング型のシステム開発はプログラムを作成しながら、その内容の確認と修正を繰返し、システムを完成させる手順で行われる。
1.4 System development method Waterfall type system development is performed in the order of programming and operation confirmation by conducting systemization planning and basic design, finalizing external specifications and business requirements. Prototyping-type system development is performed in a procedure that completes the system by repeatedly checking and correcting the contents while creating a program.
Lyeeプログラムの開発手順は、外部設計で決った入出力仕様(画面レイアウトやファイルレイアウト情報)と内部設計で決めるデータ項目毎の業務アプリケーション情報をリポジトリに蓄積する。これらの情報とモジュール構造情報や入出力命令(SQL文など)を入力しLyeeプログラム生成機能を使い(2005年4月現在、Lyeeプログラム生成機能はカテナ社の「LyeeALL」が販売されている。)稼動環境にあわせたプログラミング(ソースコードは100%自動生成)を完了させる。そして単体テストを繰返しプログラムを完成させる。 The Lyee program development procedure stores input / output specifications (screen layout and file layout information) determined by external design and business application information for each data item determined by internal design in the repository. Enter this information, module structure information and input / output instructions (SQL statements, etc.) and use the Lyee program generation function (as of April 2005, the “LyeeALL” from Catena is available as the Lyee program generation function). Complete programming that matches the operating environment (the source code is 100% automatically generated). The unit test is repeated to complete the program.
Lyeeプログラミングを前提としたシステム開発手順は、入出力仕様とデータ項目毎の業務要件が決ることでプログラムが作成可能であるため、ウオータフォール型開発でもプロトタイピング型開発でも適用可能である(図33及び34)。 The system development procedure on the premise of Lyee programming can be applied to both waterfall type development and prototyping type development because the program can be created by determining the business requirements for each input / output specification and data item (FIG. 33). And 34).
Lyeeプログラム生成機能
Lyeeプログラム生成機能(図35及び表13)は以下の要素の構成で、Lyeeプログラムのソースプログラムを自動作成する。業務要件の追加変更に対応したプログラム修正もこの生成機能を使い行うことができる。このためにソースプログラムを直接修正することはない。
Lyee program generation function
The Lyee program generation function (FIG. 35 and Table 13) automatically creates a Lyee program source program with the following elements. Program modification corresponding to additional changes in business requirements can also be performed using this generation function. For this reason, the source program is not directly modified.
2章 Lyeeプログラムの入出力処理
Lyeeプログラムは業務アプリケーション機能を担うが、WEBや利用者インターフェース、データベースインターフェースなどとの入出力処理を行う必要がある。この章では業務アプリケーション機能と入力処理機能、出力処理機能の3機能を独立させた構成としたLyeeプログラムを説明する。
The Lyee program is responsible for business application functions, but requires input / output processing with the web, user interface, database interface, and so on. This chapter describes the Lyee program that consists of the business application function, input processing function, and output processing function.
なおこの例でもかなり余計で回りくどいプログラムフローとなっているとの見方もあろう。しかし、これは例題である「購入金額照会」処理固有のプログラムを作るのでなく、入出力処理を含めたソースプログラムの自動生成をいかに実現するかが目的であることを念頭に読み進んでいただきたい。
2.1 入出力処理のプログラミング方法
Lyeeプログラムの入出力処理は「入力処理命令群」と「出力処理命令群」を独立した“塊“として扱うことが特色である。以降入力処理群、出力処理群の“塊“をどうのプログラミングすれば良いのかを説明する。
In this example, there is a view that the program flow is rather extraordinary and unwieldy. However, this is not an example of creating a program specific to the “Purchase Amount Inquiry” process, which is an example, but it should be read with the intent of how to automatically generate a source program including input / output processes. .
2.1 I / O processing programming method
The input / output processing of the Lyee program is characterized by treating the “input processing instruction group” and the “output processing instruction group” as independent “lumps”. The following describes how to program the “lumps” of the input processing group and output processing group.
なお、入出力処理を含むLyeeプログラムの基本構成は図36である。 The basic configuration of the Lyee program including input / output processing is shown in FIG.
「初期処理命令群」では、ファイルのOpen、DBのConnect等を行い、「終了処理命令群」ではファイルのClose、DBのCommit/RollBack等を行う。 In the “initial processing instruction group”, file open, DB connect, and the like are performed, and in the “end processing instruction group”, file close, DB commit / roll back, and the like are performed.
入力処理の上司プログラム
(1)入力処理のフロー
通常は入力命令の発行順序を考慮してプログラミングする。これに対して、Lyeeプログラムは「変数間の関係」を斟酌せず「考慮範囲の極小化」を目指している。このため、Lyeeプログラムは各入力処理の処理順を不問とし、計算や値をセットする「業務アプリケーション処理」と「入力処理」の独立化を図るプログラム構造を実現する必要がある。
ア 入力処理と業務アプリケーション処理の完全分離
各処理の独立化を図るため、「入力処理命令群」と「業務アプリケーション命令群」の‘塊’は完全に分離する。フローで表すと以下(図37に示すように)となる。ここでの業務アプリケーション処理とは出力領域にある値をセットしたり、ある条件により計算をしたりすることを意味している。
イ 入力命令の発行順の不問
続いて、入力命令の発行順序を考慮しないことを実現するため、業務アプリケーションの各命令群の処理順を不問とした方式と同様に、入力処理の完了状態を記録する方式を採用する。完了状態を記録する項目名を「入力実施フラグ」とすると、上司プログラムのプログラムフローは以下(図38に示すように)となる。
ウ 入力処理と業務アプリケーション処理の連携方法
入力処理の‘塊‘と業務処理の’塊‘は分離したが、この塊をどのように連携させれば良いかが次の課題となる。
Boss program for input processing (1) Flow of input processing Normally, programming is performed in consideration of the order of issuing input commands. On the other hand, the Lyee program aims to “minimize the range of consideration” without hesitating “relationships between variables”. For this reason, the Lyee program needs to realize a program structure that makes the processing order of each input processing unquestioned and makes the “business application processing” and “input processing” for setting calculations and values independent.
A) Complete separation of input processing and business application processing In order to make each processing independent, the “lumps” of “input processing command group” and “business application command group” are completely separated. The following is the flow (as shown in FIG. 37). Here, business application processing means setting a value in the output area or calculating under certain conditions.
B) Input command issue order unquestioned Next, in order to realize that the input command issue order is not taken into account, the completion status of input processing is recorded in the same way as the method in which the processing order of each instruction group of business applications is unquestioned. Adopt the method to do. If the item name for recording the completion state is “input execution flag”, the program flow of the supervisor program is as follows (as shown in FIG. 38).
C. Coordination method between input processing and business application processing The "processing block" of input processing and the "processing block" of business processing are separated, but the next issue is how to link these processing blocks.
一般的には「ある入力命令」が実行され、入力されたデータにより業務アプリケーション処理が実施できる。業務アプリケーション処理が実施できたことにより、更に入力命令が実施できる可能性がある。これを繰返し、必要な全ての入力処理の完了まで続ける。入力処理と業務処理の塊の連携はこの考え方に基づく。これをプログラムフロー化すると図39となる。
(2)入力処理群の完了判定方式
入力処理命令群の完了判定方法は業務アプリケーション処理と同様に、入力処理の「完了」を記録し、この記録内容により完了を判定する。
Generally, a “certain input command” is executed, and business application processing can be performed using the input data. As business application processing can be performed, there is a possibility that further input commands can be performed. This is repeated until all necessary input processes are completed. The linkage between input processing and business processing is based on this concept. When this is converted into a program flow, FIG. 39 is obtained.
(2) Completion determination method of input processing group The completion determination method of the input processing instruction group records “completion” of the input processing as in the business application processing, and determines completion based on the recorded contents.
具体的には入力完了記録の項目名を「入力実施フラグ」とし、このフラグが「On」の場合は未完了(まだ入力処理は実施可能)、フラグが「Off」の場合は完了(これ以上入力処理は無効である)と判断できる。なお入力処理群での無限ループの回避策は業務処理の回避策と同様の論理で可能となる。(参考資料1「無限ループ回避の詳細説明」参照)
(3)入力処理群の完了判定後の制御の遷移
ア 入力処理群が未完了
入力処理群の処理が「未完了」の場合はまだ入力処理を実施する必要があるため、制御は入力処理の命令群へ制御を移す。ここでの入力処理の前提として、1回実施された入力処理は再び入力処理は実行しないとしている。なおバッチ処理等で入力ファイルをEOFまで繰返し読む場合等のように入力処理を繰返す必要がある処理の実現方法は3章の3.4.2「自モジュール処理の繰返」を参照されたい。
イ 入力処理群が完了
入力処理群の処理が「完了」の場合は既に業務処理も完了しているため、制御は出力処理へ遷移する。
(4)具体例
購入金額計算画面(図40)を例にLyeeプログラムの上司プログラムの入力処理と業務処理のプログラムフローをまとめると図41となる。
Specifically, the item name of the input completion record is “input execution flag”. If this flag is “On”, it is not completed (input processing can still be performed), and if the flag is “Off”, it is completed (more than this) It can be determined that the input process is invalid. An infinite loop avoidance measure in the input processing group is possible with the same logic as the work processing avoidance measure. (Refer to
(3) Control transition after the completion judgment of the input processing group Input processing group is incomplete If the processing of the input processing group is “incomplete”, it is necessary to execute the input processing yet. Transfer control to the instruction group. As a premise of the input process here, the input process executed once is not executed again. Refer to 3.4.2 “Repetition of own module processing” in
B) Input processing group is complete When the processing of the input processing group is “complete”, since the business process has already been completed, the control shifts to the output process.
(4) Specific Example FIG. 41 shows a summary of the program flow of the input process and the business process of the supervisor program of the Lyee program, taking the purchase price calculation screen (FIG. 40) as an example.
なお、図41において、入力処理の部下プログラムで入力命令が実行されると「入力実施フラグ」をOnとしている。また、入力順を考慮不要を強調するために、意図的に「商品マスター入力」を先頭にしている。 In FIG. 41, when an input command is executed by a subordinate program for input processing, the “input execution flag” is set to On. Moreover, in order to emphasize the necessity of considering the input order, “product master input” is intentionally placed at the top.
入力処理の部下プログラム
入力処理の部下プログラムは、業務アプリケーション処理の部下プログラムと基本は同型であるが、入力命令実行結果により内容が異なる。具体的にはReadやSelect等の入力命令が正常終了した場合は必要となる入力項目が得られたので、入力完了情報の記録のため「フラグ」類を「On」とする。入力処理の部下プログラムフローは図42となる。
Subordinate program for input processing The subordinate program for input processing is basically the same type as the subordinate program for business application processing, but the contents differ depending on the result of executing the input command. Specifically, when an input command such as Read or Select ends normally, necessary input items are obtained, so that “flag” type is set to “On” for recording input completion information. The subordinate program flow of the input process is shown in FIG.
なお、同図中、「入力命令を実施すべきか」とは、具体的には、
1 If 商品マスター入力処理実施フラグ=Off
2 And 検索キーの商品名セット完了フラグ=On である。
In addition, in the same figure, “should an input command be executed” specifically means
1 If Product master input processing execution flag = Off
2 Product name set completion flag of the And search key = On.
また、「商品単価入力完了フラグをOn」について、この例では「入力完了フラグ」のセットは1項目となっているが、入力命令で複数項目を得る場合はおのおのの項目の「完了フラグ」をOnとする必要がある。 In addition, with regard to “product unit price input completion flag On”, in this example, the “input completion flag” set is one item. However, when multiple items are obtained by an input command, the “completion flag” of each item is set. Must be set to On.
留意点はプログラムフローの第一番目の命令の「入力命令実施」判定の内容である。判定内容は表14の3点に該当する項目を考慮する必要がなる。 The points to be noted are the contents of the “input command execution” determination of the first command in the program flow. It is necessary to consider items corresponding to the three points in Table 14 for the determination contents.
出力処理は、入力処理と業務アプリケーション処理が全て完了した後で実行する。出力処理の上司プログラムのプログラム構成(図43)はLyeeプグラム全体の同型性を保持するため、「上司/部下」のプログラム構成とするが、出力「完了」判定や繰返し処理は行わない。
以上をまとめると上司プログラムの入力処理、業務アプリケーション処理、出力処理のプログラムフローは図44となる。
2.1.4 出力処理の部下プログラム
出力処理の部下プログラムはWriteやInsert、Update、Delete等の出力命令を記述するが、その前段として出力命令を実施すべきか否かの判定を行う。出力処理の部下プログラムフローは図45となる。
In summary, the program flow of the input process, business application process, and output process of the supervisor program is shown in FIG.
2.1.4 Output Processing Subordinate Program The output processing subordinate program describes output commands such as Write, Insert, Update, and Delete, and determines whether or not the output command should be executed as a preceding stage. The subordinate program flow of the output process is shown in FIG.
なお、出力処理の上司プログラムでは「完了」判定は必要でないため、「完了情報(フラグ)」のセットは基本形としては行わない。また、「出力命令を実施すべきか」に関して、具体的な出力遂行判定は、
(一)If 単価セット完了フラグ=On
(二)And 商品コードキー値セット完了フラグ=On である。
Note that the “completion” determination is not required in the boss program of the output process, and therefore the “completion information (flag)” is not set as a basic form. In addition, with regard to “whether to execute an output command”, a specific output execution determination is as follows:
(1) If unit price set completion flag = On
(2) And Product code key value set completion flag = On.
一般的には、
(一)If 各出力項目のセット完了フラグ=On
(二)And 更新、削除キー項目セット完了フラグ=ON
(三)And 出力業務条件に合致か となる
2.2 具体例:購入金額照会プログラム
具体例で入出力処理を含んだLyeeプログラムのフローを確認する。
2.2.1 処理概要
商品名、購入数量を入力し、割引率、消費税を加味した購入金額を表示する。
2.2.2 画面
図46の画面とする。
2.2.3 データベース
検索するデータベースは商品マスターとし、所属項目は簡単に表15とする。
In general,
(1) If Set flag for each output item = On
(2) And update / delete key item set completion flag = ON
(3) And Output business conditions are met 2.2 Specific example: Purchase amount inquiry program In the specific example, the flow of the Lyee program including input / output processing is confirmed.
2.2.1 Process Outline Enter the product name and purchase quantity, and display the purchase price with discount rate and consumption tax.
2.2.2 Screen The screen shown in FIG.
2.2.3 Database The database to be searched is the product master, and the belonging items are simply shown in Table 15.
業務要件は表16とする。
割引率は購入数量と購入価格により異なることとする。 The discount rate depends on the purchase quantity and purchase price.
また商品マスターに商品名が無い場合はメッセージを出力することとする。 If there is no product name in the product master, a message is output.
上司プログラムのプログラムフローは図47となる。いままで説明しているようにプログラム構造は入力処理と業務処理が独立の“塊”となり、「入れ子」構造となっている。
初期処理の内容
一般的プログラムの初期処理と同様にトランザクションの開始、DBへのコネクト、ファイルOPENを行う。また、Lyeeプログラムの固有処理としては制御情報の初期化を行う。制御情報の項目名と初期化内容は表17である。
Contents of initial processing Starts a transaction, connects to a DB, and opens a file in the same way as the initial processing of a general program. Control information is initialized as specific processing of the Lyee program. Table 17 shows the item names and initialization contents of the control information.
図47に示す。なお、「初期処理」は領域初期化やトランザクション開始、Lyeeプログラム特有のフラグ類の初期化を行う。また、業務処理については、入力される「購入商品名」と「購入数量」の内容は出力しないものとした。出力する必要がある場合は該当の部下プログラムを作成し、上司プログラムよりCallする必要がある。
(3)入力処理の部下プログラム
商品マスター入力secや画面入力secのプログラムフローは以下(図48〜49)である。
業務アプリケーション処理の部下プログラム
各業務アプリケーション処理の部下プログラムのフローは第1部2章の部下プログラムフロー図2.18〜図2.21と同型である。
(3) Subordinate program of input processing The program flow of the product master input sec and the screen input sec is as follows (FIGS. 48 to 49).
Business Application Processing Subordinate Programs The flow of each business application processing subordinate program is the same type as the subordinate program flow diagrams 2.18 to 2.21 in
なお割引率20%セット条件は「購入数量」20個以上または「購入価格が1万円」以上が与件なので、フローの第1番目の判定は図50と「Or」判定が加わったものとなる。
(4)出力処理の部下プログラム
画面出力セクションのプログラムフローは以下(図51)である。
(5)終了処理
一般的なプログラムの終了処理と同様、必要に応じトランザクションのコミット/ロールバック、ファイルClose等の処理を行う。
2.3 まとめ
入出力処理を含めたLyeeプログラムフローの説明は以上である。要点としては以下の3点に要約できる。
(一)Lyeeプログラムは入力処理と業務処理、出力処理を独立化した‘塊‘とする。入力処理は業務処理を「入れ子」とする2重Loop構造をとる。
(二)入力処理群の完了判定後は以下となる
未完了の場合は、再度入力処理群へ制御を移す。
入力処理群が完了した場合は、出力処理へ制御を移す。
(三)出力処理では完了判定は行わないが、Lyeeプログラムの同型性を保つため上司/部下プログラムの構成とする。
3章 Lyeeプログラムの複数モジュール構成
この章ではプログラムの内部モジュールが複数となる場合のLyeeプログラミングを 説明する。これで実際のシステムで使用可能なLyeeプログラムが作成できる。
Since the 20% discount rate set condition is “Purchase quantity” of 20 pieces or “Purchase price is 10,000 yen” or more, the first judgment of the flow is the addition of FIG. 50 and “Or” judgment. Become.
(4) Subordinate program for output processing
The program flow of the screen output section is as follows (FIG. 51).
(5) End processing As with general program end processing, processing such as transaction commit / rollback and file close is performed as necessary.
2.3 Summary The above is the explanation of the Lyee program flow including input / output processing. The main points can be summarized in the following three points.
(1) The Lyee program is a lump that separates input processing, business processing, and output processing. The input process has a double loop structure in which business processes are “nested”.
(2) After the completion determination of the input processing group, if the following is incomplete, control is transferred to the input processing group again.
When the input process group is completed, control is transferred to the output process.
(3) Completion determination is not performed in the output process, but a supervisor / subordinate program configuration is used to maintain the homogeneity of the Lyee program.
なお稼動可能なプログラムやプログラム生成機能を作成する場合はJava、Cobol 等の言語文法や特性、稼動環境インターフェース規約を考慮しソースプログラムを 作成する必要があることは言うまでも無い。
3.1 Lyeeプログラムの複数モジュール化
第1部1章の図1.14〜図1.17で「複数モジュール対応のLyeeプログラム構成」の考え方を説明した。これをプログラムとしてどう実現するかを順次説明する。
Needless to say, when creating an operable program or program generation function, it is necessary to create a source program in consideration of language grammar and characteristics such as Java and Cobol, and operating environment interface rules.
3.1 Making the Lyee Program into Multiple Modules The concept of “Lyee Program Configuration for Multiple Modules” was explained in FIG. 1.14 to FIG. How this is realized as a program will be described in turn.
モジュールとは、一般的にプログラムを開発する場合、画面や帳票毎とかイベント毎とかをプログラム作成の単位とする。通常この決められた単位を更に機能的に分割して「ある塊」を作成する。この「塊」の呼び方はモジュール、セクション、サブプログラム、関数、オブジェクト等いろいろある。以降この「塊」を単にモジュールと呼ぶ。プログラムを更に分割した塊なので「内部モジュール」と呼ばれることも多い。(サブルーチンやオブジェクト等もLyeeプログラムで作成できることは言うまでもない。)
モジュールは機能的な「塊」として作成されるが、ここでの説明はLyeeプログラムの構造的な考えに従い「塊」を作成することとする。この目的は自動的に「モジュール構成」を決めることにある。(Lyeeプログラムのモジュールも保守容易性や企業の伝統的なモジュール化の考え方等を考慮して作成可能である。このことは現実的で実務的でもある。)
3.1.2 Lyeeプログラムのモジュールの機能
Lyeeプログラムのモジュール機能は前章までの(一)初期処理、(二)入力処理、(三)業務アプリケーション処理、(四)出力処理、(五)終了処理の5機能に(六)「モジュール制御」機能を加えた6機能で構成する。
In general, a module is a unit for creating a program when developing a program, such as a screen, a form, or an event. Usually, this determined unit is further functionally divided to create a “lumps”. There are various ways to call this “block”, such as modules, sections, subprograms, functions, and objects. Hereinafter, this “block” is simply referred to as a module. It is often called an “internal module” because it is a block that further divides the program. (It goes without saying that subroutines and objects can also be created with the Lyee program.)
The module is created as a functional “bulk”, but the explanation here is based on the structural idea of the Lyee program. The purpose is to automatically determine the “module configuration”. (Lyee program modules can also be created taking into account the ease of maintenance and the traditional way of modularizing companies. This is both practical and practical.)
3.1.2 Function of Lyee program module
The module functions of the Lyee program are (1) Initial processing, (2) Input processing, (3) Business application processing, (4) Output processing, and (5) End processing up to the previous chapter. (6) “Module control” Consists of 6 functions plus functions.
また領域構成は複数モジュール構造化により、モジュール共通領域と各モジュールの固有領域に分ける(図52及び表18)。 The area configuration is divided into a module common area and a unique area of each module by structuring a plurality of modules (FIG. 52 and Table 18).
Lyeeプログラムのモジュールは図53の階層構造で複数モジュール化を実現する。「親モジュール」から「子モジュール」、「子モジュール」から「孫モジュール」等の呼び出しと戻り(Call/Return)の制御はモジュール制御命令群が担う。 The module of the Lyee program realizes a plurality of modules in the hierarchical structure of FIG. The control of calling and returning (Call / Return) such as “parent module” to “child module” and “child module” to “grandchild module” is handled by the module control instruction group.
Lyeeプログラム内のモジュール分割の基準は次とする。(一)は一般的であるが(二)の入出力件数区分はLyeeプログラムの構造上およびプログラムの自動生成を容易に実施するためのモジュール分割基準である。この基準に従いプログラムのモジュール分割を行う。
(一)処理(イベント)・機能区分
(二)入出力件数区分
入出力件数単位とは、入力または出力が「1件」か「複数件」の処理かで区分する。
3.2 具体例:注文画面処理プログラム
「注文画面」処理の具体例でLyeeプログラムのモジュール分割とプログラムフローを概観する。
3.2.1 処理概要
画面遷移や各ボタン押下時の処理は以下(表19に示すとおり)である。
The criteria for dividing modules in the Lyee program are as follows. Although (1) is general, the input / output number category in (2) is a module division standard for the easy construction of the Lyee program and automatic program generation. The program is divided into modules according to this standard.
(1) Processing (event) / function classification
(2) Number of input / output cases The number of input / output cases is classified according to whether the input or output is “one” or “multiple”.
3.2 Specific Example: Order Screen Processing Program A specific example of the “order screen” process outlines the module division and program flow of the Lyee program.
3.2.1 Process Overview The process when the screen transitions and each button is pressed is as follows (as shown in Table 19).
図54の画面とする。
3.2.3 ファイル
検索や更新するファイルは表20とする。
3.2.3 Files Table 20 shows the files to be searched and updated.
なおログイン時に顧客コードが得られ「引継ファイル」にその情報が格納されているとする。ファイル編成は「引継ファイル」は順編成(テキスト)ファイル、他はデータベースとする。 It is assumed that a customer code is obtained at the time of login and the information is stored in the “takeover file”. As for file organization, “succession file” is a sequential organization (text) file, and others are databases.
業務アプリケーションの処理要件は表21とする。
(1)プログラムの単位
プログラムをどのような単位で作成するかをまず決めておく必要がある。ここでは画面単位にプログラムを作成するとする。(イベント単位でプログラムを作成する場合は各イベント内でのモジュール構成の検討となる。また複数画面をまとめて1つのプログラムとする場合は複数画面をまとめたモジュール構成の検討となる。)
(2)注文処理のモジュール分割
ア 注文画面の処理の単位(以降イベントと呼ぶ)は以下となる。
(一)初期起動
(二)金額計算ボタン押下
(三)発注ボタン押下
(四)クリアボタン押下
(五)戻るボタン押下
イ (一)〜(四)に共通している機能は画面の入出力処理であるため、まず画面の入出力処理を親モジュールとする。
(2) Module division of order processing a) The unit of order screen processing (hereinafter referred to as event) is as follows.
(1) Initial startup
(2) Press the amount calculation button
(3) Press the order button
(4) Press clear button
(5) Pressing the back button (a) Since the function common to (1) to (4) is the screen input / output processing, the screen input / output processing is first set as the parent module.
ウ (四)と(五)の処理は親モジュールで処理可能なので、子モジュールは作成しない。 C) Since the processing of (4) and (5) can be processed by the parent module, no child module is created.
エ 初期起動処理の顧客名を表示する処理は顧客マスターを1件読むので「1件処理」、購入商品コンボBoxの商品名表示処理は商品マスターの「複数件処理」である。 モジュール分割基準の入出力処理の「1件/複数件」区分に従い初期起動処理の 子モジュールは2モジュール構成となる。 D The process of displaying the customer name in the initial activation process reads one customer master, so “one process”, and the product name display process of the purchased product combo box is “multiple processing” of the product master. The child module of the initial startup process consists of two modules according to the “one / multiple cases” classification of the input / output process of the module division standard.
オ 金額計算処理は商品マスターを1件読めば良いので子モジュールは1モジュール
構成となる。
O The amount calculation process only needs to read one item master, so the child module is composed of one module.
カ 発注処理は各ファイルの1件「Select」処理や1件「Insert」処理のため子モジュールは1モジュール構成となる。
(3)モジュール構成
上記の検討より、モジュール構成は表22となりこれを図示すると図55となる。
The ordering process has one module configuration because each file has one “Select” process and one “Insert” process.
(3) Module Configuration From the above examination, the module configuration is shown in Table 22, and this is shown in FIG.
上司プログラムのフロー
各モジュールの上司命令群は参考資料2プログラムフロー参照(表23)。
「モジュール制御処理」のプログラムフローは参考資料2プログラムフロー参照(表24)。
なお、繰返:商品マスターを複数件読み、コンボBoxへ複数件出力することのためである。詳しくは3.3.2「自モジュール処理の繰返」参照。 Repeat: To read multiple product masters and output multiple items to the combo box. For details, refer to 3.3.2 “Repeat processing of own module”.
一般的な内容でモジュール制御を含めたプログラムフローを説明する。
3.3.1 モジュール制御機能
モジュール制御機能は一般的なプログラムと同様まず以下が必要である。
3.3.1 Module control function As with a general program, the module control function requires the following.
(一)「子モジュールへの遷移」
(二)「親モジュール(呼び元)へ戻る」
これに1プログラム1モジュール構成も考慮し、プログラムの制御機能として以下を加える。
(1) "Transition to child module"
(2) “Return to parent module (caller)”
Considering the configuration of one program and one module, the following is added as a program control function.
(三)「他プログラムへ遷移」
(四)「プログラムの終了」
これらの次にLyeeプログラム特有の5番目の機能を加える。その内容は例示の注文画面の購入商品コンボBoxの出力処理ファイルや全レコードを読むバッチ処理などのように、「入力処理と出力処理」を繰返す「複数件処理」が可能となるモジュール制御機能である。
「複数件処理」は当該モジュール内の入力処理、業務アプリケーション処理、出力処理の一連の処理を繰返し、処理終了条件(例えば全レコード読み込み完了)に合致するまで繰返すこととなる。
(3) "Transition to other programs"
(4) End of program
Following these, we add a fifth feature specific to the Lyee program. The content is a module control function that enables "multiple processing" to repeat "input processing and output processing", such as the output processing file of the purchased product combo box on the example order screen and batch processing that reads all records. is there.
“Multiple processing” repeats a series of processing of input processing, business application processing, and output processing in the module, and repeats until a processing end condition (for example, completion of reading of all records) is met.
(五)「自モジュール処理の繰返」
以上がLyeeプログラムのモジュール制御機能で、一覧表にまとめると表25となる。
(5) "Repeat processing of own module"
The above is the module control function of the Lyee program.
「自モジュール処理の繰返」はLyeeプログラム特有の機能であり、図56のように画面に「複数行」表示する場合や入力ファイルを1件読み、処理結果を1件出力する、2件目も同様に処理し、これを入力ファイルの全レコードについて行うような場合に適用する。
3.3.3 「自モジュール繰返」機能を加えた上司プログラム
「自モジュ−ル処理の繰返」機能を追加したLyeeプログラムの上司プログラムは図57のコーデング例となる。プログラムフロー図は参考資料2の図2.11参照。
3.3.3 Boss program with “Repeat own module” function The supervisor program of the Lyee program to which the “Repeat own module process” function is added is the coding example of FIG. See Figure 2.11 of
なおモジュール内の「初期処理」は以下の2区分に分けることとする(表26)。
(一)初期処理1:モジュール起動時の1回だけ行う処理
(二)初期処理2:「自モジュ−ル処理の繰返」の繰返処理ごとに実行する処理
The “initial processing” in the module is divided into the following two categories (Table 26).
(1) Initial processing 1: Processing to be performed only once at module startup
(2) Initial process 2: Process to be executed for each repetition process of “Repetition of own module process”
5種類のモジュール制御機能の適用順序はそれぞれの機能を考慮し、優先度に従ったプログラミングをする必要がある。ここはプログラムの順序性を考慮しソースプログラムを作成する。
(1)「他プログラムへ遷移」や「プログラム終了」
この条件が発生したら、すみやかに「他プログラムへ遷移」や「プログラム終了」処理を行い、当該プログラムは処理完了として良いので、他のモジュール制御機能に比べ適用順位は1位である。
(1) "Transition to other program" or "End program"
When this condition occurs, “transition to another program” or “program end” processing is immediately performed, and the program may be completed, so that the application order is first in comparison with other module control functions.
なお、実際のコーデングでは整形する必要があるが、処理を再開する点は業務処理からである。
(2)「親モジュールへの戻り」
この条件は自モジュールの処理が全て完了した段階(完了とは出力処理が終わったか、繰返し処理の終了条件に合致したかで判断する。)で処理する必要があるため、適用順位は最下位となる。
(3)「子モジュールへ遷移」と「自モジュール処理の繰返」
「自モジュール処理の繰返」の条件は、子モジュール処理が全て完了した後に「繰返処理」が行われる必要がある。このため、「子モジュールへ遷移」処理が「自モジュール処理の繰返」処理より適用順位は高い。
In actual coding, it is necessary to reshape, but the point at which the process is resumed is from the business process.
(2) “Return to parent module”
Since this condition needs to be processed at the stage where all the processing of the module itself is completed (completion is judged based on whether the output process is completed or the end condition of the repeated process is met), the application order is the lowest. Become.
(3) “Transition to child module” and “Repetition of own module processing”
The condition of “repeating own module processing” requires that “repeating processing” be performed after all child module processing is completed. For this reason, the “transition to child module” process has a higher application order than the “repeating own module process” process.
これらをまとめるとモジュール制御機能内での適用順位と適用条件は表27となる。 In summary, the application order and application conditions in the module control function are shown in Table 27.
モジュール制御命令群の処理開始は、一連の「入力処理と業務アプリケーション処理」が完了し、これ以上入力処理が行われない時点である。モジュール制御処理機能は表25の5種類である。
処理内容は機能どおりであるが、処理完了後の処理をどうするかに留意する必要がある。
例えば、複数の子モジュールがあった場合は「子モジュール1を実行後、親モジュールの業務処理と入力処理を行い」次ぎに「子モジュール2を実行しその後、親モジュールの業務処理と入力処理を行う」処理内容とする必要があることである。この理由は子モジュール実行後に親モジュールとして何らかの処理が実施できる可能性があるため、それを実施しておくことにある(表28)。プログラムフローは図58のコーデング例を参照されたい。
The contents of the processing are functional, but it is necessary to pay attention to what should be done after completion of the processing.
For example, when there are a plurality of child modules, “after executing
但し、図58で、「2.Call 初期処理1」は、当該モジュール処理を繰返す毎に領域を初期化する内容は「初期処理2」、当該モジュールが起動した時のみ領域を初期化する内容は「初期処理1」で行う。
However, in FIG. 58, “2. Call
モジュール制御処理の部下プログラムのフローは今までのフローと同様であるが、内容は2種類ある(表29)。 The flow of the module control processing subordinate program is the same as the flow so far, but there are two types of contents (Table 29).
子モジュールへ遷移する部下プログラムは子モジュール遷移条件に合致したら、実際に「子モジュールへ遷移」する。また子モジュールから戻った場合「モジュール制御実施フラグをOn」とするなど各種制御情報の記録を行う(図59)。
但し、同図において、「子モジュールXへ遷移すべきか」については、モジュール制御遂行判定は以下である。 However, in the figure, with regard to “whether to transition to the child module X”, the module control performance determination is as follows.
If (1)モジュール制御実施フラグ=Off
And (2)当該モジュール制御X実施フラグ=Off
And (3)モジュール制御の業務条件(業務条件例:「戻るボタン」押下 等)
3.4.2 子モジュール遷移以外の部下プログラム
子モジュール遷移以外のモジュール制御部下プログラムは情報をセットするだけを行い、上司プログラムで「自モジュールの繰返」等のモジュール制御機能の実現を図る(図60)。
If (1) Module control execution flag = Off
And (2) The relevant module control X execution flag = Off
And (3) Business conditions for module control (examples of business conditions: pressing “Back button”, etc.)
3.4.2 Subordinate programs other than child module transition Module control subordinate programs other than child module transition only set information, and the supervisor program realizes module control functions such as “Repeat own module” ( FIG. 60).
但し、同図において、「モジュール制御情報をセットすべきか」については、モジュール制御遂行判定は以下である。 However, in the same figure, as to “module control information should be set”, the module control performance determination is as follows.
If (1)モジュール制御実施フラグがOffか
And (2)当該モジュール制御Y実施フラグがOffか
And (3)モジュール制御の業務条件(業務条件例 「戻るボタン」押下 等)
また、「遷移先他プログラム名セット」はモジュール制御が「他プログラムへ遷移」で条件に合致する場合、「自モジュール繰返しフラグ=On」はモジュール制御が「自モジュール繰返」で繰返し条件合致する場合である。
3.4.3 制御情報(データ領域)
モジュール制御のための制御情報(データ領域)は、モジュール制御を完了したか否かの情報を管理するモジュール制御実施フラグや自モジュール繰返しフラグ、他プログラムへ遷移する場合の遷移先モジュール名等5種類を用意する(表30)。
If (1) Is the module control execution flag off?
And (2) Is the relevant module control Y execution flag off?
And (3) Module control business conditions (example of business conditions "Return button" pressed, etc.)
In addition, when the module control is "Transition to other program" and the condition is met for the "transition destination other program name set", the "Own module repeat flag = On" matches the repeat condition when the module control is "Own module repeat" Is the case.
3.4.3 Control information (data area)
There are five types of control information (data area) for module control, such as a module control execution flag that manages information on whether or not module control has been completed, a self-module repeat flag, and a transition destination module name when transitioning to another program Is prepared (Table 30).
4章 システム開発上の効果
Lyeeプログラムのプログラミング方法の特徴や説明を行って来たが、ここでは「は じめに」で述べたLyeeプログラムのシステム開発上の効果をまとめる。なおLyeeプログラムでシステム開発事例を参考資料3としてまとめてあるので参照されたい。
スピーデイなシステム開発
4.1.1 ソースプログラムの自動生成
前章までで説明して来たように、Lyeeプログラムは定型的なプログラム構造をしている。このため、出力項目についての計算式や条件、値のセット等の業務アプリケーション処理情報が得られれば、特定言語のプログラムソースを作成する「ソースジェネレータ」を作ることは容易に可能となる。特に「フレーム」だけでなく業務アプリケーション部分のソースプログラムも100%できることを強調したい。
We have explained the features and explanations of the programming method of the Lyee program. Here, we summarize the effects of the Lyee program on system development described in “Introduction”. Please refer to the
Speedy system development 4.1.1 Automatic generation of source program As explained in the previous chapter, the Lyee program has a typical program structure. Therefore, if business application processing information such as calculation formulas, conditions, and value sets for output items is obtained, it is possible to easily create a “source generator” that creates a program source in a specific language. In particular, I want to emphasize that not only “frames” but also source programs for business application parts can be made 100%.
なおソースジェネレータは稼動環境の各製品(OLTP、DBMS等)とのインターフェースは事前に雛型ソースを用意し、ソースジェネレータに取り込める形態となる。このため稼動環境の隠蔽やバージョンアップ対応も容易となる。(2005年4月現在、カテナ(株)で「LyeeALL」という製品を販売しており、複数の言語や稼動環境に対応している。)
4.1.2 業務要件の稼動基盤からの独立性
Lyeeプログラムの業務要件は「出力項目」の情報を決めることと、この「出力項目」単位に計算式や条件、値のセット方法を決めることである。これは画面や帳票、ファイル内容が決定されることにより、決めることができる事項であり、かつ稼動基盤と分離独立できる(表31)。
The source generator has a template source prepared in advance for the interface with each product (OLTP, DBMS, etc.) in the operating environment, and it can be imported into the source generator. For this reason, it is easy to conceal the operating environment and cope with version upgrades. (As of April 2005, Catena Co., Ltd. sells a product called “LyeeALL” that supports multiple languages and operating environments.)
4.1.2 Independence of business requirements from operating infrastructure
The business requirements of the Lyee program are to determine the information of “output items” and to determine the calculation formula, conditions, and value setting method for each “output item”. This is a matter that can be determined by determining the screen, form, and file contents, and can be separated and independent from the operating base (Table 31).
副題とした「データ指向プログラムの自動生成」の「データ指向プログラム」とは、この「表データ」=「データ指向」=「プログラム」という関係より命名しており、業務アプリケーションの要件をデータと同等に扱えることを意味している。
4.1.3 変数関係の順序未考慮
「出力項目」の計算式や条件、値のセット等のソースプログラムは処理順を考慮する必要がある。図61の例では、各処理は処理順に並んでいる必要からケース1としなければならない。
“Data-oriented program” of “automatic generation of data-oriented program” as a subtitle is named from the relationship of “table data” = “data-oriented” = “program”, and business application requirements are equivalent to data It means that it can be handled.
4.1.3 Order of variable relations not considered Source programs such as formulas, conditions, and value sets for “output items” need to consider the processing order. In the example of FIG. 61, since each process needs to be arranged in the processing order, it must be set to
Lyeeプログラムはプログラムの構造上“いつか”は「AやBが満たされ」結果的に「C=A+B」の計算が行われるめ、図61のケース1でもケース2でも処理は可能である。図61は簡単な例であるが、項目数が多い場合や複数個の「入れ子」構成の関数と変数の関係でもそれぞれの関数式さえ明確化できれば‘いつか’は「各変数が満たされ(値がセットされ)」最終的に関数の計算が完了する。(以下のような関数でも並び順に無関係で順次値が得られることにより最終的にYの値が得られる:Y=F(g、h) g=G(g1、g2) h=H(h1) g1=x1、g2=x2、h1=x3)「はじめに」で述べた「従来の意味でのプログランミニングが不要」とはこのことを指している。
The Lyee program can be processed in either
この変数間の関係の処理順序を考慮しないで良いことは、プログラム作成上、プログラムの生産性や品質に多大な効果をもたらす。
品質の向上とテスト工程の削減
システム開発のテスト工程はプログラム単体のテストやファイル、画面遷移等を含めた結合テスト、総合テスト等により順次システム内容を確認し、プログラムの誤りを修正していく。Lyeeプログラムはプログラム構造が確定しているため、プログラム処理誤りが比較的少なく、かつ誤り個所の発見が容易にできる。このため単体テストのテスト期間や工数は短くて済む。
The fact that it is not necessary to consider the processing order of the relationship between the variables has a great effect on the productivity and quality of the program in creating the program.
Improvement of quality and reduction of test process In the system development test process, the contents of the system are checked in sequence by a unit test including a single program test, file, screen transition, etc., and a comprehensive test, and the error of the program is corrected. Since the program structure of the Lyee program is fixed, program processing errors are relatively small, and the error location can be easily found. For this reason, the test period and man-hour of the unit test can be shortened.
なお結合テスト、総合テストの場合は画面やファイル設計等に関係している部分が多いため、プログラム単体の品質が良いことが効率化に貢献する。
4.2 保守作業の効率化
4.1で述べたプログラムのスピーデイな開発が可能なことは、プログラム保守の変更・追加作業でも効果が発揮され、作業の容易化、効率化が図られる。
In addition, since there are many parts related to the screen and file design in the integration test and the comprehensive test, a good quality of the program alone contributes to efficiency.
4.2 Improving the efficiency of maintenance work The speedy development of the program described in 4.1 is effective even when program maintenance is changed or added, thereby facilitating and improving the efficiency of the work.
一般的にプログラムは標準化して作成するが、保守作業では「変更箇所の確定」や「影響範囲の調査」、「レベルダウン防止のテスト確認」などに多大な時間がかかってしまう状況である。それに加え担当者が変わることや、プログラム修正が繰り返されることで、更に作業効率は悪化する。 Generally, the program is standardized and created, but in the maintenance work, it takes a lot of time to “confirm change location”, “examination of influence range”, “confirmation of level down prevention test” and the like. In addition to this, the work efficiency is further deteriorated by changing the person in charge and repeating the program correction.
Lyeeプログラムはプログラムが「表データ的」であり、「変数関係の順序未考慮」となっているため、要件の「変数関係」が変わるか否かしか考慮する必要が無く修正できる(表32)。 The Lyee program is “table-data-like” and is “not considering the order of variable relationships”, so it can be corrected without having to consider only whether or not the “variable relationship” of requirements changes (Table 32). .
4.3 業務アプリケーション定義書類の削減
プログラムの業務アプリケーション定義書は、プログラム制御に係わる記述が不要となるため記述量が少なくて済み、定義書の量的な削減が図られる。
4.3 Reduction of business application definition documents Since the business application definition document of a program does not require a description related to program control, the amount of description can be reduced and the definition document can be reduced in quantity.
また、ソースプログラムと業務アプリケーション定義書内容の同期を取ることへの多大な努力を各社行っているが、Lyeeプログラムのアプリケーション定義書は「項目名と要件」が対となっている表データ形式であるため、プログラムと定義書の同期が容易に取ることができる。
4.4 多種なフレームとの共存
第2部1章でMDAのフレームワークの中でのLyeeプログラムの機能と位置付けを説明した。LyeeプログラムはMDAで規定するSIMとPSMそれぞれに対応可能である。またLyeeプログラムはプログラム構造のみを規定しているため、MDA以外のフレームワークで規定しているフレームにも容易に対応可能と考えられる。
4.5 課題
前述のような効果は期待できるが、以下の課題も存在している。Lyeeプログラミングがより広範に活用されることにより、これら課題に対してもよりよい対応案が出来てくることと思われる。
4.5.1 配列の処理
一般的に2次元、3次元等の配列としてデータ処理を行うことが多い。例えば、月別支店別の売上金額を求める場合、表33のコーデングをする場合が多い。
Each company makes great efforts to synchronize the contents of the source program and business application definition document, but the application definition document of the Lyee program is a tabular data format in which "item name and requirement" are paired. As a result, the program and the definition document can be easily synchronized.
4.4 Coexistence with
4.5 Issues Although the effects described above can be expected, the following issues also exist. By using Lyee programming more widely, it seems that better solutions to these issues can be made.
4.5.1 Array Processing In general, data processing is often performed as a two-dimensional or three-dimensional array. For example, when the sales amount for each monthly branch is obtained, the coding shown in Table 33 is often performed.
プログラムを作成する上で、使用しているデータ領域をいつ初期化するかは単純ではない。またこの領域初期化条件をあまり複雑化してしまうと、分かり難いプログラムとなってしまう。Lyeeプログラムでは現在は表35のNo1の内容で領域の初期化を行っているが、必ずしも作業者に理解され易い内容とはなっていない。特に合計を求める場合や突合(マージ)処理での新/旧のキー値比較などを表35のNo1で実施した場合「Lyeeプログラム特有」の処理となる感じは拭えない。これらを隠蔽した方法などが今後の課題である。
昨今はCPUの処理能力やメモリ容量、OSのアドレス空間など急激に拡張増大されている。このため、Lyeeプログラムの冗長なソースコードでも特段の問題は無い場合が多いが、一定の考慮をしておく必要がある。
レスポンス時間等の処理完了時間はLyeeプログラムと一般のプログラムとの差は一概には言えないが、Lyeeプログラムの繰返すことで値が成立する構造からすると、CPU時間は相対的に長いと考えられる。しかし、CPU時間は千分の1秒以下の単位が通常であるため、このCPU時間が長いことによる問題は、既にLyeeプログラムで作成され本番稼動しているシステムで発生していない。ただし、ファイル設計やSQLの作り方により処理完了時間は大きく変動するため、一般のプログラムで開発すると同様にこれらは十分検討してシステムを構築する必要がある。
参考資料1 無限ループ防止仕様の詳細説明
1部の1.2.2「上司プログラムの構造」や2.1.2「上司プログラムの完了判断の方法」および第2部の2.1.1「入力処理の上司プログラム」等でプログラムの仕様上無限ループが起こらない旨の説明をしているが、ここでまとめてその仕組みを説明する。
1 業務処理の上司プログラム
第1部2章の購入金額計算上司プログラムのフローは以下(図62のとおり)である。(以降この具体例で説明する。項目数が増えても無限ループ回避の仕組みは変わらない。)
(1)無限ループの検討をするため図63のループ部分のフローに注目し、各命令に(一)、(二)と番号を付番する。ループが終了するためには(一)の判定で「業務実施フラグ」が「Off」であれば良い。すなわち、3個の部下プログラムの中で「業務実施フラグ」 が「Off」のままとなれば良い。
(2)図64が部下プログラムの一般形である。部下プログラムの(一)の判定で「No」と判断されると「業務実施フラグ」は「On」とはならない。このため部下プログラで(一)の判定が全て「No」と判断されることが必ず起こるか否かが問題である。必ず起こるとすれば、無限ループは回避できる。
(3)図63に対応する3個の部下プログラムを図65のようにN回ループを繰返すと以下の状態となる。
The processing completion time such as response time cannot be generally described as the difference between the Lyee program and the general program, but the CPU time is considered to be relatively long from the structure in which the value is established by repeating the Lyee program. However, since the CPU time is usually a unit of 1 / 1,000 second or less, the problem due to the long CPU time does not occur in a system that has already been created and operated in the Lyee program. However, since the process completion time varies greatly depending on the file design and SQL creation method, it is necessary to construct a system by carefully considering these as well as developing with a general program.
Program 1.2.2 “Supervisor Program Structure”, 2.1.2 “Supervisor Program Completion Judgment Method” and Part 2.2.1.1 “Supervisor Program for Input Processing” Although it is explained that an infinite loop does not occur in the specification, here is a summary of the mechanism.
1 Business Process Supervisor Program The flow of the purchase price calculation supervisor program in
(1) Pay attention to the flow of the loop portion of FIG. 63 in order to examine the infinite loop, and number each instruction with (1) and (2). In order to end the loop, it is sufficient that the “task execution flag” is “Off” in the determination of (1). In other words, the “work execution flag” should remain “Off” among the three subordinate programs.
(2) FIG. 64 shows a general form of a subordinate program. If “No” is determined in (1) of the subordinate program, the “business execution flag” is not “On”. For this reason, it is a problem whether subordinate programs are always judged as “No” in (1). An infinite loop can be avoided if it always happens.
(3) When the three subordinate programs corresponding to FIG. 63 are repeated N times as shown in FIG. 65, the following state is obtained.
ケース1:ある部下は図64の「当該IDnに必要な命令」が実施され「部下nセット完了フラグ」がOnとなっている。 Case 1: For a certain subordinate, the “instruction required for the IDn” in FIG. 64 is executed and the “subordinate n set completion flag” is On.
N+1回目では条件4に合致しないため1番目の判定は「No」となる。
In the (N + 1) th time, since the
ケース2:ある部下は図64の「当該IDnに必要な命令」は実施されず「部下nセット完了フラグ」はOffのままである。N+1回目でも条件2、3、5のどれかにより1の判定は「Yes」とはならないため、6は実施されず、8のフラグはOffのままである。
Case 2: A certain subordinate does not execute the “instruction necessary for the IDn” in FIG. 64 and the “subordinate n set completion flag” remains Off. Even in the N + 1th time, the determination of 1 is not “Yes” due to any of the
そこで、N+1回目では全ての部下プログラムで新たに図64の6が実施されないので7も実施されない。このことで、結局「業務実施フラグ」はOffのままであり、無限ループは回避される。
(4)別の観点では、図64の6が1度実施されれば8で「部下nセット完了フラグ」 がOnとなり、以降、部下nプログラムに制御が移っても、1の判定は4により常 に「No」と判断され、「業務実施フラグ」はOffのままである。
Therefore, in the (N + 1) th time, since 6 of FIG. 64 is not newly implemented in all subordinate programs, 7 is not also implemented. As a result, the “business execution flag” remains Off, and an infinite loop is avoided.
(4) From another point of view, if 6 of FIG. 64 is executed once, the “subordinate n set completion flag” is turned on in 8 and the control of the sub n program is subsequently transferred. It is always judged as “No”, and “Business implementation flag” remains Off.
また部下プログラムの中では「あるデータ」では図63のループ処理を何回繰返 しても、図64の2、3、5に該当せず、常に1の判定はNoとなるものもある。こ の場合は「業務実施フラグ」はOffのままとなる。 In some subordinate programs, “some data” does not correspond to 2, 3 and 5 in FIG. 64, no matter how many times the loop processing in FIG. 63 is repeated, and the determination of 1 is always No. In this case, the “business execution flag” remains Off.
よって図63のループは、いつかは「業務実施フラグ」がOffとなり、無限ループ は起こらない。なお最大ループ回数は部下プログラムの数と等しくなる。
2 入力処理を含めた上司プログラム
2部2章2.1.1では入力処理を含めた上司プログラムフローは以下(図66に示すとおり)である。
「1 業務処理の上司プログラム」で述べたとおり、図66の下半分の業務処理部分は無限ループしない。このため入力処理を含めた上司プログラムフローは図67に単純化しても問題はない。
Therefore, in the loop of FIG. 63, the “business execution flag” will be turned off at some point and an infinite loop will not occur. The maximum number of loops is equal to the number of subordinate programs.
2 Supervisor Program Including Input Processing In
As described in “1 Business Process Supervisor Program”, the business process part in the lower half of FIG. 66 does not endlessly loop. Therefore, there is no problem even if the boss program flow including input processing is simplified to FIG.
図67のループが終了するためには1の判定で「入力実施フラグ」がOffであ れば良い。 In order to end the loop of FIG. 67, it is only necessary that the “input execution flag” is OFF in the determination of 1.
図1.7が入力処理の部下プログラムの一般形である。1の判定で「No」と判断されると「入力実施フラグ」は「On」とはならない。このため全ての部下入力プログラムの判定で「No」と判断されることが必ず起これば、無限ループが回避できる。 Figure 1.7 shows the general form of a subordinate program for input processing. If “No” is determined in the determination of 1, the “input execution flag” is not “On”. For this reason, an infinite loop can be avoided if it is determined that all subordinate input programs are determined to be “No”.
図67に対応した2個の入力処理の部下プログラムを想定し、図69のN回ループを繰返すと以下の状態となる。
ケース1:ある部下入力プログラムは図68の4が実施され7または10のフラグがOnとなっている。N+1回目の処理では条件3により1判定はNoとなる。
ケース2:ある部下入力プログラムは図68の4が実施されず7または10も実施されない。このため、「入力処理n実施フラグ」はOffのままである。N+1回目の処理でも4は実施されない。これは条件2、4のどれかにより1の判定はYesとならない。
Assuming two input processing subordinate programs corresponding to FIG. 67 and repeating the loop N times in FIG. 69, the following state is obtained.
Case 1: For a certain subordinate input program, 4 in FIG. 68 is executed, and the 7 or 10 flag is On. In the N + 1th process, 1 determination is No due to
Case 2: For a certain subordinate input program, 4 in FIG. 68 is not performed and neither 7 nor 10 is performed. For this reason, the “input processing n execution flag” remains Off. 4 is not performed even in the N + 1th processing. This is because the determination of 1 does not become Yes due to any of
そこで、N+1回目の処理では、全ての部下入力プログラムは図68の1の判定でNoとなる。すなわち、「入力実施フラグ」はOffのままであり、無限ループは回避される。
3 自モジュールの繰返について
自モジュールの繰返し処理を加えると図70のプログラムフローとなり、ここでも無限ループが起こる可能性がある。
Therefore, in the (N + 1) th process, all subordinate input programs are No in the determination of 1 in FIG. That is, the “input execution flag” remains Off, and an infinite loop is avoided.
3 Repeating of own module When the repetition processing of its own module is added, the program flow of FIG. 70 is obtained, and an infinite loop may also occur here.
自モジュールの繰返しを停止する条件は表36のような業務要件に従う。この停止条件は自モジュールの繰返し処理には存在するので、条件設定誤り以外は必ず繰返しは停止される。 Conditions for stopping the repetition of the own module comply with business requirements as shown in Table 36. Since this stop condition exists in the repetition process of the own module, the repetition is always stopped except for the condition setting error.
複数モジュール構成となった場合、無限ループは起こらないか?につき考察する。
まず、最下位のモジュールは前述の説明で無限ループは起こさない。この結果その上位の階層のモジュールも無限ループは起きない。これを最終的な最上位のモジュールまでも同様な論理で考えることができる。結局複数モジュール構成となっても、無限ループは起きない。
参考資料2 プログラムフローの補足
2部の3.2「具体例:商品注文プログラム」の上司プログラムフローやモジュール制御処理の部下プログラムフローは以下(図71に示すとおり)となる。
1 商品注文画面の親モジュールの上司プログラムフロー
図71に示すとおりである。なお、同図において、部下12から14は2部3章の3.2.4の業務要件より3種類のメッセージが必要のため作成している。
2 商品注文画面の子モジュール1の上司プログラムフロー
引継ぎファイルと顧客マスターを読む処理である(図72)。
3 商品注文画面の子モジュール2の上司プログラムフロー
商品マスターを読み商品名コンボBox内容を複数件出力処理である(図73)。
4 商品注文画面の子モジュール3の上司プログラムフロー
選択された商品名で商品マスターを読む処理である(図74)。
5 商品注文画面の子モジュール4の上司プログラムフロー
商品マスターと採番テーブルを読み、受注マスターの登録と採番テーブルの更新を行う 処理である(図75)。
6 「親モジュールへ戻る」の部下プログラムフロー
商品注文画面の子モジュール1の「親モジュールへ戻る」モジュール制御の部下プログラムフローは以下(図76に示すとおり)である。
7 「子モジュール1へ遷移」の部下プログラムフロー
商品注文画面の親モジュールの「子モジュール1へ遷移」のモジュール制御の部下プログラムフローは以下(図77に示すとおり)である。
8 「子モジュール4へ遷移」の部下プログラムフロー
商品注文画面の親モジュールの「子モジュール4へ遷移」のモジュール制御の部下プログラムフローは以下(図78に示すとおり)である。
9 「メニュープログラムへ遷移」の部下プログラムフロー
商品注文画面の親モジュールの「メニュープログラムへ遷移」のモジュール制御の部下プログラムフローは以下(図79に示すとおり)である。
10 「自モジュール繰返」の部下プログラムフロー
商品注文画面の子モジュール2の「自モジュール繰返」のモジュール制御の部下プログラムフローは以下(図80に示すとおり)である。
11 「自モジュール処理の繰返」を加えたの上司プログラムフロー(図81)
12 モジュール制御処理を含めた上司プログラムフロー(図82)
参考資料3 Lyeeプログラム実績(図83) 2005年4月現在
参考資料4 ソース生成ツール入力例
<購入金額計算>
画面(図84)
(2)要件(図85)
(3)ソース生成ツールへの入力内容
ア 上司プログラム関連
(ア)入出力情報(図86)
入出力情報と項目・属性
購入金額計算画面:KEISAN_gm
(図87)
商品マスター:GoodsMF
(図88)
イ 部下プログラム関連(図89)
<購入金額照会>
画面(図90)
要件(図91)
ソース生成ツールへの入力例
ア 上司プログラム関連
入出力情報(図92)
入出力情報と項目・属性
購入金額照会画面:Syoukai_gm
(図93)
商品マスター:GoodsMF (図94)
イ 部下プログラム関連(図95)
なお、本発明は、上述した実施形態および実施例には限定されず、本発明の技術思想の範囲内で様々な変形が可能である。
First, the lowest module does not cause an infinite loop as described above. As a result, an infinite loop does not occur in the higher-level module. The same logic can be applied to the final top-level module. Eventually, an infinite loop does not occur even if it has multiple modules.
1. Manager program flow of parent module of product order screen As shown in FIG. In this figure, subordinates 12 to 14 are created because three types of messages are required from the business requirements of 3.2.4 of
2 The supervisor program flow of the
3. The supervisor program flow of the
4 Program flow of the supervisor of the
5 Supervisor program flow of
6 Subordinate program flow of “return to parent module” The subordinate program flow of “return to parent module” module control of
7 Subordinate Program Flow of “Transition to
8 Subordinate Program Flow of “Transition to
9. Subordinate program flow of “transition to menu program” The subordinate program flow of module control of “transition to menu program” of the parent module of the product order screen is as follows (as shown in FIG. 79).
10 Subordinate Program Flow of “Self Module Repeat” The subordinate program flow of “Self Module Repeat” module control of
11 Boss program flow with "Repeat module processing" added (Fig. 81)
12 Boss program flow including module control processing (Figure 82)
Screen (Fig. 84)
(2) Requirements (Figure 85)
(3) Input contents to the source generation tool A. Related to supervisor program (A) Input / output information (Fig. 86)
Input / output information and item / attribute purchase price calculation screen: KEISAN_gm
(Fig. 87)
Product Master: GoodsMF
(Fig. 88)
(I) Subordinate programs (Figure 89)
<Purchase price inquiry>
Screen (Fig. 90)
Requirements (Figure 91)
Example of input to the source generation tool a. Boss program related input / output information (Figure 92)
Input / output information and item / attribute purchase price inquiry screen: Syoukai_gm
(Fig. 93)
Product Master: GoodsMF (Fig. 94)
(I) Subordinate programs (Figure 95)
The present invention is not limited to the above-described embodiments and examples, and various modifications can be made within the scope of the technical idea of the present invention.
たとえば、上記した適用例に本願は限定されることなく、種々の機能を実現するいかなるシステム開発に対しても本願は適用可能であり、かかる本願の適用された各対象は当該対象物固有の効果を奏する。 For example, the present application is not limited to the application examples described above, and the present application can be applied to any system development that realizes various functions, and each object to which the present application is applied has an effect unique to the object. Play.
さらに本願発明は、その技術思想の同一及び等価に及ぶ範囲において様々な変形、追加、置換、拡大、縮小等を許容するものである。また、本願発明を用いて生産される装置、方法、ソフトウェア、システムが、その2次的生産品に登載されて商品化された場合であっても、本願発明の価値は何ら減ずるものではない。 Furthermore, the present invention allows various modifications, additions, substitutions, expansions, reductions, etc. within the scope of the same and equivalent technical idea. In addition, even if an apparatus, a method, software, and a system that are produced using the invention of the present application are listed as a secondary product and commercialized, the value of the invention of the present application is not reduced at all.
本発明によれば、ソースプログラムの自動生成が可能になり、業務要件の稼動基盤からの独立性が確保され、変数関係の順序を考慮する必要がなくなり、さらに、品質の向上とテスト工程の削減がなされることで、スピーデイなシステム開発が可能となる。 According to the present invention, it is possible to automatically generate a source program, the independence of business requirements from the operating base is ensured, there is no need to consider the order of variable relations, and quality is improved and test processes are reduced. As a result, speedy system development becomes possible.
さらに、プログラムのスピーデイな開発が可能なことは、プログラム保守の変更・追加作業でも効果が発揮され、作業の容易化、効率化が図られる。 Furthermore, the fact that programs can be developed quickly is effective even in program maintenance change / addition work, and facilitates and improves work efficiency.
またさらに、プログラムの業務アプリケーション定義書は、プログラム制御に係わる記述が不要となるため記述量が少なくて済み、定義書の量的な削減が図られる。 Furthermore, since the business application definition document of the program does not require a description related to program control, the amount of description is small, and the amount of definition document can be reduced.
さらに、LyeeプログラムはMDAで規定するSIMとPSMそれぞれに対応可能である。またLyeeプログラムはプログラム構造のみを規定しているため、MDA以外のフレームワークで規定しているフレームにも容易に対応可能である。
よって本発明は、いかなる用途、或いはネットワークを介して配信され若しくはスタンドアローンを問わずあらゆる存在形態におけるソフトウェア、及びソフトウェアの生産方法にも適用できる。
Furthermore, the Lyee program is compatible with both SIM and PSM defined by MDA. Also, because the Lyee program only defines the program structure, it can easily handle frames defined by frameworks other than MDA.
Therefore, the present invention can be applied to software in any form of existence regardless of use, distribution over a network, or stand-alone, and a software production method.
sec セクション
MDA モデリング駆動型アーキテクチャ
sec section MDA modeling driven architecture
Claims (1)
要件の過不足を調整する第2のステップと、
前記第2のステップで調整されたデータをソフトウェアの必須要素としてLyee所与のプログラム構造をもつ自動生成ツールに入力することにより所望のソフトウェアの目的コードを得る第3のステップと
を具備するソフトウェア生成方法において、
前記Lyee所与のプログラム構造においては入力処理と業務処理、出力処理を独立化し、入力処理は業務処理を「入れ子」とする2重Loop構造をとり、入力処理群の完了判定後は、未完了の場合は、再度入力処理群へ制御を移し、入力処理群が完了した場合は、出力処理へ制御を移し、出力処理では完了判定は行わずに上司/部下プログラムの構成とすることを特徴とするソフトウェア生成方法。 A first step of defining a predetermined attribute as data in units of words belonging to each logical body based on a requirement definition;
A second step of adjusting the requirement deficiency,
A third step of obtaining a target code of the desired software by inputting the data adjusted in the second step as an essential element of the software into an automatic generation tool having a given program structure. In the method
In the above-mentioned Lyee program structure, input processing, business processing, and output processing are independent, and the input processing has a double loop structure in which the business processing is “nested”, and after completion of the input processing group is determined to be incomplete In this case, the control is transferred to the input processing group again, and when the input processing group is completed, the control is transferred to the output processing, and the completion of the output processing is not performed and the supervisor / subordinate program is configured. To generate software.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005124245A JP2008171023A (en) | 2005-04-21 | 2005-04-21 | Software creation method |
PCT/JP2006/308475 WO2006115229A1 (en) | 2005-04-21 | 2006-04-21 | System program, processor, recording medium, program creating assisting device, data structure, and program creating method |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005124245A JP2008171023A (en) | 2005-04-21 | 2005-04-21 | Software creation method |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2008171023A true JP2008171023A (en) | 2008-07-24 |
Family
ID=37214844
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2005124245A Pending JP2008171023A (en) | 2005-04-21 | 2005-04-21 | Software creation method |
Country Status (2)
Country | Link |
---|---|
JP (1) | JP2008171023A (en) |
WO (1) | WO2006115229A1 (en) |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002312167A (en) * | 2001-04-13 | 2002-10-25 | Fujitsu Ltd | Program for making computer calculate value of variable, compile program, variable value determining method, and program generating method |
WO2005029322A1 (en) * | 2003-09-22 | 2005-03-31 | Catena Corporation | Software generation method |
EP1693745A4 (en) * | 2003-09-22 | 2007-03-07 | Catena Corp | Software generation method |
-
2005
- 2005-04-21 JP JP2005124245A patent/JP2008171023A/en active Pending
-
2006
- 2006-04-21 WO PCT/JP2006/308475 patent/WO2006115229A1/en active Application Filing
Also Published As
Publication number | Publication date |
---|---|
WO2006115229A1 (en) | 2006-11-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
RU2390822C2 (en) | Method and device for creating user interfaces based on automation with possibility of complete setup | |
CN100461158C (en) | Method for processing data using application program | |
US7266549B2 (en) | Optimization using a multi-dimensional data model | |
US20110161371A1 (en) | Sql generation | |
JPH11296586A (en) | Production management system and computer-readable recording medium where production managing program is recorded | |
JP2008512794A (en) | Object processing graph application development system | |
US5394546A (en) | Database management system and method of extending system functions | |
CN111784108B (en) | Modeling method and device of main data management platform | |
JPH09198240A (en) | Mock-up method and controller therefor | |
JP7339628B2 (en) | Online report creation system using Excel tools | |
JP3577400B2 (en) | System design equipment and data warehouse design system | |
US7076779B2 (en) | System for controlling and monitoring a process | |
Parfitt et al. | Computer-integrated design drawings and construction project plans | |
JP2008171023A (en) | Software creation method | |
JPH1097417A (en) | Program assembling device and storage medium | |
US20060026522A1 (en) | Method and apparatus for revising data models and maps by example | |
WO2012137390A1 (en) | Parallelized design assistance system, program, and method | |
JP7216377B2 (en) | Online reporting system with query binding capabilities | |
JPH06230957A (en) | Check list system | |
JPH10254691A (en) | Support method for developing program and storage medium having program for implementing the same | |
US11977866B2 (en) | Application screen display program installing method | |
CN117632997A (en) | Command line interface crossing database platform and read-write operation method | |
CN114356394A (en) | Multi-version development method based on AutoCAD | |
Bojčetić et al. | A TOOL FOR SUPPORTING THE PROCESS OF PROPERTY MANAGEMENT AND THE CREATION OF TECHNICAL DRAWINGS. | |
WO2006025472A1 (en) | Processing path creating method on the basis of lyee methodology, creating device, software creating method, creating device, software, and development assisting software |