在我以前blog中提到过Mendix，本篇介绍一下Mendix，还是相当有借鉴意义的，对企业级软件开发感兴趣的可以看看。

传统开发方法

　　传统开发过程中存在多种角色：项目经理、业务人员、需求人员、技术架构师、可用性设计师、程序员、测试人员、主要客户等，这些角色会被严格的区分为两种类型：业务（business）和IT技术人员。业务部分主要负责客户、业务分析、需求工程，而IT部分主要包括开发人员。架构师、测试人员等。总的来说，就是

• 业务对what负责
• IT对how负责

　　这种方式看起来好像没有问题，但是为什么这么多项目超过时间、超过预算、不能满足需求而失败呢？我们能够责怪大家吗？能够怪需求为什么总是变化的吗？能够怪技术人员为什么不能对复杂业务进行随需应变？答案是明显的：不能。

　　原因很简单：

• 我们不能预见所有的可能性和复杂性
• 很难把抽象的业务需求很好的转换成精细的IT方案
• 设计、文档和实现不同步

软件工程到业务工程

• 释放业务分析师的能力
  现在很多业务分析人员都习惯于使用Visio或者word之类的来编写文档和画流程，在实现过程中很难完整无误的把这些内容转换为实现所需要的东西，如果我们采用一种统一的可视化模型方式来进行业务分析，应用软件大部分功能由业务分析师完成，而剩下的复杂功能由技术人员来解决。
• 减少上市时间
  通过可视化的模型，软件会自动化运行和测试
• 提高灵活性
  如果我们能在模型级别上考虑可变性，那么更改需求将会更灵活简单
• 防止过时的文档
  模型及文档，模型可以被用来运行，所以模型和最终应用程序是100％的同步
• 不重型发明轮子
  构建块、模板等都会在应用开发过程中很好的进行累积，不会重头再次处理同样的事情

　　Mendix 提供软件工具、方法和架构平台来快速建模、构造、测试、继承、部署、管理和优化Service-Oriented Business Applications (SOBA) 。它继承了模型驱动开发和敏捷方法，允许业务分析人员使用可视化模型参与到开发周期中。

与以前开发方法比较

Mendix Model-driven Platform Suite

技术原则

• 提高业务和IT的协作
  每个模型都是业务分析师和IT工程师进行沟通的共同语言，分析师可以找到模型是否匹配业务需求，技术人员检查模型是否满足特定技术细节
• 每个DSL都是可以在运行期下直接运行的
  模型可以直接被运行，防止代码生成带来的一些维护和测试问题（注：我不清楚它是如何做到无代码的，我想是不是生成一些代码，只是模型部分没有生成代码，这个还有待考证）
• 每个DSL都可以扩展为其它第三代编程语言
• 尽量少使用第三代语言
• 开放、可扩展的技术平台，提供可扩展的API访问框架低级别的核心功能
• 开放标准
• 自动化业务流程驱动，业务流程模型是模型的中心
• 服务组件架构（Service Component Architecture）
• 重用，提供可重用的模型、服务、组件等

Mendix Business Modeller: a unified modelling space

模型编辑器

Mendix Business Server

开发方法

 本文转自 jingen_zhou 51CTO博客，原文链接：http://blog.51cto.com/zhoujg/522565，如需转载请自行联系原作者