本节向大家介绍一下如何用UML设计Java应用程序， 这里就以图书馆借阅和预定图书和杂志的应用程序为例向大家讲解，主要有需求分析和域分析等内容，相信本节的学习一定会让你对UML设计有新的理解。
用UML设计Java应用程序
本文的案例学习提供了一个例子，说明如何将UML用在现实中。一个处理图书馆借阅和预定图书和杂志的应用程序，可以大到足够检验UML解决现实问题能力的程度。但是如果太大的话，则不适合在杂志上发表。
在分析模型中，用用例和域分析描述了应用程序。我们进一步把它扩展成设计模型。在设计模型中，我们描述了典型的技术解决方案细节。***，我们编写了一段Java代码（代码连同完整的分析和设计模型放在网上，以一种包括评估版在内的RationalRose能够识别的格式在线提供。）
必须注意，这里只是一个可行的解决方案。可能会有许多其他的解决方案。没有绝对正确的方案。当然，有的方案更好一些，但只有不断的实践和努力的工作才能掌握相应的技能。
1．需求（Requirements）
典型地，由系统最终用户的代表写出文本形式的需求规范文档。UML设计中对于该图书馆应用程序来说，需求规范文档应该类似于这样：
1.这是一个图书馆支持系统；
2.图书馆将图书和杂志借给借书者。借书者已经预先注册，图书和杂志也预先注册；
3.图书馆负责新书的购买。每一本图书都购进多本书。当旧书超期或破旧不堪时，从图书馆中去掉。
4.图书管理员是图书馆的员工。他们的工作就是和读者打交道并在软件系统的支持下工作。
5.借阅人可以预定当前没有的图书和杂志。这样，当他所预定的图书和杂志归还回来或购进时，就通知预定人。当预定了某书的借书者借阅了该书后，预定就取消。或者通过显式的取消过程强行取消预定。
6.图书馆能够容易地建立、修改和删除标题、借书者、借阅信息和预定信息。
7.系统能够运行在所有流行的技术环境中，包括Unix,Windows和OS/2，并应有一个现代的图形用户界面(GUI)。
8.系统容易扩展新功能。
系统的***版不必考虑预定的图书到达后通知预定人的功能，也不必检查借书过期的情况。
2．分析（Analysis）
系统分析的目的是捕获和描述所有的系统需求，并且建立一个模型来定义系统中主要的域类。通过系统分析达到开发者和需求者的理解和沟通。因此，分析一般都是分析员和用户协作的产物。在这个阶段，程序开发者不应该考虑代码或程序的问题；它只是理解需求和实现系统的***步。
2．1需求分析（RequirementsAnalysis）
UML设计中需求分析的***步是确定系统能够做什么？谁来使用这个系统？这些分别叫角色（actors）和用例（usecases）。用例描述了系统提供什么样的功能。通过阅读和分析文档，以及和潜在的用户讨论系统来分析用例。#p#
图书馆的角色定为图书管理员和借书人。图书管理员是软件系统的用户；而借书者则是来借阅或预定图书杂志的客户。偶尔，图书管理员或图书馆的其他工作人员也可能是一个借书者。借书者不直接和系统交互，借书人的功能由图书管理员代为执行。
图书馆系统中的用例有：
1.借书
2.还书
3.预定
4.取消预定
5.增加标题
6.修改或删除标题
7.增加书目
8.删除书目
9.增加借书者
10.修改或删除借书者
由于一本书通常有多个备份，因此系统必须将书的标题和书目的概念区分开。
UML设计中图书馆系统分析的结果写在UML用例图中。每一个用例都附带有文本文档，描述用例和客户交互的细节。文本是通过与客户讨论得到的。用例“借书”描述如下：
1．如果借阅者没有预定：
◆确定标题
◆确定该标题下有效的书目
◆确定借书者
◆图书馆将书借出
◆登记一个新的借阅
2．如果借阅者有预定：
◆确定借书人
◆确定标题
◆确定该标题下有效的书目
◆图书馆将相应的书目借出
◆登记一个新的借阅
◆取消预定
除了定义系统的功能需求之外，在分析过程中用例用于检查是否有相应的域类已经被定义，然后他们可以被用在设计阶段，确保解决方案可以有效地处理系统功能。可以在顺序图中可视化实现细节。
图1：角色和用例。分析中的***步就是指出系统能被用来做什么，谁将去使用它。它们分别就是用例和角色。所有的用例必须始于角色，而且有些用例也结束于角色。角色是位于你所工作的系统外部的人或其他系统。一台打印机或一个数据库都可能是一个角色。本系统有两个角色：借阅者和图书管理员。通过与用户或客户的讨论，可以将每一个用例用文字进行说明。
2．2域分析（DomainAnalysis）
UML设计时系统分析也详细地列出了域（系统中的关键类）。为了导出一个域分析，可以阅读规范文档（specifications）和用例，查找哪一些概念应该被系统处理。或者组织一个集体讨论，在用户及领域专家共同的参与下指出系统中必须处理的关键概念，以及它们之间的关系。
图书馆系统中的域类如下：borrowerinformation（如此命名是为了与用例图中的角色borrower区分开来），title，booktitle,magazinetitle,item,reservation和loan。这些类以及它们之间的关系记录在类图文档中，如图2所示。域类定义为Businessobject版型，Businessobject版型是一个用户自定义的版型，指定该类的对象是关键域的一部分，并且应该在系统中持久存储。
其中有些类有UML状态图，用来显示这些类的对象可能具有的不同状态，以及触发他们的状态发生改变的事件。该例子中有状态图的类是item和title类。
用例lenditem（借阅者没有预定的情况）的顺序图显示在图3中。所有用例的顺序图都可从在线模型中查到。
图2：域类结构。域分析详细说明了系统中的关键类。对每一个对象而言，如果它调用了其他对象的方法，那么在他们之间就用一条直线连结起来，以显示他们之间的关系。每一个代表类的四边形被分成了三部分，最顶层包括类的名称，中间一层是类的属性，***层是类的方法。类之间的直线是关联，用来指出一个对象调用另一个对象的方法。如果再仔细看，将会发现在Loan和Item之间的关联关系中靠近Loan的一端有“0..1”,这代表关联的重数。重数“0..1表示Item可以感知0个到1个loan。其他可能出现的重数还有：“0..*”表示0或多；“1”表示就是1；“0”表示就是0，“1..*”表示1或多。
当对顺序图建模时，必须提供窗体和对话框作为人机交互的界面。在本分析当中，只要知道借书、预定和还书需要窗体就可以了。在此，详细的界面不必考虑。
为了把系统中的窗体类和域类分开，所有的窗体类组织在一起放在GUIPackage包中。域类组织在一起放在BusinessPackage包中。
图3：Lenditem场景的顺序图。UML设计中场景是从头到尾实现一个用例的一次特定的过程。场景总是始于角色，而角色是属于系统外部的。场景描绘了从所有角色的观点出发，完成一次系统动作的完整过程。UML在用顺序图来图示场景。本用例图显示了在借阅者没有预定图书的情况下的Lend用例。横在图的顶部的是参与交互的对象。自上而下表示时间的流逝。首先，图书管理员尝试去查找标题。标有“LendingWindow”的是用户界面，在分析阶段作为一个粗略的对象。横在顺序图中的每一个箭头都是一次方法的调用，箭头的首端是调用的对象，箭头的末端是被调用的对象。
【编辑推荐】
