uml业务建模实例分析5545.docx

《uml业务建模实例分析5545.docx》由会员分享，可在线阅读，更多相关《uml业务建模实例分析5545.docx（29页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

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

2、类似的，只是将工作人员换成了ATM。整个银行系统包括了帐户库、银行储户库及ATM系统。许多单个的帐户组成了帐户库。帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。 setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。 getType获取帐户类型，返回类型为char，无参数。

3、setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。 getAccountNumbe获取帐户号，返回类型为int，无参数。 caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。 getBalance获取帐户余额，返回类型为double，无参数。许多银行储户组成了储户库。ATM系统包含了许多ATM机。银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。更多的属性及操作都可以一一加上，使这个类图更详细

4、更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。同样对于一个真正的银行系统，这个类图过于简单。比如帐户类型我们可以先定义一个abstract class，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract class，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达

5、自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。 图5.22 银行行系统类类图5.3顺顺序图图55.3描描述了顾顾客在AATM机机上取款款时信息息的流动动情况。以以时间为为顺序。因因为仅是是示例，所所以整个个过程是是没有出出现任何何故障时时的流程程，并且且只画到到了取款款结束。通通过这个个图，我我们可以以看出消消息是如如何在系系统中不不同对象象之间进进行交互互。通过流流程图我我们可以以很清楚楚地看到到系统是是如何工工作的，系系统各部部分之间间的信息息及控制制是如何何发送的的，整个个流程是是否合理理。流程程图对我我们的设设计起到到了很好好的帮助助作用。注注意在本本图没有有一个生生命线

6、终终端有一一个XX，这这是因为为这个流流程中还还未遇到到有对象象生命结结束。当当有对象象生命结结束时需需在对应应的生命命线终端端画XX，表表明这个个对象在在这时被被销毁。首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来.因为这个顺序图较长，且很清晰，即便是初学者也很容易读懂，在此就不对本图做过多的解释。图5.33 ATTM取款款顺序图图图5.4描述述了顾客客在ATTM机上上进行操操作会经经历的几几种状态态，及各各种状态态之间转转换的条条件。因因为是简简化了的的例子，所所以除了了等待顾顾客插入入磁卡的的起始状状态和结结束服务务的终止

7、止状态，顾顾客会处处于输入入密码、选选择服务务类型、存存款及取取款四种种状态。 插入磁卡卡后进入入输密码码状态，当当密码输输入正确确时进入入选择服服务类型型状态，当当输入密密码不正正确时，停停留在原原状态，但但如果三三次不正正确，服服务结束束。进入入选择服服务类型型后根据据选择的的不同，顾顾客可进进入存款款和取款款状态。存存、取款款结束后后，顾客客既可以以选择结结束服务务到最终终状态，也也可以选选择继续续服务回回到选择择服务类类型状态态。通过状态态图我们们可以无无歧义的的了解各各个活动动角色是是如何在在不同状状况下转转换的，转转换的条条件是什什么，是是否会出出现死锁锁现象，是是否有条条件没考考

8、虑周全全，是否否有状态态无法达达到。状状态图可可以帮助助我们发发现问题题，并及及时改正正。 5.5活活动图图5.55参考了了Ranndy Milllerr的AA Haandss-Onn Inntrooducctioon ffor Devvelooperrs一一文，55.3图图中的客客户管理理和事物物管理对对应于55.5图图中的BBankk，图55.3中中的读卡卡机、显显示、输输入设备备及点钞钞机对应应于5.5图中中的ATTM MMachhinaa，银行行储户就就是Cuustoomerr。初看看活动图图和顺序序图表达达的意义义很接近近。但我我们可以以注意到到顺序图图着重时时间的顺顺序，而而活动图

9、图侧重于于各部分分之间的的相互制制约，对对于一些些并行的的活动能能够有效效的表示示出来。例例如5.5图中中forrk和jjoinn处，我我们可以以很清楚楚的看到到一些并并行活动动的存在在。这个活动动图以顾顾客插入入卡为开开始，以以顾客取取卡结束束。我们们可以看看到活动动图的重重点虽然然不在时时间顺序序，但我我们同样样可以得得到时间间的信息息。 图5.55 ATTM银行行系统活活动图5.6协协作图在第四章章中我们们知道协协作图和和顺序图图是可以以无信息息损失的的相互转转换，只只是它们们的侧重重点是不不一样的的。顺序序图着重重于对象象间消息息传递的的时间顺顺序，协协作图着着重于表表达对象象之间的的

10、静态连连接关系系。图55.6将将5.33图转换换为协作作图。1. 插入ATTM卡2. 接受ATTM卡3. 查询密码码4. 显示输入入密码请请求5. 输入密码码6. 密码传递递7. 请求确认认密码合合法性8. 确认密码码合法性性9. 询问服务务类别10. 显示输入入服务服服务类别别请求11. 输入取款款请求12. 取款请求求 13. 询问取款款数额14. 显示输入入数额请请求15. 输入取款款数额16. 传递取款款数额17. 询问取款款数额确确认18. 显示确认认数额请请求19. 输入确认认20. 传递确认认信息21. 数额合法法性确认认请求22. 确认数额额和法性性23. 出钞请求求24. 计

11、算帐户户余额25. 出钞26. 取钞27. 传递余额额并询问问是否还还需要其其他服务务28. 显示帐户户余额并并提示选选择下面面的服务务 从图上我我们可以以看出协协作图的的角色和和顺序图图的对象象是一一一对应的的，而协协作图上上的各对对象上的的协作关关系和顺顺序图上上的消息息传递是是一一对对应的。 例解基于于UMLL的面向向对象分分析与设设计摘要 本文文以实例例的方式式，展示示了如何何使用UUML进进行面向向对象的的分析与与设计。本本文将假假设读者者对UMML、面面向对象象等领域域的基本本内容已已了然于于胸，所所以将不不会过多多阐述，而而将重点点放在应应用过程程上。本本文的目目的是通通过一个个

12、完整的的实例，展展现基于于UMLL的OOOA&DD过程的的一个简简化模式式，帮助助朋友们们更好的的认识UUML在在OOAA&D中中起的作作用。前前言 经常常听到有有朋友抱抱怨，说说学了UUML不不知该怎怎么用，或或者画了了UMLL却觉得得没什么么作用。其其实，就就UMLL本身来来说，它它只是一一种交流流工具，它它作为一一种标准准化交流流符号，在在OOAA&D过过程中开开发人员员间甚至至开发人人员与客客户之间间传递信信息。另另外，UUML也也可以看看做是OOO思想想的一种种表现形形式，可可以说“OO是是神，而而UMLL是型”。所以以，想用用好UMML，扎扎实的OOO思想想基础是是必不可可少的。然

13、然而，在在UMLL应用到到开发过过程中时时，还是是有一定定的模式式可以遵遵循的。（注注意，是是模式而而不是教教条，我我下面给给出的流流程只是是一个启启发式过过程，而而不是说说一定要要遵循这这个流程程。）下下面，我我们通过过一个CCMS系系统的分分析设计计实例，看看看如何何将UMML应用用到实际际的开发发中。11.从需需求到业业务用例例图 OOOA&DD的第一一步，就就是了解解用户需需求，并并将其转转换为业业务用例例图。我我们的CCMS系系统需求求非常简简单，大大致课做做如下描描述：这这个系统统主要用用来发布布新闻，管管理员只只需要一一个，登登录后可可以在后后台发布布新闻。任任何人可可以浏览览新

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

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

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

17、。所谓业务领域类图要描述一下三点： 1.系统中有哪些实体。 2.这些实体能做什么操作。 3.实体间的关系。 这里要特别强调：这里的实体不是Actor，而是Actor使用系统时使用的所调用的实体，是处在系统边界之内的实体。例如，管理员就没有作为一个实体出现在这里，因为管理员处在系统边界之外，它所有的工作都可以通过调用这三个类的方法完成。并且，这里的“注册会员”实体也不是刚才用例图中注册会员这个Actor，而是作为一个系统内的业务实体，供Actor们使用的。例如，其中的注册功能是给注册会员这个Actor使用，而移除则是给管理员这个Actor使用的。 理解以上这段话非常重要，我经常看到由于混淆了实体

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

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

20、Controller的Login方法启动序列，然后序列按图示步骤执行。其中UserServices作为业务组件，首先调用数据访问组件的GetByName确定用户是否存在，如果存在，再调用GetByNameAndPassword确定输入密码是否是此用户的密码。从而完成业务功能。 要注意，序列图在实际中是很多的，几乎每个类方法都配有相应的序列图。8.后面的步骤 在完成了上面的过程后，就可以进行编码、调试、测试等工作了。但这些已经超出了本文讨论的范围。总结 本文简要给出了使用UML进行OOA&D的过程。当然，由于示例较小，而且本人水平有限，所以给出的相关内容可能不是很准确。而且软件分析设计本来就不是

21、一个固定模式的过程，随着系统的不同整个过程会有变化。本文只是想起到一个抛砖引玉的作用，让朋友们大致了解UML的使用流程。至于实际的分析设计，还需要深入的学习和实践的积累。UML业业务建模模实例分分析作者: 范里程程 出处处:软件件世界对于大中型信息系统，很难直接进行需求分析设计，需要借助模型来分析设计系统，根据系统调研数据，建立起目标系统的逻辑模型。 在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中越来越多的人认识到它是整个过程中最为关键的一个过程。假如在需求分析时分析者们未能正确地认识到客户的需求的话，那么最后的软件实际上不可能达到客户的要求

22、，或者导致需求的频繁变更，而软件无法在规定的时间里完工。 在需求分析阶段，要对经过可行性分析所确定的系统目标和功能作进一步的详细论述，确定系统“做什么？”的问题，最终建立起目标系统的逻辑模型。 首先是获得当前系统的物理模型。物理模型是对当前系统的真实写照，可能是一个由人工操作的过程，也可能是一个已有的但需要改进的计算机系统。首先是要对现行系统进行分析、理解，了解它的组织情况、数据流向、输入输出，资源利用情况等，在分析的基础上画出它的物理模型。然后抽象出当前系统的逻辑模型。 逻辑模型是在物理模型基础上，去掉一些次要的因素，建立起反映系统本质的逻辑模型。接下来建立目标系统的逻辑模型。通过分析目标系

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

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

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

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

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

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

29、、查询、删除的功能。 10.条目信息维护：提供书刊条目的录入、修改、查询、删除的功能。 11.系统信息维护：提供对系统的参数的设置。 12.登录：管理员需要先登录才能进入系统。 并且，可以画出如下系统用例图： 通过用例图，可以对系统功能有一个大概的了解，对于复杂系统，我们可以结合IDEF方法，通过分层分解，逐步细化的方法来描述系统的功能。对于用例图，建议不要画的过于复杂，特别是用例之间的关系，因为复杂的用例图不仅不能让需求分析人员与客户之间更好的沟通，反而是制造了一种沟通障碍。 下一步就是编制每一个用例的详细说明，对用例说明的主要信息包括有：用例名称、编号、用例的简短描述、用例的参与者、与其他

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

31、。 为了让系统设计能够以结构、组织方式和代码重用的形式表现出来，要对系统进行设计规划，设计阶段应该与分析阶段交迭。需求是不断地发展，而设计本身也会推动需求的发展(反之亦然) 。在图书馆管理系统的建模设计中，以下3个方面的问题是要关注的：业务对象的表示、业务服务的实现、用户界面的组织。 业务对象的表示 在图书馆管理系统系统中，业务对象主要是数据库和数据实体类的表示方式。建模时，可以构造出系统的静态模型，也就是系统类图来表示。如下图则描述了借书这一用例的静态结构图。为了体现类之间的关系，在下图中没有显示出每一个类的属性和基本操作。 业务服务的实现 业务服务的实现需要完成的功能是各种业务规则和逻辑的

32、实现,如借书处理的业务逻辑。每个模块的信息录入、修改、删除、查询等。业务规则和逻辑的实现基本相似，没有太多的规律可循。采用UML来进行业务服务的建模，可以使用UML 的序列图、状态图、活动图。这个部分的工作,通常通过一系列的类之间的交互来完成。为了在更动态的层面上描述系统，UML 提供了许多其他类型的图。 对于B/S系统设计而言，情节图(Scenario Diagram) 特别有用。情节图分成两种：协作图(Collaboration Diagram) ，序列图(Sequence Diagram) 。UML 建模工具Rational Rose 能够从协作图生成序列图也可以从序列图生成协作图。例如

33、，借阅书刊的业务过程可以采用如下序列图来描述： 借阅书刊过程主要包括：管理员选择“借阅书刊”菜单，弹出对话框，管理员输入书刊信息和用户信息，系统查找数据库，是否存在该种物理书刊，如果不存在，显示提示信息，用例结束;是否存在借阅者信息，如果不存在，显示提示信息，用例结束;否则，管理员单击确认按钮后，该图书借阅给该借阅者，系统存储借阅信息到数据库。 用户界面的组织 用户界面布局图能够帮助组织系统页面、文件、服务的布局结构。在UML 中，对于页面和文件的组织，可以使用构件图(Component Diagram) 或类图(Class Diagram) 建模型。本系统中使用类图对界面组织建模，页面结构以

34、及各种业务服务被捆绑到不同的区域。 在 UML 中，系统的体系结构使用部署图(DeploymentDiagram) 来完成。应用部署的规划对于规划整个B/ S 系统是很有用的。它确定了一种有效的应用部署的规划组织方式,还可以作为一个模式在多个类似B/ S 系统上应用。 在建模完成后，开发人员利用一些UML Case工具如Rational ROSE生成程序代码框架，并对代码框架进行修改和补充，形成完整代码;而且，还可根据代码逆向生成 UML模型。这就较好地保证了模型与代码的一致性。 测试必须在整个项目周期中进行，对每个阶段都要用所建立的模型进行测试，这样才能保证开发的质量，减少开发的风险。 统一

35、建模语言 UML 是国际软件工程领域具有划时代意义的重要成果，适用于以面向对象技术来描述任何类型的系统，而且适用于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。软件系统的规模越来越大，复杂度不断提高，RUP迭代式增量开发方式可以降低风险，同时可以适应需求变化的需要。 在本次UML实践之旅中，我们通过对图书馆管理系统的需求进行分析，将 UML 应用于系统开发的各个阶段，建立了系统的需求模型、静态模型和动态模型，同时遵循Rationl统一过程(RUP)的核心思想和基本原则，采用以用例为驱动、以体系构架为核心的迭代化面向对象分析和设计过程。 图1：系统用例图图2：用况活动图图3：借书

36、部分的类结构图UML行为图用况图（use case diagram）描述了一组用况和参与者（一种特殊的类）以及它们之间的关系。 交互图（interaction diagram）是顺序图和协作图的统称。 顺序图(sequence diagram)是强调消息的时间次序的交互图。 协作图(collaboration diagram)是强调收发消息的对象的结构组织的交互图。 状态图显示了一个由状态，转换，事件和活动组成的状态机。 活动图显示了系统中从活动到活动的流。 UML实实例：销销售管理理系统的的UMLL分析与与设计 作者者：王文文豪|转贴自自：UMML软件件工程组组织|点击数数：15553|更新

37、时时间：220066-8-29|文章录录入：aadmiin 摘 要 销售管理系统是现代企业管理系统的一个重要组成部分，传统的系统分析设计方法已经难以保证软件开发的效率和质量，通过将UML应用于销售管理系统建模，可以加速软件开发进程，提高软件质量，支持动态的业务需求，并方便地集成已有的企业管理资源。 关键词 销售管理系统；UML；分析；实现1 引言当前社会对信息系统的需求日益增长，需求变化也越来越快，软件开发的技术发展方向已经从“提升被开发系统的执行效率”转变为“提升开发效率”。面向对象（OO）技术降低了解决方法域与问题域的差别，提供了良好的复用机制，能够更加有效提高软件开发效率，完全顺应了软件

38、开发技术的发展方向。UML(The Unified Modeling Language,即统一建模语言) 是一个通用的标准建模语言，可以对复杂的系统建立可视化系统模型，目前已经被工业标准组织OMG(Object Management Group)接受，一经推出便得到许多著名计算机厂商如Microsoft,HP,IBM,Oracle等支持，在国际上应用日益广泛。本文通过一个销售管理系统的分析与设计，阐述如何通过UML降低开发难度和提高开发效率。2 销售管理系统的基本特征和功能模块本系统以“订单”为核心，构建出了以“客户”为中心的管理模式。该系统具有以下一些特征：（1） 先进的系统结构，面向销售流

39、程，能适应原有销售工作流程并进行合理的改进，从而更贴近实际的应用；（2） 针对大型企业销售管理人员多，销售管理复杂的特点，通过系统提供的灵活的人员权限设置和全面的财务核算方式，实现真正的销售网络化办公；（3） 在实现订单的电子化、工作流程的数字化同时，帮助公司领导提高决策的科学化水平；（4） 通过对客户信息的管理，实现对客户广告走势和重要客户情况统计和分析。整个系统操作业务人员包括：销售员、销售经理、仓库管理员、审计员、公司销售主管、和系统管理员。各个角色承担不同的系统任务，通过网络和通信系统，连接到销售管理系统，使用统一的访问界面，进行日常的销售业务操作，最终实现销售部门业务的正常运转。3

40、系统的UML分析与实现UML概述及特点UML是一种编制系统蓝图的标准化语言，可以对大型复杂系统的各种成分可视化说明并构造系统模型，以及建立各种必要的文档。UML通过三类图形建立系统模型：Use Case图，静态结构图（类图，对象图，组件图，配置图）和动态行为图（顺序图，协同图，状态图，活动图），这些图可以从不同抽象角度使系统可视化。UML具有面向对象、可视化、独立与开发过程和程序设计语言以及易于掌握使用等特点。UML适用于各种规模的系统开发，能促进软件复用，方便地集成已有的系统并有效减少开发中的各种风险。UML在销售管理系统中的实际应用UML是一种建模语言，是系统开发的一个组成部分，本身并没有

41、关于开发过程概念的定义和表示符号。UML的创始人 booch,Jacobson和Rum Baugh在rational公司的支持下综合了多种系统开发过程的长处，提出新的面向对象的开发过程，称为Rational统一过程（Rational Unified Process,RUP）。RUP过程的核心工作流程包括：业务建模、需求分析、系统分析与设计和实现、实现、测试和系统部署。下面通过UML来分析并构造销售管理系统模型，并结合Rational统一过程加以描述，图形使用Rational Rose 工具软件绘制。3.1 销售管理系统的业务建模和需求分析业务模型和需求分析的目的是对系统进行评估，采集和分析系统

42、的需求，理解系统要解决的问题，重点是充分考虑系统的实用性。结果可以用一个业务用例（Business Use Case）框图表达，根据销售系统的基本特征和功能可得到 本系统的用例图，如图2。图1 销售管理系统业务用例框图模型中的活动者代表外部与系统交互的单元，包括销售员、销售经理、仓库管理员、审计员、公司销售主管、和系统管理员；业务用例框图是对系统需求的描述，表达了系统的功能和所提供的服务，包括客户管理子系统、订单管理子系统、销售统计子系统、产品管理子系统系统管理子系统。图2是销售管理系统层次的用例模型，只包含了最基本的Use Case模型，是系统的高层抽象。在开发过程中，随着对系统需求认识的不

43、断加深，用例模型可以从顶向下不断细化，演化出更加详细的Use Case模型。 根据系统的用例图，可以对系统的持久对象进行设计，下图是本系统持久对象类及类之间关系图。图2 核心业务对象类及类之间关系3.2 销售管理系统设计系统分析与设计是研究欲采用的实现环境和系统结构，结果是产生一个对象模型，也就是设计模型。设计模型包含了Use Case的实现，可以表现对象如何相互通信和运作来实现Use Case流的。对于系统的静态结构，可以通过类图、对象图、组件图和配置图来描述；对于系统的动态行为，可以通过顺序图、协同图、状态图、活动图描述。这些图在加上说明文档就构成一个完整的设计模型。3.2.1系统架构设计

44、销售管理系统拥有大量销售信息资源，这些资源包括各种客户、订单、和产品等信息。其数据量大、信息变化快，非结构化信息与结构化信息共存。使用UML对销售管理系统进行基于面向对象的分析和实现，可以从开发的第一步开始，从系统的底层就把握住销售信息资源的特征，为下一步具体实现打好基础。在销售管理系统建立模型时要涉及到处理大量的模型元素，如类、进口、组件、节点、图等，可以将语意上相近的模型元素组织在一起，这就构成了UML的包，包从较高的层次来组织管理系统模型。系统主要有以下四个包：（1）用户接口包（ser Interface Package）用户接口包在其他包的顶层次，为系统用户提供访问信息和服务。要注意一

45、点，由于开发工具使用不同，该接口描述也是有区别的。如果采用Java Web开发，就要以JSP(Java Server Pages)为基础，如果采取Microsoft的A开发，其基础就是标准化控件组。本系统在此将使用Java Web开发，下面有关代码的描述都是基于Java的。（2）业务逻辑包(Business Rule Package)该包是销售管理系统业务的核心实现部分，包括客户管理、订单管理、产品管理等，其他包可以通过访问该包提供的接口，实现业务逻辑，如客户管理业务等。（3）数据持久访问包(Data Persistence Package)该包实现数据的持久化，也就是与数据库交互，实现数据的

46、存取、修改等操作。（4）通用工具包（til Package）该包主要包括应用程序安全检查的类，可以为上面三个包提供安全检查，如客户端检查和服务器端业务规则检查等，同时包括一些系统异常检查与抛出处理以及系统日志服务等。3.2.2系统详细设计详细设计主要是描述在系统分析阶段产生的类，与分析阶段类的区别就是偏重于技术层面和类的细节实现。销售管理系统提供的各种服务都是建立在分布、开放的信息结构之上，依托高速、可靠的网络环境来完成的。每项服务都可以看作一个事件流，由若干相关的对象交互合作来完成。对于这种系统内部的协作关系和过程行为，可以通过绘制序列（Sequence）框图和协作（Collaboratio

47、n）框图来帮助观察和理解。此外，描述工作流和并发行为还可以通过活动框图，表达从一个活动到另一个活动的控制流。同时，可以在理解这些图的基础上，抽象出系统的类图，为系统编码阶段继续细化提供基础。下面以Java Web开发为例，介绍客户管理子系统的详细设计1.客户管理子系统的基本结构建模：下图是客户管理子系统主要类极其关系的详细设计图3 客户关系子系统类的详细设计及类之间关系2.序列图：序列图是一种对象交互图，着重强调了时间序列，而不是静态对象的关系，通过序列图可以清楚地看到“谁在什么时间对谁说了写什么”。图4 客户管理的序列框图图5 销售人员对客户管理的顺序框图图4是一个客户管理的序列框图例子。描述了先加载某个客户；显示某些状态；再更改某些属性值，最后更新数据库状态的一次执行过程。此图可设计Customer类的loadCustomer(int)和updateCustomer()方法实现。通过序列框图可以清晰看出系统用户、客户管理子系统的用户接口、数据