Blog entry by Phil Martin
There is a sense of calmness when you look at a VC model and it looks organised and structured. I get to see various models in various industries and businesses. Often it may be to troubleshoot a problem or as a review. In either case, a good indication of how well the troubleshooting occurs, or the ease of review of the model, it comes down to two main criteria.
- Is the model well structured
- Is good naming in place
Firstly - notice the structure. I use Constraints to be my primary modelling technique. Secondly, I then use procedures if II need to. Each procedure has a purpose, so I can find the one I need easily.
This model only has one constraint net, however, many models will have a few. They are great to organise constraints by a purpose.
Notice the naming. I have prefixed firstly with RT_ as the system used has other data so this allows me to segregate more easily. On most projects, I do not use a prefix like that as it is not necessary, but I use this convention.
- CN_ Constraint Net
- CS_ Constraint
- PR_ Procedure
- SC_ Selection Condition
- PC_ Precondition
- N300_ Type 300 used in the class hierarchy (not assigned to the material)
- M300_ Type 300 assigned to a material master
- S200_ Type 200 used as a selector class
- S300_ Type 300 used as a selector class
- Structure and naming make it easier to understand the model.
- Good naming conventions guide modellers to use good structure and approaches.
- Maintenance is easier, and new members to the team can quickly learn the design.
- Good for wildcard searches in lists or ALE
- Can see the purpose of the object
I hope this is useful. Our online training course VC Essentials follows these principles, in conjunction with a modelling framework to assist with the translation of requirements to a solution.