開発方法論
下の動画はこの節の解説ではありません。 解説動画の雰囲気を知っていただくための見本として、「AI・機械学習」の動画を再生します。
この節の解説動画はプレミアム限定です。プレミアムなら全科目・全節が見放題！
プレミアムで見るUMLは、オブジェクト指向のシステム開発における設計図の統一表記法です。13種類ほどの図が定められていますが、試験で繰り返し問われるのは「ユースケース図」「クラス図」「シーケンス図」「アクティビティ図」の4つ。しかも、その4つを入れ替えた誤った記述が出題の定番です。この節では、それぞれの図が「何を表すのか」を、混同しないように区別しながら押さえていきます。
簡単にいうと
UMLは「表記法」であって「開発手法」じゃない——ここが一番のポイント！1997年にOMGが標準として認定したことも、そのまま出題されるよ。
① UML（Unified Modeling Language）とは
UMLは、オブジェクト指向のシステム開発におけるプログラム設計図の統一表記法です。
② 標準化の経緯
従来、オブジェクト指向設計の表記法は50以上の規格が乱立していましたが、1997年にOMG（Object Management Group：オブジェクト指向技術の標準化、普及を進めるための業界団体）によってUMLが標準として認定されました。
| 項目 | 内容 |
|---|---|
| それまで | 50以上の規格が乱立 |
| 1997年 | OMGがUMLを標準として認定 |
③ OMGとは
| 項目 | 内容 |
|---|---|
| 正式名称 | Object Management Group |
| 性格 | オブジェクト指向技術の標準化、普及を進めるための業界団体 |
前節で学んだBPMNも、2005年の合併後はOMGがメンテナンスを行っています。
④ UMLのメリット
UMLを利用することで、共通の設計図を用いてコミュニケーションを円滑に行えるというメリットがあります。
| 統一されないと | 統一されると |
|---|---|
| 人によって書き方が違う | 誰が書いても同じ読み方ができる |
| 読むたびに記法を確認 | そのまま読める |
| 会社が変わると通じない | 業界共通で通じる |
⑤ UMLは開発手法ではない
UMLそのものは表記法にすぎず、開発手法ではありません。
| 誤解 | 実際 |
|---|---|
| UMLという開発手法がある | UMLは表記法。開発手法ではない |
この点が試験で問われます。
⑥ 各種図の使い分けは自分で決める
またUMLで用いる各種図は、用途や目的を明確に定義したものではありません。
よって、各工程では必要な図を用途や目的に合わせて選択する必要があります。
| 誤解 | 実際 |
|---|---|
| どの工程でどの図を使うか決まっている | 用途や目的に合わせて選択する |
| すべての図を書かなければならない | 必要な図だけ書けばよい |
⑦ 2つの「〜ではない」
UMLの位置づけは、2つの否定で押さえるのが確実です。
| 否定 | 内容 |
|---|---|
| 開発手法ではない | 表記法にすぎない |
| 用途や目的を明確に定義したものではない | 各工程で必要な図を選択する |
⑧ UMLの図の種類
UMLには、大きく分けて構造を表す図と振る舞いを表す図があります。
| 分類 | 図 |
|---|---|
| 構造（静的） | クラス図、オブジェクト図、コンポーネント図、配置図、コンポジットストラクチャ図 |
| 振る舞い（動的） | ユースケース図、シーケンス図、コミュニケーション図、ステートマシン図、アクティビティ図、タイミング図、インタラクションオーバービュー図 |
⑨ 試験で押さえるべき図
すべてを細かく覚える必要はありません。繰り返し出題されているのは次の4つです。
| 図 | 表すもの |
|---|---|
| ユースケース図 | システムとその利用者とのやり取り（システムが提供する機能） |
| クラス図 | 概念・事物・事象とそれらの間の関連（静的な構造） |
| シーケンス図 | オブジェクト間のメッセージの流れを時系列に |
| アクティビティ図 | 業務や処理の実行順序 |
この4つを、互いに入れ替えた記述が出題の定番です。
⑩ オブジェクト指向との関係
UMLはOOA（オブジェクト指向アプローチ）で用いられる図式化技法です。
| アプローチ | 技法 |
|---|---|
| POA | DFD |
| DOA | E-R図 |
| OOA | UML |
前節で学んだ対応関係を、ここでもう一度確認しておきましょう。
具体例
UMLが生まれた背景
1990年代前半、オブジェクト指向設計の表記法は乱立していました。
| 状況 | 起きていたこと |
|---|---|
| 50以上の規格 | どの記法で書くかを毎回決める必要があった |
| 人によって書き方が違う | 読み手が記法を学び直す |
| ツールが対応できない | 設計支援ツールが記法ごとに別々 |
統一による効果
| 効果 | 内容 |
|---|---|
UMLの主な図
試験のポイント
簡単にいうと
ユースケース図の登場人物は3つ！ ユースケース・アクター・システム境界。「システムが提供する機能を記述する」——この一文がそのまま正解肢になるよ。
① ユースケース図とは
ユースケース図は、対象となるシステムとその利用者とのやり取りを表現するダイアグラムです。
② 3つの構成要素
| 要素 | 内容 | 記号 |
|---|---|---|
| ユースケース | システムの機能を意味する |
簡単にいうと
クラス図は「E-R図に相当する」——この一文が大事！そして多重度の「0..*」「0..1」「1」の読み方も出るよ。クラス図が抽象、オブジェクト図が具体、と覚えよう。
① クラス図とは
クラス図は、対象となるシステムを構成する概念・事物・事象とそれらの間にある関連を表現するダイアグラムです。
② E-R図との対応
UMLにおいて静的な構造を示すクラス図は、E-R図に相当します。
| E-R図 | クラス図 | |
|---|---|---|
| 用いるアプローチ |
簡単にいうと
シーケンス図は「時系列」、コミュニケーション図は「誰と誰が」。同じ相互作用を、時間で見るか関係で見るかの違いだよ。シーケンス図の「時系列」は超頻出！
① シーケンス図とは
シーケンス図は、オブジェクト間のメッセージの流れ（相互作用）を時系列に記述するダイアグラムです。
サービスを要求するオブジェクトからサービスを提供するオブジェクトに向けて矢線を引くことにより、メッセージを時系列に記述できます。
② 「時系列」がキーワード
| 図 | キーワード |
|---|---|
| シーケンス図 | 時系列 |
簡単にいうと
アクティビティ図は「UMLのフローチャート」！ エンドユーザにも理解しやすいのが特長。そして「業務や処理の実行順序を記述する」——ユースケース図と入れ替える誤りが定番だよ。
① ステートマシン図（従来、ステートチャート図）
ステートマシン図は、システム内部の振る舞いを表現するためのもので、ユースケースをまたがったオブジェクトごとの状態遷移を表現するダイアグラムです。
オブジェクトの状態は時間の経過とともにさまざまに変化しますが、ステートマシン図を用いることにより、これらの様子を視覚的に表現することが可能になります。
② ステートマシン図の構成要素
| 要素 | 内容 |
|---|---|
| 状態 | オブジェクトが取りうる状態 |
動画・テキスト・過去問・AI添削まですべて網羅！
予備校代の1/10以下で、独学の不安をまるごと解決できます
全7科目536節の解説動画539本・合計約41時間が見放題。連続再生・ブックマーク再生で、移動中も1本5分前後で進められます。プレミアム限定
令和3〜7年度の1次過去問1,116問を、科目別・年度別に無制限で演習。問題の図・表と解説つきで、間違えた問題はマイページに残ります。プレミアム限定
2次は事例I〜IVの114設問に何度でも書いて出せます。AIが設問ごとの基準で採点し、改善点は「どう書き直すか」の例と模範解答つき。プレミアム限定
科目別のテキストPDFをダウンロードできます。印刷して書き込む、タブレットで持ち歩くなど、好きな使い方で。プレミアム限定| 共通の設計図で話せる |
| ツールが揃う | 設計支援ツールが共通で使える |
| 人材の流動性が上がる | 会社が変わっても同じ記法 |
「表記法」であることの意味
| 決めていること | 決めていないこと |
|---|---|
| どう書くか（記号の意味） | いつ書くか |
| どの図を使うか | |
| どう開発を進めるか |
楽譜にたとえる
| 楽譜 | UML |
|---|---|
| 音符の書き方を決めている | 図の書き方を決めている |
| どんな曲を作るかは自由 | どう開発するかは自由 |
「UMLで開発する」という言い方は正確ではない——UMLはあくまで書き方の取り決めです。
設例 UMLの位置づけ
> 次の記述の正誤を判定せよ。
> a UMLは、オブジェクト指向のシステム開発におけるプログラム設計図の統一表記法である。
> b UMLは、1997年にOMGによって標準として認定された。
> c UMLで用いる各種図は、用途や目的を明確に定義しているため、各工程で用いる図があらかじめ決まっている。
解答 a：○ b：○ c：×
cの誤りの作られ方
| 本文 | 選択肢 |
|---|---|
| 用途や目的を明確に定義したものではない | 明確に定義している |
| 必要な図を選択する必要がある | あらかじめ決まっている |
否定を肯定に変えるのが、この手の誤りの作り方です。本文に「〜ではない」と書かれている箇所は、そのまま出題されると考えておきましょう。
中小企業の現場でUMLを使うか
| 場面 | 使うか |
|---|---|
| ベンダとの仕様確認 | ベンダが使うことが多い |
| 経営者への説明 | 向かない（専門的すぎる） |
| 業務部門との整理 | ユースケース図なら使える |
ユースケース図だけは例外
| 図 | 業務部門が読めるか |
|---|---|
| ユースケース図 | 読める（人型と楕円だけ） |
| アクティビティ図 | 読める（フローチャートに近い） |
| クラス図 | 難しい |
| シーケンス図 | 難しい |
「誰に見せる図か」で選ぶ——UMLが用途を固定していないからこそ、この判断が必要になります。
診断士としての関わり方
| 場面 | 役割 |
|---|---|
| ベンダから設計書が出てきた | ユースケース図で機能の抜けを確認する |
| 要件を整理する | アクティビティ図で業務の流れを確認する |
| 細かい設計 | ベンダに任せる |
すべてを読める必要はなく、「何を表している図か」が分かれば十分です。
| アクター | システムの外部に存在してユースケースを起動しシステムから情報を受け取る | 人型 |
| システム境界 | システム内部とシステム外部の境界を示す | 四角の枠 |
③ 目的
システムに対するユーザ要求を明確にすることを目的としています。
④ 受注管理システムの例
| 要素 | 内容 |
|---|---|
| システム境界 | 受注管理システム |
| アクター | ユーザ、本社オペレータ |
| ユースケース | ユーザを登録する／商品を注文する／注文を確認する／商品を登録する |
誰がどの機能を使うか
| アクター | 使うユースケース |
|---|---|
| ユーザ | ユーザを登録する、商品を注文する、注文を確認する |
| 本社オペレータ | 注文を確認する、商品を登録する |
線で結ばれている＝そのアクターがその機能を使う、という読み方です。
⑤ アクターの定義に注意
| 項目 | 内容 |
|---|---|
| どこにいるか | システムの外部 |
| 何をするか | ユースケースを起動し、システムから情報を受け取る |
アクターは人だけとは限りません。外部システムや他のシステムもアクターになりえます。
⑥ システム境界の意味
| 内側 | 外側 |
|---|---|
| ユースケース（システムの機能） | アクター |
「どこまでがシステムの責任範囲か」を明示するのがシステム境界の役割です。
⑦ ユースケース図が役立つ場面
| 場面 | 効果 |
|---|---|
| 要件定義の初期 | 必要な機能を洗い出せる |
| 利用者との合意 | 図が単純なので読んでもらえる |
| 開発範囲の確認 | 境界の内か外かで判断できる |
⑧ 「システムが提供する機能を記述する」
試験ではこの表現で問われます。
| 図 | 記述するもの |
|---|---|
| ユースケース図 | システムが提供する機能 |
令和5年度の本試験では、この内容がアクティビティ図の説明として出題され、誤りとされました。
⑨ アクティビティ図との違い
| ユースケース図 | アクティビティ図 | |
|---|---|---|
| 表すもの | システムが提供する機能 | 業務や処理の実行順序 |
| 着目点 | 何ができるか | どういう順で動くか |
| 時間 | 表さない | 表す |
「機能の一覧」がユースケース図、「順序」がアクティビティ図——この対比で押さえます。
⑩ 読み方のこつ
ユースケース図を見たら、次の3点を確認します。
| 確認 | 内容 |
|---|---|
| ① | 誰が使うか（アクター） |
| ② | 何ができるか（ユースケース） |
| ③ | どこまでがシステムか（システム境界） |
この3点だけで読めるのが、ユースケース図の使いやすさです。
具体例
設例 ユースケース図
> 次の記述の正誤を判定せよ。（令和5年度第17問 改題）
> UMLにおけるユースケース図は、業務や処理の実行順序を記述する。
解答 ×
アクティビティ図の内容です。
正しい説明
| 図 | 記述するもの |
|---|---|
| ユースケース図 | 対象となるシステムとその利用者とのやり取り（システムが提供する機能） |
| アクティビティ図 | 業務や処理の実行順序 |
ユースケース図を書いてみる
小売店の在庫管理システムを例にします。
手順① アクターを洗い出す
| アクター | 立場 |
|---|---|
| 店舗スタッフ | 在庫を確認、入出庫を登録 |
| 店長 | 在庫状況を確認、発注 |
| 本部 | 全店舗の在庫を確認 |
| POSシステム | 外部システムもアクター（売上データを渡す） |
手順② ユースケースを洗い出す
| ユースケース |
|---|
| 在庫を照会する |
| 入庫を登録する |
| 出庫を登録する |
| 棚卸を行う |
| 発注する |
| 在庫レポートを出力する |
手順③ 線で結ぶ
| アクター | 使うユースケース |
|---|---|
| 店舗スタッフ | 在庫を照会する、入庫を登録する、出庫を登録する、棚卸を行う |
| 店長 | 在庫を照会する、発注する、在庫レポートを出力する |
| 本部 | 在庫レポートを出力する |
| POSシステム | 出庫を登録する（販売時に自動で） |
手順④ 境界を引く
| 内側 | 外側 |
|---|---|
| 在庫管理システムの6機能 | 4つのアクター |
ユースケース図で見つかること
| 発見 | 内容 |
|---|---|
| 誰も使わないユースケースがある | 不要な機能 |
| 1人のアクターに機能が集中している | 業務負荷の偏り |
| 必要な機能が抜けている | 要件の漏れ |
3つ目がとくに重要
| 問い | 例 |
|---|---|
| 返品はどう扱うのか | 「返品を登録する」が抜けている |
| 廃棄はどう扱うのか | 「廃棄を登録する」が抜けている |
図にして関係者に見せると、抜けが見つかります。
なぜ利用者と話しやすいのか
| 理由 | 内容 |
|---|---|
| 記号が2つだけ（人型と楕円） | 説明が要らない |
| 専門用語が出てこない | 業務の言葉で書ける |
| 「誰が何をするか」で書ける | 業務の理解と一致する |
ユースケースの名前の付け方
| よい名前 | よくない名前 |
|---|---|
| 商品を注文する | 注文処理 |
| 在庫を照会する | 在庫機能 |
「〜する」という動作で書くと、利用者に伝わりやすくなります。
診断士としての使い方
| 場面 | 使い方 |
|---|---|
| ベンダの提案を確認する | ユースケース図で機能の過不足を見る |
| 業務部門の要望を整理する | 誰が何をしたいかを図にする |
| 費用対効果を考える | 使われないユースケースを削る |
「使われない機能を作らない」ことが、費用を抑える近道です。LSD（リーンソフトウェア開発）の「ムダをなくす」「作りすぎのムダ」という発想と、ここでつながります。
確認してみましょう
> 次の記述の正誤を判定せよ。
> a ユースケース図は、システムの機能を意味するユースケース、システムの外部に存在するアクター、システム境界などから構成される。
> b ユースケース図は、システムに対するユーザ要求を明確にすることを目的としている。
> c アクターとは、システム内部に存在し、ユースケースを起動する要素である。
解答 a：○ b：○ c：×
ユースケース図（1／2）
ユースケース図（2／2）
試験のポイント
| OOA |
| 表すもの | データの構造 | 静的な構造 |
この対応関係は、そのまま出題されます。
③ クラス図で表す関係
| 記号 | 関係 |
|---|---|
| △（白い三角） | 「汎化―特化」の関係 |
| ◇（白いひし形） | 「集約―分解」の関係 |
④ 汎化―特化の例
| 上位（汎化） | 下位（特化） |
|---|---|
| 動物 | イヌ、サル、キジ |
「イヌは動物の一種である」という関係です。
| 見方 | 内容 |
|---|---|
| 上から下 | 特化（動物を細かく分ける） |
| 下から上 | 汎化（共通点でまとめる） |
⑤ 集約―分解の例
| 全体（集約） | 部分（分解） |
|---|---|
| 自動車 | タイヤ、車体、エンジン |
「自動車はタイヤ・車体・エンジンから成る」という関係です。
⑥ 2つの関係の違い
| 関係 | 言い換え | 例 |
|---|---|---|
| 汎化―特化 | 「〜は〜の一種である」 | イヌは動物の一種 |
| 集約―分解 | 「〜は〜から成る」 | 自動車はタイヤから成る |
「一種である」か「から成る」かで見分けます。
⑦ 多重度
クラス図で2つのクラス間のリレーション（関連）を定義する際に、一方のインスタンスにリンクする他方のインスタンスの数を多重度とよびます。
関連を表す線の両方の終端近くには、それぞれの相手に対するクラス間の多重度の範囲を表します。
⑧ 多重度の表記
多重度の範囲は、下限をn、上限をmとする場合は「n..m」という形式で表します。
| 表記 | 意味 |
|---|---|
| 1 | 接続線が必ず1つ |
| 0..1 | 接続が存在しないか、あるいは1つ |
| 0..\* | 接続がゼロ以上 |
⑨ 多重度の読み方（例）
「社員」と「部署」を「所属」で結び、社員側に0..\*、部署側に1と書かれている場合。
| 読み方 |
|---|
| 1人の社員は、必ず1つの部署に所属する |
| 1つの部署には、0人以上の社員が所属する |
読む向きに注意
| 書かれている場所 | 読み方 |
|---|---|
| 相手側に書かれた数 | 自分1つに対して相手がいくつか |
部署側に「1」→ 社員1人から見て部署は1つ。
社員側に「0..\*」→ 部署1つから見て社員は0人以上。
⑩ オブジェクト図
オブジェクト図は、システムのある時点におけるオブジェクト間の関係を記述するダイアグラムです。
クラス図が抽象的な構造・関係を記述しているのに対し、オブジェクト図では個々のオブジェクト（インスタンス）の関係を表現します。
| クラス図 | オブジェクト図 | |
|---|---|---|
| 表すもの | 抽象的な構造・関係 | 個々のオブジェクト（インスタンス）の関係 |
| 時点 | 時点を持たない | ある時点 |
⑪ オブジェクト図の書き方
オブジェクト図では、各インスタンスを四角形で表します。中にはインスタンスの名称と、そのインスタンスが属するクラスを併記し、下線を引きます。
| 書き方 |
|---|
| インスタンス名：クラス名（下線付き） |
例
| 表記 | 意味 |
|---|---|
| 店舗A：店舗 | 「店舗」クラスのインスタンス「店舗A」 |
| 紳士服：部門 | 「部門」クラスのインスタンス「紳士服」 |
⑫ クラスとインスタンス
第8章のプログラミング言語で学んだ関係です。
| 用語 | 意味 |
|---|---|
| クラス | 設計図（型） |
| インスタンス | 実体（クラスから作られた個々のもの） |
| 例 | クラス | インスタンス |
|---|---|---|
| 店舗 | 店舗 | 店舗A、店舗B、店舗C |
| 部門 | 部門 | 紳士服、婦人服、食品 |
クラス図は設計図の関係、オブジェクト図は実体の関係——この対比で整理できます。
具体例
多重度を読む練習
「社員」と「部署」が「所属」で結ばれ、多重度が次のように書かれています。
| クラス | 多重度 |
|---|---|
| 社員側 | 0..\* |
| 部署側 | 1 |
読み方
| 向き | 読み |
|---|---|
| 社員から部署を見る | 1人の社員は、必ず1つの部署に所属する |
| 部署から社員を見る | 1つの部署には、0人以上の社員が所属する |
この多重度が意味すること
| 業務ルール |
|---|
| 兼務は認められない（社員は1つの部署のみ） |
| 社員が0人の部署が存在しうる（新設部署など） |
多重度を変えると業務ルールが変わる
| 多重度 | 意味する業務ルール |
|---|---|
| 社員側 0..\*、部署側 1 | 兼務なし。空の部署あり |
| 社員側 1..\*、部署側 1 | 兼務なし。部署には必ず1人以上 |
| 社員側 0..\*、部署側 1..\* | 兼務あり |
多重度は、業務ルールの表明です。設計の段階でここを間違えると、後から直すのが大変になります。
よくある設計の失敗
| 状況 | 起きること |
|---|---|
| 「兼務はない」と決めてシステムを作った | 後から兼務が発生し、対応できない |
| 「顧客は1つの住所」と決めた | 請求先と納品先が違う場合に困る |
業務の実態を確認してから多重度を決める——診断士として関われる部分です。
汎化―特化と集約―分解を、業務で考える
汎化―特化の例
| 上位 | 下位 |
|---|---|
| 従業員 | 正社員、パート、アルバイト |
| 商品 | 食品、日用品、衣料品 |
| 取引先 | 仕入先、得意先 |
共通の属性は上位に、固有の属性は下位に
| クラス | 属性 |
|---|---|
| 従業員（上位） | 従業員コード、氏名、入社日 |
| 正社員（下位） | 基本給、役職 |
| パート（下位） | 時給、契約期間 |
集約―分解の例
| 全体 | 部分 |
|---|---|
| 受注 | 受注明細 |
| 製品 | 部品 |
| 店舗 | 部門 |
オブジェクト図の例
店舗Aの部門構成を、ある時点で表します。
| インスタンス | 属するクラス |
|---|---|
| 店舗A | 店舗 |
| 衣服、家具、食品 | 部門 |
| 紳士服、婦人服、子供服 | 部門（衣服の下） |
| 生鮮食品、菓子類 | 部門（食品の下） |
| 紳士服売上、婦人服売上…… | 売上 |
リンク（線）で、インスタンス同士のつながりを表します。
クラス図なら、こうなる
| クラス | 関連 |
|---|---|
| 店舗 | 1 ― 0..\* 部門 |
| 部門 | 1 ― 0..\* 売上 |
クラス図は「店舗には複数の部門がある」という一般則、オブジェクト図は「店舗Aには衣服・家具・食品という部門がある」という具体例です。
設例 クラス図
> 次の記述の正誤を判定せよ。（令和4年度第11問 改題）
> a クラス図は、対象となるシステムを構成する概念・事物・事象とそれらの間にある関連を表現するダイアグラムである。
> b UMLにおいて静的な構造を示すクラス図は、DFDに相当する。
> c オブジェクト図では、個々のオブジェクト（インスタンス）の関係を表現する。
解答 a：○ b：× c：○
bの誤りに注意
| 図 | 相当するもの |
|---|---|
| クラス図 | E-R図 |
| アクティビティ図 | BPMN（同等の機能） |
どちらも「対応するもの」を問う形で出題されます。
UMLのクラス図
試験のポイント
③ シーケンス図の構成要素
| 要素 | 内容 |
|---|---|
| オブジェクト | 上部に四角で並べる |
| ライフライン | オブジェクトから下に伸びる点線（時間軸） |
| 活性区間 | そのオブジェクトが処理を行っている区間（細長い四角） |
| メッセージ | オブジェクト間に引く矢線 |
④ 読む向き
| 方向 | 意味 |
|---|---|
| 横 | どのオブジェクトか |
| 縦（上から下） | 時間の流れ |
上にあるメッセージほど先に起きる——これが時系列の表し方です。
⑤ 受注処理のシーケンス図（例）
オブジェクトとして「顧客」「注文」「注文明細」「商品」を並べます。
| 順 | メッセージ | 送り手 → 受け手 |
|---|---|---|
| ① | 合計金額取得() | 顧客 → 注文 |
| ② | 小計算出() | 注文 → 注文明細 |
| ③ | 単価取得() | 注文明細 → 商品 |
| ④ | （戻り） | 商品 → 注文明細 |
| ⑤ | （戻り） | 注文明細 → 注文 |
| ⑥ | 消費税計算() | 注文 → 注文（自分自身） |
| ⑦ | （戻り） | 注文 → 顧客 |
読み取れること
| 読み取れること | 内容 |
|---|---|
| 処理の順序 | 合計金額 → 小計 → 単価の順に問い合わせる |
| どのオブジェクトが何をするか | 消費税計算は注文が行う |
| 戻り値の流れ | 点線の矢印で返る |
⑥ 自分自身へのメッセージ
注文オブジェクトが自分自身に「消費税計算()」を送っている部分があります。
| 意味 |
|---|
| そのオブジェクト内部の処理 |
⑦ コミュニケーション図（従来、コラボレーション図）
コミュニケーション図は、オブジェクト同士の相互作用を表現するためのダイアグラムです。
シーケンス図が時系列にやり取りされるメッセージを重視しているのに対し、コミュニケーション図ではどのオブジェクトとどのオブジェクトが関係し、どのようなメッセージをやり取りするのかを表現します。
⑧ 2つの図の違い
| シーケンス図 | コミュニケーション図 | |
|---|---|---|
| 重視するもの | 時系列にやり取りされるメッセージ | どのオブジェクトとどのオブジェクトが関係するか |
| 見やすいこと | 処理の順序 | オブジェクト間のつながり |
同じ相互作用を、違う角度から表したものです。
⑨ コミュニケーション図の例
ユーザ登録の流れを表します。
| オブジェクト |
|---|
| メールユーザ、ユーザ登録画面、ユーザ登録、データベース |
| メッセージ |
|---|
| メールユーザ → ユーザ情報入力 → ユーザ登録画面 |
| ユーザ登録画面 → ユーザ情報登録 → ユーザ登録 |
| ユーザ登録 → データベース登録 → データベース |
| データベース → 登録結果 → ユーザ登録 |
| ユーザ登録 → 登録結果 → ユーザ登録画面 |
| ユーザ登録画面 → 登録結果表示 → メールユーザ |
オブジェクトを自由に配置し、線でつなぐ——時間軸がない代わりに、関係の全体像が見やすくなります。
⑩ 名称の変更に注意
| 現在の名称 | 従来の名称 |
|---|---|
| コミュニケーション図 | コラボレーション図 |
| ステートマシン図 | ステートチャート図 |
どちらの名称でも出題されうるので、両方を押さえておきましょう。
具体例
設例 シーケンス図
> 次の記述の正誤を判定せよ。（令和5年度第17問、令和3年度第14問 改題）
> UMLにおけるシーケンス図は、オブジェクト間の相互作用を時系列に記述する。
解答 ○
この記述はそのまま正解肢として出題されています。
「時系列」という語がシーケンス図の目印
| 選択肢の語 | 対応する図 |
|---|---|
| 時系列に記述する | シーケンス図 |
| どのオブジェクトとどのオブジェクトが関係するか | コミュニケーション図 |
| システムの状態とその遷移 | ステートマシン図 |
| 業務や処理の実行順序 | アクティビティ図 |
シーケンス図とアクティビティ図の違い
どちらも「順序」を表すので混同しやすい論点です。
| シーケンス図 | アクティビティ図 | |
|---|---|---|
| 主役 | オブジェクト | 処理（アクティビティ） |
| 表すもの | オブジェクト間のメッセージの流れ | 業務や処理の実行順序 |
| 読む相手 | 開発者 | エンドユーザにも理解しやすい |
「オブジェクト間のメッセージ」が出たらシーケンス図——この結びつけが判別の鍵です。
シーケンス図を業務で読む
飲食店の注文システムを例にします。
| オブジェクト |
|---|
| 客、タブレット端末、注文管理、厨房ディスプレイ、会計 |
| 順 | メッセージ |
|---|---|
| ① | 客 → 注文入力() → タブレット端末 |
| ② | タブレット端末 → 注文登録() → 注文管理 |
| ③ | 注文管理 → 調理指示() → 厨房ディスプレイ |
| ④ | 厨房ディスプレイ → 調理完了() → 注文管理 |
| ⑤ | 注文管理 → 配膳通知() → タブレット端末 |
| ⑥ | 客 → 会計要求() → 会計 |
| ⑦ | 会計 → 注文内容取得() → 注文管理 |
読み取れる業務上の課題
| 発見 | 内容 |
|---|---|
| ④が人手の操作 | 厨房で完了ボタンを押し忘れると止まる |
| ⑤の通知先がタブレットのみ | ホールスタッフに伝わらない |
図にすると、運用上の弱点が見える——これがシーケンス図の実務的な価値です。
コミュニケーション図が向く場面
| 場面 | 理由 |
|---|---|
| システム間の連携を俯瞰したい | つながりの全体像が見える |
| どこと通信しているか確認したい | 関係が線で見える |
シーケンス図が向く場面
| 場面 | 理由 |
|---|---|
| 処理の順序を確認したい | 上から下に読める |
| タイミングの問題を調べたい | 時系列が見える |
| 応答時間を検討したい | どこで時間がかかるか追える |
同じ情報を2通りに表せる
| 図 | 強み |
|---|---|
| シーケンス図 | 時間軸が明確 |
| コミュニケーション図 | 関係の構造が明確 |
どちらか一方が優れているのではなく、見たいものによって使い分ける——UMLが「用途や目的を明確に定義したものではない」という性格が、ここに表れています。
確認してみましょう
> 次の記述の正誤を判定せよ。
> a シーケンス図では、サービスを要求するオブジェクトからサービスを提供するオブジェクトに向けて矢線を引く。
> b コミュニケーション図は、従来コラボレーション図とよばれていた。
> c コミュニケーション図は、時系列にやり取りされるメッセージを重視している。
解答 a：○ b：○ c：×
シーケンス図とコミュニケーション図（1／2）
シーケンス図とコミュニケーション図（2／2）
試験のポイント
| 状態遷移 | 状態から状態への移り変わり |
| イベント | 遷移のきっかけ |
| 開始・終了 | ●で開始、◎で終了 |
③ 注文登録のステートマシン図（例）
| 状態 | 次の状態へのイベント |
|---|---|
| （開始） | 「注文」メニューの選択 |
| 顧客確認 | 顧客番号の入力 |
| 商品登録 | 注文する商品の確定（自分自身へ：注文する商品の追加） |
| 配達日指定 | 配達日の確定 |
| 注文登録中 | 注文登録の終了 |
| （終了） | — |
自分自身に戻る遷移
| 状態 | 内容 |
|---|---|
| 商品登録 | 注文する商品の追加（何度でも繰り返せる） |
④ 状態遷移図との違い
前節で学んだ状態遷移図（STD）と似ていますが、位置づけが異なります。
| 状態遷移図（STD） | ステートマシン図 | |
|---|---|---|
| 属するもの | UML以外のモデリング技法 | UMLの図の1つ |
| 表すもの | システムの状態とその遷移 | ユースケースをまたがったオブジェクトごとの状態遷移 |
表すものは近いが、UMLの図かどうかが違う——試験ではここが問われます。
⑤ アクティビティ図
アクティビティ図は、「オブジェクトがどのような処理をするか」といった業務や処理の実行順序を記述するダイアグラムです。
いわばUMLのフローチャートであり、エンドユーザにも理解しやすいという特長があります。
| 項目 | 内容 |
|---|---|
| 記述するもの | 業務や処理の実行順序 |
| 性格 | UMLのフローチャート |
| 特長 | エンドユーザにも理解しやすい |
⑥ アクティビティ図の例
メール確認の流れを表します。
| 順 | 内容 |
|---|---|
| ① | （開始） |
| ② | メール確認する |
| ③ | （分岐）新着メールあり／なし |
| ④ | 新着メールなし → 開始に戻る |
| ⑤ | 新着メールあり → 並行して「返事を書く」「内容確認して削除」 |
| ⑥ | （合流） |
| ⑦ | （終了） |
表せること
| 表せること | 記号 |
|---|---|
| 処理 | 角丸四角 |
| 分岐 | ひし形 |
| 並行処理の開始・終了 | 太い横線 |
| 開始・終了 | ●、◎ |
⑦ BPMNとの関係
前節で学んだとおり、BPMNはUMLのアクティビティ図と同等の機能をもちます。
| 図 | 属するもの |
|---|---|
| アクティビティ図 | UML |
| BPMN | UMLとは別の表記法（OMGがメンテナンス） |
⑧ その他の図
| 図 | 内容 |
|---|---|
| コンポーネント図、配置図 | オブジェクトやコンポーネントの物理的な配置関係を記述する |
| コンポジットストラクチャ図 | クラスや部品の「中身がどう組まれているか」を止まった絵で見せる |
| タイミング図 | 動きを時間軸に乗せて、いつ何が起きるかを並べる |
| インタラクションオーバービュー図 | やりとりの流れをおおづかみに見るための、複数の図を組み合わせたもの |
⑨ コンポーネント図の例
Webシステムの構成を表します。
| 領域 | 構成要素 |
|---|---|
| インターネット | 届け先のPC |
| DMZ（非武装地帯） | Webサーバ（210.120.5.11〜14） |
| 社内ネットワーク | アプリケーションサーバ（192.168.0.63〜66）、データベースサーバ（192.168.0.80） |
第6章で学んだDMZや、第7章のクライアントサーバシステムが、そのまま図になっています。
⑩ 主な図を一覧で
| 図 | 記述するもの |
|---|---|
| ユースケース図 | システムとその利用者とのやり取り（システムが提供する機能） |
| クラス図 | 概念・事物・事象とそれらの間の関連（静的な構造） |
| オブジェクト図 | ある時点におけるオブジェクト間の関係 |
| シーケンス図 | オブジェクト間のメッセージの流れを時系列に |
| コミュニケーション図 | どのオブジェクトとどのオブジェクトが関係するか |
| ステートマシン図 | オブジェクトごとの状態遷移 |
| アクティビティ図 | 業務や処理の実行順序 |
| コンポーネント図・配置図 | 物理的な配置関係 |
⑪ 頻出の入れ替え
| 誤った記述 | 正しくは |
|---|---|
| ユースケース図は、業務や処理の実行順序を記述する | アクティビティ図 |
| アクティビティ図は、システムが提供する機能を記述する | ユースケース図 |
| ER図は、システムの状態とその遷移を記述する | 状態遷移図 |
具体例
設例 UMLの図の判別
> 次の記述の正誤を判定せよ。（令和5年度第17問 改題）
> c UMLにおけるアクティビティ図は、システムが提供する機能を記述する。
> e UMLにおけるユースケース図は、業務や処理の実行順序を記述する。
解答 c：× e：×
きれいに入れ替えられている
| 選択肢 | 書かれている内容 | 本来の図 |
|---|---|---|
| c（アクティビティ図） | システムが提供する機能 | ユースケース図 |
| e（ユースケース図） | 業務や処理の実行順序 | アクティビティ図 |
2つの図を区別する
| ユースケース図 | アクティビティ図 | |
|---|---|---|
| 表すもの | 何ができるか（機能） | どういう順で動くか（順序） |
| 記号 | 人型、楕円、四角の枠 | 角丸四角、ひし形、太い横線 |
| 時間 | 表さない | 表す |
| たとえるなら | 機能の一覧 | フローチャート |
アクティビティ図を業務で書く
飲食店の受注から提供までを表します。
| 順 | 内容 |
|---|---|
| ① | （開始） |
| ② | 注文を受ける |
| ③ | （分岐）在庫あり／なし |
| ④ | 在庫なし → 品切れを伝える →（終了） |
| ⑤ | 在庫あり → 並行して「調理する」「ドリンクを用意する」 |
| ⑥ | （合流） |
| ⑦ | 提供する |
| ⑧ |
並行処理が表せるのが強み
| 表現 | 意味 |
|---|---|
| 太い横線で分かれる | 同時に進む |
| 太い横線で合流する | 両方終わるのを待つ |
業務改善で見えること
| 発見 | 内容 |
|---|---|
| 調理とドリンクが直列になっている | 並行にできれば早くなる |
| 分岐が多すぎる | 判断が現場任せで属人化している |
| 合流待ちが長い | ボトルネックがある |
運営管理の工程分析と同じ発想
| 運営管理 | アクティビティ図 |
|---|---|
| 工程分析図 | 処理の順序 |
| 手待ちの発見 | 合流待ち |
| ボトルネック工程 | 時間のかかる処理 |
「エンドユーザにも理解しやすい」理由
| 理由 | 内容 |
|---|---|
| フローチャートに似ている | 多くの人が見慣れている |
| 専門用語が少ない | 業務の言葉で書ける |
| 上から下に読める | 順序が直感的 |
診断士が使うならアクティビティ図とユースケース図
| 図 | 使う場面 |
|---|---|
| ユースケース図 | 機能の洗い出し、過不足の確認 |
| アクティビティ図 | 業務の流れの確認、改善点の発見 |
この2つは業務部門と一緒に見られるので、現場での価値が高い図です。
ステートマシン図の実務的な使い方
| 対象 | 状態 |
|---|---|
| 受注 | 受付 → 引当済 → 出荷済 → 請求済 → 入金済 |
| 従業員 | 在籍 → 休職 → 復職／退職 |
| 在庫 | 入庫待ち → 在庫 → 引当中 → 出庫済 |
状態を洗い出すと見えること
| 発見 | 内容 |
|---|---|
| 考慮していない状態がある | 「キャンセル」はどう扱うのか |
| 戻れない遷移がある | 「出荷済」から戻せない |
| 状態が多すぎる | 業務が複雑すぎる |
「キャンセルはどうするのか」という問い
| 状態 | キャンセルできるか |
|---|---|
| 受付 | できる |
| 引当済 | できる（引当を戻す） |
| 出荷済 | 返品扱いになる |
状態ごとにルールが違う——これを整理せずにシステムを作ると、現場で例外対応が積み上がります。
確認してみましょう
> 次の記述の正誤を判定せよ。
> a アクティビティ図は、いわばUMLのフローチャートであり、エンドユーザにも理解しやすい。
> b ステートマシン図は、ユースケースをまたがったオブジェクトごとの状態遷移を表現する。
> c コンポーネント図、配置図は、クラスやコンポーネントの内部構造を静的に表現する。
解答 a：○ b：○ c：×
ステートマシン図・アクティビティ図・その他の図（1／2）
ステートマシン図・アクティビティ図・その他の図（2／2）
試験のポイント
科目別の正答率と連続学習日数がマイページに出るので、次にどの科目をやるかで迷いません。プレミアム限定プレミアムプラン
¥9,800〜/ 買い切り・自動更新なし（税込）
決済はStripe（世界最高水準・PCI-DSS準拠）で安全に処理されます。カード情報は当サービスに保存されません。
| ⑨ | （終了） |
