JPH0656577B2

JPH0656577B2 - ソフトウェア仕様管理方法

Info

Publication number: JPH0656577B2
Application number: JP12393185A
Authority: JP
Inventors: 清三森; 利弘林
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1985-06-07
Filing date: 1985-06-07
Publication date: 1994-07-27
Anticipated expiration: 2009-07-27
Also published as: JPS61282934A

Description

【発明の詳細な説明】〔発明の利用分野〕本発明はソフトウエア仕様管理方法に係り、特に、プロ
グラムロジック設計仕様およびソースプログラムを一元
管理する場合に好適なソフトウエア仕様管理方法に関す
る。

〔発明の背景〕

従来、ソースプログラムを管理する方法としては、構造
エディタによるソースプログラム管理方式がある（原田
賢一：「構造エディタ」，情報処理学会誌，Vol.25,198
4,No.8,PP767〜776参照）。

構造エディタにおいては、ソースプログラムは、コンパ
ラインが内部中間語として扱っているような、プログラ
ミング言語文法規則に基づいて構文解析した結果の構文
木として管理されている。

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

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

プログラミング言語文法規則としては、例えば以下に示
すような規則１ないし規則４を例にとる。

前述の各規則１〜９において、符号「＜」と「＞」で囲
まれたものを構文要素と呼ぶ。また、の左辺の構文要素がの右辺の要素から成ることを示し、「１」は「または」
の意味を示すものである。これらの符号は、文法規則を
定義するための一般的記法である。

規則１は、「文は、選択文または反復文または代入文か
ら成る」ことを意味する。

規則２は、「選択文は、ＩＦと条件式と、THENと文と、
ELSEと文と、ENDと；とからなる」ことを意味する。

規則３は、「条件式は、項と．GT．と項、または項と、
GE．と項、または項と、EQ．と項、または項と．NE．と
項、または項と．LE．と項、または項と．LT．と項とか
ら成る」ことを意味する。

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

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

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

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

規則８は、「定数は、数字列から成る」ことを意味す
る。

規則９は、「反復文またはWHILEまたはUNTILと、条件式
と、REPEATと、ENDと；とからなる」ことを意味する。

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

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

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

すなわち、前述の各規則に示されたの左辺の構文要素を、の右辺の構文要素で置き換える場合は、左辺構文要素を
親として、右辺構文要素を子供として、その間を有向グ
ラフ「→」で結びつけて木を構成する。

例えば、第３図のソースプログラムにおいて、＜文＞は
＜選択文＞であるので、まず、規則１を適用して第４図
の“Ｉ”部分の木が構成される。

＜選択文＞は規則２に準拠して、第４図の“II”部分で
示した構文木に構成される。

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

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

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

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

また、前記規則１ないし４に基づいて記述されたロジッ
ク設計仕様の一例を第５図に示す。なお明らかなよう
に、このロジック設計仕様は、第３図に示したソースプ
ログラムに対応するものである。

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

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

第１表において、Ｅ欄は親の構文要素番号、またP1，P2
………Pjの各欄はそれぞれ第６図に示した各子供構文要
素の番号をあらわしている。

すなわち、親の構文要素＜文＞の番号は「１」であり、
これに関連づけられた子供構文要素は、番号「２」の＜
選択文＞のみである。また、親としての構文要素「２」
に関連づけられた子供構文要素は番号「３」「４」およ
び「５」であらわされている。以下、番号「６」〜「１
０」の構文要素についても同様である。

前記従来技術によれば、構造エディタにより、プログラ
ムのロジック設計仕様およびソースプログラムを、各々
構文木として、電子計算機のメモリ上に管理することが
できる。

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

すなわち、プログラムを作成する場合、通常は、まずプ
ログラムのロジック設計を行なってロジック設計仕様を
作成し、次に、このロジック設計仕様にもとづき、プロ
グミング言語を用いてソースプログラムを作成する。

そして最後に、このソースプログラムをコンパイラによ
り機械語に翻訳し、計算機で実行させて正常に動作する
かどうかを確認する。

その結果、もし正常に動作しない場合は、その原因を究
明し、ロジック設計仕様およびソースプログラムを修正
し、再度電子計算機で実行させる。そして、必要に応じ
てはさらに、前記の修正と実行をくり返すことになる。

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

この結果、ロジック設計仕様とソースプログラム間の仕
様不一致（不整合）が発生し、プログラムの品質が大幅
に低下するという問題点があった。

不整合発生の具体例を、第７図および第８図を参照して
以下に説明する。

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

前述の変更に対応して、本来ならば、第８図(a)に示し
たソースプログラムの「TEMP．LE．１００」も「TEMP．
LE．９０」と変更しなければならない。

にもかかわらず、この変更を忘れると、(b)のように、
ソースプログラムの「１００」が「９０」に変更されな
いままとする。

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

〔発明の目的〕

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

〔発明の概要〕

本発明は、「第６図に示したロジック設計仕様の構文木
と、第４図に示したソースプログラムの構文木とを比較
して見れば判るように、両者は、 (1)第９図(a)に示した部分では一致しており、 (2)異なるのは、ロジック設計仕様構文木においてはレ
ベルが浅い（第９図のｂ参照）のに対し、ソースプログ
ラム構文木においては、レベルが深い−すなわち、さら
に詳細に構文木が構成される（第９図のｃ参照）点のみ
である。」という２点に着目してなされたものである。

そして、本発明は、従来の木構造に加えて、ロジック設
計仕様構文木とソースプログラム構文木の相違なる部分
を記憶する拡張構文木構造により、ロジック設計仕様と
ソースプログラムを１本の構文木で一元的に管理するよ
うにした点に特徴がある。

〔発明の実施例〕

以下に、図面を参照して本発明の実施例を説明する。

まずロジック設計仕様とソースプログラムを一元管理す
るための拡張構文木の構造を第１図に示す。第１図にお
いて、 (1)実線矢印で示した有向グラフ→は、親の構文要素か
ら子供の構文要素への詳細化が、ロジック設計仕様とソ
ースプログラムとで一致する場合を示し、 (2)２重線矢印で示した有向グラフ⇒は、親の構文要素
から子供の構文要素への詳細化が、ロジック設計仕様の
場合であることを示し、また、 (3)点線矢印で示した有向グラフは構文要素の詳細化がソースプログラムの場合であるこ
とをそれぞれ示している。

本発明による拡張構文木によれば、ロジック設計仕様と
ソースプログラムは、１本の拡張構文木として管理する
ことが出来る。

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

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

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

また、＜条件式＞の構文要素は、ロジック設計仕様では
の部分木のように詳細化され、一方、ソースプログラ
ムではの部分木のように詳細化される。

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

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

第２表のGj欄は、該当構文要素と、Pj欄に示されたｊ番
目の子供構文要素との関係を示す有向グラフの種別を示
したものである。すなわち、第１図において実線矢印、
２重線矢印および点線矢印で示された有向グラフを、そ
れぞれ「０」「１」「２」で表わしたものである。

これを第２表に即してさらに具体的に説明すれば、例え
ば、第１図の構文要素３と構文要素６および構文要素８
の関係は、第２表の構文要素３の行（横方向）の形で記
憶される。

すなわち、Ｅ欄の構文要素３は、Ｐ１欄の番号６で示さ
れる構文要素（すなわち、構文要素６）で構成され、し
かも、構文要素３から構文要素６への詳細化は、Ｇ１欄
で示される種別１（すなわち、２重線矢印）により、ロ
ジック設計仕様の詳細化であることを示している。

また同時に前記構文要素３は、Ｐ２欄の番号８で示され
る構文要素（すなわち、構文要素８）で構成され、しか
も、構文要素３から構文要素８への詳細化は、Ｇ２欄で
示される種別２（すなわち、点線矢印）により、ソース
プログラムとしての詳細化であることを示している。ま
た、このように同一の構文要素３が異なった種別１、２
（すなわち、２重線矢印と点線矢印）でそれぞれ子供の
構文木６、８に詳細化されている場合には、各子供の構
文木６、８は、同一の構文要素３を『ロジック設計仕様
構文木』および『ソースプログラム構文木』という異な
った木構造で詳細化している、換言すれば、構文木６と
構文木８とは、その構造が異なっていても実態は同一で
あり、両者は一意に対応することを示している。

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

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

第１０図の処理アルゴリズムを、第１１図のロジック設
計仕様変更例の場合（修正対象がロジック設計仕様の場
合）について説明する。

まず、Ｂ１０では、修正対象がロジック設計仕様である
か、またはソースプログラムであるかの判定をする。

Ｂ２０により、第１，２図において、実線矢印および２
重線矢印で表わされた部分木が、第２表のテーブルを参
照して抽出され、Ｂ３０によりCRTに表示される。

前記のＢ２０によって抽出された部分木は、ロジック設
計仕様であり、CRT画面やプリンタ上では、第１１図に
示したように、 IF温度が１００℃以下 THEN スイッチをＯＮにする ELSE スイッチをＯＦＦにする END；と表示される。

プログラマがCRT画面上で、「温度が１００℃以下」を
「温度が９０℃以下」に変更した場合、第１０図のＢ４
０，５０により、「温度が１００℃以下」という部分木
（第１１図の部分）に対応するソースプログラムの部
分木（第１１図の部分）を以下のように特定して取り
出し、CRT画面に表示する。すなわち、 TEMP．LE．１００を表示する。

ここで、ロジック設計仕様の部分木ａに対応するソース
プログラムの部分木ｂを一意に特定する方法について説
明する。なお、以下では説明を判りやすくするために、
選択文＝ＩＦ＜条件式＞ＴＨＥＮ＜文＞ＥＬＳＥ＜文＞
ＥＮＤを図１の構文要素２、その＜条件式＞を構文要素
３、「温度が１００℃以下」を構文要素６と仮定する。

初めに、第１１図の拡張構文木に対応する第２表のテー
ブルのＥ欄の番号３（すなわち、構文要素３）の行（横
方向）を参照すると、そのＰ１欄に番号６（すなわち、
構文要素６）が記憶されていることから、「温度が１０
０℃以下」という部分木ａ（構文要素６）は、選択文の
中の＜条件式＞という構文要素３の詳細化であることが
判る。

また、そのＰ２欄には番号８（すなわち、構文要素８）
が記憶されていることから、構文要素３には更に別の子
供の構文木（構文要素８）が存在することが判る。しか
も、そのＧ１欄およびＧ２欄には番号１（すなわち、２
重線矢印）、２（すなわち、点線矢印）が記憶されてい
ることから、構文要素６へは種別１（２重線矢印）で詳
細化され、構文要素８へは種別２（点線矢印）で詳細化
されていることが容易に判る。この結果、構文要素６と
構文要素８とは相互に対応し、その実態は同一であるこ
とがわかる。

そして、構文要素８が「TEMP．LE．１００」を表現する
構文木ｂである旨は別途管理されていることから、プロ
グラマがＣＲＴ画面上で「温度が１００℃以下」を「温
度が９０℃以下」に変更すると、これに対応するソース
プログラム「TEMP．LE．１００」がＣＲＴ画面上に自動
的に表示されることになる。

なお、「温度が１００℃以下」の構文要素６がロジック
設計仕様およびソースプログラムに共通の構文であれ
ば、これに対応する他の形式の構文要素は存在しないの
で、改めて説明するまでもなく、対応した構文要素は表
示されることなく次の処理へ進む。

次に、Ｂ６０により、プログラマに「TEMP．LE．１０
０」の変更要否を問合せる。プログラマは、この問合せ
に応じ、必要に応じて、例えばソースプログラムの１部
「１００」を「９０」に変更する。

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

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

以上述べたように、本発明の方法によれば、プログラマ
がロジック設計仕様を変更する場合、対応するソースプ
ログラムの変更の要否が電子計算機側から問合せられる
ので、必要なソースプログラムの変更が忘れずに実施さ
れる。

このため、ロジック設計仕様とソースプログラムとが、
拡張構文木上で不一致となることがなく、整合性を保ち
ながら管理される。

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

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

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

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

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

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

〔発明の効果〕

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

これにより、ロジック設計仕様とソースプログラムを両
者の整合性を保ちながら管理できるので、プログラム品
質の低下を未然に防止することができる。

【図面の簡単な説明】

第１図は本発明による拡張構文木の概略構成を説明する
ための図である。第２図は本発明の拡張構文木によって、ロジック設計仕
様とソースプログラムの一元管理を実現するテーブルの
構成例を示す図である。第３図はプログラミング言語規則に基づいて作成された
ソースプログラムの例を示す図である。第４図は第３図のソースプログラムを構造エディタの構
文木で示した図である。第５図はロジック設計言語規則に基づいて作成されたロ
ジック設計仕様の例を示す図である。第６図は第５図のロジック設計仕様を構造エディタの構
文木で示した図である。第７図および第８図はロジック設計仕様とソースプログ
ラムとの不整合を説明するための、ソースプログラム、
ロジック設計仕様および構文木を示した図である。第９図はロジック設計仕様構文木とソースプログラム構
文木の一致点および相違点を説明した点である。第１０図は拡張構文木に基づいてロジック設計仕様およ
びソースプログラムを変更する場合の構造エディタの処
理アルゴリズムを示すフローチャートである。第１１図はロジック設計仕様変更の例を示した図であ
る。第１２図は本発明の１実施例の全体構成を示すブロック
図である。

Claims

【特許請求の範囲】

【請求項１】プログラムのロジック設計仕様およびソー
スプログラムを、両者に共通の構文木に対応する第１の
部分木と、ロジック設計仕様に特有の構文に対応する第
２の部分木と、ソースプログラムに特有の構文に対応す
る第３の部分木とに分割し、これらを構造エディタが扱
う構文木の形式で１つの拡張構文木として電子計算機メ
モリ上に記憶・管理するソフトウエア仕様管理方法にお
いて、プログラムを構成する各構文要素の親子関係を、親の構
文要素から詳細化された子供の構文要素が、第１、第２
および第３の部分木のいずれであるかを示す情報と共に
記憶・管理し、前記拡張構文木上に記載されたロジック設計仕様および
ソースプログラムの一方の構文要素を、構造エディタに
よって変更する場合には、変更対象の構文要素に対応す
る、前記ロジック設計仕様およびソースプログラムの他
方の構文要素を、前記親子関係に基づいて選択し、選択された構文要素を可視的に端末に表示することを特
徴とするソフトウエア仕様管理方法。
【請求項２】構文要素を可視的に表示する前記端末は、
ＣＲＴおよびプリンタの少なくとも１つであることを特
徴とする前記特許請求の範囲第１項記載のソフトウエア
仕様管理方法。
【請求項３】構文要素を可視的に表示する前記端末は、
会話端末であることを特徴とする前記特許請求の範囲第
１項または第２項記載のソフトウエア仕様管理方法。