最終更新日:2026年9月5日
fe fe-technology system-development uml
まず結論
UML(Unified Modeling Language)は、オブジェクト指向によるシステム開発で、システムの構造や振る舞いをモデルとして表すための標準的なモデリング言語です。
FE試験では、次の語がまとまって出たらUMLを強く疑います。
オブジェクト指向
+
分析・設計などでモデルを表現
+
統一された表記
→ UML
また、UMLの図を選ぶ問題では、図の名前ではなく「何を表したいのか」を見ます。
アクタ(利用者)とシステム機能
→ ユースケース図
クラスと関連・静的構造
→ クラス図
イベントによる状態変化
→ 状態遷移図
データの流れ
→ DFD(UMLではない)
まず覚える一文はこれです。
UMLは、プログラムを書く言語ではなく、システムを図で表すモデリング言語。
直感的な説明
UMLは、家を建てる前に作る設計図のようなものです。
システムには、構造・利用者・処理順・状態変化など、いろいろな見方があります。UMLでは、同じシステムを目的に応じて別の図で表します。
クラス・属性・関連を見る
→ クラス図
誰が、どの機能を使うかを見る
→ ユースケース図
オブジェクト間のやり取りを時間順に見る
→ シーケンス図
処理や業務の流れを見る
→ アクティビティ図
イベントによる状態変化を見る
→ 状態遷移図
ユースケース図だけは、次の形で覚えると判断しやすくなります。
誰が?
+
システムで何をする?
→ ユースケース図
図の名前を丸暗記するより、「何を見たい図か」から選ぶのがコツです。
定義・仕組み
UMLは、OMG(Object Management Group)が標準化しているモデリング言語です。
UMLには大きく、システムの静的な構造を表す図と、動きや処理を表す図があります。
構造を表す代表的な図
| 図 | 主に表すもの |
|---|---|
| クラス図 | クラス・属性・操作・クラス間の関係 |
| オブジェクト図 | ある時点のオブジェクトの具体例 |
| コンポーネント図 | ソフトウェア部品と依存関係 |
| 配置図 | 実行環境やハードウェアへの配置 |
| パッケージ図 | 要素のまとまりと依存関係 |
振る舞いを表す代表的な図
| 図 | 主に表すもの |
|---|---|
| ユースケース図 | アクタ(利用者など)とシステム機能の関係 |
| アクティビティ図 | 処理や業務の流れ |
| 状態遷移図 | イベントによる状態の変化 |
| シーケンス図 | オブジェクト間のメッセージを時間順に表す |
| コミュニケーション図 | オブジェクト同士のつながりとメッセージ |
ユースケース図の基本要素
FE試験では細かな記法より、アクタとユースケースの役割を押さえることが重要です。
アクタ
→ システムの外側から利用・関与する人や外部システム
ユースケース
→ アクタから見たシステムの機能
関連
→ アクタとユースケースの関係
つまりユースケース図は、内部処理の詳細ではなく、「外から見たシステムの使われ方」を表します。
UMLではないもの
UMLと一緒に出やすい図もありますが、すべてがUMLではありません。
データの流れ
→ DFD
データベースの実体と関係
→ E-R図
一般的なアルゴリズムの処理手順
→ 流れ図
科目Aでどう出る?
UMLそのものを選ぶ問題
選択肢にEAI・EJB・ERP・UMLが並ぶ問題では、役割の違いで切ります。
| 用語 | 判断するキーワード |
|---|---|
| EAI | 異なるシステムやアプリケーションを連携・統合 |
| EJB | Java・サーバ側コンポーネント |
| ERP | 企業の経営資源を統合管理 |
| UML | オブジェクト指向・モデル化・統一表記 |
短く覚えるなら、次のイメージです。
EAI → つなぐ
EJB → Java
ERP → 経営資源
UML → 描く
「オブジェクト指向」「分析・設計」「統一された表記法」がそろえば、UMLを選びます。
代表的な図を選ぶ問題
問題文の動詞や対象に注目します。
クラス・関連・静的構造を表す
→ クラス図
アクタとシステムの相互作用を表す
→ ユースケース図
処理の流れを表す
→ アクティビティ図
外部の出来事による状態の変化を表す
→ 状態遷移図
メッセージの時間順を表す
→ シーケンス図
特にユースケース図は、次の語が判断材料です。
アクタ
利用者
外部システム
システムの機能
相互作用
→ ユースケース図
ユースケース図・クラス図・状態遷移図・DFDの切り分け
この4つは説明文だけで出題されやすいので、次の対応を優先して覚えます。
| 問題文の手掛かり | 考える図 |
|---|---|
| アクタとシステム機能・相互作用 | ユースケース図 |
| クラスと関連・静的な構造 | クラス図 |
| イベント・状態の変化 | 状態遷移図 |
| データの発生・処理・蓄積・流れ | DFD |
誰が何を使う?
→ ユースケース図
何がどうつながる?
→ クラス図
状態がどう変わる?
→ 状態遷移図
データがどこへ流れる?
→ DFD
UML以外の図との切り分け
| 問題文の手掛かり | 考えるもの |
|---|---|
| エンティティ・属性・関連 | E-R図 |
| データの発生・処理・蓄積・流れ | DFD |
| オブジェクト指向・複数の観点・標準表記 | UML |
| アルゴリズムの処理手順 | 流れ図 |
どんな場面で使う?
要求を整理する
利用者がシステムで何をしたいかを整理するときは、ユースケース図が役立ちます。
例えばATMなら、利用者というアクタに対して「残高照会」「現金を引き出す」「振込する」といった機能を整理します。
システムの構造を設計する
クラスや部品の関係を整理するときは、クラス図やコンポーネント図を使います。
処理の呼出し順序を確認する
オブジェクトやサービスがどの順番でやり取りするかを見るときは、シーケンス図を使います。
業務や処理の流れを整理する
分岐を含む処理や業務の流れを見るときは、アクティビティ図を使います。
よくある誤解・混同
UMLはプログラミング言語
違います。
JavaやPythonのように処理を実行させる言語ではなく、システムをモデルとして表現するための言語です。
ユースケース図は処理の流れを表す図
違います。
ユースケース図が表すのは、アクタとシステム機能の関係です。処理の順序や分岐を表したいなら、アクティビティ図などを考えます。
ユースケース図とDFDは同じ
違います。
誰が、どの機能を使うか
→ ユースケース図
どのデータが、どこからどこへ流れるか
→ DFD
「外部とのやり取り」という点では似て見えますが、人・役割と機能を見るのか、データの流れを見るのかが違います。
UMLとE-R図は同じ
違います。
オブジェクト指向のクラス・属性・関連
→ クラス図
データベースのエンティティ・属性・関連
→ E-R図
DFDはUMLの図
違います。DFDはデータの流れを表す図ですが、UMLそのものではありません。
シーケンス図は構造を表す
違います。シーケンス図は、オブジェクト間のメッセージを時間順に表します。
「図を使う」なら何でもUML
違います。
FE試験では、図が使われていることよりも、何を表しているかを確認します。
参考になる一次情報
UMLの標準化団体であるOMGは、UMLの公式仕様を公開しています。
OMGの公式仕様ページでは、UML 2.5.1が正式仕様として掲載され、規範文書も公開されています。
FE試験の出題範囲は、IPAの公式情報も確認できます。
確認問題(FE試験対策)
UMLそのものを選ぶ
オブジェクト指向によるシステム開発で利用され、分析・設計などでシステムを統一した表記でモデル化するために用いるものはどれか。
- ア. EAI
- イ. EJB
- ウ. ERP
- エ. UML
▶ クリックして答えと解説を見る(ここを開く)
正解:エ
オブジェクト指向
+
モデル化
+
統一された表記
→ UML
EAIはシステム連携、EJBはJavaのサーバ側コンポーネント技術、ERPは経営資源の統合管理です。
👉 判断ポイント
「何をする仕組みか」ではなく、「システムをどう表現するものか」を見る。
ユースケース図を選ぶ
UMLの図のうち、システムの利用者などのアクタと、システムが提供する機能との関係を表すものはどれか。
- ア. 状態遷移図
- イ. クラス図
- ウ. ユースケース図
- エ. DFD
▶ クリックして答えと解説を見る(ここを開く)
正解:ウ
アクタ
+
システムの機能
+
その関係
→ ユースケース図
状態遷移図は状態変化、クラス図は静的構造、DFDはデータの流れを表します。
👉 判断ポイント
「誰が、システムのどの機能を使うのか」が中心ならユースケース図。
まとめ(試験直前用)
- UMLは、オブジェクト指向開発で使う標準的なモデリング言語
- オブジェクト指向+分析・設計+統一表記 → UML
- アクタ+システム機能・相互作用 → ユースケース図
- クラス・関連・静的構造 → クラス図
- 時系列のやり取り → シーケンス図
- 処理の流れ → アクティビティ図
- イベントによる状態変化 → 状態遷移図
- データの流れ → DFD
- DFD・E-R図・一般的な流れ図はUMLそのものではない
図の名前を暗記するより、「何を表したいか」で判断する。