こんにちわ、んだです。
今回は「ユースケース図をvsCodeで書いて管理を楽にしたいんだ」というタイトルでお届けします。
ユースケース図、ロバストネス分析の修正コストについて
これまでいくつかの案件でユースケース図を用いて開発を進めてきました。
ユースケース図を書き、各ユースケースごとにロバストネス分析をするという、いわゆるICONIXプロセスで進めていったのですが、 ICONIXプロセスで進めると実装のイメージはしやすくなるし、ドメインに対する理解も深まるしで、ICONIXプロセス僕お気に入りです。
案件では、主に見やすさと操作性の観点から、デザインツールのmiroを使用してユースケース図の作成を進めました。 draw.ioを使用したこともありますが、miroで作成した方がかなり見やすくなったので、miroで書き始めた当初は気分よく書けてました。
ただ、しばらく経つとちょっとした問題が出てきました
その問題とは「ユースケース図、ロバストネス図自体の修正が手間＆後手になる」
ユースケース図もロバストネス図も、クライアントとのMTGや社内で要件定義の中でどんどん改善していくものなので 当然のことながら修正は必ずあります。
修正があったときに、さらっと修正できればよいのですが、普段デザインツールを触らないちょっと修正が次第に億劫になってくる という問題がありました。
PlantUMLを使ってみる
PlantUML公式: シンプルなテキストファイルで UML が書ける、オープンソースのツール
テキスト言語ベースでユースケース図とロバストネス図を書けるツールがありますた。
では、早速使ってみます。
※導入方法については、他の方の記事をご覧ください
PlantUMLでユースケース図を書いてみる
記述はかなりシンプルですぐにマスターできますし、公式のマニュアルに大概のことは書いてあります。
@startuml
left to right direction
actor Admin
package User {
usecase "ユーザー登録" as UC1
usecase "ユーザー編集" as UC2
usecase "ユーザー削除" as UC3
usecase "権限付与" as UC4
}
Admin --> UC1
Admin --> UC2
Admin --> UC3
Admin --> UC4
@enduml
秒です。
ユースケース図に即時反映されますし、画像として書き出すことも可能です。
さらに良いことに、これならgitでバージョン管理しておけるわけです。
さらにさらに、境界ごとにディレクトリをきちんと整理しておけば、 ユースケース図のディレクトリ構成をそのままプロダクションコードに持っていけるのではないか？とも思っている
僕から以上でした。
