在我以前blog中提到過(guò)
Mendix，本篇介紹一下Mendix，還是相當有借鑒意義的，對企業(yè)級軟件開(kāi)發(fā)感興趣的可以看看。
傳統開(kāi)發(fā)方法
傳統開(kāi)發(fā)過(guò)程中存在多種角色：項目經(jīng)理、業(yè)務(wù)人員、需求人員、技術(shù)架構師、可用性設計師、程序員、測試人員、主要客戶(hù)等，這些角色會(huì )被嚴格的區分為兩種類(lèi)型：業(yè)務(wù)（business）和IT技術(shù)人員。業(yè)務(wù)部分主要負責客戶(hù)、業(yè)務(wù)分析、需求工程，而IT部分主要包括開(kāi)發(fā)人員。架構師、測試人員等?？偟膩?lái)說(shuō)，就是
- 業(yè)務(wù)對what負責
- IT對how負責
這種方式看起來(lái)好像沒(méi)有問(wèn)題，但是為什么這么多項目超過(guò)時(shí)間、超過(guò)預算、不能滿(mǎn)足需求而失敗呢？我們能夠責怪大家嗎？能夠怪需求為什么總是變化的嗎？能夠怪技術(shù)人員為什么不能對復雜業(yè)務(wù)進(jìn)行隨需應變？答案是明顯的：不能。
原因很簡(jiǎn)單：
- 我們不能預見(jiàn)所有的可能性和復雜性
- 很難把抽象的業(yè)務(wù)需求很好的轉換成精細的IT方案
- 設計、文檔和實(shí)現不同步
軟件工程到業(yè)務(wù)工程
- 釋放業(yè)務(wù)分析師的能力
現在很多業(yè)務(wù)分析人員都習慣于使用Visio或者word之類(lèi)的來(lái)編寫(xiě)文檔和畫(huà)流程，在實(shí)現過(guò)程中很難完整無(wú)誤的把這些內容轉換為實(shí)現所需要的東西，如果我們采用一種統一的可視化模型方式來(lái)進(jìn)行業(yè)務(wù)分析，應用軟件大部分功能由業(yè)務(wù)分析師完成，而剩下的復雜功能由技術(shù)人員來(lái)解決。
- 減少上市時(shí)間
通過(guò)可視化的模型，軟件會(huì )自動(dòng)化運行和測試
- 提高靈活性
如果我們能在模型級別上考慮可變性，那么更改需求將會(huì )更靈活簡(jiǎn)單
- 防止過(guò)時(shí)的文檔
模型及文檔，模型可以被用來(lái)運行，所以模型和最終應用程序是100％的同步
- 不重型發(fā)明輪子
構建塊、模板等都會(huì )在應用開(kāi)發(fā)過(guò)程中很好的進(jìn)行累積，不會(huì )重頭再次處理同樣的事情
Mendix 提供軟件工具、方法和架構平臺來(lái)快速建模、構造、測試、繼承、部署、管理和優(yōu)化Service-Oriented Business Applications (SOBA) 。它繼承了模型驅動(dòng)開(kāi)發(fā)和敏捷方法，允許業(yè)務(wù)分析人員使用可視化模型參與到開(kāi)發(fā)周期中。
與以前開(kāi)發(fā)方法比較
Mendix Model-driven Platform Suite
技術(shù)原則
- 提高業(yè)務(wù)和IT的協(xié)作
每個(gè)模型都是業(yè)務(wù)分析師和IT工程師進(jìn)行溝通的共同語(yǔ)言，分析師可以找到模型是否匹配業(yè)務(wù)需求，技術(shù)人員檢查模型是否滿(mǎn)足特定技術(shù)細節
- 每個(gè)DSL都是可以在運行期下直接運行的
模型可以直接被運行，防止代碼生成帶來(lái)的一些維護和測試問(wèn)題（注：我不清楚它是如何做到無(wú)代碼的，我想是不是生成一些代碼，只是模型部分沒(méi)有生成代碼，這個(gè)還有待考證）
- 每個(gè)DSL都可以擴展為其它第三代編程語(yǔ)言
- 盡量少使用第三代語(yǔ)言
- 開(kāi)放、可擴展的技術(shù)平臺，提供可擴展的API訪(fǎng)問(wèn)框架低級別的核心功能
- 開(kāi)放標準
- 自動(dòng)化業(yè)務(wù)流程驅動(dòng)，業(yè)務(wù)流程模型是模型的中心
- 服務(wù)組件架構（Service Component Architecture）
- 重用，提供可重用的模型、服務(wù)、組件等
Mendix Business Modeller: a unified modelling space
模型編輯器
Mendix Business Server
開(kāi)發(fā)方法
本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請
點(diǎn)擊舉報。
