In a UML class diagram, draw bidirectional associations by default, and omit the Operations compartment in a class diagram if it's empty. This sample extends the UML features of Visual Studio 2010 Ultimate.
Note: To see these features when you are drawing a class diagram, you must select the Domain Modeling profile in the properties of your model, or of a package that contains the classes you are working on.
The sample provides these features:
The operation compartment feature is a bit primitive. If you add an operation to the class, the compartment will not automatically re-appear. Either close and re-open the diagram; or delete the class shape and then drag the class from UML Explorer onto the diagram.
In Windows Explorer, double click bin\Debug\*.vsix. This will install the extension so that it will work in regular instances of Visual Studio.
You can also copy the .vsix file to any computer that has Visual Studio Ultimate.
To uninstall, use Tools>Extension Manager in Visual Studio.
Please note that this sample code is provided for demonstration purposes only.
One of the best uses of UML (in my experience) is for disambiguating users' needs. When you start work in a new business area or 'domain', you have to understand your users' terminology. You might feel the urge to write a glossary. One of the most effective ways of doing this is to draw a class diagram, which displays all the terms and the relationships between them.
Actually, it's really an entity relationship model. Because you aren't trying to assign methods to classes - that's something that happens when you're coding in an object-oriented language. For this reason, the Operations compartment in the classes is superfluous. Sure, you could hide it and the Attributes compartment at the same time; but the attributes can be very useful. So with this sample, you can hide all those unused Operations compartments. But only in models - or packages within models - that you mark with the Domain Modeling profile.
Also in a business model, arrows on associations aren't so useful. Again, directionality is really a software implementation concern. In a business model, the association is just a way of showing answers to questions: What can I have in my Library? Answer, DVDs. Can I have more than one? Yes, 0..*. So I draw a line between Library and DVD. But if Libraries have DVDs, then every DVD naturally can belong to a Library. Because we're modeling reality rather than a software design, the question "Can I get from a DVD to a Library?" doesn't arise.
I've found modeling at this level one of the most useful applications of UML. Particularly when going into a new business area, creating a model like this does help to iron out a lot of ambiguities and misunderstandings. And yes, it works very well in agile projects! I'm not advocating "big upfront design" here - just some models to help out at the initial stages of the project, and of each sprint. There are some gaps and inconsistencies that you can discover this way much faster than by writing the code. Of course, you still need the feedback from the code too! I'm a great believer in agile development - good proper agile! - where your management understand that you're doing this in sprints precisely so that you can replan if the feedback from the early sprints suggests it.
More about domain modeling in Modeling User Requirements.
Please post suggestions and questions on Visualization and Modeling SDK Forum.