提示：文章寫完后，目錄可以自動生成，如何生成可參考右邊的幫助文檔
文章目錄
- 前言
- 試題一 軟件架構設計
- 一、2019年 案例分析
- 二、2020年 案例分析
- 三、2021年 案例分析
- 四、2022年 案例分析
- 試題二 軟件系統設計
- 一、2019年 案例分析
- 二、2020年 案例分析
- 三、2021年 案例分析
- 四、2022年 案例分析
- 試題五 Web系統設計
- 一、2019年 案例分析
- 二、2020年 案例分析
- 三、2021年 案例分析
- 四、2022年 案例分析
- 試題三、數據庫系統設計
- 一、 2019年 案例分析
- 二、2020年 案例分析
- 三、 2021年 案例分析
- 四、2022年 案例分析
- 總結
前言
試題一 軟件架構設計
一、2019年 案例分析
答案解析：
(1) 將用戶級別、折扣規則等與系統啟動時加載的固定數據相結合，適用于基于規則的架構風格。面向對象架構適合這種靜態數據加載及規則的執行。
(2) 對新用戶級別和折扣規則的支持要求增加新對象，并需重新啟動系統，這表明基于規則的架構風格適合動態的需求變更，而不是硬編碼規則。
(3) 系統需要支持用戶的動態請求，尤其是在折扣規則更新和變更時，要求系統可以在線加載并實時應用這些規則，說明采用面向對象架構風格更為合適，能夠靈活擴展，允許變動數據的快速處理。
架構風格的選擇：根據需求分析，基于規則架構風格適合動態變化的需求，能夠靈活應對用戶級別和折扣規則的變化；面向對象架構風格能夠提供更高的靈活性，并且能更好地處理用戶請求和數據變動。
效用樹的使用：效用樹是質量屬性分析的工具，它幫助系統設計者明確目標，并通過各層級的屬性來優化系統的性能、可用性和安全性。
二、2020年 案例分析
三、2021年 案例分析
四、2022年 案例分析
解釋器風格屬于虛擬機風格中的子風格，重點是“自定義”。
試題二 軟件系統設計
一、2019年 案例分析
二、2020年 案例分析
三、2021年 案例分析
四、2022年 案例分析
項目信息表、指標參數表等是右邊開放的矩形，用于存儲使用，和實體有所區別。
試題五 Web系統設計
一、2019年 案例分析
閱讀以下關于web系統架構設計的敘述，在答題紙上回答問題1至問題四。
問題1
答案
性能：(1)、(2)、(6)
安全性：(5)
可用性：(3)、(7)
易用性：(4)、(8)
解釋
(1) 支持>50個終端設備并發 → 典型吞吐/并發性能指標。
(2) 識別時間小于1s → 典型響應時間要求，屬于性能。
(6) 獨立事務響應時間<3s → 也是時延/響應性能約束。
(5) 防御SQL注入 → 明確是安全性要求。
(3) 7×24小時、(7) 故障1小時內恢復 → 強調持續提供服務與故障恢復，屬于可用性/可靠性。
(4) 良好用戶界面、(8) 新用戶半天上手 → 強調易學易用與界面友好，屬于易用性。
問題2
答案
(1)→(d) 表現層
(2)→(e) HTTP協議
(3)→(i) 業務處理層
(4)→(h) 分布式通信處理層
(5)→(g) Kafka分發消息
(6)→(f) Redis數據緩存
(7)→(a) 數據存儲層
解釋
(1 頂層 HTML/CSS) 就是前端表現層(d)。
(2 箭頭位于前端與后端之間) 前后端交互采用HTTP協議(e)。
(3 Spring 容器 / Spring MVC) 承擔控制與業務編排，放在*業務處理層(i)*最合適（備選中沒有“控制層”，因此歸于業務層）。
(4 數據處理與“非實時請求”) 表示跨進程/跨節點的協作，屬于分布式通信處理層(h)。
(5 長條隊列形狀) 對應消息分發/隊列——Kafka(g)，支撐“非實時請求”。
(6 小塊緩存) 是Redis數據緩存(f)，加速讀寫、減輕數據庫壓力。
(7 最底部 MySQL) 典型數據存儲層(a)。
問題3
SQL注入是指：攻擊者把惡意的SQL片段混入到應用接收的輸入（表單、URL參數、請求體等）中，使服務器在構造并執行查詢時把這些片段當成合法SQL執行，從而竊取/篡改數據或控制數據庫。
常見有效防護（舉兩種即可，這里多給幾種便于理解）：
-
參數化查詢/預編譯語句（PreparedStatement/ORM綁定變量）——不把用戶輸入拼到SQL字符串里。
-
最小權限原則（應用賬戶只授予必須的讀寫權限，禁用危險操作）。
-
使用存儲過程/視圖做受控訪問（注意也需參數化）。
-
使用正則表達式
-
檢查用戶輸入的合法性
二、2020年 案例分析
答案解析：
問題1
性能 (Performance)
性能要求包括響應時間、吞吐量等。比如要求 系統響應時間小于1秒，這是典型的性能要求。
對應選擇 (b)，(a)。
安全性 (Security)
安全性要求包括防止攻擊、保護用戶數據等。比如要求 防止SQL注入、提供有效的用戶認證。
對應選擇 (d)，(f)。
可用性 (Availability)
可用性要求包括系統的持續運行能力、容錯機制等。例如，要求 系統故障時1小時內恢復，這是典型的可用性需求。
對應選擇 (c），(e)。
問題2
) a → Connection Pool（連接池）
連接池用于管理數據庫連接的獲取與釋放，通常由像 HikariCP 或 C3P0 這樣的數據庫連接池組件來實現。它確保系統在執行數據庫操作時不會頻繁創建和銷毀連接，提高性能。
(2) c → Persistent Layer（持久層）
持久層用于與數據庫進行交互。在SSM框架中，通常是 MyBatis，用于處理數據庫的增刪改查操作，將數據庫表映射為Java對象。
(3) d → MyBatis
MyBatis 是一個持久層框架，它通過 XML 配置文件或注解與數據庫進行交互，執行數據庫查詢并將結果映射為對象。
(4) k → Spring
Spring 是一個開源的輕量級框架，提供了依賴注入和面向切面的編程。它管理整個應用程序的生命周期，負責業務邏輯層和數據訪問層之間的協調。
(5) j → Controller Layer（控制器層）
控制器層 是 Spring MVC 的一部分，負責處理用戶的請求，將數據傳遞給服務層并返回結果給用戶。
(6) h → View Layer（視圖層）
視圖層 負責將業務邏輯的數據展示給用戶。在SSM中，常見的視圖層技術是 JSP、Thymeleaf 等。
(7) i → JSP
JSP（Java Server Pages） 是一種動態網頁技術，允許將 Java 代碼嵌入 HTML 頁面中，通常用于顯示數據和用戶交互界面。
該問題要求根據SSM框架（Spring + SpringMVC + MyBatis）工作流程圖，填充對應的層次和組件。根據圖5-1，可以填入下列內容：
(a) Connection Pool：用于數據庫連接的池化管理。
(b) Struts2：如果是需要處理表單或頁面請求的部分，可能涉及Struts2框架，但通常在SSM中以SpringMVC代替。
(c） Persistent Layer：持久層，通常使用MyBatis處理數據庫的交互。
(d) MyBatis：ORM框架，負責數據映射和數據庫交互。
(e) HTTP：請求/響應通過HTTP協議進行通信。
(f) Spring：提供依賴注入、事務管理等核心功能。
(g) Kafka：用于消息隊列和分布式數據流。
(h) ViewLayer：視圖層，負責呈現數據，通常通過JSP或者Thymeleaf渲染。
(i) JSP：JavaServer Pages，用于生成動態HTML頁面。
(j) Controller Layer：SpringMVC的控制器層，處理用戶請求和響應。
(k) Spring：負責請求的分發和控制。
連接池（a）管理數據庫連接，持久層（c）負責數據庫操作，MyBatis（d）負責數據的映射與交互，Spring（k）管理框架和依賴，控制器層（j）處理用戶請求，視圖層（h）負責頁面展示，JSP（i）用于實際的頁面渲染。
圖中的 POJO 代表的是 Plain Old Java Object（普通的舊版 Java 對象），它是 Java 編程中一種常見的簡單對象模型。
問題3
通過使用標準化的數據訪問機制，可以統一不同設備的數據交互方式，這樣解決了數據結構的不一致性。標準化的數據訪問減少了數據結構和應用系統的耦合度，提升了數據處理的靈活性，同時減少了系統維護的工作量。通過采用中間件技術，如 Web服務、消息隊列，能夠實現設備間數據的高效傳輸，并保證數據一致性和系統擴展性。
三、2021年 案例分析
四、2022年 案例分析
試題三、數據庫系統設計
一、 2019年 案例分析
二、2020年 案例分析
三、 2021年 案例分析
四、2022年 案例分析
總結
2022年之前的案例分析題，比較有規律，有的題目都一樣。但機考后真題變化較大，有許多超綱題，但只要根據自己的理解寫滿，應該也能過。機考后真題不好拿出來，所有市面上真題較少，幾乎沒有。
)
