Abstract
Software build systems tackle the problem of building software from sources in a way which is sound (when a build completes successfully, the relations between the generated and source files are as specified) and optimal (only genuinely required rebuilding steps are done). In this paper, we explain and exploit the connection between software build and the megamodel consistency problem. The model-driven development of systems involves multiple models, metamodels and transformations. Transformations—which may be bidirectional—specify, and provide means to enforce, desired “consistency” relationships between models. We can describe the whole configuration using a megamodel. As development proceeds, and various models are modified, we need to be able to restore consistency in the megamodel, so that the consequences of decisions first recorded in one model are appropriately reflected in the others. At the same time, we need to minimise the amount of recomputation needed; in particular, we would like to avoid reapplying a transformation when no relevant changes have occurred in the models it relates. The megamodel consistency problem requires flexibility beyond what is found in conventional software build, because different results are obtained depending on which models are allowed to be modified and on the order and direction of transformation application. In this paper, we propose using an orientation model to make important choices explicit. We show how to extend the formalised build system pluto to provide a means of restoring consistency in a megamodel, that is, in appropriate senses, flexible, sound and optimal.
Highlights
Model-driven development (MDD) is well established in a number of niches such as automotive software [1]
What is fixed is the notions of consistency specified by the edges of the megamodel: in accordance with Step 5 of Definition 6, the restoreConsistency method of the Code-builder must produce a version of the Code that is consistent with the models identified from the orientation model, in this case m, tests and safety
There will be one builder which is responsible for both the class diagram and the state diagram, but the transformation that only reads the class diagram may freq the combined model with a custom stamper which ignores changes to the state diagram, so that it will not need to be reapplied if only the state diagram changes
Summary
Model-driven development (MDD) is well established in a number of niches such as automotive software [1]. If the metamodel to which the model is supposed to conform is the standard UML metamodel, it is not sensible to try to restore that conformance relationship by modifying the metamodel, which should rather be considered authoritative; if the model is in an evolving domain-specific modelling language, it may be For another example, even if the individual transformations roundtripconforms and safeconforms each provide a means of updating the code to bring it into consistency with the design model, respectively, with the tests, the result of applying these transformations will in general depend on the order in which they are applied. We newly discuss the relation with Mokhov et al.’s paper [8], which appeared after [10] but seems to have high potential in this area; in Sect. 11, we discuss future work that will build further on this
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
