The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 229 , trackbacks - 0

My Links

News

Article Categories

Archives

Post Categories

The environment of software cells

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.

image

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.

image

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.

image

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.

image

In addition to actors and resources software cells can be the entities using other software cells or they can be used by others.

image

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.

image

Print | posted on Monday, July 7, 2008 11:31 AM |

Feedback

Gravatar

# re: The environment of software cells

Hello Ralf,

I just discovered your blog about software cells and really like what you've written so far. Also the focus on modeling asynchronously behaving objects as cells is very good in my opinion because it gives the method a focus and allows experienced developers to see immediately where there might be problematic areas in the application.

What I'm struggling with, is the distinction between actors and resources as well as the communication between them and software cells. What about an actor that subscribes to state changes of the cell - would it become a resource if it gets notified a few hours later? What about coupling between software cells: although a software cell has its own lifetime and operates asynchronously it might access resources synchronously - eg. an Oracle stored procedure doing some business validation via an NHibernate call. The SP could certainly be modeled as a distinct software cell running within the DB process, but wouldn't this contradict the idea of asynchronously communicating cells? Or is there an important distinction between independent and asynchronous software cells and synchronous OR asynchronous communication between cells and resources/actors?

I'm looking forward to further articles!

Benedikt
8/13/2008 4:05 PM | Benedikt Eckhard
Gravatar

# re: The environment of software cells

@Benedickt: Yours are very valid questions. I hope to answer them one way or the other in upcoming postings.

At this point just let me comment on actor vs resource. An actor is initiating a communication with a software cell, a resource is passive in that regard. So the arrows between actors and software cells and resources signify control flow. Think an arrow pointing from a client to a service.

So what´s an environmental entity that´s subscribing to state changes of a software cell? Is it an actor or a resource?

Who´s initiating the "contact" between it and the software cell? I´d say it´s the entity, so it should be modelled as an actor. The software cell is its service - which occaissonally sends notifications about its state.

But if you like, you can model it differently. E.g. if the entity is subscribing just once after installation and then is notified for years on end... Then you could model the same entity as an actor in the subscription process and as a resource for the notifications.

Distinguishing between actors and resources is less important than you might think ;-) The main reason I suggest to model them at all is because we´ll derive part of the software structure from their existence. So stay tuned...
8/15/2008 9:19 AM | Ralf
Post A Comment
Title:
Name:
Email:
Comment:
Verification:
 

Powered by: