软件工程中业务模式的使用（第二部分）

Philip Teale

微软公司

Robert Jarvis

SA Ltd

本文研究了怎样去开发基于业务功能、数据、业务构件的业务模式，并且演示了怎样利用这些业务模式来构建软件系统。

介绍
业务功能
数据模型
业务模式和行业方案
结论：设计模式和行业方案的框架和方法

文章一共有两个部分，旨在探讨是否能够用一种结构化的方法去定义业务模式，如果能，这些业务模式又是否能够为那些支持业务的系统构建者们提供有用价值。本文的观点是这种价值是确实存在的。

文章的第一部分已经出版在刊物第二期上了，第一部分探讨了怎样去定义对软件工程师有用的业务模式。在这一部分中，介绍了企业结构框架SAM，来分析可能性，并得出以下结论：

• 业务模式支持业务功能

• 业务模式需要数据来支持描述业务功能

• 业务构件是业务所需要的数据和功能的IT代表

• 业务模式的结构应该能够随意地支持业务功能、数据和构件。这在分布的企业、决策者或者应用不同技术和运作环境的单位都是非常必要的

而且，也给出了具有上述特点的业务模式的定义。

文章的第二部分描述了怎样去开发基于业务功能、 数据和业务构件的业务模式，同时介绍了工程软件系统中业务模式的使用方法。

第二部分摘要

本文用一个现实简单例子来阐述开发业务模式所需的业务功能、数据、业务构件的标准方法。这里并不讨论它的理论基础，也不讨论理论之间的关系。文章的目标在于证实：“这种方法能够被实现，并且知道怎样去实现”，而不是提供具体的实现步骤。文章的开始，介绍了一种方法，来定义所需的业务功能、数据、业务构件，然后用PRM来指导接下来的整个过程。文中采用的例子是关于医疗行业的，但所用的技术是任何领域通用。并且这些技术也已经应用在实际的项目中。需要着重申明的是，不是必须刻意地使用这些技术，技术本身并不重要，关键的是结果。正是因为这些结果，才使得设计更加精确的模式和可交付的软件系统成为可能。

模式和系统之间的不同点

如果没有太多关于模式的经验，那么，你在阅读这些例子的时候，就应该把它们看作是一个系统开发而不是模式，这是因为在软件工程中，模式是开发局部系统的踏脚石。模式保证了从一个可靠的起点开发到最后的目标系统的部分方法。它看似简单，实际上它本身也不是一种具体的解决方案而是抽象的，使得你不得不去创建一种符合自己需要的具体方案。创建模式时最谨慎的是正确获取它的抽象层次，很少有抽象来约束模式的有效性，因为它是被逐渐具体化的。但是许多抽象也限制了模式的实用性，从而使得它提供的实践价值比较少。

今天一个共同的趋势就是设计一个叫“消息经纪人”的服务去提供消息的路线和保证各种IT服务之间的转换。高度抽象的模式应该十分精确—如果想要提供消息的路线和保证各种IT服务之间的转换，就用“消息经纪人”，它的益处在哪里呢？这个思路虽然有些作用，但却不能提供更多实际的帮助。

另一方面， 当银行操作统一的顾客视图时，我们建立一个消息经纪人来处理那些需要的IT服务。那么，能够称这种方案为业务模式吗？答案是肯定的，但是它有多少价值呢？这种方案太具体并可能存在潜在的可重复的方案，所以还是不能视之为业务模式。最有效的业务模式应当有这样的优势：能够被抽象、反复地应用到系统构建时的各个层次中，解决许多行业问题。本文给出的业务构件规格书的例子就是医疗行业业务模式。我们应该能清楚地认识到业务模式的以下重要特性，即一些模式将对行业外并无益处（像本文中的例子），而另一些却不（它们能够代表通用的功能）

诚然，那些跨行业通用的业务模式确实能够被相当成熟地用来识别某些行业领域，但那将是另外一种完全不同的讨论了

为了开发业务模式，我们首先必须发现、定义和文档化相关业务功能。以下是主要任务：

1. 发现描述问题空间的原子功能集，在功能建模里称之为“原始功能”，类似地，在业务过程重组里称作“基础过程”

2. 把这些原子功能聚合成更大的更条理的功能组

“原子”的意思是功能不能够被分解，一旦开始，功能就应该被完成和接受。

因此我们实际追求的业务模式是将业务功能定义在一种可以分解的层次，这些层次间有紧密联系。特别是数据层，如果发现业务功能定义在整个体系结构的第四层，通常可以形成数据层实体间的CRUD（创建、读取、修改、删除）关系。业务功能可以采用自底向上或者自顶向上或者二者混合的方式来分析和定义。

自底向上分析

分析员使用这种方法，聚焦用户典型业务领域，去分析他们的业务过程。用例图或者任何能表达业务过程中执行顺序和并行任务的方法，将会被采用，随后，分类、分析过程集合。通常可以注意到，许多步骤或过程中执行的低层次的任务将在在不同的过程中被重复执行很多次。因此，必须识别这些多余的任务，并且从原始功能的必要集合中排除出去。图１用一个简单的流程图演示了这一过程。从图中可知，任务Ａ是多余的，应该仅出现在原始集合中一次，通过这样类似的分析，最后得出必要的原始集合。再反复合并功能，得到如图２所示的动态结果。从业务模式的角度考虑，自底向上的分析方法存在一些问题。

图１　过程的发现和合成

1. 对于包含许多用户的庞大过程，自顶向下地分析过程工作量非常大（为了减轻工作量，一种折衷的办法是，采用过程分析和用例分析相结合的方法来提炼过程）

2. 过程的本质在于对“像-是”的情况的分析，只要这种分析足够清晰，它的结果就可以接受。

3. 为了确保业务模式的正确性，必须在相同的领域范围内进行反复的分析验证。在这个过程中就会发现很多实际的问题。

自底向上的分析方法的好处在于，基础分析为驱动业务模式方案奠定了基础，验证业务模式的关键在于成功地实践，一旦选好了实例，自底向上的分析方法的这些优势就会有明显体现。

自顶向下分析

图2中的功能分解依靠另外一种方法——自顶向下分析方法来进行，这种方法首先假定最上层的结构，然后逐步填充下面的层次，直到充分详细为止。

图2 业务功能分析的典型实例

很明显，有必要对分析的结果进行验证，看它是否正确地反映了现实世界。因此，自顶向下的分析方法从描述最抽象的业务问题领域开始，然后逐步分解，直到最原始层为止，以此来验证结果的正确性。这种方法能够通过一种标准方法来实现，就是用于功能建模的IDEF0，或者用于业务过程建模的扩展UML也可以。

事实上，很多前因后果决定了自顶向下的分析方法不需要详述业务过程。

自顶向下的分析方法在模式定义中的好处是行业顾问完全能做这项工作，这些顾问们往往有和许多客户在某个问题领域打交道的许多经验，因此有他们来完成这项工作将会既准确又迅速。本质上，这种分析方法一方面执行了和专家进行知识挖掘的任务，另一方面，它也减少了必须直接分析的实例数目，改变了分析员的角色——不再是以前的工作人员而是现在的浏览者。

混合分析方法

实际上，我们经常把自顶向上和自底向上的分析结合使用，在过程综合到层次结构低层次分解之间反复的变换。这样做的好处是，可以用自底向下获取的现实世界功能来验证假设的自顶向下的分解。实践证明，这是最快、最可靠的方法。

功能分解实例

以下是关于病人医疗情况的实例，使用上述方法来进行业务分析，从而演示了核心业务模式的形成过程。

首先，分析问题领域的功能性需求。以乳房癌治愈为例，得出40多个过程，参与的角色有病人、医生、系统管理者和机密保管员等。其中机密保管员这个角色会随着信息的机密性改变而改变。这些过程是用UML用例来文档化的。它们在许多用例中都有相同或者相似的子活动高度地重复。因此，我们抽取并整理了这些活动，形成以下清单：

• 病人登陆（用户检查）

• 病人注销（核查）

• 搜索申请的病人

• 管理病人详细信息

• 管理病人权利

• 查看私人区域

• 查看个人GP详情

• 管理个人一般健康数据

• 管理捐赠人明细

• 管理病人明细

• 管理家庭成员

• 查看采取的免疫措施和种痘

• 管理个人权利

• 查看病人病厉

• 查看病人私人区域

• 申请病历

• 复查病历

• 创建病人事件

• 管理病人个人事件

• 建立病人疗程

• 查看病人疗程

• 查看个人病历

• 定义普通协议

• 管理个人协议

• 维护医疗项目

• 执行医疗代码翻译

• 获取其它医疗代码

• 编制其他医疗代码

• 维护医疗路径

• 管理预约

• 改变预约

• 访问事件明细

• 访问系统索引

• 维护临床过程

• 维护角色定义

• 维护组/队结构

• 维护组/队成员

• 维护许可证授权

• 维护医生注册

• 医生登陆（身份鉴定）

• 医生注销（核查）

• 查看医生许可

• 维护具体许可

• 定义普通许可

图 3 医疗实例—功能分解

图三表达了医疗实例功能分解过程。利用主题和功能的相似性把各个分散的功能归纳到更高的层次上去。

医疗实例有综合的数据模型。经过对同一个问题领域的数据进行分析，共定义了31个主要的实体，如病人、医生、病人事件、医疗路线等等。数据模型需要识别实体的候选码和它们的主要属性，描述实体之间的相互关系，分解所有的多对多的关系。并且这些操作就是在功能分析时并行地得到的。

据我们所知，数据模型应该支持所有已识别的功能需求，反之亦然。在实体之间的相互关系和聚合的基础上，上述31个实体已经分配给8个数据项。这些项分别是：

• 病人

• 病人协议

• 医疗路线

• 医疗项目

• 临床过程

• 角色、团队和组织

• 医生和许可

• 本地系统

这些数据项是目标数据库和动态内容定义的第一步。图4显示病人数据项的全部内容，采用传统的E-R图描述了数据实体以及实体间的关系，并且标出了每个实体的主键。框外的实体是属于其它数据项的，但是与框内的实体有着紧密的联系。

图 4 病人数据项的实例模型

映射关系

功能分解的层次结构定义了需求功能，关系数据模型定义了需求数据。此后，我们通过比较功能和数据二者之间的关系，能够得出一个初步的构件体系结构。具体的做法是建立一个矩阵，行表示功能，列表示识别的实体，行列交叉处的值有C、R、U、D四种：

• C代表“创建”数据实体实例的功能

• R代表“读取”数据实体实例的功能

• U代表“修改”数据实体实例的功能

• Ｄ代表“删除”数据实体实力的功能

得出的结果如下图5所示：

图 5 功能和数据的 CRUD 的矩阵

矩阵簇群

我们确保矩阵中每一列（数据实体）至少有一个创建操作，每一行（功能）都有少许活动。请注意矩阵中的操作并不是绝对正确的，特别是读取操作。同时表中没有制定删除操作。现在用归类和聚合的方法来分析矩阵，以获取那些共享创建和修改操作的功能组和实体组。对于数据模型中内部实体动静态关系，我们采用高内聚、低耦合的原则进行功能分解。然后调整矩阵，合并关系紧密的功能和实体，最后得到的就是候选业务构件。具体的算法描述（"North West"算法）超出了本文的范围。图6所示。

图 6 矩阵簇群

业务构件的来由

首先应该说明业务构件是用来做什么的。一个业务功能创建、读取、修改和删除数据。分组聚合相同数据实体的创建和修改功能，用诸如相互的分簇技术定义一个必要的构造块，就形成了业务构件，用它来构造模式、系统或应用，以便支持特定的业务过程。业务构件是一个驱动领域的实例——它是从其它2个领域的相互关系中推导出来的。这是一个强大的技术，可以获取企业体系结构中隐藏的特性。通过封装功能和数据到一个构件中，软件重用和重构才能切实可行。更进一步说，业务构件提供了一些服务，使得它们能够和其它业务构件提供的服务相结合一起协调的工作，完成一个具体的应用。

业务构件来源于对服务和接口的簇群分析，业务实体构件、数据访问构件和某些服务代理这些制品共同构成了.Net体系结构，业务构件并不包含敏捷的元素如UI构件和UI过程构件、业务工作流或其他元素，如安全、运作管理和交互。这些初步的定义是十分有用的。它提供了一个全部体系结构方案的稳定部分。然后结合一些敏捷元素，像UI、UI过程、业务工作流，就能提供一个以稳定模式为基础的敏捷方案。

通过对业务功能和数据之间的整合分析，能够得出初步的业务构件和服务。从而生成CRUD矩阵，来定义构件与数据之间的关系

图 7 业务构件样例

在SAM中，业务构件也是一个层次，因此业务构件能够被分解成更为具体的服务、业务实体、数据访问子构件层，并且包含想要业务服务。对这些服务进行明确的定义是非常有用的，这样才能够搞清楚哪些是internal服务，哪些是web服务

构件和服务

构件清单如下图：

• 病人构件

• 病人事件构件

• 病人协议书构件

• 医疗项构件

• 预约构件

• 疗程构件

• GP&医院系统访问组建

• 临床过程构件

• 组/队构件

• 医生构件

• 许可证构件

图 8 PRM 的体系结构视图和设计视图

上述构件显示了业务模式定义的本质，其中的病人构件如下图7所示，它描述了整个构件的功能、管理的数据和服务、特征。

业务模式对软件工程有什么作用？

现在我们将来讨论本文的关注点——怎样利用上述业务模式来建造其它模式或实际的软件系统。图8的PRM的五个层次说明了这个问题。注意到PRM区分了系统结构视图（一个更高的视图，如项目规划）和系统设计视图（如项目或主题设计）。图8介绍了适合这些视图的不同技术和标记，帮助建立一个正确的软件系统。值得注意的是，PRM辨别简单的元素时，要依靠实践而不是假定或者臆断。在业务模式定义后，就可以随心所欲地开展工作了。

在对业务模式进行仔细分析时，首先需要认清体系结构和设计之间抽象水平本质的不同。

业务模式用在哪些地方比较适合？

图9显示了业务模式的优势，图中定义了业务、业务功能、数据和业务构件这些稳定元素。这种方法可以用来指导大型项目开发，保证了项目之间的一致性，节约了项目开发成本。

图 9 PRM 中业务模式的优势

业务模式和面向服务的体系结构（ＳＯＡ）

对于那些想要提供其它ＩＴ模式或者更进一步地提供业务问题的ＩＴ方案的人士来说，业务模式能够用ＳＯＡ原理更深入地来定义，ＳＯＡ虽然不是必须的，但确实最优秀的。利用ＳＯＡ来定义业务模式，我们所需要做的事就是将体系结构中的详细内容转化为ＩＴ方案。那么首先需要提供给业务敏捷一个机会，如图１０所示，将下一层描述的业务细节包含到模式中来，图中新加的这两套原理将把业务模式改变成业务方案模式，另外，业务可以为业务模式构造一个具体的业务方案体系结构。下面我们就来讨论这个问题。注意，此时各个阶段的工作仍然是独立的技术产品

图１０　在业务模式中附加ＩＴ体系结构

业务模式、SOA、(Microsoft)产品细节

最后，图11清楚地描述了更深层次的产品和实践，成功地实施了微软技术方案

图 11 附加微软技术元素

到目前为止，我们已经讲述了业务模式、面向服务的应用体系结构和微软的一套实施模式，接下来将利用相关的模式或IT方案来解决体系结构层次的共同问题。但是仍然需要更加详细的信息，它就是设计视图。

上面已经讨论了体系结构的建立过程，并且这个过程保证了IT项目的管理和价值。如果想要提供一个具体的方案，那么就需要对体系结构的设计层次更详细的研究。将一个方案应用到几个项目上是有可能的，并且体系结构保证了这些项目之间的一致性。

图 12 精化设计方案

图12显示了设计方案的精化过程，并告知用UML这个标准的方法来进行系统设计。

这是精化体系结构的一个普遍的方法，设计结果可以直接用来实现。

在精化体系结构的时候，还能产生一个模式，即IT设计模式。今天大多数软件模式的描述也是采用上述这种方法。包括Microsoft公司的企业方案模式—Microsoft .NET6和Martin Fowler的企业应用体系结构模式。

当然，并不是仅仅依靠设计模式就能创建一个实际的解决方案的，找出模式之间的关联性这一步也是相当关键的。这些模式涉及到Gang of Four8或面向模式的软件体系结构集，以及上面提到的Microsoft和Martin Fowler的模式等。

本文描述了创建业务模式的框架和方法，然后使用业务模式来实现指定的体系结构，这种体系结构可以用来定位、核算、管理IT项目。并且提供了一种方案，来更进一步地指导该体系结构的设计和实施

Microsoft技术模式的实例可以在此处获得，https://www.microsoft.com/resources/practices/

尾注：

1. 本文对模式的定义遵循由Christopher Alexander在《创建永恒的构造方法》（牛津大学，1979）一文中建立的模式标准。描述模式时采用一种Coplien-style的标记。

2. 对于SAM更详细的信息，请查看《企业体系结构—对Bigger Picture的理解》，Bob Jarvis，牛津大学计算机中心，UK, 2003年5月，或者查看http://www.systems-advisers.com

3. 模型问题精化—查看本刊2出版的第一部分

4. NIST中 FIPS 的IDEF 成员标准，查看此处文章183页http://www.itl.nist.gov/fipspubs/by-num.htm

5. .Net的应用体系结构：设计应用、服务模式和实践指南—Microsoft 公司 2002

6. 查看https://www.microsoft.com/resources/practices/ or 或者Amazon

7. http://www.martinfowler.com/books.html#eaa

8. 《可重用的面向对象软件设计模式原理》，Erich Gamma, Richard Helm, Ralph Johnson, 和John Vlissides. http://hillside.net/patterns/DPBook/DPBook.html

慎重声明：

未经本文作者所在公司授权，任何其他公司都不得擅自采纳文章中的思想和理念。

作者介绍：

Philip Teale是一位伙伴策略咨询师，之前供职于英国微软的Enterprise & Partner集团，现就职于微软Prescriptive Architecture 集团，之前为微软提供咨询服务，有29年的IT从业经验，其中有4年供职于微软，16年供职于IBM，均承担软件开发业务。他的国际性经验包括了9年在美国工作，3年在加拿大，17年在英国。Philip Teale的背景是架构师、设计师和能构建大型复杂分布的商业系统。他最近的对领导思想产业的贡献将推动微软在企业系统模型创建上的发展，他是RSA会员。可以通过E-mail与他取得联系：pteale@microsoft.com.

Robert Jarvis是系统顾问有限公司的总监，这是一家英国的顾问公司，专业从事为国际性大型企业开发战略系统建设的业务。他也是一位微软的建筑咨询合作人，Robert Jarvis在国际性系统咨询方面具有超过30年的工作经验，在英国、欧洲大陆和美洲为商业和政府组织提供咨询。他特别擅长企业系统机构的构建，特别是业务/技术交叉点上。他是企业构建的创造者——对大型图纸的理解，一篇很好的应用指南，于2003年，由英国国家计算中心出版。E-mail：v-rjarvi@microsoft.com

转到原英文页面