Difference reports are a staple of software development, they allow you to quickly see what has changed. Model-Based Design, with its graphical environment, presents some unique issues in differencing; we will examine them with this post.
Differencing best practices
The following best practice hold regardless of the development environment
- Reasonable diffing cadence: Finding the difference between two objects is easy if the number of changes are small; however if large structural, or multiple-point changes have occurred difference operations become difficult if not impossible. Perform differencing operations when no more then 5% of the object has changed.
- Diff function changes / ignore visual changes: Visual changes, such as the use of indents in textual languages, or block placement in graphical, do not impact the behavior of the code. While these changes may violate modeling guidelines they should be ignored during the diff operations
- Include the authors: Have both the original author and updating person take part in the review for complex issues.
- Test after diffing: After performing the difference operations have been run the files should be run through their test suites to ensure that the changes did not have a negative impact.
Don’t judge a model by its cover
In text based languages changes in the text are it; with Model-Based development environments it is the combination of the
- Block connections: How the blocks are connected to each other determines execution order and data flow.
- Block parameters: How the block is parameterized determines the functionality of the block
- Model configuration: The model can have parameters that influence the behavior system beyond the data set by the blocks
It is possible to diff the underlying text files that define graphical models; at one point in time this was the only method that was possible. However, doing this presents multiple problems and should be avoided.
- Determining what is significant: The text representations often encode information into parameters / structures. Often it is not obvious what are significant changes versus cosmetic.
- Block changes: The text representation can have the same functionality “shifted” in the code to a new location depending on where it shows up in the model; however this is often not a functional change.
- Interpretation: When reviewing the text changes the reviewers then have to interpret what the text means.