Getting Started with Rational XDE Professional: A Guide for Visual Studio .NET Developers

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

JJ Kuslich, Software Engineer, IBM

09 Jun 2005
Updated 10 Nov 2005

Rational XDE Professional v2002, Microsoft .NET Edition, is a powerful modeling and productivity tool for developers that integrates with Visual Studio .NET. This article introduces XDE's major features and takes you through a simple example project.

Editor's note

On June 5, 2006 IBM announced the withdrawal of the Rational Rose XDE product family listed below. The Rational XDE components are being withdrawn from the market; however, the Rational Rose components will continue to be supported and will be re-packaged into a new set of offerings.

For more comprehensive information on the product migrations with the IBM Rational June 2006 product release plans, please visit: http://www.ibm.com/software/rational/support/migrations/

Software design is a process practiced by all developers, whether they do formal design or scratches on a napkin. Often development teams working against tight schedules don't feel they have the time to devote to a more comprehensive design process. Design documentation is scoffed at in some organizations, since it's often voluminous and must constantly be kept up to date; after all, the ultimate goal of software development is good code, not good design documents. Yet good software design leads to good code. What developers really need is a design tool that's closer to the code they're working so hard to write.

Rational XDE Professional v2002, Microsoft .NET Edition, is both a sophisticated software modeling tool and a productivity tool for developers. This "extended development environment" integrates directly with Visual Studio .NET and even runs within it. It merges the practices of software design and coding into a seamless, coordinated process supporting the work of real-world developers. XDE isn't just a tool for analysts, it's a software development productivity tool for development teams.

This article will introduce you to the major features of XDE and help you start working with it quickly. To keep this article brief and focused, I'll assume you're familiar with software development and design. Experience with a software modeling tool like Rational Rose will be extremely helpful. In addition, you should have used at least some version of the Visual Studio tools so that you can follow along with the example, which was produced with Visual Studio .NET. You don't have to know how to write code for the Microsoft .NET platform, but knowing the basic concepts of .NET development in the C# language will be helpful.

XDE Feature Overview

I'll start the tour of XDE with a brief introduction to its major features that will help you build better software:

• Integration with Visual Studio .NET - XDE is so tightly integrated with Visual Studio.NET that it runs inside it as an add-in. I can't think of a better way to access a software engineering tool than from inside the integrated development environment (IDE) itself.

• UML modeling - XDE has sophisticated software modeling features, including support for much of the Unified Modeling Language (UML). You can build a design model that incorporates UML model elements such as classes and use cases, and there are diagramming tools for building diagrams (for example, class and sequence diagrams). You can use the modeling features by themselves, but the real power of XDE is in its integration of modeling with the coding process.

• Code synchronization - XDE can generate code from models and vice versa, and keep the two in sync. In the real world, much of the development process involves writing a great deal of straightforward code, such as class and method definitions, and the hard part of writing a class is designing it (especially when it must interact with other classes). With XDE's code synchronization features, you can generate code from your design model elements, saving coding time. You can also generate model elements with your code and keep your models and code in sync, so you don't have to spend time manually keeping the design model up to date.

• Support for team development - Teams already have source code control systems to help them share source code files and control their versions. XDE provides several ways to work with existing source code control systems to share and control access to model elements.

• Custom code templates - In addition to enabling automatic generation of code from model elements, XDE lets you create and apply your own custom code templates. You can bind code templates to methods of your modeled classes, and XDE will generate the code from the template in the method body. Code templates can be reused on many methods, improving consistency and reducing the amount of boilerplate code that you have to type yourself. Those of you who use C++ should note that code templates are nothing like templates in C++; in XDE, code templates are chunks of reusable code that you can tell XDE to generate for you for elements in your model.

• Design patterns - XDE provides concrete support for the software engineering concept of design patterns. A design pattern is a formalized description of a piece of software that can be applied repeatedly in the designs of many different applications. It generally describes a common software mechanism, such as a proxy object that facilitates communication between two other objects across various communication mechanisms. Such a pattern is specific in intent but isn't tied to any particular piece of software. Design patterns help you to improve productivity and quality by reusing proven concepts throughout an application, and to ensure consistency by designing the same mechanism (such as the proxy object) the same way each time. With the design pattern feature of XDE, you can create, store, and reuse design patterns in your models.

Back to top

Getting Started with XDE

Since XDE integrates directly into the Visual Studio .NET environment, before getting started you should have installed Visual Studio .NET. The first release of XDE is designed to work with C#, so make sure you've installed Visual C# as part of your Visual Studio .NET configuration. Later on I'll show how XDE can work with Visual Basic .NET and managed C++ code.

Once you've installed XDE, you may want to dive in and start using it right away, but you have a few things to consider first. As I mentioned earlier, XDE isn't just for use by a couple of high-level architects or analysts in a technology group. It's meant to be used by developers working in teams, so it supports the need for teams to share access to software models. After installing XDE, you'll need to consider how your team will work with and share models and model elements, so that you can configure XDE to meet your needs.

XDE provides four options for storing models and model elements, as described below. Models are stored as files, and, depending on the file storage options you choose, some elements may be stored in separate files as well. You need to choose a file storage policy that best suits how your team works with models.

• Single File: The simplest but least sharable option is to store a model, including all of its elements and diagrams, in a single file. This option prevents you from saving individual model elements or diagrams to a separate file. It might work well for small, exploratory models built by individual developers, but it certainly won't accommodate a team of developers who need to share code and models. You probably won't use this option much in a production team development environment.

• Automatic - Typical: This is the default setting for XDE. It automatically saves in a separate file each package and subsystem in a model, including model elements and diagrams contained within the model. You can still choose to save any individual element or diagram you wish in a separate file. This option is good for teams that divide responsibilities by functional areas that align more or less with packages, where only one or two people for each package will typically modify the model elements in the package.

• Automatic - All: With this option, every model element and diagram is automatically saved as an individual file. It provides the most sharable implementation of XDE; however, because a file is generated for every element, you should carefully consider whether you need this much flexibility (and, for the same reason, it's not ideal for very large elements). Of course, this option doesn't affect how you work with elements within the XDE user interface, but only how sharable your model is and how you store your element files in your source code control system. This is probably a good choice for development teams with many developers who need access to models and model elements.

• Manual: This option requires you to manually save each model element that you want stored in a separate file. All other elements are stored either within the model file or within the package that contains them (if the package has been saved to a separate file). This option gives you a good deal of control over the files that are generated, but it can require extra work to divide up the elements initially.

You can set the file storage option through the Tools > Options command, as we'll see in our example later. For more information on how models are stored, see the XDE help topic "Setting Model File Storage Policy."

Back to top

The Relationship Between Models and Code

Another concept you should understand before working in XDE is the relationship between XDE models and code. There are essentially three types of model that you can build with XDE — an analysis model, a code model, and a reference model — and each model relates to your code and software project somewhat differently.

You might construct an analysis model during the initial analysis and design phase of a project. These models typically describe business requirements with elements such as use cases, and define the initial architecture and high-level design for a project. These models may be related directly to code, but often they're built more for analysis than for code construction. Analysis models are often prepared by analysts and architects and used by developers as a reference for detailed software design.

A code model contains elements that map one-to-one with code elements. You build code models to describe the detailed design of your software. This is the type of model that you can use with XDE's round-trip engineering features to generate code, generate model elements from code, or keep the two in sync. Code models are the heart and soul of XDE and are what developers will work with day in and day out. After all, the whole purpose of modeling software is to understand how to build code. The code, not the model, is the software; the model isn't an end in and of itself. It's important to understand this tight relationship between models and code, because it's the key to improving productivity and to keeping developers as involved with the design of the software as they are with the code.

The distinction between an analysis model and a code model in XDE is minor. It's mostly a difference of intent and purpose: one is focused on defining the problem and the other on building a solution. In general, you'll only synchronize code models, and not design models, with code.

XDE does distinguish reference models from code and analysis models. A reference model represents the elements in a .NET assembly that may or may not have been produced by the development team. You may not always have control over the code in assemblies that your project uses, and in the case of third-party assemblies you may not even be familiar with the design and internals of the code. Reference models are useful for visualizing the design of third-party assemblies or assemblies produced by other teams within your organization. XDE generates these models for you. It can even generate reference models for the assemblies that are part of the .NET platform itself!

Although you cannot modify a reference model, you can add diagrams, such as class diagrams, to your code model and include elements from reference models. This may help you get a better picture of code you're not familiar with.

XDE can generate reference models for any .NET assembly, not just those written in C#. This is the one area where the first release of XDE interoperates to some degree with Visual Basic .NET and managed C++ code: XDE can generate reference models for .NET assemblies written in these languages as well.

Back to top

Creating Your First Code Model

Now that you have this background, I'll give you a tour of what it's like to work with XDE, walking you through the process for creating a simple code model. Here are the steps:

1. Create a new Visual C# project.
2. Add a new code model to the project.
3. Set the file storage policy for the model and save the model.
4. Add model elements.
5. Generate C# code from the model.
6. Modify the C# code to add our application logic.
7. Synchronize the code and model to ensure any changes made in the code are reflected back in the model.

I'll take you through the details of these steps below. In addition, you can download the Visual Studio .NET project (including the XDE files).

Create a Visual C# Project

The first step to creating a code model is to create a new Visual C# project in Visual Studio. To follow along in this example, you should create a C# Windows Application type of project. For this project type, Visual Studio .NET generates a couple of source files, which are accessible from the Solution Explorer. One of these files is named Form1.cs; rename it as frmMain.cs, rename the form frmMain, and set the form's Text property to "Simple Example".

Add a Code Model

At this point, no XDE model file exists. We could create it in one of two ways: by adding a new model to the project or by generating (via synchronization) a new model from the existing code. Granted, there's not much code at this point, but if you're creating a code model, the quickest method is to generate it after creating your project.

To generate the model, right-click the project in the Solution Explorer and choose Synchronize from the context menu. Alternatively, you could select the solution or project and click the Synchronize icon in the Solution Explorer toolbar.

When synchronizing for the first time, you'll notice a flurry of activity in Visual Studio .NET. XDE does several things on initial synchronization:

• It generates a model file for your Visual C# project. This is the model you'll use as your code model.
• It populates the code model with elements that correspond to any code elements — for example, classes, methods, and namespaces — that already exist in your Visual C# project.
• It generates reference models that correspond to the .NET namespaces referenced in your project.

Set the File Storage Policy

At this point, before saving your project, you need to set the file storage policy for the model if you don't want to use the default. For this example, to store each model element in a separate file, change the policy to "Automatic — All" as follows:

1. Choose Options from the Tools menu.
2. In the Options dialog box, click Rational XDE.
3. Under Rational XDE, click File Storage.
4. Make sure the "Settings For" choice refers to your current code model.
5. For this example, change the Store in Subfiles option to "Automatic — All".
6. Click OK.

Now, save the Visual Studio .NET project by clicking the Save All icon in the toolbar. This saves all of your Visual Studio .NET files and also saves your XDE model file. In addition, since you've selected the "Automatic — All" file storage option, each model element is stored in a separate file. At this point you have only one class corresponding to your form, and you should see it in the directory in which you saved your project. Take a moment to examine the directory and the file types for the files XDE has generated.

These files can now be stored in a source code control system, such as Rational ClearCase or Microsoft Visual SourceSafe. You can manage the model and element files through your source code control system just as you'd manage your C# source code and project files.

Developers in a team working on a model set up this way can make changes to model elements without having to fight over access to a single model file. They can check out the files they need, make their changes to either the code or the model, and then synchronize the files and check them back in, making them available for reference or for use by other developers.

Add Model Elements

At this point we're ready to build software. We can add model elements through XDE, write C# code, or both. XDE will take care of the rest by keeping the code and model in sync whenever we synchronize the model. (Note that there's also an autosynchronization feature, which I don't use here but which you can learn more about through XDE's help documentation.) We'll see how this works in a moment; you'll have an opportunity to explore the modeling functionality in addition to learning how XDE generates code from models.

For this example, we'll model a simple "Hello, World" application. The example is simple so that the focus can remain on learning how to use the features of XDE.

Our application will have two classes other than our Windows form, frmMain. The first class, CGreeting, will represent a general type of greeting, and the second, CHelloWorld, will derive from CGreeting. The class diagram in Figure 1 illustrates the relationship. Note that CGreeting has one method, greet, and that CHelloWorld overrides this method.

Next you'll add both of these classes to the main package of your model. To add a class to a package, right-click the package in the Model Explorer, choose Add UML, and select Class.

The easiest way to create a generalization relationship between the two classes is to create it using the class diagram, as follows:

1. Right-click the code model in the Model Explorer and choose Add Diagram.
2. Select Class.
3. Drag each class from the Model Explorer and drop it on the content window for the diagram to include it in the diagram.
4. Select the Generalization tool from the Visual Studio .NET Toolbox and drag it onto the diagram.
5. Place the bottom of the connector over CHelloWorld.
6. Drag the arrow up to CGreeting.

Next, add the greet method to each class. To add a method (known as an operation in XDE) to a class, right-click the class, choose Add UML, and select Operation. You can also add operations to a class by clicking the ellipsis button of the Collections property in the property page for the class and selecting the Operations tab.

Generate Code from the Model

Now that you've defined your classes, you're ready to synchronize your model again and have XDE generate code representing your classes and methods. Right-click the model in the Model Explorer and choose Synchronize, or click the Synchronize button in the Model Explorer toolbar. Then right-click the CHelloWorld class and choose Browse Code. This takes you to the Solution Explorer and highlights the CHelloWorld.cs file. Listing 1 shows the code that should have been generated.

						
namespace HelloWorld
{
    public class CHelloWorld : CGreeting
    {
        public void greet()
        {
        }
    }
}

Notice that XDE not only generated the class definition but also properly generated the inheritance relationship between CHelloWorld and CGreeting in the code, just as you specified in your class diagram. With no duplication of effort, your code was matched to your design.

At this point, let's try to build the Visual C# project and see what happens. From the Build menu, choose Build. Unfortunately, the build fails with a build error in Visual Studio .NET. The error message states:

The keyword new is required on 'SimpleExample.CHelloWorld.greet()' because it hides inherited member 'SimpleExample.CGreeting.greet()'

As we'll soon see, the implied solution to this error is a bit misleading, but the message does indicate the problem correctly: we attempted to override a method improperly in C#. This was not a problem or a bug in XDE, which synchronized our code and model just as we specified. XDE saves us the time of generating our class and method definitions, but it doesn't do everything for us; it isn't magic and doesn't eliminate the need to write code. (If it did, many software developers would be sorely disappointed.)

When overriding methods in C#, we must declare the method in the superclass as virtual and specify that the method in the subclass will explicitly override the method of its superclass. The error message we received was Visual Studio .NET's best guess at what caused the problem, but in this case the new keyword isn't in fact what we need. We can add the virtual and override keywords to our C# code as indicated in bold in Listings 2 and 3.

namespace HelloWorld
{
    public class CHelloWorld : CGreeting
    {
        public override void greet()
        {
        }
    }
}

Listing 3. Code modified by hand in Visual Studio .NET for CGreeting.cs

						
namespace HelloWorld
{
    public class CGreeting
    {
        public virtual void greet()
        {
        }
    }
}

Now rebuild the project and you'll find that this time there are no build errors.

While much of the code you write by hand, such as method implementations, produces no content within your model, it turns out that modifiers such as virtual and override are represented in the XDE model. Synchronize your model and code and then select the greet method of the CGreeting class in the Model Explorer. Look at the value for the LanguageModifiers property: it's now set to the value virtual, which corresponds with the modifier you added in C#. Select the CHelloWorld class and look at its LanguageModifiers property. There you'll see the value override, matching what you typed in C#. With no duplication of effort, the model was kept in sync with the code.

Next, we'll add some implementation code to the bodies of our two greet methods.

Modify the Code to Add Application Logic

Modify the bodies of the greet methods as shown in bold in Listings 4 and 5. Be sure not to forget to include the using statements at the top of each file as shown, or building your project will produce errors.

using System.Windows.Forms;
namespace HelloWorld
{
    public class CGreeting
    {
        public virtual void greet()
        {
            MessageBox.Show("Hi!");
        }
    }
}

Listing 5. Application logic added to the methods in CHelloWorld.cs

using System.Windows.Forms;
namespace HelloWorld
{
	public class CHelloWorld : CGreeting
	{
		public override void greet()
		{
			MessageBox.Show("Hello World!");
		}
	}
}

Now we need some way to call our methods. To do this, let's add two buttons to our form that will call the methods and display the message boxes. Go to the Solution Explorer, right-click frmMain.cs, and choose View Designer. Drag two buttons to the form from the Toolbox and give them the labels shown in Figure 2. Set the name property of the button labeled "Greeting" to btnGreeting and the name property of the button labeled "Hello World!" to btnHello.

Now double-click btnGreeting to generate a Click event handler, and edit the body as shown in Listing 6. Do the same for btnHello, editing the body as shown in Listing 7.

						
private void btnGreeting_Click(object sender, 
System.EventArgs e)
{
	CGreeting grt = new CGreeting();
	grt.greet();
}

Listing 7. Click event handler logic for btnHello

						
private void btnHello_Click(object sender, 
System.EventArgs e)
{
	CHelloWorld hw = new CHelloWorld();
	hw.greet();
}

Rebuild your project and execute it to see it in action.

Synchronize to Update the Model

Finally, I'll show how your model can be updated from the code you write. Open CHelloWorld.cs and type in the code in Listing 8 to add a new method named sayGoodbye to the class.

namespace HelloWorld
{
	public class CHelloWorld : CGreeting
	{
		public override void greet()
		{
			 MessageBox.Show("Hello World!");
		}

		public void sayGoodbye(int numTimes)
		{
			for (int i=0; i < numTimes; i++)
				MessageBox.Show("Goodbye!");
		}
	}
}

Resynchronize your code and model. Then expand the CHelloWorld class in the Model Explorer, and you'll see that the new sayGoodbye method has been added to the model as an operation. Expand the operation and you'll see its argument, numTimes, represented. If you look at the properties sheet, you'll even see the C# type int stored in your model in the TypeExpression property. Even your class diagram has been updated; if you open it, you'll see that the sayGoodbye method is now shown on the diagram as a member of your class.

Back to top

Only the Beginning

XDE has even more features for building consistent software and improving productivity that you should explore. The code templates feature enables you to store and generate reusable code along with the code generated by the defined model elements. With the design patterns tool, senior developers can create reusable design elements that can be applied many times in the same project or in multiple projects.

Whether you use a full implementation of the Rational Unified Process or an agile process like Extreme Programming, Rational XDE has features that developers and development teams need in order to stay productive without sacrificing software design and modeling. Software models are excellent communication tools, but they're time-consuming to maintain. With XDE, you can concentrate on designing and building good software while still producing up-to-date models that the entire development team can reference and work with. Integrated directly with the Visual Studio .NET IDE, Rational XDE is a tool for the entire development team.

Back to top

Acknowledgments

Many thanks to Davor Gornik and Raj Kesarapalli for their assistance in reviewing this article. Thanks also to Caroline Rose for her editing work and to Gary Clarke for his guidance.

Resources

• "Building XML Web services in IBM Rational XDE Developer v2003: A guide for Visual Studio .NET developers" by JJ Kuslich
  
  
• XDE Developer help topics
  

About the author

		JJ Kuslich is a software engineer who designs and builds data-driven business applications. Over the years he has also worked as a software architect and project manager, and has written many articles along the way. He currently works in the Pacific Northwest and lives just 15 minutes from a dozen hiking trails that do his body (and mind) good.

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

Back to top