建模和编程的本质区别是什么
来自: 黄毅(程序猿) 2011-06-02 15:19:20
看了楼主的博文，发现这是一个我不熟悉的领域，感谢组长让我学到新东西。
关于这个问题没怎么看明白，斗胆提问，还望赐教 ;-)
关于建模，我的疑问是，如果建模语言是确定的，构造性的，那么自然就可以写一个编译器把它转换成可执行代码；
如果建模语言不是确定的，那是什么原因阻止它成为确定的？
非确定的建模语言最后还是得由程序员来把它转换成确定的代码，是什么东西阻止这个转换过程自动化呢？
-
TY (你的因果就是你的世界) 2011-06-02 16:13:40
你很敏锐啊，已经触到了许多关键的地方。由模型产生代码，是国外软件界MDA背景（其实要宽一些，大致统称为模型驱动软件开发或软件工程）目前盯住的基本目标，但其中问题也不少。
总体而言，这涉及建模与传统理解的编程到底有何区别问题。上面提到的国际软件界中这个领域的主流意见，基本还是以OMG的MDA策略中奠定的，主要要点就是“提升抽象层级”，以及所谓“将建模语言当编程语言用”。虽然如此，他们的既定目标却只敢说“部分自动生成代码”，而大部分活跃的实践者努力的方向，则是试图完全自动产生代码，甚至于试图达成往返工程。
所谓“可执行模型”最近随着可执行UML的进展，似乎被重视得更多了。
综合地看，国外这个领域还在探路，所遇到的问题，可能和它们最初的前提（比如上面提到的两个）有关。比如：就象你问题中暗示的，如此模型那么确定，为何计算机不能自动处理呢（注意：我不是用的“转换”，这又涉及到模型与代码的关系与异同问题）。既然模型语言“当作”编程语言用了，那为何OMG专家们不敢假定能完全自动生成代码（或“可执行”）呢？
这些问题，正是目前这个领域并没有解答清楚的。大家可以一起进一步讨论:-) -
-
-
-
-
TY (你的因果就是你的世界) 2011-06-07 14:35:47
Zhang3:
我的理解也许有些不同：模型并不一定是心智的产物；不一定是“语言的”；关于动态性，是建模与模型应用的一个要点，也许还是难点，但却未必是重点。
半缘君：
基本上，现在国外软件工程领域比较流行的观点，就是把模型界定在这个“描述性”上（这是一个极端宽泛的定义，大致上，我很多年前也曾经倾向于类似的想法），然后，把传统的程序（或代码）摆在“执行”的层面上。
其实这里有很多问题（在我看来，和这个领域十多年不尽如意的进展状况有关）。比如：描述性，是否就意味着语言陈述？和图是什么关系？描述性与宣告性/声明性（软件常用术语declare, declarative）有什么区别吗？（因为，任何一个完整的程序，都有declare的部分）。 -
TY (你的因果就是你的世界) 2011-06-07 14:45:31
接我的那篇日志“形式化是一个有毒的概念”里的话题，“描述性”，与“形式化”又有什么关系？这同样涉及到模型的本质问题。比如，软件界的UML，现在开始展“可执行”的版本（就是为达成可执行的模型），同时也很自然：舍弃图形，所以同时变成所谓文本化UML。这个方向，没有解决问题，可能更偏了——偏的结果不会是做不出东西，而是达不成某些效果，稍稍改善编程方式的同时，带来的新问题也不少——比如，维护模型，以及因此而多增加的一个层次，成了新的问题，所以有要人强调模型-代码往返工程，但也有人隐隐地意识到二者本质上可能不能往返——对这一点还没看到谁明确地论述。
-
半缘君 2011-06-07 15:57:53
描述元语言与执行语言的一个例子：
XPDL与BPEL是完全不同且互补的标准，BPEL是一个“执行语言”，旨在提供一个Web服务编排定义，BPEL的定义关注一个进程以Web服务和XML数据集成为主的可执行。而XPDL则是一个与开发者相关实现无关的流程过程描述规范和交换接口，在工作流结构完整性方面XPDL较为成熟，但XPDL未在基于SOA架构下的服务编排方面给定更多标准化的交换格式，大部分BPM厂商均以XPDL扩展语法提供私有的扩展，而此部分正是BPEL所努力的，虽然BPEL已经向其不擅长的人工流程和非Web Service服务编排领域拓展规范，但仍然需要在非集成领域的流程规范方面向XPDL老大哥学习，比如在面向BPM业务分析师视角，目前BPEL2.0尚缺失对过程模拟规范的制定。 -
-
-
-
-
TY (你的因果就是你的世界) 2011-06-08 09:01:02
这个问题，我想引进一个看法：我们所讨论的一切问题，都是自然语言能够“说得清楚”的问题，自然语言是表达能力最强的，所有的数学、逻辑、计算机语言，都是自然语言的子集。
换言之，没有一个问题，是用计算机语言说得清楚，而自然语言说不清楚的，如果那样，一定是我们对自然语言的使用有问题，例如，没有对不同的概念做出准确的区分，等。
既然是“两种执行”，就是两件不同的事，它们相同与不同的具体地方是什么，这就是我的问题。当然，答案不能是，一个是虚拟机，一个是解析器——这就好像说，张三李四不同，因为一个是张三，一个是李四；相同，因为都是人。这个答案基本弱到没有意义了。 -
-
-
-
-
-
半缘君 2011-07-06 10:42:32
使用UML面向对象的业务建模方法，分为业务分析和业务设计两项任务。建立的业务模型包括业务用例模型和业务对象模型。
业务分析的任务是：搞清楚企业将面对哪些类型的外部客户、供应商等相关业务伙伴？这些业务伙伴将需要企业的哪些业务过程的运作？企业的这些业务过程为这些业务伙伴能提供什么服务价值？从伙伴的外部角度看，业务过程应该怎样一步一步通过交互操作完成？业务分析对应的结果模型就是业务用例模型。
业务设计的任务是：设计一组方案来实现业务分析中提出的业务过程。这组方案应包括：需要找到哪些类型的业务对象资源，包括业务人员、业务中应用的设备、生产资料、信息系统等？这些业务对象资源应具备怎样的表象特征和行为特征？这些业务对象间建立了怎样的关联，通过这些关联可以互相发送消息，驱动业务对象做出动作行为，最终满足业务过程的外部需求？业务设计对应的结果模型就是业务对象模型。
业务分析的语言是描述性的，回答“做什么”，而业务设计语言对前者来说就是可执行的“算法”语言，回答“如何做”的语言。
参见表达佳作赏析：http://blog.sina.com.cn/u/2191450162 -
-
-
TY (你的因果就是你的世界) 2012-08-30 20:27:34
欢迎！
国外软件工程中围绕建模技术这个领域（目前主要聚集在MDE，模型驱动工程名下），UML当然是它们捧的“圣杯”。
所谓转换或代码生成（模型-模型，模型-代码）是他们集中探索的热点。基本上我看到他们拿出来秀的东西，大多属于基于UML模型的代码生成一类。较新的，用可执行模型（比如可执行UML）。也有个别用“模型解释”（通过解释器实现模型之所表达）。
转换的一个话题是往复，即可逆向工程。这个怀疑的人比较多，似乎不少人认为不仅没必要，而且有害。
仅仅生成代码框架这种，其实就是帮你打打字——你定义了模型，这些所谓模型是要在代码中一一声明的，框架自动生成至少帮你完成了这个。至于逆向转换，对于正常开发与维护，我也认为，基本没必要，因为在自主的开发过程中出现这个，至少意味着你的开发流程管理是混乱的。既然运用了建模技术，就要建立真正以模型为中心的思想：模型如手足，代码如衣服 :-) -
DeepBlue (很多事其实都是无关痛痒的...) 2012-08-31 10:43:17
感谢解释！
可执行模型我的理解就是图形化编程语言的雏形或者说其中之一 不知你觉得这个解释如何？
从实现角度 如果模型已经细化到了可转换为代码的程度 为什么不直接用编程语言描述呢？因此我觉得MDE(或者MDA)可能追求的是一种形式化的美感。不能说不对，但至少对实现的角度来看， 是引入了不少多余的东西的。
至于逆向工程 如果给开发人员的代码不是面向对象的呢？如果当初写代码的人并不是按照可转化的指导原则编写的呢？这些都是问题 所以我觉得应该意义不大。
最后 深深的赞同你的“模型如手足，代码如衣服” Hand shake! -
-
TY (你的因果就是你的世界) 2012-08-31 11:02:08
“如果模型已经细化到了可转换为代码的程度 为什么不直接用编程语言描述呢”
目前这个领域的专家的标准答案基本上仍然是：
1）建模比编程具有更高的抽象水平（从汇编到高级语言……到今天的UML）
2）模型是描述性，规范性的，即what，程序（代码）是实现，包含所有细节，即how。
见MDE社区的讨论：
http://modeldrivensoftware.net/forum/top ics/what-is-the-esse ntial -
-
-
167
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
