staticフィールド/メソッドを別のクラスに移す

MixJuiceでは、staticメソッドをサポートしていません。そこで、staticフィールド/メソッドを、新たに作成した別クラスに移し、そのクラスのシングルトンインスタンスを元のクラスのstaticフィールドに設定しました。

内部クラスを通常のクラスにする

Grappaでは、内部クラスがいくつか使用されていたので、通常のクラスに変更しました。

モジュール分けに備えた変更の試み

Grappaのリファクタリング進めていく中で、次のモジュールに分けることができそうと考えました。

• 論理的なグラフモデルを表すベースモジュール(att.grappa.base)
• グラフを幾何学的にレイアウトするためのモジュール(att.grappa.patchwork)
• 幾何学的なグラフを描画するためのさまざまな属性(フォントや線の太さなど)を管理するモジュール(att.grappa.attribute)
• 様々なノードの形を描画するためのモジュール(att.grappa.grappanexus.impl)
• GUIのメニューやイベントをハンドリングするモジュール(att.grappa.ui)

phase 2が終わってから振り返ると、この時点でクラスからインターフェイスを抽出し、インターフェイスと実装を分けておくと、MixJuice化の際に仕様モジュールと実装モジュールに分割しやすかったと考えられます。Javaの段階でのリファクタリングでは、仕様モジュールと実装モジュールの分離を広範囲に行うことは考えていませんでした。

定数の分類

オリジナルのGrappaのインターフェイスGrappaConstantsは、様々な場所から参照される定数を集めたものでした。さらに、ほとんどのクラスが同インターフェイスを実装し、その定数を利用していました。そのため、どの定数がどの機能から必要とされるものか不明確でした。

そこで、まずJavaの段階で、同インターフェイスに含まれる定数をドメインごとに分割し、GCElementType, GCHighlightSettings, GCAttributes, GCShapesの4つのインターフェイスを作成しました。さらに、インターフェイスGrappaConstantsが、これら4つのインターフェイスを継承するように変更しました。これで、各定数がどのドメインに属すのか明確にすることができます。なお、どのドメインにも属さないGrappa共通の定数は、インターフェイスGrappaConstantsに残しました。

特定のドメインの定数しか参照しないクラスは、4つのインターフェイスのうちのいずれかを参照することになります。

なお、MixJuice化をする際は、GCElementType, GCHighlightSettings, GCAttributes, GCShapesがGrappaConstantsのサブモジュールになります。

リファクタリングにおけるIDEの有用性

リファクタリングを行うには、元のプログラムの構造を理解する必要がありますが、eclipseの検索機能や型階層の表示機能を使うことで、構造の理解が容易になりました。

また、実際のリファクタリングにも、eclipseを使用しました。インターフェイスの抽出やメソッドの抽出など便利な機能が用意されています。

リファクタリングの際に重要なのは、影響範囲の特定とバグを混入させないことです。IDEを利用することで、影響箇所がコンパイルエラーとして即時に判明し、短いサイクルでリファクタリングを進めることができ、バグの混入を最小限にすることができました。特に今回のようにプログラムの規模が大きくなると、その効果は大きいです。実際、リファクタリングが終了した時点でデモプログラムを実行しましたが、リファクタリングによる問題は発生しませんでした。

Javaレベルでのリファクタリング後のクラス図を示します。

仕様モジュールと実装モジュール

まず、Java 言語で書かれたアプリケーションを MJ に書き直す手順に書いてあるように、ひとつのモジュールにすべてのクラスを入れようとしました。しかし、ソースの量が多いため、コンパイルが通るレベルにするのにかなり時間がかかり、しかもひとつの巨大なソースになると作業効率が落ちます(コンパイル時間、エラー個所の特定、カーソルの移動など)。そこで、複雑な実装のクラスについては、仕様モジュールと実装モジュールに分割することにしました。

仕様モジュールでは、前述(表1Grappaの概要項やモジュール分けに備えた変更の試み項)のようなある程度のモジュール分けを行いました。実装モジュールでは、必要な仕様モジュールをすべてextendsし、オリジナルのメソッドにできるだけ手を加えないように注意しました。これは、メソッドの中身に手をつけるとバグを混入しやすいためです。phase 1としては、メソッドにできるだけ手を加えずにMixJuice化し、動作確認後、phase 2でメソッドの中身に着手することにしました。これは、MixJuice化の最中は、動作確認ができないためです。

	複雑なクラスやモジュールの依存関係の整理には仕様モジュールを使う
	仕様モジュールは、複雑なクラスやモジュールの依存関係を解きほぐし、理解しやすくするのに役立ちます。インターフェイスは、実装と比較すると、相対的に単一のモジュールに属するものが多いですが、メソッド内の実装は、複数のモジュールにまたがるものが多くなります。そのため、実装を含んだままでは、モジュール分けが困難です。そこで、仕様モジュールと実装モジュールに分割して、仕様モジュールをさらに分割することにしました。そうすることにより、メソッドの実装に加える変更を最小限にでき、バグ混入を回避できます。

Windowsでのコンパイルの問題

モジュールに含まれるクラスが多くなると、mjcの途中、mjjavacに渡す引数がWindowsのコマンドラインの長さの限界を超えるために、コンパイルが不可能になりました。 Windows版のJDKのjavacには、コマンドライン引数をファイルから読み込む機能があります。 そこで、コンパイル対象のファイルを一時ファイルに書き込み、javacの引数に「@コマンドライン引数ファイル名」を渡すように、mjtool.jarを変更して回避しました。

フラットな長いブロックの問題

例1のように、ひとつのブロックに極端に多くの文があると、mjcのプリプロセスの段階で、スタックオーバーフローが発生しました。eppで、ループではなく再帰で処理しているか、reduceが起きずに延々とshiftが続くためと考えられます。メソッドが400個あるクラスのコンパイルは正常にできたので、特定のスコープで要素数が多いと発現するようです。

{
  hoge(0);
  hoge(1);
  hoge(2);
// ...
  hoge(100);
}

例2のように名前空間が分断されても問題ない場所でブロックを区切ることで回避しました。

{
  {
  hoge(0);
  hoge(1);
// ...
  hoge(50);
  }
  {
  hoge(51);
// ...
  hoge(100);
  }
}

originalメソッドでのthrows節が無効になる

メソッドをdefineで定義した際に、throws節で発生する例外を指定します。このメソッドを別のモジュールでオーバーライドした場合(例3)、本来であれば、 original()の呼び出しでは、throws節で指定された例外が発生する可能性があるので、try/catch、またはオーバーライドする側でもthrows節が必要となります。

module m {
  define class MyException extends Exception {
    define MyException() {}
  }
  define class Base {
    define void func() throws MyException { throw new MyException(); }
  }
  define class Derived extends Base {
    void func() {
      try {
        original(); // MyExceptionが発生する可能性あり
      }
      catch (MyException e) {
      }
    }
  }
}

m\_Delta_m_Derived.java:11: 例外 m.MyException は対応する try 文の本体ではスローされません。
      super.func(); } catch (
                      ^

      try {
        original();
        if (false) throw new MyException(); // ダミー
      }
      catch (MyException e) {
      }

一部のJava interfaceをMixJuiceで実装できない時の注意点

一部のJavaのinterfaceはMixJuiceで実装できません(MixJuiceのホームページの「知られているバグと対処法」参照)ので、Java側でそのinterfaceを実装するクラスを作成しておき、そのクラスをMixJuiceでextendsする必要があります。しかし、Javaのinterfaceを実装したい元のクラスが既に親クラスを持っている場合、多重継承はできないため、親クラス側に遡ってextendsしなければなりません。

今回の移植では、Subgraphがjava.util.Comparatorを実装する必要があります。そこで、java.util.Comparatorを実装したComparatorWrapperというJavaクラスを用意しました。しかし、図1Grappaの概要項に示したように、SubgraphにはElementという親クラスがあるので、やむを得ずElementがComparatorWrapperをextendsするように変更しました。そのため、本来java.util.Comparatorを実装していないはずのNodeやEdgeなど、全てのElementの子孫がjava.util.Comparatorを実装することになり、移植前のJavaプログラムと等価性が失われました。

原因不明のNullPointerException

再現条件を特定できないNullPointerExceptionが発生することがあります。現在推測できている条件は、

• 多くのモジュールを imports しているモジュールで発生する
• コンストラクタが原因になっている
• モジュール名に強く関わっている

通常不必要な、子クラスから親クラスへの明示的なキャストを追加することで解消するNullPointerExceptionも存在しました。(demo.java 中の DemoFrame のコンストラクタ)

クラス名に$を含むクラスの問題

クラス名に $ を含むクラスを、二つ以上のモジュールから参照すると、リンク時にエラーが発生します。

module dollar1 {
  define class doll$doll {
    define doll$doll() {}
  }
  class SS {
    doll$doll d = null;
    void main(String[] args) {
      d = new doll$doll();
    }
  }
}
module dollar2 extends dollar1 {
  class SS {
    void main(String[] args) {
      original(args);
      d = new doll$doll();
    }
  }
}
   

エラーメッセージは以下のようなものになります。

     java.lang.LinkageError: duplicate class definition: dollar1/_Dummy_dollar1_doll$doll
   

解決方法は、問題となっているのが MixJuice のクラスであれば $ を使うのをやめれば良いです。Java のクラスである場合(特に Java の内部クラスで実現されているクラスは $ をクラス名に含むことに注意してください)、Java の段階で$を含むクラスを継承した$を含まないクラスを作り、 MixJuice でこれを使わなければなりません(今のところ、それをさらに MixJuice で継承したクラスを使わないとうまくいきませんが、これは CLASSPATH の問題の可能性もあります)。

モジュール依存に関する注意点

モジュール a を b が継承するようなモジュール継承ツリーがあったとして、a を変更した場合、b をコンパイルしなおさなければならない可能性は高いです。bをコンパイルしなおすだけでなく、eppout ディレクトリの中身を空にしなければいけない場合もあります。

Java パッケージ名と MixJuice モジュール名の問題

MixJuice 中で imports する Java クラスのパッケージ名と同じモジュール名のモジュールを作ることはできません。どちらかの名前を変更して対処すれば良いです。

曖昧な名前の解決方法

曖昧な名前の解決には、FQN[moduleName::simpleName]の表記方法を用いることになっていますが、クラス/interface名に関してはmoduleName.simpleNameという表記でなければコンパイルが通らず、メンバ名のFQN表記と統一されていません。

サブモジュールでのインターフェイスの追加

module M {
  define class A {}
  define interface I {}
}

module M1 extends M {
  class A implements I {}
}

module M2 extends M {
  class A implements I {}
}

module M3 extends M1, M2 {
}

java.lang.ClassFormatError: Repetitive interface name

そもそも、クラスの実装インターフェイスを、サブモジュール(M1,M2)で追加することがMixJuiceの文法上正しいのか、不明確でした。

クラスの二重定義

module m {
  define class Base {
  }
}
module m1 extends m {
  class Base {
    define void f() {}
  }
  class Base {
    define void g() {}
  }
}

Preprocessing phase.
test9.java:7: m.Base:(id f)
    define void f() {}
    ^
java.lang.Error: MJC: FATAL ERROR : m.Base:(id f)

そもそも、同一のモジュールで同じクラスを複数に分けて記述する必要性はなく、また、MixJuiceの文法上許されない記述だと思われます。したがって適切なエラーメッセージが出るようになれば問題ありません。

しかし、次のようにメソッド名を同じにするとコンパイル/実行 可能ですが、実行結果は"FOO"の表示のみとなり、最後のf()しか有効で ない模様です。エラーを出力すべきと思われます。

module m {
  define class Base {
     define Base() {}
  }
}
module m1 extends m {
  class Base {
    define void f() {System.out.println("FOOx");}
  }
  class Base {
    define void f() {System.out.println("FOO");}
  }
  class SS {
    void main(String[] str) {
      (new Base()).f();
    }
  }
}

実行時のjava.lang.ExceptionInInitializerError

正常にコンパイルできたプログラムを実行すると、java.lang.ExceptionInInitializerError が発生することがあります。これは、下記のように静的初期化の順序が重要なケースで発現します。 この例では、Grappa.DICTの初期化の後、Grappa.selfを初期化しないと上記の例外が 発生します。ただし、下記の例では、例外は発生しません。おそらくモジュールのリニアライズ の結果、初期化順序が逆転する場合に本現象が現れるものと考えられます。 いろいろ試しましたが、問題が発現する単純な例を見つけることはできませんでした。

module att.grappa {
  define class Grappa {
    static final Grappa self = new Grappa();
    define Grappa () {}
  }
}
module att.grappa.base extends att.grappa {
  class Grappa  {
    static java.util.Map DICT = new java.util.HashMap();
  }
}
module att.grappa.attribute extends att.grappa.base {
  class Grappa  {
    Grappa () {
      original();
      DICT.get("");
    }
  }
}
module m.all extends att.grappa.attribute {
  class SS {
    void main(String[] args) {
      Grappa  x = Grappa.self;
      System.out.println("ok");
    }
  }
}

典型的なエラーメッセージ

MixJuice への移植は類型的な作業が多いため、発生するエラーも類型的なものが多いです。ここでは、表示されるエラーメッセージのうち、特に頻発するものを示します。

	同一クラスに対して define が二つある場合
	panel-impl.java:3: MJ: Ambiguous class name "GrappaPanel" is used at module panel.impl これは同一クラスに対して define が二つある場合に発生します。エラーメッセージが特にわかりにくいため、注意が必要です。

同一メソッドに対して define が二つある場合

subgraph-impl.java:1790: MJ: Reference to prepPatchWork(java.lang.String, int) of att.grappa.Subgraph is ambiguous. : subgraph-impl.java:1801: findMethodInfo: More than one MethodInfo found. java.lang.Error: MJC: FATAL ERROR : findMethodInfo: More than one MethodInfo found. 両者とも同一メソッドに対して define が二つある場合に発生します。 問題となるメソッド宣言とそのメソッド呼び出しの位置を比べて、宣言が先にプリプロセッサに発見された場合は前者が、呼び出しが先に発見された場合は後者のエラーメッセージが出ます。前者のメッセージは多少わかりにくいため、注意が必要です。equalsメソッドなどの親クラスで既に定義されているメソッドに対して define を付けてしまった場合に発生します。

	クラスに define が無い場合
	panel-impl.java:3: MJ: No class definition of GrappaPanel found. Probably, missing "define" for it, missing "extends" declaration or misspelling. これはクラスに define が無い場合に発生します。

	メソッドに define が無い場合
	panel-impl.java:49: MJ: In att.grappa.GrappaPanel at module panel.impl : Definition-method does not have "define" . : addGrappaListener これはメソッドに define が無い場合に発生します。

	コンストラクタでfinalなフィールドに代入できない場合
	subgraph/impl/_Delta_subgraph_impl_SubgraphEnumerator.java:2583: cannot assign a value to final variable subgraph_impl_self ((subgraph.impl._Delta_subgraph_impl_SubgraphEnumerator)(Object)(this)).subgraph_impl_self = (((subgraph.impl._Delta_subgraph_impl_SubgraphEnumerator)(Object)(this)).subgraph_impl_root = (self)); ^ これに限らずエラーメッセージに final があればその final は取り除かなければなりません。

	static final な変数を、定数式が必要とされるコンテキストで、クラス名の修飾なしで参照した場合
	panel/impl/_Delta_panel_impl_GrappaAdapter.java:1859: constant expression required case ((att.grappa._Delta_att_grappa_GCElementType)(Object)(this)).att_grappa_SUBGRAPH : static final 変数をクラス名で修飾します。

ダンプ機能の分離

ダンプ機能は、グラフ構造をdotフォーマットでダンプする機能です。 この作業における、元のJavaコードのクラス図と、 MixJuice化してリファクタリングしたコードのレイヤードクラス図を示します。

モジュールatt.grappa.element.impl, att.grappa.node.impl, att.grappa.graph.impl, att.grappa.subgraph.impl, att.grappa.edge.implに分散していたdotフォーマット(Grappaでグラフ構造を記述するのに使用するフォーマット)の出力機能は、いくつかのクラスにまたがってはいるものの、同一アスペクトに属する機能であると考えられます。そこで、att.grappa.dumpというモジュールを作成し、そちらにdotフォーマット出力機能を移動しました。att.grappa.dumpは、att.grappa.element.impl, att.grappa.node.impl, att.grappa.graph.impl, att.grappa.subgraph.impl, att.grappa.edge.implを継承しました。

att.grappa.element.impl, att.grappa.node.impl, att.grappa.graph.impl, att.grappa.subgraph.impl, att.grappa.edge.implモジュールにおいて、このダンプ機能が占めるコードの量がかなり多く、それぞれのモジュールの可読性を悪くしていました。 ダンプ機能をatt.grappa.dumpモジュールにまとめることができたため、各モジュールの保守性が向上しました。また、att.grappa.dumpモジュールには、ダンプ機能しか含まれないため、クライアントが同機能を使わない場合は、同モジュールを継承しないという選択も可能となりました。

モジュールの分離/統合

定数モジュール

定数の分類項で述べたように、インターフェイスGrappaConstantsに含まれる定数を、Javaの段階で定数を複数のインターフェイスに分類しました。

この分割によって、どの定数がどの機能に使われているかが明確になり、ソースコードの保守性が高くなりました。また、モジュールで分割する方がオブジェクト指向の継承で実現していた段階よりも明確な記述であると考えられます。このように、MixJuiceのモジュール機構は、互いに依存しない、定数のみのクラスをモジュール分けする場合には非常に良く機能します(逆に他で述べるように複雑なケースでは表現が難しくなるケースが少なからず存在します)。

大きなユーティリティクラス

クラスGrappaSupportはstaticメソッドのみで構成されるクラスで、広い範囲で必要とされている機能や、特定のクラスに分類がしにくい機能(ドメインが近い二つのクラスに必要とされているなど)を提供するクラスでした。MixJuice化の早い段階で継承ツリーの上位層にatt.grappa.supportモジュールを作成し、このクラスを置きました。局所的にしか使われませんが、特定のクラスに分類しにくいがためにGrappaSupportに置かれていたようなメソッドは、それぞれもっと適切であろう下層のモジュールに移動させていきました。

結果として、GrappaSupportのメソッドは非常に多くのモジュールに分散し、メソッドの定義位置を特定しにくいクラスになってしまいました。プロジェクトの全容をあまり把握していない人間には、メソッドの定義場所を探すのが難しくなってしまいました。この問題はよくできたコードブラウザなどがあれば緩和されると考えられますが、完全に問題が解消されることは無いでしょうし、そういったツールの存在しない現状においては依然として大きな問題です。

この問題を解決する一つの方法として、異なるドメインに属するGrappaSupportクラスには別のシンボル名を与えることが考えられます。例えば、grappaparserモジュール内でしか使用しないGrappaSupportの機能は、クラスGrappaParserSupportを新たに定義して、こちらに移動すれば良いです。しかし、この解決法では必然的に細かいクラスの増加を招いてしまいますし、GrappaSupportは将来的に他のモジュールから使用されることも考慮している機能も多いため望ましい解決とはなりません。

このように、どこから利用しても構わないようなユーティリティクラスは、 複数のモジュールに分散させずに、クラスをdefineしたモジュールに全て詰め込んだ方が保守性が高いと考えられます。 GrappaSupportクラスの場合、全てatt.grappa.supportに戻してしまうのが最も適切と考えられます。全メソッドが、ほぼ全てのモジュールに公開されてしまいますが、ユーティリティ的なメソッドなので問題はありません。

実際の解決には上記の解決法や、個々の事例に応じた解決(例えば一部の機能を適当なクラスに移動するなど)を組み合わせて解決するべきです。今回のリファクタリングではこの解決はまだ実現されていませんが、大きなユーティリティクラスのモジュール分けが難しい問題であることは認識できました。

モジュール機構によるMVCの実装サポート

この作業における、元のJavaコードのクラス図と、 MixJuice化してリファクタリングしたコードのレイヤードクラス図を示します。

モジュールatt.grappa.panel.implのクラスGrappaPanelは、MVCを全て備えたかなり大きなクラスでした。このクラスはユーザーインターフェイスのコードの見通しを悪くしていたため、*Listenerのメソッドを実装している部分を分離し、モジュールatt.grappa.uiに移動しました。その結果、モジュールの意義が不明確になっていたatt.grappa.uiに、MVCのC(コントローラ)を担うという意義を与えることになり、モジュールatt.grappa.panel.implとモジュールatt.grappa.uiの継承関係も逆転しました。(CVStag: FIX_8 リファクタリングの経過項参照)

この段階では、モジュールatt.grappa.panel.implで宣言されているGrappaPanelクラスは*Listenerのメソッドをオーバーライドしなければならないため、*Listenerインターフェイスを実装していました。しかし、モジュールatt.grappa.panel.implはMVCのモデルとビューを担うモジュールであり、*Listenerインターフェイスを含むJavaパッケージ(java.awt.event.*など)をimportするのは不自然でした。そこで、*Listenerインターフェイスを実装してコントローラの役割を持つクラスGrappaPanelControlを定義し、これをatt.grappa.uiに移動することによって、モジュールatt.grappa.panel.implがjava.awt.event.*などに依存しないようにしました。(CVStag: FIX_9 リファクタリングの経過項参照)

この変更を単純化したものを以下に示します。viewモジュールがatt.grappa.panel.implに、controlモジュールがatt.grappa.uiにそれぞれ対応しています。

// FIX_8 の前
module view { 
  define class View extends JFrame implements SomeListener { 
    define View() { 
     // initialize... 
     addSomeListener(this);
    } 

    void handleSomeEvent(SomeEvent ev) { 
     // handling... 
    } 
  } 
} 
   

// FIX_8 の後
module view { 
  define class View extends JFrame implements SomeListener { 
    define View() { 
     // initialize... 
     addSomeListener(this); 
    }
  } 
} 

module control { 
  class View { 
    handleSomeEvent(SomeEvent ev) { 
     // handling... 
    } 
  } 
} 

// FIX_9 の後
module view { 
  define class View extends JFrame { 
    define View() { 
     // initialize... 
    } 
  }
}

module control { 
  define Control implements SomeListener { 
    View view; 
    define Control(View view) { 
     this.view = view; 
    } 
    handleSomeEvent(SomeEvent ev) { 
      view.updateView(...); 
    } 
  } 

  class View { 
    Control control;

    View() { 
     original(); 
     addSomeListener(control); 
    }

    define updateView(...) { 
     // ... 
    }
  }
}
   

仕様モジュールと実装モジュールの分離

リファクタリングを進める中で、仕様モジュールと実装モジュールの分離は、常によい結果をもたらしました。

仕様モジュールと実装モジュールを分離する1つ目のメリットは、仕様モジュールが依存するモジュールを最小限にできることです。 仕様と実装が同じモジュールにあると、実装上(つまりメソッドの中身を記述する上で)必要なモジュールを拡張しなければなりません。 仕様と実装を別のモジュールに分けることで、仕様モジュールが依存するモジュールを、インターフェイス上現れる型を解決するのに必要なモジュールに限定することができます。 これにより、情報隠蔽を効果的に実現できます。

次の例では、モジュールmod1, mod2が仕様モジュールです。インターフェイス(仕様)レベルでは、mod1とmod2は独立です。しかし、実装レベル(モジュールmod12.impl)では、method1とmethod2は相互に依存しています。

module mod0 {
  define class Grappa {
    define Grappa() {}
    define boolean isX() { return false; }
  }
}
module mod1 extends mod0 {
  class Grappa {
    define abstract void method1();
  }
}
module mod2 extends mod0 {
  class Grappa  {
    define abstract void method2();
  }
}
module mod extends mod1 {
  class SS {
    void main(String[] args) {
       Grappa g = new Grappa();
       g.method1();
    }
  }
}
module mod12.impl extends mod1, mod2 {
  class Grappa  {
    void method1() {
       System.out.println("method1");
       method2();
    }
    void method2() {
       System.out.println("method2");
       if (isX())
          method1();
    }
  }
}

仕様モジュールと実装モジュールに分離しなかった場合、mod1のクライアント(モジュールmod)からmod2のインターフェイスが可視になってしまいます。

仕様モジュールと実装モジュールを分離する2つ目のメリットは、コンパイル時間の短縮です。仕様モジュールのインターフェイスを利用するクライアントモジュールのコンパイルの際、仕様モジュールだけ参照すればよいのでコンパイルが高速になります。 また、実装モジュールを変更した際、クライアントモジュールのコンパイルの再コンパイルは不要で、実装モジュールだけコンパイルすればよいです。これにより、プログラムのビルド時間が大幅に短縮されます。

このようなメリットは、Javaのインターフェイスを用いても得ることができますが、その概念をモジュール単位に広げても、同様メリットが得られることが分かりました。

リファクタリングの経過

リファクタリングの経過を後で分析できるように、リファクタリングの節目節目で、その時点のソースのバージョンにCVSのタグをつけるようにしました。以下、各CVSのタグごとにどのようなリファクタリングを行ったのかを示します。

	FIX_1(att-grappa-support.javaだけrevision 1.1 を使用) grappaparserモジュールの継承元の変更
	モジュールatt.grappa.graph.implにクラスGraphのコンストラクタが存在したので、モジュールatt.grappa.baseにabstractなコンストラクタを宣言することで、モジュールgrappaparserが、モジュールatt.grappa.graph.implに依存しないようにしました。 結果として、モジュールgrappaparserは、モジュールlexerおよびatt.grappa.attributeに依存するようになりました。 また、grappaparserモジュールのファイル名をparser.javaからgrappaparser.javaに変更しました。

	FIX_2 幾何学的クラスをatt.grappa.geomモジュールに抽出
	att.grappa.supportモジュールなどに存在した幾何学的クラスGrappaBoxやGrappaPointなどをatt.grappa.geomモジュールに抽出しました。

	FIX_3 att.grappa.graph.implモジュールの継承元をatt.grappa.element.implに変更
	att.grappa.subgraph.implモジュールを継承していたatt.grappa.graph.implモジュールをatt.grappa.element.implモジュールを継承するように変更しました。

	FIX_4 att.grappa.nexus.implモジュールの継承元をatt.grappa.element.implとatt.grappa.patchworkへ変更の試み
	本来、att.grappa.nexus.implモジュールが、att.grappa.edge.implモジュールを継承する必要がなさそうなため、att.grappa.edge.implモジュールを継承する代わりに、att.grappa.element.implモジュールを継承するように変更を試みましたが、att.grappa.nexus.implモジュールが、att.grappa.edge.implモジュールの実装(フィールドの直接参照)を参照していたため、変更を保留しました。

FIX_5 assertだけの空メソッドの追放

以前、別の原因のコンパイルエラーを、define abstractによる抽象メソッドに対してのエラーと勘違いして、抽象メソッドをassert false;というダミー実装のメソッドにしてしまっていたのを、抽象メソッドに戻しました。 ただし、一部のJava interfaceをMixJuiceで実装できない時の注意点項で述べたように、JavaではSubgraphクラスでjava.util.Comparatorインターフェイスを実装していたものを、MixJuiceの制限のため、MixJuice版ではSubgraphクラスではなくその親クラスであるElementクラスでjava.util.Comparatorインターフェイスを実装するように変更しました。そのため、Node.compare と Edge.compare メソッドの呼び出しが理論上可能になりましたが、本来、この呼び出しはバグであるため、これらのメソッドの中身はassert false;のままにしてあります。

	FIX_6 各要素の状態のダンプ部の分離(ダンプ機能の分離項参照)
	att.grappa.element.impl, att.grappa.node.impl, att.grappa.graph.impl, att.grappa.subgraph.impl, att.grappa.edge.implモジュールに分散していたダンプ系メソッドを att.grappa.dump モジュールに移動しました。

	FIX_7 nexus のパース部分離
	nexus 内のパース処理を att.grappa.nexus.impl.parser に分離しました。 実は、att.grappa.patchwork にはほとんど パース関係は含まれていませんでした。 代わりに、ダンプ関係のメソッドが att.grappa.patchworkに多少残っています。

	FIX_8 ui - panel の MVC化 その1(モジュール機構によるMVCの実装サポート項)
	att.grappa.panel.impl が M と V、att.grappa.ui が C となるように変更しました。 それに伴って今までは ui を panel が継承していましたが、 逆転して att.grappa.panel.impl が att.grappa.ui を継承するようになりました。 また、上位のモジュールである att.grappa.panel.impl も att.grappa.nexus.impl を継承するように変更しました。

	FIX_9 ui - panel の MVC化 その2(モジュール機構によるMVCの実装サポート項)
	その1の変更では、GrappaPanelクラスは元々 VC 両方を兼ねていたため、 GrappaPanelクラスの宣言時に *Listenerインターフェイスを implements しなければならず、 結果として event 周りのモジュールを att.grappa.panel.impl 側で import する必要がありました。 そこで GrappaPanel の *Listenerインターフェイスを継承して コールバックを登録する役割を移動させた新しいクラス GrappaPanelControl を導入して、この問題を回避しました。

	FIX_10 不要コードの整理
	不要コードの整理と、ビルドファイルの更新を行いました。

アスペクトを明確に分けられない場合

以下の図のように、クラスZのメソッドAはアスペクトAに属し、メソッドCはアスペクトCに属し、メソッドBはアスペクトAとCの中間に位置するような場合、モジュール分けの判断が難しいところです。一般に、クラスはアスペクト単位で作るものではないので、実際のプログラムでは、このようなケースは非常に多いです。また、このようなアスペクトのオーバーラップがあちこちで起こると、3竦み、4竦み状態となり、どのようにモジュール分割を行うか悩まされます。

メソッドBが、実装上、アスペクトAとCの両方に依存するのであれば、仕様モジュールと実装モジュールに分けることにより解決できます。しかし、メソッドBがインターフェイス上アスペクトAとCの中間に位置する場合、次のいずれかになります。

1. モジュールA(メソッドA)、モジュールAC(メソッドB)、モジュールC(メソッドC)の3つのモジュールに分ける

2. モジュールAC(メソッドA,メソッドB,メソッドC)の一つにする

3. モジュールA-(メソッドA)とモジュールC(メソッドB,メソッドC)の二つにする(その逆もある)

フレームワークのなどの開発では、1のような厳密なモジュール分けが好ましいと考えられます。しかし、多くのアプリケーション開発にとっては、厳密なモジュール分け(javaのパッケージ分けも然り)にそれほど重要な意味はなく、モジュール分けに時間を使うよりも2のようにモジュールを分割しない方が現実的です。

今回の移植では、クラスSubgraphのメソッドcreateElementがどのモジュールに属すべきか曖昧なメソッドに該当します。下記のその理由を示します。