uml业务建模实例分析.docx

《uml业务建模实例分析.docx》由会员分享，可在线阅读，更多相关《uml业务建模实例分析.docx（27页珍藏版）》请在第一文库网上搜索。

1、um1业务建模实例分析银行储户在ATM机上完成取款、存款及其他业务。5.2 类图图5.2所示的银行系统类图与图3.5是类似的，只是将工作人员换成了ATM。整个银行系统包含了帐户库、银行储户库及ATM系统。许多单个的帐户构成了帐户库。帐户具有帐户类型、帐户号、余额三个属性，均为PriVate,其类型分别为Char,int,doub1e。六个操作分别为setType、getTypexgetAccountNumbevSetACCOUntNUmbe、CacuIateBaIancevgetBa1ance,除CacuIateBaIance为protected其余均为pubIicoSetTyPe设置帐户类型

2、，返回类型为Void,参数类型为Char,输入帐户类型。getType获取帐户类型，返回类型为Char,无参数。SetACCOUntNumbe设置帐户号，返回类型为VOid,参数类型为int,输入帐户号。getAccountNumbe获取帐户号，返回类型为int,无参数。CaCUIateBaIanCe计算余额，返回类型为Void,参数为doub1e,第一个参数为输入存取款数额，第二个参数为存款余额，既为揄入也为输出。getBa1ance获取帐户余额，返回类型为doub1e,无参数。许多银行储户构成了储户库。ATM系统包含了许多ATM机。银行储户及ATM机两个类包含什么属性，什么操作，它们的可见

3、性及操作的返回类型参数个数参数类型从类图上都一目了然。更多的属性及操作都能够一一加上，使这个类图更全面更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。同样关于一个真正的银行系统，这个类图过于简单。比如帐户类型我们能够先定义一个abstractc1ass,它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract,如余额的计算。然后再继5.3 承这个abstractc1ass,我们能够有SaVingaCCOUnt与CheCkingaCCOUnt等等。不一致的帐户有不一致的余额计算方法，我们能够加上具体的算法。关于不一致的帐户可能还有一些它特有的操作，我们也能够加上,

4、比如savingaccount在存款达到多少时能够享受机票打折的优惠。通过类图不仅能够使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。5.4 顺序图图5.3描述了顾客在ATM机上取款时信息的流淌情况。以时间为顺序。由于仅是示例，因此整个过程是没有出现任何故障时的流程，同时只画到了取款结束。通过这个图，我们能够看出消息是如何在系统中不一致对象之间进行交互。通过流程图我们能够很清晰地看到系统是如何工作的，系统各部分之间的信息及操纵是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个X,这是由于这个流程中还未遇到有对

5、象生命结束。当有对象生命结束时需在对应的生命线终端画X,说明这个对象在这时被销毁。首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来.由于这个顺序图较长，且很清晰，即便是初学者也很容易读懂，在此就不对本图做过多的解释。售行我户灌卡机IJ1zI*人及占客户守住克的机弊置救援幡受ATM/词也确认求E3的台法桂极om员示勒人宓碣清束直加K宓码传递愉入IHa艮示翰人册务卖别R京r类创S认定码（怡注仕效注也确认谪求J取就请求喻人本改请求国示八颉*!西期取）1帖人取,改徽联传啰审敛救霸H罩兼1Ir强&认员示&认触触齿求1传郎嫌认错.包帕人认山“

6、I确认数豺的合格性NPW暂请*hyesky.唯妙匚I，图5.3ATM取款娱序图图5.4描述了顾客在ATM机上进行操作会经历的几种状态，及各类状态之间转换的条件。由因此简化了的例子，因此除了等待顾客插入磁卡的起始状态与结束服务的终止状态，顾客会处于输入密码、选择服务类型、存款及取款四种状态。插入磁卡后进入输密码状态，当密码输入正确时进入选择朋务类型状态，当输入密码不正确时，停留在原状态，但假如三次不正确，服务结束。进入选择服务类型后根据选择的不一致，倾客可进入存款与取款状态.存、取款结束后，顾客既能够选择结束服务到最终状态，也能够选择继续服务回到选择服务类型状态.通过状态图我们能够无歧义的熟悉各

7、个活动角色是如何在不一致状况下转换的，转换的条件是什么，是否会出现死锁现象，是否有条件没考虑周全，是否有状态无法达到。状态图能够帮助我们发现问题，并及时改正。5.5 活动图图5.5参考了RandyMi11er的AHands-OnIntroductionforDeve1opers一文，5.3图中的客户管理与事物管理对应于5.5图中的Bank,图5.3中的读卡机、显示输入设备及点钞机对应于5.5图中的ATMMachina,银行储户就是CUStomer。初看活动图与顺序图表达的意义很接近.但我们能够注意到顺序图着重时间的顺序，而活动图侧重于各部分之间的相互制约，关于一些并行的活动能够有效的表示出来。

8、比如5.5图中fork与join处，我们能够很清晰的看到一些并行活动的存在。这个活动图以顾客插入卡为开始，以顾客取卡结束。我们能够看到活动图的重点尽管不在时间顺序，但我们同样能够得到时间的信息。CustomerATMMachineinsertcrd2)J7.FCE二PWr-utrorj)furdeptmtonwaHdPZIba1anCmOUMTakemonyfromMo*ba1ance(Ex-CMd)TakecardfDt1MCOjniJ乂CMCkMCjrXgnc)(EntermourJ-end图5.5ATM银行系统活动图5.6 协作图在第四章中我们明白协作图与顺序图是能够无信息缺失的相互转换

9、，只是它们的侧重点是不一样的。顺序图若束于对象间消息传递的时间顺序，协作图着重于表达对象之间的薛态连接关系。图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 .出钞请求

10、24 .计算帐户余额25 .出钞26 .取钞27 .传递余额并询问是否还需要其他服务28 .显示帐户余额并提示选择下面的服务从图上我们能够看出协作图的角色与顺序图的对象是一一对应的，而协作图上的各对象上的协作关系与顺序图上的消息传递是一一对应的。摘要本文以实例的方式，展示了如何使用UM1进行面向对象的分析与设计。本文将假设读者对UM1、面向对象等领域的基本内容已了然于胸，因此将不可能过多阐述，而将重点放在应用过程上。本文的目的是通过一个完整的实例，展现基于UM1的00A&D过程的一个简化模式，帮助朋友们更好的认识UM1在00A&D中起的作用。前言经常听到有朋友埋怨，说学了UM1不知该怎么用，或

11、者者画了UM1却觉得没什么作用。事实上，就UM1本身来说，它只是一种交流工具，它作为一种标准化交流符号，在OOA&D过程中开发人员间甚至开发人员与客户之间传递信息。另外，UM1也能够看做是OO思想的一种表现形式，能够说“00是神，而UM1是型”。因此，想用好UM1,扎实的00思想基础是必不可少的。然而，在UM1应用到开发过程中时，还是有一定的模式能够遵循的。（注意，是模式而不是教条，我下面给出的流程只是一个启发式过程，而不是说一定要遵循这个流程。）下面，我们通过一个CMS系统的分析设计实例，看看如何将UM1应用到实际的开发中。1 .从需求到业务用例图00A&D的第一步，就是熟悉用户需求，并将其

12、转换为业务用例图。我们的CMS系统需求非常简单，大致课做如下描述：这个系统要紧用来公布新闻，管理员只需要一个，登录后能够在后台公布新闻。任何人能够浏览新闻，浏览者能够注册成为系统会员，注册后可对新闻进行评论。管理员在后台能够对新闻、评论、注册会员进行管理，如修改、删除等。通过以上需求描述，我们画出如下的业务用例图：这里要注意三点：1 .业务用例是仅从系统业务角度关注的用例,而不是具体系统的用例。它描述的是“该实现什么业务”,而不是“系统该提供什么操作”。比如,在实际系统中,“登录”确信要作为一个用例,但是这是软件系统中的操作,而用户所关注的业务是不包含“登录”的。2 .业务用例仅包含客户“感兴

13、趣”的内容。3 .业务用例所有的用例名应该让客户能看懂,假如某个用例的名字客户看不懂什么意思,它也许就不适合作为业务用例。2 .从业务用例图到活动图完成了业务用例图后，我们要为每一个业务用例绘制一幅活动图。活动图描述了这个业务用例中，用户可能会进行的操作序列。活动图有个很重要的使命：从业务用例分析出系统用例。比如，下面是“新闻管理”的活动图：能够看到，一个“新闻管理”这个业务用例，分解出N多系统操作。这里要特别注意这些操作，其中很多“活动”都很可能是一个系统用例（当然，不是每个都是）。比如，由这个活动图能够看出，系统中至少要包含下列备选系统用例：登录、注销登录查看新闻列表修改新闻删除新闻。这样

14、，将每个业务用例都绘制出相应的活动图，再将其中的“活动”整合，就得出所有备选系统用例。3 .从活动图到系统用例图找出所有的备选系统用例后，我们要对他们进行合并与筛选。合并就是将相同的用例合并成一个，筛选就是将不符合系统用例条件的备选用例去掉。一个系统用例应该是实际使用系统的用户所进行的一个操作，比如，“查看新闻列表”就不能算一个系统用例，由于他只是某系统用例的一个序列项。最终我们得出的系统用例图如下:45 .从系统用例图到用例规约得出系统用例图后，我们应该对每一个系统用例给出用例规约。关于用例规约，没有一个通用的格式,大家能够按照习惯的格式进行编写。对用例规约唯一的要求就是“清晰易懂”。下面给出“登录”这个系统用例的一个规约：用例名称C登录系统，用例简述白用户登录CMS系统二用例图*主要流程1）用户输入用户名和密码一2）选择用户类型33）点击登录按钮，替代流程3a）“用户名或密码错误”，系统出现用户名或密码错误的提示信息，回到主要流程1由用户重新输入3b）“输入的用户名与类型不符”，系统出现提示信息，回到主要流程b由用户重新输入3b）当用户点击取消按钮时，取消登录76 .蛤制业务领域类图完成了上面几步，下面应该是绘制业务领域类图了。所谓业务领域类图要描述一下三点:1 .系统中有什么实体.2 .这些实体能做什么操作。3 .实体间的关系。这里要特别强调：这里的实体不是Act