Profiles for ArgoUML
According to the
UML specification:
A profile
is a stereotyped package that
contains model elements that have been customized for a specific domain or
purpose by extending the metamodel using stereotypes, tagged definitions, and constraints.
A stereotype is a model element
that defines additional values (based on tag definitions),
additional constraints, and optionally a new graphical representation.
Tag definitions
specify new kinds of properties that may be attached to model elements.
The actual properties of individual model elements are specified using Tagged
Values.
Constraints attached to a stereotype must
be observed by all model elements branded by that stereotype.
The profiles
implementation in ArgoUML allows:
·
The definition of new profiles as user made XMI files containing stereotypes and tagged definitions.
·
The use of plug-in profiles that define
o
constraints as critics
o
new graphical
representations for stereotyped elements
·
The use of multiple
profiles at the same time on a given project
·
The clear separation among the UML, Java and C++ profiles.
Tutorial
1.
Creating a new profile
2.
Loading an user defined Profile
3.
Using a profile defined as a plug-in
4.
Changing the default visualization
for stereotyped elements
5.
Global settings
6.
Breaking the rules: testing the
constraints
7.
Persistence
8.
The default profiles
9.
Defining local Profiles
10.
Coding your own profiles
1. Creating a new profile
Any XMI model
can be loaded as a profile. Thus, in order to define a new profile (File ->
New), create a new model defining the profile’s stereotypes and tag definitions
and export it as an XMI file (File -> Export XMI). The next picture
illustrates a profile for GUI modeling:
Picture 1 Defining a new Profile
It defines two
stereotypes. The Frame stereotype
marks a class as a frame that is displayed on the screen whereas the Link stereotype marks some associations
between frames, it indicates that some action execute in a frame leads to the
exhibition of another.
2. Loading a user defined
profile
In order to
apply a user defined profile to a project. Open the project and go to the File
-> Properties option. Click on the “Profiles” tab.
The displayed screen should be similar to the next one:
Picture 2 File properties
The left panel
lists the profiles that are currently loaded but have not been applied to the
current project. The right pane shows the profiles that have been loaded and
are applied to the current project. The picture above shows that the “C++”
profile has been loaded, but is not active and that the “UML
Use the
“>>” and the “<<” buttons in order to activate and deactivate the
loaded profiles. The “UML
The Stereotype
visualization indicates the default stereotype visualization to be applied to
all newer elements in this project.
As soon as the
new profile is applied, its stereotypes, datatypes
and tag definitions are available on the current project. For example, create a
new class. Since the profile defines a new stereotype (Frame) that can be
applied to classes, the “Stereotypes” tab of the created class should now
contain the recently created stereotype. See the next picture:
Picture 3 Applying a stereotype
The tree
explorer also shows the list of currently applied profiles. Using this feature
you can see the stereotypes and other elements that are part of each profile.
Picture 4 Profiles in the tree view
The following
picture illustrates a model for the ArgoUML’s GUI
created using the user-defined profile:
Picture 5 Sample model using user defined profile
The model says
that there are three “Frames”: the “MainWindow”, the
“FilePropertiesDialog” and the “FileOpenDialog”.
There is a “Link” between the “MainWindow” and the “FilePropertiesDialog” called “fileProperties”.
There is a “Link” from the “MainWindow” to the “FileOpenDialog” called “exportGraphics”
and there is a “Link” from the “FilePropertiesDialog”
to the “FileOpenDialog” called “loadProfile”.
3. Using a profile defined as a
plug-in
A plug-in
profile is provided as a JAR file. It should be installed as any other plug-in
(copying the JAR files into the “ext” directory). The profiles provided as
plug-ins can define new icons for stereotyped elements (see item 4) and new
critiques (see item 5). Here you can find a subset of a JavaBeans profile. When copied to the “ext” directory, the
plug-in automatically installs itself during the initialization phase. It
should appear then at the list of loaded profiles, as seen on the next picture:
Picture 6 Profile list after 'JavaBeans' profile being loaded
4. Changing the default
visualization for stereotyped elements
According to UML
2.0’s specification, a profile can profile can define a new icon for a
stereotyped element. This implementation provides three visualizations for a
stereotyped element: its default visualization, its default visualization with
a small icon for each stereotype that defines an icon and the provided icon
replacing the default visualization.
In order to
change the default visualization, use the right mouse button to click on some
model element and use the “Stereotype Visualization” to select the desired
view. See the next picture:
Picture 7 Changing visualization
The following
picture displays the three possible views for a class stereotyped with the
“<<Bean>>” stereotype:
Picture 8 Possible visualizations for a class with
the “Bean” stereotype.
Textual (left), Big Icon (center) and Small Icon (right)
The following
pictures illustrate a model created using the sample JavaBeans profile:
Picture 9 Sample java beans model
5. Global Settings
The profiles tab
at the settings window contains the set of configurations used to create new
projects. The Stereotype Visualization combobox
selects the default visualization in all new projects. The Available Profiles and
the Default Profiles contain the list profiles that are going to be applied to
the new project.
The default XMI
directories contain a list of directories. When ArgoUML
starts, it searches through all of the directories looking for the XMI files in
these folders. The found XMI files are going to be automatically added as
available and will appear on the “Available Profiles” list.
Picture 10 Global Settings
6. Breaking the rules: testing
the constraints
A profile
provided as a plug-in can use the critic’s mechanism in order to enforce its
constraints. The sample JavaBeans profile discussed at the previous sections
installs a critic that says that “Properties” can only be defined in classes
with the “Bean” stereotype. If you try applying the “Property” stereotype to
some attribute that is not part of a “Bean” the critic’s mechanism will point
the problem. See the next picture:
Picture 11 Critic provided by a plug-in
7. Persistence
The list of used
profiles is persisted along with the project. When some element from an applied
profile is used on a project it is copied from the profile model into the
project model, thus, if some profile used to build a model is not available
anymore the used stereotypes will still be available and the model will be
still valid.
The user defined
profiles used to build the project model are persisted in the Zargo file. Thus, if some user defined profile is not
available at the current machine the Zargo file is
still loadable. Although being loaded from the Zargo
file, the user defined profiles are not registered as available profiles. They
are not going to appear at the Profile Settings tab and if it is removed from
the profile configuration it will be lost forever.
8. The default profiles
Some profiles
are enabled by default. This is the case of the “UML
9. Defining local profiles
A profile is
applied by default to the whole model, so the defined elements will be
available to all elements in user model. You can also define a profile that exists
only in your model and apply it to part of the model.
Picture 12 Locally defined profile
In order to
define a local profile, you must create a new package and add the “<<profile>>”
stereotype to it. As depicted in Picture 12, you can define new stereotypes, data
types and so on, as you define any profile. Locally defined profiles can only
be applied to packages into an user model. You need to
add an dependency from the package to the profile and
stereotype the dependency with the “<<appliedProfile>>”
stereotype. The elements defined in the profile can now be used in all elements
in the model.
10. Coding your own profiles
Profiles
provided as plug-ins can offer a better support than the user defined ones. This
tutorial is not going to teach how to write plug-ins but aims to describe how
plug-ins providing Profiles are expected to behave. The first thing you should
do is to implement a subclass of the org.argouml.uml.profile.Profile
class, following, you can see the code of the JavaBeans class (a reduced
version, in fact):
public
class
ProfileJavaBeans extends Profile {
private Collection model;
public ProfileJavaBeans() throws ProfileException
{
model = new ResourceModelLoader(this.getClass()).loadModel("JavaBeans.xmi");
addProfileDependency(ProfileJava.getInstance());
}
public String getDisplayName() {
return "JavaBeans";
}
public Collection getProfilePackages() throws ProfileException
{
return model;
}
}
The first thing
a generally profile does is to load its model from an XMI file, this is done
invoking the loadModel() method from one of the ProfileModelLoader
subclasses:
model = new ResourceModelLoader(this.getClass()).loadModel("JavaBeans.xmi");
After loading
the profile model, a profile is expected to declare its dependencies. This is
done invoking the addProfileDependency() method from the superclass. The
dependency relation is recursive (so you automatically depend on the UML 1.4
profile when you say that you depend on the Java profile). Cycles are also not
allowed. The addProfileDependency() should raise an IllegalArgumentException if it detects an cycle. Profiles
are not expected to change its dependencies after they have been instantiated. Profiles
are also expected to be able to find the profiles they depend on and
dependencies can only be added between registered profiles.
After defining
the profile class, the first thing a plug-in should do is to register the
profile at the ProfileManager. This is done inviking the registerProfile() method of the ProfileManager:
public boolean enable() {
ProfileManagerImpl.getInstance().registerProfile(ProfileJavaBeans.getInstance());
...
}
Don’t forget to remove
the profile of the ProfileManager when your plug-in
gets unloaded:
public boolean disable() {
ProfileManagerImpl.getInstance().removeProfile(ProfileJavaBeans.getInstance());
...
}
When the plug-in
gets loaded the profile should then be registered at the ProfileManager
and should be available for users to use.