Uml 传统的基于代码的工程和模型驱动的工程方法之间有什么区别？

我在文献中找到了这一段，但我不明白它的意思

设计实践正在从传统的基于代码的工程转向， 在整个开发生命周期内进行强有力的分工，以 模型驱动的工程方法，所有参与设计的人员 flow可以在模型上发表自己的看法

---

任何帮助都将不胜感激

我不确定我是否同意这个句子的写作方式，但我可能会遗漏一些上下文，而且无论如何，这不是问题的要点

传统上，计算机时间是昂贵的，所以设计通常发生在纸上——有时是成堆的纸。设计师会写下要求。在设计阶段，他们使用塑料“RapiDesign”模板（我还有我的…）在纸上绘制了一些图表，以描述程序和数据流图、梯形图（逻辑）图、信号图等。完成后，使用各种技术（如“结构化英语”）来定义程序的运行方式。然后，程序员将获取这些信息并实际编写可以在计算机上运行的代码（汇编程序、COBOL、FORTAN、C）

进化的下一步是构建软件工具来更好地处理一些工作。建模工具诞生了，许多工具以不同的方式显示信息。这些早期的建模工具被美化为绘图程序，很少建立语义来支持模型。他们基本上足够好，可以自动化这个过程，使修改图纸变得更容易。RationalRose（基于Booch符号）和Popkin System Architect的早期版本就是此类工具的例子

随着这些工具增加了更多的功能和相关的方法，它们也增加了一些语义（有时隐含在方法中）。这使得这些工具可以开始生成一些代码。由于这些工具主要对面向对象的方法感兴趣，因此生成的代码主要是类定义。由于缺乏行为语义，无法创建实际运行的代码

同时，UML（统一建模语言）的出现是为了帮助连接各种语言，从Booch、OMT和Objectory开始。随着UML的发展，其元模型变得更复杂、更严格，并添加了更多的行为语义。最近，还定义了一个抽象语言框架（ALF），以认识到程序需要执行的操作不能总是使用图形化UML符号表示

注意，其他方法也与UML并行出现。实现模型驱动工程方法的一些值得注意的方法是ROOM和SDL，它们都是特定于领域的，都为UML的发展提供了能力（例如，ROOM:结构化类，SDL:消息序列图）

这就是我们现在所处的情况，在模型驱动的工程世界中，在设计过程中使用具有定义语义的形式化模型，而不是在纸上和黑板上绘制，来驱动所使用的代码

在一些具有支持工具的特定领域中，您甚至可以看到从模型生成和部署完整应用程序的情况—模型正在成为代码

---

整个建模历史也是运行软件一代发展的延续，其中抽象级别不断从可编程门阵列上升到二进制、汇编、2GL（如C）、3GL（如C++），现在又是模型。

基于代码的工程意味着大部分工作是在编码和代码中完成的。这不是一个广泛使用的术语。它不是一种项目管理方法，相反，它似乎是对一些糟糕的PM实践的负面描述，当开发人员在获得任务后几乎立即开始编写代码时。这个方法以前用过，唉，现在也用了

基于代码的编程之所以长寿，是因为在它的最佳变体中，它非常适用于短项目——最多1k行。我们可以将描述/模型直接写入注释中，使用

结构化英语

（我习惯于命名

伪代码

）将它们重写一两次，然后转到相同的文件中。它确实适用于较小的项目，人们从较小的项目开始，通常作为学生习惯于这种方法，并在遇到困难时转向其他开发人员。但他们必须这样做，因为这种方法不适用于更大的项目

模型驱动工程（Model driven engineering）是指定期将创建的产品与它的模型进行比较。模型也发生了变化，是团队需要达到的一个不断移动的目标。这个术语出现在敏捷编程中，因此，它是相对现代的

它反对测试驱动和需求驱动的工程，而不是基于代码的工程。使基于代码和模型驱动的项目成为可能。但我不建议这样做。

历史 基于代码的工程对我来说意味着程序员在头脑中创建一些模型并编写相应的代码。当需求发生变化时，程序员会改变脑海中的模型并重写代码。这样的程序员也称为程序员分析员。（s） 他从模糊的、通常不成文的需求中创建代码，不需要其他任何东西一人秀

未来 相反，模型驱动工程意味着在编码工作完成之前，需求必须足够清楚，并写下来，并且必须创建目标系统和代码的一些“模型”。使用一些建模标准，如BPMN、UML等。这种建模工作通常由一些非程序员、一些分析人员完成。然后程序员将模型（在它被批准后）具体化为代码