第一篇：uml案例教務管理系統
某大學教務管理系統UML模型
隨著高校校園網的建設和Internet技術的引進，基于校園網和Internet的應用系統的開發正在蓬勃發展。教務管理師高校教學管理的一向重要工作，現代化的高校教務管理需要現代化的信息管理系統支持。新世紀背景下，高校教育體制進行了大規模的改革，招生人數逐年增加，教學計劃不斷更新。在高校日常管理中，教務管理無疑是核心工作，重中之重。其管理模式的科學化與規范化，管理手段的信息化與自動化對于學校的總體發展產生深遠的影響，由于管理內容過多，繁瑣，處理的過程也非常復雜，并且隨著學校人員的增加，教務管理系統的信息量大幅上升，因此往往很難及時準確地掌握教務信息的運作狀態這使得高校教務管理的工作量大幅度增加，另外，隨著教育改革的不斷深化，教學管理模式也在發生變化，例如實施學分制、學生自主選課等。這一切都有賴于計算機網絡技術和數據庫技術的支持，在這樣的形勢下建立和完善一個集成化的教務管理系統勢在必行。
目前，國內高校都開發了自己基于校園網的教務管理系統。由于其教務管理模式不盡相同，不同學校的實際教務管理情況各有自己的特點，因而各高校需要針對自己的教務管理模式和特點建立自己的教務管理系統。本設計是基于某高校的教務管理模式開發的基于校園網的教務管理系統。這樣一個系統不僅可以降低工作量、提高辦公效率，而且使分散的教務信息得到集中處理，對減輕教務工作負擔、提高教務管理水平、實現教務管理的現代化具有重要意義。
1.建立系統用例模型
1.1確定系統模型的參與者
仔細分析教務管理系統問題描述。在UML中，角色代表位于系統之外和系統進行交互的一類對象，本系統中創建主要的角色有以下三類：
(1)教務員：教務員在教學管理系統中對全體學生進行用戶登錄、學籍管理、選課管理、教學管理和成績管理，并且對教師進行登錄管理、教學管理和成績管理。教務處工作人員處理日常的系統維護，例如維護和及時更新學生，教師信息以及安排選課等。
(2)教師：教師根據教務系統的選課安排進行教學，將學生的考試成績錄入此系統。 (3)學生：學生能夠在教務管理系統更改學籍信息、進行選課、查詢已選課程和考試成績。
1.2識別用例
用例是系統外部參與者與系統在交互過程中需要完成的任務，識別用例最好的方法就是從分析系統的參與者開始，考慮每一類參與者需要使用系統的哪些功能，如何使用系統，根據教務管理系統的運行流程個提取的參與者信息，確定系統分為以下幾個用例： (1)學生參與者用例：
用戶登錄 學籍管理 選課管理 (2)教師參與者用例：
用戶登錄 成績管理 教學管理
(3)教務員參與者用例：
用戶登錄 學籍管理 排課管理 成績管理 選課管理 教學管理 系統維護
1.3建立如下四個用例圖模型
(1)頂層用例圖如圖1-1所示
圖1-1頂層用例圖
從用例圖1-1可以看出學生、教師和教務員都使用了“用戶登錄”用例，表示學生必須先進行用戶登錄后才可以進行學籍管理和選課管理。同理，教師也必須登錄后才能進行成績管理和教學管理。教務員登錄后進行系統設置、學籍管理、排課管理和教學管理等操作。
(2)學生角色用例圖 如圖1-2所示
圖1-2學生角色用例圖
從用例圖1-2可以看出學生登錄后才能進行所有的操作，這樣可以提高系統的安全性。 (3)教師角色用例圖如圖1-3所示
圖1-3教師角色用例圖 從用例圖1-3可以看出教師所有的用例都是建立在“用戶登錄”基礎上，表示教師必須先登錄后才可以執行相應的功能，這樣可以提高系統的安全性，以免有人故意提供虛假信息。 (4)教務員角色用例圖如圖1-4所示
圖1-4教務員角色用例圖
從用例圖1-4可以看出教務員的用例相對較多，但是教務員的所有的用例都必須在“用戶登錄”的基礎上，表示教務員必須先登錄才可以執行相關的功能，這樣同樣可以提高系統的安全性，避免有人故意更改信息。
2 建立系統動態模型 2.1活動圖
經過活動圖的建?？梢员容^清楚地了解整個進程過程的操作過程，本系統中主要的活動圖有如下幾個：學生成績查詢活動圖、教務員修改學生資料活動圖、學生選課活動圖以及教師成績錄入活動圖
(1)學生成績查詢圖如圖2-1所示
圖2-1 學生成績查詢活動圖
從圖2-1可以看出，活動圖分為多個不同的泳道，每個泳道表示學生在查詢成績活動中不同參與者的工作流。每個泳道中的活動是參與者要執行的操作。通過不通泳道之間的活動過渡，可以了解參與者之間的通信。這些信息可以幫助我們更好地理解系統的業務過程。
在學生成績查詢活動圖中可以知道，學生、教師和教務員之間存在著相互聯系。學生登錄以后可以查詢已選科目和成績單，如果發現自己的成績單有錯誤后可以通知教務員成績有誤，教務員聯系教師后，教師修改成績，然后教務員更新數據庫。成績無誤后，查詢結束。
(2)教務員學生資料修改活動圖如圖2-2所示; (3)學生選課活動圖如圖2-3所示;
圖2-2教務員學生資料修改活動圖圖2-3學生選課活動圖
從圖2-2可以看出，教務員登錄教務系統，系統驗證用戶名和密碼，若有錯誤重新輸入，無誤后進行選擇修改項目，確定修改，
圖2-3學生選課活動圖圖2-4 教師成績錄入活動圖
2.2順序圖
主要包括如下幾個順序圖 ①教務學籍管理順序圖 ②學生注冊順序圖 ③學生選課順序圖 ④教師成績錄入順序圖
圖2-5教務學籍管理順序圖
圖2-6學生注冊順序圖
圖2-7教師成績錄入順序圖
3系統類模型 3.1系統包圖
將整個教務管理系統劃分為人員信息、接口和事務3個包，分別控制不同的應用。
3.2類圖
根據系統劃分的三類包圖，分別討論人員信息包，接口包和事務包中的類圖分別為： (1)人員信息包內的類圖 (2)接口包內的類圖 (3)事務包內的類圖
圖3-1 人員信息包內的類圖
圖3-2接口信息包內的類圖
圖3-3系統事務信息包內的類圖
第二篇：UML庫存管理系統
UML課程設計
報告 設計名稱： 庫存管理系統
專業班級： 姓 名： 學 號： 起止時間： 成 績 評 定
考核 設計 設計 綜合評 答辯 內容 表現 報告 定成績 成 績 計算機科學與工程系
一、系統需求說明 20世紀90年代以來隨著科學技術和生產力的迅速發展以及經濟全球環境的深刻變化，企業面臨著一個嶄新而又激烈的競爭環境，體現在全球化的信息網絡和全球化市場形成所帶來的信息爆炸技術變革的加速市場和勞務競爭的全球化，圍繞新產品的市場競爭日趨激烈，用戶的需求越來越苛刻，同時產品的生命周期不斷縮短，企業又面臨著縮短交貨期、提供產品質量、降低成本和改進服務的壓力，在這種情況下全面提高和改善自身水平成為企業最關心的問題之一。企業實施信息化建設已成為企業的發展趨勢和提高企業的管理水平的有效手段。信息化建設不在是企業的效益工程而是企業的生存工程，20世紀90年代美國著名的IT分析公司Grant Group Inc,提出了ERP企業資源計劃的概念，迎合了信息時代企業管理的發展要求。隨著ERP相關理論，以及ERP系統開發的逐漸成熟，企業界掀起了實施ERP管理信息系統的浪潮。中國作為制造大國，在制造業迅速發展的今天，庫存國民投資額在整個國民生產總值占有相當大的比重達到了20%——30%，庫存管理的適當與否對企業經營利潤有很大影響，因此新環境下非常值得人們對ERP環境下的庫存管理進行深入研究和探討。 本文結合ERP環境下的庫存管理系統，重點研究如何利用UML建模語言對庫存管理系統進行建模，給出了ERP環境下庫存管理系統的需求模型和對象模型，在建模過程中利用了用例圖、類圖、包圖、順序圖等圖形。最后，結合系統模型的研究，實現了庫存管理系統。
二、系統分析
(一) 庫存管理業務流程分析 企業的庫存管理工作主要由企業物資部門或倉庫部門完成，其主要業務就是對企業物料收獲、存貨、發貨，以及分析提供庫存管理所需的各種數據報表等管理工作。 庫存管理業務流程圖，如圖所示： 采購部門采購訂單 供應商發票 財務部門發貨 檢驗接受庫存盤點發銷售出入庫票貨款憑證求購處理入庫領料通知單生產發料發料 生產部門倉庫部門客戶入庫 庫存訂單工票產品入庫分析提貨單決策部門銷售部門 2
(二) Uml表示法 1.1 用例圖 根據業務流程圖確定系統邊界，確定用例(Use Case)。用例可從另一個方面對企業的業務流程建模，從中可以提取對我們開發系統有用的信息，可以確定系統功能。如圖2所示庫存管理系統的用例圖
inter manageout manageadministratorinventory manage
information search
該圖展示了一張倉庫管理系統的用例圖，從系統的外部執行者的角度來看，普通倉庫管理員可以進行出庫管理、入庫管理、盤點管理和信息查詢等操作。 (2)順序圖
: administrator1: load
2: back3: data name and position4: copy data5: copy success 3
(3)活動圖
produce inventory bills inventory on the spot inventory manage
三、系統設計報告 (一) 庫存管理系統需求模型的建立
1、用例圖 在庫存管理系統中，由于牽扯到大量的執行者和用例，為了便于組織，按與系統交互的對象的不同將系統劃分為三個包，如圖所示：
用例模型包圖 其它系統與倉庫高層決策人員和系統倉庫管理員管理系統的交互 管理員與系統的交互 與交互系統 倉庫管理員與系統交互包主要描述倉庫管理員要使用系統的那些功能，向系統輸入哪些信息，從系統獲取哪些信息，以及需要系統提供哪些功能支持倉庫管理員的日常工作。高層決策人員及系統管理員與系統交互包描述高層決策人員需要從系統獲取什么信息，做出什么分析與決策支持系統更好的運轉;系統管理員則需要維護，管理系統，使其正?；ぷ?。由于庫存管理系統并不是一個孤立系統，他需要其他系統進行交互，其他系統與庫存管理系統的交互包則反映交互信息的流向。 下面對每個系統包進行詳細的描述。 4
(1)倉庫管理員與交互的用例模型
high-inventory alarm identity testexpand
useinventory place appointaccount updateinter manageuseexpandadministratorout
managelow-inventory alarminventory manageinformation searchform produce 在這個用例模型中有一個執行者：庫存管理員。十一個用例：身份驗證，入庫管理員，最高庫存警報，出庫管理，最低庫存管理，指定庫位，更新賬目，庫存信息查詢，盤點管理及報表生成。 當有物資需要進行出入庫時，倉庫管理員就要進行出入庫的管理：核實賬單，清點物資，錄入單據，然后由系統自動為該批物資分配貨架，同時更新賬目。在入庫時，如果系統檢測該類物資庫存量超過限定的最高存量，也將發出警報。在入庫管理用例與最高庫存警報用例，出庫管理用例與最低庫存警報用例之間采用了擴展關系。入庫管理，出庫管理與指定庫位之間，指定庫位與更新賬目之間采用了使用關系。擴展時一種基本需求的特殊情況。而當在兩個或更多的用例中出現重復描述而又想避免這種重復時，采用使用。 出入庫單據錄入后，倉庫管理員還需要定期對單據進行核對，即進行庫存信息的查詢，主要包括：賬目信息，出入庫信息，以及庫位信息，存量信息等。當所有信息核對完成后，倉庫管理員還需要定期打印出各種報表，以供其他系統做出一些決策。 盤點也是庫管員一項很重要的工作，保持經常有效的盤點，可以更加全面準確的掌握庫存信息。當庫管員進行盤點時，首先要鎖定盤點的庫位或物料信息，即盤點時刻不允許出入庫;盤點完畢后，要填寫盤點記錄，對于盤點數量與賬目數量不同的物料需求要給出原因。 5
(2)高層決策人員與系統管理員的交互用例模型
inventory originallimits manage
inventory controlidentity testadministratorhigh-adminform produceanalyze reportdata copy and resume 在這個用例模型中共有兩個執行者：高層決策人員，系統管理員。七個用例：基本信息維護、數據的備份與恢復、身份驗證、倉庫信息初始化、庫存控制、分析評價及庫存信息查詢。其中身份驗證和庫存信息查詢用例和庫管員和系統的交互的用例是同一用例。對于高層決策人員來講倉庫一些基本信息的初始化，主要是賬目和庫位信息初始化。當系統開始使用，高層決策人員還是要進行一些庫存控制，即為了滿足用戶及生產需求，確定最低庫存量，決定訂貨時間及訂貨量。當然為了及時動態了解庫存情況，還需要一些庫存信息進行分析評價，例如：資金占用情況，積壓失效情況，倉庫使用情況等。不論是做決定還是分析，都需要庫存基本信息支持。對于系統管理員來講，主要的工作室進行基本信息的維護，包括權限的管理和數據的備份與恢復。 (3)其它系統與庫存系統的交互
out manageform produceproduce sys information searchsupply syscost manage project data syssell sysinter manage 由于庫存管理系統并不是一個獨立的系統，他需要和其他系統進行信息的集成，以保證數據的完整和準確。再生產計劃出入庫時，需要根據計劃來限制出入庫的物資品種及數量。 6
當然，計劃的制定還需要準確的庫存信息。采購供應管理系統需要根據庫存信息來制定采購計劃，外購物資則需要根據采購計劃進行入庫。庫存管理系統需要用工程數據管理系統中的一些基本信息，包括：物料信息，人員信息，以支持系統準確的進行。銷售和成本核算管理系統的梳理進行同樣需要庫存數據的支持。 2.業務活動圖 (1)物資入庫活動 inter form receive identity test inter manage inventory inventory inventory place checkcheckstate check alarm transmit inventory place appoint account update 物資的出入庫是庫存管理中主要的業務，合理的出入庫流程不僅能加快出入庫的效率， 7
而且能夠對庫存信息做到心中有數。 當一批物資需要進行出入庫時，首先庫管員需要核對入庫單，清點入庫物資，當入庫單據與入庫物資相符時，才能入庫。接著庫管員登錄系統，通過身份驗證，進入入庫管理主界面。輸入要入庫物資的基本信息后，系統自動進行一些信息查詢：存量信息，庫位狀態，盤點狀態。當該類物資存量超出最高庫存量，系統發出報警，此時可以退出系統，即此類物資不在進行入庫，也可以強行入庫。在檢查庫位信息時，如果發現沒有空余庫位，同樣系統會發出警報，但允許入庫，只是需要人工指定庫位。完成上述步驟，系統會主動為物資安排庫位，更新賬目，到此時也就完成入庫過程。 (2)主要業務活動圖 inventory inter out check account place checkcheckcheck
produce
inter and
inventory formoutmanage
analyze
and
inventory NewStatevaluatecontrole 8
庫存管理的業務都是以出入庫信息，賬目信息和庫位信息為依托進行的。所以首先需要將出入庫信息，賬目信息，庫位信息進行核對，只有這些信息準確無誤才可以進行下一步的工作。核對基本信息后，為了確定倉庫內物資，可以進行盤點;為了進行分析評價，庫存控制，可以生成報表;對一些信息篩選后，可以進行數據的備份或恢復。
(二)庫存管理系統對象模型的建立 1. 類圖 基本信息中的類圖 入庫類別與出庫類別的屬性為出入庫別編碼及名稱，在進行出入庫時，以其為依據判別出入庫類型，例如確定一批貨物是一般收料還是委托加工等等。 不論是倉庫管理員還是系統管理員還是高層決策人員在登錄時，都需要進行身份驗證，以確定其權限，如果是倉庫管理員則需要細化倉庫一級權限。 下圖為主要類圖及沒類圖的具體屬性及操作，如圖所示： 9
10
2.順序圖與協作圖 (1)物資入庫順序圖
inter windowaccountshelves state
inter shelves info1: ready to assign shelve 2: shelve not null3: shelve on inventory4: shelve available5: work normal and update6: back 物資入庫順序圖 在完成入庫單與入庫項的填寫后，進入胃物資指定庫位的操作中，首先系統要自動檢查庫位的狀態，當沒有多余庫位或者庫位正在進行盤點時，則系統提示不能進入下一步的操作，如果有多余庫位則系統自動為物資安排庫位，進行物資的入庫，同時修改庫存信息，此時完成了物資的入庫的所有操作。 (2)物資入庫協作圖 5: error4: error
6: change or check of goods incoming of 3: incoming of change the form(right)formitem2: incoming of form7: checkquit9: surpass of max reserve
window of
account of incomingreserve8: less than max resevelogon 1: incoming of administrgoodsator 11
物資入庫協作圖 上圖為物資入庫的合作圖。在一批物資要入庫時，首先倉庫管理員登陸系統進入入庫窗體，然后進行入庫單錄入，只有在入庫單填寫正確的情況下才能轉入入庫項填寫，如果入庫項填寫錯誤時，同樣不能進行下一步操作;并且如果在填寫入庫項時發現倉庫內此類物資正在盤點，則此批貨物此時不能進行入庫的，需要退出或等待。當所有條件都符合時，系統自動檢查物資的庫存量，但超出倉庫最大庫存時，退出所有操作;反之進入為此貨物指定庫位的操作。 (3)狀態圖
系統人機交互狀態圖
fail logonstartlogonlogon successoperateentry/ inputdo/ check
namefinishreturncancel password and logoncancelcancelfinishexit/ quit
entry/ prompt do/ checkexit/ quit or returnoutcome 人機系統交互狀態圖
四、系統的配置與實現
(一)系統的組件圖
<>Businessp
The user
The
Server The rocessinterfacedatebase 系統組件圖 12
(二) 系統配置圖
clientdatab...program 系統配置圖
五、設計心得體會 項目實訓開始的時候，要求每兩個人選擇一個題目，本以為這會很簡單，可坐下來之后才發現，事實并非如此。從需求分析到最后的課題的終結，中間實現的過程都需要應用很多的理論知識，而時間的推移讓自己發現所學知識的膚淺性，只是模糊的停留在知識的表面，沒有對其深刻的認識與掌握，同時，這也是對信心，和耐心的一次考驗。 通過這次課程設計，小組成員分工合作，我們兩個都學到了很多東西。以前不熟悉的地方都得到了很好的解決。我們通過自我學習掌握一些基本應用，并通過項目來加強對其的理解，我們完成了這一系列的設計。過程是艱苦的，但是通過這次實訓我們學到了很多，結果是美好的。這次課程設計也讓我明白了，作為一個軟件技術的學習者，多動手顯得尤為重要，另外，多看看經典的例題，多與同學之間交流，對于知識和能力的提高也有很大的幫助。由于我們能力有限，加上時間倉促，本系統難免會出現一些不足之處，對于出現的問題，在此深表歉意，如果還有其他問題希望老師批評指正。 13
第三篇：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 描述高校教材管理系統
2 高校教材管理系統
隨著高等學校擴大招生情況的出現，每一個高校需要處理的各種教材的數量逐年倍增。如何改變低效率的原始教材管理方式，成為擺在高校管理人員面前的一個重要課題。而建立高效的教材管理系統就是一個解決此根本問題的思路。所以，這里為讀者介紹一個高校教材管理系統的建模實例。
2.1需求分析
高校教材管理系統的功能性需求綜述如下：
(1)高校的每個學生使用自己的姓名和學號登陸系統之后，可以查詢自己每個學期的教材使用情況，也能夠查詢自己的教材費用。
(2)高校的每個老師使用自己的姓名和密碼登陸系統后，能夠查詢自己教材的使用情況，也可查詢自己的教材費用(供報銷用)。
(3)系統管理員通過用戶名和密碼登陸系統后,能夠輸入教材訂購計劃,生成訂購單,統計各個班級教材費用和教材使用情況,同時，還可以更新刪除學生﹑教師﹑教材等各類信息。
2.2系統建模
在系統建模以前，我們首先需要在Rational Rose 2003中創建一個模型。并命名為“高校教材管理系統”，該名稱將會在Rational Rose 2003的頂端出現，如下圖2-1所示。
圖2-1創建項目系統模型
2.2.1創建系統用例模型
創建系統用例的第一步是確定系統的參與者。高校教材管理系統的參與者包含以下三種：
(1)學生(2)教師(3)系統管理員
此三個參與者如圖2-2所示。
圖2-2 系統參與者圖 2-3 學生用例圖
然后，我們根據參與者的不同分別畫出各個參與者的用例圖。
(1)學生用例圖：學生在本系統中可以進行登錄、教材費用查詢和教材使用情況查詢的相關操作，通過這些活動創建的學生用例圖如圖2-3所示。
(2)教師用例圖：教師在本系統中可以進行登錄、查詢教材費用和教材使用情況查詢的操作，通過這些活動創建的教師用例圖如圖2-4所示。
圖 2-4 教師用例圖圖 2-5 系統管理員用例圖
(3)系統管理員用例圖：系統管理員在本系統中可以進行登錄、教材訂購資料輸入、生成訂購單、統計教材費用、統計教材使用情況和管理各類信息的操作，通過這些活動創建的系統管理員用例圖如圖2-5所示。
2.2.2創建系統靜態模型
從前面的需求分析中，我們可以依據主要六個類對象：學生、教師、班級、教材、庫存和訂單創建完整的類圖如圖2-6所示。
圖2-6 系統類圖
2.2.3創建系統動態模型
系統的動態模型可以使用交互作用圖、狀態圖和活動圖來描述。
2.2.3.1 創建序列圖和協作圖
1.學生在本系統中活動步驟分為：(1)進行注冊個人信息(2)登錄通過身份驗證(3)選擇查詢的教材(4)查詢使用情況(5)返回查詢結果(6)退出系統。根據以上步驟創建的序列圖和協助圖，如下圖2-7和圖2-8所示。
圖 2-7 學生序列圖
圖 2-8 學生協作圖
2.表示教師的序列圖和協作圖與學生序列圖和協作圖相似，只是把學生換成了教師。
3.系統管理員在本系統活動的步驟分為：(1)進行注冊個人信息(2)登錄通過身份驗證(3)管理學生信息、管理教師信息或管理教材信息。(4)退出系統。根據以上步驟創建的的序列圖和協作圖，如圖2-9和圖2-10所示。
圖 2-9 系統管理員序列圖
圖 2-10 系統管理員協作圖
2.2.3.2 創建活動圖
我們還可以利用系統的活動圖來描述系統的參與者是如何協同工作的。高校教材管理系統中，根據教材管理人員、學生和教師的活動步驟，我們可以創建活動圖如下圖2-11所示。
圖 2-11 系統活動圖
2.2.3.3 創建狀態圖
在高校教材管理系統中，有明確狀態轉換的類是系統參與者，在整個驗證過程前后有各種不同的狀態。本系統的狀態圖如下圖2-12所示。
圖 2-12 參與者狀態圖
2.2.4創建系統部署模型
對系統的實現結構進行建模的方式包括兩種，即構件圖和部署圖。高校教材管理系統的構件圖我們通過構件映射到系統的實現類中，說明該構件物理實現的邏輯類，在本系統中，我們可以對學生類、系統管理員類、教師類、教材庫存、訂單類、教材類和班級類分別創建對應的構件進行映射，創建的高校教材管理系統的構件圖如圖2-13所示。
.圖2-13 系統構件圖
高校教材管理系統的部署圖描繪的是系統節點上運行資源的安排。包括四個節點，分別是：客戶端瀏覽器、Http服務器、數據庫服務器和打印機，創建后的部署圖如圖2-14所示。
圖 2-14 系統部署圖
第五篇：圖書管理系統UML分析與設計
1. 系統需求
系統的功能性需求描述如下：
·
圖書管理系統為管理員提供主功能界面。
·
圖書管理系統在啟動時要求管理員輸人口令，只有口令正確，才可以進入系統的主功能界面。
·
管理員負責對圖書管理系統的維護工作，因此系統應賦予管理員對圖書信息、讀者信息和出版社信息進行錄入、修改、查詢和刪除等功能的操作權限。
·
管理員作為讀者的代理實現借書與還書業務。
·
圖書信息、讀者信息和出版社信息保存在對應的數據庫表中。
在上述功能性需求分析的基礎上，可以寫出較為詳細的需求規格說明書，作為進行系統分析、設計和實現的依據。需求分析規格說明書由系統最終用戶提出需求，系統分析人員負責編寫。圖書管理系統需求分析規格說明書如下：
·
這是一個圖書館圖書借閱管理的應用系統;
·
圖書管理系統負責將圖書、雜志借給讀者，前提條件是這些讀者在系統進行了注冊，圖書和雜志也在系統中進行了注冊;
·
圖書館負責新書的購買，當書和雜志已經過時或者破舊不堪時，可以將這些圖書和雜志從圖書館管理系統中刪除;
·
圖書管理員是圖書館的員工，負責與讀者打交道，并且是在系統提供的支持下開展工作;
·
圖書管理系統能夠容易地建立、修改和刪除系統中的信息，包括圖書信息、讀者信息、以及出版社信息等;
·
圖書管理系統能夠在所有流行的平臺環境(windows，uNIx等操作系統)上運行，并具有一個美觀的圖書用戶界面;
·
圖書管理系統容易擴展新功能。
2. 分析建模
Use case diagram 分析
采用下列描述項撰寫用例的腳本。
· 用例名稱——表明用戶的意圖或用例的用途。
· 參與者——與該用例相關的參與者列表。
· 前置條件——一個條件列表，如果其中包含條件，則這些條件必須在訪問用例之前得到滿足。
· 后置條件——一個條件列表，如果其中包含條件，則這些條件將在用例完成以后得到滿足。
· 基本事件流——描述用例中各項活動都正常進行時用例的工作方式。
· 分支事件流——描述用例中某項活動的子活動各項工作都正常進行時用例的工作式。
· 異常事件流——描述用例的變更工作方式，以及出現異?；虬l生錯誤的情況下所執行的路徑。
圖書管理系統中每個用例的腳本描述如下：
1.系統登錄
用例名稱：系統登錄
參與者：圖書管理員 1.1前置條件 無
1.2后置條件
如果用例成功，參與者可以啟動系統，使用系統提供的功能。反之，系統的狀態不發生變化。
1.3基本事件流
當圖書管理員登錄系統時，用例啟動。
①系統提示用戶輸入用戶名和密碼。
②用戶輸入用戶名和密碼。
③系統驗證輸入的用戶名和密碼，若正確，則用戶登錄到系統中。
1.4異常事件流
如果用戶輸入無效的用戶名/密碼，則系統顯示錯誤信息。用戶可以選擇返回基本事件流的起始點，重新輸入正確的用戶名/密碼;或者取消登錄，用例結束。
2.圖書借閱
用例名稱：借閱圖書
參與者：讀者，圖書管理員 2.1前置條件
在這個用例開始之前，圖書管理員必須登錄到系統;否則，系統的狀態不發生變化。
2.2后置條件
如果這個用例成功實現，則在系統中創建并存儲借閱記錄。 2.3基本事件流
當讀者借閱圖書時，用例啟動。
①登錄系統。
②輸人圖書ID和讀者ID。
③檢索讀者ID。
④檢索圖書ID。
⑤根據時間算法確定圖書借出日期和歸還日期。
⑥圖書館將圖書借給讀者。
⑦創建借閱記錄。
⑧存儲借閱記錄。 2.4異常事件流
①如果讀者未注冊，則系統顯示提示信息，用例被終止。
②如果要借圖書不存在，系統顯示提示信息，用例被終止。
③如果要借圖書都已借出，則系統提示信息，用例被終止。 3.圖書歸還
用例名稱：圖書歸還
參與者：讀者，圖書管理員 3.1前置條件
在這個用例開始之前，圖書管理員必須登錄到系統;否則，系統的狀態不發生變化。
3.2后置條件
如果這個用例成功實現，則系統刪除借閱記錄;否則，系統的狀態不發生變化。 3.3基本事件流
當讀者歸還借閱的圖書時，用例被啟動。
①登錄系統。
②輸入圖書ID和讀者ID。 ③檢索圖書ID。
④檢索讀者ID。
⑤查詢圖書借閱記錄。 ⑥刪除借閱記錄。 3.4異常事件流
①如果歸還圖書不存在，則系統顯示提示信息，用例被終止。 ②如果借閱記錄不存在，則系統顯示提示信息，用例被終止。 4.讀者維護
用例名稱：讀者維護 ‘ 參與者：圖書管理員 ’ 4.1前置條件
在這個用例開始之前，圖書管理員必須登錄到系統;否則，系統的狀態不發生變化。 4.2后置條件
如果這個用例成功地實現，則系統添加、修改或檢索讀者信息;否則，系統的狀態不發生變化。
4.3基本事件流
當圖書管理員維護讀者信息時，用例被啟動。 ①登錄系統。
②如果選擇的活動是“添加讀者信息”，則執行分支事件流4.3.1：添加讀者信息。 ③如果選擇的活動是“修改讀者信息”，則執行分支事件流4.3.2：修改讀者信息。 ④如果選擇的活動是“檢索讀者信息”，則執行分支事件流4.3.3：檢索讀者信息。 4.3.1分支事件流
①提供讀者的信息，例如，讀者ID，讀者姓名、電話號碼等。 ②系統存儲讀者信息。 4.3.2分支事件流 ①輸入讀者ID。
②查詢并顯示讀者信息。 ③更新系統中讀者信息。 4.3.3分支事件流 ①輸入讀者ID。
②查詢并顯示讀者信息。 4.4異常事件流
①如果讀者已經存在，則系統顯示提示信息，用例被終止。 ②如果查詢不到讀者，則系統顯示提示信息，用例被終止。 5.圖書維護
用例名稱：圖書維護 參與者：圖書管理員 5.1前置條件
在這個用例開始之前，圖書管理員必須登錄到系統;否則，系統的狀態不發生變化。 5.2后置條件
如果這個用例成功實現，則系統添加、修改或檢索圖書信息;否則，系統的狀態不發生變化。
5.3基本事件流
當圖書管理員維護圖書信息時，用例被啟動。 ①登錄系統。
②如果選擇的活動是“添加圖書信息”，則執行分支事件流5.3.1：添加圖書信息。 ③如果選擇的活動是“修改圖書信息”，則執行分支事件流5.3.2：修改圖書信息。 ④如果選擇的活動是“檢索圖書信息”，則執行分支事件流5.3.3：檢索圖書信息。 5.3.1分支事件流
①提供圖書的信息，例如，圖書ID，圖書名稱、編著者、出版社、價格、出版年份籌 ②系統存儲圖書信息。 5.3.2分支事件流 ①輸人圖書ID。
②查詢并顯示圖書信息。 ⑨更新系統中圖書信息。 5.3.3分支事件流 ①輸入圖書ID。
②查詢并顯示圖書信息。 5.4異常事件流
①如果該圖書已經存在，則系統顯示提示信息，用例被終止。 ②如果查詢不到該圖書，則系統顯示提示信息，用例被終止。
系統總體功能結構
根據用例圖定義分析包以及分析包(子系統)之間的關系。
圖書管理系統分析包詳細結構
定義類、用例實現(序列圖)、類關系圖 (1) 系統登錄
類圖：
系統登錄分析類圖
用例實現：
登錄系統成功順序圖
登錄系統失敗順序圖
(2) 登錄圖書信息
類圖：
登錄圖書信息分析類圖
用例實現：
登錄圖書信息順序圖
(3) 修改圖書信息
類圖：
修改圖書信息分析類圖
用例實現：
修改圖書信息順序圖
(4) 檢索圖書信息
類圖:
檢索圖書信息分析類圖
用例實現：
檢索圖書信息順序圖
(5) 借閱圖書 類圖：
借閱圖書分析類圖
用例實現：
借閱圖書順序圖
(6) 歸還圖書
類圖：
歸還圖書分析類圖
用例實現：
歸還圖書順序圖
(7) 借出圖書一覽表
類圖：
借出圖書一覽表分析類圖
用例實現：
借出圖書一覽表順序圖
(8) 類關系圖
系統實體類(業務類)之間的關系
(9) 類的具體定義
1.圖書表類
編號：A—l一0l
類名：圖書表
職責：存放圖書館所能處理的所有圖書的基本信息
屬性：圖書代號，圖書名稱，編著者，ISBN代碼，出版社代碼，出版年份，頁數，價格，購入日期，過期日期，書架代碼，備注
說明：該類存放所有圖書類的公用信息，它是“圖書借閱表”的父類。圖書也有身份，可以通過不同的ISBN相區別。在圖書管理系統中，圖書也有相關的行為，圖書因為使用期限等可以被銷毀，所以圖書表也是系統中的一個對象。
2.登錄圖書界面類
編號：A一1—02
類名：登錄圖書界面
職責：提供輸入所有圖書信息的界面
屬性：圖書代號，圖書名稱，編著者，ISBN代碼，出版社代碼，出版年份，頁數，價格，購入日期，過期日期，書架代碼，備注
說明：該類的所有屬性是非持久性的，但它為用戶保存永久性的圖書屬性提供了一個臨時的輸入接口。
3.登錄圖書信息控制類
編號：A—l—03
類名：登錄圖書信息控制類
職責：實現登錄圖書界面類與圖書表類所提供信息的交互。
屬性：圖書代號，圖書名稱，編著者，ISBN代碼，出版社代碼，出版年份，頁數，價 格，購人日期，過期日期，書架代碼，備注
說明：該類的所有屬性是非持久性的，但它為用戶保存永久性的圖書屬性提供了一 個臨時的輸人接口。
4.出版社表類
編號：B—l—01
類名：出版社表
職責：存放圖書表所使用的所有圖書的出版單位
屬性：出版社代碼，出版社名稱
說明：該類與出版社表之間存在著單向關聯的關系。
5.讀者表類
編號：C一1一Ol
類名：讀者表
職責：存放圖書館的所有讀者的基本信息
屬性：讀者代碼，讀者名，聯絡電話
說明：該類類描述了物理借閱者的信息，代表了系統中存儲的物理借閱者的信息， 即物理借閱者在系統中的賬戶。同時，讀者表又是圖書借閱表的組成成分之一。
6.圖書借閱表類
編號：D—l—01
類名：圖書借閱表
職責：存放圖書館所能處理的所有圖書的基本信息
屬性：圖書代號，讀者代號，借書日期，還書日期， 說明：該類描述了從圖書館借閱圖書的借閱記錄。一個該類的對象對應一個借閱者和一本圖書。該類的對象的存在表示借閱者借閱了借閱記錄中記錄的物理圖書。當圖書被歸還時，要刪除借閱記錄(對象)。
形成系統分析規約(注意規約可能會有活動圖、狀態圖等)
3. 系統設計
設計模型的主要工作： 1).軟件平臺設計
軟件平臺是系統開發和運行的環境。圖書管理系統的開發和運行環境如下：
· 操作系統——操作系統是計算機系統中最重要的系統軟件。圖書管理系統可以運行在Windows 95/98/2000/NT/Windows XP等桌面操作系統上。
· 支撐軟件——支撐軟件是協助人們開發和維護軟件的工具和環境軟件。數據庫系統、集成開發環境等都屬于支撐型軟件，例如，Delphi、Oracle、Java等。圖書管理系統使用的DBMS是Access 2003，數據庫中間件是JDBC。
· CASE平臺——采用CASE開發環境可保證系統開發質量，提高開發效率，保證文檔的一致性。圖書管理系統的分析、設計j實現和部署模型是在Rose 2003建模環境下創建的，清晰地表達了在不同的開發階段的系統模型。 2).結構設計
結構設計是把軟件分解成為多個子系統，并確定出由各子系統及其接口構成的軟件結構。子系統是對軟件分解的一種中間形式，也是組織和描述軟件的一種方法。由多個子系統構成系統軟件，每一個子系統又包括多個用例設計、設計類和接口。結構設計具體要做的工作是將系統劃分成相對獨立、功能相對完整的子系統(包)，將系統模型中的元素劃分到不同的包中，說明在什么地方定義包，各個包之間的依賴性和主要通信機制。從而得到盡可能簡單和清晰的結構，各部分之間的依賴盡可能的少，并盡量減少雙向的依賴關系。 3).詳細設計與界面設計
詳細設計是對軟件結構中確定出的各個子系統內部的設計，需要分析和確定每一個子系統中的用例設計、設計類和接口。詳細設計還要描述每個類的細節，并用動態模型描述類的實例在具體環境中的行為。
界面設計是對人和外部系統與系統之間交互界面的設計，包括輸入界面、輸出界面和輸入/輸出界面的設計。另外，界面設計還涉及到人機交互方式、人機交互流程、輸入輸出設備和媒體等內容。 4).數據庫設計
數據庫是系統存儲和管理數據的主要技術手段，數據庫設計的任務是根據給定的系統應用需求和系統環境，設計出合理的數據庫結構。數據庫設計可分為概念設計、邏輯設計和物理設計3個階段。用UML進行數據庫設計的主要思想，是利用UML的擴展機制定義一些版型，用于表示與數據庫相關的一些概念。Rose 2003提供了對數據庫設計的支持，所設計的模型可以直接生成具體數據庫中的表、觸發器、存儲過程等。
系統結構設計
系統框架視圖
· 用戶界面包(User Interface Package)——用于描述整個用戶界面使用的類，這些類提供的操作允許用戶瀏覽系統中的數據，允許用戶輸入新數據。用戶界面類基于Java AWT包設計，AWT包是Java語言中用于編寫用戶界面應用程序的一個標準庫。用戶界面包與業務模型包相互協作，調用業務模型包中類實例的方法對圖書信息進行檢索和插入操作。
。 業務模型包(Business Model Package)——包含分析階段主要的類(借閱圖書類、歸還圖書類、圖書類、讀者類、出版社類)。在設計階段將進一步細化這些類，從而完整地定義它們的操作，并為它們增加永久性存儲支持。業務模型包與數據庫包相互協作，訪問數據庫中的數據。 · 數據庫包(Database Package)——為業務模型包中的類提供數據存取服務，以便這些類能夠實現數據的永久性存儲功能。
。 組件包(Utility Package)——包含一些可以被系統中其他包所使用的服務。
界面設計
詳細設計
圖書信息管理詳細設計：
1.設計類圖
“圖書信息管理’’是一個用例，在“圖書信息管理”用例所提取的3個概念類的基礎上，可以確定該用例有3個設計類：登錄圖書信息(LoginBook)、修改圖書信息(UpdateBook)、檢索圖書信息(SelectRook)。如圖13.2所示為“圖書信息管理”用例的設計類圖。
“圖書信息管理”用例設計類圖
·
BpFrame類——屬于用戶界面包，定義系統檢索與修改界面的框架。
·
BpSelectFrame類——屬于用戶界面包，繼承BpFrame類，定義檢索界面框架。
·
BpUpdateFrame類——屬于用戶界面包，繼承BpSelectFrame類，定義系統修改界面框架。
·
SelectBook類——屬于用戶界面包，繼承BpSelectFrame類，與DbChoice類相關聯，顯示圖書信息檢索界面。
·
LoginBook類——屬于業務模型包，繼承BpUpdateFrame類，與DbChoice類相關聯,實現圖書信息登錄功能。
·
UpdateBook類——屬于業務模型包，繼承BpUpdateFrame類，與DbChoice類相關聯，實現圖書信息修改功能。
·
DbChoice類——屬于組件包，定義了用于數據庫操作的實例變量和實例方法。
2.順序圖
為實現用例的功能，每個用例要實現的功能要通過用例中各個類的對象的操作的相互協作完成，這就要在順序圖或協作圖中反映各個對象之間的消息調用過程。如圖13.3所示為添加的圖書ID不重復的情況下“登錄圖書信息”用例的順序圖。
“登錄圖書信息”順序圖
3.屬性和方法設計
用例設計中識別出了大量的設計類，接下來要詳細地設計所識別出來的每一個設計類，即設計類的屬性和方法。屬性設計應該注意的問題是：一要補充屬性分析時沒有考慮到的屬性，確定屬性的全部內容，其中包括屬性名、可視性、范圍、類型、初始值;二要盡量采用系統采用的程序設計語言的語法規范描述屬性。
方法設計包括數據結構設計、算法設計和流程設計。方法設計要注意的是：一要立足于所采用的程序設計語言;二所選用的程序設計語言應該能夠提供豐富的數據結構;三要根據所實現的功能確定算法設計;四是可以用程序流程圖或活動圖來描述流程設計的結果。
如圖所示為添加了屬性和方法“圖書信息管理”用例的設計類圖。
添加屬性和方法后的“圖書信息管理”類圖
LoginBook類的屬性和方法設計如下：
·
sql屬性——定義執行插人操作的SQL命令字符串。
·
chpublish_id屬性——定義出版社ID。
·
LoginBook()方法——類的構造方法。①調用DbChoice類的對象實例，以實現加載JDBC驅動程序，創建數據庫連接等功能;②提供添加圖書信息界面。
·
cheekInsea()方法——①檢查各輸入項的輸人格式是否正確;②檢查圖書ID是否重復。
·
makelnsertStmt()方法——定義執行插人操作的SQL命令字符串。
·
afterlnsert()方法——清空登錄圖書界面的各輸入項。
SelectBook類的屬性和方法設計如下：
·
sql屬性——定義執行插入操作的SQL命令字符串。
·
chpublish_id屬性——定義出版社ID。
·
SelectBook()方法——類的構造方法。①調用DbChoice類的對象實例，以實現加載JDBC驅動程序，創建數據庫連接等功能;②提供檢索圖書界面。
·
checkSelect()方法——檢查是否輸入要檢索的圖書ID。
·
makeSelectStmt()方法——定義執行檢索操作的SQL命令字符串。
·
setSelectedData()方法——顯示檢索圖書的結果。
·
clear()方法——清空圖書檢索界面各檢索項。
UpdateBook類的屬性和方法設計如下：
·
sql屬性——定義執行插入操作的SQL命令字符串。
·
chpublish_id屬性——定義出版社ID。
·
UpdateBook()方法——類的構造方法。①調用DbChoice類的對象實例，以實現加載JDBC驅動程序，創建數據庫連接等功能;②提供檢索圖書界面;③提供修改圖書功能。
·
checkSelect()方法——檢查是否輸人要檢索的圖書ID。
·
makeSelectStmt()方法——定義執行檢索操作的SQL命令字符串。
·
setSelectedData()方法——顯示檢索圖書的結果。
·
clear()方法——清空圖書修改界面各修改項。
·
checkUpdate()方法——檢查各修改項的修改格式是否正確。
·
makeUpdateStmt()方法——定義執行修改操作的SQL命令字符串。
讀者信息管理詳細設計： 1.設計類圖
“讀者信息管理”是一個用例，在“讀者信息管理”用例確定了3個概念類：添加讀者信息、修改讀者信息、檢索讀者信息。但是，該用例的功能相對比較簡單?？梢杂?個設計類Borrow實現這3個概念類的功能。如圖所示為“讀者信息管理”用例的設計類圖。
圖13.5 “讀者信息管理”用例設計類圖
· Borow類——屬于業務模型包，繼承BpupdateFrame類，實現讀者信息添加修改和檢索功能。
2.順序圖
如圖13.6所示為添加的讀者ID不重復的情況下“添加讀者信息”用例的順序圖。
“添加讀者信息”順序圖
通過分析如圖所示的順序圖，可以得到下圖所示為“讀者信息管理”用例的設計類圖。
圖優化后的“讀者信息管理”用例設計類圖
3.屬性和方法設計
如下圖所示為添加了屬性和方法“讀者信息管理”用例的設計類圖。
添加屬性和方法后的“讀者信息管理”類圖
Borrow類的屬性和方法設計如下：
· sql屬性——定義執行插入操作的SQL命令字符串。
· Borrow()方法——類的構造方法。①調用DbChoice類的對象實例，以實現加載JDBC驅動程序，創建數據庫連接等功能;②提供添加、修改和檢索讀者信
息界面。
· checkSelect()方法——檢查是否輸入要檢索的讀者ID。
· makeSeleetStmt()方法——定義執行檢索操作的SQL命令字符串。
· setSelectedData()方法——顯示檢索讀者的結果。
· ehecklnsert()方法——檢查是否可執行插入操作。
· makeInsertStmt()方法——定義執行插入操作的SQL命令字符串。
· afterlnsert()方法——清空各輸入項。
· checkUpdate()方法——檢查是否可執行修改操作。
· makeUpdateStmt()方法——定義執行修改操作的SQL命令字符串。
· checkData()方法——檢查各輸入項的輸人格式是否正確。
· clear()方法——清空各文本框。
出版社信息管理詳細設計： 1.設計類圖
“出版社信息管理”是一個用例，可以用1個設計類Publish實現添加出版社信息、修改出版社信息、檢索出版社信息3個概念類。如圖13.9所示為“出版社信息管理”用例的設計類圖。
圖13.9 “出版社信息管理”用例設計類圖
· Publish類——屬于業務模型包，繼承BpUpdateFrame類，實現出版社信息添加、修改和檢索功能。
2.順序圖
如圖13.10所示為添加的出版社ID不重復情況下“添加出版社信息”用例的順序圖。
圖13.10 “添加出版社信息”順序圖
3.屬性和方法設計
如圖13.1l所示為添加了屬性和方法“出版社信息管理”用例的設計類圖。
圖13.11 添加屬性和方法后的“出版社信息管理”類圖
Publish類的屬性和方法設計如下：
· sql屬性——定義執行插入操作的SQL命令字符串。
· Publish()方法——類的構造方法。①調用DbChoice類的對象實例，以實現加載JDBC驅動程序，創建數據庫連接等功能;②提供添加、修改和檢索出版社信息界面。
· checkSelect()方法——檢查是否輸入要檢索的出版社ID。
· makeSelectStmt()方法——定義執行檢索操作的SQL命令字符串。 · setSelectedData()方法——顯示檢索出版社的結果。 · checklnsert()方法——檢查是否可執行插入操作。
· makeInsertStmt()方法——定義執行插入操作的SQL命令字符串。 · afterInsert()方法——清空各輸人項。
· checkUpdate()方法——檢查是否可執行修改操作。
· makeUpdateStmt()方法——定義執行修改操作的SQL命令字符串。 · checkData()方法——檢查各輸入項的輸人格式是否正確。 · clear()方法——清空各文本框。
圖書借還信息管理詳細設計： 1.設計類圖
“圖書借還信息管理”是一個用例，在“圖書信息管理”用例所提取的4個概念類的基礎上，可以確定該用例有4個設計類：借閱圖書( BorrowBook)、歸還圖書(RetumBook)、借出圖書一覽表(BorrowBookList)和未按期歸還圖書一覽表(OverdueList)。如圖所示為“圖書借還信息管理”用例的設計類圖。
圖“圖書借還信息管理”用例設計類圖
· BorrowBook類——屬于業務模型包，繼承BpUpdateFrame類，與DbChoice類相關聯，實現圖書借閱功能。
· ReturnBook類——屬于業務模型包，繼承BpUpdateFrame類，與DbChoice類相關聯，實現圖書歸還功能。
· BorrowBookList類——屬于業務模型包，繼承BpSelectFrame類，與DbChoice類相關聯，顯示借出圖書清單一覽表。
· OverdueList類——屬于業務模型包，繼承BpSelectFrame類，與DbChoice類相關聯，顯示未按期歸還圖書與讀者清單一覽表。
2.順序圖
如圖所示為讀者ID與圖書ID都存在情況下的“借閱圖書”用例的順序圖。
“登錄圖書信息”順序圖
3.屬性和方法設計
如圖所示為添加了屬性和方法“圖書借還信息管理”用例的設計類圖。
添加屬性和方法后的“圖書借還信息管理”類圖
BorrowBook類的屬性和方法設計如下：
· sql屬性——定義執行插入操作的SQL命令字符串。
· BorrowBook()方法——類的構造方法。①調用DbChoice類的對象實例，以實現加載JDBC驅動程序，創建數據庫連接等功能;②提供添加圖書信息界面。 · checklnsert()方法——①檢查各輸入項的輸入格式是否正確;②檢查借閱圖書ID是否存在。
· makeInsertStmt()方法——定義執行插入操作的SQL命令字符串。
· afterInsert()方法——清空借閱圖書界面的各輸入項。
· checkSelect()方法——檢查是否輸入讀者ID和圖書ID。
· makeSelectStmt()方法——顯示檢索結果。
· checkDelete()方法——檢查是否可執行刪除操作。
· makeDeleteStmt()方法——定義執行刪除操作的SQL命令字符串。
· afterDelete()方法——清空刪除操作后的各輸入項。
· clear()方法——清空所有的文本框。 ReturnBook類的屬性和方法設計如下：
· sql屬性——定義執行插人操作的SQL命令字符串。
· RetumBook()方法——類的構造方法。①調用DbChoice類的對象實例，以實現加載JDBC驅動程序，創建數據庫連接等功能;②提供圖書歸還界面。
· checkUpdate()方法——檢查各修改項的修改格式是否正確。
· makeUpdateStmt()方法——定義執行修改操作的SQL命令字符串。 · afterUpdate()方法——清空所有的文本框。 BorrowBookList類的屬性和方法設計如下：
· sql屬性——定義執行插入操作的SQL命令字符串。
· BorrowBookList()方法——類的構造方法。①調用DbChoice類的對象實例，以實現加載JDBC驅動程序，創建數據庫連接等功能;②提供實現“借出圖書一覽表”功能的界面。
· makeSelectStmt()方法——定義執行檢索操作的SQL命令字符串。
· setSelectedData()方法——顯示檢索結果。 OverdueList類的屬性和方法設計如下：
· sql屬性——定義執行插入操作的SQL命令字符串。
· xOverdueList()方法——類的構造方法。①調用DbChoice類的對象實例，以實現加載JDBC驅動程序，創建數據庫連接等功能;②提供實現“未按期歸還圖書一覽表”功能的界面。
· makeSelectStmt()方法——定義執行檢索操作的SQL命令字符串。
· setSelectedData()方法——顯示檢索結果。
組件包設計：
組件包包含被所有其他包使用的通用組件，圖書管理系統的組件包由Const、DbChoice、BpUtil三個類組成，這三個類定義了系統所有其他類所使用的公共常量與公共方法。另外，IconCanvas(加載系統界面所使用的圖標)、MsgDialog(信息顯示對話框)、SQLExceptionDialog(顯示數據庫異常信息對話框)3個類也為系統所有其他類所公共使用。在此與組件包中的類一起進行說明。 1.Const類
Const類定義了系統所使用的公共名稱等常量，其類圖如圖所示。
Const類的類圖
2.BpUtil類
BpUtil類定義了系統使用的公共方法，其類圖如圖所示。
BpUtil類的類圖
BpUtil類的方法設計如下：
· repeateString()方法——返回指定個數的字符串對象。
· varchar2text()方法——返回按照指定長度調整的字符串對象。
· setComp()方法——在組件上按照CridBagConstraints布局配置Panel。 · checkWaming()方法——檢查數據庫連接操作是否出現異常。 · isNumeric()方法——驗證字符串能否轉換為數值。
· getToday()方法——以YYYY/MM/DD的格式返回今日的日期。
· getToday()方法——返回以今日為基點的指定為YYYY/MM/DD格式的日期。 · isYMD()方法——驗證能否識別YYYY/MM/DD格式的字符串。 · GB2312Unicode()方法——GB2312轉換為Unicode。 · UnicodeGB2312()方法——Unicode轉換為GB2312。
· getRowCount()方法——求數據表中滿足條件的記錄數。
· convYMD()方法——Java.util.Date類型數據轉換為YYYY/MM/DD格式。
3.DbChoice類
DbChoice類定義了用于數據庫操作的實例變量與實例方法，其類圖如圖所 示。
DbChoice類的類圖
DbChoice類的屬性和方法設計如下：
· con屬性——定義用于數據庫連接的實例變量。 · query屬性——定義用于SELECT語句的實例變量。 · displayCol屬性——定義用于檢索結果的列數。
· valueCol屬性——定義方法getSelectedVal()返回值的列數。
· vItem屬性——定義用于保存方法getSelectedVal()返回值的Vector · DbChoice()方法——構造方法，用于初始化實例變量。 · setQueryData()方法——執行檢索操作。 · getSelectedVal()方法——返回檢索結果。 · setValueCol()方法——設置列的值。 · getValueCol()方法——返回列的值。
· setDisplayCol()方法——設置顯示列的值。 · getDisplayCol()方法——返回顯示列的值。
· setDisplayhem()方法——設置顯示項的列的值。 4.IconCanvas類
IconCanvas類用于完成加載系統界面所使用圖標的功能，其類圖如圖所示。
IconCanvas類的類圖
IconCanvas類的方法設計如下：
· IconCanvas()方法——構造方法，用于完成加載圖像文件的功能。 · paint()方法——用于完成顯示圖像文件的功能。 5.MsgDialog類
MsgDialog類用于完成顯示系統界面所使用的信息對話框功能，其類圖如圖13.19所 示。
MsgDialog類的類圖
MsgDialog類的屬性和方法設計如下：
· MsgDialog()方法——構造方法，用于生成信息顯示區域，定義信息對話框的
標題、布局管理器等功能。
· actionPerformed()方法——用于處理發生的事件。
6.SQLExceptionDialog類
當發生數據庫異常時，SQLExceptionDialog類定義了用于顯示數據庫異常信息對話框，其類圖如圖所示。
SQLExceptionDialog類的類圖
SQLExceptionDialog類的屬性和方法設計如下：
· SQLExceptionDialog()方法——構造方法，用于定義發生的SQL異常。 · actionPerformed()方法——用于處理發生的事件。 · setMessage()、方法——用于顯示發生的異常信息。 系統管理詳細設計：
系統管理由Bookplate和LoginDialog兩個類組成，Bookplate類用于顯示系統主功能界面，LoginDialog類用于顯示用戶登錄對話框界面。Bookplate類與LoginDialog類之間有單向關聯關系，即Bookplate類中定義的實例變量dialog可以調用LoginDialog類的構造函數，以實現系統登錄界面的顯示，描述兩者之間關系的類圖如圖所示。
“系統管理”用例設計類圖
Bookplate類的方法設計如下：
· main()方法——系統執行的入口點，用于顯示系統主功能界面。
· Bookplate()——構造方法，用于設置系統框架(Frame)、標題、菜單、按鈕布局、標簽等系統組件。
· aetionPerformed()——當用鼠標左鍵點擊各功能按鈕時，分別調用各個子功能系統，同時實現生成、顯示和隱藏對應的框架的功能。 LoginDialog類的方法設計如下：
· LoginDialog()方法——構造方法，用于設置用戶登錄對話框界面的標題、顯示信息區域、設置標簽和文本域、生成按鈕等功能。
· actionPerformed()——當用鼠標左鍵點擊功能按鈕時，處理所觸發的事件。 · getStatus()——返回按鈕的狀態值。 · getUserID()——返回用戶ID。 · getPassword()——返回用戶口令。
數據庫設計(表略)
完成設計規約