今回は2000年にIEEE Software誌に掲載された、実際の航空管制システムのモダナイゼーションの事例報告です。掲載から20年以上が経過していますが、古いからこそ価値のある教訓が得られる論文です。テクノロジーの進歩を経ても変わらない、ソフトウェアエンジニアリングの基本テクニックの価値を明らかにしてくれる内容だからです。
研究者たちによる実システムのモダナイゼーション
この論文の著者は二人ともマサチューセッツ工科大学（MIT）のコンピューターサイエンス研究所（現コンピューターサイエンス・人工知能研究所）に所属する研究者で、Daniel Jacksonは教授、John Chapibnは助教です（所属や肩書は掲載当時のもの）。
この論文が掲載された2000年ごろのソフトウェアエンジニアリング界隈では、新しい技術やパラダイムが次々に登場していました。主要な動きは以下のとおりです：
- 1995年：Windows95の登場、デザインパターン
- 1997年：単体テスト、JUnit
- 1999年：エクストリームプログラミング（XP）
- 2001年：アジャイルソフトウェア開発宣言
- 2002年：テスト駆動開発
開発プロセスの革新がソフトウェアの品質向上を実現する、という熱気に業界が包まれる中、著者らはテクノロジーが相対的に軽視されているように感じました。ソフトウェア設計の段階で設計仕様の自動検証技術やコード解析技術の研究に従事していた著者らは、こうしたソフトウェア開発支援技術の重要性を示すための事例研究に乗り出します。
事例研究の題材となったのは、アメリカ航空宇宙局（NASA）が開発しアメリカ連邦航空局（FAA）が米国内の空港へのデプロイを進めていた航空管制システム「Center/TRACON Automation System」、通称CTASでした。MITの教員である著者らは、CTASのモダナイゼーションに、大学院における1学期間（セメスター、4か月）のプロジェクトとして、12名の大学院生とともに取り組んだのです。（もう1名の教員もプロジェクトに参加していました。）
プロジェクトでは、CTASのコア機能を担うモジュール（コミュニケーションズマネージャ、以下CM）の仕様とコードを分析し、同等機能を設計しなおしました。既存のCMは約8万行のC++コードで書かれていましたが、それを1万5千行のJavaコードで実装しなおすことで、システムを劇的にシンプル化することに成功したのです。（C++コードの約4分の1はコメントでした。）
ソフトウェアエンジニアリングの基本テクニック
このモダナイゼーションプロジェクトは、リバースエンジニアリング技術や仕様検証技術の効果を示すためのものでしたが、得られた結果は想定と大きく異なっていました。コンピューターサイエンスや情報工学など大学のソフトウェア系の学科で普通に教えられているような、ソフトウェアエンジニアリングの基本テクニックを適用するだけで大きな成果が得られてしまい、仕様検証など高度な技術は適用せずじまいになったのです。（リバースエンジニアリングツールは複数を適用しただけでなく、プロジェクトでも自作するなどして、大きな効果を挙げました。）
著者らが言うソフトウェアエンジニアリングの基本テクニックとは以下のようなものでした：
- 凝集度、結合度を意識したモジュール設計
- 仕様化、ドキュメント化
- データ抽象、情報隠蔽
プロジェクトの対象となったCTASは、米国の航空輸送を支えるミッションクリティカルシステムです。CTASの導入によって空港近辺の航空機管制が効率化し、ダラス空港では航空便の着陸数を10%増加させることに成功しました。決して、大学の教材用のトイプロジェクト（おもちゃのような規模のプロジェクト）ではないのです。
こうしたミッションクリティカルな実システムですが、ソフトウェアの内部構造には様々な問題を抱えていました。そして、それらの問題は、ソフトウェアエンジニアリングの基本をしっかり押さえた設計と実装によって対応できるものだったのです。ソフトウェア開発における「基本の大切さ」を示す重要な示唆だと思います。
既存システムの問題点
ソフトウェア開発の現場は様々な方向からのプレッシャーにさらされています。CTASのように、求められた機能を充足するシステムをきちんと動作させることは成功でしょう。しかし内部構造が不必要に複雑化・肥大化していると、その後の保守フェーズや拡張フェーズで大きな代償を払うことになります。（技術的負債となっている、ということです。）
今回のモダナイゼーションの対象となったCMは、CTASの各種コンポーネントの中心に位置し、コンポーネント間通信、データベース、コンポーネント実行制御まで担うモジュールでした。どこに配置すべきかわからない機能がとりあえず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,” in IEEE Software, vol. 17, no. 3, pp. 63-70, May-June 2000, doi: 10.1109/52.896251.
なお、原著論文ではCTASの再設計の取り組みを「redesign（リデザイン、再デザイン）」と呼んでいます。筆者もリデザインがもっともしっくりくると思っていますが、日本国内ではまだ「設計」と「デザイン」は別物という捉え方が多いようです。
なので今回記事では「既存システムを見直し、再設計・再実装する」という取り組みを「モダナイゼーション」と表現しています。
参考文献
- 2000年ごろのソフトウェアエンジニアリングの状況については、田中ひさてる著「ちょうぜつソフトウェア設計入門」（技術評論社、2022年）を参考にしました。
コメント