In the scenery of web engineering methodologies [1] [2], there is a current trend on following the Model-Driven Development (MDD) approach [3], adopting the Model-Driven Architecture (MDA). In MDA, model transformations are essential. Thus, instead of directly generate the code from the conceptual model (model-to-text transformation), the conceptual models, i.e. Platform Independent Models (PIMs), are translated to one or more Platform Specific Models (PSMs) by means of model-tomodel (M2M) transformations. Subsequently, PSMs are translated into code by means of model-to-text (M2T) transformation techniques.One of the strategies that MDA promotes to facilitate changeability and portability of the conceptual model is the prescription of the PIM separated from the PSM. However, in practice, current web methodologies tend to cope with architectural evolution trends by extending their modeling notations directly at the PIM level (e.g., WebML RIA [4], UWE for RIA [5], OOH4Ria [6], among others). MDD proposals for mobile applications development also follow this landscape. Examples of this are WebRatio [3], MD2 [7], MobiCloud [8], among others. Such extension usually results in an enriched PIM that includes characteristics and constraints of a certain specific architecture or platform. The enriched PIMs are obtained either by adding marks (but without considering this as a marked PIM), or by adding new entire models, or even by adding new elements in the PIM notation. Although it could be argued that after extending a PIM to support a specific architecture it is no longer a PIM, but a PSM, in general, the literature does not analyze this distinction.The problem is that this tendency of adapting the PIM to specific architectures goes against the principle of the PIM portability promoted by MDA. The enriched PIM loses part of its independence from the architecture/platform, and becomes increasingly more complex to understand and manage. The consequence is a loss of portability and reusability of the conceptual models.A complementary portability problem arises when web methodologies tend to enrich the PSM with architectural details, since the same architecture can be implemented in different platforms (e.g., the RIA architecture can be implemented in Backbase, Dojo, GWT, jQuery, among others). In this case, the problem is not concerning the conceptual model, but it requires for the same architecture multiple PSMs according to the different implementation platforms.To preserve the independence of the PIM and the portability of models towards different architectures, some authors have already proposed the introduction of an Architectural Specific Model (ASM) (e.g., [9], [10]). The ASM allows details related to the architecture to be moved out from the problem space (PIM) to an intermediate vii model in the solution space (ASM), avoiding the PIM from containing such details and contributing to its so desired portability. Moreover, the ASM model can result in different PSM models, one per each implementation platform.In this w...