UML业务建模实例分析四例

《UML业务建模实例分析四例》由会员分享，可在线阅读，更多相关《UML业务建模实例分析四例（27页珍藏版）》请在装配图网上搜索。

1、UML业务建模实例分析在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。我们在日常生活中也经常和ATM打交道。本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。5.1用例图参与者银行储户和ATM机。简化后的ATM机仅有取款、存款及其余功能。其余功能不做详细说明。图5.1 自动取款机（ATM）系统用例图 银行储户在ATM机上完成取款、存款及其他业务。5.2类图图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。整个银行系统包括了帐户库、银行储户库及ATM系统。许多单个的帐户组成了

2、帐户库。帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。 setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。 getType获取帐户类型，返回类型为char，无参数。 setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。 getAcc

3、ountNumbe获取帐户号，返回类型为int，无参数。 caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。 getBalance获取帐户余额，返回类型为double，无参数。许多银行储户组成了储户库。ATM系统包含了许多ATM机。银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。同样对于一个真正的银行系统，这个类图过

4、于简单。比如帐户类型我们可以先定义一个abstract class，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract class，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。 图5.2 银行系统类图5.3顺序图图5.3描

5、述了顾客在ATM机上取款时信息的流动情况。以时间为顺序。因为仅是示例，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个X，这是因为这个流程中还未遇到有对象生命结束。当有对象生命结束时需在对应的生命线终端画X，表明这个对象在这时被销毁。首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示

6、出来.因为这个顺序图较长，且很清晰，即便是初学者也很容易读懂，在此就不对本图做过多的解释。图5.3 ATM取款顺序图图5.4描述了顾客在ATM机上进行操作会经历的几种状态，及各种状态之间转换的条件。因为是简化了的例子，所以除了等待顾客插入磁卡的起始状态和结束服务的终止状态，顾客会处于输入密码、选择服务类型、存款及取款四种状态。 插入磁卡后进入输密码状态，当密码输入正确时进入选择服务类型状态，当输入密码不正确时，停留在原状态，但如果三次不正确，服务结束。进入选择服务类型后根据选择的不同，顾客可进入存款和取款状态。存、取款结束后，顾客既可以选择结束服务到最终状态，也可以选择继续服务回到选择服务类型

7、状态。通过状态图我们可以无歧义的了解各个活动角色是如何在不同状况下转换的，转换的条件是什么，是否会出现死锁现象，是否有条件没考虑周全，是否有状态无法达到。状态图可以帮助我们发现问题，并及时改正。 5.5活动图图5.5参考了Randy Miller的A Hands-On Introduction for Developers一文，5.3图中的客户管理和事物管理对应于5.5图中的Bank，图5.3中的读卡机、显示、输入设备及点钞机对应于5.5图中的ATM Machina，银行储户就是Customer。初看活动图和顺序图表达的意义很接近。但我们可以注意到顺序图着重时间的顺序，而活动图侧重于各部分之间

8、的相互制约，对于一些并行的活动能够有效的表示出来。例如5.5图中fork和join处，我们可以很清楚的看到一些并行活动的存在。这个活动图以顾客插入卡为开始，以顾客取卡结束。我们可以看到活动图的重点虽然不在时间顺序，但我们同样可以得到时间的信息。 图5.5 ATM银行系统活动图5.6协作图在第四章中我们知道协作图和顺序图是可以无信息损失的相互转换，只是它们的侧重点是不一样的。顺序图着重于对象间消息传递的时间顺序，协作图着重于表达对象之间的静态连接关系。图5.6将5.3图转换为协作图。1. 插入ATM卡2. 接受ATM卡3. 查询密码4. 显示输入密码请求5. 输入密码6. 密码传递7. 请求确认

9、密码合法性8. 确认密码合法性9. 询问服务类别10. 显示输入服务服务类别请求11. 输入取款请求12. 取款请求 13. 询问取款数额14. 显示输入数额请求15. 输入取款数额16. 传递取款数额17. 询问取款数额确认18. 显示确认数额请求19. 输入确认20. 传递确认信息21. 数额合法性确认请求22. 确认数额和法性23. 出钞请求24. 计算帐户余额25. 出钞26. 取钞27. 传递余额并询问是否还需要其他服务28. 显示帐户余额并提示选择下面的服务 从图上我们可以看出协作图的角色和顺序图的对象是一一对应的，而协作图上的各对象上的协作关系和顺序图上的消息传递是一一对应的。

10、例解基于UML的面向对象分析与设计 摘要 本文以实例的方式，展示了如何使用UML进行面向对象的分析与设计。本文将假设读者对UML、面向对象等领域的基本内容已了然于胸，所以将不会过多阐述，而将重点放在应用过程上。本文的目的是通过一个完整的实例，展现基于UML的OOA&D过程的一个简化模式，帮助朋友们更好的认识UML在OOA&D中起的作用。前言 经常听到有朋友抱怨，说学了UML不知该怎么用，或者画了UML却觉得没什么作用。其实，就UML本身来说，它只是一种交流工具，它作为一种标准化交流符号，在OOA&D过程中开发人员间甚至开发人员与客户之间传递信息。另外，UML也可以看做是OO思想的一种表现形式，

11、可以说“OO是神，而UML是型”。所以，想用好UML，扎实的OO思想基础是必不可少的。然而，在UML应用到开发过程中时，还是有一定的模式可以遵循的。（注意，是模式而不是教条，我下面给出的流程只是一个启发式过程，而不是说一定要遵循这个流程。）下面，我们通过一个CMS系统的分析设计实例，看看如何将UML应用到实际的开发中。1.从需求到业务用例图 OOA&D的第一步，就是了解用户需求，并将其转换为业务用例图。我们的CMS系统需求非常简单，大致课做如下描述：这个系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。管理

12、员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。 通过以上需求描述，我们画出如下的业务用例图： 这里要注意三点： 1.业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。它描述的是“该实现什么业务”，而不是“系统该提供什么操作”。例如，在实际系统中，“登录”肯定要作为一个用例，但是这是软件系统中的操作，而用户所关注的业务是不包含“登录”的。 2.业务用例仅包含客户“感兴趣”的内容。 3.业务用例所有的用例名应该让客户能看懂，如果某个用例的名字客户看不懂什么意思，它也许就不适合作为业务用例。2.从业务用例图到活动图 完成了业务用例图后，我们要为每一个业务用例绘制一幅活动图。活

13、动图描述了这个业务用例中，用户可能会进行的操作序列。活动图有个很重要的使命：从业务用例分析出系统用例。例如，下面是“新闻管理”的活动图： 可以看到，一个“新闻管理”这个业务用例，分解出N多系统操作。这里要特别注意这些操作，其中很多“活动”都很可能是一个系统用例（当然，不是每个都是）。例如，由这个活动图可以看出，系统中至少要包含以下备选系统用例：登录、注销登录、查看新闻列表、修改新闻、删除新闻。 这样，将每个业务用例都绘制出相应的活动图，再将其中的“活动”整合，就得出所有备选系统用例。3.从活动图到系统用例图 找出所有的备选系统用例后，我们要对他们进行合并和筛选。合并就是将相同的用例合并成一个，

14、筛选就是将不符合系统用例条件的备选用例去掉。 一个系统用例应该是实际使用系统的用户所进行的一个操作，例如，“查看新闻列表”就不能算一个系统用例，因为他只是某系统用例的一个序列项。 最终我们得出的系统用例图如下：4.从系统用例图到用例规约 得出系统用例图后，我们应该对每一个系统用例给出用例规约。关于用例规约，没有一个通用的格式，大家可以按照习惯的格式进行编写。对用例规约唯一的要求就是“清晰易懂”。 下面给出“登录”这个系统用例的一个规约：5.绘制业务领域类图 完成了上面几步，下面应该是绘制业务领域类图了。所谓业务领域类图要描述一下三点： 1.系统中有哪些实体。 2.这些实体能做什么操作。 3.实

15、体间的关系。 这里要特别强调：这里的实体不是Actor，而是Actor使用系统时使用的所调用的实体，是处在系统边界之内的实体。例如，管理员就没有作为一个实体出现在这里，因为管理员处在系统边界之外，它所有的工作都可以通过调用这三个类的方法完成。并且，这里的“注册会员”实体也不是刚才用例图中注册会员这个Actor，而是作为一个系统内的业务实体，供Actor们使用的。例如，其中的注册功能是给注册会员这个Actor使用，而移除则是给管理员这个Actor使用的。 理解以上这段话非常重要，我经常看到由于混淆了实体和Actor的关系而导致画出的领域类图不准确或职责分配不准确。大家可能还注意到，我们这里没有给

16、出每个实体的属性。其实，在领域分析阶段，实体的属性并不重要，重要的是找出实体的操作。 6.绘制实现类图 以上这几步，就是分析的过程。而下面的步骤就是设计了。 设计没有分析那么好描述，因为分析是“客户面”，它只关心系统本身的功能和业务，而不关心任何和计算机有关的东西。但是，设计和平台、语言、开发模型等内容关系紧密，因而很难找出一个一致的过程。但是，一般在设计过程中实现类图是要绘制的。 实现类图和领域类图不一样，它描述的是真正系统的静态结构，是和最后的代码完全一致的。因此，它和平台关系密切，必须准确给出系统中的实体类、控制类、界面类、接口等元素以及其中的关系。因此，实现类图是很复杂的，而且是平台技

17、术有关的。所以，我在这里不可能给出一个准确的实现类图，不过为了描述，我还是给出一个简化了的实现类图，当然，它是不准确的，而只是从形式上给出实现类图的样子。 我们假设这个系统建构于.NET 3.5平台上，并且使用ASP.NET MVC作为表示层，整体使用三层架构。那么，用户模块体系的实现类图大体是这样子（不准确）：7.绘制序列图 有了静态结构，我们还要给出动态结构，这样，才能看清系统间的类是如何交互的，从而有效帮助程序员进行编码工作。 上图给出的是用户登录的序列图。首先注册会员作为Actor，调用UserController的Login方法启动序列，然后序列按图示步骤执行。其中UserServi

18、ces作为业务组件，首先调用数据访问组件的GetByName确定用户是否存在，如果存在，再调用GetByNameAndPassword确定输入密码是否是此用户的密码。从而完成业务功能。 要注意，序列图在实际中是很多的，几乎每个类方法都配有相应的序列图。8.后面的步骤 在完成了上面的过程后，就可以进行编码、调试、测试等工作了。但这些已经超出了本文讨论的范围。总结 本文简要给出了使用UML进行OOA&D的过程。当然，由于示例较小，而且本人水平有限，所以给出的相关内容可能不是很准确。而且软件分析设计本来就不是一个固定模式的过程，随着系统的不同整个过程会有变化。本文只是想起到一个抛砖引玉的作用，让朋友

19、们大致了解UML的使用流程。至于实际的分析设计，还需要深入的学习和实践的积累。UML业务建模实例分析作者: 范里程 出处:软件世界对于大中型信息系统，很难直接进行需求分析设计，需要借助模型来分析设计系统，根据系统调研数据，建立起目标系统的逻辑模型。 在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中越来越多的人认识到它是整个过程中最为关键的一个过程。假如在需求分析时分析者们未能正确地认识到客户的需求的话，那么最后的软件实际上不可能达到客户的要求，或者导致需求的频繁变更，而软件无法在规定的时间里完工。 在需求分析阶段，要对经过可行性分析所确定的系统

20、目标和功能作进一步的详细论述，确定系统“做什么？”的问题，最终建立起目标系统的逻辑模型。 首先是获得当前系统的物理模型。物理模型是对当前系统的真实写照，可能是一个由人工操作的过程，也可能是一个已有的但需要改进的计算机系统。首先是要对现行系统进行分析、理解，了解它的组织情况、数据流向、输入输出，资源利用情况等，在分析的基础上画出它的物理模型。然后抽象出当前系统的逻辑模型。 逻辑模型是在物理模型基础上，去掉一些次要的因素，建立起反映系统本质的逻辑模型。接下来建立目标系统的逻辑模型。通过分析目标系统与当前系统在逻辑上的区别，建立符合用户需求的目标系统的逻辑模型。最后补充目标系统的逻辑模型。对目标系统

21、进行补充完善 ,将一些次要的因素补充进去，例如出错处理等。 UML（The Unified Modeling Language，即统一建模语言）是一种编制系统蓝图的标准化语言，可以对复杂的系统建立可视化的系统模型，目前已经被工业标准化组织OMG（Object Management Group）接受，一经推出便得到许多著名的计算机厂商如Microsoft、HP、IBM、Oracle等的支持，也在逐步开始应用到需求分析过程中。 在使用UML建立当前系统逻辑模型过程中，初学者通常会遇到一些问题： 1.什么时候真正需要业务模型？什么时候用例模型独立存在？ 2.在进行精确的业务建模时能用哪些UML图形？

22、如何知道是否用顺序图或者交互图？ 3.业务模型如何涉及到其他模型（如领域模型，用例模型等等）呢？如何有机地组织这些模型？ 本文将通过图书馆管理系统这个简单而典型的实例来进行一次UML需求分析实践之旅。 许多读者对图书馆图书管理工作比较熟悉，主要是围绕读者、图书和工作人员的借还书展开工作。我们先看看图书馆工作人员和部分读者的需求。 读者来图书馆借书，可能先查询书库的图书记录。查询可以按书名、作者、图书编号、关键字查询。查询有两种结果，如果查到则记下书号，交给工作人员，然后等候办理借书手续。如果该书已经被全部借出，则可做借书登记，等待有书时被通知。如果图书馆没有该书的记录，则做缺书登记。 办理借书

23、手续时先要出示图书证，没有图书证则去申请图书证。如果借书数量超出规定，则提示“借书数量超限，不能继续借阅”。工作人员登记借阅人信息、借阅的图书信息、借出时间和应还书时间。系统自动修改书库的图书记录、读者库信息。 当一位读者还书时，工作人员根据图书证编号，找到读者的借书信息，查看是否超期，如果已经超期，则进行超期处罚。 如果图书有破损、丢失，则进行破损处罚。清除借阅记录，同时系统自动查看是否有等待借阅登记，如果有则发出通知，修改书库记录，该书设置为已预订状态，否则设置为可借状态。 图书采购人员进行图书采购时，要参考各类图书的库存数和借阅率，注意合理采购。如果有缺书登记则随时进行采购。正在采购的图

24、书组成一个采购中书库。 采购到货后，进行验收，编号，同时加入图书库，修改采购中书库，并且查看订阅库，发出到书通知，并且已经修改书库的图书记录为已预订状态。 借书登记是当欲借的书被借空后，读者自愿选择的一种操作，它应该记录读者名和联系方式，一旦有这本书后可通知读者。 到书通知，当读者预订的书来到之后，按照读者给出的联系方式发出通知。 缺书登记是当读者需要的书库内查询没有记录时，将此信息转入缺货库，通知采购员采购。 图书注销，如果图书丢失或旧书淘汰，则将该书从书库中清除。 根据需求描述整理一张需求表： 需求分析时首先要识别出系统的参与者，在简单的图书馆管理系统中，可以划分出两种参与者：读者和管理员

25、。当然，根据业务的复杂程度，参与者也可以进行细分，比如读者可以再分为学生读者、教师读者、校外读者，管理员根据业务和权限的不同可以再细分为库房管理员、借还书操作员、系统维护人员、图书馆管理人员等不同角色。在这里，为了简化处理，我们只列出了读者和管理员。对参与者描述如下： （1）读者 描述：读者可以借阅、预定、归还物理书刊，可以对书籍和个人信息进行查询，可以取消预定，可以提出办卡申请。 示例：持有借阅卡的任何人和组织。（2）管理员 描述：图书管理员对系统进行维护，包括读者信息的创建、修改、删除，书刊信息的维护，条目信息的维护，还有系统信息的维护。 示例：图书管理员。 通过识别的参与者，对需求进一步

26、分析，将业务需求进行分解，获得每个参与者的使用用例。在本例中，我们可以得到以下用例： 1.书籍借出：提供借阅物理书刊的功能。 2.书籍归还：提供归还物理书刊的功能。 3.读者办卡：提供为读者办理借阅卡的功能。 4.预定书刊：提供对某一个种类的书刊的预约功能。 5.取消预定：提供对预定进行取消的功能。 6.书籍查询：为读者提供网上的书籍查询功能。 7.信息查询：为读者提供信息查询的功能。 8.读者信息维护：提供读者信息的录入、修改、查询、删除的功能。 9.书刊信息维护：提供物理书刊的录入、修改、查询、删除的功能。 10.条目信息维护：提供书刊条目的录入、修改、查询、删除的功能。 11.系统信息维

27、护：提供对系统的参数的设置。 12.登录：管理员需要先登录才能进入系统。 并且，可以画出如下系统用例图： 通过用例图，可以对系统功能有一个大概的了解，对于复杂系统，我们可以结合IDEF方法，通过分层分解，逐步细化的方法来描述系统的功能。对于用例图，建议不要画的过于复杂，特别是用例之间的关系，因为复杂的用例图不仅不能让需求分析人员与客户之间更好的沟通，反而是制造了一种沟通障碍。 下一步就是编制每一个用例的详细说明，对用例说明的主要信息包括有：用例名称、编号、用例的简短描述、用例的参与者、与其他用例的管理、用例启动的前提条件、用例结束后的事后条件、用例的输入、输出、用例的执行事件流等。在实际项目中

28、，我们并不一定要面面俱到，而是根据实际情况对用例描述进行裁减。其中有几点重要信息是不能裁减的：用例名称、描述、输入、输出、执行事件流、参与者。另外，如果实际情况需要，还可以使用MS Visio等工具画出界面的示意图来。 如上例所述，我们对每一个用例都进行详细的描述，建立当前系统的功能用例模型。需求沟通与分析是一个迭代的过程，通过与用户的不断沟通，最终达成对目标系统的一致理解。如果用户确认了需求分析的成果，一般是需求规格说明书之后，项目开始进入系统分析设计阶段，也就是开始构造目标系统的逻辑模型。 为了让系统设计能够以结构、组织方式和代码重用的形式表现出来，要对系统进行设计规划，设计阶段应该与分析

29、阶段交迭。需求是不断地发展，而设计本身也会推动需求的发展(反之亦然) 。在图书馆管理系统的建模设计中，以下3个方面的问题是要关注的：业务对象的表示、业务服务的实现、用户界面的组织。 业务对象的表示 在图书馆管理系统系统中，业务对象主要是数据库和数据实体类的表示方式。建模时，可以构造出系统的静态模型，也就是系统类图来表示。如下图则描述了借书这一用例的静态结构图。为了体现类之间的关系，在下图中没有显示出每一个类的属性和基本操作。 业务服务的实现 业务服务的实现需要完成的功能是各种业务规则和逻辑的实现,如借书处理的业务逻辑。每个模块的信息录入、修改、删除、查询等。业务规则和逻辑的实现基本相似，没有太

30、多的规律可循。采用UML来进行业务服务的建模，可以使用UML 的序列图、状态图、活动图。这个部分的工作,通常通过一系列的类之间的交互来完成。为了在更动态的层面上描述系统，UML 提供了许多其他类型的图。 对于B/S系统设计而言，情节图(Scenario Diagram) 特别有用。情节图分成两种：协作图(Collaboration Diagram) ，序列图(Sequence Diagram) 。UML 建模工具Rational Rose 能够从协作图生成序列图也可以从序列图生成协作图。例如，借阅书刊的业务过程可以采用如下序列图来描述： 借阅书刊过程主要包括：管理员选择“借阅书刊”菜单，弹出对

31、话框，管理员输入书刊信息和用户信息，系统查找数据库，是否存在该种物理书刊，如果不存在，显示提示信息，用例结束;是否存在借阅者信息，如果不存在，显示提示信息，用例结束;否则，管理员单击确认按钮后，该图书借阅给该借阅者，系统存储借阅信息到数据库。 用户界面的组织 用户界面布局图能够帮助组织系统页面、文件、服务的布局结构。在UML 中，对于页面和文件的组织，可以使用构件图(Component Diagram) 或类图(Class Diagram) 建模型。本系统中使用类图对界面组织建模，页面结构以及各种业务服务被捆绑到不同的区域。 在 UML 中，系统的体系结构使用部署图(DeploymentDia

32、gram) 来完成。应用部署的规划对于规划整个B/ S 系统是很有用的。它确定了一种有效的应用部署的规划组织方式,还可以作为一个模式在多个类似B/ S 系统上应用。 在建模完成后，开发人员利用一些UML Case工具如Rational ROSE生成程序代码框架，并对代码框架进行修改和补充，形成完整代码;而且，还可根据代码逆向生成 UML模型。这就较好地保证了模型与代码的一致性。 测试必须在整个项目周期中进行，对每个阶段都要用所建立的模型进行测试，这样才能保证开发的质量，减少开发的风险。 统一建模语言 UML 是国际软件工程领域具有划时代意义的重要成果，适用于以面向对象技术来描述任何类型的系统，

33、而且适用于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。软件系统的规模越来越大，复杂度不断提高，RUP迭代式增量开发方式可以降低风险，同时可以适应需求变化的需要。 在本次UML实践之旅中，我们通过对图书馆管理系统的需求进行分析，将 UML 应用于系统开发的各个阶段，建立了系统的需求模型、静态模型和动态模型，同时遵循Rationl统一过程(RUP)的核心思想和基本原则，采用以用例为驱动、以体系构架为核心的迭代化面向对象分析和设计过程。 图1：系统用例图图2：用况活动图图3：借书部分的类结构图UML行为图 用况图（use case diagram）描述了一组用况和参与者（一种特殊的

34、类）以及它们之间的关系。 交互图（interaction diagram）是顺序图和协作图的统称。 顺序图(sequence diagram)是强调消息的时间次序的交互图。 协作图(collaboration diagram)是强调收发消息的对象的结构组织的交互图。 状态图显示了一个由状态，转换，事件和活动组成的状态机。 活动图显示了系统中从活动到活动的流。 UML实例：销售管理系统的UML分析与设计 作者：王文豪|转贴自：UML软件工程组织|点击数：1553|更新时间：2006-8-29|文章录入：admin 摘 要 销售管理系统是现代企业管理系统的一个重要组成部分，传统的系统分析设计方法已

35、经难以保证软件开发的效率和质量，通过将UML应用于销售管理系统建模，可以加速软件开发进程，提高软件质量，支持动态的业务需求，并方便地集成已有的企业管理资源。 关键词 销售管理系统；UML；分析；实现1 引言当前社会对信息系统的需求日益增长，需求变化也越来越快，软件开发的技术发展方向已经从“提升被开发系统的执行效率”转变为“提升开发效率”。面向对象（OO）技术降低了解决方法域与问题域的差别，提供了良好的复用机制，能够更加有效提高软件开发效率，完全顺应了软件开发技术的发展方向。UML(The Unified Modeling Language,即统一建模语言) 是一个通用的标准建模语言，可以对复杂

36、的系统建立可视化系统模型，目前已经被工业标准组织OMG(Object Management Group)接受，一经推出便得到许多著名计算机厂商如Microsoft,HP,IBM,Oracle等支持，在国际上应用日益广泛。本文通过一个销售管理系统的分析与设计，阐述如何通过UML降低开发难度和提高开发效率。2 销售管理系统的基本特征和功能模块本系统以“订单”为核心，构建出了以“客户”为中心的管理模式。该系统具有以下一些特征：（1） 先进的系统结构，面向销售流程，能适应原有销售工作流程并进行合理的改进，从而更贴近实际的应用；（2） 针对大型企业销售管理人员多，销售管理复杂的特点，通过系统提供的灵活的

37、人员权限设置和全面的财务核算方式，实现真正的销售网络化办公；（3） 在实现订单的电子化、工作流程的数字化同时，帮助公司领导提高决策的科学化水平；（4） 通过对客户信息的管理，实现对客户广告走势和重要客户情况统计和分析。整个系统操作业务人员包括：销售员、销售经理、仓库管理员、审计员、公司销售主管、和系统管理员。各个角色承担不同的系统任务，通过网络和通信系统，连接到销售管理系统，使用统一的访问界面，进行日常的销售业务操作，最终实现销售部门业务的正常运转。3 系统的UML分析与实现UML概述及特点UML是一种编制系统蓝图的标准化语言，可以对大型复杂系统的各种成分可视化说明并构造系统模型，以及建立各种

38、必要的文档。UML通过三类图形建立系统模型：Use Case图，静态结构图（类图，对象图，组件图，配置图）和动态行为图（顺序图，协同图，状态图，活动图），这些图可以从不同抽象角度使系统可视化。UML具有面向对象、可视化、独立与开发过程和程序设计语言以及易于掌握使用等特点。UML适用于各种规模的系统开发，能促进软件复用，方便地集成已有的系统并有效减少开发中的各种风险。UML在销售管理系统中的实际应用UML是一种建模语言，是系统开发的一个组成部分，本身并没有关于开发过程概念的定义和表示符号。UML的创始人 booch,Jacobson和Rum Baugh在rational公司的支持下综合了多种系统

39、开发过程的长处，提出新的面向对象的开发过程，称为Rational统一过程（Rational Unified Process,RUP）。RUP过程的核心工作流程包括：业务建模、需求分析、系统分析与设计和实现、实现、测试和系统部署。下面通过UML来分析并构造销售管理系统模型，并结合Rational统一过程加以描述，图形使用Rational Rose 工具软件绘制。3.1 销售管理系统的业务建模和需求分析业务模型和需求分析的目的是对系统进行评估，采集和分析系统的需求，理解系统要解决的问题，重点是充分考虑系统的实用性。结果可以用一个业务用例（Business Use Case）框图表达，根据销售系统的

40、基本特征和功能可得到 本系统的用例图，如图2。图1 销售管理系统业务用例框图模型中的活动者代表外部与系统交互的单元，包括销售员、销售经理、仓库管理员、审计员、公司销售主管、和系统管理员；业务用例框图是对系统需求的描述，表达了系统的功能和所提供的服务，包括客户管理子系统、订单管理子系统、销售统计子系统、产品管理子系统系统管理子系统。图2是销售管理系统层次的用例模型，只包含了最基本的Use Case模型，是系统的高层抽象。在开发过程中，随着对系统需求认识的不断加深，用例模型可以从顶向下不断细化，演化出更加详细的Use Case模型。 根据系统的用例图，可以对系统的持久对象进行设计，下图是本系统持久

41、对象类及类之间关系图。图2 核心业务对象类及类之间关系3.2 销售管理系统设计系统分析与设计是研究欲采用的实现环境和系统结构，结果是产生一个对象模型，也就是设计模型。设计模型包含了Use Case的实现，可以表现对象如何相互通信和运作来实现Use Case流的。对于系统的静态结构，可以通过类图、对象图、组件图和配置图来描述；对于系统的动态行为，可以通过顺序图、协同图、状态图、活动图描述。这些图在加上说明文档就构成一个完整的设计模型。3.2.1系统架构设计销售管理系统拥有大量销售信息资源，这些资源包括各种客户、订单、和产品等信息。其数据量大、信息变化快，非结构化信息与结构化信息共存。使用UML对

42、销售管理系统进行基于面向对象的分析和实现，可以从开发的第一步开始，从系统的底层就把握住销售信息资源的特征，为下一步具体实现打好基础。在销售管理系统建立模型时要涉及到处理大量的模型元素，如类、进口、组件、节点、图等，可以将语意上相近的模型元素组织在一起，这就构成了UML的包，包从较高的层次来组织管理系统模型。系统主要有以下四个包：（1）用户接口包（ser Interface Package）用户接口包在其他包的顶层次，为系统用户提供访问信息和服务。要注意一点，由于开发工具使用不同，该接口描述也是有区别的。如果采用Java Web开发，就要以JSP(Java Server Pages)为基础，如果

43、采取Microsoft的A开发，其基础就是标准化控件组。本系统在此将使用Java Web开发，下面有关代码的描述都是基于Java的。（2）业务逻辑包(Business Rule Package)该包是销售管理系统业务的核心实现部分，包括客户管理、订单管理、产品管理等，其他包可以通过访问该包提供的接口，实现业务逻辑，如客户管理业务等。（3）数据持久访问包(Data Persistence Package)该包实现数据的持久化，也就是与数据库交互，实现数据的存取、修改等操作。（4）通用工具包（til Package）该包主要包括应用程序安全检查的类，可以为上面三个包提供安全检查，如客户端检查和服务

44、器端业务规则检查等，同时包括一些系统异常检查与抛出处理以及系统日志服务等。3.2.2系统详细设计详细设计主要是描述在系统分析阶段产生的类，与分析阶段类的区别就是偏重于技术层面和类的细节实现。销售管理系统提供的各种服务都是建立在分布、开放的信息结构之上，依托高速、可靠的网络环境来完成的。每项服务都可以看作一个事件流，由若干相关的对象交互合作来完成。对于这种系统内部的协作关系和过程行为，可以通过绘制序列（Sequence）框图和协作（Collaboration）框图来帮助观察和理解。此外，描述工作流和并发行为还可以通过活动框图，表达从一个活动到另一个活动的控制流。同时，可以在理解这些图的基础上，抽

45、象出系统的类图，为系统编码阶段继续细化提供基础。下面以Java Web开发为例，介绍客户管理子系统的详细设计1.客户管理子系统的基本结构建模：下图是客户管理子系统主要类极其关系的详细设计图3 客户关系子系统类的详细设计及类之间关系2.序列图：序列图是一种对象交互图，着重强调了时间序列，而不是静态对象的关系，通过序列图可以清楚地看到“谁在什么时间对谁说了写什么”。图4 客户管理的序列框图图5 销售人员对客户管理的顺序框图图4是一个客户管理的序列框图例子。描述了先加载某个客户；显示某些状态；再更改某些属性值，最后更新数据库状态的一次执行过程。此图可设计Customer类的loadCustomer(

46、int)和updateCustomer()方法实现。通过序列框图可以清晰看出系统用户、客户管理子系统的用户接口、数据库连接模块之间以时间为顺序的消息交换，这对于把握系统的控制流、顺序行为和交互行为是非常有益的。建立在分布网络环境下的销售管理系统的事件流和控制流是非常复杂的，需要从顶层到底层进行一步步分解，用多幅能反映动态结构的图来分析与说明。图5反映了销售人员对客户管理的顺序框图。3.状态图适合描述一个对象穿越多个Use Case的行为。类的状态图表示类的对象可以呈现的状态和这个对象从一种状态到另一种状态的转换。图6 Customer对象状态图图6描述了Customer对象的生命期中可能的状态

47、及状态变化（从创建、更新到消亡的转变过程），其中insertOrder/deleteOrder不是直接作用于当前customer对象，而是指当前customer对象所涉及的订单操作。此例说明其他对象的操作可能改变当前对象的状态。4.协作图：协作图和序列图相似，两种图所表达的是同一种信息，可以将序列图转换为协作图，反之也然。但两者是有区别的，序列图强调的是交互的时间序列，协作图强调的是交互的语境和参与交互的对象的整体组织。下图描述的是查询一个客户信息消息传递的过程。图7、查询客户信息的协作图5.活动图：用于描述业务过程和类的操作，类似与旧流程图，是对业务处理工作流建模，在活动图中可以增加角色的可

48、视化的维数，下图是增加了Customer、Saleman、Warehouse三个角色的系统活动图，反映了在业务处理过程中，每个角色执行的过程。图8 活动图通过框图，设计和开发人员可以确定需要开发的类，类之间的关系和每个类操作和责任。序列框图按照时间排序，用于通过情境检查逻辑流程。协作框图用于了解改变后的影响，可以很容易看出对象之间的通信，状态图描述了对象在系统可能中的状态，如果要改变对象，就可以方便地看到受影响的对象。6.软件系统一般由一组部件组成，换句话说，部件是相对独立的部分软件实施，有自己特有的功能，并可在系统中安装使用，系统中各部件是相互协作合作，给系统提供完整的功能。下图是本系统运行

49、时的主要部件图9 运行的部件图3.2.3销售管理系统的实现、测试和系统配置系统采用五层逻辑结构：客户端只需中文浏览器；表示层用12个JSP(Java Server Page)文档实现动态页面以创建、操作业务对象；核心对象层用6个Java类以JavaBean形式构成业务处理的核心对象；连接层采用JDBC2提供两种连接方式：一种是基于DriverManager，主要支持Java应用和测试；另一种基于DataSource；资源层即数据库服务器。经过系统分析和设计后，就可以根据设计模型在具体的环境中实现系统，生成系统的源代码、可执行程序和相应的软件文档，建立一个可执行系统；进而需要对系统进行测试和排错，保证系统符合预定的要求，获得一个无错的系统实现。测试结果将确认所完成的系统可以真正使用；最后完成系统配置，其任务是在真实的运行环境中配置、调试系统，解决系统正式使用前可能存在的任何问题。4 结束语销售管理系统的发展方兴未艾，目前正处于传统手工、半手工管理向数字化过渡的阶段，转变过程中需要应用和集成最新的信息技术，以达到对网络信息资源最有效的利用和共享。传统的系统分析设计方法难以保证效率和质量，将 UML应用于 销售管理系统的建设，可以加速开发进程，提高代码质量，支持动态的业务需求。从实际效果来看，UML可以保证软件开发的稳定性、鲁棒性，在实际应用中取得良好的效果。