形式方法与企业 | 码农家园

Formal Methods and Enterprises

所以…

我教正式的软件工程方法。我还教授"敏捷方法论"。大多数人似乎认为这是矛盾的。我觉得这很有道理…我还为一家公司工作，我们需要实际完成工作：)虽然我可以在日常工作中将我所获得的技能点应用到"规范"上，但我的同事通常会避开"正式"这个词。

我曾经认为这是由于我们学习如何编程的内在方式：我们通常被驱使去寻找一个有效的解决方案，而不是去理解问题。然后我认为这是因为在正式的社区中，大多数人不是工程师，而是数学家或计算机科学家。现在，我想知道是否仅仅是因为形式方法社区隐藏在某种"模糊"法律的背后，使用所有可用的Unicode符号，积极开发粗鲁的、非实用的工具，并在标准面前大笑。

是的，我已经从一个"责备他们"的角度转到了一个"责备我们"的角度；-)

所以，我的问题是：你们公司有没有使用任何形式的方法？你介绍过他们吗，还是他们是先决条件？你使用什么技术来消除人们对数学的恐惧，并鼓励他们使用正式的方法？您认为当前的工具对于更广泛的用途来说缺少什么？

让人们接受任何方法或方法的关键是向他们展示它如何解决他们所面临的问题。如果他们能看到这将使他们的生活变得更好，你就有很大的机会让他们采用这些技术。

如果你不能向他们展示这一点，也许你想采用基于哲学而非实践的方法。除非其他人和你分享你的哲学，否则你什么也得不到。也许你不应该。

几十年来，有很多方法论。新的项目总是解决旧项目的缺点，但是项目仍然会遇到麻烦和失败。为什么？因为提出新方法论的摇滚明星都是摇滚明星，他们之所以提出新方法论，正是因为他们了解潜在问题以及如何应用这些问题。那些追求的人往往盲目地遵循食谱，而且效果不太好。

所以我认为最好的办法是讲授潜在的问题，然后展示各种方法是如何处理这些问题的。公司、项目和团队之间的差异是如此之大，以至于没有一种方法可以成功地应用于所有组合。学会选择合适的工具并将其应用是至关重要的。

感谢你的贡献。他们真的很有趣。请允许我燃烧一个比特(不要拿它作为个人，尽管:-)

大多数人认为，正式的方法只是程序验证。或临界系统。This may be true if we pursue the ultimate cliche：to prove we are doing the program right(V.S.Validation，which asks，a s a contributor said，if we are doing the right program).

但考虑模型发现/检查工具，如合金。学会使用一个工具，就像这样，用一个不适宜的时间给任何人使用UML和OO。但是，它可以让你立即进入你的模型。这通常需要10分钟以上的时间，以便在一个小规模的补贴上找到一个对应的例子，一个小的补贴试图使用(包括在第一个地点描述合金中的模型)。

以要求工程为例。一个通常画一大堆UML。少数人使用OCL、Though、and many business rules are informally annoted in natural language.为什么？时间限制？

现在考虑的事实是，大多数人只是利用她/他的口感来证明一个模特是令人满意的。又来了，为什么？我可以用同样的时间(可能是较少的时间，因为我不需要在乎绘画美学)来写出合金中的模型，只是为了满足？我现在需要什么数学？"说教？范西的名字和布朗斯；-)量化？Fancy names for foreachs()

关于大信息系统他们不需要批评试着在你的头脑中分析一个概念(而不是实现！)超过600个班的图表。我看到很多人轻易地把头颅撞在墙上，造成模型错误，因为他们错过了一些约束，或是模型错误地让事情发生。

事实上，一个人不需要从头部到尾部的正式方法。花岗岩，我可以在公鸡中找到一个完整的应用，并确定它100%符合某些规格。This may be the computer scientist/Mathematican approach.

但是，有一个GTD Philisophy，为什么我不能给电脑指派一些任务，并允许它帮助改善我的发展呢？Why can I delegate some tasks for the computer and allow i t to help improving my development？是"时间"的问题，还是"时间"的问题，简单的技术能力缺陷，并将学习/不学习？

在企业中与业务线IT开发合作意味着必须将有关业务的知识从实际业务人员转移到开发人员的头上。虽然我自己发现抽象数学是最伟大的消遣之一，但它是一个糟糕的沟通工具。沟通就是一切。虽然我可能会成功地说服IT人员接受更抽象的符号，但我基本上没有机会接触业务人员。

虽然在某些领域，我可以看到企业中正式方法的作用(数学和逻辑重的专业软件，对可证明属性的重要需求，如安全关键软件)，但它们在如何通过向一组可能的外部或内部提供者。

我认为陪审团仍在基于模型的方法和特定领域的语言上争论不休。我认为他们会成功或失败，这取决于他们是否能更快地从IT部门反馈到商业方面的愿望和需求，以及他们是否认为商业人士必须进行任何重要的研究。

技术很简单。沟通是困难的。正式的方法可以帮助我们做正确的事情，但我见过的那些方法对帮助我们做正确的事情毫无帮助。(是的，这些都是陈词滥调，但那是因为它们是不可避免的、痛苦的事实。)

在故障成本较低的系统中，形式化方法毫无意义。

在一个生产Web应用程序中，您有多个前端框、多个后端框、多个数据库框——如果其中任何一个框上的程序失败，这是一个非事件。硬件是如此便宜，你可以用远低于正式指定所有软件的成本来构建这些系统。

我试过几次让人们接受正式的规范方法(Z和合金)，并且和你的方法一样有效：大多数人，虽然觉得他们有一个有用的目的，但在实际工作中使用他们是非常不舒服的。

有趣的是，同样的人非常乐意以巨大的数量生成完全无用的UML图。

我认为有两个主要原因：

许多开发人员对正式方法所需的抽象级别感到不舒服。事实上，大多数初级数学教育都是微积分，而非离散数学可能与此有关。

b.)正式的方法需要一个自下而上的设计方案，在这个方案中，您从一开始就设计核心模型，使其不透气，然后通过在其上提供一个接口将其连接到实际的用户需求上。由于我们倾向于让需求驱动开发工作，自顶向下的方法感觉更自然，尽管它常常导致不一致的模型。这就像在你的房子已经建成后，对它下面的地下室进行改造。