Mermaid.jsとChart.jsを比較して学ぶ(第一回:MermaidとUML)

2024/07/18 Javascript mermaid UML 比較シリーズ

はじめに

比較シリーズ第一弾では、「C#をPythonと比較して学ぶ」と題して、C#について学びました。第二弾の比較シリーズでは、視覚的な要素に焦点を当て、HTMLで使える、Mermaid.jsとChart.jsの比較を行います。Mermaid.jsはmermaid記法を使用し、Chart.jsは異なるアプローチでグラフを生成します。この記事では、それぞれのライブラリの概要に加えて、Mermaid.jsのmermaid記法とChart.jsの基本的な使い方に深く掘り下げます。図を作成する際にどちらを選ぶか迷っている方にとって、理解を深める手助けとなるでしょう。それでは、各ライブラリの基本を探っていきましょう。

注：なお、私がMermaid.jsとChart.jsについて学んだことを元にしていますが、不足している部分や誤っている部分があるかもしれません。その際は、遠慮なくご指摘いただければ幸いです。

目次
  1. はじめに
  2. Mermaid.jsとは
  3. Chart.jsとは
  4. UMLとは
  5. UMLの分類
  6. ユースケース図
  7. クラス図
  8. シーケンス図
  9. ステートマシン図
  10. アクティビティ図
  11. データベース設計とER図
  12. mermaid記法で扱えるその他の図
  13. まとめ


mermaid.jsとは

Mermaid.jsは、図やグラフをテキスト記述から生成するためのJavaScriptライブラリです。Mermaid記法はマークダウン風のスクリプト言語で、開発者やドキュメンテーション作成者がコードブロック内でシーケンス図、フローチャート、ガントチャート、クラス図などを作成できます。

Mermaid記法の基本

Mermaid記法は直感的でシンプルな図がすぐに作成できます。例えば、以下のようなフローチャートをMermaid記法で表現できます：

graph LR
    Start --> GetMoney --> GoShopping
    GoShopping --> LetMeThink
    LetMeThink --> |Laptop| BuyALaptop
    LetMeThink --> |iPhone| BuyAnIPhone
    LetMeThink --> |Car| BuyACar

graph LR
    Start --> GetMoney --> GoShopping
    GoShopping --> LetMeThink
    LetMeThink --> |Laptop| BuyALaptop
    LetMeThink --> |iPhone| BuyAnIPhone
    LetMeThink --> |Car| BuyACar

Mermaid記法のユースケース

Mermaid記法は以下のような場面で便利です：

  1. 複雑な情報の視覚化: フローチャートやシーケンス図などを使用して、複雑なプロセスやシステムの理解を助けます。
  2. コード内での図の作成: マークダウンファイルやソースコードのコメント内に直接図を描けます。
  3. 迅速なビジュアル化が必要なとき: 学習曲線が低く、シンプルな図は素早く作成できます。

Mermaid記法の便利な使い方

Mermaid記法を活用して次のようなことができます：

  1. プロジェクトのフローを視覚化: タスクの流れをフローチャートとして描き、全体像を把握しやすくします。
  2. コードの挙動の説明: ソースコードのコメントにMermaid記法を使って図を描くことで、コードの挙動を視覚的に説明できます。
  3. ドキュメンテーションの作成: テキストベースのドキュメンテーションに直接図を描き込み、読者の理解を深めます。

Mermaid.jsの利用方法

Mermaid.jsはオープンソースで、CDNを介して手軽に利用できます。以下のHTML例では、Mermaid.jsを読み込み、Mermaid記法でフローチャートを描画しています：

<script src="https://cdn.jsdelivr.net/npm/mermaid@10.5.0/dist/mermaid.min.js"></script>
<pre class="mermaid">
graph LR
    Start --> Something --> End
</pre>

これにより、テキストベースで図を描画することができます。Mermaid.jsは多くのサービスでサポートされ、GitHubやZenn、esa.io、Notionなどで広く採用されています。

mermaid記法の詳細は以下の公式ページやチートシートなどを参考にしてください。

Mermaid公式

Mermaidチートシート

Chart.jsとは

Chart.jsは無料のJavaScriptライブラリで、HTMLベースのグラフを作成するのに利用されます。これは最も単純な視覚化ライブラリの1つであり、散布図、折れ線グラフ、棒グラフ、円グラフ、ドーナツチャート、バブルチャート、面グラフ、レーダーチャート、混合チャートなど、様々な組み込みグラフタイプが含まれています。

Chart.jsの使用方法

  1. CDNの追加:

    ライブラリを利用するために、提供されているCDNへのリンクをHTMLに追加します。

    <script src="https://cdnjs.cloudflare.com/ajax/libs/Chart.js/2.9.4/Chart.js"></script>

  2. <canvas>の追加:

    グラフを描画するために、HTML内の適切な場所に <canvas> 要素を追加します。各 <canvas> 要素には一意のIDが必要です。

    <canvas id="myChart" style="width:100%;max-width:700px"></canvas>

Chart.jsの特徴

  • グラフの種類: Chart.jsは線グラフ、棒グラフ、レーダーチャート、鶏頭図、円グラフ、ドーナツチャート、バブルチャート、散布図など多彩なグラフを作成できます。

  • カスタマイズ可能性: 開発者はデフォルトの設定以外にも、チャートの表示形式、軸の設定、色やスタイル、アニメーションなどのプロパティを調整し、独自のビジュアル表現を作り出すことができます。

  • 柔軟性: チャートの作成において柔軟性が重要です。Chart.jsは開発者が自身の目的や要件に合わせて、様々なカスタマイズを行えるため、多様なプロジェクトに適用可能です。

ライセンスと注意事項

Chart.jsはMITライセンスの下で提供されており、再配布が自由です。ただし商標利用についてはMITライセンスでは規定されておらず、商標ポリシーに従う必要があります。バージョンごとにプロパティの位置やプロパティ名が異なるので、注意が必要です。

UMLとは

統一モデリング言語（Unified Modeling Language, UML）は、ソフトウェア工学で用いられる汎用的で開発に特化したモデリング言語です。システム設計を視覚的に図式化して標準化されたモデリング手法を提供することが目的とされています。UMLはオブジェクト指向分野で主に活用され、その普及のためには標準的なモデリング手法を提供することが求められていました。

UMLはグラディ・ブーチ、イヴァー・ヤコブソン、ジェームズ・ランボーによって1994～95年に最初の版が作成されました。これらの開発者たちはスリーアミーゴスと呼ばれ、96年まで改良を続けました。1997年にObject Management Group（OMG）が採用し、以降は同団体によって管理され、2005年にはISOで国際標準化されました。最新版は2017年12月に採択された UML 2.5.1 です。

UML 2.0 以降では、クラス図、アクティビティ図、シーケンス図など、開発の各局面に応じて使い分けることができる14種類のダイアグラムがあります。これにより、UMLはソフトウェアのモデリングだけでなく、ビジネスプロセスのモデリングやシステム工学的モデリングにも応用され、組織の構造図を表現するのにも適しています。

UMLはモデル駆動工学（MDE) やモデル駆動型アーキテクチャ (MDA) などのモデル駆動型の技術の発展に貢献しました。その柔軟性や概念の視覚的な記法により、ソフトウェア開発者は設計や構造に焦点を当て、UMLを通じてソフトウェアの仕様、視覚化、構築、文書化を行います。

UMLのポイント

システム開発は、分析設計、実装、テストに大きく分けられます。このうち、UMLは分析設計を担う言語です。ちなみに、実装部分を担うのが、いわゆるプログラミング言語であるpythonやjavascriptなどです。

この分析設計を行う際にポイントとなるのが、システムのモデル化における３つの視点です。１つ目は動的視点・静的視点、２つ目は論理的視点・物理的視点、３つ目は外部的視点・内部的視点です。

  1. 動的視点・静的視点

    動的視点

    動的視点では、システムの流れ、動きを見ていく視点です。つまりシステムの構成要素同士が互いに協調動作をしている様を表す振る舞いに着目した視点ということです。

    静的視点

    静的視点では、システムのある一瞬の断面を見るか、システムを俯瞰して見る視点です。つまりシステムの構成要素同士の関係性を表す構造に着目した視点ということです。

  2. 物理的視点・論理的視点

    物理的視点

    物理的にかなっている様子を見る視点です。たとえば、管理アプリシステムならあるボタンが画面上のどこに配置されているか、物流システムなら工場や倉庫がどこにあるか、など物理的な距離に着目した視点です。

    論理的視点

    論理的な構造に着目する視点です。たとえばある機能がどのような役割を担っているかということに着目し、物理的な距離に関わらず、論理構造で把握する視点のことです。

  3. 外部的視点・内部的視点

    外部的視点

    外部からみて、どのような機能があるかということを見る視点です。たとえば、ユーザーがこのアプリには、この機能やあの機能があると挙げるような視点です。

    内部的視点

    外部的視点で見られた機能を、内部で具体的にどのようなシステムで実現していくかを見る視点です。コードを書いていく際はこの内部的視点が直接関わっていくといえます。

UMLの分類

先に挙げた３つの視点から、UMLを構成する各図を分類することができます。

  1. 外部的視点：ユースケース図
  2. 内部的視点

    1. 静的視点

      • 論理的視点：クラス図、オブジェクト図
      • 物理的視点：コンポーネント図、配置図

    2. 動的視点

      • 相互作用：シーケンス図、コミュニケーション図
      • 状態遷移：ステートマシン図、アクティビティ図

このUMLのモデリングのポイントは、1.機能(何をするか What), 2.構造(誰がするのか Who), 3.振る舞い(どのようにするのか How)をそれぞれ考えて、システム開発をすることです。

そのため、1.機能を表すユースケース図、2.構造を表す静的視点の図、3.振る舞いを表す動的視点の図を使い分けることが大切になってきます。

以下の章では、これらの図に関して、mermaid記法を添えながら、扱っていきます。

ユースケース図

ユースケース図は、システムの外部から見たシステムの機能や振る舞いを表現するためのダイアグラムです。主にアクター（ユーザーや外部システム）とシステムとの相互作用を視覚的に示します。ちなみに、mermaid記法では、ユースケース図はサポートしていません。

ユースケース図の構成要素

  1. アクター（Actor）:

    • 説明: アクターはシステムと対話する外部エンティティです。これは通常、ユーザー、他のシステム、または外部エンティティを表します。(人形がこれに当たります。)

  2. ユースケース（Use Case）:

    • 説明: ユースケースはシステムが提供する個々の機能や機能群を表します。アクターとユースケース間の関係がアクションや機能の要件を示します。機能を表す楕円がこれに当たります。

  3. 関連（Association）:

    • 説明: アクターとユースケース、およびユースケース間の関連性を表現します。通常、矢印で示され、どのアクターがどのユースケースに対話できるかを示します。

  4. システム境界（System Boundary）:

    • 説明: システム全体の境界を示し、システム内外の要素との区別を明確にします。

ユースケース図の例

以下は、ユーザーがシステムにログインし、商品を購入するユースケース図の表現例です。

この例では、ユーザーがログインして商品を購入するシナリオを表現しています。

クラス図

クラス図は、システムの静的な構造を表現し、クラス、属性、操作、関連などの要素を含むダイアグラムです。以下にクラス図の重要な概念と構成要素について説明します。

クラス図の抽象化

クラス図は静的視点にたって、システムの論理的モデルを表現します。その抽象化には以下の要素が含まれます。

  1. クラス（Class）:

    • 説明: システム内の物理または概念的なエンティティを表します。クラスには属性（静的特徴）と操作（動的特徴）が含まれます。

    • 表現例:

      classDiagram
   class Car {
   - brand: String
   - model: String
   + startEngine(): void
   }
    コード詳細 
    classDiagram
   class Car {
   - brand: String
   - model: String
   + startEngine(): void
   }

  2. 属性（Attributes）:

    • 説明: クラスが持つ静的な特徴やデータを表します。属性はクラスの状態を定義します。

    • 表現例:

      classDiagram
   class Person {
   - name: String
   - age: int
   }
      コード詳細 
      classDiagram
   class Person {
   - name: String
   - age: int
   }

  3. 操作（Operations）:

    • 説明: クラスが実行できる動的な振る舞いや機能を表します。操作はメソッドや関数として実装されます。

    • 表現例:

      classDiagram
   class Calculator {
   + add(a: int, b: int): int
   + subtract(a: int, b: int): int
   }
      コード詳細 
      classDiagram
   class Calculator {
   + add(a: int, b: int): int
   + subtract(a: int, b: int): int
   }

  4. 識別子（Identifier）:

    • 説明: クラス属性の中で、オブジェクトを一意に識別するための属性。通常、IDやキーとして使用されます。

  5. 集合（Type）:

    • 説明: クラスのインスタンス（オブジェクト）の型。クラスは型の定義であり、オブジェクトはその型の実体です。

    • 表現例:

      classDiagram
   class Dog{
       体温
   }

   class `ポチ:Dog`{
       体温="36.5℃"
   }
      コード詳細 
      classDiagram
   class Dog{
       体温
   }

   class `ポチ:Dog`{
       体温="36.5℃"
   }

クラス図の一般化

一般化は、クラスの継承関係を示します。親クラス（上位概念）から子クラス（下位概念またはサブクラス）に特徴や操作が引き継がれます。一般化の例を以下に示します。親クラスの属性は子クラスの属性に継承されるため、クラス図では省略する事ができます。

classDiagram
    class Animal {
    - 体温: int
    }

    Animal <|-- Dog : 一般化
    Animal <|-- Cat : 一般化
コード詳細 
classDiagram
    class Animal {
    - 体温: int
    }

    Animal <|-- Dog : 一般化
    Animal <|-- Cat : 一般化

コードの説明:

  • Animalは基底クラスで、Dogはそれを一般化したサブクラスです。
  • 一般化の関係は<|--で表現されます。

クラス図の構造

クラス図で構造化する際にポイントとなるのは、関連、依存、汎化、実現です。汎化は、一般化のように親クラスと子クラスの継承関係を表します。以下では残りの関連、依存、実現について説明していきます。

クラス図の関連

クラス図では、異なるクラス間の関連性を示します。以下に関連の概念と表現方法を示します。

  1. 関連（Association）:

    • 説明: クラス間の静的な関係を示します。通常、直線で表現され、関連名と方向(▲)が付与されます。

    • 表現例:

      classDiagram
   Student -- Course : 履修▼
      コード詳細 
      classDiagram
  Student -- Course : 履修▼

  2. 多重度（Multiplicity）:

    • 説明: 関連において、各クラスが関連する際のインスタンス数の範囲を示します。下の例では自動車とタイヤの関係を表しています。自動車はタイヤを必ず４つ保有しています。一方、タイヤは１台の自動車に保有されています。購入カートの例では、商品を必ず1つ以上保有しているのに対し、商品は誰からも買われていないものから、沢山の人に買われているものもあります。このような範囲を表す際に..が使われます。また＊は上限がないことを表しています。

    • 表現例:

      classDiagram
   自動車 "1" -- "4" タイヤ

   商品 "1..*" -- "0..*" 購入カート
      コード詳細 
      classDiagram
   自動車 "1" -- "4" タイヤ

   商品 "1..*" -- "0..*" 購入カート

  3. 集約（Aggregation）:

    • 説明: 複数のオブジェクトが集まって新たなオブジェクトを構成する関係。集約は弱い関連を示します。

    • 表現例:

      classDiagram
   Team o-- Player : 所属
      コード詳細 
      classDiagram
  Team o-- Player : 所属

  4. コンポジション（Composition）:

    • 説明: 関連において、子クラスが親クラスに完全に依存している関係。コンポジションは強い関連を示します。下の例では、車とエンジンの関係を示しています。車を燃やしたときに、同時にエンジンも燃えて消失することから、エンジンは車という存在に依存していることがわかります。

    • 表現例:

      classDiagram
   class Car {
   - engine: Engine
   }

   Car *-- Engine : 所有
      コード詳細 
      classDiagram
  class Car {
  - engine: Engine
  }

  Car *-- Engine : 所有

  5. 関連の5W1H:

    • 説明: 関連を考える際に、Why（なぜ）、What（なにを）、Where（どこに）、Who（だれが）の4つの視点に分類して考えると、関連する項目が見いだしやすくなります。

    • 表現例:

      classDiagram
   class 出荷 {
   - 出荷番号
   - 出荷日付 : When

   -出荷() : How
   }

   出荷 -- 受注 : Why
   出荷 -- 製品 : What
   出荷 -- 顧客 : Where
   出荷 -- 出荷業者 : Who
      コード詳細 
      classDiagram
  class 出荷 {
  - 出荷番号
  - 出荷日付 : When

  -出荷() : How
  }

  出荷 -- 受注 : Why
  出荷 -- 製品 : What
  出荷 -- 顧客 : Where
  出荷 -- 出荷業者 : Who

  6. 分解と分類:

    • 説明: 集約は分解を表しており、一般化は分類を表しています。この二軸で関係性を分類してみるという点でもクラス図の構築ができます。

    • 表現例:

      classDiagram
   車 o-- タイヤ : 分解(集約)
   車 <|-- バス : 分類(汎化)
   車 <|-- トラック : 分類(汎化)
      コード詳細 
      classDiagram
   車 o-- タイヤ : 分解(集約)
   車 <|-- バス : 分類(汎化)
   車 <|-- トラック : 分類(汎化)

  7. 抽象化（Abstraction）:

    • 説明: クラスが持つサブクラスを要素として持つものをメタクラスやパワータイプ、集合族と呼びます。以下の例では、AnimalクラスとAnimal Speciesクラスなどを表しています。AnimalクラスはDogクラスやHumanクラスなどの親クラスにあたり、ポチ(個体識別番号:0001)や太郎(個体識別番号:0002)、タマ(個体識別番号:0003)などのインスタンスを要素として持っています。一方、Animal Speciesクラスでは、Dog, Cat, Humanそのものを要素として持っています。そのため、Animalクラスを抽象化したものと言えるでしょう。

    • 表現例:

      classDiagram
   class Animal{
       + 個体識別番号
       + 体温
       + 歩行()
   }

   class Dog{
       + 吠える()
   }

   class Cat{
       + 喉を鳴らす()
   }

   class Human{
       + 文字を書く()
   }

   class Animal Species{
       + 動物種識別番号
   }

   Animal <|-- Dog
   Animal <|-- Cat
   Animal <|-- Human
   Animal Species -- Animal: メタクラス
      コード詳細 
      classDiagram
   class Animal{
       + 個体識別番号
       + 体温
       + 歩行()
   }

   class Dog{
       + 吠える()
   }

   class Cat{
       + 喉を鳴らす()
   }

   class Human{
       + 文字を書く()
   }

   class Animal Species{
       + 動物種識別番号
   }

   Animal <|-- Dog
   Animal <|-- Cat
   Animal <|-- Human
   Animal Species -- Animal: メタクラス

  8. 参照オブジェクトと値オブジェクト:

    • 説明: 同一性はオブジェクトそのものが同じであるかどうかを示し、等価性はオブジェクトが同じではないが同等であるかどうかを示します。参照オブジェクトは同一性を持ち、エンティティを表します。一方、値オブジェクトは等価性を持ち、値を表します。
    • 表現例:
    classDiagram
   note for Animal Species "Memo: 参照オブジェクト"
   note for Behavior "Memo: 値オブジェクト"

   class Animal Classification Criterion{
       + 定義
   }

   class Animal Species{
       + 動物種識別番号
   }

   Animal Classification Criterion <-- Animal Species
   Animal Species -- Animal: メタクラス
   Animal Classification Criterion <|-- Skeleton
   Animal Classification Criterion <|-- Color
   Animal Classification Criterion <|-- Behavior
    コード詳細 
    classDiagram
   note for Animal Species "Memo: 参照オブジェクト"
   note for Behavior "Memo: 値オブジェクト"

   class Animal Classification Criterion{
       + 定義
   }

   class Animal Species{
       + 動物種識別番号
   }

   Animal Classification Criterion <-- Animal Species
   Animal Species -- Animal: メタクラス
   Animal Classification Criterion <|-- Skeleton
   Animal Classification Criterion <|-- Color
   Animal Classification Criterion <|-- Behavior

依存関係（Dependency）:

  • 説明: クラスが変更されると、それに依存するクラスも変更される関係。依存関係は方向性があり、変更が伝播します。

  • 表現例:

    classDiagram
   大工..>ノコギリ : 依存関係
    コード詳細 
    classDiagram
   大工..>ノコギリ : 依存関係

実現関係（Realization）:

  • 説明: インターフェイスとクラス間の関係。クラスがインターフェイスを実現することを示します。

  • 表現例:

    classDiagram
   class 飼育動物{
       <<interface>>
       + 飼い主の命令を聞く()
   }
   Animal <|-- Dog : 汎化
   Animal <|-- Cat
   Animal <|-- Human

   飼育動物 <|.. Dog
   飼育動物 <|.. Cat
   飼育動物 <|.. Human: 実現
    コード詳細 
    classDiagram
   class 飼育動物{
       <<interface>>
       + 飼い主の命令を聞く()
   }
   Animal <|-- Dog
   Animal <|-- Cat
   Animal <|-- Human

   飼育動物 <|.. Dog
   飼育動物 <|.. Cat
   飼育動物 <|.. Human

これらの概念と関係性をクラス図に表現することで、システムの静的な構造や関連性を理解しやすくなります。

シーケンス図

シーケンス図は、オブジェクト同士の相互作用やメッセージの流れを順番に示す図であり、主にシステムの動的な振る舞いをモデル化します。以下にシーケンス図の重要な構成要素や概念について説明します。

シーケンス図の構成要素

  1. アクター（Actor）:
    • 説明: システム外部からの相互作用を開始する外部エンティティを表します。通常、人や外部システムがアクターとなります。
sequenceDiagram
    actor User as ユーザー
コード詳細 
sequenceDiagram
    actor User as ユーザー
  1. オブジェクト（Object）:
    • 説明: シーケンス図において相互作用する対象となるオブジェクトやクラスを表します。
sequenceDiagram
    participant System as システム
コード詳細 
sequenceDiagram
    participant System as システム
  1. ライフライン（Lifeline）:
    • 説明: オブジェクトが存在する時間軸を表します。垂直の実線で示され、オブジェクトの寿命を示します。
sequenceDiagram
    User ->> System: ログインリクエスト
コード詳細 
sequenceDiagram
    User ->> System: ログインリクエスト
  1. メッセージ（Message）:
    • 説明: オブジェクト間での相互作用を表現する手段。メッセージはアクションを開始するオブジェクトから別のオブジェクトへ向けて送信されます。(mermaid記法では、メッセージは必須)
sequenceDiagram
    System ->> Database: メッセージ
コード詳細 
sequenceDiagram
    System ->> Database: メッセージ
  1. 実行仕様（Execution Specification）:
    • 説明: メッセージの送信と受信の間に発生するアクションや処理を示します。垂直のボックスで表現され、実行時間を表しています。
sequenceDiagram
    Database ->> System: 起動
    activate Database
    System ->> Database: メッセージ
    Database -->> System: 認証結果
    deactivate Database
コード詳細 
sequenceDiagram
    Database ->> System: 起動
    activate Database
    System ->> Database: メッセージ
    Database -->> System: 認証結果
    deactivate Database
  1. シーケンス番号（Sequence Number）:
    • 説明: メッセージの順序を示すために使用される数字。通常、左から右に向かって1, 2, 3...と順に増加します。
sequenceDiagram
autonumber

User ->> System: メッセージ
System ->> Database: メッセージ
Database -->> System: 返事
コード詳細 
sequenceDiagram
autonumber

User ->> System: メッセージ
System ->> Database: メッセージ
Database -->> System: 返事

シーケンス図の動作とクラス図の操作

シーケンス図での動作はクラス図の操作と対応関係にあります。

---
title: シーケンス図
---

sequenceDiagram
autonumber

User ->> System: Tap()
System ->> Database: Get()
Database -->> System: Post()
コード詳細 
---
title: シーケンス図
---

sequenceDiagram
autonumber

User ->> System: Tap()
System ->> Database: Get()
Database -->> System: Post()

↓対応するクラス図

---
title: クラス図
---

classDiagram 
direction LR

class User{Tap()}
class System {Get()}
class Database {System: Post()}

User--System
System--Database
コード詳細 
---
title: クラス図
---

classDiagram 
direction LR

class User{Tap()}
class System {Get()}
class Database {System: Post()}

User--System
System--Database

複合フラグメント

シーケンス図では以下の複合フラグメントが使われます。

  1. loopとbreak:
    • 説明: 特定の条件が満たされるまで繰り返される部分を示す。loop内で条件を定義し、breakで抜けることができます。
sequenceDiagram
    loop　1,5
    System ->> Database: 書き込み
        break 書き込み失敗
            Database -->> System: 容量不足通知
        end
    Database -->> System: 書き込み成功
    end
コード詳細 
sequenceDiagram
    loop　1,5
    System ->> Database: 書き込み
        break 書き込み失敗
            Database -->> System: 容量不足通知
        end
    Database -->> System: 書き込み成功
    end
  1. altとelse:
    • 説明: 条件分岐を表します。altは条件が真の場合、elseは条件が偽の場合のみ表示されるアクションを示します。一方、optは条件が真のときのみ実行し、elseが存在しない場合に使用されます。
sequenceDiagram

    User ->> System: ログイン
    alt 認証成功
        System ->> User: ホームページ
    else 認証失敗
        System ->> User: 認証失敗メッセージ
    end
    opt 管理者
        System ->> User: 管理者ページ
    end
コード詳細 
sequenceDiagram

    User ->> System: ログイン
    alt 認証成功
        System ->> User: ホームページ
    else 認証失敗
        System ->> User: 認証失敗メッセージ
    end
    opt 管理者
        System ->> User: 管理者ページ
    end
  1. parallel:
    • 説明: 並列処理を表現します。par内のアクションは同時に実行されます。
sequenceDiagram
    par 認証
    System ->> Database: 認証リクエスト
    and ログ
    System ->> LoggingService: ログ記録リクエスト
    end
コード詳細 
sequenceDiagram
    par 認証
    System ->> Database: 認証リクエスト
    and ログ
    System ->> LoggingService: ログ記録リクエスト
    end
  1. 排他処理:
    • 説明: 特定の時間において、あるオブジェクトが他のオブジェクトとの相互作用を排他的に行うことを示します。つまり影響を受けずに実行されます。
sequenceDiagram
    critical
    User ->> System: 通常操作
    option 他
    Admin ->> System: 特別な操作
    end
コード詳細 
sequenceDiagram
    critical
    User ->> System: 通常操作
    option 他
    Admin ->> System: 特別な操作
    end

シーケンス図の例

以下はシーケンス図の例です。この例では、ユーザーがシステムにログインするプロセスが示されています。

sequenceDiagram
  actor User
  participant System
  participant Database

  User ->> System: ログインリクエスト
  activate System

  System ->> Database: ユーザー認証
  activate Database

  Database -->> System: 認証結果
  deactivate Database

  alt 認証成功
    System ->> User: ログイン成功メッセージ
  else 認証失敗
    System ->> User: 認証失敗メッセージ
  end
  deactivate System
コード詳細 
sequenceDiagram
  actor User
  participant System
  participant Database

  User ->> System: ログインリクエスト
  activate System

  System ->> Database: ユーザー認証
  activate Database

  Database -->> System: 認証結果
  deactivate Database

  alt 認証成功
    System ->> User: ログイン成功メッセージ
  else 認証失敗
    System ->> User: 認証失敗メッセージ
  end
  deactivate System

コードの説明:

  • Userがログインリクエストを送信し、Systemが認証を行います。
  • 認証の結果に応じて、Systemが成功または失敗メッセージをUserに送信します。
  • altとelseで条件分岐を表現しています。
  • ダイアグラム内でのオブジェクトのアクティベーションとディアクティベーションが示されています。

ステートマシン図

ステートマシン図は、オブジェクトが遷移する状態やその遷移条件を示す図です。以下に、ステートマシン図の構成要素や基本的な概念について説明します。

ステートマシン図の構成要素

  1. 開始状態（Initial State）:
    • 説明: ステートマシンの開始点を示す。通常、最初に実行される状態。
stateDiagram
  [*] --> State1
コード詳細 
stateDiagram
  [*] --> State1
  1. 終了状態（Final State）:
    • 説明: ステートマシンの終了点を示す。通常、処理が完了した状態。
stateDiagram
  State2 --> [*]
コード詳細 
stateDiagram
  State2 --> [*]
  1. 状態（State）:
    • 説明: オブジェクトが存在できる状態。開始状態や終了状態以外の一般的な状態。
stateDiagram
  State1
コード詳細 
stateDiagram
  State1
  1. トリガー（Trigger）:
    • 説明: 状態遷移を引き起こす外部からの刺激。イベントや条件がトリガーとなります。
stateDiagram
    State2 --> State3 : Trigger1
コード詳細 
stateDiagram
    State2 --> State3 : Trigger1
  1. ガード条件（Guard Condition）:
    • 説明: 状態遷移が発生するための条件。トリガーが発生する条件を表します。
stateDiagram
  State3 --> State1 : 出荷依頼 [在庫あり]出荷
コード詳細 
stateDiagram
  State3 --> State1 : 出荷依頼 [在庫あり]出荷
  1. アクション（Action）:
    • 説明: 状態遷移中に実行されるアクションや処理。状態が変わる際に実行される動作を示します。
stateDiagram
    state C : 分岐
    state C <<choice>>

    [*] --> 議題
    議題 --> C
    C --> D: 出荷依頼[在庫なし]報告
    C --> E : 出荷依頼[在庫あり]出荷
コード詳細 
stateDiagram
    state C : 分岐
    state C <<choice>>

    [*] --> 議題
    議題 --> C
    C --> D: 出荷依頼[在庫なし]報告
    C --> E : 出荷依頼[在庫あり]出荷
  1. フォーク:
    • 説明: フォークは分岐のうち、同じ方向を向いた分岐に使用します。 最終的に1つに統合される分岐です。
stateDiagram
    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 --> [*]
コード詳細 
stateDiagram
    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 --> [*]

ステートマシン図の例

以下は、ステートマシン図の例です。この例では、オブジェクトが開始状態から始まり、異なるトリガーによって状態が遷移するプロセスが示されています。

stateDiagram
  [*] --> Idle

  state Idle {
    [*] --> Ready : SystemInit
    Ready --> Processing : StartButtonPressed
    Ready --> [*] : StopButtonPressed
    Processing --> Completed : ProcessingComplete
    Completed --> [*] : ResetButtonPressed
  }

  state Processing {
    entry / StartProcessingAction
    exit / StopProcessingAction
  }

  state Completed {
    entry / ShowResultAction
  }

  [*] --> Idle

  state Idle {
    [*] --> Ready : SystemInit
    Ready --> Processing : StartButtonPressed
    Ready --> [*] : StopButtonPressed
    Processing --> Completed : ProcessingComplete
    Completed --> [*] : ResetButtonPressed
  }

  state Processing {
    entry / StartProcessingAction
    exit / StopProcessingAction
  }

  state Completed {
    entry / ShowResultAction
  }

  [*] --> Idle

  state Idle {
    [*] --> Ready : SystemInit
    Ready --> Processing : StartButtonPressed
    Ready --> [*] : StopButtonPressed
    Processing --> Completed : ProcessingComplete
    Completed --> [*] : ResetButtonPressed
  }

  state Processing {
    entry / StartProcessingAction
    exit / StopProcessingAction
  }

  state Completed {
    entry / ShowResultAction
  }

  [*] --> Idle
コード詳細 
stateDiagram
  [*] --> Idle

  state Idle {
    [*] --> Ready : SystemInit
    Ready --> Processing : StartButtonPressed
    Ready --> [*] : StopButtonPressed
    Processing --> Completed : ProcessingComplete
    Completed --> [*] : ResetButtonPressed
  }

  state Processing {
    entry / StartProcessingAction
    exit / StopProcessingAction
  }

  state Completed {
    entry / ShowResultAction
  }

  [*] --> Idle

  state Idle {
    [*] --> Ready : SystemInit
    Ready --> Processing : StartButtonPressed
    Ready --> [*] : StopButtonPressed
    Processing --> Completed : ProcessingComplete
    Completed --> [*] : ResetButtonPressed
  }

  state Processing {
    entry / StartProcessingAction
    exit / StopProcessingAction
  }

  state Completed {
    entry / ShowResultAction
  }

  [*] --> Idle

  state Idle {
    [*] --> Ready : SystemInit
    Ready --> Processing : StartButtonPressed
    Ready --> [*] : StopButtonPressed
    Processing --> Completed : ProcessingComplete
    Completed --> [*] : ResetButtonPressed
  }

  state Processing {
    entry / StartProcessingAction
    exit / StopProcessingAction
  }

  state Completed {
    entry / ShowResultAction
  }

  [*] --> Idle

アクティビティ図:

アクティビティ図は、システムやプロセスのワークフローを可視化するための図で、特にビジネスプロセスのモデリングに使用されます。アクティビティ図は、タスクの実行、意思決定、条件分岐、ループなど、様々なアクションを視覚的に表現します。このアクティビティ図にmermaid記法はサポートしていません。

アクティビティ図の構成要素:

  1. 開始状態 (Initial Node): プロセスやワークフローの開始を示します。
  2. 終了状態 (Final Node): プロセスやワークフローの終了を示します。
  3. アクション (Action): タスクや処理を表します。
  4. パーティション (Partition): 実行者や役割を区別するための枠です。
  5. オブジェクトノード (Object Node): オブジェクトの生成や使用を示します。
  6. ディシジョンノード (Decision Node): 条件分岐を表現します。
  7. マージノード (Merge Node): 分かれた流れを再度一緒にします。
  8. フォークノード (Fork Node): 同時に複数のフローに分かれます。
  9. ジョインノード (Join Node): 分かれたフローを結合して進行します。

マージノードとジョインノードの違い:

  • マージノード: 同時に進行した非同期のフローを、他方を待たずに進行することができます。
  • ジョインノード: 分かれたフローがここで再び結合され、進行します。このノードでは、他方がジョインノードに到達するまで待つ必要があります。つまり同期的な結合を表します。

データベース設計

データベース設計は、データベースの構造を計画し、組織化するプロセスです。これにはデータの表現方法、データの関連性、データの整合性などが含まれます。データベース設計は、効率的で信頼性の高いデータベースを構築するために不可欠です。

リレーションとその具体例

リレーションは、データベースのテーブル間の関連性を示します。主なリレーションには以下の種類があります。

  1. 1対n (One-to-Many):

    • 具体例: 1つの部署には複数の従業員が所属する。部署テーブルと従業員テーブルの関係。

  2. n対n (Many-to-Many):

    • 具体例: 複数の学生が複数の科目を履修する。学生テーブルと科目テーブルの関係。

  3. n対1 (Many-to-One):

    • 具体例: 複数の注文が1つの顧客に関連付けられる。注文テーブルと顧客テーブルの関係。

ER図とは

ER図（Entity-Relationship Diagram）は、データベースの設計を視覚的に表現するためのモデリングツールです。この図は、エンティティ（テーブル）、リレーションシップ（テーブル間の関連）、属性（列）などを含みます。

mermaid記法での表し方

テーブルの表し方

PKはPrimary Keyの意味で、そのテーブルの中で唯一の項目です。またFKは外部のテーブルにあるキーのことを指します。

erDiagram
  "部署" {
    string ID PK
    string name
  }
  "社員" {
    string ID PK
    string name
    string DepartmentID FK
  }
コード詳細 
erDiagram
  "部署" {
    string ID PK
    string name
  }
  "社員" {
    string ID PK
    string name
    string DepartmentID FK
  }

1対nの表し方

erDiagram
  "部署" {
    string ID PK
    string name
  }
  "社員" {
    string ID PK
    string name
    string DepartmentID FK
  }
  "部署"　||--|{ "社員": "所属"
コード詳細 
erDiagram
  "部署" {
    string ID PK
    string name
  }
  "社員" {
    string ID PK
    string name
    string DepartmentID FK
  }
  "部署"　||--|{ "社員": "所属"

説明:

  • 部署が一つに対し、社員が複数いる1対nの関係を表しています。
  • 1以上1以下の場合、横線２つ書きます。
  • 1以上の多(n)の場合、三叉に分かれたものを書きます。

n対nの表し方

各科目は複数人の学生が履修し、また学生は複数の科目を履修していることをn対nで表しています。

erDiagram
  "学生" {
    string ID PK
    string name
  }
  "科目" {
    string ID PK
    string name
  }
  
  "学生" }|--o{"科目":"履修"
コード詳細 
erDiagram
  "学生" {
    string ID PK
    string name
  }
  "科目" {
    string ID PK
    string name
  }
  
  "学生" }|--o{"科目":"履修"

n対1の表し方

顧客は注文を複数出せるが、注文それぞれは各顧客からしか出せないため、n対1の関係になっている。

erDiagram
  "顧客" {
    string ID PK
    string name
  }
  "注文" {
    string ID PK
    date date
    string customerID FK
  }
  "注文" }|--|| "顧客":"注文"
コード詳細 
erDiagram
  "顧客" {
    string ID PK
    string name
  }
  "注文" {
    string ID PK
    date date
    string customerID FK
  }
  "注文" }|--|| "顧客":"注文"

n対nのデータベース設計のアンチパターン

n対nのデータベースを設計する際、相手のDBのidを並べるカラムを使うのは避けるべきアンチパターンです。代わりに、中間テーブル（または交差テーブル）を使用することで、クリーンで拡張可能な設計を実現できます。

データベース設計のアンチパターン

erDiagram
  "学生" {
    string ID PK
    string name
    string subject_ID1 FK
    string subject_ID2 FK
  }
  "科目" {
    string ID PK
    string name
    string student_ID1 FK
    string student_ID2 FK
  }
  
  "学生" }|--o{"科目":"履修"
コード詳細 
erDiagram
  "学生" {
    string ID PK
    string name
    string subject_ID1 FK
    string subject_ID2 FK
  }
  "科目" {
    string ID PK
    string name
    string student_ID1 FK
    string student_ID2 FK
  }
  
  "学生" }|--o{"科目":"履修"

データベース設計の良い例

erDiagram
  "学生" {
    string ID PK
    string name
  }

  "学生_科目" {
    string studentID FK 
    string subjectID FK
  }
  

  "科目" {
    string ID PK
    string name
  }
  
  "学生"||--o{ "学生_科目": ""
  "科目"||--|{ "学生_科目": ""
コード詳細 
erDiagram
  "学生" {
    string ID PK
    string name
  }

  "学生_科目" {
    string studentID FK 
    string subjectID FK
  }
  

  "科目" {
    string ID PK
    string name
  }
  
  "学生"||--o{ "学生_科目": ""
  "科目"||--|{ "学生_科目": ""

mermaid記法で扱えるその他の図

以下は、mermaid 記法を使用してその他の図を表現した例です。具体的な使用方法などは、こちらのサイトを見てください。

フローチャートの例

graph LR;
  A[開始] -->|条件1| B[タスク1]
  B -->|条件2| C[タスク2]
  C --> D[終了]
コード詳細 
graph LR;
  A[開始] -->|条件1| B[タスク1]
  B -->|条件2| C[タスク2]
  C --> D[終了]

説明:

  • フローチャートを始めるために graph TD; を使用します。
  • A[開始] から始まり、条件によって B[タスク1] または C[タスク2] に進むフローチャートです。

ユーザージャーニー図の例

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

説明:

  • journey キーワードを使用してユーザージャーニー図を始めます。
  • title で図のタイトルを指定し、section で各セクションを定義します。
  • 各行はユーザーの行動やサービスの流れを示します。

Requirement Diagramの例

requirementDiagram

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

element test_entity {
type: simulation
}

test_entity - satisfies -> test_req
コード詳細 
requirementDiagram

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

element test_entity {
type: simulation
}

test_entity - satisfies -> test_req

説明:

  • erDiagram キーワードを使用して Requirement Diagram を始めます。
  • entity で各エンティティ（ここでは「タスク」と「ユーザー」）を定義します。
  • 各エンティティの属性や関連を記述します。

Gantt diagramsの例

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
コード詳細 
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

説明:

  • gantt キーワードを使用して Gantt ダイアグラムを始めます。
  • title で図のタイトルを指定し、section で各セクションを定義します。
  • 各セクション内で作業の期間を指定します。

まとめ

このドキュメントでは、Unified Modeling Language (UML) を中心に、mermaid記法を用いて様々なモデリング図について説明しました。

ユースケース図では、システムの外部から見た機能をアクターとユースケースの相互作用として表現し、クラス図では抽象化を通じて論理的なモデルを示しました。シーケンス図ではオブジェクト同士の相互作用を順序立てて描写し、ステートマシン図ではオブジェクトの状態遷移を示しました。

アクティビティ図はアクションのフローを表し、データベース設計においてはER図がエンティティとリレーションを通じてデータ構造を表現します。その他にもフローチャート、ユーザージャーニー図、Requirement Diagram、Gantt diagramsなど、様々なモデリング図があります。

これらのモデリング図を理解することで、ソフトウェア開発やシステム設計のコミュニケーションが円滑に進み、プロジェクトの成功に寄与します。各図は異なる側面や視点を提供し、開発者や関係者が共通の理解を築くのに役立ちます。

「Mermaid.jsとChar.jsを比較して学ぶ」の第二回では、Chart.jsの使い方について学んでいきます。



参考文献
  1. mermaid記法のチートシート
  2. ビジネスやDXの共通言語 UMLとは何か
  3. データベース設計入門#1 リレーションとER図【11分でマスター！DB設計】