- The AutroLooper in our new fire alarm panel -
Autronica Fire and Security (A UTC Fire and Security Company)
Trondheim, Norway

This project in two earlier papers

"From message queue to ready queue" (Ercim/Porto 2005, [1])
"Case study of a small, dependable synchronous blocking channels API"
"Ship & forget rather than send & forget"
Main description of system
"No Blocking on Yesterday’s Embedded CSP Implementation" (CPA-2006, [2])
"The Rubber Band of Getting it Right and Simple"
Description of errors and design changes
14 more pages...

Case "observation"

Industrial paper
Case study
This paper is a "Case observation" (is, perhaps, a term invented here)
13...

The "Office Mapping Factor"

Where are the lines (if any) mapping from the process-dataflow diagram to the office floor layout?
By Office Mapping Factor we mean the degree to which a program architecture may be mapped to separate offices for individual programmers to implement,
and the degree to which that implementation work is complete (high cohesion) and undisturbed (low coupling)
12...

The "solitaire" of mapping

Prior to the mapping to offices, the program architecture would have gone through a partitioning phase mostly based on functional decomposition
We believe that high Office Mapping Factor gives high satisfaction in the office, as the programmer knows what he should do, and does not have to think about how the others do their parts
However: the result must live in this world: somebody is going to implement it!
Who knows what could influence the architectural result! In our system we strived to iterate between functional decomposition and office knowledge and experience (next page).
So, Office Mapping Factor is influenced both by inherent structure and willed structure
It is recursive: so one has to stop design and start implementing at some stage
11...

The office "data base"

is not only what a person knows and his/hers experience
but often also maps some kind of curriculum
If a person has more diverse interests, this person may take care of several distinct parts of the architecture
3-5 programmers with some 20 years of real-time experience per programmer: the architecture was designed much in informal meetings around a whiteboard
10...

High Cchesion, low coupling and the office

In the context of a confined office

cohesion means that the programmer knows what to do
and is able to fulfil the task having little communication or coupling with the others in the team

He/she would not need to know how the others solve their processes
No cheating with shared variables!
To strive for high cohesion and low coupling is nothing new!
But with "the office" and "sw processes/tasks" is, perhaps, a new reflection of an old scene
9...

Process encapsulation check list (beta)

Are processes able to shut the door for other processes (or do they have to cater for every message there is)
Do you use a well understood and correct pattern for inter-process communication?
Is malignant buffer overflow possible?
Use well understood processes to contain objects (not opposite)
Does inheritance wear too much on encapsulation?
Aliasing creeps in where least expected, beware! [goto]
Enough or really too many priorities?
Have you dared to do extensive assert programming?
8...

Asynchronous comm. is “wide open”

Asynchronous communication is “wide open”

Sloping message diagram - no blocking or synchronization
Time flows end exists (to do other things in the meantime?)
Commands with replies in a defined order, or not? What if contrary to expected / designed?
What if other clients send (un)wanted commands in this phase? Do I have to set messages aside and become my own scheduler?
Correlation with running in and out of the office to agree on today's protocol?
7...

Synchronous comm. has “door”

Non-sloping/horizontal message diagram - the first passively blocks until rendezvous & data transfer
Time stops for the first to arrive
No slope to hide under - instead other processes may do their work
This scheme provides an input switch which the receiver controls!
Correlation with staying in the office to finish off the work and open only when one has time?
6...

Half this & half that: sender-side sloping

A pipe where a sender may send until the pipe is full
Pipe == chain of processes
A versatile tool when sender should never block on first N sendings
However Office Factor may be lower:
Things are easy until we reach blocking: then the easy becomes hard and the coupling increases
More things to detail with the other parties or offices
This is, I think, the reason why "blocking" has such low prestige: too late blocking is in fact, difficult to implement and to understand
Start with immediate blocking (no buffering) until that, in a particular case, gets too complicated!
5...

Scope

Medium to large grained processes
Few (3-5) programmers with 1-2 processes each
We have not used small state machines as communicating state machines
No comparable observation for OO/UML
but small OO/UML inner worlds in processes would, perhaps, make sense
A comparative study should be done!
4...

Too high cohesion & too low coupling = too bad

Too high cohesion would cause too high internal complexity!

If the persons stays in his office and almost builds the whole product for himself!
Watch out for cuckoos!

Too low coupling could also cause too high internal complexity

Just see the difference between [1] and [2]
More coupling (communication) and less cohesion (internal states) gave less total complexity

3...

Testing

We used units testing to a small degree only
The system grew with "in vivo" tests of more and more complex systems
Once the traffic system was built and the use of it designed, the skeleton seemed stable and it was easy to verify that the eye could indeed cause a rotating toe (?-)--!
When problems, it turned out that it was easy to find the office where the fix had to be done
Error tracking with a small number [0-10] open points at any time
Small enough, so that each would remember his errors
2...

Conclusions

Mapping from process data-flow to offices is possible
Simultaneous programming (high cohesion) with only the necessary amount of meetings (low coupling) seemed to work fine - both on people and C+run-time layer scale
This would give a high "Office Mapping Factor" - a term coined here
Disclaimer: other architectures may be just as good or may be better. If so,
I would, personally, be surprised!
1...

Links and contact info

[1] "From message queue to ready queue" (Teig, ERCIM'05)
[2] "No Blocking on Yesterday’s Embedded CSP Implementation" (Teig, CPA-2006)
CPA-2007 is a conference arranged by WoTUG
This paper: http://www.teigfam.net/oyvind/pub/pub_details.html#TheOfficeMappingFactor
Feel free to contact the author at:

This page has been update Dec. 2012
http://www.teigfam.net/oyvind/	http://www.autronicafire.com

High Cohesion and Low Coupling: the Office Mapping Factor

Øyvind Teig

This project in two earlier papers

Case "observation"

The "Office Mapping Factor"

The "solitaire" of mapping

The office "data base"

High Cchesion, low coupling and the office

Process encapsulation check list (beta)

Asynchronous comm. is “wide open”

Synchronous comm. has “door”

Half this & half that: sender-side sloping

Scope

Too high cohesion & too low coupling = too bad

Testing

Conclusions

Links and contact info