Modelio API audit services provide a programmatic access to Modelio audit functions.
Modelio' audit permanently checks the changes in the model, whether these changes are carried out by a end-user or by a program (module). The performed controls are of two kind:
- core controls
- audit rules
Core controls are checked by Modelio for each batch of modifications of the model (See Transactions) and before the changes are committed. The role of the core controls is to protect the Modelio core implementation from errors that could lead to severe defects in the model (including crashing in the worst cases). The core controls cannot be disabled or customized. They are run synchronously in any case prior to committing any changes in the model.
Audit rules check the model against UML rules to help designing a well-formed model. Some audit rules produce errors report while some others produce warnings or simple tips. Audit rules are run asynchronously after some changes have been committed in a separate background thread. An Audit rule cannot cancel or prevent a model change even if this change is breaking this rule. The rule can only produce a diagnostic in the audit view. For more information, please see the audit rule list.
Performance considerations The core controls are run synchronously with the changes made in the model thereby possibly slowing down the execution of the changes. This is why core controls have been limited to detecting dangerous situations for the tool. Audit rules are far more detailed and accurate as they try to control model correctness against UML design rules. This can be costly and this is why audit rules checks are run asynchronously in a separate thread. Furthermore, to reduce computation costs, only those audit rules that are relevant for the model changes that occurred are fired by Modelio (this is currently done by analysing ‘what’ has been modified in the transaction). The combination of these two approaches ensures a reactive tool to the end-user.
The audit service allows for firing either core controls or audit rules checking on a particular element:
- the audit service interface is
IAuditServiceinstance can be obtained from the
IModuleContextof the module via
Audit of a model element¶
audit() method of
IAuditService can be called to fire the audit rules on a particular element.
1... 2IAuditService auditService = myModule.getModuleContext().getModelioServices().getAuditService(); 3... 4// The model element to check 5Element aModelElement = ...; 6 7// Audit the model element 8auditService.audit(aModelElement); 9 10...
The code (line 8) is straightforward: just call the audit method while passing it aModelElement, the element to audit. The audit method will perform the following operations on it:
- audit aModelElement itself as if all the possible changes have been made on it, ie firing all the applicable rules for this element
- audit all the model elements that are owned by aModelElement (ie its children in the explorer)
- and proceed recursively!
Imagine that you are calling the
audit() method on the project root, then your complete model will be audited for all the defined rules. Be sure that this is what you really need as this task might require a significant amount of time and resources…
Audit diagnostics are displayed in the Audit View of Modelio.
Check a model element (core controls)¶
check() method of
IAuditService can be called to fire core controls on a particular element.
1... 2IAuditService auditService = myModule.getModuleContext().getModelioServices().getAuditService(); 3... 4// The model element to check 5Element aModelElement = ...; 6 7// Check the model element 8boolean ok = auditService.check(aModelElement); 9 10...
The code (line 8) is straightforward: just call the audit method while passing it aModelElement, the element to control.
check() method will only check aModelElement itself, returning
true is the check is successful,
false otherwise. The controls are carried out synchronously.
As core controls are always carried out by Modelio when committing a transaction, rollbacking the transaction in case of failure, calling the check() method outside any transaction will always control a correct model and return
check() method has only interest within a transaction to control the state of the model before committing the transaction.
check() remains seldom in modules, most of the time modules use the