Login | Register
My pages Projects Community openCollabNet
Profiles for ArgoUML - Tutorial

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:

NewProfile.png

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 1.4” and the “Java” profiles are currently active.

Use the “>>” and the “<<” buttons in order to activate and deactivate the loaded profiles. The “UML 1.4” profile is considered to be the default profile and cannot be deactivated neither unloaded. In order to load a user defined profile, click on the “Load profile from file” button. Locate the XMI file that contains the user defined profile and open it.

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:

SampleArgoUMLGUIModel.png

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:

MyClassBeanTextual.pngMyClassBeanBigIcon.pngMyClassBeanSmallIcon.png

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:

SampleBeans.png

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 1.4”, the “Java” and the “C++” profiles. The “UML 1.4” one is the default profile (because it contains the UML’s default stereotypes and datatypes) and thus cannot be removed. The Java and the C++ profiles define classes and datatypes that are available in these programming languages.

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.