背单词最好的软件排名 [行业应用软件中的词根表和库结构]

　　行业应用软件的发展要求技术人员具有更宽的知识面，更多的技术融合手段，实现技术与业务的顺畅沟通。而词根表和库结构是行业应用软件开发中最基础、最稳定、对行业应用软件影响最大的领域知识。因此也将成为软件企业重要的知识资产。
　　行业应用软件是某一领域内的核心应用软件，是目前国内外应用软件的主体，是应用软件企业最关心的问题。行业应用软件的内容可以简单地归纳为如图1所示的三个部分。
　　
　　作为以理工科专业为背景的软件工程师群体，需要学习更多的领域知识和过程管理知识。去年笔者在“第四届中国软件技术大会”上就曾呼吁讨论行业应用软件的社会科学和自然科学结合的问题，今年我们也将在第五届大会上讨论更多的有关领域知识的话题。
　　然而领域知识有关的内容很多，我们要选择其中最基础、最稳定、对行业应用软件影响最大的内容首先进行讨论，所以我们选择了词根表和库结构。本文主要讨论它们的内容特点，以
　　及与过程管理和支撑技术的关系。
　　
　　词根表和库结构的定位
　　
　　目前领域知识的表述是沿着两条相关的主线进行的，即: 结构主线和流程主线。在不同的业务和概念层面，它们的称呼有一定的差别。在管理学方面它们分别对应目标管理（侧重成果管理）和流程管理（侧重行为管理）; 在业务实务方面它们分别对应表单管理（表单对应业务管理中的各种单据和报表）和活动/流程管理（活动反映业务的操作步骤，并贯穿性地讨论流程的整体含义，及相应组织环节的岗位责任）。
　　其特点是结构主线强调某个环节的具体结构，具有相对稳定的特性，而流程主线强调各环节的整体性和过程集成性，反映相对变化部分，具有灵活的一面。
　　在现实中，两条主线也是相关相融的。流程主线的稳定部分可能以一种约束的形式，用结构的方式表示，配合更概括的流程进行工作。
　　库结构是结构主线讨论的主体，在不同的业务概念层面有不同的相似定义。但无论是结构主线还是流程主线讨论领域知识，都还有一个共同的基础，就是用词。我们无论做任何概念叙述还是信息处理都离不开用词，而词根表就是用词在一个特定层面的称呼。
　　虽然我们大体知道了词根表和库结构在领域知识中的位置，但是还必须更具体地在概念层次上标出它们更适当的位置。如图2所示。
　　
　　当软件工程师进行行业应用软件开发的时候，一定会遇到基础性的用词（命名）和结构（数据库结构）问题。当与领域专家讨论问题的时候，必须学会大量的业务术语和概念，不能反复提到与之概念体系不相匹配的技术用词。即使是软件工程师也必须学会用领域术语、行业参考数据模型或者用表单去讨论有关的模型结构问题。
　　词根表和库结构是软件工程师看到的领域知识的最稳定、最基础的内容，但是要更好地理解它，必须上溯去学习更多的领域知识。
　　
　　利用词根表实现标准化命名
　　
　　词根表就是行业应用软件中用以表述领域术语的词码表。词根的含义是最基础的词及其缩写符号，也可能是某些词根组成的新词，所以词根表中充满了“造词”的创新。统一词根表有标准化的含义，这样便于更大范围的交流。
　　行业应用软件运用领域的词根进行编程，是独有的特点。是以技术为主要背景的软件工程师困惑和不屑的地方，而且也是传统软件学科培训和教育中不太涉及的地方，因为传统的软件技术教育集中在系统级和通用的软件对象（它也确实不知道以后想用在什么地方）。
　　与系统软件和通用型软件不同，行业应用软件的主要对象是有特定含义的领域对象，这些对象庞大而且变化频繁，并构成特定的语义网络。如果我们采用系统软件开发或一般数学思维，就会命名太多的“变量”，反而增加了理解的难度并降低了处理的效率。另一个原因是行业应用软件是一种应用型软件，它要频繁、高效地映射程序对象与领域业务（术语）对象的关系，越直接的表达，映射的效率就越高。所以我们被迫使用领域术语中稳定的部分做成词根表，以便在行业应用软件中有效地使用。
　　引入词根表的另一个原因是语言学中符号操作问题。由于我们使用的是中文进行领域知识的表达，而中文在符号操作方面有先天的不足，拼音文字又反映出较弱的表义特征。所以词根表又出现了一个翻译问题，即: 所有领域术语中文的词和词根都必须有好的英文的词和词根对应。这又给行业应用软件工程师带来了新的挑战。他们必须学会领域术语包括中英文两种用词，如果不做充分的基础准备，我们行业应用软件的用词就会出现“百花齐放”的发散状态。归纳地说，词根表的主要项就包括: 中文含义、分类、中文词、中文词根、英文词、英文词根、备注，或者更复杂的变种。
　　词根的分类是类似于字典或图书馆的索引手段。总之，我们要对基础的用词做全面的管理，就像我们过去做系统软件时有一个编程约定，词根表就是补充了这部分内容。
　　
　　库结构是一种蓝图数据库结构
　　
　　我们所说的库结构是有特定含义的。它的定位是在领域数据参考模型和具体的行业应用软件中使用的大量数据库之间寻找一种中间结构。它要克服领域数据参考模型过于通用、对编程指导太弱的问题; 也要克服现实程序中成百上千的库表结构无法进行概念梳理的问题。更直接的目的是，目前很多行业应用软件数据库文档，没有一个“引言”，没有一个重要的原理描述工具――就像一个巨型仓库缺少目录和索引的介绍，是很不方便的。而文科背景的人员，有更强的写作训练，会写各种摘要和汇总，但涉及技术对象的摘要和汇总对他们也确实是一个挑战，大家需要讨论一个新的工具。简单地说，本文所说的库结构就是一种蓝图数据库结构。
　　
　　库结构的抽象原则
　　
　　●抽象的分类原则
　　库结构既然是蓝图型数据库，那它必须要做某种抽象，我们要给出一些抽象原则，首先的抽象原则就是分类。为了简化起见，我们分成四类。具体如下:
　　1. 记录事实型库结构类（纵）
　　记录事实型库结构类表示具体某一细分领域的结果性结构，是领域纵向的、有多个元素复合而成的、记录事实的结构。
　　组成= 区别其他结构的符号（本体）+ 组成元素（维度）清单及相应元素特性（元素属性）+ 本结构的特性（结构属性）+ 标量
　　2． 约束型库结构类（纵）
　　约束型库结构类表示对相应细分领域的记录事实型库结构的控制约束结构，是以细分领域为纵向的、控制行为中的稳定部分的结构。
　　组成= 区别其他结构的符号（本体）+ 组成元素（维度）清单及相应属性 + 本结构的特性（结构属性）+ 标量（约束记录事实结构的标量）
　　3． 通用关系型库结构类（纵/横）
　　通用关系型库结构类表示可以跨越不同细分领域，强调在记录事实型和约束型结构中主要元素之间的一些通用的、固有关系的结构。
　　组成= 本体+ 维度+ 属性
　　4． 代码/单元素库结构类（横）
　　代码/单元素库结构类表示在以上三种结构中独立元素的结构，它的取值称代码，所以也简称代码库。
　　组成= 本体+ 属性
　　这里说明的本体主要是指具体对象本身，是区别于其他对象的独立存在体，在行业信息化模型中，更多的是领域概念主体。
　　强调库结构的分类是一种重要的抽象组织方法，它便于我们对具体问题做概括性、代表性分析，每一种分类都有一些类比:
　　其中，记录事实型库结构类反映数据库结构中，领域最细分组合的特性和记录信息事实（带标量）的特征。如果与化学类比，它是一类长分子或工程性化合物。约束型库结构类反映对于记录事实型库结构的约束事实（标量）特征性结构，它表示一种对基础结构的控制结构，而且是相对的，即: 也存在约束的约束型库结构。与化学类比，它是某个化合物的约束表示的分子式。通用关系型库结构类反映一种通用约束关系，它可能在很大的范围内，也有可能在一个相对小的范围内。与化学类比，是一种通用的少元素的分子式（如: H2O）。代码/单元素库结构类反映独立的元素及取值，它的范围是最通用的，所以称为横向的。与化学类比，是类似元素周期表或所有的元素列表。
　　分类的主要目的是进行概念的分层和概念的划分，具体的原理我们在后面补充说明。
　　●抽象的忽视原则
　　一般而言，在讨论分类时，越横向的越通用、越倾向为一种环境描述，在具体细分领域中越要淡化（忽略横向和环境），而把注意力集中在具体领域细分中的记录事实型和相应的约束型结构中。从写作方法上看，这是一种只做少量的背景描述就直论主题的方法。它的优点是突出重点，缺点是读者要有一定的背景知识。把握背景描述的量，永远是写作的技巧。
　　●抽象的明细原则
　　而在记录事实型库结构中，有很多元素复合而成，我们要把注意力关注在最多元素复合的、有特征标量的库结构（有时称为事实表，或最明细表），因为从信息论角度看，它带的信息量最多。
　　这种抽象是不是完备和通用呢？我们没有给出证明，它需要由实践来检验。但是它起到了划分不同概念库结构的作用，并突出了我们讨论问题的重点。这种分类聚类的方法并不一定唯一，有可能是四类，也可能是五到十类，但是它可以帮助我们讨论内容。
　　
　　建立蓝图数据库
　　有了以上的抽象原则，我们就要给出具体的典型领域结构的库结构。这些库结构给出以后，特别是纵向的库结构，我们细分的领域数据模型就基本上确定了，大家就可以自己做实践了。
　　有了这些方法，我们就可以写一个面向具体领域、涉及成百上千个库结构的原理性介绍文档，有时称做原理性介绍或白皮书。
　　总之，它是一种蓝图说明，类似UML工具（传统的UML工具是以流程蓝图为主的，如顺序图、协同图、活动图，而结构抽象只有一个类图，相对比较简单，并且没有领域模型的支持），它辅助我们理解在一个行业应用软件内用PDM工具管理的上千个具体的库结构（这上千个库结构相当于建筑工程的工程图，而讨论原理时，应该有个工程蓝图）。
　　有了这样的蓝图库结构，不同的领域项目组，可以进行更有效的沟通交流，甚至加强标准化的工作。要让软件工程师学会用蓝图的方法沟通、表达自己的想法，而不是只能在一个很低的工程图范围内，逐表地讨论自己的设计（由于它的抽象能力太低，所以总不能进行更高效率的沟通）。
　　所有的蓝图，本质上采用的是“概念分层”和“概念划分”方法:
　　●概念分层
　　我们把概念分成上下两层，上层叫上位概念，下层叫下位概念，上位概念一般是下位概念的抽象。这种定义在专利文献写作时被普遍使用。因为它决定了我们在涉及知识产权保护时保护的范围，这也是文档级概念表述最具可操作性的框架方法。在库结构中，上位概念往往是概括性更强的库结构，很多时候一个下位概念对应几个上位概念的结构，就像一个明细表对应几个汇总表一样。
　　由于上位概念结构都包含下位概念结构，是不是越抽象越好呢？不一定，这取决于我们描述的侧重点。很多时候，流程反映功能/操作，如果大量的功能和操作都发生在某个下位概念结构，我们再一般化到上位概念结构的话，我们倾向于直接讨论这个下位概念结构。这样更有针对性，更容易理解。
　　在词根表的取值上和在库结构的命名上，我们都要区分概念的分层。
　　●概念划分
　　概念划分本质是概念组成规划，但要求是均匀、完整，它与数学中“划分”的概念是一样的。
　　把一个黄瓜均匀地切成片，就是一个良好的划分。至于分了多少片，有时不太重要。但是分得不均匀，我们认为不是一个太好的划分。
　　概念划分的难点，还不止于此。因为黄瓜是可以物理度量的，就像整个化学科学也是建立在分子物理的基础之上的，它是可以度量的。而概念划分的度量太不可测量了，这甚至涉及大量的语言、语义的知识，词根表中的词义概念是主要的载体，从方法上看，我们甚至要在更多艺术类学科寻找灵感。一首好诗，往往伴随好的概念划分、比喻和对仗。在具体的领域中，只有熟知领域概念的人才能更好地划分概念，甚至于“创造”概念。概念“汇总”有时侧重为一种技术，而概念“归纳”有时侧重为一种艺术，蓝图一般是“汇总”和“归纳”综合的产物。
　　更进一步的看，信息科学，可以不完全基于物理学或物质的基础，它可以是纯的人类思维产物，但是它通常与物质基础有很好的对应关系，如:
　　物质对象= 物质本身(本体)+ 特性 + 特征量
　　概念对象= 概念本体 + 特性 + 标量
　　从操作层面看，并不是越物质越好。从物质的描述上看，我们已经开始大量的人为概念化了，因为纯的物质几乎无法进行高效的信息加工和处理。
　　物理的蓝图与原对象有一个比例尺，而概念的蓝图只能在概念分层和概念划分的基础上，灵活地运用分类原则、忽视原则和明细原则。以纵向记录事实型库结构为例，如果元素也可以是结构的话，典型的纵向结构就是一个树枝图。如果只能是元素的话，就是一个鱼刺图。在保险行业，ACORD就给出一个典型领域细分“保单”树枝图的结构。虽然在应用软件中，我们有很多表示“保单”的库结构，但作为蓝图可以就此一个。
　　有人会问: 既然行业参考数据模型已经有人讨论了，蓝图数据库是不是就已经存在了呢？从现实看，确实不是这样的。但一般情况下行业参考数据模型有通用的标准化含义，它是一个蓝图数据库的上位概念结构，也就是说我们的蓝图数据库受行业参考数据模型的引导，但细节的创新全靠我们自己。这也并不奇怪，因为我们的具体行业应用软件是五花八门的，特别是各种约束的结构也是千变万化的，在现实中，我们也要进行相应的交流，所以蓝图数据库似乎永远有其生存的空间！
　　链接一
　　词根表和库结构与过程管理的关系
　　词根表和库结构的产生过程是迭代循环产生的，是与过程管理密切相关的。在组织上我们可以先从不同的项目组和部门产生，通过定版、沟通、讨论，甚至是比赛，来逐步完善我们的内容。当达到一定统一水平的时候，我们会在更大的范围内做出引导性建议。当相当成熟了之后，作为强制性的标准，加以统一。过程管理是保证词根表和库结构走向成熟的重要手段。
　　
　　链接二
　　词根表和库结构与支撑技术的关系
　　传统的支撑技术反映更通用的支撑手段，在数据库技术指导下，支撑性技术反映传统的数据库原理技术，特别是关系数据库技术，在应用系统实现时确实是数据存储管理的基础。就像写文章，一定要有好的笔、纸等工具（古代确实不如现代），但是文章的结构、分类是一门相对独立的学问。过去软件工程师把太多的注意力放在支撑技术上了，而今天我们提倡的是要均衡发展，更多地关注构成领域模型的要素。
　　
　　作者简介
　　左春
　　中科软科技股份有限公司总裁，中科院软件研究所研究员，中科院研究生院软件学院计算机技术学科专家组专家成员，1998年获国务院政府特殊津贴奖。
　　长期从事计算机管理信息系统和计算机辅助软件工程的研究和开发。主持开发了《保险业务综合管理信息系统》系列软件产品。这些软件目前已经推广到了全国一半以上的保险公司，并成功地进入香港市场，取得了显著的经济效益和社会效益。