第15组论文阅读内容介绍及读后感

沈煜 2023-04-09 19:45:43

A pattern language for use cases specification内容介绍及读后感

在过去的十年中，出现了一种趋势，即认为模型不仅是文档工件，而且是软件工程过程中的核心工件。除了有利于促进对所研究的系统形成共同一致的愿景，模型还可以通过元建模、模型转换、代码生成或模型解释等复杂技术去实现创建或自动执行基于这些模型的软件系统。为了更好地支持软件开发生命周期的活动（从需求规范到产生式编程技术的使用）我们需要以更严格的方式指定需求，不仅仅是非正式的文本规范，还有更正式的文本或基于图形的模型。为解决上述问题，其中有一些方法被归类为模型驱动开发；其主要集中在需求、分析与设计、实现等方面。

一个设计模式主要被看作是一个通用的解决方案，可以在不同的问题和情况下多次应用。此外，设计模式在程序的维护和升级中提供了极大的灵活性。多年来，模式的概念被研究人员和从业人员采用，不仅用于设计和实现，也用于其他软件学科，如需求工程或测试工程。需求模式被定义为 "编写特定类型需求的指南"，或 "基于可重用经验的框架，帮助需求工程师在尽可能短的时间内编写或建立更高质量的需求"。其主要目标是引导分析人员理解问题；提供一个共同的框架来定义需求，通过这个框架可以更好地评估、设计、构建和测试软件产品；以及能够将系统的设计追溯到最初的商业目标。

在介绍相关内容之前，该论文介绍了几种现有的模型驱动开发(Model-Driven Develoopment ,MDD)方法；包括ProjectIT、SilabMDD和RSLingo。ProjectIT的目标是提供一个完整的软件开发工作台，支持项目管理、需求工程、分析、设计和代码生成活动；ProjectIT-Requirement是ProjectIT架构中处理需求工程的组件；其主要目标是开发一种用于定义和记录需求的文本语言，通过提高其严谨性，促进可能用于MDD方法的模型的重复使用。SilabMDD方法是Silab项目的主要成功，其主要目标是实现软件需求的自动分析和处理，以实现软件系统的不同部分的自动生成；在开始时，Silab项目被分为两个子项目：SilabReq项目专注于用户需求的形式化，并将其转换为不同的UML模型，以促进分析过程并保证软件需求的质量；SilabUI项目专注于基于用例规范的用户界面的自动生成；当这两个子项目都达到理想的成熟度时，可以进行整合，即将SilabReq项目生成的一些结果作为SilabUI项目的输入。通常，在MDD中，实现是由模型（半）自动生成的。尽管用例是叙述性的，但没有一个标准规定用例的文本规范应该是什么。在SilabMDD中，开发了SilabReq DSL语言用于用例规范。它需要对用例规范进行严格的定义，特别是描述行动步骤的顺序、前后条件以及用例模型和领域模型之间的关系。SilabMDD是用例驱动方法，但它没有过多关注于用例的引出方式，用例可以从业务流程或纯文本中获取到。如果需求是以某种形式的模型表达的，那么就有可能自动使用适当的转换来提供用例。ProjectIT-Requirements发展到一个更灵活的方法，名为RSLingo。RSLingo是一种提高需求规范质量的语言学方法，基于两种语言和它们之间的映射：RSL-PL和RSL-IL；RSL-PL是一种可扩展的语言，用于定义语言模式，与自然语言处理和文本提取工具一起使用，从用自然语言编写的需求中自动产生RSL-IL规范；RSL-IL是一种形式化的语言，有一套固定的结构，用于表达和传递大量需求工程所特有的关注点。

该论文提出的模式语言主要适用于信息系统的用户需求规范，由以下规则组成：定义使用案例类型；保持使用案例与领域模型的一致性；定义具有不同场景和交互块类型的使用案例；定义具有不同行动类型的使用案例。

软件密集型系统分为两类，一类是信息系统，负责收集、存储、转换、传输和处理信息；一类是嵌入式软件密集型系统，其中，软件是系统的一部分，它与硬件紧密结合。本文提出的模式语言主要适用于信息系统的用户需求规范。本文提出了四种模式，分别是定义用例类型、使用例与领域模型保持一致、定义具有不同场景和交互时的用例以及定义具有不同动作的用例。这些模式主要是规范了用例、参与者、场景、领域实体、用例动作、交互块等模式概念模型的使用过程。在这里，本文使用一个基于“账单系统”案例研究展示模式在实际案例中的运用。

第一种模式，是定义具有不同类型的用例。我们注意到在很多系统中，很多用例的目标都是访问和管理数据实体。即针对数据的增删改查等。针对这个现象，我们可以确定一种模式来进行分类。在一个用例模型中，将用例按照各自的类型分类，分配给各自的领域实体，以确保用例和领域模型之间的一致性。首先，我们应该定义用例类型，大多数用例可以分类为实体-创建、实体-搜索、实体-查看、实体-更新或实体-删除，或者这些类型的组合，例如实体-管理。其次，根据这组类型对每个用例进行分类。最后，把每个用例与补充领域模式中定义的主要实体联系起来。

第二种模式，是保持用例与领域模型的一致性模式。一个用例同时封装了结构和行为，结构与行为不能分离，它们在用例动作、前提条件和后置条件中重叠。用例动作描述了用例的行为，同时它们又隐藏了用例的结构，因为用例中封装的结构是领域模型的一部分。问题是如何正确地确保这种一致性，考虑到有在整个需求规范中，有许多粒度不同的用例。为了确保一致性，我们的方法是：让用例的每一部分都必须与该领域模型中定义的实体相关。这样做的好处是产生了更加一致和完整的模型，并且可以在MDD方法的背景下使用。

第三种模式，是定义具有不同场景和交互块类型的使用案例模式。用户与系统的交互通常是通过图形化的用户界面完成的。因此，图形用户界面被行为者用来向系统发送请求以执行系统的操作，以及让系统呈现执行系统操作后的结果。我们如何描述这种交互，以便将与用户界面相关的信息与对系统运行重要的信息分开，同时也保证它们之间的一致性？我们的解决方案是使用交互块来指定角色和系统之间的交互。这样做的好处是清楚地定义了系统所需的行为，也提供了不断检查用例和领域模型之间一致性的能力同时也是以独立于平台的方式指定用户界面细节的良好基础。

第四种模式，是定义具有不同动作的用例。在MDD方法中，用例的结合需要严格缜密的规范，作为一种用户需求规范的技术，用例因其实用性和可读性而广受欢迎。但目前依然存在不同的动作类型来表述用例场景，并且这些动作的语义并不总是有明确的定义，导致用例规范的需求和水平模糊不清。而为了更好地指定每个用例动作的语法和语义，用例规范应该考虑一组预定义的用例动作类型，分为用户执行的动作和系统执行的动作。此外，在分析需求和设计用例时应该注意，用例应该以清晰和准确的方式定义，而不同类型的用例动作可以在不同的用例交互块中被定义。MDD模式允许定义交互块和用例动作之间的正确关系，这在其他模式中也很常见，比如silabMDD方法就是直接遵循这条准则。

综上所述，为了产生高质量的信息系统的需求规格，这些规格需要不断地检查一致性、完整性和正确性。在本文中，我们提出的方式可以保证在处理密集型信息系统时，将保持用例模型和区域模型之间的一致性作为更为重要的部分。

...全文