情報処理試験を勉強していると、「実現って汎化と何が違うの?」「クラス図に出てくる破線の矢印はどういう意味?」と混乱しがちです。この記事では、UMLにおける「実現」の意味と使い方を、日常の例え話を交えて解説します。
対象試験と出題頻度
実現(Realization)は、基本情報技術者・応用情報技術者で出題されるテーマです。
UMLのクラス図に登場するクラス間の関係の一つであり、汎化・集約・依存といった他の関係との違いを正確に区別できるかが問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★☆☆☆
ランクC(応用)余裕があれば覚える
用語の定義
実現(Realization)とは、一言で言うと
「インタフェースが定義した操作(メソッドの仕様)を、クラスが具体的に実装する関係」
のことです。
イメージとしては、「資格試験の出題範囲と、その範囲をカバーする参考書」の関係です。
出題範囲(シラバス)には「これを問います」という仕様が列挙されていますが、具体的な解説は書かれていません。参考書がその仕様に沿って中身を提供します。インタフェースがシラバス、クラスが参考書にあたります。
📊 実現(Realization)の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Realization |
| UMLでの分類 | クラス図で表現される関係の一種 |
| 記法 | 破線+白抜き三角形の矢印(実装クラス → インタフェース) |
| Java での対応 | implements キーワード |
解説
オブジェクト指向では、クラスに「何ができるか」の仕様だけを定義し、具体的な処理を書かないインタフェースという仕組みがあります。インタフェースを使うと、異なるクラスに共通の操作名を強制でき、プログラムの柔軟性が高まります。
この「インタフェースの仕様を引き受けて、中身を実装する」という関係こそが実現です。
汎化との違い
実現と混同しやすいのが汎化(Generalization)です。両者は「上位の定義を下位が引き継ぐ」という点で似ていますが、引き継ぐ対象と記法が異なります。
実現 vs 汎化 ― 線種の違いを見比べる
実現(Realization)
Flyable
破線 + 白抜き△
Java: implements
汎化(Generalization)
実線 + 白抜き△
Java: extends
見分けポイント:矢印先端はどちらも白抜き△。線が破線なら実現、実線なら汎化。ここだけ覚えれば判別できる。
ポイントは線種です。
実現は「破線」、汎化は「実線」。矢印の先端はどちらも白抜き三角形ですが、線が実線か破線かで意味がまったく変わります。
図解:実現の記法
具体例として、「飛べるもの」というインタフェースを「鳥」クラスと「飛行機」クラスが実現する関係を図にします。
実現(Realization)の記法
«interface»
Flyable(飛べるもの)
+ fly(): void
鳥
+ fly(): void
// 羽ばたいて飛ぶ
飛行機
+ fly(): void
// エンジンで飛ぶ
※ 破線+白抜き三角形が「実現」の目印。実線+白抜き三角形だと「汎化(継承)」になる
Javaコードとの対応
プログラミング言語Javaでは、実現は implements キーワードで表現されます。先ほどの図をコードにすると以下の通りです。
// インタフェース:仕様だけを定義(中身は書かない) public interface Flyable { void fly(); } // 実現:クラスがインタフェースの仕様を実装する public class Bird implements Flyable { public void fly() { System.out.println("羽ばたいて飛ぶ"); } } public class Airplane implements Flyable { public void fly() { System.out.println("エンジンで飛ぶ"); } }
クラス図の6つの関係における位置づけ
クラス図で表現できる主な関係は6種類あります。
実現がどの位置にあるかを整理しておくと、他の関係と混同しにくくなります。
📊 クラス図の6つの関係と記法
| 関係 | 意味 | 記法名 | 図 |
|---|---|---|---|
| 関連 | クラス間の構造的なつながり | 実線 | |
| 集約 | 「全体と部分」の弱い所有関係(part-of) | 実線+白抜き◇ | |
| コンポジション | 「全体と部分」の強い所有関係(全体が消えると部分も消える) | 実線+黒塗り◆ | |
| 汎化 | 親クラスの属性・操作を子クラスが継承(is-a) | 実線+白抜き△ | |
| 実現 | インタフェースの仕様をクラスが実装する | 破線+白抜き△ | |
| 依存 | 一方のクラスの変更が他方に影響する一時的な利用関係 | 破線+矢印(▷) |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 実現(Realization)の核心を3行で
・インタフェースが定めた操作仕様を、クラスが中身を書いて実装する関係
・UMLの記法は「破線+白抜き三角形」。汎化(実線+白抜き三角形)との線種の違いが決め手
・Javaでは implements、汎化は extends に対応する
試験ではこう出る!
実現は、FE・APの午前問題でクラス図の関係を問う問題の選択肢として登場します。単体で「実現とは何か」が問われるケースは少なく、クラス図の関係一覧(関連・汎化・集約・実現など)の中で正しい組み合わせや記法を選ぶ形式が中心です。
📊 過去問での出題実績
| 試験回 | 出題内容 | 実現との関連 |
|---|---|---|
| SW H17秋 午前 問41 |
UMLで静的な相互関係を表現する図を選ぶ問題。解説にてクラス図の関係として「リンク、関連、集約、汎化、特化、実現」が列挙されている。 | クラス図の関係の1つとして「実現」が明記 |
| FE H25秋 午前 問46 |
クラス図の汎化の関係を示す記法を選ぶ問題。 | 汎化の記法との混同を狙ったひっかけ。実現の破線との区別が必要 |
| FE H19秋 午前 問45 |
クラス図に記述するものを選ぶ問題。 | クラス図で表現できる関係として実現が含まれることを前提知識として要求 |
📝 IPA試験での出題パターン
パターン1:「クラス図で表現できる関係を選べ」
関連・汎化・集約・実現などの中から、正しい組み合わせを選ぶ形式。「ライフライン」や「メッセージ」はシーケンス図の要素であり、クラス図の関係ではないので除外する。
パターン2:「記法の違いを問う」
矢印の形(実線 or 破線、白抜き△ or 黒塗り◆)からどの関係かを判別させる問題。汎化と実現は矢印先端が同じ白抜き三角形のため、線種(実線か破線か)だけが判別材料になる。
試験ではここまででOKです。インタフェースの設計原則(依存性逆転の原則など)まで問われることはないので、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. UMLのクラス図において、インタフェースの操作仕様をクラスが実装する関係を示す記法はどれでしょうか?
- A. 実線に白抜き三角形の矢印を付けて、子クラスから親クラスへ引く。
- B. 破線に白抜き三角形の矢印を付けて、実装クラスからインタフェースへ引く。
- C. 実線に白抜きひし形を付けて、全体クラスから部分クラスへ引く。
正解と解説を見る
正解:B
解説:
実現(Realization)は、インタフェースが定めた操作をクラスが実装する関係であり、UMLでは破線に白抜き三角形の矢印で表記します。
選択肢Aは汎化(Generalization)の記法です。汎化は親クラスの属性・操作を子クラスが継承する関係で、実線を使う点が実現と異なります。選択肢Cは集約(Aggregation)の記法です。集約は全体と部分の所有関係を表し、白抜きひし形を使います。
よくある質問(FAQ)
Q. 実現は多重に行えますか?1つのクラスが複数のインタフェースを実装できるのでしょうか?
できます。Javaでは1つのクラスが複数のインタフェースをimplementsで指定できます。例えば class Duck implements Flyable, Swimmable のように書くと、Duckクラスは「飛べる」と「泳げる」の両方の仕様を実装する形になります。UML上では、Duckクラスから各インタフェースへ破線+白抜き三角形を複数本引きます。なお、Javaではクラスの多重継承(extendsを複数指定)は禁止されていますが、インタフェースの多重実現は許可されています。
Q. 実現と依存(Dependency)の破線は同じ見た目ですか?
線が破線である点は共通していますが、矢印の先端が異なります。実現は白抜き三角形(△)、依存は開いた矢じり(▷、いわゆるスティック矢印)です。依存は「一方のクラスを一時的に利用する」関係で、メソッドの引数やローカル変数でしか相手を参照しないケースに使います。先端の形を見比べれば区別できます。
Q. 実務でインタフェースと実現はどのような場面で使いますか?
データベースアクセスや外部API呼び出しなど、将来的に実装を差し替える可能性のある箇所で多用されます。例えば「UserRepository」というインタフェースを定義しておき、MySQL用の実装クラスとPostgreSQL用の実装クラスを別々に作ることで、データベースを切り替える際にインタフェースを利用する側のコードを変更する必要がなくなります。このような設計は「依存性逆転の原則(DIP)」と呼ばれ、大規模開発では標準的な手法です。
Q. Pythonなどインタフェース構文がない言語では実現の概念は使えないのですか?
UMLの実現はJavaやC#のようにinterface構文を持つ言語と相性が良い概念ですが、Pythonでも抽象基底クラス(ABCモジュール)を使って同様の設計を表現できます。試験の範囲では、実現=Javaのimplementsという理解で十分です。