A:象这种情况定时器是actor。
actor的概念并不是人，而是站在系统边界外（系统边界根据分析需要是可以扩大缩小的）驱动系统的一切人，事，物，甚至规则。系统边界划定后，边界以内的，只有用例。边界以外的，向系统主动发出动作的，是为actor，被动的从系统获得消息的，是为接口。
Q:接着上面这个问题，actor是属于系统边界之外的人、事、物，可是定时器应该是属于系统内部的一个物，我可不可以这么理解，认为计算机的时钟是Actor，以一分钟时间间隔调度为例，Actor就是1分钟、2分钟等这些分钟点。
A:我倒不认为定时器是系统内部的一个物。如果是系统内部的，它必须向外提供服务，也就是系统外有人在驱动它，它是不主动执行的。从UML的观点来说，区分系统内外并不是计算机的内外，不是自己的代码和别人的代码，也不是已经有的代码和将要开发的代码。而是主张者和服务者，或驱动者和执行者的差别。
如果你把定义器认为是系统内部的，那么必须还有另一个系统外的东西来驱动它，哪怕只需要发出一次消息定时器就开始自动工作。就像，上帝轻轻推动了一下，世界从此开始按规律运行。
A:把什么作为一个用例，前提是你事先划定了一个边界。站在边界外的是actor，边界内的是用例。边界是很重要的。它决定了你的视角和能够得出的结果。例如，对于站在笼子外的你来看，笼子里的猴子是用例，而如果笼子里的猴子来看，用例就是你了。这是视角不同。边界同时可以决定粒度。比如，你站在汽车外时，你看到的东西是车体大小，颜色。你在汽车里时，你看到的是仪表盘，方向盘。当把仪表盘拆开，你看到的是电路，显示版...
用例获得也是同样道理，哪些是actor，哪些是用例，粒度如何，取决于你对于边界的认定.
Q:果要分析用例,那么考勤登记里的登记上班时间和登记下班时间算两个用例吗,还是考勤登记就是一个用例,根据楼主说明的用例的第一个特征:这件事是相对独立的,我想应该是分为两个用例吧?
A:用例分为业务用例和系统用例。业务用例描述业务需求，系统用例描述系统需求。业务用例最重要的一点是能否完整表述actor主角的期望。所以你先要弄清楚谁在驱动考勤登记，他的目的是什么。
我觉得只登记上班和只登记下班应该都是目的的一部分，所以应该登记考勤是业务用例。至于上班和下班是否在系统用例阶段要分开，取决于你打算在系统层面将它分成两个逻辑功能还是一个。
Q:我现在在做一个项目，把所有的涉及到的业务都细分成添加、删除、浏览等等类似的一个个小的用例，这应该都是业务用例了，那请问我的系统用例是哪些呢？应该怎么写？或者说有必要写吗？（你可以拿一个电子商务的系统作例子指导一下，多谢了！）
A:你列举出的那些用例实际上都是系统用例了，你还怎么再细分呢？业务用例是指的业务目标，例如说维护人员档案，这是一个完整的业务目标，也是一个业务用例。至于维护办法，有手工的，有自动的，有的只能加不能删，有的只能修改，有的只能看....这些，是实现业务目标的方法。在这些方法中，打算纳入软件开发范围的，才叫做系统用例。
Q:那我是不是可以这样理解呢，如果把业务用例进行功能上的细分的话，分成若干个小的用例，那么这些小的用例是不是就是系统用例？
就象维护人员档案，如果细分成添加档案，修改档案，删除档案，查看档案等等。。。
如果你的答案是肯定的话，那我是不是可以继续这样理解：一般情况下，业务用例实际上是在一个比较高的层面上来看业务逻辑，更接近于用户的直接需求，而系统用例则是业务逻辑的详细的划分，更接近与程序的设计了？
A:不大对喔。系统用例和业务用例的区别并非是细分。
请注意理解：业务用例是用来捕获功能性需求的，功能性需求是由actor的业务目标来体现的。也就是对于actor来说，他所负责的业务需要由一系列的业务目标组成。比如一个档案管理员，他的业务目标就是维护档案。比如论坛管理员，他的业务目标有维护用户，维护帖子等..这些业务目标构成actor职责的全部。业务用例体现了需求。
而需求的实现有多种方式。如何实现它，是由系统用例来体现的，它们并不是一个简单的细分关系，虽然看上去象。就说维护档案吧，这样一个业务目标，会有多种不同的用例场景去完成它，这些场景包括如何增加档案，如何修改档案，如何删除档案....对于系统用例来说，就是通过分析这些场景，来决定哪些场景中的哪些部分是要纳入系统建设范围的。比如维护档案业务用例中，假设由于某个原因，修改档案很困难，只能通过先删除，再全部重建的方式来实现，那么系统用例就增加档案，删除档案，而没有修改档案。
业务用例和系统用例是分别站在客户的业务视角和系统建设视角来规划的。业务用例不是接近，而是完全的直接需求，系统用例也不是业务逻辑的详细划分，而是系统对需求的实现方式，但不是与程序设计无关，它只是说，要建设的系统功能性需求由这些系统用例构成。
所以业务用例和系统用例都是需求范畴，它们分别代表了业务范围和系统范围。
Q:楼主的系统分析员之路第一篇讨论的是什么是用例，第三篇讨论了涉众。这里一直有一个疑问怎么从涉众中找出系统的actor？ 就拿网上图书借阅系统来说，图书馆的一些领导希望查询系统获得他们想知道的信息，这里要不要把作为一个actor，如果是actor的话，有没有必要有“综合查询”用例
A:如果某涉众直接使用计算机系统，则该涉众就是一个备选actor。如果多个涉众使用计算机系统的目的是一样的，则只需要一个actor。
领导希望查询系统获得他们想知道的信息，如果这个信息只有领导需要，它的确是actor，如果有很多涉众都在使用，应当考虑是不是有另一个actor代理这些涉众来使用。至于“综合查询”用例，我觉得是不准确的，至少在需求阶段，需要明确知道查询什么。而是不是“综合”起来，取决于设计而不是需求。
Q:例如领导直接查询系统获得上架图书的统计情况，领导也直接查询系统获得借出图书的统计情况。我想说的是：领导希望查询的信息可能和几个用例都有交叉。 这个时候该怎么处理这种情况呢？
A:http://coffeewoo.itpub.net/post/9169/227772
这篇文章中讨论到一些关于查询的问题。拷贝到这里。
有一点是值得讨论的，就是查询用例。这是一个比较特殊的东西，因为查询的目标可以很明确，也可以很模糊。比如，我就只是查查看而已，看完了什么也不做；也可能是因为我要租房，所以查询；还可以因为是我要查完后修改我已经发布的信息...类似这样的不同目标还有很多，显然我们不可能每一个目标都去定义一个查询XXX业务用例。同时，一个查询可能是跨越多个业务用例的，比如把求租、寻租和用户信息集中在一个查询结果里面。在这一点上我也不能断定你专门目标的用例：找房屋信息业务用例，和你朋友通用目标的用例：查询信息业务用例哪一个是正确的，事实上都是正确的，也都有道理，取决于客户需求中针对查询的要求，到底是专门目的，还是模糊目的。
另外补充一点，如果是模糊的，通常查询XX作为某一个用例的扩展或者包含。例如，要删除用户，必须先查询，查询是删除的一个包含。或者，要删除用户，可以直接从列表中删除，也可以设定条件查询，查询是删除的一个扩展
Q:看了好几遍了，确实受益匪浅啊，还有问题不明白，关于增删改查这样的用例，比如一个管理系统，基本都有这些操作，如果把它们看作系统用例，那么有这样一个结果，到处都有这样的用例，这样存在是否有意义，如果没有意义的话，是否可以用一个‘维护XX’这样的一个用例来代替？
A:
我说系统用例，附带的意思是这些系统用例是可复用的。到处都有这些操作，那么它们应该被视为是可复用的部分。
例如，Hibernate提供了增删改查的API，你要做的事情是产生HQL。Hibernate提供了增删改查的API就是可复用的部分，但它是系统的，与客户业务无关。
这是用Hibernate做例子来讲，如果你的项目中不用任何的第三方框架，完全是自己的，要避免到处都有这样的用例，那么你们就要在自己的项目框架里实现这些与业务无关的的系统用例，那么与业务相关的用例就可以用“维护XX”来代替了，因为“维护”的功能已经实现了。
如果不是这样做的，如果要维护文档和代码的一致性，那到处是增删改查不可避免的。省略掉当然也可以，只不过需要大家达成共识：所有带“维护”的用例都包括“增删改查”
Q:谢谢，什么时候出版你的书，好想看看，增加自己的分析能力！还有一问题想请教一下，比如说图书馆登记图书这样一个事件，如果把它看作一个用例，问题就是：新图书登记上架之前是要对图书分类，那么这个图书分类应该看作单独用例，还是登记图书中的包含用例，这个过程本来就没有清晰的界限？
A:表面上看没有清晰的界限，实际上有。你这个问题是个用例粒度的问题，到底多大合适？这个问题其实是有明确界限的，就看你选择的边界在哪里。比如，你选择的边界是整个图书馆管理，那么登记图书就是图书馆管理中的一个业务环节，而图书分类是看不到的。如果选择的边界是登记图书管理，那么分类图书、装订图书、编辑概要等等就是适合的用例。
所以说这个过程是有明确界限的，依赖于你所选择的边界。
Q:对边界还是不大明白。请问一下边界的选择是否有一定的原则或规则？是不是由项目组成员自己来确定这个边界？
A:边界即是你面对的问题领域。边界的决定没有严格的规则，但有经验可循。面对一个复杂的问题时，为了能够把问题弄清楚，人们会把整个问题分解成一些小的问题领域，这就形成了边界。在项目最初，边界可能是很宽泛，很粗的，随着项目的进展，信息越来越多，越来越细致，边界也会随着清晰，细致。
在分析过程中，边界绝不是一成不变的，在项目的不同阶段，面对不同的问题，总有很多种可能的边界选择。没有标准判断对错，只不过边界选择的结果要利于分析问题。当然，不好的边界选择会导致分析困难。如果根本不用边界的概念，那问题就是一锅粥了。
Q:
系统建模时经常遇到的工作流类型应用的建模方法
在企业应用建模中，我们经常遇到的一种情况：某种业务，它由一系列顺序相关的业务活动组成，这些业务活动一般由不同的人甚至不同的部门负责，也就是说为了实现一个业务目标需要不同的职责的人或部门协作。
我们考虑一个315服务系统处理顾客投诉的应用，在业务模型中，它只是一个业务用例，我们就把它叫“顾客投诉”。
“顾客投诉”可以这样一种场景来描述：
张大头最近买了一部手机，刚用了没多久发觉是一部水货，张大头很是气愤，找到商家要求退货，不料售货员态度蛮横，不理睬他，张大头没办法，只得向315热线投诉。
315的受理人员接受了他的投诉，并记录了投诉人的信息以及投诉案件的一般情况，如手机型号、商家、购买时间等，然后要求张大头在家等消息。315协会的管理人员很快接到了新的投诉案件信息，并将它分配给处理人员李曲去处理。然后，李曲开始处理这件事情，李曲找到李大头，把它的手机首先拿去鉴定，仅确认确实是水货，然后李曲和张大头拿着检验报告到商家，要求他们退货，几番交涉，商家退货了事。然后李曲将这个的处理结果写了报告交给管理人员。管理人员向张大头进行了回访，确认了此事，并签署了审批意见，然后结束了这件案子。
好了，现在要求开发这个应用，需求人员认为有以下几个业务活动：
（前台）电话受理
（主管）分派任务
（调查人员）处理案件并编写案件处理报告
（主管）电话回访用户，签署审批意见，结束案件
需求人员同样认为采用用例来描述需求既能够比较清晰又符合项目开发的要求，按照以前的习惯，我们获得了以下用例模型：
按照用例的定义，它应该是合理的，但用例之间没有关系，总让人觉得没有更好地反映出业务之间的密切的关系，实际上我们不难发现，这些业务都是围绕着一个投诉案件来进行的，如果能够很好的描述它们的关系对于业务的理解和用户的最后价值是有帮助的，毕竟谁会使用一个只有电话受理，却不处理的业务应用呢。当然这种关系在业务模型是中可以看出来的，因为都包括在“顾客投诉”业务用例中，但问题是并不是所有系统都建立业务模型，而且怎样在系统用例中反映它们的关系呢，同时用例的事件流描述也会出现像“受理后将案件传给主管”等“将...传递给...”的描述，因为它们确实关系密切。
当然有人提出这种方式：将用例之间加上带箭头的连接线来表示：
但遗憾的是这并不是一种正确语义的表示方法，有些UML的CASE工具（像TogetherJ）甚至根本不让绘制这样的图形。更为重要的是如果主管需要根据“填写处理报告”用例的结果来决定是“结案”，还是需要“案件转移”到其它部门，又应该在什么地方描述呢。
当然也可以考虑单独绘制一张活动图来描述。但是这些仅仅都是关注在表示方法上的改进，更为重要的是如何从功能（业务）的关系上如何更好地反映它本来具有的自然依赖关系。
请问coffewoo兄这种情况下如何进行用例建模。
另外，该系统实现时（姑且不考虑数据与逻辑分离原则），可否实现为一个《顾客投诉类》，其中该类中有四个方法：（前台）电话受理 ；（主管）分派任务 ；（调查人员处理案件）编写案件处理报告； （主管电话回访用户）签署审批意见，结束案件。这里姑且将《案件处理报告》实现为《顾客投诉类》的多个属性。
A:
这些思考是你自己的吗？真的非常棒！能够思考这些问题，可以说你对用例方法的理解已经非深刻了！觉得你这个问题很有意思，我会把它作为一篇博文发出来的
在回答你的问题之前我先扯点别的东西，与这个问题的答案相关。昨天晚上我跟一个同事闲聊SOA，天马行空的扯了很多将来可能的商务模式和应用模型。尽管聊天的内容玩笑和吹牛皮的成份居多，不过观点总结起来就是一个：on demand business，也就是所谓的商务随需应变。在我们的牛皮里，将来的应用系统处于一种“不确定”状态，例如，假设你想交手机费，你会请求一个交费服务，但是你不知道这个交费服务最后将你的费用交到了哪家银行，还是哪家运营商，还是某个中介机构，你只知道你的交费成功了。甚至，交费服务的开发者自己也不知道会交到哪里，它按照一定的规则（例如目速度最快的、最稳定的、手续费最低的...等等）搜索可以接受交费请求的其他服务提供商提供的服务，并调用它们。这个过程是动态而不是事先定义的。社会上的各个服务机构都提供了各式各样的服务，而个人或中服务中介则可以自己定义自己的综合服务以获得赢利。例如，你可以定义一个集交手机费、交水电费、交有线电视费、纳税....等等服务于一身的一榄子交费服务。换句话说，业务流程由使用者决定而不是服务提供商！于是，应用系统模型变为服务机构提供服务，而使用者在使用时自行定制业务流程。
之所以扯上面的故事是因为在你的思考中，你的疑虑在于你认为如果功能之间的业务关系不能够清晰的表示出来，那么业务模型不能成立，随之编写程序也变为不可能。正如你所说：但是这些仅仅都是关注在表示方法上的改进，更为重要的是如何从功能（业务）的关系上如何更好地反映它本来具有的自然依赖关系。
不过我并不这样看。功能（业务）之间的关系真的是“自然依赖关系”么？不，功能（业务）之间的关系是因需而存的。用你所举的例子来说，如“主管需要根据“填写处理报告”用例的结果来决定是“结案”，还是需要“案件转移”到其它部门”之类的业务关系并不是自然依赖的，而是由315案件处理条例之类的规则来决定的，更本质的说，是这样的规则也是因为处理顾客投诉的需求而产生的。回到我之前的故事，商务随需应变，怎么理解？需是本质，商务是形式，商务随需而变。一旦顾客投诉需求有变，你所说的“关系密切的、自然依赖的”业务就完全有可能不再关系密切，不再相互依赖。如果这样，你还认为必须要把用例之间因为当前业务而产生的关系当做“天然、本质”的内容来定义吗？
将用例定义为“独立”的，不定义它们之间的关系的道理就在这里。用例之间本来没有所谓的自然形成的客观关系，它们之所以发生关系，是因为业务场景的需要，换言之，是因为需求的需要。需求变了，业务场景就变了，但业务场景变了却不意味着用例会变。举个最简单的例子，现在很多大中城市已经合并了110，119，112等应急电话，原来打110只能报匪警，打119只能报火警。但现在打110既可以报匪警也可以报火警。我们发现，需求变了，业务场景变了，但是用例却没变，我们不会看到民警挥舞着警棍冲入火场，也不会看到消防警拖着消防栓狂追小偷。由是得出结论：110不等于匪警，它只是匪警出警用例的一个业务场景而已，因为这个业务场景，110应急程序和匪警产生了关系，但这个关系不是天然的。或许有一天我们每个人手机上都有一个紧急事件按钮，一按就可以与所谓城市应急处理中心联系，而110，119，112等等服务程序则可能光荣下岗，而民警、消防警、急救中心还是一个都不能少。
不知你得到答案了吗？这种情况下进行用例建模跟你现在习惯的做法一般无二，用例仍然是独立的；它们之间的“关系”仍然体现在各种场景中；不要试图在用例之间用什么线来表示用例之间有业务关系；不要将现在的业务关系认为是用例之间的天然关系。
如果真的实现了我与同事海吹的那个将来，你所能做的是提供适合的用例，将其实现为服务；而业务场景，则是由顾客自己来决定，通过服务搜索引擎从海量用例（服务）中挑出自己中意的，拖拖拽拽，定义出一些个性化的诸如“购房一条龙服务”、“生活费用一条龙服务”、“挑选女朋友一条龙服务”之类的业务流程供自己使用，那才是真正的商务随需应变，on demand business!
呵呵，憧憬ing...