It can't hurt to have documentation for your own hobby projects, especially with multiple people working on it. Seeing things on paper helps you realize some bad design choices too.

What exactly does your tool do other than make the diagrams that's giving you trouble?

UML may be a bit heavyweight for a hobby project. There are lighter versions; Booch notation isn't as complex -- it's what I use for my projects (although I just draw ellipses because clouds are too difficult to draw).

UML notation class diagrams specifically are (in my opinion) absolutely pointless uses of time and effort. They perfectly hit the sweet spot of being both complex enough to be time consuming and also not expressive enough to be useful later on. This is one of the reasons why large businesses enjoy them. It looks detailed enough to look like work, but not enough that you can actually be assessed on the ROI of the outputs.

Basic Booch has enough structure to be worthwhile and illustrative without taking an age to do.

UML interaction diagrams, on the other hand, are actually pretty handy to have lying around, particularly the minute you start doing threading stuff and need to track lock lifetimes and so on.


As for turning the diagrams into code, just write it. Don't try and use a tool to do it; they're ALL hopeless. A few years ago UML round-tripping was the next great thing which was going to save us from the software crisis[1], but like all other silver bullets it turned out not to be the case[3].

Process and paperwork doesn't (despite the promise to) hide the fact that in order to do OO software you need to be able to do two things[2];

1. Design objects coherently. And that seems to be something that really only humans can do and then not even many of those.

2. Code objects based on those designs. This is easier -- in the sense that more people seem able to do it -- but it still seems to be a skillset not even everyone in the software business has.




[1] It started in the 60s and has never actually gone away. Although largely people have stopped talking about it using the term. It's scary that largely the industry has utterly failed to learn lessons which were obvious when my mother was a software engineer...

[2] And this is actually true whatever methodology one uses. Good OO developers can make waterfall function. Bad ones can't write the code whether you do.

[3] For two reasons. One is that the software analysis is just difficult[4]. But the main, and most obvious one, is that the poster child for the glorious revolution was Rational Rose which is one of the worst written bits of software to stagger out the door of any software company ever. And isn't the irony of that just stunning? So companies which launched heart-and-soul into that sort of thing found the tools weren't there. It was like trying to do car maintenance with only the contents of the kitchen cutlery drawer available. Those of us who had witness the 'miracle' of CASE systems saving us in the late 80s suffered a sort of redeja vu[5].

[4] Understanding what code is supposed to do is hard, even for actually intelligent humans. The machine *could* just run it and see what it does. But firstly that assumes that the code is well formed (Which is, of course, the question you're trying to answer), and secondly, at the limit, it becomes the halting problem...

[5] Not only has it happened before but it will definitely happen again.

{removed duplicate}

I disagree Katie, I always use UML when I create a hobby project and sometimes its just so that I dont get overwhelmed when I actually start coding. I also find myself much more likely to restart a project that has some documentation as it puts my mind back into the same mode of thinking.

I use StarUML, its free and once you understand the StarUML syntax the C++ output works very well; making the time spent creating UML diagrams worthwhile.

Quote:Original post by The Communist Duck
Do many other people do this for small hobby projects? I guess something like this would be standard for big, industry applications.

To my knowledge, it's not that common among indie developers to use UML.

Quote:Original post by The Communist DuckAlso, can anyone recommend any material about going from UML diagrams to C++ code?

I found one tutorial here, after googling.

UML should be seen for what it is; a standardized language for modelling systems. It's a tool to identify and document stuff, all the way from requirements right down to software design. The UML in turn does not state in which language you shall implement the software design.

When we write documentation, we always have to think about who the intended consumer of the documentation is. As an indie developer, you (often) don't have a customer with whom you have to discuss and agree upon requirements. You (often) don't have a validation and verification crew to whom you have to transfer an understanding of the requirements. You play the roles of the developer, the manager, the tester, the customer, etc. all at the same time. Thus, there's is no real need to communicate information on requirements and design between different roles through documentation.

If you are only two people working in your project it's not necessary to go with UML. You will probably be fine writing a so called "Game Design Document (GDD)", putting a scope on the requirements you have on the game for your own sake (so that you don't forget).
That said, I'm not saying you shouldn't go with UML for the project you're working on, I'm just saying it's not in any way necessary. However, as you wrote, if you want to try UML for the sake of learning, by all means go with it. It's useful knowledge when you are thrown into a larger project utilising UML. :)

If one must use some methodology, then TDD wins over UML.

1. Skill, knowledge and insight
UML, TDD: If person is the same, there is no difference. Difference comes in large enough environments where domain specialists provide enough to outweigh the communication gap between different departments, in which case UML wins, since TDD requires production code. Despite that, outsourcers seem to have mostly move to agile techniques, since they at least produce some production code, vs. lots of paperwork with no production value with UML

2. Feedback
UML: The documentation disconnect:

// must be 7 or it crashesconst int FOO = 4;

It will happen. It will happen before the first line of code is written
TDD: Test fail to compile on first disconnect, the they are always in sync

3. High vs. low-level
UML: Higher level, but abstract. A programmer/coder knows that devil lies in detail. High risk of encoding programming detail into design
TDD: Lots of noise, but when trying to remember how to use Foo with Bar, there is a function which gives tutorial-like example.

4. Tool support
UML: Usual tools, but nothing useful for production. They deal with drawing pretty pictures, not delivering the application
TDD: None to help with design, but very large insta-feedback ecosystem

5. Overhead
In both cases, there is duplicate work. TDD has advantage of being always used on actual production code, so it has better "cache locality", when coding, one can keep relevant tests in head. With UML, these two require completely different mindsets.

6. Results
TDD: brings results. They may be utter crap and result in abysmal code - but there is something. Something that works and runs
UML: It's a piece of paper that does nothing. After UML is done, there is nothing to show for.


UML works well for rigid IT departments, it's lovely for government contracts, but it's been a while since I've seen it actively used in production. Even TDD has been vastly replaced by BDD.

In the end, I've seen UML abandoned in all environments that demand results in form of production code. Companies that use focus on different goals will likely benefit from isolation and plausible deniability that UML-based approach provides.

For personal projects, each person is different, so whatever works.

PS: UML refers to RUP-based approachl, and TDD to general agile.