开发 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(未来的功能)
|