返回总目录
目录
第11章图书馆信息系统UML实例 (2)
11.1  理解需求 (2)
11.2  分析 (3)
11.3  设计 (6)
11.4    实现 (15)
11.5  测试和配置 (22)
11.6  小结 (23)
第11章图书馆信息系统UML实例
本章将通过一个实例来说明在一个应用中如何使用UML通过前面的讨论首先在分析模型中用用例和域分
析来描述应用然后将分析模型扩展成设计模型描述技术上的解决方案最后用Java语言编程具体实现可以运行的应用有一点需要说明的
是本章中讨论的例子并不包括所有的模型和图
本章讨论的案例是一个图书馆信息系统主要处理书和杂志的借阅和保存虽然它算不上是一个大的应用但可以对它作许多扩展本章的案例研究的目的主要有三个演示在一个完整的应用中如何使用UML从分
析到设计模型到真正的代码和可运行的应用
以Rational Rose为例说明用UML建模时使用的工具
有兴趣的读者可以根据本章中讨论的方法对模型进行扩展从而达到提高应用
UML的水平
注意本章给出的仅仅是一个可能的解决方案可能还有许多其它的方案不存在一个适用于所有环境的正确的解决方案如果读者想对初始的模型作些改变尽管去做目的只有一个产生满足需求且工作正常的系统而不是产生在所有细节上都很完美的图
当然某些解决方案将被证明比其它的好但是只有各界经验和努力工作才能获得知识
11.1  理解需求
下面是一份典型的文本需求说明它是图书馆应用程序的第一版的需求说明是为系统的终端用户或客户而写的
它是图书馆的支持系统
z图书馆将书和杂志借给读者读者和书杂志一样必须在系统中注册
z图书馆负责购买图书对于流行的书一般要多买几本如果旧书或杂志过期了或
很破烂则可以从图书馆中删除
z图书馆管理员是图书馆的雇员负责与客户(借书者)打交道他们的工作要得到
系统的支持
z借书者可以预订目前借不到的书或杂志一旦预订的书被返还给图书馆或图书馆新购买书到达就立即通知预订者
z图书馆可以方便地产生更新和删除系统中与书目借书者借书(loan)和预订的
有关信息
z系统能够在所有流行的技术环境下运行(UNIX, Windows, OS/2 等等)还应该有一个非常好的图形用户界面(GUI)
z系统应该具有很好的可扩展性
系统的第一个版本不需处理当读者预订的书到达时通知预订者的消息也不必检查
一个书目是否过期有关更高的版本的其它需求可在本章的练习中了解到
11.2  分析
分析就是描述系统的需求通过定义系统中的关键域类来建立模型分析的根本目的是在开发者和提出需求的人(用户/客户)之间建立一种理解和勾通的机制因此典型情况下分析是开发人员同用户或客户一起来完成的
分析不受技术方案或细节的限制在分析阶段开发人员不应该考虑代码或程序的问题它是迈向真正理解需求和所要设计的系统的第一步
11.2.1需求分析
分析的第一步是定义用例即描述图书馆系统的功能确定系统的功能需求用例分
析主要涉及阅读和分析规格说明和系统的潜在用户讨论
图书馆中的角为图书管理员和借书者图书管理员是系统的用户而借书者是客
户虽然偶尔图书馆管理员或另一个图书馆也可能是一个借书者借书者的目的不是直接
同系统交互借书者的功能由图书管理员来实现
图书馆信息系统中的用例如下所示
z借出书目(Lend Item)
java图书馆最新z返回书目(Return Item)
z预订(Make Reservation)
z删除预订(Remove Reservation)
z增加标题(Add Title)
z更新或删除标题(Update or Remove Title)
z增加书目(Add Item)
z删除书目(Remove Item)
z增加借书者(Add Borrower)
z更新或删除借者书(Update or Remove Borrower)
上面所列的用例中没有维护维护是一个使用其它用例的更一般的用例同时还应注意到上述用例中出现的两个概念标题(Title)和书目(Item)因为在一个图书馆中一个流行的标题可能有好几本因此系统必须将标题(可能是书名或书的作者)同其它
的书目(代表一个指定标题的物理副本)区分开来从图书馆借的是书目在图书馆拥有一本书的副本(书目)之前加一个标题到系统中是可能的这样做的目的是让借书者可以预
订
图书馆信息系统的分析可以用UML的用例图来描述如图11-1所示每个用例以文本的方式来描述描述的内容包括用例以及用例与角交互的更详细的信息文本的内容是通过与用户/客户讨论后确定的用例借出书目的描述如下
1如果借书者没有预订
a. 标记标题
b. 标记可用的该标题下的书目
c. 标记借书者
d. 图书馆借出标记的书目
图
11-1
图书馆信息系统的用例图
2
如果借书者已经预订
a. 标记借书者
b. 标记标题
c. 标记可用的该标题下的书目
d. 图书馆借出标记的书目
e. 增加一条新的借书记录
f. 删除预订记录
读者可以照此法描述其它的用例在整个系统开发过程中用例描述系统的功能需求在分析阶段利用它们来检查某一域类是否已定义在设计阶段可以用来证实技术方案是否能够处理要求的功能可以在序列图中可视化用例
11.2.2  领域分析
分析也将系统中的领域和关键类条理化为了进行领域分析需要阅读规格说明和用例了解系统要处理的概念或将用户领域专家组织在一起开一个讨论会设法确定所有必须处理的概念以及概念间的关系
图书馆信息系统中的域类主要有借书者(在这里将其取名为BorrowerInformation 以便同用例图中的角Borrower 区分开)标题书的标题杂志标题书目预订和借
书(loan)在类图中将这些域类以及它们之间的关系表示出来如图11-2所示通过版类Business Object来定义域类Business Object是一个用户定义的版类用来表示类
的对象是关键域的一部分应该永久地保存在系统中
有一点要强调的是在本阶段域类还是处于草图状态定义的操作和属性不是
最后的版本只是在现阶段看来这些操作和属性是比较合适的一些操作是在序列图的草图中而不是在用例中定义的(有关情况将在本章后面讨论)
某些类用UML状态图来显示类的对象的不同的状态以及改变状态的事件有状态图的类有书目和标题标题类的状态图如图11-3所示
为了描述域类的动态行为任何动态UML图都可以使用序列图协作图或活动
图因为Rational Rose 4.0不支持活动图对协作图也只提供有限的支持因此我们选用序列图序列图的基础是用例在序列图中说明域类如何协作来操作系统中的用例很
自然地当建立这些序列图时将会发现新的操作并将它们加到类中(图11-2中的类图
显示了建立的序列图模型)另外操作仅仅是草案同样要用说明来详细描述分析的
目的是同用户/客户勾通以对要建立的系统有更好的了解而不是一个详细的设计方案
用例借出书目(没有预订)的序列图如图11-4所示
当用序列图建模时很显然需要窗口或对话窗作为到角的接口在图11-4中借
出书目的窗口是存在的在分析时意识到需要窗口来标识基本的接口就可以了借出
预订和返还书目都需要窗口维护窗口也是必要的此时还没有定义详细的用户接口
另外关于用户接口中包含些什么仅仅还是个草案注意无论怎样也有一些过程或方
法提倡在本阶段设计或原型化一个详细的用户接口但是在本例中因为应用比较简
单所以不采用这些技术详细的用户接口是设计阶段的一部分
在分析阶段为了将域类同窗口类分开将窗口类组装成一个GUI包(称为GUI
包)将域类组装成业务包(Business Package)此外也给应用程序取一个名字称为
通用图书馆应用(Unified Library Application)

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。