JPWO2008093734A1 - ソースファイル管理システム - Google Patents

Abstract

ソフトウェア開発を外国に発注して行うオフショア開発において、各国の開発チームが日常使用する言語を用いて仕様書作成を行い、開発チーム間で不一致なく各言語の仕様書を更新する方法及びシステムが提供される。ソースファイル管理システムは、ソースコードとソースコードの機能を多国語で記述するコメントを含むソースファイルにおいて、機能を示す機能符号と言語の種類を示す言語符号を付加するソースファイルとし、そのソースファイルを格納するサーバであるソースファイル管理システムを設置する。そのサーバは、世界各地のクライアントに対し多国語のソースファイルを用いた開発に必要な機能である使用中の自然言語の管理、機械翻訳、課金機能を備え、不一致を起こすことなく各自然言語によるコメントを編集する。

Description

本発明は、多国語によるコメントが記述されたソースファイルを編集するための編集方法とシステムに関するものであり、更に、詳しくは、世界各地に分散してソフトウェア開発作業を行っている開発チームの間で異なる種類の自然言語によりソースファイルにコメントを付加し維持する管理方法およびソースファイル管理システムに関するものである。

本明細書において、言語、自然言語及び国語とは日本語、英語等の言語を表し、プログラミング言語と明記した場合はＪａｖａ（登録商標）言語のようなプログラミング言語を表す。ソフトウェアはソースファイル中にソースコードおよびコメントとして記述される。ソフトウェアが開発される際は、備えるべき機能と使用法とを自然言語で記述した仕様に沿って開発される。また、ソフトウェアが他のソフトウェアに機能を提供する場合、その機能の呼び出しインターフェースをＡＰＩと言い、ＡＰＩの仕様書はソフトウェアと共に出荷される。本明細書では、仕様及び説明をとりまとめた文書を仕様書あるいは説明書と呼び区別なく用いる。

ソフトウェア開発はグローバル化している。米国や日本のようなソフトウェアの需要地においては開発するソフトウェアの仕様作成のみを行い、開発作業は開発費の低い国で分担して行う形態が一般的になった。このような開発形態はオフショア開発と呼ばれる。また、新製品の研究開発でも世界各地の開発チームが分担してひとつの製品の開発を行うことが多い。本明細書ではこれらを総称して分散開発と呼ぶ。

本明細書では、ソースファイルや説明書を提供する機能をサーバ、使用や編集を行う機能（エディタ等）あるいはそれを使用する人をクライアントと呼ぶ。サーバとクライアントの配置は集中型でも分散型でもＰ２Ｐでもよい。クライアントであるA国の開発チームはサーバからファイルを取り出し、編集や開発作業を行った後、サーバに格納する。別のクライアントであるB国の開発チームは同じファイルをサーバから取り出し、参照や更なる編集作業を行う。

そのような地理的に分散する開発チームの間で高品質のソフトウェアを開発するには、正確な仕様を共有することが必要である。一方の開発チームにおける仕様の変更が、正確に他の開発チームに伝達され、他の開発チームのソースコードが、変更されなければならない。

仕様、特にＡＰＩの仕様とソースコードの乖離を防ぐため「ドキュメンテーションコメント」というプログラミング言語の機能及びツールが用いられている。ドキュメンテーションコメントは、ソースファイル中に自然言語によるコメントとしてＡＰＩの仕様を記述する方法である。Ｊａｖａ言語では「／＊＊」から始まるコメントがドキュメンテーションコメントであり、Ｃ＃言語では「／／／」で始まるコメントがドキュメンテーションコメントである。ソフトウェア中に記述されたコメントからＡＰＩ仕様書を生成するツールの例としては、Ｊａｖａｄｏｃ、Ｄｏｘｙｇｅｎ、ＫＤＯＣ、ＤＯＣ＋＋といったものがある。

それらのツールでは、ＡＰＩの仕様をソフトウェア中に自然言語によるコメントとして記述するために、図１に示すように、コメントの「機能を表す符号」を用いる記法を使用する。図１はＪａｖａ言語にドキュメンテーションコメント機能を提供するＪａｖａｄｏｃの使用例であり、ソースファイルのドキュメンテーション１００において、たとえば、コメント１０１では、引数の仕様を記述するために「＠ｐａｒａｍ」という機能を表す符号を用いて「ｒｅｐｅａｔ」という引数は「挨拶繰り返し回数」を表すという意味で記述している。Ｊａｖａｄｏｃコマンドはソースファイルからこの仕様部分を抜粋し、ソースコードとは独立のＡＰＩ説明書を生成する。

ところで、図１に示す例の説明では、ソースファイルのドキュメンテーション１００において、コメント１０１は、日本語で記述されているため、他国の開発チームのメンバーは理解することができない。共通の言語として英語を設定し、英語でコメントを記述することが多く行われているが、開発者が日常用いる言語を用いることの利点も多い。例えば、日本の開発チーム内では日本語のコメントを、ベトナムではベトナム語を使用すると生産性が高い。出荷するソフトウェア製品に各言語のＡＰＩ仕様書を添付する必要がある場合も多い。

しかし、上記のＪａｖａ言語もＣ＃言語もツールのＤｏｘｙｇｅｎも多国語によるコメントを適切に扱う機能を有していないため、ひとつのソースファイル中で各国の開発チームが理解しやすいそれぞれの言語を同時に使用することは困難である。「＃ｉｆｄｅｆ日本語」というようにプリプロセッサを利用して多国語のコメントを書くことは可能であるが、言語が異なるコメント間の一貫性を保つ仕組みがなく、言語間の仕様の不一致やソースコードとの不一致が発生しやすい欠点がある。

ＰＬＭ（Ｐｒｏｄｕｃｔ Ｌｉｆｅｃｙｃｌｅ Ｍａｎａｇｅｍｅｎｔ）製品、ＰＤＭ（Ｐｒｏｄｕｃｔ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ）製品も含め、分散開発環境における製品開発環境として、多くの製品が提供されている。日本電気株式会社の「Ｏｂｂｌｉｇａｔｏ（オブリガート）ＩＩ」では、仕様書等文書類は共通のデータベースに格納される。各地の開発チームはデータベースを参照し仕様書を取り出して、それに従ってソフトウェアの開発を行う。多国語の文書の作成は可能であるが、ソースファイルとは独立して管理されるため、ソースファイルの変更によって仕様に変更が生じた場合、ソースファイルとは別に各言語の仕様書をデータベースから取り出して、すべて変更を加えなければならないという課題がある。他にもＩＢＭの「ＥＮＯＶＩＡ ＳｍａｒＴｅａｍ」、ＵＧＳの「Ｔｅａｍｃｅｎｔｅｒ」、富士通の「ＰＬＥＭＩＡ」等があるが、各言語の仕様書とソースファイルが別々にデータベースに格納されている点は共通であり、同様に仕様とソースファイルの不一致が生じやすいという課題がある。

複数の種類の外国語で書かれた電子ドキュメント用のコンテンツフィルタの技術としては、特許文献１が公知である。このコンテンツフィルタの技術は、主に時事的な内容のニュース記事を話題分野別に分類することを目的としている。

また、ソフトウェア仕様書自動生成の技術としては、特許文献２および特許文献３が公知である。特許文献２はオブジェクト指向のソフトウェアにおける仕様書作成に関する方法およびソフトウェアについてのものであり、また特許文献３はソフトウェアの構造解析に着目した仕様書作成の方法についてのものである。しかし、どちらもコメントの記述の自然言語は単一であることを前提としている。

非特許文献６は複数の自然言語で記述されたソースファイルから仕様書を生成する方法の１つを説明しているが、ソースファイル管理を効率化する工夫には及んでいない。非特許文献７においては、Ｊａｖａｄｏｃの国際化について議論を行い、＜ＬＡＮＧ ＬＡＮＧＡＧＥ＝ｊａ“＞…＜／ＬＡＮＧ＞のようなタグで区切って言語毎に並べるコメントの記述方法を提案している。議論はＵｎｉｃｏｄｅ等による多国語のエンコード方法の問題点の検討を行っており、ソースファイルの管理には及んでいない。
米国特許第６，５４２，８８８号明細書 特開２００５−２５８５６１号公報 特開２００５−１２２４０７号公報 Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ、Ｃ＃ Ｌａｎｇｕａｇｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ １．０，Ａｐｐｅｎｄｉｘ Ｂ Ｄｏｃｕｍｅｎｔａｔｉｏｎ Ｃｏｍｍｅｎｔ ｈｔｔｐ：／／ｍｓｄｎ２．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｅｎ−ｕｓ／ｖｃｓｈａｒｐ／ａａ３３６８０９．ａｓｐｘ． Ｋｅｎ Ａｒｎｏｌｄ他、Ｊａｖａ Ｌａｎｇｕａｇｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ，Ｓｅｃｔｉｏｎ １９， Ｄｏｃｕｍｅｎｔａｔｉｏｎ Ｃｏｍｍｅｎｔｓ． 日本電気株式会社 ＰＬＭソリューション「Ｏｂｂｌｉｇａｔｏ ＩＩ」，ｈｔｔｐ：／／ｗｗｗ．ｐｌｍｓｏｌ．ｃｏｍ／ｏｂｂｌｉｇａｔｏ／ ＩＢＭ ＥＮＯＶＩＡ Ｓｍａｒｔｅａｍ，ｈｔｔｐ：／／ｗｗｗ−０６．ｉｂｍ．ｃｏｍ／ｊｐ／ｍａｎｕｆａｃｔｕｒｉｎｇ／ｐｒｏｄ／ｐｄｍ／ｓｍａｒｔｅａｍ／ｉｎｄｅｘ．ｈｔｍｌ． ＵＧＳ Ｔｅａｍｃｅｎｔｅｒ，ｈｔｔｐ：／／ｗｗｗ．ｕｇｓ．ｊｐ／ｐｒｏｄｕｃｔ／ｔｅａｍｃｅｎｔｅｒ／ｉｎｄｅｘ．ｈｔｍｌ． 高橋他「Ｉｎｌｉｎｅ ｔａｇｌｅｔを用いたｊａｖａｄｏｃのＮＬＳ化手法」、２００６年１月２０日公開、ｈｔｔｐ：／／ｗｗｗ．ｉｂｍ．ｃｏｍ／ｄｅｖｅｌｏｐｅｒｗｏｒｋｓ／ｊｐ／ｙｓｌ／ｌｉｂｒａｒｙ／ｊａｖａ／ｙ−ｊ−ｉｎｌｉｎｅｔａｇｌｅｔ／ 高木他「ｍｕｌｔｉｌｉｎｇｕａｌｉｚａｔｉｏｎ ｏｆ ｊａｖａｄｏｃ」、１９９９年６月６日公開、ｈｔｔｐ：／／ｊａｖａ−ｈｏｕｓｅ．ｊｐ／ｍｌ／ａｒｃｈｉｖｅ／ｊ−ｈ−ｂ／０２５７５４．ｈｔｍｌ

ソフトウェアの開発工程において、開発作業や翻訳作業は一度に一言語ずつ完了してゆくわけではなく、プロジェクトの開始から終了まで、たえず改良が重ねられ完成度を高めてゆく。完成する説明書は、たとえ、たくさんの言語の版があったとしても、各言語の版の内容はソフトウェアと精密に一致していなければならない。そこで、多数の開発者がそれぞれ作業を行っても内容に不一致が生じないような仕組みが必要である。

そのような問題を解決するために、各々の異なる種類の自然言語で書かれた各々のコメント文に対して当該言語の種類を識別する符号とコメントの機能を示す符号とを組み合わせた組み合わせ符号を付加することにより、希望する言語で書かれたコメントを抽出し、その言語で記述されたソフトウェア説明書を生成することを可能とする「複数自然言語のソフトウェア説明書生成システム」を、本発明者等は先に提案した。図２は、多国語で記述されたコメントを含むソースファイルの一例を示す図である。この方法により、コメントとして記述された仕様の修正とソースコードの修正は同一ファイルの修正で済むため、不一致が生じる可能性が大幅に減少する。以下、ソースファイルは多国語コメントを含むソースファイルを表すものとする。

しかし、分散開発環境において各開発チームが多言語コメントを含むソースファイルを共有する場合、ファイルサーバやデータベースにソースファイルを格納しておくだけでは、管理者や開発者はどの言語により仕様が記述されているかを知ることができない。更に、開発チームが増えたり減ったりして使用する言語が変化する場合もあるが、どの言語が使用されているか常に把握するにはコストがかかる。

クライアントが多国語によるコメントを処理することができる開発ツールを所有していない場合、所望の言語のコメントのみを含むソースファイルをサーバから取り出したい場合、特定の言語のコメントのみを取り出したとしても、クライアントがそれに編集を行うと、サーバ中に格納されているソースファイルに含まれるソースコードや他の言語によるコメントと不一致が生ずる。後に手作業で不一致を解消することは難しい。

複数の自然言語に堪能な人の数は限られている。そこで、例えば、４カ国語のソフトウェア説明書を作成する際には、これまでは、世界各地にいるそれぞれの言語の翻訳者あるいは開発者がメールにより連絡を取りながらそれぞれの担当自然言語への翻訳作業を行っていた。この従来方式では、説明文の修正を重ねていくと、どの部分を修正したのか、どの言語のコメントが最新の状態なのかがわかりにくく、手間とコストがかかっていた。また、仕様とソースコード間、あるいは複数の言語による仕様間に更新漏れがあると不具合のあるソフトウェアが作られてしまい、使用時において人命に関わる重大な事故を引き起こす可能性がある。

他にも多くの課題がある。例えば、特定の言語への翻訳ができる人がいない場合もある。そこで機械翻訳を用いることになるが、その場合、機械翻訳の品質は低いため、後で人手による確認・修正が必要になるかもしれない。クライアントはどの言語で変更が生じたか、自分はどのような変更作業をすべきかを知る手段が必要である。また、クライアントの役割はプログラマであることも翻訳者であることも管理者であることもある。翻訳者がコメントの翻訳を行うためにソースファイルを編集中に、誤ってソースコードを変更してしまうことも考えられる。開発者が翻訳者に翻訳を依頼した場合、翻訳者に翻訳料を支払うために、開発者が翻訳を依頼した量と翻訳者が行った翻訳の量を記録することも必要である。

また、ＪａｖａｄｏｃにはＪａｖａｄｏｃの文法があるように、プログラミング言語やツールによってコメントの書式には違いがあるため、必ずしも一種類の組み合わせ符号の形式が適しているとは限らない。言語の種類の符号とコメントの機能を表す符号の適切な配置形式はプログラミング言語により異なる。

上記の課題を解決するため、本発明においては、プログラミング言語で記述されたソースコードとソースコードの機能を多国語で記述するコメントを含むソースファイルにおいて、機能を示す機能符号と言語の種類を示す言語符号を付加したソースファイルとし、そのソースファイルを格納するサーバであるソースファイル管理システムを設置する。そのサーバは、世界各地のクライアントに対し、多国語のソースファイルを用いた開発に必要なサービスを提供する。必要なサービスとは、あるソースファイルではどの言語が使用されているかを表示あるいは情報提供することや使用する自然言語の種類を追加、削除する手段を提供することを含む。

本発明は、第１の様態としては、プログラミング言語で記述されたソースコード文及び前記ソースコード中の機能を説明するコメントが複数の種類の自然言語で記述されたソースファイル内において、前記機能を示す機能符号とコメントの自然言語の種類を表す言語符号とを組み合わせた組合せ符号が付加されているソースファイルを格納する格納手段と、クライアントからの要求によってネットワークを介してソースファイルを送信あるいは受信するソースファイル通信手段と、ソースファイル中のコメントが含む自然言語の種類を提示する言語種類提示手段とを備えることを特徴とするものである。

第２の様態としては、前記第１の様態の機能を示す機能符号と言語の種類を示す言語符号とを組み合わせた組合せ符号を付加するソースファイルに代えて、機能を示す機能符号に続いてコメントの自然言語の種類を表す言語符号が付加されているソースファイルとするものである。

第３の様態としては、前記第１の様態の機能を示す機能符号と言語の種類を示す言語符号とを組み合わせた組合せ符号を付加するソースファイルに代えて、機能を示す機能符号とコメントの自然言語の種類を表す言語符号とが付加されているソースファイルとするものである。

管理の手間を軽減するために、本発明によるソースファイル管理システムは、更に、ソースファイル内のコメントの記述に用いる自然言語の種類を記憶、追加あるいは削除する言語種類管理手段を備えてもよい。

また、本発明によるファイル管理システムは、単一の言語のみを扱うことができる開発環境のために、複数の自然言語によるコメントからクライアントが指定した指定自然言語によるコメントのみを抽出し、指定自然言語のコメントを含むソースファイルをソースファイル通信手段を介して送信する言語抽出手段を備え、クライアントに単一の言語のみを含むソースファイルを提供し、クライアントによる編集後、指定の自然言語のコメントを含むソースファイルをソースファイル通信手段を介して受信し、元の複数の自然言語によるコメントを含むソースファイルにマージする複数言語マージ手段を備えるようにしてもよい。

更に、ある自然言語によるコメントに変更を検出した際に、他の自然言語により記述されたコメントに更新が必要である旨を示す更新符号を付加する更新符号付加手段を備えたり、更新が起きたことをクライアントに通知する更新通知手段と、更新が必要な箇所を提示する更新箇所提示手段とを備えるようにしてもよい。

翻訳者の人数に制限がある場合には、機械翻訳を用いてソースファイル内のコメントの翻訳を行う翻訳手段と、前記翻訳を行ったコメントに前記機械翻訳を用いたことを示す符号を付加する機械翻訳符号付加手段とを備えるよう構成することもできる。

誤った操作を防止するためには、本ソースファイル管理システム及びクライアントにおいて、利用者に許される操作を制限する操作制限手段を配置し、操作を翻訳者が使用する言語のみに限るといった制限を加えることができる。

最終的な説明書を得るためには、ソースファイルを元にクライアントが指定する自然言語による説明書を生成する説明書生成手段により各言語の説明書を得る。

また、開発コストの管理と翻訳者への翻訳料の支払いのために、開発者が翻訳者に依頼した翻訳の翻訳依頼量を記録する翻訳依頼量記録手段と、翻訳者が行った翻訳の翻訳量を記録する翻訳量記録手段と、翻訳費を算出する翻訳費算出手段とを備えるよう構成してもよい。

各国の編集者、開発者がそれぞれ各言語によるコメントとソースコードを編集してゆく際に、不一致が生じないように編集する方法としては、前記機能を表す符号の機能符号とコメントの自然言語の種類を表す符号の言語符号とコメントが更新を必要とする旨の符号が付加されているソースファイルをネットワークを介して受信するステップと、コメントに新たな修正を行った場合、修正を行った自然言語以外の自然言語で記述されたコメントに更新を必要とすることを示す符号の更新符号を付加するステップと、編集を行いたい自然言語によるコメントに更新符号が付加されていたら、更新符号が付加されていない自然言語によるコメントに意味を合わせて修正し、更新符号を削除するステップと、修正したソースファイルをネットワークを介して送信するステップとを含み、全ての更新符号がなくなり、かつ、全てのクライアントにおいて新たな修正の必要がなくなるまで上記のステップを繰り返すソースファイル編集方法が提供される。

このような本発明のソースファイル管理システムが提供されることにより、従来まで、複数の国に分散して配置された開発チーム間でソースコードとドキュメントコメントを編集する場合、メールでやりとりを行ったり、多国語編集の機能を備えないデータベースやソースコード管理システムを用いていたりするため、容易に言語間の意味の不一致やソースコードとの乖離が発生していたが、本発明によるソースファイル管理システムによって、ソースコードと各言語による仕様の記述がひとつのソースファイルに統合され、かつ、ソースファイル中で使用されている言語を識別して必要な管理を行うため、ソースコードの意味と各言語の仕様を一致させることが大幅に容易になる。主要な効果としては、コストや人員の削減と共に、仕様間の更新漏れによるソフトウェアの不具合を防止し、ひいては不具合のあるソフトウェアに起因する事故の発生を防止することができる。

ドキュメンテーションコメントの例を示す図である。 機能符号と言語符号を組み合わせた組み合わせ符号の例を示す図である。 全体のシステム構成を示す図である。 工程上の仕様の変化を示す図である。 ソースファイル管理システムの構成を示す図である。 XML形式のコメントにおいて機能符号と言語符号を組み合わせた例を示す図である。 機能符号に言語符号が続く例を示す図である。 ＸＭＬ形式のコメントにおいて機能符号に言語符号が続く例を示す図である。 機能符号が言語符号に挟まれている例を示す図である。 ＸＭＬ形式のコメントにおいて機能符号が言語符号に挟まれている例を示す図である。 自然言語種類管理手段の例を示す図である。 ソースファイルの言語の抽出とマージを示す図である。 更新符号の追加の例を示す図である。 変更箇所の提示の例を示す図である。 機械翻訳符号を付加した例を示す図である。 操作制限の設定情報の例を示す図である。 説明書の生成を示す図である。 翻訳量の記録と課金管理を示す図である。 編集方法による不一致解消のステップの例を示す図である。 編集方法のステップを示すフローチャート図である。 機能符号に言語符号が続く例を示す図である。

符号の説明

１００ ドキュメンテーション
１０１ ドキュメンテーションコメント
２０１ ドキュメンテーションコメント
３０１ ネットワーク
３０２ ソースファイル管理システム
３０３ クライアント
４０６ 英語による仕様書
４０７ フランス語による仕様書
４０８ 実行可能ソフトウェア
４０９ 多国語によるコメントを含むソースファイル
５０１ 格納部
５０２ 通信部

本発明を実施するひとつの例として、図３に、日本に本社がある会社が、米国市場及びＥＵ市場向けに日本及び中国でソフトウェアの開発を行うプロジェクトの構成を示す。ネットワーク３０１中においてサーバとして機能するのはソースファイル管理システム３０２であり、クライアントである開発者・翻訳者群３０３はソースファイル管理システム３０２からソースファイル及び管理情報を引き出して開発作業や管理作業を行う。図３ではソースファイル管理システム３０２は集中型のサーバとして表現されているが、分散型であってもＰ２Ｐ型であってもよい。

図４に工程上の仕様間の関係を示す。最終的に作成されるべき製品は実行可能ソフトウェア４０８と、英語によるＡＰＩ仕様書４０６とフランス語によるＡＰＩ仕様書４０７とする。開発者は日本３０９、中国３０７、米国３０５にいて、共同で開発に当たる。中国の開発者３０７は日本語の仕様書を理解できないため、中国語の仕様書に翻訳する中国語翻訳者３０６が必要となる。フランス語の仕様書を作成するためにはフランス語への翻訳者３１０がいる。

図５にソースファイル管理システム３０２の構成を示している。図３及び図４を参照すると、工程の最初として、日本の本社にいる上流工程の開発者３０９がソースファイルの雛形４０９の中に日本語でＡＰＩの仕様４０１を記述し、ソースファイル管理システム３０２に格納する。ソースファイル管理システム３０２においては、その際、クライアント３０３との間の通信手段であり、クライアントからの指示を解釈する通信部５０２を介してソースファイル４０９を受信し、格納手段である格納部５０１に格納する。通信部５０２における通信手段としては、任意のネットワークプロトコルを用いることができるが、典型的にはＨＴＴＰやＷｅｂサービスが用いられる。格納手段としては、ハードディスク内のファイルシステム、ＣＶＳ等のバージョン管理システム、データベース、あるいは、クライアントに分散格納するＰ２Ｐ技術等を用いる。

開発者３０９は日本と中国の開発者３０７にソフトウェア作成作業を割り振る。この時点でソースファイルは図１のようになっている。ソースファイル管理システム３０２においては、誰がいつまでに何をすべきかを管理する工程管理機能と組み合わせることや、言語毎のコメント記述の進捗状況を管理、表示する進捗状況管理手段を備えることも有効である。

クライアントは、格納されているソースファイル４０９にどのような種類の言語が使用されているかを知りたい場合がある。クライアントは通信部５０２を介して、言語種類提示部５０３に問い合わせる。言語種類提示部５０３は格納部５０１の中の所望のソースファイルをコメント解釈部５１６によって分析し、コメント中の言語符号を数え上げることによって使用されている言語の種類を求め、クライアントに提示する。もしくは、後述する言語種類管理手段に問い合わせて、使用されている言語の種類を求めるようにシステムが構成されていてもよい。クライアントへの提示方法としては、ＨＴＭＬによるＷｅｂブラウザを介しての表示、ＷｅｂサービスやＣＯＲＢＡによる通信及びクライアント側ソフトウェアでの表示ができるようにする。クライアント側ソフトウェアとしては、Ｅｃｌｉｐｓｅ等のソフトウェア開発環境、ＰＬＭ製品、ブラウザ等を用いることができる。

格納部５０１に格納されるソースファイルに多国語でコメントを記述する形式は大別して３つの形式を用いることができる。いずれの形式を用いるようにしても良い。
（１）機能を示す機能符号とコメントの自然言語の種類を表す言語符号とを組み合わせた組合せ符号が付加されている形式、
（２）機能を示す機能符号に続いてコメントの自然言語の種類を表す言語符号が付加されている形式、
（３）より一般的な、機能を示す機能符号とコメントの自然言語の種類を表す言語符号とが付加されている形式である。

図１に示しているメソッド「ｓａｙ（）」の引数「ｒｅｐｅａｔ」に関するコメント１０１を例にとって、本発明による形式を説明する。以下において、「＠ｐａｒａｍ」は説明のために用いるＪａｖａｄｏｃのタグであり、他の表現でも構わない。また、ｊａは“Ｊａｐａｎｅｓｅ”のような他の表現でも構わない。ひとつの機能に関する多国語の説明全体をコメントブロックと呼ぶ。文字コードとしては、Ｕｎｉｃｏｄｅなど多国語を表現可能な文字コードであればよい。

図２のコメントブロック２０１の形式では、「メソッドの引数」を表す機能に「＠ｐａｒａｍ」という機能符号を割り当て、日本語による記述には「ｊａ」という言語符号を割り当てている。コメントブロック２０１の中の組み合わせ符号「＠ｐａｒａｍ．ｊａ」は機能符号と言語符号を組み合わせた符号の例である。フランス語のコメントの組み合わせ符号の例は「＠ｐａｒａｍ．ｆｒ」であり、中国語のコメントの組み合わせ符号の例は「＠ｐａｒａｍ．ｚｈ」である。この例でも英語ではデフォルトとして言語符号を省略している。この形式は開発者にとって読みやすい利点がある。

図６は、上記組み合わせ符号をＸＭＬ形式によるコメントに適用した例を示している。ｐａｒａｍタグとｌａｎｇｕａｇｅアトリビュートが組み合わせられた組み合わせ符号となっている。続けて表記して“ｐａｒａｍ．ｌａｎｇｕａｇｅ”というようなタグあるいはアトリビュートとして構成してもよい。

図７と図２１は、コメントが機能を表す機能符号「＠ｐａｒａｍ」に続いて自然言語の種類を表す言語符号が付加されている例を示している。図７では言語符号としては日本語を表す＜ｊａ＞、フランス語を表す＜ｆｒ＞、中国語を表す＜ｚｈ＞が続いている。また、この例では英語はデフォルトとして言語符号を省略している。図２１ではＪａｖａｄｏｃのインラインタグの記法によって言語符号と説明文が中括弧で囲まれている。この形式の利点は、既存のＪａｖａｄｏｃの文法の範囲内で多国語を実現していることである。

図８は、機能を表す機能符号に続いて自然言語の種類を表す言語符号が付加されている形式をＸＭＬ形式によるコメントに適用した例を示している。＜ｐａｒａｍ＞タグに続いて、＜ｌａｎｇｕａｇｅ ｔｙｐｅ＝”ｊａ”＞というような各言語を表す言語符号が付加されている。この形式も既存のＣ＃言語の文法の範囲内で多国語を実現している利点を有する。

その他の形式としては、図９及び図１０のような、機能符号が言語符号に挟まれている例が考えられる。利点としては、特定の言語に関するコメントのみを抽出する操作が容易である事が挙げられる。

図５のコメント解釈部５１６は、ソースファイルを解釈し、コメント中の機能符号、言語符号、あるいは機能符号と言語符号の組み合わせ符号を抽出し、他の構成要素に対しソースファイル中で使用されている言語に関する情報を提供する機能を有する。コメント中の符号を解釈する方法としては、コメント解釈部５１６中に解釈方法をソフトウェアとして埋め込む方法の他、コメントの解釈方法を含むプラグインソフトウェア、あるいはＸＭＬのＤＴＤや他の書式による文法定義ファイルを外部から供給可能とする構成も可能である。これにより、様々なコメントの文法形式を柔軟に対応できる。

言語の種類が問い合わされるたびにソースファイルを解釈して数え上げてもよいが、言語種類管理部５０４に記憶しておいてそれを読み出す方法も有効である。言語種類管理部５０４は言語の種類を記憶、追加、削除等行う管理処理部である。ソースファイルが追加されたり変更されたりすると内部の記憶手段に言語の種類を記憶する。図１１に示すような、言語の種類をわかりやすく表示し、容易に追加、削除するためのグラフィックユーザインタフェースＧＵＩを備えるように構成されていてもよい。記憶する言語の種類を管理するだけではなく、言語の追加においてはソースファイル中に追加する言語の符号を一斉に埋め込むことを、言語の削除においてはソースファイル中の削除する言語のコメントを一斉に削除することも考えられる。これにより、管理者や開発者は、ソースファイル中で使用されている言語の種類を表示、追加、削除できるようになり、管理の手間が大幅に低減する。

クライアントが従来型の単一言語のコメントのみを処理する開発環境を有している場合、指定の言語のコメントのみを含むソースファイルを作成し、クライアントに送出することも有用である。図１２において、言語抽出部５０５は、格納部５０１からソースファイル１２０４を取り出し、指定の言語以外の言語を削除することにより指定の言語のコメントのみを含むソースファイル１２０５を作成する。

クライアントにおいて指定の言語によるコメントあるいはソースコードに変更を加えたソースファイルを格納部５０１に格納する際は、複数言語マージ部５０６はクライアントから送られた変更済みのソースファイル１２０６に、格納部５０１から新たに取り出したソースファイルに含まれる前記指定の言語以外の言語によるコメントを抽出し、前記変更済みのソースファイル１２０６にマージすることにより、全ての言語が含まれるソースファイル１２０７を再生成して格納する。これにより、単一の言語のコメントのみを処理可能な開発環境においてもコメントの編集が可能である。

日本の開発者がソースコードを変更する際、ＡＰＩ仕様の変更も必要になったとする。その際、日本語のコメントの変更により仕様変更を行う。他の言語のコメントの変更も必要となるが、中国語やフランス語等はその国の開発者か翻訳者に委ねたい。その場合、図１３のように、更新が必要となった他の言語に更新が必要である旨を表す符号「／ｕｐｄａｔｅ」（更新符号）を付加する更新符号付加部５０７を備えるように構成する。ソースファイル管理システム内において、更新符号付加部５０７は通信部５０２を介して受信するソースファイルを監視し、変更前の版の同一箇所のコメントと比較して差異があれば、変更があったとして、変更を検出した言語によるコメントと同一のコメントブロックに属する他の言語によるコメントに更新符号「／ｕｐｄａｔｅ」を付加する。更新符号は他の形式でも構わない。

更新符号を付加しても、実際に編集あるいは翻訳作業が行われないと役には立たない。ソースファイル管理システムは変更を検出すると、変更があったことと変更すべき箇所をクライアントに提示する。更新符号付加部５０７は更新箇所提示部５０８に変更を検出した旨を通知する。更新箇所提示部５０８は通信部５０２を介してクライアントに通知する。図１４は、クライアントにおける編集ソフトウェアの画面の例である。編集ソフトウェアは更新箇所提示部５０８からどのファイルのどの場所で変更が必要であるかを表す情報を提供され、変更が必要な箇所を強調表示するなどして開発者が編集を行いやすいように計らう。図１４では、下線を引いている。更新箇所の提示方法としては、更新符号を用いる方法、ファイル名と行番号を送信する方法が考えられる。これらは、言語間のコメントの意味の不一致を容易に識別し、コメントの修正漏れを防止する効果がある。また、本機能は進捗管理にも有用である。

コメントの翻訳には機械翻訳を用いるよう構成されていてもよい。機械翻訳部５０９は更新符号付加部５０７と同様の方法により言語のコメントへの変更を検出すると、機械翻訳を用いて他の言語へ翻訳を行い既存のコメントを置き換えたのち、格納部５０１へ格納する。しかし、機械翻訳の翻訳品質はあまり高くないため、機械翻訳符号付加部５１０によって、図１５のように機械翻訳であることを示す符号である機械翻訳符号「／ｍｔ」を付加するよう構成される。これにより、後日、翻訳者は翻訳を確認することができる。機械翻訳の利用により低いコストでのオフショア開発が可能となり、同時に用いる機械翻訳符号付加手段（機械翻訳符号付加部５１０）により、翻訳の品質を管理することが可能となる。

ところで、例えば、開発者のＡさんは、日本語と英語のコメントとソースコードのみを編集してもよい、翻訳者のＢさんは、フランス語のコメントのみを編集してもよいというように、人によって許される操作を制限したいことがある。そのような操作の制限に関する情報を管理するために操作制限部５１２を備える。図１６にそのような操作制限を管理する画面の例を示す。図１６においては、開発者、役割、言語を表しているチーム名、許される操作の一覧として操作制限情報を表示し、管理している。操作制限部５１２はそのような情報をクライアントに提供し、クライアントはその情報を元に操作を制限する。また、操作制限部５１２はクライアントに操作制限に関する情報を提供するだけでなく、言語の追加や削除といったソースファイル管理システム内での操作に関しても制限を加えることができる。操作の制限は個人単位ではなく、開発者、翻訳者といった役割によって行うこともできる。制限の単位はコメント、行、文字、メソッドといった詳細な単位から、ファイルや言語といった大きな単位が考えられる。これらの制限手段には、翻訳者が誤ってソースコードを変更してしまうような事故を防ぐ効果と、管理権限がない開発者が故意に特定の言語を削除するような妨害工作を防ぐ効果がある。

また、複数のクライアントによる同時編集に対処するため、チェックイン、チェックアウト、ファイルロック、エレメント（コメント、行、文字、メソッド）単位の排他制御手段を備えてもよい。更に、変更履歴及びバージョンを管理する変更履歴管理と、変更点を提示する変更点提示手段とを備えてもよい。

ソースファイル管理システムは、最終的に必要な説明書を生成する説明書生成部５１３を備えるように構成されていてもよい。図１７に示すように、説明書生成部５１３は格納部５０１から取り出した多国語によるソースファイル４０９から、所望の言語によるコメントとソースコードのみを用いてその言語による説明書４０６、４０７を生成する。生成した説明書は格納部５０１に格納しても、印刷しても、クライアントに送ってもよい。説明書生成部５１３を設けることにより、単一の言語の説明書のみならず、内容に不一致のない複数の異なる言語の説明書をそれぞれ生成する効果がある。

ソースファイル管理システムは翻訳料金を管理する課金機能を備える。図１８に課金管理機能を示す。翻訳量記録部５１５は、翻訳者１８２がソースファイルに対し翻訳作業を行う度にその量を翻訳者単位に設けられた翻訳量カウンタ１８４に記録する。翻訳依頼量記録部５１４は開発者１８８が翻訳者に翻訳を依頼する度にその量を翻訳依頼量１８６に記録する。最終的には、翻訳費算出部５１７により、翻訳単価１８９と記録した翻訳量とから、翻訳者１８２の翻訳収入１８１０と開発者１８８の翻訳支出１８１１とが算出される。課金の単位はソースファイル単位でも、行単位でもワード単位でもよい。翻訳費算出部により、翻訳を依頼した開発者の翻訳費用の算出と、翻訳を行った翻訳者が得る翻訳料の算出が容易になる。なお、サービスとして本システムを運用する際には、翻訳料のみならず、本システムの使用料金を自動的に計算するように構成することも有効である。

複数のクライアントによる編集は言語の異なるコメント間での説明の不一致の原因となる。図２０を用いて、不一致を解消し、ある機能に関する全ての言語の説明を一致させるソースファイルの編集方法を示す。本方法はソースファイル管理システムを使用するクライアント間で協調して行う方法であるが、ソースファイル管理システムとは異なるファイルサーバその他のファイル交換手段を用いても適用可能である。

複数のクライアントによりソースファイルの編集作業を開始する（２００１）。あるクライアントがネットワークを介してソースファイル管理システムあるいはファイルサーバからソースファイルを受信（２００２）する。その際、ファイルをロックするようにファイルサーバが構成されていてもよい。自分の受け持ちの言語によるコメントに対し新たな修正を行うか判断し（２００３）、行った場合、新たな修正を行った言語以外の言語のコメントに更新を必要とすることを示す更新符号を付加する（２００４）。ここで、更新符号を付加するのは新たな修正を行ったコメントが属するコメントブロックに含まれる他の言語のコメントである。この更新符号の付加はソースファイル管理システムにおいて行っても、クライアントの側で行ってもよい。

次に、ソースファイル内の自分の受け持ちの言語によるコメントに更新符号が付加されているものがあるか検索する（２００５）。更新符号が付加されていたら、更新符号が付加されていない言語によるコメントに意味を合わせるよう修正し（２００６）、更新符号を削除する（２００７）。変更が行われたソースファイルはネットワークを介してソースファイル管理システムに送信し格納する（２００８）。

ソースファイル中のすべての更新符号がなくなり、かつ、全てのクライアントにおいて新たな修正の必要がなくなれば編集作業は終了である（２００９、２０１０）。そうでない場合は、２００２に戻って繰り返す。

図１９に英語・日本語・フランス語の３カ国語によりコメントを更新する例を示す。全ての言語が修正されていない状態１９０１から説明を始める。即ち、あるクラスの説明として、全ての言語のコメントが「こんにちはクラス」という意味を有している。

状態１９０２では、英語を用いる開発者が、ソースコードの変更に伴う仕様の変更を行っている。例では、前記開発者は、説明中のクラスは「Ｈｅｌｌｏ」ではなく、「Ｇｏｏｄ ｍｏｒｎｉｎｇ」と表示すべきだと判断したため、コメント中の「Ｈｅｌｌｏ」を「Ｇｏｏｄ ｍｏｒｎｉｎｇ」に変更した。その際、ステップ２００４により他の言語のコメントには更新符号／ｕｐｄａｔｅを付加する。更新符号の付加はクライアントで行っても、ソースファイル管理システムで自動的に行ってもよい。

状態１９０３では日本語の開発者がステップ２００５〜２００７を行っている。即ち、更新符号が付加されていない英語のコメントに日本語のコメントを合わせて「おはようクラス」と修正し、更新符号を削除した。

状態１９０４では、日本語の開発者がソースコードを再度変更し、説明中のクラスは「おはよう」ではなく、「こんばんは」を表示するようにしたとする。日本の開発者はコメントを「こんばんはクラス」と変更した。状態１９０４の前に一度ソースファイル管理システムに格納してある場合、ソースファイル管理システムは「おはよう」から「こんばんは」へ新たな変更が生じたことを検出し自動的に他の言語に更新符号を付加する。状態１９０３からソースファイル管理システムへの格納を経ずに、状態１９０４の編集を行う場合は、日本の開発者は手作業で他の言語のコメントに更新符号を付加する。この操作はクライアントの編集ソフトウェアが自動的に行ってもよい。

状態１９０５と状態１９０６では、ステップ２００５〜２００７によりフランス語と英語のコメントを更新符号が付加されていない言語（日本語）に意味を合わせる翻訳作業を行っている。全ての更新符号と仕様変更とがなくなった時点で、全ての言語によるコメントの意味が統一されている。図１９の状態１９０６では全ての言語のコメントが「こんばんは」になった。以上の編集方法により、世界中に離れてコメントの翻訳作業を行う翻訳者や技術者がそれぞれの言語によるコメントを不一致なく更新し、所望の自然言語によるソフトウェア説明書を出力することができるようになる。

本発明のソースファイル管理システムは、ソフトウェア開発を国際的な分業で行う大規模な製品開発や、ソフトウェア開発を外国に発注して行うオフショア開発において、各国の開発チームが日常使用する言語を用いて仕様書作成を行い、かつ、開発チーム間で不一致なく各言語の仕様書を更新する方法を提供する。このようなシステムを構築できれば、コストの低減のみならず、仕様書の更新漏れによるソフトウェアの不具合を防止することにつながる。

また、言語の種類を管理すること、機械翻訳を用いること、更新を通知すること、翻訳料を算出することは分散開発において開発コストと管理コストを大幅に低減することに有効である。

Claims (12)

1. プログラミング言語で記述されたソースコード文及び前記ソースコード中の機能を説明するコメントが複数の種類の自然言語で記述されたソースファイル内において、前記機能を示す機能符号とコメントの自然言語の種類を表す言語符号とを組み合わせた組合せ符号が付加されているソースファイルを格納する格納手段と、
   クライアントからの要求によってネットワークを介してソースファイルを送信あるいは受信するソースファイル通信手段と、
   ソースファイル中のコメントが含む自然言語の種類を提示する言語種類提示手段と、
   を備えることを特徴とするソースファイル管理システム。
2. プログラミング言語で記述されたソースコード文及び前記ソースコード中の機能を説明するコメントが複数の種類の自然言語で記述されたソースファイル内において、前記機能を示す機能符号に続いてコメントの自然言語の種類を表す言語符号が付加されているソースファイルを格納する格納手段と、
   クライアントからの要求によってネットワークを介してソースファイルを送信あるいは受信するソースファイル通信手段と、
   ソースファイル中のコメントが含む自然言語の種類を提示する言語種類提示手段と、
   を備えることを特徴とするソースファイル管理システム。
3. プログラミング言語で記述されたソースコード文及び前記ソースコード中の機能を説明するコメントが複数の種類の自然言語で記述されたソースファイル内において、前記機能を示す機能符号とコメントの自然言語の種類を表す言語符号とが付加されているソースファイルを格納する格納手段と、
   クライアントからの要求によってネットワークを介してソースファイルを送信あるいは受信するソースファイル通信手段と、
   ソースファイル中のコメントが含む自然言語の種類を提示する言語種類提示手段と、
   を備えることを特徴とするソースファイル管理システム。
4. 請求項１ないし３に記載のソースファイル管理システムにおいて、更に、
   ソースファイル内のコメントの記述に用いる自然言語の種類を記憶、追加あるいは削除する言語種類管理手段、
   を備えることを特徴とするソースファイル管理システム。
5. 請求項１ないし３に記載のソースファイル管理システムにおいて、更に、
   複数の自然言語によるコメントからクライアントが指定した指定自然言語によるコメントのみを抽出し、指定自然言語のコメントを含むソースファイルをソースファイル通信手段を介して送信する言語抽出手段と、
   指定自然言語のコメントを含むソースファイルをソースファイル通信手段を介して受信し、元の複数の自然言語によるコメントを含むソースファイルにマージする複数言語マージ手段と、
   を備えることを特徴とするソースファイル管理システム。
6. 請求項１ないし３に記載のソースファイル管理システムにおいて、更に、
   ある自然言語によるコメントに変更を検出した際に、他の自然言語により記述されたコメントに更新が必要である旨を示す更新符号を付加する更新符号付加手段、
   を備えることを特徴とするソースファイル管理システム。
7. 請求項１ないし３に記載のソースファイル管理システムにおいて、更に、
   ソースファイル内において更新が必要な箇所を提示する更新箇所提示手段と、
   更新が必要なことをクライアントに通知する更新通知手段と、
   を備えることを特徴とするソースファイル管理システム。
8. 請求項１ないし３に記載のソースファイル管理システムにおいて、更に、
   機械翻訳を用いてソースファイル内のコメントの翻訳を行う翻訳手段と、
   前記翻訳を行ったコメントに前記機械翻訳を用いたことを示す符号を付加する機械翻訳符号付加手段と、
   を備えることを特徴とするソースファイル管理システム。
9. 請求項１ないし３に記載のソースファイル管理システムにおいて、更に、
   本ソースファイル管理システム及びクライアントにおいて利用者に許される操作を制限する操作制限手段と、
   を備えることを特徴とするソースファイル管理システム。
10. 請求項１ないし３に記載のソースファイル管理システムにおいて、更に、
    ソースファイルを元にクライアントが指定する自然言語による説明書を生成する説明書生成手段、
    を備えることを特徴とするソースファイル管理システム。
11. 請求項１ないし３に記載のソースファイル管理システムにおいて、更に、
    開発者が翻訳者に依頼した翻訳の翻訳依頼量を記録する翻訳依頼量記録手段と、
    翻訳者が行った翻訳の翻訳量を記録する翻訳量記録手段と、
    翻訳費を算出する翻訳費算出手段と、
    を備えることを特徴とするソースファイル管理システム。
12. コンピュータシステムを用いて、請求項１ないし３に記載のソースファイルをネットワークを介して編集するソースファイル編集方法であって、
    前記機能を表す符号の機能符号とコメントの自然言語の種類を表す符号の言語符号とコメントが更新を必要とする旨の符号が付加されているソースファイルをネットワークを介して受信するステップと、
    コメントに新たな修正を行った場合、修正を行った自然言語以外の自然言語で記述されたコメントに更新を必要とすることを示す符号の更新符号を付加するステップと、
    編集を行いたい自然言語によるコメントに更新符号が付加されていたら、更新符号が付加されていない自然言語によるコメントに意味を合わせて修正し、更新符号を削除するステップと、
    修正したソースファイルをネットワークを介して送信するステップと、
    を含み、全ての更新符号がなくなり、かつ、全てのクライアントにおいて新たな修正の必要がなくなるまで上記のステップを繰り返すソースファイル編集方法。

Images