完整版UML对基于BS模式的图书管理系统的分析与毕业设计论文.docx

完整版UML对基于BS模式的图书管理系统的分析与毕业设计论文.docx

《完整版UML对基于BS模式的图书管理系统的分析与毕业设计论文.docx》由会员分享，可在线阅读，更多相关《完整版UML对基于BS模式的图书管理系统的分析与毕业设计论文.docx（10页珍藏版）》请在冰豆网上搜索。

完整版UML对基于BS模式的图书管理系统的分析与毕业设计论文

UML对基于BS模式的图书管理系统的分析与设计

∙摘要：

对基于BS模式下的图书管理系统进行分析，运用UML的静态和动态模型图，对系统的分析结果进行可视化建模，并对系统模型图进行概括性论证。

∙标签：

B  S  图书管理系统  UML  模型图

1前言

使用计算机软件对图书进行管理，是计算机应用的一部分。

以实现图书检索迅速、可靠性高、存储量大、寿命长、成本低等特点，能极大程度地提高图书管理的效率，也是图书管理信息化、正规化管理的必然趋势。

针对用户对图书资源进行有效利用和管理的功能需求，用建模技术对图书管理资源采用面向对象的描述方式，在具体系统功能实现之前，建立起系统模型是很必要的，这里采用具有可视化、能够柔性实现分析、设计和开发系统的统一建模语言实现系统模型构建。

同时，结合最流行的基于浏览器的数据管理模式，建议采用基于组件技术的BS（browerserver）系统结构。

2图书管理系统用例分析

要开发一个软件系统，首先要对软件系统的需求进行分析，要做的工作是深入描述目标系统的功能和性能，确定软件设计的限制和软件同其他系统元素间的接口细节，定义软件的其他有效性需求。

运用UML（UnifiedModellingLanguage：

统一建模语言）的目的可以捕捉系统的功能需求、分析，提取所开发系统领域的类以及描述它们之间合作概况，在完成系统的OOA（Object-OrientedAnalysis：

面向对象分析）在此基础上，对系统进行OOD（Object-OrientedDesign：

面向对象设计）。

UML的用例图较详细和确切地描述了用户的功能需求，使系统责任明确到位，奠定UML对系统建模的基础，这样，其他模型图的构造和发展依赖于用例图中所描述的内容，直至系统能够实现用例图中描述的功能。

采用用例图描述的图书管理主要包括三类用户：

读者、图书管理员、系统管理员。

其中，读者是多个，图书管理员是几个，系统管理员是一个。

对于系统，读者可以查询自己的借阅情况、分门别类的查询图书和在规定期限内续借不能超过一次操作的情况下进行自行登录续借书等。

图书管理员主要是日常操作以下几个工作环节：

图书订购、新书验证、书目录入、图书登记、读者信息管理、借阅书登记、图书信息注销和读者信息注销等，而系统管理员统筹管理图书的系统相关事宜，比如权限维护、日志维护、增删用户和管理系统后台数据等。

用例间关系、用户与用例关系及用例之间的关系如图1所示。

图1：

图书管理用例分析图

3系统静态建模    

在用例分析基础上，根据需求可建立起系统的静态数据模型，即建立系统类图，以及相关的关系和方法。

在面向对象分析中，一般只考虑与问题描述域和系统功能相关的对象。

在对系统进行分析时，这里把系统的类对象抽象为图书管理、图书流通两方面。

针到这两部分可以分化为以下相关类：

图书类（lib_Book）、图目类（lib_Category）、订书类（lib_Order）、报表类（lib_Form）、读者类（lib_Reader）、流通书类（lib_CirBook）、部门类（lib_Department）、出版社类（lib_Publish）等。

这些类之间我们可以用朴素的关联关系作一简要表达。

如图2为图书管理静态类图，在图中每条有直接多重性关联的线上已标示出多重性，这为以后编程中提供了更好的关联参考价值，并为类在整个开发中的统一性奠定基础。

图2：

图书管理静态类图

4系统动态建模

在考察了系统某一时刻的对象及对象之间朴素关系的静态结构后，下面要关注的是在任何时刻对象及其关系改变的情况，这些情况可以用UML的动态模型进行形象化描述，可以借助UML中的状态图来描述，在状态图中，把每时刻的系统状态抽象成状态和事件，然后组成一个网络，侧重于描述每一类对象的动态行为。

它是对某一时刻中属性特征的概括，并且每种状态间存在着迁移，迁移则表示了这类对象在何时对系统内外发生的哪些事件作出何种响应。

状态图设计一般是在对操作序列的顺序图细化的基础上表达。

这里以借书的状态图为例，把上面的面向对象分析与设计、并对系统静态结构的把握后，建立起系统动态数据的逻辑视图，如图3所示，以此为点，可以建立起整个系统的状态流程分析，这里不再详述。

图3：

借书状态图

5基于BS模式的系统结构

在完成了系统的用例分析、模型化静态数据描述以及局部动态数据的状态控制后，基本上掌握了系统在进行逻辑数据处理的流程。

而最终要成为一个系统管理体系，这就需要从总体上把握系统数据的获取、处理及存储。

在基于BS模式的软件开发中，其体系结构一般分为采用组件技术的三层，浏览器层、Web逻辑处理层和数据库管理层。

这里系统的开发建议采用基于Java的面向对象开发技术，将设计的逻辑组件、数据访问组件运行在JavaBean和COM+组合的运行环境，底层数据处理则采用数据管理安全性稳定性很强的Oracle9i。

不仅增强了系统访问数据的安全性，同时也可以处理后台数据库的并发、远程、跨平台访问。

在数据库管理层也是通过JavaBean对象组件完成对后台数据库服务的访问，整个逻辑处理过程如图4所示。

6总结

本文对图书管理系统采用面向对象的分析及设计方法，对系统进行了可视化的需要分析与系统设计。

整个过程中，采用了UML技术。

并对系统采用了基于BS模式的三层体系解决方案，借助于Web浏览器，提供了更加快捷方便的图书管理流程，节省了管理人员和读者的大量时间，有利于信息处理效率的提高，大大减少了重复信息。

同时，也简化工作人员对图书的管理及维护工作。

另一方面，基于组件技术的系统结构具有很好的可伸展性和可扩展性，提高了系统的柔性与自适应性，有助于系统的二次开发。

参考文献

[1]潘伟，基于UML实现图书管理系统的建模设计[J]，图书情报知识，No.103Feb，2005

[2]张广泉，刘艳，基于UML的图书管理系统体系结构模型及实现[J]，重庆师范大学学报，Vol.22No.2Jun2005

[3]高志坚，运用UML建模机制构建图书管理系统[J]，平顶山学院学报，Vol.14No.2Mar.2005

[4]柳翠寅，基于WEB的图书管理系统[J]，成都教育学报，Vol.9.No.1Jan，2005

[5]刘治国，构建基于BS结构的图书管理系统[J]，信息技术，2005年第3期

作者简介

王标（1980-），男（汉族），山东人，助理馆员

夏小娜（1980-），女（汉族），山东人，硕士研究生，主要研究方向：

管理信息系统、软件工程

用UML进行有效业务建模

∙摘要：

大多数软件开发实践者都知道，UML在对真实世界的现象进行建模时非常优秀。

这一特性可以有效帮助分析员和客户进行沟通。

本文介绍如何使用UML进行有效业务建模。

∙标签：

UML  UML建模  UML业务建模  业务用例

大多数软件开发实践者都知道，UML在对真实世界的现象进行建模时非常优秀。

这一特性可以有效帮助分析员和客户进行沟通。

一些希望使用业务建模的团队常常有一些经验性的问题，例如：

*什么时候真正需要业务模型？

什么时候用例模型独立存在？

*我在进行精确的业务建模时我能用哪些UML图形？

我如何知道是否用顺序图或者交互图。

有例子吗？

*业务模型如何涉及到其他模型（如领域模型，用例模型等等）呢？

我如何有机地组织这些模型？

很不幸，本文的焦点集中于应用UML进行业务建模的问题，而很少把业务建模和系统建模进行比较。

这将使用户和分析员对使用UML进行业务建模的感到灰心。

本文主要通过一个例子讲述它们的关系。

这个例子主要用来改进某企业的流程，主要涉及到IT部门、法律顾问、企业架构师、项目经理。

业务用例模型概览

在这个简单的例子中的第一步是完成业务用例模型概览。

如图所示，有两个业务主角和两个业务用例。

我们总结业务用例如下：

*PrepareTender:

  准备系统说明书的流程。

*SelectVendor:

     选择卖方的流程。

我们总结业务主角如下：

*EndUserManager:

 公司内的需要自动控制系统的部门。

*VendorManager:

    卖方的管理者。

在这个例子中，得到一个新系统的核心业务目标被精化为两个子目标：

*详细说明想得到的系统。

*选择并评估候选人。

业务用例规约

这一部分，我们来看看如何描述业务用例，虽然RUP中对业务用例规约有很详细的模版，但我们主要把精力放在基本流和扩展流上。

PrepareTender的基本流：

用例的目标是确定招标文件，同时可以将招标文件发布给候选卖主。

1.指定用户代表。

2.用户代表准备系统规约。

3.IT部门复审系统规约，并改进它，形成招标文件。

4.用户代表批准招标文件。

扩展流：

*系统规约无效。

当IT部门发现需求太含糊，最终用户的管理者必须重新制作需求。

那么这个用例从第二步从新开始，如果最终用户管理者不想继续，也可以终止。

*系统已存在。

如果IT部门发现这个需要的系统和其它部门存在的系统很类似，IT部门就提交给最终用户管理者。

如果最终用户管理者希望继续寻找新系统，他必须写出该系统的特色，并重新提交该说明书，回到第二步，如果最终用户管理者不想继续，也可以终止。

*招标文件和需求规约冲突。

在第四步，最终用户管理者发现招标文件有问题，它将被拒绝，IT部门必须重新做它，用例在第三步继续。

业务用例实现

在这部分，我们从几个方面去实现业务用例。

*以工作流为中心

*以流程自动化为中心

*以信息处理为中心

焦点集中在工作流

我们要精力集中在业务角色的职责上，如图所示，PrepareTender有三个业务角色：

焦点集中在工作流

我们要精力集中在业务角色的职责上，如图所示，PrepareTender有三个业务角色：

下面的顺序图描述了PrepareTender的基本流。

 上图中的消息可以映射到每个业务角色的职责（如下图所示）。

这个技术非常类似于用例分析。

由此可见RUP业务建模的技术是很强大的：

相同的技术可用于业务建模和系统建模。

焦点集中在流程自动化

   现在我们准备去探索业务主角和业务角色职责，明确什么时候使用业务系统以及如何使用业务系统。

在我们的例子中，我们有两个业务系统，如下图所示。

TMS是准备招标和选择卖主的系统。

这是一个新系统。

CMS是跟踪合同的系统，已存在。

在RUP中，业务对象建模的指导方针建议可以对“业务系统”定义一个新的泛型图标，在这篇文章中我们将使用“业务角色”图标来表示“业务系统”。

将有一个新的图标在新的UML业务建模规范中。

下面的顺序图描述了PrepareTender基本流的实现，包含了需求的业务系统。

上图中的消息可以映射到业务角色的职责。

如下图所示：

从上图中可以得到系统用例，如下图：

 焦点集中在信息处理

现在让我们看看业务用例在信息处理上的实现，这就是说，有多少业务实体。

经过分析，我们将得到四个业务实体，如下图：

下图是实现PrepareTender的交互图（侧重于信息处理）。

上面两张图的消息可以映射到每上业务实体的职责，如下图：

下图是上图的一个简化。

 结论

软件系统开发出来是为了达到业务目标，可是，用户，分析员，和开发人员常常生活在不同的世界；他们有不同的看法和用不同的行话。

小组间的通讯障碍导致在解释各种系统需求时发生很多激烈的争论。

具有代表性的一点是，他们的改变不是因为用户改变了想法，而是因为最初的需求需要净化。

【相关文章】

∙专题：

UML统一建模语言

∙UML类图详解