UML modelling with fridge-magnets

Whiteboards are a great UML case tool. They help to make modelling a social activity. They help to emphasize that the act of modelling and the understanding it produces is just as valuable as the resulting model. The wipeability of whiteboards is also a great feature. It encourages modification and experimentation.

Whiteboards are not so good when you want to rearranging a diagram though. But... it occurred to me that if the whiteboard is magnetic then fridge-magnet-style UML-shapes might help. So I found a company that sells magnetic sheet and paid a bit extra to have it coated with a dry-wipe surface. The first sample arrived today and I've made my first prototypes. I cut out two sizes of rectangles and edged them with a permanent marker. Here's one of the larger ones (the background is a tablecloth not wallpaper!)



Now simply stick them on the whiteboard - they stick to each other of course:



Here's the big rectangles vertically in 3-section class format:



And horizontally for packages (just draw on the top-left tab):



Here's a 1-section only class diagram overview made from the smaller rectangles:



And just for Pete Goodliffe here's a Booch cloud:



I'm also going to cut out some ellipses for use-cases/scenarios and some rounded rectangles (roundtangles) for activities/states.

Dan Pink's challenge to draw yourself in just 5 lines

typedef in C

I regularly coach advanced C to the great engineers at Tandberg in Oslo. One of the topics we've discussed is typedef style. For example

• not using typedefs (Linux kernel style) like this

struct wibble;

void wibble_this(struct wibble *);
void wibble_that(struct wibble *);

• or with typedefs, like this

struct wibble;

typedef struct wibble wibble;

void wibble_this(wibble *);
void wibble_that(wibble *);

This matters because typedefs are not idempotent in C, which is to say you can't write this

typedef struct wibble wibble;
...
typedef struct wibble wibble; // non-conforming duplicate

A C file has its #includes and these #includes will have their own #includes, ad infinitum. It can be tricky knowing whether a type has already been typedef'd or not, and hence whether the C file has to declare its own typedef or not (for example, when forward declaring the type). However, there is a style that neatly avoids this problem

• in header files don't typedef

// wibble.h
struct wibble;

void wibble_this(struct wibble *);
void wibble_that(struct wibble *);

• in source files do typedef

// use.c
#include "wibble.h"

typedef struct wibble wibble;

void eg1(wibble * w)
{
    ...
}

void eg2(void)
{
    wibble * w = ...
    ...
}

This is somewhat similar to the C++ rule that header files always use explicit :: qualification. My friend Kevlin Henney commented that the idea is also resembles using typedef's in the private section of a C++ class which is a nice observation. I haven't tried this on a large codebase. At the moment it's just an idea. Caveat emptor.