活动图通过重要标记符号，提醒使用软件的环节，软件需求慢慢浮出水面。
接下来，我们将活动图转化成序列图，在这个转化的过程中，“系统”作为一个业务操作的“人”，出现在序列图中。
开始绘制序列图
在序列图中，顶部方块代表业务操作者，也就是能主动发起动作的人或机器。我们将系统“数据采集平台”也放上来。在《软件方法》，真正的人又被称为“业务执行者”，而机器会被叫做“业务实体”。不过我这里就统称为业务操作者。
下面的虚线叫做“生命线”，也就是还在操作的过程。
我们可以观察到，序列图如果也抽象成“泳道”的话，它的“泳道”，比业务活动图多了我们需要设计的“系统”。
接下来，我们将活动图的活动，采用“灵魂四问法”，转化到序列图上（参考《Use Case入门与实例》）。
对着每个活动，提问：
1. 谁是业务执行者？
2. 需要系统协助吗？
3. 系统需要提供什么服务？
4. 谁是系统的支持者？
下面举例两个活动：
活动1：业务管理员发布采集任务
活动2：采集员现场采集人口信息
活动1，业务管理员发布采集任务，使用灵魂四问：
谁是执行者？
答：业务管理员
2. 需要系统协助吗？
答：不需要
活动1：业务管理员发布采集任务
在序列图，我们需要体现的重点，也就是要放大描述的地方，是其他的业务操作者如人类，和要设计的系统之间的交互。所以当一个业务活动，不需要系统提供服务支持的时候，我们只要在序列图通过业务操作者“自操作”表达他需要完成的活动就可以了。
活动2，采集员采集地址数据，使用灵魂四问：
谁是执行者：
答：采集员
2. 需要系统协助吗？
答：需要
3. 系统需要提供什么服务？
录入采集数据
4. 谁是系统需要的支持者？
没有
活动2：业务员采集地址数据
在序列图，我们通过“消息”元素（带箭头的线段），表达系统能为业务采集人员提供的服务。
在《软件方法》讲到一个点：序列图的消息（统一建模语言），即拥有“请求”之意。“请求系统做何事”。所以我们不需要在消息加上“请求”两个字。
上图的采集人员和待设计系统之间的关系，就是“采集人员请求系统录入人口数据”。
在《软件方法》提到可以思考，购买软件，购买服务的人，为这个产品买单，是否冲着这个服务来的呢，如果是的话，这个服务，你就可以体现在业务活动，业务序列里。
从业务层面上看，我们可以从“客户/用户愿不愿意买单”这个角度反向地检查，是否系统不得不提供这样的服务。
例如使用系统录入采集数据，我们从这个事情，又可以引申出，采集后的数据是否需要维护的问题，但是数据维护又是让序列图变得复杂，且让看图了解需求的人更加眼花缭乱。这个部分可以考虑自我提问：“是否系统不得不提供这样的服务”。例如数据维护即使没有，也能让业务运行起来，好像可以，所以它可以不作为核心需求出现。当然，我们并非不考虑维护，健全“录入采集数据”的需求，而是在下一个阶段，推导软件用例的时候才考虑把它引入进来。
另外一个例子“登录”，它是为了解决安全性问题不得不考虑的问题，客户/用户买的不是的登录，而是对自己的信息安全的保障，所以安全性是需求，而登录不是需求，它是安全性要求背后的一种设计解决方案。所以登录这种，也不会在我们的序列图出现。
系统提供的服务，要看是业务操作者的操作动作来完成的，还是系统给业务操作者提供的一项保障。如果是一个动作，我们才放到序列图，如果是一份保障，我们可以后续以文字的形式加以说明。
例如，上面的例子，”登录“背后的安全性需求，我们也不会体现在序列图里面，而是在先以文字的方式简要说明，在后续的用例规约阶段，通过文字的方式描述在系统层面的质量需求里面。因为安全性它不是一个系统的动作，而是系统需要提供的保障。
我们在使用序列图分析软件需求的时候，更多的，是体现“系统不得不做的需求”，而不是“系统还可以做的需求”，这样，就可以让我们通过这张图，构建系统的核心需求图景。而“系统还可以做的需求”，则留到下一个阶段，也就是推导软件用例的过程进行。
参考书籍：
《UseCase入门与实例》高焕堂
《软件方法（上）》潘加宇
网友评论