応用情報技術者 2024年 春期 午後 問08

解答の論理構成

1. 問題文では「グラフには複数の種類があるので、その種類ごとに、Viewクラスをaしたクラスを作成する」と述べています。ここで**「複数種類のグラフ」**という要件をクラス図で実装する一般的な方法は、共通部分を基底クラスにまとめ、個別の振る舞いを派生クラスで実装することです。
2. 同じ段落で「図1のデータモデル中のテーブルのうち、ダッシュボードで監視したい情報に関するテーブルのそれぞれについて、Subjectクラスをaしたクラスを作成する」とも指示しています。つまり**「テーブル数だけ Subject の派生クラスを用意する」**という方針です。
3. 以上2か所とも「基底クラスの設計を土台に派生クラスを作る」という文脈で使われているため、a には「継承」を入れるのが自然な流れです。
4. 図3 のクラス図でも、Subject から 販売実績Subject, 在庫Subject, 販売明細Subject へ、さらに View から 棒グラフView, 折れ線グラフView, 円グラフView へと「→」で接続され、その凡例に「継承（c）」と記されています。ここでも継承関係であることが補強されています。

誤りやすいポイント

• 「実装」や「拡張」と回答してしまう
  → 派生クラスを作る目的は機能追加ではなく型階層を構成することなので適切でありません。
• 集約（HAS-A）と継承（IS-A）の混同
  → Subject が View を配列で保持する部分は集約ですが、ここで問われているのは型の派生です。
• デザインパターン名（Observer 等）を書いてしまう
  → 問題は字句を問うており、パターン名は解答になりません。

FAQ

解答の論理構成

1. Subject―View 間の多重度 b
   • 【問題文】には「Subjectクラスは、データの更新をViewオブジェクトに通知するクラス。通知先は、addObserverメソッドで登録する。notifyObserversメソッドは、登録された全ての通知先のnotifyメソッドを呼び出す。」とあります。
   • 「登録された全ての通知先」という表現は、Subject 1つに対して View が複数存在し得ることを示します。さらに、View が未登録の状態（０件）も成立するため、View 側の多重度は “０個以上” が適切です。
   • よって b には「0..*」が入ります。
2. c に入るクラス間関係（矢印種別）
   • 【問題文】には「図1のデータモデル中のテーブルのうち、ダッシュボードで監視したい情報に関するテーブルのそれぞれについて、Subjectクラスをaしたクラスを作成する。」と記載されています。また、View についても「グラフには複数の種類があるので、その種類ごとに、Viewクラスをaしたクラスを作成する。」とあります。
   • これは基底クラス（Subject／View）を継承して派生クラス（販売実績Subject など、棒グラフView など）を作るという意味です。UML では汎化（generalization）を “白抜き三角形の矢印” で表現します。
   • 図3の凡例でも「→ 継承（c）」と矢印を示しており、c には汎化を示す矢印が入ると分かります。
   • 模範解答の「⇧」は、UML 汎化矢印（白三角）の簡易表記ですので、c は継承（汎化）を示す矢印「⇧」となります。

誤りやすいポイント

• 「Subject から View へ1対1」と誤読する
  addObserver で配列登録しているため 1:1 ではありません。
• View―Subject を双方向関連と早合点する
  本設計では View は Subject を知らず、Subject 側だけが View 配列を保持します。
• 汎化（継承）と依存を混同する
  DAO ←→ 集計処理 は依存、Subject／View の派生は汎化です。

FAQ

解答の論理構成

1. 対象グラフが示すデータを確認
   • 問題文より引用：「“時間帯ごと商品分類ごとの売上金額”のグラフ」
   • 必要な情報は
     ① 時間帯（販売日時）
     ② 商品分類ごとの売上金額
2. 時間帯（販売日時）を保持するテーブルを特定
   • 図3の Subject 継承ツリーに「販売実績Subject」がある。
   • 販売日時を管理するテーブルは“販売実績”であるため、該当する Subject は「販売実績Subject」。
3. 商品分類ごとの売上金額を算出するために必要な明細データを特定
   • 商品別・数量別の売上は明細レベルで保持される。図3には「販売明細Subject」が定義されている。
   • よって、商品分類ごとの集計には「販売明細Subject」も関係する。
4. 在庫Subject など他の Subject が関係しない理由
   • 在庫Subject は在庫数の更新に関係し、売上金額・販売日時とは直接関係しない。
5. 以上より、①で addObserver を呼び出す「関係する Subject オブジェクト」は
   • 「販売実績Subject」
   • 「販売明細Subject」

誤りやすいポイント

• 「商品分類」の文字を見て在庫管理を連想し、「在庫Subject」を含めてしまう。
• 集計は商品分類単位だが、商品分類のマスタは Subject 化されていない点を見落とす。
• 「販売実績Subject」だけで売上金額が取れると考え、明細が必要なことを忘れる。

FAQ

解答の論理構成

1. View クラスの 画面表示更新 の性質
   • 【問題文】には「View クラスの画面表示更新メソッドはdメソッドなので…」とあります。
   • また図3のクラス図では、View にイタリック（斜体）指定はありませんが、画面表示更新( ) は下位クラスごとに再定義されていることが示唆されています。
   • さらに「グラフには複数の種類があるので、その種類ごとに、Viewクラスをaしたクラスを作成する。」とあるように、View は共通インタフェースのみを持ち、処理本体は派生クラス側で具体化します。
   • したがって dメソッド に入るのは実装を持たない「抽象」であると論理的に導けます。
     ➡ d：抽象
2. どの派生クラスのメソッドか
   • 同じ文には「例えば、“時間帯ごと商品分類ごとの売上金額”の場合はeクラスに実装されたメソッドを呼び出す。」とあります。
   • 同じ段落冒頭の〔グラフの新規表示〕では「グラフの種類は棒グラフなので、棒グラフ View クラスのオブジェクトを作成する。」と明記されています。
   • よって 画面表示更新 を具体的に実装しているのは 棒グラフView クラスです。
     ➡ e：棒グラフView

誤りやすいポイント

• 「抽象→具体」の流れを見落として View 自体に処理を書くと誤答になりやすいです。
• 図3に斜体表記が無いことから「抽象」と結び付けにくく、protected や virtual などキーワードを連想してしまうミスが起きやすいです。
• e は「グラフの種類＝クラス名」であることを忘れ、View や Controller と書いてしまうケースも散見されます。

FAQ

解答の論理構成

• 【問題文】には次の記載があります。
  「View オブジェクトが画面の表示を更新する際に、絞込条件のオブジェクトが引き渡されるようにするために、Subject クラスの notifyObservers メソッドと、Viewクラスの notify メソッドのそれぞれについて、呼出しの②仕様を変更する。」
  ここで“絞込条件のオブジェクト”とは、同段落冒頭で導入された「絞込条件クラス」のインスタンスです。
• 変更の目的は「絞込条件のオブジェクトを View 側へ渡す」ことです。渡す手段として最も自然なのは、両メソッドに“引数”として追加することです。
• したがって、“②仕様変更”の内容は「引数に絞込条件クラスのオブジェクトを追加する」となります。

誤りやすいポイント

• 「絞込条件をクラス変数に保持する」と誤解し、引数追加ではなく“共有属性化”と答えてしまう。
• notifyObservers だけ、あるいは notify だけに引数を足すと思い込み、両方を対象にしない。
• “絞込条件”という言葉を省き「条件を渡す」とだけ書き、具体性が足りず減点される。

FAQ

解答の論理構成

• 【問題文】では、「Controller クラスは、dbUpdated メソッドが呼び出されると、更新されたテーブルに対応する Subject オブジェクトの notifyObservers メソッドを呼び出す。」とあります。
• 各 Subject オブジェクトは「views 配列に格納されている全ての View オブジェクトの notify メソッドを呼び出す」ため、同じ View オブジェクトが複数の Subject に登録されていると、その数だけ notify が連続して発生します。
• その状況を説明する文が「一つの View オブジェクトはfで、1回の販売実績の登録で、表示の更新が複数回発生してしまう。」です。
• 問題となっている原因は「同一 View が Subject ごとに重複登録される」ことなので、f に入るべき語句は「複数のSubjectオブジェクトに登録される」となります。

誤りやすいポイント

• 「View が多重度 0..* で Subject に集約されている＝View が Subject を複数持つ」と勘違いしやすいですが、実際は Subject が View を保持します。
• 「販売実績の登録 ➔ 販売実績Subject だけが通知」と早合点し、在庫や販売明細Subject も同時に動くケースを見落としがちです。
• 更新が複数回発生する理由を「DAO へのアクセス回数」や「画面描画ループ」に求めてしまい、Observer 内の重複通知だと気付かないことがあります。

FAQ