平成24年度 秋期 午前Ⅱ

解説

DFD（データフロー図）は，業務やシステムをデータの流れに着目して表す図で，データの流れを表すデータフロー（矢印），データを加工・変換するプロセス（円），データを蓄えるデータストア（二本線），システムの外部にあるデータの発生源や行き先を表す源泉と吸収（外部実体，四角）の四つの図形要素で表す。この中から三つを挙げたエが正しい。

アとウの“実体”と，アとイの“関連”は，データを実体（エンティティ）とその間の関連（リレーションシップ）で表す E-R 図の要素であり，DFD の図形要素ではない。

解説

ペトリネットは，プレース（状態や条件を表す節点）とトランジション（事象を表す節点）の 2 種類の節点を有向の枝で結んだ有向 2 部グラフで，プレースに置いたトークンがトランジションの発火によって移動する様子で，システムの振る舞いを表す。並行して進む事象の間の同期や排他，因果関係を表現できるので，並行処理を行うシステムの分析に用いられる。エが該当する。

アのエンティティ，関連及び属性でデータ構造を表すのは E-R モデル，イの入力から出力への変換として機能をとらえ段階的に階層分割していくのは構造化分析（DFD を用いる手法），ウのプロセスではなくオブジェクトを中心に問題領域をとらえるのはオブジェクト指向分析の説明である。

解説

BPMN（Business Process Model and Notation）は，OMG が標準化した業務プロセスの表記法である。イベント，アクティビティ，ゲートウェイ（分岐・合流）などのフローオブジェクトを，シーケンスフローなどの矢印で結んで業務プロセスを図に表す。業務担当者にも技術者にも理解しやすいフローチャートに似た表記を目指している。アが該当する。

イは木構造で機能や組織の階層を上から下へ分割して表す構造化チャート（階層図）の説明である。ウは外部の信号や事象によるシステムの状態の推移を表す状態遷移図，エはプログラムをモジュールに分割し，その階層構造とモジュール間のインタフェースを表す構造化設計のモジュール構造図の説明である。なお，BPMN は 1.x 版では Business Process Modeling Notation の略だったが，2.0 版で現在の名称になった。

解説

GoF（Gang of Four）のデザインパターンは，オブジェクト指向設計でよく現れる問題と解決策を23のパターンにまとめたもので，オブジェクトの生成に関わる“生成”，クラスやオブジェクトの組み合わせ方に関わる“構造”，オブジェクト間の責任分担や処理の流れに関わる“振る舞い”の三つに分類される。イが正しい。

ウとエは，ソフトウェアアーキテクチャのパターン集である POSA（Pattern-Oriented Software Architecture）の説明で，Layers や Broker はそのアーキテクチャパターンである。アは Java に特化した実装上の指針の説明で，GoF のパターンは特定の言語に依存しない。

解説

コデザイン（ハードウェア／ソフトウェア協調設計）は，組込みシステムの開発で，ハードウェアとソフトウェアを別々に作り込むのではなく，上流工程の段階から両者をまとめて設計し，どの機能をハードウェアで実現し，どの機能をソフトウェアで実現するかの分担を，協調シミュレーションによって検証しながら決めていく手法である。後工程での手戻りを減らせる。イが適切である。

アは分析から検証までを繰り返す反復型の開発手法，エは前工程に戻らないことを前提に工程を順に完了させるウォーターフォールモデルの説明である。ウはハードウェアとソフトウェアを独立に開発して最後に統合する従来の進め方で，統合テストまで仕様との不整合が分からない。コデザインはこの問題を解消するための手法である。

解説

多相性（ポリモーフィズム）は，同じメッセージを送っても，受け取るオブジェクトのクラスによって異なる振る舞いをする性質である。図では，営業部長が同じ“営業状況を報告してください”という指示を送り，営業課長は課全体の目標と実績を，営業部員は個人の目標と実績と担当顧客状況を報告している。受け手ごとに応答が異なるので，ウが該当する。

アのカプセル化は，データとそれを操作する手続を一つにまとめ，内部を外部から隠蔽すること，イの継承は，上位クラスの属性や操作を下位クラスが引き継ぐ仕組み，エの抽象化は，対象から共通する本質的な性質を取り出して，細部を捨ててモデル化することである。

解説

昇順のリストへデータを挿入するサブルーチンでは，空のリストへの挿入，先頭への挿入，末尾への挿入，途中への挿入の各場合を網羅してテストする必要がある。イの 3，1，4，2 では，3 は空のリストへ，1 は先頭へ，4 は末尾へ，2 は 1 と 3 の間へ挿入され，全ての場合を確認できる。イが適切である。

アの 1，3，2，4 は，空のリスト，末尾，途中，末尾への挿入で，先頭への挿入を確認できない。ウの 3，4，2，1 は，空のリスト，末尾，先頭，先頭への挿入で，途中への挿入を確認できない。エの 4，3，2，1 は，空のリストへの挿入の後は全て先頭への挿入になる。

解説

プログラムテスト仕様書は，全体から詳細へと順に具体化して作成する。まず a でテスト環境やテスト方法などの概要を記述し，d でテストすべき項目を全て列挙する。次に c で各テスト項目を確かめるためのテストケースを設定し，b でテストケースごとのテストデータと予想結果を作成する。最後に e で，テストを実行するときの個々の詳細な手順を設定する。a，d，c，b，e の順となり，アが適切である。

イとエはテストケースを設定する前に実行手順を決めており，何をどのデータで確かめるかが決まらないうちに手順を作ることになる。ウはテスト項目の列挙を最後に置いており，テストケースやテストデータを作る根拠となる項目が後から決まることになるので，いずれも順序が適切でない。

解説

静的テストは，プログラムを実行せずに，ソースコードや設計書を調べて欠陥を見つける手法である。人が読んで確かめるコード検査（インスペクションやウォークスルー）や，ツールで構文や制御の流れ・データの流れを解析する静的解析などがある。アが適切である。

イはスタブとドライバが逆で，単体テストでは被検査モジュールをドライバから呼び出し，被検査モジュールが呼び出す下位モジュールの代わりにスタブを使う。ウのトップダウンテストは上位モジュールから結合するので，全体の制御構造に関わる欠陥は早い段階で見つかりやすい。欠陥が最終段階まで見つかりにくいのはボトムアップテストの特徴である。エは内部構造に基づいてテストケースを設定するホワイトボックステストの説明であり，ブラックボックステストは内部構造を見ずに入力と出力の仕様から設計する。

解説

原因-結果グラフでは，“学生レコードを受け付ける”は三つの原因の論理積なので，学籍番号，出身高校コード，学年が全て正しい（全て Y）ときだけ受け付ける。“学生レコードを受け付けない”は三つの原因の否定の論理和なので，どれか一つでも正しくない（N）ときに受け付けない。決定表にすると，全て Y の列で“受け付ける”に X，いずれか一つが N でほかは問わない（－）列で“受け付けない”に X が付く。ウが正しい。

アは全て N のときに受け付けるとしており，論理積の条件と逆である。イは出身高校コードと学年が N でも受け付けるとしている。エは第3列で出身高校コードが Y のときに受け付けないとしており，否定の関係と合わない。

解説

共通フレーム 2007 の開発プロセスでは，システム要件定義のアクティビティで，システムの機能・能力や設計上の制約などとともに，適格性確認要件（システムが要件を満たしていることを評価する基準）を定義する。システム適格性確認テストは，このシステム要件定義で明確にした要件に照らして行う。イが該当する。

アのシステム方式設計は，システム要件をハードウェア・ソフトウェア・手作業に割り振る最上位の構造を決めるアクティビティである。エのソフトウェア要件定義はソフトウェア適格性確認テストで確認する内容を明確にし，ウのソフトウェア方式設計ではソフトウェア結合のための暫定的なテスト要件を定める。なお，現行の共通フレーム 2013 では，これらのアクティビティは“システム要件定義プロセス”のようなプロセスとして整理し直されている。

解説

本番稼働中のシステムに障害が起きたら，まず障害の内容を把握するために，問題を再現するか検証して，何が起きているかを確かめる。内容が分からないうちは，修正の方法も規模も決められない。JIS X 0160 のソフトウェア保守プロセスでも，問題の分析の中に“問題を再現するか又は検証する”タスクがあり，その後に修正の選択肢の作成，文書化，承認が続く。エが最初に行う作業である。

アの修正の選択肢の検討，ウの修正量・修正費用・修正時間の見積りは，障害の内容を把握したうえで行う分析の作業である。イの修正内容の文書化と承認は，選択肢を検討して修正方針を決めた後に行う作業である。

解説

マッシュアップは，Web API などで公開されている複数のサービスを組み合わせて，新しいサービスを作り出す手法である。例えば地図サービスと店舗情報のサービスを組み合わせて，店舗の場所を地図に示すサービスを作る。エが正しい。

アは既存のプログラムを解析して仕様を導き出すリバースエンジニアリング。イは既存のプログラムを部品化して組み合わせるソフトウェア部品の再利用，ウはクラスライブラリを使った開発で，いずれも自組織のプログラム資産を再利用する方法であり，外部に公開されたサービスを組み合わせるマッシュアップとは異なる。

解説

PBP（回収期間）は，投資額をキャッシュインの累計で回収し終えるまでの期間で，短いほど投資効率が良いと評価する。投資額 500 に対する累計は，a が 100，250，450，700 で 4 年目に回収（約 3.2 年），b が 100，300，600 で 3 年目に回収（約 2.7 年），c が 200，350，450，600 で 4 年目に回収（約 3.3 年），d が 300，500 でちょうど 2 年目に回収する。最も短い d が最も投資効率が良く，エになる。

a はキャッシュインの合計（1,000）が最も大きいが，前半の金額が小さいので回収が遅い。PBP は回収後のキャッシュインを評価に含めないので，合計額の大小では決まらない。b と c も d より回収に時間がかかる。

解説

全社のデータモデルは，全体計画の立案に使うため，まず企業全体を見渡せることが重要である。そこで，トップダウンで企業活動の中心となるエンティティだけを抽出し，それらの間のリレーションシップを含めた鳥瞰図を作成して全体像を把握する。次に，エンティティを詳細化し，全てのリレーションシップを明確にして全社のデータモデルに仕上げる。イが適切である。

アは機能をエンティティとしており，業務の機能とデータを取り違えている。ウは業務層の現状システムからボトムアップに積み上げるので，現状の個別システムの構造に引きずられ，全社の視点をもったモデルになりにくい。エは業務（処理）をエンティティ，データの流れをリレーションシップとしており，データフローの考え方と E-R モデルを混同している。

解説

ソフトシステムズ方法論（SSM）は，P. チェックランドが提唱した問題解決の手法で，利害関係者がそれぞれ異なる世界観をもつ，構造のはっきりしない問題状況を対象とする。問題状況の表現，根底定義，概念モデルの作成，現実との比較，望ましく実行可能な変化の議論などの七つのステージを経て，関係者の合意（折り合い）を形成し，改善の行動につなげる。アが該当する。

イは質問項目を事前に固定しない非構造化インタビュー，ウは現場の会話や身体の動きを記録して活動をあるがままに理解しようとするエスノグラフィ（行動観察）の手法，エは回答結果のフィードバックを繰り返して意見を集約するデルファイ法の説明である。

解説

エンタープライズアーキテクチャの参照モデルのうち，BRM（Business Reference Model，業務参照モデル）は，業務を分類・整理し，業務の体系や業務を構成する機能とその間を流れる情報をモデルとして示したものである。組織全体で共通化できる業務やシステムの対象領域を洗い出すために使う。イが該当する。

アのアプリケーションを機能の観点から分類したサービスコンポーネントのモデルは SRM（Service Component Reference Model），ウのプラットフォームや技術の標準仕様のモデルは TRM（Technical Reference Model），エの組織間で共有する情報の名称・定義・属性を記述したモデルは DRM（Data Reference Model）である。

解説

シン・プロビジョニングはストレージの仮想化技術の一つで，利用者（サーバ）には必要と見込まれる容量の仮想ボリュームを見せておき，物理ディスクの領域は実際にデータが書き込まれた分だけ割り当てる。物理容量を最初から全て用意する必要がなく，使用量の増加に合わせて追加できるので，ストレージの利用効率が上がる。エが適切である。

アは同じデータを複数のディスクに書き込むミラーリング（RAID 1），イは 1 台のディスクを複数の領域に分けるパーティション分割の説明である。ウは，ファイバチャネルなどでサーバとストレージをネットワーク接続する SAN（Storage Area Network）の説明である。

解説

CPU 使用率は常に 80％なので，ガーベジコレクションの頻度である 5 秒間のうち，CPU 稼働時間は 5 秒×0.8＝4 秒（4,000 ミリ秒）である。この中でガーベジコレクションの処理時間は 100 ミリ秒なので，アプリケーションの実行が停止している時間の割合は 100÷4,000＝0.025，つまり 2.50％になる。イが正しい。

アの 2.00％は，100 ミリ秒を CPU 稼働時間ではなく経過時間の 5 秒（5,000 ミリ秒）で割った値で，CPU 使用率 80％を考慮していない。ウの 6.25％とエの 8.33％は，この仕様からの計算では得られない値である。

解説

自律コンピューティングは，システムの大規模化・複雑化によって人手での管理が難しくなった問題に対し，システム自身に自己管理の機能をもたせて解決しようとする考え方である。構成の自動設定（自己構成），障害の検知と回復（自己修復），性能の調整（自己最適化），攻撃からの防御（自己防衛）などを，運用者の介入を減らしてシステムが自ら行うことを目指す。イが該当する。

アは各コンピュータが対等でサーバにもクライアントにもなる P2P（ピアツーピア），ウはコンピュータが生活や社会のいたるところに存在して連携し人間を支援するユビキタスコンピューティングの説明である。エはオーバレイネットワーク上で各コンピュータの情報を探索する，P2P ネットワークにおける情報検索の技術の説明である。

解説

条件(1)の“全ての社員は入社年を特定できる”から，社員 1 人に対応する年（入社年）はちょうど一つなので，年側の多重度 b は 1..1 になる。条件(2)の“年によっては社員が入社しないこともある”から，一つの年に対応する社員は 0 人以上なので，社員側の多重度 a は 0..* になる。イが適切である。

ア，ウの b が 0..1 だと，入社年が特定できない社員の存在を許してしまい，条件(1)に反する。ウ，エの a が 1..* だと，どの年にも必ず 1 人以上の社員が入社することになり，条件(2)に反する。

解説

共有ロックは読取りのためのロックで，ほかのトランザクションの共有ロックとは両立するが，専有ロックとは両立しない。X が A 表の行 a に共有ロックを掛けているときに，Y が A 表全体に専有ロックを獲得できると，行 a も Y に専有されてしまい，X のロックと矛盾する。したがって Y は A 表に専有ロックを獲得できない。イが適切である。

アは行 a と別の行 b へのロックなので，対象が重ならず，Y は行 b に専有ロックを獲得できる。ウは表全体への共有ロックと専有ロックが競合するので，Y は専有ロックを獲得できない。エは X が表全体を専有しているので，Y は表内のどの行にも専有ロックを獲得できない。

解説

クラス B の IPv4 アドレスは，32 ビットのうち上位 16 ビットがネットワーク部，下位 16 ビットがホスト部である。ホスト部が全て 0 のアドレスはネットワークアドレス，全て 1 のアドレスはブロードキャストアドレスとして予約されているので，ホストに割り当てられる数は 2¹⁶－2＝65,534 になる。エが正しい。

ほかの選択肢は，ホスト部のビット数が違う場合の値である。アの 1,022 はホスト部が 10 ビット（2¹⁰－2），イの 4,094 は 12 ビット（2¹²－2），ウの 32,766 は 15 ビット（2¹⁵－2）のときのホストアドレス数で，いずれもクラス B のホスト部 16 ビットとは合わない。

解説

RPO（Recovery Point Objective，目標復旧時点）は，災害などで失ったデータを，過去のどの時点の状態まで復旧させるかの目標値である。例えば“1 日前のデータまで”のように決め，バックアップやデータ複製の頻度・方式を選ぶ基準にする。システムが再稼働したときに，災害発生前のどれだけ新しい状態に戻せるかを示すので，エが該当する。

ウの災害発生から再稼働までの時間は RTO（Recovery Time Objective，目標復旧時間）である。アの人員計画と交代要員のスキル，イの代替システム環境と通常の環境との設備投資の比率は，事業継続計画で検討する事項ではあるが，RPO の定義ではない。

解説

SSH（Secure Shell）は，ネットワークを介したリモートログインやファイルのコピーを，暗号化と認証によって安全に行うためのツール及びプロトコルである。telnet や rlogin，rcp などの代わりに使われる。エが正しい。

アは電子メールの暗号化とディジタル署名の標準である S/MIME，イはクレジット決済を安全に行うための仕様である SET，ウは共通鍵暗号と公開鍵暗号を併用して電子メールを暗号化するソフトウェアである PGP の説明である。