2018年7月31日
【PlantUML】Visual Studio Codeのプラグインを使ってUMLを作成しよう!(実施編)
- Category 開発ブログ(技術ブログ)
こんにちは、ゆうこです。前回の【PlantUML】Visual Studio Codeのプラグインを使ってUMLを作成しよう!(基本編) では、PlantUMLのインストール方法と、主な図を紹介しました。
今回は、実際に資料を作って判った、便利なところ・困ったところを挙げていきます。メンバーは前回と同じ、せーいち、たいすけ、つかさ、ゆうこでお届けします。
実際に業務で使ってみての所感
シーケンス図
便利なところ
矢印や記号、コメントなどシーケンスを描くのに必要なものは一通り揃っていて、記載方法も矢印は”->”で表すなど直感的で分かりやすいです。
以前は、Excelでシーケンスを作成していたのですが、記号どうしの重なりや間隔などを逐一手動で調整しなければならなかったのですが、PlantUMLは、ツール側が自動で調整してくれるため、かなり効率よく描けます。
テキストでシーケンスを描くので、コーディングしている時と同じような感覚で書けるので、図を描くよりコーディングイメージが沸くような気がします。
例えば、とある処理をシーケンス図として記載すると下記のようになります。
@startuml hide footbox title そんな、ひどい… actor 姫 control 会話ウィンドウ control 効果音 [->> 姫 : 話しかける activate 姫 姫 -> 姫 : 確認処理 activate 姫 loop 無限ループ 姫 -> 会話ウィンドウ : はい/いいえ表示\n「姫のことを\nおもってくださいますか?」 activate 会話ウィンドウ ref over 会話ウィンドウ : はい/いいえ表示処理 break "はい"を選択 姫 <-- 会話ウィンドウ : はい end 姫 <-- 会話ウィンドウ : いいえ deactivate 会話ウィンドウ ||| 姫 -> 会話ウィンドウ : 表示\n「そんな、ひどい…」 activate 会話ウィンドウ 姫 <-- 会話ウィンドウ deactivate 会話ウィンドウ note right of 姫 : "いいえ"を選ぶ限り、無限ループ end 姫 <-- 姫 deactivate 姫 ||| 姫 ->効果音 : アイテム取得音 activate 効果音 姫 <-- 効果音 deactivate 効果音 姫 -> 会話ウィンドウ : 表示\n「うれしゅうございます。ぽっ」 activate 会話ウィンドウ 姫 <-- 会話ウィンドウ deactivate 会話ウィンドウ [<<-- 姫 deactivate 姫 @enduml
Excelで記載するとloopやbreakなどの枠位置や、オブジェクト間の幅など手動で調整しなければいけないところ、特に気にすることなく記述できます。
困ったところ
全体的に自動で描いてくれる利点が、融通の利かない箇所となってしまっている感があります。
例えば、ダメな点として、上記図で表すと、
ライフラインの実行状態 や 応答メッセージ は記載しないと表示されないところ や
書き方によっては、ライフラインの実行状態と普通のメッセージがあり得ないような表示になってしまったりなど、自動で描いてくれるのが逆に仇となっています。
また、UMLに準拠した図なら問題ないのですが、お客様向けに分かりやすくしようするなど、準拠から外れたものは描けないのが残念な点でしょうか。
クラス図
度重なる継承や、部品化により複雑になっていたクラス間の関係性を、新規参画者にもわかりやすいように整理しようと思い、クラス図を作成しました。
便利なところ
全体の構成を考えなくとも、クラスと関係さえ記載すれば、少ない時間で、綺麗な図が作成できるところ。
例えば、以下の様にクラスだけ列挙します。
title クラスチェンジ表 '武闘家 class "MartialArtistClass\n武闘家" as MartialArtist { } '戦士 class "WarriorClass\n戦士" as Warrior{ } 'バトルマスタ class "BattleMasterClass\nバトルマスター" as BattleMaster { } '僧侶 class "MonkClass\n僧侶" as Monk{ } '魔法使い class "WizardClass\n魔法使い" as Wizard{ } '賢者 class "SageClass\n賢者" as Sage{ } 'パラディン class "PaladinClass\nパラディン" as Paladin{ } '勇者 class "BraveClass\n勇者" as Brave{ } '村の少年 interface "VillageBoy\n村の少年" as VillageBoy{ }
すると 関係性のないクラスが列挙されます。
(ここでは改行コード'\n'を入れることによって、ER図の様に物理名、論理名をクラス図で表現しています。また、別名をつけているのは、関係性を表すときに簡素に記載する為です。)
次に、以下の様にクラス同士の関係性を追記します。
'村の少年の可能性 VillageBoy <|..d. Wizard :就職 VillageBoy<|..d. Monk :就職 VillageBoy <|..d. MartialArtist :就職 VillageBoy<|..d. Warrior :就職 '賢者のクラスチェンジ条件 Wizard <--- Sage :派生 Monk<--- Sage :派生 'パラディンのクラスチェンジ条件 Monk <--- Paladin :派生 MartialArtist<--- Paladin :派生 'バトルマスターのクラスチェンジ条件 MartialArtist <--- BattleMaster :派生 Warrior<--- BattleMaster :派生 '勇者のクラスチェンジ条件 Sage <--- Brave :派生 BattleMaster<--- Brave :派生
おお!なんとなくクラス図っぽくなりました!次にクラスの種別ごとに'package'でグループを作り、色付をします。
package 基本職{ '武闘家 class "MartialArtistClass\n武闘家" as MartialArtist #DEDFEF{ } '戦士 class "WarriorClass\n戦士" as Warrior #DEDFEF{ } } package 上級職{ 'バトルマスタ class "BattleMasterClass\nバトルマスター" as BattleMaster #FCF1D3{ } } package 基本職{ '僧侶 class "MonkClass\n僧侶" as Monk #EEF5D3{ } '魔法使い class "WizardClass\n魔法使い" as Wizard #EEF5D3{ } } package 上級職{ '賢者 class "SageClass\n賢者" as Sage #FCF1D3{ } 'パラディン class "PaladinClass\nパラディン" as Paladin #FCF1D3{ } } package 伝説の職業{ '勇者 class "BraveClass\n勇者" as Brave #F3D1E5{ } } '村の少年 interface "VillageBoy\n村の少年" as VillageBoy{ }
オブジェクトとオブジェクトの距離感もいい感じで、素早く書くことが出来ました。
困ったところ
PlantUMLが勝手にクラスを並び替えてくれるので「このクラスの隣はこのクラスが美しい!!」みたいなSEとしてのこだわりは、位置を厳密に指定しないとPlantUMLさんには関係ないので、無視されてしまいます。
また、全体のバランス感覚には弱く、「もっとこのオブジェクトは右の方がいいのだけど・・」と思うことがままあります。
先ほどのクラスチェンジ表で言うと・・・
<中略> package 基本職{ '武闘家 class "MartialArtistClass\n武闘家" as MartialArtist #DEDFEF{ } '戦士 class "WarriorClass\n戦士" as Warrior #DEDFEF{ } }
オブジェクトの左右が入れ替わる現象については、線が重ならないようにPlantUMLが努力してくれた結果なので、メリットかも知れません。
RGBを指定してクラスに色を付けたり、'package'を使いクラスの纏まりを作ることで、見やすい図は作れるかと思います。
何よりも作成速度が速いので、「どうしても美しさを追い求めたい・・」という場合以外はお勧めです。
コンポーネント図
複雑な処理周りを簡易的なコンポーネント図にすることで相関関係を把握するために作成しました。
便利なところ
Excelなどで作成する時のようなオブジェクト一つ一つを動かす必要がなく自動的に図を作成してくれました。そのため作成時にオブジェクト操作に時間を割かずに狙った作業に注力できました。コードでの作成となるため処理の関係性が把握しやすかったです。
例としてプラモデルをコンポーネント図として下記に記載します。
@startuml title "プラモデル" node "部品Aグループ"{ component "部品A-1" as PartA1 component "部品A-2" as PartA2 component "部品A-3" as PartA3 } node "部品Bグループ"{ component "部品B-1" as PartB1 component "部品B-2" as PartB2 component "部品B-3" as PartB3 component "部品B-4" as PartB4 component "部品B-5" as PartB5 component "部品B-6" as PartB6 component "部品B-7" as PartB7 } node "つなぎ部品Cグループ"{ interface "つなぎ部品C-1" as PartC1 interface "つなぎ部品C-2" as PartC2 } PartA1 --> PartA2 PartA1 --> PartA3 PartA1 --> PartB1 PartA1 --> PartC2 PartA2 --> PartB2 PartA2 --> PartB3 PartA3 --> PartB4 PartA3 --> PartC1 PartC1 --> PartB5 PartC2 --> PartB6 PartC2 --> PartB7 @enduml
部品Bが多く、部品Aやつなぎ部品Cとの関係性を把握するのが難しかったですが、明確になりました。
困ったところ
ただ、図が狙った通りに作成されるわけではないので、結局見た目の調整する時間が割くことになりました。それでも、今回の複雑な処理を図にする場合ではExcelでやるよりも時間は短縮されたと思います。
実は関係性を書き出した後はもっと見づらいものでした…
プレビューを見ながらコードを修正しました。
PartA1 -> PartA2 PartA1 -> PartA3 PartA1 -> PartB1 PartA1 -> PartC2 PartA2 -> PartB2 PartA2 -> PartB3 PartA3 -> PartB4 PartA3 -> PartC1 PartC1 -> PartB5 PartC2 -> PartB6 PartC2 -> PartB7
修正後
PartA1 --> PartA2 PartA1 --> PartA3 PartA1 --> PartB1 PartA1 --> PartC2 PartA2 --> PartB2 PartA2 --> PartB3 PartA3 --> PartB4 PartA3 --> PartC1 PartC1 --> PartB5 PartC2 --> PartB6 PartC2 --> PartB7
管理者として
便利なところ
テキストベースなので、TFVCやGitで管理した時に、差分が見やすいですし、複数人で同時に更新できる処も魅力です。
画像だとどこが変わったのか、目で確認しないといけません。Excelの場合は同時編集の有無や競合にも注意を払う必要があります。
素早く、統一された書式で描けるので、複数人で描いても見た目にバラつきが少ないです。そのぶん記載内容に集中できるところは嬉しいですね。
困ったところ
閲覧するにはGraphviz必須ですので、Graphvizが無い相手に渡す時(例:納品時)は図に変換する事でしょうか。
ソースコードからクラス図を起こす等、ソース連携したいなら、他ツール(AmaterasUML、astah)のほうが良さそうです。
まとめ
そのため一度作って修正しない資料や、見栄えにこだわる資料を作成するには、ExcelやCacoo、astahなど既存ツールに軍配が上がるかな、と感じました。
ですが「70点版で良いから、ざっくり設計内容を共有したい」「ガンガン入力して、考えをリアルタイムで図にまとめたい」ならPlantUMLはおすすめです!環境を作るのも記述するのも楽々です。
UML図作成ツールの候補として、いかがでしょうか?
もしかして興味あるかも?
【基本編】使ってる?Visual Studio Code おすすめプラグイン紹介 #01
【HTML編】Visual Studio Code おすすめプラグイン紹介 #02
【PlantUML】Visual Studio Codeのプラグインを使ってUMLを作成しよう!(基礎編)