# Union Models for Model Families: Efficient Reasoning over Space and Time
## 1 Introduction  
Model-based Software Engineering (MBSE) is a software engineering paradigm that endorses the use of models as first-class artifacts [1]. A model can be defined with a domain-specific modeling language (DSML) [2], which provides modeling primitives to capture the semantics of a specific application domain (such as web-based languages) or can be defined using a general-purpose modeling language (such as the UML). The main goal of MBSE is to enhance the development, maintenance, and evolution of complex software systems by raising the level of abstraction from source code to models. In particular, the use of DSMLs allows developers to focus on their essential tasks while the recurring engineering tasks are lifted to higher abstraction levels and automatically generated by transformations specified by domain experts [3]. The use of the MBSE paradigm is beneficial because it allows engineers to focus on the product to be developed and on generic and reusable assets that express problems and solutions. Other measured or claimed benefits of MBSE include better communication, effectiveness, and quality compared to pure code-oriented approaches [4, 5]. In MBSE, models expressed using any modeling language often undergo continuous evolution during their lifecycles. For example, such evolution can occur when new requirements are added or existing requirements are changed as engineers gain better understanding of the domain to be modeled. Models can evolve over _time_, resulting in a family of related models, which we refer to as a _model family_, with differences and similaritiesbetween family members. Another common source of model families is found in (software) product lines, where different configurations of a product can exist simultaneously (i.e., in the same _space_ dimension) for different customers without necessarily being caused by evolution over time. Model families can result from having several alternatives due to design-time uncertainty or uncertainty at other stages of the development process. In such cases, all models need to exist together (as a model family) to tolerate a certain level of uncertainty until decisions absolutely need to be made [6]. Finally, a model family can appear as a result of _both_ evolution over time and variation over space, such in the case of a set of software/product configurations that evolve over time [7]. The phenomenon of model families can be observed in several domains, including the _regulatory domain_, where regulations evolve over time and have variations (e.g., for different regulated parties or different versions of regulations) that need to be modeled using slightly different individual models, resulting in a _family_ of related regulatory models [8; 9]. In regulatory domains it is usually desirable to analyze models, for instance, for compliance assessment by regulators. However, the existence of several versions/variations of models makes it cumbersome and inefficient to analyze and reason about these models one at a time. This challenge was observed in practice through our previous experience in modeling and analyzing safety regulations at Transport Canada; the number of models in a model family can be very large due to multiple versions and variations that nonetheless share many elements in common. Exploiting this redundancy during analysis has the potential to reduce the effort and time required for analysis. This paper is based on the first author's PhD thesis [10], and proposes _union models_ as first-class generic artifacts to: (1) support the representation of model families (for time and space dimensions) using one generic model; (2) achieve performance gains during analysis of model families _all at once_, compared to analysis of individual models, _one model at a time_; and (3) support types of analyses that are more easily feasible with union models compared with individual models. The use of union models is challenging and non-trivial. At the _model level_, the challenges stem mainly from the following requirements:  
**Req.