解説

データ中心設計

データこそが業務の内容が変化しても変わらない最も安定した共有資源であることに着目し、データを中心に分析・設計する

プロセス中心設計

業務プロセスの流れをそのままプログラム言語で記述することを考え、業務手順や機能を中心に分析・設計する

解説

• 〔bについて〕
  図1を見ると、顧客管理機能に対応する顧客エンティティ、商品表示機能に対応する商品エンティティがそれぞれトップレベルに存在します。空欄bは顧客エンティティ及び商品エンティティと関連を持ち、下位レベルには支払等のエンティティがあることから、〔現行システム機能の調査〕(3)の購入機能に対応するエンティティであるとわかります。顧客管理機能⇒顧客エンティティ、商品表示機能⇒商品エンティティですから、購入機能のトップレベルのエンティティ名として適切なのは「購入」であると考えられます。したがって空欄bには「購入」が当てはまります。
  
  ∴b＝購入
  
  
• 図1を見ると、通常商品エンティティには自己を参照する1対多のリレーションシップが記述されています。つまり、1つの通常商品が複数の通常商品に関連付けられる場合があるということです。
  
  〔現行システム機能の調査〕(2)を読むと、商品種別として「通常商品を束ねたセット商品」があることがわかりますが、図1中にはエンティティとして表現されていません。1つのセット商品は複数の通常商品と関連を持つことを考えると、この自己参照は「セット商品」を意味するものであると判断できます。
  
  ∴セット商品
  
  
• スーパータイプ（汎化側のエンティティ）とサブタイプ（特化側のエンティティ）間の関係には、解答群にあるように共存、排他、包含の3つがあります。

  共存

  取引先は販売先かつ仕入先になることができる場合のように、一方のサブタイプに属していても、他方のサブタイプに属することができる関係。スーパータイプにフラグ属性を持たせてサブタイプを識別する。

  

  排他

  取引先は販売先または仕入先のいずれかである場合のように、一方のサブタイプに属する場合、他方のサブタイプに属することができない関係。スーパータイプに区分属性を持たせてサブタイプを識別する。

  

  包含

  取引先の一部を得意先としている場合のように、スーパータイプに対し、サブタイプが1つしかない関係。サブタイプはスーパータイプの部分集合となる。

  

  〔cについて〕
  事前予約商品は「事前に予約することによって通常商品を割引価格で購入できる」商品です。通常商品と事前予約商品は1対1で結ばれており、通常商品の一部が事前予約商品であるという関係になります。したがって空欄cには「包含」が当てはまります。
  
  ∴c＝ウ：包含
  
  〔dについて〕
  サブタイプ同士の関係なので「共存」または「排他」が入ります。通常商品がお勧め商品になることは当然にあるので、両方のサブタイプに属することができる関係です。したがって空欄dには「共存」が当てはまります。
  
  ∴d＝ア：共存

解説

• 解答群の記述をそれぞれ検討していきます。
  • 一般個人顧客と会員個人顧客の違いは、"X社電子マネー番号"の有無のみです。ほぼ同じ属性なので1つのテーブルで管理することができます。逆に個人顧客と法人顧客のように属性が大きく異なる場合には別テーブルに分ける方が良いです。したがって、本肢は理由としてふさわしいと言えます。
  • テーブルが1つだと、顧客種別の変更があった際に、個人顧客テーブルに（X社電子マネー番号のような）顧客種別ごとの固有の属性を追加したり削除したりする作業が必要となります。列の追加や削除をするとそのテーブルに関連する全てのクラスが影響を受けるので、顧客種別の変更が頻繁にある場合にはテーブルを分けた方が良いと考えられます。しかし、顧客種別に関する機能変更は過去3年に1回しかなかったと説明されています。顧客管理機能はシステム性能重視の設計なので、システム性能と変更容易性を天秤にかけて3年に1度程度の変更であれば許容できると判断したと考えられます。したがって、本肢は理由としてふさわしいと言えます。
  • 正しい。顧客管理機能のソフトウェアは、一般個人顧客と会員個人顧客を別のクラスで管理しています。テーブルが2つに分かれていれば列を追加したテーブルに対応するクラスを修正するだけで済みますが、テーブルが1つだと列追加時に常に2つのクラスの修正が必要です。したがって、ソフトウェアの影響調査の範囲は1つのテーブルにした方が大きくなります。よって、本肢の理由はふさわしくありません。
  • 2つのテーブルに分けると、個人顧客の情報を参照する度に2つのテーブルを結合させることになります。これだと処理が複雑になる分、データベースサーバへの負荷が大きくなってしまいます。顧客管理機能は、〔顧客管理機能の設計〕にあるように「システム性能に重点」を置いた設計なので、データベースサーバへの負荷を減らすために1つのテーブルとしたと考えられます。したがって、本肢は理由としてふさわしいと言えます。
  ∴ウ：テーブルへの列追加時に顧客管理機能のソフトウェアの影響調査の範囲が小さくなるから
  
  
• 一般個人顧客・会員個人顧客・法人顧客は共通の属性を持っており、同じような処理が必要となります。各処理をそれぞれのクラスに用意することもできますが、同じ処理を繰り返し書くことになるため、ソースコードが無駄に長くなります。どの顧客も共通して使う顧客クラスをスーパークラスとして定義すれば、その中で全顧客に共通の処理を一か所に定義することができます。顧客種別ごとのサブクラスでは差分だけを記述すれば済むので、重複するソースコードがなくなりソフトウェアの肥大化を防ぐことができます。
  
  ∴顧客種別によらない共通な処理を一か所で定義できるから

解説

• 図3のテーブル設計では、商品種別と商品の2つのテーブルであらゆる商品種別のデータを格納できるようになっています。この設計だと、商品種別の追加の際に商品種別テーブルと商品テーブルへのデータ追加のみで対応することができます。つまり、商品種別ごとに多数のテーブルを作成するのと比較して、商品種別を追加する度に新しいテーブルの追加を行う必要がなくなります。これによりリリース作業に伴うリスクが軽減されます。
  
  ∴データベースへのテーブル追加作業
  
  
• 基本的に似ているものは共通化し、違いが大きいものは分けると考えます。分ける理由を探すので、商品種別ごとの違いを探します。本文中の〔現行システム機能の調査〕で商品表示機能の特徴を確認すると、以下の記述があります。
  • 商品種別ごとに画面の表示方法が異なる
  • 商品種別の追加に関する機能変更が多い
  このため、画面の表示方法に関して必要なメソッドや処理の内容は商品種別ごとに大きく異なると考えられます。共通化できる範囲が少なく個別の処理が多い場合は、それぞれのクラスで処理を実装します。無理やり共通化すると、条件分岐が多く複雑なコードになるおそれがあるので、変更容易性の重視という設計方針から好ましくありません。
  
  ∴画面の表示方法が異なるから