在业务建模中最繁重的工作——描述业务用例的实现，即业务流程，有几种可选的做法：
（以针对财务部“员工→报销”用例的实现为例）
【选择一】文本
书写业务用例规约如下：
1. 员工把报销单交给财务主管 2. 财务主管确认报销单已经过员工领导审批 3. 财务主管审批报销单 4. 财务主管将审批好的报销单返还给员工 5. 员工把报销单交给会计 6. 会计复核报销单 7. 会计记录报销单 8. 会计把报销单交给出纳 9. 出纳付款 扩展： 2a. 报销单未经员工领导审批： ……
【选择二】活动图
上面的报销业务流程用活动图可以表示如下：
【选择三】序列图
优缺点比较：
文本的缺点是不够生动，而业务建模注重生动，所以不推荐在描述业务流程时使用文本的方式，而是使用图形。不过，描述系统用例（需求）的时候，推荐使用文本，因为此时更注重精确。
活动图，或者说是流程图，应该是在开发人员中使用频率最高的图形了。活动图可以看作是流程图的扩展，添加了分区（Partition，即UML1.x中的泳道）、分叉（Fork）、结合（Join）等元素，UML2.x进一步增加了Petri网的元素，表达能力更加丰富。
流程图最开始用于在编码之前表达代码逻辑，也就是所谓“详细设计”。随着软件越来越复杂，编程语言表达能力也越来越强，针对某一小段代码画流程图变得没有必要，而且如果类某个操作的代码复杂到要画一张流程图来说明，恐怕这个操作已经有问题了。
序列图用面向对象的思想描述业务流程，把业务流程看作是一系列业务对象之间为了完成业务用例而进行的协作。选择采用序列图来描述业务流程有以下几点理由：
（1）活动图只关注人，序列图把人当作系统。
软件开发的目的就是要改进当前的现实，可能是引进一个新系统，也可能是升级现有的系统。信息化发展到今天，待改进的当前现实中不只有人肉系统（即业务工人），还有大量的非人系统（即业务实体），这些非人系统封装了许多最开始位于人肉系统中的逻辑。将来和新系统交互的系统（也就是新系统的执行者），有可能只有一部分是人，另外一部分是非人系统。互联网的发展，更是使得许多商业或政府组织用来和大众打交道的接口系统不再是人肉系统，而是电脑系统。
使用活动图描述业务流程时，开发人员往往只注意人或部门的活动，忽略了非人系统的责任。如，会计记录报销单和出纳记录付款信息都需要用到现有的电脑系统SCS，活动图未能表达出来，序列图表达出来了。虽然活动图可以稍作变通，将非人系统也单列为分区，但我见过的绝大多数活动图，分区的抬头只是描述人或部门。
（2）活动图表示动作，序列图强迫思考动作背后的目的。
对比左图（活动图）和右图（序列图），右图不但表达了非人系统的责任，同时也清晰地揭示出来营业员这个岗位对外暴露的责任是：受理申请，这也是市民对于营业员的期望。期望和承诺，是用例和对象技术的关键思想。使用序列图来做业务建模，“对象协作以完成用例”的思想就可以统一地贯彻业务建模和系统建模的始终。
（3）活动图更“灵活”，序列图更不“灵活”。
有人认为活动图胜过序列图的地方是它灵活，但这种灵活是一把双刃剑。活动图很灵活，它的控制流箭头可以指向任何地方，就像编码原始时代的goto语句，所以活动图很容易画。不过，“很容易画”的活动图，也比较容易掩盖开发人员对业务流程认识不足或者业务流程本身存在缺陷的事实。
序列图通过alt、loop等结构化控制片断来描述业务流程，强迫开发人员用这种方式去思考。对于现状确实乱七八糟的流程，描述起来相对要困难，需要按照场景分开画很多张序列图来表达，但这也揭示了业务流程的糟糕现状。
必须要承认，用活动图或类似活动图的手段（如BPMN）来建模业务流程是主流，而且已有的参考资料和模型积累也非序列图可比。选择序列图来做业务建模，最主要原因是“把人和电脑系统一样看待”。如果您使用其他方法来做业务建模已经做得很好，而且能解决这个问题，就没有必要切换到序列图。