软件方法 01

一、系统用例可以看做系统执行者和系统之间买卖的平衡点，期望和承诺的平衡点。系统用例可以把需求提升到思考系统“卖什么”的高度。（搞清自己的“用例”，认清自己的定位。）

二、思考用例的过程就是发现价值的过程。

三、“粒度”的问题。开发人员切勿玩弄“粒度原则”、“分层技巧”，应该把屁股挪到涉众那边去，揣摩涉众的心理，实事求是的写下来。

对于判断“用例是否用对”的标准：是否加强了和涉众的联系，如果不是，那就用错了。

业务建模映射出系统用例的识别方法：在业务序列图中，从外部指向所研究系统的消息可以映射为该系统的用例。

识别系统用例的注意事项：

一、主执行者和辅执行者：主执行者从执行者指向用例，而辅执行者从用例指向执行者，主执行者发起用例的交互，辅执行者在交互过程中被动参与进来。场景：主执行者要执行用例，需要辅执行者的帮忙。

二、切勿把到辅执行者的箭头误解为数据传送的方向。

三、主辅执行者是针对某个用例来说的，一个系统在这个用例中充当主执行者，也可以在另一个用例中充当辅执行者。一般说来，辅执行者是人肉系统的情况比较少，更多时候是另一个非人智能系统。

四、用例是涉众愿意“购买”的、对系统的一种“用法”，只要涉众愿意“购买”，当然是越多越好。

五、需求是不考虑“复用“的，如果在考虑”复用“，要紧惕自己是不是已经转换到了设计视角来思考问题。

六、针对不同执行者、不同业务流程，系统提供的价值可大可小，无论大小均是用例。

七、用例的命名。用例命名采用"动宾结构"，宾语前可以加定语，把一句话的主语砍掉，剩下的可以做用例的名字。