【正文】 關(guān)系對象屬性特性描述 在實(shí)驗(yàn)六中，我們的到如下的對象關(guān)系 Order PrimaryOrderId OrderDate DerivedSubTotal DerivedTotalAmount //create order() //get order info() //update order info() Customer PrimaryCustId CustomerName CustPhone CustPhone //get customer info() //charge customer() Product PrimaryProId ProName ProPrice //get products info() //update inventory LineItem Quantity ActualPrice DeriveLineAmount //add item() //get lineitems() //write order lineitems() BUY OrderControl //select item() //confirm order() //calc total() OrdertForm //select item() //confirm order() Admin（ AdminId， AdminName， AdminPsd， AdminType） Order （ OrderId ， CustId ， AdminId ， OrderDate ， DerivedSubTotal ，DerivedTotalAmount） LineItem（ OrderId ， ProId ， Quantity， ActualP。 例如， 對象訂單的狀態(tài)經(jīng)歷創(chuàng)建、供應(yīng)、完成， 它的狀態(tài)圖如下： 訂 單 被 創(chuàng) 建 檢 查 可 獲 得 的 訂 單 項(xiàng) 目 供 應(yīng) 顧 客 的 餐 點(diǎn) 訂 單 完 成 ： 分析類圖說明分析類和這些類之間的關(guān)系，有兩種關(guān)系 —— 結(jié)構(gòu)關(guān)系和行為關(guān)系，結(jié)果方面從數(shù)據(jù)建模中可以獲得，分析類圖的行 為方面可以從順序圖或通信圖導(dǎo)出。一個對象的狀態(tài)是在對象生存期間的一個條件或情況，在這個時間它滿足某些條件，執(zhí)行某些活動或等待某些事件。 圖： 活動圖和順序圖相似， 但 兩個圖的重點(diǎn)不同，順序圖在于說明一個程序中的控制流，而活動圖說明系統(tǒng)中活動到活動的控制流 ，什么活動可以并行進(jìn)行，和任何通過流的可選路徑。它來創(chuàng)建一個新的項(xiàng)目?？刂茖ο髮?chuàng)建新訂單的責(zé)任傳給了 ： Order， ： Order 創(chuàng)建一個新訂單。 下圖為按照指導(dǎo)原則描繪的“預(yù)訂”用例的順序圖： :P r o d u c t:C u s to m e r :O r d e r F o r m :O r d e r C o n tr o l :C u s to m e r :O r d e r :L in e ite m/ / s e l e c t i t e m （ ）/ / s e l e c t i t e m （ ） / / c r e a t e o r d e r （ ）/ / a d d i t e m （ ）/ / g e t c u s t o m e r I n f o （ ） / / g e t o r d e rI n f o （ ） / / d i s p l a y o r d e r d e t a i l s （ ） / / c a l c t o t a l （ ） / / c o n f i r m o r d e r （ ） / / c o n f i r m o r d e r （ ）/ / c h a r g e c u s t o m e r （ ） / / w r i t e o r d e r i n f o （ ）/ / w r i t e o r d e r l i n e i t e m（ ）/ / u p d a t e i n v e n t o r y （ ）/ / g e t p r o d u c t i n f o（ ）/ / g e t l i n e i t e m s （ ） 圖中詳細(xì)描述 了 “ 預(yù)定 ”用例 的順序圖：參與者 ： Customer 選擇一個或多個產(chǎn)品調(diào)用該用例，這個消息 //select item（選擇產(chǎn)品項(xiàng)）表明，它被傳給 ：OrderForm。 Order （ OrderId ， CustId ， AdminId ， OrderDate ， DerivedSubTotal ，DerivedTotalAmount） 最后轉(zhuǎn)化關(guān)聯(lián)類 在 Order 和 Product 之間有一關(guān)聯(lián)類 LineItem，其可映像為對象關(guān)系，并用兩個類的主鍵 OrderId 和 ProId 的組合作為他的主鍵。本次實(shí)驗(yàn) 基于前面概念數(shù)據(jù)模型的建立，將其轉(zhuǎn)化為對象關(guān)系，接著將所有關(guān)系合并為最終的、 綜合的一組關(guān)系，其步驟如下： 將類轉(zhuǎn)化為對象關(guān)系 類的標(biāo)識符成為該對象關(guān)系的主鍵，類的其他屬性成為該對象關(guān)系的非主鍵屬性。 每個訂單可包含多種產(chǎn)品，每個產(chǎn)品可以包括在不同的訂單里，因此 Product和 Order 為多對多的關(guān)系，用關(guān)聯(lián)類 LineItem來表示。在此我們選擇 AdminId（管理員號）、 OrderId（訂單號、 CustId（顧客號）、 ProId（產(chǎn)品號）為標(biāo)識符 考慮屬性的性質(zhì) 在此，除了普通的屬性以外，我們認(rèn)為顧客聯(lián)系方式應(yīng)除了常用的一個以外，至少一個備用，所以 CustPhone（顧客電話）為多值屬性，訂單的 ubTotal（小計），TotalAmount（總數(shù)量），產(chǎn)品的 ProAmount（產(chǎn)品庫存）可由其他數(shù)據(jù)確定，應(yīng)為導(dǎo)出屬性。 確定每一個類的屬性 用例中沒有提供關(guān)于屬性 的所有詳細(xì)資料，因此我查看了與“訂單” 用例 相關(guān)文檔，并結(jié)合本系統(tǒng)的功能需求，將屬性分配到類。 實(shí)驗(yàn)五：通過用例獲取概念數(shù)據(jù)模型 概念數(shù)據(jù)模型是對組織數(shù)據(jù)的描繪，它以一種獨(dú)立于現(xiàn)實(shí)的方式說明了數(shù)據(jù)的結(jié)構(gòu)和數(shù)據(jù)之間的相互關(guān)系。 (2) 系統(tǒng)根據(jù)訂單中的餐品名稱和餐品數(shù)量作相應(yīng)庫存量的減少。 5送貨員向顧客供應(yīng)訂貨的用例描述 用例名稱：供應(yīng)訂貨 簡要說明：送貨員憑借其中一份訂單與顧客錢貨兩清，完成整個訂餐過程 參與者： 送貨員 前置條件：顧客完成“點(diǎn)餐”用例，且餐品未送達(dá)。 (2) 系統(tǒng)顯示每種餐品剩余庫存量以便管理員及時同有關(guān)部門協(xié)調(diào)，增加相應(yīng)餐品的供給。 參與者 ： 后臺管理員 前置條件：系統(tǒng)中存在一些已經(jīng)生成的訂單 后置條件：庫存量作相應(yīng)的變動 假設(shè)條件：后臺管理員使用特殊賬號正確登錄到點(diǎn)餐系統(tǒng) 基本操作流程： (1) 系統(tǒng)根據(jù)已經(jīng)確認(rèn)的訂單中餐品名稱和餐品數(shù)量做相應(yīng)庫存量的減少。 可選操作流程：增加餐品的前提是庫存不為零，庫存超過一定數(shù)量的餐品系統(tǒng)顯示不能刪除餐品信息。 (2) 后臺管理員在主頁上輸出查詢條件，選擇出需要修改的餐品（一般是餐品價格的修改），點(diǎn)擊餐品圖片進(jìn)入二級頁面， 完 成對餐品的修改操作。 用例名稱：餐品管理 簡要說明：后臺管理員根據(jù)公司業(yè)務(wù)發(fā)展的需要對點(diǎn)餐系統(tǒng)中供應(yīng)的餐品進(jìn)行增、刪、該操作。 (3) 后臺管理員實(shí)時查詢庫存量，向有關(guān)部門報告，進(jìn)行有效的庫存控制。 用例名稱：訂單管理 簡要說明：由后臺管理員對已經(jīng)生成的訂單進(jìn)行查詢和刪除 參與者： 后臺管理員 前置條件：點(diǎn)餐系統(tǒng)中存在業(yè)已生成的訂單 后置條件：顯示訂單信息、刪除相應(yīng)的訂單 假設(shè)條件：后臺管理員使用特殊賬號正確登錄到點(diǎn)餐系統(tǒng) 基本操作流程： (1) 后臺管理員輸入需要查詢的訂單編號，也可以通過顧客名稱、電話號碼等進(jìn)行訂單查詢。 可選操作流程 ： （ 1）顧客有信息輸入錯誤的，前臺人員 不予以確認(rèn)原錯誤訂單，再按照顧客的正確信息重新生成訂單即可。 （ 3）在庫存充足的條件下，點(diǎn)擊進(jìn)入目標(biāo)餐品的預(yù)訂頁面，要求顧客報送姓名、電話及住址信息，點(diǎn)擊“確認(rèn)按鈕”生成訂單，此項(xiàng)操作只針對電話訂餐接線員，如為前臺訂餐，直接在庫存充足的情況下，點(diǎn)擊“確定”按鈕生成訂單一式三聯(lián)即可。 參與者：電話訂餐接線員或者前臺 前置條件：顧客的訂餐需求是有效的 后置條件 ： 生成正確的訂單，包括顧客的姓名、電話、住址以及訂單編號 等基礎(chǔ)內(nèi)容。 一、 印第安漢堡點(diǎn)餐系統(tǒng)的用例圖如下所示。 從經(jīng)濟(jì)上考慮，當(dāng)貼現(xiàn)率為 5%是，新系統(tǒng)在經(jīng)濟(jì)上具有可行性。 （貼現(xiàn)率為