开发 AndroMDA 4 的几个原因。事实证明AndroMDA 3是当今代码生成任务最成功的架构，但已经可以看出，它难以应付未来新的任务。AndroMDA 4 架构的目标有：

可配置和可扩展性

我们应该让我们的用户比以前更容易（重新）配置和扩展AndroMDA。用户应该能够把AndroMDA作为一个组件使用，可以组织、链接，扩展和部署，以实现他们的代码生成的目标。可配置和可扩展性，必须支持以下功能：

可与其他UML metamodels（元模型）配合工作

AndroMDA 3 是主要用于与UML配合使用。它可以和其他UML元模型配合工作，太糟糕了，没有人对其进行了测试。

有些事情不容易在UML表示，例如，图形用户界面。domain specific languages (DSLs)能够更好的表述、形容此类事情AndroMDA 4 应支持任意的基于metamodels （元模型的）模型输入。

重用，改造和chaining of off-the-shelf和定制cartridges

在AndroMDA 3中，有可能从头开始写一个cartridge ，使用一个已有的cartridge或在一定范围内扩展已有的cartridge。然而，一个cartridge输入模型几乎总是依赖一个特定的UML配置文件（profile），使用户被迫以某种方式建模。一个fledged的输入总是“完全成熟”的模型，输出总是“准备使用”源代码。这种方法可以被称为“百分百方法the always 100% approach”。大面积使用cartridges不可能用非常精细和复用，比如：cartridges A 做30％的工作，cartridges B 拿A的输出最为输入，完成50％工作，最后cartridges C完成20%的工作，这样就100%的完成了。

在AndroMDA 4中，用户应该能够在从模型到代码的转换中重用已有的cartridges建立blocks 一个cartridge 把输入模型转化为一个或更多的模型或者文本，任何基于元模型的内容，cartridges 建可相互配合、来完成工作。

一个典型的例子是：一个用户说：“行，我最喜欢Hibernate的 cartridge ，但我希望所有生成的实体实现某些接口”。 这个用户可以编写另一个cartridge 添加了必要的接口生成的实体类。最好的办法来处理，就是用模型到模型转换。

模型到模型转换

这些转化为1..n输入模式到1..m输出模式，每个模型包含在一个元数据储存库。对于转换，我们将使用开放源码框架ATL。然而，AndroMDA不应仅仅依赖于ATL的，但必须能够使用任何模型到模型转换引擎。

这里，可配置性也是一个重要方面。转型引擎应该能够访问AndroMDA配置，以便能够转换能够参数化。我们的解决方式是把AndroMDA配置作为一个模式，可以像任何其他模型一样进行转换。因此，AndroMDA必须有一个配置元模型。

支持基于构件的开发

模型往往是随着时间的推移逐渐变大。The generator 需要越来越多的时间来验证模型和生成代码。应该可以运行the generator 处理输入模型的部分内容（请注意，在一部分独立元模型上，这是可能的）。在AndroMDA 3中，唯一可能的是，限制只产生UML模型中的包的代码。在AndroMDA 4中，这应该只是一个特例。AndroMDA 4应该能够随心所欲的产生输入模型中部分代码，如：架构的一个切片（MD，怎么切啊）、一个子集，（实在是不会了）a time or one architectural tier at a time or one server at a time or whatever subset of the content of the input model(s)

这需要一个配置机制，来增加全局的限制，从而找到那些模型元素需要被转换。

更好的可测性

AndroMDA的每个组件应该很容易testable，as isolated as possible。在设计组件的界限和接口时，我们应该注意，一个组件应尽可能少的依赖其他组件的成功测试（其他组件需要测试通过后才能测试这个组件）。

性能和可伸缩性

AndroMDA应当有很好的性能和执行成绩，因为用户生成代码的规模和的形式在不断发展（要不产生代码越来越费劲，费时，谁还用啊）。两种可能的方案，以减少执行时间：

• 仅生成部分模型（参见上面的CBD）
• 增量生成，reacting to changes（未来的功能）