• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 一部申し立て 5項1、2号及び6項 請求の範囲の記載不備  G06F
審判 一部申し立て 特36 条4項詳細な説明の記載不備  G06F
審判 一部申し立て 2項進歩性  G06F
管理番号 1097907
異議申立番号 異議2001-71558  
総通号数 55 
発行国 日本国特許庁(JP) 
公報種別 特許決定公報 
発行日 1996-04-12 
種別 異議の決定 
異議申立日 2001-05-28 
確定日 2004-03-05 
異議申立件数
訂正明細書 有 
事件の表示 特許第3112623号「プログラム生産支援装置」の請求項1、3、5ないし9、11、13、14に係る特許に対する特許異議の申立てについて、次のとおり決定する。 
結論 訂正を認める。 特許第3112623号の請求項1、3、5ないし8に係る特許を取り消す。 
理由 第1 手続・経緯
(1)出 願 日:平成 6年 9月21日
(2)登 録 日:平成12年 9月22日
(3)公報発行日:平成12年11月27日
(4)異議申立(1件)
異議申立日:平成13年5月28日
申立請求項:請求項1,3,5〜9,11,13〜14
異議申立人:富士通株式会社
(5)取消理由通知書:平成13年11月19日(起案日)
(6)訂正請求書:平成14年1月29日(提出日)
(7)取消理由通知書:平成15年6月16日(起案日)
(8)訂正請求書:平成15年8月26日(提出日)
(9)訂正拒絶理由通知書:平成15年9月10日(起案日)
(10)手続補正書:平成15年11月21日(提出日)


第2 訂正の適否
1.訂正請求書の補正の適否
(1)補正の内容
平成15年8月26日付訂正請求書に対する、平成15年11月21日付の補正は、次のとおりのものである。

「(1) 1.補正前の訂正請求書の訂正事項aを削除するために、補正前の訂正請求書第2頁第17行目〜第4頁第1行日の「○1(審決注:○の中に数字が記載されているものを○数字で代用した。以下、同様に代用する。)訂正事項a ・・・訂正する。」の記載、および同第9頁第5行目〜第10頁第5行目の「○1上記訂正事項aについては、・・・適合するものである。」の記載を削除する。
2.補正前の訂正請求書の訂正事項aを削除したことに伴い、補正前の全文訂正明細書における特許請求の範囲の請求項1中の「自然言語と各機能の階層構造を示す記号とがテキストで記述された書籍の目次に準じた形式の仕様記述を読み込みその内容を字句に分解する字句解析手段と、」を、「自然言語と各機能の階層構造を示す記号とで記述された仕様記述を読み込みその内容を字句に分解する字句解析手段と、」と訂正し、同請求項1中の「疑似言語記述のひな型を生成する生成手段と」を、「疑似言語記述を生成する生成手段と」と訂正する。
そして、補正前の全文訂正明細書の段落番号【0006】第6行目、同段落番号【0159】第3行目の「記号とがテキストで記述された書籍の目次に準じた形式の」をそれぞれ「記号とで記述された」と訂正し、同段落番号【0006】第10行〜第11行目、同段落番号【0151】第8行目の「疑似言語記述のひな型を生成する生成手段と」をそれぞれ「疑似言語記述を生成する生成手段と」と訂正する。
さらに、補正前の全文訂正明細書における特許請求の範囲の請求項2中の「自然言語と各機能の階層構造を示す記号とで記述された仕様記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された仕様記述の構文解析を行う構文解析手段と、構文解析結果をもとに各機能の階層構造を抽出する階層構造抽出手段と、上記抽出された階層構造をもとに上記仕様記述に対応した図または自然言語及びプログラミング言語に準じた制御構造で記述された疑似言語記述を生成する生成手段とを有し、上記仕様記述には、種別を示す記号が記述されており、上記生成手段は、」を「仕様記述には、種別を示す記号が記述されており、生成手段は、」と、同請求項2中の「プログラム生産支援装置。」を「請求項1記載のプログラム生産支援装置。」とそれぞれ訂正する。
そして、補正前の全文訂正明細書の段落番号【0007】第1行目〜第7行目、同段落番号【0152】第1行目〜第7行目の「また、この発明に係るプログラム生産支援装置は、自然言語と各機能の階層構造を示す記号とで記述された仕様記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された仕様記述の構文解析を行う構文解析手段と、構文解析結果をもとに各機能の階層構造を抽出する階層構造抽出手段と、上記抽出された階層構造をもとに上記仕様記述に対応した図または自然言語及びプログラミング言語に準じた制御構造で記述された疑似言語記述を生成する生成手段とを有し、上記仕様記述には、種別を示す記号が記述されており、上記生成手段が、」を「さらに、仕様記述に、種別を示す記号を記述し、生成手段が、」と、同段落番号【0007】第9行目の「生成するものである。」を「生成するようにしてもよい。」と、同段落番号【0152】第9行目の「生成するので、」を「生成する場合には、」とそれぞれ訂正する。
(2)補正前の訂正請求書の訂正事項aを削除したことに伴い、補正前の訂正請求書の訂正事項bを訂正事項aとするために、補正前の訂正請求書第4頁第2行目の「○2訂正事項b」を「○1訂正事項a」と、同第10頁第6行目の「○2上記訂正事項b」を「○1 上記訂正事項a」と、同第10頁第15行日、同第10頁第28行目の「訂正事項b」を「訂正事項a」とそれぞれ訂正する。
(3)補正前の訂正請求書の訂正事項aを削除したことに伴い、補正前の訂正請求書の訂正事項cを訂正事項bとするために、補正前の訂正請求書第5頁第13行目の「○3訂正事項c」を「○2訂正事項b」と、同第11頁第1行目の「○3上記訂正事項c」を「○2上記訂正事項b」と、同第11頁第13行目、同第11頁第28行目の「訂正事項c」を「訂正事項b」とそれぞれ訂正する。
(4)補正前の訂正請求書の訂正事項aを削除したことに伴い、補正前の訂正請求書の訂正事項dを訂正事項cとするために、補正前の訂正請求書第5頁第27行目の「○4訂正事項d」を「○3訂正事項c」と、同第12頁第1行目の「○4上記訂正事項d」を「○3 上記訂正事項c」と、同第12頁第15行目、同第13頁第1行目の「訂正事項d」を「訂正事項c」とそれぞれ訂正する。
(5)補正前の訂正請求書の訂正事項aを削除したことに伴い、補正前の訂正請求書の訂正事項eを訂正事項dとするために、補正前の訂正請求書第6頁第22行目の「○5訂正事項e」を「○4訂正事項d」と、同第13頁第3行目の「○5上記訂正事項e」を「○4上記訂正事項d」と、同頁第7行目 の「訂正事項e」を「訂正事項d」とそれぞれ訂正する。」

2.補正の適否
前記補正は、平成15年8月26日付訂正請求書中の、訂正事項aを削除するとともに、当該削除に伴い、同訂正事項b〜eを、訂正事項a〜dとして繰り上げるためのものであるから、前記平成15年8月26日付の訂正請求書の要旨を変更するものではない。
したがって、平成15年11月21日付の手続補正書による平成15年8月26日付訂正請求書の補正は適法なものである。

3.訂正の要旨
前記1.のとおり補正された平成15年8月26日付訂正請求書による訂正は、前記手続補正書の「7.請求の理由」,「(3)訂正の要旨」に記載の次のとおりのものである。

「○1訂正事項a
特許請求の範囲の請求項3中の「自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、」を特許請求の範囲の減縮を目的として、「自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、」と訂正する。
これに伴ない、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を目的として、明細書の段落番号【0008】第2行目、同段落番号【0161】第2行目の「制御構造で記述された疑似言語記述」を「制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述」とそれぞれ訂正する。
さらに、特許請求の範囲の請求項3の訂正をするに伴ない、訂正前の請求項3を引用する特許請求の範囲の請求項4を独立形式とするため、明瞭でない記載の釈明を目的として、同請求項4中の「疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、生成手段は、」を「自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、上記生成手段は、」と、同請求項4中の「請求項3記載のプログラム生産支援装置。」を「プログラム生産支援装置。」とそれぞれ訂正する。
これに伴ない、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を目的として、明細書の段落番号【0008】第6行目〜第7行目、同段落番号【0161】第8行目〜第9行目の「また、疑似言語記述に、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とを記述し、生成手段が、」を「また、この発明に係るプログラム生産支援装置は、自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、上記生成手段が、」と、同段落番号【0008】第13行目の「有するようにしてもよい。」を「有するものである。」と、同段落番号【0161】第15行目の「有する場合には、」を「有しているので、」とそれぞれ訂正する。
○2訂正事項b
特許請求の範囲の請求項7中の「構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段と」を特許請求の範囲の減縮を目的として、「構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述を生成する生成手段と」と訂正する。
これに伴ない、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を目的として、明細書の段落番号【0011】第5行目、同段落番号【0164】第4行目〜第5行目の「図、表または言語記述」を「自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述」と、同段落番号【0164】第6行目〜第7行目の「図、表または言語記述」を「疑似言語記述」とそれぞれ訂正する。
○3訂正事項c
特許請求の範囲の請求項8中の「生成手段は、」、「上記プログラミング言語の文およびコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段と」を明りょうでない記載の釈明を目的として、それぞれ「プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有するものであって、生成手段が、」、「上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段と」と訂正する。
これに伴ない、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を目的として、明細書の段落番号【0012】第1行目、同段落番号【0165】第1行目の「生成手段が、」を「プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有するものであって、生成手段が、」とそれぞれ訂正し、同段落番号【0012】第5行目〜第6行目、同段落番号【0165】第5行目〜第6行目の「上記プログラミング言語の文およびコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段」を「上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段」とそれぞれ訂正する。
○4訂正事項d
特許請求の範囲の請求項9-14において、特許請求の範囲の減縮を目的として、訂正前の請求項9、11、13、14を削除し、さらに、特許請求の範囲の請求項7の訂正をするに伴ない、明瞭でない記載の釈明を目的として、訂正前の請求項7を引用する特許請求の範囲の訂正前の請求項10、12を独立形式として、以下項数を繰り上げ、
「【請求項9】 特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段は、構文解析結果をもとにプログラミング言語記述のへツダーコメントに記述されたインターフェース仕様を抽出するインターフェース仕様抽出手段と、構文解析結果をもとに上記プログラミング言語記述のモジュールの定義・参照を木構造に変換して記憶するモジュール定義・参照抽出手段と、ヘッダーコメント中のモジュール欄の名称が実際のモジュール名に一致しているかを照合するモジュール名照合手段と、上記インターフェース仕様及び上記木構造をもとにプログラミング言語記述に対応したモジュール仕様書を生成するモジュール仕様生成手段とを有することを特徴とするプログラム生産支援装置。
【請求項10】 特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段は、構文解析結果をもとにシンボルの定義情報を記憶するシンボル定義抽出手段と、上記シンボルの定義情報をシンボルが定義された順に並び換えるシンボル定義並び換え手段と、上記シンボルの定義情報をもとにプログラミング言語記述に対応したシンボル一覧表を生成するシンボル一覧表生成手段とを有することを特徴とするプログラム生産支援装置。」と訂正する。(クレーム対応表参照)
これに伴ない、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を目的として、明細書の段落番号【0013】、同段落番号【0015】、同段落番号【0017】、同段落番号【0018】、同段落番号【0025】、同段落番号【0027】、同段落番号【0029】、同段落番号【0030】、同段落番号【0166】、同段落番号【0168】、同段落番号【0170】、同段落番号【0171】の全ての記載をそれぞれ削除し、さらに、同段落番号【0014】第1行目、同段落番号【0167】第1行目の「また、生成手段が、」を「また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、」と、同段落番号【0014】第8行目の「有するようにしてもよい。」を「有するものである。」と、同段落番号【0167】第8行目の「有する場合には、」を「有しているので、」と、同段落番号【0016】第1行目、同段落番号【0169】第1行目の「また、生成手段が、」を「また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、」と、同段落番号【0016】第5行目の「有するようにしてもよい。」を「有するものである。」と、同段落番号【0169】第5行目の「有する場合には、」を「有しているので、」とそれぞれ訂正する。」

4.訂正の目的の適否、新規事項の有無及び拡張・変更の存否
(1)訂正事項a
(訂正の目的)
訂正事項a-1:
特許請求の範囲の請求項3中の「自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、」を「自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、」とする訂正は、特許請求の範囲の減縮を行うものである。

訂正事項a-2:
明細書の段落番号【0008】第2行目、同段落番号【0161】第2行目の「制御構造で記述された疑似言語記述」を「制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述」とする訂正は、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を行う訂正である。

訂正事項a-3:
特許請求の範囲の請求項4中の「疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、生成手段は、」を「自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、上記生成手段は、」と、
同請求項4中の「請求項3記載のプログラム生産支援装置。」を「プログラム生産支援装置。」と、
する訂正は、訂正前の請求項3を引用する特許請求の範囲の請求項4を独立形式とするためのもので、明りょうでない記載の釈明を行う訂正である。

訂正事項a-4:
明細書の段落番号【0008】第6行目〜第7行目、同段落番号【0161】第8行目〜第9行目の「また、疑似言語記述に、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とを記述し、生成手段が、」を「また、この発明に係るプログラム生産支援装置は、自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、上記生成手段が、」と、同段落番号【0008】第13行目の「有するようにしてもよい。」を「有するものである。」と、同段落番号【0161】第15行目の「有する場合には、」を「有しているので、」とする訂正は、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を行う訂正である。

(新規事項の有無)
次に、訂正事項a-1ないし訂正事項a-4について、願書に添付した明細書又は図面に記載した事項の範囲内のものかどうかを検討する。
訂正事項a-1ないしa-4は、本件明細書の発明の詳細な説明の実施例3に係る記載等に基づくものであるから、実施例3の記載をみると、
「実施例3では、モジュールのインターフェース仕様と処理フローを記述する手段として、C言語に準じた疑似言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語(例えば「Ada」)に準じたものであっても構わない。」(【0056】)、
「(注1)疑似言語とは、プログラミング言語の制御構造と自然言語の文章が混在する設計用の仮想言語を意味する。」(【0056】)
と記載されている。したがって、本件明細書の疑似言語は、プログラミング言語の制御構造と自然言語の文章が混在する設計用の仮想言語である。一般にプログラミング言語も自然言語もテキストで記述され、汎用のテキストエディタを用いて入力及び編集されるものであるし、本件発明の目的の一つは「広く一般に普及している汎用のテキスト・エディタを用いて、データの入力および編集を可能にする」(【0005】)ものであるから、訂正事項a-1ないしa-4は、願書に添付した明細書又は図面に記載した事項の範囲内のものである。

(拡張・変更の存否)
前記a-1〜4の訂正は、願書に添付した明細書に記載した発明が解決しようとする課題ないし発明の効果を本質的に変更するものではなく、実質上特許請求の範囲を拡張又は変更するものではない。

(2)訂正事項b
(訂正の目的)
訂正事項b-1:
特許請求の範囲の請求項7中の「構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段と」を「構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述を生成する生成手段と」とする訂正は、特許請求の範囲の減縮を行う訂正である。

訂正事項b-2:
明細書の段落番号【0011】第5行目、同段落番号【0164】第4行目〜第5行目の「図、表または言語記述」を「自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述」と、同段落番号【0164】第6行目〜第7行目の「図、表または言語記述」を「疑似言語記述」とする訂正は、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図るため、明りようでない記載の釈明を行う訂正である。

(新規事項の有無)
次に、訂正事項b-1,2について、願書に添付した明細書又は図面に記載した事項の範囲内のものかどうかを検討する。
本件明細書に記載の疑似言語は、前記(2)で述べたとおりテキストで表現されたものであるから、訂正事項b-1は、願書に添付した明細書又は図面に記載した事項の範囲内のものである。訂正事項b-2は、訂正事項b-1による訂正に伴う、不明りょうな記載の釈明を行うものであるから、これらも願書に添付した明細書又は図面に記載した事項の範囲内のものである。

(拡張・変更の存否)
前記b-1〜2の訂正は、願書に添付した明細書に記載した発明が解決しようとする課題ないし発明の効果を本質的に変更するものではなく、実質上特許請求の範囲を拡張又は変更するものではない。

(3)訂正事項c
(訂正の目的)
請求項8に対する訂正、及びこれと整合を図るためにする、発明の詳細な説明に対する訂正は、いずれも明りょうでない記載の釈明を目的としてするものである。

(新規事項の有無)
請求項8の訂正された「プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有する」ことは、図31ないし図34と本件明細書の【0089】の記載等から読み取れる事項である。
また、請求項8の訂正された「上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する」ことも、図31ないし図34と本件明細書の【0089】の記載等から読み取れる事項であり、両者とも、プログラム言語のモジュール内のコメント、条件文中の条件式に対するコメントをそれぞれ処理説明に変換し、前記モジュール内のコメントに対応する処理説明はモジュール内のコメントの位置に、前記条件式に対するコメントの処理説明は条件式の位置に配置することを示していることは明らかである。
さらに、前記発明の詳細な説明に対する訂正は、請求項8の訂正に対応して、発明の詳細な説明の明りようでない記載の釈明を目的とするものである。
したがって、訂正事項cは、願書に添付した明細書又は図面に記載した事項の範囲内のものである。

(拡張・変更の存否)
前記訂正事項cは、願書に添付した明細書に記載した発明が解決しようとする課題ないし発明の効果を本質的に変更するものではなく、実質上特許請求の範囲を拡張又は変更するものではない。

(4)訂正事項d
(訂正の目的)
訂正事項d-1:
訂正前の請求項9、11、13、14を削除する訂正は、特許請求の範囲の減縮を行うものである。

訂正事項d-2:
「【請求項9】 特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段は、構文解析結果をもとにプログラミング言語記述のへッダーコメントに記述されたインターフェース仕様を抽出するインターフェース仕様抽出手段と、構文解析結果をもとに上記プログラミング言語記述のモジュールの定義・参照を木構造に変換して記憶するモジュール定義・参照抽出手段と、ヘッダーコメント中のモジュール欄の名称が実際のモジュール名に一致しているかを照合するモジュール名照合手段と、上記インターフェース仕様及び上記木構造をもとにプログラミング言語記述に対応したモジュール仕様書を生成するモジュール仕様生成手段とを有することを特徴とするプログラム生産支援装置。
【請求項10】 特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段は、構文解析結果をもとにシンボルの定義情報を記憶するシンボル定義抽出手段と、上記シンボルの定義情報をシンボルが定義された順に並び換えるシンボル定義並び換え手段と、上記シンボルの定義情報をもとにプログラミング言語記述に対応したシンボル一覧表を生成するシンボル一覧表生成手段とを有することを特徴とするプログラム生産支援装置。」とする訂正は、訂正前の請求項7を引用する特許請求の範囲の訂正前の請求項10、12を独立形式として、項数を繰り上げて記載したものであるから、明りょうでない記載の釈明を行う訂正である。

訂正事項d-3:
・明細書の段落番号【0013】、同段落番号【0015】、同段落番号【0017】、同段落番号【0018】、同段落番号【0025】、同段落番号【0027】、同段落番号【0029】、同段落番号【0030】、同段落番号【0166】、同段落番号【0168】、同段落番号【0170】、同段落番号【0171】の全ての記載をそれぞれ削除し、
・同段落番号【0014】第1行目、同段落番号【0167】第1行目の「また、生成手段が、」を「また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、」と、
・同段落番号【0014】第8行目の「有するようにしてもよい。」を「有するものである。」と、同段落番号【0167】第8行目の「有する場合には、」を「有しているので、」と、
・同段落番号【0016】第1行目、同段落番号【0169】第1行目の「また、生成手段が、」を「また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、」と、
・同段落番号【0016】第5行目の「有するようにしてもよい。」を「有するものである。」と、
・同段落番号【0169】第5行目の「有する場合には、」を「有しているので、」と、
する訂正は、いずれも、特許請求の範囲の記載と発明の詳細な説明の記載との整合を図り、明りようでない記載の釈明を目的として行う訂正である。

(新規事項の有無)
また、前記d-1〜3に示した訂正内容は、いずれも 願書に添付した明細書又は図面の記載から明白に読み取れることである。

(拡張・変更の存否)
前記d-1〜3の訂正は、願書に添付した明細書に記載した発明が解決しようとする課題ないし発明の効果を本質的に変更するものではなく、実質上特許請求の範囲を拡張又は変更するものではない。

5.まとめ
前記1.〜4.のとおり、訂正事項aないしdの訂正は、特許法第120条の4第3項において準用する特許法等の一部を改正する法律(平成6年法律第116号)附則第6条第1項の規定によりなお従前の例によるとされる特許法第126条第1項ただし書,第2項及び第3項の規定に適合するものである。

よって、前記補正された平成15年8月26日付けの訂正を認める。


第3 取消理由について
1.本件の請求項に係る発明
(1)請求項1に係る発明
前記第2に認定したとおり訂正が認められることから、本件の請求項1に係る特許発明(以下、特許発明1という。)は、訂正された明細書の特許請求の範囲の請求項1に記載されたとおりの次の事項により特定されるものである。

「自然言語と各機能の階層構造を示す記号とで記述された仕様記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された仕様記述の構文解析を行う構文解析手段と、構文解析結果をもとに各機能の階層構造を抽出する階層構造抽出手段と、上記抽出された階層構造をもとに上記仕様記述に対応した図または自然言語及びプログラミング言語に準じた制御構造で記述された疑似言語記述を生成する生成手段とを有することを特徴とするプログラム生産支援装置。」

(2)請求項2に係る発明
同じく、本件の請求項2に係る特許発明(以下、特許発明2という。)は、訂正された明細書の特許請求の範囲の請求項2に記載されたとおりの次の事項により特定されるものである。

「仕様記述には、種別を示す記号が記述されており、
生成手段は、上記種別に従って、ディレクトリ、ファイル、またはモジュールの少なくとも1つを生成することを特徴とする請求項1記載のプログラム生産支援装置。」

(3)請求項3に係る発明
同じく、本件の請求項3に係る特許発明(以下、特許発明3という。)は、訂正された明細書の特許請求の範囲の請求項3に記載されたとおりの次の事項により特定されるものである。

「自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有することを特徴とするプログラム生産支援装置。」

(4)請求項4に係る発明
同じく、本件の請求項4に係る発明(以下、特許発明4という。)は、訂正された明細書の特許請求の範囲の請求項4に記載されたとおりの次の事項により特定されるものである。

「自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、
上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、
上記生成手段は、構文解析結果をもとに上記仕様記述部に記述されたインターフェース仕様を抽出するインターエース仕様抽出手段と、上記構文解析結果をもとに上記ロジック記述部に記述されたモジュールの定義・参照を抽出するモジュール定義・参照抽出手段と、上記抽出されたインターフェース仕様及びモジュールの定義・参照をもとに上記疑似言語記述に対応したデザインレビュー用資料を生成するデザインレビュー用資料生成手段とを有することを特徴とするプログラム生産支援装置。」

(5)請求項5に係る発明
同じく、本件の請求項5に係る特許発明(以下、特許発明5という。)は、訂正された明細書の特許請求の範囲の請求項5に記載されたとおりの次の事項により特定されるものである。

「生成手段は、構文解析結果をもとに自然言語で記述されている処理説明および制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語記述に対応した木構造チャートを生成する木構造チャート生成手段とを有することを特徴とする請求項3記載のプログラム生産支援装置。」

(6)請求項6に係る発明
同じく、本件の請求項6に係る特許発明(以下、特許発明6という。)は、訂正された明細書の特許請求の範囲の請求項6に記載されたとおりの次の事項により特定されるものである。

「生成手段は、構文解析結果をもとに自然言語で記述されている処理説明及び制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語の制御構造をそれに対応するプログラミング言語の制御構造に変換する制御構造変換手段と、上記変換された木構造をもとに疑似言語の処理説明をプログラミング言語のコメントに変換する手段とを有することを特徴とする請求項3記載のプログラム生産支援装置。」

(7)請求項7に係る発明
同じく、本件の請求項7に係る発明(以下、特許発明7という。)は、訂正された明細書の特許請求の範囲の請求項7に記載されたとおりの次の事項により特定されるものである。

「特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述を生成する生成手段とを有することを特徴とするプログラム生産支援装置。」

(8)請求項8に係る発明
同じく、本件の請求項8に係る発明(以下、特許発明8)は、訂正された明細書の特許請求の範囲の請求項8に記載されたとおりの次の事項により特定されるものである。

「プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有するものであって、
生成手段が、構文解析結果をもとにプログラムの制御構造及びそれに付随するコメントを抽出する制御構造抽出手段と、上記制御構造をもとにプログラミング言語の制御構造を自然言語及び上記プログラミング言語に準じた制御構造で記述された疑似言語の制御構造に変換する制御構造変換手段と、上記制御構造をもとに上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段とを有することを特徴とする請求項7記載のプログラム生産支援装置。」

(9)請求項9に係る発明
同じく、本件の請求項9に係る特許発明(以下、特許発明9という。)は、訂正された明細書の特許請求の範囲の請求項9に記載されたとおりの次の事項により特定されるものである。

「特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、
上記生成手段は、構文解析結果をもとにプログラミング言語記述のへッダーコメントに記述されたインターフェース仕様を抽出するインターフェース仕様抽出手段と、構文解析結果をもとに上記プログラミング言語記述のモジュールの定義・参照を木構造に変換して記憶するモジュール定義・参照抽出手段と、ヘッダーコメント中のモジュール欄の名称が実際のモジュール名に一致しているかを照合するモジュール名照合手段と、上記インターフェース仕様及び上記木構造をもとにプログラミング言語記述に対応したモジュール仕様書を生成するモジュール仕様生成手段とを有することを特徴とするプログラム生産支援装置。」

(10)請求項10に係る発明
同じく、本件の請求項10に係る特許発明(以下、特許発明10という。)は、訂正された明細書の特許請求の範囲の請求項10に記載されたとおりの次の事項により特定されるものである。

「 特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、
上記生成手段は、構文解析結果をもとにシンボルの定義情報を記憶するシンボル定義抽出手段と、上記シンボルの定義情報をシンボルが定義された順に並び換えるシンボル定義並び換え手段と、上記シンボルの定義情報をもとにプログラミング言語記述に対応したシンボル一覧表を生成するシンボル一覧表生成手段とを有することを特徴とするプログラム生産支援装置。」

2.平成15年6月16日付の取消理由通知書で通知した取消理由
前記取消理由通知書によって、次のア)ないしウ)の取消理由を通知した。
ア) 平成14年1月29日付で訂正された特許請求の範囲の請求項1に係る特許発明は、特許法第36条第4項の規定に違反してされたものである。
イ) 同特許請求の範囲の請求項1の記載は、特許法第36条第5項及び第6項の規定に違反するものである。
ウ) 同特許請求の範囲の請求項1,3,5ないし8に係る特許発明は、特許法第29条第2項の規定に違反してされたものである。

なお、現特許発明1,3,5ないし8は、同特許請求の範囲1,3,5ないし8に係る特許発明に対応するものであり、また、前記取消理由でそれぞれの特許発明に引用した刊行物も同じものである。

3.取消理由の有無の検討
異議申立のない請求項2,4,9,10に対する前記訂正は、従属形式で記載されたそれらの請求項を、明りょうでない記載の釈明を目的として、独立形式とするためのものであり、いわゆる独立特許要件の検討は要さない。したがって、異議申立のされた特許発明である、特許発明1,3,5ないし8について前記2.の取消理由の有無を検討する。

3.1 特許法第36条第4項違反についての検討
特許発明1は、仕様記述を読み込み、階層構造を抽出し、上記抽出された階層構造をもとに上記仕様記述に対応した図または自然言語及びプログラミング言語に準じた制御構造で記述された疑似言語記述を生成する旨のものである。
しかし、本件明細書の発明の詳細な説明には、仕様記述101から疑似言語記述のひな型1301を生成する方法が実施例2として記載されているが、仕様記述101から疑似言語記述301を生成する実施例は記載されていない(前記実施例2は、仕様記述を読み込んで、プログラムを実現するのに必要なディレクトリ、ファイル、およびモジュールを含む疑似言語記述のひな型を自動生成するものであるが(【0041】〜【0051】等参照)、前記疑似言語記述のひな型には、例えば、疑似言語が備えるモジュールのインターフェース仕様(【0053】〜【0055】,図14等参照)などが含まれておらず、また、それらが含まれていることを、本件明細書の発明の詳細な説明から読み取ることもできない。さらに、前記実施例2は、前工程の設計情報(機能構成)を後工程に忠実に伝えるものである(【0051】)から、機能構成には関係のない、例えば、前記モジュールのインタフェース仕様まで自動生成することは念頭におかれていないものと解される。)。

すなわち、本件明細書の(各実施例の)記載及び図面(例えば図80)を参照しても、仕様記述から疑似言語記述を生成するようなものを読み取ることはできない。

したがって、本件特許明細書の発明の詳細な説明の記載は、当業者が特許発明1を容易に実施できる程度に記載されたものではなく、特許法第36条第4項の規定に違反するものである。

3.2 特許法第36条第5項及び6項違反についての検討
特許発明1は、前記2.1で述べたように、本件明細書の発明の詳細な説明に記載したものではないから、特許法第36条第6項第1号の規定を満たしていない。
したがって、前記請求項1の記載は、特許法第36条第5項及び第6項の規定に違反してされたものである。

3.3 特許法第29条第2項違反についての検討
(1)引用刊行物一覧
刊行物1.特開平2-59818号公報
刊行物2.「NCOSソフトウェア NCOS1 NCOS1/AF ソフトウェア開発支援システム説明書」,昭和62年8月,初版,日本電気株式会社
刊行物3.「OS IV YPS/COBOL85 ジェネレータ使用手引書 V10L11用」,平成3年6月,第2版,富士通株式会社
(審決注:平成15年6月16日付の取消理由通知書において刊行物名が「OS IV YPS/COBOL85 使用手引書 V10L11系用」となっていたのを上記のとおり訂正。)
刊行物4.「FMシリーズ FM YPSエディタ V1.1使用手引書」,平成元年12月,富士通株式会社

(2)刊行物に記載の発明
[刊行物1]
刊行物1には、次のとおり記載されている。
(a).「従来からソフトウェアの設計にはフローチャート等が主に使われているが、近年、理解性および視認性の観点から木構造図が注目を浴びている。
主な木構造図としてはTFF,HCP,PAD等が知られており、これらによる木構造図をCRTディスプレイ上で編集する木構造図エディタも開発されている。
ところで、木構造図は、一般に処理の種類および流れを表現するシンボルと、処理の内容を表現するテキストとの2種類の情報から構成されている。
したがってディスプレイ上で木構造図の編集または表示を行なおうとすると、シンボルをグラフィックスで表現しておく必要があるが、グラフィックスは計算機やオペレーティングシステム(OS)等に依存する処理が相当多いので、グラフィックスを利用した木構造図エディタは、利用できる計算機が限定される。」(第1頁右下段第4行〜第20行)

(b).「(発明が解決しようとする課題)
このように従来の木構造図作成システムは、グラフィックスを利用しているので、利用できる計算機が限定されるという問題があった。
本発明はこのような事情によりなされたもので、利用できる計算機が限定されず、キャラクタベースの端末からでも利用することができる木構造図簡易作成システムの提供を目的としている。」(第2頁左上段第1行〜第8行)

(c).「(作用)
本発明の木構造図簡易作成システムによれば、専用の木構造図エディタを使わないで、テキストエディタによりプログラムモジュールの木構造図情報を簡単に入力することができる。また記述法ごとにシンボルテーブルを作成するので、各種の木構造図を簡易に作成することができる。」(第2頁右上段第4行〜第10行)

(d).「(イ)テキスト情報の入力
利用者は入力装置2からテキストエディタ13を利用してテキスト情報を入力する。
処理の流れを示すシンボルは第2図に示したように、その意味を表すキーワードで記述する。そして各シンボルとその意味を表すキーワードとの対応はシンボルテーブルで保持している。また入力されたテキスト情報は外部記憶装置5に保存する。
(ロ)テキスト情報解釈
外部記憶装置5に保存されているテキスト情報は木構造図生成部10により解釈されて第3図に示したような木構造図に変換される。この変換はシンボルテーブルを参照して行なわれる。」(公報第2頁右下段第5行〜第18行)

(e).「本実施例のシステムによれば、処理の流れを表す木構造図を作成するのに専用の木構造図エディタを利用しなくてもテキストエディタからデータを容易に入力することができる。
したがって、木構造図の専用エディタがない計算機でも使用することができ、専用エディタの操作方法を知らなくても容易に木構造図を生成することができる。」(第3頁左上段第15行〜同頁右上段第2行)

そして、
ア) 引用記載(a)〜(e)に記載の木構造図は、引用記載(a)によれば、ソフトウェアの設計に用いるものなので、引用記載(b)の木構造図簡易作成システムは、プログラム生産支援装置の一つである。

イ) 引用記載(c)及び第2図によると、「処理の内容を表現するテキスト」の「テキスト」は、自然言語である。

したがって、刊行物1には、

木構造図の専用エディタがない計算機でも使用することができ、専用エディタの操作方法を知らなくても容易に木構造図を生成するプログラム生産支援装置であって、
木構造図は、一般に処理の種類および流れを表現するシンボルと、処理の内容を表現するテキストとの2種類の情報から構成されており、
前記処理の流れを表現するシンボルを、その意味を表すキーワードと対応付けて保持するシンボルテーブルと、
前記シンボルを、その意味を表す前記キーワードで記述することにより、前記処理の流れを表現するシンボルと、処理の内容を表現する自然言語のテキストとを、テキストエディタを利用してテキスト情報として入力可能とし、
前記テキストエディタで入力されたテキスト情報を、前記シンボルテーブルを参照つつ解釈して、前記処理の流れを表現するシンボルと処理の内容を表現する自然言語のテキストとを、木構造図に変換することを特徴とするプログラム生産支援装置。

が記載されている(以下、引用発明1という)。

[刊行物2]
刊行物2には、次のとおり記載されている。
(a).「プログラム開発支援では、プログラムの生産性を支援するために、次のツールを用意している。
・FORTRAN/S
・COBOL/S
・画面エディタ
(1) FORTRAN/S
FORTRAN/Sは、FORTRAN言語に疑似言語を導入して、構造的プログラミングの思想を取り入れたプログラミングツールであり、既存のFORTRAN言語プロセッサの前段に位置するプリプロセッサという形で提供される。」(第3頁第9行〜第17行)

(b).「2.3.1 機能と特徴
FORTRAN/S言語の機能は、
・表現機能
・操作機能
の二つに分けて概括することができ、以下はすべてFORTRAN言語とは異なる付加された機能とその特徴について述べる。
(1) 表現機能
表現機能とは、FORTRAN/S言語のうち、プログラムの記述に関するものであり、特記すべきは次のものである。
(a) プログラムの構造的論理化機能
現在のFORTRAN言語で最も表現能力が不十分な仕様は、プログラムの構造的論理化を明確にすることができない点である。これらを解決するために、FORTRAN/S言語では構造的プログラミングの基本概念である、
(i) 一入口(トップ)、一出口(ボトム)
(ii) 順次構造
(iii) 選択構造
(iv) 繰り返し構造
を完全に実現している。この結果プログラムは、ALGOL、PL/Iのような構造的論理化が可能である。」(第7頁第2行〜20行)

(c).「(3) 画面エディタ
画面エディタは、画面型端末を用い、テキストファイルの生成、編集および保存処理を、端末特性を生かし確実かつ迅速に行うツールである。」(第6頁第1行〜第3行)

(d).「(b) FORTRAN/S言語の構文解析機能
コンピュータ上で稼働可能なオブジェクトプログラムは、FORTRAN/S言語プリプロセッサ、FORTRAN言語プロセッサを経由して作られるから、正しいオブジェクトプログラムを得るための構文解析は、最も操作上問題となる点である。それらは、次のように処理される。
(1) プリプロセッサ、プロセッサの構文解析
FORTRAN/S言語で記述されたソース入力プログラムは、まずプリプロセッサの構文解析部によってFORTRAN/S言語として付加された機能に関するもののみのチェックが行われ、必要であれば引き続きFORTRAN言語プロセッサによってFORTRAN言語本体の構文解析が行われる。」(第9頁第18行〜28行)

(e).「2.5.4 日本語データの編集処理
画面エディタ起動時、日本語モードを選択すると、日本語データ(日本語文字または漢字文字)と英数カナ文字データ(ANK文字)を同時に扱うことができる。」(第20頁第20行〜22行)

と記載されている。ここで、
ア) 引用記載(a),(c),(e)及び図2-1(第4頁),図2-3(第6頁)および表2-1(第11,12頁)とを参照すると、FORTRAN/Sは、テキストで表現される疑似言語であるから、FORTRAN/Sは、自然言語とプログラミング言語に準じた制御構造とがテキストで記述された疑似言語記述である。

イ) 前記疑似言語は、表2-1の注釈記述文を用いて、注釈を入力することができるものである。

ウ) 引用記載(c)によると、エディタは画面上でテキストを編集するテキストエディタである。

エ) 図2-1,2-3に記載のものは、プログラム生産支援装置である。

したがって、上記刊行物2には、

自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、テキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応したプログラミング言語記述を生成する生成手段を有するプログラム生産支援装置であって、
前記疑似言語記述には、注釈記述文によって、自然言語で注釈を記述することができるプログラム生産支援装置。

が記載されている(以下、引用発明2という。)。

[刊行物3]
刊行物3には、次のとおり記載されている。
(a).「YPS/COBOL85ジェネレータは,COBOL85原始プログラムを入力とし,YPSプログラム仕様書を出力します.
出力されるYPSプログラム仕様書は,以下のような形で表現されます.
- 制御線を含む図記号
- 標準変換構文で定めるCOBOL85の文の日本語表現
- 利用者が定義した変換構文によるCOBOL85の文の日本語表現
- 日本語項目変換辞書による文字列の日本語化
図記号については,“表2.1 COBOL85からYPS/COBOL85への変換規則”にしたがって変換されます.」(第2頁第2行〜10行)

(b).「コメント行/デバッグ行
・デバッグ行はコメント行として変換されます.COBOL85原始プログラム中にデバッグ行がある場合,デバッグ行はコメント行としてYPSプログラム仕様書に出力され,
“JPB00971-W デバッグ行が存在します.”とメッセージが出力されます.変換例は“表2.1 COBOL85からYPS/COBOL85への変換規則”を参照して下さい.
利用者は,そのデバッグ行が必要かどうかを確認し,必要な場合には,7カラム目のDを空白に変更後,YPS/COBOL85ジェネレータで変換してください.
・“☆”は,YPS/COBOL85で予約語となっています.よって,
YPS/COBOL85ジェネレータの変換の対象となるCOBOL85原始プログラム中に,“☆”,または“☆”のコードを,利用者は記述できません.
・標識領域の“/”(斜線)は,“◎”(改ページ図記号)に変換されます.注記行のA領域とB領域に文字が記述されている場合は,次行の☆印の後に文字が出力されます.標識領域の斜線の変換例を図2.8に示します.
・1文の途中に注記行を記述した場合,その注記行は,記述された文の終止符の次の行に出力されます.文の途中に注記行を記述した場合の変換の例を図2.9に示します.」(第23頁第12行〜第24頁第2行)

(c). 「JPB0011I-S
COBOL85原始プログラムの構成に誤りがあります。
[メッセージの意味]
COBOL85原始プログラムの構成に必要な部、節などの構成要素が存在しません。」(第70頁第41行〜44行)

(d).「JPB0091I-W
COBOLで使用できない文字xxxxxxが存在します。
[メッセージの意味]
COBOLで使用できない文字が存在します。」(第80頁第31行〜34行)

ここで、
ア) 引用記載(a)および表2.1(第5頁)によると、YPS/COBOL85ジェネレータは、COBOL85原始プログラムを入力とし、制御線を含む図記号、標準変換構文で定めるCOBOL85の文の日本語表現、利用者が定義した変換構文によるCOBOL85の文の日本語表現、日本語項目変換辞書による文字列の日本語化の形で表現される、YPSプログラム仕様書を出力するものである。

イ) 引用記載(c),(d)によると、引用発明3は、入力されたCOBOL85原始プログラムに対して構文解析を行なうものである。

ウ) 前記イ)の構文解析結果をもとに抽出される、YPSプログラム仕様書を構成する、制御線を含む図記号、標準変換構文で定めるCOBOL85の文の日本語表現、利用者が定義した変換構文によるCOBOL85の文の日本語表現、日本語項目変換辞書による文字列は、COBOL85原始プログラムの制御構造を表すものである。

エ) 引用記載(b)及び、表2.1そして図2.8(第24頁)及び図2.9(第24頁)を参照すると、自然言語で対応するプログラム言語を説明する注記行は、抽出・変換されて前記対応するプログラム言語の制御構造に付随する処理説明として出力されている。

オ) 引用記載(a)〜(d)によると、YPS/COBOL85ジェネレータは、プログラム生産支援装置の一つといえる。

したがって、刊行物3には、

COBOL85原始プログラムを入力として構文解析を行って、当該構文解析の結果をもとに、入力されたCOBOL85原始プログラムから抽出した制御構造等で表現されるYPSプログラム仕様書を出力するプログラム生産支援装置において、
入力したCOBOL85原始プログラムを自然言語で説明する注記行を抽出・変換し、当該抽出した自然言語を、当該注釈が対応するプログラムの制御構造に付随する処理説明として、YPSプログラム仕様書に含めて出力することを特徴とするプログラム生産支援装置。

が記載されている(以下、引用発明3という。)。

(3)本件特許発明と刊行物に記載の発明との対比・検討
<特許発明1>
特許発明1と引用発明1とを対比・検討する。

引用発明1について、
ア) 引用発明1の木構造図を構成する「処理の種類及び流れを表現するシンボル」について、前記「処理の種類」及び「処理の流れ」は、それぞれ、処理の機能及び階層構造を含む繋がり、を示しているものと解される。

イ) 引用発明1のテキスト情報の解釈は、技術常識からして、構文解析により行われるものである。

ウ) 引用発明1の前記構文解析により階層構造情報を含んだ木構造図を生成しているのであるから、前記構文解析においては、各機能の階層構造を抽出している。

したがって、特許発明1と刊行物1に記載の発明とは、

[一致点]
自然言語と各機能の階層構造を示す記号とで記述されたテキスト情報を読み込み、前記テキスト情報の構文解析を行う手段と、
構文解析結果をもとに各機能の階層構造を抽出する手段と、
上記抽出された階層構造をもとに上記テキスト情報に対応した図を生成する生成手段を有することを特徴とするプログラム生産支援装置。

である点で一致し、

[相違点]
(相違点1)
読み込む情報が、特許発明1は仕様記述であるのに対して、引用発明1はテキスト情報である点。

(相違点2)
疑似言語記述を読み込みんだ後の解析処理が、
特許発明1は、その内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段で行われるが、
刊行物2に記載の発明は、その内容の構文解析を行う構文解析手段で行われる点。

で相違している。

[相違点の検討]
(相違点1について)
特許発明1の仕様記述は自然言語と各機能の階層構造を示すものであるが、引用発明1のテキスト情報も、自然言語と機能の階層構造情報を含む情報であるから、前記相違点1は実質的な差異にはあたらない。

(相違点2について)
構文解析は、字句解析を行った後に行うのが技術常識であるから、引用発明2の構文解析においても、構文解析に先立ち字句解析が行われているとみるのが自然であり、合理的である。したがって、前記相違点2は、実質的な差異にはあたらない。

よって、特許発明1は、引用発明1に基づいて当業者が容易に発明をすることができたものである。

なお、特許権者は、特許発明1の仕様記述は、書籍の目次に準じた形式のものである点で引用発明1と相違する旨主張しているが、前記特許権者が相違点と主張する事項を加える訂正はすでに削除されているから、特許権者の前記主張は検討を要しない。


<特許発明3>
特許発明3と引用発明2とを対比・検討すると、両者は、

[一致点]
自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、テキストエディタを用いて入力及び編集可能な疑似言語記述を読み込み、その内容の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応したプログラミング言語記述を生成する生成手段を有するプログラム生産支援装置。

である点で一致し、

[相違点]
(相違点1)
テキストエディタが、特許発明3では汎用のものであるのに対し、引用発明2では汎用のものとは明記されていない点。

(相違点2)
疑似言語記述を読み込みんだ後の解析処理が、
請求項3に係る発明は、その内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段で行われるが、
刊行物2に記載の発明は、その内容の構文解析を行う構文解析手段で行われる点。

で相違している。

[相違点の検討]
(相違点1について)
引用発明2のテキストエディタは、テキストを入力・編集できればいいものであることは明らかであるから、引用発明2のテキストエディタを、汎用のテキストエディタとすることに困難性は認められない。
したがって、相違点1は、格別のものではない。

(相違点2について)
構文解析を行う際に、字句解析が伴うことは技術常識であるから、引用発明2に記載のものでも、字句解析が行われているものと解される。
したがって、相違点2は、格別のものではない。

よって、特許発明3は、引用発明1に基づいて当業者が容易に発明をすることができたものである。


<特許発明5>
請求項5は、請求項3の引用形式で記載されているから、<特許発明3>の検討に引き続いて、特許発明5と、引用発明2とを対比・検討する。

引用発明2は、自然言語とプログラミング言語に準じた制御構造とがテキストで記述された疑似言語からプログラミング言語記述を生成するもので、自然言語は処理説明に用いるものであることは技術常識である。したがって、引用発明2においては、プログラミング言語記述を生成する際に、自然言語で記述されている処理説明及び制御構造を抽出しているものと解される。

したがって、両者は、
[一致点]
自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、テキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容の構文解析を行う構文解析手段と、構文解析結果をもとに自然言語で記述されている処理説明および制御構造を抽出する手段を有するプログラム生産支援装置。

である点で一致し、

[相違点]
(相違点1)
テキストエディタが、特許発明6は汎用のものであるのに対し、引用発明2は汎用のものとは明記されていない点。

(相違点2)
抽出した処理説明および制御構造について、
特許発明5は、木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語記述に対応した木構造チャートを生成する木構造チャート生成手段を備えるのに対して、
引用発明2は、プログラム言語記述に変換するものである点で相違している。

[相違点の検討]
(相違点1について)
前記<特許発明3>で相違点1について検討したのと同じく、格別のものではない。

(相違点2について)
プログラムを木構造図に変換することは周知である(例えば、下に示す周知例1,2参照)から、引用発明2において、疑似言語をプログラム言語記述に変換していたものを、木構造図に変換して出力するようにし、特許発明3の如く構成することに困難性は認めらない。なお、その処理過程で、木構造の制御構造を記憶することは適宜為し得る事項に過ぎない。

よって、特許発明5は、引用発明2及び前記周知技術に基づいて、当業者が容易に発明をすることができたものである。

周知例1: 特開昭60-100226号公報
周知例2: 特開平4-24733号公報

<特許発明6>
請求項6は請求項3の引用形式で記載されているから、前記<特許発明3>での検討に引き続いて、特許発明6と、引用発明2とを対比する。

引用発明2の注釈は、処理説明に相当するものである。
したがって、両者は、
[一致点]
自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、テキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容の構文解析を行う構文解析手段と、
構文解析結果をもとに自然言語で記述されている処理説明及び制御構造を得るもので、前記処理説明及び制御構造から疑似言語の処理説明をプログラミング言語のコメントに変換する手段を有する点。

で一致し、

[相違点]
(相違点1)
テキストエディタが、特許発明6は汎用のものであるのに対し、引用発明2は汎用のものとは明記されていない点。

(相違点2)
疑似言語の処理説明をプログラミング言語のコメントに変換する過程において、
特許発明6は、自然言語で記述されている処理説明及び制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語の制御構造をそれに対応するプログラミング言語の制御構造に変換する制御構造変換手段を備えているが、
引用発明2は、どのような処理を行う手段を有するのか、明記されていない点。

で相違している。

[相違点の検討]
(相違点1について)
前記<特許発明3>で(相違点1)について検討したのと同じく、相違点1は格別のものではない。

(相違点2について)
プログラム等の制御構造を表現する形式として、木構造の形式は周知であるから、引用発明2において、制御構造を木構造に変換して記憶しておき、木構造の制御構造をもとにプログラミング言語の制御構造を得るように為し、相違点2の如く構成することに困難性はない。

したがって、特許発明6は、引用発明2及び前記周知技術に基づいて、当業者が容易に発明をすることができたものである。

<特許発明7>
特許発明7と、引用発明3とを対比する。

引用発明3において、COBOL85原始プログラムを入力とすることは、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込むことでもあるから、両者は、

[一致点]
特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込み、プログラミング言語記述の構文解析を行う構文解析手段を備え、構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とが記述された情報を生成するプログラム生産支援装置。

である点で一致し、

[相違点]
(相違点1)
構文解析手段の前に、特許発明7が、プログラミング言語記述を読み込みその内容を字句に分解する字句解析手段を備えるのに対して、
引用発明3では、そのような手段は明記されていない点、

(相違点2)
生成される情報が、特許発明7では、疑似言語記述であり、当該疑似言語は、自然言語と制御構造とがテキストで記述されたものであるのに対して、引用発明3では、YSPプログラム仕様書であり、当該YSPプログラム仕様書は、自然言語はテキストであるが、制御構造は図記号を含んで記述されるものである点。

で相違している。

[相違点の検討]
(相違点1について)
構文解析は、字句解析を伴うのが技術常識であるから、相違点1は格別のものではない。

(相違点2について)
プログラムの論理をわかりやすく表すために、引用発明3においては木構造図の一種であるYPSプログラム仕様書が、特許発明7においては疑似言語記述が、用いられている。また、プログラムの論理を表現するものとして、疑似言語と木構造図を含む図形表現が等価であることは周知である(必要であれば周知例3参照。)。
したがって、引用発明3において、YPSプログラム仕様書に代えて、疑似言語記述を採用し、相違点2の如く構成することに困難性はない。

周知例3: 情報処理ハンドブック,株式会社オーム社発行,第1版第1刷,第986〜988頁,1989年5月30日発行

よって、いずれの相違点も格別のものではなく、特許発明7は当業者が引用発明3及び周知技術に基づいて容易に発明をすることができたものである。

<特許発明8>
請求項8は請求項7の引用形式で記載されているから、前記<特許発明7>での検討に引き続きいて、特許発明8と引用発明3とを対比すると、両者は、

[一致点]
プログラミング言語は、コメントを有するものであって、
プログラムの論理を表す情報の生成手段が、構文解析結果をもとにプログラムの制御構造及びそれに付随するコメントを抽出する手段と、
上記制御構造をもとにプログラミング言語の制御構造を自然言語及び上記プログラミング言語に準じた制御構造で記述された前記プログラムの論理を表す情報の制御構造に変換する手段と、
上記制御構造をもとに上記プログラミング言語のコメントを前記情報の自然言語で記述された処理説明に変換する手段と、
を有することを特徴とするプログラム生産支援装置。

である点で一致し、

[相違点]
(相違点1)
特許発明8では、プログラミング言語のモジュール内のコメントを処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換するが、
引用発明3では、コメントを処理説明に変換する際の様々な場合を個別に詳説していない点。

(相違点2)
生成手段が生成するプログラムの論理を表す情報が、特許発明8のものは、疑似言語であるのに対して、引用発明3のものは、YSPプログラム仕様書である点。

で相違する。

[相違点の検討]
(相違点1について)
プログラミング言語のなかに、モジュール、条件文、条件文中の条件式を備え、プログラム中に適宜コメントを記載できるものがあることは周知(必要であれば、周知例4参照)である。
したがって、引用発明3に記載のものにおいて、処理説明に変換するコメントを、条件文中の条件式に対するコメント、モジュール内のコメントとして、前記相違点1の如く構成することに困難性はない。なお、条件文の条件式を処理説明で置き換えることも適宜為し得る事項に過ぎない。

周知例4:特開昭62-145424号公報

(相違点2について)
前記<特許発明7>の[相違点の検討](相違点2について)で述べたのと同様、格別のものではない。

よって、いずれの相違点も格別のものではなく、特許発明8は、当業者が引用発明3及び周知技術に基づいて容易に発明をすることができたものである。


第4 むすび
本件明細書の特許請求の範囲の請求項1に記載の発明の特許は、前記第3の2.1で述べた点で、特許法第36条第4項の規定に違反してされたものである。
また、本件明細書の特許請求の範囲の請求項1の記載は、前記第3の2.2で述べた点で、特許法第36条第5項及び6項の規定に違反してされたものである。
さらに、請求項1,3,5ないし8に係る発明の特許は、前記2.3で検討したとおり、特許法第29条2項の規定に違反してされたものである。
以上のとおり、請求項1に係る発明の特許は特許法第113条第1項第2号及び第4号に該当し、請求項3,5ないし8に係る発明の特許は特許法第113条第1項第2号に該当するから、取り消されるべきものである。

よって、結論のとおり審決する。
 
発明の名称 (54)【発明の名称】
プログラム生産支援装置
(57)【特許請求の範囲】
【請求項1】 自然言語と各機能の階層構造を示す記号とで記述された仕様記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された仕様記述の構文解析を行う構文解析手段と、構文解析結果をもとに各機能の階層構造を抽出する階層構造抽出手段と、上記抽出された階層構造をもとに上記仕様記述に対応した図または自然言語及びプログラミング言語に準じた制御構造で記述された疑似言語記述を生成する生成手段とを有することを特徴とするプログラム生産支援装置。
【請求項2】 仕様記述には、種別を示す記号が記述されており、
生成手段は、上記種別に従って、ディレクトリ、ファイル、またはモジュールの少なくとも1つを生成することを特徴とする請求項1記載のプログラム生産支援装置。
【請求項3】 自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有することを特徴とするプログラム生産支援装置。
【請求項4】 自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、
上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、
上記生成手段は、構文解析結果をもとに上記仕様記述部に記述されたインターフェース仕様を抽出するインターエース仕様抽出手段と、上記構文解析結果をもとに上記ロジック記述部に記述されたモジュールの定義・参照を抽出するモジュール定義・参照抽出手段と、上記抽出されたインターフェース仕様及びモジュールの定義・参照をもとに上記疑似言語記述に対応したデザインレビュー用資料を生成するデザインレビュー用資料生成手段とを有することを特徴とするプログラム生産支援装置。
【請求項5】 生成手段は、構文解析結果をもとに自然言語で記述されている処理説明および制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語記述に対応した木構造チャートを生成する木構造チャート生成手段とを有することを特徴とする請求項3記載のプログラム生産支援装置。
【請求項6】 生成手段は、構文解析結果をもとに自然言語で記述されている処理説明及び制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語の制御構造をそれに対応するプログラミング言語の制御構造に変換する制御構造変換手段と、上記変換された木構造をもとに疑似言語の処理説明をプログラミング言語のコメントに変換する手段とを有することを特徴とする請求項3記載のプログラム生産支援装置。
【請求項7】 特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述を生成する生成手段とを有することを特徴とするプログラム生産支援装置。
【請求項8】 プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有するものであって、
生成手段が、構文解析結果をもとにプログラムの制御構造及びそれに付随するコメントを抽出する制御構造抽出手段と、上記制御構造をもとにプログラミング言語の制御構造を自然言語及び上記プログラミング言語に準じた制御構造で記述された疑似言語の制御構造に変換する制御構造変換手段と、上記制御構造をもとに上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段とを有することを特徴とする請求項7記載のプログラム生産支援装置。
【請求項9】 特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、
上記生成手段は、構文解析結果をもとにプログラミング言語記述のヘッダーコメントに記述されたインターフェース仕様を抽出するインターフェース仕様抽出手段と、構文解析結果をもとに上記プログラミング言語記述のモジュールの定義・参照を木構造に変換して記憶するモジュール定義・参照抽出手段と、ヘッダーコメント中のモジュール欄の名称が実際のモジュール名に一致しているかを照合するモジュール名照合手段と、上記インターフェース仕様及び上記木構造をもとにプログラミング言語記述に対応したモジュール仕様書を生成するモジュール仕様生成手段とを有することを特徴とするプログラム生産支援装置。
【請求項10】 特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、
上記生成手段は、構文解析結果をもとにシンボルの定義情報を記憶するシンボル定義抽出手段と、上記シンボルの定義情報をシンボルが定義された順に並び換えるシンボル定義並び換え手段と、上記シンボルの定義情報をもとにプログラミング言語記述に対応したシンボル一覧表を生成するシンボル一覧表生成手段とを有することを特徴とするプログラム生産支援装置。
【発明の詳細な説明】
【0001】
【産業上の利用分野】
この発明は、プログラムの生産を支援する装置に関するものである。
【0002】
【従来の技術】
図82は、例えば特開平4-111124号公報に示された従来のプログラム生産支援装置を示す構成図、図83は同従来のプログラム生産支援装置の動作を示すフローチャートである。
図82において、1501はキーボードなどのデータ入力手段、1502はデータ定義部、1503は表示部、1504は表示手段、1505はブロック・チャート編集部、1506はブロック・エディタ部、1507はソースコード出力部、1508はソースコード記録手段である。
【0003】
この従来のプログラム生産支援装置の動作について、図83のフローチャートを用いて説明する。まず、データ入力手段1501より、ファイル名、デバイス・タイプなどのデータをデータ定義部1502に入力し、表示部1503を介して表示手段1504に表示して確認を行なう。
同様にして、データ入力手段1501より、ブロック・チャートのレイアウト情報をブロック・チャート編集部1505に入力し、表示部1503を介して表示手段1504に表示して確認し、修正の必要があれば同じ手順にて修正する。
更に、データ入力手段1501より、プログラムの部品内容をブロック・エディタ部1506に入力し、表示部1503を介して表示手段1504に表示して確認し、修正の必要があれば同じ手順にて修正する。
以上の作業結果に不備がある場合は、満足のいく結果が得られるまで以上の操作を手作業にて繰り返し行なう。
しかる後に、データ定義、ブロック・チャート、プログラム部品の情報を寄せ集めてソースコード出力部1507に入力して編集し、その結果をソースコード記録手段1508に記録する。
こうして得られたソースコードに不備がある場合は、満足のいく結果が得られるまで以上全ての操作を繰り返し行なう。
【0004】
【発明が解決しようとする課題】
従来のプログラム生産支援装置は以上のように構成されているので、プログラムを変更する場合には、作業者が上記作業を画面で確認しながら繰り返して行なう必要があり、かなりの時間を要するという問題があった。
更に作業者が間違ったデータを入力しても、そのことを検出する手段がなかったり、入力途中の段階では内容を確認できないなどの問題点があった。
入力に際しても設計が固まってからでなければ作業に着手できず、設計途中の未完成段階では全く入力できないという問題があった。
また、このような作業を行なう為には、グラフィック表示機能の付いた高価な計算機が必要となり、広く全員に広めることが不可能であった。
【0005】
この発明は上記課題を解決する為になされたものであり、言語ベースのデータを入力とすることにより、このデータを入力するだけで、入力データに関する文法チェックを自動的に行なうと共に、必要な図表を自動的に生成する装置を得ることを目的とする。
また、前工程で作成されレビューされたデータを、後工程の入力(ひな型)として流用できるようにすることで、前工程のデータを正確に後工程に伝える為の装置を得ることも目的とする。
更に、全ての入力と出力をテキスト(文字データ)にすることにより、広く一般に普及している汎用のテキスト・エディタを用いて、データの入力および編集を可能にすると共に、広く一般に普及しているCRTおよびプリンタから図表を出力できるようにし、広く全員に普及できる装置を得ることも目的とする。
【0006】
【課題を解決するたもの手段】
この発明におけるプログラム生産支援装置は、言語から言語もしくは言語から図表への自動変換を主体とし、言語の正当性検査手段と図表の自動生成手段を設けたものである。
この発明に係るプログラム生産支援装置は、自然言語と各機能の階層構造を示す記号とで記述された仕様記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された仕様記述の構文解析を行う構文解析手段と、構文解析結果をもとに各機能の階層構造を抽出する階層構造抽出手段と、上記抽出された階層構造をもとに上記仕様記述に対応した図または自然言語及びプログラミング言語に準じた制御構造で記述された疑似言語記述を生成する生成手段とを有するものである。
【0007】
さらに、仕様記述に、種別を示す記号を記述し、生成手段が、上記種別に従って、ディレクトリ、ファイル、またはモジュールの少なくとも1つを生成するようにしてもよい。
【0008】
また、この発明に係るプログラム生産支援装置は、自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有するものである。
また、この発明に係るプログラム生産支援装置は、自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、上記生成手段が、構文解析結果をもとに上記仕様記述部に記述されたインターフェース仕様を抽出するインターエース仕様抽出手段と、上記構文解析結果をもとに上記ロジック記述部に記述されたモジュールの定義・参照を抽出するモジュール定義・参照抽出手段と、上記抽出されたインターフェース仕様及びモジュールの定義・参照をもとに上記疑似言語記述に対応したデザインレビュー用資料を生成するデザインレビュー用資料生成手段とを有するものである。
【0009】
また、生成手段が、構文解析結果をもとに自然言語で記述されている処理説明および制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語記述に対応した木構造チャートを生成する木構造チャート生成手段とを有するようにしてもよい。
【0010】
さらに、生成手段が、構文解析結果をもとに自然言語で記述されている処理説明及び制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語の制御構造をそれに対応するプログラミング言語の制御構造に変換する制御構造変換手段と、上記変換された木構造をもとに疑似言語の処理説明をプログラミング言語のコメントに変換する手段とを有するようにしてもよい。
【0011】
また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述を生成する生成手段とを有するものである。
【0012】
また、プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有するものであって、生成手段が、構文解析結果をもとにプログラムの制御構造及びそれに付随するコメントを抽出する制御構造抽出手段と、上記制御構造をもとにプログラミング言語の制御構造を自然言語及び上記プログラミング言語に準じた制御構造で記述された疑似言語の制御構造に変換する制御構造変換手段と、上記制御構造をもとに上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段とを有するようにしてもよい。
【0013】
また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、構文解析結果をもとにプログラミング言語記述のヘッダーコメントに記述されたインターフェース仕様を抽出するインターフェース仕様抽出手段と、構文解析結果をもとに上記プログラミング言語記述のモジュールの定義・参照を木構造に変換して記憶するモジュール定義・参照抽出手段と、ヘッダーコメント中のモジュール欄の名称が実際のモジュール名に一致しているかを照合するモジュール名照合手段と、上記インターフェース仕様及び上記木構造をもとにプログラミング言語記述に対応したモジュール仕様書を生成するモジュール仕様生成手段とを有するものである。
【0014】
また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、構文解析結果をもとにシンボルの定義情報を記憶するシンボル定義抽出手段と、上記シンボルの定義情報をシンボルが定義された順に並び換えるシンボル定義並び換え手段と、上記シンボルの定義情報をもとにプログラミング言語記述に対応したシンボル一覧表を生成するシンボル一覧表生成手段とを有するものである。
【0015】
【作用】
この発明におけるプログラム生産支援装置は、言語から言語への変換を主体とし、図表レベルでの変更・修正に比べてデータの変更・修正を容易とする一方、データが部分的に入力された段階でも各種図表を生成し、中間的な出力結果を見ながらデータを変更・修正していくことを可能とする。
すなわち、この発明のプログラム生産支援装置は、書籍の目次に準じた形式の仕様記述を入力にすることにより、プログラムの機能構成を示した機能構成図を自動的に生成する。
【0016】
さらに、書籍の目次に準じた形式の仕様記述を入力にすることにより、プログラムを実現するに必要なディレクトリ、ファイルおよびモジュールを自動的に生成する。
【0017】
また、この発明のプログラム生産支援装置は、プログラミング言語に準じた疑似言語記述を入力にすることにより、モジュールのデザインレビュー用資料を自動的に生成する。
【0018】
また、プログラミング言語に準じた疑似言語記述を入力にすることにより、モジュールの処理フローを示す木構造をチャートを自動的に生成する。
【0019】
さらに、プログラミング言語に準じた疑似言語記述を入力にすることにより、モジュールのプログラミング言語記述のひな形を自動的に生成する。
【0020】
また、この発明のプログラム生産支援装置は、プログラミング言語記述を入力にすることにより、プログラミング言語記述からプログラミング言語記述に準じた疑似言語を自動的に生成する。
【0021】
また、プログラミング言語記述を入力にすることにより、ヘッダーコメント中の「MODULE」欄に記述された名前に正確に対応したモジュール仕様書を自動的に生成する。
【0022】
また、プログラミング言語記述を入力にすることにより、プログラミング言語記述から実用的なシンボル一覧表を自動的に生成する。
【0023】
さらに、プログラム生産における事務的な処理を自動化したり、前工程で作成されレビューされた情報を後工程の入力として流用することが可能となる。
【0024】
【実施例】
以下、この発明の各実施例について、図1乃至図81を用いて説明する。
図81は、以下に記述する実施例1〜実施例12の前提となるハードウェアを示す構成図である。この図81において、1401は入力手段としてのキーボード、1402は表示手段としてのディスプレイ、1403はプログラム生産支援装置の主要構成部としての計算機、1404は計算機1403に対する外部メモリを構成する外部記憶、1405は出力手段としてのプリンタである。
実施例1.
図1は実施例1のプログラム生産支援装置を示す構成図、図2は実施例1におけるプログラム生産支援装置の動作を示すフローチャート、図3および図4は実施例1の入力である「仕様記述」の一例を示す図、図5および図6は実施例1の出力である「機能構成図」の一例を示す図、図7は実施例1の制御構造抽出手段によって変換され記憶される木構造を示す図である。
【0025】
図1において、101は自然言語および各機能の階層構造と種別が記述された「仕様記述」、102は仕様記述101を読み込みその内容を字句に分解する「字句解析手段」、103は字句に分解された仕様記述101の構文解析を行う「構文解析手段」、104は構文解析手段103による仕様記述101の構文解析結果をもとに各機能の階層構造を木構造に変換して記憶する「階層構造抽出手段」、105は階層構造抽出手段104によって記憶された木構造をもとに仕様記述101に対応した機能構成図を自動生成する「機能構成図生成手段」、106は機能構成図生成手段105によって自動生成された「機能構成図」である。
【0026】
この実施例1におけるプログラム生産支援装置の動作について、図2に示すフローチャートを用いて説明する。まず、字句解析手段102は、自然言語および各機能の階層構造と種別を示す特殊記号で記述された仕様記述101(図3および図4参照)を読み込みその内容を字句に分解する(図2のステップ(イ))。
次に、構文解析手段103は、字句解析手段102によって字句に分解された仕様記述101の構文解析を行う(図2のステップ(ロ))。
次に、階層構造抽出手段104は、構文解析手段103による仕様記述101の構文解析結果をもとに仕様記述101内の行頭に記述されたピリオドの数によって、各機能の階層構造(ピリオドの数が多いほど下位構造であることを意味する)を判断し、その情報、例えば、
.大機能
..中機能
...小機能
...小機能
..中機能
...小機能
...小機能
を図7に示す木構造に変換して記憶すると共に、ピリオドの直後に記述されている機能概要(例えば図3および図4中の「全機能」)を、階層構造に対応付けて記憶する(図2中のステップ(ハ))。
次に、機能構成図生成手段105は、階層構造抽出手段104によって記憶された木構造をもとに、仕様記述101に対応した機能構成図106(図5および図6参照)を自動生成する(図2中のステップ(ニ))。
【0027】
この実施例1では、各機能の階層構造を示す特殊記号としてピリオドを用いる方法を紹介したが、これは他のいかなる記号(例えば「@」)であっても構わない。
同様に、この実施例1では、各機能の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造(例えば「リスト構造」)であっても構わない。
【0028】
次に、従来例と比較して、この実施例1の優れている点について説明する。この実施例1と同じ機能を実現する従来の方法としては次の2つが考えられる。
【0029】
第1の方法は、図形エディタなどの汎用ツールを用いて、目的とする機能構成図を人間が作成するというものである。この方法は確かに現実的ではあるが、図の作成に膨大な時間が必要(作業コストの問題)となるだけでなく、図の書き方に個人差が出る(属人性の問題)、ミスが入り込みやすい(作業品質の問題)、など多くの問題がある。
【0030】
第2の方法は、機能構成図を作成する為の専用エディタを開発し提供するというものである。この方法では、第1の方法の欠点をある程度解消することはできるが、代わりに、専用エディタを開発するのに相当な費用がかかる(開発コストの問題)、開発したエディタは機能構成図専用であり潰しが利かない(投資効果の問題)、ユーザに専用エディタの使い方を教育する必要がある(教育コストの問題)、といった新たな問題を誘発する。
【0031】
これに対しこの実施例1を使用した場合、書籍の目次に準じた形式(〜章、〜節、〜項といった感覚)の仕様記述101を入力するだけで、プログラムの機能構成を示した機能構成図が自動的に生成されるので、人間が図形エディタなどを用いてこれと同等な機能構成図を作成するのに比べ、図の作成に要する時間が大幅に短縮されるだけでなく、図の書き方に関する個人差が完全に是正されると共に、仕様と図との不一致が全く無くなるという効果がある。
更に、入力となる仕様記述101は容易に再配置可能であり、必要に応じ如何ようにでも順番を入れ替えて試行錯誤できるという効果がある。
また、入力となる仕様記述101は単なるテキストであり、一般的なテキスト・エディタを用いて作成できるので、新たに専用エディタを開発して提供する必要がないばかりか、ユーザが自分の使い慣れたエディタを用いて仕様記述101を作成できるという効果がある。これは、この実施例1が低コストで実現かつ運用可能であることを意味している。
【0032】
以上のようにこの実施例1によれば、図1に示すように、書籍の目次に準じた形式の仕様記述101を入力にすると共に、プログラム生産支援装置中に、字句解析手段102、構文解析手段103、階層構造抽出手段104、および機能構成図生成手段105を設けることにより、機能構成図106の作成に要する時間を大幅に短縮できると共に、機能構成図106の品質を格段に高めることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
【0033】
実施例2.
図8は、実施例2のプログラム生産支援装置を示す、図9は実施例2におけるプログラム生産支援装置の動作を示すフローチャート、図10は実施例2の出力であるディレクトリ構成の一例を示す図、図11は実施例2の出力であるモジュールの一例を示す図構成図である。なお、実施例2の入力である「仕様記述」の一例としては、図3および図4に図示したものを使用する。
【0034】
以下、図8の図1と異なる要素について説明する。図8において、201は階層構造抽出手段104によって記憶された木構造をもとに仕様記述101に従ってディレクトリを自動生成する「ディレクトリ生成手段」、202は階層構造抽出手段104によって記憶された木構造をもとに仕様記述101に従ってファイルを自動生成する「ファイル生成手段」、203は階層構造抽出手段104によって記憶された木構造をもとに仕様記述101に従ってモジュールを自動生成する「モジュール生成手段」、204は「外部記憶」、205はディレクトリ生成手段201によって外部記憶204中に自動生成された「ディレクトリ」、206、207、208はファイル生成手段202によってディレクトリ205下に自動生成された「ファイル」、209、210、211はモジュール生成手段203によってファイル208内に自動生成された「モジュール」である。
【0035】
この実施例2におけるプログラム生産支援装置の動作について、図9に示すフローチャートを用いて説明する。図9において、ステップ(イ)、ステップ(ロ)、ステップ(ハ)は、図2のそれと基本的に同じである。ただし、ステップ(ハ)は、ピリオドの直後に記述されている機能概要(例えば図3および図4中の「全機能」)を階層構造に対応付けて記憶する以外に、ピリオドで始まる行の行末に記述されている識別子(例えば図3および図4中の「dir_1」)、その識別子の末尾に記述されている各機能の種別を示す特殊記号(「/」「.c」「()」)、および、行頭がピリオドで始まる行の次の行に記述されている機能説明(例えば図3および図4中の「全機能に対する機能説明」)を、階層構造に対応付けて記憶する点が異なっている。
尚、このとき階層構造に対応付けて記憶された各機能の種別を示す特殊記号は、のちほど各機能を具現化する際に、それらをディレクトリ205、ファイル206〜208、モジュール209〜211のいずれとして生成するかを決定する(図9のステップ(ニ))。
以下、図9の図2と異なる動作について説明する。仕様記述101に対して一通りの処理(木構造への変換とその記憶)が完了すると、ディレクトリ生成手段201は、階層構造抽出手段104によって記憶された木構造をもとに、各機能の種別を示す特殊記号が「/」であるものについて、それに対応して記憶された識別子を名前とするディレクトリ205を、外部記憶204中に自動生成する(図9のステップ(ホ))。
同様に、ファイル生成手段202は、階層構造抽出手段104によって記憶された木構造をもとに、各機能の種別を示す特殊記号が「.c」であるものについて、それに対応して記憶された識別子を名前とするファイル206〜208(図10参照)をディレクトリ205下に自動生成する(図9のステップ(ヘ))。
同様に、モジュール生成手段203は、階層構造抽出手段104によって記憶された木構造をもとに、各機能の種別を示す特殊記号が「()」であるものについて、それに対応して記憶された識別子を名前とするモジュール209〜211(図11参照)をファイル208内に自動生成する(図9のステップ(ト))。
【0036】
次に、仕様記述101からモジュール209〜211を生成する手順を、図3と図4および図11を用いて説明する。
【0037】
前述のとおり、仕様記述101内の情報がディレクトリ205、ファイル206〜208、モジュール209〜211のいずれとして具現化されるかは、各機能の種別を示す特殊記号(「/」「.c」「()」)によって決定される。
例えば、図3および図4中の
..大機能 dir_1_1/
[大機能に対する機能説明]
...中機能 file_1_1_1.c
[中機能に対する機能説明]
....小機能 func_1_1_1_1()
[小機能に対する機能説明]
という記述は、行頭のピリオドの数によって、
大機能-中機能-小機能
という階層構造を意味すると共に、各機能の種別を示す特殊記号によって、
「「dir_1_1」という名前のディレクトリを生成(「/」で指示)した上で、その下に「file_1_1_1.c」という名前のファイルを生成(「.c」で指示)し、その内部に「func_1_1_1_1」という名前のモジュールを生成(「()」で指示)せよ」
という作業指示を意味している。
この原則により、仕様記述101から必要なディレクトリ205、ファイル206〜208、モジュール209〜211が自動的に生成される。
【0038】
尚、こうして生成されたモジュール209〜211には、仕様記述101中のピリオドで始まる行の行末に記述されている識別子(例えば図3および図4中の「func_1_1_1_1()」)がモジュール209〜211内の仕様記述部(function spec)とロジック記述部(function logic)の名前として、ピリオドの直後に記述されている機能概要(例えば図3および図4中の「小機能」)が仕様記述部のABSTRACT欄の説明として、ピリオドで始まる行の次の行に記述されている機能説明(例えば図3および図4中の「小機能に対する機能説明」)が仕様記述部のFUNCTION欄の説明として、それぞれ
function spec func_1_1_1_1() ←仕様記述部

ABSTRACT:小機能
FUNCTION:小機能に対する機能説明
NOTE :
interface:
ARGUMENT:
RETURN :
GLOBAL :

function logic func_1_1_1_1() ←ロジック記述部


という形式で自動的に反映される。
【0039】
この実施例2では、各機能の階層構造を示す特殊記号としてピリオドを用いる方法を紹介したが、これは他のいかなる記号(例えば「@」)であっても構わない。
同様に、この実施例2では、各機能の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造(例えば「リスト構造」)であっても構わない。
同様に、この実施例2では、各機能の種別を示す特殊記号(ディレクトリ205、ファイル206〜208、モジュール209〜211のいずれとして具現化するかを指示)として、それぞれ「/」「.c」「()」を用いる方法を紹介したが、これは他のいかなる記号(例えば「.dir」「.file」「.module」)であっても構わない。
同様に、この実施例2では、仕様記述内の情報をモジュール209〜211内に反映する手段として、「仕様記述部」と「ロジック記述部」という形式を用いる方法を紹介したが、これは他のいかなる形式(例えば「表形式」)であっても構わない。
【0040】
次に、従来例と比較して、この実施例2の優れている点について説明する。この実施例2と同じ機能を実現する従来の方法としては次のものが考えられる。
【0041】
その方法とは、ディレクトリ、ファイル、およびモジュールを生成する為の対話型ツールを開発し提供するというものである。この方法は一見合理的に見えるが、実施例1のところでも指摘したとおり、対話型ツールを開発するのに相当な費用がかかる(開発コストの問題)、開発した対話型ツールは当該機能専用であり潰しが利かない(投資効果の問題)、ユーザに対話型ツールの使い方を教育する必要がある(教育コストの問題)だけでなく、目的のものを作成するのに膨大な時間がかかる(作業コストの問題)、作業のやり方に個人差が出る(属人性の問題)、ミスが入り込みやすい(作業品質の問題)、など多くの問題がある。
【0042】
これに対しこの実施例2を使用した場合、書籍の目次に準じた形式(〜章、〜節、〜項といった感覚)の仕様記述101を入力するだけで、プログラムを実現するのに必要なディレクトリ205、ファイル206〜208およびモジュール209〜211が自動的に生成されるので、人間が対話型ツールを用いてこれと同等なリソースを生成するのに比べ、これらの生成に要する時間が大幅に短縮されるだけでなく、作業のやり方に関する個人差を完全に是正できると共に、前工程の設計情報(機能構成)を後工程に忠実に伝えることができるという効果がある。
また、入力となる仕様記述101は単なるテキストであり、一般的なテキスト・エディタを用いて作成できるので、新たに専用エディタを開発して提供する必要がないばかりか、ユーザが自分の使い慣れたエディタを用いて仕様記述101を作成できるという効果がある。これは、この実施例2が低コストで実現かつ運用可能であることを意味している。
【0043】
以上のようにこの実施例2によれば、図8に示すように、書籍の目次に準じた形式の仕様記述101を入力にすると共に、プログラム生産支援装置中に、字句解析手段102、構文解析手段103、階層構造抽出手段104、ディレクトリ生成手段201、ファイル生成手段202、およびモジュール生成手段203を設けることにより、プログラムを実現するのに必要なディレクトリ205、ファイル206〜208、およびモジュール209〜211を自動生成できると共に、前工程の設計情報(機能構成)を後工程に忠実に伝えることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
【0044】
実施例3.
図12は実施例3のプログラム生産支援装置を示す構成図、図13は実施例3におけるプログラム生産支援装置の動作を示すフローチャート、図14および図15は実施例3の入力である「疑似言語記述」の一例を示す図、図16は実施例3の出力である「デザインレビュー用資料」の一例を示す図である。
【0045】
図12において、301はモジュールのインターフェース仕様と処理フローが記述された「疑似言語記述」、302は疑似言語記述301を読み込んで字句に分解する「字句解析手段」、303は字句に分解された疑似言語記述301の構文解析を行なう「構文解析手段」、304は構文解析手段303による疑似言語記述301の構文解析結果をもとに仕様記述部の各欄に記述されたインターフェース仕様を記憶する「インターフェース仕様抽出手段」、305は構文解析手段303による疑似言語記述301の構文解析結果をもとにロジック記述部に記述されたモジュールの定義・参照を記憶する「モジュール定義・参照抽出手段」、306はインターフェース仕様抽出手段304およびモジュール定義・参照抽出手段305によって記憶された情報をもとに疑似言語記述301に対応したデザインレビュー用資料を自動生成する「デザインレビュー用資料生成手段」、307はデザインレビュー用資料生成手段306によって自動生成された「デザインレビュー用資料」である。
【0046】
この実施例3におけるプログラム生産支援装置の動作について、図13に示すフローチャートを用いて説明する。
【0047】
まず、字句解析手段302は、モジュールのインターフェース仕様と処理フローが記述された疑似言語記述301(図14および図15参照)を読み込みその内容を字句に分解する(図13のステップ(イ))。
次に、構文解析手段303は、字句解析手段302によって字句に分解された疑似言語記述301の構文解析を行なう(図13のステップ(ロ))。
次に、インターフェース仕様抽出手段304は、構文解析手段303による疑似言語記述301の構文解析結果をもとに、疑似言語記述301内の仕様記述部(function spec)の先頭に記述されているモジュール名(例えば図14および図15中の「main」)、ABSTRACT欄に記述されている機能概要(例えば図14および図15中の「モジュールの概要」)、FUNCTION欄に記述されている機能説明(例えば図14および図15中の「モジュールの機能」)、NOTE欄に記述されている備考(例えば図14および図15中の「モジュールを使う際の注意事項」)、ARGUMENT欄に記述されている仮引数(例えば図14および図15中の「IN int argument_1 仮引数の説明」)、GLOBAL欄に記述されている大域変数(例えば図14および図15中の「IN int global_1 大域変数の説明」)、RETURN欄に記述されている戻り値(例えば図14および図15中の「0 戻り値の説明」)を抽出して記憶する(図13のステップ(ハ))。
次に、モジュール定義・参照抽出手段305は、構文解析手段303による疑似言語記述301の構文解析結果をもとに、疑似言語記述301内のロジック記述部(function logic)の先頭に記述されているモジュールの定義(例えば図14および図15中の「function logic main {・・・}」)と、ロジック記述部(function logic)中に記述されているモジュールの参照(例えば図14および図15中の「××を××する[function_1]」)を抽出して記憶する(図13のステップ(ニ))。
次に、デザインレビュー用資料生成手段306は、インターフェース仕様抽出手段304および、モジュール定義・参照抽出手段305によって記憶された情報をもとに、疑似言語記述301に対応したデザインレビュー用資料307(図16参照)を自動生成する(図13のステップ(ホ))。
【0048】
この実施例3では、モジュールのインターフェース仕様と処理フローを記述する手段として、C言語に準じた疑似言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語(例えば「Ada」)に準じたものであっても構わない。
同様に、この実施例3では、モジュールの処理フローの階層構造を記述する手段として、疑似言語のブロック構造(例えば図14および図15中の「{・・・}」)を用いる方法を紹介したが、これは他のいかなる方法(例えばbegin文とend文で下位構造を囲む)であっても構わない。
(注1)疑似言語とは、プログラミング言語の制御構造と自然言語の文章が混在する設計用の仮想言語を意味する。
(注2)C言語とは、AT&Tベル研究所で開発され、ANSI(American National Standards Institute)で標準化されたプログラミング言語を意味する。
(注3)Adaとは米国防総省で開発されたプログラミング言語のことである。
【0049】
次に、従来例と比較して、この実施例3の優れている点について説明する。この実施例3と同じ機能を実現する従来の方法としては次の2つが考えられる。
【0050】
第1の方法は、ワープロなどの汎用ツールを用いて、目的とするデザインレビュー用資料を人間が作成するというものである。この方法は確かに現実的ではあるが、デザインレビュー用資料の作成に膨大な時間が必要(作業コストの問題)となるだけでなく、デザインレビュー用資料の形式に個人差が出る(属人性の問題)、ミスが入り込みやすい(作業品質の問題)、など多くの問題がある。
【0051】
第2の方法は、デザインレビュー用資料を作成する為の専用エディタを開発し提供するというものである。この方法では、第1の方法の欠点をある程度解消することができるが、代わりに、専用エディタを開発するのに相当な費用がかかる(開発コストの問題)、開発したエディタはデザインレビュー用資料専用であり潰しが利かない(投資効果の問題)、ユーザに専用エディタの使い方を教育する必要がある(教育コストの問題)、といった新たな問題を誘発する。
【0052】
これに対しこの実施例3を使用した場合、プログラミング言語に準じた疑似言語記述を入力するだけで、モジュールのデザインレビュー用資料307が自動的に生成されるので、人間がワープロなどを用いてこれと同等なデザインレビュー用資料を作成するのに比べ、デザインレビュー用資料307の作成に要する時間が大幅に短縮されるだけでなく、デザインレビュー用資料307の形式に関する個人差が完全に是正されると共に、モジュールの仕様とデザインレビュー用資料307との不一致が完全になくなるという効果がある。
また、入力となる疑似言語記述301は単なるテキストであり、一般的なテキスト・エディタを用いて作成できるので、新たに専用エディタを開発して提供する必要がないばかりか、ユーザが自分の使い慣れたエディタを用いて疑似言語記述301を作成できるという効果がある。これは、この実施例3が低コストで実現かつ運用可能であることを意味している。
【0053】
以上のようにこの実施例3によれば、図12に示すように、プログラミング言語に準じた疑似言語記述301を入力にすると共に、プログラム生産支援装置中に、字句解析手段302、構文解析手段303、インターフェース仕様抽出手段304、モジュール定義・参照抽出手段305およびデザインレビュー用資料生成手段306を設けることにより、デザインレビュー用資料307の作成に要する時間を大幅に短縮できると共に、デザインレビュー用資料307の品質を格段に高めることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
【0054】
実施例4.
図17は実施例4のプログラム生産支援装置を示す構成図、図18は実施例4におけるプログラム生産支援装置の動作を示すフローチャート、図19は実施例4の出力である「木構造チャート」の一例を示す図、図20は実施例4の制御構造抽出手段によって変換され記憶される木構造の一例を示す図、図21は実施例4の木構造チャート生成手段によって生成される木構造チャートの一例を示す図、図22は実施例4の制御構造抽出手段によって変換され記憶される上記とは別の木構造の一例を示す図、図23は実施例4の木構造チャート生成手段によって生成される上記とは別の木構造チャートの一例を示す図である。なお、この実施例4の入力である「疑似言語記述」の一例としては、図14および図15に図示したものを使用する。
【0055】
以下、図17の図12と異なる要素について説明する。図17において、401は構文解析手段303による疑似言語記述301の構文解析結果をもとに疑似言語記述301のロジック記述部に記述された処理説明および制御構造を木構造に変換して記憶する「制御構造抽出手段」、402は制御構造抽出手段401によって記憶された木構造をもとに疑似言語記述301に対応した木構造チャートを自動生成する「木構造チャート生成手段」、403は木構造チャート生成手段402によって自動生成された「木構造チャート」である。
【0056】
この実施例4におけるプログラム生産支援装置の動作について、図18に示すフローチャートを用いて説明する。図18において、ステップ(イ)、ステップ(ロ)は図13のそれと同じである。
以下、図18の図13と異なる動作について説明する。まず、制御構造抽出手段401は、構文解析手段303による疑似言語記述301の構文解析結果をもとに、疑似言語記述301のロジック記述部(function logic)に記述された処理説明(例えば図14および図15中の「// ××を××する」)および制御構造(例えば図14および図15中の「if(・・・){・・・}」)を木構造に変換して記憶する(図18のステップ(ハ))。
次に、木構造チャート生成手段402は、制御構造抽出手段401によって記憶された木構造をもとに、疑似言語記述301に対応した木構造チャート403(図19参照)を自動生成する(図18のステップ(ニ))。
【0057】
次に、制御構造抽出手段401および木構造チャート生成手段402が、疑似言語記述301から木構造チャート403を生成する手順を図14、図15および図19〜図23を用いて説明する。
【0058】
この疑似言語では、
(1)ブロック(「{」と「}」)は、その内側に記述された要素を下位構造として包含する。
例えば、
××を××する

△△を△△する;

という記述において、「××を××する」という処理説明は、「△△を△△する」という処理説明を下位構造として包含する。
(2)「//」は、それに連なる一連の要素を下位構造として包含する。
例えば、
// ××を××する
△△を△△する;
□□を□□する;
という記述において、「××を××する」という処理説明は、「△△を△△する」および「□□を□□する」という2つの処理説明を下位構造として包含する。という単純な原則を前提としているので、
例えば、
××を××する

// △△を△△する
□□を□□する;
□□を□□する;
// △△を△△する
□□を□□する;
□□を□□する;

という疑似言語記述301は、制御構造抽出手段401によって図20に示す木構造に変換して記憶された後、木構造チャート生成手段402によって図21に示す木構造チャートに自動的に変換される。
同様に、図14および図15中の
// ××を××する
if(××が××ならば){
××を××する[function_1];
return エラーステータス;

という疑似言語記述301は、制御構造抽出手段401によって図22に示す木構造に変換して記憶された後、木構造チャート生成手段402によって図23に示す木構造チャート(図19参照)に自動的に変換される。
【0059】
この実施例4では、モジュールのインターフェース仕様と処理フローを記述する手段として、C言語に準じた疑似言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語(例えば「Ada」)に準じたものであっても構わない。
同様に、この実施例4では、モジュールの処理フローの階層構造を記述する手段として、疑似言語のブロック構造(例えば図14および図15中の「{・・・}」)を用いる方法を紹介したが、これは他のいかなる方法(例えばbegin文とend文で下位構造を囲む)であっても構わない。
同様に、この実施例4では、具体的な木構造チャートとしてNTT(株)で考案されたHCPチャートを用いる例を紹介したが、これは他のいかなる木構造チャート(例えば日本電気(株)のSPD)であっても構わない。
同様に、この実施例4では、処理説明の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造(例えば「リスト構造」)であっても構わない。
(注4)HCPチャートとは、Hierarchical and ComPact description chartの略称である。
(注5)SPDとは、Structured Programming Diagramの略称である。
【0060】
次に、従来例と比較して、この実施例4の優れている点について説明する。この実施例4と同じ機能を実現する従来の方法としては次の2つが考えられる。
【0061】
第1の方法は、図形エディタなどの汎用ツールを用いて、目的とする木構造チャートを人間が作成するというものである。この方法は確かに現実的ではあるが、木構造チャートの作成に膨大な時間が必要(作業コストの問題)となるだけでなく、木構造チャートの形式に個人差が出る(属人性の問題)、ミスが入り込みやすい(作業品質の問題)、など多くの問題がある。
【0062】
第2の方法は、木構造チャートを作成する為の専用エディタを開発し提供するというものである。この方法では、第1の方法の欠点をある程度解消することができるが、代わりに、専用エディタを開発するのに相当な費用がかかる(開発コストの問題)、開発したエディタは木構造チャート専用であり潰しが利かない(投資効果の問題)、ユーザに専用エディタの使い方を教育する必要がある(教育コストの問題)、といった新たな問題を誘発する。
【0063】
これに対しこの実施例4を使用した場合、プログラミング言語に準じた疑似言語記述301を入力するだけで、モジュールの処理フローを示す木構造チャート403が自動的に生成されるので、人間が図形エディタなどを用いてこれと同等な木構造チャート403を作成するのに比べ、木構造チャート403の作成に要する時間が大幅に短縮されるだけでなく、木構造チャート403の形式に関する個人差が完全に是正されると共に、モジュールの処理フローと木構造チャート403との不一致が完全になくなるという効果がある。
また、入力となる疑似言語記述301は単なるテキストであり、一般的なテキスト・エディタを用いて作成できるので、新たに専用エディタを開発して提供する必要がないばかりか、ユーザが自分の使い慣れたエディタを用いて仕様記述を作成できるという効果がある。これは、本実施例が低コストで実現かつ運用可能であることを意味している。
【0064】
以上のようにこの実施例4によれば、図17に示すように、プログラミング言語に準じた疑似言語記述301を入力にすると共に、プログラム生産支援装置中に、字句解析手段302、構文解析手段303、制御構造抽出手段401および木構造チャート生成手段402を設けることにより、木構造チャート403の作成に要する時間を大幅に短縮できると共に、木構造チャート403の品質を格段に高めることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
【0065】
実施例5.
図24は実施例5におけるプログラム生産支援装置の構成を示すブロック図、図25は実施例5におけるプログラム生産支援装置の動作を示すフローチャート、図26および図27は実施例5の出力である「プログラミング言語記述のひな形」の一例を示す図、図28は実施例5の制御構造抽出手段によって変換され記憶される木構造の一例を示す図である。なお、この実施例5の入力である「疑似言語記述」の一例としては、図14および図15に図示したものを使用する。
【0066】
以下、図24の図17と異なる要素について説明する。図24において、501は制御構造抽出手段401によって記憶された木構造をもとに疑似言語の制御構造をプログラミング言語の制御構造に変換する「制御構造変換手段」、502は制御構造抽出手段401によって記憶された木構造をもとに疑似言語の処理説明をプログラミング言語のコメントに変換する「処理説明→コメント変換手段」、503は制御構造変換手段501および処理説明→コメント変換手段502によって自動生成された「プログラミング言語記述のひな形」である。
【0067】
この実施例5におけるプログラム生産支援装置の動作について、図25に示すフローチャートを用いて説明する。
【0068】
図25において、ステップ(イ)、ステップ(ロ)、ステップ(ハ)は図18のそれと同じである。
以下、図25の図18と異なる動作について説明する。まず、本処理系は、制御構造抽出手段401によって記憶された木構造をもとに、変換すべき対象が制御構造、処理説明のいずれであるかを判断する(図25のステップ(ニ))。
変換すべき対象が制御構造の場合、制御構造変換手段501は、制御構造抽出手段401によって記憶された木構造をもとに、疑似言語の制御構造(例えば図14および図15中の「if(・・・){・・・}」)を、プログラミング言語の制御構造(例えば図26および図27中の「if(){・・・}」に変換する(図25のステップ(ホ))。
変換すべき対象が処理説明の場合、処理説明→コメント変換手段502は、制御構造抽出手段401によって記憶された木構造をもとに、疑似言語の処理説明(例えば図14および図15中の「××が××ならば」)を、プログラミング言語のコメント(例えば図26および図27中の「/*?××が××ならば*/」)に変換する(図25のステップ(ヘ))。
【0069】
次に、制御構造変換手段501および処理説明→コメント変換手段502が疑似言語記述301からプログラミング言語記述のひな形503を生成する手順を、図14および図15と図26および図27を用いて説明する。
【0070】
疑似言語からプログラミング言語への変換に際しては、
(1)疑似言語の仕様記述部に記述されているモジュールのインターフェース仕様を、プログラミング言語のコメントに変換してモジュールの先頭に出力する。
(2)上記(1)の実行に際し、仮引数に関するインターフェース仕様だけは、プログラミング言語における仮引数の宣言およびコメントに変換して出力する。
(3)疑似言語の制御構造を、プログラミング言語の制御構造に変換して出力する。
(4)疑似言語の処理説明を、プログラミング言語のコメントに変換して出力する。
(5)上記(4)の実行に際し、疑似言語記述の条件中に記述された処理説明を条件の外へ移動させると共に、文章の先頭に「?」マークを付加してからプログラミング言語のコメントに変換して出力する。
(6)上記(4)の実行に際し、break文、return文、exit文に付随する処理説明を、それぞれの文と分離してからプログラミング言語のコメントに変換して出力する。
という変換規則を前提としているので、例えば、図14および図15中の
// ××を××する
if(××が××ならば){
××を××する[function_1];
return エラーステータス;

という疑似言語記述301は、制御構造抽出手段401によって図28に示す木構造に変換して記憶された後、制御構造変換手段501および処理説明→コメント変換手段502によって
/*
* ××を××する
*/
if(){ /*?××が××ならば */
/* ××を××する */
function_1();
return; /* エラーステータス */

というプログラミング言語記述のひな形(図26および図27参照)に自動的に変換される。
【0071】
この実施例5では、モジュールのインターフェース仕様と処理フローを記述する手段として、C言語に準じた疑似言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語(例えば「Ada」)に準じたものであっても構わない。
同様に、この実施例5では、モジュールの処理フローの階層構造を記述する手段として、疑似言語のブロック構造(例えば図14および図15中の「{・・・}」)を用いる方法を紹介したが、これは他のいかなる方法(例えばbegin文とend文で下位構造を囲む)であっても構わない。
同様に、この実施例5では、処理説明の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造(例えば「リスト構造」)であっても構わない。
【0072】
次に、従来例と比較して、この実施例5の優れている点について説明する。この実施例5と同じ機能を実現する従来の方法としては次のものが考えられる。
【0073】
その方法とは、モジュールのインターフェース仕様および処理フローをユーザに対話形式で定義させ、それらの情報からプログラミング言語記述のひな形を生成する対話型ツールを開発し提供するというものである。この方法は一見合理的に見えるが、前記実施例1のところでも指摘した通り、対話型ツールを開発するのに相当な費用がかかる(開発コストの問題)、開発した対話型ツールは当該機能専用であり潰しが利かない(投資効果の問題)、ユーザに対話型ツールの使い方を教育する必要がある(教育コストの問題)だけでなく、これらのツールは、一般にモジュールの処理フローを自然言語で記述すること(例えば「××を××する」)ができないので、設計工程であるにもかかわらず、ユーザはプログラミング言語でコーディングするのと変わらないレベルの詳細な情報(例えば「if(a==0){a=a+1;}」)の入力を強要されるという問題がある。
すなわち、この種のツールは、設計工程(モジュールの輪郭を定義することが目的)とコーディング工程(モジュールの詳細を定義することが目的)の境目を不明確にし、結果的にデザインレビュー(設計の再検討)を阻害するという問題を内包している。
【0074】
これに対しこの実施例5を使用した場合、プログラミング言語に準じた疑似言語記述301からプログラミング言語記述のひな形503が自動的に生成されるので、前記実施例3および実施例4を用いてモジュールのインターフェース仕様および処理フロー(疑似言語で記述)に対し十分なデザインレビューを行ってから、その情報をプログラミング言語記述のひな形503に正確に反映させられるという効果がある。これは、前工程(設計)における設計者の意図を後工程(コーディング)を担当するプログラマに正確に伝えられることを意味している。
また、入力となる疑似言語記述301は単なるテキストであり、一般的なテキスト・エディタを用いて作成できるので、新たに専用エディタを開発して提供する必要がないばかりか、ユーザが自分の使い慣れたエディタを用いて仕様記述を作成できるという効果がある。これは、この実施例5が低コストで実現かつ運用可能であることを意味している。
【0075】
以上のようにこの実施例5によれば、図24に示すように、プログラミング言語に準じた疑似言語記述301を入力にすると共に、プログラム生産支援装置中に、字句解析手段302、構文解析手段303、制御構造抽出手段401、制御構造変換手段501および処理説明→コメント変換手段502を設けることにより、前工程(設計)で十分にデザインレビューされた情報(疑似言語記述)を、後工程(コーディング)の入力(プログラミング言語記述のひな形)として流用できるので、設計者の意図をプログラマに正確に伝えることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
【0076】
実施例6.
図29は実施例6のプログラム生産支援装置を示す構成図、図30は実施例6におけるプログラム生産支援装置の動作を示すフローチャート、図31および図32は実施例6の入力である「プログラミング言語記述」の一例を示す図、図33および図34は実施例6の出力である「疑似言語記述」の一例を示す図、図35は実施例6の制御構造抽出手段によって変換され記憶される木構造の一例を示す図、図36は実施例6の制御構造変換手段によって置換された木構造の一例を示す図である。
【0077】
図29において、601は特定のプログラミング言語で記述された「プログラミング言語記述」、602はプログラミング言語記述601を読み込んで字句に分解する「字句解析手段」、603は字句に分解されたプログラミング言語記述601の構文解析を行う「構文解析手段」、604は構文解析手段603によるプログラミング言語記述601の構文解析結果をもとにプログラムの制御構造とそれに付随するコメントを木構造に変換して記憶する「制御構造抽出手段」、605は制御構造抽出手段604によって記憶された木構造をもとにプログラミング言語の制御構造を疑似言語の制御構造に変換する「制御構造変換手段」、606は制御構造抽出手段605によって記憶された木構造をもとにプログラミング言語のコメントを疑似言語の処理説明に変換する「コメント→処理説明変換手段」、301は制御構造変換手段605およびコメント→処理説明変換手段606によって自動生成された「疑似言語記述」である。
【0078】
この実施例6におけるプログラム生産支援装置の動作について、図30に示すフローチャートを用いて説明する。
【0079】
図30において、ステップ(イ)〜(ヘ)は図25のそれと基本的に同じである。両者で異なるのは、図30が「プログラミング言語記述→疑似言語記述」への変換を、図25が「疑似言語記述→プログラミング言語記述」への変換を説明している点である。
【0080】
次に、制御構造変換手段605およびコメント→処理説明変換手段606がプログラミング言語記述601から疑似言語記述301を生成する手順を、図31〜図36を用いて説明する。
【0081】
プログラミング言語から疑似言語への変換に際しては、
(1)モジュールのヘッダー・コメント中のABSTRACT欄、FUNCTION欄、NOTE欄、RETURN欄に記述されたインターフェース仕様、および、モジュールの仮引数の型・名前・コメント、モジュール内で参照している大域変数の型・名前・コメントを、疑似言語における仕様記述部(function spec)の形式に変換して出力する。
(2)モジュール内の制御構造を、疑似言語の制御構造に変換して出力する。
(3)モジュール内のコメントを、疑似言語の処理説明に変換して出力する。
(4)上記(3)の実行に際し、文章の先頭に「?」マークの付いたコメントをそれに対応する条件と置き換え、疑似言語の処理説明に変換して出力する。
(5)上記(3)の実行に際し、break文、return文、exit文の行末にあるコメントをそれに対応する引数と置き換え、疑似言語の処理説明に変換して出力する。
という変換規則を前提としているので、例えば、図31および図32中の
/*
*××を××する
*/
if(global_1==0){ /*?××が××ならば */
/* ××を××する */
function_1();
return -1; /* エラーステータス */

というプログラミング言語記述601は、制御構造抽出手段604によって図35に示す木構造に変換して記憶された後、制御構造変換手段605およびコメント→処理説明変換手段606によって図36のようにif文の条件とreturn文の引数がそれぞれに対応するコメントと置き換えられてから
// ××を××する
if(××が××ならば){
××を××する[function_1];
return エラーステータス;

という疑似言語記述301(図33および図34参照)に自動的に変換される。
【0082】
この実施例6では、入力となるプログラミング言語としてC言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語(例えば「Ada」)であっても構わない。
同様に、この実施例6では、出力としてC言語に準じた疑似言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語(例えば「Ada」)に準じたものであっても構わない。
同様に、この実施例6では、処理説明の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造(例えば「リスト構造」)であっても構わない。
【0083】
次に、従来例と比較して、この実施例6の優れている点について説明する。この実施例6と同じ機能を実現する従来の方法としては次のものが考えられる。
【0084】
その方法とは、プログラミング言語記述の中からモジュールのインターフェース仕様に関する情報を手作業で抽出するというものである。この方法は誰もが無意識に行っていることであるが、情報を抽出するのに膨大な時間が必要(作業コストの問題)となるだけでなく、経験年数などによって作業効率のばらつきが大きい(属人性の問題)、ミスが入り込みやすい(作業品質の問題)など多くの問題がある。
【0085】
これに対しこの実施例6を使用した場合、プログラミング言語記述601からプログラミング言語に準じた疑似言語が自動的に生成されるので、こうして得られた疑似言語記述301に対して前記実施例3および実施例4を適用すれば、結果的に、プログラミング言語記述からモジュールのインターフェース仕様に関する情報を自動的に抽出し、その情報をデザインレビュー用資料307や木構造チャート403の形式で把握できるという効果がある。
実際問題として、ソフトウェアが大規模・複雑化の一途を辿っている現状では、何百、何千とあるモジュールのインターフェース仕様を人間に分かりやすいデザインレビュー用資料307や木構造チャート403の形式で把握できる意義は極めて大きい。
【0086】
以上のようにこの実施例6によれば、図29に示すように、プログラミング言語記述601を入力にすると共に、プログラム生産支援装置中に、字句解析手段602、構文解析手段603、制御構造抽出手段604、制御構造変換手段605およびコメント→処理説明変換手段606を設けることにより、プログラミング言語記述601からモジュールのインターフェース仕様に関する情報を自動的に抽出できるので、実際に動作しているプログラムの仕様を容易かつ正確に把握することが可能となり、結果としてプログラム生産および保守の高品質化に大きく寄与することができる。
【0087】
実施例7.
図37は実施例7のプログラム生産支援装置を示す構成図、図38は実施例70のプログラム生産支援装置の動作を示すフローチャート、図39および図40は実施例7の入力である「プログラミング言語記述」の一例を示す図、図41乃至図43は実施例7の出力である「木構造チャート」の一例を示す図、図44は実施例7の制御構造抽出手段によって変換され記憶される木構造の一例を示す図、図45は実施例7の木構造チャート生成手段によって生成される木構造チャートの一例を示す図、図46は実施例7の不要情報割愛手段701によって補正される木構造の一例を示す図、図47は実施例7の木構造チャート生成手段によって生成される上記とは別の木構造チャートの一例を示す図、図48は実施例7の木構造チャート生成手段によって生成される上記とは更に別の木構造チャートの一例を示す図である。
【0088】
以下、図37の図29と異なる要素について説明する。図37において、701は制御構造抽出手段604によって記憶された木構造をもとにユーザの指定に応じ木構造から不要情報を割愛する「不要情報割愛手段」、702は不要情報割愛手段701によって補正された木構造をもとにプログラミング言語記述601に対応した木構造チャートを自動生成する「木構造チャート生成手段」、703は木構造チャート生成手段702によって自動生成された「木構造チャート」である。
【0089】
この実施例7のプログラム生産支援装置の動作について、図38に示すフローチャートを用いて説明する。図38において、ステップ(イ)〜(ハ)は図6Bのそれと同じである。
以下、図38の図30と異なる動作について説明する。まず、不要情報割愛手段701は、ユーザの指定に応じて、制御構造抽出手段604によって記憶された木構造から何を割愛するかを決定する(図38のステップ(ニ))。
ユーザの指定が「全ての文を木構造チャートに反映せよ」である場合、不要情報割愛手段701は、制御構造抽出手段604によって記憶された木構造に対して何も行わない。
ユーザの指定が「コメントと制御構造のみを木構造チャートに反映せよ」である場合、不要情報割愛手段701は、制御構造抽出手段604によって記憶された木構造からコメントと制御構造以外を削除する(図38のステップ(ホ))。
ユーザの指定が「コメントのみを木構造チャートに反映せよ」である場合、不要情報割愛手段701は、制御構造抽出手段604によって記憶された木構造からコメント以外を削除する(図38のステップ(ヘ))。
次に、木構造チャート生成手段702は、不要情報割愛手段701によって補正された木構造をもとに、プログラミング言語記述601に対応した木構造チャート703(図41、図42、図43参照)を生成する(図38のステップ(ト))。
【0090】
次に、不要情報割愛手段701および木構造チャート生成手段702が、プログラミング言語記述601からユーザの指定に応じ木構造チャート703を生成する手順を図39〜図48を用いて説明する。
【0091】
例えば、図39および図40中の
/*
* ××を××する
*/
local_1=0;
if(global_1==0){
function_1();
return -1;

というプログラミング言語記述は、制御構造抽出手段604によって図44に示す木構造に変換して記憶される。
ユーザの指定が「全ての文を木構造チャートに反映せよ」である場合、不要情報割愛手段701はこの木構造に対して何も行わないので、木構造チャート生成手段702は図45に示す木構造チャート(図41参照)を自動的に生成する。
これに対し、ユーザの指定が「コメントと制御構造のみを木構造チャートに反映せよ」である場合、不要情報割愛手段701は木構造からコメントと制御構造以外を削除し、図46に示すように、木構造を補正するので、木構造チャート生成手段702は図47に示す木構造チャート703(図42参照)を自動的に生成する。
更に、ユーザの指定が「コメントのみを木構造チャートに反映せよ」である場合、不要情報割愛手段701は木構造からコメント以外を全て削除し
××を××する
のように木構造を補正するので、木構造チャート生成手段702は図48に示す木構造チャート703(図43参照)を生成する。
【0092】
この実施例7では、入力となるプログラミング言語としてC言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語(例えば「Ada」)であっても構わない。
同様に、この実施例7では、具体的な木構造チャート703としてNTT(株)で考案されたHCPチャートを用いる方法を紹介したが、これは他のいかなる木構造チャート(例えば日本電気(株)のSPD)であっても構わない。
同様に、この実施例7では、処理説明の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造(例えば「リスト構造」)であっても構わない。
【0093】
次に、従来例と比較して、この実施例7の優れている点について説明する。
【0094】
従来、プログラミング言語記述から木構造チャートを自動生成するツールとしては既に幾つかのものが知られているが、それらは一様にプログラミング言語記述中の文をありのまま木構造チャートに反映するものであり、大規模なプログラムに適用した場合には木構造チャートが詳細すぎて、プログラムの大まかな流れを把握する目的では使い物にならないという問題があった。
【0095】
これに対しこの実施例7を使用した場合、ユーザの指定に応じて「プログラミング言語記述中の全ての文を木構造チャートに反映する」、「コメントと制御構造のみを木構造チャートに反映する」、「コメントのみを木構造チャートに反映する」、といった具合に木構造チャート703の粗さを調整できるので、「処理内容を逐一チェックしたい」、「プログラムの大まかな流れを把握したい」、「処理の概要を把握したい」という目的に応じた木構造チャート703を生成できるという効果がある。
【0096】
以上のようにこの実施例7によれば、図37に示すように、プログラミング言語記述601を入力にすると共に、プリンタ生産支援装置中に、字句解析手段602、構文解析手段603、制御構造抽出手段604、不要情報割愛手段701および木構造チャート生成手段702を設けることにより、プログラミング言語記述601からユーザの要求に応じた木構造チャート703を生成することができ、結果としてプログラム生産および保守の高品質化に大きく寄与することができる。
【0097】
実施例8.
図49は実施例8のプログラム生産支援装置を示す構成図、図50は実施例8のプログラム生産支援装置の動作を示すフローチャート、図51および図52は実施例8の入力である「プログラミング言語記述」の一例を示す図、図53は実施例8の出力である「モジュール仕様書」の一例を示す図である。
図49の図29と異なる要素について説明する。図49において、801は構文解析手段603によるプログラミング言語記述601の構文解析結果をもとにモジュールのインターフェース仕様を記憶する「インターフェース仕様抽出手段」、802は構文解析手段603によるプログラミング言語記述601の構文解析結果をもとにモジュールの定義・参照情報を記憶する「モジュール定義・参照抽出手段」、803はインターフェース仕様抽出手段801およびモジュール定義・参照抽出手段802によって記憶された情報をもとにモジュール名を照合する「モジュール名照合手段」、804はインターフェース仕様抽出手段801およびモジュール定義・参照抽出手段802によって記憶された情報をもとにプログラミング言語記述601に対応したモジュール仕様書を自動生成する「モジュール仕様書生成手段」、805はモジュール仕様書生成手段804によって自動生成された「モジュール仕様書」である。
【0098】
この実施例8のプログラム生産支援装置の動作について、図50に示すフローチャートを用いて説明する。
【0099】
図50において、ステップ(イ)〜(ロ)は図30のそれと同じである。
以下、図50の図30と異なる動作について説明する。まず、インターフェース仕様抽出手段801は、構文解析手段603によるプログラミング言語記述601の構文解析結果をもとに、モジュールのヘッダーコメント中の各欄(例えば図51および図52中の「MODULE」欄)に記述されたインターフェース仕様を抽出して記憶する(図50のステップ(ハ))。
次に、モジュール定義・参照抽出手段802は、構文解析手段603によるプログラミング言語記述601の構文解析結果をもとに、モジュールの定義(例えば図51および図52中の「void main(){・・・}」)および、モジュールの参照情報を抽出して記憶する(図50のステップ(ニ))。
次に、モジュール名照合手段803は、インターフェース仕様抽出手段801およびモジュール定義・参照抽出手段802によって記憶された情報をもとに、ヘッダーコメント中の「MODULE」欄に記述されている名前と、そのヘッダーコメントに対応するモジュール定義の名前を照合する(図50のステップ(ホ))。
モジュール名が一致した場合、モジュール仕様書生成手段804は、インターフェース仕様抽出手段801およびモジュール定義・参照抽出手段802によって記憶された情報をもとに、プログラミング言語記述601に対応したモジュール仕様書805を生成する(図50のステップ(ヘ))。
モジュール名が一致しなかった場合、モジュール仕様書生成手段804は、エラーメッセージを出力してその旨をユーザに報告しモジュール仕様書805の生成を中止する(図50のステップ(ト))。
【0100】
この実施例8では、入力となるプログラミング言語としてC言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語(例えば「Ada」)であっても構わない。
【0101】
次に、従来例と比較して、この実施例8の優れている点について説明する。
【0102】
従来、プログラミング言語記述からモジュール仕様書を自動生成するツールとしては既に幾つかのものが知られているが、それらは一様に、ヘッダーコメント中から抽出したインターフェース仕様を、その直後に記述されているモジュール定義と盲目的に対応付けてモジュール仕様書を生成する様になっている為、ヘッダーコメント中に記述されたインターフェース仕様がモジュール定義と対応していなくてもモジュール仕様書が生成されるという問題があった。
現実問題として、仕様書から内容を判断して作業しなければならない場合も多いので、でたらめな仕様書がソフトウェア生産全体に与える影響は無視できない。 勿論、ヘッダーコメントを記述する際に細心の注意を払っていれば問題ないのだが、実際には
(1)最初のモジュールに対してヘッダーコメントを作成する。
(2)それをテンプレートにして2番目のヘッダーコメントを作成する。
(3)以下、全てのモジュールに対して(2)を繰り返す。
といった手順で作業した方が合理的なので、往々にして無関係なヘッダーコメントの付いたモジュールが発生する。
大規模なプログラムではモジュールの数が1000を越えることも珍しくないだけに、一旦紛れ込んだミスを見つけるのはこの問題がプログラムの動作に影響しない分だけ余計に厄介である。
【0103】
これに対しこの実施例8を使用した場合、ヘッダーコメント中の「MODULE」欄に記述された名前とそのヘッダーコメントに対応するモジュール定義の名前が一致しないと、エラーメッセージが出力されモジュール仕様書805の生成が中止されるので、この種の事故を未然に、かつ確実に防ぐことができるという効果がある。
【0104】
以上のようにこの実施例8によれば、図49に示すように、プログラミング言語記述601を入力にすると共に、プログラム生産支援装置中に、字句解析手段602、構文解析手段603、インターフェース仕様抽出手段801、モジュール定義・参照抽出手段802、モジュール名照合手段803およびモジュール仕様書抽出手段804を設けることにより、プログラミング言語記述601から実際のモジュール定義に正確に対応したモジュール仕様書805を自動生成することができ、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
【0105】
実施例9.
図54は実施例9プログラム生産支援装置を示す構成図、図55は実施例9におけるプログラム生産支援装置の動作を示すフローチャート、図56および図57は実施例9の入力である「プログラミング言語記述」の一例を示す図、図58は従来の「モジュール構成図」の一例を示す図、図59は実施例9の出力である「モジュール構成図」の一例を示す図、図60は実施例9のモジュール定義・参照抽出手段によって変換され記憶される木構造の一例を示す図、図61は実施例9の同一構造割愛手段によって補正された木構造の一例を示す図である。
【0106】
図54の図29と異なる要素について説明する。図54において、802は構文解析手段603によるプログラミング言語記述601の構文解析結果をもとにモジュールの定義・参照情報を記憶する「モジュール定義・参照抽出手段」、901はモジュール定義・参照抽出手段802によって記憶された木構造をもとに木構造上の同一構造を割愛する「同一構造割愛手段」、902は同一構造割愛手段901によって補正された木構造をもとにプログラミング言語記述601に対応したモジュール構成図を自動生成する「モジュール構成図生成手段」、903はモジュール構成図生成手段902によって自動生成された「モジュール構成図」である。
【0107】
この実施例9におけるプログラム生産支援装置の動作について、図55に示すフローチャートを用いて説明する。図55において、ステップ(イ)〜(ロ)は図30のそれと同じである。
以下、図55の図30と異なる動作について説明する。まず、モジュール定義・参照抽出手段802は、構文解析手段603によるプログラミング言語記述601の構文解析結果をもとに、モジュールの定義(例えば図56および図57中の「main(){・・・}」)およびモジュールの参照(例えば図56および図57中の「sub();」)を木構造に変換して記憶する(図55のステップ(ハ))。
次に、同一構造割愛手段901は、モジュール定義・参照抽出手段802によって記憶された木構造をもとに、木構造上から同一構造を摘出する(図55のステップ(ニ))。
同一構造が摘出できなかった場合、同一構造割愛手段901は、モジュール定義・参照抽出手段802によって記憶された木構造に対して何も行わない。
同一構造が摘出された場合、同一構造割愛手段901は、モジュール定義・参照抽出手段802によって記憶された木構造上から同一構造を削除し「〜と同じ」という情報で置換する(図55のステップ(ホ))。
次に、モジュール構成図生成手段902は、同一構造割愛手段901によって補正された木構造をもとに、プログラミング言語記述601に対応したモジュール構成図903(図59参照)を自動生成する(図55のステップ(ヘ))。
【0108】
次に、同一構造割愛手段901およびモジュール構成図生成手段902がプログラミング言語記述601からモジュール構成図903を生成する手順を、図56および図57、図59を用いて説明する。
【0109】
例えば、図56および図57中の
main()

sub();
sub();

sub()

sub2();
sub2();

sub2()

sub3();
sub3();

というプログラミング言語記述601は、モジュール定義・参照抽出手段802によって図60に示す木構造に変換して記憶された後、同一構造割愛手段901によって、木構造を根元から辿りながら同一構造を順次「〜と同じ」という情報で置換することによって図61に示す木構造に補正され、モジュール構成図生成手段902によって、図59に示すモジュール構成図903が自動的に生成される。
ちなみに、従来の方法では同一構造が割愛されない為に、結果として図58に示す冗長なモジュール構成図が生成される。
【0110】
この実施例9では、入力となるプログラミング言語としてC言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語(例えば「Ada」)であっても構わない。
同様に、この実施例9では、処理説明の階層構造を記憶する手段として木構造を用いる方法を紹介したが、これは他のいかなるデータ構造(例えば「リスト構造」)であっても構わない。
【0111】
次に、従来例と比較して、この実施例9の優れている点について説明する。
【0112】
従来、プログラミング言語記述からモジュール構成図を自動生成するツールとしては既に幾つかのものが知られているが、それらが生成するモジュール構成図は一様に図58の出力形式に準じたものであり、同一モジュールの参照が随所に現われる大規模プログラム(数万行以上)では、生成されるモジュール構成図が冗長(場合によってはA4版で数百ページ)になりすぎて使い物にならないという問題があった。
【0113】
これに対しこの実施例9を使用した場合、モジュール構成図903上の同一構造が「〜と同じ」という情報で置換されるので、同一モジュールの参照が随所に現われるような大規模プログラムでは、それに対するモジュール構成図903が劇的に簡素化(圧縮)されるという効果がある。
【0114】
以上のようにこの実施例9によれば、図54に示すように、プログラミング言語記述601を入力にすると共に、プログラム生産支援装置中に、字句解析手段602、構文解析手段603、モジュール定義・参照抽出手段802、同一構造割愛手段901およびモジュール構成図生成手段902を設けることにより、プログラミング言語記述601から実用的なモジュール構成図903を自動生成することができ、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
【0115】
実施例10.
図62は実施例10のプログラム生産支援装置を示す構成図、図63は実施例10におけるプログラム生産支援装置の動作を示すフローチャート、図64乃至図67は実施例10の入力である「プログラミング言語記述」の一例を示す図、図68は従来の「シンボル一覧表」の一例を示す図、図69は実施例10の出力である「シンボル一覧表」の一例を示す図である。
【0116】
図62の図29と異なる要素について説明する。図62において、1001は構文解析手段603によるプログラミング言語記述601の構文解析結果をもとにシンボルの定義情報を記憶する「シンボル定義抽出手段」、1002はシンボル定義抽出手段1001によって記憶された情報をもとにシンボルの定義情報を定義位置の順に並べ換える「シンボル定義並換え手段」、1003はシンボル定義並換え手段1002によって並べ換えられた情報をもとにプログラミング言語記述601に対応したシンボル一覧表を自動生成する「シンボル一覧表生成手段」、1004はシンボル一覧表生成手段1003によって自動生成された「シンボル一覧表」である。
【0117】
この実施例10におけるプログラム生産支援装置の動作について、図63に示すフローチャートを用いて説明する。
【0118】
図63において、ステップ(イ)〜(ロ)は図30のそれと同じである。
以下、図63の図30と異なる動作について説明する。まず、シンボル定義抽出手段1001は、構文解析手段603によるプログラミング言語記述601の構文解析結果をもとに、シンボルの定義(例えば図64乃至図67中の「function_1(){}」)を辞書順に記憶する(図63のステップ(ハ))。
次に、シンボル定義並換え手段1002は、シンボル定義抽出手段1001によって記憶された情報をもとに、シンボルの定義情報を定義位置(例えば「module-list.cの6行目」)の順に並べ換える(図63のステップ(ニ))。
次に、シンボル一覧表生成手段1003は、シンボル定義並換え手段1002によって並べ換えられた情報をもとに、プログラミング言語記述601に対応したシンボル一覧表1004を自動生成する(図63のステップ(ホ))。
【0119】
この実施例10では、入力となるプログラミング言語としてC言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語(例えば「Ada」)であっても構わない。
同様に、この実施例10では、シンボルの例としてモジュール定義を対象とする方法を紹介したが、これは他のいかなるシンボル(例えば「大域変数」や「マクロ」)であっても構わない。
【0120】
次に、従来例と比較して、この実施例10の優れている点について説明する。
【0121】
従来、プログラミング言語記述からシンボル一覧表を自動生成するツールとしては既に幾つかのものが知られているが、それらが生成するシンボル一覧表は一様に図68の出力形式に準じたものである。
この種の表は特定のシンボルがどこで定義されているかを探す手掛かりとしては有用であるが、一般にモジュールや大域変数といったシンボルは、関連性の強いもの同士が一箇所(特定のファイル内)に固めて定義される傾向がある為、辞書順にシンボル名を並べる方法だと、例えば
int x_axis; /*X座標 */
int y_axis; /*Y座標 */
という定義が一覧表上ではばらばらに出力されてしまう可能性が高い。
従って、辞書順にシンボルを出力する形式のシンボル一覧表では、定義順序に込められたプログラマの意図をないがしろにしてしまうという問題があった。
【0122】
これに対しこの実施例10を使用した場合、プログラミング言語記述601中に定義された順にシンボルが出力されるので、定義順序に込められたプログラマの意図がありのまま表現されるという効果がある。
【0123】
以上のようにこの実施例10によれば、図62に示すようにプログラミング言語記述601を入力にすると共に、プログラム生産支援装置中に、字句解析手段602、構文解析手段603、シンボル定義抽出手段1001、シンボル定義並換え手段1002およびシンボル一覧表生成手段1003を設けることにより、プログラミング言語記述601から実用的なシンボル一覧表1004を自動生成することができ、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
【0124】
実施例11.
図70は実施例11のプログラム生産支援装置を示す構成図、図71は実施例11におけるプログラム生産支援装置の動作を示すフローチャート、図72および図73は実施例11の入力である「プログラミング言語記述」の一例を示す図、図74は実施例11の出力である「警告メッセージ」の一例を示す図である。
【0125】
図70の図29と異なる要素について説明する。図70において、1101は字句解析手段602によって字句に分解されたプログラミング言語記述601をもとに字句の並びの中から特定パターンを検出する「特定パターンの検出手段」、1102は特定パターンの検出手段1101によって出力された「警告メッセージ」である。
【0126】
この実施例11におけるプログラム生産支援装置の動作について、図71に示すフローチャートを用いて説明する。
【0127】
図71において、ステップ(イ)は図30のそれと同じである。
以下、図71の図30と異なる動作について説明する。まず、特定パターンの検出手段1101は、字句解析手段602によって字句に分解されたプログラミング言語記述601をもとに、それらの字句がプログラムのどこに現われたかを見極め、特定の場所(例えば条件の中)に現われた字句の並びだけを抽出する(図71のステップ(ロ))。
次に、特定パターンの検出手段1101は、特定の場所に現われた字句の並びを並びのパターンによって選別し経験則と照合する(図71のステップ(ハ))。
字句の並びが経験則と一致した場合、特定パターンの検出手段1101は、その旨を通知する警告メッセージ1102を出力する(図71のステップ(ニ))。
【0128】
次に、特定パターンの検出手段1101が、プログラミング言語記述601(図72および図73参照)から文法的には問題ないが意味的にはエラーである可能性の高いことが知られている記述を検出する手順を、図72〜図74を用いて説明する。
【0129】
例えば、図72および図73中の
if(a=0){
function();

というC言語記述は文法的には正しい為、この記述に対しC言語のコンパイラはいかなるエラーメッセージも出力しない。
ところが、C言語において「if(a=0)」という条件が成立することはありえない為、結果的に「function();」という決して実行されることのない死角が発生する。
このような記述に対し、特定パターンの検出手段1101は、特定の場所(この場合は「条件の中」)に現われた字句の並び(この場合は「a=0」)だけに着目し、それを
条件の中に代入演算子「=」が単独で現われるのはおかしい
条件の中にビット演算子「|」が単独で現われるのはおかしい
といった一連の経験則と照合することにより、それが経験則と合致する場合には
演算子「==」と「=」を間違えている可能性があります
といった警告メッセージを出力し、文法的には正しいが意味的にはエラーである可能性が高い記述を摘出する。
【0130】
次に、従来例と比較して、この実施例11の優れている点について説明する。この実施例11と同じ機能を実現する従来の方法としては次のものが考えられる。
【0131】
その方法とは、プログラミング言語記述の中から文法的には正しいが意味的にはエラーである可能性が高い記述を、自分の経験だけを頼りに手作業で摘出するというものである。この方法は誰もが無意識に行っていることであるが、問題を摘出するのに膨大な時間が必要(作業コストの問題)となるだけでなく、経験年数などによって作業効率のばらつきが大きい(属人性の問題)、ミスが入り込みやすい(作業品質の問題)など多くの問題がある。
【0132】
これに対しこの実施例11を使用した場合、プログラミング言語記述601から文法的には正しいが意味的にはエラーである可能性が高い記述を自動的に検出できるので、同様な作業を人間が行った場合に比べ、問題点の摘出に要する時間を桁違いに短縮(数日に対して数秒)できるだけでなく、チェック漏れ、チェックミスといったことが全く無くなるという効果がある。
【0133】
以上のようにこの実施例11によれば、図70に示すように、プログラミング言語記述601を入力にすると共に、プログラム生産支援装置中に、字句解析手段602、特定パターンの検出手段1101を設けることにより、プログラミング言語記述601から文法的には正しいが意味的にはエラーである可能性が高い記述を自動的に検出できるので、結果としてプログラム生産の高品質化に大きく寄与することができる。
【0134】
実施例12.
図75は実施例12のプログラム生産支援装置を示す構成図、図76は実施例12におけるプログラム生産支援装置の動作を示すフローチャート、図77は実施例12の入力である「プログラミング言語記述」の一例を示す図、図78は実施例12の出力である「加工されたプログラミング言語記述」の一例を示す図、図79は実施例12によって加工されたプログラムの「実行結果」の一例を示す図である。
【0135】
図75の図29と異なる要素について説明する。図75において、1201は構文解析手段603によるプログラミング言語記述601の構文解析結果をもとにプログラミング言語記述601の特定箇所にプログラムの実行を追跡する為の実行追跡処理を埋込む「実行追跡処理埋込み手段」、1202は実行追跡処理埋込み手段1201によって実行追跡処理を埋め込まれた「加工されたプログラミング言語記述」である。
【0136】
この実施例12におけるプログラム生産支援装置の動作について、図76に示すフローチャートを用いて説明する。
【0137】
図76において、ステップ(イ)〜(ロ)は図30のそれと同じである。
以下、図76の図30と異なる動作について説明する。まず、実行追跡処理埋込み手段1201は、構文解析手段603によるプログラミング言語記述601の構文解析結果をもとに、プログラム中の位置によって処理を振り分ける(図76のステップ(ハ))。
プログラム中の位置が「モジュールの先頭」である場合、実行追跡処理埋込み手段1201は、プログラムのブロックを一つ深くして実行追跡処理を埋込む(図76のステップ(ニ))。
プログラム中の位置が「モジュールの末尾」である場合、実行追跡処理埋込み手段1201は、プログラムのブロックを一つ深くして実行追跡処理を埋込む(図76のステップ(ホ))。
プログラム中の位置が「return文の所」である場合、実行追跡処理埋込み手段1201は、return文を囲む局所的なブロックを作って実行追跡処理を埋込む(図76のステップ(ヘ))。
プログラム中の位置が「普通の実行文の所」である場合、実行追跡処理埋込み手段1201は、実行文の直前に局所的なブロックを作って実行追跡処理を埋込む(図76のステップ(ト))。
【0138】
次に、実行追跡処理埋込み手段1201がプログラミング言語記述601(図77参照)に対して実行追跡処理を埋め込む手順を、図77、図78を用いて説明する。
例えば、図77中において1〜2行目の
main()

が「モジュールの先頭」という条件に該当するが、この行に対して実行追跡処理埋込み手段1201は、
main()
{ {
の様に2行目の「{」の外側にもう一つ「{」を追加してブロックを一つ深くした上で、
main()
{_probe(*+*,”main”,”sample.c”,2);{
の様に「{」と「}」の間にプログラムの実行追跡処理を埋め込む。これにより、元のプログラムの動作には一切干渉せず当該プログラムの実行を追跡することが可能となる。
尚、こうして埋め込まれた「_probe」というモジュールには、それが埋め込まれた「プログラム中の論理的な位置(この場合はモジュールの実行開始を示す「+」)」、「モジュールの名前(この場合は「main」)」、「物理的な位置(この場合は「sample.cというファイルの2行目」)」という情報が引数で渡される為、後ほどこのプログラムを実行した時にどの「_probe」であるかを容易に判断することができる。
同様に、図77において10行目の

が「モジュールの末尾」という条件に該当するが、この行に対して実行追跡処理埋込み手段1201は、
} }
の様に10行目の「}」の外側にもう一つ「}」を追加してブロックを一つ深くした上で、
}_probe(*-*,”main”,”sample.c”,10);}
のように「}」と「}」の間にプログラムの実行追跡処理を埋め込む。
「モジュールの先頭」の場合と同様、こうして埋め込まれた「_probe」というモジュールには、それが埋め込まれた「プログラム中の論理的な位置(この場合はモジュールの実行終了を示す「-」)」、「モジュールの名前(この場合は「main」)」、「物理的な位置(この場合は「sample.cというファイルの10行目」)」という情報が引数で渡される。
同様に、図77において8行目の
return(sub());
が「return文の所」という条件に該当するが、この行に対して実行追跡処理埋込み手段1201は、
{return(sub());}
のように8行目のreturn文を「{」と「}」で囲んで局所的なブロックに封じ込めた上で、
{int tmp;tmp=sub();_probe(*-*,肯ain”,行ample.c”,8);return(tmp);}
のように、return文の引数を一旦一時変数に退避する処理と、return文との間にプログラムの実行追跡処理とを埋め込む。
「モジュールの先頭」の場合と同様、こうして埋め込まれた「_probe」というモジュールには、それが埋め込まれた「プログラム中の論理的な位置(この場合はモジュールの実行終了を示す「-」)」、「モジュールの名前(この場合は「main」)」、「物理的な位置(この場合は「sample.cというファイルの8行目」)」という情報が引数で渡される。
尚、return文の引数を一旦一時変数に退避しているのは、return文の引数が関数参照である場合にプログラムの実行追跡結果が
main:sample.cの2行目[モジュールの実行開始]
main:sample.cの5行目
main:sample.cの8行目[モジュールの実行終了]
sub:sample.cの13行目[モジュールの実行開始]
sub:sample.cの14行目
sub:sample.cの15行目[モジュールの実行終了]
のように見かけ上おかしくなるのを回避する為である。
ちなみに、この実施例12の方法では
main:sample.cの2行目[モジュールの実行開始]
main:sample.cの5行目
sub:sample.cの13行目[モジュールの実行開始]
sub:sample.cの14行目
sub:sample.cの15行目[モジュールの実行終了]
main:sample.cの8行目[モジュールの実行終了]
のように実際の実行順序に従って正しく報告される。
同様に図77において6行目の
i=1;
が「普通の実行文の所」という条件に該当するが、この行に対して実行追跡処理埋込み手段1201は、
{ } i=1;
のように実行文の直前に「{」と「}」で囲まれた局所的なブロックを作った上で、
{_probe(*=*,”main”,”sample.c”,6);} i=1;
のように「{」と「}」の間にプログラムの実行追跡処理を埋め込む。
「モジュールの先頭」の場合と同様に、こうして埋め込まれた「_probe」というモジュールには、それが埋め込まれた「プログラム中の論理的な位置(この場合はモジュールの実行途中を示す「=」)」、「モジュールの名前(この場合は「main」)」、「物理的な位置(この場合は「sample.cというファイルの6行目」)」という情報が引数で渡される。
【0139】
この実施例12では、入力となるプログラミング言語としてC言語を用いる方法を紹介したが、これは他のいかなるプログラミング言語(例えば「Ada」)であっても構わない。
同様に、この実施例12では、全ての実行文を対象とする方法を紹介したが、これは「モジュールの開始と終了」だけを対象とするものであっても構わない。
【0140】
次に、従来例と比較して、この実施例12の優れている点について説明する。この実施例12と同じ機能を実現する従来の方法としては次のものが考えられる。
【0141】
その方法とは、プログラミング言語記述の任意の場所にプログラムの実行追跡処理を手作業で埋め込むというものである。この方法はコンピュータの歴史が始まった頃から行われているが、実行追跡処理を埋め込むのに膨大な時間が必要(作業コストの問題)となるだけでなく、経験年数などによって作業効率のばらつきが大きい(属人性の問題)、ミスが入り込みやすい(作業品質の問題)、プログラミング言語記述を修正する度に実行追跡処理を埋め込み直す必要があるなど多くの問題がある。
【0142】
これに対しこの実施例12を使用した場合、プログラムの実行追跡処理がプログラミング言語記述601中に自動的に埋め込まれるので、同様な作業を人間が行った場合に比べ、実行追跡処理の埋め込みに要する時間を桁違いに短縮(数日に対して数秒)できるだけでなく、埋め込み漏れ、埋め込みミスといった事が全く無くなるという効果がある。
更に、
(1)入力となるプログラミング言語記述を読み込む。
(2)プログラミング言語記述に実行追跡処理を埋め込む。
(3)加工したプログラミング言語記述を別のファイルに出力する。
(4)出力されたファイルをコンパイルして実行モジュールを生成する。
という手順を踏めば、
オリジナルのプログラミング言語記述601を一切変更せずに実行追跡処理を埋め込んだ実行モジュールを生成できるので、プログラミング言語記述601に直接実行追跡処理を埋め込むことによる弊害、
すなわち、
・プログラミング言語記述が汚くなる(可読性、保守性が低下する)。
・実行追跡処理を埋め込む前の状態に戻せない。
といった問題を完全に解消できるという効果がある。
【0143】
以上のようにこの実施例12によれば、図75に示すように、プログラミング言語記述601を入力にする字句解析手段602、構文解析手段603、および実行追跡処理埋込み手段1201を設けることにより、プログラミング言語記述601にプログラムの実行追跡処理を自動的に埋め込むことができるので、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
【0144】
実施例13.
図80は実施例13のプログラム生産支援装置を示す構成図である。図80において、101は各機能の階層構造と種別が記述された「仕様記述」、106は前記実施例1によって自動生成された「機能構成図」、1301は前記実施例2によって自動生成された「疑似言語記述のひな形」、301はモジュールのインターフェース仕様と処理フローが記述された「疑似言語記述」、307は前記実施例3によって自動生成された「デザインレビュー用資料」、403は、前記実施例4によって自動生成された「木構造チャート」、503は前記実施例5によって自動生成された「プログラミング言語記述のひな形」、601は特定のプログラミング言語で記述された「プログラミング言語記述」、703は前記実施例7によって自動生成された「木構造チャート」、805は前記実施例8によって自動生成された「モジュール仕様書」、903は前記実施例9によって自動生成された「モジュール構成図」、1004は前記実施例10によって自動生成された「シンボル一覧表」、1102は前記実施例11によって自動出力された「警告メッセージ」、1202は前記実施例12によって自動生成された「加工されたプログラミング言語記述」である。
【0145】
この実施例13のプログラム生産支援装置は、本発明の第1〜12の実施例によって構成されているので、それぞれの部分の動作は第1〜12の実施例で説明した通りである。
【0146】
この実施例13では前記実施例1〜12を全て組み合わせたものを紹介したが、この発明は前記実施例1〜12を任意に組み合わせたものであっても適用できる。
【0147】
次に、従来例と比較して、この実施例13の優れている点について説明する。この実施例13と同じ機能を実現する従来の方法としては次のものが考えられる。
【0148】
その方法とは、
(1)プログラムの機能構成を決定する。
(2)ワープロなどを用いてそれらの情報を手作業で機能構成図の形にまとめる。
(3)機能構成図を見ながら手作業でモジュール分割を行う。
(4)モジュールのインターフェース仕様と処理フローを決定する。
(5)ワープロなどを用いてそれらの情報を手作業で仕様書の形にまとめる。
(6)仕様書を見ながらプログラミング言語記述を手作業でコーディングする。
(7)プログラミング言語記述を見ながら必要な図表を手作業で作成する。
(8)プログラムの実行追跡処理を手作業で埋め込む。
(9)プログラムを実行する。
というものである。
この方法は現在一般的に行われているものであり現実的ではあるが、手作業が主体である以上は、それぞれの作業に膨大な時間が必要(作業コストの問題)となるだけでなく、作業のやり方に個人差が出る(属人性の問題)、ミスが入り込みやすい(作業品質の問題)など多くの問題がある。
個々の作業を人手で行っている限り本質的にこれらの問題を解決することは不可能である。
【0149】
これに対しこの実施例13を使用した場合、事務的な作業(例えば機能構成図の作成など)が全て自動的に行われるので、同じ作業を人間が手作業で行う場合に比べ、作業効率および品質が格段に高くなる(理論的にミスは発生しない)という効果がある。
更に、前工程で作成されレビューされた情報(仕様記述、疑似言語記述など)を後工程の入力(ひな形)として流用できるので、前工程を担当した作業者の意図を後工程の作業者に正確に伝えられるという効果がある。
また、それぞれの段階で利用される入力は単なるテキストであり、一般的なテキスト・エディタを用いて作成できるので、新たに専用エディタを開発して提供する必要がないばかりか、ユーザが自分の使い慣れたエディタを用いて仕様記述を作成できるという効果がある。これはこの実施例13が、低コストで実現かつ運用可能であることを意味している。
【0150】
以上のようにこの実施例13によれば、前記実施例1〜12のいずれか2つ以上の組み合わせを利用することにより、プログラム生産における事務的な処理を自動化できると共に、前工程で作成されレビューされた情報を後工程の入力として流用できるので、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
【0151】
【発明の効果】
以上のように、本発明に係るプログラム生産支援装置は、自然言語と各機能の階層構造を示す記号とで記述された仕様記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された仕様記述の構文解析を行う構文解析手段と、構文解析結果をもとに各機能の階層構造を抽出する階層構造抽出手段と、上記抽出された階層構造をもとに上記仕様記述に対応した図または自然言語及びプログラミング言語に準じた制御構造で記述された疑似言語記述を生成する生成手段とを有しているので、機能構成図または疑似言語記述の作成に要する時間を大幅に短縮できると共に、機能構成図または疑似言語の品質を格段に高めることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
【0152】
さらに、仕様記述に、種別を示す記号を記述し、生成手段が、上記種別に従って、ディレクトリ、ファイル、またはモジュールの少なくとも1つを生成する場合には、プログラムを実現するのに必要なディレクトリ、ファイル、モジュールを自動生成できると共に、前工程の設計情報(機能構成)を後工程に忠実に伝えることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
【0153】
また、本発明に係るプログラム生産支援装置は、自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、汎用のテキストエディタを用いて入力及び編集可能な疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有しているので、汎用のテキストエディタ等を用いてデータの入力や編集を可能にすると共に、必要な資料、図またはプログラミング言語記述を生成することができる。
また、この発明に係るプログラム生産支援装置は、自然言語とプログラミング言語に準じた制御構造で記述された疑似言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解された疑似言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記疑似言語に対応した資料、図またはプログラミング言語記述を生成する生成手段とを有し、上記疑似言語記述には、インターフェース仕様が記述された仕様記述部とモジュールの定義・参照が記述されたロジック記述部とが記述されており、上記生成手段が、構文解析結果をもとに上記仕様記述部に記述されたインターフェース仕様を抽出するインターエース仕様抽出手段と、上記構文解析結果をもとに上記ロジック記述部に記述されたモジュールの定義・参照を抽出するモジュール定義・参照抽出手段と、上記抽出されたインターフェース仕様及びモジュールの定義・参照をもとに上記疑似言語記述に対応したデザインレビュー用資料を生成するデザインレビュー用資料生成手段とを有しているので、デザインレビュー用資料の作成に要する時間を大幅に短縮できると共に、デザインレビュー用資料の品質を格段に高めることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
【0154】
また、生成手段が、構文解析結果をもとに自然言語で記述されている処理説明および制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語記述に対応した木構造チャートを生成する木構造チャート生成手段とを有する場合には、木構造チャートの作成に要する時間を大幅に短縮できると共に、木構造チャートの品質を格段に高めることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
【0155】
さらに、生成手段が、構文解析結果をもとに自然言語で記述されている処理説明及び制御構造を木構造に変換して記憶する制御構造抽出手段と、変換された木構造をもとに疑似言語の制御構造をそれに対応するプログラミング言語の制御構造に変換する制御構造変換手段と、上記変換された木構造をもとに疑似言語の処理説明をプログラミング言語のコメントに変換する手段とを有する場合には、前工程(設計)で十分にデザインレビューされた情報(疑似言語記述)を後工程(コーディング)の入力(プログラミング言語記述のひな形)として流用できるので、設計者の意図をプログラマに正確に伝えることができ、結果としてプログラム生産の高品質化に大きく寄与することができる。
【0156】
また、本発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した自然言語とプログラミング言語に準じた制御構造とがテキストで記述され、条件文の条件式が自然言語で記述された疑似言語記述を生成する生成手段とを有しているので、汎用のテキストエディタ等を用いてデータの入力や編集を可能にすると共に、必要な疑似言語記述を生成することができる。
【0157】
また、プログラミング言語は、条件文、この条件文中の条件式に対するコメント、及びモジュール内のコメントを有するものであって、生成手段が、構文解析結果をもとにプログラムの制御構造及びそれに付随するコメントを抽出する制御構造抽出手段と、上記制御構造をもとにプログラミング言語の制御構造を自然言語及び上記プログラミング言語に準じた制御構造で記述された疑似言語の制御構造に変換する制御構造変換手段と、上記制御構造をもとに上記プログラミング言語のモジュール内のコメントを疑似言語の処理説明に変換すると共に上記プログラミング言語の条件文の条件式を上記条件式に対するコメントに置き換え、上記条件文中の条件式、条件式に対するコメント、及び上記モジュール内のコメントを上記疑似言語の自然言語で記述された処理説明に変換する手段とを有する場合には、プログラミング言語記述からモジュールのインターフェース仕様に関する情報を自動的に抽出できるので、実際に動作しているプログラムの仕様を容易かつ正確に把握することが可能となり、結果としてプログラム生産および保守の高品質化に大きく寄与することができる。
【0158】
また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、構文解析結果をもとにプログラミング言語記述のヘッダーコメントに記述されたインターフェース仕様を抽出するインターフェース仕様抽出手段と、構文解析結果をもとに上記プログラミング言語記述のモジュールの定義・参照を木構造に変換して記憶するモジュール定義・参照抽出手段と、ヘッダーコメント中のモジュール欄の名称が実際のモジュール名に一致しているかを照合するモジュール名照合手段と、上記インターフェース仕様及び上記木構造をもとにプログラミング言語記述に対応したモジュール仕様書を生成するモジュール仕様生成手段とを有しているので、プログラミング言語記述から実際のモジュール定義に正確に対応したモジュール仕様書を自動生成することができ、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
【0159】
また、この発明に係るプログラム生産支援装置は、特定のプログラミング言語で記述されたテキストのプログラミング言語記述を読み込みその内容を字句に分解する字句解析手段と、字句に分解されたプログラミング言語記述の構文解析を行う構文解析手段と、構文解析結果をもとに上記プログラミング言語に対応した図、表または言語記述を生成する生成手段とを有し、上記生成手段が、構文解析結果をもとにシンボルの定義情報を記憶するシンボル定義抽出手段と、上記シンボルの定義情報をシンボルが定義された順に並び換えるシンボル定義並び換え手段と、上記シンボルの定義情報をもとにプログラミング言語記述に対応したシンボル一覧表を生成するシンボル一覧表生成手段とを有しているので、プログラミング言語記述から実用的なシンボル一覧表を自動生成することができ、結果としてプログラム生産および保守の合理化に大きく寄与することができる。
【図面の簡単な説明】
【図1】 実施例1のプログラム生産支援装置を示す構成図である。
【図2】 実施例1のフローチャートである。
【図3】 実施例1の仕様記述(入力)の一例を示す図である。
【図4】 実施例1の仕様記述(入力)の一例の続きを示す図である。
【図5】 実施例1の機能構成図(出力)の一例を示す図である。
【図6】 実施例1の機能構成図(出力)の一例の続きを示す図である。
【図7】 実施例1の木構造の一例を示す図である。
【図8】 実施例2のプログラム生産支援装置を示す構成図である。
【図9】 実施例2のフローチャートである。
【図10】 実施例2のディレクトリ構成(出力)の一例を示す図である。
【図11】 実施例2の疑似言語記述のひな形(出力)の一例を示す図である。
【図12】 実施例3のプログラム生産支援装置を示す構成図である。
【図13】 実施例3のフローチャートである。
【図14】 実施例3の疑似言語記述(入力)の一例を示す図である。
【図15】 実施例3の疑似言語記述(入力)の一例の続きを示す図である。
【図16】 実施例3のデザインレビュー用資料(出力)の一例を示す図である。
【図17】 実施例4のプログラム生産支援装置を示す構成図である。
【図18】 実施例4のフローチャートである。
【図19】 実施例4の木構造チャート(出力)の一例を示す図である。
【図20】 実施例4の木構造の一例を示す図である。
【図21】 実施例4の木構造チャートの一例を示す図である。
【図22】 実施例4の木構造の一例を示す図である。
【図23】 実施例4の木構造チャートの一例を示す図である。
【図24】 実施例5のプログラム生産支援装置を示す構成図である。
【図25】 実施例5のフローチャートである。
【図26】 実施例5のプログラミング言語記述のひな形(出力)の一例を示す図である。
【図27】 実施例5のプログラミング言語記述のひな形(出力)の一例の続きを示す図である。
【図28】 実施例5の木構造の一例を示す図である。
【図29】 実施例6のプログラム生産支援装置を示す構成図である。
【図30】 実施例6のフローチャートである。
【図31】 実施例6のプログラミング言語記述(入力)の一例を示す図である。
【図32】 図31の続きを示す図である。
【図33】 実施例6の疑似言語記述(出力)の一例を示す図である。
【図34】 図34の続きを示す図である。
【図35】 実施例6の木構造の一例を示す図である。
【図36】 実施例6の木構造の一例を示す図である。
【図37】 実施例7のプログラム生産支援装置を示す構成図である。
【図38】 実施例7のフローチャートである。
【図39】 実施例7のプログラミング言語記述(入力)の一例を示す図である。
【図40】 実施例7のプログラミング言語記述(入力)の一例の続きを示す図である。
【図41】 実施例7の木構造チャート(出力)の一例を示す図である。
【図42】 実施例7の木構造チャート(出力)の一例を示す図である。
【図43】 実施例7の木構造チャート(出力)の一例を示す図である。
【図44】 実施例7の木構造の一例を示す図である。
【図45】 実施例7の木構造チャートの一例を示す図である。
【図46】 実施例7の木構造の一例を示す図である。
【図47】 実施例7の木構造チャートの一例を示す図である。
【図48】 実施例7の木構造チャートの一例を示す図である。
【図49】 実施例8のプログラム生産支援装置を示す構成図である。
【図50】 実施例8のフローチャートである。
【図51】 実施例8のプログラミング言語記述(入力)の一例を示す図である。
【図52】 図51の続きを示す図である。
【図53】 実施例8のモジュール仕様書(出力)の一例を示す図である。
【図54】 実施例9のプログラム生産支援装置を示す構成図である。
【図55】 実施例9のフローチャートである。
【図56】 実施例9のプログラミング言語記述(入力)の一例を示す図である。
【図57】 図56の続きを示す図である。
【図58】 従来のモジュール構成図(出力)の一例を示す図である。
【図59】 実施例9のモジュール構成図(出力)の一例を示す図である。
【図60】 実施例9の木構造の一例を示す図である。
【図61】 実施例9の木構造の一例を示す図である。
【図62】 実施例10のプログラム生産支援装置を示す構成図である。
【図63】 実施例10のフローチャートである。
【図64】 実施例10のプログラミング言語記述(入力)の一例を示す図である。
【図65】 図64の続きを示す図である。
【図66】 図65の続きを示す図である。
【図67】 図66の続きを示す図である。
【図68】 従来のシンボル一覧表(出力)の一例を示す図である。
【図69】 実施例10のシンボル一覧表(出力)の一例を示す図である。
【図70】 実施例11のプログラム生産支援装置を示すブロック図である。
【図71】 実施例11のフローチャートである。
【図72】 実施例11のプログラミング言語記述(入力)の一例を示す図である。
【図73】 図72の続きを示す図である。
【図74】 実施例11の警告メッセージ(出力)の一例を示す図である。
【図75】 実施例12のプログラム生産支援装置を示す構成図である。
【図76】 実施例12のフローチャートである。
【図77】 実施例12のプログラミング言語記述(入力)の一例を示す図である。
【図78】 実施例12の加工されたプログラミング言語記述(出力)の一例を示す図である。
【図79】 実施例12の実行結果(出力)の一例を示す図である。
【図80】 実施例13のプログラム生産支援装置を示す構成図である。
【図81】 実施例1〜13の前提となるハードウェア構成を示す図である。
【図82】 従来のプログラム生産支援装置を示す構成図である。
【図83】 従来のフローチャートである。
【符号の説明】
101 仕様記述、102 字句解析手段、103 構文解析手段、104 階層構造抽出手段、105 機能構成図生成手段、106 機能構成図、201 ディレクトリ生成手段、202 ファイル生成手段、203 モジュール生成手段、204 外部記憶、205 ディレクトリ、206 ファイル1、207 ファイル2、208 ファイルN、209 モジュール1、210 モジュール2、211 モジュールN、301 疑似言語記述、302 字句解析手段、303 構文解析手段、304 インターフェース仕様抽出手段、305 モジュール定義・参照抽出手段、306 デザインレビュー用資料生成手段、307 デザインレビュー用資料、401 制御構造抽出手段、402 木構造チャート生成手段、403 木構造チャート、501 制御構造変換手段、502 処理説明→コメント変換手段、503 プログラミング言語記述のひな形、601 プログラミング言語記述、602 字句解析手段、603 構文解析手段、604 制御構造抽出手段、605 制御構造変換手段、606 コメント→処理説明変換手段、701 不要情報割愛手段、702 木構造チャート生成手段、703 木構造チャート、801 インターフェース仕様抽出手段、802 モジュール定義・参照抽出手段、803 モジュール名照合手段、804 モジュール仕様書生成手段、805 モジュール仕様書、901 同一構造割愛手段、902 モジュール構成図生成手段、903 モジュール構成図、1001 シンボル定義抽出手段、1002 シンボル定義並換え手段、1003 シンボル一覧表生成手段、1004 シンボル一覧表、1101 特定パターンの検出手段、1102 警告メッセージ、1201 実行追跡処理埋込み手段、1202 加工されたプログラミング言語記述、1301 疑似言語記述のひな形、1401 キーボード、1402 ディスプレイ、1403 計算機、1404 外部記憶、1405 プリンタ、1501 データ入力手段、1502 データ定義部、1503 表示部、1504 表示手段、1505 ブロックチャート編集部、1506 ブロックエディタ部、1507 ソースコード出力部、1508 ソースコード記録手段。
 
訂正の要旨 審決(決定)の【理由】欄参照。
異議決定日 2004-01-15 
出願番号 特願平6-226928
審決分類 P 1 652・ 121- ZA (G06F)
P 1 652・ 534- ZA (G06F)
P 1 652・ 531- ZA (G06F)
最終処分 取消  
前審関与審査官 田川 泰宏  
特許庁審判長 川名 幹夫
特許庁審判官 前田 典之
橋本 正弘
登録日 2000-09-22 
登録番号 特許第3112623号(P3112623)
権利者 三菱電機株式会社 三菱電機コントロールソフトウェア株式会社
発明の名称 プログラム生産支援装置  
代理人 横山 淳一  
代理人 宮田 金雄  
代理人 宮田 金雄  
代理人 高瀬 彌平  
代理人 高瀬 彌平  
代理人 宮田 金雄  
代理人 高瀬 彌平  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ