Software Cells #5: A journey through the software universe from single statement to Software Societies

So, where are we with Software Cells? In my last posting I talked about Contract First design, and I guess, we now need to tie together the various bits and pieces.
We need to talk about how to connect Software Cells. For that it´s beneficial, to put Software Cells into perspective. So let´s first vary the scale of our software map. Let´s get on a journey thru the "software universe"! What can we see, if we look thru a microsope? What can we see, if you look thru a telescope?

The smallest relevant units of software development are single statements, I´d say. We can write programs by just adding statement to statement to statement etc.
Here´s how such a list of statements could look like:

If we increase the scale of our map, we can see the first unit of aggregation. If we come across groups of statements, that appear several times in our code, we can lump them together to form subroutines.
With subroutines we can start to structure our code:

On the next level we group subroutines which somehow belong together to form classes (or more general: types):

If we crank up the scale of our software map, assemblies come into view. Each assembly implements one or more types which in turn contain our statements organized into methods:

One or more assemblies together can constitute a component. Of course, not every assembly (or group of assembly) can be viewed as a component. But if several assemblies together solve a (sub)problem and publish their service thru an interface, than they can be labeled "component":

But standalone componente don´t make much sense. Components always run in a Software Application (or Software Cell) whereas the Host and the implicit Microkernel, too, are components (albeit given infrastructure components):

If you´re missing the Software Cell structures in the above picture (e.g. Core, Application Adapter), fear not! I have not forgotten about them :-) During our journey thru the software map using varying scales, though, I chose not to depict them, because they are logical enities, whereas statement, method, class, assembly, component, and Application are physical entities. E.g. a component consisting of several assemblies is a VS.NET solution with several projects. An Application comprises a Host EXE and several DLL assemblies, its physical unit is a directory (with subdirectories) (lets leave aside for a moment assemblies installed in the GAC). But where´s the phyiscal boundary around a Software Cell´s Core or Adapter? A Portal can consist of one or more components. But there is no "natural" physical tie holding them together. (Although, this makes me think, if maybe Cell structures should always be deployed in separate sub directories of the Application directory. Hm... I guess, that whould be a good idea. But for now, I won´t include it here in this series of pictures.)

Another reason, why I do not show Core, Adapter etc. is, they are different kinds of "containers". However, what I´m trying to show here is, how entities of the same kind tied together form a new kind of entity on a higher abstraction level: Many statements taken together constitue methods, many components taken together form Applications etc. The structure of an entity on a given level thus always is homogeneous. Applications just contain components. Components just contain assemblies, assemblies just contain types etc.

Of course, then the question is, what do several Applications taken together form? Applications put together to solve a problem constitute a Software Solution:

Several Software Solutions communicating with each other are the subject of the discussion around "Service Oriented Architectures" (SOA). But SOA is not a name of the entity formed by several cooperating solutions. SOA is concerned about the How of combining solutions, but is not and neither coins a name for the entity that is made up of those solutions. So, I gues, I´m free to choose a name, since the term "system" sounds too general. Inspired by Marvin Minsky´s "Society of Mind" I call several solutions working together a Software Society, and it´s the last level of abstraction I´m going to depict:

The longer I think about the name "Software Society" the more I´m satisfied with it. "Society" implies the living/working together of many individuals. And since services in SOA are to be seen as autonomous entities, the almost look like individuals with their own agendas.

Now lets step back to get an overview of the "software universe" we just travelled thru. (If this reminds you of "Powers of Ten" I´m glad, because this book somewhat inspired me to take you on this journey thru the different abstraction levels of software.)

I would have liked to provide you with a single tool and an extensive example to zoom thru just moving a scale slider up or down like you can do in Mappoint. But, alas, I neither know of a single tool, that lets you view software structures from whole Software Societies down to single statements, nor do I have an example of such a large system. But I hope you get an idea of what I wanted to show you: Software exists and can be talked/thought about on different levels of abstraction. And as usual, it´s best, if you always know on which level you are in your work. It´s good to know that in order to apply the right tools, patterns, concepts, as well as terminology.

Also, I find it quite enlightening to see the similarieties among the different levels of abstractions. Firstly the constituents on each level are of the same kind and consist of homogenous substrcutures. Secondly, on each level structures define (or should define) an interface and then implement that interface. The more explicit, the better :-) Since each statement can be expressed as a subroutine call, small scale interfaces are equal to method signatures. A the type level, the sum of subroutine signatatures on a type form its implicit default interface, but we can define an explicit one. So far all´s well.

However, I now find it strange, that on medium and large scale levels of abstractions above the type level there is no explicit interface "structure". Instead, it´s a lot about conventions and "you should". The interface of assemblies, components, applications, and solutions is always just the sum of the interfaces on the lower levels. But a "sum" is a very weak definition. WSDL can be seen as an effort to counter that and to attach an explicit interface to an Application. But components and Software Societies lack such explicit interface descriptions. Thus, the interfaces of assemblies and components and even solutions are the implementations. And that´s exactly what should not happen. An interface should be separately defined from its (possibly many) implementations.

But there are more aspects that come to my mind, when I look at the "software universe" with it´s levels of abstraction. They have to do with sciences we know well, but usually are not connected to software development: social science, biology/chemistry, and physics. Try this:

• Look at the levels of abstractions as the path of development of the "civilization" of software artifacts. At the bottom you see individuals (statements) and the higher up you go, the larger the groups those individuals form. They start out with small groups (methods), then methods flock together to form types etc. Although each level´s structure is physically homogeneous, logically the substructures are different. This is like the ongoing trend of specialization and division of labour found in our human societies.
• Or look at the "software universe" as different levels of organizational forms in living organisms. At the lowest levels they are made up of molecules. Then molecules form cells, cells flock together for constitue tissues and organs. On each level information is exchanged in various ways, cells have interfaces, and organs like a heart or brain have interfaces.
• Or look at how the parts on each level are connected. On the lowest levels the connection is very tight. Tight coupling is beneficial between methods and classes and even assemblies to provide performance. Since on those levels a single human being can keep the complexity in his/her head, tight coupling also seems ok from the perspective of maintainability. But above the level of assemblies the coupling between the parts becomes ever looser. This is like in physics. The tightes coupling exists between quarks that make up neutrons and protons. The farther you try to pull them apart, the higher the force binding them together. But this is contrary to our experience on the mikro or makro level. There forces like gravitation or electro-magnetic fields descrease with increasing distance between parts. The same is (or should be) true for the "force" of coupling in software: it becomes weaker and weaker the higher the level of abstraction.

Most literature you come across in developer magazines and books, deals with small to medium scale scenarios. Often, though, the component level is not discussed. Then Web services and SOA came along and brought Software Societies into the picture (although without giving them a name). But neither SOA nor OOP clearly defined what Applications and Solutions were. So there was a gap, I´d say. OOP is concerned with small to medium scale software concepts and structures. Component Based Development (CBD, or Component Oriented Development (COD)) is less of an official diciplin but is concerned with medium scale concepts. SOA is about the top end of large scale software concepts. But what about the lower end of the large scale concepts? What about a connection between components and societies.

That´s were Software Cells step in. I figure, they close a gap by clearly defining aggregates of components running within a host as Software Cells (aka Applications) and aggregates of Applications as Software Solutions which then are the consituent parts of Software Societies.

My, oh, my, this journey thru the "software universe" has taken me longer than I thought. I guess, I´ve to postpone talking about connecting Software Cells. What out for my next posting when we will see, how Applications are tied together to form Software Solutions and even Software Societies. Then, finally, technologies like .NET Remoting and Web services fall into their places within this large puzzle :-)