Comparing and merging UML models in IBM Rational Software Architect, Part 6: Parallel model development with custom profiles

Document options Document options requiring JavaScript are not displayed New site feature Check out our new article design and features. Tell us what you think. Rate this page Help us improve this content

Level: Introductory

Kim Letkeman (kletkema@ca.ibm.com), Development Lead, Rational Modeling Tools EMF Compare Support, IBM

16 Aug 2005

IBM Rational Software Architect (IRSA) is built on the Eclipse IDE and shares Eclipse's compare support workflows. IRSA UML models are built using the Eclipse Modeling Framework, so cannot be safely merged using the default Eclipse text compare support. This is Part 6 of a multi-part article discussing how to compare and merge UML models in Eclipse using a custom EMF and UML compare support solution. This article covers parallel development with custom profiles.

What is a UML Profile?

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
• CORBA Component Model
• Enterprise Application Integration
• Enterprise Distributed Object Computing
• QoS and Fault Tolerance
• Schedulability, Performance, and Time
• Testing
• ... 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.

Back to top

Introduction to custom profiles

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.

Create the custom profile

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.

Selecting other brings up the artifact type selection dialog shown in Figure 2.

Selecting UML Profile and clicking the Next button takes you to the New UML Profile dialog as shown in Figure 3.

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.

Add a meta-class extension

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.

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.

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.

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.

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.

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.

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.

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).

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).

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.

Stereotype the class

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.

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.

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.

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.

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.

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.

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.

You can see the applied stereotype in the Properties view shown in Figure 22.

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.

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).

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.

Back to top

Manage your custom profiles

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.

Create the profile

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.

Release the profile

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.

Adopt the profile

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.

Apply the profile and upgrade the model

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.

• 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).

If you are opening the model for edit, please click Yes. Other scenarios will be covered in the next section.

Back to top

Custom profile impact on parallel development

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.

References make a big difference

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.

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 four reference types

Relative references
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:

 href="nonsense.epx#_7ofWMeX4Edm174lcDiveMA?nonsense"

ClearCase In ClearCase, workflow problems with relative and platform references are actually more severe. ClearCase likes to handle most of the mundane details of a multiple checkin or a workspace update for you, so the order of operations is not really deterministic. You cannot force a specific order, so there is no easy way to adjust the timing to provide an ugly manual intervention like those described above. You may in fact have to stop an operation entirely because you have encountered a failure caused by the inability to load one of the models (any of the remote, ancestor, or local models can be affected as mentioned previously.) Once the operation is stopped, the offending artifact or project must be manually inserted into the workspace, a sometimes difficult chore because ClearCase likes to manage the workspace actively, so it is often necessary to refuse to let ClearCase take action on temporary artifacts. For example, to grab a new profile early, the ClearCase update command cannot be used on the whole view because the ordering problem is likely to recur. Running an update on the top level directory or the profile project might successfully retrieve the new project(s), but there is no equivalent to the UCM rebase command. Again, this is all a risky proposition and one that might never occur to an individual user. The only way to avoid all of this pain is to adopt the appropriate model and profile management workflows right up front.

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.

Platform references
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.

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:

 href="platform:/resource/example_prof/Profile.epx#_ApdpIecfEdmf8KgJJPxA2w?Profile"

The preamble platform:/resource/example_prof/ 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.

Absolute path
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.

The reference looks like:

 href="file:/C:/profiles/Profile_Absolute.epx#_ApdpIecfEdmf8KgJJPxA2w?Profile"

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.

PathMap
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 31 shows the result.

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.

Now apply the new profile to the same class and take a look in the file.

 href="pathmap://PROFILES/Profile_PathMap.epx#_ApdpIecfEdmf8KgJJPxA2w?Profile"

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.

 href="pathmap://PROFILES/Profile_Absolute.epx#_ApdpIecfEdmf8KgJJPxA2w?Profile"

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!

Back to top

Summary so far

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.

Back to top

Create a profile plug-in

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.

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.

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).

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 com.ibm.xtools.uml2.msl.UMLProfiles. Double-click that entry or select it and click Finish.

To add the pathmap extension, do the same thing -- looking for com.ibm.xtools.emf.msl.Pathmaps. Figure 38 shows the result.

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.

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 6.0.0.1.

Use the same technique to fill in the pathmap data, as shown in Figure 40.

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.

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 http://www-128.ibm.com/developerworks/lotus/library/workplace-updates/.

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.

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.

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.

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.

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.

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.

Back to top

Final word

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.

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.
  
  

• 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.

About the author

		Kim joined IBM in 2003 with 24 years in large financial and telecommunications systems development. His responsibilities with the IBM Rational Modeling Tools team include Modeling (EMF) Compare Support, Architectural Discovery for Java and UML, Traceability, and QE Test Automation.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top