C/C++ システムのアーキテクチャ管理 Whitepaper October 2007 (Revised October 2008) Original Version Copyright 2007-8 Lattix, Inc. All rights reserved Japanese Version 2009 TechMatrix Corporation C/C++ システムのアーキテクチャ管理 - C/C++ アプリケーションのための Lattix DSM C/C++ アプリケーションのための Lattix DSM はじめに Lattix 社は、さまざまな言語とシステムについて、他に先駆けて DSM の使用を進めてきました。C/C++ をサポートすることは、C/C++ という言語に特有の複雑さがあるため、特に困難です。プリプロセッサとヘッダーファイルの使用、そして C/C++ の全般的な複雑さが、アプリケーションアーキテクチャの本質を捉えることを困難にしています。Lattix 社は迅速で非常にスケーラブルな C/C++ ソリューションを提供します。 Lattix DSM についての基本事項標準的な C/C++ プロジェクトは、ソースファイルとインクルードファイルから構成されます。一般的にソースファイルは cpp または c というファイルタイプで示され、インクルードファイルは hpp または h というファイルタイプで示されます。ソースファイル間の依存関係の解析には、各ソースファイル中のシンボルを見て関係を確立することが必要です。たとえば、File1 中のあるメソッドが File2 中のあるメソッドを呼び出す場合、Lattix はメソッドの名前を記録するほか、メソッドがどこで定義されているのか、そしてどこから呼び出されているかを記録して関係を確立します。ヘッダーファイルへの依存は通常、インクルード依存関係を使って確立されます。ただし、他にもいくつか考慮される依存関係があります。たとえばクラス (および構造体) は、しばしばヘッダーファイルで定義され、ソースファイルによって参照されます。また、ヘッダーファイル中のシンボルを見てヘッダーファイルとソースファイルとの関係を確立することも可能です。ただし、この関係の確立はデフォルトでオフになっています。マクロも解析します。展開後のマクロが依存解析対象のソースファイルの一部と見なされます。大規模なシステムは、何百万ものシンボルを持つことがありますが、Lattix は全てのシンボルをチェックします。そして、各シンボルがどこで定義されているか、どこで参照されているかを特定します。この情報に基づいて、さまざまな要素間の関係が確立した DSM が生成されます。デフォルトの DSM はファイル間の依存関係を示しますが、メンバレベルが有効な場合、ファイル中のメンバ (メソッドおよびグローバル変数) の依存関係も示されます。重要な注意事項: 1. 複数の実行モジュールについて 1 つの DSM を作成する場合: 1 つのシンボルについて複数の定義が存在する場合、シンボルの参照を正しい定義に結び付けるのは不可能です。通常、リンカーは複数定義されたシンボルを防ごうとします。しかし、一緒にリンクされない異なるソースファイルが、重複する名前のメソッドあるいはグローバルデータを持つことを防ぐのは不可能です。したがって、まずビルド環境を理解し、重複シンボルを持たないファイルだけをロードす Page 2/8 Copyright 2007-8 Lattix, Inc. All rights reserved C/C++ システムのアーキテクチャ管理 - C/C++ アプリケーションのための Lattix DSM ることが非常に重要です。 2. 異なるアーキテクチャを 1 つの DSM にロードしないようにする: C/C++ プログラムが複数のハードウェアプラットフォームに対して作成されていることがあります。しかし、異なるアーキテクチャのための異なるマシン依存ファイルが、同じメソッドとグローバル変数を持つことがあります。この場合、重複シンボル定義が発生します。 3. 重複ヘッダーファイルを使用しないようにする: 重複ヘッダーファイルがある場合、ヘッダーファイルへの依存関係が、正しいヘッダーファイルへのものではないことがあります。Lattix は include ディレクティブを利用して、正しいインクルードファイルを判別します。ただし、「ビルドプロセスがコンパイル前にファイルまたはディレクトリの名前を変更している」あるいは「ビルドプロセスがファイル/ディレクトリを移動している」といった理由から、include ディレクティブの情報が不正確な場合、正しくない依存関係が表示されることがあります。 4. マクロ定義を正しく処理する: 一部のマクロはコンパイル時引数として設定されることがあります。そのようなマクロがメソッドシグニチャを変更する場合、一部の依存関係が表示されなかったり、不正確な依存関係が表示されることすらあります。Understand for C++ を使用すると、Understand データベースを生成する前にマクロを定義することができます。Understand から udb を生成する前に、マクロを指定してください。効果的に Lattix を使用するには、ビルド環境をよく理解している必要があります。上記の項目に従っていても問題が発生している場合は、Lattix 社までお問い合わせください。Lattix 社は、これまでに何百ものプロジェクトを検証した経験があり、アーキテクチャの理解とリファクタに役立つ情報を抽出することに常に成功しています。 Page 3/8 Copyright 2007-8 Lattix, Inc. All rights reserved C/C++ システムのアーキテクチャ管理 - Lattix プロジェクトの作成: 2 段階のプロセス Lattix プロジェクトの作成: 2 段階のプロセス Lattix は、2 段階のプロセスによって C/C++ をサポートします。1 番目の段階では、コードをパースしてパース結果を生成します。生成されたパース結果は Lattix LDM にロードすることができます。 1 番目の段階 (3 種類のパース方法) Lattix LDM にロードできる依存関係情報は、次の 3 種類の方法で生成することができます。本ホワイトペーパーは 1 つ目の方法を使用することを想定しています。方法 1 - Ｕｎｄｅｒｓｔａｎｄデータベースを使用する一般に広く使用されている商用プログラムである Scitools 社の Understand for C++ を使って Understand データベースを生成します。Understand データベースは udb ファイルに格納され、このファイルは Lattix にロードすることができます (Understand バージョン 1.4 では udc ファイル)。この方法の利点は、Understand for C++ によって生成された正確なデータベースを Lattix LDM に容易にロードできることです。 Understand for C++ は、エラーに対処するよう最適化されたパーサーを使用しているため、データベースは短時間で生成されます。さらに、Understand for C++ は、コンパイルできないコードでさえも適切に処理します。本ホワイトペーパーは Understand データベースをロードすることを想定して説明しますが、 Understand データベースを使用する以外に、次の 2 つの方法もあります。方法 2 - Doxygen が生成したXML ファイルを使用する Doxygen を使って C/C++ ソースコードを処理します。Doxygen はよく知られたオープンソースプログラムであり、自由にダウンロードすることができます。Doxygen は、C/C++ アプリケーションの相互参照付きドキュメントを生成するために使用されます。通常、Doxygen はＨＴＭＬファイルを生成しますが、ＸＭＬファイルを生成するようオプションを設定できます。生成されたＸＭＬファイルは Lattix LDM によって処理されます。ユーザに必要な操作は、index.xml ファイルを指定して Lattix LDM で単純にプロジェクトを新規作成することです。残りのＸＭＬファイルは Lattix が読み込みます。方法 3 - BSC ファイルを使用する BSC ファイルは、Microsoft Visual Studio によって生成されるファイルであり、プロジェクトを構成するさまざまなファイル間の依存関係情報を持ちます。BSC ファイルを生成するには、まず Visual Studio C/C++ コンパイラによってコンパイルされるファイルごとに 1 つの .sbr ファイルを生成します。そして、bscmake を使ってすべての sbr ファイルを結合し、1 つの bsc ファイルを生成します。Lattix LDM には 1 つの BSC ファイルをロードしなければならない点に注意してください。また、別名で同じファイルを参照することを避けるために、一回のビルドで sbr ファイルを生成することを強く推奨します。 Page 4/8 Copyright 2007-8 Lattix, Inc. All rights reserved C/C++ システムのアーキテクチャ管理 - Lattix プロジェクトの作成: 2 段階のプロセス 2 番目の段階 (Lattix プロジェクトの作成) 1 番目の段階で生成したファイルをロードして Lattix プロジェクトを作成します。[新規プロジェクトの作成] ダイアログボックスで適切なモジュールの形式 (C/C++(BSC) 、 C/C++(Doxygen) 、または C/C++(Understand)) を選択し、適切なファイルをロードして Lattix プロジェクトを作成します。オプションの設定プロジェクトを作成する前に設定できるオプションはいくつかあります。その中には、メソッド、グローバル変数、構造体、クラスを見ることができるようメンバレベルを有効にするオプションや、パーティション名の中に絶対パスを表示しないようにするオプションがあります。今のところは、デフォルトオプションを使用してください。オンラインヘルプの『Understand モジュール(C/C++)』には、利用可能なすべてのオプションについての説明があります。ソースコードへのアクセス Understand for C++、Doxygen、BSC モジュールを使用するかどうかに関わらず、サブシステムを選択して右クリックし、[ソースファイルの表示] を選択するだけで、サブシステムのソースコードを参照することができます。ただし、Understand for C++ を使用している場合、[依存関係の詳細] ペインで依存関係を選択して右クリックし、[ソースファイルの表示] を選択することによって、実際の依存関係を参照することができます。依存関係が発生しているコード行にアクセスするには、プロジェクトを作成する前に、行番号の処理オプションを有効にする必要があります。詳細についてはオンラインヘルプの『Understand モジュール(C/C++)』を参照してください。 Page 5/8 Copyright 2007-8 Lattix, Inc. All rights reserved C/C++ システムのアーキテクチャ管理 - Apache Server の解析 Apache Server の解析我々は、初期解析のために Apache Server バージョン 2.0.55 を使用しました。Understand for C++ を使って Apache Server を解析し、生成されたデータベースを Lattix LDM にロードしました。 Understand for C++ プロジェクトをビルドする際、3 つの重要な対策を行いました。 1. 重複するシンボルがプロジェクト内にないことを確認しました。これは、重複するメソッドまたは重複するグローバル変数がプロジェクト中にないことを意味します。通常、一緒にリンクされるものは、曖昧さを無くすことができないシンボルを持ちません。 2. 重複するヘッダーファイルが Understand プロジェクト中にないことも確認しました。Understand GUI ではロードするファイルを明確に選択できることに注意してください。 3. 基本的な API のためのメソッドシグニチャを正しく生成するために、AP_DECLARE_STATIC および AP_DECLARE_STATIC マクロが定義されていることも確認しました。 server に対する modules の依存関係 srclib に対する server の依存関係図 1 : 初期ＤＳＭ初期 DSM は、DSM の行と列にソースコードのディレクトリ構造を示します。DSM 自体はディレクトリ中のファイル間の集約された依存関係を示します。各ディレクトリを展開すると、そのディレクトリ中のファイルまたはディレクトリを表示することができます。 Page 6/8 Copyright 2007-8 Lattix, Inc. All rights reserved C/C++ システムのアーキテクチャ管理 - Apache Server の解析パーティションの再編成は、DSM で実行できる主な変換の 1 つです。DSM パーティショニングアルゴリズムを適用してみましょう (再編成は手動で行うことも可能です)。いくつかのインクルードファイルが os.win32 テスト中のインクルードファイルに依存している server はいくつかの modules に依存している図 2 : パーティショニングされたＤＳＭパーティショニングされた DSM (再編成された DSM) は、興味深い状況を示しています。サブシステム os.win32、modules、server、および include がグループ化されています。このことは、これらのサブシステムが互いに循環的に結合されていることを意味します。また、support がサブシステム中でもっとも上位に配置された一方、srclib はもっとも下位に配置されており、srclib はその上位に位置するすべてのレイヤによって使用されます。非常に興味深いことは、サブシステムが循環的に結合されていても、対角線より上の依存強度が最小になるようサブシステムが編成されていることです。これは多くの場合に設計意図を明らかにします。パーティショニングした結果、多くのことを素早く観察することができます。 1. srclib は最下位に移動されました。srclib は Apace サーバのプラットフォームであり、ユーティリティ関数と正規表現処理のためのライブラリを持ちます。このことは、srclib より上位の層が、srclib が上位の層に依存するよりも、ずっと強く srclib に依存しているという事実に一致します。 2. os.win32 に対する include の依存は驚きです。検証によって、include/ap_config.h と httpd.h が os.win32/os.h をインクルードしていることを発見しました。また、include に対する os.win32 の逆依存関係も存在することを言及しておきたいと思います。 3. もっとも重要なこととして、server と modules の間に依存関係があることに注目してください。Apache アーキテクチャの背後にある基本原則は、modules は server に登録し、Web サーバリクエストに関連する処理を実行します。modules は動的にロードされるため、server が modules に依存することは予想外です。これらの依存関係を調査した際、server が http モジュールと proxy モジュールに依存していることが判明しました。このことは、これらのモジュールが apache core の一部であり、他のモジュールがさほど緊密に結合されていないことを示唆します。 Page 7/8 Copyright 2007-8 Lattix, Inc. All rights reserved C/C++ システムのアーキテクチャ管理 - Apache Server の解析このアーキテクチャを表す概念アーキテクチャ図も作成することができます。さらに重要なことは、許可する依存関係と許可しない依存関係のルールを作成できることです。アーキテクチャは毎日のビルドの一部としてテストすることができます。Apache サーバのさまざまな部分の間における、予想される依存関係についてのルールでさえも作成することができます。図 3: Apache の概念アーキテクチャ図 Page 8/8 Copyright 2007-8 Lattix, Inc. All rights reserved