ネットワーク経由で組み込みソフトのバグを修正する　――後からモジュールを追加できるITRON仕様OSの開発

3）バージョン依存関係

　本開発の方針として，バージョンアップした際，下位バージョンで実装したインターフェース機能のすべてを上位バージョンでも互換性を保って実装するものとしました．またバージョンアップにあたっては，ブランチ（一つのバージョンから複数のバージョンが派生すること）は認めないものとしました．これはパソコン・アプリケーション開発者がダイナミック・ローダブル・モジュール（いわゆるDLLなど）のバージョン不整合から発生する不ぐあいに日々悩まされていることを考慮して，なるべくシンプルな仕様にして対応したかったからです^注5．

　なお，本開発ではロード・モジュール間の依存関係については考慮せず，ユーザ責任（ロード・モジュール初期化処理責任）という立場をとっています．これは本開発でこの問題をOS機能側で解決するには，考慮すべき問題のバリエーションが多く，一般解が見つからなかったためです．本開発ではベース・モジュールとロード・モジュールの間のバージョン整合性のみを考慮した開発を行い（図12），その依存関係を管理する手法を保守管理者に提供しています．

　具体的にはロード・モジュールのエントリをサーバのロード・モジュール管理データベースに登録する際に，動作可能なベース・モジュールのバージョン番号の範囲を登録できる仕様としています．

 注5；パソコンでDLLをバージョンアップしたとたん，アプリケーション・ソフトウェアが動作しなくなった経験はないだろうか？ ユーザの立場から見ても困った問題だが，開発者にとっても，バージョンの不整合から発生する障害に対処し続けなくてはならないのは，まさに地獄の日々だろう．

〔図12〕ベース・モジュールとロード・モジュールのバージョン依存関係
破線の矢印は，ロード・モジュールに対するベース・モジュールの依存関係を表している．例えば，左端の矢印は「ロード・モジュールVer1.00はベース・モジュールVer1.00以降で動作可能である」ということを意味する．この依存関係の矢印が交差することはありえない（すなわち，上図ではロード・モジュールVer1.02がベース・モジュールVer1.01で動作することはありえない）．