>>前編

コンパイラの仕組みを応用

 ソースコードからクラス図やシーケンス図をどのように生成するのか。そのメカニズムを見ていこう。

 図3は,Eclipseを例にJavaのソースコードをリバースする仕組みである。他の開発言語でも基本原理は同じだ。

図3●リバース・エンジニアリングのメカニズム(Javaの場合)
図3●リバース・エンジニアリングのメカニズム(Javaの場合)
Java向けのツールであるEclipseの例を示したが,他の開発言語でも基本原理は同じ。リバース・エンジニアリングの流れは,コンパイラの仕組みを応用してソースコードを解析した後,「UML2」と呼ぶAPIを使って各要素をUMLモデル上に配置する
[画像のクリックで拡大表示]

 リバースの流れは,コンパイラの仕組みを応用している。具体的には,まずソースコード(テキスト・ファイル)に含まれる文字列を「public」や「void」のように,字句の単位で分割する。これを「字句解析」と呼ぶ。次に,「public」の後には「static」が続いて問題がないといった,文法上の並びを確認する。これが「構文解析」だ。その上で各字句の意味を解釈する「意味解析」を実施する。例えば「public」は「誰でも利用可能」といった具合である。

 後はUMLモデルへのマッピングを実施するためのAPI(UML2)を使って,各字句をクラス図上に配置するだけだ。ここでは,字句解析→構文解析→意味解析という流れで生成される,Javaの中間コードを使う。中間コードは,JavaVM上で実行可能な実行ファイルである。この中間コードに含まれる各情報をUMLモデル上に配置していく。当たり前だが,中間コードに含まれない情報をUMLモデル上に示すことはできない。また,コンパイル・エラーとなるソースコードは,基本的にリバースできない。

使いものにならないUMLモデルを生成

 リバースの仕組みは非常にシンプルである。ただ,リバースすればきれいなUMLモデルが描けるとは限らない。せっかくリバースしてもソースコードに問題があると,複雑かつ難解なUMLモデルを生成してしまう。ウルシステムズの吉田氏によれば,それは次のような三つのケースだ(図4)。

図4●複雑かつ難解なクラス図を生成してしまうソースコードの例
図4●複雑かつ難解なクラス図を生成してしまうソースコードの例
循環参照や巨大クラス,冗長処理といった要素を持つソースコードは,リバース・エンジニアリングをしても複雑かつ難解なUMLモデルになってしまう。ソースコードを書き換える,再設計をするなどの対策が必要である(ソースコードの下線部分が問題の個所)
[画像のクリックで拡大表示]

 一つ目は「循環参照」である。図のソースコードの下線部分が問題の個所。FirstClass,SecondClass,ThirdClassという三つのクラスがあるが,FirstClassはSecondClassを参照し,SecondClassはThirdClassを参照している。さらにThirdClassはFirstClassを参照しており,参照関係が複雑なモデルになってしまう。

 二つ目は「巨大クラス」の例だ。機能の追加や修正などで一つのクラスに様々な属性や操作を追加したのが原因である。こうなると,巨大クラスにいくつものクラスが関連し,改修などによる影響の範囲が格段に広がる。巨大クラスを分割する対策などが必要だ。

 最後は「冗長処理」。これは,似たような属性や操作がソースコードのあちこちにあるので,それら属性や操作がモデル中に分散してしまう。

 このほか,テクノロジックアートの長瀬氏は「パッケージ間の関連が複雑に絡み合うと,読解不能なクラス図を生成してしまう」と指摘する。このようなケースの場合,「ファサード(門)」と呼ぶオブジェクトを用意し,各オブジェクトはファサードを通じて他のパッケージを参照させるような対策が必要となる。

RDBのリバースは成熟の域

 最後に,リレーショナル・データベース(RDB)を対象としたリバースについても触れておこう。「この分野はほぼ成熟の域に達している」と,日本オラクルの杉達也氏(Fusion Middlewareグループ 担当シニアマネジャー)は説明する。

 図5に示したのが,RDBをリバースする際の仕組みだ。Oracle Databaseを例にデータ・モデルを生成する流れを示したが,基本原理は他のRDBでも同じである。

図5●RDBのリバース・エンジニアリングの仕組み(Oracle Databaseの場合)
図5●RDBのリバース・エンジニアリングの仕組み(Oracle Databaseの場合)
テーブル名や列情報,制約情報などを格納したDBカタログを解析し,物理データ・モデル(E-R図)を生成。物理データ・モデルと論理データ・モデルの属性同士の対応表を用意すれば,論理データ・モデルも生成できる
[画像のクリックで拡大表示]

 リバースの入力情報となるのは,テーブル名や列情報,制約情報などを格納する「DBカタログ(データ・ディクショナリ)」である。

 例えば,「USER_TABLES」というDBカタログには,テーブル名がある。図の例ではUSER_TABLESを参照し,「DEPT」や「EMP」などのテーブル名を抽出している。列情報を解析するには「USER_TAB_COLUMNS」を参照する。例えば,DEPTテーブルには列名「DEPTNO」があり,そのデータ型は「NUMBER」である,といった情報が分かる。

 主キーや外部キーといった制約情報は「USER_CONSTRAINTS」と呼ぶDBカタログを参照する。USER_CONSTRAINTSを見れば,例えばEMPテーブルの「DEPTNO」が,DEPTテーブルを参照する際の外部キー(FK)であることが分かる。

 テーブル名,列情報,制約情報を抽出したら,それをE-R図上に配置していく。ここまでは,ほとんどのデータモデリング・ツールが備える機能である。

 さらに,「Oracle Designer」など一部のモデリング・ツールを使うと,物理データ・モデルを論理データ・モデルに変換できる。これは,物理データ・モデルと論理データ・モデルの属性同士を対応付けた表を用意し,それぞれ変換していくものだ。ただし,この表が無ければ変換はできないだけに,UMLモデルと同様,意味付けしたモデルへのリバースは簡単にできないと言える。