Model Validation

Usage of Check-based Validation

The AMALTHEA validation can be triggered by right clicking a model element in the left Model Explorer View and choose in the context menu Validate – Check-based Validation.

All AMALTHEA sub elements of the chosen element are then included for the validation. In the next window the catalog appears allowing the selection of specific validation checks based on your selected model. Button “Select All” will select all listed validation checks for execution. Each entry of the catalog is called Category which may contain several validation checks (i.e. constraints). The simplest way is to define a 1:1 relationship between category and constraint.

If an error is found, it is shown in the Problems view of Eclipse. A simple double click on the error will lead you to the affected elements in the AMALTHEA model. Sphinx validation distinguishes between three error types: errors, warnings and info.

Available Validations

The plugin org.eclipse.app4mc.amalthea.validation contains several validators and constraints (i.e. checks) for various model types of AMALTHEA.

Basic Check Validator

Basic checks which cannot be assigned to a specific AMALTHEA model are summarized. Responsible implementation for this validation is the class org.eclipse.app4mc.amalthea.validation.checks.BasicCheckValidator.

Missing Referable Name
Checks the name of all objects that are instances of IReferable. The name is used to refer to objects in the AMALTHEA model, therefore missing names are handled as an error .

Duplicate Unique Name
Checks the unique name of all objects that are instances of IReferable. The unique name is used to refer to objects in the AMALTHEA model, therefore duplicates are handled as an error .

Undefined Unit
Checks all units: TimeUnit, FrequencyUnit, DataSizeUnit, DataRateUnit.
If the unit is undefined, it will be handled as an error .

Custom Property Duplicate Key
A validation to check all custom attributes of one element. If it contains duplicate key entries, it is treated as a warning .

Weibull Parameters
Checks the parameters in the Distribution of type WeibullEstimators. The parameters must not be equal to each other, if this is the case, it will be handled as an warning .

ConstraintsModel Check Validator

Responsible implementation for this validation is the class org.eclipse.app4mc.amalthea.validation.checks.ConstraintsModelCheckValidator.

EventChainsConstraint
Checks for the AMALTHEA constraints model if the EventChains are consistent regarding completeness (fully build chain) and correctness. Therefore each EventChain’s stimulus/response pair is checked if events are existent and linked properly to a complete chain. An event chain of type SubEventChain is checked for its “border” events fit to the stimulus and response event of the parent event chain. Cascades of sub events are processed recursively. A missing or wrong information in the event chain will be handled as an error .

MappingModel Check Validator

Responsible implementation for this validation is the class org.eclipse.app4mc.amalthea.validation.checks.MappingModelCheckValidator.

Process2Scheduler2CoreMappingConstraint
Checks for the entire AMALTHEA model instance if the mapping information are complete and correct between Software(SW) <-> Operating System(OS) <-> Software(SW) model. I.e. mapping relationship {Process(SW) to Scheduler(OS) to Core(HW)}. A missing mapping information (i.e. no Entity) or unmapped Processes will be handled as an error .

EventModel Check Validator

Responsible implementation for this validation is the class org.eclipse.app4mc.amalthea.validation.checks.EventModelCheckValidator.

to be extended

HardwareModel Check Validator

Responsible implementation for this validation is the class org.eclipse.app4mc.amalthea.validation.checks.HardwareModelCheckValidator.

to be extended