前の関連記事:linuxBean14.04(56)Eclipse Modeling ToolsでJavaコードからUMLを生成:その4
Javaソースコードの静的コールグラフを作成してくれるEclipseプラグインispaceのコールグラフをispaceのソースコードで作って、エッジの意味を調べてみます。
EclipseプラグインispaceのソースコードをEclipseに取り込む
ispace : Ispace - Downloads browse
この一番下にあるリンクからispace_0.8.1.zipをダウンロードしました。
これを解凍してでてくるispace_0.8.1フォルダの中にあるispaceフォルダがすでにEclipseプロジェクトフォルダになっています。
EclipseのメニューからFile→Import。
General→Existing Projects into Workspace。Next。
Select root directoryでispace_0.8.1/ispaceフォルダを選択するとProjectにispaceプロジェクトがでてくるのでそれにチェックがついた状態で「Finish」。
ライブラリもすべて追加されています。
UMLフォルダとispace_kdm.xmiファイルはプロジェクトをインポート後にあとでlinuxBean14.04(52)Eclipse Modeling ToolsでJavaコードからUMLを生成:その1の方法で追加したものです。
isapceでispaceプロジェクトを見る
やり方はlinuxBean14.04(51)Eclipse4.5のインストールと静的コールグラフ生成でやった通りです。
パッケージを展開していくとエッジがでてきます。
私が知りたいのはエッジを選択したときに横に表示される数値の意味と赤いエッジの意味です。
ispaceのソースでエッジに表現に関係していそうなところを探す
結論としてはいまの私にはJavaソースを理解する力はなく、以下のように動作させた結果と解説で知りたいことの解を得ました。
ソースにコメントが書いてあればUML(2)yWorks UML Doclet:JavadocにUML図をつけるツールの方法を使おうと思ったのですがチラッと読んでみるとコメントはほとんどないようでしたのでこの方法は断念しました。
Javaソースファイルがたくさんあって何がどこに書いてあるのかさっぱりわからないのでまずはjavaファイルを適当な単語で検索してあたりをつけます。
ファイルマネージャでispace_0.8.1/ispace/srcフォルダを開いてツール→ファイルを検索する。
「ファイル名のパターン」に「*.java」と入力。
(「*」をつけ忘れると何もファイルがひっかからないので忘れないようにします。>>よく忘れる自分へ。)
「color」で検索してみました。
8つのjavaファイルがひっかかりました。
一つずつ右クリックしてGeanyで確認してみるとAggregatedConnectionEditPart.javaがエッジの表現をしているような印象でした。
このファイルはispace_0.8.1/ispace/src/de/tud/st/ispace/ui/partsにありました。
Eclipseのパッケージエクスプローラでみるとde.tud.st.ispace.ui.patrsパッケージにありました。
アイコンの意味はアウトライン ビュー | Eclipseの使用方法に解説があります。
AggregatedConnectionEditPartクラスにはprivateフィールドが4つ、publicメソッドが3つあることがわかります。
performRezuest()メソッドのアイコンの右下にあるVariableアイコンは引数を表しているようです。
ソースを読んでも今の私には理解できないのでとりあえずこのAggregatedConnectionEditPart.javaにあるAggregatedConnectionEditPartクラスをispaceでみてみます。
ipsaceのエッジはUMLのRealization(実現), Generalization(汎化), Usage(使用)のいずれか
ispace : Ispace - User Guide browseのNode and relation typesの項をみるとispace relations are categorized as: implements, inherits, uses.Visually they conform to the UML notation.と書いてあります。
なのでispaceの図のエッジはimplements、inherits、usesのいずれかを表していることになります。
これらはUML1.4の用語でUML2.4ではそれぞれRealization(実現), Generalization(汎化), Usage(使用)になります。
これらのどれに該当するのかをみていけばよいことになります。
クラスグループ内のエッジを選択したときに表示される数値はUsage(使用)にある要素数を表す
AggregatedConnectionEditPartクラス内のメソッド同士に依存関係はないようです。
methodsグループとfieldsグループを結んでいるエッジを選択するとmethodsグループ側に2、fieldsグループ側に4と表示されます。
これはそれぞれに含まれるUsageにある要素の数を表しているようです。
試しにmethodsグループにあるhidelnfosメソッドをドラッグしてmethodsグループの外に出してエッジを選択して数値をみてみます。
hideInfosメソッド側が1、fieldsグループ側が2になりました。
類推が正しければhidInfosメソッド側は要素が一つしかないので当然1で、fieldsグループ側の数値が2ということはhideInfosメソッドからfieldsグループの要素を二つ使っているはずです。
予測どおりhideInfosメソッドを除いたmethodsグループ側の要素数が2から1に減少しています。
fieldsグループ側の要素数が4のままなのはこの数値は使用している回数ではなく使用しているfieldsグループ側の要素の数(種類)を表しているからです。
hideInfosメソッドがfieldsグループのどの要素を使用しているかを確認するにはfieldsグループの要素をその外に一つずつ出してみればわかります。
sourceMultiplicityLabelフィールドをfieldsグループの外に出してみるとhideInfosメソッドと結ばれhideInfosメソッドとfieldsグループを結ぶエッジを選択したときに表示されるfields側の数値が2から1に減少しました。
sourceMultiplicityフィールドに加えてtargetMultiplicityLabelフィールドをfieldsグループの外に出すとhideInfosメソッドとエッジで結ばれhideInfosメソッドとfieldsグループを結ぶエッジは消えました。
グループの外にある単独要素同士のエッジを選択しても要素数の数値は表示されませんでした。
要素が1つ同士の関係は1と当然決まっているからでしょう。
グループとつながるエッジは使用している要素数が増える程太さが太くなり、色も灰色から黒色へ変化していくようです。
1対1で要素を直接つなぐエッジは黒色になるようです。
ソースを読まなくてもispaceのグラフをいじるだけでこれだけのことがわかってしまいました。
本当にそうなっているかソースを見るためにhideInfosメソッドをダブルクリックします。
hideInfosメソッドがハイライトされた状態でAggregatedConnectionEditPart.javaファイルがエディタ画面に開きました。
ispaceで確認したとおりtargetMultiplicityLabelフィールドとsourceMultiplicityLabelフィールドが使われていますね。
パッケージエクスプローラにある「Link with Editor」ボタンをクリックするとエディタ画面で開いているパッケージをパッケージエクスプローラで表示してくれます。
Ungroupで各要素の関係をみてMember Clusteringで元に戻す
一つずつ要素を選択してグループ外にドラッグするのが面倒に思うときはグループを選択した状態で右クリックしてUngroupします。
AggregatedConnectionEditPartクラス内のmethodsグループとfieldsグループをともにUngroupしまた図です。
元に戻すにはAggregatedConnectionEditPartクラスを選択した状態で右クリック→Member Clustering→Member Type、とします。
何も選択せずに行うと影響する範囲がはっきりせずぐちゃぐちゃな図になって戻すのが大変になるのでやめといたほうがよいでしょう。
ぐちゃぐちゃになってどうしようもなくなって最初に戻りたいときはパッケージエクスプローラでプロジェクトを右クリック→ispace→Remove ispace Nature、でispaceの図を捨ててまた最初から作り直します。
赤色のエッジは関係が循環していることを示す
JdtVisualMappingクラス内のメソッド間に赤いエッジで結ばれたものを見つけたのでそちらをみます。
ソースを見てもお互いにUsageの関係にあるだけでどういうときに赤色になるのか類推できずに困り果てていたらispace : Ispace - User Guide browseのLayoutの項にちゃんと書いてありました。
ispaceでは依存関係はlevelで管理されておりすべては最初はlevel0にいます。
level0のものに依存するものはlevel1になり、それに依存するものはlevel2、、、というようにlevelがどんどん上がっていくものですが、お互いに依存関係にあって、関係性が循環しているものは赤色になるようです。
確かに上図をみても赤いエッジをたどっていくと元のノードにもどってこれます。
右クリックメニューでDo Layoutとするとlevelが再計算されるとのことですが、何がどうかわるのかよくわかりませんでした。
srcフォルダをlayoutで検索してでてくるファイルにCycleFinder.javaをみつけました。
ispace_0.8.1/ispace/src/de/tud/st/ispace/analyses/cyclesフォルダにあります。
このCycleFinder.javaを読んでもエッジを赤色に指定している部分は見つけられませんでしたが、赤色が何を意味しているのかわかったのでもう追究しません。
白抜き矢頭はGeneralization(汎化)を表す
public class AggregatedConnectionEditPart extends ConnectionEditPart implements IModelElementListener {
AggregatedConnectionEditPart.javaの28行目でAggregatedConnectionEditPartクラスはConnectionEditPartクラスを継承しているとわかります。
UML2.4以降はInheritance(継承)は定義されずGeneralization(汎化)(継承とは逆側から見た方向)になります。
なのでAggregatedConnectionEditPartからConnectionEditPartへの白抜き矢頭(色は関係なし)はAggregatedConnectionEditPartがConnectionEditPartに汎化されていることを表します。
Class AggregatedConnectionEditPart is generalized by (=inherited from) Class ConnectionEditPart.
破線に白抜き矢頭はRealization(実現)を表す
public class MethodTag implements IMemberTag {
ispace_0.8.1/ispace/src/de/tud/st/ispace/jdt/tags/IMemberTag.javaの15行目でIMemberTagインターフェイスを実装しています。
implementationもUMLでは厳密に定義されずRealization(実現)になります。
MethodsクラスからIMemberTagへの白抜き矢頭の点線はMethodTagがIMemberTagを実現していること表しています。
MethodTag realizes (=implements) Interface IMemberTag.
UMLのクラス図との比較
linuxBean14.04(55)Eclipse Modeling ToolsでJavaコードからUMLを生成:その3と同様にしてAggregatedConnectionEditPartクラスをUML図に描いてみます。
AggregatedConnectionEditPartクラスはPapyrusのモデルエクスプローラからroot model→ispace→tud→st→ispace→ui→partsでたどりつくAggregatedConnectionEditPartをClassDiagramにドロップします。
描画されたクラスを右クリック→Filters→Show/Hide Contents。
継承したものも表示されているので括弧書きのfromがないものだけにチェックをつけます。
UMLのクラス図はispaceのコールグラフと違ってクラス内の依存関係は表現できません。
モデルエクスプローラにあるGeneralization(汎化)とRealization(実現)のアイコンをClassDiagramにドロップするとConnectionEditPartクラスへの汎化とIModelElementListenerの実現が描画されます。
Generalization(汎化)とRealization(実現)の矢印の形はispaceのコールグラフのエッジと同じですね。
AggregatedConnectionEditPartクラスと依存関係にあるクラスをモデルエクスプローラで探すのは困難なのでispaceのコールグラフで探します。
ispaceのコールグラフでみるとAggregatedConnectionEditPartクラスは同じpartsパッケージ内でUsageのエッジがつながっているものがないのでpartsパッケージ外にドラッグします。
AggregatedConnectionEditPartクラスからcommandパッケージへUsageのエッジが伸びています。
commandパッケージ内のどのクラスを使っているのかを調べるにはcommadパッケージをUngroupします。
ExpandSourceAndTargetSideCommandクラスへエッジがつながっていることがわかりました。
Papyrusのモデルエクスプローラに戻ってroot model→ispace→tud→st→ispace→ui→partsの中にあるExpandSourceAndTargetSideCommandへのDependencyを探し出してClassDiagramへドロップします。
アルファベット順に並んでいるわけでもないので探し出すのは大変です。
Dependencyのエッジだけはispaceのコールグラフのエッジと異なります。
参考にしたサイト
ispace : Ispace - Home browse
開発中断になっていますがJavaコードを図化してくれる便利なEclipseプラグインです。
ispace : Ispace - Publications browse
ここにある二つの論文にispaceがしていることの解説が詳しく書いてありますがとても理解が難しいです。
アウトライン ビュー | Eclipseの使用方法
Eclipseのパッケージエクスプローラでも同じアイコンが見れます。
UML Class Diagrams - Graphical Notation Reference
UMLのクラス図の凡例。
0 件のコメント:
コメントを投稿