Conclusion - Model-Driven and Software Product Line Engineering - page 250

using our case study, how one of these stages involved
concerns about software architecture based on components.
For this, we created one specialized metamodel capturing
concepts of component-based software development.There are,
however, several Architectural Description Languages (ADL)
such as [ASI 07, DAS 05, RAS 11], which are based on
metamodels that include very complete information about
architectural concerns. We consider it important to include
the use of these ADLs into our approach to extend the
scope of variations we are able to manage regarding
software architecture, irrespective of the domain of the
MD-SPL we are interested in developing.
We considered AOP as a suitable paradigm to tackle the
problem of adapting the execution ordering of transformation
rules. Recent work (see [ASP 08]), has shown how AOM
is a valuable paradigm to be incorporated in model-driven
engineering. AOM allows product line architects to create
re-usable models, which during the derivation of product
line members can be woven with other models according
to variability choices performed by product designers. We
believe that AOM enables the explicit expression and
modularization of variability on model level and facilitates
the maintainability and re-use of models as core assets.
Thus, we consider it important to integrate AOM in our
approach.
Declarative programming minimizes side effects by
describing what the program should accomplish, rather
than describing how to go about accomplishing it [LLO 94].
DeclarativeprogramminginMDEhasanumberofadvantages.
Declarative transformation rules are based on specifying
relations between source and target patterns, hiding the
details related to selection of source elements, rule triggering,
and ordering [JOU 05]. We believe that the integration of
declarative transformation rules may help to deal with the
problem of adapting the execution ordering of transformation
rules, given different product configurations.