3

相互に依存する多数の関数を含むライブラリがあるとします。このライブラリは大きすぎるため、分割したいと考えています。適切なパーティションを見つけるためのアルゴリズムは何ですか?

簡単な例では、アルファ、ベータ、ガンマ、デルタの 4 つの関数があります。

  • beta と gamma は両方とも delta を呼び出します。
  • module1 は alpha と beta を呼び出します。
  • module2 はガンマを呼び出します。
  • module3 は、alpha、beta、および gamma を呼び出します。

アルゴリズムの出力は次のようになります。

  • LibA には (アルファ、ベータ) が含まれています
  • LibB には (ガンマ) が含まれています
  • LibC には (デルタ) が含まれています
  • module1 は LibA に依存します
  • module2 は LibB に依存します
  • module3 は LibA と LibB に依存します
  • LibA は LibC に依存します
  • LibB は LibC に依存します

つまり、次のプロパティを持つ最もきめ細かい Lib* パーティションを見つけます。

すべての X について、LibX が何らかの方法で LibY と LibZ に分割されている場合、LibY に依存するすべてのモジュール/ライブラリも LibZ に依存し、その逆も同様です。

これに対する標準的な解決策はありますか？

4

1 に答える 1

1

(これは、C および C++ プログラムのヘッダー ファイルで発生するのと同じ種類の問題です。)

依存関係を作成するのは「呼び出し」だけではありません。メンバー変数、静的変数、さらには定数定義へのあらゆる種類の参照です。

基本的に必要なことは、すべての細かい依存関係を発見することです (これには通常、コードを読み取り、宣言された言語要素 (宣言、フィールド、メソッド、クラス、パッケージなど) 間の依存関係を発見するコンパイラのような分析ツールが必要です。 Java 中心など) と他の言語要素. ライブラリが記述されている言語のセマンティクスを使用. (このような分析はおそらく保守的です). これは本質的に、ノードが言語要素である巨大なグラフを提供します.アークは「用途」です。

抽象的なライブラリのパッケージングの問題は、このグラフをチャンクに分割し、チャンク間の依存アークを最小限に抑えます。これにより、膨大な数の小さなライブラリが得られる場合があります。

実際の問題は、実際には相互に依存していないが、一般的に一緒に使用されるいくつかのチャンクをグループ化することです。たとえば、一連のバッファ アクセス プロシージャは、デフォルトのバッファ サイズの定義に明示的に依存していない場合がありますが、デフォルトのバッファ サイズ宣言のみを含む 2 つのライブラリではなく、両方を含む 1 つのライブラリが必要になる場合があります。一緒に使用されるというこの概念は、実際には問題領域のアーティファクトであり、使用の統計的な同時発生を除いて、コードのどこにも表示されません。

この問題の難しい部分は、細粒度のセマンティック依存関係を発見することです。これは手で概算できますが、問題にスケールがある場合は、それを実行する意欲がありません。(人々は同じ理由でヘッダーファイルを再編成しません)。分析を行うための言語ツール、チャンクを提案するための大きなグラフ管理、ヒューリスティックなグループ化を取得するための統計分析、そしておそらくドメインの専門家がグループ化を編集して改訂されたライブラリを生成できるようにする UI が必要です。

次に、従来のライブラリを使用するコードに戻り、改訂されたライブラリを使用するように変更するためのツールが必要です。ライブラリのリファクタリングとコード ベースのリビジョンの両方で、自動化が必要な大規模なコード分析と変更が必要です。

多くの言語フロント エンドを備えたDMS ソフトウェア リエンジニアリング ツールキットは、おそらく、このようなライブラリの再編成を実装するための優れた基盤となります。私たちは C と C++ でこれを行うことを検討しましたが [これが私がこの回答を持っている理由です]、私たちにとっても大きな仕事です。深刻な追加のモチベーションが欲しいです!.

于 2011-11-30T16:47:39.570 に答える