A profile is supported by a package stereotyped profile, the main goal is to define stereotypes, themselves supported by classes stereotyped stereotype. A Stereotype has attributes producing properties on the element having this stereotype. Plug-outs can be associated to a stereotype to automatically call them when an element receive the stereotype or when the element was edited (the plug-outs are not called when the modifications are made through a plug-out). A profile can define standard classes, probably enumerations to type the stereotype's attributes.
When you stereotype an element you can choose to use a stereotype defined in a profile, or a non modeled stereotype (pure text).
When the set stereotype is defined in a profile, the associated properties (may be inherited) are automatically added to the element with the specified default value (may be empty), then the plug-out optionally associated to the setting of the stereotype is applied to the element receiving the stereotype. This is done after validating the new stereotype by validating the element edition through its dedicated dialog, so, if you want to modify the element's properties associated to its stereotype you have to edit the elements two times : one to set the stereotype, the second to set the properties to the desired values. Nothing is done when the stereotype is set through a plug-out.
When you unset or change the stereotype and it was a stereotype defined in a profile, the associated properties (may be inherited) are automatically removed. Nothing is done when the stereotype is modified through a plug-out.
By default the values of the stereotype properties for a stereotyped element are not shown in the diagrams, to show them through notes set the drawing setting show stereotype properties
A stereotypes defined in profile can be projected in stereotype known by a code generator by defining the projection through the generation settings, like for textual stereotypes.
Contrarily to some other modelers, you can modify profiles and stereotypes even when there are applied to elements, and stereotypes part of a profile are applicable immediately in the model where there are defined without asking for that explicitly.
A package-profile has some restrictions regarding to the standard packages :
the menus doesn't propose to add sub deployment view nor component view
the dialog doesn't give access to the C++, Java, Idl nor python tabs
the dialog doesn't propose to generate / reverse / roundtrip
To create a new profile, use the package menu entry New profile and enter its name or cancel its creation. Obviously you can also add profiles in a project by importing a project definition profiles, and you can also add a package then change its stereotype to profile.
When you edit a package-profile the dedicated tab profile is enabled :
When the stereotype of the package is profile, the tab Profile allows to set the meta model reference (by default http://schema.omg.org/spec/UML/2.1/uml.xml, specifies the value of the href produced in the XMI through an imported package) and meta class reference (specifies the value of the href produced in the XMI through an imported element). For a plug-out there are supported by the properties metamodelReference and metaclassreference.
When you delete a profile, Bouml asks for to propagate or not the deletion. If the propagation is done all the its stereotypes are also deleted and the corresponding properties removed from the stereotyped elements.
When a profile is defined in an other project and you re-import it to upgrade its use : delete the profile asking for to not propagate the deletion, then imports the new definition. In case used profiles are coming from several other projects, process step by step, before importing a given project defining a group of stereotypes delete these profiles and only them, then import the project. In case profiles are placed under a package grouping them, delete the profiles directly, don't delete them by deleting the container package because Bouml doesn't ask for to not propagate the deletion when the profiles are deleted indirectly.
A class-stereotype has some restrictions regarding to the standard classes:
it doesn't have an associated artifact
it doesn't have projection in the languages (C++, Java ...)
the menu doesn't propose to add a sub-class
the dialog doesn't propose to generate / reverse / roundtrip
the unidirectional associations from the class to meta classes (classes stereotyped metaclass) are drawn as extensions and indicate the extended meta classes. The explicit multiplicity 1 indicates the extension is required :
the attributes support the attribute of the properties. For the element receiving the stereotype, each property's name is the name of the profile followed by ':' followed by the name of the stereotype followed by a ':' followed by the name of the stereotype attribute. The type of an attribute is considered to be a string in case it is not an enumeration (a class stereotyped enum).
a class-stereotype can generalize or realize other class-stereotypes and inherits attributes
Bouml doesn't manage OCL, so the constraints aren't checked, however you can attach plug-outs to a class-stereotype, refer to the corresponding dialogs described below.
To create a stereotype in a profile, choose the menu entry New stereotype proposed by the menu of a class view part of a package-profile.
When you edit a class-stereotype the dedicated tab stereotype is enabled :
The tab Stereotype allows to set who is extended, the elements on which the stereotype applies, and to set dedicated plug-outs :
initialization plug-out : indicate the plug-out to be applied after the edition of an element setting its stereotype to the current stereotype. When the plug-out is applied the stereotype's attributes was already added to the element and initialized with their default values. It is your responsibility to call the corresponding plug-out for the inherited stereotypes. Obviously to set this plug-out is optional.
check plug-out : indicates the plug-out to be applied after the edition of an element which stereotype is unchanged. It is your responsibility to call the corresponding plug-out for the inherited stereotypes. This plug-out is also called when a children in the browser tree is edited. Obviously to set this plug-out is optional.
parameters : to give parameters to the plug-out allowing to limit the number of plug-outs, and for instance to define only one plug-out for a profile and to use these parameters to to indicate the stereotype and if this is an initialization or a check.
icon path : to specify an icon, several kind of image can be used depending on the QT release (png, gif, jpeg, xpm ...). If specified this icon will be always used in the browser for the elements having this stereotype except when there are deleted, the image is resized to have its width and weight less or equal to 16. In a diagram the image is used without modification when the scale is 100%, else it is resized. This image is used in the diagrams for classes when the drawing mode is natural, components when you ask for to use an icon, packages (context not written), state actions (behavior not written), activity object nodes, deployment nodes and artifacts. You are able to specify an absolute path, or a path relative to the root directory for the icons or relative to the project directory. In case the path of an icon is not absolute, the icon are searched first using the root directory for the icons, then using the current directory, then using the project directory.
apply on : to set the types of element on which the stereotype can be applied, to filter the stereotypes and to not propose all the stereotypes part of profiles on any element. Note this field is set independently of who is extended, the consistency is not checked.
Note : these plug-outs aren't called when the modifications are made by an other plug-out.
The extension is supported by an implicit attribute whose name is prefixed by base_, for instance base_Element when the stereotype extends http://schema.omg.org/spec/UML/2.1/uml.xml#Element
For a plug-out the list of elements on which the stereotype applies is supported by the property stereotypeApplyOn and the attached plug-outs are supported by the properties stereotypeSet and stereotypeCheck and their parameters by stereotypeSetParameters and stereotypeCheckParameters. The icon path is attached to the property stereotypeIconPath.
If the stereotype MyStereotype is defined in the profile MyProfile, an element stereotyped by MyStereotype has in fact the stereotype MyProfile:MyStereotype, and this couple of name must be unique without considering the case of the characters. You have to use the full stereotype name in the generation setting if you to project it in the target languages.
When you delete a profile (may be by changing its stereotype to not be profile), all its stereotypes are of course also deleted (except if the deletion is not propagated). When you rename a profile, the stereotypes of the elements are updated. When you move a class view out of a profile, the own stereotypes are first deleted and may be re-created after if the new package is a profile, the stereotyped elements are updated.
When you delete a stereotype (perhaps changing its stereotype to not be stereotype or moving its container class view), the stereotype and the associated properties are removed on the elements having this stereotype, the elements having a stereotype inheriting the deleted stereotype are also updated to remove the associated properties. When you rename a stereotype, the properties of the elements having its stereotype or having a stereotype inheriting it are also renamed. When you undelete a stereotype the consistency of the information related to the stereotypes is forced. Nothing is done when the stereotype is deleted through a plug-out except if this one calls UmlBasePackage::updateProfiles().
When you modify the inheritance between stereotypes, the properties of the elements are added/removed. When you undelete an inheritance between stereotypes the consistency of the information related to the stereotypes is forced. Nothing is done when the inheritance is modified through a plug-out except if this one calls UmlBasePackage::updateProfiles().
When you add/delete a stereotype attribute, the corresponding property of the elements are added/removed. When you undelete a stereotype attribute the consistency of the information related to the stereotypes is forced. Nothing is done when the modifications is done through a plug-out except if this one calls UmlBasePackage::updateProfiles().
When you load a model the consistency of the information related to the stereotypes is forced, adding or removing properties on the stereotyped elements. You can also ask for that phase, this is useful when you delete profiles without propagation and you want later to propagate the deletions, or when the modifications was made through a plug-out. You can also ask for to apply the plug-out dedicated to check the stereotyped elements.
A meta class is a class stereotyped metaclass
The path of a meta class (by default http://schema.omg.org/spec/UML/2.0/uml.xml or http://schema.omg.org/spec/UML/2.1/uml.xml depending on the XMI generation) is memorized through the property (tagged value) metaclassPath.
Previous : Deployment diagram
Next : C++ generator