Questions tagged «formal-methods»

22
为什么有些程序员认为理论与实践之间存在差异?[关闭]
将软件工程与土木工程进行比较时,我惊讶地发现了另一种思维方式:任何土木工程师都知道,如果您想在花园中建造一个小木屋,则只需获取材料并进行建造,而如果您要建造一栋10层高的房子(或类似这样的房子),您需要做一些数学运算以确保它不会崩溃。 相反,在与一些程序员交谈或阅读博客或论坛时,我经常发现一种广泛的观点,可以或多或少地提出如下观点:理论和形式方法适用于数学家/科学家,而编程则更多地是要把事情做好。 这里通常暗示的是编程是非常实用的东西,即使形式方法,数学,算法理论,简洁/连贯的编程语言等可能是有趣的主题,但如果所有人都想得到东西,通常就不需要它们了。完成。 根据我的经验,我想说的是,虽然您不需要太多理论来编写100行脚本(小屋),但是要开发复杂的应用程序(10层建筑),则需要结构化的设计,定义的方法,良好的编程语言,可在其中查找算法的良好教科书等。 因此,IMO(适量的)理论是完成任务的工具之一。 我的问题是,为什么有些程序员认为理论(形式方法)与实践(完成任务)之间存在差异? 与土木工程(房屋)相比,软件工程(房屋软件)是否被许多人认为 容易? 还是这两个学科真的不同(除了关键任务软件,软件故障比构建故障更容易接受)? 我尝试总结一下,到目前为止,我已经从答案中了解了什么。 与软件工程相反,在土木工程中,对于特定任务需要多少理论量(建模,设计)更加清楚。 部分原因是因为土木工程与人类一样古老,而软件工程仅存在了几十年。 另一个原因是软件是一种更具可变性的人工产品,具有更灵活的要求(可能会崩溃),不同的营销策略(可以牺牲良好的设计以便快速将其投放市场)等。 结果,要确定在软件工程中合适的设计/理论量是非常困难的(太少->凌乱的代码,太多->我永远无法完成),因为没有通用规则,而只有(很多)经验可以提供帮助。 因此,如果我正确地解释了您的答案,那么 对于真正需要多少理论的不确定性会导致一些程序员对理论的爱恨交加。

8
如果您学习了软件的形式化方法,您发现它有多有用?
如果您已经接受过使用形式化方法(FM)进行编程的培训,则: 您发现它有用吗? 您的FM培训涉及什么(例如一门课程,一本书)? 您使用什么调频工具? 与不使用FM相比,它在速度/质量上有什么优势? 您使用FM创建哪种软件? 如果您现在不直接使用FM,至少值得学习吗? 我很想听到在这个社区中可以找到的尽可能多的FM经验/观点。我开始阅读它,并想了解更多。 背景 编程和软件开发/工程是地球上最新的人类技能/专业,因此,该领域并不成熟也就不足为奇了-在我们领域的主要输出中显示出来,因为代码通常很晚且容易出错。平均编码和顶级编码器之间的生产率差异很大(至少10:1)也表明了行业的不成熟。这些令人沮丧的事实已在文献中得到了很好的报道,并被史蒂夫·麦康奈尔(Steve McConnell)的《密码大全》(Code Complete)等书所介绍。 软件/ CS中的主要人物(例如,已故的E. Dijkstra)已提出使用形式化方法(FM)来解决错误的根本原因(其中之一):编程中缺乏数学上的严格性。例如,迪克斯特拉(Dijkstra)提倡学生共同开发程序及其证明。 与美国相比,FM在欧洲的CS课程中似乎更为普遍。但是在过去的几年中,新的“轻量级” FM方法和诸如Alloy之类的工具引起了一些关注。FM仍远不是行业中的常用方法,我希望在此获得一些有关原因的反馈。 更新资料 截至目前(2010年10月14日),在下面的6个答案中,没有人明确提出要在“现实世界”作品中使用FM。我真的很好奇有人是否可以并且愿意。也许FM确实说明了学术界(FM是未来!)和行业(FM几乎没有用)之间的鸿沟。

3
阻碍广泛采用正式方法的障碍是什么?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 2年前关闭。 形式化方法可用于指定,证明和生成应用程序的代码。这不太容易出错-因此通常用于安全/关键程序中。 为什么我们不经常在日常编程或Web应用程序等中使用它? 参考文献: 形式方法 B法 霍尔逻辑

5
是否有任何正式的/数学的软件测试理论?
谷歌搜索“软件测试理论”似乎只是给出了软词义的理论。我没有找到任何可以归类为数学,信息理论或其他科学领域意义上的理论的东西。 我正在寻找的东西可以形式化什么是测试,使用的概念,什么是测试用例,测试某物的可行性,测试某物的实用性,应该测试某物的程度,形式的定义/解释代码覆盖率等 更新:另外,从直觉上讲,我不确定形式验证与我所要求的内容之间是否存在联系,但是显然存在某种联系。

3
重构大型方法以确保我不会破坏任何内容时,会有什么帮助?
我目前正在重构大型代码库的一部分,而没有任何单元测试。我试图以残酷的方式重构代码,即试图猜测代码在做什么,什么更改不会改变它的含义,但是没有成功:它随机破坏了整个代码库的功能。 请注意,重构包括将旧版C#代码移动到更具功能性的样式(旧版代码未使用.NET Framework 3和更高版本的任何功能,包括LINQ),在代码可能会从中受益的地方添加了泛型,等等。 考虑到要花多少钱,我不能使用形式化方法。 另一方面,我认为至少要严格遵循“任何重构的遗留代码都应带有单元测试”的规则,无论它要花多少钱。问题在于,当我重构500 LOC私有方法的一小部分时,添加单元测试似乎是一项艰巨的任务。 什么可以帮助我了解哪些单元测试与给定的代码相关?我猜测对代码进行静态分析会有所帮助,但是我可以使用哪些工具和技术: 确切知道我应该创建什么单元测试, 和/或知道我所做的更改是否以与现在不同的方式影响了原始代码?
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.