-
Exporting Diagrams
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.
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.February 1, 2005
5:30 P.M. Pacific Time
Additional Time ZonesIf 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
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?
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
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.
-
Bind Dependency
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
Would the Collection
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.
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
. 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
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
and not from List . 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
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
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
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
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!
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
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.
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
{} public class Bar
I recently heard from
-
Feature Requests
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
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.
OR
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.
-
Decisions.
There were some areas where I had requested feedback. Based on the feedback received from external and internal patrons these are the decisions.
Function overloading
Our proposed approach, in nut shell, was to create an additional parameter whenever overload conflicts arise. Many of the readers and internal supporters found our approach not very clean because there were a lot of ways to modify a method from the diagram and adding a parameter of a random type to resolve the conflict will make the users uncomfortable. Based on the feedback and with the intention of keeping things simpler we have decided to make the designer not allow creation of overloaded conflicts. We will trap an overload conflict and will let the user know that an overload conflict occurred and so the method creation will not be allowed.
Inline
Again based on precious feedback we will make the inline read/write. You will be able to set the Inline property (bool) on a method which is defined outside the class. This will add the “inline” keyword. If the function is defined inside the class, then we will make the property readonly.
Constant Kind
We were thinking of not showing this information for a variable. But once again our benefactors wanted this information to surface on the designer. We will display on the designer whether a selected variable is a const or initonly or none. The only drawback is that a variable of type “literal” in code, will be displayed in the designer as a constant. -
Your Choice.
Constant Kind.
Look at this code…
public ref class C1
{
public:
const int i;
initonly int j;
literal char c = 'a';
public:
Class1() :
i(0)
{
j = 1;
}
};
In a property page you will see properties relating to the selected field. For example, you will see that “i” is int and “c” is char.
How important is it to visualize that the field “i” or ”j” or ”c” is a const or initonly or literal? If I see a lot of you wanting this information to surface I will make it possible. I am currently leaning towards not showing this information in the properties page.
Inline
A method/property can be inlined. There will be a property in the property page displaying whether the selected method/property is inline or not. Currently I am inclined to make this property read only. Inline will be true if the method/property is defined in the class/struct or explicitly inlined by using “inline” keyword.
How important is to allow users to be able to create inline methods or toggle “inline” characteristics of a method/property?
-
Feature Requests.
Please try the Class Designer on C++ projects. The Class Designer is shipped with Visual Studio 2005 beta1 bits.
If you would like to suggest some new features or see some improvements on existing features please post them in this category. I will make sure that the suggestions are reviewed. I will try to accomodate them depeinding on the availability of resources in VS 2005.
-
Please report any bugs you find here...
Please try the Class Designer shipped with Visual Studio 5, beta1 bits. If you find any bugs please post them in this category. I will make sure that the reported bugs are addressed in beta2 or in RTM.
-
Comments in code.
Wow! Did we get the overload behavior of Class Designer perfect or what? No comments on that postJ.
Did you know that the VC will support XML comments in Whidbey? XML comments are an excellent way to document your code. Here is a link to an MSDN article that delves on XML comments in C#. It will give you a fair idea, in case you were not aware of XML comments and all the different tags.
C++ Class Designer will be able to reverse and forward engineer XML comments from code. In the Class Details Window or in the Property pages there will be a “Summary” column/property. If you select that there will be a clickable button that will launch a simple “Comments” form, in which you can enter the comments.
We will be supporting regular comments as well. If you don’t prefer XML comments and use the regular “//” or “/*…*/” kind, the Class Designer will still be able to reverse and forward engineer comments.
For example, if the method in a class was coded like this...
public ref class Customer
{
///
/// This is method SetOrder. And method SetOrder does blah,
/// blah for you.
///
/// Order id is a guid that uniquely tracks
/// the order.
/// OrderContents stores all the
/// information about the order.
///
SetOrder returns a unique integer which as an /// acknowledgment.
public int SetOrder(Guid id, OrderContents contents)
{
}
};
In the Comments form that is launched on the method, you can visualize the contents of the “summary” tag and the “returns” tag. The place holders are editable and if you change the contents then the changes will be applied to code. To visualize/modify the “params” tag, you will have to launch the comments form on the param node in the Class Details Window.
But if you had chosen to code like this…
public ref class Customer
{
// This is method SetOrder. And method SetOrder does blah,
// blah for you.
// Order id is a guid that uniquely tracks
// the order.
// OrderContents stores all the information about the order.
// SetOrder returns a unique integer which as an
// acknowledgment.
public int SetOrder(Guid id, OrderContents contents)
{
}
};
We will reverse engineer all your comment lines to the “summary” tag in the Comments form on the method node. The “returns” or the “remarks” place holders on the form will be empty. The Comments form on the param node will be empty as well. Only modifications made to the “summary” place holder in the method’s Comments form will be forward engineered. We will maintain the “//” and will not overwrite it with “///”.
-
Overload Methods
I have decided to post issues that solicit feedback from you and in the process touch upon the cool aspects of Class Designer. I hope you find it engaging.
The Class Designer sits on top of the VC Code Model. The VC Code Model poses certain restrictions while creating overloaded functions. VC Code Model would not allow a function to be added to a type, if it already contains a function with the same signature. Say we want to add an overload that differs in the last parameter type. We start with the first parameter and keep adding. When you add the penultimate one VC Code Model wouldn’t let you continue. Because adding the last but one parameter causes a conflict with a function that already exists.
Following are some problems we face and solutions we have. Your opinions are invaluable.
Adding a parameter to a method needs a default type
class Bar
{
public:
// Rest of the class!
};
Cool!
The user has opened the VC project and wants to know about the class Bar. The Bar class is huge and has tons of methods. The user is interested only in browsing the “public” methods of Bar.
The user right clicks on the header file “Bar.h” in the Solution Explorer and chooses “View in Diagram”. The Class Designer will be launched and it will display all types declared in the file “Bar.h”. The user selects the Bar class on the diagram and expands it so that it displays all members. To see members grouped by access, the user would right click on the designer and chooses “Group by Access”. All the members in the Bar class will be grouped as public, private, protected etc. The user could collapse the compartments (private and protected) that are not interesting. The user also notices that when a type is selected there is a Class Details Window (a grid control) showing more details about members in the type.
Issue?
Through the Class Details Window the user wants to add a method Foo that takes a parameter. First the user adds a method named Foo. Then the user adds a parameter to the method and names it “myParam”. You have to realize that we are trying to synchronize the designer to the code editor. Every action the user does will, if applicable, translates to code being generated. In the above case a method Foo got added in code and now we have to add a parameter in code. To add a parameter we need the type. Since the user hasn’t entered a type we have to generate a default type.
What should be the default type?
Our Solution –
The default type will be “__ProvideType_N”. Where “N” will replaced by an integer value that will be incremented for every new parameter. Note that the default type will be generated to code.
Resulting Code -
class Bar
{
public:
void Foo(__ProvideType_1 myParam)
{
}
// Rest of the class!
};
Adding a method causes overload conflict
class Bar
{
public:
void Foo()
{
}
// Rest of the class!
};
class MyBar : Bar
{
};
Cool!
Assume that in the Class Designer the user has the MyBar class displaed. The user wants to view the Bar class in the designer. The user can right click on the MyBar class and select “Show Base Classes”. The Bar class will be displayed on the designer and an inheritance relationship will be displayed between MyBar and Bar.
Issue?
Say the user wants to add an overload for Foo that takes a parameter in the Bar class. First the user adds a method named Foo through the Class Details Window. As soon as the method is added we try to generate code for it through the VC Code Model. This conflicts with the existing Foo method.
Our Solution –
Before adding the new method we will search in the current class to see if there would be a conflict. If there will be a conflict then we will do the following on the VC Code Model…
1. Create a temp method with the name __Foo
2. Add a parameter of type “__ProvideTypeToResolveConflict_N” and name of the parameter will be “Param_N”, where “N” is an incrementing integer value.
3. Rename the __Foo method to Foo
4. Select the parameter we added
The user will only notice that a method “Foo” was added as requested but in addition a parameter has been added to resolve overload conflict with an existing method in the class.
Resulting code –
class Bar
{
public:
void Foo()
{
}
void Foo(__ProvideTypeToResolveConflict_1 Param_1)
{
}
// Rest of the class!
};
class MyBar : Bar
{
};
Modifying a method causes overload conflict
class Bar
{
public:
void Foo(int i)
{
}
void Foo(char c)
{
}
// Rest of the class!
};
class MyBarContainer
{
Bar* myBar;
}
Cool!
The user has the type MyBarContainer on the Class Designer. To see the contents of the Bar class, the user will right click on the member myBar and chooses “Show As Association”. The Class Designer will display the Bar class on the diagram and will establish an association relationship between MyBarContainer and Bar.
Issue?
The user wants to change the signature of “void Foo(char c)” to “void Foo(int c, double d)”. To achieve that, the user decides to first change the type of the first parameter “c” to “int”. If we translate this action to VC Code Model it will throw an exception since modifying the type on “c” to “int” conflicts with an already existing method.
Our Solution –
Before deleting/modifying the parameters on the VC Code Model, we figure out the resulting signature
1. Search the current class and check if there would be any conflicts with the calculated signature
2. If the user intended change would create a conflict then we will insert a parameter “Param_N” of type “__ProvideTypeToResolveConflict_N” as the first parameter to the method that is being modified.
3. The parameter we added will be selected
Resulting Code –
class Bar
{
public:
void Foo(int i)
{
}
void Foo(__ProvideTypeToResolveConflict _1 Param_1, int c)
{
}
// Rest of the class!
};
class MyBarContainer
{
Bar* myBar;
}
It would be great if you could let me know if the user experience for creating overloaded functions is good enough or if you would prefer some modifications or prefer some other way of doing this.
-
Our outlook.
Here is a wonderful way our Program Manager
“We want to complement the code editor, not substitute it. Rather than provide a class diagramming experience where you can write and tweak every language feature from the designer as you can in the code editor, our goal was to optimize for designing and visualizing types in your project from a higher-level (i.e. the user is thinking about the top-level classes for their system and how they interact, not the deep, specific implementation details of one single class). At the time you are deeply into implementation detail, switching to the code editor for those tasks is a natural transition. The good thing is the user needn’t worry about the diagram becoming irrelevant, because we of course keep the diagram automatically in synch with the code.
Another way to put it is we don’t want users doing “visual typing” in our designer. For many tasks, typing text in a code editor is a much more efficient way of doing things and we shouldn’t feel compelled to provide the same functionality in the diagramming space under the guise of “completeness”. We focus on the tasks that are a better fit for the visual/diagram space and leave the things that are best done in a textual format to the code editor.”
-
Hard Decisions (Contd..)
I was at
Operator overloading
In our initial V1 offering of C++ Class Designer we decided to only allow reverse engineering of operator overloaded functions. They show up as read only items, but if you make changes to operator overloaded functions in code we will synchronize to those changes in the designer.
Let me know if this would handicap you seriously and if you have strong arguments to see forward engineering of operator overloading.
Global functions
There will be no UI representation for global functions. We will not be able to forward engineer or even reverse engineer global functions. The Class View will display the global functions and variables.
Macros
There will be no UI representation for Macros. Again this is one of the many places where the Class View complements the Class Designer. But if a macro is applied then we do reverse engineer the resulting code elements. And those code elements we reverse engineer will be read only.
For example,
#define MyExampleMacro(x) int MyMethod(int x) { return x; }
public class MyClass
{
MyExampleMacro(x);
};
The macro will expand and in the Class Designer the user will see a class, with a method “MyMethod” that returns an “int” and takes a parameter “x” of type “int”. This method in the class is read only. The class can be still be modified but the method can’t be.
#includes
There will be no UI representation for Include statements. The user will have to see the code file to know what files have been included.
Managed Types can be created only in managed projects
If you run the AddClass wizard you will notice that it doesn’t allow you to generate managed types to projects, which don’t have the “Support Managed Extensions” turned on in the project properties. We will be following the same paradigm. If the project is not configured to support managed types, then the user will not be able to create managed types on the designer for the project. Note that the VC IDE allows the users to turn this option on a per file basis. But we will not be supporting this in our V1 version.
Maps (MFC)
We really wanted to provide support for Maps. They fit very well in their own compartment in a class. But we had to unfortunately cut the support for them in our V1 version. Once again the C++ Class View pitches in and offers some visualization of Maps.
I am glad that I have completed representing the tough decisions we took. It is time to dwell on the really cool things that you could do with the C++ Class Designer. I will glide through them in my coming postings.
-
Customer Wants.
I am gland that I heard from one visitor (Vikranth) of my blog post what their team finds very important to visualize
a. Virtual Destructors
b. Operator Overloading
This is exactly the kind of feedback that would help us build something that you as a customer would enjoy using.
We were allowing reverse engineering of Virtual Destrcustors. The user could click on a Destructor mehtod in a Class/Struct and see in the properties page the “Inheritance Modifier” property set to “Virtual”.
I found that we weren’t allowing the property to be modified. The property was forced to be readonly on Destructors. I have logged a tracking item in our database to investigate and if possible allow this property to be modified from the Designer.
Operator Overloading is a tougher one and I will address it in my next posting of “Hard Decisions”. -
Hard Decisions...
There seems to be no easy process to upload pictures onto the server. But I found a good msdn article that explains, with pretty pictures, the Class Designer and its cohorts (ToolBox, Class Details Window, ClassView & SolutionExplorer).
Going forward I am going to assume that you can imagine the user experience when I refer to any interactions between Class Designer and its partners.
Hard Decisions
It is a difficult art juggling time to release, resources and features. Obviously we are forced to make some tough cuts and concentrate on making the features we are planning to visualize top notch. So I will outline all those C++ concepts we offer minimum or no support.
Old syntax for managed types
Class Designer is not a porting tool. Theoretically we should be able to reverse and forward engineer old managed syntax if you have set the right configurations on the project. But we will not officially guarantee support for old syntax for managed types.
Typedefs
There will be no UI that allows users to create a Typedef on the Class Designer. But if you have a Typedef in code it will be honored.
For example,
typedef int (*MyFunctionPointer) (int, char);
class Foo
{
MyFunctionPointer ptrToHandler;
};
On the Class Designer you will see the variable “ptrToHandler” of type “MyFunctionPointer”.
Unions
There will be no UI that would allow the users to create a
There is a cool feature in Class Designer. Say you have this code
namespace SomeExampleCode
{
class Order
{
};
union DayTimeContact
{
char* homePhoneNumber;
char* email;
};
class Customer
{
Order* order;
DayTimeContact customerContact;
};
}
In the Class Designer the user can drag and drop the Customer class from Class View. The user can right click the “order” field and choose “Show as Association”. We will pull the “Order” class into the Designer and establish a relationship between the class “Customer” and class “Order”.
Now that can’t be done with the field “customerContact” of type “DayTimeContact”, because DayTimeContact is a
There are more Hard Decisions to defend J and I will table them soon.
-
Introduction
Hello, I am Rakesh Namineni. I work for the Class Designer team in Visual Studio. I own Class Designer for C++.
Purpose of this blog
What is Visual Studio 2005 Class Designer?
The Visual Studio Class Designer lets you visualize the structure and relationships of classes and other types. Changes made to the visual designer are immediately reflected in code, and changes made to the code immediately affect the appearance of the designer. Members of a type can be visualized as compartments within the type. Members can be added and modified through a tool window called the Class Details Window that accompanies the Class Designer.
A picture would definitely make the explanation more clear. I will add one as soon as I figure out how to do it. You would have heard many first time blogers say thatJ.
Class Designer and UML
Now that you have pictured what a Class Designer is, the next question that often pops up is whether the designer is UML compliant. Well, it is not. It borrows from UML the notations that are intuitive to developers. If you have more questions regarding Microsoft’s reasoning behind developing designers that are domain language specific, I request that you post your queries at Keith Short’s blog. He is our architect and qualified to handle queries regarding this issue.
C++ Challenge
C++ is easily one of the most complex languages. We had seriously considered whether we should attempt to build a Class Designer for C++. I have listed some of the customer centric reasons that led us to accept the challenge
a. Tools should help developers improve productivity in areas they most spend time in. Many studies have reflected that developers spend most time in debugging or understanding existing code. Visualizing existing code will be a powerful tool in improving a developer’s productivity and we wanted the VC developers to have that power.
b. The Class Designer could be an excellent alternative to VC wizards. There a lot of customers who dearly miss the wizards the VC team cut in their earlier release. The Visual Studio 2005Class Designer could be poised to partially fill that void.
c. The VC team is completely changing the syntax for managed types. The Class Designer could be an excellent tool for customers to visually create types and relationships and read the code that gets generated. An excellent tool to blunt the learning curve.
Class Designer for C++
In the coming postings, I will focus (not necessarily in the listed order) on the extent of support the Class Designer offers to the following
· Old syntax for managed types
· Macros
· Typedefs
· Unions
· Global functions
· Comments
· Creation of managed types
· Inheritance
· Interface Implementation
· Creation of type members
· Method/Property overloading
· Variable arguments
· Function pointers
· Templates
· Generics
There are certain decisions we have made that will be hard to change. But your feedback will be noted and could influence our next version. There will be some parts I will beg for your feedback and it will have an impact on what we are designing and implementing.
-
Wednesday 1 July 2009
Exporting Diagram
Subscribe to:
Posts (Atom)