3 ms·

I also had an Enterprise Architect license, which I paid for myself - it's an impressive product. But what most people don't get about UML is that it works best

I also had an Enterprise Architect license, which I paid for myself - it's an impressive product. But what most people don't get about UML is that it works best as a documentation and explanation tool, not a design tool. I've never seen a project that successfully used UML (or other structured graphical languages) for design on a realistic (say 5 man year) project - it would be interesting to hear if anyone else here has, and even more interesting (and believable) to see the actual design. Edit: reduced 10 man year to 5. 10 is too long & overmanned (though I have worked, unhappily, on such projects).

zenogais 6y ago
Agree with this and I think it's the crucial point. Where I've had the most success with UML-like tools and diagrams is early on in a project since its much faster to rip up and rebuild a few diagrams. The diagrams also help with getting consensus among stakeholders that this direction makes sense and doesn't have any glaring holes. Later on you can drop the diagrams entirely and perhaps keep them as some onboarding documentation if they're still useful.
andreskytt 6y ago
Yes, exactly. Modelling things has many uses (collaborative thinking, communication, dependency tracing, complexity management etc.) and specifying things is probably one of the least useful of these. I work with UML (and Sparx EA) primarily as a high-level architecture tool. Once everybody has a rough shared understanding of what and why we are building, people get to coding and UML stops. Should we get to a problem, we dig up the initial idea, validate it, us it for problem-solving and move on. Sometimes sequence diagrams might be used for making sure everybody has the same understanding of how an interaction should go. But that’s it. Communication, problem-solving, knowledge management. And not specification.
osigurdson 6y ago
I find Enterprise Architect to be very bloated. I use it on occasion but the useful stuff is rather hard to find. I'm using this on a ~500 person year project though I am not sure project size is an important differentiator.

zenogais 6y ago

Agree with this and I think it's the crucial point. Where I've had the most success with UML-like tools and diagrams is early on in a project since its much faster to rip up and rebuild a few diagrams. The diagrams also help with getting consensus among stakeholders that this direction makes sense and doesn't have any glaring holes. Later on you can drop the diagrams entirely and perhaps keep them as some onboarding documentation if they're still useful.

andreskytt 6y ago

Yes, exactly. Modelling things has many uses (collaborative thinking, communication, dependency tracing, complexity management etc.) and specifying things is probably one of the least useful of these. I work with UML (and Sparx EA) primarily as a high-level architecture tool. Once everybody has a rough shared understanding of what and why we are building, people get to coding and UML stops. Should we get to a problem, we dig up the initial idea, validate it, us it for problem-solving and move on. Sometimes sequence diagrams might be used for making sure everybody has the same understanding of how an interaction should go. But that’s it. Communication, problem-solving, knowledge management. And not specification.

osigurdson 6y ago

I find Enterprise Architect to be very bloated. I use it on occasion but the useful stuff is rather hard to find. I'm using this on a ~500 person year project though I am not sure project size is an important differentiator.