# Union Models for Model Families: Efficient Reasoning over Space and Time
## 9 Conclusions and Future Work  
In this paper, we propose union models as a first-class generic artifact to capture and represent model families. The paper provides a graph theory-based formalization of model families and their union models. In particular, model families are formalized as a set of attributed typed graphs in which all models are typed over the same metamodel. Metamodels are formalized as attributed type graphs, whereas union models are formalized as the union of all graph elements in the set of typed attributed graphs which constitute a model family. Included in the union model are the graph elements annotated by the models they are occurring. The purpose of this formalization is to permit representation of model families and their union models _independent_ of any modeling language used in the context of MBSE. In addition, we propose a Spatio-Temporal Annotation Language (STAL) to support the representation of variability in model families in both the space and time dimensions and to facilitate reasoning about union models. We demonstrate how the properties of these formalisms can be used to support the construction of union models as well as to perform typical reasoning tasks, such as trend analysis and property checking, on union models. We empirically illustrate the potential of using union models to improve analysis and reasoning over a set of models all at once as opposed to analyzing single models separately one at a time. Positive results are observed even when the time taken to construct union models is taken into consideration; in practice, the construction time can be amortized over many analyses. The artifacts related to this paper are available online. These include Excel files for attributed typed graphs defined according to the formalization provided in Section 3. In addition, GRL model families generated for four SIZE categories (i.e., small, medium, large, X-large) for our experiments, and the Python programs used for the union algorithm, for generating models, and for measuring the reasoning tasks defined in Section 6 are included. See [[https://bit.ly/UnionModelsExtra](https://bit.ly/UnionModelsExtra)]([https://bit.ly/UnionModelsExtra](https://bit.ly/UnionModelsExtra)), accessed on 8 February 2023. For future work, there are many opportunities to follow up on several directions:  
* Studying the effects of variation and topology on reasoning techniques: it is necessary to describe how sensitive reasoning and analysis are to the degree of variation in a union model, as well as where this variation is located (topology). The degree of variation of an \(M_{U}\) can be inferred from the number of annotations and the number of annotated elements that exist in a model family and are represented by that \(M_{U}\). * Improved tool support: although a prototype tool exists for creating union models, the software ecosystem could be greatly enhanced by providing conversion from metamodels (in EMF or MOF) to type graphs and from models to typed graphs expressed with PELA. Tools to better visualize annotated union models in the original language's syntax whenever possible would be very useful. Support for more rigorous lifting analysis methods and editors would contribute to the practical adoption of the proposed approach. * Studying the usability of the approach: there is a need to assess which practitioners this approach is useful to and which parts require usability enhancements in order to improve adoption in industry, especially regarding automation. We envision offering merging and several types of reasoning as online services. * Exploration of further synergies with techniques for representing and managing design-time uncertainty using partial models [51]. Specifically, we would like to adapt model transformation lifting to union models and to develop operators for managing union models across their lifecycle. **Author Contributions:** Conceptualization: S.A., D.A. and Y.L. ; methodology: S.A. and D.A. ; software: S.A.; validation: S.A.; formal analysis: S.A., D.A. and Y.L.