Loading article…
ソフトウェア考古学またはソースコード考古学は、ソフトウェア保守の一環として、文書化が不十分または文書化されていないレガシーソフトウェア実装を研究する学問です。[1] [2]考古学との類似性から名付けられたソフトウェア考古学には、[3]ソフトウェアモジュールのリバースエンジニアリング、およびプログラム構造の抽出と理解、設計情報の回復のためのさまざまなツールとプロセスの適用が含まれます。 [1] [4]ソフトウェア考古学では、設計が不十分なソフトウェアモジュールや未使用のソフトウェアモジュールを生み出した機能不全のチームプロセスが明らかになる場合があり、場合によっては意図的に難読化されたコードが見つかることもあります。[5]この用語は何十年も使用されています。[6]
ソフトウェア考古学は、最近のソフトウェアエンジニアリング会議でも議論の話題となり続けています。[7]
テクニック
2001年のOOPSLA（オブジェクト指向プログラミング、システム、言語、アプリケーション）会議でのソフトウェア考古学に関するワークショップでは、次のようなソフトウェア考古学の手法が特定されましたが、その一部はオブジェクト指向プログラミングに特有のものです。[8]
- 静的レポートの作成と診断出力のフィルタリングのためのスクリプト言語
- HTML ページまたは Wiki での継続的なドキュメント
- 総観シグネチャ分析、統計分析、ソフトウェア視覚化ツール
- リバースエンジニアリングツール
- trussまたはstraceによるオペレーティング システム レベルのトレース
- ソースファイル内のキーワードを検索するための検索エンジンとツール
- IDEファイルブラウジング
- JUnitやCppUnitなどのユニットテストフレームワーク
- Javadocやdoxygenなどのツールを使用したAPIドキュメントの生成
- デバッガー
より一般的には、アンディ・ハントとデイブ・トーマスは、バージョン管理、依存関係管理、GLIMPSEやSWISH-Eなどのテキスト索引ツール、そして「探索を始めるときに地図を描くこと」の重要性を指摘しています。[8]
真の考古学と同様に、ソフトウェア考古学には先人の思考プロセスを理解するための調査作業が含まれます。[8] OOPSLA ワークショップで、Ward Cunningham は、セミコロンや中括弧などの句読点のみを表示することでプログラムの全体的な「感触」を伝えるシノプティック シグネチャ分析手法を提案しました。[9]同様に、Cunningham は、全体的な構造を理解するために 2 ポイント フォントでプログラムを表示することを提案しました。[10]ワークショップで特定されたもう 1 つの手法は、 AspectJなどのアスペクト指向プログラミングツールを使用して、レガシー プログラムを直接編集せずにトレースコードを体系的に導入することでした。[8]
ネットワークと時間分析技術は、レガシーソフトウェアの開発者による共同作業のパターンを明らかにし、その結果、作成されたソフトウェア成果物の長所と短所を明らかにすることができます。[11]
エンバカデロ・テクノロジーズ のマイケル・ロズログは、ソフトウェア考古学を、プログラマーが「今何を引き継いだのか？」や「コードの恐ろしい部分はどこにあるか？」といった質問に答えることを可能にする6段階のプロセスであると説明している。 [12]これらのステップは、OOPSLAワークショップで特定されたものと同様、視覚化を使用してプログラムの設計を視覚的に表現すること、ソフトウェア・メトリクスを使用して設計およびスタイルの違反を探すこと、ユニット・テストおよびプロファイリングを使用してバグやパフォーマンスのボトルネックを探すこと、プロセスによって回収された設計情報をまとめることなどが含まれる。[12]ソフトウェア考古学は、外部コンサルタントがプログラマーに提供するサービスでもある。[13]
大衆文化では
「プログラマー考古学者」という職業は、ヴァーナー・ヴィンジの1999年のSF小説『A Deepness in the Sky』に大きく取り上げられている。 [14]
参照
参考文献
- ^ ab Robles, Gregorio; Gonzalez-Barahona, Jesus M.; Herraiz, イスラエル (2005). 「ソフトウェア考古学への経験的アプローチ」(PDF)。国際ソフトウェア保守会議のポスター議事録。
- ^ Ambler, Scott W.「Agile Legacy System Analysis and Integration Modeling」。agilemodeling.com。2010-08-20取得。正確なドキュメントや知識のある人へのアクセスが
ない場合、最後の手段はレガシー システムのソース コードを分析することかもしれません... この作業は、ソフトウェア考古学と呼ばれることがよくあります。
- ^ Moyer, Bryon (2009 年 3 月 4 日)。「ソフトウェア考古学: 古いシステムの近代化」(PDF)。Embedded Technology Journal。
- ^ ホプキンス、リチャード、ジェンキンス、ケビン (2008)。「5. 神話のメタマン」IT 象の食いつぶし: グリーンフィールド開発からブラウンフィールド開発への移行。アディソン・ウェズリー。p. 93。ISBN 978-0-13-713012-2。
- ^ Spinellis, Diomidis ; Gousios, Georgios (2009). 「2. 2 つのシステムの物語 § 凝集性の欠如」. Beautiful Architecture . O'Reilly. p. 29. ISBN 978-0-596-51798-4。
- ^ 初期の議論としては、Grass, Judith E. (1992 年冬)「CIA++ によるオブジェクト指向設計考古学」(PDF) . Computing Systems . 5 (1) があります。
- ^ たとえば、「第 32 回 ACM/IEEE 国際ソフトウェア工学会議」。2010 年 5 月。。
- ^ abcd Hunt, Andy ; Thomas, Dave (2002 年 3 月 - 4 月)。 「ソフトウェア考古学」(PDF)。IEEEソフトウェア。19 (2): 20 - 22。doi :10.1109/52.991327。
- ^ Cunningham, Ward (2001)。「Signature Survey: 未知のコードを閲覧する方法」。ワークショップの立場表明、ソフトウェア考古学: 大規模システムの理解、OOPSLA 2001。
- ^ Cook, John D. (2009 年 11 月 10 日). 「ソフトウェア考古学」. The Endeavour .
- ^ de Souza, Cleidson; Froehlich, Jon; Dourish, Paul (2005). 「ソースの探求: 社会的かつ技術的な成果物としてのソフトウェア ソース コード」(PDF)。2005 International ACM SIGGROUP Conference on Supporting Group Work の議事録。pp . 197– 206。doi : 10.1145/1099203.1099239。ISBN 1595932232。
- ^ ab Rozlog, Michael (2008 年 1 月 28 日)。「ソフトウェア考古学: それは何であり、なぜ Java 開発者は気にする必要があるのか?」java.sys-con.com。
- ^ シャーウッド、サイモン (2004 年 11 月 3 日)。「レイダース・オブ・ザ・ロスト・コード」ZDNet。
- ^ Rees, Gareth (2013-06-12). 「ソフトウェア考古学と技術的負債」
外部リンク
- 「ポジションペーパー」。OOPSLA 2001 ソフトウェア考古学ワークショップ: 大規模システムの理解。2010-06-12 にオリジナルからアーカイブ。
- 「コードを書く、コードを読む、そしてソフトウェア考古学」。Once More into the Code。Computerworld。2009年9 月 23 日。2011 年 1 月 29 日のオリジナルからアーカイブ。
- Rozlog, Michael (2008 年 3 月 13 日)。「ソフトウェア考古学を開発プロセスに適用する方法」(PDF)。
- 「OOPSLA 2008 ポッドキャスト、Grady Booch 氏によるソフトウェア考古学と関連トピックについて」(ポッドキャスト)。2008 年。2011 年 9 月 26 日にオリジナルからアーカイブされました。