关于建模与编程的一些见解

首先看看形式化的概念：

“形式化”（formal, formalization），其实是个有毒的概念，虽然在相当多的场合，它用起来很方便。用起来方便，是相当多的概念（其中许多看来很“基本”）存在的理由，但是，每当我们的认识要达到某种不寻常的范围或深度时，这些概念就不知不觉地成了某种障碍，误导或遮掩一些东西。

形式化的背景，是精确性，可推理性，逻辑（或有时喜欢说，数学）的严格性、一致性。但从操作性的角度来解析，“形式化”涉及的主要内容实际就是可操作性，加上确定性。循“操作性”的途径，作为一个形容词乃至名词的形式化一词，基本上都可以消解掉。

例如：在很需要形容词的时候，可以用“严格”或“精确性”来替代，它们的好处是更直接地与“度量”（又是操作！）关联得更密切。而“形式化系统”这样的概念，可以直接地称之为“逻辑系统”（我觉得，各种数学的系统，也应归纳于此）。与“形式化”相比，我更喜欢“逻辑”的概念，因为它更具体、明确——有操作性。

本文不是实证的研究，也不是严格的论证，也许可以称之为“直觉”，但证明的过程，每时每刻都在进行着。计算机的每一个应用，对更复杂的问题的解决，都是把形式化变成具体操作的一个具体进步。对于程序员来说，“形式化”，甚至“精确”这样的形容词都是不需要的。另一方面，形容程序或代码是一种形式化的东西，对于他们也没有意义；说编程（包括建模）是将需要处理的问题形式化，也是多余的，我们需要的是具体的规则，告诉/约束我们怎样编程与建模。

所谓“毒性”在哪里呢？在它变得多余的地方，它可能会造成我们对“形式”的迷惑或错误的寄托，甚至有时变成一种迷信，从而忽略了实际的操作性方面。在这种地方，我们很需要奥卡姆的剃刀。当然，方便永远比严谨得到更多的青睐，所以总是会有许多的概念是因为方便而普遍存在的，关键是我们要弄清楚，在什么时候它们可以剔除。

补充一点：
原本写的时候，第一句还加了“尤其是中文这个词”，当时一转念，怕又激发某些类型的口水，就删掉了。事实上，对于我们这里要讨论的这个概念，英文 formal, formalization，“形式化”实在不是个好的对应，例如，“正规化”、“规范化”也比它好一些。

————————————————————————————————————————————————————————————————————————————

系统、体系仿真建模与软件建模

形式化就像我们最初接触计算机时通过伪代码来描述程序一样，现在的算法导论等书籍中仍长期保持着这种“伪”的形式化风格，很多时候他给我们提供了方便，而没有标准的形式化就是毒奶。就像大学生对许多概念的宽泛认识一样。

最近接触了建模语言比较多，类似于HarmonySE和UML、SysML、UPDM等等。之前在本科和研究生的学习过程中接触了不少的建模，主要还是UML和E-R图这种，在软件设计模式中用到了很多，但是就像大多形式化方法一样都是大而简的，即使符合标准，却很难真正标准化。

用了一段时间的Rational Rhapsody建模，发现标准化的模型与代码生成是可以密切相关的，模型可以在自动化的IDE中执行，并在不同视图之间相互自动转化，而他可以帮助你生成代码，并应用到实际的系统工程之中。

DODAF2.0和DODAF1.5就是通过工具建模来实现架构设计的，用来描述作战活动，而非软件设计，通过模型生成的代码，在visual studio的工程应用，模型可以执行，代码在工程中也可以执行并实现作战流程的仿真，将形式化模型与代码工程实现连接。或许这也是未来UML的发展方向，实现真正的标准化。

所以说不管是体系仿真建模还是软件建模，优秀的建模是和代码紧密联系的，甚至是可以执行的。本人对这一块以前了解的比较浅，现在感觉不是那么容易，想搞透还有很长的路要走。