令和6年度 春期 応用情報技術者試験 午後 問8 ObserverパターンによるダッシュボードのUI設計
テクノロジシステム開発技術
この問題は2024(R6)春 応用情報技術者 午後に出題されたものです。出題時点の法令・制度に基づく内容のため、現行の内容と一致しない場合があります。
本ページの問題文・選択肢は、原本の体裁を Web 表示用に正規化しています(改行・記号・数式・図表参照の調整)。設問の趣旨および正解に影響する変更は加えていません。
学習ガイド
販売情報をリアルタイムに可視化するダッシュボードを題材に、Observerパターンを使ったクラス設計を問う問題です。SubjectとObserverの役割分担、クラス間の関係と多重度、そして仕様変更への対応まで、デザインパターンを「知っている」から「使える」に引き上げることを狙った出題です。この記事では、データ更新が画面のグラフに反映されるまでの通知の流れを追いながら、各空欄の答えを確定していきます。
この記事で押さえる論点
- Observerパターンの構造(Subject/Observer)をクラス図で説明する
- 通知の流れから関係するクラスと多重度を特定する
- 仕様変更時に修正が局所化される設計の利点を具体化する
出題情報
- 出題
- 2024(R6)春 応用情報技術者 午後 問8
- 配点
- 20点満点
- 模範解答
- 公表(設問ごとに掲載)
出題趣旨・採点講評(IPA 公表)
アプリケーションの設計を行う際,デザインパターンを参考にすることで,効率よく妥当な設計ができることが多い。また,デザインパターンに沿った設計を行うことで,アプリケーションの設計思想を他者と共有しやすくなる利点もある。本問では,販売情報をリアルタイムに可視化するダッシュボードの設計を題材として,デザインパターンの一つであるObserverパターンを参考にしたクラス設計に関する理解と応用力を問う。
問8では,販売情報をリアルタイムに可視化するダッシュボードの設計を題材に,デザインパターンの一つであるObserverパターンを参考にしたクラス設計について出題した。全体として正答率は平均的であった。
問題本文
問8 ダッシュボードの設計に関する次の記述を読んで,設問に答えよ。
Y社は,食品などを販売する店舗を経営する企業である。複数ある店舗では,商品の販売状況や在庫状況に合わせて,割引率を設定したり,店舗間で在庫の移動を行ったりしている。販売に関する情報は販売管理システムで管理しているが,状況をリアルタイムで監視するには不向きであった。そこで,販売状況をリアルタイムで監視できるシステム(以下,ダッシュボードという)を開発することにした。
Y社では,商品ごとに商品分類を設定し,売上金額や販売数の集計に利用している。Y社が扱う情報のデータモデル(抜粋)を図1に,ダッシュボードのイメージ(一部)を図2に示す。

図の説明テキスト
データモデルの抜粋図(ER図)。
左側に凡例があり、直線は「1対1」、右矢印は「1対多」、両矢印は「多対多」を表す。
各テーブルと関係は以下の通り。
- 店舗マスタ(店舗コード, 店舗名) から 販売実績(店舗コード, 販売コード, 販売日時, 売上金額合計) へ「1対多」
- 店舗マスタ から 在庫(店舗コード, 商品コード, 在庫数) へ「1対多」
- 販売実績 から 販売明細(店舗コード, 販売コード, 商品コード, 単価, 数量) へ「1対多」
- 商品分類マスタ(商品分類コード, 商品分類名) から 商品マスタ(商品コード, 商品分類コード, 商品名, 単価) へ「1対多」
- 商品マスタ から 在庫 へ「1対多」
- 商品マスタ から 販売明細 へ「1対多」

図の説明テキスト
ダッシュボードのイメージ図(一部)。3つのグラフが横に並んでいる。
- 左: 「時間帯ごと商品分類ごとの売上金額(千円)」を示す積み上げ棒グラフ。横軸は時間帯(7:00-, 8:00-, 9:00-, 10:00-, 11:00-)、縦軸は売上金額(0〜3,000)。凡例は「青果」「総菜」「肉類」。
- 中央: 「売上金額全体に対する店舗ごとの割合」を示す円グラフ。A店(49%)、B店(34%)、C店(17%)の割合が示されている。
- 右: 「時刻ごと店舗ごとの売上金額推移(千円)」を示す折れ線グラフ。横軸は時刻(8:00, 9:00, 10:00, 11:00, 12:00)、縦軸は売上金額(0〜3,000)。凡例はA店、B店、C店の推移。
販売状況や在庫状況はデータベースで管理する。データベースに新たな販売実績が追加されたり,在庫数が更新されたりすると,その内容がダッシュボードに随時反映され,最新の情報が表示される。
Y社は,ダッシュボードの開発をZ社に依頼し,Z社はその設計に取り掛かった。
〔ダッシュボードのクラスの設計〕
Z社は,ダッシュボードのクラスの設計を行った。設計したクラス図を図3に,表示できるグラフの種類を表1に,主なクラスの説明を表2に示す。Controllerクラスは,システム全体の挙動を制御するクラスである。Viewクラスは,画面にグラフを表示する機能をもつクラスである。グラフには複数の種類があるので,その種類ごとに,Viewクラスをaしたクラスを作成する。Subjectクラスは,データベースが更新されたことをViewクラスのオブジェクトに通知するクラスである。図1のデータモデル中のテーブルのうち,ダッシュボードで監視したい情報に関するテーブルのそれぞれについて,Subjectクラスをaしたクラスを作成する。以下,Viewクラス,Subjectクラスをaしたクラスのオブジェクトを,それぞれViewオブジェクト,Subjectオブジェクトという。

図の説明テキスト
クラス図。ダッシュボードのクラス設計を示すUMLクラス図です。
【クラスと関係】
・Controller (<
- 属性: -instance, -views[], -subjects[]
- 操作: +getInstance(), +dbUpdated(テーブル名[])
- 関係:
Subjectに対してコンポジション (Controller側 1, Subject側 0..)。Viewに対してコンポジション (Controller側 1, View側 0..)。
・Subject:
- 属性: -views[]
- 操作: +addObserver(View v), +notifyObservers()
- 関係:
Viewに対して集約 (Subject側 1, View側 空欄 b)。 - サブクラス:
販売実績Subject,在庫Subject,販売明細SubjectがSubjectを継承 (継承の線上に空欄 c)。
・View:
- 属性: -集計項目[]
- 操作: +notify(), +set集計項目(集計項目[] d), +画面表示更新() ※画面表示更新()は斜字体(抽象)
- 関係:
集計項目に対して関連 (View側 1, 集計項目側 0..*)。集計処理に依存。 - サブクラス:
棒グラフView,折れ線グラフView,円グラフViewがViewを継承 (継承の線上に空欄 c)。それぞれ+画面表示更新()メソッドを持つ。
・集計項目:
- 属性: -軸の識別子, -テーブル名, -項目名
・集計処理:
- 関係:
DAOクラスに依存。
・DAO:
- 属性・操作の記載なし
【凡例】
四角枠の上段に <<ステレオタイプ>>、クラス名、中段に -属性名、下段に +操作名(引数) を記述。
実線は関連、黒ダイヤはコンポジション、白ダイヤは集約、白抜き三角は継承、破線矢印は依存を示す。数字や「0..*」は多重度を表す。
斜字体は抽象を意味し、下線は静的を意味する。
【注記】
集計項目クラスの属性“軸の識別子”は、グラフの“縦軸”、“横軸”などを一意に示す値である。

図の説明テキスト
| 種類 | グラフの構成要素 | 説明 |
|---|---|---|
| 棒グラフ | 横軸の項目,集計対象の項目,分類 | 横軸の項目について,任意の値の範囲で区切り,集計対象の項目の値を縦棒で表現する。縦棒の値は,分類ごとに色分けし,それらを積み上げて表示する。 |
| 円グラフ | 集計対象の項目,分類 | 集計対象の項目について,分類ごとに集計して,その割合を扇形の面積で表現する。扇形は分類ごとに色分けして表示する。 |
| 折れ線グラフ | 横軸の項目,集計対象の項目,分類 | 横軸の項目について,任意の値の範囲で区切り,集計対象の項目の値の推移を折れ線で表現する。折れ線は分類ごとに分けて表示する。 |

図の説明テキスト
| クラス | 説明 |
|---|---|
| Controller | プログラムの流れを制御するクラス。データベースが更新されたときに,更新されたテーブル名の配列を引数にして,dbUpdated メソッドを呼び出す。 |
| DAO | データベースにアクセスするためのクラス。 |
| Subject | データの更新を View オブジェクトに通知するクラス。通知先は,addObserver メソッドで登録する。notifyObservers メソッドは,登録された全ての通知先の notify メソッドを呼び出す。 |
| View | ダッシュボードに一つのグラフを表示するクラス。グラフの軸や集計対象の項目の情報を,集計項目オブジェクトの配列で保持している。notify メソッドは,画面表示更新メソッドを呼び出す。画面表示更新メソッドは,対象に関する集計を行い,画面の表示を更新する。 |
| 集計処理 | グラフを表示する際に必要になる,各種の集計の処理を実装したクラス。 |
〔グラフの新規表示〕
例えば,“時間帯ごと商品分類ごとの売上金額”のグラフを新たに画面上に表示する場合を考える。グラフの種類は棒グラフなので,棒グラフ View クラスのオブジェクトを作成する。次に,①関係する Subject オブジェクトの addObserver メソッドを呼び出す。その後,画面の初期表示のために,画面表示更新メソッドを呼び出す。
〔グラフの表示内容更新〕
店舗で商品が販売されると,販売管理システムが,データベースにレコードを追加する。そのとき,ダッシュボードの Controller クラスに実装されている dbUpdated メソッドが呼び出されるように,システム間の連携が行われている。
Controller クラスは,dbUpdated メソッドが呼び出されると,更新されたテーブルに対応する Subject オブジェクトの notifyObservers メソッドを呼び出す。notifyObservers メソッドは, そのオブジェクトが属性としてもつ配列 views に格納されている全ての View オブジェクトの notify メソッドを呼び出す。notify メソッドは, 画面表示更新メソッドを呼び出す。View クラスの画面表示更新メソッドは d メソッドなので, 例えば, “時間帯ごと商品分類ごとの売上金額” の場合は e クラスに実装されたメソッドを呼び出す。
〔データのフィルタリング〕
Y社からの追加の要求で, 集計結果をフィルタリングする機能を追加することになった。例えば, “時間帯ごと商品分類ごとの売上金額” のグラフ上で, 特定の商品分類の表示箇所をマウスでクリックしたときに, 表示されている全てのグラフについて, 指定した商品分類で絞り込んだ結果を表示したい。そこで, 絞込条件を取り扱うクラスとして絞込条件クラスを導入し, 次の改修を加えることで機能を実現することにした。
- 絞込条件クラスは, 属性として “テーブル名”, “項目名”, “絞込条件の値” をもつ。例えば, 商品分類で絞り込む場合は, テーブル名に “商品マスタ”, 項目名に “商品分類コード”, 絞込条件の値に “商品分類コードの値” が入る。
- Controller クラスの属性に絞込条件クラスのオブジェクトを追加し, その属性に条件を設定するための setFilter メソッドを追加する。
- View オブジェクトが画面の表示を更新する際に, 絞込条件のオブジェクトが引き渡されるようにするために, Subject クラスの notifyObservers メソッドと, View クラスの notify メソッドのそれぞれについて, 呼出しの②仕様を変更する。
- 集計処理クラスの処理で絞込条件を考慮して集計し, 画面を更新する。
画面の操作が行われたら, View オブジェクトが絞込条件オブジェクトを生成し, Controller オブジェクトの setFilter メソッドを呼び出す。その後, 全ての View オブジェクトの画面表示更新メソッドを呼び出すことで, 機能を実現する。
〔過負荷の回避〕
設計レビューを実施したところ, 次の点が指摘された。
- 販売管理システムが, データベースに販売実績のレコードを連続で追加すると, ダッシュボードが過負荷になるおそれがある。
- 一つの View オブジェクトは f ので,1 回の販売実績の登録で,表示の更新が複数回発生してしまう。
そこで,View クラスの属性に“更新フラグ”を追加し,notify メソッドでは画面表示更新メソッドを呼び出すのではなく,“更新フラグ”を立てるようにした。また,“更新フラグ”を立てる処理とは別に,定期的に画面表示更新メソッドを呼び出す仕組みを用意し,“更新フラグ”が立っている場合だけ画面の更新処理を実行してから“更新フラグ”を降ろすようにした。
設問と解答・解説
設問1
本文中の a に入れる適切な字句を答えよ。
模範解答
継承
採点基準(配点 3点)
正確性(内容)(3点)
- 3点: 「継承」と正確に解答している。
- 1点: 意味的に近いが用語として不正確な記述。
- 0点: 無回答、または全く異なる内容。
解説
デザインパターンを適用する際、既存のクラスを基にして新たなクラスを作成する 継承 が頻繁に用いられます。Observerパターンにおいても、抽象クラスやインタフェースを継承・実装して具体的なSubjectやObserverを作成します。
高得点のポイント
- 継承 という用語を正確に解答している。
設問2
(1)
図 3 中の b について答えよ。
模範解答
0..*
採点基準(配点 2点)
正確性(内容)(2点)
- 2点: 「0..*」と正確に解答している。
- 1点: 意味的に近いが記法に誤りがある。
- 0点: 無回答、または不適切な多重度。
解説
クラス間の関係における多重度についての設問です。Subjectは複数のObserverを保持・管理することが多いため、Subject側から見たObserverの多重度は (0以上)となります。
高得点のポイント
- UMLクラス図の 多重度 表現を正確に理解している。
という記法で正しく解答している。
(2)
図 3 中の c について答えよ。
模範解答
模範解答は公表されていません。下の採点基準と解説から、解答に求められる要素を読み取ってください。
採点基準(配点 2点)
正確性(内容)(2点)
- 2点: 適切な関係性や多重度を正確に解答している。
- 1点: 関連性は読み取れるが、記法に不備がある。
- 0点: 無回答、または不適切な解答。
解説
図中のクラス間の関連を示す問題です。ObserverパターンにおけるSubjectとObserver間の 関連 や、他のクラスとの依存関係について、UMLの表記法に従い正確に多重度や関係性を表現する必要があります。
高得点のポイント
- Observerパターンにおける クラス間の関連 を理解している。
- 適切な多重度や関係名を正確に記述できている。
設問3
本文中の下線①について,関係する Subject オブジェクトのクラス名を図 3 中から選び全て答えよ。
模範解答
販売実績Subject
販売明細Subject
採点基準(配点 3点)
正確性(内容)(3点)
- 3点: 「販売実績Subject」および「販売明細Subject」の両方を正確に選択している。
- 1点: 片方のみを正しく選択している。
- 0点: 無回答、または対象外のクラスを選択している。
解説
下線①の文脈において、監視対象となる(状態の変化を通知する)役割を持つクラスを選択します。ここでは 販売実績Subject および 販売明細Subject が該当します。
高得点のポイント
- Subject としての役割を持つクラスを図から正確に読み取れている。
- 該当するクラスを 全て 選択している。
設問4
(1)
本文中の d について答えよ。
模範解答
抽象
採点基準(配点 2点)
正確性(内容)(2点)
- 2点: 「抽象」と正確に解答している。
- 1点: 意味的に近いが用語として不正確な記述。
- 0点: 無回答、または全く異なる内容。
解説
オブジェクト指向において、共通の性質を抽出して定義することを 抽象(抽象化)と呼びます。UMLクラス図では、抽象クラス名や抽象メソッド名はイタリック体で表記されます。
高得点のポイント
- 抽象 という概念とUMLにおける表記法を正しく理解している。
(2)
本文中の e について答えよ。
模範解答
棒グラフView
採点基準(配点 2点)
正確性(内容)(2点)
- 2点: 「棒グラフView」と正確に解答している。
- 1点: 部分的に合致しているが、クラス名が不正確。
- 0点: 無回答、または全く異なるクラス名。
解説
文脈から、具体的なObserver(View)の一つである 棒グラフView が当てはまります。
高得点のポイント
- 対象となる具体クラスの役割を正しく理解し、図中から適切に判断できている。
設問4のdは,正答率が平均的であった。オブジェクト指向のクラス設計において,抽象化に関する概念は非常に重要なので,関連した語句やUMLの表記法についても,よく理解しておいてほしい。
設問5
本文中の下線②について,仕様変更の内容を 30 字以内で答えよ。
模範解答
引数に絞込条件クラスのオブジェクトを追加する。
採点基準(配点 3点)
知識・理解度(内容)(2点)
- 2点: 「絞込条件クラスのオブジェクト」などの必須要素が過不足なく正確に記述されている。
- 2点: 必須要素の大部分が含まれているが、表現にわずかな揺れがある。
- 1点: 必須要素の一部のみが記述されている。
- 0点: 関連する語句はあるが、仕様変更の内容として不適切。
- 0点: 無回答、または見当違いの記述。
論理性(構造)(1点)
- 1点: 文脈が通っており、「引数に追加する」という構造で正しく説明されている。
- 1点: 文脈は通っているが、やや不自然な言い回しがある。
- 0点: 日本語として破綻している、または意味が通らない。
- 0点: 単語の羅列にとどまっている。
- 0点: 無回答。
解説
仕様変更により、メソッドの呼出し時に新たな条件を渡す必要があります。この際、絞込条件クラスのオブジェクトを引数として渡すように変更します。
高得点のポイント
- 絞込条件クラスのオブジェクト を用いることを明記している。
- 引数に 追加する という動作が正確に記述されている。
- 指定された制限文字数(30字以内)に収められている。
設問5は,正答率が平均的であった。クラス間の関連の構造を変更するなど,メソッドの呼出しに関する仕様変更に留まらない解答が散見された。設問をよく読み,求められていることを理解した上で解答してほしい。
設問6
本文中の f に入れる適切な字句を,30 字以内で答えよ。
模範解答
複数のSubjectオブジェクトに登録される
採点基準(配点 3点)
知識・理解度(内容)(2点)
- 2点: 「複数のSubjectオブジェクト」に関連付けられる旨が過不足なく正確に記述されている。
- 2点: 必須要素は含まれているが、表現にわずかな揺れがある。
- 1点: Subjectオブジェクトに関する言及はあるが、複数の関連付けについて不明確である。
- 0点: 関連する語句はあるが、内容が不適切。
- 0点: 無回答、または見当違いの記述。
論理性(構造)(1点)
- 1点: 文脈が通っており、Observerが登録されるという構造で正しく説明されている。
- 1点: 文脈は通っているが、やや不自然な言い回しがある。
- 0点: 日本語として破綻している、または意味が通らない。
- 0点: 単語の羅列にとどまっている。
- 0点: 無回答。
解説
Observer(ここではダッシュボードのViewなど)が、一つだけでなく複数の状態監視対象(Subject)に依存・登録される場合の挙動について記述します。
高得点のポイント
- 複数のSubjectオブジェクト というキーワードが含まれている。
- それらに 登録される (あるいは関連付けられる)ことが記述されている。
- 指定された制限文字数(30字以内)に収められている。
設問6は,正答率が低かった。クラスからオブジェクトを作成して利用する際の,オブジェクト同士の関係や,関連したオブジェクト間におけるメソッドの呼出しの流れについて,具体的にイメージする能力を身につけてほしい。