航空管制を支える巨大コードをどうシンプルにするか──MITによるモダナイゼーション事例
今回紹介するのは実際の航空管制システムのモダナイゼーションの事例報告で、2000年に IEEE Software 誌に掲載されたものです。既に20年以上が経過していますが、古いからこそ価値のある教訓が得られる論文です。テクノロジーの進歩を経ても変わらない、ソフトウェアエンジニアリングの基本テクニックの価値を明らかにしてくれる内容だからです。
論文の背景とプロジェクト概要
この論文の著者は二人ともマサチューセッツ工科大学(MIT)のコンピューターサイエンス研究所(現在はコンピューターサイエンス・人工知能研究所)に所属する研究者で、Daniel Jacksonは教授、John Chapinは助教です(所属や肩書は掲載当時のもの)。
この論文が掲載された2000年ごろのソフトウェアエンジニアリング界隈では、新しい技術やパラダイムが次々に登場していました。主要な動きは以下のとおりです:
- 1995年:Windows95の登場、デザインパターン
- 1997年:単体テスト、JUnit
- 1999年:エクストリームプログラミング(XP)
- 2001年:アジャイルソフトウェア開発宣言
- 2002年:テスト駆動開発(TDD)
開発プロセスの革新がソフトウェアの品質向上を実現する、という熱気に業界が包まれる中、著者らはテクノロジーが相対的に軽視されているように感じました。
ソフトウェア設計の段階で設計仕様の自動検証技術やコード解析技術の研究に従事していた著者らは、こうしたソフトウェア開発支援技術の重要性を示すための事例研究に乗り出します。
事例:CTAS(Center/TRACON Automation System)
事例研究の題材となったのは、アメリカ航空宇宙局(NASA)が開発し、アメリカ連邦航空局(FAA)が米国内の空港へのデプロイを進めていた航空管制システム「Center/TRACON Automation System」、通称 CTAS でした。
MITの教員である著者らは、CTASのモダナイゼーションに、大学院における1学期間(セメスター、約4か月)のプロジェクトとして、12名の大学院生とともに取り組みました。(もう1名の教員もプロジェクトに参加していました。)
成果:大規模C++システムのJava化による簡素化
プロジェクトでは、CTASのコア機能を担うモジュール(コミュニケーションズマネージャ、以下 CM )の仕様とコードを分析し、同等機能を設計しなおしました。
既存のCMは約 8万行 のC++コードで書かれていましたが、それを約 1万5千行 のJavaコードで再実装し、システムを劇的にシンプル化することに成功しました。
(C++コードの約4分の1はコメントでした。)
基本テクニックの力:高度な技術に頼らず得られた成果
このモダナイゼーションプロジェクトは、リバースエンジニアリング技術や仕様検証技術の効果を示すためのものでしたが、得られた結果は想定と大きく異なっていました。
コンピューターサイエンスや情報工学など、大学のソフトウェア系の学科で普通に教えられているような ソフトウェアエンジニアリングの基本テクニック を適用するだけで大きな成果が得られたため、仕様検証などの高度な技術は適用せずじまいになったのです。
リバースエンジニアリングツールは複数を適用しただけでなく、プロジェクトでも自作するなどして、大きな効果を挙げました。
著者らが言う「ソフトウェアエンジニアリングの基本テクニック」とは、以下のようなものでした:
- 凝集度・結合度を意識したモジュール設計
- 仕様化、ドキュメント化
- データ抽象、情報隠蔽
プロジェクトの対象となったCTASは、米国の航空輸送を支える ミッションクリティカルシステム です。
CTASの導入によって空港近辺の航空機管制が効率化され、たとえば ダラス空港では航空便の着陸数を10%増加 させることに成功しました。決して、大学の教材用の「トイプロジェクト」(学習用に設計された簡易なプロジェクト)ではないのです。
こうしたミッションクリティカルな実システムですが、ソフトウェアの内部構造には様々な問題を抱えていました。そして、それらの問題は、ソフトウェアエンジニアリングの基本をしっかり押さえた設計と実装 によって対応できるものでした。
これは、ソフトウェア開発における「基本の大切さ」を示す、非常に重要な示唆だと思います。
既存システムの問題点
ソフトウェア開発の現場は、さまざまな方向からのプレッシャーにさらされています。CTASのように、求められた機能を満たすシステムを正しく動作させる ことはひとつの成功です。
しかし、内部構造が不必要に複雑化・肥大化 していると、その後の保守や拡張のフェーズで大きな代償を払うことになります。
いわゆる、技術的負債 です。
今回のモダナイゼーションの対象となった CM(コミュニケーションズマネージャ) は、CTASの各種コンポーネントの中心に位置し、
- コンポーネント間通信
- データベース操作
- コンポーネントの実行制御
といった役割を担うモジュールでした。
本来であれば別の場所に配置すべき機能が「とりあえずCMに入れられる」ことが繰り返され、仕様が複雑化・肥大化 していきました。
CMは他のコンポーネントを起動するなどの実行制御を担う重要なモジュールでしたが、CM自体のコントロールフローは暗黙的で、理解しにくい構造になっていました。
また、コンポーネント間通信にはブロッキング型のプリミティブが使用されており、デッドロックのリスクが存在しました。
その回避のためのロジックがあちこちに実装され、さらに理解困難なコードになっていたのです。
さらに、**ミッションクリティカルシステムであるにもかかわらず、CMはSPOF(Single Point of Failure)**にもなっていました。
FAAは空港管制に関する新たな監視機能を望んでおり、それらをCMに搭載したいと考えていました。
しかし、既存仕様ではそれが困難でした。なぜなら、修正の影響分析に膨大なコストがかかることが明らかだったからです。
ドキュメントの面でも、マニュアル等を含めて数百ページにおよぶ資料が整備されており、個々のコンポーネントの動作などはしっかり記述されていました。
しかし、モダナイゼーションプロジェクトのメンバーにとって最も必要な情報が欠けており、それらを求めて大量のコードを読み解く必要がありました。
ドキュメントに記載すべきだった最重要情報(欠けていたもの)
- システムとして何を入力し、何を出力しているのか
- 各コンポーネントの仕様、およびコンポーネント間の関係
- システムの外部環境に関する想定事項
得られた教訓
著者らは、本プロジェクトで得られた教訓を以下のようにまとめています。
-
大規模で複雑なシステムを劇的にシンプル化することは本当に可能である
-
ソフトウェアエンジニアリングの基本テクニックの価値はもっと認識されるべき
-
コーディング規約は、コード読解だけでなく、ツールによるコード解析のためにも重要
CTASの場合、NASAによる厳格なコーディング規約が運用されており、モダナイゼーションプロジェクトはそれにかなり助けられたとのことです。
-
コード解析などリバースエンジニアリングは効果がある
-
システムを概観するようなモデル(high-level models)は極めて重要
「木を見て森を見ず」という言葉がありますが、CTASの既存ドキュメントは「木」にフォーカスするものが多く、「森」を語るものが欠如していました。
これはCTASに限らず、多くの現場にもあてはまる問題であると、著者らは警鐘を鳴らしています。
さらに著者らは、カーネギーメロン大学のMahadev (Satya) Satyanarayanan の言葉を引用しています:
「システムが肥大化し内部構造が劣化していくのは、システムへの投資が不十分であることを示している」
継続的に投資されているシステムは、むしろシンプル化・縮小化していくというのです。
今回のプロジェクトでは実際に、既存のミッションクリティカルシステムのコード規模を劇的に縮小し、内部構造をシンプル化することに成功しました。
その結果、保守性や拡張性も大きく向上しました。
これはまさに、ソフトウェアエンジニアリングの基本テクニックの重要性を示す、説得力ある成果といえるでしょう。
紹介した論文
- D. Jackson and J. Chapin, “Redesigning air traffic control: an exercise in software design,” IEEE Software, vol. 17, no. 3, pp. 63–70, May–June 2000.
doi: 10.1109/52.896251
なお、原著論文ではCTASの再設計の取り組みを 「redesign(リデザイン、再デザイン)」 と呼んでいます。
私自身も「リデザイン」という言葉がもっともしっくりくると感じていますが、日本国内ではまだ「設計」と「デザイン」は別物として捉えられる傾向が強いようです。
こうした事情も踏まえ、今回の記事では「既存システムを見直し、再設計・再実装する」という取り組みを、あえて 「モダナイゼーション」 と表現しています。
参考文献
- 田中ひさてる著『ちょうぜつソフトウェア設計入門』技術評論社、2022年
※2000年ごろのソフトウェアエンジニアリングの状況について参考にしました。
Discussion