Notice: this Wiki will be going read only early in 2024 and edits will no longer be 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"
(Added list of constraints) |
|||
| Line 25: | Line 25: | ||
! style="background: #FFFFFF;" width="200" align="center"| ECState | ! style="background: #FFFFFF;" width="200" align="center"| ECState | ||
! style="background: #FFFFFF;" width="200" align="center"| UnreachableState | ! style="background: #FFFFFF;" width="200" align="center"| UnreachableState | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Terminal states | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECC | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| States that are reachable, but which do not have any outgoing EC transitions | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Error | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECState | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| TerminalState | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Unused event inputs | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECC | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| Event inputs of the FB type containing the ECC that are not used in any EC transitions. | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Warning | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECC | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| UnusedEventInput | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Unused event outputs | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECC | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| Event outputs of the FB type containing the ECC that are not used in any EC transitions. | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Warning | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECC | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| UnusedEventOutput | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Self-cycle | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECC | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| 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. | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Warning | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECTransition | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| SelfCycleMustBeGatedByEvent | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Guard-only cycle | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECC | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| 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). | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Warning | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECTransition | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| GuardOnlyCycle | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Transitions with lower priorty than one (Dead Transitions | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECC | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| Transitions with lower priority than the 1 transition condition will never be taken regardless they are with pure data-driven conditions or event conditions. | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Error | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECTransition | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| TransitionLowerThanOne | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Transitions with higher priorty than one (Dead Transitions | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECC | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| Transitions with lower priority than the 1 transition condition will never be taken regardless they are with pure data-driven conditions or event conditions. | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Error | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECTransition | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| TransitionHigherThanOne | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Dead states | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECC | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| States (except start state) to which a path cannot be found from the EC initial state by following the directed links | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Warning | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| ECState | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| DeadState | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Data Input Must Have Value | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| FB | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| States (except start state) to which a path cannot be found from the EC initial state by following the directed links | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Info | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| e.g. VarDeclaration | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Comment field must have a value | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| FB | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| Problem: FB is not commented good enough (it should be a warning) | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Info | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Write access on Inputs | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| FB | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| Checking the algorithms. Data inputs, checking whether the algorithm writes on it? | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Error | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Checking the literals: Checking the format of time values | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| FB | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| Checking the correctness of time values: The format should be T#[value][ms,s] ? (using regular expression in OCL) | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Error | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Copy pasting input variable as output and you do not rename it. How should it be a rule? (Naming issue) | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| FB | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| For example: Checking if you don't have an output variable DI (using With construct in ECore) | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Info | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| In resource networks if there is an event INIT it has to have a connection going in. (invoke the window before the deployment) | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Resource networks | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| INIT must be connected (Problem: Users tend to forget reconnecting FB-s, after deleting a particular FB) | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Error | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Event loops in FB networks | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| FB networks | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| 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. | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Not in OCL :) | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Error | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| If the particular input event is connected,then the associated data should be connected or configured. | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| FB | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Info | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Detecting Function blocks that have no event path to an input event. | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| FB network | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| Problem in big subapplications and in composite | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Possible with the closure in OCL? | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Error | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| E_RESTART can only be used in resources. | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Resources | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Info | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| No need to restart composite funciton blocks and subapplications | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Composite function blocks, Subapplications | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Warning | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
| + | |- | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Unreachable FB | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| FB | ||
| + | ! style="background: #FFFFFF;" width="400" align="center"| FBs (except start FB) which do not have any input event connections | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Invariant | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| Error | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| FB, FBType FBNetworkElement, FBNetwork | ||
| + | ! style="background: #FFFFFF;" width="200" align="center"| | ||
|} | |} | ||
Revision as of 06:47, 24 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
| 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
- Eclipse OCL project provides standalone usage to create and evaluate OCL constraints and queries in Java (We should choose this option for better maintainability? Advantage: It is easier to combine Java code with OCL constraints.)
- Besides OCL constraints, additional Java code may be required to implement certain requirements (e.g. detecting self-cycles in ECC)
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
- View:
- Validation Message Dialog?
- Something like the errors and warning view?
- Customizing built-in OCL Validation view?
- Extra feature: Highlighting the problematic model elements in the model editor
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.