引言
2022 SA am2
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
這份專門試卷難度倒是還好，不過還是有我學過的內容，想必經過一定的學習後我應該可以通過選擇題，希望能早點做完後看看下午題，這才是我合格的關鍵。
說到這裡，我覺得共通一我的做法很有問題，完全看不懂的情況下做題完全沒有意義，還是慢慢一題一題做比較好。之前我做完後在寫文章解析時，倒是想著快點完成，導致那張試卷幾乎相當於白做，畢竟剛開始一題一題慢慢做也沒關係。
碎碎念
最近突然覺得學習彷彿是一種連結，靈感來源於語言的學習就是一種將事物與語言的連結，而學習的東西是一種抽象的連結，針對於某種輸入，產生某種輸出，通過不斷地重複加深這種連結。比較直觀的就是知識點的關聯，從某一點推出另一點，彷彿就是兩個知識之間的連結，在看過或者自己推出這個連結後將這種連結加深，這就類似事物與語言詞彙的連結，從而讓人掌握了這個事物，或者說這種連結後，也就掌握了此知識。（當然只是隨便一想而已，無相應證明。事實上我聽到的多數觀點或論據也可能是基於不夠嚴謹的證明，從自己的一段經歷推導出來的。人基於自己的經歷來形成自己的觀點，沒有見過的事物是無法想像的。不過有一個例外，可能就是夢吧，夢確實可能是自己到了某個世界遊歷，當然並不嚴謹，這還是最近我看到一個小說是進入某世界隨機出現在那個世界的某處，然後經歷一番後若有完成特殊條件可以保留那個世界的部分記憶有所收穫，對於自己做的夢倒也是如此從而讓我有了這個推斷。但事後仔細回想後，倒是可能因為睡著後大腦可以專注於想像，此時想像力達到巔峰，從而完成自己醒著時候無法想像到的。比如 DNA 雙螺旋結構的發現人也是從夢中得到的靈感）
1
アジャイル開発の初期段階において、プロジェクトの目的、スコープなどに対する共通認識を得るために、あらかじめ設定されている設問と課題について関係者が集まって確認し合い、その成果を共有する手法はどれか。
ア アジャイルモデリング
イ インセプションデッキ
ウ プランニングポーカ
エ ユーザストーリマッピング
題目翻譯：在敏捷開發的初期階段，為了在專案的目的、範圍等方面達成共識，相關人員會聚集在一起確認預先設定的問題與課題，並共享成果。這種方法是哪一種？
ア agile modeling (敏捷建模)
イ Inception Deck (創始手冊)
ウ planning poker (規劃撲克)
エ user story mapping (使用者故事對照)
Inception Deck 是一種重要的方法，尤其在專案的初始階段使用，以確保團隊對專案的目的和範圍形成共識。團隊會事先確定並探討一些關鍵性的問題（如專案的目標、潛在風險、成功標準等），這能夠幫助所有團隊成員對專案的整體方向和邊界有清晰的理解並達成一致。因此，正確答案是 イ。
2
ソフトウェアパターンのうち、GoFのデザインパターンの説明はどれか。
ア Javaのパターンとして、引数オブジェクト、オブジェクトの可変性などで構成される。
イ オブジェクト指向開発のためのパターンであって、生成、構造、振る舞いの三つのカテゴリに分類される。
ウ 構造、分散システム、対話型システム及び適合型システムの四つのカテゴリに分類される。
エ 抽象度が異なる要素を分割して階層化するためのLayers、コンポーネント分割のためのBrokerなどで構成される。
題目翻譯：在軟體模式中，GoF (Gang of Four) 設計模式的描述是哪一個？
ア Java 模式，由參數物件和物件的可變性等構成。
イ 物件導向開發的模式，分為生成 (Creational)、結構 (Structural) 和行為 (Behavioral) 三類。
ウ 分為結構、分散式系統、互動式系統及適應性系統四類。
エ 為了將不同抽象層次的元素分離並階層化，包含 Layers、Broker 等。
GoF 的設計模式是由四位軟體工程師提出的經典設計模式，專門用於物件導向程式設計。它將設計模式分為三大類：生成（創建）、結構、行為，用於解決常見的物件導向設計問題。因此，正確答案是 イ。
我去搜了下 相關介紹 ，貌似就是 我之前寫的設計模式 的由來吧。
3
Pattern-Oriented Software Architecture (POSA) のアーキテクチャパターンのうち、ソフトウェアをメタレベルとベースレベルの二つのレベルに分割し、ソフトウェアの構造と振る舞いとを動的に変更できる仕組みを提供しているものはどれか。
ア Broker
イ Microkernel
ウ Model-View-Controller
エ Reflection
題目翻譯：在模式導向軟體架構 (POSA) 的架構模式中，將軟體分為元層 (meta level) 和基礎層 (base level) 兩個層級，並提供一種能夠動態改變軟體結構和行為的機制的是哪一種？
ア Broker (經紀人/代理)
イ Microkernel (微核心)
ウ Model-View-Controller (模型-視圖-控制器)
エ Reflection (反射)
Broker 模式是一種分散式系統架構模式，旨在將系統的不同組件（如用戶端和伺服器）解耦合，透過 Broker 進行通訊。Broker 充當媒介的角色，負責傳遞訊息並管理遠端服務的呼叫。
Microkernel 模式通常用於作業系統設計，將核心功能（如記憶體管理、行程管理）保留在微核心中，而將其他選用功能作為獨立模組來實現，能夠動態載入或解除載入。
Model-View-Controller (MVC) 模式是一種常見的互動式系統架構模式，用於分離應用程式的商業邏輯 (Model)、使用者介面 (View) 和使用者輸入控制 (Controller)。MVC 主要目的是解耦顯示邏輯和商業邏輯，並沒有提供動態改變軟體結構和行為的機制。
Reflection 模式是一種將軟體分為「元層」和「基礎層」兩層的架構模式，元層包含描述系統結構和行為的元資料，而基礎層負責執行實際的商業邏輯。透過反射模式，軟體可以動態修改其結構和行為，以適應不同的需求和場景。這種模式常用於需要高擴充性和靈活性的系統。因此，正確答案是 エ。
4
組込みシステムでDBMSを用いるときには、通信のオーバヘッド、通信負荷の発生を防ぐこと、必要なメモリ容量をリソース制限内に抑えることなどを目的として、インプロセスデータベースを用いることがある。このインプロセスデータベースの説明として、適切なものはどれか。
ア クライアントサーバ形式のクライアントとなるアプリケーションプログラムとソケットを介して通信し、SQLを用いて処理を記述する。
イ データベースエンジンはライブラリ形式で提供され、アプリケーションプログラムとリンクされて同一メモリ空間で動作する。
ウ データベースの全体をメモリ上に配置して、データベース処理を高速化する。
エ 一つのテーブルを一つのファイルで管理し、アプリケーションプログラムからはファイル入出力のAPIで操作する。
題目翻譯：在嵌入式系統中使用 DBMS 時，常常為了防止通訊開銷 (Overhead)、通訊負荷的產生，並將必要的記憶體容量控制在資源限制範圍內，而使用程序內資料庫 (In-process database)。關於這種程序內資料庫的描述，正確的是哪一個？
ア 透過通訊端 (Socket) 與作為用戶端的應用程式進行通訊，並使用 SQL 進行處理。
イ 資料庫引擎以函式庫 (Library) 的形式提供，與應用程式連結，在同一記憶體空間中執行。
ウ 將整個資料庫載入到記憶體中，以加快資料庫處理速度。
エ 將一個資料表管理為一個檔案，並透過檔案 I/O API 從應用程式進行操作。
程序內資料庫 (インプロセスデータベース) 是指資料庫引擎作為函式庫檔案與應用程式連結，共享同一記憶體空間。這種設計避免了用戶端-伺服器模式帶來的通訊開銷和負載，適合資源受限的嵌入式系統。
ア 選項描述了用戶端-伺服器架構的資料庫，通常透過網路通訊端通訊；ウ 選項描述了「記憶體資料庫」，即將資料庫全部載入至記憶體以提高效能；エ 選項描述了一種基於檔案的資料庫管理方法，通常用於檔案資料庫。因此，正確答案是 イ。
5
デザインパターンのなかのストラテジパターンを用いて、帳票出力のクラス図のとおりに設計した。適切な説明はどれか。
ア クライアントは、使用したいフォーマットに対応する、帳票出力ストラテジクラスのサブクラスを意識せずに利用できる。
イ 新規フォーマット用のアルゴリズムの追加が容易である。
ウ 帳票出力ストラテジクラスの中で、どのフォーマットで帳票を出力するかの振り分けを行っている。
エ 帳票出力のアルゴリズムは、コンテキストクラスの中に記述する。
題目翻譯：使用策略模式 (Strategy Pattern) 設計了報表輸出的類別圖。下列哪項描述是正確的？
ア 用戶端可以在不關注具體策略子類別的情況下使用相應的報表輸出格式。
イ 可以輕鬆添加用於新格式的演算法。
ウ 報表輸出策略類別負責選擇使用哪種格式輸出報表。
エ 報表輸出的演算法應寫在 Context 類別（上下文類別）中。
題目是使用策略模式實現了一個多格式報表的分發。策略模式的設計原則是將演算法的實現和使用分離，使得可以在不修改用戶端程式碼的情況下切換或增加不同的演算法。同時我也寫過策略模式的文章： https://blog.yexca.net/archives/137
策略模式的設計使得新演算法的增加非常方便，只需實作新的具體策略類別並與現有結構整合即可。因此，正確答案是 イ。
6
モジュール間のデータの受渡し方法のうち、最も低いモジュール結合度となるものはどれか。
ア 単一のデータ項目を大域的データで受け渡す。
イ 単一のデータ項目を引数で受け渡す。
ウ データ構造を大域的データで受け渡す。
エ データ構造を引数で受け渡す。
題目翻譯：以下關於模組之間的資料傳遞方法，哪一種方式的模組耦合度最低？
ア 使用全域資料傳遞單一資料項。
イ 使用參數傳遞單一資料項。
ウ 使用全域資料傳遞資料結構。
エ 使用參數傳遞資料結構。
這題是考程式的耦合度的，我也寫過一篇文章： https://blog.yexca.net/archives/145#%E8%80%A6%E5%90%88
傳遞單一資料值為資料耦合 (Data Coupling)，傳遞資料結構為標記耦合 (Stamp Coupling)，全域參數應該屬於公共耦合 (Common Coupling)，其中資料耦合的耦合度最低。因此，正確答案是 イ。
7
既存システムを基に、新システムのモデル化を行う場合のDFD作成の手順として、適切なものはどれか。
ア 現物理モデル -> 現論理モデル -> 新物理モデル -> 新論理モデル
イ 現物理モデル -> 現論理モデル -> 新論理モデル -> 新物理モデル
ウ 現論理モデル -> 現物理モデル -> 新物理モデル -> 新論理モデル
エ 現論理モデル -> 現物理モデル -> 新論理モデル -> 新物理モデル
題目翻譯：基於現有系統進行新系統建模時，建立資料流圖 (DFD) 的步驟順序應為何？
ア 現實體模型 -> 現邏輯模型 -> 新實體模型 -> 新邏輯模型
イ 現實體模型 -> 現邏輯模型 -> 新邏輯模型 -> 新實體模型
ウ 現邏輯模型 -> 現實體模型 -> 新實體模型 -> 新邏輯模型
エ 現邏輯模型 -> 現實體模型 -> 新邏輯模型 -> 新實體模型
這題盲猜選 イ。一般建立資料流圖需要從現有系統的具體實作抽象出業務需求（實體到邏輯），然後再基於現有業務需求改進出邏輯模型，最後實作新的邏輯需求（邏輯到實體）。
8
ある購買システムの開発において、開発者が行った探索的テストの例として、適切なものはどれか。
ア 過去に購買システムを開発した経験に基づいて、入力項目間の関連チェックの不備を検出できそうなデータパターンを推測し、テストケースを事前に作成してテストした。
イ 数量の範囲に応じて適用する商品価格が正しいかどうかを確認するために、各範囲の数量の中央の値を用いたテストケースを作成してテストした。
ウ 組織変更の前後で組織名が正しく印刷されるかどうかを確認するために、新組織の有効開始日とその前日とを発注日とするテストケースを事前に作成してテストした。
エ 入力値の組合せが無効なときは伝票を作成しないことを確認するために、幾つかの代表的な入力値の組合せをテストし、その結果に基づいて次のテストケースを作成してテストしを繰り返した。
題目翻譯：在一個採購系統的開發中，作為開發者進行的探索性測試的合適例子是哪一個？
ア 根據過去開發採購系統的經驗，推測出可能檢測到輸入項之間關係不完善的測試資料模式，預先建立測試案例並進行了測試。
イ 為了確認根據數量範圍套用的商品價格是否正確，使用每個範圍中間值的測試案例並進行了測試。
ウ 為了確認組織變更前後的組織名稱是否正確列印，預先建立了使用新組織有效開始日和前一日作為下單日的測試案例並進行了測試。
エ 為了確認當輸入值組合無效時不產生單據，測試了幾個具代表性的輸入值組合，並根據結果反覆建立新的測試案例進行測試。
探索性測試是一種在測試過程中動態設計和執行測試的方式，不依賴事先確定的測試案例，而是基於對系統的理解和觀察結果即時調整測試方案。探索性測試的特點在於測試案例並非完全預設，而是根據測試結果不斷調整和補充。
ア、イ、ウ 選項中測試案例都是事先建立好的，符合傳統的事前設計測試，不符合探索性測試的特點。所以正確答案是 エ。