システムアーキテクト試験 2009年 午後1 問01

模範解答

解説

解答の論理構成

1. 売上プロセスの役割を確認
   問題文（2）②に「自販機コードと、コラムごとに…売上数のデータを取得する」とあり、ここで当日の「売上数」が確定します。
2. 補充プロセスの入力を確認
   同（2）③には「売上処理で取得した売上数を基にコラムごとの最適補充数を計算する」と記載されています。
3. データ依存関係の導出
   補充プロセスは売上数という計算済みデータを前提に動くため、売上プロセスより前に置くと必要データが存在しません。
4. 結論
   したがって「補充プロセスは売上プロセスの後」となる理由は「補充で売上数を参照する」ことに尽きます。

誤りやすいポイント

• 「在庫数更新が後だから」という表面的理由だけを書くと、売上数依存を示せず減点対象。
• プロセスの並列実行可否を論じてしまい、本質のデータ依存関係を外す。
• 補充プロセスが売上数を“更新”すると誤解し、順序を逆転させてしまう。

FAQ

模範解答

解説

解答の論理構成

1. 売上処理の流れ
   • 【問題文】「自販機に到着後、HTと自販機を通させ、自販機コードと、コラムごとに…売上数のデータを取得する。」
   • 同段落で「売上金額を計算し、取得及び計算したデータをHTに保存する。」
     すなわち、巡回時点の売上数を読み取り計算します。
2. 補充処理の最後の操作
   • 【問題文】「さらに、自販機内のコラムごとの売上数をゼロにする。」
     ここでカウンタを初期化している事実が明記されています。
3. 初期化の必要性
   • 次の巡回では再び「売上数」を読み取り計算するため、前回分を残しておくと「累積」され実際の当日売上を超えてしまいます。
   • 逆にゼロにしておけば、次回は当該巡回以降の純粋な増分だけが取得できます。
4. よって「累積防止」がゼロクリアの直接目的となります。

誤りやすいポイント

• 「在庫数の初期化」と取り違え、売上数でなく在庫補充後の在庫リセットと誤解する。
• 「売上金額」までゼロにすると解釈し、会計データ消失と混同する。
• 「翌日の締め処理で自動的にクリアされる」と思い込み、HT側のリアルタイム処理を軽視する。

FAQ

模範解答

解説

解答の論理構成

1. 業務と既存プロセスの突き合わせ
   • 売上処理→P1、補充処理→P2、積込積降処理→P3 まで図に存在。
   • 【問題文】「④トラック棚卸処理」が図に見当たらず、これが追加対象。
2. 入力データの特定
   • 【問題文】「棚卸しでは、トラックコード、商品コード及び実地棚卸数をHTに入力する。」
   • よって外部エンティティ「営業担当者」からプロセスへ上記 3 項目を流す。
3. 更新・登録対象の洗い出し
   • 同じ段落に「トラック在庫マスタの在庫数を実地棚卸数で更新」とある。
   • 表1 に「トラック棚卸」「トラック棚卸明細」があり、棚卸結果を保持するファイルであることが分かる。
4. データフローの作成
   • プロセス「トラック棚卸」から
     • トラック在庫マスタへ更新フロー
     • トラック棚卸明細へ登録フロー
     を引く。
   • これでデータフローは合計 3 本となり、設問条件を充足。
5. 属性ラベル
   • ラベルには表1の正式名称を引用する。
     例：「トラックコード」「商品コード」「実地棚卸数」など。

誤りやすいポイント

• 「トラック棚卸」をデータストア名と混同し、プロセスを描かない。
• 属性名を省略／別表記にする（例：「棚卸数」と短縮）→減点対象。
• マスタ更新と明細登録を一本のフローにまとめてしまい、データフローが 2 本しか無い。
• 外部エンティティを「HT」としてしまう。入力者は【問題文】で明示された「営業担当者」です。

FAQ

模範解答

解説

解答の論理構成

1. 倉庫在庫確定処理の目的
   「倉庫在庫マスタ」を当日分で確定させるバッチ処理であり、入力は “当日 HT からアップロードされたデータ” と明示されています。
2. 当日 HT からアップロードされるファイル
   • 巡回終了後に行う「⑥アップロード処理」でサーバへ送信されるファイルは、「積込積降」と「積込積降明細」であると【問題文】が示しています。
3. サーバ専用ファイルは対象外
   「入出庫明細」や「倉庫在庫マスタ」そのものはサーバに常駐し、アップロード対象ではないため入力ファイルには該当しません。
4. よって入力ファイルは
   「積込積降, 積込積降明細」となります。

誤りやすいポイント

• 「入出庫明細」や「入出庫」と混同してしまう
  → 自動倉庫間移動や返品時に使うサーバ側の伝票であり、HT アップロードの対象外です。
• 「トラック棚卸明細」もアップロードされると勘違い
  → 棚卸はトラック在庫を更新するための処理で、倉庫在庫には直接関与しません。
• ファイル名の入力漏れ
  → 「積込積降」と「積込積降明細」はセットで扱われるため両方を書きます。

FAQ

模範解答

解説

解答の論理構成

1. 営業担当者は「⑤積込積降処理」で「倉庫コード、トラックコード、商品コード及び積込数」をHTに入力し、トラック⇔倉庫間の在庫移動を登録します。
2. 登録内容は「⑥アップロード処理」でサーバへ送られ、「積込積降明細」などのレコードが更新されます。
3. しかし倉庫在庫そのものは直ちには変わらず、夜間に「⑤倉庫在庫確定処理」で「HTから当日アップロードされたデータ」を用いて「倉庫在庫マスタ」を更新すると問題文に記載されています。
4. したがって、積込・積降登録分を倉庫在庫に正確に反映する目的で倉庫在庫確定処理が必須となります。

誤りやすいポイント

• 積込積降入力時点で倉庫在庫が即時更新されると誤解する。
• 「トラック棚卸処理」が倉庫在庫を動かすと混同する。
• 夜間バッチ処理の役割（アップロードデータをまとめて反映）を見落とす。

FAQ

模範解答

解説

解答の論理構成

1. 状況変化の把握
   • 【問題文】「現在、1日のうちに複数の営業担当者が同一自販機を巡回することはない。しかし、今後は巡回する可能性があり」とある。
   • つまり同一自販機に対して複数 HT から売上・補充データが送られる前提に変わる。
2. 既存方式の問題点
   • 「サーバのコラムマスタの在庫数を…HT内に保存されている値で更新する」とある。
   • 単純上書きでは、後にアップロードした HT が先の HT の在庫計算を潰してしまう。
3. 必要となる対策
   • 各 HT が送る「売上数」「補充数」を合算し、「コラムごとの在庫数」を再計算すれば整合性が保たれる。
   • これが「サーバで計算し直す理由」であり、模範解答の「在庫数は巡回したすべてのHT 内の売上と補充の情報から計算する必要があるから」に一致する。

誤りやすいポイント

• 「ロット番号追加」や「賞味期限一覧」と混同し、理由に賞味期限を絡めてしまう。
• 「複数自販機」ではなく「複数 HT」が問題である点を見落とす。
• 「上書き防止」ではなく「レスポンス向上」など枝葉の利点を挙げてしまう。

FAQ

模範解答

解説

解答の論理構成

1. 目的確認
   問題文に「サーバのコラムマスタの在庫数を、HT 内のコラムマスタのアップロード時に HT 内に保存されている値で更新するのではなく、サーバで計算し直す」とあります。つまりサーバは“変化量”を受け取り、現在高を自力で再構築します。
2. 変化量を含む HT ファイルを列挙
   表1 より、売上を保持するのは「売上補充明細」（属性：売上金額, 売上数, 補充数）。そのヘッダ情報をまとめるのが「売上補充」（属性：売上日, 自販機コード, 回収金額）。
3. 他候補との比較
   • 「トラック在庫マスタ」はトラック全体の在庫数であり、自販機内在庫とは直接関係しません。
   • 「トラック棚卸明細」「積込積降明細」はトラックと倉庫の移動に関するデータであり、コラム在庫計算には不要です。
4. 結論
   在庫数を算出する最小限の HT ファイルは「売上補充」と「売上補充明細」の二つになります。

誤りやすいポイント

• トラック関連ファイルを選択してしまう
  自販機コラム在庫の更新対象はあくまで自販機内の売上と補充。トラックの在庫増減は計算に直接使いません。
• ファイルの所在を見落とす
  表1 の注にある「無印はサーバ及び HT 上に存在」を読み飛ばすと、アップロード対象を取り違える危険があります。
• 「売上補充明細」だけを選んでしまう
  明細行だけでは日付・自販機コードが欠けるため、サーバ側で正しく在庫をひも付けできません。ヘッダ「売上補充」も必須です。

FAQ

模範解答

解説

解答の論理構成

1. (a) を決める
   トラック在庫マスタ（H）に「CU」、積込積降明細（H）に「C」とある処理は、HT でトラックへの積み込み／積み降ろしを行う【問題文】「⑥アップロード処理：…HTのアプリケーションは…トラックの商品ごとの在庫数を計算し…」に該当する。よって (a)＝「積込積降処理」。
2. (b)・(c) を決める
   倉庫在庫マスタ（S）に「CU」、入出庫明細（S）に「C」が立つ処理は倉庫への“入庫”系。複数あるので順不同で (b)・(c) を割り付ける。
   • 工場からの受入れ【問題文】「①入庫処理：工場から倉庫に商品が届いた際、検品後に登録する。」
   • 他倉庫からの受入れ【問題文】「③移動入庫処理：ほかの倉庫から商品が届いた際…登録する。」
     従って (b)＝「入庫処理」、(c)＝「移動入庫処理」。
3. (d)・(e) を決める
   倉庫在庫マスタ（S）に「U」のみ、入出庫明細（S）に「C」が立つ処理は倉庫から“出庫”する系。順不同で (d)(e) を割り付ける。
   • 工場返品【問題文】「④返品出庫処理」
   • 他倉庫への移動【問題文】「②移動出庫処理」
     よって (d)＝「返品出庫処理」、(e)＝「移動出庫処理」。
4. (f) を決める
   倉庫在庫マスタ（S）のみ「U」が立つ夜間バッチは【問題文】「⑤倉庫在庫確定処理：HTから当日アップロードされたデータを入力として…夜間バッチ処理で行われる。」に対応する。よって (f)＝「倉庫在庫確定処理」。
5. (g) を決める
   トラック在庫マスタ（H）に「U」、トラック棚卸明細（H）に「R」がある処理は【問題文】「④トラック棚卸処理：…棚卸しでは…トラック在庫マスタの在庫数を実地棚卸数で更新する。」に一致する。よって (g)＝「トラック棚卸処理」。

誤りやすいポイント

• 「CU」を “更新だけ” と早合点し、実際には「登録＋更新」であることを見逃す。
• 「移動入庫」と「移動出庫」を、入庫元／出庫先の視点で反対にしてしまう。
• 夜間バッチの「倉庫在庫確定処理」を “更新のみ” と捉え “C” が無いことに違和感を覚え、他の処理と取り違える。

FAQ