Visio for VS.NET
-
Hi, I am confused. I am a universal MSDN subscriber and gets tons of CDs every few months. I have located and installed VS.NET and now want to use visio. However, I am confused on which visio to use. In the MSDN I have found several ranging from: Visio Visio for Enterprise architects Visio 2003 (Marketing edition) Visio 2000 Visio 2000 SR1 And others... Which one is the corret one for integration with VS.NET? Thanks! Jeremy Pullicino C++ Developer Homepage
-
Hi, I am confused. I am a universal MSDN subscriber and gets tons of CDs every few months. I have located and installed VS.NET and now want to use visio. However, I am confused on which visio to use. In the MSDN I have found several ranging from: Visio Visio for Enterprise architects Visio 2003 (Marketing edition) Visio 2000 Visio 2000 SR1 And others... Which one is the corret one for integration with VS.NET? Thanks! Jeremy Pullicino C++ Developer Homepage
IMHO, Visio for EA "Courage choose who will follow, Fate choose who will lead" - Lord Gunner, Septerra Core "Press any key to continue, where's the ANY key ?" - Homer Simpsons
-
Hi, I am confused. I am a universal MSDN subscriber and gets tons of CDs every few months. I have located and installed VS.NET and now want to use visio. However, I am confused on which visio to use. In the MSDN I have found several ranging from: Visio Visio for Enterprise architects Visio 2003 (Marketing edition) Visio 2000 Visio 2000 SR1 And others... Which one is the corret one for integration with VS.NET? Thanks! Jeremy Pullicino C++ Developer Homepage
Visio for Enterprise architects
-
Hi, I am confused. I am a universal MSDN subscriber and gets tons of CDs every few months. I have located and installed VS.NET and now want to use visio. However, I am confused on which visio to use. In the MSDN I have found several ranging from: Visio Visio for Enterprise architects Visio 2003 (Marketing edition) Visio 2000 Visio 2000 SR1 And others... Which one is the corret one for integration with VS.NET? Thanks! Jeremy Pullicino C++ Developer Homepage
Real programmers never use diagrams. The code speaks by itself. Trying to make bits uncopyable is like trying to make water not wet. -- Bruce Schneier By the way, dog_spawn isn't a nickname - it is my name with an underscore instead of a space. -- dog_spawn
-
Real programmers never use diagrams. The code speaks by itself. Trying to make bits uncopyable is like trying to make water not wet. -- Bruce Schneier By the way, dog_spawn isn't a nickname - it is my name with an underscore instead of a space. -- dog_spawn
But remember: All the code will ever say is what it DOES. Not what it is SUPPOSED TO DO! A diagram often helps describe what the code is supposed to do. It is like comments. Comments should always describe intention (which is why it is a good idea to write them first) then if there is a bug in the code and you have to go back after 6 months or even someone else go back then to modify the code the original intent is still clear. --Colin Mackay--
"In the confrontation between the stream and the rock, the stream always wins - not through strength but perseverance." (H. Jackson Brown)
-
But remember: All the code will ever say is what it DOES. Not what it is SUPPOSED TO DO! A diagram often helps describe what the code is supposed to do. It is like comments. Comments should always describe intention (which is why it is a good idea to write them first) then if there is a bug in the code and you have to go back after 6 months or even someone else go back then to modify the code the original intent is still clear. --Colin Mackay--
"In the confrontation between the stream and the rock, the stream always wins - not through strength but perseverance." (H. Jackson Brown)
Colin Angus Mackay wrote: But remember: All the code will ever say is what it DOES. Not what it is SUPPOSED TO DO! A diagram often helps describe what the code is supposed to do. I assume you agree that wrong documentation is worse than no documentation. If you don't, don't read my opinions below. No, a diagram only describes how the code was structured to do something when it was designed. If your code (or, at least the class structure) is not generated from the diagram, your process offers no guarantee that your code will be in sync with your diagram. Colin Angus Mackay wrote: It is like comments. Comments should always describe intention (which is why it is a good idea to write them first) No, comments should only describe what's not obvious (I know, this is vague, but "intention" is also vague), or give an overview of the code for the very same reasons above. They are best for explaining things that don't change often, or you will have sync problems again. Until we have some decent intentional programming framework, white box/unit testing should describe intention, because this way your process will assure that you always have intentions synced with the code. I'm also not particularly fond of throwing more code to solve a coding problem, but until a better solution is found, it's what I use. Trying to make bits uncopyable is like trying to make water not wet. -- Bruce Schneier By the way, dog_spawn isn't a nickname - it is my name with an underscore instead of a space. -- dog_spawn