【正文】 擇產(chǎn)品項）表明，它被傳給 ：OrderForm。它來創(chuàng)建一個新的項目。一個對象的狀態(tài)是在對象生存期間的一個條件或情況，在這個時間它滿足某些條件，執(zhí)行某些活動或等待某些事件。 關(guā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) 建 檢 查 可 獲 得 的 訂 單 項 目 供 應(yīng) 顧 客 的 餐 點 訂 單 完 成 ： 分析類圖說明分析類和這些類之間的關(guān)系，有兩種關(guān)系 —— 結(jié)構(gòu)關(guān)系和行為關(guān)系，結(jié)果方面從數(shù)據(jù)建模中可以獲得，分析類圖的行 為方面可以從順序圖或通信圖導(dǎo)出。 圖： 活動圖和順序圖相似， 但 兩個圖的重點不同，順序圖在于說明一個程序中的控制流，而活動圖說明系統(tǒng)中活動到活動的控制流 ，什么活動可以并行進行，和任何通過流的可選路徑。控制對象將創(chuàng)建新訂單的責(zé)任傳給了 ： Order， ： Order 創(chuàng)建一個新訂單。 Order （ OrderId ， CustId ， AdminId ， OrderDate ， DerivedSubTotal ，DerivedTotalAmount） 最后轉(zhuǎn)化關(guān)聯(lián)類 在 Order 和 Product 之間有一關(guān)聯(lián)類 LineItem，其可映像為對象關(guān)系，并用兩個類的主鍵 OrderId 和 ProId 的組合作為他的主鍵。 每個訂單可包含多種產(chǎn)品，每個產(chǎn)品可以包括在不同的訂單里，因此 Product和 Order 為多對多的關(guān)系，用關(guān)聯(lián)類 LineItem來表示。 確定每一個類的屬性 用例中沒有提供關(guān)于屬性 的所有詳細資料，因此我查看了與“訂單” 用例 相關(guān)文檔，并結(jié)合本系統(tǒng)的功能需求，將屬性分配到類。 (2) 系統(tǒng)根據(jù)訂單中的餐品名稱和餐品數(shù)量作相應(yīng)庫存量的減少。 (2) 系統(tǒng)顯示每種餐品剩余庫存量以便管理員及時同有關(guān)部門協(xié)調(diào)，增加相應(yīng)餐品的供給。 可選操作流程：增加餐品的前提是庫存不為零，庫存超過一定數(shù)量的餐品系統(tǒng)顯示不能刪除餐品信息。 用例名稱：餐品管理 簡要說明：后臺管理員根據(jù)公司業(yè)務(wù)發(fā)展的需要對點餐系統(tǒng)中供應(yīng)的餐品進行增、刪、該操作。 用例名稱：訂單管理 簡要說明：由后臺管理員對已經(jīng)生成的訂單進行查詢和刪除 參與者： 后臺管理員 前置條件：點餐系統(tǒng)中存在業(yè)已生成的訂單 后置條件：顯示訂單信息、刪除相應(yīng)的訂單 假設(shè)條件：后臺管理員使用特殊賬號正確登錄到點餐系統(tǒng) 基本操作流程： (1) 后臺管理員輸入需要查詢的訂單編號，也可以通過顧客名稱、電話號碼等進行訂單查詢。 （ 3）在庫存充足的條件下，點擊進入目標(biāo)餐品的預(yù)訂頁面，要求顧客報送姓名、電話及住址信息，點擊“確認按鈕”生成訂單，此項操作只針對電話訂餐接線員，如為前臺訂餐，直接在庫存充足的情況下，點擊“確定”按鈕生成訂單一式三聯(lián)即可。 一、 印第安漢堡點餐系統(tǒng)的用例圖如下所示。 （貼現(xiàn)率為 5%） 成本收益分析 （ 1） 投資回收期為第 年。由于總成本是大于總收益的，所以系統(tǒng)越運行，越虧損，該信息系統(tǒng)不具備經(jīng)濟上的可行性。根據(jù)預(yù)測，印第安漢堡的餐品預(yù)定系統(tǒng)的投資收益如下所示： 1 一次性收益：無。 根據(jù)搜集到的資料顯示，在印第安漢堡的餐品預(yù)定系統(tǒng)中，這種經(jīng)常性投入表現(xiàn)為續(xù)生成本，并且需要連續(xù)投資 5年，具體如下所示： （ 1） 預(yù)定系統(tǒng)的維護： 1000 元 /年 *5 年 =5000 元 （ 2） 每年增加的數(shù)據(jù)存儲費用： 5000 元 /年 *5 年 =25000 元 （ 3） 消費用品支出： 800 元 /年 *5 年 =4000 元 （ 4） 其他支出： 1000 元 /年 *5年 =5000 元 綜上可得，印第安漢堡的餐品預(yù)定系統(tǒng)為 15000 美元 /年，折算為現(xiàn)值為96862 元。 第一部分 實驗一：制定項目計劃 實驗二 ：制定項目計劃 從經(jīng)濟上分析項目的可行性 一、 投資成本 印 第安 漢堡餐品預(yù)定系統(tǒng)在投資成本上包括兩方面，一次性成本和續(xù)生成本。 1 附錄：項目成員分工情況 1 第四 部分 系統(tǒng)實現(xiàn) 1 第三 部分 系統(tǒng)設(shè)計 1 實驗 8 確定設(shè)計方案（ *） 1 實驗 6 將概念數(shù)據(jù)模型轉(zhuǎn)換為對象關(guān)系模型 第 五 章 系統(tǒng)設(shè)計總結(jié) 第一節(jié) 項目實施中各個工作流程及時間分布 1． 項目開發(fā)的編寫 1 天 2． 業(yè)務(wù)流程圖設(shè)計 2 天 3． 數(shù)據(jù)流程圖設(shè)計 1 天 4． ER 圖設(shè)計 1 天 5． U/C 矩陣設(shè)計 2 天 6． HIPO 圖設(shè)計 2 天 模塊名稱：配件入庫處理系統(tǒng) 使用單位：采購部 輸入部分 I 處理描述 P 輸出部分 O 1. 利用權(quán)限打開數(shù)據(jù)庫 2. 上組中輸出的采購訂貨單信息 3. 輸入供應(yīng)商發(fā)貨信息 4. 讀取原庫存量信息 5. 讀取標(biāo)準(zhǔn)配件質(zhì)量信息 1. 核對采購訂貨單和發(fā)貨單信息 2. 核對發(fā)貨配件質(zhì)量信息和標(biāo)準(zhǔn)配件 質(zhì)量信息 3. 處理過程 出錯信息 核對出錯 質(zhì)量不合格 不合格配件處理 合格配件入庫處理 1. 將合格標(biāo)志送回上一級調(diào)用模式 2. 將核對記錄記入文件 3. 修改庫存量信息 4. 修改應(yīng)付款明細帳 7． 文檔修改、定稿 1 天 第二節(jié) 本人系統(tǒng)設(shè)計特點 1． 優(yōu)點：本系統(tǒng)具有較強的直觀性，設(shè)計完整，能較好的體現(xiàn)系統(tǒng)的設(shè)計構(gòu)思； 缺點：設(shè)計的有些方面有點簡單，有很多地方還需進一步分析改進。 輸入部分 I 處理描述 P 輸出部分 O 1. 利用權(quán)限打開數(shù)據(jù)庫 2. 輸入定貨單的顧客信息：名 稱、地址、電話、開戶行、賬號 3. 輸入定貨單的各類信息：配 件名稱、規(guī)格、編號 1. 核對用戶賬號和新建用賬號 2. 核查定單信息 3. 處理過程 出錯信息 定單不合格 新建用戶合格定單處理 老用戶合格定單處理 1. 將合格標(biāo)志送回上一級調(diào)用模式 2. 將核對的記錄記入文件 3. 修改顧客記錄 4. 將合格的定 單信息以標(biāo)準(zhǔn)格式輸出 模塊名稱：定單輸入系統(tǒng) 使用單位：銷售部 訂貨管理 訂單輸入 訂單處理 開 發(fā)貨單 圖 102 訂單處