摘要：
Q:请教咖啡兄了，类似调度这种需求怎么描述，比如数据库调度，1天做一次备份。又比如我系统里需要每一分钟做一些数据分析处理，这种需求没有哪个用户来驱动，如何定义它的用户，我开始把定时器作为用户，但发现那已经是实现了，那可以把调度本身作为个用户吗，这样调度做的事情就可以方便的用用例来描述了。我这个系统可能会碰到多种类似情况，比如数据改变而做的事情。缺乏经验阿。
A:象这种情况定时器是actor。
actor的概念并不是人，而是站在系统边界外（系统边界根据分析需要是可以扩大缩小的）驱动系统的一切人，事，物，甚至规则。系统边界划定后，边界以内的，只有用例。边界以外的，向系统主动发出动作的，是为actor，被动的从系统获得消息的，是为接口。
Q:接着上面这个问题，actor是属于系统边界之外的人、事、物，可是定时器应该是属于系统内部的一个物，我可不可以这么理解，认为计算机的时钟是Actor，以一分钟时间间隔调度为例，Actor就是1分钟、2分钟等这些分钟点。
A:我倒不认为定时器是系统内部的一个物。如果是系统内部的，它必须向 阅读全文
摘要：
在了解了系统目标以后，系统分析员最先要做的事情不是去了解业务的细节，而是去发现与这个目标相关的人和物。英文把这种人和物称为Stakeholder，在Rose中，这类模型的类型被定义为Business Actor 。有的资料翻译为干系人，笔者则更喜欢涉众这种翻译方法。这就谈到了业务建模的第一步：发现和定义涉众。
从这一篇开始，笔者将借助一个虚拟的实例来阐述获取用例的方法，以及如何判断用例获取是否完备，粒度选择是否合适。事实上，在做这些工作时，我们正在进行需求分析的第一个阶段，即业务建模阶段。借助这个例子，笔者同样会阐述业务建模到底应该做什么，做到什么地步才能说明业务需求已经完整，可以称为一份完整的需求规格说明书了。
一般来说，只有当以下工作都完成，才能说业务模型建立完成，它们是：
阅读全文
摘要：
在正式讨论如何获取用例之前，笔者觉得有两个问题还是先解释清楚为好，这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑，也是最难掌握的。一个是各种用例类型之间的区别和用法，另一个是用例的粒度。
在正式讨论如何获取用例之前，笔者觉得有两个问题还是先解释清楚为好，这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑，也是最难掌握的。一个是各种用例类型之间的区别和用法，另一个是用例的粒度。
先说说用例类型的问题。
用例类型，有的资料翻译为版型，英文原文是stereotype。在Rose中默认的类型有business usecase , business usecase realization和use case realization三种。 阅读全文
摘要：
用例是什么？其原始英文是usecase，直译过来就成了用例。这也是一个比较贴切的叫法了，从字面的直接理解就是使用的例子。另一种比较流行的定义是用例就是与使用者(actor)交互的，并且给使用者提供可观测的有意义的结果的一系列活动的集合。
这个定义还是比较费解的，笔者在众多应聘者中发现很多使用用例来做需求的系统分析员，有的已经使用了两年以上，但仍不能把握用例的本质，虽然他们号称精通UML。
最具普遍意义的理解错误是认为用例就是功能的划分和描述，认为一个用例就是一个功能点。在这种理解下，用例变成了仅仅是较早前需求中功能框图的翻版，很多人用用例来划分子系统，功能模块和功能点。如果这样，用例根本没有存在的必要。有意思的是，造成这种理解错误的相当一部分原因却是因为对OO思想的理解不够深入，本质上说，把用例当成功能点的系统分析员脑子里还是面向过程的那一套思想，虽然他们在使用OO的工具，OO的语言，号称在做面向对象的开发，但过程的影子还没有从他们脑子里彻底抹去。
阅读全文