Packages | Classes | Enumerations

Package de.fraunhofer.isst.eastadl.featuremodeling

Packages

package  impl
package  presentation
package  provider
package  tests
package  util

Classes

interface  BindingTime
interface  Feature
interface  FeatureConstraint
interface  FeatureGroup
interface  FeatureLink
interface  FeatureModel
interface  FeaturemodelingFactory
interface  FeaturemodelingPackage
interface  FeatureTreeNode

Enumerations

enum  BindingTimeKind {
  CODEGENERATIONTIME = (0, "codegenerationtime", "codegenerationtime"), LINKTIME = (1, "linktime", "linktime"), POSTBUILD = (2, "postbuild", "postbuild"), PRECOMPILETIME = (3, "precompiletime", "precompiletime"), RUNTIME = (4, "runtime", "runtime"),
  SYSTEMDESIGNTIME = (5, "systemdesigntime", "systemdesigntime")
}
enum  VariabilityDependencyKind {
  CUSTOM = (0, "custom", "custom"), IMPEDES = (1, "impedes", "impedes"), MANDATORYALTERNATIVE = (2, "mandatoryalternative", "mandatoryalternative"), NEEDS = (3, "needs", "needs"), OPTIONALALTERNATIVE = (4, "optionalalternative", "optionalalternative"),
  SUGGESTS = (5, "suggests", "suggests")
}

Detailed Description

<copyright> </copyright>

$Id$


Enumeration Type Documentation

BindingTimeKind (from FeatureModeling) «enumeration»

Generalizations
None

Description
BindingTimeKind represents the set of possible binding times.

Enumeration Literals

  • codeGenerationTime
    Variability will be bound during code generation.
    From AUTOSAR:
    * Coding by hand, based on requirements document.
    * Tool based code generation, e.g. from a model.
    * The model may contain variants.
    * Only code for the selected variant(s) is actually generated.
  • linkTime
    Variability will be bound during linking.
    From AUTOSAR:
    Configure what is included in object code, and what is omitted
    Based on which variant(s) are selected
    E.g. for modules that are delivered as object code (as opposed to those that are delivered as source code)
  • postBuild
    Variability will be bound at certain occasions after shipment, for example when the vehicle is in a workshop.
  • preCompileTime
    Variability will be bound during or immediately prior to code compilation.
    From AUTOSAR:
    This is typically the C-Preprocessor. Exclude parts of the code from the compilation process, e.g., because they are not required for the selected variant, because they are incompatible with the selected variant, because they require resources that are not present in the selected variant. Object code is only generated for the selected variant(s). The code that is excluded at this stage will not be available at later stages.
  • runtime
    Variability will be bound by the customer after shipment by way of vehicle configuration.
    Variability with such a late binding time can also be seen as a special functionality of the system which is not documented as variability at all. However, it is sometimes advantageous to represent such cases as variability in order to be able to seamlessly include them in the overall variability management activities.
  • systemDesignTime
    Variability will be bound during development of the electrical/electronic system.
    From AUTOSAR:
    * Designing the VFB.
    * Software Component types (portinterfaces).
    * SWC Prototypes and the Connections between SWCprototypes.
    * Designing the Topology
    * ECUs and interconnecting Networks
    * Designing the Communication Matrix and Data Mapping

Associations
No additional associations

Constraints
No additional constraints

Semantics
-

Author:
dprenzel
Enumerator:
CODEGENERATIONTIME 

The 'Codegenerationtime' literal object.

Variability will be bound during code generation.
From AUTOSAR:
* Coding by hand, based on requirements document.
* Tool based code generation, e.g. from a model.
* The model may contain variants.
* Only code for the selected variant(s) is actually generated.

See also:
CODEGENERATIONTIME_VALUE
LINKTIME 

The 'Linktime' literal object.

Variability will be bound during linking.
From AUTOSAR:
Configure what is included in object code, and what is omitted
Based on which variant(s) are selected
E.g. for modules that are delivered as object code (as opposed to those that are delivered as source code)

See also:
LINKTIME_VALUE
POSTBUILD 

The 'Postbuild' literal object.

Variability will be bound at certain occasions after shipment, for example when the vehicle is in a workshop.

See also:
POSTBUILD_VALUE
PRECOMPILETIME 

The 'Precompiletime' literal object.

Variability will be bound during or immediately prior to code compilation.
From AUTOSAR:
This is typically the C-Preprocessor. Exclude parts of the code from the compilation process, e.g., because they are not required for the selected variant, because they are incompatible with the selected variant, because they require resources that are not present in the selected variant. Object code is only generated for the selected variant(s). The code that is excluded at this stage will not be available at later stages.

See also:
PRECOMPILETIME_VALUE
RUNTIME 

The 'Runtime' literal object.

Variability will be bound by the customer after shipment by way of vehicle configuration.
Variability with such a late binding time can also be seen as a special functionality of the system which is not documented as variability at all. However, it is sometimes advantageous to represent such cases as variability in order to be able to seamlessly include them in the overall variability management activities.

See also:
RUNTIME_VALUE
SYSTEMDESIGNTIME 

The 'Systemdesigntime' literal object.

Variability will be bound during development of the electrical/electronic system.
From AUTOSAR:
* Designing the VFB.
* Software Component types (portinterfaces).
* SWC Prototypes and the Connections between SWCprototypes.
* Designing the Topology
* ECUs and interconnecting Networks
* Designing the Communication Matrix and Data Mapping

See also:
SYSTEMDESIGNTIME_VALUE

VariabilityDependencyKind (from FeatureModeling) «enumeration»

Generalizations
None

Description
This enumeration encapsulates the available types of constraints that can be applied to a FeatureLink or VariationGroup (the latter is applicable only if the variability extension is used).

Enumeration Literals

  • custom
    When used in a FeatureLink: the attribute customType in the FeatureLink defines the custom feature link type as explained there.
    When used in a VariationGroup: this kind states that the dependency between the elements denoted by association variableElement of the VariationGroup will be defined by a logical expression in attribute 'constraint' of the VariationGroup.
  • impedes
    Weak from of "excludes".
    When used in a FeatureLink: the FeatureLink's start feature S and its end feature E must usually(!) not be selected in a single configuration. You can select S together with E but you should have a good reason to do so. Always bidirectional. When used in a VariationGroup: accordingly as above.
  • mandatoryAlternative
    When used in a FeatureLink: either the FeatureLink's start feature S or its end feature E must be selected in any configuration: S xor E. Always bidirectional. When used in a VariationGroup: this kind states that exactly(!) one element of the elements denoted by association variableElement of the VariationGroup must be selected in any valid final system configuration.
  • needs
    When used in a FeatureLink: if the FeatureLink's start feature S is selected, then also its end feature E must be selected: not (S and not E). Always unidirectional.
    When used in a VariationGroup: assuming the ordered association variableElement in meta-class VariationGroup refers to elements VE1, VE2, ..., VEn, this kind states that VE1 requires (i.e. may not appear without) all other elements VE2, VE3, ..., VEn.
  • optionalAlternative
    When used in a FeatureLink: the FeatureLink's start feature S and end feature E are incompatible and must never be both selected in a single configuration: not (S and E). Always bidirectional.
    When used in a VariationGroup: this kind states that at most(!) one element of the elements denoted by association variableElement of the VariationGroup must be selected in any valid final system configuration.
  • suggests
    Weak form of "needs".
    When used in a FeatureLink: if the FeatureLink's start feature S is selected, then usually(!) also its end feature E must be selected. You can select S without E but you should have a good reason to do so. Always unidirectional.
    When used in a VariationGroup: accordingly as above.

Associations
No additional associations

Constraints
No additional constraints

Semantics
Predefined kinds of constraints that can be associated to a FeatureLink or VariationGroup.

Author:
dprenzel
Enumerator:
CUSTOM 

The 'Custom' literal object.

When used in a FeatureLink: the attribute customType in the FeatureLink defines the custom feature link type as explained there.
When used in a VariationGroup: this kind states that the dependency between the elements denoted by association variableElement of the VariationGroup will be defined by a logical expression in attribute 'constraint' of the VariationGroup.

See also:
CUSTOM_VALUE
IMPEDES 

The 'Impedes' literal object.

Weak from of "excludes".
When used in a FeatureLink: the FeatureLink's start feature S and its end feature E must usually(!) not be selected in a single configuration. You can select S together with E but you should have a good reason to do so. Always bidirectional. When used in a VariationGroup: accordingly as above.

See also:
IMPEDES_VALUE
MANDATORYALTERNATIVE 

The 'Mandatoryalternative' literal object.

When used in a FeatureLink: either the FeatureLink's start feature S or its end feature E must be selected in any configuration: S xor E. Always bidirectional. When used in a VariationGroup: this kind states that exactly(!) one element of the elements denoted by association variableElement of the VariationGroup must be selected in any valid final system configuration.

See also:
MANDATORYALTERNATIVE_VALUE
NEEDS 

The 'Needs' literal object.

When used in a FeatureLink: if the FeatureLink's start feature S is selected, then also its end feature E must be selected: not (S and not E). Always unidirectional.
When used in a VariationGroup: assuming the ordered association variableElement in meta-class VariationGroup refers to elements VE1, VE2, ..., VEn, this kind states that VE1 requires (i.e. may not appear without) all other elements VE2, VE3, ..., VEn.

See also:
NEEDS_VALUE
OPTIONALALTERNATIVE 

The 'Optionalalternative' literal object.

When used in a FeatureLink: the FeatureLink's start feature S and end feature E are incompatible and must never be both selected in a single configuration: not (S and E). Always bidirectional.
When used in a VariationGroup: this kind states that at most(!) one element of the elements denoted by association variableElement of the VariationGroup must be selected in any valid final system configuration.

See also:
OPTIONALALTERNATIVE_VALUE
SUGGESTS 

The 'Suggests' literal object.

Weak form of "needs".
When used in a FeatureLink: if the FeatureLink's start feature S is selected, then usually(!) also its end feature E must be selected. You can select S without E but you should have a good reason to do so. Always unidirectional.
When used in a VariationGroup: accordingly as above.

See also:
SUGGESTS_VALUE