使用UML编写Java应用程序

天极软件专题专区精选　　　　　到天极软件“读编交流区”畅所欲言
Google专区	POPO专区	QQ专区　QQ挂机	了解Web2.0
Flash MX 视频教程	Photoshop视频教程	网页设计视频教程	照片处理数字暗房
PPT动画演示教程	Excel动画教程集	Word动画演示教程	Windows Vista专区
特洛伊木马专区	黑客知识教程专区	防火墙应用专区	注册表应用专区
Windows API开发专区	网络编程专区	VB数据库编程专区	图像处理与多媒体编程

　　引言

　　统一建模语言（Unified Modeling Language，简写为UML）是一种通用的模拟语言，它可以用于确定、展示和记录软件系统的设计过程。统一建模语言中的图形标记，尤其是用于面向对象的软件设计。它有两大优点：

　　（1）UML是国际软件工业界广泛认可的标准，它统一了对象模拟的标记和含义，使软件设计工具能发挥更大的功用，同时，现有的对象设计也能更容易地被重新使用。

　　（2）UML博采众长，设当地平衡了简洁性和具体化两个总之，UML已经成为一种单独的系统来演化，不像以前的多种标准的体系引起的问题。

　　所以，作为软件开发者，完全有必要学习、了解UML。本文就提供了一个案例研究，我只是想利用这个案例研究给大家一个对UML的感性认识，了解在现实世界中如何使用UML来编写应用程序。所以我想找了一个相对比较复杂的案例，找来找去，发现图书馆中处理借出以及预借书籍和杂志的应用程序是相当大的例子，足以说明UML如何在现实世界中使用。

　　我只是利用使用案例（use case）和讨论域分析来分析描述一个分析模型中的应用，我把它扩展成一个设计模型，用来描述技术解决方案的一个代表部分，最后，我们再用Java语言进行编码。但请记住，我给出的只是一种可能的解决方案，还有许多其他的解决方案需要您用聪明的头脑去发掘，而且这世界上也没有适合所有的情况的解决方案。当然，某些解决方案会比其他的要好，但那只有有了足够的经验和遇到的许多困难的事并解决之后才会积累下来知识。好，下面我们进入案例研究。

　　要求

　　一般情况下，是使用系统的最终用户的代表人来书写要求规范，对于图书馆应用程序，要求规范应该如下：

　　1、图书馆应用程序应当是图书馆的支持系统。

　　2、图书馆把书籍和杂志借给借书者（读者）的条件当然是读者应当在该系统中注册过，同样书籍和杂志也应当在系统中注册过。

　　3、图书馆处理购买新书或杂志的操作，畅销书或杂志应当多购几本，旧的书籍和杂志当它们过时或残破时就应适当把它们从书架上请下来。

　　4、图书管理员是图书馆中的职员，他的职责就是与顾客(借书者）打交道并通过该系统完成工作。

　　5、借书者可以预借一本当前不在图书馆中的书籍或杂志，当这本书被归还或被购入图书馆的时候，他就会接到通知；当借书者借到这本书或杂志的时候，预定就会被取消；也可以使用显示程序取消预借。

　　6、图书馆可以很容易地创建，更新和删除系统中的书名，借书者，借阅情况以及预借情况等信息

　　7、该系统可以运行于所有流行的操作系统，包括UNIX，Windows以及OS/2，它还应当有先进的友好的图形用户界面( GUI )。

　　8、该系统应当很容易使用新的功能扩展。

　　在本案例分析中，该系统的第一个版本不需要处理某个读者预借的书籍成为可借书籍时发送消息给读者的操作，也不需要检查某本书籍是否已经超时了。

　　分析

　　分析的目的是为了获得和描述系统中所有的要求，以及生成一个在该系统中定义关键域类的模型。其目标是在开发者与制定要求的人之间建立相互理解和沟通，因此分析是一种典型的与用户或客户合作的行为。在这个阶段开发者不应该考虑具体的代码或程序细节；这只是真正地理解要求和正在设计的系统的实际情况的第一步。

　　第一节分析要求

　　分析的第一步应当是判断该系统将被用于做什么以及谁将使用它。这分别是所谓的使用案例（use case）和行动者（actor）。使用案例描述了图书馆系统具体应当提供哪些功能，即系统的功能要求。一个使用案例分析过程包括阅读和分析规范，并且讨论该系统的潜在的用户(客户)。图书馆中的行动者是图书管理员和借书者，图书管理员是该系统的用户而借书者则是顾客，查看并且预订书籍和杂志的人应该是借书者，但是有时候也可能是一个图书管理员或另外一个图书馆。借书者并不需要直接与系统打交道，借书者的功能通过图书管理员来代理完成。

　　图书馆系统的使用案例是：

　　借书
　　还书
　　生成预订
　　删除预订
　　增加书目
　　更新或删除书目
　　添加书籍
　　删除书籍
　　添加借书者
　　更新或删除借书者

　　因为图书馆中的一种畅销书常常有好几本，所以系统必须把畅销书从普通书目中区别开来。

　　如果借书者没有预借书籍：

　　识别像要借的书的书名。
　　识别馆中本书目前可借的书籍
　　识别借书者
　　图书馆借出这本书。
　　登记刚刚发生的借出情况。
　　如果借书者曾预借某本书籍：
　　识别借书者。
　　识别预借的书名。
　　识别馆中本书目前可借的书籍。
　　图书馆借给借书人相应的书。
　　登记借出情况。
　　删除预借书籍的纪录。

　　除用于定义本系统的功能要求之外，使用案例还被用来分析检查适当的讨论域类是否已经被定义，以及在设计过程中它们是否能被用来确认该技术解决方案能够处理所需要功能。使用案例可以在序列图上看见，来实现一些技术细节。

　　第二节 讨论域分析

　　分析过程中还要详细地列举讨论域(domain ，系统中关键的类)，为了进行讨论域分析，需要充分理解规范和使用案例并且着眼于系统将要处理的"概念"；或者与使用者及讨论域专家组织一次集体研讨会谈，尝试找出所有必须处理的关键概念以及它们之间的相互关系。

　　图书馆系统中的讨论域类如下：: BorrowerInformation（这样命名是为了区别于使用案例图表中的行动者Borrower），Title，Book Title，Magazine，Item，Reservation和Loan。图2是一张类图，标出它们的相互关系。这些讨论域类是用户自定义的类，指定该类的对象是关键域的一部分并将被持久的保存在系统中。

图二解释：域类结构。域分析要详细列举系统中的关键的类。对于每一个对象，它调用另外一个对象上的方法，就要在类之间加上一根线来说明它们的关系。每个用来表示类的矩形框被横向隔成三部分。最上面一格是类的名称，中间是类的属性，最下面一格是类的方法。两个类之间的关联用一根实现连接代表，象征一个对象调用了另外一个对象的方法。如果你仔细观察，还会发现在Loan和Item关联的Loan端的"0..1"，代表那一端可取的对象数。

　　一些类用UML状态图来显示这些类的对象的不同状态以及能够使它们的状态改变的事件，如本文中的例子就是Item和Title。图3就是借书（Lend Item）的使用案例的序列图（借书者没有预借书籍）。

图三解释：借书情景的序列图。本情景给出的是使用案例的特定的过程，情景总是以一个行动者为开端，即系统以外的人。然后记录通过系统直到以所有的行动者角度来看这个的行动都已完成的完整的路线。用于标注一个情景的UML记号法就是序列图。这张序列图用来说明一个情景，即借书者没有预借某本书时的借书情景。

　　当我们给序列图建模的时候，很明显，我们需要给行动者提供一个与窗口或对话框的接口界面。在本案例分析中，为了把窗口类从讨论域类中区分开的，就把窗口类放入一个名为" GUI Package "的包中，而把讨论域类放入一个名为" Business Package "的包，应当明确需要提供借书、预借书籍和还书界面窗口，此时还不需要定义具体的用户界面。

　　设计

　　当已经考虑了所有的技术细节和限制条件，我们就可以进入设计阶段，设计阶段需要展开和细化分析模型。设计的目的是为了说明一种可以很容易地翻译成程序设计代码的工作解决方案。

　　设计阶段可以分成两部分：

　　1、结构设计这是非常高级的设计，说明在什么地方定义包（子系统），以及包与包之间的相互依赖与通信机制。自然，我们的目标是构建一种清晰而又简单的体系结构，包与包之间的依赖要少，如果可能的话，尽量避免双向的依赖。

　　2、详细设计所有的类都应描述足够的细节，来明确规定谁来编码这些类。UML中的动态模型用于示范类的对象在具体的环境中的行为。

　　下面我将详细说明。

　　第一节结构设计

　　一个设计良好的体系结构是开发一个可扩展、可改变的系统的基础，程序包所需要关心的是要么处理一个具体的功能区域，要么处理一个具体的技术区域。从技术逻辑中把应用程序逻辑（域类）区分开来是极其重要的，这是为了万一需要修改程序的某一部分而不会对另一部分产生影响：一个目标就是标识并设定包与包之间（例如“子系统”）的相互依赖的规则，并不在包之间创建双向的依赖（为了避免程序包集成的太过紧密），另一个目标是为了表示标准类库的需要。现在可用的应用程序库强调的主要还是在技术领域，比如用户界面，数据库或通信机制等等，但是，我们也同样盼望出现更多的具体的应用程序库。

　　本案例研究中的程序包或者说是子系统如下：

　　1、用户界面包（User-Interface）这些类都是基于Java AWT包这个Java中用于编写用户界面应用程序的一个标准的类库。这个程序包与商业对象包（Business Object）协作，商业对象包包含了实际上用于储存数据用的类，用户界面包调用商业对象中的方法来取得并向商业对象中插入数据。

　　2、商业对象包（Business Object）它包括来自分析模型，比如BorrowerInformation，Title，Item，Loan等等的讨论域类。该设计完全地定义了它们的操作并且添加了对于持久性的支持。商业对象包与数据库包合作，所有的商业对象类都必须从数据库包中的Persistent类继承而来。

　　3、数据库包（Database Package）数据库包给商业对象包中的另外一个类提供服务，以使它们能够持久的储存信息。在目前的版本，Persistent类将储存它的子类对象到文件系统中的文件中去。

　　4、实用程序包（Utility Package）实用程序包包含用于该系统中的另外一个包的服务，现在，该包中只有ObjId类，它用于引用遍及本系统的持久对象，包括用户界面，商业对象和数据库包。

　　这些程序包的内部设计见图4。

图4解释图书馆应用程序结构概图。这是一张类图，说明应用程序包以及它们之间的关系。数据库包提供了持久性，公用程序包提供了Object ID类，商业对象包包含了讨论域类，这点在图5中将详细列出。最后，基于标准Java AWT类库的UI包调用商业对象中的操作来向它们中间插入数据。