Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Eclipse 4diacWiki/Development/Detecting Model Inconsistencies in 4diac Models with OCL"

(Created page with "Overview page of GSoC 2020 Project")
 
(Init)
Line 1: Line 1:
Overview page of GSoC 2020 Project
+
'''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.
 +
 
 +
== Milestones ==
 +
=== Requirement specification ===
 +
* Precise and traceable requirement list for rules which should be validated on the Ecore models
 +
* Assigning the requirements to OCL constraints to facilitate traceability
 +
* OCL constraint types: invariant, pre- and postcondition, derived element, operation contracts
 +
* Format: Table format? Columns: ID, Name, Description, Contraint type, Context
 +
 
 +
{| border="1" cellpadding="5" cellspacing="0" align="center"
 +
|+ '''Requirements'''
 +
|-
 +
! style="background: #CEF2CE;" width="200"  align="center"| ID
 +
! style="background: #CEF2CE;" width="200"  align="center"| Name
 +
! style="background: #CEF2CE;" width="400"  align="center"| Description
 +
! style="background: #CEF2CE;" width="200"  align="center"| Constraint type
 +
! style="background: #CEF2CE;" width="200"  align="center"| Context
 +
|-
 +
! style="background: #FFFFFF;" width="200"  align="center"| 1
 +
! style="background: #FFFFFF;" width="200"  align="center"| DTMustHaveValue
 +
! style="background: #FFFFFF;" width="400"  align="center"| Check if DT is null 
 +
! style="background: #FFFFFF;" width="200"  align="center"| Invariant
 +
! style="background: #FFFFFF;" width="200"  align="center"| VarDeclarationImpl
 +
|}
 +
 
 +
=== Improving 4diac Ecore models ===
 +
* Adding new elements (e.g. classes and operations) to the Ecore models to facilitate the introduction of OCL constraints
 +
* Making suggestions for improvements on the Ecore models
 +
 
 +
=== Validity view for displaying validation results ===
 +
* Displaying the violated OCL constraints and the problematic model elements in a user-friendly way
 +
* Modal window? Something like the errors and warning view? Customizing built-in OCL errors view?
 +
* 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

Revision as of 05:08, 25 May 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.

Milestones

Requirement specification

  • Precise and traceable requirement list for rules which should be validated on the Ecore models
  • Assigning the requirements to OCL constraints to facilitate traceability
  • OCL constraint types: invariant, pre- and postcondition, derived element, operation contracts
  • Format: Table format? Columns: ID, Name, Description, Contraint type, Context
Requirements
ID Name Description Constraint type Context
1 DTMustHaveValue Check if DT is null Invariant VarDeclarationImpl

Improving 4diac Ecore models

  • Adding new elements (e.g. classes and operations) to the Ecore models to facilitate the introduction of OCL constraints
  • Making suggestions for improvements on the Ecore models

Validity view for displaying validation results

  • Displaying the violated OCL constraints and the problematic model elements in a user-friendly way
  • Modal window? Something like the errors and warning view? Customizing built-in OCL errors view?
  • 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

Back to the top