課程設(shè)計UML支持校園卡食堂消費管理信息系統(tǒng)

1、統(tǒng)一建模語言UMLM程設(shè)計報告支持校園卡的食堂消費管理信息系統(tǒng)第 1 章 系統(tǒng)需求分析 21.1 系統(tǒng)功能分析 21.1.1 功能需求 21.1.2 非功能需求 21.2 數(shù)據(jù)庫管理模塊 31.3 基本業(yè)務(wù)模塊 41.4 信息查詢模塊 4第2章系統(tǒng)的UM型本模型 62.1 UML 初始模型 62.2 系統(tǒng)的用例圖 62.3 系統(tǒng)的時序圖 72.4 系統(tǒng)的協(xié)作圖 92.5 系統(tǒng)的狀態(tài)圖 102.6 系統(tǒng)的活動圖 11第3 章系統(tǒng)中的類 153.1 類圖的生成 153.2 各類之間的關(guān)系 16第4章系統(tǒng)的配置與實現(xiàn) 184.1 系統(tǒng)的組件圖 184.2 系統(tǒng)的配置圖 19第5 章小結(jié) 21附錄 參

2、考資料 23第 1 章 系統(tǒng)需求分析1.1 系統(tǒng)功能分析1.1.1 功能需求對于支持校園卡的食堂消費信息管理系統(tǒng)來說，應(yīng)該至少包括如下幾部分功能：（ 1）信息查詢系統(tǒng)在驗證用戶身份之后，允許用戶根據(jù)需要進行查詢。查詢搜索的分類只要有三種：對賬號的基本信息查詢時，主要通過連接數(shù)據(jù)庫查詢用戶的賬號、姓名、性別、卡類、單位、專業(yè)、備注信息。對消費明細的查詢時，可以查詢最近30 天內(nèi)制定時期內(nèi)消費明細，包括消費日期、具體時間、消費地點、消費金額、余額。對充值明細的查詢時，可以查詢4 年內(nèi)制定時期內(nèi)的充值明細，包括充值時間、交易金額、交易類型（柜臺充值、網(wǎng)銀充值、充值地點等）、操作員或交易號等。（ 2）

3、校園卡管理掛失和解掛；通知學(xué)生事務(wù)中心補辦新卡，學(xué)生事務(wù)中心通知客戶取新卡；使用網(wǎng)上銀行為校園卡充值，必須與網(wǎng)上銀行連接，實現(xiàn)充值功能。1.1.2 非功能需求（ 1）操作需求系統(tǒng)可以在任何主流 web瀏覽器上運行；系統(tǒng)可以進行后臺數(shù)據(jù)庫管理。（ 2）性能需求系統(tǒng)可以滿足每天24小時全年365天持續(xù)工作；系統(tǒng)每天會在晚10 點以后進行更新；在 8： 00 22： 00時段支持300位并發(fā)用戶使用，其余時間支持150位。（ 3）安全需求由于系統(tǒng)涉及到個人財產(chǎn)安全問題，所以系統(tǒng)要求有很高的安全性；系統(tǒng)包含對病毒、蠕蟲和木馬等病毒的防衛(wèi)；系統(tǒng)系統(tǒng)對登錄用戶進行身份驗證，管理員對網(wǎng)站和后臺數(shù)據(jù)庫進行管理

4、。功能需求分析以后，可知滿足上述需求的系統(tǒng)需要包括以下幾個模塊：（ 1）數(shù)據(jù)庫管理模塊。數(shù)據(jù)庫管理模塊提供了使用者錄入、修改并維護數(shù)據(jù)的途徑。比如學(xué)生和老師都可以修改自己的基本信息，然后保存到數(shù)據(jù)庫中； 也提供了系統(tǒng)管理員進行用戶信息維護的功能。(2)基本業(yè)務(wù)模塊?？梢杂眯@卡消費、充值、也可以掛失和解掛，并在 遺失以后舊卡的所有信息保留到新卡。(3)信息查詢模塊。主要是對校園卡用戶的基本信息查詢，也可以對消費 和充值的相關(guān)記錄進行查詢、瀏覽。支持校園卡的食堂消費管理信息系統(tǒng)基本業(yè)務(wù)模塊信 息 查 詢 模 塊數(shù) 據(jù) 庫 管 理 模 塊圖1-1系統(tǒng)功能需求1.2 數(shù)據(jù)庫管理模塊數(shù)據(jù)庫模塊包括如下

5、圖所示的幾個方面:數(shù)據(jù)庫模塊圖1-2數(shù)據(jù)庫管理模塊功能(1)用戶注冊的信息管理，包括教師和學(xué)生在系統(tǒng)上進行注冊信息的更新 操作，操作者可以是用戶，也可以是系統(tǒng)管理員。(2)消費明細信息管理，系統(tǒng)管理員在教師離職，或者學(xué)生學(xué)籍不存在時 可以進行刪除或者清空消費信息。(3)充值明細信息管理，系統(tǒng)管理員在教師離職，或者學(xué)生學(xué)籍不存在時 可以進行刪除或者清空充值信息。1.3 基本業(yè)務(wù)模塊基本業(yè)務(wù)模塊包括如下圖所示的幾個方面：圖1-3基本業(yè)務(wù)模塊功能(1)在校園卡丟失之后可以登錄系統(tǒng)補辦新卡。(2)到指定的地方可以為校園卡充值，也可以進行網(wǎng)上轉(zhuǎn)賬(3)校園卡丟失以后可以掛失，防止別人用自己的卡消費。(4

6、)校園卡找到之后可以解掛，卡的狀態(tài)從停用變?yōu)檎！?.4 信息查詢模塊信息查詢模塊主要用于網(wǎng)頁上的信息瀏覽和查詢，包括如下圖所示幾個方面:圖1-4信息查詢模塊功能(1)用戶注冊信息，通過網(wǎng)頁登陸瀏覽、查詢。(2)用戶消費信息，通過給定日期進行查詢。(3)用戶充值信息，同樣通過給定提起進行查詢。(4)用戶賬戶信息，在查詢消費信息和充值信息的時候在網(wǎng)頁上都同時顯 示賬戶余額。第2章系統(tǒng)的UMLS本模型2.1 UML初始模型選擇菜單【File->New】可以打開如下圖所示的“ Create New Model”對話框，選擇J2SE模式，點擊【ok】按鈕，表示此系統(tǒng)將用Java語言來開發(fā)。接下來

7、開始設(shè)計自己的模型，在此之前先保存，將模型命名為“基于校園卡 的食堂消費信息管理系統(tǒng)”，如下圖所示：gj曷于校園卡的食堂消費信息管理系蜻 由（3 Use Case View 田匚。Log£ c aH. Vi ew國Cwiponent Vi 卦，Deployment View | 一匾 Mod虱 Trapertieg圖2-1 UML建模初始模型2.2 系統(tǒng)的用例圖根據(jù)系統(tǒng)的需求可以確定四類參與者，分別是學(xué)生和教師、營業(yè)員、數(shù)據(jù)庫、 銀行，參與者的詳細信息如下：學(xué)生和教師：是持有校園卡的任何個人，由于學(xué)生和教師登錄系統(tǒng)之后只是 瀏覽到的自己信息不同，所以可以將兩者統(tǒng)稱為用戶，可以通過本系

8、統(tǒng)查詢個人 的基本信息、某時間段的消費明細或者充值明細；可以辦理校園卡掛失和解掛； 可以通知注冊中心補辦新卡；可以到指定的地點為一卡通充值。管理員：是校園卡的管理者，通過校園卡的服務(wù)器端進行管理工作。在客戶 端方面，接收用戶充值的請求，并且接收系統(tǒng)的為用戶辦理新卡的通知。數(shù)據(jù)庫：是服務(wù)器端的數(shù)據(jù)庫存儲器，負責接收用戶輸入的信息，并將相應(yīng) 的信息顯示給用戶。銀行：是任何在網(wǎng)上開通網(wǎng)上銀行的銀行網(wǎng)上系統(tǒng)，可以接收用戶輸入的信 息，并執(zhí)行相應(yīng)的數(shù)據(jù)處理服務(wù)，之后將處理結(jié)果傳遞給服務(wù)器端的數(shù)據(jù)庫。根據(jù)以上描述，可以確定系統(tǒng)用例圖包括三部分登錄系統(tǒng)、充值業(yè)務(wù)、其他 業(yè)務(wù)。其中，用戶登錄的是客戶端系統(tǒng)，管

9、理員所登陸的是服務(wù)器系統(tǒng)。識別用例：校園卡客戶端系統(tǒng)的功能簡單，只需要一層用例即可表示。根據(jù)系統(tǒng)的需求可以確定用例包括6個：查詢信息（包括查詢用戶信息、查詢消費信 息、查詢充值信息、查詢余額四類信息）、掛失和解掛、補辦新卡、銀行轉(zhuǎn)賬充 值、維護用戶信息。維護用戶信息圖2-2系統(tǒng)參與者總的用例圖【用例說明】：(1)查詢信息：在用戶登陸系統(tǒng)之后，查詢注冊信息、消費信息還有卡上 余額信息用例，而且此用例的執(zhí)行時依賴于后臺數(shù)據(jù)庫的。(2)銀行轉(zhuǎn)賬充值：可以根據(jù)卡號為校園卡直接進行網(wǎng)上銀行轉(zhuǎn)賬充值。(3)掛失和解掛：在用戶登陸系統(tǒng)之后，可以辦理掛失和解掛，在系統(tǒng)中 提交辦理掛失和解掛。(4)補辦新卡：在

10、用戶登錄系統(tǒng)之后，提交補辦新卡的請求，而在系統(tǒng)管 理員進入系統(tǒng)之后可以受理用戶補辦新卡的請求將舊卡的信息完整復(fù)制到新卡 上面去。(5)維護用戶信息：在系統(tǒng)管理員進入系統(tǒng)之后，對數(shù)據(jù)庫中的用戶信息 進行更新操作，對離職的教師、畢業(yè)的學(xué)生信息做刪除或者清空操作。2.3系統(tǒng)的時序圖本系統(tǒng)的時序圖包括以下幾個：(1)查詢信息時序圖：查詢功能在用戶打開查詢界面后，對于基本信息查詢，系統(tǒng)接收到學(xué)號后執(zhí) 行查詢，并直接將數(shù)據(jù)庫的信息顯示給學(xué)生，相對的收到工號后執(zhí)行查詢，并將 數(shù)據(jù)庫中的信息顯示給老師；對于消費明細查詢和充值明細查詢， 用戶輸入開始 和結(jié)束時間并確定查詢后，數(shù)據(jù)庫接收學(xué)號或工號、查詢的開始時間

11、和結(jié)束時間， 執(zhí)行查詢，并將信息顯示給用戶。(2)網(wǎng)銀轉(zhuǎn)賬時序圖：用戶打開轉(zhuǎn)賬界面后，輸入轉(zhuǎn)賬金額，然后確定轉(zhuǎn) 賬，系統(tǒng)接收學(xué)號和金額跳到網(wǎng)銀界面， 當用戶在網(wǎng)上銀行轉(zhuǎn)賬成功后，網(wǎng)銀將 成功信息傳給數(shù)據(jù)庫，數(shù)據(jù)庫保存數(shù)據(jù)成功后，將信息回顯給用戶。十-1#®轉(zhuǎn)賬界面 |轉(zhuǎn)賬信息輸jW數(shù)據(jù)庫 -入界面 |:用戶-1%入姓名密緲T”2:進入主界面0-3:進入查詢I I4：丫 4:輸入金額f_4一5:輸入網(wǎng)銀密碼.6:錄入數(shù)據(jù)庫.7:信息顯示11圖2-4網(wǎng)銀轉(zhuǎn)賬時序圖(3)補辦新卡、掛失解掛順序圖：用戶打開掛失和解掛界面并確定該業(yè)務(wù)后，系統(tǒng)根據(jù)學(xué)號修改數(shù)據(jù)庫信息，并將信息回顯該用戶:用戶掛失

12、解掛界補辦新卡界數(shù)據(jù)庫1L輸入姓名密碼2:進入主界面- >3：掛失解掛-I5：錄入數(shù)據(jù)庫、6：信!表顯不JLVTI4：補辦新卡 /圖2-5補辦新卡、掛失解掛時序圖2.4系統(tǒng)的協(xié)作圖(1)用戶登陸以后查找消費充值信息的協(xié)作圖:1：輸入用戶名密碼：用戶4登陸>查詢消費充值 信息>f2:輸入查詢?nèi)掌?:查找信息4:返回要查找的信息內(nèi)容：數(shù)據(jù)庫圖2-6查找信息的協(xié)作圖(2)用戶登陸以后掛失、解掛校園卡的協(xié)作圖:2：輸入身份證號3：更改數(shù)據(jù)庫中卡的狀態(tài)1：輸入用戶名密碼：用戶4：顯示卡的狀態(tài)：數(shù)據(jù)庫圖2-7辦理掛失解掛的協(xié)作圖(3)用戶登陸后進行網(wǎng)銀轉(zhuǎn)賬的協(xié)作圖：用戶3：更改賬戶余額4

13、：顯示賬戶余額：數(shù)據(jù)庫2.5系統(tǒng)的狀態(tài)圖(1)數(shù)據(jù)庫的狀態(tài)圖：數(shù)據(jù)庫的狀態(tài)比較復(fù)雜，剛開始處于空閑狀態(tài)，接 收到查詢請求的時候進入查詢狀態(tài)，接收到更新數(shù)據(jù)請求的時候進入到更新數(shù)據(jù) 的狀態(tài)，這些操作都是在數(shù)據(jù)庫中存儲的表上進行操作的，當對表的操作結(jié)束， 查詢的信息提交給系統(tǒng)，數(shù)據(jù)庫又恢復(fù)到空閑的狀態(tài)。圖2-9數(shù)據(jù)庫狀態(tài)圖(2)校園卡的狀態(tài)圖：校園卡從正常使用到已被刪除，總共經(jīng)歷了如下幾 個狀態(tài)。圖2-10校園卡狀態(tài)圖2.6系統(tǒng)的活動圖在本系統(tǒng)中，用到的活動圖有以下5個，所有的活動圖均分為用戶和系統(tǒng)兩 個泳道：(1)登陸系統(tǒng)活動圖：用戶申請登錄系統(tǒng)，接著系統(tǒng)要求輸入密碼，然后 用戶輸入密碼，最后系

14、統(tǒng)判斷用戶名和密碼的正確性， 并由此響應(yīng)是進入系統(tǒng)還 是保留申請登陸狀態(tài)。K 提示用戶輸入 姓名和密碼用戶信息輸 入錯誤/顯 示登錄失敗 信息二/輸入正確/顯示登錄成功信息圖2-11登陸系統(tǒng)的活動圖(2)轉(zhuǎn)帳充值活動圖：在成功登陸之后，首先用戶申請轉(zhuǎn)帳，然后系統(tǒng)要求用戶輸入轉(zhuǎn)帳金額并選擇銀行，然后進入網(wǎng)銀系統(tǒng)進行轉(zhuǎn)帳操作，之后后， 若 轉(zhuǎn)帳成功，系統(tǒng)修改數(shù)據(jù)庫，最后將轉(zhuǎn)帳成功信息提示給用戶， 否則提示用戶失 敗信息。用戶銀行輸入轉(zhuǎn)賬金選擇轉(zhuǎn)賬銀輸入密碼錯誤提示用戶輸 入網(wǎng)銀密碼進入到轉(zhuǎn)賬 頁面系統(tǒng)提示用戶選 擇銀行JV增加校園卡中. 相應(yīng)的余額提示用戶轉(zhuǎn) 賬成功/繼續(xù)提示輸入密碼減少銀行卡 中

15、的余額¥提示用戶輸、入轉(zhuǎn)賬金額J圖2-12轉(zhuǎn)賬充值的活動圖(3)查詢消費信息的活動圖：在成功登陸系統(tǒng)之后，先進入到查詢消費信息的頁面，輸入指定的日期，系統(tǒng)開始查找數(shù)據(jù)庫中的信息，顯示給用戶用戶系統(tǒng)數(shù)據(jù)庫進入到信息 查詢頁面提示3戶輸入日期 X rA>L輸入要查詢的開始、 日期和截止日期 1I 合并1瀏覽返回信息114注銷登錄將查找請求提交給數(shù)據(jù)庫服務(wù)器|1查找對應(yīng)日期的數(shù)據(jù)、信息并提交給系統(tǒng)“IV一顯示數(shù)據(jù)庫.:.信J9存在/分支中的信息八提示用戶對應(yīng) V 1言息不存在'一信息不存在J圖2-13查詢消費信息的活動圖第 3 章 系統(tǒng)中的類3.1 類圖的生成本系統(tǒng)所需要的類

16、的確定只要考慮一下幾點：主要功能中，查詢功能只需要通過學(xué)號訪問數(shù)據(jù)庫，轉(zhuǎn)賬業(yè)務(wù)、補辦新卡和掛失解掛業(yè)務(wù)只需要通過學(xué)號修改數(shù)據(jù)庫。查詢界面的功能只需要取學(xué)生卡號和查詢信息的時間段（包括開始時間和結(jié)束時間） ；補辦新卡和掛失解掛界面只需要取學(xué)號即可；轉(zhuǎn)賬界面需要用到學(xué)號和金額信息；辦理定期轉(zhuǎn)賬界面需要用到卡號和銀行卡號、每次轉(zhuǎn)賬的金額。因此這些界面的功能都非常簡單，所有的功能只要寫在一個控制類里面即可。對于用戶的數(shù)據(jù)取得，需要用到數(shù)據(jù)庫，由于數(shù)據(jù)庫的查詢修改刪除工作所要編寫的類本身就有一定量，故本系統(tǒng)的關(guān)于數(shù)據(jù)庫的類都另外定義在實體類里面。（ 1）定義系統(tǒng)控制類控制類是主要負責其它類工作的類。如：

17、主程序類、主窗體類。本系統(tǒng)中的實體類有：用戶登陸類（Login ）和主程序類（Main） 。（ 2）定義系統(tǒng)邊界類邊界類位于系統(tǒng)與外界的交界處。如： 窗體類、 報表類、 描述通信協(xié)議的類、直接與外設(shè)交互的類、直接與外部系統(tǒng)交互的類。本系統(tǒng)較簡單，各個界面要實現(xiàn)的功能均由主程序?qū)崿F(xiàn)，不需要專門的邊界類。（ 3）定義系統(tǒng)實體類實體類描述要保存到持久存儲體中的信息。如：數(shù)據(jù)庫、各種形式的數(shù)據(jù)文件中的信息。實體類有以下幾個：DataBase-負責連接數(shù)據(jù)庫：UserInfo 、 CostInfo 、 SaveInfo- 查詢基本信息、消費明細以及充值明細的數(shù)據(jù)庫處理類GetNewCard補辦新卡的數(shù)據(jù)

18、庫處理類LostAndBack-掛失和解掛的數(shù)據(jù)庫處理類BankTransfer- 銀行轉(zhuǎn)賬的數(shù)據(jù)庫處理類Login- 用戶登錄的類3.2 各類之間的關(guān)系各個類的操作都是依賴于數(shù)據(jù)庫類的，所以在繪制類圖的時候，把數(shù)據(jù)庫類BataBase放置在中間，其他類圍繞在其周圍，與它都是依賴關(guān)系。Userinfo/用ql String骷有即舊 Siringu 與 erlEoSeafch。CostInfo< sql : Slrifkg 除usa口口 String startDate : Date 屈電足口3o pe nCOnnec gnO* loseConnection0 jury。 Update(&

19、gt;DateSaveinfo 品sql: String it-口 : Siring slartDate : Date endDate DmlecostlnfoSearch)*saelnfbSearch(；Logi n年腦日rName : Stringpassword ： Stringchk&ck()DataBase懇ql String 縱nt :ConnectionGctNewCard rUseriD : Stnng is New : Int 唾與 ql StungBankTnansfer： String 防sql : String 電HnkNaEe : Stnng 息加函口 ： S

20、tring 百治DatebankTransfer()圖3-1系統(tǒng)類之間的關(guān)系圖【類圖說明】：上述的所有類中都包含有共同的參數(shù)，那就是String類型的傳遞給數(shù)據(jù)庫的參數(shù)sql ,里面存放的是傳遞給數(shù)據(jù)庫的信息。UserInfo是查詢基本信息的類，可以查詢數(shù)據(jù)庫中的用戶基本信息，屬性 包括用戶的賬戶號等，操作包括查找用戶信息的方法userInfoSearch();CostInfo是查詢消費信息的類，里面新增了兩個屬性那就是開始日期和結(jié) 束日期，用來確定所要查詢的信息所在的時段，而操作函數(shù)costInfoSearch()的調(diào)用可以顯示出消費信息和賬戶余額；SavaInfo是查詢充值信息的類，其構(gòu)造

21、和 CostInfo類類似，也需要加入開 始日期和結(jié)束日期，用來確定所要查詢信息的時段，而操作函數(shù)costInfoSearch() 的調(diào)用，可以顯示出消費信息和賬戶余額；Login是用戶登陸類，必須包括的屬性有用戶名和密碼，操作方法check()里面需要有連接到數(shù)據(jù)庫的操作，驗證登陸的用戶是否存在于數(shù)據(jù)庫中，驗證用 戶輸入的密碼是否與數(shù)據(jù)庫中的密碼匹配；LostAndBack 是為用戶辦理掛失和解掛校園卡的類，必須包括的屬性有State 類型的參數(shù)，代表校園卡當前的狀態(tài)，類里面還有兩個操作方法get() 、lost() 分別調(diào)用，用來辦理掛失和解掛；GetNewCard是補辦新卡的類，里面有的

22、操作方法newCard()是用來將原來掛 失的卡上的信息復(fù)制到新卡上的方法；BankTransfer 是辦理網(wǎng)上銀行轉(zhuǎn)賬的類，其中的屬性bankNam、e bankID、Date 是用來記錄交易信息的，如交易銀行的名字、交易號、交易時間，里面的 操作方法bankTransfer() 的調(diào)用可以為校園卡充值，并將余額信息存入到數(shù)據(jù)庫當中；DataBase 是 系 統(tǒng) 用 來 連 接 到 數(shù) 據(jù) 庫 的 類 ， 里 面 有 四 個 操 作 方 法 ， openConnection() 和 closeConnection() 者兩個操作方法的設(shè)計是為了防止多個 的用戶并發(fā)訪問數(shù)據(jù)庫的時候出錯，而 Q

23、uery() 和 Update() 兩個方法則是對數(shù)據(jù)庫表中數(shù)據(jù)的操作，分別是查詢和更新數(shù)據(jù)。第4章系統(tǒng)的配置與實現(xiàn)4.1系統(tǒng)的組件圖基于校園卡的食堂消費管理信息系統(tǒng)主要有兩種組件圖，業(yè)務(wù)對象組件和用 戶界面組件。(1)業(yè)務(wù)對象組件：UserInfo.javaSaveInfo.java圖4-1業(yè)務(wù)包Business中所有的組件【業(yè)務(wù)對象組件圖說明】：UserInfo.java是查詢基本信息的類，可以查詢數(shù)據(jù)庫中的用戶基本信息；CostInfo.java 是查詢消費信息的類，同時可以顯示出賬戶余額；SavaInfo.java 是查詢充值信息的類，同時可以顯示出賬戶余額；Login.java 是用

24、戶登陸類，里面需要有連接到數(shù)據(jù)庫的操作，驗證登陸的用戶是否存在于數(shù)據(jù)庫中，驗證用戶輸入的密碼是否與數(shù)據(jù)庫中的密碼匹配；LostAndBack.java是為用戶辦理掛失和解掛校園卡的類；GetNewCard.java是補辦新卡的類；BankTransfer.java 是辦理網(wǎng)上銀行轉(zhuǎn)賬的類；DataBase.java是系統(tǒng)用來連接到數(shù)據(jù)庫的類。將各種用戶不同的業(yè)務(wù)操作封裝成不同的類，也就是一個個的工作產(chǎn)品組件, 再把這些類組合成一個包Business ,充分體現(xiàn)面向?qū)ο蟮乃枷?2)用戶界面組件圖QueryWindow.javaMainWindow.javaBankTransferWindow.j

25、ava NewCardWindow.java圖4-2用戶界面包Swing中所有的組件【用戶界面組件圖說明】：MainWindow.java是用戶登陸系統(tǒng)后，系統(tǒng)呈現(xiàn)給用戶的主界面。Query.java是用戶在提交查詢信息請求之后，系統(tǒng)呈現(xiàn)給用戶的界面。BankTransfer.java 是用戶在提交網(wǎng)銀轉(zhuǎn)賬的請求之后，系統(tǒng)呈獻給用戶的 界面。NewCardWindow.java是用戶有補辦新卡的需要是進入的界面。上述業(yè)務(wù)對象組件和用戶界面組件都是添加了包規(guī)范的組件。系統(tǒng)的整體組件圖如下圖所示，包括系統(tǒng)服務(wù)、用戶(教師和學(xué)生)、數(shù)據(jù)庫服務(wù)3個組件，從組件的分類上來看，三者都屬于配置組件，是運行系

26、統(tǒng)必須 要配置的組件，是形成可執(zhí)行文件的基礎(chǔ)?；谛@卡的食堂 消費信息管理系統(tǒng)系統(tǒng)服務(wù)用戶服務(wù)數(shù)據(jù)服務(wù)圖4-3系統(tǒng)的組件圖4.2系統(tǒng)的配置圖配置圖主要是用來說明如何配置系統(tǒng)的軟件和硬件。系統(tǒng)配置由以下幾個節(jié)點構(gòu)成<<局域網(wǎng)>><<Internet>><<Internet>>圖4-4系統(tǒng)配置圖【配置圖說明】：應(yīng)用服務(wù)器用來協(xié)調(diào)整個系統(tǒng)的總體協(xié)調(diào)工作；數(shù)據(jù)庫負責數(shù)據(jù)管理和所有信息的存儲；客戶機通過互聯(lián)網(wǎng)與應(yīng)用服務(wù)器相連， 這樣，系統(tǒng)管理員可以通過互聯(lián)網(wǎng)管 理應(yīng)用程序服務(wù)器，用戶則可以通過互聯(lián)網(wǎng)訪問基于校園卡和食堂消費信息管理

27、 系統(tǒng)。第 5 章 小結(jié)本次UML勺課程設(shè)計是對基于校園卡的食堂消費信息管理系統(tǒng)進行建模，首先我們做了系統(tǒng)需求分析，知道了系統(tǒng)需要的一些功能需求和非功能需求，然后將系統(tǒng)的整體架構(gòu)分為3 個模塊進行設(shè)計，分別是數(shù)據(jù)庫管理模塊、基本業(yè)務(wù)模塊、信息查詢模塊。然后分別用UML®用建模語言對本系統(tǒng)從不同的角度進行建 模描述，換句話說，UM呢供了從不同的角度去觀察和展示系統(tǒng)的各個特征的標 準和方法。在UML中，從任何一個角度對系統(tǒng)所做的抽象都可以用幾種模型圖來 描述，而這些來自不同角度的模型圖最終組成了系統(tǒng)的完整的模型。用例圖是需求分析到系統(tǒng)實現(xiàn)的第一步，是非常關(guān)鍵的，它描述了人們希望如何使用一

28、個系統(tǒng)。時序圖描述了對象之間傳送消息的時間順序。協(xié)作圖描述了對象之間相互交互的關(guān)系?；顒訄D著重表現(xiàn)一個活動到另一個活動的控制流，是內(nèi)部處理驅(qū)動的流程，而狀態(tài)圖則著重描述從一個狀態(tài)到另外一個狀態(tài)的流程，主要有外部事件的參與。組件圖描述了軟件的各組件和她們之間的依賴關(guān)系。配置圖描述了運行軟件的系統(tǒng)中硬件和軟件的物理結(jié)構(gòu)，即系統(tǒng)執(zhí)行處理中系統(tǒng)系統(tǒng)資源元素的配置情況以及軟件到這些資源元素的映射。只要能夠繪出這些關(guān)鍵的圖，就可以從各個方面非常好的理解系統(tǒng)。要想設(shè)計出好的軟件，建模都很重要，軟件的開發(fā)問題不僅僅是寫代碼，而是怎么樣正確的寫代碼和怎么樣少些代碼，這就使得高質(zhì)量的軟件開發(fā)變成了一個結(jié)構(gòu)、過程和

29、工具箱結(jié)合的問題，所以說，如果沒有對結(jié)構(gòu)、過程和工具加以考慮，所造成的失敗是慘重的。每個失敗的軟件項目都有其特殊的原因，但是成功的項目在許多方面是相似的。軟件組織獲得成功的因素有很多，但是一個基本的因素是對建模工具的使用。模型提供系統(tǒng)的藍圖，包含細節(jié)設(shè)計，也包含對系統(tǒng)的總體設(shè)計。一個好的模型包括重要的因素，而忽略不相關(guān)的細節(jié)。每一個系統(tǒng)可以從不同的方面使用不同的模型進行描述，因此每個模型都是對系統(tǒng)從語義上的抽象。模型可以是結(jié)構(gòu)的、側(cè)重于系統(tǒng)的組織，也可以是行為的、側(cè)重于系統(tǒng)的動作?，F(xiàn)代的軟件開發(fā)采用面向?qū)ο蟮姆椒?。主要的模塊是類或者對象，比如在考慮包含界面、中間層和數(shù)據(jù)庫的簡單的系統(tǒng)。在用戶界

30、面層上，有一些具體的對象，例如按鈕、菜單以及對話框。在數(shù)據(jù)庫中，也有一些具體的對象，例如包含系統(tǒng)所需信息的表、視圖。面向?qū)ο笾允乾F(xiàn)在軟件開發(fā)的主流，原因非常簡單，因為它已經(jīng)被證實在任何情況下，都能夠很好的建模，而且，大多數(shù)現(xiàn)代的編程語言、操作系統(tǒng)和編程工具都是不同形式的面向?qū)ο蟮捏w現(xiàn)。在建模過程中，我從不了解到熟悉 UML®模，雖然在過程中遇到許多問題，諸如某些操時序圖的順序、組件圖的組建構(gòu)造等，通過詢問查看書本和上網(wǎng)查找資料，漸漸解決了一個又有一個問題，對統(tǒng)一建模的概念也越來越清晰。通過本次可設(shè)我對Rational Rose的UMLft能運用更加系統(tǒng)、更加熟練地了解了，在一個軟

31、件工程中起著一個非常重要的作用。這讓我明白，要開發(fā)好一款軟件首先要做的就是對軟件的分析建模，完整的建?？梢杂欣陂_發(fā)人員的軟件設(shè)計展示開發(fā)系統(tǒng)做到與客戶良好的溝通協(xié)調(diào)。UML勺知識是十分豐富的，我將會在以后的 學(xué)習(xí)中，不斷提高自己的UML®識。在以后的其他課程設(shè)計上，設(shè)計系統(tǒng)時考慮 系統(tǒng)的UML真型，這樣不僅能夠提高我的UM健模水平，還能更加高效地統(tǒng)一規(guī) 劃設(shè)計的程序軟件系統(tǒng)。在對于基于校園卡的食堂消費信息管理系統(tǒng)的需求分析數(shù)據(jù)模塊等的劃分后，開始定義UML勺建模。建模的目的是便于開發(fā)人員展現(xiàn)系統(tǒng)；允許開發(fā)人員指定系統(tǒng)的結(jié)構(gòu)或行為；提供指導(dǎo)開發(fā)人員構(gòu)造系統(tǒng)模板；記錄開發(fā)人員的決策。在目的明確的情況下還要遵循認真選擇模型；每個模型可以有多種表達方式；最好的模型總是能夠切合實際；孤立的模型是不完整的這四個原則把現(xiàn)實的食堂消費信息管理系統(tǒng)進行模型構(gòu)建的簡化呈現(xiàn)。明確所有需要的UM堆模概念后開始選擇選