ロバストネス (コンピュータ)
計算機科学における、ロバストネス (英: robustness)、ロバスト性、堅牢性とは、コンピュータシステムで実行中のエラー[1][2]や、誤った入力に対処できる能力のこと。 堅牢性には、堅牢なプログラミング、堅牢な機械学習、堅牢なセキュリティネットワークなど、計算機科学の多くの分野が当てはまる。堅牢性を示すためテストでは無効または予期しない入力を行うため、ファズテストなどの手法が不可欠である。または、フォールトインジェクションを行い堅牢性をテストすることもできる。さまざまな商用製品が、ソフトウェア分析の堅牢性テストを実行できる[3]。
概要[編集]
一般に、考えられる入力と入力の組み合わせが膨大な量であるため、考えられる障害のすべてのポイントを網羅する堅牢なシステムを構築することは困難である.[4]。 すべての入力と入力の組み合わせはテストに時間がかかりすぎるため、開発者はすべてのケースを網羅的に実行できない。代わりに、開発者はケースの一般化を試みる[5]。 たとえば、いくつかの整数値を入力する場合、入力は負の数、ゼロ、正の数の場合がある。これらの数値でソフトウェアをテストする場合、開発者はすべての実数のセットを3つの数値に一般化する。これはより効率的で管理しやすい方法だが、失敗することもある。テストケースの一般化は、失敗、具体的には無効なユーザー入力による失敗に対処するための1つの手法の例である。システムは通常、ネットワークからの切断など、他の理由でも失敗する可能性がある。
とにかく、システムが複雑化しても、発生したエラーを適切に処理する必要がある。成功したシステムについての多くの事例がある。最も堅牢なシステムのいくつかは進化させて、新しい状況に簡単に適応させることができる[4]。
課題[編集]
プログラムとソフトウェアは非常に特定のタスクを扱うツールであるため、一般化されておらず、柔軟性がない[4]。 一方、インターネットや生物学的なシステムは環境に適応する。生物学的システムは冗長性で環境に適応している。 人間の多くの臓器は腎臓のように冗長である。人間は腎臓がひとつあれば生きていけるが、腎臓が2つあれば片方が機能しなくなっても生きていける。これと同じ原則をソフトウェアに適用できるが、いくつかの課題がある。冗長性の原則を計算機科学に適用する場合、やみくもにコードを追加することは推奨されない。盲目的にコードを追加すると、エラーが増え、システムが複雑になり、理解しにくくなるからだ[6]。 これにより、機能が壊れた場合でも、手動または自動のソフトウェアダイバーシティを使用して、同じ機能を提供する別のコードで置き換えることができる。そのためには、新しいコードは、障害点に対応する方法とタイミングを知っている必要がある[4]。 これは、システムにロジックの追加が必要であることを意味する。ただし、システムはロジックやコンポーネントを追加し、サイズが大きくなると、より複雑になる。したがって、より冗長なシステムを作成する場合、システムもより複雑になり、開発者は冗長性と複雑さのバランスを検討する必要がある。
現在、計算機科学の実践は、堅牢なシステムの構築に重点を置いていない[4]。むしろ、スケーラビリティと効率に重点を置く傾向がある。今日、堅牢性に重点が置かれていない主な理由の1つは、一般的な方法で行うのが難しいためである[4]。
領域[編集]
堅牢なプログラミング[編集]
堅牢なプログラミングは、予期しない終了と予期しないアクションの処理に焦点を当てたプログラミングのスタイルである[7]。 正確で明確なエラーメッセージを表示することにより、これらの終了とアクションを適切に処理するためのコードが必要である。これらのエラーメッセージにより、ユーザーはプログラムをより簡単にデバッグできる。
原則[編集]
- 攻撃性の想定
- ソフトウェアを構築するとき、プログラマーはユーザーがコードを壊そうとしていると想定する[7]。 プログラマーはまた、自分で書いたコードが失敗したり、正しく機能しなかったりする可能性があると想定する。
- 誤りの想定
- プログラマーは、ユーザーが誤った、偽の、不正な形式の入力を試みると想定する[7]。 結果として、プログラマーは、エラーコードを検索する必要のない明確で直感的なエラーメッセージをユーザーに返す。エラーメッセージは、問題を簡単に修正できるように、ユーザーに誤解を与えないようにできるだけ正確にする必要がある。
- 危険な実装の排除
- ユーザーは、ライブラリ、データ構造、またはデータ構造へのポインタにアクセスすべきでない[7]。 ユーザーが誤って情報を変更したり、コードにバグを導入したりしないように、この情報はユーザーから非表示にする必要がある。正しく構築されたインターフェイスの場合、ユーザーに抜け穴を発見されずにユーザーに利用させる。ユーザーはインターフェイスに変更を加える必要はなく、自分のコードだけに集中する。
- 不可能の想定
- 非常に頻繁に、コードが変更され、「不可能な」ケースが発生する可能性がある。したがって、不可能なケースは、代わりに非常にありそうもないと想定する[7]。 開発者は、ありそうもないケースの処理方法を考え、それに応じて処理を実装する。
堅牢な機械学習[編集]
堅牢な機械学習とは、通常、機械学習アルゴリズムの堅牢性を指す。機械学習アルゴリズムが堅牢であるとは、テストエラーがトレーニングエラーと一致しているか、データセットにノイズを追加した後のパフォーマンスが安定しているかのいずれかの状態のことを指す[8]。
堅牢なネットワーク設計[編集]
堅牢なネットワーク設計は、変動するまたは不確実な要求に直面したネットワーク設計の研究である[9]。 ある意味で、ネットワーク設計の堅牢性は、変更や入力の可能性が非常に大きいため、ソフトウェア設計の堅牢性と同じように幅広い対策が必要となる。
堅牢なアルゴリズム[編集]
入力[10]や計算中のエラーを許容するアルゴリズムがある[11]。 その場合、計算は最終的に正しい出力に収束する。この現象は「correctness attraction」と呼ばれる[11]。
脚注[編集]
- ^ “A Model-Based Approach for Robustness Testing”. Dl.ifip.org. 2016年11月13日閲覧。
- ^ 1990. IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 610.12-1990 defines robustness as "The degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions"
- ^ Baker, Jack W.; Schubert, Matthias; Faber, Michael H. (2008). “On the assessment of robustness”. Structural Safety 30 (3): 253–267. doi:10.1016/j.strusafe.2006.11.004 2016年11月13日閲覧。.
- ^ a b c d e f Gerald Jay Sussman (2007年1月13日). “Building Robust Systems an essay”. Groups.csail.mit.edu. 2016年11月13日閲覧。
- ^ Joseph, Joby (2009年9月21日). “Importance of Making Generalized Testcases - Software Testing Club - An Online Software Testing Community”. Software Testing Club. 2016年11月13日閲覧。
- ^ Agents on the wEb : Robust Software. “Building Robust Systems an essay”. Cse.sc.edu. 2016年11月13日閲覧。
- ^ a b c d e “Robust Programming”. Nob.cs.ucdavis.edu. 2016年11月13日閲覧。
- ^ El Sayed Mahmoud. “What is the definition of the robustness of a machine learning algorithm?”. 2016年11月13日閲覧。
- ^ “Robust Network Design”. Math.mit.edu. 2016年11月13日閲覧。
- ^ Carbin, Michael; Rinard, Martin C. (12 July 2010). “Automatically identifying critical input regions and code in applications”. Proceedings of the 19th international symposium on Software testing and analysis - ISSTA '10. ACM. pp. 37–48. doi:10.1145/1831708.1831713. ISBN 9781605588230
- ^ a b Danglot, Benjamin; Preux, Philippe; Baudry, Benoit; Monperrus, Martin (21 December 2017). “Correctness attraction: a study of stability of software behavior under runtime perturbation”. Empirical Software Engineering 23 (4): 2086–2119. arXiv:1611.09187. doi:10.1007/s10664-017-9571-8.