Sunday, September 21, 2008

... and Found?

What is a center in software? Although I gave the subject some serious thinking, my answer is quite simple; in fact, we knew it all along.

Let's recap Alexander's definition:
Centers are those particular identified sets, or systems, which appear within the larger whole as distinct and noticeable parts. They appear because they have noticeable distinctness, which makes them separate out from their surroundings and makes them cohere, and it is from the arrangements of these coherent parts that other coherent parts appear.

We might be tempted to define centers as the main decomposition mechanism in some paradigm. For instance, we could say that centers are classes. In fact, if you change "centers" with "classes" in the text above, it still makes sense. Of course, that would be the wrong answer. Is is functions, then? This is the path Jim took, until he got down to the spatial properties of code and so on. I'll try the road less traveled by.

I've often quoted Philip Armour saying that software development is a knowledge acquisition activity. In Listen to your Tools and Materials, I went one small step further and said "Our material is knowledge, or information.We acquire, understand, filter, and structure information".

Information is often assimilated with data, as in data structures, databases, and so on. That's a limiting view, as it could only be applied to finite sets, defined extensionally. Information can also be captured intensionally, by defining predicates. Information can be captured procedurally, by defining processes. This is where I first depart from Jim. I see no need to transform procedures into spatial data structures. Procedures are fine just as they are: information encoded through a process.

It is interesting to see that the act of acquiring and encoding information permeates all phases (or activities) of software development. We analyze requirements by understanding, classifying, encoding information. It doesn't really matter if the result is a use case, a class diagram, a piece of code, some natural text, a set of test cases. We structure information during design, while coding, even while indenting text. It may be turtles :-) all the way down in meatspace, but it's information all the way down in cyberspace.

This is exactly the kind of fractal nature we were looking for. However, the magic X is not simply information: it's highly cohesive information. OK, that was it :-).

The concept scales very well across a number of paradigms, artifacts, scales. A few examples:
- a good class is a set of cohesive methods and data
- a good module is a set of cohesive classes or functions
- a good function (or method) manipulates cohesive input through a cohesive process (separation of concerns) giving out a cohesive output (information hiding)
- a good aspect brings scattered concerns together into a single, cohesive point of development, maintenance, and reuse.
- empty lines in source code are used to separate highly cohesive portions of code.
- proper layout in UML class/component diagrams is used to aggregate highly cohesive portions.
- and so on.

So what is a center? A center is a locus of highly cohesive information. The form of a center is influenced by our paradigm and our material. But as I contended a couple of years ago in a post I prophetically :-) titled Unifying Concepts, paradigms are all about one single principle. Partitioning knowledge, I said then. Partitioning information in highly cohesive sets (or loci), I should say now.

What about Jim question? What kind of x is there that makes it true to say that every successful program is an x of x's? Highly cohesive information, of course! From subsystems to components, down to grouping and indentation of source code.

I began this post by saying we knew it all along. In a sense, we did: in another prophetic post (More synchronicity, do I need to say more? :-), I quoted Yourdon saying that he got the concept of cohesion while reading Alexander.
That kinda closes the circle, doesn't it?


michelangelo said...

Carlo, un post molto bello, complimenti!

La visione che proponi e' come al solito chiara ed illuminante. Credo sia il punto di arrivo della discussione su forma e funzione ma anche un punto di partenza.

Un punto di arrivo perche' mira a catturare l'essenza del bello (tutta?). Spesso ho potuto apprezzare la bellezza di un design come si puo' apprezzare la bellezza di una composizione musicale o artistica. Ma senza poter dire quale era la ragione profonda di tale apparenza. Adesso mi fornisci un criterio per riconoscere i motivi di un apprezzamento estetico. Un criterio che razionalmente condivido e spero di poter verificare.

Un punto di partenza perche' fornisce un criterio operativo per costruire un buon design. Si' perche' e' un criterio allo stesso tempo artistico e ingegneristico, dove l'estetica coincide con i principi, il bello col buono. E il primo diventa oggettivo (che e' la tesi di Cristopher Alexander).

Come tu stesso dici nel post precedente si puo' usare questo criterio nella ricerca di soluzioni di design come complemento agli strumenti (=principi) usuali. Come e' usuale fare per un matematico o uno scienziato.

Osservando che quanto dici unifica le due anime dell'ingegneria del software, che e' insieme arte e scienza, concludo con la frase duale rispetto a quella di apertura: un post molto buono, complimenti!

Carlo.Pescio said...

Grazie Michelangelo,
considerando l'argomento non proprio trendy, mi fa piacere vedere che qualcuno ha apprezzato :-).

Sul concetto di forma nel software ho ancora molto da dire; diluisco l'argomento nel tempo perche' mi rendo conto che per molte persone e' un po' un "mattone", ed anche perche' io stesso devo trovare, strada facendo, il modo migliore per esprimere e concretizzare alcune intuizioni...

Sto imparando, insomma :-).

Fulvio said...

Non credo che post del genere siano meno apprezzati. Forse si ha un po' meno da ad esempio non ho molto da commentare perchè non ho conoscenze in tal senso (e anche se mi piacerebbe farmele e pensarci tanto, al momento ho altre priorità :-)). Di solito sono però post illuminanti, nel senso che imparo lo stesso molte cose. Qualcosa su cui devo ancora riflettere è cmq un inizio ;-)))