A key point which we really wanted was to have full round-trip engineering of code - that is, you can generate code from your diagrams, then edit the code and update the diagrams from the code. Microsoft Visio for Enterprise Architects, which was included in our MSDN subscriptions (and doesn't seem to be available for sale in this edition separately from Visual Studio), didn't do this for us, and it was a bit clunky and slow.
We first looked at Enterprise Architect (EA) maybe as much as a couple of years ago, but we passed on it then for a number of reasons - only some of which were to do with the package, and we could have been mistaken in those. Anyway, we have recently had a fresh project start and looked at Enterprise Architect again. Although we still had a few reservations, we liked what we saw and decided that if we were going to jump then now was the time.
Leaving aside some of the technical issues we've had with it (it doesn't import the Loki C++ library very succcessfully, but Loki is a very challenging test-case), we have actually been able to start doing some real work with it. Getting into the mind-set of using UML to express design ideas is a bit of a leap if you haven't done it before, and there's quite a lot to learn and get accustomed to.
UML is not a programming language, but a design language from which code can be generated, and we intend to generate both C++ and C#, as appropriate. EA should handle these, as well as a few other languages we don't intend to use. Also, UML is not limited to explicitly designing code, but starts at a much higher level of modelling what solutions are intended to achieve and how they will be used.
It's good to have a tool which helps in capturing these ideas in a standard format, although learning how to express ourselves in the language of UML is, like learning any new language, slow going at first. In fact, it is more like learning a new human language than a new programming language. Although there are always different ways of writing the same algorithm in code, programming languages are quite strict in how they allow you to express things. UML, in contrast, feels very free-form, with only limited guidelines as to what you can and can't do - the rules are more like grammar in English than syntax in a programming language. This makes it a bit more difficult to get started, as you wonder what to do next - with freedom comes responsibility!
This week, though, there was one of those "Aha!" moments - not in the sense of "Aha! - I've got it!", but "Aha! - this was a good idea after all!". We can rationalise being a bit slow picking up the use of UML, as I have above, but whenever you're taking time to learn something there are doubts as to whether you've taken the right road. "Are we wasting our time doing this?"
Probably not. This week, I showed a diagram I had been working on to
qidane to get his opinion on a significant detail, and after a quick look at the diagram he was able to talk me through what I was trying to express in the diagram better than I felt I could have explained it to him. Aha! It might be a bit of a slog learning to "speak" our new language, but it looks like it is going to pay off. 