JPS61282934A - ソフトウェア仕様管理方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 〔発明の利用分野〕 本発明はソフトウェア仕様管理方式に係り、特に、プロ
グラムロジック設計仕様およびソースプログラムを一元
管理する場合に好適なソフトウェア仕様管理方式に関す
る・ 〔発明の背景〕 従来、ソースプログラムを管理する方式としては、構造
エディタによるソースプログラム１ｆ理方式がある（原
田賢−：「構造エディタ」、情報処理学会誌、Ｖｏｌ、
２５，１９８４．ｍ８．ＰＰ７６７−７７６参照）０ 構造エディタに３いては、ソースプログラムは、コンパ
イラが内部中間語として扱っているような。

プログラミング言語文法規則に基づいて構文解析した結
果の構文木として管理される０ ここで構文木とは、ソースプログラムをプログラミング
言語文法規則に基づいて木構造で表現したものである。

以下、構造エディタにおいて、ソースプログラムがどの
ように構文木で管理されるかにつき具体的に説明する。

プログラミング言語文法規則として１例えば以下に示す
ような規則１ないし規則４を例にとる０規則１　く　文
　＞：：−＜選択文〉 １　く反復文〉 １　く代人文〉 規則２　く選択文〉：ニー　ＩＦ＜条件式〉ＴＨＥＮ＜
文〉 ＢＬ８Ｆｔ＜文〉 ＥＮＤ　　： 規則３　く条件式）：：−（項＞　、　Ｇ’Ｉ’　、　
＜項〉１　く項＞　、　ＧＥ　、　＜項〉 １　く項＞、ＥＱ、＜項〉 １　く項＞　、　Ｎ１３　、　＜項〉 １　く項）、ＬＢ、＜項〉 １　く項＞、ＬＴ、＜項〉 規則４　く代人文＞：：−＜変数〉−＜算術式〉：規則
５　く算術式＞：：−＜項〉 １　く項〉十＜項〉 ｉ　く項〉−＜項〉 １　く項〉／＜項〉 １　く項〉＊＜項〉 規則６　く　項　＞：：−＜変数〉１く定数〉規則７　
く変数ン：：−＜英文字列〉 規則８　（定数ン；ニー＜数字列〉 規則９　く反復文ン：：−ＷＨＩＬＥ　Ｉ　ＵＮＴＩし
く条件式＞　Ｒ１！ｆＰＦｔＡＴ く文〉 ＢＮＤ　　： 前述の各規則１〜９において、符号「＜」と「〉」で囲
まれたものを構文要素と呼ぶ。また、ｒ：：−Ｊは、ｒ
：：−Ｊの左辺の構文要素がｒ：：−Ｊの右辺の要素か
ら成ることを示し、「１」は「または」の意味を示すも
のである。これらの符号は、文法規則を定義するための
一般的記法である０規則１は、ｒ文は、選択文または反
復文または代入文から成る」ことを意味する。

規則２は、「選択文は、ＩＰと条件式と、　ＴＨＥＮと
文と、ｇＬ８Ｂと文と、ＥＮＤ　　と：とからなる」こ
とを意味する〇 規則３は、「条件式は１項と、ＧＴ、　　と項、または
項と、　ＧＥ　、と項、または項と、　ＥＱ　、と項。

または項と、ＮＢ、と項、または項と、　ＩＪ　、と項
、または項と、ＬＴ、　　と項とから成る」ことを意味
する。

規則４は、「代入文は、変数式と、−と、算術式と、；
とから成る」ことを意味する。

規則５は、「算術式は１項、または項と十と項、または
項と−と項、または項と／と項、または項と＊と項から
成る」ことを意味する。

規則６は、「項は、変数または定数から成る」ことを意
味する。

規則７は、「変数は、英文字列から成る」ことを意味す
る〇 規則８は、「定数は、数字列から成る」ことを意味して
いる。

規則９は、「反復文はＷＨＩＬＢまたはＵＮＴＩＬと、
条件式と、Ｒ１！１ＰＢＡＴと、ＥＮＤと；とからなる
」ことを意味する。

このプログラミング言語文法規則によって定義されるソ
ースプログラムは、規則１のく文〉から始まって、構文
要素をつぎつぎに、構文要素を１つも含まなくなるまで
、ｒ：：−Ｊの右辺にあるものと置き換えていくことに
よって、得られるものである。

構造エディタにおいては、例えば、第３図に示したソー
スプログラムは、前述のプログラミング言語文法規則に
基づき、第４図に示すような構文木として電子計算機の
メモリ上に管理（記憶）される。

第４図の構文木は、第３図のソースプログラムを、前述
の規則ｌのく文〉から始まって、順次構文要素をｒ：：
−Ｊの右辺にあるものに置きかえて行く過程を木構造に
反映したものである。

すなわち、前述の各規則に示されたｒ：：−Ｊの左辺の
構文要素を、ｒ：：−Ｊの右辺の構文要素で置き換える
場合は、左辺構文要素を親とし、右辺構文要素を子供と
して、その間を有向グラフ「→」で結びつけて木を構成
する〇 例えば、第３図のソースプログラムにおいて、く文〉は
く選択文〉であるので、まず、規則１を適用して第４図
の１■”　部分の木が構成される〇く選択文〉は規則２
に準拠して、第４図の＠Ｉ”部分で示した構文木に構成
される。

以下、規則３〜８を順次適用すると、全体として第４図
に示す木が構成されることは、容易に理解されるであろ
う。

以上構造エディタにおけるソースプログラムの管理方式
について述べたが、このような管理方式は、プログラム
のロジック設計仕様の管理にも適用することができる、
ここでロジック設計仕様とは、プログラムのロジックを
、より人間に近い自然語レベルで記述したものである。

もつとも、自然語とは言っても、設計レベルでの厳密さ
を保持するため、処理の渡れ（処理の選択、処理の繰返
し）を示す制御構造を持った言語文法規則に基づいて記
述されることは当然である。

ロジック設計に使用される言語（以下ロジック設計言語
と呼ぶ］の規則の例をつぎに示す。

規則１　〈文〉二：＝〈選択文〉 １く反復文〉 １〈擬似文〉 規則２　〈選択文＞：：＝ＩＦ＜条件式〉ＴＨＥＮ　＜
文〉 ＥＬＳＥ＜文〉 ＥＮＤ； 規則３　く条件式＞：：＝＜Ｓ本語文字列〉規則４　く
擬似文＞：：＝＜日本語文字列〉また、前記規則１ない
し４に基づいて記述されたロジック設計仕様の一例を第
５図に示す。なお明らかなように、このロジック設計仕
様は、第３図に示したソースプログラムに対応するもの
である。

構造エディタにおいては、前述のソースプログラムと同
じように、第５図に示したロジック設計仕様は、前述の
ロジック設計言語規則に基づき、第６図に示すような構
文木として電子計算機のメモリ上に管理される。

なお、実際上は、電子計算機のメモリ上では、第６図の
構文木は、第１表に示したようなテーブルとして記憶、
管理される。また、第４図のソースプログラムについて
も同様である。

Ｅ、Ｐｌ、Ｐ２・・・・・・・・・Ｐｊ：構文要素番号
第１表において、Ｅ欄は親の構文要素番号、またｐｉ　
、　Ｐ２・・・・・・・・・Ｐｊ　　の各欄はそれぞれ
第６図に示した各子供構文要素の番号をあられしている
〇すなわち、親の構文要素く文〉の番号は「１」であり
、これに関連づけられた子供構文要素は。

番号「２」のく選択文〉のみである。また、親としての
構文要素「２」に関連づけられた子供構文要素は番号ｒ
３Ｊｒ４Ｊおよび「５」であられされている。以下１番
号「６」〜「１０」の構文要素についても同様である〇 前記従来技術によれば、構造エディターこより、プログ
ラムのロジック設計仕様およびソースプログラムを、各
々構文木として、電子計算機のメモリ上に管理すること
ができる。

しかしながら、従来技術においては、ロジック設計仕様
とソースプログラムを互いに関連づけて管理する配慮が
なされていないので、ロジック設計仕様とソースプログ
ラム間の不整合を生じ易いという問題点が発生する。

すなわち、プログラムを作成する場合、通常は、まずプ
ログラムのロジック設計を行なってロジック設計仕様を
作成し、次に、このロジック設計仕様に基づき、プログ
ラミング言語を用いてソースプログラムを作成する〇 そして最後に、このソースプログラムをコンパイラによ
り機械語に翻訳し、計算機で実行させて正常に動作する
かどうかを確認する〇 その結果、もし正常に動作しない場合は、その原因を究
明し、ロジック設計仕様およびソースプログラムを修正
し、再度電子計算機で実行させる。

そして、必要に応じてはさらに、前記の修正と実行をく
り返すことになる。

この場合、従来技術では、ロジック設計仕様とソースプ
ログラムとが、相互に関連のない別々な構文木として電
子計算機メモリ上に管理されているため、 （１）　　ロジック設計仕様は修正したが、ソースプロ
グラムの修正を忘れるとか、また逆に（２）ソースプロ
グラムは修正したが、ロジック設計仕様の修正を忘れる
。

というケースがしばしば発生する。

この結果、ロジック設計仕様とソースプログラム間の仕
様不一致（不整合）が発生し、プログラムの品質が大幅
Ｉこ低下するという問題点があった〇不整合発生の具体
例を、第７図および第８図を参照して以下に説明する。

第７図（ａ）に示したように、ロジック設計仕様のうち
、「温度が１００℃以下」が「温度が９０℃以下」に変
更されると、これに伴って、同図（ｂ）のロジック設計
仕様の構文木の「温度が１００”Ｃμ下」も、図示のよ
うに「温度が９０℃以下」に変更される。

前述の変更に対応して、本来ならば、第８図（ａ）に示
したソースプログラムのｒ　ＴＢＭＰ　、ＬＥ　。

１００」も、ｒＴＢＭＰ、ＬＢ、９０」と変更しなけれ
ばならない。

にもかかわらず、この変更を忘れると、同図（ｂ）のよ
うに、ソースプログラムのｒｌｏｏＪが「９０」に変更
されないままとなる。

これにより、第７図（ｂ）のロジック設計仕様の構文木
と、第８図（ｂ）のソースプログラムの構文木との間で
不整合が発生するので、プログラムの品質低下の原因と
なる。

〔発明の目的〕

本発明の目的は、ロジック設計仕様とソースプログラム
間の不整合発生を防止するために、ロジック設計仕様と
ソースプログラムを一つの構文木で一元管理するソフト
ウェア仕様管理方法を提供することにある。

〔発明の概要〕

本発明は、「第６図に示したロジック設計仕様の構文木
と、第４図に示したソースプログラムの構文木とを比較
して見れば分るように、同者は、（１）第９図（荀に示
した部分では一致しており、（２）異なるのは、ロジッ
ク設計仕様構文木においてはレベルが浅い（第９図のｂ
参照）のに対し。

ソースプログラム構文木においては、レベルが深い−す
なわち、ざらに＃ａに構文木が構成される（第９図のＣ
゛参照点のみである◇」という２点に着目してなされた
ものである。

そして、本発明は、従来の木構造に加えて、ロジック設
計仕様構文木とソースプログラム構文木の相異なる部分
を記憶する拡張構文木構造によりロジック設計仕様とソ
ースプログラムを１本の構文木で一元的に管理するよう
にした点に特徴がある０ 〔発明の実施岡〕 以下に、図面を参照して本発明の詳細な説明する◇ まずロジック設計仕様とソースプログラムを一元管理す
るための拡張構文木の構造を第１図に示す。第１図にお
いて。

（１）実線矢印で示した有向グラフ→は、親の構文要素
から子供の構文要素への詳細化が、ロジック設計仕様と
ソースプログラムとで一致する場合を示し、 （２）２重線矢印で示した有向グラフ→は、親の構文要
素から子供の構文要素への詳細化が、ロジック設計仕様
の場合であるくとを示し、また、（３）点線矢印で示し
た有向グラツー−−−りは構文要素の詳細化がソースプ
ログラムの場合であることをそれぞれ示している〇 本発明による拡張構文木によれば、ロジック設計仕様と
ソースプログラムは、１本の拡張構文木として管理する
ことが出来る。

従来技術の構文木である第６図のロジック設計仕様の構
文木、およびｓｇ４図のソースプログラムの構文木を１
本発明の拡張構文木で一元管理した場合の例を第２図に
示す。

なお、この図において、実線矢印、２重線矢印および点
線矢印は、第１図の場合と同じ意味合いをもっている。

第２図においては、■の部分木はロジック設計仕様とソ
ースプログラムによらず同じである。

また、く条件式〉の構文ＩＩＪ素は、ロジック設計仕様
では■の部分木のように詳細化され、一方。

ソースプログラムでは■の部分木のように詳細化される
。

本発明番こよる拡張構文木は、具体的には、電子計算機
のメモリ上では、第２表に示すようなテーブルとして管
理される。

第２表において、Ｅ欄は拡張構文木に現われる全ての構
文要素の番号であり、この図では、前記番号は第１図の
それに対応させられている。

第２表 Ｂ：構文要素番号 第２衣のＧｊ欄は、鈑当構文要素と、Ｐｊ欄に示された
５番目の子供構文要素との関係を示す有向グラフの種別
を示したものである０すなわち、第１図において実線矢
印、２重線矢印および点線矢印で示された有向グラフを
、それぞれ「０」「１」「２」で表わしたものである〇 これを第２表に即してさらに具体的に説明すれば１例え
ば、第１図の構文要素３と構文要素６および構文要素８
の関係は、第２表の構文要素３の行（横方向）の形で記
憶される〇 すなわち、Ｂ欄の構文１！累３は、ＰＩ欄の番号６で示
される構文要素（すなわち、構文要素６）で構成され、
しかも、構文要素３から構文要素６への詳細化は、Ｇｌ
橢で示される種別１（すなわち、・２重線矢印）により
、ロジック設計仕様の詳細化であることを示している。

また同時に前記構文要ｌＸ３は、Ｐ２欄の番号８で示さ
れる構文要素（すなわち、構文要素８）で構成され、し
かも、構文要素３から構文要素８への詳細化は、Ｇ２欄
で示される種別２（すなわち、点線矢印）により、ソー
スプログラムとしての詳細化であることを示している。

さらに、２つのく文〉は、それぞれ第２図に示したよう
に、ロジック設計仕様とソースプログラムとで、別々に
異って詳細化される。

次に１以上に述べた本発明の拡張構文木５こより管理さ
れた。ロジック設計仕様およびソースプログラムを変更
する場合の、構造エディタの処理アルゴリズムを第１０
図に示す。

第１０図の処理アルゴリズムを、第１１図のロジック仕
様変更例の場合（修正対象がロジック設計仕様の場合）
について説明する〇 まず、ＢＩＧでは、修正対象がロジック設計仕様である
か、またはソースプログラムであるかの判定をする０ ８２Ｇにより、第１．２図１こおいて、実線矢印および
２重線矢印で表わされた部分木が、第２表のテーブルを
参照して抽出され、Ｂ２ＯによりＣＲＴに表示される〇 前記のＢ１０によって抽出された部分木は、ロジック設
計仕様であり、ＣＲＴ画面やプリンタ上では、第１１図
に示したように。

ＩＰ湿温度１００′Ｃ以下 ＴＨＥＮ　　スイッチをＯＮにする ＢＬＵＮ　　スイッチをＯＦＦにする ＥＮＤ　　： と表示される〇 プログラマがＣＲＴ画面上で、「温度が１００ＣＩＪ下
」を［温度が９０　′ｃＫ下」に変更した場合、第１θ
図のＢ２Ｏ，５０により、「温度が１００℃以下」とい
う部分木（第１１図の０部分）に対応するソースプログ
ラムの部分木（第１１図の０部分）を取り出し、ＣＲＴ
画面に表示する。すなわち、 ＴＥＭＰ　　、ＬＢ　、　　１　ｏ　　。

を表示する。

次に、Ｂ２Ｏにより、プログラマにｒ　ＴＥＭＰ　。

Ｌｌｉｆ　、　１００Ｊの変更要否を間合せる。プログ
ラマは、この間合せに応じ、必要に応じて、例えばソー
スプログラムの１部ｒｌｏＯＪを「９０」に変更する。

この結果に応じて、Ｂ２Ｏで、変更されたソースプログ
ラムの部分を取り込む。

Ｂ１０で取り込まれたロジック設計仕様「温度が９０ｔ
ｌ：１ｇ下」％およびＢｏｏで取り込まれたソースプロ
グラムの変更内容「９０」に基づき、Ｂ２Ｏで、拡張構
文木の部分木を変更する。すなわち、第１１図中に示し
た■の変更および■の変更が実施される。

以上に述べたように１本発明の方法によれば、プログラ
マがロジック設計仕様を変更する場合、対応するソース
プログラムの変更の要否が電子計算機側から間合せられ
るので、必要なソースプログラムの変更が忘れずに実施
される０このため、ロジック設計仕様とソースプログラ
ムとが、拡張構文木上で不一致となることがなく。

整合性を保ちながら管理される。

また、プログラマがソースプログラムを変更する場合は
、第１０図のＢ９０〜Ｂ１５旧こより、前述と同様のＣ
ＲＴ　への表示および処理が行なわれ、さらにロジック
設計仕様の変更要否の問合せが行なわれる。

それ故に、ソースプログラム変更に伴なって必要となる
ロジック設計仕様の変更を、プログラマが忘れることは
無くなり１両者の整合性の保持が保証される。

μ上、本発明の詳細な説明して来たが、本発明のシステ
ムの全体構成は第１２図に示す通りである。同図におい
て、１００は電子計算機、２００は前記電子計算機１０
０内のメモリである。

また３００は、前記メモＩＪ　２００上で管理されるロ
ジック設計仕様およびソースプログラムの拡張構文木で
あり、具体的には、例えば第２表に示した拡張構文木の
テーブルである。

４００は、前記メモリ２００に記憶されたロジック設計
仕様およびソースプログラムを町視表示し、かつプログ
ラマによるロジック設計仕様およびソースプログラムの
変更指示を受付ける会話型端末である。

５００は、メモ！Ｊ２００上で管理されるロジック設計
仕様およびソースプログラムの拡張構文木３００を会話
型端末４０Ｇに表示するとともに、会話型端末４００か
らプログラマによって入力されたロジック設計仕様およ
びソースプログラムの変更指示を解析し、メモＩＪ　２
００上の拡張構文木３００を変更するための、構造エデ
ィタであり、具体的には、例えば第１θ図に示した処理
アルゴリズムを持つ構造エディタである。

〔発明の効果〕

本発明によれば、 （１）　　ロジック設計仕様が変更されれば、それに対
応したソースプログラムも併せて変更され、また （２）ソースプログラムが変更されれば、それに対応し
たロジック設計仕様も併せて変更される。

これＩこより、ロジック設計仕様とソースプログラムを
両者の整合性を保ちながら管理できるので。

プログラム品質の低下を未然に防止することができる０

【図面の簡単な説明】

第１図は本発明による拡張構文木の概略構成を説明する
ための図である。 第２図は本発明の拡張構文木によって、ロジック設計仕
様とソースプログラムの一元管理を実現するテーブルの
構成列を示す図である。 第３図はプログラミング言語規則に基づいて作成された
ソースプログラムの例を示す図である。 第４図は第３図のソースプログラムを構造エディタの構
文木で示した図である〇 第５図はロジック設計言語規則に基づいて作成されたロ
ジック設計仕様の例を示す図である。 第６図は第５図のロジック設計仕様を構造エディタの構
文木で示した図である。 第７図および第８図はロジック設計仕様とソースプログ
ラムとの不整合を説明するための、ソースプログラム、
ロジック設計仕様および構文木を示した図である。 第９図はロジック設計仕様構文木とソースプログラム構
文木の一致点および相違点を説明した図である。 第１０図は拡張構文木に基づいてロジック設計仕様およ
びソースプログラムを変更する場合の構造エディタの処
理アルゴリズムを示すフローチャートである。 第１１図はロジック設計仕様変更の的を示した図である
。 第１２図は本発明の１実施的の全体構成を示すブロック
図である。 代理人　弁理士　　平　　木　　道　　入坑　　１　　
図　　　　　く構文要素１〉會 第３図 第４図 ＴＥＭＰ　　　　１００　　　　　　　＜定数〉　　　
　　く定数〉第　　　５　　　図 第　　６　　図 第７図 （ａ） （ｂ） 〈文〉 ↓ シーと唄ｘｊ工 第８図 （ａ） （ｂ） 〈文〉 ■ ９０（（変更もれ　　　　　　１０ 第９図 （ａ） く文〉 （ｂ）　　　　　　　　　　　　　　　（ｃ）番 く定数〉 番 第１０図 ！　１２図

Claims (3)

【特許請求の範囲】
1. （１）プログラムのロジック設計仕様およびソースプロ
   グラムを、構造エディタが扱う構文木の形式で電子計算
   機メモリ上に記憶・管理するソフトウェア仕様管理方式
   において、 （ａ）ロジック設計仕様およびソースプログラムに共通
   の構文に対応する第１の部分木と、ロジック設計仕様に
   特有の構文に対応する第２の部分木と、ソースプログラ
   ムに特有の構文に対応する第３の部分木とを、１つの拡
   張構文木として記憶・管理し、 （ｂ）前記拡張構文木上に記憶されたロジック設計仕様
   およびソースプログラムの一方の構文要素を、構造エデ
   ィタによつて変更する場合には、変更対象の構文要素に
   対応する、前記ロジック設計仕様およびソースプログラ
   ムの他方の構文要素を、可視的に端末に表示し、（ｃ）
   これによつて、プログラマに、前記ロジック設計仕様お
   よびソースプログラムの他方の変更を促すことを特徴と
   するソフトウェアー仕様管理方式。
2. （２）構文要素を可視的に表示する前記端末は、ＣＲＴ
   およびプリンタの少なくとも１つであることを特徴とす
   る前記特許請求の範囲第１項記載のソフトウェア仕様管
   理方式。
3. （３）構文要素を可視的に表示する前記端末は、会話型
   端末であることを特徴とする前記特許請求の範囲第１項
   または第２項記載のソフトウェア仕様管理方式。