Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Eclipse 4diacWiki/Development/Detecting Model Inconsistencies in 4diac Models with OCL"
m |
|||
Line 217: | Line 217: | ||
* The constraint elements could be saved in .fbt files. Once loaded, they could be translated to OCL constraints and additional Java code. | * The constraint elements could be saved in .fbt files. Once loaded, they could be translated to OCL constraints and additional Java code. | ||
− | + | == Final report == | |
In this section, I give a brief overview of the current state of this project and a reference to all the code I wrote during the summer. | In this section, I give a brief overview of the current state of this project and a reference to all the code I wrote during the summer. | ||
Line 226: | Line 226: | ||
'''Application''': UnreachableFB, DataInputMustHaveValue, FBCommentFieldMustHaveValue, TimeFormat, BoolFormat, AssociatedDataMustBeConfigured | '''Application''': UnreachableFB, DataInputMustHaveValue, FBCommentFieldMustHaveValue, TimeFormat, BoolFormat, AssociatedDataMustBeConfigured | ||
− | At the beginning of the project, I implemented a simple dialog window for displaying the results of the violated constraints. | + | At the beginning of the project, I implemented a simple dialog window for displaying the results of the violated constraints. It was a preliminary prototype only for testing purposes. Later, we decided to improve the UI and use the Problems tab of Eclipse. The current implementation has several cool features: |
+ | * Displaying description, resource, path, location and severity(Error, Warning, Info) of the problem | ||
+ | * Better Error Marker support: When the user double clicks on one of the lines in the Problems View, the framework automatically selects the corresponding model element on which the constraint is violated. | ||
+ | * The automatic invocation of the OCL validation: When the user saves the currently edited model, the validation is automatically invoked. | ||
+ | |||
+ | ;Code | ||
+ | :* Add support for Eclipse Complete OCL documents [https://git.eclipse.org/r/c/4diac/org.eclipse.4diac.ide/+/165313/ Gerrit commit] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=564549 Bugzilla Bug] | ||
+ | :* Add ECC validation rules [https://git.eclipse.org/r/c/4diac/org.eclipse.4diac.ide/+/165720 Gerrit commit] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=564852 Bugzilla Bug] | ||
+ | :* Minor changes in ECC constraints [https://git.eclipse.org/r/c/4diac/org.eclipse.4diac.ide/+/166020 Gerrit commit] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=564852 Bugzilla Bug] | ||
+ | :* Add FB validation rules [https://git.eclipse.org/r/c/4diac/org.eclipse.4diac.ide/+/166415 Gerrit commit] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=565065 Bugzilla Bug] | ||
+ | :* Added NoneTransitionWithoutCondition [https://git.eclipse.org/r/c/4diac/org.eclipse.4diac.ide/+/166707 Gerrit commit] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=550559 Bugzilla Bug] | ||
+ | :* Improve infrastructure around OCL [https://git.eclipse.org/r/c/4diac/org.eclipse.4diac.ide/+/167238 Gerrit commit] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=565474 Bugzilla Bug] | ||
+ | :* Improve ECC validation [https://git.eclipse.org/r/c/4diac/org.eclipse.4diac.ide/+/168110 Gerrit commit] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=565474 Bugzilla Bug] | ||
+ | :* Automatic invocation of the OCL validation [https://git.eclipse.org/r/c/4diac/org.eclipse.4diac.ide/+/168111 Gerrit commit] [https://bugs.eclipse.org/bugs/show_bug.cgi?id=565474 Bugzilla Bug] |
Revision as of 03:02, 28 August 2020
Overview page of GSoC 2020 Project
The aim of this project is to develop OCL constraints and well-formedness rules to the metamodels of 4diac in order to improve the usability of the IDE.
Contents
Milestones
Requirement specification
- Requirements
- Precise and traceable requirement list for rules which should be validated on the Ecore models (ECC and Application level)
Name | Level | Description | Constraint type | Severity | Context(Ecore) | Constraint Name |
---|---|---|---|---|---|---|
Unreachable states | ECC | States (except start state) which do not have any input transitions | Invariant | Warning | ECState | UnreachableState |
Terminal states | ECC | States that are reachable, but which do not have any outgoing EC transitions | Invariant | Error | ECState | TerminalState |
Unused event inputs | ECC | Event inputs of the FB type containing the ECC that are not used in any EC transitions. | Invariant | Warning | ECC | UnusedEventInput |
Unused event outputs | ECC | Event outputs of the FB type containing the ECC that are not used in any EC transitions. | Invariant | Warning | ECC | UnusedEventOutput |
Self-cycle | ECC | A self-cycle exists when there is a transition from an EC action back to itself. Problem: the process that is executing the ECC may enter an infinite loop. | Invariant | Warning | ECTransition | SelfCycleMustBeGatedByEvent |
Guard-only cycle | ECC | A guard-only cycle is the general case of a self-cycle, where a path exists from an EC state, through other EC states and back to itself through a path consisting of transitions with guard-only conditions (i.e., transitions not containing an event). | Invariant | Warning | ECTransition | GuardOnlyCycle |
Transitions with lower priorty than one (Dead Transitions | ECC | Transitions with lower priority than the 1 transition condition will never be taken regardless they are with pure data-driven conditions or event conditions. | Invariant | Error | ECTransition | TransitionLowerThanOne |
Transitions with higher priorty than one (Dead Transitions | ECC | Transitions with lower priority than the 1 transition condition will never be taken regardless they are with pure data-driven conditions or event conditions. | Invariant | Error | ECTransition | TransitionHigherThanOne |
Dead states | ECC | States (except start state) to which a path cannot be found from the EC initial state by following the directed links | Invariant | Warning | ECState | DeadState |
Data Input Must Have Value | FB | States (except start state) to which a path cannot be found from the EC initial state by following the directed links | Invariant | Info | e.g. VarDeclaration | |
Comment field must have a value | FB | Problem: FB is not commented good enough (it should be a warning) | Invariant | Info | ||
Write access on Inputs | FB | Checking the algorithms. Data inputs, checking whether the algorithm writes on it? | Invariant | Error | ||
Checking the literals: Checking the format of time values | FB | Checking the correctness of time values: The format should be T#[value][ms,s] ? (using regular expression in OCL) | Invariant | Error | ||
Copy pasting input variable as output and you do not rename it. How should it be a rule? (Naming issue) | FB | For example: Checking if you don't have an output variable DI (using With construct in ECore) | Invariant | Info | ||
In resource networks if there is an event INIT it has to have a connection going in. (invoke the window before the deployment) | Resource networks | INIT must be connected (Problem: Users tend to forget reconnecting FB-s, after deleting a particular FB) | Invariant | Error | ||
Event loops in FB networks | FB networks | Checking event loops which block the system in FB networks. Very difficult, since we have to know what is inside the function block. OCL is not the right tool for this. | Not in OCL :) | Error | ||
If the particular input event is connected,then the associated data should be connected or configured. | FB | Invariant | Info | |||
Detecting Function blocks that have no event path to an input event. | FB network | Problem in big subapplications and in composite | Possible with the closure in OCL? | Error | ||
E_RESTART can only be used in resources. | Resources | Invariant | Info | |||
No need to restart composite funciton blocks and subapplications | Composite function blocks, Subapplications | Invariant | Warning | |||
Unreachable FB | FB | FBs (except start FB) which do not have any input event connections | Invariant | Error | FB, FBType FBNetworkElement, FBNetwork |
- Assigning the requirements to OCL constraints to facilitate traceability
- OCL constraints: Invariant, pre- and postcondition, derived element, operation body, initial value
- Two options:
- Using OCLinEcore
- CompleteOCL (We should choose this option for better maintainability? Advantage: It is easier to combine Java code with OCL constraints.)
- Decision: CompleteOCL
- Storing OCL constraints in separate OCL files and parse them
- Besides OCL constraints, additional Java code may be required to implement certain requirements
Improving 4diac Ecore models
- Adding new elements (e.g. classes and helper operations) to the Ecore models to facilitate the introduction of OCL constraints
- Making suggestions for improvements on the Ecore models (without side-effects!)
Validity view for displaying validation results
- Displaying the violated OCL constraints and the problematic model elements in a user-friendly way
- First prototype: Validation Message Dialog
- Decision: Eclipse Problems View using markers
- Highlighting the problematic model elements in the model editor (ECC)
- Automatic invocation of the OCL validation (onSave)
Implementing OCL constraints
- Developing the OCL constraints and well-formedness rules based upon the requirement list
- Testing the newly implemented features and constraints
Idea: Function Block Constraint Language (FBCL)
- How should we handle the constraints related to individual FB types?
- How should we handle the semantic issues of individual FB types?
- When creating a Function Block Type in 4diac IDE, users could specify constraints on the particular FB type using a declarative representation (not necessarily a textual DSL) or a graphical interface. e.g. something like MustHaveValue constraints or preventing loops on certain FB types)
- The constraint elements could be saved in .fbt files. Once loaded, they could be translated to OCL constraints and additional Java code.
Final report
In this section, I give a brief overview of the current state of this project and a reference to all the code I wrote during the summer.
By the end of my GSoC project, I created a set of OCL constraints at the ECC and Application level. Altogether, 17 constraints have been created:
ECC: SelfCycleMustBeGatedByEvent, TransitionLowerThanOne, TransitionHigherThanOne, UnreachableState, TerminalState, DeadState, UnusedEventInput, UnusedEventOutput, NoneTransitionWithoutCondition, GuardOnlyCycle
Application: UnreachableFB, DataInputMustHaveValue, FBCommentFieldMustHaveValue, TimeFormat, BoolFormat, AssociatedDataMustBeConfigured
At the beginning of the project, I implemented a simple dialog window for displaying the results of the violated constraints. It was a preliminary prototype only for testing purposes. Later, we decided to improve the UI and use the Problems tab of Eclipse. The current implementation has several cool features:
- Displaying description, resource, path, location and severity(Error, Warning, Info) of the problem
- Better Error Marker support: When the user double clicks on one of the lines in the Problems View, the framework automatically selects the corresponding model element on which the constraint is violated.
- The automatic invocation of the OCL validation: When the user saves the currently edited model, the validation is automatically invoked.
- Code
- Add support for Eclipse Complete OCL documents Gerrit commit Bugzilla Bug
- Add ECC validation rules Gerrit commit Bugzilla Bug
- Minor changes in ECC constraints Gerrit commit Bugzilla Bug
- Add FB validation rules Gerrit commit Bugzilla Bug
- Added NoneTransitionWithoutCondition Gerrit commit Bugzilla Bug
- Improve infrastructure around OCL Gerrit commit Bugzilla Bug
- Improve ECC validation Gerrit commit Bugzilla Bug
- Automatic invocation of the OCL validation Gerrit commit Bugzilla Bug