teacher asking a question to the class
Photo by Max Fischer on Pexels.com

【授業レポート】システム開発(2年) 第34週目 〜UML設計:クラス図とシーケンス図で「構造」と「振る舞い」を描く〜

第34週目は、先週まとめた要求定義を受けてUMLを使った設計実習を行いました。今回は「クラス図で構造を整理」「シーケンス図で処理の流れを可視化」することが狙い。チームごとの設計力を一気に高める実践的な回です。


■ 先生の導入:「図にすれば見えてくることがある」

田中先生:「設計は言葉だけだと伝わりにくい。クラス図で『何があるか』を、シーケンス図で『どう動くか』を描けば、チーム全員の理解が揃います。」

先生はホワイトボードに簡潔な例(図書館システムの主要クラスと貸出シーケンス)を示し、UMLの目的と使いどころを解説しました。


■ 今日のポイント(短く)

  • クラス図:クラス(属性・操作)、関係(関連/集約/継承)、多重度を明確にする。
  • シーケンス図:オブジェクトのやり取りを時間軸で表し、メッセージの順序と責務を示す。
  • 図は「設計の約束」。コードに落とす前にチームで合意することが大切。

■ 実習①:クラス図を描く(90分)

手順

  1. 要求定義(ユーザーストーリー・受け入れ条件)を再確認。
  2. 必要なエンティティ(クラス)を洗い出す。
  3. 各クラスの属性(データ)とメソッド/操作(振る舞い)を定義。
  4. クラス同士の関係(関連/依存/継承/集約)と多重度(1、0…* など)を記入。
  5. 図を班内でレビューし、コメントを反映して修正。

例(図書館システムの抜粋)

  • Book (title, author, is_available) + lend(), return_book()
  • Member (name, member_id) + borrow(book), give_back(book)
  • Library (books:list) + find_book(title), register_book(book)
  • Member —(借りる)→ Book (多重度:Member 1 — 0…* Book)

生徒の気づき:「属性と操作を分けて書くと、実装時のメソッドが自然に決まる」「多重度を書くことでUIでの表示設計も見えてきた」


■ 実習②:シーケンス図で主要シナリオを可視化(80分)

対象シナリオ(班ごとに選択)

  • 本を検索して貸出するフロー(Search → Borrow)
  • 返却と延滞チェックのフロー(Return → CheckOverdue)
  • 外部API(天気等)を参照して結果を表示するフロー(API呼び出し含む)

描き方のポイント

  • ライフライン(オブジェクト)を並べ、左から右へ責務の流れを配置。
  • メッセージ(同期/非同期)を矢印で示す。戻り値や例外フローも忘れずに。
  • 条件分岐やループはフレーム(alt / loop)で表現する。

例の一部(擬式)

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

生徒のコメント:「シーケンス図を書くと、UIでどのボタンが何を呼ぶかまで自然に整理できた」「例外(在庫なし)の取り扱いが最初から明確になって、実装ミスが減りそう」


■ レビューとフィードバック(30分)

各班のクラス図・シーケンス図をホワイトボードに貼り、相互レビューを実施。チェックポイントは以下。

  • 要件と図の対応が取れているか(抜けはないか)
  • 責務分離ができているか(単一責任の原則)
  • 例外・異常系の振る舞いが図示されているか
  • 図が実装に落とせる具体性を持っているか

田中先生の指摘例:「Library に全てのロジックを詰め込みすぎないこと」「検索結果のキャッシュは別クラス(CacheManager)で扱うと責任が明確になる」


■ 先生のひとこと

「設計図はコミュニケーションツールです。コードを書く前に『これで合っているか』をチームで合意することで、実装時間の無駄を大幅に減らせます。図は何度でも書き直して良いのです—重要なのは合意すること。」


■ 宿題(次週の準備)

  1. 班の最終版クラス図(PNG or PDF)代表的シーケンス図1つを提出。
  2. クラス設計に基づく**ファイル構成案(モジュール分割)**を作成(例:models/, services/, ui/)。
  3. 次回に備え、簡単な**ER図(テーブルと主キー)**の草案を1枚用意。

■ 来週の予告:データベース設計(ER図)と永続化の落とし込み

次週はUMLで決めた構造を**データベース設計(ER図)**に落とし込み、テーブル設計と簡単なマイグレーション案を作ります。クラスの属性がどのように永続化されるかを考える実務的な回です。今日のUML設計が基盤になります—しっかりまとめてきてください!


UMLで「何を作るか」と「どう動くか」をチームで可視化した34週目。生徒たちは設計図を通じて実装前の合意形成の重要性を体感し、次の段階(データ設計)へ準備を整えました。

投稿者 greeden

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)