多层表示模型（精选3篇）
多层表示模型 篇1
0引言
顾客购买某一产品或服务不仅仅是为了消费产品或服务本身,而是为了使其自身获得价值。 通常情况下,单个产品/ 服务需要与其他关联产品/ 服务配套使用才能使顾客获得价值。 因此, 顾客需要的是一种产品/ 服务关联需求,而不是单一的需求。 然而,顾客往往不能清楚地、完整地表达这样的关联需求。 帮助顾客识别关联需求,对实现顾客价值最大化具有重要意义。
目前,缪淮扣等指出结构化方法能增加软件规格说明的可读性,但软件系统对功能的变化十分敏感。［1］张莉等发现面向对象方法运用人类日常的逻辑思维,但在描述问题域方面不足。［2］Anne Dardenne等指出面向目标的方法运用起来比较直观,但目标的演化难于处理。［3］Matthias Jarke等指出情景实例方法用户易于领会,但在大规模项目中的应用有风险。［4］李景洲等认为形式化方法虽可使需求规格说明更精确, 但大都假定已明确用户需求。［5］Ariel Fuxman等提出的方法比面向目标的方法更全面。［6］陈小红等提出问题框架法,相对较少考虑建模。［7］陆汝钤、金芝等提出了基于领域建模的预需求分析, 提高了软件需求过程的用户友好性和自动化程度。［8］
综上所述, 这些建模方法都是针对软件需求工程领域单一系统的需求建模研究,对于顾客的关联需求研究还很少。 研究发现关联需求之间存在某种共性,而每个需求又有其特性。 这种现象可以用“对象—属性”的形式来表示。 概念格是一种表示属性关联的概念层次结构图,描述了对象与属性之间的二元关系,非常适用于表示需求之间的关联。
本文运用概念格对服务关联需求进行表示, 并结合实例来证明该方法的有效性。 这为后续的关联需求挖掘提供了基础。
1服务关联需求表示模型
1.1需求关联特性
随着企业竞争的日益加剧, 集成化的服务越来越受到企业的重视。但是,顾客的关联需求之间除了相互促进,还有相互竞争的关系。顾客需求的关联特性可以分为以下两种:
1.1.1竞争性
顾客的关联需求之间可以是非此即彼的关系,即竞争性。 例如,对于鼠标的需求,可以是有线鼠标,或者是无线鼠标。
1.1.2协同性
协同性还可分为独立协同性和依赖协同性。 独立协同性的关系如购买西装与衬衫,单件购买固然可以,但是搭配购买更能提升单件产品的价值。 依赖协同性的关系如硬件与软件的关系, 软件需依托硬件才能发挥作用, 硬件结合软件才能实现价值。
1.2关联需求模型
用D表示顾客需求集合, 用N表示顾客需求属性集合,关联需求模型用如下三元组表示:M: = {S,R,U}(1)
式中,S表示一对需求集;R表示这对需求集之间的关系;U表示这对需求集能带给顾客的效用。
(1) S = (Ci,Cj),Ci、Cj是基于概念格的关联需求模型中的两个概念。
(2) R = {r1,r2},r1表示竞争性的关系,r2表示协同性的关系。
(3) U的取值不仅与R有关,还跟S有关。
1.3效用函数的建立
用us表示需求集S对效用的影响,用ur表示关联关系R对效用的影响。
1.3.1uS的确定
用d表示单一需求,m表示某一属性, 用w表示属性m的权重,用v(d,m)表示需求d是否具有属性m。 当v(d,m) = 1时表示需求d具有属性m,当v(d,m) = 0时表示需求d不具有属性m。
1.3.2ur的确定
若Ci与Cj是竞争性关系r1,则ur取值为0,表示这对需求集不会成为顾客的选择。
若Ci与Cj是协同性关系r2,则ur取值为1.1,协同性关联需求可产生“1 + 1 > 2”的效果。
2服务关联需求建模
2.1初始模型的建立
假设初始需求是d1,d2,…,dn,根据顾客的购买动机,得到初始属性为m1,m2,… ,mt。 需求和属性的关系构成的n × t阶初始形式背景矩阵:
然后借鉴专家经验、思维发散,以及关联特性,从属性m1进一步得到属性m1a,m1b,… ,m1p,通过新的属性或新的属性集合得到新需求dsa,dsb,…,dsk。 将新属性与新需求加入原始关联需求概念格中。
(1) 若g (m1a)∩g (m) = ф, m ∈M, 那么新增节点Csa= (g(m1a),m1a)。
(2) 若存在C = (g(m),f(g(m))),其中m∈M,使得g(m1a)⊆g(m),且C的子概念节点与概念(g(m1a),m1a)的外延交集不等于g(m1a) , 那么新增概念C的子概念节点, 得Csb= ( g ( m1a) , f(g(m))∪m1a)。
(3) 若存在C = (g(m),f(g(m))),其中m∈N,使得g(m1a) = g(m),那么更新概念C,得C*= (g(m),f(g(m))∪m1a)。
将属性m1a插入后,再以同样的方法插入属性m1b,m1c,…,m1p。
重复上述步骤,继续从属性m2进一步得到属性m2a,m2b,…, m2q,通过新的属性或新的属性集合得到新需求dua,dub,… ,duk。 将新属性与新需求继续加入已有的关联需求概念格中。 通过逐一将新属性加入已有概念格逐步完善概念格, 最终将得到一个复杂的概念格。
2.2属性权重的度量
假设属性集合为{m1,m2,…,mn},用aij表示两个属性权重的比值,即aij= wi/ wj。
采用Saaty的建议, 用1~9及其倒数作为标度来确定aij的值,1~9比例标度的含义见表1。
2、4、6、8表示两个相邻判断的中间值。
可得到如下矩阵:
运用最小二乘法进行求解,即
若f(C0) = ф,则不考虑C0与其他概念节点的关联效用;若g(Cz)= ф,则不考虑Cz与其他概念节点的关联效用;若g(Ci) = g(CX1)∪g(CX2) ∪…∪g(CXj),则不考虑Ci与其他概念节点的关联效用。
3算例
假设需求集D = {投影仪,激光笔,U盘,投影幕布,音响,吊架,推车,电池},属性集N = {播放图像,可发光,存储信息,显示图像,播放音频,固定设备,供电,可移动}。 为便于表示,分别用如下字母对应表示需求集和属性集。
得到形式背景矩阵和概念格如下:
要为某顾客提供服务, 首先需要该顾客对属性重要性进行判断比较,得到如下判断矩阵:
可计算得:
由于f(C0) = ф且f(C10) =ф,同时g(C1) = g(C3)∪g(C4)∪ g(C5)∪g(C6)∪g(C7),所以,不考虑C0、C1、C10与其他概念节点的关联效用。 根据效用公式U = ur· ∑wq,可得到关联效用矩阵:
4结论
服务关联需求的研究旨在为顾客提供服务集成方案, 对提高顾客满意度有重要意义。 本文选用概念格相关理论对服务关联需求进行建模、表示。 通过对关联需求的关联特性进行分析, 进一步构建关联需求的效用函数。 最后以简单但完备的算例验证了方法的可行性。
摘要：顾客的需求通常不是单一的产品或服务,而是一系列关联需求的集合。但是,顾客往往无法明确地意识到这些关联的需求。帮助顾客识别出这些关联需求,一方面增加顾客价值,另一方面可以提升企业竞争力。本文借助概念格相关理论对顾客的这种关联需求构建模型进行表示,通过与顾客的信息交互,引导并帮助顾客明确自身的实际需求,最后结合实例验证了这种方法的可行性。
关键词：服务集成,关联需求,表示模型,概念格
基于知识树的知识表示模型设计 篇2
通过对现有各种智能化教学系统进行分析,不难发现要实现系统的智能化关键要解决两个难题:一是网络课程的知识表示模型设计二是获取用户兴趣的用户模型设计,典型的智能化教学系统模型如图1所示。
用户模型:描述用户的个性特征,包括用户基本信息、学习风格、学生兴趣、认知水平(背景知识、知识熟练程度、认知能力);学习行为记录了用户的学习历史过程(如访问哪些资源、学习时间、访问次数等),系统可根据用户的学习历史过程更新用户模型。
课程知识库:智能化教学系统的核心,是实现个性化知识推荐的关键。知识表示模型决定了知识库的架构。知识表示模型能够有效地控制教学过程,与科学的教学策略相结合,能够满足个性化知识推荐的需求,实现因材施教的教育思想。知识表示是学科知识与教学策略的整合,它的实质是知识的符号化,主要是为了便于计算机对知识进行存储和处理。目前,使用较多的知识表示技术有一阶谓词逻辑表示法、语义网表示法、产生式表示法、框架表示法等。课程知识库[3]包含与知识点对应的教学素材、试题、辅助学习资料等,它包含知识点属性和知识点链接两个部分,是知识表示的基础,反映了知识库的层次结构和知识点之间的相互关系。
知识点过滤推荐算法:在用户模型、课程知识库基础之上,根据不同类型的学习风格及个性差异,选择相应的教学内容和教学策略,适应性地向用户推荐最佳学习活动序列和学习资源。
呈现模型:该模型的主要工作是将个性化推荐结果返还给用户,个性化推荐结果可以以各种方式返还给用户,如信函、电子邮件、网络电子公告栏等。
1 知识表示模型设计
网络课程的知识结构可以看做是一棵倒立的知识树,课程相当于根,每一章和每一节构成树的茎,知识点是树的叶。课程的章节之间存在着一定联系,课程的知识点也存在着内在联系,通过前驱、后继关系描述这种联系,并通过关联度反映知识点之间关联的紧密程度。每一个课件或者每一个专题讲解资料都对应一个或者若干个知识点。基于此种思路,该文设计的知识表示模型如图3所示,它也是下文进行个性化知识推荐的基础和依据。
1.1 知识与知识点
知识点:是指不能再分的完整、独立的基本知识单位,如数学中的基本概念、定义等。
单元知识:由内容相关度较高的知识点整合而成,如教材中的每一节知识,就是由若干相关的知识点整合而成。
章知识:由若干相关的单元知识整合而成,是比较完整的教学知识的表达。
课程知识:由若干篇章知识整合而成,其特点是知识体系相对系统、完整、独立,通过课程的学习,学员能够深入掌握某种专门的技能,或为进一步学习打下良好的基础,如高等数学课程、网络设计课程等。
为了方便用户学习,知识点划分的基本作法是教科书的一章可以化为一个大的知识点,其中一节的内容又可细划为较小的知识点,一节中的定义、定理等还可以划分为更小的知识点。从这种知识组织的角度来讲,将知识点分为基本知识点和整合知识点两种基本类型。其中基本知识点为领域知识中最基本的知识单元,对教学而言基本知识点在内容上具有不可划分性。而整合知识点由两个或两个以上的知识点组成,组成整合知识点的知识点可以是基本知识点,也可以是若干整合知识点的整合[3]。
知识点是教学组织的知识单位,就计算机专业的《操作系统》课程而言,见下图,知识点可以是一个概念、一个实例、某个操作,某个实现模式等,也可以是几个知识点的整合或一个知识点的分解。
1.2 知识表示模型的设计[4]
该文的知识表示模型特点是通过层次关系描述知识点之间的相互关系结构,为此定义了两种关系:前驱关系和后继关系。
(1)前驱关系:例如,知识点“进程”与“线程”之间的关系。知识点“线程”的学习依赖于知识点“进程”的学习,则知识点“进程”是知识点“线程”的前驱。前驱关系具有传递性,如果A是B的前驱,B是C的前驱,则A是C的前驱。
(2)后继关系:例如,“线程”与“处理器调度”之间的关系。学习完知识点“线程”后学习的知识点为“处理器调度”,则“线程”与“处理器调度”构成后继关系。“处理器调度”是“线程”的后继。后继关系与前驱关系是互逆的。后继关系也具有传递性。
课程的知识表示模型可通过知识之间的层次关系图描述。下图是《操作系统》课程的教学知识层次关系图,图中由若干结点与知识点组成,每一个结点表示一个知识点,结点之间的连线表示它们之间具有关联关系,连线上的值代表关联程度。关联程度是反映知识点之间相互关系的基本参数,整个课程的知识结构由这种层次关系图描述,不过,如何科学的确定知识点之间的关联程度,直接影响对课程知识体系的表述与构建,显然不可以随心所欲地主观确定。我们的作法是:由若干有丰富教学经验的老师先提出各自的预案,对知识点间的关联度先给出参考值,然后通过求取平均值来确定。
知识点之间的关系可能有一个前驱知识点多个后继知识点,例如:对于知识点“进程”,它有一个前驱知识点“进程管理”和多个后继知识点“进程的基本特征”、“进程状态及转换”、“进程描述”和“进程控制”。此外,知识点还会有如下几种情况:一个前驱知识点一个后继知识点;多个前驱知识点一个后继知识点;一个前驱知识点多个后继知识点;以及没有前驱知识点或者没有后继知识点等情况。
图3的分析思路相应的表格设计如下:
知识点描述表(编号,名称,描述,所属章节),编号为此表的主键。
知识点关系表(编号,前驱知识点编号,知识点间的关联度),编号和前驱知识点编号共同作为此表的主键,知识点编号是相对于知识点表的外键。对应的表关系如下:
表1中知识点“进程”有一个前驱知识点“进程管理”和多个后继知识点“进程的基本特征”、“进程状态及转换”、“进程描述”和“进程控制”,它们的关联度分别为0.8,0.7,0.7,0.60
2 个性化知识推荐[5]
在完成了基于网络课程的知识表示设计的基础上,实施课程知识点的个性化推荐。侧重通过知识点之间的关联关系(如表1所示)来进行知识点的推荐,考察用户过去的学习行为也即浏览访问的知识点,从而可以获取用户感兴趣的学习内容,并向用户推荐同类的教学资源。知识树过滤推荐算法的具体步骤如下:
1)通过对课程的基本知识点的测试,获得用户的基础水平,根据专家经验,向用户推荐符合其基础水平的章节知识点进行学习。具体思路如下:
若用户是新生,则用户基础水平的知识点范围涉及本课程的基本知识点内容,根据专家经验向学生推荐章节进行学习,如:
If认知水平值<=0.3 then学习第四章知识点
Else if认知水平值>=0.7 then学习第六章知识点
Else学习第五章知识点
若用户是老生,测试其基础水平,分析其对此章节的学习掌握程度,以决定推荐下一章节的学习或前一章节的学习,如:
If认知水平值>0.5 then学习下一章节知识点
Else学习上一章节知识点
2)获得用户可能感兴趣的知识点集合。通过上步测试,确定向学员推荐当前适合的知识点,并得到这些知识点的后继知识点根据知识点关联度属性,去掉关联度小于0.5的相邻知识点。表1表示了知识点间的关联度,知识点“进程”有一个前驱知识点“进程管理”和多个后继知识点“进程的基本特征”、“进程状态及转换”、“进程描述”和“进程控制”,它们的关联度分别为0.8,0.7,0.70.60,表明这些知识点的关联度都超过0.5,即它们与知识点“进程”关系密切,是用户必须学习掌握的内容。如果当前访问的知识点是“进程”,则用户感兴趣的知识点集合包含这些后继知识点。
3)然后选择当前知识点相关度最高的前若干项(Top-N)作为推荐结果给当前用户。
3 实验评估设计[6]
为验证知识树过滤推荐算法的准确性和有效性,按以下方法进行实验评估设计:由多名专家通过讨论提出操作系统课程到底包含哪些基础知识点,我们的设计方案中应有30个基础知识点,并组织专家提供两套操作系统试题,每套30个选择题,每个选择题都是对一个基础知识的考核,并且考核的难度相,只是考核的角度有所不同。
第一步,抽取15名用户对第一套试题进行自测,该套试题共涉及到30个知识点。测试后,根据知识点掌握熟练情况及知识点间的关联程度按知识树过滤推荐算法获取推荐集合。
第二步,组织用户按照推荐结果进行复习,用户复习完全部推荐内容后,组织用户对第二套试题进行自测,并对自测成绩和第一次自测成绩进行对比。通过统计,15名学员推荐前的平均学习成绩为38,通过知识树过滤推荐算法进行学习后的平均学习成绩则达到84,算法的有效性值得肯定。
4 结论
该文研究网络教学平台下如何实施因材施教,为学员提供个性化知识推荐问题,通过知识库、教学方法、教学手段、学员认知水平等方面的协同整合,实现目标知识的发现、定位及访问,是对传统的填鸭式教学的变革,使网络教学平台智能化。为此基于网络课程进行了知识表示模型的设计,在此基础上提出了一种知识点过滤推荐算法,能够避免“冷启动”造成的对新学员无法进行知识点推荐的问题,也能够针对个体特征引导学生学习,从而改善用户学习效率低、学习过程盲目混乱的状况,能够激发学生求知的欲望,引导学生主动探求知识,让学生与教学平台“互动”起来。但该文的研究局限于网络课程,而不是网络教学平台的个性化知识推荐研究,需要今后进一步扩展和完善。
参考文献
[1]杨德华.个性化远程教学模型的研究与实现[J].现代远距离教育,2008(2).
[2]李高敏.基于协同过滤的教学资源个性化推荐技术的研究及应用[D].北京交通大学,2010.
[3]曹伟.自适应网络教学系统中知识表示模型的设计[J],计算机仿真,2010(3).
[4]胡晓楠.基于知识点的学习内容个性化推荐研究[D].重庆大学计算机学院,2010.
[5]Jonathan L.Herlocker,Joseph A.Konstan,Loren G.Terveen,Johh T.Riedl,Evaluatingcollaborative iltering recommender systems.ACMTransaction on Information Systems,2004,22(1),20-21.
多层表示模型 篇3
近些年来,世界各地灾害频发,各国政府非常重视应急决策支持系统的研究。模型管理是决策支持系统中的核心,其主要任务是建立决策模型并支持其使用,通过帮助决策者理解决策问题、提供候选方案,辅助预测等方法来改善决策者的表现[1]。由于模型的管理起始于模型的表示[2],因此模型表示也成为当前研究的热点。
在模型的表示方式上,国内外许多学者进行了理论研究,主要有Blanning提出的实体关系模型[3]、Geoffrion提出的结构化模型[4]、Huh等人提出的面向对象表示[5]、Hong的框架表示[6]、Dutta提出的一阶逻辑表示[7]以及由Dolk和Konsynski[8]提出的模型抽象表示等。
这些传统的模型库模型种类较为单一,存在着对决策者领域知识要求较高,扩展性较差,对模型操作支持不足等诸多问题,难以满足应急管理领域中对模型操作、管理和组合上的要求,所以研制针对应急管理领域的模型表示方法具有重要的理论意义和应用价值[9]。
针对应急管理领域模型的特点以及传统模型表示法的缺陷,本文结合框架和面向对象的表示法,提出了一种适合应急领域模型的表示法——框架(Frame)-形式(Formal)-实体(Entity)三层模型表示法,这种表示法能很好地解决模型管理的不足,实现模型的重用和组合,并使得业务人员从开发中解脱出来,更加专注建模和分析。
1 框架-形式-实体三层模型表示法
1.1 基本思想
Marvin Lee Minsky在1975年提出了知识表示的框架表示法。Hong用这种方法表示了模型例化的三个层次,即模型类、模型结构与模型实例三个继承层次,并且使得模型与结构、数据独立,支持模型集成。但Hong的方法并没有与面向对象的方法紧密结合,模型的定义没有引入继承机制,不支持模型的层次结构。本文借鉴了Hong的模型例化三层次的思想和面向对象的思想,提出了框架-形式-实体三层模型表示法,将应急决策模型进行三次抽象,如图1所示,形成框架模型、形式模型和实体模型,从而实现了模型与结构、结构与数据的分离,并使得模型世界和问题世界相关联。
1.2 问题分解与框架模型的建模
决策者依靠模型来解决结构化和半结构化问题,所以模型首先是面向问题的。根据问题求解理论的问题归约法,引出框架模型的定义。
定义1 框架模型是一个两元组,其EBNF形式如下:
<框架模型>::=<元数据, 任务列表>
<元数据>::=<模型编号,模型名称,模型提供者, 模型提供时间, 模型描述>
<任务列表>::={<任务>}
<任务>::={<虚算子列表, 约束>}
<虚算子列表>::={<虚算子, 约束>}
根据定义1,框架模型由元数据和任务列表组成。元数据描述了框架模型的基本信息,它能够方便地进行模型的维护。由于应急领域的模型种类各异,开发人员也来自各个领域,故描述模型的元数据应包括模型的唯一编号、模型名称,模型的提供者、模型的提供时间和模型的描述。任务列表是由各个任务按一定次序排列组成的。这种次序的定义与前述任务分解时子任务关系的定义相同,这样,就能够在任务分解形成的子任务列表和框架模型的任务列表间形成双射关系。在框架模型中,任务被定义为一个或多个虚算子列表和约束组成,而虚算子列表是由一个或多个虚算子及其约束组成的。借用面向对象的方法,这些虚算子并不实现具体的算法,而是面向对象中的虚函数或抽象类,需要其派生类来实现这些方法。
由于任务的分解和框架模型的任务列表存在双射关系,故可以将一个问题映射成为框架模型,这个过程就是框架模型的建模。
根据上述任务问题求解理论,一个问题可以表示成三元组(X,C,Π),通过Create(p)→T⇔Create(X,C)→(Y,D),将问题P转换成任务T。再通过问题分解理论,任务分解链表示为:
T::={(Yo1,Do1,Πo1),(Yo2,Do2,Πo3) ,…,(Yon,Don,Πon)}T::={f(tFRMT1),f(tFRMT2),…,f(tFRMTn)}
定义一个集合F,其元素为T中各映射f的逆映射,所以:
<T,F, meta-data >::=< Frame Model>
该结论表明,分解后的任务加上框架模型的元数据,以及问题分解的子任务到框架模型的任务的映射就完成了问题世界到模型世界的建模过程,这个映射完成了问题解决步骤的生成。映射集F随着任务分解方法的不同而不同,故同样的任务可以生成不同的框架模型,这取决于框架模型的构造者。
1.3 结构例化和形式模型的建模
框架模型建立以后,需要算法来完成虚算子。把算法实现的虚算子称为算子,这个过程就是框架模型的结构例化,也是形式模型的建模过程。
定义2 形式模型是一个四元组,其EBNF形式如下:
<形式模型>::=<元数据, 算子列表, 黑板模型, 框架模型>
<元数据>::=<模型编号,模型名称,模型提供者, 模型提供时间, 模型描述>
<算子列表>::={<算子>}
<算子>::=<会话, 方法>
<会话>::={<输入><约束>|<输出><约束>}
<输入>::={<参数定义>}
<输出>::={<参数定义>}
<参数定义>::=<参数名, 参数类型>
根据定义,形式模型由元数据、算子列表,黑板模型和对应的框架模型组成。黑板模型用来储存共有的数据。之所以采用黑板结构存储,是为了方便模型或方法集成后的调用,因为一个方法可能需要前面几个方法生成的参数。算子列表是由算子组成,而算子是由会话和方法组成。方法体现了面向对象的封装性,它封装了完成框架模型任务的算法。会话是该算子与其它算子的消息接口,它包括两方面,一个是输入及对输入的约束,另一个是输出及对输出的约束。输入和输出都是由参数定义组成,而参数定义由参数名和参数类型组成。考虑到模型之间的集成,参数名和参数类型应在知识库中有统一的规定。参数的类型有字符型、数值型、矩阵型、XML等,其中的矩阵长度和维数、XML格式等由constraint 约束。凡派生于该形式模型的实体模型传入的参数和接受的数据都应该遵守其对应的约束。形式模型需有一个框架模型与它对应,算子既可以有虚算子与它对应,也可以没有,但框架模型所有的虚算子都要靠形式模型的算子来实现,它们之间存在满射关系。
根据上述框架模型和形式模型的关系,可以将框架模型转换成形式模型,这就是框架模型的结构例化或形式模型的建模过程。
根据框架模型和形式模型的定义,定义f,从一个框架模型构造一个形式模型就是将任务(task)映射到算子(operator)上,其形式化描述为:
f:f(task)→operator
f⊇constraint⇒f(virtual-operator)→operator
上式说明如果f包含约束集(constraint)的话,从框架模型到形式模型的映射转化为虚算子(virtual-operator)到算子的映射,这从本质上说明了形式模型的建模过程就是在约束条件下,完成虚算子的算法。
在形式模型建模中,应有以下约束:
∀virtual-operator⇒∃operator(f(virtual-operator)→operator)
这说明在建模中框架模型的虚算子必须由算子来映射,但反过来则不需要,形式模型继承了框架模型的结构,并可以扩展、重载虚算子。由框架模型建模到形式模型,完成了问题解决方案的生成,实现了模型与方法的连接。因为有着不同领域知识的专家实现同一个虚算子的算法并不相同,所以一个框架模型可以结构例化为多个形式模型。在面向对象的方法中,建立形式模型是也可以引用已建好的形式模型或其算子,这样为模型在组件和零件级别上的组合打下了基础。
1.4 数据例化与实体模型的建模
从框架模型建模到形式模型后,形式模型并不能运行,这是因为模型的运行必须依靠特定问题的数据。连接算子和参数的过程称为形式模型的数据例化。把带有数据的形式模型称为实体模型。与具体问题相关联的实体模型可以运行并能提供应急决策者最关心的输出结果。
定义3 实体模型是一个三元组。
<实体模型>::=<元数据, 数据列表, 形式模型>
<元数据>::=<模型编号,模型名称,模型提供者, 模型提供时间, 模型描述>
<数据列表>::={<参数>}
<参数>::=<参数名,参数类型, 参数值>
根据定义,实体模型由元数据、数据列表和相应的形式模型组成。其中,数据列表由参数组成,参数包括参数名、参数类型和参数值。因为知识库中定义了统一的概念,形式模型会根据参数名识别出参数,从而传递和共享数据。
从形式模型到实体模型的建模,主要是将参数(parameter)映射到形式模型中需要外部输入的参数定义(parameter-define)中,其形式化描述如下:
f(parameter-define,parameter-value)→parameter
其中,映射f必须满足形式模型中的定义的参数名和参数类型与实体模型的相一致,并且,所有的形式模型需外部输入的参数定义都在实体模型中有相应的参数对应。
由形式模型构模到实体模型,完成了具体问题的解决,实现了模型与数据之间的连接。
1.5 框架-形式-实体三层模型表示法优点
由于应急管理领域涉及到多专业领域和政府不同部门的人员,所以模型的三级实例化可以极大限度地使不同分工的人员分担建模的工作。框架模型定义了模型应用服务和创建维护的规格,形式模型创建了数据交互的规格,实体模型创建了模型运行的规格,如表1所示,从而解决了应急领域模型异构和业务管理人员难分离的矛盾。三级模型与面向对象的方法紧密结合,使得模型管理可以最大限度地使用面向对象的方法,从而支持渐进式建模、支持模型和模型方法的集成、共享和重用,有利于模型的管理和利用。
2 模型三层例化下的物理存储
应急领域的模型由于开发者往往来自不同单位,故很难在同一的平台下进行模型的开发,所以大多模型都采用集成的方式统一到模型管理平台中去,所以模型最佳的存储方式是 :
模型=元数据+文件+(数据)
文件=(模板文件)+业务逻辑文件
业务逻辑文件=接口文件|算法文件
其中,()表示可以没有,| 表示两者可以为任意一种。
以此为标准,框架模型、形式模型以及实体模型的物理存储形式如下:
(1) 框架模型存储形式
框架模型=模型元数据+文件元数据+接口文件
根据框架模型的定义,框架模型由元数据和任务列表组成。模型元数据表存放模型的编号、名称、提供者、提供时间、功能描述,文件元数据表中还要存放接口文件的路径信息等。接口文件是程序文件,如Java等,由于框架模型存放的任务列表,所以使用面向对象语言的接口、抽象类能够很好地表达框架模型的含义,一个接口可以表示一个任务,其中声明的方法是任务的虚算子,数据类型的定义等是任务的约束。
(2) 形式模型存储形式
形式模型=模型元数据+文件元数据+模板文件+算法文件
其存储方式与框架模型类似,但其算法文件要求实现框架模型的接口,如在Java中,使用implements关键字表明该算法文件中的类遵循框架模型的接口,并声明其如何工作的,这个过程即声明了框架模型的虚算子在约束下是如何被实现的,也即完成了框架模型的任务。
(3) 实体模型存储形式
实体模型=模型元数据+文件元数据+模板文件+算法文件+数据
可见,实体模型是形式模型加上数据,模型的数据储存在数据库中,可以是字符串或XML格式等,在实体模型运行时,会从数据库中取出相应的数据传给算法文件,从而使其能够运算出结果。
3 应用实例
以模拟2005年福建“龙王”台风为例,进行框架模型的生成。“龙王”台风于2005年10月2日05:30在台湾省花莲登陆,在台湾海峡再次得到加强作用,与当日夜间在福建中南部沿海登陆,登陆时风力12级,在福建滞留10小时。位于迎风海岸的福州沿海,受闽江下游喇叭形河口助长,产生长时间大风。台风登陆后继续向西偏北方向移动,受垂直于台风移动方向的闽中戴云山脉和闽西武夷山脉抬升,又遇到北方弱冷空气影响形成台前飑线,产生短时强降水。
3.1 问题的分解和框架模型的生成
以上的案例是应急管理领域中常见的灾害链,该问题可表述为:
P=<X, C, Π>
X论域为2005年福建的“龙王”台风,目标为计算此次台风的损失,约束可以为计算精度、计算时间等。该问题经专家转换为任务为:
T=<Y, D, Π>
Y论域为台风、暴雨和洪涝灾害链,约束和目标不变,根据任务分解理论,任务T分解链为:
T=<<T, B, H>, l>
l=<<T, B, 1><B, H, 1>>
T=<T, B, H>
其中,T表示台风模拟子问题,B表示暴雨模拟子问题,H表示洪涝模拟子问题。由于框架模型与问题存在映射关系,我们把每个子问题映射到抽象类的抽象方法,加上框架模型的元数据,该框架模型用抽象类表示,如图2所示(用Java语言表示)。
abstract class disasterChain{
private String id; //框架模型的编号
private String name; //框架模型的名称
private String Provider; //模型提供者
private String Time; //模型提供时间
private String description; //模型功能描述
//台风模型的抽象方法(目标)
//约束说明
public abstract void typhoon();
//暴雨模型的抽象方法(目标)
//约束说明
public abstract void rainstorm();
//洪涝模型的抽象方法(目标)
//约束说明
public abstract void flood();
//定义各目标之间的关系
public void g_relation(){
typhoon();
rainstorm();
flood();
}
}
DSS构造者中提供知识标准的业务人员并不需要了解台风、暴雨和洪涝灾害的专业知识,这些方法如何具体实现则交给创建形式模型的专业知识提供者,如气象局、地质局等专业部门的人员。
3.2 形式模型的生成和模型的选择、集成
框架模型定义完成后,问题解决的步骤已分解完毕,DSS专业领域知识提供者需要继承框架模型并覆盖其抽象方法,对于已经在模型库中存在的满足约束条件的模型或方法,可以直接实例化加以集成,由于模型参数的命名应该遵从知识库的统一概念体系,故修改模型结构并不会影响其他的模型。业务人员采用不同的方式覆盖抽象方法便形成了不同的形式模型。下面是一个继承以上框架模型的形式模型的例子,图3为形式模型类图。
public class LongWang extends disasterChain{
//黑板结构
public typhoon typhoon_input; //台风输入参数
public typhoon typhoon_output; //台风输出参数
public rainstorm rainstorm_input; //暴雨输入参数
public rainstorm rainstorm_output; //暴雨输出参数
public flood flood_input; //洪涝输入参数
public flood flood_output; //洪涝输出参数
public void typhoon(){
typhoonGetdataConversation(); //台风处理输入参数的会话
setRedirect(interface); //调用人机交互界面
typhoonOperator();
typhoonSetdataConversation(); //台风处理输出参数的会话
setRedirect(interface); //调用展现结果界面
}
public void rainstorm(){
rainstorm r=new rainstorm(); //已经存在的模型可以直接集成
r.operator(rainstorm_input);
}
3.3 实体模型的生成和模型的运行
根据定义3,实体模型是由元数据、数据列表和对应的形式模型组成。其中元数据存在实体模型管理表中。因此当形式模型创建完毕后,DSS构造者将模型实际运行的任务交给参谋,参谋并不需要了解模型的内部细节,只要根据某一个特定的灾害问题,向形式模型按照约束输入参数,形成数据列表,从而形成实体模型。系统生成实体模型的运行界面如图4所示。
在建立实体模型时,若选定形式模型后,建模Agent会自动调出该形式模型所对应的交互建模模板,供用户输入数据,从而形成完整的实体模型。
以“龙王”台风为例,假设输入参数风力、经度、纬度、温度、气压等参数,形式模型的会话会校验这些参数并处理给算子,根据方法间关系和参数传递关系,该实体模型最终会将台风-暴雨-洪涝灾害链的结果展现给决策者。图5为建模的时序图。用户需依次进行台风、暴雨、洪水的子任务,从而最终解决“龙王”台风损失的任务。通过模型中各方法中会话的输出算子,可以进行模型的运行控制,调用展现人机界面,提供模型运行的中间结果,籍以跟踪模型的运行。
4 结 论
为了实现应急决策支持系统中模型管理,本文借鉴模型例化合面向对象的思想,设计了一种新的模型表示方法——框架-形式-实体三层模型表示法。该方法使得业务人员更专注于自己擅长的业务领域,便于模型管理,共享和重用,适于进行模型组合,满足应急领域对模型的要求。应用框架-形式-实体三层模型表示方法构建应急模型管理平台,能够较好地实现应急问题解决的智能化、模型表示的规范化、模型在部件级和零件级上的高重用,为应急领域的决策提供了强有力的支持。
本文提出的模型的表示方法,针对应急管理领域模型和人员的复杂是一个好的解决方案,但目前仍存在一些问题,如该方法对模型的表示要求较高,它要求不同的模型构造元件需要采用同一形式化描述,否则虽然可以集成,但不能支持模型方法级上的各种操作;模型表示法过于复杂,对建模人员要求较高,对模型管理系统要求较高等。这些问题都有待进一步研究与探讨。
摘要：由于应急管理领域模型的特点,传统的模型表示方法并不适合表示应急决策支持系统中的模型。有鉴于此,结合框架和面向对象的表示法,提出了一种旨在适应应急领域模型的表示法,即框架-形式-实体三层模型表示法;设计了模型三层例化下的物理存储;最后以福建“龙王”台风为例,给出了此方法的应用实例。
关键词：模型表示,框架模型,形式模型,实体模型
参考文献
[1]黄梯云.智能决策支持系统[M].北京:电子工业出版社,2001.
[2]Sprague R,Watson H.Model management in MIS[C]//Seventh Na-tional AIDS,Cincinnati,1975:213-215.
[3]Blanning K W.An Entity-Relationship Approach to Model Management[J].Decision Support Systems,1986,2:65-72.
[4]Geoffrion A M.The SML language for structured modeling:level 1 and2[J].Operations Research,1992,40(1):38-57.
[5]Soon Young Huh.Modelbase construction with object-oriented constructs[J].Decision Sciences,1992,24(2):409-431.
[6]Hong.Inheritance and instantiation in model management[C]//HawaiiInternational Conference on System Science,Western Periodicals Com-pany,1990.
[7]Dutta A,Basu A.An artificial intelligence approach to model manage-ment in decision support system[J].IEEE Computer,1984,9:89-97.
[8]Dolk D R,Konsynski B R.Knowledge representation for model manage-ment systems[J].IEEE Transactions on Software Engineering,1984,10(6).
[9]Zhong Qiuyan,Wang Heng,Ye Xin.The Model Representation in E-mergency Management System[C]//The 2008 IEEE/WIC/ACMInter-national Joint Conference on Web Intelligence and Intelligent AgentTechnology.