软件工程术语-“不一致”和“不完整”的真正含义是什么[关闭]

不一致性和不完全性都是形式逻辑的原始术语,用来描述逻辑系统。

完整的定义取决于具体的上下文,但是 inconsistency 通常意味着“对于一些x,你可以证明x和!X”和 incompleteness 意思是“对于一些x,你不能证明x,你也不能证明!X”。

因此,对于规范,我理解“不一致”是指“无法实现,因为它在某种程度上是自相矛盾的”,而“不完整”是指“未指定-对于某些输入,输出没有明确定义”。

问题标题表示软件工程,但正文指定软件设计。这两个术语不是等价的。

关于不一致性和不完整性,有许多方面适用于这些问题。举几个例子:

不完整:

• 是什么使代码格式不好或语法不完整,因而不可编译、可解释、可执行
• 实现-算法可能不完整,无法正确处理可能的情况
• 功能性-软件不包括客户机订购或团队计划的所有功能

不一致性

• 惯例和编码风格
• 实现设计——以不一致的方式设计的函数、类和算法的接口(即,矢量排序期望传递矢量,列表排序接受两个迭代器)
• 在交互方面用户界面的设计-在一个对话框上,用户应该点击Enter接受,但在另一个对话框上,此操作显示OK按钮。
• 图形用户界面的外观-不同的窗口有完全不同的外观;或命令行界面-一个选项被指定为-v值,另一个选项被指定为-v值
• 许可-假设Visual Studio产品在BSD上获得许可,但在GPL上获得.NET Framework:-)

在数据库系统中,一致事务是指在执行期间不违反任何完整性约束的事务。如果事务使数据库处于非法状态,将中止该事务并报告错误。

在算法中,完整性的概念是指算法在存在解的情况下找到解的能力,如果不存在,则报告说不可能有解。

在计算复杂性理论中,如果p在c中,那么在给定的约简类型下,对于C类复杂度,问题p是完全的,而C中的每个问题都用约简形式约简为p。例如,对于NP类,NP类完备中的每个问题都是完整的,在多项式时间下,多个一次约简。

在软件测试中,完整性的目标是调用图(软件项之间)和控制图(每个软件项内部)的功能验证。 完备性的概念可以在知识库理论中找到。

你可以继续这样的定义…也许可以让问题不那么含糊?

如果我今天过得不好,我会链接到“哥德尔不完全性定理”,因为它肯定是关于这个主题的;)

在正式系统的上下文中,一致性和完整性(及其各自的否定)的一个含义是:大体上,一个系统是一致的,如果不可能从中产生矛盾。一个系统是完整的,如果有可能生成关于底层模型的所有真相。理想情况是提出一套合理的公理,它能够“捕获”关于某个特定领域的所有事实,并且只捕获这些事实。

它们有很多意思,我就举几个例子:

不一致性:

• 有一个抽象类,由几个类继承,但实现不一致/冲突
• 在几个类似的实现/模型上使用不同的设计模式

Incompleteness:

• 没有整体的异常处理,只实现了明显的异常处理
• 不涵盖用户所需功能/功能的整个范围

名单不断地…

根据上下文,有可能 Formal Methods 是指证明程序正确性的数学技术。在这种情况下,使用数学证明可以确保规范不矛盾(没有逻辑矛盾),或者 incomplete (有规范有效性的正式证明)。

在您提供的示例的上下文中,它们仅仅意味着强制实施一个正式的过程——一个具有端到端文档化方法、方法、可交付结果集、定义的角色和责任的过程,将比针对同一问题的特别方法产生更好的产品。换句话说,描述在整个项目生命周期中持续使用和应用的完整软件工程过程的正式系统将比不提供此支持框架的系统产生更好的结果。

这和盖房子一样。是的,你可以跑出去把木板钉在一起,你也许可以建造一些你可以居住的东西,但是如果你改为学习建筑,建筑材料和技术,定义一个工作流程等,你会得到一个更好的房子。不过,比这更好的是,你可以建造同样的房子,或者类似的房子,成功的概率也要高得多。