图 3 展示了流程、子流程及任务的等级关系：
图 3. 流程、子流程及任务之间的等级关系
图 4 展示了购买项目的业务流程模型：
图 4. 购买项目的业务流程模型
服务确定
我们确定了基于内部组件交互的候选服务，我们从业务流程中获得了这样的交互。基于所选的 CBM 零售业务组件，我们首先通过组件将业务任务分组，然后确定内部组件的交互模式。这种内部组件的交互最初在 Rational Rose 中使用 UML 时序图将其建模。
为了最终得出服务规范（在 WSDL 中适用的），将这种内部组件的交互建模得更好的方式是有效地使用 Business Integration Modeler。在回顾了产品特征之后，我们发现实现该功能的一种创新的方法：我们可以使用组织单元结构来表示组件，并且我们可以使用这种组织单元的出入流作为天然的服务候选。以这种方式，将任务分配给特定的组织单元依照它的核心业务功能，并且任何通过组织单元传递的信息都代表内部组件的交互并且可以作为候选服务。
图 5 通过组织单元以泳道视图展示了购买项目的业务流程模型。
图 5. 购买项目业务流程模型的泳道视图
从泳道视图中可以明显看出下列是可以被发布的用于购买项目业务流程的两个候选服务：
在 Web 上找到存货——由 Web Store 组织单元发布
在商店中找到存货——由 Inventory Management 组织单元发布
为了确定数据服务，我们进一步分析了核心 POS 解决方案和已支持的或即将被支持的遗留系统之间的数据流。此外，设计数据服务使它们能够被访问以满足应用程序的大多数（或所有的）数据需求。这里有 SoT 解决方案所需的三种类型的数据服务：
支持内部组件交互的数据服务
支持将 POS 事务数据上传到遗留系统（私有格式）的数据服务
从遗留系统中下载公共支持的数据（包括商品、价格和财政等）的数据服务
我们也提取了通用的安全及工具服务来帮助内部组件的交互。
然后，我们列出了在这一步中确定的服务并将它们映射到文档中。图 6 展示了购买项目的候选服务清单。
图 6. 候选服务清单
3）业务流程实现
在这一步中，我们使用已确定的一套服务来说明可以通过应用程序组件和集成服务来实现所有需要的业务流程（请参阅图 14 的购买项目的服务组合视图。
文章来源于领测软件测试网 https://www.ltesting.net/
