All PowerDesigner resource files contain a Profile category directly beneath root. A profile is a UML extension mechanism, which is used for extending a metamodel for a particular target.
Profiles are used in PowerDesigner for adding additional metadata to objects and creating new kinds of links between them, sub-dividing object types (via stereotypes and criteria), customizing symbols, menus, and forms, and modifying generation output. For example:
The Java 5.0 object language resource file - extends the Component metaclass via several levels of criteria to model various forms of EJBs.
The BPEL4WS 1.1 process language resource file - extends the Event metaclass through stereotypes to model Compensation, Fault, and Timer events.
The MSSQLSRV2005 DBMS resource file - uses stereotyped extended objects in order to model aggregates, assemblies, and other SQL Server-specific objects.
Add or sub-classify new kinds of objects:
Metaclasses (Profile) – to sub-classify objects.
Stereotypes (Profile) [for metaclasses and stereotypes only] – to sub-classify objects.
Criteria (Profile) – to evaluate conditions to sub-classify objects.
Extended Objects, Sub-Objects, and Links (Profile) – to create new kinds of objects.
Provide new ways of viewing connections between objects:
Add new properties to objects:
Extended Attributes (Profile) – to provide extra metadata.
Extended Collections and Compositions (Profile) – to enable manual linking between objects.
Calculated Collections (Profile) – to automate linking between objects.
Forms (Profile) – to display custom property tabs or dialog boxes.
Custom Symbols (Profile) – to help you visually distinguish objects.
Add constraints and validation rules to objects:
Custom Checks (Profile) – to provide data testing.
Event Handlers (Profile) – to invoke methods when triggered by an event.
Execute commands on objects:
Methods (Profile) – to be invoked by other profile extensions such as menus and form buttons (written in VBScript).
Menus (Profile) [for metaclasses and stereotypes only] – to customize PowerDesigner menus.
Generate objects in new ways:
Templates and Generated Files (Profile) – to customize generation.
Transformations and Transformation Profiles (Profile) – to automate changes to objects at generation or on demand.
You can review and edit the profile in a resource file by opening it in the Resource Editor and expanding the top-level Profile category. You can add extensions to a metaclass (a type of object, such as Class in an OOM or Table in a PDM), or to a stereotype or criterion, which has previously been defined on a metaclass:
In the example above:
Class is a metaclass. Metaclasses are drawn from the PowerDesigner metamodel, and always appear at the top level, directly beneath the Profile category
MyCriterion is a criterion that refines the Class metaclass. Those classes that meet the criterion can be presented and processed differently from other classes.
MyStereotype is a stereotype that refines the Class metaclass. Those classes that bear the MyStereotype stereotype can be presented and processed differently from other classes.
AnotherCriterion is a criterion that refines further those classes that bear the MyStereotype stereotype. Classes bearing the stereotype AND meeting the criterion can be presented and processed differently from those that merely bear the stereotype.
Extensions are inherited, so that any extensions made to a metaclass are available to its stereotyped children, and those that are subject to criteria.
Thus, in the example above, classes that bear the MyStereotype stereotype have available the Attribute_5 extended attribute, and those that bear this stereotype AND meet AnotherCriterion have Attribute_4 and Attribute_5 available.
Since you can attach several resource files to a model (for example, a target language and one or more extended model definitions) you can create conflicts, where multiple extensions with identical names (for example, two different stereotype definitions) are defined on the same metaclass in separate resource files. In case of such conflicts, the extended model definition extension usually prevails. When two XEMs are in conflict, priority is given to the one highest in the list.