Hi All,
I simply want to create a diagram for a C++ object hierarchy.
Why would you do that?
If you are a C++ programmer, you would be better off not worrying about
using Visio to draw pretty pictures, and instead, you should focus on
finding the proper form and correct object relationships in your class
designs. This is not something that a UML design tool can teach you or
do for you. If you are one of the *best programmers* then you will find
that Visio does nothing for you (is it any wonder that it is not
included in Visual Studio?). The best programmers can keep an entire
design in their head. They can see the relationships between object
classes, they can drill down to highly minute details of specification,
or pull back and see the big picture. Achiving clarity throughout your
design should be your only goal.
I saw the organizational chart, but I don't like it because it insists
that the text inside each box take up two lines, and I only need one
line of text per box. Also, it is clear that organizational elements
were created to be used for...well, organizational charts. I need
something for programming language objects.
Creating diagrams for object-oriented hierarchies is such common task,
I must be missing something. I did a search for "hierarchy" and got a
few shapes, including a couple "Hierarchy" elements that don't do
much.
There is a version of Visio which ships with common software design
templates, such as UML, COM/DCOM, networks, basic flow charts, etc. How
appropriate that this should be billed as an 'architect edition' or
something like that.
I have seen plenty of software shops (some with $10,000,000,000USD in
annual revenue), where I find a clueless and frightened 'architect'
dictating design from the top. These are often the people who used a
combination of politics and seniority to attain their position, and
subsequently, would not be able to think of anything original to save
their lives. These so-called architects use pretty UML diagrams to
snowball managers into a false sense of accomplishment. They destroy
more trees than a wildfire printing UML-laced 'design documents' that
are hopelessly generalized and disconnected from reality. They have to
do something to justify their $150,000USD annual salaries, bonuses,
company car, etc. Meanwhile, the 'merely senior' programmers are given
the task of turning said design into a real working product. Often these
programmers quickly realize that the design they were handed is
untenable, inconsistent, and vague to the point of being useless. Then
one of two things will happen: either the programmers revolt and produce
a *real design* or else they will try their best to implement the
software according to the architect's plan, and subsequently millions of
dollars will be spent in the confusion, deadlines will slip, customers
will be angry, and guess who gets the blame? Yup - the programmers.
--Lynx
