第4章 软件架构与设计流程

 

从软件工程发展的历史来看，我们可以看到许多各式各样耳熟能详的流程或模型：例 如瀑布式软件开发流程、迭代式的RUP、敏捷开发流程、CMM/CMMI、各个公司自己定制 的流程等。但是，无论是哪种软件开发流程，无论其使用了怎样的用词和行文来表述流程， 基本上都遵循了 “V-Model”这个著名的软件开发流程模型，如图4-1所示。

 

V-Model是由Paul Rook在20世纪80年代后期提出的软件开发流程模型，它正式于 1990年在英国国家计算中心期刊中发布。该期刊收录了一些旨在改进软件开发效率的建 议、论文、方法研讨等著作，Paul Rook的V-Mode丨是其中最著名的一篇。该模型推出后 不久，英国及其他欧洲各国就纷纷开始应用这个模型。实践检验证明了 V-Model是继经典 的潷布式开发流程模型之后的又一个重要的软件开发流程模型。

 

可是直到现在，软件工程界还有很多人依然混淆了瀑布式开发模型和V-Model模型. 把Paul Rook的模型错误地称作经典的瀑布式开发模型。事实上，V-Model是Paul Rook 在经典的瀑布模型（Waterfall Model)基础之上进行的改进。我们可以注意到，瀑布式模 型（Waterfall Model)将软件系统生命周期划分为界定系统需求、架构构建、系统设计、 开发实施、测试和运维这几个重要的阶段.也就是我们通常所谈论的系统生命周期的六个 重要阶段。瀑布模型中各个阶段的任务是按照一种自上而下、依次顺序（所谓瀑布式的）、 一步一个任务来完成的。前一个任务没有完全结束前，后续的任务是不能幵始的。这种强 时序性就是瀑布式模型的特征。

 

当然，这种系统生命周期的阶段划分非常经典，现在软件系统开发依然沿用这样的阶 段划分来开展工作。但是，瀑布式模型却暴露出一些明显的缺点，例如测试工作（无论是 单元测试、集成测试或者系统测试）只能在整个系统开发阶段或项目总里程碑过半后才能 展开。系统开发前期积累下来的大量架构问题、子系统及构件的设计问题、编码的Bug等，

 

只有在系统开发后期才能被发现，从而带来了大童的返工，甚至会造成通常我们所谈的系 统开发“定时炸弹”。

 

V-Model继承了瀑布式模型的优点，例如继续沿用其中所界定的几个重要的系统开发 阶段里程碑，并且保留了时序的概念。同时，V-Model也修正了瀑布式模型的缺点^例如 可以将测试活动提前，以并行的方式在系统开发早期就开展各项测试活动。我们从模型图 中可以看到，开发活动和测试活动几乎同时开始。这样能够尽早进行系统级校验、子系统 及构件级校验等工作，从而避免了在系统开发后期才发现震撼级的错误。

 

如果仔细观察V-Model模型.我们能够很清楚地看到，软件系统架构和设计活动主要 位于模型图的左侧。软件系统架构构建的活动发生在“软件系统要求”、“软件系统架构”、“子系统要求”这三个阶段：软件系统设计活动主要发生在“子系统架构/设计”、“构件设 计/单^设计”这两个阶段。但可惜的是，V-Model模型只划分了系统开发的大轮麻及大的 阶段标志，并没有按照标准的流程模板进行更加细致的探索。我们从该模型中只能看到一 些大的方面，但是并没有看到一些至关重要的细节。例如“软件系统架构”是V-Model模 型界定的阶段，可是我们不知道在做“软件系统架构”之前，必需的输入是什么7在进行 “软件系统架构”任务时具体有哪些步骤？ “软件系统架构”完成后必需的输出又是什么？ 这些问题，并不能从V-Mode丨模型中找到令人满意的答案。

 

看来，仅仅遵循V-Model模型是远远不够的，它不能精细地回答实际工作中的一些问 题。参考实际系统开发的各种实践和经验，我们总结出如图4-2所示的系统架构与设g流 程模型，简称为系统架构BABSC流程模型（BABSC Architecture Process Model),其中 BABSC是如下5个阶段的核心英文单词的首字母组成。

 

B.构建商业架构概念（gusiness Architecture Concept)

 

A.构建应用架构概念（Application    Architecture Concept)

 

B.确立和稳定架构基线（Architecture    Baseline)

 

S.子系统架构及设计（Subsystem Architecture and Design)

 

C.构件与单元设计(£omponent/Untt    Detail Design)

 

4.1构建商业架构概念

为构建一个好的系统或产品的架构，需要架构师建立起一系列的系统化概念。这样一 系列的概念，也就是通常我们构建系统架构之前，需要深入理解和澄清问题的what (系统 的要求）、when (实现的时间）、who (负责的角色)、how (实现的方法)、why (实现的 目的）9例如：整个系统是因什么商业或运营目的而构建的？系统投入运行后是为了服务于 哪些stakeholders的利益？什么角色在什么时候进行怎样的业务操作或系统维护？为什么 商业运营会要求系统的实现是这样而不是那样的？系统投入运行后，整个商业业务是怎样 围绕系统运转的？商业人员会在怎样的情况下如何使用我们的系统？整个商业信息是如何 依靠系统进行流转的？商业数据是以怎样的逻辑关系组织在一起的？

 

上述问题的答案，并不是简单地让需求分析人员进行所谓的“用户需求分析”就能完 成的。经验告诉我们，“用户需求收集”或“用户需求分析”经常是一些业务分析人员从业 务的视角进行的信息收集和整理活动。其产生的结果并不能让架构师马上进行系统架构的构建，它们只是系统各stakeholders的业务对系统的初步需求，并不能称其为商业架构概 念。为了真正形成架构概念，需要架构人员进行进一步的工作：即架构人员依靠自身在软件系 统构建上的实践经验，结合系统构建时所要求重点考虑的视角，一点一滴地逐步组织并最终形 成完整准确的商业架构概念，并最终汇总出系统的“要求”。从中我们也可以看出，“系统需求” 与“系统要求”两个词在系统架构师眼里有着微妙的差异(虽然许多人认为它们是相同的意思)。

 

构建商业架构概念主要是指利用各种商业建模手段，全面、清晰地构建商业领域内的 组织结构关系、商业功能、商业流程、信息交互、商业结构地理分布、商业规则和约束条 件、商业目的、战略决策等商业概念。这些概念的构建，是架构师进行下一步系统架构构 建的基石。

 

严格地讲，只有当架构师完全明确并完整具备了这些相互关联的商业概念之后，架构人员才可以从这些概念中抽象出需要的架构元素，完整准确地回答what、when、who、how、 why这样一系列的问题，继而高质量地进行系统架构的构建。只有这样，构建的系统才能 在真正意义上准确完成商业对系统的各方面要求。

 

我们可以借助下面的流程卡，来看看实践中架构师是以怎样的流程来进行商业概念构 建工作的，如表4-1所示。

                                        表4-1商业架构概念构建流程卡

目标描述： 建立详细的商业模型，捕获当前商业运行的各种重要信息：组织结构关系、商业功能，商业流程' 信息交互、商业结 构地理分布、商业规则和约束条件、商业目的' 战略决策等?建立构建应用架构概念的工作基础，并淸晰定位系统边羿、 项目范围等架构初启阶段的边界，为后续逐步淸晰系统功能及非功能方面的要求提供概念帮助.
负责人员：	参与人员：
软件系统总架构师	需求分析人员
	商业领域专家
	Stakeholders 代表
	技术经理
	架构师
	子系统架构师
	系统测试人员

 

输入：	输入事件：
产品/项目定义文档	需求分析结束，收到构建系统架构请求
商业目标和战略决策文档
需求规格说明书（需求分类列表、需求优先级列表、需求
描述文档、系统Use Case等〉
活动描述：              建立产品/项目信息概览，确定产品/项目的范围、目的、最终用户、商业背景等重要初始信息。 建立完整的商业及系统术语字典，以便使商业分析人员、客户、架构与设计人员、系统测试人员等对同样的商业及架 构描述的理解保持一致. 建立最宏观层面的商业运作总体概念，明确商业运作的总体流程、各商业功能边界、商业功能的交互与协作等，确定 稳定的系统化概念模型， 汇总和分析商业组织结构的组成与协作职能关系，建立该商业背聚下的组织结构概念模型。 分析商业运作的组成节点、节点间交互关系，商业的协同及各个商业职能间信息交换和依賴的方式。 汇总商业运作节点及商业活动中互相传递的亊件及消息。 分析商业活动动态运行时各种商业活动/流程特征,构建商业活动动态变化过程的模型
确定商业活动进行时造成的商业节点或商业活动内部状态变化的机理及变化过程， 确定并汇总商业运作时数据交换的基本模型信息，以便于雎踪信息的流动和格式的转换。  汇总及分析各种商业活动中所交互的数据间的关联关系，并最终构建商业数据关系模型.  汇总商业各个运作层面的基本商业规则及约束条件。 输出： 产品目信息概览  商业及系统术语字典  商业运作总体概念  商业组织结构  商业运作节点及信息交换  商业运作亊件跟踪模型  商业运作活动模型  商业运作状态变化模型  商业数据交换矩阵  商业数据模型

从上面这张“构建商业架构概念”流程卡中，我们能够清楚地看到概念构建前必需的 输入、进行商业架构概念构建时应该完成的动作和任务、概念构建结束时要求必需的输出 等重要信息。从实践的角度上来讲，当我们面对的是一个大规模的复杂系统时，如果没有 进行这样细致的商业架构概念构建的过程，势必会造成严重的后果。谁能想象一个连商业 运作概念模型都不淸楚的架构师，能够构建出一个满足商业要求的软件系统架构呢？

 

1.产品/项目信息概览

 

产品/项目信信息概览是一份主要以文字进行叙述的项目执行期间信息汇总的文档。主要 目的是让系统架构的参与人员及最终客户明确有关产品幵发的一些基本信息，方便后续工 作的展开和相关信息的査询。其中可以包括产品/项目的前提约束条件、既定的假设、会影响管理层决策的情况，也有一些在产品/项目开展前既定的范围、背景、时间、人员任命、 业务目标等重要的基础信息。

 

在系统架构初启阶段，该文档中包含的信息主要用来指导架构构建的计划工作，是一 份指导性文件。随着架构工作的持续展开，这份信息概览会随之进行修改，详细的信息会 被汇总进该文档，例如：商业架构概念进行了哪些概念的构建。不断完善的产品/项目信息 概览会成为一份架构构建过程中的信息检索工具。

 

产品/项目信息概览主要包括项目识 别信息、范围、目标及实现方法、项目背 景、工具及文档、意见及建议等6个部分 (可以参考右侧的表单作为架构流程模板之一 )。

 

A.项目识别信息：为了方便地进行 检索，标示出项目或产品名称、系统总架 构师及架构师的姓名：同时可以包括该项 目约束条件、前提假设、管理及授权机构、 架构构建完成日期、项目财务信息(成本、 人工、预算等)。

 

B.范围：包括构建架构概念时考虑商业及系统问題的视角，

同时汇总了描述 这些视角而构建的概念模型的信息，从而 方便地检索相应概念模型的细节。

同时分 类和汇总了各个概念模型的参与构建部 门及起止工作时段。更重要的是，

分别为 构建的各个概念模型的实现进行投资回报(Return of Investment)分析，方便管理层

进行战略决策。

C.目标及实现方法：阐述了既定的商业与系统实现目标，汇总了可能的分析及实现 方法，确定各个角色所进行的工作，从而最终实现既定的目标。同时，为了更好地管理项 目的期望，分析并汇总了架构构建工作所服务的各方利益相关者stakeholders的要求。

 

D.项目背景：为了完整阐述项目/产品架构工作的大背景，必须详细阐述商业改进及 系统架构的任务、目标、远景计划、商业宏观运营概念。同时，澄淸重要的商业规则、前 提、法规的约束等条件。如果该项目/产品的架构构建与其他项目/产品有关联关系时，要详 细描述这种架构间的联系。

 

E.工具及文档：汇总本项目/产品架构工作所用到的各种架构工具集。同时，制定架 构文档的命名规则及文档格式规范。

 

F.意见及建议：架构组所发现的问題、建议的系统实现手段、可利用的技术等各方面 的问题及建议陈述。

 

 

 

2.商业及系统术语字典

 

进行软件系统工程，使用精确的术语及数据表现来进行沟通是至关重要的。这就要求 我们尽量使用业界广泛认同并使用的术语，避免使用含有歧义的用词。只有使用这样一致 性的语言，才能确保在商业及应用架构概念构建期、子系统及构件设计期间以及产品开发、 校验、运维及复用时期内沟通的一致性。

 

在商业及系统术语字典制作及演化中，只有完成这些工作，才算真正完成了建立术语 字典的任务：

汇总商业术语；

 

制定及规范商业/系统数据的元數据（Metadata）； 

将系统架构术语及系统实现术语进行分类及规范；

 

将商业业务术语与系统架构及实现的术语进行映射与统一。

 

3.商业运作总体概念

商业运作总体概念（Overall Business Operational Concept)的建立，是构建商业架

 

构概念中非常重要的一步。通过勾画商业运作的总体概念，可以使阅读者快速掌握商业运 作中核心功能模块、核心模块之间的交互过程、整个商业运作的背景环境、商业运作与背 景环境的关系等重要概念信息，并能方便地与管理层进行交流，促使决策者进行最高层面 的决策。同时，只有在统一的总体商业运作概念的引导下，后续逐步建立的细节商业概念 才是准确有效的。

 

如何表现总体商业运作概念，业界并没有一个统一的规范或标准来进行表现。通常， 我们可以根据不同的商业类型、商业范围、商业复杂程度而采取不同的表现形式。实践中 主要是通过绘制商业运作图，结合一些文字描述，来表述我们构建的总体概念。在有些场 合甚至可以考虑使用一些精心制作的影像材料进行更加贴切和有力的表述。当然，无论采 用哪种形式，都要保证概念表述的淸晰和一目了然^____

 

在勾画商业运作总体概念时，要淸晰而准确地描述商业运作的主线业务流程、商业任 务、商业使命、商业目标、总体商业运作模式、参与机构和组织、资源分布与协同、主要 角色及其完成的任务、运营模式与外部环境的交互等概念信息，这样才能清晰地表述业务 运作中所发生的重要事件。为了实现上述目的，实践中我们可能会绘制一系列的运作概念 图，从不同的视角来阐述我们构建出的商业总体概念”当然，随着后续阶段确立了更多的 其他架构概念，我们依然有必要不断对这些总体概念图进行修改和完善。

 

在第3章中，有一张美国国防部“海军作战管理系统”的总体运作概念图。该图就很 好地表现了在现实系统开发中，总体商业架构概念图制作时的目的及用意。同样，作为我 们展现商业总体运作概念的参考，我们可以参考美国国防部开发“网络化联合作战系统” 时制作的运行概念图作为我们构建自己商业运行总体概念时的参考，如图4-3所示。

从图4-3中我们可以看出，不同的兵种、不同的武器会通过一个网络化的通信及控制 系统而形成联合作战的能力。例如陆、海、空通过WEAPON C2系统的联合指挥，向敌军 的移动目标（MovingTargets)发起联合攻击。

 

当然，这样一系列最髙层面的宏观概念示意图，并不可能事无巨细地表达各种需要表 述的商业架构概念。如果我们只是把构建商业概念的工作停留在这样简单和概括的图表上， 无疑是非常危险的。只是简单地圆几张图表，就希望能够开发出一个成功的系统是完全不 切实际的。还需要进行下述方面的概念构建，这样才能在真正意义上完成整个商业概念的构建工作。

4.商业组织结构

 

作为构建商业运作架构概念中重要的部分，我们必须建立起该商业组织结构的概念模 型。针对具体商业领域，商业运作会形成很多组织或职能体，例如，一个产品生产型企业 会有这些组织结构：管理组织、计划组织、设计组织、生产组织、质量监控组织、财务组 织、物流组织、销售组织、市场组织等。而一个服务提供型企业则有着不同的组织结构： 服务管理及规划、服务开发、服务销售、服务实施、服务交付等。

 

从商业运作层面上看，有些组织或部门属于一个运作层面，有些商业组织隶属于更上 一层的组织，有些又是临时性的组织’但是在商业运作中却又扮演着重要的角色。为了澄 清这些与组织结构有关的重要概念，我们可以参考使用如图4-4所示的模板来构建商业组 织结构。

 

一这样的组织关系图非常形象地构建了商业内部组织结构的层次关系。但是，在现实商 业运作时，各个组织及部门担当了各自的业务职能角色，它们通过分工协作来完成共同的 一一个商业目标。如果只是构建上述的组织结构概念，我们还不能确定商业部门或组织间进 行协作的职能层次结构。其次，我们也不明确各部门在商业流程或商业活动进行协同工作时担当的角色。所以，我们需要进一步构建组织结构概念。可以参考使用如图4-5所示的 模板来构建组织间角色的关系及协同工作的层次关系。

 

 

我们首先通过构建组织结构，从而清晰表达了商业内组织结构的层次关系。接着，我 们通过汇总组织职能和角色明确各组织所隶属的业务协作层次关系及角色划分。

 

5.商业运作节点及信息交换

 

构建商业运作节点间有关信息交互的概念，需要我们汇总各个运作节点间互相传递哪 些类型的商业运作信息，以及这些信息是以怎样的方向进行流动的。

 

需要澄清的是，这里所谈到的商业运作节点主要是指那些可以产生、消费及处理信息 的商业运作架构中的功能单元，例如：可以是商业运作职能/人员角色（例如：产品设计角 色、产品销售角色)，可以是商业组织/部门（客户技术支持部门、市场部门），有时也可以 是商业职能模块（物流配送职能、人力资源职能）。需要注意的是，构建概念时运作节点的 选择是随着构建概念的深入程度而决定的。例如：如果进行详细的汇总，运作节点就可能 变成角色这样的细粒度节点。

除了选择适当的运行节点，还要识别节点间相应的信息交换。这里所谈到的信息交换,

有着这样的侧重点及指导原则:

信息交换主要表述了运作节点间需要交互的商业信息，即信息依箱关系。

 

信息交换并不表述信息交换是如何实现的。例如：从运作节点A传出的信息，首先 要经过节点B,最终到达节点C。这样的信息传递路由并不在本概念构建的描述范 围内，我们只会表述节点A与节点C间有信息交换。

 

信息交換只汇总和描述那些商业功能节点间的信息，对IT系统间的信息交互不在本概 念的构建范围内。因为目前的任务不是汇总和构建那些有关rr系统信息交互的概念。

 

信息交换的方向以箭头代表互相传递信息的方向，并加以适当的文字进行说明。

 

当前的概念构建，只是为了界定节点间信息交互的这种依赖关系。交换信息的详细 内容不在本概念构建的范围之内，例如：信息依赖是指总共需要交互哪些信息，而 交换的每个信息内容、信息的组成结构/格式、信息的属性（Attribute)等不在汇总 的范围内。

 

必须考虑商业内部节点与商业外部的信息交互及依赖关系。

 

为了有效和淸晰地表述本阶段所构建的概念，我们可以参考使用如图4-6所示的两个 模板来工作。

为了构建商业运作节点间信息交互的概念，我们通常会通过如图4-7所示的5个步骤 来逐步完成概念构建。

 

1 识别和界定商业运作过程中（流程）的重要活动。

 

2 分辨参与该项商业活动的主要角色。

 

3 把参与商业活动的各个角色归类为各自隶属的商业运作节点（例如：商 业组织、商业职能模块）。    

 

4 分析参与该商业活动的角色间如何进行信息交換。

 

5 总结角色间的信息交换，汇总为商业运作节点间信息交互的概念图。

6.商业运作事件跟踪横型

 

上面构建出的“商业运作节点及信息交换”概念，帮助我们澄淸了在商业运作中的重 要节点及相应的信息依赖关系。但是，还有一个非常明显的问题需要我们进一步澄清：某 一个商业运作节点，是在怎样的商业情节中、怎样的时间点、需要怎样的事件驱动来完成 相应的商业活动，并通过怎样的事件驱动下一个商业节点呢？

 

这样的问题，需要我们以“商业运作节点及信息交换”的工作为基础，进一步构建这 种动态的事件驱动以及节点协作的关系，从而帮助我们清晰回答什么运作节点、在什么时 间点、接受了什么事件、完成了什么商业活动的问题。在实践的基础上，我们经常会采用 一种叫“商业运作事件跟踪动态模型时序图”来进行业务的梳理，请参照如图4-8所示的 模板。

 

7.商业运作活动/流程模型

 

在上面的第6步中，我们需要以商业运作主要活动（通常为商业流程）为出发点，帮 助我们构建出一个商业在运作时各项活动的总体概念：

 

•为了实现哪些特定的商业目的，正常操作时有哪些活动发生。

 

•这些活动发生的时序关系以及前后依賴关系。

 

•每个活动开始前要求怎样的输入。

 

•收到输入之后会发生怎样的细节动作。

 

•活动结束时会有怎样相应的输出。

 

很明显’第6步“商业运作事件跟踪模型”所构建的商业概念与第5步“商业运作节 点及信息交换”构建的商业概念有着明显的不同。第5步强调的是商业运作节点间的协作 及信息交换，而第6步完全以商业运作流程为视角，试图构建业务活动/流程的协同和信息 交换的概念。需要强调的是’商业运行概念中，商业活动/流程是非常重要和关键的部分。

 

为了完整地构建商业活动/流程概念，通常我们可以采取下述几个步骤来逐步进行细化。

 

Step 01 为了完整表述一个商业内的活动/流程，可以采用活动/流程分级“层次图” 这种静态的表现方法，来详细汇总各项活动/流程及其子活动/子流程。这样既从最髙层面对 商业内的活动/流程进行了抽象，又可以很直观和方便地进行检索和查询。我们可以参照如 图4-9所示的模板来协助进行活动/流程的汇总和表述。

 

Step 02 一般来讲’要完成一个商业功能，都需要跨商业节点（例如：部门）或跨流 程的几个商业活动来协同执行。例如：某业务是通过图4-9中的活动/流程A1、A2、A3等 依次串行协作完成。为了完整汇总商业中这种横向的关联，我们可以采用活动/流程图这种 动态图的表现方法进行汇总，如图4-10所示。

 

 

在实践中，我们可以参照下述多种模板来进行表述，例如价值链图表Value-added Chain Diagram (VACD)、事件驱动流程链图 Event^driven Process Chain (EPC)等，如 图‘11和图4-12所示。

 

为更清晰地表述为完成某一项商业功能所进行的一系列主要活动及相关的信 息流动，需要汇总横向的活动关联关系。我们可以利用各种表现形式来汇总建立起来的概 念，例如流程图、活动图等，甚至我们可以考虑采用时序图这种动态表现形式进一步细化 各个主要活动的纵向详细操作过程。在如图4-13所示的模板中，我们在左侧用事件驱动流 程链图EPC来描述商业功能，在右侧则用时序图进一步深化某项活动的细节信息。

 

8.商业运作状态变化模型

 

作为第5步“商业运作节点及信息交换”及第7步“商业运作活动/流程模型”概念的 进一步补充，通常还可以考虑结合“商业运作状态变化模型”。

 

构建运作状态变化的概念有两个重要的目的：

 

可以帮助我们分辨一个商业节点或者一个商业活动在受到不同事件的触发时，其采取的相应动作及动作之后造成其内部状态变化的过程。简而言之，事件造成商业节 点/活动状态的变化。

 

•如果我们采用类似1998年由Kristensen提出的Colored PetriNet (CPN)状态转化模拟技术，可以动态地模拟这种复杂的、多节点/流程协作的特征。通过对这些商 业内部活动的模拟，可以帮助我们获取、分析和校验商业内部交织的各种复杂的商 业情节，而这些详细信息往往是无法通过静态分析方法获取的。

 

为了澄清商业运行状态变化的信息，我们可以应用如图4-14所示的模板汇总事件、状 态之间的关系。通常，我们也称之为“状态机（State Machine)”。

 

 

 

9.商业数据交换矩阵

 

随着商业运作节点间信息交互概念及商业运作活动概念的建立，我们己经了解到商业 职能及商业活动间数据依赖关系的概念，即在怎样的商业运作活动中，哪些商业运作节点 参与了什么方向的信息交互•但是直到现在，我们依然不能精确地箪握商业节点间交互的细节信息，例如，运作节点间到底交换了什么信息、商业运作活动中互相传递了什么信息、 进行这些信息交换时有什么具体的要求（例如：安全方面)、信息的组成内容是怎样的等。

 

可以试想，如果我们不能详细汇总信息的发出者、信息的接受者以及交换的信息内容, 没有构建这样一个完整的数据交换矩阵，肯定会导致严重的架构概念缺失。

 

通常，为了完整地构建这样一个数据交换矩阵，我们会按照以下步骒来完成。

 

以“商血运作节点及信息交换”及“商业运作活动/波程”为基础，分辨并汇 总运作节点间及运作活动间需要交换的详细信息。

 

界定唯一标识交換信息时使用ID的命名规范。

 

识别信息发送者的描述信息：商业运作节点名称或id、商业活动名称或id。

 

识别信息接受者的描述信息：商业运作节点名称或ID、商业活动名称或ID。

 

澄清并汇总单个信息的内容组成：信息名称、信息内容、信息范围或时效、 信息编码方式等。

 

识别信息的Transaction属性：Transaction类型、Trigger事件、重要级别程度。

 

信息时序方面的要求：一次性、按固定时段、随机。

 

信息安全方面的要求：访问控制、有效性要求、不可抵赖、完整性等。

 

信息保密方面的要求：分类、加密、审计等。

 

在实际工作中，结合上述工作步骤，可以参考使用如图t15所示的模板。

 

10.商业数据樸型

 

到现在为止，我们已经清晰而全面掌握了一个商业在其运作过程中，商业运作及商业 活动各个节点间是怎样进行数据级别的信息交换等细节信息。实践告诉我们，数据或信息 之间的关系一般是商业规则中一个重要的组成方面。但是到目前为止，我们还没有进行这种信息之间关系的汇总。这就要求我们在商业数据模型中，通过认知商业规则在数据信息 级的约束条件，构建商业数据棋塑（Business Data Model)，从而彻底完成数据信息级的 概念构建工作。

 

构建商业数据模型时，主要的工作是依据前几个阶段的商业概念构建（尤其是“商业 数据交换矩阵”及“商业运作活动/流程模型”)，确定信息的数据实体类型、数据实体的各 种属性以及与其他数据实体间的关系。

 

需要注意的是：第一，目前的数据模型只是构建整个商业架构概念的一个组成部分， 即在构建商业运作时涉及的信息或数据的概念，以便帮助我们更加深入地建立其完整而彻 底的商业运作认知。不能将目前的商业数据模型构建等同于通常我们所做的系统级逻辑数 据模型（Logical Data Model〉，那是系统架构和设计阶段有关纯丨T系统的数据级任务。第 二，“商业运作节点及信息交互”可以帮助我们初步构建数据模型。但是’ “商业运作活动/ 流程模型”的建立’才能在真正意义上帮助我们持续修订并完善商业数据模型。因为对商 业运作活动的理解，尤其是各个活动的输入作&出/控制信息/数据的汇总，才是帮助我们完 整而准确地界定数据模型中数据间关系的基础。

 

在实际操作中，可以借鉴如图4-16所示的模板进行分析及汇总。

 

11.商业运作规则及约束

 

一个商业只有在其运作过程中遵循了某些既定的规则及约束条件，才能保证该商业的 任务及使命得以圆满完成。先前的种种概念构建，只是能够回答我们个商业会如何运 作”的问题。但是，并没有淸晰地回答“在什么条件下，商业运作必须完成什么动作或者 不准执行什么动作”这种商业规则所带来的强制约束。

 

这些所谓的商业运作规则，基本上包括规章制度、指南、操作规范等商业强制要求。 这些规则确保了商业运作有序并且按既定要求进行活动^如果回顾上述构建出来的概念， 我们能够发现，在最为宏观的运作概念部分，一定有着一个类似的商业运行计划作为指导， 这就是一个规则。在商业运作节点及信息依赖概念中，我们可以注意到，如果在一个条件 满足的情况下’一个既定的角色会完成某个既定的任务。这也是一个规则。在运作活动/流 程模型这样细节概念的构建中，经常会发生“If某个条件满足，并且接收到某个事件，Then 执行某个既定的动作”这样的强制商业规则。

 

为了完整地构建我们对该商业架构的理解，除了已经完成的那些结构性概念构建，我 们还应对这些隐含的商业运作规则进行汇总（需要说明的是，我们现在完全是以构建商业 架构概念为驱动去总结这些商业规则，而不是以系统架构及设计为驱动去总结这些约束规 则）。在实践中，我们可以参照如图4-17所示的模板汇总各个概念构建阶段的不同规则。