1. When you open Rhapsody, it reads the properties in the read-only factory prp files in the $OMROOT/properties folder.
2. It then opens the site prp files in the same folder. The latter are user editable. Setting a property here will override the value set in the factory prp files. Care, however, is needed when sharing models as different users may have different site.prp files (unless you're pointing to a common OMROOT). As such, site prp customization may not be the best way.
3. Rhapsody then opens the project. A property set at the project level will override properties in the Site prp files, and so on; this is what we mean by the property hierarchy.
4. Next comes the profiles or settings. If a profile is ‘globally applied’ it will override the Project settings. If we don’t tick ‘Globally Applied’ then we can make the profile apply to only part of the project by establishing an «AppliedProfile» dependency.
5. At this stage we could still override the properties at a level lower than the project, e.g., at a package level or a diagram level. If you want to customize the code generation then this can also be done at Component/Configuration level. This help topic is pretty good.
This video illustrates the hierarchy in action:
The benefit of using profiles are that we can standardize the use of the same default properties across multiple projects. You can create your own profiles or settings (a setting is like a profile) be careful though, there’s no guarantee of order precedent here if you have multiple profiles. One guarantee you do have though, is that you need to customize Rhapsody properties if you want to harness the true power of MBSE for your project. In our training we provide a ready to use example of this.