One thing you will have noticed from the new material we've been posting is the use of UML for design work, and indeed we have an open question from Frank as to what you think of our use of UML (http://www.psdn.com/library/thread.jspa?threadID=2121&tstart=0), but I have a more general question.
In these days of n-Tier, OERA, SOA, SOBA etc, do you do any formal design work when gathering requirements and specifying application functionality? If so, do you use UML or some other notation? Do you use a specific design tool such as Enterprise Architect, Visio, etc, or just use the drawing tools in MS Word !!
If not, why not? Is there no perceived value in doing design work as the designs are always out of date when compared to the code as no-one can be bothered to keep the two in sync. Is it simply that you not doing n-Tier, OERA, SOA, SOBA etc and therefore don't see the need for design in your environment.
We tried an ambitious project once: requirement management by tracing requirements into code via UML-diagrams. First there is the mismatch between logical model and implementation model. Yes sure, there was full round trip engineering between code and implementation model, but there is no such thing between logical model and implementation model.
Than there is the mismatch between requirement and UML-diagram: you had to trace features via use case diagrams
So you end up using the UML-tools at the design stage and throw away the diagrams after implementation, since they will become out of sync.
Sure you can reverse engineer the code to create some documentation, but that is hardly what you need, since you have to add additional diagrams.
Now the tools themselves: Visio is not a dedicated UML-tools, it's a generic diagramming tool with added UML-diagramming support (and some degree of reverse engineering). It's very bad at multi paged diagrams, so it's a nice tool to do some high level designing.
We used Togethersoft, nowadays a Borland product for rountrip engineering C#, but it was not very successfull a couple of years ago. I know they have rewritten the stuff since than. The missing link at that stage: no IDE/compiler/build integration. The positive thing compared to Visio: it's a real UML design tool.
In Visual Studio.Net 2005 we have UML-support as well. This is Microsoft's idea of UML and the diagramming is not what you expect.
So I guess, the best way to use UML-diagrams is: paper and pencil
Theo.
....
So I guess, the best way to use UML-diagrams is:
paper and pencil
Theo.
In the past when I've done customer engagements, pencil & paper is exactly what we used (Also stops people hiding behind the technology of the tool!!)
But I hear your point about the platform independent models vs the platform specific models. Obviously this is something the tools guys are trying to address with MDA. I do think the tools have gotten better at the reverse engineering side of things. Admittedly they generally only give you the interface of the class or whatever, not generally the guts of the code, but you should be able to keep them pretty much in sync these days. Maybe there's a market opportunity here
On a side note I've just downloaded the new Borland DefineIT product to have a play. It seems to be getting some good write reviews and it's eclipse based which opens up a whole host of ideas and possibilities (Now before anyone gets excited, this is just Mike doing stuff personally, not a corporate strategy or anything!!)
On a side note I've just downloaded the new Borland
DefineIT product to have a play. It seems to be
getting some good write reviews and it's eclipse
based which opens up a whole host of ideas and
possibilities (Now before anyone gets excited,
this is just Mike doing stuff personally, not a
corporate strategy or anything!!)
You could also try an opensource version like http://argouml.tigris.org/
On a side note I've just downloaded the new
Borland
DefineIT product to have a play. It seems to be
getting some good write reviews and it's eclipse
based which opens up a whole host of ideas and
possibilities (Now before anyone gets excited,
this is just Mike doing stuff personally, not a
corporate strategy or anything!!)
You could also try an opensource version like
http://argouml.tigris.org/
Cool, I 'll have a look.
>(Now before anyone gets excited,
>this is just Mike doing stuff personally, not a
>corporate strategy or anything!!)
How does this compare with Enterprise Architect?
Responding to the broader question, I think that the problem of lack of connection between platform independent models and implementation models is more a reflection of the quality of the tool or of the adherence to the methodology than it is a necessity. To be sure, with MDA one would like to be generating the PSM (platform specific model) from the PIM (platform independent model), but even if it isn't automated, there is no reason not to have the diagrams connected to each other. My sense is that all too many models already assume a fair amount of platform specificity anyway and the problem is more how to abstract that to a really independent model in case one wants to change the platform target.
>(Now before anyone gets excited,
>this is just Mike doing stuff personally, not a
>corporate strategy or anything!!)
How does this compare with Enterprise Architect?
I've really only just installed it, so I'll post back in a few days once I've played.
... My sense is that
all too many models already assume a fair amount of
platform specificity anyway and the problem is more
how to abstract that to a really independent model
in case one wants to change the platform target.
That's very true, although I've seen it the other way also, where there is so little in the models it makes you wonder why they bothered! I sat in some UML training, and the trainer stated that if it took more that 7 use cases to describe your app then your thinking at the wrong level!! I think this is a bit too far the other way.
I'll post back in a few days once I've played.
Please do. EA is hardly expensive and it seems awfully good so far.
OK, so there are idiot UML trainers in the world too, no matter how much they understand the material.
Frankly, I think this relates to one of the big challenges in software these days ... we have a bunch of people who can create it, but the number of really good designers and architects, especially with any knowledge in any particular domain, is very limited. And, if they don't have domain knowledge, then they are hobbled by what they don't know.