用于分析形式化的需求以及定位错误的可缩放方法与流程
开发具有软件和硬件组件的系统往往涉及由消费者提供的系统需求。这些需求用于设计系统。在软件和硬件组件中的许多错误往往被早早引入(例如在需求捕捉阶段)，但是直到之后在组件创建过程中才可被发现。通常，在错误引入和错误发现之间的距离越大，与解决错误相关联的成本越大。
因此，将期望设计一种提供需求错误的较早检测的装置和方法。
技术实现要素：
根据一些实施例，需求由形式(formal)需求分析模块验证和确认(validate)。形式需求分析模块可包括各自被连续地应用到需求的类型安全模块、偶然模块、全局偶然模块、独立模块、自冲突模块、组冲突模块、完整模块、有条件的完整模块、满射(surjectivity)模块、部分满射模块和有条件的满射模块。如果需求不满足分析，在一个或多个实施例中，经由错误定位模块的运行而生成反例并显示给用户。用户然后能够编辑由错误定位模块识别的需求，并且再次应用形式需求分析模块以确认和验证更新的需求。在一个或多个实施例中，在验证和确认需求之后，为下一个设计阶段的开发传送需求，合并验证的和确认的需求。
该发明的一些实施例的技术效果是用于确认和验证需求的改善的技术和系统。由于将在下文中变得显而易见的这个和其它优点和特征，可以通过参考下面的详细描述和所附于此的图来获得该发明的本质的更全面理解。
其它实施例与存储指令以执行本文所述的任何方法的系统和/或计算机可读媒介相关联。
该发明提供如下的一组技术方案：
1.一种系统，包括：
通信设备，操作以与用户通信以获得一个或多个需求，其中每个需求使用形式符号来定义；
需求分析模块，用来接收所述一个或多个需求，存储所述一个或多个需求，并且个别地分析每个需求，以及以联合的方式分析两个或多个需求以确定冲突是否存在于所述一个或多个需求中；
错误定位模块，用来识别涉及所述冲突中的每个需求，并且指示所述一个或多个需求如何冲突；
存储器，用于存储程序指令；
至少一个需求分析处理器，耦合到存储器，并且与需求分析模块以及所述错误定位模块通信，并且操作以运行程序指令以：
个别地分析每个需求以通过运行所述需求分析模块的自冲突模块确定所述需求是否是自冲突的；
响应于所述自冲突模块确定所述需求自冲突，通过运行所述错误定位模块而生成错误解释；
响应于所述自冲突模块确定所述需求是自冲突的，从用户接收第一更新的需求；
重复地分析每个更新的需求以确定所述需求是否自冲突，直到所述自冲突模块确定所述需求不是自冲突的；
在确定每个需求不是自冲突的之后，通过运行所述需求分析模块的组冲突模块，以联合的方式分析两个或多个需求以确定两个或多个需求是否冲突；
响应于所述组冲突模块确定两个或多个需求冲突，通过运行错误定位模块生成错误解释；
响应于所述组冲突模块确定两个或多个需求冲突，从用户接收第二更新的需求；以及
采用所述组冲突模块重复地分析每个更新的需求，以确定所述两个或多个需求是否冲突，直到所述组冲突模块确定所述两个或多个需求不是自冲突的；
生成需求分析对于所述一个或多个需求是完整的并且确认所述一个或多个需求供在软件设计中使用的指示。
2.根据技术方案1所述的系统，其中如果存在对于其需求是不可满足的一个或多个监测的变量的输入值，而不考虑给予受控变量的值，所述需求是自冲突的。
3.根据技术方案1所述的系统，其中所述组冲突模块操作以对于一组两个或多个需求确定所述监测的变量的输入值是否是不可满足的，而不考虑受控变量的值。
4.根据技术方案1所述的系统，其中所述形式符号具有数学定义的语法和语义。
5.根据技术方案1所述的系统，其中每个需求可能是完整的或不完整的之一。
6.根据技术方案1所述的系统，其中所述需求分析模块的运行是动态的。
7.根据技术方案1所述的系统，其中所述需求分析模块的运行进一步包括在自冲突模块的运行之前，运行操作以指示所述需求中的类型违反的类型安全模块。
8.根据技术方案7所述的系统，其中在所述类型安全模块的运行之后并且在所述自冲突模块的运行之前，所述需求分析模块运行：
偶然模块，操作以确定单个需求是否是既可满足的又可伪造的；
在所述偶然模块的运行之后的全局偶然模块，其中所述全局偶然模块操作以确定一组两个或多个需求是否是既可满足的又可伪造的；
在所述全局偶然模块的运行之后的独立模块，其中所述独立模块操作以确定所述组需求是否是独立的。
9.根据技术方案8所述的系统，其中在所述独立模块之后运行所述自冲突模块。
10.根据技术方案1所述的系统，其中在定义所述需求时运行所述自冲突模块。
11.根据技术方案1所述的系统，其中在所述组冲突模块的运行之后，所述需求分析模块运行完整模块，所述完整模块操作以确定所述组两个或多个需求是否唯一地指定每个受控变量的值，为所述一个或多个监测的变量中的每一个给予一个或多个值。
12.根据技术方案11所述的系统，其中在所述完整模块的运行之后，所述需求分析模块运行有条件的完整模块，所述有条件的完整模块操作以确定一组需求对于一组指定的模式是否是完整的。
13.根据技术方案12所述的系统，其中在所述有条件的完整模块的运行之后，所述需求分析模块运行满射模块，所述满射模块操作以确定在枚举类型的所述一个或多个受控变量的每个输出值是否是可能的。
14.根据技术方案13所述的系统，其中在所述满射模块的运行之后，所述需求分析模块运行部分满射模块，所述部分满射模块操作以确定所述一个或多个受控变量的每个指定的输出值是否是可能的。
15.根据技术方案14所述的装置，其中在所述部分满射模块的运行之后，所述需求分析模块运行有条件的满射模块，所述有条件的满射模块操作以确定所述一个或多个受控变量的所有指定的输出值在一个或多个指定的模式下是否是可能的。
16.一种方法，包括：
接收使用形式符号定义的至少一个需求；
经由自冲突模块的运行确定所述需求是否是自冲突的；
在所述自冲突模块的运行之后，经由组冲突模块的运行确定两个或多个需求是否彼此冲突；
经由错误定位模块的运行，识别涉及在冲突中的每个需求以及所述一个或多个需求如何冲突；
接收更新的需求；
采用所述自冲突模块和所述组冲突模块重复地分析每个更新的需求；以及
生成需求分析对于所述一个或多个需求是完整的并且确认所述一个或多个需求供在软件设计中使用的指示。
17.根据技术方案16所述的方法，进一步包括在所述自冲突模块的运行之前：
在接收的一个或多个需求上运行类型安全模块；
在所述类型安全模块的运行之后，在所述一个或多个需求上运行偶然模块；
在所述偶然模块的运行之后，在所述一个或多个需求上运行全局偶然模块；
在所述全局偶然模块的运行之后，在所述一个或多个需求上运行独立模块。
18.根据技术方案16所述的方法，其中当用于所述需求的监测的变量的输入值是不可满足时，所述需求是自冲突的，而不考虑受控变量的值。
19.根据技术方案16所述的方法，其中在形式定义每个需求时运行所述自冲突模块。
20.根据技术方案16所述的方法，其中所述组冲突模块的运行进一步包括：
对于一组两个或多个需求，确定所述需求中一个或多个监测的变量的输入值是否是不可满足的，而不考虑需求的受控变量的值。
部件列表
编号 描述
100 软件开发系统
102 一个或多个系统需求
104 规范模型
106 基于需求的自动测试案例生成模块
108 设计模型
110 结构测试案例模块
112 源代码模块
114 可运行对象代码模块
116 消费者确认模块
118 形式需求分析模块
120 形式设计验证模块
122 基于模型的验证模块
124 结构覆盖分析模块
126 形式代码验证模块
128 基于测试的可运行对象代码验证模块
200 过程
210 过程步骤
211 过程步骤
212 过程步骤
213 过程步骤
214 过程步骤
215 过程步骤
216 过程步骤
217 过程步骤
218 过程步骤
219 过程步骤
220 过程步骤
221 过程步骤
222 过程步骤
223 过程步骤
224 过程步骤
225 过程步骤
226 过程步骤
227 过程步骤
228 过程步骤
229 过程步骤
230 过程步骤
232 过程步骤
234 过程步骤
236 过程步骤
302 类型安全模块
303a-k 错误定位模块
304 偶然模块
305a-k 错误解释
306 全局偶然模块
308 独立模块
310 自冲突模块
312 组冲突模块
314 完整模块
316 有条件的完整模块
318 满射模块
320 部分满射模块
322 有条件的满射模块
400 用户界面
500 模型
600 模型
700 需求分析处理平台
710 处理器
712 程序
714 处理逻辑
720 通信设备
730 存储器/存储设备
740 输入设备
750 输出设备
附图说明
图1图示根据一些实施例的系统。
图2A和2B图示根据一些实施例的流程图。
图3图示根据一些实施例的系统的框图。
图4图示根据一些实施例的用户界面。
图5图示根据一些实施例的模型。
图6图示根据一些实施例的模型。
图7是根据一些实施例的自动测试案例生成处理工具或平台的框图。
具体实施方式
开发具有软件和硬件组件的系统往往涉及由消费者提供的系统需求。可以以计算机可读形式在规范模型中合并或捕捉这些需求。还可以以人类可读的形式在规范模型中捕捉需求。然后可从包含在规范模型中的需求开发设计模型，并且可表达软件设计数据(例如规定的软件组件内部的数据结构、数据流和/或控制流)。然后可从设计模型中使用有资格的代码生成器自动生成源代码。
软件和硬件组件中的许多错误往往被早早引入(例如在需求捕捉阶段)，但是直到之后在组件设计和创建过程中才可被发现。通常，错误可能难以在过程中早早确定，因为需求可能是抽象的并且仅仅在系统的建立(例如生成最终的软件或硬件组件)时才可变得更加清楚。通常，在错误引入和错误发现之间的距离越大，与解决错误相关联的成本越大。
在一个或多个实施例中，可使用定理证明来形式分析需求，诸如包括在规范模型中的那些。在一些实施例中，其中分析生成不是定理的场合。可自动生成反例以图示需求在何处以及如何不能满足一些分析。
在一个或多个实施例中，使用形式符号描述需求(例如，符号具有精确的数学定义的语法和语义)。形式符号的示例包括但不限于：建模语言、一阶逻辑、集合论、高阶逻辑、编程语言和结构的自然语言。
在一个或多个实施例中，可以以增量方式验证和确认需求，其中可增量地和动态地检查需求(例如，同时形式化/写入个别的需求)。
在一个或多个实施例中，验证和确认策略例如可被集成到需求捕捉工具中，使得用户一更新需求，需求的验证和确认就自动发生，而无需用户明显地发起验证和确认分析。
在一个或多个实施例中，验证和确认策略可用于分析需求而无需访问可运行的对象代码、低级需求或高级需求。
一些实施例以特定次序将运行验证和确认策略的一系列模块应用到需求。该系列的模块可在最早可能的时间点发现错误(例如同时写入需求)。
在一个或多个实施例中，可排序模块的应用，使得在更复杂的分析之前执行较简单的分析。较简单的分析可比复杂的分析更快地被执行，并且可发现更易于校正的显而易见的惊人的错误。
在一个或多个实施例中，可排序模块的应用，使得如果执行分析A可以帮助简化分析B，则分析A可在分析B之前出现。
在一个或多个实施例中，由模块执行的分析可被简化，因为前述的分析已经被执行。
在一些实施例中，模块被应用到不完整的需求(例如，需求未被完整写入)。
在一个或多个实施例中，模块被连续应用到需求，使得可实时提供需求的验证/确认状态的通知。
在一个或多个实施例中，检查公式的可满足性可由完整判定程序(例如模块返回“满意”或“不满意”)或部分判定程序(例如模块可为不完整返回“？”)执行。例如，不完整的判定程序可出现，因为基础的逻辑可能是不可判定的，或者问题可能是难处理的(例如，判定程序的计算复杂性大于可用资源(例如时间、空间))。
图1是根据一些实施例的软件开发系统100的示例。系统100可包括系统需求102、规范模型104、基于需求的自动测试案例生成模块106、设计模型108、结构测试案例模块110、源代码模块112和可运行对象代码模块114。如本文所使用，“系统需求”和“需求”将互换使用。
在一些实施例中，获得待分配给软件和硬件的系统需求102的文本版本。从这些需求102中，开发规范模型104。在一个或多个实施例中，可使用语义建模和图形建模技术的组合开发规范模型104。可使用其它合适的规范模型开发技术。在一个或多个实施例中，可经由消费者确认模块116与消费者一起确认规范模型104。在一些实施例中，可使用自动定理证明为关于形式需求分析模块118的正确性和一致性形式分析和验证规范模型104，如将在下面进一步描述的。可使用分析和验证的其它合适的方法。形式需求分析模块118可在软件开发过程中的早期识别需求中的错误，这可显著地降低后期软件开发循环再加工，从而节省时间和金钱。
在规范模型104被消费者确认模型116和形式需求分析模块118批准之后，规范模型104作为到基于模型的设计组的输入而被传递，以创建设计模型108。设计模型108可使用形式设计验证模块120来形式验证，形式设计验证模块120可包括形式需求分析模块118中的相同方法中的一些。
在一些实施例中，规范模型104可被用作到基于需求的自动测试案例生成模块106的输入。测试案例和程序可由测试案例模块106自动生成，并且然后可经由基于模型的验证模块122而被应用到设计模型108，并且为了正确的功能性而被分析。采用测试案例模块106生成的测试案例可被应用到设计模型108，并且采用结构覆盖分析模块124为结构覆盖来分析。基于需求的自动测试案例生成模块106可包括形式需求分析模块118中的方法中的一些。
源代码模块112可从设计模型108创建源代码。例如，源代码可采用使用静态分析方法的形式代码验证模块126来形式分析。可使用其它合适的分析。可运行对象代码模块114可编译源代码。基于测试的可运行目标代码验证模块128然后可重新使用在测试案例模块106中开发的测试案例来验证可运行目标代码。
转向图2-6，在根据一些实施例的一个示例操作中，图2A和2B是过程200的流程图。本文所述的过程200和其它过程可使用硬件(例如一个或多个电路)、软件或手动部件的任何合适的组合来执行。在一个或多个实施例中，系统100被调节以执行过程200，使得系统100是配置成执行不可由通用计算机或设备执行的操作的专用元件。体现这些过程的软件可由包括固定盘、软盘、CD、DVD、闪存驱动或磁带的任何非暂时性有形媒介存储。下面将相对于系统100的元件描述这些过程的示例，但是实施例不限于此。
如上所述，实施例应用以特定次序运行策略的一系列模块。例如，如下进一步所述，过程200包括经由一系列模块、以特定次序运行对需求的验证和确认策略。在一个或多个实施例中提供的次序是有利的，因为在更多复杂分析之前执行更简单的分析。更简单的分析可比复杂分析更快地被执行，并且可发现可能较早被校正的显而易见的惊人的错误。
当将在下面更详细地描述过程200和相关联的模块时，过程200最初在类型安全模块302(图3)处接收需求。在一个或多个实施例中，通信设备720(图7)与用户通信，以获得与规范模型104或其它模型相关联的一个或多个需求。类型安全模块302在S210中确定需求是否是类型安全的。如果需求不是类型安全的，过程200继续进行到S212，并且错误消息由类型安全模块302生成，并且错误解释305a可经由错误定位模块303a生成并被显示。错误解释模块303a可包括反例。虽然在图3中示出错误定位模块303a-k，使得每个模块包括个别/模块专用的错误定位模块303a-k，但是在其它实施例中，单个错误定位模块可由所有的模块共享。在一个或多个实施例中，每个错误定位模块可包括用于由分析模块执行的分析的特定的方法。然后在S214中编辑和修订需求以解决类型安全错误。在一个或多个实施例中，可通过软件工程师或者能够解决错误的任何其它合适的元件在该步骤中或者遍及规范编辑和修订需求。在更新(例如编辑/修订)需求之后，过程200返回到S210，并且类型安全模块302接收更新的需求。过程200是迭代的，直到类型安全模块302确定需求是类型安全的。
如果在S210中，类型安全模块302确定需求是类型安全的，过程200继续到S216，并且在偶然模块304(图3)处接收需求。偶然模块304在S216确定需求是否是偶然的(例如，既可满足又可伪造的需求)。如果需求不是偶然的，过程200继续进行到S211，并且错误消息由偶然模块304生成，并且错误解释305b可由错误定位模块303b生成并且被显示。错误解释可包括反例。然后在S214中编辑和修订需求以解决偶然错误。在更新(编辑/修订)需求之后，过程200返回到S210，并且类型安全模块302接收更新的需求。类型安全模块302以及然后偶然模块304被应用到更新的需求，如上所述。过程200是迭代的，直到偶然模块304确定需求是偶然的。
如果在S216中偶然模块304确定需求是偶然的，过程200继续到S218，并且在全局偶然模块306(图3)处接收需求。全局偶然模块306在S218中确定需求是否是全局偶然的(即所有需求的联合是偶然的)。如果需求不是全局偶然的，过程200继续进行到S213，并且错误消息由识别不是全局偶然的最小组需求的全局偶然模块306生成，并且错误解释305c由错误定位模块303c生成并且被显示。错误解释305c可包括反例。然后在S214中编辑和修订需求以解决全局偶然错误。在更新(例如编辑/修订)需求之后，过程200返回到S210，并且类型安全模块302接收变化的需求。类型安全模块302、然后偶然模块304以及然后全局偶然模块306被应用到更新的需求，如上所述。过程200是迭代的，直到全局偶然模块306确定需求是全局偶然的。
如果在S218中全局偶然模块306确定需求是全局偶然的，过程200继续到S220，并且在独立模块308(图3)处接收需求。独立模块308在S220中确定需求是否是独立的(例如，每个需求独立于(未暗示)其它需求)。如果需求不是独立的，过程200继续进行到S215，并且错误消息由独立模块308生成，并且通过错误定位模块303d生成错误解释305d，由此不独立的需求连同它依赖的需求的最小组被识别并被显示。然后在S214中编辑和修订需求以解决独立错误。在更新(例如编辑/修订)需求之后，过程200返回到S210，并且类型安全模块302接收变化的需求。类型安全模块302、然后偶然模块304、然后全局偶然模块306以及然后独立模块308被应用到更新的需求，如上所述。过程200是迭代的，直到独立模块308确定需求是独立的。
如果独立模块308在S220中确定需求是独立的，过程200继续到S222，并且在自冲突模块310(图3)处接收需求。自冲突模块310确定每个需求是否是自冲突的(即，是否存在对其不能满足需求的监测的变量的一些输入值，无论给予受控变量什么值)。如果需求是自冲突的，过程200继续进行到S217，并且错误消息由自冲突模块310生成，并且错误解释305e由错误定位模块303e生成并被显示。错误解释305e可包括反例。然后在S214中编辑和修订需求以解决自冲突的错误。在更新(例如编辑/修订)需求之后，过程200返回到S210，并且类型安全模块302接收变化的需求。类型安全模块302、然后偶然模块304、然后全局偶然模块306、然后独立模块308并且然后自冲突模块310被应用到更新的需求，如上所述。过程200是迭代的，直到自冲突模块310确定需求不是自冲突的。
如果自冲突模块310在S222中确定需求不是自冲突的，过程200继续到S224，并且在组冲突模块312(图3)处接收需求。组冲突模块312确定该组需求是否是冲突的(即，存在对其不能满足该组需求的监测的变量的一些输入值，无论给予受控变量什么值)。如果需求是组冲突的，过程200继续进行到S219，并且错误消息由组冲突模块312生成，并且最小组的冲突需求被识别，并且可包括反例的错误解释305f由错误定位模块303f生成并被显示。然后在S214中编辑和修订需求以解决组冲突的错误。在更新(例如编辑/修订)需求之后，过程200返回到S210，并且类型安全模块302接收更新的需求。类型安全模块302、然后偶然模块304、然后全局偶然模块306、然后独立模块308、然后自冲突模块310并且然后组冲突模块312被应用到更新的需求，如上所述。过程200是迭代的，直到组冲突模块312确定需求不是组冲突的。
如果组冲突模块312确定需求不是组冲突的，过程200继续到S226，并且在完整模块314(图3)处接收需求。完整模块314确定该组需求是否是完整的(为监测的变量给出具体值，如果需求唯一地指定每个给定的受控变量的值，一组需求相对于一组受控变量是完整的)。如果该组需求不是完整的，过程200继续进行到S221，并且错误消息由完整模块314生成，并且包括最小组的控制器变量和需求的错误解释305g被识别，连同包括用于受控变量的两个可能值的反例由错误定位模块303g生成并被显示。然后在S214中编辑和修订需求以解决不完整的组错误。在更新(例如编辑/修订)需求之后，过程200返回到S210，并且类型安全模块302接收更新的需求。类型安全模块302、然后偶然模块304、然后全局偶然模块306、然后独立模块308、然后自冲突模块310、然后组冲突模块312并且然后完整模块314被应用到更新的需求，如上所述。过程200是迭代的，直到完整模块314确定需求是完整的。
如果完整模块314确定需求是完整的，过程200继续到S228，并且在有条件地完整模块316(图3)处接收需求。有条件地完整模块316确定该组需求是否是有条件地完整的(如果需求在条件成立的假设下是完整的，一组需求相对于一组受控变量和条件是有条件地完整的，其中该条件是其自由变量为需求中出现的监测的变量的子集的公式)。如果该组需求不是有条件地完整的，过程200继续进行到S223，并且错误消息由有条件地完整模块316生成，并且包括控制器变量和需求的最小组的识别的错误解释303h连同包括用于受控变量的两个可能值的反例由错误定位模块303h生成并被显示。然后在S214中编辑和修订需求以解决有条件地不完整的组错误。在更新(例如编辑/修订)需求之后，过程200返回到S210，并且类型安全模块302接收更新的需求。类型安全模块302、然后偶然模块304、然后全局偶然模块306、然后独立模块308、然后自冲突模块310、然后组冲突模块312、然后完整模块314并且然后有条件地完整模块316被应用到更新的需求，如上所述。过程200是迭代的，直到有条件地完整模块316确定需求是有条件地完整的。
如果有条件地完整模块316确定需求是有条件地完整的，过程200继续到S230，并且在满射模块318(图3)处接收需求。满射模块318确定需求是否是满射的(如果对于c类型的每个值v，存在为其给c分配v的某系统状态，受控变量c相对于一组需求R是满射的)。如果该组需求不是满射的，过程200继续进行到S225，并且错误消息由满射模块318生成，并且包括反例的错误解释305由错误定位模块303i生成并被显示，错误定位模块303i识别用于受控变量的值，使得无论我们在什么系统状态中出发，决不向受控变量分配该值。然后在S214中编辑和修订需求以解决满射的错误。在更新(例如编辑/修订)需求之后，过程200返回到S210，并且类型安全模块302接收更新的需求。类型安全模块302、然后偶然模块304、然后全局偶然模块306、然后独立模块308、然后自冲突模块310、然后组冲突模块312、然后完整模块314、然后有条件地完整模块316、然后满射模块318被应用到更新的需求，如上所述。过程200是迭代的，直到满射模块318确定需求是满射的。
如果满射模块318确定需求是满射的，过程继续到S232，并且在受限或部分满射模块320(图3)处接收需求。部分满射模块320确定需求是否是部分满射的(如果对于每个值v∈V，存在为其给c分配v的某系统状态，受控变量c相对于一组需求R和一组值V是部分满射的)。如果该组需求不是部分满射的，过程200继续进行到S227，并且错误消息由部分满射模块320生成，并且包括反例的错误解释305j由错误定位模块303j生成并被显示，错误定位模块303j识别用于受控变量的V中的值，使得无论我们在什么系统状态中出发，决不向受控变量分配该值。然后在S214中编辑和修订需求以解决部分满射的错误。在更新(例如编辑/修订)需求之后，过程200返回到S210，并且类型安全模块302接收更新的需求。类型安全模块302、然后偶然模块304、然后全局偶然模块306、然后独立模块308、然后自冲突模块310、然后组冲突模块312、然后完整模块314、然后有条件地完整模块316、然后满射模块318并且然后部分满射模块320被应用到更新的需求，如上所述。过程200是迭代的，直到部分满射模块320确定需求是满射的。
如果部分满射模块320确定需求是部分满射的，过程继续到S234，并且在模式或有条件的满射模块322(图3)处接收需求。有条件的满射模块322确定需求是否是有条件地满射的(例如，如果在假设成立的假设下，对于每个值v∈V，存在为其给c分配v的某系统状态，受控变量c相对于一组需求R和一组值V以及条件是有条件地满射的)。如果该组需求不是有条件的满射的，过程200继续进行到S229，并且错误消息由有条件的满射模块322生成，并且包括反例的错误解释305k由错误定位模块303k生成并被显示，错误定位模块303k识别用于受控变量的V中的值，使得无论我们在什么系统状态中出发，如果系统状态满足决不向受控变量分配该值。然后在S214中编辑和修订需求以解决有条件的满射的错误。在更新(例如编辑/修订)需求之后，过程200返回到S210，并且类型安全模块302接收更新的需求。类型安全模块302、然后偶然模块304、然后全局偶然模块306、然后独立模块308、然后自冲突模块310、然后组冲突模块312、然后完整模块314、然后有条件地完整模块316、然后满射模块318、然后部分满射模块320以及然后有条件的满射模块322被应用到更新的需求，如上所述。过程200是迭代的，直到有条件的满射模块322确定需求是满射的。
如果有条件的满射模块322确定需求是有条件地满射的，过程200继续进行到S236。并且需求已经成功地穿过所有模块时，消息在用户界面显示，指示需求被验证和确认。在包括需求的规范模型104由需求分析模块118验证和确认供在软件设计中使用之后，，规范模型104可作为到基于模型的设计组被传递，以创建设计模型108。
转向图3，提供包括在需求分析模块118中的模块的更详细的描述。
与S210相关联的类型安全模块302可分析需求以确定用于形式化需求的所有表达被良好地分类(class)，如由语义分类规则所指定。该分析可捕捉错误，诸如向双精度型分配单个浮动、将以mph(海里/小时)为单位的变量分配到kph(km/小时)中的变量等。在一个或多个实施例中，在由类型安全模块302识别类型安全错误之后，错误定位模块303a可通过高亮需求中的类型违反而隔离错误，并且可提供包括反例的错误解释305a。由类型安全模块302执行的类型安全分析可取决于用于表示需求的框架或形式化的类型。
在一个或多个实施例中，需求可包括变量和组件及模块，并且类型安全分析可在用类型信息编码的变量、组件或模块上被执行。在一个或多个实施例中，类型信息可能是语义的。例如，如果变量x和y存储整数，但是x旨在保持单位α的值，而y旨在保持单位β的值，则x和y应当是不同类型。具有不同的类型可便于在类型安全分析期间发现错误，诸如添加x和y。另外，x和y的类型可能是仅仅包括那个类型的可行值的范围(例如，如果x意为表示可能同时位于车辆上的乘客的数量，则x的类型应当是高达车辆的最大容量的非负整数的组)。值得注意，通过以这种方式指定类型，发现难以以其它方式发现的需求中的错误也许是可能的。在一个或多个实施例中，各种变量的类型可被陈述为需求的部分。
在定义语义类型之后，在那些类型的函数可被定义为需求的部分。在一个或多个实施例中，这些函数可使用需求规范形式来定义，需求规范形式可以抽象方式来完成，并且然后经由提炼步骤的序列来提炼，直到开发出实际的实现。在一个或多个实施例中，受控变量(输出变量)可能是监测的变量(输入变量)的函数。在一个或多个实施例中，函数满足莱布尼兹规则：则即f的返回值仅仅取决于f的自变量。值得注意，用函数定义需求可具有优点：函数、组件或模块的所有相关性被清楚地识别，这可便于分析和错误识别。
与S216相关联的偶然模块304可分析每个需求以确定需求本身是否是偶然的。如上所述，如果既是可满足的又是可伪造的，需求是偶然的。在一个或多个实施例中，不是可满足的需求可能不被实现。在一个或多个实施例中，不是可伪造的需求总是真实的(例如，它不放置关于系统行为的任何约束)，并且因此可不向系统添加任何值。在一个或多个实施例中，偶然模块304首先分析需求以确定需求r是否是可满足的。如果r是不可满足的，则r不是偶然的，并且该状态可由偶然模块304报告给用户。在一个或多个实施例中，可在用户界面上显示状态，如下面进一步所述。然后偶然模块304分析需求以确定是否是可满足的，例如r是否是可伪造的。如果r和二者都是可满足的，则r是偶然的，并且该状态可由偶然模块304报告给用户。
在一个或多个实施例中，不是偶然的需求对应于错误。在一个或多个实施例中，错误定位模块303b可识别并且报告哪个测试(可满足的，可伪造的)故障。在一个或多个实施例中，如果不可以确定偶然测试之一的结果，错误可由错误定位模块303b报告给用户，并且可包括哪个测试具有不确定的结果。
与S218相关联的全局偶然模块306可分析所有需求以确定所有需求的联合是否是偶然的。注意：因为已经经由偶然模块304个别地检查每一个的需求中的偶然，所以可以简化全局偶然分析。如上所述，如果需求的联合是偶然的(可满足的并且可伪造的)，一组需求是偶然的。在一个或多个实施例中，如果该组需求不是可满足的，需求可能不是一致的，并且因此可能不被实现。在一个或多个实施例中，如果该组需求不是可伪造的，该组可不放置关于系统行为的任何约束，并且因此可能不是必要的。如本文所使用，R是该组所有需求，并且符号表示该组R中需求的联合。假定：偶然模块304已经被个别地应用到每个需求，使得当在全局偶然模块306处接收时，每个需求是偶然的，它是从是可伪造的建议推理中得到的。因此，在一个或多个实施例中，可避免的可伪造性的检查以节省成本，并且检查的偶然，在一个或多个实施例中，全局偶然模块306仅仅可检查是可满足的。
在一个或多个实施例中，可能存在至少两个实例，其中可不确定R的偶然。在第一实例中，R的可满足性可能是未知的，并且该状态可由全局偶然模块306报告给用户。在一个或多个实施例中，如果可满足性状态是未知的，用户可执行下列中的至少一个：增加可满足性测试的超时，如果它是问题的话；将分析约束到需求的子集，使用用于减少检查R的可满足性的复杂性的任何其它合适的标准方法。
在第二实例中，如果R是不可满足的，错误定位模块303c则可识别不可满足的需求核。在一个或多个实施例中，不可满足的需求核可能是需求的子集，S，其满足两个属性：1.S中需求的联合是不可满足的，以及2.S的每个合适的子集是可满足的。
在一个或多个实施例中，为了确定不可满足的需求核，错误定位模块303c可最初将S设置成所有需求的列表，并且然后核C可被初始化成空列表。然后错误定位模块303c可检查s的元素。在每个检查期间，错误定位模块303c可确定S(除第一个之外的所有元素)的REST与C的联合是否不是不可满足的。如果是这样，则S的FIRST元素被添加到C。在一个或多个实施例中，如果错误定位模块303返回可满足的值，则FIRST是不可满足的核的部分。然而，如果错误定位模块303c不能确定可满足性，则FIRST可能是或可能不是不可满足的核的部分。在这些实例中，FIRST(S)还可被添加到C。如果错误定位模块303c返回不可满足，则可从S移除FIRST(S)，并且过程继续每个需求以确定不可满足的需求核。
在一个或多个实施例中，不可满足的需求核可能小于该组所有需求(例如，可能存在数千个需求，但是不可满足的需求核可仅仅包括少数需求)。
在一个或多个实施例中，确定不可满足的需求核可使用线性数量的可满足性查询。在一个或多个实施例中，确定不可满足的需求核的调用可仅仅包括有助于不可满足的核的需求。
与S220相关联的独立分析模块308可分析需求以确定一组需求是独立的。如上所述，如果没有由其它需求暗示，需求r独立于一组需求R。如果需求由该组需求暗示，则需求依赖于R。在一个或多个实施例中，如果需求是依赖的，需求可能是错误的，并且需要被解决，或者需求可能是冗余的。在一个或多个实施例中，如果独立分析模块308确定需求是冗余的，错误定位模块303d可生成依赖的核(例如，不是独立的最小组的需求)，并且可将依赖的核报告给用户。在一个或多个实施例中，用户可修订或删除需求以移除冗余，好像冗余被留在规范中，它可通向冗余的工作下游，包括冗余的验证和确认工作。在一个或多个实施例中，独立分析模块308可分析存在冗余的原因，以确定是否存在系统的处理问题。
在一个或多个实施例中，存在两个实例，其中独立分析模块308不可确定需求Ri独立于Ri，其中Ri表示除需求Ri之外的该组所有需求。第一实例可能是：独立分析模块308可能不能够确定独立，并且报告由独立分析模块308为用户生成，指示Ri的独立是未知的。在第二实例中，如果独立分析模块308确定需求不是独立的(即是依赖的)，依赖的核由错误定位模块303d确定，并且报告给用户。在一个或多个实施例中，依赖的核可能是需求的子集，S，其满足下列需求：1.S是所有需求的子集，并且不包含需求Ri，并且2.需求Ri依赖于S，以及3.Ri独立于S的每个合适的子集。
在一个或多个实施例中，错误定位模块303d可确定依赖的需求核。在一些实施例中，依赖的需求核可显著地小于该组所有需求(例如，可能存在数千个需求，但是依赖的核可包括少数(例如，小于或等于一打)个需求)。依赖的需求核的确定可向用户指示独立故障的原因以及如何校正它。对于该确定，S最初可能是除了需求Ri之外的所有需求的列表，并且r最初是需求Ri。在一个或多个实施例中，错误定位模块303d可仅仅包括在依赖的需求核的确定中有助于独立确定的需求。
与S222相关联的自冲突模块310可分析需求以确定需求是否是自冲突的。如上所述，如果存在用于测视的变量的从其中需求不能被满足的一些输入值，需求是自冲突的，无论给受控变量什么值。在一个或多个实施例中，如果需求是自冲突的，则需求暗示：不允许监测变量的一些值。然而，可能不允许需求约束监测的变量的域，并且因此需求是自冲突的确定导致自冲突模块310向用户生成指示存在自冲突的报告，并且错误定位模块303e识别自冲突的需求。
例如，考虑需求：如果加速模式是打开，则期望速度应当被设置成大于目前速度的值。如果目前速度和期望速度是相同类型，比如说它们是[0..400]范围中的整数，并且如果监测的变量目前速度＝400，则决不给受控变量期望速度分配值，使得需求被满足。在该示例中，可行的变量值的表征允许冲突的确定(例如，如果变量的类型刚已经被指定成整数，则需求将不是自冲突的，因为不存在最大整数)。
在一个或多个实施例中，其中标准逻辑符号是：
●求反符号(非)
●逻辑和符号(或)
●∧：逻辑乘符号(与)
●推断符号(暗示)
●≡：双推断符号(当且仅当)
●＝：相等符号(等于)
●通用量化符号(对于所有)
●存在量化符号(存在有)
<Qx1......xn：r：b>表示量化的表达，其中：
1.量词Q是或者是
2.x1......xn是界限变量；
3.r是范围(如果省略为真)；以及
4.b是主体。
等于并且等于
在一个或多个实施例中，自冲突分析模块310可将自冲突检查形式化为：
其中r是正在分析的需求，m1，...mn是需求的监测的变量，T1，...Tn是监测的变量的类型，c1，...ck是需求的受控变量，而Z1，...Zk是受控变量的类型。公式1陈述：对监测的变量的任何可行值的分配(回想监测的变量的类型对应于它们的可行值)，存在对受控变量至少一个可行值的分配，使得需求r成立。
在一个或多个实施例中，为了确定公式1是否有效，自冲突分析模块310确定需求是否满足下列(等式取反)：
如果需求满足公式2，则存在对监测的变量m1，...mn的分配，监测的变量可提供展现自冲突的具体系统状态。如果需求不满足公式2，则公式1是无效的(例如，需求r不是自冲突的)。
在一个或多个实施例中，为了确定需求是否自冲突，自冲突模块310可向需求应用决策程序。自冲突模块310可首先确定需求是否包含任何量词或者函数符号。如果需求不包含任何量词或者函数符号，则判定程序可用于确定需求是否自冲突。在一个或多个实施例中，例如，如上所述，公式1通过提取出现在r中的监测的和受控变量(例如，分别是m1，...mn和c1，...，ck，以及它们的类型T1，...，Tn和Z1，...Zk，)来构建，并且然后运行决策程序，并且返回结果，这取决于是否每个运行公式的需求自冲突。
在一个或多个实施例中，为了确定需求是否自冲突，自冲突模块310可首先确定与每个受控变量相关联的有限类型。在一些实施例中，自冲突模块310可选择包括所有受控变量的一组变量，并且为每个选择的类型Z的变量z关联有限组V，使得在一个或多个实施例中，自冲突模块310可以以几种方式之一确定关联。例如：
1.如果|Z|＜ω，则V＝Z(其中ω表示该组自然数的基数，即它是第一无限序数)。
2.对于每个类型Z，通过选择使用随机过程的S的元素来确定指定大小的有限子类型的关联。
3.如果类型Z是从l到h范围的一组数字，通过将范围划分成n-1个大小相等的片段，并且然后在片段的边界处选择数量，可定义大小n＞1的有限子类型。例如，数量可被选为：
4.对于每个类型Z，基于历史信息执行分析以确定有限的子集，例如通过考虑对其在过去中测试发现错误的值。
5.对于每个类型，基于主题专门技术，构建有限组的值。
6.对于每个类型，执行等效分类分析以将类型分割成等效分类，并且然后从每个等效分类中选择一定数量的代表。在一个或多个实施例中，等效分类分析可包括健壮性分析、正常案例分析和任何其它合适的分析之一。
7.任何有限数量的策略可用于构建子类型V1，V2，...Vk的序列，其然后可以一定方式组合(例如通过采用它们的联合)。
在一个或多个实施例中，以上策略1-7中的每一个可应用于类型或应用于个别的变量。例如，相同类型的两个变量可具有与它们相关联的不同的有限子类型。虽然本文的示例假设仅仅受控变量与有限组相关联，但是在一个或多个实施例中，有限组可与监测的变量相关联。
在自冲突模块310将有限类型与每个受控变量相关联之后，模块310可采用需求r、需求中监测的变量的列表、需求中监测的变量的类型的列表、需求中受控变量的列表、需求中受控变量的类型以及相关联的有限类型作为输入。在一个或多个实施例中，在受控变量和有限类型之间的关联可允许从公式2移除通用量词，产生：
其中符号表示将σ替换到公式的应用，其中替换是从变量到值的映射。
在一个或多个实施例中，满足公式3的分配可能不一定满足公式2。因此，如果需求不是使用公式3的自冲突，推断是不存在使用公式2的冲突；但是如果存在使用公式3的冲突，其可能不一定暗示存在使用公式2的冲突。因此，自冲突模块310确定公式3是否对于需求成立。在一个或多个实施例中，为了确定公式3是否对于需求成立，自冲突模块310向需求应用下面的公式4。在一个或多个实施例中，公式4是公式3，其中所有参数成为明显的。
如本文所使用，矢量符号可表示列表，例如表示m1，...，mn。
在一个或多个实施例中，公式4的应用可导致需求不是自冲突的或者它可能不被确定需求是自冲突的输出。在一个或多个实施例中，该输出被报告给用户。
在一个或多个实施例中，如果自冲突分析模块310经由等式4的应用确定需求是自冲突的，模块310可进一步应用附加的测试以确定需求是否是真正自冲突的。例如，模块310可例示公式1中监测的变量，并且求解该公式。错误定位模块303e然后可返回自冲突的需求。
在一个或多个实施例中，在自冲突模块310确定需求不是自冲突之后，它可创建更佳的类型有限近似，这可增加分析的精度。
与S224相关联的组冲突模块312可分析该组需求以确定它们是否是冲突的。如上所述，如果存在对其不能满足该组需求的监测的变量的一些输入值，一组需求是冲突的，无论给予受控变量什么值。在一个或多个实施例中，如果该组需求是冲突的，则该组需求可暗示不允许监测的变量的一些值。然而，可能不允许需求约束监测的变量的域，使得如果组冲突模块312确定一组需求冲突，为用户生成指示冲突的报告。两个冲突的需求的示例是：
如果外部温度小于或等于低温度(TemperatureLow)，则温度告警应当被设置成打开。
如果温度告警模式是关闭，则温度告警应当被设置成关闭。
在其中外部温度小于低温度并且温度告警模式是关闭的情况下，则第一需求暗示温度告警应当被设置成打开，但是第二需求暗示它应当被设置成关闭。这是冲突。虽然在该示例中两个需求参与组冲突，但是冲突可取决于需求的任何数量。
在一个或多个实施例中，组冲突模块312可将公式1应用到需求，用需求R的联合替换单个需求r。
在一个或多个实施例中，如果组冲突模块312确定一组需求包括冲突，错误定位模块303可通过提取冲突核而识别冲突中涉及的那些需求。在一个或多个实施例中，给定需求S的列表、分配到展示冲突(a1，...，an)的监测的变量、受控变量(c1，...，ck)的列表和受控变量(Z1，...，ZK)的类型的列表，错误定位模块303可提取冲突核。给定S、一组冲突需求、冲突核，假定S′可满足所有下列属性：
1.
2.S′包含冲突
3.没有合适的S′的子集包含冲突
在一个或多个实施例中，通过首先将冲突核C定义成空列表并且将P定义成通过向S中所有需求应用分配所获得需求的列表，错误定位模块303f可开始冲突核确定。错误定位模块303f然后可通过P中的需求迭代，并且如果对于冲突需要特定的需求，它可被添加到C。在一个或多个实施例中，对于冲突是否需要需求可通过公式1的应用确定。
值得注意，如果一组需求不包含冲突，它还不包含自冲突。然而，如在本发明的实施例中，首先执行需求上的自冲突分析，提供几个优点。一个优点是：自冲突分析可随着每个需求被定义而被执行，而无需等待所有需求就绪，允许更早发现错误。另一个优点是：因为自冲突仅仅需要理解一个需求，自冲突可比一组冲突更易于理解和解决，而一组冲突可涉及任何数量的需求。另一个优点是：自冲突分析可能更简单，更不复杂，并且因此比一组冲突分析更健壮。
值得注意，同时检查许多(例如复杂系统可包括超过十万个需求)需求可能难以缩放。在一个或多个实施例中，例如可通过组冲突检查模块312分割冲突分析(类似于系统设计期间使用分割以将系统分解成组件)使得组冲突检查更加可缩放。分割可允许在隔离中检查每个组件，并且然后检查指定组件如何交互的界面需求。在一个或多个实施例中，还可通过组冲突模块312检查可共享可彼此冲突的受控变量的需求对之间的冲突使得组冲突检查更加可缩放，因为许多冲突涉及少量的需求。在其它实施例中，检查与组冲突模块312的冲突可被扩展到其基数小于一些小整数的需求组。在一些实施例中，还可通过组冲突模块312在每个变量基础上执行冲突分析(“基于变量的冲突分析”)使得组冲突检查更加可缩放。在基于变量的冲突分析中，组冲突模块312可选择可以约束值的所有需求，特定的变量可以采用该值并且仅仅为冲突分析这些需求。由于单个需求可以潜在地包含不止一个变量，需求现在可涉及几个冲突分析，但是每个冲突分析将趋向于包含比需求总量少得多的需求，使得分析更加可缩放。
在一个或多个实施例中，为了使得组冲突分析更加可缩放，组冲突模块312可始于一组需求R，并且确定受控变量连接的组件。在一个或多个实施例中，连接的组件可通过始于一组需求R来确定，然后创建无向的图表G，其节点是R的元素，并且其中如果它们具有至少一个共同的受控变量，两个需求之间存在边缘。然后对于H的每个组件C(其中H是该组所有连接的组件，并且如上所述，C是一组节点，即一组需求)，可执行任何前述冲突分析以分析C，以确定冲突。如果发现冲突，可提取冲突核(由于C的严格的子集可负责冲突)。注意，在H中的组件上执行分析，不是在变量上，因为连接的组件确定将变量分割成等效分类，并且因此在相同分类中的两个变量可具有与它们相关联的相同组的需求。因此，通过变量分析可导致冗余确定。
与S226相关联的完整模块314可确定一组需求是否相对于一组受控该变量是完整的，如果需求唯一地指定每个给定的受控变量的值，给定用于监测的变量的具体值的话。在一个或多个实施例中，对于功能需求可需要完整。如本文所使用，“唯一”意为对于给监测的变量的每个可行分配，允许给受控变量的至少一个值分配，并且允许给受控该变量的只是一个分配。通过在自冲突模块312之后向需求应用完整模块314，已经为监测的变量的每个值建立它，存在给满足需求的所有受控变量的至少一个值分配。完整模块314然后确定：对于感兴趣的受控变量，允许只是一个分配。在一个或多个实施例中，具有需求应当完整地描述它们的行为的性质的受控变量可被称为“功能完整”。在一个或多个实施例中，完整模块314仅仅可被应用到包括被识别为功能完整的变量的需求。
在一个或多个实施例中，为了确定完整，完整模块314可以以那个次序采用该组需求、监测的变量的列表、监测的变量的类型、功能完整的受控变量的列表以及受控变量的类型作为输入。完整模块314可确定该组需求是完整的或可能不能够确定该组需求是否完整，并且可生成为该用户指示完整状态的报告。完整模块314可确定该组需求不是完整的(不完整)。如果该组需求被确定为不完整，完整模块314可将该状态报告给用户，并且错误定位模块303g可确定和报告给用户哪组需求不完整，并且可向监测的变量提供分配，对于监测的变量，存在至功能完整的受控变量的两个不同分配，两个不同分配都满足需求。
在一个或多个实施例中，完整模块314可应用与组冲突模块312类似的策略，以使得组完整的确定更加可缩放。例如，在每个变量的基础上，通过将可以约束特定功能完整的受控变量的值的所有需求收集在一起，完整模块314可执行完整分析，如上所述。约束不止一个功能完整的受控变量的需求可涉及几个完整分析，但是每个个别的完整分析可包含比需求总数少的需求，使得分析更加可缩放。使得完整分析更加可缩放的优点是：完整结果可能理解起来更简单。
与S228相关联的有条件地完整模块316可确定一组需求是否是有条件地完整的。在一个或多个实施例中，如果它们对于一组指定的模式完整(即，如果需求在条件成立的假设下完整，其中条件是其自由变量是出现在需求中的监视的变量的子集的公式)，一组需求相对于一组受控变量和需求的条件是有条件地完整的。在一个或多个实施例中，对于给定的一组需求、一组受控变量和条件，有条件地完整的组分析模块316确定该需求相对于受控变量和条件是否是有条件地完整的。
在一个或多个实施例中，可能存在条件，诸如某些操作模式，例如，其中给予受控变量的值是不相关的(例如，因为受控变量不用在这些模式中)。如果识别这类条件，这些条件中不必要地过度指定这些受控变量的值是常见的设计实践。如果使用这些设计实践，有条件的完整模块316可指示：在适当的条件下需求相对于受控变量是完整的。为了确定该组需求是否是有条件地完整的，有条件的完整模块316可接收该组需求、监测的变量的列表、监测的变量的类型、功能完整的受控变量的列表、受控变量的类型和条件作为输入。有条件的完整模块316然后可确定该组是否是有条件地完整的，有条件的完整是不确定的，还是展现不完整的有条件的不完整和变量，并且将状态(以及不完整的变量，如果存在的话)报告给用户。在一个或多个实施例中，如果确定有条件的不完整，错误定位模块303h可生成报告，该报告包括展现不完整所需的降低的该组需求、展现不完整所需的降低的该组受控变量以及条件。
在一个或多个实施例中，可通过有条件的完整组分析模块316生成一组受控变量连接的组件H使得确定该组需求是否是有条件地完整更加可缩放6。回想：该组所有受控变量可用在生成H中，并且H的每个组件是一组需求。
与S230相关联的满射模块318可确定受控变量c是否是满射的。如本文所使用，受控变量相对于一组需求R是满射的，如果对于以v类型的每个值v，存在为其给v分配v的某系统状态。换句话说，满射意味着：在枚举类型的受控变量的所有输出值是可能的。如果受控变量不是满射的，需求错误存在，或者变量的类型应当被更新。在一个或多个实施例中，给定一组需求和受控变量，满射模块318可确定受控变量相对于需求是否是满射。
在一个或多个实施例中，满射模块318可被应用到所有受控变量，所有受控变量的类型是具有小基数的组，例如布尔值变量。
非满射受控变量的示例如下：变量是速度警报(Speed-Alarm)，并且其类型是枚举类型{绿色，红色}。下面两个需求仅仅是其中速度警报作为受控变量出现的需求。
需求1：当速度大于60kn时，飞行员显示(Pilot-Display)应当将速度警报设置成绿色，以便通知飞行员速度不在危险区域。
需求2：当速度小于340kn时，飞行员显示应当将速度警报设置成绿色，以便通知飞行员速度不在危险区域。
以上两个需求暗示：速度警报总是指示需求是错误的绿色。在这种情况下，看上去需求的作者可能已经意味着写：如果速度在60kn与340kn之间，速度警报应当是绿色，并且否则是红色。即使假设需求如写入的正确，则可以更新速度警报的类型以移除红色。
在一个或多个实施例中，如果满射模块318确定下面的公式是可满足的，则满足公式的分配为受控变量提供Z(受控变量的类型)的元素，该受控变量是满射违反的证明，因为无论最初存在什么系统状态，并且无论将什么值分配给其它受控变量，需求禁止受控变量在任何时候呈现该值。
在一个或多个实施例中，通过计算受控变量连接的组件，模块318可开始，由此允许使用仅仅关于与受控变量c相关的该组需求的以上公式，使得分析更加可缩放。在一个或多个实施例中，如果需求不包含任何量词或函数符号，可使用以上公式。
在一个或多个实施例中，将有限组与受控变量相关联，如上相对于自冲突模块310所述，可便于可缩放性。模块318可计算给定需求的受控变量连接的组件，并且识别该包括受控变量c的组件，然后，对于V中的每个值v，应用下面的公式：
以上公式的输出可指示：受控变量不是满射的，满射不可以被确定，或者变量是满射的，并且该输出可被报告给用户。在一个或多个实施例中，当发现满射违反时，错误定位模块303i可生成分配。
与S232相关联的部分满射模块320确定受控变量c是否是部分满射的。在一个或多个实施例中，如果对于每个值v∈V，存在为其给c分配v的某系统状态，受控变量相对于一组需求R和一组值V是部分满射的。在一个或多个实施例中，对于给定的组需求、受控变量和一组值，部分满射模块320可确定受控变量是否相对于需求和值是满射的。在一些实例中，可能存在其域非常大的受控变量(例如，浮动类型的变量)。需要满射的这些变量可能没意义，但是可能期望检查部分满射，其中感兴趣的域使用分析来确定，诸如健壮性分析、正常案例分析、等效分类分析和任何其它合适的分析。在一个或多个实施例中，部分满射模块320可使用与以上相对于满射模块318所述的相同的分析，替换V，Z的子集而不是Z，对于Z的子集，期望c是满射的。在一个或多个实施例中，如果部分满射是不可确定的，部分满射模块320可向用户报告受控变量是否是部分满射的，或者受控变量是否不是部分满射的。错误定位模块303i可确定和报告考虑违反部分满射的受控变量的值。
与S234相关联的有条件的满射模块322确定受控变量c是否是有条件地满射的。在一个或多个实施例中，如果在条件成立的假设下，受控变量相对于一组需求R、一组值V和条件是有条件地满射的，对于每个值v∈V，存在为其给c分配v的某系统状态。换句话说，有条件的满射模块322可确定受控变量的所有指定的输出值在所有指定模式下是否是可能的(即，该满射在某些模式下成立)。
在一个或多个实施例中，对于给定的一组需求、受控变量、一组值和条件，有条件的满射模块322可确定受控变量相对于需求、值和条件是否是满射的。类似于有条件地完整模块316，可能存在条件，诸如某些操作模式，其中给予受控变量的值是不相关的(例如，因为在这些模式中不使用受控变量)。在一些实施例中，可使用有条件的满射模块322来示出：某些受控变量在适当的条件下是部分满射的。注意：对于受控变量，可能相对于一组需求(部分)满射，但是不相对于相同需求和相同条件有条件地满射。因此，有条件的满射可能是比满射更强的验证和确认元件，因为受控变量在满足条件的状态空间的子集上必须是满射的。有条件的满射可用于检查需求在域上是满射的，在该域上它们的输出是有意义的。
在一个或多个实施例中，有条件的满射模块322可通过应用下列公式开始。如果公式是可满足的，则满足公式的分配为受控变量c提供V的元素，受控变量c是有条件的满射违反的证明，因为无论最初存在什么条件兼容的系统状态，以及无论分配给其它受控变量什么值，需求禁止受控变量在任何时候呈现该值。
基于以上公式的输出，有条件的满射模块322可向用户报告受控变量是否不是有条件地满射的，有条件的满射确定是否是不确定的，或者受控变量是否在V上有条件地满射。
转向图4-6，提供需求分析模块118的应用的示例。图4示出用户界面400，用户界面400显示被形式化成逻辑表达并使用语义建模技术捕捉的一组需求。在本文所示的示例中，需求是关于温度警告指示器。因为需求已经被形式化和捕捉，下一步是用需求分析模块118执行需求分析，以确保需求是精确的和一致的。特别地，本文所示的示例中的下一步是应用组冲突模块312，并且模块发现需求18和32之间的冲突。例如，图5示出用于参考的这两个需求的语义模式500捕捉。在分析需求18和32之后，组冲突模块312确定冲突存在于这些需求之间，并且错误定位模块303提供展现冲突的下列测试案例。
(温度告警模式关闭)，(低温度12)，以及(外部温度2)。
如上所述，如果对于不可以为其满足的该组需求的监测的变量存在某输入值，一组需求是冲突的，无论给予受控变量什么值。在一个或多个实施例中，基本原理用于应用组冲突分析是：当一组需求陈述受控变量必须具有一个值，而另一组需求陈述它必须具有不同的值，冲突存在。
关于需求18和32的问题是：需求18假定：当外部温度小于或等于低温度时，温度告警是打开的，但是需求32假定：当温度告警模式是关闭的时，温度告警是关闭的。没有什么阻止两个前提同时为真，如由错误定位模块303生成的反例测试案例所证明。
在一个或多个实施例中，对该冲突的分解可涉及与系统工程师商议或者重新访问分配给软件的系统需求(SRATS)以理解消费者的意图。在本文的示例中，高级需求错过监测的变量，并且还错过区分温度告警模式是打开还是关闭的文本。在规范模型中校正提炼的和免冲突的需求，如图6中的表600中所示，其中提炼被粗体加亮。如上所述，一旦冲突以及来自其它模块的结果被分解，需求可准备好被传递给软件设计师以被实现。
注意，本文所述的实施例可使用任何数量的不同硬件配置来实现。例如，图7图示需求分析处理平台，其例如可与图1的系统100相关联。需求分析处理平台700包括需求分析处理器710诸如以一个芯片处理器形式的一个或多个商业可获得的中央处理单元(CPU)，需求分析处理器710耦合到配置成经由通信网络(图7中未示出)通信的通信设备720。通信设备720例如可用于与一个或多个用户通信。需求分析平台700进一步包括输入设备740(例如，用来输入关于变量、群集和优化的信息的鼠标和/或键盘)和输出设备750(例如用来输出和显示选择的样本)。
需求分析处理器710还与存储器/存储设备730通信。存储设备730可包括任何适当的信息存储设备，包括磁存储设备(例如硬盘驱动)、光存储设备、移动电话和/或半导体存储器设备的组合。存储设备730可存储用于控制处理器710的程序712和/或需求分析处理逻辑714。处理器710执行程序712、714的指令，并且从而根据本文所述的任何实施例操作。例如，处理器710可接收需求，并且然后可经由程序712、714的指令应用需求分析模块118。
程序712、714可以以压缩的、未编译和/或加密的格式存储。程序712、714可进一步包括其它编程元件，诸如操作系统、数据库管理系统和/或由处理器710用于与外围设备接口的设备驱动器。
如本文所使用，信息可由下列“接收”或被“发送”给下列，例如：(i)来自另一个设备的平台700；或者(ii)来自另一个软件应用程序、模块或任何其它源的平台700内的软件应用或者模块。
如由本领域技术人员将理解的，本发明的方面可体现为系统、方法或计算机程序产品。相应地，本发明的方面可采用一般都可被称为“电路”、“模块”或“系统”的完全硬件实施例、完全软件实施例(包括固件、驻留软件、微代码等)或组合软件和硬件方面的实施例的形式。此外，本发明的方面可采用计算机程序产品的形式，计算机程序产品体现在具有在其上体现的计算机可读程序代码的一个或多个计算机可读媒介中。
图中的流程图和框图图示了根据本发明的多个实施例的系统、方法和计算机程序产品的可能实现方式的架构、功能性和操作。在这方面，流程图或框图中的每个框可表示包括用于执行一个或多个指定逻辑功能的一个或多个可运行指令的部分代码、模块或片段。还应当注意的是：在一些备选实现中，框中指出的功能可不以图中指出的次序发生。例如，连续示出的两个框实际上可基本上同时被运行，或者框有时以相反次序被运行，这取决于涉及的功能性。还将注意的是：框图和/或流程图图示的每个框以及框图和/或流程图图示中的框的组合可以由执行专用功能或动作的基于专用硬件的系统或者专用硬件和计算机指令的组合来实现。
应当注意的是：本文所述的任何方法可以包括提供系统的附加步骤，该系统包括在计算机可读存储媒介上体现的明显的软件模块；该模块例如可以包括在框图中描绘的和/或本文所述的任何或所有元件；作为示例而非限制，自冲突模块和完整模块。方法步骤然后可以使用系统的在一个或多个硬件处理器710(图7)上运行的明显的软件模块和/或子模块来执行，如上所述。此外，计算机程序产品可以包括具有代码的计算机可读存储媒介，该代码适于被实现以执行本文所述的一个或多个方法步骤，包括为系统提供明显的软件模块。
该书面描述使用包括最佳模式的示例来公开本发明，并且还使本领域内技术人员能够实施本发明，其包括制作和使用任何设备或系统并且执行任何包含的方法。本发明的可取得专利范围由权利要求定义，并且可包括本领域内技术人员想到的其他示例。这类其他示例如果它们具有不与权利要求的书面语言不同的结构元素，或者如果它们包括与权利要求的书面语言无实质区别的结构元素则意图处于权利要求的范围内。来自所述各种实施例的方面以及用于每个这类方面的其它已知等效物可以由本领域技术人员混合和匹配，以根据本申请的原理构建附加的实施例和技术。
本领域技术人员将理解：可以配置上述实施例的各种调整和修改而不脱离权利要求的范围和精神。因此，将理解可实践除了如本文所具体所述的之外的权利要求。
- 还没有人留言评论。精彩留言会获得点赞！