(57)【要約】【課題】  ソースコード一式を再利用する形態のプログラム開発であって、多数のプログラマが空間的にも時間的に何度も変更を行う開発形態の場合に、コードセグメントのレベルで変更や利用に関するノウハウを共有できるプログラムソース開発支援装置およびシステムを提供する。【解決手段】  コメントをＸＭＬタグ１０３ａ，１０３ｂで記述したプログラム１１０〜１１２とそれを管理するデータベース１０２，ＸＭＬタグで記述したプログラムソースを処理して、ＸＭＬパーサでパースできる形式に変換するプリプロセッサ１０５，処理されたプログラムソースの構文チェックを行うチェッカ１０６を組み合わせたコンパイラ１０４を備え、プログラムとしてのチェックだけでなく、コメントの構文チェックも行うことで、コードセグメントの検索を支援するとともに、不要な改造に対してコンパイル時に警告する。【選択図】図１
2009230294.tif 000002
【特許請求の範囲】
【請求項１】
構造化されたプログラム言語で記述されたプログラムソースの開発を支援するプログラムの開発支援装置であって、管理の対象となるソースコードを管理するＤＢ又はファイルシステム，ソースコードを編集するエディタ，ソースコードをコンパイルするコンパイラを含んで構成され、前記プログラムソースにはコメント開始記号以降にＸＭＬで構造化したコメントが記載され、前記コンパイラには、通常のコンパイルの他に、ＸＭＬファイルをパースして構文チェックを行うチェッカを有するプログラムの開発支援装置。
【請求項２】
前記通常のコンパイラ及び前記ＸＭＬの構文チェックの何れもが通った場合に、コンパイル処理をソースコードに対し実施する請求項２に記載のプログラムの開発支援装置。
【請求項３】
前記エディタは、ＸＭＬファイルをパースし、特定のタグで記載されたコードセグメントを選択的に表示するものである請求項１に記載のプログラムの開発支援装置。
【請求項４】
前記プログラムソースの前記コメント部のＸＭＬタグの開始記号＜，終了記号＞，属性値の開始終了記号“をそれぞれ、例えば全角などの一対一で対応する別の記号で表記したプログラムソースを管理する請求項１に記載のプログラムの開発支援装置。
【請求項５】
前記コンパイルの前処理又は後処理で、ソースコード中の半角＜記号，半角＞記号，半角＆記号，半角“記号を別の文字列に置換し、コメント中の半角＜記号，半角＞記号，半角“記号の夫々に対応する記号、例えば全角＜記号，全角＞記号，全角”記号を、夫々の半角記号に置換した上で前記コメント部の構文解析を行ってチェックし、問題が検出された場合に警告する請求項１に記載のプログラムの開発支援装置。
【請求項６】
前記プログラムソースのコメント部のＸＭＬタグの開始記号＜，終了記号＞，属性値の開始終了記号“をそれぞれ、＆ｌｔ；，＆ｇｔ；，＆quot；のような文字列で表記した請求項１に記載のプログラムの開発支援装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はプログラムソースコードの開発を支援するプログラムの開発支援装置に関する。
【背景技術】
【０００２】
携帯電話や車載装置などの様々な用途で、ソフトウェアの重要性が増している。特に、産業分野向けのソフトウェアは、新規に開発する場合の他、既存コードの再利用や一部機能追加による改良，改造が行われる場合が多い。
【０００３】
特定用途向けのベースとなるソフトウェアをカスタマイズして開発／システム構築する形態は、発電制御や交通管制システムなどの社会インフラ分野の大規模情報制御システムにおいても度々用いられる手法である。
【０００４】
既存コードを再利用して大規模ソフトウェア開発を行う場合、対象となるソフトウェアは、何年にも亘って、何度も、案件毎に異なる様々な要求に基づいて修正が行われる。全ての案件に亘って、同一の開発チームが対応できることは稀であり、様々なエンジニアやプログラマ，試験担当者が、ベースとなるソフトウェアの改造部分の設計，コーディング，全体のテストなどに携わることとなる。
【０００５】
このような運用が行われるソフトウェアにおいては、開発段階において、コメントその他の手法で、ファイルやコードセグメントに関する情報を残す運用が行われる。
【０００６】
〔特許文献１〕には、ユーザが各クラスに対して役割を設定するとともに、その役割に対応する規約を登録しておくことにより、作成されたプログラムが当該規約に適合したものであるかどうかを自動的にチェックすることが記載されている。又、〔特許文献２〕には、プログラムパターンを生成するための複数のクラス間の協働関係を記述した生成パターン記述を記憶し、プログラム生成部は、構文解析情報を参照しながら、生成パターン記述に基づいて、指定されたプログラムパターンの生成を行い、生成検証部は、生成されたプログラムが既存のクラス定義と矛盾していないかどうかを検証することが記載されている。
【０００７】
一方、前述のようなソフトウェア全体の再利用ではなく、コードセグメントを汎用的に再利用する技術としては、〔特許文献３〕に記載の技術がある。
【０００８】
【特許文献１】特開２００５−９２５１９号公報
【特許文献２】特開平１０−１８７４５０号公報
【特許文献３】特開２００５−１１３４５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
Ｃ言語が主流の時代には、一関数を一ファイルに記述するというスタイルも少なくはなかったが、Ｃ＋＋やJava（登録商標）と言ったオブジェクト指向言語では、クラスとファイルが対応するため、複数のメンバー関数が一つのファイルに記述される。このため、案件に応じた改造が発生する場合、結果的に、複数の改造項目に関する変更が一つのプログラムファイルに記述されるケースが多くなっている。
【００１０】
このため、既存コードを再利用してソフトウェア開発を行う場合は、ファイルの内容、即ちコードセグメントにまで踏み込んだ管理が必要になる。このようなコードセグメントの再利用技術には、〔特許文献３〕に記載の技術があるが、任意のプログラムの中に、再利用可能なコードスニペットを埋め込む形態での再利用を前提としている。
【００１１】
一方、ソフトウェア全体を再利用し、その中の一部分を、ハンドコーディングするような再利用形態を想定している場合は、変更してはいけない部分への変更、変更可能な部分の不適切な改造などを抑止することが課題となる。
【００１２】
〔特許文献３〕の段落〔００３６〕と〔００３７〕に、言語が適合しない場合は、コードセグメントの不適切な挿入を防止することが記載されているが、再利用型の開発では、Ｃのプログラムの中に、あえて、Visual Basicのコードを記載したり、名前空間にいきなりｉｆ文などのコードセグメントを記載したりすることはない。例えば、コメント部分にＸＭＬタグでコメントを記述させる開発環境としては、MicrosoftのVisual Studio．ＮＥＴがあるが、これは、Java（登録商標）Docと同様、関数の説明、その引数や戻り値の説明、開発者の説明などを記すための機能であり、開始タグ（例えば＜tag＞）と終了タグ（＜／tag＞）の間に、ｉｆ文や代入文のような実行コードが入ることはない。
【００１３】
そのような問題は、マルチ言語対応の汎用の開発環境において、コードセグメントの内容をユーザが意識せずにコードセグメントを再利用するシステムでの課題である。むしろ、前述のような再利用ベースの開発では、性能など、過去の経験上、手を入れてはいけないところに手を加えたり、ループ処理を入れてはいけないところにループ処理を入れたりといった、そのソースファイル特有の問題に関する制限事項の違反をチェックしやすくすることが課題となる。
【００１４】
また、再利用型開発では、参考となるコードセグメントを検索して参照しながら、必要なコードを実装するといった運用もよく実施される。〔特許文献３〕では、検索対象は符号化されたコードとなるが、〔特許文献３〕の図１３ａ〜図１３ｃに記載されているように、一般のプログラマには、何が記載されているのかわかり難く、参考になり難い。このような面では、実装されたソースコード上のコードセグメントを適切に検索できることが重要である。
【００１５】
〔特許文献３〕のような先端的な技術を使用せずに、プログラムに関する説明などを記載し、管理する方法には、検査伝票のような方法だけでなく、ソースコードにコメントを入れるといった方法がある。このような考え方はeXtream Programmingでも推奨されている。
【００１６】
通常、Ｃ／Ｃ＋＋のコメントは“／＊”（半角）と“＊／”（半角）で囲んだ範囲、又は“／／”（半角）と行末の間に記載し、この間にあるコードは無効となる。その他の言語でも、コメントの開始終了記号に差はあるが、同様に範囲を指定する形態である。このため、複数行の実行コードを含む領域にコメント入れる場合、領域の初めと終わりにコメントを入れ、何か対応がわかるようなキーワードを２つのコメントに入れたりする。このようなコメントの入れ方では、キーワードの解釈をしないと領域を機械的に抽出して、検索・再利用することが難しい。
【００１７】
更に、場合によってはコメントの検索などを目的としたキーワードなどを、領域の先頭にしか入れない場合もある。このような場合、機械的に領域を取り出すことは難しい。
【００１８】
また、どちらにしても後から改造し、それに関するコメントを追加する場合、他のコメントと混ざり合って分かり難いため、コメントを解釈する者にとっても、コメントを記述するものにとっても誤解釈，誤記入の原因となり易い。
【００１９】
本発明の目的は、複数のソースコードを纏めて再利用し、基本的に一部コードを改造することで、類似したシステム，装置の開発を行うような、ソフトウェアの開発において、コードセグメントへの不適切な改造の検出精度と、参考となるコードセグメントの検出精度を向上させたプログラムの開発支援装置を提供することにある。
【課題を解決するための手段】
【００２０】
上記目的を達成するために、本発明は、管理の対象となるソースコードを管理するＤＢ（ファイルシステムでもよい），ソースコードを編集するエディタ，ソースコードをコンパイルするコンパイラから構成され、プログラムソースにはコメント開始記号以降にＸＭＬで構造化したコメントを記載し、コンパイラには、通常のコンパイルの他に、コメント開始記号，コメント終了記号の削除などを行うプリプロセッサと、ＸＭＬファイルをパースして構文チェックを行うチェッカを有するものである。
【００２１】
コンパイラはコンパイル時に、コメント開始記号，コメント終了記号を削除したテンポラリファイルを生成し、これをＸＭＬのパース機能で読み出しＸＭＬの構文チェックを行う。このＸＭＬの構文チェックが通った場合に、通常のコンパイラと同様なコンパイル処理をコメント開始記号，コメント終了記号削除前のソースに対し実施する。なお、コメントの構文チェックとプログラムのコンパイルの順序はどちらを先にしても良い。
【００２２】
また、エディタにも、ソースコードのコメント開始記号，コメント終了記号を削除して、ＸＭＬファイルをパースし、特定のタグで記載されたコードセグメントを選択的に表示する機能とを有しても良い。
【００２３】
また、ソースコードを管理するＤＢ（あるいはファイルシステム）を、特定案件に対応するための改造，修正対象となるソースコード（複数）だけでなく、その元となるソースコードも保存するＤＢ（あるいはファイルシステム）とし、改造，改修対象コードの特定タグ、あるいは特定属性値を持つタグで範囲指定されるコードセグメントに対して、対応する元コードのコードセグメントと比較して、差異があれば、警告する機能を有する構文チェッカを用いてもよい。
【発明の効果】
【００２４】
本発明によれは、プログラムへのコメント記述に対しても構文チェックが働くため、構文上解析できないコメントが記述されることを防ぐことができ、プログラムのコードセグメントレベルでの管理が可能となる。その結果、変更不可部分への変更や不適切な変更の検出が容易になるとともに、参考とすべきコードの検出も容易になる。
【発明を実施するための最良の形態】
【００２５】
本発明の各実施形態について、図面を用いて説明する。
【実施例１】
【００２６】
本発明の実施例１を図１から図７により説明する。図１は、本発明の実施例１であるプログラムの開発支援装置の構成図である。又、図１にソフトウェアの基本構成を示している。
【００２７】
本実施例のプログラム開発支援装置は、コンピュータ１０１であり、エディタ１０７とコンパイラ１０４，ソースコードを格納するデータベース１０２（以下、ＤＢ１０２という）で構成される。ＤＢ１０２は、ファイルシステムであってもよい。
【００２８】
ＤＢ１０２に格納されるプログラムソース１１０，１１１，１１２は、下線部のコメントの開始タグ１０３ａと下線部のコメントの終了タグ１０３ｂで示すように、コメントをＸＭＬ（Extensible Markup Language）の対になるタグで記載する形で、コードセグメントにコメントを入れている。コンパイラ１０４には、プログラム言語のコメント開始記号と終了記号を取り除き、“＜”，“＞”，“＆”（半角）などの記号を例えば全角文字に置換するプリプロセッサ１０５と、コメント開始記号とコメント終了記号を取り除いたプログラムソースをＸＭＬファイルとしてパースし、構文チェックを行うチェッカ１０６とが付属しており、通常のコンパイルの前、又は後のいずれか定められた順番で、チェッカ１０６によるコメントの構文チェックを実施する。
【００２９】
ここで、順番はどちらでも良いが、望ましくはコメントのチェックは後に実施したほうが、肝心のソースコードが安定してからコメントを安定させるので、望ましい。逆の場合は、コードのコンパイルエラー対応で、コメント自体も変わる可能性がある。
【００３０】
図２は、本実施形態におけるコンパイラ１０４の処理手順を示す図である。コンパイラ１０４は、通常のコンパイル処理２０１を行い、ステップ２０２で、エラーがあれば、ステップ２０３で、通常通りエラーメッセージを表示してコンパイルを終了する。
【００３１】
ステップ２０２で、コンパイルが通った場合は、プリプロセッサ１０５を用いて、ステップ２０４で、コメント開始記号，コメント終了記号を削除し、一部コード（“＜，＞，＆”など）の置換を行ったコードを生成し、ステップ２０５で、これをチェッカ１０６のＸＭＬパース機能でパースし、構文エラーをチェックする。ステップ２０６で、パースでエラーが見つかれば、ステップ２０７で、エラーメッセージを表示する。
【００３２】
図３に本実施形態におけるＸＭＬのＤＴＤ（Document TYPE Definition）の定義例を示す。この一例では、後述する実施例のように固有のチェッカを追加する場合には、その実装に合わせたＤＴＤを定義する必要がある。チェッカ１０６は、ＤＴＤ部３０１に基づいてソースコード部３０２の中のＸＭＬタグをチェックし、ＤＴＤの定義と違反する場合にはエラーを出力する。
【００３３】
（なお、ＤＴＤに対する構文チェックに関しては、幾つかの市販開発環境、Ｗｅｂで公開されたツールで実施可能であり、チェッカ１０６は、これらのツールを利用して構成することが出来る。）
図３に示すＸＭＬのＤＴＤの定義例の第４行〜第１８行には、使用可能なＸＭＬタグの種類を示している。この定義例では、class_defタグには、任意文字列，summaryタグ，templateタグ，mem_funタグ，mem_varタグ，stat_varタグを子要素として定義できることを示しており、expタグには、文字列のみが定義可能なことを示している。
【００３４】
ＸＭＬのＤＴＤの定義例の第１９行〜３６行には、各タグの取り得る属性を示している。例えば、regionタグのspec属性は、「permanent」，「under_dev」，「modifiable」，「sensitive」の４値の何れかであることを規定している。init_valタグのvalue属性は未定義も許されるが、templateタグのname属性は文字列で何らかの定義が必須であることを示している。
【００３５】
チェッカ１０６は、タグの開始と終了のペアが正しく設定されているといったwellformedness Constraintsだけでなく、ＤＴＤで定義された制約（validiy Constraints）もチェックして、エラーを検出するようにしてもよい。
【００３６】
図４に本実施形態のプリプロセッサ１０５の処理の概要を示す。プリプロセッサ１０５は、前述したようにプログラムソースをＸＭＬで正しくパースできるように前処理を行う。ＸＭＬでは、“＜”（半角 little than），“＞”（半角 greater than），“＆”（半角 ampersand）“””（半角 quotation）をコンテンツとして処理することが出来ないため、コンテンツ上のそれらの記号は、それぞれ、“＆ｌｔ；”，“＆ｇｔ；”，“＆amp；”，“＆quot；”（夫々、半角）と記述する。
【００３７】
プリプロセッサ１０５は、ソースコード中の“＜”（little than），“＞”（greater than），“＆”（ampersand）“””（quotation）記号（夫々、半角）を、それぞれ、“＆ｌｔ；”，“＆ｇｔ；”，“＆amp；”，“＆quot；”（夫々、半角）に置換する処理を行い、コメント開始記号，コメント終了記号を削除する。
【００３８】
このためには、プログラムソース上で、記述するＸＭＬタグの開始記号である”＜“と終了記号である“＞”と、プログラムソース中の“＜”と“＞”を区別できる必要がある。また、タグの属性値を記述する“””とプログラムソース中の“””も区別できる必要がある。
【００３９】
このため、コメントに使用するＸＭＬタグの“＜”，“＞”，“””は、夫々、全角で記述するものとする。なお、ソースコード中の同一記号と区別できれば、別の記号でもかまわない。但し、ソースコードを何らかの理由でコメント化して無効にした部分に含まれる同一記号に対しても区別できる必要がある。
【００４０】
ステップ４０１で、プリプロセッサ１０５は、プログラムソースを読み込み、ステップ４０２で、出力先ファイルを開いて、ステップ４０３で、読み込んだ文字列を先頭からチェックし、もしそれが２バイトコードの上位バイトか、“／“（半角）又は“＊”（半角）であれば、もう一文字読み込み、ステップ４０４で、それが半角の“＜”，“＞”，“＆”，“”“の何れかであれば、ステップ４０５で、それぞれ、“＆ｌｔ；”，“＆ｇｔ；”，“＆amp；”，“＆quot；”（全て半角）に置換する。
【００４１】
ステップ４０６で、全角の“＜”，“＞”，“””であれば、ステップ４０７で、それぞれ半角に置換する。ステップ４０８で、コメントの開始終了記号（“／＊”，“＊／”，“／／”）であれば、なにもせず、そうでなければ、ステップ４０９で、読み込んだ文字をそのまま出力する。
【００４２】
なお、プログラムソースのコメント開始記号，コメント終了記号の削除に関しては、厳密には、ＤＴＤ部と、コメントを記述するタグの最上位要素、例えば、図３に示す例では、c_sourceタグの開始タグ（＜c_source＞）の前のコメント開始終了記号（図３line−１）と、終了タグ（＜／c_source＞）の後のコメント開始終了記号（図３line−４１）のみを削除すれば、ＸＭＬ文書としての構文解析とチェック（well formednessおよびvalidity）が可能である。
【００４３】
図５は、本実施例のチェッカ１０６の他の例を示す図である。図５に示すチェッカ１０６は、ＤＴＤに対する構文チェックを行う汎用チェック機能（validity Constraintsのチェック）と、ＤＴＤの定義に依存した機能を組み込んだ非汎用機能とで構成される。
【００４４】
ステップ５０１で、チェックが開始されると、初めに標準のＤＴＤ構文チェックを実施する。ステップ５０２で、この結果に問題があれば、ステップ５０３で、エラーメッセージを出力して、チェックを終了する。問題がなければ、ステップ５０５で、regionタグで示される領域をファイルの先頭から順次取り出し、spec属性がpermanentかsensitiveのどちらかに該当するか否かを判定する。これらの何れかに該当する場合は、ステップ５０６で、ベースとなるファイルの同一regionを取り出し、比較を行う。ステップ５０７で差がある場合は、ステップ５０８でメッセージを出力して、ユーザに警告する。
【００４５】
この例では、permanentとかsensitiveという属性値によって、変更を許可しないことや、変更には注意が必要ということを表し、そのような領域の変更に対して、注意を促す仕掛けを持たせた場合の例に示した。region以外のタグで指定される領域にも、同様の属性を付与することで、変更に対して注意を促してもよい。
【００４６】
また、spec属性のpermanentやsensitiveという属性値によるのではなく、例えばrankといった属性を持たせ、rankの値が１０〜６のregionに対する変更に対してアラームを発するようにしても良い。ここで、ランクの値は１〜１０の整数をとり、大きいほど変更には注意が必要なことを示すようにする。
【００４７】
図６，図７は、ソースコードの編集に当たって参考となるコードを検索する機能を付与した場合の例を示す。図６は、検索指示を受けた後の処理を、図７は検索処理要求を行う際の画面を示す。
【００４８】
検索メニューバーから、例えばTech＆Knowhowが選択された時は、ステップ６０３で、同一フォルダ、或は同一案件としてＤＢ１０２に格納されたファイルから、regionタグのtype属性がtechで、その領域にあるｅｘｐタグにtype＝knowhowの要素があるファイルを探し、ステップ６０４で、見つかった場合は、ステップ６０５で、そのファイルを検索結果のWindow７０２に表示する。
【００４９】
この例では検索結果にチェックボックス７０３があり、そこをチェックして開くボタン７０４を押すことで、検索結果を参照する形態を想定しているが、検索結果の行をダブルクリックすることで開くといったインタフェースでも良い。
【００５０】
なお、コマンド入力が検索でない場合は、ステップ６０７で、エディタの標準機能にコマンドを渡すことで、通常の処理を行わせる。また、検索条件に合致するファイルが無い場合には、ステップ６０６で、その旨をメッセージ出力する。
【実施例２】
【００５１】
本発明の実施例２を図８から図１１により説明する。図８は、特定タグの値に関するリポジトリを持つ実施例のシステム構成図である。
【００５２】
図８に示すシステム構成では、編集およびチェックの対象となる文書を保存するＤＢ１０２の他に、特定タグのリポジトリ８０１が設けられている。この例では、regionタグのsubject属性が、当該領域が何に関する処理を記述したものであるかを示している。ユーザが、それを検索条件に検索し、その結果を参考に改造や修正を行うためのregionタグのsubject属性に関するリポジトリを保持している。
【００５３】
図９は、このようなタグの属性値に関するリポジトリを持つ場合の検索画面の例を示す。この例では、検索メニューバーを展開した際、予めリポジトリ８０１に登録されている属性値のリストをメニューバー９０１に表示して選択させる。選択が実施された後は、選択された属性値に対応するファイルの情報をリポジトリから取得し、検索結果画面９０２に表示させる。それ以降の参照動作は、図７に示す場合と同様に行われる。
【００５４】
図１０に当該タグを右クリックするなどして、メニューを表示し、検索（Search）を実施する例を示した。この場合、当該タグと同じ属性値を持つタグを検索して、検索結果画面に表示することが出来る。
【００５５】
図１１は、ソースコード編集行うマシン１１０１とファイルサーバ（およびタグ情報のレジストリ）１１０２を分離しネットワーク接続した構成例を示す。この実施例ではマシン１１０１で、エディタ１１０３とコンパイラ１１０４が実行され、ファイルサーバ１１０２側でコンパイラを実行してもよい。また、ファイルサーバ側にタグ情報のレジストリがあるケースを示しているが、これが無い形態でも良い。
【産業上の利用可能性】
【００５６】
各実施例は、組み込みシステムや、情報制御システムなどのプログラムソースの開発支援に関し、特に再利用により一部コードの改造，追加，削除などは行うが、基本的にはプログラムソース一式を再利用するようなソフトウェア開発におけるプログラムソースの編集およびコンパイルに活用できる。
【図面の簡単な説明】
【００５７】
【図１】本発明の実施例１であるプログラムの開発支援装置の構成図。
【図２】本実施例のプログラムのコンパイル処理手順を示す図。
【図３】本実施例のソースプログラムのチェックに用いるＤＴＤ部とプログラムソースの構成図。
【図４】本実施例のプリプロセッサの処理手順を示す図。
【図５】本実施例の領域変更へのアラーム提供の処理手順を示す図。
【図６】本実施例の類似コードセグメントの検索処理手順を示す図。
【図７】本実施例の類似コードセグメントの検索インタフェースを示す図。
【図８】本発明の実施例２であるプログラムの開発支援装置の構成図。
【図９】リポジトリを持つ場合の検索画面の例を示す図。
【図１０】メニューを表示し、検索する画面例を示す図。
【図１１】プログラムの開発支援装置の他の構成図。
【符号の説明】
【００５８】
１０１  コンピュータ
１０２  ＤＢ
１０３ａ  コメントの開始タグ
１０３ｂ  コメントの終了タグ
１０４  コンパイラ
１０５  プリプロセッサ
１０６  コメント部構文チェッカ
１０７  エディタ
１１０，１１１，１１２  プログラムソース
【図１】
2009230294.tif 000003
【図２】
2009230294.tif 000004
【図３】
2009230294.tif 000005
【図４】
2009230294.tif 000006
【図５】
2009230294.tif 000007
【図６】
2009230294.tif 000008
【図７】
2009230294.tif 000009
【図８】
2009230294.tif 000010
【図９】
2009230294.tif 000011
【図１０】
2009230294.tif 000012
【図１１】
2009230294.tif 000013