広告 要件定義・設計

【設計シリーズ:11】 クラス図 - システムの骨格を視覚化する設計の羅針盤

【設計シリーズ:11】 クラス図 - システムの骨格を視覚化する設計の羅針盤

概要

フリーランスエンジニア スリーネクスト

オブジェクト指向設計の要である「クラス図」について解説します。システムの静的な構造を示すクラスの基本要素や関係性(関連、汎化など)を整理し、テキストベースで作図できるMermaid記法を具体的な横書きサンプル付きで紹介。

さらに、チームでの設計レビューや共同編集を円滑にする作図ツール「Cacoo」の優位性にも言及し、Mermaidとの賢い使い分けを提案します。個人の思考整理からチームの合意形成まで、設計の質を高めるための知識とツール選択の指針を提供します。

はじめに

ソフトウェアという複雑な構造物を築き上げる上で、その根幹をなす「設計図」の価値は計り知れません。本「設計シリーズ」の第11回では、オブジェクト指向設計の心臓部、クラス図に光を当てます。

クラス図は、システムの静的な構造、すなわち、どのような「モノ」(クラス)が存在し、それぞれがどんな情報(属性)と振る舞い(操作)を持ち、互いにどう関係しているのかを視覚的に表現するUMLの図です。それはシステムの骨格であり、開発者間の共通言語として、実装のブレを防ぐ羅針盤の役割を果たします。

本記事では、クラス図の基本概念を解説した後、テキストから図を生成するツールMermaidを用いた記述方法と、実践的なサンプル構成図のアイデアを提示します。さらに、テキストベースのMermaidの利便性に触れつつ、チームでの共同作業を飛躍的に効率化するビジュアルコラボレーションツール**「Cacoo」**の魅力もご紹介します。この記事を読めば、クラス図の本質を掴み、プロジェクトの状況に応じて最適なツールを選択する知見が得られるでしょう。

第1部: クラス図の基礎 - システムの構成要素を理解する

クラス図を読み書きするためには、まずその構成要素と記法を理解することが第一歩です。

1. クラス:オブジェクトの設計図

クラスとは、オブジェクトの設計図です。例えば「顧客」というクラスは、「田中さん」「鈴木さん」といった具体的な顧客オブジェクトが共通して持つべき特性を定義したものです。クラス図では、クラスは3つの区画を持つ長方形で表現されます。

  • クラス名: 「Customer」「Product」など、クラスの名前。
  • 属性 (Attribute): クラスが持つデータ。「顧客ID」「氏名」「住所」など。
  • 操作 (Operation): クラスができる振る舞い。「ログインする()」「商品を購入する()」など。

また、属性や操作には、外部からのアクセス可否を示す可視性を付与します。

  • + Public: 公開。どこからでもアクセス可能。
  • - Private: 非公開。そのクラス内部からのみアクセス可能。情報の隠蔽に重要。
  • # Protected: 保護。そのクラスとサブクラス(継承先)からアクセス可能。

---------------------
|      Customer     |
---------------------
| - customerId: String |
| - name: String      |
---------------------
| + login(): boolean  |
| + purchase(): void  |
---------------------

2. クラス間の関係性

クラス図の真価は、複数のクラスがどのように連携するかを示す関係性の表現にあります。

  • 関連 (Association): クラス間の一般的なつながり。実線で表現します。「顧客」と「注文」は、「顧客が注文する」という関連で結ばれます。線の端には多重度1, * (0以上), 1..* (1以上)など)を記述し、インスタンス間の数量関係を示します。 Customer "1" -- "0..*" Order (一人の顧客は0個以上の注文を持つ)
  • 集約 (Aggregation): 「全体」と「部分」の関係で、部分が全体から独立して存在できる場合に使います。「サークル」と「学生」の関係が好例です。サークルが解散しても学生は存在し続けます。全体側に白抜きの菱形(◇)を付けます。 Circle ◇-- Student
  • コンポジション (Composition): より強い「全体」と「部分」の関係で、全体と部分が運命を共にします。「注文」と「注文明細」の関係のように、注文が消えれば注文明細も消滅します。全体側に黒塗りの菱形(◆)を付けます。 Order ◆-- OrderDetail
  • 汎化 (Generalization): いわゆる「継承」です。一般的なクラス(親)と、それを具体化したクラス(子)の関係(is-a関係)を示します。「正社員」と「アルバイト」は共に「従業員」の一種です。子から親へ白抜きの三角矢印(△)で表現します。 FullTimeEmployee --|> Employee
  • 実現 (Realization): インターフェース(仕様のみを定義)とその実装クラスの関係です。「印刷可能」というインターフェースを「レポート」クラスが実装する、といったケースで用います。実装クラスからインターフェースへ破線の三角矢印(△)で表現します。 Report ..|> Printable

第2部: Mermaidによるクラス図 - テキストが生み出す設計図

これらのクラス図を、近年ではMermaidのようなテキストベースのツールで作成する流れが加速しています。Mermaidは、Markdownに似たシンプルな構文で、クラス図を含む様々なダイアグラムを生成できるライブラリです。

Mermaidのメリット:

  1. 学習が容易: 直感的な構文ですぐに書き始められます。
  2. バージョン管理: テキストなのでGitで差分管理が非常に簡単です。
  3. ドキュメント親和性: GitHubのREADMEやWikiに直接埋め込めます。
  4. 高速な記述: キーボード操作だけで素早く思考を形にできます。

Mermaidの基本構文: classDiagramで開始し、クラス定義と関係性を記述していきます。

classDiagram
  direction LR
  class Customer {
    -customerId: string
    -name: string
    +login()
  }
  class Order {
    -orderId: string
    -orderDate: date
  }

  %% 関係性の定義
  Customer "1" -- "0..*" Order : places

関係性は クラスA [多重度] -- [多重度] クラスB : ラベル のように記述します。汎化は <|--、コンポジションは *-- のように、記号を使い分けるだけで簡単に関係性を表現できます。

第3部: 実践!Mermaidクラス図サンプル構成図

理論だけでは掴みづらいので、具体的なアプリケーションを想定したサンプルを2つ見ていきましょう。

サンプル1: ECサイト

ECサイトは、クラス図の基本的な関係性を網羅しており、最初の練習台として最適です。

主要なクラス: Customer(顧客)、Product(商品)、Order(注文)、OrderDetail(注文明細)、ShoppingCart(買い物かご)

関係性のポイント:

  • CustomerOrder: 1対多の関連
  • OrderOrderDetail: 1対多のコンポジション
  • CustomerShoppingCart: 1対1のコンポジション
  • ShoppingCartProduct: 多対多の集約
  • PremiumCustomerCustomer: 汎化

Mermaidコード例:

classDiagram
  direction LR
  class Customer {
    -customerId: string
    -name: string
    +login()
  }
  class PremiumCustomer {
    -membershipLevel: int
    +getDiscount(): float
  }
  class Order {
    -orderId: string
    -orderDate: date
    +calcTotalPrice()
  }
  class OrderDetail {
    -quantity: int
  }
  class Product {
    -productId: string
    -price: int
  }
  class ShoppingCart {
    +addProduct(product)
    +checkout()
  }

  Customer <|-- PremiumCustomer

  Customer "1" -- "0..*" Order : places
  Customer "1" *-- "1" ShoppingCart : has

  Order "1" *-- "1..*" OrderDetail : contains
  OrderDetail "1" -- "1" Product : refers to

  ShoppingCart o-- "*" Product : items

この図は、システムの主要なエンティティ間の静的な構造と責務分担を明確に示しており、開発の初期段階における共通認識の形成に大きく貢献します。

サンプル2: ブログシステム

ブログシステムは、再帰的な関係や多対多の関連など、少し応用的なモデリングの練習に適しています。

主要なクラス: User(ユーザー)、Post(記事)、Comment(コメント)、Category(カテゴリ)、Tag(タグ)

関係性のポイント:

  • UserPost: 1対多の関連
  • PostComment: 1対多のコンポジション
  • Comment同士: 再帰的な関連(コメントへの返信)
  • PostTag: 多対多の関連

Mermaidコード例:

classDiagram
  direction LR
  class User {
    -userId: string
    -username: string
  }
  class Post {
    -postId: string
    -title: string
    -content: string
  }
  class Comment {
    -commentId: string
    -body: string
  }
  class Category {
    -categoryId: string
    -name: string
  }
  class Tag {
    -tagId: string
    -name: string
  }

  User "1" -- "0..*" Post : authors
  Post "1" *-- "0..*" Comment : has

  %% コメントへの返信を表現
  Comment "0..1" -- "0..*" Comment : replies to

  Post "*" -- "1" Category : belongs to
  Post "*" -- "*" Tag : is tagged with

多対多の関係(PostTag)は、概念モデルとしてこのように表現します。この図から、実装時には中間テーブルが必要になることなどを読み取ることができます。

第4部: Cacooという選択肢 - チームの設計力を最大化する

Mermaidは個人の思考整理やドキュメント化に非常に強力なツールです。しかし、ソフトウェア開発はチームで行うもの。複数のメンバーでアイデアを出し合い、レビューを重ね、設計の合意形成を図るコラボレーションのフェーズでは、Mermaidのテキストベースという特性が逆に足かせになることもあります。

そこでご紹介したいのが、ビジュアルコラボレーションツール**「Cacoo(カクー)」**です。Cacooは、Mermaidが「コードを書く」感覚なら、「チームでホワイトボードを囲む」感覚で設計を進められるツールです。

なぜ、チーム設計にCacooが最適か?

  1. 直感的で自由な作図体験 Cacooの魅力は、誰でもすぐに使える直感的な操作性です。UMLの豊富なテンプレートやステンシル(図形パーツ)が用意されており、ドラッグ&ドロップで線をつなぐだけで、簡単に整ったクラス図が作成できます。Mermaidの構文を覚える必要はありません。 また、自動レイアウトでは難しい、意図を込めた配置調整や色分け、補足説明の追加なども自由自在。これにより、「設計の意図」をより明確に伝えられます。
  2. 設計を加速させるリアルタイム共同編集 Cacooの真骨頂は、複数人が同じキャンバスで同時に図を編集できる機能です。誰がどこを編集しているかリアルタイムに分かり、まるで同じ部屋で作業しているかのような一体感が得られます。図を見ながらビデオ通話やコメント機能で議論すれば、リモート環境でも設計レビューが劇的に効率化します。「ここの関連は本当に正しい?」「このクラスの責務は多すぎない?」といったフィードバックを、図の特定の部分を指し示しながら行えるのです。
  3. 設計資産の一元管理と共有 作成した図は、Cacoo上でバージョン管理され、いつでも過去の状態に戻せます。さらに、プロジェクト管理ツールのBacklogや情報共有ツールのConfluenceなどと強力に連携し、関連タスクやドキュメントに設計図を直接埋め込めます。これにより、情報が分散することなく、設計資産を一元的に管理できます。

MermaidとCacooの賢い使い分け

どちらかが優れているという話ではなく、適材適所で使い分けるのが賢い選択です。

  • Mermaidが輝くシーン: 個人の思考整理、Gitでの厳密なバージョン管理、技術ドキュメントへの埋め込み。
  • Cacooが輝くシーン: チームでのブレインストーミング、設計レビュー、公式な設計ドキュメントの作成、非エンジニアへの説明。

おすすめは、まず個人がMermaidで素早くドラフトを作成し、それをチームでの議論のたたき台としてCacooに持ち込むワークフローです。Mermaidの手軽さと、Cacooの協調性を組み合わせることで、開発プロセス全体がスムーズになります。

まとめ: 設計という対話のためのツールを選ぶ

今回見てきたように、クラス図はシステムの構造を表現するだけでなく、**開発者間の円滑なコミュニケーションを促す「対話のツール」**です。

Mermaidはその対話をテキストで迅速かつ正確に記録し、Cacooはその対話自体をより豊かで創造的なものにする場を提供します。

あなたのプロジェクトが求めるのは、個人の思考の高速なアウトプットですか? それとも、チームの知性を結集させるクリエイティブな議論の場ですか?

ぜひ、この記事を参考にクラス図の作成に挑戦してみてください。そして、チームでの設計に壁を感じたなら、Cacooがその壁を打ち破る強力な武器になるはずです。適切なツールを選択し、良質な設計という礎の上に、成功するソフトウェアを築き上げてください。

-要件定義・設計