电子商务系统设计 10 电子商务业务过程和信息建模

电子商务系统设计电子商务业务过程和信息建模10.1基本概念

为规范各国各行业各领域电子商务系统的设计与建设，联合国贸易便利与电子商务中心（UN/CEFACT）制定并发布了《UN/CEFACT建模方法学用户指南》与《UN/CEFACT建模方法学元模型》，指导各国电子商务设计者按规范设计与构建系统，使之能实现信息共享与业务标准化。

UN/CEFACT推出规范的另一重要目的，是基于

EDI商务系统的结构、数据模型与成功运行经验，将其改进为能在互联网中运行的开放式EDI系统，改进为网络中对业务过程和业务信息建模的方法。10.2UMM统一建模方法1）UMM统一建模方法简述

UN/CEFACT为规范各行业各领域电子商务系统的建设，提出对电子商务业务过程和业务信息模型的建立采用UN/CEFACT建模方法学（UMM）。

UMM是UN/CEFACTModelingMethod，是建立商业过程的建模方法。

UMM的商业过程和信息建模技术基于UML(统一建模语言)和RUP(统一软件过程)。

UMM依据UML框架，定义一系列商业过程和信息语义原型对UML元模型进行扩充，定义UMM元模型。UMM分两种视图描述电子商务的事务处理：业务操作视图（BOV）和功能服务视图（FSV）；其基本目的是清楚地区分操作和功能视图，最大程度地确保系统的互操作性和系统的向后兼容性。BOV主要关注事务处理的业务方面，FSV则关注事务处理的信息技术方面。

在建立商务业务视图：

1）在UMM定义的框架下建立商务一体化的领域视图（BusinessDomainView–BDV），确定建模范围；2）根据BDV确定的范围描述业务需求，获取需求视图（BusinessRequirementsView–BRV）；

3）再根据需求视图获取具体的业务过程视图（BusinessTransactionView–BTV）。

每个建模工作流程都有明确目标和一系列活动，各建模工作流程的模型产物采用UML进行描述，每个建模阶段的产物可以作为下一个阶段的输入，以进一步细化业务过程和业务信息模型。每个建模工作流程中都包含了建模所涉及的角色、建模步骤以及建模产物。

UN/CEFACT的建模方法学覆盖了业务建模、需求、分析与设计4个工作流程，以及统一过程中初始阶段和细化阶段2个阶段。

在系统建设中，这2阶段的8个单元属于系统概念与逻辑设计阶段。UN/CEFACT对此实施规范化，既能促进各类商务系统在概念与逻辑上的标准化，又给予各系统的物理设计与实现以充分的自由度。3）UMM相关概念与定义UML语言通过版型等扩展机制扩展，扩展了一些业务用例：

业务角色（businessactor）,

业务用例（businessevent）,

业务目标（businessgoal）；

扩展的业务对象，如：

业务执行者（businessworker）,

业务实体（businessentity）,

业务事件（businessevent）,

业务规则（businessrule）等；

扩展了业务系统，如：

业务系统（businesssystem），

业务单元（businessunit）等。（1）执行者（actor）---在系统或业务之外但又与该系统或业务交互的人或物，执行者的选择依赖于这个边界的选择。（2）业务（business）---一系列过程，其中每个过程都具有清晰易解的目的，涉及多个组织，通过信息交换实现，指向某个共同商定的目标，并延续一段时间。（3）业务对象（BusinessObject）---业务对象代表那些在业务内部具有行为和职责的事物。关注点在业务对象要做什么，而非将如何做。

（4）业务执行者（businessactor）---用来定义业务（目标组织）的边界，代表业务之外的事物，必须与业务进行交互，以获得有价值的结果。商务系统中各种类型的业务执行者如客户、供应商、商业伙伴、管理者、目标组织外的伙伴与单位等。（5）业务范围（businessarea）---用一系列相关联的系统特征化的知识或活动的范围，或按一套概念和术语特征化的知识或活动的范围，其中所述的概念和术语是该领域的从业人员所能理解的。（6）业务协同框架（businesscollaborationframework–BCF）---定义在两个或多个业务伙伴之间电子业务交换的规范的集合。

（7）业务协同协议（businesscollaborationprotocol–BCP）---设计和编排好的一个或多个业务交易活动。（8）业务交易（businesstransaction–BT）---业务的一个单元，它由两个参与方执行，并产生一个可量化的成功或失败的状态；或是在两个业务伙伴之间发生的组业务信息和业务信号的交换，这些业务信息和业务信号交换必须以商定的格式、次序和时间间隔出现。（9）角色（role）---在特定的语境中执行指定的具体行为的实体。（10）业务实体（businessentity）---在业务中可被访问、检查、操作、创建、处理的事物。

（11）业务过程（businessprocess）---在业务实践中用来完成一项或多项活动的方法。（12）组织轮廓图（OrganizationChart）---简单描述目标机构的结构和业务流程，以便更好地理解应用软件的需求；它包含于软件工程项目的内容中，通常不更改业务本身。（13）领域模型（DomainModeling）---电子商务平台是信息密集系统，可在业务层面对关键信息建模，主要是管理和呈现业务信息，而不考虑其上的业务流程。该工作也是系统开发的内容。（14）通用业务（GenericBusiness）---商务系统中业务项目复杂，可在多个系统中复用一个或一组应用系统。故可建立一个业务模型，成为多个软件项目的输入，业务建模在此通常作为单独项目展开。

（15）通用业务模型（GenericBusinessModel）---可规范不同机构间的业务处理方式，成为标准的可复用软件，以避免需求过于复杂；或在规范不了流程时，帮助项目理解各商务与用户和机构对目标软件在使用场景上的不同之处，并加以控制。（16）全新业务（NewBusiness）---拓展新业务流程时，业务建模用于发现软件需求，同时用于设计新业务操作，通常作为单独项目来展开。（17）业务重组（Revmap）---重组业务时，业务建模常作为独立项目展开。商务流程再造可分为多个阶段，构思新业务，开发与部署等。（18）业务过程（Businessprocess）---提供可观测、有价值商务活动。它也是一组逻辑相关资源，以实现商务机构的目标。

（19）业务用例（BusinessUseCase）---用例代表了客户或供应商、业务伙伴间如何使用业务的服务，角度在于使用方式而非功能。特点：业务用例由执行者发起，有明确定义的开始和结尾，描述一组可能的执行序列，表达所执行业务的行为。

（20）业务用例模型（BusinessUseCaseModel）---业务用例模型描述了目标组织的业务方向和意图。具体为：业务方向使用业务目标的形式来表达，它们从业务策略引申而来；业务意图通过执行业务用例带来的增加值来表示，这些业务用例支持业务目标的实现。（21）业务用例分类（BusinessUseCaseCatalogue）---可归纳出3类业务用例：

1）核心：是面向客户的业务用例，能提供可见的价值，如购买商品等；

2）管理：组织内部用以控制和协同支撑业务的整个价值链，例如总体规划、业务部署与流程管理、业务监控与审计等；

3）支持：组织内部用以支持形成完整的价值链，例如原材料采购，内部的日常运作等。（22）业务用例规范（BusinessUseCaseSpecification）---商务系统中的业务用例规范有：

1）名称，2）用例目标（涉众利益）、简述，

3）业务执行者（角色）、涉众（Stakeholder），4）支持的业务目标，5）触发事件，6）基本事件流（正常执行路径），

7）扩展事件流（可选/异常执行路径），8）前置条件，

9）后置条件（最小保证和成功保证），

10）特别需求（与用例行为关联的附属特性）。

（23）业务用例分析（BusinessUseCaseAnalysis）---相关步骤的设置应确保业务用例规格的描述足够详细，应针对每个业务用例实现：

1）从业务用例的行为中识别业务对象；

2）将业务用例的行为分配到各业务对象的职责上。

针对每个被识别的业务对象应：

1）描述其职责；

2）描述其属性和相关的关系。（24）业务用例实现（RealityofBusinessUseCase）---业务流程的实现为特定的业务服务（业务用例）的结构和行为提供了一种容器，并在业务用例和业务对象模型间建立跟踪关系。10.3UMM建模目标10.3.1UMM建模目标与步骤1）UMM建模目标UMM建模主要用于描述商务业务过程，建立商务活动的信息模型。具体目标：1）理解各机构参与商务系统时所需的功能，识别各子系统建立与改进架构与接口等；2）分析并理解商务系统中企业、机构、用户等加入与退出业务时引起的相关变化；3）确保企业平台、最终用户、系统开发人员和其他相关者对业务需求、功能架构与实现目标拥有一致的理解；4）分析与抽取商务系统的软件需求，支持目标系统的业务需要用来理解被部署的软件系统如何实现与适应商务系统的总体目标。2）UMM业务建模步骤分解描述商务系统涉及的各个相关目标与子系统机构识别与分析商务系统外部的业务服务（业务用例）识别与分析商务客户、供应商和合作伙伴（业务执行者）间的业务链接与关系建立以商务客户为中心的业务模型（业务用例模型）分析业务用例的实现，识别商务系统中相关业务员工、业务实体和业务系统，并向其分配相关的业务职责分解商务系统中各业务流程的运行模式，定义其软件系统需求。

10.3.2UMM商务一体化建模

在对电子商务系统建模时，要在UMM定义的框架下建立一体化的业务领域视图（BDV），确定建模范围；再根据其确定的范围分别描述业务需求，获得业务需求视图（BRV）；然后根据需求视图获得具体的业务过程视图（BTV）。10.4业务领域视图10.4.1业务领域视图的基本概念1）业务领域视图的功能

BDV

是描述业务范围中各子过程间关系的框架，也是标识其中业务过程的总体架构。为统一定义过程范围边界及获得业务过程的互操作性，需要参考采用各行业已有的通用业务领域参考模型。在无规范模型的情况下，则根据规范建立视图。2）业务领域视图的目的

建立BDV是以形式化方式描述业务领域内，交易伙伴间业务的静态结构，动态关系。BDV内容主要为描述业务文件。具体目的如下。（1）了解电子商务业务领域的静态结构及机制；（2）确保用户、系统设计者和软件开发者对业务领域达成共识；（3）确保业务领域视图的合理性；（4）标识各业务领域的涉众，各涉众与具体的业务过程无关；（5）理解业务领域中的各项日常业务，该业务与具体技术无关；（6）对电子商务业务领域进行分类，通过具体领域划分和领域迭代来完成建模。

3）与其他视图的关系

BDV生成的模型是商务业务需求视图的重要输入，用于了解整个电子商务系统的需求。10.4.2业务领域视图建模步骤建模步骤主要分为：描述商务系统的：业务步骤、业务范围、过程范围和标识业务过程等4步骤。具体如下。1）描述业务领域模型

是通用业务过程框架。

B2B中，这类领域模型由的行业提供；

B2C中，重在建立普适性的对象交易模式。

综合型B2B，不同企业均可通过其内部系统参与交易与业务协作。

对各参与方间的业务过程，针对具体商务对象制定业务领域模型是业务流程设计的起点。对这些业务过程描述建立统一框架，是标准化建模的基础。

表10-2为业务领域模型的模板，指导商务系统设计者描述对象业务领域。10.4.2业务领域视图建模步骤

描述商务系统的：业务步骤、业务范围、过程范围和标识业务过程等4步骤。具体如下。1）描述业务领域模型

2）描述业务范围对业务领域模型分解时，第一层应确定业务范围。而业务领域模型的业务范围分类应能反映企业与商务作业相关的结构，或该行业的通用业务过程框架。这种描述也应采用规范化模板，其格式应采用表10-3所示的电子商务业务范围模板来描述业务范围。3）描述过程范围

过程范围是业务领域模型的另一个层次的分解。在某种意义上，它是所选业务范围的垂直分类。例如，当业务范围是营销时，过程范围可以是业务领域中对应每一个业务范围的点对点过程，也就是ISO/IEC15944-1中的5个基本业务交易活动：计划、标识、协商、实现、实现后。描述过程范围也应采用规范化模板来描述过程范围，具体如表10-4。4）标识业务过程

标识业务过程是业务领域视图的主要目标，这些业务过程是B2B协同所要求的，或B2B协同可能备选的业务过程。采用表10-5所示的规范化标识业务过程模板来标识过程范围中的业务过程，该模板将指出业务过程的一些需求，如与其他业务过程的相互依存联系，详细需求描述将在业务需求视图（BRV）中的业务过程模板中列出。10.4.3建模产物针对具体电子商务领域，业务领域视图通过标识每项业务过程来表达电子商务的总体业务架构。

业务领域建模产物是电子商务的业务范围、业务过程范围、业务过程用例图。

当业务领域分析完成后，业务领域视图阶段应转向商务业务需求视图构建阶段。10.4.4建模参与角色参与业务领域建模的角色有三种人员。1）业务人员

为业务过程分析人员和技术建模人员提供业务领域知识，帮助他们最终提取业务过程用例。2）业务过程分析人员根据业务领域人员提供的领域知识，进行业务过程用例建模。3）技术建模人员将业务模型用建模语言形式进行文档化。技术建模人员采用用例图来描述业务领域人员提供的业务领域信息，与业务过程分析人员共同标识出业务过程所涉及的各个参与方并定义其相关职责。10.4.5业务模式业务模式可参考现有各相关行业的电子商务业务领域模式。

10.4.6

建模实例---商品目录订购业务过程和信息建模实例

根据业务过程和信息建模方法和步骤对“商品目录订购”的业务过程建模。

1）构建业务领域视图

步骤1：描述业务领域模型---即描述业务领域中的业务范围，可引用系统中已有的业务领域模型。根据前述规范模板建立“商品目录订购”，所属的业务领域模型见表10-6。步骤2：描述业务范围---表10-7是描述业务领域模型中商务目录订购的零售业务范围。步骤3：描述过程范围---完成业务范围的界定和描述后，进一步对业务范围中确定的过程范围进行描述。

根据商品目录订购的业务过程包含订购和结算两个过程范围。此处仅用订购业务范围作示例描述，订购业务过程范围如表10-8所示。步骤4：标识业务过程

完成过程范围标识和描述后，本步骤采用业务过程模板来标识过程范围中所列的业务过程。表10-9只标识出上述订购业务范围中的一个业务过程，即获取客户ID。

图10-3商品目录订购的用例图

完成此步骤后，则进入业务需求视图（BRV）阶段。10.5业务需求视图10.5.1业务需求视图（BRV）基本概述1）业务需求视图（BRV）的功能

主要作用是在参考业务领域模型的基础上，依据业务领域分析定义的商务系统业务领域和范围，细化其中各子系统的业务需求。即针对前述步骤所建的业务模式，定义哪些是相关的业务范围，再进一步分析相关的业务协同模式，以获得在后续开发商务系统时所须的各种详细资料。最后与业务领域人员重审设计结果，修正前述业务领域阶段所建的各模型。2）业务需求视图（BRV）的目的

BRV

模型的目标对象较业务领域模型更为详细，它主要详述系统中的业务过程或业务协同用例。BRV模型的具体目的为：（1）在业务领域视图的基础上，更详细地描述用户需求；（2）在用户和其他涉众之间就特定的电子商务解决方案达成一致；（3）在详细了解业务过程用例的基础上，确定业务过程的本体，定义相关事件、约束条件、边界，以及与其他用例的关系，进一步得到业务协同用例，以及参与协同角色的信息实体等。10.5.2业务需求工作流程步骤业务需求的工作步骤主要分以下9步骤。1）使用REA(Resource-Event-Agent)本体描述业务协同；2）描述业务领域视图中的每个业务过程；3）描述业务协同规范；4）描述业务过程衡量指标；5）描述业务协同；6）描述业务过程生命周期；7）描述业务实体；8）描述业务实体生命周期，9）确定和描述业务实体。10.5.4业务需求视图建模步骤1）使用REA描述业务协同

REA是一种计算机信息处理模型。业务需求分析人员利用REA，以UML类图形式自顶向下解析BRV阶段所用的对象，建立商务活动的数字化模型，表示商业活动中的对象。

REA本体中，“R”为Resources（资源）：如商品、服务、资本等；“E”为Events（事件），例如买卖交易、签订协议等；“A”为Agents（主体）：指人、公司、机构等。

商务系统中，每类业务流程都有单独的REA模型。

每个REA模型均含有成对事件，它们由相对的关系联系在一起，称为“二重性”关系。这对事件中的一个代表着一种资源的放弃或转移，而另一个则代表资源的接收或获得。

REA模型，可扩展到如商务承诺（如订货交易），营销策略（如购买一定数量商品或达到一定金额后免运费）等。

2）业务协同5阶段业务协同的5阶段即ISO/IEC15944-1中的5个基本业务交易活动：计划、标识、协商、实现、实现后，它们将指导业务需求视图的建立。其具体内涵如下。（1）计划---为获得商品、服务或权利、买卖双方需要采取的各项活动。（2）标识---为构建作业过程，应标识所有的活动或事件，以及数据在买方、卖方与相关机构间的交换流程。在标识阶段，买方与卖方均要确认：（一）商品或服务的诸项特征属性；（二）确认对方及交易活动中的相关方。（3）协商---包括标识阶段之后的所有信息交换活动和事件。协商过程是在相互理解基础上，对业务协同和相关条款和条件达成一致；协商议题可能包括货物、服务、权利、价格、数量、售后服务、发送要求、结算、代理或第三方等内容，这些都涉及诸方交换信息。（4）实现---包括用于执行实际业务交易协商结果的必要的活动或事件。一般地，根据协商阶段的条款或条件，卖方生产或组装货物，提供服务，准备和完成货物、服务或权利。同样，买方向提供货物、服务或权利的卖方进行等价转移支付、通常以货币形式进行。（5）实现后---包括所有的活动或事件以及在货物、服务或权利被发送之后，在卖方和买方之间的相关信息交换。这些活动涉及担保范围、售后服务等。3）REA本体模板

模板内容如表10-9，它根据上述5阶段来描述，以确业务需求视图其他阶段所要完成的任务（如，业务协同模板和业务实体模板）。当需求分析清楚和详细时，系统设计者需要回到前面并不断反复更新所有的相关模板。10.5.5描述业务过程1）业务过程描述模板

是分析和获取系统功能需求的基础，联合国标准中提供了规范化模板作为商务系统设计者的工具。内容与格式如表10-10。10.5.6描述业务协同1）业务协同描述模板当业务协同涉及多个角色时，10-11的业务协同规范模板来描述各业务协同用例，是业务过程模板的扩展，两种模板在很多方面相互关联。10.5.7业务过程衡量指标

此类指标是在业务协同执行时定义和评估局部应用相关条件。可标识能完成具体商业活动目的或目标的关键绩效指标，它们也可能驱动某项用于该过程或其他过程的事件。

形态上，业务过程衡量指标是可实施的结构化度量，它能跟踪描述业务过程随时间序列将被如何被执行。可实施的业务过程衡量指标能直接描述业务的动态属性；结构化的业务过程衡量指标则描述业务的静态属性。业务过程衡量指标规范模板如表10-12所示。10.5.8描述业务协同

业务协同是业务协同规范的实现。规范化业务协同模板如表10-13，其实例会链接到业务协同规范模板的一个对应实例。业务协同规范通过角色、资源、角色间的关系、资源与活动转换，以及关联关系来实现（通过业务协同或业务交易模式实现）。10.5.9业务过程生命周期

业务过程生命周期模板用来获取业务过程的各项动态需求，如业务过程或业务活动模型。活动是属于业务过程或业务协同内的活动。10.5.10描述业务实体

业务实体模板是用来描述参与该业务协同的业务实体。10.5.11业务实体生命周期

业务实体模板中的生命周期栏目中对应的信息，在业务实体生命周期模板进行详细描述。10.5.11业务实体生命周期生命周期栏目中对应的信息，表10-16所示业务实体生命周期描述模板。10.5.12其他内容1）建模产物（1）业务协同的REA本体；（2）业务过程及其生命周期；（3）业务协同规范及其衡量指标；（4）业务实体及其生命周期。2）业务需求工作参与方（1）业务人员；（2）业务过程分析人员；（3）技术建模人员。3）业务协同模式业务协同模式是REA本体。10.5.13业务需求视图构建步骤业务需求视图构建有7个主要步骤。1）步骤1：使用REA本体描述业务协同交易承诺到履行的通用业务协同模式可用REA确定，其业务需求是BRV的输入。REA以业务协同5阶段为分析基础，对业务过程的REA即资源、事件、参与方等进行分析。在计划和标识阶段，买方和卖方在获得或销售产品、服务之前决定需要采取什么措施，同时还决定在确立它们间的关系时需要交换什么数据。协商阶段就业务协同的目标、相关条款和条件等达成一致，此处可以包括：货物、服务、权利、数量、价格、售后服务、送货要求、结算、中介或第三方的详细规范等。在实现/实现后两阶段，它包括必要的活动或事件，以便确保商议的货物、服务、权利等被传送和相互交换。2）步骤2:描述业务