Skip to main content
Jump to: navigation, search

ETrice/GSoC/2013/Error Markers and Quick Fixes in State Chart Diagrams

< ETrice‎ | GSoC/2013
Revision as of 05:40, 20 April 2013 by Hrr.protos.de (Talk | contribs) (Q.6. What does the current idea adds?)

Basic Understanding of the Project Idea

Q.1. What is ROOM?

ROOM (Real time Object Modelling) is both an object-oriented modelling language and a development method specifically designed for dealing with large distributed real-time embedded software systems characterized by event-driven or, reactive behavior. It supports automatic code generation to ensure reliability and increase productivity.

Q.2. What is eTrice?

eTrice is a project under Eclipse Model Development Tools (MDT) which provides an implementation of the ROOM modelling language in the following ways:

  • It provides a textual editor (made in Xtext) for defining ROOM models in textual from.
  • It provides graphical editors (made in Graphiti) for graphically editing the structure and behavior (i.e. state charts) parts of the actors involved in the model. These diagrams just contain layout information and any changes made in the graphical editor are reflected in the textual model.
  • It provides code generators for the ROOM model in a variety of target languages like Java, C (ANSI-C), C++(under development).
  • It provides Runtimes which give basic infrastructure like messaging and debug support.

Q.3. What problem are we trying to address?

While making a complex ROOM State Chart Diagram for an actor in the eTrice behavior graphical editor, the user might end up in an incomplete or invalid state machine, for example, the state machine might have some unconnected parts (or) their might be some unhandled incoming messages. The user will only come to know about these problems at the time of executing the model and depending on the error, it could be quiet difficult to identify the root cause which invalidates the model.

Q.4. What solution could be provided?

To address the above problem, there is a need to provide validation of the State Chart Diagram at the time of editing the model itself, i.e Extended Model Validation.

  • The error identified with such a validation could be reported to the user by means of an error markers.
  • Depending upon this validation and the error generated , the user could be provided with some kind of proposals for correcting the error, the so-called quick fixes for the error.
  • Also depending upon the port & protocol interface of an actor, info markers regarding the valid messages which could be send, and moreover proposals for generating a valid state graph (states and transitions) could be provided (similar to content assist).

Q.5. What already exists?

To support the extended model validation, there exits an option to equip the protocols with semantic description defining the allowed message replies for each incoming message, the so called legal execution trees. Given these legal execution trees, an abstract state machine execution could be performed.

In the current scenario, this abstract state machine execution results in creation of warning markers in the textual model whenever a transition trigger doesn't catch a message which it should catch. Also info markers are generated at positions where a certain message is valid to send.

Q.6. What does the current idea adds?

Though the warning markers and info markers are present in the textual editor, these are not depicted in the behavior graphical editor, which is indeed the easiest and most intuitive way of editing the diagrams. As such this project aims at proving these results of validation in the diagrams of the behavior graphical editor.

Following things could be done in this regards :

  • Provide visual feedback for warning in the diagrams.
  • Provide Visual feedback for infos in the diagrams.
  • Provide a mechanism to pick from a list of proposals to :
    • correct the errors : quick fix.
    • implement the info : content assist.
  • Also, the graphical editor could be linked with the eclipse problems view.
    • So, if the user double clicks on the a warning in the problems view (corresponding to extended model validation), then the corresponding problematic state/transition will be focused.
    • Also, a mechanism for directly invoking the quick fix from the problems view can be provided.

Back to the top