使用业务序列图原因：

一、活动图只关注人，序列图把人当作系统。活动图描述流程时，往往会忽略了非人工系统的责任。

二、活动图表示动作，序列图强迫思考动作背后的目的。序列图不但表达非人工系统的责任，也揭示出某个岗位对外暴露的责任，序列图可以在业务建模和系统建模的过程中始终贯彻“对象协作以完成用例“的思想。

三、活动图更“灵活”，序列图更不“灵活”。“很容易画”的活动图容易掩盖开发人员对业务流程认识不足或者业务流程本身存在缺陷的事实。序列图强迫开发人员通过alt、loop等结构化控制片段描述业务流程的方式去思考，通过故事来思考待开发系统的位置。

业务序列图要点：

一、消息代表责任分配而不是数据流动。在序列图中，焦点是对象之间的责任和写作，数据流是作为消息的输入输出参数存在的。建模人员不但要看到数据的流动，还要找出背后的责任。消息代表对他人提供的服务，如果没有指定目的可以用“处理...”来命名，消息名称中不需要带“请求”二字，箭头已表明请求的意义。

二、聚焦于系统之间的协作。业务建模研究的焦点是组织，所以业务序列图上对象的最小单位是人肉或非人肉系统。建模的基本原则是抽象级别的一致，勿需细化到每一步操作。

三、只画核心域相关的系统。一个智能系统要不要成为序列图上出现的业务实体，要根据“它是否核心域内的系统”来判断。

四、把时间看作特殊的业务实体。这样便可以映射到系统用例的时间执行者。注意，时间是外系统，世上只有一个时间系统，定时器是其他系统用来和时间大交道的边界类，定时器会有无数个。

a.绘制现状业务序列图：现状好比拿着摄像机去拍摄，会拍到什么？把拍到的场景如实绘制成业务序列图。根据不同的业务用例，会有多个业务序列图。

应避免的错误：

一、把“现状”误解为“纯手工”。业务流程中有人工系统也有非人工的系统，新系统的需求需要通过研究业务现状，再结合愿景推导得出。

二、以待开发系统为中心拼凑流程。业务建模时，摄像机应该一路跟随着实现业务用例的流程去拍摄，如实反映拍摄的故事，各个系统知识流程中的一个零件。业务建模就是要从业务流程中待到代开发系统的位置，证明该系统对实现业务用例是有帮助的。

b.绘制业务交互概述图：将各个业务用例的序列图串联起来。

c.改进业务序列图：挑选一个最值得改进的业务序列，阐明原因，然后空降一个系统，画出改进后的序列图，从而得到第一批用例。注意UML建模不是为了“先建模后需求在分析”的顺序而使用，而是迅速定位最值得改进点，得到最有价值的用例，先开发。这才是敏捷。

改进途径：

一、物流变信息流。为降低流转成本，尽可能把物流变成信息流，在需要物的时候才将信息变成物。

二、改善信息流程。可以依靠引入一个新的系统来达到在多个信息系统之间实现信息传递和协调。

三、封装领域逻辑。通过将人脑中的领域逻辑提炼封装到信息系统中，使人脑得到解放。在绘制业务流程时，非常重要的改进点是：一定要注意画出人脑中的思考逻辑，避免白开水一样的业务流程。前两条改进，系统内部封装逻辑不复杂，效率高，而做到第三条，就可以靠软件的功能就能卖钱。

四、阿布思考法。

改进思路是：

1.假设有足够的资源去解决问题，得到一个完美的方案；

2.用手上现有的资源去山寨这个完美方案。例如：中国组织最得力的会议是靠人脑组织的全国人民代表大会，做会议软件的话可以山寨一二。

“创新的需求是从观察和思考的汗水中来，不是把拍脑袋闭门造车的所谓‘头脑风暴‘当作调研”。

2-系统建模：与业务建模不同的是研究对象，业务建模的对研究对象是组织，而系统建模的研究对象是系统。

1.画出系统用例图：有了业务建模的铺垫，系统用例实际上以呼之欲出。

1). 系统用例图：

a. 确定系统执行者：系统执行者的定义是在所研究系统外，与该系统发生功能性交互的其他系统。有了前面的业务建模，就不需要头脑风暴了，直接从业务序列图映射即可得到系统执行者。

理解要点：

一、系统外：系统执行者不是所研究系统的一部分，而是该系统边界外的一个系统。这里的边界指的是责任的边界而非物理的边界。

二、交互：系统执行者必须和系统有交互，不和系统交互的不算是系统的执行者。系统执行者和重要无关，系统执行者只关注谁和这个系统接口，而正真和重要相关的概念是涉众。用例必须在它的路径、步骤、补充约束中考虑这些涉众的利益。

三、功能性交互：执行者和系统发生的交互是系统的功能需求。

四、系统：系统可以是人肉系统，也可以使一个智能系统，甚至是一个特别的外系统——时间。

业务建模映射出系统执行者的方法：与系统交互（存在实的消息线）的人肉系统或其他系统即为系统的执行者。

注意事项：实际工作中，系统执行者和系统用例是一起识别的。

一、不要把执行者和权限管理混淆。用例的主执行者只是表明这个用例是为这一类执行者而做，但不代表系统一定要有权限控制以防止其他的人或电脑系统使用该用例。

b. 系统用例：系统用例的定义是系统能够为执行者提供的，涉众可以接受的价值。

用例识别要点：做需求的目的不是为了安慰自己或者走过场，而是让产品更加好卖，不以这个为出发点的需求工作是没有意义的。即使再难，也只能从涉众的视角来定义需求，切不可贪图方便选一个自己熟悉的视角了事。

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

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

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

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

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

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

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

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

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

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

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

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

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

常见错误：踏实研究业务流程，做好业务建模，尽量从业务序列图中映射出系统用例，这样的系统用例是不会骗人的。

一、把步骤当作用例。Include（包含）关系的目的是为了复用在多个用例中重复出现的步骤集合，形状往往是多个大用例Include一个小用例。

二、CRUD问题。把数据库的各个表名加上新增、检索、修改、删除就得到了用例的名字或者把四种操作合并称为“XX管理”。

三、玩弄“复用”：用例的执行者不同，背后的涉众利益也有差别，不能简单的合并复用为某一个操作。

四、多个主执行者指向同一个用例。如果用例图已完成，对于这种错误的修改，可以通过泛化出抽象的执行者或者分成几个不同的用例的方法来修改。后一种更常见。

五、玩弄”层次“。切勿偷换"研究对象"，也切勿”把愿景当系统功能“。

六、玩弄”子系统“：用例很多时可以将用例分包，但用例包是在系统的外部对系统功能所做的划分，而子系统则是根据内部部件的耦合和内聚切割得到。

七：模糊的价值：系统往往无法承诺执行者预期的价值时，则该价值不是执行者的用例。主执行者执行用例时，若是需要辅执行者提供实时的帮助后才能进行，则用例正确，否则用例错误。