uml业务建模实例分析.doc

uml业务建模实例分析图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处，我们能够专门清晰的看到一些并行活动的存在。那个活动图以顾客插入卡为开