uml业务建模实例分析.docx
《uml业务建模实例分析.docx》由会员分享，可在线阅读，更多相关《uml业务建模实例分析.docx（30页珍藏版）》请在冰豆网上搜索。
uml业务建模实例分析
UML业务建模实例分析
在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。
我们在日常生活中也经常和ATM打交道。
本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。
5.1用例图
参与者"银行储户"和ATM机。
简化后的ATM机仅有取款、存款及其余功能。
其余功能不做详细说明。
图5.1自动取款机（ATM）系统用例图
银行储户在ATM机上完成取款、存款及其他业务。
5.2类图
图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。
整个银行系统包括了帐户库、银行储户库及ATM系统。
许多单个的帐户组成了帐户库。
帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。
六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。
setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。
getType获取帐户类型，返回类型为char，无参数。
setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。
getAccountNumbe获取帐户号，返回类型为int，无参数。
caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。
getBalance获取帐户余额，返回类型为double，无参数。
许多银行储户组成了储户库。
ATM系统包含了许多ATM机。
银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。
同样对于一个真正的银行系统，这个类图过于简单。
比如帐户类型我们可以先定义一个abstractclass，它包含一个帐户最基本的属性及操作。
而有些操作先定义为abstract，如余额的计算。
然后再继承这个abstractclass，我们可以有savingaccount和checkingaccount等等。
不同的帐户有不同的余额计算方法，我们可以加上具体的算法。
对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如savingaccount在存款达到多少时可以享受机票打折的优惠。
通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。
图5.2银行系统类图
5.3顺序图
图5.3描述了顾客在ATM机上取款时信息的流动情况。
以时间为顺序。
因为仅是示例，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。
通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。
通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。
流程图对我们的设计起到了很好的帮助作用。
注意在本图没有一个生命线终端有一个"X"，这是因为这个流程中还未遇到有对象生命结束。
当有对象生命结束时需在对应的生命线终端画"X"，表明这个对象在这时被销毁。
首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来…..因为这个顺序图较长，且很清晰，即便是初学者也很容易读懂，在此就不对本图做过多的解释。
图5.3ATM取款顺序图
图5.4描述了顾客在ATM机上进行操作会经历的几种状态，及各种状态之间转换的条件。
因为是简化了的例子，所以除了等待顾客插入磁卡的起始状态和结束服务的终止状态，顾客会处于输入密码、选择服务类型、存款及取款四种状态。
插入磁卡后进入输密码状态，当密码输入正确时进入选择服务类型状态，当输入密码不正确时，停留在原状态，但如果三次不正确，服务结束。
进入选择服务类型后根据选择的不同，顾客可进入存款和取款状态。
存、取款结束后，顾客既可以选择结束服务到最终状态，也可以选择继续服务回到选择服务类型状态。
通过状态图我们可以无歧义的了解各个活动角色是如何在不同状况下转换的，转换的条件是什么，是否会出现死锁现象，是否有条件没考虑周全，是否有状态无法达到。
状态图可以帮助我们发现问题，并及时改正。
5.5活动图
图5.5参考了RandyMiller的《AHands-OnIntroductionforDevelopers》一文，5.3图中的客户管理和事物管理对应于5.5图中的Bank，图5.3中的读卡机、显示、输入设备及点钞机对应于5.5图中的ATMMachina，银行储户就是Customer。
初看活动图和顺序图表达的意义很接近。
但我们可以注意到顺序图着重时间的顺序，而活动图侧重于各部分之间的相互制约，对于一些并行的活动能够有效的表示出来。
例如5.5图中fork和join处，我们可以很清楚的看到一些并行活动的存在。
这个活动图以顾客插入卡为开始，以顾客取卡结束。
我们可以看到活动图的重点虽然不在时间顺序，但我们同样可以得到时间的信息。
图5.5ATM银行系统活动图
5.6协作图
在第四章中我们知道协作图和顺序图是可以无信息损失的相互转换，只是它们的侧重点是不一样的。
顺序图着重于对象间消息传递的时间顺序，协作图着重于表达对象之间的静态连接关系。
图5.6将5.3图转换为协作图。
1.插入ATM卡
2.接受ATM卡
3.查询密码
4.显示输入密码请求
5.输入密码
6.密码传递
7.请求确认密码合法性
8.确认密码合法性
9.询问服务类别
10.显示输入服务服务类别请求
11.输入取款请求
12.取款请求
13.询问取款数额
14.显示输入数额请求
15.输入取款数额
16.传递取款数额
17.询问取款数额确认
18.显示确认数额请求
19.输入确认
20.传递确认信息
21.数额合法性确认请求
22.确认数额和法性
23.出钞请求
24.计算帐户余额
25.出钞
26.取钞
27.传递余额并询问是否还需要其他服务
28.显示帐户余额并提示选择下面的服务
从图上我们可以看出协作图的角色和顺序图的对象是一一对应的，而协作图上的各对象上的协作关系和顺序图上的消息传递是一一对应的。
例解基于UML的面向对象分析与设计
摘要
本文以实例的方式，展示了如何使用UML进行面向对象的分析与设计。
本文将假设读者对UML、面向对象等领域的基本内容已了然于胸，所以将不会过多阐述，而将重点放在应用过程上。
本文的目的是通过一个完整的实例，展现基于UML的OOA&D过程的一个简化模式，帮助朋友们更好的认识UML在OOA&D中起的作用。
前言
经常听到有朋友抱怨，说学了UML不知该怎么用，或者画了UML却觉得没什么作用。
其实，就UML本身来说，它只是一种交流工具，它作为一种标准化交流符号，在OOA&D过程中开发人员间甚至开发人员与客户之间传递信息。
另外，UML也可以看做是OO思想的一种表现形式，可以说“OO是神，而UML是型”。
所以，想用好UML，扎实的OO思想基础是必不可少的。
然而，在UML应用到开发过程中时，还是有一定的模式可以遵循的。
（注意，是模式而不是教条，我下面给出的流程只是一个启发式过程，而不是说一定要遵循这个流程。
）下面，我们通过一个CMS系统的分析设计实例，看看如何将UML应用到实际的开发中。
1.从需求到业务用例图
OOA&D的第一步，就是了解用户需求，并将其转换为业务用例图。
我们的CMS系统需求非常简单，大致课做如下描述：
这个系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。
任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。
管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。
通过以上需求描述，我们画出如下的业务用例图：
这里要注意三点：
1.业务用例是仅从系统业务角度关注的用例，而不是具体系统的用例。
它描述的是“该实现什么业务”，而不是“系统该提供什么操作”。
例如，在实际系统中，“登录”肯定要作为一个用例，但是这是软件系统中的操作，而用户所关注的业务是不包含“登录”的。
2.业务用例仅包含客户“感兴趣”的内容。
3.业务用例所有的用例名应该让客户能看懂，如果某个用例的名字客户看不懂什么意思，它也许就不适合作为业务用例。
2.从业务用例图到活动图
完成了业务用例图后，我们要为每一个业务用例绘制一幅活动图。
活动图描述了这个业务用例中，用户可能会进行的操作序列。
活动图有个很重要的使命：
从业务用例分析出系统用例。
例如，下面是“新闻管理”的活动图：
可以看到，一个“新闻管理”这个业务用例，分解出N多系统操作。
这里要特别注意这些操作，其中很多“活动”都很可能是一个系统用例（当然，不是每个都是）。
例如，由这个活动图可以看出，系统中至少要包含以下备选系统用例：
登录、注销登录、查看新闻列表、修改新闻、删除新闻。
这样，将每个业务用例都绘制出相应的活动图，再将其中的“活动”整合，就得出所有备选系统用例。
3.从活动图到系统用例图
找出所有的备选系统用例后，我们要对他们进行合并和筛选。
合并就是将相同的用例合并成一个，筛选就是将不符合系统用例条件的备选用例去掉。
一个系统用例应该是实际使用系统的用户所进行的一个操作，例如，“查看新闻列表”就不能算一个系统用例，因为他只是某系统用例的一个序列项。
最终我们得出的系统用例图如下：
4.从系统用例图到用例规约
得出系统用例图后，我们应该对每一个系统用例给出用例规约。
关于用例规约，没有一个通用的格式，大家可以按照习惯的格式进行编写。
对用例规约唯一的要求就是“清晰易懂”。
下面给出“登录”这个系统用例的一个规约：
5.绘制业务领域类图
完成了上面几步，下面应该是绘制业务领域类图了。
所谓业务领域类图要描述一下三点：
1.系统中有哪些实体。
2.这些实体能做什么操作。
3.实体间的关系。
这里要特别强调：
这里的实体不是Actor，而是Actor使用系统时使用的所调用的实体，是处在系统边界之内的实体。
例如，管理员就没有作为一个实体出现在这里，因为管理员处在系统边界之外，它所有的工作都可以通过调用这三个类的方法完成。
并且，这里的“注册会员”实体也不是刚才用例图中注册会员这个Actor，而是作为一个系统内的业务实体，供Actor们使用的。
例如，其中的注册功能是给注册会员这个Actor使用，而移除则是给管理员这个Actor使用的。
理解以上这段话非常重要，我经常看到由于混淆了实体和Actor的关系而导致画出的领域类图不准确或职责分配不准确。
大家可能还注意到，我们这里没有给出每个实体的属性。
其实，在领域分析阶段，实体的属性并不重要，重要的是找出实体的操作。
6.绘制实现类图
以上这几步，就是分析的过程。
而下面的步骤就是设计了。
设计没有分析那么好描述，因为分析是“客户面”，它只关心系统本身的功能和业务，而不关心任何和计算机有关的东西。
但是，设计和平台、语言、开发模型等内容关系紧密，因而很难找出一个一致的过程。
但是，一般在设计过程中实现类图是要绘制的。
实现类图和领域类图不一样，它描述的是真正系统的静态结构，是和最后的代码完全一致的。
因此，它和平台关系密切，必须准确给出系统中的实体类、控制类、界面类、接口等元素以及其中的关系。
因此，实现类图是很复杂的，而且是平台技术有关的。
所以，我在这里不可能给出一个准确的实现类图，不过为了描述，我还是给出一个简化了的实现类图，当然，它是不准确的，而只是从形式上给出实现类图的样子。
我们假设这个系统建构于.NET3.5平台上，并且使用ASP.NETMVC作为表示层，整体使用三层架构。
那么，用户模块体系的实现类图大体是这样子（不准确）：
7.绘制序列图
有了静态结构，我们还要给出动态结构，这样，才能看清系统间的类是如何交互的，从而有效帮助程序员进行编码工作。
上图给出的是用户登录的序列图。
首先注册会员作为Actor，调用UserController的Login方法启动序列，然后序列按图示步骤执行。
其中UserServices作为业务组件，首先调用数据访问组件的GetByName确定用户是否存在，如果存在，再调用GetByNameAndPassword确定输入密码是否是此用户的密码。
从而完成业务功能。
要注意，序列图在实际中是很多的，几乎每个类方法都配有相应的序列图。
8.后面的步骤
在完成了上面的过程后，就可以进行编码、调试、测试等工作了。
但这些已经超出了本文讨论的范围。
总结
本文简要给出了使用UML进行OOA&D的过程。
当然，由于示例较小，而且本人水平有限，所以给出的相关内容可能不是很准确。
而且软件分析设计本来就不是一个固定模式的过程，随着系统的不同整个过程会有变化。
本文只是想起到一个抛砖引玉的作用，让朋友们大致了解UML的使用流程。
至于实际的分析设计，还需要深入的学习和实践的积累。
UML业务建模实例分析
作者:
范里程出处:
软件世界
对于大中型信息系统，很难直接进行需求分析设计，需要借助模型来分析设计系统，根据系统调研数据，建立起目标系统的逻辑模型。
在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中越来越多的人认识到它是整个过程中最为关键的一个过程。
假如在需求分析时分析者们未能正确地认识到客户的需求的话，那么最后的软件实际上不可能达到客户的要求，或者导致需求的频繁变更，而软件无法在规定的时间里完工。
在需求分析阶段，要对经过可行性分析所确定的系统目标和功能作进一步的详细论述，确定系统“做什么？
”的问题，最终建立起目标系统的逻辑模型。
首先是获得当前系统的物理模型。
物理模型是对当前系统的真实写照，可能是一个由人工操作的过程，也可能是一个已有的但需要改进的计算机系统。
首先是要对现行系统进行分析、理解，了解它的组织情况、数据流向、输入输出，资源利用情况等，在分析的基础上画出它的物理模型。
然后抽象出当前系统的逻辑模型。
逻辑模型是在物理模型基础上，去掉一些次要的因素，建立起反映系统本质的逻辑模型。
接下来建立目标系统的逻辑模型。
通过分析目标系统与当前系统在逻辑上的区别，建立符合用户需求的目标系统的逻辑模型。
最后补充目标系统的逻辑模型。
对目标系统进行补充完善,将一些次要的因素补充进去，例如出错处理等。
UML（TheUnifiedModelingLanguage，即统一建模语言）是一种编制系统蓝图的标准化语言，可以对复杂的系统建立可视化的系统模型，目前已经被工业标准化组织OMG（ObjectManagementGroup）接受，一经推出便得到许多著名的计算机厂商如Microsoft、HP、IBM、Oracle等的支持，也在逐步开始应用到需求分析过程中。
在使用UML建立当前系统逻辑模型过程中，初学者通常会遇到一些问题：
1.什么时候真正需要业务模型？
什么时候用例模型独立存在？
2.在进行精确的业务建模时能用哪些UML图形？
如何知道是否用顺序图或者交互图？
3.业务模型如何涉及到其他模型（如领域模型，用例模型等等）呢？
如何有机地组织这些模型？
本文将通过图书馆管理系统这个简单而典型的实例来进行一次UML需求分析实践之旅。
许多读者对图书馆图书管理工作比较熟悉，主要是围绕读者、图书和工作人员的借还书展开工作。
我们先看看图书馆工作人员和部分读者的需求。
读者来图书馆借书，可能先查询书库的图书记录。
查询可以按书名、作者、图书编号、关键字查询。
查询有两种结果，如果查到则记下书号，交给工作人员，然后等候办理借书手续。
如果该书已经被全部借出，则可做借书登记，等待有书时被通知。
如果图书馆没有该书的记录，则做缺书登记。
办理借书手续时先要出示图书证，没有图书证则去申请图书证。
如果借书数量超出规定，则提示“借书数量超限，不能继续借阅”。
工作人员登记借阅人信息、借阅的图书信息、借出时间和应还书时间。
系统自动修改书库的图书记录、读者库信息。
当一位读者还书时，工作人员根据图书证编号，找到读者的借书信息，查看是否超期，如果已经超期，则进行超期处罚。
如果图书有破损、丢失，则进行破损处罚。
清除借阅记录，同时系统自动查看是否有等待借阅登记，如果有则发出通知，修改书库记录，该书设置为已预订状态，否则设置为可借状态。
图书采购人员进行图书采购时，要参考各类图书的库存数和借阅率，注意合理采购。
如果有缺书登记则随时进行采购。
正在采购的图书组成一个采购中书库。
采购到货后，进行验收，编号，同时加入图书库，修改采购中书库，并且查看订阅库，发出到书通知，并且已经修改书库的图书记录为已预订状态。
借书登记是当欲借的书被借空后，读者自愿选择的一种操作，它应该记录读者名和联系方式，一旦有这本书后可通知读者。
到书通知，当读者预订的书来到之后，按照读者给出的联系方式发出通知。
缺书登记是当读者需要的书库内查询没有记录时，将此信息转入缺货库，通知采购员采购。
图书注销，如果图书丢失或旧书淘汰，则将该书从书库中清除。
根据需求描述整理一张需求表：
需求分析时首先要识别出系统的参与者，在简单的图书馆管理系统中，可以划分出两种参与者：
读者和管理员。
当然，根据业务的复杂程度，参与者也可以进行细分，比如读者可以再分为学生读者、教师读者、校外读者，管理员根据业务和权限的不同可以再细分为库房管理员、借还书操作员、系统维护人员、图书馆管理人员等不同角色。
在这里，为了简化处理，我们只列出了读者和管理员。
对参与者描述如下：
（1）读者
描述：
读者可以借阅、预定、归还物理书刊，可以对书籍和个人信息进行查询，可以取消预定，可以提出办卡申请。
示例：
持有借阅卡的任何人和组织。
（2）管理员
描述：
图书管理员对系统进行维护，包括读者信息的创建、修改、删除，书刊信息的维护，条目信息的维护，还有系统信息的维护。
示例：
图书管理员。
通过识别的参与者，对需求进一步分析，将业务需求进行分解，获得每个参与者的使用用例。
在本例中，我们可以得到以下用例：
1.书籍借出：
提供借阅物理书刊的功能。
2.书籍归还：
提供归还物理书刊的功能。
3.读者办卡：
提供为读者办理借阅卡的功能。
4.预定书刊：
提供对某一个种类的书刊的预约功能。
5.取消预定：
提供对预定进行取消的功能。
6.书籍查询：
为读者提供网上的书籍查询功能。
7.信息查询：
为读者提供信息查询的功能。
8.读者信息维护：
提供读者信息的录入、修改、查询、删除的功能。
9.书刊信息维护：
提供物理书刊的录入、修改、查询、删除的功能。
10.条目信息维护：
提供书刊条目的录入、修改、查询、删除的功能。
11.系统信息维护：
提供对系统的参数的设置。
12.登录：
管理员需要先登录才能进入系统。
并且，可以画出如下系统用例图：
通过用例图，可以对系统功能有一个大概的了解，对于复杂系统，我们可以结合IDEF方法，通过分层分解，逐步细化的方法来描述系统的功能。
对于用例图，建议不要画的过于复杂，特别是用例之间的关系，因为复杂的用例图不仅不能让需求分析人员与客户之间更好的沟通，反而是制造了一种沟通障碍。
下一步就是编制每一个用例的详细说明，对用例说明的主要信息包括有：
用例名称、编号、用例的简短描述、用例的参与者、与其他用例的管理、用例启动的前提条件、用例结束后的事后条件、用例的输入、输出、用例的执行事件流等。
在实际项目中，我们并不一定要面面俱到，而是根据实际情况对用例描述进行裁减。
其中有几点重要信息是不能裁减的：
用例名称、描述、输入、输出、执行事件流、参与者。
另外，如果实际情况需要，还可以使用MSVisio等工具画出界面的示意图来。
如上例所述，我们对每一个用例都进行详细的描述，建立当前系统的功能用例模型。
需求沟通与分析是一个迭代的过程，通过与用户的不断沟通，最终达成对目标系统的一致理解。
如果用户确认了需求分析的成果，一般是需求规格说明书之后，项目开始进入系统分析设计阶段，也就是开始构造目标系统的逻辑模型。
为了让系统设计能够以结构、组织方式和代码重用的形式表现出来，要对系统进行设计规划，设计阶段应该与分析阶段交迭。
需求是不断地发展，而设计本身也会推动需求的发展（反之亦然）。
在图书馆管理系统的建模设计中，以下3个方面的问题是要关注的：
业务对象的表示、业务服务的实现、用户界面的组织。
业务对象的表示
在图书馆管理系统系统中，业务对象主要是数据库和数据实体类的表示方式。
建模时，可以构造出系统的静态模型，也就是系统类图来表示。
如下图则描述了借书这一用例的静态结构图。
为了体现类之间的关系，在下图中没有显示出每一个类的属性和基本操作。
业务服务的实现
业务服务的实现需要完成的功能是各种业务规则和逻辑的实现,如借书处理的业务逻辑。
每个模块的信息录入、修改、删除、查询等。
业务规则和逻辑的实现基本相似，没有太多的规律可循。
采用UML来进行业务服务的建模，可以使用UML的序列图、状态图、活动图。
这个部分的工作,通常通过一系列的类之间的交互来完成。
为了在更动态的层面上描述系统，UML提供了许多其他类型的图。
对于B/S系统设计而言，情节图（ScenarioDiagram）特别有用。
情节图分成两种：
协作图（CollaborationDiagram），序列图（SequenceDiagram）。
UML建模工具RationalRose能够从协作图生成序列图也可以从序列图生成协作图。
例如，借阅书刊的业务过程可以采用如下序列图来描述：
借阅书刊过程主要包括：
管理员选择“借阅书刊”菜单，弹出对话框，管理员输入书刊信息和用户信息，系统查找数据库，是否存在该种物理书刊，如果不存在，显示提示信息，用例结束;是否存在借阅者信息，如果不存在，显示提示信息，用例结束;否则，管理员单击确认按钮后，该图书借阅给该借阅者，系统存储借阅信息到数据库。
用户界面的组织
用户界面布局图能够帮助组织系统页面、文件、服务的布局结构。
在UML中，对于页面和文件的组织，可以使用构件图（ComponentDiagram）或类图（ClassDiagram）建模型。
本系统中使用类图对界面组织建模，页面结构以及各种业务服务被捆绑到不同的区域。
在UML中，系统的体系结构使用部署图（DeploymentDiagram）来完成。
应用部署的规划对于规划整个B/S系统是很有用的。
它确定了一种有效的应用部署的规划组织方式,还
升级会员 