软件方法（上）：业务建模和需求（第2版）

好的，没问题！根据您的要求，以下是对您提供的书籍章节内容的总结：

第4章 业务建模之业务序列图

• 内容总结：本章主要讲解如何使用业务序列图描述和改进业务流程，并将其与活动图进行对比，强调序列图在捕捉系统责任和目的方面的优势。
• 你能获得：学习业务序列图的绘制技巧，理解如何从业务流程推导出系统需求，以及掌握改进业务流程的有效方法。

核心内容：

1. 选择合适的业务流程描述手段

• 文本描述：不够直观，不推荐。

• 活动图：侧重人或部门的活动，可能忽略非人智能系统的责任。

• 序列图：将人视为系统，强调对象协作以完成用例，可以贯穿业务建模和系统建模。

  • 详细解释：序列图能更清晰地揭示出岗位对外暴露的责任，表达非人系统的责任。
  • 序列图强迫思考动作背后的目的，通过结构化控制片断（如alt、loop）描述业务流程，揭示业务流程的现状。
  • 例子：用活动图描述报销流程时，可能只关注财务主管审批报销单的活动；而用序列图时，会考虑财务主管使用计算机系统SCS记录报销单。

2. 业务序列图的关键要点

• 消息代表责任分配：消息箭头表示A请求B做某事，消息名称反映B的责任，数据流作为消息的输入输出参数。

  • 详细解释：不要把消息的方向当成数据流动的方向，避免出现成对的消息。

• 抽象级别是系统之间的协作：业务序列图上的对象是系统，包括人和非人系统。要避免抽象级别跳跃，混入不该有的内容。

  • 详细解释：不要暴露系统内部的组件，如数据库表；不要表达过细的交互步骤，这些内容应在分析和需求工作流中描述；不要把不具备任何智能的物体（如申请单）放到生命线上。

• 只画核心域相关的系统：只将核心域相关的系统放入业务序列图，非核心域相关的系统可以忽略。

  • 详细解释：如果某个系统对业务流程的改进没有影响，可以先画出来，发现无关后再删除。
  • 例子：在采购流程中，可以先画出工作人员使用Word制作文档，但如果使用Word或WPS不影响流程改进，则可以删除Word。

• 把时间看作特殊的业务实体：将时间看作是特殊业务实体，向各个系统发送时间消息。

  • 详细解释：时间和定时器不是一个概念，时间是外系统，定时器是其他系统用来和时间打交道的边界类。

• 为业务对象分配合适的责任：分配给业务对象的责任必须是该对象有能力承担的。

  • 详细解释：在不了解系统内部逻辑的情况下，不要把不属于业务实体或业务工人的行为强加给它们。
  • 例子： "Word无法承担写标书的责任，编辑文档的内容是工作人员的大脑"

3. 现状业务序列图的绘制步骤

• 如实描绘现状，尽力靠近真相，在尊重现实背后的理性的前提下再去改变。
  • 详细解释：不要把想象中的改进当成现状；不要把“现状”误解为“纯手工”或“规范”；“我是创新，没有现状”是错误的；“我做产品，没有现状”也是错误的。

4. 改进业务序列图的模式

• 物流变成信息流：提炼物中包含的信息，通过软件系统交换信息，增加流转速度和降低成本。
  • 详细解释：现在各领域在“物流变成信息流”方面留下的改进空间已经不多，随之而来要面对的是信息流转不通畅的问题。
• 改善信息流转：由一个软件系统完成各软件系统之间的协调工作，减少人与多个系统打交道的需要。
  • 详细解释：注意观察信息流转不通畅的地方，特别是一些隐蔽的地方。
• 封装领域逻辑：提炼人脑中封装的领域逻辑，改为封装到软件系统中，用软件系统代替人脑。
  • 详细解释：人脑相对于计算机，存在成本高、状态不稳定、会徇私舞弊等问题
• 阿布思考法：
  • 假设有充足的资源去解决问题，得到一个完美的方案；
  • 用手上现有的资源去山寨这个完美方案。

问答：

• 问：业务建模时使用活动图和序列图，应该如何选择？
  • 答：主要看建模人员更注重哪方面。活动图关注人，序列图把人当作系统，能更好的表达非人系统的责任。
• 问：画业务流程图时，如何避免把“现状”误解为“纯手工”或“本开发团队未参与之前”？
  • 答：要采用“投币法”思考，假设研发团队的人全部完蛋了，系统是路上捡来的，这样可以摆脱从自身角度看问题的错误。
• 问：如何找到业务流程改进点？
  • 答：可以通过观察物流和信息流，提炼领域逻辑，并结合阿布思考法，在资源充足的情况下，思考完美解决方案，然后用现有的资源去山寨。

希望这个总结对您有所帮助！