AP22 — 要件、UML、オブジェクト指向設計

応用情報技術者試験の科目Aに向けて、機能・非機能要件、双方向トレーサビリティ、ユースケース図・クラス図・シーケンス図・ステートマシン図、多重度の読み方、カプセル化と多相性、結束性と結合度を、図書貸出の例とオリジナル問題5問で学びます。

応用情報技術者試験科目A要件定義UMLオブジェクト指向

AP科目A・第22回 · 2026年度・シラバスVer.7.2に基づく独立した学習資料です。IPAとの提携はなく、合格を保証しません。 シリーズ一覧を見る

改訂・出典確認日:2026-10-21

学習インデックスとシラバス対応

この回では、各成果物の理由を失わずに要件から設計へつなげる。以下ではIPA公式シラバスのPDFページとフッターの印刷ページを区別する。

学習インデックス IPA Ver.7.2の位置 本稿で扱う範囲
1. 要件 PDF 62 / 印刷 58 システム境界、機能・性能・その他の機能/非機能要件、評価とレビュー
2. トレーサビリティ PDF 63 / 印刷 59 双方向トレーサビリティ、要件属性からソフトウェア要素・テストケース・情報項目への追跡、マトリクス、ユースケース、UML
3. UMLの視点 PDF 64 / 印刷 60 要件レビュー、ユースケース・クラス・ステートマシン・シーケンス図
4. 要件と設計の境界 PDF 65 / 印刷 61 状態遷移図/表、機能/非機能設計
5. オブジェクト指向設計 PDF 68 / 印刷 64 クラス、カプセル化、サブクラス、継承、多相性、関連、汎化/特化、分解、集約
6. モジュール設計 PDF 69 / 印刷 65 結束性、結合度、モジュール独立性、データ結合、制御結合

AP22の範囲は要件、UML、オブジェクト指向設計である。AP23はテスト、品質、開発手法を扱い、ここでは参照だけにとどめたテスト設計を詳しく学ぶ。AP24はプロジェクト管理、AP25はサービス管理、AP26は監査・内部統制・セキュリティ管理である。

共通用語表

次の表は3言語の記事で意図的にバイト単位まで同一である。

English Korean Japanese
functional requirement 기능 요구사항 機能要件
non-functional requirement 비기능 요구사항 非機能要件
bidirectional traceability 양방향 추적성 双方向トレーサビリティ
traceability matrix 추적성 매트릭스 トレーサビリティマトリクス
use-case diagram 유스케이스 다이어그램 ユースケース図
class diagram 클래스 다이어그램 クラス図
sequence diagram 시퀀스 다이어그램 シーケンス図
state-machine diagram 상태 머신 다이어그램 ステートマシン図
association 연관 関連
multiplicity 다중성 多重度
generalization 일반화 汎化
aggregation 집약 集約
composition 합성 コンポジション
encapsulation 캡슐화 カプセル化
inheritance 상속 継承
polymorphism 다형성 多相性
cohesion 응집도 結束性
coupling 결합도 結合度

一つの例で目標から設計まで

全体を通して架空の図書貸出システムを使う。

  • R-F01(機能): 利用資格のある会員は貸出可能な蔵書コピーを借りることができ、システムは貸出を記録する。
  • R-N01(非機能): 明示した架空の試験条件である同時セッション200件において、蔵書検索応答の95%が2.0秒以内に完了する。これは測定可能なしきい値の例であり、IPAの規則ではない。
  • トレーサビリティ連鎖: ステークホルダー目標 → R-F01 → UC-01 Borrow Copy → LoanService.borrowとCopy.checkout → SD-01 → V-F01。

機能要件はシステムが提供する振る舞いを示す。非機能要件は品質や運用を制約し、指標と条件を明示すれば検証可能になる。双方向トレーサビリティは成果物への採番だけではない。順方向は影響分析と網羅性、逆方向は根拠と起源を確認する。トレーサビリティマトリクスには両方向を記録できる。V-F01は後続の検証項目であり、テスト設計はAP23で本格的に扱う。

相互補完する四つのUMLビュー

図 目的 限界
ユースケース 外部アクターの目標とシステム境界を示す 内部メッセージ順序やデータ構造は示さない
クラス 静的なクラス、属性、操作、関係、多重度を示す 実行時の時間順序は示さない
シーケンス 一つのシナリオのメッセージを時間順に示す 起こり得る全ライフサイクル状態は示さない
ステートマシン(状態) 一つの実体の状態とイベント/ガードによる遷移を示す オブジェクト構造は示さない

ユースケース:

[Member]    --> (UC-01 Borrow Copy)
[Librarian] --> (UC-02 Register Copy)

クラス関係:

Member    "1" -- "0..*" Loan
BookTitle "1" -- "0..*" Copy
Copy      "1" -- "0..1" activeLoan: Loan

多重度は関連の反対側の端を基準に読む。ある端の数値は、反対側のインスタンス一つに対して、その端のインスタンスがいくつ関連できるかを表す。したがって各LoanにはMemberがちょうど一人、Member一人にはLoanが0件以上関連できる。各CopyにはBookTitleがちょうど一つ、BookTitle一つにはCopyが0件以上関連できる。各アクティブLoanにはCopyがちょうど一つ、Copy一つにはアクティブLoanが最大一つである。過去の貸出は別で、複数存在し得る。

関係表記では、関連は実線、汎化はスーパークラスを指す白抜き三角、集約は全体側の白抜きひし形、コンポジションは全体側の黒塗りひし形を使う。「has-a」だけで集約やコンポジションとは推論できない。ライフサイクルと所有の意味で決め、通常の関連が適切な場合も多い。

シーケンスSD-01:

Member -> UI: requestBorrow
UI -> LoanService: borrow
LoanService -> Copy: checkout
Copy -> Copy: validate Available; status := OnLoan
LoanService -> LoanRepository: save
LoanRepository --> LoanService --> UI --> Member: success

Copyのステートマシン:

Available --checkout--> OnLoan
OnLoan --return [undamaged]--> Available
OnLoan --return [damaged]--> Maintenance
Maintenance --repairComplete--> Available

SD-01が有効なのはCopy.checkoutの開始時にAvailableである場合だけである。OnLoanでの2回目のcheckoutは拒否しなければならない。

オブジェクト指向とモジュール構造

  • カプセル化: Copy.statusは、有効な遷移を強制するcheckout、return、repairCompleteなどの操作だけで変更する。
  • 継承: サブタイプはスーパタイプの特性を継承して拡張する。例えばBookTitleがCatalogItemのサブタイプなら共通の識別子とタイトルを継承するが、BookTitleをCatalogItemの代わりに使える場合にだけこの汎化は妥当である。継承が常にコンポジションより望ましいわけではなく、代替可能性、所有、変更要求から選ぶ。
  • 多相性: LoanServiceはNotificationChannel.sendを呼び、EmailChannelとPushChannelは一つの契約を介して異なる実装を提供する。これはオーバーライド/実行時置換であり、同名で複数のシグネチャを持つオーバーロードとは異なる。

高い結束性と低い結合度は一般に保守性を支えるが、絶対的な普遍法則でも、それだけで十分な尺度でもない。LoanServiceは無関係な帳票やUIではなく、貸出判断とライフサイクルに集中して結束性を高める。NotificationChannelインタフェースへの依存は具体的チャネルとの結合を減らす。データ結合は必要な値を渡し、制御結合は相手モジュール内部の分岐を指示するフラグを渡す。一般にデータ結合は制御結合より制約が少ない。

例題A — 分類、追跡、変更

  1. 「資格のある会員が貸出可能なCopyを借り、Loanを記録する」は機能的振る舞いR-F01である。「同時200セッションで検索応答の95%が2.0秒以内」は測定可能な非機能品質条件R-N01であり、IPAの基準ではない。
  2. マトリクスに目標 ↔ R-F01 ↔ UC-01 ↔ LoanService.borrow/Copy.checkout ↔ SD-01 ↔ V-F01を両方向で記録する。
  3. 規則が「延滞貸出のない会員だけが有資格」に変わると、順方向の影響分析でR-F01、UC-01、LoanService.borrowの資格判定、SD-01(モデル化する場合は拒否の代替経路も)、V-F01が見つかる。逆方向追跡で各変更成果物の存在理由を確認する。可用性の振る舞いが同じならCopy.checkoutと状態遷移は確認対象だが必ずしも変更しない。R-N01は自動的には影響を受けない。

例題B — 多重度と振る舞い

Member "1" -- "0..*" LoanのLoan側の端を読むと、Member一人にLoanが0件以上関連する。Member側の端を読むと、Loan一件にMemberがちょうど一人関連する。逆に読むとLoan一件に複数会員が可能という誤答になる。同様にCopy "1" -- "0..1" activeLoan: LoanはCopy一つにアクティブLoanが最大一つという意味である。LoanにCopyが0または1という意味ではなく、反対側の1はアクティブLoanごとにCopyがちょうど一つと示す。

SD-01を再生すると、要求がCopy.checkoutへ届き、Available --checkout--> OnLoanへ遷移し、保存して成功を返す。すでにOnLoanのとき再びcheckoutすると有効な遷移がないため拒否する。状態矢印や多重度の端の解釈を逆にしてはならない。

練習問題

Q1

正しい記述はどれか。

  • ア. R-F01は会員に言及するので非機能要件である。
  • イ. R-N01は検索に言及するので機能要件である。
  • ウ. R-F01は振る舞い、R-N01は同時200セッション条件で測定可能な品質条件であり、しきい値は例示であってIPAの規則ではない。
  • エ. 非機能要件は測定できない。

正解:ウ (3)。 アはアクターと要件種別を混同する。イは応答時間が品質制約であることを無視する。ウは両方と架空のしきい値を正しく分類する。エは測定条件が検証を可能にするため誤りである。

Q2

一つの貸出シナリオのメッセージを時間順に示す最適な図はどれか。

  • ア. クラス図
  • イ. シーケンス図
  • ウ. ユースケース図
  • エ. ステートマシン図

正解:イ (2)。 アは静的構造、イはシナリオの時間順メッセージ、ウはアクター目標と境界、エは一実体の状態と遷移を示す。

Q3

Copy "1" -- "0..1" activeLoan: Loanの一意に正しい読み方はどれか。

  • ア. 一つのアクティブLoanにはCopyが0または1ある。
  • イ. すべてのCopyには常にアクティブLoanが一つ必要である。
  • ウ. Copy一つには任意数のアクティブLoanを関連できる。
  • エ. 各アクティブLoanにはCopyがちょうど一つあり、各CopyにはアクティブLoanが最大一つある。

正解:エ (4)。 アは端の意味を逆にする。イは0..1を必須の1にする。ウは上限を無視する。エは両端を正しく読み、過去のLoanは複数でもよい。

Q4

カプセル化と多相性を正しく区別した記述はどれか。

  • ア. カプセル化はCopy.statusを有効な操作だけで変更させ、多相性はLoanServiceが一つのNotificationChannel.send契約で異なるチャネル実装を呼べるようにする。
  • イ. カプセル化は全フィールドの公開で、多相性はオーバーロードだけである。
  • ウ. カプセル化は継承で、多相性は集約である。
  • エ. どちらもLoanServiceが全具体チャネル型を検査する必要がある。

正解:ア (1)。 アは両概念を正しく述べる。イは情報隠蔽を否定し、実行時オーバーライドとオーバーロードを混同する。ウは無関係な関係に置換する。エは代替可能性を損ない具体結合を強める。

Q5

最も適切な設計判断はどれか。

  • ア. 結束性を最大化するため帳票とUI描画をLoanServiceに入れる。
  • イ. 分岐制御フラグを渡す方が必要データを渡すより常に制約が少ない。
  • ウ. LoanServiceを集中させNotificationChannelに依存する。一般にデータ結合は制御結合より制約が少ないが、結束性/結合度は絶対法則ではない。
  • エ. 低結合にはモジュール間の通信を一切なくす必要がある。

正解:ウ (3)。 アは無関係な責務を混ぜ結束性を下げる。イは通常の比較を逆にする。ウは均衡の取れた判断である。エは低結合を相互作用ゼロと誤解する。

解答キー: 3, 2, 4, 1, 3 (ウ, イ, エ, ア, ウ)

クイックシート

  • 振る舞い→機能、測定可能な品質/制約→非機能。
  • 順方向(影響/網羅性)と逆方向(起源/根拠)の両方を追跡する。
  • ユースケース=アクター目標、クラス=静的構造、シーケンス=シナリオ順序、ステートマシン=実体のライフサイクル。
  • 多重度は反対側の端を基準に読む。
  • 白抜き三角→スーパークラス、白抜き/黒塗りひし形→集約/コンポジションの全体。
  • 状態変更をカプセル化する。多相性は実行時置換で、単なるオーバーロードではない。
  • 責務を集中しインタフェースに依存し、データ結合と制御結合を区別する。

セルフチェックと1/3/7日復習

R-F01/R-N01の分類、連鎖の双方向再現、各図の限界、三つの多重度の読解、Copy状態に照らしたSD-01再生、カプセル化・実行時多相性・結束性・結合度を説明できるか。

  • 1日目: 四つの図を描き直し、ノートなしでQ1〜Q5を解く。
  • 3日目: トレーサビリティ連鎖を再構築し、二つの例題を声に出して説明する。
  • 7日目: 全問を再回答し、排除理由を説明できない選択肢を復習する。

公式出典と告知

出典確認日は2026-10-21である。この独立学習資料はIPAまたはOMGと提携せず、その承認を受けたものでもない。試験合格を保証しない。

ブログへ