FeatureModel denotes a model owning Features. The FeatureModel can be used to describe variability and commonality of a specified electrical/electronic system at any abstraction level in the SystemModel.<br/><br/>The FeatureModel can be used either to describe the variability within a particular Function or to describe the overall variability of a vehicle (cf. VehicleLevel). The FeatureModel describing internal variability of a FunctionType refers to the VehicleLevel by a «realizes» link (informative).<br/><br/>Note, however, that a FeatureModel per definition does not always have to define variability. If a feature model contains only mandatory features, then its purpose is completely unrelated to variability. The features in such a FeatureModel could serve, for example, as invariant "coarse-grained requirements". The most important example is the core technical feature model on vehicle level which is also used for SystemModels that do not contain any variability at all. However, most uses of feature models in EAST-ADL are primarily motivated by variability definition and management.<br/><br/>A public, local FeatureModel of an artifact element realizes a VehicleFeature of the VehicleLevel.<br/><br/><br/>Semantics:<br/>The FeatureModel has no specific semantics. Further subclasses of FeatureModel will add semantics appropriate to the concept they represent.<br/><br/><br/>Extension:<br/>Package<br/>
Name: productFeatureModel
This association points to zero or more feature models intended to be used on the vehicle level in addition to the core technical feature model (cf. association technicalFeatureModel in meta-class VehicleLevel).
Usually there will be the core technical feature model and one or more so-called "product feature models" on the vehicle level, which provide an orthogonal view on the core technical feature model tailored to a particular purpose, for example an end-customer feature model. However, there may be more and other use cases for feature models on vehicle level. More detailed treatment of this is beyond the scope of the language specification and can be found in the accompanying usage and methodology documentations.
Name: technicalFeatureModel
This association identifies the core technical feature model of the complete system. This has a special role as it defines all the features of the complete system on vehicle level. In addition to this feature model, there may be one or more so-called product feature models (cf. association productFeatureModel in meta-class Variability in the variability extension).
Usually there will be the core technical feature model and one or more so-called "product feature models" on vehicle level, which provide an orthogonal view on the core technical feature model tailored to a particular purpose, for example an end-customer feature model. However, there may be other use cases for feature models on vehicle level. More detailed treatment of this is beyond the scope of the language specification and can be found in the accompanying usage and methodology documentations.
Name: publicFeatureModel
The local feature model of the ConfigurableContainer.
PublicFeatureModel represents internal variability of a ConfigurableContainer. Thus it can be seen as being part of the public interface of a ConfigurableContainer.
Name: rootFeature
The root Features owned by the FeatureModel. Note that only root Features are directly contained in the model; non-root Features are contained in their parent Feature or parent FeatureGroup.
