僕的Plant UMLのススメ【UML知識&環境構築 for mac編】

こんにちは
前回から引き続き、Plant UMLに関して書いていきます。
今回は、「そもそもUMLってなんや？」から始まり、「PlantUMLってどうすれば使えるようになるの？」等をご紹介する記事です。

Style編 (前回)
環境構築編 For Mac & PlantUMLとはなんぞや & UMLって何？(これ)
図形描画編 (次回)

それではいつもどおりネタ画像とともにどうぞ

PlantUMR?

第1章: 目次

第0章: ご挨拶
第1章: 目次
第2章: UMLとは？
第3章: PlantUMLとは？
- PlantUMLを使うメリット
- PlantUMLを使うデメリット
第4章: PlantUML on Atomの環境構築 for Mac
最終章: おわりに
- 参考

第2章: UMLとは？

UMLの定義

UMLとは(Unified Modeling Language)の略で、統一モデリング言語と訳されることが多いです。
言語と書かれているので非エンジニアの方は忌避してしまうかもしれませんが、極論を言うと誰でもわかるようにある一定の規格をまとめた図の総称です。

UMLとは、オブジェクト指向のソフトウェア開発において、データ構造や処理の流れなどソフトウェアに関連する様々な設計や仕様を図示するための記法を定めたもの。ソフトウェアのモデリング言語の標準としてとして最も広く普及している。 *1

主にシステムを開発する際の設計時に作成されることが多いです。

そもそも、なぜUMLなどというモノが必要なのかというと、大きく4つの理由があります。

開発チーム内でのプロダクト(開発物)に対する共有を図るため
- エンジニアも一人の人間。感じ方・考え方は人それぞれ。
  複数の作曲家が「なんか、POPでイカした90秒の曲作って」と依頼を受けた場合、誰一人として同じ曲を作れないのと一緒。
  システムも音楽も実体がないので、密な共有がないと同じものを作ることができないのは当たり前。
開発にかかわらない人でも、システムのできること・できないこと等の共有を図るため
- 依頼者も開発者もそれぞれ一人の人間。言葉だけですべてのイメージを共有できるのであれば、それはすでに超能力の一種。
  エンジニアが「ここの仕様どうしましょうか？」ってめっちゃ聞いてきても、キチンと答えてあげてください。彼らは使う人達の要望を~~お金と時間と人間関係が良好な限り~~最大限叶えようと努力しています。
開発チームがいなくても、他のエンジニアが設計を把握するため
- ~~作った人が皆やめてもギリギリ生き残る~~
プロダクトの問題点を洗い出しやすくするため
- システムの仕様書とか設計とかを書くと、色んな人からレビューをもらうことができ、システムの穴を見つけたりすることができる。

アジャイル手法で開発を進めていない会社で「なんでシステム開発をするときにUMLみたいな図を書くんだ!! さっさと作ればいいじゃないか。」みたいなことを言い出す上司がいたら、上記の理由を言って説明してあげてください。
~~アジャイル手法を使っているからと言って、全く設計しないところは逆にやばいので気をつけて(特に第3項目)~~

UMLの種類

前節でご紹介したとおり、UMLはソフトウェアの設計するために用いられる図なので、様々な種類があります。ここではとりあえず、主要なUMLを列挙し、次節でそれぞれのUMLの細かいところの説明をします。

名称	図
ユースケース図
アクティビティ図
状態図(ステートマシン図)
クラス図
ER図
CURD図
データフロー図
シーケンス図
コンポーネント図

UMLの使いみち

ユースケース図

丸い枠内の内容をユースケース、人形をアクター(Actor)と呼ぶ。
Actorはシステム(対象)外のシステム(対象)に対して何らかのユースケースを実施可能なすべてのモノを指す。(人だけじゃなくて、外部のBotなどもActorになり得る)

Actorとユースケースが線でつながっている場合は、
(Actor)は(ユースケース)の機能を利用できる
ということを意味する。

inculde	extend

システム設計以外ユースケース図を使う場合

f:id:DTM3110:20191027010341p:plain

@startuml
skinparam Usecase {
  BorderColor Black
  FontColor Black
}
skinparam Actor {
  BackgroundColor<<Mother>> Pink
  BorderColor<<Mother>> Pink
  BackgroundColor<<Father>> Blue
  BorderColor<<Father>> Blue
  BackgroundColor<<Me>> DeepSkyBlue
  BorderColor<<Me>> DeepSkyBlue
}
skinparam Shadowing false
title 母親の権威が強い家庭のユースケース図

:母: as 母 <<Mother>>
:父: as 父 <<Father>>
:私: as 私 <<Me>>
:銀行: as 銀行

母 <.. 父 : <<include>>
父 <.. 私 : <<extend>>

母 --> (引き落とし)
(エステ) ..> (買い物) : <<extend>>
母 --> (エステ)
母 --> (家事)
父 --> (入金)
父 --> (出社)
父 --> (買い物)
私 --> (登校)
私 --> (買い物)
銀行 --> (引き落とし)
銀行 --> (入金)

@enduml

アクティビティ図

物事の初期状態から最終的な状態までの行動を図示するUML。
記号(構成要素)がたくさんあるけど、詳しく知らなくてもおおよそ分かる。

構成要素一覧

f:id:DTM3110:20191027101402p:plain *2

図の特性上、システムのフローはもちろん、私生活の一部も図示することができる。
たぶん利用範囲が一番広い図。

私生活で使う例

f:id:DTM3110:20191027105739p:plain *3

@startuml
skinparam Shadowing false
skinparam Activity {
  BorderColor Black
  FontColor Black
}
title 肉じゃがのレシピ

start
:材料を準備;
note right
  準備する材料
  ====
  ・牛肉または豚肉(250g)
  ・じゃがいも(中4〜5個)
  ・玉ねぎ(中1個)
  ・人参(中1本)
  ・白滝(1袋)
  ・サラダ油(大さじ1)
  ◎ 砂糖(大さじ2と1/2)
  ◎ みりん(大さじ2と1/2)
  ◎ 料理酒(大さじ2と1/2)
  ◎ だし汁(300ml)
  ◎ 醤油(大さじ3)
end note
:具材を切る;
note right
  じゃがいも：煮崩れしやすいので大きめに
  玉ねぎ・人参・肉：好みに合わせた大きさで切る
end note
:鍋にサラダ油を引く;
:じゃがいも・玉ねぎ・人参を炒める;
while (じゃがいもの表面が) is (透き通っていない)
  :炒め続ける;
endwhile (透き通ってきた)
:◎で示した調味料を加える;
-> 中火で5分間煮付ける;
:醤油を加える;
:肉を入れて良くほぐす;
:肉に重ならないように
白滝を入れる;
-> 弱火よりの中火で15分煮付ける;
while (じゃがいもが) is (硬い)
  :煮続ける;
endwhile (柔らかくなった)
:火を止める;
note right
  鍋に入れたまま一度冷やすと味がよく染みて良い
end note
end
@enduml

ステートマシン図

対象(オブジェクト)の状態線を表現するためのUML。
対象が主体になるところがポイント。
実施者単体にフォーカスして、どんな動きをするのかを図示する感じ。

具体的なサンプル画像

携帯電話の充電状態 *4

クラス図

システムを構成するクラスとそれらの関係を表現するUML。
一つのまとまりの持つクラスの属性や機能をわかりやすく示し、それらの関係性を表現する。

f:id:DTM3110:20191027114608p:plain

PlantUML記述例

@startuml
class エンジニア {
 + 名前
 + スキル
 # 生年月日
 - 給料
 + システム開発()
}
class PM {
 + 名前
 # 生年月日
 - 給料
 + システム設計()
 + 開発マネジメント()
}
class 開発部 {
 + プロジェクト予算
 + 参加人数
 + システム設計()
 + システム開発()
}

PM "1" --* "多" 開発部
エンジニア "多" *-* "多" 開発部

@enduml

ER図

ER図のERとは、Entity Relationshipの略称であり、データベースのテーブル(Entity)とテーブル同士の関連(Relationship)を示したUMLです。
クラス図から機能がなくなって、主キーや外部キーが増える以外はクラス図とほぼ同じ書き方。 RDBを設計するときによく使われる図。

f:id:DTM3110:20191027121024p:plain

PlantUML記述例

@startuml
class エンジニア {
 # ID
 - 名前
 - スキル
 - 生年月日
 - 給料
}
class PM {
 # ID
 - 名前
 - 生年月日
 - 給料
}
class 開発部 {
 # PM_ID (FK)
 # ID
 + プロジェクト予算
 + 参加人数
}
class 開発部ーエンジニア {
 # ID
 # エンジニア_ID (FK)
 # 開発部_ID (FK)
}

PM "1" --* "多" 開発部
エンジニア "1" --* "多" 開発部ーエンジニア
開発部ーエンジニア "多" *--* "多" 開発部

@enduml

CURD図

データの操作に着目して機能を洗い出すときに用いるUML。
マトリックス形式で記述できれば何でもOK。
「このデータって更新できないんだっけ？」や「このデータの削除ってどうやってやるんだっけ？」みたいなことを確認できる。

例)

	ユーザー情報
ユーザー登録	C
ユーザー一覧	R
ユーザー情報詳細	R,U
ユーザー情報削除	D

データフロー図

データの入出力や流れを可視化する図
外部実体、データストア、プロセス、データフローという4つの要素から記述される。
要素の表現方法は、派閥によって2つある。(Yourdon & DeMarco記法 VS Gane & Sarson記法)

※ Yourdon & DeMarco：YD
※ Gane & Sarson：GS

要素	説明	YD	GS
データフロー	データの流れを示す矢印とその要因
プロセス	データを書き換えるような処理を実施する行動(動作)
外部実体	対象(システム)に関連する自分以外の対象
データストア	データの永続的な保存先 DBやデータレイク等

DFD *5

シーケンス図

クラスやオブジェクト間のやり取りを時間軸ごとに表現するUML
バケツリレーみたいに、何がどうするのかがわかる。

sample

f:id:DTM3110:20191027150418p:plain

PlantUML記述例

@startuml
skinparam Shadowing false

autonumber

actor 顧客 #Cyan
actor 営業 #Cyan
actor 顧客管理システム #Blue
database 顧客管理DB #Green
actor 営業課長 #Cyan
actor 部長 #Cyan
actor 法務 #Cyan

営業 -> 顧客 : 売り込み
顧客 -> 営業 : 契約申請
営業 -> 顧客管理システム : システム入力
顧客管理システム -> 顧客管理DB : 顧客登録
顧客管理システム -> 営業課長 : 新規申請通知
営業課長 -> 部長 : 承認申請
部長 -> 法務 : 法務チェック申請
法務 -> 顧客管理システム : 申請許可入力
顧客管理システム -> 顧客管理DB : データ更新
顧客管理システム -> 部長 : 承認通知
顧客管理システム -> 営業課長 : 承認通知
顧客管理システム -> 営業 : 承認通知
営業 -> 顧客 : 契約完了通知

@enduml

コンポーネント図

複数のクラスで構成される挙動を、コンポーネントという1つにまとめて、1つのクラスのように取り扱うための表現。

f:id:DTM3110:20191027155759p:plain

PlantUML記述例

@startuml

skinparam Shadowing false

package ログイン機能 {
  [ログイン情報入力コンポーネント] - [ログイン情報検証コンポーネント]
}

cloud {
  [ユーザー情報取得API]
}

database UserDB

[ログイン情報検証コンポーネント] --> [ユーザー情報取得API]
[ユーザー情報取得API] --> UserDB

@enduml

第3章: PlantUMLとは？

テキストベースで記述した様々な図を生成するツール。
前章で、PlantUML記述例というところに書かれているものがPlantUMLでの記法になります。
公式サイトは、英・独・西・仏・日・韓・露・中の8カ国語分のドキュメントが用意されています。
ただ、ドキュメントがあまり詳しくないので、Ashley Engelund氏が個人でドキュメント(Ashley's PlantUML Doc)を作っています。(前回ご紹介したドキュメントはこちらになります。)
こちらのドキュメントは、メチャチャ詳しく細かくPlantUMLに関して記載してありますので、英語の読解に自身のある方はこちらを見てみるのも良いかもしれません。

PlantUMLを使うメリット

PlantUMLのメリットは色々ありますが、一番メリットが大きいのは、一番最後のMarkdownの中に挿入できるものが増えてきた点です。 f:id:DTM3110:20191027183251p:plain *6
例えば、システムを開発する際にそのドキュメントをMarkdownでReadMeとして記述することが多々あるかと思います。
その際に問題になってくるのが、UMLなどの画像ファイルを更新したい場合の対応です。
Markdownファイル上で画像を記述できるということは、画像ファイルのもととなるツールのダウンロードや、画像自体の元ファイルの管理などをする必要がなくなるということと同義です。
つまり、UMLを共同で編集する場合や、共同で確認・更新するという作業をする点で、準備をする必要がないため、すぐに変更したり共有したりすることができます。

PlantUMLを使うデメリット

前節ではメリットを熱く書き連ねましたが、もちろんデメリットも存在します。
中でも一番大きなデメリットは、ローカルでの環境構築が少し面倒という点です。
Onlineで書くことができるツール・サービスが増えてきていますが、やはりローカル環境で記述してローカルで確認したいということも多いでしょう。
いろいろな方法がありますが、今回はMacユーザの私が活用している、Atomエディター内で編集と表示確認をする方法をご紹介します。

第4章: PlantUML on Atomの環境構築 for Mac

環境・ツール	バージョン
	10.11.6
	v2.1.15
Atom	v1.25.1
	v2.6.2

Homebrewの準備
1. Homebrewの公式サイトに従って、Homebrewをダウンロード
Atomの準備
1. Atomの公式サイトからダウンロード
PlantUMLのダウンロード
1. PlantUML公式のダウンロードページから、最新のplantuml.jarを任意の場所にダウンロード
  例) /Users/(hatena)/Documents/plantuml.jar
描画機能のダウンロード
1. brew install graphvizを実行
2. 上記実行ができない場合があるので、その場合はMacPortsの指定環境をダウンロード
Atomパッケージ追加
1. Atomを開き、ツールバーから Atom→Prefarencesを選択
2. サイドバーからInstallを選択
3. 検索窓でlanguage-plantumlとplantuml-viewerを探し、インストール
plantuml-viewer設定
1. サイドバーからPackagesを選択し、plantuml-viewerを検索
2. plantuml-viewerのsettingを選択
3. PlantUML JARの項目のところに、ダウンロードしてきたplantuml.jarを指定(/Users/(hatena)/Documents/plantuml.jar)
使ってみる
1. 新しくファイルを作成し、PlantUMLを記述
2. ctrl-alt-pを実施するとVuewerが表示される

最終章: おわりに

今回もだいぶ長文になってしまいましたが、ご覧頂きありがとうございます。
環境構築の方法などはいろいろな方がブログや記事にしていたりしますので、いろいろ探しながら試してみるとよいかと思います。
またUMLに関してですが、UMLの書き方にも派閥のようなものがあったりするので、私の説明したものが利用したい環境の使い方と違う可能性はありますのでご注意ください。
次回、PlantUML集最終回です。
やっと図を書き始めます。
なんか僕がやりたかったことをもうQiitaで書いてる方がいて、心が折れそうですが、めげずに最後まで書ききろうかと思います。ではでは、また次回。

お知らせ

下記イベントで登壇することになりました。

abeja-innovation-meetup.connpass.com