日々ブログ

当サイトは、アフィリエイトプログラムにより商品をご紹介しています

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

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

xinformation.hatenadiary.com

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

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

登場人物を一番上に列挙して、 それぞれの関わりあい方を矢印で示します。
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

個人的な書き方ルール

個人的には下記のポイントを抑えて記述します。
設計を表したいのか仕様を記述したいのかでも若干変わります。

  • その処理の流れについて正常系について記述する
  • ユニット内部の細かな動作は記述しない

この2点でしょうか。

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

条件分岐が多いとかなり読みにくくなります。
シーケンス図は、各ユニットの役割と動くタイミングを示すために記述するものです。 なので先程の例を取り、料理と注文情報が間違っていた場合を加筆すると、下図のようになります。 料理の注文くらい単純なものであればよいですが、プログラミングのような条件分岐だらけの処理をすべて記述すると非常に冗長になります。

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

たとえば、作った料理が間違った場合を考えた場合は下図のようになります。
alt はシーケンス図特有の書き方で横にその処理を行う条件を横に記載します。
前半で行った処理と全く同じ内容を付け足すことになって、ただただ長くなり見にくいです。
プログラマからすると、長ったらしい図を読まされることになった時点で気が滅入るというのが本音でしょうから、最低限の条件分岐に留めるのがおすすめです。

ユニット内部の細かな動作は記述しない

次に、各ユニットの細かな動作は記述しないのがおすすめです。
繰り返しになりますが、 シーケンス図は、各ユニットの役割と動くタイミングを示すために記述するものです。
なので、シーケンス図において各ユニットの処理をこと詳細に記述してメンバーに展開しても、伝わりません。
webアプリとするならば、サーバーのことはサーバーでやってくれ!という感じでしょうか。
またまた先程の図を例にとると、 お客さん側からしたらホール担当のことしか気にしないですし、キッチンのことなど気にもかけません。
気にしなくてもいい人が気にしなくてもいいことを気にしないといけなくなるのは非常に冗長です。 何よりユニット間の疎結合な設計も阻害します。

もちろん、何か伝えたい情報があるのならば記述しても良いです。
しかし、あまりそういった事情に出くわしたことはないので、そういったことがないならば不必要な情報を伝えても混乱するだけですから記載しないのをおすすめします。