UML對基于BS模式的圖書管理系統(tǒng)的分析與設(shè)計

1、uml對基于b/s模式的圖書管理系統(tǒng)的分析與設(shè)計 摘要：對基于b/s模式下的圖書管理系統(tǒng)進行分析，運用uml的靜態(tài)和動態(tài)模型圖，對系統(tǒng)的分析結(jié)果進行可視化建模，并對系統(tǒng)模型圖進行概括性論證。 標(biāo)簽：bs圖書管理系統(tǒng)uml模型圖 1 前言使用計算機軟件對圖書進行管理，是計算機應(yīng)用的一部分。以實現(xiàn)圖書檢索迅速、可靠性高、存儲量大、壽命長、成本低等特點，能極大程度地提高圖書管理的效率，也是圖書管理信息化、正規(guī)化管理的必然趨勢。針對用戶對圖書資源進行有效利用和管理的功能需求，用建模技術(shù)對圖書管理資源采用面向?qū)ο蟮拿枋龇绞?，在具體系統(tǒng)功能實現(xiàn)之前，建立起系統(tǒng)模型是很必要的，這里采用具有可視化、能夠柔性實

2、現(xiàn)分析、設(shè)計和開發(fā)系統(tǒng)的統(tǒng)一建模語言實現(xiàn)系統(tǒng)模型構(gòu)建。同時，結(jié)合最流行的基于瀏覽器的數(shù)據(jù)管理模式，建議采用基于組件技術(shù)的b/s(brower/server)系統(tǒng)結(jié)構(gòu)。2 圖書管理系統(tǒng)用例分析要開發(fā)一個軟件系統(tǒng)，首先要對軟件系統(tǒng)的需求進行分析，要做的工作是深入描述目標(biāo)系統(tǒng)的功能和性能，確定軟件設(shè)計的限制和軟件同其他系統(tǒng)元素間的接口細(xì)節(jié)，定義軟件的其他有效性需求。運用uml(unified modelling language：統(tǒng)一建模語言)的目的可以捕捉系統(tǒng)的功能需求、分析，提取所開發(fā)系統(tǒng)領(lǐng)域的類以及描述它們之間合作概況，在完成系統(tǒng)的ooa(object-oriented analysis：面向

3、對象分析)在此基礎(chǔ)上，對系統(tǒng)進行ood(object-oriented design：面向?qū)ο笤O(shè)計)。uml的用例圖較詳細(xì)和確切地描述了用戶的功能需求，使系統(tǒng)責(zé)任明確到位，奠定uml對系統(tǒng)建模的基礎(chǔ)，這樣，其他模型圖的構(gòu)造和發(fā)展依賴于用例圖中所描述的內(nèi)容，直至系統(tǒng)能夠?qū)崿F(xiàn)用例圖中描述的功能。采用用例圖描述的圖書管理主要包括三類用戶：讀者、圖書管理員、系統(tǒng)管理員。其中，讀者是多個，圖書管理員是幾個，系統(tǒng)管理員是一個。對于系統(tǒng)，讀者可以查詢自己的借閱情況、分門別類的查詢圖書和在規(guī)定期限內(nèi)續(xù)借不能超過一次操作的情況下進行自行登錄續(xù)借書等。圖書管理員主要是日常操作以下幾個工作環(huán)節(jié)：圖書訂購、新書驗證、

4、書目錄入、圖書登記、讀者信息管理、借閱書登記、圖書信息注銷和讀者信息注銷等，而系統(tǒng)管理員統(tǒng)籌管理圖書的系統(tǒng)相關(guān)事宜，比如權(quán)限維護、日志維護、增刪用戶和管理系統(tǒng)后臺數(shù)據(jù)等。用例間關(guān)系、用戶與用例關(guān)系及用例之間的關(guān)系如圖1所示。圖1：圖書管理用例分析圖3 系統(tǒng)靜態(tài)建模 在用例分析基礎(chǔ)上，根據(jù)需求可建立起系統(tǒng)的靜態(tài)數(shù)據(jù)模型，即建立系統(tǒng)類圖，以及相關(guān)的關(guān)系和方法。在面向?qū)ο蠓治鲋?，一般只考慮與問題描述域和系統(tǒng)功能相關(guān)的對象。在對系統(tǒng)進行分析時，這里把系統(tǒng)的類對象抽象為圖書管理、圖書流通兩方面。針到這兩部分可以分化為以下相關(guān)類：圖書類(lib_book)、圖目類(lib_category)、訂書類(li

5、b_order)、報表類(lib_form)、讀者類(lib_reader) 、流通書類(lib_cirbook)、部門類(lib_department)、出版社類(lib_publish)等。這些類之間我們可以用樸素的關(guān)聯(lián)關(guān)系作一簡要表達。如圖2為圖書管理靜態(tài)類圖，在圖中每條有直接多重性關(guān)聯(lián)的線上已標(biāo)示出多重性，這為以后編程中提供了更好的關(guān)聯(lián)參考價值，并為類在整個開發(fā)中的統(tǒng)一性奠定基礎(chǔ)。圖2：圖書管理靜態(tài)類圖4 系統(tǒng)動態(tài)建模在考察了系統(tǒng)某一時刻的對象及對象之間樸素關(guān)系的靜態(tài)結(jié)構(gòu)后，下面要關(guān)注的是在任何時刻對象及其關(guān)系改變的情況，這些情況可以用uml的動態(tài)模型進行形象化描述，可以借助uml中的

6、狀態(tài)圖來描述，在狀態(tài)圖中，把每時刻的系統(tǒng)狀態(tài)抽象成狀態(tài)和事件，然后組成一個網(wǎng)絡(luò)，側(cè)重于描述每一類對象的動態(tài)行為。它是對某一時刻中屬性特征的概括，并且每種狀態(tài)間存在著遷移，遷移則表示了這類對象在何時對系統(tǒng)內(nèi)外發(fā)生的哪些事件作出何種響應(yīng)。狀態(tài)圖設(shè)計一般是在對操作序列的順序圖細(xì)化的基礎(chǔ)上表達。這里以借書的狀態(tài)圖為例，把上面的面向?qū)ο蠓治雠c設(shè)計、并對系統(tǒng)靜態(tài)結(jié)構(gòu)的把握后，建立起系統(tǒng)動態(tài)數(shù)據(jù)的邏輯視圖，如圖3所示，以此為點，可以建立起整個系統(tǒng)的狀態(tài)流程分析，這里不再詳述。圖3：借書狀態(tài)圖5 基于b/s模式的系統(tǒng)結(jié)構(gòu)在完成了系統(tǒng)的用例分析、模型化靜態(tài)數(shù)據(jù)描述以及局部動態(tài)數(shù)據(jù)的狀態(tài)控制后，基本上掌握了系統(tǒng)在

7、進行邏輯數(shù)據(jù)處理的流程。而最終要成為一個系統(tǒng)管理體系，這就需要從總體上把握系統(tǒng)數(shù)據(jù)的獲取、處理及存儲。在基于b/s模式的軟件開發(fā)中，其體系結(jié)構(gòu)一般分為采用組件技術(shù)的三層，瀏覽器層、web邏輯處理層和數(shù)據(jù)庫管理層。這里系統(tǒng)的開發(fā)建議采用基于java的面向?qū)ο箝_發(fā)技術(shù)，將設(shè)計的邏輯組件、數(shù)據(jù)訪問組件運行在javabean和com+組合的運行環(huán)境，底層數(shù)據(jù)處理則采用數(shù)據(jù)管理安全性穩(wěn)定性很強的oracle 9i。不僅增強了系統(tǒng)訪問數(shù)據(jù)的安全性，同時也可以處理后臺數(shù)據(jù)庫的并發(fā)、遠(yuǎn)程、跨平臺訪問。在數(shù)據(jù)庫管理層也是通過javabean對象組件完成對后臺數(shù)據(jù)庫服務(wù)的訪問，整個邏輯處理過程如圖4所示。6 總結(jié)

8、本文對圖書管理系統(tǒng)采用面向?qū)ο蟮姆治黾霸O(shè)計方法，對系統(tǒng)進行了可視化的需要分析與系統(tǒng)設(shè)計。整個過程中，采用了uml技術(shù)。并對系統(tǒng)采用了基于b/s模式的三層體系解決方案，借助于web瀏覽器，提供了更加快捷方便的圖書管理流程，節(jié)省了管理人員和讀者的大量時間，有利于信息處理效率的提高，大大減少了重復(fù)信息。同時，也簡化工作人員對圖書的管理及維護工作。另一方面，基于組件技術(shù)的系統(tǒng)結(jié)構(gòu)具有很好的可伸展性和可擴展性，提高了系統(tǒng)的柔性與自適應(yīng)性，有助于系統(tǒng)的二次開發(fā)。參考文獻 1 潘偉，基于uml實現(xiàn)圖書管理系統(tǒng)的建模設(shè)計j，圖書情報知識，no.103 feb，20052 張廣泉，劉艷，基于uml的圖書管理系統(tǒng)

9、體系結(jié)構(gòu)模型及實現(xiàn)j，重慶師范大學(xué)學(xué)報，vol.22 no.2 jun 20053 高志堅，運用uml建模機制構(gòu)建圖書管理系統(tǒng)j，平頂山學(xué)院學(xué)報，vol.14 no.2 mar.20054 柳翠寅，基于web的圖書管理系統(tǒng)j，成都教育學(xué)報，vol.9.no.1 jan，20055 劉治國，構(gòu)建基于b/s結(jié)構(gòu)的圖書管理系統(tǒng)j，信息技術(shù)，2005年第3期作者簡介王標(biāo)(1980-)，男(漢族)，山東人，助理館員夏小娜（1980-），女（漢族），山東人，碩士研究生，主要研究方向：管理信息系統(tǒng)、軟件工程用uml進行有效業(yè)務(wù)建模 摘要：大多數(shù)軟件開發(fā)實踐者都知道，uml在對真實世界的現(xiàn)象進行建模時非常優(yōu)秀

10、。這一特性可以有效幫助分析員和客戶進行溝通。本文介紹如何使用uml進行有效業(yè)務(wù)建模。 標(biāo)簽：umluml建模uml業(yè)務(wù)建模業(yè)務(wù)用例大多數(shù)軟件開發(fā)實踐者都知道，uml在對真實世界的現(xiàn)象進行建模時非常優(yōu)秀。這一特性可以有效幫助分析員和客戶進行溝通。一些希望使用業(yè)務(wù)建模的團隊常常有一些經(jīng)驗性的問題，例如：* 什么時候真正需要業(yè)務(wù)模型？什么時候用例模型獨立存在？* 我在進行精確的業(yè)務(wù)建模時我能用哪些uml圖形？我如何知道是否用順序圖或者交互圖。有例子嗎？* 業(yè)務(wù)模型如何涉及到其他模型（如領(lǐng)域模型，用例模型等等）呢？我如何有機地組織這些模型？很不幸，本文的焦點集中于應(yīng)用uml進行業(yè)務(wù)建模的問題，而很少把

11、業(yè)務(wù)建模和系統(tǒng)建模進行比較。這將使用戶和分析員對使用uml進行業(yè)務(wù)建模的感到灰心。本文主要通過一個例子講述它們的關(guān)系。這個例子主要用來改進某企業(yè)的流程，主要涉及到it部門、法律顧問、企業(yè)架構(gòu)師、項目經(jīng)理。業(yè)務(wù)用例模型概覽在這個簡單的例子中的第一步是完成業(yè)務(wù)用例模型概覽。如圖所示，有兩個業(yè)務(wù)主角和兩個業(yè)務(wù)用例。我們總結(jié)業(yè)務(wù)用例如下：* prepare tender: 準(zhǔn)備系統(tǒng)說明書的流程。* select vendor: 選擇賣方的流程。我們總結(jié)業(yè)務(wù)主角如下：* end user manager: 公司內(nèi)的需要自動控制系統(tǒng)的部門。* vendor manager: 賣方的管理者。在這個例子中，得

12、到一個新系統(tǒng)的核心業(yè)務(wù)目標(biāo)被精化為兩個子目標(biāo)：* 詳細(xì)說明想得到的系統(tǒng)。* 選擇并評估候選人。 業(yè)務(wù)用例規(guī)約這一部分，我們來看看如何描述業(yè)務(wù)用例，雖然rup中對業(yè)務(wù)用例規(guī)約有很詳細(xì)的模版，但我們主要把精力放在基本流和擴展流上。prepare tender的基本流：用例的目標(biāo)是確定招標(biāo)文件，同時可以將招標(biāo)文件發(fā)布給候選賣主。1. 指定用戶代表。2. 用戶代表準(zhǔn)備系統(tǒng)規(guī)約。3. it部門復(fù)審系統(tǒng)規(guī)約，并改進它，形成招標(biāo)文件。4. 用戶代表批準(zhǔn)招標(biāo)文件。擴展流：* 系統(tǒng)規(guī)約無效。當(dāng)it部門發(fā)現(xiàn)需求太含糊，最終用戶的管理者必須重新制作需求。那么這個用例從第二步從新開始，如果最終用戶管理者不想繼續(xù)，也可

13、以終止。* 系統(tǒng)已存在。如果it部門發(fā)現(xiàn)這個需要的系統(tǒng)和其它部門存在的系統(tǒng)很類似，it部門就提交給最終用戶管理者。如果最終用戶管理者希望繼續(xù)尋找新系統(tǒng)，他必須寫出該系統(tǒng)的特色，并重新提交該說明書，回到第二步，如果最終用戶管理者不想繼續(xù)，也可以終止。* 招標(biāo)文件和需求規(guī)約沖突。在第四步，最終用戶管理者發(fā)現(xiàn)招標(biāo)文件有問題，它將被拒絕，it部門必須重新做它，用例在第三步繼續(xù)。業(yè)務(wù)用例實現(xiàn)在這部分，我們從幾個方面去實現(xiàn)業(yè)務(wù)用例。* 以工作流為中心* 以流程自動化為中心* 以信息處理為中心焦點集中在工作流我們要精力集中在業(yè)務(wù)角色的職責(zé)上，如圖所示，prepare tender有三個業(yè)務(wù)角色：焦點集中在工

14、作流我們要精力集中在業(yè)務(wù)角色的職責(zé)上，如圖所示，prepare tender有三個業(yè)務(wù)角色：下面的順序圖描述了prepare tender的基本流。上圖中的消息可以映射到每個業(yè)務(wù)角色的職責(zé)（如下圖所示）。這個技術(shù)非常類似于用例分析。由此可見rup業(yè)務(wù)建模的技術(shù)是很強大的：相同的技術(shù)可用于業(yè)務(wù)建模和系統(tǒng)建模。焦點集中在流程自動化 現(xiàn)在我們準(zhǔn)備去探索業(yè)務(wù)主角和業(yè)務(wù)角色職責(zé)，明確什么時候使用業(yè)務(wù)系統(tǒng)以及如何使用業(yè)務(wù)系統(tǒng)。在我們的例子中，我們有兩個業(yè)務(wù)系統(tǒng)，如下圖所示。tms是準(zhǔn)備招標(biāo)和選擇賣主的系統(tǒng)。這是一個新系統(tǒng)。cms是跟蹤合同的系統(tǒng)，已存在。在rup中，業(yè)務(wù)對象建模的指導(dǎo)方針建議可以對“業(yè)務(wù)系統(tǒng)”定義一個新的泛型圖標(biāo)，在這篇文章中我們將使用“業(yè)務(wù)角色”圖標(biāo)來表示“業(yè)務(wù)系統(tǒng)”。將有一個新的圖標(biāo)在新的uml業(yè)務(wù)建模規(guī)范中。下面的順序圖描述了prepare tender基本流的實現(xiàn)，包含了需求的業(yè)務(wù)系統(tǒng)。上圖中的消息可以映射到業(yè)務(wù)角色的職責(zé)。如下圖所示：從上圖中可以得到系統(tǒng)用例，如下圖：焦點集中在信息處理現(xiàn)在讓我們看看業(yè)務(wù)用例在信息處理上的實現(xiàn)，這就是說，有多少業(yè)務(wù)實體。經(jīng)過分析，我們將得到四個業(yè)務(wù)實體，如下圖：