I´ve talked about what software cells are - asynchronous "islands" of code on several levels of abstraction -, and I showed you how easy they make it for you to place (business) logic where it´s most appropriate. Software cells - to me - are the structural elements for modelling an application in the large. If you´re faced with a modelling problem, don´t fear the blank flipchart! Just start with a single software cell comprising the whole of your application and do a stepwise decomposition. The goal of this first phase is to determine just functional responsibilities that can and should be executed in parallel. Most importantly that´s the processes of any application. But don´t stop there! There´s potential for parallel processing within (!) many processes. You should try to tap into it because that way you can make your application more responsive and scale better.
So far I´ve primarily covered the very nature of software cells and the meaning of their "interior". What´s missing is a discussion of their environment. A software cell is just a piece of code that needs to be triggered and which (mostly) relies on some resources.
When you start out modelling an application what you´re most interested in is determining the "parties" relevant to a software cell which you don´t have any control over. You want to know who´s using an application and what kind of resources the application is going to use. The former I call actors, the latter are, well, resources.
Actors are active, they use a software cell, they control its functions. That´s why the arrow is pointing from the actors to the software cell. Although the term "actor" might hint at humans being actors, in fact any "entity" which has the ability to trigger functions in a software cell can be an actor. Of course users (or user roles) are modelled as actors, but also an SAP system or some other application can be an actor. Whenever you do not add any code to a controlling "entity" it´s an actor.
On the other hand your application (or any software cell) is not only acted upon but also acts itself upon "entities". Those entities I call resources. They are passive with regard to a software cell. But not only files can be resources. Also other programs - again like an SAP system - can be resources. Whenever you do not add any code to a controlled "entity" it´s a resource.
Actors and resources can be introduced on any level of abstraction while modelling the nested software cell hierarchy. However, in the end, they should be visible on all levels. It needs to be clear, which actor uses which software cell, and which software cell uses which resource.
The arrows in the above pictures show control flow. The entity where and arrow starts controls the entity the arrow is pointing to. Data flow, however, is in both directions. An actor triggers some function on a software cell thereby sending it data. Later the software cell returns some result to the actor.
In addition to actors and resources software cells can be the entities using other software cells or they can be used by others.
The environment of a software cell thus consists of actors, resources, as well as other software cells. Whatever entity the logic core of a software cell is communicating with via an API (e.g. ADO.NET, System.Net, System.IO, System.Windows.Forms) belongs to its environment. Think of the membrane of the software cell as a placeholder for all such APIs. They stand between the logic of one software cell and another. And they decouple a software cell from humans or other software.
