Everyone has a different set of ideas about where, if anywhere, the use of UML is appropriate. Some use it just for a little upfront modeling, some use it to drive code generation in an MDA paradigm, some use it as the output of a reverse engineering tool. ArgoUML can be used for all of these and more. Of course, some only use it on a whiteboard.
One scenario that you'll find almost no one advocating is hand maintenance of a parallel set of source code and UML diagrams. It's extra work that, by its very nature, is always out of sync with itself and thus inaccurate, to a greater or lesser degree. Having all the cookbook diagrams collected together in a single project might be a useful way to make the information easier to access, but it's got the disadvantage of making revision control a little "lumpier" and more difficult to manage since the .zargo projects are binary files. I'm pretty sure the ArgoUML files for all the diagrams *are* available in one form or another though. The projects could be enhanced with more supporting documentation, so they're not just used for pretty pictures, but unless our cookbook documentation can be generated directly from these projects we're again attempting to maintain duplicate information. Automatically generating a set of diagrams reverse engineered from the current sources as part of the nightly build might be a long term goal to work towards, but our current reverse engineering support is nowhere near capable of that task. There are a whole host of things that could be done to make it easier to quickly generate useful diagrams with user assistance from improved layout engines to better interactive connection routing to just plain making it run faster for models the size of ArgoUML. Picking a concrete use case and using it as a forcing function to prioritize and drive the implementation of features to support it could be a good way to achieve useful results, but someone needs to do the coding to support it. Tom On Tue, Jul 15, 2008 at 4:13 PM, Tony | Zearin <[EMAIL PROTECTED]> wrote: > Bogdan Szanto wrote: > > Tony | "Zearin" wrote: > > It seems like it would be a great way for ArgoUML to promote itself, > especially since the project has so many classes… > > I guess this is why it hasn't been done. It would be too big to make > something of it. > > This got me thinking… > > - *Diagrams are more useful on larger projects than smaller projects.*When > you can wrap your head around a simple idea, like the obligatory MVC > "Calculator" programming example, diagrams help less. When it's hard to > visualize a complex set of relationships, diagrams communicate this > information such that you can glance at the part you are interested in and > instantly know what you need about a piece of software. > - *If ArgoUML does not use itself for diagrams, what does that say > about the project?* Why would anyone want to use this software if it's > not good enough for its creators? > - *What better way is there to test?* Seriously! ArgoUML can test * > itself*. This would get everyone looking at the application on the same > page, looking at the same strengths and weaknesses, and motivate people > towards the most important things that need fixing. > - *Automate what works, revise what doesn't.* I just tried importing > a direct SVN Export of my branch. (It's old and has not been touched in > months, but I svn-updated it first.) To whoever contributed to ArgoUML's > import process: BRAVO. The generated diagrams aren't all that great, but > the model is there, in full. > > I propose that the repository include a file of a similar import, and > then we can just delete the diagrams that don't work and create the ones > that do. That would make a lot of information in the Cookbook "glanceable" > information, rather than something that needs to be looked up, read > through, > and mentally constructed. > > After all, when conceiving of a project, doesn't your brain try to > create a mental diagram? I know mine does. Cut out the middle-man! Save > your brain's processing power and look up an existing diagram instead. > > Thoughts / questions / comments welcome. (Flames that are repackaged as > thoughts / questions / comments are also welcome. :) > > —Zearin > > --------------------------------------------------------------------- To > unsubscribe, e-mail: [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED]
