2024年下半年系統架構設計師案例

題：效用樹+可用性中ping/echo策略和心跳策略比較

第1題

閱讀以下關于面向質量屬性的軟件架構設計的敘述，回答問題1和問題2。
【說明】
某公司擬開發一個基于大語言模型的智能系統，該系統將通過多個大語言模型來協作處理用戶提交的任務請求，任務求解過程的狀態數據將被記錄在任務板中，各個大語言模型根據任務板上任務的實時求解狀態，來確定它們當前是否需要被調用以進一步處理該任務，并在處理完成之后將任務的最新狀態更新到任務板上。
基于該系統的開發任務，公司召開項目討論會。會上，項目組介紹了系統需求，主要包括：
(a)系統可支持用戶在任務板上查看任務的狀態和結果，并允許用戶多次調用大型語言模型以進一步優化處理結果。
(b)系統可支持任務數據的導入導出，數據導入導出在1分鐘內完成
(?)在數據服務器發生故障時，系統應能夠立刻切換到備份服務器，并保證數據同步，以確保系統的不間斷的服務。
(d)在系統正常負荷情況下，用戶在任務板上查詢任務狀態和結果的響應時間應在2秒內。
(e)系統應確保用戶數據和操作記錄的安全，防止未經授權的訪問。
(f)系統需要支持多語言接口，并提供查詢詞自動補全和搜索關聯功能。
(g)系統應支持擴容，以容納更多的用戶和任務。擴容需求的實現應在兩名運維人員工作的情況下在5天內完成。
(h)系統部署在云服務器上。當云服務器出現故障時，系統應在1分鐘內檢測出故障，并在1小時之內恢復。
(i)系統支持根據用戶任務類型調用相應的大語言模型對任務進行處理。
(j)用戶可以在任務板上搜索歷史任務和結果，搜索結果應在3秒內返回。
【問題1】(14分)
為了輔助架構師張工完成系統架構設計，首先需要對上述需求進行分析。請分析需求(a)-(g)，補充完善下表中(1)~(7)的空白處。

【問題2】(11分)
針對需求可用性需求(h)，張工提出可采用ping/echo策略完成故障檢測，但李工認為從系統資源利用率的角度出發，采用心跳策略完成故障檢測更優。
(1)請分別說明如何采用ping/echo策略和心跳策略來完成可用性的故障檢測;
(2)請解釋李工認為心跳策略更優的原因。

【問題1】
(1)性能
(2)性能
(3)安全性
(4)功能性
(5)可修改性
(6)功能性
(7)性能

【問題2】
(1)ping/echo故障檢測：ping/echo通過發送ping請求報文給目標主機，并等待其回應來檢測網絡連通性。如果收到回應，則表明網絡通路正常；如果未收到回應或超時，則可能表示網絡存在問題或目標主機不可達。
心跳故障檢測：心跳機制通過節點間定期發送心跳信號來檢測各節點的狀態。如果連續一段時間內未收到某個節點的心跳信號，則判定該節點出現故障或失聯，并觸發相應的故障恢復或切換操作。這種方式常用于分布式系統中，以確保系統的高可靠性和穩定性。
(2)資源消耗較少：心跳模式通常是由被監控組件主動、周期性地向監控組件發送簡短的消息，以表明其正在正常運行。這種方式相比ping echo更為高效，因為ping echo需要監控組件定時向被監控組件發送請求，并等待回應，這增加了網絡流量和處理器資源的消耗。另外心跳模式使用的是長連接，而pig使用的是短連接。
降低網絡負載：由于心跳消息通常較短且發送頻率相對較低（根據系統需求設定），因此它們對網絡帶寬的占用較少。相比之下，ping echoi可能需要更頻繁地發送和接收消息，從而增加了網絡的負載。
故障檢測效率更快：心跳模式能夠更快速地檢測到故障或失聯的節點。因為心跳消息是周期性發送的，所以一旦某個節點出現故障或無法發送心跳消息，監控組件就能立即察覺并采取相應的措施。而pig/echo雖然也能用于故障檢測，但其響應時間和檢測效率可能受到網絡延遲和消息丟失等因素的影響。

(1) 故障檢測策略
ping/echo 策略：
方法：監控節點每 5 秒向云服務器發送 ping 請求（ICMP Echo Request），連續 3 次無回應（約 15 秒）判定故障，觸發切換或通知。
特點：簡單易實現，但頻繁 ping 占用網絡和服務器資源，易受網絡抖動誤判，僅驗證網絡可達性。
心跳策略：
方法：云服務器每 5 秒主動向監控節點發送心跳包（含服務狀態，如 LLM API），連續 3 次未收到（約 15 秒）判定故障，觸發切換或通知。
特點：服務器主動發送，資源占用低，可攜帶服務狀態，抗網絡抖動，適合復雜系統。
(2) 心跳策略更優的原因
低資源占用：心跳由服務器單向發送，監控節點被動接收，請求量隨節點數線性增長（N 臺服務器 N 次心跳）；ping/echo 需雙向請求，流量高（多節點互 ping 呈平方增長）。
高準確性：心跳包可包含服務狀態（如 LLM API 是否正常），檢測更精準；ping 僅驗證網絡，無法確認服務狀態。
低誤判率：心跳使用 TCP/UDP，抗網絡抖動；ping 易受 ICMP 阻擋或延遲誤判。
擴展性：心跳適合大規模系統（如 1000 臺服務器）；ping 請求隨節點增加導致網絡擁塞。
電商背景：心跳支持高并發（5000 用戶）、高可用性（99.9%），確保任務板無中斷，滿足 15 秒檢測要求。

【架構-31】各架構風格對比

2022年下半年系統架構設計師案例

題：效用樹+面向對象與解釋器風格比較

第1題

試題一是必答題
閱讀以下關于軟件架構設計與評估的敘述，在答題紙上回答問題1和問題2。
【說明】
某電子商務公司擬升級其會員與促銷管理系統，向用戶提供個性化服務，提高用戶的粘性。在項目立項之初，公司領導層一致認為本次升級的主要目標是提升會員管理方式的靈活性，由于當前用戶規模不大，業務也相對簡單，系統性能方面不做過多考慮。新系統除了保持現有的四級固定會員制度外，還需要根據用戶的消費金額、偏好、重復性等相關特征動態調整商品的折扣力度，并支持在特定的活動周期內主動篩選與活動主題高度相關的用戶集合，提供個性化的打折促銷活動。
//
在需求分析與架構設計階段，公司提出的需求和質量屬性描述如下：
//
(a)管理員能夠在頁面上靈活設置折扣力度規測和促銷活動邏輯，設置后即可生效；
(b)系統應該具備完整的安全防護措施，支持對惡意攻擊行為進行檢測與報警；
( c) 在正常負載情況下，系統應在0.3秒內對用戶的界面操作請求進行響應：
(d)用戶名是系統唯一標識，要求以字母開頭，由數字和字母組合而成，長度不少于6個字符：
(e)在正常負載情況下，用戶支付商品費用后在3秒內確認訂單支付信息；
(f)系統主站點電力中斷后，應在5秒內將請求重定向到備用站點：
(g)系統支持橫向存儲擴展，要求在2人天內完成所有的擴展與測試工作：
(h)系統宕機后，需要在10秒內感知錯誤，并自動啟動熱備份系統：
(i)系統需要內置接口函數，支持開發團隊進行功能調試與系統診斷：
(j)系統需要為所有的用戶操作行為進行詳細記錄，便于后期查閱與審計：
(k)支持對系統的外觀進行調整和配置，調整工作需要在4人天內完成。
//
在對系統需求、質量屬性描述和架構特性進行分析的基礎上，系統架構師給出了兩種候選的架構設計方案，公司目前正在組織相關專家對系統架構進行評估。
【問題1】(12分)
在架構評估過程中，質量屬性效用樹(utility tree)是對系統質量屬性進行識別和優先級排序的重要工具。請將合適的質量屬性名稱填入圖1-1中(1)、(2)空白處，并選擇題干描述的(a)-(k)填入(3)~(6)空白處，完成該系統的效用樹。
//
【問題2】(13分)
針對該系統的功能，李工建議采用面向對象的架構風格，將折扣力度計算和用戶篩選分別封裝為獨立對象，通過對象調用實現對應的功能；王工則建議采用解釋器(interpreters)架構風格，將折扣力度計算和用戶篩選條件封裝為獨立的規則，通過解釋規測實現對應的功能。請針對系統的主要功能，從折扣規測的可修改性、個性化折扣定義靈活性和系統性能三個方面對這兩種架構風格進行比較與分析，并指出該系統更適合采用哪種架構風格。

我的答案：
問題1：
（1）安全性
（2）可修改性
（3)e
（4）j
（5）h
（6）k

問題2：
折扣規則的可修改性方面：面向對象的架構風格，當折扣規則修改時，需要修改對應對象的方法，然后重新調用；而解釋器風格，修改對應的規則即可，通過解釋規則實現功能；解釋器風格可修改性更強。
個性化折扣定義靈活性方面：面向對象的架構風格，需要將折扣定義須在類中個性化折扣的方法，然后重新調用；
而解釋器風格，可預先自定義定多種折扣，更加方便靈活；
系統性能方面：面向對象的架構風格，經過創建類對象，然后調用方法，性能開銷大；而解釋器風格，利用解釋引擎解釋規則實現對應功能，針對特定的規則來實現，性能開銷小；
綜上，該系統更適用解釋器風格

參考解析1：
【問題1】本題主要考查考生對軟件架構評估、軟件質量屬性以及架構評估中相關概念的理解與掌握。考生應該在熟記基礎概念的基礎上結合實際問題靈活掌握并應用這些概念。在解答本題時，首先需要對題干中的所有軟件需求描述進行分析與梳理，區分并找出其中的需求分析、軟件質量屬性描述，或者可能的風險、權衡點或敏感點描述。

具體列舉如下：
(a)管理員能夠在頁面上靈活設置折扣力度規側和促銷活動邏輯，設置后即可生效，對應易用性屬性。
(b)系統應該具備完整的安全防護措施，支持對惡意攻擊行為進行檢測與報警，對應安全性屬性。
?在正常負載情況下，系統應在0.3秒內對用戶的界面操作請求進行響應；對應性能屬性。
(d)用戶名是系統唯一標識，要求以字母開頭，由數字和字母組合而成，長度不少于6個字符，對應系統的設計約束。
(e)在正常負載情況下，用戶支付商品費用后在3秒內確認訂單支付信息，對應性能屬性。
(f)系統主站點電力中斷后，應在5秒內將請求重定向到備用站點，對應可用性屬性
(g)系統支持橫向存儲擴展，要求在2人天內完成所有的擴展與測試工作，對應可修改性屬性。
(h)系統宕機后，雲要在10秒內感知錯誤，并自動啟動熱備份系統，對應可用性屬性
(i)系統需要內置接口函數，支持開發團隊進行功能調試與系統診斷，對應可測試性屬性。
(j)系統需要為所有的用戶操作行為進行詳細記錄，便于后期查閱與審計，對應安全性屬性。
(k)支持對系統的外觀進行調整和配置，調整工作需要在4人天內完成，對應可修改性屬性。

【問題2】在解答本題時，需要從可修改性、靈活性和系統性能三個方面進行綜合考慮。
從可修改性來看，解釋器風格折扣規則是獨立的語法規測，由解釋器可對變化的規則進行解析，修改更容易。而面向對象相對固定，有變化需要修改具體的類。
從靈活性來看，解釋器可以根據用戶靈活解釋執行規則，優于面向對象。
從系統性能來看，面向對象優于解釋器。綜合三個方面來看，解釋器的優勢更大，所以該系統更適合采用解釋器風格。

解釋器可修改性:
面向對象風格通過編寫新的規則實現代碼，并通過應用重啟或熱加載添加規則，可修改性稍差;解釋器風格通過編寫新的規則文件，并通過導入資源文件或外部配置添加規則，可修改性較好。
靈活性:
面向對象風格通過策略模式定義規則對象，規則以程序邏輯實現，靈活性較差，解釋器風格可靈活定義規則計算表達式，靈活性更好。
性能:
面向對象風格以編譯后代碼運算規則，性能好;而虛擬機風格需要加載規則，解析規則，規則運算,再得出結果，性能較差。
從項目關注點來看，系統性能不做過多考慮，則王工建議的解釋器風格較為合適;
||
v

折扣規則的可修改性：
面向對象風格：折扣規則和用戶篩選邏輯封裝在對象中（如 DiscountCalculator 類）。修改規則需更改代碼、重新編譯、測試、部署，通常需要開發人員介入，修改成本高，可修改性較低。
解釋器風格：規則定義為腳本文件（如 JSON 或 DSL），管理員通過界面上傳或修改規則，系統動態解析并立即生效，無需重啟，修改成本低，可修改性高。
優勢：解釋器更優，滿足管理員靈活設置規則的需求（(a)）。
個性化折扣定義靈活性：
面向對象風格：通過對象方法（如策略模式或繼承）實現規則，新增個性化規則（如基于生日折扣）需開發新代碼，靈活性受限，難以支持管理員定義復雜邏輯。
解釋器風格：支持復雜規則腳本，管理員可定義動態條件（如“消費 > 1000 且偏好電子產品，折扣 20%”），靈活性高，滿足個性化促銷需求。
優勢：解釋器更優，支持任意規則組合。
系統性能：
面向對象風格：通過編譯后的代碼直接執行規則，執行效率高，響應時間短（如微秒級），適合高負載場景。
解釋器風格：需加載和解析規則腳本，執行開銷較大（如毫秒級），性能稍低，但可通過緩存解析結果優化，滿足 0.3 秒響應和 3 秒支付確認的要求。
優勢：面向對象性能更優，但解釋器性能足夠。
結論：

題目強調靈活性為主要目標（管理員動態設置規則，個性化促銷），性能要求不高（小規模用戶，0.3 秒和 3 秒寬松）。解釋器風格在可修改性和靈活性上顯著優于面向對象，支持動態規則調整，滿足核心需求。盡管性能稍低，但足以應對當前規模。因此，王工建議的解釋器架構風格更適合

第2題

閱讀以下關于軟件系統設計與建模的敘述，在答題紙上回答問題1至問題3。
【說明】
煤炭生產是國民經濟發展的主要領域之一，其煤礦的安全非常重要。某能源企業擬開發一套煤礦建設項目安全預警系統，以保護煤礦建設項目從業人員生命安全。本系統的主要功能包括如下(a)～(h)所述。
(a)項目信息維護
(b)影響因素錄入
?關聯事故錄入
(d)安全評價得分
(e)項目指標預警分析
(f)項目指標填報
(g)項目指標審核
(h)項目指標確認


【問題3】(7分)
在結構化分析和設計過程中，數據流圖和數據字典是常用的技術手段，請用200字以內的文字簡要說明它們在軟件需求分析和設計階段的作用。

我的回答：
問題1：
（1）f
（2）g
（3）h
（4）d
（5）b
（6）e
數據平衡原則：
1）父圖和子圖間的數據平衡：父圖中出現的數據流，應該在子流中也要出現；
2）子圖中的數據平衡：加工有輸入和輸出，加工描述了輸入數據經過變化得到了輸出數據；

問題2：
（1）項目管理員
（2）項目經理
（3）項目指標
（4）安全評價
（5）影響因素
（6）項目指標預警

問題3：
數據字典：數據字典描述并標識了數據流圖中各個元素的作用，功能以及名稱。在需求分析階段，用于完善數據流圖以及相關圖的建立，在設計階段，對軟件設計的各個元素信息進行參考；
數據流圖：數據流圖由外部實體、加工、存儲、數據流組成，描述了外部實體與數據流的交互，反映了軟件系統的功能性需求，在設計階段，用于指導軟件系統設計；

【問題1】
(1) f
(2) g
(3) h
(4) d
(5) b
(6) e
分層細化的數據平衡原則：
1、子圖與父圖之間的平衡：
（1）父圖與子圖之間平衡是指任何一張DFD子圖邊界上的輸入輸出數據流必須與其父圖對應加工的輸入/輸出數據流保持一致。
(2）如果父圖中某個加工的一條數據流對應于子圖中的幾條數據流，而子圖中組成這些數據流的數據項全體正好等于父圖中的這條數據流，那么它們仍然是平衡的。
2、子圖內部：加工的輸入和輸出需要平衡。每個加工必須有輸入數據流和輸出數據流，反映此加工的數據來源和加工變換結果。

【問題2】
（1）項目管理員
(2）項目經理
（3）項目指標數據
（4）～（6）指標參數、項目信息、事故及影響因素參數

【問題3】
（1）在軟件需求分析階段：
數據流圖主要用于建立軟件的功能模型，以圖形化方式呈現業務數據的流動和處理過程**。
數據字典是關于數據的信息集合，用于對數據流圖中每個組成部分加以定義和說明。
(2）在軟件設計階段：
數據流圖為模塊劃分與模塊之間接口設計提供依據，數據流圖主要用于經過一系列設計轉換后，產生由模塊圖表示的軟件設計模型；詳細設計階段數據流圖可進行模塊內部的數據流設計。
數據字典用于描述系統中各類數據，為數據庫概要設計、邏輯設計提供支持。

2021年下半年系統架構設計師案例

題：效用樹+管道過濾器風格，隱式調用風格與解釋器風格比較

第1題

閱讀以下關于軟件架構設計與評估的敘述，回答問題1和問題2。
【說明】
某公司擬開發一套機器學習應用開發平臺，支持用戶使用瀏覽器在線進行基于機器學習的智能應用開發活動。
該平臺的核心應用場景是用戶通過拖拽算法組件靈活定義機器學習流程，采用自助方式進行智能應用設計、實現與部署，并可以開發新算法組件加入平臺中。在需求分析與架構設計階段，公司提出的需求和質量屬性描述如下：
(a)平臺用戶分為算法工程師、軟件工程師和管理員等三種角色，不同角色的功能界面有所不同；
(b)平臺應該具備數據庫保護措施，能夠預防核心數據庫被非授權用戶訪問；
(?)平臺支持分布式部署，當主站點斷電后，應在20秒內將請求重定向到備用站點；
(d)平臺支持初學者和高級用戶兩種界面操作模式，用戶可以根據自己的情況靈活選擇合適的模式；
(e)平臺主站點宕機后，需要在15秒內發現錯誤并啟用備用系統；
(f)在正常負載情況下，機器學習流程從提交到開始執行，時間間隔不大于5秒：
(g)平臺支持硬件擴容與升級，能夠在3人天內完成所有部署與測試工作；
(h)平臺需要對用戶的所有操作過程進行詳細記錄，便于審計工作：
(i)平臺部署后，針對界面風格的修改需要在3人天內完成；
(j)在正常負載情況下，平臺應在0.5秒內對用戶的界面操作請求進行響應；
(k)平臺應該與目前國內外主流的機器學習應用開發平臺的界面風格保持一致：
(l)平臺提供機器學習算法的遠程調試功能，支持算法工程師進行遠程調試。
在對平臺需求、質量屬性描述和架構特性進行分析的基礎上，公司的架構師給出了三種候選的架構設計方案，公司目前正在組織相關專家對平臺架構進行評估。
【問題1】(9分)
在架構評估過程中，質量屬性效用樹(utility tree)是對系統質量屬性進行識別和優先級排序的重要工具。請將合適的質量屬性名稱填入圖1-1中(1)、(2)空白處，并從題干中的(a)-(l)中選擇合適的質量屬性描述，填入(3)-(6)空白處，完成該平臺的效用樹。

【問題2】(16分)
針對該系統的功能，趙工建議采用解釋器(interpreter)架構風格，李工建議采用管道過濾器(pipe-and-fter)的架構風格，王工則建議采用隱式調用(implicit invocation)架構風格。請針對平臺的核心應用場景，從機器學習流程定義的靈活性和學習算法的可擴展性兩個方面對三種架構風格進行對比與分析，并指出該平臺更適合采用哪種架構風格。

我的回答：
問題1：
(a) 功能性需求
(b) 安全性
? 可用性
(d) 功能性需求
(e) 可用性
(f) 性能
(g) 可修改性
(h) 安全性
(i) 可修改性
(j) 性能
(k) 功能性需求
(l) 可測試性

（1）性能 （2）可修改性 （3）（e) （4）（j) （5）（h) (6) (i)

問題2：
從機器學習流程定義的靈活性來看：
管道過濾器風格通過管道連接各個過濾器，順序執行各個過濾器，來進行流程定義，流程定義依賴于前一個過濾器，定義方式不夠靈活；隱式調用風格通過事件觸發來進行相應的流程定義，依賴于特定事件的觸發，定義方式也不夠靈活；而解釋器風格通過動態定義解釋規則來確定流程的定義，方便用戶自定義，以及增添改查，靈活性最強；
從學習算法的可擴展性來看：
管道過濾器風格支持多個過濾器并行執行算法組件從而執行多個學習算法，但此多個算法組件均依賴于前一個組件，算法組件擴展時需要與前一個組件相關，其擴展性受限；隱式調用風格通過事件觸發，可以將該事件廣播給多個組件使用，組件通過訂閱這個事件來進行算法的執行。解釋器風格通過用戶自定義添加運行規則，方便算法組建的添加，可擴展性較好；
綜上，考慮到該系統對靈活性和可擴展性的要求，該平臺更適合用解釋器風格。

【問題1】
(1)性能
(2)可修改性
(3)(e)可用性
(4)(j)性能
(5)(h)安全性
(6)(i)可修改性
【問題2】
本題系統中有多個應用場景提到了系統分角色有不同的操作流程與界面，以及在修改擴充系統時，需要能夠在限定時間內快速完成任務。基于這樣的情況，我們從兩方面進行分析：

解釋器：機器學習流程定義的靈活性高，學習算法的可擴展性強。因為解釋器風格可以通過自定義流程規則及配套流程解釋引擎開發，做到用戶層面的流程完全定義，而不需要修改代碼，所以無論是修改已有的業務流程，還是要擴展不同的角色，創建新角色的流程都非常便利。解釋器按照輸入輸出格式將學習算法封裝為組件，通過解釋器機制動態增加或刪除算法組件，并支持動態調用，學習算法的可擴展性強。

管道過濾器：機器學習流程定義的靈活性低，學習算法的可擴展性弱。因為管道過濾器是把數據處理職能做成過濾器，把數據傳遞做成管道，此時如果流程不發生變化，是可以通過這種方式實現的，但一旦流程變化，或是擴展功能，需要對過濾器進行修改調整，或是流程在程序層面重建，此時必須修改代碼完成任務。管道過濾器按照輸入輸出格式將學習算法封裝為組件，如果需要增加或刪除組件，需要停止平臺并進行重新部署，學習算法的可擴展性弱。

隱式調用：機器學習流程定義的靈活性一般，學習算法的可擴展性一般。隱式調用強調的是通過間接方式進行調用，如采用事件機制，要完成某個動作時先觸發事件，事件與相關動作關聯，以提升靈活度，本題中可把角色執行業務的流程用事件觸發。這種做法比管道過濾器強，但弱于完全自定義的解釋器。隱式調用按照輸入輸出格式將學習算法封裝為處理函數，支持動態增加和刪除函數，學習算法的可擴展性一般。

經過綜合比較與分析，可以看出該系統更適合使用解釋器風格。
系統架構設計師考試題庫重點案例：軟件架構設計與評估

第2題

閱以下關于軟件系統設計與建模的敘述，回答問題1至問題3。
【說明】
某醫院擬委托軟件公司開發一套預約掛號管理系統，以便為患者提供更好的就醫體驗，為醫院提供更加科學的預約管理。本系統的主要功能描述如下：(a)注冊登錄，(b)信息瀏覽，?賬號管理，(d)預約掛號，（e）查詢與取消預約，(f)號源管理，(g)報告查詢，(h)預約管理，(i)報表管理和(j)信用管理等。
【問題1】(6分)
若采用面向對象方法對預約掛號管理系統進行分析，得到如圖21所示的用例圖。請將合適的參與者名稱填入圖21中的(1)和(2)處.使用題干給出的功能描術(a)-(j),完善用例(3)~(12)的名稱

(問題2】(10分)
預約人員（患者）登錄系統后發起預約掛號請求，進入預約界面。進行預約掛號時使用數據庫訪問類獲取醫生的相關信息，
在數據庫中調用醫生列表，并調取醫生出診時段表，將醫生出診時段反饋到預約界面，并顯示給預約人員；預約人員選擇醫
生及就診時間后確認預約，系統反饋預約結果，并向用戶顯示是否預約成功。
采用面向對象方法對預約掛號過程進行分析，得到如圖2-2所示的順序圖，使用題干中給出的描述，完善圖2-2中對象(1)，及消息(2)~(4)的名稱，請簡要說明在描述對象之間的動態交互關系時，協作圖與順序圖存在哪些區別。

【問題3】(9分)
采用面向對象方法開發軟件，通常需要建立對象模型、動態模型和功能模型，請分別介紹這3種模型，并詳細說明它們之間的關聯關系，針對上術模型，說明哪些模型可用于軟件的需求分析？

我的回答：
問題1：
（1）患者
（2）預約掛號管理系統
（3）c
（4）a
（5）b
（6）d
（7）e
（8）g
（9）f
（10）h
（11）i
（12）j

問題2：
（1）預約人員
（2）發起預約掛號請求
（3）顯示醫生可預約時間段
（4）顯示是否預約成功

協作圖與順序圖的區別：

交互方式不同：順序圖是描述了對象之間順序的交互關系，協作圖則描述了對象間交互協作關系，交互關系不是順序的，不強調時間上的順序
消息格式不一樣：順序圖有返回消息，調用消息等，而協作圖沒有返回消息等

問題3：
對象模型：描述了對象之間的靜態關系，如類圖反映了一組類與接口的關系，對象圖是類圖的靜態快照，描述了對象與對象間的靜態關系
動態模型：描述了對象之間的動態交互關系，如順序圖是描述了對象之間順序的交互關系，協作圖則描述了對象間交互協作關系，交互關系不是順序的，不強調時間上的順序，定時圖，則描述了各個對象交互時的特定時間節點。
功能模型：描述了用戶設計類或對象時所需實現的功能，如用例圖描述了用例與參與者間的關系，用例就是一個功能，反應了開發軟件所需的功能

關聯聯系：采用面向對象方法開發軟件時，首先建立功能模型，將實際場景功能，轉換為功能模型，讓開發者明確軟件具體功能，然后根據功能模型來實現動態模型，反映描述了對象之間的動態交互關系，最后將抽象的功能模型以及動態模型轉換為對象模型，從而設計程序中所需要的類和對象

功能模型可用于需求分析

【問題1】
該問考查UL中的用例圖填充，首先根據題意可以分析出患者這個參與者。而另一個參與者題目沒有明示，然而
從號源管理、預約管理等用例來看，定性為“醫院管理員”較為合適，醫院管理員是一個系統中比較常見的角色，起
系統管理職能。
然后通過用例的名稱來分析判斷哪些用例歸屬于患者哪些歸屬于醫院管理員，按這個羅輯很容易分析出：
患者：(a)注冊登錄(b)信息瀏覽?賬號管理(d)預約掛號(e)查詢與取消預約(g)報告查詢
醫院管理員：(a)注冊登錄(f)號源管理(h)預約管理()報表管理()信用管理
從而根據圖中參與者對應的用例數給參與者和用例定位到具體的空中。
【問題2】
該問考查UML中的順序圖，本問比較容易，緊扣題目描述來組織內容即可，從題干中“預約人員（患者）登錄系統后發起預約掛號請求，進入預約界面”的信息可知(1)應為預約人員（患者），(2)為預約掛號請求；從題干中“將醫生出診時段反饋到預約界面，并顯示給預約人員”的信息可知(3)應為顯示醫生可預約時段；從題干中“系統反饋預約結果，并向用戶顯示是否預約成功”的信息可知(4)應為顯示預約是否成功。序列圖（順序圖）是用來顯示你的參與者如何以一系列順序的步驟與系統的對象交互的模型。
順序圖可以用來展示對象之間是如何進行交互的。順序圖將顯示的重點放在消息序列上，即強調消息是如何在對象之間被發送和接收的。
協作圖，和序列圖相似，顯示對象間的動態合作關系。可以看成是類圖和順序圖的交集，協作圖建模對象或者角色，以及它們彼此之間是如何通信的。如果強調時間和順序，則使用序列圖；如果強調上下級關系或對象間組織結構，則選擇協作圖。
【問題3】
該問考查了一個較為早期提出的面向對象模型一OMT。
OMT方法的OOA模型包括對象模型、動態模型和功能模型
對象模型表示靜態的，結構化的“數據”性質，它是對模擬客觀世界實體的對象及對象間的關系映射，描述了系統的靜態及結構。通常用類圖表示。對象模型描述系統中對象的靜態結構、對象之間的關系、對象的屬性、對象的操作。對象模型表示靜態的、結構上的、系統的“數據”特征。對象模型為動態模型和功能模型提供了基本的框架。對象模型用包含對象和類的對象圖來表示。

動態模型表示瞬間的，行為化的系統控制性質，它規定了對象模型中的對象合法化變化序列。通常用狀態圖表示。動態模型描述與時間和操作順序有關的系統特征一激發事件、事件序列、確定事件先后關系的狀態以及事件和狀態的組織。動態模型表示瞬間的、行為上的、系統的“控制”特征。動態模型用狀態圖來表示，每張狀態圖顯示了系統中一個類的所有對象所允許的狀態和事件的順序。

功能模型表示變化的系統的功能性質，它指明了系統應該做什么，因此直接地反映了用戶對目標系統的需求，通常用數據流圖表示。功能模型描述與值變換有關的系統特征一功能、映射、約束和函數依賴。

對象模型用于描述系統數據結構；動態模型用于描述系統控制結構；功能模型用于描述系統功能。
這3種模型都涉及數據、控制和操作等共同的概念，但側重，點不同，從不同側面反映了系統的實質性內容，綜合起來全面地反映了對目標系統的需求。
功能模型指明了系統應該“做什么”；動態模型明確規定了什么時候做；對象模型則定義了做事情的實體。
對象模型、動態模型和功能模型均可用于軟件的需求分析。

軟考高項UML的14種圖詳解
軟考高級《系統架構設計師》UML圖的總結與真題解析
05 對象建模技術OMT