特開 2024-164392 ソフトウェア開発支援装置、ソフトウェア開発支援方法、およびソフトウェア開発支援プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024164392

(43)【公開日】2024-11-27

(54)【発明の名称】ソフトウェア開発支援装置、ソフトウェア開発支援方法、およびソフトウェア開発支援プログラム

(51)【国際特許分類】

   G06F 8/30 20180101AFI20241120BHJP

【ＦＩ】

G06F8/30

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2023079837

(22)【出願日】2023-05-15

(71)【出願人】

【識別番号】000005234

【氏名又は名称】富士電機株式会社

(74)【代理人】

【識別番号】110004185

【氏名又は名称】インフォート弁理士法人

(74)【代理人】

【識別番号】100121083

【弁理士】

【氏名又は名称】青木 宏義

(74)【代理人】

【識別番号】100138391

【弁理士】

【氏名又は名称】天田 昌行

(74)【代理人】

【識別番号】100132067

【弁理士】

【氏名又は名称】岡田 喜雅

(74)【代理人】

【識別番号】100141232

【弁理士】

【氏名又は名称】飯塚 達

(72)【発明者】

【氏名】澤田 孝雄

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376BC07

5B376BC23

5B376BC38

5B376BC70

5B376BC79

(57)【要約】

【課題】メモリ安全性の保証のための作業の負担を軽減させる。
【解決手段】記憶部１０１には、Rust言語による記述のうちのunsafeを宣言したブロック内において許容する記述が定義されている記述ルールが格納されている。抽出部１０２は、Rust言語で記述された対象ソフトウェアのソースコードから、unsafeの宣言がされているブロックを抽出する。判定部１０３は、抽出部１０２により抽出されたブロック内に含まれている記述を許可するかどうかの判定を、記憶部１０１に格納されている記述ルールに従って行う。出力部１０４は、判定部１０３による判定によって許可しないと判定された記述を、対象ソフトウェアのソースコードから特定する情報を出力する。
【選択図】図８

【特許請求の範囲】

【請求項1】

Rust言語による記述のうちのunsafeを宣言したブロック内において許容する記述が定義されている記述ルールが格納されている記憶部と、
Rust言語で記述された対象ソフトウェアのソースコードから、unsafeの宣言がされているブロックを抽出する抽出部と、
抽出された前記ブロック内に含まれている記述を許可するかどうかの判定を前記記述ルールに従って行う判定部と、
前記判定によって許可しないと判定された記述を前記ソースコードから特定する情報を出力する出力部と、
を備えることを特徴とするソフトウェア開発支援装置。

【請求項2】

前記記述ルールには、Rust言語による記述のうちのunsafeを宣言したブロック内において許容する記述が、unsafeを宣言した前記ブロックが用いられるソフトウェアの種別毎に定義されており、
前記判定部は、抽出された前記ブロック内に含まれている記述を許可するかどうかの判定を、前記対象ソフトウェアの種別に応じた前記記述ルールに従って行う
ことを特徴とする請求項１に記載のソフトウェア開発支援装置。

【請求項3】

前記記述ルールは、unsafeを宣言した前記ブロックが用いられるソフトウェアについてのソフトウェア階層の階層毎に定義されており、
前記判定部は、抽出された前記ブロック内に含まれている記述を許可するかどうかの判定を、前記対象ソフトウェアについてのソフトウェア階層に応じた前記記述ルールに従って行う
ことを特徴する請求項２に記載のソフトウェア開発支援装置。

【請求項4】

前記記述ルールは、Rust言語においてunsafeを宣言したブロック内でのみ許容される記述のルールと前記記述のルールについての付帯条件との組み合わせによる定義を含むことを特徴とする請求項１に記載のソフトウェア開発支援装置。

【請求項5】

前記出力部は、前記判定によって許可すると判定された記述を前記ソースコードから特定する情報を更に出力することを特徴する請求項１から４のうちのいずれか一項に記載のソフトウェア開発支援装置。

【請求項6】

Rust言語で記述された対象ソフトウェアのソースコードから、unsafeの宣言がされているブロックを抽出し、
抽出された前記ブロック内に含まれている記述を許可するかどうかの判定を、Rust言語による記述のうちのunsafeを宣言したブロック内において許容する記述が定義されている記述ルールに従って行い、
前記判定によって許可しないと判定された記述を前記ソースコードから特定する情報を出力する、
処理をコンピュータが実行することを特徴とするソフトウェア開発支援方法。

【請求項7】

Rust言語で記述された対象ソフトウェアのソースコードから、unsafeの宣言がされているブロックを抽出し、
抽出された前記ブロック内に含まれている記述を許可するかどうかの判定を、Rust言語による記述のうちのunsafeを宣言したブロック内において許容する記述が定義されている記述ルールに従って行い、
前記判定によって許可しないと判定された記述を前記ソースコードから特定する情報を出力する、
処理をコンピュータに実行させることを特徴とするソフトウェア開発支援プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は情報処理技術に関する。

【背景技術】

【0002】

ソースコードがコーディングルールに準拠しているかどうかを解析して解析結果を出力するというソースコード解析支援システムが知られている（例えば特許文献１参照）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１０－１９８５２２号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

メモリ安全性において定評のあるプログラム言語のひとつとして広く知られているRust（ラスト）は、unsafeという仕組みを有している。unsafeを宣言したブロック内では、自由度の高いプログラミングを許容する代償として、コンパイラによるメモリ安全性のチェックが行われず、プログラマの責任となる。このため、プログラマには、作成したプログラムに対する入念なチェック作業が強いられる。

【課題を解決するための手段】

【0005】

実施形態のひとつでは、ソフトウェア開発支援装置が記憶部と抽出部と判定部と出力部とを備える。記憶部には、Rust言語による記述のうちのunsafeを宣言したブロック内において許容する記述が定義されている記述ルールが格納されている。抽出部は、Rust言語で記述された対象ソフトウェアのソースコードから、unsafeの宣言がされているブロックを抽出する。判定部は、抽出部により抽出されたブロック内に含まれている記述を許可するかどうかの判定を、記憶部に格納されている記述ルールに従って行う。出力部は、判定部による判定によって許可しないと判定された記述を、対象ソフトウェアのソースコードから特定する情報を出力する。

【発明の効果】

【0006】

上記の態様によれば、メモリ安全性の保証のための作業の負担が軽減される。

【図面の簡単な説明】

【0007】

【図1A】Rust言語においてunsafeを宣言したブロック内でのみ使用が許容される機能の記述例（その１）である。

【図1B】Rust言語においてunsafeを宣言したブロック内でのみ使用が許容される機能の記述例（その２）である。

【図2】ソフトウェア開発の手順の一例を示した図である。

【図3】ルールチェックの手順の一例を示した図である。

【図4】ソフトウェア分類定義の定義例を示した図である。

【図5】ソフトウェアの階層構造の一例を示した図である。

【図6A】unsafe記述ルール定義の一例を示した図である。

【図6B】unsafe記述ルールの一例を示した図である。

【図7】ソースファイル分類リストの一例を示した図である。

【図8】ソフトウェア開発支援装置の機能構成例を示した図である。

【図9】情報処理装置のハードウェア構成例を示した図である。

【図10A】ソフトウェア開発支援処理の処理内容を示したフローチャート（その１）である。

【図10B】ソフトウェア開発支援処理の処理内容を示したフローチャート（その２）である。

【図11】違反リストの一例を示した図である。

【図12】許可リストの一例を示した図である。

【図13】プログラム修正手順の一例を示した図である。

【発明を実施するための形態】

【0008】

以下、図面を参照しながら、実施形態を詳細に説明する。

【0009】

広く知られているプログラム言語のひとつにRustという言語がある。Rust言語はメモリ安全性や処理の高速性などに定評がある。

【0010】

このRust言語には、unsafeという仕組みが用意されている。このunsafeを宣言したブロック内では、他の部分よりも自由度の高いプログラミングが許容される。その一方で、unsafeを宣言したブロック内の記述はメモリ安全性についてのコンパイラによるチェックが行われず、当該ブロック内の記述に対するメモリ安全性の保証はプログラマの責任となる。

【0011】

図１Ａ及び図１Ｂは、Rust言語においてunsafeを宣言したブロック内でのみ使用が許容される機能の記述例である。なお、説明の便宜のために、この記述例では各行の先頭に行番号を表しており、例えば、「001:」の表示は第１行目を示している。

【0012】

図１Ａに示す第１の例は、unsafeを宣言したブロック内で生ポインタ（raw pointer）の参照外しが記述されている例である。なお、生ポインタとは、「let … as *const」あるいは「let … as *mut」の文により定義されたポインタである。

【0013】

この第１の例において、第５行目の文は、ポインタio_regを生ポインタとして定義することを記述している。この生ポインタio_regに関し、第８行目の文は、生ポインタio_regの参照先に値「１」を代入することを記述している。また、第９行目の文は、「io_reg data =」の表示に続けて、生ポインタio_regの参照先の値を取得して表示することを記述している。生ポインタの参照先には、有効なデータが格納されていることが保証されていないため、このような参照先の値を取得する記述は、生ポインタの参照外しとして扱われ、Rust言語では一般的には禁止される。

【0014】

但し、第１の例では、第７行目の文においてunsafeの宣言を記述しており、第７行目の「unsafe {」の記載と第１０行目の「}」の記載とに挟まれている第８行目及び第９行目の文は、unsafeを宣言したブロック内の記述となる。従って、第９行目の文はRust言語において例外的に許容され、プログラムのコンパイルにおいてメモリ安全性に関するエラーが出力されることはない。このため、プログラマは、第９行目の文に記述された処理が不具合を引き起こす場合がないこと、より具体的には、当該処理の実行時点において、常に、生ポインタio_regの参照先に有効なデータが格納されていることを十分に検証する必要がある。

【0015】

図１Ｂに示す第２の例は、unsafeを宣言したブロック内にstatic mut変数をアクセスしたり変更したりする記述が含まれている例である。なお、static mut変数とは、変更可能な（ミュータブルな）静的変数である。

【0016】

この第２の例において、第１行目の文は、static mut変数G_VARを定義して初期値「０」を代入することを記述している。この変数G_VARに関し、第５行目の文は、変数G_VARの値をインクリメントすることを記述しており、第６行目の文は、「G_VAR =」の表示に続けて、変数G_VARの値を取得して表示することを記述している。static mut変数は、複数のスレッドでの競合がないことが保証されていないため、変数G_VARに対してこのようなアクセスや変更を行う記述についても、Rust言語では一般的には禁止される。

【0017】

但し、第２の例では、第４行目の文においてunsafeの宣言を記述しており、第４行目の「unsafe {」の記載と第７行目の「}」の記載とに挟まれている第５行目及び第６行目の文は、unsafeを宣言したブロック内の記述となる。従って、第５行目及び第６行目の文はRust言語において例外的に許容され、プログラムのコンパイルにおいてメモリ安全性に関するエラーが出力されることはない。このため、プログラマは、第５行目及び第６行目の文に記述された処理が不具合を引き起こす場合がないこと、より具体的には、複数のスレッドでの変数G_VARの競合の発生の可能性がないことを十分に検証する必要がある。

【0018】

以上のように、Rust言語により作成されたプログラムにおいてunsafeの宣言が多用されていると、Rust言語が本来的に有しているメモリ安全性の特徴が十分には活かせなくなり、メモリ操作に関する不具合発生の可能性が高くなる。また、ひいては、メモリ安全性の保証のためにプログラマが行う検証作業の負担が増加する。

【0019】

そこで、これより説明する実施形態では、unsafe宣言ブロック内の記述において許容する記述ルールを予め定義しておく。そして、この記述ルールに従って、Rust言語により記述されたプログラムのソースコード（ソフトウェア）のチェックを行うようにする。そして、このチェックによってルール違反が検出された場合に、当該違反を解消する修正をプログラマが行うようにする。

【0020】

まず、図２について説明する。図２は、ソフトウェア開発の手順の一例を示したものであり、後述するソフトウェア開発支援装置を用いてソフトウェア開発を行う場合の手順を表したものである。

【0021】

図２の手順が開始されると、まず、Rust言語によりソースコードを記述したプログラムがプログラマにより作成される（Ｓ１０１）。次に、Rust言語のコンパイラがＰＣ上で実行されて、作成したプログラムのコンパイルが行われる（Ｓ１０２）。なお、「ＰＣ」とはPersonal Computerの略称である。

【0022】

このプログラムのコンパイルにおいて、エラーが検出されたかどうかが判定される（Ｓ１０３）。ここで、エラーが検出された場合（Ｓ１０３がＹＥＳの場合）、当該エラーを解消するためのプログラムの修正がプログラマにより行われ（Ｓ１０４）、その後、Ｓ１０２の手順に戻り、修正後のプログラムに対するコンパイル以降の手順が改めて行われる。

【0023】

一方、プログラムのコンパイルにおいてエラーが検出されなかった場合（Ｓ１０３がＮＯの場合）、当該プログラムに対して、前述した記述ルールに基づいたルールチェックが行われる（Ｓ１０５）。そして、このルールチェックにおいて、当該プログラムからルール違反が検出されたかどうかが判定される（Ｓ１０６）。

【0024】

ここで、ルール違反が検出された場合（Ｓ１０６がＹＥＳの場合）、当該ルール違反を解消するためのプログラムの修正がプログラマにより行われる（Ｓ１０７）。その後、Ｓ１０２の手順に戻り、修正後のプログラムに対するコンパイル以降の手順が改めて行われる。

【0025】

一方、ルールチェックにおいてプログラムからルール違反が検出されなかった場合（Ｓ１０６がＮＯの場合）、当該プログラムを製品に実装してテストが行われ（Ｓ１０８）、当該テストに合格するとプログラムは完成となる。

【0026】

以上のように、本実施形態に係るソフトウェア開発の手順は、図２において破線の枠で囲まれている、unsafe宣言ブロック内での記述ルールに基づいたルールチェックに関する手順を含む点を特徴としている。

【0027】

次に図３について説明する。図３は、ルールチェックの手順の一例を示した図であって、図２において破線の枠で囲まれている手順の詳細を示したものである。

【0028】

まず、ルールチェックに先だって、unsafe記述ルール１０が例えば開発プロジェクト・開発部門などにより作成される（Ｓ２０１）。unsafe記述ルール１０は、ソフトウェア分類定義２０とunsafe記述ルール定義３０とを用いて作成される。

【0029】

図４は、ソフトウェア分類定義２０の定義例を示したものである。この定義例は、ソフトウェアの階層構造の各階層に従ってソフトウェアを分類する場合の例であり、予め用意されている。

【0030】

図５は、ソフトウェアの階層構造の一例を示したものである。この階層構造における「アプリケーション層」、「ミドルウェア層」、及び「ドライバ層」の各階層が、図４における「アプリケーション」、「ミドルウェア」、及び「ドライバ」の分類名称にそれぞれ対応している。

【0031】

なお、本実施形態では、「ライブラリ」は、様々なソフトウェアにおいて引用される汎用のソフトウェアの集合体を表すものとし、前述した階層構造のいずれにも分類されない別個の分類として扱うこととして、図４及び図５にそれぞれ示している。

【0032】

図６Ａはunsafe記述ルール定義３０の一例である。このunsafe記述ルール定義３０は、「ルールＮｏ．」、「ルール」、及び「付帯条件」の各項目を含むテーブルの形式を有している。

【0033】

「ルールＮｏ．」の項目には、図６Ａに例示したテーブルの各行を識別する情報が示されている。

【0034】

「ルール」の項目には、Rust言語においてunsafeを宣言したブロック内でのみ許容される記述ルールが示されている。例えば、ルールＮｏ．「５－１」のルール「インラインアセンブリ」は、Rust言語で記述されるプログラムにインラインアセンブリを埋め込むという記述ルールである。また、この「インラインアセンブリ」を除く４種類のルールは、Rust言語において「unsafeの強大な力（unsafe superpower）」などと称されて広く知られている４つの記述ルールのそれぞれである。これらの記述ルールに従った記述は既存のコンパイラにより検出が可能であり、当該記述がunsafeを宣言したブロック外に配置されていた場合にはコンパイラからメモリ安全性に関するエラーが出力される。一方、当該記述がunsafeを宣言したブロック内に配置されていた場合には、コンパイラからメモリ安全性に関するエラーは出力されない。

【0035】

「付帯条件」の項目には、「ルール」で示されている記述ルールに付帯する条件が示されている。

【0036】

例えば、ルール「生ポインタの参照外し」については、ルールＮｏ．「１－１」では、付帯条件が「アクセス許可アドレス範囲１」とされている。「アクセス許可アドレス範囲１」はメモリ空間のアドレスの範囲を表している値であり、このルールＮｏ．「１－１」は、「アクセス許可アドレス範囲１」に含まれるアドレスを参照する生ポインタの参照外しを行う記述ルールを表している。また、同様に、ルールＮｏ．「１－２」は、「アクセス許可アドレス範囲２」に含まれるアドレスを参照する生ポインタの参照外しを行う記述ルールを表している。

【0037】

また、例えば、ルールＮｏ．「２－１」は、安全であることが保証されていない関数やメソッドの呼び出しのうちの、ＦＦＩの呼び出しを行う記述ルールである。なお、「ＦＦＩ」とは、Foreign Function Interfaceの略称である。一方、「２－２」は、ＦＦＩ以外の関数やメソッドの呼び出しを行う記述ルールである。

【0038】

また、例えば、ルールＮｏ．「３－１」は、static mut変数、すなわち、ミュータブル（変更可能）である静的変数へのアクセスを行う記述ルールである。一方、ルールＮｏ．「３－２」は、extern {static}変数、すなわち、外部関数における静的変数へのアクセスを行う記述ルールである。

【0039】

また、ルールＮｏ．「４－１」は、付帯条件が定義されていないが、安全であることが保証されていないトレイトを実装する記述ルールである。

【0040】

また、ルールＮｏ．「５－１」は、システムレジスタへのアクセスが記述されたインラインアセンブリを記述する記述ルールである。

【0041】

図６Ｂは、unsafe記述ルール１０の一例である。このunsafe記述ルール１０は、図４に例示したソフトウェア分類定義２０を用いて作成されたものである。

【0042】

図６Ｂに例示したunsafe記述ルール１０は、「ルールＮｏ．」、「ルール」、及び「付帯条件」の各項目と、分類識別子である「１」、「２」、「３」、及び「４」の各項目とを含むテーブルの形式を有している。このうち、「ルールＮｏ．」、「ルール」、及び「付帯条件」の各項目は、図６Ａに例示したunsafe記述ルール定義３０の情報をそのままコピーしたものである。

【0043】

一方、unsafe記述ルール１０において「１」、「２」、「３」、及び「４」と示されている分類識別子は、図４のソフトウェア分類定義２０において各分類に対応付けられている識別子である。unsafe記述ルール１０の作成を行うＳ２０１の手順では、unsafe記述ルール定義３０で定義されている記述ルールでの記述を、unsafeを宣言したブロック内で許可するか否かの設定が、分類識別子で識別されるソフトウェアの分類毎に行われる。

【0044】

図６Ｂの例では、分類識別子で識別される分類に含まれるソフトウェアについて、各ルールＮｏ．で特定される記述ルールでの記述を当該ブロック内で許可する場合に丸印が付与されており、許可しない場合に罰印が付与されている。

【0045】

従って、図６Ｂの例では、例えば、unsafeを宣言したブロック内におけるルールＮｏ．「１－１」の記述ルールでの記述は、「ライブラリ」に分類されたソフトウェアについては許可することが示されている。一方、「アプリケーション」、「ミドルウェア」、及び「ドライバ」に分類されたソフトウェアについては、unsafeを宣言したブロック内におけるルールＮｏ．「１－１」の記述ルールでの記述を許可しないことが示されている。また、例えば、unsafeを宣言したブロック内におけるルールＮｏ．「２－１」の記述ルールでの記述は、図４の例で示されているいずれの分類に属するソフトウェアであっても許可することが示されている。一方、例えば、unsafeを宣言したブロック内におけるルールＮｏ．「２－２」の記述ルールでの記述は、図４の例で示されているいずれの分類に属するソフトウェアであっても許可しないことが示されている。

【0046】

unsafe記述ルール１０は、以上のようにして、ソフトウェア分類定義２０とunsafe記述ルール定義３０とを用いて作成される。

【0047】

図３の説明に戻ると、unsafe記述ルール１０の作成とは並行して、ソースファイル４０の分類が例えば開発プロジェクト・開発部門などによって行われて（Ｓ２０２）、ソースファイル分類リスト５０が作成される。

【0048】

ソースファイル４０は、図２におけるＳ１０３の手順によって、Rust言語のコンパイラによってエラーが検出されなくなったプログラムのソースコードが格納されているファイルである。Ｓ２０２の手順では、このプログラムの分類がソフトウェア分類定義２０に従って行われ、この分類の結果がソースファイル分類リスト５０に示される。

【0049】

図７は、ソースファイル分類リスト５０の一例を示している。

【0050】

ソースファイル分類リスト５０は、ソースファイル４０を個々に識別する「ファイル名」と、ソースファイル４０に格納されているプログラムが含まれる分類を示す「分類識別子」とを対応付けたリストである。なお、分類識別子には、図４のソフトウェア分類定義２０において各分類に対応付けられているものが用いられる。

【0051】

図７において、例えば、「ソースファイルＡ」はソースファイル４０のひとつのファイル名である。この「ソースファイルＡ」に格納されているプログラムは、図５の階層構造における「アプリケーション層」に分類された結果、ソフトウェア分類定義２０において「アプリケーション」に対応付けられている分類識別子「１」が付与されたことが表されている。

【0052】

以上のようにして作成されたunsafe記述ルール１０とソースファイル分類リスト５０とが、ソースファイル４０と共にソフトウェア開発支援装置１００に入力される。ソフトウェア開発支援装置１００は、ソースファイル４０に含まれているプログラムのソースコードからunsafeを宣言したブロックを検索する。そして、当該ブロック内の記述が許可されているかどうかを、unsafe記述ルール１０とソースファイル分類リスト５０とに基づいて判定し、この判定結果を判定結果リスト６０として出力する。

【0053】

その後、判定結果リスト６０に示される判定結果に基づいて、ソースファイル４０に含まれているプログラムの修正がプログラマにより行われる（Ｓ２０３）。この修正が完了したプログラムが、図２のＳ１０８の手順として行われるテストの対象のプログラムとなる。

【0054】

図３に示した手順によるルールチェックは、以上のようにして行われる。

【0055】

次に、ソフトウェア開発支援装置１００について、さらに詳細に説明する。

【0056】

まず、ソフトウェア開発支援装置１００の機能構成例について、図８を用いて説明する。図８に例示したソフトウェア開発支援装置１００は、記憶部１０１、抽出部１０２、判定部１０３、及び出力部１０４を備えている。

【0057】

記憶部１０１には、Rust言語による記述のうちのunsafeを宣言したブロック内において許容する記述が定義されている記述ルールが格納されている。

【0058】

抽出部１０２は、Rust言語で記述された対象ソフトウェアのソースコードから、unsafeの宣言がされているブロックを抽出する。この対象ソフトウェアのソースコードは、例えば、図３に示されているソースファイル４０に格納されているソースコードである。

【0059】

判定部１０３は、抽出部１０２により抽出されたブロック内に含まれている記述を許可するかどうかの判定を、記憶部１０１に格納されている記述ルールに従って行う。

【0060】

出力部１０４は、判定部１０３による上記の判定によって許可しないと判定された記述を、対象ソフトウェアのソースコードから特定する情報を出力する。なお、出力部１０４が、判定部１０３による上記の判定によって許可すると判定された記述を、対象ソフトウェアのソースコードから特定する情報を更に出力するようにしてもよい。

【0061】

記憶部１０１に格納されている記述ルールとは、例えば、図３に手順を示したルールチェックにおけるＳ２０１の手順により作成されたunsafe記述ルール１０である。前述のように、unsafe記述ルール１０は、「ルール」と「付帯条件」との組み合わせ、すなわち、unsafeを宣言したブロック内でのみ許容される記述のルールと当該記述のルールについての付帯条件との組み合わせにより前述の定義がされている。

【0062】

また、前述したように、unsafe記述ルール１０には、unsafeを宣言したブロック内において許容する記述が、当該ブロックが用いられるソフトウェアの種別毎、より具体的にはソフトウェア階層の階層毎に定義されているといえる。そこで、判定部１０３が、抽出部１０２により抽出されたブロック内に含まれている記述を許可するかどうかの判定を、対象ソフトウェアの種別に応じた記述ルールに従って行うようにしてもよい。なお、対象ソフトウェアがソースファイル４０に格納されているプログラムである場合には、対象ソフトウェアの種別の情報は、ソースファイル分類リスト５０から得られる。

【0063】

次に、ソフトウェア開発支援装置１００のハードウェア構成について説明する。

【0064】

図９は情報処理装置７０のハードウェア構成例を示している。この情報処理装置７０を用いてソフトウェア開発支援装置１００を構成することが可能である。

【0065】

情報処理装置７０は、ＣＰＵ７１、メモリ７２、入力装置７３、表示装置７４、補助記憶装置７５、及び通信Ｉ／Ｆ７６の各構成要素を備えているコンピュータである。これらの構成要素はいずれも内部バス７７に接続されており、各構成要素間でデータの授受が可能であるように構成されている。なお、「ＣＰＵ」とはCentral Processing Unitの略語である。また、「Ｉ／Ｆ」とはInterfaceの略称である。

【0066】

ＣＰＵ７１は、例えば、メモリ７２を利用して所定のプログラムを実行することによって情報処理装置７０の各構成要素を制御して、ソフトウェア開発支援装置１００の各構成要素の機能の提供を可能にする。

【0067】

入力装置７３は、例えば、指示の入力用のキーボードやポインティングデバイス等である。

【0068】

表示装置７４は、例えば、各種の情報の表示出力に用いられる。

【0069】

補助記憶装置７５は、例えばフラッシュメモリやハードディスクドライブである。補助記憶装置７５にプログラム及びデータを格納しておき、それらを情報処理装置７０がメモリ７２にロードして使用することができる。

【0070】

通信Ｉ／Ｆ７６は、例えば、必要に応じてＣＰＵ７１から送られてくる指示に従い、不図示の通信ネットワークを介してデータを送受信する。

【0071】

情報処理装置７０を用いてソフトウェア開発支援装置１００を構成する場合には、ＣＰＵ７１が抽出部１０２及び判定部１０３としての機能を提供し、表示装置７４が出力部１０４としての機能を提供し、補助記憶装置７５が記憶部１０１としての機能を提供する。

【0072】

なお、情報処理装置７０を用いてソフトウェア開発支援装置１００を構成する場合、情報処理装置７０が図９に示されている全ての構成要素を含む必要はなく、用途又は条件に応じて一部の構成要素を省略してもよい。例えば、情報処理装置７０を用いてソフトウェア開発支援装置１００を構成する場合に通信Ｉ／Ｆ７６を省略するようにしてもよい。

【0073】

次に、ソフトウェア開発支援装置１００によって行われるソフトウェア開発支援処理について説明する。

【0074】

図１０Ａ及び図１０Ｂは、ソフトウェア開発支援処理の一例の処理内容を示すフローチャートである。なお、図９に例示したハードウェア構成を有する情報処理装置７０を用いてソフトウェア開発支援装置１００を構成する場合には、この処理を記述したソフトウェア開発支援プログラムをＣＰＵ７１に実行させるようにすればよい。

【0075】

ソフトウェア開発支援処理の実行が開始されると、まず、図１０ＡのＳ３０１において、ソフトウェア開発支援装置１００に入力されたソースファイル４０を１つ取得する処理が抽出部１０２により行われる。

【0076】

次に、Ｓ３０２では、ソフトウェア開発支援装置１００に入力されたソースファイル分類リスト５０を参照して、直近に実行されたＳ３０１の処理により取得されたソースファイル４０のファイル名に対応付けられている分類識別子を取得する処理が行われる。この処理は判定部１０３により行われる処理である。

【0077】

Ｓ３０３では、直近に実行されたＳ３０１の処理により取得されたソースファイル４０に格納されているソースコードから、unsafeを宣言したブロックを１つ抽出する処理が抽出部１０２により行われる。

【0078】

Ｓ３０４では、直近に実行されたＳ３０３の処理により抽出されたブロック内の記述を１行取得する処理が判定部１０３により行われる。

【0079】

Ｓ３０５では、ソフトウェア開発支援装置１００に入力されたunsafe記述ルール１０に含まれているルールの定義（図６Ｂの例における「ルール」と「付帯条件」との組み合わせ）を１つ取得する処理が判定部１０３により行われる。

【0080】

Ｓ３０６では、直近に実行されたＳ３０４の処理により取得した記述は、直近に実行されたＳ３０５の処理により取得したunsafe記述ルール１０の定義に該当する記述であるかどうかを判定する処理が判定部１０３により行われる。この判定処理において、Ｓ３０４の処理により取得した記述は、Ｓ３０５の処理により取得したunsafe記述ルール１０の定義に該当する記述であると判定したとき（判定結果がＹＥＳのとき）にはＳ３０７に処理を進める。一方、この判定処理において、Ｓ３０４の処理により取得した記述は、Ｓ３０５の処理により取得したunsafe記述ルール１０の定義に該当する記述ではないと判定したとき（判定結果がＮＯのとき）には、図１０ＢのＳ３１０に処理を進める。

【0081】

Ｓ３０７では、unsafe記述ルール１０を参照して、直近に実行されたＳ３０４の処理により取得した記述は不許可とされているかどうかを判定する処理が判定部１０３により行われる。

【0082】

Ｓ３０７の判定処理は、直近に実行されたＳ３０１の処理により取得したソースファイル４０についてのソフトウェアの分類に基づいて行われる。ソースファイル４０についてのソフトウェアの分類は、直近に実行されたＳ３０２の処理により取得された分類識別子により特定される。従って、この判定処理では、図６Ｂに例示したunsafe記述ルール１０において、直近に実行されたＳ３０５の処理により取得した定義での記述が、当該分類識別子で識別される分類のソフトウェアでは不許可とされているかどうかが判定される。

【0083】

このＳ３０７の判定処理において、Ｓ３０４の処理により取得した記述が、Ｓ３０１の処理により取得したソースファイル４０についての分類では不許可とされていると判定したとき（判定結果がＹＥＳの場合）には、Ｓ３０８処理を進める。一方、Ｓ３０４の処理により取得した記述が、Ｓ３０１の処理により取得したソースファイル４０についての分類では許可とされていると判定したとき（判定結果がＮＯの場合）には、Ｓ３０９に処理を進める。

【0084】

Ｓ３０８では、Ｓ３０７の判定処理によって不許可と判定された記述に関する情報を違反リストに出力する処理が出力部１０４により行われ、その後は、図１０ＢのＳ３１０に処理を進める。一方、Ｓ３０９では、Ｓ３０７の判定処理によって許可と判定された記述に関する情報を許可リストに出力する処理が出力部１０４により行われ、その後は、図１０ＢのＳ３１０に処理を進める。

【0085】

違反リスト及び許可リストは、図３に示されている判定結果リスト６０の具体例である。図１１は違反リストの一例を示しており、図１２は許可リストの一例を示している。

【0086】

図１１と図１２とを対比すると分かるように、違反リストと許可リストとは同様の構造を有しており、「ファイル名」、「分類識別子」、「ルール番号」、及び「行番号」の各項目を有している。

【0087】

「ファイル名」の項目には、直近に実行されたＳ３０１の処理により取得したソースファイル４０のファイル名が示される。

【0088】

「分類識別子」の項目には、直近に実行されたＳ３０２の処理により取得した分類識別子が示される。

【0089】

「ルール番号」の項目には、直近に実行されたＳ３０５の処理によりunsafe記述ルール１０から取得したルールの定義を特定する情報（図６Ｂの例では、取得したルールの定義に対応付けられている「ルールＮｏ．」の情報）が示される。

【0090】

「行番号」の項目には、直近に実行されたＳ３０４の処理により取得した記述についての、ソースファイル４０における記述位置を特定する行番号が示される。

【0091】

Ｓ３０８及びＳ３０９の処理では、違反リストと許可リストとのそれぞれに対して、上述した各行の情報が、出力部１０４によって格納される。

【0092】

次に、図１０ＢのＳ３１０では、unsafe記述ルール１０に含まれているルールの定義をＳ３０５の処理によって全て取得したか否かを判定する処理が判定部１０３により行われる。この判定処理において、ルールの定義を全て取得したと判定したとき（判定結果がＹＥＳのとき）にはＳ３１１に処理を進める。一方、この判定処理において、未取得のルールの定義が残されていると判定したとき（判定結果がＮＯのとき）にはＳ３０５に処理を戻して、未取得のルールの定義を１つ取得する処理が判定部１０３により行われ、その後、Ｓ３０６以降の処理が改めて行われる。

【0093】

Ｓ３１１では、直近に実行されたＳ３０３の処理により抽出されたブロック内の記述をＳ３０４の処理によって全て取得したか否かを判定する処理が判定部１０３により行われる。この判定処理において、当該ブロック内の記述を全て取得したと判定したとき（判定結果がＹＥＳのとき）にはＳ３１２に処理を進める。一方、この判定処理において、未取得の記述が当該ブロック内に残されていると判定したとき（判定結果がＮＯのとき）にはＳ３０４に処理を戻して、未取得の記述を１行取得する処理が判定部１０３により行われ、その後、Ｓ３０５以降の処理が改めて行われる。

【0094】

Ｓ３１２では、直近に実行されたＳ３０１の処理により取得されたソースファイル４０に格納されているソースコードから、unsafeを宣言したブロックを、Ｓ３０３の処理によって全て抽出したか否かを判定する処理が抽出部１０２により行われる。この判定処理において、当該ブロックを全て抽出したと判定したとき（判定結果がＹＥＳのとき）にはＳ３１３に処理を進める。一方、この判定処理において、未抽出の記述が当該ブロック内に残されていると判定したとき（判定結果がＮＯのとき）にはＳ３０３に処理を戻して、未抽出の当該ブロックを１つ抽出する処理が抽出部１０２により行われる。そして、その後はＳ３０４以降の処理が改めて行われる。

【0095】

Ｓ３１３では、Ｓ３０１の処理によりソースファイル４０を全て取得したか否かを判定する処理が抽出部１０２により行われる。この判定処理において、ソースファイル４０を全て取得したと判定したとき（判定結果がＹＥＳのとき）には、このソフトウェア開発支援処理を終了する。一方、この判定処理において、未取得のソースファイル４０が残されていると判定したとき（判定結果がＮＯのとき）にはＳ３０１に処理を戻して、未取得のソースファイル４０を１つ取得する処理が抽出部１０２により行われる。そして、その後はＳ３０２以降の処理が改めて行われる。

【0096】

以上までの処理がソフトウェア開発支援処理である。

【0097】

次に、図３に手順を示したルールチェックにおけるＳ２０３の手順である、プログラムの修正のより詳細な手順について、図１３を用いて説明する。図１３は、プログラム修正手順の一例を示した図である。

【0098】

この手順は、ソフトウェア開発支援装置１００による前述したソフトウェア開発支援処理の実行が終了すると開始され、まず、図１１に例示した、ソフトウェア開発支援装置１００により作成された違反リストの取得が行われる（Ｓ４０１）。そして、unsafe記述ルール１０において不許可とされている記述である、記述ルールに違反する記述があったかどうかが判定され（Ｓ４０２）、違反する記述がなかった場合（Ｓ４０２がＮＯの場合）、このプログラム修正手順が終了する。

【0099】

一方、記述ルールに違反する記述があり、当該記述に関する情報が違反リストに示されている場合（Ｓ４０２がＹＥＳの場合）、当該情報によって特定されるソースファイル４０の違反箇所の修正作業が行われる（Ｓ４０３）。

【0100】

その後、Rust言語のコンパイラがＰＣ上で実行されて、違反箇所の修正作業が完了したソースファイル４０のコンパイルが行われる（Ｓ４０４）。

【0101】

このプログラムのコンパイルにおいて、エラーが検出されたかどうかが判定される（Ｓ４０５）。ここで、エラーが検出された場合（Ｓ４０５がＹＥＳの場合）、当該エラーを解消するためのプログラムの再修正がプログラマにより行われ（Ｓ４０６）、その後、Ｓ４０４の手順に戻り、修正後のプログラムに対するコンパイル以降の手順が改めて行われる。

【0102】

一方、プログラムのコンパイルにおいてエラーが検出されなかった場合（Ｓ４０５がＮＯの場合）、当該プログラムにおいて、unsafeを宣言したブロック内の記述が記述ルールに従っているかどうかが再判定される（Ｓ４０７）。この再判定では、ソフトウェア開発支援装置１００に当該プログラムのソースファイル４０を入力して、前述したソフトウェア開発支援処理を行わせる。その後、この処理の結果を用いて、上述したＳ４０１以降の手順が繰り返される。

【0103】

図１３に示した手順によるプログラムの修正は、以上のようにして行われる。

【0104】

以上までに説明した実施形態では、unsafe宣言ブロック内の記述において許容する記述ルールを予め定義しておき、ソフトウェア開発支援装置１００が、この記述ルールに従って、Rust言語により記述されたプログラムのソースコードのチェックを行う。そして、このチェックによってルール違反が検出された場合に、当該違反を解消する修正をプログラマが行う。従って、この実施形態によれば、メモリ安全性の保証のためのプログラマによる作業の負担が軽減される。

【0105】

以上、開示の実施形態とその利点について詳しく説明したが、当業者は、特許請求の範囲に明確に記載した本発明の範囲から逸脱することなく、様々な変更、追加、省略をすることができるであろう。

【0106】

例えば、図４に例示したソフトウェア分類定義２０は、ソフトウェアの階層構造に従って分類を定義しているが、ソフトウェアの階層構造の階層数は、図５に示した３つの階層でなくてもよい。

【符号の説明】

【0107】

１０ unsafe記述ルール
２０ ソフトウェア分類定義
３０ unsafe記述ルール定義
４０ ソースファイル
５０ ソースファイル分類リスト
６０ 判定結果リスト
７０ 情報処理装置
７１ ＣＰＵ
７２ メモリ
７３ 入力装置
７４ 表示装置
７５ 補助記憶装置
７６ 通信Ｉ／Ｆ
７７ 内部バス
１００ ソフトウェア開発支援装置
１０１ 記憶部
１０２ 抽出部
１０３ 判定部
１０４ 出力部

【図1A】

【図1B】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図7】

【図8】

【図9】

【図10A】

【図10B】

【図11】

【図12】

【図13】