Legacy code, that is to say code from prior to your Model-Based Design environment can either act like an eagle allowing you to soar higher, or an albatross, a weight around your neck. Like the ships crew, think twice on your code and what you shoot for.
Migrate or encapsulate?
The decision on how to treat existing code is predicated on a series of questions.
- In the current form, is it performing all the required functions? If the code (as is) is complete, then consider calling it in the “as is” fashion.
- Dose the code need to be expanded or changed? If major changes are anticipated then migration to the Model-Based Design environment should be considered.
- Is the code encapsulated? If the code is not well encapsulated then calling it from an external environment will difficult. The existing code should be refactored into smaller portions and then re-evaluated.
- Dose the code perform functions not well suited for the Model-Based Design environment? There are some functions, such as device drivers that are best written in textual languages.
En-cap-so-early…
If the decision is made to bring existing legacy code into the Model-Based Design environment then efforts should be made to do this as early in the development process as possible to facilitate the testing of the encapsulated code. There are 3 types of tests that should be performed.
- Simulation based tests: Does the legacy code provide meaningful data during simulation?
- Code generation: Is the call to the legacy code correct in the generated code?
- Encapsulation: Is the legacy code fully encapsulated, or does it require additional legacy code? Often this is an iterative process to pair down to the minimum code.
Simulation time stubs
In some cases the legacy code is collecting data from outside of the system e.g., in the cases where the code is for hardware or communication. When testing the code there are two options, static and dynamic “stubbing.”
In a static stub scenario, the return value(s) from the legacy code are set to a valid value that the code could provide.
In the dynamic stubbing scenario a model of the external code is created to simulate the values that the code could provide. To fully exercise the system the simulated code should provide not only expected values but potential error values which the system could produce.
Making the call
There are multiple ways that legacy code can be called from within the Model-Based Design environment. My current recommendation is to use the coder.ceval methodology.