A UML profile is a generic method for extending a base meta-model into a domain. Profiles can extend meta-classes using stereotypes, add meta-attributes using tagged values, and add constraints. A profile can then be applied to a model, immediately making its extensions available to the modeler.
Profiles exist today for many domains, including:
- Profile for Software Services (read the article UML2.0 Profile for Software Services on developerWorks)
- CORBA Component Model
- Enterprise Application Integration
- Enterprise Distributed Object Computing
- QoS and Fault Tolerance
- Schedulability, Performance, and Time
- ... and many more
Of course, it is likely that you or someone at your site will want to create a custom profile to extend the UML meta-model specifically for your domain. Since a profile is an extension to the meta-model, it follows that the profile becomes critical to the definition of the internals of the model as soon as it is used. That is, the model can only be opened in the presence of all of the profiles that are applied to it.
This article will introduce you to the steps necessary to create a custom profile in IBM® Rational® Software Architect (IRSA) in two ways: as a stand-alone file (*.epx), and as a plug-in. Each method has advantages and disadvantages for both management and parallel development. This article will guide you through creating a trivial profile and applying it to a model. The next segment will cover issues with managing profiles (both types.) And finally, issues with parallel development where custom profiles are involved will be covered.
You'll start by creating a trivial profile in an epx artifact to see how it is done.
To start the ball rolling, create a custom profile in a model project. Call it something other than the default name, for example nonsense. Right-click the example model project and select New and then Other as shown in Figure 1.
Figure 1. Project context menu to start the new profile wizard
Selecting other brings up the artifact type selection dialog shown in Figure 2.
Figure 2. Artifact Type Selection dialog
Selecting UML Profile and clicking the Next button takes you to the New UML Profile dialog as shown in Figure 3.
Figure 3. New UML Profile dialog
Change the name of both the artifact and the profile to nonsense so that it is a bit more obvious later where your new profile is being used and displayed. Clicking Finish completes the creation of the profile in your project, as shown in Figure 4.
Figure 4. Model and Profile Sharing a Project
First, right-click the nonsense profile package in the new profile artifact. On the context menu, click Add UML, then click Stereotype in the sub-menu that appears as shown in Figure 5.
Figure 5. Add Stereotype menu
The result of this command is an added stereotype with its name in edit mode, as shown in figure 6. We'll leave the name alone.
Figure 6. Added stereotype in Edit mode
Now, to make the stereotype useful, you'll have to add a meta-class extension capability. To do this, you have to go to the properties view and click the Extensions tab as shown in figure 7.
Figure 7. Stereotype Extensions tab
Click Add Extension and you'll see a dialog in which you can select the meta-class that you would like to extend, as shown in Figure 8.
Figure 8. Meta Class Extension dialog
Select Classifier from the list, leave the Required field clear, and click OK. The profile will now contain a stereotype extension named for the meta-class and the stereotype's name. Yours is shown in Figures 9 and 10.
Figure 9. Meta-class extension in profile
Figure 10. Meta-class extension in Properties view
Next, you'll add an attribute to the profile by right-clicking the stereotype, this time selecting Add UML and then Attribute, as shown in Figure 11.
Figure 11. Add Attribute menu
No surprise, you end up with a new attribute with its name in edit mode (see Figure 12). Leave the name as Attribute1 for this example.
Figure 12. Added attribute in Edit mode
Finally, set the attribute type in the properties page. First, click the Select type button (shown in Figure 13). Next, select the string type from the resulting dialog. Then, type in a string value in the Default Value field in the Properties window (also shown in Figure 13).
Figure 13. Attribute properties
The stereotype is now ready for use in your example. Wait ... you forgot to add the icon. Glad I was paying attention. To add an icon to the stereotype, create an icon (*.ico or *.gif) and save it into the project with the other artifacts. It does not show up in the modeling perspective, but you can see it in the resource perspective (Figure 14).
Figure 14. Stereotype icon in project
To add the icon to your stereotype, go back to the modeling perspective, click on the stereotype in the model explorer, and go to the General tab of the Properties window and find the icon property. At the far right of the icon row, you will find a Browse button. Clicking the Browse button will give you a file browse dialog called Open. Find your icon and you'll be able to attach it to the stereotype. When you have "opened" the icon according to the dialog, you are returned to the property window with the word defined in the icon cell.
At this point you should have an attribute and an icon defined, so you should now proceed to apply the stereotype to see the effect.
Although the model shown so far has not had a class in it, presumably yours does. If not, add a class. Now it's time to apply the profile and then stereotype that class. First, select the Model element and look at the properties window. You'll see a tab called Profiles (see Figure 15), which you'll select.
Figure 15. Profiles tab
It's not a stretch for you to guess that you'll click the Add Profiles button. When you do that, you'll see Select Profile dialog shown in Figure 16.
Figure 16. Select Profile dialog
The dialog comes up defaulting to the Deployed Profile option. You'll select the File option and then browse for the nonsense.epx file in the resulting Open dialog (see Figure 17.) Note that (ironically) Eclipse does not display the *.ico file's icon. The icon file is a Windows format, and Eclipse tends to work better with cross-platform formats. You could be better off using a *.gif file for the icon.
Figure 17. Open Profile dialog
Opening the profile will immediately present a warning (see Figure 18) that the profile was not released. The tool is warning you that the profile is not guaranteed to remain backwards-compatible when it is next edited. Since this is an informal exercise, you did not go through the whole process of guaranteeing backwards compatibility. This will actually work for the example, but will leave users who apply the profile open to incompatible future profile changes that could cause them problems. See the Help on profiles before releasing your profile to the general user community, or you could end up repairing by hand every model in your shop. Meanwhile, it is safe to dismiss the warning for this disposable example.
Figure 18. Profile Not Released warning
Note that you can turn off the warning in the Preference page under Modeling, then Views. But why would you want to take that risk? The profile is now safely applied, as shown in Figure 19.
Figure 19. Applied profile
To stereotype a class, select the class and then select the Stereotypes tab in the Properties window. Figure 20 shows these two side by side.
Figure 20. Class and Stereotypes tab selected
Now click the Add Stereotypes button. You'll see a selection dialog (Figure 21) that includes the new nonsense stereotype. You'll check Stereotype1 from the nonsense profile.
Figure 21. Apply Stereotypes dialog
You can see the applied stereotype in the Properties view shown in Figure 22.
Figure 22. Applied Stereotype dialog
Go back and look at the class to see if the icon shows up in place of the original class icon. Oops ... in this case it did not. There is a blank space there now, as shown in Figure 23. This is a rare occurrence, caused by some tricky timing -- you may have changed an icon in a stereotype after it had already been used in the same session -- the old icon is still in the cache and the application gets a bit confused. If you ever see this happen, simply restart the application.
Figure 23. Icon not working
After restarting the application, both the Model explorer and the diagram refresh perfectly, as shown in Figure 24. To reiterate, this is a rare occurrence, I only show it here because it is confusing when it happens (and it coincidentally happened to me as I was writing this article).
Figure 24. Icon working
Note that the <<stereotype>> notation no longer displays when a custom icon is shown in the Model explorer. The diagram, however, does show the notation. These can be adjusted somewhat in the modeling Preference pages. Open the Preference pages and select Modeling and then Views. On the page you'll see a group called Model Explorer Settings inside of which is a combo-box selector called Stereotype style. The choices for this field are None, Text, and Decorator. If you select None, you'll see the original icon and the name of the element only. Selecting Text adds the stereotype name in between the angle brackets. Finally, selecting Decorator shows the overriding icon but not the text. There is no selection that will give you both notations. On the other hand, to change the decoration for shapes on a diagram go to the Preference page for Modeling, then Appearance, then Shapes. There you will find another field called Stereotype style, under which there are several choices, including Text and Decorator. This is obviously the default as it shows in Figure 24.
Your custom profiles are as important to your models as any other profile. To reiterate: you cannot properly operate on your model files without all of the applied profiles being in the location and at the version level the models expect.
IBM strongly advises that you maintain your UML Profiles on a separate life cycle from your models, as shown in Figure 25. It is also advisable that they reside in a separate repository, and that their original source is accessible only to your meta-model extenders (not to the general development and modeling population). It is not possible to over-stress the importance of this point.
Figure 25. Profile lifecycle
Your meta-modelers will create the appropriate UML profile to provide domain-specific extensions for your site. They will thoroughly test the profile so that it can be used by all of your modelers without an immediate revision and all the upheaval that implies. A stable meta-model is critical to a stable team development experience. In other words, constant change in the meta-model propagates downstream, increasing risk at every stage.
The need to upgrade to new profile versions frequently creates windows of failure opportunity that should not exist. An example would be where three profile versions are released in quick succession to a community of 50 modelers, with a typically slow adoption rate that leaves the community about equally split as to their current version. As changes are made to the models, some are upgraded to the new profile version and others are not. As modelers on older versions of the profile try to open a model that needs a later version, the tool will complain and ask if it can open the model in compatibility mode. This is a bad thing because the new stereotypes will not be handled at all: they'll be effectively invisible to the tool.
Now what happens if the operation that caused the model open attempt was an update from IBM® Rational® ClearCase® and the model open was in the context of a merge session? At this point, the merge session has to fail (it does that automatically) and now the modeler has to upgrade to the latest profile version and recover the merge session somehow. This can be very confusing and should be prevented at all costs, to avoid the possibility of accidentally overwriting artifacts.
Since you will by now agree that there is great value in a stable profile, you will now proceed to take your thoroughly tested profile and certify it for use by your modeling community. The release operation is a formal "stamping in concrete" of a specific version of the profile that will remain backwards-compatible in perpetuity (this is enforced by the tool.) This backwards compatibility requirement is the reason you saw the warning that the profile had not been released during your earlier creation of the toy profile. The tool was warning you that building on an unreleased profile does not guarantee backwards-compatible changes in the future. Building upon an unreleased profile is always at your peril.
Your modeling community will now adopt the newly released profile. At this point, there are many distribution options.
- Deploy a plug-in from a local update site and notify the modeling community to update as soon as possible.
- Deploy an epx file to a share and notify the modeling community to copy to their local hard drive as soon as possible.
- Deploy an epx file to a share that is mapped by the modeling community. The next time they open any model, they will be forced to upgrade the model.
- Deploy a plug-in or epx file to a project in the main modeling repository and notify the modeling community to update to the latest version of that project as soon as possible.
Each of these techniques has strengths and weaknesses when performing parallel development. These will be covered in depth later in this article. The choice of technique is also intimately entwined with the way in which the model will reference the profile. There are four reference types, which are explained in depth later as well. For now, though, I will stipulate that the appropriate reference type is a pathmap reference, which uses a map entry in your modeling preferences (or automatically created by a plug-in) through which it can reference any location to find the profile.
Applying the profile for the first time was covered during your example creation in the first portion of this article. The main issue with applying the profile is whether it appears automatically in the Apply Profiles dialog, or whether the modeler has to browse for it.
- If the profile is deployed as a plug-in, you can give the Eclipse update manager the path to the local deployment site and the plug-in will be loaded from there by Eclipse. This also has the advantage of handling the pathmap creation for you.
- If the deployment is by file, then the modeler will have to ensure that a correctly-named pathmap points to the location of the custom profile artifacts. This location can be a network share, which obviously requires that access to the network be established before any model editing can take place. This is not ideal for mobile workers, so the pathmap can instead point to a local mirror of the profiles. This is ideal for mobile workers, but requires a separate copy step during the adoption. This does have another advantage though; the exact timing of the application can be easily controlled, because the new profile can only be applied after the copy step has been taken.
IBM recommends plug-in based deployment as the appropriate option in most cases. This technique has these advantages:
- Adopting a new profile plug-in is managed mainly by Eclipse.
- Upgrading to a new version of a profile is also managed mainly by Eclipse.
- The pathmap entry is handled transparently by the plug-in.
- Most important, the profile now appears in the list of deployed profiles, eliminating the disk or network browsing step! Eclipse manages this for you now.
Applying a newer profile is semi-automatically handled by the tool. Whenever a model is opened, the tool checks the versions of all applied profiles against the latest version that has been adopted into the model. If the profile is newer than has been adopted previously, a message is shown offering to upgrade the model to the latest version (see Figure 25).
Figure 26. Profile Upgrade message
If you are opening the model for edit, please click Yes. Other scenarios will be covered in the next section.
Custom profiles interact intimately with your models. Their impact on parallel development can range from negligible to fatal. That is, an incorrect workflow or profile deployment model can fatally damage your model workflow.
Just to be clear: there are no parallel development issues with the custom profiles themselves, because there can be no parallel development of the profiles in the first place. The tool intentionally does not support parallel development of profiles because the development of profiles is a specialized task that only one or a very few modelers will be performing at any one time. As mentioned several times in this article, it is also one of the most critical areas of your modeling workflow, so you must get it right every time. It is an unacceptable place for the (albeit minor) risks associated with developing artifacts in parallel. Just as important are the optics: the profiles should be kept under "lock and key" and be accessible by a very few.
So all of the impact issues that matter occur on the models to which the profiles are applied.
Once you have set up your profile life cycle and deployment model, you would assume that the references between your model and your profile should be created the right way automatically. Unfortunately, that is not quite how things work. The references between the model and the profile are created at the moment that you apply the profile to the model, and exactly what kind of reference gets created depends entirely on where the two artifacts happen to be in relation to each other at that critical moment. Also, there is no way to tell from the way in which profile paths are displayed in the model's property window exactly how each profile is referenced, because paths are always shown in their full form. In Figure 27, which is a smaller snippet from Figure 19, you can clearly see three paths, all being displayed as fully qualified file paths.
Figure 27. Applied profile paths
None of these three references are actually direct references to the profiles indicated. The first two are pathmap references to the tool's profile directory, and the third is the relative reference to your example profile, which is in the same Eclipse project as your model.
The only way to determine the reference's type is to inspect the actual model file after the reference has been created. This clearly illustrates why procedures are so critical to profile management.
The default reference type for EMF-based models is the relative reference. That is, the location of the referenced artifact is anchored to the current artifact's location. A relative path to a profile, taken directly from your previously created example, looks like:
This reference has no preamble before the file name, so it is obviously anchored to the directory in which the model resides.
When you create a profile in the same Eclipse project as your model, IRSA will always create a relative reference. Now here's the bad news -- relative references do not work well with parallel development and are therefore not a supported mechanism for profile management in a team environment. To be clear: managing your custom profiles in the same Eclipse project with your models is an unsupported work flow.
Here are several scenarios that break when custom profiles are referenced with relative paths.
- Users A and B check out an artifact in parallel. User A adds a new custom profile to the same project as the model, and then applies it to the model. In both CVS and ClearCase, this will result in a modification to the parent folder of the model and profile. User A checks in the changes. User B now synchronizes with the workspace and notes that there is a new incoming file and that there is a conflict. User B must process the incoming file before the conflict because the merge can only load the remote file if the new meta-model on which it depends is already in the workspace. This timing issue can be overcome manually with CVS, but this timing dependency opens a window of confusion and an opportunity for failure that is unacceptable in a reliable process.
- When a profile is no longer needed and is deleted from the project, say by User A, a similar issue occurs in the opposite direction. User B synchronizes his or her workspace and must recognize the fact that accepting the artifact deletion first will destroy any chance of successfully merging the model because the remote (and possibly the ancestor) copy of the model still requires the profile in order to be successfully processed. Once the mistake is made, the file must be found in the repository and temporarily copied to the project again. This might work in CVS, but is not at all an ideal solution because the management of this portion of the workspace now falls entirely to the user.
- Browsing the CVS repository is impossible with relative references to profiles, because artifacts depend on those secondary artifacts being present in the workspace at the correct location, but when launching from the repository CVS provides only a single stream to the editor. Prerequisite artifacts are not made available.
Eclipse has a second form of reference called the platform reference. You get a platform reference when you create your profile(s) in a second (parallel) project in the same workspace. This method is probably the most obvious method for managing custom profiles (it is at least as obvious as keeping the custom profiles in the same project as the model, as discussed in the previous section.)
You can extend the previous example by creating a new project with a profile in it and then applying that profile to the same class. The new path list is shown in Figure 28a. The effect on the class is shown in Figure 28b.
Figure 28a. Applied profile paths with a separate project
Figure 28b. Both stereotypes applied
As with relative references, it is not obvious how the reference manifests in the file. You created the reference by applying from another Eclipse project, so it should be a platform reference. Inspecting the model file shows us this reference:
indicates that the reference is anchored to the Eclipse workspace and
that the resource can be found in the example_prof project.
This is another unsupported configuration. Similar reasons exist. It requires a lot of manual intervention during synchronization. In CVS, this can be made to work so long as there is a broadcast to all users and they adopt the new or updated project(s) in the right order: for added profiles they must process the profile project before proceeding with the synchronization. For deleted profiles, they must process the profile project after the project that contains the models that have been changed in parallel and which the deleted profiles affect. There are two addition and deletion variants; one where an individual profile was added or deleted and one where the whole profile project was added or deleted. Each will require a slightly different mental picture of what is going on in order to do the right things in the right order. This is sufficiently complex that it is quite unlikely that it will be handled correctly every time, or even some of the time. This is why storing profiles with models in the same or a parallel project are unsupported team development workflows.
An absolute path reference is exactly what it sounds like. The entire physical path to the profile is stored. This has a distinct advantage over the two previous reference types: no matter what the scenario, so long as the latest version of the profile is where the model expects it to be, all versions of the model will load. Of course, this all versions of the model statement has a caveat: that being that only released versions of profile guarantee this backwards compatibility. Make sure you properly release your profiles before they get applied to models!
By way of example, you can copy the profile you created in the separate project and paste the entire file into a directory hanging off of C:\ as shown in Figure 29. Again the path is shown with no indication of what type of reference was created.
Figure 29. Applied Profiles -- relative, platform, and absolute
The reference looks like:
This eliminates all of the previously documented workflow issues, so where's the catch? Well, it's a big one -- once you establish an absolute path, then every machine on which the model is opened must have the applied version (or later) available at the exact location. No exceptions.
An obvious consequence is that the use of a data disk (E:\) instead of the standard (C:\) will cause havoc in your design community. Can you really expect every machine in the shop to have the same disk drive layout? Another obvious problem is that disk style references don't work on UNIX operating systems, so your model can now work on Windows or Linux only (for example.) One alternative is to put the absolute path on the network and have everyone mount it in the same location (for example P:\), but this makes life difficult for mobile users and still does not solve the cross-platform issue.
Absolute paths are supported for team development because they work. But they are not a recommended technique because they suck in almost every other way. Which brings me to the best of the techniques ... and the only one recommended by IBM.
A PathMap specifies a named location for a folder containing whatever you are referencing. In this case, you can explore this technique using the existing example, and adding yet one more profile to the mix.
Start by defining a pathmap pointing to the profiles folder you created a moment ago. This is done in the Preference pages under Modeling, then Path Maps. The field Defined path variables contains the list of paths that the tool will use for mapping profile and cross-model references. Again, the tool automatically chooses the reference type at the moment of reference creation, so make sure that your paths are created before applying your profiles. Click the New button and you'll get the dialog shown in Figure 30.
Figure 30. PathMap Definition dialog
Figure 31 shows the result.
Figure 31. Figure 31. PathMap defined
Now you can make a copy of the profile that's in your separate project and rename it so you can tell the difference once you apply it (Figure 32.) Drop a copy of that profile in the profiles folder to which the pathmap points.
Figure 32. Both profiles in folder
Now apply the new profile to the same class and take a look in the file.
The pathmap format uses a form of UNC syntax, specifying that the reference must look up the folder in the table entry with key PROFILES and find the file named Profile_PathMap.epx.
Checking the file after applying the profile reveals that the absolute reference has been recast as a pathmap reference. If that was accidental behavior (on your part that is -- did you really intend both profiles to be in the same location?), then this is not necessarily a good thing.
The obvious advantage with pathmaps is that the tool will deflect through a pathmap to any UNC path at all. This allows each modeler to choose where the profiles should exist. It also allows plug-in based profiles (the recommended approach) to create the pathmap before the profile can be applied, thus guaranteeing that the reference will be a pathmap reference!
Profiles are absolutely necessary for domain-specific modeling using the UML. Parallel development in a Software Configuration Management (SCM) system is absolutely necessary if you want your modelers to work together efficiently. These two necessities will interact well if you follow a few rules:
- Maintain your profiles in a separate repository and only deploy them to your modeling community after thorough testing.
- Always release the profile before deployment so that updated versions will remain backwards-compatible.
- Deploy your profiles in one or more plug-ins. The developer community will obtain updates using the Eclipse update manager from your local profiles update site.
- Use a PATHMAP variable that is created automatically by your plug-in! This guarantees that your modeling community will create the appropriate references no matter who applies the profile originally or upgrades the profile in a model.
Putting all of this information together, the following discussion briefly demonstrates creating and deploying a profile plug-in. Start by creating a new plug-in using the File main menu. Select New, then Plug-In Project. If that entry is not visible at the first level of the menu, then select Other, which will bring up a Wizard Selection dialog. In the Plug-In Development category, you can find Plug-In Project. The wizard launches, as shown in Figure 33.
Figure 33. New Plug-In wizard
Give your project a name and check Create an OSGI bundle. Click Next to go to a second page, where names and paths are confirmed. The defaults should be acceptable here. Click Finish to generate your plug-in. Your plug-in project is opened in the navigator as shown in Figure 34, and your manifest and plug-in.xml files are opened in the manifest editor as shown in Figure 35.
Figure 34. New plug-in in Navigator view
Figure 35. New plug-in in Manifest editor
You need to extend the platform in two places to make this plug-in useful. First, you must add the UMLProfiles extension to bind your new profile into the tool. Go to the Extensions tab in the manifest editor. You'll see an empty list (See Figure 36) of extensions that your plug-in currently implements (or more accurately, does not implement).
Figure 36. Empty extensions
To add the UMLProfiles extension, click Add. You'll be presented
with a dialog in which all extension points are visible. Actually,
you will first have to clear the field named Show only extension
points from the required plug-ins at the bottom of the dialog
shown in Figure 37, then scroll down until you find
Double-click that entry or select it and click Finish.
Figure 37. Add UMLProfile extension
To add the pathmap extension, do the same thing -- looking for
Figure 38 shows the result.
Figure 38. Added both extensions
To fill in the extension point data, you need to add the appropriate field items to each. Right-click the UMLProfiles entry and select New, then UMLProfile. This will add an entry beneath the UMLProfiles extension entry. You can repeat this step for each profile artifact that you want the plug-in to provide. Click on the UMLProfile entry and you will see new properties to be filled in. Figure 39 shows the appropriate values.
Figure 39. Filled in profile data
The name*: field should indicate which profile is deployed by this specific extension. As already mentioned, you must add a new UMLProfiles extension for each profile that you want to deploy from this plug-in. Each will be shown separately in the GUI. This name field is shown in the Profile Application dialog under Deployed Profiles. It is not shown in the Applied Profiles property of the model; instead, the profile's own name is used there. This could become confusing, so a best practice would be to register the actual profile name in this field. In the path*: field, you must enter the exact path to your profile starting at the plug-in's main project folder. You'll note that the path shown here includes a profiles sub-directory. This is used by convention and you should stick to that convention. Create a profiles sub-directory as a peer to your src sub-directory. As already mentioned, this path is anchored relative to your plug-in directory for deployment, but is converted to an absolute path when stored. These extension points can be quite picky about the syntax of the name and the path. Experiment with the values at your own risk. Follow the conventions shown here whenever possible. Also, in version 6.0, you will need to reboot the platform after applying the profile in order to refresh the GUI. This was fixed in version 126.96.36.199.
Use the same technique to fill in the pathmap data, as shown in Figure 40.
Figure 40. Filled in pathmap data
The pathmap name is less important than the profile name because it appears only in the model artifact. Plug-in generated pathmaps do not appear in the Path Maps modeling preference page, but IBM reserves the right to display them in a future release so choose them wisely. You cannot go wrong with a meaningful name that is unique to your organization. You'll note that the path value is the profiles sub-directory that you created. Since all of your UMLProfiles should be stored in the same place, you need only this one entry to point to them all.
Now you can add your newly minted (and released -- see Figure 41) profile into the profiles folder. The final look for the project is shown in figure 42.
Figure 41. Release menu item
Figure 42. Profile plug-in project
When you selected the Release menu item, you were asked for a release label, which is just a text string used to identify the version level of the profile. After closing the dialog, the profile was modified to released status. The next step is to deploy the plug-in to a local update site.
If you need to create a new update site for your custom profile
plug-ins, I suggest that you read the developerWorks article Deploying
updates in IBM Workplace at
To complete this example more quickly, you can export the plug-in as a deployable plug-in as shown in Figure 43. This will allow you simply to copy the plug-in into your target environment and re-launch that environment to apply the new profile to a test model.
Figure 43. Export as plug-in
On the next dialog, be sure to select Deploy as a directory structure as shown in Figure 44. This will give you a folder to copy to your Eclipse installation.
Figure 44. Export to directory
Finally, copy the plug-ins directory into your Eclipse installation and restart your platform. You should be able to choose any of the ...\Eclipse\plug-ins folders under your installation. The one underneath the CSDev folder works fine, for example. Open the model and go to the Profiles tab to add the newly deployed profile. You will see the same dialog as you have every time, but this time the profile appears in the deployed section of the dialog (see Figure 45), a much more convenient mechanism for your modeling community.
Figure 45. Profile appears immediately
If you get a profile could not be found error when you try to apply the profile, you need to check your build.properties settings, because the profiles directory may not have been copied over to your deployed plug-in. Add the highlighted line in Figure 46 if necessary.
Figure 46. Add profiles to build.properties
After that, you should see the profile in the model's property sheet, as shown in Figure 47. The release label is blank in this screen shot because this particular profile was not actually released (my bad.) Yours should show whatever release label you entered during deployment.
Figure 47. Profile is applied
Finally, just to prove that the appropriate pathmap reference was created, a text format screen shot of the portion of the model that contains the application of the custom profile. Figure 48 clearly shows the pathmap: format.
Figure 48. Pathmap in model
You should by now be aware that custom profiles are a critical resource for your meta-models. Treat them with all the respect that they deserve. For a much more detailed treatment of the authoring material, please read the article Authoring UML profiles using Rational Software Architect and Rational Software Modeler, just published on developerWorks--see Resources.
Comparing models with local history: Part 1 in this series.
Merging models using compare with each other: Part 2 in this series.
A deeper understanding of model merging: Part 3 in this series.
Parallel model development with CVS: Part 4 in this series.
Model management with IBM Rational ClearCase and IBM Rational Software Architect Version 7 and later: Part 5 in this series (developerWorks, July 2007).
Ad-hoc modeling – Fusing two models with diagrams: Part 7 in this series (developerWorks, March 2007).
Authoring UML profiles using Rational Software Architect and Rational Software Modeler: A detailed treatment of authoring UML profiles.
IBM Rational Software Architect product page: Find technical documentation, how-to articles, education, downloads, and product information about Rational Software Architect.
Introducing IBM Rational Software Architect: Improved usability makes software development easier: This article is a basic introduction to the Rational Software Architect product.
UML 2.0 Profile for Software Services: This article describes the UML profile for software services, a profile for UML 2.0 which allows for the modeling of services, service-oriented architecture (SOA), and service-oriented solutions.
Get products and technologies
IBM Rational Software Architect: Download a trial version from developerWorks.
Rational Software Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Software Architect.