- トップページ
- システムアーキテクト
- 平成26年度秋季問題
- 平成26年度秋季解答・解説
平成26年度秋季解答
問題1
ソフトウェアの要求分析や設計に利用されるモデルに関する記述のうち、ペトリネットの説明として、適切なものはどれか。
ア | 外界の事象をデータ構造として表現する、データモデリングのアプローチをとる。 その表現は、エンティティ、関連及び属性で構成される。 |
イ | システムの機能を入力データから出力データへの変換とみなすとともに、機能を段階的詳細化に基づき階層的に分割していく。 |
ウ | 対象となる問題領域に対して、プロセスではなく、オブジェクトを用いて解決を図るというアプローチをとる。 |
エ | 平行して進行する事象間の同期を表す。その構造は2種類の節点をもつ有向2部グラフで表される。 |
解答:エ
<解説>
ペトリネットとは、カール・アダム・ペトリが1962年に発表した離散分散システムを数学的に表現する手法である。モデリング言語としては分散システムを注釈付の有向2部グラフとして視覚的に表現する。
ア | × | E-Rモデルの説明である。 |
イ | × | DFDの説明である。 |
ウ | × | オブジェクト指向分析の説明である。 |
エ | ○ | ペトリネットの説明である。 |
問題2
要求分析・設計技法のうち、BPMNの説明はどれか。
ア | イベント・アクティビティ・分岐・合流をオブジェクトと、フローを示す矢印などで構成された図によって、業務プロセスを表現する。 |
イ | 木構造に基づいた構造化ダイアグラムであり、トップダウンでの機能分割やブロック構造図、組織図などの表現に用いられる。 |
ウ | システムの状態が外部の信号や事象に対してどのように推移していくかを図で表現する。 |
エ | プログラムをモジュールに分割して表現し、モジュールの階層構造と編成、モジュール間のインタフェースを記述する。 |
解答:ア
<解説>
ビジネスプロセスモデリング表記法(英語: Business Process Modeling Notation:BPMN)とは、ワークフローとしてビジネスプロセスを描画するグラフィカルな標準記法である。BPMN は Business Process Management Initiative (BPMI) が開発し、Object Management Group (OMG) と BPMI が 2005年に合併した後は OMG が保守している。
BPMN の目的はすべてのビジネス関係者が容易に理解できる標準記法を提供することである。ビジネス関係者には、プロセスの作成・更新を行うビジネスアナリスト、プロセスの実装を行う技術者、プロセスを管理するマネージャなどが含まれる。さらに BPMN はビジネスプロセスと実装の間によく発生するコミュニケーションギャップを埋めることを意図している。
したがって、アが正解である。
問題3
ソフトウェアパターンのうち、GoFのデザインパターンの説明はどれか。
ア | Javaのデザインパターンとして引数オブジェクト、オブジェクトの可変性などで構成される。 |
イ | オブジェクト指向開発のためのパターンとして生成、構造、振舞いの3カテゴリから構成される。 |
ウ | 構造、分散システム、対話型システム及び適合型システムの4つのカテゴリから構成される。 |
エ | 抽象度が異なる要素を分割して階層化するためのLayers、コンポーネント分割のためのBrokerなどで構成される。 |
解答:イ
<解説>
GoF(Gang of Four、4人組)のデザインパターンとは、オブジェクト指向のソフトウエア再利用について代表的なものを23のパターンにまとめたものです。効率的な生産性、再利用や修正などのメンテナンス性を考慮したオブジェクト指向のプログラミングをする時の模範となります。
したがって、イが正解である。
問題4
内部設計書のデザインレビューを実施する目的として、最も適切なものはどれか。
ア | 外部設計書との一貫性の検証と要件定義の内容を満たしていることの確認 |
イ | 設計記述規約の遵守性の評価と設計記述に関する標準化の見直し |
ウ | 要件定義の内容に関する妥当性の評価と外部設計指針の見直し |
エ | 論理データ設計で洗い出されたデータ項目の確認と物理データ構造の決定 |
解答:ア
<解説>
デザインレビューは、開発における各フェーズの成果物に対して、要求された仕様を満たしているか検査を行う作業である。
デザインレビューでは、文書化された成果物を、客観的に複数の人が様々な視点で検査する。その結果、次の工程に進む前に現工程の誤りや不備を発見することができる。
ア | ○ | 内部設計では外部設計で作成された仕様に基づいて、ソフトウェア内部のアーキテクチャ、データ処理や管理の方法、アルゴリズムなどを設計する工程である。したがって外部設計書との一貫性の検証と要件定義の内容を満たしていることの確認が必要となる。 したがって、内部設計書のデザインレビューで実施する。 |
イ | × | 開発工程のデザインレビューで実施する。 |
ウ | × | 基本計画工程のデザインレビューで実施する。 |
エ | × | 内部設計そのもので行う作業である。 |
問題5
図は、商品の受注処理を行うプログラムのモジュール構成図である。 a~dのうち、機能的強度のモジュールはどれか。
ア | a |
イ | b |
ウ | c |
エ | d |
解答:ウ
<解説>
モジュール強度とは、ソフトウェアを構成するプログラムのモジュール(部品)の性質を表す用語の一つで、モジュールに含まれる複数の機能の関連性の強さのことである。モジュール強度が強いものから,弱いものの順に次のようになる。
- 機能的強度
全安素が1つの機能を実行するために関連性をもっている - 情服的強度
特定のデータを扱う複数の機能がまとまっており,機能ごとに別の入り口点をもつ - 連絡的強度
手順的強度の性格をもつことに加えて.各機能が同一データを扱っている - 手順的強度
ある手続きを実現するために複数の逐次的処理がまとまっている - 時問的強度
初期設定処理,終了処理など,同じタイミングで実行される複数の逐次的処理がまとまっている - 倫理的強度
関連のある複数の機能を含み,どの機能を実行するかを選択できる - 暗号的強度
関連のない複数の機能を含み,特定の機能を定義していない
ア | × | 時問的強度の説明である。 |
イ | × | 倫理的強度の説明である。 |
ウ | ○ | 機能的強度の説明である。 |
エ | × | 連絡的強度の説明である。 |
お問い合わせ