FUKUOKA UNIV. / NAKANISHI / FINAL EXAM

情報処理システム開発／ソフトウェア工学
期末試験 対策シート

出題5類型 → 論点整理 → 過去問（2025/07/25）完全解答。答えは黒塗り部分をタップすると出ます。
TYPE 1オブジェクト指向とUMLの知識確認：◯×問題
TYPE 2ユースケース記述から、シーケンス図・ステートマシン図・ユースケース図を完成
TYPE 3ユースケースの拡張（extend）と挿入（include）
TYPE 4日本語の説明どおりにクラス図を完成（多重度必須）
TYPE 5用語の穴埋め

01◯×で狙われる論点と、ひっかけの型

◯×は「定義の主語・向き・数」をすり替えてくる。下表の右列（ひっかけ）を先に覚えると、本番では文の1か所を見るだけで判定できる。

論点正しい理解よく出るひっかけ（＝×になる書き方）
コミュニケーション図の四角オブジェクト（インスタンス）。名前は「オブジェクト名：クラス名」で下線付き。「四角はクラスを表す」→ ×
多重度の読み方反対端のインスタンス1個に対して、当該端のインスタンスがいくつ対応するか。「m個にn個が関連している」のようなm対nの総数解釈 → ×
コンポジション◆側が全体。全体が消滅すると部分も消滅（生存期間が等しい）。◆の向きを逆にする／「部分が消えると全体も消える」→ ×
集約全体と部分だが生存期間は別。全体が消えても部分は残る（白抜き◇）。集約なのに「一緒に削除される」→ ×
汎化の向き「BはAの一種」と読めるなら、AがBを汎化したもの（A＝親、B＝子）。親子を入れ替える → ×。文を「〜の一種」に直して読むのがコツ。
継承下位クラスは上位クラスの属性・振舞いをすべて持ち、さらに追加できる。「一部だけ継承」「追加できない」→ ×
プライマリアクタユースケースを起動するアクタ。一連の相互作用を始める側。「後から参加するアクタ」（＝セカンダリアクタ）と入替 → ×
アクタ役割を表す。人でなくてもよい（外部システム・I/Oデバイス・タイマ）。1人が複数アクタを兼ねてよい。「アクタは個人を表す」「必ず人間」→ ×
ユースケース記述の粒度アクタとシステムの外部からのやりとりのみ。内部構造・内部処理は書かない。「内部の振舞いまで詳細に記述すべき」→ ×
ユースケース記述とUIアクタの意図を書く（「目覚ましを止める」）。「ボタンを押す」などUI操作の記述を推奨 → ×
同期メッセージ送信先の処理が完了する（応答が返る）まで送信元は次に進めない。非同期の説明とすり替え → ×
opt / alt / loop条件で生じたり生じなかったりする交換＝opt。多岐選択＝alt。繰返し＝loop。optとaltの入替、loopをoptに → ×
アクティビティ（do）ある状態に留まっている間に継続実行される処理。「遷移の際に実行」（＝アクション）と入替 → ×
アクション状態遷移の際に実行。所要時間は0。複数書けるが依存関係があってはならない。「状態にいる間ずっと実行」→ ×
entry / exitその状態に入る時／出る時に実行。遷移ではなく状態に付随。遷移に付随すると書く → ×
状態と時間状態遷移に要する時間は0。イベント処理中に割り込まれない。「遷移に時間がかかる」→ ×
初期状態／終了状態初期状態は必ず1個、終了状態は0個以上。「終了状態は必ず1個」→ ×
階層ステートマシン図常に平坦なステートマシン図に変換できる。可読性と抽象度分離のための記法。「変換できない」「表現力が増える」→ ×
階層制御パターン複数の制御コンポーネントがあり、うち1つが他を調停して全体を司る（上下関係あり）。「上下関係のない同格」→ それは分散制御。×
集中制御パターン1つの制御コンポーネントが有限状態機械として全体を司る。「複数の制御コンポーネント」→ ×
extend / includeextend：基底は拡張なしでも機能する／基底は拡張先を知らない。include：基底は挿入なしでは機能しない／基底が明示的に指定。この4点の入替が定番 → 表で暗記（§3）
静的メンバ／オブジェクト名どちらも下線。静的属性は全インスタンス共通の値。「太字」「斜体」など表記のすり替え → ×
分析と設計の分担分析＝What（クラス・関連・多重度・メッセージ内容）。設計＝How（並行性・同期/非同期・パラメータ・可視性）。「分析で同期／非同期を決める」→ ×
◯×の即断ルール：①「クラス」と「オブジェクト」②「全体」と「部分」③「親」と「子」④「送信元」と「送信先」⑤「遷移時」と「滞在中」──この5組のどれかが入れ替わっていないかだけを見る。入れ替わっていれば×。

02ユースケース：図・記述・粒度

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

  • アクタ：システムの外側でシステムと関わるステークホルダ。人／外部システム／外部I/Oデバイス／タイマ（時の経過を告げる「時間の神様」）。
  • ユースケース：システムの機能を「アクタとの相互作用」として表したもの。「〜する」と動詞で終わる名前。
  • SuC（System under Consideration）：開発対象を囲む四角。アクタは必ずその外側。
  • アクタの汎化可（会員 ← 個人会員／法人会員）。パッケージで機能別に整理してもよい。
  • ステレオタイプ《primary actor》《secondary actor》で種別を表記できる。

ユースケース記述の記載項目（順番ごと覚える）

項目内容
ユースケース名「〜する」と動詞で終わる名前。
概要1〜2文の簡単な説明。
アクタ関係するアクタ名（primary / secondary）。
依存関係他ユースケースを include / extend するか。
事前条件開始時に充たされているべき条件。
主シーケンス開始から成功裏に終わるまでの、最も代表的なやりとり。番号付き。
代替的シーケンス条件処理・エラー処理などの副次的なやりとり。どのStepから分岐するかを書く。
事後条件主シーケンス終了時に充たされているべき条件。
未解決の課題議論中の事項。
良い記述の型
「主語 ＋ 修飾語 ＋ 目的語 ＋ 述語」。主語を必ず書く。芝居の台本のように観客の視点で、システムとアクタを外から見て書く。各行はだいたい次の4パターンのどれか：
①アクタが要求とデータを送る ②システムが確認する ③システムが内部状態を変更する ④システムが結果を返す
ダメな記述4パターン
①内部処理を書く（「時レジスタに設定する」）
②UI操作を書く（「時ボタンを押す」→「時刻を進める」）
③やりとりの手段を書く（入力指示→入力→…）→ 何の情報をやりとりするかだけ書く
④主語がない／粒度が細かすぎる（一操作＝一ユースケース）
「〜かどうかをチェックする」は「〜を確認する」に直す。チェックと書くと、正しかった場合と正しくなかった場合を冗長に書く必要が生じるため。

モデリングの基本姿勢（記述問題で効く一言）

唯一解はなく、大多数が納得する「納得解」を目指す。理解と意思疎通のために描くのだからわかりやすさこそ正義。書きすぎも書かなすぎも誤り。

03ユースケースの拡張（extend）と挿入（include）

出題は「どちらを使うか」「矢印の向き」「拡張点の位置」「展開後のシーケンス」。この表を丸暗記すれば全部解ける。

観点extend（拡張）include（挿入）
意味相互作用列の外からの追加相互作用列の中からの挿入
基底だけで動くか動く（拡張ユースケースは無くてもよい）動かない（挿入ユースケースなしには機能し得ない）
相手を知っているか基底はどの拡張に拡張されるか知らない基底が明示的に指定する
矢印の向き（UML）拡張 --《extend》--> 基底（子→親向き）基底 --《include》--> 挿入
拡張点基底の主シーケンス中に「拡張点：◯◯」と書く。展開時はそこが拡張側の相互作用列に置き換わる。基底の主シーケンスに「include ◯◯する」と1行書く。
条件ガード条件 [条件] を付けられる。条件が排他的なら1つの拡張点に複数の拡張を接続可。条件は付けない（必ず実行される）。
アクタ—挿入ユースケースは特定のアクタを想定しない
使いどころ条件実行部分・選択的実行部分・複雑／代替的な相互作用列を切り出す共通の相互作用列の重複排除／抽象度による分離
典型例「電話をかける」＋「電話帳で相手を指定する」「履修科目を登録する」／「個人成績を閲覧する」← 「ログインする」
展開問題の解き方：extendは拡張点の行を消して拡張側の主シーケンスを丸ごと差し込み、以降を番号振り直し。includeは「include 〜」の行を挿入側の主シーケンスに置換。どちらも展開後は1本の番号付きシーケンスにする。
1つのextendで拡張点が複数（n個）に分散してよい。その場合、拡張ユースケース中の同数の「拡張セグメント」が各拡張点に付け足される。extend関係の線自体は1本のまま。

04相互作用図：シーケンス図／コミュニケーション図

シーケンス図
メッセージのやりとりを時系列（上から下）で描く。順番が一目瞭然。ライフライン・実行オカレンス・イベントオカレンス・相互作用オカレンス（refで他図を参照）。
コミュニケーション図
オブジェクト間のつながりが一目瞭然。順番はシーケンス式（番号）を見ないと分からない。書式：シーケンス式：メッセージ名(引数)／戻り 型 = メッセージ名( )：戻り値。リカレンス 3*[j:=1,n]、条件 4[x<n]。

複合フラグメント（keywordの意味）

keyword意味keyword意味
opt条件実行（ガード条件成立時のみ）par並行実行
alt多岐選択critical割り込まれずに実行
loop繰返し実行seq異なるライフライン間で順序が厳守されない
break送信されると親フレームを中止strict送信順序を厳守

メッセージの種類

  • 非同期メッセージ：送信先の処理完了を待たずに次へ進める（細い開矢印）。
  • 同期メッセージ：送信先の処理が完了するまで次に進めない（黒塗り矢印）。同期メッセージ（戻り）は破線。
  • 生成メッセージ：オブジェクトを生成する（同期・非同期どちらもあり得る）。
穴埋めの解き方（超重要）：シーケンス図の空欄はユースケース記述の主シーケンスの番号と1対1で対応している。
① 主シーケンスを上から番号順に読む → ② 「誰が誰に」を確定（センサ／ボタン／タイマ → 制御、制御 → アクチュエータ） → ③ 選択肢を当てはめる。
繰り返しの指示（「4〜7を繰り返す」）があれば、その範囲を囲むフレームが loop。条件付き（「〜の場合」）なら opt／alt。
向きの原則：センサI/F・ボタンI/F・タイマ → 制御（報告・通知＝イベント）。制御 → ヒータI/F・表示器I/F・タイマ（指令・要求＝アクション）。「計時開始要求」は制御→タイマ、「計時完了通知」はタイマ→制御。名前の語尾で向きが決まる。

05ステートマシン図

記法の全部

要素書き方と意味
遷移ラベルイベント [ガード条件] / アクション, アクション　※アクション複数可・同時実行・依存関係を持たせない
イベント有限状態機械への入力。時間0のシグナル。ガード条件成立時のみ遷移を引き起こす。
タイマイベントafter(時間)　その状態に入ってから指定時間経過で発生。
アクション遷移の際に実行。所要時間0。
entry / exitentry / 処理 exit / 処理　状態に入る時／出る時。状態に付随。同じアクションが多数の遷移に重複するときの簡略化に使う。
アクティビティdo / 処理　その状態に留まっている間、継続して実行。状態に付随。
初期／終了状態●が初期状態（必ず1個）、◎が終了状態（0個以上）。
履歴状態 H最後に親状態を脱出したときの副状態に戻る。
階層化可読性向上＋抽象度別の記述。常に平坦な図に変換可能。親状態からの遷移は全副状態に共通して効く。
穴埋めの解き方（超重要）：制御オブジェクトのステートマシン図では
　イベント ＝ 制御オブジェクトが受け取るメッセージ（センサ・ボタン・タイマからの報告）
　アクション ＝ 制御オブジェクトが送るメッセージ（I/Fクラスへの指令）
これがシーケンス図との追跡可能性（トレーサビリティ）。だからシーケンス図を先に解いてから状態図を埋めると確実。
親状態から出る遷移を見落とさない。「どの状態にいても起こる異常（例：水位低下）」は、副状態ではなく親状態の境界から出す。逆に復帰の遷移は「1に戻る」＝どの副状態へ戻るかを代替シーケンスの記述から特定する。

状態非依存／状態依存

  • 状態非依存オブジェクト：入力メッセージだけで出力が決まる（→ 制御なら《coordinator》）。
  • 状態依存オブジェクト：同じ入力でも状態で出力が変わる（→《state dependent control》）。有限状態機械としてモデル化する。
  • 状態のある機械の定義：f(現在状態, 入力イベント)→次状態、g(現在状態, 入力イベント)→出力イベント。

06クラス図：日本語 → 図に変換する手順

変換の対応表（この訳し方を暗記する）

日本語の言い回しクラス図での表現
「AはBの一種である」汎化。B（親）△←A（子）。白抜き三角はいつも親側。
「Aは◯◯を属性として持つ」Aのクラス箱の2段目に - ◯◯。
「Aは1個以上のBで構成され、Aを削除すればBも削除される」コンポジション。A側に◆、A側多重度1、B側 1..*。
「Aは0個以上のBで構成され、Aを削除してもBは残る」集約。A側に◇、B側 *。
「1つのBは1つのAに属する」B側から見たAの多重度＝1。
「1人のAは0個以上のBを提供する」関連「提供する」、B側 *。
「1つのBは0人以上のAに提供される」同じ関連のA側 *。
関連の情報（成績・履修年度など）関連クラス（関連線に破線でぶら下げる）。
「〜としてのA」関連端名（旧・関連ロール名）。同じ2クラス間に複数の関連があるときに必須。
多重度の書き方：n＝n個、*＝0個以上、m..n＝m個以上n個以下、1..*＝1個以上。省略時は1。ただし試験では「関連には多重度を必ずつけること」と指示されるので両端に必ず記入。

手順（減点されない書き順）

  1. 文中の名詞をクラス候補として全部拾う（動詞は振舞い候補）。
  2. 「〜の一種」の文から汎化階層を先に決める。親を上に置く。
  3. 「属性として持つ」の文から属性を書き込む。
  4. 残りの文を1文＝1関連として線を引き、関連名（動詞）を書く。
  5. 各文の「1つの〜は◯個以上の…」を、反対端の多重度として書き込む。文が2つで1組（両方向）になっている。
  6. 「削除すると一緒に消えるか」で ◆（コンポジション）／◇（集約）を判定。

その他の記法（◯×でも出る）

  • 可視性：+ public（全クラス）／- private（自クラス）／# protected（自分と子）／~ package（同一パッケージ）。
  • 静的メンバは下線。オブジェクト名も下線（オブジェクト図では振舞い部を書かない、属性値は書いてよい）。
  • 再帰関連：自クラスへの二項関連（上司／部下）。関連端名で区別する。
  • 分析段階のクラスはクラス名のみでよい。実体クラスに振舞いは書かなくてよい（振舞いの決定は設計まで後回し）。
  • アクティブクラスは枠線を太く（他オブジェクトのオペレーションを自発的に呼べる）。パッシブクラスは通常の枠。

クラスの役割分類とステレオタイプ

分類役割ステレオタイプ
インターフェースクラス外部環境との窓口（境界オブジェクト）《interface》《device interface》《input device interface》《output device interface》《user interface》《system interface》
制御クラスオブジェクト群の監督役《control》《coordinator》《state dependent control》《timer》
実体クラス概念＝永続データの記録役《entity》《data abstraction》《database wrapper》
アプリケーションロジッククラスロジックの隠蔽《application logic》《business logic》《algorithm》《agent》
外部クラス（物理クラス）ソフトウェアの外側《external device》《external user》《external system》《external timer》《system》
標準入出力（キーボード・マウス・モニタ）は《external device》ではなく《external user》。／外部タイマは物理クラスだが、タイマクラスはソフトウェアの部品。両者は別物。

07ソフトウェアアーキテクチャのパターン

パターンは3分類（アーキテクチャパターン／デザインパターン＝マイクロアーキテクチャ／イディオム＝言語依存）。アーキテクチャパターンはさらに構造と通信に分かれる。パターンの三大観点は文脈・問題・解決策。

アーキテクチャ構造パターン（名前を答えさせる出題が定番）

パターン特徴（この一文で判定する）
階層構造パターン上位層が下位層のサービスを使う。直下のみ利用＝Strict、より下層も利用＝Flexible。例：OSI参照モデル、TCP/IP。
カーネルパターン核心的な基本機能をカーネルに閉じ込め、明確に定義された手続（システムコール）経由でのみアクセスさせる。
サーバ／クライアントサーバが要求に応じてサービス提供。多層もあり。
ブローカサーバとクライアントの間に仲介人。クライアントはサーバの所在を知らなくてよい＝疎結合。
サーバ／エージェント／クライアントエージェントが代理交渉する。
集中制御1つの制御コンポーネントが有限状態機械として全体を司る。I/Fクラス群が中央の制御クラスにぶら下がる形。
分散制御複数の制御コンポーネントが各自の役割を司り、同格でP2P通信。例：自動車のECU＋CAN。
階層制御複数の制御コンポーネントがあり、うち1つが他を調停して全体を司る。例：店頭端末全体制御＋UI制御／印刷制御／DBアクセス制御。
通信するコンポーネント異なるスレッドの並行コンポーネントが相互通信（メッセージパッシング／共有メモリ）。
3つの制御パターンの見分け方：クラス図に制御クラスがいくつあるかを数える。1つ＝集中制御。複数で同格＝分散制御。複数だが1つが他を制御している＝階層制御。

アーキテクチャ通信パターン

  • 非同期メッセージ通信／双方向非同期メッセージ通信（返信は必ずするが待たない）
  • コールバックによる非同期メッセージ通信（コールバックハンドルを渡す）
  • 返信つき同期メッセージ通信（応答まで待つ）／応答不要同期メッセージ通信（受け取られたら解放）
  • ブローカ通信：Broker Forwarding（全通信を仲介、安全だがオーバヘッド大）／Broker Handle（ハンドルを得て直接通信、対話的な交換向き）
  • 発見パターン／グループメッセージ通信（ブロードキャスト／マルチキャスト＝Subscription-Notification）／交渉通信
  • 疎結合になる通信パターンが望ましい：ブローカ通信、発見、マルチキャスト。

トランザクションパターン

トランザクション＝完全に実行されるか全く実行されないかの一蓮托生のオペレーション列（Commit／Abort）。Two-Phase Commit（準備→コミットの2段階）、複合トランザクション（小分割・各々ロールバック可）、Long-Living（人間が介在し時間が読めないものを2つ以上に分割）。

08用語穴埋め対策

開発プロセスと工程（最頻出）

用語定義（この言い回しで書く）
ソフトウェアライフサイクルソフトウェアの一生。各ステージ＝フェーズ。開発／運用／保守／廃棄。
ソフトウェア開発プロセスソフトウェア開発の段取り（一連の工程）。
段階的詳細化各種の図表を作りながら、徐々に詳細度を上げていく開発の進め方。
要求定義どのようなソフトウェアを作りたいかを、実装の詳細に立ち入らず記述する（What）。
基本設計（＝外部設計）ソフトウェアをモジュールに分割し、そのインターフェースを設計（WhatをHowに）。
詳細設計（＝内部設計）各モジュールの内部を設計（HowをさらにHowに）。
実装実際にプログラムを作成する（Howをコードに）。
テスト期待通りの振舞いをするか検証。単体→結合→システム（→受入）。

プロセスモデル

  • ウォータフォールモデル：各工程を逐次実施。前工程の成果物完成まで次に進まない。長所＝進捗管理がしやすい／短所＝手戻りに弱い。
  • インクリメンタルモデル：ウォータフォールを何度か繰り返し発展的に作る。工程管理は複雑だが、リスクを早く認識できる。
  • プロトタイピング：要求定義時に試作し、顧客と共通認識を深めモレ・ヌケ・矛盾をつぶす。
  • スパイラルモデル（進化型）：1)目標設定・解決案・制約認識 → 2)リスク分析 → 3)開発＆テスト → 4)次サイクルの計画。
  • V字モデル：左側の各工程と右側の各テスト工程の対応関係を示すモデル（要求定義↔受入テスト、基本設計↔システムテスト、詳細設計↔結合テスト、実装↔単体テスト）。

要求・仕様・品質

用語定義
要求これから開発するシステムがどうあって欲しいかを記述したもの。受益者の視点。
仕様（要求仕様）同じくどうあって欲しいかの記述だが開発者の視点。要求を詳細化したもの。文書＝要求仕様書。
機能要求／非機能要求提供すべき機能／充たすべき特性。非機能＝品質要求＋制約（法令遵守・アーキテクチャ制約・開発制約）。
品質要求（5つ）信頼性・使用性・効率性・保守性・移植性。
仕様に必要な性質曖昧さ・モレ・ヌケ・矛盾がない／実現可能性と検証可能性が吟味されている。
要求工学プロセス要求獲得 → 要求分析 → 要求仕様化 → 要求の検証・妥当性確認・評価（＋要求管理）。
分析／設計／実装分析＝要求仕様書を書くまで（What）。設計＝コードを書くまで（How、複数案を評価して意思決定）。実装＝コードを書く。
ソフトウェアのモデル実現の詳細に立ち入らず問題の本質を、自然言語より低くプログラミング言語より高い抽象度で記述したもの。重要な3観点＝機能・構造・振舞い。
OOA / OOD / OOPオブジェクト指向分析／設計／プログラミング。
クラス／インスタンスクラス＝オブジェクトの種（型）。インスタンス＝クラスに属する個々のオブジェクト。

09過去問（2025/07/25 実施）完全解答と解説

解答は黒塗り。まず自力で解いてからタップして確認。右上の「解答を全部表示」で一括表示もできる。

【問題1】◯×

No.解答理由
①×コミュニケーション図の四角はオブジェクト（インスタンス）。クラスではない。
②◯コンポジションは◆側が全体。全体の消滅とともに部分も消滅する（生存期間が等しい）。
③×多重度は「反対端のインスタンス1個に対し当該端がいくつ対応するか」。m個にn個、という総数の解釈は誤り。
④◯「AはBの一種」＝Bが親。したがって「BはAを汎化した関係」で正しい。
⑤◯条件によって生じたり生じなかったりする＝条件実行＝opt。
⑥×ユースケース記述はシステムの内部構造に立ち入らない。外部仕様のみ。
⑦◯同期メッセージの定義そのもの。
⑧◯プライマリアクタ＝ユースケースを起動する（相互作用を始める）アクタ。
⑨◯アクティビティ（do）＝状態に留まっている間、継続して実行される振舞い。
⑩×「上下関係のない同格」は分散制御パターン。階層制御は1つが他を調停する。

【問題2】給湯ポットの制御ソフトウェア

（小問1）アーキテクチャ構造パターンの名前　→　集中制御パターン

制御クラスは「給湯ポット制御」1つだけで、それが全I/Fクラスを制御し、状態依存の振舞い（有限状態機械）を持つ。制御クラスが1つ＝集中制御。

（小問2）シーケンス図の空欄（登場順：タイマ／水温センサI/F／給湯ポット制御／ヒータI/F）

空欄解答やりとり対応する主シーケンス
①ヒータON制御 → ヒータI/F1. 通電開始後、ヒータに通電を始める
②沸騰水温センサI/F → 制御2. 水温が98℃を超えた
③計時開始要求制御 → タイマ3の前提（2分の計時を依頼）
④計時完了通知タイマ → 制御3. 2分経過を知らせる
⑤loop複合フラグメント8. 保温のため4〜7を繰り返す
⑥ヒータOFF制御 → ヒータI/F4. 通電を止める
⑦水温低下水温センサI/F → 制御5. 90℃を割った
⑧ヒータON制御 → ヒータI/F6. 通電を再開する
⑨沸騰水温センサI/F → 制御7. 98℃を超えた
ポイント：⑤の枠は「4〜7を繰り返す」に対応するので loop。ここで opt や alt を選ばないこと。選択肢に par があるのは撹乱。

（小問3）階層ステートマシン図の空欄

空欄遷移イベントアクション根拠
①初期化中 → 加熱中初期化完了（既出）ヒータON主1. 通電を始める
②加熱中 → 沸騰中沸騰計時開始要求主2→3. 98℃超過で2分の計時を開始
③沸騰中 → 保温中（加熱待機中）計時完了通知ヒータOFF主3→4. 2分経過で通電停止
④加熱待機中 → 再加熱中水温低下ヒータON主5→6. 90℃を割って通電再開
⑤再加熱中 → 加熱待機中沸騰ヒータOFF主7→4. 98℃超過で通電停止
⑥保温中 → 加熱中再沸騰ボタン押下ヒータON代替 Step4-7. 再沸騰要求で1に戻る
⑦動作中 → 停止中水位低下ヒータOFF代替 Step1-7. 空焚き防止
⑧停止中 → 加熱中水位回復ヒータON代替. 水位上昇で1に戻る
⑦は親状態「動作中」の境界から出る遷移。水位低下はどの副状態でも起こり得るので、副状態ごとに書かず親から1本出す。⑧の戻り先が「初期化中」ではなく「加熱中」なのは、代替シーケンスが「1に戻る」＝主シーケンスStep1（ヒータ通電開始）だから。

【問題3】クラス図（解答例）

プレイリスト アーティスト 作品 楽曲 アルバム - 名前 - 曲名 - 演奏時間 - アルバム名 * * 集約 * * 提供する 1 1..* コンポジション 汎化（△は親「作品」側）
【問題3】解答例：汎化2本＋関連1本＋集約1本＋コンポジション1本。多重度は必ず両端に。
記述図での表現
楽曲／アルバムは作品の一種作品を親とする汎化（△は作品側）
楽曲＝曲名・演奏時間、アルバム＝アルバム名、アーティスト＝名前各クラスの属性欄に記入（作品・プレイリストは属性なし）
1つのアルバムは1曲以上の楽曲で構成、アルバム削除で楽曲も削除／1つの楽曲は1つのアルバムに属するコンポジション。アルバム側◆で多重度1、楽曲側 1..*
1人のアーティストは0個以上の作品を提供／1つの作品は0人以上のアーティストに提供される関連「提供する」、両端とも *
プレイリストは0個以上の作品で構成、削除しても作品は残る／作品は0個以上のプレイリストの構成要素集約。プレイリスト側◇、両端とも *
ここが差がつく：アーティスト・プレイリストは作品（親クラス）と結ぶ。楽曲やアルバムに直接つながない。「作品の一種」と書かれている以上、共通の関連は親側に集約するのが自然。

【問題4】用語

No.解答補足
①ソフトウェア開発プロセス一連の工程＝開発の段取り。
②要求定義顧客要求を聞き取り整理する工程（What）。
③基本設計（外部設計）部品とインターフェースの設計。
④詳細設計（内部設計）各部品の内部の設計。
⑤段階的詳細化徐々にソフトウェアのつくりの詳細を固めていくこと。

10直前チェックと解答手順

本番の解答手順（時間配分の型）

  1. 問題1（◯×）を5分で。迷ったら「主語のすり替え」だけ確認して次へ。
  2. 問題2はユースケース記述を先に精読し、主シーケンスの各行に「誰→誰／何」を書き込む。この下ごしらえでシーケンス図と状態図の両方が埋まる。
  3. 小問1（パターン名）はクラス図の制御クラスの数を数えるだけ。
  4. シーケンス図 → ステートマシン図の順。イベント＝制御への入力、アクション＝制御からの出力で機械的に転写。
  5. クラス図は汎化 → 属性 → 関連 → 多重度 → ◆/◇の順。多重度の書き忘れは即減点。
  6. 用語問題は最後に1分で回収。

覚えたか自己チェック