每個人都曾試圖在平淡的學習、工作和生活中寫一篇文章,。寫作是培養(yǎng)人的觀察,、聯(lián)想,、想象,、思維和記憶的重要手段,。相信許多人會覺得范文很難寫,？接下來小編就給大家介紹一下優(yōu)秀的范文該怎么寫,，我們一起來看一看吧,。

銀行儲蓄管理系統(tǒng)uml建模篇一

廣西科技大學

guangxi university of scienceand technology

課 程 作 業(yè)

專

業(yè)： 計算機科學與技術

班級學號：

學生姓名：

班級學號：

學生姓名：

指導教師：

二〇一三年十二月摘要.....................................................................................................................................................iii 1 引言.......................................................................................................................................................3

1.1 選題背景....................................................................................................................................3 1.2 選題意義和目的.........................................................................................................................3 1.3 研究方法....................................................................................................................................3 2 可行性分析...........................................................................................................................................4

2.1 技術可行性分析.........................................................................................................................4

2.1.1與現(xiàn)有系統(tǒng)比較的優(yōu)越性...............................................................................................4 2.1.2 技術可行性評價..............................................................................................................4 2.2 經(jīng)濟可行性分析.........................................................................................................................4

2.2.1 支出.................................................................................................................................4 2.2.2 投資回收周期..................................................................................................................4 網(wǎng)上購物系統(tǒng)的分析............................................................................................................................5

3.1 網(wǎng)上購物系統(tǒng)的需求分析：.....................................................................................................5 3.2 用例分析....................................................................................................................................5

3.2.1確定用例:.........................................................................................................................5 3.2.2 創(chuàng)建用例..........................................................................................................................5 3.2 用例分析....................................................................................................................................6

3.2.3創(chuàng)建用例圖.......................................................................................................................6 3.3 類圖分析....................................................................................................................................7

3.3.1 當前系統(tǒng)的類..................................................................................................................7 3.4 時序圖分析................................................................................................................................8

3.4.1 時序圖描述......................................................................................................................8 3.4.2 顧客的時序圖..................................................................................................................8 3.4.3客戶刪除訂單的時序圖...................................................................................................9 3.4.4 管理員處理訂單的時序圖............................................................................................10 3.4.4 管理員處理訂單的時序圖............................................................................................10 3.5 系統(tǒng)的協(xié)作圖分析...................................................................................................................11

3.5.1 顧客訂購協(xié)作圖............................................................................................................11 3.5.2 顧客刪除訂單的協(xié)作圖................................................................................................11 3.5.3 管理員處理訂單協(xié)作圖................................................................................................12 3.6 系統(tǒng)的狀態(tài)圖分析...................................................................................................................13

3.6.1 管理員狀態(tài)圖................................................................................................................13 3.6.2 用戶狀態(tài)圖....................................................................................................................13 3.7 系統(tǒng)的構件圖分析...................................................................................................................14

3.7.1 網(wǎng)上購物系統(tǒng)構件圖....................................................................................................14 3.8 系統(tǒng)的部署圖分析...................................................................................................................15

3.8.1 網(wǎng)上購物系統(tǒng)部署圖....................................................................................................15 參考書籍.............................................................................................................................................17 結

論.....................................................................................................................................................17

摘要

本論文共分三部分,，分別介紹了統(tǒng)一建模語言（uml）、面向對象程序分析與設計以及通過一個簡易電子商務系統(tǒng)的例子介紹如何應用uml進行項目需求分析,、結構規(guī)劃和生成框架代碼,，以及如何從現(xiàn)有系統(tǒng)逆向轉出代碼，生成uml模型,。

該設計的主要目的是對統(tǒng)一建模語言的學習過程,，并在學習中，通過一個簡單的例子來理解uml語言的建模思想,。本設計是通過一個購物車的例子來理解uml語言的,。通過面向對象程序設計方法與uml思想的結合，對系統(tǒng)進行建模,。即設計uml中的類圖,、對象圖、用例圖,、協(xié)作圖,、順序圖,、狀態(tài)圖、構件圖和部署圖,。通過這些uml框圖生成代碼,。然后，根據(jù)生成的代碼框架及uml模型來完善整個程序,。

這個網(wǎng)上購物系統(tǒng),，主要是實現(xiàn)向購物車中添加和刪除商品及對商品進行結帳的功能。系統(tǒng)是用jsp語言實現(xiàn)的,，它的主要功能都是通過servlet控制的,。該程序的設計思想都是通過uml語言體現(xiàn)的，論文詳細描述了整個設計及學習的全過程,。

關鍵詞：

統(tǒng)一建模語言 面向對象分析

abstract

this paper is spanided into three parts and introduces separately unified modeling language, ooa and a piece of easy e-business system , it shows how to apply uml to carry on requirement analysis and structure plan and to turn into project code, and how to transfer to project code reversely and produce uml model from a existing main purpose of this design is to study course of unified modeling studying, the modeling thought of uml can be understood through a simple order to understand the thought of uml, an example of shopping cart is h the combination of the method of ood and the thought of uml, the model of the system is , it is to design class diagram,、use case diagram、sequence diagram,、state diagram,、component diagram and deployment code is produced by using these uml block , the whole program is perfected according to code frame that are produced and uml online shopping system mainly realizes functions of adding goods to shopping cart and deleting goods from shopping cart and checking system is developed by jsp language, and the main functions of it are controlled through design philosophy of this procedure was all embodied through uml paper has described in detail the design and whole studying word:

unified modeling language

ii

1.1 選題背景 引言

它主要是通過在網(wǎng)頁上進行簡單的對商品進行選購。

1.2 選題意義和目的

該案例的目的主要是：一,，學習uml在面向對象技術中的應用,。二，演示在一個完整的應用中如何使用uml：從分析到設計模型到真正的代碼和可運行的應用,。三,，學習使用uml建模工具visio。本案例遵循的是一種順序過程,。

1.3 研究方法

一個成功的系統(tǒng)開發(fā)項目的成功之處在于它能夠在想象者和實現(xiàn)這些想象的系統(tǒng)開發(fā)人員之間建立起溝通的橋梁,。統(tǒng)一建模語言(unified modeling language,uml)就是一種建立橋梁的工具。它能幫你捕捉住對系統(tǒng)所發(fā)揮的想象力,，并是你能夠用這些想象出來的東西來和項目的風險承擔人(在這里可以理解為用戶)進行交流,。uml借助與一套符號和圖形來幫助我們完成這些工作。每種圖形在開發(fā)過程中都發(fā)揮其各自不同的作用,?？尚行苑治?/p>

2.1 技術可行性分析

2.1.1與現(xiàn)有系統(tǒng)比較的優(yōu)越性

簡單性：在實現(xiàn)平臺的功能的同時，盡量讓平臺操作簡單易懂,，這對于一個網(wǎng)站來說是非常重要的,。

針對性：該平臺設計是網(wǎng)上購物系統(tǒng)及后臺管理的定向開發(fā)設計，所以具有專業(yè)突出和很強的針對性,。

實用性：該平臺能完成商品展示和管理員管理的基本信息,，具有良好的實用性。2.1.2 技術可行性評價

技術可行性：目前,，公司的管理工作和服務工作存在盲目性,、隨意性,、和無效消耗，不能保證營銷部門的工作質量,，影響商品的銷售,，給公司帶來實際的和潛在的經(jīng)濟損失。雖然系統(tǒng)開發(fā)初期投資較大,，但是,，若開發(fā)成功本系統(tǒng)，將有助于公司更好地預測市場,，更好的開發(fā)客戶及時調整經(jīng)營銷售策略,，在激烈的市場競爭中把握主動。因此,，從長遠利益考慮，本項目若能開發(fā)成功,，它所帶來的效益將遠高于系統(tǒng)投入,。

2.2 經(jīng)濟可行性分析

2.2.1 支出

經(jīng)濟可行性：由于實體店鋪對電子購物商城系統(tǒng)開發(fā)項目達成了共識，并撥出專項資金,，用以購置建立網(wǎng)絡中心所需的網(wǎng)絡設備和軟件,，具備了開發(fā)web平臺系統(tǒng)的基本條件。

為了今后的系統(tǒng)維護,，開發(fā)團隊準備聯(lián)合具有豐富經(jīng)驗的軟件開發(fā)人員共同研究,，這為今后系統(tǒng)的順利開發(fā)提供了有力的技術條件。2.2.2 投資回收周期

資本周轉速度快,，回收期短,，風險小，盈利多,。不足的是,，投資回收期沒有全面地考慮投資方案整個計算期內的現(xiàn)金流量，即：忽略在以后發(fā)生投資回收期的所有好4

處,對總收入不做考慮,。只考慮回收之前的效果,，不能反映投資回收之后的情況，即無法準確衡量方案在整個計算期內的經(jīng)濟效果,。網(wǎng)上購物系統(tǒng)的分析

3.1 網(wǎng)上購物系統(tǒng)的需求分析：

1：普通用戶可以登陸系統(tǒng),，成為登陸后用戶。

2：普通用戶只具有搜索產品,、查看產品分類,、查看產品項目、查看產品等幾個基本權限,。

3：除提供一般權限外,，本系統(tǒng)還可為登陸后用戶提供編輯帳號,、購物車、定單,、結算的功能和服務,。

4：登陸后用戶可修改購物數(shù)量。

3.2 用例分析

3.2.1確定用例: 1系統(tǒng)需要哪些輸入/輸出,？這些輸入/輸出從何而來,？到哪里去？ 2執(zhí)行者是否需要對系統(tǒng)中的信息進行讀,、創(chuàng)建,、修改、刪除或存儲,？ 3.2.2 創(chuàng)建用例 訂單處理 2 訂單維護 3 訂單狀態(tài)查詢 4 個人信息維護 5 訂購 6 接收發(fā)貨 7 庫存查詢 8 缺貨拒絕 商品查詢 10商品信息維護 11銷售查詢 12員工信息維護 13報表維護 14訂單增加 15訂單刪除

3.2 用例分析

3.2.3創(chuàng)建用例圖

系統(tǒng)管理的用例圖如圖3-1所示：

系統(tǒng)用戶的用例圖如圖3-2所示：

3.3 類圖分析

3.3.1 當前系統(tǒng)的類

當前系統(tǒng)的類： 產品類（product）的主要操作：設置和獲取每個屬性值的方法,。產品類別類（category）的主要操作：設置和獲取每個屬性值的方法。3 產品項目類（item）的主要操作：設置和獲取每個屬性值的方法,。訂單類（order）的主要操作：設置和獲取每個屬性值的方法,、初始化訂單（initorder）、增加產品項目（addlineitem）等,。購物車類（cart）的主要操作：設置和獲取每個屬性值的方法,、增加產品項目（additem）、刪除產品項目（removeitembyid）等,。購物車項目類(cartitem)的主要操作：設置和獲取每個屬性值的方法,、統(tǒng)計金額（calculatetotal）等。

網(wǎng)上購物系統(tǒng)的類圖如圖3-3所示：

圖3-3 網(wǎng)上購物系統(tǒng)的類圖

3.4 時序圖分析

3.4.1 時序圖描述

順序圖可描述幾個對象間的動態(tài)協(xié)作關系,，它非常直觀的展示了對象之間傳遞消息的時間順序,。反映了系統(tǒng)執(zhí)行過程中某個特定時刻所發(fā)生的事情。在系統(tǒng)分析時,，可對主要對象類繪制順序圖,，以便分析系統(tǒng)的行為，驗證和修改系統(tǒng)的靜態(tài)結構,，滿足用戶的需求,，達到系統(tǒng)的目標。3.4.2 顧客的時序圖

顧客首先使用自己的帳號和密碼進行登陸系統(tǒng),，登陸模塊會將客戶的id保存在系統(tǒng)緩存中,，并提交給商品查詢模塊。商品查詢模塊提示客戶輸入查詢條件,，客戶輸8

入適當?shù)牟樵儣l件后,，查詢模塊將顯示商品列表?？蛻舻玫缴唐妨斜砗?，提交自己想要購買的商品id,，訂購模塊得到商品id。生成訂單并提交給數(shù)據(jù)庫模塊進行保存,，保存成功后,，提示用戶訂購商品成功。顧客訂購的時序圖如圖3-4所示：

圖3-4 顧客訂購的時序圖

3.4.3客戶刪除訂單的時序圖

客戶在提交訂單后可以對訂單進行維護（添加,，刪除,，修改）?？蛻羰紫容斎胱约旱膸ぬ柡兔艽a登陸系統(tǒng),，登陸模塊會將客戶的id保存在系統(tǒng)緩存中，并提交給訂單查詢模塊,。訂單查詢模塊會顯示當前所有的訂單,，顧客得到該列表后，選擇要刪除商品的id,，訂單處理模塊把刪除信息提交給數(shù)據(jù)模塊,，數(shù)據(jù)模塊保存信息。訂單處理提示用戶刪除成功,。客戶刪除訂單的時序圖如圖3-5所示：

圖3-5 客戶刪除訂單的時序圖

3.4.4 管理員處理訂單的時序圖

管理員使用其帳號和密碼登陸后,，登陸模塊會將管理員的id保存在系統(tǒng)緩存中并提交給訂單處理模塊,。訂單處理模塊提交給管理員未處理的列表，管理員提交某商品的id得到該商品的庫存情況,，如果庫存充足則接收訂單，并把接收信息提交給數(shù)據(jù)模塊,，數(shù)據(jù)模塊更新該客戶的訂單信息并返回成功信息給訂單處理模塊,，訂單處理模塊提示改操作成功。管理員處理訂單的時序圖如圖3-6所示：

3.4.4 管理員處理訂單的時序圖

圖3-6 管理員處理訂單的時序圖

3.5 系統(tǒng)的協(xié)作圖分析

3.5.1 顧客訂購協(xié)作圖

顧客訂購協(xié)作圖如圖3-7所示：

圖3-7 顧客訂購協(xié)作圖

3.5.2 顧客刪除訂單的協(xié)作圖

顧客刪除訂單的協(xié)作圖如圖3-8所示：

圖3-8 顧客刪除訂單的協(xié)作圖

3.5.3 管理員處理訂單協(xié)作圖

管理員處理訂單協(xié)作圖如圖3-9所示：

圖3-9 管理員處理訂單協(xié)作圖

3.6 系統(tǒng)的狀態(tài)圖分析

3.6.1 管理員狀態(tài)圖

管理員狀態(tài)圖如圖3-10所示：

圖3-10 管理員狀態(tài)圖

3.6.2 用戶狀態(tài)圖

用戶狀態(tài)圖如圖3-11所示：

圖3-11 用戶狀態(tài)圖

3.7 系統(tǒng)的構件圖分析

3.7.1 網(wǎng)上購物系統(tǒng)構件圖

構件之間存在的唯一關系是構件的依賴性,。構件依賴性指一個構件依賴于另一個構件,。構件依賴性畫成構件之間的虛線箭頭。如下圖箭頭指的構件表示被依賴,，也就是說,cart,、eshop、checkout都依賴于shoppingservlet,。下圖描述的是在網(wǎng)上購物系統(tǒng)中幾個構件之間的依賴關系,。網(wǎng)上購物系統(tǒng)構件圖如圖3-12所示：

圖3-12 構件圖

3.8 系統(tǒng)的部署圖分析

3.8.1 網(wǎng)上購物系統(tǒng)部署圖

部署圖可以顯示節(jié)點以及它們之間的必要連接，也可以顯示這些連接的類型,，還可以顯示組件和組件之間的依賴關系,，但是每個組件必須存在于某些節(jié)點上,。部署圖用于對系統(tǒng)的實現(xiàn)視圖建模。繪制這些視圖主要是為了描述系統(tǒng)中各個物理組成部分的分布,、提交和安裝過程,。在實際應用中，并不是每一個軟件開發(fā)項目都必須繪制部署圖的,。如果項目開發(fā)組所開發(fā)的軟件系統(tǒng)只需要運行于一臺計算機并且只需使用此計算機上已經(jīng)由操作系統(tǒng)管理的標準設備,，這種情況下就沒有必要繪制部署圖了。另一方面,，如果項目開發(fā)組所開發(fā)的軟件系統(tǒng)需要使用操作系統(tǒng)管理以外的設備（例如數(shù)碼相機,、路由器等）、或者系統(tǒng)中的設備分布在多個處理器上,，這時就有必要繪制 部署圖,，用其來幫助開發(fā)人員理解系統(tǒng)中軟件和硬件的映射關系。下面是本系統(tǒng)的部署圖,，如圖3-13所示：

desktop...16

desktop...registrations lanerverwebbrowserbuyingsystemsalesystemmaintainsystemlandesktop pc(saler)

圖3-13 網(wǎng)絡購物系統(tǒng)的配置圖internet 參考書籍

[1] 面向對象程序設計高級教程,，陳奇，高等教育出版社,，2001 [2] 標準建模語言uml極其支持環(huán)境,，周伯生，張莉等,，北京：計算機世界,，1998 [3] uml和模式應用——面向對象分析和設計導論，craig larman等,，姚淑珍,，李虎譯，機械工業(yè)出版社,，2002 [4] uml asl reference guide asl language level 2.5,；ian wilkie, adrian king, mike clarke, chas weaver and chris rastrick；

[5] stephen , marc ,executable uml :a foundation for model-driven architecture, ,2003,科學出版社

結

論

本次課程設計將uml建模應用到構建系統(tǒng)設計上,，并通過八種框圖,，從各種角度觀察系統(tǒng)來進行需求分析、系統(tǒng)設計,。通過一個完整的簡單例子來說明uml在整個系統(tǒng)設計所發(fā)揮的作用,。

通過這次的課程設計，使我對uml全新的理解,使我對uml產生了更加濃厚的興趣,在程序的設計過程中,，我發(fā)現(xiàn)自己的軟件知識尤其是對軟件的整體設計不是完全理解,，對于一些細節(jié)不夠了解，對知識的了解不全面，有待學習和提高,。

通過這次的設計,，知道自己的不足，我相信自己會在一定時間內通過不斷的學習和實踐提高自己的能力,，設計給我?guī)砗艽蟮膸椭瑫r開闊了我的眼界，使我明白只有自己親自實踐，才能了解自己所做的東西,，如果沒有實踐，恐怕就不會有電流的產生,，地球為什么是圓的，以及現(xiàn)在的一切,。勤于實踐不僅能鍛煉自己,，還能夠提高17

自己的能力,，增強自己的自信心,。在面對困難時要勇敢的面對才有能力、有把握去克服它,，征服它。雖然我現(xiàn)在還有所欠缺，但我相信在以后的工作和生活中,，我會不斷提高自己,，完善自己,。

銀行儲蓄管理系統(tǒng)uml建模篇二

銀行管理系統(tǒng)的uml

建模

課程設計報告

專業(yè)：

學號：

姓名：

任課教師：

一,、系統(tǒng)概述

銀行是與人們生活密切相關的一個機構，銀行可以提供存款,、取款,、轉賬等業(yè)務,。在銀行設立賬戶的人或機構被稱為銀行的客戶（customer）。一個客戶可以在銀行開設多個賬戶（account）,，客戶可以存錢到賬戶中,，也可以從自己的賬戶中取錢,，還可以將存款從一個賬戶轉到另一個賬戶,。另外，客戶可以隨時查詢自己的賬戶情況,，以及查詢以前所進行的存款,、取款等交易記錄,?？蛻暨€有權利要求關閉自己的賬戶。

實際生活中的銀行功能其實還要復雜得多,，但為了簡化系統(tǒng),，本次設計只考慮銀行的基本功能。簡化版的銀行信息系統(tǒng)至少應具有如下功能：

1.一個銀行可以有多個賬戶,； 2.一個銀行可以有多個客戶,； 3.一個客戶可以持有多個賬戶； 4.一個賬戶可以有多個持有者,； 5.銀行可以為客戶開設賬戶,； 6.銀行可以為客戶注銷賬戶； 7.客戶可以從自己賬戶中取錢,； 8.客戶可以向自己賬戶中存錢,；

9.客戶可以在同一銀行的不同賬戶之間轉賬； 10.客戶可以在不同銀行的不同賬戶之間轉賬,； 請完成登錄,、存款、取款,、轉賬和查詢幾個模塊的設計,。

二、需求分析

銀行系統(tǒng)是與生活緊密相關的一個機構,，銀行提供了存款,、取款、轉賬等業(yè)務,。在銀行設立賬戶的人或機構通常被稱為銀行的儲戶,。一個儲戶可以在銀行開多個賬戶，儲戶可以存錢到賬戶中,，也可以從自己的賬戶中取現(xiàn),，還可以將存款從一個賬戶轉到另一個賬戶。儲戶還可以隨時查詢自己賬戶的情況,，并查詢以前所進行的存款、取款等交易記錄。后臺管理員可以對客戶的賬戶進行注銷,、刪除,、查詢等管理，還有就是銀行利息,、匯率,、手續(xù)費之類參數(shù)的設置，以及財務管理以及財務分析,。

軟件分別有開戶,，查詢存取款，轉賬等功能,。各個模塊各有不同的功能,，但都能完成查詢和存取功能。各模塊的數(shù)據(jù)都存放在數(shù)據(jù)庫中,。數(shù)據(jù)的調用和連接都有程序來完成,。

此軟件所要完成的主要功能有三方面：如果是存款，用戶填寫存款單,，然后交給收銀員鍵入系統(tǒng),，同時系統(tǒng)還要記錄存款人姓名,，住址，身份證號碼,，存款類型,，存款日期，利率及密碼（可選）等信息,，完成后由系統(tǒng)反饋成功存款信息給用戶,。如果是取款，用戶填寫取款的相關信息（取款金額,、取款幣種）進行提交,，系統(tǒng)要求用戶輸入密碼以確認身份，核對密碼正確無誤后系統(tǒng)計算利息并印出利息單給用戶,。如果是轉賬,，用戶填寫轉賬的相關信息進行提交，系統(tǒng)要求用戶輸入密碼以確認身份,，核對密碼正確無誤后系統(tǒng)計算利息并反饋信息給用戶,。系統(tǒng)及時更新數(shù)據(jù)庫。

外部功能：實現(xiàn)化窗口,，開戶/銷戶,、存款/取款、查詢/轉賬,。

內部功能：同步,，過濾，定位,，識別,，更新，連接,。

三,、系統(tǒng)的uml基本模型

（1）、用例圖

通過分析對銀行管理系統(tǒng)的需求分析,，確定參與者有銀行客戶,、收銀員。收銀員具有維護系統(tǒng)信息,、維護客戶信息,、查詢客戶情況和處理處理客戶需求的作用。用例包括：

1）開戶,、2）存款,、3）取款、4）轉賬,、5）查詢,、6）銷戶等

（2）,、用例描述：

用例名稱：銀行信息系統(tǒng)

描述：銀行客戶對需要辦理業(yè)務的需求以及收銀員對事件的處理。

（3）,、銀行信息系統(tǒng)的事件流

1.用例存款的事件流

1.1 前置條件

在存款之前,，客戶已經(jīng)辦理銀行賬號并且?guī)憩F(xiàn)金若干，并到達銀行網(wǎng)點,。1.2 后置條件

如果這個用例成功，這個存款事件是成功的,，否則,，系統(tǒng)沒有變化。1.3 擴充點

無 1.4 事件流

1.4.1 基流（1）客戶將銀行卡交給收銀員,。

（2）收銀員要求客戶輸入卡密碼,。

（3）客戶輸入卡密碼，并確認密碼,。

（4）收銀員提示,，請客戶選擇服務類型。

（5）客戶選擇存款服務,。

（6）收銀員提示：存款數(shù)目,。

（7）客戶說出數(shù)目，并把錢交給收銀員,。

（8）收銀員完成服務,。

（9）收銀員退還卡。1.4.2 替代流

如果輸入的密碼無效,，用戶可以重新輸入密碼或者終止用例,。

2.用例轉賬的事件流

2.1 前置條件

在轉賬之前，客戶已經(jīng)辦理銀行賬號,，被轉賬人的賬號已經(jīng)存在并且已經(jīng)知道了對方的賬號,。

2.2 后置條件

如果這個用例成功，這個轉賬事件是成功的,，否則,，系統(tǒng)沒有變化。2.3 擴充點

無 2.4 事件流

2.4.1 基流

（1）客戶填寫轉賬單,。

（2）客戶把轉賬單和銀行卡交給收銀員,。

（3）收銀員要求客戶輸入卡密碼。

（4）客戶輸入卡密碼,，并確認密碼,。

（5）收銀員轉賬成功。

（6）收銀員退還卡,。2.4.2 替代流

如果輸入的密碼無效,，用戶可以重新輸入密碼或者終止用例,。

3.用例查詢的事件流

3.1 前置條件

在查詢之前，客戶已經(jīng)辦理銀行賬號并且攜帶銀行卡,，并到達銀行網(wǎng)點,。3.2 后置條件

如果這個用例成功，這個查詢事件是成功的,，否則,，系統(tǒng)沒有變化。3.3 擴充點

無 3.4 事件流

3.4.1 基流

（1）客戶將銀行卡交給收銀員,。

（2）收銀員要求客戶輸入卡密碼,。

（3）客戶輸入卡密碼，并確認密碼,。

（4）收銀員提示,，請客戶選擇服務類型。（5）客戶選擇查詢服務,。

（6）客戶說出查詢內容,，收銀員將內容反饋給客戶。

（7）收銀員完成服務,。

（8）收銀員退還卡,。3.4.2 替代流

如果輸入的密碼無效，用戶可以重新輸入密碼或者終止用例,。

（4）,、活動圖

活動圖是基于對象的狀態(tài)變遷所繪制的視圖。

收銀員首先憑著自己的系統(tǒng)用戶名和密碼登錄系統(tǒng),，收銀員可以通過銀行客戶提供的有效證件號開戶,，提供客戶賬號開戶、存款,、取款,、轉賬、查詢,、銷戶等功能,，最后退出系統(tǒng)。

1．存款活動圖

2．轉賬活動圖

3．查詢活動圖

（5）,、時序圖

時序圖（sequence diagram）主要用于按照交互發(fā)生的一系列順序,，顯示對象之間的這些交互。收銀員通過用戶賬號和密碼登錄系統(tǒng),，在系統(tǒng)的操作窗口對需要存款,、取款、轉賬、查詢,、銷戶的用戶進行操作,，最后退出操作窗口。

我們所開發(fā)的銀行管理系統(tǒng)時序圖如圖所示：

（6）,、類圖

類圖是對象結構建模的一部分,，類圖描述系統(tǒng)中類的靜態(tài)結構,。類圖是代碼生成（將模型轉化為代碼）的來源,，也是逆向工程（將代碼轉化為模型）的目標設生成物,。

類圖設計如下圖：

系統(tǒng)中主要的類（1）用戶類： 它的屬性有用戶名（name）,、密碼（password）,、銀行卡號（cardnumber）,、用戶身份證號碼（id）,。

操作包括修改密碼（changpassword）,、存款（deposit）,、取款（cash）、轉賬（transfer）,、查詢（chaxun）,、、用戶開戶（registered）,。

（2）系統(tǒng)類：

它的屬性有電腦號（computernumber）,、機器地址（mac）。本身的操作沒有,，但有被管理員使用的操作,。（3）收銀員類：

它的屬性有用戶名（name）、密碼（password）,。

操作包括用戶開戶（registeredusers）,、注銷用戶（deleteusers）、查詢用戶信息（chaxun）,、系統(tǒng)維護（weihu）。

（7）狀態(tài)圖

狀態(tài)圖用來表示建模對象是如何改變其狀態(tài)的,，狀態(tài)定義為對象行為在某一時刻的快照或轉折點。

四,、結論

系統(tǒng)主要的實現(xiàn)目標是實現(xiàn)客戶開戶,、存款、取款,、轉賬,、查詢、銷戶和后臺服務器端系統(tǒng)的設計,，提供完善的功能設計,。

五、總結及心得體會

uml工具很好的幫助我們實現(xiàn)了對銀行信息系統(tǒng)的設計,，通過uml建模,，把事物從抽象到實例化的過程，對每個對象進行細化分析,，從而得到簡單而方便,，容易理解的模型結構。通過此次試驗收獲很大,，使我們認識到了通過uml模型可以高效完成軟件設計,，收獲頗豐。

一,、開發(fā)背景與目標

1.1開發(fā)背景

本系統(tǒng)選題為銀行存儲系統(tǒng),，是模擬銀行存儲開發(fā)的。隨著計算機的飛速發(fā)展及應用領域的擴大,，特別是計算機網(wǎng)絡和電子商務的發(fā)展,，極大的改變了商業(yè)銀行傳統(tǒng)的經(jīng)營模式,。能夠為客戶提供方便、快捷,、安全的服務,，也能夠有效的降低銀行的營運成本，這是銀行存儲系統(tǒng)追求的目標,。目前,，對于現(xiàn)代化銀行運營的要求是客戶可以實現(xiàn)方便安全的業(yè)務交易，銀行職員可以進行高效合理的工作管理,，實現(xiàn)銀行業(yè)務電子化

在銀行管理系統(tǒng)中,，系統(tǒng)包括4個節(jié)點，分別是：銀行管理員業(yè)務處理節(jié)點,、atm自動取款機節(jié)點,、系統(tǒng)維護節(jié)點、數(shù)據(jù)庫節(jié)點,。

銀行管理員業(yè)務處理節(jié)點,，銀行管理員通過該節(jié)點辦理相應業(yè)務； atm自動取款節(jié)點,，用戶通過該節(jié)點進行自動取款服務,；

系統(tǒng)維護節(jié)點，系統(tǒng)管理員通過該節(jié)點進行后臺維護,，執(zhí)行銀行管理員允許的所有操作,；數(shù)據(jù)庫節(jié)點，負責數(shù)據(jù)的存儲與處理,。

誰使用系統(tǒng)的主要功能?誰改變系統(tǒng)的數(shù)據(jù)? 誰從系統(tǒng)獲取信息? 誰需要系統(tǒng)的支持才能完成日常的工作任務?誰負責維護,管理并保持系統(tǒng)的正常運行?系統(tǒng)需要應付,處理那些硬件設備?系統(tǒng)需要和那些外部系統(tǒng)交互?誰(或是什么)對系統(tǒng)運行產生的結果感興趣?

用例圖主要用來描述“用戶,、需求、系統(tǒng)功能單元”之間的關系,。它展示了一個外部用戶能夠觀察到的系統(tǒng)功能模型圖,。

【用途】：幫助開發(fā)團隊以一種可視化的方式理解系統(tǒng)的功能需求

銀行儲蓄管理系統(tǒng)uml建模篇三

銀行管理系統(tǒng)的uml

建模

課程設計報告

專業(yè)：

學號：

姓名：

任課教師：

一,、系統(tǒng)概述

銀行是與人們生活密切相關的一個機構,，銀行可以提供存款、取款,、轉賬等業(yè)務,。在銀行設立賬戶的人或機構被稱為銀行的客戶（customer）。一個客戶可以在銀行開設多個賬戶（account）,，客戶可以存錢到賬戶中,，也可以從自己的賬戶中取錢，還可以將存款從一個賬戶轉到另一個賬戶,。另外,，客戶可以隨時查詢自己的賬戶情況,，以及查詢以前所進行的存款、取款等交易記錄,?？蛻暨€有權利要求關閉自己的賬戶。

實際生活中的銀行功能其實還要復雜得多,，但為了簡化系統(tǒng),，本次設計只考慮銀行的基本功能。簡化版的銀行信息系統(tǒng)至少應具有如下功能：

1.一個銀行可以有多個賬戶,； 2.一個銀行可以有多個客戶,； 3.一個客戶可以持有多個賬戶； 4.一個賬戶可以有多個持有者,； 5.銀行可以為客戶開設賬戶,； 6.銀行可以為客戶注銷賬戶； 7.客戶可以從自己賬戶中取錢,； 8.客戶可以向自己賬戶中存錢,；

9.客戶可以在同一銀行的不同賬戶之間轉賬； 10.客戶可以在不同銀行的不同賬戶之間轉賬,； 請完成登錄,、存款、取款,、轉賬和查詢幾個模塊的設計,。

二、需求分析

銀行系統(tǒng)是與生活緊密相關的一個機構,，銀行提供了存款,、取款、轉賬等業(yè)務,。在銀行設立賬戶的人或機構通常被稱為銀行的儲戶,。一個儲戶可以在銀行開多個賬戶，儲戶可以存錢到賬戶中,，也可以從自己的賬戶中取現(xiàn),，還可以將存款從一個賬戶轉到另一個賬戶。儲戶還可以隨時查詢自己賬戶的情況,，并查詢以前所進行的存款,、取款等交易記錄。后臺管理員可以對客戶的賬戶進行注銷,、刪除,、查詢等管理，還有就是銀行利息,、匯率,、手續(xù)費之類參數(shù)的設置,，以及財務管理以及財務分析。

軟件分別有開戶,，查詢存取款,，轉賬等功能。各個模塊各有不同的功能,，但都能完成查詢和存取功能,。各模塊的數(shù)據(jù)都存放在數(shù)據(jù)庫中。數(shù)據(jù)的調用和連接都有程序來完成,。

此軟件所要完成的主要功能有三方面：如果是存款,，用戶填寫存款單，然后交給收銀員鍵入系統(tǒng),，同時系統(tǒng)還要記錄存款人姓名,，住址，身份證號碼,，存款類型,，存款日期，利率及密碼（可選）等信息,，完成后由系統(tǒng)反饋成功存款信息給用戶,。如果是取款，用戶填寫取款的相關信息（取款金額,、取款幣種）進行提交,，系統(tǒng)要求用戶輸入密碼以確認身份，核對密碼正確無誤后系統(tǒng)計算利息并印出利息單給用戶,。如果是轉賬,，用戶填寫轉賬的相關信息進行提交，系統(tǒng)要求用戶輸入密碼以確認身份,，核對密碼正確無誤后系統(tǒng)計算利息并反饋信息給用戶,。系統(tǒng)及時更新數(shù)據(jù)庫。

外部功能：實現(xiàn)化窗口,，開戶/銷戶,、存款/取款、查詢/轉賬,。

內部功能：同步,，過濾,，定位,，識別，更新,，連接,。

三,、系統(tǒng)的uml基本模型

（1）、用例圖

通過分析對銀行管理系統(tǒng)的需求分析,，確定參與者有銀行客戶,、收銀員。收銀員具有維護系統(tǒng)信息,、維護客戶信息,、查詢客戶情況和處理處理客戶需求的作用。用例包括：

1）開戶,、2）存款,、3）取款、4）轉賬,、5）查詢,、6）銷戶等

（2）、用例描述：

用例名稱：銀行信息系統(tǒng)

描述：銀行客戶對需要辦理業(yè)務的需求以及收銀員對事件的處理,。

（3）,、銀行信息系統(tǒng)的事件流

1.用例存款的事件流

1.1 前置條件

在存款之前，客戶已經(jīng)辦理銀行賬號并且?guī)憩F(xiàn)金若干,，并到達銀行網(wǎng)點,。1.2 后置條件

如果這個用例成功，這個存款事件是成功的,，否則,，系統(tǒng)沒有變化。1.3 擴充點

無 1.4 事件流

1.4.1 基流（1）客戶將銀行卡交給收銀員,。

（2）收銀員要求客戶輸入卡密碼,。

（3）客戶輸入卡密碼，并確認密碼,。

（4）收銀員提示,，請客戶選擇服務類型。

（5）客戶選擇存款服務,。

（6）收銀員提示：存款數(shù)目,。

（7）客戶說出數(shù)目，并把錢交給收銀員,。

（8）收銀員完成服務,。

（9）收銀員退還卡。1.4.2 替代流

如果輸入的密碼無效,，用戶可以重新輸入密碼或者終止用例,。

2.用例轉賬的事件流

2.1 前置條件

在轉賬之前，客戶已經(jīng)辦理銀行賬號,，被轉賬人的賬號已經(jīng)存在并且已經(jīng)知道了對方的賬號,。

2.2 后置條件

如果這個用例成功,，這個轉賬事件是成功的，否則,，系統(tǒng)沒有變化,。2.3 擴充點

無 2.4 事件流

2.4.1 基流

（1）客戶填寫轉賬單。

（2）客戶把轉賬單和銀行卡交給收銀員,。

（3）收銀員要求客戶輸入卡密碼,。

（4）客戶輸入卡密碼，并確認密碼,。

（5）收銀員轉賬成功,。

（6）收銀員退還卡。2.4.2 替代流

如果輸入的密碼無效,，用戶可以重新輸入密碼或者終止用例,。

3.用例查詢的事件流

3.1 前置條件

在查詢之前，客戶已經(jīng)辦理銀行賬號并且攜帶銀行卡,，并到達銀行網(wǎng)點,。3.2 后置條件

如果這個用例成功，這個查詢事件是成功的,，否則,，系統(tǒng)沒有變化。3.3 擴充點

無 3.4 事件流

3.4.1 基流

（1）客戶將銀行卡交給收銀員,。

（2）收銀員要求客戶輸入卡密碼,。

（3）客戶輸入卡密碼，并確認密碼,。

（4）收銀員提示,，請客戶選擇服務類型。（5）客戶選擇查詢服務,。

（6）客戶說出查詢內容,，收銀員將內容反饋給客戶。

（7）收銀員完成服務,。

（8）收銀員退還卡,。3.4.2 替代流

如果輸入的密碼無效，用戶可以重新輸入密碼或者終止用例,。

（4）,、活動圖

活動圖是基于對象的狀態(tài)變遷所繪制的視圖。

收銀員首先憑著自己的系統(tǒng)用戶名和密碼登錄系統(tǒng),，收銀員可以通過銀行客戶提供的有效證件號開戶,，提供客戶賬號開戶、存款、取款,、轉賬,、查詢,、銷戶等功能,，最后退出系統(tǒng)。

1．存款活動圖

2．轉賬活動圖

3．查詢活動圖

（5）,、時序圖

時序圖（sequence diagram）主要用于按照交互發(fā)生的一系列順序,，顯示對象之間的這些交互。收銀員通過用戶賬號和密碼登錄系統(tǒng),，在系統(tǒng)的操作窗口對需要存款,、取款、轉賬,、查詢,、銷戶的用戶進行操作，最后退出操作窗口,。

我們所開發(fā)的銀行管理系統(tǒng)時序圖如圖所示：

（6）,、類圖

類圖是對象結構建模的一部分，類圖描述系統(tǒng)中類的靜態(tài)結構,。類圖是代碼生成（將模型轉化為代碼）的來源,，也是逆向工程（將代碼轉化為模型）的目標設生成物。

類圖設計如下圖：

系統(tǒng)中主要的類（1）用戶類： 它的屬性有用戶名（name）,、密碼（password）,、銀行卡號（cardnumber）、用戶身份證號碼（id）,。

操作包括修改密碼（changpassword）,、存款（deposit）、取款（cash）,、轉賬（transfer）,、查詢（chaxun）、,、用戶開戶（registered）,。

（2）系統(tǒng)類：

它的屬性有電腦號（computernumber）、機器地址（mac）,。本身的操作沒有,，但有被管理員使用的操作。（3）收銀員類：

它的屬性有用戶名（name）,、密碼（password）,。操作包括用戶開戶（registeredusers）、注銷用戶（deleteusers）、查詢用戶信息（chaxun）,、系統(tǒng)維護（weihu）,。

（7）狀態(tài)圖

狀態(tài)圖用來表示建模對象是如何改變其狀態(tài)的，狀態(tài)定義為對象行為在某一時刻的快照或轉折點,。

四,、結論

系統(tǒng)主要的實現(xiàn)目標是實現(xiàn)客戶開戶、存款,、取款,、轉賬、查詢,、銷戶和后臺服務器端系統(tǒng)的設計,，提供完善的功能設計。

五,、總結及心得體會

uml工具很好的幫助我們實現(xiàn)了對銀行信息系統(tǒng)的設計,，通過uml建模，把事物從抽象到實例化的過程,，對每個對象進行細化分析,，從而得到簡單而方便，容易理解的模型結構,。通過此次試驗收獲很大,，使我們認識到了通過uml模型可以高效完成軟件設計，收獲頗豐,。

銀行儲蓄管理系統(tǒng)uml建模篇四

基于uml的圖書館管理系統(tǒng)建模設計

一,、圖書館管理系統(tǒng)可行性分析

隨著政府機關與廣大企事業(yè)單位內部網(wǎng)絡的廣泛建立，在通用信息平臺上構筑高效實用的協(xié)同工作和自動化辦公應用系統(tǒng),，滿足信息高度共享和即時發(fā)布的需求,，有效實現(xiàn)內部知識管理，已成為眾多用戶的共同需求,。

該圖書管理系統(tǒng),，為圖書館管理提供了一個較好的解決方案。在開發(fā)過程中,，按照軟件工程的步驟,，從設計到開發(fā)采用了面向對象的思想和技術，采用了sql server 2000數(shù)據(jù)庫,，使得本系統(tǒng)可以方便的和其他子系統(tǒng)進行數(shù)據(jù)交換,。同時，注意從軟件的圖形應用界面上優(yōu)化軟件質量,，使得本系統(tǒng)具有很強的可操作性,。

二,、需求分析

需求分析的目的是深入描述軟件功能和性能，確定軟件設計的約束和軟件同其他系統(tǒng)元素的接口細節(jié),，定義軟件的其他有效性需求,。2．

1、客戶需求分析

①能夠對圖書進行注冊登記,，也就是將圖書的基本信息（如：書的編號,、書名、作者,、價格等）預先存入數(shù)據(jù)庫中,，供以后檢索,。

②能夠對借閱人進行注冊登記,，包括記錄借閱人的姓名、編號,、班級,、年齡、性別,、地址,、電話等信息。

③提供方便的查詢方法,。如：以書名,、作者、出版社,、出版時間（確切的時間,、時間段、某一時間之前,、某一時間之后）等信息進行圖書檢索,，并能反映出圖書的借閱情況；以借閱人編號對借閱人信息進行檢索,；以出版社名稱查詢出版社聯(lián)系方式信息,。

④提供舊書注銷功能，對于淘汰,、損壞,、丟失的書目可及時對數(shù)據(jù)庫進行修改。

⑤能夠對使用該管理系統(tǒng)的用戶進行管理,，按照不同的工作職能提供不同的功能授權,。⑥對所借圖書情況進行登記，包括借閱時間,、借閱人等 ⑦對超出借閱時間,、損壞或丟失圖書的讀者進行相應處理 ⑧讀者可以查詢自己的信息 ⑨借書,、還書、續(xù)借書

2．2 定義系統(tǒng)的邊界和范圍 該系統(tǒng)的邊界為學校的圖書館

該系統(tǒng)的范圍可包括“讀者管理子系統(tǒng)”,、“書籍管理子系統(tǒng)”,、“借閱管理子系統(tǒng)”、“系統(tǒng)管理子系統(tǒng)” 2.3確定執(zhí)行者

根據(jù)前面介紹的客戶需求分析可以看出,?！皥D書館管理系統(tǒng)”有三個執(zhí)行者，即“讀者”,、“圖書管理員”,、“系統(tǒng)管理員”

1）2）讀者：查詢個人信息、查詢圖書信息,、借閱圖書,、返還圖書、續(xù)借圖書,、接受相應處理

圖書管理員：借書處理,、還書處理、新舊書登記處理,、辦理相應處理手續(xù)

3）系統(tǒng)管理員：系統(tǒng)維護工作——學生信息管理,、圖書信息管理、系統(tǒng)狀態(tài)維護 2.4確定用例

（1）“圖書館管理系統(tǒng)”中的用例

在第一層,，根據(jù)客戶對“圖書館管理系統(tǒng)”的整體業(yè)務功能要求,，可選的用例有：

·基本業(yè)務功能管理

·基本數(shù)據(jù)修改 ·信息查詢

·數(shù)據(jù)庫管理

（2）“基本業(yè)務功能子系統(tǒng)”中的用例

在第二層，客戶對“基本業(yè)務功能子系統(tǒng)”的整體業(yè)務功能要求,，可選的用例有： ·借閱管理 ·借書

·續(xù)借書 ·還書

（3）“基本數(shù)據(jù)修改功能子系統(tǒng)”中的用例

在第二層,，客戶對“基本數(shù)據(jù)修改功能子系統(tǒng)”的整體業(yè)務功能要求，可選的用例有： ·讀者信息管理 ·讀者信息錄入 ·讀者信息修改 ·讀者信息注銷 ·書籍信息管理 ·書籍信息錄入 ·書籍信息修改

·書籍信息注銷（4）“信息查詢子系統(tǒng)”中的用例

在第二層,，客戶對“信息查詢子系統(tǒng)”的整體業(yè)務功能要求,，可選的用例有： ·圖書信息查詢 ·讀者信息查詢

（5）“數(shù)據(jù)庫管理子系統(tǒng)”中的用例

在第二層，客戶對“數(shù)據(jù)庫管理子系統(tǒng)”的整體業(yè)務功能要求,，可選的用例有： ·借閱管理 2.5分層繪制用例圖

根據(jù)系統(tǒng)需求分析中客戶對系統(tǒng)的功能要求,，我們一確定了系統(tǒng)和子系統(tǒng)的邊界、執(zhí)行者和用例,，現(xiàn)在就可以繪制用例圖了,。

1． 最高層用例圖

根據(jù)客戶對“圖書館管理系統(tǒng)”的整體業(yè)務功能要求，可以繪制如圖1-1所示的最高層用例圖 2． 第2層用例圖

在第2層用例圖中包括四個用例圖：基本業(yè)務功能子系統(tǒng),、基本數(shù)據(jù)修改功能子系統(tǒng),、信息查詢子系統(tǒng)、數(shù)據(jù)庫管理子系統(tǒng),。如下圖所示：

system<

>借書<

>續(xù)借書圖書管理員借閱管理<

><

>還書超期罰款<

>系統(tǒng)管理員丟失罰款圖1-2 基本業(yè)務功能子系統(tǒng)system圖書信息管查詢圖書管理員讀者信息查詢讀者圖1-4 信息查詢子系統(tǒng) 讀者

><

>讀者信息錄入讀者信息管理<

>讀者信息修改系統(tǒng)管理員書籍信息管理<

>書籍信息錄入<

><

>書籍信息修改圖書管理員書籍信息銷毀圖1-3 基本數(shù)據(jù)修改功能子系統(tǒng)

2.6 描述用例

1．“借書”用例

用例編號：0102（共有兩層用例圖,，每層用2位數(shù)字表示,，采用4位編號）用例名：借書

執(zhí)行者：直接執(zhí)行者：圖書管理員，涉及到的執(zhí)行者有：讀者,、系統(tǒng)管理員 目的：借閱圖書

過程描述：

（1）圖書管理員登陸基本數(shù)據(jù)修改功能子系統(tǒng),，點擊“借閱管理”中的“借閱”（2）輸入圖書證編號

若輸入不正確，則提示“您輸入的借閱證號碼有誤,，請重新輸入,！”；輸入正確后,，顯示讀者已借閱圖書信息,，提示超期未歸還的圖書；（3）輸入圖書編號

若讀者已借滿,，提示“您已借滿,，請先歸還部分圖書再來借，謝謝,！”,；若讀者可以正常 4 借閱,，提示“您確定要借閱這本書嗎,？”

（4）確定借閱圖書，則借閱證號增加一條借閱信息記錄,；讀者選擇 “放棄”,，回到步驟（3）重新選擇圖書；

（5）讀者成功借閱圖書,，系統(tǒng)管理員保存借閱記錄并修改庫存圖書數(shù)量,、讀者借出數(shù)量。

（6）借閱完成,，點擊“退出”,，退出系統(tǒng)。2．“還書”用例 用例編號：0103 用例名：還書

執(zhí)行者：直接執(zhí)行者：圖書管理員,，涉及到的執(zhí)行者有：讀者,、系統(tǒng)管理員 目的：歸還圖書 過程描述：

（1）圖書管理員登陸基本數(shù)據(jù)修改功能子系統(tǒng)，點擊“借閱管理”中的“還書”,；（2）輸入圖書證編號,；

若輸入不正確，則提示“您輸入的借閱證號碼有誤,，請重新輸入,！”；輸入正確后,，顯示讀者已借閱圖書信息,，提示超期未歸還的圖書,，有超期未還的圖書，調用“超期罰款”,；若讀者說自己丟失圖書,，調用“丟失罰款”

（3）輸入要還的圖書編號； 若輸入錯誤,，提示“您未借閱該圖書,！” 若輸入正確，提示“您確定要歸還這本書嗎,？”（4）讀者選擇“確定”,，讀者借閱的圖書信息記錄消失；讀者選擇 “放棄”,，返回到步驟（3）

（5）完成還書,，點擊“退出”，退出系統(tǒng),；

（6）讀者成功歸還圖書,，系統(tǒng)管理員刪除借閱記錄，并修改數(shù)據(jù)庫管理子系統(tǒng)的圖書數(shù)量和讀者借出數(shù)量,。

3．“讀者信息錄入”用例

用例編號：0302 用例名：讀者信息錄入

執(zhí)行者：直接執(zhí)行者：系統(tǒng)管理員,，間接執(zhí)行者：讀者 目的：錄入新讀者相關信息，包括姓名,、身份,、學院 過程描述：

（1）系統(tǒng)管理員登陸基本數(shù)據(jù)修改功能子系統(tǒng)，點擊“讀者信息錄入”（2）寫入讀者相應信息,，將讀者信息保存至數(shù)據(jù)庫

（3）發(fā)放圖書證

（4）創(chuàng)建完成,，讀者信息錄入成功，在數(shù)據(jù)庫管理子系統(tǒng)增加圖書信息,，退出系統(tǒng)

4．“讀者信息注銷”用例 用例編號：0303 用例名：讀者信息銷毀

執(zhí)行者：直接執(zhí)行者：系統(tǒng)管理員,，間接執(zhí)行者：讀者

目的：當讀者由于工作地點變化或其他原因，無需再使用圖書館的圖書資料時,，應當為其辦理注銷

過程描述：

（1）系統(tǒng)管理員登陸基本數(shù)據(jù)修改功能子系統(tǒng),，點擊“讀者信息注銷”（2）查詢讀者的借閱記錄

若有未歸還圖書，給出提示：暫時不能注銷

否則注銷讀者,，提示：注銷后,，不能借閱圖書 若不確定，返回上一層界面

（3）注銷圖書證,，刪除基本數(shù)據(jù)修改功能子系統(tǒng)中的讀者信息（4）注銷完成,，在數(shù)據(jù)庫管理子系統(tǒng)刪除讀者信息，退出系統(tǒng) 5．“書籍信息錄入”用例 用例編號：0305 用例名：書籍信息錄入

執(zhí)行者：直接執(zhí)行者：系統(tǒng)管理員,，間接執(zhí)行者：圖書管理員,，數(shù)據(jù)庫管理子系統(tǒng) 目的：圖書館里的圖書根據(jù)館藏需求進行更新 過程描述：

（1）系統(tǒng)管理員登陸基本數(shù)據(jù)修改功能子系統(tǒng),，點擊“書籍信息錄入”

（2）寫入圖書相應信息

（3）圖書管理員給圖書進行分類編號，記錄條形碼信息（4）圖書管理員為圖書張貼條形碼

（5）圖書管理員檢查圖書編號是否入庫

（6）在數(shù)據(jù)庫管理子系統(tǒng)增加圖書信息,，書籍信息錄入成功,，退出系統(tǒng) 相應活動圖如下：

系統(tǒng)管理員界面圖書管理員數(shù)據(jù)庫管理子系統(tǒng)登陸基本數(shù)據(jù)修改功能子系統(tǒng)點擊書籍信息錄入圖書進行分類編號，記錄條形碼信息圖書張貼條形碼檢查圖書編號是否入庫增加圖書信息[否]退出系統(tǒng)[是]

6．“書籍信息注銷”用例

用例編號：0306 用例名：書籍信息注銷

執(zhí)行者：直接執(zhí)行者：系統(tǒng)管理員,，間接執(zhí)行者：圖書管理員,，數(shù)據(jù)庫管理子系統(tǒng)

目的：當圖書館里藏書，由于受到毀損或其他意外的破壞而無法再使用的情況下,，需要對館藏圖書進行注銷,。過程描述：

（1）系統(tǒng)管理員登陸基本數(shù)據(jù)修改功能子系統(tǒng)，點擊“書籍信息注銷”

（2）輸入圖書編號,，若該書借閱出庫,，則暫時不能注銷，提示“該書借閱中,，不能注銷”,；若該書未被借閱，提示“確定要注銷此書嗎,？”若不確定,，返回上一層界面（3）成功注銷圖書后，在數(shù)據(jù)庫管理子系統(tǒng)刪除圖書信息,，退出系統(tǒng)

三,、系統(tǒng)分析

3.1建立對象類（1）reader 類名：reader 類的類型：該類創(chuàng)建的對象是持久對象，存儲在服務器上的數(shù)據(jù)庫中,，不可以共享 功能：負責讀者信息并對這些信息進行處理，便于對讀者借閱信息進行統(tǒng)一管理,。屬性：讀者的編號id（reader_id）,、姓名（reader_name）、身份（identification）,、學院（academy）,、所借書籍的編號（borrowed）等 操作：借書和還書、接受相應處理

(2)system admin 類名：system admin 類的類型：該類創(chuàng)建的對象是持久對象,，存儲在服務器上的數(shù)據(jù)庫中,，不可以共享 屬性：編號和姓名等

操作：讀者信息管理、書籍信息管理,、借閱管理,、（3）books admin 類名：books admin

類的類型：該類創(chuàng)建的對象是持久對象，存儲在服務器上的數(shù)據(jù)庫中,，不可以共享 屬性：編號和姓名等

操作：借閱管理,、書籍信息錄入,、書籍信息修改、書籍信息注銷（3）books 類名：books 類的類型：該類創(chuàng)建的對象是持久對象,，存儲在服務器上的數(shù)據(jù)庫中,，可以共享 屬性：書名、作者,、書籍編碼,、類別、價錢,、入庫時間 操作：分類編號,、記錄條形碼信息、（4）borrow 類名：borrow 類的類型：該類創(chuàng)建的對象是持久對象,，存儲在服務器上的數(shù)據(jù)庫中,，不可以共享 屬性：借閱書籍的編號、借閱時間,、操作：借書,、還書、續(xù)借書,、交欠款,、交罰款（5）data 類的類型：該類創(chuàng)建的對象是持久對象，存儲在服務器上的數(shù)據(jù)庫中,，不可以共享 屬性：書籍信息,、讀者信息、借閱信息

操作：讀者信息錄入,、讀者信息修改,、讀者信息注銷、書籍信息錄入,、書籍信息修改,、書籍信息注銷、增加借閱信息,、刪除借閱信息 3.2 建立對象類圖

reader+編號+姓名+身份+學院+所借書籍的編號+借書()+還書()+接受相應處理()data+書籍信息+讀者信息+attribute1+讀者信息錄入()+讀者信息修改()+讀者信息注銷()+書籍信息錄入()+書籍信息修改()+書籍信息注銷()+增加借閱信息()+刪除借閱信息()system admin+編號+姓名+讀者信息管理()+書籍信息管理()+借閱管理()books+書名+作者+書籍編碼+類別+價錢+入庫時間+分類編號()+記錄條形碼信息()borrow+借閱書籍的編號+借閱時間+借書()+還書()+續(xù)借書()+交欠款()+交罰款()books admin+編號+姓名+借閱管理()+書籍信息錄入()+書籍信息修改()+書籍信息注銷()圖2-1 圖書館管理系統(tǒng)類圖

四,、系統(tǒng)設計

4.1順序圖建模

◆在“借書”用例中涉及的對象間的交互分析如下：

1）登錄系統(tǒng)。圖書管理員登陸“基本數(shù)據(jù)修改功能子系統(tǒng)”,，對讀者的借書要求進行處理,。涉及的對象：

·消息的發(fā)送者：“系統(tǒng)管理員”對象 ·消息的接收者：“基本數(shù)據(jù)修改功能子系統(tǒng)借閱窗口”對象 傳遞的消息：

·消息：口令密碼（）

·消息的類型：同步消息

·返回消息：口令密碼正確或出錯信息 2）輸入圖書證編號。涉及的對象：

·消息的發(fā)送者：“基本數(shù)據(jù)修改功能子系統(tǒng)借閱窗口”對象 ·消息的接收者：“基本數(shù)據(jù)修改功能子系統(tǒng)借閱窗口”對象

傳遞的消息：

·消息：核對圖書證編號（）·消息的類型：自調用消息

·返回消息：圖書證編號正確或出錯信息 3）輸入圖書編號,。涉及的對象：

·消息的發(fā)送者：“基本數(shù)據(jù)修改功能子系統(tǒng)借閱窗口”對象 ·消息的接收者：“reader”對象

傳遞的消息：

·消息：[最大借書額為0]:核對借書額（）·消息的類型：同步消息

·返回消息：可以借書 4）確定借閱圖書,。涉及的對象： ·消息的發(fā)送者：“reader”對象 ·消息的接收者：“reader”對象 傳遞的消息：

·消息：[確定借書]: 借閱證號增加借閱信息記錄（）·消息的類型：自調用消息 ·返回消息：借書成功 5）修改數(shù)據(jù)庫。涉及的對象： ·消息的發(fā)送者：“reader”對象 ·消息的接收者：“數(shù)據(jù)庫管理系統(tǒng)借閱管理”對象

傳遞的消息：

·消息：[借書成功]: 保存借閱記錄并修改庫存圖書數(shù)量、讀者借出數(shù)量（）·消息的類型：同步消息

·返回消息：退出系統(tǒng)

根據(jù)以上確立的“借書”用例圖中涉及的對象,，建立“借書”用例的順序圖如圖3-1：

基本數(shù)據(jù)修改功能子系統(tǒng)借閱窗口reader數(shù)據(jù)庫管理系統(tǒng)借閱管理窗口 : 圖書管理員1 : 登錄系統(tǒng)()2 : 核對圖書證編號()3 [最大借書額為0] : :核對借書額()4 [確定借書] : 借閱證號增加借閱信息記錄()5 [借書成功] : 保存借閱記錄并修改庫存圖書數(shù)量,、讀者借出數(shù)量()圖3-1 “借書”用例順序圖

◆在“還書”用例中涉及的對象間的交互分析如下：

1）登錄系統(tǒng)。圖書管理員登陸“基本數(shù)據(jù)修改功能子系統(tǒng)”,，對讀者的還書要求進行處理,。涉及的對象：

·消息的發(fā)送者：“系統(tǒng)管理員”對象 ·消息的接收者：“基本數(shù)據(jù)修改功能子系統(tǒng)還書窗口”對象 傳遞的消息：

·消息：口令密碼（）

·消息的類型：同步消息

·返回消息：口令密碼正確或出錯信息

2）輸入圖書證編號。涉及的對象：

·消息的發(fā)送者：“基本數(shù)據(jù)修改功能子系統(tǒng)還書窗口”對象 ·消息的接收者：“基本數(shù)據(jù)修改功能子系統(tǒng)還書窗口”對象

傳遞的消息：

·消息：核對圖書證編號（）

·消息的類型：自調用消息

·返回消息：圖書證編號正確或出錯信息

3）超期罰款處理,。涉及的對象：

·消息的發(fā)送者：“基本數(shù)據(jù)修改功能子系統(tǒng)還書窗口”對象 ·消息的接收者：“基本數(shù)據(jù)修改功能子系統(tǒng)超期罰款窗口”對象 傳遞的消息：

·消息：[超期]：超期罰款（）·消息的類型：同步消息 ·返回消息：銷毀超期信息

3）丟失罰款處理,。涉及的對象：

·消息的發(fā)送者：“基本數(shù)據(jù)修改功能子系統(tǒng)還書窗口”對象 ·消息的接收者：“基本數(shù)據(jù)修改功能子系統(tǒng)丟失罰款窗口”對象

傳遞的消息：

·消息：[丟失]：丟失罰款（）·消息的類型：同步消息 ·返回消息：銷毀超期信息

4）輸入圖書編號。涉及的對象：

·消息的發(fā)送者：“基本數(shù)據(jù)修改功能子系統(tǒng)還書窗口”對象 ·消息的接收者：“reader”對象 傳遞的消息：

·消息：[借閱]：核對是否借閱此書（）·消息的類型：同步消息 ·返回消息：是否借閱此書 5）確定還書,。涉及的對象： ·消息的發(fā)送者：“reader”對象 ·消息的接收者：“reader”對象

傳遞的消息：

·消息：[確定還書]: 借閱證號刪除借閱信息記錄（）·消息的類型：自調用消息 ·返回消息：還書成功

6）修改數(shù)據(jù)庫,。涉及的對象：

·消息的發(fā)送者：“reader”對象 ·消息的接收者：“數(shù)據(jù)庫管理系統(tǒng)借閱管理”對象

傳遞的消息：

·消息：[還書成功]: 刪除借閱記錄并修改庫存圖書數(shù)量、讀者借出數(shù)量（）·消息的類型：同步消息 ·返回消息：退出系統(tǒng)

根據(jù)以上確立的“還書”用例圖中涉及的對象,，建立“還書”用例的順序圖如圖：

基本數(shù)據(jù)修改功能子系統(tǒng)還書窗口基本數(shù)據(jù)修改功能子系統(tǒng)超期罰款窗口基本數(shù)據(jù)修改功能子系統(tǒng)丟失罰款窗口reader : 圖書管理員1 : 登錄系統(tǒng)()2 : 核對圖書證編號()3 [超期] : ：超期罰款()4 [丟失] : ：丟失罰款()5 [借閱] : ：核對是否借閱此書()6 [確定還書] : : 借閱證號刪除借閱信息記錄()

圖3-2 “還書”用例順序圖一

reader數(shù)據(jù)庫管理系統(tǒng)借閱管理5 [確定還書] : : 借閱證號刪除借閱信息記錄()6 [還書成功] : :刪除借閱記錄并修改庫存圖書數(shù)量,、讀者借出數(shù)量()

圖3-3 “還書”用例順序圖二

4.2 構件圖建模

構件圖主要用于建立系統(tǒng)的靜態(tài)實現(xiàn)視圖模型，通過構件之間的依賴關系描述系統(tǒng)軟件的組織結構,，展示了系統(tǒng)中的不同物理構件機器之間的聯(lián)系,。

圖3-4所示的是圖書館管理系統(tǒng)部分構件圖，圖書管理員登陸“基本數(shù)據(jù)修改功能子系統(tǒng)”并成功通過驗證后,，進入基本數(shù)據(jù)修改功能子系統(tǒng)主界面

圖書管理員登陸驗證基本數(shù)據(jù)修改功能子系統(tǒng)主界面續(xù)借書借書還書丟失罰款超期罰款圖3-4 基本數(shù)據(jù)修改功能子系統(tǒng)構件圖

4.3 配置圖建模

實用配置圖定義的軟硬件結構及通訊機制,，表示軟硬件系統(tǒng)之間的合作關系；使用構件圖描述系統(tǒng)由哪些構件組成,。

圖書館管理系統(tǒng)是一個客戶/服務器和服務器/瀏覽器相結合的系統(tǒng),，可以同配置圖顯示系統(tǒng)的物理結構，如圖3-5所示：

tcp/ip應用服務器odbc圖3-5 圖書館管理系統(tǒng)配置圖sql server13 客戶程序數(shù)據(jù)庫服務器

銀行儲蓄管理系統(tǒng)uml建模篇五

實驗3 動態(tài)建模

一,、實驗目的與要求 掌握分析atm系統(tǒng)用例中用例的流程,，分析對象之間的交互關系 掌握用uml設計參與對象之間的交互，用狀態(tài)圖,、時序圖,、協(xié)作圖和活動圖來描述系統(tǒng)的行為。

二,、實驗設備、環(huán)境

pc(一臺),，windows 2000或以上版本,，安裝microsoft visio 2003

三、實驗內容及步驟 交互圖：實現(xiàn)atm系統(tǒng)的序列關系圖和通信（協(xié)作）關系圖,； 2 分析設計軟件系統(tǒng)的狀態(tài)圖,。（（1）和（2）選做一個狀態(tài)圖）；

（1）atm系統(tǒng)

（2）具體題目如下：某銷售pos機,，它的工作流程是：當客戶到收銀臺后,，收銀員逐一輸入用戶購買的商品,，輸入完之后，計算出總金額,，然后等待用戶付款,，確定支付成功之后，完成收銀,，等待下一個客戶,。請為其繪制出相應的狀態(tài)機圖。

3分析設計atm系統(tǒng)的活動圖（選做1個活動圖）,。

建立動態(tài)模型：

建立序列關系圖,、狀態(tài)圖、活動圖

步驟：

?

編寫腳本

?

確定各個對象之間的事件

?

構造事件追蹤圖（交互圖）?

構造狀態(tài)圖

?

添加活動和動作

一,、時序關系圖

1）atm系統(tǒng)的正常情況腳本

? atm請儲戶插卡,；儲戶插入一張現(xiàn)金兌換卡。? atm接受該卡并讀它上面的卡號,。

? atm要求儲戶輸入密碼,；儲戶輸入自己的密碼“1234”等數(shù)字。

? atm請求系統(tǒng)驗證卡號和密碼,；核對儲戶密碼,，然后通知顯示器顯示說這張卡有效。

? atm要求儲戶選擇事務類型（取款,、轉賬,、查詢等）；儲戶選擇“取款”,。? atm要求儲戶輸入取款額,；儲戶輸入“880”。

? atm確認取款額在預先規(guī)定的限額內,，然后要求處理這個事務,；成功處理完這項事務并返回該賬戶的新余額。

? atm吐出現(xiàn)金并請儲戶拿走這些現(xiàn)金,；儲戶拿走現(xiàn)金,。? atm問儲戶是否繼續(xù)這項事務；儲戶回答“不”,。

? atm打印賬單,，退出現(xiàn)金兌換卡，請儲戶拿走它們,；儲戶取走賬單和卡,。? atm請儲戶插卡。

2）atm系統(tǒng)的異常情況腳本

? atm請儲戶插卡；儲戶插入一張現(xiàn)金兌換卡,。? atm接受該卡并順序讀它上面的數(shù)字,。

? atm要求密碼；儲戶誤輸入“8888”等數(shù)字,。

? atm請求總行驗證卡號和密碼,；經(jīng)驗證發(fā)現(xiàn)密碼錯誤，拒絕這張卡,。? atm顯示“密碼錯”,，并請儲戶輸入密碼；儲戶輸入“1234”等數(shù)字,；atm請求總行驗證后知道輸入密碼正確,。

? atm要求儲戶選擇事務類型；儲戶選擇“取款”,。

? atm詢問取款額,；儲戶改變主意不想取款了，按“取消”,。? atm退出現(xiàn)金兌換卡,，請儲戶拿走它們；儲戶取走卡,。? atm請儲戶插卡,。

atm 腳本的事件時序圖如下圖所示：（正常情況）

用戶讀卡器顯示器atm卡用戶賬戶事務提款機插卡讀卡初始化提示輸入密碼輸入密碼驗證密碼獲取密碼獲取賬戶初始化提示選擇業(yè)務選擇業(yè)務執(zhí)行事務初始化提示輸入金額輸入金額獲取余額驗證取款金額計算余額計算利息更新賬戶配給現(xiàn)金打印收據(jù)退卡

二、狀態(tài)圖

主屏]do：顯示主屏幕插卡[可讀]do：要求密碼輸入密碼do:驗證賬戶繼續(xù)密碼錯拿走卡退卡do：退卡請拿走卡插卡[不可讀]不可讀的卡do：顯示信息取消取消do:顯示取消信息無效賬戶賬戶有效do:要求類型取消輸入類型do:要求金額取消結束do：打印賬單do:顯示無效賬戶信息輸入金額等待5秒do:處理事務中止取消do:請求繼續(xù)拿走現(xiàn)金do：吐出現(xiàn)金請拿走現(xiàn)金事務成功取消事務失敗do:失敗信息網(wǎng)絡響應等待網(wǎng)絡響應中斷do：顯示取消信息atm類的狀態(tài)圖

處理事務驗證賬戶請求處理事務請求驗卡事務成功事務失敗無效賬戶賬戶有效密碼錯

事務處理狀態(tài)圖

賬戶驗證狀態(tài)圖

三,、活動圖

插卡<沒有接收動作>輸入密碼<沒有接收動作>輸入賬戶類型輸入金額取卡取錢<沒有發(fā)送動作>

四,、實驗體會

順序圖的重點是完成某個行為的對象類之間所傳遞的消息的時間順序。一個順序圖事務對象角色,，生命線,，激活期和消息構成。協(xié)作圖用于描述系統(tǒng)的行為是如何有系統(tǒng)的成分合作實現(xiàn)的,。協(xié)作時一種靜態(tài)結構,，是一個系統(tǒng)對實現(xiàn)某些服務所涉及的對象及其交互的投影。一個協(xié)同定義了一組對某些服務有意義的參加者和它們的聯(lián)系,，這些參加者定義了交互中的對象所扮演的角色,。