基于SOA思想的业务建模和需求分析流程和案例分析

　　今天整理下基于SOA架构思想下的业务建模，服务识别和需求分析规范流程。并给出一些案例数据作为参考。在前面文章里面经常谈到SOA是否过时的问题，在这里再次强调下对于ESB服务总线可能会逐步淘汰，但是SOA架构思想本身不会过时，而且在平台+应用成为主流IT架构规划思想下，会更加发挥巨大的作用。
　　SOA架构思想核心是服务，而能力即是服务。
　　当前整体IT系统建设规划，都需要考虑可复用共性能力下沉，然后以API接口服务方式暴露给上层应用使用，进行能力开放。
　　在电信eTom模型中经常提到的资源-服务-应用三层分层架构思想，讲是指导当前企业数字化转型，微服务架构实施，云原生转型核心的架构指导思想。
　　比如我们经常谈到的中台里面的共性业务能力下沉然后以服务方式提供给前台使用，再比如谈到的云原生PaaS平台建设中应该逐步从资源层走向服务层，整个云的重心通过重心逐步上移等都是这个分层架构思想的核心体现。SOA需求分析总体说明
　　服务需求的主要工作是基于SOA的需求分析方法论，以流程和业务驱动IT的指导思想，对业务系统进行业务建模，用例建模和业务实体建模，形成企业级需求和业务功能清单，作为后续服务识别的输入。
　　对于服务需求，以流程分析为基础，通过流程的逐层分解，细化出关键的业务活动，将流程活动识别为业务用例，并对业务用例进行建模。用例建模本身可以作为业务系统功能开发的需求规格说明书，同时对用例分析和功能操作的识别形成业务域->流程分解->用例->业务操作的分解过程，用于后续服务的识别。
　　在整个分析过程中，流程的关键活动或业务用例的操作都会涉及到业务实体对象，因此需要对业务实体对象进行单独建模，分析实体对象的关键属性和对象间关系，同时分析实体对象和业务操作间的U/C矩阵，作为后续公用服务提取的基础。
　　整个需求分析中的功能分级模型可以用下图描述，其中流程分析和流程分解对应到Level1和Level2层。用例对应业务活动层Level3，业务操作对应Level 4层的业务活动。
　　若是没有服务识别与发现，SOA是不可能实现的。服务识别（Service Identification）用于处理那些企业所采用的识别新的共享的候选服务（service candidates）的规程和指导。服务识别开始于需求分析，终止于识别出候选服务集。
　　在形成了候选服务集合后，再跟进项目目标需求，服务本身的优先级评估来确定最终的服务迭代实施计划，同时对第一批要实施的服务进行详细的服务定义操作。服务识别整体流程
　　从上图可以看到整个服务识别过程分为四个阶段，即业务建模，用例建模，服务识别，服务评估四个关键阶段。
　　对于服务需求，以流程分析为基础，通过流程的逐层分解，细化出关键的业务活动，将流程活动识别为业务用例，并对业务用例进行建模。用例建模本身可以作为业务系统功能开发的需求规格说明书，同时对用例分析和功能操作的识别形成业务域-》流程分解-》用例-》业务操作的分解过程，用于后续服务的识别。
　　在整个分析过程中，流程的关键活动或业务用例的操作都会涉及到业务实体对象，因此需要对业务实体对象进行单独建模，分析实体对象的关键属性和对象间关系，同时分析实体对象和业务操作间的U/C矩阵，作为后续公用服务提取的基础。
　　对于服务本身可以分为业务服务，数据服务，技术服务等。从上图也可以看到通过业务流程分析和业务架构梳理来识别业务服务；通过数据架构和数据建模来分析和识别数据服务；通过技术架构分析来识别关键的技术服务能力。业务建模
　　业务建模（Business Modeling）是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统。业务建模（Business Modeling）是一种建模方法的集合，目的是对业务进行建模。这方面的工作可能包括了业务流程建模，对业务组织建模，改进业务流程，领域建模等方面。
　　SOA服务识别中的业务建模描述项目或业务系统产生的业务背景，项目的高端业务流程图和各业务域流程分解图。
　　如分析和描述物流系统所涉及的业务背景和流程的时候，首先可以给出端到端的业务全流程图，然后再分解为采购需求，招投标，采购订单，出入库管理几个二级子流程，对于招投标二级子流程又可以根据招投标类型不同分解为更细的三级子流程。
　　业务建模的输出包括流程分析说明，全局用例模型和全局数据建模。其中全局用例模型作为第二步骤用例建模的输入，全局数据建模可作为第三步骤数据建模的输入。
　　业务调研
　　该部分包括业务需求调研，包括业务流程或问题产生的背景介绍，具体的业务需求收集和分类。现有的业务流程现状，业务需求所在的具体业务域，涉及到的岗位角色人员信息等。
　　业务调研包括了业务流程，业务数据，业务系统三个方面的内容，业务调研内容具体输出为业务调研文档。
　　流程分析
　　流程分析需遵循端到端流程分析的思路，对流程进行二级，或三级分解。流程分析前可以先进行主题域分析，绘制上下文关系图，通过上下文关系图来进一步识别关键业务流程。具体参考流程分析指导书。
　　通过上下文关系图对主题域进行分析后，可以得到主题域中所包含的业务事件，而这些业务事件就是业务流程的起点。流程分析时，需要注意流程的目标性、内在性、整体性、动态性、层次性、结构性这六大特性，流程是需求分析的重要内容，流程图对于和用户确认需求以及向开发团队传递需求都是非常重要的。可以选择使用UML规范中的活动图或商业建模标准中所推荐的跨职能流程图对流程建模。
　　通过流程分析可以进一步明确流程的的关键业务活动，每个业务活动的输入，输出，涉及的岗位角色，传递的业务数据等关键内容。具体流程分析输出包括：
　　业务系统所涉及的端到端业务流程图
　　业务域的业务流程分解图
　　针对业务流程图进行的详细业务流程活动和输入、输出描述
　　以供应链端到端流程梳理分析示例参考如下：
　　端到端业务流程在系统间交互分析示例如下：
　　可以看到通过端到端流程分析基本能够找到核心的业务阶段，核心的业务活动，业务对象数据，跨业务组织或系统的核心交互协同点等。
　　全局用例建模
　　根据业务域划分和业务流程分析，进行用例的识别，流程中清晰地表达了角色所要执行的业务活动，这正是用例的内容，用例即用户使用系统完成业务活动的场景在将业务活动及报表转换为用例后，使用UML中的用例图对用例建模，用例图不但可以表达出用户是如何使用系统的，还可以表达出用户与用户之间的关系，用例与用例之间的关系。
　　对于流程图转换到用例的具体方法，可以参考需求分析指导书中的详细说明和转换原则。对于业务用例分析和建模基础，请参考UML相关文档。
　　全局数据建模
　　本部分主要是根据流程分析和用例建模，抽取流程和用例中的关键业务实体对象进行数据建模分析。全局数据建模只需要分析出关键的业务实体，实体描述和实体之间的关系即可，在业务实体建模环节讲进一步对该部分内容进行细化分析。
　　全局数据建模需要输出数据概念模型，数据实体对象清单和实体描述信息。
　　具体的实体描述信息示例参考如下：
　　用例建模
　　用例建模首先是流程建模中的关键业务活动会转化为用例，这在全局用例建模中会进行分析。从流程图中转换用例时，先基于流程图分析流程图中的职能带区(泳道)哪一些是不直接使用系统，将其排除，将余下的职能带区(泳道)转为角色，将流程图中的业务活动及判断转换为用例，决定活动是否要转换为用例的标准是它是否属于系统范畴，而决定判断是否要转换为用例的标准是它是否独立。
　　用例建模需要参考用例编写标准模板进行用例的编写。其中包括了用例基本信息，用例上下文，前置条件，用例基本流，扩展流，业务规则，假设约束等描述等。
　　一个用例建模的参考文档模板如下：
　　业务操作分析
　　在用例建模的过程中，用例本身即是一个实现业务价值的交互业务活动集合。因此可以对用例进一步分析，识别更细粒度的业务活动和操作，这些业务活动或操作可以从基本流，扩展流和业务规则中寻找。业务操作分析要求如下：
　　业务操作即业务活动中的业务任务，有明确的业务含义
　　业务操作本身就是可复用的业务单位
　　业务操作本身采用动宾结构进行描述
　　业务操作本身具有高内聚，松耦合性的自治性数据建模
　　在这块实际上是在面向对象的用例分析建模思路上引入了部分结构化的分析思路。对于数据建模和数据CRUD分析实际是在结构化分析中经常使用的需求分析和建模方法。
　　数据建模阶段包括了业务实体分析和数据CRUD分析两个部分内容。
　　业务实体分析
　　用例模型只是对用户如何使用系统的业务场景进行建模，如果要构建系统，还需要对系统的框架进行建模，即要弄清楚目标系统所要管理的＂物＂：业务实体，并弄清楚这些业务实体间的关系。
　　在对业务实体建模时，一般是使用＂名词动词法＂识别出业务实体，并逐步确定实体间的关联关系及其属性。
　　对业务实体建模选择使用UML规范中的类图或实体图作为模型，类图/实体图中的一个类/实体表达一个业务实体，类/实体的属性用于对业实体的属性建模，而它们之间的关系则可以用来对业务实体间的关联关系建模。对于比较复杂的业务实体，还可以采用UML规范中的状态图对其建模，可以表达出业务实体的状态切换与触发事件的关系。
　　业务实体分析中需要对识别的业务实体详细描述业务实体的数据字典信息，包括业务实体中各个数据项的类别，长度，完整性规则，业务用途等相关信息。
　　实体使用U/C矩阵分析
　　实体使用分析主要包括业务实体跨系统使用情况分析和业务实体系统内使用情况分析两方面的内容。
　　跨系统使用情况分析，主要是为公共数据服务的提取做准备，在该分析矩阵中需要列出业务系统产生的关键业务实体，分析这些业务实体在MSS域相关业务系统中的CRUD情况，作为后续数据服务识别的一个输入。
　　业务实体系统内使用分析主要分析系统内关键业务实体和业务用例之间的对应关系，找寻系统内可复用的业务操作，为系统内服务识别做准备。服务识别
　　服务识别开始于需求分析，终止于识别出的候选服务列表。为了有效的实施SOA工程，应用不能孤立于其他应用而独立开发。SOA的应用应该可以共享服务，这些服务不单单属于某个独立的应用，并且有自己的生命周期，能够被独立的管理。在SOA工程中，为了有效的管理需求，各个项目必须知道其他已经存在的项目、正在开发的项目以及未来将要开发的项目需求。所以，与SOA服务相关的需求应该在企业级层面管理。
　　候选服务是被识别出用于系统重用的业务功能。一个候选服务不一定一对一地对应到实际交付的服务，比如，在分析阶段，一个粗粒度的服务可能对应到需求中两个或两个以上的初始候选服务。另一方面，服务识别并不是简单地识别出候选服务，也包括了一系列的校验和评估。
　　数据服务识别
　　通过业务建模和数据建模分析，识别出供应商是一个业务实体，根据业务实体跨系统使用情况分析，发现供应商业务实体被多个业务系统所使用，因此供应商业务实体可识别为可重用的数据服务。
　　对该企业供应商实体进一步分析，供应商实体还可分解为几类子实体，识别出的候选服务清单示例参考如下：
　　业务服务识别
　　根据用例建模对供应商管理中每个用例进行了详细的业务操作分析，识别出可重用的业务操作为业务服务，得出的业务服务候选服务清单示例参考如下：
　　服务校验和评估
　　服务校验主要是对服务和需求的匹配度，服务的重用性，服务设计的可适应性，服务的预期扩展能力等进行校验。服务的校验直接影响到后续服务的评估。
　　校验服务可重用性
　　这个步骤要求通过分析来确保识别的服务可重用，并能满足业务和项目的需求。SOA的一个核心价值是识别可重用的服务。因此在该步骤需要校验该服务的服务重用度，并对服务可能潜在存在的服务重用点进行分析，以保证在服务设计的时候充分考虑服务的可扩展性。
　　如果识别的服务不可重用，则需要考虑在服务评估的时候降低服务的实现优先级，或者暂时不纳入服务接入和实现的范围。
　　校验服务设计的适应性
　　这个步骤确保这个服务是以适合用户请求的方式设计的。特别的，对特殊用户的可重用服务来说，QoS和接口可能是不用验证的。然而，需求要与客户的需要相匹配，一个服务的其它地方，像QoS和接口设计可能使服务不适合重用。这可以对存在的候选服务进行有用的扩展，或者要建立一个新的服务。
　　服务的评估则是从服务的可重用性，服务的适应性，服务的技术实现难度，服务的灵活度等多个方面进行评估，以确定最终的候选服务清单和服务优先级排序。
　　服务影响范围评估
　　服务的影响范围包括了跨企业级，企业级，企业部门级和应用级。服务的影响范围越大，这服务评估的权重越大。
　　对于跨业务应用的服务，往往任何一个服务的变更都会影响到多个业务系统的正常使用，因此这类服务在服务设计时应该充分考虑到服务的健壮性，服务安全和服务性能。
　　服务可重用性评估
　　服务的可重用性包括了服务跨业务系统的可重用性，服务在业务系统内的可重用性。跨业务系统的可重用性权重大于系统内可重用性权重。服务预计的重用次数是服务可重用性权重评估的重要参考。
　　如果一个服务可重用性较低，则在服务实现前期只需列入候选服务，同时在服务实现的时候可以先实现为API接口，在需要的时候再暴露为标准的服务。
　　服务敏捷性和业务重要性评估
　　任何服务的识别和使用都是为了满足业务敏捷性和核心业务价值实现的需求。在对服务敏捷性进行评估的时候主要考虑该服务是否为企业核心业务流程和核心业务价值链上的重要IT资产，当实现该服务后可以提升了业务敏捷度和业务灵活性等。
　　服务敏捷性评估完全是通过业务视角来评估服务实现的优先级和权重。
　　服务技术实现评估
　　本部分评估包括了服务技术实现的难易程度的评估，服务技术实现方法的评估。
　　服务实现的难易程度一方面受到服务实现方法的影响，一方面受到服务安全性，性能，可靠性，高可用性要求的影响。因此需要从多个维度评估服务实现的难易程度。
　　服务实现方法包括了服务同步/异步方式的评估，采用的标准协议的评估，是否采用ODI大数据量传输模式的评估等。
　　服务校验评估参考模板如下：
　　服务规范编写
　　服务规范编写实际已经到了详细的服务定义阶段，即对已经明确要在当前迭代版本进行实施的服务进行详细的服务定义。其中包括了服务实现方式，接入方法，详细的输入输出，服务使用场景，服务非功能性需求等。
　　确定服务实现方式
　　对于服务实现方式的确定包括了服务接入方式，服务同步/异步，服务调用方式等多个方面的内容，具体说明如下：
　　确定服务接入方式
　　对于服务的接入包括了Web Service、JMS消息、数据库、FTP文件适配等多种接入方式，因此在服务规范编写中首先需要确定服务的接入方式，以指导后续的服务设计和服务开发。
　　确定同步/异步服务
　　确定服务提供和服务消费采用的模式，对于服务同步调用模式下还需要进一步确认服务本身是实时调用还是定时调用。对于异步模式还需要进一步在服务规范中明确对应的消息回写接口服务。
　　确定服务详细输入/输出
　　服务的详细输入输出包括了服务消息头、服务输入和服务输出三个方面的内容。对于服务消息头和服务异常和规范类消息输出已经在服务设计规范中有详细描述可以参考。
　　在确认服务规范的详细输入和输出时候，需要参考服务调研报告和服务接口需求文档，并和服务提供方，服务消费方共同确认每个数据项的含义，数据类型，数据本身的约束规则等相关内容。
　　确定服务非功能特性需求
　　对于服务的非功能性需要主要包括了服务调用得频度，服务调用传递的数据量，服务消费和调用得时效性和性能要求，服务本身的业务优先级等相关内容，这些都已经在服务规范模版文档中有详细的定义。
　　服务规范模板参考如下：
　　欢迎关注 @人月聊IT 分享云原生，微服务，数字化转型，思维类文章。公众号同名，周一，三，五更新。