JPH04195222A - モジュール仕様書検証システム - Google Patents

モジュール仕様書検証システム

Info

Publication number
JPH04195222A
JPH04195222A JP31939190A JP31939190A JPH04195222A JP H04195222 A JPH04195222 A JP H04195222A JP 31939190 A JP31939190 A JP 31939190A JP 31939190 A JP31939190 A JP 31939190A JP H04195222 A JPH04195222 A JP H04195222A
Authority
JP
Japan
Prior art keywords
module
specifications
function
modules
name
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
Application number
JP31939190A
Other languages
English (en)
Inventor
Katsuhiko Oba
克彦 大場
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shimadzu Corp
Original Assignee
Shimadzu Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Shimadzu Corp filed Critical Shimadzu Corp
Priority to JP31939190A priority Critical patent/JPH04195222A/ja
Publication of JPH04195222A publication Critical patent/JPH04195222A/ja
Pending legal-status Critical Current

Links

Landscapes

  • Stored Programmes (AREA)

Abstract

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

Description

【発明の詳細な説明】 A、産業上の利用分野 この発明は、自然言語で記述された仕様書から、ユーザ
の要求を満足するプログラムを自動的に作り出す自動プ
ログラミングツステムで利用されるものであって、前記
仕様書(モジュール仕様書)の記述内容を検証するモジ
ュール仕様書検証システムに関する。
B、従来技術 通常、プログラムは複数のモジュール(サブプログラム
)から構成され、さらに、各モジュールはいくつかのモ
ジュールから構成される、という階層構造を持っている
自動プログラミングシステムでは、まず、個々のモジュ
ールのソースコードを生成し、これらのソースコードを
結合して目標プログラムを生成するという手法が採られ
ており、個々のモジュールのソースコードは、モジュー
ルの仕様を記述したモジュール仕様書から生成される。
モジュール仕様書は、そのモジュールの入出力データ名
、データ型などを定義するデータ定義項目や、定義され
たデータの処理内容を処理手順Jこしたがって記載する
処理手順項目などの複数の項目から構成されている。
このようなモジュール仕1書からソースコードを自動的
に生成する場合、処理手順項目に記載されている内容を
分析し、それにしたがってソースコードを生成するので
あるが、処理手順項目に表記されているデータと、デー
タ定義項目に定義されているデータとが一致していない
と、生成されたモジュールが正常に動作しなかったり、
また、各モジュール間で受は渡される入出力データ(イ
ンターフェイス関係)がそれらの仕様書内で一致して定
義されていないと、モジュール同士を結合して最終的な
目標プログラムを得ることができなくなってしまう。
そこで、モジュール仕様書の上記各項目内で記述されて
いるデータが一致しているがどうが、各モジュールのイ
ンターフェイス関係が一致しているかどうかの検証を行
う必要があり、従来のモジュール仕様書検証ノステムで
は、個々のモジュール仕様書を解析二でその記述誤?り
やインターフェイス関係を検証している。
C8発明が解決しようとする課題 プログラムを開発するにあたって、初期のモジュール仕
様に対して機能を追加したり、あるいは削除したりする
ことがあり、これには入出力データ変更(インターフェ
イスの変更)が伴う。
上述したように、プログラムは複数のモジュールを階層
構造化したものであるため、1つのモジュールの仕様を
変更すると、そのモジュールの上下位にあるモジュール
とのインターフェイス関係を、その変更にしたがって修
正する必要がある。
この場合、すでに上述したモジュール仕様書検証システ
ムで検証を終えたモジュールもその修正対象モジュール
となることがあり、修正対象モジュール(変更したモジ
ュールの上下位にあるモジュールで要修正モジュールと
もいう)を検索するにあたっては人手を軽るしがなかっ
た。
変更したモジュールの下位モジュールは、変更モジュー
ルの仕様書内で゛呼び出し間数“として定義されている
ため、変更したモジュール仕様書をみれば容易二こそれ
を検索することができるが、上位にあるモジュール(変
更したモジュールを逆に′呼び出し関数“として定義し
ているモジュール)は変更モジュールの仕様書内では定
義されておらず、これを検索するためには、全てのモジ
ュール仕様書内を調べ、上位にあるモジュールを探す必
要があった。これを人手で行うのであるから、検索に要
する労力や時間は大幅に費やされ、検索の正確性に欠け
るという問題点が生している。
この発明は、このような事情に鑑みてなされたものであ
って、要修正モジュールを自動的に検出することができ
るモジュール仕様書検証システムを提供することを目的
としている。
01課題を解決するための手段 この発明は、上記目的を達成するために次のような構成
を備えている。
すなわち、この発明に係るモジュール仕様書検証システ
ムは、プログラムを階層構造化する複数のモジュール(
サブプログラム)の仕様を記述したモジュール仕様書を
格納するモジュール仕様書記憶部と、前記各モジュール
の名称および入出力データ型を含むインターフェイス情
報を記憶する定義関数記憶部と、この定義関数記憶部へ
のインターフェイス情報の登録や削除を行う定義関数更
新部と、インターフェイス情報が更新されるモジュール
名をキーワードとして前記各モジュール仕様書内を検索
し、そのモジュールを下位モジュールとして定義してい
る上位モジュールを要修正モジュールとして検出する要
修正モジュール検出手段と、検出された要修正モジュー
ルをオペレータに提示する出力手段とを備えたことを特
徴としている。
E9作用 この発明による作用は以下のとおりである。
定義関数更新部は、仕様の変更を受けるモジュールのイ
ンターフェイス情報を定義関数記憶部がら削除し、その
モジュール名を要修正モジュール検出手段に送出する。
要修正モジュール検出手段は、与えられたモジュール名
をキーワートニこ巳て、モー゛ニール仕様書記憶部内に
格納されている各モジュール仕様書の内部を検索してい
き、そのモジュールを呼び出し関数として利用している
上位モジュール名を要修正モジュール名として検出する
そして、検出した要修正モジュール名を出力手段に送出
して、オペレータに提示する。
F、実施例 以下、この発明の一実施例を図面に基づいて説明する。
第1図は、モジュール仕様書検証システムの概略構成を
示したブロック図である。
オペレータによって操作されるキーボード1と、要修正
モジュール名などを表示するモニタデイスプレィ2とが
インターフェイス3を介して、以下の構成部品と相互に
接続されている。
符号4はオペレータによるモジュール仕様書の作成を支
援するモジュール仕様書作成支援部である。
ここで作成されるモジュール仕様書は、プログラムを構
成する複数のモジュールの仕様を記述した書式で、各モ
ジュールは階層構造を形成じでいる。その−例を第2回
に示す。この例では、モジュールミルモジュールCがプ
ログラムAを構成して、モジュールal とa2がモジ
ュールaを、モジュールal とb2がモジュールbを
、モジュールa2 C,c2がモジュールCを構成して
いる。
以後、モジュールa −Cを上位モジュール、添え字を
付加したモジュールa1〜C2を下位モジュールという
モジュール仕様書の概略の一例を第3図に示し以下に説
明する。なお、この書式は上下位ともに共通である。
モジュール仕様書は、 [11モジュールの名称 [2i IR能概要 [3] 処理仕様のインターフェイス [41人出力データの詳細事項 [5]  プログラムインターフェイス[61使用環境 7 内部データ宣言 濾 その他 ・9 処理内容 などの項目で構成されている。
Il+ には当該モノニールの名称か記述され、[21
の機能概要項目には、モジュールが果たす機能を要約し
たものが記述される。
[3; の処理仕様のインターフェイスには、主として
入出力データ名、型が定義される。
[4[の入出力データの詳細事項には、人出力データの
説明が記述される。
[5] のプログラムインターフェイスには、内部関数
名(所属するプログラムを構成しているモジュール名)
と外部関数名(他のプログラムを構成しているモジュー
ル名)とが記述される。
[6] の使用環境は、使用する基本ソフトウェアの種
類や、プログラム言語の種類が記述される。
[7] の内部データ宣言には、当該モジュール内で使
用するデータ名、型が記述される。
[9] の処理内容は、処理の流れを図記号を使って記
述↓たもので 例えば、“◎“の記号二よ当該モジュー
ルの関数を表5、そのあとに記述されている文字列が関
数名を表し、“○“の記号は繰り返し処理を、”◇°の
記号は分岐処理を、“・“の記号は順次処理を、それぞ
れ表している。各記号の後にはその記号の持つ意味を文
字で表記しており、例えば、“○“の記号のあとには、
2FOR−という繰り返し処理を表す文字列が、“◇“
の記号のあとには、raF、という分岐処理を表す文字
列が記述されている。
また、@は呼び出し関数を表す記号で、記号のあとに記
述されているのがその関数名、すなわち、当該モジュー
ルに利用される下位モジュールの名称である。その次の
“(・・・)“内には下位モジュールの入力データ名が
記述され、“=〉“の記号のあとの“(・・・)“内に
は出力データ名が記述される。なお、この入出力データ
名の記述方法は、“◎°記号のあとに記述されている当
該モジュールの関数に対しても同様である。
上記のようなモジュール仕様書は、モジュール仕様書作
成支援部lを起動してオペレータ自身↓こより作成され
る。
第1図に戻って、符号5は上記のモジュール仕様書を格
納する仕様書記憶部、6はモジュール仕様書の記述誤り
やモジュール間のインターフェイス関係の一致を検証す
るモジュール仕様書検証部である。
7はプログラムを構成する各モジュール名(関数名と同
義)および、入出力データ型を登録する定義関数辞書で
、モジュール仕様書検証部6がモジュール間のインター
フェイス関係を検証するときにアクセスする辞書ファイ
ルである。定義関数辞書7に登録される情報を模写した
のが第4回である。8は定義関数辞書7への登録を行う
登録部、9は定義関数辞書7の削除処理を実行する削除
部、】0は定義関数辞書7内のデータを所定の表示形態
にしてモニタデイスプレィ2に表示する定義関数表示部
である。
以上の構成部品で、モジュール仕様書の記述誤りや入出
力インターフェイス関係の一致が検証される。
符号11−よあるモジュールの内容変更に伴い、インタ
ーフェイス関係を修正する必要のあるモジュール(要修
正モジュール)を検出する要修正モジュール検出部で、
文字コートを一時記憶するし・ジスタA、Bを備えてい
る。この要修正モンユ−)し検出部11が本発明の特徴
を示す構成部品の1つとなっている。
12はモジュール仕様書検証部6で検証済みとなったモ
ジュール仕様書の処理内容に記述されてL)る図記号な
どを解析してソースコードを生成するソースコード生成
部である。
次に、要修正モジュール検出部11の動作について第5
図のフローチャートを基に説明する。
ここで、第2図のモジュールjIN構造中、下位モジュ
ールatにある機能を追加したため、下位モジュールa
2の入出力データ数、型に変更が生じたとする。これに
伴い下位モジュールatを利用している上位モジュール
のインターフェイス関係も変更しなければならない。そ
の上位モジュール(要修正モジュール)を自動的二こ検
出する処理について以下に説明する。なお、このとき、
機能を変更する下位モジュールa2の名称(モジュール
at)、入出力データ型はオペレータのキーボード操作
によって定義関数辞書7から削除されているとする。こ
れは、新たに変更後の入出力データ数、型を登録する前
の処理である。
まず、ステップSlで、削除部9から削除モジュール名
を入力する。この例では、削除モジュール名:モジュー
ルa2が入力される。
ステップS2で、これらの文字コードをレジスタAに登
録する。
ステップS3で、定義関数辞書7から1つの関数名を順
番に取り出す(第4図参照)。ここでは、まず、先頭の
上位モジエールaが取り出されたとする。
ステップS4で、定義関数辞書7内の全ての関数の取り
出しを終了したかどうかを判断し、取り出しを終了した
場合はこの処理を終え、まだの場合は次のステップS5
に進む、全ての関数の取り出しを終了した場合には、関
数名の代わりに゛定義関数辞書終端記号、・が読み込ま
れる。
ステップS5で、取り出しだ関数名「モジュールaJを
キーワードにして、モジュール仕様書記憶部5内を検索
し、モジュールaの仕様書を抽出する。
ステ、ブS6で、抽出したモジュールaの仕様書の項目
番号[9(を検索キーとして処理内容項目を読み出し、
さらに、呼び出し関数記号@を検索キーとし、モジュー
ルaが呼び出している関数名、つまり、モジュールaが
持っている下位モジュール名を取り出す。
そして、取り出した下位モジュール名と入出力データ型
をレジスタBに登録する。ここで、第3図を参照して、
登録された下位モジュール名が、最初に記述されている
[モジュールa+Jであったとする。
ステ、ブS7で、レジスタAと已に登録した内容(文字
コード)、すなわち、モジュール名の比較を行う。この
例では、レジスタAに登録されているモジュール名が″
モジュールa2.で、レジスタB 5こ登録されている
モジュール名が−モジュールa1−・であるから、一致
しないと判断されて、ステップS9に進む。
ステップS9では、モジュールaの仕様書内で記述され
ている全ての呼び出し関数情報と、レジスタAに登録さ
れている内容との比較を終了したかを判断する。この例
では、第3図示のように、呼び出し関数としての「モジ
ュールa2Jとの比較がまだ残っているので、ステップ
S6にリターンし、[モジュールazJがレジスタBに
登録される。
そして、ステップS7で、レジスタAとBとの内容を比
較した結果、両者の情報が一致する。
一致するとステップS8に進み、ステップS3で取り出
した関数名「モジュールa」を定義関数表示部10に出
力して、ステップS3にリターンし、次の上位モジュー
ルに対して上記一連の処理を繰り返す。
第2図示のように、次の上位モジュールとじてモア・1
−ルb、そしてモジュールCが読み出され、結果、変更
モジュールa2にかかわる要修正モジュールとして先の
モジュールaとモジュールCが検出される。
なお、ステップS9で、モジュールaの仕様書内で記述
されている全ての呼び出し関数と、レジスタAに登録さ
れている内容情報との比較が終わったと判断された場合
もステップS3二こリターンする。
ステップS8の処理による定義関数表示部10の表示形
態の一例を第6回に示す。
この例では、要修正モジュール名の状態欄に「要変更(
または、要修正)」の文字表示を行うことによって、オ
ペレータに報知している。定義関数表示部10には表示
用メモリ(図示せず)が備えられており、この表示用メ
モリには予め第6図に示すような表示用書式が記憶され
ている。
定義関数表示部10は関数定義辞書7に登録されている
情報を読み出して、表示用書式中に入力し、第6図に示
した「定義関数表」としてモニタデイスプレィ2に出力
する。したがって、ステ、ブS8で要修正モジュール名
が出力されると、“定義関数表、中、同し名称で登録さ
れているモジュール名の状Mlに先の文字表示を行う。
なお、状態欄に登録される状態名は、定義関数表示部1
0がオペレータからのキーボード−命令を受は取って表
示するようになっている。すなわち、「作成中」はオペ
レータによって、モジュール仕様書作成支援部4が起動
され、当該モジュールの仕様書を作成している状態、「
検証法」はオペレータによって当該モジュール仕様書の
検証命令が出され、モジュール仕様書検証部6による検
証が終わった状態、「生成済」はオペレータによって当
該モジュール仕様書のソースコード生成命令が出され、
ソースコード生成部12によるソースコード生成が終わ
った状態である。
これを利用し、先の文字表示「要変更(または、要修正
)」の変形例として、すでに、「検証法」となっている
上位モジュールの状態名を「作成中」に替えるようにし
てもよい。これで、モジュール仕様書二こ11正箇所が
あり、再び作成中に戻るという意図がオペレータに伝え
られる。
以上のようにして、要修正モジュールが自動的に検出さ
れ、オペレータに報知されると、オペレータは、まず、
機能を変更した下位モジニールa2の新たな(変更後の
)入出力データ数。
型を登録部8から定義関数辞書7内乙こ書き込む。
これに合わせて、下位モジュールa2を呼び出して利用
しているモジュール(報知されたモジュールa、モジュ
ールC)の仕様書中、呼び出し宣言部の変更を行う。
なお、上述した実施例では、下位モジュールa2の機能
変更に伴う要修正モジュールの自動検出について説明し
たが、下位モジュールa2をプログラム階層構造の中か
ら削除する場合にも、同様にして下位モジュールa2を
利用している要修正モジュールを検出することができる
G9発明の効果 以上の説明から明らかなように、この発明に係るモジュ
ール仕様書検証システムは、仕様が変更されたモジュー
ルの名称をキー一一ト二こじで、階層構造化された各モ
ジュールの仕様書内を検索じていき、変更モジュールを
下位として利用する上位モジュールを要修正モジュール
と巳て検出じ、オペレータに提示するようにしたので、
従来のように人手でモジュール仕様書内を調べて要修正
モジュールを検出のムニ比べ、オペレータの労力と時間
とを大幅に削減することができ、検出の正確性も増す。
【図面の簡単な説明】
第1図ないし第6図は、この発明の一実施例に係り、第
1図はモジュール仕様書検証システムの概略構成を示し
たブロック図、第2図はプログラムを構成するモジュー
ルの階層構造例を示した図、第3図はモジュール仕様書
の一例図、第4図は定義関数辞書内の情報を模写した図
、第5図は要修正モジュール検出処理手順を示したフロ
ーチャート、第6図はオペレータに提示される要修正モ
ジュールの表示形態の一例を示した図である。 2・・・モニタデイスプレィ 5・・モジュ−ル仕様書記憶部 7・・定義関数辞書 8・・・登録部・ )定義関数更新部 9・・・削除部・ 10・・・定義関数表示部 】1・・・要修正モジュール検出部 特許出願人 株式会社 島津製作所

Claims (1)

    【特許請求の範囲】
  1. (1)プログラムを階層構造化する複数のモジュール(
    サブプログラム)の仕様を記述したモジュール仕様書を
    格納するモジュール仕様書記憶部と、前記各モジュール
    の名称および入出力データ型を含むインターフェイス情
    報を記憶する定義関数記憶部と、この定義関数記憶部へ
    のインターフェイス情報の登録や削除を行う定義関数更
    新部と、インターフェイス情報が更新されるモジュール
    名をキーワードとして前記各モジュール仕様書内を検索
    し、そのモジュールを下位モジュールとして定義してい
    る上位モジュールを要修正モジュールとして検出する要
    修正モジュール検出手段と、検出された要修正モジュー
    ルをオペレータに提示する出力手段とを備えたことを特
    徴とするモジュール仕様書検証システム。
JP31939190A 1990-11-24 1990-11-24 モジュール仕様書検証システム Pending JPH04195222A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP31939190A JPH04195222A (ja) 1990-11-24 1990-11-24 モジュール仕様書検証システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP31939190A JPH04195222A (ja) 1990-11-24 1990-11-24 モジュール仕様書検証システム

Publications (1)

Publication Number Publication Date
JPH04195222A true JPH04195222A (ja) 1992-07-15

Family

ID=18109649

Family Applications (1)

Application Number Title Priority Date Filing Date
JP31939190A Pending JPH04195222A (ja) 1990-11-24 1990-11-24 モジュール仕様書検証システム

Country Status (1)

Country Link
JP (1) JPH04195222A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7861227B2 (en) 2002-12-06 2010-12-28 Ricoh Company Ltd. Software development environment with design specification validation tool

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7861227B2 (en) 2002-12-06 2010-12-28 Ricoh Company Ltd. Software development environment with design specification validation tool

Similar Documents

Publication Publication Date Title
JP3259928B2 (ja) 業務仕様ハンドリング装置
JP5747698B2 (ja) 要件管理支援装置
JPH04195222A (ja) モジュール仕様書検証システム
JP3516843B2 (ja) データベースアクセス方法
JPH04242829A (ja) プログラム更新システム
JPH0750480B2 (ja) 文章データ編集装置
JP3337717B2 (ja) データベース処理装置およびデータベース処理方法
JP2990314B2 (ja) データ管理装置
JPH04348468A (ja) データベース装置
JP3722854B2 (ja) データ編集装置
JP3499040B2 (ja) データベース設計支援システム
JP3143909B2 (ja) ファイル処理装置
JPH07121599A (ja) 設計情報提示装置
JPH0887548A (ja) 情報管理装置とその情報管理方法
JPH1040089A (ja) データ移行プログラム生成方式
CN117632997A (zh) 一种跨数据库平台的命令行界面及读写操作方法
JP2855203B2 (ja) 伝票レコードデータ作成処理装置
JPH05143304A (ja) 整合性検査方式
JP3231120B2 (ja) 図面管理システム
JPS608935A (ja) 対話形プログラム処理方式
JPH04290137A (ja) 情報処理システムにおけるデータベース構築方法
JPH0511989A (ja) パラメータ解析装置
JPH01307844A (ja) 編集装置
JPH0756727A (ja) プログラムの改定履歴の生成方法とその装置
JPH09128284A (ja) ファイル編集装置