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方法启动序列，然后序列按图示步骤