【正文】 會計部門 應付款賬目 應收款明細賬 報表 客戶訂單 公司 合作 合作 編輯 接受 屬于 查詢 記錄 屬于 管理 參考 對應 產(chǎn)生 對應 管理 產(chǎn)生 屬于 購買 供應 圖 62 ER 圖 第七節(jié) 系統(tǒng) U/C 矩陣分析 圖 7 U/C 矩陣 顧客數(shù)據(jù) 發(fā)貨單 應收款賬目 銷售歷史 暫存訂單 公司訂單 到貨通知 應付款賬目 收付單據(jù) 會計總賬 報表 庫存 銷售管理 客戶管理 C U 銷售配件 U C U U U 記錄業(yè)務 C C 采購管理 記錄缺貨 U C U 追加訂貨 U C 驗貨入庫 U U C C U 財務管理 收付款 U U U U C 會計核算 U U U C U 編制報表 U U U U U C U 庫存管理 庫存管理 U U U C 監(jiān)督管理 U U U U U 數(shù)據(jù)類 功能 第三章 汽車 銷售 管理信息系統(tǒng)的系統(tǒng)設計 第一節(jié) 功能子系統(tǒng)劃分 根據(jù) U/C 矩陣分析，對汽車配件公司業(yè)務管理信息系統(tǒng)進行功能子系統(tǒng)劃分， 如圖 8 所示。、汽車銷售管理信息系統(tǒng)的系統(tǒng)規(guī)劃 第一節(jié) 項目開發(fā)背景 隨著經(jīng)濟的發(fā)展和中國汽車市場的不斷擴大，某汽車配件公司也隨著發(fā)展 的浪潮不斷擴大規(guī)模，隨之，訂單成倍增加，各項業(yè)務更加細化，各部門工作量增加，以往的人工處理方式就顯得力不從心，勞動強度大而且容易出錯。本系統(tǒng)只要花分為四個 功能子系統(tǒng)： 圖 8 系統(tǒng)功能子系統(tǒng)圖 銷售管理子系統(tǒng)：對客戶數(shù)據(jù)、訂貨處理等銷售業(yè)務進行管理； 財務管理子系統(tǒng)：負責各種報表和賬目的管理工作； 采購管理子系統(tǒng)：管理供應商信息，進行采購、收貨、驗貨等采購業(yè)務； 庫存管理子系統(tǒng)：對倉庫存貨進行管理和監(jiān)督。層次結構圖描述了整個系統(tǒng)的設計結構以及各類模塊之間的關系； IPO 圖則描述了在某個特定模塊內部的輸入（ I）、處理過程（ P）、輸出（ O）思想。這樣，從整體上來劃分，形成從全局來進行管理的格局。 圖 93 層次化配件采購管理模塊結構圖 圖 104 暫存訂單處理 IPO 圖 暫存訂單處理 IPO 圖表示了暫存訂單管理模塊，講述了如何核查暫存訂單配件匯總信息，核對暫存配件和相應的供應商的列表等處理過程。 1 實驗 1 制定項目計劃 1 實驗 4 用例建模 1 實驗 5 通過用例獲取概念數(shù)據(jù)模型 1 實驗 7 分析類圖建模（序列圖、交互圖、狀態(tài)圖、活動圖） 1 實驗 9 物理數(shù)據(jù)庫設計 1 實驗 10 確定系統(tǒng)構架等設計元素、設計類圖建模 1 實驗 12 系統(tǒng)實現(xiàn)代碼（ *） 根據(jù)搜集到的資料顯示，印第安漢堡的餐品預定系統(tǒng)的一次性成本如下所示： （ 1） PC 機： 2臺， 5000*2=10000 元 （ 2） Microsoft SQL Server 2021（ 1套）： 5000 元 （ 3） Microsoft Server2021（ 1 套）： 10000 元 （ 4） 打印機 1臺： 1000 元 （ 5） 人員培訓： 7 人 /2021 元，合計 14000 元 總計：本系統(tǒng)開發(fā)的一次性投入為 40000 元，并且新系統(tǒng)需在 6個月內實現(xiàn)。 （貼現(xiàn)率為 10%時） 二、 投資收益 由于我們的系統(tǒng)結構較為簡單，功能單一，初期投入后利潤也不會有太多。 （貼現(xiàn)率為 10%時） 綜上可知，五年內系統(tǒng) 的總收益為 94770 美元。 （貼現(xiàn)率為 5%） 總成本為 104942 美元。 從經(jīng)濟上考慮，當貼現(xiàn)率為 5%是，新系統(tǒng)在經(jīng)濟上具有可行性。 參與者：電話訂餐接線員或者前臺 前置條件：顧客的訂餐需求是有效的 后置條件 ： 生成正確的訂單，包括顧客的姓名、電話、住址以及訂單編號 等基礎內容。 可選操作流程 ： （ 1）顧客有信息輸入錯誤的，前臺人員 不予以確認原錯誤訂單，再按照顧客的正確信息重新生成訂單即可。 (3) 后臺管理員實時查詢庫存量，向有關部門報告，進行有效的庫存控制。 (2) 后臺管理員在主頁上輸出查詢條件，選擇出需要修改的餐品（一般是餐品價格的修改），點擊餐品圖片進入二級頁面， 完 成對餐品的修改操作。 參與者 ： 后臺管理員 前置條件：系統(tǒng)中存在一些已經(jīng)生成的訂單 后置條件：庫存量作相應的變動 假設條件：后臺管理員使用特殊賬號正確登錄到點餐系統(tǒng) 基本操作流程： (1) 系統(tǒng)根據(jù)已經(jīng)確認的訂單中餐品名稱和餐品數(shù)量做相應庫存量的減少。 5送貨員向顧客供應訂貨的用例描述 用例名稱：供應訂貨 簡要說明：送貨員憑借其中一份訂單與顧客錢貨兩清，完成整個訂餐過程 參與者： 送貨員 前置條件：顧客完成“點餐”用例，且餐品未送達。 實驗五：通過用例獲取概念數(shù)據(jù)模型 概念數(shù)據(jù)模型是對組織數(shù)據(jù)的描繪，它以一種獨立于現(xiàn)實的方式說明了數(shù)據(jù)的結構和數(shù)據(jù)之間的相互關系。在此我們選擇 AdminId（管理員號）、 OrderId（訂單號、 CustId（顧客號）、 ProId（產(chǎn)品號）為標識符 考慮屬性的性質 在此，除了普通的屬性以外，我們認為顧客聯(lián)系方式應除了常用的一個以外，至少一個備用，所以 CustPhone（顧客電話）為多值屬性，訂單的 ubTotal（小計），TotalAmount（總數(shù)量），產(chǎn)品的 ProAmount（產(chǎn)品庫存）可由其他數(shù)據(jù)確定，應為導出屬性。本次實驗 基于前面概念數(shù)據(jù)模型的建立，將其轉化為對象關系，接著將所有關系合并為最終的、 綜合的一組關系，其步驟如下： 將類轉化為對象關系 類的標識符成為該對象關系的主鍵，類的其他屬性成為該對象關系的非主鍵屬性。 下圖為按照指導原則描繪的“預訂”用例的順序圖： :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 （ ） 圖中詳細描述 了 “ 預定 ”用例 的順序圖：參與者 ： Customer 選擇一個或多個產(chǎn)品調用該用例，這個消息 //select item（選