軟體開發的未來，是MDA/MDD/面向模式/Plug-in IDE嗎？

軟體開發的未來，是MDA/MDD/面向模式/Plug-in IDE嗎？

一、問題：

1．  有快速的類似PB的J2EE開發工具嗎？

2．  客戶需求不確定、易變時，如何保證J2EE體系的開發效率？

 

近期開發了套EJB3.0+JSF的業務系統。從技術、開發時間等方面，開發人員是自信的。但是，老闆和客戶，卻覺得開發效率、使用者介面操作不夠理想。

原因在於，老闆和客戶，認為應當有PB、Delphi這樣的快速開發工具，來快速開發複雜的J2EE的分布式系統。而採用Jbuilder、Eclipse，和基於Annotation、Tag的單向代碼產生方式，開發效率仍然不能讓他們滿意，尤其是業務需求易變、不穩定的時候。

 

二、解決問題的方法，MDA是方向嗎？

 

為了取悅老闆和客戶，便狂找是否有IDE能解決這個問題。最後，卻在MDA處，朦朧地找到，應對易變和不確定的需求，高效開發J2EE這種複雜應用體系的軟體的大致方向。

 

未來主流的開發方式和支援工具，肯定不是走PB、Delphi的道路。而是走MDA/MDD（模型驅動和開發），Pattern Driven（模式驅動），支援Plugin的IDE的道路。

 

那些固定技術模式（業務+介面的組成）的開發工具（如PB、Delphi），是不可能支援不同客戶的獨特業務需求和多種類的用戶端介面。這就是Borland要出售IDE的內在原因。

 而Eclipse的前途，也在於其Plug-In的體系。

而採用MDA/MDD（模型驅動和開發）、Pattern Driven（模式驅動）、支援Plugin的IDE，企業就可以開發出自己的工具（IDE），根據業務，快速產生符合自己的Framework的代碼。

 

所以，市面上的J2EE開發工具，才都不提供現成的組件，用固定的模式，實現象PB那樣的開發方式。

 

三、MDA/MDD、Pattern Driven支援Plugin的IDE，怎樣實現高效率的開發？

 

採用了MDA，項目組的結構，肯定要調整。簡單說，就是貧富差距拉大，能者越重要，普通程式員越普通。

 

1．BA、SA：

只需要跟客戶溝通，擷取需求，確定功能，確定模型（Domain Model，或者E-R圖），寫需求功能文檔。他們最多隻需要UML畫圖（PIM層次），不需要深入技術細節。身份接近於“諮詢師”，業務知識是他們的價值所在。

2．架構師：

根據SA的反饋，儘早確定技術方案，建立Framework。

確定了前後端（Business、Gui）的Framework後，架構師根據MDA規範和具體工具，定義模型驅動模板(Pattern Plug-In)、代碼轉換模板（Transaction）。

基於Annotation、Tag的單向代碼產生方式，會很少採用。

他是項目的靈魂，Framework+代碼轉換摸板，他協助項目產生了核心的代碼，尤其是業務端（如EJB、資料庫關聯層）。

3．SA、高程：

根據Domain Model，轉換為PSM。

在PSM級，根據模型驅動模板(Pattern Plug-In)，產生業務組件類代碼。如為實體產生Session Bean，產生Command模式的代碼。

SA、高程，適當地手工調整好PSM，根據代碼轉換模板（Transaction），產生符合企業Framework的Java代碼。如根據實體類，產生EJB或Hibernate；根據Session Bean等組件，產生用戶端（Gui）需要的代碼（JSF的ManageBean、Struts的Action或Swing的布局代碼）。

具體語言技術、模式知識，是他們要掌握的。SA懂技術，就更能把業務模型設計好。

這裡，可以產生全部業務端（中介軟體層）代碼，比如實體類、Session Bean、業務代理類。

如果需求變化，比如增減欄位，修改Domain Model後，變化可以同步到Code。而且，不會覆蓋Code中手工輸入的部分。真正作到雙向同步。

4．程式員：

在前期，輔助BA、SA，設計原型。根據客戶需求，用快速開發工具，畫出介面，類比互動操作，但無須綁定到資料來源。如，用JSF或Swing，畫Gui介面。

從目前MDA工具和介面技術，完全靠工具自動產生Gui代碼，無論是Swing或Jsp，都不是很現實。所以，只需要用工具產生Gui代碼架構就足夠了。

而業務部分的代碼，主要在中介軟體層，而中介軟體層是由工具產生。所以，Gui除了布局，只是簡單地調用中介軟體的業務介面。所以，程式員的主要工作，就是實現介面，單元測試。

 

四、通過Rational Architect，實踐基於MDA的快速開發

 

理論要實踐。MDA的前途，是大家都疑惑的。那麼，通過項目，先用Rational Architect來逐步實現；通過結果看，目前的MDA工具，到底可以作到什麼程度。

1．  根據新項目的業務特點，調整中介層Framework。

2．  通過自訂的Pattern Plug-In，把實體類模型（E-R），轉換成EJB3.0有關的PSM。主要產生細粒度的Session Bean。

3．  在PSM裡，手工定義粗粒度Session Bean。

4．  通過自訂的Pattern Plug-In，為粗粒度Session Bean的業務介面，產生Command。

5．  通過自訂的Pattern Plug-In，為每個實體，產生Gui代碼架構，先實現基於Swing的。

6．  當業務變更，只需要增減PIM的實體模型裡的欄位，就能同步更新到PSM。

7．  當商務邏輯變更，調整PSM中的Session Bean的方法的細節，與代碼變更同步。

8．  當業務端變更，重建Command。程式員手工調整Gui以適應Command在介面細節上的變化。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=621754