关于MDA/BPM/SOA的随想

软件开发不外是：需求->设计->组件->编码，在软件开发中，为提高效率，一般要求这四层尽量解耦，即各自变化，互不影响。 其实，现实中很难做到，一般变化的层次越高，引起的变化越大，组件可能只引起编码的变化，而需求一旦变了，则可能会全盘皆变； 所以软件开发的突破重点是如何隔离需求的变动； 当然应用人工智能是一个很不错的场景，只要业务人员与AI多对对话，什么都能搞定；但本世纪可能不会实现吧！ 现实中，强大而灵活的组件及组件的组装架构也是一种很不错方法，BPM/SOA这么流行，也就是能灵活的粘合不同的组件！组件就象天地人中的人，BPM/SOA就是巫了，能通天达地。 积累的组件越多，做起什么应用系统、管理咨询也就越轻松，所以现在中间件厂商都被做咨询的、做数据库的、做操作系统的招安了嘛！ 组件在设计及以下层之间做了很好的隔离。当然，要组装起组件，还是要做一些编码！当然是BPEL、SCA级次的编码。 这两天看了下MDA，觉得可能不会有什么前途吧！ MDA的目的，在于解耦设计与实现。基于这样一种认识：设计的变化自动引起实现的变化。 源代码的自动生成是其主要方式吧！ 使“编码”一层尽可能的“薄”，当然这个“薄”不是指数量少，而是指开发人员关心的少、做得少。 UML作为一种需求分析工具很强大，但它能否象BPEL/SCA一样起作用呢？或者作为BPEL/SCA的前端图形化工具？ 需求的变动是软件开发公司不好控制的，重点只能在组件及组件组装架构上了。组件设计得好、组装方式灵活，就能以不变应万变。 客户需求只管来，反正敌有铁浮图，我有麻扎刀。但万一客户提出组件及协作不能达到功能，那只能敌有狼牙棒，我只有天灵盖了，开动脑筋去开发、维护组件了。 但强大的组件（很难理解），灵活的组装方式（很难掌握），实际上把开发的复杂性转移了。 MDA能否减少这种复杂性？就要看它所能表达的语义能否囊括这种复杂性了。首先要能表达组件所有的行为，然后还要能表达组件协作所能产生的行为。 在嵌入式系统中，以上行为可能不是太多，MDA能胜任愉快。但在企业应用中业务可能太复杂了，以至于要么MDA表达不了，要么MDA不断扩展，以至于太复杂了，导致其产生的问题，大于了其能解决的问题！ 我看它可能只会起到设计工具的作用，想成为一种开发语言或者模式，还有很长的路要走！