ClassDesigner's WebLog

Refactoring Support in Class Designer

The language teams added several refactoring features to the editor in the Whidbey release of visual studio.  We attempted, as best we could, to expose these refactoring features through the class designer in ways users would expect them in a modeling tool.  One of the most obvious and seamless of these features is simply rename.  If you have constructors, parameters, members or even method body statements which are using an identifier which is exposed in the class designer, renaming that in the class designer will update all instances of that name in code.  For example if we have the following code and class diagram:

And we then use in place editing to change the name of the Book class to DVD in the class diagram we instantly get the following class diagram and code where all the instances of the Book type have been updated to the new name DVD.

We also expose the C# and VB refactoring commands to extract interfaces from types, to encapsulate fields with properties, and to reorder or remove parameters to methods or properties.  To invoke these refactoring commands right click on the class designer element you'd like to refactor and go to the refactoring sub-menu to invoke the command as illustrated in this image:

There are a lot of refactoring patterns which exist in practice beyond what we’ve supported in this upcoming release of Visual Studio.  We’d be interested to hear what types of refactoring support in the class designer you users would like to see and get value from.  For example I could personally see some value with in a mechanism to split a bloated class in to two classes via designer actions. What other ones to people use and would see value from being supported in the Class Designer.

Class Designer availability

Class Designer will be availabe on all Visual Studio Editions Standard and above.  There seems to be some confusion that Class Designer will only be available in Team Architect and Team Dev SKUs, so we wanted to make it clear that it is not the case.  However, it will not be available on the Express Editions.

Regards,

Ramesh Rajagopal.

Class Designer Team.

No article for this week

Oops! This is the fault on my part. The person who is scheduled to write the article is out of the office this week. Therefore, there is no posting for this week.  Please come back to our site next week.

Thanks!

Patrick Tseng

Visual Studio Class Designer Team

Setting up and viewing relationships between classes

When I’m learning about a new program or teaching someone else about an existing one, I find it helpful to begin by identifying the key classes and seeing how they relate to each other.  There are many different ways that classes can be related.  Three important relationships are inheritance, association, and dependency.  I’ll talk about associations and dependencies in this article.  Inheritance is covered in another article titled Visualizing Inheritance Hierarchies at http://blogs.msdn.com/classdesigner/archive/2005/03/10/391292.aspx.

Expressing relationships between types

Visualizing inheritance hierarchies

HelloJ! My name is Yu Xiao. I am a Software Design Engineer/Test working on Visual Studio Class Designer team. This time I am going to demonstrate how to visualize inheritance hierarchies using Class Designer.

When I was reading existing code, even with well documented one, I always spent a lot of time jumping from one file to another file, one location to another location, back and forth, and then, guess what? I lost. The bookmarks were set everywhere, and I really don’t know where to go back. Then I have to start all over again. This story happened everyday, …, until I started using Class Designer.

Let me use a simple example to show the idea. I have a project to simulate a car racing organization. From the Driver class, I want to find out its base type information. There are several options here - use class view to check its base class, or go to the code editor to find its base class code. But I will show you something else.

Right click the Driver class shape to invoke context menu, and then select “Show Base Class” command.

The Class Designer will find its base class and show it in the diagram with appropriate relationship. In this case, you will see the inheritance line pointing from derived class to base class.

And keep on repeating this operation, you will be able to trace its root down to object class. By this way, it will help you traverse to any base type you want in this class hierarchy.

Now we have the base class. Probably you want to see if there is any other class derived from this CrewMember class. Without Class Designer, you have to do a search and find them one by one. But with Class Designer’s help, this work is trivial – simply right click the CrewMember class shape, and select “Show Derived Classes”.

As expected, another class, Mechanic, will be brought onto the diagram and positioned properly along with current types in the diagram.

Now you can traverse the inheritance hierarchies in a single diagram. Whenever you find something interesting and want to see how it got implemented, just right click the type or member, selection “View Code” command. This will bring you right to the code element in the code editor.

A picture is worth a thousand wordsJ, I won’t say too much here about how easy it would be to understand existing code with Class Designer. Please try it and let us know what you think.

Yu Xiao

Software Design Engineer/Test

Visual Studio Class Designer Team

Visual Studio 2005 Class Designer will not support the C++ language

The Visual Studio Class Designer team is sad to announce that the Class Designer will not support the C++ language in the upcoming release of Visual Studio 2005.  Late last week we were forced to make a very difficult decision, which we are relaying to you today.  Needless to say this was a very painful decision, as we had invested a lot of time and effort in providing support for C++.  However, after analyzing the work items remaining to fully support C++ class design, we concluded it would not be possible to deliver a high quality experience for C++ users by product release.  Therefore, we have decided to remove support for C++ in the Class Designer.  Enabling support for C++ in the Class Designer will be a top priority in future releases of Visual Studio.  For Visual Studio 2005, the Class Designer will support the VB.NET, C# and J# languages.  We welcome your thoughts and feedback on this decision.

The Class Designer Team.

Visualizing class and member details in the Properties window and viewing details from tooltips

Hi! I’m Eugene Chigirinskiy, a Software Design Engineer working on Visual Studio Class Designer. In this blog entry I will give an overview of how the details of various diagram elements (classes, members, inheritance lines, etc) are visualized in the Properties window. Also, this entry will show some examples on how to view details from tooltips in Class Designer.

Quickly view information with tooltips

Tooltips are available for locally defined types as well as referenced types. They display information in language-specific terms, where possible. Usually tooltips can provide very specific information on the UI element. As an example, hovering over method on the diagram will show its complete signature in a tooltip.

To demonstrate what Class Designer tooltips can do, I have created the HTML image map that provides the experience very similar to what users get while using Class Designer. Just hover the mouse over various UI elements on the following diagram based on C# code:

(click the above bitmap to show the full picture)

Using the Properties window to view more information

Class Designer diagrams provide rich information about various code elements, like classes, interfaces, enumerations, type members, etc. But since each of these elements have multiple properties associated with it, it is impossible to show all of them on the diagram and not make it too cluttered. This is where Properties window comes to help. Class Designer uses Properties window to show various details of code elements.

Each code element has its own set of properties. In order to see them in the Properties window, user can select the needed element on the diagram. User can also change values of some properties, making immediate modifications of the the source code. For instance, changing the value of “Access Modifier” property for any class to “private” (in C# project) will immediately change the access modifier for the same class in code. You can even select multiple methods and with one edit change, for example, their Access Modifier from public to protected.

Also, I’d like to mention that Class Designer uses the syntax and terminology of the language of the project. For instance, inheritance modifiers for the class in C# projects will look like this:

Here is the same property for the class in VB project. Please note, that classes in VB cannot be static, so one of the choices was filtered out.

This rule can be applied to all Class Designer UI elements, such as tooltips, toolbox entries, etc.

We will continue improving these features as well as language-oriented support in Class Designer. We would very much like your feedback on using them.

Regards,

Eugene Chigirinskiy

Software Design Engineer

Visual Studio Class Designer Team

A picture is worth a thousand words

G’day! I’m John Stallo, a Program Manager working on the Visual Studio Class Designer.  In this blog entry I’d like to give an overview of what our goals for Class Designer in this release are, and perhaps more if not equally important, invite folks in a lively discussion to help us direct our future path in delivering useful tools for our users.  

But, before I get started, here’s a screenshot to help you get a better idea of the tool I’m talking about (incidentally, it’s a diagram visualizing File System classes in System.IO, which is part of the .NET Framework):

(click the above bitmap to show the full picture)

This reminds me of a quip someone on our team came up with when we first starting building the designer.  It went something like:

A picture may be worth a thousand words, but a class diagram is worth thousands of lines of code.

V1 Class Designer goals

There are certainly many class diagramming tools out in the market today, with some enjoying widespread use.  So while the concept of class diagrams isn’t new, we set ourselves two main goals for the first version when we decided to build a Class Designer from the ground up and fully integrated within Visual Studio:

1. Make class diagrams relevant throughout the development cycle.
2. Focus on the experience to make class diagrams easy and approachable.

Making diagrams relevant not only means that they should provide functionality that makes them useful for development tasks such as code design through to documentation, but also making sure the diagrams remain up to date with the many code changes that occur in a team environment.  This has actually been the biggest gripe with class diagramming tools today, where the diagram is ok for sketching out an initial design, but the headache of managing the synchronization between the code and diagrams becomes such a hassle that the diagrams are thrown away.  Or worse, out of date diagrams end up being included in documentation anyway!

With Visual Studio Class Designer, we’ve tried our hardest to promote the user model that the diagram is just a view of the code.  Any changes you make to the diagram are automatically updated in code, and vice versa – much like today’s Windows Forms designer.  No manual synchronization, no worrying about a model and its code – just choose where you want to make edits and the code and diagram are always in synch for you.  Hopefully, throughout the articles written by my colleagues, you’ll see the work we’ve done to achieve and mitigate tricky scenarios such as team development.

A little about making class diagrams easy and approachable.  This goal is really about reaching critical mass with mainstream .NET developers – so instead of putting the stress on developers to learn new modeling terminology and constructs, Class Designer treats .NET language concepts and terminology as first class citizens on the diagram.  This means that if you’re a C# developer, you’ll see terminology such as ‘public’, ‘protected’, and work with concepts such as fields, properties, methods, and events.  If you’re a VB.NET developer, Class Designer actually surfaces VB terminology such as ‘Public’ and ‘Friend’ and concepts such as Module.  We felt this avoids the developer having to mentally map concepts between diagrams and code when switching between the two.

In general, we felt the experience when using the designer needed to shine.  Shapes needed to look nice and professional, it should be easy to get a quick, default diagram up and running, and customizations that are made in the diagram (such as line routing) should be protected as much as possible.  In short, the tool shouldn’t get in the way of getting work done!

So, what’s next?

To be totally honest, I’m not sure! :)  We certainly have many ideas around what we could do, but ultimately much of what we end up doing depends on your feedback. Here’s how you can participate:

• Download VS 2005 and give Class Designer a try (we aim to have a Beta2 available in a few months time).
• Log bugs (you can even collect votes)
• Let us know what you think on our newsgroup and this blog.  

 In the upcoming weeks, you’re going to see more in-depth blog entries being written by team members on Class Designer features.  This is where your feedback really matters – what have we done well, where can we improve, what are we totally missing altogether?  As our efforts become more focused around planning for the next release, we’ll be sure to share these with you.  I look forward to your input… thanks for your time.

John Stallo

Program Manager

Visual Studio Class Designer Team

Introducing the Visual Studio Class Designer Team Blog