class MODModule
{
	// ...
	bool m_loaded;
	bool m_playing;
	bool m_paused;
	bool m_reachedEnd;
};

What’s the problem with this approach ?
Let’s see…
Suppose I want to call methods on the MOD object (e.g: Pause(), Resume(), etc)
I need to make some checks in each method.

To pause…

if (!m_loaded || m_playing || m_paused)
	return SOME_ERROR;
m_pause = true;
// ... do pause stuff

Then to resume…

if (!m_loaded || !m_paused)
	return SOME_ERROR;
m_paused = false;
// ... do resume stuff

When the MOD finishes playing, I needed something like this…

// ... some code that checks for end
m_reachedEnd = true;
//ups... How about m_playing, m_paused?
//We need to change their values, so we don't break code elsewhere
m_playing = false;
m_pause = false;

And similar things when playing, stopping, etc.
See the problems?

• We need checks for multiples variables
• We need to make sure the variables have valid values in relation to each other
• What if we want to add an extra state? For example, “bool m_fading”. We would need to examine a lot of code to check how the other variables are used, and hardwire this new one somewhere. Every time you need to add an extra variable, you’ll need to check more and more code to make sure everything is ok.

Now look at the meaning of the variables. They are mostly mutually exclusive.

• If it’s playing, it can’t be paused and hasn’t reached the end.
• If it’s paused, it’s not playing, and hasn’t reached the end yet.
• … and so on….

The more data members a class has, the harder it gets to keep the object in a valid state, so, the less data to manage, the better. Less maintenance and less bugs.

One technique I use a lot when trying to simplify code is to look at it with state diagrams whenever possible.
Here it is what happens (kind of) with instances of the MODModule class:

I can easily translate it to code with enums.

enum MODState
{
    MOD_STATE_NOT_LOADED,
    MOD_STATE_STOPPED,
    MOD_STATE_PLAYING,
    MOD_STATE_PAUSED,
    MOD_STATE_REACHED_END
};

class MODModule
{
    // ...
    MODState m_state; // Now we have only one variable
};

This approach is a lot easier to maintain, and less error prone.
Now the code in most functions become something like this:

To play…

if (m_state!=MOD_STATE_STOPPED)
    return SOME_ERROR;
m_state = MOD_STATE_PLAYING;
// ... do play stuff

To pause…

if (m_state!=MOD_STATE_PLAYING)
    return SOME_ERROR;
m_state = MOD_STATE_PAUSED;
// ... do pause stuff

To resume…

if (m_state!=MOD_STATE_PAUSED)
    return SOME_ERROR;
m_state = MOD_STATE_PLAYING;
// ... do resume stuff

To stop…

// We cannot stop if it's not even loaded yet, or it's already stopped
if (m_state==MOD_STATE_NOT_LOADED || m_state==MOD_STATE_STOPPED)
    return SOME_ERROR;
m_state = MOD_STATE_STOPPED;
// ... do stop stuff

The code may look similar, but it’s a lot less error prone, easier to follow and maintain.
Looking at the State Diagram, I could easily squeeze in a “Fading” state and understand the conditions to enter or leave that state.

As a bonus, using enums will enforce more rules and help you out with errors the compiler might catch. Always prefer compile-time errors over run-time errors.

I have already tried a few.

- BOUML

- UML Pad

- Rational Rose . Only used some years ago, and never liked it.

- Visual Paradigm for UML

So far, and by far… the one I like the most is Visual Paradigm for UML . The first time I looked at it, it scared me a little, with all the buttons, and functionality. But its quite a complete package. Great documentation, somewhat clutter free windows (considering the amount of functionality), and an amazing intuitive interface, that can get you going in no time.

For example, in a State Machine Diagram, just place the initial state, and you can do most stuff from there without ever leaving the design area, simply pulling the other states from that one. Mouse gestures really help with productivity. First time I discovered those, it reminded me of “Black and White”. Depending on the kind of diagram we are working on, we’ll have some specific gestures available. For example, in a Class Diagram, we have a gestures to create classes, packages, add operations, attributes, and so on.

Most gestures are easy to remember, but to make things even easier, we even have a fast lookup window:

That menu option will show you the available mouse gestures for each diagram type, like this:

Thumbs up for Visual Paradigm. Really intuitive interface, that can really boost productivity.

Of course it has a lot more features, but the productivity boost was the most interesting to me.

If you’re looking for a good UML tool, give it a try. Maybe you’ll like it too. You can always use the Community Edition for a while, which is free for non-commercial use.