基本情報のUML図｜クラス図とアクティビティ図の読み方

基本情報技術者試験のソフトウェア設計で、UML図が出てくると急に手が止まる人は多いです。クラス図、アクティビティ図、シーケンス図、ユースケース図という名前は聞いたことがあっても、問題文のどこを見て判断すればいいのか迷いやすいですよね。

UMLは、図をきれいに書けるかを問うものではありません。基本情報では、図の目的、記号の意味、設問文との対応を読み取れるかが大事です。丸暗記だけで進めると、少し形が変わった問題で混乱しやすくなります。

この記事では、基本情報のUML図を「図の種類を見分ける」「要素の意味を読む」「選択肢の根拠を探す」という順番で整理します。クラス図やアクティビティ図が苦手な人でも、試験問題で見るべき場所がわかるようにまとめます。

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

UMLは目的で分ける

基本情報のUML図で最初にやることは、図の名前を全部暗記することではなく、「この図は何を表したいのか」を見ることです。システムの構造を見る図なのか、処理の流れを見る図なのか、利用者と機能の関係を見る図なのか。この分類ができると、設問文を読んだときに見る場所がかなり絞れます。UMLの種類一覧を眺めるだけでは、実際の問題でどこを見ればよいかが曖昧になりやすいです。

たとえば、クラス図は「もの同士の関係」を表す図です。顧客、注文、商品、会員のような部品があり、それぞれがどんな情報を持ち、どうつながるのかを読みます。一方、アクティビティ図は「処理の順番」を表す図です。申し込み、確認、承認、登録、通知のように、手続きがどう進むかを追います。シーケンス図は「時間の順にメッセージがどう渡るか」を見る図です。目的で分けると、名前の暗記よりも実戦で使いやすくなります。

IPAの基本情報技術者試験シラバスでも、UMLはオブジェクト指向設計の標準化された表記法として扱われ、クラス図やユースケース図などの用語例が示されています。正確な出題範囲は、IPAの基本情報技術者試験シラバスで確認できます。

図の種類	見るポイント	基本情報での考え方
クラス図	属性・操作・関係	構造を読む
アクティビティ図	開始・分岐・終了	処理手順を読む
シーケンス図	時間順のメッセージ	やり取りを読む
ユースケース図	利用者と機能	できることを読む

勉強の順番としては、まず図の目的を言えるようにし、次に記号を覚え、最後に過去問で選択肢の根拠を探す流れが向いています。出題範囲全体との位置づけを先に押さえたい場合は、基本情報技術者試験の出題範囲を完全解説した記事も合わせて見ると、UMLがどの分野に入るのか整理しやすいです。

クラス図は関係を見る

クラス図は、基本情報のUML図の中でもつまずきやすい図です。理由は、四角の中に文字が並び、線や矢印も多く、どこから読めばいいかわかりにくいからです。ただ、試験でまず見るべき場所は決まっています。最初に四角い箱の名前を見て、何を表すクラスなのかを確認します。次に、箱同士を結ぶ線を見て、どのクラスがどのクラスと関係しているのかを読みます。細かい記号をいきなり覚えようとせず、まず「登場人物」と「つながり」を押さえるのがコツです。

たとえば、会員、注文、商品というクラスがあるなら、会員は注文を行い、注文は商品を含む、という関係が考えられます。ここで大事なのは、現実の業務を想像しすぎないことです。問題文に書かれている条件を優先し、図にない関係を勝手に足さないようにします。基本情報の選択肢では、「この関係は図から読み取れるか」「この属性はどのクラスが持つべきか」のように、図と文章の対応を問われることがあります。

クラス図を読むときは、線の意味を完璧に暗記してから進むより、まず大まかな関係をつかむ方が得点につながりやすいです。もちろん、集約、合成、継承、関連などの記号は覚える必要がありますが、試験ではそれらの用語だけでなく、図を見て正しい説明を選べるかが問われます。線の端に数字が書かれている場合は多重度も重要です。ひとつの注文に複数の商品が入る、ひとりの会員が複数の注文を持つ、といった関係を読み取れるようにしておきましょう。

属性と操作を分ける

クラス図の箱は、上からクラス名、属性、操作に分かれていることが多いです。属性は、そのクラスが持つデータです。会員なら会員番号、氏名、メールアドレスのようなものですね。操作は、そのクラスが行う処理や振る舞いです。会員情報を更新する、注文を登録する、在庫を確認する、といった動きに近いものです。基本情報では、属性と操作を混同すると選択肢を間違えやすくなります。

問題文に「商品には商品番号と単価を保持する」とあれば、商品番号や単価は商品クラスの属性として考えます。一方、「注文金額を計算する」とあれば、それは操作として扱う可能性があります。ただし、実務の設計論として絶対にこうだと言い切るより、試験では問題文に書かれた条件に合わせることが大切です。基本情報の問題は、現場の設計センスを競うというより、与えられた情報から矛盾のない構造を選ぶ試験だと考えると読みやすくなります。

属性は「持っている情報」、操作は「できる処理」とざっくり分けると覚えやすいです。箱の中の区切り線を見て、データなのか処理なのかを先に分けてから選択肢を読むと、ひっかけに気づきやすくなります。

• 名詞に近いものは属性になりやすい
• 動詞に近いものは操作になりやすい
• 問題文にない属性を勝手に追加しない
• どのクラスが持つべき情報かを確認する

属性と操作を分ける練習をすると、オブジェクト指向の問題も少し楽になります。基本情報で「オブジェクト指向がわからない」と感じる場合、クラス、属性、操作、インスタンスなどの言葉が一気に出てくることが原因になりがちです。用語全体の整理が必要な人は、基本情報が理解できない原因と対策の記事も参考にしながら、まず言葉の意味を分けて覚えると進めやすいです。

多重度と矢印を読む

クラス図でよく見落とされるのが、多重度です。線の端に書かれる「1」「0..1」「0..*」「1..*」のような表記は、ひとつのクラスのインスタンスが相手側のインスタンスといくつ関係するかを表します。ここは、基本情報の選択肢でかなり使われやすいポイントです。たとえば、ひとりの会員が複数の注文を行えるなら、会員から見た注文側は複数になりやすいです。反対に、ひとつの注文が必ずひとりの会員に対応するなら、注文から見た会員側は1になります。

矢印やひし形も、意味を知っておくと読み取りが楽になります。白いひし形は集約、黒いひし形は合成として出てくることがあります。継承関係では、三角形の矢印が親クラスの方向を向きます。ただし、試験中に記号だけを見て焦る必要はありません。問題文に「AはBの一部である」「AはBの一種である」「AはBを複数持つ」のような表現がないか探すと、図の関係と対応しやすくなります。

表記	ざっくりした意味	読み方の例
1	必ず1つ	注文は1人の会員に属する
0..1	0または1つ	登録が任意の場合がある
0..*	0以上	会員は注文がない場合もある
1..*	1以上	注文には明細が1つ以上ある

多重度は、問題文の「必ず」「任意」「複数」「少なくとも」といった言葉に対応します。この言葉を見つけたら、図の数字と照らし合わせてください。特に「0..*」と「1..*」の違いは、対象が存在しないケースを許すかどうかで変わります。基本情報では、細かい表記を知らなくても常識で読める問題もありますが、数字の意味を覚えておくと、選択肢を切るスピードが上がります。

設問文と図をつなぐ

UML図の問題で大切なのは、図だけを眺め続けないことです。基本情報の問題は、ほとんどの場合、問題文、図、選択肢の三つを行き来して解きます。図の意味を完全に説明できなくても、設問文に書かれた条件と図の要素がつながれば正解に近づけます。まず問題文の名詞を拾い、次に図のクラス名やユースケース名と対応させます。そのあと、動詞や処理の順番を見て、操作やアクティビティに対応する場所を確認します。

たとえば「利用者が申請し、管理者が承認する」という文章があれば、利用者と管理者はアクターやクラスの候補になります。申請、承認は処理やユースケースの候補です。これを図の中に探すだけで、選択肢の判断がかなりしやすくなります。逆に、選択肢だけを先に読んでしまうと、もっともらしい説明に引っ張られやすいです。UML図の問題では、選択肢を読む前に、問題文と図の対応をざっくり作っておくのが安定します。

設問文の名詞はクラスやアクター、動詞は操作や処理に対応しやすいです。最初から図を完璧に読もうとせず、文章の要素を図へ写していく感覚で確認すると、根拠を持って選べます。

この読み方は、クラス図だけでなくアクティビティ図やシーケンス図にも使えます。処理の流れが問われるなら、問題文の順番を図の矢印に合わせます。オブジェクト間のやり取りが問われるなら、どの相手にメッセージが渡っているかを見ます。基本情報のUML図は、記号の知識だけでなく、文章読解の要素も強いです。だからこそ、問題文を図に対応させる練習をしておくと、初見の図でも落ち着いて読めるようになります。

基本情報のUML図の解き方

アクティビティ図は流れ

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

たとえば、注文処理のアクティビティ図なら、注文受付、在庫確認、支払い確認、出荷準備、通知といった流れが並びます。途中で在庫がない場合は別ルートに進むかもしれません。支払いが失敗した場合は処理が終了するかもしれません。このように、アクティビティ図では「どの条件でどちらに進むか」を見ることが大切です。開始から終了まで一本の線として読むのではなく、分岐ごとに条件を確認していくと安定します。

勉強するときは、図を見ながら自分で一文ずつ説明してみるのがおすすめです。「開始後に申請内容を確認する。条件を満たせば承認処理に進む。満たさなければ差し戻す」のように、矢印を文章へ変換します。これができれば、アクティビティ図の読み取り問題はかなり解きやすくなります。図を眺めるだけで終わらせず、処理の順番を声に出すかメモにするのがポイントです。

シーケンス図は時間順

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

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

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

クラス図との違いも押さえておきましょう。クラス図は構造を表す静的な図です。どんな部品があり、どんな関係があるかを見ます。シーケンス図は振る舞いを表す動的な図です。処理の中でどんな順番でメッセージが渡るかを見ます。問題文に「処理の順序」「メッセージ」「呼び出し」「応答」のような言葉が出てきたら、シーケンス図の考え方に近いと判断できます。図の種類を目的で切り分けると、選択肢を読む前に方向性が決まります。

ユースケース図は役割

ユースケース図は、利用者や外部システムが、システムでどんな機能を使うのかを表します。棒人間のようなアクターと、楕円で描かれるユースケースが出てくる図ですね。基本情報では、利用者の役割、システム境界、機能の関係を読み取る問題として出てくることがあります。ユースケース図では、処理の細かい順番よりも、「誰が何をできるか」を見るのが大切です。

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

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

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

過去問では根拠を探す

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

過去問演習では、最初から時間を測って解くより、最初の数問はゆっくり読んで構いません。図に出てくる要素を問題文へ戻し、選択肢ごとに合っている点と違う点を探します。慣れてきたら、時間を意識して解きます。UML図は、知識問題と読解問題の中間のような存在です。記号を覚えるだけでは足りませんが、読解だけでも限界があります。用語の意味と、問題文との対応をセットで練習するのが効率的です。

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

演習量の目安に迷う場合は、基本情報の過去問は何年分解くべきかをまとめた記事も参考になります。UMLだけを何十問も解くというより、ソフトウェア設計、オブジェクト指向、開発手法の問題と一緒に触れる方が、知識がつながりやすいです。図が出てきた問題は、正解しても復習対象にして、どの記号や関係を見たのか確認しておきましょう。

基本情報のUML図まとめ

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

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

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

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

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