ClassDesigner's WebLog

C++ support added to Class Designer in VS 2007 March CTP

ClassDesigner — Tue, 06 Mar 2007 13:18:00 GMT

The March CTP of Visual Studio 2007 will have support for C++ projects in Class Designer. This will be limited only to visualizing your existing code from native C++ projects.

Editing code from Class Diagrams and Managed C++ projects will not be supported in the Orcas release due to time/resource constraints.

Cheers,

Ramesh Rajagopal.

Class Designer Team.

Class Designer File Format

ClassDesigner — Thu, 28 Jul 2005 19:56:00 GMT

In the past few months, we have covered Class Designer features in the upcoming Visual Studio 2005 release. After reading these articles, you have probably noticed that the serialization format for the diagram file (.cd file extension) is in plain XML format. In this article, I will describe the Class Designer file format in detail.

As you know, the diagram file uses the .cd file extension. If you use the Notepad to open this file, you will notice it is in simple plain XML format. As opposed to a proprietary binary format, we decide to serialize the diagram in the XML format. The reason to use the XML format is for its brevity and simplicity. You can easily understand the element/attribute describes the shape rendering behavior in the diagram. Another benefit is for you to easily diff the delta between iterations. Imagine you are working in a collaborative environment and the .cd file is also checked into the source code control system. You can easily diff the diagram file versions and understand the changes between them. If we’re to store the diagram in the binary proprietary format, you will not be able to make sense out of the deltas.

Consider your have the following code snipped in your class library project.

namespace CDFileFormat

{

public delegate void OrderShipped( Order order);

public class Customer

{

public string FirstName;

public string LastName;

public Address Address;

public void OrderGoods(int productID) { }

public IList<Order> currentOrders;

public event OrderShipped OrderShipped;

}

public class Address

{

public string Street;

public int ZipCode;

}

public class Order

{

}

And you create the following diagram

If you open the actual .cd file from the solution explorer using Notepad, you will see the following XML content.

<?xml version="1.0" encoding="utf-8"?>

<FileName>Class1.cs</FileName>

<HashCode>AAAAAGAAAAAAAAAAAAAEAAAAAAAAAAASAAAAAAAAAAg=</HashCode>

</TypeIdentifier>

</ShowAsAssociation>

</ShowAsCollectionAssociation>

</Compartments>

</Class>

<FileName>Class1.cs</FileName>

<HashCode>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=</HashCode>

</TypeIdentifier>

</Class>

<FileName>Class1.cs</FileName>

<HashCode>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAIAAAAAAAA=</HashCode>

</TypeIdentifier>

</Class>

</Class>

</ClassDiagram>

Here’re the element descriptions:

ClassDiagram: This is the top level element which describes the setting applicable to the whole diagram. Attribute MembersFormat indicates whether we’re displaying class member in name, name_and_type, or full_signature format. In our case, we have value FullSignature which indicates showing member in its full signature form.

Font: Indicates the font used throughout the whole diagram. Attribute Name and size describe the font and size used in the diagram.

Class: For each class (box) shape in the diagram, it has a corresponding element Class in the file. It describes the rendering information for your class. The Name attribute described the fully qualified name for this class. During the file open phase, we’re using this full name to find the type in your project. Attribute Collapsed indicates whether the member compartments are hidden or not. In the above example, member compartments in Address, Order and System.Object classes are hidden from the user. Attribue HideInheritanceLine indicates whether the inheritance line is hidden or not. In our example above, both Address’ and Order’s parent class (System.Object) are present in the diagram. However, notice that the inheritance line is not being drawn because I chose to hide it for both the Address and Order classes.

Position: The shape position in the diagram. The (X, Y) coordinates are relative to the upper left corner of the diagram. The unit is in inches.

TypeIdentifier: This is used to identify the class in your actual project. E.g. Let’s say you have Address class shown in the diagram and you close the diagram. The next day, your co-worker changes the class name to LocalAddress in the project. When you open the diagram again at later time, we cannot find class Address in the project anymore. In this case, we will be using the FileName and HashCode with the heuristic algorithm to determine shape Address is now class LocalAddress is the project. If we cannot determine where the class is, the Address shape will be shown in red color. This is what we referred to as Orphan shape in the diagram. For details on orphan shape, please refer to the previous blog article.

ShowAsAssociation and ShowAsCollectionAssociation: These two elements represent which field/property is being shown as association/collection_association to other class in the diagram. If you look at the example above, you will notice that field Address and currentOrders are rendered as association lines in the diagram.

Members: This element holds a collection of hidden members in the shape. In our example above, field Customer.FirstName is hidden in the diagram.

Compartments: This element contains a collection of member compartments which are hidden in the diagram. In our example above, we see the Events compartment is hidden in class Customer.

As you can see, the XML file format we use is pretty straightforward. By comparing the diagram with the XML text, you can see how the diagramming information is maintained in the XML file. If you have a complex diagram, you might want to open the .cd file using Notepad. You will find interesting information in it.

Have you installed the latest CTP and tried out the Class Designer? As we are wrapping up the current release, this is also a good time for you to provide feedback to us. Do you have any suggestions on what topic we should be covering in the coming months? Any missing features you would like us to address? We would love to hear your feedback...

Regards,

Patrick Tseng

Visual Studio Class Designer Team

June CTP available

ClassDesigner — Thu, 16 Jun 2005 03:44:00 GMT

For more information about this CTP and see if you really want to install it, see this post in Rob Caron's blog: http://blogs.msdn.com/robcaron/archive/2005/06/15/429278.aspx

I'll add that this build should have the option to show method signatures on the diagram.

Thanks,
Ramesh Rajagopal.

Class Designer Hands on Lab in TechEd 2005

ClassDesigner — Fri, 03 Jun 2005 14:23:00 GMT

I will be attending this year's Microsoft TechEd in Orlando Florida from 6/6~6/10. There's a HandsOnLab (HOL007 in ARC07 track) for the Class Designer beta2 bits which you can try it out. I will also be spending 25 hrs in the ARC cabana booth. That's like 4~5 hrs a day. Please swing by and we can chat on features, ideas about Class Designer.

Speaking of HandsOnLabs, the following hands on labs are also from our team.

1. ARC01-HOL001: "Using the Distribution System Designer to visually design and validate service-oriented system"

2. ARC02-HOL002: "Using Application Designer to design your Web Service Architecture"

3. ARC03-HOL003: "Using the Logical Datacenter Designer for Configuration and Deployment"

4. ARC04-HOL004: "Build a Domain Specific Language Designer Using the DSL Tools"

You might want to check them out...

Patrick Tseng

Visual Studio Class Designer Team

No Articles for the next few weeks...

ClassDesigner — Wed, 25 May 2005 07:21:00 GMT

You’ve probably know why we will not have blog articles for the next few weeks. The team is currently busy working on fixing bugs. We will resume our weekly blogs articles in a few weeks. In the meantime, please let us know specifically:
1. What topics would you like us to cover?
2. Suggestion on future features.

Thanks ahead for your input!
Patrick Tseng
Visual Studio Class Designer Team

PowerToys for the Visual Studio 2005 Class Designer and Distributed System Designers

ClassDesigner — Tue, 17 May 2005 10:17:00 GMT

We’ve published a set of set of add-ins which augments existing functionality in the Visual Studio 2005 Class Designer and the Distributed Systems Designers. The Design Tools Enhancements add-in provides a common set of features that can be used by both the Class Designer and the Distributed System Designers, such as pan/zoom window and rich formatting commands. The Class Designer Enhancements add-in provides additional functionality for the Visual Studio 2005 Class Designer, such as HTML export and nested type creation commands. This download includes all necessary source code and a Visual Studio project template for creating your own add-ins for the Visual Studio 2005 designers.

The installer and source code are available for download from gotdotnet workspace. The installation requires the Beta2 version of Visual Studio 2005 installed on the machine. You can use the Class Designer MSDN forum or discussion boards in the workspace to post any questions/feedback on the add-ins.

Here is a list of features provided by the add-ins (you can find more detailed description in the documentation installed by the download):

Design Tools Enhancements

Diagram Search
Formatting Commands
Floating Property Grid
Pan/Zoom Window
Design Surface Scrolling Improvements
Create Comments with Double-Click
Design Surface Grid

Class Designer Enhancements

Export Diagrams for Web
Display Xml Comment Command
Documentation Tool Window
Filtering Appearance
Filtering Lines
Filtering Members
MSDN Help on System Types
Fast Navigation
Interface Lollipop Labels Commands
Inheritance Visualization Commands
Show Type Command
Association and Inheritance Line Dongles
Create Tests Command
Type Creation Commands
Add Member Commands
Synchronization with Code Definition Window
View Class Diagram Command Improvements

Creating Custom Add-ins

Enjoy!
Dmitriy Vasyura
Class Designer Team

Orphan Shape in the Class Designer

ClassDesigner — Thu, 12 May 2005 07:47:00 GMT

One of the biggest value propositions of the Class Designer is to keep class diagrams always in-sync with code – in fact it is supposed to be another view of your code. Code is the ‘model’ behind class diagrams. If you open a class diagram file in an xml editor you will find that all it contains is the visual information – placement of the shapes, hidden members if any, association lines if any, etc. The thing that associates a shape to code is the fully qualified name of the type it is representing and the source artifact that type is defined. You can find more information on the file format of class diagrams in an upcoming blog post.

When you open a class diagram, Class Designer will look for the type associated with each shape by its fully qualified name and associate it with the shape. The members of the type are dynamically populated by parsing the source files or retrieving it from the assembly (as the case may be). If the class diagram is open, the class designer will listen to change events to update the diagram to reflect the changes made to the code. When you save the diagram, the fully qualified name of the type and the artifact it came from (source file/assembly) will be persisted in the diagram file.

However, what happens if you rename a class (or its namespace) with the class diagram closed? Or what if, in a team scenario, somebody just checks out source code, makes the changes and checks it back in, without updating the diagram? When the diagram is opened, since Class Designer will try to associate the shape with the fully qualified name of the type, it won’t be able to find the shape’s type and load the member information. If it is unable to find a shape’s type Class Designer will remove the shape from the diagram. But you might have spent considerable effort customizing your shape – for example, grouped them by access, hidden some of the members, shown some of the members as association lines, manually placed line ends etc. If the class designer removed the shape you’d have to redo the whole thing again (of course if you had the diagram opened while you refactored your code, Class Designer will be able to listen to the change events and update the diagram).

Here are a couple of shapes before customization.

Here are the shapes after the following customizations:

XmlNode
- Methods compartment is collapsed to hide all methods.
- The Attributes property is shown as a line pointing to XmlAttributeCollection class, rather than just a regular member inside the shape.
- The following properties are hidden on the diagram: BaseURI, InnerXml, IsReadOnly, LocalName, NamespaceURI, NextSibling, OuterXml, OwnerDocument, Prefix, PreviousSibling, SchemaInfo.
- “Lollipop” is collapsed – the diagram now communicates that the class implements one or more interfaces, but it isn’t important to show in this diagram precisely which interfaces are implemented.
XmlAttributeCollection
- Shape is collapsed to hide all its members.
- Width is increased so that entire name is readable.

Class Designer has a couple of cool features that helps you preserve your shape customizations in scenarios described earlier (refactoring your code with the class diagrams closed). I mentioned earlier the thing that associates a shape to code is the fully qualified type name and the source artifact name. Well, there is one additional piece of information that is also stored for a shape – a hash code value. This value is computed from the member signatures (other than constructor/destructor) of the various members in the class. When the class diagram is opened, if the class designer cannot find the type in the source file, it will look for other classes defined in the same file and compute the hash value for those classes. If it finds one that falls within a certain pre-determined threshold percentage, then class designer will assume that type to be the one representing the shape and associate it with that shape. Obviously, this heuristic will work better if the class has more members. The reason we don’t require an exact match of the hash value is because it is likely that along with the rename, you might have added or changed a few members. But it may be the case that you also changed the file name along with the class name. If this is so, the class designer will go through all the files in your project and try to find a class that is the best match. Note if your project contains a lot of files this will result in a delay in opening the diagram. If your project contains more than 50 files, Class Designer will give you an option of doing this search or not.

Under what circumstances will I see orphan shapes in my diagram?

The class designer makes a reasonable effort to keep your diagram intact by using this heuristic. However, as any solution based on heuristics, it is likely that there are situations where Class Designer cannot make an association between a shape and the type it represents. Or you may have a large project and choose to not wait for Class Designer to search through all the files to look for a match. In such situations, when you open a diagram, you will get what we call an “Orphan” shape on the diagram for any shapes that cannot be associated with its type. Here is an example:

The following table lists the possible causes for an orphaned shape in your diagram.

If user does the following while diagram is closed	Class Designer will react as follows at diagram load time
Class code is significantly changed such that CD can no longer associate the shape with its code.	Shape is displayed as orphaned. The user can delete the shape or associate it with existing code.
Deletes class	Shape is displayed as orphaned.
Removes reference to assembly or project	Shape is displayed as orphaned.
Unload referenced project (class resides in the referenced project)	Shape is displayed as orphaned.
Delete or remove class’ source code file from project	Shape is displayed as orphaned.
Moves class to another file	Class Designer should be able to associate the shape and its code, as long as the code has not significantly changed.

If you hover over the shape you will get tooltip text that says code is missing for the shape and how you can associate the shape back to the type.

As the tooltip text suggests, you can either type in the new fully qualified name for the shape (either in-place on the shape or in the property browser) or drag and drop the renamed type from Class View. Once this association is made, the Class Designer will restore the shape with all the customizations that still apply including lines coming to and going from the shape!

A simple walkthrough:

The following section provides a simple walk through that lets you experiment with this feature:

1. Create a new C# class library. In the auto-generated class Class1, add a new method foo which looks like this:

public void foo(int i)

{

}

2. Create a new class diagram which looks like

3. Save and close the diagram.

4. In source code, rename class Class1 to MyClass

5. Re-open the diagram and you will see that the diagram now shows class MyClass

In this example, Class Designer’s heuristics determined that there is a high probability that the shape that used to be associated with Class1 ought to be associated with MyClass. In most cases, the heuristic can reconcile differences well enough to re-associate shapes to types. In the event it cannot, please read on…

You can re-associate an orphaned shape to a type using one of the following methods:

1. Drag/drop a type node from Class View onto the orphaned shape. The orphaned shape will display appropriate drop target feedback when a Class View type is dragged onto it for re-association.

Here are a couple of things to keep in mind:

a. You cannot drop a selection containing multiple types from the Class View onto an orphaned shape. If you try to do so, a no-smoking icon will appear to indicate that the shape is rejecting the types.

b. You cannot drop a type from Class View onto an orphaned shape if the type is already represented by another shape on the diagram. A no-smoking icon will appear to indicate that that type cannot be dropped on the shape.

2. Rename the shape to match the name of the type that you want it to be associated with. You can rename a shape by single-clicking on its name; this will put you in edit mode. Alternatively, you can right-click on the orphan shape and choose “Relink Shape with Code” and then enter the name of the type that you want the shape to be associated with. When you’re done, press ENTER to commit the change.

3. Another alternative is simply to rename the class in the code file to match the name of the orphaned shape. Class Designer automatically will recognize the match and associated the type with the shape.

4. Or, if you don’t want the orphaned shape anymore, you can simply delete it.

Ramesh Rajagopal and Patrick Tseng

Microsoft Visual Studio Class Designer Team

Using Class Designer to document your code – Exporting diagrams as images

ClassDesigner — Thu, 05 May 2005 04:09:00 GMT

One of the design goals of Class Designer was to enable developers to easily document the design of applications and keep it in sync with the code. Class diagrams residing in Visual Studio projects solve this purpose very well, however more traditional documentation formats commonly used for external documentation or presentation such as Microsoft Office documents or web-pages, require diagrams to be saved in some image format.

“Export as Image” functionality provided by Class Designer allows you to export all or a subset of class diagrams inside a solution with a few mouse clicks. In this post I’ll describe how to use this feature to produce project design documentation and keep it in sync later on.

Preparing Diagram for Export

Before you save diagrams as images for embedding into Office documents or publishing on the web, you can use class diagram annotation and customization features to make diagrams better explain your design.

While working with a class diagram within Visual Studio tool-tips and live code are available right there to look at, this information is not accessible when diagram is saved as an image – thus you might want to display types of members on the diagram using the “Display Member Types” command available from toolbar or diagram context menu.

In case you’re documenting a general-purpose API which will be consumed by external customers, you might want to filter members visible on the diagram to those of public and protected visibility and hide all private/internal details of implementation. You can use “Group by Access” mode of the diagram (available from toolbar) to see all private/internal members in groups and hide groups of members by invoking “Hide Compartment” command on Private or Internal compartments. Another thing to consider would be removing private/internal types from diagrams for

Finally, you can make great use of comment shapes to annotate your diagram to explain design decisions and to clarify the purpose of different elements. To create a comment shape, open the Toolbox tool window, then drag & drop a Comment item on the diagram and enter your annotation text.

Here is an example of a class diagram customized for documentation:

Exporting Diagrams as Images

When the diagram(s) are ready for export, simply right-click empty design surface area of the diagram and choose “Export Diagram as Image…” menu item – you will see Export Diagram as Image dialog opened and the active diagram checked in the diagrams list:

If you click Export button now a diagram image with the same name as diagram name and .png extension, designating Portable Network Graphics format, will be created at the same location where your solution (.sln) file is located on disk.

Lets take a quick look over dialog elements.

Diagrams check list – this element allows you to choose diagrams to be exported and contains a full list of all diagrams included in the projects of the currently opened solution.

Overwrite existing files – this option switches on or off the prompt for image file overwrite – when the check-box is set (the default), Class Designer won’t ask you to overwrite existing files.

Export location – specifies path of the folder where diagram image files will be created.

Image format – allows you to choose the format of exported images from a list of standard formats (BMP, JPEG, GIF, PNG, TIFF and EMF). If you need a quality/size balance, PNG format is probably a good choice, however if quality is important and/or diagram is large and needs to scale, EMF (Enhanced Metadata Format) might be a better choice.

When you click Export and all checked diagrams are exported to specified location in format selected, dialog settings are also stored in the user options file (.suo) for the opened solution. Next time you use the Export dialog, all choices are preserved unless you change it again or remove the .suo file from solution folder.

Documentation Scenarios

Now lets take a look how “Export Diagram as Image” functionality can be used in documentation scenarios.

One scenario is when diagrams are published to web and linked from web-pages – in this case most likely there’s a folder on the web-site containing diagram images, so specifying this folder in the “Export Diagram as Image” dialog would directly update the web-site content replacing existing diagram images with the current versions.

When documentation represents a set of Office documents, diagram images are embedded into the documents. You do so by using “Insert | Picture | From File…” command from Microsoft Word menu. This menu item brings Insert Picture dialog which lets you choose the image to insert. Default behavior of this command is to copy image into the document. However another option might look more attractive from the point of view of continuous updates to diagrams used within the document when code they’re generated from is changing. Instead of storing the image in the Word document itself, store a link to the image file in disk – you can choose this option by clicking on the down arrow icon on the “Insert” button of Insert Picture dialog and choosing “Link to File” or “Insert and Link”:

In case of “Link to File” the document will always display the external image file and in the case of “Insert and Link” the image will still be inserted into the document, however a link to the file on disk will be added so that when the image file is updated, the image stored in the document will be updated as well.

Using image linking option you can keep your design documentation up-to-date with minimal effort by invoking the “Export Diagram as Image” command from Class Designer. Images in design documents will be updated automatically when you update diagram images using Export as Image.

Copy Image Command

Cases when you need to copy/paste just a single class shape or a couple of types with lines from a class diagram to a Word document or e-mail are quite often. Exporting the whole diagram in such situations neither practical nor reasonable. For these cases Copy Image command available on type shapes and/or multiple selection of those comes in handy – this command places the image of current selection on clipboard in BMP and WMF formats. When you paste “Copy Image” result into raster applications such as Paint the BMP format will be placed. Pasting into Word documents will paste a vector-base scalable image of the diagram which doesn’t loose quality/clarity on reasonable resizing.

What is the difference between Copy and Copy Image?

You might ask why there are two commands available – Copy and “Copy as Image”? The usual Copy command (available via Ctrl+C) places on clipboard shape information (e.g. for cloning code or copying the shape to another diagram) as well as regular raster BMP image of selection. “Copy Image” command as described above places BMP format as well and WMF format, but doesn’t place shape info, so it can’t be used to copy the shape.

Dmitriy Vasyura
Visual Studio Class Designer Team

Class Designer Integration with Source-Code Control

ClassDesigner — Thu, 28 Apr 2005 08:13:00 GMT

Class Designer Integration with Source-Code Control

Class Designer is built for use with solutions checked into source-code control systems. For those of you using Visual Studio Team System (VSTS), this will mean you are plugged into Team Foundation source control. If you are using a Standard or Professional SKU then you can install Visual Source-Safe which comes bundled with Visual Studio. In this article I will be showing you screenshots from the excellent integration Class Designer has with Visual Studio Team Foundation (VSTF) source control. Let’s discuss the main scenarios.

Check in

Check in scenarios are simple. If you have a solution which contains a Class Designer you can check it in along with the rest of your solution. Here’s a screenshot:

Once you check in the solution you will see an icon next to the Class Diagram file which indicates it is checked in.

Check out

Check out scenarios are more interesting. By default most SCC providers have ‘Check out automatically’ turned on. In this case any changes you make will automatically check out the affected files. If you want to change these settings look in the Visual Studio menus under Tools | Options | Source Control | Environment. I like to see what files I’m editing so I have it set to ‘Prompt for check out’ as shown here:

When you make a change to the diagram you will see a ‘Check Out for Edit’ dialog as each file is modified.

There are three types of changes one can make to the diagram which will cause SCC actions to occur. The first are presentation edits which only check out the CD file. If you have a diagram and would like to make some changes to the appearance of the shapes, lines or members then these changes will only require you to check out the diagram.

The second types of changes are actions on the diagram which check out code-file(s). Changes such as creating an inheritance or association, implementing an interface, deleting a type, or modifying members will cause the code-file to be checked out. You will be prompted to check out the diagram as well if your change affects the presentation of these elements on the diagram.

The third types of changes are actions on the diagram which cause the check out of the project. Creating a new type by dragging it from the Class Designer toolbox can create a new file for this type. This will prompt you to check out the project file and then the diagram file.

What happens if I cancel a check out?

You might make a change to the diagram which attempts to change a file you do not have access to (in the case of exclusive check out), or you can simply decide not to check out a file. If you have ‘Prompt for check out’ turned on than you can click ‘Cancel’ when the ‘Check Out for Edit’ dialog pops-up. In cases where you cancel checking out the first file you won’t need to worry, the change will be aborted immediately. Things are more complicated if you accept the checkout of a code-file or project and then cancel the checkout of the diagram. In this case the diagram can not be updated and will close. The following dialog will appear to let you know what happened. Don’t worry, the diagram will remain intact, just re-open it.

What about merge conflicts?

Class Designer is designed to be a team-working tool. Developers make conflicting changes to their code. Since the diagram is just a representation of the code, it too must be ready to handle these conflicts.

CD files are represented by XML. The format of these files is intentionally easy to read and easy to merge. We also take advantage of the XML merge tool provided with Visual Studio Team Foundation. When a merge conflict is detected the source-code control system will attempt to auto-merge the conflicts. If this can not be done automatically then the user is given the option to manually merge the files. Here is what the XML merge tool looks like:

In this simple example one user has hidden a member and the other has expanded a compartment in the same class. This has resulted in a conflict. As you can see the user has the option to accept one, both or neither changes. Once the user has resolved all conflicts then the file is saved and can be checked in.

Erik Cutts
Visual Studio Class Designer Team

Auto Layout of Class Diagrams

ClassDesigner — Sat, 23 Apr 2005 07:00:00 GMT

By now you hopefully have the beta 2 version of Class Designer. If not, maybe this beta 2 feature will convince you to get it.

One of the new features in Class Designer beta 2 is Auto Layout. In the olden days (pre beta 2), the default layout you got when you visualized classes on a diagram was quite far from pretty. You had to spend a fair amount of time manually moving shapes around to make the diagram look presentable and easy to understand. And if the diagram was anything beyond 30-40 shapes, you could forget about doing all that by hand.

But in the flashy new Class Designer, we make life much easier for you. When you add types to a new or existing diagram through the Class View or Solution Explorer, we automatically lay them out for you.

You’ll also notice a new item on the Class Designer toolbar that looks like this: . You can click on this to automatically layout the diagram anytime you want. Using the toolbar button, you can layout a selection of shapes, or an entire diagram (when nothing is selected).

The layout algorithm takes into account inheritance and association relationships. Any types that don’t participate in either of these relationships will be placed in a grid on the right of the diagram.

A well laid out diagram does make the diagram look aesthetically pleasing, which is important in its own right. But looking pretty is just a small part of the picture. More importantly, a well laid out diagram makes it so much easier to understand the structure of the code, the inheritance hierarchies, and the relationships between classes. But you probably knew that already.

Of course, we don’t expect that the auto-layout feature will be the panacea for all your layout issues. In many cases, it provides a very good default layout for the diagram. If the default layout is not good enough, we expect that it will provide a good starting point for further customization of the layout to the users taste and to more accurately reflect the semantics of the diagram.

Ok, enough typing. I’ll let the pictures speak now.

System.Xml namespace

System.Xml.dll

System.Windows.Forms namespace

We're looking forward to feedback from you on this cool feature.

Thanks,
George Mathew
Visual Studio Team System - DSL Tools