【授業レポート】システム開発（2年）第34週：UMLのクラス図とシーケンス図で設計を整理

システム開発（2年）の第34週では、前週に整理した要求定義を設計へつなげるため、UMLを使った実習に取り組みました。

UMLは、システムの構造や処理の流れを図で共有するための表記法です。今回は、クラス図で「何があるか」を整理し、シーケンス図で「どの順番でやり取りするか」を確かめました。二つの図を組み合わせることで、コードを書く前にチーム内の認識のずれを見つけやすくなります。

クラス図とシーケンス図で確認すること

田中先生は図書館システムを例に、主要なクラスと貸出時のやり取りをホワイトボードに示しました。授業で扱った二つの図には、次の役割があります。

クラス図だけでは、操作がどの順番で呼ばれるかまでは分かりません。シーケンス図だけでは、各オブジェクトがどのデータと操作を持つかを一覧しにくくなります。構造と処理の流れを分けて描き、最後に対応を確かめることが今回の狙いです。

実習1：クラス図でシステムの構造を整理

クラス図は、システムを構成するクラスと、それぞれが持つデータや操作、クラス間の関係を表します。授業では90分を使い、要求定義から実装の候補となるクラスを見つけるところから始めました。

クラス図を作る手順

1. ユーザーストーリーと受け入れ条件を読み直し、必要な機能を確認する。
2. 機能に登場する対象を洗い出し、クラスの候補にする。
3. 各クラスが保持する属性と、実行する操作を分けて書く。
4. 関連、依存、継承、集約など、クラス同士の関係を記入する。
5. 一対一、一対多などの対応数を示す多重度を加える。
6. 班内で図を読み合わせ、要件の抜けや役割の偏りを修正する。

図書館システムの例

授業では、図書館システムの一部を次のように整理しました。英語名は実装を想定したクラス名、属性名、操作名です。

たとえば「会員1人に対して、本が0冊以上対応する」と考えた場合は、Member 1とBook 0..*のように多重度を書きます。0..*は「0件でもよく、複数件でもよい」という意味です。数を図に書くと、一覧に何件表示するか、対象がない場合をどう扱うかも検討しやすくなります。

属性と操作を分ける作業からは、「どのクラスが何を担当するか」が見えてきます。ただし、図からメソッドが機械的に決まるわけではありません。要求と照らし合わせ、実装する操作の候補を班で確かめることが必要です。クラス図を実装へつなぐ例は、UMLクラス図からPython実装とテストへ進んだ授業でも紹介しています。

実習2：シーケンス図で処理の流れを確認

シーケンス図は、処理に参加するオブジェクトを横に並べ、時間の流れに沿ってメッセージの順番を表す図です。授業では80分を使い、班ごとに主要なシナリオを一つ選んで作図しました。

班ごとに選んだシナリオ

• 本を検索し、貸し出すまでの流れ
• 本の返却と延滞確認の流れ
• 天気などの外部APIを呼び出し、結果を表示する流れ

図に書く要素

ライフライン

利用者やオブジェクトなど、処理に参加するものを表します。

メッセージ

オブジェクト間の呼び出しや返答を矢印で表します。授業では同期と非同期を区別し、戻り値も確認しました。

altフレーム

在庫がある場合とない場合など、条件によって処理が分かれる場面を表します。

loopフレーム

一覧の各項目を処理する場合など、同じやり取りを繰り返す場面を表します。

図書館システムの検索処理は、簡略化すると次の順序になります。

User -> Library: find_book(title)
Library -> Book: check availability
Book --> Library: available / not available
Library -> User: return list / "該当なし"

この例では、利用者の検索要求を受けたLibraryがBookの貸出可否を確認し、その結果に応じて一覧または「該当なし」を返します。正常に見つかる流れだけでなく、対象がない場合も同じ図に置くことで、実装前に例外時の応答を確認できます。

二つの図を照らし合わせるレビュー

作図後の30分は、各班のクラス図とシーケンス図をホワイトボードに貼り、相互レビューを行いました。レビューでは図の見た目より、要求、構造、処理の流れがつながっているかを確かめます。

単一責任の原則は、一つのクラスに役割を集めすぎないための考え方です。レビューでは、Libraryにすべての処理を持たせず、検索結果のキャッシュはCacheManagerのような別クラスへ分ける案が示されました。役割を分けるかどうかは、クラス名を増やすこと自体ではなく、それぞれの担当を説明できるかで判断します。

田中先生は、設計図をチームのコミュニケーションに使い、コードを書く前に「この構造と流れでよいか」を合意するよう伝えました。最初の図を完成形と考えず、レビューで見つかったずれを直していくことが授業の到達点です。

宿題と次週への準備

1. 班の最終版クラス図をPNGまたはPDFで提出する。
2. 代表的なシーケンス図を一つ提出する。
3. クラス設計に基づき、models/、services/、ui/などのファイル構成案を作る。
4. テーブルと主キーを示した簡単なER図の草案を一枚用意する。

次週は、UMLで整理した構造をデータベースへつなげます。クラスの属性をどのテーブルに保存するかを考え、ER図とマイグレーション案へ落とし込みます。続きは、第35週のデータベース設計とER図の授業で確認できます。

第34週の振り返り

第34週は、要求定義をクラス図とシーケンス図へ変換し、構造と処理の流れを別々に確かめました。設計図の役割は、きれいな図を完成させることだけではありません。実装前に要件の抜け、責務の偏り、例外時の動きを話し合える状態をつくることにあります。