關於MDA/BPM/SOA的隨想

軟體開發不外是：需求->設計->組件->編碼，在軟體開發中，為提高效率，一般要求這四層盡量解耦，即各自變化，互不影響。
其實，現實中很難做到，一般變化的層次越高，引起的變化越大，組件可能只引起編碼的變化，而需求一旦變了，則可能會全盤皆變；
所以軟體開發的突破重點是如何隔離需求的變動；
當然應用人工智慧是一個很不錯的情境，只要業務人員與AI多對對話，什麼都能搞定；但本世紀可能不會實現吧！
現實中，強大而靈活的組件及組件的組裝架構也是一種很不錯方法，BPM/SOA這麼流行，也就是能靈活的粘合不同的組件！組件就象天地人中的人，BPM/SOA就是巫了，能通天達地。
積累的組件越多，做起什麼應用系統、管理諮詢也就越輕鬆，所以現在中介軟體廠商都被做諮詢的、做資料庫的、做作業系統的招安了嘛！
組件在設計及以下層之間做了很好的隔離。當然，要組裝起組件，還是要做一些編碼！當然是BPEL、SCA級次的編碼。
這兩天看了下MDA，覺得可能不會有什麼前途吧！ MDA的目的，在於解耦設計與實現。基於這樣一種認識：設計的變化自動引起實現的變化。
原始碼的自動產生是其主要方式吧！ 使“編碼”一層儘可能的“薄”，當然這個“薄”不是指數量少，而是指開發人員關心的少、做得少。
UML作為一種需求分析工具很強大，但它能否象BPEL/SCA一樣起作用呢？或者作為BPEL/SCA的前端圖形化工具？
需求的變動是軟體開發公司不好控制的，重點只能在組件及組件組裝架構上了。組件設計得好、組裝方式靈活，就能以不變應萬變。
客戶需求只管來，反正敵有鐵浮圖，我有麻紮刀。但萬一客戶提出組件及協作不能達到功能，那隻能敵有狼牙棒，我只有天靈蓋了，開動腦筋去開發、維護組件了。
但強大的組件（很難理解），靈活的組裝方式（很難掌握），實際上把開發的複雜性轉移了。
MDA能否減少這種複雜性？就要看它所能表達的語義能否囊括這種複雜性了。首先要能表達組件所有的行為，然後還要能表達組件協作所能產生的行為。
在嵌入式系統中，以上行為可能不是太多，MDA能勝任愉快。但在公司專屬應用程式中業務可能太複雜了，以至於要麼MDA表達不了，要麼MDA不斷擴充，以至於太複雜了，導致其產生的問題，大於了其能解決的問題！
我看它可能只會起到設計工具的作用，想成為一種開發語言或者模式，還有很長的路要走！