Netbeans6.1のUMLで遊んでみる。

netbeans UML

※本文中、NetbeansをNBと略している

興味

NB6.1のUMLは、何が得意か？どんな使い方に向いているか？

おおまかな所感

  • シンプルなモデリングツール
  • 操作性は今後の課題。
    • モデリング時の操作の流れがスムーズでないと感じる。
    • 試行錯誤を繰り返しながらモデルを洗練させていくには向かない。（UNDOなし、タイプの変更不可etc..）
  • 設計者と実装者の”第一版”のコミュニケーションに使うツールとして有効。
  • IDEとモデリングツールが一体化している点が最も良い点。
    • 複数のツールを起動しなくてよいのがありがたい。
    • フォワードエンジニアリングで作成したモデルを確認しながら実装できる。 #0812追記
    • リバースエンジニアリングでモデルを生成し、整合性や無駄がないか確認しながら実装できる。 #0812追記
  • ターゲットや用途を絞り、サポートするダイアグラムを絞り込んでもよかったのかも。

特記事項

  • NB6.0.1の使用経験は、ほぼ皆無なので、NB6.0.1とNB6.1の比較ではない。
  • 普段使っている、または昔使ったことのあるUMLモデリングツールをもとに評価した私見であり、公平な評価ではない。
  • 普段、私がUMLモデリングツールを使う際の使い方は以下の通り。
    • クラス図、ステートマシン、アクティビティ図を主に作成する
    • あまり厳格な仕様は求めない。考えをまとめて可視化し、共有すること。
    • モデルはレビューを繰り返して徐々に洗練していく。
    • もちろん、設計モデルは実装との整合性がとれていることは必須。

確認ポイント

以下のポイントで確認した（定性的な指標のみ。）

  • モデリング時の流れを止めないこと
  • 共有したりレビューしたりできるよう、図の整形や印刷などが容易であること
  • フォワードエンジニアリング：自然であること
  • リバースエンジニアリング：モデルがないものについて、モデルを確認し、精査する材料を得られる等、補助的に使えること

個別の所感

※簡単に使って、気になった点のみメモ。

モデリングそのものや流れなど

⇒試行錯誤は苦手のように感じる。モデルの構成が決まったものや、頭の中のモデルのイメージをザクザクOUTPUTするのに向いているようだ。

■操作性、モデリングの流れ

  • △全般：パレットからコンポーネントを選ぶと、リピート設定がONの状態となり、好みが分かれるだろう（動作は指定できるのかもしれない）
    • 例えば、クラスを選択してクラス図に置いたあと、図内のどこかをクリックすると、そこにもクラスが作成される。
      • Esc押す習慣つければ、何てことないのだが。（ん？Escはメニューなどで示されているか？）
    • 参考までにEAの振る舞いに触れる。シフトキー押しながらパレットをクリックするとリピートON、Escでリピート解除。
    • ダイアグラムごとにどんなリピートのふるまいが向いているかを書いてみると、
      • クラス図：クラスを置いたら、次にクラス名を決めることが多いので、リピートOFFが自然。
      • アクティビティ図：新規ダイアグラムを作成する際には、パーティションはリピートONが自然。ただし、スタートノードや終了ノードはリピートOFFが自然。修正時はリピートOFFが自然。やはり選べるとよい。
      • ステートマシン図（状態図）：新規時はリピートONが自然。修正時はリピートOFFが自然。
  • ◎全般：各種設定画面で設定できる項目が統一されており、使い易い。ドキュメントも、タグ付き値も指定できる。
  • △全般：メニューでできること、コンテキストメニューでできること、プロパティで設定できるものが整備されていないようだ。


■試行錯誤

  • ×全般：UMLではUNDOは使えないようだ。
  • ○クラス図：関連：多重度や誘導可能性（ナビゲート可能）、別名などはいつでも変更できる。但し、設定画面の項目はカテゴライズされているのだが、項目がだーっと強弱なく並んでおり、探しにくい。慣れの問題か？
  • ×クラス図：関連：AssociationをAggregationやCompositionに変更することがよくあるが、できない。この場合は関連を引き直すことになり、関連のプロパティも設定しなおしになる。
    • ただし、これを実現する複雑度や優先度を想像すると、このバージョンで変更できないのは納得できる。が、こういった機能がないと、モデリングツールとしては辛い・・


■機能

  • ◎「依存図の作成」機能がうれしい。でも、関連が多すぎると依存図がみづらくなるので、依存や使用されているダイアグラムを検索できるだけでよいかも（EAはこちらの方式）
  • △パッケージ図：書けない。設計モデル作成時には、結構頻繁に書くんだがな。
  • ◎クラス図：関連クラスが作成できる！（そのままコード生成したら、どうなるんだろう・・後で確認）
  • △クラス図：関連のアクセッサ：誘導可能性をつけるとアクセッサが生成されるが、生成後に関連先クラス名を変更してもアクセッサメソッド名が変更されない。（意図した動作か？）
  • ×クラス図：関連：関連端名がダイアグラムに表示されない
    • ⇒関連右クリック⇒ラベル⇒両終端名　で表示可能だそうです ＃0508追記
  • ×クラス図：タグ付き値：タグを予め登録しておくことはできないと思われる。
  • △クラス図：表示：ダイアグラムに表示する可視性を設定できるとよい。（privateメソッドは表示したくないとか）
  • ○クラス図：インターフェースの実現クラスに、インターフェースの操作が再定義される。変更も即座に反映される。
  • ？アクティビティ図：シグナル送信はあるが、シグナル受信がない
図の整形と印刷

⇒整形はやや弱。印刷は良。

  • ×関連をクリックすると、関連が折れてしまい、場所を移動しにくい。どうやったら直線に復帰できるのか、わからん＞＜
  • ×サイズ揃えがないようだ。
    • アクティビティ図や概念クラスはユーザに見せることが多いので、レビューしてもらうためには、割合重要。
      • 「揃ってない⇒がちゃがちゃ感＝不快感、しかも読み方慣れていない⇒レビュー面倒」という連鎖が想定される。
      • ※UMLに不慣れなユーザとレビューして概念の共有化するとう目的を果たすためには、UMLそのものより、UMLちっくなもののほうがコミュニケーションしやすいことも事実。なので、モデルの整合性は確保できなくとも、VISIOが向いているケースもある。たとえば、アクティビティで業務フローを書く場合に、やりとりされるオブジェクトは、「荷物アイコン」とか「電話アイコン」で表すなど。ちなみに、EAはオブジェクトに好きなアイコンを割り当てられるので気に入っている。
  • ○ダイアグラムの印刷は良。大きなダイアグラムを任意のページに分けて印刷しやすい。
  • ○ダイアグラムを画像として出力できる。（クリップボードへのコピーも、もちろん可能）
フォワードエンジニアリング

ラウンドトリップには向かない。

  • ○生成時、もちろんモデル上に存在するメソッドのコードは保護される。
  • ×ソースコード上にモデル上存在しないメソッドなどがある場合、有無を言わさず上書きしてしまう。private属性やprivateメソッドはモデルに定義したくないんだが。。
  • ×生成されるJavaDocが過剰だし、化ける。（ソースはUTF-8にしてるつもり。[TODO]ほかの設定を確認） ※以下は、ところどころ全角に変更した例



    /**

     *  

     *    

     *  

     *    

     *    

     *      ＜p style="margin-top: 0">

     *        ＆#21517;＆#21069;＆#12391;＆#12377;

     *      ＜/p>

     *    

     *  

     */

リバースエンジニアリング

リバースですから。そんなに使わないし、十分だと思います。

  • ◎さくさくリバース。高パフォーマンス。
  • ○リバース時に、無理に図を作成しようとしない考えは共感できる。１０年くらい前のRationalRoseは図を生成していた(今は知らない)が、全クラスが１つのダイアグラムに含まれるため、意味がなかった。見ずらい図を時間をかけて生成するくらいなら、生成しないほうがずっとよい。）
  • △リバース時、java.langパッケージのように、明示的にimportを記述しないものは、モデル直下にフラットに吐かれてしまう。
  • ○モデルがあればモデルを上書きするか確認される。
  • ○「プログラムを先に書き、改めて構造を視覚的に確認する」用途に使うためには、この動作の軽さ、IDE一体化による手軽さはメリットと思われる。


と思ったけど、IDE一体型の強みはリバースして頻繁にモデルの整合性を確認できることかもね！と思いなおした。　#0812追記
リバースエンジニアリングについて(08/12)


手順は、
1.Javaソース右クリックで「リバースエンジニア」。
2.プロジェクトを指定する。
2.1.既存のUMLプロジェクトに生成することもできる。
2.2.新たなプロジェクトを起こすこともできる。

訳語

訳語は、統一用語集があるものの、いくつかの訳語が併記されている状態で、方言があるようです。
ここの所感は、「私の文化と違う」と言っているだけであり、ちょっと言いがかりっぽかったです。ごめんなさい。m(_ _)m
参考：UMTPのUML用語集

  • △訳：MLでもエディタの日本語訳についてのコメントが流れてますが、ここも訳さなくてよいものを無理やり訳している感がある。
    • ⇒少し疑問。私らが元の用語のままで使う文化をもっているのかも。
  • ×「図」とは言わない。「ダイアグラム」のほうが自然。
    • 勘違い。JudeCommunityでは「図」だった。UMTPの用語集では「図」、「ダイアグラム」併記
  • ×「状態図」とは言わない。「状態マシン」または「ステートマシン」
    • ⇒⇒これは誤訳と思われます
    • ⇒UML2.0の古い版（βとか？）を使っているため、UML1.XのStateDiagramを訳したそうです。訳した人も律儀ですね。 ＃0508追記
  • ×「入場点」「退場点」ではなく、「入状点」「退状点」では？
    • ⇒勘違い。UMTPの用語集では「入場点」「退場点」が優先訳で、「入状点」「退状点」は低優先でした。

変更履歴

2008/05/08 MLでの回答を追記。また、若干所感を追記。
2008/06/05 セクションを移動し、結論がさっさとわかるようにした。（気が短いのでね。）
2008/08/12 IDE一体型の強みは、実はリバースなのではないかと思えてきたので、追記した。大きな声では言えませんけど。
2008/08/14 所感などを少し読みやすくした（つもり）。また表現を手直しした。※内容の追加変更はなし。
2008/08/19 UML用語集のURLが変更されたので修正