Deprecating Components
When managing a Distributed MBD project, it is important to properly handle the churn as components evolve during the lifecycle of the project. A significant part of this is deprecating design elements that are supplanted by later versions, or are no longer a part of the project.
Any time the design is updated, elements of the project will be changed, and managing the outdated parts will be necessary any time the project is updated.
Component Versioning
Component Split
Design Update
- A mix of old and new components will probably not be compatible with each other
- The team should work on a common set of components, so that their results are consistent, or at least comparable.
- Just like any software development, you want to avoid working on older versions of your software. Obviously, there are exceptions, e.g., if you are delivering your integrated simulation as a product, you will need to support older versions that have been delivered.
- When different participants are using different versions of components, you should usually avoid any analysis that combines the results from the different versions. An exception to this would be an explicit comparison of different versions, such as comparing improvements from version to version.
As I discussed in my previous article, an update can be structural change that is a new configuration of the existing components:
SystemBlend™
SystemBlend’s publishing and versioning facility makes it very easy to update components and deprecate outdated design elements.
In the SystemDesigner application, updating and managing component definitions is quite easy:
In the Client/Server variant of SystemBlend™, the project manager uses the management console to deprecate component implementations:
In the IntegrationMaster application, creating and saving different simulation configurations is straight-forward:
Other Articles in this Series:
- Part 1: Project Launch
- Part 2: Updating Components
- Part 3: Adding Components
- Part 4: Splitting Components
- Part 5: Replacing Components
- Part 6: Component Delivery
- Part 7: Imprecise ICDs
- Part 8: Misinterpreted ICDs
- Part 9: Naming Collisions
- Part 10: Simulation Parameters
- Part 11: Simulator Configuration
- Part 12: Location Independence
- Part 13: Shared Parameters
- Part 14: Data Capture
- Part 15: Architecture Updates
- Part 16: Deprecating Components
- Part 17: Project End-of-Life
Note: This post has been updated with links to other posts in the series