uml報告-食堂飯卡管理系統(tǒng)

1、精選優(yōu)質(zhì)文檔-傾情為你奉上 UML面向?qū)ο蠓治稣n程實踐項目報告項目名稱：食堂飯卡管理系統(tǒng)模型 項目組成員： 學 號： 班 級： 指導 教師： 08年 11 月 15 日專心-專注-專業(yè)目 錄統(tǒng)一建模語言UML是業(yè)務和軟件應用建模的標準語言，適用于各種軟件開發(fā)方法、軟件生命周期的各個階段、各種應用領域以及各種開發(fā)工具。設計系統(tǒng)時，首先是描述需求；其次根據(jù)需求建立系統(tǒng)的靜態(tài)模型，以構造系統(tǒng)的結構；第三步是描述系統(tǒng)的行為。其中在第一步與第二步中所建立的模型都是靜態(tài)的，包括用例圖、類圖、對象圖、組件圖和配置圖等五個圖形。其中第三步中所建立的模型包括狀態(tài)圖、活動圖、順序圖和合作圖等四個圖形,是UML的動

2、態(tài)建模機制1需求分析1.1 需求概述南京工業(yè)職業(yè)技術學院食堂分別由教工食堂、學生一食堂、學生二食堂、三食堂 四食堂 等等組成。其中教工食堂采用計次消費，學生食堂采用刷卡消費，校園內(nèi)食堂全部由內(nèi)部承包、獨立核算，不可付現(xiàn)金只可刷卡。校園食堂統(tǒng)一由后勤科管理，共需管理10000余人用餐，需通過消費系統(tǒng)實現(xiàn)一卡通。 根據(jù)對該大學四個食堂及管理中心現(xiàn)場勘察情況以及對客戶需求的詳細調(diào)查，總結分析如下： 一、 該大學共有食堂5個，消費點46個，其中；教工食堂5個消費點，一食堂二食堂三食堂四食堂各20個消費點，師生園飯莊5個消費點； 二、 在后勤科設立食堂管理中心，主要負責對全校持卡人進行消費刷卡、發(fā)卡充值

3、、銷卡等操作。每月根據(jù)食堂消費情況打印出總報表及各食堂報表等； 三、 僅學校教職員工在此消費，每人每餐標準定額補給。教職工分早餐、中餐、晚餐及夜宵四種。 四、 學生一食堂、二食堂等食堂采用金額式消費，僅供本校學生在此消費，學生分早餐、中餐、晚餐三種。 五、 校園飯莊由于個人承包，教職員工及學生均可在此消費。不分早中晚餐和宵夜。每月終了，管理中心核算其營業(yè)收入。 六、 消費卡片標記持卡人相片、姓名、院名、系名、學號等信息；食堂飯卡應能實現(xiàn)以下功能支持定額扣費和自選扣費、記次消費三種模式；  支持學校補貼包和個人充值兩個獨立錢包；補貼錢包支持覆蓋上月余額或累加上月余額兩種模式選

4、擇；   支持軟件訂餐和硬件訂餐功能；不同餐別票價設置，比如：早餐1元、午餐4元、晚餐4元、宵夜2元；   可以限定一餐（或一天）的最高消費額，超額拒絕消費；不同卡類的設置，可以設定同一餐不同的卡扣不同的金額，如果：午餐員工卡扣4元，教師卡扣3元可以限制一餐只能消費一次或者消費第二次扣不同的金額。  IC卡使用有效期限定，離校學生或離職教工無法使用；    支持聯(lián)網(wǎng)、脫機使用 實時監(jiān)控交易數(shù)據(jù)支持硬件查詢消費金額和人次；   自動生成各種報表（充

5、值報表、發(fā)卡報表、退卡報表、消費報表、經(jīng)營匯總表、平衡報表，可以按年、月、周、日、時段查詢及打印報表等）；   支持掛失、黑名單下載、黑名單拒絕消費功能需求分析：食堂就餐卡系統(tǒng)是用現(xiàn)代信息技術和自動控制技術的計算機網(wǎng)絡系統(tǒng)。它的使用對于加強校園后勤服務的信息化建設，提高服務質(zhì)量、管理水平和經(jīng)濟效益有重要的作用。系統(tǒng)中每個消費者都有一張卡，在管理中心注冊繳費，卡內(nèi)記著消費者的身份、余額。使用時將卡插入窗口機則顯示卡上金額，服務員按窗口機上數(shù)字鍵，窗口機自動計算并顯示消費額及余額。管理中心監(jiān)視每一筆消費，可打印出消費情況的相關統(tǒng)計數(shù)據(jù)。應可以滿足以下的幾點要求 系統(tǒng)信

6、息管理：建立營業(yè)組檔案、卡用戶檔案、收款機檔案； 卡的管理：開戶、更改、發(fā)卡、掛失解掛、注銷、補卡、充值、統(tǒng)計等； 日常操作：數(shù)據(jù)采集、終端設置、掛失名單、上傳交易、上傳充值等； 營業(yè)匯總：自動匯總交易數(shù)據(jù)，實現(xiàn)金額結算，生成相應報表； 查詢：對每一次消費情況進行實時記錄，可查詢卡內(nèi)余額或消費記錄； 系統(tǒng)維護：數(shù)據(jù)備份、數(shù)據(jù)恢復、端口設置、管理員信息并設置密碼和權限； 統(tǒng)計報表：就餐卡發(fā)行、各窗口機就餐數(shù)據(jù)、黑名單等匯總、明細報表；需求模型（用例圖）用例圖的分析：分析階段的一個主要工作是對用戶的需求進行分析，找出系統(tǒng)的用例，如下圖是網(wǎng)絡購物系統(tǒng)的用例圖：當然這并不是唯一的用例圖，每個設計者對用

7、例的劃分粒度，參與者的選擇，用例優(yōu)先級的分配等有不同的方案。在用例的分析中，對于用例還有一個很重要的工作就是要有用例的描述，這樣會讓用戶能更加明白你的系統(tǒng)的用途。在食堂管理系統(tǒng)中，使用者插卡進行消費，對于用例的描述有不同的格式，但是基本的內(nèi)容應該都是差不多的。都是能盡量的把系統(tǒng)的所有功能描述清楚，讓用戶最大化的理解和能使用系統(tǒng)的功能。用例圖被稱為參與者和外部用戶所能觀察到的系統(tǒng)功能的模型圖。下圖之一是本系統(tǒng)的用例圖。食堂管理系統(tǒng)用例圖由三個二元關聯(lián)類的事項組成，即消費者與系統(tǒng)服務器之間的卡的管理事項，儲值卡與收款機之間的消費事項，以及系統(tǒng)服務器與服務員的結算事項。整個系統(tǒng)參與者是消費者、管理員

8、和服務員，第一幅用來解釋用例里設計的流程，。其中administer 與服務器是屬于一個整體的，這里僅有administer 來表示服務器 2 靜態(tài)模型類圖的分析：畫類圖和理解類圖時都應采用三個層次的觀點。這些觀點也適用于其它模型。三個層次的觀點不是UML的組成部分，但對建造模型或評價模型都非常有用，且都可應用于UML.（1）概念層描述應用域中的概念，是對現(xiàn)實世界的直接描述，與實現(xiàn)它們的類有關但與實現(xiàn)方案和實現(xiàn)語言無關。（2）說明層描述軟件的接口，而不是軟件的實現(xiàn)。一個類型描述一個接口，但可能有多種實現(xiàn)。（3）實現(xiàn)層從實現(xiàn)的角度定義類及其實現(xiàn)，揭示了軟件實現(xiàn)體的構成情況。下面是食堂管理系統(tǒng)的類

9、圖食堂系統(tǒng)管理類圖對象圖 學生類；發(fā)送姓名 獲取卡號 和查詢時要輸入卡號服務員類 包含學生的動作 并顯示卡號 傳遞消息 和退出 管理員類 登陸 增加減用戶 加值 掛失 注銷用戶 查詢消費信息等等 食堂管理系統(tǒng)對象簡圖Students內(nèi)記著消費者的身份、余額。使用時將卡插入窗口機（收款機）則顯示卡上金額，服務員按窗口機上數(shù)字鍵，窗口機自動計算并顯示消費額及余額。管理中心（數(shù)據(jù)服務器）監(jiān)視每一筆消費并可容易可打印出消費情況的相關統(tǒng)計數(shù)據(jù)。2.1 包圖包圖用來補充說明事件所用1GUI包是圖像用戶界面的包圖：含有+lenders WINDOWS returnWINDOWS 等等 圖形元素SEVER P

10、ACKAGE1 事件包！如工作人員鍵入數(shù)據(jù) 收款機損壞 數(shù)據(jù)鍵入數(shù)值有誤 等等！從而進行相應的處理！CARD CLIENT 處理卡的相應事件！如當卡內(nèi)余額不足時 給出相應提示GUI包是圖像用戶界面的包圖：含有+lenders WINDOWS returnWINDOWS 等等 圖形元素SEVER PACKAGE1 事件包！如工作人員鍵入數(shù)據(jù) 收款機損壞 數(shù)據(jù)鍵入數(shù)值有誤 等等！從而進行相應的處理！CARD CLIENT 處理卡的相應事件！如當卡內(nèi)余額不足時 給出相應提示3動態(tài)模型時序圖如下面兩圖，學生把卡貼到顯示器（即收款機）上，注意！此時其他卡在放到收款機無效，除非收款機一取消前一用戶！收款機

11、讀取該卡額相關信心！并發(fā)送到服務器中！讀取數(shù)據(jù)庫中的相關數(shù)據(jù)！符合則返回到收款機收款員鍵入數(shù)字！收款機負責發(fā)送！服務器查看數(shù)據(jù)是否合法，有其合法性確定確定按鈕是否有效 再有其按確定按鈕！數(shù)據(jù)等待處理完成后保存，并是收款機返回初始狀態(tài)學生消費時序圖食堂系統(tǒng)管理域時序圖食堂打卡管理系統(tǒng)時序圖狀態(tài)圖食堂打卡狀態(tài)圖 卡被收款機讀取后 收款機將自動將數(shù)據(jù)發(fā)送到服務器，有服務器分析判斷該戶是否存在，卡是否有效，從而決定是否繼續(xù)下一步操作的有效型管理員狀態(tài)圖圖協(xié)作圖系統(tǒng)管理員協(xié)作圖管理員輸入姓名 登陸進入操作界面 選擇操作界面選擇操作事項操作完畢數(shù)據(jù)庫自動保存完成后返回主界面活動圖食堂管理員活動圖管理員進入

12、系統(tǒng)后根據(jù)需要選擇相應需求 為學生完成相關服務！管理員登陸需要用戶驗證選擇操作界面進行各項操作如上圖操作完畢系統(tǒng)自動保存返回該主界面 gong工作人員活動圖工作人員根據(jù)學生消費數(shù)量鍵入數(shù)字 有收款機發(fā)送到服務器，有服務器接受保存后，注銷該卡信息，是收款機回復初始狀態(tài)食堂系統(tǒng)活動圖學生插卡 讀卡機機收款機自動讀取信息并驗證驗證完畢服務員方可進行各項操作 活動如上圖4項目組成員分工說明需求分析 類圖 協(xié)作圖 需求概述 包圖 活動圖 需求模型 時序圖 狀態(tài)圖 對象圖 總結:從整個食堂飯卡管理系統(tǒng)的設計過程可以看出，UML作為面向?qū)ο蠼I域的工業(yè)標準，在軟件系統(tǒng)的設計過程中有著巨大的優(yōu)勢。它的各個模

13、型可以幫助我們更好地理解業(yè)務流程，建立更可靠、更完善的系統(tǒng)模型。從而使用戶和開發(fā)人員對問題的描述達到相同的理解，以減少語義差異，保障分析的正確性從使用UML建模的整個過程來講，可分成概念級建模、邏輯級建模、物理級建模三個階段。概念級建模用于需求分析階段，主要采取用例圖、對象圖、活動圖來表示；邏輯級建模用于分析和初步設計階段，主要用類圖、序例圖、狀態(tài)圖 活動圖 狀態(tài)圖 來表示； 第三階段由于水平有限 咱無法給出所以本食堂飯卡管理系統(tǒng)只是簡單地給出前兩個階段對應的相應圖例。在概念級建模階段，設計人員 必須清楚了解用戶的需求！以及系統(tǒng)要實現(xiàn)的功能！原則是不增加不必要的功能，也不缺少必要的功能例如加值 掛失 黑戶 或是支持補貼 或是更先進的銀行卡！能與銀行卡綁定！、6參考資料 1 Alan Zeichick , Modeling Usage Low; Developers Confused About UML , MDA,20042 ITU Recommendation , Specification and Description Language(SDL)；20033 UML和模式應用面向?qū)ο蠓治龊驮O計導論，Craig Larman等，姚淑珍，李虎譯，機械工業(yè)出版社，20024 UML ASL R