从角色出发
(大致2005年左右写的。由于订正笔误重发布，时间变了）
在我们的设计过程里,"角色"这个术语是相对来说被提的很少的,"业务","流程"则更多.我们拿到的需求或设计文档里,序列图,流程图是主要组成部分.Use case也是有的,主要是用于简单描述事件流.
也许是认为角色这个概念并不是很复杂,或者已经分析的够透彻了，所以不用再提.实际上大家对系统相关都有哪些角色是有感性认识的，但感觉对角色的实质，角色的细节，角色之间的互操作等方面，细化的不够，抽象归纳的也不够。
如果从角色出发,也许大致可以如此分析
1:定义角色的职责
2:定义角色的一般属性
3:定义角色可能有的扩展属性（考虑实现的话可以通过继承等方法）
4:定义角色的一般行为，包括访问管理其属性的方法。
5:定义角色之间的交互行为和操作接口 ，接口很大程度上是基于角色的属性和行为
6:定义当角色本身发生变更，新角色加入或角色消失时的行为。
需要考虑角色定义的粒度，层次（整个系统或子系统），是否有互相依赖或冲突。角色应该是高内聚，低耦合的。
角色作为系统中相对来说是比较固定的一部分，当角色本身和角色之间的交互基本确定清晰后，流程的更改更多的是改变角色之间交互的次序。
以上思路个人还没有成熟的示例，只是一点随想。总之事在人为，首先做人，再考虑做事，这个原则是不会错的。