关于BPM/SOA/MDA的随想

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

很好的思考和观点

MDA是一个努力方向,MDD/DDD也是,其实我们的软件系统如果计算机身份越明显,就越不能快速跟随需求变化,如果我们把需求知识和计算机概念看成矛盾两个方面。

所以,站在需求只是和计算机概念分界线中间才能协同这两个一起发展,做好他们两个之间变动的沟通,而显然DDD/oo方法是目前最适合的,相反数据库等计算机概念很强的则不能。