Software Cells #E: Splitting the General Software Architecture Framework from the Prescriptive Model and Coming to Terms with UML

After I did my previous posting on the "Big Picture", I felt qualms as to whether my vision was a little bit too grant. Does the world really need my view on software? Isn´t there already UML covering almost everything you need to know in terms of modelling software? After having slept bad for a couple of nights ;-) the following answer came to me: Yes, trying to stuff everything into just one model is too much. And I´m not trying to replace UML; in fact UML can be used to express my Software Cells´ concepts.

So, how can my "Big Picture" be chopped up into more manageable pieces? I´d say, it´s best to separate the overall framework from concrete advice. Thus from now there are two different models building on one another:

Software Universe

The Software Universe is supposed to be a general framework for thinking about software. It consists of...

• The holarchy of software artifacts from Method up to Society
• An arbittrary number of Concerns to which artifacts can belong and which are orthogonal to each other
• A hiearchy of logical Categories to which each artifact can belong

Also, artifacts communicate with each other and can form a communication network:

Arifacts communicate directly on the same level within the same encompassing holon and through Connection Points if they need to cross boundaries. Connection points define and follow Contracts governing how one holon can use another one. There is no conceptual limit as to how holons can be connected, no hierarchy, no direction. Software is supposed to be able to form arbitrary networks on each level of the holarchy.

That´s all there is to the Software Universe. I guess it´s simple but nevertheless helpful in its generality. It provides a framework for thinking about software, a framework you can hook into your own models - with the only "limitation" being the holarchy with its predefined levels of abstraction which describe "software containers" and map to real world software artifacts:

However, the Software Universe is open and extensible. For example, I´m thinking if it would make sense to introduce a new holon level between Application and Solution called "Culture". A Culture would contain all Applications running on the same platform within a Solution. This level could make sense because it would clearly mark where communication crosses an important boundary. Let me know what you think of this idea, if you like.

Any extensions to the Software Universe, though, would need to fit into the existing scheme or be orthogonal to it. Also they would need to be on the same level of generality and abstraction.

That brings me to...

Software Cells

Software Cells make very concrete statements about how software should look on a certain level of the Software Universe holarchy. Software Cells thus are on a different level of abstraction than the Software Universe. They are an application of the Software Universe concepts and don´t constitute it. That´s why I pulled them from the holarchy etc. and instead set them apart as a model in its own right. Software Cells can be explained without the Software Universe - but it´s easier, I´d say, if Software Cells are based on the Software Universe.

So what do Software Cells talk about? They zoom into the Software Universe and describe how an Application holon should look like:

A Software Cell is an Application and is called a cell because it is assumed, that every Application has a basic structure regardless of the problem domain and often is part of a network of cooperating applications thus forming something like a biological united cell structure:

The most important part of a Software Cell is its Core which contains the main problem solving logic of the application. The Core consists of at least one Component holon which needs to be run by some kind of Host (a standalone executable). If the Core wants to access other Cells or resources or should be steered by a user, Adapter and Portal Components are the means to do that. A Software Cell thus is an Application holon with the following structural elements:

• Core Component
• Any number of Adapter Components to access other Cells or recourses
• Any number of Portal Components to open up for access by other Cells
• A Host providing infrastructure services to the Core and the Connection Point Components (Adapters, Portals)

Software Cells resemble the software layer architectural model in so far as they define software to consist of several parts. But where software layers put thos parts in a strict line from frontend to data access and otherwise be not very concrete, Software Cells are more flexible. Firstly they put logic at a more prominent and more appropriate position in the center. It´s no longer wedged between other concepts which might not even be present in a software. Secondly communication doesn´t distinguish between arbitrarily grouped technology but makes all input/output equal. Thus it´s much easier to describe networks of software. Thirdly Software Cells get rid of fuzzy terms like "business logic" and replace them with very concrete structures with concrete tasks: Adapter/Portals do only what is necessary to bridge the impedance mismatch between a communication API and the level of abstraction of the Core logic. Nothing more. So the logic is defined by "whatever doesn´t have to do with communication" - and thereby gets free to float from one Cell to another in a Solution (network of Cells/Applications). If you want, you then can split whatever is done by the Core logic into several categories. That´s just fine and uses another dimension of the Software Universe. However, the Software Cells model does not (yet) make any statement as to how your Cells or Core logic should be structured. So if you want to carry over anything from the software layer model, feel free. Just stick to the clear definitions of the Connection Points, the Core, and the Host. Compared to the software layer model more code will belong to the Core logic Components than to the business logic layer.

Also be aware that a software layer architecture often will map to several cooperating Software Cells.

UML

Now, finally, what about UML? Do Software Cells duplicate anything UML does? I´d say, no. Although Software Cells come with their own graphical notation (based on the Software Universe), you can depict everything using UML, if you like. Use a UML package diagram for a Software Cell network (aka Solution), use UML components for Core, Adapter, and Portal, if you like. Although I personally find the UML notation too general in many aspects, I don´t see any real reason, you can´t use it.

UML´s notion of component and package are quite abstract. That make UML widely applicable. Software Cells on the other hand try to be very concrete. A Software Universe´ Component is a set of library files (or .NET assemblies) bound together by a certain purpose. A Software Cell is a Software Universe Application, that means it´s a process hosting Components. UML doesn´t know of .NET assemblies and processes. So you maybe could say, Software Cell diagrams can be drawn as instantiations of UML diagrams with certain stereotypes to denote Software Cell structures and connections.

Phew, I feel relieved now :-) Splitting the Software Universe from Software Cells makes easier to understand and work with both. And seeing UML not as a rival, but complementing drawing tool could help to approach developers to take a closer look at the Software Cells concepts. (However, I still find it easier to quickly draw a Software Cell diagram like above than using UML notation. Maybe I´ll try to set up a Domain Specific Language for VS2005 at some point :-)