見出し画像

mermaidチート表

あちこち調べまわるのに疲れたので自分用に作成します。
(7/10更新[途中上げ)


mermaidとは

md(マークダウン)形式の時、図が描けるやつ(ざっくり)

githubがこれに対応したので、readme.mdが画期的になったとかなんとか。


左に打ち込んだコードが右みたいな図になる


mermaidの導入

VScodeの拡張機能ですべて済む。

Markdown Preview Mermaid

最低限これだけあればおk。
Markdown Preview Enhancedも加えるとGithubとかmermaid公式の色合いになるぞ。


書き方

.mdに書くのが前提。

```mermaid

【この間に書く】

```

`(Shift+@)で上のように囲むとその間だけその言語対応になる。

場合から使い分けるmermaid

いくつか種類があるので、使い分けに。

なお、

```mermaid
```

は省略する。



手順を描きたい

Flowcharts - Basic Syntax#

---
title: Node
---
flowchart LR
    id

今のところ一番バラエティ豊かで、特殊な知識がなくても理解しやすい。

$$
\def\arraystretch{1.5}
\begin{array}{c:l}
呼び出し & flowchart \\ \hline
ウィズテキスト & id1[This is the text in the box] \\ \hline
矢印の左右反転使用 & できる \\ \hline
矢印を両方に向ける & できる \\ \hline
矢印の見た目 & たくさん  \\ \hline
矢印にコメント & できる(複数) \\ \hline
矢印の長さ & 3段階  \\ \hline
向き & サブグラフ毎で可能  \\ \hline
表示位置の指定 & できない  \\ \hline
ノード変形 & たくさん \\ \hline
ノードの中にノード & 可能 \\ \hline
ノードにコメント & できない  \\ \hline
ノードの色を変更 & 可能(直orCSS)  \\ \hline
線の色を変更 & 可能(直orCSS)  \\ \hline
曲線を変更 & 可能  \\ \hline
メモ(付箋) & できない  \\ \hline
コメントアウト & 【\%\% hoge】  \\ \hline
fontawesome & 使用できる(V4 fa:) \\ \hline
リンクを繋げる & できる(URLのみ) \\ \end{array}
$$

一番思い通りにできて、完成形を描きながら打ち込む使い方。
fontawesomeを取り入れたいときや、GUI的な手順を描きたいときに重宝。
ただし、他と違って付箋が使えないのと、ノード自体に情報を書き加えることができない。

矢印

コードを左右反転に書いても機能します。

flowchart LR
    A --> B
    C --- D
    E -.-> F
    G ==> H
    I ~~~ J --> 拡張機能によっては使用できない
    K --o L
    M --x N
Markdown Preview Enhanced
を入れると~~~は使えなくなる。
つまりgithubでは使えない。

矢印コメント

矢印の間に文字列を書くか、矢印の直後に| |(Shift+\)で囲んで文字列を書きます。
矢印の間は半角スペースを空けても書けます。
真ん中に書けないものは| | で書くしか方法がないです。

flowchart LR
    A --あ--> B
    C --い--- D
    E -.う.-> F
    G ==え==> H
    I ~~~|お| J --> 拡張機能によっては使用できない
    K --か--o L
    M --き--x N

矢印の長さ

flowchart LR
    O -->|1|P
    O' --->|2| P'
    O'' ---->|3| P''
    Q ---|4| R
    Q' ----|5| R'
    Q'' -----|6| R''
入力順と関係なく長さで表示順が切り替わる

$$
\def\arraystretch{1.5}
\begin{array}{l:c:c:c}
Length & 1 & 2 & 3 \\ \hdashline
Normal & --- & ---- & -----\\ \hline
Normal with arrow & --> & ---> & ---->\\ \hline
Thick & === & ==== & =====\\ \hline
Thick with arrow & ==> & ===> & ====>\\ \hline
Dotted & -.- & -..- & -…-\\ \hline
Dotted with arrow & -.-> & -..-> & -…->\\ \end{array}
$$

向き

全体的な向き

flowchart LR

TB(TD) ,RL , BT , LRの4方向。
上の「LR」のところを書き換える。

サブグラフ内の向き

flowchart
subgraph A
    direction TB
 a --> b
end
subgraph B
    direction BT
c --> d
end

direction でその中だけの方向を変更する。

全体的な向きの優先度は下がる

ノードの変形とウィズテキスト

flowchart 

A
B[A]
C[[A]]
D[\A\]
E[/A/]
F[/A\]
G[\A/]
H(A)
I((A))
J(((A)))
L[(A)]
L{A}
M{{A}}
N>A]
この形にできる。
好きに使え。

ウィズテキストの使い道として、ノードの表示は長文、コードの記入は短文にしたいというのが主な使い方だが

flowchart

A --> A
自分自身に向けられる
flowchart LR

B[A]
C[A]

B --> C
A→A

このように、コードが違えば見た目は同じでも構わないのでこのような表示で書くことができる。

ノードの中にノード

flowchart 

subgraph サブグラフ
    サブグラフのサブグラフ
    B
end

subgraph サブグラフのサブグラフ
    何重にもできるよ --> A
    何重にもできるよ --> B
end
何重にもできるよ --> E
サブグラフのサブグラフ -->C
サブグラフ --> D

subgraph hoge ~~ end で囲むとそれがグループになります。
どこからでも矢印は伸ばせるけど、癖があるので実際やってみるとわかる。

文字のラップ

`(Shift+@)で囲むとそこがマークダウン文字列として認識されます。
ノードを定義するときにA["` hoge `"]で適用されます。

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
a("`The **cat**
  in the hat`")
b{{"`The **dog** in the hog`"}}
c("`The *cat*
in the hat`")
d("The dog in the hog")

subgraph "*One*"
  a -- "`edge label`" --> b
end

subgraph "`**Two**`"
  c -- "`Bold **edge label**`" --> d
end
マークダウン文字列内だと改行したものは改行したまま表示、
空白がある場合は空白として表示
*で囲むと斜体
**で囲むと太字
ノード、線、サブグラフに適用

今のとこ、サブグラフの太字は機能してないです。

Markdown Preview Enhancedで一部無効化になる機能です。

文字の太さ、斜体が無効化されている。
改行と空白はOK。



フローチャートというもののルール

暗黙のルールがあります。
まあわかりやすければ何でもいいと思いますけど。
とりあえずノードのよく使われる意味合いと線の意味。

flowchart 

A(開始)
B(終了)
処理1
C[処理2]
D{判断}
E[処理2-2]
F{{準備}}
G1[/外部データ<上にあると入力>/]
G2[/外部データ<下にあると出力>/]
H[[定義<マクロ>]]
I[(データベース)]
J1((結合子A))
J2((結合子A'))
K1[/ループ開始\]
K2[\ループ終了条件式/]

A --> F
F --> K1
K1 --> 処理1
処理1 --> D
D --> E & G1
E --> H
G1 --> C --> G2
G2 & H --> K2 --> B

H -.- J1
J2 --> マクロ内容開始 --- I --- マクロ内容終了 --> J2
flowchart 

a[\特にない\]
b(((特にない)))
c{{特にない}}
d>特にない]

subgraph 線の意味
    ん --> |手順の流れを表す|を
    わ --- |流れが見てわかる場合はこっちでもいい|end

subgraph 特にないグループ
    a
    b
    c
    d
    あ -.-|特にない線| い
    う -.->|特にない矢印| え
    お --x |特にない| か
    き --o |特にない|end

なお、宗教によって〇が結合子だったり、磁気テープ、順次アクセス可など意味が変わったりします。悩んだら上司に聞け。


fontawesome

flowchart LR

A[fa:fa-gear 歯車]
B[1 fa:fa-plus 1 fa:fa-minus 5]

これの表示にはMarkdown Preview Enhancedが必須です。
また、表示できるアイコンは、デフォでは【fa fa-hoge】のみ。つまり、バージョン5未満のアイコンだけです。fasとかfalとかダメ。

---
title: 使用手順
---
flowchart 
A[fa:fa-search 英語で検索]
B[6.4.0 fa:fa-arrow-down]
C[5.15.4 fa:fa-arrow-down]

subgraph https://fontawesome.com/
    icons
end
icons --> A --> B
subgraph 検索一覧ページ
    B ==>|変更| C
    C --> fa:から始まるものを探す
end
こんな感じ。

対応していないV5以降を表示する

MarkdownPreviewMermeidSupportのsetting.jsonを書き換えます。
これをするとMarkdown Preview Enhancedがなくても表示可能です。

Using custom CSS in the Markdown Preview

You can use the built-in functionality to add custom CSS. More info can be found in the markdown.styles documentation

導入している拡張機能一覧から
MarkdownPreviewMermeidSupportの歯車マークから
拡張機能の設定を選択
「setting.jsonで編集」を開く
// {
//     "workbench.colorTheme": "Default Dark+",
//     "files.autoGuessEncoding": true,
//     "window.zoomLevel": -1, <-これは人によってあったりなかったり
//     "markdown-mermaid.languages": [

//         "mermaid"
        
//     ]
// }


//ここから下を記入↓

{
    "markdown.styles": [
        "https://use.fontawesome.com/releases/v5.7.1/css/all.css"
    ],
    "markdown-mermaid.languages": [
        
        "mermaid"
    ]
    
  }
元々書かれていたコードを上書きあるいは//でコメントアウトにして
上のコードを入力。おわり。
```mermaid
flowchart LR
    fa:fa-check-->fa:fa-coffee
```
書き換え前 → 書き換え後

終わり。
ただし、githubでこれが対応済みかは未検証。

色を変更する

紹介されてる1つの「事前にcssを読み込んで変更する方法」は効果がありませんでした。多分、上記のsetting.jsonに参照cssを増やすんだと思いますが。

クラスに直接書き込む

flowchart LR
    
    style A fill:#f9f,stroke:#333,stroke-width:4px;
A自体に直接書き込んだ

CSSクラスを定義して適用する

    classDef cssClass fill:#f9f,stroke:#333,stroke-width:4px;
    
    A

    class A cssClass
    %%適用するときはノードが表示されてから
cssClassという定義を作って適用した。
    classDef cssClass fill:#f9f,stroke:#333,stroke-width:4px;
    
    A:::cssClass

この短縮コードでも同じ結果。
同じ内容を別ノードにも与える場合に便利ですね。

 classDef cssClass color:red;
    
    style A fill:#f9f,stroke:#333,stroke-width:4px;

    class A cssClass

CSSと同じく、特定のプロパティを上書きして扱うことも可能

後から適用したcolor:red
で文字が赤くなる

全てに適用する

flowchart LR
    classDef default fill:#f9f,stroke:#333,stroke-width:4px;

A ~~~ B ~~~ C ~~~ D
cssClassを「default」にすると全てのノードに適用。

線の色を変える

flowchart LR

   A -- text --> B -- text2 --> C

linkStyle 0 stroke:#ff3,stroke-width:4px,color:red;
linkStyle 1 stroke:#ff,stroke-width:4px,color:blue;

線にはIDがないので、何番目に使われた線なのかで指定します。
0から数えます。1番目は0,2番目は1です。
これも同じく、数字を「default」にすると全てに適用されます。

線の形を変える

%%{ init: { 'flowchart': { 'curve': 'stepBefore' } } }%%

graph LR
a --> b --> a

UML宣言の前に%% %%で一時的にinitを変更します。
曲線の形を変更できます。
ただし、全体適用で一部の線のみを変更することはできません。
上記の例の'stepBefore'を書き換えることで以下の種類の変更ができます。

%%{ init: { 'flowchart': { 'curve': '【ここ書き換え】' } } }%%

graph LR
a --> b --> c --> d --> a
b ----> e
e --> f --> g --> e
g --> h --> g

a -----> z --> a
basis, bumpX, bumpY,
cardinal, catmullRom, linear,
monotoneX, monotoneY, natural,
step, stepAfter, stepBefore

それぞれの詳細はここから


ノードにリンクを付ける

flowchart LR
    A-->B
    B-->C
    C-->D
    click A callback "Tooltip for a callback"
    click B "https://www.github.com" "This is a tooltip for a link"
    click A call callback() "Tooltip for a callback"
    click B href "https://www.github.com" "This is a tooltip for a link"
Bをクリックすると外部リンクに飛ぶ
” ”で囲んだ部分はマウスオーバーすると表示される文。

書き方はそれぞれ2種類でどっちでもいいです。
Aは事前読込しておいたJSの関数を発動させる仕組みですが、VScodeのmd環境だと発動しませんでした。
BはURLのみで、パスで内部ファイルにアクセスはできません。

flowchart LR
    A-->B-->C-->D
    
    click A "https://www.github.com" _self
    click B "https://www.github.com" "Open this in a new tab" _blank
    click C href "https://www.github.com" _parent
    click D href "https://www.github.com" "Open this in a new tab" _top

最後に_self や _blank を付けることでリンク表示方法を変更できます。
ただし、VScodeから開く場合はどれも既存のブラウザのblankになります。

TARGET="_top" 分割を廃止して1枚で表示
TARGET="_blank" 新たにブラウザを立ち上げて表示
TARGET="_self" クリックしたウィンドウに表示
TARGET="_parent" 親フレームに表示

http://www.interq.or.jp/japan/webhouse/html/tip08_a.html


Markdown Preview Enhanced

これを入れると

A ~~~ B

の表記が使えなくなります。
fontawesomeを使うには入れる必要があります。(json書き換えの場合は✖)
fontawesomeV5以降は表示されません。
マークダウン文字列(`)で*を使った表現が無効化されます。
今後のアップデートで変わる可能性はあります。(23.4.24現在)



時系列且つ人物に焦点を当てた図を描きたい

Sequence diagrams

---
title: Node
---
sequenceDiagram
autonumber

actor Alice

    Alice->>John: Hello John, how are you?
    John-->>Alice: Great!
    Alice-)John: See you later!

人物(または物)を横軸に、時間を縦軸に表示する。
手順の順番が重要な場合に。また、自動で手順番号の割り振りもできる。

$$
\def\arraystretch{1.5}
\begin{array}{c:l}
呼び出し & sequenceDiagram \\ \hline
ウィズテキスト & participant\ A\ as\ Alice \\ \hline
矢印の左右反転使用 & できない \\ \hline
矢印を両方に向ける &できない \\ \hline
矢印の見た目 & 実線or点線  \\ \hline
矢印にコメント & 必須 \\ \hline
矢印の長さ & 選べない  \\ \hline
向き & できない  \\ \hline
表示位置の指定 & 宣言順に左  \\ \hline
ノード変形 & participant\ or\ actor \\ \hline
ノードの中にノード & できない \\ \hline
ノードにコメント & できる  \\ \hline
ノードの色を変更 & 可能(直orCSS)  \\ \hline
メモ(付箋) & できる  \\ \hline
コメントアウト & 【\%\% hoge】  \\ \hline
fontawesome & できない  \\ \hline
リンクを繋げる & できる \\ \end{array}
$$

時系列が最優先で、付箋も時系列の表に収まるように配置される。
複数の人やモノが関わる作業で、無駄の洗い出しや、全体的な理解をさせたい場合に利用することが多い。
縦軸横軸固定なので、自由度は少ない。

宣言

必須。

autonumber

actor Alice
participant B as 帽子屋
人型かそれ以外

また、後ろにasを付けて名乗ることで、ウィズテキストで宣言可能。
これは「役割」が入ることが多いです。
人型(actor)はシステムの外部に存在、あるいは相互作用がある役割に使われます。

行動順番を数える

sequenceDiagram
autonumber %%これを付けるだけ

actor Alice
participant B as 帽子屋

矢印+コメント

---
title: Node
---
sequenceDiagram
autonumber %%これを付けるだけ

actor Alice
participant B as 帽子屋

Alice -> B : 実線
Alice ->> B : 矢印実線
Alice --> B : 点線
Alice -->> B : 矢印点線
Alice -x B : 終わりに✖
Alice --x B : 点線終わりに✖
Alice -) B : 開いた矢印実線
Alice --) B : 開いた矢印点線

矢印の後に、:【コメント】が必須です。
UML(シーケンス図)という書き方なので、それぞれの矢印には意味があります。

実線は始点から送る場合に使用します。
点線は実線の返事に使用します。
黒つぶし矢印は同期を表し、開いた矢印は非同期を表します。
✖は消滅を意味します。

同機…送信側が受信側のアクションを待つ
非同期…受信側のアクションを待たない

表にまとめるとこうなります。

$$
\def\arraystretch{1.5}
\begin{array}{c:c:c}
 & 実線 & 点線  \\ \hline
▲ & 送信(同期) & 返信(同期)  \\ \hline
> & 送信(非同期) & 返信(非同期) \\ \hline
✖ & 送り先が消滅 & 戻り先が消滅 \\ \hline
 & 特になし & 特になし \\ \end{array}
$$

つまりこう

---
title: Node
---
sequenceDiagram
autonumber %%これを付けるだけ

actor Alice
participant B as 白うさぎの家

Alice -> B : 家破壊RTA開始
Alice ->> B : 手袋を探しに家に入る
B -->> Alice : 部屋データを返す

Alice -) B : 落ちてたクッキー食べる
Alice -x B : 巨大化そして破壊

Alice --> B : 家破壊RTA終了
実線と点線は多分相互に使うんだろうなと思いつつ

付箋をつける

書き込んだ順番の高さに付箋が入ります。

---
title: Node
---
sequenceDiagram
autonumber %%これを付けるだけ

actor Alice
participant B as 白うさぎの家

Alice -> B : 家破壊RTA開始
Alice ->> B : 手袋を探しに家に入る
B -->> Alice : 部屋データを返す

Alice -) B : 落ちてたクッキー食べる
Alice -x B : 巨大化そして破壊

Alice --> B : 家破壊RTA終了

note over Alice,B : 白兎はそれを化け物といい、家に火を付けました
note left of Alice : 畑の人参で元の大きさに戻りました。

縦軸の人物たちの上(over)または右か左(right of , left of)の位置に付箋を表示させます。
なお、<br>で改行できます。

背景色を変更

rect rgb() || rgba() ~ end で囲んだところの背景色が変わります。
文字色は変わりません。文字色はCSSで変えます
ただしVScode環境ではCSSの適応がbody以外できません。

sequenceDiagram
autonumber %%これを付けるだけ

actor Alice
participant B as 白うさぎの家

rect rgba(200, 150, 255,0.5)
    rect rgb(191, 223, 255)
        Alice -> B : 家破壊RTA開始
    end
    Alice ->> B : 手袋を探しに家に入る
    B -->> Alice : 部屋データを返す

    Alice -) B : 落ちてたクッキー食べる
    Alice -x B : 巨大化そして破壊

    Alice --> B : 家破壊RTA終了
end


リンクを付ける

Markdown Preview Enhancedが必要です。
Actorの上をマウスオーバーすると、リンク集が出ます。

---
title: Node
---
sequenceDiagram
    participant Alice
    participant John
    link Alice: Dashboard @ https://dashboard.contoso.com/alice
    link Alice: Wiki @ https://wiki.contoso.com/alice
    link John: Dashboard @ https://dashboard.contoso.com/john
    link John: Wiki @ https://wiki.contoso.com/john
    Alice->>John: Hello John, how are you?
    John-->>Alice: Great!
    Alice-)John: See you later!

シーケンス図特有のその他

他ではないし、勉強しないとわからん奴らです。
専門用語でフラグメントといいます。


Loopsあとbreak

繰り返し処理です。

sequenceDiagram
autonumber %%これを付けるだけ

actor A as ほむら
participant B as 世界

A --> B : 30日前
loop 1,∞
    A ->> B : 色々やる
    break ワルプルギスの夜
        B --> A :ゴッドまどか覚醒
    end
    B --) A : まどか死亡
end

loop~endで囲んだ部分がloopsになります。
loop 【開始,終了】 が書けます。
breakはloopに限った使い方ではないですが、フラグメントから終了条件を満たさずに脱出するときに書きます。
break~endで囲んだ中に、中断するときの処理を必ず書きます。付箋でも大丈夫です。

altとopt

分岐処理です。altはオルタナティブの略。optはオプションの略。
altはelseがある場合、optはない場合に使用します。

IF文に置き換えると

【 alt 】
if(条件){
A;
}else{
B;
};

【 opt 】
if(条件)A;

altは条件を満たさなくても必ずelseを実行するのに対し、
optは条件を満たさなければ何も起こりません。

sequenceDiagram
autonumber %%これを付けるだけ

actor A as ほむら
actor M as マミ
actor S as さやか
participant B as 世界

alt ソウルジェムが濁る
    M --) A :お前が悪いのか
    S ->> A : ほんとバカ
else 濁らない
    M --) A :指南役
    S ->> A : ほんとバカ
end
opt 油断する
    M --) M :マミる
end

Parallel

並行処理です。パラレル。

sequenceDiagram
autonumber %%これを付けるだけ

actor A as ほむら
actor M as マミ
actor S as さやか
participant B as 世界

par 時間停止中

        A ->> B:弾丸調達

    and 仲間集め

        A ->> M :交渉

    and 邪魔者排除

        A ->> S : 帰れ
end
同時にいろんなことが発生する場合に。

par~endで囲んだ中にand を入れると平行な項目が増やせます。

Critical Region#

排他処理です。別枠とか閉鎖空間とかそんな感じ。影響を受けません。

sequenceDiagram
autonumber %%これを付けるだけ

actor A as ほむら
actor C as まどか
actor M as マミ
actor S as さやか

par 通信
C ->> M : 報告
C ->> S : 連絡
end
critical
    C ->> A : まどほむ
 option ほむまど
    A ->> C : 
end

 M --) C : やっと連絡取れた
 S --) C : ほんとバカ

特定の行動や場所にいるときは携帯の電源をOFFにしておく
みたいな。
criticalは致命的という意味で、致命的な状況から保護するみたいな感じ。

Activations

実行状態を表します。受信したものに返信するまでの時間

---
title: Node
---
sequenceDiagram
    participant Alice
    participant John

%% activate actor ~ deactivate actor が基本形
    Alice->>John: Hello John, how are you?
    activate John
        John-->>Alice: Great!
    deactivate John

%% +が始まり、-が終わりというショトカ。コメントと同時に発生できる。
    Alice ->> + John: Hello John, how are you?
    John -->> - Alice: Great!

%%入れ子状に重ねることも可能
    Alice->> + John: Hello John, how are you?
        Alice->> + John: John, can you hear me?
        John-->> - Alice: Hi Alice, I can hear you!
    John-->> - Alice: I feel great!
縦軸についてる■がそれ。


関係性を描きたい

Class diagrams

---
title: Animal example
---
classDiagram
    note "From Duck till Zebra"
    Animal <|-- Duck
    note for Duck "can fly\ncan swim\ncan dive\ncan help in debugging"
    Animal <|-- Fish
    Animal <|-- Zebra
    Animal : +int age
    Animal : +String gender
    Animal: +isMammal()
    Animal: +mate()
    class Duck{
        +String beakColor
        +swim()
        +quack()
    }
    class Fish{
        -int sizeInFeet
        -canEat()
    }
    class Zebra{
        +bool is_wild
        +run()
    }

物体Aと物体B、物体C…それぞれの上下関係を入力することで整理された関係図が出力されます。
これの場合、物体Aからみた物体Bとの関係性、物体Aからみた物体Cとの関係性といった、物体1つからどこに繋がるかが重要視されています。

$$
\def\arraystretch{1.5}
\begin{array}{c:l}
呼び出し & classDiagram \\ \hline
ウィズテキスト & class\ A["text"]  \\ \hline
矢印の左右反転使用 & できない(意味が変わる) \\ \hline
矢印を両方に向ける &できる \\ \hline
矢印の見た目 & たくさん  \\ \hline
矢印にコメント & 可能 \\ \hline
矢印の長さ & 選べない  \\ \hline
向き & direction RL   \\ \hline
表示位置の指定 & できない  \\ \hline
ノード変形 & できない \\ \hline
ノードの中にノード & できない \\ \hline
ノードにコメント & できる  \\ \hline
ノードの色を変更 & 可能(直orCSS)  \\ \hline
メモ(付箋) & できる  \\ \hline
コメントアウト & 【\%\% hoge】  \\ \hline
fontawesome & できない  \\ \hline
リンクを繋げる & できない \\ \end{array}
$$

データフォルダの繋がりの確認に使用してます。どこにリンクつなげたかとか、どこでどの変数を定義したかとか。自分で配置の制御が一切できないので、これが見やすくなることがプロジェクトがわかりやすくなるのに繋がるんじゃないかと考えています。
(Flowchartsと同じく、クラス ダイアグラムの既存のマークアップの制限でcssの加工ができません。近日修正予定らしい。)(23年5月2日現在)

クラス図というものの書き方

このUMLはクラス図を書くために使われます。
つまり、システムの関係図を書きます。

主にクラスとは
1.それの名前
2.それの型(種類)
3.それの機能
の3つで表します。これらをメンバーという名で区切ってます。

まったく違うけど考え方としては、

alert("おはよー!")

が書かれた目覚まし.txtデータ」を表すには

1.目覚まし
2.txt
3.alertとその中身

となります。
「この目覚まし.txtが、何かのボタンを押したら発生する」という関係性を描く場合

力の流れを矢印で表す

こうなります。

classDiagram
  direction LR

    class 目覚まし{
        .txt
        + str alert("おはよー!")
    }
    class index {
        .html
        + bool btn1(true)
    }
    目覚まし ..|> index : btn1(true)

クラス名=クラス名、
()がない行=型
()がある行=性能
でそれぞれ線が引かれます。

クラス宣言

基本の形

classDiagram
    class 目覚まし

マークダウン文字列でも

classDiagram
    class `目覚ま し`
スペースとか!とか対応できる

宣言しながら中身を描く1

classDiagram
    class 目覚まし
    目覚まし : .txt
    目覚まし : + str alert("おはよー!")

宣言しながら中身を描く2

classDiagram
    class 目覚まし {
        .txt
        + str alert("おはよー!")
    }
最終出力は一緒

これはクラス名が同じであれば後から宣言内容を追加することができます。

クラスラベル

ウィズテキストと大体同じ。

classDiagram
    class A["目覚まし"]
同じ名前のクラス名は統合されるが、
クラスラベルで別クラスを同じ名前で表示させることができる。

ただし、Markdown Preview Enhanced を使うとエラーになります。(23年5月2日現在)
githubでは使えないということです。

メンバー

3.の機能について深堀。
機能とひとまとめにしたけど正確にはメソッド、関数、定義を記述する。

クラスの内容により表すことが変わるので記入方法。

リターン型の宣言

そのクラスの関数が返す型を記述します。

classDiagram
class 目覚まし {
    .txt
    + alert("おはよー!") str
    # btn1(true) bool
}
記述の後ろに半角スペースの後に返し値の型を記載する

汎用型の宣言

引数の型が異なっていても返し値は特定の型で返すものもあれば、
引数の型と関数が受け入れる型が同じでないと関数が働かないものなどあります。
(例)0は数字(int)、文字列(str)、成否(bool)いずれにも当てはまります。
その時、入れる型、受け入れる型、出力する型をそれぞれ記載します。

classDiagram
class 目覚まし{
    メッセージ~str~
    + alert(~str~メッセージ) str
}
~(チルド)で囲むとどこでも型の宣言が行えます。
List~List~int~~といった入れ子にも対応

可視性

メンバーが他のクラスからどのように見えるかを表す4種。
+,-,#,~。

パッケージ=それ独立で機能を果たせる範囲
アプリケーションとか。

$$
\def\arraystretch{1.5}
\begin{array}{c:c:l}
可視性 & 意味 & 効果 \\ \hline
+ & public & パッケージ外でも使える \\ \hline
- & private & そのクラス内のみ使える \\ \hline
\# & protected  & 親子関係同士のクラス両方\\ \hline
\~\ & package & パッケージ内ならどこでも使える \\ \end{array}
$$

どこまでそれを呼び出すことができるか、という感じ。
ユーザーに入力させるなら+、
一時変数なら-、
値を継承するなら#、
汎用的な関数なら~。

それぞれのメンバーの最初に記入する。

classDiagram
class A{
    + Userform() str
    - hoge~byte~
    # userdata~str~
    ~ style~data~
}

矢印とラベル

クラス図における矢印の意味があります。
クラスAとBの関係性により決まった矢印で表します。

classDiagram
  direction LR

class A["動物"]{
    # 名前
    # 鳴く()
}
class B["犬"]{
    - 品種
    + 犬情報取得()
}
class C["バス"]{
    - バス会社名
    - 乗員数
    + バス情報取得()
}
class D["タイヤ"]{
    - 型番
    - 利用開始日
    + タイヤ情報取得()
}
class E["乗員"]{
    - 名前
    - 年齢
    + 乗員情報取得()
}
class F["社員"]{
    - 社員番号
    - ユーザー情報
    + 社員情報取得()
}
class G["ユーザー"]{
    - 名前
    - 住所
    + ユーザー情報取得()
}
class J["ホイール"]{
    - 型番
    - 利用開始日
    + ホイール情報取得()
}
class L["犬"]{
    + 鳴く()
}
class M["動物"]{
    + 鳴く()
}
<<interface>> M


A <|-- B :Inheritance(継承・汎化)
C"1" *-- "4"J : Composition(構成要素)
C"1" o-- "0..n"E : Aggregation(集計・集約)
F"1" <--> "1"G : Association(関連)
E -- G : Link (Solid)(特になし)
D"1" ..> "1"J : Dependency(依存)
L ..|> M : Realization(実現)
A .. G : Link(Dot)(特になし)

$$
\def\arraystretch{1.5}
\begin{array}{c:c:c:l}
種類 & 和訳 & A<使用>B & 意味 \\ \hline
Inheritance & 継承・汎化 &  <|--  & Aの性質を継承したB(Aを前提として構成) \\ \hline
Composition & 構成要素 &  *--  & Aの構成にBは含まれている。Aが消えるとBも心中する \\ \hline
Aggregation & 集計・集約 & o-- & BはAの一部になりうるが、心中しない \\ \hline
Association & 関連 & <-- & AとBは関係するが、それぞれの構成要素ではない \\ \hline
Link (Solid) & - & -- & 特に意味を持たないが、Associationの代理使用もアリ  \\ \hline
Dependency & 依存 & <.. & 両依存であり、互いの変更に影響を受ける\\ \hline
Realization & 実現  & <|.. & A(インターフェース)を具体的に実装したのがB \\ \hline
Link(Dot) & - & ..& 特に意味を持たない。矢じりのない関係の使用  \\ \end{array}
$$

記号の後ろに : "コメント"
を付けることで、矢印自体にコメント(ラベル)を付けることができます。


両方向矢印

例えば…
AからみたBはCompositionだが、BからみたAはInheritanceという場合

classDiagram
    direction LR
    A <|--* B

両方の性質を1本にまとめた線を描くことができる。

多重度

書いても書かなくてもというとこではあるが。
それぞれの関係性の比率です。
車1台につきタイヤは4つ付いています。なので

classDiagram
    direction TB
    class A["車"]
    class B["タイヤ"]

    A"1" *-- "4"B
こう。

40人用バス1台につき乗客は何人乗れるのかということであれば

classDiagram
    direction TB
    class A["バス"]
    class B["乗客"]

    A"1" o-- "0..40"B
こう。

整数だが上限がわからないという場合は"0..n"
整数だが上限が無限大になるという場合は"0..*"
数が不明"n"、数が数えきれないほどある"*"

クラスに関する注釈

クラス自体にも種類がある。
例えばRealization(<..)の目標にできるのはinterfaceクラスのみ。(というルールなだけでエラーが起きるわけではない)

classDiagram
class A
<<interface>>A

class B
<<Abstract>>B

class C
<<service>>C

class D
<<Enumeration>>D

A .. B
C .. D

別の書き方

classDiagram
class A{
<<interface>>
}

class B{
<<Abstract>>
}

class C{
<<service>>
}

class D{
<<Enumeration>>
}

A .. B
C .. D
この4種
どちらも表示内容は同じ。
interface…これ単体で存在できず、Realization(<..)するサブクラスがいて初めて成立する。
サブクラスの共通部分を書く。
Abstract…抽象クラス。自身は機能を何も持たない。
このクラス1つをセレクタにして、
紐づけた他クラスを一気に呼び出すなど機能をまとめるクラス。
service…宗教により意味が変わる。
アンチパターンの記述場所、複数機能ごちゃまぜ、他のクラスには当てはまらない場合など。
Enumeration…列挙型。列挙子が含まれる場合に。ユーザー定義に使います。
全体において1つしかクラスが存在しません。


表示する向き

  direction RL

全体適用で4方向。TB,RL,BT,LR。

ノードにリンクを付ける

Flowchartsのとほぼ同じです。
同じく、javasctirptの関数を呼び出す能力がありますが、VScode環境だと無理です。

action className "reference" "tooltip"
click className call callback() "tooltip"
click className href "url" "tooltip"

いずれの3種類の書き方ができます。
1行目はactionを`callback`あるいは`link`にすることでそれぞれ2行目、3行目と同じ意味を持つようになります。

classDiagram
  direction LR
class A
class B
class C
class D

A -- B
C -- D

callback A "alert()" "tooltip"
link D "https://twitter.com/home" "オーバーの時出るやつ"
click B call callback() "tooltip"
click C href "url" "tooltip"
tooltipの部分はマウスオーバーの時に出る文字です。

クラスの宣言をした後にリンクかコールバックを記載します。

CSSで色を変更する

?> Due to limitations with existing markup for class diagrams, it is not currently possible to define css classes within the diagram itself. Coming soon!

提携しているソフトのアプデによる不具合で現在使えないみたいです。(23年5月3日現在)



始点と終点が一筆で収まる工程図を描きたい

State diagrams#

stateDiagram-v2
direction LR
[*]--> 卵
卵 --> 幼虫
幼虫 --> 脱皮
脱皮 --> 脱皮
脱皮 --> 蛹
蛹 --> 蝶
蝶 --> 死
死 --> [*]

卵 --> 死
幼虫 --> 死
脱皮 --> 死
蛹 --> 死

ステータス図(状態遷移図)。入口に水を灌ぐと、どこからも漏れずに、出口から排出されるみたいな構造の考え方。
フローチャートは複数の出口が考えられるが、これはどれだけ中で分岐しようが最後には1つの出口に収束していく。

完全変態と死

$$
\def\arraystretch{1.5}
\begin{array}{c:l}
呼び出し & stateDiagram-v2 \\ \hline
ウィズテキスト & A : hoge とか\\ \hline
矢印の左右反転使用 & できない \\ \hline
矢印を両方に向ける &できない \\ \hline
矢印の見た目 & 実線  \\ \hline
矢印にコメント & : hoge \\ \hline
矢印の長さ & 選べない  \\ \hline
向き & direction LR   \\ \hline
表示位置の指定 & できない  \\ \hline
ノード変形 & できない \\ \hline
ノードの中にノード & できる \\ \hline
ノードにコメント & できる  \\ \hline
ノードの色を変更 & 可能(直orCSS)  \\ \hline
メモ(付箋) & できる  \\ \hline
コメントアウト & 【\%\% hoge】  \\ \hline
fontawesome & できない  \\ \hline
リンクを繋げる & できない \\ \end{array}
$$

端的に言うと、スイッチを押して、どのような過程を経て結果が出力されるのか。その過程を書く奴です。入口と出口は同じ個所でなくてもいいので、変態を表すにも使います。
これはかなり単純でルールの縛りはほぼないです。


宣言

stateDiagram-v2
A
B
C
state A 宣言のショートハンド

矢印

stateDiagram-v2
A --> B
A --> C
Flowchartsのように
A --> B & C 
という書き方はできない。

ラベル

stateDiagram-v2

A : ラベル1 
state "ラベル2" as B 
出力は同じだが、ラベル2の書き方だと入れ子構造が作成できる。

入れ子

stateDiagram-v2

A : ラベル1

state A {
    中身
}

state "ラベル2" as B {
    中身'
}

state C {
    中身''
}
A:ラベルを先に宣言してから入れ子を作成
B:ラベルと同時に入れ子を作成
C:そのままでももちろん作成
ただし、同じステート名は使用できない(中身)(ラベルで同じならOK)
stateDiagram-v2

state D {
    d
}

state d {
    E
}

state E {
    e
}

%%一応ここまで短縮は可能
state e {F
    }
無限にマトリョーシカできる。
stateDiagram-v2
direction LR

    [*] --> First

    state First {
        [*] --> Second

        state Second {
            [*] --> second
            second --> Third

            state Third {
                [*] --> third
                third --> [*]
            }
        }
    }
始まりマークを結合子として利用できる。

矢印と始まりと終わりとコメント

stateDiagram-v2
direction LR

[*] --> [*]

[*] --> a

a --> [*] : コメント
左に書くと[*]は始まり
右に書くと[*]は終わり
矢印は --> のみ。
コメントは式に「 : hoge」 で記入

分岐

direction LR

    state C : 分岐
    state C <<choice>>

    [*] --> 議題
    議題 --> C
    C --> False: if n < 0
    C --> True : if n >= 0
ステート宣言時、<<choice>>で◇になる。
この時、state "hoge " as A の表記は使えない。

▶フォーク

フォークは分岐のうち、同じ方向を向いた分岐に使用します。
並列世界とかそんなイメージ。最終的に1つに統合される分岐です。

stateDiagram-v2
direction LR

state C <<choice>>

[*] --> C

C --> A
C --> B

state F <<fork>>

A --> F
F --> D
F --> D2
F --> D3

state F2 <<fork>>

D --> F2
D2 --> F2
D3 --> F2
F2 --> A2
A2 --> [*]
 
B --> [*]
分岐のchoiceと同じく、
ステート宣言の時に<<fork>>で属性を付ける。

付箋

ノードの右か左に付箋のようなメモをつけることができます。

stateDiagram-v2
direction LR

state "ゲ制開始" as A
state "日常" as B {
    起きる --> 食べる
    食べる --> 寝る
    寝る --> 起きる
    nte left of 食べる
        三食食べる
    end note
}
state "締め切り" as C

note right of A
    開始日:421日
end note
note left of C
    831日
end note

    A --> B
    B --> C
note rightまたはleft of ノードID ~ note end
で囲んだところが付箋内容。
入れ子の中身につける場合は入れ子の中に記入する必要あり。

同時進行

入れ子ステートの中で、分岐ではなく複数同時に進行してすべてができたら次のステートへ行く場合があります。

stateDiagram-v2
direction TB

state 材料作成 {
    パンを切る
    --
    肉を切る
    --
    野菜を切る
    --
    ソースを作る
}

[*] --> 準備
準備 --> 材料作成
材料作成 --> 合わせる
合わせる --> 細長く切る
細長く切る --> 盛る
盛る --> [*]
入れ子ステートを -- で区切ります。
サンドイッチの完成です。

表示する向き

  direction RL

全体適用で4方向。TB,RL,BT,LR。

ノード(ステート)の色を変える

現状のバージョンでは
・開始と終了に色は付けられない
・入れ子状態の外と中は色が付けられない
であり、今後利用可能になる予定らしいっす。

また、他のUMLと同じくCSSによる変更は提携先ソフトのアップデートで扱えなくなってます。(23年5月3日)

直接記入する方法のみ可能です。

1つのノードに適用する

stateDiagram-v2
direction LR
    classDef badBadEvent fill:#f00,color:white,font-weight:bold,stroke-width:2px,stroke:yellow

GAMEOVER :::badBadEvent
badBadEvent というclassDefの情報を付けた
スタイル名:badBadEvent
fill=ノードの色
color=文字の色
font-weight=文字の太さ(ほぼbold一択)
stroke-width=枠線の太さ
stroke=枠線の色
なお、色はwhiteとか色の名前でも対応。

2つ以上のノードに同じ適用をする

class A,B badBadEvent

B --> A
ただし、これより後に適用させたノードを表示させないといけない。

またCSS同様、後に適用させたclassDefのオプションに継承する。

stateDiagram-v2
direction LR
    classDef badBadEvent fill:#f00,color:white,font-weight:900,stroke-width:2px,stroke:yellow
        GAMEOVER :::badBadEvent

    class A,B badBadEvent

    GAMEOVER --> B
        B --> A
    classDef bluemountain fill:blue
        A ::: bluemountain
fillを青にしたが、他の設定は今までと一緒。

ラベルも付ける

 A ::: bluemountain
%%上の続き
A : 青山




作業で人物を振り分ける図を描きたい


User Journey Diagram#

例えば作業の報告用とか、グループ内の振り分けとか。
それ専用のアプリがあるぐらいなので本腰ならそっち使った方がいいかもだけど。

journey
    title My working day
    section Go to work
      Make tea: 5: Me
      Go upstairs: 3: Me
      Do work: 1: Me, Cat
    section Go home
      Go downstairs: 5: Me
      Sit down: 5: Me

これは、誰が、作業のどの段階で、どのような評価をしたか
を端的に表しています。右が未来の時系列順です。
拡張性は特になくて、これが全てです。

journey
    title 寿司の作り方
    section 準備
      材料:海苔、スモークサーモン、スシ飯、しょうゆ: 5: Me
    section 作り始める
      海苔でスシ飯とサーモンをやさしく巻いて……: 5: Me
    section ハプニング
        ちくしょう!だいなしにしやがった!: 3:Me
        このスシはお前の人生そのものだ。:2:Me
        お前はいつも失敗ばかりだ。 :2 :Me
        お前はいろんなことに手を付けるが、ひとつだってやり遂げられない。:1:Me
    section 膝抱え
        誰もお前を愛さない。 :0:Me


王道のユーザージャーニー図の使い方

一応本来の使い方のお勉強。
本来は人が挫折や落胆をする箇所を可視化して、それを改善するために使用されます。外からの意見をまとめるときに使うべきものです。

ペルソナを作成します。簡単に言うとキャラクターシートです。
そのキャラをRPしつつその動作を行い、チェックポイントでどのような評価を行ったかというのが具体的な作成方法です。

チェックポイントはテンプレートがあり、有名な買い物の例だと
「認知・興味」「情報収集・比較対象」「来店・試着」「購入」が大枠、
小枠にそのキャラがしそうな行動を書いて現状と比べます。
この横軸をステージと言います。

1人のペルソナに対し1枚のユーザージャーニー図を使用します。

journey
    title 新作の服を買うまで
    section 認知・興味
        テレビ、雑誌 : 6 
        インフルエンサー :8 : 広報
    section 情報収集・比較対象
        商品名を検索 : 5 
        購入方法の確認 : 5 : EC
        最安値を探す : 4 : EC
    section 来店・試着
        電車を乗り継ぐ : 3 
        最寄り駅から徒歩で到着 : 3 
        試着する : 5 : 店舗スタッフ
    section 購入
        お得サービスの紹介 : 5 : 店舗スタッフ,総務
        購入 : 6 : 店舗スタッフ
上の問題は、
購入者と実店舗の物理的距離が遠く
購入意欲が下がっているという問題がわかる。

と、上は理想的な想定しているユーザーの行動だが、実際はどうだろうか。
テレビや雑誌の情報は想定ユーザー(ペルソナ)が普段見ているものか?
ユーザーはそのインフルエンサーをフォローしているのか?
など、それぞれの列で不安・不満・不足を考えていく
最もうまく言った状態が躁状態として、鬱状態のときどうかなど。
もちろん1列1個でなくたくさんで良し。

洗い出したら優先順位をつけて解決していく。
優先順位が得意なUMLはこれ


弱点

これは単純で、おっさんがJKの行動のお気持ちを代弁できるだろうか?
というとこ。
なのでこの図は個人が作るのでなく、複数人様々な年代と性別の人が目を通して完成度を高める必要があります。
あと、考え方が古来なので古来のテンプレを使ってると現代社会に全く適用しない時代遅れになるのでテンプレを考え出す頭が必要です。

作り方

大体の場合、ユーザーインタビューを行ってするとこがほとんどな気がします。『調査目的に合致する人』を見つけ出して話を聞く。

そのインタビューから重要なところを抜き出して整理していくと
ユーザージャーニー図になるわけです。

As-Is、To-Be
現状(As-Is)と期待(To-Be)は根本は同じですが、それぞれ別紙に描きます。
As-Isは現状に対してユーザーが感じているネガティブと解決策
To-Beはユーザーの期待と、それを叶える提案
を描きます。

まあ、このMermaidにはこれらを書く場所はないですが。


参照

ちなこの中のカスタマージャーニーと、ユーザージャーニーは方言ぐらいの違いです。あんまないです。



問題定義とそれを解決する要素の図を描きたい

Requirement Diagram#

要件定義書です。要求図とも。「問題」を1単位まで細切れにして状況の整理と解決策を結ぶために使うやつです。
日本語未対応

    requirementDiagram

    requirement test_req {
    id: 1
    text: the test text.
    risk: high
    verifymethod: test
    }

    element test_entity {
    type: simulation
    }

    test_entity - satisfies -> test_req

$$
\def\arraystretch{1.5}
\begin{array}{c:l}
呼び出し & requirementDiagram \\ \hline
ウィズテキスト & できない \\ \hline
矢印の左右反転使用 & できない \\ \hline
矢印を両方に向ける &できない \\ \hline
矢印の見た目 & 固定  \\ \hline
矢印にコメント & 必須(固定) \\ \hline
矢印の長さ & 選べない  \\ \hline
向き & できない  \\ \hline
表示位置の指定 & できない  \\ \hline
ノード変形 & できない \\ \hline
ノードの中にノード & できない \\ \hline
ノードにコメント & できない  \\ \hline
ノードの色を変更 & できない  \\ \hline
メモ(付箋) & できない  \\ \hline
コメントアウト & 【\%\% hoge】  \\ \hline
fontawesome & できない  \\ \hline
リンクを繋げる & できない \\ \end{array}
$$

例えば「ザングースに惹かれるのは何故か」みたいな問題があるとして、
「色合い」「大きな爪」「ハブネークとの関係性」「体形」「大きさ」
から、
「爪が伸びて攻撃するから」
とかに分解します。そうしたときの最下層を用いて解決策を考えます。
すると、「この要素が含まれているキャラは惹かれる可能性が高い」とかの分析ができるわけです。
要求図としてしか使えず、日本語不可という使い方超限定なやつです。
本質を倫理的に考えたいときに。

表示

エレメントを決まった型で複数作成して、それを矢印で結びます。

    requirementDiagram

    element Otameshi {
    type: need to write
    }


    element Otameshi2 {
    type: need to write
    }

Otameshi - traces  -> Otameshi2
特に意味ない最低文字数表示

エレメント(要素)

要素の構成は型が決まっていて、自由記入なところ、固定記入なところを切り替えて要素を作成します。

element 好きな名前(英語) {
    type: 自由に書ける(英語)
    docref: 外部URL
}

element は外部URLを付けるやつです。(ざっくり)
typeとdocrefのみ。typeは貼られた先が画像なのか、ホームページなのかがわかるような感じで書く。

要件(Requirement)

こちらが主役。これのテキストが何を表しているのかを決まった型で定義します。

<type> 要件の名前(英語) {
    id: 数字か英語
    text: 短く簡潔に(英語)
    risk: <risk>
    verifymethod: <method>
}
超適当

idはバージョン管理みたいなもので、1.0から始まって、1.1になったり、1.0aになったりします。最終的に枝分かれしていくので隣接するのは順繰りの方がいいかも。

textは図として表示されるのは80文字まで。半角英数が使えます。それ以上長いということは分割できるということです。

type,risk,verifymethodは限られた種類から組み合わせて使います。
なお、これらを組み替えても見た目は変化しません。

type

$$
\def\arraystretch{1.5}
\begin{array}{l:c}
type & 意味合い \\ \hline
requirement & 問題定義 \\ \hline
functionalRequirement & 詳細=つまり \\ \hline
interfaceRequirement & 提案 \\ \hline
performanceRequirement & 問題定義の分解 \\ \hline
physicalRequirement & 解決機能 \\ \hline
designConstraint & 機能設計の制約 \\ \end{array}
$$

RiskはLow、Medium、Highの3種類。対応優先度。

引用:https://www.newton-consulting.co.jp/bcmnavi/glossary/risk_evaluation.html

verifymethodは要件の種別です。いずれかの用途に分類されます。

$$
\def\arraystretch{1.5}
\begin{array}{l:c}
verifymethod & 意味合い \\ \hline
Analysis & 分析 \\ \hline
Test & 議題 \\ \hline
Inspection & 検査 \\ \hline
Demonstration & 証明 \\ \end{array}
$$

〇〇用紙に書くものとイメージするといいかも。
だいたい、開始=test、補足=inspection、提案=Demonstration、解決へ=Inspection
みたな感じです。

矢印

要件や要素を矢印で結びます。

矢印には意味があり、その意味以外では使用されません。
A -> B または B <- A という反転はできます。

%%要素とか上にあるけど省略
    A - contains -> B
    C - copies -> D
    E - derives -> F
    G - satisfies -> H
    I - verifies -> J
    K - refines -> L
    M - traces -> N

$$
\def\arraystretch{1.5}
\begin{array}{c:c:l}
矢印 & 用途 & 例文 \\ \hline
contains & 分解 & Aを分解して別個体にしたのがBである \\ \hline
copies & 読み取り専用 & BはAの情報を吸い取っている \\ \hline
derives & 追加詳細 & Aの進化系がBである \\ \hline
satisfies & 要求を満たす & AはBを実現したものである \\ \hline
verifies & 相互作用 & AはBの一部である \\ \hline
refines & 明白にする & Aをさらに洗い出したのがB \\ \hline
traces & 汎用関係 & BはAに繋がっている他と何も影響を受けない関係 \\ \end{array}
$$

    requirementDiagram

    requirement req {
        id:0.00
        text: why am I lived Zangoose !!??
        risk:high
        verifymethod:test
    }
    functionalRequirement what Zangoose{
        id:0.00a1
        verifymethod:inspection
        text:Zangoose is pokemon .
    }

    req -traces-> what Zangoose

    performanceRequirement idea1 {
        id:1.00a
        text:cool claw
        risk:high

    }
        performanceRequirement idea2 {
        id:1.00b
        text:cute size
        risk:high

    }
        functionalRequirement idea2a{
        id:1.00b1
        verifymethod:inspection
        text:1.3m
    }
    req -contains-> idea1
    req -contains-> idea2
    idea2 -traces-> idea2a

    interfaceRequirement sug {
        id:2.00a
        verifymethod:demonstration
        text:I had an idea same it charactor!
    }
    idea1 -derives-> sug
章始めのザングースの例を表すとこんなん。



プロジェクト達成までのプロセスを描きたい

Gantt diagrams#

ガント図。エクセルで作ってたみんなー!楽できるぞー!

gantt
    title タイトル
    dateFormat  YYYY-MM-DD

    
    section セクションA
        A task           :a1, 2014-01-01, 30d
        Another task     :after a1  , 20d
    section セクションB
        Task in sec      :2014-01-12  , 12d
        another task      : 24d

複数人プロジェクトの進行予定表を視覚化する感じ。
全体的の作業日程の見直しとかに。

$$
\def\arraystretch{1.5}
\begin{array}{c:l}
呼び出し & gantt \\ \hline
ウィズテキスト & できない \\ \hline
矢印の左右反転使用 & ない \\ \hline
矢印を両方に向ける &ない \\ \hline
矢印の見た目 & ない  \\ \hline
矢印にコメント & ない \\ \hline
矢印の長さ & ない  \\ \hline
向き & できない  \\ \hline
表示位置の指定 & できない  \\ \hline
ノード変形 & できる(milestone) \\ \hline
ノードの中にノード & できない \\ \hline
ノードにコメント & できない  \\ \hline
ノードの色を変更 & 用途で変わる  \\ \hline
メモ(付箋) & できない  \\ \hline
コメントアウト & 【\%\% hoge】  \\ \hline
fontawesome & できない  \\ \hline
リンクを繋げる & できる \\ \end{array}
$$

書き方

基本は、業務名を決める、何日間(時間)行うのかを決める。この2点です。
例えば締切日を設定してそこから逆算する、という機能はありません。

上と大体同じです。

gantt
    %% データ記入方法
    dateFormat  YYYY-MM-DD

    %% タイトル名
    title       Adding GANTT diagram functionality to mermaid

    %% 休日除外(他にYYYY-MM-DD形式やsundayなど可能、「weekdays」は不可)
    excludes    weekends

    %% sectionで大枠区分
    section A section

        %% タスク名 :ステータス,固有ID,開始日付(dataFormatの書式),完了日(または作業日数)
        %% 開始日付より左のオプションは省略して記入できる
        %% 開始日はafter【固有ID】でそのIDタスクの終了日の翌日から始められる。
        Completed task            :done,    des1, 2014-01-06,2014-01-08
        Active task               :active,  des2, 2014-01-09, 3d
        Future task               :         des3, after des2, 5d
        Future task2              :         des4, after des3, 5d

    section Critical tasks
        Completed task in the critical line :crit, done, 2014-01-06,24h
        Implement parser and jison          :crit, done, after des1, 2d
        Create tests for parser             :crit, active, 3d
        Future task in critical line        :crit, 5d
        Create tests for renderer           :2d
        Add to mermaid                      :1d
        Functionality added                 :milestone, 2014-01-25, 0d

    section Documentation
        Describe gantt syntax               :active, a1, after des1, 3d
        Add gantt diagram to demo page      :after a1  , 20h
        Add another diagram to demo page    :doc1, after a1  , 48h

    section Last section
        Describe gantt syntax               :after doc1, 3d
        Add gantt diagram to demo page      :20h
        Add another diagram to demo page    :48h

dateFormat

日付の記入書式です。タスクのオプションの記入方法を固定します。
YYYY-MM-DDなら2023-05-11と記入、YY-MM-DDなら23-05-11と記入。
YYYY-MM-DDがデフォなので、dateFormatが違ってもYYYY-MM-DD形式がある場合そちらが優先表示されます。
逆にそれ以外の書式の場合はdateFormatで設定しないと表示しません。

    gantt
    title 西暦日付
    dateFormat YYYY-MM-DD
        お仕事 :2023-05-11, 1w
基本形
    gantt
    title 四半期
    dateFormat YYYY-Q
    axisFormat %m-%d

        お仕事 :2023-1, 30d
        お仕事2 :2023-2,30d
        お仕事3 : 2023-4,30d
1年の1/4の範囲で行う仕事の視覚化
大体は年間目標のための何やら。


対応してるらしいけど他は上手くいきませんでした。

axisFormat

縦軸に表示される内容の形式です。
dateよりaxisの内容が優先されて表示されます。
基本形はYYYY-MM-DD。

    gantt
    title 3m走結果
    axisFormat %S.%L
    選手A : 0 ,1s
    選手B : 0 ,1.5s
開始日時は必須項目なので仕方なく0を代入

「%なんとか」で縦軸の表示内容を変更できます。
表示内容の大本はタスクに記入した開始日と工程日数の2つから表示するものだけ表示させる仕組み。
例えば上の中身を全て出すと
「2000年1月1日(曜日)午前0時0分」の「1秒」と「1.5秒」です。
%Sは秒、%Lはミリ秒です。
中身から「秒」「.」「ミリ秒」の情報だけを抜き取りました。
他表現は以下より。


excludes

休日除外です。

    gantt
    title 休日は仕事しない
    excludes sunday,wednesday
    仕事A :2023-05-1,30d
5月1日から30日なので5月31までが、
休日が12日分あるので6月11日に延長している
なおdでなくw(週)でも同じく増える。

excludesで登録した曜日、あるいはweekends(土日)が登録できます。
祝日は登録できません。日を指定もできません。

section

同じ時間軸の中で複数の種類または人物の仕事で分類できます。

    gantt
    title 複数人作業

    section A
        仕事 : a,2022-05-11,1d
        仕事 : a,2022-05-11,1d
    section B
        仕事 : after a,1d
        仕事 : after a,1d
    section C
        仕事 : 2022-05-11,1d
        仕事 : 2022-05-11,2d
これは過重労働

タスクの中身

タスクはショートハンドで記載します。

タスク名 :ステータス,固有ID,開始日付(dataFormatの書式),完了日(または作業日数)

ステータスは以下の通りです。

$$
\def\arraystretch{1.5}
\begin{array}{c:c}
ステータス & 意味 \\ \hline
 & ノーマル \\
\hdashline
done & 済 \\
\hdashline
active & 現在進行中\\
\hdashline
crit & 重要 \\
\end{array}
$$

    gantt
    title ステータス種類

    section A
        仕事 : a,2022-05-11,1d
        仕事 : done, b,after a , 1d
        仕事 : active ,c,after b , 1d
        仕事 : crit ,after c , 1d
        仕事 : active,crit ,after c , 1d
        仕事 : done,crit ,after c , 1d
critは固有IDがつけられない。
critは他の状態を併合して扱える。

%% sectionで大枠区分
section A section

%% タスク名 :ステータス,固有ID,開始日付(dataFormatの書式),完了日(または作業日数)
%% 開始日付より左のオプションは省略して記入できる
%% 開始日はafter【固有ID】でそのIDタスクの終了日の翌日から始められる。



マイルストーン

プロジェクトのチェックポイント(目標日など)に当てます。◇で表示。

クリティカル

絶対に遅らせてはいけない進行タスクに使います。赤くなる。
主に一番時間がかかるタスクを指し、最初から最後までの複数通りの手順で最も時間がかかるルートをクリティカルパスとかいいます。

アクティブ

現在実行中のタスクに使います。タスクが青くなります。クリティカルと併合して使うと、青くなったうえ、枠だけ赤くなります。

ここまだ途中


データベースを構築前に視覚化したい

項目追加)23/05/23

Entity Relationship Diagrams#

エンティティ関係図です。ERD。

---
title: Order example
---
erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ LINE-ITEM : contains
    CUSTOMER }|..|{ DELIVERY-ADDRESS : uses

ERDはデータベースをプログラマー視点から視覚化します。

ここでのデータベースのイメージはエクセルの顧客情報一覧表
上の動画では、Amazonになったつもりで、
誰が、いつ、どの商品を、何個購入したのかというのが1行にまとめられて
その情報が数千行に渡り構成されています。

上は顧客情報がまとめられたブックですが、他に1商品情報のブック、
メーカーが取り扱っている商品情報のブックなどがあって運用ができます。
そうした、ブック同士の関係性、そのブックの意味合いを概念的に図として表すことができます。

ここでは二次元的にわかりやすくブックで例を出していますが、概念的な想像ができるようになれば、フォルダの中のファイル構成などでも利用できることがわかると思います。

ブックを表す

例えば、
ブック名:顧客情報
列:ID、名前、苗字、注文商品名、個数、注文時間、完了
行:1行が同じIDの情報

という、ブックがあるとしたら

---
title: 顧客情報というブック
---
erDiagram
    "顧客情報" {
        string ID PK
        string name 
        string Fname
        string Order
        long count
        date time
        bool finish

    }
要素名(2列目)は日本語使えない

mermaidのERDの場合、返し値 | 要素名 | Key |"コメント"
の順に表します。
このKeyは、ぶっちゃけ本人がわかれば何でもいいんですけど、
PKはPrimaryKey(主キー)、FKはForeignKey(外部キー)、何も入れないの3種が主流みたいです。
UK(Unique Key)もあります。

PKは1行同士を比べたときに差別化できる唯一の項目に付けられます。
FKは他のブックに主題があり、そのデータを引用して構成している場合です。

ブックの関係性を表す

上の顧客情報に、商品情報を紐づけます。

---
title: 顧客情報と商品情報を繋げる
---
erDiagram

    "顧客情報" {
        string ID PK
        string name 
        string Fname
        string Order FK
        long count
        date time
        bool finish

    }
    "商品情報" {
        string Order PK
        string CustmeNum
        string CustmeName
        long sizeX
        long sizeY
    }

    "顧客情報" ||--|{ "商品情報" : Order
FKのOrderから伸ばしたことを表す
つまり、FKのOrderは商品情報のPKのOrderを引用している

この2つを結ぶ線はそれぞれ意味があります。
上の場合、
顧客情報から見た商品情報の関係性はOrderより下部分の先部分、
商品情報から見た顧客情報の関係性は~上部分の先部分です。
2つの間の中央に近い方を最小値、遠い方を最大値で表します。

日本語訳すると、
顧客情報からみた商品情報は最小値1、最大値がたくさん
商品情報からみた顧客情報は最小値1、最大値1です。
これを会話文に変えると
「顧客は商品をいくつ注文できますか?」「1個以上です」
「商品は顧客(ID固定)何人に注文されますか?」「1人です。(ID固定)」

使用できる表記は以下です。

$$
\def\arraystretch{1.5}
\begin{array}{c:l:}
(内)\ 表記\ (外) & 意味 \\ \hline
o| & 最小値0、最大値1 \\ \hline
|| & 最小値1、最大値1\\ \hline
o\{ & 最小値0、最大値上限なし \\ \hline
|\{ & 最小値1、最大値上限なし\\ \hline
\end{array}
$$

ブリッジテーブル

ところで上の関係図は厳密には誤りがあります。
顧客情報に注文した商品を入れていることですね。複数注文したらどうするんでしょこれ。

なので、「顧客情報」--「注文履歴」--「商品情報」であるべきです。
こうしたテーブルとテーブルの間を繋げるテーブルをブリッジテーブル
いうらしい。(日本語情報なかった)

ブリッジA }o--o{ ブリッジB

と、互いから見て最小値が0になる場合は間に何か入れた方が円滑に進む。





開発中機能

構文が変わる可能性や、未実装機能があったりするやつ

Gitgraph Diagrams#

---
title: Example Git diagram
---
gitGraph
   commit
   commit
   branch develop
   checkout develop
   commit
   commit
   checkout main
   merge develop
   commit
   commit
GitHubのブランチ派生やマージの計画図などに

C4 Diagrams#

C4Context
      title System Context diagram for Internet Banking System
      Enterprise_Boundary(b0, "BankBoundary0") {
        Person(customerA, "Banking Customer A", "A customer of the bank, with personal bank accounts.")
        Person(customerB, "Banking Customer B")
        Person_Ext(customerC, "Banking Customer C", "desc")

        Person(customerD, "Banking Customer D", "A customer of the bank, <br/> with personal bank accounts.")

        System(SystemAA, "Internet Banking System", "Allows customers to view information about their bank accounts, and make payments.")

        Enterprise_Boundary(b1, "BankBoundary") {

          SystemDb_Ext(SystemE, "Mainframe Banking System", "Stores all of the core banking information about customers, accounts, transactions, etc.")

          System_Boundary(b2, "BankBoundary2") {
            System(SystemA, "Banking System A")
            System(SystemB, "Banking System B", "A system of the bank, with personal bank accounts. next line.")
          }

          System_Ext(SystemC, "E-mail system", "The internal Microsoft Exchange e-mail system.")
          SystemDb(SystemD, "Banking System D Database", "A system of the bank, with personal bank accounts.")

          Boundary(b3, "BankBoundary3", "boundary") {
            SystemQueue(SystemF, "Banking System F Queue", "A system of the bank.")
            SystemQueue_Ext(SystemG, "Banking System G Queue", "A system of the bank, with personal bank accounts.")
          }
        }
      }

      BiRel(customerA, SystemAA, "Uses")
      BiRel(SystemAA, SystemE, "Uses")
      Rel(SystemAA, SystemC, "Sends e-mails", "SMTP")
      Rel(SystemC, customerA, "Sends e-mails to")

      UpdateElementStyle(customerA, $fontColor="red", $bgColor="grey", $borderColor="red")
      UpdateRelStyle(customerA, SystemAA, $textColor="blue", $lineColor="blue", $offsetX="5")
      UpdateRelStyle(SystemAA, SystemE, $textColor="blue", $lineColor="blue", $offsetY="-10")
      UpdateRelStyle(SystemAA, SystemC, $textColor="blue", $lineColor="blue", $offsetY="-40", $offsetX="-50")
      UpdateRelStyle(SystemC, customerA, $textColor="red", $lineColor="red", $offsetX="-50", $offsetY="20")

      UpdateLayoutConfig($c4ShapeInRow="3", $c4BoundaryInRow="1")
階層型の関係図。
イメージで言うとグーグルマップを国から1つの道が見えるまで拡大していくような感じ。
4つの拡大構造レイヤーがあり、
まあホームページ作ってるみたいな感じになっていくんだろうな。

Mindmap#

mindmap
  root((mindmap))
    Origins
      Long history
      ::icon(fa fa-book)
      Popularisation
        British popular psychology author Tony Buzan
    Research
      On effectiveness<br/>and features
      On Automatic creation
        Uses
            Creative techniques
            Strategic planning
            Argument mapping
    Tools
      Pen and paper
      Mermaid
中心に議題を置き、それから派生させて新しいアイデアを発掘する図。

Timeline Diagram#

timeline
    title History of Social Media Platform
    2002 : LinkedIn
    2004 : Facebook
         : Google
    2005 : Youtube
    2006 : Twitter
見たままです。大枠を付けられたり、色を変えられれます。


その他(md)

ファイル引用

@import "【ファイルパス】"

で、そのファイル内容を引用して表示できます。
ただし、MarkdownPreviewMermaidSupportの力なので、MarkdownPDFで出力すると、上のコードだけが表示されて引用されません。

MarkdownPreviewMermaidSupportで出力するには、プレビュー画面の右クリックメニューの「Chrome」からPDFで出力します。

改ページ

<div class="page"/>

で、任意箇所でページ改行ができます。
ただし、MarkdownPDFの力なので、MarkdownPreviewMermaidSupportで出力すると無効化されます。




おわり!!


この記事が気に入ったらサポートをしてみませんか?