谁告诉我，究竟为什么老外总是想通过model产生一切？？？

我从一开始就没有看明白，这个主题到底是在讨论什么。

“为什么老外总是想通过model产生一切”。
－ “老外”是指谁？Ivar Jacobson吗？还有谁？至少Martin Fowler并不认为“model可以产生一切“，Rickard Oberg说“我和我的朋友都不会去用Fxxx MDA“，那么这里说的“老外”是指谁？
－ “总是”是什么意思？
－ “model”是指什么？说泛化了，软件就是对真实世界的建模，一切软件都是某种模型。那么这里所说的“model”，具体是指什么？
－ “产生”是什么意思？代码生成？运行时推导？程序员根据模型设计写出其他代码是不是“产生”？
－ “一切”是指什么？我相信没有人认为可以根据什么模型产生一个西瓜，那么这里说的“一切”包含什么？

这个问题本身，至少在我看来，不是那么容易理解的，所以后续的讨论，就有点更加不容易理解了。

gigix的疑问我觉得我要首先拿到汉语言文学，计算机科学，哲学，历史，医学，植物学等等NNN个相关的博士后再后再后后，才能有个比较准确的解释（为了不被gigix问，我只有用“准确”不用“正确”，相信gigix也知道任何事情都没有对错）。所以，在此，我暂时还是很俗气的理解为抠字眼（我在犹豫，这个词我是用“抠字眼”好还是“抠字眼儿”好），嘿嘿，开个玩笑先。

我不知道你为什么说软件就是对真实世界的建模，软件就是软件，它本身就是真实的，我认为软件是我们现在世界的一部分，它和所有的东西都有联系，包括西瓜（难道没联系?）。他并不是对世界的建模，而是人们知道了这个东西，然后逐渐认识到了它，然后再通过我们的思想认知，使得这种联系被我们掌握。模型是模型，软件是软件，有联系，但是地位是平等的。或许教科书上写他是模型，但是我不这样认为。就像“gigix”一样，你说这个是你的模型还是你？:o 这里的文字，是为了和“gigix”沟通，而不是和“gigix”这个“模型”（如果“gigix”认为“gigix”是“模型”的话）沟通。

其他，关于标题，你把他理解为标题党的做法好了。从大家的讨论来看，我觉得都是有价值的信息，如果从类似头脑风暴的出发点，现在基本处在良性讨论/争论之中。

这个就是原型化开发，也是最实际值得我们花精力去研究的，至少我个人认为原型化开发这个才是软件开发的突破口。



我认为，界面基本可以包含一切需求（当然包含不了），而model只是一部分，无论哪位是用户，可以没有model，但是你要有界面。或者更严谨一些些说，界面是需求，但是model不是需求。当然，我不否认model这种中间产物的用处。至少它的抽象帮助我们解决了很多问题，就像1，2，3这些数字一样。抽象是必要的。



不错，这个根源应该在于前面gigix提到的软件是模型的假定，当然我认为这个定义是错误而且有误导性的，但是就像教科书一样，有时候为了让大多数人能够明白，然后定了一个义，至于能否理解，只有靠自己的悟性了。


类似20楼Julien说的，model现在被滥用了，model是从哪里来的，是你的需求来的。所以，出发点是需求，不是model。4楼及21楼gigix也提到Fxxx MDA事情，虽然那位不知名的Rickard Oberg大师感情强烈了些，但是可以说明他对这种model driven的某物的不爽。
关于model，最典型的就是各种O的出现，自从OO出来，VO，PO，DTO，XO:D，YO，呵呵，都出来了，什么东西都想来个O。见http://www.iteye.com/topic/627?page=8的78楼，我有提到一些。
这个也有些像模特model，其实关键是那些服装，更关键是那些服装传达的信息。
我觉得，各种container基本都够大家用了，为啥还没完没了的O。17楼我有提到Mapping，这个Mapping我们一直在用，哪里？？？就是这些O。

再次重申，我认为在现在的软件开发过程中model是必要的。（为什么要加个“现在”，这样想一下，我们如果用穷举法在硬盘上写0和1，是不是总有一天能把你的软件举出来？包括你的windows操作系统。所以，假定计算机足够快，硬盘和你我的寿命够长，你还要做什么软件设计，剩下的只有测试，测试举出来的是不是我们要的软件就可以了 ）

我认为软件最主要的是界面，其次是我们所谓的持久层那块的东西。这个界面包含与其它必要的外部系统通信使用的接口。都是Interface。持久层那块需要什么？这里才是要model的地方。当然业务逻辑那块也要，如果系统大些的话。为什么我们要mapping，因为我们的语言和计算机能够了解的不一样，当然这个也表现在不同技术之间的语义上的差别，这样才造成了，我们需要通过mapping转译。mapping动作的承担者，就是model，于是O开始出现。

*mapping这个词可能不准确，他的含义是建立联系，同时为了双方能够理解而进行必要的转换/翻译
*model这个词，前面有些是做model这个任务，差不多就是modeling，另外也有些是model这个东西，有些混（困了 ），大家见谅，不明白的地方我再单独说明吧。


声明一下，上面有些内容可能与现在大多数人的认知不同，希望大家能够随意发表意见，本帖希望开放性的讨论，特别欢迎实战人员的加入。
  

最近弄Eclipse plugin玩, 接触了一下GEF,EMF 我不敢说MDA是"银弹"什么的 但的确是一种很值得一看的思想
(xml+xslt : model->UI) ? (formbean + beantag : model -> UI)

怎么我的感觉是恰好相反。
对于一个稍有复杂度的界面，要想向一个新人说明白这个界面到底是在干什么事情，必须翻出一堆文档来，或者找一个熟悉设计，同时又熟悉业务的人把系统运行起来讲解一下。透过支离破碎的界面根本看不出业务的全貌。程序员只知道这个画面把xx数据放进yy数据表，根本不知道这个业务含义是什么。
如果这个界面下面是一段业务意义很明确的代码，基本上看代码就可以明白了。对于规模较大的系统来说，他不能是一个独立的系统，他必须是一个开发平台，提供业务API，开发者可以不断的在这个平台上开发新的功能。就像是我们平常使用的office，他有完备的领域层，并且向外界保露了这些接口，可以使用VB脚本调用，于是我们可以编写宏，实现千变万化的各种需求。

这点确实是有些迷惑人,关键还是你要从谁的角度看.需求是客户提的,所以,从客户的角度,他最直接的是看见你的界面,做过需求分析的人知道,客户其实不关心你的后台是怎么做的,他关心的是如何来用这个系统(当然，更重要的是这个系统可以为他带来什么？).而且,无论怎么样的需求文档,最终客户要的也是那个界面.对客户而言,界面就是一切.
你所说的新人,似乎是站在开发人员的角度来说的.包括下面的Office的例子,也是站在开发人员的角度看的.而我认为任何一个项目都应该以客户为中心.现在的技术,大家说白了,没太多新东西.软件开发行业,我觉得下面一个阶段注重的是"用户体验".

"至少Martin Fowler并不认为“model可以产生一切" ---难道 分析模式 搞出来的东西，不属于模型范畴么？

从high level到low level，各个层面都有它的模型表述形式，比如用来描述架构的四个（或者更多）模型视图，详细设计的对象流程图等等。 一说到Model，不知道每个人心里想到什么了？想得不一样，讨论起来就风牛马了

别以为客户的需求就是界面，表面上客户是在界面上工作，其实他的工作和这个界面一点关系也没有。这个界面只是他此时此刻实现工作的一个途径，说不定他的心里早就恨透了这个界面——怎么做的这么蠢，升级了无数次为什么还不改掉！
经常有人喜欢拿着一个示例界面向别人演示需求，很多用户就喜欢这么做。很多开发者也乐于看见这样的“需求”，因为他很明确。但是实际上应该这样：假设现在没有任何界面，也没有IT系统，没有接口，没有数据库……去掉这一切以后，我们仍然要做的事情就是需求。
需求是客户提出的，但是有时他们会提出一个解决需求的方案，而不是直接的提出需求。他的需求你要去挖掘、牢记，他的方案你最好是当作放p。

这种情况确实会遇到,但是,如果没有界面,可以肯定的一点,这个系统对人没有价值,你开发的干啥?
客户要的当然是系统为其带来的价值,系统应当算是其实现business goals的一个工具。但是business goals和requirements也是有区别的。


你说的啥都不要的那个是business goals，是在一般所说的需求之前需要知道的，所有系统需求都是建立在这个基础之上的。另外，如果没有IT系统，把我们开发人员拉过去干啥？
还有界面不仅仅包含屏幕上面那些东西啊，打印机，音响，话筒，扫描仪，任何一个可以与系统交流的东东都是界面。嗯，或者我用“介面”会不会更准确些。

界面，或者你提到的“介面”是不能代替需求分析的。我曾进与一个用户沟通了长达半年的时间，弄清了他需要哪些“界面”，结果需求仍然是不断在变，最后这是一个失败的项目。实际上那只是一个简单的计划编排系统，需求并没有发生根本的变化。
对于一个需要长期维护的系统来说，开发者需要做出来的不仅是满足当前的功能需要，更是要在开发的过程中建立一个业务开发的平台，开发和维护的过程就是不断的在这个平台上做新的功能点。要做到这一点，就必须一开始就把力量放到业务上，开发和维护一个合理的业务模型。在这个基础上，功能点和界面是很容易开发的。
调查需求的时候千万不能先入为主想着需要做哪些功能和界面，一旦陷入这些想法，可能就再也回不来了。用户经常会向开发者提出他需要某个界面，功能点。其实他们的目的是在描述需求，用这样的方式在描述，并不是他们真的需要这些界面。你需要提供的是一个solution，是一个解决问题的方式，而不一定是某个系统或者程序。也许这个solution是用户业务流程的一个变更，也许他们可以换一种方式使用现在的系统，而他们不知道其实可以这样做。最后的结果也许不需要写一行代码。