模型驱动软件工程教学框架的演变与改进

可在www.sciencedirect.com在线获取理论计算机科学电子笔记321（2016）41-65www.elsevier.com/locate/entcs模型驱动过程框架的演进WilsonP'adua1，2巴西米纳斯吉拉斯州贝洛奥里藏特联邦大学计算机科学系摘要我们讨论了Praxis的演变，一个模型驱动的过程框架，建立在教育和专业应用程序的反馈，在过去的十五年。我们遵循实践的第一个版本的演变到目前的一个，讨论什么是介绍了每一个。对于过去和当前的版本，我们对模型改进进行了分类，讨论了它们的性质和原理，这些改进来自于收到的反馈。关键词：过程、模型驱动开发、模型转换、CRUD事务、框架、重用、持久化数据。1引言根据CMMI [10]，定义的软件开发过程具有主要的过程描述，并将过程相关经验贡献给组织过程资产。通过过程框架，我们定义了一组工件，其中包括过程描述和其他重要类型的资产，如可重用库和指导资源。这种框架被定义为模型驱动的，当模型是其核心工件时，其他工件部分或全部派生。在这项工作中，我们描述了一个模型驱动的框架是如何在十五年的时间里，通过教育和专业应用程序的反馈所建议的改进来发展的这里讨论的过程框架是Praxis，其主要目的是支持软件工程课程项目。因此，在过去的十五年里，它一直被用于支持软件工程课程的教学。1我们感谢IBM Rational在IBM Academic Initiative中支持这项工作。2电子邮件：wppf@ieee.orghttp://dx.doi.org/10.1016/j.entcs.2016.02.0041571-0661/© 2016作者。出版社：Elsevier B.V.这是一篇基于CC BY-NC-ND许可证的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。42W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）41此外，作者本人在面向行业的研究生软件课程中系统地应用和评估了Praxis。这种应用的结果已在其他地方讨论过（[30]，[31]，[32]，[33]）。正如那里更详细地显示的那样，这些课程的学生需要使用完整的过程开发小型典型的课程包括四个软件工程学科，每个学科大约30个小时，典型的学生项目大约有100到150个功能点。Praxis-Synergia是一种为现实项目量身定制的衍生过程，已应用于数百至数千个功能点的应用程序开发中。该应用程序由Synergia执行，Synergia是一个基于大学的软件工程实验室，主要为政府组织开发合同下的实际应用程序（[35]，[5]）。这些年来，实践过程一直在发展，主要是通过课程和协同项目的反馈本文描述了在这些年中引入的变更，因为收集和分析了来自工艺使用的反馈在第2节中，我们讨论了过程和建模改进的目标，并对它们进行了分类。在第3节中，我们介绍了一个模型驱动的开发过程的演变，面向支持课程项目，显示在每个版本中执行的改进，这些改进是如何建议从其应用程序的反馈，以及它们引起了什么样的变化在第4节中，我们讨论了cur-租工作。 结论见第5节。2流程改进2.1改进目标一个主要的过程改进目标是使其更有效，也就是说，帮助项目在特定的约束条件下完成其使命。对于现实生活中的项目，这通常意味着交付具有令人满意的质量水平的产品，以可证明的方式满足产品需求。然而，即使是一个完全有效的过程，如果它不是同样有效的，在其市场预算和进度限制内完成这样的任务，也将不允许竞争性开发。在过程的演化中，来自过程应用的反馈导致了改进过程有效性和效率对于教育过程，有效性还意味着运用他们在课程项目中的应用旨在传授的知识效率也意味着将这些项目保持在课程预算的时间和效率之内。2.2流程构件软件开发过程旨在生成可执行代码（如应用代码和测试脚本）及其环境数据（如数据库模式、测试数据、配置文件、本地化文本、图形和其他资源文件）。许多其他工件有助于交付这样的代码和数据。也许有些被W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）4143其他方法可以由工具生成，而其他方法可能需要至少部分地手动导出。这些人工制品包括：• 一组模型，它描述了要解决的问题和建议的解决方案，通常使用图形语言，如UML;• 供人类使用的技术文档和超文档，例如需求说明、手动测试脚本、可视原型、用户手册、在线用户帮助和模型本身的超文档表示• 管理工件，如计划和报告;• 记录数据的日志，可能以部分或完全自动化的方式记录，例如工作、评估和测试日志。2.3建模改进有几种过程改进行动要求对工件和实践进行更改出于讨论的目的，我们将它们分为以下几类：工件重组、转换精简、过程简化、重用增强和指导增强。当过程工件集合中存在结构性更改时，工件重组发生;在模型驱动的框架中，最重要的是其核心模型中的更改。 集合中的模型可能会改变，或者可能会有变化在他们的内部。一个特别有趣的例子是模型分层，其中模型或模型部分被分成几层，这样一个层只使用同一层或下面一层这些层可以在派生的人工制品中镜像转换流线化可以应用于生成导出的工件、其他模型或相同模型的其他部分的模型转换这包括转换自动化，但也包括转换部分或完全手动的情况这可能是因为衍生需要人类的设计或选择，或者因为自动化可能不具有成本效益，至少在给定的时刻。在这种情况下，精简有助于以更系统和可靠的方式执行这些任务。过程简化意味着丢弃那些实际上没有用的工件或工件部分，从而减少过程开销，使其更加敏捷和高效。然而，选择要丢弃的工件需要仔细的分析，以避免降低质量保证，这将导致返工的增加，这可能会抵消敏捷性的提高。重用增强是旨在促进模型和派生工件重用的操作。重用通常是提高流程效率的最佳方式[13]。与其他方法相比，例如减少过程开销，减少项目返工和通过使用更强大的工具实现自动化，它通常需要更多的长期投资，但回报更大指南增强适用于支持过程工件，以改进开发人员使用模型的方式。它们包括对过程描述的增强，也包括对参考材料的增强，如过程使用指南、过程44W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）41标准、工件模板、应用程序示例和教具。3过程演变3.1版本1.0Praxis 1.0版于2000年出版，并在2001年出版的教科书（葡萄牙文）中得到充分描述。它是从前几年根据工业客户的合同开发的以前的工艺发展而来的。从一开始，它的主要目标是支持课程项目，遵循Humphreys过程的概念（[16]，[17]，[18]）。此外，它还打算运用UML和SW-CMM [10]中的关键概念。它的过程工件按照IEEE软件工程标准1993年版[5]的规定进行组织。过程结构松散地受到MBase [9]的启发;它与其他MBase后代（[22]，[3]，[25]）有相似之处，但总体而言，其生命周期模型更接近级联而不是螺旋。几个IEEE风格的文档是它的主要工件;分析和设计UML模型被用作组织信息的手段，这些信息应该出现在IEEE文档中，用于需求，设计和测试;几种电子表格被用作管理文档的来源单个分析模型，使用Rational Rose编写，作为一个例子。3.22.0版2003年，2.0版与第二版教科书一起出版。这是第一个真正的模型驱动版本，其中分析和设计模型得到了改进和重组，以容纳所有重要的技术信息。IEEE的文档成为了模型的衍生物;经验表明，对于在课程中开发的小型应用程序来说，它们往往很难使用和更新。表1总结了此版本中引入的增强功能，根据第2.3节中引入的类别对其进行分类，并说明其描述和原理。表12.0版中的建模改进类别描述理由制导增强样品申请的提供说明框架使用重组Ratio- nal Rose视图单独的建模关注点重组模型和代码分层分离关注点;提高重用性示例应用程序提供了完整的分析模型及其派生的需求规范，但设计模型、其派生文档和应用程序W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）4145由于课程项目指定了整个应用程序，因此代码仅部分实现，但没有时间实现一个或两个以上的功能。支持使用Swing用户界面开发Java独立应用程序;这仍然是以下版本的标准环境模型使用Rational Rose标准视图：用例视图指定功能需求，在分析模型中，用户界面设计，在设计模型中;逻辑视图将问题概念和结构需求建模为概念类，在分析模型中，内部设计类，在设计模型中。建模工具允许正向和反向工程，设计之间模型和应用代码。设计模型中的逻辑视图采用分层结构和应用程序代码;它使用了Jacobson等人提出的边界层、控制层和实体层。[22]，加上一个在面向对象和关系表示之间转换持久数据的持久层，以及一个封装环境服务的系统层。过程生命周期模型变得更接近螺旋，尽管分析模型及其衍生规范仍有望在项目第二阶段结束3.32.1版过程框架的中间次要版本旨在测试增强功能，如果成功，则在以下主要版本中明确采用。这些中间版本在教科书中没有完全记录;当他们测试时，补充材料会提供。2.1版引入了重要的变更，这些变更经过测试、评估，后来保留在3.0版中。部分课程项目的结果在已发表的论文中进行了分析（[31]，[32]，[35]，[5]）使用2.1版。表2总结了它的增强功能。与2.0版的一个主要区别是引入了一个重用框架，用于与实现相关的工件：应用程序代码、设计模型和单元测试代码。这个框架提供了一个持久层，它使用Java反射来完全独立于应用程序，遵循Ambler [1]提出的设计重用框架，也被称为Praxis，提供了（大多是抽象的）基类，支持简单的CRUD函数（管理仅包含原始字段的持久对象）和具有单一强细节的CRUD（管理字段可能包含具有独立生命周期的其他对象的集合的持久对象）。这个重用框架受到了第一个工业应用项目中类似框架的其中一篇已发表的论文[5]详细讨论了重用框架带来的好处。多亏了它，才有可能完全实现具有至少100个功能点的应用程序，对应于大约5个CRUD功能，足以练习支持课程中教授的大多数技术非UML需求，设计和测试信息，以前只存在于IEEE文档中，被重新塑造为分析和设计模型的附件;相应的文档变成了纯粹的格式化报告，可以从模型中机械地提取出来。此后，他们逐渐46W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）41表22.1版中的建模改进类别描述理由重用增强应用程序代码和设计模型的重用框架允许应用程序专注于面向问题的代码重用增强独立于应用程序的持久层单独的cerns建模表示...的意思流程简化移民文件tagrant的to数据来自模型-避免模型和文档流程简化将数据从文档迁移到电子表格收集数据以提供定量反馈重组需求和设计原型用视觉辅助工具重用增强重用框架测试代码和模型简化测试驱动开发制导增强通过流程模型提供提供结构化的供应商信息流程简化管理人为因素精简项目人员从课程项目中删除。然而，IEEE文档仍然保留在示例应用程序中，以说明它们可能的外观;专业变体Praxis-Synergia自动提取IEEE需求规范，因为大多数客户需要它作为合同参考。所有的管理工件都变成了电子表格; IEEE文档被具有相同内容的电子表格所取代。他们的重点从仅仅满足IEEE标准，转变为收集有用的规模、工作和质量数据的手段，为过程演变提供定量反馈该框架包括对创建低质量需求原型和高质量设计原型的支持。示例应用程序使用了一个电子表格作为需求原型，使用了一个技术绘图工具作为设计原型，两者都生成HTML。原型并没有向模型添加信息，但提供了视觉反馈，特别是对最终用户。在这个版本中开始使用测试驱动的开发，使用JUnit [39]脚本来驱动和测试每个应用程序层。真正的系统测试，作用于实际的用户界面，没有被使用，因为当时可用的工具使用了非标准的脚本语言。然而，它们是通过在边界层中执行字段和命令的JUnit测试以某种人为的方式模拟的再利用框架-W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）4147工作包括测试脚本基类，其中包含大多数测试过程逻辑，允许它们的专门化集中于提供特定于应用程序的测试数据，并将实际结果与预期的应用程序结果进行比较。由于本过程版本的课程教科书没有改变，因此将补充过程信息作为UML过程模型提供给了试验班。这将流程本身表示为用例和类，使用Rational立体类型进行业务流程建模。与其他模型一样，所需的非UML信息由模型附件提供管理工件被组织在一个派生链中，该派生链开始于使用Rational RationalsitePro工具维护的需求数据库。它使用该工具提供的与RationalRose的集成，保持了从主要需求（由分析模型用例和持久类表示）到两个模型中的派生项的跟踪关系对于主要需求，该数据库还保存功能点计数及其原理。提取的功能规模报告提供了项目规划电子表格进行的估计。计划工件提供给项目控制报告，比较预期和实际的项目绩效。3.43.0版第三版和当前版本的教科书反映了新的或升级的相关软件标准，如UML 2.0 [28]，CMMI [10]，2003年IEEE软件标准集[21]，PMBoK [36]和SPEM 2.0 [29]; UML2.0和SPEM深入研究了建模。大多数极限编程[7]敏捷方法的实践都被采用;然而，模型仍然是框架的核心，不像XP，更像敏捷建模[2]。在这一过程中采用这些标准的目的是让Praxis用户有机会在实践中使用一些当时最重要的标准。事实上，迄今为止，所有这些标准都只作了微小的修订和改进。表3总结了它的增强功能。为了采用UML2.0，并且因为RationalRose的日落是预期的，模型迁移到嵌入在Eclipse中的IBMRationalArchitect。供应商提供的转换工具只能提供有限的帮助，因为UML 2.0带来了有用的新建模工具，比如更丰富的序列图来建模交互。诸如选择、迭代和使用引用之类的构造可以被正式记录，并且更正式的专业化定义有助于重用协作和用例。SPEM允许更好地记录过程本身。大多数流程模型迁移到EPFComposer [14]，提供更好的在线流程参考。然而，保留了一个较小的UML业务模型，以记录过程概念之间的结构关系，EPF没有很好地支持它，它关注于过程动态的表示UML 2.0和Rational Architect为原型概要文件提供了丰富的支持。在以前的版本中，构造型的目的有限，只是提供可视表示，以增强图表的清晰度。现在开发了Praxis概要文件，允许模型使用UML标记值（在48W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）41表33.0版中的建模改进类别描述理由重组模型迁移到Eclipse支持UML 2.0;旧工具制导增强流程模型迁移到EPF支持SPEM;更丰富的在线文档转型精简丰富的原型配置文件在模型中嵌入更多数据转型精简XML附件简化转换和可视化重组使用活动对场景进行建模改进的用例建模重组将模型划分为视图将模型与工艺步骤相重用增强划分为框架和产品级别在框架中组织可重用元素重组内部视图分层独立的架构、结构和行为重组分层测试视图和代码通过分离关注点重用增强持久层迁移到Hibernate更强大的坚持。使用自由元件流程简化改进管理工件数据精简;更好的数据质量保证建模工具）来保存以前保存在模型附件中的许多需求和设计信息。这些属性为人类用户和工具扩展提供了更方便的访问，特别是当一组标量数据与单个UML元素相关联时。例如，I/O需求的细节被保存在边界类的原型中;业务规则、用例先决条件和后置条件、非功能性需求、设计规则和设计决策被保存在原型化的UML约束中;持久性需求和设计数据被保存在原型化的持久性类中。另一方面，与UML元素集相关联的数据集合被保存为附件，因为在这种情况下，裸建模工具不容易使用。该工具为Java插件提供了一个API，比上一代使用的Microsoft OLE模型这是专业人士用的W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）4149Praxis-Synergia变体，为更复杂的数据提取工具提供可视化支持，例如功能点计数（[24]，[11]），以及需求规范和需求的生成和设计原型[24]。插件的开发被认为对教育版本来说太昂贵了。相反，许多附件都迁移到了XML，使用XSL样式表来提供可视表示。在需要计算的情况下，仍然使用数据表进行管理在标准版本中，示例应用程序中的原型在其他情况下，例如测试数据和用户消息，一个简单的转换将XML附件转换为Java属性文件，由应用程序在运行时查询。更丰富的支持和用例的形式化允许替换通过活动图描述用例场景的文本附件。用例专门化的更好的形式化和改进的用例建模Praxis保留了建模做什么（问题规范，对应于需求和分析学科）和如何做（解决方案设计，对应于设计，测试和实现）之间的鲜明区别。这种区别在其他模型驱动的、基于转换的提议中并不存在，比如AndroMDA [4]、Jarzabek和Trung [23]以及Mashkoor和Fernandes [26]。事实上，实践模型的名称改为问题模型和解决方案模型，以强调这一区别。问题模型应该是技术独立的，并且是问题复杂性度量（如功能点计数）的唯一来源对于一个给定的问题模型可能对应于几个解决方案模型，如果开发了几个解决方案，使用不同的体系结构和技术。代替Rational Rose强加的固定的主要划分，新工具允许在视图中划分模型，部分对应于每个功能开发中遵循的步骤在问题模型中，需求视图在面向用户的更高级别上对需求进行建模，使用用例对所需功能进行过程描述，并对业务规则和非功能性需求进行约束。分析视图使用概念级的类来保存更详细的需求，例如所需的I/O字段和命令，以及持久性需求;这些类的协作必须以令人信服的方式实现用例。在专业实践中，需求视图是在JAD风格的研讨会中构建的（如McConnell [27]所述），可能会协调不同用户的冲突需求，而分析视图则反映了与单个用户进行的详细访谈。解决方案模型有一个使用视图，用于建模外部产品设计，即其用户界面以及用户与用户之间的交互（例如导航和外观更改）。该视图表达了必须与问题需求相匹配的设计决策，但对于给定的技术，还包括对可用性、体系结构和实现问题的很少有其他方法提供这种视图，更少的方法使用UML模型，如RUP-UX [15]，但是专业变体的使用已经证明了它是 模型最有用的应用在该变体中，插件允许自动化50W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）41从使用视图生成可视化设计原型，使原型和模型保持同步。其他解决方案模型视图是测试视图，它从使用视图派生出一组测试模型元素，从中可以生成手动和自动测试脚本和数据;以及逻辑视图，它表示内部应用程序设计。建模工具提供的正向和反向工程工具用于保持最后两个视图分别与测试和应用程序代码同步分层现在在三个层次上进行在第一层，通过将框架划分为框架级来支持重用，框架级包含可重用模型，主要由抽象类、用例和协作组成;可重用代码库，与框架级解决方案模型的测试和逻辑视图相匹配;以及可重用工件，如XSD模式、XSL样式表和电子表格模板。在第二层，每个视图都有一个架构部分，其中需求和设计规则以及决策被表达为定型的约束;一个结构部分，其中这些约束被附加到类，属性，操作和关系;以及一个行为部分，其中这些类参与协作，包含来自用例场景的交互，在连续的链中。第三层用于在与代码层匹配的层中划分一些视图。分析视图有边界、控制和实体类层;逻辑视图包含额外的持久层和系统层。使 用 IBMRationalFunctionalTester 引 入 了 完 全 自 动 化 的 功 能 测 试 ，IBMRationalFunctionalTester提供了与Eclipse紧密集成的Java测试脚本。为了简化其有点复杂的API的使用，并提供一定程度的技术独立性，测试模型视图和代码也被分层并采用重用。一个公共层，由所有类型的测试共享，保存测试数据，由类表示，类的实例包含测试用例数据，类似的测试用例共享测试实体。在公共层之上，测试视图和代码被划分为黑盒层（包含系统测试）和灰盒层（包含应用程序实体和控制层的单元测试）边界层单元测试不再使用，因为根据流程指南，这一层必须只处理表示，将功能（如字段验证）委托给下面的层。为了进一步驯服复杂性并提供关注点分离和技术独立性，黑盒层使用三层类：测试检查员将数据移入和移出用户界面;测试检查员比较预期和实际结果;测试过程实现测试协作中的交互持久性处理经历了重大的变化。它决定采用Hibernate [6]，而不是改进以前的特定对象到关系转换机制，它的功能非常有限。这个决定是基于专业版采用Hibernate的良好结果，以及市场对该工具的接受，特别是JPA API，更容易W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）4151并 且 比 以 前 的 Java EJB 持 久 化 机 制 更 方 便 然 而 ， 为 了 允 许 上 层 基 于PersistentObject类的专门化来保留持久化的简单视图，JPA调用被封装在瘦外观层中，该瘦外观层提供与先前版本中的层相同的API在实体和控制层中只需要很少的更改，主要是为了允许Hibernate处理其持久性缓存的方式的一些附带影响。如果关系表名称遵循Hibernate默认值，则应用程序代码中必须存在最少的JPA持久化注释，仅用于标记持久化类及其返回持久化集合的方法在这个版本中，管理工件链继续在需求数据库中开始，因为这也可能与Architect集成。大多数更改旨在进一步简化它们，同时在工件之间保留一些冗余在一些情况下，这种冗余允许检测不正确的甚至伪造的数据，这在课程项目评分期间会受到严厉的处罚。一个重大的改进是采用COCOMO [8]来估算和规划项目工作。虽然有些旧，很难与其余的过程工具集成，但COCOMO已经证明了自己非常有用3.5版本3.5表43.5版中的建模改进类别描述理由转型精简更丰富的刻板印象通过报告轻松提取数据转型精简将XML文件匹配到立体类型复杂数据重用增强框架级问题模型促进重新使用拟合要求重用增强更丰富的CRUD模式在重用中支持更丰富的变化3.5版本是作为4.0版本的垫脚石而开发的。这个版本是该框架的第一个国际版本：所有工件都被翻译成英语，以及示例应用程序的用户界面，使用Eclipse对Java外部化字符串的支持。表4总结了其增强功能。框架构造型概要文件得到了增强，以简化派生工件的提取这些在专业环境中很有用，简化了大型开发团队使用的模型，正如我们在工业项目中的经验所显示的那样，其中许多不是高度UML优势的。对于教育版，使用Eclipse提供的报告生成器BIRT提取52W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）41生成问题级原型需要更复杂的数据提取;为此，原型属性结构匹配外部XML表示，XSL样式表为外部XML表示提供即时HTML生成。这使得仍然手动，但非常系统的原型和模型之间的匹配在以前的版本中，没有框架级别的问题模型，因为它比解决方案模型小得多，也简单得多。可以通过从示例应用程序复制粘贴来执行粗略的然而，在这个版本中引入了一个框架级的问题模型，建立在专业版本的经验现实生活中的项目已经从导致生产力损失的低重用中恢复过来问题模型元素的重用可能有助于需求工程师尝试将用户需要的功能融入标准化框架支持的模式，从而允许提供商对这些功能收取更少的在教育版中，预计这将指导学生将为他们的项目提出的需求适应重用模式。在过去的项目中，有时学生发现他们最初提出的功能太难实现，使用现有的模式。在这种情况下，他们被允许改变要求，但在他们意识到这一点之前，已经浪费了一些时间和工作。在大多数情况下，发现实现困难的函数不适合解决方案模型和代码中存在的模式;也就是说，一个单一的细节。对于其他类型的细节，示例应用程序提供了一些示例函数，但是修改它们比重用框架要困难得多。当前版本提供了对多个细节集合的支持，包括弱细节集合（其生命周期受主实例生命周期约束的处理这样的集合建立在UML参数化类（在解决方案模型中）和Java泛型（在代码中）的4现状4.1版本4.0目前，4.0版本正在开发中这个版本与3.5版没有太大的不同，可能反映了框架的稳定性大多数改进都很小;表5显示了几个主要的改进。对于解决方案级别的原型，可以使用HTML原型，就像对问题级别所做的那样然而，在以前的版本中发现，需要大量的JavaScript代码才能有一个具有重要行为的原型。原型公共元素的重用减少了每个新原型所需的JavaScript数量，但这个版本尝试并接受了不同的解决方案使用IBMRationalFunctionalTester工具发现的几个困难促使我们回到基于Junit的系统测试。到目前为止，随着Selenium [38]等工具的出现，JUnit环境中的系统级测试已经变得更加强大，并得到了JUnitParams[12]的补充。与我们的新方法，边界层的初步版本被用作解决方案级的原型。只有小的修改，然后需要改变W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）4153表54.0版中的建模改进类别描述理由重用增强作为原型的设计原型成为边界开发的途径伪影重组支持Selenium测试系统测试更类似于单元测试，在开源环境制导增强支持Vaadin绑定层许多面向Web的应用程序这是一个定义代码。两个版本之间的一些差异对应于实际和模拟控制层和实体层之间的差异;一些来自于对原型来说过于繁重的有效性检查;一些对应于只有实际版本才允许进行彻底测试的功能;还有一些是代码优化，应该只在最终代码中完成。差异通常小于代码的5%此外，还提供了边界层基础设施的附加版本，以支持使用Vaadin [40]组件的基于Web的应用程序。这增加了对基于Swing的本地接口组件的现有支持4.2一些示例在问题模型中，图1显示了应用程序中复杂使用的场景。然而，任何流程都不需要特定的事件流程步骤。这些都在CRUD抽象用例中描述，而程序管理具体用例专门化了CRUD抽象用例，如图2所示。只有原型化的属性需要实例化;一个场景的例子如图3所示。在这种情况下，该场景实例化了图1中所示的事件流程图四、问题模型由分析视图完成;实体和边界层的示例分别显示在图5和图6中。对于实体层，所有显示的类都继承自PersistentEntity框架类，这意味着它们表示数据库中持久化的信息图7示出了对应于图6中的模型的原型。在解决方案模型中，使用视图，如图8所示。这提供了一个比图1所示的问题模型视图更接近现实第六章54W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）41Fig. 1. 用例的要求W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）4155图10显示了Test视图的附件，该附件显示了 必须执行系统测试以进行验证。试验所用的数据见表，其中一小部分见图11。这里显示的数据描述了示例项目，其详细信息由以相同方式描述的其他项目定义，这些项目是每个项目集合的一部分。强集合是那些在项目存在后仍然存在的集合，因此在其他页面中进行管理，而弱集合则不是，并且完全在项目中进行管理图二. 示例用例图3.第三章。场景的构造型属性56W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）41见图4。 一个可重用的场景图五. 问题模型实体层W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）4157见图6。 问题模型边界层见图7。 应用接口原型58W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）41图9显示了附加到Use视图的文档化设计规则和决策的示例。图八、解决方案模型的使用视图见图9。 设计规则和决策W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）4159见图10。 测试用例见图11。 测试实体60W. Pádua/Electronic Notes in Theoretical Computer Science 321（2016）41见图12。 逻辑模型强实体图十三. 逻辑模型弱实体