【プログラミング】UMLを作成するメリットとplantumlの書き方

プログラミングする際に、UMLを作成することのメリットについて記載したいと思います。

UMLの役割って？
UMLの導入メリット
UMLを導入する際の注意点
ユースケースの記載方法
- チケット販売機のユースケース
まとめ

UMLの役割って？

UMLはunified modeling language の略称で、和名は「統一モデリング言語」です。
もう少し砕いて言うと、UMLはソフトウェアの仕様の策定から実装の設計までの設計内容の記載方法についてのガイドラインです。

なぜこんなものが必要かというと、ソフトウェアはモノを伴ったハードウェアと異なり、テキスト文字で綴られたプログラムコードが集まってできています。
規模の大きなものとなると、膨大な文字数の業務などで使用されているシステムにだとコードの行数は100万行（文字数だと1億文字くらいかな）を超えます。
プログラマはこうしたテキストの塊に修正を加えたり、新しいプログラムを加えることでシステムをより便利にしています。その際、こうしたテキストの塊をを何の手がかりもなく、読み解いたり作成するのは至難の業です。

こうしたテキスト文の全体構成を把握したり、一から作成するためにUMLが必要になるのです。
UMLとしては以下のような図があります。

シーケンス図
ユースケース図
クラス図
オブジェクト図
アクティビティ図
コンポーネント図
配置図
状態遷移図
タイミング図

UMLの導入メリット

ソフトウェアの品質を担保できることがメリットです。
役割で述べた内容と少々被りますが、そのプログラムがどのような工程で作られたか、属人化されてできないか、論理的におかしくないかなどを説明できるようになります。
また、プロジェクトの都合上、人員が入れ替わったりした場合の情報共有に非常に役立ちます。
取引先にもよりますが、ソフトウェアの動作をUMLを用いて説明することもでできるでしょう。

Point

非プログラマに説明する資料となる
プログラマの教養みたいなものなので設計情報を共有しやすい

UMLを導入する際の注意点

UMLを導入する場合、記載粒度を気をつけなければいけません。
記載粒度が粗いと、実装工程で何を作れば良いのかが分からなくなってしまい、開発工程が滞ってしまいます。
では、細かく書けば良いかというと、今度は細かすぎるためプログラムを2度書くようなことになり、これまた開発が前に進みません。
また、細かすぎると全容を把握できず、誰にも読まれない文章が出来上がってしまいます。
プロジェクトメンバーの状況を見ながら適切な情報を適切な粒度で記載するのが重要です。
とくに重要なのがユースケースです。

ユースケースの記載方法

ユースケースは、ソフトウェアの振る舞いを端的に表せます。
もともとはUMLの用語なのですが、PRなどにも利用できるため、最近はWEBサービスの紹介ページなどにもよく使われています。
ソフトウェアだけでなく、製品全体に関わるくらいの情報量がある素晴らしいツールです。

私は作成する際に以下の点に気をつけています。
・目的語と動詞で構成する・できることが同じ登場人物はまとめる・ソフトウェアでしない/できないことを意識しながら書く

チケット販売機のユースケース

たとえばチケット販売機の場合は以下のようになります。
他にも細かなユースケースはあると思いますが、代表的な機能だけ記載しました。
まず、登場人物に「一般消費者」・「会員」・「保守担当者」があることが分かります。
会員は一般消費者と同じことができます。
保守担当者は会員が行うことはできませんが、保守担当者しかできないことをメンテナンスツールによって行います。
メンテナンスツールとチケット販売機を線でつなげるなどしても良いと思います。
ポイントとしては、「退会」はチケット販売機ではできないということです。
こうした人によっては当然あるだろうと思う機能をチケット販売機では行わないことを暗に示しています。
ついつい見落としがちですが、ソフトウェアの開発委託で発注者側と受注者側の認識の違いはこうしたところで表れてくるので、ユースケースを持ちいてしっかりと仕様について議論しましょう。

f:id:xinformation:20211120105303p:plain

@startuml
left to right direction
skinparam packageStyle rectangle
actor 一般消費者 as GeneralUser
actor 会員 as VIpuser
actor 保守担当者 as ServicePerson
rectangle チケット販売機 as VenderMachine {
  usecase "チケットを買う" as UC_VM1
  usecase "会員権を購入する" as UC_VM2
  usecase "会員権を更新する" as UC_VM3
}

rectangle メンテナンスツール as MaintenanceTool {
    usecase チケット販売機の売上を確認する as UC_MT1
    usecase チケットの不具合状況を確認する as UC_MT2
    usecase 売上代金を確認する as UC_MT3
    usecase 売上代金を回収する as UC_MT4
}

GeneralUser --> UC_VM1
GeneralUser --> UC_VM2

VIpuser --> UC_VM3
VIpuser -|> GeneralUser

ServicePerson -->UC_MT1
ServicePerson -->UC_MT2
ServicePerson -->UC_MT3
ServicePerson -->UC_MT4

@enduml