What is the name of the development technique that uses diagrams to map out a program?

Please try not to make duplicate threads. I left this one and deleted the other, as Game Design seems to be the better location for what you wish to learn.
Alex

UML is the most known of many. http://en.wikipedia.org/wiki/Unified_Modeling_Language

(Jan 10, 2011 09:02 PM)Jmcclane Wrote:  What is the name of the development technique that uses diagrams to map out a program?

You mean a flow chart?

UML! Thats it. Thanks fellas

I do most of my UML diagrams on the Mac in Omni Graffle.
http://en.wikipedia.org/wiki/OmniGraffle

On the PC, I guess Visio is the way to go.
http://en.wikipedia.org/wiki/Microsoft_Visio

Ugh. OmniGraffle is teeeeeeeerrible for UML. It's terrible for almost every thing I try to use it for. I constantly find myself fighting with it to get lines and text to go where I want.

I think it's really only useful if you stick exactly to using prefab'd stencils. If you want to do something slightly different, you're hosed. (Unless you go learn how to make stencils...)

Writing a UML program has actually been on of the ideas rattling around in my head for a long time. I'm just pretty sure no one would buy it, even if it was the most awesomest UML program ever

(Jan 12, 2011 12:30 AM)SethWillits Wrote:  OmniGraffle... I constantly find myself fighting with it to get lines and text to go where I want.

Agreed, I have to create a separate layer with empty (invisible) text boxes just to position the arrows and lines. But it is the best I can do on the Mac...

(Jan 12, 2011 12:30 AM)SethWillits Wrote:  Writing a UML program has actually been on of the ideas rattling around in my head for a long time. I'm just pretty sure no one would buy it, even if it was the most awesomest UML program ever

That is because UML is inherently useless

(Jan 12, 2011 08:30 AM)OneSadCookie Wrote:  

(Jan 12, 2011 12:30 AM)SethWillits Wrote:  Writing a UML program has actually been on of the ideas rattling around in my head for a long time. I'm just pretty sure no one would buy it, even if it was the most awesomest UML program ever

That is because UML is inherently useless

Excuse me, what?

What is useless is reading tons of your source code trying to understand and extremely easy finite state machine that can be draw and understood in UML in seconds/minutes using state charts diagrams.

And nowadays, it is possible to create programs using exclusively UML, as well as other techniques as DSLs.

One example:
http://www.acceleo.org/pages/home/en

An extremely good example using MDD with real time graphics (not UML but similar idea):
http://quest3d.com/

And more info:
http://en.wikipedia.org/wiki/Model-driven_development

You are like that people that 50 years ago said that very firsts compilers (Fortran, COBOL...) were useless and never will be used. In other words, you are inherently wrong. The history repeats.

If you have an extremely simple finite state machine, you don't need UML to describe it. A few circles and arrows will be intelligible to anyone, not just people who understand UML.

I'm not arguing that diagrams are not useful in explaining code structure. I'm not arguing that a graphical programming language is a bad idea (though I haven't seen a good one). I'm arguing that UML itself (and possibly any such formalism) is a bad idea.

The biggest problem I see with UML is that in order to be maximally expressive, it is complex. That means that for anyone to interact with UML, they need to first learn it. That's something nobody wants in a documentation tool. To me, it will always be better to create an ad-hoc minimal representation and briefly describe it, than to use a complex external system like UML and refer to its documentation by way of explanation.

The other problem with UML is that it tends to capture the most useless details about system interaction. Data models and interaction diagrams are not often actually useful information, and they can usually be trivially gleaned from the code.

UML is huge. There are 500-page books written on it.

Class diagramming might be nice, but it doesn't make all of UML nice. In my university software engineering course we did everything in the most archaic way possible. As part of that, we learned a ton of different UML diagrams to describe how to build software. If anybody ever used those in a real job, I'd walk away from it. UML has a diagram for everything, but just because it exists doesn't mean you should use it. With UML, describing the simple takes way longer than it needs to, and describing the complex is often pointless because...... THIS IS SOFTWARE!! Software is *constantly* changing. Bridges do not. Engineering practices for bridges (making detailed blueprints of everything) do not work well for software.

My scatterbrained 2¢.

(Mar 22, 2011 10:14 AM)OneSadCookie Wrote:  If you have an extremely simple finite state machine, you don't need UML to describe it. A few circles and arrows will be intelligible to anyone, not just people who understand UML.

I'm not arguing that diagrams are not useful in explaining code structure. I'm not arguing that a graphical programming language is a bad idea (though I haven't seen a good one). I'm arguing that UML itself (and possibly any such formalism) is a bad idea.

The biggest problem I see with UML is that in order to be maximally expressive, it is complex. That means that for anyone to interact with UML, they need to first learn it. That's something nobody wants in a documentation tool. To me, it will always be better to create an ad-hoc minimal representation and briefly describe it, than to use a complex external system like UML and refer to its documentation by way of explanation.

The other problem with UML is that it tends to capture the most useless details about system interaction. Data models and interaction diagrams are not often actually useful information, and they can usually be trivially gleaned from the code.

Just the opposite. UML and that kind of languages (ie, DSLs) are used to raise your level of abstraction, an example are state charts, you think about states, transitions, enter actions, exit actions, transition conditions... if you use java or c++, you don't have that kind of expressions.

As you said, it is true maybe is not neccesary for a very small state chart (as far as I remember, PACMAM ghosts had 3 states), but usually your program becomes more complex and apart from that, it is easier (and faster, and time is money) share your knowlegde with your work mates.

For your comments, I believe (maybe I'm wrong) you think in theory a system could be done entirely visually with diagrams, but as you think, there are some restrictions and requests in model you cannot express using UML, so, UML has what is callled OCL, which is a language, let's say similar to SQL (not the same).

---

(Mar 22, 2011 10:31 AM)SethWillits Wrote:  UML is huge. There are 500-page books written on it.

Class diagramming might be nice, but it doesn't make all of UML nice. In my university software engineering course we did everything in the most archaic way possible. As part of that, we learned a ton of different UML diagrams to describe how to build software. If anybody ever used those in a real job, I'd walk away from it. UML has a diagram for everything, but just because it exists doesn't mean you should use it. With UML, describing the simple takes way longer than it needs to, and describing the complex is often pointless because...... THIS IS SOFTWARE!! Software is *constantly* changing. Bridges do not. Engineering practices for bridges (making detailed blueprints of everything) do not work well for software.

My scatterbrained 2¢.

UML have more than 20 diagrams and many artifacts. But you don't have to know all of them, actually, usually I use only 3 diagrams: Class diagrams (static part), state charts diagrams (dynamic part) and another one that I don't remember its name in English, to express how diferent objects interac among them in time.

"THIS IS SOFTWARE!! Software is *constantly* changing. Bridges do not."
You can change your flat outside and inside as many times as you one, meanwhile you don't touch columns. And software usually has columns, sometimes in order to make a change, you have to start your software from scratch.
Apart from that,let's say I have a system where state charts ara automatically converted to code (quest3d is an example), what do you think it is easier to maintain/understand and faster to change, a state chart diagram or several pages of c++ code?

Please don't lump UML and DSLs in the same basket. DSLs are a *good* thing, that successfully raises the level of abstraction. UML doesn't raise the level of anything, except possibly buzzword-compliance. UML diagrams each "explain" (usually poorly) some small facet of the whole system. They focus, rather than abstract.

If you need a class diagram, draw a class diagram. You don't need 500 pages of specification to say "boxes are classes, methods are above the line, ivars are below the line, composition is --> and inheritance is ==>". You probably don't even need that sentence; chances are it's self-evident from any diagram. Likewise for any of the other chart and diagram types UML specifies.

(Jan 12, 2011 12:30 AM)SethWillits Wrote:  Ugh. OmniGraffle is teeeeeeeerrible for UML. It's terrible for almost every thing I try to use it for. I constantly find myself fighting with it to get lines and text to go where I want.

It takes getting used to, but I've found it pretty great for lots of things, especially general architecture diagrams.

Quote:Writing a UML program has actually been on of the ideas rattling around in my head for a long time. I'm just pretty sure no one would buy it, even if it was the most awesomest UML program ever

I think a good UML program would be very popular. But "good" means it follows all the UI rules: self-explanatory, discoverable, beautiful, intuitive, and most-of-all, useful.

Unfortunately, UML itself isn't most of those things, and needs to be overhauled or replaced with something more obvious and generally useful.

On the other hand, good pseudo-code is still often preferable. But diagrams have their place, especially class and sequence diagrams.