# Union Models for Model Families: Efficient Reasoning over Space and Time
## 8 Related Work  
In the literature, few approaches have been proposed to support model families. [PERSON] et al. [9] used GRL to define a generic goal model family for various types of organizations in the legal compliance domain. They annotated models with information about organization types to specify which were applicable to which family members. Different from our work, the work of [9] handled only variation of models in the space dimension, and did not consider evolution over time. In addition, the authors focused only on maintainability issues and did not propose union models to improve analysis complexity and reduce analysis effort. [PERSON] et al. [8] elaborated further on the work of [9] to support more variable regulations. The authors integrated GRL and feature models to handle regulatory goal model families as software product lines (SPLs) by annotating a goal model with propositional formula related to features in a feature model. Unlike [9], [PERSON] et al. considered further dimensions such as the organization size, type, the number of people, etc. However, they did not consider the evolution of goal models over time, and did not introduce union models. Our work has strong conceptual resemblances with the domain of SPL engineering, which aims to manage software variants in order to efficiently handle families of software [31; 32]. The notion of a feature is central to variability modeling in SPL [33], where features are expressed as variability points. Feature models (FMs) [16] are a formalism commonly used to model variability in terms of optional, mandatory, and exclusive features organized in a rooted hierarchy and associated with constraints over features. FMs can be encoded as propositional formula defined over a set of Boolean variables, with each variable corresponding to a feature. FMs are deemed to be very useful to represent feature dependencies, describe precisely allowed variability between products in a product line, and guide feature selection to allow for the construction of specific products [34; 35]. However, it is important to emphasize here that FM is different from our proposed union models \(M_{U}\) in both usage and formalism. The differences between both artifacts can be summarized as follows:* A feature model represents variability at an abstract \"feature level\", which is separate from software artifacts (such a grammar of possible configurations), whereas \(M_{U}\) represents the variability of all existing models at the \"artifact level\" itself [36];
* While a feature model defines all possible valid configurations of products along with constraints on their possible configurations, an \(M_{U}\) provides a complete view of the solution space that makes it explicit for modelers which particular element belongs to which model without necessarily modeling dependencies or constraints between elements of one model or across several models of a family;
* The purpose behind using both artifacts is different, in that FMs are mainly used to ensure that the derived individual models are valid through valid feature configurations, with the possibility of generating new models or products. On the other hand, \(M_{U}\) is proposed to perform domain-specific analysis beyond configuration validation more efficiently on a group of existing models than on individual models;
* Finally, an \(M_{U}\) enables the extraction of individual members of a model family by means of selecting particular time and/or space annotations, while FM enables model extraction by means of selecting valid combination of dependency rules and cross-tree constraints between features. There exist verification approaches that target many valid configurations of feature models [37]. For instance, [PERSON] et al. [38] explored the use of model checking on a family of behavioral models captured by a feature model, with resulting gains in verification time. Similar approaches have been developed for real-time SPLs [39], for symbolic model checking [40], and for probabilistic model checking [41], among others [42].