基本情報のUML図｜3種類の見分け方

基本情報技術者試験のソフトウェア設計でUML図が出ると、クラス図、アクティビティ図、ユースケース図のどれを見ているのかで迷いやすいです。名前は聞いたことがあっても、問題文の条件、図の記号、選択肢の説明が一度に出てくると、どこから手を付ければよいのか分からなくなりますよね。

ただ、基本情報のUML図は、専門家のように図を完璧に作図する試験ではありません。大事なのは、図の目的を見分け、必要な記号だけを読み、設問文との対応から選択肢を切ることです。クラス図なら構造、アクティビティ図なら流れ、ユースケース図なら利用者と機能の関係を見る、と最初に切り分けるだけでもかなり解きやすくなります。

この記事では、基本情報のUML図を、クラス図・アクティビティ図・ユースケース図の見分け方から整理します。さらに、属性と操作、多重度、分岐、アクターの読み方、過去問で根拠を探す手順までまとめます。図表を使いながら、試験中に何を見ればよいかを確認していきましょう。

基本情報のUML図の見分け方

UML図は目的で見分ける

基本情報のUML図で最初に見るべきなのは、図の細かい記号ではなく「何を表す図なのか」です。構造を表す図なのか、処理の流れを表す図なのか、利用者と機能の関係を表す図なのか。この目的が分かると、設問文で拾うべき言葉も変わります。クラス図なのに処理順ばかり追う、アクティビティ図なのに属性を探す、という読み違いを減らせるんですね。

たとえば、四角い箱がいくつもあり、線でつながっているならクラス図の可能性が高いです。開始点、処理、分岐、終了点が矢印でつながるならアクティビティ図として読みます。棒人間のようなアクターと楕円の機能が並ぶなら、ユースケース図として「誰が何をできるか」を見ます。シーケンス図なら、上から下へ時間が進むやり取りを追います。

IPAの基本情報技術者試験シラバスでも、UMLはソフトウェア設計の表記法として扱われ、クラス図、ユースケース図、アクティビティ図などが用語例に含まれます。最新の出題範囲はIPAの基本情報技術者試験シラバスで確認できます。

図の種類	表すもの	最初に見る場所	設問での狙い
クラス図	データや部品の構造	箱、属性、操作、線	関係や多重度を読む
アクティビティ図	処理や業務の流れ	開始、分岐、合流、終了	条件ごとの進み方を読む
ユースケース図	利用者と機能の関係	アクター、楕円、境界	誰が何をできるか読む
シーケンス図	時間順のやり取り	縦の時間軸、メッセージ	呼び出し順を読む

この表のように、同じUMLでも見る場所はかなり違います。試験中は、図を見た瞬間に「これは構造を見る問題か、流れを見る問題か、役割を見る問題か」と分類してください。分類できたら、選択肢を読む前に注目箇所を軽くマークします。これだけで、もっともらしい説明に引っ張られにくくなります。UML図は暗記だけでなく、読む順番を決めることが得点につながる分野です。

クラス図は構造を読む

クラス図は、基本情報のUML図の中でも出題されやすく、苦手意識を持ちやすい図です。四角い箱の中に名前、属性、操作が入り、箱同士が線で結ばれます。最初に見るのは、箱の名前です。会員、注文、商品、在庫のようなクラス名を確認し、問題文の名詞と対応させます。次に、箱同士の線を見て、どのクラスがどのクラスと関係しているかを読みます。

クラス図では、現実の業務を想像しすぎないことも大切です。たとえば「会員は複数の商品を購入できるはず」と思っても、問題文に直接書かれていなければ、勝手に関係を足してはいけません。基本情報では、与えられた条件と図の整合性を問う問題が多いです。図の中にある線、属性、操作、多重度を根拠にして、選択肢の説明が本当に読み取れるかを確認します。

設計図の読み取りとしては、UMLだけでなくER図も近い考え方で出ます。データ同士の関係や多重度の読み方を合わせて固めたい場合は、基本情報のER図で主キーと多重度を読む記事も確認しておくと、図から条件を読み取る練習になります。UML図とER図は別物ですが、問題文と図の対応を探す姿勢は共通しています。

クラス図を読む順番を決めておくと、試験中に手が止まりにくくなります。私なら、最初にクラス名を丸で囲む感覚で確認し、次に線で結ばれている相手を見ます。そのあとで、属性、操作、多重度の順に細部を確認します。いきなり全部を読もうとせず、構造から細部へ進むのが現実的です。

属性と操作を分ける

クラス図の箱は、上からクラス名、属性、操作に分かれていることが多いです。属性は、そのクラスが持つデータです。会員番号、氏名、商品番号、単価のように、名詞に近いものが入りやすいですね。操作は、そのクラスが行う処理です。登録する、更新する、計算する、確認する、という動詞に近いものが操作として表されます。この2つを混同すると、選択肢の判断がぶれます。

たとえば問題文に「商品は商品番号と単価を保持する」とあれば、商品番号と単価は商品クラスの属性として考えます。一方で「注文金額を計算する」とあれば、計算処理は操作として扱う可能性があります。ただし、実務なら別の設計もあり得る、という方向に広げすぎない方がよいです。基本情報では、問題文に書かれた条件と図の構造が矛盾していないかを見るのが中心です。

属性は「持っている情報」、操作は「できる処理」と分けると覚えやすいです。選択肢に属性と操作が混ざって出てきたら、名詞か動詞か、データか処理かを先に切り分けましょう。

• 属性はクラスが保持するデータとして読む
• 操作はクラスが行う処理として読む
• 問題文にない属性を勝手に追加しない
• どのクラスが持つべき情報かを確認する

この読み方は、オブジェクト指向の用語整理にもつながります。クラス、インスタンス、属性、操作という言葉が一度に出てくると難しく感じますが、図の中で役割を分けるとかなり理解しやすくなります。まずは箱の中を上下に分けて、上がデータ、下が処理という感覚で読んでください。完璧な設計論より、試験で選択肢を切れる理解を優先するのが現実的です。

迷ったときは、問題文の表現をそのまま図に戻すのが安全です。「保持する」「管理する」は属性に近く、「登録する」「計算する」は操作に近いと考えます。もちろん例外はありますが、基本情報では、この大まかな分け方だけでも選択肢を絞れる場面が多いです。難しい用語を先に覚えるより、データと処理を分ける練習を優先しましょう。

多重度と関係を読む

クラス図で点数差が出やすいのが、多重度と関係の読み取りです。線の端にある「1」「0..1」「0..*」「1..*」のような表記は、一方のクラスのインスタンスが、相手側のインスタンスといくつ関係するかを示します。ここを読み飛ばすと、「必ず1つ必要なのか」「0でもよいのか」「複数あり得るのか」を間違えやすいです。

たとえば、ひとりの会員が複数の注文を行えるなら、会員と注文の関係では注文側が複数になりやすいです。反対に、ひとつの注文が必ずひとりの会員に対応するなら、注文から見た会員側は1になります。問題文の「必ず」「任意」「複数」「少なくとも」「一つ以上」という言葉を見つけたら、多重度と照らし合わせるのがコツです。

表記	意味	問題文で見る言葉
1	必ず1つ	必ず、1件だけ、対応する
0..1	0または1つ	任意、存在しない場合がある
0..*	0以上	複数、ない場合もある
1..*	1以上	少なくとも1つ、1件以上

集約、合成、継承などの関係も出ることがあります。白いひし形は集約、黒いひし形は合成、三角形の矢印は継承として扱われます。とはいえ、記号だけで判断しようとすると焦りやすいです。問題文に「AはBの一部」「AはBの一種」「AはBを持つ」といった表現があるかを探し、図の線と対応させてください。記号、言葉、多重度をセットで見ると、選択肢の矛盾を見つけやすくなります。

多重度は、片側だけを見ると混乱します。線の端に書かれた数字は、反対側のクラスから見た個数を表す、と意識してください。会員と注文の関係なら、会員側から注文側を見る、注文側から会員側を見る、というように視点を切り替えます。ここを丁寧に読むだけで、クラス図のひっかけはかなり減らせます。

設問文と図を対応させる

UML図の問題でやってはいけないのは、図だけを長く眺め続けることです。基本情報では、問題文、図、選択肢を行き来して解きます。最初に問題文の名詞を拾い、クラス名、アクター名、ユースケース名と対応させます。次に、動詞や処理の順番を拾い、操作、アクティビティ、メッセージと対応させます。この対応表を頭の中で作ると、選択肢の根拠が見つけやすくなります。

たとえば「利用者が申請し、管理者が承認する」という文章があれば、利用者と管理者はアクターやクラスの候補です。申請、承認はユースケースや処理の候補です。図の中にその要素がどう表されているかを見れば、選択肢の「利用者が承認する」「管理者が申請する」のような入れ替えに気づけます。選択肢だけを先に読むと、もっともらしい説明に引っ張られやすいので注意です。

設問文の名詞はクラスやアクター、動詞は操作や処理に対応しやすいです。先に対応関係を作ってから選択肢を読むと、勘ではなく根拠で判断できます。

この読み方は、設計だけでなくテスト技法の学習にもつながります。図から条件や分岐を読み、どのパターンを確認すべきか考える力は、ブラックボックステストや同値分割の考え方とも相性がよいです。テスト観点まで広げたい場合は、基本情報のテスト技法でブラックボックスと同値分割を学ぶ記事も合わせて確認しておくと、設計からテストまでの流れがつながります。

この対応づけは、短いメモでも十分です。たとえば「利用者=アクター」「申請=ユースケース」「承認=管理者側の機能」のように書ければ、図と文章がつながります。問題を解くたびにこの作業をしておくと、UML図を見た瞬間に読む順番が自然に決まるようになります。暗記量を増やすより、対応づけの型を身につける方が安定します。

基本情報のUML図の解き方

アクティビティ図は流れ

アクティビティ図は、処理や業務の流れを表す図です。基本情報で出てきたら、まず開始位置を探し、矢印に沿って処理を追います。角丸の処理、ひし形の分岐、黒丸の開始や終了、太い横線の並行処理や合流が出ることがあります。フローチャートに近いので、UMLの中では比較的読みやすいですが、分岐条件を飛ばすと選択肢で間違えやすいです。

注文処理を例にすると、注文受付、在庫確認、支払い確認、出荷準備、通知のような流れが考えられます。在庫がない場合は別の処理に進み、支払いに失敗した場合は終了するかもしれません。ここで見るべきなのは、処理名だけではありません。「どの条件でどちらへ進むか」「分岐後に合流するか」「終了まで到達する条件は何か」を確認します。

勉強するときは、図を文章に直してみるのがおすすめです。「開始後に申請内容を確認する。条件を満たせば承認へ進む。満たさなければ差し戻す」のように、矢印を一文ずつ日本語にします。図を眺めるだけだと、分かった気になりやすいです。自分の言葉で流れを説明できるようにすると、選択肢の順番違いや条件違いに気づけます。

アクティビティ図は、アルゴリズムのトレースに近い感覚で読めます。開始から終了までの全ルートを一気に追うのではなく、分岐ごとに条件を確認し、片方のルートを最後までたどってから別ルートに戻ると整理しやすいです。並行処理が出た場合も、どこで分かれてどこで合流するかを確認すれば、選択肢の矛盾を見つけやすくなります。

ユースケース図は役割

ユースケース図は、利用者や外部システムが、システムのどの機能を使えるかを表します。棒人間のようなアクター、楕円で描かれるユースケース、システム境界の枠が主な要素です。クラス図のようにデータ構造を見る図ではなく、アクティビティ図のように処理順を細かく追う図でもありません。中心は「誰が何をできるか」です。

たとえば、利用者、管理者、外部決済システムが登場する場合、それぞれがどの楕円と線でつながっているかを見ます。利用者は商品を検索し、注文する。管理者は商品を登録し、注文状況を確認する。外部決済システムは支払い処理と関係する。このように、役割ごとの機能を分けて読むと、選択肢の誤りを見つけやすくなります。

• アクターはシステム外部の利用者や外部システム
• ユースケースはシステムが提供する機能
• 線で結ばれている機能だけを使えると読む
• システム境界の内側と外側を混同しない

ユースケース図で迷うときは、「この機能を実行する主体は誰か」と問い直してください。利用者ができることと管理者ができることは違います。外部システムは人ではありませんが、システムとやり取りする相手としてアクターになります。ここを理解しておくと、要件定義や外部設計の問題にもつながります。UML図は単独の暗記項目ではなく、ソフトウェア開発全体の整理にも使える知識です。

ユースケース図では、線で結ばれていない機能を勝手に使えると判断しないことも大事です。問題文を読むと「管理者なら何でもできそう」と思ってしまうことがありますが、試験では図に示された関係が根拠になります。アクターの種類、システム境界、楕円の名前を順番に確認し、誰の機能なのかを落ち着いて分けましょう。

シーケンス図は時間順

シーケンス図は、オブジェクトやアクター同士のやり取りを時間順に表す図です。縦方向に時間が進み、横方向に登場する相手が並びます。矢印はメッセージや処理の呼び出しです。基本情報でシーケンス図が出てきたら、上から下へ順番に追うのが基本です。左右に相手が並ぶため複雑に見えますが、時間の流れは上から下だと決めて読むと落ち着けます。

シーケンス図では、「誰が誰に何を依頼しているか」を見ます。利用者が画面に入力し、画面が管理オブジェクトへ処理を依頼し、管理オブジェクトがデータベースへ問い合わせる、というような流れですね。選択肢では、メッセージの順番や送信先が入れ替わっていることがあります。最初の矢印、次の矢印、戻りの矢印を順に確認してください。

シーケンス図は「上から下へ時間が進む」と覚えるだけで読みやすくなります。左右は登場人物、縦は時間、矢印はメッセージとして分けて見ましょう。

クラス図との違いも押さえておくと整理しやすいです。クラス図は静的な構造を表します。どんな部品があり、どんな関係があるかを見る図です。シーケンス図は動的な振る舞いを表します。処理中にどんな順番でやり取りが発生するかを見る図です。問題文に「処理の順序」「メッセージ」「呼び出し」「応答」が出てきたら、シーケンス図の読み方に近いと判断できます。

シーケンス図で焦りやすいのは、戻りの矢印や破線が出てきたときです。細かい表記に不安があっても、まずは呼び出しの順番と相手を確認してください。最初に誰が処理を始め、次にどの相手へ依頼し、最後にどの結果が返るのか。この流れを追えれば、メッセージの順序が入れ替わった選択肢を切りやすくなります。

過去問では根拠を探す

基本情報のUML図を得点につなげるには、過去問で「なぜその選択肢が正しいのか」を説明する練習が必要です。図を見てなんとなく正しそうな選択肢を選ぶだけだと、似た表現で迷います。解いたあとに、問題文のどの条件、図のどの線、どの属性、どの処理順から判断したのかを確認しましょう。根拠を言葉にできると、初見問題でも安定しやすくなります。

最初から時間を測って解く必要はありません。最初の数問は、問題文の名詞と動詞を拾い、図の要素と対応させ、選択肢ごとに合っている点と違う点を探します。慣れてきたら、時間を意識して解きます。UML図は、知識問題と読解問題の中間のような存在です。記号の意味だけでは足りませんが、読解だけでも限界があります。用語と根拠探しをセットにするのが効率的です。

過去問を解いたら、正解番号だけでなく「図のどこを見て判断したか」を一行でメモしてください。この一手間で、UML図の読み取りが暗記から根拠ベースの判断に変わります。

今すぐ手を動かすなら、基本情報の過去問アプリで無料演習できます。UML図は、解説を読むだけでなく、実際の問題で「どの図のどこを見たか」を確認する方が身につきやすいです。特にクラス図の多重度、アクティビティ図の分岐、ユースケース図のアクターは、演習で繰り返し見ると判断が速くなります。

復習では、間違えた理由を「記号を知らなかった」「問題文との対応を見落とした」「選択肢の主語を読み違えた」のように分類しておくと便利です。同じUML図のミスでも、原因が違えば対策も変わります。知識不足なら記号を覚え直し、読解ミスなら問題文と図を結ぶ練習を増やす、というように分けて直しましょう。

基本情報のUML図まとめ

基本情報のUML図は、すべての記号を深く覚えるより、まず図の目的で見分けることが大切です。クラス図は構造、アクティビティ図は流れ、ユースケース図は利用者と機能の関係、シーケンス図は時間順のやり取りを表します。この軸があるだけで、初見の図でも「何を見ればいいのか」が決まりやすくなります。

クラス図では、クラス名、属性、操作、関係、多重度を確認します。アクティビティ図では、開始、処理、分岐、合流、終了を矢印に沿って追います。ユースケース図では、アクターと機能の対応を見ます。シーケンス図では、上から下へ時間が進むことを意識し、誰が誰にメッセージを送っているかを確認します。どの図でも、設問文と図の対応を根拠にして選ぶことが共通です。

UML図は「きれいに書く知識」ではなく、「設問文と図を対応させて読む知識」として勉強すると得点につながりやすいです。

• 図の目的を最初に確認する
• クラス図は構造と多重度を見る
• アクティビティ図は条件分岐を追う
• ユースケース図はアクターと機能を見る
• 過去問では判断根拠を一行で残す

苦手な人は、まずクラス図、アクティビティ図、ユースケース図、シーケンス図を一言で説明できるようにしてください。そのあと、過去問で図を日本語に直す練習をします。基本情報の範囲は広いので、UMLだけに時間をかけすぎる必要はありません。ただ、UML図を読めるようになると、ソフトウェア設計やテスト技法の問題も少し見えやすくなります。焦らず、図の目的、記号、設問文の順で確認していきましょう。

最後に、UML図は毎日長時間やるより、他の設計問題やテスト問題と一緒に少しずつ触れる方が続けやすいです。クラス図で構造を読む、アクティビティ図で流れを読む、ユースケース図で役割を読む。この基本パターンを何度も確認すれば、初見の図でも見るべき場所を外しにくくなります。