下午題總結
- 1 試題一
- 1.1 結構化語言
- 2 試題二
- 弱實體
- 增加權限
- 增加實體間聯系和聯系的類型
- 3 試題三
- 3.1 UML關系
- 例子
- 3.2 例子(2016上半年)
- 3.3 設計類分類
- 3.3.1 接口類
- 3.3.2 控制類
- 3.3.3 實體類
- 3.4 簡答題
- 3.4.1 簡要說明選擇候選類的原則
- 3.4.2 某個類必須擁有的屬性是什么
- 3.5 設計模式
1 試題一
實體(長方體)
數據存儲(沒有封閉的長方體)
加工(橢圓長方體)
需要注意的錯誤:
1.加工有輸入但是沒有輸出
2.加工有輸出但是沒有輸入
3.加工的輸入不足以產生輸出
數據流的起點和終點中必須有一個是加工
父圖與子圖不平衡,圖 1-2 中沒有圖 1-1 中的數據流“維修情況”
1.1 結構化語言
用結構化語言對“道閘控制”的加工邏輯進行描述
道閘控制。根據道閘控制請求向道閘控制系統發送放行指令和接收道閘執行狀態。若道閘執行狀態為正常放行時,對入場車輛,將車牌號及其入場時間信息存入停車記錄,修改空余車位數;對出場車輛更新停車狀態,修改空余車位數。當因道閘重置系統出現問題(斷網斷電或是故障為抬杠等情況),而無法在規定的時間內接收到其返回的執行狀態正常放行時,系統向管理人員發送異常告警信息,之后管理人員安排故障排查處理,確保車輛有序出入停車場。
收到道閘控制請求
IF 道閘執行狀態為正常放行THEN IF 入場車輛THEN將車牌號及其入場時間信息存入停車記錄,修改空余車位數ELSE 更新停車狀態,修改空余車位數ENDIF
ELSE向管理人員發送異常告警信息
ENDIF
2 試題二
弱實體
一個郵件帳號可以含有多封郵件,一封郵件可以含有多個附件。附件信息主要包括附件號、附件文件名、附件大小。一個附件只屬于一封郵件,附件號僅在一封郵件內唯一。
附件屬于弱實體嗎?
附件屬于弱實體,因為附件的存在必須以郵件的存在為前提,即附件總是依附于某郵件
增加權限
為了數據庫信息的安全性,公司要求對數據庫操作設置權限管理功能,當員工登錄系統時,系統需要檢查員工的權限。權限的設置人是部門經理。為滿足上述需要,應如何修改(或補充)圖2-1所示的實體聯系圖,請給出修改后的實體聯系圖和關系模式。
權限(員工號 ,權限,部門經理)主鍵是員工號
增加實體間聯系和聯系的類型
電子商務公司的主營業務是銷售各類家電,對賬戶有余額的客戶,還可以聯合第三方基金公司提供理財服務,為此設立客戶經理崗位。客戶通過電子商務公司的客戶經理和基金公司的基金經理進行理財。每名客戶只由一名客戶經理和一名基金經理負責,客戶經理和基金經理均可負責多名客戶。請根據該要求,對圖2-1進行修改,畫出修改后的實體間聯系和聯系的類型。
3 試題三
3.1 UML關系
聚合 (空心菱形)
部分和整體的生命周期不一致,整體消失了,部分仍然存在。
?部分????????整體
組合 (實心菱形)
整體消失了,部分也消失了
購物車和商品適合采用聚合關系,網店和商品適合采用組合關系。
網店消失了,商品也下架了。
泛化 (實線三角形)
子類繼承父類,父類泛化子類
子元素????????父元素
例子
表示組合和聚合,在組合關系中,整體對象與部分對象具有統一的生命周期,當組合整體消失了,部分也消失了。而在聚合關系中,整體消失了,部分依然存在。
3.2 例子(2016上半年)
3.3 設計類分類
3.3.1 接口類
負責系統與用戶之間的交互,用于封裝在用例內、外流動的信息或數據流
這個我是排除法,先把實體類和控制類寫了
3.3.2 控制類
控制類負責業務邏輯的處理
控制類包含動詞
比如:計算總價、調用支付系統、發送完整訂單信息
3.3.3 實體類
實體類保存需要存儲在永久存儲體中的信息,主要負責持久化數據的存儲
我的理解是一直存在的人或東西
比如:會員、訂單表、郵箱地址、支付方式
3.4 簡答題
3.4.1 簡要說明選擇候選類的原則
認定類是面向對象分析中非常關鍵的一個步驟。一般首先從問題域中得到候選類集合,在根據相應的原則從該集合中刪除不作為類的,剩余的就是從問題域中認定出來的類。簡要說明選擇候選類的原則,以及對候選類集合進行刪除的原則。
具有下列特征的候選類需要刪除:含義相近(冗余)、含義不明確的對象、暗示實現方式的、表示屬性或特征、有動詞含義的名詞(表示行為和方法)。
3.4.2 某個類必須擁有的屬性是什么
圖3-2所示的類圖中使用了哪種設計模式?在這種設計模式下,類CFrequentFlyer必須具有的屬性是什么?C1?C4中的travel方法應具有什么功能?
使用了 State 模式(狀態模式)。
類 CFrequentFlyer 必須具有的屬性:CLevel 的對象。
travel 方法的功能:計算飛行里程數,根據里程數判斷是否需要調整會員級別(跳轉到不同的狀態)。
3.5 設計模式