再谈基于SOA的需求分析

流程分析和业务建模

对于传统的面向结构和面向对象的分析方法，都少了流程分析和业务建模这个关键步骤，后续UML发展增加了业务建模部分的内容。SOA一个重要概念就是流程驱动IT，如果不从最起始的流程和业务建模入手，将会使我们只见局部而无法看到全貌；只知道有这个功能或服务，而不知道功能或服务产生的业务场景。

对于流程分析，体现由高端到低端逐层分解的过程，高端流程主要还是价值链流程分析，由价值链分析结合业务主题域的情况分解到1级和2级的业务架构视图。在 SOA的业务建模里面有个重要概念就是业务组件，业务组件可以是业务域按执行，控制，引导三个层面的进一步分解。每个业务组件本身就是由相互关联的业务活动组成，实现独立的业务价值，业务组件本身是粗粒度的。业务组件之间的交互必须要通过服务进行。对于业务组件，可以从五个方面进一步进行描述，如下：

业务用途 – 业务组件在组织内存在目的，表明其提供了业务价值

业务活动 – 为实现业务用途，每个业务组件需要实现一系列相互独立的活动 资源 – 需要什么样的人员或资产来支持这些活动

治理方式 – 每个组件是自治的，以相互独立的方式进行管理 业务服务 – 提供或接收业务服务，外界交互的唯一渠道

业务组件本身高内聚，松耦合，完成一个长流程需要业务组件间相互协作完成。对于业务组件的识别可以由顶向下或由底向下两个方面进行分析和识别，由底向上可以是根据业务域列出所有核心的业务功能，根据传统的UC矩阵分析方法，按照高内聚松耦合的原则来归类和抽象相应的业务组件；或者是由顶向下，进行高端业务和流程分解，充分考虑业务职能划分和流程阶段分解因素，端到端流程分解中的核心活动就是关键的业务组件。

业务架构图矩阵分两个维度，一个是业务能力，一个是责任级别。业务能力可以根据高端业务价值链分解来确定，责任级别包括战略规划，控制和执行三个层面。业务组件图本身是动态活动的静态构图。在业务组件图出来后，针对单个的业务组件，可以进一步做流程分解和流程分析，这个分析通常有两个方面，一个是跨职能带的流程图分析，一个是EPC流程图分析，在分解到较为底层的流程图的时候，我们都推荐EPC事件驱动的流程链分析方法，这个方法和现在BPM工具的流程建模方法基本类似，很容易直接过渡到BPM流程建模。

从业务流程到业务用例分析

在原来谈基于SERU的软件需求最佳实践的时候，我们就经常谈到了业务流程分析到用例的转化，对于流程分解和流程分析，到了底层后出来的就是活动，这个活动需要识别和转化为用例。业务用例是可以独立实现一个业务价值的业务过程，可以看做是业务组件本身进一步的细化分解。在SERU分析方法里面，强调了如下几点：

主题域分解 – 类似业务建模中的业务组件分析 流程分析 – 识别业务用例的关键步骤

领域建模 – 建立领域模型，识别关键的业务对象

业务用例是否是服务？很多时候业务用例本身就已经是流程服务或业务组合服务，因为它是一个实现了业务价值的业务过程。在SOA里面强调了业务操作和业务数据的分离，在传统的使用ROSE工具进行用例建模的过程中也可以看到用例分析和建模从前面的流程分析到后面的两个关键模型组件即是用例模型和业务对象模型。

模型部分：用例模型，业务对象模型，序列图活动图

文档部分：业务场景，基本流，扩展流，业务规则，数据描述，界面原型

从业务用例到服务识别和设计

在用例到服务转化的时候，可以看到一个用例实现可能还涉及到多个原子服务的识别和设计，这些原子类服务业务人员不关心，但是却能够较好的应用于服务的组合和流程的编排。用例到服务的转化一个重点是通过序列图来分析用例实现的过程，在这个过程中我们抛弃点泳道前面用户到界面层的交互，而重点关注逻辑层的所有交互点，这些逻辑层的交互点很可能都是重要的原子类服务。

在没有基于SOA前，可以看到业务和系统组件是强绑定的，业务变动会带来大量的技术层面的修改。而实施SOA后，在业务和IT之间会增加一个服务层，服务层实现了业务和IT的解耦。业务组件之间交互抽象和暴露为服务，服务用于业务实现时候的组合和编排，以增加组件对业务变化应对的灵活性。

这里有一个过程，即通过业务用例的实现分析，可以识别出大部分的原子类服务，然后对服务进行进一步的归类，合并和整理。这些原子类服务里面有些是需要跨组件或跨系统协作的，而有些仅仅是用于内部协作。服务本身的可重用性和管理成本又涉及到我们如何来控制服务的粒度，对于仅仅用于内部协作的建议仍然需要保留相应的服务接口，方便后续在有需求的时候很方面的转化为服务。