【事件の表示】
　特許第３１１２６２３号「プログラム生産支援装置」の請求項１、３、５ないし９、１１、１３、１４に係る特許に対する特許異議の申立てについて、次のとおり決定する。
【結　論】
　訂正を認める。
　特許第３１１２６２３号の請求項１、３、５ないし８に係る特許を取り消す。
【理　由】
第１　手続・経緯
　(1)出　願　日：平成 6年 9月21日
　(2)登　録　日：平成12年 9月22日
　(3)公報発行日：平成12年11月27日
　(4)異議申立（１件）
　　　　異議申立日：平成13年5月28日
　　　　申立請求項：請求項１，３，５〜９，１１，１３〜１４
　　　　異議申立人：富士通株式会社
　(5)取消理由通知書：平成13年11月19日（起案日）
　(6)訂正請求書：平成14年1月29日（提出日）
　(7)取消理由通知書：平成15年6月16日（起案日）
　(8)訂正請求書：平成15年8月26日（提出日）
　(9)訂正拒絶理由通知書：平成15年9月10日（起案日）
 (10)手続補正書：平成15年11月21日（提出日）
　
　
第２　訂正の適否
１．訂正請求書の補正の適否
（１）補正の内容
　平成15年8月26日付訂正請求書に対する、平成15年11月21日付の補正は、次のとおりのものである。
　
「（１）　１．補正前の訂正請求書の訂正事項ａを削除するために、補正前の訂正請求書第２頁第１７行目〜第４頁第１行日の「○１（審決注：○の中に数字が記載されているものを○数字で代用した。以下、同様に代用する。）訂正事項ａ　・・・訂正する。」の記載、および同第９頁第５行目〜第１０頁第５行目の「○１上記訂正事項ａについては、・・・適合するものである。」の記載を削除する。
　２．補正前の訂正請求書の訂正事項ａを削除したことに伴い、補正前の全文訂正明細書における特許請求の範囲の請求項１中の「自然言語と各機能の階層構造を示す記号とがテキストで記述された書籍の目次に準じた形式の仕様記述を読み込みその内容を字句に分解する字句解析手段と、」を、「自然言語と各機能の階層構造を示す記号とで記述された仕様記述を読み込みその内容を字句に分解する字句解析手段と、」と訂正し、同請求項１中の「疑似言語記述のひな型を生成する生成手段と」を、「疑似言語記述を生成する生成手段と」と訂正する。
　そして、補正前の全文訂正明細書の段落番号【０００６】第６行目、同段落番号【０１５９】第３行目の「記号とがテキストで記述された書籍の目次に準じた形式の」をそれぞれ「記号とで記述された」と訂正し、同段落番号【０００６】第１０行〜第１１行目、同段落番号【０１５１】第８行目の「疑似言語記述のひな型を生成する生成手段と」をそれぞれ「疑似言語記述を生成する生成手段と」と訂正する。
　さらに、補正前の全文訂正明細書における特許請求の範囲の請求項２中の「自然言語と各機能の階層構造を示す記号とで記述された仕様記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された仕様記述の構文解析を行う構文解析手段と、構文解析結果をもとに各機能の階層構造を抽出する階層構造抽出手段と、上記抽出された階層構造をもとに上記仕様記述に対応した図または自然言語及びプログラミング言語に準じた制御構造で記述された疑似言語記述を生成する生成手段とを有し、上記仕様記述には、種別を示す記号が記述されており、上記生成手段は、」を「仕様記述には、種別を示す記号が記述されており、生成手段は、」と、同請求項２中の「プログラム生産支援装置。」を「請求項１記載のプログラム生産支援装置。」とそれぞれ訂正する。
　そして、補正前の全文訂正明細書の段落番号【０００７】第１行目〜第７行目、同段落番号【０１５２】第１行目〜第７行目の「また、この発明に係るプログラム生産支援装置は、自然言語と各機能の階層構造を示す記号とで記述された仕様記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された仕様記述の構文解析を行う構文解析手段と、構文解析結果をもとに各機能の階層構造を抽出する階層構造抽出手段と、上記抽出された階層構造をもとに上記仕様記述に対応した図または自然言語及びプログラミング言語に準じた制御構造で記述された疑似言語記述を生成する生成手段とを有し、上記仕様記述には、種別を示す記号が記述されており、上記生成手段が、」を「さらに、仕様記述に、種別を示す記号を記述し、生成手段が、」と、同段落番号【０００７】第９行目の「生成するものである。」を「生成するようにしてもよい。」と、同段落番号【０１５２】第９行目の「生成するので、」を「生成する場合には、」とそれぞれ訂正する。
（２）補正前の訂正請求書の訂正事項ａを削除したことに伴い、補正前の訂正請求書の訂正事項ｂを訂正事項ａとするために、補正前の訂正請求書第４頁第２行目の「○２訂正事項ｂ」を「○１訂正事項ａ」と、同第１０頁第６行目の「○２上記訂正事項ｂ」を「○１　上記訂正事項ａ」と、同第１０頁第１５行日、同第１０頁第２８行目の「訂正事項ｂ」を「訂正事項ａ」とそれぞれ訂正する。
（３）補正前の訂正請求書の訂正事項ａを削除したことに伴い、補正前の訂正請求書の訂正事項ｃを訂正事項ｂとするために、補正前の訂正請求書第５頁第１３行目の「○３訂正事項ｃ」を「○２訂正事項ｂ」と、同第１１頁第１行目の「○３上記訂正事項ｃ」を「○２上記訂正事項ｂ」と、同第１１頁第１３行目、同第１１頁第２８行目の「訂正事項ｃ」を「訂正事項ｂ」とそれぞれ訂正する。
（４）補正前の訂正請求書の訂正事項ａを削除したことに伴い、補正前の訂正請求書の訂正事項ｄを訂正事項ｃとするために、補正前の訂正請求書第５頁第２７行目の「○４訂正事項ｄ」を「○３訂正事項ｃ」と、同第１２頁第１行目の「○４上記訂正事項ｄ」を「○３　上記訂正事項ｃ」と、同第１２頁第１５行目、同第１３頁第１行目の「訂正事項ｄ」を「訂正事項ｃ」とそれぞれ訂正する。
（５）補正前の訂正請求書の訂正事項ａを削除したことに伴い、補正前の訂正請求書の訂正事項ｅを訂正事項ｄとするために、補正前の訂正請求書第６頁第２２行目の「○５訂正事項ｅ」を「○４訂正事項ｄ」と、同第１３頁第３行目の「○５上記訂正事項ｅ」を「○４上記訂正事項ｄ」と、同頁第７行目　の「訂正事項ｅ」を「訂正事項ｄ」とそれぞれ訂正する。」
　
２．補正の適否
　前記補正は、平成15年8月26日付訂正請求書中の、訂正事項ａを削除するとともに、当該削除に伴い、同訂正事項ｂ〜ｅを、訂正事項ａ〜ｄとして繰り上げるためのものであるから、前記平成15年8月26日付の訂正請求書の要旨を変更するものではない。
　したがって、平成15年11月21日付の手続補正書による平成15年8月26日付訂正請求書の補正は適法なものである。
　
３．訂正の要旨
　前記１．のとおり補正された平成15年8月26日付訂正請求書による訂正は、前記手続補正書の「７．請求の理由」，「（３）訂正の要旨」に記載の次のとおりのものである。
　
「○１訂正事項ａ
　　特許請求の範囲の請求項３中の「自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、」を特許請求の範囲の減縮を目的として、「自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、」と訂正する。
　　これに伴ない、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を目的として、明細書の段落番号【０００８】第２行目、同段落番号【０１６１】第２行目の「制御構造で記述された疑似言語記述」を「制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述」とそれぞれ訂正する。
　　さらに、特許請求の範囲の請求項３の訂正をするに伴ない、訂正前の請求項３を引用する特許請求の範囲の請求項４を独立形式とするため、明瞭でない記載の釈明を目的として、同請求項４中の「疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、生成手段は、」を「自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、上記生成手段は、」と、同請求項４中の「請求項３記載のプログラム生産支援装置。」を「プログラム生産支援装置。」とそれぞれ訂正する。
　これに伴ない、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を目的として、明細書の段落番号【０００８】第６行目〜第７行目、同段落番号【０１６１】第８行目〜第９行目の「また、疑似言語記述に、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とを記述し、生成手段が、」を「また、この発明に係るプログラム生産支援装置は、自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、上記生成手段が、」と、同段落番号【０００８】第１３行目の「有するようにしてもよい。」を「有するものである。」と、同段落番号【０１６１】第１５行目の「有する場合には、」を「有しているので、」とそれぞれ訂正する。
○２訂正事項ｂ
　特許請求の範囲の請求項７中の「構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段と」を特許請求の範囲の減縮を目的として、「構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述を生成する生成手段と」と訂正する。
　これに伴ない、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を目的として、明細書の段落番号【００１１】第５行目、同段落番号【０１６４】第４行目〜第５行目の「図、表または言語記述」を「自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述」と、同段落番号【０１６４】第６行目〜第７行目の「図、表または言語記述」を「疑似言語記述」とそれぞれ訂正する。
○３訂正事項ｃ
　特許請求の範囲の請求項８中の「生成手段は、」、「上記プログラミング言語の文およびコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段と」を明りょうでない記載の釈明を目的として、それぞれ「プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有するものであって、生成手段が、」、「上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段と」と訂正する。
　これに伴ない、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を目的として、明細書の段落番号【００１２】第１行目、同段落番号【０１６５】第１行目の「生成手段が、」を「プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有するものであって、生成手段が、」とそれぞれ訂正し、同段落番号【００１２】第５行目〜第６行目、同段落番号【０１６５】第５行目〜第６行目の「上記プログラミング言語の文およびコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段」を「上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段」とそれぞれ訂正する。
○４訂正事項ｄ
　特許請求の範囲の請求項９−１４において、特許請求の範囲の減縮を目的として、訂正前の請求項９、１１、１３、１４を削除し、さらに、特許請求の範囲の請求項７の訂正をするに伴ない、明瞭でない記載の釈明を目的として、訂正前の請求項７を引用する特許請求の範囲の訂正前の請求項１０、１２を独立形式として、以下項数を繰り上げ、
　　「【請求項９】　特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段は、構文解析結果をもとにプログラミング言語記述のへツダーコメントに記述されたインターフェース仕様を抽出するインターフェース仕様抽出手段と、構文解析結果をもとに上記プログラミング言語記述のモジュールの定義・参照を木構造に変換して記憶するモジュール定義・参照抽出手段と、ヘッダーコメント中のモジュール欄の名称が実際のモジュール名に一致しているかを照合するモジュール名照合手段と、上記インターフェース仕様及び上記木構造をもとにプログラミング言語記述に対応したモジュール仕様書を生成するモジュール仕様生成手段とを有することを特徴とするプログラム生産支援装置。
　　【請求項１０】　特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段は、構文解析結果をもとにシンボルの定義情報を記憶するシンボル定義抽出手段と、上記シンボルの定義情報をシンボルが定義された順に並び換えるシンボル定義並び換え手段と、上記シンボルの定義情報をもとにプログラミング言語記述に対応したシンボル一覧表を生成するシンボル一覧表生成手段とを有することを特徴とするプログラム生産支援装置。」と訂正する。(クレーム対応表参照)
　これに伴ない、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を目的として、明細書の段落番号【００１３】、同段落番号【００１５】、同段落番号【００１７】、同段落番号【００１８】、同段落番号【００２５】、同段落番号【００２７】、同段落番号【００２９】、同段落番号【００３０】、同段落番号【０１６６】、同段落番号【０１６８】、同段落番号【０１７０】、同段落番号【０１７１】の全ての記載をそれぞれ削除し、さらに、同段落番号【００１４】第１行目、同段落番号【０１６７】第１行目の「また、生成手段が、」を「また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、」と、同段落番号【００１４】第８行目の「有するようにしてもよい。」を「有するものである。」と、同段落番号【０１６７】第８行目の「有する場合には、」を「有しているので、」と、同段落番号【００１６】第１行目、同段落番号【０１６９】第１行目の「また、生成手段が、」を「また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、」と、同段落番号【００１６】第５行目の「有するようにしてもよい。」を「有するものである。」と、同段落番号【０１６９】第５行目の「有する場合には、」を「有しているので、」とそれぞれ訂正する。」
　
４．訂正の目的の適否、新規事項の有無及び拡張・変更の存否
（１）訂正事項ａ
（訂正の目的）
　訂正事項ａ−１：
　特許請求の範囲の請求項３中の「自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、」を「自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、」とする訂正は、特許請求の範囲の減縮を行うものである。
　
　訂正事項ａ−２：
　明細書の段落番号【０００８】第２行目、同段落番号【０１６１】第２行目の「制御構造で記述された疑似言語記述」を「制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述」とする訂正は、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を行う訂正である。
　
　訂正事項ａ−３：
　特許請求の範囲の請求項４中の「疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、生成手段は、」を「自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、上記生成手段は、」と、
　同請求項４中の「請求項３記載のプログラム生産支援装置。」を「プログラム生産支援装置。」と、
する訂正は、訂正前の請求項３を引用する特許請求の範囲の請求項４を独立形式とするためのもので、明りょうでない記載の釈明を行う訂正である。
　
　訂正事項ａ−４：
　明細書の段落番号【０００８】第６行目〜第７行目、同段落番号【０１６１】第８行目〜第９行目の「また、疑似言語記述に、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とを記述し、生成手段が、」を「また、この発明に係るプログラム生産支援装置は、自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、上記生成手段が、」と、同段落番号【０００８】第１３行目の「有するようにしてもよい。」を「有するものである。」と、同段落番号【０１６１】第１５行目の「有する場合には、」を「有しているので、」とする訂正は、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を行う訂正である。
　
（新規事項の有無）
　次に、訂正事項ａ−１ないし訂正事項ａ−４について、願書に添付した明細書又は図面に記載した事項の範囲内のものかどうかを検討する。
　訂正事項ａ−１ないしａ−４は、本件明細書の発明の詳細な説明の実施例３に係る記載等に基づくものであるから、実施例３の記載をみると、
　「実施例３では、モジュールのインターフェース仕様と処理フローを記述する手段として、Ｃ言語に準じた疑似言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語（例えば「Ada」）に準じたものであっても構わない。」（【００５６】）、
　「（注１）疑似言語とは、プログラミング言語の制御構造と自然言語の文章が混在する設計用の仮想言語を意味する。」（【００５６】）
と記載されている。したがって、本件明細書の疑似言語は、プログラミング言語の制御構造と自然言語の文章が混在する設計用の仮想言語である。一般にプログラミング言語も自然言語もテキストで記述され、汎用のテキストエディタを用いて入力及び編集されるものであるし、本件発明の目的の一つは「広く一般に普及している汎用のテキスト・エディタを用いて、データの入力および編集を可能にする」（【０００５】）ものであるから、訂正事項ａ−１ないしａ−４は、願書に添付した明細書又は図面に記載した事項の範囲内のものである。
　
（拡張・変更の存否）
　前記ａ−１〜４の訂正は、願書に添付した明細書に記載した発明が解決しようとする課題ないし発明の効果を本質的に変更するものではなく、実質上特許請求の範囲を拡張又は変更するものではない。
　
（２）訂正事項ｂ
（訂正の目的）
　訂正事項ｂ−１：
　特許請求の範囲の請求項７中の「構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段と」を「構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述を生成する生成手段と」とする訂正は、特許請求の範囲の減縮を行う訂正である。
　
　訂正事項ｂ−２：
　明細書の段落番号【００１１】第５行目、同段落番号【０１６４】第４行目〜第５行目の「図、表または言語記述」を「自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述」と、同段落番号【０１６４】第６行目〜第７行目の「図、表または言語記述」を「疑似言語記述」とする訂正は、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を行う訂正である。
　
（新規事項の有無）
　次に、訂正事項ｂ−１，２について、願書に添付した明細書又は図面に記載した事項の範囲内のものかどうかを検討する。
　本件明細書に記載の疑似言語は、前記（２）で述べたとおりテキストで表現されたものであるから、訂正事項ｂ−１は、願書に添付した明細書又は図面に記載した事項の範囲内のものである。訂正事項ｂ−２は、訂正事項ｂ−１による訂正に伴う、不明りょうな記載の釈明を行うものであるから、これらも願書に添付した明細書又は図面に記載した事項の範囲内のものである。
　
（拡張・変更の存否）
　前記ｂ−１〜２の訂正は、願書に添付した明細書に記載した発明が解決しようとする課題ないし発明の効果を本質的に変更するものではなく、実質上特許請求の範囲を拡張又は変更するものではない。
　
（３）訂正事項ｃ
（訂正の目的）
　請求項８に対する訂正、及びこれと整合を図るためにする、発明の詳細な説明に対する訂正は、いずれも明りょうでない記載の釈明を目的としてするものである。
　
（新規事項の有無）
　請求項８の訂正された「プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有する」ことは、図３１ないし図３４と本件明細書の【００８９】の記載等から読み取れる事項である。
　また、請求項８の訂正された「上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する」ことも、図３１ないし図３４と本件明細書の【００８９】の記載等から読み取れる事項であり、両者とも、プログラム言語のモジュール内のコメント、条件文中の条件式に対するコメントをそれぞれ処理説明に変換し、前記モジュール内のコメントに対応する処理説明はモジュール内のコメントの位置に、前記条件式に対するコメントの処理説明は条件式の位置に配置することを示していることは明らかである。
　さらに、前記発明の詳細な説明に対する訂正は、請求項８の訂正に対応して、発明の詳細な説明の明りようでない記載の釈明を目的とするものである。
　したがって、訂正事項ｃは、願書に添付した明細書又は図面に記載した事項の範囲内のものである。
　
（拡張・変更の存否）
　前記訂正事項ｃは、願書に添付した明細書に記載した発明が解決しようとする課題ないし発明の効果を本質的に変更するものではなく、実質上特許請求の範囲を拡張又は変更するものではない。
　
（４）訂正事項ｄ
（訂正の目的）
　訂正事項ｄ−１：
　訂正前の請求項９、１１、１３、１４を削除する訂正は、特許請求の範囲の減縮を行うものである。
　
　訂正事項ｄ−２：
　　「【請求項９】　特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段は、構文解析結果をもとにプログラミング言語記述のへッダーコメントに記述されたインターフェース仕様を抽出するインターフェース仕様抽出手段と、構文解析結果をもとに上記プログラミング言語記述のモジュールの定義・参照を木構造に変換して記憶するモジュール定義・参照抽出手段と、ヘッダーコメント中のモジュール欄の名称が実際のモジュール名に一致しているかを照合するモジュール名照合手段と、上記インターフェース仕様及び上記木構造をもとにプログラミング言語記述に対応したモジュール仕様書を生成するモジュール仕様生成手段とを有することを特徴とするプログラム生産支援装置。
　【請求項１０】　特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段は、構文解析結果をもとにシンボルの定義情報を記憶するシンボル定義抽出手段と、上記シンボルの定義情報をシンボルが定義された順に並び換えるシンボル定義並び換え手段と、上記シンボルの定義情報をもとにプログラミング言語記述に対応したシンボル一覧表を生成するシンボル一覧表生成手段とを有することを特徴とするプログラム生産支援装置。」とする訂正は、訂正前の請求項７を引用する特許請求の範囲の訂正前の請求項１０、１２を独立形式として、項数を繰り上げて記載したものであるから、明りょうでない記載の釈明を行う訂正である。　
　
　訂正事項ｄ−３：
・明細書の段落番号【００１３】、同段落番号【００１５】、同段落番号【００１７】、同段落番号【００１８】、同段落番号【００２５】、同段落番号【００２７】、同段落番号【００２９】、同段落番号【００３０】、同段落番号【０１６６】、同段落番号【０１６８】、同段落番号【０１７０】、同段落番号【０１７１】の全ての記載をそれぞれ削除し、
・同段落番号【００１４】第１行目、同段落番号【０１６７】第１行目の「また、生成手段が、」を「また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、」と、
・同段落番号【００１４】第８行目の「有するようにしてもよい。」を「有するものである。」と、同段落番号【０１６７】第８行目の「有する場合には、」を「有しているので、」と、
・同段落番号【００１６】第１行目、同段落番号【０１６９】第１行目の「また、生成手段が、」を「また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、」と、
・同段落番号【００１６】第５行目の「有するようにしてもよい。」を「有するものである。」と、
・同段落番号【０１６９】第５行目の「有する場合には、」を「有しているので、」と、
する訂正は、いずれも、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図り、明りようでない記載の釈明を目的として行う訂正である。
　
（新規事項の有無）
　また、前記ｄ−１〜３に示した訂正内容は、いずれも 願書に添付した明細書又は図面の記載から明白に読み取れることである。
　
（拡張・変更の存否）
　前記ｄ−１〜３の訂正は、願書に添付した明細書に記載した発明が解決しようとする課題ないし発明の効果を本質的に変更するものではなく、実質上特許請求の範囲を拡張又は変更するものではない。
　
５．まとめ
　前記１．〜４．のとおり、訂正事項ａないしｄの訂正は、特許法第120条の4第3項において準用する特許法等の一部を改正する法律（平成6年法律第116号）附則第6条第1項の規定によりなお従前の例によるとされる特許法第126条第1項ただし書，第2項及び第3項の規定に適合するものである。
　
　よって、前記補正された平成15年8月26日付けの訂正を認める。
　
　
第３　取消理由について
１．本件の請求項に係る発明
（１）請求項１に係る発明
　前記第２に認定したとおり訂正が認められることから、本件の請求項１に係る特許発明（以下、特許発明１という。）は、訂正された明細書の特許請求の範囲の請求項１に記載されたとおりの次の事項により特定されるものである。
　
「自然言語と各機能の階層構造を示す記号とで記述された仕様記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された仕様記述の構文解析を行う構文解析手段と、構文解析結果をもとに各機能の階層構造を抽出する階層構造抽出手段と、上記抽出された階層構造をもとに上記仕様記述に対応した図または自然言語及びプログラミング言語に準じた制御構造で記述された疑似言語記述を生成する生成手段とを有することを特徴とするプログラム生産支援装置。」
　
（２）請求項２に係る発明
　同じく、本件の請求項２に係る特許発明（以下、特許発明２という。）は、訂正された明細書の特許請求の範囲の請求項２に記載されたとおりの次の事項により特定されるものである。
　
「仕様記述には、種別を示す記号が記述されており、
　生成手段は、上記種別に従って、ディレクトリ、ファイル、またはモジュールの少なくとも１つを生成することを特徴とする請求項１記載のプログラム生産支援装置。」
　
（３）請求項３に係る発明
　同じく、本件の請求項３に係る特許発明（以下、特許発明３という。）は、訂正された明細書の特許請求の範囲の請求項３に記載されたとおりの次の事項により特定されるものである。
　
「自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有することを特徴とするプログラム生産支援装置。」
　
（４）請求項４に係る発明
　同じく、本件の請求項４に係る発明（以下、特許発明４という。）は、訂正された明細書の特許請求の範囲の請求項４に記載されたとおりの次の事項により特定されるものである。
　
「自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、
　上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、
　上記生成手段は、構文解析結果をもとに上記仕様記述部に記述されたインターフェース仕様を抽出するインターエース仕様抽出手段と、上記構文解析結果をもとに上記ロジック記述部に記述されたモジュールの定義・参照を抽出するモジュール定義・参照抽出手段と、上記抽出されたインターフェース仕様及びモジュールの定義・参照をもとに上記疑似言語記述に対応したデザインレビュー用資料を生成するデザインレビュー用資料生成手段とを有することを特徴とするプログラム生産支援装置。」
　
（５）請求項５に係る発明
　同じく、本件の請求項５に係る特許発明（以下、特許発明５という。）は、訂正された明細書の特許請求の範囲の請求項５に記載されたとおりの次の事項により特定されるものである。
　
「生成手段は、構文解析結果をもとに自然言語で記述されている処理説明および制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語記述に対応した木構造チャートを生成する木構造チャート生成手段とを有することを特徴とする請求項３記載のプログラム生産支援装置。」
　
（６）請求項６に係る発明
　同じく、本件の請求項６に係る特許発明（以下、特許発明６という。）は、訂正された明細書の特許請求の範囲の請求項６に記載されたとおりの次の事項により特定されるものである。
　
「生成手段は、構文解析結果をもとに自然言語で記述されている処理説明及び制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語の制御構造をそれに対応するプログラミング言語の制御構造に変換する制御構造変換手段と、上記変換された木構造をもとに疑似言語の処理説明をプログラミング言語のコメントに変換する手段とを有することを特徴とする請求項３記載のプログラム生産支援装置。」
　
（７）請求項７に係る発明
　同じく、本件の請求項７に係る発明（以下、特許発明７という。）は、訂正された明細書の特許請求の範囲の請求項７に記載されたとおりの次の事項により特定されるものである。
　
「特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述を生成する生成手段とを有することを特徴とするプログラム生産支援装置。」
　
（８）請求項８に係る発明
　同じく、本件の請求項８に係る発明（以下、特許発明８）は、訂正された明細書の特許請求の範囲の請求項８に記載されたとおりの次の事項により特定されるものである。
　
「プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有するものであって、
　生成手段が、構文解析結果をもとにプログラムの制御構造及びそれに付随するコメントを抽出する制御構造抽出手段と、上記制御構造をもとにプログラミング言語の制御構造を自然言語及び上記プログラミング言語に準じた制御構造で記述された疑似言語の制御構造に変換する制御構造変換手段と、上記制御構造をもとに上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段とを有することを特徴とする請求項７記載のプログラム生産支援装置。」
　
（９）請求項９に係る発明
　同じく、本件の請求項９に係る特許発明（以下、特許発明９という。）は、訂正された明細書の特許請求の範囲の請求項９に記載されたとおりの次の事項により特定されるものである。
　
「特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、
　上記生成手段は、構文解析結果をもとにプログラミング言語記述のへッダーコメントに記述されたインターフェース仕様を抽出するインターフェース仕様抽出手段と、構文解析結果をもとに上記プログラミング言語記述のモジュールの定義・参照を木構造に変換して記憶するモジュール定義・参照抽出手段と、ヘッダーコメント中のモジュール欄の名称が実際のモジュール名に一致しているかを照合するモジュール名照合手段と、上記インターフェース仕様及び上記木構造をもとにプログラミング言語記述に対応したモジュール仕様書を生成するモジュール仕様生成手段とを有することを特徴とするプログラム生産支援装置。」
　
（１０）請求項１０に係る発明
　同じく、本件の請求項１０に係る特許発明（以下、特許発明１０という。）は、訂正された明細書の特許請求の範囲の請求項１０に記載されたとおりの次の事項により特定されるものである。
　
「 特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、
　上記生成手段は、構文解析結果をもとにシンボルの定義情報を記憶するシンボル定義抽出手段と、上記シンボルの定義情報をシンボルが定義された順に並び換えるシンボル定義並び換え手段と、上記シンボルの定義情報をもとにプログラミング言語記述に対応したシンボル一覧表を生成するシンボル一覧表生成手段とを有することを特徴とするプログラム生産支援装置。」
 　
２．平成15年6月16日付の取消理由通知書で通知した取消理由
　前記取消理由通知書によって、次のア）ないしウ）の取消理由を通知した。
ア）　平成14年1月29日付で訂正された特許請求の範囲の請求項１に係る特許発明は、特許法第36条第4項の規定に違反してされたものである。
イ）　同特許請求の範囲の請求項１の記載は、特許法第36条第5項及び第6項の規定に違反するものである。
ウ）　同特許請求の範囲の請求項１，３，５ないし８に係る特許発明は、特許法第29条第2項の規定に違反してされたものである。
　
　なお、現特許発明１，３，５ないし８は、同特許請求の範囲１，３，５ないし８に係る特許発明に対応するものであり、また、前記取消理由でそれぞれの特許発明に引用した刊行物も同じものである。
　
３．取消理由の有無の検討
　異議申立のない請求項２，４，９，１０に対する前記訂正は、従属形式で記載されたそれらの請求項を、明りょうでない記載の釈明を目的として、独立形式とするためのものであり、いわゆる独立特許要件の検討は要さない。したがって、異議申立のされた特許発明である、特許発明１，３，５ないし８について前記２．の取消理由の有無を検討する。
　
３．１　特許法第36条第4項違反についての検討
　特許発明１は、仕様記述を読み込み、階層構造を抽出し、上記抽出された階層構造をもとに上記仕様記述に対応した図または自然言語及びプログラミング言語に準じた制御構造で記述された疑似言語記述を生成する旨のものである。
　しかし、本件明細書の発明の詳細な説明には、仕様記述１０１から疑似言語記述のひな型１３０１を生成する方法が実施例２として記載されているが、仕様記述１０１から疑似言語記述３０１を生成する実施例は記載されていない（前記実施例２は、仕様記述を読み込んで、プログラムを実現するのに必要なディレクトリ、ファイル、およびモジュールを含む疑似言語記述のひな型を自動生成するものであるが（【００４１】〜【００５１】等参照）、前記疑似言語記述のひな型には、例えば、疑似言語が備えるモジュールのインターフェース仕様（【００５３】〜【００５５】，図１４等参照）などが含まれておらず、また、それらが含まれていることを、本件明細書の発明の詳細な説明から読み取ることもできない。さらに、前記実施例２は、前工程の設計情報（機能構成）を後工程に忠実に伝えるものである（【００５１】）から、機能構成には関係のない、例えば、前記モジュールのインタフェース仕様まで自動生成することは念頭におかれていないものと解される。）。
　
　すなわち、本件明細書の（各実施例の）記載及び図面（例えば図８０）を参照しても、仕様記述から疑似言語記述を生成するようなものを読み取ることはできない。
　
　したがって、本件特許明細書の発明の詳細な説明の記載は、当業者が特許発明１を容易に実施できる程度に記載されたものではなく、特許法第36条第4項の規定に違反するものである。
　
３．２　特許法第36条第5項及び6項違反についての検討
　特許発明１は、前記２．１で述べたように、本件明細書の発明の詳細な説明に記載したものではないから、特許法第36条第6項第1号の規定を満たしていない。
　したがって、前記請求項１の記載は、特許法第36条第5項及び第6項の規定に違反してされたものである。
　
３．３　特許法第29条第2項違反についての検討
（１）引用刊行物一覧
　刊行物１．特開平２−５９８１８号公報
　刊行物２．「ＮＣＯＳソフトウェア　ＮＣＯＳ１　ＮＣＯＳ１／ＡＦ　ソフトウェア開発支援システム説明書」，昭和６２年８月，初版，日本電気株式会社
　刊行物３．「ＯＳ　ＩＶ　ＹＰＳ／ＣＯＢＯＬ８５　ジェネレータ使用手引書　Ｖ１０Ｌ１１用」，平成３年６月，第２版，富士通株式会社
　（審決注：平成15年6月16日付の取消理由通知書において刊行物名が「ＯＳ　ＩＶ　ＹＰＳ／ＣＯＢＯＬ８５　使用手引書　Ｖ１０Ｌ１１系用」となっていたのを上記のとおり訂正。）
　刊行物４．「ＦＭシリーズ　ＦＭ　ＹＰＳエディタ　Ｖ１．１使用手引書」，平成元年12月，富士通株式会社
　
（２）刊行物に記載の発明
［刊行物１］　
　刊行物１には、次のとおり記載されている。
(a).「従来からソフトウェアの設計にはフローチャート等が主に使われているが、近年、理解性および視認性の観点から木構造図が注目を浴びている。
　主な木構造図としてはＴＦＦ，ＨＣＰ，ＰＡＤ等が知られており、これらによる木構造図をＣＲＴディスプレイ上で編集する木構造図エディタも開発されている。
　ところで、木構造図は、一般に処理の種類および流れを表現するシンボルと、処理の内容を表現するテキストとの２種類の情報から構成されている。
　したがってディスプレイ上で木構造図の編集または表示を行なおうとすると、シンボルをグラフィックスで表現しておく必要があるが、グラフィックスは計算機やオペレーティングシステム（ＯＳ）等に依存する処理が相当多いので、グラフィックスを利用した木構造図エディタは、利用できる計算機が限定される。」（第1頁右下段第4行〜第20行）
　
(b).「（発明が解決しようとする課題）
　このように従来の木構造図作成システムは、グラフィックスを利用しているので、利用できる計算機が限定されるという問題があった。
　本発明はこのような事情によりなされたもので、利用できる計算機が限定されず、キャラクタベースの端末からでも利用することができる木構造図簡易作成システムの提供を目的としている。」（第2頁左上段第1行〜第8行）
　
(c).「（作用）
　本発明の木構造図簡易作成システムによれば、専用の木構造図エディタを使わないで、テキストエディタによりプログラムモジュールの木構造図情報を簡単に入力することができる。また記述法ごとにシンボルテーブルを作成するので、各種の木構造図を簡易に作成することができる。」（第2頁右上段第4行〜第10行）
　
(d).「（イ）テキスト情報の入力
　利用者は入力装置２からテキストエディタ１３を利用してテキスト情報を入力する。
　処理の流れを示すシンボルは第２図に示したように、その意味を表すキーワードで記述する。そして各シンボルとその意味を表すキーワードとの対応はシンボルテーブルで保持している。また入力されたテキスト情報は外部記憶装置５に保存する。
　　　（ロ）テキスト情報解釈
　外部記憶装置５に保存されているテキスト情報は木構造図生成部１０により解釈されて第３図に示したような木構造図に変換される。この変換はシンボルテーブルを参照して行なわれる。」（公報第2頁右下段第5行〜第18行）
　
(e).「本実施例のシステムによれば、処理の流れを表す木構造図を作成するのに専用の木構造図エディタを利用しなくてもテキストエディタからデータを容易に入力することができる。
　　　したがって、木構造図の専用エディタがない計算機でも使用することができ、専用エディタの操作方法を知らなくても容易に木構造図を生成することができる。」（第3頁左上段第15行〜同頁右上段第2行）
　
　そして、
　ア）　引用記載(a)〜(e)に記載の木構造図は、引用記載(a)によれば、ソフトウェアの設計に用いるものなので、引用記載(b)の木構造図簡易作成システムは、プログラム生産支援装置の一つである。
　
　イ）　引用記載(c)及び第２図によると、「処理の内容を表現するテキスト」の「テキスト」は、自然言語である。
　
したがって、刊行物１には、
　
　木構造図の専用エディタがない計算機でも使用することができ、専用エディタの操作方法を知らなくても容易に木構造図を生成するプログラム生産支援装置であって、
　木構造図は、一般に処理の種類および流れを表現するシンボルと、処理の内容を表現するテキストとの２種類の情報から構成されており、
　前記処理の流れを表現するシンボルを、その意味を表すキーワードと対応付けて保持するシンボルテーブルと、
　前記シンボルを、その意味を表す前記キーワードで記述することにより、前記処理の流れを表現するシンボルと、処理の内容を表現する自然言語のテキストとを、テキストエディタを利用してテキスト情報として入力可能とし、
　前記テキストエディタで入力されたテキスト情報を、前記シンボルテーブルを参照つつ解釈して、前記処理の流れを表現するシンボルと処理の内容を表現する自然言語のテキストとを、木構造図に変換することを特徴とするプログラム生産支援装置。
　
が記載されている（以下、引用発明１という）。
　
［刊行物２］　
　刊行物２には、次のとおり記載されている。
(a).「プログラム開発支援では、プログラムの生産性を支援するために、次のツールを用意している。
　　　・ＦＯＲＴＲＡＮ／Ｓ
　　　・ＣＯＢＯＬ／Ｓ
　　　・画面エディタ
　　　(1)　ＦＯＲＴＲＡＮ／Ｓ
　ＦＯＲＴＲＡＮ／Ｓは、ＦＯＲＴＲＡＮ言語に疑似言語を導入して、構造的プログラミングの思想を取り入れたプログラミングツールであり、既存のＦＯＲＴＲＡＮ言語プロセッサの前段に位置するプリプロセッサという形で提供される。」（第3頁第9行〜第17行）
　
(b).「２．３．１　機能と特徴
　　　ＦＯＲＴＲＡＮ／Ｓ言語の機能は、
　　　・表現機能
　　　・操作機能
の二つに分けて概括することができ、以下はすべてＦＯＲＴＲＡＮ言語とは異なる付加された機能とその特徴について述べる。
　　　(1)　表現機能
　　　　　表現機能とは、ＦＯＲＴＲＡＮ／Ｓ言語のうち、プログラムの記述に関するものであり、特記すべきは次のものである。
　　　　　(a)　プログラムの構造的論理化機能
　　　　　　　現在のＦＯＲＴＲＡＮ言語で最も表現能力が不十分な仕様は、プログラムの構造的論理化を明確にすることができない点である。これらを解決するために、ＦＯＲＴＲＡＮ／Ｓ言語では構造的プログラミングの基本概念である、
　　　　　　　(i)　一入口（トップ）、一出口（ボトム）
　　　　　　　(ii)　順次構造
　　　　　　　(iii)　選択構造
　　　　　　　(iv)　繰り返し構造
を完全に実現している。この結果プログラムは、ＡＬＧＯＬ、ＰＬ／Ｉのような構造的論理化が可能である。」（第7頁第2行〜20行）
　
(c).「(3)　画面エディタ
　　　　　画面エディタは、画面型端末を用い、テキストファイルの生成、編集および保存処理を、端末特性を生かし確実かつ迅速に行うツールである。」（第6頁第1行〜第3行）
　
(d).「(b)　ＦＯＲＴＲＡＮ／Ｓ言語の構文解析機能
　　　　　コンピュータ上で稼働可能なオブジェクトプログラムは、ＦＯＲＴＲＡＮ／Ｓ言語プリプロセッサ、ＦＯＲＴＲＡＮ言語プロセッサを経由して作られるから、正しいオブジェクトプログラムを得るための構文解析は、最も操作上問題となる点である。それらは、次のように処理される。
　　　　　(1)　プリプロセッサ、プロセッサの構文解析
　　　　　　　ＦＯＲＴＲＡＮ／Ｓ言語で記述されたソース入力プログラムは、まずプリプロセッサの構文解析部によってＦＯＲＴＲＡＮ／Ｓ言語として付加された機能に関するもののみのチェックが行われ、必要であれば引き続きＦＯＲＴＲＡＮ言語プロセッサによってＦＯＲＴＲＡＮ言語本体の構文解析が行われる。」（第9頁第18行〜28行）
　
(e).「２．５．４　日本語データの編集処理
　画面エディタ起動時、日本語モードを選択すると、日本語データ（日本語文字または漢字文字）と英数カナ文字データ（ＡＮＫ文字）を同時に扱うことができる。」(第20頁第20行〜22行)
　
と記載されている。ここで、
　ア）　引用記載(a)，(c)，(e)及び図2-1（第4頁），図2-3（第6頁）および表2-1（第11,12頁）とを参照すると、ＦＯＲＴＲＡＮ／Ｓは、テキストで表現される疑似言語であるから、ＦＯＲＴＲＡＮ／Ｓは、自然言語とプログラミング言語に準じた制御構造とがテキストで記述された疑似言語記述である。
　
　イ）　前記疑似言語は、表2-1の注釈記述文を用いて、注釈を入力することができるものである。
　
　ウ）　引用記載(c)によると、エディタは画面上でテキストを編集するテキストエディタである。
　
　エ）　図2-1,2-3に記載のものは、プログラム生産支援装置である。
　
したがって、上記刊行物２には、
　
　自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、テキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応したプログラミング言語記述を生成する生成手段を有するプログラム生産支援装置であって、
　前記疑似言語記述には、注釈記述文によって、自然言語で注釈を記述することができるプログラム生産支援装置。
　
が記載されている（以下、引用発明２という。）。
　
［刊行物３］
　刊行物３には、次のとおり記載されている。
(a).「ＹＰＳ／ＣＯＢＯＬ８５ジェネレータは，ＣＯＢＯＬ８５原始プログラムを入力とし，ＹＰＳプログラム仕様書を出力します．
　出力されるＹＰＳプログラム仕様書は，以下のような形で表現されます．
　−　制御線を含む図記号
　−　標準変換構文で定めるＣＯＢＯＬ８５の文の日本語表現
　−　利用者が定義した変換構文によるＣＯＢＯＬ８５の文の日本語表現
　−　日本語項目変換辞書による文字列の日本語化
　図記号については，“表２．１　ＣＯＢＯＬ８５からＹＰＳ／ＣＯＢＯＬ８５への変換規則”にしたがって変換されます．」（第2頁第2行〜10行）
　
(b).「コメント行／デバッグ行
・デバッグ行はコメント行として変換されます．ＣＯＢＯＬ８５原始プログラム中にデバッグ行がある場合，デバッグ行はコメント行としてＹＰＳプログラム仕様書に出力され，
“ＪＰＢ００９７１−Ｗ　デバッグ行が存在します．”とメッセージが出力されます．変換例は“表２．１　ＣＯＢＯＬ８５からＹＰＳ／ＣＯＢＯＬ８５への変換規則”を参照して下さい．
　利用者は，そのデバッグ行が必要かどうかを確認し，必要な場合には，７カラム目のＤを空白に変更後，ＹＰＳ／ＣＯＢＯＬ８５ジェネレータで変換してください．
・“☆”は，ＹＰＳ／ＣＯＢＯＬ８５で予約語となっています．よって，
ＹＰＳ／ＣＯＢＯＬ８５ジェネレータの変換の対象となるＣＯＢＯＬ８５原始プログラム中に，“☆”，または“☆”のコードを，利用者は記述できません．
・標識領域の“／”（斜線）は，“◎”（改ページ図記号）に変換されます．注記行のＡ領域とＢ領域に文字が記述されている場合は，次行の☆印の後に文字が出力されます．標識領域の斜線の変換例を図２．８に示します．
・１文の途中に注記行を記述した場合，その注記行は，記述された文の終止符の次の行に出力されます．文の途中に注記行を記述した場合の変換の例を図２．９に示します．」（第23頁第12行〜第24頁第2行）
　
(c).　「ＪＰＢ００１１Ｉ−Ｓ
　　　ＣＯＢＯＬ８５原始プログラムの構成に誤りがあります。
　　［メッセージの意味］
　　　ＣＯＢＯＬ８５原始プログラムの構成に必要な部、節などの構成要素が存在しません。」（第70頁第41行〜44行）
　
(d).「ＪＰＢ００９１Ｉ−Ｗ
　　　ＣＯＢＯＬで使用できない文字ｘｘｘｘｘｘが存在します。
　　［メッセージの意味］
　　　ＣＯＢＯＬで使用できない文字が存在します。」（第80頁第31行〜34行）
　
　ここで、
ア）　引用記載(a)および表2.1（第5頁）によると、ＹＰＳ／ＣＯＢＯＬ８５ジェネレータは、ＣＯＢＯＬ８５原始プログラムを入力とし、制御線を含む図記号、標準変換構文で定めるＣＯＢＯＬ８５の文の日本語表現、利用者が定義した変換構文によるＣＯＢＯＬ８５の文の日本語表現、日本語項目変換辞書による文字列の日本語化の形で表現される、ＹＰＳプログラム仕様書を出力するものである。
　
イ）　引用記載(c),(d)によると、引用発明３は、入力されたＣＯＢＯＬ８５原始プログラムに対して構文解析を行なうものである。
　
ウ）　前記イ）の構文解析結果をもとに抽出される、ＹＰＳプログラム仕様書を構成する、制御線を含む図記号、標準変換構文で定めるＣＯＢＯＬ８５の文の日本語表現、利用者が定義した変換構文によるＣＯＢＯＬ８５の文の日本語表現、日本語項目変換辞書による文字列は、ＣＯＢＯＬ８５原始プログラムの制御構造を表すものである。
　
エ）　引用記載(b)及び、表2.1そして図2.8（第24頁）及び図2.9（第24頁）を参照すると、自然言語で対応するプログラム言語を説明する注記行は、抽出・変換されて前記対応するプログラム言語の制御構造に付随する処理説明として出力されている。
　
オ）　引用記載(a)〜(d)によると、ＹＰＳ／ＣＯＢＯＬ８５ジェネレータは、プログラム生産支援装置の一つといえる。
　
　したがって、刊行物３には、
　
　ＣＯＢＯＬ８５原始プログラムを入力として構文解析を行って、当該構文解析の結果をもとに、入力されたＣＯＢＯＬ８５原始プログラムから抽出した制御構造等で表現されるＹＰＳプログラム仕様書を出力するプログラム生産支援装置において、
　入力したＣＯＢＯＬ８５原始プログラムを自然言語で説明する注記行を抽出・変換し、当該抽出した自然言語を、当該注釈が対応するプログラムの制御構造に付随する処理説明として、ＹＰＳプログラム仕様書に含めて出力することを特徴とするプログラム生産支援装置。
　
が記載されている（以下、引用発明３という。）。
　
（３）本件特許発明と刊行物に記載の発明との対比・検討
＜特許発明１＞
　特許発明１と引用発明１とを対比・検討する。
　
　引用発明１について、
　ア）　引用発明１の木構造図を構成する「処理の種類及び流れを表現するシンボル」について、前記「処理の種類」及び「処理の流れ」は、それぞれ、処理の機能及び階層構造を含む繋がり、を示しているものと解される。
　
　イ）　引用発明１のテキスト情報の解釈は、技術常識からして、構文解析により行われるものである。
　
　ウ）　引用発明１の前記構文解析により階層構造情報を含んだ木構造図を生成しているのであるから、前記構文解析においては、各機能の階層構造を抽出している。
　
したがって、特許発明１と刊行物１に記載の発明とは、
　
［一致点］
　自然言語と各機能の階層構造を示す記号とで記述されたテキスト情報を読み込み、前記テキスト情報の構文解析を行う手段と、
　構文解析結果をもとに各機能の階層構造を抽出する手段と、
　上記抽出された階層構造をもとに上記テキスト情報に対応した図を生成する生成手段を有することを特徴とするプログラム生産支援装置。
　
である点で一致し、
　
［相違点］
（相違点１）
　読み込む情報が、特許発明１は仕様記述であるのに対して、引用発明１はテキスト情報である点。
　
（相違点２）
　疑似言語記述を読み込みんだ後の解析処理が、
　特許発明１は、その内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段で行われるが、
　刊行物２に記載の発明は、その内容の構文解析を行う構文解析手段で行われる点。
　
で相違している。
  　
［相違点の検討］
（相違点１について）
　特許発明１の仕様記述は自然言語と各機能の階層構造を示すものであるが、引用発明１のテキスト情報も、自然言語と機能の階層構造情報を含む情報であるから、前記相違点１は実質的な差異にはあたらない。
　
（相違点２について）
　構文解析は、字句解析を行った後に行うのが技術常識であるから、引用発明２の構文解析においても、構文解析に先立ち字句解析が行われているとみるのが自然であり、合理的である。したがって、前記相違点２は、実質的な差異にはあたらない。
　
　よって、特許発明１は、引用発明１に基づいて当業者が容易に発明をすることができたものである。
　
　なお、特許権者は、特許発明１の仕様記述は、書籍の目次に準じた形式のものである点で引用発明１と相違する旨主張しているが、前記特許権者が相違点と主張する事項を加える訂正はすでに削除されているから、特許権者の前記主張は検討を要しない。
　
　
＜特許発明３＞
　特許発明３と引用発明２とを対比・検討すると、両者は、
　
［一致点］
　自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、テキストエディタを用いて入力及び編集可能な疑似言語記述を読み込み、その内容の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応したプログラミング言語記述を生成する生成手段を有するプログラム生産支援装置。
　
である点で一致し、
　
［相違点］
（相違点１）
　テキストエディタが、特許発明３では汎用のものであるのに対し、引用発明２では汎用のものとは明記されていない点。
　
（相違点２）
　疑似言語記述を読み込みんだ後の解析処理が、
　請求項３に係る発明は、その内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段で行われるが、
　刊行物２に記載の発明は、その内容の構文解析を行う構文解析手段で行われる点。
　
で相違している。
　
［相違点の検討］
（相違点１について）
　引用発明２のテキストエディタは、テキストを入力・編集できればいいものであることは明らかであるから、引用発明２のテキストエディタを、汎用のテキストエディタとすることに困難性は認められない。
　したがって、相違点１は、格別のものではない。
　
（相違点２について）
　構文解析を行う際に、字句解析が伴うことは技術常識であるから、引用発明２に記載のものでも、字句解析が行われているものと解される。
　したがって、相違点２は、格別のものではない。
　
　よって、特許発明３は、引用発明１に基づいて当業者が容易に発明をすることができたものである。
　
　
＜特許発明５＞
　請求項５は、請求項３の引用形式で記載されているから、＜特許発明３＞の検討に引き続いて、特許発明５と、引用発明２とを対比・検討する。
　
　引用発明２は、自然言語とプログラミング言語に準じた制御構造とがテキストで記述された疑似言語からプログラミング言語記述を生成するもので、自然言語は処理説明に用いるものであることは技術常識である。したがって、引用発明２においては、プログラミング言語記述を生成する際に、自然言語で記述されている処理説明及び制御構造を抽出しているものと解される。
　
　したがって、両者は、
［一致点］
　自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、テキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容の構文解析を行う構文解析手段と、構文解析結果をもとに自然言語で記述されている処理説明および制御構造を抽出する手段を有するプログラム生産支援装置。
　
である点で一致し、
　
［相違点］
（相違点１）
　テキストエディタが、特許発明６は汎用のものであるのに対し、引用発明２は汎用のものとは明記されていない点。
　
（相違点２）
　抽出した処理説明および制御構造について、
　特許発明５は、木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語記述に対応した木構造チャートを生成する木構造チャート生成手段を備えるのに対して、
　引用発明２は、プログラム言語記述に変換するものである点で相違している。
　
［相違点の検討］
（相違点１について）
　前記＜特許発明３＞で相違点１について検討したのと同じく、格別のものではない。
　
（相違点２について）
　プログラムを木構造図に変換することは周知である（例えば、下に示す周知例１，２参照）から、引用発明２において、疑似言語をプログラム言語記述に変換していたものを、木構造図に変換して出力するようにし、特許発明３の如く構成することに困難性は認めらない。なお、その処理過程で、木構造の制御構造を記憶することは適宜為し得る事項に過ぎない。
　
　よって、特許発明５は、引用発明２及び前記周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
　周知例１：　特開昭６０−１００２２６号公報
　周知例２：　特開平４−２４７３３号公報
　
＜特許発明６＞  
　請求項６は請求項３の引用形式で記載されているから、前記＜特許発明３＞での検討に引き続いて、特許発明６と、引用発明２とを対比する。
　
　引用発明２の注釈は、処理説明に相当するものである。
　したがって、両者は、
［一致点］
　自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、テキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容の構文解析を行う構文解析手段と、
　構文解析結果をもとに自然言語で記述されている処理説明及び制御構造を得るもので、前記処理説明及び制御構造から疑似言語の処理説明をプログラミング言語のコメントに変換する手段を有する点。
　
で一致し、
　
［相違点］
（相違点１）
　テキストエディタが、特許発明６は汎用のものであるのに対し、引用発明２は汎用のものとは明記されていない点。
　
（相違点２）
　疑似言語の処理説明をプログラミング言語のコメントに変換する過程において、
　特許発明６は、自然言語で記述されている処理説明及び制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語の制御構造をそれに対応するプログラミング言語の制御構造に変換する制御構造変換手段を備えているが、
　引用発明２は、どのような処理を行う手段を有するのか、明記されていない点。
　
で相違している。
　
［相違点の検討］
（相違点１について）
　前記＜特許発明３＞で（相違点１）について検討したのと同じく、相違点１は格別のものではない。
　
（相違点２について）
　プログラム等の制御構造を表現する形式として、木構造の形式は周知であるから、引用発明２において、制御構造を木構造に変換して記憶しておき、木構造の制御構造をもとにプログラミング言語の制御構造を得るように為し、相違点２の如く構成することに困難性はない。
　
　したがって、特許発明６は、引用発明２及び前記周知技術に基づいて、当業者が容易に発明をすることができたものである。
　
＜特許発明７＞
　特許発明７と、引用発明３とを対比する。
　
　引用発明３において、ＣＯＢＯＬ８５原始プログラムを入力とすることは、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込むことでもあるから、両者は、
　
［一致点］
　特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込み、プログラミング言語記述の構文解析を行う構文解析手段を備え、構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とが記述された情報を生成するプログラム生産支援装置。
　
である点で一致し、
　
［相違点］
（相違点１）
　構文解析手段の前に、特許発明７が、プログラミング言語記述を読み込みその内容を字句に分解する字句解析手段を備えるのに対して、
　引用発明３では、そのような手段は明記されていない点、
　
（相違点２）
　生成される情報が、特許発明７では、疑似言語記述であり、当該疑似言語は、自然言語と制御構造とがテキストで記述されたものであるのに対して、引用発明３では、ＹＳＰプログラム仕様書であり、当該ＹＳＰプログラム仕様書は、自然言語はテキストであるが、制御構造は図記号を含んで記述されるものである点。
　
で相違している。
　
［相違点の検討］
（相違点１について）
　構文解析は、字句解析を伴うのが技術常識であるから、相違点１は格別のものではない。
　
（相違点２について）
　プログラムの論理をわかりやすく表すために、引用発明３においては木構造図の一種であるＹＰＳプログラム仕様書が、特許発明７においては疑似言語記述が、用いられている。また、プログラムの論理を表現するものとして、疑似言語と木構造図を含む図形表現が等価であることは周知である（必要であれば周知例３参照。）。
　したがって、引用発明３において、ＹＰＳプログラム仕様書に代えて、疑似言語記述を採用し、相違点２の如く構成することに困難性はない。
　
　周知例３：　情報処理ハンドブック，株式会社オーム社発行，第１版第１刷，第986〜988頁，1989年5月30日発行
　
　よって、いずれの相違点も格別のものではなく、特許発明７は当業者が引用発明３及び周知技術に基づいて容易に発明をすることができたものである。
　
＜特許発明８＞
 請求項８は請求項７の引用形式で記載されているから、前記＜特許発明７＞での検討に引き続きいて、特許発明８と引用発明３とを対比すると、両者は、
　
［一致点］
　プログラミング言語は、コメントを有するものであって、
　プログラムの論理を表す情報の生成手段が、構文解析結果をもとにプログラムの制御構造及びそれに付随するコメントを抽出する手段と、
　上記制御構造をもとにプログラミング言語の制御構造を自然言語及び上記プログラミング言語に準じた制御構造で記述された前記プログラムの論理を表す情報の制御構造に変換する手段と、
　上記制御構造をもとに上記プログラミング言語のコメントを前記情報の自然言語で記述された処理説明に変換する手段と、
を有することを特徴とするプログラム生産支援装置。
　
である点で一致し、
　
［相違点］
（相違点１）
　特許発明８では、プログラミング言語のモジュール内のコメントを処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換するが、
　引用発明３では、コメントを処理説明に変換する際の様々な場合を個別に詳説していない点。
　
（相違点２）
　生成手段が生成するプログラムの論理を表す情報が、特許発明８のものは、疑似言語であるのに対して、引用発明３のものは、ＹＳＰプログラム仕様書である点。
　
　で相違する。
　
［相違点の検討］
（相違点１について）
　プログラミング言語のなかに、モジュール、条件文、条件文中の条件式を備え、プログラム中に適宜コメントを記載できるものがあることは周知（必要であれば、周知例４参照）である。
　したがって、引用発明３に記載のものにおいて、処理説明に変換するコメントを、条件文中の条件式に対するコメント、モジュール内のコメントとして、前記相違点１の如く構成することに困難性はない。なお、条件文の条件式を処理説明で置き換えることも適宜為し得る事項に過ぎない。
　
　周知例４：特開昭６２−１４５４２４号公報
　
（相違点２について）
　前記＜特許発明７＞の［相違点の検討］（相違点２について）で述べたのと同様、格別のものではない。
　
　よって、いずれの相違点も格別のものではなく、特許発明８は、当業者が引用発明３及び周知技術に基づいて容易に発明をすることができたものである。
　
　
第４　むすび
　本件明細書の特許請求の範囲の請求項１に記載の発明の特許は、前記第３の２．１で述べた点で、特許法第36条第4項の規定に違反してされたものである。
　また、本件明細書の特許請求の範囲の請求項１の記載は、前記第３の２．２で述べた点で、特許法第36条第5項及び6項の規定に違反してされたものである。
　さらに、請求項１，３，５ないし８に係る発明の特許は、前記２．３で検討したとおり、特許法第29条2項の規定に違反してされたものである。
　以上のとおり、請求項１に係る発明の特許は特許法第１１３条第１項第２号及び第４号に該当し、請求項３，５ないし８に係る発明の特許は特許法第１１３条第１項第２号に該当するから、取り消されるべきものである。
　
　よって、結論のとおり審決する。
【異議決定日】
平成１６年１月１５日（２００４．１．１５）
【訂正の要旨】
審決（決定）の【理由】欄参照。
（５４）【発明の名称】
プログラム生産支援装置
（５７）【特許請求の範囲】
　【請求項１】　自然言語と各機能の階層構造を示す記号
とで
た仕
述を
　【請求項２】　
仕
　
生
る請求項１記載のプ
　【請求項３】　自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有することを特徴とするプログラム生産支援装置。
　【請求項４】　自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、
　上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、
　上記生成手段は、構文解析結果をもとに上記仕様記述部に記述されたインターフェース仕様を抽出するインターエース仕様抽出手段と、上記構文解析結果をもとに上記ロジック記述部に記述されたモジュールの定義・参照を抽出するモジュール定義・参照抽出手段と、上記抽出されたインターフェース仕様及びモジュールの定義・参照をもとに上記疑似言語記述に対応したデザインレビュー用資料を生成するデザインレビュー用資料生成手段とを有することを特徴とするプログラム生産支援装置。
　【請求項５】　生成手段は、構文解析結果をもとに自然言語で記述されている処理説明および制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語記述に対応した木構造チャートを生成する木構造チャート生成手段とを有することを特徴とする請求項３記載のプログラム生産支援装置。
　【請求項６】　生成手段は、構文解析結果をもとに自然言語で記述されている処理説明及び制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語の制御構造をそれに対応するプログラミング言語の制御構造に変換する制御構造変換手段と、上記変換された木構造をもとに疑似言語の処理説明をプログラミング言語のコメントに変換する手段とを有することを特徴とする請求項３記載のプログラム生産支援装置。
　【請求項７】　特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述を生成する生成手段とを有することを特徴とするプログラム生産支援装置。
　【請求項８】　プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有するものであって、
　生成手段が、構文解析結果をもとにプログラムの制御構造及びそれに付随するコメントを抽出する制御構造抽出手段と、上記制御構造をもとにプログラミング言語の制御構造を自然言語及び上記プログラミング言語に準じた制御構造で記述された疑似言語の制御構造に変換する制御構造変換手段と、上記制御構造をもとに上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段とを有することを特徴とする請求項７記載のプログラム生産支援装置。
　【請求項９】　特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、
　上記生成手段は、構文解析結果をもとにプログラミング言語記述のヘッダーコメントに記述されたインターフェース仕様を抽出するインターフェース仕様抽出手段と、構文解析結果をもとに上記プログラミング言語記述のモジュールの定義・参照を木構造に変換して記憶するモジュール定義・参照抽出手段と、ヘッダーコメント中のモジュール欄の名称が実際のモジュール名に一致しているかを照合するモジュール名照合手段と、上記インターフェース仕様及び上記木構造をもとにプログラミング言語記述に対応したモジュール仕様書を生成するモジュール仕様生成手段とを有することを特徴とするプログラム生産支援装置。
　【請求項１０】　特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、
　上記生成手段は、構文解析結果をもとにシンボルの定義情報を記憶するシンボル定義抽出手段と、上記シンボルの定義情報をシンボルが定義された順に並び換えるシンボル定義並び換え手段と、上記シンボルの定義情報をもとにプログラミング言語記述に対応したシンボル一覧表を生成するシンボル一覧表生成手段とを有することを特徴とするプログラム生産支援装置。
【発明の詳細な説明】
　【０００１】
　【産業上の利用分野】
　この発明は、プログラムの生産を支援する装置に関するものである。
　【０００２】
　【従来の技術】
　図８２は、例えば特開平４−１１１１２４号公報に示された従来のプログラム生産支援装置を示す構成図、図８３は同従来のプログラム生産支援装置の動作を示すフローチャートである。
　図８２において、１５０１はキーボードなどのデータ入力手段、１５０２はデータ定義部、１５０３は表示部、１５０４は表示手段、１５０５はブロック・チャート編集部、１５０６はブロック・エディタ部、１５０７はソースコード出力部、１５０８はソースコード記録手段である。
　【０００３】
　この従来のプログラム生産支援装置の動作について、図８３のフローチャートを用いて説明する。まず、データ入力手段１５０１より、ファイル名、デバイス・タイプなどのデータをデータ定義部１５０２に入力し、表示部１５０３を介して表示手段１５０４に表示して確認を行なう。
　同様にして、データ入力手段１５０１より、ブロック・チャートのレイアウト情報をブロック・チャート編集部１５０５に入力し、表示部１５０３を介して表示手段１５０４に表示して確認し、修正の必要があれば同じ手順にて修正する。
　更に、データ入力手段１５０１より、プログラムの部品内容をブロック・エディタ部１５０６に入力し、表示部１５０３を介して表示手段１５０４に表示して確認し、修正の必要があれば同じ手順にて修正する。
　以上の作業結果に不備がある場合は、満足のいく結果が得られるまで以上の操作を手作業にて繰り返し行なう。
　しかる後に、データ定義、ブロック・チャート、プログラム部品の情報を寄せ集めてソースコード出力部１５０７に入力して編集し、その結果をソースコード記録手段１５０８に記録する。
　こうして得られたソースコードに不備がある場合は、満足のいく結果が得られるまで以上全ての操作を繰り返し行なう。
　【０００４】
　【発明が解決しようとする課題】
　従来のプログラム生産支援装置は以上のように構成されているので、プログラムを変更する場合には、作業者が上記作業を画面で確認しながら繰り返して行なう必要があり、かなりの時間を要するという問題があった。
　更に作業者が間違ったデータを入力しても、そのことを検出する手段がなかったり、入力途中の段階では内容を確認できないなどの問題点があった。
　入力に際しても設計が固まってからでなければ作業に着手できず、設計途中の未完成段階では全く入力できないという問題があった。
　また、このような作業を行なう為には、グラフィック表示機能の付いた高価な計算機が必要となり、広く全員に広めることが不可能であった。
　【０００５】
　この発明は上記課題を解決する為になされたものであり、言語ベースのデータを入力とすることにより、このデータを入力するだけで、入力データに関する文法チェックを自動的に行なうと共に、必要な図表を自動的に生成する装置を得ることを目的とする。
　また、前工程で作成されレビューされたデータを、後工程の入力（ひな型）として流用できるようにすることで、前工程のデータを正確に後工程に伝える為の装置を得ることも目的とする。
　更に、全ての入力と出力をテキスト（文字データ）にすることにより、広く一般に普及している汎用のテキスト・エディタを用いて、データの入力および編集を可能にすると共に、広く一般に普及しているＣＲＴおよびプリンタから図表を出力できるようにし、広く全員に普及できる装置を得ることも目的とする。
　【０００６】
　【課題を解決するたもの手段】
　この発明におけるプログラム生産支援装置は、言語から言語もしくは言語から図表への自動変換を主体とし、言語の正当性検査手段と図表の自動生成手段を設けたものである。
　この発明に係るプログラム生産支援装置は、自然言語と各機能の階層構造を示す記号
とで
た仕
述を
　【０００７】
　
さらに、
、
を
し、
ようにしてもよい
　【０００８】
　また、この発明に係るプログラム生産支援装置は、自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有するものである。
　また、この発明に係るプログラム生産支援装置は、自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、上記生成手段が、構文解析結果をもとに上記仕様記述部に記述されたインターフェース仕様を抽出するインターエース仕様抽出手段と、上記構文解析結果をもとに上記ロジック記述部に記述されたモジュールの定義・参照を抽出するモジュール定義・参照抽出手段と、上記抽出されたインターフェース仕様及びモジュールの定義・参照をもとに上記疑似言語記述に対応したデザインレビュー用資料を生成するデザインレビュー用資料生成手段とを有するものである。
　【０００９】
　また、生成手段が、構文解析結果をもとに自然言語で記述されている処理説明および制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語記述に対応した木構造チャートを生成する木構造チャート生成手段とを有するようにしてもよい。
　【００１０】
　さらに、生成手段が、構文解析結果をもとに自然言語で記述されている処理説明及び制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語の制御構造をそれに対応するプログラミング言語の制御構造に変換する制御構造変換手段と、上記変換された木構造をもとに疑似言語の処理説明をプログラミング言語のコメントに変換する手段とを有するようにしてもよい。
　【００１１】
　また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述を生成する生成手段とを有するものである。
　【００１２】
　また、プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有するものであって、生成手段が、構文解析結果をもとにプログラムの制御構造及びそれに付随するコメントを抽出する制御構造抽出手段と、上記制御構造をもとにプログラミング言語の制御構造を自然言語及び上記プログラミング言語に準じた制御構造で記述された疑似言語の制御構造に変換する制御構造変換手段と、上記制御構造をもとに上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段とを有するようにしてもよい。
　【００１３】
　また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、構文解析結果をもとにプログラミング言語記述のヘッダーコメントに記述されたインターフェース仕様を抽出するインターフェース仕様抽出手段と、構文解析結果をもとに上記プログラミング言語記述のモジュールの定義・参照を木構造に変換して記憶するモジュール定義・参照抽出手段と、ヘッダーコメント中のモジュール欄の名称が実際のモジュール名に一致しているかを照合するモジュール名照合手段と、上記インターフェース仕様及び上記木構造をもとにプログラミング言語記述に対応したモジュール仕様書を生成するモジュール仕様生成手段とを有するものである。
　【００１４】
　また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、構文解析結果をもとにシンボルの定義情報を記憶するシンボル定義抽出手段と、上記シンボルの定義情報をシンボルが定義された順に並び換えるシンボル定義並び換え手段と、上記シンボルの定義情報をもとにプログラミング言語記述に対応したシンボル一覧表を生成するシンボル一覧表生成手段とを有するものである。
　【００１５】
　【作用】
　この発明におけるプログラム生産支援装置は、言語から言語への変換を主体とし、図表レベルでの変更・修正に比べてデータの変更・修正を容易とする一方、データが部分的に入力された段階でも各種図表を生成し、中間的な出力結果を見ながらデータを変更・修正していくことを可能とする。
　すなわち、この発明のプログラム生産支援装置は、書籍の目次に準じた形式の仕様記述を入力にすることにより、プログラムの機能構成を示した機能構成図を自動的に生成する。
　【００１６】
　さらに、書籍の目次に準じた形式の仕様記述を入力にすることにより、プログラムを実現するに必要なディレクトリ、ファイルおよびモジュールを自動的に生成する。
　【００１７】
　また、この発明のプログラム生産支援装置は、プログラミング言語に準じた疑似言語記述を入力にすることにより、モジュールのデザインレビュー用資料を自動的に生成する。
　【００１８】
　また、プログラミング言語に準じた疑似言語記述を入力にすることにより、モジュールの処理フローを示す木構造をチャートを自動的に生成する。
　【００１９】
　さらに、プログラミング言語に準じた疑似言語記述を入力にすることにより、モジュールのプログラミング言語記述のひな形を自動的に生成する。
　【００２０】
　また、この発明のプログラム生産支援装置は、プログラミング言語記述を入力にすることにより、プログラミング言語記述からプログラミング言語記述に準じた疑似言語を自動的に生成する。
　【００２１】
　また、プログラミング言語記述を入力にすることにより、ヘッダーコメント中の「ＭＯＤＵＬＥ」欄に記述された名前に正確に対応したモジュール仕様書を自動的に生成する。
　【００２２】
　また、プログラミング言語記述を入力にすることにより、プログラミング言語記述から実用的なシンボル一覧表を自動的に生成する。
　【００２３】
　さらに、プログラム生産における事務的な処理を自動化したり、前工程で作成されレビューされた情報を後工程の入力として流用することが可能となる。
　【００２４】
　【実施例】
　以下、この発明の各実施例について、図１乃至図８１を用いて説明する。
　図８１は、以下に記述する実施例１〜実施例１２の前提となるハードウェアを示す構成図である。この図８１において、１４０１は入力手段としてのキーボード、１４０２は表示手段としてのディスプレイ、１４０３はプログラム生産支援装置の主要構成部としての計算機、１４０４は計算機１４０３に対する外部メモリを構成する外部記憶、１４０５は出力手段としてのプリンタである。
実施例１．
　図１は実施例１のプログラム生産支援装置を示す構成図、図２は実施例１におけるプログラム生産支援装置の動作を示すフローチャート、図３および図４は実施例１の入力である「仕様記述」の一例を示す図、図５および図６は実施例１の出力である「機能構成図」の一例を示す図、図７は実施例１の制御構造抽出手段によって変換され記憶される木構造を示す図である。
　【００２５】
　図１において、１０１は自然言語および各機能の階層構造と種別が記述された「仕様記述」、１０２は仕様記述１０１を読み込みその内容を字句に分解する「字句解析手段」、１０３は字句に分解された仕様記述１０１の構文解析を行う「構文解析手段」、１０４は構文解析手段１０３による仕様記述１０１の構文解析結果をもとに各機能の階層構造を木構造に変換して記憶する「階層構造抽出手段」、１０５は階層構造抽出手段１０４によって記憶された木構造をもとに仕様記述１０１に対応した機能構成図を自動生成する「機能構成図生成手段」、１０６は機能構成図生成手段１０５によって自動生成された「機能構成図」である。
　【００２６】
　この実施例１におけるプログラム生産支援装置の動作について、図２に示すフローチャートを用いて説明する。まず、字句解析手段１０２は、自然言語および各機能の階層構造と種別を示す特殊記号で記述された仕様記述１０１（図３および図４参照）を読み込みその内容を字句に分解する（図２のステップ（イ））。
　次に、構文解析手段１０３は、字句解析手段１０２によって字句に分解された仕様記述１０１の構文解析を行う（図２のステップ（ロ））。
　次に、階層構造抽出手段１０４は、構文解析手段１０３による仕様記述１０１の構文解析結果をもとに仕様記述１０１内の行頭に記述されたピリオドの数によって、各機能の階層構造（ピリオドの数が多いほど下位構造であることを意味する）を判断し、その情報、例えば、
　　．大機能
　　．．中機能
　　．．．小機能
　　．．．小機能
　　．．中機能
　　．．．小機能
　　．．．小機能
を図７に示す木構造に変換して記憶すると共に、ピリオドの直後に記述されている機能概要（例えば図３および図４中の「全機能」）を、階層構造に対応付けて記憶する（図２中のステップ（ハ））。
　次に、機能構成図生成手段１０５は、階層構造抽出手段１０４によって記憶された木構造をもとに、仕様記述１０１に対応した機能構成図１０６（図５および図６参照）を自動生成する（図２中のステップ（ニ））。
　【００２７】
　この実施例１では、各機能の階層構造を示す特殊記号としてピリオドを用いる方法を紹介したが、これは他のいかなる記号（例えば「＠」）であっても構わない。
　同様に、この実施例１では、各機能の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造（例えば「リスト構造」）であっても構わない。
　【００２８】
　次に、従来例と比較して、この実施例１の優れている点について説明する。この実施例１と同じ機能を実現する従来の方法としては次の２つが考えられる。
　【００２９】
　第１の方法は、図形エディタなどの汎用ツールを用いて、目的とする機能構成図を人間が作成するというものである。この方法は確かに現実的ではあるが、図の作成に膨大な時間が必要（作業コストの問題）となるだけでなく、図の書き方に個人差が出る（属人性の問題）、ミスが入り込みやすい（作業品質の問題）、など多くの問題がある。
　【００３０】
　第２の方法は、機能構成図を作成する為の専用エディタを開発し提供するというものである。この方法では、第１の方法の欠点をある程度解消することはできるが、代わりに、専用エディタを開発するのに相当な費用がかかる（開発コストの問題）、開発したエディタは機能構成図専用であり潰しが利かない（投資効果の問題）、ユーザに専用エディタの使い方を教育する必要がある（教育コストの問題）、といった新たな問題を誘発する。
　【００３１】
　これに対しこの実施例１を使用した場合、書籍の目次に準じた形式（〜章、〜節、〜項といった感覚）の仕様記述１０１を入力するだけで、プログラムの機能構成を示した機能構成図が自動的に生成されるので、人間が図形エディタなどを用いてこれと同等な機能構成図を作成するのに比べ、図の作成に要する時間が大幅に短縮されるだけでなく、図の書き方に関する個人差が完全に是正されると共に、仕様と図との不一致が全く無くなるという効果がある。
　更に、入力となる仕様記述１０１は容易に再配置可能であり、必要に応じ如何ようにでも順番を入れ替えて試行錯誤できるという効果がある。
　また、入力となる仕様記述１０１は単なるテキストであり、一般的なテキスト・エディタを用いて作成できるので、新たに専用エディタを開発して提供する必要がないばかりか、ユーザが自分の使い慣れたエディタを用いて仕様記述１０１を作成できるという効果がある。これは、この実施例１が低コストで実現かつ運用可能であることを意味している。
　【００３２】
　以上のようにこの実施例１によれば、図１に示すように、書籍の目次に準じた形式の仕様記述１０１を入力にすると共に、プログラム生産支援装置中に、字句解析手段１０２、構文解析手段１０３、階層構造抽出手段１０４、および機能構成図生成手段１０５を設けることにより、機能構成図１０６の作成に要する時間を大幅に短縮できると共に、機能構成図１０６の品質を格段に高めることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
　【００３３】
実施例２．
　図８は、実施例２のプログラム生産支援装置を示す、図９は実施例２におけるプログラム生産支援装置の動作を示すフローチャート、図１０は実施例２の出力であるディレクトリ構成の一例を示す図、図１１は実施例２の出力であるモジュールの一例を示す図構成図である。なお、実施例２の入力である「仕様記述」の一例としては、図３および図４に図示したものを使用する。
　【００３４】
　以下、図８の図１と異なる要素について説明する。図８において、２０１は階層構造抽出手段１０４によって記憶された木構造をもとに仕様記述１０１に従ってディレクトリを自動生成する「ディレクトリ生成手段」、２０２は階層構造抽出手段１０４によって記憶された木構造をもとに仕様記述１０１に従ってファイルを自動生成する「ファイル生成手段」、２０３は階層構造抽出手段１０４によって記憶された木構造をもとに仕様記述１０１に従ってモジュールを自動生成する「モジュール生成手段」、２０４は「外部記憶」、２０５はディレクトリ生成手段２０１によって外部記憶２０４中に自動生成された「ディレクトリ」、２０６、２０７、２０８はファイル生成手段２０２によってディレクトリ２０５下に自動生成された「ファイル」、２０９、２１０、２１１はモジュール生成手段２０３によってファイル２０８内に自動生成された「モジュール」である。
　【００３５】
　この実施例２におけるプログラム生産支援装置の動作について、図９に示すフローチャートを用いて説明する。図９において、ステップ（イ）、ステップ（ロ）、ステップ（ハ）は、図２のそれと基本的に同じである。ただし、ステップ（ハ）は、ピリオドの直後に記述されている機能概要（例えば図３および図４中の「全機能」）を階層構造に対応付けて記憶する以外に、ピリオドで始まる行の行末に記述されている識別子（例えば図３および図４中の「ｄｉｒ＿１」）、その識別子の末尾に記述されている各機能の種別を示す特殊記号（「／」「．ｃ」「（）」）、および、行頭がピリオドで始まる行の次の行に記述されている機能説明（例えば図３および図４中の「全機能に対する機能説明」）を、階層構造に対応付けて記憶する点が異なっている。
　尚、このとき階層構造に対応付けて記憶された各機能の種別を示す特殊記号は、のちほど各機能を具現化する際に、それらをディレクトリ２０５、ファイル２０６〜２０８、モジュール２０９〜２１１のいずれとして生成するかを決定する（図９のステップ（ニ））。
　以下、図９の図２と異なる動作について説明する。仕様記述１０１に対して一通りの処理（木構造への変換とその記憶）が完了すると、ディレクトリ生成手段２０１は、階層構造抽出手段１０４によって記憶された木構造をもとに、各機能の種別を示す特殊記号が「／」であるものについて、それに対応して記憶された識別子を名前とするディレクトリ２０５を、外部記憶２０４中に自動生成する（図９のステップ（ホ））。
　同様に、ファイル生成手段２０２は、階層構造抽出手段１０４によって記憶された木構造をもとに、各機能の種別を示す特殊記号が「．ｃ」であるものについて、それに対応して記憶された識別子を名前とするファイル２０６〜２０８（図１０参照）をディレクトリ２０５下に自動生成する（図９のステップ（ヘ））。
　同様に、モジュール生成手段２０３は、階層構造抽出手段１０４によって記憶された木構造をもとに、各機能の種別を示す特殊記号が「（）」であるものについて、それに対応して記憶された識別子を名前とするモジュール２０９〜２１１（図１１参照）をファイル２０８内に自動生成する（図９のステップ（ト））。
　【００３６】
　次に、仕様記述１０１からモジュール２０９〜２１１を生成する手順を、図３と図４および図１１を用いて説明する。
　【００３７】
　前述のとおり、仕様記述１０１内の情報がディレクトリ２０５、ファイル２０６〜２０８、モジュール２０９〜２１１のいずれとして具現化されるかは、各機能の種別を示す特殊記号（「／」「．ｃ」「（）」）によって決定される。
　例えば、図３および図４中の
　　．．大機能　　　　　　　　　　　　　　　ｄｉｒ＿１＿１／
　　　　　　［大機能に対する機能説明］
　　．．．中機能　　　　　　　　　　　　　　ｆｉｌｅ＿１＿１＿１．ｃ
　　　　　　［中機能に対する機能説明］
　　．．．．小機能　　　　　　　　　　　　　ｆｕｎｃ＿１＿１＿１＿１（）
　　　　　　［小機能に対する機能説明］
という記述は、行頭のピリオドの数によって、
　　大機能−中機能−小機能
という階層構造を意味すると共に、各機能の種別を示す特殊記号によって、
　「「ｄｉｒ＿１＿１」という名前のディレクトリを生成（「／」で指示）した上で、その下に「ｆｉｌｅ＿１＿１＿１．ｃ」という名前のファイルを生成（「．ｃ」で指示）し、その内部に「ｆｕｎｃ＿１＿１＿１＿１」という名前のモジュールを生成（「（）」で指示）せよ」
という作業指示を意味している。
　この原則により、仕様記述１０１から必要なディレクトリ２０５、ファイル２０６〜２０８、モジュール２０９〜２１１が自動的に生成される。
　【００３８】
　尚、こうして生成されたモジュール２０９〜２１１には、仕様記述１０１中のピリオドで始まる行の行末に記述されている識別子（例えば図３および図４中の「ｆｕｎｃ＿１＿１＿１＿１（）」）がモジュール２０９〜２１１内の仕様記述部（ｆｕｎｃｔｉｏｎ　ｓｐｅｃ）とロジック記述部（ｆｕｎｃｔｉｏｎ　ｌｏｇｉｃ）の名前として、ピリオドの直後に記述されている機能概要（例えば図３および図４中の「小機能」）が仕様記述部のＡＢＳＴＲＡＣＴ欄の説明として、ピリオドで始まる行の次の行に記述されている機能説明（例えば図３および図４中の「小機能に対する機能説明」）が仕様記述部のＦＵＮＣＴＩＯＮ欄の説明として、それぞれ
　　ｆｕｎｃｔｉｏｎ　ｓｐｅｃ　ｆｕｎｃ＿１＿１＿１＿１（）　　　　　←仕様記述部
　　｛
　　　　　　　　　　ＡＢＳＴＲＡＣＴ：小機能
　　　　　　　　　　ＦＵＮＣＴＩＯＮ：小機能に対する機能説明
　　　　　　　　　　ＮＯＴＥ　　　　：
　　ｉｎｔｅｒｆａｃｅ：
　　　　　　　　　　ＡＲＧＵＭＥＮＴ：
　　　　　　　　　　ＲＥＴＵＲＮ　　：
　　　　　　　　　　ＧＬＯＢＡＬ　　：
　　｝
　　ｆｕｎｃｔｉｏｎ　ｌｏｇｉｃ　ｆｕｎｃ＿１＿１＿１＿１（）　　　　←ロジック記述部
　　｛
　　｝
という形式で自動的に反映される。
　【００３９】
　この実施例２では、各機能の階層構造を示す特殊記号としてピリオドを用いる方法を紹介したが、これは他のいかなる記号（例えば「＠」）であっても構わない。
　同様に、この実施例２では、各機能の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造（例えば「リスト構造」）であっても構わない。
　同様に、この実施例２では、各機能の種別を示す特殊記号（ディレクトリ２０５、ファイル２０６〜２０８、モジュール２０９〜２１１のいずれとして具現化するかを指示）として、それぞれ「／」「．ｃ」「（）」を用いる方法を紹介したが、これは他のいかなる記号（例えば「．ｄｉｒ」「．ｆｉｌｅ」「．ｍｏｄｕｌｅ」）であっても構わない。
　同様に、この実施例２では、仕様記述内の情報をモジュール２０９〜２１１内に反映する手段として、「仕様記述部」と「ロジック記述部」という形式を用いる方法を紹介したが、これは他のいかなる形式（例えば「表形式」）であっても構わない。
　【００４０】
　次に、従来例と比較して、この実施例２の優れている点について説明する。この実施例２と同じ機能を実現する従来の方法としては次のものが考えられる。
　【００４１】
　その方法とは、ディレクトリ、ファイル、およびモジュールを生成する為の対話型ツールを開発し提供するというものである。この方法は一見合理的に見えるが、実施例１のところでも指摘したとおり、対話型ツールを開発するのに相当な費用がかかる（開発コストの問題）、開発した対話型ツールは当該機能専用であり潰しが利かない（投資効果の問題）、ユーザに対話型ツールの使い方を教育する必要がある（教育コストの問題）だけでなく、目的のものを作成するのに膨大な時間がかかる（作業コストの問題）、作業のやり方に個人差が出る（属人性の問題）、ミスが入り込みやすい（作業品質の問題）、など多くの問題がある。
　【００４２】
　これに対しこの実施例２を使用した場合、書籍の目次に準じた形式（〜章、〜節、〜項といった感覚）の仕様記述１０１を入力するだけで、プログラムを実現するのに必要なディレクトリ２０５、ファイル２０６〜２０８およびモジュール２０９〜２１１が自動的に生成されるので、人間が対話型ツールを用いてこれと同等なリソースを生成するのに比べ、これらの生成に要する時間が大幅に短縮されるだけでなく、作業のやり方に関する個人差を完全に是正できると共に、前工程の設計情報（機能構成）を後工程に忠実に伝えることができるという効果がある。
　また、入力となる仕様記述１０１は単なるテキストであり、一般的なテキスト・エディタを用いて作成できるので、新たに専用エディタを開発して提供する必要がないばかりか、ユーザが自分の使い慣れたエディタを用いて仕様記述１０１を作成できるという効果がある。これは、この実施例２が低コストで実現かつ運用可能であることを意味している。
　【００４３】
　以上のようにこの実施例２によれば、図８に示すように、書籍の目次に準じた形式の仕様記述１０１を入力にすると共に、プログラム生産支援装置中に、字句解析手段１０２、構文解析手段１０３、階層構造抽出手段１０４、ディレクトリ生成手段２０１、ファイル生成手段２０２、およびモジュール生成手段２０３を設けることにより、プログラムを実現するのに必要なディレクトリ２０５、ファイル２０６〜２０８、およびモジュール２０９〜２１１を自動生成できると共に、前工程の設計情報（機能構成）を後工程に忠実に伝えることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
　【００４４】
実施例３．
　図１２は実施例３のプログラム生産支援装置を示す構成図、図１３は実施例３におけるプログラム生産支援装置の動作を示すフローチャート、図１４および図１５は実施例３の入力である「疑似言語記述」の一例を示す図、図１６は実施例３の出力である「デザインレビュー用資料」の一例を示す図である。
　【００４５】
　図１２において、３０１はモジュールのインターフェース仕様と処理フローが記述された「疑似言語記述」、３０２は疑似言語記述３０１を読み込んで字句に分解する「字句解析手段」、３０３は字句に分解された疑似言語記述３０１の構文解析を行なう「構文解析手段」、３０４は構文解析手段３０３による疑似言語記述３０１の構文解析結果をもとに仕様記述部の各欄に記述されたインターフェース仕様を記憶する「インターフェース仕様抽出手段」、３０５は構文解析手段３０３による疑似言語記述３０１の構文解析結果をもとにロジック記述部に記述されたモジュールの定義・参照を記憶する「モジュール定義・参照抽出手段」、３０６はインターフェース仕様抽出手段３０４およびモジュール定義・参照抽出手段３０５によって記憶された情報をもとに疑似言語記述３０１に対応したデザインレビュー用資料を自動生成する「デザインレビュー用資料生成手段」、３０７はデザインレビュー用資料生成手段３０６によって自動生成された「デザインレビュー用資料」である。
　【００４６】
　この実施例３におけるプログラム生産支援装置の動作について、図１３に示すフローチャートを用いて説明する。
　【００４７】
　まず、字句解析手段３０２は、モジュールのインターフェース仕様と処理フローが記述された疑似言語記述３０１（図１４および図１５参照）を読み込みその内容を字句に分解する（図１３のステップ（イ））。
　次に、構文解析手段３０３は、字句解析手段３０２によって字句に分解された疑似言語記述３０１の構文解析を行なう（図１３のステップ（ロ））。
　次に、インターフェース仕様抽出手段３０４は、構文解析手段３０３による疑似言語記述３０１の構文解析結果をもとに、疑似言語記述３０１内の仕様記述部（ｆｕｎｃｔｉｏｎ　ｓｐｅｃ）の先頭に記述されているモジュール名（例えば図１４および図１５中の「ｍａｉｎ」）、ＡＢＳＴＲＡＣＴ欄に記述されている機能概要（例えば図１４および図１５中の「モジュールの概要」）、ＦＵＮＣＴＩＯＮ欄に記述されている機能説明（例えば図１４および図１５中の「モジュールの機能」）、ＮＯＴＥ欄に記述されている備考（例えば図１４および図１５中の「モジュールを使う際の注意事項」）、ＡＲＧＵＭＥＮＴ欄に記述されている仮引数（例えば図１４および図１５中の「ＩＮ　ｉｎｔ　ａｒｇｕｍｅｎｔ＿１　仮引数の説明」）、ＧＬＯＢＡＬ欄に記述されている大域変数（例えば図１４および図１５中の「ＩＮ　ｉｎｔ　ｇｌｏｂａｌ＿１　大域変数の説明」）、ＲＥＴＵＲＮ欄に記述されている戻り値（例えば図１４および図１５中の「０　戻り値の説明」）を抽出して記憶する（図１３のステップ（ハ））。
　次に、モジュール定義・参照抽出手段３０５は、構文解析手段３０３による疑似言語記述３０１の構文解析結果をもとに、疑似言語記述３０１内のロジック記述部（ｆｕｎｃｔｉｏｎ　ｌｏｇｉｃ）の先頭に記述されているモジュールの定義（例えば図１４および図１５中の「ｆｕｎｃｔｉｏｎ　ｌｏｇｉｃ　ｍａｉｎ　｛・・・｝」）と、ロジック記述部（ｆｕｎｃｔｉｏｎ　ｌｏｇｉｃ）中に記述されているモジュールの参照（例えば図１４および図１５中の「××を××する［ｆｕｎｃｔｉｏｎ＿１］」）を抽出して記憶する（図１３のステップ（ニ））。
　次に、デザインレビュー用資料生成手段３０６は、インターフェース仕様抽出手段３０４および、モジュール定義・参照抽出手段３０５によって記憶された情報をもとに、疑似言語記述３０１に対応したデザインレビュー用資料３０７（図１６参照）を自動生成する（図１３のステップ（ホ））。
　【００４８】
　この実施例３では、モジュールのインターフェース仕様と処理フローを記述する手段として、Ｃ言語に準じた疑似言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語（例えば「Ａｄａ」）に準じたものであっても構わない。
　同様に、この実施例３では、モジュールの処理フローの階層構造を記述する手段として、疑似言語のブロック構造（例えば図１４および図１５中の「｛・・・｝」）を用いる方法を紹介したが、これは他のいかなる方法（例えばｂｅｇｉｎ文とｅｎｄ文で下位構造を囲む）であっても構わない。
　（注１）疑似言語とは、プログラミング言語の制御構造と自然言語の文章が混在する設計用の仮想言語を意味する。
　（注２）Ｃ言語とは、ＡＴ＆Ｔベル研究所で開発され、ＡＮＳＩ（Ａｍｅｒｉｃａｎ　Ｎａｔｉｏｎａｌ　Ｓｔａｎｄａｒｄｓ　Ｉｎｓｔｉｔｕｔｅ）で標準化されたプログラミング言語を意味する。
　（注３）Ａｄａとは米国防総省で開発されたプログラミング言語のことである。
　【００４９】
　次に、従来例と比較して、この実施例３の優れている点について説明する。この実施例３と同じ機能を実現する従来の方法としては次の２つが考えられる。
　【００５０】
　第１の方法は、ワープロなどの汎用ツールを用いて、目的とするデザインレビュー用資料を人間が作成するというものである。この方法は確かに現実的ではあるが、デザインレビュー用資料の作成に膨大な時間が必要（作業コストの問題）となるだけでなく、デザインレビュー用資料の形式に個人差が出る（属人性の問題）、ミスが入り込みやすい（作業品質の問題）、など多くの問題がある。
　【００５１】
　第２の方法は、デザインレビュー用資料を作成する為の専用エディタを開発し提供するというものである。この方法では、第１の方法の欠点をある程度解消することができるが、代わりに、専用エディタを開発するのに相当な費用がかかる（開発コストの問題）、開発したエディタはデザインレビュー用資料専用であり潰しが利かない（投資効果の問題）、ユーザに専用エディタの使い方を教育する必要がある（教育コストの問題）、といった新たな問題を誘発する。
　【００５２】
　これに対しこの実施例３を使用した場合、プログラミング言語に準じた疑似言語記述を入力するだけで、モジュールのデザインレビュー用資料３０７が自動的に生成されるので、人間がワープロなどを用いてこれと同等なデザインレビュー用資料を作成するのに比べ、デザインレビュー用資料３０７の作成に要する時間が大幅に短縮されるだけでなく、デザインレビュー用資料３０７の形式に関する個人差が完全に是正されると共に、モジュールの仕様とデザインレビュー用資料３０７との不一致が完全になくなるという効果がある。
　また、入力となる疑似言語記述３０１は単なるテキストであり、一般的なテキスト・エディタを用いて作成できるので、新たに専用エディタを開発して提供する必要がないばかりか、ユーザが自分の使い慣れたエディタを用いて疑似言語記述３０１を作成できるという効果がある。これは、この実施例３が低コストで実現かつ運用可能であることを意味している。
　【００５３】
　以上のようにこの実施例３によれば、図１２に示すように、プログラミング言語に準じた疑似言語記述３０１を入力にすると共に、プログラム生産支援装置中に、字句解析手段３０２、構文解析手段３０３、インターフェース仕様抽出手段３０４、モジュール定義・参照抽出手段３０５およびデザインレビュー用資料生成手段３０６を設けることにより、デザインレビュー用資料３０７の作成に要する時間を大幅に短縮できると共に、デザインレビュー用資料３０７の品質を格段に高めることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
　【００５４】
実施例４．
　図１７は実施例４のプログラム生産支援装置を示す構成図、図１８は実施例４におけるプログラム生産支援装置の動作を示すフローチャート、図１９は実施例４の出力である「木構造チャート」の一例を示す図、図２０は実施例４の制御構造抽出手段によって変換され記憶される木構造の一例を示す図、図２１は実施例４の木構造チャート生成手段によって生成される木構造チャートの一例を示す図、図２２は実施例４の制御構造抽出手段によって変換され記憶される上記とは別の木構造の一例を示す図、図２３は実施例４の木構造チャート生成手段によって生成される上記とは別の木構造チャートの一例を示す図である。なお、この実施例４の入力である「疑似言語記述」の一例としては、図１４および図１５に図示したものを使用する。
　【００５５】
　以下、図１７の図１２と異なる要素について説明する。図１７において、４０１は構文解析手段３０３による疑似言語記述３０１の構文解析結果をもとに疑似言語記述３０１のロジック記述部に記述された処理説明および制御構造を木構造に変換して記憶する「制御構造抽出手段」、４０２は制御構造抽出手段４０１によって記憶された木構造をもとに疑似言語記述３０１に対応した木構造チャートを自動生成する「木構造チャート生成手段」、４０３は木構造チャート生成手段４０２によって自動生成された「木構造チャート」である。
　【００５６】
　この実施例４におけるプログラム生産支援装置の動作について、図１８に示すフローチャートを用いて説明する。図１８において、ステップ（イ）、ステップ（ロ）は図１３のそれと同じである。
　以下、図１８の図１３と異なる動作について説明する。まず、制御構造抽出手段４０１は、構文解析手段３０３による疑似言語記述３０１の構文解析結果をもとに、疑似言語記述３０１のロジック記述部（ｆｕｎｃｔｉｏｎ　ｌｏｇｉｃ）に記述された処理説明（例えば図１４および図１５中の「／／　××を××する」）および制御構造（例えば図１４および図１５中の「ｉｆ（・・・）｛・・・｝」）を木構造に変換して記憶する（図１８のステップ（ハ））。
　次に、木構造チャート生成手段４０２は、制御構造抽出手段４０１によって記憶された木構造をもとに、疑似言語記述３０１に対応した木構造チャート４０３（図１９参照）を自動生成する（図１８のステップ（ニ））。
　【００５７】
　次に、制御構造抽出手段４０１および木構造チャート生成手段４０２が、疑似言語記述３０１から木構造チャート４０３を生成する手順を図１４、図１５および図１９〜図２３を用いて説明する。
　【００５８】
　この疑似言語では、
　（１）ブロック（「｛」と「｝」）は、その内側に記述された要素を下位構造として包含する。
　例えば、
　　××を××する
　　｛
　　　　　　△△を△△する；
　　　｝
という記述において、「××を××する」という処理説明は、「△△を△△する」という処理説明を下位構造として包含する。
　（２）「／／」は、それに連なる一連の要素を下位構造として包含する。
　例えば、
　　／／　××を××する
　　△△を△△する；
　　□□を□□する；
という記述において、「××を××する」という処理説明は、「△△を△△する」および「□□を□□する」という２つの処理説明を下位構造として包含する。という単純な原則を前提としているので、
　例えば、
　　××を××する
　　｛
　　　　　　／／　△△を△△する
　　　　　　□□を□□する；
　　　　　　□□を□□する；
　　　　　　／／　△△を△△する
　　　　　　□□を□□する；
　　　　　　□□を□□する；
　　｝
という疑似言語記述３０１は、制御構造抽出手段４０１によって図２０に示す木構造に変換して記憶された後、木構造チャート生成手段４０２によって図２１に示す木構造チャートに自動的に変換される。
　同様に、図１４および図１５中の
　　／／　××を××する
　　ｉｆ（××が××ならば）｛
　　　　　　　××を××する［ｆｕｎｃｔｉｏｎ＿１］；
　　　　　　　ｒｅｔｕｒｎ　エラーステータス；
　　｝
という疑似言語記述３０１は、制御構造抽出手段４０１によって図２２に示す木構造に変換して記憶された後、木構造チャート生成手段４０２によって図２３に示す木構造チャート（図１９参照）に自動的に変換される。
　【００５９】
　この実施例４では、モジュールのインターフェース仕様と処理フローを記述する手段として、Ｃ言語に準じた疑似言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語（例えば「Ａｄａ」）に準じたものであっても構わない。
　同様に、この実施例４では、モジュールの処理フローの階層構造を記述する手段として、疑似言語のブロック構造（例えば図１４および図１５中の「｛・・・｝」）を用いる方法を紹介したが、これは他のいかなる方法（例えばｂｅｇｉｎ文とｅｎｄ文で下位構造を囲む）であっても構わない。
　同様に、この実施例４では、具体的な木構造チャートとしてＮＴＴ（株）で考案されたＨＣＰチャートを用いる例を紹介したが、これは他のいかなる木構造チャート（例えば日本電気（株）のＳＰＤ）であっても構わない。
　同様に、この実施例４では、処理説明の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造（例えば「リスト構造」）であっても構わない。
　（注４）ＨＣＰチャートとは、Ｈｉｅｒａｒｃｈｉｃａｌ　ａｎｄ　ＣｏｍＰａｃｔ　ｄｅｓｃｒｉｐｔｉｏｎ　ｃｈａｒｔの略称である。
　（注５）ＳＰＤとは、Ｓｔｒｕｃｔｕｒｅｄ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｄｉａｇｒａｍの略称である。
　【００６０】
　次に、従来例と比較して、この実施例４の優れている点について説明する。この実施例４と同じ機能を実現する従来の方法としては次の２つが考えられる。
　【００６１】
　第１の方法は、図形エディタなどの汎用ツールを用いて、目的とする木構造チャートを人間が作成するというものである。この方法は確かに現実的ではあるが、木構造チャートの作成に膨大な時間が必要（作業コストの問題）となるだけでなく、木構造チャートの形式に個人差が出る（属人性の問題）、ミスが入り込みやすい（作業品質の問題）、など多くの問題がある。
　【００６２】
　第２の方法は、木構造チャートを作成する為の専用エディタを開発し提供するというものである。この方法では、第１の方法の欠点をある程度解消することができるが、代わりに、専用エディタを開発するのに相当な費用がかかる（開発コストの問題）、開発したエディタは木構造チャート専用であり潰しが利かない（投資効果の問題）、ユーザに専用エディタの使い方を教育する必要がある（教育コストの問題）、といった新たな問題を誘発する。
　【００６３】
　これに対しこの実施例４を使用した場合、プログラミング言語に準じた疑似言語記述３０１を入力するだけで、モジュールの処理フローを示す木構造チャート４０３が自動的に生成されるので、人間が図形エディタなどを用いてこれと同等な木構造チャート４０３を作成するのに比べ、木構造チャート４０３の作成に要する時間が大幅に短縮されるだけでなく、木構造チャート４０３の形式に関する個人差が完全に是正されると共に、モジュールの処理フローと木構造チャート４０３との不一致が完全になくなるという効果がある。
　また、入力となる疑似言語記述３０１は単なるテキストであり、一般的なテキスト・エディタを用いて作成できるので、新たに専用エディタを開発して提供する必要がないばかりか、ユーザが自分の使い慣れたエディタを用いて仕様記述を作成できるという効果がある。これは、本実施例が低コストで実現かつ運用可能であることを意味している。
　【００６４】
　以上のようにこの実施例４によれば、図１７に示すように、プログラミング言語に準じた疑似言語記述３０１を入力にすると共に、プログラム生産支援装置中に、字句解析手段３０２、構文解析手段３０３、制御構造抽出手段４０１および木構造チャート生成手段４０２を設けることにより、木構造チャート４０３の作成に要する時間を大幅に短縮できると共に、木構造チャート４０３の品質を格段に高めることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
　【００６５】
実施例５．
　図２４は実施例５におけるプログラム生産支援装置の構成を示すブロック図、図２５は実施例５におけるプログラム生産支援装置の動作を示すフローチャート、図２６および図２７は実施例５の出力である「プログラミング言語記述のひな形」の一例を示す図、図２８は実施例５の制御構造抽出手段によって変換され記憶される木構造の一例を示す図である。なお、この実施例５の入力である「疑似言語記述」の一例としては、図１４および図１５に図示したものを使用する。
　【００６６】
　以下、図２４の図１７と異なる要素について説明する。図２４において、５０１は制御構造抽出手段４０１によって記憶された木構造をもとに疑似言語の制御構造をプログラミング言語の制御構造に変換する「制御構造変換手段」、５０２は制御構造抽出手段４０１によって記憶された木構造をもとに疑似言語の処理説明をプログラミング言語のコメントに変換する「処理説明→コメント変換手段」、５０３は制御構造変換手段５０１および処理説明→コメント変換手段５０２によって自動生成された「プログラミング言語記述のひな形」である。
　【００６７】
　この実施例５におけるプログラム生産支援装置の動作について、図２５に示すフローチャートを用いて説明する。
　【００６８】
　図２５において、ステップ（イ）、ステップ（ロ）、ステップ（ハ）は図１８のそれと同じである。
　以下、図２５の図１８と異なる動作について説明する。まず、本処理系は、制御構造抽出手段４０１によって記憶された木構造をもとに、変換すべき対象が制御構造、処理説明のいずれであるかを判断する（図２５のステップ（ニ））。
　変換すべき対象が制御構造の場合、制御構造変換手段５０１は、制御構造抽出手段４０１によって記憶された木構造をもとに、疑似言語の制御構造（例えば図１４および図１５中の「ｉｆ（・・・）｛・・・｝」）を、プログラミング言語の制御構造（例えば図２６および図２７中の「ｉｆ（）｛・・・｝」に変換する（図２５のステップ（ホ））。
　変換すべき対象が処理説明の場合、処理説明→コメント変換手段５０２は、制御構造抽出手段４０１によって記憶された木構造をもとに、疑似言語の処理説明（例えば図１４および図１５中の「××が××ならば」）を、プログラミング言語のコメント（例えば図２６および図２７中の「／＊？××が××ならば＊／」）に変換する（図２５のステップ（ヘ））。
　【００６９】
　次に、制御構造変換手段５０１および処理説明→コメント変換手段５０２が疑似言語記述３０１からプログラミング言語記述のひな形５０３を生成する手順を、図１４および図１５と図２６および図２７を用いて説明する。
　【００７０】
　疑似言語からプログラミング言語への変換に際しては、
　（１）疑似言語の仕様記述部に記述されているモジュールのインターフェース仕様を、プログラミング言語のコメントに変換してモジュールの先頭に出力する。
　（２）上記（１）の実行に際し、仮引数に関するインターフェース仕様だけは、プログラミング言語における仮引数の宣言およびコメントに変換して出力する。
　（３）疑似言語の制御構造を、プログラミング言語の制御構造に変換して出力する。
　（４）疑似言語の処理説明を、プログラミング言語のコメントに変換して出力する。
　（５）上記（４）の実行に際し、疑似言語記述の条件中に記述された処理説明を条件の外へ移動させると共に、文章の先頭に「？」マークを付加してからプログラミング言語のコメントに変換して出力する。
　（６）上記（４）の実行に際し、ｂｒｅａｋ文、ｒｅｔｕｒｎ文、ｅｘｉｔ文に付随する処理説明を、それぞれの文と分離してからプログラミング言語のコメントに変換して出力する。
という変換規則を前提としているので、例えば、図１４および図１５中の
　　／／　××を××する
　　ｉｆ（××が××ならば）｛
　　　　　　　××を××する［ｆｕｎｃｔｉｏｎ＿１］；
　　　　　　　ｒｅｔｕｒｎ　エラーステータス；
　　｝
という疑似言語記述３０１は、制御構造抽出手段４０１によって図２８に示す木構造に変換して記憶された後、制御構造変換手段５０１および処理説明→コメント変換手段５０２によって
　　／＊
　　　＊　××を××する
　　　＊／
　　ｉｆ（）｛　　　　　　　　　　　／＊？××が××ならば　＊／
　　　　　　　／＊　××を××する　＊／
　　　　　　　ｆｕｎｃｔｉｏｎ＿１（）；
　　　　　　　ｒｅｔｕｒｎ；　　　　／＊　エラーステータス　＊／
　　｝
というプログラミング言語記述のひな形（図２６および図２７参照）に自動的に変換される。
　【００７１】
　この実施例５では、モジュールのインターフェース仕様と処理フローを記述する手段として、Ｃ言語に準じた疑似言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語（例えば「Ａｄａ」）に準じたものであっても構わない。
　同様に、この実施例５では、モジュールの処理フローの階層構造を記述する手段として、疑似言語のブロック構造（例えば図１４および図１５中の「｛・・・｝」）を用いる方法を紹介したが、これは他のいかなる方法（例えばｂｅｇｉｎ文とｅｎｄ文で下位構造を囲む）であっても構わない。
　同様に、この実施例５では、処理説明の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造（例えば「リスト構造」）であっても構わない。
　【００７２】
　次に、従来例と比較して、この実施例５の優れている点について説明する。この実施例５と同じ機能を実現する従来の方法としては次のものが考えられる。
　【００７３】
　その方法とは、モジュールのインターフェース仕様および処理フローをユーザに対話形式で定義させ、それらの情報からプログラミング言語記述のひな形を生成する対話型ツールを開発し提供するというものである。この方法は一見合理的に見えるが、前記実施例１のところでも指摘した通り、対話型ツールを開発するのに相当な費用がかかる（開発コストの問題）、開発した対話型ツールは当該機能専用であり潰しが利かない（投資効果の問題）、ユーザに対話型ツールの使い方を教育する必要がある（教育コストの問題）だけでなく、これらのツールは、一般にモジュールの処理フローを自然言語で記述すること（例えば「××を××する」）ができないので、設計工程であるにもかかわらず、ユーザはプログラミング言語でコーディングするのと変わらないレベルの詳細な情報（例えば「ｉｆ（ａ＝＝０）｛ａ＝ａ＋１；｝」）の入力を強要されるという問題がある。
　すなわち、この種のツールは、設計工程（モジュールの輪郭を定義することが目的）とコーディング工程（モジュールの詳細を定義することが目的）の境目を不明確にし、結果的にデザインレビュー（設計の再検討）を阻害するという問題を内包している。
　【００７４】
　これに対しこの実施例５を使用した場合、プログラミング言語に準じた疑似言語記述３０１からプログラミング言語記述のひな形５０３が自動的に生成されるので、前記実施例３および実施例４を用いてモジュールのインターフェース仕様および処理フロー（疑似言語で記述）に対し十分なデザインレビューを行ってから、その情報をプログラミング言語記述のひな形５０３に正確に反映させられるという効果がある。これは、前工程（設計）における設計者の意図を後工程（コーディング）を担当するプログラマに正確に伝えられることを意味している。
　また、入力となる疑似言語記述３０１は単なるテキストであり、一般的なテキスト・エディタを用いて作成できるので、新たに専用エディタを開発して提供する必要がないばかりか、ユーザが自分の使い慣れたエディタを用いて仕様記述を作成できるという効果がある。これは、この実施例５が低コストで実現かつ運用可能であることを意味している。
　【００７５】
　以上のようにこの実施例５によれば、図２４に示すように、プログラミング言語に準じた疑似言語記述３０１を入力にすると共に、プログラム生産支援装置中に、字句解析手段３０２、構文解析手段３０３、制御構造抽出手段４０１、制御構造変換手段５０１および処理説明→コメント変換手段５０２を設けることにより、前工程（設計）で十分にデザインレビューされた情報（疑似言語記述）を、後工程（コーディング）の入力（プログラミング言語記述のひな形）として流用できるので、設計者の意図をプログラマに正確に伝えることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
　【００７６】
実施例６．
　図２９は実施例６のプログラム生産支援装置を示す構成図、図３０は実施例６におけるプログラム生産支援装置の動作を示すフローチャート、図３１および図３２は実施例６の入力である「プログラミング言語記述」の一例を示す図、図３３および図３４は実施例６の出力である「疑似言語記述」の一例を示す図、図３５は実施例６の制御構造抽出手段によって変換され記憶される木構造の一例を示す図、図３６は実施例６の制御構造変換手段によって置換された木構造の一例を示す図である。
　【００７７】
　図２９において、６０１は特定のプログラミング言語で記述された「プログラミング言語記述」、６０２はプログラミング言語記述６０１を読み込んで字句に分解する「字句解析手段」、６０３は字句に分解されたプログラミング言語記述６０１の構文解析を行う「構文解析手段」、６０４は構文解析手段６０３によるプログラミング言語記述６０１の構文解析結果をもとにプログラムの制御構造とそれに付随するコメントを木構造に変換して記憶する「制御構造抽出手段」、６０５は制御構造抽出手段６０４によって記憶された木構造をもとにプログラミング言語の制御構造を疑似言語の制御構造に変換する「制御構造変換手段」、６０６は制御構造抽出手段６０５によって記憶された木構造をもとにプログラミング言語のコメントを疑似言語の処理説明に変換する「コメント→処理説明変換手段」、３０１は制御構造変換手段６０５およびコメント→処理説明変換手段６０６によって自動生成された「疑似言語記述」である。
　【００７８】
　この実施例６におけるプログラム生産支援装置の動作について、図３０に示すフローチャートを用いて説明する。
　【００７９】
　図３０において、ステップ（イ）〜（ヘ）は図２５のそれと基本的に同じである。両者で異なるのは、図３０が「プログラミング言語記述→疑似言語記述」への変換を、図２５が「疑似言語記述→プログラミング言語記述」への変換を説明している点である。
　【００８０】
　次に、制御構造変換手段６０５およびコメント→処理説明変換手段６０６がプログラミング言語記述６０１から疑似言語記述３０１を生成する手順を、図３１〜図３６を用いて説明する。
　【００８１】
　プログラミング言語から疑似言語への変換に際しては、
　（１）モジュールのヘッダー・コメント中のＡＢＳＴＲＡＣＴ欄、ＦＵＮＣＴＩＯＮ欄、ＮＯＴＥ欄、ＲＥＴＵＲＮ欄に記述されたインターフェース仕様、および、モジュールの仮引数の型・名前・コメント、モジュール内で参照している大域変数の型・名前・コメントを、疑似言語における仕様記述部（ｆｕｎｃｔｉｏｎ　ｓｐｅｃ）の形式に変換して出力する。
　（２）モジュール内の制御構造を、疑似言語の制御構造に変換して出力する。
　（３）モジュール内のコメントを、疑似言語の処理説明に変換して出力する。
　（４）上記（３）の実行に際し、文章の先頭に「？」マークの付いたコメントをそれに対応する条件と置き換え、疑似言語の処理説明に変換して出力する。
　（５）上記（３）の実行に際し、ｂｒｅａｋ文、ｒｅｔｕｒｎ文、ｅｘｉｔ文の行末にあるコメントをそれに対応する引数と置き換え、疑似言語の処理説明に変換して出力する。
という変換規則を前提としているので、例えば、図３１および図３２中の
　　／＊
　　　＊××を××する
　　　＊／
　　ｉｆ（ｇｌｏｂａｌ＿１＝＝０）｛　　　　／＊？××が××ならば　＊／
　　　　　　　　　　　　　　　　　　／＊　××を××する　＊／
　　　　　　　　　　　　　　　　　　ｆｕｎｃｔｉｏｎ＿１（）；
　　　　　　　　　　　　　　　　　　ｒｅｔｕｒｎ　−１；　　　　／＊　エラーステータス　＊／
　　｝
というプログラミング言語記述６０１は、制御構造抽出手段６０４によって図３５に示す木構造に変換して記憶された後、制御構造変換手段６０５およびコメント→処理説明変換手段６０６によって図３６のようにｉｆ文の条件とｒｅｔｕｒｎ文の引数がそれぞれに対応するコメントと置き換えられてから
　　／／　××を××する
　　ｉｆ（××が××ならば）｛
　　　　　　　××を××する［ｆｕｎｃｔｉｏｎ＿１］；
　　　　　　　ｒｅｔｕｒｎ　エラーステータス；
　　｝
という疑似言語記述３０１（図３３および図３４参照）に自動的に変換される。
　【００８２】
　この実施例６では、入力となるプログラミング言語としてＣ言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語（例えば「Ａｄａ」）であっても構わない。
　同様に、この実施例６では、出力としてＣ言語に準じた疑似言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語（例えば「Ａｄａ」）に準じたものであっても構わない。
　同様に、この実施例６では、処理説明の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造（例えば「リスト構造」）であっても構わない。
　【００８３】
　次に、従来例と比較して、この実施例６の優れている点について説明する。この実施例６と同じ機能を実現する従来の方法としては次のものが考えられる。
　【００８４】
　その方法とは、プログラミング言語記述の中からモジュールのインターフェース仕様に関する情報を手作業で抽出するというものである。この方法は誰もが無意識に行っていることであるが、情報を抽出するのに膨大な時間が必要（作業コストの問題）となるだけでなく、経験年数などによって作業効率のばらつきが大きい（属人性の問題）、ミスが入り込みやすい（作業品質の問題）など多くの問題がある。
　【００８５】
　これに対しこの実施例６を使用した場合、プログラミング言語記述６０１からプログラミング言語に準じた疑似言語が自動的に生成されるので、こうして得られた疑似言語記述３０１に対して前記実施例３および実施例４を適用すれば、結果的に、プログラミング言語記述からモジュールのインターフェース仕様に関する情報を自動的に抽出し、その情報をデザインレビュー用資料３０７や木構造チャート４０３の形式で把握できるという効果がある。
　実際問題として、ソフトウェアが大規模・複雑化の一途を辿っている現状では、何百、何千とあるモジュールのインターフェース仕様を人間に分かりやすいデザインレビュー用資料３０７や木構造チャート４０３の形式で把握できる意義は極めて大きい。
　【００８６】
　以上のようにこの実施例６によれば、図２９に示すように、プログラミング言語記述６０１を入力にすると共に、プログラム生産支援装置中に、字句解析手段６０２、構文解析手段６０３、制御構造抽出手段６０４、制御構造変換手段６０５およびコメント→処理説明変換手段６０６を設けることにより、プログラミング言語記述６０１からモジュールのインターフェース仕様に関する情報を自動的に抽出できるので、実際に動作しているプログラムの仕様を容易かつ正確に把握することが可能となり、結果としてプログラム生産および保守の高品質化に大きく寄与することができる。
　【００８７】
実施例７．
　図３７は実施例７のプログラム生産支援装置を示す構成図、図３８は実施例７０のプログラム生産支援装置の動作を示すフローチャート、図３９および図４０は実施例７の入力である「プログラミング言語記述」の一例を示す図、図４１乃至図４３は実施例７の出力である「木構造チャート」の一例を示す図、図４４は実施例７の制御構造抽出手段によって変換され記憶される木構造の一例を示す図、図４５は実施例７の木構造チャート生成手段によって生成される木構造チャートの一例を示す図、図４６は実施例７の不要情報割愛手段７０１によって補正される木構造の一例を示す図、図４７は実施例７の木構造チャート生成手段によって生成される上記とは別の木構造チャートの一例を示す図、図４８は実施例７の木構造チャート生成手段によって生成される上記とは更に別の木構造チャートの一例を示す図である。
　【００８８】
　以下、図３７の図２９と異なる要素について説明する。図３７において、７０１は制御構造抽出手段６０４によって記憶された木構造をもとにユーザの指定に応じ木構造から不要情報を割愛する「不要情報割愛手段」、７０２は不要情報割愛手段７０１によって補正された木構造をもとにプログラミング言語記述６０１に対応した木構造チャートを自動生成する「木構造チャート生成手段」、７０３は木構造チャート生成手段７０２によって自動生成された「木構造チャート」である。
　【００８９】
　この実施例７のプログラム生産支援装置の動作について、図３８に示すフローチャートを用いて説明する。図３８において、ステップ（イ）〜（ハ）は図６Ｂのそれと同じである。
　以下、図３８の図３０と異なる動作について説明する。まず、不要情報割愛手段７０１は、ユーザの指定に応じて、制御構造抽出手段６０４によって記憶された木構造から何を割愛するかを決定する（図３８のステップ（ニ））。
　ユーザの指定が「全ての文を木構造チャートに反映せよ」である場合、不要情報割愛手段７０１は、制御構造抽出手段６０４によって記憶された木構造に対して何も行わない。
　ユーザの指定が「コメントと制御構造のみを木構造チャートに反映せよ」である場合、不要情報割愛手段７０１は、制御構造抽出手段６０４によって記憶された木構造からコメントと制御構造以外を削除する（図３８のステップ（ホ））。
　ユーザの指定が「コメントのみを木構造チャートに反映せよ」である場合、不要情報割愛手段７０１は、制御構造抽出手段６０４によって記憶された木構造からコメント以外を削除する（図３８のステップ（ヘ））。
　次に、木構造チャート生成手段７０２は、不要情報割愛手段７０１によって補正された木構造をもとに、プログラミング言語記述６０１に対応した木構造チャート７０３（図４１、図４２、図４３参照）を生成する（図３８のステップ（ト））。
　【００９０】
　次に、不要情報割愛手段７０１および木構造チャート生成手段７０２が、プログラミング言語記述６０１からユーザの指定に応じ木構造チャート７０３を生成する手順を図３９〜図４８を用いて説明する。
　【００９１】
　例えば、図３９および図４０中の
　　／＊
　　　＊　××を××する
　　　＊／
　　ｌｏｃａｌ＿１＝０；
　　ｉｆ（ｇｌｏｂａｌ＿１＝＝０）｛
　　　　　　　　　ｆｕｎｃｔｉｏｎ＿１（）；
　　　　　　　　　ｒｅｔｕｒｎ　−１；
　　｝
というプログラミング言語記述は、制御構造抽出手段６０４によって図４４に示す木構造に変換して記憶される。
　ユーザの指定が「全ての文を木構造チャートに反映せよ」である場合、不要情報割愛手段７０１はこの木構造に対して何も行わないので、木構造チャート生成手段７０２は図４５に示す木構造チャート（図４１参照）を自動的に生成する。
　これに対し、ユーザの指定が「コメントと制御構造のみを木構造チャートに反映せよ」である場合、不要情報割愛手段７０１は木構造からコメントと制御構造以外を削除し、図４６に示すように、木構造を補正するので、木構造チャート生成手段７０２は図４７に示す木構造チャート７０３（図４２参照）を自動的に生成する。
　更に、ユーザの指定が「コメントのみを木構造チャートに反映せよ」である場合、不要情報割愛手段７０１は木構造からコメント以外を全て削除し
　　××を××する
のように木構造を補正するので、木構造チャート生成手段７０２は図４８に示す木構造チャート７０３（図４３参照）を生成する。
　【００９２】
　この実施例７では、入力となるプログラミング言語としてＣ言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語（例えば「Ａｄａ」）であっても構わない。
　同様に、この実施例７では、具体的な木構造チャート７０３としてＮＴＴ（株）で考案されたＨＣＰチャートを用いる方法を紹介したが、これは他のいかなる木構造チャート（例えば日本電気（株）のＳＰＤ）であっても構わない。
　同様に、この実施例７では、処理説明の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造（例えば「リスト構造」）であっても構わない。
　【００９３】
　次に、従来例と比較して、この実施例７の優れている点について説明する。
　【００９４】
　従来、プログラミング言語記述から木構造チャートを自動生成するツールとしては既に幾つかのものが知られているが、それらは一様にプログラミング言語記述中の文をありのまま木構造チャートに反映するものであり、大規模なプログラムに適用した場合には木構造チャートが詳細すぎて、プログラムの大まかな流れを把握する目的では使い物にならないという問題があった。
　【００９５】
　これに対しこの実施例７を使用した場合、ユーザの指定に応じて「プログラミング言語記述中の全ての文を木構造チャートに反映する」、「コメントと制御構造のみを木構造チャートに反映する」、「コメントのみを木構造チャートに反映する」、といった具合に木構造チャート７０３の粗さを調整できるので、「処理内容を逐一チェックしたい」、「プログラムの大まかな流れを把握したい」、「処理の概要を把握したい」という目的に応じた木構造チャート７０３を生成できるという効果がある。
　【００９６】
　以上のようにこの実施例７によれば、図３７に示すように、プログラミング言語記述６０１を入力にすると共に、プリンタ生産支援装置中に、字句解析手段６０２、構文解析手段６０３、制御構造抽出手段６０４、不要情報割愛手段７０１および木構造チャート生成手段７０２を設けることにより、プログラミング言語記述６０１からユーザの要求に応じた木構造チャート７０３を生成することができ、結果としてプログラム生産および保守の高品質化に大きく寄与することができる。
　【００９７】
実施例８．
　図４９は実施例８のプログラム生産支援装置を示す構成図、図５０は実施例８のプログラム生産支援装置の動作を示すフローチャート、図５１および図５２は実施例８の入力である「プログラミング言語記述」の一例を示す図、図５３は実施例８の出力である「モジュール仕様書」の一例を示す図である。
　図４９の図２９と異なる要素について説明する。図４９において、８０１は構文解析手段６０３によるプログラミング言語記述６０１の構文解析結果をもとにモジュールのインターフェース仕様を記憶する「インターフェース仕様抽出手段」、８０２は構文解析手段６０３によるプログラミング言語記述６０１の構文解析結果をもとにモジュールの定義・参照情報を記憶する「モジュール定義・参照抽出手段」、８０３はインターフェース仕様抽出手段８０１およびモジュール定義・参照抽出手段８０２によって記憶された情報をもとにモジュール名を照合する「モジュール名照合手段」、８０４はインターフェース仕様抽出手段８０１およびモジュール定義・参照抽出手段８０２によって記憶された情報をもとにプログラミング言語記述６０１に対応したモジュール仕様書を自動生成する「モジュール仕様書生成手段」、８０５はモジュール仕様書生成手段８０４によって自動生成された「モジュール仕様書」である。
　【００９８】
　この実施例８のプログラム生産支援装置の動作について、図５０に示すフローチャートを用いて説明する。
　【００９９】
　図５０において、ステップ（イ）〜（ロ）は図３０のそれと同じである。
　以下、図５０の図３０と異なる動作について説明する。まず、インターフェース仕様抽出手段８０１は、構文解析手段６０３によるプログラミング言語記述６０１の構文解析結果をもとに、モジュールのヘッダーコメント中の各欄（例えば図５１および図５２中の「ＭＯＤＵＬＥ」欄）に記述されたインターフェース仕様を抽出して記憶する（図５０のステップ（ハ））。
　次に、モジュール定義・参照抽出手段８０２は、構文解析手段６０３によるプログラミング言語記述６０１の構文解析結果をもとに、モジュールの定義（例えば図５１および図５２中の「ｖｏｉｄ　ｍａｉｎ（）｛・・・｝」）および、モジュールの参照情報を抽出して記憶する（図５０のステップ（ニ））。
　次に、モジュール名照合手段８０３は、インターフェース仕様抽出手段８０１およびモジュール定義・参照抽出手段８０２によって記憶された情報をもとに、ヘッダーコメント中の「ＭＯＤＵＬＥ」欄に記述されている名前と、そのヘッダーコメントに対応するモジュール定義の名前を照合する（図５０のステップ（ホ））。
　モジュール名が一致した場合、モジュール仕様書生成手段８０４は、インターフェース仕様抽出手段８０１およびモジュール定義・参照抽出手段８０２によって記憶された情報をもとに、プログラミング言語記述６０１に対応したモジュール仕様書８０５を生成する（図５０のステップ（ヘ））。
　モジュール名が一致しなかった場合、モジュール仕様書生成手段８０４は、エラーメッセージを出力してその旨をユーザに報告しモジュール仕様書８０５の生成を中止する（図５０のステップ（ト））。
　【０１００】
　この実施例８では、入力となるプログラミング言語としてＣ言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語（例えば「Ａｄａ」）であっても構わない。
　【０１０１】
　次に、従来例と比較して、この実施例８の優れている点について説明する。
　【０１０２】
　従来、プログラミング言語記述からモジュール仕様書を自動生成するツールとしては既に幾つかのものが知られているが、それらは一様に、ヘッダーコメント中から抽出したインターフェース仕様を、その直後に記述されているモジュール定義と盲目的に対応付けてモジュール仕様書を生成する様になっている為、ヘッダーコメント中に記述されたインターフェース仕様がモジュール定義と対応していなくてもモジュール仕様書が生成されるという問題があった。
　現実問題として、仕様書から内容を判断して作業しなければならない場合も多いので、でたらめな仕様書がソフトウェア生産全体に与える影響は無視できない。　勿論、ヘッダーコメントを記述する際に細心の注意を払っていれば問題ないのだが、実際には
　（１）最初のモジュールに対してヘッダーコメントを作成する。
　（２）それをテンプレートにして２番目のヘッダーコメントを作成する。
　（３）以下、全てのモジュールに対して（２）を繰り返す。
といった手順で作業した方が合理的なので、往々にして無関係なヘッダーコメントの付いたモジュールが発生する。
　大規模なプログラムではモジュールの数が１０００を越えることも珍しくないだけに、一旦紛れ込んだミスを見つけるのはこの問題がプログラムの動作に影響しない分だけ余計に厄介である。
　【０１０３】
　これに対しこの実施例８を使用した場合、ヘッダーコメント中の「ＭＯＤＵＬＥ」欄に記述された名前とそのヘッダーコメントに対応するモジュール定義の名前が一致しないと、エラーメッセージが出力されモジュール仕様書８０５の生成が中止されるので、この種の事故を未然に、かつ確実に防ぐことができるという効果がある。
　【０１０４】
　以上のようにこの実施例８によれば、図４９に示すように、プログラミング言語記述６０１を入力にすると共に、プログラム生産支援装置中に、字句解析手段６０２、構文解析手段６０３、インターフェース仕様抽出手段８０１、モジュール定義・参照抽出手段８０２、モジュール名照合手段８０３およびモジュール仕様書抽出手段８０４を設けることにより、プログラミング言語記述６０１から実際のモジュール定義に正確に対応したモジュール仕様書８０５を自動生成することができ、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
　【０１０５】
実施例９．
　図５４は実施例９プログラム生産支援装置を示す構成図、図５５は実施例９におけるプログラム生産支援装置の動作を示すフローチャート、図５６および図５７は実施例９の入力である「プログラミング言語記述」の一例を示す図、図５８は従来の「モジュール構成図」の一例を示す図、図５９は実施例９の出力である「モジュール構成図」の一例を示す図、図６０は実施例９のモジュール定義・参照抽出手段によって変換され記憶される木構造の一例を示す図、図６１は実施例９の同一構造割愛手段によって補正された木構造の一例を示す図である。
　【０１０６】
　図５４の図２９と異なる要素について説明する。図５４において、８０２は構文解析手段６０３によるプログラミング言語記述６０１の構文解析結果をもとにモジュールの定義・参照情報を記憶する「モジュール定義・参照抽出手段」、９０１はモジュール定義・参照抽出手段８０２によって記憶された木構造をもとに木構造上の同一構造を割愛する「同一構造割愛手段」、９０２は同一構造割愛手段９０１によって補正された木構造をもとにプログラミング言語記述６０１に対応したモジュール構成図を自動生成する「モジュール構成図生成手段」、９０３はモジュール構成図生成手段９０２によって自動生成された「モジュール構成図」である。
　【０１０７】
　この実施例９におけるプログラム生産支援装置の動作について、図５５に示すフローチャートを用いて説明する。図５５において、ステップ（イ）〜（ロ）は図３０のそれと同じである。
　以下、図５５の図３０と異なる動作について説明する。まず、モジュール定義・参照抽出手段８０２は、構文解析手段６０３によるプログラミング言語記述６０１の構文解析結果をもとに、モジュールの定義（例えば図５６および図５７中の「ｍａｉｎ（）｛・・・｝」）およびモジュールの参照（例えば図５６および図５７中の「ｓｕｂ（）；」）を木構造に変換して記憶する（図５５のステップ（ハ））。
　次に、同一構造割愛手段９０１は、モジュール定義・参照抽出手段８０２によって記憶された木構造をもとに、木構造上から同一構造を摘出する（図５５のステップ（ニ））。
　同一構造が摘出できなかった場合、同一構造割愛手段９０１は、モジュール定義・参照抽出手段８０２によって記憶された木構造に対して何も行わない。
　同一構造が摘出された場合、同一構造割愛手段９０１は、モジュール定義・参照抽出手段８０２によって記憶された木構造上から同一構造を削除し「〜と同じ」という情報で置換する（図５５のステップ（ホ））。
　次に、モジュール構成図生成手段９０２は、同一構造割愛手段９０１によって補正された木構造をもとに、プログラミング言語記述６０１に対応したモジュール構成図９０３（図５９参照）を自動生成する（図５５のステップ（ヘ））。
　【０１０８】
　次に、同一構造割愛手段９０１およびモジュール構成図生成手段９０２がプログラミング言語記述６０１からモジュール構成図９０３を生成する手順を、図５６および図５７、図５９を用いて説明する。
　【０１０９】
　例えば、図５６および図５７中の
　　ｍａｉｎ（）
　　｛
　　　　　　　　ｓｕｂ（）；
　　　　　　　　ｓｕｂ（）；
　　｝
　　ｓｕｂ（）
　　｛
　　　　　　　　ｓｕｂ２（）；
　　　　　　　　ｓｕｂ２（）；
　　｝
　　ｓｕｂ２（）
　　｛
　　　　　　　　ｓｕｂ３（）；
　　　　　　　　ｓｕｂ３（）；
　　｝
というプログラミング言語記述６０１は、モジュール定義・参照抽出手段８０２によって図６０に示す木構造に変換して記憶された後、同一構造割愛手段９０１によって、木構造を根元から辿りながら同一構造を順次「〜と同じ」という情報で置換することによって図６１に示す木構造に補正され、モジュール構成図生成手段９０２によって、図５９に示すモジュール構成図９０３が自動的に生成される。
　ちなみに、従来の方法では同一構造が割愛されない為に、結果として図５８に示す冗長なモジュール構成図が生成される。
　【０１１０】
　この実施例９では、入力となるプログラミング言語としてＣ言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語（例えば「Ａｄａ」）であっても構わない。
　同様に、この実施例９では、処理説明の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造（例えば「リスト構造」）であっても構わない。
　【０１１１】
　次に、従来例と比較して、この実施例９の優れている点について説明する。
　【０１１２】
　従来、プログラミング言語記述からモジュール構成図を自動生成するツールとしては既に幾つかのものが知られているが、それらが生成するモジュール構成図は一様に図５８の出力形式に準じたものであり、同一モジュールの参照が随所に現われる大規模プログラム（数万行以上）では、生成されるモジュール構成図が冗長（場合によってはＡ４版で数百ページ）になりすぎて使い物にならないという問題があった。
　【０１１３】
　これに対しこの実施例９を使用した場合、モジュール構成図９０３上の同一構造が「〜と同じ」という情報で置換されるので、同一モジュールの参照が随所に現われるような大規模プログラムでは、それに対するモジュール構成図９０３が劇的に簡素化（圧縮）されるという効果がある。
　【０１１４】
　以上のようにこの実施例９によれば、図５４に示すように、プログラミング言語記述６０１を入力にすると共に、プログラム生産支援装置中に、字句解析手段６０２、構文解析手段６０３、モジュール定義・参照抽出手段８０２、同一構造割愛手段９０１およびモジュール構成図生成手段９０２を設けることにより、プログラミング言語記述６０１から実用的なモジュール構成図９０３を自動生成することができ、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
　【０１１５】
実施例１０．
　図６２は実施例１０のプログラム生産支援装置を示す構成図、図６３は実施例１０におけるプログラム生産支援装置の動作を示すフローチャート、図６４乃至図６７は実施例１０の入力である「プログラミング言語記述」の一例を示す図、図６８は従来の「シンボル一覧表」の一例を示す図、図６９は実施例１０の出力である「シンボル一覧表」の一例を示す図である。
　【０１１６】
　図６２の図２９と異なる要素について説明する。図６２において、１００１は構文解析手段６０３によるプログラミング言語記述６０１の構文解析結果をもとにシンボルの定義情報を記憶する「シンボル定義抽出手段」、１００２はシンボル定義抽出手段１００１によって記憶された情報をもとにシンボルの定義情報を定義位置の順に並べ換える「シンボル定義並換え手段」、１００３はシンボル定義並換え手段１００２によって並べ換えられた情報をもとにプログラミング言語記述６０１に対応したシンボル一覧表を自動生成する「シンボル一覧表生成手段」、１００４はシンボル一覧表生成手段１００３によって自動生成された「シンボル一覧表」である。
　【０１１７】
　この実施例１０におけるプログラム生産支援装置の動作について、図６３に示すフローチャートを用いて説明する。
　【０１１８】
　図６３において、ステップ（イ）〜（ロ）は図３０のそれと同じである。
　以下、図６３の図３０と異なる動作について説明する。まず、シンボル定義抽出手段１００１は、構文解析手段６０３によるプログラミング言語記述６０１の構文解析結果をもとに、シンボルの定義（例えば図６４乃至図６７中の「ｆｕｎｃｔｉｏｎ＿１（）｛｝」）を辞書順に記憶する（図６３のステップ（ハ））。
　次に、シンボル定義並換え手段１００２は、シンボル定義抽出手段１００１によって記憶された情報をもとに、シンボルの定義情報を定義位置（例えば「ｍｏｄｕｌｅ−ｌｉｓｔ．ｃの６行目」）の順に並べ換える（図６３のステップ（ニ））。
　次に、シンボル一覧表生成手段１００３は、シンボル定義並換え手段１００２によって並べ換えられた情報をもとに、プログラミング言語記述６０１に対応したシンボル一覧表１００４を自動生成する（図６３のステップ（ホ））。
　【０１１９】
　この実施例１０では、入力となるプログラミング言語としてＣ言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語（例えば「Ａｄａ」）であっても構わない。
　同様に、この実施例１０では、シンボルの例としてモジュール定義を対象とする方法を紹介したが、これは他のいかなるシンボル（例えば「大域変数」や「マクロ」）であっても構わない。
　【０１２０】
　次に、従来例と比較して、この実施例１０の優れている点について説明する。
　【０１２１】
　従来、プログラミング言語記述からシンボル一覧表を自動生成するツールとしては既に幾つかのものが知られているが、それらが生成するシンボル一覧表は一様に図６８の出力形式に準じたものである。
　この種の表は特定のシンボルがどこで定義されているかを探す手掛かりとしては有用であるが、一般にモジュールや大域変数といったシンボルは、関連性の強いもの同士が一箇所（特定のファイル内）に固めて定義される傾向がある為、辞書順にシンボル名を並べる方法だと、例えば
　　ｉｎｔ　　　ｘ＿ａｘｉｓ；　　　／＊Ｘ座標　　＊／
　　ｉｎｔ　　　ｙ＿ａｘｉｓ；　　　／＊Ｙ座標　　＊／
という定義が一覧表上ではばらばらに出力されてしまう可能性が高い。
　従って、辞書順にシンボルを出力する形式のシンボル一覧表では、定義順序に込められたプログラマの意図をないがしろにしてしまうという問題があった。
　【０１２２】
　これに対しこの実施例１０を使用した場合、プログラミング言語記述６０１中に定義された順にシンボルが出力されるので、定義順序に込められたプログラマの意図がありのまま表現されるという効果がある。
　【０１２３】
　以上のようにこの実施例１０によれば、図６２に示すようにプログラミング言語記述６０１を入力にすると共に、プログラム生産支援装置中に、字句解析手段６０２、構文解析手段６０３、シンボル定義抽出手段１００１、シンボル定義並換え手段１００２およびシンボル一覧表生成手段１００３を設けることにより、プログラミング言語記述６０１から実用的なシンボル一覧表１００４を自動生成することができ、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
　【０１２４】
実施例１１．
　図７０は実施例１１のプログラム生産支援装置を示す構成図、図７１は実施例１１におけるプログラム生産支援装置の動作を示すフローチャート、図７２および図７３は実施例１１の入力である「プログラミング言語記述」の一例を示す図、図７４は実施例１１の出力である「警告メッセージ」の一例を示す図である。
　【０１２５】
　図７０の図２９と異なる要素について説明する。図７０において、１１０１は字句解析手段６０２によって字句に分解されたプログラミング言語記述６０１をもとに字句の並びの中から特定パターンを検出する「特定パターンの検出手段」、１１０２は特定パターンの検出手段１１０１によって出力された「警告メッセージ」である。
　【０１２６】
　この実施例１１におけるプログラム生産支援装置の動作について、図７１に示すフローチャートを用いて説明する。
　【０１２７】
　図７１において、ステップ（イ）は図３０のそれと同じである。
　以下、図７１の図３０と異なる動作について説明する。まず、特定パターンの検出手段１１０１は、字句解析手段６０２によって字句に分解されたプログラミング言語記述６０１をもとに、それらの字句がプログラムのどこに現われたかを見極め、特定の場所（例えば条件の中）に現われた字句の並びだけを抽出する（図７１のステップ（ロ））。
　次に、特定パターンの検出手段１１０１は、特定の場所に現われた字句の並びを並びのパターンによって選別し経験則と照合する（図７１のステップ（ハ））。
　字句の並びが経験則と一致した場合、特定パターンの検出手段１１０１は、その旨を通知する警告メッセージ１１０２を出力する（図７１のステップ（ニ））。
　【０１２８】
　次に、特定パターンの検出手段１１０１が、プログラミング言語記述６０１（図７２および図７３参照）から文法的には問題ないが意味的にはエラーである可能性の高いことが知られている記述を検出する手順を、図７２〜図７４を用いて説明する。
　【０１２９】
　例えば、図７２および図７３中の
　　ｉｆ（ａ＝０）｛
　　　　　　　ｆｕｎｃｔｉｏｎ（）；
　　｝
というＣ言語記述は文法的には正しい為、この記述に対しＣ言語のコンパイラはいかなるエラーメッセージも出力しない。
　ところが、Ｃ言語において「ｉｆ（ａ＝０）」という条件が成立することはありえない為、結果的に「ｆｕｎｃｔｉｏｎ（）；」という決して実行されることのない死角が発生する。
　このような記述に対し、特定パターンの検出手段１１０１は、特定の場所（この場合は「条件の中」）に現われた字句の並び（この場合は「ａ＝０」）だけに着目し、それを
　条件の中に代入演算子「＝」が単独で現われるのはおかしい
　条件の中にビット演算子「｜」が単独で現われるのはおかしい
といった一連の経験則と照合することにより、それが経験則と合致する場合には
　演算子「＝＝」と「＝」を間違えている可能性があります
といった警告メッセージを出力し、文法的には正しいが意味的にはエラーである可能性が高い記述を摘出する。
　【０１３０】
　次に、従来例と比較して、この実施例１１の優れている点について説明する。この実施例１１と同じ機能を実現する従来の方法としては次のものが考えられる。
　【０１３１】
　その方法とは、プログラミング言語記述の中から文法的には正しいが意味的にはエラーである可能性が高い記述を、自分の経験だけを頼りに手作業で摘出するというものである。この方法は誰もが無意識に行っていることであるが、問題を摘出するのに膨大な時間が必要（作業コストの問題）となるだけでなく、経験年数などによって作業効率のばらつきが大きい（属人性の問題）、ミスが入り込みやすい（作業品質の問題）など多くの問題がある。
　【０１３２】
　これに対しこの実施例１１を使用した場合、プログラミング言語記述６０１から文法的には正しいが意味的にはエラーである可能性が高い記述を自動的に検出できるので、同様な作業を人間が行った場合に比べ、問題点の摘出に要する時間を桁違いに短縮（数日に対して数秒）できるだけでなく、チェック漏れ、チェックミスといったことが全く無くなるという効果がある。
　【０１３３】
　以上のようにこの実施例１１によれば、図７０に示すように、プログラミング言語記述６０１を入力にすると共に、プログラム生産支援装置中に、字句解析手段６０２、特定パターンの検出手段１１０１を設けることにより、プログラミング言語記述６０１から文法的には正しいが意味的にはエラーである可能性が高い記述を自動的に検出できるので、結果としてプログラム生産の高品質化に大きく寄与することができる。
　【０１３４】
実施例１２．
　図７５は実施例１２のプログラム生産支援装置を示す構成図、図７６は実施例１２におけるプログラム生産支援装置の動作を示すフローチャート、図７７は実施例１２の入力である「プログラミング言語記述」の一例を示す図、図７８は実施例１２の出力である「加工されたプログラミング言語記述」の一例を示す図、図７９は実施例１２によって加工されたプログラムの「実行結果」の一例を示す図である。
　【０１３５】
　図７５の図２９と異なる要素について説明する。図７５において、１２０１は構文解析手段６０３によるプログラミング言語記述６０１の構文解析結果をもとにプログラミング言語記述６０１の特定箇所にプログラムの実行を追跡する為の実行追跡処理を埋込む「実行追跡処理埋込み手段」、１２０２は実行追跡処理埋込み手段１２０１によって実行追跡処理を埋め込まれた「加工されたプログラミング言語記述」である。
　【０１３６】
　この実施例１２におけるプログラム生産支援装置の動作について、図７６に示すフローチャートを用いて説明する。
　【０１３７】
　図７６において、ステップ（イ）〜（ロ）は図３０のそれと同じである。
　以下、図７６の図３０と異なる動作について説明する。まず、実行追跡処理埋込み手段１２０１は、構文解析手段６０３によるプログラミング言語記述６０１の構文解析結果をもとに、プログラム中の位置によって処理を振り分ける（図７６のステップ（ハ））。
　プログラム中の位置が「モジュールの先頭」である場合、実行追跡処理埋込み手段１２０１は、プログラムのブロックを一つ深くして実行追跡処理を埋込む（図７６のステップ（ニ））。
　プログラム中の位置が「モジュールの末尾」である場合、実行追跡処理埋込み手段１２０１は、プログラムのブロックを一つ深くして実行追跡処理を埋込む（図７６のステップ（ホ））。
　プログラム中の位置が「ｒｅｔｕｒｎ文の所」である場合、実行追跡処理埋込み手段１２０１は、ｒｅｔｕｒｎ文を囲む局所的なブロックを作って実行追跡処理を埋込む（図７６のステップ（ヘ））。
　プログラム中の位置が「普通の実行文の所」である場合、実行追跡処理埋込み手段１２０１は、実行文の直前に局所的なブロックを作って実行追跡処理を埋込む（図７６のステップ（ト））。
　【０１３８】
　次に、実行追跡処理埋込み手段１２０１がプログラミング言語記述６０１（図７７参照）に対して実行追跡処理を埋め込む手順を、図７７、図７８を用いて説明する。
　例えば、図７７中において１〜２行目の
　　ｍａｉｎ（）
　　｛
が「モジュールの先頭」という条件に該当するが、この行に対して実行追跡処理埋込み手段１２０１は、
　　ｍａｉｎ（）
　　｛　｛
の様に２行目の「｛」の外側にもう一つ「｛」を追加してブロックを一つ深くした上で、
　　ｍａｉｎ（）
　　｛＿ｐｒｏｂｅ（＊＋＊，”ｍａｉｎ”，”ｓａｍｐｌｅ．ｃ”，２）；｛
の様に「｛」と「｝」の間にプログラムの実行追跡処理を埋め込む。これにより、元のプログラムの動作には一切干渉せず当該プログラムの実行を追跡することが可能となる。
　尚、こうして埋め込まれた「＿ｐｒｏｂｅ」というモジュールには、それが埋め込まれた「プログラム中の論理的な位置（この場合はモジュールの実行開始を示す「＋」）」、「モジュールの名前（この場合は「ｍａｉｎ」）」、「物理的な位置（この場合は「ｓａｍｐｌｅ．ｃというファイルの２行目」）」という情報が引数で渡される為、後ほどこのプログラムを実行した時にどの「＿ｐｒｏｂｅ」であるかを容易に判断することができる。
　同様に、図７７において１０行目の
　　｝
が「モジュールの末尾」という条件に該当するが、この行に対して実行追跡処理埋込み手段１２０１は、
　　｝　｝
の様に１０行目の「｝」の外側にもう一つ「｝」を追加してブロックを一つ深くした上で、
　　｝＿ｐｒｏｂｅ（＊−＊，”ｍａｉｎ”，”ｓａｍｐｌｅ．ｃ”，１０）；｝
のように「｝」と「｝」の間にプログラムの実行追跡処理を埋め込む。
　「モジュールの先頭」の場合と同様、こうして埋め込まれた「＿ｐｒｏｂｅ」というモジュールには、それが埋め込まれた「プログラム中の論理的な位置（この場合はモジュールの実行終了を示す「−」）」、「モジュールの名前（この場合は「ｍａｉｎ」）」、「物理的な位置（この場合は「ｓａｍｐｌｅ．ｃというファイルの１０行目」）」という情報が引数で渡される。
　同様に、図７７において８行目の
　　ｒｅｔｕｒｎ（ｓｕｂ（））；
が「ｒｅｔｕｒｎ文の所」という条件に該当するが、この行に対して実行追跡処理埋込み手段１２０１は、
　　｛ｒｅｔｕｒｎ（ｓｕｂ（））；｝
のように８行目のｒｅｔｕｒｎ文を「｛」と「｝」で囲んで局所的なブロックに封じ込めた上で、
　　｛ｉｎｔ　ｔｍｐ；ｔｍｐ＝ｓｕｂ（）；＿ｐｒｏｂｅ（＊−＊，肯ａｉｎ”，行ａｍｐｌｅ．ｃ”，８）；ｒｅｔｕｒｎ（ｔｍｐ）；｝
のように、ｒｅｔｕｒｎ文の引数を一旦一時変数に退避する処理と、ｒｅｔｕｒｎ文との間にプログラムの実行追跡処理とを埋め込む。
　「モジュールの先頭」の場合と同様、こうして埋め込まれた「＿ｐｒｏｂｅ」というモジュールには、それが埋め込まれた「プログラム中の論理的な位置（この場合はモジュールの実行終了を示す「−」）」、「モジュールの名前（この場合は「ｍａｉｎ」）」、「物理的な位置（この場合は「ｓａｍｐｌｅ．ｃというファイルの８行目」）」という情報が引数で渡される。
　尚、ｒｅｔｕｒｎ文の引数を一旦一時変数に退避しているのは、ｒｅｔｕｒｎ文の引数が関数参照である場合にプログラムの実行追跡結果が
　　ｍａｉｎ：ｓａｍｐｌｅ．ｃの２行目［モジュールの実行開始］
　　ｍａｉｎ：ｓａｍｐｌｅ．ｃの５行目
　　ｍａｉｎ：ｓａｍｐｌｅ．ｃの８行目［モジュールの実行終了］
　　　　　　　　　ｓｕｂ：ｓａｍｐｌｅ．ｃの１３行目［モジュールの実行開始］
　　　　　　　　　ｓｕｂ：ｓａｍｐｌｅ．ｃの１４行目
　　　　　　　　　ｓｕｂ：ｓａｍｐｌｅ．ｃの１５行目［モジュールの実行終了］
のように見かけ上おかしくなるのを回避する為である。
　ちなみに、この実施例１２の方法では
　　ｍａｉｎ：ｓａｍｐｌｅ．ｃの２行目［モジュールの実行開始］
　　ｍａｉｎ：ｓａｍｐｌｅ．ｃの５行目
　　　　　　　　　ｓｕｂ：ｓａｍｐｌｅ．ｃの１３行目［モジュールの実行開始］
　　　　　　　　　ｓｕｂ：ｓａｍｐｌｅ．ｃの１４行目
　　　　　　　　　ｓｕｂ：ｓａｍｐｌｅ．ｃの１５行目［モジュールの実行終了］
　　ｍａｉｎ：ｓａｍｐｌｅ．ｃの８行目［モジュールの実行終了］
のように実際の実行順序に従って正しく報告される。
　同様に図７７において６行目の
　　ｉ＝１；
が「普通の実行文の所」という条件に該当するが、この行に対して実行追跡処理埋込み手段１２０１は、
　　｛　｝　ｉ＝１；
のように実行文の直前に「｛」と「｝」で囲まれた局所的なブロックを作った上で、
　　｛＿ｐｒｏｂｅ（＊＝＊，”ｍａｉｎ”，”ｓａｍｐｌｅ．ｃ”，６）；｝　ｉ＝１；
のように「｛」と「｝」の間にプログラムの実行追跡処理を埋め込む。
　「モジュールの先頭」の場合と同様に、こうして埋め込まれた「＿ｐｒｏｂｅ」というモジュールには、それが埋め込まれた「プログラム中の論理的な位置（この場合はモジュールの実行途中を示す「＝」）」、「モジュールの名前（この場合は「ｍａｉｎ」）」、「物理的な位置（この場合は「ｓａｍｐｌｅ．ｃというファイルの６行目」）」という情報が引数で渡される。
　【０１３９】
　この実施例１２では、入力となるプログラミング言語としてＣ言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語（例えば「Ａｄａ」）であっても構わない。
　同様に、この実施例１２では、全ての実行文を対象とする方法を紹介したが、これは「モジュールの開始と終了」だけを対象とするものであっても構わない。
　【０１４０】
　次に、従来例と比較して、この実施例１２の優れている点について説明する。この実施例１２と同じ機能を実現する従来の方法としては次のものが考えられる。
　【０１４１】
　その方法とは、プログラミング言語記述の任意の場所にプログラムの実行追跡処理を手作業で埋め込むというものである。この方法はコンピュータの歴史が始まった頃から行われているが、実行追跡処理を埋め込むのに膨大な時間が必要（作業コストの問題）となるだけでなく、経験年数などによって作業効率のばらつきが大きい（属人性の問題）、ミスが入り込みやすい（作業品質の問題）、プログラミング言語記述を修正する度に実行追跡処理を埋め込み直す必要があるなど多くの問題がある。
　【０１４２】
　これに対しこの実施例１２を使用した場合、プログラムの実行追跡処理がプログラミング言語記述６０１中に自動的に埋め込まれるので、同様な作業を人間が行った場合に比べ、実行追跡処理の埋め込みに要する時間を桁違いに短縮（数日に対して数秒）できるだけでなく、埋め込み漏れ、埋め込みミスといった事が全く無くなるという効果がある。
　更に、
　（１）入力となるプログラミング言語記述を読み込む。
　（２）プログラミング言語記述に実行追跡処理を埋め込む。
　（３）加工したプログラミング言語記述を別のファイルに出力する。
　（４）出力されたファイルをコンパイルして実行モジュールを生成する。
という手順を踏めば、
オリジナルのプログラミング言語記述６０１を一切変更せずに実行追跡処理を埋め込んだ実行モジュールを生成できるので、プログラミング言語記述６０１に直接実行追跡処理を埋め込むことによる弊害、
　すなわち、
　・プログラミング言語記述が汚くなる（可読性、保守性が低下する）。
　・実行追跡処理を埋め込む前の状態に戻せない。
といった問題を完全に解消できるという効果がある。
　【０１４３】
　以上のようにこの実施例１２によれば、図７５に示すように、プログラミング言語記述６０１を入力にする字句解析手段６０２、構文解析手段６０３、および実行追跡処理埋込み手段１２０１を設けることにより、プログラミング言語記述６０１にプログラムの実行追跡処理を自動的に埋め込むことができるので、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
　【０１４４】
実施例１３．
　図８０は実施例１３のプログラム生産支援装置を示す構成図である。図８０において、１０１は各機能の階層構造と種別が記述された「仕様記述」、１０６は前記実施例１によって自動生成された「機能構成図」、１３０１は前記実施例２によって自動生成された「疑似言語記述のひな形」、３０１はモジュールのインターフェース仕様と処理フローが記述された「疑似言語記述」、３０７は前記実施例３によって自動生成された「デザインレビュー用資料」、４０３は、前記実施例４によって自動生成された「木構造チャート」、５０３は前記実施例５によって自動生成された「プログラミング言語記述のひな形」、６０１は特定のプログラミング言語で記述された「プログラミング言語記述」、７０３は前記実施例７によって自動生成された「木構造チャート」、８０５は前記実施例８によって自動生成された「モジュール仕様書」、９０３は前記実施例９によって自動生成された「モジュール構成図」、１００４は前記実施例１０によって自動生成された「シンボル一覧表」、１１０２は前記実施例１１によって自動出力された「警告メッセージ」、１２０２は前記実施例１２によって自動生成された「加工されたプログラミング言語記述」である。
　【０１４５】
　この実施例１３のプログラム生産支援装置は、本発明の第１〜１２の実施例によって構成されているので、それぞれの部分の動作は第１〜１２の実施例で説明した通りである。
　【０１４６】
　この実施例１３では前記実施例１〜１２を全て組み合わせたものを紹介したが、この発明は前記実施例１〜１２を任意に組み合わせたものであっても適用できる。
　【０１４７】
　次に、従来例と比較して、この実施例１３の優れている点について説明する。この実施例１３と同じ機能を実現する従来の方法としては次のものが考えられる。
　【０１４８】
　その方法とは、
　（１）プログラムの機能構成を決定する。
　（２）ワープロなどを用いてそれらの情報を手作業で機能構成図の形にまとめる。
　（３）機能構成図を見ながら手作業でモジュール分割を行う。
　（４）モジュールのインターフェース仕様と処理フローを決定する。
　（５）ワープロなどを用いてそれらの情報を手作業で仕様書の形にまとめる。
　（６）仕様書を見ながらプログラミング言語記述を手作業でコーディングする。
　（７）プログラミング言語記述を見ながら必要な図表を手作業で作成する。
　（８）プログラムの実行追跡処理を手作業で埋め込む。
　（９）プログラムを実行する。
というものである。
　この方法は現在一般的に行われているものであり現実的ではあるが、手作業が主体である以上は、それぞれの作業に膨大な時間が必要（作業コストの問題）となるだけでなく、作業のやり方に個人差が出る（属人性の問題）、ミスが入り込みやすい（作業品質の問題）など多くの問題がある。
　個々の作業を人手で行っている限り本質的にこれらの問題を解決することは不可能である。
　【０１４９】
　これに対しこの実施例１３を使用した場合、事務的な作業（例えば機能構成図の作成など）が全て自動的に行われるので、同じ作業を人間が手作業で行う場合に比べ、作業効率および品質が格段に高くなる（理論的にミスは発生しない）という効果がある。
　更に、前工程で作成されレビューされた情報（仕様記述、疑似言語記述など）を後工程の入力（ひな形）として流用できるので、前工程を担当した作業者の意図を後工程の作業者に正確に伝えられるという効果がある。
　また、それぞれの段階で利用される入力は単なるテキストであり、一般的なテキスト・エディタを用いて作成できるので、新たに専用エディタを開発して提供する必要がないばかりか、ユーザが自分の使い慣れたエディタを用いて仕様記述を作成できるという効果がある。これはこの実施例１３が、低コストで実現かつ運用可能であることを意味している。
　【０１５０】
　以上のようにこの実施例１３によれば、前記実施例１〜１２のいずれか２つ以上の組み合わせを利用することにより、プログラム生産における事務的な処理を自動化できると共に、前工程で作成されレビューされた情報を後工程の入力として流用できるので、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
　【０１５１】
　【発明の効果】
　以上のように、本発明に係るプログラム生産支援装置は、自然言語と各機能の階層構造を示す記号
とで記述された
述を
　【０１５２】
　
さらに、
、
を
し、
場合には
　【０１５３】
　また、本発明に係るプログラム生産支援装置は、自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有しているので、汎用のテキストエディタ等を用いてデータの入力や編集を可能にすると共に、必要な資料、図またはプログラミング言語記述を生成することができる。
　また、この発明に係るプログラム生産支援装置は、自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、上記生成手段が、構文解析結果をもとに上記仕様記述部に記述されたインターフェース仕様を抽出するインターエース仕様抽出手段と、上記構文解析結果をもとに上記ロジック記述部に記述されたモジュールの定義・参照を抽出するモジュール定義・参照抽出手段と、上記抽出されたインターフェース仕様及びモジュールの定義・参照をもとに上記疑似言語記述に対応したデザインレビュー用資料を生成するデザインレビュー用資料生成手段とを有しているので、デザインレビュー用資料の作成に要する時間を大幅に短縮できると共に、デザインレビュー用資料の品質を格段に高めることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
　【０１５４】
　また、生成手段が、構文解析結果をもとに自然言語で記述されている処理説明および制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語記述に対応した木構造チャートを生成する木構造チャート生成手段とを有する場合には、木構造チャートの作成に要する時間を大幅に短縮できると共に、木構造チャートの品質を格段に高めることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
　【０１５５】
　さらに、生成手段が、構文解析結果をもとに自然言語で記述されている処理説明及び制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語の制御構造をそれに対応するプログラミング言語の制御構造に変換する制御構造変換手段と、上記変換された木構造をもとに疑似言語の処理説明をプログラミング言語のコメントに変換する手段とを有する場合には、前工程（設計）で十分にデザインレビューされた情報（疑似言語記述）を後工程（コーディング）の入力（プログラミング言語記述のひな形）として流用できるので、設計者の意図をプログラマに正確に伝えることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
　【０１５６】
　また、本発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述を生成する生成手段とを有しているので、汎用のテキストエディタ等を用いてデータの入力や編集を可能にすると共に、必要な疑似言語記述を生成することができる。
　【０１５７】
　また、プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有するものであって、生成手段が、構文解析結果をもとにプログラムの制御構造及びそれに付随するコメントを抽出する制御構造抽出手段と、上記制御構造をもとにプログラミング言語の制御構造を自然言語及び上記プログラミング言語に準じた制御構造で記述された疑似言語の制御構造に変換する制御構造変換手段と、上記制御構造をもとに上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段とを有する場合には、プログラミング言語記述からモジュールのインターフェース仕様に関する情報を自動的に抽出できるので、実際に動作しているプログラムの仕様を容易かつ正確に把握することが可能となり、結果としてプログラム生産および保守の高品質化に大きく寄与することができる。
　【０１５８】
　また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、構文解析結果をもとにプログラミング言語記述のヘッダーコメントに記述されたインターフェース仕様を抽出するインターフェース仕様抽出手段と、構文解析結果をもとに上記プログラミング言語記述のモジュールの定義・参照を木構造に変換して記憶するモジュール定義・参照抽出手段と、ヘッダーコメント中のモジュール欄の名称が実際のモジュール名に一致しているかを照合するモジュール名照合手段と、上記インターフェース仕様及び上記木構造をもとにプログラミング言語記述に対応したモジュール仕様書を生成するモジュール仕様生成手段とを有しているので、プログラミング言語記述から実際のモジュール定義に正確に対応したモジュール仕様書を自動生成することができ、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
　【０１５９】
　また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、構文解析結果をもとにシンボルの定義情報を記憶するシンボル定義抽出手段と、上記シンボルの定義情報をシンボルが定義された順に並び換えるシンボル定義並び換え手段と、上記シンボルの定義情報をもとにプログラミング言語記述に対応したシンボル一覧表を生成するシンボル一覧表生成手段とを有しているので、プログラミング言語記述から実用的なシンボル一覧表を自動生成することができ、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
【図面の簡単な説明】
　【図１】　実施例１のプログラム生産支援装置を示す構成図である。
　【図２】　実施例１のフローチャートである。
　【図３】　実施例１の仕様記述（入力）の一例を示す図である。
　【図４】　実施例１の仕様記述（入力）の一例の続きを示す図である。
　【図５】　実施例１の機能構成図（出力）の一例を示す図である。
　【図６】　実施例１の機能構成図（出力）の一例の続きを示す図である。
　【図７】　実施例１の木構造の一例を示す図である。
　【図８】　実施例２のプログラム生産支援装置を示す構成図である。
　【図９】　実施例２のフローチャートである。
　【図１０】　実施例２のディレクトリ構成（出力）の一例を示す図である。
　【図１１】　実施例２の疑似言語記述のひな形（出力）の一例を示す図である。
　【図１２】　実施例３のプログラム生産支援装置を示す構成図である。
　【図１３】　実施例３のフローチャートである。
　【図１４】　実施例３の疑似言語記述（入力）の一例を示す図である。
　【図１５】　実施例３の疑似言語記述（入力）の一例の続きを示す図である。
　【図１６】　実施例３のデザインレビュー用資料（出力）の一例を示す図である。
　【図１７】　実施例４のプログラム生産支援装置を示す構成図である。
　【図１８】　実施例４のフローチャートである。
　【図１９】　実施例４の木構造チャート（出力）の一例を示す図である。
　【図２０】　実施例４の木構造の一例を示す図である。
　【図２１】　実施例４の木構造チャートの一例を示す図である。
　【図２２】　実施例４の木構造の一例を示す図である。
　【図２３】　実施例４の木構造チャートの一例を示す図である。
　【図２４】　実施例５のプログラム生産支援装置を示す構成図である。
　【図２５】　実施例５のフローチャートである。
　【図２６】　実施例５のプログラミング言語記述のひな形（出力）の一例を示す図である。
　【図２７】　実施例５のプログラミング言語記述のひな形（出力）の一例の続きを示す図である。
　【図２８】　実施例５の木構造の一例を示す図である。
　【図２９】　実施例６のプログラム生産支援装置を示す構成図である。
　【図３０】　実施例６のフローチャートである。
　【図３１】　実施例６のプログラミング言語記述（入力）の一例を示す図である。
　【図３２】　図３１の続きを示す図である。
　【図３３】　実施例６の疑似言語記述（出力）の一例を示す図である。
　【図３４】　図３４の続きを示す図である。
　【図３５】　実施例６の木構造の一例を示す図である。
　【図３６】　実施例６の木構造の一例を示す図である。
　【図３７】　実施例７のプログラム生産支援装置を示す構成図である。
　【図３８】　実施例７のフローチャートである。
　【図３９】　実施例７のプログラミング言語記述（入力）の一例を示す図である。
　【図４０】　実施例７のプログラミング言語記述（入力）の一例の続きを示す図である。
　【図４１】　実施例７の木構造チャート（出力）の一例を示す図である。
　【図４２】　実施例７の木構造チャート（出力）の一例を示す図である。
　【図４３】　実施例７の木構造チャート（出力）の一例を示す図である。
　【図４４】　実施例７の木構造の一例を示す図である。
　【図４５】　実施例７の木構造チャートの一例を示す図である。
　【図４６】　実施例７の木構造の一例を示す図である。
　【図４７】　実施例７の木構造チャートの一例を示す図である。
　【図４８】　実施例７の木構造チャートの一例を示す図である。
　【図４９】　実施例８のプログラム生産支援装置を示す構成図である。
　【図５０】　実施例８のフローチャートである。
　【図５１】　実施例８のプログラミング言語記述（入力）の一例を示す図である。
　【図５２】　図５１の続きを示す図である。
　【図５３】　実施例８のモジュール仕様書（出力）の一例を示す図である。
　【図５４】　実施例９のプログラム生産支援装置を示す構成図である。
　【図５５】　実施例９のフローチャートである。
　【図５６】　実施例９のプログラミング言語記述（入力）の一例を示す図である。
　【図５７】　図５６の続きを示す図である。
　【図５８】　従来のモジュール構成図（出力）の一例を示す図である。
　【図５９】　実施例９のモジュール構成図（出力）の一例を示す図である。
　【図６０】　実施例９の木構造の一例を示す図である。
　【図６１】　実施例９の木構造の一例を示す図である。
　【図６２】　実施例１０のプログラム生産支援装置を示す構成図である。
　【図６３】　実施例１０のフローチャートである。
　【図６４】　実施例１０のプログラミング言語記述（入力）の一例を示す図である。
　【図６５】　図６４の続きを示す図である。
　【図６６】　図６５の続きを示す図である。
　【図６７】　図６６の続きを示す図である。
　【図６８】　従来のシンボル一覧表（出力）の一例を示す図である。
　【図６９】　実施例１０のシンボル一覧表（出力）の一例を示す図である。
　【図７０】　実施例１１のプログラム生産支援装置を示すブロック図である。
　【図７１】　実施例１１のフローチャートである。
　【図７２】　実施例１１のプログラミング言語記述（入力）の一例を示す図である。
　【図７３】　図７２の続きを示す図である。
　【図７４】　実施例１１の警告メッセージ（出力）の一例を示す図である。
　【図７５】　実施例１２のプログラム生産支援装置を示す構成図である。
　【図７６】　実施例１２のフローチャートである。
　【図７７】　実施例１２のプログラミング言語記述（入力）の一例を示す図である。
　【図７８】　実施例１２の加工されたプログラミング言語記述（出力）の一例を示す図である。
　【図７９】　実施例１２の実行結果（出力）の一例を示す図である。
　【図８０】　実施例１３のプログラム生産支援装置を示す構成図である。
　【図８１】　実施例１〜１３の前提となるハードウェア構成を示す図である。
　【図８２】　従来のプログラム生産支援装置を示す構成図である。
　【図８３】　従来のフローチャートである。
　【符号の説明】　
　１０１　仕様記述、１０２　字句解析手段、１０３　構文解析手段、１０４　階層構造抽出手段、１０５　機能構成図生成手段、１０６　機能構成図、２０１　ディレクトリ生成手段、２０２　ファイル生成手段、２０３　モジュール生成手段、２０４　外部記憶、２０５　ディレクトリ、２０６　ファイル１、２０７　ファイル２、２０８　ファイルＮ、２０９　モジュール１、２１０　モジュール２、２１１　モジュールＮ、３０１　疑似言語記述、３０２　字句解析手段、３０３　構文解析手段、３０４　インターフェース仕様抽出手段、３０５　モジュール定義・参照抽出手段、３０６　デザインレビュー用資料生成手段、３０７　デザインレビュー用資料、４０１　制御構造抽出手段、４０２　木構造チャート生成手段、４０３　木構造チャート、５０１　制御構造変換手段、５０２　処理説明→コメント変換手段、５０３　プログラミング言語記述のひな形、６０１　プログラミング言語記述、６０２　字句解析手段、６０３　構文解析手段、６０４　制御構造抽出手段、６０５　制御構造変換手段、６０６　コメント→処理説明変換手段、７０１　不要情報割愛手段、７０２　木構造チャート生成手段、７０３　木構造チャート、８０１　インターフェース仕様抽出手段、８０２　モジュール定義・参照抽出手段、８０３　モジュール名照合手段、８０４　モジュール仕様書生成手段、８０５　モジュール仕様書、９０１　同一構造割愛手段、９０２　モジュール構成図生成手段、９０３　モジュール構成図、１００１　シンボル定義抽出手段、１００２　シンボル定義並換え手段、１００３　シンボル一覧表生成手段、１００４　シンボル一覧表、１１０１　特定パターンの検出手段、１１０２　警告メッセージ、１２０１　実行追跡処理埋込み手段、１２０２　加工されたプログラミング言語記述、１３０１　疑似言語記述のひな形、１４０１　キーボード、１４０２　ディスプレイ、１４０３　計算機、１４０４　外部記憶、１４０５　プリンタ、１５０１　データ入力手段、１５０２　データ定義部、１５０３　表示部、１５０４　表示手段、１５０５　ブロックチャート編集部、１５０６　ブロックエディタ部、１５０７　ソースコード出力部、１５０８　ソースコード記録手段。