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

銀行儲蓄管理系統uml建模篇一

廣西科技大學

guangxi university of scienceand technology

課 程 作 業

專

業： 計算機科學與技術

班級學號：

學生姓名：

班級學號：

學生姓名：

指導教師：

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

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

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

2.1.1與現有系統比較的優越性...............................................................................................4 2.1.2 技術可行性評價..............................................................................................................4 2.2 經濟可行性分析.........................................................................................................................4

2.2.1 支出.................................................................................................................................4 2.2.2 投資回收周期..................................................................................................................4 網上購物系統的分析............................................................................................................................5

3.1 網上購物系統的需求分析：.....................................................................................................5 3.2 用例分析....................................................................................................................................5

3.2.1確定用例:.........................................................................................................................5 3.2.2 創建用例..........................................................................................................................5 3.2 用例分析....................................................................................................................................6

3.2.3創建用例圖.......................................................................................................................6 3.3 類圖分析....................................................................................................................................7

3.3.1 當前系統的類..................................................................................................................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 系統的協作圖分析...................................................................................................................11

3.5.1 顧客訂購協作圖............................................................................................................11 3.5.2 顧客刪除訂單的協作圖................................................................................................11 3.5.3 管理員處理訂單協作圖................................................................................................12 3.6 系統的狀態圖分析...................................................................................................................13

3.6.1 管理員狀態圖................................................................................................................13 3.6.2 用戶狀態圖....................................................................................................................13 3.7 系統的構件圖分析...................................................................................................................14

3.7.1 網上購物系統構件圖....................................................................................................14 3.8 系統的部署圖分析...................................................................................................................15

3.8.1 網上購物系統部署圖....................................................................................................15 參考書籍.............................................................................................................................................17 結

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

摘要

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

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

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

關鍵詞：

統一建模語言 面向對象分析

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 選題背景 引言

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

1.2 選題意義和目的

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

1.3 研究方法

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

2.1 技術可行性分析

2.1.1與現有系統比較的優越性

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

針對性：該平臺設計是網上購物系統及后臺管理的定向開發設計，所以具有專業突出和很強的針對性。

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

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

2.2 經濟可行性分析

2.2.1 支出

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

為了今后的系統維護，開發團隊準備聯合具有豐富經驗的軟件開發人員共同研究，這為今后系統的順利開發提供了有力的技術條件。2.2.2 投資回收周期

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

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

3.1 網上購物系統的需求分析：

1：普通用戶可以登陸系統，成為登陸后用戶。

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

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

4：登陸后用戶可修改購物數量。

3.2 用例分析

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

3.2 用例分析

3.2.3創建用例圖

系統管理的用例圖如圖3-1所示：

系統用戶的用例圖如圖3-2所示：

3.3 類圖分析

3.3.1 當前系統的類

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

網上購物系統的類圖如圖3-3所示：

圖3-3 網上購物系統的類圖

3.4 時序圖分析

3.4.1 時序圖描述

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

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

入適當的查詢條件后，查詢模塊將顯示商品列表。客戶得到商品列表后，提交自己想要購買的商品id，訂購模塊得到商品id。生成訂單并提交給數據庫模塊進行保存，保存成功后，提示用戶訂購商品成功。顧客訂購的時序圖如圖3-4所示：

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

3.4.3客戶刪除訂單的時序圖

客戶在提交訂單后可以對訂單進行維護（添加，刪除，修改）。客戶首先輸入自己的帳號和密碼登陸系統，登陸模塊會將客戶的id保存在系統緩存中，并提交給訂單查詢模塊。訂單查詢模塊會顯示當前所有的訂單，顧客得到該列表后，選擇要刪除商品的id，訂單處理模塊把刪除信息提交給數據模塊，數據模塊保存信息。訂單處理提示用戶刪除成功?？蛻魟h除訂單的時序圖如圖3-5所示：

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

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

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

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

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

3.5 系統的協作圖分析

3.5.1 顧客訂購協作圖

顧客訂購協作圖如圖3-7所示：

圖3-7 顧客訂購協作圖

3.5.2 顧客刪除訂單的協作圖

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

圖3-8 顧客刪除訂單的協作圖

3.5.3 管理員處理訂單協作圖

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

圖3-9 管理員處理訂單協作圖

3.6 系統的狀態圖分析

3.6.1 管理員狀態圖

管理員狀態圖如圖3-10所示：

圖3-10 管理員狀態圖

3.6.2 用戶狀態圖

用戶狀態圖如圖3-11所示：

圖3-11 用戶狀態圖

3.7 系統的構件圖分析

3.7.1 網上購物系統構件圖

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

圖3-12 構件圖

3.8 系統的部署圖分析

3.8.1 網上購物系統部署圖

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

desktop...16

desktop...registrations lanerverwebbrowserbuyingsystemsalesystemmaintainsystemlandesktop pc(saler)

圖3-13 網絡購物系統的配置圖internet 參考書籍

[1] 面向對象程序設計高級教程，陳奇，高等教育出版社，2001 [2] 標準建模語言uml極其支持環境，周伯生，張莉等，北京：計算機世界，1998 [3] uml和模式應用——面向對象分析和設計導論，craig larman等，姚淑珍，李虎譯，機械工業出版社，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建模應用到構建系統設計上，并通過八種框圖，從各種角度觀察系統來進行需求分析、系統設計。通過一個完整的簡單例子來說明uml在整個系統設計所發揮的作用。

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

通過這次的設計，知道自己的不足，我相信自己會在一定時間內通過不斷的學習和實踐提高自己的能力，設計給我帶來很大的幫助，同時開闊了我的眼界，使我明白只有自己親自實踐，才能了解自己所做的東西，如果沒有實踐，恐怕就不會有電流的產生，地球為什么是圓的，以及現在的一切。勤于實踐不僅能鍛煉自己，還能夠提高17

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

銀行儲蓄管理系統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建模篇四

基于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<

>借書<

>續借書圖書管理員借閱管理<

><

>還書超期罰款<

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

><

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

>讀者信息修改系統管理員書籍信息管理<

>書籍信息錄入<

><

>書籍信息修改圖書管理員書籍信息銷毀圖1-3 基本數據修改功能子系統

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建模篇五

實驗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類的狀態圖

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

事務處理狀態圖

賬戶驗證狀態圖

三、活動圖

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

四、實驗體會

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