Rakesh's Blog

Thank you.

2005-03-04T01:13:00Z

The readers of this blog had provided great feedback. We would like to consolidate our customer reach. As part of that effort, I will be closing this blog. I kindly request you to follow our team blog at http://blogs.msdn.com/classdesigner. Please continue providing us your inputs so that we can build great products for you. Once again thanks for sharing your thoughts here.

Exporting Diagrams

2005-02-11T17:58:00Z

The user can create multiple class diagrams using the Class Designer. Every class diagram could be explaining a part of your code base.

There are diagrams in design docs that provide a better explanation for the design. Also diagrams are a big plus in User Guides. But one of the pains is keeping these diagrams up to date with the changing code base.

We provide “Export Diagram” menu option that will allow you to export your diagram to a few formats. You can export the diagram to a desired location. Then you can have your design docs or user guides pick the images from that location. Over time as the code changes the diagrams will stay synchronize. Remember that the diagrams are a view of your code. You can export the diagrams every now and then and have your design docs & user guides always pointing to the recent architecture.

For a peek at the export dialog – click here.

Chat with us.

2005-02-01T06:04:00Z

Our team will be holding MSDN online chats on Feb 1st. You can chat with the team that builds Class Designer.

Visual Studio - Class Designer
Chat with members of the Class Designer team. Class Designer offers visualization features to help you understand, design, and refactor code. You'll learn more about what's coming in the tool for Beta 2, and have an opportunity to give feedback on what code modeling features you would like to see in the future.

Add to Calendar

February 1, 2005
5:30 P.M. Pacific Time
Additional Time Zones

Enter Chat Room

If the above link doesn't work then go to http://msdn.microsoft.com/chats/ and enter chat room for "Visual Studio - Class Designer"

Thanks in Advance.

Interface Implementation

2005-01-26T19:04:00Z

Class Designer generates default stubs for interfaces inherited by your class. Say you had IDriveable interface in IDriveable.h and a Mechanic class in Mechanic.h file

IDriveable.h

#pragma once

__interface IDriveable

{

int Stop();

char Start();

};

Mechanic.h

#pragma once

class Mechanic

{

public:

Mechanic(void);

~Mechanic(void);

};

If you view the Class Diagram for this code in the Class Designer you will see… click here

Choosing the Inheritance option from the toolbox the user can create an inheritance from Mechanic class to IDriveable interface. In response to this action, the Class Designer generates stubs in the Mechanic class. Note that we have also included the header file IDriveable.h in the Mechanic.h file. If you remember this was something you all requested that we do in an earlier post.

The code now in Mechanic.h is…

#pragma once

#include "IDriveable.h"

class Mechanic : IDriveable

{

public:

Mechanic(void);

~Mechanic(void);

int Stop(void)

{

}

char Start(void)

{

}

};

The Class Diagram for this code in the Class Designer would change to… click here

A shortcomings I notice are

· The code generated would not compile because the Start and Stop methods have return types.

· The stubs are generated to the header file and not to the corresponding Mechanic.cpp file.

If you have suggestions on how we could improve the user experience please let me know.

Is C++ dying?

2005-01-14T23:10:00Z

Thanks for all the mails sent by the readers enquiring about the long silence. I took a long vacationJ. I started to learn to ski this season. But unfortunately this winter season seems to be a disappointment for ski enthusiasts.

I will continue to keep you posted on how the Class Diagram is shaping and keep requesting you for feedback on issues we face.

When I started this blog some readers were saying that C++ is a dying language. Here is a related post http://www.microsoft-watch.com/article2/0,1995,1684756,00.asp

Namespaces

2004-11-14T00:33:00Z

I have heard this a lot of times… 75-80% of the C++ code out there doesn’t use namespaces. A lot of C++ developers do not use namespaces.

Is this a valid assumption?

I would appreciate if you could share your opinion about this.

If we were to believe that most C++ code or C++ developers don’t use namespaces, it could influence how we triage/prioritize some bugs and how content we are with some fixes in Beta2.

Bind Dependency

2004-10-29T05:54:00Z

Last week we had an intra team challenge. Our manager offered to put on the apron and grill some bbq if we hit some phenomenal bug fixing goal he set. We strapped ourselves to the seats in our offices and took up the gauntlet. Glad to inform you that we succeeded and I hope he makes something good and make us feel that it was worth the sleepless ride last week.

Here is a question I received from Bryan Rieger… click here

Bind Dependency?

Click here and this page gives a good explanation of bind dependency.

Here is an example we will use…

generic<typename T>

public ref class Collection{};

public ref class Class1

{

Collection<float> myFloatCollection;

};

Answering Bryan’s questions…

Would the Collection<T> be modeled as a parameterized class?

Yes. To view the parameterized class... click here

If it is modeled as a parameterized class, will you be supporting bind dependency?

Yes. In the Class Designer shown in the link, you right click on field FloatCollection and select “Show as Association”. To view the UML equivalent bind dependency created… click here

Here is my own follow up question…

If we model templates and generics as parameterized classes how do we differentiate them in the model?

I created a template class called Container. I have juxtaposed the Collection generic class and the template Container class on the designer. They both show as parameterized classes but check out the title right after the class name… click here

Default Template Argument.

2004-10-15T04:22:00Z

When the user drags an inheritance line to a template or specialization, what would be good defaults for the generated template arguments?

Say in code I have...

template <class T> List {};

class MyClientList {};

The user drags an inheritance line from MyClientList to List<T>. Currently we have set the default template argument to “int” and so the code generated will be…

template <class T> List {};

// We generate the inheritance to code

// and instantiated template List<int>

class MyClientList : public List<int> {};

And here is one of the issues we run into.

If the code was this…

template <class T> List {};

template <> List <int> {};

class MyClientList : public List<int> {};

Our default as “int” is wrong, because the user intended to inherit from the primary template List<T> and not from List<int>. You can think of various other cases where keeping the default as "int" would generate wrong and even code that wouldn't compile.

I would like to get your feedback on what would be a good default template argument.

I was thinking that we will not try to generate any default. We will just plop the parameter names as they appear.

So for the above example when the user dragged an inheritance from MyClientList to List<T> we would generate…

template <class T> List {};

template <> List <int> {};

// Note that the default template

// argument in now “T” instead of “int”

class MyClientList : public List<T> {};

Yes it doesn’t compile, but is it better than default always being “int”? And also note that you can select the inheritance line and change the template arguments.

Please post your feedback and I am sure you will have some better suggestions.

#include

2004-09-17T01:07:00Z

Say I have the following code in

Employee.h

namespace Company

{

class Employee {};

}

Manager.h

namespace Company

{

class Manager {};

}

When the user drags an inheritance line between Manager and Employee, we will generate the following code in Manager.h…

Manager.h

namespace Company

{

class Manager : Company::Employee {};

}

Your feedback on the following issues will be appreciated.

Note that we didn’t generate the “#include Employee.h” in Manager.h file. Would it be reasonable to assume that the user will have to deal with inserting proper include statements in the Manager.h file?

The following are some of the reasons that deter us from doing it ourselves

· Redundant #includes may introduce clutter, may cause compilation errors

· It will be difficult to find the correct path to Employee.h

· What if the user #includes everything in a precompiled header

· What if the #included header requires other #includes before it? Many headers do not embed #includes for dependent headers, instead relying on the .cpp to #include the dependent headers separately. We cannot figure out what is ‘right’ without a proper dependency graph.

· Yes what we generated won’t compile but at least we just did what the user requested. It is in a better state, than actually generating something more than what the user requested and that causing more compilation errors.

Would you prefer that we generate “Company::Employee” or just “Employee” as the base name? If we do the short name the generated code will be…

namespace Company

{

class Manager : Employee {};

}

Association

2004-09-10T15:33:00Z

Here is a link to a site that describes what “Association” means in UML 2.

We have “Show as Association” in the context menu. Choosing the option displays a line between the two related types.

For example, if you have the following standard C++ code…

class KeyBoard {};

class Computer

{

KeyBoard* keyBoard;

};

You view the classes in C++ Class Designer. You then right mouse click on the “keyboard” field in the “Computer” class. The context menu would show up.

You choose “Show as Association” and we will show a relationship between “Computer” and “KeyBoard” classes.

If you check out the image that shows the context menu, you will find another menu item “Show as Collection Association”. What this would do is…

using namespace System;

using namespace System::Collections::Generic;

public ref class Customer

{

List<Order> orders;

};

If you right click on the field “orders” and choose “Show as Collection Association”, then it would actually draw a line relating the “Customer” class and the “Order” class, which is the collected type. Choosing “Show as Association” on the same field would actually draw a line relating “Customer” class and the “List” class.

Is the name “Show as Association” and “Show as Collection Association” intuitive enough?

Would UML aware users not like it, because it is the simplest form of Association and has no other decorations to it and also a Composition would be shown as an Association?

Would semi UML aware or non UML aware users find the words “Association” and “Collection Association” overwhelming? Would they be discouraged to use the feature or the term, so as to avoid any miscommunications with their UML aware colleagues? If so, could you please suggest some alternatives?

Pictures!

2004-09-01T21:30:00Z

Finally I have managed to link to some pictures.

A complete picture with C++ Class Designer flanked by other tools that complement it - http://www.winisp.net/rakeshnamineni/images/Everything.jpg

The Class Designer - http://www.winisp.net/rakeshnamineni/images/Designer.jpg

The Class Details window –

http://www.winisp.net/rakeshnamineni/images/ClassDetailsWindow.jpg

The Toolbox - http://www.winisp.net/rakeshnamineni/images/Toolbox.jpg

The Class View - http://www.winisp.net/rakeshnamineni/images/ClassView.jpg

The Property Page - http://www.winisp.net/rakeshnamineni/images/PropertyPage.jpg (Note that I had posted that all of this would be ReadOnly)

Resolving Templates

2004-08-25T15:16:00Z

How often do C++ developers write specialized templates?

Just to make sure that I don’t mislead you on the terminology, here is an example…

// Primary List template

// initialCount is the default parameter

template <typename T, int intialCount = 0>

class List {};

// List template is specialized for "int"

template <>

class List<int> {};

You know that in a C++ Class Designer user can right click on a member (field or property) and do “Show as Association”. Also the user can right click on a type on the diagram and do “Show Base”. Moreover the user can drag drop any type from Class View on to the diagram. In all such cases we have to go and fetch the right type.

We are finding it very difficult to resolve template specializations to the right type, especially when they employ default parameters. So I would like you to give me your opinion on how often C++ developers write code that specializes templates. And when they use libraries that employ template specializations (STL does) how often would they like to browse to those types in that library.

What would you prefer in case we can’t resolve to the correct type?

Some of the choices are

Not support template specializations at all. Note that STL employs a lot of template specialization.
Try to resolve and if we can’t (especially when there are default parameters) then put an error message. Again STL uses a lot of default template parametersJ.
Try to resolve and if we can’t resolve then always fetch the primary template. But it could be the wrong one.

Templates and Generics.

2004-08-19T23:16:00Z

While trying to scope the support for Templates and Generics in Class Designer, I wanted to know the difference between them. I came across this posting by Brandon Bray, who is a Program Manager in C++. Hope you find it useful as well.

Type overloading of generics is allowed in C# and VB.

For example in C# overloading of the generic type is possible.

public class Bar <T> {}

public class Bar <R, S> {}

I recently heard from Brandon that C++ will not be able to support this for Whidbey.

Feature Requests

2004-08-10T23:47:00Z

Title : Feature requests.

Chris Monachan had requested…

I'd like to for instance, arrange classes by protection (private/public), but also by method/data at the same time. So I can print out diagrams with say just the public methods, nothing else.

In the Class Details Window you can hide members/compartments that you are not interested in visualizing. So you can hide the protected and private member. Hope that addresses your request. If I am not addressing the issue correctly please provide me an example on what you need.

Also, in terms of a planning tool, it would be nice to put in bold pure virtual functions, or somehow indicate them in the diagram.

This is a great suggestion. I also received feedback from other sources that they would like to see this. I don’t have this scheduled for Whidbey but will add this to our TODO list for the next release.

Amit Bahree had requested…

I would like to get some more control using the keyboard. It is a *big pain* trying to add new members using the Mouse. I would prefer something along the lines of how Rose does it where I can quickly add new members all usin keyboard shorcuts.

Actually in my earlier posting I had sought feedback regarding making Class Details Window in C++ Class Designer read only. So if that proposal goes through unchallenged then you wouldn’t be able to add membersJ. But we had taken extensive effort to make editing the grid based tool window very easy to use. If you are still using beta1 bits please refer to this link to know about some tips on editing the Class Details Window. The tips would still be useful if you happened to use Class Designer for languages other than C++.

Quality or Quantity

2004-08-05T16:24:00Z

I have to agree that in the recent weeks as more and more people have started using C++ CD, we have observed a spike in our incoming bug rate. I had a discussion with my Program Manager over lunch yesterday about how we should manage our C++ CD deliverable.

We had a couple of options

Keep the breadth of the features offered by C++ CD, but raise our triage bar. This means that a lot of bugs wouldn’t qualify to get fixed.

Cut some features and try to keep the quality of the delivered tool high. This culminates in features delivered, even if lesser than promised set, being solid.

We are leaning towards option 2. We would like to cut some implemented/semi-working features. We would like to concentrate on features that offer “good” value for C++ developers and make them robust.

We have gotten feedback that C++ developers wouldn’t prefer to use the “Class Details Window”. It is a grid based tool window. The developers would rather type the method signature in code editor.

This feedback is making us reevaluate our promise on the abilities of Class Details Window and the Properties pages. We are thinking of making Class Details Window and the Properties pages read only.

So if we do this, then C++ Class Designer would offer

1. Create types (managed and unmanaged)

2. Create and modify Inheritance relationship between types

3. Visualize Associations to other types

4. Visualize Implemented Interfaces (as lollipops on the shape)

5. Visualize a types’ members and the members’ constituents

6. Visualize the characteristics (virtual, abstract, sealed etc) of a types’ Members

7. In managed projects browse and view details about types from referenced assemblies.

8. The designer will give you the ability to jump from the designer to code and from code back to the designer.

9. Visualize Attributes and XML Comments

We cut L

1. Ability to create/modify Members of a type

2. Ability to create/modify Associations to a type

3. Ability to generate stubs for inherited Interfaces or Abstract Types

4. Ability to override members of a base type from the designer

5. Ability to create/modify Attributes and XML comments.

I would appreciate feedback on our approach. Thanks.