A note on diagrams

I’ve been writing object oriented software most of my life. First with C++ and then with Java. You can do OO with other languages of course but these two are compiled. With compiled languages, there’s a tendency to define classes and class relationships quite early in the development. You also tend to refine your OO models in much finer details than with dynamic languages (e.g. Ruby). I’m not saying it’s a good thing, by the way…

I’ve been doing this for close to 25 years. Initially with Booch and Rumbaugh and later on with UML. I’ve done it so much over the years that I tend to disassemble most books (be they science, software and even novels using a bastardized, simplified version of UML). I’ve even done a Game of Thrones taxonomy using UML at the time.

So for the sake people looking at my web site, here is a very VERY small example that gives you an inkling of the diagramming method that may be found here.

In the following diagram:

you’ll find the following relationships and concepts:

  • Any rectangle in a diagram represents a “class”. A class is usually an abstraction of a concept associated with the topic I am talking about. So if I want to talk about the car and the car fabrication process, “Car” would definitively be something that I would want to model.
  • Sometimes (most times?) I will leave the rectangle as is (like the “SUV” or “Sedan” class). Other times, I will model some attributes of the car (for example, its make and model) or some of its operations (“start” and “stop”). When that happens, I will split the rectangle in up to three sections:
    • top: name of the class
    • middle: attributes of the class
    • lower: operations of the class.
  • An arrow linking two classes represent a “generalization” (aka an “is-a” relationship). You can read the relationship following the arrow… so an “SUV is a Car” or a “Sedan is a Car”.
  • Diamonds (empty or full) represent containment. There are two types of containment (aggregation or composition). Composition (full, black) implies that the two classes “life spans” are tied together. The aggregation (empty, white) implies that the two classes’ lifespan are independent. In the diagram, I’ve represented the driver with an aggregation, meaning that their lifespan are not tied while the wheels are tied (basically, they don’t have meaning outside of the concept of a car).
  • Containment relationships may have a multiplicity. For example, a car has 4 wheels.

In any case, UML can get quite complex. What I just showed is a small portion of the class diagramming aspect of UML. It is a much larger spec that also covers sequence and state diagramming. That being said, I find that it’s usually an 80-20 proposition where you can get most of the value of the specification with the first 20% of the language. (Though what I just described is probably less than 2% of the whole thing).

If I write anything that requires more detailed UML or more detail about my “bastardized” version of it, I will attempt to document it in that blog entry or I might just spawn a new page just for notation.

P.S. I’m using a StarUML for the diagram.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: