応用情報技術者過去問題 令和3年秋期 午後問8

⇄問題文と設問を画面2分割で開く⇱問題PDF

問8 情報システム開発

データ中心設計に関する次の記述を読んで,設問1~4に答えよ。

 X社は,30店舗をもつスーパーマーケットチェーンである。X社の店舗は,地域の顧客ニーズに合わせた商品選定,販売戦略によって,売上げを伸ばしている。
 X社では,Webサイトで購入した商品を自宅に配送するサービス(以下,ネットスーパーという)を3年前から開始している。近年,他社も同様のサービスを開始し,競争が加熱している。
 X社のネットスーパーを支える情報システム(以下,現行システムという)は,システム機能の追加や変更(以下,機能変更という)が多く,ソフトウェアが肥大化,複雑化している。そこで,X社では,顧客や店舗スタッフからの機能変更の要求に迅速に対応することを目的に,新しいネットスーパーシステム(以下,新システムという)を構築することにした。新システムの開発は,システム部門のY君が担当することになった。

〔システム設計方法の調査〕
 Y君は,機能変更を繰り返しても,ソフトウェアの構造が複雑になりにくく,変更容易性の高いシステムが構築可能なデータ中心設計について調査した。
 X社がこれまで採用してきたa中心設計は,データの設計に先行して機能を設計し,機能に合わせて必要なデータを設計する手法である。この手法を用いると,業務要件が変わると機能もデータも変更が必要となる。
 一方で,データ中心設計は,データの構造は機能と比較して変わりにくいという点に注目し,機能の設計に先行してデータの設計を行う手法である。データを中心に設計することで,機能変更時にもデータの変更を少なくできる。

〔現行システム機能の調査〕
 Y君は,現行システムの三つの機能と機能変更の頻度について調査した。
  • 顧客管理機能
    顧客情報を登録,更新するための機能。顧客には,顧客種別として,個人顧客と法人顧客があり,個人顧客には一般個人顧客とX社電子マネーをもつ会員個人顧客がある。この機能は,過去3年間に顧客種別の追加に関する機能変更が1回だけあった。
  • 商品表示機能
    顧客へ商品を表示する機能。商品には,商品種別として,通常商品のほか,通常商品を束ねたセット商品,特売商品,タイムセール商品,事前に予約することによって通常商品を割引価格で購入できる事前予約商品,及び顧客の購入履歴から算出したお勧め商品がある。商品種別ごとに画面の表示方法が異なる。この機能は,顧客にX社のネットスーパーを選択してもらうための重要な機能であり,商品種別の追加に関する機能変更が多い。
  • 購入機能
    顧客が商品を購入し,料金を支払う機能。料金支払には,X社電子マネー,クレジットカード,銀行振込,3種類の他社の電子マネーが利用できる。この機能への機能変更は多くない。
〔概念データモデルの設計〕
 Y君は,現行システム機能の調査及び現行システムの関係者に対するヒアリングを行い,新システムが管理するデータの概念データモデルを設計した。図1にY君が設計した概念データモデル(抜粋)を示す。
pm08_1.png/image-size:545×179
 この概念データモデルのうち,通常商品と事前予約商品はc関係,通常商品とお勧め商品はd関係である。

〔顧客管理機能の設計〕
 Y君は,顧客管理機能については,システム性能に重点を置きつつ,顧客管理機能への変更が他機能に与える影響を小さくする設計とした。図2にY君が設計した顧客管理機能の論理テーブルとソフトウェアのクラス図(抜粋)を示す。
pm08_2.png/image-size:549×323
 Y君は,顧客管理機能の論理テーブルとして,①顧客種別,顧客,個人顧客,法人顧客の四つのテーブルを設計した。また,ソフトウェアの設計として,②ソフトウェアの肥大化を防止するために顧客クラスを定義し,顧客クラスを継承するクラスとして一般個人顧客,会員個人顧客,法人顧客の三つのクラスを設計した。

〔商品表示機能の設計〕
 Y君は,商品表示機能は機能変更の頻度が高いことを考慮し,システム性能よりも変更容易性に重点をおいた設計とした。図3にY君が設計した商品表示機能の論理テーブルとソフトウェアのクラス図(抜粋)を示す。
pm08_3.png/image-size:549×356
 Y君は,商品表示機能の論理テーブルとして,③特売商品テーブル,セット商品テーブルなど商品種別ごとに多数のテーブルを作成するのではなく,商品種別と商品の二つのテーブルを作成し,運用環境へのリリース時の作業量を低減する設計とした。また,ソフトウェア設計としては商品クラスを定義するとともに,④商品種別ごとに個別のクラスを設計した。
 その後Y君は,新システムの設計及び構築を完了させ,X社は新システムを用いたネットスーパーのサービスを開始した。

設問1

本文中のaに入れる,データ中心設計と対比される適切な字句を答えよ。

解答入力欄

  • a:

解答例・解答の要点

  • a:プロセス

解説

aについて〕
空欄aの設計手法は「データの設計に先行して機能を設計し,機能に合わせて必要なデータを設計する手法」と説明されています。システムやソフトウェアを作成する際に、業務手順や機能に着目して分析・設計する手法を「プロセス中心設計」といいます。プロセス中心設計は"業務"→"データ"の順でモデリングするため、業務手順に合わせたデータ構造を作成できる利点があり、特定の業務を短期間でシステム化するには有効ですが、システムが業務手順に依存しているため業務手順の変更によるシステムへの影響が大きいというデメリットがあります。
データ中心設計
データこそが業務の内容が変化しても変わらない最も安定した共有資源であることに着目し、データを中心に分析・設計する
プロセス中心設計
業務プロセスの流れをそのままプログラム言語で記述することを考え、業務手順や機能を中心に分析・設計する
a=プロセス

設問2

〔概念データモデルの設計〕について,(1)~(3)に答えよ。
  • 図1中のbに入れる適切な字句を〔現行システム機能の調査〕内の字句を使って答えよ。
  • 図1中の通常商品を始点とし通常商品を終点とする1対多の関連は何を意味するか〔現行システム機能の調査〕内の字句を使って答えよ。
  • 本文中のcdに入れる適切な字句を,解答群の中から選び,記号で答えよ。
c,d に関する解答群
  • 共存
  • 排他
  • 包含

解答入力欄

    • b:
    • c:
    • d:

解答例・解答の要点

    • b:購入
    • セット商品
    • c:
    • d:
  • 解説

    • bについて〕
      図1を見ると、顧客管理機能に対応する顧客エンティティ、商品表示機能に対応する商品エンティティがそれぞれトップレベルに存在します。空欄bは顧客エンティティ及び商品エンティティと関連を持ち、下位レベルには支払等のエンティティがあることから、〔現行システム機能の調査〕(3)の購入機能に対応するエンティティであるとわかります。顧客管理機能⇒顧客エンティティ、商品表示機能⇒商品エンティティですから、購入機能のトップレベルのエンティティ名として適切なのは「購入」であると考えられます。したがって空欄bには「購入」が当てはまります。

      b=購入

    • 図1を見ると、通常商品エンティティには自己を参照する1対多のリレーションシップが記述されています。つまり、1つの通常商品が複数の通常商品に関連付けられる場合があるということです。

      〔現行システム機能の調査〕(2)を読むと、商品種別として「通常商品を束ねたセット商品」があることがわかりますが、図1中にはエンティティとして表現されていません。1つのセット商品は複数の通常商品と関連を持つことを考えると、この自己参照は「セット商品」を意味するものであると判断できます。

      ∴セット商品

    • スーパータイプ(汎化側のエンティティ)とサブタイプ(特化側のエンティティ)間の関係には、解答群にあるように共存、排他、包含の3つがあります。
      共存
      取引先は販売先かつ仕入先になることができる場合のように、一方のサブタイプに属していても、他方のサブタイプに属することができる関係。スーパータイプにフラグ属性を持たせてサブタイプを識別する。
      pm08_4.png/image-size:416×105
      排他
      取引先は販売先または仕入先のいずれかである場合のように、一方のサブタイプに属する場合、他方のサブタイプに属することができない関係。スーパータイプに区分属性を持たせてサブタイプを識別する。
      pm08_5.png/image-size:416×105
      包含
      取引先の一部を得意先としている場合のように、スーパータイプに対し、サブタイプが1つしかない関係。サブタイプはスーパータイプの部分集合となる。
      pm08_6.png/image-size:319×105
      cについて〕
      事前予約商品は「事前に予約することによって通常商品を割引価格で購入できる」商品です。通常商品と事前予約商品は1対1で結ばれており、通常商品の一部が事前予約商品であるという関係になります。したがって空欄cには「包含」が当てはまります。

      c=ウ:包含

      dについて〕
      サブタイプ同士の関係なので「共存」または「排他」が入ります。通常商品がお勧め商品になることは当然にあるので、両方のサブタイプに属することができる関係です。したがって空欄dには「共存」が当てはまります。

      d=ア:共存

    設問3

    〔顧客管理機能の設計〕について,(1),(2)に答えよ。
    • 本文中の下線①について,一般個人顧客と会員個人顧客を二つのテーブルに分けるのではなく個人顧客というテーブルとした理由として,ふさわしくないものを解答群の中から選び,記号で答えよ。
    • 本文中の下線②について,顧客クラスを定義することでソフトウェアの肥大化が防止できるのはなぜか,30字以内で述べよ。
    解答群
    • 一般個人顧客と会員個人顧客で属性に大きな差がないから
    • 顧客種別には,多くの変更が入らないことが予想されるから
    • テーブルへの列追加時に顧客管理機能のソフトウェアの影響調査の範囲が小さくなるから
    • 販売実績の集計などを行う場合に,二つのテーブルではテーブル結合が多くなり,データベースサーバの負荷が大きいから

    解答入力欄

    解答例・解答の要点

    • 顧客種別によらない共通な処理を一か所で定義できるから (26文字)
  • 解説

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

    • 一般個人顧客・会員個人顧客・法人顧客は共通の属性を持っており、同じような処理が必要となります。各処理をそれぞれのクラスに用意することもできますが、同じ処理を繰り返し書くことになるため、ソースコードが無駄に長くなります。どの顧客も共通して使う顧客クラスをスーパークラスとして定義すれば、その中で全顧客に共通の処理を一か所に定義することができます。顧客種別ごとのサブクラスでは差分だけを記述すれば済むので、重複するソースコードがなくなりソフトウェアの肥大化を防ぐことができます。

      ∴顧客種別によらない共通な処理を一か所で定義できるから

    設問4

    〔商品表示機能の設計〕について,(1),(2)に答えよ。
    • 本文中の下線③の設計とすることで,商品種別を追加した際に,運用環境へのリリース時にどのような作業を低減できるか,20字以内で述べよ。
    • 本文中の下線④について,Y君が商品種別ごとにクラスを定義した理由を,商品表示機能の特徴の観点から20字以内で述べよ。

    解答入力欄

    解答例・解答の要点

    • データベースへのテーブル追加作業 (16文字)
    • 画面の表示方法が異なるから (13文字)
  • 解説

    • 図3のテーブル設計では、商品種別と商品の2つのテーブルであらゆる商品種別のデータを格納できるようになっています。この設計だと、商品種別の追加の際に商品種別テーブルと商品テーブルへのデータ追加のみで対応することができます。つまり、商品種別ごとに多数のテーブルを作成するのと比較して、商品種別を追加する度に新しいテーブルの追加を行う必要がなくなります。これによりリリース作業に伴うリスクが軽減されます。

      ∴データベースへのテーブル追加作業

    • 基本的に似ているものは共通化し、違いが大きいものは分けると考えます。分ける理由を探すので、商品種別ごとの違いを探します。本文中の〔現行システム機能の調査〕で商品表示機能の特徴を確認すると、以下の記述があります。
      • 商品種別ごとに画面の表示方法が異なる
      • 商品種別の追加に関する機能変更が多い
      このため、画面の表示方法に関して必要なメソッドや処理の内容は商品種別ごとに大きく異なると考えられます。共通化できる範囲が少なく個別の処理が多い場合は、それぞれのクラスで処理を実装します。無理やり共通化すると、条件分岐が多く複雑なコードになるおそれがあるので、変更容易性の重視という設計方針から好ましくありません。

      ∴画面の表示方法が異なるから
    問8成績

    令和3年秋期 午後問題一覧

    問1 問2 問3 問4 問5 問6 問7 問8 問9 問10 問11 採点講評
    © 2010-2024 応用情報技術者試験ドットコム All Rights Reserved.

    Pagetop