|
開發 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（未來的功能）
|