The Voodoo UML Class Diagram Editor Website

• What is it?
• What do I need to run it?
• What do I need to compile it?
• How can I get it?
• How do I install it?
• I found a bug. How do I report it?
• Can I help?
• Relevant (and less relevant) links

What is it?

The Voodoo UML class diagram editor is a UML class diagram editor. That is, it allows someone to draw a model of the static structure of a system (a class diagram) in a standard industry-wide notation (UML).

It is also a very portable, self-documented (that is, the program's structure is documented with diagrams done using the program itself), object-oriented, buzzword-compliant piece of software.

It was originally written for a software engineering course (COEN431) at Concordia University; since that time, it has been significantly enhanced and cleaned up, mostly as part of a project course (COEN490) at the university as well.

The full list of people who have, at one time or the other, worked on the project, is available in the THANKS file.

The program is made available free of charge, but with (non)-restrictions on its distribution; it is licensed under the GNU LGPL.

What do I need to run it?

You'll need Tcl/Tk version 8.0.5 or later. The program has been tested on Linux, Solaris, Windows 95 and Windows NT 4.0. It was written with high portability in mind, so it should work on any platform to which Tcl/Tk 8.0.5 or later was ported.

For non-Windows platforms, you'll also need a C++ compiler to compile the stuff, because we're too lazy to build for every UNIX and Tcl version out there. You should use G++ version 2.95 for compiling. It may work with older compilers, but they aren't supported officially.

UPDATE! This now compiles under VC++, but the DSP files tend to be a bit behind (they are as I write this). Also, the current build system works much better with Tcl/Tk 8.3.x (we use the Tcl and Tk stubs).

What do I need to compile it?

The provided Makefile compiles using g++. Use version 2.95 or later; there's no good reason you should use any older version than that.

You'll also need the development libraries for Tcl/Tk version 8.0.5 or later. They should be properly installed. We have tested with Tcl/Tk 8.0.5 and 8.3.2; it works rather well with both. 8.3.2 is the supported configuration.

For compiling under Win32, the provided Makefile assumes you are using the Mingw32 environment for your compilation. There are .dsp and .dsw files for VC++ compiler users, but they are usually a bit out of date (I don't have that beast at home). You'll need the libraries for Tcl/Tk as well.

How can I get it?

The current ``stable'' version is Version 1.99.11. The source archive contains files necessary to build the system. The Win32 executable contains a dynamically-linked executable for Windows 9x and NT 4.0 or later (linked for Tcl/Tk 8.1+).

The manual (PDF file, ~260 KB) points out how to use the program. Other documents are available in the source archive.

The canonical source for the project's files is the SourceForge repository. Follow the site's instructions to get anonymous CVS access. To gain write access to the repository, please contact the current maintainer, and make sure you mention what you've changed so he can stick you in the THANKS file. Note that the CVS version is not guaranteed to work at all--use it at your own risks.

You can also see the CVS repository through the CVS web interface.

I found a bug. How do I report it?

If you found a bug, please report it in the Voodoo Sourceforge Project Page. Go to the Bug Reporting section and enter your bug. Note that it sometimes takes some time for the developers to see and fix your bug. If you have a patch for the bug, please submit it in the Patch Manager as well as report the bug itself, and we'll be eternally grateful.

Remember that even something as ``trivial'' as reporting a bug helps the project become better. So, if you find one, don't be shy! Report it!

Can I help?

Glad you asked! Voodoo is a Free Software project, and although the current maintainer likes messing with it, more developers are always welcome.

To register as a developer, you'll need to register as a developer on SourceForge. Once you've done this, e-mail your SourceForge ID to the project's adminstrator. Please include a small blurb on your past experience in programming; this is not because we're elitists, it's just that we don't want some random bozo messing up the CVS repository.

You should gain full CVS access within a few days. The project administrator will send you a confirmation e-mail.

How can you help with the project? Well, before you do, you should read the design document (located in design/design.texi in the source distribution) and try playing a bit with the source. Feel free to bug the maintainer with questions on how the code works--remember, there are no stupid questions! Once you feel comfortable, here's a (more or less up-to-date) list of things to do:

• Somebody needs to revamp the build system, and that can't be the current maintainer because autoconf hurts his head too much.
• It would be nice if someone could take an afternoon or two and seek and destroy useless header inclusions in the code, so we can reduce recompiles (the current makefiles are actually optimistic, but we want to fix their dependencies so they behave properly, and that means never compiling one file too many).
• Someone good with template could give us a vector<> and map<> partial specialization for all pointers to void* to reduce code size. I'm confident we could make the application a bit smaller by doing so. A similar solution for the double pointers would be great too, although I'm not holding my breath here.
• Add a cycles detector to help detect problems in some odd situations. This is necessary to kick the current CVS version out of Beta status.
• Fix the architecture: nearly all Edges and all Nodes share an awful lot of common code; that code should be in common classes so we don't have to go and change each and every view all the time...
• Persistence format really sucks; we should output XML to interoperate with other products, or at least supply a converter. Even if we don't go XML, we need to update the format to support stereotypes, and I'd like to do so in a backward compatible manner, which definitely means we have to change the format because I'm sick and tired of redoing it every time I add a field to a Node type!
• Documentation! If you're not a coder, we need to move the user's manual to something I can edit properly (texinfo, perhaps?)
• Figure out how to use one of the Win32 printing extensions. PostScript printing is OK, but it's not fantastic, and stops any serious use under Win32 unless we assume everybody has Adobe Distiller or Ghostscript.
• The UI Tcl/Tk script isn't the cleanest piece of software engineering. It needs a bit of cleaning up and major commenting.
• The back-end needs to be commented properly, or at least, the design document must be updated.

Here's a list of features I don't especially expect to implement anytime soon, but I think the necessary framework is there to do so. It's just that they're sort of pipe dreams.

• Validation. The system should disallow creation of UML class diagrams that aren't valid. This may be a switch, because current version diagrams would be unusable if we disallowed that kind of operation all the time.
• Plugins. The system could probably support plugins for new object types relatively easily. We just need to do it.
• More fine-grained interface to the Tcl script. Coupled with the abovementioned plugin system and a C++ to Tcl bridge, we could actually write new object types in Tcl, hence distribute object types without recompiling the app! Maybe even embed them in the save file.
• Other UML diagram types. Now, I'm not sure how we'd handle that, but the framework is certainly flexible enough to support all sorts of other wacky diagram objects. The main problem may be to make sure that you can't mix and match. That would give a tool that would be a portable alternative to Dia (wouldn't that be swell?)
• Multi document support. Shouldn't be so difficult, just hunt and destroy any direct references to the docMan global, replace it with a list, and do some monkeying with canvas variables. Most of the work would probably be to fix voodoo.tcl...
• Code generation. That would be really, really, really swell, but it's also totally nuts. Maybe a separate project that would use the same underlying framework, but without the views? That could be the start of a full CASE tool... (shyeah, right!)

How do I install it?

We provide two installation guides: The guide for people compiling themselves, and The guide for people installing the Win32 executable.

Relevant Links

• The maintainer's webpage is full of random stuff, some of it useful (see especially the programming section).
• Frank's website contains the old documentation for the project; this is mostly for historical interest.

Comments? Suggestions? Email-me at Benoit Goudreault-Emond <bge@crosswinds.net>

Last modified: Sat Dec 2 01:58:05 EST 2000