"例，比也"（《说文》），本次连载将给出一个利用UML进行建模的完整实例，综合应用前面学到的知识，达到"举此以例其余"（元刘壎《隐居通议·欧阳公》）的目的。
在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。我们在日常生活中也经常和ATM打交道。本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。
5.1用例图
参与者"银行储户"和ATM机。简化后的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机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。同样对于一个真正的银行系统，这个类图过于简单。比如帐户类型我们可以先定义一个abstract class，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract class，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。
5.3顺序图
图5.3描述了顾客在ATM机上取款时信息的流动情况。以时间为顺序。因为仅是示例，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。
通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个"X"，这是因为这个流程中还未遇到有对象生命结束。当有对象生命结束时需在对应的生命线终端画"X"，表明这个对象在这时被销毁。
首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来…..因为这个顺序图较长，且很清晰，即便是初学者也很容易读懂，在此就不对本图做过多的解释。
5.4状态图
图5.4描述了顾客在ATM机上进行操作会经历的几种状态，及各种状态之间转换的条件。因为是简化了的例子，所以除了等待顾客插入磁卡的起始状态和结束服务的终止状态，顾客会处于输入密码、选择服务类型、存款及取款四种状态。
插入磁卡后进入输密码状态，当密码输入正确时进入选择服务类型状态，当输入密码不正确时，停留在原状态，但如果三次不正确，服务结束。进入选择服务类型后根据选择的不同，顾客可进入存款和取款状态。存、取款结束后，顾客既可以选择结束服务到最终状态，也可以选择继续服务回到选择服务类型状态。
通过状态图我们可以无歧义的了解各个活动角色是如何在不同状况下转换的，转换的条件是什么，是否会出现死锁现象，是否有条件没考虑周全，是否有状态无法达到。状态图可以帮助我们发现问题，并及时改正。
5.5活动图
图5.5参考了Randy Miller的《A Hands-On Introduction for Developers》一文，5.3图中的客户管理和事物管理对应于5.5图中的Bank，图5.3中的读卡机、显示、输入设备及点钞机对应于5.5图中的ATM Machina，银行储户就是Customer。初看活动图和顺序图表达的意义很接近。但我们可以注意到顺序图着重时间的顺序，而活动图侧重于各部分之间的相互制约，对于一些并行的活动能够有效的表示出来。例如5.5图中fork和join处，我们可以很清楚的看到一些并行活动的存在。
这个活动图以顾客插入卡为开始，以顾客取卡结束。我们可以看到活动图的重点虽然不在时间顺序，但我们同样可以得到时间的信息。
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．显示帐户余额并提示选择下面的服务
从图上我们可以看出协作图的角色和顺序图的对象是一一对应的，而协作图上的各对象上的协作关系和顺序图上的消息传递是一一对应的。
在我国十年前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机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。同样对于一个真正的银行系统，这个类图过于简单。比如帐户类型我们可以先定义一个abstract class，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract class，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。
5.3顺序图
图5.3描述了顾客在ATM机上取款时信息的流动情况。以时间为顺序。因为仅是示例，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。
通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个"X"，这是因为这个流程中还未遇到有对象生命结束。当有对象生命结束时需在对应的生命线终端画"X"，表明这个对象在这时被销毁。
首先银行储户将ATM卡插入读卡机，读卡机将信息传给客户管理，客户管理提出查询密码，显示部分将输入密码请求显示出来…..因为这个顺序图较长，且很清晰，即便是初学者也很容易读懂，在此就不对本图做过多的解释。
图5.4描述了顾客在ATM机上进行操作会经历的几种状态，及各种状态之间转换的条件。因为是简化了的例子，所以除了等待顾客插入磁卡的起始状态和结束服务的终止状态，顾客会处于输入密码、选择服务类型、存款及取款四种状态。
 图5.4 ATM状态图 |
插入磁卡后进入输密码状态，当密码输入正确时进入选择服务类型状态，当输入密码不正确时，停留在原状态，但如果三次不正确，服务结束。进入选择服务类型后根据选择的不同，顾客可进入存款和取款状态。存、取款结束后，顾客既可以选择结束服务到最终状态，也可以选择继续服务回到选择服务类型状态。
通过状态图我们可以无歧义的了解各个活动角色是如何在不同状况下转换的，转换的条件是什么，是否会出现死锁现象，是否有条件没考虑周全，是否有状态无法达到。状态图可以帮助我们发现问题，并及时改正。
5.5活动图
图5.5参考了Randy Miller的《A Hands-On Introduction for Developers》一文，5.3图中的客户管理和事物管理对应于5.5图中的Bank，图5.3中的读卡机、显示、输入设备及点钞机对应于5.5图中的ATM Machina，银行储户就是Customer。初看活动图和顺序图表达的意义很接近。但我们可以注意到顺序图着重时间的顺序，而活动图侧重于各部分之间的相互制约，对于一些并行的活动能够有效的表示出来。例如5.5图中fork和join处，我们可以很清楚的看到一些并行活动的存在。
这个活动图以顾客插入卡为开始，以顾客取卡结束。我们可以看到活动图的重点虽然不在时间顺序，但我们同样可以得到时间的信息。
 图5.5 ATM银行系统活动图 |
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．显示帐户余额并提示选择下面的服务
 图5.6 ATM系统协作图 |
从图上我们可以看出协作图的角色和顺序图的对象是一一对应的，而协作图上的各对象上的协作关系和顺序图上的消息传递是一一对应的。
