平成26年度 秋期 午前Ⅱ システムアーキテクト試験 | 解答一覧

1. 外界の事象をデータ構造として表現する。データモデリングのアプローチをとる。その表現は、エンティティ、関連及び属性で構成される。

2. システムの機能を入力データから出力データへの変換とみなすとともに、機能を段階的詳細化に基づき階層的に分割していく。

3. 対象となる問題領域に対して、プロセスではなくオブジェクトを用いて解決を図るというアプローチをとる。

4. 並行して進行する事象間の同期を表す。その構造は2種類の節点をもつ有向2部グラフで表される。

並行して進行する事象間の同期を表す。その構造は2種類の節点をもつ有向2部グラフで表される。

1. イベント・アクティビティ・分岐・合流を示すオブジェクトと、フローを示す矢印などで構成された図によって、業務プロセスを表現する。

2. 木構造に基づいた構造化ダイアグラムであり、トップダウンでの機能分割やプログラム構造図、組織図などを表現する。

3. システムの状態が外部の信号や事象に対してどのように推移していくかを図で表現する。

4. プログラウをモジュールに分割して表現し、モジュールの階層構造と編成、モジュール間のインタフェースを記述する。

イベント・アクティビティ・分岐・合流を示すオブジェクトと、フローを示す矢印などで構成された図によって、業務プロセスを表現する。

1. Javaのパターンとして引数オブジェクト、オブジェクトの可変性などで構成される。

2. オブジェクト指向開発のためのパターンとして生成、構造、振る舞いの3カテゴリから構成される。

3. 構造、分散システム、対話型システム及び適合型システムの4カテゴリから構成される。

4. 抽象度が異なる要素を分割して階層化するためのLayers、コンポーネント分割のためのBrokerなどで構成される。

オブジェクト指向開発のためのパターンとして生成、構造、振る舞いの3カテゴリから構成される。

1. 外部設計書との一貫性の検証と要件定義の内容を満たしていることの確認

2. 設計記述規約の遵守性の評価と設計記述に関する標準化の見直し

3. 要件定義の内容に関する妥当性の評価と外部設計指針の見直し

4. 論理データ設計で洗い出されたデータ項目の確認と物理データ構造の決定

外部設計書との一貫性の検証と要件定義の内容を満たしていることの確認

1.

2.

3.

4.

スポンサー

1.

2.

3.

4.

1. 決定表は、条件と処理を対比させた表形式で論理を表現したものであり、複雑な条件判定を伴う要件定義の記述手段として有効である。

2. 構造化チャートは、システムの"状態"の種別とその状態が遷移するための"要因"との関係を分かりやすく表現する手段として有効である。

3. 状態遷移図は、DFDに"コントロール変換とコントロールフロー"を付加したものであり、制御系システムに特有な処理を表現する手段として有効である。

4. 制御フロー図は、データの"源泉、吸収、流れ、処理、格納"を基本要素としており、システム内のデータの流れを表現する手段として有効である。

決定表は、条件と処理を対比させた表形式で論理を表現したものであり、複雑な条件判定を伴う要件定義の記述手段として有効である。

1. ソフトウェアに障害が発生してから1時間以内に、利用者が使用できること

2. 利用者が使用したい機能の改善を、1週間以内に実装できること

3. 利用者が使用したい機能を、100%提供できていること

4. 利用者が使用したいソフトウェアの使用方法を、1時間以内に習得できること

利用者が使用したいソフトウェアの使用方法を、1時間以内に習得できること

1.

2.

3.

4.

1.

2.

3.

4.

スポンサー

1. オーバライド

2. オーバロード

3. メッセージパッシング

4. ユニフィケーション

ユニフィケーション

1. ウォータフォールモデルだけ

2. ウォータフォールモデルと進化的モデルだけ

3. ウォータフォールモデルとスパイラルモデルだけ

4. ウォータフォールモデル、進化的モデル、スパイラルモデルの全て

ウォータフォールモデル、進化的モデル、スパイラルモデルの全て

1. 開発を反復するので、新しい要求やビジネス目標の変化に柔軟に対応しやすい。

2. 開発を反復するので、リスクが高い部分に対して初期段階で対処しやすく、プロジェクト全体のリスクを減らすことができる。

3. 基本となるアーキテクチャをプロジェクトの初期に決定するので、コンポーネントを再利用しやすくなる。

4. ひとまとまりの要件を単位として設計からテストまでを実施するので、要件ごとに開発状況が把握できる。

ひとまとまりの要件を単位として設計からテストまでを実施するので、要件ごとに開発状況が把握できる。

1.

2.

3.

4.

1. 管理層の業務から機能を抽出し、機能をエンティティとする。次に、機能の相互関係に基づいてリレーションシップを定義する。さらに、全社の帳票類を調査して整理し、正規化された項目に基づいて属性を定義し、全社のデータモデルとする。

2. 企業の全体像を把握するために、主要なエンティティだけを抽出し、それらの相互間のリレーションシップを含めて、鳥瞰図を作成する。次に、エンティティを詳細化し、全てのリレーションシップを明確にしたものを全社のデータモデルとする。

3. 業務層の現状システムを分析し、エンティティとリレーションシップを抽出する。それぞれについて適切な属性を定め、これらを基にE-R図を作成し、それを抽象化して、全社のデータモデルを作成する。

4. 全社のデータとその処理過程を分析し、重要な処理を行っている業務を基本エンティティとする。次に、基本エンティティ相互のデータの流れをリレーションシップとして捉え、適切な識別名を与える。さらに、基本エンティティと関係のあるデータを属性とし、全社のデータモデルを作成する。

企業の全体像を把握するために、主要なエンティティだけを抽出し、それらの相互間のリレーションシップを含めて、鳥瞰図を作成する。次に、エンティティを詳細化し、全てのリレーションシップを明確にしたものを全社のデータモデルとする。

スポンサー

1. 新しい業務の在り方や運用に関わる業務手順、入力情報、組織、責任、権限、業務上の制約などの項目

2. 新しい業務の遂行に必要なアプリケーションシステムに関わる利用者の作業、システム機能の実現範囲、機能間の情報の流れなどの項目

3. 経営戦略や情報戦略に関わる経営上のニーズ、システム化・システム改善を必要とする業務上の課題、求められる成果・目標などの項目

4. システム基盤に関わる可用性、性能、拡張性、運用性、保守性、移行性、セキュリティ、システム環境などの項目

システム基盤に関わる可用性、性能、拡張性、運用性、保守性、移行性、セキュリティ、システム環境などの項目

1. 業務・システムの処理過程において、情報システム間でやり取りされる情報の種類及び方向を図式化したものである。

2. 業務を構成する各種機能を、階層化した3行3列の格子様式に分類して整理し、業務・システムの対象範囲を明確化したものである。

3. 最適化計画に基づき決定された業務対象領域の全情報（伝票、帳票、文書など）を整理し、各情報間の関連及び構造を明確化したものである。

4. 対象の業務機能に対して、情報の発生源と到達点、処理、保管、それらの間を流れる情報を、統一記述規則に基づいて表現したものである。

対象の業務機能に対して、情報の発生源と到達点、処理、保管、それらの間を流れる情報を、統一記述規則に基づいて表現したものである。

1. 業務モデルとしてビジネスプロセスとデータクラスとの関係を明らかにするために、データクラスに含まれるデータ項目を詳細にしておく必要がある。

2. 業務モデルは企業活動のモデルでもあるので、ビジネスプロセスには、日常業務レベルの活動だけでなく意思決定活動や戦略計画活動も含む必要がある。

3. 業務モデルは企業活動を正確に表現するので、データクラス間に存在しているデータの重複はそのまま反映しておく必要がある。

4. 業務モデルは全社情報システム構築の基本構造となるもので、ビジネスプロセスはその企業の現行のプロセスをそのまま反映させる必要がある。

業務モデルは企業活動のモデルでもあるので、ビジネスプロセスには、日常業務レベルの活動だけでなく意思決定活動や戦略計画活動も含む必要がある。

1. 50

2. 60

3. 70

4. 80

70

1. CGI

2. PHP

3. RPC

4. XML

RPC

スポンサー

1.

2.

3.

4.

1. 障害発生時、異常終了したトランザクションをロールバックする。

2. 障害発生時点でコミットしていたがデータベースの実更新がされていないトランザクションをロールフォワードする。

3. 障害発生時点でまだコミットもアボートしていなかった全てのトランザクションをロールバックする。

4. バックアップコピーでデータベースを復元し、バックアップ取得以降にコミットした全てのトランザクションをロールフォワードする。

バックアップコピーでデータベースを復元し、バックアップ取得以降にコミットした全てのトランザクションをロールフォワードする。

1.

2.

3.

4.

1. ブラックリスト方式では、正常な通信の検出パターンがブラックリストに登録されており、通信がブラックリストに該当しないとき、不正な通信と判定する。

2. ブラックリスト方式では、不正な通信の検出パターンがブラックリストに登録されており、通信がブラックリストに該当しないとき、不正な通信と判定する。

3. ホワイトリスト方式では、正常な通信の検出パターンがホワイトリストに登録されており、通信がホワイトリストに該当しないとき、不正な通信と判定する。

4. ホワイトリスト方式では、不正な通信の検出パターンがホワイトリストに登録されており、通信がホワイトリストに該当しないとき、正常な通信と判定する。

ホワイトリスト方式では、正常な通信の検出パターンがホワイトリストに登録されており、通信がホワイトリストに該当しないとき、不正な通信と判定する。

1. 既知の脆弱性に対するシステムの対応状況に注目し、システムに導入されているソフトウェアのバージョン及びパッチの適用状況の検査を行う。

2. ソフトウェアのデータの入出力に注目し、問題を引き起こしそうなデータを大量に多様なパターンで入力して挙動を観察し、脆弱性を見つける。

3. ソフトウェアの内部構造に注目し、ソースコードの構文を機械的にチェックするホワイトボックス検査を行うことによって脆弱性を見つける。

4. ベンダや情報セキュリティ関連機関が提供するセキュリティアドバイザリなどの最新のセキュリティ情報に注目し、ソフトウェアの脆弱性の検査を行う。

ソフトウェアのデータの入出力に注目し、問題を引き起こしそうなデータを大量に多様なパターンで入力して挙動を観察し、脆弱性を見つける。

スポンサー