军事物流业务流引擎应用本体研究

齐继东， 马 妍 ， 荀 烨 ，陈 建

（1．军事交通学院，天津 300161；2.62402部队，天津 300182）

1 问题提出

目前，军事物流业务MIS功能操作步骤、操作权限等均是编码固化、高耦合度，严重制约了系统信息流程的可修改性，无法适应物资保障中数据的采集、传输、存储、处理和使用等事务或功能点的改变。比如，某物资调拨信息流，传统模式是物资主管部门将出库凭证直接下达至任务仓库，但如果改变为物资主管部门将出库凭证下达至联勤分部，再由联勤分部下达至任务仓库，使数据操作权限、事务链、功能点关系发生改变，严重时将导致相关业务MIS重构。

为改变现役业务MIS的编码固化、高耦合度问题，论文[1]提出了基于军事物流业务流引擎开发业务MIS的技术架构，分析设计了业务流程 （Business Process）、功能环节 （Function Tache）、功能点 （Function Node）、元数据 （Meta Data）及数据服务 （Data Service）等5个结构要素的定制模式，但由于对MLBFE的结构要素缺乏统一公认的注释，流程定制者和使用者对MLBFE结构要素的理解不同，使用过程中必将产生语义 （本文是指MLBFE的结构要素及其关系的解释）上或结构上的歧义，如果完全靠人力经验与理论去辨识含义是不现实的，需要提供能够被计算机自动识别与释义的符号系统。截至目前本体 （Ontology）是：解决语义、结构歧义的最佳技术手段；不仅能够解决语义、结构等异构问题，还能够基于此推导出新的隐藏的新知识[4]；为充分发挥关系数据库的优势，还可将构建的本体文件持久化到数据库[3]；为基于本体库的MIS具备智能特点奠定了基础。因此，本文提出研究军事物流业务流引擎应用本体库的主题内容。

2 本体理论

本体是共享概念模型的明确的形式化规范说明，它支持语义级信息交换，是实现Semantic Web的关键技术。本体是用来描述某个领域的知识的，是实现不同主体之间共享与互操作的语义、结构基础，利用声明式语义[4]能够使计算机真正理解 “符号”的含义并进行推理。但对本体的描述，不同语言具备不同特征，但无论用XML（可扩展性标记语言，一套元标记语言，用于定义与特定领域有关的、结构化标记语言的语法规则，如＜单元＞＜名称＞炊事挂车＜/名称＞＜类别＞后勤装备＜类别＞＜/单元＞）、RDF（一种由资源、属性、属性值组成的三元组，如＜rdfs:Class rdfs:label="炊事挂车"/＞＜rdf:Property rdf:about="&rdf_;类别"＞）等何种语言进行描述。本体的典型结构由5个基本要素构成，分别是： （1）类。任何事务，相关概念构成一个概念层次结构； （2）关系。领域中个体之间的交互约束作用； （3）函数。前n-1个元素能够唯一确定第n个元素； （4）公理。定义在实例和属性之上的约束与规则，是本体推理的依据； （5）实例。类的具体化，每个类包含多个实例，实例之间存在显示或隐式关系，实例都是对象，但对象不一定都是实例。

目前，OWL（Web Ontology Language）同XML、RDF一样，是W3C为Semantic Web定义的本体描述语言。OWL在知识表示 （Knowledge Represenation）、知识库 （Knowledge Base）、人类语言处理技术 （Human Language Technology）、自然语言处理 （Natural Language Processing）、语义信息处理 （Semantic Information Processing）和数字图书馆 （Digital Library）等领域广泛应用[2]。从语义上讲，OWL提供了类之间、实例之间、类与实例之间的关系[4]，分别代表本体的概念、个体及个体之间的关系。具体是： （1）类 （Class）关系，为本体类推理奠定基础。语法主要有： 类 （owl:Class）、 子类 （rdf:sub Classof）、 相等类 （owl:Equivalent Class）、 互斥类 （owl:Disjoint With）和合并类 （owl:UnionClass）等。 （2）对象属性 （Object Property），实例约束主要形式，本体推理中使用最为广泛的属性。语法主要有：对象属性 （owl:Object Property）、反义属性 （owl:Inverse）、唯一性 （owl:Functional）、对称性 （owl:ymmetric）、 传递性 （owl:Transitive）、 序列性 （owl:Cardinality）。 （3） 数据类型属性 （Data Type Property），代表实例 （owl:Individual）与基本数据类型的关系，描述主要是自定义的，语法是：数据类型 （owl:Data Type Property）等。 （4）注释属性 （comment），本体中Class、Individuals、Property等注释语句，是不同实例及属性匹配的基础，是实现语义层 “对象”的自动识别与映射的手段之一，但对rdfs:comment赋值时，应尽量是领域内公认的描述语言，如国标、军标或行业标准，以及相关公理或常识等。 （5）类型域、值域关系，针对每个对象属性定义类型域 （rdf:Domain）、值域 （rdf:Range），即 “类型域＋对象属性＋值域”构成三元组等。 （6）实例之间约束度，类型域与值域之间关于某对象属性的可能性。语法主要有：全称取值约束[4]（owl:all Values From，如∀Belong）、受限存在取值约束[4]（owl:some Values From，如∀Belong）、基数约束 （owl:cardinality）等。

3 流程分析

根据军事物流业务流引擎管控技术体系架构[1]，可知业务流引擎的结构要素主要有5个，不同结构要素之间存在严格的约束绑定关系。流程定制者根据军事物流保障业务相关主题，按照约定的 “输入/输出”关系绑定相关“结构要素” （见图1）：按序列为业务主题流程绑定功能环节 （事务）；按序列为功能环节绑定功能点；为功能点绑定数据集；不同功能点的数据元素CRUDT（Create、Read、Update、Delete、Transmit）存在差异，需在功能点绑定数据集时定制各数据元素的 “CRUDT”；等等。本文以某类物资供应主题中某业务功能为例，分析定制MLBFE的结构需求。

其中，BPi表示第i个业务流程，FTij表示BPi中包含的具备严格逻辑串联或并联的第j个功能环节 （关系见图1），i、j表示 1、 2、 3、…。

（2）功能环节 （FT）与功能点 （FN）。多个具备严格逻辑关系与接口的功能点构成一具备特定行为的功能环节，而功能点是一聚合程度高且具备输入/输出功能的系统单元。针对某功能环节，FN序列为：功能环节 “编制/处理/提请物资需求”可分解为编制、处理和提请等功能点；功能环节 “获取/编制/提交物资需求计划”可分解为获取、编制和提交等功能点；功能环节 “开具/提交出库或入库凭证”可分解为提交出库凭证、提交入库凭证等功

（1）业务流程 （BP）与功能环节 （FT）。多个具备严格逻辑关系的功能环节构成一完整业务流程。对于某类物资供应而言，业务FT序列为：第一步，编制/处理/提请物资需求；第二步，获取/编制/提交物资需求计划；第三步，开具/提交出库或入库凭证；第四步，获取调拨凭证，制定物资出库/入库计划；第五步，执行物资出库/入库计划；第六步，执行物资运输/配送；等等。经分析得业务流程与功能环节关系的函数 （3-1）。能点；等等。另，军事物流保障中每个功能环节或功能点均与机构 ｛ 后勤机关，保障实体，受供单位 ｝ 中部分机构相关，因此设计功能点时需考虑角色与功能关系。经综合分析得功能环节与功能点关系函数 （3-2）。

其中：FNi表示业务流程中具体功能环节的第i个功能点；MDij表示FNi中包含的第j个数据元素；DFij表示MDij的数据获取点 （数据元素的唯一采集点）；pj1、pj2、pj3、pj4和pj5分别表示FNi中第j个数据元素MDij的CRUDT，一个数据元素具备1个以上的CRUDT权限；i、j表示1、2、3、…。

（4）数据服务与数据元素。基于已定制的业务功能点与数据元素绑定关系、CRUDT权限与获取点，利用定制的服务集成相关业务数据，对具体功能环节或功能点的执行状态实施监控。服务定制典型函数 （3-4）。

其中，FTi表示某业务流程中第i个功能环节，FNij表示FTi中包含的具备严格逻辑串联或并联的第j个功能点（关系见图1）， Rkj表示角色Rk具备 FNij功能，i、 j、k表示1、2、3、…。

（3）数据元素 （CRUDT）与获取点。数据流是业务流程管控重点，CRUDT是确保数据集机密性与不可抵赖性的手段。各功能点具备 （获取）输入量，按约定处理生成输出量，作为下一环节的输入量。因此，需要准确定制相邻功能点的接口。

假设每个功能点对应唯一角色，业务流定制者需为功能点中各数据元素指定CRUDT和获取点。经分析得功能点内数据元素 （CRUDT）与获取点关系的函数 （3-3）。

示例如下：

其中：cmd代表SQL的操作命令；fld（..）表示字段集合；frm（..）表示字段所属数据库表集 （含表之间约束关系）；val（..）表示字段集合，与fld（..）对应；w表示SQL的Where条件，而conds是查询条件集；FNi.MDij表示某业务功能环节中第i个功能点所辖第j个数据元素；DFit.table表示与FNi.MDij具备同一 “获取点”的数据元素的数据表；FNi.MDtp表示DFit.table的关键字 （主键，可能是复合主键）；v×××表示相关字段的数据值；i、j、t、p表示1、2、 3、 …。

（由于篇幅所限，其它分析略）

4 本体建模

根据MLBFE结构要素分析，为流程定制者和使用者提供公认统一的概念描述，如 “提请”、 “上报”、 “提交”的注释，以及MLBFE的结构关系及其对象或个体关系等。本节利用OWL中Class、Individuals、Property等从语义和语法层次上，借助Protégé设计MLBFE应用本体库，主要包括术语本体、业务流程本体、功能环节 （事务）本体、功能点本体、业务数据主题本体和数据服务本体等。建模中，用Individuals（实例）描述MLBFE中具体对象或个体；用Class（类）声明相关对象或个体的共性，统一概念；用Object Property描述Class之间和Individuals之间关系约束、层次结构等；用Datatype Property描述Class的数值类型属性等。

（1）类 （Class）/实例 （Individuals）设计，OWL编码见表1。某物资供应业务流程中，功能环节 “编制／处理／提请物资需求”可拆分为3个串联的功能环节：编制物资需求、处理物资需求、提请物资需求；当功能环节“编制物资需求”绑定到不同种类的物资 （如弹药物资、装甲器材、被装物资等）供应流程中时，其位置、数据集、CRUDT等方面存在差异；等等。对于 “编制物资需求”经分析得：实例有 “编制弹药需求”、 “编制装甲器材需求”、 “编制被装物资需求”等。通过对多个具体化实例形成概念类，即具体功能点本体；而为完成某业务功能环节的任务，需将多个功能点串联或并联，按序 “运行” （如 “编制物资需求”功能环节 （事务）需按 “部队承担任务”、 “部队现有物资统计”、 “需求量分析”、 “部队自筹能力”等步骤实施与提请），即功能环节本体；多个功能环节按逻辑串联或并联构成业务流程本体；业务流本体通过绑定业务流程本体、功能环节 （事务）本体和功能点本体等而形成。

（2）对象属性 （Object Property）设计，定义实例之间约束，OWL编码见表2。根据业务实例集抽象出相关概念，但现实中概念之间或实例之间存在多样关系。同时，利用实例之间约束语句 （全称取值约束、受限存在取值约束、基数约束等）严格定义实例之间的类型域与值域等。如，物资提请功能点本体 （Function Node）与申请物资本体 （Applyfor Material）之间存在关系∃Belong，即owl:some Values From，又由于实例是类的具体化，实

表1 MLBFE应用本体类/实例OWL片段

例之间也必然存在∃Belong关系等。另，为明确定义出：业务流程本体实例绑定的功能环节本体实例序列、功能环节本体实例绑定的功能点本体实例序列，及功能点本体实例接口关系，需要为业务流程本体、功能环节本体设计环节/功能点的起点 （begin Tache/begin Node）与终点 （end Tache/end Node）的对象属性，为功能环节本体及其内含的功能点本体的逻辑关系设计各自的父节点 （has Front Tache/has FrontNode）与子节点 （has ChildTache/has Child Node）的对象属性；等等。

表2 MLBFE本体类/实例的对象属性OWL片段

（3）数据类型属性 （Datatype Property）设计，OWL编码见表3。实例的数据语义是对数据的描述。因此，为实例设计的数据类型属性主要有物资名称 （Material Name）、数值类型 （Data Value Type）、类型域 （Domain）、值域 （Range）和注释 （comment）等。

另，通过对业务所涉数据元素对象的分析，参照数据元素采集点和使用周期与范围，设计数据获取点。将业务所涉数据元素按业务主题划分 （OWL语句片段见表4）：物资需求数据主题本体 （Dataof Requirement Material Subject）、物资筹措数据主题本体 （Dataof Rasie Material Subject）、物资储备数据主题本体 （Dataof Storage Mate-

表3 MLBFE类/实例的数据类型属性OWL片段

rial Subject）、物资运输数据主题本体 （Dataof Transportation Route Subject）、物资入库数据主题本体 （DataofIn-Base Document Subject）和财务审计数据主题本体 （Subjectof Financeand Audit）等。业务数据主题本体不仅包含数据类型属性，而且还包含数据对象本体，因为不同业务数据主题本体的子本体之间可能存在owl:Equivalent Class、owl:Disjoint With，等。因此，针对数据元素而言，又形成了业务数据主题本体、数据元素本体、CRUD本体及其采集点本体等。

表4 MLBFE主题数据本体OWL片段

最后，利用Protégé中组件onto Graph生成了MLBFE应用本体结构层次图，由于篇幅所限图2仅展示了部分结构。

图2 MLBFE应用本体结构层次示例

5 本文结论

本文针对文献[1]中军事物流业务流程管控技术架构的结构定制，分析在业务流引擎结构要素缺乏统一的概念、个体及其关系注释条件下，产生的语义异构与结构异构问题。基于此，引入本体技术，用OWL的类、实例和属性等对MLBFE的5个结构要素的内容与关系进行定义、规范和注释，为计算机能够依据定义的本体库进行匹配、推理奠定基础。利用protégé对MLBFE本体进行了建模，形成了包含术语、业务流程、功能环节、功能点、业务数据主题、数据元素和采集点等本体的体系。本文的研究成果具有较高的现实意义和研究前景，属于应用创新性研究。

[1] 齐继东,等.军事物流业务流程管控系统初探[J].物流技术，2012(2):213-215.

[2] 张智雄.从RDF（S）到OWL，什么在改变之中[J].图书馆杂志，2005(1):54-60.

[3] 齐继东,等.物流本体数据库的应用研究[J].物流科技，2009(2):63-65.

[4] 林志阳.基于OWL语义本体的推理与存储研究[EB/OL].(2008-12-21)[2012-08-21].http://wenku.baidu.com.