はじめに

2022 SA 午前2

01-08: http://127.0.0.1:4000/archives/191 09-15: http://127.0.0.1:4000/archives/192 16-20: http://127.0.0.1:4000/archives/193 21-25: http://127.0.0.1:4000/archives/194

この専門試験の難易度はそこそこだけど、これまでに学んだ内容も出てくるね。しっかり勉強すれば午前（客観式）はパスできそう。早めに終わらせて午後問題に取り掛かりたいな、そっちが合格の決め手だから。

そういえば、共通Iの時のやり方は良くなかったなと反省してる。全く理解できていない状態で問題を解いても意味がないし、一題ずつ丁寧に進めるのが一番。前は記事を書く時に「早く終わらせなきゃ」と思って焦っちゃって、結局あの回は身に付かなかった気がする。最初はゆっくり一歩ずつで大丈夫だよね。

ひとりごと

最近、学習って一種の「繋がり」を作ることなんじゃないかって感じてるんだ。言語学習が「モノ」と「言葉」を繋げるように、他の学習も抽象的な繋がりを作ることなんだと思う。特定の入力に対して特定の出力を出す。それを繰り返すことで繋がりを深くしていくんだ。知識同士の関連付けも同じで、ある点から別の点を導き出すのは、知識間のルートを太くするようなもの。これって、モノと単語を繋げてその概念を把握するのと似てる気がする。（まあ、ただの思いつきで根拠はないけどね。実際、僕らが持ってる意見も、案外あやふやな根拠や自分の経験から勝手に導き出したものだったりするし。人間は自分の経験に基づいて観点を作るから、見たことがないものは想像できないんだよね。でも例外があるとしたら、それは「夢」かな。夢って、実は別の世界を旅してるんじゃないか、なんて妄想しちゃうんだ。最近読んだ小説で、別世界にランダムに飛ばされて、特定の条件を満たすとその世界の記憶を一部持ち帰れるっていうのがあって、自分の夢もそんな感じだったら面白いなと思って。まあ、実際は寝ている間に脳が想像力に全振りして、起きてる時にはできないような発想をしてるだけなんだろうけど。DNAの二重螺旋構造を見つけた人も、夢からインスピレーションを得たらしいしね。）

1

アジャイル開発の初期段階において、プロジェクトの目的、スコープなどに対する共通認識を得るために、あらかじめ設定されている設問と課題について関係者が集まって確認し合い、その成果を共有する手法はどれか。

ア　アジャイルモデリング

イ　インセプションデッキ

ウ　プランニングポーカ

エ　ユーザストーリマッピング

【問題の要約】アジャイル開発の初期に、目的や範囲の共通認識を作るために、質問や課題を確認し合う手法はどれ？

ア agile modeling イ Inception Deck ウ planning poker エ user story mapping

インセプションデッキ（Inception Deck）は、プロジェクトの初期段階でチームが目的や範囲について合意形成するために使われる重要な手法なんだ。チームは事前に決められた重要な質問（プロジェクトの目標、潜在的リスク、成功基準など）について話し合うことで、全員がプロジェクトの方向性と境界線を明確に理解できるようになる。だから、正解は イ。

2

ソフトウェアパターンのうち、GoFのデザインパターンの説明はどれか。

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

イ　オブジェクト指向開発のためのパターンであって、生成、構造、振る舞いの三つのカテゴリに分類される。

ウ　構造、分散システム、対話型システム及び適合型システムの四つのカテゴリに分類される。

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

【問題の要約】GoF（Gang of Four）デザインパターンの説明として正しいのはどれ？

ア Javaのパターン。引数オブジェクトや可変性などで構成。 イ オブジェクト指向開発用で、生成・構造・振る舞いの3つに分類。 ウ 構造、分散、対話型、適合型の4つに分類。 エ 抽象度による階層化（Layers）やコンポーネント分割（Broker）などで構成。

GoFのデザインパターンは、4人のソフトウェアエンジニアが提唱した古典的なパターンで、オブジェクト指向プログラミングに特化したもの。デザインパターンを「生成（Creational）」「構造（Structural）」「振る舞い（Behavioral）」の3つのカテゴリに分けて、よくある設計上の問題を解決するんだ。だから、正解は イ。

ちょっと 関連する紹介 を調べてみたけど、たぶん僕が 以前書いたデザインパターンの記事 の元ネタだね。

3

Pattern-Oriented Software Architecture (POSA) のアーキテクチャパターンのうち、ソフトウェアをメタレベルとベースレベルの二つのレベルに分割し、ソフトウェアの構造と振る舞いとを動的に変更できる仕組みを提供しているものはどれか。

ア　Broker

イ　Microkernel

ウ　Model-View-Controller

エ　Reflection

【問題の要約】POSAのパターンの中で、ソフトウェアを「メタレベル」と「ベースレベル」に分け、構造や振る舞いを動的に変更できるようにするのはどれ？

ア Broker（代理） イ Microkernel（マイクロカーネル） ウ Model-View-Controller（MVC） エ Reflection（リフレクション/反射）

Brokerパターンは、分散システムのコンポーネント間（クライアントとサーバなど）を疎結合にするためのもので、Brokerが通信を仲介する役割を果たす。

Microkernelパターンは、OS設計によく使われるもので、コア機能（メモリ管理など）をカーネルに持ち、他の機能は独立したモジュールとして動的に追加・削除できるようにするもの。

MVCパターンは、アプリケーションのビジネスロジック（Model）、インターフェース（View）、入力制御（Controller）を分離するインタラクティブなシステム用。主に表示とロジックの分離が目的で、動的な構造変更の仕組みではない。

Reflectionパターンは、システムを「メタレベル」と「ベースレベル」の2層に分けるアーキテクチャ。メタレベルにはシステムの構造や振る舞いを記述したメタデータがあり、ベースレベルが実際の業務ロジックを動かす。リフレクションによって、ソフトウェアは実行時に自分の構造や振る舞いを動的に変更できるんだ。高い拡張性や柔軟性が必要なシステムで使われるよ。だから、正解は エ。

4

組込みシステムでDBMSを用いるときには、通信のオーバヘッド、通信負荷の発生を防ぐこと、必要なメモリ容量をリソース制限内に抑えることなどを目的として、インプロセスデータベースを用いることがある。このインプロセスデータベースの説明として、適切なものはどれか。

ア　クライアントサーバ形式のクライアントとなるアプリケーションプログラムとソケットを介して通信し、SQLを用いて処理を記述する。

イ　データベースエンジンはライブラリ形式で提供され、アプリケーションプログラムとリンクされて同一メモリ空間で動作する。

ウ　データベースの全体をメモリ上に配置して、データベース処理を高速化する。

エ　一つのテーブルを一つのファイルで管理し、アプリケーションプログラムからはファイル入出力のAPIで操作する。

【問題の要約】組込みシステムで使われる「インプロセスデータベース」の説明として正しいのはどれ？

ア ソケット通信を使って、クライアントアプリからSQLで操作する。 イ エンジンがライブラリとして提供され、アプリと同じメモリ空間で動く。 ウ データベース全体をメモリに置いて高速化する。 エ 1テーブル1ファイルで管理し、ファイルI/O APIで操作する。

インプロセスデータベース（In-process database）は、データベースエンジンがライブラリファイルとしてアプリケーションに組み込まれ、同じメモリ空間を共有するもの。これによってクライアント・サーバ型のような通信オーバーヘッドや負荷を避けられるから、リソースが限られた組み込みシステムに向いているんだ。

ア は一般的なクライアント・サーバ型、ウ は「インメモリデータベース」、エ はファイルベースの管理方法を指しているね。というわけで、正解は イ。

5

デザインパターンのなかのストラテジパターンを用いて、帳票出力のクラス図のとおりに設計した。適切な説明はどれか。

ア　クライアントは、使用したいフォーマットに対応する、帳票出力ストラテジクラスのサブクラスを意識せずに利用できる。

イ　新規フォーマット用のアルゴリズムの追加が容易である。

ウ　帳票出力ストラテジクラスの中で、どのフォーマットで帳票を出力するかの振り分けを行っている。

エ　帳票出力のアルゴリズムは、コンテキストクラスの中に記述する。

【問題の要約】ストラテジ（Strategy）パターンを使った帳票出力の設計について、正しい説明はどれ？

ア クライアントは具体的なサブクラスを意識しなくていい。 イ 新しいフォーマット用のアルゴリズム追加が簡単。 ウ ストラテジクラス自身がフォーマットの振り分けを行う。 エ アルゴリズムはコンテキストクラスの中に書く。

これはストラテジパターンを使って、複数のフォーマットで帳票を出し分ける設計だね。ストラテジパターンの原則は、「アルゴリズムの実装」と「その利用」を分離すること。そうすることで、クライアント側のコードを変えずにアルゴリズムを切り替えたり追加したりできるんだ。ちなみに、ストラテジパターンの記事も書いたことがあるよ： https://blog.yexca.net/archives/137

新しいアルゴリズム（フォーマット）を増やしたい時は、新しい具体的なストラテジクラスを作るだけで既存の構造に組み込めるから、追加がすごく楽なんだ。だから、正解は イ。

6

モジュール間のデータの受渡し方法のうち、最も低いモジュール結合度となるものはどれか。

ア　単一のデータ項目を大域的データで受け渡す。

イ　単一のデータ項目を引数で受け渡す。

ウ　データ構造を大域的データで受け渡す。

エ　データ構造を引数で受け渡す。

【問題の要約】モジュール結合度が「最も低い（良い）」データの渡し方はどれ？

ア グローバル変数で単一データを渡す。 イ 引数で単一データを渡す。 ウ グローバル変数でデータ構造を渡す。 エ 引数でデータ構造を渡す。

これはプログラムの結合度についての問題だね。これについても記事を書いたことがあるよ： https://blog.yexca.net/archives/145#%E8%80%A6%E5%90%88

単一のデータ値を渡すのは「データ結合」、データ構造を渡すのは「スタンプ結合」、グローバル変数を使うのは「共通結合」になる。この中で最も結合度が低い（独立性が高い）のはデータ結合。だから、正解は イ。

7

既存システムを基に、新システムのモデル化を行う場合のDFD作成の手順として、適切なものはどれか。

ア　現物理モデル -> 現論理モデル -> 新物理モデル -> 新論理モデル

イ　現物理モデル -> 現論理モデル -> 新論理モデル -> 新物理モデル

ウ　現論理モデル -> 現物理モデル -> 新物理モデル -> 新論理モデル

エ　現論理モデル -> 現物理モデル -> 新論理モデル -> 新物理モデル

【問題の要約】既存システムをベースに新システムをモデル化する時のDFD作成順序は？

ア 現物理 -> 現論理 -> 新物理 -> 新論理 イ 現物理 -> 現論理 -> 新論理 -> 新物理 ウ 現論理 -> 現物理 -> 新物理 -> 新論理 エ 現論理 -> 現物理 -> 新論理 -> 新物理

これは感覚的に イ かな。一般的にDFDを作るときは、まず今のシステムの具体的な実装（現物理）から業務要件を抽出（現論理）して、それから新しい業務要件に改善（新論理）し、最後にそれをどう実現するか（新物理）を決める、という流れになるんだ。

8

ある購買システムの開発において、開発者が行った探索的テストの例として、適切なものはどれか。

ア　過去に購買システムを開発した経験に基づいて、入力項目間の関連チェックの不備を検出できそうなデータパターンを推測し、テストケースを事前に作成してテストした。

イ　数量の範囲に応じて適用する商品価格が正しいかどうかを確認するために、各範囲の数量の中央の値を用いたテストケースを作成してテストした。

ウ　組織変更の前後で組織名が正しく印刷されるかどうかを確認するために、新組織の有効開始日とその前日とを発注日とするテストケースを事前に作成してテストした。

エ　入力値の組合せが無効なときは伝票を作成しないことを確認するために、幾つかの代表的な入力値の組合せをテストし、その結果に基づいて次のテストケースを作成してテストしを繰り返した。

【問題の要約】「探索的テスト」の例として正しいのはどれ？

ア 経験に基づいてテストケースを事前に作ってテストした。 イ 範囲の中央値を使ってテストケースを作ってテストした。 ウ 境界日を使ってテストケースを事前に作ってテストした。 エ 代表的な組み合わせをテストし、その結果を見ながら次のテストケースを繰り返し作った。

探索的テスト（Exploratory Testing）は、テストをしながら動的にテストケースを設計・実行する手法のこと。あらかじめ決められたテストケースに頼るんじゃなくて、システムの動きを観察しながらその場でテストプランを調整していくのが特徴なんだ。

ア、イ、ウ はどれも「事前にテストケースを作成」しているから、従来型の設計テストだね。結果を見ながら次のテストを考えて繰り返している エ が探索的テストに該当する。だから、正解は エ。