Re: Updated design document: decoupling

On Tue, 1 Jul 2003, Peter Soetens wrote:

[...]
> Semantic decoupling (a drawing might be handy) : 
> What I understand is that you want the programmer work with purely symbolic 
> representations at one place and let him decide at another place what is 
> underneath these representations. 

That's not what I mean :-) "Semantic decoupling" is a learned term
(patented by me :-) that means nothing else than that the designer
should group functionality together in a common library to the extent
that this functionality "naturally" and "inherently" belongs together.
In short: common sense :-) In practice: it's _very_ difficult, because
most designers group things together according to there application
domain scope. (We do too in Orocos, but hopefully our scope is much
wider than most designers' :-)

> Small Interfaces :
>  - means also many interfaces. The more interfaces exist, the more difficult 
> it is to : 1) grasp their existence and working (they are often too abstract) 
> 2) maintain them (need to edit many files if one changes) 3)  design or 
> refactor them  (ditto)

Here the "semantic decoupling" comes in handy :-) Each interface
should be _very easy_ for a worker in the field to understand, exactly
_because_ it groups naturally connected functionality.
Your objections 2) and 3) are exactly what I'm quite sure can be
avoided by choosing the appropriate semantic decoupling: somebody who
is expert in a certain field will understand the _whole_ API and the
algoritms behind it. So, it should be easy for him to maintain and
refactor.

Some examples: 
- in the kinematics design, I separated the "internal" and "external"
  modelling and programming aspects. Because somebody who is versed in
  singularities and redundancy resolution and efficient kinematics need
  not be an expert in Cartesian motion planning or modelling.
- in the "scheduling" part of our control Kernel, we separated the
  "timing" aspects from the "sequencing" aspects, although most of the
  design just use the same thing (priority based scheduler with periodic
  threads) for both purposes.


> Library structure :
> More, fine grained libraries mean : 1) gigantic load on maintenance (double 
> work, documentation, makefiles, scripts, installation etc) 2) gigantic load 
> on development : Imagine that a 'root' library has changed an interface or 
> so, then all depending libraries need to be recompiled and reinstalled _in 
> the correct order_ !

There would be no "root" library! And to take a practical example: the
Linux kernel is (more or less) working along the lines of semantic
decoupling, because an USB device driver writer should not worry about
other serial communication technologies. (The designers/writers of a
common infrastructure for pluggable serial media should, but then again
that is another fine example of semantic decoupling.)

> Orocos@KUL has only 4 packages and we already experience 
> time loss due to separate recompilation and installation when
> developping.
So there must be something wrong with your responsible senior designer :-)

> As the proposal is correct in theory, I believe the practical
> constraints were not taken into account.
For once, my writings were _very_ much inspired by the hard lessons
I've learned in our previous robot control software trials...

Herman

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480