uml中那些难以拿捏得词们

角色

角色（actor）实在系统之外与系统交互的某人或者某事物。

前些时间朋友的父亲出车祸了，人没事，但是车废了。于是去找保险公司去赔偿去了，可是朋友的父亲需要填写表单，证明之类的一系列的复杂过程，那么在这个过程中，谁是参与者，是每一个人吗？亲，你乱了吗。

定义上说的很清楚，系统之外与系统交互的人或事，那么在这个过程中我们只需要想清楚两个问题。

1. 谁对系统有着明确的目标和要求并且主动发出动作。

2. 系统为谁服务。

显然在这个场景中，朋友的父亲是有明确的目标，主动找保险司索赔的。第二个问题的答案就是保险公司要为朋友的父亲服务。那么朋友的父亲就是参与者。

建模这也常常面临另一个问题，有些需求并没有人参与，参与者咱们确定呢，例如每天自动统计网页访问量，生成统计报表，并发送之管理员的信箱，这个过程的参与人是谁呢，如何确定呢。

那么还用上边的问题来解决，统计器需要统计网页网页访问量，是他发出的动作，系统为统计器服务，所以统计器就是参与者。

查找参与者的办法：1谁负责提供、使用或删除信息？2谁将使用此功能？3 谁对某个特定功能感性趣。4在组织中的什么地方使用系统。

用例

把显示世界的需求捕获下来的方法。例如上文上的需要找保险公司索赔，计数器需要统计网页访问情况，再例如一个人需要喝水，用例是一个完整的过程，不能说去找贡献公司，去统计，去和，没有宾语是不行。且必须有参与者参与，这样两者才算是一个用例

边界

对于有行的东西，边界很好理解，比如说电视机，汽车等，因为我们可以看得到，可是如果我们看不到呢？例如系统的边界，统的边界也就是需求的集合，我们要如何来判断呢？明明是先有的边界再有的需求呀。所以在面向对象技术的开发中，随着我们不断地需求的明确，边界也就越来越明确了。不断地调整，最后达到一个让合理的边界（需求合集）。

节点

节点是带有至少一个处理器、内存以及可能还带有其他设备的处理元素。在实际工作中，一般说来服务器、工作站或客户机都可以称为一个节点。节点是应用程序的部署单元。节点元素特别用于部署视图，描述应用程序在物理结构上是如何部署在应用环境中的，是一种包括软、硬件环境在内的拓扑结构描述。

粒度

粒度是令人困惑的。比如在ATM取钱的场景中，取钱、读卡、验证账号、打印回执单等都是可能的用例，显然，取钱包含了后续的其他用例，取钱粒度更大一些，其他用例的粒度则要小一些。到底是一个大的用例合适还是分解成多个小用例合适呢？这个问题并没有一个标准的规则，是在项目过程中根据阶段不同，使用不同的粒度。在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。例如取钱、报装电话、借书等表达完整业务的用例，而不要细到验证密码、填写申请单、查找书目等。