摘要：传统的软件开发模式丅从提出需求到完成设计之间跨越的鸿沟是降低开发效率的主要因素。为了辅助设计人员进行高效的软件开发文中提出一个基于本体嘚需求分析报告模板和软件体系结构设计方法。首先建立领域本体模型、需求本体模型和软件体系结构本体模型；接着在需求分析报告模板阶段通过本体映射将用户需求映射到本体概念上，进行准确地需求质量评估；然后在体系结构设计阶段通过对网上共享的设计文档進行五种维度的语义标注生成语义索引，实现跨领域的语义搜索为设计人员提供更全面、更详细的设计文档作为参考；最后结合自己项目的特点，逐步构建、完善系统体系结构本文将本体作为描述需求和体系结构的基础，实现了需求到设计的平滑过度减少了设计人员囷用户进行交流的时间开销，对于整体提高软件开发效率来说具有一定的帮助
　　关键字：本体；语义网；语义标注；语义搜索；软件體系结构设计
　　中图法分类号：TP311文献标识码： A doi：
　　?S着软件的普及，用户对系统提出的需求也在与日俱增软件开发过程变得越来越複杂。一个良好的需求规格说明对于成功的软件开发项目来说是至关重要的但是需求工程阶段是既耗时又容易出错的，主要表现在如何獲取用户的真实需求以及如何发现需求中存在的错误这需要开发人员与客户不断的沟通交流，并且许多错误是在执行或测试阶段才被检測出来这大大增加了软件开发周期，降低了整体开发效率[1-4]在需求分析报告模板完成之后，接下来就要进行系统体系结构设计这一阶段要求开发人员从整个系统的角度进行考虑，设计一个从整体到部分的最高层次的划分[5]在这过程中，面临的最困难的问题就是如何满足鼡户需求和常见的体系结构设计目标如可靠性、安全性、可扩展性、可维护性等。除了提升设计人员自身的知识能力水平之外另一种辦法就是调研同类产品的情况以及技术特征[6]。通过了解当前世界上对这种产品所能提供的理论支持和技术平台支持再结合自己项目的特點，逐步构建完善系统体系结构但是如何理解设计文档中的领域词汇，如何从网上海量的数据中高效的选择和自己项目类似的文档这些都是我们所要解决的问题。
　　近几年研究人员探讨使用人工智能技术用以解决这些问题[1][2]。Avgeriou P等人在文献[1]中将软件工程定义为一个跨学科的问题与大量的情景、社会学、心理学、人类学和教育因素等有关，并且分析了其中可能产生的问题例如需求是不完整的、模糊的、不精确的等。针对这些原因Hany H Ammar等人在文献[3]中分析并提出有必要探索一个新的技术和方法，用于整合在软件工程中积累的理论、技术和资源提供一个统一的、共享的、公认的知识基础设施。因此他们将人工智能技术引入软件工程具体包括自然语言需求处理（NLR）、知识库系统（KBS）、本体和智能计算。
　　本体作为人工智能技术的一种能够用于复用、集成、合并数据和知识，构建一个统一的、共享的、公認的知识基础设施并且通过推理得到信息中蕴含的隐藏信息或错误信息。M. P. S. Bhatia等人在文献[4]中详细介绍了软件工程领域中各个本体的定义和实際应用价值包括Upper Ontology、Domain Ontology、Architecture and Design Ontologies等，但仅仅是一些概要性描述没有给出一个完整的知识体系来实现在整个软件开发周期中理解和沟通的共享。 　　针对本体在软件工程中应用的研究方向LI Zong-yong等人在文献[7]中提出一个多本体框架用于辅助设计人员进行需求获取，并且对框架中提及的多种夲体进行了描述但是该研究只是理论阶段，没有对本体中的概念进行形式化描述也没有验证本体如何对需求进行质量评估。R?ih? O.等人在文獻[8]中提出一种基于基因遗传算法的软件体系结构设计它将设计过程看成是一个搜索问题，即寻找一个应用通用方案的组合能够以最优嘚方式满足质量要求。通过基因遗传的启发式搜索方法自动生成一个合理的软件体系结构。但是该方法的出发点是一个已经满足功能需求的概念体系结构对于需求与体系结构之间的平滑过度没有很好地解决。H. Duran-Limon等人将本体引入软件产品线工程中在文献[9]中提出一种基于本體的产品导出方法，用本体作为描述需求模型的基础然后利用本体的逻辑推理能力，在需求模型到产品体系结构模型转换过程中提供推悝服务以此减少手动导出的开销，但是该方法只考?]了本体对需求模型的重构没有考虑质量属性在产品体系结构推导过程中对结构变囮的影响。
　　本文利用本体作为描述需求和体系结构的基础通过建立领域本体模型、需求本体模型和软件体系结构本体模型，帮助分析人员在需求分析报告模板阶段更准确的捕获和评估用户需求；在体系结构设计阶段利用语义标注和语义搜索技术辅助设计人员从海量嘚设计文档库中选择具有语义相似的系统体系结构文档作为参考，对实现需求到设计的平滑过度和提高软件开发效率来说都起到一定的帮助
　　文章其余部分结构如下：第二节概述了我们提出的整个框架以及框架中用到的本体的构建。第三节详细介绍本体在需求分析报告模板和体系结构设计阶段是如何发挥作用的第四节总结我们的工作并讨论今后工作的研究方向。
　　软件开发是一个复杂的、不断演变嘚社会活动涉及了许多层次和方面。为了能够帮助开发人员更准确地理解整个系统我们提出了一个基于本体的需求分析报告模板和软件体系结构设计框架。
　　图1描述了整个框架其中可大致分为两阶段，第一阶段：根据用户给出的需求文档结合领域本体和需求本体進行语义映射，为其添加语义信息同时利用这些语义信息进行需求质量评估，用以修改、完善用户需求第二阶段：通过软件体系结构夲体，对网上共享的软件设计文档进行语义标注建立体系结构本体和领域本体以及需求本体的一种内在语义关联，再根据系统的功能性囷非功能性需求以及架构限制和目标的系统高层架构通过这种语义关联进行语义搜索，按照搜索条件返回相应的结果例如整个设计文檔、文档中部分段落或者图表等，用于辅助构建、完善系统的体系结构
　　文中提出的方法是针对传统的瀑布式开发模型，但是在实际開发过程中很少完全采用瀑布模型因此在接下来的研究中，将进一步探讨如何在当前一些流行的开发模型中使用这种本体辅助设计思路如敏捷开发模型、RUP模型、CMMI模型等。
　　在框架中一共使用了四个本体：顶层本体、领域本体、需求本体和软件体系结构本体前三个本體在文献[7][10][11]中已经进行了详细的定义，我们对其只进行简单的介绍这里主要对软件体系结构本体的构建进行详细描述。
　　2.2.1顶层本体、领域本体和需求本体
　　首先我们介绍一个顶层本体[10]顶层本体描述的是通用的基本概念和它们之间的关系，例如object、environment、goal、task等都是独立于特定嘚应用程序的基本概念其他本体中的概念都是顶层本体中的概念的实例。
　　领域本体描述的是一种静态的、可重用的领域概念和关系例如汽车行业领域本体就表示了有关汽车部件的知识[7]。在需求分析报告模板阶段扮演了一个领域字典的角色
　　仅仅使用领域本体无法很好地表达出用户指定的系统功能需求和非功能需求，因为在领域本体中无法对用户的业务目标、质量属性等进行语义描述因此还需偠构建一个需求本体，也可以叫做系统行为本体[4][11]需求可以分为两种类型：功能需求和非功能需求，功能需求可以描述为系统执行的操作序列非功能需求表达了系统质量相关的方面。系统行为本体是对软件系统的行为进行建模例如在特定情况下系统将要执行什么操作，咜还定义了在一个操作执行之前需要满足的条件以及操作执行时系统的状态等。
　　2.2.2软件体系结构本体
　　我们使用本体开发工具Protégé来构建该本体。首先根据《Software Modeling& Design》[14]书中介绍将软件体系结构模式分为三类：结构模式、通信式和事务模式，将每一个类别中包含的模式概念莋为SoftwareArchitecturePattern的子类进行描述然后以一些常用的软件体系结构风格为基础，例如B/S风格、管道和过滤器风格、面向对象风格、仓库风格等进行归納总结，作为SoftwareArchitectureStyle的子类我们将每种风格中包含的 　　为了更全面地描述该本体包含的内容，这里我们使用了一个本体可视化插件OntoGraf图4表示叻软件体系结构本体可视化结果。
　　3. 基于本体的需求和设计方法
　　3.1基于本体的需求获取和评估
　　当拿到用户需求文档之后分析人員首先要做的就是挖掘用户的真实需求，这是由于人与人之间的交流沟通无法达到100%因此这一步也是最重要的。对于分析人员来说要想挖掘出真实的需求，就要求对业务和技术都有所了解这往往也是最难的，借助本体的辅助或许能够解决这方面问题
　　借助领域本体囷需求本体的辅助，可以从用户的角度来进行需求获取用户参与需求分析报告模板主要有两种方法：一是在领域本体的指导下填写问卷調查，意味着通过问题解决法来表达用户的真实需求二是借助CASE工具，使用领域本体和需求本体中的领域知识进行需求建模可以看出领域本体和需求本体的作用不仅是指导用户快速的提出需求，而且还能够保证最终的需求模型没有违反领域标准和规范
　　除此之外，通過领域本体和需求本体的结合使用还能够对用户需求的准确性、完整性、一致性、无二义性进行评估分析。为了能够分析出这些用户需求的质量属性必须先建立需求和本体之间的一种映射关系。首先对于用户提供的非结构化需求文档进行文字预处理针对每个需求进行實体和关系的抽取，然后将其映射到领域本体和需求本体的概念上如图5所示。
　　完成映射后也就意味着将用户的需求描述转换为用夲体中的概念和关系进行表示，即为需求文档中的用户需求添加了语义信息在假定映射正确的情况下，接下来可以利用这些语义信息进荇需求质量的评估并且反馈给用户和分析人员执行不同的解决措施。
　　（1）准确性检测：当一个需求条目能够被映射到本体元素上时我们认为它是针对一个问题域的准确的需求。对于无法映射到本体的需求反馈给用户询问其是否是有必要的，若是由于其中包含的概念是该领域的新型词汇那么就交由技术人员对本体进行添加修改，再重新进行需求的准确性检测
　　（2）一致性检测：如果在两个需求条目映射的本体元素之间，存在“矛盾”约束属性例如两个类是互斥类（Disjoint classes），那么我们认为这两个需求是不一致的通过在映射的本體元素中搜索“矛盾”关系来发现不一致性的需求条目，根据需求的优先关系来帮助用户和分析人员进行删改
　　（3）完整性检测：在悝想状态下，对于所有相关联的本体中的元素都应该出现在映射的需求条目中，例如一个用户管理系统的需求“Userscanchange the phonenumber for the binding”映射到本体中的元素為{change phonenumber}，而在需求本体中这些元素与{Add phone}和{Unbind，phonenumber}存在Complementary（互补的）关系这意味着和功能也应该出现在这个需求条目中，如果没有则可以认为该需求是不完整的需要向其添加新的概念元素。
　　（4）无二义性检测：如果一个需求条目被映射为若干个没有语义关系的概念那么可以認为该需求存在歧义，拥有多重含义针对这种情况需要将存在歧义的需求进行修改、移除或者分解成多个需求，以此消除歧义
　　3.2 基於本体的软件体系结构设计
　　软件体系结构对于软件开发有着举足轻重的作用，只要需求和体系结构确定之后这个软件就基本上可以萣型了。这就好比骨骼确定了这个人的体形就不会有很大的变化。
　　但是在实际项目开发中很少有团队会注重系统体系结构设计，甚至会忽略这一过程主要原因是需求是从用户角度看待系统，体系结构是从设计角度看待系统因此在需求和设计之间存在着巨大的鸿溝，这对设计人员来说不仅要有丰富的软件开发经验还需要拥有一定的领域知识。这里我们希望通过本体将需求和设计进行抽象化在抽象出的需求模型和设计模型之间建立语义关联来缩小这个鸿沟。
　　在前一节中介绍了如何将需求映射到本体中的概念和关系上这也意味着我们已经将用户需求抽象为一个需求模型。接下来我们将探讨如何利用语义标注[15]技术来对体系结构进行抽象
　　3.2.1使用软件体系结構本体的语义标注
　　如果说本体的构建主要是关于领域知识的抽象表示，那么语义标注可以看作是丰富本体的过程即添加、扩展本体實例。因此语义标注所要做的工作就是将现实应用中涉及的实例和抽象的本体概念联系在一起
　　这里我们使用的是GATEdeveloper，一个应用于自然語言处理领域尤其是信息标注与抽取环节的开放源码架构。根据前面建立的软件体系结构本体对匹配的概念、实例等元素进行语义标紸，其流程如图6所示：
　　执行该流程为资源文本添加语?x信息，这里我们提出可以按照表1中几个维度进行语义标注：
　　例如我们按照文档结构维度即标题、段落和句子三个方面进行语义标注，对标题进行标注的内容主要是关于系统或子系统使用的体系结构风格对段落进行标注时主要注重整段内容语义的索引，对句子进行标注时主要注重相关概念的提取其中语义索引包含的内容为本体中出现的概念，索引的键是概念及概念的属性索引的值是文档的位置、文档的内容、文档的语义信息。这种标注方法适用于结构化的设计文档对於无结构化的文档需要先根据经验对文档进行理解、总结，再按照上面介绍的三个方面进行标注
　　利用本体直接标注资源的优势在于標注方式灵活，并且能够确保语义标注准确率进而充分挖掘资源语义，增强语义标注效果经上述过程完成的语义标注结果是形成设计攵档的语义索引，语义索引主要保存了一个文档的三个主要信息：1.文本的层次级别（篇章、段落、句子）2.文本段落的内容。3.文本段落的語义标注后应将文本的索引结构以一定的形式保存起来，以供下一节的语义搜索使用我们将标注信息以可视化方式显示在文档资源中，如下图所示： 　　我??希望能够对每个文档都按照上面五种维度进行标注但是这样一来标注过程就变得十分繁琐，下一步我们将参栲近几年提出的一些新的语义标注方法对其进行改进例如Rajput等人提出的一种基于贝叶斯网络的语义标注框架[16]；Nguyen等人提出一种基于朴素贝叶斯和关联规则，并结合本体结构图和交互网络的语义标注方法[17]等
　　在标注完成后，将新的实例信息抽取到本体即保存在本体类的实唎信息中作为新的个体，在下次加载本体时应用通过这种信息抽取也可以促进本体进化。最后将含有语义标注信息的文本资源解析为XML文件格式存储形成语义标注库，代码片段如下：
　　3.2.2设计文档的语义搜索
　　在执行完语义标注和信息抽取之后下一步便根据标注生成嘚语义索引以及前面抽象出的需求模型进行设计文档搜索，我们将上一节描述的标注对象作为搜索条件根据不同的搜索条件返回相应的搜索结果。例如需要搜索使用了某个体系结构风格的整个项目设计文档便可以通过计算文档与查询实例的语义相关度，以及查询实例与攵档的相似度后得到各个文档的排序得分，按得分高低将排好序的搜索结果返回给用户
　　这里我们主要探讨如何在需求模型和设计攵档之间建立一种语义关联，实现跨领域的语义搜索关于搜索步骤、使用何种搜索算法、如何计算文档的排序得分、搜索返回的相关文檔的数量有多少、正确率有多少以及如何评估返回的结果等问题是接下来我们研究的重点，可以参考第二节中介绍的基因遗传算法的使用以及[18]中介绍的一种设计模式的匹配搜索。
　　为了建立这种语义关联我们需要找到需求本体和软件体系结构本体之间的关系。在第三節中我们构建软件体系结构本体时，将每一种体系结构模式或架构风格所能够解决的某些方面的问题归纳总结为Problem类而这些问题是从设計人员角度来进行描述的。如果从客户的角度来看待这些问题那么Problem类描述的其实就是用户希望系统能够实现的功能。因此可以将体系结構本体和需求本体通过对系统行为的不同角度的描述来建立一种关联，从而使本体映射后的语义需求模型和语义标注后的软件体系结构設计文档之间产生关系为实现跨领域的语义搜索提供条件。
　　3.2.3 系统体系结构设计过程
　　接下来我们将利用搜索出的软件设计文档結合自己项目的特点，逐步构建、完善系统体系结构具体步骤如下：
　　第一步建立系统体系结构元模型。由于设计文档中的概念是跨領域跨平台的所以先从中抽象出一个领域无关、平台无关的系统体系结构元模型是有必要的。这里我们参考OMG组织提出的MOF四层模型结构[19]所建立的系统体系结构元模型不仅仅是为了描述系统或子系统的体系结构，更重要的是它是从软件设计文档库中抽象而来的这意味着我們可以将它看作一个“设计蓝图”，更有效、更直观的指导设计人员理解、构建系统体系结构
　　关于如何构建以及构建什么样的元模型将是我们接下来要解决的问题，可以借鉴一些相关的研究思路例如[20]中介绍的通过构建系统特征模型来完成概念体系结构设计的方法以忣[21]中提出的一种基于本体模型的架构知识管理框架等。
　　第二步建立系统体系结构模型从系统的整体角度出发，结合用户需求进行体系结构设计这里主要考虑的是系统的非功能需求。
　　第三步建立子系统（子模块）体系结构模型这里可以根据用户对子系统的功能需求，有针对性的再次进行语义搜索然后对子系统进行元模型建模，进而完成子系统体系结构的构建
　　对于大多数系统的体系结构設计，我们都可以从现有的项目寻找共同点鉴于此，本文从本体技术入手先利用本体在领域知识表达方面的优势，帮助用户提出更加標准化和规范化的需求再利用本体内在的逻辑推理能力，通过本体映射进行需求质量评估快速的找到存在错误的需求，减少和用户交鋶的时间开销然后利用本体在知识统一和共享方面的优势，对网上共享的设计文档进行语义标注实现跨领域的语义搜索，从而更好地悝解和构建系统（子系统）体系结构缩短需求与设计之间的鸿沟。
　　在接下来的研究中我们将进一步细化框架中的每个细节，对多個本体进行完善修改针对设计文档的语义搜索方面，改进多维度的语义标注方法研究智能搜索算法的应用，设计并开发支持该框架的軟件平台

面向对象复习材料)（可编辑）,建築材料复习资料,建筑材料复习题,土木工程材料复习题,工程材料复习资料,机械工程材料复习题,复习材料,cfa考试复习材料,材料科学基础复习题,道蕗建筑材料复习题

第 7 章 面向问题域的需求分析报告模板方法 第 7 章 面向问题域的需求分析报告模板方法 7.1 问题域 7.2 问题域的划分 7.3 问题框架 7.4 问题框架的类型 7.5 PDOA方法的分析步骤 7.6 问题框架实例间的关系及其组合 7.1 问题域 问题域 与问题相关的部分现实世界 问题与问题域之间的相互关系 问题域和问题相互依存，问题处于一定的问题域之中脱離了问题域，问题就无法存在问题域也是与特定的问题相关的现实世界，脱离特定的问题考虑纯粹的问题域没有任何意义 7.1 问题域 问题域包括所有与描述期望效果有关的事务，可用来产生这些效果的方法也是问题域的一部分 用来产生相关效果的方法可分为直接方法和间接方法。 直接方法是指机器的输入、输出设备 间接方法包括用户以及可以执行任务的其他计算机等。用户需求可视为通过计算机程序在問题域中施加的效果这些效果是对用户预期的描述。用户需求描述中的每一个术语都代表了问题域中的相应事物必须用问题域中的相應事物来指称。 7.1 问题域 解系统：与问题相对应的是问题的解决方案 在软件开发中是指能在计算机上运行且能解决问题的程序。 需求分析報告模板方法或多或少直接以问题的解决方案即在机器中运行的程序为出发点来考虑待开发软件系统的需求。 从问题域与从机器域考虑哃一问题的侧重点不同所使用的技术、方法和表示符号也不相同。 用户只关心问题域的知识所以必须从问题域出发来获取并文档化用戶的需求信息。 7.1 问题域 需求分析报告模板文档、规格说明文档和程序之间的关系 7.2 问题域的划分 对于复杂问题的分析一般的做法是采用“汾而治之”的策略。人们一般采用层次式功能分解的方法 确定系统所需的各项功能； 若某些（或个）功能对应于一个足够小的具体实现單元，则由该实现单元直接实现这些（或个）功能； 否则把功能分解为一系列子功能，并重复步骤2和3直到所有子功能可分别对应一个足够小的具体实现单元。 7.2 问题域的划分 层次式分解方法的不足 把高层功能分解成子功能的方式可能有多种但没有任何方法可以提前告知這些分解方式中哪一个好或哪一个差，直到进入实现阶段时才可评价所采用的分解方式是否恰当而此时分解活动早已结束。 7.2 问题域的划汾 并行划分 将每个子问题看成是整个问题的一个投影通过不同角度的投影，将整个问题分解为一系列相互关联的子问题其中子问题的需求是整个需求的一个投影，它的接口也是整个问题接口的一个投影同时，在划分子问题的过程中以已知解决方案的问题或以已知解決方案的相似问题为导向，来对未知解决方案的整个待求解问题进行恰当的分析和划分 7.3 问题框架 问题框架是一种模式，它捕获并定义了瑺见的简单子问题的类型 7.4 问题框架的类型 需求式行为问题框架 思想：存在客观世界的某个部分，其行为要受到控制以使得它满足特定嘚条件。问题是要建立一个机器该机器施加所需要的控制。 7.4 问题框架的类型 命令式行为问题框架 思想：存在客观世界的某个部分其行為要依据操作者发出的命令来控制。问题是要建立一个机器该机器接受操作者的命令并施加相应控制。 7.4 问题框架的类型 信息显示问题框架 思想：存在客观世界的某个部分关于其状态和行为的特定信息被连续的需要。问题是要建立一个机器该机器从客观世界中获得相关信息，并按所要求的格式呈现在所要求的地方 7.4 问题框架的类型 7.4 问题框架的类型 工件问题框架 思想：需要一个工具，让用户创建并编辑特萣类型的计算机可处理的文本或图形对象或简单结构以便它们随后能被拷贝、打印、分析或按其它方式使用。问题是要建立一个机器該机器可以充当这个工具。 7.4 问题框架的类型 变换问题框架 思想：存在一些计算机可读的输入文件其数据必须被变换以给出所需要的特定輸出文件，输出数据必须遵守特定的格式并且必须按照特定的规则从输入数据中导出。问题是要建立一个机器该机器从输入中产生所需要的输出。 7.5 PDOA方法的分析步骤 特点 将关注的重点定位在问题及其相关的问题域上通过对问题及其问题域进行合理的分类，为分析人员提供解决具体问题的相关指南同时从问题域的角度出发，使用户能参与整个需求过程有利于更直观和真实地反映问题域的信息和用户的需求。 7.5 PDOA方法的分析步骤 步骤 搜集需求信息界定和描述问题及问题域； 划分问题域并开发相关问题框架； 根据问题框架的类型进一步描述問题域的相关特性。 7.5 PDOA方法的分析步骤 问题及问题域的界定与描述 上下文图界定并描述整个问题及其问题域存在的不足： 只描述了与解系统矗接相连的域而没有描述与解系统间接