下一代軟件開發模式――系統可視化配置生成

  隨着技術的進步與社會的發展，應用系統也日益複雜化，系統升級也成屢見不鮮。
  因爲開發系統使用技術過於舊，與如今的技術兼容性很差，若是升級可能要從新來過，之前的工做就這樣白費了。
  因爲開發系統時過於急，沒來得及考慮使用什麼技術就動工，已經開發了至關一部分以後忽然發現其實用另外一種技術更適合開發本系統，你會是怎麼樣做呢？
  因爲系統生命週期過長，文檔也對不上，若是有一天要修改某些地方，這時要修改的某數據是什麼來，通過什麼處理，也許要摸索得好久都沒法徹底瞭解，若是修改了這個地方會 不會影到系統的其它地方的使用，這無形中給咱們帶來了巨大的工做量。
  因爲客戶的需求不斷地更改，每每修改一個小小需求，開發人員可能要修改好幾個地方，而且還要對修改一次又一次的測試，無形增長了開發成本。
  因爲系統開發都時限，面對着巨大的任務，咱們又是如何解決呢？選擇增長人員？選擇要求員工加班？
… …
  目前軟件開發模式的問題不斷的出現，促使新的開發模式的出現――系統可視化配置生成。乍看，不少人以爲不是一個新鮮的事情，並以爲這種開發模式不大現實。這也是不能否認的事情，由於這種開發模式須要一個比較強大的工具――配置引擎做支撐，而目前還沒有或極少這類型的產品。配置引擎的做用是用於可視化形式配置，描述出整個系統。另外還須要一個代碼生成引擎，將根據配置引擎配置生成XML和選擇使用的技術（如使用JAVA 的SSH2 ――Struts2+Spring+hibernate），即可生成對應的系統.也許不少人以爲不大現實，若是這麼神奇，咱們還要開發人員嗎？其實目前階段因爲這方面的技術還沒有成熟和極少人去研究，因此複雜性通常的系統生成代碼大概也只是70%（目前），接下來須要開發人員完善。
如今討論一下系統可視化配置生成優缺點.
  系統可視化配置生成有以下的優勢：
  （1）能夠粗略配置，可生成Demo，若是初步瞭解了客戶的需求以後，咱們能夠用生成 的Demo與客戶進一步溝通，確認，因爲可模仿真實系統效果，這樣客戶會更明確本身要求的系統是什麼樣子，系統能做什麼的事。只有這樣，須要分析更加深刻，返工的機會便少了。
  （2）因爲配置完成以後，能夠生成相應的文檔，給與客戶溝通或者對生成代碼修改帶來極大的方便。
  （3）開發週期縮短，由於從需求階段到開發階段都很大程度上方便咱們工做，開發週期縮短是不用說的了。
  （4）配置時能夠不考慮採用什麼技術實現，等專心配置好以後，咱們能夠選擇任何一種或者多種技術的系統，接着咱們還能夠對不一樣技術生成的相同系統進行對比，再最終肯定系統實現是採用什麼技術。
  （5）若是系統升級，咱們能夠在以前配置（配置結果是經過XML保存下來）的基礎上配置，同時咱們能夠選擇用新技術，生成整套系統。
  （6）代碼規範性好，容易維護。
  （7）系統健壯性好。生成系統存在的BUG相對更少，由於代碼生成引擎生成的代碼能夠說是經過測試了。生成代碼同時還會生成測試用例和測試數據。這樣咱們只要驗證一下報告結果，針對存在問題，再修改配置。

系統可視化配置生成有以下的缺點：
  （1）系統使用技術相對限制，由於代碼生成引擎不可能有任何種技術組合，若是一個生成代碼引擎，有JSP+BEAN、 Struts2+Spring+Hibernate這二種組合代碼引擎。就不能夠選擇用Struts+Spring+Ibatis這種技術組合，但你能夠本身開發相應的生成引擎或者在網上找對應的技術組合下載回來，而後集成到代碼引擎，供之後使用。
  （2）系統的框架也會限制，因爲不一樣的公司，就算是用相同結合技術，但系統的框架風格也是不同的。但如對現有的框架風格不滿意，能夠自行開發本身風格的生成引擎 ，就能夠避免了這種問題。
  （3）生成系統局部性能不佳，因爲生成代碼考慮是比較大衆的方式，而某一些細節可能採用另外一種方式實現，性能更佳，這時須要開發人員自行修改。
  （4）再次生成時，對先前開發人員修改後的代碼，可能覆蓋了。這個問題是最大的問題、也是目前還要探討一方面。由於若是配置文件修改了而開發人員在以前配置的基礎上生成代碼進行的修改，涉及到的問題是比較複雜，因此有待探討，完善這一缺點。

  大概地講一下生成引擎的優缺點，接下來，討論一下本人開發的配置生成引擎（SSX Config）是基本部分組成：
  （1）數據庫配置。
  （2）數據庫中表結構讀取，對比和刷新功能。由於是基於表進行配置，表結構讀取功能是必要;刷新和對比功能並行使用的，用於對如今數據庫的變動的檢測，對變動的，能夠可視調整。如咱們以前編號是用ID，如今要修改爲EID,刷新與對比以後，就配置引擎顯示讓ID已經刪除，新增了EID，咱們能夠對ID的配置，替換成EID，替換以後，不用再對EID與ID 相同其它配置，EID將持有ID全部配置。
  （3）數據庫中的表查看，表名，表字段等顯示名配置，在頁面上咱們通常有數據有說明，如一個接收姓名的輸入框，咱們會它的前面加顯示名――「姓名」，有這個顯示名，配置時也比較容易清楚某個表或者某一個字段是什麼意思。
  （4）表關係的配置，這個功能是針對用持久層框架設計的，如用Hibernate，Xml配置文件中有表之間的關係，這樣若是設計表時沒有表關係也無所謂，能夠經過這種方式配置，效果也差很少。
  （5）表的表單全局配置，本功能針對頁面層對應某字段顯示的形式（如是輸入框，仍是下拉框等），驗證（如：長度，EMAIL等）,配置新增、編輯時，讀取這裏的信息做爲默認信息。
  （6）添、編、刪、看的配置，支持多表複雜的添加、編輯、查看。
  （7）查詢列表配置，支持多表複雜的查詢，查詢頁面條件配置等。
  （8）下拉框，多選框等數據配置
   對（6）（7）（8）在本文不詳細討論，由於比較難用二三句話說得清楚，搞很差，反而讓人一頭霧水。本人往後將會有會針對性詳細討論的文章。
  代碼生成引擎部分，本人針對SSH2（J2EE）組合技術正在開發引擎，也即將開發完成。有時間，再詳細與你們探討一下這方面的技術。由於這種技術將會在不少軟件公司使用，而且有針對性的開發出本身風格和需求的代碼生成引擎，方便新系統的開發。
謝謝你們的關注，系統可視化配置生成技術。因爲本人水平有限，不免一些遺漏、不足地方，但願你們指出，若有對這方面感興趣，能夠與我繼續討論，個人聯繫方式：[email]cmm3.com@163.com[/email]。(做者：cmm3.com)