UML...Do you use it and is it worth it?
-
I'm relatively new in an organization that's going to port over the C++/CLI. I've never formally used UML and I'm curious if anyone here regularly uses it for production projects and what their overall opinion of it is. I would like to unify (no pun intended) the documentation because it's rather disparate and difficult to navigate and translate.
-
I'm relatively new in an organization that's going to port over the C++/CLI. I've never formally used UML and I'm curious if anyone here regularly uses it for production projects and what their overall opinion of it is. I would like to unify (no pun intended) the documentation because it's rather disparate and difficult to navigate and translate.
I do think that some knowledge of UML is worth it... not necessarily for its use, but for the clarity and practices that it teaches. I use it sparingly in my docs (rarely then!), but it does make sketching, designing and putting complex ideas down on paper a lot easier.
I Dream of Absolute Zero
-
I'm relatively new in an organization that's going to port over the C++/CLI. I've never formally used UML and I'm curious if anyone here regularly uses it for production projects and what their overall opinion of it is. I would like to unify (no pun intended) the documentation because it's rather disparate and difficult to navigate and translate.
I sometimes use different parts of UML (mainly object, state, and flow diagrams) during the initial design. My difficulty, and this isn't UML specific, deals more with updating/maintaining the documentation as the application develops. The object model always changes to some degree during development. I've never found (but haven't looked that hard either) for something that works right with regards to reverse engineering. By "works right", I mean, is easy to use, preserves my object layout, additional notes, etc. However, if you're documenting a stable, finished app, then UML might be a good way to go. However, I find that most UML diagrams still need a lot of ancillary documentation. The diagram shows "how", but a diagram often doesn't describe "why". And after years of doing this, my opinion is that the "why" is usually more important than the "how". And frankly, to describe "why", Word works great, although what I end up doing is using FrontPage and putting together webpages, as I like the flexibility of posting documentation onto a website. That said, a wiki is also a great way of managing documentation, IMO. You can have images, text, and it tracks revisions to the doc automatically. Hope that gives you some ideas. :) Marc VS2005 Tips & Tricks -- contributions welcome!
-
I'm relatively new in an organization that's going to port over the C++/CLI. I've never formally used UML and I'm curious if anyone here regularly uses it for production projects and what their overall opinion of it is. I would like to unify (no pun intended) the documentation because it's rather disparate and difficult to navigate and translate.
We use UML a lot at work and from my viewpoint the main stumbling block isn't the UML methodology, it's the tools and processes that implement it. UML itself isn't a bad system for designing software, but the company needs to have in place a good process for using it, and a user-friendly tool. I initially wasn't keen on using UML to design my software, but after using it a while I found it was quite a useful way to visualise what I was trying to achieve, without hacking away at code (which can also be fun). As far as porting software, it pretty much depends on the state of what you're starting with. Certainly I'd find that even doing a basic modelling of what's there already would help you to understand what's going on. Hmm.
-
I'm relatively new in an organization that's going to port over the C++/CLI. I've never formally used UML and I'm curious if anyone here regularly uses it for production projects and what their overall opinion of it is. I would like to unify (no pun intended) the documentation because it's rather disparate and difficult to navigate and translate.
espeir wrote:
I've never formally used UML and I'm curious if anyone here regularly uses it for production projects and what their overall opinion of it is.
For technical documentation, often. For the actual design, almost never.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
I'm relatively new in an organization that's going to port over the C++/CLI. I've never formally used UML and I'm curious if anyone here regularly uses it for production projects and what their overall opinion of it is. I would like to unify (no pun intended) the documentation because it's rather disparate and difficult to navigate and translate.
I use it and it froms the core part of my general system definition. We do not use it for code generation (on my project). Step one in the process I follow is to create business flow models of what I read the customer is desiring. When my first pass is done I insist that I have a 1/2 day (maybe several single hour sessions) and I tell them what their business process is. If they concure I was correct then I can convert these flow diagrams to use case senarios which in turn are the sources for the derived softare requirements (you know the ones coders complain are never stable, guess why.) If they do not concur then, proof this was a wise step has been given and correct it try again. I also use sections to document all of the terms people are using, so again they can tell me it is correct of not. "Simplicity is more complicated than you think. But it’s well worth it” (Ron Jeffries)
-
I'm relatively new in an organization that's going to port over the C++/CLI. I've never formally used UML and I'm curious if anyone here regularly uses it for production projects and what their overall opinion of it is. I would like to unify (no pun intended) the documentation because it's rather disparate and difficult to navigate and translate.
I find it pretty much indespensible for design work, and (scarily enough) at that stage I often find myself visualising something similar to it mentally before writing anything down! :wtf: I tend to try to keep modelling to a relatively high level (the more detailed the model the less likely it is to keep up to date) and rely on Doxygen to document the detail... Anna :rose: Currently working mostly on: Visual Lint :cool: Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
I'm relatively new in an organization that's going to port over the C++/CLI. I've never formally used UML and I'm curious if anyone here regularly uses it for production projects and what their overall opinion of it is. I would like to unify (no pun intended) the documentation because it's rather disparate and difficult to navigate and translate.
For any working group larger than, say 4 or 5, it's almost impossible to do without it, specially if your group is scattered over several time zones. We use Enterprise Architect (Sparx), it's cheap, does reverse and forward engineering on both code and assemblies/jar and DDL. It integrates with VS.. can also connect to a VCS to keep updated version for the whole group aaaaannd... is automatable (COM Automation). :cool: Denevers
-
I'm relatively new in an organization that's going to port over the C++/CLI. I've never formally used UML and I'm curious if anyone here regularly uses it for production projects and what their overall opinion of it is. I would like to unify (no pun intended) the documentation because it's rather disparate and difficult to navigate and translate.
UML is worth it. The trick is to document only whats needed, not EVERYTHING. And when you do that, UML gives you a clear and consistant way to documnet those parts that need it. Too many people get UML mixed up with documentation methodologies. I'm not going to get into this religious despute, other than to say that whenever you DO want/need to document something, UML is the way to go: everybody either (a) know's the standard notation, and thus can easily understand the document, or (b) can easily pick up a UML reference and then easily understand the document.
-
I sometimes use different parts of UML (mainly object, state, and flow diagrams) during the initial design. My difficulty, and this isn't UML specific, deals more with updating/maintaining the documentation as the application develops. The object model always changes to some degree during development. I've never found (but haven't looked that hard either) for something that works right with regards to reverse engineering. By "works right", I mean, is easy to use, preserves my object layout, additional notes, etc. However, if you're documenting a stable, finished app, then UML might be a good way to go. However, I find that most UML diagrams still need a lot of ancillary documentation. The diagram shows "how", but a diagram often doesn't describe "why". And after years of doing this, my opinion is that the "why" is usually more important than the "how". And frankly, to describe "why", Word works great, although what I end up doing is using FrontPage and putting together webpages, as I like the flexibility of posting documentation onto a website. That said, a wiki is also a great way of managing documentation, IMO. You can have images, text, and it tracks revisions to the doc automatically. Hope that gives you some ideas. :) Marc VS2005 Tips & Tricks -- contributions welcome!
Marc Clifton wrote:
However, if you're documenting a stable, finished app, then UML might be a good way to go. However, I find that most UML diagrams still need a lot of ancillary documentation. The diagram shows "how", but a diagram often doesn't describe "why". And after years of doing this, my opinion is that the "why" is usually more important than the "how". And frankly, to describe "why", Word works great, although what I end up doing is using FrontPage and putting together webpages, as I like the flexibility of posting documentation onto a website.
This is the case with me. We have a stable system in production that we're porting. Unfortunately, I've lost a lot of confidence in the previous development effort, because when I had put out my first change, there was an unexpected (as it was undocumented) result in another part of the system that QA didn't know to test. There's a lot of free-text documentation, but nothing in a single, easily-navigable and coherent model. I almost just want a module dependency diagram so that we can track when changes to one part of the system will effect other parts.
-
Marc Clifton wrote:
However, if you're documenting a stable, finished app, then UML might be a good way to go. However, I find that most UML diagrams still need a lot of ancillary documentation. The diagram shows "how", but a diagram often doesn't describe "why". And after years of doing this, my opinion is that the "why" is usually more important than the "how". And frankly, to describe "why", Word works great, although what I end up doing is using FrontPage and putting together webpages, as I like the flexibility of posting documentation onto a website.
This is the case with me. We have a stable system in production that we're porting. Unfortunately, I've lost a lot of confidence in the previous development effort, because when I had put out my first change, there was an unexpected (as it was undocumented) result in another part of the system that QA didn't know to test. There's a lot of free-text documentation, but nothing in a single, easily-navigable and coherent model. I almost just want a module dependency diagram so that we can track when changes to one part of the system will effect other parts.
espeir wrote:
I almost just want a module dependency diagram so that we can track when changes to one part of the system will effect other parts.
Funny, I was just raving about how fantastic the Find All References feature in VS2005 is, when refactoring code. I'm working in C#, but I assume the same feature is available with C++. Marc VS2005 Tips & Tricks -- contributions welcome!
-
espeir wrote:
I almost just want a module dependency diagram so that we can track when changes to one part of the system will effect other parts.
Funny, I was just raving about how fantastic the Find All References feature in VS2005 is, when refactoring code. I'm working in C#, but I assume the same feature is available with C++. Marc VS2005 Tips & Tricks -- contributions welcome!
Unfortunately it's a rewrite from PB (PukeBuilder) which has no such tool. There's also a lot of business logic that has seeped into stored procedures that are pretty well disconnected from the PB code.
-
I'm relatively new in an organization that's going to port over the C++/CLI. I've never formally used UML and I'm curious if anyone here regularly uses it for production projects and what their overall opinion of it is. I would like to unify (no pun intended) the documentation because it's rather disparate and difficult to navigate and translate.
just say NO!