Wednesday, December 27, 2006
Poster: Modeling with UML and Colors
Over time, I've seen more than a few people printing out some of my papers on colors and sticking them to the wall, so I took a little time during the holidays to create a poster (A3 format, but it's in PDF and should scale relatively well) representing the original colors from Coad, my extension for classes, and colored interaction. I've been frequently asked for the exact colors to use, so I've included the RGB coordinates I'm normally using in my drawings.
For some background, look here:
- Peter Coad, "Show Your Colors", in The Coad Letter No. 44, September 1997.
- Peter Coad, "Component Models in Color", in The Coad Letter No. 51, July 1998
- My UML Manuale di Stile (in Italian)
- My paper (with Andrea Baruzzo) "Progettare con UML ed il colore: facciamo parlare la struttura", Computer Programming N. 145, Aprile 2005 (again, in Italian).
For some ideas on why coloring a diagram can be useful, see my paper "Listen to Your Tools and Materials", IEEE Software, September/October 2006
Sunday, December 24, 2006
Merry Christmas!
To all of you, my best wishes for a joyful Christmas!
Saturday, December 23, 2006
Infrastructure and Superstructure
- intentional architecture ("explicitly identified and then implemented")
- accidental architecture ("emerges from the multitude of individual design decisions that occur during development,")
( - to these, I would add "no architecture", when the accidental architecture has no internal coherence, but more on that later).
I've been using those terms since then, but recently I realized that I would prefer to use Structure as the foundational term. Architecture (from Greek, αρχιτεκτων, "master builder") is an act of will; in this sense, it's always intentional. Structure can be the consequence of several unrelated decisions. Lack of structure is the byproduct of unrelated and inconsistent decisions.
So, what Booch calls "accidental architecture" I would simply call Structure; "intentional architecture" is indeed "intentional structure", or Architecture tout-court.
Structure can also be found at finer granularity, and it makes sense to say that although we have no Architecture, some modules are well Structured.
We also use the term Infrastructure quite liberally, while its use should be somewhat constrained, as the implication of a real infrastructure is that it soon disappear from conscious thought processes. If you have to think about it all the time, it's not an infrastructure.
Indeed, quite recently one of my clients told me "with this infrastructure we built, we have a foundation for further developments". Which would be nice, except that what they build it's not an Infrastructure: it's a Superstructure.
Now, the difference between an infrastructure and a superstructure is that the superstructure is built upon something else. Quite often, in software development, that "something else" is relatively ill-structured, and the additional layer is supposed to bring some order to the chaos.
The dark side is: unless you can remove all access to the underlying layer (that includes calls from existing software) you're not building an infrastructure. Unless you have to go through it, it's not an infrastructure.
If you have to be consciously aware to use it properly, if you constantly have to pay attention, if you can bypass it by mistake, it's a superstructure, not an infrastructure.
Note that a superstructure is not inherently bad: quite the opposite, the ultimate goal of an infrastructure is to be the foundation for a superstructure. However, when we mistake (or sell :-) a superstructure as an infrastructure, we're in for some major headaches...
Wednesday, December 13, 2006
Simulating Trail Argument Deduction in C#
Somehow, they must have inspired me :-), because although we didn't talk about generics yet, on the way home I realized there is an extremely simple way to simulate trail arguments deduction in C# (see an old post of mine about C# lacking that feature).
Let's review a trivial example:
class Test
{
public static void f< T1, T2 >(T2 p)
{
// would use T1 and T2 in real cases
}
}
class App
{
public static void Main()
{
Test.f< double, int >(3); // works
// Test.f< double >(3); // error
}
}
If we accept a small twist in syntax, we can easily simulate trail argument deduction by adding a class:
class Test
{
public static void f< T1, T2 >(T2 p)
{
// would use T1 and T2 in real cases
}
}
class Test< T1 >
{
public static void f< T2 >(T2 p)
{
Test.f< T1, T2 >(p);
}
}
class App
{
public static void Main()
{
Test.f< double, int >(3); // works
// Test.f< double >(3); // error
Test< double >.f(3); // works
}
}
Not exactly the same thing, but good enough in many practical cases.
