Model Validations (workshop)

[raulmonti]

I will enumerate here model validations ideas I come up with while modeling:

• Data types validations
  • all fields have a proper name
  • all fields have a type
  • field names are unique
  • unused datatype (WARNING)
  • unused datatype field (WARNING)
• Guards validations
  • currently any record to record comparison type-passes, no matter the type of the record. You can actually compare anything you want, for instance a record against an integer.
• Task updates
  • Reference to RUN task outputs should only be mentioned in the reference section. Unless we want to unify concrete, reference and maybe even symbolic in a single update and anyways resolve the linking. Current issue is that if you use a reference to a RUN task output in the concrete update, then it is not linked.
• Other validations
  • when you omit a field in a token initialization and you want to fetch that field later, maybe when assigning that token to another, snakes fails. We need to think what to do here. Do we want a validation? do we want to allow the users to omit fields and overcome the issue in the CPN code?

[dbera]

• Dangling data references (are all issues solved by one-button validation?)
• Mixing concrete and symbolic data field assignment expressions
• Missing fields in data instance constructors
• Detect deadlocks and provide trace
• Handle empty tspec files
• Allow run steps without compose

[kontrag]

• Detect deadlocks and provide trace
  Add a "finish" condition (e.g., an end event) and check if there's any deadlock before that.

• Handle empty tspec files
  Validation for non-existent Run tasks in the traces (combined with the "deadlock" validation)

• Allow run steps without compose
  To be done as part of refactoring (Deb/Diego)

[dbera]

• Name of global model should not have underscores.
• Run step must always have step type.
• A system block may have many RUN steps but they all must be of the same step-type.
• Variables start with lower case and Types with upper case. TODO. Investigate name collision issue in BPMN4S to PSpec

[kontrag]

• Name of global model should not have underscores.
  Only alphanumerical and space is allowed, and not starting with a digit

• Run step must always have step type.
• A system block may have many RUN steps but they all must be of the same step-type.
• Variables start with lower case and Types with upper case. TODO. Investigate name collision issue in BPMN4S to PSpec

[dbera]

The suppression feature (suppress output variables of tasks/fields of record type) is particularly important to link data correctly between compose and run steps. If not done properly especially if a compose step is doing a persistent read from various data stores (where data is being produced by another run step or another compose step), leads to extra data in output of compose steps. As a consequence unwanted chaining of compose and run steps will occur leading to ambiguous multiple "consumes-from-step", breaking the transformation chain. So it is necessary to take into account "suppress" variables to do the linking properly in the generated abstract tspec.

[kontrag]

I will enumerate here model validations ideas I come up with while modeling:

• Data types validations

  • all fields have a proper name
  • all fields have a type
  • field names are unique
  • unused datatype (WARNING)
  • unused datatype field (WARNING)
    All above to be added on one-button model validation (in next sprint)

• Guards validations

  • currently any record to record comparison type-passes, no matter the type of the record. You can actually compare anything you want, for instance a record against an integer.
    Implement on PSpec level

• Task updates

  • Reference to RUN task outputs should only be mentioned in the reference section. Unless we want to unify concrete, reference and maybe even symbolic in a single update and anyways resolve the linking. Current issue is that if you use a reference to a RUN task output in the concrete update, then it is not linked.
    To be solved (Be able to mark record fields in the type def. as symbolic and enforce throughout the model)
  • Update expressions should only assign the involved output (no input or other output).

• Other validations

  • when you omit a field in a token initialization and you want to fetch that field later, maybe when assigning that token to another, snakes fails. We need to think what to do here. Do we want a validation? do we want to allow the users to omit fields and overcome the issue in the CPN code?
    To be addressed: Enforce 2 types of assignments: Through constructors or through variable copy

[samira-shirzadeh]

When there is an error in the PSpec file, Python files are still generated—even though they may be invalid. For example, if the BPMN model name doesn't match the expected Rule_ID format, the Python files and the tspec_abstract folder are still created despite the error.

[dbera]

Chaining of references: LHS and RHS matching Validation. (Elaborate. This is important. )