JP2000089945A - 統合型ソフトウエア開発支援システム - Google Patents

Abstract

(57)【要約】 【課題】 制御論理、及び制御論理を規定したソースプ
ログラムの内容を把握でき、保守性を向上させる統合型
ソフトウエア開発支援システムを提供する。 【解決手段】 基本設計部１２及び詳細設計部１３で作
成された設計情報に基づいてプログラム自動生成部１４
及びコーディング部１５でプログラムコードを編集する
際に、自動生成されたプログラムコードについてはその
修正等ができないようにし、設計情報とプログラムコー
ドとの一貫性を確保する。また、リポジトリは上流側ツ
ール用のみを設け、下流側ツールでは、このリポジトリ
を参照専用に変換したインタフェースファイルを用い
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ソフトウエア開発
に用いられる統合化ソフトウェア開発システムに関す
る。あるソフトウエアを開発する場合、設計、製造、試
験の各フェーズを経るのが通常である。本発明は、これ
らのフェーズを統合的に支援するための新規な手法に関
する。

【０００２】

【従来の技術】システム計画から保守／運用までのソフ
トウエア開発工程全般をカバーする統合型ソフトウエア
開発支援システムが知られている。このような統合型ソ
フトウエア開発支援システムは、統合ＣＡＳＥツール
（Computer Aided Software Engineering Tool）とも呼
ばれ、上流ＣＡＳＥツールと下流ＣＡＳＥツールとを単
に組み合わせた場合に比べて、両者の連携が密接である
ことに特徴がある。しかし、従来の統合ＣＡＳＥツール
は、開発するホストマシンが決定されてしまうことか
ら、複数のホストマシンで動作するプログラムを開発す
るためには、必然的にＣＡＳＥツールを組み合わせて使
用する必要があった。

【０００３】ソフトウエア開発に際しては、構造化プロ
グラミング技法で使用するビジュアルな表記法を用いた
各種ダイヤグラムを使う。上流側ソフトウエア開発支援
システム（以下、「上流側ツール」）で定めた設計情
報、具体的にはダイヤグラム情報、ファイル仕様、アプ
リケーション（以下、「ＡＰ」）テーブル仕様等のデー
タ項目定義情報等を生かして下流側ソフトウエア開発支
援システム（以下、「下流側ツール」）を用いた作業を
行うことができ、最後にソースプログラムを自動生成す
る。その際、上流側ツールにより参照されるリポジトリ
を下流側ツールにより参照されるリポジトリに変換して
両者を連携させ、ソースプログラムに不備が生じたとき
は、上流側ツールに戻って該当個所を修正している。

【０００４】

【発明が解決しようとする課題】従来の統合ＣＡＳＥツ
ールには、以下のような問題点があった。 （１）上述のように、自動生成されたソースプログラム
に設計情報にはない制御論理を追加したり、設計情報の
内容と異なるコーディングの削除を行う必要が生じた場
合は、上流側ツールに戻って該当個所の設計情報である
ダイヤグラム情報を修正するのが原則であるが、ソース
プログラムの修正を迅速に行うために、それを下流側ツ
ールで直接行う場合がある。しかし、これを無秩序に行
うと、上流側ツールで定めた設計情報とソースプログラ
ムとが１対１に対応しなくなるため、ソースプログラム
の内容を設計情報だけで把握することができなくなり、
保守性が低下する（第１の問題点）。そこで本発明の第
１の課題は、設計情報を参照するだけでソースプログラ
ムの内容を把握でき、保守性を向上させる手法を提供す
ることにある。

【０００５】（２）また、上記のように設計情報から直
接自動生成されたソースプログラムに追加コーディング
を施した後、設計情報に変更が生じて再度ソースプログ
ラムを自動生成すると、追加コーディングの部分は直接
には反映されない。そのため、再生成前のソースプログ
ラムからカット・アンド・ペーストによって追加コーデ
ィングの部分を復活させる必要があり、手間がかかるう
えに信頼性に不安があるという問題があった（第２の問
題点）。そこで、本発明の第２の課題は、追加コーディ
ングされた部分を新しいソースプログラムに自動的に反
映させる仕組みを構築することにある。

【０００６】（３）上述のように、従来は、上流側ツー
ルにより参照されるリポジトリを下流側ツールにより参
照されるリポジトリに変換して両者を連携させている。
そのため、上流側ツールと下流側ツールとでそれぞれ独
立のリポジトリを保持して設計情報を二重に管理するこ
とになり、設計工程からプログラム製造工程まででの情
報に一貫性をもたせることが難しくなる。例えば下流側
ツールで発見された設計バグは、上流側ツールまで戻っ
て修正し、これを上流側ツールのリポジトリに反映させ
るとともに下流側ツールのリポジトリにも反映すること
により連携がとられるのが本来の手法であるが、設計工
程はＡ社、プログラム製造工程はＢ社が担当する場合に
は、連絡ミスや設計工程まで戻る修正作業に時間がかか
ることを回避するあまり、設計工程まで戻らずにプログ
ラム製造工程で下流側ツールのリポジトリを直接修正す
ることが多々ある。このような場合は、２つのリポジト
リが不整合となる（第３の問題点）。そこで本発明の第
３の課題は、設計情報の二重管理とそれによる設計情報
の不整合を回避することができる手法を提供することに
ある。

【０００７】（４）ところで、複数のベンダのホストで
動作するソースプログラムを作成する場合、汎用マシン
である程度の動作確認を行った後、そのホストにソース
プログラムを転送して最終的な動作確認を行う開発形態
をとることが多くなっている。その中で、例えばＣＯＢ
ＯＬ（Common Business Oriented Language）プログラ
ムを生成する場合、記述ステップ数の削減及び品質の向
上のため、作成済みのプログラムの一つであるＣＯＰＹ
原文を取り込む方式（＝「ＣＯＰＹ文」）が知られてい
る。この方式では、汎用マシンとホストとで、それぞれ
ＣＯＰＹ原文を管理する必要があるため、ＣＯＰＹ原文
にいくつかのバージョンが存在する場合、ホストと汎用
マシンとの間で取り込みを行うべきＣＯＰＹ原文のバー
ジョンを取り違える可能性がある。そのため、多くのＣ
ＯＢＯＬプログラムで利用され、且つ頻繁に変更がある
作成済みプログラム集をＣＯＰＹ文を利用してプログラ
ムの取り込みを行うと、汎用マシンで取り込んだＣＯＰ
Ｙ原文のバージョンと、ホスト上で取り込むべきＣＯＰ
Ｙ原文のバージョンとが一致していることを保証するた
めに多大な稼働を伴うという問題があった（第４の問題
点）。そこで、本発明の第４の課題は、最終的に動作さ
せるべきマシンにおける、ＣＯＰＹ原文の管理資源量の
削減を図るための手法を提供することにある。

【０００８】（５）生成ないし修正されたプログラムの
動作確認を行った結果、そのプログラムの障害（バグ）
を取り除く作業（デバッグ）が伴う場合がある。デバッ
グはデバッガと呼ばれるツールを用いて行う。従来、４
ＧＬ（第４世代言語）からＣＯＢＯＬプログラムを生成
する形式の４ＧＬプログラムをデバッグする場合は、４
ＧＬの動作とＣＯＢＯＬの動作に機能の差異が発生する
ため、プログラム試験を高品質で行うことが困難であっ
た。例えば最終的にＣＯＢＯＬプログラムを生成する手
段として、４ＧＬを用いて製造及び動作確認を行う場
合、そのために使用される４ＧＬコンパイラは、４ＧＬ
をコンパイルすることによって実行形式ファイルを生成
する。デバッガは、この実行形式ファイルを入力として
動作するものであり、その実行形式ファイルによる動作
確認が完了した時点で、ＣＯＢＯＬプログラムにコンパ
イルする。このため、デバッガでは、４ＧＬをコンパイ
ルして生成された実行形式ファイルの動作と、４ＧＬを
コンパイルして生成されるＣＯＢＯＬプログラムの動作
保証を行う場合、複数ホストで４ＧＬ全命令に対するＣ
ＯＢＯＬソースを生成して動作確認を行う必要があり、
多大な稼働を要するという問題があった（第５の問題
点）。そこで、本発明の第５の課題は、最終生成物であ
るプログラムソースの動作確認を容易に行える手法を提
供することにある。

【０００９】（６）また、デバッグを行う場合、従来
は、試験対象となるプログラムを修正する度にカバレー
ジ率０％からやり直しているため、デバッグ工数がプロ
グラムのサイズに応じて増加し、極めて効率が悪かった
（第６の問題点）そこで、本発明の第６の課題は、デバ
ッグ工数の効率化を図ることができる手法を提供するこ
とにある。

【００１０】

【課題を解決するための手段】第１の課題を解決するた
め、本発明は、上流工程支援手段と下流工程支援手段と
を具備する統合型ソフトウエア開発支援システムであっ
て、上流工程支援手段は、開発対象となるソフトウエア
の設計情報の作成支援を行う手段を有し、下流工程支援
手段は、前記作成された前記設計情報に基づいてプログ
ラムコードを自動生成する手段と、自動生成されたプロ
グラムコードを含むプログラムコードの編集を行う手段
と、前記自動生成されたプログラムコードを表す第１領
域とそれ以外のプログラムコードを表す第２領域とを識
別して前記編集手段による第１領域の編集を制限する編
集制限手段とを有する統合型ソフトウエア開発支援シス
テムを提供する。

【００１１】第２の課題を解決するため、本発明は、上
流工程支援手段と下流工程支援手段とを具備する統合型
ソフトウエア開発支援システムであって、上流工程支援
手段は、開発対象となるソフトウエアの設計情報の作成
支援を行う手段を有し、下流工程支援手段は、前記作成
された前記設計情報に基づいてプログラムコードを自動
生成する手段と、前記プログラムコードに追加されたコ
ーディング部分を索出する手段と、事後的に変更された
前記設計情報に基づいてプログラムコードを再度自動生
成する際に前記追加されたコーディング部分を取得して
この自動生成されたプログラムコードにマージする手段
とを有する統合型ソフトウエア開発支援システムを提供
する。

【００１２】第３の課題を解決するため、本発明は、上
流工程支援手段と下流工程支援手段とを具備する統合型
ソフトウエア開発支援システムであって、上流工程支援
手段は、開発対象となるソフトウエアの設計情報の作成
支援を行う手段と、作成された設計情報を保持するリポ
ジトリと、このリポジトリを下流工程支援手段で参照の
みが可能なインタフェースファイルに変換する手段とを
有し、下流工程支援手段は、前記インタフェースファイ
ルに基づいてプログラムコードを自動生成する手段を有
する統合型ソフトウエア開発支援システムを提供する。

【００１３】第４の課題を解決するため、本発明は、作
成済みのプログラム群を保持する作成済プログラム保持
手段と、新規プログラムを生成する際に当該プログラム
の該当領域に前記作成済みのプログラムをインライン展
開するかＣＯＰＹ原文として取り込むかを指定する指定
手段とを有し、前記新規プログラムの種別及び利用回数
に応じて前記インライン展開とＣＯＰＹ原文としての取
り込みとを選択可能に構成されていることを特徴とする
プログラム生成装置を提供する。

【００１４】第５の課題を解決するため、本発明は、第
１言語とこの第１言語によって生成される第２言語との
対応関係を保持した対応情報ファイルと第２言語プログ
ラムとを生成する第１のコンパイラと、前記対応情報フ
ァイル及び第２言語プログラムに基づいて第２言語によ
る実行形式ファイルを生成する第２のコンパイラと、前
記第２言語実行形式ファイル及び前記対応情報ファイル
を入力として内部的には第２言語プログラムとして走行
しながら、表示上は第１言語プログラムで走行している
ように見せる手段とを有し、第１言語体系下で第２言語
体系のプログラムの動作確認を行うデバッガを提供す
る。

【００１５】第６の課題を解決するため、本発明は、プ
ログラムの試験をルート毎に行う装置であって、試験実
行済みルートと試験未実行のルートとを区別するための
区別情報をコンパイルの度に保持する区別情報保持手段
と、前記保持されている区別情報のうちプログラムの変
更があった部分を試験未実行の情報に更新する区別情報
更新手段と、前記試験未実行のルートのみを抽出して表
示する手段とを有するプログラム試験装置を提供する。

【００１６】

【発明の実施の形態】以下、本発明を、４ＧＬをベース
としてＣＯＢＯＬソースを生成する統合型ソフトウエア
開発支援システムに適用した場合の実施の形態を説明す
る。図１は、この実施形態による統合型ソフトウエア開
発支援システムの全体構成図である。統合型ソフトウエ
ア開発支援システムは、汎用のコンピュータ装置がその
内部あるいは外部記憶装置にインストールされた所定の
プログラムを読み込んで実行することにより実現される
ソフトウエア開発支援装置１０と、このコンピュータ装
置に接続される表示装置２０，印刷装置３０，通信ネッ
トワーク４０，入力装置５０を備えて構成される。

【００１７】上記プログラムは、可搬性の記録媒体、例
えばフレキシブルディスク、ハードディスク、光ディス
ク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶ
Ｄ、磁気テープにコンピュータ装置が読取可能な形態で
記録されて流通し、所定のメディア読取装置を通じて上
記内部あるいは外部記憶装置にインストールされるもの
である。あるいは上記通信ネットワーク４０を通じてア
クセス可能なプログラムサーバを通じて内部あるいは外
部記憶装置にインストールされたものである。なお、上
記プログラムのみを実行することによってソフトウエア
開発支援装置１０が実現されるだけでなく、そのプログ
ラムの指示に基づいて当該コンピュータ装置上で稼働し
ているオペレーティングシステムが実際の処理の一部を
行い、その処理を通じてソフトウエア開発支援装置１０
が実現されるものであっても良い。

【００１８】ソフトウエア開発支援装置１０は、表示装
置２０等との間のデータの入出力制御を行う入出力制御
部１１、開発対象となるソフトウエアの基本設計を行う
基本設計部１２、ソフトウエアの詳細設計を行う詳細設
計部１３、設計情報に基づいてコンピュータプログラム
の自動生成を行うプログラム自動生成部１４、自動生成
されたプログラムの編集を行うとともに、自動生成され
たプログラムに追加してコーディングを行うコーディン
グ部１５、リポジトリ１７１やプログラム等を記憶する
ためのデータ記憶部１７、上流側ツールで使用するリポ
ジトリを下流側ツールで参照されるインタフェースファ
イル１７２に変換するリポジトリ変換部１８、生成され
たプログラムの試験を行うためのプログラムテスト部１
９の各機能ブロックを有している。

【００１９】従来型システムとの対比では、基本設計部
１２と詳細設計部１３とリポジトリ１７１とで上流側ツ
ール、プログラム自動生成部１４とコーディング部１５
とインタフェースファイル１７２で下流側ツールを構成
している。また、図示を省略してあるが、この種のシス
テムに必須となるエディタ（論理ネット図エディタ、４
ＧＬエディタ等）やコンパイラ（４ＧＬコンパイラ、Ｃ
ＯＢＯＬコンパイラ）を有している。なお、ここでは、
ソフトウエア開発支援装置１０をスタンドアロン型にし
た場合の例を示してあるが、分散型処理形態を採用して
も良いことはいうまでもない。

【００２０】リポジトリ１７１には、参照用のデータ辞
書や大型／小型共通部品設計情報が格納され、さらに、
基本設計部１２及び詳細設計部１３で定義された設計情
報が格納されるようになっている。リポジトリ変換部１
８で変換されたインタフェースファイル１７２は、プロ
グラム自動生成部１４やコーディング部１５で参照のみ
が行える形式のファイル（プログラム定義ファイル、デ
ータ定義ファイル等）であり、更新はできない。従っ
て、下流側で設計バグ等を発見した場合は、常にリポジ
トリ１７１を修正する必要があり、これによって設計工
程とプログラム製造工程の一貫性を保つようになってい
る。

【００２１】基本設計部１２は、ビジュアルな外部論理
ネット図を用いて業務体系を明確にするとともに入力デ
ータに対する出力データ、処理内容の概要等を決定し、
これらを基本設計工程での設計情報としてリポジトリ１
７１に保存する。また、リポジトリ（データ辞書）１７
１を参照してドキュメントとしての基本設計書やファイ
ル仕様書の自動作成をも行う。

【００２２】詳細設計部１３は、上記外部論理ネット図
に対応する詳細論理ネット図（外部論理ネット図の個々
の機能の動きを規定した図）やチャート図の作成、機能
概要等の作成を行い、これらを詳細設計工程での設計情
報、具体的には制御プログラム構造情報、プログラム生
成パターン情報としてデータ記憶部１７のリポジトリ１
７１に保存する。また、リポジトリ（大型／小型共通部
品設計情報）１７１を参照してドキュメントとしての詳
細設計書の自動作成をも行う。

【００２３】リポジトリ変換部１８は、設計情報を下流
側ツールでも共通に使用可能なインタフェースファイル
に変換する機能を有している。インタフェースファイル
には、プログラムコードにおける個々の機能を識別する
ためのアイテムの名称、アイテムが配置されている論理
ネット図・チャート図の位置情報、さらに、論理ネット
図・チャート図の構造を記録しておく。

【００２４】プログラム自動生成部１４は 詳細論理ネ
ット図からプログラム論理構造（スケルトン構造）を自
動生成するものであり、コーディング部１５は、自動生
成されたプログラムに不足している命令の追加コーディ
ングを行うものである。プログラム自動生成に際しては
上記インタフェースファイルを参照し、自動生成後は、
４ＧＬプログラムに対して追加すべきコーディング欄の
番号と、その追加コーディング欄に対応するアイテム
名、論理ネット図の位置情報等を記録した「論理ネット
図・４ＧＬ対応情報ファイル」を作成する。上流側ツー
ルで設計情報が変更され、プログラム論理構造を再度自
動生成する場合は、この論理ネット図・４ＧＬ対応情報
ファイル中に、一致するアイテム名または位置番号が存
在するかどうかを調べ、存在する場合は、対応するブロ
ックの追加コーディング欄を継承し、その欄の内容を自
動的に埋め込みながら修正後の自動コーディングを行
う。一致するアイテム名、又は位置番号が存在しなかっ
た場合は、追加コーディング欄を空欄として自動コーデ
ィングを行う。

【００２５】図２は、上述の基本設計部１２、詳細設計
部１３及びプログラム自動生成部１４における機能の相
関関係、すなわち、外部論理ネット図、詳細論理ネット
図、自動生成される制御論理のプログラム構造の相互関
係を示している。外部論理ネット図は対象となるソフト
ウエアの処理の概要を示しており、詳細論理ネット図は
外部論理ネット図における個々の機能の詳細内容を示し
ている。図示の例では、外部論理ネット図の処理Ａの概
要を詳細論理ネット図で詳細に把握できるようになって
いる。プログラム自動生成部１４は、この詳細論理ネッ
ト図の内容を解釈してプログラムを自動生成する。自動
生成されたプログラムは必要に応じて編集され、コンパ
イラで翻訳されてＣＯＢＯＬソースが生成される。

【００２６】次に、本実施形態における統合型ソフトウ
エア開発支援システムの処理動作を説明する。まず、自
動生成された４ＧＬプログラムに対する下流側ツールで
の編集（機能変更等）を制限する場合の処理について説
明する。ここでは、変更不可能文字開始記号、及び、変
更不可能文字終了記号から成る画面制御キーワードを設
定し、この画面制御キーワードに従って、自動生成され
たプログラムコードの領域とそれ以外のプログラムコー
ドの領域とを識別する。なお、前者の領域は、変更不可
能領域となり、後者の領域は、変更可能領域となる。こ
のような仕組みによって自動生成されたプログラムコー
ドが編集されることを抑止する。また、ＩＦ文、ＥＶＡ
ＬＵＡＴＥ文、ＬＯＯＰ文のように、自動生成されたプ
ログラムの制御論理を変更することが可能な命令を使用
した場合、コンパイルエラーとする。

【００２７】この場合の処理の手順例を示したのが図３
である。前提として、図３左側フローに示すように、上
流側ツールで定義された論理ネット図のリポジトリ情報
を変換したインタフェースファイル中に存在する制御プ
ログラム構造情報Ｓ１１の内容を解析し（ステップＡ１
１）、解析結果に対応するプログラム生成パターン情報
Ｓ１２より取得して４ＧＬプログラムＳ１３を自動生成
する（ステップＡ１２）。図４は制御プログラム構造情
報Ｓ１１の一例、図５はプログラム生成パターン情報Ｓ
１２の一例、図６はこれらの情報に基づいて自動生成さ
れた４ＧＬプログラムＳ１３の一例を示した図である。
生成された４ＧＬプログラムＳ１３には、それが自動生
成されたものであることを示す識別情報、具体的には、
上記画面制御キーワードが付加されるようになってい
る。図７は、この画面制御キーワードの一例を示した図
である。

【００２８】４ＧＬプログラムを表示装置２０のエディ
タ画面に表示するときには、図３中央フローに示すよう
に、テキストファイルを最終行に至るまで１行づつ読み
込み（ステップＡ２１、Ａ２２：Ｎｏ）、読み込まれた
行が画面制御キーワードか否かを判定する（ステップＡ
２３）。画面制御キーワードであった場合は、それが図
７上段の変更不可能文字開始記号か下段の変更不可能文
字終了記号かを判定し、変更不可能文字が記録されてい
る行番号の情報を変更不可能行情報Ｓ１４としてデータ
記憶部１７に記録する（ステップＡ２３：Ｙｅｓ、Ａ２
４）。また、読み込まれた行が変更不可能行か否かを判
断し、変更不可能行でない場合はそのまま（ステップＡ
２５：Ｎｏ、Ａ２６）、変更不可能行であった場合は、
表示装置２０のディスプレイＳ１５に出力する色を変更
させ（ステップＡ２５：Ｙｅｓ、Ａ２６）、その行をエ
ディタ画面に出力させる（ステップＳ２７）。これによ
り、ユーザに対して注意を喚起することができる。

【００２９】エディタは、入力装置５０のキーボードＳ
１５を通じて入力されたコーディング文字を取得する
（ステップＡ３１）。そして、キーボードＳ１５から入
力された文字に対応するカーソル位置の情報を取得し
（ステップＡ３２）、予め記録されている変更不可能行
情報Ｓ１４と現在のカーソル位置の情報とを比較する。
カーソル位置が変更不可能行であった場合は、入力され
た文字を破棄する（ステップＡ３３：Ｙｅｓ、Ａ３
４）。一方、変更不可能行でなかったときは入力文字を
ディスプレイＳ１５に表示させる（ステップＡ３３：Ｎ
ｏ、Ａ３５）。このようにして、変更可能領域と不可能
領域とを切り分ける。

【００３０】なお、上述のようにして自動生成されたプ
ログラムコードの領域とそれ以外のプログラムコードの
領域とを切り分けるだけでなく、コンパイル時にエラー
情報を生成して出力するように構成することもできる。
図８は、この場合の処理手順図であり、４ＧＬコンパイ
ラでの処理を示したものである。

【００３１】すなわち、追加記述を完了した４ＧＬプロ
グラムＳ１３からテキストファイルを最終行に達するま
で１行づつ読み込み（ステップＡ４１）、各行につい
て、それが画面制御キーワードを含む行かどうかを判定
する（ステップＡ４２：Ｎｏ、Ａ４３）。画面制御キー
ワードを含む行であった場合は、変更不可能行であるか
どうかの状態を表す変更不可能行判定フラグＳ１７を生
成してデータ記憶部１７に記憶させる（ステップＡ４
３：Ｙｅｓ、Ａ４４）。変更不可能行判定フラグＳ１７
は、例えば、「変更可能＝ＴＲＵＥ」のように表現して
おく。

【００３２】さらに、変更不可能判定フラグＳ１７から
現在の行が変更不可能行かどうかを判断する（ステップ
Ａ４５）。変更不可能行であった場合は自動生成された
行であり、制御構造を変更できる命令が記述されている
ことを意味するので、その行を追加不可命令判定の対象
外とする（ステップＡ４５：Ｙｅｓ）。変更不可能行で
なかった場合は追記記述を行った部分であるため、図９
にその内容を例示した追加不可命令テーブルＳ１８に記
述されている「追加不可命令」を使用しているかどうか
を検査する（ステップＡ４５：Ｎｏ、Ａ４６）。検査の
結果、「追加不可命令」が使用されていると判断できる
場合は、エラー情報を生成してディスプレイＳ１５に表
示させるとともに、４ＧＬコンパイラの処理を終了させ
る（ステップＡ４７：Ｙｅｓ、Ａ４８）。

【００３３】追加不可命令が使用されていない場合、ま
たはステップＡ４５において変更不可能行であった場合
は、構文解析処理を行い（ステップＡ４９）、構文が次
の行に継続しているかどうかを判定する（ステップＡ５
０）。次の行に継続しているならばステップＡ４１に戻
り、次の行に継続していないならば、ＣＯＢＯＬ（ソー
ス）プログラムＳ１９を生成する。

【００３４】このように、編集を制限した領域に対して
下流側ツールで編集がなされた場合は、コンパイル時に
エラー情報が生成されるので、設計工程とプログラム製
造工程での一貫性をより徹底させることができる。

【００３５】ここで、上流側ツールで定義した設計情報
に対して変更の必要が生じて再度プログラムの自動生成
を行う際に、既に追加コーディング等がなされている部
分を新たなプログラムに引き継ぐ場合の処理について説
明する。

【００３６】図１０はこの場合の処理の概要手順図であ
り、図１１は詳細手順図である。まず、制御プログラム
生成処理（ステップＡ１２）を再度実行する際に、変更
前のプログラムである旧４ＧＬプログラムＳ１３−１が
存在するか否かを判定する（ステップＡ１２１）。存在
する場合は、ステップＡ１１で解析したプログラム構造
情報に対応する４ＧＬプログラム生成パターン情報Ｓ１
２を取得する（ステップＡ１２２）。そして、上記プロ
グラム構造情報に対応する名称をキーとして、データ記
憶部１７内の論理ネット図・４ＧＬ対応情報ファイルＳ
２０を検索する。論理ネット図・４ＧＬ対応情報ファイ
ルＳ２０の例を図１２に示す。図１２中、(1)はステッ
プＡ１１の制御プログラム構造情報解析処理において取
得した、制御プログラム構造情報Ｓ１１中の、論理ネッ
ト図の最大位置番号である。この最大位置番号をもと
に、論理ネット図全体の変更を検知する。(2)は上記制
御プログラム構造情報Ｓ１１中の論理ネット図のアイテ
ム名称である。(3)はステップＡ１１の制御プログラム
構造情報解析処理において取得した、アイテムの論理ネ
ット図上の位置番号である。この位置番号をもとに、論
理ネット図中のアイテムの位置の変更を検知する。(4)
はステップＡ１１の制御プログラム構造情報解析処理に
おいて取得した、論理ネット図のアイテムに対応する、
新４ＧＬ（Ｓ１３−２）が保持する追加コーディング欄
のブロック番号である。「入力項目の確認」機能プログ
ラムについては、アイテム数だけ、これを繰り返す。

【００３７】この論理ネット図・４ＧＬ対応情報ファイ
ルＳ２０と図１３に示す判定条件と行動の関係表（テー
ブル）を用いて、旧４ＧＬプログラム中に、対応する追
加コーディング欄が存在するかどうかを判定する（ステ
ップＡ１２４）。存在する場合は、論理ネット図・４Ｇ
Ｌ対応情報ファイル中のブロック番号をキーとして、旧
４ＧＬプログラムＳ１３−１から、対応する追加コーデ
ィング欄を取得する（ステップＡ１２４：Yes、Ａ１２
５）。追加コーディング欄の情報が取得できなかった場
合は、新規に追加コーディングが行われるため、追加コ
ーディング欄に空白記号を埋め込んでおく（ステップＳ
１２４：No）。その後、追加コーディング欄の情報と上
述のプログラム生成パターンとをマージし（ステップＡ
１２７）、この追加コーディング欄とマージされている
プログラム生成パターンから新４ＧＬプログラムＳ１３
−２を生成する（ステップＡ１２８）とともに、図１２
に示した情報を論理ネット図・４ＧＬ対応情報ファイル
Ｓ２０宛に出力する（ステップＡ１２９）。

【００３８】なお、ステップＡ１２１の処理で旧４ＧＬ
プログラムＳ１３−１が存在しないと判定した場合は、
プログラム新規生成であると判断し、上記プログラム構
造情報に対応するプログラム生成パターン情報Ｓ１２を
取得し（ステップＡ１２１：No、Ａ１２６）、これをス
テップＡ１２７の処理に渡す。

【００３９】次に、上流側ツールで定義した設計情報の
下流側ツールでの展開形態を選択可能にする処理につい
て説明する。例えばあるベンダのホスト環境で動作する
プログラムを生成し、ある程度の動作確認を行った後、
そのホストにプログラムを転送して最終的な動作確認を
行う場合を考える。この場合を想定し、本実施形態の統
合型ソフトウエア開発支援システムでは、作成済みプロ
グラム集をＣＯＢＯＬプログラム上にインライン展開す
るか、ＣＯＰＹ原文を展開してホスト上でも同じプログ
ラムを取り込むようにするかを指定する「レベル９９指
定」の機能を搭載している。

【００４０】例えば多くのＣＯＢＯＬプログラムで利用
され、かつ頻繁に変更がある作成済みプログラムについ
ては、「レベル９９指定」を用いてＣＯＢＯＬプログラ
ムにインライン展開させるようにすることで、ホスト側
での作成済みプログラム集のバージョンのずれを防止で
きるようになる。一方、頻繁に変更が行われない作成済
みプログラム集については、「レベル９９指定」を用い
てＣＯＰＹ原文を取り込むようにすることで、ホストで
の管理資源量の削減を図ることができる。

【００４１】具体的には図１４に示す手順でＣＯＢＯＬ
プログラムを生成する。すなわち、前述のステップＡ４
９の構文解析処理の結果を受けて、「レベル９９指定」
かどうかを判定し、その構文に対する振分を行う（ステ
ップＡ５１１）。「レベル９９指定」であった場合は、
作成済みプログラム集Ｓ２０を検索し、該当するものを
取得する（ステップＡ５１２）。この作成済みプログラ
ムの例を図１５に示す。また、取り込み対象プログラム
に対するインライン展開種別情報Ｓ２１を取得し（ステ
ップＡ５１３）、作成済みプログラム集Ｓ２０をインラ
イン展開するかどうかを判定する（ステップＡ５１
４）。インライン展開種別情報Ｓ２１の例を図１６、イ
ンライン展開を行った後のＣＯＢＯＬプログラムＳ１９
の例を図１７に示す。

【００４２】図１７から明らかなように、インライン展
開を指定した場合（INLINEの文字で指定）は、図１５の
作成済みプログラムがＣＯＢＯＬプログラム中に埋め込
まれる。インライン展開を行わない場合は、ＣＯＰＹ原
文を取り込む命令として、ＣＯＰＹ文をＣＯＢＯＬプロ
グラムＳ１９に出力する（ステップＡ５１５）。ＣＯＰ
Ｙ文を出力した場合のＣＯＢＯＬプログラムＳ１９の例
を図１８に示す。図示の例では、「処理対象入力電文」
がＣＯＰＹ文として指定されている。

【００４３】次に、４ＧＬからＣＯＢＯＬソースを生成
する形式の４ＧＬプログラムの動作確認とデバッグの処
理について説明する。従来は、図１９（ａ）に示すよう
に、４ＧＬコンパイラで４ＧＬ実行形式ファイルを生成
し、４ＧＬデバッガで実行形式ファイルによる走行確認
を行った後、ＣＯＢＯＬプログラムにコンパイルしてＣ
ＯＢＯＬ実行形式ファイルを生成し、これを各ベンダの
ホスト環境で走行確認を行っていた。そのために前述の
ように４ＧＬ・ＣＯＢＯＬ間の実装内容の差異によるエ
ラーが混入することがあった。

【００４４】これに対し、本実施形態では、図１９
（ｂ）に示すように、４ＧＬコンパイラでＣＯＢＯＬプ
ログラムと４ＧＬ：ＣＯＢＯＬ対応情報ファイルとを生
成し、これらをＣＯＢＯＬコンパイラに引き渡す。ＣＯ
ＢＯＬコンパイラは、４ＧＬ：ＣＯＢＯＬ対応情報ファ
イルとＣＯＢＯＬプログラムとを入力としてＣＯＢＯＬ
実行形式ファイルを生成する。デバッガは、このＣＯＢ
ＯＬ実行形式ファイルと４ＧＬ：ＣＯＢＯＬ対応情報フ
ァイルとを入力として、内部的にはＣＯＢＯＬプログラ
ムとして走行しながら、表示上は、４ＧＬプログラムで
走行を行っているように見せる。

【００４５】この方式では、同じ汎用マシン環境及びホ
スト環境と、ＣＯＢＯＬプログラムを入力として実行形
式ファイルを生成しているため、最終生成物であるＣＯ
ＢＯＬプログラムの動作保証を容易に行えるようにな
る。また、４ＧＬとＣＯＢＯＬプログラムとの間の実装
内容の差異によるエラーが混入しないので、走行試験の
品質を向上させることができ、しかも走行するプログラ
ムの環境にとらわれないデバッグが可能になるという効
果もある。

【００４６】次に、図２０を参照してプログラムテスト
部１９の動作をより詳細に説明する。図２０（ａ）は従
来の処理、（ｂ）は本実施形態による処理である。従来
は、対象となるプログラムをコンパイルする度に、実行
形式ファイルの内容が変更されるため、テストカバレー
ジの表示をカバレージ率０％からやり直していたことは
前述のとおりである。そのため、デバッグ工数の効率化
を図ることができなかった。これに対し、本実施形態で
は、「蓄積型カバレージ機構」を搭載し、コンパイル・
リンクを行う際に、実行形式ファイル中に記憶されてい
る、試験実行済み・試験未実行の情報を継承し、プログ
ラムを修正した部分のみ試験未実行情報に更新し、実行
形式のファイルを作成する。これにより、コンパイルと
デバッグを繰り返しても、毎回、プログラムを修正した
部分だけが試験未実行として表示されるようにした。こ
のことをより詳しく説明する。

【００４７】従来、コンパイルからデバッグまでの流れ
は、図２０（ａ）に示すように、ソースコードからコン
パイルしてＣＯＢＯＬソースとＩＬ（ＣＯＢＯＬ実行形
式ファイル）とに分離し、さらに、ＩＬをリンカを通し
てＩＬ統合ファイル、つまりＣＢＴファイル（ＣＯＢＯ
Ｌ実行形式結合ファイル）に変換していた。そして、デ
バッガは、このＣＢＴファイルを入力として動作を行
い、命令ごとの試験実行済み・未実行の情報（以下、
「カバレジ情報」）をＣＢＴファイルに保管する形式で
あったため、プログラムに修正が加えられると、新しい
ＩＬファイルが作成され、また、新しいＣＢＴファイル
が作成されるため、コンパイル・リンク毎にカバレジ情
報がクリアされていた。

【００４８】これに対し、本実施形態では、ソースコー
ドをコンパイルするが、その際、ＣＯＢＯＬソースとＩ
Ｌのほか、リソース情報（ソースコード：ＣＯＢＯＬ対
応情報）を生成する。従来方式とは異なり、リンカを呼
び出す前に、旧ＣＯＢＯＬソースとＣＯＢＯＬソースの
行とを比較して差分情報を取得する。リンカは、差分情
報とＩＬとを入力とし、ＣＢＴファイルのカバレジ情報
に差分情報中の変更が無かった行に対して、試験済みの
フラグを入力する。そして、デバッガにＣＢＴファイル
を入力して試験を行う。試験開始時には、差分情報がす
べて反映されており、再コンパイルを行った後でも試験
済みの部分については試験済みとして表示を行うことが
可能となる。

【００４９】

【発明の効果】以上の説明から明らかなように、本発明
の統合型ソフトウエア開発支援システムでは、生成され
たプログラムのうち、ユーザが下流工程で変更可能な部
分と変更不可能な部分とを切り分けることができ、自動
生成される部分は、変更を不可能にし、また、自動生成
されたプログラムに対して、設計で定義を行った制御が
変更されるような命令を記述した場合は、コンパイル時
にすべてエラーになるようにしたので、上流・下流ツー
ル間の制御論理の不一致の発生を抑制できるようにな
る。

【００５０】また、プログラムの自動生成時に追加コー
ディング欄の番号、追加コーディング欄に対応するアイ
テム名、論理ネット図の位置情報を記録しておき、設計
情報が変更され、プログラムを再度自動生成する必要が
ある場合に、論理ネット図、４ＧＬ対応情報ファイルを
読み込みながら、対応するアイテムが保持していた追加
コーディング欄の内容を埋め込みつつ、プログラムを自
動生成するようにしたので、設計情報の変更時にも、そ
れまでの追加コーディング部分を継承でき、設計情報変
更時の生産性、品質を高めることができるようになる。

【００５１】また、下流側ではリポジトリをもたずに上
流側からリポジトリ変換を行ったインタフェースファイ
ルを参照情報とし、しかもインタフェースファイルは、
参照のみが行える形式のファイルで、更新ができないよ
うにしたので、設計バグが発見された場合には常に上流
側のリポジトリを修正する必要が生じ、設計工程とプロ
グラム製造工程での一貫性が保てるようになる。

【００５２】また、レベル指定手段を設け、対象となる
プログラム上に作成済みプログラムをインライン展開す
るかＣＯＰＹ原文を展開するかを本システム内で選択で
きるようにしたので、そのプログラムを走行させるホス
ト側で作成済みプログラムのバージョンを管理する必要
がなくなり、管理資源量の削減が図れるようになる。

【００５３】また、デバッグの際に、内部的には第２言
語体系での動作を行いながらあたかも第１言語体系で動
作を行っているように見せるようにしたので、最終生成
物である第２言語体系のプログラムの動作保証を第１言
語で容易且つ高品質に行えるようになる。

【図面の簡単な説明】

【図１】本発明の統合型ソフトウエア開発支援システム
の全体構成図。

【図２】基本設計部、詳細設計部、プログラム自動生成
部の相互関係を示した説明図。

【図３】変更不可能行とそうでない行との切り分け処理
の手順説明図。

【図４】インタフェースファイル中の制御プログラム構
造情報の一例を示した図。

【図５】プログラム生成パターン情報の一例を示した
図。

【図６】インタフェースファイル中の制御プログラム構
造情報より自動生成された４ＧＬプログラムの一例を示
した図。

【図７】画面制御キーワードの一例を示した図であり、
上段は変更不可能文字開始記号、下段は変更不可能文字
終了記号である。

【図８】自動生成されたプログラムに対する追加コーデ
ィング部分に、制御論理を変更できる命令が記述されて
いる場合に、エラー情報を出力する場合の処理手順図。

【図９】変更不可能行でなかった場合に参照される追加
不可命令テーブルの内容例を示した図。

【図１０】上流側ツールで定義した設計情報に対して変
更の必要が生じて再度プログラムの自動生成を行う際
に、既に追加コーディング等がなされている部分を新た
なプログラムに引き継ぐ場合の処理の概要手順説明図。

【図１１】図１０の処理の詳細手順説明図。

【図１２】論理ネット図・４ＧＬ対応情報ファイルＳ２
０の例。

【図１３】追加コーディング欄が存在するかどうかを判
定するための判定条件の一例を示した図。

【図１４】上流側ツールで定義した設計情報の下流側ツ
ールでの展開形態を選択できるようにするための処理手
順説明図。

【図１５】インライン展開の対象となる作成済みプログ
ラムの例を示した図。

【図１６】取り込み対象プログラムに対するインライン
展開種別情報の一例を示した図。

【図１７】インライン展開を行った後のＣＯＢＯＬプロ
グラムの例を示した図。

【図１８】ＣＯＰＹ文による展開を行った後のＣＯＢＯ
Ｌプログラムの例を示した図。

【図１９】（ａ）は従来のデバッガの処理概要図、
（ｂ）は本実施形態によるデバッガの処理概要図。

【図２０】（ａ）は従来のコンパイル・リンクの処理手
順図、（ｂ）は本実施形態によるコンパイル・リンクの
処理手順図。

【符号の説明】

１０ ソフトウエア開発支援装置 ２０ 表示装置 ３０ 印刷装置 ４０ 通信ネットワーク ５０ 入力装置 １１ 入出力制御部 １２ 基本設計部 １３ 詳細設計部 １４ プログラム自動生成部 １５ コーディング部 １７ データ記憶部 １８ リポジトリ変換部 １９ プログラムテスト部 １７１ 上流工程におけるリポジトリ １７２ インタフェースファイル

フロントページの続き (72)発明者 土屋 久志 東京都江東区豊洲三丁目３番３号 株式会 社エヌ・ティ・ティ・データ内 (72)発明者 藤井 浩司 東京都江東区豊洲三丁目３番３号 株式会 社エヌ・ティ・ティ・データ内 (72)発明者 櫻井 糧 東京都江東区豊洲三丁目３番３号 株式会 社エヌ・ティ・ティ・データ内 (72)発明者 岡部 直樹 東京都江東区豊洲三丁目３番３号 株式会 社エヌ・ティ・ティ・データ内 (72)発明者 矢島 英明 東京都江東区豊洲三丁目３番３号 株式会 社エヌ・ティ・ティ・データ内 (72)発明者 福田 修之 東京都江東区豊洲三丁目３番３号 株式会 社エヌ・ティ・ティ・データ内 (72)発明者 木村 嘉和 東京都江東区豊洲三丁目３番３号 株式会 社エヌ・ティ・ティ・データ内 (72)発明者 中野 正三 東京都町田市相原町307−44 (72)発明者 水沼 充 神奈川県横浜市霧が丘４−２ 霧が丘グリ ーンタウン３−403 (72)発明者 高見沢 正己 神奈川県横須賀市田浦町１−１−５ ファ ミール湘南田浦1007 Ｆターム(参考） 5B042 GA01 HH11 NN50 5B076 DD04 EC07

Claims (15)

【特許請求の範囲】
1. 【請求項１】 上流工程支援手段と下流工程支援手段と
   を具備する統合型ソフトウエア開発支援システムであっ
   て、 上流工程支援手段は、開発対象となるソフトウエアの設
   計情報の作成支援を行う手段を有し、 下流工程支援手段は、前記作成された前記設計情報に基
   づいてプログラムコードを自動生成する手段と、自動生
   成されたプログラムコードを含むプログラムコードの編
   集を行う手段と、前記自動生成されたプログラムコード
   を表す第１領域とそれ以外のプログラムコードを表す第
   ２領域とを識別して前記編集手段による第１領域の編集
   を制限する編集制限手段とを有することを特徴とする統
   合型ソフトウエア開発支援システム。
2. 【請求項２】 前記第１領域の識別情報を前記自動生成
   されたプログラムコードに付加する手段をさらに有し、
   前記編集制限手段は、前記付加された識別情報をもとに
   前記第１領域を識別することを特徴とする、 請求項１記載の統合型ソフトウエア開発支援システム。
3. 【請求項３】 前記編集制限手段は、前記第１領域と第
   ２領域とを異なる形態で表示するように構成されている
   ことを特徴とする、 請求項１記載の統合型ソフトウエア開発支援システム。
4. 【請求項４】 前記自動生成されたプログラムコードは
   プログラム制御論理を含むものであり、編集可能な前記
   第２領域に前記プログラム制御論理を変更する命令が記
   述されていた場合はコンパイル時にエラー情報を生成す
   るエラー情報生成手段を有することを特徴とする、 請求項１または２記載の統合型ソフトウエア開発支援シ
   ステム。
5. 【請求項５】 上流工程支援手段と下流工程支援手段と
   を具備する統合型ソフトウエア開発支援システムであっ
   て、 上流工程支援手段は、開発対象となるソフトウエアの設
   計情報の作成支援を行う手段を有し、 下流工程支援手段は、前記作成された前記設計情報に基
   づいてプログラムコードを自動生成する手段と、前記プ
   ログラムコードに追加されたコーディング部分を索出す
   る手段と、 事後的に変更された前記設計情報に基づいてプログラム
   コードを再度自動生成する際に前記追加されたコーディ
   ング部分を取得してこの自動生成されたプログラムコー
   ドにマージする手段とを有することを特徴とする、 統合型ソフトウエア開発支援システム。
6. 【請求項６】 前記上流工程支援手段または下流工程支
   援手段は、前記設計情報を上流工程及び下流工程で共通
   に使用される共通フォーマットファイルに変換する手段
   を備え、当該共通フォーマットファイルには、プログラ
   ムコードの機能を識別するためのアイテムの名称、アイ
   テムが配置されている論理ネット図の位置情報、論理ネ
   ット図の構造が前記追加されたコーディング部分に対応
   付けて記録されており、 前記下流工程支援手段は、前記プログラムコードの再生
   成時に前記共通フォーマットファイルから該当するアイ
   テムに対応するコーディング部分の内容を取得するよう
   に構成されていることを特徴とする、 請求項５記載の統合型ソフトウエア開発支援システム。
7. 【請求項７】 上流工程支援手段と下流工程支援手段と
   を具備する統合型ソフトウエア開発支援システムであっ
   て、 上流工程支援手段は、開発対象となるソフトウエアの設
   計情報の作成支援を行う手段と、作成された設計情報を
   保持するリポジトリと、このリポジトリを下流工程支援
   手段で参照のみが可能なインタフェースファイルに変換
   する手段とを有し、 下流工程支援手段は、前記インタフェースファイルに基
   づいてプログラムコードを自動生成する手段を有するこ
   とを特徴とする、 統合型ソフトウエア開発支援システム。
8. 【請求項８】 作成済みのプログラム群を保持する作成
   済プログラム保持手段と、 新規プログラムを生成する際に当該プログラムの該当領
   域に前記作成済みのプログラムをインライン展開するか
   ＣＯＰＹ原文として取り込むかを指定する指定手段とを
   有し、 前記新規プログラムの種別及び利用回数に応じて前記イ
   ンライン展開とＣＯＰＹ原文の取り込みとを選択可能に
   構成されていることを特徴とする、 プログラム生成装置。
9. 【請求項９】 第１言語とこの第１言語によって生成さ
   れる第２言語との対応関係を保持した対応情報ファイル
   と第２言語プログラムとを生成する第１のコンパイラ
   と、 前記対応情報ファイル及び第２言語プログラムに基づい
   て第２言語による実行形式ファイルを生成する第２のコ
   ンパイラと、 前記第２言語実行形式ファイル及び前記対応情報ファイ
   ルを入力として内部的には第２言語プログラムとして走
   行しながら、表示上は第１言語プログラムで走行してい
   るように見せる手段とを有し、 第１言語体系下で第２言語体系のプログラムの動作確認
   を行うことを特徴とする、デバッガ。
10. 【請求項１０】 前記第１言語が４ＧＬ、第２言語がＣ
    ＯＢＯＬであることを特徴とする、請求項９記載のデバ
    ッガ。
11. 【請求項１１】 プログラムの試験をルート毎に行う装
    置であって、試験実行済みルートと試験未実行のルート
    とを区別するための区別情報をコンパイルの度に保持す
    る区別情報保持手段と、 前記保持されている区別情報のうちプログラムの変更が
    あった部分を試験未実行の情報に更新する区別情報更新
    手段と、 前記試験未実行のルートのみを抽出して表示する手段と
    を有することを特徴とする、プログラム試験装置。
12. 【請求項１２】 請求項１乃至請求項７のいずれかの項
    記載の統合型ソフトウエア開発支援システムをコンピュ
    ータ装置上で実現するためのプログラムが記録されたコ
    ンピュータ読取可能な記録媒体。
13. 【請求項１３】 請求項８記載のプログラム生成装置を
    コンピュータ装置上で実現するためのプログラムが記録
    されたコンピュータ読取可能な記録媒体。
14. 【請求項１４】 請求項９または１０記載のデバッガを
    コンピュータ装置上で実現するためのプログラムが記録
    されたコンピュータ読取可能な記録媒体。
15. 【請求項１５】 請求項１１記載のプログラム試験装置
    をコンピュータ装置上で実現するためのプログラムが記
    録されたコンピュータ読取可能な記録媒体。