第一篇：UML建模--銀行管理系統（范文）
銀行管理系統的UML
建模
課程設計報告
專業：
學號：
姓名：
任課教師：
一、系統概述
銀行是與人們生活密切相關的一個機構，銀行可以提供存款、取款、轉賬等業務。在銀行設立賬戶的人或機構被稱為銀行的客戶（customer）。一個客戶可以在銀行開設多個賬戶（account），客戶可以存錢到賬戶中，也可以從自己的賬戶中取錢，還可以將存款從一個賬戶轉到另一個賬戶。另外，客戶可以隨時查詢自己的賬戶情況，以及查詢以前所進行的存款、取款等交易記錄?？蛻暨€有權利要求關閉自己的賬戶。
實際生活中的銀行功能其實還要復雜得多，但為了簡化系統，本次設計只考慮銀行的基本功能。簡化版的銀行信息系統至少應具有如下功能：
1.一個銀行可以有多個賬戶； 2.一個銀行可以有多個客戶； 3.一個客戶可以持有多個賬戶； 4.一個賬戶可以有多個持有者； 5.銀行可以為客戶開設賬戶； 6.銀行可以為客戶注銷賬戶； 7.客戶可以從自己賬戶中取錢； 8.客戶可以向自己賬戶中存錢；
9.客戶可以在同一銀行的不同賬戶之間轉賬； 10.客戶可以在不同銀行的不同賬戶之間轉賬； 請完成登錄、存款、取款、轉賬和查詢幾個模塊的設計。
二、需求分析
銀行系統是與生活緊密相關的一個機構，銀行提供了存款、取款、轉賬等業務。在銀行設立賬戶的人或機構通常被稱為銀行的儲戶。一個儲戶可以在銀行開多個賬戶，儲戶可以存錢到賬戶中，也可以從自己的賬戶中取現，還可以將存款從一個賬戶轉到另一個賬戶。儲戶還可以隨時查詢自己賬戶的情況，并查詢以前所進行的存款、取款等交易記錄。后臺管理員可以對客戶的賬戶進行注銷、刪除、查詢等管理，還有就是銀行利息、匯率、手續費之類參數的設置，以及財務管理以及財務分析。
軟件分別有開戶，查詢存取款，轉賬等功能。各個模塊各有不同的功能，但都能完成查詢和存取功能。各模塊的數據都存放在數據庫中。數據的調用和連接都有程序來完成。
此軟件所要完成的主要功能有三方面：如果是存款，用戶填寫存款單，然后交給收銀員鍵入系統，同時系統還要記錄存款人姓名，住址，身份證號碼，存款類型，存款日期，利率及密碼（可選）等信息，完成后由系統反饋成功存款信息給用戶。如果是取款，用戶填寫取款的相關信息（取款金額、取款幣種）進行提交，系統要求用戶輸入密碼以確認身份，核對密碼正確無誤后系統計算利息并印出利息單給用戶。如果是轉賬，用戶填寫轉賬的相關信息進行提交，系統要求用戶輸入密碼以確認身份，核對密碼正確無誤后系統計算利息并反饋信息給用戶。系統及時更新數據庫。
外部功能：實現化窗口，開戶/銷戶、存款/取款、查詢/轉賬。
內部功能：同步，過濾，定位，識別，更新，連接。
三、系統的UML基本模型
（1）、用例圖
通過分析對銀行管理系統的需求分析，確定參與者有銀行客戶、收銀員。收銀員具有維護系統信息、維護客戶信息、查詢客戶情況和處理處理客戶需求的作用。用例包括：
1）開戶、2）存款、3）取款、4）轉賬、5）查詢、6）銷戶等
（2）、用例描述：
用例名稱：銀行信息系統
描述：銀行客戶對需要辦理業務的需求以及收銀員對事件的處理。
（3）、銀行信息系統的事件流
1.用例存款的事件流
1.1 前置條件
在存款之前，客戶已經辦理銀行賬號并且帶來現金若干，并到達銀行網點。1.2 后置條件
如果這個用例成功，這個存款事件是成功的，否則，系統沒有變化。1.3 擴充點
無 1.4 事件流
1.4.1 基流（1）客戶將銀行卡交給收銀員。
（2）收銀員要求客戶輸入卡密碼。
（3）客戶輸入卡密碼，并確認密碼。
（4）收銀員提示，請客戶選擇服務類型。
（5）客戶選擇存款服務。
（6）收銀員提示：存款數目。
（7）客戶說出數目，并把錢交給收銀員。
（8）收銀員完成服務。
（9）收銀員退還卡。1.4.2 替代流
如果輸入的密碼無效，用戶可以重新輸入密碼或者終止用例。
2.用例轉賬的事件流
2.1 前置條件
在轉賬之前，客戶已經辦理銀行賬號，被轉賬人的賬號已經存在并且已經知道了對方的賬號。
2.2 后置條件
如果這個用例成功，這個轉賬事件是成功的，否則，系統沒有變化。2.3 擴充點
無 2.4 事件流
2.4.1 基流
（1）客戶填寫轉賬單。
（2）客戶把轉賬單和銀行卡交給收銀員。
（3）收銀員要求客戶輸入卡密碼。
（4）客戶輸入卡密碼，并確認密碼。
（5）收銀員轉賬成功。
（6）收銀員退還卡。2.4.2 替代流
如果輸入的密碼無效，用戶可以重新輸入密碼或者終止用例。
3.用例查詢的事件流
3.1 前置條件
在查詢之前，客戶已經辦理銀行賬號并且攜帶銀行卡，并到達銀行網點。3.2 后置條件
如果這個用例成功，這個查詢事件是成功的，否則，系統沒有變化。3.3 擴充點
無 3.4 事件流
3.4.1 基流
（1）客戶將銀行卡交給收銀員。
（2）收銀員要求客戶輸入卡密碼。
（3）客戶輸入卡密碼，并確認密碼。
（4）收銀員提示，請客戶選擇服務類型。（5）客戶選擇查詢服務。
（6）客戶說出查詢內容，收銀員將內容反饋給客戶。
（7）收銀員完成服務。
（8）收銀員退還卡。3.4.2 替代流
如果輸入的密碼無效，用戶可以重新輸入密碼或者終止用例。
（4）、活動圖
活動圖是基于對象的狀態變遷所繪制的視圖。
收銀員首先憑著自己的系統用戶名和密碼登錄系統，收銀員可以通過銀行客戶提供的有效證件號開戶，提供客戶賬號開戶、存款、取款、轉賬、查詢、銷戶等功能，最后退出系統。
1．存款活動圖
2．轉賬活動圖
3．查詢活動圖
（5）、時序圖
時序圖（Sequence Diagram）主要用于按照交互發生的一系列順序，顯示對象之間的這些交互。收銀員通過用戶賬號和密碼登錄系統，在系統的操作窗口對需要存款、取款、轉賬、查詢、銷戶的用戶進行操作，最后退出操作窗口。
我們所開發的銀行管理系統時序圖如圖所示：
（6）、類圖
類圖是對象結構建模的一部分，類圖描述系統中類的靜態結構。類圖是代碼生成（將模型轉化為代碼）的來源，也是逆向工程（將代碼轉化為模型）的目標設生成物。
類圖設計如下圖：
系統中主要的類（1）用戶類： 它的屬性有用戶名（Name）、密碼（Password）、銀行卡號（Cardnumber）、用戶身份證號碼（ID）。
操作包括修改密碼（Changpassword）、存款（deposit）、取款（cash）、轉賬（transfer）、查詢（Chaxun）、、用戶開戶（Registered）。
（2）系統類：
它的屬性有電腦號（Computernumber）、機器地址（Mac）。本身的操作沒有，但有被管理員使用的操作。（3）收銀員類：
它的屬性有用戶名（name）、密碼（password）。
操作包括用戶開戶（Registeredusers）、注銷用戶（Deleteusers）、查詢用戶信息（Chaxun）、系統維護（Weihu）。
（7）狀態圖
狀態圖用來表示建模對象是如何改變其狀態的，狀態定義為對象行為在某一時刻的快照或轉折點。
四、結論
系統主要的實現目標是實現客戶開戶、存款、取款、轉賬、查詢、銷戶和后臺服務器端系統的設計，提供完善的功能設計。
五、總結及心得體會
UML工具很好的幫助我們實現了對銀行信息系統的設計，通過UML建模，把事物從抽象到實例化的過程，對每個對象進行細化分析，從而得到簡單而方便，容易理解的模型結構。通過此次試驗收獲很大，使我們認識到了通過UML模型可以高效完成軟件設計，收獲頗豐。
一、開發背景與目標
1.1開發背景
本系統選題為銀行存儲系統，是模擬銀行存儲開發的。隨著計算機的飛速發展及應用領域的擴大，特別是計算機網絡和電子商務的發展，極大的改變了商業銀行傳統的經營模式。能夠為客戶提供方便、快捷、安全的服務，也能夠有效的降低銀行的營運成本，這是銀行存儲系統追求的目標。目前，對于現代化銀行運營的要求是客戶可以實現方便安全的業務交易，銀行職員可以進行高效合理的工作管理，實現銀行業務電子化
在銀行管理系統中，系統包括4個節點，分別是：銀行管理員業務處理節點、ATM自動取款機節點、系統維護節點、數據庫節點。
銀行管理員業務處理節點，銀行管理員通過該節點辦理相應業務； ATM自動取款節點，用戶通過該節點進行自動取款服務；
系統維護節點，系統管理員通過該節點進行后臺維護，執行銀行管理員允許的所有操作；數據庫節點，負責數據的存儲與處理。
誰使用系統的主要功能?誰改變系統的數據? 誰從系統獲取信息? 誰需要系統的支持才能完成日常的工作任務?誰負責維護,管理并保持系統的正常運行?系統需要應付,處理那些硬件設備?系統需要和那些外部系統交互?誰(或是什么)對系統運行產生的結果感興趣?
用例圖主要用來描述“用戶、需求、系統功能單元”之間的關系。它展示了一個外部用戶能夠觀察到的系統功能模型圖。
【用途】：幫助開發團隊以一種可視化的方式理解系統的功能需求
第二篇：UML建模--銀行管理系統
銀行管理系統的UML
建模
課程設計報告
專業：
學號：
姓名：
任課教師：
一、系統概述
銀行是與人們生活密切相關的一個機構，銀行可以提供存款、取款、轉賬等業務。在銀行設立賬戶的人或機構被稱為銀行的客戶（customer）。一個客戶可以在銀行開設多個賬戶（account），客戶可以存錢到賬戶中，也可以從自己的賬戶中取錢，還可以將存款從一個賬戶轉到另一個賬戶。另外，客戶可以隨時查詢自己的賬戶情況，以及查詢以前所進行的存款、取款等交易記錄?？蛻暨€有權利要求關閉自己的賬戶。
實際生活中的銀行功能其實還要復雜得多，但為了簡化系統，本次設計只考慮銀行的基本功能。簡化版的銀行信息系統至少應具有如下功能：
1.一個銀行可以有多個賬戶； 2.一個銀行可以有多個客戶； 3.一個客戶可以持有多個賬戶； 4.一個賬戶可以有多個持有者； 5.銀行可以為客戶開設賬戶； 6.銀行可以為客戶注銷賬戶； 7.客戶可以從自己賬戶中取錢； 8.客戶可以向自己賬戶中存錢；
9.客戶可以在同一銀行的不同賬戶之間轉賬； 10.客戶可以在不同銀行的不同賬戶之間轉賬； 請完成登錄、存款、取款、轉賬和查詢幾個模塊的設計。
二、需求分析
銀行系統是與生活緊密相關的一個機構，銀行提供了存款、取款、轉賬等業務。在銀行設立賬戶的人或機構通常被稱為銀行的儲戶。一個儲戶可以在銀行開多個賬戶，儲戶可以存錢到賬戶中，也可以從自己的賬戶中取現，還可以將存款從一個賬戶轉到另一個賬戶。儲戶還可以隨時查詢自己賬戶的情況，并查詢以前所進行的存款、取款等交易記錄。后臺管理員可以對客戶的賬戶進行注銷、刪除、查詢等管理，還有就是銀行利息、匯率、手續費之類參數的設置，以及財務管理以及財務分析。
軟件分別有開戶，查詢存取款，轉賬等功能。各個模塊各有不同的功能，但都能完成查詢和存取功能。各模塊的數據都存放在數據庫中。數據的調用和連接都有程序來完成。
此軟件所要完成的主要功能有三方面：如果是存款，用戶填寫存款單，然后交給收銀員鍵入系統，同時系統還要記錄存款人姓名，住址，身份證號碼，存款類型，存款日期，利率及密碼（可選）等信息，完成后由系統反饋成功存款信息給用戶。如果是取款，用戶填寫取款的相關信息（取款金額、取款幣種）進行提交，系統要求用戶輸入密碼以確認身份，核對密碼正確無誤后系統計算利息并印出利息單給用戶。如果是轉賬，用戶填寫轉賬的相關信息進行提交，系統要求用戶輸入密碼以確認身份，核對密碼正確無誤后系統計算利息并反饋信息給用戶。系統及時更新數據庫。
外部功能：實現化窗口，開戶/銷戶、存款/取款、查詢/轉賬。
內部功能：同步，過濾，定位，識別，更新，連接。
三、系統的UML基本模型
（1）、用例圖
通過分析對銀行管理系統的需求分析，確定參與者有銀行客戶、收銀員。收銀員具有維護系統信息、維護客戶信息、查詢客戶情況和處理處理客戶需求的作用。用例包括：
1）開戶、2）存款、3）取款、4）轉賬、5）查詢、6）銷戶等
（2）、用例描述：
用例名稱：銀行信息系統
描述：銀行客戶對需要辦理業務的需求以及收銀員對事件的處理。
（3）、銀行信息系統的事件流
1.用例存款的事件流
1.1 前置條件
在存款之前，客戶已經辦理銀行賬號并且帶來現金若干，并到達銀行網點。1.2 后置條件
如果這個用例成功，這個存款事件是成功的，否則，系統沒有變化。1.3 擴充點
無 1.4 事件流
1.4.1 基流（1）客戶將銀行卡交給收銀員。
（2）收銀員要求客戶輸入卡密碼。
（3）客戶輸入卡密碼，并確認密碼。
（4）收銀員提示，請客戶選擇服務類型。
（5）客戶選擇存款服務。
（6）收銀員提示：存款數目。
（7）客戶說出數目，并把錢交給收銀員。
（8）收銀員完成服務。
（9）收銀員退還卡。1.4.2 替代流
如果輸入的密碼無效，用戶可以重新輸入密碼或者終止用例。
2.用例轉賬的事件流
2.1 前置條件
在轉賬之前，客戶已經辦理銀行賬號，被轉賬人的賬號已經存在并且已經知道了對方的賬號。
2.2 后置條件
如果這個用例成功，這個轉賬事件是成功的，否則，系統沒有變化。2.3 擴充點
無 2.4 事件流
2.4.1 基流
（1）客戶填寫轉賬單。
（2）客戶把轉賬單和銀行卡交給收銀員。
（3）收銀員要求客戶輸入卡密碼。
（4）客戶輸入卡密碼，并確認密碼。
（5）收銀員轉賬成功。
（6）收銀員退還卡。2.4.2 替代流
如果輸入的密碼無效，用戶可以重新輸入密碼或者終止用例。
3.用例查詢的事件流
3.1 前置條件
在查詢之前，客戶已經辦理銀行賬號并且攜帶銀行卡，并到達銀行網點。3.2 后置條件
如果這個用例成功，這個查詢事件是成功的，否則，系統沒有變化。3.3 擴充點
無 3.4 事件流
3.4.1 基流
（1）客戶將銀行卡交給收銀員。
（2）收銀員要求客戶輸入卡密碼。
（3）客戶輸入卡密碼，并確認密碼。
（4）收銀員提示，請客戶選擇服務類型。（5）客戶選擇查詢服務。
（6）客戶說出查詢內容，收銀員將內容反饋給客戶。
（7）收銀員完成服務。
（8）收銀員退還卡。3.4.2 替代流
如果輸入的密碼無效，用戶可以重新輸入密碼或者終止用例。
（4）、活動圖
活動圖是基于對象的狀態變遷所繪制的視圖。
收銀員首先憑著自己的系統用戶名和密碼登錄系統，收銀員可以通過銀行客戶提供的有效證件號開戶，提供客戶賬號開戶、存款、取款、轉賬、查詢、銷戶等功能，最后退出系統。
1．存款活動圖
2．轉賬活動圖
3．查詢活動圖
（5）、時序圖
時序圖（Sequence Diagram）主要用于按照交互發生的一系列順序，顯示對象之間的這些交互。收銀員通過用戶賬號和密碼登錄系統，在系統的操作窗口對需要存款、取款、轉賬、查詢、銷戶的用戶進行操作，最后退出操作窗口。
我們所開發的銀行管理系統時序圖如圖所示：
（6）、類圖
類圖是對象結構建模的一部分，類圖描述系統中類的靜態結構。類圖是代碼生成（將模型轉化為代碼）的來源，也是逆向工程（將代碼轉化為模型）的目標設生成物。
類圖設計如下圖：
系統中主要的類（1）用戶類： 它的屬性有用戶名（Name）、密碼（Password）、銀行卡號（Cardnumber）、用戶身份證號碼（ID）。
操作包括修改密碼（Changpassword）、存款（deposit）、取款（cash）、轉賬（transfer）、查詢（Chaxun）、、用戶開戶（Registered）。
（2）系統類：
它的屬性有電腦號（Computernumber）、機器地址（Mac）。本身的操作沒有，但有被管理員使用的操作。（3）收銀員類：
它的屬性有用戶名（name）、密碼（password）。操作包括用戶開戶（Registeredusers）、注銷用戶（Deleteusers）、查詢用戶信息（Chaxun）、系統維護（Weihu）。
（7）狀態圖
狀態圖用來表示建模對象是如何改變其狀態的，狀態定義為對象行為在某一時刻的快照或轉折點。
四、結論
系統主要的實現目標是實現客戶開戶、存款、取款、轉賬、查詢、銷戶和后臺服務器端系統的設計，提供完善的功能設計。
五、總結及心得體會
UML工具很好的幫助我們實現了對銀行信息系統的設計，通過UML建模，把事物從抽象到實例化的過程，對每個對象進行細化分析，從而得到簡單而方便，容易理解的模型結構。通過此次試驗收獲很大，使我們認識到了通過UML模型可以高效完成軟件設計，收獲頗豐。
第三篇：UML(ATM系統)動態建模
實驗3 動態建模
一、實驗目的與要求 掌握分析ATM系統用例中用例的流程，分析對象之間的交互關系 掌握用UML設計參與對象之間的交互，用狀態圖、時序圖、協作圖和活動圖來描述系統的行為。
二、實驗設備、環境
PC(一臺)，Windows 2000或以上版本，安裝Microsoft Visio 2003
三、實驗內容及步驟 交互圖：實現ATM系統的序列關系圖和通信（協作）關系圖； 2 分析設計軟件系統的狀態圖。（（1）和（2）選做一個狀態圖）；
（1）ATM系統
（2）具體題目如下：某銷售POS機，它的工作流程是：當客戶到收銀臺后，收銀員逐一輸入用戶購買的商品，輸入完之后，計算出總金額，然后等待用戶付款，確定支付成功之后，完成收銀，等待下一個客戶。請為其繪制出相應的狀態機圖。
3分析設計ATM系統的活動圖（選做1個活動圖）。
建立動態模型：
建立序列關系圖、狀態圖、活動圖
步驟：
?
編寫腳本
?
確定各個對象之間的事件
?
構造事件追蹤圖（交互圖）?
構造狀態圖
?
添加活動和動作
一、時序關系圖
1）ATM系統的正常情況腳本
? ATM請儲戶插卡；儲戶插入一張現金兌換卡。? ATM接受該卡并讀它上面的卡號。
? ATM要求儲戶輸入密碼；儲戶輸入自己的密碼“1234”等數字。
? ATM請求系統驗證卡號和密碼；核對儲戶密碼，然后通知顯示器顯示說這張卡有效。
? ATM要求儲戶選擇事務類型（取款、轉賬、查詢等）；儲戶選擇“取款”。? ATM要求儲戶輸入取款額；儲戶輸入“880”。
? ATM確認取款額在預先規定的限額內，然后要求處理這個事務；成功處理完這項事務并返回該賬戶的新余額。
? ATM吐出現金并請儲戶拿走這些現金；儲戶拿走現金。? ATM問儲戶是否繼續這項事務；儲戶回答“不”。
? ATM打印賬單，退出現金兌換卡，請儲戶拿走它們；儲戶取走賬單和卡。? ATM請儲戶插卡。
2）ATM系統的異常情況腳本
? ATM請儲戶插卡；儲戶插入一張現金兌換卡。? ATM接受該卡并順序讀它上面的數字。
? ATM要求密碼；儲戶誤輸入“8888”等數字。
? ATM請求總行驗證卡號和密碼；經驗證發現密碼錯誤，拒絕這張卡。? ATM顯示“密碼錯”，并請儲戶輸入密碼；儲戶輸入“1234”等數字；ATM請求總行驗證后知道輸入密碼正確。
? ATM要求儲戶選擇事務類型；儲戶選擇“取款”。
? ATM詢問取款額；儲戶改變主意不想取款了，按“取消”。? ATM退出現金兌換卡，請儲戶拿走它們；儲戶取走卡。? ATM請儲戶插卡。
ATM 腳本的事件時序圖如下圖所示：（正常情況）
用戶讀卡器顯示器ATM卡用戶賬戶事務提款機插卡讀卡初始化提示輸入密碼輸入密碼驗證密碼獲取密碼獲取賬戶初始化提示選擇業務選擇業務執行事務初始化提示輸入金額輸入金額獲取余額驗證取款金額計算余額計算利息更新賬戶配給現金打印收據退卡
二、狀態圖
主屏]do：顯示主屏幕插卡[可讀]Do：要求密碼輸入密碼Do:驗證賬戶繼續密碼錯拿走卡退卡do：退卡請拿走卡插卡[不可讀]不可讀的卡do：顯示信息取消取消do:顯示取消信息無效賬戶賬戶有效Do:要求類型取消輸入類型Do:要求金額取消結束do：打印賬單Do:顯示無效賬戶信息輸入金額等待5秒Do:處理事務中止取消Do:請求繼續拿走現金do：吐出現金請拿走現金事務成功取消事務失敗Do:失敗信息網絡響應等待網絡響應中斷do：顯示取消信息ATM類的狀態圖
處理事務驗證賬戶請求處理事務請求驗卡事務成功事務失敗無效賬戶賬戶有效密碼錯
事務處理狀態圖
賬戶驗證狀態圖
三、活動圖
插卡<沒有接收動作>輸入密碼<沒有接收動作>輸入賬戶類型輸入金額取卡取錢<沒有發送動作>
四、實驗體會
順序圖的重點是完成某個行為的對象類之間所傳遞的消息的時間順序。一個順序圖事務對象角色，生命線，激活期和消息構成。協作圖用于描述系統的行為是如何有系統的成分合作實現的。協作時一種靜態結構，是一個系統對實現某些服務所涉及的對象及其交互的投影。一個協同定義了一組對某些服務有意義的參加者和它們的聯系，這些參加者定義了交互中的對象所扮演的角色。
第四篇：基于UML的圖書館管理系統建模設計
基于UML的圖書館管理系統建模設計
一、圖書館管理系統可行性分析
隨著政府機關與廣大企事業單位內部網絡的廣泛建立，在通用信息平臺上構筑高效實用的協同工作和自動化辦公應用系統，滿足信息高度共享和即時發布的需求，有效實現內部知識管理，已成為眾多用戶的共同需求。
該圖書管理系統，為圖書館管理提供了一個較好的解決方案。在開發過程中，按照軟件工程的步驟，從設計到開發采用了面向對象的思想和技術，采用了SQL SERVER 2000數據庫，使得本系統可以方便的和其他子系統進行數據交換。同時，注意從軟件的圖形應用界面上優化軟件質量，使得本系統具有很強的可操作性。
二、需求分析
需求分析的目的是深入描述軟件功能和性能，確定軟件設計的約束和軟件同其他系統元素的接口細節，定義軟件的其他有效性需求。2．
1、客戶需求分析
①能夠對圖書進行注冊登記，也就是將圖書的基本信息（如：書的編號、書名、作者、價格等）預先存入數據庫中，供以后檢索。
②能夠對借閱人進行注冊登記，包括記錄借閱人的姓名、編號、班級、年齡、性別、地址、電話等信息。
③提供方便的查詢方法。如：以書名、作者、出版社、出版時間（確切的時間、時間段、某一時間之前、某一時間之后）等信息進行圖書檢索，并能反映出圖書的借閱情況；以借閱人編號對借閱人信息進行檢索；以出版社名稱查詢出版社聯系方式信息。
④提供舊書注銷功能，對于淘汰、損壞、丟失的書目可及時對數據庫進行修改。
⑤能夠對使用該管理系統的用戶進行管理，按照不同的工作職能提供不同的功能授權。⑥對所借圖書情況進行登記，包括借閱時間、借閱人等 ⑦對超出借閱時間、損壞或丟失圖書的讀者進行相應處理 ⑧讀者可以查詢自己的信息 ⑨借書、還書、續借書
2．2 定義系統的邊界和范圍 該系統的邊界為學校的圖書館
該系統的范圍可包括“讀者管理子系統”、“書籍管理子系統”、“借閱管理子系統”、“系統管理子系統” 2.3確定執行者
根據前面介紹的客戶需求分析可以看出。“圖書館管理系統”有三個執行者，即“讀者”、“圖書管理員”、“系統管理員”
1）2）讀者：查詢個人信息、查詢圖書信息、借閱圖書、返還圖書、續借圖書、接受相應處理
圖書管理員：借書處理、還書處理、新舊書登記處理、辦理相應處理手續
3）系統管理員：系統維護工作——學生信息管理、圖書信息管理、系統狀態維護 2.4確定用例
（1）“圖書館管理系統”中的用例
在第一層，根據客戶對“圖書館管理系統”的整體業務功能要求，可選的用例有：
·基本業務功能管理
·基本數據修改 ·信息查詢
·數據庫管理
（2）“基本業務功能子系統”中的用例
在第二層，客戶對“基本業務功能子系統”的整體業務功能要求，可選的用例有： ·借閱管理 ·借書
·續借書 ·還書
（3）“基本數據修改功能子系統”中的用例
在第二層，客戶對“基本數據修改功能子系統”的整體業務功能要求，可選的用例有： ·讀者信息管理 ·讀者信息錄入 ·讀者信息修改 ·讀者信息注銷 ·書籍信息管理 ·書籍信息錄入 ·書籍信息修改
·書籍信息注銷（4）“信息查詢子系統”中的用例
在第二層，客戶對“信息查詢子系統”的整體業務功能要求，可選的用例有： ·圖書信息查詢 ·讀者信息查詢
（5）“數據庫管理子系統”中的用例
在第二層，客戶對“數據庫管理子系統”的整體業務功能要求，可選的用例有： ·借閱管理 2.5分層繪制用例圖
根據系統需求分析中客戶對系統的功能要求，我們一確定了系統和子系統的邊界、執行者和用例，現在就可以繪制用例圖了。
1． 最高層用例圖
根據客戶對“圖書館管理系統”的整體業務功能要求，可以繪制如圖1-1所示的最高層用例圖 2． 第2層用例圖
在第2層用例圖中包括四個用例圖：基本業務功能子系統、基本數據修改功能子系統、信息查詢子系統、數據庫管理子系統。如下圖所示：
System<
System讀者信息銷毀<
System借閱管理系統管理員圖1-5 數據庫管理子系統
2.6 描述用例
1．“借書”用例
用例編號：0102（共有兩層用例圖，每層用2位數字表示，采用4位編號）用例名：借書
執行者：直接執行者：圖書管理員，涉及到的執行者有：讀者、系統管理員 目的：借閱圖書
過程描述：
（1）圖書管理員登陸基本數據修改功能子系統，點擊“借閱管理”中的“借閱”（2）輸入圖書證編號
若輸入不正確，則提示“您輸入的借閱證號碼有誤，請重新輸入！”；輸入正確后，顯示讀者已借閱圖書信息，提示超期未歸還的圖書；（3）輸入圖書編號
若讀者已借滿，提示“您已借滿，請先歸還部分圖書再來借，謝謝！”；若讀者可以正常 4 借閱，提示“您確定要借閱這本書嗎？”
（4）確定借閱圖書，則借閱證號增加一條借閱信息記錄；讀者選擇 “放棄”，回到步驟（3）重新選擇圖書；
（5）讀者成功借閱圖書，系統管理員保存借閱記錄并修改庫存圖書數量、讀者借出數量。
（6）借閱完成，點擊“退出”，退出系統。2．“還書”用例 用例編號：0103 用例名：還書
執行者：直接執行者：圖書管理員，涉及到的執行者有：讀者、系統管理員 目的：歸還圖書 過程描述：
（1）圖書管理員登陸基本數據修改功能子系統，點擊“借閱管理”中的“還書”；（2）輸入圖書證編號；
若輸入不正確，則提示“您輸入的借閱證號碼有誤，請重新輸入！”；輸入正確后，顯示讀者已借閱圖書信息，提示超期未歸還的圖書，有超期未還的圖書，調用“超期罰款”；若讀者說自己丟失圖書，調用“丟失罰款”
（3）輸入要還的圖書編號； 若輸入錯誤，提示“您未借閱該圖書！” 若輸入正確，提示“您確定要歸還這本書嗎？”（4）讀者選擇“確定”，讀者借閱的圖書信息記錄消失；讀者選擇 “放棄”，返回到步驟（3）
（5）完成還書，點擊“退出”，退出系統；
（6）讀者成功歸還圖書，系統管理員刪除借閱記錄，并修改數據庫管理子系統的圖書數量和讀者借出數量。
3．“讀者信息錄入”用例
用例編號：0302 用例名：讀者信息錄入
執行者：直接執行者：系統管理員，間接執行者：讀者 目的：錄入新讀者相關信息，包括姓名、身份、學院 過程描述：
（1）系統管理員登陸基本數據修改功能子系統，點擊“讀者信息錄入”（2）寫入讀者相應信息，將讀者信息保存至數據庫
（3）發放圖書證
（4）創建完成，讀者信息錄入成功，在數據庫管理子系統增加圖書信息，退出系統
4．“讀者信息注銷”用例 用例編號：0303 用例名：讀者信息銷毀
執行者：直接執行者：系統管理員，間接執行者：讀者
目的：當讀者由于工作地點變化或其他原因，無需再使用圖書館的圖書資料時，應當為其辦理注銷
過程描述：
（1）系統管理員登陸基本數據修改功能子系統，點擊“讀者信息注銷”（2）查詢讀者的借閱記錄
若有未歸還圖書，給出提示：暫時不能注銷
否則注銷讀者，提示：注銷后，不能借閱圖書 若不確定，返回上一層界面
（3）注銷圖書證，刪除基本數據修改功能子系統中的讀者信息（4）注銷完成，在數據庫管理子系統刪除讀者信息，退出系統 5．“書籍信息錄入”用例 用例編號：0305 用例名：書籍信息錄入
執行者：直接執行者：系統管理員，間接執行者：圖書管理員，數據庫管理子系統 目的：圖書館里的圖書根據館藏需求進行更新 過程描述：
（1）系統管理員登陸基本數據修改功能子系統，點擊“書籍信息錄入”
（2）寫入圖書相應信息
（3）圖書管理員給圖書進行分類編號，記錄條形碼信息（4）圖書管理員為圖書張貼條形碼
（5）圖書管理員檢查圖書編號是否入庫
（6）在數據庫管理子系統增加圖書信息，書籍信息錄入成功，退出系統 相應活動圖如下：
系統管理員界面圖書管理員數據庫管理子系統登陸基本數據修改功能子系統點擊書籍信息錄入圖書進行分類編號，記錄條形碼信息圖書張貼條形碼檢查圖書編號是否入庫增加圖書信息[否]退出系統[是]
6．“書籍信息注銷”用例
用例編號：0306 用例名：書籍信息注銷
執行者：直接執行者：系統管理員，間接執行者：圖書管理員，數據庫管理子系統
目的：當圖書館里藏書，由于受到毀損或其他意外的破壞而無法再使用的情況下，需要對館藏圖書進行注銷。過程描述：
（1）系統管理員登陸基本數據修改功能子系統，點擊“書籍信息注銷”
（2）輸入圖書編號，若該書借閱出庫，則暫時不能注銷，提示“該書借閱中，不能注銷”；若該書未被借閱，提示“確定要注銷此書嗎？”若不確定，返回上一層界面（3）成功注銷圖書后，在數據庫管理子系統刪除圖書信息，退出系統
三、系統分析
3.1建立對象類（1）reader 類名：reader 類的類型：該類創建的對象是持久對象，存儲在服務器上的數據庫中，不可以共享 功能：負責讀者信息并對這些信息進行處理，便于對讀者借閱信息進行統一管理。屬性：讀者的編號ID（reader_id）、姓名（reader_Name）、身份（identification）、學院（academy）、所借書籍的編號（borrowed）等 操作：借書和還書、接受相應處理
(2)system admin 類名：system admin 類的類型：該類創建的對象是持久對象，存儲在服務器上的數據庫中，不可以共享 屬性：編號和姓名等
操作：讀者信息管理、書籍信息管理、借閱管理、（3）books admin 類名：books admin
類的類型：該類創建的對象是持久對象，存儲在服務器上的數據庫中，不可以共享 屬性：編號和姓名等
操作：借閱管理、書籍信息錄入、書籍信息修改、書籍信息注銷（3）Books 類名：Books 類的類型：該類創建的對象是持久對象，存儲在服務器上的數據庫中，可以共享 屬性：書名、作者、書籍編碼、類別、價錢、入庫時間 操作：分類編號、記錄條形碼信息、（4）borrow 類名：borrow 類的類型：該類創建的對象是持久對象，存儲在服務器上的數據庫中，不可以共享 屬性：借閱書籍的編號、借閱時間、操作：借書、還書、續借書、交欠款、交罰款（5）data 類的類型：該類創建的對象是持久對象，存儲在服務器上的數據庫中，不可以共享 屬性：書籍信息、讀者信息、借閱信息
操作：讀者信息錄入、讀者信息修改、讀者信息注銷、書籍信息錄入、書籍信息修改、書籍信息注銷、增加借閱信息、刪除借閱信息 3.2 建立對象類圖
reader+編號+姓名+身份+學院+所借書籍的編號+借書()+還書()+接受相應處理()data+書籍信息+讀者信息+Attribute1+讀者信息錄入()+讀者信息修改()+讀者信息注銷()+書籍信息錄入()+書籍信息修改()+書籍信息注銷()+增加借閱信息()+刪除借閱信息()system admin+編號+姓名+讀者信息管理()+書籍信息管理()+借閱管理()Books+書名+作者+書籍編碼+類別+價錢+入庫時間+分類編號()+記錄條形碼信息()borrow+借閱書籍的編號+借閱時間+借書()+還書()+續借書()+交欠款()+交罰款()books admin+編號+姓名+借閱管理()+書籍信息錄入()+書籍信息修改()+書籍信息注銷()圖2-1 圖書館管理系統類圖
四、系統設計
4.1順序圖建模
◆在“借書”用例中涉及的對象間的交互分析如下：
1）登錄系統。圖書管理員登陸“基本數據修改功能子系統”，對讀者的借書要求進行處理。涉及的對象：
·消息的發送者：“系統管理員”對象 ·消息的接收者：“基本數據修改功能子系統借閱窗口”對象 傳遞的消息：
·消息：口令密碼（）
·消息的類型：同步消息
·返回消息：口令密碼正確或出錯信息 2）輸入圖書證編號。涉及的對象：
·消息的發送者：“基本數據修改功能子系統借閱窗口”對象 ·消息的接收者：“基本數據修改功能子系統借閱窗口”對象
傳遞的消息：
·消息：核對圖書證編號（）·消息的類型：自調用消息
·返回消息：圖書證編號正確或出錯信息 3）輸入圖書編號。涉及的對象：
·消息的發送者：“基本數據修改功能子系統借閱窗口”對象 ·消息的接收者：“reader”對象
傳遞的消息：
·消息：[最大借書額為0]:核對借書額（）·消息的類型：同步消息
·返回消息：可以借書 4）確定借閱圖書。涉及的對象： ·消息的發送者：“reader”對象 ·消息的接收者：“reader”對象 傳遞的消息：
·消息：[確定借書]: 借閱證號增加借閱信息記錄（）·消息的類型：自調用消息 ·返回消息：借書成功 5）修改數據庫。涉及的對象： ·消息的發送者：“reader”對象 ·消息的接收者：“數據庫管理系統借閱管理”對象
傳遞的消息：
·消息：[借書成功]: 保存借閱記錄并修改庫存圖書數量、讀者借出數量（）·消息的類型：同步消息
·返回消息：退出系統
根據以上確立的“借書”用例圖中涉及的對象，建立“借書”用例的順序圖如圖3-1：
基本數據修改功能子系統借閱窗口reader數據庫管理系統借閱管理窗口 : 圖書管理員1 : 登錄系統()2 : 核對圖書證編號()3 [最大借書額為0] : :核對借書額()4 [確定借書] : 借閱證號增加借閱信息記錄()5 [借書成功] : 保存借閱記錄并修改庫存圖書數量、讀者借出數量()圖3-1 “借書”用例順序圖
◆在“還書”用例中涉及的對象間的交互分析如下：
1）登錄系統。圖書管理員登陸“基本數據修改功能子系統”，對讀者的還書要求進行處理。涉及的對象：
·消息的發送者：“系統管理員”對象 ·消息的接收者：“基本數據修改功能子系統還書窗口”對象 傳遞的消息：
·消息：口令密碼（）
·消息的類型：同步消息
·返回消息：口令密碼正確或出錯信息
2）輸入圖書證編號。涉及的對象：
·消息的發送者：“基本數據修改功能子系統還書窗口”對象 ·消息的接收者：“基本數據修改功能子系統還書窗口”對象
傳遞的消息：
·消息：核對圖書證編號（）
·消息的類型：自調用消息
·返回消息：圖書證編號正確或出錯信息
3）超期罰款處理。涉及的對象：
·消息的發送者：“基本數據修改功能子系統還書窗口”對象 ·消息的接收者：“基本數據修改功能子系統超期罰款窗口”對象 傳遞的消息：
·消息：[超期]：超期罰款（）·消息的類型：同步消息 ·返回消息：銷毀超期信息
3）丟失罰款處理。涉及的對象：
·消息的發送者：“基本數據修改功能子系統還書窗口”對象 ·消息的接收者：“基本數據修改功能子系統丟失罰款窗口”對象
傳遞的消息：
·消息：[丟失]：丟失罰款（）·消息的類型：同步消息 ·返回消息：銷毀超期信息
4）輸入圖書編號。涉及的對象：
·消息的發送者：“基本數據修改功能子系統還書窗口”對象 ·消息的接收者：“reader”對象 傳遞的消息：
·消息：[借閱]：核對是否借閱此書（）·消息的類型：同步消息 ·返回消息：是否借閱此書 5）確定還書。涉及的對象： ·消息的發送者：“reader”對象 ·消息的接收者：“reader”對象
傳遞的消息：
·消息：[確定還書]: 借閱證號刪除借閱信息記錄（）·消息的類型：自調用消息 ·返回消息：還書成功
6）修改數據庫。涉及的對象：
·消息的發送者：“reader”對象 ·消息的接收者：“數據庫管理系統借閱管理”對象
傳遞的消息：
·消息：[還書成功]: 刪除借閱記錄并修改庫存圖書數量、讀者借出數量（）·消息的類型：同步消息 ·返回消息：退出系統
根據以上確立的“還書”用例圖中涉及的對象，建立“還書”用例的順序圖如圖：
基本數據修改功能子系統還書窗口基本數據修改功能子系統超期罰款窗口基本數據修改功能子系統丟失罰款窗口reader : 圖書管理員1 : 登錄系統()2 : 核對圖書證編號()3 [超期] : ：超期罰款()4 [丟失] : ：丟失罰款()5 [借閱] : ：核對是否借閱此書()6 [確定還書] : : 借閱證號刪除借閱信息記錄()
圖3-2 “還書”用例順序圖一
reader數據庫管理系統借閱管理5 [確定還書] : : 借閱證號刪除借閱信息記錄()6 [還書成功] : :刪除借閱記錄并修改庫存圖書數量、讀者借出數量()
圖3-3 “還書”用例順序圖二
4.2 構件圖建模
構件圖主要用于建立系統的靜態實現視圖模型，通過構件之間的依賴關系描述系統軟件的組織結構，展示了系統中的不同物理構件機器之間的聯系。
圖3-4所示的是圖書館管理系統部分構件圖，圖書管理員登陸“基本數據修改功能子系統”并成功通過驗證后，進入基本數據修改功能子系統主界面
圖書管理員登陸驗證基本數據修改功能子系統主界面續借書借書還書丟失罰款超期罰款圖3-4 基本數據修改功能子系統構件圖
4.3 配置圖建模
實用配置圖定義的軟硬件結構及通訊機制，表示軟硬件系統之間的合作關系；使用構件圖描述系統由哪些構件組成。
圖書館管理系統是一個客戶/服務器和服務器/瀏覽器相結合的系統，可以同配置圖顯示系統的物理結構，如圖3-5所示：
TCP/IP應用服務器ODBC圖3-5 圖書館管理系統配置圖SQL SERVER13 客戶程序數據庫服務器
第五篇：uml建模報告ATM自動柜員機系統
UML建模報告
（2010 / 2011 學年 第 2學期）
題 目：
基于UML的ATM自動
柜員機系統
專
業：
成員：
指
導
教
師：
基于UML的ATM自動柜員機系統建模報告
一、需求分析
（1）功能需求：
1.登陸：客戶通過輸入正確的登陸密碼即可登陸ATM。
2.取款：允許客戶取出自己賬戶中的現金。3.客戶存款：允許客戶把現金存入自己賬戶。4客戶查詢余額：允許客戶查詢自己的賬戶余額。
5客戶轉賬：允許客戶將自己賬戶中的金額轉移至另一賬戶。6客戶更改密碼：允許客戶修改自己的登錄密碼。
（2）系統操作要求：
1．要求用戶每次取款數額為50的整數倍；
2．要求用戶一次取款數額不得大于1000元； 3．要求用戶一天取款數額不得超過5000元； 4．要求用戶每次取款數額不得大于賬戶余額； 5．要求用戶設置的登錄密碼為6位。
（3）系統性能要求：
1．要求反應時間不得大于10秒鐘； 2． 系統設計目標：
ATM自動取款機可以提供24小時不間斷服務，操作簡單，可以很方便為用戶提供取款、轉賬/匯款、查詢賬戶余額等服務。
（4）實現手段：
使用ASP.NET進行界面設計，建立一個數據庫保存客戶的賬戶信息，使用C#語言功能函數并對數據庫中的賬戶信息進行操作。
二、總體設計
本系統總共分為登陸、查詢、存款、取款、轉賬、修改密碼等6個功能模塊。
1.登錄模塊：登陸模塊使用字符匹配算法，要求用戶在輸入賬號之后輸入登陸密碼，只有輸入正確的密碼才能登陸自己的賬戶。否則提示密碼錯誤。
2.查詢模塊：用戶輸入正確的密碼后就可登陸自己的賬戶并接受服務。查詢功能允許用戶查得自己賬戶上的余額信息。
3.存款模塊：允許客戶向自己的賬戶中存入現金。
4.取款模塊：允許客戶從賬戶中取走現金，要求取出的金額不能大于所剩余款，否則提示余額不足。
5.轉賬模塊：允許客戶將自己賬戶中的金額轉移至另一賬戶。要求所轉的金額不能多于所剩余款，否則提示余額不足。
6.修改密碼模塊：允許用戶修改自己的登陸密碼，密碼仍然是6位數的，修改之后，下次登陸就應該用新密碼。
三、詳細設計 用例圖：
類圖：
客戶取錢的協作圖：
其他功能的協作圖與此類似。
賬目類的狀態圖：
ATM系統的部署圖：
四、測試報告 我們在客戶數據庫中建立四個賬戶，如下：
其中四個屬性分別是客戶名、賬號、密碼、賬戶余額。打開網頁，進入初始頁面：
若選擇取回磁卡，顯示如下：
1.登錄功能測試
我們選擇繼續以進行測試，單擊測試進入如下頁面：
若輸入不存在的賬號，則出現提示：
現在我們輸入正確的賬號，這里以08060112為例：
單擊確認，系統將提示客戶輸入密碼，正確的密碼是“123456”，我們輸入“333333”以進行測試，系統提示密碼錯誤：
我們輸入正確的密碼“123456”，單擊確認，則進入交易界面：
2.查詢功能測試
單擊查詢，顯示如下
與數據庫表中的number值比較可得，結果正確。3.取款功能測試
選擇返回，回到主菜單，單擊取款，系統提示客戶輸入取款金額：
我們輸入300單擊確認，顯示如下
單擊確定回到主菜單，單擊查詢，顯示如下：
余額為700，說明取款成功，取款功能順利實現。4.轉賬功能測試
單擊返回，回到主菜單，單擊轉賬，系統提示用戶輸入轉入賬號，我們以轉入08060119為例：
單擊確認，系統提示轉賬金額，我們輸入300：
單擊確認，提示轉賬成功：
單擊確定回到主菜單，這時我們單擊查詢08060112的余額：
結果正確，我們再通過數據庫查詢08060119的余額，打開表格，右擊，執行，顯示如下：
結果也正確，說明轉賬功能也已順利實現。5.存款功能測試
單擊返回回到主菜單，單擊“存款”，我們通過輸入數值來模擬放入現金：
單擊確認，系統提示操作成功：
單擊“確定”回到主菜單，單擊查詢，顯示如下：
結果正確。
6.修改密碼功能測試
單擊返回回到主菜單，單擊“修改密碼”，系統提示如下：
我們將密碼修改為“555555”，輸入“555555”后，提示操作成功：
單擊確定就回到主菜單。這時我們取回磁卡重新登錄以測試密碼是否已經修改。依舊輸入卡號08060112，單擊確認，輸入舊密碼“123456”，提示密碼錯誤：
單擊確定，重新輸入新密碼“555555”，單擊確認，則可順利登錄到主菜單
可見，密碼已經修改成功，另一方面，我們查看數據庫中的數據，右擊，執行，顯示如下：
可以看到賬戶08060112的password屬性已經變為“555555”，因此，修改密碼功能也能順利實現。至此，ATM系統的六大功能都已通過測試并正確無誤。
五、總結
通過這次UML建模的學習，我們學會了很多知識。之前我對UML建模一無所知，但現在我已學會了一些UML建模的基本知識，并學會了建立一些簡單的模型。
雖然只有短短的幾個禮拜，但收獲卻是很大的。首先是分析問題的能力，剛拿到這個題，總覺得無從下手，不知道題目到底要我們做什么，心里只是干著急，不知道該干嘛。經過一周的迷茫，我們開始靜下心來，分析題目，找參考書，嘗試性地進行編程。到第三周，我們終于做出了一個成果并且編譯沒有錯誤。之后就是嘗試運行，運行的過程中出現很多問題。比如轉賬，修改密碼等，但經過我們細心的測試、排查，還是找到了錯誤的原因并進行了糾正。因此，我們的查錯改錯的能力也得到了提高。最重要的是，我們通過這次實習學會了互相合作，俗話說“三個臭皮匠頂個諸葛亮”，也許我們單獨做很難完成這個程序。但是只要我們團結一致就沒有克服不了的困難。這次實習在我們的大學生活乃至整個人生中都有著非常重要的意義，是一筆不小的財富，難忘的經歷。我們會以此為基礎走好人生的每一步。
以上是我們對UML建模的學習的一點總結，同時也是為自己的未來整理好思路，為以后的學習做好準備。UML建模，教會了我很多，而我要做的，就是在以后的學習與生活中更加努力的學習來迎接它帶來的知識與挑戰。
點擊咨詢 