First Proposal for Profiles Implementation

After having studied the current ArgoUML code, I have coded a minimal prototype of what I think profiles should be in ArgoUML. At this page I'm going to discuss the main modifications I propose. I have generated a patch containing all the code modifications I have done. This patch can be found here.

The following class diagram illustrates how profiles could be implemented in ArgoUML:

(you can find the zargo file for this class diagram here )

The Profile's concept

A profile is mainly an object of the Profile class. This object is in charge for providing a model where ArgoUML can look for the defined stereotypes, tag definitions and etc, a formating strategy (used to format the element names according to the namespace). In future, it can provide wizards, critiques, figures and so on.

There are two ways to deliver a new profile: as a plug-in or as an XMI file. A profile defined as a plug-in can offer more specialized services, as special critics and automatic registration. I have put an exemple of plug-in profile here (source code here).

This plug-in defines a micro-java beans profile. It defines a <<Bean>> and a <<Property>> stereotype, and a critics to enforce the constraint "A <<Property>> can only be applied to a <<Bean>>'s attribute".

A plug-in delivered as an XMI file is a UserDefinedProfile object that just provides a model from where ArgoUML gets the definition for the stereotypes, tag definitions and primitive types. There's an example of XMI profile here. It defines a reduced threading profile (don't try to figure out what it is ;)). It defined two stereotypes, <<activeThread>> for classes and <<communicationChannel>> for associations, a datatype called mutex and a tag definition called priority.

The support for both strategies is very important, because supporting XMI files allows the creation of new profiles by the user with almos no effort (just define the profile using ArgoUML and export the XMI file). The support for profiles defined as plug-ins is also important, because the information contained at the XMI model is not enough for a rich user experience. UML allows the user to define the new stereotypes as subclasses of the metamodel metaclasses and to define OCL constraints 'constraining' the application of these stereotypes.

The main problem here is that the most ArgoUML can do with the information provided by the XMI file is to check if the profile is being correcly applied. But it would be very difficult to try to provide more useful information like: why is the profile not being correctly applied? how can I change it to make it correct? and so on.

The Model loader

The model loader interface intends to isolate the profile code from the code used to load the XMI model. This is just part of the effort to remove everything that's not related directly to profiles from the Profile class.

The class hierarchy under the ModelLoader interface tries to avoid unecessary checks and repeated code.

The ProfileConfiguration

This class should contain all the information related to profiles and that should be kept as part of the object. It contains the links to all the applied profiles and the notion of default profile (the profile that is going to be used as default model -- I don't know yet exactly what is it). The ProfileConfiguration has also a method to gather the models of all Profiles.

The ProfileManager

This class is responsible for keeping the list of profiles available to be applied to current project. To illustrate its functionalities I have implemented a new settings tab for projects that can be used to view the profiles currently applied and allows the instalation of new XMI profiles.

(yes... I know I'm not good at desiging interfaces ;-) )


Summary of implemented features

+ Support for Plug-in profiles
+ Support for XMI profiles
+ Making stereotypes, tag definitions and primitive types defined in all installed profiles available for application
+ Profile management