tools to diagram a program flow?
Discussion
http://bouml.free.fr/
Write some Use Cases to design your app and maybe some Class Diagrams
Edit: requires you to know / learn UML. But every develper should be at least comfortable with UML
Write some Use Cases to design your app and maybe some Class Diagrams
Edit: requires you to know / learn UML. But every develper should be at least comfortable with UML
Edited by JonRB on Saturday 17th May 09:02
www.inkscape.org - a sophisticated vector graphics editor released under the GPL
Pencil, paper, ruler, scanner!
Everything else is either code, or in my head.
Edited to add;
IMO Visio, is the best of all the "system diagram", type packages. It'll do all of state, flow and structure, and if you can be bothered to program it, it can generate code fragments for you.
UML.... It's a great big waste of time. DUH! (Like Vista, it's a productivity aid, that makes life more difficult and expensive!)
Everything else is either code, or in my head.
Edited to add;
IMO Visio, is the best of all the "system diagram", type packages. It'll do all of state, flow and structure, and if you can be bothered to program it, it can generate code fragments for you.
UML.... It's a great big waste of time. DUH! (Like Vista, it's a productivity aid, that makes life more difficult and expensive!)
Edited by dilbert on Saturday 17th May 14:51
UML has been around for a long time in it's various precursor forms (Rumbaugh OMT, Booch, Coad-Yourdon OOA/OOD) - since the early 90's in fact.
If you're serious about Object-Oriented development it is hard not to use elements of it. Class Diagrams are the most-used and the basic idea of drawing a box with 2 horizontal divisions and class name, methods and attributes in the 3 areas made by the 2 lines is something I think every professional developer does. At least all the ones I've worked with.
UML is just a case of the various different methods getting together and settling their differences (hence "Unified Modelling Language").
I don't see what is a "waste of time" about using a common design language to design and document a system.
If you're serious about Object-Oriented development it is hard not to use elements of it. Class Diagrams are the most-used and the basic idea of drawing a box with 2 horizontal divisions and class name, methods and attributes in the 3 areas made by the 2 lines is something I think every professional developer does. At least all the ones I've worked with.
UML is just a case of the various different methods getting together and settling their differences (hence "Unified Modelling Language").
I don't see what is a "waste of time" about using a common design language to design and document a system.
Edited by JonRB on Saturday 17th May 15:02
JonRB said:
UML has been around for a long time in it's various precursor forms (Rumbaugh OMT, Booch, Coad-Yourdon OOA/OOD) - since the early 90's in fact.
If you're serious about Object-Oriented development it is hard not to use elements of it. Class Diagrams are the most-used and the basic idea of drawing a box with 2 horizontal divisions and class name, methods and attributes in the 3 areas made by the 2 lines is something I think every professional developer does. At least all the ones I've worked with.
UML is just a case of the various different methods getting together and settling their differences (hence "Unified Modelling Language").
I don't see what is a "waste of time" about using a common design language to design and document a system.
That's always going to be the view of a believer. I'm not saying you're wrong, just that I don't agree. The thing is that I don't believe in a "right" way of doing things.If you're serious about Object-Oriented development it is hard not to use elements of it. Class Diagrams are the most-used and the basic idea of drawing a box with 2 horizontal divisions and class name, methods and attributes in the 3 areas made by the 2 lines is something I think every professional developer does. At least all the ones I've worked with.
UML is just a case of the various different methods getting together and settling their differences (hence "Unified Modelling Language").
I don't see what is a "waste of time" about using a common design language to design and document a system.
Edited by JonRB on Saturday 17th May 15:02
Such toolsets do offer some useful capabilities, and certainly I'm a huge fan of GUI based code generation tools. The thing for me though, is that "some" languages are available on virtually every platform that exists. It's not hard to write code without UML that will work on virtually any platform.
That it offers the ability to generate class diagrams is useful. For anything I have been involved with the development of I don't need a class diagram. It's sufficiently intelligable that you don't need one. If there is a "right" way to generate code, to me that's it.
Class diagrams are beneficial, when you take on unknown code, that's not all that clear. Certainly it is invaluable to establish dependencies, and is necassary bring the code into a "realm of understanding", but that is strictly the reverse engineering process. My IDE has a tool to do that anyhow.
The thing with tools that make the process understandable, at a higher level is that it leads to unnecassary complication, a code level, and that's not usually a good thing. From a development perspective, people spend good time considerig things that at a code level make little or no difference. That's the forward process.
Code generation tools are useful where the language of choice is not so good at describing the thing you are trying to describe. The most significant example of this is stateful behaviour, mealy and moore machines in c/c++. If that's what you're tryigng to do, a state diagram is massively useful, because the code that results is usually a huge switch with many bitwise assignments. The individual bits are functionally connected across disparate case clauses, and if the switch is big, it's difficult to maintain the context in your head, because you cant see the whole thing at once. I'm not clear that UML would offer such a capability in a standard form.
There is an issue with documentation, and maintaining it's synchronisation with the actual code, but if you have a tool to do that for you, then the temptation is for it to become a mechanism for requirements capture, which should be justifiably separate from user guidance material. Another temptation is that the user guidance material is unnecassarily maintained before a given capability has "hardened off"
I don't know, but I can see lots of potential problems, not many advantages that are otherwise unavailable, and facilities that would be nice that are not obviously present.
Edited by dilbert on Saturday 17th May 16:04
spants said:
Guys
Im looking for a tool to show how an application should work (before I write it!). What do you use? Visio? I'd prefer gpl/freeware if possible.
I have mac and xp here - either os would be ok
This is a very big area and a lot depends on what you're trying to do. It could range from a template or Visio to something like Rational to a fully-fledged 4GL-type mockup. How big is the application and where on that scale do you fit into it?Im looking for a tool to show how an application should work (before I write it!). What do you use? Visio? I'd prefer gpl/freeware if possible.
I have mac and xp here - either os would be ok
Pick the tool that satisfies the requirements. If you're building an OO app (and there *are* still cases where multi-tier OO isn't appropriate, regardless of what some TAs say) then anything comfortable with UML will do the job. However that's normally the case when you've picked an architecture and you're going deeper into technical requirements. I wouldn't present a bunch of pages of UML to a business head, for example. Who are the diagrams for? Are they to show basic data flow to clients, or internal technical documentation intended for programmers? Or even in-between stuff for BAs?
If you're right at the planning stage and want to put a few ideas down and throw them around, then the most important thing IMO is that the tool is usable and doesn't get in the way of your thoughts, or worse, try to force the architecture into any dogma.
I recommend OmniGraffle for this. It's not free, but I use it for all my diagrams. It's a damn sight more intuitive (to me) than Visio, doesn't 'write code fragments' (which implies a given architecture) and doesn't get in the way of my thoughts. It's incredibly flexible and extensible, and diagram objects for all sorts of formal methodologies (if that's your thing) are freely available. If formal methodologies aren't your thing, and you just want to bung down a data flow and see whether corner cases could foul up the system, you can just do boxes and lines like paper and pencil
It's really, really good. Latest version will import / export recent-version Visio XML files.
If you're right at the planning stage and want to put a few ideas down and throw them around, then the most important thing IMO is that the tool is usable and doesn't get in the way of your thoughts, or worse, try to force the architecture into any dogma.
I recommend OmniGraffle for this. It's not free, but I use it for all my diagrams. It's a damn sight more intuitive (to me) than Visio, doesn't 'write code fragments' (which implies a given architecture) and doesn't get in the way of my thoughts. It's incredibly flexible and extensible, and diagram objects for all sorts of formal methodologies (if that's your thing) are freely available. If formal methodologies aren't your thing, and you just want to bung down a data flow and see whether corner cases could foul up the system, you can just do boxes and lines like paper and pencil
It's really, really good. Latest version will import / export recent-version Visio XML files.
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff