详细的图书馆管理系统UML图终极版.docx

详细的图书馆管理系统UML图终极版.docx

《详细的图书馆管理系统UML图终极版.docx》由会员分享，可在线阅读，更多相关《详细的图书馆管理系统UML图终极版.docx（16页珍藏版）》请在冰豆网上搜索。

详细的图书馆管理系统UML图终极版

ThelibrarymanagementsystemUMLdiagrams

1．需求（Requirements）

典型地，由系统最终用户的代表写出文本形式的需求规范文档。

对于该图书馆应用程序来说，需求规范文档应该类似于这样：

1.这是一个图书馆支持系统；

2.图书馆将图书和杂志借给借书者。

借书者已经预先注册，图书和杂志也预先注册；

3.图书馆负责新书的购买。

每一本图书都购进多本书。

当旧书超期或破旧不堪时，从图书馆中去掉。

4.图书管理员是图书馆的员工。

他们的工作就是和读者打交道并在软件系统的支持下工作。

5.借阅人可以预定当前没有的图书和杂志。

这样，当他所预定的图书和杂志归还回来或购进时，就通知预定人。

当预定了某书的借书者借阅了该书后，预定就取消。

或者通过显式的取消过程强行取消预定。

6.图书馆能够容易地建立、修改和删除标题、借书者、借阅信息和预定信息。

7.系统能够运行在所有流行的技术环境中，包括Unix,Windows和OS/2，并应有一个现代的图形用户界面（GUI）。

8.系统容易扩展新功能。

系统的第一版不必考虑预定的图书到达后通知预定人的功能，也不必检查借书过期的情况。

Typically,theenduser'srepresentativebysystemofregulatingwritetextdocumentdemand.Forthelibraryapplication,itshouldbesimilartothestandarddocumentdemandso:

1.Thisisalibrarysupportsystem;

2.ThelibrarywilllendbooksandmagazinesJieShuZhe.JieShuZhehasregisterinadvance,booksandmagazineswillregisterinadvance;

3.Newbookpurchaseforlibrary.Thebookismorethanbuyingeverybook.Whenoldbooksextendedorwornout,removingfromthelibrary.

4.Thelibrarianisthelibrarystaff.Theirjobistodealwiththereaderinsoftwaresupportsystemwork.

5.Borrowingpeoplecanbescheduledhavenocurrentofbooksandmagazines.So,whenhisbookofbooksandmagazinesreturnedbackorpurchase,confirmation.WhenbookedMouShuJieShuZheborrowingofthereservationiscancelledafter.Orbyexplicitcancelprocessforciblycancellationofreservation.

6.Thelibrarycaneasilyestablish,modifyanddeletetitle,JieShuZhe,borrowinginformationandbookinginformation.

7.Systemcanrunonallpopulartechnologyenvironment,includingUnix,WindowsandOS/2,andshouldhaveamoderngraphicaluserinterface（GUI）.

8.Thesystemiseasytoexpandnewfunctions.

Thefirsteditionofneednotconsiderbookingsystemofbooksafterconfirmationofarrive,don'tcheckfunctionofbooksexpired.

2．分析（Analysis）

系统分析的目的是捕获和描述所有的系统需求，并且建立一个模型来定义系统中主要的域类。

通过系统分析达到开发者和需求者的理解和沟通。

因此，分析一般都是分析员和用户协作的产物。

在这个阶段，程序开发者不应该考虑代码或程序的问题；它只是理解需求和实现系统的第一步。

2．1需求分析（RequirementsAnalysis）

分析的第一步是确定系统能够做什么？

谁来使用这个系统？

这些分别叫角色（actors）和用例（usecases）。

用例描述了系统提供什么样的功能。

通过阅读和分析文档，以及和潜在的用户讨论系统来分析用例。

图书馆的角色定为图书管理员和借书人。

图书管理员是软件系统的用户；而借书者则是来借阅或预定图书杂志的客户。

偶尔，图书管理员或图书馆的其他工作人员也可能是一个借书者。

借书者不直接和系统交互，借书人的功能由图书管理员代为执行。

Systemanalysispurposeistocaptureanddescribeallofthesystemrequirements,andtoestablishamodeltodefinethedomaininthesystemof.Throughsystematicanalysistodevelopersanddemandersunderstandingandcommunication.Thus,theanalysisaregenerallyanalystandusercollaborativeproduct.

Atthisstage,theprogram'sdevelopersshouldnotconsidercodeorprogramproblem;Itjustunderstanddemandandrealizesystemthatfirststep.

图书馆系统中的用例有：

1.        借书

2.        还书

3.        预定

4.        取消预定

5.        增加标题

6.        修改或删除标题

7.        增加书目

8.        删除书目

9.        增加借书者

10.     修改或删除借书者

由于一本书通常有多个备份，因此系统必须将书的标题和书目的概念区分开。

图书馆系统分析的结果写在UML用例图中，如图1所示。

每一个用例都附带有文本文档，描述用例和客户交互的细节。

文本是通过与客户讨论得到的。

用例“借书”描述如下：

1．如果借阅者没有预定：

确定标题

确定该标题下有效的书目

确定借书者

图书馆将书借出

登记一个新的借阅

2．如果借阅者有预定：

确定借书人

确定标题

确定该标题下有效的书目

图书馆将相应的书目借出

登记一个新的借阅

取消预定

除了定义系统的功能需求之外，在分析过程中用例用于检查是否有相应的域类已经被定义，然后他们可以被用在设计阶段，确保解决方案可以有效地处理系统功能。

可以在顺序图中可视化实现细节。

Thelibrarysystemofcasesare:

1.Borrowbooks

2.Alsobooks

3.Reservation

4.Cancellations

5.Addtitle

6.Reviseordeletetitle

7.Increasebibliography

8.Deletebibliography

9.IncreaseJieShuZhe

10.JieShuZhemodifiedordeleted

Duetoabookoftenhavemultiplebackup,thereforesystemmustwillbooktitleandbibliographyconceptseparate.

ThelibrarysystemanalysisresultswritteninUMLusecasediagram,asshowninfigure1below.Everycasesareclutteredwithtextdocuments,describecasesandcustomerinteractiondetails.Textisdiscussedwithcustomersget.Cases"borrow"descriptionasfollows:

1.Ifborrowednoreservation:

suretitle

surethistitlevalidunderthebibliography

sureJieShuZhe

librarywillbookout

registeranewlending

2.Ifborrowedabook:

determineBooks

suretitle

surethistitlevalidunderthebibliography

librarywillcorrespondingbibliographyout

registeranewlending

cancellationofreservation

Inadditiontodefiningofthefunctionalrequirementsofthesystemusedinanalyzingprocessoutside,usedtocheckwhethercorrespondingexampleofdomainclasseshavebeendefined,thentheycanbeusedinthedesignphase,ensuresolutioncaneffectivelyprocessingsystemfunction.Caninsequencediagramvisualizationimplementationdetails.

 图1：

角色和用例。

分析中的第一步就是指出系统能被用来做什么，谁将去使用它。

它们分别就是用例和角色。

所有的用例必须始于角色，而且有些用例也结束于角色。

角色是位于你所工作的系统外部的人或其他系统。

一台打印机或一个数据库都可能是一个角色。

本系统有两个角色：

借阅者和图书管理员。

通过与用户或客户的讨论，可以将每一个用例用文字进行说明。

2．2域分析（DomainAnalysis）

系统分析也详细地列出了域（系统中的关键类）。

为了导出一个域分析，可以阅读规范文档（specifications）和用例，查找哪一些概念应该被系统处理。

或者组织一个集体讨论，在用户及领域专家共同的参与下指出系统中必须处理的关键概念，以及它们之间的关系。

图书馆系统中的域类如下：

borrowerinformation（如此命名是为了与用例图中的角色borrower区分开来），title，booktitle,magazinetitle,item,reservation和loan。

这些类以及它们之间的关系记录在类图文档中，如图2所示。

域类定义为Businessobject版型，Businessobject版型是一个用户自定义的版型，指定该类的对象是关键域的一部分，并且应该在系统中持久存储。

其中有些类有UML状态图，用来显示这些类的对象可能具有的不同状态，以及触发他们的状态发生改变的事件。

该例子中有状态图的类是item和title类。

用例lenditem（借阅者没有预定的情况）的顺序图显示在图3中。

所有用例的顺序图都可从在线模型中查到。

betweenthemarerecordedinclassdiagramdocumentation,showninfigure2.Domainobjectclassdefinitionforafriend,afriendobjecteditionversiontotypeisauser-definedversionoftheclasstype,designatedpartoftheobjectisthekeydomain,andshouldinsystemlastingstorage.

SomeofthesetypesofUMLastatechart,usedtodisplaytheseobjectsofaclassmayhavedifferentcondition,andtriggertheirstatechangeofevents.Thisexamplehasastatechartclassisitemandtitleclasses.

Casesonthisitem（borrowedlendnoreservationsituation）sequencediagramshowninfigure3.Allcasessequencediagramcanbefoundfromonlinemodel.

图2：

域类结构。

域分析详细说明了系统中的关键类。

对每一个对象而言，如果它调用了其他对象的方法，那么在他们之间就用一条直线连结起来，以显示他们之间的关系。

每一个代表类的四边形被分成了三部分，最顶层包括类的名称，中间一层是类的属性，最底层是类的方法。

类之间的直线是关联，用来指出一个对象调用另一个对象的方法。

如果再仔细看，将会发现在Loan和Item之间的关联关系中靠近Loan的一端有“0..1”,这代表关联的重数。

重数“0..1表示Item可以感知0个到1个loan。

其他可能出现的重数还有：

“0..*”表示0或多；“1”表示就是1；“0”表示就是0，“1..*”表示1或多。

当对顺序图建模时，必须提供窗体和对话框作为人机交互的界面。

在本分析当中，只要知道借书、预定和还书需要窗体就可以了。

在此，详细的界面不必考虑。

为了把系统中的窗体类和域类分开，所有的窗体类组织在一起放在GUIPackage包中。

域类组织在一起放在BusinessPackage包中。

Whenthesequencediagrammodeling,mustprovidetheformanddialogboxasman-machineinterface.Inthisanalysis,justknowamongbooks,reservationandalsobookneeds.YoucanformInthis,neednotconsiderdetailedinterface.

Inordertoputthesystemoftheformandfield,alltheformofseparatesuchorganizationtogetherinGUIPackagebag.DomainclassorganizationtogetheronPackagebag.Afriend

图3：

Lenditem场景的顺序图。

场景是从头到尾实现一个用例的一次特定的过程。

场景总是始于角色，而角色是属于系统外部的。

场景描绘了从所有角色的观点出发，完成一次系统动作的完整过程。

UML在用顺序图来图示场景。

本用例图显示了在借阅者没有预定图书的情况下的Lend用例。

横在图的顶部的是参与交互的对象。

自上而下表示时间的流逝。

首先，图书管理员尝试去查找标题。

标有“LendingWindow”的是用户界面，在分析阶段作为一个粗略的对象。

横在顺序图中的每一个箭头都是一次方法的调用，箭头的首端是调用的对象，箭头的末端是被调用的对象。

3．设计（Design）

设计阶段对分析模型进行扩展并将模型进一步细化，并考虑技术细节和限制条件。

设计的目的是指定一个可行的解决方案，以便能很容易地转变成为编程代码。

设计可以分成两个阶段：

体系结构设计阶段（ArchitectureDesign）。

这是一个从较高层次的进行的设计，用来定义包（子系统），描述包之间的依赖性及通信机制。

很自然，目的是要设计一个清晰简单的体系结构，有很少的依赖性，而且尽可能避免双向依赖。

详细设计阶段（DetailedDesign）。

在此阶段，所有的类都详尽地进行描述，给编写代码的程序员一个清晰的规范说明。

UML中的动态模型用来说明类的对象如何在特定的情况下做出相应的表现。

3．1体系结构设计

一个良好的体系结构设计是一个可扩展的和可改变的系统的基础。

包可能关注特定的功能领域或关注特定的技术领域。

把应用程序逻辑（域类）和技术逻辑分开是至关重要的，这样不管哪一部分的改变都不会影响其他的部分。

本案例的包或叫子系统如下：

User-InterfacePackage包。

该包中的类基于JavaAWT包，javaAWT是一个用来书写用户界面应用程序的Java的标准库。

该包和Business-objectsPackage包协作。

Business-objectsPackage包包含那些实际存储数据的类。

UI包调用Business对象的操作，对他们进行取出或插入数据操作。

Business-objectPackage。

该包包括域类，这些域类（如borrowerinformation，title，item，loan等）来自于分析模型。

设计阶段完整地定义了这些类的操作，并增加了一些其他细节来支持持续存储。

Business-object包与DatabasePackage进行协作。

所有的Business-object类必须继承DatabasePackage中的persistent类。

DatabasePackage。

DatabasePackage向Business-object包中的类提供服务，以便他们能够持续地存储。

在当前版本中，persistent类将把它的子类的对象存储到文件系统的文件中。

Designstagesofanalysismodelandwillexpandfurtherrefinement,andconsiderthemodelofthetechnicaldetailsandconstraints.Thedesignaimstoappointafeasiblesolutions,sothatcaneasilychangetobecomeprogrammingcode.

Designcanbedividedintotwophases:

ArchitectureDesignstage（themselves）Architecture.Thisisahigherleveloffromthedesign,usedtodefinebag（subsystem）,describingthedependencebetweenpacketsandcommunicationmechanism.Naturally,thepurposeistodesignaclear,simplestructure,havelittledependence,andasfaraspossibletoavoidtwo-waydependent.TheDetailedDesignstage（Detailedthemselves）.Inthisstage,allclassesaredescribedindetail,towritecodeprogrammersaclearspecifications.ThedynamicmodelusedtoindicatetheUMLhowobjectsofaclassincertaincircumstancesmakecorrespondingperformance.

3.1architecturedesign

Agoodsystemstructuredesignisascalableandcanchangethebasisofthesystem.Packagemayconcernspecificfunctionalareasorconcernspecifictechnicalareas.Theapplicationlogic（domainclasses）andtechnicallogicseparateisvital,sonomatterwhatpartchangeswillnotaffectotherparts.

ThiscasebagorJiaoZisystemasfollows:

User-withPackagebag.ThepacketbasedontheclassAWTbag,JavaJavaAWTisauserinterfaceapplicationsusedtowritetheJavastandardlibrary.ThePackageandPackagebagitasafriend-cooperation.It'safriend-Packagebagcontainingtheactualdatastorageclasses.TheUIpackagecallsforafriendobjecttheyremoveoperation,orinsertdataoperation.

Afriend-objectPackage.Thispackageincludesdomainclasses,thesedomainclasses（suchasyourtitle,borrowerinformation,loan,etc.）onthisitem,fromanalysismodel.Designstagecompletelydefinesthesekindofoperation,andaddedsomeotherdetailstosupportcontinuedstorage.Afriend-