Umbrello 1.1 Released 37
An anonymous reader writes "The new stable version of Umbrello UML Modeller 1.1 was released on 20 January. Currently only source and SuSE packages are available. Is there a better UML modeller for Linux?"
You can be replaced by this computer.
But what about... (Score:4, Funny)
Re:But what about... (Score:1, Funny)
Possibly Better (Score:4, Informative)
Re:Possibly Better (Score:2, Informative)
Why ? (Score:1)
In my experience UML makes you overdesign, and spend far to much time on things you one should rather use to do something productive.
By all means, dont't start coding without thinking, just don't think and design to much. Remember, just because you do UML, doesn't mean the result is without problems.
Quite the oposite imho.
Re:Why ? (Score:5, Insightful)
If you have a good UML software package it will be able to create stubs for all the classes in your object oriented project. It's not an amazing thing, but it saves a lot of time in typing. The main use of UML is if you have a team of say 40 guys working on a project. You can all meet, discuss the design, get a complete UML cranked out. Then break off a piece for everyone. Theoretically everybody will be able to code their portion correctly without having to worry about whether anyone else messed up or not. Since the UML tells them what objects they should be using and all the public methods and such.
So if you're coding something small at home. UML isn't entirely useful. But as project size increases UMLs usefulness does as well. Besides overdesigning is much more preferable than underdesignin.
Re:Why ? (Score:1)
I don't agree with you here. In an XP style development you can add design later as you need it. If you have overdesigned your project you will loose much more time once you find that your design does not completely do the job (and that happens in every project anyway, right?).
I do have coworkers who do stuff like defining lots of interfaces with one implementing class only or include thousands of features one might need someday. That is wasted time twice - once in the design and a second time if you have to change/refactor it.
Also UML might be useful in tiny projects as well. I use UML not much as a means for design but more for documentation. A simple class diagramm will help you so much understanding your project if you come back to it after months or even years. In larger projects where there are lots of coworkers or even external partners having class diagrams is a must IMO.
Re:Why ? (Score:2, Interesting)
Consider the case where you write a complex piece of software that publishes an API layer for other people to use to extend the software. If you follow good OOP practices in building your solution, decent UML documentation is an invaluable source of information for developers who want to build on top of your stuff. This is talking from experience with a large software package where I use the UML class diagrams much more frequently than the (good) API documentation.
Overdesign can be a problem, but with a reasonable amount of experience in software development, you should be able to minimise this happening. UML is more a communication aid than anything else.
I strongly believe that a good solid design makes up at least 50% of a successful software project. While this is not necessarily true for small projects, I try not to touch any code before I have a design thought out.
Whatever happened to small tools (Score:5, Insightful)
Now we're recognising the use for UML tools, have we taken the unix path or the integrated windows path? Seems the integrated tools are winning. Oh yeah, and there's thousands of them, all in various states of disrepair.
I know this isn't a very convincing argument, but frankly, I shouldn't have to make it: small tools working together is the unix way and we should strive to make our new tools the same way as our old tools.
I recommend the following small tools:
Most of these transformations can be done in XSLT. By maintaining XLinks between each of these documents you can navigate from one SVG to another and even effect changes earlier in the pipeline to create an interactive editor.
Even if you have no interest in reverse engineering C++ code the last 2 steps will be of interest to anyone writing another one of those big ass UML editors.
Re:Whatever happened to small tools (Score:1)
This way, everyone is doing what (s)he's doing best.
Re:Whatever happened to small tools (Score:1)
Re:Whatever happened to small tools (Score:1)
Re:Whatever happened to small tools (Score:1)
It should at least keep up the impression of it to fool the managers
Re:Whatever happened to small tools (Score:2, Insightful)
Re:Whatever happened to small tools (Score:3, Insightful)
Your recommendation seems to miss the point: how do you design with UML?. Check Rational Rose.
Re:Whatever happened to small tools (Score:1)
Re:Whatever happened to small tools (Score:2)
Re:Whatever happened to small tools (Score:1)
By pulling togheter scritps, XSL, grep, sed and a few other tools I can get perhaps 8 percent of the functionality. Take in account the effort to integrate all this to get something that sticks with duct tape.
My choice would be easy.
Re:Whatever happened to small tools (Score:2)
Every project has different requirements for tools, the idea that you can write one tool that is going to do everything for you in a particular field is rediculous.
Re:Whatever happened to small tools (Score:3, Insightful)
1.Parse C++ using a general parser, such as Earley's algorithm or Tomita, generate a readable XML parse tree.
2.Filter parts of the parse tree that are not used in the UML diagram you want to generate, i.e., you don't need code in class diagrams.
3.Transform the parse tree into a standard UML exchange language.
4.Transform the UML into scalable vector graphics (SVG) format.
5.Use open tools to view the resulting SVG file.
You are speaking about Class diagrams only, right? So you ommit the other 8 diagrams UML offers?
Anyway
1. Use open tools to view (and of course, manipulate!!!) SVG files.
2. Transform the SVG into an UML model.
3. Transfrom the UML model into an parse tree.
4. Enhance the parse tree by language dependend features, e.g. pointers or references for C++.
5. Unparse the parse tree into compilebale source code.
Hu hom, your 5 steps plus my 5 steps together are minimum if you like to work with class diaggrams only
Still 8 further diagrams missing
angel'o'sphere
Re:Whatever happened to small tools (Score:1)
Re:Whatever happened to small tools (Score:2)
so we only need to DO IT
Strangely the OMG is defining the XML formats for case data interchange and also the meta model of case data in a totaly incompetent way. So if no one wins 10M bucks in a lottery and is going to spend it for "The Ultimative Modelling and Generation Work Bench(Reverse Engineering included)" this will not happen in the forseeable future
Powerfull GUI interaction + SVG + XML + XSLT + code generation + reverse engineering
angel'o'sphere
Re:Whatever happened to small tools (Score:2)
Powerfull GUI interaction + SVG + XML + XSLT + code generation + reverse engineering .... of course that is the dream tool chain
And we can build it one part at a time with each of the parts serving some useful purpose. Seperate tools with agreed interchange formats is the best way to parallelize work.
Other UML Modeller (Score:4, Informative)
Re:Other UML Modeller (Score:1)
worst writeup ever?? (Score:1, Troll)
come on!
FYI: Code Import only supports C++ (Score:2)
I was hoping that the tool would be able to import Java classes - no such luck. Maybe in the next release!
Re:FYI: Code Import only supports C++ (Score:3, Informative)
Re:FYI: Code Import only supports C++ (Score:2)
Yes, it supports all those languages for code GENERATION, not code IMPORT. My point was that if you want to IMPORT existing Java code, you're out of luck.
quick critique (Score:2)
also, sequence diagrams don't mark the active period when one objects invokes another.
Other tools. (Score:3, Informative)
cute & useful (Score:1)