日々ブログ

日々のくらしの中で思ったこと

【プログラミング】plant UMLのシーケンス図の書き方

過去に、plantumlを使ったユースケースの書き方を記載しました。
今回は、シーケンス図について記載してみたいと思います。

xinformation.hatenadiary.com

f:id:xinformation:20220213230156p:plain

シーケンス図は処理の流れの概要を表す

各システム同士がどのように連携しあうかを表した図です。
ソフトウェアでよく書かれる図なんですが、 ソフトウェア以外にも使えるような汎用的な図ですよ。
複数の人がどう連携すれば問題無くことが進むかを考える際に重宝する図です。
たとえば、レストランで注文を伝える場合を表すとこんな感じになります。

f:id:xinformation:20220213231324p:plain

登場人物を一番上に列挙して、 それぞれの関わりあい方を矢印で示します。
webアプリのサーバーとデータベースの通信のやりとりを示す場合などによく使われることが多いかな。

Plantumlでの記載方法

さきほどの図はPlantumlだと、下のスクリプトでかけます。
シーケンス図って、パワポとかそういう描画ソフトで描くと非常に面倒なんですよね。
作成している途中で登場人物が増えたり、処理が抜けていることに気づくと矢印の位置とか、四角形の位置とかの調整をする必要があります。
Plantumlだと、そうしたところはすべて自動で対応してくれるので非常に簡単ですよ。

@startuml
participant "お客さん" as Customer
participant "ホール担当" as Hole
participant "キッチン" as Kitchen

[-> Customer:開始
activate Customer
Customer -> Hole :食べたいメニューを伝える
activate Hole
Hole -> Hole:注文内容を記録する
Hole -> Customer:注文内容を確認する
Customer -> Hole:訂正情報を伝える
deactivate Customer
Hole -> Kitchen:注文内容を伝える
deactivate Hole

activate Kitchen
Kitchen ->Kitchen:調理する
Kitchen -> Hole:料理を渡す
deactivate Kitchen
activate Hole
Hole -> Customer :注文内容を確認してお客さんに料理を運ぶ
activate Customer
Hole -> Customer:注文内容に間違いないか確認する
Customer -> Hole:注文と料理が合っていることを伝える
Hole -> Hole:伝票処理する

Customer ->[:終了
deactivate Hole

@enduml

条件分岐が多いと読みにくい

個人的にですが、条件分岐が多いとかなり読みにくくなります。
料理を注文するというだけでもあれだけ縦長になりますからね~。
条件分岐があると、もっと縦長になって見通しが悪くなります。
条件分岐をしっかり書くなら個人的にはフローチャートとか、アクティビティ図をの方が良いと思いますね。

たとえば、作った料理が間違った場合を考えた場合は下図のようになります。
alt はシーケンス図特有の書き方で横にその処理を行う条件を横に記載します。
前半で行った処理と全く同じ内容を付け足すことになって、ただただ長くなり見にくいです。

f:id:xinformation:20220213231336p:plain